{"id":35800,"date":"2019-10-31T22:06:24","date_gmt":"2019-10-31T19:06:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/dizajn-virtualizovannogo-tsod\/"},"modified":"2019-10-31T22:06:24","modified_gmt":"2019-10-31T19:06:24","slug":"dizajn-virtualizovannogo-tsod","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","title":{"rendered":"Design eines virtualisierten Rechenzentrums","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Design
\n
\nEinf\u00fchrung<\/b><\/p>\n

Ein Informationssystem wird aus der Sicht des Nutzers gut im GOST RV 51987 definiert \u2013 \u201eeine automatisierte System, dessen Ergebnis die Pr\u00e4sentation von Ausgangsinformationen zur weiteren Verwendung ist\u201c. Betrachtet man jedoch die interne Struktur, so ist im Kern jedes Informationssystem ein System von in Code umgesetzten verkn\u00fcpften Algorithmen. In einem weiten Sinne f\u00fchrt das Turing-Church-Theorem dazu, dass ein Algorithmus (und damit das Informationssystem) eine Transformation einer Vielzahl von Eingabedaten in eine Vielzahl von Ausgabedaten vornimmt.
\nMan 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.
\nAuf 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.<\/p>\n

Gespeicherte Daten<\/b>
\nEin entscheidender Schritt bei der Vorbereitung des Designs ist die Erfassung der Merkmale aller Datens\u00e4tze, die verarbeitet und gespeichert werden sollen. Diese Merkmale umfassen:
\n \u2014 Datenvolumen;
\n \u2014 Informationen \u00fcber den Lebenszyklus von Daten (Zuwachs neuer Daten, Lebensdauer, Verarbeitung veralteter Daten);
\n \u2014 Klassifizierung von Daten unter dem Gesichtspunkt ihrer Auswirkungen auf das Kerngesch\u00e4ft des Unternehmens (unter Ber\u00fccksichtigung der Triade Datenschutz, Integrit\u00e4t, Verf\u00fcgbarkeit) sowie der finanziellen Kennzahlen (z. B. Kosteneinbu\u00dfen durch Datenverlust in der letzten Stunde);
\n \u2014 Geographie der Datenverarbeitung (physische Standorte der Verarbeitungssysteme);
\n \u2014 Anforderungen der Regulierungsbeh\u00f6rden f\u00fcr jede Datenklasse (z. B. FZ-152, PCI DSS).<\/p>\n

<\/a><\/noindex><\/p>\n

Informationssysteme<\/b><\/p>\n

Daten werden nicht nur gespeichert, sondern auch durch Informationssysteme verarbeitet (transformiert). Der n\u00e4chste Schritt nach der Erfassung der Dateneigenschaften besteht darin, eine m\u00f6glichst vollst\u00e4ndige Inventarisierung der Informationssysteme, ihrer architektonischen Besonderheiten, Abh\u00e4ngigkeiten und Infrastrukturanforderungen in relativen Einheiten f\u00fcr vier Arten von Ressourcen durchzuf\u00fchren:
\n \u2014 Rechenleistung des Prozessors;
\n \u2014 Gr\u00f6\u00dfe des Arbeitsspeichers;
\n \u2014 Anforderungen an Kapazit\u00e4t und Leistung des Speichersystems;
\n \u2014 Anforderungen an das Daten\u00fcbertragungsnetz (externe Kan\u00e4le, Verbindungen zwischen den Komponenten der IS).
\nDie Anforderungen m\u00fcssen f\u00fcr jeden Service\/Mikroservice im Rahmen des Informationssystems festgelegt werden.
\nEs ist wichtig, dass zur korrekten Planung Daten \u00fcber die Auswirkungen des Informationssystems auf das Hauptgesch\u00e4ft des Unternehmens in Form von Kosten f\u00fcr Ausfallzeiten des Systems (in Rubel pro Stunde) vorliegen.<\/p>\n

Bedrohungsmodell<\/b><\/p>\n

Es muss unbedingt ein formales Bedrohungsmodell vorhanden sein, gegen das die Daten\/Services gesch\u00fctzt werden sollen. Dieses Bedrohungsmodell umfasst nicht nur Aspekte der Vertraulichkeit, sondern auch der Integrit\u00e4t und Verf\u00fcgbarkeit. Zum Beispiel:
\n \u2014 Ausfall eines physischen Servers;
\n \u2014 Ausfall eines Top-of-the-Rack-Switches;
\n \u2014 Unterbrechung des optischen Kommunikationskanals zwischen den Rechenzentren;
\n \u2014 Komplettausfall des operativen SAN.
\nIn einigen F\u00e4llen werden Bedrohungsmodelle nicht nur f\u00fcr infrastrukturelle Komponenten, sondern auch f\u00fcr spezifische Informationssysteme oder deren Komponenten erstellt, wie beispielsweise der Ausfall einer Datenbank mit logischer Zerst\u00f6rung der Datenstruktur.
\nAlle Entscheidungen im Rahmen des Projekts zum Schutz gegen nicht beschriebene Bedrohungen sind \u00fcberfl\u00fcssig.<\/p>\n

Vorgaben der Regulierungsbeh\u00f6rden<\/b><\/p>\n

Wenn die verarbeiteten Daten unter spezielle Vorschriften fallen, die von den Regulierungsbeh\u00f6rden festgelegt werden, ist unbedingt Informationen \u00fcber Datens\u00e4tze und die Regeln f\u00fcr deren Verarbeitung\/Speicherung erforderlich.<\/p>\n

Zielwerte RPO \/ RTO<\/b><\/p>\n

Die Planung jeder Art von Schutz erfordert Zielwerte f\u00fcr den potenziellen Datenverlust und die Wiederherstellungszeit f\u00fcr jeden der beschriebenen Bedrohungen.
\nIdealerweise sollten RPO und RTO mit den assoziierten Kosten f\u00fcr Datenverluste und Ausfallzeiten pro Zeiteinheit verbunden sein.<\/p>\n

\"Design
\n
\nRessourcenteilung<\/b><\/p>\n

Nach der Sammlung aller grundlegenden Informationen besteht der erste Schritt darin, Datens\u00e4tze und Informationssysteme in Pools zu gruppieren, basierend auf Bedrohungsmodellen und regulatorischen Anforderungen. Es wird bestimmt, welchen Typ der Trennung der verschiedenen Pools es gibt \u2013 softwarebasiert auf der Ebene der Systemsoftware oder physisch.
\nBeispiele:
\n \u2014 Der Bereich, der personenbezogene Daten verarbeitet, ist vollst\u00e4ndig physisch von den anderen Systemen getrennt;
\n \u2014 Backups werden auf einem separaten Speichersystem gespeichert.<\/p>\n

Die Pools k\u00f6nnen mit teilweiser Unabh\u00e4ngigkeit betrieben werden, zum Beispiel werden zwei Pools von Rechenressourcen (CPU-Leistung + Arbeitsspeicher) definiert, die einen gemeinsamen Pool von Datenspeicher und einen gemeinsamen Pool von \u00dcbertragungsressourcen nutzen.<\/p>\n

CPU-Leistung<\/b><\/p>\n

\"Design
\n
\nDer 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\u00fccksichtigung von Hyper-Threading). Die Anzahl der vCPUs wird \u00fcber alle definierten Ressourcensets summiert (von denen jedes einen eigenen Konsolidierungsfaktor haben kann).
\nDer Konsolidierungsfaktor f\u00fcr belastete Systeme wird empirisch bestimmt, basierend auf der bestehenden Infrastruktur oder w\u00e4hrend einer Pilotinstallation und Lasttests. F\u00fcr unbelastete Systeme gelten 'Best Practices'. VMware gibt beispielsweise einen durchschnittlichen Konsolidierungsfaktor von 8:1 an.<\/p>\n

