Viens no jaunajiem spēlētājiem katastrofu atjaunošanas risinājumu tirgū ir uzņēmums Hystax – Krievu startups, kas dibināts 2016. Gadā. Tā kā tēma par avārijas atjaunošanu ir ļoti populāra un tirgū ir ārkārtīgi liela konkurence, startups nolēmis koncentrēties uz migrāciju starp dažādām mākoņinfrastruktūrām. Produkts, kas ļauj organizēt vienkāršu un ātru migrāciju uz mākoņa, būtu ļoti noderīgs arī uzņēmuma "Onlanta" klientiem — lietotājiem. . Tā es iepazinos ar Hystax un sāku testēt tā iespējas. Par to, kas no tā iznāca, pastāstīšu šajā rakstā.
Hystax galvenā priekšrocība ir tā plašā funkcionalitāte attiecībā uz dažādu virtualizācijas platformu, viesoperētājsistēmu un mākoņu pakalpojumu atbalstu, kas ļauj pārvietot jūsu slodzes no jebkuras vietas uz jebkuru vietu.
Tas ļauj izveidot ne tikai DR risinājumus, lai uzlabotu pakalpojumu noturību, bet arī operatīvi, elastīgi migrēt resursus starp dažādām platformām un hiperskalariem, lai palielinātu izmaksu efektivitāti un izvēlētos vislabāko risinājumu konkrētam pakalpojumam šajā brīdī. Papildus platformām, kas uzskaitītas virsraksta attēlā, uzņēmums aktīvi sadarbojas arī ar Krievu mākoņu pakalpojumu sniedzējiem: Yandex.Cloud, KROK "Mākoņu pakalpojumi", Mail.ru un daudziem citiem. Tāpat ir vērts pieminēt, ka 2020. gadā uzņēmumam tika izveidots R&D centrs, kas atrodas Skolkovo.
Lēmums par viena risinājuma izvēli daudzām tirgus spēlētājiem liecina par labu cenu politiku un augstu produkta pielietojamību, ko mēs nolēmām pārbaudīt praksē.
Tātad, mūsu testēšanas uzdevums sastāv no migrācijas no manas testēšanas vides VMware un fiziskajām mašīnām uz pakalpojumu sniedzēja vidi, kas arī tiek pārvaldīta ar VMware. Jā, ir daudzi risinājumi, kas var veikt līdzīgu migrāciju, taču mēs uzskatām Hystax par universālu rīku, un izmēģināt migrāciju visos iespējamos kombinācijas — ir vienkārši nereāla uzdevums. Un mākoņa Oncloud.ru ir balstīts tieši uz VMware, tāpēc šī platforma kā mērķis mūs interesē vairāk. Tālāk es aprakstīšu pamata darbības principu, kas kopumā nav atkarīgs no platformas, un VMware no jebkuras puses var tikt aizvietota ar citas piegādātāja platformu.
Pirmajā posmā jāuzstāda Hystax Acura, kas ir sistēmas vadības paneļa rīks.
Tas tiek uzstādīts no veidnes. Kaut kādā veidā mūsu gadījumā tā nebija pilnīgi pareiza, un vietā, lai uzstādītu ieteiktos 8CPU, 16Gb, tā tika uzstādīta ar divreiz mazāk resursiem. Tāpēc ir jāatceras tos mainīt, citādi ar konteineriem infrastruktūra iekš VM, uz kuras viss balstīts, vienkārši nesāksies un portāls būs nepieejams. D detalizēti aprakstītas nepieciešamās resursu un visu sistēmas komponentu porti.
Ar IP adreses iestatīšanu caur veidni arī radās grūtības, tāpēc to mainījām no konsoles. Pēc tam var pāriet uz administrācijas tīmekļa saskarni un aizpildīt sākotnējo konfigurācijas vedni.
Endpoint – IP vai FQDN mūsu vCenter.
Lietotājvārds un parole – šeit viss skaidrs.
Target ESXi hostname – viens no mūsu klastera hostiem, uz kuru notiks replikācija.
Target datastore – viens no mūsu klastera datastoriem, uz kuru notiks replikācija.
Hystax Acura kontrolpaneļa publiskais IP – adrese, caur kuru būs pieejams vadības panelis.
Nepieciešams neliels precizējums par hostu un datastoru. Proti, ka Hystax replikācija darbojas uz hosta un datastora līmeņa. Tālāk es pastāstīšu, kā tenants var nomainīt hostu un datastoru, bet problēma ir cita. Hystax neatbalsta darbu ar resursu grupām, tas ir, replikācija vienmēr notiks klastera saknē (rakstot šo materiālu, Hystax komanda izlaida atjauninājumu, kurā ātri ieviesa manu funkciju pieprasījumu attiecībā uz resursu grupu atbalstu). Tika arī neatbalstīts vCloud Director, tātad, ja, kā manā gadījumā, tenantam nav administratora tiesību visam klasterim, bet tikai uz konkrētu resursu grupu, un mēs devām piekļuvi Hystax, viņš varēs patstāvīgi replikēt un palaist šos VM, bet viņš tos nespēs redzēt VMware infrastruktūrā, kurai viņam ir piekļuve un, attiecīgi, tālāk pārvaldīt virtuālās mašīnas. Ir nepieciešams, lai klastera administrators pārvietotu VM uz pareizo resursu grupu vai importētu to vCloud Director.
Kāpēc es uzsveru šos punktus? Jo, cik es saprotu produkta koncepciju, klientam vajadzētu spēt patstāvīgi veikt jebkuru migrāciju vai DR, izmantojot Acura paneli. Bet, kamēr VMware atbalsts nedaudz atpaliek no tā paša OpenStack, kur šādas mehānismes jau ir ieviesti.
Bet atgriezīsimies pie izvietošanas. Pirmais solis, pēc sākotnējās paneles iestatīšanas, mums ir jāizveido pirmais tenants mūsu sistēmā.
Visi šie lauki ir skaidri, es izstāstīšu tikai par lauku Cloud. Mums jau ir «noklusējuma» mākoņi, kurus mēs izveidojām, kad sākotnēji konfigurējām. Bet, ja mēs vēlamies, lai katrs tenants būtu savā datu krātuvē un resursu grupā, mēs to varam īstenot, izveidojot atsevišķus mākoņus katram no mūsu klientiem.
Jaunā mākoņa pievienošanas formā mēs norādām tos pašus parametrus, kā sākotnējā konfigurēšanā (mēs varam pat izmantot to pašu hostu), norādam konkrētajam klientam nepieciešamo datu krātuvi, un tagad papildu parametros mēs varam individuāli norādīt nepieciešamo resursu grupu {«resource_pool»: «YOUR_POOL_NAME»}.
Kā jūs varējāt pamanīt, tenant izveidošanas formā nav nekā par resursu piešķiršanu vai kvotām – sistēmā nav nekā tāda. Ierobežot tenant skaitu līdzstrādājošo replikāciju skaitā, replikācijas mašīnu skaitā vai citos parametrus nav iespējams. Tātad, mēs esam izveidojuši pirmo tenant. Tagad ir jāveic ne gluži loģiska, bet obligāta darbība – instalēt Cloud aģentu. Tā nav loģiska, jo aģents tiek lejupielādēts konkrētā klienta lapā.
Tas nav piesaistīts izveidotajam tenantam, un caur to darbosies visi mūsu pasūtītāji (vai caur vairākiem, ja mēs tos izvietosim). Viens aģents atbalsta 10 vienlaicīgas sesijas. Viena sesija tiek uzskatīta par vienu mašīnu. Nav svarīgi, cik daudz diskus tai ir. Pašlaik Acura iekšējam mehānismam aģentu mērogošanai VMware nav pieejams. Ir arī vēl viens nepatīkams moments – mēs nevaram no Acura paneļa apskatīt šī aģenta “izmantošanu”, lai spriestu, vai mums vajag izvietot vēl vai pašreizējā instalācija ir pietiekama. Rezultātā stends izskatās šādi:
Nākamais posms, lai piekļūtu mūsu klienta portālam, ir jāizveido lietotāja konts (ieguldot arī lomu, kas tiks piemērota šim lietotājam).
Tagad mūsu klients var patstāvīgi izmantot portālu. Viss, kas viņam jādara, ir lejupielādēt aģentus no portāla un uzstādīt tos savā pusē. Pastāv trīs veidu aģenti: Linux, Windows un VMware.
Pirmie divi tiek uzstādīti uz fiziskajām mašīnām vai virtuālajām mašīnām uz jebkura hipervizora, izņemot VMware. Šeit nav nepieciešams nekas papildu konfigurēt, aģents tiek lejupielādēts un jau zina, uz kuru adresi nepieciešams piekļūt, un burtiski pēc minūtes mašīnu varēs redzēt Acura panelī. Ar VMware aģentu situācija ir nedaudz sarežģītāka. Problēma ir tāda, ka aģents VMware tiek lejupielādēts no portāla jau sagatavots un ar nepieciešamo konfigurāciju. Bet, lai aģents VMware varētu piekļūt mūsu Acura portālam, tam jāzina arī par to virtualizācijas sistēmu, kurā tas tiks izvietots.
Faktiski šie dati tiks prasīti, kad pirmo reizi lejupielādēsim VMware aģentu. Problēma ir tāda, ka mūsu drošības laikmetā tālu ne visi vēlēsies norādīt savu administratora paroli svešā portālā, kas ir pilnīgi saprotams. Iekšpusē, pēc izvietošanas, aģentu vairs nevarēs konfigurēt (varēs tikai mainīt tā tīkla iestatījumus). Šeit es paredzu grūtības ar īpaši piesardzīgiem klientiem.
Tātad, pēc aģentu uzstādīšanas mēs varam atgriezties Acura panelī un redzēt visas mūsu mašīnas.
Kopš esmu strādājis ar sistēmu jau kādu laiku, man ir mašīnas dažādos stāvokļos. Visas tās atrodas grupā Default, taču ir iespēja izveidot atsevišķas grupas un pārvietot tajās mašīnas pēc vajadzības. Tas neietekmē neko – tas ir tikai loģisks datu attēlojums un to grupēšana ērtākai darbībai. Pirmais un vissvarīgākais, kas mums jādara pēc tam, ir uzsākt migrācijas procesu. Mēs to varam izdarīt gan piespiedu kārtā manuāli, gan iestatīt grafiku, tostarp arī masveida visām mašīnām uzreiz.
Atgādinu, ka Hystax tika pozicionēts kā produkts migrācijai. Tādēļ nav nekā pārsteidzoša, ka, lai uzsāktu mūsu replikētās mašīnas, mums ir jāizveido DR plāns. Plānu var sastādīt mašīnām, kuras jau atrodas stāvoklī Synced. Var ģenerēt gan vienai konkrētai VM, gan visām mašīnām uzreiz.
Parametru kopums DR plāna ģenerēšanai būs atšķirīgs atkarībā no infrastruktūras, uz kuru migrēsiet. VMware vidē ir pieejams minimālais parametru kopums. Tāpat netiek atbalstīta Re-IP mašīnām. Šajā plānā mūs interesē šādi aspekti: VM aprakstā parametrs „subnet”: „VMNetwork”, kur mēs piesaistām VM konkrētai tīklam klasterī. Rank – ir svarīgs, migrējot vairākas VM, nosaka to iedarbošanās secību. Flavor – apraksta VM konfigurāciju, šajā gadījumā – 1CPU, 2GB RAM. Subnetu sekcijā mēs nosakām, ka „subnet”: „VMNetwork” tiek asociēts ar tīklu „VM Network” VMware.
Izveidojot DR plānu, nav iespējas „sad repartir” diskus pa dažādiem datastoriem. Tie atradīsies tajā pašā datastorā, kas tika noteikts šim klienta mākoņa pakalpojumam, un, ja jums ir diski atšķirīgā klasē, tas var radīt dažas grūtības mašīnas palaišanā, bet pēc palaišanas un VM „atvienošanās” no Hystax, būs nepieciešama arī atsevišķa disku migrācija uz vajadzīgajiem datastoriem. Tālāk mums atliks tikai uzsākt mūsu DR plānu un gaidīt, kad tiks palaistas mūsu mašīnas. P2V/V2V konversijas process arī aizņem laiku. Manā lielākajā testēšanas mašīnā ar 100GB un trim diskiem tas aizņēma maksimums 10 minūtes.
Pēc tam ir jāizpēta palaistā VM, tās pakalpojumi, datu saderība un jāveic citas pārbaudes.
Tālāk mums ir divi ceļi:
- Dzēst – izdzēst palaistu DR plānu. Šī darbība vienkārši izslēgs palaisto VM. Replikācijas dati nekur nepazudīs.
- Atsiet – atvienot replikāciju mašīnu no Acura, t.i., būtībā pabeigt migrācijas procesu.
Risinājuma priekšrocības:
- vienkārša uzstādīšana un konfigurācija gan no klienta, gan no pakalpojumu sniedzēja puses;
- vienkārša migrācijas iestatīšana, DR plāna izveide un replikāciju uzsākšana;
- atbalsts un izstrādātāji pietiekami ātri reaģē uz izsistajām problēmām un novērš tās, izmantojot platformas vai aģentu atjauninājumus.
Mīnusi
- Nepietiekama atbalsta sniegšana Vmware.
- Trūkst jebkāda kvotēšanas tuvākajiem lietotājiem no platformas puses.
Tāpat es esmu izstrādājis Feature Request, kuru nosūtījām pārdevējam:
- izmantošanas un izvietojuma uzraudzība no Acura vadības konsoles Cloud aģentiem;
- kvotu esamība tuvākajiem lietotājiem;
- iespēja ierobežot vienlaicīgo replikāciju skaitu un ātrumu katram tuvākajam lietotājam;
- atbalsts VMware vCloud Director;
- atbalsts resursu grupām (tika realizēts testa laikā);
- iespēja konfigurēt VMware aģentu no paša aģenta, neieviešot klientu infrastruktūras akreditācijas datus Acura panelī;
- „vizualizācija” VM palaides procesa laikā, uzsākot DR plānu.
Vienīgais, kas man radīja ievērojamas sūdzības, ir dokumentācija. Es nepatīku „melniem kastēm” un dodu priekšroku, ja ir detalizēta dokumentācija par to, kā produkts darbojas iekšienē. Un, ja AWS un OpenStack produkti ir aprakstīti vēl kaut cik saprotami, tad VMware dokumentācijas ir ļoti maz.
Ir Izstrādāšanas ceļvedis, kas apraksta tikai Acura paneļa izvietošanu, un kur nav ne vārda par to, ka vajag arī Cloud aģentu. Ir pilns specifikāciju komplekts produktam, kas ir labi. Ir dokumentācija, kas apraksta iestatīšanu „no un līdz” ar AWS un OpenStack piemēru (lai gan tā man vairāk atgādina bloga ierakstu), un ir ļoti mazs Zināšanu bāzes parametrs.
Kopumā, tas nav pilnīgi tas dokumentācijas formāts, pie kura esmu pieradis, teiksim, pie lielākiem pārdevējiem, tāpēc man bija neērti. Tajā pašā laikā man neizdevās atrast atbildes uz daudziem sistēmas darbības „iekšējām” niansēm šajā dokumentācijā – ļoti daudzas jautājumu nācās precizēt pie tehniskā atbalsta, un tas diezgan ievērojami aizkavēja stenda izvietošanas un testēšanas procesu.
Noslēdzot sarunu, varu teikt, ka kopumā man patika gan produkts, gan uzņēmuma pieeja uzdevuma īstenošanai. Jā, ir trūkumi, ir patiešām kritiska funkcionalitātes nepietiekamība (sadarbībā ar VMware). Redzams, ka uzņēmums vispirms orientējas uz publiskajiem mākoņiem, jo īpaši AWS, un daudziem tas var būt pietiekami. Šāda vienkārša un ērta produkta esamība šodien, kad daudzas kompānijas izvēlas multimākoņu stratēģiju, ir ārkārtīgi svarīga. Ņemot vērā daudz zemāku cenu salīdzinājumā ar konkurentiem, tas padara produktu ļoti pievilcīgu.
Mēs meklējam nesen pievienoties mūsu komandai . Varbūt tieši jūs esat tas, ko meklējam?
Avots: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish