Design des virtualisierten Rechenzentrums

Einführung

Das Informationssystem aus Sicht des Benutzers wird gut in GOST RV 51987 definiert – „ein automatisiertes System, dessen Funktion darin besteht, Ausgangsinformationen zur weiteren Nutzung bereitzustellen“. Betrachtet man die interne Struktur, ist im Grunde jedes IS ein System von in Code umgesetzten miteinander verknüpften Algorithmen. Im weitesten Sinne transformiert der Algorithmus (und entsprechend das IS) eine Menge von Eingabedaten in eine Menge von Ausgabedaten.
Man kann sogar sagen, dass der Sinn der Existenz eines Informationssystems gerade in der Transformation der Eingabedaten liegt. Dementsprechend wird der Wert des IS und des gesamten Komplexes von IS durch den Wert der Eingabedaten und der Ausgabedaten definiert.
Aus diesem Grund sollte das Design beginnen und auf den Daten basieren, indem die Architektur und Methoden an die Struktur und Bedeutung der Daten angepasst werden.

Gespeicherte Daten
Ein entscheidender Schritt bei der Vorbereitung auf die Planung ist das Erfassen der Merkmale aller Datensätze, die bearbeitet und gespeichert werden sollen. Diese Merkmale umfassen:
— Datenvolumen;
— Informationen über den Lebenszyklus der Daten (Zuwachs neuer Daten, Lebensdauer, Verarbeitung veralteter Daten);
— Klassifizierung der Daten hinsichtlich ihres Einflusses auf das Hauptgeschäft des Unternehmens (in der Triade von Vertraulichkeit, Integrität, Verfügbarkeit) zusammen mit finanziellen Kennzahlen (z. B. die Kosten für den Verlust von Daten in der letzten Stunde);
— Geografie der Datenverarbeitung (physikalische Lage der Verarbeitungssysteme);
— Anforderungen der Regulierungsbehörden für jede Datenklasse (z. B. FZ-152, PCI DSS).

Informationssysteme

Daten werden nicht nur gespeichert, sondern auch von Informationssystemen verarbeitet (transformiert). Der nächste Schritt nach dem Erfassen der Datenmerkmale ist eine möglichst vollständige Inventarisierung der Informationssysteme, ihrer architektonischen Besonderheiten, Abhängigkeiten und Infrastrukturvoraussetzungen in Einheitspreisen für vier Arten von Ressourcen:
— Rechnerische Prozessleistung;
— Volumen des Arbeitsspeichers;
— Anforderungen an Volumen und Leistungsfähigkeit des Datenspeichers;
— Anforderungen an das Datennetzwerk (externe Kanäle, Kanäle zwischen IS-Komponenten).
Die Anforderungen müssen für jeden Dienst/Mikrodienst im Rahmen des IS vorliegen.
Es ist besonders wichtig, dass für die korrekte Planung Daten über den Einfluss des IS auf das Hauptgeschäft des Unternehmens in Form der Kosten für Ausfallzeiten des IS (Rubel pro Stunde) vorliegen.

Bedrohungsmodell

Es muss zwingend ein formelles Bedrohungsmodell vorhanden sein, gegen das die Daten/Dienste geschützt werden sollen. Dabei umfasst das Bedrohungsmodell nicht nur Aspekte der Vertraulichkeit, sondern auch der Integrität und Verfügbarkeit. Das heißt zum Beispiel:
— Ausfall des physischen Servers;
— Ausfall des Top-of-the-Rack-Switches;
— Unterbrechung des optischen Kommunikationskanals zwischen den Rechenzentren;
— Totalausfall des laufenden Storage Systems.
In einigen Fällen werden Bedrohungsmodelle nicht nur für infrastrukturelle Komponenten, sondern auch für spezifische IS oder deren Komponenten geschrieben, wie zum Beispiel der Ausfall der DBMS mit logischer Zerstörung der Datenstruktur.
Alle Entscheidungen im Rahmen des Projekts zum Schutz vor nicht beschriebenen Bedrohungen sind überflüssig.

Anforderungen der Regulierungsbehörden

Wenn die verarbeiteten Daten unter spezielle Regelungen fallen, die von Aufsichtsbehörden festgelegt werden, ist zwingend Informationen über Datensätze und die Regeln für Verarbeitung/Speicherung erforderlich.

Zielwerte RPO/RTO

Die Planung jeglicher Art von Schutz erfordert die Festlegung von Werten für den angestrebten Datenverlust und die angestrebte Wiederherstellungszeit des Dienstes für jede der beschriebenen Bedrohungen.
Idealerweise sollten RPO und RTO mit den entsprechenden Kosten für Datenverluste und Ausfallzeiten pro Zeiteinheit verbunden sein.

