|
|
 |
Warum Virtual Server?Mit dem explodierendem Wachstum des Internets und seiner anwachsenden wichtigen Rolle in unserem Leben, nimmt der Traffic auf dem Internet dramatisch zu, welcher letztes Jahr zu 100 Prozent angestiegen ist. Die Arbeitslast auf den Servern wächst rapide an, so das Server für eine kurze Zeit einfach überladen werden, in besonder Weise für einen populären Web Server. Zur Bewältigung des überladungs Problems von den Servern, gibt es zwei Lösungen. Eine ist die einzelne Server Lösung, d.h. den Server zu einem höher performanten Server austauschen, aber er wird schon bald wieder überladen sein, wenn die Anfragen ansteigen, so das wir ihn schon wieder austauschen können, der upgrade Prozess ist komplex und die Kosten sind hoch. Die andere ist die Multi-Server Lösung, d.h. wir bauen einen skalierbaren Server auf einen Cluster von Servern. Wenn der Load ansteigt, können wir einfach einen neuen Server oder mehrere in das Cluster aufnehmen um die ansteigenden Anfragen zu bewältigen. Wie auch immer, es gibt mehrere Methoden den Cluster aus Servern zu konstruieren. Jetzt das am meisten benutzte ist Round-Robin DNS, welches einen einfachen Namen zu verschiedenen IP Adressen in einer Round-Robin Mannier Mapt, so dass unterschiedliche Clients zu verschiedenen Servern in dem Cluster gemappt werden. Eine ideale Situation. In dieser Weise, wird der Load unter den Servern verteilt. Wie auch immer, zu der Caching natur von Clients und hierarchischen DNS Systemen, kommt es leicht zur dynamischen Load unbalancierung zwischen den Servern, so dass es für einen Server nicht leicht ist, seinen Peak Load zu handhaben. Der TTL (Time To Live) Wert von einem Name Mapping kann bei Round Robin-DNS nicht gut ausgesucht werden , mit kleinen Werten RR-DNS ist wie ein Flaschenhals, und mit höheren Werten der TTL Wert ist mit 0 besetzt, die Scheduler Feinkörnigkeit ist pro Host, verschiedenartige User zugriffs Muster können zu dynamischer Load unbalancierung führen, weil einige Leute möglichereweise eine menge Seiten von dieser Site anfordern. Und andere mögen zu ein paar Seiten Surfen und weggehen. Ausserdem ist es nicht so zuverlässig wenn ein Server Node ausfällt, und der Client welcher den Namen zu der IP Adresse Mapt herausfindet, das der Server down ist. Das Problem besteht auch wenn der Benutzer die "reload" oder "refresh" Buttons in seinem Browser drückt. Ein eben besserer Weg ist es einen Load Balancer zu benutzen um den Load zwischen Servern in einem Cluster aufzuteilen. Die parallelen Dienste der Server können wie ein Virtueller Dienst an einer einzelnen IP Adresse erscheinen, so dass der End-Benutzer einen Virtuellen Server sieht, nicht einen Cluster aus Servern. Die Scheduling Feinkörnigkeit ist pro Verbindung. Ausfälle können Maskiert werden, wenn ein Server oder mehrere ausfallen. Das Server Management wird dadurch sehr einfach, und Administratoren können einen Server oder mehrere aus dem Dienst zu jeder Zeit herausnehmen, was nicht die Dienste für die Benutzer unterbricht. Load Balancing kann in zwei Stufen erfolgen, Applications-Level und IP-Level. Als Beispiel, Reverse-proxy und pWEB ist eine Applications-Level Load Balancing Methode um einen skalierbaren Web Server zu bauen. Sie forwarden die HTTP Anfragen zu den verschiedenen Web Servern im Cluster, bekommen die Ergebnisse zurück, und schicken Sie an die Clients zurück. Nun der Overhead mit den HTTP Anfragen und ihren Antworten in dem Applications-Level ist hoch. Ich glaube der Applications-Level Load Balancer wird der nächste Flaschenhals sein, wenn die Anzahl der Server Nodes zu 4 oder mehr ansteigen wird, welches von dem Durchsatz eines jeden Servers abhängt. Ich bevorzuge das IP-Level Load Balancing, weil der Overhead von IP Load Balancing gering ist, und die maximale Anzahl an Server Nodes kann 25 oder bis zu 100 erreichen. Das ist wofür der Linux Virtual Server Code Designed wurde. Wie es funktioniert wird im Detail in dem nächsten Abschnitt erklärt werden.
Übersetzung durch Stefan M. Dohn Original Text von Wensong
|
