|
|
|
 |
 |
 |
Hochverfügbarkeit durch Cluster |
 |
|
|
Erinnern Sie sich? Hochverfügbarkeit (High Availability oder HA) beginnt im allgemeinen Sprachgebrauch bei Ausfallzeiten, die sich im jährlichen Schnitt in einem Bereich von weniger als einer Stunde bewegen - das entspricht dann einer Verfügbarkeit der Systeme von 99,99%. Nach den Vorbetrachtungen im letzten Thema der Woche wollen wir Ihnen heute einen kurzen Überblick geben über mögliche Lösungen zur Absicherung Ihrer IT-Systeme mit dem Ziel einer möglichst hohen Verfügbarkeit.
Es sei noch einmal daran erinnert, dass der Begriff der «Verfügbarkeit» aus der Perspektive des Anwenders zu sehen ist: Dieser möchte und muss möglicherweise ständig auf eine Ressource zugreifen können. Eine Ressource kann dabei ein Webserver, das Mailsystem, der Datenbankserver oder was auch immer sein. «Anwender» sind dabei nicht unbedingt externe Kunden - auch und gerade Nutzer im eigenen Unternehmen oder angedockte IT-Systeme müssen einen möglichst ununterbrochenen Zugriff auf die IT-Ressourcen eines Unternehmens haben. Ein funktionierender Onlineauftritt eines Reisebüros ist schön, aber wenig nützlich, wenn das dahinter stehende Online-Buchungssystem zusammengebrochen ist…
Übrigens: Dieses weitgehende Verständnis von Dienstleistung und der Zurverfügungstellung von IT-Ressourcen entspricht der Idee der ITIL, der IT Infrastructure Library - WEKA IT stellte Ihnen dieses wichtige «Handwerkzeug» für hochprofessionellen IT-Service bereits vor einiger Zeit an dieser Stelle vor. Die IT-Verantwortlichen sind demnach für eine Anwenderfreundliche IT-Umgebung verantwortlich. Den Anwender interessieren dabei weder die technischen Hintergründe zum System der Ressource noch Begründungen, weshalb die Ressource bei notwendigen Wartungsarbeiten, Systemwechseln, Updates und so weiter «vorübergehend unerreichbar» ist - den berüchtigten Satz «Wir danken für Ihr Verständnis» im Falle des (Aus-)Falles dürften in Wirklichkeit nur die wenigsten Anwender unterschreiben…
Wie aber soll ein Dienst, eine Ressource, ein Serversystem (oder was auch immer hinter dem Dienstleistungsauftrag der IT-Abteilung oder des externen Dienstleisters steckt) möglichst ständig verfügbar gehalten werden? Die wichtigsten Punkte seien hier noch einmal kurz genannt:
- ausreichende Kapazitäten des Systems
- qualitativ hochwertige Auslegung der Komponenten
- mehrfache Auslegung aller wichtigen Komponenten (Redundanz)
Und ein Notfallkonzept für die schnelle Wiederherstellung eines wichtigen Systems einschliesslich eines guten Backups versteht sich von selbst. Aber können Administrator, IT-Verantwortlicher und die Leitung des Unternehmens angesichts der latenten Bedrohung durch einen Ausfall der IT-Systeme niemals mehr beruhigt in das lange Wochenende fahren? Doch, durchaus - wenn die derzeit beste denkbare Lösung gefahren wird, nämlich die mehrfache Auslegung des Systems, des Dienstes oder der Ressource selbst. Das Stichwort heisst Clusterung der Ressourcen. Dies erreicht man durch die Parallelschaltung beziehungsweise den parallelen Betrieb zweier oder mehrerer Server, die sich möglichst auch noch an verschiedenen Standorten befinden; bitte beachten Sie, dass in letzterem Szenario natürlich auch noch die Netzanbindungen redundant, also mehrfach, vorgehalten werden müssen.
Im Prinzip sind im oben beschriebenen Szenario bereits beide Server geclustert - allerdings nur fast. Unter einem echten Cluster verstehen wir einen Verbund von Rechnersystemen, die nach Aussen als eine identische Einheit auftreten.
Es gibt grundsätzlich zwei verschiedene Auslegungen eines solchen Clusters:
- Aktiv/Passiv-Cluster: Hier läuft ein Server parallel zum Hauptsystem quasi im Leerlauf mit. Diese Lösung ist nicht zu verwechseln mit einem reinen Standby-System, welches nicht aktiv in Reserve gehalten wird und bei dem es Aufgabe des Administrators ist, das System zu aktivieren - was eine echte Hochverfügbarkeit zu einem beliebigen Zeitpunkt unmöglich macht. In einem Aktiv/Passiv-Cluster könnten sogar einzelne Ressourcen, die auf dem Hauptsystem laufen sollen, aber ausgefallen sind, auf dem Passiv-System aktiviert werden.
- Aktiv/Aktiv-Cluster: Hier laufen zwei oder mehr Server ständig parallel. Alle Systeme verarbeiten im Prinzip alle Anfragen (einfache Clusterung) oder teilen sich die Verarbeitung (Load Balancing).
In beiden Fällen muss eine Clustersoftware die Server überwachen und für das Aktivieren des Reservesystems (Aktiv/Passiv-Cluster) respektive das Abschalten des ausgefallenen Systems (Aktiv/Aktiv-Cluster) sorgen. Beim Betrieb zweier sich gegenseitig vertretender Server im Sinne der Lastverteilung UND der Hochverfügbarkeit würde ein Load Balancer vorgeschaltet, der dann nicht nur für eine Abschaltung eines ausgefallenen Systems, sondern im normalen Betrieb auch noch für eine Lastverteilung sorgt - wichtig für Server mit hohen Zugriffen. Andererseits muss sichergestellt sein, dass jedes einzelne System über genügend Leistung verfügt, um das oder die ausgefallenen System(e) vollwertig ersetzen zu können.
Einige weitere Probleme müssen gelöst werden:
- Wie stellt man sicher, dass die mehrfach ausgelegten Systeme auf denselben Datenbestand zugreifen?
- Was geschieht mit den offenen Verbindungen zwischen einem Client und einem aktuell ausfallenden Server?
- Im Falle eines Load Balancing, also einer Verteilung der Anfragen an die unterschiedlichen Server, bleibt die Frage der Absicherung des Load Balancers selbst. Dieses liesse sich aber natürlich durch eine Clusterung desselbigen lösen.
Es muss also sichergestellt sein, dass jedes System innerhalb des Clusterverbundes - diese einzelnen Systeme werden gemeinhin als Knoten, Nodes, bezeichnet - bei einem Ausfall eines Knotens die Funktionen des Systems weiterhin bereitstellen kann. Es bedarf dazu entweder eines ständigen Austauschs zwischen den einzelnen Knoten über die aktuell verarbeiteten Daten oder des erwähnten Load Balancers, der alle Informationen über die aktuell bearbeiteten Anfragen vorhält und diese entsprechend umleiten kann.
Das Problem, den Datenbestand redundant zu halten, lässt sich durch eine gemeinsame Datenquelle lösen: beispielsweise könnten im Cluster betriebene Mailserver auf eine gemeinsame Datenbank zugreifen. Diese wird über eine ebenfalls redundante Leitung an die Server angebunden. Gängige Lösungen sind NAS-Systeme, ein SAN oder iSCSI.
Dennoch bleibt noch das Problem der gerade geöffneten Verbindungen, die sich beim Ausfall eines Systems quasi im luftleeren Raum verlieren würden. Ganz einfach lässt sich dieses mit einem Ping, also dem Absenden einer ICMP Request Message auf das System, nachprüfen. Der ICMP Request wird von Server A beantwortet, dieser schickt die ICMP Reply Messages an den Client zurück. Bei einem plötzlichen Ausfall von Server A bleibt die Verbindung offen, der Client erhält einen TimeOut.
Es gab und gibt eine ganze Reihe an Lösungen, die für die gewünschte Synchronisation beziehungsweise den Abgleich der Daten zwischen den einzelnen Knoten eines Clusterverbundes sorgen. Mit dem «Oracle Parallel Server» (OPS) etwa konnte bereits in den 90er Jahren des vergangenen Jahrhunderts ein leistungsfähiger, aber auch recht komplex zu verwaltender Cluster aufgebaut werden, der - wie sollte es anders sein - für die Hochverfügbarkeit einer Oracle-Datenbank sorgte. Microsoft bietet ebenfalls Clusterlösungen für seine Serversysteme an. Dabei setzt Microsoft auf drei unterschiedliche Lösungen: Microsoft Cluster Service (MSCS), Component Load Balancing (CLB) und die Network Load Balancing Services (NLB). In der aktuellen Serverversion Windows Server 2008 spricht Microsoft vom Failover Clustering.
Eine der bekanntesten Lösungen aus dem OpenSource-Bereich ist Linux-HA, welches in der Version 2 vorliegt. Das auf Linux aufbauende High Availability mit dem Namen Linux-HA ist - in Massstäben der IT-Welt gemessen - recht alt, die erste kommerzielle Umsetzung gab es im Jahr 1999. Die Lösung war jedoch nicht besonders flexibel, unter anderem konnten lediglich Aktiv/Passiv-Cluster aufgebaut werden. Linux-HA in der Version 2 behebt viele der Einschränkungen der ersten Version, bietet Lösungen für bekannte Probleme wie Fencing und Quorum auf und ist vor allem unter einer freien Lizenz erhältlich.
Abgleich der Informationen
Jede Clustering-Lösung muss das Problem der Inkonsistenz des Datenbestandes lösen. Für den Abgleich der jeweils aktuell bearbeiteten Daten wird DRBD, das Distributed Replicated Block Device, genutzt. DRBD bildet ein blockorientiertes Device, einen Netzwerkspeicher, aus dem sich die Systeme praktisch «bedienen» können - der Datenbestand wird so immer konsistent gehalten.
Kontrollverbindung zwischen den Clusterknoten
Welche Software stellt nun die Kontrollverbindung zwischen den Servern her? Jede HA-Lösung verfügt - in Analogie zum Herzschlag eines Organismus aus Fleisch und Blut - über einen sogenannten heartbeat-Mechanismus, je nach Auslegung des Clusters als Aktiv/Aktiv oder Aktiv/Passiv mit unterschiedlicher Intention. In Linux-HA stellte die gleichnamige Komponente heartbeat lange die Standardlösung für diese Überprüfung dar: der Dienst überprüft, ob die beteiligten Komponenten noch aktiv sind. Bleibt das Signal (der «heartbeat») von einer der Komponenten aus, reagiert die Software, die Reserve wird aktiviert. Aufgrund einer ganzen Reihe an Einschränkungen des ursprünglichen heartbeat hat sich hier aber inzwischen OpenAIS als Standard etabliert.
Fazit
Dieser Beitrag kann verständlicherweise nur einen sehr kurzen Aufriss des komplexen Themas Hochverfügbarkeit und Clustering geben. Deutlich sollte eines geworden sein: Geht es um Hochverfügbarkeit im Serverbereich, führt kein Weg an einer Clusterung vorbei. Dabei können sowohl einzelne Dienste, die ein Server anbietet, als auch ganze Serversysteme per Cluster ausfallsicher vorgehalten werden.
Nicht vergessen werden dürfen bei einer Betrachtung dieses Themas die Aspekte der Komplexität und der Kosten für die jeweilige Lösung. Ein weiterer interessanter Ansatz liegt in der Virtualisierung der Systeme - hier öffnet sich ein ganz neues Feld der Möglichkeiten, wenn man Virtualisierung als Vehikel für die Hoch-Verfügbarkeit sieht. Grund genug für Weka-IT, dieses Thema demnächst einer genaueren Betrachtung zu unterziehen…
http://msdn.microsoft.com/en-us/library/aa907676.aspx
www.drbd.org/
www.linux-ha.org/
Hier gelangen Sie direkt zum Download
|
|
|
|
 |