Aufteilung in Ressourcenpools

Nach der Erhebung aller primären Informationen ist der erste Schritt die Gruppierung von Datensätzen und IS in Pools, basierend auf Bedrohungsmodellen und Anforderungen der Regulierungsbehörden. Es wird der Typ der Trennung der verschiedenen Pools festgelegt – programmatisch auf der Ebene der Systemsoftware oder physisch.
Beispiele:
— Der Rahmen, der personenbezogene Daten verarbeitet, ist vollständig physisch von anderen Systemen getrennt;
— Backups werden auf einem separaten Storage-System gespeichert.

Dabei können die Pools teilweise unabhängig sein, zum Beispiel werden zwei Pools von Rechenressourcen (Rechenleistung + Arbeitsspeicher) definiert, die einen gemeinsamen Datenspeicherpool und einen gemeinsamen Datenübertragungspool nutzen.

Rechenleistung

Die abstrakten Anforderungen an die Verarbeitungsleistung eines virtualisierten Rechenzentrums werden in der Anzahl der virtuellen Prozessoren (vCPU) und dem Verhältnis ihrer Konsolidierung auf physischen Prozessoren (pCPU) gemessen. In diesem speziellen Fall entspricht 1 pCPU = 1 physischer Prozessorkern (ohne Hyper-Threading). Die Anzahl der vCPUs wird über alle definierten Ressourcensäulen hinweg summiert (jede kann ihren eigenen Konsolidierungsfaktor haben).
Der Konsolidierungsfaktor für stark belastete Systeme wird empirisch ermittelt, basierend auf der bereits bestehenden Infrastruktur oder während der Pilotinstallation und Lasttests. Für unbelastete Systeme kommen „Best Practices“ zur Anwendung. VMware nennt beispielsweise einen durchschnittlichen Konsolidierungsfaktor von 8:1.

Arbeitsspeicher

Der gesamte Speicherbedarf wird durch einfaches Summieren ermittelt. Die Verwendung von Overcommitment bei Arbeitsspeicher wird nicht empfohlen.

Speicherressourcen

Die Anforderungen an Speicherressourcen ergeben sich durch die einfache Addition aller Pools in Bezug auf Umfang und Leistung.
Die Leistungsanforderungen werden in IOPS ausgedrückt, in Kombination mit dem durchschnittlichen Verhältnis von Lese- zu Schreibvorgängen und gegebenenfalls der maximalen Antwortzeit.
Die Anforderungen an die Qualität des Service (QoS) müssen für spezifische Pools oder Systeme separat angegeben werden.

Netzwerkressourcen

Die Anforderungen an die Netzwerkressourcen werden durch die einfache Addition aller Pools in Bezug auf die Bandbreite ermittelt.
Die Anforderungen an die Qualität des Service (QoS) und die Latenz (RTT) müssen für spezifische Pools oder Systeme separat angegeben werden.
Im Rahmen der Anforderungen an die Netzwerkressourcen müssen auch Anforderungen an die Isolation und/oder Verschlüsselung des Datenverkehrs sowie bevorzugte Mechanismen (802.1q, IPSec usw.) angegeben werden.

Architekturwahl

Im Rahmen dieses Leitfadens wird keine andere Wahl als die x86-Architektur und 100% Virtualisierung von Servern betrachtet. Daher reduziert sich die Wahl der Rechenarchitektur auf die Auswahl der Servervirtualisierungsplattform, die Bauform der Server und die allgemeinen Konfigurationsanforderungen der Server.

Ein entscheidender Punkt bei der Wahl ist die Klarheit hinsichtlich der Verwendung des klassischen Ansatzes mit Trennung der Funktionen für Verarbeitung, Speicherung und Datenübertragung oder des konvergenten Ansatzes.

Klassische Architektur bedeutet die Verwendung intelligenter externer Datenspeicher- und Übertragungssysteme, während die Server nur Rechenleistung und Arbeitsspeicher in den allgemeinen Pool physischer Ressourcen einbringen. Im Extremfall werden Server völlig anonym, ohne eigene Festplatten und sogar ohne Systemidentifikatoren. In diesem Fall erfolgt das Booten des Betriebssystems oder Hypervisors von eingebauten Flash-Laufwerken oder von einem externen Datenspeichersystem (Boot von SAN).
Im Rahmen der klassischen Architektur erfolgt die Wahl zwischen Blade- und Rack-Servern in erster Linie nach folgenden Prinzipien:
— Wirtschaftlichkeit (Rack-Server sind im Durchschnitt günstiger);
— Rechenkapazität (bei Blades höher);
— Energieverbrauch und Wärmeabgabe (bei Blades höher pro Einheit);
— Skalierbarkeit und Managebarkeit (Blades erfordern insgesamt weniger Aufwand bei großen Installationen);
— Verwendung von Erweiterungskarten (bei Blades sehr begrenzte Auswahl).
Konvergente Architektur (auch bekannt als hyperkonvergent) bedeutet die Kombination von Datenverarbeitungs- und Speicherfunktionen, was zur Nutzung von lokalen Festplatten der Server führt und folglich den Verzicht auf das Formfaktor klassischer Blades zur Folge hat. Für konvergente Systeme werden entweder Rack-Server oder Cluster-Systeme verwendet, die mehrere Blade-Server und lokale Festplatten in einem Gehäuse kombinieren.

