Hej Habr!
Post la novjaraj ferioj, ni relanĉis kontraŭkatastrofan nubon bazitan sur du retejoj. Hodiaŭ ni rakontos al vi kiel ĝi funkcias kaj montros kio okazas al klientaj virtualaj maŝinoj kiam individuaj elementoj de la grapolo malsukcesas kaj la tuta retejo kraŝas (spoiler - ĉio estas en ordo kun ili).
Katastrofrezista nuba stokadosistemo sur la OST-ejo.
Kio estas interne
Sub la kapuĉo, la areto havas Cisco UCS-servilojn kun VMware ESXi-hiperviziero, du INFINIDAT InfiniBox F2240 stokadsistemojn, Cisco Nexus-retajn ekipaĵojn, same kiel Brocade SAN-ŝaltilojn. La areto estas dividita en du ejojn - OST kaj NORD, t.e. ĉiu datumcentro havas identan aron de ekipaĵo. Efektive, ĉi tio faras ĝin imuna al katastrofoj.
Ene de unu retejo, la ĉefaj elementoj ankaŭ estas duobligitaj (gastigantoj, SAN-ŝaltiloj, retoj).
La du ejoj estas ligitaj per diligentaj fibro-optikaj itineroj, ankaŭ rezervitaj.
Kelkajn vortojn pri stokaj sistemoj. Ni konstruis la unuan version de katastrofa nubo sur NetApp. Ĉi tie ni elektis INFINIDAT, kaj jen kial:
- Aktiva-Aktiva replika opcio. Ĝi permesas al la virtuala maŝino resti funkcianta eĉ se unu el la stokadsistemoj tute malsukcesas. Mi rakontos al vi pli pri reproduktado poste.
- Tri diskregiloj por pliigi sisteman faŭltoleremon. Kutime estas du.
- Preta solvo. Ni ricevis antaŭmuntitan rakon, kiu nur bezonas esti konektita al la reto kaj agordita.
- Atenta teknika subteno. INFINIDAT-inĝenieroj konstante analizas stoksistemojn protokolojn kaj eventojn, instalas novajn firmware-versiojn kaj helpas pri agordo.
Jen kelkaj fotoj de elpakado:
Kiel ĝi funkcias
La nubo jam estas tolerema al misfaroj en si mem. Ĝi protektas la klienton kontraŭ unuopaj misfunkciadoj de aparataro kaj programaro. Katastrofrezista helpos protekti kontraŭ amasaj misfunkciadoj ene de unu retejo: ekzemple, fiasko de stokada sistemo (aŭ SDS-areto, kio okazas sufiĉe ofte 🙂), amasaj eraroj en stoka reto, ktp. Nu, kaj plej grave: tia nubo ŝparas kiam tuta retejo fariĝas nealirebla pro fajro, senkurentiĝo, rabatakanto aŭ eksterterana surteriĝo.
En ĉiuj ĉi tiuj kazoj, la klientaj virtualaj maŝinoj daŭre funkcias, kaj jen kial.
La areto-dezajno estas desegnita tiel ke ĉiu ESXi-gastiganto kun klientaj virtualaj maŝinoj povas aliri iun el la du stokadsistemoj. Se la konserva sistemo en la OST-ejo malsukcesas, la virtualaj maŝinoj daŭre funkcios: la gastigantoj, sur kiuj ili funkcias, aliros la stoksistemon ĉe NORD por datumoj.
Jen kiel aspektas la koneksa diagramo en areto.
Ĉi tio eblas pro la fakto, ke Inter-Switch Link estas agordita inter la SAN-ŝtofoj de la du ejoj: la Fabric A OST SAN-ŝaltilo estas konektita al la Fabric A NORD SAN-ŝaltilo, kaj simile por la Fabric B SAN-ŝaltiloj.
Nu, por ke ĉiuj ĉi tiuj komplikaĵoj de SAN-fabrikoj havu sencon, Aktiva-Aktiva reproduktado estas agordita inter la du stokadsistemoj: informoj estas preskaŭ samtempe skribitaj al la lokaj kaj malproksimaj stokadsistemoj, RPO = 0. Rezultas, ke la originaj datumoj estas konservitaj en unu stoka sistemo, kaj ĝia kopio estas konservita sur la alia. Datenoj estas reproduktitaj je la nivelo de stokadvolumoj, kaj la VM-datumoj (ĝiaj diskoj, agorda dosiero, interŝanĝdosiero ktp.) estas stokitaj sur ili.
La ESXi-gastiganto vidas la primaran volumon kaj ĝian kopion kiel unu disko-aparato (Stoka Aparato). Estas 24 vojoj de la ESXi-gastiganto al ĉiu diskaparato:
12 padoj ligas ĝin al la loka stokadsistemo (optimumaj padoj), kaj la ceteraj 12 al la malproksima stokadsistemo (ne-optimumaj padoj). En normala situacio, ESXi aliras datumojn sur la loka stokada sistemo uzante "optimumajn" vojojn. Kiam ĉi tiu konserva sistemo malsukcesas, ESXi perdas optimumajn vojojn kaj ŝanĝas al "ne-optimumaj". Jen kiel ĝi aspektas sur la diagramo.
Skemo de katastrof-rezista areto.
Ĉiuj klientretoj estas konektitaj al ambaŭ retejoj per komuna retoŝtofo. Ĉiu retejo funkciigas Provizan Rando (PE), sur kiu la retoj de la kliento estas finitaj. PEoj estas kunigitaj en oftan areton. Se PE malsukcesas ĉe unu loko, la tuta trafiko estas redirektita al la dua retejo. Danke al ĉi tio, virtualaj maŝinoj de la retejo forlasita sen PE restas alireblaj tra la reto al la kliento.
Ni nun vidu, kio okazos al klientaj virtualaj maŝinoj dum diversaj fiaskoj. Ni komencu per la plej malpezaj elektoj kaj fini per la plej serioza - fiasko de la tuta retejo. En la ekzemploj, la ĉefa platformo estos OST, kaj la rezerva platformo, kun datumaj kopioj, estos NORD.
Kio okazas al la klienta virtuala maŝino se...
Replica Ligo malsukcesas. Reproduktado inter la stokaj sistemoj de la du ejoj ĉesas.
ESXi funkcios nur kun lokaj disko-aparatoj (per optimumaj vojoj).
Virtualaj maŝinoj daŭre funkcias.
La ISL (Inter-Switch Link) rompiĝas. La kazo estas neverŝajna. Krom se iu freneza elkavatoro elfosas plurajn optigajn itinerojn samtempe, kiuj funkcias laŭ sendependaj itineroj kaj estas alportitaj al la ejoj per malsamaj enigaĵoj. Sed ĉiuokaze. En ĉi tiu kazo, ESXi-gastigantoj perdas duonon de la vojoj kaj nur povas aliri siajn lokajn stokadsistemojn. Kopioj estas kolektitaj, sed gastigantoj ne povos aliri ilin.
Virtualaj maŝinoj funkcias normale.
La SAN-ŝaltilo malsukcesas en unu el la retejoj. ESXi-gastigantoj perdas kelkajn el la vojoj al la stokadsistemo. En ĉi tiu kazo, la gastigantoj ĉe la retejo, kie la ŝaltilo malsukcesis, funkcios nur per unu el siaj HBA-oj.
La virtualaj maŝinoj daŭre funkcias normale.
Ĉiuj SAN-ŝaltiloj sur unu el la retejoj malsukcesas. Ni diru, ke tia katastrofo okazis sur la OST-ejo. En ĉi tiu kazo, ESXi-gastigantoj en ĉi tiu retejo perdos ĉiujn vojojn al siaj disko-aparatoj. La norma VMware vSphere HA-mekanismo ekfunkcias: ĝi rekomencos ĉiujn virtualajn maŝinojn de la OST-ejo en NORD en maksimume 140 sekundoj.
Virtualaj maŝinoj funkciigantaj sur NORD-retaj gastigantoj funkcias normale.
La ESXi-gastiganto malsukcesas en unu retejo. Ĉi tie la mekanismo de vSphere HA denove funkcias: virtualaj maŝinoj de la malsukcesa gastiganto estas rekomencitaj sur aliaj gastigantoj - sur la sama aŭ fora retejo. La tempo de rekomenco de virtuala maŝino estas ĝis 1 minuto.
Se ĉiuj ESXi-gastigantoj en la OST-ejo malsukcesas, ne ekzistas ebloj: la VM-oj estas rekomencitaj sur alia. Rekomenca tempo estas la sama.
La konserva sistemo malsukcesas ĉe unu loko. Ni diru, ke la konserva sistemo malsukcesas ĉe la OST-ejo. Tiam la ESXi-gastigantoj de la OST-ejo ŝanĝas por labori kun stokaj kopioj en NORD. Post kiam la malsukcesa stokadsistemo revenos al servo, devigita reproduktado okazos kaj la ESXi OST-gastigantoj denove komencos aliri la lokan stokadsistemon.
Virtualaj maŝinoj funkciis normale dum ĉi tiu tempo.
Unu el la retejoj malsukcesas. En ĉi tiu kazo, ĉiuj virtualaj maŝinoj estos rekomencitaj sur la rezerva retejo per la mekanismo vSphere HA. La tempo de rekomenco de VM estas 140 sekundoj. En ĉi tiu kazo, ĉiuj retaj agordoj de la virtuala maŝino estos konservitaj, kaj ĝi restas alirebla por la kliento per la reto.
Por certigi, ke la rekomenco de maŝinoj ĉe la rezerva retejo iras glate, ĉiu retejo estas nur duonplena. La dua duono estas rezervo, se ĉiuj virtualaj maŝinoj moviĝas de la dua, difektita retejo.
Katastrofrezista nubo bazita sur du datumcentroj protektas kontraŭ tiaj fiaskoj.
Ĉi tiu plezuro ne estas malmultekosta, ĉar krom la ĉefaj rimedoj necesas rezervo sur la dua retejo. Tial, komercaj kritikaj servoj estas metitaj en tian nubon, kies longtempa malfunkcio kaŭzas grandajn financajn kaj reputaciajn perdojn, aŭ se la informsistemo estas submetata al katastrof-rezistemaj postuloj de regulistoj aŭ internaj kompaniaj regularoj.
Fontoj:
fonto: www.habr.com