ProHoster > Blogs > Administrācija > AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

Sveiki, Habr lasÄ«tāji! Pēdējā rakstā mēs runājām par vienkārÅ”u lÄ«dzekli avārijas seku novērÅ”anai AERODISK ENGINE uzglabāŔanas sistēmās - replikāciju. Å ajā rakstā mēs iedziļināsimies sarežģītākā un interesantākā tēmā - metroklasterā, tas ir, divu datu centru automatizētā katastrofu aizsardzÄ«bas lÄ«dzeklÄ«, kas ļauj datu centriem darboties aktÄ«vā-aktÄ«vā režīmā. Mēs jums pateiksim, parādÄ«sim, salauzÄ«sim un salabosim.

Kā parasti, vispirms teorija

Metroklasteris ir klasteris, kas izvietots vairākās vietās pilsētas vai reÄ£iona ietvaros. Vārds ā€œklasterisā€ mums skaidri norāda, ka komplekss ir automatizēts, tas ir, klastera mezglu pārslēgÅ”ana kļūmju gadÄ«jumā notiek automātiski.

Å eit ir galvenā atŔķirÄ«ba starp metroklasteri un parasto replikāciju. Operāciju automatizācija. Tas ir, noteiktu incidentu gadÄ«jumā (datu centra atteice, bojāti kanāli utt.), uzglabāŔanas sistēma patstāvÄ«gi veiks nepiecieÅ”amās darbÄ«bas, lai saglabātu datu pieejamÄ«bu. Izmantojot parastās kopijas, administrators Ŕīs darbÄ«bas pilnÄ«bā vai daļēji veic manuāli.

Ko tas dara?

Galvenais mērÄ·is, ko klienti cenÅ”as sasniegt, izmantojot noteiktas metroklasteru ievieÅ”anas iespējas, ir samazināt RTO (atkopÅ”anas laika mērÄ·i). Tas ir, lai samazinātu IT pakalpojumu atkopÅ”anas laiku pēc neveiksmes. Ja izmantojat regulāru replikāciju, atkopÅ”anas laiks vienmēr bÅ«s ilgāks nekā atkopÅ”anas laiks, izmantojot metroklasteri. Kāpēc? Ä»oti vienkārÅ”i. Administratoram ir jāatrodas pie sava galda un jāpārslēdz replikācija manuāli, un metroklasteris to dara automātiski.

Ja jums nav dežurējoÅ”a administratora, kurÅ” neguļ, neēd, nesmēķē vai neslimst un 24 stundas diennaktÄ« uzrauga uzglabāŔanas sistēmas stāvokli, tad nevar garantēt, ka administrators jābÅ«t pieejamai manuālai pārslēgÅ”anai kļūmes laikā.

AttiecÄ«gi RTO, ja nav metroklastera vai nemirstÄ«gā administratora dežūrpakalpojuma 99. lÄ«meņa administratora, bÅ«s vienāds ar visu sistēmu pārslēgÅ”anās laiku un maksimālo laika periodu, pēc kura administratoram tiek garantēta darba uzsākÅ”ana. ar uzglabāŔanas sistēmām un saistÄ«tām sistēmām.

Tādējādi mēs nonākam pie acÄ«mredzama secinājuma, ka metroklasteri vajadzētu izmantot, ja prasÄ«ba RTO ir minÅ«tes, nevis stundas vai dienas, proti, kad vissliktākās datu centra atteices gadÄ«jumā IT nodaļai ir jānodroÅ”ina uzņēmumam laiks. lai atjaunotu piekļuvi IT pakalpojumiem dažu minÅ«Å”u vai pat sekunžu laikā.

Kā tas strādā?

