Hola, lectors de Habr! En l'últim article, vam parlar d'un mitjà senzill de recuperació de desastres en sistemes d'emmagatzematge AERODISK ENGINE: la replicació. En aquest article, ens endinsarem en un tema més complex i interessant: el metrocluster, és a dir, un mitjà de protecció automatitzada contra desastres per a dos centres de dades, que permet que els centres de dades funcionin en mode actiu-actiu. T'ho direm, t'ensenyarem, ho trencarem i ho arreglarem.
Com és habitual, primer la teoria
Un metroclúster és un clúster distribuït per diversos llocs dins d'una ciutat o regió. La paraula "clúster" ens indica clarament que el complex està automatitzat, és a dir, el canvi de nodes del clúster en cas de fallades es produeix automàticament.
Aquí és on rau la diferència principal entre un metroclúster i la replicació regular. Automatització d'operacions. És a dir, en cas que es produeixin determinades incidències (falla del centre de dades, canals trencats, etc.), el sistema d'emmagatzematge realitzarà de manera independent les accions necessàries per tal de mantenir la disponibilitat de les dades. Quan s'utilitzen rèpliques habituals, aquestes accions les realitza totalment o parcialment de manera manual per l'administrador.
Per a què serveix?
L'objectiu principal que persegueixen els clients quan utilitzen determinades implementacions de metrocluster és minimitzar el RTO (Objectiu de temps de recuperació). És a dir, per minimitzar el temps de recuperació dels serveis informàtics després d'una fallada. Si utilitzeu la rèplica regular, el temps de recuperació sempre serà més llarg que el temps de recuperació amb un metroclúster. Per què? Molt simple. L'administrador ha d'estar al seu escriptori i canviar de rèplica manualment, i el metrocluster ho fa automàticament.
Si no teniu un administrador dedicat que no dorm, no menja, no fumi ni es emmalalteix i vigili l'estat del sistema d'emmagatzematge les 24 hores del dia, no hi ha manera de garantir que l'administrador ho faci. estar disponible per a la commutació manual durant una fallada.
En conseqüència, RTO en absència d'un clúster de metro o d'un administrador immortal del nivell 99 del servei de servei d'administrador serà igual a la suma del temps de canvi de tots els sistemes i el període màxim de temps després del qual es garanteix que l'administrador comenci a treballar. amb sistemes d'emmagatzematge i sistemes relacionats.
Així, arribem a la conclusió òbvia que s'hauria d'utilitzar el metroclúster si el requisit de RTO és de minuts, no d'hores o dies, és a dir, quan en el cas de la pitjor fallada del centre de dades, el departament informàtic ha de proporcionar temps al negoci. per restaurar l'accés als serveis informàtics en qüestió de minuts, o fins i tot segons.
Com funciona?
Al nivell inferior, el metrocluster utilitza un mecanisme per a la replicació de dades sincrònica, que vam descriure a l'article anterior (vegeu. ). Com que la replicació és sincrònica, els requisits per a ella són corresponents, o millor dit:
- fibra òptica com a física, 10 gigabit Ethernet (o superior);
- la distància entre centres de dades no és superior a 40 quilòmetres;
- El retard del canal òptic entre centres de dades (entre sistemes d'emmagatzematge) és de fins a 5 mil·lisegons (òptimament 2).
Tots aquests requisits són de caràcter consultiu, és a dir, el metroclúster funcionarà encara que no es compleixin aquests requisits, però hem d'entendre que les conseqüències de l'incompliment d'aquests requisits equivalen a una frenada en el funcionament d'ambdós sistemes d'emmagatzematge en el metrocluster.
Per tant, s'utilitza una rèplica síncrona per transferir dades entre sistemes d'emmagatzematge, i com es canvien automàticament les rèpliques i, el més important, com evitar el cervell dividit? Per fer-ho, a un nivell superior, s'utilitza una entitat addicional: un àrbitre.
Com funciona un àrbitre i quina és la seva tasca?
L'àrbitre és una petita màquina virtual o un clúster de maquinari que s'ha de llançar en un tercer lloc (per exemple, en una oficina) i proporcionar accés al sistema d'emmagatzematge mitjançant ICMP i SSH. Després del llançament, l'àrbitre hauria d'establir la IP i, des del costat d'emmagatzematge, indicar la seva adreça, a més de les adreces dels comandaments a distància que participen en el metrocluster. Després d'això, l'àrbitre està preparat per treballar.
L'àrbitre supervisa constantment tots els sistemes d'emmagatzematge del metroclúster i si un sistema d'emmagatzematge en particular no està disponible, després de confirmar la indisponibilitat d'un altre membre del clúster (un dels sistemes d'emmagatzematge "en directe"), decideix iniciar el procediment per canviar les regles de rèplica. i cartografia.
Un punt molt important. L'àrbitre s'ha d'ubicar sempre en un lloc diferent d'aquells on es troben els sistemes d'emmagatzematge, és a dir, ni al centre de dades 1, on hi ha instal·lat el sistema d'emmagatzematge 1, ni al centre de dades 2, on hi ha instal·lat el sistema d'emmagatzematge 2.
Per què? Perquè aquesta és l'única manera que un àrbitre, amb l'ajuda d'un dels sistemes d'emmagatzematge supervivents, pot determinar de manera inequívoca i precisa la caiguda de qualsevol dels dos llocs on estan instal·lats els sistemes d'emmagatzematge. Qualsevol altre mètode per col·locar un àrbitre pot donar lloc a un cervell dividit.
Ara endinsem-nos en els detalls del treball de l'àrbitre.
L'àrbitre executa diversos serveis que sondegen constantment tots els controladors d'emmagatzematge. Si el resultat de l'enquesta és diferent de l'anterior (disponible/no disponible), llavors es registra en una petita base de dades, que també funciona a l'àrbitre.
Vegem amb més detall la lògica del treball de l'àrbitre.
Pas 1: determineu la no disponibilitat. Un esdeveniment d'error del sistema d'emmagatzematge és l'absència de ping dels dos controladors del mateix sistema d'emmagatzematge en 5 segons.
Pas 2. Inicieu el procediment de canvi. Després que l'àrbitre s'hagi adonat que un dels sistemes d'emmagatzematge no està disponible, envia una sol·licitud al sistema d'emmagatzematge "en viu" per assegurar-se que el sistema d'emmagatzematge "mort" està realment mort.
Després de rebre aquesta ordre de l'àrbitre, el segon sistema d'emmagatzematge (en directe) comprova, a més, la disponibilitat del primer sistema d'emmagatzematge caigut i, si no hi és, envia la confirmació a l'àrbitre de la seva conjectura. De fet, el sistema d'emmagatzematge no està disponible.
Després de rebre aquesta confirmació, l'àrbitre llança un procediment remot per canviar la rèplica i augmentar el mapeig en aquelles rèpliques que estaven actives (primàries) al sistema d'emmagatzematge caigut, i envia una ordre al segon sistema d'emmagatzematge per canviar aquestes rèpliques de secundària a primària i elevar el mapeig. Bé, el segon sistema d'emmagatzematge, en conseqüència, realitza aquests procediments i, a continuació, proporciona accés als LUN perduts des de si mateix.
Per què cal una verificació addicional? Per a quòrum. És a dir, la majoria del nombre total senar (3) de membres del clúster ha de confirmar la caiguda d'un dels nodes del clúster. Només llavors aquesta decisió serà definitivament correcta. Això és necessari per evitar canvis erronis i, en conseqüència, el cervell dividit.
El pas de temps 2 triga aproximadament entre 5 i 10 segons, per tant, tenint en compte el temps necessari per determinar la indisponibilitat (5 segons), entre 10 i 15 segons després de l'accident, els LUN del sistema d'emmagatzematge caigut estaran disponibles automàticament per treballar amb el directe. sistema d'emmagatzematge.
És evident que per evitar la pèrdua de connexions amb els amfitrions, també cal tenir cura de configurar correctament els temps d'espera als amfitrions. El temps d'espera recomanat és d'almenys 30 segons. Això evitarà que l'amfitrió talli la connexió al sistema d'emmagatzematge durant el canvi de càrrega en cas d'un desastre i pot garantir que no hi hagi interrupcions d'E/S.
Espereu un segon, resulta que si tot està tan bé amb el metrocluster, per què necessitem una rèplica regular?
En realitat, no tot és tan senzill.
Considerem els avantatges i els contres del metrocluster
Així doncs, ens vam adonar que els avantatges evidents del metrocluster en comparació amb la replicació convencional són:
- Automatització total, assegurant un temps de recuperació mínim en cas de desastre;
- Això és tot :-).
I ara, atenció, els contres:
- Cost de la solució. Tot i que el metroclúster dels sistemes Aerodisk no requereix llicències addicionals (s'utilitza la mateixa llicència que per a la rèplica), el cost de la solució encara serà encara més gran que l'ús de la replicació síncrona. Haureu d'implementar tots els requisits per a una rèplica síncrona, a més dels requisits per al clúster de metro associat amb un canvi addicional i un lloc addicional (vegeu la planificació del clúster de metro);
- Complexitat de la solució. El metrocluster és molt més complex que una rèplica normal, i requereix molta més atenció i esforç per a la planificació, configuració i documentació.
Finalment. Metrocluster és sens dubte una solució molt avançada tecnològicament i bona quan realment necessiteu proporcionar RTO en segons o minuts. Però si no hi ha aquesta tasca, i RTO en hores està bé per als negocis, llavors no té sentit disparar pardals amb un canó. La replicació habitual obrer-camperola és suficient, ja que un clúster de metro comportarà costos addicionals i complicació de la infraestructura informàtica.
Planificació del Metrocluster
Aquesta secció no pretén ser una guia completa per al disseny de metroclústers, sinó que només mostra les direccions principals que s'han d'elaborar si decidiu construir aquest sistema. Per tant, quan realment implementeu un metroclúster, assegureu-vos d'implicar el fabricant del sistema d'emmagatzematge (és a dir, nosaltres) i altres sistemes relacionats per a les consultes.
Llocs
Com s'ha dit anteriorment, un metroclúster requereix un mínim de tres llocs. Dos centres de dades on funcionaran els sistemes d'emmagatzematge i els sistemes relacionats, així com un tercer lloc on treballarà l'àrbitre.
La distància recomanada entre centres de dades no és superior a 40 quilòmetres. És molt probable que una distància més gran provoqui retards addicionals, que en el cas d'un clúster de metro són extremadament indesitjables. Recordem que els retards han de ser de fins a 5 mil·lisegons, tot i que s'aconsella mantenir-los en 2.
Es recomana comprovar els retards també durant el procés de planificació. Qualsevol proveïdor més o menys madur que proporcioni fibra òptica entre centres de dades pot organitzar un control de qualitat amb força rapidesa.
Pel que fa als retards davant l'àrbitre (és a dir, entre el tercer lloc i els dos primers), el llindar de retard recomanat és de fins a 200 mil·lisegons, és a dir, una connexió VPN corporativa regular a Internet és adequada.
Commutació i xarxa
A diferència de l'esquema de replicació, on n'hi ha prou amb connectar sistemes d'emmagatzematge de diferents llocs, l'esquema de metrocluster requereix connectar amfitrions amb tots dos sistemes d'emmagatzematge en llocs diferents. Per aclarir quina és la diferència, a continuació es mostren tots dos esquemes.
Com es pot veure al diagrama, els nostres amfitrions del lloc 1 miren tant el sistema d'emmagatzematge 1 com el sistema d'emmagatzematge 2. També, per contra, els amfitrions del lloc 2 miren tant el sistema d'emmagatzematge 2 com el sistema d'emmagatzematge 1. És a dir, cada host veu els dos sistemes d'emmagatzematge. Aquest és un requisit previ per al funcionament del metroclúster.
Per descomptat, no cal connectar cada host amb un cable òptic a un altre centre de dades; no n'hi haurà prou amb ports ni cables. Totes aquestes connexions s'han de fer mitjançant commutadors Ethernet 10G+ o FibreChannel 8G+ (FC només serveix per connectar amfitrions i sistemes d'emmagatzematge per a IO, actualment el canal de rèplica només està disponible mitjançant IP (Ethernet 10G+).
Ara unes quantes paraules sobre la topologia de la xarxa. Un punt important és la configuració correcta de les subxarxes. Cal definir immediatament diverses subxarxes per als següents tipus de trànsit:
- La subxarxa de replicació sobre la qual es sincronitzaran les dades entre els sistemes d'emmagatzematge. N'hi pot haver diversos, en aquest cas no importa, tot depèn de la topologia de xarxa actual (ja implementada). Si n'hi ha dos, òbviament s'ha de configurar l'encaminament entre ells;
- Subxarxes d'emmagatzematge a través de les quals els amfitrions accediran als recursos d'emmagatzematge (si és iSCSI). Hi hauria d'haver una subxarxa a cada centre de dades;
- Subxarxes de control, és a dir, tres subxarxes encaminables en tres llocs des dels quals es gestionen els sistemes d'emmagatzematge, i l'àrbitre també s'hi troba.
No considerem subxarxes per accedir als recursos de l'amfitrió aquí, ja que depenen molt de les tasques.
Separar el trànsit diferent en diferents subxarxes és extremadament important (és especialment important separar la rèplica de l'E/S), perquè si barregeu tot el trànsit en una subxarxa "gruixuda", aleshores aquest trànsit serà impossible de gestionar, i en les condicions de dos centres de dades, això encara pot provocar diferents opcions de col·lisió de xarxa. No aprofundirem en aquesta qüestió en el marc d'aquest article, ja que podeu llegir sobre la planificació d'una xarxa estirada entre centres de dades sobre els recursos dels fabricants d'equips de xarxa, on es descriu amb gran detall.
Configuració de l'àrbitre
L'àrbitre ha de proporcionar accés a totes les interfícies de gestió del sistema d'emmagatzematge mitjançant els protocols ICMP i SSH. També hauríeu de pensar en la seguretat de l'àrbitre. Aquí hi ha un matís.
La migració per error de l'àrbitre és molt desitjable, però no és necessària. Què passa si l'àrbitre xoca en el moment equivocat?
- El funcionament del metroclúster en mode normal no canviarà, perquè arbtir no té cap efecte en el funcionament del metrocluster en mode normal (la seva tasca és canviar la càrrega entre els centres de dades de manera oportuna)
- A més, si l'àrbitre cau per un motiu o un altre i "s'adorm" en un accident al centre de dades, no es produirà cap canvi, perquè no hi haurà ningú que doni les ordres de canvi necessàries i organitzi el quòrum. En aquest cas, el metroclúster es convertirà en un esquema regular amb replicació, que s'haurà de canviar manualment durant un desastre, cosa que afectarà el RTO.
Què se'n desprèn d'això? Si realment necessiteu garantir un RTO mínim, heu d'assegurar-vos que l'àrbitre sigui tolerant a errors. Hi ha dues opcions per a això:
- Inicieu una màquina virtual amb un àrbitre en un hipervisor tolerant a errors, afortunadament tots els hipervisors adults admeten la tolerància a errors;
- Si al tercer lloc (en una oficina convencional) us fa massa mandra instal·lar un clúster normal i no hi ha cap clúster d'hipervozor existent, hem proporcionat una versió de maquinari de l'àrbitre, que es fa en una caixa de 2U en què hi ha dos Els servidors x-86 funcionen i poden sobreviure a un error local.
Recomanem encaridament garantir la tolerància a fallades de l'àrbitre, malgrat que el metrocluster no ho necessita en mode normal. Però, com mostren tant la teoria com la pràctica, si creeu una infraestructura a prova de desastres veritablement fiable, és millor jugar amb seguretat. És millor protegir-se i protegir el vostre negoci de la "llei de la mesquinesa", és a dir, de la fallada tant de l'àrbitre com d'un dels llocs on es troba el sistema d'emmagatzematge.
Arquitectura de la solució
Tenint en compte els requisits anteriors, obtenim la següent arquitectura general de solució.
Els LUN s'han de distribuir uniformement entre dos llocs per evitar una sobrecàrrega greu. Al mateix temps, a l'hora de dimensionar en ambdós centres de dades, hauríeu d'incloure no només el doble volum (que és necessari per emmagatzemar dades simultàniament en dos sistemes d'emmagatzematge), sinó també el doble rendiment en IOPS i MB/s per evitar la degradació de l'aplicació en el cas de fallada d'un dels centres de dades.
Per separat, observem que amb l'enfocament adequat de la mida (és a dir, sempre que hàgim proporcionat els límits superiors adequats d'IOPS i MB/s, així com els recursos necessaris de CPU i RAM), si un dels sistemes d'emmagatzematge del El clúster de metro falla, no hi haurà una caiguda greu del rendiment en condicions de treball temporal en un sistema d'emmagatzematge.
Això s'explica pel fet que quan dos llocs funcionen simultàniament, la replicació síncrona "menja" la meitat del rendiment d'escriptura, ja que cada transacció s'ha d'escriure en dos sistemes d'emmagatzematge (similar al RAID-1/10). Així, si un dels sistemes d'emmagatzematge falla, la influència de la replicació temporalment (fins que es recuperi el sistema d'emmagatzematge fallit) desapareix i obtenim un augment del doble del rendiment d'escriptura. Després de reiniciar els LUN del sistema d'emmagatzematge fallit al sistema d'emmagatzematge en funcionament, aquest doble augment desapareix a causa del fet que apareix la càrrega dels LUN de l'altre sistema d'emmagatzematge, i tornem al mateix nivell de rendiment que teníem abans del "caiguda", però només en el marc d'un lloc.
Amb l'ajuda d'un dimensionament competent, podeu garantir condicions en què els usuaris no sentiran la fallada d'un sistema d'emmagatzematge complet. Però repetim una vegada més, això requereix una mida molt acurada, per la qual cosa, per cert, podeu contactar amb nosaltres gratuïtament :-).
Configuració d'un metroclúster
Configurar un metroclúster és molt semblant a configurar una rèplica regular, que vam descriure a . Per tant, centrem-nos només en les diferències. Vam muntar un banc al laboratori basat en l'arquitectura anterior, només en una versió mínima: dos sistemes d'emmagatzematge connectats mitjançant Ethernet 10G, dos commutadors 10G i un host que mira a través dels commutadors dels dos sistemes d'emmagatzematge amb ports 10G. L'àrbitre s'executa en una màquina virtual.
Quan configureu les IP virtuals (VIP) per a una rèplica, hauríeu de seleccionar el tipus VIP: per a metrocluster.
Hem creat dos enllaços de rèplica per a dos LUN i els hem distribuït en dos sistemes d'emmagatzematge: LUN TEST Primary al sistema d'emmagatzematge 1 (enllaç METRO), LUN TEST2 Primary per al sistema d'emmagatzematge 2 (enllaç METRO2).
Per a ells, hem configurat dos objectius idèntics (en el nostre cas iSCSI, però també és compatible amb FC, la lògica de configuració és la mateixa).
Sistema d'emmagatzematge 1:
Sistema d'emmagatzematge 2:
Per a les connexions de replicació, es van fer mapes a cada sistema d'emmagatzematge.
Sistema d'emmagatzematge 1:
Sistema d'emmagatzematge 2:
Vam configurar múltiples camins i el vam presentar a l'amfitrió.
Constitució d'un àrbitre
No cal que feu res especial amb el propi àrbitre; només heu d'habilitar-lo al tercer lloc, donar-li una IP i configurar-hi l'accés mitjançant ICMP i SSH. La pròpia configuració es realitza des dels mateixos sistemes d'emmagatzematge. En aquest cas, n'hi ha prou amb configurar l'àrbitre una vegada a qualsevol dels controladors d'emmagatzematge del metrocluster; aquests paràmetres es distribuiran a tots els controladors automàticament.
A la secció Replicació remota >> Metrocluster (a qualsevol controlador) >> el botó “Configurar”.
Introduïm la IP de l'àrbitre, així com les interfícies de control de dos controladors d'emmagatzematge remot.
Després d'això, heu d'habilitar tots els serveis (el botó "Reinicia-ho tot"). Si es tornen a configurar en el futur, els serveis s'han de reiniciar perquè la configuració tingui efecte.
Comprovem que tots els serveis funcionin.
Això completa la configuració del metrocluster.
Prova de xoc
La prova de xoc en el nostre cas serà bastant senzilla i ràpida, ja que la funcionalitat de replicació (canvi, coherència, etc.) es va parlar a . Per tant, per provar la fiabilitat del metroclúster, n'hi ha prou amb comprovar l'automatització de la detecció de fallades, la commutació i l'absència de pèrdues de gravació (atura d'E/S).
Per fer-ho, emulem una fallada completa d'un dels sistemes d'emmagatzematge apagant físicament els dos controladors, després d'haver començat a copiar primer un fitxer gran al LUN, que s'ha d'activar a l'altre sistema d'emmagatzematge.
Desactiva un sistema d'emmagatzematge. Al segon sistema d'emmagatzematge veiem alertes i missatges als registres que s'ha perdut la connexió amb el sistema veí. Si es configuren les notificacions mitjançant la supervisió SMTP o SNMP, l'administrador rebrà les notificacions corresponents.
Exactament 10 segons després (visible a les dues captures de pantalla), la connexió de rèplica de METRO (la que era primària al sistema d'emmagatzematge fallit) es va convertir automàticament en principal al sistema d'emmagatzematge en funcionament. Utilitzant el mapeig existent, LUN TEST va romandre disponible per a l'amfitrió, la gravació va baixar una mica (dins del 10 per cent promès), però no es va interrompre.
La prova s'ha completat correctament.
En resum
L'actual implantació del metroclúster als sistemes d'emmagatzematge de la sèrie N del motor AERODISK permet resoldre plenament problemes on cal eliminar o minimitzar els temps d'inactivitat dels serveis informàtics i garantir el seu funcionament les 24 hores del dia, els 7 dies de la setmana, els 365 dies de la setmana amb uns costos laborals mínims.
Podem dir, és clar, que tot això és teoria, condicions ideals de laboratori, etc. PERÒ tenim una sèrie de projectes implementats en els quals hem implementat la funcionalitat de resiliència a desastres, i els sistemes funcionen perfectament. Un dels nostres clients força coneguts, que només utilitza dos sistemes d'emmagatzematge en una configuració a prova de desastres, ja ha acceptat publicar informació sobre el projecte, de manera que en la següent part parlarem de la implementació de combat.
Gràcies, esperem una discussió productiva.
Font: www.habr.com