{"id":40138,"date":"2020-01-31T20:49:06","date_gmt":"2020-01-31T17:49:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/katastrofoustojchivoe-oblako-kak-eto-rabotaet"},"modified":"2020-01-31T20:49:06","modified_gmt":"2020-01-31T17:49:06","slug":"katastrofoustojchivoe-oblako-kak-eto-rabotaet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/katastrofoustojchivoe-oblako-kak-eto-rabotaet","title":{"rendered":"Katastrophensichere Cloud: wie das funktioniert","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hallo, Habra! <\/p>\n<p>Nach den Neujahrsfeierlichkeiten haben wir die katastrophensichere Cloud auf Basis von zwei Standorten neu gestartet. Heute erkl\u00e4ren wir, wie das funktioniert und zeigen, was mit den virtuellen Maschinen der Kunden passiert, wenn einzelne Elemente des Clusters ausfallen und die gesamte Infrastruktur zusammenbricht (Spoiler: es geht ihnen gut). <\/p>\n<p><img decoding=\"async\" alt=\"Katastrophensichere Cloud: wie das funktioniert\" src=\"\/wp-content\/uploads\/2020\/01\/58b56261b55785a76bce3e754c86f6a9.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>SAS der katastrophensicheren Cloud am Standort OST.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Was ist drin<\/h3>\n<p>\nIm Inneren des Clusters befinden sich Cisco UCS-Server mit dem Hypervisor VMware ESXi, zwei INFINIDAT InfiniBox F2240 SAN-Systeme, Netzwerkger\u00e4te von Cisco Nexus sowie Brocade SAN-Switches. Das Cluster ist auf zwei Standorte verteilt \u2013 OST und NORD, d. h. in jedem Rechenzentrum ist die Ausr\u00fcstung identisch. Genau das macht es katastrophensicher. <\/p>\n<p>Innerhalb eines Standorts sind auch die Hauptbestandteile dupliziert (Hosts, SAN-Switches, Netzwerke).<br \/>\nDie beiden Standorte sind durch reservierte Glasfaserstrecken verbunden.<\/p>\n<p>Ein paar Worte zu SAN. Die erste Version der katastrophensicheren Cloud haben wir mit NetApp aufgebaut. Hier haben wir uns f\u00fcr INFINIDAT entschieden, und das sind die Gr\u00fcnde:<\/p>\n<ul>\n<li>Active-Active-Replikationsoption. Sie erm\u00f6glicht es der virtuellen Maschine, auch bei einem vollst\u00e4ndigen Ausfall eines der SAN-Systeme betriebsf\u00e4hig zu bleiben. Mehr zur Replikation sp\u00e4ter.<\/li>\n<li>Drei Festplattencontroller zur Erh\u00f6hung der Fehlertoleranz des Systems. Normalerweise sind es zwei.<\/li>\n<li>Fertige L\u00f6sung. Uns wurde ein bereits montierter Rack geliefert, der nur noch ans Netzwerk angeschlossen und konfiguriert werden muss.<\/li>\n<li>Aufmerksamer technischer Support. Die Ingenieure von INFINIDAT analysieren st\u00e4ndig die Protokolle und Ereignisse des SAN, installieren neue Firmware-Versionen und helfen bei der Konfiguration.<\/li>\n<\/ul>\n<p>\nHier sind ein paar Fotos vom Auspacken:<\/p>\n<p><img decoding=\"async\" alt=\"Katastrophensichere Cloud: wie das funktioniert\" src=\"\/wp-content\/uploads\/2020\/01\/b953a56bba9f0308f5fe1b27b356683b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Katastrophensichere Cloud: wie das funktioniert\" src=\"\/wp-content\/uploads\/2020\/01\/94b5ceb8565ebe1ef2aacff943e1a9d0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Wie es funktioniert<\/h3>\n<p>\nDie Cloud ist bereits innerhalb ihrer eigenen Infrastruktur katastrophensicher. Sie sch\u00fctzt den Kunden vor einzelnen Hardware- und Softwareausf\u00e4llen. Die katastrophensichere L\u00f6sung hilft, sich vor massiven St\u00f6rungen innerhalb eines Standorts zu sch\u00fctzen: zum Beispiel beim Ausfall eines SAN-Systems (oder des SDS-Clusters, was h\u00e4ufig vorkommt \ud83d\ude42), massiven Fehlern im Speichernetzwerk und anderem. Und das Wichtigste: Eine solche Cloud sch\u00fctzt, wenn ein ganzes Rechenzentrum aufgrund von Feuer, Stromausfall, \u00dcbernahme durch Dritte oder Alien-Invasion nicht mehr verf\u00fcgbar ist. <\/p>\n<p>In all diesen F\u00e4llen laufen die virtuellen Maschinen der Kunden weiter, und das ist der Grund. <\/p>\n<p>Das Cluster-Schema ist so aufgebaut, dass jeder ESXi-Host mit Client-VMs auf eines der beiden SAN-Systeme zugreifen kann. Wenn das SAN am Standort OST ausf\u00e4llt, bleiben die virtuellen Maschinen weiterhin in Betrieb: Die Hosts, auf denen sie laufen, werden auf die Daten des SAN am NORD zugreifen. <\/p>\n<p><img decoding=\"async\" alt=\"Katastrophensichere Cloud: wie das funktioniert\" src=\"\/wp-content\/uploads\/2020\/01\/996193debdab5b3564c97b05b1e5ba27.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>So sieht das Verbindungsdiagramm im Cluster aus. <\/i><\/p>\n<p>Dies ist m\u00f6glich, weil zwischen den SAN-Fabriken der beiden Standorte ein Inter-Switch Link eingerichtet wurde: Der SAN-Switch Fabric A OST ist mit dem SAN-Switch Fabric A NORD verbunden, ebenso wie die SAN-Switches Fabric B. <\/p>\n<p>Damit all diese komplexen Verbindungen der SAN-Fabriken Sinn machen, ist zwischen den beiden SAN-Systemen eine Active-Active-Replikation eingerichtet: Informationen werden fast gleichzeitig auf das lokale und das entfernte SAN geschrieben, RPO=0. Das bedeutet, dass auf einem SAN das Original der Daten gespeichert ist, auf dem anderen die Replik. Die Daten werden auf der Ebene der SAN-Volumes repliziert, und darauf werden die VM-Daten (ihre Festplatten, die Konfigurationsdatei, die Swap-Datei usw.) gespeichert. <\/p>\n<p>Der ESXi-Host sieht das Hauptvolume und seine Replik als ein einzelnes Speicherger\u00e4t (Storage Device). Vom ESXi-Host zu jedem Speicherger\u00e4t gibt es 24 Pfade:<\/p>\n<p>12 Pfade verbinden es mit dem lokalen SAN (optimale Pfade), w\u00e4hrend die anderen 12 mit dem entfernten SAN (nicht optimale Pfade) verbunden sind. In einer regul\u00e4ren Situation greift ESXi mit den \"optimalen\" Pfaden auf die Daten des lokalen SAN zu. F\u00e4llt dieses SAN aus, verliert ESXi die optimalen Pfade und wechselt auf die \"nicht optimalen\". So sieht es im Diagramm aus.<\/p>\n<p><img decoding=\"async\" alt=\"Katastrophensichere Cloud: wie das funktioniert\" src=\"\/wp-content\/uploads\/2020\/01\/e2b61eb8b9db4b882a6d20c0abf9fc4e.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Schema des katastrophensicheren Clusters.<\/i><\/p>\n<p>Alle Client-Netze sind \u00fcber eine gemeinsame Netzwerkfabrik an beide Standorte angeschlossen. An jedem Standort arbeitet ein Provider Edge (PE), an dem die Netzwerke des Kunden terminiert werden. PE sind in einem gemeinsamen Cluster verbunden. Bei einem Ausfall des PE an einem Standort wird der gesamte Verkehr auf den zweiten Standort umgeleitet. Dadurch bleiben die virtuellen Maschinen am Standort, der ohne PE ist, f\u00fcr den Kunden \u00fcber das Netzwerk zug\u00e4nglich. <\/p>\n<p>Lassen Sie uns nun untersuchen, was mit den virtuellen Maschinen des Kunden bei verschiedenen Ausf\u00e4llen passiert. Wir beginnen mit den mildesten Situationen und enden mit dem kritischsten \u2013 dem Ausfall des gesamten Standorts. In den Beispielen wird der Hauptstandort OST sein und der Sicherungsstandort mit den Datenreplikaten NORD.<\/p>\n<h3>Was passiert mit der virtuellen Maschine des Kunden, wenn\u2026 <\/h3>\n<p>\n<b>Der Replikationslink ausf\u00e4llt.<\/b> Die Replikation zwischen den SAN-Systemen der beiden Standorte wird unterbrochen.<br \/>\nESXi wird nur mit lokalen Festplattenspeicherger\u00e4ten (auf optimalen Pfaden) funktionieren. <br \/>\nVirtuelle Maschinen laufen weiterhin.<\/p>\n<p><img decoding=\"async\" alt=\"Katastrophensichere Cloud: wie das funktioniert\" src=\"\/wp-content\/uploads\/2020\/01\/c15c34e54cb456011f3155b30cbe1063.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>ISL (Inter-Switch-Link) wird unterbrochen.<\/b> Der Fall ist unwahrscheinlich. Es sei denn, ein durchgeknallter Bagger gr\u00e4bt mehrere optische Strecken auf einmal um, die auf unabh\u00e4ngigen Routen verlaufen und \u00fcber verschiedene Einspeisepunkte auf die Standorte geleitet werden. Aber dennoch. In diesem Fall verlieren die ESXi-Hosts die H\u00e4lfte der Pfade und k\u00f6nnen nur auf ihre lokalen SANs zugreifen. Repliken werden gesammelt, aber die Hosts k\u00f6nnen nicht darauf zugreifen. <\/p>\n<p>Die virtuellen Maschinen arbeiten normal.<\/p>\n<p><img decoding=\"async\" alt=\"Katastrophensichere Cloud: wie das funktioniert\" src=\"\/wp-content\/uploads\/2020\/01\/c6c1b8b4972cd90cdb639fffe623bc1d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Ein SAN-Switch an einer der Standorte f\u00e4llt aus.<\/b> Die ESXi-Hosts verlieren Teile der Pfade zu den SANs. In diesem Fall werden die Hosts am Standort, an dem der Switch ausgefallen ist, nur \u00fcber einen eigenen HBA arbeiten. <\/p>\n<p>Die virtuellen Maschinen laufen dabei weiterhin normal.<\/p>\n<p><img decoding=\"async\" alt=\"Katastrophensichere Cloud: wie das funktioniert\" src=\"\/wp-content\/uploads\/2020\/01\/3325765d426751e8717af20f7f122b90.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Alle SAN-Switches an einem der Standorte fallen aus.<\/b> Angenommen, ein solcher Vorfall tritt am Standort OST auf. In diesem Fall verlieren die ESXi-Hosts an diesem Standort alle Pfade zu ihren Speichereinheiten. Der Standardmechanismus von VMware vSphere HA greift ein: Er startet alle virtuellen Maschinen am Standort OST im NORD sp\u00e4testens nach 140 Sekunden neu. <\/p>\n<p>Die virtuellen Maschinen, die auf den Hosts des Standorts NORD laufen, arbeiten normal.<\/p>\n<p><img decoding=\"async\" alt=\"Katastrophensichere Cloud: wie das funktioniert\" src=\"\/wp-content\/uploads\/2020\/01\/c7a129691cd4d6c161e165fd55607206.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Ein ESXi-Host an einem Standort f\u00e4llt aus. <\/b>Hier greift erneut der Mechanismus von vSphere HA: Die virtuellen Maschinen des ausgefallenen Hosts werden auf anderen Hosts neu gestartet \u2013 am selben oder an einem anderen Standort. Die Neustartzeit der virtuellen Maschine betr\u00e4gt bis zu 1 Minute. <\/p>\n<p>Wenn alle ESXi-Hosts am Standort OST ausfallen, gibt es hier keine Optionen: Die VMs werden auf einem anderen Standort neu gestartet. Die Neustartzeit bleibt gleich. <\/p>\n<p><img decoding=\"async\" alt=\"Katastrophensichere Cloud: wie das funktioniert\" src=\"\/wp-content\/uploads\/2020\/01\/c00fb5078e0c4df1461187d8896670a4.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Ein SAN f\u00e4llt an einem Standort aus.<\/b> Nehmen wir an, das SAN hat am Standort OST versagt. Dann wechseln die ESXi-Hosts am Standort OST auf den Betrieb mit den Repliken des SAN in NORD. Nach der Wiederherstellung des ausgefallenen SAN wird eine erzwungene Replikation durchgef\u00fchrt, und die ESXi-Hosts am OST werden wieder auf das lokale SAN zugreifen. <\/p>\n<p>Die virtuellen Maschinen laufen in der gesamten Zeit normal.<\/p>\n<p><img decoding=\"async\" alt=\"Katastrophensichere Cloud: wie das funktioniert\" src=\"\/wp-content\/uploads\/2020\/01\/87f7e1d012886d963f020768864154a7.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Einer der Standorte f\u00e4llt aus.<\/b> In diesem Fall werden alle virtuellen Maschinen \u00fcber den Mechanismus von vSphere HA auf dem Backup-Standort neu gestartet. Die Neustartzeit der VMs betr\u00e4gt 140 Sekunden. Dabei bleiben alle Netzwerkeinstellungen der virtuellen Maschine erhalten, und sie bleibt \u00fcber das Netzwerk f\u00fcr den Kunden verf\u00fcgbar.<\/p>\n<p>Um sicherzustellen, dass der Neustart der Maschinen auf dem Backup-Gel\u00e4nde problemlos verl\u00e4uft, ist jede Fl\u00e4che nur zur H\u00e4lfte belegt. Die andere H\u00e4lfte ist als Reserve f\u00fcr den Umzug aller virtuellen Maschinen von der zweiten, betroffenen Fl\u00e4che vorgesehen.<\/p>\n<p><img decoding=\"async\" alt=\"Katastrophensichere Cloud: wie das funktioniert\" src=\"\/wp-content\/uploads\/2020\/01\/62cad7aaf5043f6879dc4a6cbb7b35bb.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVor solchen Ausf\u00e4llen sch\u00fctzt die katastrophensichere Cloud, die auf zwei Rechenzentren basiert. <\/p>\n<p>Dieser Komfort ist nicht billig, da neben den Hauptressourcen auch eine Reserve auf der zweiten Fl\u00e4che ben\u00f6tigt wird. Daher werden in einer solchen Cloud gesch\u00e4ftskritische Dienste platziert, deren l\u00e4ngere Ausfallzeiten erhebliche finanzielle und reputationsbezogene Verluste mit sich bringen, oder wenn an das Informationssystem Anforderungen an die Katastrophensicherheit von Regulierungsbeh\u00f6rden oder internen Vorschriften des Unternehmens gestellt werden.<\/p>\n<p><b>Quellen:<\/b><\/p>\n<ol>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.infinidat.com\/sites\/default\/files\/resource-pdfs\/DS-INFBOX-190331-US_0.pdf\">www.infinidat.com\/sites\/default\/files\/resource-pdfs\/DS-INFBOX-190331-US_0.pdf<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/support.infinidat.com\/hc\/en-us\/articles\/207057109-InfiniBox-best-practices-guides\">support.infinidat.com\/hc\/en-us\/articles\/207057109-InfiniBox-best-practices-guides<\/a><\/noindex><\/li>\n<\/ol>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dataline\/blog\/486186\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u041f\u043e\u0441\u043b\u0435 \u043d\u043e\u0432\u043e\u0433\u043e\u0434\u043d\u0438\u0445 \u043f\u0440\u0430\u0437\u0434\u043d\u0438\u043a\u043e\u0432 \u043c\u044b \u043f\u0435\u0440\u0435\u0437\u0430\u043f\u0443\u0441\u0442\u0438\u043b\u0438 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0435 \u043e\u0431\u043b\u0430\u043a\u043e \u043d\u0430 \u0431\u0430\u0437\u0435 \u0434\u0432\u0443\u0445 \u043f\u043b\u043e\u0449\u0430\u0434\u043e\u043a. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u044d\u0442\u043e \u0443\u0441\u0442\u0440\u043e\u0435\u043d\u043e, \u0438 \u043f\u043e\u043a\u0430\u0436\u0435\u043c, \u0447\u0442\u043e \u043f\u0440\u043e\u0438\u0441\u0445\u043e\u0434\u0438\u0442 \u0441 \u043a\u043b\u0438\u0435\u043d\u0442\u0441\u043a\u0438\u043c\u0438 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u043c\u0438 \u043c\u0430\u0448\u0438\u043d\u0430\u043c\u0438 \u043f\u0440\u0438 \u043e\u0442\u043a\u0430\u0437\u0435 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0445 \u044d\u043b\u0435\u043c\u0435\u043d\u0442\u043e\u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 \u0438 \u043f\u0430\u0434\u0435\u043d\u0438\u0438 \u0446\u0435\u043b\u043e\u0439 \u043f\u043b\u043e\u0449\u0430\u0434\u043a\u0438 (\u0441\u043f\u043e\u0439\u043b\u0435\u0440 \u2013 \u0441 \u043d\u0438\u043c\u0438 \u0432\u0441\u0435 \u0445\u043e\u0440\u043e\u0448\u043e). \u0421\u0425\u0414 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0433\u043e \u043e\u0431\u043b\u0430\u043a\u0430 \u043d\u0430 \u043f\u043b\u043e\u0449\u0430\u0434\u043a\u0435 OST. \u0427\u0442\u043e \u0432\u043d\u0443\u0442\u0440\u0438 \u041f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442\u043e\u043c \u0443 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u044b Cisco [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":40139,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-40138","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u041f\u043e\u0441\u043b\u0435 \u043d\u043e\u0432\u043e\u0433\u043e\u0434\u043d\u0438\u0445 \u043f\u0440\u0430\u0437\u0434\u043d\u0438\u043a\u043e\u0432 \u043c\u044b \u043f\u0435\u0440\u0435\u0437\u0430\u043f\u0443\u0441\u0442\u0438\u043b\u0438 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0435 \u043e\u0431\u043b\u0430\u043a\u043e \u043d\u0430 \u0431\u0430\u0437\u0435 \u0434\u0432\u0443\u0445 \u043f\u043b\u043e\u0449\u0430\u0434\u043e\u043a.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/katastrofoustojchivoe-oblako-kak-eto-rabotaet\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0435 \u043e\u0431\u043b\u0430\u043a\u043e: \u043a\u0430\u043a \u044d\u0442\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u041f\u043e\u0441\u043b\u0435 \u043d\u043e\u0432\u043e\u0433\u043e\u0434\u043d\u0438\u0445 \u043f\u0440\u0430\u0437\u0434\u043d\u0438\u043a\u043e\u0432 \u043c\u044b \u043f\u0435\u0440\u0435\u0437\u0430\u043f\u0443\u0441\u0442\u0438\u043b\u0438 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0435 \u043e\u0431\u043b\u0430\u043a\u043e \u043d\u0430 \u0431\u0430\u0437\u0435 \u0434\u0432\u0443\u0445 \u043f\u043b\u043e\u0449\u0430\u0434\u043e\u043a.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/katastrofoustojchivoe-oblako-kak-eto-rabotaet\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-01-31T17:49:06+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-01-31T17:49:06+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Katastrophensichere Cloud: So funktioniert es | ProHoster","description":"Hallo, Habr! Nach den Neujahrsfeiertagen haben wir die katastrophensichere Cloud auf Basis von zwei Fl\u00e4chen neu gestartet.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/katastrofoustojchivoe-oblako-kak-eto-rabotaet","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\u041a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0435 \u043e\u0431\u043b\u0430\u043a\u043e: \u043a\u0430\u043a \u044d\u0442\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u041f\u043e\u0441\u043b\u0435 \u043d\u043e\u0432\u043e\u0433\u043e\u0434\u043d\u0438\u0445 \u043f\u0440\u0430\u0437\u0434\u043d\u0438\u043a\u043e\u0432 \u043c\u044b \u043f\u0435\u0440\u0435\u0437\u0430\u043f\u0443\u0441\u0442\u0438\u043b\u0438 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0435 \u043e\u0431\u043b\u0430\u043a\u043e \u043d\u0430 \u0431\u0430\u0437\u0435 \u0434\u0432\u0443\u0445 \u043f\u043b\u043e\u0449\u0430\u0434\u043e\u043a.","og:url":"https:\/\/prohoster.info\/de\/blog\/katastrofoustojchivoe-oblako-kak-eto-rabotaet","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":"2020-01-31T17:49:06+00:00","article:modified_time":"2020-01-31T17:49:06+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"40138","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:44:38","updated":"2022-09-28 05:19:32","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\/40138","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=40138"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/40138\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/40139"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=40138"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=40138"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=40138"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}