CPU / Arbeitsspeicher

Für die korrekte Berechnung der Konfiguration muss der Typ der Last für die Umgebung oder jeden der unabhängigen Cluster verstanden werden.
CPU bound – Umgebung, die in der Leistung durch die Prozessorkapazität begrenzt ist. Die Hinzufügung von Arbeitsspeicher ändert nichts an der Leistungsfähigkeit (Anzahl der VMs pro Server).
Memory bound – Umgebung, die durch den Arbeitsspeicher begrenzt ist. Größere Menge an Arbeitsspeicher auf dem Server ermöglicht das Starten einer größeren Anzahl von VMs auf dem Server.
GB / MHz (GB / pCPU) – das durchschnittliche Verhältnis des Verbrauchs ebendieser spezifischen Last von Arbeitsspeicher und Prozessorkapazität. Kann zur Berechnung des benötigten Speichervolumens bei gegebener Leistung und umgekehrt verwendet werden.

Berechnung der Serverkonfiguration

Zunächst müssen alle Arten von Lasten bestimmt und entschieden werden, ob verschiedene Berechnungspools innerhalb verschiedener Cluster kombiniert oder getrennt werden sollen.
Anschließend wird für jeden der bestimmten Cluster das Verhältnis von GB / MHz bei bekannter Last festgelegt. Wenn die Last nicht im Voraus bekannt ist, aber eine ungefähre Vorstellung vom Auslastungsniveau der Rechenleistung besteht, können standardisierte Verhältnisse von vCPU:pCPU verwendet werden, um die Anforderungen der Pools in physische Ressourcen zu übersetzen.

Für jeden Cluster teilen wir die Summe der Anforderungen der vCPU-Pools durch den Koeffizienten:
vCPUsumme / vCPU:pCPU = pCPUsumme – benötigte Anzahl physischer Kerne
pCPUsumme / 1.25 = pCPUht – Anzahl der Kerne unter Berücksichtigung des Hyper-Threadings
Angenommen, wir müssen einen Cluster mit 190 Kernen / 3,5 TB RAM berechnen. Dabei nehmen wir eine Zielauslastung von 50 % für die Rechenleistung und 75 % für den RAM an.

pCPU
190
CPU-Auslastung
50%

Mem
3500
RAM-Auslastung
75%

Sockel
Kern
Srv / CPU
Srv RAM
Srv / RAM

2
6
25,3
128
36,5

2
8
19,0
192
24,3

2
10
15,2
256
18,2

2
14
10,9
384
12,2

2
18
8,4
512
9,1

In diesem Fall verwenden wir immer die Rundung auf die nächste ganze Zahl nach oben (=ROUNDUP(A1;0)).
Aus der Tabelle wird offensichtlich, dass mehrere Serverkonfigurationen den Zielvorgaben entsprechen:
— 26 Server 2*6c / 192 GB
— 19 Server 2*10c / 256 GB
— 10 Server 2*18c / 512 GB

Die Auswahl aus diesen Konfigurationen sollte basierend auf zusätzlichen Faktoren erfolgen, wie zum Beispiel dem Wärmepaket und der verfügbaren Kühlung, bereits genutzten Servern oder den Kosten.

Besonderheiten der Serverkonfiguration

Breite VMs. Bei der Notwendigkeit, breite VMs (vergleichbar mit 1 NUMA-Knoten und mehr) unterzubringen, wird empfohlen, nach Möglichkeit Server auszuwählen, die es diesen VMs ermöglichen, innerhalb eines NUMA-Knotens zu bleiben. Bei einer großen Anzahl von breiten VMs besteht die Gefahr der Fragmentierung der Clusterressourcen, und in diesem Fall werden Server ausgewählt, die eine möglichst dichte Unterbringung breiter VMs ermöglichen.

Größe der Domäne einzelner Ausfälle.

Die Auswahl der Servergröße erfolgt ebenfalls nach dem Prinzip der Minimierung der Domäne einzelner Ausfälle. Zum Beispiel bei der Auswahl zwischen:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
Bei gleichbleibenden Bedingungen sollte die zweite Option gewählt werden, da beim Ausfall eines Servers (oder während der Wartung) nicht 33 % der Clusterressourcen verloren gehen, sondern nur 17 %. Ebenso wird die Anzahl der VMs und IS, die von dem Vorfall betroffen sind, halbiert.

