Design eines virtualisierten Rechenzentrums

Einführung

Ein Informationssystem wird aus der Sicht des Nutzers gut im GOST RV 51987 definiert – „eine automatisierte System, dessen Ergebnis die Präsentation von Ausgangsinformationen zur weiteren Verwendung ist“. Betrachtet man jedoch die interne Struktur, so ist im Kern jedes Informationssystem ein System von in Code umgesetzten verknüpften Algorithmen. In einem weiten Sinne führt das Turing-Church-Theorem dazu, dass ein Algorithmus (und damit das Informationssystem) eine Transformation einer Vielzahl von Eingabedaten in eine Vielzahl von Ausgabedaten vornimmt.
Man kann sogar sagen, dass die Transformation der Eingabedaten den Sinn eines Informationssystems ausmacht. Folglich wird der Wert des Informationssystems und des gesamten Komplexes an Informationssystemen durch den Wert der Eingabe- und Ausgabedaten bestimmt.
Auf dieser Grundlage sollte das Design beginnen und die Daten als Grundlage nehmen, indem die Architektur und die Methoden an die Struktur und die Bedeutung der Daten angepasst werden.

Gespeicherte Daten
Ein entscheidender Schritt bei der Vorbereitung des Designs ist die Erfassung der Merkmale aller Datensätze, die verarbeitet und gespeichert werden sollen. Diese Merkmale umfassen:
— Datenvolumen;
— Informationen über den Lebenszyklus von Daten (Zuwachs neuer Daten, Lebensdauer, Verarbeitung veralteter Daten);
— Klassifizierung von Daten unter dem Gesichtspunkt ihrer Auswirkungen auf das Kerngeschäft des Unternehmens (unter Berücksichtigung der Triade Datenschutz, Integrität, Verfügbarkeit) sowie der finanziellen Kennzahlen (z. B. Kosteneinbußen durch Datenverlust in der letzten Stunde);
— Geographie der Datenverarbeitung (physische Standorte der Verarbeitungssysteme);
— Anforderungen der Regulierungsbehörden für jede Datenklasse (z. B. FZ-152, PCI DSS).

Informationssysteme

Daten werden nicht nur gespeichert, sondern auch durch Informationssysteme verarbeitet (transformiert). Der nächste Schritt nach der Erfassung der Dateneigenschaften besteht darin, eine möglichst vollständige Inventarisierung der Informationssysteme, ihrer architektonischen Besonderheiten, Abhängigkeiten und Infrastrukturanforderungen in relativen Einheiten für vier Arten von Ressourcen durchzuführen:
— Rechenleistung des Prozessors;
— Größe des Arbeitsspeichers;
— Anforderungen an Kapazität und Leistung des Speichersystems;
— Anforderungen an das Datenübertragungsnetz (externe Kanäle, Verbindungen zwischen den Komponenten der IS).
Die Anforderungen müssen für jeden Service/Mikroservice im Rahmen des Informationssystems festgelegt werden.
Es ist wichtig, dass zur korrekten Planung Daten über die Auswirkungen des Informationssystems auf das Hauptgeschäft des Unternehmens in Form von Kosten für Ausfallzeiten des Systems (in Rubel pro Stunde) vorliegen.

Bedrohungsmodell

Es muss unbedingt ein formales Bedrohungsmodell vorhanden sein, gegen das die Daten/Services geschützt werden sollen. Dieses Bedrohungsmodell umfasst nicht nur Aspekte der Vertraulichkeit, sondern auch der Integrität und Verfügbarkeit. Zum Beispiel:
— Ausfall eines physischen Servers;
— Ausfall eines Top-of-the-Rack-Switches;
— Unterbrechung des optischen Kommunikationskanals zwischen den Rechenzentren;
— Komplettausfall des operativen SAN.
In einigen Fällen werden Bedrohungsmodelle nicht nur für infrastrukturelle Komponenten, sondern auch für spezifische Informationssysteme oder deren Komponenten erstellt, wie beispielsweise der Ausfall einer Datenbank mit logischer Zerstörung der Datenstruktur.
Alle Entscheidungen im Rahmen des Projekts zum Schutz gegen nicht beschriebene Bedrohungen sind überflüssig.

Vorgaben der Regulierungsbehörden

Wenn die verarbeiteten Daten unter spezielle Vorschriften fallen, die von den Regulierungsbehörden festgelegt werden, ist unbedingt Informationen über Datensätze und die Regeln für deren Verarbeitung/Speicherung erforderlich.

Zielwerte RPO / RTO

