{"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: Continuit\u00e0 operativa. Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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! Il tema di questo articolo sar\u00e0 l'implementazione di strumenti di tolleranza ai guasti nei sistemi di storage AERODISK Engine. Inizialmente volevamo scrivere un articolo unico su entrambi gli strumenti: la replica e il metrocluster, ma purtroppo l'articolo \u00e8 diventato troppo ampio, quindi abbiamo deciso di suddividerlo in due parti. Procediamo dal semplice al complesso. In questo articolo configureremo e testeremo la replica sincrona \u2013 simuleremo un guasto in un data center e interromperemo il collegamento 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, ci faremo una breve introduzione su cosa sia la replica nei sistemi di storage.<\/p>\n<p><\/p>\n<h2 id=\"nemnogo-teorii\">Un po' di teoria<\/h2>\n<p><\/p>\n<p>La replica nei sistemi di storage \u00e8 un processo continuo che garantisce l'identit\u00e0 dei dati simultaneamente su pi\u00f9 sistemi di storage. Tecnicamente, la replica viene eseguita in due modi.<\/p>\n<p><\/p>\n<p><strong>Replica sincrona<\/strong> \u2013 \u00e8 la copia dei dati da uno storage primario a uno secondario con successiva conferma obbligatoria da entrambe le unit\u00e0 di storage che i dati sono stati scritti e confermati. Solo dopo la conferma da entrambe le parti (da entrambe le unit\u00e0 di storage) i dati sono considerati scritti e possono essere utilizzati. In questo modo si garantisce l'identit\u00e0 dei dati su tutte le unit\u00e0 di storage coinvolte nella replica.<\/p>\n<p><\/p>\n<p>Vantaggi di questo metodo:<\/p>\n<p><\/p>\n<ul>\n<li>I dati sono sempre identici su tutte le unit\u00e0 di storage<\/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, fibra ottica costosa, transceiver 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 danneggiati (intenzionalmente o accidentalmente) sulla unit\u00e0 di storage primaria, diventeranno automaticamente e istantaneamente danneggiati anche sulla secondaria, poich\u00e9 i dati sono sempre identici (questo \u00e8 un paradosso))<\/li>\n<\/ul>\n<p><\/p>\n<p><strong>Replica asincrona<\/strong> \u2013 \u00e8 anch'essa una copia dei dati dal sistema di archiviazione principale a quello secondario, ma con un certo ritardo e senza necessit\u00e0 di conferma della registrazione dall'altro lato. \u00c8 possibile lavorare sui dati immediatamente dopo la registrazione nel sistema principale, mentre sui dati secondari saranno disponibili dopo un certo periodo. In questo caso, la corrispondenza dei dati non \u00e8 affatto garantita. I dati nel sistema 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, la fibra ottica \u00e8 opzionale)<\/li>\n<li>Nessuna limitazione di distanza<\/li>\n<li>I dati nel sistema secondario non vengono danneggiati in caso di corruzione nel sistema principale (almeno per un certo periodo); se i dati diventano corrotti, \u00e8 sempre possibile interrompere la replica per evitare la corruzione dei dati nel sistema secondario<\/li>\n<\/ul>\n<p><\/p>\n<p>Contro:<\/p>\n<p><\/p>\n<ul>\n<li>I dati in diversi data center non sono mai identici<\/li>\n<\/ul>\n<p><\/p>\n<p>La scelta della modalit\u00e0 di replica dipende, quindi, dagli obiettivi aziendali. Se \u00e8 fondamentale avere esattamente gli stessi dati nel centro di elaborazione dati di backup (cio\u00e8, l'esigenza aziendale di RPO=0), \u00e8 necessario fare un investimento e accettare le limitazioni della replica sincronizzata. Se, invece, \u00e8 tollerabile una certa latenza nei dati o se semplicemente non ci sono fondi sufficienti, \u00e8 decisamente meglio optare per il metodo asincrono.<\/p>\n<p><\/p>\n<p>Mettiamo in evidenza separatamente una modalit\u00e0 (piuttosto, una topologia) chiamata metrocluster. Nella modalit\u00e0 metrocluster si utilizza la replica sincronizzata, ma, a differenza della replica tradizionale, il metrocluster consente a entrambe le SAN di operare in modalit\u00e0 attiva. In altre parole, non ci sono distinzioni tra i centri di dati attivi e di riserva. Le applicazioni operano simultaneamente con due SAN fisicamente situate in diversi centri di dati. 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 tema molto ampio e articolato, quindi dedicheremo un articolo separato a questo argomento, in continuazione a questo. <\/p>\n<p><\/p>\n<p>Molto spesso, quando parliamo di replica tramite storage, molte persone si chiedono: &gt; \u00abMolte applicazioni hanno i propri strumenti di replica, perch\u00e9 dovremmo usare la replica tramite storage? \u00c8 meglio o peggio?\u00bb<\/p>\n<p><\/p>\n<p>Non c'\u00e8 una risposta semplice, quindi presenteremo gli argomenti A FAVORE e CONTRO:<\/p>\n<p><\/p>\n<p>Argomenti A FAVORE della replica tramite storage:<\/p>\n<p><\/p>\n<ul>\n<li>Semplicit\u00e0 della soluzione. Con un unico strumento puoi replicare l'intero array di dati, indipendentemente dal tipo di carico e di applicazioni. Utilizzando la replica delle applicazioni, dovrai configurare ogni applicazione singolarmente. Se ce ne sono pi\u00f9 di due, \u00e8 estremamente laborioso e costoso (la replica delle applicazioni richiede, di norma, una licenza separata e a pagamento per ciascuna applicazione. Ma di questo parleremo pi\u00f9 avanti).<\/li>\n<li>Puoi replicare qualsiasi cosa \u2013 qualsiasi applicazione, qualsiasi dato \u2013 e saranno sempre coerenti. Molti (la maggior parte) delle applicazioni non dispongono di strumenti di replica, e le repliche tramite storage sono l'unico mezzo per garantire la protezione da disastri.<\/li>\n<li>Non \u00e8 necessario pagare in eccesso per le funzionalit\u00e0 di replica delle applicazioni. Di solito, ha un costo significativo, cos\u00ec come le licenze per la replica dello storage. Tuttavia, la licenza per la replica dello storage deve essere acquistata una sola volta, mentre la licenza per la replica delle applicazioni deve essere acquistata separatamente per ogni applicazione. Se ci sono molte applicazioni, ci\u00f2 comporta costi elevati, e il costo delle licenze per la replica dello storage diventa una goccia nell'oceano.<\/li>\n<\/ul>\n<p><\/p>\n<p>Argomenti CONTRO la replica dello storage:<\/p>\n<p><\/p>\n<ul>\n<li>La replica tramite applicazioni offre maggiore funzionalit\u00e0 dal punto di vista delle stesse applicazioni; l'applicazione conosce meglio i propri dati (cosa evidente), quindi ci sono pi\u00f9 opzioni per lavorare con essi.<\/li>\n<li>I produttori di alcune applicazioni non garantiscono la coerenza dei propri dati se si utilizza la replica con strumenti di terze parti.*<\/li>\n<\/ul>\n<p><\/p>\n<p>* - affermazione controversa. Ad esempio, una nota azienda produttrice di DBMS dichiarava per molto tempo che il loro DBMS poteva essere replicato correttamente solo con i loro strumenti, e che qualsiasi altra forma di replica (inclusa quella dello storage) non \u00e8 'vera'. Ma la realt\u00e0 ha dimostrato il contrario. Probabilmente (ma non \u00e8 certo) si tratta semplicemente di un tentativo non del tutto onesto di vendere ulteriori licenze ai clienti. <\/p>\n<p><\/p>\n<p>In molti casi, la replica da parte dello storage \u00e8 la soluzione migliore, poich\u00e9 \u00e8 pi\u00f9 semplice e meno costosa. Tuttavia, ci sono situazioni complesse in cui \u00e8 richiesta una funzionalit\u00e0 specifica delle applicazioni, e in questi casi \u00e8 necessario lavorare con la replica a livello di applicazione. <\/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>Configureremo la replica nel nostro laboratorio. In condizioni di laboratorio abbiamo emulato due data center (in realt\u00e0, due rack posti uno accanto all'altro come se fossero in edifici diversi). L'setup consiste in due unit\u00e0 di storage Engine N2, collegate tra loro tramite cavi in fibra ottica. A entrambe le unit\u00e0 di storage \u00e8 collegato un server fisico con Windows Server 2016, utilizzando Ethernet a 10Gb. L'installazione \u00e8 piuttosto semplice, ma questo non cambia il suo scopo.<\/p>\n<p><\/p>\n<p>Schematizzando, appare cos\u00ec:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/044f81f6145cd05695c236e21a3d9aba.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Logicamente, la replica \u00e8 organizzata nel seguente modo:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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 replica che abbiamo a disposizione.<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, per la modalit\u00e0 sincrona \u00e8 necessario utilizzare fibra ottica come supporto fisico e Ethernet a 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 data center fino a 2 millisecondi. In generale, funzioner\u00e0 anche con latenze pi\u00f9 elevate, ma ci saranno forti ritardi durante la scrittura (il che \u00e8 comprensibile); quindi, se stai contemplando la replica sincrona tra i data center, \u00e8 necessario verificare la qualit\u00e0 dell'ottica e le latenze.<\/p>\n<p><\/p>\n<p>Per la replica asincrona i requisiti non sono cos\u00ec severi. In effetti, non ci sono requisiti specifici. Qualsiasi connessione Ethernet funzionante andr\u00e0 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 (sia su rame che su fibra ottica). Per i progetti in cui \u00e8 assolutamente necessaria la replica attraverso un fabric SAN su Fibre Channel, stiamo attualmente sviluppando una soluzione corrispondente, ma finch\u00e9 non sar\u00e0 pronta, nel nostro caso \u00e8 disponibile solo Ethernet.<\/p>\n<p><\/p>\n<p>La replica pu\u00f2 funzionare tra qualsiasi sistema di archiviazione della serie ENGINE (N1, N2, N4), sia dai sistemi pi\u00f9 piccoli a quelli pi\u00f9 grandi e viceversa.<\/p>\n<p><\/p>\n<p>Le funzionalit\u00e0 di entrambi i modi di replica sono completamente identiche. Di seguito sono riportati ulteriori dettagli su ci\u00f2 che \u00e8 disponibile: <\/p>\n<p><\/p>\n<ul>\n<li>Replica 'one to one' o 'uno a uno', ovvero la variante classica con due data center, principale e di riserva.<\/li>\n<li>La replica \u00abone to many\u00bb o \u00abuno a molti\u00bb, ovvero un LUN pu\u00f2 essere replicato su pi\u00f9 sistemi di storage contemporaneamente.<\/li>\n<li>Attivazione, disattivazione e \u00abrivoluzionamento\u00bb della replica, rispettivamente, per abilitare, disabilitare o cambiare la direzione della replica.<\/li>\n<li>La replica \u00e8 disponibile sia per i gruppi RDG (Raid Distributed Group) che per i DDP (Dynamic Disk Pool). Tuttavia, un LUN del gruppo RDG pu\u00f2 essere replicato solo in un altro RDG. Con DDP funziona in modo simile.<\/li>\n<\/ul>\n<p><\/p>\n<p>Ci sono anche molte altre 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 di 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 mappatura<\/li>\n<\/ol>\n<p><\/p>\n<p>Un aspetto importante della configurazione della replica \u00e8 che le prime due fasi devono essere ripetute su un sistema di storage remoto, mentre la terza fase deve essere eseguita solo sul 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 tale scopo, \u00e8 necessario attivare le porte e impostarle <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 IP virtuale per la replica (VIP). Il VIP \u00e8 un indirizzo IP fluttuante, assegnato a due indirizzi \"fisici\" dei controller di storage (porte che abbiamo appena configurato). Sar\u00e0 l'interfaccia principale per la replica. Possiamo anche usare un VLAN se dobbiamo gestire il traffico taggato.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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 di un VIP per la replica \u00e8 simile a quello per la creazione di un VIP per l'input\/output (NFS, SMB, iSCSI). In questo caso, creiamo un VIP normale (senza VLAN), specificando obbligatoriamente che \u00e8 per la replica (senza questa indicazione non potremo aggiungere il VIP alla regola nel passaggio successivo).<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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 appartenere alla stessa sottorete degli IP delle porte tra cui \"fluttua\".<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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 sullo storage remoto, ovviamente con un IP diverso.<br \/>\nI VIP di diversi storage possono trovarsi in sottoreti diverse, ma \u00e8 fondamentale 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: Continuit\u00e0 operativa. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/3d43b4339277e50413cc9944c53e0d62.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>A questo punto, 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 si differenzia da quella normale solo per il fatto che la mappatura viene effettuata attraverso il menu speciale \"Mappatura della replica\". Per il resto, \u00e8 tutto come per la configurazione normale. Procediamo per ordine.<\/p>\n<p><\/p>\n<p>Nel pool R02 gi\u00e0 creato, \u00e8 necessario creare un LUN. Lo creiamo e lo chiamiamo LUN1.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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 sistema di storage remoto con la stessa capacit\u00e0. Creiamo. Per evitare confusione, chiameremo il LUN remoto LUN1R. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/bbd302358c2bd825a234da94b2410770.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Se avessimo bisogno di prendere un LUN gi\u00e0 esistente, durante la configurazione della replica questo LUN produttivo dovrebbe essere smontato dall'host, mentre sul sistema di storage remoto \u00e8 sufficiente creare un LUN vuoto di capacit\u00e0 identica.<\/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 collegamenti di replica.<\/h3>\n<p><\/p>\n<p>Dopo aver creato i LUN sul sistema di storage che sar\u00e0 attualmente principale (Primary), configuriamo la regola di replica di LUN1 su S\u0425D1 in LUN1R su S\u0425D2.<\/p>\n<p><\/p>\n<p>La configurazione avviene nel menu \"Replica remota\".<\/p>\n<p><\/p>\n<p>Creiamo la regola. A questo scopo, \u00e8 necessario specificare il destinatario della replica. Qui impostiamo anche il nome del collegamento e il tipo di replica (sincrona o asincrona).<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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 storage SAN2. Per aggiungere \u00e8 necessario utilizzare l'IP di gestione SAN (MGR) e il nome del LUN remoto in cui eseguiremo la replica (nel nostro caso LUN1R). Gli IP di gestione sono necessari solo durante la fase di aggiunta del collegamento; il traffico di replica non passer\u00e0 attraverso di essi, ma 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 mostrato nell'immagine qui sotto. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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 solo un sistema remoto, quindi ci limitiamo a questo.<\/p>\n<p><\/p>\n<p>La regola \u00e8 pronta. Nota che viene aggiunta automaticamente a tutti i partecipanti alla replica (nel nostro caso sono due). \u00c8 possibile creare quante pi\u00f9 regole si desidera, per qualsiasi numero di LUN e in qualsiasi direzione. Ad esempio, possiamo per bilanciare il carico replicare alcuni LUN da SAN1 a SAN2, mentre altri in senso inverso \u2013 da SAN2 a 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: Continuit\u00e0 operativa. 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: Continuit\u00e0 operativa. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/f15b69af4de726d5c337d789c37b9cf8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>LUN1 su SCD1 \u00e8 in ruolo Primario, quindi \u00e8 attivo. LUN1R su SCD2 \u00e8 in ruolo Secondario, quindi \u00e8 in standby nel caso in cui SCD1 fallisca.<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 tramite FC. La configurazione del mapping del LUN iSCSI nella replica non \u00e8 praticamente diversa dallo scenario normale, quindi non la tratteremo in dettaglio qui. Se necessario, questo processo \u00e8 descritto nell'articolo \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/tssolution\/blog\/432876\/\">Impostazione rapida<\/a><\/noindex>\u00bb. <\/p>\n<p><\/p>\n<p>L'unica differenza \u00e8 che creiamo il mapping nel menu \u00abMapping Replica\u00bb<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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 e dato il LUN all'host. L'host ha visto il LUN.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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: Continuit\u00e0 operativa. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/09c707bf8037ea381cd7ec88b97c9b62.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Tutto, la configurazione \u00e8 completa. Ora inizieranno i 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>Commuta normalmente i ruoli da Secondario a Primario. La commutazione normale dei ruoli \u00e8 necessaria nel caso in cui, ad esempio, nel data center principale dobbiamo eseguire operazioni di manutenzione e per questo periodo, affinch\u00e9 i dati siano disponibili, trasferiamo il carico nel data center di backup.<\/li>\n<li>Commutazione di emergenza dei ruoli da Secondario a Primario (guasto del data center). Questo \u00e8 lo scenario principale per cui esiste la replicazione, che pu\u00f2 contribuire a sopravvivere a un guasto totale del data center senza interrompere l'attivit\u00e0 aziendale per un lungo periodo.<\/li>\n<li>Interruzione dei canali di comunicazione tra i data center. Verifica del corretto funzionamento di due sistemi di archiviazione dati in condizioni in cui, per qualsiasi motivo, il canale di comunicazione tra i data center non \u00e8 disponibile (ad esempio, un escavatore ha scavato nel posto sbagliato e ha danneggiato la fibra ottica).<\/li>\n<\/ol>\n<p><\/p>\n<p>Per cominciare, iniziamo a scrivere dati sul nostro LUN (scriviamo file con dati casuali). Subito controlliamo cosa viene utilizzato nel canale di comunicazione tra i sistemi di archiviazione. \u00c8 facile capire se apriamo il monitoraggio del carico delle porte responsabili della replicazione.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/bba2e0b14669a2c8ccef8a2d3eb336ed.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ora entrambe le unit\u00e0 di archiviazione contengono dati 'utili', possiamo iniziare il test.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/62b0614cee954738e878609feb3a5e08.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Per sicurezza, diamo un'occhiata ai checksum di uno dei file e annotiamolo.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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\">Commute di ruoli regolare<\/h3>\n<p><\/p>\n<p>L'operazione di commutazione dei ruoli (cambiamento della direzione della replicazione) pu\u00f2 essere effettuata con qualsiasi unit\u00e0 di archiviazione, ma sar\u00e0 comunque necessario operare su entrambe, poich\u00e9 su quella Primaria sar\u00e0 necessario disattivare il mapping, e sulla Secondaria (che diventer\u00e0 Primaria) attivarlo.<\/p>\n<p><\/p>\n<p>\u00c8 lecito chiedersi perch\u00e9 non automatizzare questo processo. La risposta \u00e8 semplice: la replicazione \u00e8 un metodo di resilienza alle catastrofi basato esclusivamente su operazioni manuali. Per automatizzare queste operazioni esiste la modalit\u00e0 metrocluster, che \u00e8 completamente automatizzata, ma la sua configurazione \u00e8 notevolmente pi\u00f9 complessa. Scriveremo della configurazione del metrocluster nel prossimo articolo.<\/p>\n<p><\/p>\n<p>Sulla principale array di archiviazione disabilitiamo il mapping per garantire l'interruzione della scrittura.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/f5afc222a966a1e1dd1d804b06b7963e.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Poi su uno dei sistemi di archiviazione (non importa se principale o secondario) nel menu \"Replicazione remota\" selezioniamo la nostra connessione REPL1 e clicchiamo su \"Cambia ruolo\".<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/7346bd30c549d2e263b5c37fbc412f05.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dopo qualche secondo, LUN1R (sistema di archiviazione secondario) diventa Primary.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/d87a7cf770a262c1c3bfb97bb75cf47d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Effettuiamo il mapping di LUN1R con il sistema di archiviazione 2.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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, l'host collega automaticamente il nostro disco E:, solo che questa volta \u00e8 \"arrivato\" da LUN1R.<\/p>\n<p><\/p>\n<p>Per sicurezza, confrontiamo le somme hash.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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\">Failover. Guasto del Data Center.<\/h3>\n<p><\/p>\n<p>Attualmente, il sistema di archiviazione principale dopo il normale failover \u00e8 il sistema 2 e LUN1R, rispettivamente. Per simulare un guasto, disattiveremo l'alimentazione su entrambi i controllori di sistema 2.<br \/>\nNon c'\u00e8 pi\u00f9 accesso a essa.<\/p>\n<p><\/p>\n<p>Controlliamo cosa succede sullo storage 1 (attualmente in riserva).<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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 Primary LUN (LUN1R) non \u00e8 disponibile. \u00c8 comparso un messaggio di errore nei log, nel pannello informativo, e anche nella regola di replica stessa. Di conseguenza, i dati dall'host non sono attualmente accessibili.<\/p>\n<p><\/p>\n<p>Cambiamo il ruolo di LUN1 in Primary.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/aebb3adbdc037e559aa9d33350dec36c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Facciamo il mapping all'host.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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: Continuit\u00e0 operativa. 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: Continuit\u00e0 operativa. 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. Il fallimento del data center attivo \u00e8 stato gestito con successo dallo storage. Il tempo approssimativo che abbiamo impiegato per avviare la replica e collegare il LUN dal data center di riserva \u00e8 stato di circa 3 minuti. \u00c8 chiaro che nel mondo reale tutto \u00e8 molto pi\u00f9 complicato e, oltre alle operazioni con lo storage, \u00e8 necessario eseguire molte altre operazioni in rete, sugli host e nelle applicazioni. Nella pratica, questo intervallo di tempo sar\u00e0 significativamente pi\u00f9 lungo.<\/p>\n<p><\/p>\n<p>Vorremmo scrivere che \u00e8 tutto, il test \u00e8 stato completato con successo, ma non affrettiamoci. Lo storage principale \u00e8 'gi\u00f9', sappiamo che quando '\u00e8 caduto', era nel ruolo di Primary. Cosa succeder\u00e0 se si accende improvvisamente? Ci saranno due ruoli Primary, il che equivale a corruzione dei dati? Ora verifichiamo.<br \/>\nAndiamo ad accendere improvvisamente lo storage gi\u00f9. <\/p>\n<p><\/p>\n<p>Ci vogliono alcuni minuti per ricaricarsi e dopo un breve processo di sincronizzazione torna in funzione, ma come secondaria.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/c332b05c9a2ed31873d1e738009fcb12.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Tutto ok. Non c'\u00e8 stato alcun split brain. Ci abbiamo pensato, e dopo un guasto della SAN, si riavvia come secondaria, indipendentemente dal ruolo che aveva 'in vita'. Ora possiamo dire con certezza che il test di failover del data center \u00e8 andato a buon fine.<\/p>\n<p><\/p>\n<h3 id=\"otkaz-kanalov-svyazi-mezhdu-cod-ami\">Guasto dei canali di comunicazione tra i data center<\/h3>\n<p><\/p>\n<p>L'obiettivo principale di questo test \u00e8 assicurarsi che la SAN non inizi a comportarsi in modo strano se perde temporaneamente i canali di comunicazione tra due SAN, e poi li ripristina.<br \/>\nDunque. Scollegiamo i cavi tra le SAN (immaginiamo che un escavatore li abbia colpiti).<\/p>\n<p><\/p>\n<p>Sul primary vediamo che non c'\u00e8 connessione con il secondario.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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 primary. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. Parte 1\" src=\"\/wp-content\/uploads\/2019\/06\/14a28c3930bb6ac83e5bd10976577d18.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Tutto funziona correttamente, e continuiamo a scrivere dati sulla SAN principale, quindi ora sono gi\u00e0 garantita diverse dalla riserva, cio\u00e8 'si sono separate'.<\/p>\n<p><\/p>\n<p>Dopo alcuni minuti ripristiniamo il canale di comunicazione. Non appena le SAN si riconoscono, la sincronizzazione dei dati si attiva automaticamente. Qui non \u00e8 richiesto nulla dall'amministratore.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"AERODISK Engine: Continuit\u00e0 operativa. 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: Continuit\u00e0 operativa. 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, non ci sono state situazioni anomale e l'interruzione dei canali di comunicazione non ha causato problemi; dopo l'accensione, la sincronizzazione \u00e8 avvenuta automaticamente.<\/p>\n<p><\/p>\n<h2 id=\"vyvody\">Conclusioni<\/h2>\n<p><\/p>\n<p>Abbiamo analizzato 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 effettuati i test principali per il passaggio regolare, il guasto del data center e l'interruzione dei canali di comunicazione. In tutti i casi, il sistema di archiviazione ha funzionato correttamente. Non ci sono stati perdite di dati e 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 primari e il comportamento in caso di guasti \u00e8 completamente automatizzato.<\/p>\n<p><\/p>\n<p>Vi preghiamo di scrivere commenti, saremo felici di critiche costruttive e consigli utili.<\/p>\n<p><\/p>\n<p>Arrivederci.<\/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.0.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! \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\" \/>\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.0.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! \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\" \/>\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: Disaster Recovery. Parte 1 | ProHoster","description":"Ciao, lettori di Habr! Il tema di questo articolo sar\u00e0 l'implementazione di soluzioni di disaster recovery nei sistemi di archiviazione AERODISK Engine. Inizialmente volevamo scrivere un unico articolo su entrambe le soluzioni: la replicazione e il metrocluster, ma, sfortunatamente, l'articolo \u00e8 risultato troppo lungo, quindi lo abbiamo suddiviso in due parti. Procederemo dal semplice al complesso. In questo articolo configureremo e testeremo la sincronizzazione.","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! \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","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}]}}