Arbeitsspeicher<\/b><\/p>\n

Der Gesamtbedarf an Arbeitsspeicher ergibt sich durch einfache Summation. Die Verwendung von Overcommitment bei Arbeitsspeicher wird nicht empfohlen.<\/p>\n

Speicherressourcen<\/b><\/p>\n

Die Anforderungen an die Speicherressourcen ergeben sich aus der einfachen Summe aller Pools hinsichtlich Kapazit\u00e4t und Leistung.
\nDie Leistungsanforderungen werden in IOPS angegeben, unter Ber\u00fccksichtigung des durchschnittlichen Verh\u00e4ltnisses von Lese- zu Schreibvorg\u00e4ngen sowie gegebenenfalls der maximalen Latenzzeit.
\nDie Anforderungen an die Servicequalit\u00e4t (QoS) m\u00fcssen separat f\u00fcr spezifische Pools oder Systeme angegeben werden.<\/p>\n

Netzwerkressourcen<\/b><\/p>\n

Die Anforderungen an die Netzwerkressourcen ergeben sich aus der einfachen Summe aller Bandbreitenpools.
\nDie Anforderungen an die Servicequalit\u00e4t (QoS) und Latenzen (RTT) m\u00fcssen separat f\u00fcr spezifische Pools oder Systeme angegeben werden.
\nIm Rahmen der Anforderungen an die Netzwerkressourcen m\u00fcssen auch die Anforderungen an die Isolation und\/oder Verschl\u00fcsselung des Netzwerkverkehrs sowie die bevorzugten Mechanismen (802.1q, IPSec usw.) angegeben werden.<\/p>\n

