ICT sicherheit


1. Ausfall einer Festplatte Fällt eine Festplatte aus, hat dies für den operativen Betrieb so gut wie keine Folgen. Der Administrator tauscht die Platte im laufenden Betrieb aus, die Daten der defekten Platte werden einfach wieder synchronisiert.


2. Ausfall eines wichtigen Komponenten in den Disk-Shelves Das Multi-pathing der Storage Nodes sorgt beim Ausfall eines SAS Kabels, SAS-HBAs oder Expanders dafür, dass alle Services ohne Unterbrechung online bleiben. Der Administrator ersetzt die Teile im laufenden Betrieb.


3. Ausfall eines ganzen Disk-Shelves Die Verteilung der RAIDZ-2-Festplattenverbünde werden so zwischen den JBODs verteilt, dass auch ein kompletter JBOD-Ausfall verkraftet wird. Geht nach einem Ausfall eines JBODs dieser wieder online, so werden nur die bis dahin veränderten Daten synchronisiert. Alle Services bleiben so ohne Unterbrechung online, ohne dass ein nennenswerter Einbruch der Performance zu erwarten ist.


4. Ausfall eines Storage Nodes


Beim Ausfall eines kompletten Servers der Storage Nodes übernimmt ein zweiter Server am selben Standort die Aufgaben des defekten Servers innerhalb weniger Sekunden. Obwohl der I/O-Datenstrom kurzzeitig aussetzt, welches von den Service Nodes im oberen Bereich bemerkt wird, werden diese Aussetzer nicht an die Anwendungen weitergereicht, da zu jeder Zeit noch der Spiegel zum zweiten Standort vorhanden ist.


5. Ausfall eines Switches, Kabels oder Fibre Channel-HBAs zwischen Storage Nodes und den oberen Service Nodes Auch dieses Szenario wird durch Multi-pathing der Service Nodes bewältigt. Ein Failover auf das andere Rechenzentrum ist nicht notwendig und die Performance der Applikationen wird nicht merklich beeinträchtigt.


6. Ausfall eines Service Nodes


Bei einem kompletten Ausfalls eines Service-Nodes kommt es bei der Nutzung von ZFS nur zu einer kurzen, einige Sekunden dauernden Unterbrechung des I/O-Stroms an die Applikationen. Die Umschaltzeit ist abhängig von der Anzahl der Services wie NFS Shares, CIFS-Shares, iSCSI-Targets. Sie ist dagegen unabhängig von der Datenmenge, da ZFS- Technologie im Gegensatz zu anderen Systemen nie einen kompletten ‘File System Check’ durchführen muss.


Für die Applikationsserver ist diese Umschaltung transparent, im Falle von Fibre Channel müssen die Applikationsserver vom Betriebssystem einen ALUA-fähigen Multi-pathing Treiber mitbringen, was heutzutage oft Standard ist. Das Cluster wird so konfiguriert, dass die Services immer zuerst auf den lokal benachbarten Node umgezogen werden, um ein Site Failover nur für den kompletten Ausfall eines Standorts nötig zu machen.


7. Ausfall eines kompletten Standorts Im schlimmsten anzunehmenden Fall, fällt ein kompletter Standort aus. Erst in diesem Fall nutzt der Metrocluster die Redundanz des Rechenzentrums für ein Failover und der zweite Standort übernimmt alle Services. Den Anwendungsservern stehen somit alle Dienste zur Verfügung, wenn auch nur auf der Hälfte der Service Nodes, d.h. mit eingeschränkter Performance.


Da in diesem Fall allerdings auch das Spiegeln, Lesen und Schreiben zwischen den Standorten wegfällt, verbessert sich die Latenz, was zum Beispiel bei Datenbanken sogar zu besserer Performance führen kann. Geht der ausgefallene Standort wieder online, wird niemals der komplette Datenbestand zurückgespielt, sondern nur alle bisher dahin geänderten Daten.


Vermeidung eines ‘Split Brains’ Um bei einem einfachen Ausfall der Verbindungen zwischen den Rechenzentren nicht zu undefinierten Zuständen („Split Brain“) zu gelangen, wird ein ZFS-Metrocluster wie folgt implementiert:


1. Bei undefinierten Zuständen wird nicht auf Verdacht ein automatisches Umschalten zwischen den Sites ausgeführt. Services bleiben zuerst dort, wo sie bisher


liefen, online. Ein


Manuelles Eingreifen des Administrators ist mit einem Mausklick natürlich möglich.


2. Volume Service Lockung sorgt dafür, dass bei einem einfachen


Netzwerkausfall


zwischen den Sites dieser auch nur als Netzwerkausfall erkannt wird.


3. Ein Cloud Bacon Repeater sorgt dafür, dass die beiden Standorte gegenseitig den „Herzschlag“ des anderen


hören und über dessen Zustand informiert sind.


4. End-to-End-Prüfsummen über den gesamten Datenbestand hinweg sorgen dafür, dass fehlerhafte Daten automatisch gefunden und mittels der Parität repariert werden können.


5. Das Copy-on-write-Verfahren sorgt dafür, dass beim Schreiben neue Daten nicht den alten Daten-Block überschreiben. Stattdessen wird ein neuer Block zugewiesen und die Metadaten als Referenz des Originals ändern sich, um auf den neuen Block zu verweisen. Auf diese Weise sind Daten in ZFS stets konsistent.


Metrocluster bieten viele Vorteile


Hochverfügbare Rechenzentren sind heute das Rückgrat zahlreicher Unternehmen und sie investieren hohe Summen in ihre Geschäftstätigkeit. Für alle Unternehmen, die ohnehin zwei Standorte innerhalb von 50 Kilometer Umkreis besitzen oder die Ressourcen in einem von Dienstleistern betriebenen Rechenzentrum in Anspruch nehmen können, ist ein Metrocluster eine geeignete Methode, ihre Systeme unter allen Umständen zugänglich und aktiv zu halten.


März 2013 I www.dcsdach.info 23


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28