| |
|
|
|
 |
Dipl.-Paed Lars Behrens
Herr Behrens ist Geschäftsführer der Firma MaLiWi IT. Staatlich geprüfter Netzwerkadministrator, Microsoft MCP / Linux LCP. Herr Behrens hat langjährige Erfahrung in der Beratung bei Planung und Einrichtung von IT-Systemen und Netzwerken und dem Support heterogener Systeme (Apple Macintosh, Microsoft Windows, Linux). Universitätsstudium der Pädagogik, mehrere Jahre Tätigkeit im Ausland. Seminar- und Kursleiter, Referent und Fachbuchautor.
|
|
 |
|
 |
 |
Fernzugriff mit TeamViewer: Fernwartung, Fernzugriff, Remote Control, das Ende der Turnschuhadministration - Schlagworte, die sicher jedem IT-Administrator und -verantwortlichen geläufig sind. Gemeint ist, dass die allfällige Wartung eines Rechners und vor allem die Unterstützung der Benutzer bei Fragen und Problemen nicht mehr direkt am Gerät erfolgt, sondern vom PC des Admins aus über das Intra- oder Internet hinweg. Heute sehen wir uns einmal eine interessante Lösung für diesen Fernzugriff an, die keine Client-Server-Infrastruktur und keine aufwändig einzurichtenden VPN-Tunnel benötigt: TeamViewer.
|
|
|
|
|
|
Hotline-Warteschleifen – Wie man sich gegen Abzockerei wehrt: Oft ärgert man sich über Warteschleifen, wenn man eine Dienstleistungstelefonnummer anruft. Ist diese gebührenpflichtig, kann man die Regeln des OR über Schlechterfüllung anwenden und Schadenersatz verlangen.
Wenn man eine geführenpflichtige Hotline anruft, kommt ein Vertrag zustande. Der Anrufer erwartet eine Dienstleistung. Dies kann eine Beratung sein oder beispielsweise die Vorbestellung eines Veranstaltungsbilletes. Wird der Anrufer in eine gebührenpflichtige Warteschleife umgeleitet, kann das verschiedene Gründe haben.
Natürlich gibt es immer wieder Zeiten, während denen die Servicemitarbeitenden überlastet sind. Dann wäre es korrekt, die Wartezeit und ihre Kosten vorher anzugeben oder noch besser, die Warteschleife gebührenfrei zu gestalten. Das ist technisch möglich. Für Beschwerden, Anfragen oder Reklamationen von Kunde sollte die Hotline kostenlos sein.
|
|
|
|
|
|
Sind Sie bereit für IPv6?: IPv6 wird kommen - im letzten «Thema der Woche» hatten wir einiges über die Hintergründe dieser Entwicklung aufgezeigt. Zwar steht die nächste Generation des weltweiten Standards für Internetprotokolle seit Jahren immer nur in den Startlöchern, ohne es bisher geschafft zu haben, IPv4 abzulösen. Dennoch ist dieser Schritt unausweichlich und überfällig - zu knapp war seinerzeit der Adressraum in IPv4 berechnet worden und zu sehr leiden bereits einige Regionen - vor allem im boomenden fernen Osten - unter der Adressenverknappung. Die Umstellung unseres Internets auf IPv6 ist also nur noch eine Frage des Zeitpunkts.
|
|
|
|
|
|
zeige die ersten 25
|
|
|
|
|
|
|
|
|