Architekturwahl<\/b><\/p>\n

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.<\/p>\n

Ein entscheidender Aspekt bei der Wahl ist die Klarheit dar\u00fcber, ob der klassische Ansatz mit Trennung von Datenverarbeitung, -speicherung und -\u00fcbertragung oder ein konvergenter Ansatz verfolgt wird.<\/p>\n

Klassische Architektur<\/i> Dieser Ansatz impliziert die Nutzung intelligenter externer Systeme f\u00fcr die Speicherung und \u00dcbertragung von Daten, w\u00e4hrend die Server lediglich Rechenleistung und RAM in den gemeinsamen Pool physischer Ressourcen einbringen. Im Extremfall werden die Server vollst\u00e4ndig anonym, ohne eigene Festplatten oder sogar eine Systemidentifikation. In diesem Fall erfolgt das Booten des Betriebssystems oder Hypervisors von integrierten Flash-Speicherger\u00e4ten oder einem externen Speichersystem (boot from SAN).
\nIm Rahmen der klassischen Architektur erfolgt die Wahl zwischen Blade- und Rack-Servern in erster Linie nach den folgenden Prinzipien:
\n \u2014 Wirtschaftlichkeit (Rack-Server sind in der Regel g\u00fcnstiger);
\n \u2014 Rechenkapazit\u00e4t (Blade-Server haben eine h\u00f6here Dichte);
\n \u2014 Energieverbrauch und W\u00e4rmeentwicklung (bei Blade-Servern ist der spezifische Verbrauch pro Einheit h\u00f6her);
\n \u2014 Skalierbarkeit und Verwaltung (Blade-Server erfordern insgesamt weniger Aufwand bei gro\u00dfen Installationen);
\n \u2014 Verwendung von Erweiterungskarten (bei Blade-Servern ist die Auswahl stark eingeschr\u00e4nkt).
\nKonvergente Architektur<\/i> (auch bekannt als hyperkonvergent<\/i>) vereint die Funktionen der Datenverarbeitung und Datenspeicherung, was zur Nutzung lokaler Festplatten in Servern f\u00fchrt und somit den Formfaktor klassischer Blade-Server obsolet macht. F\u00fcr konvergente Systeme werden entweder Rack-Server oder Cluster-Systeme verwendet, die mehrere Blade-Server und lokale Festplatten in einem Geh\u00e4use kombinieren.<\/p>\n

CPU \/ RAM <\/b><\/p>\n

