Sveiki, Habr skaitytojai! Paskutiniame straipsnyje kalbėjome apie paprastą atkūrimo priemonę AERODISK ENGINE saugojimo sistemose – replikaciją. Šiame straipsnyje pasinersime į sudėtingesnę ir įdomesnę temą – metroklasterį, tai yra dviejų duomenų centrų automatinės apsaugos nuo nelaimių priemonę, leidžiančią duomenų centrams veikti aktyviu-aktyviu režimu. Mes jums pasakysime, parodysime, sulaužysime ir sutvarkysime.
Kaip įprasta, pirmiausia teorija
Metroklasteris yra klasteris, išsidėstęs keliose miesto ar regiono vietose. Žodis „klasteris“ mums aiškiai rodo, kad kompleksas yra automatizuotas, ty klasterio mazgų perjungimas gedimų atveju vyksta automatiškai.
Čia yra pagrindinis skirtumas tarp metroklasterio ir įprastos replikacijos. Operacijų automatizavimas. Tai yra, įvykus tam tikriems incidentams (duomenų centro gedimas, nutrūkę kanalai ir pan.), saugojimo sistema savarankiškai atliks reikiamus veiksmus, kad būtų išlaikytas duomenų prieinamumas. Naudojant įprastas kopijas, administratorius šiuos veiksmus visiškai arba iš dalies atlieka rankiniu būdu.
Ką jis daro?
Pagrindinis tikslas, kurio klientai siekia, kai naudoja tam tikrus metrocluster diegimus, yra sumažinti RTO (Recovery Time Objective). Tai yra, siekiant sumažinti IT paslaugų atkūrimo laiką po gedimo. Jei naudosite įprastą replikaciją, atkūrimo laikas visada bus ilgesnis nei atkūrimo laikas naudojant metroklasterį. Kodėl? Labai paprasta. Administratorius turi būti prie savo stalo ir perjungti replikaciją rankiniu būdu, o metroklasteris tai daro automatiškai.
Jei neturite budinčio paskirto administratoriaus, kuris nemiega, nevalgo, nerūko ir neserga, o visą parą stebi saugojimo sistemos būklę, tai nėra galimybės garantuoti, kad administratorius gedimo metu galima rankiniu būdu perjungti.
Atitinkamai, RTO, nesant metroklasterio ar nemirtingojo administratoriaus pareigų 99 lygio administratoriaus, bus lygus visų sistemų perjungimo laiko sumai ir maksimaliam laikotarpiui, po kurio administratoriui garantuojama, kad jis pradės dirbti. su saugojimo sistemomis ir susijusiomis sistemomis.
Taigi darome akivaizdžią išvadą, kad metroklasteris turėtų būti naudojamas, jei RTO reikalavimas yra minutės, o ne valandos ar dienos, tai yra, kai blogiausio duomenų centro gedimo atveju IT skyrius turi suteikti verslui laiko. atkurti prieigą prie IT paslaugų per kelias minutes ar net sekundes.
Kaip tai veikia?
Žemesniame lygyje metroklasteris naudoja sinchroninio duomenų replikavimo mechanizmą, kurį aprašėme ankstesniame straipsnyje (žr. ). Kadangi replikacija yra sinchroninė, jai keliami reikalavimai yra atitinkami, tiksliau:
- optinis pluoštas kaip fizinis, 10 gigabitų eternetas (arba didesnis);
- atstumas tarp duomenų centrų yra ne didesnis kaip 40 kilometrų;
- optinio kanalo delsa tarp duomenų centrų (tarp saugojimo sistemų) yra iki 5 milisekundžių (optimaliai 2).
Visi šie reikalavimai yra patariamojo pobūdžio, tai yra, metroklasteris veiks, net jei šie reikalavimai nebus įvykdyti, tačiau turime suprasti, kad šių reikalavimų nesilaikymo pasekmės prilygsta abiejų saugojimo sistemų veikimo sulėtėjimui. metroklasteris.
Taigi, sinchroninė kopija naudojama duomenims perduoti tarp saugojimo sistemų ir kaip replikos automatiškai persijungia ir, svarbiausia, kaip išvengti smegenų padalijimo? Norėdami tai padaryti, aukštesniame lygyje naudojamas papildomas subjektas - arbitras.
Kaip dirba arbitras ir kokia jo užduotis?
Arbitras yra maža virtuali mašina arba aparatinės įrangos klasteris, kuris turi būti paleistas trečioje svetainėje (pavyzdžiui, biure) ir suteikia prieigą prie saugojimo sistemos per ICMP ir SSH. Po paleidimo arbitras turėtų nustatyti IP, o tada iš saugyklos pusės nurodyti savo adresą, taip pat nuotolinio valdymo pultelių, dalyvaujančių metroklasteryje, adresus. Po to teisėjas yra pasirengęs dirbti.
Arbitras nuolat stebi visas saugojimo sistemas metroklasteryje ir, jei tam tikra saugojimo sistema nepasiekiama, patvirtinęs nepasiekiamumą kitam klasterio nariui (vienai iš „gyvų“ saugojimo sistemų), nusprendžia pradėti replikacijos taisyklių perjungimo procedūrą. ir kartografavimas.
Labai svarbus momentas. Arbitras visada turi būti kitoje vietoje nei tos, kuriose yra saugojimo sistemos, tai yra nei 1 duomenų centre, kur yra įdiegta 1 saugojimo sistema, nei 2 duomenų centre, kur įrengta 2 saugojimo sistema.
Kodėl? Nes tik taip arbitras, pasitelkęs vieną iš išlikusių saugojimo sistemų, gali vienareikšmiškai ir tiksliai nustatyti bet kurios iš dviejų vietų, kuriose įrengtos saugojimo sistemos, kritimą. Bet kokie kiti arbitro paskyrimo būdai gali sukelti smegenų padalijimą.
Dabar pasinerkime į arbitro darbo detales.
Arbitras vykdo keletą paslaugų, kurios nuolat apklausia visus saugojimo valdiklius. Jei apklausos rezultatas skiriasi nuo ankstesnio (prieinamas/nepasiekiamas), tada jis įrašomas į mažą duomenų bazę, kuri taip pat veikia ir arbitre.
Pažvelkime į arbitro darbo logiką plačiau.
1 veiksmas: nustatykite nepasiekiamumą. Saugojimo sistemos gedimo įvykis – tai tos pačios saugojimo sistemos abiejų valdiklių ping nebuvimas per 5 sekundes.
2 veiksmas. Pradėkite perjungimo procedūrą. Sužinojęs, kad viena iš saugojimo sistemų nepasiekiama, arbitras siunčia užklausą „gyvai“ saugojimo sistemai, kad įsitikintų, jog „negyva“ saugojimo sistema tikrai neveikia.
Gavusi tokią komandą iš arbitro, antroji (gyva) saugojimo sistema papildomai patikrina, ar yra nukritusi pirmoji saugojimo sistema, o jei jos nėra, arbitrui išsiunčia patvirtinimą apie jo spėjimą. Saugojimo sistema iš tikrųjų nepasiekiama.
Gavęs tokį patvirtinimą, arbitras pradeda nuotolinę procedūrą, skirtą replikacijos perjungimui ir atvaizdavimui tose kopijose, kurios buvo aktyvios (pirminės) nukritusioje saugojimo sistemoje, ir siunčia komandą antrajai saugojimo sistemai pakeisti šias kopijas iš antrinės į pirminę ir pakelti kartografavimą. Na, o antroji saugojimo sistema atitinkamai atlieka šias procedūras ir suteikia prieigą prie prarastų LUN iš savęs.
Kodėl reikalingas papildomas patikrinimas? Dėl kvorumo. Tai reiškia, kad dauguma nelyginio (3) klasterio narių skaičiaus turi patvirtinti vieno iš klasterio mazgų kritimą. Tik tada šis sprendimas bus tikrai teisingas. Tai būtina siekiant išvengti klaidingo perjungimo ir, atitinkamai, smegenų suskaidymo.
2 laiko veiksmas trunka maždaug 5 - 10 sekundžių, taigi, atsižvelgiant į laiką, reikalingą nepasiekiamumui nustatyti (5 sekundės), per 10 - 15 sekundžių po avarijos LUN iš nukritusios saugojimo sistemos bus automatiškai prieinami darbui su gyvuoju. saugojimo sistema.
Akivaizdu, kad norint neprarasti ryšių su pagrindiniais kompiuteriais, taip pat turite pasirūpinti, kad būtų tinkamai sukonfigūruoti skirtojo laiko tarpai. Rekomenduojamas laikas yra mažiausiai 30 sekundžių. Tai neleis pagrindiniam kompiuteriui nutraukti ryšio su saugojimo sistema perjungiant apkrovą nelaimės atveju ir gali užtikrinti, kad nebus įvesties / išvesties pertrūkių.
Palaukite sekundę, paaiškėja, kad jei su metroklasteriu viskas taip gerai, kodėl mums apskritai reikia reguliaraus replikavimo?
Iš tikrųjų viskas nėra taip paprasta.
Panagrinėkime metroklasterio privalumus ir trūkumus
Taigi, mes supratome, kad akivaizdūs metroklasterio pranašumai, palyginti su įprastu replikavimu, yra šie:
- Pilna automatika, užtikrinanti minimalų atsigavimo laiką nelaimės atveju;
- Tai viskas :-).
O dabar, dėmesio, minusai:
- Sprendimo kaina. Nors metroklasteris Aerodisk sistemose nereikalauja papildomų licencijų (naudojama ta pati licencija kaip ir kopijai), sprendimo kaina vis tiek bus dar didesnė nei naudojant sinchroninį replikavimą. Turėsite įgyvendinti visus sinchroninės kopijos reikalavimus, taip pat reikalavimus metroklasteriui, susijusiam su papildomu perjungimu ir papildoma svetaine (žr. metroklasterio planavimą);
- Sprendimo sudėtingumas. Metroklasteris yra daug sudėtingesnis nei įprasta kopija, todėl planuojant, konfigūruojant ir dokumentuojant reikia skirti daug daugiau dėmesio ir pastangų.
Galų gale. Metrocluster tikrai yra labai technologiškai pažangus ir geras sprendimas, kai jums tikrai reikia pateikti RTO per kelias sekundes ar minutes. Bet jei tokios užduoties nėra, o RTO valandomis tinka verslui, tada nėra prasmės šaudyti į žvirblius iš patrankos. Pakanka įprasto darbininko ir valstiečio replikacijos, nes metro klasteris sukels papildomų išlaidų ir komplikuotų IT infrastruktūrą.
Metroklasterių planavimas
Šis skyrius nepretenduoja į išsamų metroklasterių projektavimo vadovą, o tik parodo pagrindines kryptis, kurias reikėtų parengti, jei nuspręsite sukurti tokią sistemą. Todėl realiai diegdami metroklasterį, būtinai į konsultacijas įtraukite saugojimo sistemos gamintoją (tai yra mus) ir kitas susijusias sistemas.
Vietos
Kaip minėta pirmiau, metroklasteriui reikia mažiausiai trijų svetainių. Du duomenų centrai, kuriuose veiks saugojimo sistemos ir susijusios sistemos, taip pat trečia vieta, kurioje dirbs arbitras.
Rekomenduojamas atstumas tarp duomenų centrų yra ne didesnis kaip 40 kilometrų. Didesnis atstumas gali sukelti papildomų vėlavimų, o tai labai nepageidautina metroklasterio atveju. Priminsime, kad vėlavimai turėtų būti iki 5 milisekundžių, nors patartina juos laikyti 2 milisekundėmis.
Taip pat planavimo proceso metu rekomenduojama patikrinti vėlavimus. Bet kuris daugiau ar mažiau subrendęs tiekėjas, teikiantis optinį pluoštą tarp duomenų centrų, gali gana greitai organizuoti kokybės patikrinimą.
Kalbant apie vėlavimus prieš arbitrą (ty tarp trečiosios svetainės ir pirmųjų dviejų), rekomenduojama vėlavimo riba yra iki 200 milisekundžių, tai yra, tinka įprastas įmonės VPN ryšys internetu.
Perjungimas ir tinklų kūrimas
Skirtingai nuo replikacijos schemos, kai pakanka prijungti saugojimo sistemas iš skirtingų vietų, metroklasterio schemoje reikia prijungti pagrindinius kompiuterius su abiem saugojimo sistemomis skirtingose vietose. Kad būtų aiškiau, kuo skiriasi, toliau pateiktos abi schemos.
Kaip matyti iš diagramos, mūsų svetainės 1 prieglobos žiūri ir į 1 saugojimo sistemą, ir į 2 saugojimo sistemą. Be to, priešingai, 2 svetainės prieglobos žiūri ir į 2 saugojimo sistemą, ir į 1 saugojimo sistemą. Tai reiškia, kad kiekvienas pagrindinis kompiuteris mato abi saugojimo sistemas. Tai būtina metroklasterio veikimo sąlyga.
Žinoma, nebūtina kiekvieno kompiuterio optiniu laidu jungti prie kito duomenų centro, neužteks jokių prievadų ar laidų. Visi šie ryšiai turi būti atliekami per Ethernet 10G+ arba FibreChannel 8G+ jungiklius (FC skirtas tik IO prieglobos ir saugojimo sistemų prijungimui, replikacijos kanalas šiuo metu pasiekiamas tik per IP (Ethernet 10G+).
Dabar keli žodžiai apie tinklo topologiją. Svarbus dalykas yra teisinga potinklių konfigūracija. Būtina nedelsiant apibrėžti kelis potinklius šiems srauto tipams:
- Replikacijos potinklis, per kurį duomenys bus sinchronizuojami tarp saugojimo sistemų. Jų gali būti keletas, šiuo atveju tai nesvarbu, viskas priklauso nuo esamos (jau įdiegtos) tinklo topologijos. Jei jų yra du, akivaizdu, kad tarp jų turi būti sukonfigūruotas maršrutas;
- Saugyklos potinkliai, per kuriuos prieglobos prieiga prie saugyklos išteklių (jei tai iSCSI). Kiekviename duomenų centre turėtų būti vienas toks potinklis;
- Valdykite potinklius, ty tris nukreipiamus potinklius trijose svetainėse, iš kurių valdomos saugojimo sistemos, ir ten taip pat yra arbitras.
Čia neatsižvelgiame į potinklius, kad būtų galima pasiekti pagrindinio kompiuterio išteklius, nes jie labai priklauso nuo užduočių.
Skirtingo srauto atskyrimas į skirtingus potinklius yra nepaprastai svarbus (ypač svarbu atskirti repliką nuo įvesties/išvesties), nes sumaišius visą srautą į vieną „storą“ potinklį, šio srauto bus neįmanoma valdyti. dviejų duomenų centrų sąlygos vis tiek gali sukelti skirtingas tinklo susidūrimo parinktis. Šiame straipsnyje mes nesigilinsime į šią problemą, nes apie tinklo, ištempto tarp duomenų centrų, planavimą galite perskaityti iš tinklo įrangos gamintojų išteklių, kur tai labai išsamiai aprašyta.
Arbiterio konfigūracija
Arbitras turi suteikti prieigą prie visų saugojimo sistemos valdymo sąsajų per ICMP ir SSH protokolus. Taip pat turėtumėte pagalvoti apie arbitro gedimų saugumą. Čia yra niuansas.
Arbitras yra labai pageidautinas, bet neprivalomas. Kas atsitiks, jei teisėjas atsitrenks netinkamu laiku?
- Metroklasterio veikimas įprastu režimu nepasikeis, nes arbtir visiškai neturi įtakos metroklasterio veikimui įprastu režimu (jo užduotis yra laiku perjungti apkrovą tarp duomenų centrų)
- Be to, jei arbitras dėl vienokių ar kitokių priežasčių nukris ir „užmigs“ avariją duomenų centre, tada joks perjungimas neįvyks, nes nebus kam duoti reikiamų perjungimų komandų ir organizuoti kvorumą. Tokiu atveju metroklasteris pavirs įprasta schema su replikacija, kurią teks rankiniu būdu perjungti nelaimės metu, o tai turės įtakos RTO.
Kas iš to seka? Jei tikrai reikia užtikrinti minimalų RTO, turite užtikrinti, kad arbitras būtų atsparus gedimams. Tam yra dvi parinktys:
- Paleiskite virtualią mašiną su gedimams atsparaus hipervizoriaus arbitru. Laimei, visi suaugusiųjų hipervizoriai palaiko gedimų toleravimą;
- Jei trečioje vietoje (įprastame biure) esate per tingus įdiegti įprastą klasterį ir nėra hipervozorinio klasterio, mes pateikėme aparatinę arbitro versiją, pagamintą 2U dėžutėje, kurioje yra dvi paprastos. x-86 serveriai veikia ir gali išgyventi vietinį gedimą.
Primygtinai rekomenduojame užtikrinti arbitro gedimų toleranciją, nepaisant to, kad įprastu režimu metroklasteriui to nereikia. Tačiau, kaip rodo teorija ir praktika, jei sukuriate tikrai patikimą, nelaimėms atsparią infrastruktūrą, geriau žaiskite saugiai. Geriau apsaugoti save ir savo verslą nuo „niekšybės įstatymo“, tai yra, nuo arbitro ir vienos iš vietų, kuriose yra saugojimo sistema, nesėkmės.
Sprendimo architektūra
Atsižvelgdami į aukščiau pateiktus reikalavimus, gauname tokią bendrą sprendimo architektūrą.
LUN turi būti tolygiai paskirstyti dviejose vietose, kad būtų išvengta didelės perkrovos. Tuo pačiu metu, nustatydami dydį abiejuose duomenų centruose, turėtumėte įtraukti ne tik dvigubą tūrį (kuri būtina norint vienu metu saugoti duomenis dviejose saugojimo sistemose), bet ir dvigubą našumą IOPS ir MB/s, kad būtų išvengta programos pablogėjimo. vieno iš duomenų centrų gedimo atveju.
Atskirai pažymime, kad taikant tinkamą požiūrį į dydžio nustatymą (tai yra su sąlyga, kad pateikėme tinkamas viršutines IOPS ir MB/s ribas, taip pat reikiamus procesoriaus ir RAM išteklius), jei viena iš saugojimo sistemų metro klasteris sugenda, nebus rimto našumo sumažėjimo, kai laikinas darbas vienoje saugojimo sistemoje.
Tai paaiškinama tuo, kad kai vienu metu veikia dvi svetainės, sinchroninis replikavimas „suvalgo“ pusę rašymo našumo, nes kiekviena operacija turi būti įrašyta į dvi saugojimo sistemas (panašiai kaip RAID-1/10). Taigi, sugedus vienai iš saugojimo sistemų, replikacijos įtaka laikinai (kol atsigaus sugedusi saugojimo sistema) išnyksta ir gauname dvigubai padidėjusį rašymo našumą. Iš naujo paleidus sugedusios saugojimo sistemos LUN veikiančioje saugojimo sistemoje, šis dvigubas padidėjimas išnyksta dėl to, kad apkrova atsiranda iš kitos saugojimo sistemos LUN ir grįžtame į tą patį našumo lygį, kokį turėjome prieš „kritimas“, bet tik vienos svetainės ribose.
Kompetentingo dydžio parinkimo pagalba galite užtikrinti sąlygas, kuriomis vartotojai visiškai nepajus visos saugojimo sistemos gedimo. Bet dar kartą kartojame, tai reikalauja labai kruopštaus dydžio nustatymo, dėl kurio, beje, galite susisiekti su mumis nemokamai :-).
Metroklasterio nustatymas
Metroklasterio nustatymas yra labai panašus į įprastos replikacijos nustatymą, kurį aprašėme . Todėl sutelkime dėmesį tik į skirtumus. Laboratorijoje pastatėme stendą pagal aukščiau pateiktą architektūrą, tik minimalioje versijoje: dvi saugojimo sistemos, sujungtos per 10G Ethernet, du 10G komutatoriai ir vienas hostas, kuris žiūri per jungiklius abiejose saugojimo sistemose su 10G prievadais. Arbitras veikia virtualioje mašinoje.
Konfigūruodami virtualius IP (VIP) replikai, turėtumėte pasirinkti VIP tipą - metroklasteriui.
Sukūrėme dvi replikacijos nuorodas dviem LUN ir paskirstėme jas dviejose saugojimo sistemose: LUN TEST pirminis 1 saugojimo sistemoje (METRO nuoroda), LUN TEST2 pagrindinis, skirtas 2 saugojimo sistemai (METRO2 nuoroda).
Jiems sukonfigūravome du identiškus tikslus (mūsų atveju iSCSI, bet palaikomas ir FC, sąrankos logika ta pati).
1 saugojimo sistema:
2 saugojimo sistema:
Replikacijos ryšiams kiekvienoje saugojimo sistemoje buvo sudaryti atvaizdai.
1 saugojimo sistema:
2 saugojimo sistema:
Mes nustatėme daugialypį kelią ir pristatėme jį šeimininkui.
Arbitražo sudarymas
Jums nereikia nieko ypatingo daryti su pačiu arbitru; tereikia jį įjungti trečioje svetainėje, suteikti jai IP ir sukonfigūruoti prieigą prie jo per ICMP ir SSH. Pati sąranka atliekama iš pačių saugojimo sistemų. Tokiu atveju pakanka vieną kartą sukonfigūruoti arbitrą bet kuriame metroklasterio saugyklos valdiklyje; šie nustatymai bus automatiškai paskirstyti visiems valdikliams.
Skiltyje Nuotolinis replikavimas>> Metrocluster (bet kuriame valdiklyje)>> mygtuką "Konfigūruoti".
Įvedame arbitro IP, taip pat dviejų nuotolinių saugojimo valdiklių valdymo sąsajas.
Po to turite įjungti visas paslaugas (mygtukas „Paleisti viską iš naujo“). Jei ateityje bus sukonfigūruotas iš naujo, paslaugos turi būti paleistos iš naujo, kad nustatymai įsigaliotų.
Tikriname, ar veikia visos paslaugos.
Tai užbaigia metroklasterio sąranką.
Avarijos testas
Avarijos testas mūsų atveju bus gana paprastas ir greitas, nes replikacijos funkcionalumas (perjungimas, nuoseklumas ir kt.) buvo aptartas m. . Todėl, norint patikrinti metroklasterio patikimumą, mums pakanka patikrinti gedimų aptikimo, perjungimo automatizavimą ir įrašymo nuostolių (I/O stotelių) nebuvimą.
Norėdami tai padaryti, imituojame visišką vienos iš saugojimo sistemų gedimą, fiziškai išjungiame abu jos valdiklius, prieš tai pradėję kopijuoti didelį failą į LUN, kurį reikia suaktyvinti kitoje saugojimo sistemoje.
Išjungti vieną saugojimo sistemą. Antroje saugojimo sistemoje matome perspėjimus ir pranešimus žurnaluose, kad nutrūko ryšys su kaimynine sistema. Jei sukonfigūruoti pranešimai per SMTP arba SNMP stebėjimą, administratorius gaus atitinkamus pranešimus.
Lygiai po 10 sekundžių (matoma abiejose ekrano kopijose) METRO replikacijos ryšys (tas, kuris buvo pagrindinis sugedusioje saugojimo sistemoje) automatiškai tapo pagrindiniu veikiančioje saugojimo sistemoje. Naudojant esamą atvaizdavimą, LUN TEST liko prieinamas šeimininkui, įrašymas šiek tiek nukrito (per žadėtus 10 proc.), bet nenutrūko.
Bandymas sėkmingai baigtas.
Apibendrinant
Šiuo metu AERODISK Engine N serijos saugojimo sistemose įdiegtas metroklasteris visiškai leidžia išspręsti problemas, kai reikia pašalinti arba sumažinti IT paslaugų prastovas ir užtikrinti jų darbą 24/7/365 su minimaliomis darbo sąnaudomis.
Galima sakyti, žinoma, kad visa tai yra teorija, idealios laboratorinės sąlygos ir taip toliau... BET turime nemažai įgyvendintų projektų, kuriuose įdiegėme atsparumo nelaimėms funkcionalumą, o sistemos veikia puikiai. Vienas iš mūsų gana žinomų klientų, kurie naudoja vos dvi saugojimo sistemas nelaimėms atsparioje konfigūracijoje, jau sutiko skelbti informaciją apie projektą, tad kitoje dalyje kalbėsime apie kovinį įgyvendinimą.
Ačiū, laukiame produktyvios diskusijos.
Šaltinis: www.habr.com