Die Planung jeder Art von Schutz erfordert Zielwerte für den potenziellen Datenverlust und die Wiederherstellungszeit für jeden der beschriebenen Bedrohungen.
Idealerweise sollten RPO und RTO mit den assoziierten Kosten für Datenverluste und Ausfallzeiten pro Zeiteinheit verbunden sein.

Ressourcenteilung

Nach der Sammlung aller grundlegenden Informationen besteht der erste Schritt darin, Datensätze und Informationssysteme in Pools zu gruppieren, basierend auf Bedrohungsmodellen und regulatorischen Anforderungen. Es wird bestimmt, welchen Typ der Trennung der verschiedenen Pools es gibt – softwarebasiert auf der Ebene der Systemsoftware oder physisch.
Beispiele:
— Der Bereich, der personenbezogene Daten verarbeitet, ist vollständig physisch von den anderen Systemen getrennt;
— Backups werden auf einem separaten Speichersystem gespeichert.

Die Pools können mit teilweiser Unabhängigkeit betrieben werden, zum Beispiel werden zwei Pools von Rechenressourcen (CPU-Leistung + Arbeitsspeicher) definiert, die einen gemeinsamen Pool von Datenspeicher und einen gemeinsamen Pool von Übertragungsressourcen nutzen.

CPU-Leistung

Der abstrakte Bedarf an CPU-Leistung eines virtualisierten Rechenzentrums wird in der Anzahl der virtuellen Prozessoren (vCPU) und ihrem Konsolidierungsfaktor auf physische Prozessoren (pCPU) gemessen. In diesem speziellen Fall entspricht 1 pCPU = 1 physischer Prozessorkern (ohne Berücksichtigung von Hyper-Threading). Die Anzahl der vCPUs wird über alle definierten Ressourcensets summiert (von denen jedes einen eigenen Konsolidierungsfaktor haben kann).
Der Konsolidierungsfaktor für belastete Systeme wird empirisch bestimmt, basierend auf der bestehenden Infrastruktur oder während einer Pilotinstallation und Lasttests. Für unbelastete Systeme gelten 'Best Practices'. VMware gibt beispielsweise einen durchschnittlichen Konsolidierungsfaktor von 8:1 an.

Arbeitsspeicher

Der Gesamtbedarf an Arbeitsspeicher ergibt sich durch einfache Summation. Die Verwendung von Overcommitment bei Arbeitsspeicher wird nicht empfohlen.

Speicherressourcen

Die Anforderungen an die Speicherressourcen ergeben sich aus der einfachen Summe aller Pools hinsichtlich Kapazität und Leistung.
Die Leistungsanforderungen werden in IOPS angegeben, unter Berücksichtigung des durchschnittlichen Verhältnisses von Lese- zu Schreibvorgängen sowie gegebenenfalls der maximalen Latenzzeit.
Die Anforderungen an die Servicequalität (QoS) müssen separat für spezifische Pools oder Systeme angegeben werden.

Netzwerkressourcen

Die Anforderungen an die Netzwerkressourcen ergeben sich aus der einfachen Summe aller Bandbreitenpools.
Die Anforderungen an die Servicequalität (QoS) und Latenzen (RTT) müssen separat für spezifische Pools oder Systeme angegeben werden.
Im Rahmen der Anforderungen an die Netzwerkressourcen müssen auch die Anforderungen an die Isolation und/oder Verschlüsselung des Netzwerkverkehrs sowie die bevorzugten Mechanismen (802.1q, IPSec usw.) angegeben werden.

Architekturwahl

In diesem Leitfaden wird keine andere Option als die x86-Architektur und 100% Servervirtualisierung betrachtet. Daher reduziert sich die Wahl der Architektur der Rechensysteme auf die Auswahl der Server-Virtualisierungsplattform, des Serverformfaktors und allgemeiner Konfigurationsanforderungen.

Ein entscheidender Aspekt bei der Wahl ist die Klarheit darüber, ob der klassische Ansatz mit Trennung von Datenverarbeitung, -speicherung und -übertragung oder ein konvergenter Ansatz verfolgt wird.

