IT-Architektur: High Availability, und Failover-Cluster – Ein Einstieg

(Last Updated On: 28. September 2015)

In meiner HA- und Failover-Reihe vermittle ich nach und nach Wissen über die Konfiguration von hochempfindlichen Enterprise-IT-Services in Hochverfügbarkeits- oder Failover-Szenarien.

Unterschied zwischen Load Balancing Clustern und Failover-Strategien

Es gibt zwei verschiedene Möglichkeiten, um ein System dauerhaft gegen Ausfall zu schützen: durch einen High Availability Cluster oder durch eine Failover-Konfiguration. Beide sind eigentlich für unterschiedliche Zwecke gedacht.

Load Balancing Cluster haben als primären Einsatzzweck eigentlich den Lastausgleich von Serverdiensten. Das bedeutet: Wenn ein einziges Serversystem nicht mehr ausreicht, um die hereinkommenden Useranfragen in angenehmer Reaktionszeit zu beantworten, können Sie einen zweiten, dritten und noch einige Server mehr hinzuschalten, damit diese sich die Last aufteilen und somit ein höheres Nutzeraufkommen bewältigen können. Damit geht natürlich aber auch einher, dass dadurch gleichzeitig der Dienst besser verfügbar bleibt, wenn ein einzelner Server ausfällt. Eine High Availability Koniguration bringt also in einem gewissen Maße schon von Haus aus eine Ausfallsicherheit mit. Die tritt jedoch nur ein, wenn Ihre Hochverfügbarkeitskonfiguration auch den Ausfall eines Servers verkraften kann. Fällt ein Server aus und die restlichen Serversysteme brechen unter der zusätzlichen Last zusammen, haben Sie auch keine Ausfallsicherheit.

Eine Failover-Konfiguration bietet keinen Lastausgleich zwischen Serversystemen, bietet dafür aber eine Ausfallsicherheit zu einem wesentlich günstigeren Preis. Bei einer Failover-Konfiguration bedient ein Produktivserversystem die Nutzeranfragen, und ein zweites System wird ohne Lastaufkommen in der Rückhand gehalten, falls das Produktivsystem ausfällt. Die Konfiguration ist dabei so gestrickt, dass bei Ausfall eines Servers die möglichst aktuellen Serverdaten an das Failover-System überspielt werden und dann der Serverdienst auf dem Failover-Sytem neu gestartet wird. Somit können die Nutzer dann auf dem Failover-Sytem weiterarbeiten.

Man unterscheidet zwei Varianten von Faillover-Clustern, auch Aktiv/Passiv-Cluster genannt. eine Variante, das Hot-Standby-Failover schaut so aus. Die minimale Konfiguration sind zwei live betriebene Server, wobei nur ein Server derzeit die nutzeranfragen beantwortet und der andere nur bereit steht, falls der erste Server ausfällt.

2015-08-26_12h47_21

Nun gibt es verschiedene Fälle. die eintreten können. Der einfachste fall ist der, dass der gesamte Server ausfällt oder der Server gewartet werden und somit offline genommen werden muss. Dann springt Server 2 einfach in vollem Umfang für Server 1 ein. Die Clients verbinden sich statt auf Server 1 plötzlich auf Server 2, kriegen davon aber nichts mit.

2015-08-26_12h49_59

Wenn dieser Wechsel von Server 1 auf Server 2 durch einen unvorhergesehenen Ausfall hervorgerufen wird, spricht man von einem Failover. Wenn ein Systemadministrator den Server manuell offline genommen hat, weil der Server gewartet werden muss (Austausch von Festplatten oder anderer Hardware, Einspielen von Betriebssystemupdates o. Ä.), spricht man von einem Switchover. Wenn man irgendwann vom Failover-System zurück auf das primäre Produktivsystem wechselt, spricht man von einem Fallback.

Damit so ein Hot-Standby-Backup reibungslos funktioniert, muss natürlich der Server 2 an die topaktuellen Daten kommen, welche kurz vor dem Ausfall von Server 1 zur Verfügung standen. Ansonsten wäre es ja so, dass die Änderungen, welche die Nutzer kurz vor dem Ausfall von Server 1 gemacht haben, verloren gehen würden. Deswegen arbeitet man in einem Failover-cluster häufig mit einem Storage Attached Network, so dass beide Server immer auf das selbe Dateisystem zugreifen.

2015-08-26_12h53_33

Eine andere Variaante des Failover-Clusters oder Aktiv/Passiv-Clusters ist ein Cold-Standby-System. hierbei ist das Failover-system ausgeschaltet / auf Standby, solange der Primärserver läuft.

2015-08-26_16h19_18

Erst wenn der Primärserver ausfällt, wird das Failover-System hochgefahren und die Serverdienste werden mit den aktuellen Daten gestartet. Bei einem Aktiv/Passiv-Cluster übernimmt die Cluster-Software das Hochfahren des Failover-Systems. In primitiven Steinzeit-Cold-Standby-Systemen fährt der Administrator das System manuell hoch, sobald er davon Wind bekommt, dass das Primärsystem ausgefallen ist.