Um die Konfiguration korrekt zu berechnen, muss der Typ der Belastung f\u00fcr die Umgebung oder jeden unabh\u00e4ngigen Cluster verstanden werden.
\nCPU-bound<\/i> \u2013 eine Umgebung, die durch die Rechenleistung des Prozessors begrenzt ist. Das Hinzuf\u00fcgen von Arbeitsspeicher hat keinen Einfluss auf die Leistung (Anzahl der VMs auf dem Server).
\nMemory-bound<\/i> \u2013 eine Umgebung mit begrenztem Arbeitsspeicher. Mehr Arbeitsspeicher auf dem Server erm\u00f6glicht den Betrieb einer gr\u00f6\u00dferen Anzahl von VMs auf dem Server.
\nGB \/ MHz (GB \/ pCPU) \u2013 das durchschnittliche Verh\u00e4ltnis des Arbeitsspeicher- und CPU-Verbrauchs dieser speziellen Last. Dies kann verwendet werden, um den erforderlichen Speicherbedarf bei gegebener Leistung zu berechnen und umgekehrt. <\/p>\n

Berechnung der Serverkonfiguration<\/b><\/p>\n

\"Design
\n
\nZun\u00e4chst m\u00fcssen alle Arten von Lasten bestimmt und eine Entscheidung \u00fcber die Kombination oder Trennung verschiedener Rechen-Pools in verschiedene Cluster getroffen werden.
\nAnschlie\u00dfend wird f\u00fcr jeden definierten Cluster das Verh\u00e4ltnis von GB \/ MHz bei bekannter Last festgelegt. Wenn die Last nicht im Voraus bekannt ist, aber ein ungef\u00e4hres Verst\u00e4ndnis der Auslastung der CPU-Leistung besteht, k\u00f6nnen Standardverh\u00e4ltnisse von vCPU:pCPU verwendet werden, um die Anforderungen der Pools in physische Ressourcen zu \u00fcbertragen. <\/p>\n

F\u00fcr jeden Cluster teilen wir die Summe der Anforderungen der vCPU-Pools durch den Koeffizienten:
\nvCPU_sum \/ vCPU:pCPU = pCPU_sum \u2013 die erforderliche Anzahl physischer Kerne
\npCPU_sum \/ 1,25 = pCPU_ht \u2013 die Anzahl der Kerne unter Ber\u00fccksichtigung von Hyper-Threading
\nAngenommen, Sie m\u00fcssen einen Cluster mit 190 Kernen \/ 3,5 TB RAM berechnen. Dabei nehmen wir eine Zielauslastung von 50 % der Rechenleistung und 75 % des RAM an.<\/p>\n

pCPU<\/b>
\n190
\nCPU Auslastung<\/b>
\n50%<\/p>\n

RAM<\/b>
\n3500
\nRAM Auslastung<\/b>
\n75%<\/p>\n

Sockel<\/b>
\nKern<\/b>
\nSrv \/ CPU<\/b>
\nSrv RAM<\/b>
\nSrv \/ RAM<\/b><\/p>\n

2
\n6
\n25,3
\n128
\n36,5<\/p>\n

2
\n8
\n19,0
\n192
\n24,3<\/p>\n

2
\n10
\n15,2
\n256
\n18,2<\/p>\n

2
\n14
\n10,9
\n384
\n12,2<\/p>\n

2
\n18
\n8,4
\n512
\n9,1<\/p>\n

In diesem Fall verwenden wir immer die Aufrundung auf die n\u00e4chste ganze Zahl nach oben (=ROUNDUP(A1;0)).
\nAus der Tabelle geht deutlich hervor, dass mehrere Serverkonfigurationen f\u00fcr die Zielvorgaben ausgewogen sind:
\n \u2014 26 Server 2*6c \/ 192 GB
\n \u2014 19 Server 2*10c \/ 256 GB
\n \u2014 10 Server 2*18c \/ 512 GB <\/p>\n