Klassische Architektur Dieser Ansatz impliziert die Nutzung intelligenter externer Systeme für die Speicherung und Übertragung von Daten, während die Server lediglich Rechenleistung und RAM in den gemeinsamen Pool physischer Ressourcen einbringen. Im Extremfall werden die Server vollständig anonym, ohne eigene Festplatten oder sogar eine Systemidentifikation. In diesem Fall erfolgt das Booten des Betriebssystems oder Hypervisors von integrierten Flash-Speichergeräten oder einem externen Speichersystem (boot from SAN).
Im Rahmen der klassischen Architektur erfolgt die Wahl zwischen Blade- und Rack-Servern in erster Linie nach den folgenden Prinzipien:
— Wirtschaftlichkeit (Rack-Server sind in der Regel günstiger);
— Rechenkapazität (Blade-Server haben eine höhere Dichte);
— Energieverbrauch und Wärmeentwicklung (bei Blade-Servern ist der spezifische Verbrauch pro Einheit höher);
— Skalierbarkeit und Verwaltung (Blade-Server erfordern insgesamt weniger Aufwand bei großen Installationen);
— Verwendung von Erweiterungskarten (bei Blade-Servern ist die Auswahl stark eingeschränkt).
Konvergente Architektur (auch bekannt als hyperkonvergent) vereint die Funktionen der Datenverarbeitung und Datenspeicherung, was zur Nutzung lokaler Festplatten in Servern führt und somit den Formfaktor klassischer Blade-Server obsolet macht. 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 / RAM

Um die Konfiguration korrekt zu berechnen, muss der Typ der Belastung für die Umgebung oder jeden unabhängigen Cluster verstanden werden.
CPU-bound – eine Umgebung, die durch die Rechenleistung des Prozessors begrenzt ist. Das Hinzufügen von Arbeitsspeicher hat keinen Einfluss auf die Leistung (Anzahl der VMs auf dem Server).
Memory-bound – eine Umgebung mit begrenztem Arbeitsspeicher. Mehr Arbeitsspeicher auf dem Server ermöglicht den Betrieb einer größeren Anzahl von VMs auf dem Server.
GB / MHz (GB / pCPU) – das durchschnittliche Verhältnis des Arbeitsspeicher- und CPU-Verbrauchs dieser speziellen Last. Dies kann verwendet werden, um den erforderlichen Speicherbedarf bei gegebener Leistung zu berechnen und umgekehrt.

Berechnung der Serverkonfiguration

Zunächst müssen alle Arten von Lasten bestimmt und eine Entscheidung über die Kombination oder Trennung verschiedener Rechen-Pools in verschiedene Cluster getroffen werden.
Anschließend wird für jeden definierten Cluster das Verhältnis von GB / MHz bei bekannter Last festgelegt. Wenn die Last nicht im Voraus bekannt ist, aber ein ungefähres Verständnis der Auslastung der CPU-Leistung besteht, können Standardverhältnisse von vCPU:pCPU verwendet werden, um die Anforderungen der Pools in physische Ressourcen zu übertragen.

Für jeden Cluster teilen wir die Summe der Anforderungen der vCPU-Pools durch den Koeffizienten:
vCPU_sum / vCPU:pCPU = pCPU_sum – die erforderliche Anzahl physischer Kerne
pCPU_sum / 1,25 = pCPU_ht – die Anzahl der Kerne unter Berücksichtigung von Hyper-Threading
Angenommen, Sie müssen einen Cluster mit 190 Kernen / 3,5 TB RAM berechnen. Dabei nehmen wir eine Zielauslastung von 50 % der Rechenleistung und 75 % des RAM an.

pCPU
190
CPU Auslastung
50%

RAM
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 Aufrundung auf die nächste ganze Zahl nach oben (=ROUNDUP(A1;0)).
Aus der Tabelle geht deutlich hervor, dass mehrere Serverkonfigurationen für die Zielvorgaben ausgewogen sind:
— 26 Server 2*6c / 192 GB
— 19 Server 2*10c / 256 GB
— 10 Server 2*18c / 512 GB

Die Auswahl aus diesen Konfigurationen sollte in weiterer Folge auf Basis zusätzlicher Faktoren getroffen werden, wie beispielsweise das thermische Paket und die verfügbare Kühlung, bereits eingesetzte Server oder die Kosten.

Besonderheiten bei der Auswahl der Serverkonfiguration

Große VMs. Wenn es notwendig ist, große VMs (vergleichbar mit 1 NUMA-Knoten und mehr) bereitzustellen, sollte nach Möglichkeit ein Server gewählt werden, dessen Konfiguration es ermöglicht, diese VMs innerhalb eines NUMA-Knotens zu belassen. Bei einer großen Anzahl von großen VMs besteht die Gefahr der Fragmentierung der Clusterressourcen, und in diesem Fall sollten Server ausgewählt werden, die es ermöglichen, große VMs möglichst dicht zu platzieren.

Die Größe der Single Point of Failure-Domäne.