Zemākā lÄ«menÄ« metroklasteris izmanto sinhronas datu replikācijas mehānismu, ko mēs aprakstÄ«jām iepriekŔējā rakstā (sk. saite). Tā kā replikācija ir sinhrona, prasÄ«bas tai ir atbilstoÅ”as ā€‹ā€‹vai drÄ«zāk:

  • optiskā Ŕķiedra kā fizika, 10 gigabitu Ethernet (vai lielāks);
  • attālums starp datu centriem nav lielāks par 40 kilometriem;
  • optiskā kanāla aizkave starp datu centriem (starp uzglabāŔanas sistēmām) ir lÄ«dz 5 milisekundēm (optimāli 2).

Visām Ŕīm prasÄ«bām ir ieteikuma raksturs, tas ir, metroklasteris darbosies arÄ« tad, ja Ŕīs prasÄ«bas netiks izpildÄ«tas, taču jāsaprot, ka Å”o prasÄ«bu neievēroÅ”anas sekas ir lÄ«dzvērtÄ«gas abu uzglabāŔanas sistēmu darbÄ«bas palēninājumam. metroklasteris.

Tātad datu pārsÅ«tÄ«Å”anai starp uzglabāŔanas sistēmām tiek izmantota sinhronā kopija, un kā replikas automātiski pārslēdzas un, pats galvenais, kā izvairÄ«ties no smadzeņu sadalÄ«Å”anas? Lai to izdarÄ«tu, augstākā lÄ«menÄ« tiek izmantota papildu vienÄ«ba - Ŕķīrējtiesnesis.

Kā strādā Ŕķīrējtiesnesis un kāds ir viņa uzdevums?

Å Ä·Ä«rējtiesnesis ir maza virtuālā maŔīna vai aparatÅ«ras klasteris, kas jāpalaiž treÅ”ajā vietnē (piemēram, birojā) un nodroÅ”ina piekļuvi krātuves sistēmai, izmantojot ICMP un SSH. Pēc palaiÅ”anas Ŕķīrējtiesnesim jāiestata IP un pēc tam no krātuves puses jānorāda tā adrese, kā arÄ« tālvadÄ«bas pults adreses, kas piedalās metroklasterā. Pēc tam tiesnesis ir gatavs darbam.

Å Ä·Ä«rējtiesnesis pastāvÄ«gi uzrauga visas krātuves sistēmas metroklasterā un, ja konkrēta krātuves sistēma nav pieejama, pēc nepieejamÄ«bas apstiprināŔanas no cita klastera dalÄ«bnieka (vienas no ā€œdzÄ«vajāmā€ krātuves sistēmām), viņŔ nolemj uzsākt replikācijas noteikumu pārslēgÅ”anas procedÅ«ru. un kartÄ“Å”anu.

Ä»oti svarÄ«gs punkts. Å Ä·Ä«rējtiesnesim vienmēr jāatrodas vietā, kas atŔķiras no tām, kur atrodas uzglabāŔanas sistēmas, tas ir, ne 1. datu centrā, kur ir uzstādÄ«ta 1. uzglabāŔanas sistēma, ne 2. datu centrā, kur ir uzstādÄ«ta 2. uzglabāŔanas sistēma.

Kāpēc? Jo tikai tā Ŕķīrējtiesnesis ar vienas no saglabājuŔās uzglabāŔanas sistēmas palÄ«dzÄ«bu var viennozÄ«mÄ«gi un precÄ«zi noteikt jebkuras no divām vietām, kur ir uzstādÄ«tas uzglabāŔanas sistēmas, kritumu. Jebkādas citas ŔķīrējtiesneÅ”a iecelÅ”anas metodes var izraisÄ«t smadzeņu ŔķelÅ”anos.

Tagad iedziļināsimies ŔķīrējtiesneÅ”a darba detaļās.

Å Ä·Ä«rējtiesnesis vada vairākus pakalpojumus, kas pastāvÄ«gi aptaujā visus krātuves kontrolierus. Ja aptaujas rezultāts atŔķiras no iepriekŔējā (pieejams/nav pieejams), tad tas tiek ierakstÄ«ts nelielā datu bāzē, kas darbojas arÄ« uz arbitra.

ApskatÄ«sim ŔķīrējtiesneÅ”a darba loÄ£iku sÄ«kāk.

