Hallo Habr-lesers! In die laaste artikel het ons gepraat oor 'n eenvoudige manier van rampherstel in AERODISK ENGINE-bergingstelsels - replikasie. In hierdie artikel sal ons in 'n meer komplekse en interessante onderwerp duik - 'n metrocluster, dit wil sê 'n outomatiese rampbeskermingsinstrument vir twee datasentrums wat datasentrums toelaat om in aktief-aktiewe modus te werk. Ons sal vertel, wys, breek en regmaak.
Soos gewoonlik, aan die begin van die teorie
'n Metrokluster is 'n groep wat in verskeie terreine binne 'n stad of distrik gespasieer is. Die woord "cluster" dui duidelik vir ons aan dat die kompleks geoutomatiseer is, dit wil sê die omskakeling van cluster nodusse in geval van mislukkings (failover) vind outomaties plaas.
Dit is waar die belangrikste verskil tussen 'n metrocluster en gereelde replikasie lê. Outomatisering van bedrywighede. Dit wil sê, in die geval van sekere voorvalle (mislukking van die datasentrum, breek van kanale, ens.), sal die bergingstelsel onafhanklik die nodige aksies uitvoer om die beskikbaarheid van data te handhaaf. Wanneer gereelde replikas gebruik word, word hierdie aksies heeltemal of gedeeltelik met die hand deur die administrateur uitgevoer.
Waarvoor is dit?
Die hoofdoelwit wat deur kliënte nagestreef word wat sekere metrocluster-implementerings gebruik, is om RTO (Recovery Time Objective) te minimaliseer. Dit wil sê om die hersteltyd van IT-dienste na 'n mislukking te verminder. As jy konvensionele replikasie gebruik, sal die hersteltyd altyd groter wees as die hersteltyd met 'n metro-kluster. Hoekom? Baie eenvoudig. Die administrateur moet by die werkplek wees en replikasie met die hand oorskakel, terwyl die metro-kluster dit outomaties doen.
As jy nie 'n toegewyde diensadministrateur het wat nie slaap nie, nie eet nie, nie rook of siek word nie, maar 24 uur per dag na die stand van die stoorstelsel kyk, dan is daar geen manier om te waarborg dat die administrateur sal beskikbaar wees vir handskakeling tydens 'n mislukking.
Gevolglik sal RTO in die afwesigheid van 'n metrocluster of 'n onsterflike admin van die 99ste vlak van die administrateurdiensdiens gelyk wees aan die som van die skakeltyd van alle stelsels en die maksimum tydperk waarna die administrateur gewaarborg is om te begin werk met stoorstelsels en verwante stelsels.
Ons kom dus tot die voor die hand liggende gevolgtrekking dat die metrocluster gebruik moet word as die vereiste vir RTO minute is, nie ure of dae nie, dit wil sê wanneer, in die geval van die mees verskriklike val van die datasentrum, die IT-afdeling moet voorsien die besigheid met tyd om toegang tot IT-dienste binne minute of selfs sekondes te herstel.
Hoe werk dit?
Op die laer vlak gebruik die metrocluster die sinchrone data-replikasiemeganisme wat ons in die vorige artikel beskryf het (sien hieronder). ). Aangesien replikasie sinchronies is, is die vereistes daarvoor toepaslik, of eerder:
- vesel as fisika, 10 gigabit ethernet (of hoër);
- die afstand tussen datasentrums is nie meer as 40 kilometer nie;
- optiese kanaalvertraging tussen datasentrums (tussen bergingstelsels) tot 5 millisekondes (optimaal 2).
Al hierdie vereistes is adviserende van aard, dit wil sê, die metro-kluster sal werk selfs al word nie aan hierdie vereistes voldoen nie, maar dit moet verstaan word dat die gevolge van nie-nakoming van hierdie vereistes gelykstaande is aan die verlangsaming van die werking van beide bergingstelsels in die metro-kluster.
Dus, 'n sinchrone replika word gebruik om data tussen bergingstelsels oor te dra, maar hoe skakel replikas outomaties oor en, bowenal, hoe om gesplete brein te vermy? Om dit te doen, op die vlak hierbo, word 'n bykomende entiteit gebruik - die arbiter.
Hoe werk 'n arbiter en wat is sy taak?
Die arbiter is 'n klein virtuele masjien of 'n hardeware-kluster wat op 'n derde webwerf (byvoorbeeld in 'n kantoor) geloods moet word en toegang tot berging via ICMP en SSH verskaf. Nadat die arbiter begin het, moet die arbiter die IP stel, en dan sy adres van die stoorkant spesifiseer, plus die adresse van die afstandbeheerders wat aan die metro-groep deelneem. Daarna is die skeidsregter gereed om te gaan.
Die arbiter moniteer voortdurend alle bergingstelsels in die metro-groepering, en in die geval dat 'n bepaalde bergingstelsel onbeskikbaar is, na bevestiging van onbeskikbaarheid van 'n ander groeplid (een van die "lewendige" stoorstelsels), besluit hy om die prosedure vir omskakeling van replikasiereëls en kartering.
'n Baie belangrike punt. Die arbiter moet altyd op 'n ander terrein geleë wees as dié waarop die bergingstelsels geleë is, dit wil sê nie in DPC 1, waar berging 1 geleë is, nóg in DPC 2, waar berging 2 geïnstalleer is.
Hoekom? Want net so kan die arbiter met behulp van een van die oorblywende bergingstelsels ondubbelsinnig en akkuraat die val van enige van die twee terreine waar die bergingstelsels geïnstalleer is, bepaal. Enige ander manier om 'n arbiter te plaas, kan lei tot 'n gesplete brein.
Kom ons duik nou in die besonderhede van die arbiter se werk.
Verskeie dienste loop op die arbiter wat voortdurend alle stoorbeheerders ondervra. As die uitslag van die peiling verskil van die vorige een (beskikbaar/onbeskikbaar), dan word dit na 'n klein databasis geskryf wat ook op die arbiter werk.
Oorweeg die logika van die arbiter in meer besonderhede.
Stap 1. Bepaling van onbeskikbaarheid. 'n Gebeurtenis wat 'n stoorstelselfout aandui, is die afwesigheid van 'n ping van beide beheerders van dieselfde bergingstelsel vir 5 sekondes.
Stap 2. Begin van die oorskakelingsprosedure. Nadat die arbiter besef het dat een van die stoorstelsels nie beskikbaar is nie, stuur hy 'n versoek na die "lewendige" stoorstelsel om seker te maak dat die "dooie" stoorstelsel werklik dood is.
Nadat so 'n opdrag van die arbiter ontvang is, kontroleer die tweede (lewendige) bergingstelsel addisioneel die beskikbaarheid van die gevalle eerste stoorstelsel en, indien nie, stuur die arbiter bevestiging van sy raaiskoot. SHD is inderdaad nie beskikbaar nie.
Na ontvangs van sodanige bevestiging, begin die arbiter 'n afstandprosedure vir die omskakeling van replikasie en die verhoging van die kartering op daardie replikas wat aktief (primêr) op die gevalle bergingstelsel was, en stuur 'n opdrag na die tweede bergingstelsel om hierdie replikas van sekondêr na primêre te maak en verhoog die kartering. Wel, die tweede bergingstelsel voer onderskeidelik hierdie prosedures uit, waarna dit vanaf homself toegang tot die verlore LUN'e verskaf.
Hoekom is bykomende verifikasie nodig? Vir kworum. Dit wil sê, die meerderheid van die totale onewe (3) aantal klusterlede moet die val van een van die klusternodusse bevestig. Eers dan sal hierdie besluit presies reg wees. Dit is nodig om foutiewe oorskakeling en gevolglik gesplete brein te vermy.
Stap 2 neem ongeveer 5-10 sekondes betyds, dus, met inagneming van die tyd wat nodig is om onbeskikbaarheid (5 sekondes) te bepaal, binne 10-15 sekondes na die mislukking, sal LUN's met 'n gevalle bergingstelsel outomaties beskikbaar wees om met lewendige werk te werk berging.
Dit is duidelik dat om te verhoed dat die verbinding met die gashere verbreek word, jy ook moet sorg vir die korrekte instelling van time-outs op die gashere. Die aanbevole tydsduur is ten minste 30 sekondes. Dit verhoed dat die gasheer die verbinding met die berging laat val tydens 'n failover-lading en kan verseker dat daar geen I/O-onderbreking is nie.
Wag 'n oomblik, dit blyk dat as alles reg is met die metro-kluster, hoekom het ons enigsins gereelde replikasie nodig?
Trouens, alles is nie so eenvoudig nie.
Oorweeg die voor- en nadele van die metrocluster
So, ons het besef dat die ooglopende voordele van die metrocluster in vergelyking met konvensionele replikasie is:
- Volle outomatisering, wat minimale hersteltyd verseker in die geval van 'n ramp;
- En dit is dit :-).
En nou, aandag, nadele:
- Oplossing koste. Alhoewel die metrocluster in Aerodisk-stelsels nie addisionele lisensiëring vereis nie (dieselfde lisensie word gebruik as vir die replika), sal die koste van die oplossing steeds selfs hoër wees as om sinchrone replikasie te gebruik. Jy sal al die vereistes vir 'n sinchrone replika moet implementeer, plus die vereistes vir die metro-kluster wat verband hou met bykomende skakeling en bykomende terrein (sien metro-klusterbeplanning);
- Die kompleksiteit van die besluit. 'n Metrocluster is baie meer kompleks as 'n gewone replika, en verg baie meer aandag en moeite om te beplan, op te stel en te dokumenteer.
Uiteindelik. Metrocluster is beslis 'n baie tegnologiese en goeie oplossing wanneer jy regtig RTO binne sekondes of minute moet verskaf. Maar as daar nie so 'n taak is nie, en RTO in ure is OK vir besigheid, dan maak dit geen sin om mossies uit 'n kanon te skiet nie. Die gewone werker-boer-replikasie is genoeg, aangesien die metro-kluster bykomende koste en komplikasie van die IT-infrastruktuur sal veroorsaak.
Metro-klusterbeplanning
Hierdie afdeling gee nie voor om 'n omvattende tutoriaal oor metro-kluster-ontwerp te wees nie, maar wys slegs die hoofrigtings wat uitgewerk moet word as jy besluit om so 'n stelsel te bou. Daarom, tydens die werklike implementering van die metro-kluster, maak seker dat u die vervaardiger van die bergingstelsel (dit is ons) en ander verwante stelsels vir konsultasie betrek.
Plekke
Soos hierbo genoem, benodig 'n metrokluster 'n minimum van drie terreine. Twee datasentrums, waar bergingstelsels en verwante stelsels sal werk, asook 'n derde webwerf, waar die arbiter sal werk.
Die aanbevole afstand tussen datasentrums is nie meer as 40 kilometer nie. 'n Groter afstand sal hoogs waarskynlik bykomende vertragings veroorsaak, wat hoogs ongewens is in die geval van 'n metro-kluster. Onthou dat vertragings tot 5 millisekondes moet wees, hoewel dit wenslik is om binne 2 te hou.
Vertragings word ook aanbeveel om tydens die beplanningsproses nagegaan te word. Enige min of meer volwasse verskaffer wat vesel tussen datasentrums verskaf, kan redelik vinnig 'n kwaliteitkontrole reël.
Wat die vertragings aan die arbiter betref (dit wil sê tussen die derde werf en die eerste twee), is die aanbevole vertragingsdrempel tot 200 millisekondes, dit wil sê 'n gereelde korporatiewe VPN-verbinding oor die internet sal doen.
Skakeling en netwerk
Anders as die replikasieskema, waar dit genoeg is om bergingstelsels vanaf verskillende werwe te koppel, vereis die metro-klusterskema dat gashere aan beide bergingstelsels op verskillende terreine gekoppel word. Om dit duideliker te maak wat die verskil is, word beide skemas hieronder gelys.
Soos jy uit die diagram kan sien, het ons werf 1-gashere wat na beide berging 1 en berging 2 kyk. Inteendeel, werf 2-gashere kyk ook na beide berging 2 en berging 1. Dit wil sê, elke gasheer sien beide bergingstelsels. Dit is 'n voorvereiste vir die werking van die metrokluster.
Natuurlik is dit nie nodig om elke gasheer met 'n optiese koord na 'n ander datasentrum te trek nie, daar sal nie genoeg poorte en toue wees nie. Al hierdie verbindings moet gemaak word deur Ethernet 10G+ of FibreChannel 8G+ skakelaars (FC slegs vir die koppeling van gashere en berging vir IO, die replikasiekanaal is tans slegs beskikbaar oor IP (Ethernet 10G+).
Nou 'n paar woorde oor die netwerktopologie. 'n Belangrike punt is die korrekte konfigurasie van subnette. Jy moet onmiddellik verskeie subnette definieer vir die volgende soorte verkeer:
- Subnet vir replikasie, waaroor data tussen bergingstelsels gesinchroniseer sal word. Daar kan verskeie van hulle wees, in hierdie geval maak dit nie saak nie, dit hang alles af van die huidige (reeds geïmplementeerde) netwerktopologie. As daar twee van hulle is, dan moet roetering tussen hulle natuurlik gekonfigureer word;
- Bergingsubnette waardeur gashere toegang tot bergingshulpbronne sal verkry (as dit iSCSI is). Daar moet een so subnet in elke datasentrum wees;
- Beheer subnette, dit wil sê drie herleibare subnette by drie werwe vanwaar berging bestuur word, en die arbiter is ook daar geleë.
Ons oorweeg nie subnette vir toegang tot gasheerhulpbronne hier nie, aangesien dit baie afhanklik is van take.
Om verskillende verkeer in verskillende subnette te skei is uiters belangrik (dit is veral belangrik om die replika van die I / O te skei), want as jy al die verkeer in een "dik" subnet meng, dan sal hierdie verkeer onmoontlik wees om te bestuur, en in die toestande van twee datasentrums kan dit steeds verskeie netwerkbotsingsopsies veroorsaak. Ons sal nie binne die raamwerk van hierdie artikel diep in hierdie kwessie delf nie, aangesien u kan lees oor die beplanning van 'n netwerk tussen datasentrums op die hulpbronne van netwerktoerustingvervaardigers, waar dit in groot detail beskryf word.
Arbiter konfigurasie
Die arbiter moet toegang verskaf tot alle beheerkoppelvlakke van die bergingstelsel via ICMP- en SSH-protokolle. Jy moet ook dink oor die fouttoleransie van die arbiter. Hier is 'n nuanse.
Arbiter failover is hoogs wenslik, maar nie nodig nie. En wat gebeur as die arbiter op die verkeerde tyd ineenstort?
- Die werking van die metrocluster in die normale modus sal nie verander nie, want arbtir beïnvloed glad nie die werking van die metrocluster in normale modus nie (sy taak is om die las tussen datasentrums betyds te wissel)
- Terselfdertyd, as die arbiter om die een of ander rede val en die ongeluk in die datasentrum "slaap", sal geen oorskakeling plaasvind nie, want daar sal niemand wees om die nodige skakelopdragte te gee en 'n kworum te organiseer nie. In hierdie geval sal die metro-kluster in 'n gereelde replikasieskema verander, wat tydens 'n ramp handmatig omgeskakel sal moet word, wat RTO sal beïnvloed.
Wat volg hieruit? As jy regtig 'n minimum RTO moet verskaf, moet jy die fouttoleransie van die arbiter verseker. Daar is twee opsies hiervoor:
- Begin 'n virtuele masjien met 'n arbiter op 'n foutverdraagsame hipervisor, aangesien alle volwasse hipervisors foutverdraagsaamheid ondersteun;
- As dit op die derde werf (in 'n voorwaardelike kantoor) te lui is om 'n normale groepie te installeer en daar is geen bestaande groep hipervisers nie, dan het ons 'n hardeware weergawe van die arbiter verskaf, wat in 'n 2U-boks gemaak is, waarin twee gewone x-86-bedieners werk en wat 'n plaaslike mislukking kan oorleef.
Ons beveel sterk aan dat jy die fouttoleransie van die arbiter verseker, ten spyte van die feit dat die metro-kluster dit nie in normale modus nodig het nie. Maar soos beide teorie en praktyk toon, as jy 'n werklik betroubare rampverdraagsame infrastruktuur bou, is dit beter om dit veilig te speel. Dit is beter om jouself en jou besigheid te beskerm teen die "wet van gemeenheid", dit wil sê teen die mislukking van beide die arbiter en een van die terreine waar die bergingstelsel geleë is.
Oplossingsargitektuur
Met inagneming van die vereistes hierbo, kry ons die volgende algemene oplossing-argitektuur.
LUN's moet eweredig oor die twee terreine versprei word om erge opeenhoping te vermy. Terselfdertyd, wanneer die grootte in beide datasentrums verander word, is dit nodig om nie net dubbel die volume te verskaf nie (wat nodig is om data gelyktydig op twee stoorstelsels te stoor), maar ook dubbele werkverrigting in IOPS en MB / s om te voorkom agteruitgang van toepassings in die geval van 'n mislukking van een van die datasentrums - ov.
Afsonderlik neem ons kennis dat met die regte benadering tot grootte (dit wil sê, op voorwaarde dat ons voorsiening gemaak het vir die behoorlike boonste limiete van IOPS en MB / s, sowel as die nodige SVE en RAM hulpbronne), as een van die bergingstelsels in die metro-kluster misluk, sal daar geen ernstige prestasiedaling in toestande wees nie tydelike werk aan een bergingstelsel.
Dit word verklaar deur die feit dat in toestande van twee werwe wat gelyktydig werk, sinchroniese replikasie die helfte van die skryfwerkverrigting "vreet", aangesien elke transaksie na twee stoorstelsels geskryf moet word (soortgelyk aan RAID-1 / 10). Dus, as een van die bergingstelsels misluk, verdwyn die effek van replikasie tydelik (totdat die mislukte bergingstelsel styg), en ons kry 'n tweevoudige toename in skryfwerkverrigting. Nadat die LUN's van die mislukte bergingstelsel op die werkende bergingstelsel herbegin het, verdwyn hierdie tweevoudige toename as gevolg van die feit dat daar 'n las van die LUNs van 'n ander bergingstelsel is, en ons keer terug na dieselfde vlak van werkverrigting as wat ons voor die “val”, maar net binne dieselfde platform.
Met behulp van bekwame grootte is dit moontlik om toestande te verskaf waaronder gebruikers glad nie die mislukking van die hele bergingstelsel sal voel nie. Maar weereens, dit vereis baie versigtige grootte, wat, terloops, jy ons gratis kan kontak :-).
Die opstel van 'n metro-kluster
Die opstel van 'n metro-kluster is baie soortgelyk aan die opstel van gereelde replikasie, wat ons beskryf het in . Laat ons dus net op die verskille fokus. Ons het 'n bankie in die laboratorium opgestel op grond van die argitektuur hierbo, slegs in die minimum weergawe: twee bergingstelsels wat via 10G Ethernet aan mekaar gekoppel is, twee 10G skakelaars en een gasheer wat deur die skakelaars kyk na albei bergingstelsels met 10G-poorte. Die arbiter loop op 'n virtuele masjien.
Wanneer u virtuele IP (VIP) vir 'n replika opstel, moet u die VIP-tipe kies - vir 'n metro-groepering.
Het twee replikasieskakels vir twee LUN's geskep en dit oor twee stoorstelsels versprei: LUN TEST Primêr op stoor1 (METRO-verbinding), LUN TEST2 Primêr vir stoor2 (METRO2-verbinding).
Vir hulle het ons twee identiese teikens opgestel (in ons geval, iSCSI, maar FC word ook ondersteun, die konfigurasielogika is dieselfde).
berging 1:
berging 2:
Vir replikasieskakels is kartering op elke stoorstelsel gemaak.
berging 1:
berging 2:
Ons het multipath opgestel en dit aan die gasheer aangebied.
Die opstel van 'n arbiter
U hoef niks spesiaals met die arbiter self te doen nie, u hoef dit net op die derde webwerf aan te skakel, sy IP in te stel en toegang daartoe op te stel via ICMP en SSH. Die konfigurasie self word vanaf die bergingstelsels self uitgevoer. Terselfdertyd is dit genoeg om die arbiter een keer op enige van die stoorbeheerders in die metro-groep op te stel, hierdie instellings sal outomaties aan alle beheerders versprei word.
Onder Afstandsreplikasie>> Metrocluster (op enige beheerder)>> Konfigureer-knoppie.
Ons voer die IP van die arbiter in, sowel as die beheerkoppelvlakke van die twee afstandbeheerders.
Daarna moet u alle dienste aktiveer (knoppie "Herbegin alles"). As jy in die toekoms herkonfigureer, moet die dienste herbegin word vir die instellings om in werking te tree.
Ons kyk of alle dienste loop.
Dit voltooi die metrocluster-opstelling.
Botsingstoets
Die botstoets in ons geval sal redelik eenvoudig en vinnig wees, aangesien die replikasie-funksionaliteit (omskakeling, konsekwentheid, ens.) oorweeg is in . Daarom, om die betroubaarheid van die metro-kluster te toets, is dit genoeg vir ons om die outomatisering van ongelukopsporing, skakeling en die afwesigheid van skryfverliese (I/O-stops) na te gaan.
Om dit te doen, boots ons 'n volledige mislukking van een van die bergingstelsels na deur beide sy beheerders fisies af te skakel, nadat ons 'n groot lêer na 'n LUN begin kopieer het, wat op 'n ander bergingstelsel geaktiveer moet word.
Deaktiveer een bergingstelsel. Op die tweede bergingstelsel sien ons waarskuwings en boodskappe in die logs dat die verbinding met die naburige stelsel verdwyn het. As kennisgewings via SMTP- of SNMP-monitering opgestel is, sal die toepaslike kennisgewings aan die administrateur gestuur word.
Presies 10 sekondes later (gesien in albei skermkiekies), het die METRO-replikasieskakel (die een wat Primêr was op die gevalle stoorstelsel) outomaties Primêr geword op die werkende stoorstelsel. Deur die bestaande kartering te gebruik, het LUN TEST vir die gasheer beskikbaar gebly, die opname het 'n bietjie gedaal (binne die beloofde 10 persent), maar het nie gestop nie.
Die toets is suksesvol voltooi.
Opsomming
Die huidige implementering van die metrocluster in die AERODISK Engine N-reeks bergingstelsels stel jou ten volle in staat om probleme op te los waar jy die stilstand van IT-dienste moet uitskakel of minimaliseer en hul werking in 24/7/365-modus moet verseker met minimale arbeidskoste.
Jy kan natuurlik sê dat dit alles teorie is, ideale laboratoriumtoestande, ensovoorts ... MAAR ons het 'n aantal geïmplementeerde projekte waarin ons die rampherstelfunksionaliteit geïmplementeer het, en die stelsels werk perfek. Een van ons redelik bekende kliënte, waar net twee bergingstelsels in 'n rampverdraagsame opset gebruik word, het reeds ingestem om inligting oor die projek te publiseer, so in die volgende deel sal ons oor gevegsimplementering praat.
Dankie, sien uit na 'n produktiewe bespreking.
Bron: will.com