2015-08-26_16h21_11

die Vor- und nachteile liegen auf der hand: Das Failover-system verursacht in der Zeit, in welcher das Primärsystem sauber läuft, keine laufenden Kosten. Dafür dauert es länger, bis das Failover-System für die Clients zur Verfügung steht, wodurch es zu einer downtime kommt.

Es gibt noch ein weiteres Aktiv/Passiv-Szenario, welches Warm-Backup genannt wird. Beim Hot STandby Backup laufen zwei oder mehrere Server parallel und können gegenseitig übernehmen, wenn andere Partner aus dem Hot-Standb-Verbund ausfallen. Beim Hot Standby Backup greifen hierbei beide serer auf die selbe Datenquelle zu, alsoa uf das Storage Attached Network.

Beim Warm-Standby-Backup hält der zweite server hingegen sein eigenes Replikat vor, das heißt er verwendet nicht die selbe Quelle wie der Originalserver, sondern die Datenquelle des Originalservers wird in regelmäßigen Abständen auf die Datenquelle des Backup-Servers repliziert. Das heißt aber auch, dass bei einem Ausfall des Systems die aktuellen Daten erst von der Datenquelle des ausgefallenen Servers auf die Datenqeulle des Redundanzsystems fertig repliziert werden müssen, was etwas länger dauer,t als wenn sich beide Systeme die selbe Datenquelle teilen. DAher nur warm Backup. Vorteil ist hingegen, dass es eben zwei voneinander komplett unabhängige Datenquellen gibt.

Ein weiteres Szenario ist der Aktiv/Aktiv-Cluster. Hierbei teilen sich die Systeme von Anfang an die Ressourcen beider clientanfragen.

2015-08-26_16h29_01

Das Problem hierbei? Nun, man hat keine Ausfallsicherheit, solange nicht ein einziger der beiden Server ausreichen würde, um alle Clientanfragen zu bedienen. Das heißt ein einziger Server alleine muss dazu in der lage sein, alle Cleintanfragen alleine zu bewältigen. Diese Form des Aktiv/Aktiv-Clusters nutzt die Ressourcen der Systeme besser als ein Aktiv/Passiv-Hot-Standby-System, verursacht aber mehr Kosten als ein Aktiv/Passiv-Cold-Standby-System. Da man bei einem Aktiv/Aktiv-Cluster jedoch einen höheren Konfigurations- und Wartungsaufwand hat als bei eienm Aktiv/Passiv-Hot-Standby-Cluster, bevorzugt man in diesem Szenario das Aktiv/Passiv-Hot-Standby-Szenario.

Einen Aktiv/Aktiv-Cluster bevorzugt man ab dem Moment, in welchem ein Server alleine nicht mehr ausreicht, um alle Cleintanfragen bewältigen zu können. In diesem Fall hätten wir dann die folgende Konfiguration

2015-08-26_20h19_23

Jetzt fragt ihr euch vielleicht: „Ok, also aknn man generell sagen, dass man ab dem Moment, wo man zwei Server für den Lastausgleich braucht, immer einen Aktiv/Aktiv-Cluster nimmt?“. Nicht ganz. Ein anderes Beispiel. Wir haben zwei webservers in einem Cluster, weil ein einziger Webserver nicht mehr dazu in der Lage ist, um alle Benutzeranfragen bewältigen zu können. Alle Webserver könnten wir also mit einem Aktiv/Aktiv-Cluster abbilden

2015-08-26_20h23_50

Wie ihr jedoch vielleicht wisst, braucht man für dynamische websiten auch einen Datenbank-Server. die Datenbank jedoch schafft es derzeit alleine, alle Anfragen der Webserver an die Datenbank zu verarbeiten.

2015-08-26_20h25_44

Egal ob der Datenbankserver jetzt auf einem extra Server läuft oder auf einem Host, auf dem auch einer der drei Webserver drauf ist: Jetzt könnt ihr euch sicher vorstellen, dass es fatal wäre, wenn der Datenbankserver ausfällt. Denn dann können die nutzer die Website nicht nutzen, obwohl sich alle Webserver in einem ausfallsicheren Cluster befinden. Man nennt sowas einen Single Point of Failure. Ihr seht aber auch bestimmt ein, dass es nicht wirtscahftlich wäre, den Datenbankserver nun ebenfalls in einem Aktiv/Aktiv-Cluster mit drei Knoten laufen zu lassen, wenn doch ein einziger Server ausreichen würde, um alle Webserver-Anfragen zu beantworten? Also wäre es doch wirtschaftlicher, den Datenbankserver in enem Aktiv/Passiv-Cluster unterzubringen, egal ob man diesen dann Hot-STandby oder Cold-Standby macht?

Cluster- und Failover-Konfigurationen lassen sich nämlich genua für solche Szenarien miteinander kombinieren. Somit ist es möglich, einen Lastausgleich herzustellen und gleichzeitig eine Failover-Konfiguration für kritische Dienste zur Verfügung zu stellen. Dies nennt man dann einen High Availability-Cluster.

2015-08-26_20h30_36

Storage Cluster