1. darbÄ«ba: nosakiet nepieejamÄ«bu. Krātuves sistēmas kļūmes notikums ir tas, ka 5 sekunžu laikā netiek veikta ping no vienas un tās paÅ”as sistēmas abiem kontrolleriem.

2. darbÄ«ba. Sāciet pārslēgÅ”anas procedÅ«ru. Pēc tam, kad Ŕķīrējtiesnesis ir sapratis, ka viena no uzglabāŔanas sistēmām nav pieejama, viņŔ nosÅ«ta pieprasÄ«jumu uz ā€œdzÄ«voā€ uzglabāŔanas sistēmu, lai pārliecinātos, ka ā€œmirusÄ«ā€ glabāŔanas sistēma patieŔām ir mirusi.

Pēc Ŕādas ŔķīrējtiesneÅ”a komandas saņemÅ”anas otrā (dzÄ«vā) uzglabāŔanas sistēma papildus pārbauda nokrituŔās pirmās glabāŔanas sistēmas pieejamÄ«bu un, ja tās nav, nosÅ«ta Ŕķīrējtiesnesim apstiprinājumu viņa minējumam. UzglabāŔanas sistēma patieŔām nav pieejama.

Pēc Ŕāda apstiprinājuma saņemÅ”anas Ŕķīrējtiesnesis uzsāk attālo procedÅ«ru, lai pārslēgtu replikāciju un kartÄ“Å”anas palielināŔanu tām replikām, kas bija aktÄ«vas (primārās) krituÅ”ajā krātuves sistēmā, un nosÅ«ta komandu otrajai krātuves sistēmai mainÄ«t Ŕīs kopijas no sekundārās uz primāro un paaugstināt kartÄ“Å”anu. Nu, otrā uzglabāŔanas sistēma attiecÄ«gi veic Ŕīs procedÅ«ras un pēc tam nodroÅ”ina piekļuvi zaudētajiem LUN no sevis.

Kāpēc nepiecieÅ”ama papildu pārbaude? Par kvorumu. Tas nozÄ«mē, ka lielākajai daļai no kopējā nepāra (3) klastera dalÄ«bnieku skaita ir jāapstiprina viena klastera mezgla kriÅ”ana. Tikai tad Å”is lēmums noteikti bÅ«s pareizs. Tas ir nepiecieÅ”ams, lai izvairÄ«tos no kļūdainas pārslēgÅ”anas un attiecÄ«gi smadzeņu sadalÄ«Å”anas.

Laika solis 2 aizņem aptuveni 5 - 10 sekundes, lÄ«dz ar to, ņemot vērā nepieejamÄ«bas noteikÅ”anai nepiecieÅ”amo laiku (5 sekundes), 10 - 15 sekunžu laikā pēc negadÄ«juma, LUN no nokrituŔās uzglabāŔanas sistēmas bÅ«s automātiski pieejami darbam ar strāvu. uzglabāŔanas sistēma.

Ir skaidrs, ka, lai nezaudētu savienojumus ar resursdatoriem, jums ir arÄ« jārÅ«pējas par pareizu taimautu konfigurÄ“Å”anu resursdatoros. Ieteicamais taimauts ir vismaz 30 sekundes. Tas neļaus resursdatoram pārtraukt savienojumu ar uzglabāŔanas sistēmu slodzes pārslēgÅ”anas laikā katastrofas gadÄ«jumā un var nodroÅ”ināt, ka nav I/O pārtraukumu.

Pagaidiet, izrādās, ja ar metroklasteri viss ir tik labi, kāpēc mums vispār ir nepiecieÅ”ama regulāra replikācija?

Patiesībā viss nav tik vienkārŔi.

Apsvērsim metroklastera plusus un mīnusus

Tātad, mēs sapratām, ka metroklastera acÄ«mredzamās priekÅ”rocÄ«bas salÄ«dzinājumā ar parasto replikāciju ir:

  • Pilna automatizācija, nodroÅ”inot minimālu atkopÅ”anas laiku katastrofas gadÄ«jumā;
  • Tas ir viss :-).

