Salute, lettori di Habr! In l'ultimu articulu, avemu parlatu di un mezzu simplice di ricuperazione di disastru in sistemi di almacenamiento AERODISK ENGINE - replicazione. In questu articulu, avemu da immergerà in un tema più cumplessu è interessante - u metrocluster, vale à dì, un mezzu di prutezzione automatizata di disastru per dui centri di dati, chì permettenu i centri di dati per operà in modu attivu-attivu. Vi diceremu, vi mustraremu, rumpillu è riparate.
Comu di solitu, a teoria prima
Un metrocluster hè un cluster spartu in parechji siti in una cità o regione. A parolla "cluster" ci suggerisce chjaramente chì u cumplessu hè automatizatu, vale à dì, cambià i nodi di cluster in casu di fallimenti si faci automaticamente.
Hè quì chì a principal diferenza trà un metrocluster è a replicazione regulare. L'automatizazione di l'operazioni. Vale à dì, in casu di certi incidenti (fallimentu di u centru di dati, canali rotti, etc.), u sistema di almacenamentu farà indipindente l'azzioni necessarii per mantene a dispunibilità di dati. Quandu si usanu repliche regularmente, queste azzioni sò realizate interamente o parzialmente manualmente da l'amministratore.
Cosa ùn si fà?
L'obiettivu principale chì i clienti perseguenu quandu utilizanu certe implementazioni di metrocluster hè di minimizzà l'RTO (Obiettivu di u Tempu di Recuperazione). Questu hè, per minimizzà u tempu di ricuperazione di i servizii IT dopu un fallimentu. Se utilizate a replicazione regulare, u tempu di ricuperazione serà sempre più longu di u tempu di ricuperazione cù un metrocluster. Perchè? Assai sèmplice. L'amministratore deve esse à a so scrivania è cambia a replicazione manualmente, è u metrocluster faci questu automaticamente.
Se ùn avete micca un amministratore dedicatu in turnu chì ùn dorme micca, ùn manghja micca, ùn fuma o si ammala, è fighja u statu di u sistema di almacenamento 24 ore à ghjornu, allora ùn ci hè micca manera di guarantiscia chì l'amministratore serà. esse dispunibule per u cambiamentu manuale durante un fallimentu.
In cunsiquenza, RTO in l'absenza di un metrocluster o un amministratore immortale di u livellu 99 di u serviziu di serviziu di l'amministratore serà uguale à a somma di u tempu di cambiamentu di tutti i sistemi è u periodu massimu di tempu dopu chì l'amministratore hè garantitu per cumincià à travaglià. cù sistemi di almacenamentu è sistemi cunnessi.
Cusì, ghjunghjemu à a cunclusione ovvia chì u metrocluster deve esse utilizatu se u requisitu per RTO hè minuti, micca ore o ghjorni, vale à dì quandu, in casu di u peghju fallimentu di u centru di dati, u dipartimentu IT deve furnisce l'affari cù u tempu. per risturà l'accessu à i servizii IT in minuti, o ancu seconde.
Cumu viaghja?
À u livellu più bassu, u metrocluster usa un mecanismu per a replicazione di dati sincrona, chì avemu descrittu in l'articulu precedente (vede. ). Siccomu a replicazione hè sincrona, i requisiti per questu sò currispondenti, o megliu:
- fibra ottica cum'è fisica, 10 gigabit Ethernet (o più altu);
- a distanza trà i centri di dati ùn hè micca più di 40 chilometri;
- U ritardu di u canali otticu trà i centri di dati (trà i sistemi di almacenamento) hè finu à 5 millisecondi (ottimu 2).
Tutti questi requisiti sò di natura consultiva, vale à dì, u metrocluster hà da travaglià ancu s'è questi requisiti ùn sò micca soddisfatti, ma duvemu capisce chì e cunsequenze di u non-rispettu di sti requisiti sò uguali à una rallentazione in u funziunamentu di i dui sistemi di almacenamento in u metrocluster.
Allora, una replica sincrona hè aduprata per trasfiriri dati trà i sistemi di almacenamiento, è cumu si cambianu automaticamente e rèpliche è, più impurtante, cumu per evità u split-brain? Per fà questu, à un livellu più altu, una entità supplementaria hè aduprata - un arbitru.
Cumu travaglia un arbitru è quale hè u so compitu?
L'arbitru hè una piccula macchina virtuale o un cluster hardware chì deve esse lanciatu in un terzu situ (per esempiu, in un uffiziu) è furnisce l'accessu à u sistema di almacenamento via ICMP è SSH. Dopu à u lanciamentu, l'arbitru deve stabilisce l'IP, è da u latu di l'almacenamiento indicà u so indirizzu, più l'indirizzi di i cuntrolli remoti chì participanu à u metrocluster. Dopu questu, l'arbitru hè prestu à travaglià.
L'arbitru monitoreghja constantemente tutti i sistemi di almacenamento in u metrocluster è se un sistema di almacenamentu particulari ùn hè micca dispunibule, dopu avè cunfirmatu l'indisponibilità da un altru membru di u cluster (unu di i sistemi di almacenamento "live"), decide di lancià a prucedura per cambià e regule di replicazione. è cartografia.
Un puntu assai impurtante. L'arbitru deve esse sempre situatu in un situ diffirenti da quelli chì sò situati i sistemi di almacenamiento, vale à dì, nè in u centru di dati 1, induve u sistema di almacenamiento 1 hè stallatu, nè in u centru di dati 2, induve u sistema di almacenamiento 2 hè stallatu.
Perchè? Perchè questu hè l'unicu modu chì un arbitru, cù l'aiutu di unu di i sistemi di almacenamento sopravviventi, pò determinà senza ambiguità è precisa a caduta di qualsiasi di i dui siti induve i sistemi di almacenamento sò stallati. Ogni altru mètudu di mette un arbitru pò esse risultatu in un split-brain.
Avà andemu in i dettagli di u travagliu di l'arbitru.
L'arbitru gestisce parechji servizii chì sondanu constantemente tutti i controller di almacenamento. Se u risultatu di u sondaghju differisce da u precedente (disponibile / indisponibile), allora hè arregistratu in una piccula basa di dati, chì travaglia ancu nantu à l'arbitru.
Fighjemu a logica di u travagliu di l'arbitru in più detail.
Passu 1: Determinà a indisponibilità. Un avvenimentu di fallimentu di u sistema di almacenamentu hè l'assenza di ping da i dui controller di u stessu sistema di almacenamentu in 5 seconde.
Step 2. Start u prucedimentu switching. Dopu chì l'arbitru hà capitu chì unu di i sistemi di almacenamento ùn hè micca dispunibule, manda una dumanda à u sistema di almacenamentu "vivu" per assicurà chì u sistema di almacenamentu "mortu" hè veramente mortu.
Dopu avè ricivutu un tali cumandamentu da l'arbitru, u sicondu sistema di almacenamento (live) verifica in più a dispunibilità di u primu sistema di almacenamentu cadutu è, s'ellu ùn hè micca quì, manda cunferma à l'arbitru di a so guess. U sistema di almacenamiento hè veramente indisponibile.
Dopu avè ricivutu una tale cunferma, l'arbitru lancia una prucedura remota per cambià a replicazione è elevà a mappatura nantu à quelli rèplichi chì eranu attivu (primariu) nantu à u sistema di almacenamento cadutu, è manda un cumandamentu à u sicondu sistema di almacenamento per cambià queste rèpliche da secundaria à primaria è elevà a mappatura. Ebbè, u sicondu sistema di almacenamentu, per quessa, eseguisce queste prucedure, è poi furnisce l'accessu à i LUN persi da ellu stessu.
Perchè hè necessariu una verificazione supplementaria? Per quorum. Questu hè, a maiuranza di u numeru imparu tutale (3) di membri di u cluster deve cunfirmà a caduta di unu di i nodi di cluster. Solu allora sta decisione serà definitivamente curretta. Questu hè necessariu per evità un cambiamentu sbagliatu è, dunque, split-brain.
U passu di u tempu 2 dura circa 5 - 10 seconde, cusì, tenendu in contu u tempu necessariu per determinà l'indisponibilità (5 seconde), in 10 - 15 seconde dopu l'accidentu, i LUN da u sistema di almacenamentu cadutu seranu automaticamente dispunibili per travaglià cù u live. sistema di almacenamentu.
Hè chjaru chì per evità di perde e cunnessione cù l'ospiti, avete ancu bisognu di piglià cura di cunfigurà currettamente i timeouts in l'ospiti. U timeout cunsigliatu hè almenu 30 seconde. Questu impedisce à l'ospite di interrompe a cunnessione à u sistema di almacenamento durante u cambiamentu di carica in casu di disastru è pò assicurà chì ùn ci hè micca interruzioni I / O.
Aspettate un secondu, risulta chì, se tuttu hè cusì bonu cù u metrocluster, perchè avemu bisognu di replicazione regulare in tuttu?
In realtà, tuttu ùn hè micca cusì simplice.
Cunsideremu i pro è i contra di u metrocluster
Dunque, avemu capitu chì i vantaghji evidenti di u metrocluster cumparatu cù a replicazione convenzionale sò:
- Automatizazione cumpleta, assicurendu un tempu minimu di ricuperazione in casu di disastru;
- Eccu tuttu :-).
È avà, attenzione, i contra:
- U costu di suluzione. Ancu se u metrocluster in i sistemi Aerodisk ùn hè micca bisognu di licenze supplementari (a stessa licenza hè aduprata cum'è per a replica), u costu di a suluzione serà ancu più altu ch'è l'usu di a replicazione sincrona. Avete bisognu di implementà tutti i requisiti per una replica sincrona, più i requisiti per u metrocluster assuciatu cù u cambiamentu supplementu è u situ supplementu (vede a pianificazione di u metrocluster);
- A cumplessità di a suluzione. U metrocluster hè assai più cumplessu chè una replica regulare, è richiede assai più attenzione è sforzu per a pianificazione, a cunfigurazione è a documentazione.
Eventualmente. Metrocluster hè certamente una suluzione tecnologicamente avanzata è bona solu quandu avete veramente bisognu di furnisce RTO in seconde o minuti. Ma s'ellu ùn ci hè micca un tali compitu, è RTO in ore hè OK per l'affari, allora ùn ci hè nunda di sparrow sparrows da un cannone. A replicazione abituale di i travagliadori-paesani hè abbastanza, postu chì un cluster di metro causarà costi supplementari è cumplicazioni di l'infrastruttura IT.
Pianificazione di u Metrocluster
Questa rùbbrica ùn pretende micca esse una guida cumpleta per u disignu di u metrocluster, ma mostra solu e direzzione principale chì deve esse elaborata se decide di custruisce un tali sistema. Dunque, quandu implementate in realtà un metrocluster, assicuratevi di participà à u fabricatore di u sistema di almacenamentu (vale à dì, noi) è altri sistemi cunnessi per cunsultazioni.
Lodi
Comu diciatu sopra, un metrocluster richiede un minimu di trè siti. Dui centri di dati induve i sistemi di almacenamento è i sistemi cunnessi operanu, è ancu un terzu situ induve l'arbitru hà da travaglià.
A distanza cunsigliata trà i centri di dati ùn hè micca più di 40 chilometri. Una distanza più grande hè assai prubabile di causà ritardi supplementari, chì in u casu di un metrocluster sò estremamente indeserate. Ricordemu chì i ritardi duveranu esse finu à 5 millisecondi, ancu s'ellu hè cunsigliatu di mantene in 2.
Hè cunsigliatu di verificà i ritardi ancu durante u prucessu di pianificazione. Qualchese fornitore più o menu maturu chì furnisce fibra ottica trà i centri di dati pò urganizà un cuntrollu di qualità abbastanza rapidamente.
In quantu à i ritardi davanti à l'arbitru (vale à dì, trà u terzu situ è i primi dui), u limitu di ritardu cunsigliatu hè finu à 200 millisecondi, vale à dì, una cunnessione VPN corporativa regulare nantu à Internet hè adattatu.
Cambia è Networking
A cuntrariu di u schema di replicazione, induve hè abbastanza per cunnette i sistemi di almacenamento da siti diversi, u schema di metrocluster necessita di cunnessione di l'ospiti cù i dui sistemi di almacenamento in siti differenti. Per fà più chjaru quale hè a diffarenza, i dui schemi sò mostrati quì sottu.
Comu pò esse vistu da u diagramma, i nostri ospiti di u situ 1 fighjanu à u sistema di almacenamiento 1 è u sistema di almacenamentu 2. Inoltre, à u cuntrariu, l'ospiti di u situ 2 fighjanu à u sistema di almacenamiento 2 è u sistema di almacenamento 1. Vale à dì, ogni òspite vede i dui sistemi di almacenamiento. Questu hè un prerequisite per u funziunamentu di u metrocluster.
Di sicuru, ùn ci hè bisognu di cunnette ogni òspite cù un cordone otticu à un altru centru di dati; nisun portu o cordone serà abbastanza. Tutte queste cunnessioni devenu esse realizate per mezu di switch Ethernet 10G+ o FibreChannel 8G+ (FC hè solu per cunnette l'ospiti è i sistemi di almacenamento per IO, u canali di replicazione hè attualmente dispunibule solu via IP (Ethernet 10G+).
Avà uni pochi di parolle nantu à a topologia di a rete. Un puntu impurtante hè a cunfigurazione curretta di subnets. Hè necessariu di definisce immediatamente parechji subnets per i seguenti tipi di trafficu:
- A subnet di replicazione nantu à quale i dati seranu sincronizzati trà i sistemi di almacenamiento. Ci ponu esse parechji di elli, in questu casu ùn importa micca, tuttu dipende di a topologia di a rete attuale (dighjà implementata). Se ci sò dui di elli, allora ovviamente u routing deve esse cunfiguratu trà elli;
- Subnets di almacenamentu attraversu quale l'ospiti accede à e risorse di almacenamiento (se hè iSCSI). Ci deve esse unu tali subnet in ogni centru di dati;
- Cuntrolla subnets, vale à dì, trè subnets routable in trè siti da quale i sistemi di almacenamento sò amministrati, è l'arbitru hè ancu situatu quì.
Ùn avemu micca cunsideratu subnets per accede à e risorse di l'ospiti quì, postu chì sò assai dipindenti di i travaglii.
A separazione di u trafficu diffirenti in diverse subnets hè estremamente impurtante (hè soprattuttu impurtante per separà a replica da l'I / O), perchè se mischjà tuttu u trafficu in una subnet "grossa", allora stu trafficu serà impussibile di gestisce, è in i cundizioni di dui centri dati chistu pò sempre causari differente ozzione collision reta. Ùn avemu micca sfondate in questu prublema in u quadru di questu articulu, postu chì pudete leghje nantu à a pianificazione di una rete allungata trà i centri di dati nantu à e risorse di i fabricatori di l'equipaggiu di rete, induve questu hè descrittu in grande detail.
Cunfigurazione di l'arbitru
L'arbitru deve furnisce l'accessu à tutte l'interfaccia di gestione di u sistema di almacenamento via i protokolli ICMP è SSH. Duvete ancu pensà à u failsafe di l'arbitru. Ci hè una sfumatura quì.
U failover di l'arbitru hè assai desideratu, ma micca necessariu. Chì succede se l'arbitru crash à u mumentu sbagliatu?
- U funziunamentu di u metrocluster in modu normale ùn cambierà micca, perchè arbtir ùn hà assolutamente micca effettu nantu à u funziunamentu di u metrocluster in modu normale (u so compitu hè di cambià a carica trà i centri di dati in modu puntuale)
- Inoltre, se l'arbitru per una raghjone o un altru cascà è "durmi" un accidentu in u centru di dati, allora ùn ci sarà micca cambià, perchè ùn ci sarà nimu per dà i cumandamenti di cunversione necessarii è urganizà un quorum. In questu casu, u metrocluster diventerà un schema regulare cù replicazione, chì deve esse cambiatu manualmente durante un disastru, chì affettarà u RTO.
Chì seguita da questu? Sè avete veramente bisognu di assicurà un RTO minimu, avete bisognu di assicurà chì l'arbitru hè tolerante à i difetti. Ci hè dui opzioni per questu:
- Lanciate una macchina virtuale cù un arbitru nantu à un hypervisor tollerante à i difetti, per furtuna tutti l'ipervisori adulti supportanu a tolleranza di difetti;
- Se in u terzu situ (in un uffiziu convenzionale) site troppu pigro per installà un cluster normale è ùn ci hè micca un cluster hypervozor esistente, allora avemu furnitu una versione hardware di l'arbitru, chì hè fatta in una scatula 2U in quale dui ordinariu. I servitori x-86 funzionanu è chì ponu sopravvive à un fallimentu lucale.
Ricumandemu fermamente à assicurà a tolleranza di difetti di l'arbitru, malgradu u fattu chì u metrocluster ùn ne hà micca bisognu in modu normale. Ma cum'è a teoria è a pratica mostranu, se custruite una infrastruttura veramente affidabile à prova di disastru, allora hè megliu ghjucà in modu sicuru. Hè megliu di prutezzione di sè stessu è di a vostra attività da a "legge di a meanness", vale à dì da u fallimentu di l'arbitru è di unu di i siti induve u sistema di almacenamento hè situatu.
architettura di suluzione
Cunsiderendu i requisiti sopra, avemu a seguente architettura di suluzione generale.
LUN deve esse distribuitu uniformemente in dui siti per evità una sovraccarico severu. À u listessu tempu, quandu si dimensiona in i dui centri di dati, duvete include micca solu u doppiu voluminu (chì hè necessariu di almacenà dati simultaneamente in dui sistemi di almacenamento), ma ancu doppia prestazione in IOPS è MB / s per prevene a degradazione di l'applicazione in l'eventu di un fallimentu di unu di i centri di dati.
Separatamente, avemu nutatu chì cù l'approcciu propiu di dimensionamentu (vale à dì, basta chì avemu furnitu i limiti superiori adatti di IOPS è MB / s, è ancu di e risorse CPU è RAM necessarie), se unu di i sistemi di almacenamiento in u U cluster di metro fallisce, ùn ci sarà micca una seria calata di u rendiment in cundizioni di travagliu tempurale nantu à un sistema di almacenamento.
Questu hè spiegatu da u fattu chì quandu dui siti operanu simultaneamente, a replicazione sincrona "manghja" a mità di u rendiment di scrittura, postu chì ogni transazzione deve esse scritta à dui sistemi di almacenamiento (simili à RAID-1/10). Allora, se unu di i sistemi di almacenamentu falla, l'influenza di a replicazione temporaneamente (finu à chì u sistema di almacenamentu fallutu si ricuperà) sparisce, è avemu un aumentu duppiu in u rendiment di scrittura. Dopu chì i LUN di u sistema d'almacenamiento fallutu sò riavviati nantu à u sistema di almacenamento di travagliu, questu aumentu duppiu sparisce per via di u fattu chì a carica appare da i LUN di l'altru sistema di almacenamento, è tornemu à u listessu livellu di prestazione chì avemu avutu prima di l'almacenamiento. "caduta", ma solu in u quadru di un situ.
Cù l'aiutu di un dimensionamentu cumpetente, pudete assicurà e cundizioni in quale l'utilizatori ùn sentenu micca u fallimentu di un sistema di almacenamentu tutale. Ma ripetemu una volta di più, questu richiede un dimensionamentu assai attentu, per quale, per via, pudete cuntattateci gratuitamente :-).
A creazione di un metrocluster
A creazione di un metrocluster hè assai simile à a creazione di replicazione regulare, chì avemu descrittu in . Dunque, focalizemu solu nantu à e differenze. Avemu stallatu un bancu in u laboratoriu basatu annantu à l'architettura sopra, solu in una versione minima: dui sistemi di almacenamento cunnessi via 10G Ethernet, dui switch 10G è un host chì guarda attraversu i switch à i dui sistemi di almacenamento cù porti 10G. L'arbitru corre nantu à una macchina virtuale.
Quandu cunfigurà IP virtuale (VIP) per una replica, duvete selezziunate u tipu VIP - per metrocluster.
Avemu creatu dui ligami di replicazione per dui LUN è li distribuimu in dui sistemi di almacenamentu: LUN TEST Primariu nantu à u sistema di almacenamentu 1 (METRO link), LUN TEST2 Primary per u sistema di almacenamiento 2 (METRO2 link).
Per elli, avemu cunfiguratu dui miri identichi (in u nostru casu iSCSI, ma FC hè ancu supportatu, a logica di setup hè a stessa).
Sistema di almacenamentu 1:
Sistema di almacenamentu 2:
Per e cunnessione di replicazione, i mappings sò stati fatti nantu à ogni sistema di almacenamento.
Sistema di almacenamentu 1:
Sistema di almacenamentu 2:
Avemu stabilitu multipath è l'avemu prisentatu à l'ospite.
A creazione di un arbitru
Ùn avete bisognu di fà nunda di speciale cù l'arbitru stessu; basta à attivà u terzu situ, dà una IP è cunfigurà l'accessu via ICMP è SSH. A cunfigurazione stessu hè realizatu da i sistemi di almacenamentu stessu. In questu casu, hè abbastanza per cunfigurà l'arbitru una volta nantu à qualsiasi controller di almacenamento in u metrocluster; sti paràmetri seranu distribuiti à tutti i controller automaticamente.
In a sezione Replicazione remota>> Metrocluster (nantu à qualsiasi controller)>> u buttone "Configurazione".
Entremu l'IP di l'arbitru, è ancu l'interfacce di cuntrollu di dui controller di almacenamento remoti.
Dopu questu, avete bisognu di attivà tutti i servizii (u buttone "Restart everything"). Se ricunfigurati in u futuru, i servizii devenu esse riavviati per chì i paràmetri sò effettu.
Avemu verificatu chì tutti i servizii sò in esecuzione.
Questu cumpleta a cunfigurazione di u metrocluster.
Crash test
A prova di crash in u nostru casu serà abbastanza simplice è veloce, postu chì a funziunalità di replicazione (switching, coerenza, etc.) hè statu discutitu in . Dunque, per pruvà l'affidabilità di u metrocluster, hè abbastanza per noi per verificà l'automatizazione di a deteczione di fallimentu, a commutazione è l'assenza di perdite di registrazione (I / O si ferma).
Per fà questu, emulemu un fallimentu cumpletu di unu di i sistemi di almacenamentu disattivendu fisicamente i dui controllers, avè prima cuminciatu à copià un grande schedariu in u LUN, chì deve esse attivatu nantu à l'altru sistema di almacenamento.
Disattivà un sistema di almacenamento. Nantu à u sicondu sistema di almacenamentu vedemu avvisi è missaghji in i logs chì a cunnessione cù u sistema vicinu hè stata persa. Se e notificazioni via SMTP o SNMP sò cunfigurati, l'amministratore riceverà notificazioni currispondenti.
Esattamente 10 seconde dopu (visibule in i dui screenshots), a cunnessione di replicazione METRO (quellu chì era Primariu nantu à u sistema di almacenamentu fallutu) diventò automaticamente Primariu in u sistema di almacenamentu di travagliu. Utilizendu a mappatura esistente, LUN TEST hè stata dispunibile per l'ospiti, a registrazione hè stata un pocu (in u 10 per centu prumessu), ma ùn hè stata interrotta.
A prova hè finita cun successu.
Riunione
L'implementazione attuale di u metrocluster in i sistemi di almacenamento AERODISK Engine N-series permette cumplettamente di risolve i prublemi induve hè necessariu eliminà o minimizzà i tempi di inattività per i servizii IT è assicurà u so funziunamentu 24/7/365 cù costi di travagliu minimi.
Pudemu dì, sicuru, chì tuttu questu hè teoria, cundizioni ideali di laboratori, è cusì ... MA avemu una quantità di prughjetti implementati in quale avemu implementatu a funziunalità di resilienza di disastru, è i sistemi funzionanu perfettamente. Unu di i nostri clienti abbastanza cunnisciuti, chì utilizanu solu dui sistemi di almacenamento in una cunfigurazione a prova di disastru, hà digià accunsentutu à publicà infurmazioni nantu à u prugettu, cusì in a prossima parte parlemu di l'implementazione di cummattimentu.
Grazie, aspittemu una discussione produttiva.
Source: www.habr.com