{"id":35387,"date":"2019-10-31T22:04:01","date_gmt":"2019-10-31T19:04:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/aerodisk-engine-katastrofoustojchivost-chast-1\/"},"modified":"2019-10-31T22:04:01","modified_gmt":"2019-10-31T19:04:01","slug":"aerodisk-engine-katastrofoustojchivost-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-1","title":{"rendered":"AERODISK Engine: Resilienza ai disastri. Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/7749b28518da6543acd41dce646844c0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ciao, lettori di Habr! L'argomento di questo articolo sar\u00e0 l'implementazione di strumenti di resilienza nei sistemi di archiviazione AERODISK Engine. Inizialmente volevamo scrivere in un solo articolo su entrambi gli strumenti: la replica e il metrocluster, ma purtroppo l'articolo \u00e8 diventato troppo lungo, quindi l'abbiamo diviso in due parti. Passeremo dal semplice al complesso. In questo articolo configureremo e testeremo la replica sincrona: abbatteremo un data center e interromperemo il canale di comunicazione tra i data center per vedere cosa succede.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>I nostri clienti ci pongono spesso diverse domande sulla replica, quindi, prima di passare alla configurazione e al test dell'implementazione delle repliche, parleremo un po' di cosa sia la replica negli sistemi di archiviazione.<\/p>\n<p><\/p>\n<h2 id=\"nemnogo-teorii\">Un po' di teoria<\/h2>\n<p><\/p>\n<p>La replica negli sistemi di archiviazione \u00e8 un processo continuo per garantire l'identit\u00e0 dei dati contemporaneamente su pi\u00f9 sistemi di archiviazione. Tecnicamente, la replica viene eseguita con due metodi.<\/p>\n<p><\/p>\n<p><strong>Replica sincrona<\/strong> \u00e8 il copia dei dati da un sistema di archiviazione principale a uno secondario con la successiva conferma obbligatoria da entrambi i sistemi di archiviazione che i dati siano stati registrati e confermati. Solo dopo la conferma da entrambe le parti (da entrambi i sistemi di archiviazione) i dati si considerano registrati e possono essere utilizzati. In questo modo si garantisce l'identit\u00e0 dei dati su tutti i sistemi di archiviazione coinvolti nella replica.<\/p>\n<p><\/p>\n<p>I vantaggi di questo metodo:<\/p>\n<p><\/p>\n<ul>\n<li>I dati sono sempre identici su tutti i sistemi di archiviazione<\/li>\n<\/ul>\n<p><\/p>\n<p>Contro:<\/p>\n<p><\/p>\n<ul>\n<li>Alto costo della soluzione (canali di comunicazione rapidi, costosa fibra ottica, trasmettitori a lungo raggio, ecc.)<\/li>\n<li>Limitazioni di distanza (nell'ordine di alcune decine di chilometri)<\/li>\n<li>Nessuna protezione contro la corruzione logica dei dati (se i dati vengono corrotti (intenzionalmente o accidentalmente) sul sistema di archiviazione principale, essi diventeranno automaticamente e immediatamente corrotti su quello secondario, poich\u00e9 i dati sono sempre identici (un paradosso))<\/li>\n<\/ul>\n<p><\/p>\n<p><strong>Replica asincrona<\/strong> \u00e8 un'altra copia dei dati dal sistema di archiviazione principale a quello secondario, ma con un certo ritardo e senza la necessit\u00e0 di confermare la registrazione dall'altra parte. \u00c8 possibile lavorare con i dati subito dopo la registrazione sul sistema di archiviazione principale, mentre i dati sul sistema di archiviazione secondario saranno disponibili dopo un certo periodo. L'identit\u00e0 dei dati in questo caso, chiaramente, non \u00e8 garantita. I dati sul sistema di archiviazione secondario sono sempre un po' \"nel passato\".<\/p>\n<p><\/p>\n<p>Vantaggi della replica asincrona:<\/p>\n<p><\/p>\n<ul>\n<li>Costo contenuto della soluzione (qualsiasi canale di comunicazione, fibra ottica opzionale)<\/li>\n<li>Nessuna limitazione di distanza<\/li>\n<li>Sulla SAN di riserva, i dati non vengono danneggiati in caso di danneggiamento sulla principale (per lo meno, per un certo periodo di tempo). Se i dati diventano danneggiati, \u00e8 sempre possibile interrompere la replica per evitare il danneggiamento dei dati sulla SAN di riserva.<\/li>\n<\/ul>\n<p><\/p>\n<p>Contro:<\/p>\n<p><\/p>\n<ul>\n<li>I dati nei diversi data center non sono mai identici.<\/li>\n<\/ul>\n<p><\/p>\n<p>Pertanto, la scelta della modalit\u00e0 di replica dipende dalle esigenze aziendali. Se \u00e8 fondamentale avere esattamente gli stessi dati nel data center di riserva che in quello principale (ovvero, requisito aziendale RPO=0), \u00e8 necessario spendere di pi\u00f9 e accettare le limitazioni della replica sincrona. Se \u00e8 tollerabile un ritardo nello stato dei dati o semplicemente non ci sono fondi, allora \u00e8 decisamente meglio utilizzare il metodo asincrono.<\/p>\n<p><\/p>\n<p>Inoltre, vogliamo evidenziare un modo (pi\u00f9 precisamente, una topologia) chiamato metrocluster. Nella modalit\u00e0 metrocluster si utilizza la replica sincrona, ma a differenza della replica normale, il metrocluster consente a entrambe le SAN di lavorare in modalit\u00e0 attiva. Cio\u00e8, non ci sono divisioni in data center attivi e di riserva. Le applicazioni funzionano simultaneamente con due SAN, fisicamente localizzate in diversi data center. I tempi di inattivit\u00e0 in caso di guasti in tale topologia sono molto brevi (RTO, di solito, minuti). In questo articolo non tratteremo la nostra implementazione del metrocluster, poich\u00e9 \u00e8 un argomento molto vasto e complesso, quindi dedicheremo un articolo separato a questo, in continuit\u00e0 con il presente. <\/p>\n<p><\/p>\n<p>Inoltre, molto spesso, quando parliamo di replica tramite SAN, molte persone si pongono una domanda legittima: &gt; \u00abMolte applicazioni hanno i propri strumenti di replica, perch\u00e9 utilizzare la replica sulla SAN? \u00c8 meglio o peggio?\u00bb<\/p>\n<p><\/p>\n<p>Non c'\u00e8 una risposta univoca, quindi presenteremo argomenti a favore e contro:<\/p>\n<p><\/p>\n<p>Argomenti a favore della replica SAN:<\/p>\n<p><\/p>\n<ul>\n<li>Semplicit\u00e0 della soluzione. Con un singolo strumento puoi replicare l'intero array di dati, indipendentemente dal tipo di carico e di applicazioni. Se si utilizza la replica delle applicazioni, sar\u00e0 necessario configurare ogni applicazione separatamente. Se ce ne sono pi\u00f9 di due, diventa estremamente laborioso e costoso (la replica delle applicazioni richiede, di norma, una licenza separata e a pagamento per ogni applicazione. Ma di questo parleremo pi\u00f9 avanti).<\/li>\n<li>\u00c8 possibile replicare qualsiasi cosa: qualsiasi applicazione, qualsiasi dato, e saranno sempre coerenti. Molte (la maggior parte) delle applicazioni non dispongono di strumenti di replicazione, e le repliche del sistema di archiviazione (S\u0425\u0414) sono l'unico mezzo per garantire la protezione dai disastri.<\/li>\n<li>Non \u00e8 necessario pagare troppo per le funzionalit\u00e0 di replicazione delle applicazioni. Di norma, esse non sono economiche, cos\u00ec come le licenze per le repliche del S\u0425\u0414. Tuttavia, per la licenza di replicazione del S\u0425\u0414 \u00e8 necessario pagare una sola volta, mentre le licenze per le repliche delle applicazioni devono essere acquistate separatamente per ogni applicazione. Se ci sono molte di queste applicazioni, il costo pu\u00f2 essere elevato e il prezzo delle licenze per la replicazione del S\u0425\u0414 diventa una goccia nell'oceano.<\/li>\n<\/ul>\n<p><\/p>\n<p>Argomenti CONTRO la replicazione del S\u0425\u0414:<\/p>\n<p><\/p>\n<ul>\n<li>La replica tramite gli strumenti delle applicazioni offre pi\u00f9 funzionalit\u00e0 dal punto di vista delle stesse applicazioni; un'applicazione conosce meglio i propri dati (cosa evidente), quindi ci sono pi\u00f9 opzioni per lavorarci.<\/li>\n<li>I produttori di alcune applicazioni non garantiscono la coerenza dei propri dati se la replicazione viene eseguita tramite strumenti esterni. *<\/li>\n<\/ul>\n<p><\/p>\n<p>* - tesi discutibile. Ad esempio, una nota azienda produttrice di database ha a lungo dichiarato ufficialmente che il loro database pu\u00f2 essere replicato normalmente solo con i propri strumenti, mentre la replicazione esterna (compresa quella S\u0425\u0414) \u00e8 \"non vera\". Ma la vita ha mostrato che non \u00e8 cos\u00ec. \u00c8 probabile (ma non certo) che sia solo un tentativo poco onesto di vendere ulteriori licenze ai clienti. <\/p>\n<p><\/p>\n<p>In definitiva, nella maggior parte dei casi la replicazione da parte del S\u0425\u0414 \u00e8 migliore, poich\u00e9 rappresenta un'opzione pi\u00f9 semplice e meno costosa, ma ci sono casi complessi in cui \u00e8 necessaria una funzionalit\u00e0 specifica delle applicazioni, e bisogna lavorare esattamente con la replicazione a livello di applicazioni. <\/p>\n<p><\/p>\n<h2 id=\"s-teoriey-zakonchili-teper-praktika\">Abbiamo finito con la teoria, ora passiamo alla pratica<\/h2>\n<p><\/p>\n<p>Imposteremo la replica nel nostro laboratorio. In condizioni di laboratorio, abbiamo emulato due data center (in realt\u00e0, due rack vicini che sembrano trovarsi in edifici diversi). Il banco di prova \u00e8 composto da due S\u0425\u0414 Engine N2 collegati tra loro da cavi in fibra ottica. A entrambi gli S\u0425\u0414 \u00e8 collegato un server fisico con sistema operativo Windows Server 2016 utilizzando 10Gb Ethernet. Il banco di prova \u00e8 piuttosto semplice, ma ci\u00f2 non cambia il nocciolo della questione.<\/p>\n<p><\/p>\n<p>Schematizzando, appare cos\u00ec:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/044f81f6145cd05695c236e21a3d9aba.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Logicamente, la replicazione \u00e8 organizzata nel seguente modo:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/87e88c44d68c32bdad776b626ed01bdd.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ora analizziamo le funzionalit\u00e0 di replicazione che abbiamo attualmente.<br \/>\nSono supportati due modalit\u00e0: asincrona e sincrona. \u00c8 logico che la modalit\u00e0 sincrona sia limitata dalla distanza e dal canale di comunicazione. In particolare, la modalit\u00e0 sincrona richiede l'utilizzo della fibra ottica come fisica e un Ethernet da 10 gigabit (o superiore). <\/p>\n<p><\/p>\n<p>La distanza supportata per la replica sincrona \u00e8 di 40 chilometri, con valori di latenza del canale ottico tra i datacenter fino a 2 millisecondi. In generale, funzioner\u00e0 anche con latenze maggiori, ma ci saranno forti rallentamenti durante la scrittura (il che \u00e8 abbastanza logico), dunque se hai in mente di impostare una replica sincrona tra i datacenter, \u00e8 necessario verificare la qualit\u00e0 della fibra ottica e le latenze.<\/p>\n<p><\/p>\n<p>Per la replica asincrona, i requisiti non sono cos\u00ec severi. Anzi, non ce ne sono affatto. Qualsiasi connessione Ethernet funzionante va bene.<\/p>\n<p><\/p>\n<p>Attualmente, nel sistema di archiviazione AERODISK ENGINE, \u00e8 supportata la replica per dispositivi a blocchi (LUN) tramite protocollo Ethernet (su rame o fibra ottica). Per progetti che richiedono necessariamente la replica tramite una SAN di rete su Fibre Channel, stiamo attualmente scrivendo una soluzione corrispondente, ma non \u00e8 ancora pronta, quindi nel nostro caso \u2013 solo Ethernet.<\/p>\n<p><\/p>\n<p>La replica pu\u00f2 funzionare tra qualsiasi sistema di archiviazione della serie ENGINE (N1, N2, N4) dai modelli pi\u00f9 piccoli a quelli pi\u00f9 grandi e viceversa.<\/p>\n<p><\/p>\n<p>Le funzionalit\u00e0 di entrambe le modalit\u00e0 di replica sono completamente identiche. Di seguito, maggiori dettagli su ci\u00f2 che \u00e8 disponibile: <\/p>\n<p><\/p>\n<ul>\n<li>Replica \u00abone to one\u00bb o \u00abuno a uno\u00bb, ossia l'opzione classica con due datacenter, uno principale e uno di riserva<\/li>\n<li>Replica \u00abone to many\u00bb o \u00abuno a molti\u00bb, cio\u00e8 un LUN pu\u00f2 essere replicato su pi\u00f9 sistemi di archiviazione contemporaneamente<\/li>\n<li>Attivazione, disattivazione e \u00abrovesciamento\u00bb della replica, rispettivamente per abilitare, disabilitare o modificare la direzione della replica<\/li>\n<li>La replica \u00e8 disponibile sia per pool RDG (Raid Distributed Group) che per DDP (Dynamic Disk Pool). Tuttavia, il LUN del pool RDG pu\u00f2 essere replicato solo in un altro RDG. Lo stesso vale per DDP.<\/li>\n<\/ul>\n<p><\/p>\n<p>Ci sono anche molte piccole peculiarit\u00e0, ma non ha molto senso elencarle, le menzioneremo durante la configurazione.<\/p>\n<p><\/p>\n<h2 id=\"nastroyka-replikacii\">Configurazione della replica<\/h2>\n<p><\/p>\n<p>Il processo di configurazione \u00e8 piuttosto semplice e consiste in tre fasi.<\/p>\n<p><\/p>\n<ol>\n<li>Configurazione della rete<\/li>\n<li>Configurazione dello storage<\/li>\n<li>Configurazione delle regole (collegamenti) e del mapping<\/li>\n<\/ol>\n<p><\/p>\n<p>Un aspetto importante della configurazione della replica \u00e8 che le prime due fasi devono essere ripetute sul sistema di archiviazione remoto, la terza fase \u2013 solo su quello principale.<\/p>\n<p><\/p>\n<h3 id=\"nastroyka-setevyh-resursov\">Configurazione delle risorse di rete<\/h3>\n<p><\/p>\n<p>Per prima cosa, \u00e8 necessario configurare le porte di rete attraverso le quali verr\u00e0 trasmesso il traffico di replica. A tal fine, bisogna attivare le porte e configurarle <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/it\/lir\/ipv4\/\"   title=\"Indirizzi IP\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"629\">Indirizzi IP<\/a> nella sezione degli adattatori Front-end. <\/p>\n<p><\/p>\n<p>Dopo di ci\u00f2, dobbiamo creare un pool (nel nostro caso RDG) e un indirizzo IP virtuale per la replica (VIP). Il VIP \u00e8 un indirizzo IP fluttuante, legato a due indirizzi 'fisici' dei controllori SAN (porte che abbiamo appena configurato). Sar\u00e0 l'interfaccia principale di replica. Si pu\u00f2 anche operare senza VIP, ma utilizzando un VLAN, se si ha bisogno di lavorare con traffico taggato.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/ca0a86542d8fe4bb9eb7498b66eede43.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Il processo di creazione del VIP per la replica \u00e8 poco diverso dalla creazione del VIP per l'input-output (NFS, SMB, iSCSI). In questo caso, creiamo un VIP normale (senza VLAN), ma \u00e8 fondamentale indicare che \u00e8 per la replica (senza quest'indicazione non potremo aggiungere il VIP alla regola nel passaggio successivo).<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/054a5d2a9695aed19aafbd2efe833196.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Il VIP deve assolutamente essere nella stessa sottorete degli IP delle porte tra le quali 'fluttua'.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/fb96d1609425dcebb5345435ac7f6857.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ripetiamo queste impostazioni sul SAN remoto, con un altro indirizzo IP, ovviamente.<br \/>\nI VIP di diversi SAN possono trovarsi in sottoreti diverse, l'importante \u00e8 che ci sia instradamento tra di essi. Nel nostro caso, viene mostrato proprio questo esempio (192.168.3.XX e 192.168.2.XX)<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/3d43b4339277e50413cc9944c53e0d62.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Con questo, la preparazione della parte di rete \u00e8 completata.<\/p>\n<p><\/p>\n<h3 id=\"nastraivaem-hranilischa\">Configuriamo gli storage<\/h3>\n<p><\/p>\n<p>La configurazione dello storage per la replica differisce dalla normale solo per il fatto che il mapping lo facciamo attraverso un menu speciale 'Mapping di replica'. Per il resto, \u00e8 tutto come nella configurazione normale. Procediamo passo dopo passo.<\/p>\n<p><\/p>\n<p>Nel pool R02 creato in precedenza, \u00e8 necessario creare un LUN. Creiamo e lo chiamiamo LUN1.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/263fa2d3a06318d4e7da280b869123ca.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dobbiamo anche creare un LUN identico su un SAN remoto con la stessa capacit\u00e0. Creiamo. Per evitare confusione, lo chiameremo LUN1R <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/bbd302358c2bd825a234da94b2410770.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Se ci fosse bisogno di utilizzare un LUN gi\u00e0 esistente, durante la configurazione della replica sarebbe necessario smontare temporaneamente quel LUN produttivo dall'host, mentre sul SAN remoto deve essere semplicemente creato un LUN vuoto con la stessa capacit\u00e0.<\/p>\n<p><\/p>\n<p>La configurazione dello storage \u00e8 completata, passiamo alla creazione della regola di replica.<\/p>\n<p><\/p>\n<h3 id=\"nastroyka-pravil-replikacii-ili-replikacionnyh-svyazey\">Configurazione delle regole di replica o dei legami di replica<\/h3>\n<p><\/p>\n<p>Dopo aver creato i LUN sui SAN, che attualmente sar\u00e0 quello principale (Primary), impostiamo la regola di replica per il LUN1 sul SAN1 verso il LUN1R sul SAN2.<\/p>\n<p><\/p>\n<p>La configurazione avviene nel menu 'Replica remota'<\/p>\n<p><\/p>\n<p>Creiamo una regola. Per questo \u00e8 necessario indicare il destinatario della replica. Qui impostiamo anche il nome della connessione e il tipo di replicazione (sincrona o asincrona).<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/a36bdc437d4a619f47b75d5ba50971ed.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nel campo \"sistemi remoti\" aggiungiamo il nostro SAN2. Per aggiungere \u00e8 necessario utilizzare gli IP di gestione del SAN (MGR) e il nome del LUN remoto, in cui eseguiremo la replicazione (nel nostro caso LUN1R). Gli IP di gestione sono necessari solo nella fase di aggiunta della connessione, il traffico di replicazione non passer\u00e0 attraverso di essi, per questo verr\u00e0 utilizzato il VIP configurato in precedenza. <\/p>\n<p><\/p>\n<p>Gi\u00e0 a questo punto possiamo aggiungere pi\u00f9 di un sistema remoto per la topologia \"one to many\": premiamo il pulsante \"aggiungi nodo\", come nella figura sottostante. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/dbe98818d2c2d34250544db4266337ea.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nel nostro caso, c'\u00e8 un solo sistema remoto, quindi ci limitiamo a questo.<\/p>\n<p><\/p>\n<p>La regola \u00e8 pronta. Si noti che viene aggiunta automaticamente a tutti i membri della replicazione (nel nostro caso sono due). \u00c8 possibile creare quante pi\u00f9 regole si desidera, per qualsiasi numero di LUN e in entrambe le direzioni. Ad esempio, possiamo replicare parte dei LUN dal SAN1 al SAN2 per bilanciare il carico, e un'altra parte viceversa \u2013 dal SAN2 al SAN1.<\/p>\n<p><\/p>\n<p>SAN1. Subito dopo la creazione \u00e8 iniziata la sincronizzazione.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/86e1770336d40207ed9b3b6dc4249279.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>SAN2. Vediamo la stessa regola, ma la sincronizzazione \u00e8 gi\u00e0 terminata.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/f15b69af4de726d5c337d789c37b9cf8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>LUN1 su SAN1 \u00e8 nella funzione Primary, cio\u00e8 \u00e8 attivo. LUN1R su SAN2 \u00e8 nella funzione Secondary, cio\u00e8 \u00e8 in standby, nel caso ci sia un guasto di SAN1.<br \/>\nOra possiamo collegare il nostro LUN all'host.<\/p>\n<p><\/p>\n<p>Effettueremo il collegamento tramite iSCSI, anche se \u00e8 possibile farlo anche tramite FC. La configurazione del mapping per il LUN iSCSI nella replica \u00e8 praticamente identica a quella di uno scenario normale, quindi non la esamineremo dettagliatamente qui. Se necessario, questo processo \u00e8 descritto nell'articolo \"<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/tssolution\/blog\/432876\/\">Configurazione rapida<\/a><\/noindex>\u00bb. <\/p>\n<p><\/p>\n<p>L'unica differenza \u00e8 che creiamo il mapping nel menu \"Mapping di replicazione\".<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/62ceee2f7356a4716bb50b85ea31f0d6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Abbiamo configurato il mapping, abbiamo dato il LUN all'host. L'host ha riconosciuto il LUN.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/0bb675e5fead8d0222b03fa084223f7e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Lo formattiamo nel file system locale.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/09c707bf8037ea381cd7ec88b97c9b62.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Tutto, a questo punto la configurazione \u00e8 completata. Ora procederemo ai test.<\/p>\n<p><\/p>\n<h2 id=\"testirovanie\">Test<\/h2>\n<p><\/p>\n<p>Testeremo tre scenari principali.<\/p>\n<p><\/p>\n<ol>\n<li>Failover normale dei ruoli Secondary &gt; Primary. Il failover normale dei ruoli \u00e8 necessario nel caso, ad esempio, in cui nel data center principale dobbiamo eseguire alcune operazioni di manutenzione e, in quel momento, per garantire che i dati siano accessibili, trasferiamo il carico nel data center di riserva.<\/li>\n<li>Commutazione di emergenza dei ruoli Secondario &gt; Primario (guasto del centro dati). Questo \u00e8 lo scenario principale per cui esiste la replica, che pu\u00f2 aiutare a sopravvivere a un guasto totale del centro dati senza fermare il lavoro dell'azienda per un lungo periodo.<\/li>\n<li>Interruzione dei canali di comunicazione tra i centri dati. Verifica del corretto comportamento di due sistemi di archiviazione dati in condizioni in cui, per qualche motivo, il canale di comunicazione tra i centri dati non \u00e8 disponibile (ad esempio, un escavatore ha scavato nel posto sbagliato e ha rotto la fibra oscura).<\/li>\n<\/ol>\n<p><\/p>\n<p>Per iniziare, cominciamo a scrivere i dati sul nostro LUN (scriviamo file con dati casuali). Controlliamo subito che il canale di comunicazione tra i sistemi di archiviazione dati sia in uso. Questo \u00e8 facile da capire se apriamo il monitoraggio del carico delle porte responsabili della replica.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/bba2e0b14669a2c8ccef8a2d3eb336ed.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ora entrambi i sistemi di archiviazione dati hanno dati \"utili\", possiamo iniziare il test.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/62b0614cee954738e878609feb3a5e08.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Per precauzione, diamo un'occhiata ai valori di hash di uno dei file e annotiamoli.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/48e7dde27ef2371e722c72c6dc998c8f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h3 id=\"shtatnoe-pereklyuchenie-roley\">Commutazione di ruoli standard<\/h3>\n<p><\/p>\n<p>L'operazione di commutazione dei ruoli (cambiamento della direzione della replica) pu\u00f2 essere eseguita da qualsiasi sistema di archiviazione dati, ma \u00e8 necessario andare su entrambi, poich\u00e9 su quello Primario sar\u00e0 necessario disattivare il mapping, mentre su quello Secondario (che diventer\u00e0 Primario) sar\u00e0 necessario attivarlo.<\/p>\n<p><\/p>\n<p>Ora potrebbe sorgere una domanda legittima: perch\u00e9 non automatizzare questo processo? La risposta \u00e8 semplice: la replica \u00e8 un semplice mezzo di resilienza ai disastri, basato esclusivamente su operazioni manuali. Per automatizzare queste operazioni esiste la modalit\u00e0 metrocluster, che \u00e8 completamente automatizzata, ma la sua configurazione \u00e8 significativamente pi\u00f9 complessa. Scriveremo sulla configurazione del metrocluster nel prossimo articolo.<\/p>\n<p><\/p>\n<p>Sul sistema di archiviazione dati Primario disattiviamo il mapping per garantire l'interruzione della scrittura.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/f5afc222a966a1e1dd1d804b06b7963e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Successivamente, su uno dei sistemi di archiviazione dati (non importa se il Primario o il Secondario) nel menu \"Replica remota\" selezioniamo la nostra connessione REPL1 e clicchiamo su \"Cambia ruolo\".<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/7346bd30c549d2e263b5c37fbc412f05.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dopo alcuni secondi, LUN1R (sistema di archiviazione dati Secondario) diventa Primario.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/d87a7cf770a262c1c3bfb97bb75cf47d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Creiamo il mapping di LUN1R con il sistema di archiviazione dati 2.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/c1b2a04cd8ce34df833f720ba0932ae2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dopo di che, il nostro disco E: si collega automaticamente all'host, solo che questa volta \u00e8 \"arrivato\" da LUN1R.<\/p>\n<p><\/p>\n<p>Per precauzione, confrontiamo i valori di hash.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/b938253769cc660c66d7e42452f8909c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Identico. Test superato.<\/p>\n<p><\/p>\n<h3 id=\"avariynoe-pereklyuchenie-otkaz-cod-a\">Commutazione di emergenza. Guasto del centro dati<\/h3>\n<p><\/p>\n<p>Attualmente, il sistema di archiviazione dati Primario dopo la commutazione standard \u00e8 il sistema di archiviazione dati 2 e LUN1R, rispettivamente. Per simulare un guasto, disattiveremo l'alimentazione su entrambi i controller del sistema di archiviazione dati 2.<br \/>\nNon c'\u00e8 pi\u00f9 accesso.<\/p>\n<p><\/p>\n<p>Controlliamo cosa sta succedendo su SCD 1 (attualmente in riserva).<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/b38bc0b6004976a92ac0a94babfedddf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vediamo che il LUN Primario (LUN1R) non \u00e8 disponibile. \u00c8 apparso un messaggio di errore nei log, nel pannello informativo e anche nella stessa regola di replicazione. Di conseguenza, i dati dall'host non sono attualmente accessibili.<\/p>\n<p><\/p>\n<p>Cambiando il ruolo del LUN1 in Primario.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/aebb3adbdc037e559aa9d33350dec36c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Effettuiamo il mapping all'host.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/a98e09d40e218552ce0c917e13fac6b6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ci assicuriamo che il disco E sia apparso sull'host.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/5a01e43c692227460cd74d155efcd519.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Controlliamo l'hash.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/63520595bf8bda6e0bec27ed935f3714.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Tutto in ordine. L'interruzione del data center, che era attivo, \u00e8 stata gestita con successo dal SCD. Il tempo approssimativo impiegato per connettere il \u2018cambio\u2019 di replicazione e il collegamento del LUN dal data center di riserva \u00e8 stato di circa 3 minuti. \u00c8 chiaro che nella produzione reale tutto \u00e8 molto pi\u00f9 complesso e, oltre alle operazioni con il SCD, \u00e8 necessario eseguire molte altre operazioni nella rete, sugli host, nelle applicazioni. E nella realt\u00e0 questo intervallo di tempo sar\u00e0 significativamente pi\u00f9 lungo.<\/p>\n<p><\/p>\n<p>Qui vorremmo scrivere che tutto \u00e8 andato bene e il test \u00e8 stato completato con successo, ma non affrettiamoci. Il SCD principale \u00e8 \u2018gi\u00f9\u2019, sappiamo che quando \u00e8 \u2018caduto\u2019, era nel ruolo di Primario. Cosa succeder\u00e0 se si accende improvvisamente? Ci saranno due ruoli Primari, il che equivale a una corruzione dei dati? Controlliamo ora.<br \/>\nAndiamo a riaccendere il SCD che era spento. <\/p>\n<p><\/p>\n<p>Si avvia per alcuni minuti e poi torna in funzione dopo una breve sincronizzazione, ma gi\u00e0 nel ruolo di Secondario.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/c332b05c9a2ed31873d1e738009fcb12.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Tutto a posto. Non \u00e8 successo lo split-brain. Ci abbiamo pensato e, dopo un'interruzione, il SCD si riavvia sempre nel ruolo di Secondario, indipendentemente dal ruolo che aveva \u2018in vita\u2019. Ora possiamo affermare con certezza che il test di failover del data center \u00e8 riuscito.<\/p>\n<p><\/p>\n<h3 id=\"otkaz-kanalov-svyazi-mezhdu-cod-ami\">Interruzione dei canali di comunicazione tra i data center.<\/h3>\n<p><\/p>\n<p>L'obiettivo principale di questo test \u00e8 assicurarsi che il SCD non inizi a comportarsi in modo strano se perde temporaneamente i canali di comunicazione tra i due SCD, e poi li riottiene.<br \/>\nQuindi. Scolleghiamo i cavi tra gli SCD (imagine che siano stati rimossi da un escavatore).<\/p>\n<p><\/p>\n<p>Sul Primario vediamo che non c'\u00e8 connessione con il Secondario.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/42646193c62eeaa9f0e4e649e5a3be23.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Sul Secondario vediamo che non c'\u00e8 connessione con il Primario. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/14a28c3930bb6ac83e5bd10976577d18.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Funziona tutto normalmente e continuiamo a scrivere dati sul SCD principale, cio\u00e8, questi sono gi\u00e0 garantiti come diversi rispetto a quelli di riserva, quindi sono \u2018separati\u2019.<\/p>\n<p><\/p>\n<p>Dopo alcuni minuti \u2018ripariamo\u2019 il canale di comunicazione. Non appena gli SCD si vedono tra loro, la sincronizzazione dei dati si attiva automaticamente. Qui non \u00e8 richiesta alcuna azione da parte dell'amministratore.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/386a6e4b86166373a3858543572e3ac9.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dopo un po', la sincronizzazione si completa.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Resilienza ai disastri. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/e879fdebdc78505a74880f275de8f868.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>La connessione \u00e8 stata ripristinata, nessuna situazione anomala ha causato interruzioni nei canali di comunicazione e dopo l'accensione la sincronizzazione \u00e8 avvenuta automaticamente.<\/p>\n<p><\/p>\n<h2 id=\"vyvody\">Conclusioni<\/h2>\n<p><\/p>\n<p>Abbiamo esaminato la teoria \u2013 cosa e perch\u00e9 \u00e8 necessario, dove sono i vantaggi e dove gli svantaggi. Poi abbiamo configurato la replica sincrona tra due sistemi di archiviazione. <\/p>\n<p><\/p>\n<p>Successivamente sono stati eseguiti i test principali per il passaggio normale, il guasto del data center e l'interruzione dei canali di comunicazione. In tutti i casi, il sistema di archiviazione ha funzionato bene. Non ci sono state perdite di dati, le operazioni amministrative sono state ridotte al minimo per lo scenario manuale.<\/p>\n<p><\/p>\n<p>La prossima volta complicheremo la situazione e mostreremo come tutta questa logica funziona in un metrocluster automatizzato in modalit\u00e0 active-active, cio\u00e8 quando entrambi i sistemi di archiviazione sono principali e il comportamento in caso di guasti \u00e8 completamente automatizzato.<\/p>\n<p><\/p>\n<p>Vi preghiamo di scrivere i vostri commenti, saremo felici di critiche costruttive e consigli utili.<\/p>\n<p><\/p>\n<p>Alla prossima.<\/p>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/aerodisk\/blog\/456348\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0445\u0430\u0431\u0440\u0430! \u0422\u0435\u043c\u043e\u0439 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u0431\u0443\u0434\u0435\u0442 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u044f \u0441\u0440\u0435\u0434\u0441\u0442\u0432 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u0432 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u0445 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f AERODISK Engine. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u043d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u0432 \u043e\u0434\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043f\u0440\u043e \u043e\u0431\u0430 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0430: \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044e \u0438 \u043c\u0435\u0442\u0440\u043e\u043a\u043b\u0430\u0441\u0442\u0435\u0440, \u043d\u043e, \u043a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e, \u0441\u0442\u0430\u0442\u044c\u044f \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u0430\u0441\u044c \u0441\u043b\u0438\u0448\u043a\u043e\u043c \u0431\u043e\u043b\u044c\u0448\u043e\u0439, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043c\u044b \u0440\u0430\u0437\u0431\u0438\u043b\u0438 \u0441\u0442\u0430\u0442\u044c\u044e \u043d\u0430 \u0434\u0432\u0435 \u0447\u0430\u0441\u0442\u0438. \u041f\u043e\u0439\u0434\u0435\u043c \u043e\u0442 \u043f\u0440\u043e\u0441\u0442\u043e\u0433\u043e \u043a \u0441\u043b\u043e\u0436\u043d\u043e\u043c\u0443. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043c \u0438 \u043f\u0440\u043e\u0442\u0435\u0441\u0442\u0438\u0440\u0443\u0435\u043c \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u043d\u0443\u044e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26548,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35387","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"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, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0445\u0430\u0431\u0440\u0430!\" \/>\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\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-1\" \/>\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\udd47AERODISK Engine: \u041a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0445\u0430\u0431\u0440\u0430!\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-1\" \/>\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=\"2019-10-31T19:04:01+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:04:01+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\udd47AERODISK Engine: Resilienza ai disastri. Parte 1 | ProHoster","description":"Ciao, lettori di Habra!","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-1","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\udd47AERODISK Engine: \u041a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0445\u0430\u0431\u0440\u0430!","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-1","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:04:01+00:00","article:modified_time":"2019-10-31T19:04:01+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35387","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-02-08 20:27:18","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:04:24","updated":"2026-02-08 20:27:18","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\/35387","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=35387"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35387\/revisions"}],"predecessor-version":[{"id":157820,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35387\/revisions\/157820"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/26548"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=35387"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=35387"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=35387"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}