Un tagad, uzmanību, mīnusi:

  • Risinājuma izmaksas. Lai gan metroklasterim Aerodisk sistēmās nav nepiecieÅ”ama papildu licencÄ“Å”ana (tiek izmantota tā pati licence kā replikai), risinājuma izmaksas joprojām bÅ«s pat augstākas nekā sinhronās replikācijas izmantoÅ”ana. Jums bÅ«s jāievieÅ” visas prasÄ«bas sinhronajai replikai, kā arÄ« prasÄ«bas metroklasterim, kas saistÄ«ts ar papildu pārslēgÅ”anu un papildu vietni (skatiet metroklasteru plānoÅ”anu);
  • Risinājuma sarežģītÄ«ba. Metroklasteris ir daudz sarežģītāks nekā parasta kopija, un plānoÅ”anai, konfigurÄ“Å”anai un dokumentācijai ir nepiecieÅ”ams daudz vairāk uzmanÄ«bas un pūļu.

Galu galā. Metrocluster noteikti ir ļoti tehnoloÄ£iski progresÄ«vs un labs risinājums, ja jums patieŔām ir jānodroÅ”ina RTO dažu sekunžu vai minÅ«Å”u laikā. Bet, ja tāda uzdevuma nav, un RTO stundās ir OK biznesam, tad nav jēgas Å”aut zvirbuļus no lielgabala. Pietiek ar parasto strādnieku-zemnieku replikāciju, jo metro klasteris radÄ«s papildu izmaksas un sarežģīs IT infrastruktÅ«ru.

Metroklasteru plānoŔana

Å Ä« sadaļa nepretendē uz visaptveroÅ”u ceļvedi metroklasteru projektÄ“Å”anā, bet parāda tikai galvenos virzienus, kas bÅ«tu jāizstrādā, ja nolemjat izveidot Ŕādu sistēmu. Tāpēc, reāli ievieÅ”ot metroklasteri, konsultācijām noteikti iesaistiet uzglabāŔanas sistēmas ražotāju (tas ir, mÅ«s) un citas saistÄ«tās sistēmas.

Platformas

Kā minēts iepriekÅ”, metroklasterim ir nepiecieÅ”amas vismaz trÄ«s vietnes. Divi datu centri, kuros darbosies uzglabāŔanas sistēmas un ar tām saistÄ«tās sistēmas, kā arÄ« treŔā vieta, kur strādās Ŕķīrējtiesnesis.

Ieteicamais attālums starp datu centriem nav lielāks par 40 kilometriem. Lielāks attālums, visticamāk, radīs papildu kavējumus, kas metroklastera gadījumā ir ārkārtīgi nevēlami. Atgādinām, ka aizkavei jābūt līdz 5 milisekundēm, lai gan vēlams tās saglabāt 2 milisekundēs.

Kavējumus ieteicams pārbaudÄ«t arÄ« plānoÅ”anas procesā. JebkurÅ” vairāk vai mazāk nobriedis pakalpojumu sniedzējs, kas nodroÅ”ina optisko Ŕķiedru starp datu centriem, var diezgan ātri organizēt kvalitātes pārbaudi.

Kas attiecas uz kavÄ“Å”anos ŔķīrējtiesneÅ”a priekŔā (tas ir, starp treÅ”o vietni un pirmajām divām), ieteicamais aizkaves slieksnis ir lÄ«dz 200 milisekundēm, tas ir, ir piemērots parasts korporatÄ«vais VPN savienojums, izmantojot internetu.

PārslēgÅ”ana un tÄ«kla izveide

AtŔķirÄ«bā no replikācijas shēmas, kur pietiek ar krātuves sistēmu pieslēgÅ”anu no dažādām vietām, metroklasteru shēmai ir nepiecieÅ”ams savienot saimniekdatorus ar abām krātuves sistēmām dažādās vietās. Lai bÅ«tu skaidrāk, kāda ir atŔķirÄ«ba, abas shēmas ir parādÄ«tas zemāk.

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

