{"id":35387,"date":"2019-10-31T22:04:01","date_gmt":"2019-10-31T19:04:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/aerodisk-engine-katastrofoustojchivost-chast-1\/"},"modified":"2019-10-31T22:04:01","modified_gmt":"2019-10-31T19:04:01","slug":"aerodisk-engine-katastrofoustojchivost-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-1","title":{"rendered":"AERODISK Engine: Katastrophenschutz. Teil 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/7749b28518da6543acd41dce646844c0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Hallo, liebe Leser von Habr! In diesem Artikel geht es um die Implementierung von Katastrophenschutz-Ma\u00dfnahmen in den Speichersystemen des AERODISK Engines. Urspr\u00fcnglich wollten wir in einem Beitrag sowohl \u00fcber die Replikation als auch \u00fcber Metro-Cluster berichten, jedoch wurde der Artikel zu umfangreich, weshalb wir ihn in zwei Teile aufgeteilt haben. Lassen Sie uns von einfachen zu komplexen Themen \u00fcbergehen. In diesem Artikel werden wir die synchrone Replikation einrichten und testen \u2013 wir werden ein Rechenzentrum (RZ) ausfallen lassen und die Verbindung zwischen den RZ unterbrechen, um zu sehen, was passiert.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Unsere Kunden stellen uns h\u00e4ufig verschiedene Fragen zur Replikation. Daher m\u00f6chten wir, bevor wir mit der Einrichtung und dem Test der Replikationsimplementierungen beginnen, kurz erl\u00e4utern, was Replikation in Speichersystemen bedeutet.<\/p>\n<p><\/p>\n<h2 id=\"nemnogo-teorii\">Ein wenig Theorie<\/h2>\n<p><\/p>\n<p>Die Replikation in Speichersystemen ist ein kontinuierlicher Prozess, der sicherstellt, dass die Daten gleichzeitig auf mehreren Speichersystemen identisch sind. Technisch gesehen wird die Replikation auf zwei Arten durchgef\u00fchrt.<\/p>\n<p><\/p>\n<p><strong>Synchrone Replikation<\/strong> \u2013 dies ist die Datenkopie von der prim\u00e4ren Speichereinheit auf die Sicherungseinheit, gefolgt von der verbindlichen Best\u00e4tigung beider Speichereinheiten, dass die Daten geschrieben und best\u00e4tigt wurden. Erst nach der Best\u00e4tigung von beiden Seiten (von beiden Speichereinheiten) gelten die Daten als geschrieben und k\u00f6nnen bearbeitet werden. Damit wird die garantierte Identit\u00e4t der Daten auf allen an der Replikation beteiligten Speichereinheiten sichergestellt.<\/p>\n<p><\/p>\n<p>Vorteile dieser Methode:<\/p>\n<p><\/p>\n<ul>\n<li>Daten sind immer identisch auf allen Speichereinheiten<\/li>\n<\/ul>\n<p><\/p>\n<p>Nachteile:<\/p>\n<p><\/p>\n<ul>\n<li>Hohe Kosten der L\u00f6sung (schnelle Kommunikationskan\u00e4le, teure Glasfaser, Langwellen-Transceiver usw.)<\/li>\n<li>Entfernungseinschr\u00e4nkungen (innerhalb von einigen Dutzend Kilometern)<\/li>\n<li>Kein Schutz vor logischer Datenbesch\u00e4digung (wenn die Daten absichtlich oder versehentlich auf der prim\u00e4ren Speichereinheit besch\u00e4digt werden, werden sie automatisch und sofort auch auf der Sicherungseinheit besch\u00e4digt, da die Daten immer identisch sind (so ein Paradoxon))<\/li>\n<\/ul>\n<p><\/p>\n<p><strong>Asynchrone Replikation<\/strong> \u2013 dies ist ebenfalls eine Datenkopie von der prim\u00e4ren zum sekund\u00e4ren Speicher, jedoch mit einer bestimmten Verz\u00f6gerung und ohne die Notwendigkeit einer Best\u00e4tigung der Speicherung auf der anderen Seite. Mit den Daten kann sofort nach der Speicherung auf dem prim\u00e4ren Speicher gearbeitet werden, w\u00e4hrend die Daten auf dem sekund\u00e4ren Speicher nach einiger Zeit verf\u00fcgbar sind. In diesem Fall wird die Identit\u00e4t der Daten nat\u00fcrlich nicht vollst\u00e4ndig gew\u00e4hrleistet. Die Daten auf dem sekund\u00e4ren Speicher befinden sich immer ein wenig \"in der Vergangenheit\".<\/p>\n<p><\/p>\n<p>Vorteile der asynchronen Replikation:<\/p>\n<p><\/p>\n<ul>\n<li>Niedrige Kosten der L\u00f6sung (beliebige Kommunikationskan\u00e4le, Glasfaser optional)<\/li>\n<li>Keine Einschr\u00e4nkungen hinsichtlich der Entfernung<\/li>\n<li>Auf dem sekund\u00e4ren Speicher werden die Daten nicht besch\u00e4digt, falls sie auf dem prim\u00e4ren besch\u00e4digt werden (zumindest f\u00fcr eine gewisse Zeit). Wenn die Daten besch\u00e4digt sind, kann die Replikation jederzeit gestoppt werden, um eine Besch\u00e4digung der Daten auf dem sekund\u00e4ren Speicher zu vermeiden.<\/li>\n<\/ul>\n<p><\/p>\n<p>Nachteile:<\/p>\n<p><\/p>\n<ul>\n<li>Die Daten in verschiedenen Rechenzentren sind immer unidentisch.<\/li>\n<\/ul>\n<p><\/p>\n<p>Die Wahl des Replikationsmodus h\u00e4ngt von den gesch\u00e4ftlichen Anforderungen ab. Wenn es f\u00fcr Sie entscheidend ist, dass die Daten im Backup-Rechenzentrum identisch mit denen im Hauptrechenzentrum sind (d.h. das Gesch\u00e4ft fordert RPO=0), m\u00fcssen Sie bereit sein, in eine synchrone Replikation zu investieren und deren Einschr\u00e4nkungen in Kauf zu nehmen. Ist eine gewisse Datenverz\u00f6gerung akzeptabel oder einfach das Budget begrenzt, sollten Sie definitiv die asynchrone Methode w\u00e4hlen.<\/p>\n<p><\/p>\n<p>Ein spezieller Modus, den wir hervorheben m\u00f6chten (genauer gesagt, eine Topologie), ist der Metro-Cluster. Im Metro-Cluster wird eine synchronisierte Replikation eingesetzt, jedoch erm\u00f6glicht der Metro-Cluster im Gegensatz zu einer herk\u00f6mmlichen Replikation, dass beide Storage-Systeme aktiv betrieben werden. Es gibt also keine Unterscheidung zwischen aktiven und passiven Rechenzentren. Die Anwendungen arbeiten gleichzeitig mit zwei Storage-Systemen, die physisch in unterschiedlichen Rechenzentren untergebracht sind. Ausfallzeiten bei St\u00f6rungen in dieser Topologie sind sehr gering (RTO liegt in der Regel bei Minuten). In diesem Artikel werden wir unsere Umsetzung des Metro-Clusters nicht behandeln, da dies ein sehr umfangreiches und tiefgehendes Thema ist, dem wir einen separaten, n\u00e4chsten Artikel widmen werden. <\/p>\n<p><\/p>\n<p>Ganz oft, wenn wir \u00fcber Replikation mittels Storage-Systemen sprechen, stellt sich vielen die berechtigte Frage: &gt; \u201eViele Anwendungen verf\u00fcgen \u00fcber eigene Replikationsmethoden, warum also Replikation auf dem Storage-System nutzen? Ist das besser oder schlechter?\u201c<\/p>\n<p><\/p>\n<p>Hier gibt es keine eindeutige Antwort, deshalb nennen wir die Argumente F\u00dcR und GEGEN:<\/p>\n<p><\/p>\n<p>Argumente F\u00dcR die Replikation auf dem Storage-System:<\/p>\n<p><\/p>\n<ul>\n<li>Einfachheit der L\u00f6sung. Mit einem einzigen Tool k\u00f6nnen Sie das gesamte Datenvolumen replizieren, unabh\u00e4ngig von der Art der Last und den Anwendungen. Wenn die Replikation durch Anwendungen erfolgt, m\u00fcssen Sie jede Anwendung einzeln einrichten. Bei mehr als zwei Anwendungen wird dies sehr m\u00fchsam und teuer (die Replikation von Anwendungen erfordert in der Regel eine separate und kostenpflichtige Lizenz f\u00fcr jede Anwendung. Aber dazu sp\u00e4ter mehr).<\/li>\n<li>Es k\u00f6nnen beliebige Dinge repliziert werden \u2013 beliebige Anwendungen, beliebige Daten \u2013 und sie sind immer konsistent. Viele (die meisten) Anwendungen haben keine eigenen Replikationsmethoden, und die Replikation vom Storage-System ist das einzige Mittel, um einen Katastrophenschutz zu gew\u00e4hrleisten.<\/li>\n<li>Zahlen Sie nicht zu viel f\u00fcr die Funktionalit\u00e4t der Anwendungsreplikation. In der Regel ist sie nicht g\u00fcnstig, ebenso wie die Lizenzen f\u00fcr die Replikation von Storage-Systemen. Aber f\u00fcr die Lizenz zur Replikation des Storage-Systems m\u00fcssen Sie einmalig zahlen, w\u00e4hrend die Lizenz f\u00fcr die Anwendungsreplikation f\u00fcr jede Anwendung separat erworben werden muss. Wenn es viele solcher Anwendungen gibt, summieren sich die Kosten und die Lizenzkosten f\u00fcr die Replikation des Storage-Systems werden zur Nebensache.<\/li>\n<\/ul>\n<p><\/p>\n<p>Argumente GEGEN die Replikation von Storage-Systemen:<\/p>\n<p><\/p>\n<ul>\n<li>Die Replikation mithilfe von Anwendungen bietet mehr Funktionalit\u00e4t aus Sicht der Anwendungen selbst, da die Anwendung ihre Daten besser kennt (was offensichtlich ist), gibt es daher mehr Optionen im Umgang mit den Daten.<\/li>\n<li>Hersteller bestimmter Anwendungen garantieren keine Konsistenz ihrer Daten, wenn die Replikation mit Drittanbieter-Tools erfolgt.*<\/li>\n<\/ul>\n<p><\/p>\n<p>* - umstrittener Punkt. Zum Beispiel hat ein bekannter Datenbankhersteller lange Zeit offiziell behauptet, dass ihre Datenbank nur mit ihren eigenen Mitteln ordnungsgem\u00e4\u00df repliziert werden kann, und jede andere Replikation (einschlie\u00dflich der von Storage-Systemen) sei \u201enicht wahr\u201c. Aber die Realit\u00e4t hat gezeigt, dass das nicht stimmt. H\u00f6chstwahrscheinlich (aber das ist nicht sicher) handelt es sich hierbei einfach um einen nicht ganz fairen Versuch, Kunden weitere Lizenzen zu verkaufen. <\/p>\n<p><\/p>\n<p>In den meisten F\u00e4llen ist die Replikation von Storage-Systemen besser, da sie eine einfachere und kosteng\u00fcnstigere L\u00f6sung darstellt. Es gibt jedoch komplexe Szenarien, in denen spezifische Anwendungsfunktionen erforderlich sind und direkt auf die Anwendungsebene der Replikation eingegangen werden muss. <\/p>\n<p><\/p>\n<h2 id=\"s-teoriey-zakonchili-teper-praktika\">Theorie abgeschlossen, nun zur Praxis.<\/h2>\n<p><\/p>\n<p>Wir werden die Replikation in unserem Labor einrichten. Unter Laborbedingungen haben wir zwei Rechenzentren emuliert (in Wirklichkeit sind es zwei nebeneinander stehende Racks, die so aussehen, als bef\u00e4nden sie sich in verschiedenen Geb\u00e4uden). Der Stand besteht aus zwei Engine N2 Storage-Systemen, die durch optische Kabel miteinander verbunden sind. An beide Storage-Systeme ist ein physischer Server mit Windows Server 2016 \u00fcber 10Gb Ethernet angeschlossen. Der Stand ist ziemlich einfach, aber das \u00e4ndert nichts an der Bedeutung.<\/p>\n<p><\/p>\n<p>Schematically, it looks like this:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/044f81f6145cd05695c236e21a3d9aba.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Logisch ist die Replikation wie folgt organisiert:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/87e88c44d68c32bdad776b626ed01bdd.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nun betrachten wir die funktionalen M\u00f6glichkeiten der Replikation, die uns derzeit zur Verf\u00fcgung stehen.<br \/>\nEs werden zwei Modi unterst\u00fctzt: asynchron und synchron. Es ist logisch, dass der synchrone Modus durch die Distanz und die Verbindungskan\u00e4le begrenzt ist. Insbesondere f\u00fcr den synchronen Modus ist es erforderlich, Glasfaser als physische Grundlage und 10-Gigabit-Ethernet (oder schneller) zu verwenden. <\/p>\n<p><\/p>\n<p>Die unterst\u00fctzte Entfernung f\u00fcr die synchronen Replikation betr\u00e4gt 40 Kilometer, mit einer maximalen Verz\u00f6gerung von 2 Millisekunden zwischen den Rechenzentren. Obwohl auch gr\u00f6\u00dfere Verz\u00f6gerungen funktionieren, wird es dabei zu erheblichen Schreibverz\u00f6gerungen kommen, was nachvollziehbar ist. Daher sollten Sie, wenn Sie eine synchrone Replikation zwischen Rechenzentren planen, die Qualit\u00e4t der optischen Verbindung und die Verz\u00f6gerungen \u00fcberpr\u00fcfen.<\/p>\n<p><\/p>\n<p>F\u00fcr die asynchrone Replikation sind die Anforderungen nicht so streng. Genauer gesagt, es gibt \u00fcberhaupt keine. Jede funktionierende Ethernet-Verbindung ist ausreichend.<\/p>\n<p><\/p>\n<p>Aktuell unterst\u00fctzt das AERODISK ENGINE SAN die Replikation f\u00fcr blockbasierte Ger\u00e4te (LUNs) \u00fcber Ethernet (entweder \u00fcber Kupfer oder Glasfaser). F\u00fcr Projekte, bei denen eine Replikation \u00fcber eine SAN-Switch-Architektur mit Fibre Channel erforderlich ist, arbeiten wir derzeit an einer entsprechenden L\u00f6sung, die jedoch noch nicht bereit ist. Daher bieten wir in diesem Fall nur Ethernet an.<\/p>\n<p><\/p>\n<p>Die Replikation kann zwischen beliebigen SANs der ENGINE-Serie (N1, N2, N4) von \u00e4lteren auf neuere Systeme und umgekehrt funktionieren.<\/p>\n<p><\/p>\n<p>Die Funktionalit\u00e4t beider Replikationsmodi ist vollst\u00e4ndig identisch. Im Folgenden finden Sie detaillierte Informationen dazu: <\/p>\n<p><\/p>\n<ul>\n<li>Die Replikation erfolgt im \u201eone-to-one\u201c-Modus, also klassisch mit zwei Rechenzentren, einem prim\u00e4ren und einem sekund\u00e4ren.<\/li>\n<li>Die \u201eOne-to-Many\u201c-Replikation erm\u00f6glicht es, einen LUN gleichzeitig auf mehrere Storage-Systeme zu replizieren.<\/li>\n<li>Aktivierung, Deaktivierung und \u201eUmdrehung\u201c der Replikation, entsprechend zum Ein- oder Ausschalten oder zur \u00c4nderung der Replikationsrichtung.<\/li>\n<li>Replikation ist sowohl f\u00fcr RDG-Pools (Raid Distributed Group) als auch f\u00fcr DDP (Dynamic Disk Pool) verf\u00fcgbar. Hierbei kann ein LUN eines RDG-Pools nur in einen anderen RDG repliziert werden, bei DDP funktioniert es analog.<\/li>\n<\/ul>\n<p><\/p>\n<p>Es gibt noch viele weitere kleine Besonderheiten, jedoch macht es wenig Sinn, sie alle aufzuz\u00e4hlen; wir werden sie im Verlauf der Einrichtung erw\u00e4hnen.<\/p>\n<p><\/p>\n<h2 id=\"nastroyka-replikacii\">Einrichtung der Replikation<\/h2>\n<p><\/p>\n<p>Der Einrichtungsprozess ist relativ einfach und besteht aus drei Phasen.<\/p>\n<p><\/p>\n<ol>\n<li>Netzwerkkonfiguration<\/li>\n<li>Speicherkonfiguration<\/li>\n<li>Einrichtung der Regeln (Beziehungen) und des Mappings<\/li>\n<\/ol>\n<p><\/p>\n<p>Ein wichtiger Punkt bei der Einrichtung der Replikation ist, dass die ersten beiden Phasen auf dem entfernten Storage-System wiederholt werden sollten, die dritte Phase jedoch nur auf dem Hauptsystem.<\/p>\n<p><\/p>\n<h3 id=\"nastroyka-setevyh-resursov\">Einrichtung der Netzwerkressourcen<\/h3>\n<p><\/p>\n<p>Zuerst m\u00fcssen die Netzwerkports konfiguriert werden, \u00fcber die der Replikationstraffic \u00fcbertragen wird. Dazu m\u00fcssen die Ports aktiviert und konfiguriert werden. <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/de\/lir\/ipv4\/\"   title=\"IP-Adressen\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"629\">IP-Adressen<\/a> im Abschnitt Front-End-Adapter. <\/p>\n<p><\/p>\n<p>Anschlie\u00dfend m\u00fcssen wir einen Pool (in unserem Fall RDG) und eine virtuelle IP-Adresse f\u00fcr die Replikation (VIP) erstellen. VIP ist eine schwebende IP-Adresse, die an zwei 'physische' Adressen der Storage-Controller (Ports, die wir gerade konfiguriert haben) gebunden ist. Sie wird die prim\u00e4re Schnittstelle f\u00fcr die Replikation sein. Alternativ kann auch mit VLANs gearbeitet werden, wenn getaggter Verkehr erforderlich ist.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/ca0a86542d8fe4bb9eb7498b66eede43.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Der Prozess zur Erstellung einer VIP f\u00fcr die Replikation unterscheidet sich kaum von der Erstellung einer VIP f\u00fcr Ein- und Ausgaben (NFS, SMB, iSCSI). In diesem Fall erstellen wir die VIP gew\u00f6hnlich (ohne VLAN), geben jedoch zwingend an, dass sie f\u00fcr die Replikation gedacht ist (ohne diesen Verweis k\u00f6nnen wir die VIP im n\u00e4chsten Schritt nicht zu den Regeln hinzuf\u00fcgen).<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/054a5d2a9695aed19aafbd2efe833196.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Die VIP muss sich im selben Subnetz wie die IP-Adressen der Ports befinden, zwischen denen sie 'schwebt'.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/fb96d1609425dcebb5345435ac7f6857.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir wiederholen diese Einstellungen auf dem entfernten Storage-System mit einer anderen IP-Adresse, selbstverst\u00e4ndlich.<br \/>\nVIPs von verschiedenen Storage-Systemen k\u00f6nnen sich in unterschiedlichen Subnetzen befinden, Hauptsache, zwischen ihnen gibt es Routing. In unserem Fall ist genau dieses Beispiel gezeigt (192.168.3.XX und 192.168.2.XX).<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/3d43b4339277e50413cc9944c53e0d62.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Damit ist die Vorbereitung des Netzwerkteils abgeschlossen.<\/p>\n<p><\/p>\n<h3 id=\"nastraivaem-hranilischa\">Wir konfigurieren die Speicher.<\/h3>\n<p><\/p>\n<p>Die Einrichtung des Speichers f\u00fcr die Replikation unterscheidet sich nur darin, dass die Zuordnung \u00fcber das spezielle Men\u00fc \u201eReplikationszuordnung\u201c erfolgt. Ansonsten bleibt alles wie bei der normalen Einrichtung.<\/p>\n<p><\/p>\n<p>Im zuvor erstellten Pool R02 muss ein LUN erstellt werden. Wir erstellen ihn und nennen ihn LUN1.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/263fa2d3a06318d4e7da280b869123ca.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Au\u00dferdem m\u00fcssen wir ein identisches LUN auf dem entfernten Speichersystem mit demselben Volumen erstellen. Wir tun dies. Um Verwirrungen zu vermeiden, nennen wir das entfernte LUN LUN1R. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/bbd302358c2bd825a234da94b2410770.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Falls wir ein bereits existentes LUN verwenden m\u00fcssten, m\u00fcsste w\u00e4hrend der Einrichtung der Replikation dieses produktive LUN vor\u00fcbergehend vom Host abgemeldet werden, und auf dem entfernten Speichersystem m\u00fcsste einfach ein leeres LUN mit demselben Volumen erstellt werden.<\/p>\n<p><\/p>\n<p>Die Einrichtung des Speichers ist abgeschlossen, jetzt gehen wir zur Erstellung der Replikationsregel \u00fcber.<\/p>\n<p><\/p>\n<h3 id=\"nastroyka-pravil-replikacii-ili-replikacionnyh-svyazey\">Einrichtung von Replikationsregeln oder Replikationsbeziehungen<\/h3>\n<p><\/p>\n<p>Nachdem die LUNs auf dem derzeit prim\u00e4ren Speichersystem (Primary) erstellt wurden, richten wir die Replikationsregel von LUN1 auf LUN1R auf Speichersystem 2 ein.<\/p>\n<p><\/p>\n<p>Die Einrichtung erfolgt im Men\u00fc \u201eRemote-Replikation\u201c<\/p>\n<p><\/p>\n<p>Wir erstellen eine Regel. Dazu m\u00fcssen wir den Empf\u00e4nger der Replikation angeben. Dort geben wir auch den Namen der Beziehung und den Replikationstyp (synchron oder asynchron) an.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/a36bdc437d4a619f47b75d5ba50971ed.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Im Feld \u201eentfernte Systeme\u201c f\u00fcgen wir unser SAN2 hinzu. F\u00fcr die Hinzuf\u00fcgung m\u00fcssen die Verwaltungs-IP des SAN (MGR) und der Name des entfernten LUN verwendet werden, auf dem wir die Replikation durchf\u00fchren werden (in unserem Fall LUN1R). Die Verwaltungs-IP wird nur w\u00e4hrend der Verbindungserstellung ben\u00f6tigt, der Replikationsverkehr wird dar\u00fcber nicht \u00fcbertragen; daf\u00fcr wird die zuvor konfigurierte VIP verwendet. <\/p>\n<p><\/p>\n<p>Bereits auf dieser Stufe k\u00f6nnen wir mehr als ein entferntes System f\u00fcr die \u201eone to many\u201c-Topologie hinzuf\u00fcgen: Klicken Sie auf die Schaltfl\u00e4che \u201eKnoten hinzuf\u00fcgen\u201c, wie im Bild unten gezeigt. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/dbe98818d2c2d34250544db4266337ea.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In unserem Fall gibt es nur ein entferntes System, daher beschr\u00e4nken wir uns darauf.<\/p>\n<p><\/p>\n<p>Die Regel ist bereit. Beachten Sie, dass sie automatisch auf allen Replikationsbeteiligten hinzugef\u00fcgt wird (in unserem Fall sind das zwei). So viele Regeln k\u00f6nnen erstellt werden, wie gew\u00fcnscht, f\u00fcr beliebig viele LUNs und in beide Richtungen. Zum Beispiel k\u00f6nnen wir zur Lastverteilung einige LUNs von SAN1 auf SAN2 replizieren und andere hingegen von SAN2 auf SAN1.<\/p>\n<p><\/p>\n<p>SAN1. Unmittelbar nach der Erstellung begann die Synchronisierung.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/86e1770336d40207ed9b3b6dc4249279.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>SAN2. Wir sehen dieselbe Regel, aber die Synchronisierung ist bereits abgeschlossen.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/f15b69af4de726d5c337d789c37b9cf8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>LUN1 auf SCD1 ist als Prim\u00e4r konfiguriert, das hei\u00dft, er ist aktiv. LUN1R auf SCD2 wird als Sekund\u00e4r bezeichnet, was bedeutet, dass er im Bereitschaftsmodus ist, falls SCD1 ausf\u00e4llt.<br \/>\nJetzt k\u00f6nnen wir unser LUN mit dem Host verbinden.<\/p>\n<p><\/p>\n<p>Wir werden die Verbindung \u00fcber iSCSI herstellen, obwohl auch FC m\u00f6glich ist. Die Konfiguration des Mappings f\u00fcr das iSCSI-LUN in der Replikation unterscheidet sich praktisch nicht von einem gew\u00f6hnlichen Szenario, daher werden wir dies hier nicht im Detail betrachten. Falls erforderlich, wird dieser Prozess im Artikel \u201e<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/tssolution\/blog\/432876\/\">Schnelle Einrichtung<\/a><\/noindex>\u00bb. <\/p>\n<p><\/p>\n<p>Der einzige Unterschied \u2013 das Mapping erfolgt im Men\u00fc \u201eReplikationsmapping\u201c<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/62ceee2f7356a4716bb50b85ea31f0d6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir haben das Mapping konfiguriert und das LUN dem Host zugewiesen. Der Host hat das LUN erkannt.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/0bb675e5fead8d0222b03fa084223f7e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir formatieren es im lokalen Dateisystem.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/09c707bf8037ea381cd7ec88b97c9b62.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Das war's, die Einrichtung ist abgeschlossen. Jetzt folgen die Tests.<\/p>\n<p><\/p>\n<h2 id=\"testirovanie\">Testen<\/h2>\n<p><\/p>\n<p>Wir werden drei Hauptszenarien testen.<\/p>\n<p><\/p>\n<ol>\n<li>Regul\u00e4rer Rollenwechsel von Sekund\u00e4r &gt; Prim\u00e4r. Der regul\u00e4re Rollenwechsel ist notwendig, falls wir im Hauptrechenzentrum pr\u00e4ventive Wartungsarbeiten durchf\u00fchren m\u00fcssen und diese Zeit, um Daten verf\u00fcgbar zu halten, die Last in das Backup-Rechenzentrum \u00fcbertragen wird.<\/li>\n<li>Failover von Secondary zu Primary (Ausfall des Rechenzentrums). Dies ist das Hauptszenario, f\u00fcr das die Replikation existiert, und es hilft, einen vollst\u00e4ndigen Ausfall des Rechenzentrums zu \u00fcberstehen, ohne den Gesch\u00e4ftsbetrieb \u00fcber l\u00e4ngere Zeitr\u00e4ume zu unterbrechen.<\/li>\n<li>Unterbrechungen der Kommunikationskan\u00e4le zwischen den Rechenzentren. \u00dcberpr\u00fcfung des korrekten Verhaltens beider SANs unter Bedingungen, unter denen aus bestimmten Gr\u00fcnden der Kommunikationskanal zwischen den Rechenzentren nicht verf\u00fcgbar ist (z. B. wenn ein Bagger versehentlich das dunkle Glasfaserkabel besch\u00e4digt hat).<\/li>\n<\/ol>\n<p><\/p>\n<p>Zun\u00e4chst beginnen wir, Daten auf unser LUN zu schreiben (wir schreiben Dateien mit zuf\u00e4lligen Daten). Sofort beobachten wir, dass die Verbindung zwischen den SANs ausgelastet ist. Das l\u00e4sst sich leicht erkennen, wenn man die \u00dcberwachung der Portlasten \u00f6ffnet, die f\u00fcr die Replikation verantwortlich sind.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/bba2e0b14669a2c8ccef8a2d3eb336ed.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Auf beiden SANs befinden sich jetzt \u201en\u00fctzliche\u201c Daten, wir k\u00f6nnen mit dem Test beginnen.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/62b0614cee954738e878609feb3a5e08.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Zur Sicherheit schauen wir uns die Hash-Werte einer der Dateien an und notieren sie.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/48e7dde27ef2371e722c72c6dc998c8f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h3 id=\"shtatnoe-pereklyuchenie-roley\">Regul\u00e4rer Rollenwechsel<\/h3>\n<p><\/p>\n<p>Die Rollenwechseloperation (\u00c4nderung der Replikationsrichtung) kann von jedem SAN durchgef\u00fchrt werden, aber es muss dennoch auf beide zugegriffen werden, da das Mapping auf dem Primary deaktiviert und auf dem Secondary (das zum Primary wird) aktiviert werden muss.<\/p>\n<p><\/p>\n<p>Es stellt sich vielleicht die berechtigte Frage: Warum sollte man das nicht automatisieren? Die Antwort ist einfach: Replikation ist ein einfaches Mittel zur Katastrophensicherung, das nur auf manuellen Vorg\u00e4ngen beruht. Um diese Vorg\u00e4nge zu automatisieren, gibt es den Metro-Clustermodus, der vollst\u00e4ndig automatisiert ist, jedoch ist seine Einrichtung deutlich komplizierter. In einem zuk\u00fcnftigen Artikel werden wir \u00fcber die Konfiguration des Metro-Clusters berichten.<\/p>\n<p><\/p>\n<p>Auf dem prim\u00e4ren Speichersystem deaktivieren wir das Mapping, um sicherzustellen, dass keine Aufzeichnungen mehr erfolgen.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/f5afc222a966a1e1dd1d804b06b7963e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dann w\u00e4hlen wir auf einem der Speichersysteme (ob prim\u00e4r oder sekund\u00e4r ist unwichtig) im Men\u00fc \u201eRemote-Replikation\u201c unsere Verbindung REPL1 aus und klicken auf \u201eRolle \u00e4ndern\u201c.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/7346bd30c549d2e263b5c37fbc412f05.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nach ein paar Sekunden wird LUN1R (das sekund\u00e4re Speichersystem) zum Primary.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/d87a7cf770a262c1c3bfb97bb75cf47d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir machen das Mapping von LUN1R mit Speichersystem 2.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/c1b2a04cd8ce34df833f720ba0932ae2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Daraufhin wird automatisch unser Laufwerk E: auf dem Host angebunden, und diesmal ist es \u201eherangekommen\u201c von LUN1R.<\/p>\n<p><\/p>\n<p>Zur Sicherheit vergleichen wir die Hash-Werte.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/b938253769cc660c66d7e42452f8909c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Identisch. Test bestanden.<\/p>\n<p><\/p>\n<h3 id=\"avariynoe-pereklyuchenie-otkaz-cod-a\">Notfallumschaltung. Ausfall des Rechenzentrums.<\/h3>\n<p><\/p>\n<p>Im Moment ist das prim\u00e4re Speichersystem nach der regul\u00e4ren Umschaltung Speichersystem 2 und LUN1R, entsprechend. Um einen Ausfall zu simulieren, schalten wir die Stromversorgung beider Controller von Speichersystem 2 ab.<br \/>\nDer Zugriff darauf ist nicht mehr m\u00f6glich.<\/p>\n<p><\/p>\n<p>Wir beobachten, was mit dem SAN 1 (aktuell im Standby) passiert.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/b38bc0b6004976a92ac0a94babfedddf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir sehen, dass das Primary LUN (LUN1R) nicht verf\u00fcgbar ist. Es gab eine Fehlermeldung in den Protokollen, im Info-Dashboard sowie in der Replikationsregel. Daher sind die Daten vom Host derzeit nicht verf\u00fcgbar.<\/p>\n<p><\/p>\n<p>Wir \u00e4ndern die Rolle von LUN1 auf Primary.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/aebb3adbdc037e559aa9d33350dec36c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir nehmen das Mapping zum Host vor.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/a98e09d40e218552ce0c917e13fac6b6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir stellen sicher, dass die Festplatte E auf dem Host erscheint.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/5a01e43c692227460cd74d155efcd519.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir \u00fcberpr\u00fcfen den Hash.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/63520595bf8bda6e0bec27ed935f3714.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Alles in Ordnung. Der Ausfall des aktiven Rechenzentrums hat das SAN erfolgreich \u00fcberstanden. Die ungef\u00e4hre Zeit, die wir f\u00fcr die Konfiguration der Replikationsumstellung und die Anbindung des LUN aus dem Standby-Rechenzentrum ben\u00f6tigt haben, betrug etwa 3 Minuten. Es ist klar, dass es in einer realen Produktionsumgebung viel komplizierter ist und neben den Ma\u00dfnahmen am SAN noch viele weitere Operationen im Netzwerk, auf den Hosts und in den Anwendungen durchgef\u00fchrt werden m\u00fcssen. In der Realit\u00e4t wird dieser Zeitraum deutlich l\u00e4nger sein.<\/p>\n<p><\/p>\n<p>Hier m\u00f6chte ich schreiben, dass alles gut ist, der Test wurde erfolgreich abgeschlossen, aber wir wollen uns nicht zu fr\u00fch freuen. Das Haupt-SAN ist 'down' und wir wissen, dass es in der Rolle 'Primary' war, als es ausgefallen ist. Was passiert, wenn es pl\u00f6tzlich wieder einschaltet? Es w\u00e4ren zwei Primary-Rollen vorhanden, was zu Datenverlust f\u00fchren w\u00fcrde. Das \u00fcberpr\u00fcfen wir jetzt.<br \/>\nWir gehen jetzt dazu \u00fcber, das ausgefallene SAN wieder zu aktivieren. <\/p>\n<p><\/p>\n<p>Es startet einige Minuten und kehrt dann nach kurzer Synchronisation wieder in Betrieb, allerdings in der Rolle Secondary.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/c332b05c9a2ed31873d1e738009fcb12.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Alles in Ordnung. Es gab keinen Split-Brain. Wir haben daran gedacht, dass nach einem Ausfall des Speichersystems immer in der Rolle Secondary gestartet wird, unabh\u00e4ngig davon, in welcher Rolle es zuvor aktiv war. Nun k\u00f6nnen wir definitiv sagen, dass der Test f\u00fcr den Ausfall des Rechenzentrums erfolgreich war.<\/p>\n<p><\/p>\n<h3 id=\"otkaz-kanalov-svyazi-mezhdu-cod-ami\">Ausfall der Kommunikationskan\u00e4le zwischen den Rechenzentren<\/h3>\n<p><\/p>\n<p>Die Hauptaufgabe dieses Tests besteht darin, sicherzustellen, dass das Speichersystem nichts Ungew\u00f6hnliches macht, wenn es tempor\u00e4r den Kontakt zwischen zwei Speichersystemen verliert, der dann wiederhergestellt wird.<br \/>\nAlso, wir trennen die Kabel zwischen den Speichersystemen (nehmen wir an, ein Bagger hat sie durchtrennt).<\/p>\n<p><\/p>\n<p>Auf dem Primary sehen wir, dass keine Verbindung zum Secondary besteht.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/42646193c62eeaa9f0e4e649e5a3be23.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Auf dem Secondary sehen wir, dass keine Verbindung zum Primary besteht. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/14a28c3930bb6ac83e5bd10976577d18.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Alles funktioniert normal, und wir fahren fort, Daten auf das prim\u00e4re Speichersystem zu schreiben, das hei\u00dft, sie unterscheiden sich jetzt garantiert von der Backup-Version, also sind sie 'auseinandergegangen'.<\/p>\n<p><\/p>\n<p>Nach ein paar Minuten 'reparieren' wir den Kommunikationskanal. Sobald sich die Speichersysteme wieder sehen, wird die Datensynchronisation automatisch aktiviert. Hierf\u00fcr sind keine Eingriffe des Administrators erforderlich.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/386a6e4b86166373a3858543572e3ac9.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nach einiger Zeit ist die Synchronisation abgeschlossen.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Katastrophenschutz. Teil 1\" src=\"\/wp-content\/uploads\/2019\/06\/e879fdebdc78505a74880f275de8f868.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Die Verbindung wurde wiederhergestellt, es gab keine au\u00dfergew\u00f6hnlichen Situationen, die zu einem Ausfall der Kommunikationskan\u00e4le gef\u00fchrt h\u00e4tten, und nach dem Aktivieren fand automatisch eine Synchronisation statt.<\/p>\n<p><\/p>\n<h2 id=\"vyvody\">Fazit<\/h2>\n<p><\/p>\n<p>Wir haben die Theorie durchgenommen \u2013 was und warum es ben\u00f6tigt wird, wo die Vorteile und wo die Nachteile liegen. Danach haben wir die synchronisierte Replikation zwischen zwei Speichersystemen eingerichtet. <\/p>\n<p><\/p>\n<p>Anschlie\u00dfend wurden die Haupttests f\u00fcr den normalen Umschaltvorgang, den Ausfall des Rechenzentrums und den Ausfall der Kommunikationskan\u00e4le durchgef\u00fchrt. In allen F\u00e4llen hat das Speichersystem gut funktioniert. Es gab keinen Datenverlust, die administrativen Operationen wurden auf ein Minimum f\u00fcr manuelle Szenarien reduziert.<\/p>\n<p><\/p>\n<p>Beim n\u00e4chsten Mal werden wir die Situation komplizierter gestalten und zeigen, wie diese gesamte Logik in einem automatisierten Metrocluster im Active-Active-Betrieb funktioniert, das hei\u00dft, wenn beide Speichersysteme aktiv sind und das Verhalten im Falle eines Ausfalls vollst\u00e4ndig automatisiert ist.<\/p>\n<p><\/p>\n<p>Bitte schreiben Sie Kommentare, wir freuen uns \u00fcber konstruktive Kritik und n\u00fctzliche Ratschl\u00e4ge.<\/p>\n<p><\/p>\n<p>Bis zum n\u00e4chsten Mal.<\/p>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/aerodisk\/blog\/456348\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0445\u0430\u0431\u0440\u0430! \u0422\u0435\u043c\u043e\u0439 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u0431\u0443\u0434\u0435\u0442 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u044f \u0441\u0440\u0435\u0434\u0441\u0442\u0432 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u0432 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u0445 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f AERODISK Engine. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u043d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u0432 \u043e\u0434\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043f\u0440\u043e \u043e\u0431\u0430 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0430: \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044e \u0438 \u043c\u0435\u0442\u0440\u043e\u043a\u043b\u0430\u0441\u0442\u0435\u0440, \u043d\u043e, \u043a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e, \u0441\u0442\u0430\u0442\u044c\u044f \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u0430\u0441\u044c \u0441\u043b\u0438\u0448\u043a\u043e\u043c \u0431\u043e\u043b\u044c\u0448\u043e\u0439, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043c\u044b \u0440\u0430\u0437\u0431\u0438\u043b\u0438 \u0441\u0442\u0430\u0442\u044c\u044e \u043d\u0430 \u0434\u0432\u0435 \u0447\u0430\u0441\u0442\u0438. \u041f\u043e\u0439\u0434\u0435\u043c \u043e\u0442 \u043f\u0440\u043e\u0441\u0442\u043e\u0433\u043e \u043a \u0441\u043b\u043e\u0436\u043d\u043e\u043c\u0443. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043c \u0438 \u043f\u0440\u043e\u0442\u0435\u0441\u0442\u0438\u0440\u0443\u0435\u043c \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u043d\u0443\u044e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26548,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35387","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0445\u0430\u0431\u0440\u0430! \u0422\u0435\u043c\u043e\u0439 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u0431\u0443\u0434\u0435\u0442 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u044f \u0441\u0440\u0435\u0434\u0441\u0442\u0432 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u0432 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u0445 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f AERODISK Engine. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u043d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u0432 \u043e\u0434\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043f\u0440\u043e \u043e\u0431\u0430 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0430: \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044e \u0438 \u043c\u0435\u0442\u0440\u043e\u043a\u043b\u0430\u0441\u0442\u0435\u0440, \u043d\u043e, \u043a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e, \u0441\u0442\u0430\u0442\u044c\u044f \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u0430\u0441\u044c \u0441\u043b\u0438\u0448\u043a\u043e\u043c \u0431\u043e\u043b\u044c\u0448\u043e\u0439, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043c\u044b \u0440\u0430\u0437\u0431\u0438\u043b\u0438 \u0441\u0442\u0430\u0442\u044c\u044e \u043d\u0430 \u0434\u0432\u0435 \u0447\u0430\u0441\u0442\u0438. \u041f\u043e\u0439\u0434\u0435\u043c \u043e\u0442 \u043f\u0440\u043e\u0441\u0442\u043e\u0433\u043e \u043a \u0441\u043b\u043e\u0436\u043d\u043e\u043c\u0443. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043c \u0438 \u043f\u0440\u043e\u0442\u0435\u0441\u0442\u0438\u0440\u0443\u0435\u043c \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u043d\u0443\u044e\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-1\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47AERODISK Engine: \u041a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0445\u0430\u0431\u0440\u0430! \u0422\u0435\u043c\u043e\u0439 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u0431\u0443\u0434\u0435\u0442 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u044f \u0441\u0440\u0435\u0434\u0441\u0442\u0432 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u0432 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u0445 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f AERODISK Engine. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u043d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u0432 \u043e\u0434\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043f\u0440\u043e \u043e\u0431\u0430 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0430: \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044e \u0438 \u043c\u0435\u0442\u0440\u043e\u043a\u043b\u0430\u0441\u0442\u0435\u0440, \u043d\u043e, \u043a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e, \u0441\u0442\u0430\u0442\u044c\u044f \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u0430\u0441\u044c \u0441\u043b\u0438\u0448\u043a\u043e\u043c \u0431\u043e\u043b\u044c\u0448\u043e\u0439, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043c\u044b \u0440\u0430\u0437\u0431\u0438\u043b\u0438 \u0441\u0442\u0430\u0442\u044c\u044e \u043d\u0430 \u0434\u0432\u0435 \u0447\u0430\u0441\u0442\u0438. \u041f\u043e\u0439\u0434\u0435\u043c \u043e\u0442 \u043f\u0440\u043e\u0441\u0442\u043e\u0433\u043e \u043a \u0441\u043b\u043e\u0436\u043d\u043e\u043c\u0443. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043c \u0438 \u043f\u0440\u043e\u0442\u0435\u0441\u0442\u0438\u0440\u0443\u0435\u043c \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u043d\u0443\u044e\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-1\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:04:01+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:04:01+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47AERODISK Engine: Hochverf\u00fcgbarkeit. Teil 1 | ProHoster","description":"Hallo, liebe Leser von Habr! In diesem Artikel geht es um die Implementierung von Hochverf\u00fcgbarkeitsl\u00f6sungen im AERODISK Engine Storage-System. Urspr\u00fcnglich wollten wir beide L\u00f6sungen \u2013 Replikation und Metro-Cluster \u2013 in einem Artikel behandeln. Leider wurde der Artikel jedoch zu umfangreich, weshalb wir ihn in zwei Teile aufteilen. Lassen Sie uns mit den Grundlagen beginnen. In diesem Artikel werden wir die synchrone","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47AERODISK Engine: \u041a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0445\u0430\u0431\u0440\u0430! \u0422\u0435\u043c\u043e\u0439 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u0431\u0443\u0434\u0435\u0442 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u044f \u0441\u0440\u0435\u0434\u0441\u0442\u0432 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u0432 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u0445 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f AERODISK Engine. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u043d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u0432 \u043e\u0434\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043f\u0440\u043e \u043e\u0431\u0430 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0430: \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044e \u0438 \u043c\u0435\u0442\u0440\u043e\u043a\u043b\u0430\u0441\u0442\u0435\u0440, \u043d\u043e, \u043a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e, \u0441\u0442\u0430\u0442\u044c\u044f \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u0430\u0441\u044c \u0441\u043b\u0438\u0448\u043a\u043e\u043c \u0431\u043e\u043b\u044c\u0448\u043e\u0439, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043c\u044b \u0440\u0430\u0437\u0431\u0438\u043b\u0438 \u0441\u0442\u0430\u0442\u044c\u044e \u043d\u0430 \u0434\u0432\u0435 \u0447\u0430\u0441\u0442\u0438. \u041f\u043e\u0439\u0434\u0435\u043c \u043e\u0442 \u043f\u0440\u043e\u0441\u0442\u043e\u0433\u043e \u043a \u0441\u043b\u043e\u0436\u043d\u043e\u043c\u0443. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043c \u0438 \u043f\u0440\u043e\u0442\u0435\u0441\u0442\u0438\u0440\u0443\u0435\u043c \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u043d\u0443\u044e","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:04:01+00:00","article:modified_time":"2019-10-31T19:04:01+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35387","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-08 20:27:18","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:04:24","updated":"2026-02-08 20:27:18"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/35387","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=35387"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/35387\/revisions"}],"predecessor-version":[{"id":157820,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/35387\/revisions\/157820"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/26548"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=35387"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=35387"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=35387"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}