Einführung
Ein Informationssystem aus Sicht des Benutzers ist in GOST RV 51987 genau definiert – „ein automatisiertes System, dessen Ergebnis die Präsentation von Ausgabeinformationen für die spätere Verwendung ist.“ Wenn wir die interne Struktur betrachten, dann ist jeder IS im Wesentlichen ein System miteinander verbundener Algorithmen, die in Code implementiert sind. Im weitesten Sinne der Turing-Church-These wandelt ein Algorithmus (oder IS) einen Satz Eingabedaten in einen Satz Ausgabedaten um.
Man könnte sogar sagen, dass die Transformation von Eingabedaten den Sinn der Existenz eines Informationssystems ausmacht. Dementsprechend wird der Wert des IS und des gesamten IS-Komplexes durch den Wert der Eingabe- und Ausgabedaten bestimmt.
Vor diesem Hintergrund muss das Design beginnen und datengesteuert sein und Architektur und Methoden an die Struktur und Bedeutung der Daten anpassen.
Gespeicherte Daten
Ein wichtiger Schritt bei der Vorbereitung des Entwurfs besteht darin, die Eigenschaften aller zur Verarbeitung und Speicherung geplanten Datensätze zu ermitteln. Zu diesen Merkmalen gehören:
- Datenvolumen;
— Informationen über den Lebenszyklus von Daten (Wachstum neuer Daten, Lebensdauer, Verarbeitung veralteter Daten);
— Klassifizierung von Daten aus Sicht Auswirkungen auf das Kerngeschäft des Unternehmens (den Dreiklang aus Vertraulichkeit, Integrität, Verfügbarkeit) sowie auf Finanzindikatoren (z. B. die Kosten für Datenverluste in der letzten Stunde);
— Geographie der Datenverarbeitung (physischer Standort der Verarbeitungssysteme);
– Regulatorische Anforderungen für jede Datenklasse (z. B. Bundesgesetz 152, PCI DSS).
Informationssysteme
Daten werden von Informationssystemen nicht nur gespeichert, sondern auch verarbeitet (transformiert). Der nächste Schritt nach Erhalt der Datenmerkmale ist die vollständigste Bestandsaufnahme von Informationssystemen, ihren architektonischen Merkmalen, gegenseitigen Abhängigkeiten und Infrastrukturanforderungen in konventionellen Einheiten für vier Arten von Ressourcen:
— Rechenleistung des Prozessors;
- Menge an RAM;
— Anforderungen an das Volumen und die Leistung des Datenspeichersystems;
— Anforderungen an das Datenübertragungsnetz (externe Kanäle, Kanäle zwischen IS-Komponenten).
In diesem Fall müssen für jeden Dienst/Microservice Anforderungen im Rahmen des IS vorhanden sein.
Unabhängig davon ist zu beachten, dass für eine korrekte Gestaltung die Verfügbarkeit von Daten über die Auswirkungen des IS auf das Kerngeschäft des Unternehmens in Form der Kosten für IS-Ausfallzeiten (Rubel pro Stunde) zwingend erforderlich ist.
Bedrohungsmodell
Es muss ein formelles Modell der Bedrohungen vorhanden sein, vor denen Daten/Dienste geschützt werden sollen. Darüber hinaus umfasst das Bedrohungsmodell nicht nur Aspekte der Vertraulichkeit, sondern auch der Integrität und Verfügbarkeit. Diese. Zum Beispiel:
— Ausfall des physischen Servers;
– Ausfall des Top-of-the-Rack-Switches;
— Unterbrechung des optischen Kommunikationskanals zwischen Rechenzentren;
— Ausfall des gesamten operativen Speichersystems.
In einigen Fällen werden Bedrohungsmodelle nicht nur für Infrastrukturkomponenten geschrieben, sondern auch für bestimmte Informationssysteme oder deren Komponenten, beispielsweise ein DBMS-Ausfall mit logischer Zerstörung der Datenstruktur.
Alle Entscheidungen innerhalb des Projekts zum Schutz vor einer unbeschriebenen Bedrohung sind unnötig.
Regulatorischen Anforderungen
Wenn die verarbeiteten Daten besonderen, von den Aufsichtsbehörden festgelegten Regeln unterliegen, sind Informationen über Datensätze und Verarbeitungs-/Speicherregeln erforderlich.
RPO/RTO-Ziele
Für die Gestaltung jeglicher Art von Schutz müssen für jede der beschriebenen Bedrohungen Zielindikatoren für Datenverlust und eine Zielwiederherstellungszeit für Dienste vorhanden sein.
Im Idealfall sollten RPO und RTO mit Kosten für Datenverlust und Ausfallzeiten pro Zeiteinheit verbunden sein.
Aufteilung in Ressourcenpools
Nach dem Sammeln aller anfänglichen Eingabeinformationen besteht der erste Schritt darin, Datensätze und IP basierend auf Bedrohungsmodellen und regulatorischen Anforderungen in Pools zu gruppieren. Die Art der Aufteilung verschiedener Pools wird festgelegt – programmgesteuert auf Systemsoftwareebene oder physisch.
Beispiele:
— Der Kreis, der personenbezogene Daten verarbeitet, ist vollständig physisch von anderen Systemen getrennt;
— Backups werden auf einem separaten Speichersystem gespeichert.
In diesem Fall können die Pools unvollständig unabhängig sein, es werden beispielsweise zwei Pools von Rechenressourcen definiert (Prozessorleistung + RAM), die einen einzigen Datenspeicherpool und einen einzigen Datenübertragungsressourcenpool nutzen.
Rechenleistung
Kurz gesagt, der Rechenleistungsbedarf eines virtualisierten Rechenzentrums wird anhand der Anzahl virtueller Prozessoren (vCPUs) und deren Konsolidierungsverhältnis auf physischen Prozessoren (pCPU) gemessen. In diesem speziellen Fall ist 1 pCPU = 1 physischer Prozessorkern (ohne Hyper-Threading). Die Anzahl der vCPUs wird über alle definierten Ressourcenpools summiert (von denen jeder seinen eigenen Konsolidierungsfaktor haben kann).
Der Konsolidierungskoeffizient für belastete Systeme wird empirisch, basierend auf der vorhandenen Infrastruktur oder durch Pilotinstallationen und Lasttests ermittelt. Bei unbelasteten Systemen kommt „Best Practice“ zum Einsatz. Konkret gibt VMware das durchschnittliche Verhältnis mit 8:1 an.
Rom
Der gesamte RAM-Bedarf ergibt sich durch einfache Summation. Die Verwendung einer RAM-Überbelegung wird nicht empfohlen.
Speicherressourcen
Der Speicherbedarf wird ermittelt, indem einfach alle Pools nach Kapazität und Leistung summiert werden.
Leistungsanforderungen werden in IOPS ausgedrückt, kombiniert mit einem durchschnittlichen Lese-/Schreibverhältnis und, falls erforderlich, einer maximalen Antwortlatenz.
Quality of Service (QoS)-Anforderungen für bestimmte Pools oder Systeme müssen separat angegeben werden.
Datennetzwerkressourcen
Die Datennetzwerkanforderungen werden durch einfache Summierung aller Bandbreitenpools ermittelt.
Anforderungen an Servicequalität (QoS) und Latenz (RTT) für bestimmte Pools oder Systeme sollten separat angegeben werden.
Im Rahmen der Anforderungen an Datennetzwerkressourcen werden auch Anforderungen an die Isolierung und/oder Verschlüsselung des Netzwerkverkehrs und bevorzugte Mechanismen (802.1q, IPSec usw.) angegeben.
Architekturauswahl
In diesem Leitfaden werden keine anderen Optionen als die x86-Architektur und die 100-prozentige Servervirtualisierung besprochen. Daher hängt die Wahl der Architektur des Computersubsystems von der Wahl der Servervirtualisierungsplattform, dem Serverformfaktor und den allgemeinen Serverkonfigurationsanforderungen ab.
Der entscheidende Punkt bei der Wahl ist die Gewissheit, einen klassischen Ansatz mit getrennten Funktionen der Verarbeitung, Speicherung und Übertragung von Daten oder einen konvergenten Ansatz zu verwenden.
klassische Architektur beinhaltet den Einsatz intelligenter externer Subsysteme zum Speichern und Übertragen von Daten, während Server nur Rechenleistung und RAM zum gemeinsamen Pool physischer Ressourcen beitragen. Im Extremfall werden Server völlig anonym und verfügen nicht nur über eigene Festplatten, sondern nicht einmal über eine Systemkennung. In diesem Fall wird das Betriebssystem bzw. der Hypervisor vom eingebauten Flash-Medium oder von einem externen Datenspeichersystem geladen (Booten vom SAN).
Im Rahmen der klassischen Architektur erfolgt die Wahl zwischen Blades und Racks vor allem nach folgenden Grundsätzen:
— Kostengünstig (im Durchschnitt sind Rack-Server günstiger);
— Rechendichte (höher für Blades);
— Energieverbrauch und Wärmeableitung (Blätter haben eine höhere spezifische Einheit pro Einheit);
— Skalierbarkeit und Steuerbarkeit (Blades erfordern im Allgemeinen weniger Aufwand für große Installationen);
- Verwendung von Erweiterungskarten (sehr begrenzte Auswahl für Blades).
Konvergente Architektur (auch bekannt als hyperkonvergent) beinhaltet die Kombination der Funktionen Datenverarbeitung und -speicherung, was zum Einsatz lokaler Serverplatten und damit zur Abkehr vom klassischen Blade-Formfaktor führt. Bei konvergenten Systemen kommen entweder Rack-Server oder Cluster-Systeme zum Einsatz, die mehrere Blade-Server und lokale Festplatten in einem Gehäuse vereinen.
CPU/Speicher
Um die Konfiguration korrekt zu berechnen, müssen Sie die Art der Belastung für die Umgebung oder jeden der unabhängigen Cluster verstehen.
CPU gebunden – eine Umgebung, deren Leistung durch die Prozessorleistung begrenzt ist. An der Leistung (Anzahl der VMs pro Server) ändert sich durch das Hinzufügen von RAM nichts.
Speicher gebunden – Umgebung durch RAM begrenzt. Durch mehr RAM auf dem Server können Sie mehr VMs auf dem Server ausführen.
GB / MHz (GB / pCPU) – das durchschnittliche Verhältnis des RAM-Verbrauchs und der Prozessorleistung bei dieser bestimmten Last. Kann verwendet werden, um die erforderliche Speichermenge für eine bestimmte Leistung zu berechnen und umgekehrt.
Berechnung der Serverkonfiguration
Zunächst müssen Sie alle Lastarten ermitteln und entscheiden, ob Sie verschiedene Rechenpools zu verschiedenen Clustern zusammenfassen oder aufteilen möchten.
Als nächstes wird für jeden der definierten Cluster das GB/MHz-Verhältnis bei einer im Voraus bekannten Last bestimmt. Wenn die Auslastung nicht im Voraus bekannt ist, aber ein grobes Verständnis über den Grad der Prozessorleistungsauslastung besteht, können Sie Standard-vCPU:pCPU-Verhältnisse verwenden, um Poolanforderungen in physische umzuwandeln.
Teilen Sie für jeden Cluster die Summe der vCPU-Poolanforderungen durch den Koeffizienten:
vCPUsum / vCPU:pCPU = pCPUsum – erforderliche Anzahl physischer Einheiten. Kerne
pCPUsum / 1.25 = pCPUht – Anzahl der Kerne angepasst für Hyper-Threading
Nehmen wir an, dass ein Cluster mit 190 Kernen / 3.5 TB RAM berechnet werden muss. Gleichzeitig akzeptieren wir eine Zielauslastung von 50 % der Prozessorleistung und 75 % des Arbeitsspeichers.
pCPU
190
CPU-Auslastung
50%
Mem
3500
Mem-Dienstprogramm
75%
Buchse
Kernbereich
Srv/CPU
Srv Mem
Srv/Mem
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 das Aufrunden auf die nächste ganze Zahl (=ROUNDUP(A1;0)).
Aus der Tabelle wird deutlich, dass mehrere Serverkonfigurationen hinsichtlich der Zielindikatoren ausgewogen sind:
— 26 Server 2*6c / 192 GB
— 19 Server 2*10c / 256 GB
— 10 Server 2*18c / 512 GB
Die Auswahl dieser Konfigurationen muss dann auf der Grundlage zusätzlicher Faktoren getroffen werden, wie z. B. Wärmepaket und verfügbare Kühlung, bereits verwendete Server oder Kosten.
Funktionen zur Auswahl einer Serverkonfiguration
Breite VMs. Wenn es erforderlich ist, große VMs zu hosten (vergleichbar mit einem NUMA-Knoten oder mehr), wird empfohlen, wenn möglich, einen Server mit einer Konfiguration auszuwählen, die es ermöglicht, dass solche VMs innerhalb des NUMA-Knotens verbleiben. Bei einer großen Anzahl breiter VMs besteht die Gefahr einer Fragmentierung der Clusterressourcen. In diesem Fall werden Server ausgewählt, die eine möglichst dichte Platzierung breiter VMs ermöglichen.
Größe der Einzelfehlerdomäne.
Auch die Wahl der Servergröße basiert auf dem Prinzip der Minimierung der Einzelfehlerdomäne. Zum Beispiel bei der Wahl zwischen:
— 3 x 4*10c / 512 GB
— 6 x 2*10c / 256 GB
Wenn alle anderen Bedingungen gleich sind, müssen Sie die zweite Option wählen, da beim Ausfall eines Servers (oder bei der Wartung) nicht 33 %, sondern 17 % der Clusterressourcen verloren gehen. Ebenso halbiert sich die Zahl der vom Unfall betroffenen VMs und ISs.
Berechnung klassischer Speichersysteme nach Leistung
Klassische Speichersysteme werden immer mit dem Worst-Case-Szenario berechnet, ohne den Einfluss des Betriebscaches und der Betriebsoptimierung.
Als grundlegende Leistungsindikatoren nehmen wir die mechanische Leistung der Festplatte (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS
Als nächstes wird die Anzahl der Festplatten im Festplattenpool anhand der folgenden Formel berechnet: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Wo:
- GesamtIOPS – insgesamt erforderliche Leistung in IOPS aus dem Festplattenpool
- RW – Prozentsatz der Lesevorgänge
- RAID-Stift – RAID-Strafe für den ausgewählten RAID-Level
Lesen Sie hier mehr über Geräte-RAID und RAID-Strafe – и и
Basierend auf der resultierenden Anzahl an Festplatten werden mögliche Optionen berechnet, die den Anforderungen an die Speicherkapazität entsprechen, einschließlich Optionen mit mehrstufiger Speicherung.
Die Berechnung von Systemen mit SSD als Speicherschicht wird gesondert betrachtet.
Funktionen zur Berechnung von Systemen mit Flash-Cache
Flash-Cache – ein gebräuchlicher Name für alle proprietären Technologien zur Nutzung von Flash-Speicher als Second-Level-Cache. Bei der Verwendung eines Flash-Cache ist das Speichersystem normalerweise so ausgelegt, dass es eine konstante Last von Magnetplatten bereitstellt, während die Spitzenlast vom Cache abgedeckt wird.
In diesem Fall ist es notwendig, das Lastprofil und den Grad der Lokalisierung des Zugriffs auf Blöcke von Speichervolumina zu verstehen. Flash-Cache ist eine Technologie für Workloads mit stark lokalisierten Abfragen und praktisch nicht für gleichmäßig geladene Volumes (z. B. für Analysesysteme) anwendbar.
Berechnung von Low-End-/Midrange-Hybridsystemen
Hybridsysteme der unteren und mittleren Klassen verwenden mehrstufige Speicherung, wobei Daten nach einem Zeitplan zwischen den Ebenen verschoben werden. Gleichzeitig beträgt die Größe des mehrstufigen Speicherblocks bei den besten Modellen 256 MB. Diese Merkmale erlauben es uns nicht, die Tiered-Storage-Technologie als Technologie zur Steigerung der Produktivität zu betrachten, wie viele Menschen fälschlicherweise glauben. Die Mehrebenenspeicherung in Systemen der unteren und mittleren Klasse ist eine Technologie zur Optimierung der Speicherkosten für Systeme mit ausgeprägter Lastungleichmäßigkeit.
Bei mehrstufigem Speicher wird zuerst die Leistung des obersten Tiers berechnet, während davon ausgegangen wird, dass das unterste Tier nur zur fehlenden Speicherkapazität beiträgt. Bei einem hybriden Multi-Tier-System ist es zwingend erforderlich, Flash-Cache-Technologie für den Multi-Tier-Pool zu verwenden, um den Leistungsabfall durch plötzlich erhitzte Daten aus der unteren Ebene auszugleichen.
Verwendung einer SSD in einem mehrstufigen Festplattenpool
Die Verwendung von SSDs in einem mehrstufigen Festplattenpool variiert je nach der spezifischen Implementierung von Flash-Cache-Algorithmen durch einen bestimmten Hersteller.
Die allgemeine Speicherrichtlinie für einen Festplattenpool mit SSD-Ebene lautet „SSD zuerst“.
Nur-Lese-Flash-Cache. Bei einem schreibgeschützten Flash-Cache ist die Speicherschicht auf der SSD unabhängig vom Cache mit einer erheblichen Lokalisierung der Schreibvorgänge verbunden.
Flash-Cache lesen/schreiben. Beim Flash-Cache wird die Schreib-Cache-Größe zunächst auf die maximale Cache-Größe eingestellt und die SSD-Speicherebene wird nur angezeigt, wenn die Cache-Größe nicht ausreicht, um die gesamte lokalisierte Arbeitslast zu bedienen.
Die Berechnungen der SSD- und Cache-Leistung basieren jedes Mal auf den Empfehlungen des Herstellers, beziehen sich jedoch immer auf das Worst-Case-Szenario.
Source: habr.com