Kā redzams diagrammā, mÅ«su vietnes 1 saimnieki aplÅ«ko gan 1., gan 2. krātuves sistēmu. Tāpat, gluži pretēji, 2. vietnes saimniekdatori aplÅ«ko gan 2., gan 1. krātuves sistēmu. Tas nozÄ«mē, ka katrs saimniekdators redz abas uzglabāŔanas sistēmas. Tas ir priekÅ”noteikums metroklastera darbÄ«bai.

Protams, nav nepiecieÅ”ams savienot katru saimniekdatoru ar optisko vadu ar citu datu centru, nepietiks ar pieslēgvietām vai vadiem. Visi Å”ie savienojumi ir jāizveido, izmantojot Ethernet 10G+ vai FibreChannel 8G+ slēdžus (FC ir paredzēts tikai resursdatoru un uzglabāŔanas sistēmu savienoÅ”anai IO, replikācijas kanāls paÅ”laik ir pieejams tikai caur IP (Ethernet 10G+).

Tagad daži vārdi par tÄ«kla topoloÄ£iju. SvarÄ«gs punkts ir pareiza apakÅ”tÄ«klu konfigurācija. Ir nepiecieÅ”ams nekavējoties definēt vairākus apakÅ”tÄ«klus Ŕādiem trafika veidiem:

  • Replikācijas apakÅ”tÄ«kls, kurā dati tiks sinhronizēti starp krātuves sistēmām. Tie var bÅ«t vairāki, Å”ajā gadÄ«jumā tas nav svarÄ«gi, viss ir atkarÄ«gs no paÅ”reizējās (jau ieviestās) tÄ«kla topoloÄ£ijas. Ja tie ir divi, tad acÄ«mredzot starp tiem ir jākonfigurē marÅ”rutÄ“Å”ana;
  • Krātuves apakÅ”tÄ«kli, caur kuriem resursdatori piekļūs krātuves resursiem (ja tas ir iSCSI). Katrā datu centrā jābÅ«t vienam Ŕādam apakÅ”tÄ«klam;
  • Kontrolējiet apakÅ”tÄ«klus, tas ir, trÄ«s marÅ”rutējamus apakÅ”tÄ«klus trÄ«s vietnēs, no kurām tiek pārvaldÄ«tas krātuves sistēmas, un tur atrodas arÄ« arbitrs.

Å eit mēs neņemam vērā apakÅ”tÄ«klus, lai piekļūtu resursdatora resursiem, jo ā€‹ā€‹tie ir ļoti atkarÄ«gi no uzdevumiem.

Dažādas trafika sadalÄ«Å”ana dažādos apakÅ”tÄ«klos ir ārkārtÄ«gi svarÄ«ga (Ä«paÅ”i svarÄ«gi ir atdalÄ«t reprodukciju no I/O), jo, ja visu trafiku sajaucat vienā ā€œbiezāā€ apakÅ”tÄ«klā, tad Å”o trafiku nebÅ«s iespējams pārvaldÄ«t. divu datu centru apstākļos tas joprojām var izraisÄ«t dažādas tÄ«kla sadursmes iespējas. Å ajā rakstā mēs neiedziļināsimies Å”ajā jautājumā, jo par tÄ«kla plānoÅ”anu, kas izstiepts starp datu centriem, varat lasÄ«t par tÄ«kla iekārtu ražotāju resursiem, kur tas ir ļoti detalizēti aprakstÄ«ts.

Å Ä·Ä«rējtiesneÅ”a konfigurācija

Å Ä·Ä«rējtiesnesim ir jānodroÅ”ina piekļuve visām uzglabāŔanas sistēmas pārvaldÄ«bas saskarnēm, izmantojot ICMP un SSH protokolus. Jums vajadzētu arÄ« padomāt par ŔķīrējtiesneÅ”a atteices droŔību. Å eit ir kāda nianse.

Arbitera kļūmjpārlēce ir ļoti vēlama, bet nav obligāta. Kas notiek, ja tiesnesis avarēs nepareizā laikā?

  • Metroklastera darbÄ«ba parastajā režīmā nemainÄ«sies, jo arbtir absolÅ«ti nekādi neietekmē metroklastera darbÄ«bu normālā režīmā (tā uzdevums ir savlaicÄ«gi pārslēgt slodzi starp datu centriem)
  • Turklāt, ja Ŕķīrējtiesnesis viena vai otra iemesla dēļ iekrÄ«t un ā€œizguļā€ avāriju datu centrā, tad nekāda pārslēgÅ”anās nenotiks, jo nebÅ«s kam dot nepiecieÅ”amās pārslēgÅ”anas komandas un organizēt kvorumu. Å ajā gadÄ«jumā metroklasteris pārvērtÄ«sies par parastu shēmu ar replikāciju, kas katastrofas laikā bÅ«s jāpārslēdz manuāli, kas ietekmēs RTO.

Kas no tā izriet? Ja jums patieŔām ir jānodroÅ”ina minimālais RTO, jums ir jānodroÅ”ina, lai Ŕķīrējtiesnesis bÅ«tu izturÄ«gs pret kļūmēm. Tam ir divas iespējas:

  • Palaidiet virtuālo maŔīnu ar kļūdu izturÄ«gā hipervizora Ŕķīrējtiesnesi. Par laimi visi pieauguÅ”ie hipervizori atbalsta kļūdu toleranci;
  • Ja treÅ”ajā vietā (parastā birojā) esat pārāk slinks, lai uzstādÄ«tu parasto klasteru un nav esoÅ”a hipervozoru klastera, tad mēs esam nodroÅ”inājuÅ”i arbitra aparatÅ«ras versiju, kas ir izgatavota 2U kastē, kurā divas parastās x-86 serveri darbojas un var pārdzÄ«vot lokālu atteici.

Mēs stingri iesakām nodroÅ”ināt ŔķīrējtiesneÅ”a kļūdu toleranci, neskatoties uz to, ka metroklasterim tas nav vajadzÄ«gs parastajā režīmā. Bet, kā rāda gan teorija, gan prakse, ja jÅ«s izveidojat patiesi uzticamu, katastrofu droÅ”u infrastruktÅ«ru, tad labāk ir rÄ«koties droÅ”i. Labāk ir pasargāt sevi un savu biznesu no ā€œnelikumÄ«bas likumaā€, tas ir, no ŔķīrējtiesneÅ”a un vienas no vietām, kur atrodas uzglabāŔanas sistēma, neveiksmes.

Risinājuma arhitektūra

Ņemot vērā iepriekÅ” minētās prasÄ«bas, mēs iegÅ«stam Ŕādu vispārÄ«gu risinājuma arhitektÅ«ru.

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

LUN vienmērÄ«gi jāsadala divās vietās, lai izvairÄ«tos no nopietnas pārslodzes. Tajā paŔā laikā, nosakot izmērus abos datu centros, ir jāiekļauj ne tikai dubults apjoms (kas nepiecieÅ”ams, lai datus vienlaikus uzglabātu divās uzglabāŔanas sistēmās), bet arÄ« dubultā veiktspēja IOPS un MB/s, lai novērstu lietojumprogrammu degradāciju. viena datu centra atteices gadÄ«jumā ov.

AtseviŔķi mēs atzÄ«mējam, ka ar pareizu pieeju izmēru noteikÅ”anai (tas ir, ja esam nodroÅ”inājuÅ”i pareizus IOPS un MB/s augŔējos ierobežojumus, kā arÄ« nepiecieÅ”amos CPU un RAM resursus), ja kāda no uzglabāŔanas sistēmām metro klasteris neizdodas, nebÅ«s nopietns veiktspējas kritums apstākļos pagaidu darbs pie vienas uzglabāŔanas sistēmas.

Tas izskaidrojams ar to, ka, vienlaikus darbojoties divām vietnēm, sinhronā replikācija ā€œapēdā€ pusi no rakstÄ«Å”anas veiktspējas, jo katra transakcija ir jāieraksta divās uzglabāŔanas sistēmās (lÄ«dzÄ«gi kā RAID-1/10). Tātad, ja kāda no uzglabāŔanas sistēmām neizdodas, replikācijas ietekme uz laiku (lÄ«dz atkopjas neveiksmÄ«gā krātuves sistēma) pazÅ«d, un mēs iegÅ«stam divkārÅ”u rakstÄ«Å”anas veiktspējas pieaugumu. Pēc neveiksmÄ«gās krātuves sistēmas LUN restartÄ“Å”anas darba krātuves sistēmā Å”is divkārÅ”ais pieaugums pazÅ«d, jo tiek parādÄ«ta slodze no otras krātuves sistēmas LUN, un mēs atgriežamies pie tā paÅ”a veiktspējas lÄ«meņa, kāds bija pirms ā€œkritumsā€, bet tikai vienas vietnes ietvaros.

Izmantojot kompetentu izmēru noteikÅ”anu, jÅ«s varat nodroÅ”ināt apstākļus, kādos lietotāji nemaz nejutÄ«s visas uzglabāŔanas sistēmas kļūmi. Bet mēs atkārtojam vēlreiz, tas prasa ļoti rÅ«pÄ«gu izmēru noteikÅ”anu, par ko, starp citu, varat sazināties ar mums bez maksas :-).