ein Storage Cluster wird genutzt, um ein Dateisystem für mehrere Serversysteme in einem Cluster zur Verfügung zu stellen. das heißt mehrere Serversysteme in einem Clusterverbund tauschen permanent und ununterbrochen ihre Daten untereinander aus, so dass sie immer die selbe Spiegelung eines Dateisystems haben. So können mehrere Serversysteme auf die selbe Datenbasis zugreifen und somit mit den selben Daten arbeiten. Nur so ist es überhaupt möglich, dass beispielsweise ein Webserver von Google, der in Deutschland steht, auf die selben Daten zugreifen kann wie die us-amerikanischen Server. Ein weiterer Vorteil ist, dass durch die Verteilung der Daten auf mehrere Standorte auch irgendwie auch schon ein automatisches Backup vorhanden ist.

ein Storage cluster kümmert sich also nicht um eine lastaufteilung zwiscehn den Serverdiensten, sondern um eine Lastaufteilung und eine Ausfallsicherheit des von diesen Serverdiensten in Anspruch genommenen Speichersysteme.

2015-08-26_12h22_14

die Abbildung illustriert ein einfaches Beispiel. Es gibt verschiedene Storages in verschiedenen Standorten, also beispielsweise USA, Deutschland und im United Kingdom. Diese Storages synchronisieren sich gegenseitig. Alle Google-Server können wiederum auf jeden einzelnen dieser Storages zugreifen, um sich mit aktuellen daten zu versorgen. Dabei bevorzugen die Server natürlich den Server, der am nächsten bei Ihnen dransteht. Fällt der nächstgelegene Storage aber einmal aus, können immer noch die Speicher der anderen Standorte abgefragt werden.

In der Praxis würden natürlich für jeden Standort auch mehrere Storages im Cluster eingebunden werden. Somit gäbe es für den Standort Deutschland alleine beispielsweise schon drei Storage-Knoten innerhalb des Storage-Clusters.

Virtuelle Hostnames und Virtuelle IP-Adressen

Wie Sie vielleicht wissen, ist eine Hürde bei der HA- oder Failover-Konfiguration von Serversystemen, dass beim Ausfall eines Serversystems das zweite verfügbar gehaltene Serversystem unter dem selben Hostnamen erreichbar sein muss. Als Beispiel können Sie etwa annehmen, was passieren würde, wenn nur ein einziger Server der suchmaschine Google unter dem Hostnamen www.google.de erreichbar wäre und genau dieser ausfallen würde. Dann könnten Sie einen eventuell vorhandenen Ausweichserver, der aber auf einem anderen Hostnamen wie beispielsweise www2.google.de hört, nicht mehr über dieselbe URL erreichen.

Es muss also möglich sein, dass der zweite Server nicht nur über seinen expliziten Hostnamen www2.google.de erreichbar ist, sondern im Falle eines Ausfalls oder einer Lastspitze, bei dem er einspringen muss, auch unter www.google.de.

Hierbei gibt es zwei Hürden zu überwinden. Zum einen muss auf DNS-Ebene der selbe Hostname auf mehrere IP-Adressen aufgelöst werden können. Dazu brauchen Sie

  • für jeden Host eine eigene IP-Adresse
  • für jeden Host einen expliziten Hostnamen, beispielsweise www1.google.de und www2.google.de
  • einen gemeinsamen Hostnamen, auch Shared hostnamen. Also etwa www.google.de

Auf ihrem DNS-Server richten Sie für die beiden Hosts jeweils die expliziten Hostnamen über einen A-Record an. Sie lassen also www1.google.de auf die IP-Adresse des 1. Servers und www2.google.de auf die IP-Adresse des 2. Servers zeigen

Für den Shared Hostname richten Sie hingegen mehrere A-Records an. Das heißt, es gibt einen A-Record für www.google.de, er auf die IP-Adresse von www1.google.de zeigt, und einen A-Record für www.google.de, der auf die IP-Adresse von www2.google.de zeigt.

Häufig ist es so gelöst, dass die Shared IP-Adresse eine öffentliche IP-Adresse ist, die über das Internet erreichbar ist, und die expliziten IP-Adressen sind IP-Adressen im internen, lokalen Netzwerk. das muss aber nicht sein. Sie können sich beispielsweise zwei VServer net NetCup mieten, die beide eine öffentliche IP-Adresse haben, und diese Lösung genau so umsetzen. Dabei ist diese IP-Adresse wiederum keine „physikalische IP-Adresse“, die für nur einen expliziten Host spezifiziert ist, sondern es handelt sich hierbei um eine sogenannte virtuelle IP-Adresse. Das heißt sobald ein Knoten ausfällt oder zu viel Last zu tragen hat, weist die clustersoftware dem zweiten Knoten die virutelle IP-Adresse und den virtuellen / Shared Hostnamen www.google.de zu.

Ausblick auf die nächsten Posts

Im nächsten Post beschäftigen wir uns mit praktischen Projekten zum Einrichten kleiner Cluster-Szenarien.

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren...

Kommentar verfassen

This site uses Akismet to reduce spam. Learn how your comment data is processed.