{"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\/it\/blog\/katastrofoustojchivoe-oblako-kak-eto-rabotaet","title":{"rendered":"Cloud a prova di catastrofi: come funziona","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ciao, Habr! <\/p>\n<p>Dopo le festivit\u00e0 di Capodanno, abbiamo riavviato il cloud resistente ai disastri su due sedi. Oggi vi racconteremo come \u00e8 strutturato e vi mostreremo cosa succede alle macchine virtuali dei clienti in caso di guasto di singoli elementi del cluster e di un'intera sede (spoiler: stanno tutti bene). <\/p>\n<p><img decoding=\"async\" alt=\"Cloud a prova di catastrofi: come funziona\" src=\"\/wp-content\/uploads\/2020\/01\/58b56261b55785a76bce3e754c86f6a9.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sistemi di archiviazione del cloud resistente ai disastri presso la sede OST.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Cosa c'\u00e8 dentro<\/h3>\n<p>\nSotto il cofano del cluster ci sono server Cisco UCS con hypervisor VMware ESXi, due sistemi di archiviazione INFINIDAT InfiniBox F2240, apparecchiature di rete Cisco Nexus, oltre a switch SAN Brocade. Il cluster \u00e8 distribuito su due sedi: OST e NORD, ovvero, in ogni data center c'\u00e8 lo stesso set di hardware. Questo \u00e8 ci\u00f2 che lo rende resistente ai disastri. <\/p>\n<p>All'interno di una sede, anche gli elementi principali sono duplicati (host, switch SAN, rete).<br \/>\nLe due sedi sono collegate tramite linee in fibra ottica dedicate, anch'esse riservate.<\/p>\n<p>Due parole sui sistemi di archiviazione. La prima versione del cloud resistente ai disastri l'abbiamo costruita su NetApp. Qui abbiamo scelto INFINIDAT, ecco perch\u00e9:<\/p>\n<ul>\n<li>Opzione di replica Active-Active. Consente alla macchina virtuale di rimanere operativa anche in caso di guasto totale di uno dei sistemi di archiviazione. Parler\u00f2 pi\u00f9 dettagliatamente della replica in seguito.<\/li>\n<li>Tre controller disco per aumentare l'affidabilit\u00e0 del sistema. Di solito ce ne sono due.<\/li>\n<li>Soluzione pronta. Ci \u00e8 arrivato un rack gi\u00e0 assemblato, che deve semplicemente essere connesso alla rete e configurato.<\/li>\n<li>Supporto tecnico attento. Gli ingegneri di INFINIDAT analizzano costantemente i log e gli eventi dei sistemi di archiviazione, installano nuove versioni del firmware e aiutano nella configurazione.<\/li>\n<\/ul>\n<p>\nEcco alcune foto dello unpacking:<\/p>\n<p><img decoding=\"async\" alt=\"Cloud a prova di catastrofi: come funziona\" src=\"\/wp-content\/uploads\/2020\/01\/b953a56bba9f0308f5fe1b27b356683b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Cloud a prova di catastrofi: come funziona\" src=\"\/wp-content\/uploads\/2020\/01\/94b5ceb8565ebe1ef2aacff943e1a9d0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Come funziona<\/h3>\n<p>\nIl cloud \u00e8 gi\u00e0 resiliente al suo interno. Protegge il cliente da guasti hardware e software isolati. La resilienza ai disastri, invece, aiuta a proteggersi da guasti di massa all'interno di una singola sede: ad esempio, guasto del sistema di archiviazione (o del cluster SDS, che avviene abbastanza frequentemente \ud83d\ude42), errori di massa nella rete di archiviazione e altro ancora. E la cosa pi\u00f9 importante: un tale cloud salva quando un'intera sede diventa inaccessibile a causa di un incendio, blackout, attacco di pirati o invasione aliena. <\/p>\n<p>In tutti questi casi, le macchine virtuali dei clienti continuano a funzionare, ecco perch\u00e9. <\/p>\n<p>Lo schema del cluster \u00e8 strutturato in modo che qualsiasi host ESXi con macchine virtuali client possa accedere a uno qualsiasi dei due storage SAN. Se lo storage SAN nel sito OST si guasta, le macchine virtuali continueranno a funzionare: gli host su cui operano si collegheranno allo storage SAN su NORD per i dati. <\/p>\n<p><img decoding=\"async\" alt=\"Cloud a prova di catastrofi: come funziona\" src=\"\/wp-content\/uploads\/2020\/01\/996193debdab5b3564c97b05b1e5ba27.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ecco come appare lo schema di connessione nel cluster. <\/i><\/p>\n<p>Questo \u00e8 possibile grazie al fatto che tra le SAN fabric dei due siti \u00e8 stato configurato l'Inter-Switch Link: lo switch SAN Fabric A OST \u00e8 collegato allo switch SAN Fabric A NORD, lo stesso vale per gli switch SAN Fabric B. <\/p>\n<p>E affinch\u00e9 tutte queste complessit\u00e0 delle SAN fabric abbiano senso, tra i due storage SAN \u00e8 stata configurata una replica Active-Active: le informazioni vengono registrate praticamente simultaneamente nello storage locale e in quello remoto, RPO=0. Dunque, su uno storage SAN si trova l'originale dei dati, mentre sull'altro si trova la loro replica. I dati vengono replicati a livello di volumi dello storage SAN, e su questi volumi sono memorizzati i dati delle VM (i suoi dischi, il file di configurazione, il file swap, ecc.). <\/p>\n<p>L'host ESXi vede il volume principale e la sua replica come un'unica unit\u00e0 di storage (Storage Device). Ci sono 24 percorsi dall'host ESXi a ciascuna unit\u00e0 di storage:<\/p>\n<p>12 percorsi collegano l'host allo storage SAN locale (percorsi ottimali), mentre gli altri 12 collegano a quello remoto (percorsi non ottimali). In condizioni normali, l'ESXi accede ai dati sullo storage SAN locale, utilizzando i percorsi \"ottimali\". In caso di guasto di questo storage, l'ESXi perde i percorsi ottimali e passa ai \"percorsi non ottimali\". Ecco come appare nello schema.<\/p>\n<p><img decoding=\"async\" alt=\"Cloud a prova di catastrofi: come funziona\" src=\"\/wp-content\/uploads\/2020\/01\/e2b61eb8b9db4b882a6d20c0abf9fc4e.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Schema del cluster a prova di disastro.<\/i><\/p>\n<p>Tutte le reti client sono collegate a entrambi i siti attraverso un'unica fabric di rete. In ogni sito \u00e8 attivo un Provider Edge (PE), dove terminano le reti dei clienti. I PE sono uniti in un cluster comune. In caso di guasto di un PE in un sito, tutto il traffico viene reindirizzato al secondo sito. Grazie a ci\u00f2, le macchine virtuali nel sito privo di PE rimangono accessibili in rete per il cliente. <\/p>\n<p>Ora vediamo cosa accade alle macchine virtuali del cliente in caso di vari guasti. Iniziamo con le situazioni pi\u00f9 leggere e concludiamo con la pi\u00f9 seria: il guasto di tutto il sito. Negli esempi, il sito principale sar\u00e0 OST e quello di riserva, con le repliche dei dati, sar\u00e0 NORD.<\/p>\n<h3>Cosa succede alla macchina virtuale del cliente se\u2026 <\/h3>\n<p>\n<b>Si guasta il Replication Link.<\/b> La replica tra gli storage SAN dei due siti si interrompe.<br \/>\nESXi funzioner\u00e0 solo con dispositivi di archiviazione locali (attraverso percorsi ottimali). <br \/>\nLe macchine virtuali continuano a funzionare.<\/p>\n<p><img decoding=\"async\" alt=\"Cloud a prova di catastrofi: come funziona\" src=\"\/wp-content\/uploads\/2020\/01\/c15c34e54cb456011f3155b30cbe1063.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Si \u00e8 verificata un'interruzione dell'ISL (Inter-Switch Link).<\/b> Un evento raro. A meno che un escavatore impazzito non scavi in diversi percorsi ottici, che seguono rotte indipendenti e sono collegati alle piattaforme tramite ingressi diversi. Tuttavia, in questo caso, gli host ESXi perderanno met\u00e0 dei percorsi e potranno accedere solo ai propri SAN locali. Le repliche vengono raccolte, ma gli host non potranno accedervi. <\/p>\n<p>Le macchine virtuali funzionano correttamente.<\/p>\n<p><img decoding=\"async\" alt=\"Cloud a prova di catastrofi: come funziona\" src=\"\/wp-content\/uploads\/2020\/01\/c6c1b8b4972cd90cdb639fffe623bc1d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Il commutatore SAN ha subito un guasto su una delle piattaforme.<\/b> Gli host ESXi perdono parte dei percorsi verso il SAN. In questo caso, gli host sulla piattaforma dove si \u00e8 verificato il guasto del commutatore funzioneranno solo tramite un proprio HBA. <\/p>\n<p>Le macchine virtuali continuano a funzionare correttamente.<\/p>\n<p><img decoding=\"async\" alt=\"Cloud a prova di catastrofi: come funziona\" src=\"\/wp-content\/uploads\/2020\/01\/3325765d426751e8717af20f7f122b90.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Tutti i commutatori SAN hanno subito un guasto su una delle piattaforme.<\/b> Supponiamo che questo problema si sia verificato sulla piattaforma OST. In questo caso, gli host ESXi su questa piattaforma perderanno tutti i percorsi verso i propri dispositivi di archiviazione. Interviene il meccanismo standard di VMware vSphere HA: riavvier\u00e0 tutte le macchine virtuali sulla piattaforma OST nel NORD entro un massimo di 140 secondi. <\/p>\n<p>Le macchine virtuali funzionanti sugli host della piattaforma NORD funzionano correttamente.<\/p>\n<p><img decoding=\"async\" alt=\"Cloud a prova di catastrofi: come funziona\" src=\"\/wp-content\/uploads\/2020\/01\/c7a129691cd4d6c161e165fd55607206.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Un host ESXi ha subito un guasto su una piattaforma. <\/b>Qui entra nuovamente in gioco il meccanismo vSphere HA: le macchine virtuali dell'host guasto vengono riavviate su altri host \u2013 sulla stessa o su una piattaforma remota. Il tempo di riavvio della macchina virtuale \u00e8 fino a 1 minuto. <\/p>\n<p>Se tutti gli host ESXi della piattaforma OST subiscono un guasto, non ci sono alternative: le VM vengono riavviate su un'altra piattaforma. Il tempo di riavvio \u00e8 lo stesso. <\/p>\n<p><img decoding=\"async\" alt=\"Cloud a prova di catastrofi: come funziona\" src=\"\/wp-content\/uploads\/2020\/01\/c00fb5078e0c4df1461187d8896670a4.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Un SAN ha subito un guasto su una piattaforma.<\/b> Supponiamo che il SAN sulla piattaforma OST abbia subito un guasto. In tal caso, gli host ESXi della piattaforma OST passeranno a lavorare con le repliche del SAN nel NORD. Dopo il ripristino del SAN guasto, avverr\u00e0 una replica forzata e gli host ESXi OST riprenderanno a contattare il SAN locale. <\/p>\n<p>Le macchine virtuali funzionano correttamente durante tutto questo tempo.<\/p>\n<p><img decoding=\"async\" alt=\"Cloud a prova di catastrofi: come funziona\" src=\"\/wp-content\/uploads\/2020\/01\/87f7e1d012886d963f020768864154a7.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Una delle piattaforme ha subito un guasto.<\/b> In questo caso, tutte le macchine virtuali verranno riavviate sulla piattaforma di riserva tramite il meccanismo vSphere HA. Il tempo di riavvio della VM \u00e8 di 140 secondi. Nel frattempo, tutte le impostazioni di rete della macchina virtuale verranno salvate e rimarr\u00e0 accessibile per il cliente attraverso la rete.<\/p>\n<p>Affinch\u00e9 il riavvio delle macchine nel sito di emergenza avvenga senza problemi, ogni sito \u00e8 riempito solo a met\u00e0. La seconda met\u00e0 \u00e8 una riserva nel caso di trasferimento di tutte le macchine virtuali dal secondo sito, quello danneggiato.<\/p>\n<p><img decoding=\"async\" alt=\"Cloud a prova di catastrofi: come funziona\" src=\"\/wp-content\/uploads\/2020\/01\/62cad7aaf5043f6879dc4a6cbb7b35bb.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00c8 questa la protezione contro tali guasti che offre un cloud altamente resiliente basato su due data center. <\/p>\n<p>Questo piacere non \u00e8 economico, poich\u00e9 oltre alle risorse principali, \u00e8 necessaria una riserva nel secondo sito. Pertanto, vengono ospitati in questo tipo di cloud i servizi critici per il business, il cui lungo fermo comporterebbe ingenti perdite finanziarie e di reputazione, o se il sistema informativo \u00e8 soggetto a requisiti di resilienza da parte dei regolatori o delle normative interne dell\u2019azienda.<\/p>\n<p><b>Fonti:<\/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>Fonte: <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\/it\/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=\"it_IT\" \/>\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\/it\/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\udd47Cloud resiliente: come funziona | ProHoster","description":"Ciao, Habr! Dopo le festivit\u00e0 di fine anno, abbiamo riavviato il cloud altamente resiliente basato su due siti.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/katastrofoustojchivoe-oblako-kak-eto-rabotaet","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/40138","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=40138"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/40138\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/40139"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=40138"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=40138"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=40138"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}