Metroklastera iestatīŔana

Metroklastera iestatÄ«Å”ana ir ļoti lÄ«dzÄ«ga regulāras replikācijas iestatÄ«Å”anai, ko mēs aprakstÄ«jām iepriekŔējais raksts. Tāpēc pievērsÄ«simies tikai atŔķirÄ«bām. Mēs laboratorijā uzstādÄ«jām stendu, pamatojoties uz iepriekÅ” minēto arhitektÅ«ru, tikai minimālā versijā: divas uzglabāŔanas sistēmas, kas savienotas, izmantojot 10G Ethernet, divi 10G slēdži un viens resursdators, kas skatās caur slēdžiem abās uzglabāŔanas sistēmās ar 10G pieslēgvietām. Å Ä·Ä«rējtiesnesis darbojas virtuālajā maŔīnā.

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

Konfigurējot virtuālos IP (VIP) reprodukcijai, jums vajadzētu izvēlēties VIP veidu - metroklasterim.

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

Mēs izveidojām divas replikācijas saites diviem LUN un izplatÄ«jām tās divās uzglabāŔanas sistēmās: LUN TEST primārais 1. krātuves sistēmā (METRO saite), LUN TEST2 primārais 2. krātuves sistēmai (METRO2 saite).

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

Viņiem mēs konfigurējām divus identiskus mērÄ·us (mÅ«su gadÄ«jumā iSCSI, bet tiek atbalstÄ«ts arÄ« FC, iestatÄ«Å”anas loÄ£ika ir tāda pati).