Berechnung der klassischen SAN nach Leistung

Eine klassische SAN wird immer nach dem schlechtesten Szenario (worst case scenario) berechnet, wobei der Einfluss des Arbeitsspeichers und die Optimierung der Vorgänge ausgeschlossen werden.
Als Basisleistungskennzahlen nehmen wir die mechanische Leistung von der Festplatte (IOPSdisk):
— 7,2k – 75 IOPS
— 10k – 125 IOPS
— 15k – 175 IOPS

Anschließend wird die Anzahl der Festplatten im Festplattenspeicher mit der folgenden Formel berechnet: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Wo:
— TotalIOPS – die insgesamt benötigte Leistung in IOPS aus dem Festplattenspeicher
— RW – der prozentuale Anteil der Lesevorgänge
— RAIDpen – RAID-Strafmaß für das gewählte RAID-Level

Weitere Informationen über RAID-Geräte und RAID-Strafmaß finden Sie hier — Leistung der SAN. Teil eins. und Leistung der SAN. Teil zwei. und Leistung der SAN. Teil drei.

Aus der erhaltenen Anzahl von Festplatten werden mögliche Optionen berechnet, die den Anforderungen an die Speicherkapazität entsprechen, einschließlich Optionen mit mehrstufiger Speicherung.
Die Berechnung von Systemen unter Verwendung von SSDs als Speicherebene wird gesondert betrachtet.
Besonderheiten der Berechnung von Systemen mit Flash Cache

Flash Cache – ein allgemeiner Begriff für alle proprietären Technologien zur Nutzung von Flash-Speicher als zweiter Cache-Ebene. Bei Verwendung von Flash-Cache wird der SAN in der Regel zur Sicherstellung der etablierten Last von magnetischen Festplatten berechnet, während die Spitzenlast vom Cache bedient wird.
Dabei ist es notwendig, das Lastprofil und das Maß der Lokalisation von Anfragen an die Speicherblöcke zu verstehen. Flash-Cache ist eine Technologie für Arbeitslasten mit hoher Lokalisierung von Anfragen und ist nahezu nicht anwendbar für gleichmäßig belastete Volumes (wie beispielsweise bei Analysesystemen).

Berechnung hybrider Systeme für den unteren / mittleren Markt

Hybride Systeme der unteren und mittleren Klasse verwenden mehrstufige Speicherung mit einer Datenbewegung nach Zeitplan. Dabei beträgt die Blockgröße der mehrstufigen Speicherung bei den besten Modellen 256 MB. Diese Eigenschaften lassen nicht zu, die Technologie der mehrstufigen Speicherung als technologie zur Leistungssteigerung zu betrachten, wie viele fälschlicherweise annehmen. Die mehrstufige Speicherung in Systemen der unteren und mittleren Klasse ist eine Technologie zur Optimierung der Speicherkosten für Systeme mit ausgeprägter ungleichmäßiger Last.

Bei der mehrstufigen Speicherung wird in erster Linie die Leistung der obersten Ebene berechnet, während die untere Speicherebene lediglich als Ergänzung zur fehlenden Speicherkapazität betrachtet wird. Für hybride mehrstufige Systeme ist der Einsatz von Flash-Cache-Technologie für den mehrstufigen Pool unerlässlich, um die Leistungseinbußen bei plötzlich angeforderten Daten aus der unteren Ebene auszugleichen.

Einsatz von SSDs in mehrstufigen Festplattenspeicher-Pools

Der Einsatz von SSDs in mehrstufigen Festplattenspeicher-Pools variiert je nach den Besonderheiten der Implementierung von Flash-Cache-Algorithmen des jeweiligen Herstellers.
Allgemeine Praxis der Speicherpolitik für einen Festplattenspeicher-Pool mit SSD-Ebene — SSD zuerst.
Nur-Lese-Flash-Cache. Für den Nur-Lese-Flash-Cache tritt die Speicherebene auf der SSD bei erheblicher Lokalisierung von Schreiboperationen unabhängig vom Cache auf.
Lese-/Schreib-Flash-Cache. Bei einem schreibe-Flash-Cache wird zunächst die maximale Cache-Größe festgelegt, die Speicherebene auf der SSD tritt jedoch nur auf, wenn die Cache-Größe zur Bewältigung der gesamten lokalisierten Last nicht ausreicht.
Die Berechnung der Leistung von SSD und Cache erfolgt jedes Mal gemäß den Empfehlungen des Herstellers, jedoch immer für den schlechtesten Fall.

Quelle: habr.com