Die Auswahl aus diesen Konfigurationen sollte in weiterer Folge auf Basis zus\u00e4tzlicher Faktoren getroffen werden, wie beispielsweise das thermische Paket und die verf\u00fcgbare K\u00fchlung, bereits eingesetzte Server oder die Kosten.<\/p>\n

Besonderheiten bei der Auswahl der Serverkonfiguration<\/b><\/p>\n

Gro\u00dfe VMs. Wenn es notwendig ist, gro\u00dfe VMs (vergleichbar mit 1 NUMA-Knoten und mehr) bereitzustellen, sollte nach M\u00f6glichkeit ein Server gew\u00e4hlt werden, dessen Konfiguration es erm\u00f6glicht, diese VMs innerhalb eines NUMA-Knotens zu belassen. Bei einer gro\u00dfen Anzahl von gro\u00dfen VMs besteht die Gefahr der Fragmentierung der Clusterressourcen, und in diesem Fall sollten Server ausgew\u00e4hlt werden, die es erm\u00f6glichen, gro\u00dfe VMs m\u00f6glichst dicht zu platzieren.<\/p>\n

Die Gr\u00f6\u00dfe der Single Point of Failure-Dom\u00e4ne.<\/b> <\/p>\n

Die Auswahl der Servergr\u00f6\u00dfe erfolgt ebenfalls unter dem Prinzip der Minimierung der Single Point of Failure-Dom\u00e4ne. Beispielsweise bei der Wahl zwischen:
\n \u2014 3 x 4*10c \/ 512 GB
\n \u2014 6 x 2*10c \/ 256 GB
\nBei sonst gleichen Bedingungen sollte die zweite Option gew\u00e4hlt 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.<\/p>\n

Berechnung der klassischen SAN-Leistung<\/b><\/p>\n

\"Design
\n
\nDie klassische SAN wird immer nach dem ung\u00fcnstigsten Szenario (worst case scenario) berechnet, wobei der Einfluss des operativen Caches und der Optimierung von Operationen ausgeschlossen ist.
\nAls Basisindikatoren der Leistung verwenden wir die mechanische Leistung von der Festplatte (IOPSdisk):
\n \u2014 7.2k \u2013 75 IOPS
\n \u2014 10k \u2013 125 IOPS
\n \u2014 15k \u2013 175 IOPS<\/p>\n

Anschlie\u00dfend wird die Anzahl der Festplatten im Festplattenspeicher nach folgender Formel berechnet: = TotalIOPS * ( RW + (1 \u2013RW) * RAIDPen) \/ IOPSdisk<\/i>. Wo:
\n \u2014 TotalIOPS<\/i> \u2013 die insgesamt erforderliche Leistung in IOPS aus der Festplattenspeicher
\n \u2014 RW<\/i> \u2013 der prozentuale Anteil der Leseoperationen
\n \u2014 RAIDpen<\/i> \u2013 RAID-Strafe f\u00fcr das gew\u00e4hlte RAID-Level<\/p>\n

Hier erfahren Sie mehr \u00fcber RAID-Ger\u00e4te und RAID-Strafen — Leistung von Speicherl\u00f6sungen. Teil eins.<\/a><\/noindex> und Leistung von Speicherl\u00f6sungen. Teil zwei.<\/a><\/noindex> und Leistung von Speicherl\u00f6sungen. Teil drei.<\/a><\/noindex><\/p>\n

Basierend auf der Anzahl der erhaltenen Festplatten werden verschiedene Optionen berechnet, die den Anforderungen an die Speicherkapazit\u00e4t entsprechen, einschlie\u00dflich Optionen mit mehrstufiger Speicherung.
\nDie Berechnung von Systemen mit SSDs als Speicherebene wird separat betrachtet.
\nBesonderheiten bei der Berechnung von Systemen mit Flash Cache
\n<\/b><\/p>\n