UzglabāŔanas sistēma1:

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

UzglabāŔanas sistēma2:

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

Replikācijas savienojumiem kartējumi tika veikti katrā uzglabāŔanas sistēmā.

UzglabāŔanas sistēma1:

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

UzglabāŔanas sistēma2:

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

Mēs uzstādījām daudzceļus un prezentējām to saimniekam.

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

Å Ä·Ä«rējtiesneÅ”a izveidoÅ”ana

Ar paÅ”u Ŕķīrējtiesnesi jums nav jādara nekas Ä«paÅ”s; jums tas vienkārÅ”i jāiespējo treÅ”ajā vietnē, jāpieŔķir tai IP un jākonfigurē piekļuve, izmantojot ICMP un SSH. Pati iestatÄ«Å”ana tiek veikta no paŔām uzglabāŔanas sistēmām. Å ajā gadÄ«jumā pietiek vienreiz konfigurēt arbitru jebkurā no krātuves kontrolleriem metroklasterā; Å”ie iestatÄ«jumi tiks automātiski izplatÄ«ti visiem kontrolieriem.

Sadaļā Attālā replikācija>> Metrocluster (uz jebkura kontrollera)>> pogu ā€œKonfigurētā€.

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

Mēs ievadām ŔķīrējtiesneÅ”a IP, kā arÄ« divu attālās atmiņas kontrolieru vadÄ«bas saskarnes.

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

