Sveiki, Habr skaitytojai! Šio straipsnio tema bus atkūrimo įrankių diegimas AERODISK Engine saugojimo sistemose. Iš pradžių norėjome viename straipsnyje parašyti apie abu įrankius: replikaciją ir metrocluster, bet, deja, straipsnis pasirodė per ilgas, todėl straipsnį padalinome į dvi dalis. Pereikime nuo paprasto prie sudėtingo. Šiame straipsnyje nustatysime ir išbandysime sinchroninį replikavimą – atsisakysime vieno duomenų centro, taip pat nutrauksime ryšio kanalą tarp duomenų centrų ir pažiūrėsime, kas atsitiks.
Mūsų klientai dažnai užduoda mums įvairių klausimų apie replikaciją, todėl prieš pereidami prie kopijų diegimo nustatymo ir testavimo, šiek tiek papasakosime, kas yra replikacija saugykloje.
Teorijos tiek
Replikacija saugojimo sistemose yra nenutrūkstamas procesas, užtikrinantis duomenų tapatybę keliose saugojimo sistemose vienu metu. Techniškai replikacija atliekama dviem būdais.
Sinchroninis replikavimas – tai duomenų kopijavimas iš pagrindinės saugojimo sistemos į atsarginę, o po to privalomas abiejų saugojimo sistemų patvirtinimas, kad duomenys įrašyti ir patvirtinti. Tik po patvirtinimo iš abiejų pusių (abiejų saugojimo sistemų), duomenys laikomi įrašytais ir su jais galima dirbti. Tai užtikrina garantuotą duomenų tapatybę visose saugojimo sistemose, dalyvaujančiose kopijoje.
Šio metodo privalumai:
- Duomenys visose saugojimo sistemose visada yra vienodi
Trūkumai:
- Didelė sprendimo kaina (greiti ryšio kanalai, brangus optinis pluoštas, ilgųjų bangų siųstuvai-imtuvai ir kt.)
- Atstumo apribojimai (kelių dešimčių kilometrų ribose)
- Nėra apsaugos nuo loginių duomenų sugadinimo (jei duomenys sugadinami (tyčia ar netyčia) pagrindinėje saugojimo sistemoje, jie automatiškai ir akimirksniu sugadinami atsarginėje, nes duomenys visada yra identiški (tai paradoksas)
Asinchroninis replikavimas – tai taip pat duomenų kopijavimas iš pagrindinės saugojimo sistemos į atsarginę, bet su tam tikru vėlavimu ir nereikia patvirtinti įrašymo kitoje pusėje. Galite dirbti su duomenimis iškart juos įrašę į pagrindinę saugojimo sistemą, o atsarginėje saugojimo sistemoje duomenys bus pasiekiami po kurio laiko. Duomenų tapatumas šiuo atveju, žinoma, visiškai neužtikrinamas. Duomenys atsarginėje saugojimo sistemoje visada yra šiek tiek „praeityje“.
Asinchroninio replikavimo privalumai:
- Nebrangus sprendimas (bet kokie ryšio kanalai, optika neprivaloma)
- Jokių atstumo apribojimų
- Atsarginėje saugojimo sistemoje duomenys nepablogėja, jei jie yra pažeisti pagrindinėje (bent jau kurį laiką); jei duomenys sugadinami, visada galite sustabdyti repliką, kad išvengtumėte duomenų sugadinimo atsarginėje saugojimo sistemoje.
Trūkumai:
- Duomenys skirtinguose duomenų centruose visada nėra identiški
Taigi, replikacijos režimo pasirinkimas priklauso nuo verslo tikslų. Jei jums labai svarbu, kad atsarginiame duomenų centre būtų lygiai tokie patys duomenys kaip ir pagrindiniame duomenų centre (t. y. verslo reikalavimas RPO = 0), tuomet turėsite išleisti pinigus ir susitaikyti su sinchroninio ryšio apribojimais. replika. Ir jei duomenų būsenos vėlavimas yra priimtinas arba tiesiog nėra pinigų, būtinai turite naudoti asinchroninį metodą.
Taip pat atskirai pabrėžkime tokį režimą (tiksliau topologiją) kaip metroklasteris. Metrocluster režimu naudojamas sinchroninis replikavimas, tačiau, skirtingai nei įprasta kopija, metroklasteris leidžia abiem saugojimo sistemoms veikti aktyviu režimu. Tie. neatskiriate aktyvaus ir budėjimo duomenų centrų. Programos vienu metu veikia su dviem saugojimo sistemomis, kurios fiziškai yra skirtinguose duomenų centruose. Prastovos per avarijas tokioje topologijoje yra labai mažos (RTO, dažniausiai minutės). Šiame straipsnyje mes nenagrinėsime savo metroklasterio įgyvendinimo, nes tai labai didelė ir talpi tema, todėl skirsime atskirą, kitą straipsnį, tęsdami šį straipsnį.
Be to, labai dažnai, kai kalbame apie replikaciją naudojant saugojimo sistemas, daugeliui žmonių kyla pagrįstas klausimas: > „Daugelis programų turi savo replikacijos įrankius, kodėl naudoti replikaciją saugojimo sistemose? Ar tai geriau ar blogiau?
Čia nėra aiškaus atsakymo, todėl čia yra argumentai UŽ ir SU:
Argumentai UŽ saugyklos replikaciją:
- Sprendimo paprastumas. Naudodami vieną įrankį galite pakartoti visą duomenų rinkinį, neatsižvelgiant į apkrovos tipą ir taikymą. Jei naudojate programų kopiją, kiekvieną programą turėsite konfigūruoti atskirai. Jei jų yra daugiau nei 2, tai yra itin daug darbo jėgos ir brangu (programos replikacijai dažniausiai reikia atskiros, o ne nemokamos licencijos kiekvienai programai. Bet apie tai plačiau žemiau).
- Galite atkartoti bet ką – bet kokią programą, bet kokius duomenis – ir jie visada bus nuoseklūs. Daugelis (dauguma) programų neturi replikacijos galimybių, o kopijos iš saugojimo sistemos yra vienintelis būdas apsaugoti nuo nelaimių.
- Nereikia permokėti už programos replikacijos funkcionalumą. Paprastai tai nėra pigu, kaip ir saugojimo sistemos kopijos licencijos. Tačiau už saugyklos replikacijos licenciją turite sumokėti vieną kartą, o programos kopijos licenciją reikia įsigyti kiekvienai programai atskirai. Jei tokių programų yra daug, tai kainuoja nemažus centus, o saugojimo replikacijos licencijų kaina tampa lašu jūroje.
Argumentai PRIEŠ saugyklos replikaciją:
- Replika per programas turi daugiau funkcionalumo pačių programų požiūriu, programa geriau žino savo duomenis (akivaizdu), todėl yra daugiau galimybių dirbti su jomis.
- Kai kurių programų gamintojai negarantuoja savo duomenų nuoseklumo, jei replikacija atliekama naudojant trečiųjų šalių įrankius. *
* - prieštaringa disertacija. Pavyzdžiui, gerai žinomas DBVS gamintojas labai ilgą laiką oficialiai deklaruoja, kad jų DBVS galima įprastai replikuoti tik naudojant jų priemones, o likusi replikacijos dalis (įskaitant saugojimo sistemas) yra „netiesa“. Tačiau gyvenimas parodė, kad taip nėra. Greičiausiai (bet tai nėra tikras) tai tiesiog nėra pats sąžiningiausias bandymas parduoti daugiau licencijų klientams.
Dėl to daugeliu atvejų replikacija iš saugojimo sistemos yra geresnė, nes Tai paprastesnis ir pigesnis variantas, tačiau pasitaiko sudėtingų atvejų, kai reikia specifinių programos funkcijų ir reikia dirbti su programos lygio replikacija.
Baigta teorija, dabar praktika
Mes sukonfigūruosime kopiją savo laboratorijoje. Laboratorinėmis sąlygomis imitavome du duomenų centrus (iš tikrųjų du gretimus stovus, kurie atrodė skirtinguose pastatuose). Stovas susideda iš dviejų variklio N2 saugojimo sistemų, kurios yra sujungtos viena su kita optiniais kabeliais. Fizinis serveris, kuriame veikia „Windows Server 2016“, yra prijungtas prie abiejų saugojimo sistemų naudojant 10 Gb Ethernet. Stovas gana paprastas, bet tai nekeičia esmės.
Schematiškai tai atrodo taip:
Logiškai mąstant, replikacija organizuojama taip:
Dabar pažvelkime į dabar turimas replikacijos funkcijas.
Palaikomi du režimai: asinchroninis ir sinchroninis. Logiška, kad sinchroninį režimą riboja atstumas ir ryšio kanalas. Visų pirma, sinchroniniam režimui reikia naudoti skaidulą kaip fiziką ir 10 gigabitų eternetą (arba didesnį).
Palaikomas atstumas sinchroniniam replikavimui yra 40 kilometrų, optinio kanalo delsos reikšmė tarp duomenų centrų – iki 2 milisekundžių. Apskritai jis veiks su dideliais vėlavimais, tačiau tada įrašymo metu bus stiprūs sulėtėjimai (tai irgi logiška), todėl jei planuojate sinchroninį replikavimą tarp duomenų centrų, turėtumėte patikrinti optikos kokybę ir vėlavimus.
Asinchroninio replikavimo reikalavimai nėra tokie rimti. Tiksliau, jų visai nėra. Tiks bet koks veikiantis Ethernet ryšys.
Šiuo metu AERODISK ENGINE saugojimo sistema palaiko blokinių įrenginių (LUN) replikavimą per Ethernet protokolą (varinį arba optinį). Projektams, kur reikalingas replikavimas per SAN audinį per Fibre Channel, šiuo metu pridedame atitinkamą sprendimą, tačiau jis dar neparengtas, todėl mūsų atveju tik Ethernet.
Replikacija gali veikti tarp bet kurios ENGINE serijos saugojimo sistemų (N1, N2, N4) nuo jaunesnių sistemų iki senesnių ir atvirkščiai.
Abiejų replikacijos režimų funkcionalumas yra visiškai identiškas. Toliau pateikiama daugiau informacijos apie tai, kas yra pasiekiama:
- Replikacija „vienas su vienu“ arba „vienas su vienu“, tai yra klasikinė versija su dviem duomenų centrais, pagrindiniu ir atsarginiu.
- Replikacija yra „vienas prie daugelio“ arba „vienas su daugeliu“, t.y. vieną LUN galima kopijuoti į kelias saugojimo sistemas vienu metu
- Norėdami įjungti, išjungti arba pakeisti replikacijos kryptį, suaktyvinkite, išjunkite ir „atvirkštinį“ replikavimą.
- Galima replikuoti ir RDG (Raid Distributed Group), ir DDP (dinaminio disko baseino) telkinius. Tačiau RDG telkinio LUN galima kopijuoti tik į kitą RDG. Tas pats su DDP.
Yra daug daugiau smulkių funkcijų, tačiau nėra prasmės jas išvardyti; mes jas paminėsime nustatydami.
Replikacijos nustatymas
Sąrankos procesas yra gana paprastas ir susideda iš trijų etapų.
- Tinklo sąranka
- Saugyklos nustatymas
- Taisyklių (jungčių) nustatymas ir žemėlapių sudarymas
Svarbus dalykas nustatant replikaciją yra tai, kad pirmieji du etapai turi būti kartojami nuotolinio saugojimo sistemoje, o trečiasis etapas - tik pagrindinėje.
Tinklo išteklių nustatymas
Pirmas žingsnis yra sukonfigūruoti tinklo prievadus, per kuriuos bus perduodamas replikacijos srautas. Norėdami tai padaryti, turite įjungti prievadus ir nustatyti jų IP adresus skyriuje Front-end adapters.
Po to turime sukurti baseiną (mūsų atveju RDG) ir virtualų IP replikacijai (VIP). VIP yra slankusis IP adresas, susietas su dviem „fiziniais“ saugojimo valdiklių (prievadų, kuriuos ką tik sukonfigūravome) adresais. Tai bus pagrindinė replikacijos sąsaja. Taip pat galite dirbti ne su VIP, o su VLAN, jei reikia dirbti su pažymėtu srautu.
Replikos VIP kūrimo procesas nedaug skiriasi nuo VIP kūrimo I/O (NFS, SMB, iSCSI). Tokiu atveju sukuriame įprastą VIP (be VLAN), tačiau būtinai nurodykite, kad ji skirta replikacijai (be šio rodyklės kitame žingsnyje negalėsime pridėti VIP prie taisyklės).
VIP turi būti tame pačiame potinklyje kaip ir IP prievadai, tarp kurių jis plūduriuoja.
Šiuos nustatymus kartojame nuotolinėje saugojimo sistemoje, žinoma, naudojant kitą IP.
VIP iš skirtingų saugojimo sistemų gali būti skirtinguose potinkliuose, svarbiausia, kad tarp jų būtų maršrutas. Mūsų atveju šis pavyzdys tiksliai parodytas (192.168.3.XX ir 192.168.2.XX)
Tai užbaigia tinklo dalies paruošimą.
Nustatoma saugykla
Replikos saugyklos nustatymas skiriasi nuo įprasto tik tuo, kad atvaizdavimą atliekame per specialų meniu „Replikacijos atvaizdavimas“. Kitu atveju viskas yra taip pat, kaip ir įprastoje sąrankoje. Dabar tvarka.
Anksčiau sukurtame telkinyje R02 turite sukurti LUN. Sukurkime jį ir pavadinkime LUN1.
Taip pat turime sukurti tą patį LUN tokio paties dydžio nuotolinio saugojimo sistemoje. Mes kuriame. Norėdami išvengti painiavos, iškvieskime nuotolinį LUN LUN1R
Jei mums reikėtų paimti jau egzistuojantį LUN, tada nustatydami kopiją turėtume atjungti šį produktyvų LUN nuo pagrindinio kompiuterio ir tiesiog nuotolinės saugojimo sistemoje sukurti tuščią identiško dydžio LUN.
Saugyklos sąranka baigta, pereikime prie replikacijos taisyklės kūrimo.
Replikacijos taisyklių arba replikacijos nuorodų nustatymas
Sukūrę LUN saugojimo sistemoje, kuri šiuo metu bus pagrindinė, sukonfigūruojame replikacijos taisyklę LUN1 1 saugojimo sistemoje į LUN1R 2 saugojimo sistemoje.
Nustatymas atliekamas meniu „Nuotolinis replikavimas“.
Sukurkime taisyklę. Norėdami tai padaryti, turite nurodyti kopijos gavėją. Ten taip pat nustatome ryšio pavadinimą ir replikacijos tipą (sinchroninis arba asinchroninis).
Lauke „nuotolinės sistemos“ pridedame saugojimo sistemą2. Norėdami pridėti, turite naudoti valdymo IP saugojimo sistemas (MGR) ir nuotolinio LUN, į kurį atliksime replikaciją, pavadinimą (mūsų atveju LUN1R). Valdymo IP reikia tik prijungiant ryšį, per juos replikacijos srautas nebus perduodamas, tam bus naudojamas anksčiau sukonfigūruotas VIP.
Jau šiame etape galime pridėti daugiau nei vieną nuotolinę sistemą „nuo vieno iki daugelio“ topologijai: spustelėkite mygtuką „Pridėti mazgą“, kaip parodyta paveikslėlyje žemiau.
Mūsų atveju yra tik viena nuotolinė sistema, todėl mes tuo apsiribojame.
Taisyklė paruošta. Atkreipkite dėmesį, kad jis automatiškai pridedamas prie visų replikacijos dalyvių (mūsų atveju jų yra du). Galite sukurti tiek taisyklių, kiek norite, bet kokiam skaičiui LUN ir bet kuria kryptimi. Pavyzdžiui, norėdami subalansuoti apkrovą, dalį LUN galime atkartoti iš 1 saugojimo sistemos į 2 saugojimo sistemą, o kitą dalį, atvirkščiai, iš 2 saugojimo sistemos į 1 saugojimo sistemą.
Sandėliavimo sistema1. Iškart po sukūrimo prasidėjo sinchronizavimas.
Sandėliavimo sistema2. Matome tą pačią taisyklę, bet sinchronizavimas jau baigėsi.
LUN1 1 saugojimo sistemoje yra pagrindinis vaidmuo, tai yra, jis yra aktyvus. LUN1R 2 saugojimo sistemoje atlieka antrinės funkcijos vaidmenį, ty yra budėjimo režimu, jei 1 saugojimo sistema sugenda.
Dabar galime prijungti savo LUN prie pagrindinio kompiuterio.
Prisijungsime per iSCSI, nors tai galima padaryti ir per FC. Atvaizdavimo nustatymas naudojant iSCSI LUN kopijoje praktiškai nesiskiria nuo įprasto scenarijaus, todėl čia to išsamiai nenagrinėsime. Jei kas, šis procesas aprašytas straipsnyje "".
Vienintelis skirtumas yra tas, kad atvaizdavimą sukuriame meniu „Replikacijos atvaizdavimas“.
Nustatėme kartografavimą ir davėme LUN šeimininkui. Šeimininkas pamatė LUN.
Suformatuojame jį į vietinę failų sistemą.
Viskas, sąranka baigta. Testai bus toliau.
Bandymai
Išbandysime tris pagrindinius scenarijus.
- Reguliarus vaidmenų keitimas Antrinis > Pagrindinis. Reguliarus vaidmenų keitimas reikalingas tuo atveju, jei, pavyzdžiui, pagrindiniame duomenų centre turime atlikti tam tikras prevencines operacijas ir per tą laiką, kad duomenys būtų prieinami, apkrovą perkeliame į atsarginį duomenų centrą.
- Avarinio vaidmens perjungimas Antrinis > Pirminis (duomenų centro gedimas). Tai yra pagrindinis scenarijus, pagal kurį egzistuoja replikacija, kuri gali padėti išgyventi visišką duomenų centro gedimą nesustabdant įmonės ilgesniam laikui.
- Ryšio kanalų tarp duomenų centrų suskaidymas. Dviejų saugojimo sistemų teisingos elgsenos tikrinimas tokiomis sąlygomis, kai dėl kokių nors priežasčių ryšio kanalas tarp duomenų centrų nepasiekiamas (pvz., netinkamoje vietoje iškastas ekskavatorius sulaužė tamsią optiką).
Pirmiausia pradėsime rašyti duomenis į savo LUN (rašyti failus su atsitiktiniais duomenimis). Iš karto matome, kad išnaudojamas ryšio kanalas tarp saugojimo sistemų. Tai lengva suprasti, jei atidarote prievadų, atsakingų už replikaciją, apkrovos stebėjimą.
Abi saugojimo sistemos dabar turi „naudingų“ duomenų, galime pradėti testą.
Tik tuo atveju, pažiūrėkime į vieno failo maišos sumas ir jas užsirašykite.
Reguliarus vaidmenų keitimas
Vaidmenų perjungimo operaciją (replikacijos krypties keitimą) galima atlikti naudojant bet kurią saugojimo sistemą, tačiau vis tiek turėsite pereiti prie abiejų, nes turėsite išjungti atvaizdavimą pagrindiniame, o įjungti jį antriniame (kuri taps pagrindine). ).
Galbūt dabar kyla pagrįstas klausimas: kodėl gi to neautomatizuoti? Atsakymas yra toks: tai paprasta, replikacija yra paprasta atsparumo nelaimėms priemonė, pagrįsta vien rankinėmis operacijomis. Norint automatizuoti šias operacijas, yra metrocluster režimas, jis yra visiškai automatizuotas, tačiau jo konfigūracija yra daug sudėtingesnė. Apie metroklasterio nustatymą rašysime kitame straipsnyje.
Pagrindinėje saugyklos sistemoje išjungiame žemėlapių sudarymą, kad įrašymas būtų sustabdytas.
Tada vienoje iš saugojimo sistemų (nesvarbu, pagrindinėje ar atsarginėje) meniu „Nuotolinis replikavimas“ pasirinkite mūsų ryšį REPL1 ir spustelėkite „Keisti vaidmenį“.
Po kelių sekundžių LUN1R (atsarginė saugojimo sistema) tampa pagrindine.
Mes atvaizduojame LUN1R su saugojimo sistema2.
Po to mūsų E: diskas automatiškai prijungiamas prie pagrindinio kompiuterio, tik šį kartą jis „atkeliavo“ iš LUN1R.
Tik tuo atveju palyginame maišos sumas.
Identiškai. Testas išlaikytas.
Failover. Duomenų centro gedimas
Šiuo metu pagrindinė saugojimo sistema po reguliaraus perjungimo yra atitinkamai saugojimo sistema 2 ir LUN1R. Norėdami imituoti avariją, išjungsime abiejų saugojimo valdiklių maitinimą2.
Prie jo nebėra prieigos.
Pažiūrėkime, kas vyksta 1 saugojimo sistemoje (šiuo metu atsarginėje).
Matome, kad pagrindinis LUN (LUN1R) nepasiekiamas. Klaidos pranešimas pasirodė žurnaluose, informacijos skydelyje ir pačioje replikacijos taisyklėje. Atitinkamai, duomenys iš prieglobos šiuo metu nepasiekiami.
Pakeiskite LUN1 vaidmenį į pagrindinį.
Atlieku žemėlapius su šeimininku.
Įsitikinkite, kad pagrindiniame kompiuteryje rodomas E diskas.
Mes patikriname maišą.
Viskas gerai. Saugojimo sistema sėkmingai išgyveno aktyvaus duomenų centro žlugimą. Apytikslis laikas, kurį praleidome prijungdami replikacijos „atšaukimą“ ir prijungdami LUN iš atsarginio duomenų centro, buvo apie 3 minutes. Akivaizdu, kad realioje gamyboje viskas yra daug sudėtingiau ir be veiksmų su saugojimo sistemomis reikia atlikti daug daugiau operacijų tinkle, pagrindiniuose kompiuteriuose, programose. Ir gyvenime šis laikotarpis bus daug ilgesnis.
Čia norėčiau parašyti, kad viskas, testas sėkmingai atliktas, bet neskubėkime. Pagrindinė saugojimo sistema „guli“, žinome, kad kai ji „nukrito“, ji atliko pagrindinį vaidmenį. Kas atsitiks, jei jis staiga įsijungs? Bus du pagrindiniai vaidmenys, o tai prilygsta duomenų sugadinimui? Dabar patikrinkime.
Staiga įjunkite pagrindinę saugojimo sistemą.
Jis įkeliamas kelias minutes, o po trumpo sinchronizavimo grįžta į tarnybą, tačiau atlieka antrinės funkcijos vaidmenį.
Viskas gerai. Smegenų padalijimas neįvyko. Mes apie tai galvojome ir visada po kritimo saugojimo sistema pakyla į antrinį vaidmenį, nepaisant to, kokį vaidmenį ji atliko „gyvenimo metu“. Dabar galime tvirtai pasakyti, kad duomenų centro gedimo testas buvo sėkmingas.
Ryšio kanalų tarp duomenų centrų gedimas
Pagrindinis šio testo uždavinys – įsitikinti, kad saugojimo sistema nepradėtų elgtis keistai, jei laikinai prarastų ryšio kanalus tarp dviejų saugojimo sistemų ir vėl atsirastų.
Taigi. Atjungiame laidus tarp saugojimo sistemų (įsivaizduokime, kad juos iškasė ekskavatorius).
Pradinėje mokykloje matome, kad nėra jokio ryšio su viduriniu.
Vidurinėje mokykloje matome, kad nėra ryšio su pradiniu.
Viskas veikia gerai, o mes ir toliau įrašome duomenis į pagrindinę saugojimo sistemą, tai yra garantuojame, kad jie skirsis nuo atsarginės, tai yra, jie „atsiskyrė“.
Per kelias minutes „sutaisome“ ryšio kanalą. Kai tik saugojimo sistemos mato viena kitą, automatiškai įjungiamas duomenų sinchronizavimas. Iš administratorės čia nieko nereikia.
Po kurio laiko sinchronizavimas baigiamas.
Ryšys buvo atkurtas, ryšio kanalų praradimas nesukėlė jokių avarinių situacijų, o įjungus sinchronizacija vyko automatiškai.
išvados
Išanalizavome teoriją – ko reikia ir kodėl, kur pliusai, o kur minusai. Tada nustatome sinchroninį replikavimą tarp dviejų saugojimo sistemų.
Toliau buvo atlikti pagrindiniai įprastinio perjungimo, duomenų centro gedimo ir ryšio kanalo gedimo testai. Visais atvejais saugojimo sistema veikė gerai. Duomenų neprarandama, o administracinių operacijų skaičius yra minimalus rankinio scenarijaus atveju.
Kitą kartą situaciją komplikuosime ir parodysime, kaip visa ši logika veikia automatizuotame metroklasteryje aktyviu-aktyviu režimu, tai yra, kai abi saugojimo sistemos yra pirminės, o elgesys saugojimo sistemos gedimų atveju yra visiškai automatizuotas.
Rašykite komentarus, mielai sulauksime rimtos kritikos ir praktinių patarimų.
Iki kito karto.
Šaltinis: www.habr.com