Hallo Leser von Habr! In einem früheren Artikel haben wir über ein einfaches Tool zur Katastrophenverträglichkeit in AERODISK ENGINE-Speichersystemen gesprochen - über die Replikation. In diesem Artikel werden wir uns mit einem komplexeren und interessanteren Thema befassen - dem U-Bahn-Cluster, dh einem Mittel zum automatisierten Katastrophenschutz für zwei Rechenzentren, mit dem Rechenzentren im Aktiv-Aktiv-Modus arbeiten können. Wir werden es erzählen, zeigen, brechen und reparieren.
Wie üblich zu Beginn der Theorie
Ein U-Bahn-Cluster ist ein Cluster, der über mehrere Standorte innerhalb einer Stadt oder eines Bezirks verteilt ist. Das Wort "Cluster" weist uns klar darauf hin, dass der Komplex automatisiert ist, dh das Umschalten von Clusterknoten bei Fehlern erfolgt automatisch.
Hier liegt der Hauptunterschied zwischen dem Metro-Cluster und der normalen Replikation. Automatisierung von Operationen. Das heißt, bei bestimmten Vorfällen (Ausfall des Rechenzentrums, defekte Kanäle usw.) führt das Speichersystem unabhängig die erforderlichen Aktionen aus, um die Datenverfügbarkeit aufrechtzuerhalten. Bei Verwendung regulärer Replikate werden diese Aktionen vom Administrator ganz oder teilweise manuell ausgeführt.
Wofür ist das?
Das Hauptziel, das Kunden mit der einen oder anderen Implementierung des Metro-Clusters verfolgen, ist die Minimierung des RTO (Recovery Time Objective). Minimieren Sie also die Wiederherstellungszeit von IT-Services nach einem Ausfall. Wenn Sie die normale Replikation verwenden, ist die Wiederherstellungszeit immer länger als die Wiederherstellungszeit mit dem Metro-Cluster. Warum? Sehr einfach. Der Administrator muss am Arbeitsplatz sein und die Replikation von Hand wechseln. Der Metro-Cluster führt dies automatisch durch.
Wenn Sie keinen dedizierten Administrator im Dienst haben, der nicht schläft, isst, raucht oder krank wird und 24 Stunden am Tag den Speicherstatus überprüft, kann nicht garantiert werden, dass der Administrator während eines Fehlers für manuelles Umschalten verfügbar ist.
Dementsprechend RTO in Abwesenheit eines U-Bahn-Clusters oder unsterbliche Administratorstufe 99 Der Dienst des Administrators im Dienst entspricht der Summe der Umschaltzeit aller Systeme und der maximalen Zeitspanne, nach der der Administrator garantiert mit Speichersystemen und verwandten Systemen arbeitet.
Wir kommen daher zu dem offensichtlichen Schluss, dass der Metro-Cluster verwendet werden sollte, wenn die RTO-Anforderung Minuten und nicht Stunden oder Tage beträgt, dh wenn im schlimmsten Fall ein Ausfall des Rechenzentrums erforderlich ist, muss die IT-Abteilung dem Unternehmen Zeit geben, um den Zugriff auf die IT wiederherzustellen -Dienstleistungen innerhalb von Minuten oder sogar Sekunden.
Wie funktioniert es
Auf der unteren Ebene verwendet der Metro-Cluster den Mechanismus der synchronen Datenreplikation, den wir in einem früheren Artikel beschrieben haben (siehe Link ). Da die Replikation synchron ist, sind die Anforderungen dafür angemessen, oder besser:
- Glasfaser als Physik, 10 Gigabit Ethernet (oder höher);
- Die Entfernung zwischen den Rechenzentren beträgt nicht mehr als 40 Kilometer.
- Optische Kanalverzögerung zwischen Rechenzentren (zwischen Speichersystemen) bis zu 5 Millisekunden (optimal 2).
Alle diese Anforderungen sind beratender Natur, dh der Metro-Cluster funktioniert auch dann, wenn diese Anforderungen nicht erfüllt werden. Es muss jedoch verstanden werden, dass die Folgen der Nichteinhaltung dieser Anforderungen gleich der Verlangsamung beider Speichersysteme im Metro-Cluster sind.
Ein synchrones Replikat wird also verwendet, um Daten zwischen Speichersystemen zu übertragen, und wie Replikate automatisch umgeschaltet werden und vor allem, wie Split-Brain vermieden werden kann. Hierzu wird auf der obigen Ebene eine zusätzliche Entität verwendet - der Arbiter.
Wie arbeitet der Schiedsrichter und was ist seine Aufgabe?
Der Arbiter ist eine kleine virtuelle Maschine oder ein Hardware-Cluster, der auf der dritten Plattform (z. B. im Büro) ausgeführt werden muss und über ICMP und SSH Zugriff auf den Speicher bietet. Nach dem Start sollte der Arbiter die IP festlegen und dann auf der Speicherseite seine Adresse sowie die Adressen der Fernbedienungen angeben, die am Metro-Cluster teilnehmen. Danach ist der Schiedsrichter bereit zu arbeiten.
Der Arbiter überwacht ständig alle Speichersysteme im Metro-Cluster. Wenn ein Speichersystem nicht verfügbar ist, entscheidet er, nachdem er bestätigt hat, dass es von einem anderen Clustermitglied (einem der "Live" -Speichersysteme) nicht verfügbar ist, mit dem Verfahren zum Wechseln der Replikationsregeln und der Zuordnung.
Ein sehr wichtiger Punkt. Der Arbiter muss sich immer an einem anderen Standort befinden als dem, an dem sich der Speicher befindet, dh weder im Rechenzentrum 1, in dem sich der Speicher 1 befindet, noch im Rechenzentrum 2, in dem der Speicher 2 installiert ist.
Warum? Denn nur so kann ein Schiedsrichter mit Hilfe eines der überlebenden Speichersysteme den Sturz eines der beiden Standorte, an denen die Speichersysteme installiert sind, eindeutig und genau bestimmen. Alle anderen Möglichkeiten, einen Schiedsrichter zu platzieren, können zu einem gespaltenen Gehirn führen.
Tauchen Sie nun in die Details des Schiedsrichters ein
Der Arbiter führt mehrere Dienste aus, die ständig von allen Speichercontrollern abgefragt werden. Wenn sich das Ergebnis der Umfrage vom vorherigen unterscheidet (verfügbar / nicht zugänglich), wird es in einer kleinen Datenbank aufgezeichnet, die auch als Schiedsrichter fungiert.
Betrachten Sie die Logik des Schiedsrichters genauer.
Schritt 1. Feststellung der Unzugänglichkeit. Ein Ereignissignal über den Ausfall des Speichersystems ist das Fehlen eines Pings von beiden Controllern desselben Speichersystems für 5 Sekunden.
Schritt 2. Starten Sie den Schaltvorgang. Nachdem der Schiedsrichter verstanden hat, dass eines der Speichersysteme nicht verfügbar ist, sendet er eine Anfrage an das "lebende" Speichersystem, um sicherzustellen, dass das "tote" Speichersystem wirklich gestorben ist.
Nach Erhalt eines solchen Befehls vom Schiedsrichter prüft das zweite (Live-) Speichersystem zusätzlich die Verfügbarkeit des heruntergefallenen ersten Speichersystems und sendet, falls dies nicht der Fall ist, dem Schiedsrichter eine Bestätigung seiner Vermutungen. Speicher ist wirklich nicht verfügbar.
Nach Erhalt einer solchen Bestätigung startet der Arbiter die Remote-Prozedur zum Umschalten der Replikation und zum Erhöhen der Zuordnung für die Replikate, die auf dem gelöschten Speichersystem aktiv (primär) waren, und sendet einen Befehl an das zweite Speichersystem, um diese Replikate von sekundär zu primär zu erstellen und die Zuordnung zu erhöhen. Nun, das zweite Speichersystem führt diese Prozeduren aus, wonach es von sich aus Zugriff auf die verlorenen LUNs gewährt.
Warum benötige ich eine zusätzliche Überprüfung? Für das Quorum. Das heißt, der größte Teil der ungeraden (3) Gesamtzahl der Clustermitglieder sollte den Fall eines der Clusterknoten bestätigen. Nur dann ist diese Entscheidung genau richtig. Dies ist notwendig, um ein fehlerhaftes Schalten und dementsprechend ein Split-Brain zu vermeiden.
Schritt 2 dauert ungefähr 5 bis 10 Sekunden. Unter Berücksichtigung der Zeit, die erforderlich ist, um die Unzugänglichkeit festzustellen (5 Sekunden), stehen LUNs mit gelöschtem Speicher innerhalb von 10 bis 15 Sekunden nach dem Unfall automatisch für die Arbeit mit Live-Speicher zur Verfügung.
Es ist klar, dass Sie, um ein Trennen der Hosts zu vermeiden, auch auf die korrekte Einstellung der Zeitüberschreitungen auf den Hosts achten müssen. Das empfohlene Zeitlimit beträgt mindestens 30 Sekunden. Dadurch kann der Host während eines Lastübergangs während eines Lastübergangs nicht vom Speichersystem getrennt werden, und es kann garantiert werden, dass die Eingabe / Ausgabe nicht unterbrochen wird.
Nur eine Sekunde, es stellt sich heraus, wenn mit dem Metro-Cluster alles in Ordnung ist, warum benötigen Sie eine regelmäßige Replikation?
In der Tat ist nicht alles so einfach.
Berücksichtigen Sie die Vor- und Nachteile des U-Bahn-Clusters
Wir haben also festgestellt, dass die offensichtlichen Vorteile des Metro-Clusters gegenüber der herkömmlichen Replikation folgende sind:
- Vollständige Automatisierung mit minimaler Wiederherstellungszeit im Katastrophenfall;
- Und alle :-).
Und jetzt Aufmerksamkeit, Nachteile:
- Die Kosten der Entscheidung. Obwohl für den Metro-Cluster in Aerodisk-Systemen keine zusätzliche Lizenz erforderlich ist (es wird dieselbe Lizenz wie für das Replikat verwendet), sind die Kosten der Lösung immer noch höher als bei Verwendung der synchronen Replikation. Es müssen alle Anforderungen für das synchrone Replikat sowie die Anforderungen für den Metro-Cluster in Bezug auf zusätzliches Switching und zusätzlichen Standort implementiert werden (siehe Planung des Metro-Clusters).
- Die Komplexität der Entscheidung. Der Metro-Cluster ist viel komplexer als ein reguläres Replikat und erfordert viel mehr Aufmerksamkeit und Arbeit für Planung, Konfiguration und Dokumentation.
Zusammenfassend. Metro Cluster ist natürlich eine sehr technologische und gute Lösung, wenn Sie RTO wirklich in Sekunden oder Minuten bereitstellen müssen. Aber wenn es keine solche Aufgabe gibt und RTO in Stunden für das Geschäft in Ordnung ist, macht es keinen Sinn, Spatzen aus der Kanone zu schießen. Die übliche Replikation von Arbeitern ist ausreichend, da dem U-Bahn-Cluster zusätzliche Kosten entstehen und die IT-Infrastruktur kompliziert wird.
Metro Cluster Planung
Dieser Abschnitt erhebt keinen Anspruch auf eine umfassende Anleitung für den Entwurf des U-Bahn-Clusters, sondern zeigt nur die Hauptrichtungen auf, die ausgearbeitet werden sollten, wenn Sie sich für den Aufbau eines solchen Systems entscheiden. Stellen Sie daher bei der tatsächlichen Implementierung des U-Bahn-Clusters sicher, dass Sie den Hersteller von Speichersystemen (dh uns) und andere verwandte Systeme für Konsultationen einbeziehen.
Plattformen
Wie oben angegeben, sind für einen U-Bahn-Cluster mindestens drei Standorte erforderlich. Zwei Rechenzentren, in denen Speichersysteme und verwandte Systeme funktionieren, sowie eine dritte Plattform, auf der der Schiedsrichter arbeiten wird.
Die empfohlene Entfernung zwischen den Rechenzentren beträgt nicht mehr als 40 Kilometer. Größere Entfernungen verursachen höchstwahrscheinlich zusätzliche Verzögerungen, die im Fall eines U-Bahn-Clusters höchst unerwünscht sind. Es sei daran erinnert, dass Verzögerungen bis zu 5 Millisekunden betragen sollten, obwohl es wünschenswert ist, 2 zu erfüllen.
Es wird auch empfohlen, Verzögerungen während des Planungsprozesses zu überprüfen. Jeder mehr oder weniger erwachsene Anbieter, der Glasfaser zwischen den Rechenzentren bereitstellt, kann eine Qualitätsprüfung ziemlich schnell organisieren.
Für Verzögerungen vor dem Arbiter (dh zwischen der dritten Plattform und den ersten beiden) beträgt der empfohlene Verzögerungsschwellenwert bis zu 200 Millisekunden, dh eine reguläre Unternehmens-VPN-Verbindung über das Internet ist geeignet.
Switching und Networking
Im Gegensatz zu einem Replikationsschema, bei dem es ausreicht, Speichersysteme von verschiedenen Standorten aus miteinander zu verbinden, erfordert ein Schema mit einem Metro-Cluster die Verbindung von Hosts mit beiden Speichersystemen an verschiedenen Standorten. Um den Unterschied klarer zu machen, sind beide Schemata unten aufgeführt.
Wie Sie dem Diagramm entnehmen können, betrachten die Hosts auf Site 1 sowohl SHD1 als auch SHD 2. Im Gegenteil, die Hosts von Plattform 2 betrachten SHD 2 und SHD1. Das heißt, jeder Host sieht beide Speichersysteme. Dies ist eine Voraussetzung für den Betrieb des Metro-Clusters.
Natürlich muss nicht jeder Host mit einem optischen Kabel in ein anderes Rechenzentrum gezogen werden, es reichen keine Anschlüsse und Schnürsenkel aus. Alle diese Verbindungen müssen über Ethernet 10G + - oder FibreChannel 8G + -Switches hergestellt werden (FC nur zum Verbinden von Hosts und Speicher für E / A, der Replikationskanal ist derzeit nur über IP verfügbar (Ethernet 10G +).
Nun ein paar Worte zur Netzwerktopologie. Ein wichtiger Punkt ist die korrekte Konfiguration der Subnetze. Sie müssen sofort mehrere Subnetze für die folgenden Verkehrstypen identifizieren:
- Das Subnetz für die Replikation, über das Daten zwischen den Speichersystemen synchronisiert werden. Es kann mehrere geben, in diesem Fall spielt es keine Rolle, alles hängt von der aktuellen (bereits implementierten) Netzwerktopologie ab. Wenn es zwei davon gibt, sollte natürlich das Routing zwischen ihnen konfiguriert werden.
- Speichersubnetze, über die Hosts auf Speicherressourcen zugreifen (sofern es sich um iSCSI handelt). In jedem Rechenzentrum sollte ein solches Subnetz vorhanden sein.
- Steuern Sie Subnetze, dh drei routingfähige Subnetze an drei Standorten, von denen aus die Speicherverwaltung durchgeführt wird, und es gibt auch einen Arbiter.
Subnetze für den Zugriff auf Hostressourcen werden hier nicht berücksichtigt, da sie stark aufgabenabhängig sind.
Das Aufteilen von unterschiedlichem Datenverkehr in verschiedene Subnetze ist äußerst wichtig (es ist besonders wichtig, das Replikat von E / A zu trennen). Wenn Sie den gesamten Datenverkehr in ein „dickes“ Subnetz mischen, kann dieser Datenverkehr nicht verwaltet werden und kann unter den Bedingungen von zwei Rechenzentren immer noch unterschiedliche Daten verursachen Optionen für Netzwerkkollisionen. Wir werden im Rahmen dieses Artikels nicht viel auf dieses Problem eingehen, da Sie über die Planung eines Netzwerks zwischen Rechenzentren auf den Ressourcen der Hersteller von Netzwerkgeräten lesen können, wo es ausführlich beschrieben wird.
Schiedsrichter-Konfiguration
Der Arbiter muss über die ICMP- und SSH-Protokolle Zugriff auf alle Speicherverwaltungsschnittstellen gewähren. Sie sollten auch die Fehlertoleranz des Arbiters berücksichtigen. Es gibt eine Nuance.
Die Fehlertoleranz des Arbiters ist sehr wünschenswert, aber optional. Und was passiert, wenn der Schiedsrichter zur falschen Zeit abstürzt?
- Der Betrieb des U-Bahn-Clusters im Normalmodus ändert sich nicht, weil arbtir hat keinerlei Auswirkungen auf den Betrieb des U-Bahn-Clusters im normalen Modus (seine Aufgabe besteht darin, die Last zwischen den Rechenzentren rechtzeitig umzuschalten).
- Wenn der Schiedsrichter aus dem einen oder anderen Grund fällt und den Unfall im Rechenzentrum "aufweckt", erfolgt keine Umschaltung, da niemand die erforderlichen Befehle zum Umschalten und Organisieren eines Quorums erteilt. In diesem Fall wird der U-Bahn-Cluster zu einem regulären Replikationsschema, das während einer Katastrophe von Hand umgeschaltet werden muss, was sich auf RTO auswirkt.
Was folgt daraus? Wenn Sie wirklich eine minimale RTO sicherstellen müssen, müssen Sie die Fehlertoleranz des Arbiters sicherstellen. Hierfür gibt es zwei Möglichkeiten:
- Führen Sie eine virtuelle Maschine mit einem Arbiter auf einem Failover-Hypervisor aus, da alle erwachsenen Hypervisoren ein Failover unterstützen.
- Wenn am dritten Standort (in einem bedingten Büro)
Faulheit, einen normalen Cluster zu setzen Da es keinen vorhandenen Hypervizor-Cluster gibt, haben wir eine Hardwareversion des Arbiters bereitgestellt, die in einer 2U-Box hergestellt wird, in der zwei normale x-86-Server funktionieren und die einen lokalen Fehler überleben können.
Wir empfehlen dringend, dass der Schiedsrichter fehlertolerant ist, obwohl der Metro-Cluster ihn im normalen Modus nicht benötigt. Sowohl Theorie als auch Praxis zeigen jedoch, dass es besser ist, auf Nummer sicher zu gehen, wenn Sie eine wirklich zuverlässige, katastrophensichere Infrastruktur aufbauen. Es ist besser, sich und Ihr Unternehmen vor dem "Gesetz der Gemeinheit" zu schützen, dh vor dem Ausfall sowohl des Schiedsrichters als auch eines der Standorte, an denen sich das Speichersystem befindet.
Lösungsarchitektur
Unter Berücksichtigung der oben genannten Anforderungen erhalten wir die folgende allgemeine Lösungsarchitektur.
LUNs sollten gleichmäßig auf zwei Standorte verteilt sein, um starke Überlastungen zu vermeiden. Gleichzeitig muss bei der Dimensionierung in beiden Rechenzentren nicht nur ein doppeltes Volume (das zum gleichzeitigen Speichern von Daten auf zwei Speichersystemen erforderlich ist), sondern auch eine doppelte Leistung in IOPS und MB / s festgelegt werden, um eine Verschlechterung der Anwendungen bei Ausfall eines der Rechenzentren zu verhindern. ov.
Unabhängig davon stellen wir fest, dass bei einem ordnungsgemäßen Ansatz zur Größenbestimmung (dh vorausgesetzt, wir haben die richtigen Obergrenzen für IOPS und MB / s sowie die erforderlichen CPU- und RAM-Ressourcen angegeben) bei einem Ausfall eines der Speichersysteme im U-Bahn-Cluster kein schwerwiegender Leistungsabfall auftritt temporäre Arbeit an einem Speichersystem.
Dies liegt an der Tatsache, dass unter den Bedingungen von zwei Standorten gleichzeitig die synchrone Replikation die Hälfte der Schreibleistung „verschlingt“, da jede Transaktion auf zwei Speichersysteme geschrieben werden muss (ähnlich wie bei RAID-1/10). Wenn also eines der Speichersysteme ausfällt, verschwindet der Effekt der vorübergehenden Replikation (bis das ausgefallene Speichersystem steigt) und die Schreibleistung wird um das Doppelte erhöht. Nachdem die LUNs eines ausgefallenen Speichersystems auf einem funktionierenden Speichersystem neu gestartet wurden, verschwindet diese zweifache Erhöhung aufgrund der Belastung durch die LUNs eines anderen Speichersystems und wir kehren zu dem Leistungsniveau zurück, das wir vor dem „Löschen“ hatten. aber nur im Rahmen einer Plattform.
Mit Hilfe einer kompetenten Dimensionierung können Bedingungen bereitgestellt werden, unter denen Benutzer den Ausfall eines gesamten Speichersystems überhaupt nicht spüren. Aber auch dies erfordert eine sehr sorgfältige Dimensionierung, für die Sie uns übrigens kostenlos kontaktieren können :-).
Metro Cluster Setup
Das Einrichten eines Metro-Clusters ähnelt dem Einrichten einer regulären Replikation, die wir in einem vorherigen Artikel beschrieben haben . Daher konzentrieren wir uns nur auf die Unterschiede. Wir haben einen Stand basierend auf der oben beschriebenen Architektur im Labor nur in der Minimalversion eingerichtet: zwei über 10G-Ethernet miteinander verbundene Speichersysteme, zwei 10G-Switches und ein Host, der die 10 Speicherports über die Switches auf beiden Speichersystemen betrachtet. Der Arbiter wird in einer virtuellen Maschine ausgeführt.
Wählen Sie beim Einrichten von virtuellen IPs (VIPs) für ein Replikat den VIP-Typ für den Metro-Cluster aus.
Wir haben zwei Replikationsverbindungen für zwei LUNs erstellt und diese auf zwei Speichersysteme verteilt: LUN TEST Primary für SHD1 (METRO-Verbindung), LUN TEST2 Primary für SHD2 (METRO2-Verbindung).
Für sie haben wir zwei identische Ziele eingerichtet (in unserem Fall iSCSI, aber FC wird auch unterstützt, die Logik der Einstellung ist dieselbe).
SHD1:
SHD2:
Für Replikationsverbindungen haben sie Zuordnungen auf jedem Speichersystem vorgenommen.
SHD1:
SHD2:
Multipath konfiguriert und dem Host präsentiert.
Konfigurieren Sie den Arbiter
Sie müssen mit dem Schiedsrichter selbst nichts Besonderes tun, sondern ihn nur auf der dritten Plattform aktivieren, ihm eine IP-Adresse festlegen und den Zugriff über ICMP und SSH konfigurieren. Die Konfiguration selbst erfolgt über die Speichersysteme selbst. In diesem Fall reicht es aus, den Arbiter einmal auf einem der Speichercontroller im Metro-Cluster zu konfigurieren. Diese Einstellungen werden automatisch an alle Controller verteilt.
Im Abschnitt Remote-Replikation >> Metrocluster (auf einem beliebigen Controller) >> Schaltfläche Konfigurieren.
Wir stellen die IP des Arbiters sowie die Steuerschnittstellen der beiden Controller des Remote-Speichersystems vor.
Danach müssen Sie alle Dienste aktivieren (die Schaltfläche "Alles neu starten"). Im Falle einer zukünftigen Neukonfiguration müssen die Dienste neu gestartet werden, damit die Einstellungen wirksam werden.
Überprüfen Sie, ob alle Dienste ausgeführt werden.
Damit ist die Einrichtung des U-Bahn-Clusters abgeschlossen.
Crashtest
Der Crashtest ist in unserem Fall recht einfach und schnell, da die Replikationsfunktionalität (Switching, Konsistenz usw.) in einem früheren Artikel berücksichtigt wurde. Um die Zuverlässigkeit eines U-Bahn-Clusters zu testen, reicht es daher aus, die Automatisierung der Unfallerkennung, des Umschaltens und das Fehlen von Aufzeichnungsverlusten (E / A-Stopps) zu überprüfen.
Zu diesem Zweck emulieren wir den vollständigen Ausfall eines der Speichersysteme, indem wir beide Controller physisch herunterfahren und eine große Datei vorläufig in die LUN kopieren, die auf dem anderen Speichersystem aktiviert werden muss.
Deaktivieren Sie einen Speicher. Auf dem zweiten Speichersystem werden in den Protokollen Warnungen und Meldungen angezeigt, dass die Verbindung zum benachbarten System unterbrochen wurde. Wenn Sie Warnungen für die SMTP- oder SNMP-Überwachung konfiguriert haben, erhält der Administrator die entsprechenden Warnungen.
Genau 10 Sekunden später (in beiden Screenshots zu sehen) wurde der METRO-Replikationslink (derjenige, der auf dem abgestürzten Speichersystem primär war) automatisch auf dem laufenden Speichersystem primär. Unter Verwendung der vorhandenen Zuordnung blieb LUN TEST für den Host verfügbar, die Aufzeichnung sackte etwas ab (innerhalb der versprochenen 10 Prozent), brach jedoch nicht ab.
Test erfolgreich abgeschlossen.
Zusammenfassend
Die derzeitige Implementierung des Metroclusters in den Speichersystemen der AERODISK Engine N-Serie ermöglicht die vollständige Lösung von Problemen, bei denen Ausfallzeiten von IT-Services vermieden oder minimiert werden müssen und deren Betrieb rund um die Uhr und 365 Tage die Woche mit minimalem Arbeitsaufwand sichergestellt werden muss.
, , , … , , . , , , .
, .