2.3. Planung der Knoten-Hardware-Konfigurationen

Acronis Cyber Infrastructure arbeitet auf der Basis von handelsüblicher Hardware, sodass Sie einen Cluster aus herkömmlichen Servern, Festplatten und Netzwerkkarten erstellen können. Um eine optimale Performance zu erreichen, müssen jedoch eine Reihe von Anforderungen erfüllt sein und eine Reihe von Empfehlungen befolgt werden.

Bemerkung

Wenden Sie sich an Ihren Vertriebsmitarbeiter, wenn Sie sich nicht sicher sind, welche Hardware Sie wählen sollen. Sie können außerdem den Online-Hardware-Calculator verwenden. Wenn Sie sich den Aufwand mit dem Testen, Installieren und Konfigurieren der Hardware und/oder Software ersparen wollen, sollten Sie die Verwendung der Acronis Appliance erwägen. Diese ist eine direkt einsatzbereite, fehlertolerante Fünf-Knoten-Infrastrukturlösung mit hervorragender Storage-Performance, die in einem 3U-Formfaktor läuft (Server-Gehäuse mit drei Höheneinheiten (3U/3HE)).

2.3.1. Hardware-Limits

Die folgende Tabelle listet die aktuellen Hardware-Limits für die Acronis Cyber Infrastructure Server auf:

Tab. 2.3.1.1 Server-Hardware-Limits
Hardware Theoretisch Zertifiziert
RAM 64 TB 1 TB
CPU 5120 logische CPUs 384 logische CPUs

Eine logische CPU ist ein Kern (Thread) in einem Multicore-(Multithreading)-Prozessor.

2.3.2. Hardware-Anforderungen

Die untere Tabelle führt die minimalen und empfohlenen Laufwerksanforderungen in Bezug auf die jeweiligen Laufwerksrollen auf (zu weiteren Informationen siehe: Überblick über die Storage-Architektur):

Tab. 2.3.2.1 Laufwerksanforderungen
Laufwerksrolle Anzahl Minimum Empfohlen
System Ein Laufwerk pro Knoten 100 GB SATA-/SAS-HDD 250 GB SATA-/SAS-SSD
Metadaten

Ein Laufwerk pro Knoten

Fünf Laufwerke für einen Cluster empfohlen

 100 GB Enterprise-SSDs mit Stromausfallschutz, Mindestbelastbarkeit 1 DWPD (Drive Writes Per Day)
Cache

Optional

Eine SSD pro 4-12 HDDs

 100+ GB Enterprise-SSDs mit Stromausfallschutz und 75 MB/s sequentieller Schreibleistung pro betreuter HDD; Mindestbelastbarkeit 1 DWPD (Drive Writes Per Day), 10 DWPD empfohlen
Storage

Optional

Mindestens eine pro Cluster

Mindestens 100 GB, maximal 16 TB empfohlen

