{"id":36263,"date":"2019-10-31T22:10:35","date_gmt":"2019-10-31T19:10:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/aerodisk-engine-katastrofoustojchivost-chast-2-metroklaster\/"},"modified":"2019-10-31T22:10:35","modified_gmt":"2019-10-31T19:10:35","slug":"aerodisk-engine-katastrofoustojchivost-chast-2-metroklaster","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-2-metroklaster","title":{"rendered":"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/7671ec455e464b7fe98b0b8ffcd38e24.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ciao lettori di Habr! Nell'articolo precedente abbiamo parlato di un semplice metodo per la resilienza ai disastri nei sistemi di storage AERODISK ENGINE: la replica. In questo articolo ci tufferemo in un argomento pi\u00f9 complesso e interessante: il metrocluster, ovvero un sistema di protezione automatizzata contro i disastri per due datacenter, che consente il funzionamento dei datacenter in modalit\u00e0 active-active. Racconteremo, mostreremo, rompiamo e ripariamo.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2 id=\"kak-obychno-v-nachale-teoriya\">Come al solito, iniziamo con la teoria<\/h2>\n<p><\/p>\n<p>Il metrocluster \u00e8 un cluster distribuito su pi\u00f9 sedi all'interno di una citt\u00e0 o di un'area. La parola \"cluster\" ci suggerisce chiaramente che il complesso \u00e8 automatizzato, il che significa che il passaggio dei nodi del cluster in caso di guasti (failover) avviene automaticamente. <\/p>\n<p><\/p>\n<p>Qui si trova la principale differenza tra un metrocluster e una replica standard. Automazione delle operazioni. In caso di eventi problematici (guasto del data center, interruzione dei collegamenti, ecc.), il sistema di storage eseguir\u00e0 autonomamente le azioni necessarie per garantire la disponibilit\u00e0 dei dati. Con le repliche tradizionali, queste azioni sono eseguite interamente o parzialmente a mano dall'amministratore.<\/p>\n<p><\/p>\n<h3 id=\"dlya-chego-eto-nuzhno\">A cosa serve?<\/h3>\n<p><\/p>\n<p>L'obiettivo principale che i clienti perseguono usando le varie implementazioni del metrocluster \u00e8 ridurre al minimo l'RTO (Recovery Time Objective). In altre parole, ridurre il tempo per il ripristino dei servizi IT dopo un'interruzione. Se si utilizza una replica standard, il tempo di ripristino sar\u00e0 sempre superiore a quello richiesto da un metrocluster. Perch\u00e9? \u00c8 molto semplice. L'amministratore deve essere presente e commutare la replica manualmente, mentre il metrocluster lo fa automaticamente.<\/p>\n<p><\/p>\n<p>Se non avete un amministratore dedicato che monitori 24 ore su 24, 7 giorni su 7, senza mangiare, bere, fumare o ammalarsi, non \u00e8 possibile garantire che un amministratore sar\u00e0 disponibile per il passaggio manuale durante un guasto. <\/p>\n<p><\/p>\n<p>Di conseguenza, il RTO in assenza di un metrocluster o di un amministratore immortale di livello 99 sar\u00e0 pari alla somma dei tempi di switch di tutti i sistemi e al massimo intervallo di tempo dopo il quale l'amministratore inizier\u00e0 a lavorare garantito con il sistema di archiviazione e i sistemi ad esso collegati. <\/p>\n<p><\/p>\n<p>Pertanto, giungiamo alla conclusione evidente che il metrocluster deve essere utilizzato nel caso in cui il requisito per il RTO sia in minuti, e non in ore o giorni. Cio\u00e8, quando, in caso del peggior crollo del data center, il dipartimento IT deve assicurare all'azienda il ripristino dell'accesso ai servizi IT entro pochi minuti o addirittura secondi.<\/p>\n<p><\/p>\n<h3 id=\"kak-eto-rabotaet\">Come funziona?<\/h3>\n<p><\/p>\n<p>A livello inferiore, il metrocluster utilizza un meccanismo di replica dati sincronizzata, che abbiamo descritto nel precedente articolo (vedi <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/aerodisk\/blog\/456348\/\">link<\/a><\/noindex>). Poich\u00e9 la replica \u00e8 sincronizzata, anche i requisiti sono corrispondenti e, per essere pi\u00f9 precisi:<\/p>\n<p><\/p>\n<ul>\n<li>fibra ottica come fisica, Ethernet da 10 gigabit (o superiore);<\/li>\n<li>la distanza tra i data center non supera i 40 chilometri;<\/li>\n<li>la latenza del canale ottico tra i data center (tra gli storage) fino a 5 millisecondi (ottimale 2).<\/li>\n<\/ul>\n<p><\/p>\n<p>Tutti questi requisiti sono raccomandati, il che significa che il metrocluster funzioner\u00e0 anche se non vengono rispettati, ma \u00e8 importante comprendere che le conseguenze della non osservanza di questi requisiti equivalgono a un rallentamento delle prestazioni di entrambi gli storage nel metrocluster.<\/p>\n<p><\/p>\n<p>Quindi, per trasferire dati tra gli storage, si utilizza la replica sincronizzata; ma come avviene il passaggio automatico delle repliche e, soprattutto, come evitare il problema dello split-brain? A questo livello, viene utilizzata un'entit\u00e0 aggiuntiva: l'arbitro. <\/p>\n<p><\/p>\n<h3 id=\"kak-rabotaet-arbitr-i-v-chem-ego-zadacha\">Come funziona l'arbitro e qual \u00e8 il suo compito?<\/h3>\n<p><\/p>\n<p>L'arbitro \u00e8 una piccola macchina virtuale o un cluster hardware che deve essere avviato in una terza posizione (ad esempio, in ufficio) e deve garantire l'accesso agli storage tramite ICMP e SSH. Dopo l'avvio, l'arbitro deve impostare l'IP, e poi, dal lato degli storage, indicare il suo indirizzo, pi\u00f9 gli indirizzi dei controller remoti che partecipano al metrocluster. Dopo questo, l'arbitro \u00e8 pronto per il lavoro.<\/p>\n<p><\/p>\n<p>L'arbitro esegue un monitoraggio costante di tutti i sistemi di archiviazione nel metrocluster e, in caso di indisponibilit\u00e0 di un dato sistema di archiviazione, dopo aver confermato l'indisponibilit\u00e0 da un altro partecipante al cluster (uno dei sistemi di archiviazione \"attivi\"), decide di avviare la procedura di commutazione delle regole di replica e di mappatura.<\/p>\n<p><\/p>\n<p>Un aspetto molto importante. L'arbitro deve sempre trovarsi in un'area diversa da quella in cui si trovano i sistemi di archiviazione, quindi n\u00e9 nel Centro dati 1, dove si trova il sistema di archiviazione 1, n\u00e9 nel Centro dati 2, dove \u00e8 installato il sistema di archiviazione 2. <\/p>\n<p><\/p>\n<p>Perch\u00e9? Perch\u00e9 solo cos\u00ec l'arbitro, utilizzando uno dei sistemi di archiviazione rimasti attivi, pu\u00f2 identificare in modo chiaro e senza errori il fallimento di uno dei due siti in cui si trovano i sistemi di archiviazione. Qualsiasi altro modo di posizionare l'arbitro potrebbe portare a un problema di split-brain. <\/p>\n<p><\/p>\n<h3 id=\"teper-pogruzimsya-v-detali-raboty-arbitra\">Ora immergiamoci nei dettagli del funzionamento dell'arbitro.<\/h3>\n<p><\/p>\n<p>Sull'arbitro sono attivi diversi servizi che interrogano costantemente tutti i controller dei sistemi di archiviazione. Se il risultato dell'interrogazione differisce da quello precedente (disponibile\/non disponibile), viene registrato in un piccolo database che funziona anch'esso sull'arbitro.<\/p>\n<p><\/p>\n<p><strong>Esaminiamo pi\u00f9 dettagliatamente la logica di funzionamento dell'arbitro.<\/strong><\/p>\n<p><\/p>\n<p><u>Passaggio 1. Identificazione dell'indisponibilit\u00e0.<\/u> Un evento di segnalazione di guasto del sistema di archiviazione \u00e8 l'assenza di ping da entrambi i controller di un sistema di archiviazione per un periodo di 5 secondi. <\/p>\n<p><\/p>\n<p><u>Passo 2. Avvio della procedura di commutazione. <\/u>Dopo che l'arbitro ha compreso che uno dei sistemi di archiviazione non \u00e8 disponibile, invia una richiesta al sistema di archiviazione 'vivo' per accertarsi che quello 'morto' sia effettivamente non operativo. <\/p>\n<p><\/p>\n<p>Dopo aver ricevuto tale comando dall'arbitro, il secondo sistema di archiviazione (quello vivo) verifica ulteriormente la disponibilit\u00e0 del primo sistema di archiviazione che \u00e8 andato gi\u00f9 e, se non \u00e8 disponibile, invia all'arbitro una conferma della sua supposizione. Il sistema di archiviazione non \u00e8 effettivamente disponibile. <\/p>\n<p><\/p>\n<p>Dopo aver ricevuto tale conferma, l'arbitro avvia la procedura remota di commutazione della replica e di attivazione della mappatura su quelle repliche che erano attive (primary) sul sistema di archiviazione che \u00e8 andato gi\u00f9, e invia un comando al secondo sistema di archiviazione per trasformare queste repliche da secondary a primary e attivare la mappatura. Il secondo sistema di archiviazione esegue quindi tali procedure, dopo di che garantisce l'accesso agli LUN persi da esso.<\/p>\n<p><\/p>\n<p>Perch\u00e9 \u00e8 necessaria una verifica aggiuntiva? Per il quorum. Questo significa che la maggioranza del numero dispari totale (3) di partecipanti al cluster deve confermare il guasto di uno dei nodi del cluster. Solo allora questa decisione sar\u00e0 veramente corretta. \u00c8 necessario per evitare commutazioni errate e, di conseguenza, il problema dello split-brain. <\/p>\n<p><\/p>\n<p>Il Passo 2 richiede circa 5-10 secondi, quindi, tenendo conto del tempo necessario per determinare l'indisponibilit\u00e0 (5 secondi), entro 10-15 secondi dopo il guasto della LUN, il sistema di archiviazione che \u00e8 andato in down sar\u00e0 automaticamente disponibile per collaborare con il sistema di archiviazione attivo. <\/p>\n<p><\/p>\n<p>\u00c8 chiaro che per evitare interruzioni della connessione con gli host, \u00e8 anche necessario prendersi cura della corretta configurazione dei timeout sugli host. Il timeout raccomandato \u00e8 di almeno 30 secondi. Ci\u00f2 impedir\u00e0 all'host di interrompere la connessione con il sistema di archiviazione durante il passaggio del carico in caso di guasto e garantir\u00e0 l'assenza di interruzioni nella scrittura e lettura.<\/p>\n<p><\/p>\n<blockquote><p>Aspetta un attimo, quindi se il metrocluster funziona cos\u00ec bene, a cosa serve la replica normale? <\/p><\/blockquote>\n<p>In realt\u00e0, le cose non sono cos\u00ec semplici. <\/p>\n<p><\/p>\n<h3 id=\"rassmotrim-plyusy-i-minusy-metroklastera\">Esaminiamo i pro e i contro del metrocluster.<\/h3>\n<p><\/p>\n<p>Quindi, abbiamo capito che i vantaggi evidenti del metrocluster rispetto alla replica tradizionale sono:<\/p>\n<p><\/p>\n<ul>\n<li>Automazione completa, garantendo un tempo di recupero minimo in caso di disastro;<\/li>\n<li>E tutto :-).<\/li>\n<\/ul>\n<p><\/p>\n<p>Ora, attenzione, gli svantaggi:<\/p>\n<p><\/p>\n<ul>\n<li>Costo della soluzione. Sebbene il metrocluster nei sistemi Aerodisks non richieda ulteriori licenze (si utilizza la stessa licenza della replica), il costo sar\u00e0 comunque superiore rispetto all'uso della replica sincronizzata. Sar\u00e0 necessario implementare tutti i requisiti per la replica sincronizzata, oltre ai requisiti per il metrocluster, che riguardano la commutazione aggiuntiva e un'ulteriore posizione (vedi pianificazione del metrocluster);<\/li>\n<li>Complesso da gestire. Il metrocluster \u00e8 strutturato in modo significativamente pi\u00f9 complesso rispetto a una replica tradizionale e richiede molta pi\u00f9 attenzione e risorse per la pianificazione, la configurazione e la documentazione.<\/li>\n<\/ul>\n<p><\/p>\n<p>In conclusione. <strong>Il metrocluster \u00e8 sicuramente una soluzione molto tecnologica e di alta qualit\u00e0 quando \u00e8 realmente necessario garantire un RTO in secondi o minuti.<\/strong> Tuttavia, se non \u00e8 questo il caso e un RTO nell'arco di ore \u00e8 accettabile per l'azienda, non ha senso usare un cannone per colpire un passero. \u00c8 sufficiente una normale replica di tipo lavorativo, dato che un metrocluster comporterebbe costi aggiuntivi e una complessit\u00e0 maggiore per l'infrastruttura IT.<\/p>\n<p><\/p>\n<h2 id=\"planirovanie-metroklastera\">Pianificazione del metrocluster<\/h2>\n<p><\/p>\n<p>Questa sezione non pretende di essere una guida esaustiva alla progettazione di un metrocluster, ma mostra solo le principali direzioni da esplorare se desiderate costruire un sistema di questo tipo. Pertanto, durante l'implementazione reale del metrocluster, \u00e8 fondamentale consultarsi con il produttore della soluzione di archiviazione (cio\u00e8 noi) e altri sistemi correlati.<\/p>\n<p><\/p>\n<h3 id=\"ploschadki\">Siti<\/h3>\n<p><\/p>\n<p>Come menzionato sopra, per un metrocluster sono necessarie almeno tre sedi. Due data center dove opereranno le soluzioni di archiviazione e i sistemi correlati, e una terza sede dove operer\u00e0 l'arbitro.<\/p>\n<p><\/p>\n<p>La distanza raccomandata tra i data center \u00e8 di non oltre 40 chilometri. Distanze maggiori comporteranno molto probabilmente ritardi aggiuntivi, che in un metrocluster sono estremamente indesiderabili. Ricordiamo che i ritardi devono essere fino a 5 millisecondi, anche se \u00e8 preferibile rimanere entro 2.<\/p>\n<p><\/p>\n<p>\u00c8 consigliabile verificare i ritardi anche durante la fase di pianificazione. Qualsiasi provider di rete in fibra ottica di un certo livello pu\u00f2 organizzare un controllo di qualit\u00e0 piuttosto rapidamente. <\/p>\n<p><\/p>\n<p>Per quanto riguarda i ritardi fino all'arbitro (ossia tra il terzo soggetto e i due primi), la soglia raccomandata per i ritardi \u00e8 di 200 millisecondi, quindi \u00e8 adatta una normale connessione VPN aziendale sopra la rete Internet.<\/p>\n<p><\/p>\n<h3 id=\"kommutaciya-i-set\">Commuta e rete<\/h3>\n<p><\/p>\n<p>A differenza dello schema di replica, dove \u00e8 sufficiente connettere le SAN di diversi siti, lo schema del metrocluster richiede la connessione degli host a entrambe le SAN in siti diversi. Per chiarire la differenza, entrambi gli schemi sono indicati di seguito.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/12334c29a498f686e8eb946daab587c1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/46db8c81d15be3f89e1f9dbee4489e3b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Come si pu\u00f2 vedere dallo schema, gli host del sito 1 si connettono sia alla SAN1 che alla SAN2. Viceversa, anche gli host del sito 2 si connettono sia alla SAN2 che alla SAN1. Ogni host pu\u00f2 vedere entrambe le SAN. Questo \u00e8 un requisito fondamentale per il funzionamento del metrocluster.<\/p>\n<p><\/p>\n<p>Naturalmente, non \u00e8 necessario connettere ogni host tramite un cavo in fibra ottica a un altro data center; non ci sarebbero abbastanza porte e cavi. Tutte queste connessioni devono essere realizzate tramite switch Ethernet 10G+ o FibreChannel 8G+ (FC \u00e8 utilizzato solo per il collegamento degli host con l'SAN per IO, mentre il canale di replica \u00e8 attualmente disponibile solo tramite IP (Ethernet 10G+). <\/p>\n<p><\/p>\n<p>Ora qualche parola sulla topologia di rete. Un punto importante \u00e8 la corretta configurazione delle sottoreti. \u00c8 necessario definire fin da subito diverse sottoreti per i seguenti tipi di traffico:<\/p>\n<p><\/p>\n<ul>\n<li>Sottorete per la replica, attraverso la quale verranno sincronizzati i dati tra gli SAN. Possono essercene pi\u00f9 di una; in questo caso, dipende dalla topologia di rete attuale (gi\u00e0 implementata). Se ce ne sono due, ovviamente deve essere configurato il routing tra di esse;<\/li>\n<li>Sottoreti di archiviazione dei dati, tramite le quali gli host accederanno alle risorse SAN (se si tratta di iSCSI). Deve esserci una sottorete in ciascun data center;<\/li>\n<li>Sottoreti di gestione, ovvero tre sottoreti instradabili in tre localit\u00e0, da cui viene gestito l'SAN e dove si trova anche l'arbitro.<\/li>\n<\/ul>\n<p><\/p>\n<p>Le sottoreti per accedere alle risorse degli host non sono oggetto di questo nostro esame, poich\u00e9 dipendono fortemente dai requisiti specifici. <\/p>\n<p><\/p>\n<p>La separazione del traffico diverso in sottoreti distinte \u00e8 cruciale (soprattutto \u00e8 importante isolare le repliche dall'I\/O), poich\u00e9 mescolare tutto il traffico in un'unica sottorete \"grassa\" rende impossibile la gestione di questo flusso, e in un contesto di due data center questo pu\u00f2 anche causare diversi tipi di collisioni di rete. Non approfondiremo ulteriormente questo aspetto in questo articolo, poich\u00e9 per la pianificazione di una rete estesa tra i data center si pu\u00f2 consultare la documentazione dei produttori di apparecchiature di rete, dove \u00e8 trattato in dettaglio.<\/p>\n<p><\/p>\n<h3 id=\"konfiguraciya-arbitra\">Configurazione dell'arbitro<\/h3>\n<p><\/p>\n<p>L'arbitro deve garantire l'accesso a tutte le interfacce di gestione dello storage secondo i protocolli ICMP e SSH. \u00c8 inoltre importante considerare la resilienza dell'arbitro. Qui c'\u00e8 un aspetto da considerare.<\/p>\n<p><\/p>\n<p>La resilienza dell'arbitro \u00e8 molto auspicabile, ma non obbligatoria. E se l'arbitro fallisse in modo imprevisto?<\/p>\n<p><\/p>\n<ul>\n<li>Il funzionamento del metro-cluster rimarr\u00e0 inalterato, poich\u00e9 l'arbitro non influisce assolutamente sul funzionamento del metro-cluster (il suo compito \u00e8 quello di indirizzare il carico tra i datacenter in modo tempestivo).<\/li>\n<li>Tuttavia, nel caso in cui l'arbitro, per qualsiasi motivo, dovesse cadere e \u00abperdere\u00bb l'emergenza nel datacenter, non ci sarebbe alcun cambio, perch\u00e9 non ci sarebbero ordini da dare per effettuare la commutazione e organizzare il quorum. In questo caso, il metro-cluster si trasformerebbe in un normale schema di replica, che dovr\u00e0 essere commutato manualmente durante un'emergenza, con un impatto sull'RTO.<\/li>\n<\/ul>\n<p><\/p>\n<p>Cosa ne deriva da tutto ci\u00f2? Se \u00e8 davvero necessario garantire un RTO minimo, \u00e8 necessario assicurare l'affidabilit\u00e0 dell'arbitro. Ci sono due opzioni per farlo:<\/p>\n<p><\/p>\n<ul>\n<li>Eseguire una virtual machine con l'arbitro su un hypervisor a elevate prestazioni, dal momento che tutti gli hypervisor moderni supportano la tolleranza ai guasti.<\/li>\n<li>Se nella terza sede (nel nostro ufficio simulato) non si desidera configurare un cluster adeguato e non esiste un cluster di hypervisor, abbiamo previsto una soluzione hardware per l'arbitro, disponibile in un'unit\u00e0 da 2U, che ospita due server x86 standard e che pu\u00f2 resistere a un guasto locale.<\/li>\n<\/ul>\n<p><\/p>\n<p>Consigliamo vivamente di garantire la resilienza dell'arbitro, anche se nel funzionamento normale non \u00e8 necessaria per il metro-cluster. Ma come dimostrano sia la teoria che la pratica, se si costruisce un'infrastruttura realmente affidabile e resistente ai disastri, \u00e8 meglio non correre rischi. \u00c8 preferibile proteggere se stessi e la propria attivit\u00e0 dalla \"legge di Murphy\", ovvero evitare il guasto simultaneo dell'arbitro e di uno dei siti in cui \u00e8 collocato il sistema di storage.<\/p>\n<p><\/p>\n<h3 id=\"arhitektura-resheniya\">Architettura della soluzione<\/h3>\n<p><\/p>\n<p>Tenendo conto dei requisiti sopra menzionati, otteniamo la seguente architettura generale della soluzione.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/e60f67d6705d940f1c06b06328bf99a5.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Le LUN devono essere distribuiti uniformemente su due sedi per evitare sovraccarichi eccessivi. Inoltre, nella dimensione di entrambi i data center, \u00e8 necessario prevedere non solo il doppio della capacit\u00e0 (necessaria per la memorizzazione dei dati contemporaneamente su due sistemi di archiviazione), ma anche il doppio delle prestazioni in IOPS e MB\/s, per evitare la degradazione delle applicazioni in caso di guasto di uno dei data center.<\/p>\n<p><\/p>\n<p>\u00c8 importante sottolineare che, con un approccio corretto alla dimensione (cio\u00e8, a condizione che abbiamo previsto adeguati limiti superiori per gli IOPS e i MB\/s, nonch\u00e9 le risorse necessarie di CPU e RAM), in caso di guasto di uno dei sistemi di archiviazione nel metro cluster non ci sar\u00e0 un significativo calo delle prestazioni durante il funzionamento temporaneo su un solo sistema di archiviazione.<\/p>\n<p><\/p>\n<p>Questo \u00e8 dovuto al fatto che, nel lavoro simultaneo di due piattaforme, la replica sincrona in uso \"consuma\" met\u00e0 delle prestazioni in scrittura, poich\u00e9 ogni transazione deve essere registrata su due sistemi di storage (simile a RAID-1\/10). Cos\u00ec, in caso di guasto di uno dei sistemi di storage, l'impatto della replica scompare temporaneamente (fino a quando il sistema di storage guasto non viene ripristinato), e otteniamo un raddoppio delle prestazioni in scrittura. Dopo che i LUN del sistema di storage guasto sono stati riavviati su quello funzionante, questo raddoppio delle prestazioni svanisce a causa del carico proveniente dai LUN dell'altro sistema di storage, e torniamo al livello di prestazioni che avevamo prima del \"guasto\", ma solo all'interno di una singola piattaforma. <\/p>\n<p><\/p>\n<p>Con un sizing corretto, \u00e8 possibile garantire condizioni in cui gli utenti non percepiranno affatto il guasto dell'intero sistema di storage. Ripetiamo, per\u00f2, che ci\u00f2 richiede un sizing molto attento, al quale, tra l'altro, \u00e8 possibile contattarci gratuitamente :-).<\/p>\n<p><\/p>\n<h2 id=\"nastroyka-metroklastera\">Configurazione del metrocluster<\/h2>\n<p><\/p>\n<p>La configurazione del metrocluster \u00e8 molto simile alla configurazione della replica ordinaria, che abbiamo descritto in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/aerodisk\/blog\/456348\/\">articolo precedente<\/a><\/noindex>. Perci\u00f2, ci concentreremo solo sulle differenze. Abbiamo configurato in laboratorio un banco di prova basato sull'architettura di cui sopra, ma in versione minima: due archiviazioni collegate tramite Ethernet 10G, due switch 10G e un host che si connette tramite gli switch a entrambe le archiviazioni utilizzando porte 10G. L'arbitro funziona su una macchina virtuale.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/04e318609929553ed651fd702f0c7327.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Quando si configurano gli IP virtuali (VIP) per la replica, \u00e8 necessario scegliere il tipo di VIP \u2013 per il metrocluster.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/ym\/aw\/89\/ymaw89gofhplngagm5nvveg4oe0.png\"><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/974acf7aad3244c48049d09ff9b99a52.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>Abbiamo creato due collegamenti di replica per due LUN e li abbiamo distribuiti su due archiviazioni: LUN TEST Primary su Archiviazione 1 (collegamento METRO), LUN TEST2 Primary per Archiviazione 2 (collegamento METRO2).<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/7ff6c2bcf23bfa48974ba3ae5538e424.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Per queste abbiamo configurato due target identici (nel nostro caso iSCSI, ma \u00e8 supportato anche FC, la logica di configurazione \u00e8 la stessa).<\/p>\n<p><\/p>\n<p>Archiviazione 1:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/e8378f8a65ea7886d9bf0b97b76394c4.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Archiviazione 2:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/dee6c339ff0b15ec24f8d2d19d874921.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Per i collegamenti di replica abbiamo effettuato il mapping su ciascuna archiviazione.<\/p>\n<p><\/p>\n<p>Archiviazione 1:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/c71dcc46058731acb7fdf44a2ae52f56.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Archiviazione 2:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/f473a0862ccb11d55ff1b1f13d5db87e.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Abbiamo configurato il multipath e lo abbiamo presentato sull'host.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/e3eea3967f75388cf5bd5aeb8ec4f5df.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/20ce2c6f94a1ec507704b2adabe7f7fa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h3 id=\"nastraivaem-arbitra\">Configuriamo l'arbitro<\/h3>\n<p><\/p>\n<p>Con l'arbitro non bisogna fare particolari operazioni, basta attivarlo sul terzo controller, assegnargli un IP e configurare l'accesso tramite ICMP e SSH. La configurazione vera e propria viene eseguita sulle unit\u00e0 di storage. \u00c8 sufficiente configurare l'arbitro una sola volta su uno qualsiasi dei controller delle unit\u00e0 di storage nel metrocluster, queste impostazioni saranno propagate automaticamente a tutti i controller.<\/p>\n<p><\/p>\n<p>Nella sezione Replica remota &gt;&gt; Metrocluster (su qualsiasi controller) &gt;&gt; pulsante \"Configura\".<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/sy\/h0\/x-\/syh0x-gywrz2yu8w9mk0us5mwcg.jpeg\"><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/c83c1dd267dcbe0203af23e2f10772c4.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>Inseriamo l'IP dell'arbitro, cos\u00ec come le interfacce di gestione dei due controller dell'unit\u00e0 di storage remota.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/760f6f703f5f0eef1072c4c6ca393089.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dopo ci\u00f2, \u00e8 necessario attivare tutti i servizi (pulsante \"Riavvia tutto\"). In caso di riconfigurazione in futuro, \u00e8 fondamentale riavviare i servizi affinch\u00e9 le impostazioni abbiano effetto.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/ad25df4a17879bcddb45480368c51095.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Verifichiamo che tutti i servizi siano attivi.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/oh\/mw\/xl\/ohmwxl5jry0dufgfamey0ddxris.jpeg\"><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/15b658834b7682c6cc3b76882ad9e4ab.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p><strong>A questo punto, la configurazione del metrocluster \u00e8 completa.<\/strong><\/p>\n<p><\/p>\n<h2 id=\"krash-test\">Crash test<\/h2>\n<p><\/p>\n<p>Il crash test, in questo caso, sar\u00e0 piuttosto semplice e veloce, poich\u00e9 la funzionalit\u00e0 di replica (failover, coerenza, ecc.) \u00e8 stata gi\u00e0 esaminata nel <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/aerodisk\/blog\/456348\/\">precedente articolo<\/a><\/noindex>. Pertanto, per testare l'affidabilit\u00e0 del metrocluster, dobbiamo semplicemente verificare l'automazione per la rilevazione dei guasti, il failover e l'assenza di perdite durante la scrittura (interruzioni dell'input\/output). <\/p>\n<p><\/p>\n<p>A tal fine, emuliamo un guasto totale di uno dei sistemi di archiviazione, spegnendo fisicamente entrambi i suoi controller e avviando prima la copia di un grande file su un LUN, che dovrebbe attivarsi su un altro sistema di archiviazione.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/b1b108313472a03983bc1b8690c70369.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Scolleghiamo un sistema di archiviazione. Sul secondo sistema vediamo avvisi e messaggi nei log che indicano che la connessione con il sistema adiacente \u00e8 stata persa. Se le notifiche via SMTP o SNMP sono attivate, l'amministratore ricever\u00e0 notifiche appropriate.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/ae\/jo\/xv\/aejoxv6piwk4fvl-nc1leklbxce.jpeg\"><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/9af3728eec93cc2e17048ec596748cb1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>Esattamente dopo 10 secondi (visibile in entrambi gli screenshot) la connessione di replica METRO (quella che era Primary sul sistema di archiviazione guasto) \u00e8 automaticamente diventata Primary sul sistema di archiviazione funzionante. Utilizzando il mapping esistente, il LUN TEST \u00e8 rimasto accessibile all'host, con una leggera caduta nell'operativit\u00e0 (entro il promesso 10 percento), ma non si \u00e8 interrotto. <\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/v_\/gj\/d9\/v_gjd9sgoi5hwrgjdkwxwtdomeu.jpeg\"><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/e0131eb534ed10f1ac64a19d42d0b53f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/644da1a8b2de75637b58094f549d4de0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><strong>Il test \u00e8 stato completato con successo.<\/strong><\/p>\n<p><\/p>\n<h2 id=\"podvodim-itog\">In sintesi<\/h2>\n<p><\/p>\n<p>L'attuale implementazione del metrocluster nei sistemi di archiviazione AERODISK Engine di serie N consente di affrontare pienamente le sfide in cui \u00e8 necessario eliminare o ridurre al minimo i tempi di inattivit\u00e0 dei servizi IT e garantire il loro funzionamento 24\/7\/365 con il minimo sforzo lavorativo. <\/p>\n<p><\/p>\n<p>Si potrebbe dire, certo, che tutto ci\u00f2 \u00e8 teoria, condizioni di laboratorio ideali e cos\u00ec via... MA abbiamo una serie di progetti realizzati in cui abbiamo implementato la funzionalit\u00e0 di resilienza alle catastrofi, e i sistemi funzionano alla grande. Uno dei nostri clienti abbastanza noti, che utilizza proprio due sistemi di archiviazione in configurazione resiliente, ha gi\u00e0 dato il consenso alla pubblicazione delle informazioni sul progetto, quindi nella parte successiva parleremo dell'implementazione in condizioni operative.<\/p>\n<p><\/p>\n<p>Grazie, aspettiamo una discussione produttiva.<\/p>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/aerodisk\/blog\/460305\/\">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 \u0425\u0430\u0431\u0440\u0430! \u0412 \u043f\u0440\u043e\u0448\u043b\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b\u0438 \u043e \u043f\u0440\u043e\u0441\u0442\u043e\u043c \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0435 \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 \u2013 \u043e \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u043f\u043e\u0433\u0440\u0443\u0437\u0438\u043c\u0441\u044f \u0432 \u0431\u043e\u043b\u0435\u0435 \u0441\u043b\u043e\u0436\u043d\u0443\u044e \u0438 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0443\u044e \u0442\u0435\u043c\u0443 \u2013 \u043c\u0435\u0442\u0440\u043e\u043a\u043b\u0430\u0441\u0442\u0435\u0440, \u0442\u043e \u0435\u0441\u0442\u044c \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0439 \u0437\u0430\u0449\u0438\u0442\u044b \u043e\u0442 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444 \u0434\u043b\u044f \u0434\u0432\u0443\u0445 \u0426\u041e\u0414-\u043e\u0432, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0435\u0435 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0426\u041e\u0414-\u0430\u043c \u0432 \u0440\u0435\u0436\u0438\u043c\u0435 active-active. \u0420\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c, \u043f\u043e\u043a\u0430\u0436\u0435\u043c, \u0441\u043b\u043e\u043c\u0430\u0435\u043c \u0438 \u043f\u043e\u0447\u0438\u043d\u0438\u043c. \u041a\u0430\u043a [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27126,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36263","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0425\u0430\u0431\u0440\u0430! \u0412 \u043f\u0440\u043e\u0448\u043b\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b\u0438 \u043e \u043f\u0440\u043e\u0441\u0442\u043e\u043c \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0435 \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 \u2013 \u043e \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u043f\u043e\u0433\u0440\u0443\u0437\u0438\u043c\u0441\u044f \u0432 \u0431\u043e\u043b\u0435\u0435 \u0441\u043b\u043e\u0436\u043d\u0443\u044e \u0438 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0443\u044e \u0442\u0435\u043c\u0443 \u2013 \u043c\u0435\u0442\u0440\u043e\u043a\u043b\u0430\u0441\u0442\u0435\u0440, \u0442\u043e \u0435\u0441\u0442\u044c \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0439 \u0437\u0430\u0449\u0438\u0442\u044b \u043e\u0442 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444 \u0434\u043b\u044f \u0434\u0432\u0443\u0445 \u0426\u041e\u0414-\u043e\u0432, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0435\u0435 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0426\u041e\u0414-\u0430\u043c \u0432 \u0440\u0435\u0436\u0438\u043c\u0435 active-active. \u0420\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c, \u043f\u043e\u043a\u0430\u0436\u0435\u043c, \u0441\u043b\u043e\u043c\u0430\u0435\u043c \u0438 \u043f\u043e\u0447\u0438\u043d\u0438\u043c. \u041a\u0430\u043a\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-2-metroklaster\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\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 2. \u041c\u0435\u0442\u0440\u043e\u043a\u043b\u0430\u0441\u0442\u0435\u0440 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0425\u0430\u0431\u0440\u0430! \u0412 \u043f\u0440\u043e\u0448\u043b\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b\u0438 \u043e \u043f\u0440\u043e\u0441\u0442\u043e\u043c \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0435 \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 \u2013 \u043e \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u043f\u043e\u0433\u0440\u0443\u0437\u0438\u043c\u0441\u044f \u0432 \u0431\u043e\u043b\u0435\u0435 \u0441\u043b\u043e\u0436\u043d\u0443\u044e \u0438 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0443\u044e \u0442\u0435\u043c\u0443 \u2013 \u043c\u0435\u0442\u0440\u043e\u043a\u043b\u0430\u0441\u0442\u0435\u0440, \u0442\u043e \u0435\u0441\u0442\u044c \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0439 \u0437\u0430\u0449\u0438\u0442\u044b \u043e\u0442 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444 \u0434\u043b\u044f \u0434\u0432\u0443\u0445 \u0426\u041e\u0414-\u043e\u0432, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0435\u0435 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0426\u041e\u0414-\u0430\u043c \u0432 \u0440\u0435\u0436\u0438\u043c\u0435 active-active. \u0420\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c, \u043f\u043e\u043a\u0430\u0436\u0435\u043c, \u0441\u043b\u043e\u043c\u0430\u0435\u043c \u0438 \u043f\u043e\u0447\u0438\u043d\u0438\u043c. \u041a\u0430\u043a\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-2-metroklaster\" \/>\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:10:35+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:10:35+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. Parte 2. Metrocuster | ProHoster","description":"Ciao lettori di Habr! Nell'articolo precedente abbiamo parlato di uno strumento semplice per la resilienza nei sistemi di archiviazione AERODISK ENGINE: la replica. In questo articolo ci immergeremo in un tema pi\u00f9 complesso e interessante: il metrocuster, ovvero uno strumento di protezione automatizzata dai disastri per due data center, che consente loro di operare in modalit\u00e0 attiva-attiva. Racconteremo, mostreremo, romperemo e ripareremo. Come","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-2-metroklaster","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 2. \u041c\u0435\u0442\u0440\u043e\u043a\u043b\u0430\u0441\u0442\u0435\u0440 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0425\u0430\u0431\u0440\u0430! \u0412 \u043f\u0440\u043e\u0448\u043b\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b\u0438 \u043e \u043f\u0440\u043e\u0441\u0442\u043e\u043c \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0435 \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 \u2013 \u043e \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u043f\u043e\u0433\u0440\u0443\u0437\u0438\u043c\u0441\u044f \u0432 \u0431\u043e\u043b\u0435\u0435 \u0441\u043b\u043e\u0436\u043d\u0443\u044e \u0438 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0443\u044e \u0442\u0435\u043c\u0443 \u2013 \u043c\u0435\u0442\u0440\u043e\u043a\u043b\u0430\u0441\u0442\u0435\u0440, \u0442\u043e \u0435\u0441\u0442\u044c \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0439 \u0437\u0430\u0449\u0438\u0442\u044b \u043e\u0442 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444 \u0434\u043b\u044f \u0434\u0432\u0443\u0445 \u0426\u041e\u0414-\u043e\u0432, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0435\u0435 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0426\u041e\u0414-\u0430\u043c \u0432 \u0440\u0435\u0436\u0438\u043c\u0435 active-active. \u0420\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c, \u043f\u043e\u043a\u0430\u0436\u0435\u043c, \u0441\u043b\u043e\u043c\u0430\u0435\u043c \u0438 \u043f\u043e\u0447\u0438\u043d\u0438\u043c. \u041a\u0430\u043a","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-2-metroklaster","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:10:35+00:00","article:modified_time":"2019-10-31T19:10:35+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36263","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 02:36:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:47:35","updated":"2026-01-22 02:36:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/36263","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=36263"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/36263\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/27126"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=36263"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=36263"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=36263"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}