{"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 des virtualisierten Rechenzentrums","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

Das Informationssystem aus Sicht des Benutzers wird gut in GOST RV 51987 definiert \u2013 \u201eein automatisiertes System, dessen Funktion darin besteht, Ausgangsinformationen zur weiteren Nutzung bereitzustellen\u201c. Betrachtet man die interne Struktur, ist im Grunde jedes IS ein System von in Code umgesetzten miteinander verkn\u00fcpften Algorithmen. Im weitesten Sinne transformiert der Algorithmus (und entsprechend das IS) eine Menge von Eingabedaten in eine Menge von Ausgabedaten.
\nMan 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.
\nAus 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.<\/p>\n

Gespeicherte Daten<\/b>
\nEin entscheidender Schritt bei der Vorbereitung auf die Planung ist das Erfassen der Merkmale aller Datens\u00e4tze, die bearbeitet und gespeichert werden sollen. Diese Merkmale umfassen:
\n \u2014 Datenvolumen;
\n \u2014 Informationen \u00fcber den Lebenszyklus der Daten (Zuwachs neuer Daten, Lebensdauer, Verarbeitung veralteter Daten);
\n \u2014 Klassifizierung der Daten hinsichtlich ihres Einflusses auf das Hauptgesch\u00e4ft des Unternehmens (in der Triade von Vertraulichkeit, Integrit\u00e4t, Verf\u00fcgbarkeit) zusammen mit finanziellen Kennzahlen (z. B. die Kosten f\u00fcr den Verlust von Daten in der letzten Stunde);
\n \u2014 Geografie der Datenverarbeitung (physikalische Lage 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 von Informationssystemen verarbeitet (transformiert). Der n\u00e4chste Schritt nach dem Erfassen der Datenmerkmale ist eine m\u00f6glichst vollst\u00e4ndige Inventarisierung der Informationssysteme, ihrer architektonischen Besonderheiten, Abh\u00e4ngigkeiten und Infrastrukturvoraussetzungen in Einheitspreisen f\u00fcr vier Arten von Ressourcen:
\n \u2014 Rechnerische Prozessleistung;
\n \u2014 Volumen des Arbeitsspeichers;
\n \u2014 Anforderungen an Volumen und Leistungsf\u00e4higkeit des Datenspeichers;
\n \u2014 Anforderungen an das Datennetzwerk (externe Kan\u00e4le, Kan\u00e4le zwischen IS-Komponenten).
\nDie Anforderungen m\u00fcssen f\u00fcr jeden Dienst\/Mikrodienst im Rahmen des IS vorliegen.
\nEs ist besonders wichtig, dass f\u00fcr die korrekte Planung Daten \u00fcber den Einfluss des IS auf das Hauptgesch\u00e4ft des Unternehmens in Form der Kosten f\u00fcr Ausfallzeiten des IS (Rubel pro Stunde) vorliegen.<\/p>\n

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

Es muss zwingend ein formelles Bedrohungsmodell vorhanden sein, gegen das die Daten\/Dienste gesch\u00fctzt werden sollen. Dabei umfasst das Bedrohungsmodell nicht nur Aspekte der Vertraulichkeit, sondern auch der Integrit\u00e4t und Verf\u00fcgbarkeit. Das hei\u00dft zum Beispiel:
\n \u2014 Ausfall des physischen Servers;
\n \u2014 Ausfall des Top-of-the-Rack-Switches;
\n \u2014 Unterbrechung des optischen Kommunikationskanals zwischen den Rechenzentren;
\n \u2014 Totalausfall des laufenden Storage Systems.
\nIn einigen F\u00e4llen werden Bedrohungsmodelle nicht nur f\u00fcr infrastrukturelle Komponenten, sondern auch f\u00fcr spezifische IS oder deren Komponenten geschrieben, wie zum Beispiel der Ausfall der DBMS mit logischer Zerst\u00f6rung der Datenstruktur.
\nAlle Entscheidungen im Rahmen des Projekts zum Schutz vor nicht beschriebenen Bedrohungen sind \u00fcberfl\u00fcssig.<\/p>\n

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

Wenn die verarbeiteten Daten unter spezielle Regelungen fallen, die von Aufsichtsbeh\u00f6rden festgelegt werden, ist zwingend Informationen \u00fcber Datens\u00e4tze und die Regeln f\u00fcr Verarbeitung\/Speicherung erforderlich.<\/p>\n

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

Die Planung jeglicher Art von Schutz erfordert die Festlegung von Werten f\u00fcr den angestrebten Datenverlust und die angestrebte Wiederherstellungszeit des Dienstes f\u00fcr jede der beschriebenen Bedrohungen.
\nIdealerweise sollten RPO und RTO mit den entsprechenden Kosten f\u00fcr Datenverluste und Ausfallzeiten pro Zeiteinheit verbunden sein.<\/p>\n

\"Design
\n
\nAufteilung in Ressourcenpools<\/b><\/p>\n

Nach der Erhebung aller prim\u00e4ren Informationen ist der erste Schritt die Gruppierung von Datens\u00e4tzen und IS in Pools, basierend auf Bedrohungsmodellen und Anforderungen der Regulierungsbeh\u00f6rden. Es wird der Typ der Trennung der verschiedenen Pools festgelegt \u2013 programmatisch auf der Ebene der Systemsoftware oder physisch.
\nBeispiele:
\n \u2014 Der Rahmen, der personenbezogene Daten verarbeitet, ist vollst\u00e4ndig physisch von anderen Systemen getrennt;
\n \u2014 Backups werden auf einem separaten Storage-System gespeichert.<\/p>\n

Dabei k\u00f6nnen die Pools teilweise unabh\u00e4ngig sein, zum Beispiel werden zwei Pools von Rechenressourcen (Rechenleistung + Arbeitsspeicher) definiert, die einen gemeinsamen Datenspeicherpool und einen gemeinsamen Daten\u00fcbertragungspool nutzen.<\/p>\n

Rechenleistung<\/b><\/p>\n

\"Design
\n
\nDie abstrakten Anforderungen an die Verarbeitungsleistung eines virtualisierten Rechenzentrums werden in der Anzahl der virtuellen Prozessoren (vCPU) und dem Verh\u00e4ltnis 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 \u00fcber alle definierten Ressourcens\u00e4ulen hinweg summiert (jede kann ihren eigenen Konsolidierungsfaktor haben).
\nDer Konsolidierungsfaktor f\u00fcr stark belastete Systeme wird empirisch ermittelt, basierend auf der bereits bestehenden Infrastruktur oder w\u00e4hrend der Pilotinstallation und Lasttests. F\u00fcr unbelastete Systeme kommen \u201eBest Practices\u201c zur Anwendung. VMware nennt beispielsweise einen durchschnittlichen Konsolidierungsfaktor von 8:1.<\/p>\n

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

Der gesamte Speicherbedarf wird durch einfaches Summieren ermittelt. Die Verwendung von Overcommitment bei Arbeitsspeicher wird nicht empfohlen.<\/p>\n

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

Die Anforderungen an Speicherressourcen ergeben sich durch die einfache Addition aller Pools in Bezug auf Umfang und Leistung.
\nDie Leistungsanforderungen werden in IOPS ausgedr\u00fcckt, in Kombination mit dem durchschnittlichen Verh\u00e4ltnis von Lese- zu Schreibvorg\u00e4ngen und gegebenenfalls der maximalen Antwortzeit.
\nDie Anforderungen an die Qualit\u00e4t des Service (QoS) m\u00fcssen f\u00fcr spezifische Pools oder Systeme separat angegeben werden.<\/p>\n

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

Die Anforderungen an die Netzwerkressourcen werden durch die einfache Addition aller Pools in Bezug auf die Bandbreite ermittelt.
\nDie Anforderungen an die Qualit\u00e4t des Service (QoS) und die Latenz (RTT) m\u00fcssen f\u00fcr spezifische Pools oder Systeme separat angegeben werden.
\nIm Rahmen der Anforderungen an die Netzwerkressourcen m\u00fcssen auch Anforderungen an die Isolation und\/oder Verschl\u00fcsselung des Datenverkehrs sowie bevorzugte Mechanismen (802.1q, IPSec usw.) angegeben werden.<\/p>\n

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

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

Ein entscheidender Punkt bei der Wahl ist die Klarheit hinsichtlich der Verwendung des klassischen Ansatzes mit Trennung der Funktionen f\u00fcr Verarbeitung, Speicherung und Daten\u00fcbertragung oder des konvergenten Ansatzes.<\/p>\n

Klassische Architektur<\/i> bedeutet die Verwendung intelligenter externer Datenspeicher- und \u00dcbertragungssysteme, w\u00e4hrend die Server nur Rechenleistung und Arbeitsspeicher in den allgemeinen Pool physischer Ressourcen einbringen. Im Extremfall werden Server v\u00f6llig 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).
\nIm Rahmen der klassischen Architektur erfolgt die Wahl zwischen Blade- und Rack-Servern in erster Linie nach folgenden Prinzipien:
\n \u2014 Wirtschaftlichkeit (Rack-Server sind im Durchschnitt g\u00fcnstiger);
\n \u2014 Rechenkapazit\u00e4t (bei Blades h\u00f6her);
\n \u2014 Energieverbrauch und W\u00e4rmeabgabe (bei Blades h\u00f6her pro Einheit);
\n \u2014 Skalierbarkeit und Managebarkeit (Blades erfordern insgesamt weniger Aufwand bei gro\u00dfen Installationen);
\n \u2014 Verwendung von Erweiterungskarten (bei Blades sehr begrenzte Auswahl).
\nKonvergente Architektur<\/i> (auch bekannt als hyperkonvergent<\/i>) bedeutet die Kombination von Datenverarbeitungs- und Speicherfunktionen, was zur Nutzung von lokalen Festplatten der Server f\u00fchrt und folglich den Verzicht auf das Formfaktor klassischer Blades zur Folge hat. 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 \/ Arbeitsspeicher <\/b><\/p>\n

F\u00fcr die korrekte Berechnung der Konfiguration muss der Typ der Last f\u00fcr die Umgebung oder jeden der unabh\u00e4ngigen Cluster verstanden werden.
\nCPU bound<\/i> \u2013 Umgebung, die in der Leistung durch die Prozessorkapazit\u00e4t begrenzt ist. Die Hinzuf\u00fcgung von Arbeitsspeicher \u00e4ndert nichts an der Leistungsf\u00e4higkeit (Anzahl der VMs pro Server).
\nMemory bound<\/i> \u2013 Umgebung, die durch den Arbeitsspeicher begrenzt ist. Gr\u00f6\u00dfere Menge an Arbeitsspeicher auf dem Server erm\u00f6glicht das Starten einer gr\u00f6\u00dferen Anzahl von VMs auf dem Server.
\nGB \/ MHz (GB \/ pCPU) \u2013 das durchschnittliche Verh\u00e4ltnis des Verbrauchs ebendieser spezifischen Last von Arbeitsspeicher und Prozessorkapazit\u00e4t. Kann zur Berechnung des ben\u00f6tigten Speichervolumens bei gegebener Leistung und umgekehrt verwendet werden. <\/p>\n

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

\"Design
\n
\nZun\u00e4chst m\u00fcssen alle Arten von Lasten bestimmt und entschieden werden, ob verschiedene Berechnungspools innerhalb verschiedener Cluster kombiniert oder getrennt werden sollen.
\nAnschlie\u00dfend wird f\u00fcr jeden der bestimmten Cluster das Verh\u00e4ltnis von GB \/ MHz bei bekannter Last festgelegt. Wenn die Last nicht im Voraus bekannt ist, aber eine ungef\u00e4hre Vorstellung vom Auslastungsniveau der Rechenleistung besteht, k\u00f6nnen standardisierte Verh\u00e4ltnisse von vCPU:pCPU verwendet werden, um die Anforderungen der Pools in physische Ressourcen zu \u00fcbersetzen. <\/p>\n

F\u00fcr jeden Cluster teilen wir die Summe der Anforderungen der vCPU-Pools durch den Koeffizienten:
\nvCPUsumme \/ vCPU:pCPU = pCPUsumme \u2013 ben\u00f6tigte Anzahl physischer Kerne
\npCPUsumme \/ 1.25 = pCPUht \u2013 Anzahl der Kerne unter Ber\u00fccksichtigung des Hyper-Threadings
\nAngenommen, wir m\u00fcssen einen Cluster mit 190 Kernen \/ 3,5 TB RAM berechnen. Dabei nehmen wir eine Zielauslastung von 50 % f\u00fcr die Rechenleistung und 75 % f\u00fcr den RAM an.<\/p>\n

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

Mem<\/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 Rundung auf die n\u00e4chste ganze Zahl nach oben (=ROUNDUP(A1;0)).
\nAus der Tabelle wird offensichtlich, dass mehrere Serverkonfigurationen den Zielvorgaben entsprechen:
\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 basierend auf zus\u00e4tzlichen Faktoren erfolgen, wie zum Beispiel dem W\u00e4rmepaket und der verf\u00fcgbaren K\u00fchlung, bereits genutzten Servern oder den Kosten.<\/p>\n

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

Breite VMs. Bei der Notwendigkeit, breite VMs (vergleichbar mit 1 NUMA-Knoten und mehr) unterzubringen, wird empfohlen, nach M\u00f6glichkeit Server auszuw\u00e4hlen, die es diesen VMs erm\u00f6glichen, innerhalb eines NUMA-Knotens zu bleiben. Bei einer gro\u00dfen Anzahl von breiten VMs besteht die Gefahr der Fragmentierung der Clusterressourcen, und in diesem Fall werden Server ausgew\u00e4hlt, die eine m\u00f6glichst dichte Unterbringung breiter VMs erm\u00f6glichen.<\/p>\n

Gr\u00f6\u00dfe der Dom\u00e4ne einzelner Ausf\u00e4lle.<\/b> <\/p>\n

Die Auswahl der Servergr\u00f6\u00dfe erfolgt ebenfalls nach dem Prinzip der Minimierung der Dom\u00e4ne einzelner Ausf\u00e4lle. Zum Beispiel bei der Auswahl zwischen:
\n \u2014 3 x 4*10c \/ 512 GB
\n \u2014 6 x 2*10c \/ 256 GB
\nBei gleichbleibenden Bedingungen sollte die zweite Option gew\u00e4hlt werden, da beim Ausfall eines Servers (oder w\u00e4hrend 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.<\/p>\n

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

\"Design
\n
\nEine klassische SAN wird immer nach dem schlechtesten Szenario (worst case scenario) berechnet, wobei der Einfluss des Arbeitsspeichers und die Optimierung der Vorg\u00e4nge ausgeschlossen werden.
\nAls Basisleistungskennzahlen nehmen 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 mit der folgenden Formel berechnet: = TotalIOPS * ( RW + (1 \u2013RW) * RAIDPen) \/ IOPSdisk<\/i>. Wo:
\n \u2014 TotalIOPS<\/i> \u2013 die insgesamt ben\u00f6tigte Leistung in IOPS aus dem Festplattenspeicher
\n \u2014 RW<\/i> \u2013 der prozentuale Anteil der Lesevorg\u00e4nge
\n \u2014 RAIDpen<\/i> \u2013 RAID-Strafma\u00df f\u00fcr das gew\u00e4hlte RAID-Level<\/p>\n

Weitere Informationen \u00fcber RAID-Ger\u00e4te und RAID-Strafen finden Sie hier \u2014 Leistung der SAN. Teil eins.<\/a><\/noindex> und Leistung der SAN. Teil zwei.<\/a><\/noindex> und Leistung der SAN. Teil drei.<\/a><\/noindex><\/p>\n

Aus der erhaltenen Anzahl von Festplatten werden m\u00f6gliche Optionen berechnet, die den Anforderungen an die Speicherkapazit\u00e4t entsprechen, einschlie\u00dflich Optionen mit mehrstufiger Speicherung.
\nDie Berechnung von Systemen unter Verwendung von SSDs als Speicherebene wird gesondert betrachtet.
\nBesonderheiten der Berechnung von Systemen mit Flash Cache
\n<\/b><\/p>\n

Flash Cache<\/i> \u2013 ein allgemeiner Begriff f\u00fcr alle propriet\u00e4ren 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\u00e4hrend die Spitzenlast vom Cache bedient wird.
\nDabei ist es notwendig, das Lastprofil und das Ma\u00df der Lokalisation von Anfragen an die Speicherbl\u00f6cke zu verstehen. Flash-Cache ist eine Technologie f\u00fcr Arbeitslasten mit hoher Lokalisierung von Anfragen und ist nahezu nicht anwendbar f\u00fcr gleichm\u00e4\u00dfig belastete Volumes (wie beispielsweise bei Analysesystemen). <\/p>\n

Berechnung hybrider Systeme f\u00fcr den unteren \/ mittleren Markt<\/b><\/p>\n

Hybride Systeme der unteren und mittleren Klasse verwenden mehrstufige Speicherung mit einer Datenbewegung nach Zeitplan. Dabei betr\u00e4gt die Blockgr\u00f6\u00dfe 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\u00e4lschlicherweise annehmen. Die mehrstufige Speicherung in Systemen der unteren und mittleren Klasse ist eine Technologie zur Optimierung der Speicherkosten f\u00fcr Systeme mit ausgepr\u00e4gter ungleichm\u00e4\u00dfiger Last.<\/p>\n

Bei der mehrstufigen Speicherung wird in erster Linie die Leistung der obersten Ebene berechnet, w\u00e4hrend die untere Speicherebene lediglich als Erg\u00e4nzung zur fehlenden Speicherkapazit\u00e4t betrachtet wird. F\u00fcr hybride mehrstufige Systeme ist der Einsatz von Flash-Cache-Technologie f\u00fcr den mehrstufigen Pool unerl\u00e4sslich, um die Leistungseinbu\u00dfen bei pl\u00f6tzlich angeforderten Daten aus der unteren Ebene auszugleichen.<\/p>\n

Einsatz von SSDs in mehrstufigen Festplattenspeicher-Pools<\/b><\/p>\n

\"Design
\n
\nDer Einsatz von SSDs in mehrstufigen Festplattenspeicher-Pools variiert je nach den Besonderheiten der Implementierung von Flash-Cache-Algorithmen des jeweiligen Herstellers.
\nAllgemeine Praxis der Speicherpolitik f\u00fcr einen Festplattenspeicher-Pool mit SSD-Ebene \u2014 SSD zuerst.
\nNur-Lese-Flash-Cache.<\/i> F\u00fcr den Nur-Lese-Flash-Cache tritt die Speicherebene auf der SSD bei erheblicher Lokalisierung von Schreiboperationen unabh\u00e4ngig vom Cache auf.
\nLese-\/Schreib-Flash-Cache.<\/i> Bei einem schreibe-Flash-Cache wird zun\u00e4chst die maximale Cache-Gr\u00f6\u00dfe festgelegt, die Speicherebene auf der SSD tritt jedoch nur auf, wenn die Cache-Gr\u00f6\u00dfe zur Bew\u00e4ltigung der gesamten lokalisierten Last nicht ausreicht.
\nDie Berechnung der Leistung von SSD und Cache erfolgt jedes Mal gem\u00e4\u00df den Empfehlungen des Herstellers, jedoch immer f\u00fcr den schlechtesten 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 eines virtualisierten Rechenzentrums | ProHoster","description":"Einf\u00fchrung Informationssystem von Punkt.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}