SATA-/SAS-HDD oder SATA-/SAS-/NVMe-SSD (Enterprise-Klasse und mit Stromausfallschutz, Mindestbelastbarkeit 1 DWPD

Die folgende Tabelle listet die empfohlene Menge an Speicher (RAM) und CPU-Kernen für einen Knoten auf – und in Bezug zu den Services, die Sie verwenden wollen:

Tab. 2.3.2.2 CPU- und RAM-Anforderungen
Service RAM CPU-Kerne*
System 6 GB 2 Kerne
Storage-Services: jedes Laufwerk mit Storage- oder Cache-Rolle (beliebige Größe)** 1 GB 0,2 Kerne
Compute 8 GB 3 Kerne
Load Balancer Service 1 GB 1 Kern
Jeder Load Balancer 1 GB 1 Kern
Kubernetes 2 GB 2 Kerne
S3 4,5 GB 3 Kerne
Backup Gateway*** 1 GB 2 Kerne
NFS Service 4 GB 2 Kerne
Jede Freigabe 0,5 GB 0,5 Kerne
iSCSI Service 1 GB 1 Kern
Jedes Volume 0,1 GB 0,5 Kerne

* 64-Bit-x86-Prozessoren mit aktivierten AMD V- oder Intel VT-Hardware-Virtualisierungserweiterungen. Für Intel-Prozessoren müssen die Funktionen ‚Unrestricted Guest‘ sowie ‚VT-x with Extended Page Tables‘ im BIOS aktiviert sein. Es wird empfohlen, auf jedem Knoten die gleichen CPU-Modelle zu verwenden, um Probleme bei der Live-Migration von VMs zu vermeiden. Ein CPU-Kern ist hier ein physischer Kern in einem Multicore-Prozessor (Hyperthreading wird nicht berücksichtigt).

** Bei Clustern, die mehr als 1 PB physischen Speicherplatz haben, sollten Sie zusätzlich 0,5 GB RAM pro Metadaten-Service hinzufügen.

*** Beim Arbeiten mit Public Clouds und NFS verbraucht das Backup Gateway genauso viel RAM und CPU wie mit einem lokalen Storage.

Was die Netzwerke angeht: es werden mindestens zwei 10-GbE-Netzwerkadapter empfohlen (25-GbE-, 40-GbE- oder 100-GbE-Adapter sind noch besser). Netzwerkbündelungen (Bonding) wird empfohlen. Sie können zwar mit 1-GbE-Verbindungen beginnen, aber bei modernen Lasten kann dies den Cluster-Durchsatz begrenzen.

Betrachten wir einige Beispiele und berechnen die Anforderungen für bestimmte Anwendungsfälle.

  • Wenn Sie 1 Knoten (1 Systemlaufwerk und 4 Storage-Laufwerke) haben und diesen für ein Backup Gateway verwenden wollen, sollte der Knoten folgende Anforderungen erfüllen: die Systemanforderungen (6 GB, 2 Kerne) + Storage-Services für 4 Laufwerke (4 GB, 0,8 Kerne) + Backup Gateway (1 GB, 2 Kerne). Das ergibt insgesamt 11 GB RAM und 5 Kerne für den Knoten.
  • Wenn Sie 3 Knoten (1 Systemlaufwerk und 4 Storage-Laufwerke) haben und diese für den Compute-Service verwenden wollen, sollte jeder Cluster-Knoten folgende Anforderungen erfüllen: die Systemanforderungen (6 GB, 2 Kerne) + Compute-Service (8 GB, 3 Kerne). Das ergibt insgesamt 14 GB RAM und 5 Kerne für jeden Knoten. Wenn Sie z.B. eine Kubernetes-VM und einen Load Balancer aktivieren wollen, müssen Sie dem Management-Knoten folgende Anforderungen hinzufügen: Load Balancer (2 GB, 2 Kerne) + Kubernetes (2 GB, 2 Kerne). Das ergibt insgesamt 18 GB RAM und 9 Kerne für den Management-Knoten.
  • Wenn Sie 5 Knoten (2 Systemlaufwerke und 10 Storage-Laufwerke) haben und diese für ein Backup Gateway verwenden wollen, sollte jeder Cluster-Knoten folgende Anforderungen erfüllen: die Systemanforderungen (6 GB, 2 Kerne) + Storage-Services für 10 Laufwerke (10 GB, 2 Kerne) + Backup Gateway (1 GB, 2 Kerne). Das ergibt insgesamt 17 GB RAM und 6 Kerne für jeden Knoten.

Grundsätzlich gilt: je mehr Ressourcen Sie für Ihren Cluster bereitstellen, desto besser wird dieser funktionieren. Jeder zusätzliche Arbeitsspeicher (RAM) wird als Cache für Lesevorgänge auf den Laufwerken verwendet. Und zusätzliche CPU-Kerne erhöhen die Performance und verringern die Latenzzeit.

2.3.3. Hardware-Empfehlungen

Im Allgemeinen funktioniert Acronis Cyber Infrastructure mit der gleichen Hardware, die auch für Red Hat Enterprise Linux 7 empfohlen wird (inkl. AMD EPYC-Prozessoren): Server, Komponenten.

Die folgenden Empfehlungen erläutern die Vorteile, die eine bestimmte Hardware in der Hardware-Anforderungen-Tabelle bietet. Sie können diese verwenden, um Ihren Cluster optimal zu konfigurieren.

2.3.3.1. Empfehlungen zur Zusammenstellung des Storage-Clusters

Einen effizienten Storage-Cluster zu entwerfen bedeutet, einen Kompromiss zwischen Performance und Kosten zu finden, der Ihren Erfordernissen entspricht. Beachten Sie bei der Planung, dass ein Cluster mit vielen Knoten und wenigen Laufwerken pro Knoten eine höhere Performance bietet – während ein Cluster mit der minimalen Anzahl von Knoten (nämlich 3) und vielen Laufwerken pro Knoten günstiger ist. Siehe die folgende Tabelle für mehr Details.

Tab. 2.3.3.1.1 Empfehlungen zur Zusammenstellung des Clusters
Überlegungen zur Gestaltung Minimale Knoten-Anzahl (3), viele Laufwerke pro Knoten Viele Knoten, wenige Laufwerke pro Knoten (All-Flash-Konfiguration)
Optimierung Geringere Kosten. Höhere Performance.
Zu reservierender freier Speicherplatz Mehr reservierter Speicherplatz für einen Cluster-Neuaufbau, da weniger intakte Knoten die Daten von einem ausgefallenen Knoten speichern müssen. Weniger reservierter Speicherplatz für einen Cluster-Neuaufbau, da mehr intakte Knoten die Daten von einem ausgefallenen Knoten speichern müssen.
Redundanz Weniger Lösch-Codierung-Wahlmöglichkeiten. Mehr Lösch-Codierung-Wahlmöglichkeiten.
Cluster-Balance und Performance-Neuaufbau Schlechtere Balance und langsamerer Neuaufbau. Bessere Balance und schnellerer Neuaufbau.
Netzwerkkapazität Mehr Netzwerkbandbreite erforderlich, um die Cluster-Performance beim Neuaufbau aufrechtzuerhalten. Weniger Netzwerkbandbreite erforderlich, um die Cluster-Performance beim Neuaufbau aufrechtzuerhalten.
Günstiger Datentyp Cold Data (selten verwendet, z.B. Backups) Hot Data (häufig verwendet, z.B. virtuelle Umgebungen)
Beispiel-Server-Konfiguration Supermicro SSG-6047R-E1R36L (Intel Xeon E5-2620 v1/v2 CPU, 32 GB RAM, 36 x 12 TB HDDs, ein 500 GB Systemlaufwerk). Supermicro SYS-2028TP-HC0R-SIOM (4 x Intel E5-2620 v4 CPUs, 4 x 16 GB RAM, 24 x 1,9 TB Samsung PM1643 SSDs).

Beachten Sie bitte Folgendes:

  1. Diese Überlegungen gelten nur, wenn die Fehlerdomäne ein Host ist.
  2. Die Geschwindigkeit des Neuaufbaus im Replikationsmodus hängt nicht von der Anzahl der Knoten im Cluster ab.
  3. Acronis Cyber Infrastructure unterstützt hunderte Laufwerke pro Knoten. Wenn Sie planen, mehr als 36 Laufwerke pro Knoten zu verwenden, kontaktieren Sie unsere Vertriebsingenieure, die Ihnen helfen werden, einen effizienteren Cluster zu entwerfen.

2.3.3.2. Allgemeine Hardware-Empfehlungen

  • Für eine Produktionsumgebung sind mindestens fünf Knoten erforderlich. Dadurch soll sichergestellt werden, dass der Cluster den Ausfall von zwei Knoten ohne Datenverlust überstehen kann.
  • Eines der stärksten Leistungsmerkmale von Acronis Cyber Infrastructure ist dessen Skalierbarkeit. Je größer der Cluster, desto besser arbeitet Acronis Cyber Infrastructure. Es wird empfohlen, Produktionscluster aus mindestens zehn Knoten zu erstellen, um die Resilienz, Performance und Fehlertoleranz in Produktionsszenarien zu verbessern.
  • Auch wenn ein Cluster mit unterschiedlicher Hardware erstellt werden kann, führt die Verwendung von Knoten mit ähnlicher Hardware in jedem Knoten zu einer besseren Performance, Kapazität und Gesamtbalance.
  • Jede Cluster-Infrastruktur muss umfangreich getestet werden, bevor diese für den Produktionseinsatz bereitgestellt wird. Gängige Fehlerquellen wie SSD-Laufwerke und Netzwerkadapter-Bündelungen müssen immer gründlich geprüft werden.
  • Es wird nicht empfohlen, Acronis Cyber Infrastructure auf SAN-/NAS-Hardware mit deren eigenen Redundanzmechanismen auszuführen. Dies kann die Performance und Datenverfügbarkeit negativ beeinflussen.
  • Um eine optimale Performance zu erzielen, halten Sie mindestens 20% der Cluster-Kapazität frei.
  • Bei einem Disaster Recovery benötigt Acronis Cyber Infrastructure möglicherweise zusätzlichen Festplattenspeicher zur Replikation. Achten Sie darauf, mindestens so viel Speicherplatz zu reservieren, wie ihn jeder einzelne Storage-Knoten hat.
  • Es wird empfohlen, auf jedem Knoten die gleichen CPU-Modelle zu verwenden, um Probleme bei der Live-Migration von VMs zu vermeiden. Weitere Informationen finden Sie in der Befehlszeilenanleitung für Administratoren.
  • Wenn Sie das Backup Gateway zum Speichern von Backups in der Cloud verwenden wollen, sollten Sie sicherstellen, dass der lokale Storage-Cluster über genügend logischen Speicherplatz für das Staging (lokale Zwischenspeicherung der Backups, bevor diese zur Cloud gesendet werden) verfügt. Wenn Sie Backups beispielsweise täglich durchführen, sollte der bereitgestellte Speicherplatz für Backups von mindestens 1,5 Tagen reichen. Weitere Informationen finden Sie in der Anleitung für Administratoren.
  • Es wird empfohlen, UEFI statt BIOS zu verwenden, wenn dies von der Hardware unterstützt wird. Insbesondere, wenn Sie NVMe-Laufwerke verwenden.

2.3.3.3. Empfehlungen für die Storage-Hardware

  • Es ist möglich, unterschiedlich große Festplattenlaufwerke im selben Cluster zu verwenden. Sie sollten jedoch beachten, dass kleinere Laufwerke bei gleichen IOPS-Werten eine höhere Performance pro Terabyte an Daten bieten als größere Laufwerke. Es wird empfohlen, Laufwerke mit den gleichen IOPS-Werten pro Terabyte auf derselben Storage-Ebene zu gruppieren.
  • Die Verwendung von uns empfohlener SSD-Modelle kann Ihnen helfen, Datenverluste zu vermeiden. Nicht alle SSD-Laufwerke halten unternehmensgerechten Arbeitslasten stand und können daher in den ersten Monaten des Betriebs ausfallen, was die Kostenbilanz beeinträchtigt.
    • SSD-Speicherzellen können nur eine begrenzte Anzahl von Schreiboperationen aushalten. Ein SSD-Laufwerk sollte daher wie ein Verbrauchsmaterial angesehen werden, welches Sie von Zeit zu Zeit austauschen müssen. Consumer-SSD-Laufwerke können nur eine sehr geringe Anzahl von Schreibvorgängen aushalten (so niedrig, dass diese Zahlen oft in den technischen Spezifikationen nicht angegeben werden). SSD-Laufwerke, die für Storage-Cluster ausgelegt sind, müssen eine Belastbarkeit von mindestens 1 DWPD (10 DWPD werden empfohlen). Je höher diese Belastbarkeit, desto seltener müssen SSDs ausgetauscht werden, was die Kostenbilanz verbessert.
    • Viele Consumer-SSD-Laufwerke können „Disk-Flushes“ (Cache-Leerungen) übersehen und dem Betriebssystem fälschlicherweise mitteilen, dass Daten geschrieben wurden, während dies tatsächlich nicht der Fall war. Beispiele für solche Laufwerke sind OCZ Vertex 3, Intel 520, Intel X25-E und Intel X-25-M G2. Diese Laufwerke sind bekannt dafür, unsicher bei sogenannten Daten-Commit-Vorgängen zu sein. Sie sollten nicht mit Datenbanken verwendet werden und können bei einem Stromausfall leicht das Dateisystem beschädigen. Verwenden Sie aus diesen Gründen Enterprise-SSD-Laufwerke, die den Flush-Regeln entsprechen (weitere Informationen finden Sie unter http://www.postgresql.org/docs/current/static/wal-reliability.html). Diesbezüglich korrekt arbeitende Enterprise-SSD-Laufwerke zeichnen sich normalerweise dadurch aus, dass Schutzfunktionen vor Stromausfällen zu ihren technischen Spezifikation gehören. Einige der bekannteren Markennamen für solche Technologien sind „Enhanced Power Loss Data Protection“ (Intel), „Cache Power Protection“ (Samsung), „Power-Failure Support“ (Kingston) oder „Complete Power Fail Protection“ (OCZ).
    • Es wird dringend empfohlen, die Disk-Flush-Fähigkeiten Ihrer Laufwerke zu überprüfen, wie in Abschnitt ‚Die Daten-Flushing-Fähigkeiten von Laufwerken überprüfen‘ beschrieben.
    • Consumer-SSD-Laufwerke haben üblicherweise eine instabilere Performance und sind nicht geeignet, anhaltenden Enterprise-Workloads standzuhalten. Achten Sie daher bei der Auswahl von SSDs darauf, anhaltende Lasttests durchzuführen. Wir empfehlen folgende Enterprise-SSD-Laufwerke, die in Bezug auf Performance, Belastbarkeit und Investition zu den besten gehören: Intel S3710, Intel P3700, Huawei ES3000 V2, Samsung SM1635 und Sandisk Lightning.
    • Die Performance von SSD-Laufwerken kann von ihrer jeweiligen Größe abhängen. Laufwerke mit geringerer Kapazität (100 bis 400 GB) können deutlich langsamer (manchmal bis zu zehnmal) sein als solche mit höherer Kapazität (1,9 bis 3,8 TB). Bevor Sie Hardware kaufen, sollten Sie die jeweiligen Laufwerksspezifikationen bezüglich Performance und Belastbarkeit studieren.
  • Die Verwendung von NVMe- oder SAS-SSDs als Schreib-Cache verbessert die Performance von wahlfreien I/O-Operationen (Random IOPS) und wird für alle Workloads mit häufigen wahlfreien Zugriffen (wie z.B. bei iSCSI-Volumes) empfohlen. SATA-Laufwerke eignen sich dagegen am besten für reine SSD-Konfigurationen, nicht aber für den Schreib-Cache.
  • Von der Verwendung von SMR-HDD-Laufwerken (Shingled Magnetic Recording) wird dringend abgeraten – auch nicht für Backup-Szenarien. Solche Laufwerke haben unkalkulierbare Latenzzeiten, die zu unerwarteten temporären Service-Ausfällen und plötzlichen Leistungsverlusten führen können.
  • Die Ausführung der Metadaten-Services auf SSDs verbessert die Cluster-Performance. Um die Investitionskosten weiter zu senken, können dieselben SSDs auch für Schreib-Caches verwendet werden.
  • Wenn es hauptsächlich um Kapazität geht und Sie Daten speichern müssen, die selten abgerufenen werden, können Sie SATA- statt SAS-Laufwerke wählen. Wenn Performance der wichtigste Faktor ist, sollten Sie NVMe- oder SAS- statt SATA-Laufwerke bevorzugen.
  • Je mehr Laufwerke pro Knoten, desto geringer fallen die Anfangsinvestitionskosten aus. Ein Cluster, der aus zehn Knoten mit jeweils zwei Laufwerken besteht, ist beispielsweise günstiger als ein Cluster, der aus zwanzig Knoten mit jeweils einem Laufwerk aufgebaut wird.
  • Die Verwendung von SATA-Festplatten (HDDs) mit einer SSD zum Caching ist kostengünstiger, als nur SAS-HDDs (also ohne eine solche SSD) zu verwenden.
  • Erstellen Sie mithilfe von RAID- oder HBA-Controllern Hardware- oder Software-RAID1-Volumes für die Systemlaufwerke, um deren hohe Performance und Verfügbarkeit zu gewährleisten.
  • Sie können HBA-Controller verwenden, weil diese leichter verwaltbar und kostengünstiger als RAID-Controller sind.
  • Deaktivieren Sie alle RAID-Controller-Caches für SSD-Laufwerke. Moderne SSDs haben eine so gute Performance, dass diese durch den Schreib-/Lese-Cache eines RAID-Controllers eher gesenkt wird. Es wird empfohlen, das Caching für SSD-Laufwerke auszuschalten und nur für HDDs aktiviert zu lassen.
  • Wenn Sie RAID-Controller verwenden, erstellen Sie keine RAID-Volumes aus HDDs, die für die Nutzung als Storage gedacht sind. Jede Storage-HDD muss von Acronis Cyber Infrastructure als separates Gerät erkannt werden.
  • Wenn Sie RAID-Controller mit Cache-Funktionalität verwenden, statten Sie diese mit Notstromakkus (BBUs, Backup Battery Units) aus, um Cache-bedingte Datenverluste bei Stromausfällen zu verhindern.
  • Die physische Sektorgröße der Laufwerke (ob 512 Byte oder 4K) ist unwichtig und hat keinen Einfluss auf die Performance.

2.3.3.4. Empfehlungen für die Netzwerk-Hardware

  • Verwenden Sie separate Netzwerke und – idealerweise, aber optional – separate Netzwerkadapter für den internen und öffentlichen Traffic. Dadurch wird verhindert, dass der öffentliche Traffic die I/O-Performance des Clusters beeinträchtigt, und werden mögliche Denial-of-Service-Angriffe von außen unterbunden.
  • Die Netzwerklatenz kann die Cluster-Performance drastisch senken. Verwenden Sie hochwertige Netzwerkgeräte, die niedrige Latenzzeiten ermöglichen. Verwenden Sie keine Consumer-Netzwerk-Switches.
  • Verwenden Sie keine Consumer-Netzwerkadapter wie Intel EXPI9301CTBLK oder Realtek 8129, da diese nicht auf hohe Lasten ausgelegt sind und möglicherweise keine Vollduplex-Verbindungen unterstützen. Verwenden Sie Ethernet-Switches mit Non-Blocking-Fähigkeit.
  • Zur „Intrusion Prevention“ gegen Angriffe sollte sich Acronis Cyber Infrastructure in einem dedizierten internen Netzwerk befinden, auf das von außen kein Zugriff besteht.
  • Verwenden Sie (aufgerundet) eine 1-Gbit/s-Verbindung für je zwei HDDs auf dem Knoten. Bei ein oder zwei HDDs auf einem Knoten werden weiterhin zwei gebündelte Netzwerkschnittstellen für eine hohe Netzwerkverfügbarkeit empfohlen. Denn Ethernet-Netzwerke mit 1 Gbit/s können einen Datendurchsatz von ca. 110-120 MB/s bereitstellen, was nah an der Performance eines Einzellaufwerks (HDD) bei sequenziellen I/O-Operationen liegt. Da mehrere Laufwerke zusammen auf einem Server einen höheren Durchsatz liefern können als eine solche 1-Gbit-Ethernet-Verbindung, kann die Netzwerkanbindung zum Flaschenhals werden.
  • Für eine maximale sequentielle I/O-Performance empfehlen wir, pro HDD eine 1-Gbit-Verbindung oder pro Knoten eine 10-Gbit-Verbindung zu verwenden. Obwohl die meisten I/O-Operationen in realen Szenarien zufällige Zugriffe sind, sind sequentielle I/O-Operationen wichtig für Backup-Szenarien.
  • Um eine maximale Gesamtperformance zu erreichen, sollten Sie eine 10-Gbit-Verbindung pro Knoten verwenden (oder zwei gebündelte, für hohe Netzwerkverfügbarkeit).
  • Wir raten davon ab, für 1-Gbit-Netzwerkadapter eine Konfiguration zu verwenden, bei der nicht-konforme MTUs (Jumbo-Frames mit beispielsweise 9000 Byte) verwendet werden. Solche Einstellungen erfordern auch eine erweiterte Konfiguration der Switche, was jedoch leicht zu menschlichen Fehlern führen kann. 10+-Gbit-Netzwerkadaptern müssen jedoch so konfiguriert werden, dass Jumbo-Frames verwendet werden, um die volle Performance auszuschöpfen.
  • Derzeit werden die Fibre Channel-Host-Bus-Adapter (FC-HBAs) QLogic QLE2562-CK und QLogic ISP2532 unterstützt.
  • Es wird empfohlen, Mellanox ConnectX-4- und ConnectX-5-InfiniBand-Adapter zu verwenden. Mellanox ConnectX-2- und ConnectX-3-Karten werden nicht unterstützt.
  • Adapter, die den BNX2X-Treiber verwenden (wie z. B. Broadcom Limited BCM57840 NetXtreme II 10/20-Gigabit Ethernet / HPE FlexFabric 10-Gigabit-2-Port-536FLB-Adapter) werden nicht empfohlen. Sie begrenzen den MTU-Wert auf 3616, was die Cluster-Performance beeinträchtigt.

2.3.4. Hardware- und Software-Beschränkungen

Hardware-Beschränkungen:

  • Jeder Management-Knoten muss mindestens zwei Laufwerke haben (ein System+Metadaten-Laufwerk, ein Storage-Laufwerk).
  • Jeder Compute- oder Storage-Knoten muss mindestens drei Laufwerke haben (eins für System, eins für Metadaten, eins für Storage).
  • Um alle Funktionen des Produkts testen zu können, sind drei Server erforderlich.
  • Das Systemlaufwerk muss über mindestens 100 GB Speicherplatz verfügen.
  • Zur korrekten Anzeige des Admin-Panels wird ein Bildschirm mit Full-HD-Auflösung benötigt.
  • Die maximal unterstützte physische Partitionsgröße beträgt 254 TiB.

Software-Beschränkungen:

  • Ein Knoten kann nur Bestandteil eines Clusters sein.
  • Es kann nur ein S3-Cluster auf einem Storage-Cluster erstellt werden.
  • Im Admin-Panel stehen nur vordefinierte Redundanzmodi zur Verfügung.
  • Thin Provisioning ist immer für alle Daten aktiviert und kann nicht anders konfiguriert werden.
  • Die korrekte Funktionsweise des Admin-Panels wurde bei einer Bildschirmauflösung von 1280x720 (Minimum) und mit folgenden Webbrowsern getestet: den neuesten Versionen von Firefox, Chrome und Safari.

Zu den Netzwerk-Beschränkungen siehe den Abschnitt ‚Netzwerkbeschränkungen‘.

2.3.5. Minimale Storage-Konfiguration

Mit der in der Tabelle beschriebenen Mindestkonfiguration können Sie die Funktionen des Storage Clusters testen. Sie ist nicht für den Produktionsbetrieb gedacht.

Tab. 2.3.5.1 Minimale Cluster-Konfiguration
Knoten Nr. 1st disk role 2nd disk role 3.+ Laufwerksrolle Zugriffspunkte
1 System Metadaten Storage iSCSI, S3 privat, S3 öffentlich, NFS, Backup Gateway
2 System Metadaten Storage iSCSI, S3 privat, S3 öffentlich, NFS, Backup Gateway
3 System Metadaten Storage iSCSI, S3 privat, S3 öffentlich, NFS, Backup Gateway
3 Knoten insgesamt   3 MDS insgesamt 3+ CS insgesamt Die Access Point Services laufen auf insgesamt drei Knoten.

Bemerkung

SSD-Laufwerken können die System-, Metadaten- und Cache-Rollen gleichzeitig zugewiesen werden, wodurch mehr Laufwerke für die Storage-Rolle verfügbar gemacht werden.

Auch wenn als Mindestkonfiguration drei Knoten empfohlen werden, können Sie die Evaluierung von Acronis Cyber Infrastructure dennoch mit nur einem Knoten beginnen – und später/bei Bedarf weitere Knoten hinzufügen. Ein Storage-Cluster muss mindestens einen Metadaten-Service (MDS) und einen Chunk-Service (CS) ausführen. Mit einer Einzelknoten-Installation können Sie Services wie iSCSI, Backup Gateway usw. zwar bewerten, aber eine solche Konfiguration hat zwei wesentliche Einschränkungen:

  1. Nur einen MDS zu haben, kann eine maßgebliche Fehlerquelle (Single Point of Failure) sein. Wenn er ausfällt, wird der gesamte Cluster nicht mehr funktionieren.
  2. Nur einen CS zu haben bedeutet, nur ein Chunk-Replikat speichern zu können. Bei einem Ausfall können die Daten verloren gehen.

Wichtig

Wenn Sie Acronis Cyber Infrastructure auf nur einem Knoten bereitstellen, müssen Sie darauf achten, dass der Storage persistent und redundant ist, um Datenverluste zu vermeiden. Wenn es sich um einen physischen Knoten handelt, muss dieser mehrere Laufwerke haben, damit Sie die Daten zwischen diesen replizieren können. Wenn es sich bei dem Knoten um eine virtuelle Maschine handelt, müssen Sie sicherstellen, dass die VM durch die ausführende Virtualisierungslösung hochverfügbar gemacht wird.

Bemerkung

Das Backup Gateway arbeitet mit dem lokalen Objekt-Storage im Staging-Modus. Das bedeutet, dass Daten, die in eine Public Cloud repliziert, migriert oder hochgeladen werden sollen, zuerst lokal gespeichert und dann zu ihrem Ziel übertragen werden. Daher ist es entscheidend, dass der lokale Objekt-Storage persistent und redundant ist, um lokale Datenverluste zu vermeiden. Es gibt mehrere Möglichkeiten, die Persistenz und Redundanz des lokalen Storage sicherzustellen. Sie können Ihr Backup Gateway auf mehreren Knoten bereitstellen und einen guten Redundanzmodus wählen. Wenn Ihr Gateway auf einem einzelnen Knoten in Acronis Cyber Infrastructure bereitgestellt wird, können Sie die Redundanz des Storage dadurch erreichen, dass Sie ihn über mehrere lokale Laufwerke hinweg replizieren. Wenn Ihre komplette Acronis Cyber Infrastructure-Installation in einer einzigen virtuellen Maschine und allein zum Erstellen eines Gateways bereitgestellt wird, sollten Sie sicherstellen, dass diese VM durch die ausführende Virtualisierungslösung hochverfügbar gemacht wird.

2.3.7. Überlegungen zum Raw-Speicherplatz

Beachten Sie bei der Planung der Infrastruktur die folgenden Punkte, um Verwirrungen zu vermeiden:

  • Die Kapazität von HDDs und SSDs wird mit dezimalen (und nicht binären) Präfixen bemessen bzw. spezifiziert. Daher steht die Angabe „TB“ bei Laufwerksspezifikationen normalerweise für „Terabyte“. Das Betriebssystem zeigt die Laufwerkskapazität jedoch mit binären Präfixen an. Hier steht „TB“ für „Tebibyte“ – was eine deutlich größere Zahl ergibt. Infolgedessen kann ein Laufwerk in einem Betriebssystem eine geringere Kapazität aufweisen, als die ursprünglich vom Hersteller angegebene/beworbene. Ein Laufwerk, das laut Hersteller-Spezifikation beispielsweise 6 TB hat, verfügt in Acronis Cyber Infrastructure über einen tatsächlichen Speicherplatz von 5,45 TB.
  • 5% des Speicherplatzes werden als Notfallbedarf reserviert.

Wenn Sie also ein 6-TB-Laufwerk zu einem Cluster hinzufügen, sollte sich der verfügbare physische Speicherplatz um etwa 5,2 TB erhöhen.

2.3.8. Die Daten-Flushing-Fähigkeiten von Laufwerken überprüfen

Sie sollten unbedingt alle Storage-Geräte, die Sie in Ihren Cluster aufnehmen wollen, daraufhin überprüfen, ob diese im Cache zwischengespeicherte Daten auf das Laufwerk übertragen können, wenn die Stromversorgung des Servers unerwartet unterbrochen werden sollte. Auf diese Weise ermitteln Sie Geräte, die bei einem Stromausfall möglicherweise Daten verlieren.

Acronis Cyber Infrastructure wird mit dem Tool vstorage-hwflush-check ausgeliefert, mit dem Sie ein Storage-Gerät darauf überprüfen können, wie dieses Daten bei einem Notfall aus dem Cache auf das Laufwerk speichert. Das Tool ist als Client-/Server-Utility implementiert:

  • Der Client schreibt kontinuierlich Datenblöcke auf das Storage-Gerät. Wenn ein Datenblock geschrieben wurde, erhöht der Client einen speziellen Zähler und sendet diesen an den Server, der ihn aufbewahrt.
  • Der Server verfolgt die eingehenden Zähler des Clients, sodass der Server immer weiß, welche Zählernummer der Client als nächstes senden wird. Wenn der Server einen Zähler erhält, der kleiner als derjenige ist, der bereits auf dem Server gespeichert wurde (z.B. weil die Stromversorgung ausgefallen ist und das Storage-Gerät die Daten im Cache nicht auf den permanenten Datenträger geschrieben hat), meldet der Server einen Fehler.

Gehen Sie folgendermaßen vor, um zu überprüfen, ob ein Storage-Gerät bei einem Stromausfall im Cache befindliche Daten erfolgreich auf das Laufwerk schreiben kann:

  1. Führen Sie auf einem Knoten den Server aus:

    # vstorage-hwflush-check -l

  2. Führen Sie auf einem anderen Knoten, der das zu testende Storage-Gerät hostet, den Client aus. Beispiel:

    # vstorage-hwflush-check -s vstorage1.example.com -d /vstorage/stor1-ssd/test -t 50

    wobei gilt:

    • vstorage1.example.com ist der Host-Name des Servers.
    • /vstorage/stor1-ssd/test ist das Verzeichnis, das zum Testen des Daten-Flushing verwendet werden soll. Während der Ausführung erstellt das Client-Tool eine Datei in diesem Verzeichnis und schreibt Datenblöcke in diese.
    • 50 ist die Anzahl der Threads, die das Client-Tool zum Schreiben von Daten auf das Laufwerk verwenden soll. Zu jedem Thread gehört eine eigene Datei und ein eigener Zähler. Sie können die Anzahl der Threads erhöhen (auf maximal 200), um Ihr System mit einer höheren Belastung zu testen. Sie können auch noch andere Optionen für die Ausführung des Client-Tools spezifizieren. Weitere Informationen zu den verfügbaren Informationen finden Sie in der Dokumentation (Manpage) zu vstorage-hwflush-check.

  3. Warten Sie mindestens 10-15 Sekunden, trennen Sie die Stromversorgung vom Client-Knoten (drücken Sie entweder die Power-Taste oder ziehen das Netzkabel heraus) und schalten Sie ihn dann wieder ein.

  4. Starten Sie das Client-Tool neu:

    # vstorage-hwflush-check -s vstorage1.example.com -d /vstorlage/stor1-ssd/test -t 50

Nach dem Start liest das Client-Tool alle zuvor geschriebenen Daten, bestimmt die Version der Daten auf dem Laufwerk und startet den Test dann vom letzten gültigen Zähler ausgehend neu. Anschließend sendet es diesen gültigen Zähler an das Server-Tool, und dieses vergleicht den Zähler mit dem letzten, den es selbst hat. Sie sehen eine Ausgabe wie diese:

id<N>:<counter_on_disk> -> <counter_on_server>

was Folgendes bedeuten kann:

  • Wenn der Zähler auf dem Laufwerk niedriger ist als der Zähler auf dem Server-Tool, bedeutet dies, dass das Storage-Gerät keine Daten aus dem Cache auf den Datenträger schreiben konnte. Dieses Storage-Gerät sollten Sie möglichst nicht im Produktiveinsatz verwenden (insbesondere nicht für CS und Journals), da hier das Risiko von Datenverlusten besteht.
  • Wenn der Zähler auf dem Laufwerk höher ist als der Zähler auf dem Server-Tool, bedeutet dies, dass das Storage-Gerät die Daten zwar aus dem Cache auf den permanenten Datenträger geschrieben hat, das Client-Tool dies aber nicht mehr an das Server-Tool melden konnte. Möglicherweise ist das Netzwerk zu langsam oder das Storage-Gerät ist für die vorgegebene Thread-Anzahl zu schnell, sodass Sie deren Erhöhung in Betracht ziehen sollten. Ein solches Storage-Gerät kann für den Produktiveinsatz verwendet werden.
  • Wenn beide Zähler gleich sind, bedeutet dies, dass das Storage-Gerät die Daten aus dem Cache auf den Datenträger geschrieben hat und dass das Client-Tool dies dem Server-Tool gemeldet hat. Ein solches Storage-Gerät kann für den Produktiveinsatz verwendet werden.

Wenn Sie auf der sicheren Seite sein wollen, sollten Sie den Vorgang mehrmals wiederholen. Fahren Sie nach dem ersten Storage-Gerät mit der Überprüfung der übrigen Geräte fort, die Sie im Cluster verwenden wollen. Sie müssen alle Geräte testen, die Sie im Cluster verwenden wollen: SSD-Laufwerke für CS-Journaling, Laufwerke für MDS-Journale und Chunk-Server.

31.07.2020
Drucken