Unu di i ghjovani attori in u mercatu per e soluzioni di Recuperazione di Disastru hè Hystax, una startup russa da 2016. Siccomu u tema di a ripresa di disastru hè assai populari è u mercatu hè estremamente cumpetitivu, a startup hà decisu di fucalizza nantu à a migrazione trà e diverse infrastrutture di nuvola. Un pruduttu chì permette di urganizà una migrazione simplice è rapida à u nuvulu seria ancu assai utile per i clienti di Onlanta - utilizatori. . Hè cusì chì aghju cunnisciutu Hystax è hà cuminciatu à pruvà e so capacità. Vi dicu ciò chì hè vinutu in questu articulu.
A caratteristica principale di Hystax hè a so funziunalità larga per sustene diverse plataforme di virtualizazione, sistemi operativi invitati è servizii di nuvola, chì permette di trasferisce i vostri carichi di travagliu da ogni locu, in ogni locu.
Questu permette di creà micca solu suluzione DR per aumentà a tolleranza di difetti di i servizii, ma ancu per migrate rapidamente è flexiblemente risorse trà i diversi siti è iperscalers per aumentà u risparmiu di costu è selezziunate a megliu suluzione per un serviziu specificu in un momentu determinatu. In più di e plataforme listate in a stampa di u titulu, a cumpagnia coopera attivamente cù i fornituri di nuvola russi: Yandex.Cloud, CROC Cloud Services, Mail.ru è assai altri. Hè nutate ancu chì in 2020 a cumpagnia hà apertu un centru R&D situatu in Skolkovo.
L'scelta di una solu suluzione da un gran numaru di attori nantu à u mercatu indica una bona pulitica di prezzu è una alta applicabilità di u pruduttu, chì avemu decisu di pruvà in pratica.
Dunque, u nostru compitu di prova consisterà in a migrazione da u mo situ di prova VMware è e macchine fisiche à u situ di u fornitore, ancu gestitu da VMware. Iè, ci sò parechje suluzione chì ponu esse realizatu una tale migrazione, ma avemu cunsideratu Hystax cum'è un strumentu universale, è a prova di migrazione in tutte e cumminazzioni pussibuli hè solu un compitu irrealisticu. È u nuvulu Oncloud.ru hè custruitu specificamente nantu à VMware, cusì sta piattaforma cum'è destinazione ci interessa in più. In seguitu, descriveraghju u principiu basu di funziunamentu, chì hè in generale indipendente di a piattaforma, è VMware da ogni parte pò esse rimpiazzatu da una piattaforma da un altru venditore.
U primu passu hè di implementà Hystax Acura, chì hè u pannellu di cuntrollu di u sistema.
Si sviluppa da u mudellu. Per una certa ragione, in u nostru casu ùn era micca sanu currettu è invece di a 8CPU cunsigliata, 16Gb hè stata implementata cù a mità di e risorse. Per quessa, avete bisognu di ricurdà di cambià, altrimenti l'infrastruttura di cuntainer in a VM, nantu à quale tuttu hè custruitu, simpricimenti ùn principia micca è u portale serà inaccessibile. IN I risorse necessarii sò descritti in dettagliu, è ancu i porti per tutti i cumpunenti di u sistema.
Ci era ancu difficultà per stabilisce l'indirizzu IP attraversu un mudellu, cusì avemu cambiatu da a cunsola. Dopu questu, pudete andà à l'interfaccia web admin è compie l'assistente di cunfigurazione iniziale.
Endpoint - IP o FQDN di u nostru vCenter.
Login è Password - questu hè chjaru.
Target ESXi hostname hè unu di l'ospiti in u nostru cluster à quale a replicazione serà realizata.
Target datastore hè unu di i datastores in u nostru cluster à quale a replicazione serà realizata.
Hystax Acura Control Panel Public IP - l'indirizzu induve u pannellu di cuntrollu serà dispunibule.
Un pocu di clarificazione hè necessariu in quantu à l'ospite è u datastore. U fattu hè chì a replicazione di Hystax travaglia à u livellu di l'ospiti è di u datastore. In seguitu vi dicu cumu pudete cambià l'ospite è u datastore per un inquilanu, ma u prublema hè diversu. Hystax ùn sustene micca u travagliu cù pools di risorse, i.e. a replica andarà sempre à a radica di u cluster (à u mumentu di a scrittura di stu materiale, i ragazzi di Hystax anu publicatu una versione aghjurnata, induve anu implementatu rapidamente a mo dumanda di funziunalità in quantu à u supportu per i pools di risorse). vCloud Director hè ancu micca supportatu, i.e. se, cum'è in u mo casu, l'inquilanu ùn hà micca diritti di amministratore à u cluster sanu, ma solu à un pool di risorse specifiche, è avemu datu accessu à Hystax, allora ellu puderà riplicà indipindentamente è lancià sti VM, ma ellu hà da esse. ùn pò micca vedà in l'infrastruttura VMware , à quale ellu hà accessu è, per quessa, gestisce ancu e macchine virtuale. Hè necessariu per l'amministratore di u cluster movendu a VM in u pool di risorse desiderate o l'importa in vCloud Director.
Perchè mi concentru tantu nantu à questi punti? Perchè, quantu aghju capitu u cuncettu di u pruduttu, u cliente deve esse capace di implementà indipindentamente qualsiasi migrazione o DR cù u pannellu Acura. Ma finu à avà, u supportu VMware hè pocu daretu à u livellu di supportu per OpenStack, induve i meccanismi simili sò digià implementati.
Ma riturnemu à a distribuzione. Prima di tuttu, dopu a cunfigurazione iniziale di u pannellu, avemu bisognu di creà u primu inquilanu in u nostru sistema.
Tutti i campi quì sò chjaru, vi dicu solu nantu à u campu Cloud. Avemu digià un nuvulu "default" chì avemu creatu durante a cunfigurazione iniziale. Ma se vulemu esse capace di mette ogni inquilanu in u so propiu datastore è in u so propiu pool di risorse, pudemu implementà questu creendu nuvole separati per ognunu di i nostri clienti.
In a forma per aghjunghje una nova nuvola, specifiemu i stessi parametri cum'è durante a cunfigurazione iniziale (pudemu ancu aduprà u stessu òspite), indicà u datastore necessariu per un cliente specificu, è avà in paràmetri supplementari pudemu specificà individualmente a risorsa necessaria. pool {"resource_pool" : "YOUR_POOL_NAME"}
Comu pudete avè nutatu, in a forma di creazione di l'inquilanu ùn ci hè nunda di l'assignazione di risorse o di qualsiasi quota - ùn ci hè nunda di questu in u sistema. Hè impussibile di limità un inquilanu in u numeru di rèpliche simultanee, u numeru di machini per a replicazione, o per qualsiasi altri paràmetri. Dunque, avemu creatu u primu inquilino. Avà ci hè una cosa micca cumpletamente logica, ma ubligatoria - installà un agentu Cloud. Hè illogicu, postu chì l'agente hè telecaricatu nantu à a pagina di un cliente specificu.
À u stessu tempu, ùn hè micca ligatu à l'inquilanu creatu, è tutti i nostri clienti travagliaranu per ellu (o attraversu parechji, se l'avemu implementatu). Un agentu sustene 10 sessioni simultanee. Una macchina hè cuntata cum'è una sessione. Ùn importa micca quanti dischi hà. A data, ùn ci hè micca un mecanismu per l'agenti di scala in Acura stessu sottu VMware. Ci hè un momentu più dispiacevule - ùn avemu micca l'uppurtunità di guardà a "disposizione" di questu agentu da u pannellu Acura per cuncludi s'ellu ci vole à implementà più o se l'installazione attuale hè abbastanza. In u risultatu, u stand pare cusì:
U prossimu passu per accede à u nostru portale di u cliente hè di creà un contu (è prima, un rolu chì s'applicà à questu utilizatore).
Avà u nostru cliente pò aduprà u portale indipindente. Tuttu ciò chì deve fà hè di scaricà l'agenti da u portale è stallà da u so latu. Ci sò trè tippi di agenti: Linux, Windows è VMware.
I primi dui sò stallati nantu à a fisica o in macchine virtuali in qualsiasi ipervisore altru ch'è VMware. Ùn ci hè micca bisognu di cunfigurà nunda di più, l'agente hè telecaricatu è sà digià induve chjappà, è literalmente in un minutu a vittura serà visibile in u pannellu Acura. Cù l'agente VMware, a situazione hè un pocu più complicata. U prublema hè chì l'agente per VMware hè ancu scaricatu da u portale digià preparatu è chì cuntene a cunfigurazione necessaria. Ma in più di sapè nantu à u nostru portale Acura, un agente VMware hà ancu bisognu di cunnosce u sistema di virtualizazione nantu à quale serà implementatu.
In realtà, u sistema ci dumandarà di furnisce questi dati quandu avemu prima scaricatu l'agente VMware. U prublema hè chì in a nostra età di l'amore universale per a sicurità, micca tutti volenu indicà a so password di amministratore in u portale di l'altru, chì hè abbastanza comprensibile. Da l'internu, dopu a implementazione, l'agente ùn pò micca esse cunfiguratu in ogni modu (pudete solu cambià i so paràmetri di rete). Quì aghju previstu difficultà cù i clienti particularmente prudenti.
Allora, dopu avè installatu l'agenti, pudemu turnà à u pannellu Acura è vede tutte e nostre vitture.
Siccomu aghju travagliatu cù u sistema per parechji ghjorni avà, aghju vitture in diversi stati. Aghju tutti in u gruppu Default, ma hè pussibule di creà gruppi separati è trasfiriri vitture à elli cum'è avete bisognu. Questu ùn affetta nunda - solu una presentazione logica di dati è u so raggruppamentu per un travagliu più còmode. U primu è più impurtante chì avemu bisognu di fà dopu à questu hè di inizià u prucessu di migrazione. Pudemu fà questu manualmente o cunfiguendu un calendariu, ancu in massa per tutte e macchine in una volta.
Lasciami ricurdà chì Hystax hè statu posizionatu cum'è un pruduttu per a migrazione. Per quessa, ùn hè micca surprisante chì per eseguisce e nostre macchine replicate avemu bisognu di creà un pianu DR. U pianu pò esse fattu per i machini chì sò digià in u statu Synced. Pudete generà sia per una VM specifica sia per tutte e macchine in una volta.
U settore di paràmetri quandu generà un pianu DR differiscerà secondu l'infrastruttura à quale migrarete. Un settore minimu di parametri hè dispunibule per l'ambiente VMware. Re-IP per e macchine ùn hè ancu supportatu. In questu sensu, avemu interessatu in i seguenti punti: in a descrizzione di VM, u paràmetru "subnet": "VMNetwork", induve ligami a VM à una reta specifica in u cluster. Rank - pertinente quandu migrate parechje VM; determina l'ordine in quale sò lanciati. Sapore - descrive a cunfigurazione VM, in questu casu - 1CPU, 2GB RAM. In a subnets rùbbrica definimu chì "subnet": "VMNetwork" hè assuciatu cù a VMware "VM Network".
Quandu crea un pianu DR, ùn ci hè micca manera di "sparghje" dischi in diverse datastores. Seranu situati nantu à u listessu datastore chì hè statu definitu per questa nuvola di cliente, è se tenete dischi di diverse classi, questu pò causà qualchì difficultà à l'iniziu di a macchina, è dopu avè principiatu è "separatu" a VM da Hystax. richiede una migrazione di dischi separati à i datastores richiesti. Allora tuttu ciò chì avemu da fà hè di lancià u nostru pianu DR è aspittà chì e nostre vitture aumentanu. U prucessu di cunversione P2V / V2V pigghia dinù tempu. In a mo più grande macchina di prova, 100GB cù trè dischi, hà pigliatu un massimu di 10 minuti.
Dopu questu, duvete cuntrollà a VM in esecuzione, i servizii nantu à questu, a coherenza di e dati, è eseguisce altri cuntrolli.
Allora avemu dui modi:
- Elimina - sguassate u pianu DR in esecuzione. Questa azione fermarà solu a VM in esecuzione. Queste repliche ùn vanu in ogni locu.
- Detach - strappa una vittura replicata luntanu da una Acura, i.e. veramente compie u prucessu di migrazione.
Pro di a suluzione:
- facilità d'installazione è cunfigurazione sia da u cliente sia da u fornitore;
- facilità di stallà a migrazione, creendu un pianu di DR è lanciari repliche;
- u supportu è i sviluppatori rispundenu abbastanza rapidamente à i prublemi truvati è li risolve cù l'aghjurnamenti di piattaforma o agenti.
Минусы
- Support Vmware insufficiente.
- Assenza di ogni quota per l'inquilini da a piattaforma.
Aghju cumpilatu ancu una Richiesta di Funzione, chì avemu sottumessu à u venditore:
- monitoraghju di usu è implementazione da a cunsola di gestione Acura per l'agenti Cloud;
- dispunibilità di quotes per l'inquilini;
- a capacità di limità u numeru di replicazioni simultanee è a rapidità per ogni inquilino;
- Supportu VMware vCloud Director;
- supportu per i pools di risorse (implementatu durante a prova);
- a capacità di cunfigurà l'agente VMware da l'agente stessu, senza inserisce credenziali da l'infrastruttura di u cliente in u pannellu Acura;
- "visualizazione" di u prucessu di startup VM quandu eseguisce u pianu DR.
L'unicu ciò chì m'hà causatu grandi critichi era a documentazione. Ùn mi piace micca veramente "scatole nere" è preferite quandu ci hè una documentazione dettagliata nantu à cumu u pruduttu funziona in l'internu. E se per AWS è OpenStack u pruduttu hè descrittu ancu più o menu, allora per VMware ci hè pocu documentazione.
Ci hè una Guida Installazione chì discriva solu u dispiegamentu di u panel Acura, è ùn ci hè micca una parolla nantu à u fattu chì un agentu Cloud hè dinù bisognu. Ci hè un inseme cumpletu di specificazioni di u produttu, chì hè bonu. Ci hè una documentazione chì descrive a cunfigurazione "da u principiu à a fine" utilizendu AWS è OpenStack cum'è un esempiu (ancu se mi pare più cum'è un post di blog), è ci hè una Base di Cunniscenza assai chjuca.
In generale, questu ùn hè micca abbastanza u formatu di documentazione chì sò abituatu, per dì, da i venditori più grande, perchè ùn era micca sanu cunfortu. À u listessu tempu, ùn aghju mai trovu risposte nantu à alcune di e sfumature di u funziunamentu di u sistema "dentro" in questa ducumentazione - assai dumande anu da esse clarificate cù u supportu tecnicu, è questu abbastanza ritardatu u prucessu di implementazione di u stand è di cunduzzione. prova.
Per sintetizà, possu dì chì in generale mi piace u pruduttu è l'approcciu di a cumpagnia à u compitu. Iè, ci sò difetti, ci hè una mancanza veramente critica di funziunalità (in cunnessione cù VMware). Hè chjaru chì, prima di tuttu, a cumpagnia hè sempre focu annantu à i nuvuli publichi, in particulare AWS, è per alcuni questu serà abbastanza. Avè un pruduttu cusì simplice è cunvene oghje, quandu parechje cumpagnie sceglienu una strategia multi-nuvola, hè assai impurtante. In cunsiderà u prezzu assai più bassu cumparatu cù i cuncurrenti, questu rende u pruduttu estremamente attraente.
Cerchemu un membru di a squadra . Forse sì tu?
Source: www.habr.com