Saluton Habr-legantoj! En la lasta artikolo, ni parolis pri simpla rimedo de katastrofa reakiro en stoksistemoj de AERODISK ENGINE - reproduktado. En ĉi tiu artikolo, ni plonĝos en pli kompleksan kaj interesan temon - metrocluster, tio estas, aŭtomata katastrofprotekta ilo por du datumcentroj, kiu permesas datumcentrojn funkcii en aktiva-aktiva reĝimo. Ni rakontos, montros, rompos kaj riparos.
Kiel kutime, komence de la teorio
Metroareto estas areto interspacigita en plurajn ejojn ene de grandurbo aŭ distrikto. La vorto "areto" klare sugestas al ni, ke la komplekso estas aŭtomatigita, tio estas, la ŝanĝado de grapolnodoj en kazo de fiaskoj (malsukceso) okazas aŭtomate.
Ĉi tie troviĝas la ĉefa diferenco inter metrogrupo kaj regula reproduktado. Aŭtomatigo de operacioj. Tio estas, en la okazo de certaj okazaĵoj (malsukceso de la datumcentro, rompo de kanaloj, ktp.), la stokado-sistemo sendepende plenumos la necesajn agojn por konservi datumoj haveblecon. Kiam oni uzas regulajn kopiojn, ĉi tiuj agoj estas faritaj tute aŭ parte permane de la administranto.
Por kio temas?
La ĉefa celo traktita de klientoj uzantaj certajn metrocluster-efektivigojn estas minimumigi RTO (Recovery Time Objective). Tio estas, minimumigi la reakirotempon de IT-servoj post fiasko. Se vi uzas konvencian reproduktadon, tiam la reakiro-tempo ĉiam estos pli granda ol la reakiro-tempo kun metrogrupo. Kial? Tre simpla. La administranto devas esti ĉe la laborejo kaj ŝanĝi reproduktadon permane, dum la metrogrupo faras tion aŭtomate.
Se vi ne havas dediĉitan devon administranton, kiu ne dormas, ne manĝas, ne fumas aŭ malsaniĝas, sed rigardas la staton de la konserva sistemo 24 horojn tage, tiam ne estas maniero garantii, ke la administranto estos disponebla por mana ŝanĝado dum malsukceso.
Sekve, RTO en foresto de metroa grapolo aŭ senmorta administranto de la 99-a nivelo de la devo-servo de administrantoj estos egala al la sumo de la ŝanĝa tempo de ĉiuj sistemoj kaj la maksimuma tempodaŭro post kiu la administranto estas garantiita komenci labori kun la stokadsistemo kaj rilataj sistemoj.
Tiel, ni venas al la evidenta konkludo, ke la metrocluster devas esti uzata se la postulo por RTO estas minutoj, ne horoj aŭ tagoj, tio estas, kiam en la okazo de la plej malbona falo en la datumcentro, la IT-fako devas provizi la komercon tempon por restarigi aliron al IT-servoj ene de minutoj aŭ eĉ sekundoj.
Kiel ĝi funkcias?
Je la pli malalta nivelo, la metrogrupo uzas la sinkronan datuman reproduktan mekanismon, kiun ni priskribis en la antaŭa artikolo (vidu malsupre). ). Ĉar reproduktado estas sinkrona, la postuloj por ĝi taŭgas, aŭ pli ĝuste:
- fibro kiel fiziko, 10 gigabit ethernet (aŭ pli alta);
- la distanco inter datumcentroj ne estas pli ol 40 kilometroj;
- prokrasto de optika kanalo inter datumcentroj (inter stokaj sistemoj) ĝis 5 milisekundoj (optimume 2).
Ĉiuj ĉi tiuj postuloj estas konsilaj en naturo, tio estas, la metroa areto funkcios eĉ se ĉi tiuj postuloj ne estas plenumitaj, sed oni devas kompreni, ke la konsekvencoj de nerespekto de ĉi tiuj postuloj egalas al malrapidigo de la funkciado de ambaŭ stokaj sistemoj en la metroo.
Do, sinkrona kopio estas uzata por transdoni datumojn inter stokadsistemoj, sed kiel kopioj aŭtomate ŝanĝas kaj, plej grave, kiel eviti disig-cerbon? Por fari tion, ĉe la supra nivelo, aldona ento estas uzata - la arbitracianto.
Kiel funkcias arbitracianto kaj kio estas lia tasko?
La arbitro estas malgranda virtuala maŝino aŭ aparataro, kiu devas esti lanĉita sur tria retejo (ekzemple, en oficejo) kaj havigi aliron al stokado per ICMP kaj SSH. Post komenci, la arbitraciisto devas agordi la IP, kaj tiam specifi ĝian adreson de la stokado, kaj plie la adresojn de la foraj regiloj, kiuj partoprenas en la metrogrupo. Post tio, la arbitraciisto estas preta iri.
La arbitraciisto konstante kontrolas ĉiujn stokadsistemojn en la metrogrupo, kaj en la okazaĵo ke speciala stokadsistemo estas neatingebla, post konfirmo de nehavebleco de alia aretmembro (unu el la "vivaj" stokadsistemoj), li decidas komenci la proceduron por ŝanĝado de reproduktaj reguloj kaj mapado.
Tre grava punkto. La arbitracianto devas ĉiam troviĝi en loko malsama ol tiuj, sur kiuj troviĝas la stoksistemoj, tio estas, nek en DPC 1, kie stokado 1 situas, nek en DPC 2, kie stokado 2 estas instalita.
Kial? Ĉar nur tiamaniere la arbitro povas, kun la helpo de unu el la postvivantaj stoksistemoj, malambigue kaj precize determini la falon de iu el la du ejoj kie la stoksistemoj estas instalitaj. Ajna alia maniero meti arbitraciiston povas rezultigi fenditan cerbon.
Nun ni plonĝu en la detalojn de la laboro de la arbitracianto.
Pluraj servoj funkcias per la arbitraciisto, kiu konstante sondas ĉiujn stokadregilojn. Se la rezulto de la balotado diferencas de la antaŭa (disponebla/nedisponebla), tiam ĝi estas skribita en malgranda datumbazo, kiu ankaŭ funkcias ĉe la arbitracianto.
Konsideru la logikon de la arbitracianto pli detale.
Paŝo 1. Determino de nehavebleco. Okazaĵo signalanta fiaskon de stokadsistemo estas la foresto de ping de ambaŭ regiloj de la sama stokadsistemo dum 5 sekundoj.
Paŝo 2. Komencante la ŝanĝan proceduron. Post kiam la arbitraciisto rimarkis, ke unu el la stoksistemoj estas neatingebla, li sendas peton al la "viva" stoksistemo por certigi, ke la "mortinta" stoksistemo estas vere morta.
Post ricevi tian ordonon de la arbitracianto, la dua (viva) konserva sistemo aldone kontrolas la haveblecon de la falinta unua stoka sistemo kaj, se ne, sendas al la arbitraciisto konfirmon de sia diveno. SHD, ja, ne haveblas.
Post ricevado de tia konfirmo, la arbitraciisto komencas malproksiman proceduron por ŝanĝado de reproduktado kaj levado de la mapado sur tiuj kopioj kiuj estis aktivaj (ĉefaj) sur la falinta stokadsistemo, kaj sendas komandon al la dua stokadsistemo por fari tiujn kopiojn de sekundara ĝis primara kaj levi la mapadon. Nu, la dua konserva sistemo, respektive, plenumas ĉi tiujn procedurojn, post kiuj ĝi donas aliron al la perditaj LUN-oj de si mem.
Kial necesas plia konfirmo? Por kvorumo. Tio estas, la plimulto de la totala nepara (3) nombro da aretmembroj devas konfirmi la falon de unu el la aretnodoj. Nur tiam ĉi tiu decido estos ĝuste ĝusta. Ĉi tio estas necesa por eviti eraran ŝanĝadon kaj, sekve, split-cerbon.
Paŝo 2 daŭras ĉirkaŭ 5-10 sekundojn en tempo, do, konsiderante la tempon bezonatan por determini nehaveblecon (5 sekundoj), ene de 10-15 sekundoj post la fiasko, LUN-oj kun falinta stokada sistemo estos aŭtomate disponeblaj por labori kun viva stokado.
Estas klare, ke por eviti malkonektiĝon kun gastigantoj, vi ankaŭ devas prizorgi la ĝustan agordon de tempomalsukcesoj ĉe la gastigantoj. La rekomendita tempodaŭro estas almenaŭ 30 sekundoj. Ĉi tio malhelpas la gastiganton faligi la konekton al la stokado dum malsukcesa ŝarĝo kaj povas certigi, ke ne ekzistas I/O-interrompo.
Atendu sekundon, rezultas, ke se ĉio estas en ordo kun la metroa grapolo, kial ni entute bezonas regulan reproduktadon?
Fakte, ĉio ne estas tiel simpla.
Konsideru la avantaĝojn kaj malavantaĝojn de la metrogrupo
Do, ni rimarkis, ke la evidentaj avantaĝoj de la metrogrupo kompare kun konvencia reproduktado estas:
- Plena aŭtomatigo, certigante minimuman reakivan tempon en kazo de katastrofo;
- Kaj jen :-).
Kaj nun, atento, malavantaĝoj:
- Solvokosto. Kvankam la metrogrupo en Aerodisk-sistemoj ne postulas kroman licencadon (la sama permesilo estas uzata kiel por la kopio), la kosto de la solvo ankoraŭ estos eĉ pli alta ol uzado de sinkrona reproduktado. Vi devos efektivigi ĉiujn postulojn por sinkrona kopio, plus la postulojn por la metroa areto asociita kun plia ŝanĝado kaj plia retejo (vidu planadon de metroa areto);
- La komplekseco de la decido. Metrogrupo estas multe pli kompleksa ol regula kopio, kaj postulas multe pli da atento kaj penado por plani, agordi kaj dokumenti.
Fine. Metrocluster certe estas tre teknologia kaj bona solvo kiam vi vere bezonas provizi RTO en sekundoj aŭ minutoj. Sed se ne ekzistas tia tasko, kaj RTO en horoj estas bona por komerco, tiam ne havas sencon pafi paserojn el kanono. La kutima laboristo-kamparana reproduktado sufiĉas, ĉar la metroa grapolo kaŭzos aldonajn kostojn kaj komplikiĝon de la IT-infrastrukturo.
Planado de Metroa Areto
Ĉi tiu sekcio ne pretendas esti ampleksa lernilo pri metro-grupo-dezajno, sed nur montras la ĉefajn direktojn, kiuj devus esti ellaboritaj se vi decidas konstrui tian sistemon. Sekve, dum la efektiva efektivigo de la metroa grapolo, nepre impliku la fabrikanton de la stokadsistemo (tio estas, ni) kaj aliajn rilatajn sistemojn por konsulto.
Lokoj
Kiel dirite supre, metrogrupo postulas minimume tri ejojn. Du datumcentroj, kie stokaj sistemoj kaj rilataj sistemoj funkcios, same kiel tria ejo, kie la arbitro laboros.
La rekomendita distanco inter datumcentroj ne estas pli ol 40 kilometroj. Pli granda distanco estas tre verŝajne kaŭzos pliajn prokrastojn, kiuj estas tre nedezirindaj en la kazo de metroareto. Memoru, ke prokrastoj devas esti ĝis 5 milisekundoj, kvankam estas dezirinde konservi ene de 2.
Prokrastoj ankaŭ rekomendas esti kontrolitaj dum la plana procezo. Ĉiu pli-malpli plenkreska provizanto, kiu provizas fibron inter datumcentroj, povas organizi kvalitan kontrolon sufiĉe rapide.
Koncerne al la prokrastoj al la arbitracianto (tio estas, inter la tria retejo kaj la unuaj du), la rekomendita prokrasta sojlo estas ĝis 200 milisekundoj, tio estas, regula kompania VPN-konekto super la Interreto faros.
Ŝanĝado kaj reto
Male al la reproduktadskemo, kie sufiĉas konekti stokadsistemojn de malsamaj retejoj, la metroa aretskemo postulas konekti gastigantojn al ambaŭ stokadsistemoj ĉe malsamaj lokoj. Por pliklarigi kio estas la diferenco, ambaŭ skemoj estas listigitaj malsupre.
Kiel vi povas vidi el la diagramo, ni havas retejon 1 gastigantojn rigardantajn kaj stoksistemon 1 kaj stoksistemon 2. Ankaŭ, male, retejo 2 gastigantoj rigardas kaj stoksistemon 2 kaj stoksistemon 1. Tio estas, ĉiu gastiganto vidas ambaŭ stokadsistemojn. Ĉi tio estas antaŭkondiĉo por la funkciado de la metrogrupo.
Kompreneble, ne necesas tiri ĉiun gastiganton per optika ŝnuro al alia datumcentro, ne estos sufiĉe da havenoj kaj ŝnuroj. Ĉiuj ĉi tiuj konektoj devas esti faritaj per Ethernet 10G+ aŭ FibreChannel 8G+-ŝaltiloj (FC nur por konekti gastigantojn kaj stokadon por IO, la reproduktadkanalo estas nuntempe nur havebla tra IP (Ethernet 10G+).
Nun kelkajn vortojn pri la reto-topologio. Grava punkto estas la ĝusta agordo de subretoj. Vi devas tuj difini plurajn subretojn por la jenaj tipoj de trafiko:
- Subreto por reproduktado, super kiu datumoj estos sinkronigitaj inter stokadsistemoj. Povas esti pluraj el ili, ĉi-kaze ne gravas, ĉio dependas de la nuna (jam efektivigita) reto-topologio. Se estas du el ili, tiam, evidente, vojigo inter ili devas esti agordita;
- Stokadsubretoj tra kiuj gastigantoj aliros stokadresursojn (se ĝi estas iSCSI). Devus ekzisti unu tia subreto en ĉiu datumcentro;
- Kontrolu subretojn, tio estas, tri enrutigeblajn subretojn ĉe tri lokoj de kiuj stokado estas administrita, kaj la arbitracianto ankaŭ troviĝas tie.
Ni ne konsideras subretojn por aliri gastigantajn rimedojn ĉi tie, ĉar ili tre dependas de taskoj.
Apartigo de malsamaj trafikoj super malsamaj subretoj estas ege grava (precipe gravas apartigi la kopion de I / O), ĉar se vi miksas la tutan trafikon en unu "dikan" subreton, tiam ĉi tiu trafiko estos neeble administrebla, kaj en la kondiĉoj de du datumcentroj, tio ankoraŭ povas kaŭzi diversajn retajn koliziojn. Ni ne enprofundiĝos pri ĉi tiu afero en la kadro de ĉi tiu artikolo, ĉar vi povas legi pri planado de reto etendita inter datumcentroj pri la rimedoj de retaj ekipaĵoj, kie ĉi tio estas priskribita tre detale.
Arbitracia Agordo
La arbitracianto devas disponigi aliron al ĉiuj kontrolinterfacoj de la stokadsistemo per ICMP kaj SSH-protokoloj. Vi ankaŭ devus pensi pri la faŭltoleremo de la arbitracianto. Estas nuanco ĉi tie.
Arbitracimalsukceso estas tre dezirinda, sed ne postulata. Kaj kio okazas se la arbitracianto frakasas en la malĝusta tempo?
- La funkciado de la metrocluster en la normala reĝimo ne ŝanĝiĝos, ĉar arbtir neniel influas la funkciadon de la metrogrupo en la normala reĝimo (ĝia tasko estas ŝanĝi la ŝarĝon inter datumcentroj ĝustatempe)
- Samtempe, se la arbitracianto pro unu aŭ alia kialo falas kaj "dormas" la akcidenton en la datumcentro, tiam neniu ŝanĝado okazos, ĉar estos neniu por doni la necesajn ŝanĝkomandojn kaj organizi kvorumon. En ĉi tiu kazo, la metroa grapolo iĝos regula reproduktadskemo, kiu devos esti mane ŝanĝita dum katastrofo, kiu influos RTO.
Kio sekvas el tio? Se vi vere bezonas provizi minimuman RTO, vi devas certigi la faŭltoleremon de la arbitracianto. Estas du ebloj por ĉi tio:
- Ruli virtualan maŝinon kun arbitraciisto sur mistolerema hiperviziero, ĉar ĉiuj plenkreskaj hiperviziiloj subtenas misfunkciadon;
- Se en la tria retejo (en kondiĉa oficejo) estas tro maldiligente instali normalan areton kaj ne ekzistas ekzistanta aro de hiperviziiloj, tiam ni disponigis aparatan version de la arbitracianto, kiu estas farita en 2U-skatolo, en kiu funkcias du ordinaraj x-86-serviloj kaj kiuj povas travivi lokan malsukceson.
Ni forte rekomendas, ke vi certigu la faŭltoleremon de la arbitracianto, malgraŭ tio, ke la metrogrupo ne bezonas ĝin en normala reĝimo. Sed kiel kaj teorio kaj praktiko montras, se vi konstruas vere fidindan katastrof-toleran infrastrukturon, tiam estas pli bone ludi ĝin sekure. Pli bone estas protekti vin kaj vian komercon kontraŭ la "leĝo de malnobleco", tio estas, kontraŭ la malsukceso de kaj la arbitracianto kaj unu el la retejoj, kie troviĝas la stokada sistemo.
Solva arkitekturo
Konsiderante la postulojn supre, ni ricevas la jenan ĝeneralan solvan arkitekturon.
LUN-oj devas esti egale distribuitaj tra la du ejoj por eviti severan obstrukciĝon. Samtempe, kiam oni disigas en ambaŭ datumcentroj, necesas provizi ne nur duoblan volumon (kiu estas necesa por stoki datumojn samtempe sur du stokaj sistemoj), sed ankaŭ duobligi rendimenton en IOPS kaj MB/s por malhelpi la degradadon de aplikoj en la okazo de malsukceso de unu el la datumcentroj.
Aparte, ni rimarkas, ke kun taŭga aliro al grandeco (t.e., kondiĉe ke ni provizis la taŭgajn superajn limojn de IOPS kaj MB/s, kaj ankaŭ la necesajn CPU- kaj RAM-rimedojn), se unu el la stokaj sistemoj en la metroa grapolo malsukcesos, ne estos grava rendimento malpliiĝo en kondiĉoj de provizora laboro sur unu stoka sistemo.
Ĉi tio estas klarigita per la fakto, ke en kondiĉoj de du retejoj laborantaj samtempe, funkcii sinkrona reproduktado "manĝas" duonon de la skriba rendimento, ĉar ĉiu transakcio devas esti skribita al du stokadsistemoj (simila al RAID-1 / 10). Do, se unu el la stokadsistemoj malsukcesas, la efiko de reproduktado provizore (ĝis la malsukcesa stokadsistemo altiĝas) malaperas, kaj ni ricevas duoblan pliiĝon en skribefikeco. Post kiam la LUN-oj de la malsukcesa stokado-sistemo rekomenciĝis sur la funkcianta stokada sistemo, ĉi tiu duobla pliiĝo malaperas pro la fakto, ke estas ŝarĝo de la LUN-oj de alia stokada sistemo, kaj ni revenas al la sama nivelo de rendimento, kiun ni havis antaŭ la "falo", sed nur ene de la sama retejo.
Kun la helpo de kompetenta grandeco, eblas provizi kondiĉojn, sub kiuj uzantoj tute ne sentos la fiaskon de la tuta stokada sistemo. Sed denove, tio postulas tre zorgeman grandecon, kiun, cetere, vi povas kontakti nin senpage :-).
Establigo de metrogrupo
Agordo de metrogrupo estas tre simila al agordo de regula reproduktado, kiun ni priskribis en . Do ni nur koncentriĝu pri la diferencoj. Ni starigas benkon en la laboratorio surbaze de la supra arkitekturo, nur en la minimuma versio: du stokadsistemoj konektitaj per 10G Ethernet inter si, du 10G-ŝaltiloj kaj unu gastiganto, kiu rigardas tra la ŝaltiloj al ambaŭ stokadsistemoj kun 10G-havenoj. La arbitracianto funkcias per virtuala maŝino.
Kiam vi agordas virtualan IP (VIP) por kopio, vi devus elekti la VIP-tipo - por metroa grapolo.
Kreis du reproduktajn ligilojn por du LUN-oj kaj distribuis ilin super du stokadsistemoj: LUN TEST Primary sur stokado1 (METRO-konekto), LUN TEST2 Primary por stokado2 (METRO2-konekto).
Por ili, ni agordis du identajn celojn (en nia kazo, iSCSI, sed ankaŭ FC estas subtenata, la agorda logiko estas la sama).
stokado 1:
stokado 2:
Por reproduktaj ligiloj, mapadoj estis faritaj sur ĉiu stokadsistemo.
stokado 1:
stokado 2:
Ni starigis multivojon kaj prezentis ĝin al la gastiganto.
Establi arbitranton
Vi ne bezonas fari ion specialan kun la arbitracianto mem, vi nur bezonas ŝalti ĝin sur la tria retejo, agordi ĝian IP kaj agordi aliron al ĝi per ICMP kaj SSH. La agordo mem estas farita de la stokaj sistemoj mem. Samtempe, sufiĉas agordi la arbitron unufoje sur iu el la stokadregiloj en la metrogrupo, ĉi tiuj agordoj estos distribuitaj al ĉiuj regiloj aŭtomate.
Sub Remote Replication>> Metrocluster (sur iu ajn regilo)>> Agordu butonon.
Ni enigas la IP de la arbitracianto, same kiel la kontrolinterfacojn de la du foraj stokadregiloj.
Post tio, vi devas ebligi ĉiujn servojn (butono "Rekomenci Ĉion"). Se vi reagordas estonte, la servoj devas esti rekomencitaj por ke la agordoj efektiviĝu.
Ni kontrolas, ke ĉiuj servoj funkcias.
Ĉi tio kompletigas la agordon de metrocluster.
Kraŝtesto
La kraŝtesto en nia kazo estos sufiĉe simpla kaj rapida, ĉar la reproduktadfunkcio (ŝanĝado, konsistenco, ktp.) estis konsiderita en . Sekve, por testi la fidindecon de la metroa grapolo, sufiĉas por ni kontroli la aŭtomatigon de akcidento-detekto, ŝanĝado kaj la foresto de skribperdoj (I/O-haltoj).
Por fari tion, ni kopias kompletan malsukceson de unu el la stokadsistemoj fizike malŝaltante ambaŭ ĝiajn regilojn, post komenci kopii grandan dosieron al LUN, kiu devus esti aktivigita sur alia stokadsistemo.
Malŝaltu unu stoksistemon. Sur la dua konserva sistemo, ni vidas atentigojn kaj mesaĝojn en la protokoloj, ke la konekto kun la najbara sistemo malaperis. Se sciigoj per SMTP aŭ SNMP-monitorado estas agordita, tiam la taŭgaj sciigoj estos senditaj al la administranto.
Ĝuste 10 sekundojn poste (vidite en ambaŭ ekrankopioj), la METRO-reproduktadligo (tiu kiu estis Ĉefa sur la falinta stokadsistemo) aŭtomate iĝis Ĉefa sur la funkcianta stoksistemo. Uzante la ekzistantan mapadon, LUN TEST restis disponebla por la gastiganto, la registrado iomete trempis (en la promesitaj 10 procentoj), sed ne ĉesis.
La testo sukcese finiĝis.
Resumante
La nuna efektivigo de la metrogrupo en la AERODISK Engine N-serio-stokadosistemoj plene permesas vin solvi problemojn kie vi bezonas forigi aŭ minimumigi la malfunkcion de IT-servoj kaj certigi ilian funkciadon en 24/7/365 reĝimo kun minimumaj laborkostoj.
Vi povas diri, kompreneble, ke ĉio ĉi estas teorio, idealaj laboratoriokondiĉoj, kaj tiel plu... SED ni havas kelkajn efektivigitajn projektojn en kiuj ni efektivigis la katastrofan reakiro-funkcion, kaj la sistemoj funkcias perfekte. Unu el niaj sufiĉe konataj klientoj, kie nur du stoksistemoj estas uzataj en katastrof-tolerema agordo, jam konsentis publikigi informojn pri la projekto, do en la sekva parto ni parolos pri batala efektivigo.
Dankon, antaŭĝojas produktiva diskuto.
fonto: www.habr.com