Flash Cache<\/i> \u2013 ein Oberbegriff f\u00fcr alle propriet\u00e4ren Technologien zur Nutzung von Flash-Speicher als Level-2-Cache. Bei der Verwendung von Flash-Cache wird in der Regel die Belastung von herk\u00f6mmlichen Magnetfestplatten berechnet, w\u00e4hrend die Spitzenlast vom Cache abgedeckt wird.
\nDabei ist es wichtig, das Lastprofil und den Grad der Lokalisierung der Anfragen an die Speicher-Volumes zu verstehen. Flash-Caching ist eine Technologie f\u00fcr Lasten mit hoher Anfrage-Lokalisierung und ist praktisch nicht anwendbar f\u00fcr gleichm\u00e4\u00dfig belastete Volumes (wie zum Beispiel f\u00fcr Analysesysteme). <\/p>\n

Berechnung von hybriden Systemen der Einstiegsklasse \/ Mittelklasse<\/b><\/p>\n

Hybride Systeme der unteren und mittleren Klassen verwenden mehrschichtige Speicherung mit Datenverschiebungen zwischen den Ebenen nach einem Zeitplan. Dabei betr\u00e4gt die Blockgr\u00f6\u00dfe der mehrschichtigen Speicherung bei den besten Modellen 256 MB. Diese Merkmale lassen die Technologie der mehrschichtigen Speicherung nicht als Leistungssteigerungspipeline erscheinen, wie viele f\u00e4lschlicherweise annehmen. Mehrschichtige Speicherung in Systemen der unteren und mittleren Klassen ist eine Technologie zur Kostenoptimierung der Speicherung f\u00fcr Systeme mit ausgepr\u00e4gter Lastungsgleichm\u00e4\u00dfigkeit.<\/p>\n

Bei einer mehrstufigen Speicherung wird prim\u00e4r die Leistung der obersten Ebene ber\u00fccksichtigt, w\u00e4hrend die untere Speicherebene lediglich zur Bereitstellung zus\u00e4tzlicher Speicherkapazit\u00e4t dient. Der Einsatz von Flash-Cache-Technologie f\u00fcr den mehrstufigen Pool ist unerl\u00e4sslich, um Leistungseinbr\u00fcche bei pl\u00f6tzlichem Anstieg der Datenlast aus der unteren Ebene auszugleichen.<\/p>\n

Einsatz von SSD in einem mehrstufigen Speicherpool<\/b><\/p>\n

