Hondamendiak berreskuratzeko irtenbideen merkatuko eragile gazteetako bat Hystax da, 2016ko errusiar startup bat. Hondamendien berreskurapenaren gaia oso ezaguna denez eta merkatua oso lehiakorra denez, startup-ak hodeiko azpiegitura ezberdinen arteko migrazioan zentratzea erabaki zuen. Hodeirako migrazio erraz eta azkar bat antolatzeko aukera ematen duen produktu bat ere oso erabilgarria izango litzateke Onlantako bezeroentzat - erabiltzaileentzat. . Horrela ezagutu nuen Hystax eta bere gaitasunak probatzen hasi nintzen. Artikulu honetan zer atera zen kontatuko dizut.
Hystax-en ezaugarri nagusia birtualizazio plataforma, sistema eragile gonbidatuak eta hodeiko zerbitzuak onartzen dituen funtzionaltasun zabala da, eta horrek zure lan-kargak edonondik eta edonondik transferitzea posible egiten du.
Horri esker, zerbitzuen akatsen tolerantzia areagotzeko DR irtenbideak sortzeaz gain, gune eta hipereskalatzaileen artean baliabideak azkar eta malgutasunez migratzeko aukera ematen du, kostuak aurreztea areagotzeko eta une jakin batean zerbitzu zehatz baterako soluzio onena hautatzeko. Izenburuko irudian ageri diren plataformez gain, konpainiak Errusiako hodei hornitzaileekin ere lankidetzan aritzen da: Yandex.Cloud, CROC Cloud Services, Mail.ru eta beste hainbatekin. Azpimarratzekoa da, halaber, 2020an enpresak Skolkovon kokatutako I+G zentro bat ireki zuela.
Merkatuko eragile ugarik irtenbide bakarra aukeratzeak prezioen politika ona eta produktuaren aplikagarritasun handia adierazten du, praktikan probatzea erabaki genuena.
Beraz, gure proba egitekoa nire VMware proba gunetik eta makina fisikoetatik hornitzailearen gunera migratzea izango da, VMware-k ere kudeatzen duena. Bai, migrazio hori egin dezaketen irtenbide asko daude, baina Hystax tresna unibertsaltzat hartzen dugu, eta migrazioa konbinazio posible guztietan probatzea zeregin irrealista besterik ez da. Eta Oncloud.ru hodeia VMware-n bereziki eraikita dago, beraz, plataforma hau helburu gisa neurri handiagoan interesatzen zaigu. Jarraian, funtzionamenduaren oinarrizko printzipioa deskribatuko dut, oro har plataformatik independentea dena, eta VMware edozein aldetatik beste saltzaile baten plataforma batekin ordezkatu daiteke.
Lehenengo urratsa Hystax Acura zabaltzea da, hau da, sistemaren kontrol panela.
Txantiloitik zabaltzen da. Zerbaitegatik, gure kasuan ez zen guztiz zuzena eta gomendatutako 8CPUaren ordez, 16Gb baliabideen erdiarekin zabaldu zen. Hori dela eta, horiek aldatzea gogoratu behar duzu, bestela, dena eraikita dagoen VM barneko edukiontzien azpiegitura ez da abiaraziko eta ataria eskuraezina izango da. IN Beharrezko baliabideak zehatz-mehatz deskribatzen dira, baita sistemaren osagai guztien atakak ere.
Txantiloi baten bidez IP helbidea ezartzeko zailtasunak ere egon ziren, beraz, kontsolatik aldatu genuen. Horren ondoren, administratzailearen web interfazera joan eta hasierako konfigurazio morroia osa dezakezu.
Endpoint - Gure vCenter-en IP edo FQDN.
Saioa eta pasahitza - hau argi dago.
Helburuko ESXi ostalari-izena gure klusterreko ostalarietako bat da, zeinetan erreplikazioa egingo den.
Helburuko datu-biltegia erreplikazioa egingo den gure klusterreko datu-biltegietako bat da.
Hystax Acura Control Panel Public IP - kontrol panela erabilgarri egongo den helbidea.
Ostalari eta datu-biltegiari buruzko argipen txiki bat behar da. Izan ere, Hystax erreplikazioak ostalari eta datu-biltegi mailan funtzionatzen du. Jarraian, maizter baten ostalari eta datu-biltegia nola alda ditzakezun esango dizut, baina arazoa bestelakoa da. Hystax-ek ez du onartzen baliabide multzoekin lan egitea, hau da. erreplika beti klusterraren errora joango da (material hau idazteko momentuan, Hystaxeko mutilek bertsio eguneratua kaleratu zuten, non azkar inplementatu zuten nire eginbide-eskaera baliabideen multzoen laguntzari dagokionez). vCloud Director ere ez da onartzen, hau da. nire kasuan bezala, maizterrak ez badu kluster osorako administratzaile-eskubiderik, baliabide multzo zehatz baterako soilik, eta Hystax-i sarbidea eman badiogu, orduan modu independentean errepikatu eta VM hauek abiarazi ahal izango ditu, baina egingo du. ezin ditu ikusi VMware azpiegituran , zeinetara sarbidea duen eta, horren arabera, makina birtualak gehiago kudeatzen ditu. Beharrezkoa da kluster-administratzaileak VM-a nahi duzun baliabide multzora eramatea edo vCloud Director-era inportatzea.
Zergatik jartzen naiz hainbeste arreta puntu hauetan? Zeren, produktuaren kontzeptua ulertzen dudan heinean, bezeroak edozein migrazio edo DR modu independentean inplementatzeko gai izan beharko luke Acura panela erabiliz. Baina orain arte, VMware-ren laguntza OpenStack-en laguntza-mailaren apur bat atzean dago, non dagoeneko antzeko mekanismoak ezarri diren.
Baina itzul gaitezen hedapenera. Lehenik eta behin, panelaren hasierako konfigurazioa egin ondoren, gure sistemako lehen maizterrak sortu behar ditugu.
Hemen eremu guztiak argi daude, Hodei eremuari buruz bakarrik esango dizut. Dagoeneko badugu hasierako konfigurazioan sortu genuen hodei "lehenetsia". Baina maizter bakoitza bere datu-biltegian eta bere baliabide-biltegian jarri ahal izan nahi badugu, hori inplementa dezakegu gure bezero bakoitzarentzako hodei bereiziak sortuz.
Hodei berri bat gehitzeko inprimakian, hasierako konfigurazioan zeuden parametro berdinak zehazten ditugu (ostalari bera ere erabil dezakegu), bezero jakin baterako behar den datu-biltegia adierazi eta, orain, parametro gehigarrietan, beharrezkoa den baliabidea banan-banan zehaztu dezakegu. pool {"resource_pool": "YOUR_POOL_NAME"}
Konturatuko zinen bezala, maizterrak sortzeko formularioan ez dago ezer baliabideen esleipenari edo kuotei buruz; ez dago horrelakorik sisteman. Ezinezkoa da maizter bat mugatu aldibereko erreplika kopuruan, erreplikatzeko makina kopuruan edo beste edozein parametroren arabera. Beraz, lehen maizterra sortu dugu. Orain ez dago guztiz logikoa, baina derrigorrezkoa den gauza bat: Hodeiko agente bat instalatzea. Ez da logikoa, agentea bezero zehatz baten orrian deskargatzen baita.
Aldi berean, ez dago sortutako maizterrekin lotuta, eta gure bezero guztiek lan egingo dute horren bidez (edo hainbaten bidez, zabaltzen baditugu). Agente batek aldi berean 10 saio onartzen ditu. Makina bat saio bat bezala zenbatzen da. Berdin du zenbat disko dituen. Orain arte, ez dago Acuran bertan agenteak eskalatzeko mekanismorik VMware-ren arabera. Momentu desatsegin bat gehiago dago: ez dugu aukerarik Acura paneleko agente honen "esabaketa" aztertzeko, gehiago zabaldu behar dugun edo egungo instalazioa nahikoa den erabakitzeko. Ondorioz, standak honela dauka:
Gure bezeroen atarian sartzeko hurrengo urratsa kontu bat sortzea da (eta lehenik, erabiltzaile honi aplikatuko zaion rol bat).
Orain gure bezeroak ataria modu independentean erabil dezake. Agenteak atariko deskargatu eta bere alboan instalatu besterik ez du egin behar. Hiru agente mota daude: Linux, Windows eta VMware.
Lehenengo biak fisikan edo makina birtualetan instalatzen dira VMware ez den edozein hipervisoretan. Ez dago ezer gehigarririk konfiguratu beharrik, agentea deskargatu eta dagoeneko badaki non jo behar duen, eta literalki minutu batean autoa ikusgai egongo da Acura panelean. VMware agentearekin egoera pixka bat zailagoa da. Arazoa da VMware-ren agentea dagoeneko prestatuta dagoen eta beharrezko konfigurazioa duen ataritik deskargatzen dela. Baina gure Acura ataria ezagutzeaz gain, VMware agente batek zabalduko den birtualizazio sistemaren berri ere jakin behar du.
Izan ere, sistemak datu hauek emateko eskatuko digu VMware agentea lehen aldiz deskargatzen dugunean. Arazoa da gure segurtasunarekiko maitasun unibertsalaren garaian, denek ez dutela administratzailearen pasahitza adierazi nahi beste norbaiten atarian, eta hori nahiko ulergarria da. Barrutik, zabaldu ondoren, agentea ezin da inola ere konfiguratu (sarearen ezarpenak soilik alda ditzakezu). Hemen zailtasunak aurreikusten ditut bezero bereziki zuhurrekiko.
Beraz, agenteak instalatu ondoren, Acura panelera itzuli eta gure auto guztiak ikus ditzakegu.
Orain hainbat egun sistemarekin lanean nabilenez, autoak egoera ezberdinetan dauzkat. Horiek guztiak Default taldean dauzkat, baina posible da talde bereiziak sortzea eta autoak behar duzun moduan transferitzea. Horrek ez du ezertan eragiten - datuen aurkezpen logikoa eta haien taldekatzea soilik lan erosoagoa izateko. Horren ostean egin behar dugun lehenengo gauza eta garrantzitsuena migrazio prozesua abiaraztea da. Hori eskuz edo programazio bat ezarriz egin dezakegu, aldi berean makina guztien multzoan barne.
Gogorarazten dizut Hystax migraziorako produktu gisa kokatu zela. Hori dela eta, ez da harritzekoa gure erreplikatutako makinak exekutatu ahal izateko DR plan bat sortu behar izatea. Plana dagoeneko Synced egoeran dauden makinentzat egin daiteke. VM zehatz baterako eta makina guztientzat sor ditzakezu aldi berean.
DR plan bat sortzerakoan parametroen multzoa desberdina izango da migratuko duzun azpiegituraren arabera. Gutxieneko parametro multzo bat dago eskuragarri VMware ingurunerako. Makinentzako bir-IP ere ez da onartzen. Zentzu honetan, puntu hauek interesatzen zaizkigu: VM deskribapenean, βazpisareaβ parametroa: βVMNetworkβ, non VM-a klusterreko sare zehatz batera lotzen dugun. Rank - garrantzitsua da hainbat VM migratzerakoan; abiarazteko ordena zehazten du. Zaporea - VM konfigurazioa deskribatzen du, kasu honetan - 1CPU, 2GB RAM. Azpisareen atalean "azpisare" hori definitzen dugu: "VMNetwork" VMware "VM Network"-arekin lotuta dago.
DR plan bat sortzean, ez dago diskoak datu-biltegi ezberdinetan "zabaltzeko" modurik. Bezero-hodei honetarako definitu zen datu-biltegi berean kokatuko dira, eta klase ezberdinetako diskoak badituzu, horrek zailtasun batzuk sor ditzake makina abiarazteko orduan, eta VM Hystax-etik abiarazi eta "bereizi" ondoren, gainera beharrezkoak diren datu-biltegietara migrazio-disko bereiziak behar dira. Orduan egin behar duguna da gure DR plana abian jartzea eta gure autoak igo arte itxaron. P2V/V2V bihurtze prozesuak ere denbora behar du. Nire proba-makina handienean, 100GB hiru diskorekin, 10 minutu behar izan zituen gehienez.
Horren ondoren, exekutatzen ari den VM-a, bertan dauden zerbitzuak, datuen koherentzia egiaztatu beharko zenuke eta beste egiaztapen batzuk egin.
Orduan, bi modu ditugu:
- Ezabatu - ezabatu martxan dagoen DR plana. Ekintza honek exekutatzen ari den VM itxiko du. Erreplika hauek ez doaz inora.
- Desaktibatu - erreplikatutako auto bat kendu Acura batetik, hau da. benetan migrazio-prozesua osatu.
Irtenbidearen abantailak:
- instalatzeko eta konfiguratzeko erraztasuna bezeroarengandik zein hornitzailearengandik;
- migrazioa konfiguratzeko, DR plan bat sortu eta erreplikak abiarazteko erraztasuna;
- laguntza eta garatzaileek nahiko azkar erantzuten diete aurkitutako arazoei eta konpontzen dituzte plataforma edo agenteen eguneraketak erabiliz.
Cons
- Vmware-ren laguntza nahikoa ez da.
- Plataformako maizterrek kuotarik ez izatea.
Eginbide-eskaera bat ere osatu nuen, saltzaileari bidali genion:
- erabileraren jarraipena eta hedapena Hodeiko agenteentzako Acura kudeaketa kontsolatik;
- maizterentzako kuoten erabilgarritasuna;
- maizter bakoitzaren aldibereko errepikapen kopurua eta abiadura mugatzeko gaitasuna;
- VMware vCloud Director laguntza;
- baliabide-multzoetarako laguntza (probetan ezarrita);
- VMware agentea agentetik bertatik konfiguratzeko gaitasuna, Acura panelean bezeroaren azpiegiturako kredentzialak sartu gabe;
- VM abiarazteko prozesuaren "ikustaldia" DR plana exekutatzen denean.
Kritika handiak eragin zizkidan bakarra dokumentazioa izan zen. Ez zait asko gustatzen "kutxa beltzak" eta nahiago dut produktuaren barruan nola funtzionatzen duen dokumentazio zehatza dagoenean. Eta AWS eta OpenStack-entzat produktua are gehiago edo gutxiago deskribatzen bada, orduan VMwarerako oso dokumentazio gutxi dago.
Acura panelaren hedapena soilik deskribatzen duen Instalazio Gida bat dago, eta ez dago hitzik ere Hodeiko agente bat ere behar dela. Produktuen zehaztapenen multzo osoa dago, eta hori ona da. Badago konfigurazioa "hasieratik amaierara" deskribatzen duen dokumentazioa AWS eta OpenStack erabiliz adibide gisa (nahiz eta niretzat blog-argitalpen bat dirudien arren), eta oso txikia da Knowledge Base.
Orokorrean, hau ez da guztiz ohituta nagoen dokumentazio formatua, esate baterako, saltzaile handienetatik, beraz, ez nintzen guztiz eroso nengoen. Aldi berean, ez dut inoiz aurkitu dokumentazio honetan sistemak "barruan" funtzionatzen duen Γ±abardura batzuei buruzko erantzunik; galdera asko argitu behar izan ziren laguntza teknikoarekin, eta horrek nahiko atzeratu zuen standa zabaltzeko eta burutzeko prozesua. probak.
Laburbilduz, esan dezaket orokorrean produktua gustatu zaidala eta enpresak zereginari duen ikuspegia. Bai, gabeziak daude, funtzionalitate falta benetan larria dago (VMware-rekin lotuta). Argi dago, lehenik eta behin, konpainiak hodei publikoetara bideratzen duela oraindik, AWS bereziki, eta batzuentzat nahikoa izango da. Gaur egun hain produktu sinple eta erosoa izatea, enpresa askok hodei anitzeko estrategia aukeratzen ari direnean, oso garrantzitsua da. Lehiakideekin alderatuta askoz prezio txikiagoa dela kontuan hartuta, horrek produktua oso erakargarria egiten du.
Taldekide baten bila gabiltza . Agian zu zara?
Iturria: www.habr.com