Die Auswahl der Servergröße erfolgt ebenfalls unter dem Prinzip der Minimierung der Single Point of Failure-Domäne. Beispielsweise bei der Wahl zwischen:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
Bei sonst gleichen Bedingungen sollte die zweite Option gewählt werden, da bei einem Ausfall eines Servers (oder Wartungsarbeiten) nicht 33 % der Clusterressourcen verloren gehen, sondern 17 %. Auch die Anzahl der VMs und IS, die von dem Vorfall betroffen sind, wird halbiert.

Berechnung der klassischen SAN-Leistung

Die klassische SAN wird immer nach dem ungünstigsten Szenario (worst case scenario) berechnet, wobei der Einfluss des operativen Caches und der Optimierung von Operationen ausgeschlossen ist.
Als Basisindikatoren der Leistung verwenden 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 nach folgender Formel berechnet: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Wo:
— TotalIOPS – die insgesamt erforderliche Leistung in IOPS aus der Festplattenspeicher
— RW – der prozentuale Anteil der Leseoperationen
— RAIDpen – RAID-Strafe für das gewählte RAID-Level

Mehr über RAID-Geräte und RAID-Strafe erfahren Sie hier — Leistung von Speicherlösungen. Teil eins. und Leistung von Speicherlösungen. Teil zwei. und Leistung von Speicherlösungen. Teil drei.

Basierend auf der Anzahl der erhaltenen Festplatten werden verschiedene Optionen berechnet, die den Anforderungen an die Speicherkapazität entsprechen, einschließlich Optionen mit mehrstufiger Speicherung.
Die Berechnung von Systemen mit SSDs als Speicherebene wird separat betrachtet.
Besonderheiten bei der Berechnung von Systemen mit Flash Cache

Flash Cache – ein Oberbegriff für alle proprietären Technologien zur Nutzung von Flash-Speicher als Level-2-Cache. Bei der Verwendung von Flash-Cache wird in der Regel die Belastung von herkömmlichen Magnetfestplatten berechnet, während die Spitzenlast vom Cache abgedeckt wird.
Dabei ist es wichtig, das Lastprofil und den Grad der Lokalisierung der Anfragen an die Speicher-Volumes zu verstehen. Flash-Caching ist eine Technologie für Lasten mit hoher Anfrage-Lokalisierung und ist praktisch nicht anwendbar für gleichmäßig belastete Volumes (wie zum Beispiel für Analysesysteme).

Berechnung von hybriden Systemen der Einstiegsklasse / Mittelklasse

Hybride Systeme der unteren und mittleren Klassen verwenden mehrschichtige Speicherung mit Datenverschiebungen zwischen den Ebenen nach einem Zeitplan. Dabei beträgt die Blockgröße der mehrschichtigen Speicherung bei den besten Modellen 256 MB. Diese Merkmale lassen die Technologie der mehrschichtigen Speicherung nicht als Leistungssteigerungspipeline erscheinen, wie viele fälschlicherweise annehmen. Mehrschichtige Speicherung in Systemen der unteren und mittleren Klassen ist eine Technologie zur Kostenoptimierung der Speicherung für Systeme mit ausgeprägter Lastungsgleichmäßigkeit.

Bei einer mehrstufigen Speicherung wird primär die Leistung der obersten Ebene berücksichtigt, während die untere Speicherebene lediglich zur Bereitstellung zusätzlicher Speicherkapazität dient. Der Einsatz von Flash-Cache-Technologie für den mehrstufigen Pool ist unerlässlich, um Leistungseinbrüche bei plötzlichem Anstieg der Datenlast aus der unteren Ebene auszugleichen.

Einsatz von SSD in einem mehrstufigen Speicherpool

Der Einsatz von SSD in einem mehrstufigen Speicherpool variiert je nach den spezifischen Implementierungsdetails der Flash-Cache-Algorithmen des jeweiligen Herstellers.
Die gängige Praktik für Speicherrichtlinien in einem SSD-basierten Speicherpool lautet: SSD first.
Read-Only Flash-Cache. Bei einem Read-Only Flash-Cache wird die SSD-Speicherebene aktiviert, sobald die Schreiboperationen erheblich lokalisiert sind, unabhängig vom Cache.
Read/Write Flash-Cache. Im Falle eines Write-Flash-Caches wird zunächst das maximale Cache-Volumen festgelegt, und die SSD-Speicherebene wird nur aktiviert, wenn die Größe des Caches nicht ausreicht, um die gesamte lokalisierten Last zu bewältigen.
Die Berechnung der SSD- und Cache-Leistung erfolgt stets basierend auf den Empfehlungen des Herstellers, jedoch immer für den ungünstigsten Fall.

Quelle: habr.com