\"Design
\n
\nDer Einsatz von SSD in einem mehrstufigen Speicherpool variiert je nach den spezifischen Implementierungsdetails der Flash-Cache-Algorithmen des jeweiligen Herstellers.
\nDie g\u00e4ngige Praktik f\u00fcr Speicherrichtlinien in einem SSD-basierten Speicherpool lautet: SSD first.
\nRead-Only Flash-Cache.<\/i> Bei einem Read-Only Flash-Cache wird die SSD-Speicherebene aktiviert, sobald die Schreiboperationen erheblich lokalisiert sind, unabh\u00e4ngig vom Cache.
\nRead\/Write Flash-Cache.<\/i> Im Falle eines Write-Flash-Caches wird zun\u00e4chst das maximale Cache-Volumen festgelegt, und die SSD-Speicherebene wird nur aktiviert, wenn die Gr\u00f6\u00dfe des Caches nicht ausreicht, um die gesamte lokalisierten Last zu bew\u00e4ltigen.
\nDie Berechnung der SSD- und Cache-Leistung erfolgt stets basierend auf den Empfehlungen des Herstellers, jedoch immer f\u00fcr den ung\u00fcnstigsten Fall.
\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0441 \u0442\u043e\u0447\u043a\u0438 \u0437\u0440\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f \u0445\u043e\u0440\u043e\u0448\u043e \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u044f\u0435\u0442\u0441\u044f \u0432 \u0413\u041e\u0421\u0422 \u0420\u0412 51987 \u2014 \u00ab\u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u0440\u0435\u0437\u0443\u043b\u044c\u0442\u0430\u0442\u043e\u043c \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043a\u043e\u0442\u043e\u0440\u043e\u0439 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u0432\u044b\u0445\u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0434\u043b\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0435\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f\u00bb. \u0415\u0441\u043b\u0438 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0442\u044c \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u044e\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443, \u0442\u043e \u043f\u043e \u0441\u0443\u0442\u0438 \u043b\u044e\u0431\u0430\u044f \u0418\u0421 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439 \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0445 \u0432 \u043a\u043e\u0434\u0435 \u0432\u0437\u0430\u0438\u043c\u043e\u0441\u0432\u044f\u0437\u0430\u043d\u043d\u044b\u0445 \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c\u043e\u0432. \u0412 \u0448\u0438\u0440\u043e\u043a\u043e\u043c \u043f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0438 \u0442\u0435\u0437\u0438\u0441\u0430 \u0422\u044c\u044e\u0440\u0438\u043d\u0433\u0430-\u0427\u0435\u0440\u0447\u0430 \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c (\u0430 \u0441\u043b-\u043d\u043e \u0418\u0421) \u043e\u0441\u0443\u0449\u0435\u0441\u0442\u0432\u043b\u044f\u0435\u0442 \u0442\u0440\u0430\u043d\u0441\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044e \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0430 \u0432\u0445\u043e\u0434\u043d\u044b\u0445 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26806,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35800","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Design des virtualisierten Rechenzentrums | ProHoster","description":"Einf\u00fchrung. Ein Informationssystem wird aus der Perspektive des Benutzers gut durch GOST RV 51987 definiert \u2013 als \u201eautomatisiertes System, dessen Ergebnis die Bereitstellung von Ausgangsinformationen f\u00fcr die weitere Nutzung ist\u201c. Betrachtet man die interne Struktur, so ist im Grunde jedes IS ein System aus im Code verwirklichten miteinander verbundenen Algorithmen. Im weitesten Sinne f\u00fchrt der Turing-Church-Thesis Algorithmus (und damit das IS) eine Transformation einer Vielzahl von Eingaben durch.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u0438\u0437\u0430\u0439\u043d \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u043e\u0433\u043e \u0426\u041e\u0414 | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0441 \u0442\u043e\u0447\u043a\u0438 \u0437\u0440\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f \u0445\u043e\u0440\u043e\u0448\u043e \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u044f\u0435\u0442\u0441\u044f \u0432 \u0413\u041e\u0421\u0422 \u0420\u0412 51987 \u2014 \u00ab\u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u0440\u0435\u0437\u0443\u043b\u044c\u0442\u0430\u0442\u043e\u043c \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043a\u043e\u0442\u043e\u0440\u043e\u0439 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u0432\u044b\u0445\u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0434\u043b\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0435\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f\u00bb. \u0415\u0441\u043b\u0438 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0442\u044c \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u044e\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443, \u0442\u043e \u043f\u043e \u0441\u0443\u0442\u0438 \u043b\u044e\u0431\u0430\u044f \u0418\u0421 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439 \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0445 \u0432 \u043a\u043e\u0434\u0435 \u0432\u0437\u0430\u0438\u043c\u043e\u0441\u0432\u044f\u0437\u0430\u043d\u043d\u044b\u0445 \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c\u043e\u0432. \u0412 \u0448\u0438\u0440\u043e\u043a\u043e\u043c \u043f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0438 \u0442\u0435\u0437\u0438\u0441\u0430 \u0422\u044c\u044e\u0440\u0438\u043d\u0433\u0430-\u0427\u0435\u0440\u0447\u0430 \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c (\u0430 \u0441\u043b-\u043d\u043e \u0418\u0421) \u043e\u0441\u0443\u0449\u0435\u0441\u0442\u0432\u043b\u044f\u0435\u0442 \u0442\u0440\u0430\u043d\u0441\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044e \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0430 \u0432\u0445\u043e\u0434\u043d\u044b\u0445","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:06:24+00:00","article:modified_time":"2019-10-31T19:06:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35800","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 00:48:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:06:24","updated":"2026-01-22 00:48:20"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/35800","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=35800"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/35800\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/26806"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=35800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=35800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=35800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}