Pēc tam jums ir jāiespējo visi pakalpojumi (poga ā€œRestartēt visuā€). Ja pakalpojumi tiks atkārtoti konfigurēti nākotnē, tie ir jārestartē, lai iestatÄ«jumi stātos spēkā.

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

Mēs pārbaudām, vai visi pakalpojumi darbojas.

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

Tas pabeidz metroklastera iestatīŔanu.

Avārijas tests

Avārijas tests mÅ«su gadÄ«jumā bÅ«s diezgan vienkārÅ”s un ātrs, jo replikācijas funkcionalitāte (pārslēgÅ”ana, konsekvence utt.) tika apspriesta pēdējais raksts. Tāpēc, lai pārbaudÄ«tu metroklastera uzticamÄ«bu, mums pietiek pārbaudÄ«t kļūmju noteikÅ”anas automatizāciju, pārslēgÅ”anu un ierakstÄ«Å”anas zudumu neesamÄ«bu (I/O pieturas).

Lai to izdarītu, mēs atdarinām pilnīgu vienas krātuves sistēmas kļūmi, fiziski izslēdzot abus tās kontrollerus, vispirms sākot kopēt lielu failu uz LUN, kas jāaktivizē otrā krātuves sistēmā.

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

Atspējot vienu uzglabāŔanas sistēmu. Otrajā krātuves sistēmā mēs redzam brÄ«dinājumus un ziņojumus žurnālos, ka savienojums ar blakus esoÅ”o sistēmu ir zudis. Ja ir konfigurēti paziņojumi, izmantojot SMTP vai SNMP uzraudzÄ«bu, administrators saņems atbilstoÅ”us paziņojumus.

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

TieÅ”i pēc 10 sekundēm (redzams abos ekrānuzņēmumos) METRO replikācijas savienojums (tas, kas bija primārais atteices krātuves sistēmā) automātiski kļuva par primāro darboÅ”ajā krātuves sistēmā. Izmantojot esoÅ”o kartÄ“Å”anu, LUN TEST palika pieejams saimniekam, ieraksts nedaudz pasliktinājās (solÄ«to 10 procentu robežās), bet netika pārtraukts.

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

AERODISK dzinējs: izturība pret katastrofām. 2. daļa. Metroklasteris

Pārbaude veiksmīgi pabeigta.

Apkopojot

PaÅ”reizējā metroklastera ievieÅ”ana AERODISK Engine N-sērijas uzglabāŔanas sistēmās pilnÄ«bā ļauj atrisināt problēmas, kurās nepiecieÅ”ams novērst vai minimizēt IT pakalpojumu dÄ«kstāves un nodroÅ”ināt to darbÄ«bu 24/7/365 ar minimālām darbaspēka izmaksām.

Var, protams, teikt, ka tas viss ir teorija, ideāli laboratorijas apstākļi un tā tālāk... BET mums ir vairāki realizēti projekti, kuros esam ieviesuÅ”i katastrofu noturÄ«bas funkcionalitāti, un sistēmas strādā perfekti. Viens no mÅ«su diezgan pazÄ«stamajiem klientiem, kurÅ” izmanto tikai divas glabāŔanas sistēmas katastrofu droŔā konfigurācijā, jau ir piekritis publicēt informāciju par projektu, tāpēc nākamajā daļā runāsim par kaujas ievieÅ”anu.

Paldies, ceram uz produktīvu diskusiju.

Avots: www.habr.com

Pievieno komentāru