Een van die jong spelers in die Disaster Recovery-oplossingsmark is Hystax, 'n Russiese beginonderneming in 2016. Aangesien die onderwerp van rampherstel baie gewild is en die mark uiters mededingend is, het die beginonderneming besluit om op migrasie tussen verskillende wolkinfrastruktuur te fokus. 'n Produk wat jou toelaat om 'n eenvoudige en vinnige migrasie na die wolk te organiseer, sal baie nuttig wees vir Onlanta se kliënte - gebruikers . Dit is hoe ek Hystax leer ken het en die kenmerke daarvan begin toets het. En wat daarvan gekom het, sal ek in hierdie artikel vertel.
Die hoofkenmerk van Hystax is sy wye funksionaliteit om verskeie virtualisasieplatforms, gas-bedryfstelsel en wolkdienste te ondersteun, wat dit moontlik maak om jou werkladings van enige plek en enige plek af te skuif.
Dit laat jou toe om nie net DR-oplossings te skep om die foutverdraagsaamheid van dienste te verbeter nie, maar ook vinnig, buigsaam hulpbronne tussen verskillende werwe en hiperskalers te migreer om kostebesparings te verhoog en die beste oplossing vir 'n spesifieke diens op die oomblik te kies. Benewens die platforms wat in die titelprent gelys word, werk die maatskappy ook aktief saam met Russiese wolkverskaffers: Yandex.Cloud, CROC Cloud Services, Mail.ru en vele ander. Dit is ook opmerklik dat die maatskappy in 2020 'n R&D-sentrum in Skolkovo geopen het.
Die keuse van een oplossing deur 'n groot aantal spelers op die mark dui op 'n goeie prysbeleid en hoë toepaslikheid van die produk, wat ons besluit het om in die praktyk te toets.
Dus, ons toetstaak sal bestaan uit die migreer van my VMware-toetswerf en fisiese masjiene na die verskaffer se webwerf wat ook VMware gebruik. Ja, daar is baie oplossings wat so 'n migrasie kan implementeer, maar ons beskou Hystax as 'n universele instrument, en om die migrasie in alle moontlike kombinasies te toets is eenvoudig 'n onrealistiese taak. Ja, en die Oncloud.ru-wolk is spesifiek op VMware gebou, so hierdie platform, as 'n teiken, interesseer ons in 'n groter mate. Vervolgens sal ek die basiese beginsel van werking beskryf, wat as geheel nie van die platform afhang nie, en VMware kan van enige kant af vervang word met 'n platform van 'n ander verskaffer.
Die eerste stap is om Hystax Acura, wat die stelsel se beheerpaneel is, te ontplooi.
Dit brei uit vanaf die sjabloon. Om een of ander rede, in ons geval, was dit nie heeltemal korrek nie en in plaas van die aanbevole 8CPU, is 16Gb met die helfte van die hulpbronne ontplooi. Daarom moet jy onthou om dit te verander, anders sal die infrastruktuur binne die VM, waarop alles gebou is, eenvoudig nie met houers begin nie en die portaal sal onbeskikbaar wees. IN die vereiste hulpbronne word in detail beskryf, sowel as poorte vir alle stelselkomponente.
En daar was ook probleme met die opstel van die IP-adres deur die sjabloon, so ons het dit vanaf die konsole verander. Daarna kan u na die admin-webkoppelvlak gaan en die aanvanklike konfigurasie-assistent voltooi.
Eindpunt - IP of FQDN van ons vCenter.
Teken in en wagwoord - dit is duidelik hier.
Target ESXi gasheernaam is een van die gashere in ons groep waarna gerepliseer sal word.
Target datastore is een van die datastore in ons cluster waarna gerepliseer sal word.
Hystax Acura Control Panel Public IP - die adres waar die kontrolepaneel beskikbaar sal wees.
'n Bietjie verduideliking oor die gasheer en datastoor word vereis. Die feit is dat Hystax-replikasie op die gasheer- en datastoorvlakke werk. Vervolgens sal ek jou vertel hoe jy die gasheer en datastoor vir die huurder kan verander, maar die probleem is anders. Hystax ondersteun nie hulpbronpoel nie, d.w.s. die replika sal altyd met die wortel van die groep gebeur (ten tyde van die skryf van hierdie materiaal het die ouens van Hystax 'n opgedateerde weergawe vrygestel, waar hulle vinnig my kenmerkversoek oor ondersteuning vir hulpbronpoele geïmplementeer het). Ook vCloud Director word nie ondersteun nie, dws. as, soos in my geval, die huurder nie admin regte op die hele groepering het nie, maar slegs op 'n spesifieke hulpbronpoel, en ons het toegang tot Hystax gegee, dan sal hy hierdie VM's onafhanklik kan repliseer en bestuur, maar hy sal hulle nie in die VMware-infrastruktuur kan sien nie, waartoe hy toegang het en dienooreenkomstig virtuele masjiene verder kan bestuur. Die groepadministrateur moet die VM na die korrekte hulpbronpoel skuif of dit in vCloud Director invoer.
Hoekom fokus ek so baie op hierdie oomblikke? Omdat, sover ek die konsep van die produk verstaan, die kliënt in staat moet wees om onafhanklik enige migrasie of DR te implementeer deur die Acura-paneel te gebruik. Maar tot dusver is VMware-ondersteuning effens agter die vlak van ondersteuning vir dieselfde OpenStack, waar sulke meganismes reeds geïmplementeer is.
Maar terug na ontplooiing. Eerstens, na die aanvanklike opstelling van die paneel, moet ons die eerste huurder in ons stelsel skep.
Al die velde hier is duidelik, ek sal jou net vertel van die Wolk-veld. Ons het reeds 'n "verstek" wolk wat ons geskep het tydens die aanvanklike konfigurasie. Maar as ons elke huurder op sy eie datastoor en in sy eie hulpbronpoel wil kan plaas, kan ons dit implementeer deur aparte wolke vir elkeen van ons kliënte te skep.
In die vorm van die byvoeging van 'n nuwe wolk, spesifiseer ons dieselfde parameters as tydens die aanvanklike konfigurasie (ons kan selfs dieselfde gasheer gebruik), spesifiseer die datastoor wat benodig word vir 'n spesifieke kliënt, en nou in die bykomende parameters kan ons reeds individueel die vereiste swembadhulpbron {"resource_pool" :"YOUR_POOL_NAME"}
Soos u dalk opgemerk het, in die vorm van die skep van 'n huurder is daar niks oor die toewysing van hulpbronne of 'n soort kwota nie - daar is niks hiervan in die stelsel nie. Jy kan nie die huurder beperk in die aantal gelyktydige replikas, die aantal masjiene vir replikasie, of deur enige ander parameters nie. So, ons het die eerste huurder geskep. Nou is daar 'n nie heeltemal logiese, maar verpligte ding nie - die installering van 'n Wolk-agent. Dit is onlogies, want die agent word op die bladsy van 'n spesifieke kliënt afgelaai.
Terselfdertyd is dit nie gekoppel aan die geskepte huurder nie, en al ons kliënte sal daardeur werk (of na verskeie, as ons hulle ontplooi). Een agent ondersteun 10 gelyktydige sessies. Een sessie tel as een motor. Dit maak nie saak hoeveel skywe dit het nie. Tot op datum is daar geen meganisme vir skaalmiddels in Acura self vir VMware nie. Daar is nog 'n onaangename oomblik - ons is nie in staat om na die "gebruik" van hierdie agent vanaf die Acura-paneel te kyk om te besluit of ons meer moet ontplooi of die huidige installasie genoeg is nie. Gevolglik lyk die staanplek so:
Die volgende stap om toegang tot ons kliënt se portaal te verkry, is om 'n rekening te skep (en eerstens ook 'n rol wat op hierdie gebruiker toegepas sal word).
Nou kan ons kliënt die portaal onafhanklik gebruik. Al wat hy hoef te doen is om agente van die portaal af te laai en hulle aan sy kant te installeer. Daar is drie tipes agente: Linux, Windows en VMware.
Die eerste twee word op fisika of op virtuele masjiene op enige nie-VMware-hypervisor geplaas. Daar is geen bykomende konfigurasie hier nodig nie, die agent laai af en weet reeds waar om aan te klop, en letterlik oor 'n minuut sal die motor in die Acura-paneel sigbaar wees. Met die VMware-agent is die situasie 'n bietjie meer ingewikkeld. Die probleem is dat Agent for VMware ook afgelaai word vanaf die portaal wat reeds voorberei is en die nodige konfigurasie het. Maar die VMware-agent moet, benewens kennis van ons Acura-portaal, ook weet van die virtualisasiestelsel waarop dit ontplooi sal word.
Eintlik sal die stelsel ons vra om hierdie data te spesifiseer wanneer jy die VMware-agent die eerste keer aflaai. Die probleem is dat in ons era van universele liefde vir sekuriteit, nie almal hul admin-wagwoord op iemand anders se portaal sal wil aandui nie, wat heel verstaanbaar is. Van binne, na ontplooiing, kan die agent op geen manier gekonfigureer word nie (jy kan net sy netwerkinstellings verander). Hier voorsien ek probleme met veral versigtige kliënte.
Dus, nadat ons die agente geïnstalleer het, kan ons teruggaan na die Acura-paneel en al ons motors sien.
Aangesien ek al meer as 'n dag met die stelsel werk, het ek masjiene in verskeie state. Almal van hulle is in die verstekgroep, maar dit is moontlik om aparte groepe te skep en masjiene na hulle oor te dra, soos jy nodig het. Dit raak niks nie - slegs die logiese voorstelling van data en hul groepering vir geriefliker werk. Die eerste en belangrikste ding wat ons daarna moet doen, is om die migrasieproses te begin. Ons kan dit beide met geweld handmatig doen en 'n skedule opstel, insluitend in grootmaat vir alle masjiene gelyktydig.
Laat ek jou daaraan herinner dat Hystax geposisioneer is as 'n produk vir migrasie. Daarom is dit nie verbasend dat ons 'n DR-plan moet skep om ons gerepliseerde masjiene te laat loop nie. U kan 'n plan skep vir masjiene wat reeds in die gesinkroniseerde toestand is. U kan beide vir een spesifieke VM en vir alle masjiene gelyktydig genereer.
Die stel parameters wanneer 'n DR-plan gegenereer word, sal verskil na gelang van die infrastruktuur waarheen jy gaan migreer. 'n Minimale stel opsies is beskikbaar vir 'n VMware-omgewing. Re-IP vir masjiene word ook nie ondersteun nie. In hierdie verband stel ons belang in die volgende punte: in die beskrywing van die VM, die "subnet"-parameter: "VMNetwork", waar ons die VM aan 'n spesifieke netwerk in die cluster bind. Rang - relevant wanneer verskeie VM's migreer, bepaal die volgorde waarin hulle bekendgestel word. Flavor - beskryf die konfigurasie van die VM, in hierdie geval - 1CPU, 2GB RAM. In die subnet-afdeling definieer ons dat "subnet": "VMNetwork" geassosieer word met die "VM Network" van VMware.
As u 'n DR-plan skep, is daar geen manier om skywe oor verskillende datawinkels te "verdeel" nie. Hulle sal op dieselfde datastoor geleë wees wat vir hierdie kliëntwolk gedefinieer is, en as u skywe van verskillende klasse het, kan dit probleme veroorsaak wanneer u die masjien begin, en nadat u die VM van Hystax begin en "skei" het, sal dit ook vereis 'n aparte migrasieskywe na die vereiste datawinkels. Dan moet ons net ons DR-plan uitvoer en wag dat ons karre opstaan. Die P2V/V2V-omskakelingsproses neem ook tyd. Op my grootste 100GB-toetsmasjien met drie skywe het dit 'n maksimum van 10 minute geneem.
Daarna moet u die lopende VM, dienste daarop, datakonsekwentheid en ander kontrole nagaan.
Ons het dan twee opsies:
- Vee uit - vee 'n lopende DR-plan uit. Hierdie aksie sal eenvoudig die lopende VM afskakel. Hierdie replikas gaan nêrens heen nie.
- Maak los - skeur die gerepliseerde motor van Acura af, d.w.s. voltooi eintlik die migrasieproses.
Voordele van die oplossing:
- gemak van installasie en konfigurasie beide aan die kliënt kant en aan die verskaffer kant;
- gemak van die opstel van migrasie, die skep van 'n DR-plan en die bekendstelling van replikas;
- ondersteuning en ontwikkelaars reageer redelik vinnig op die probleme wat gevind is en maak dit reg met platform- of agentopdaterings.
Nadele
- Onvoldoende Vmware-ondersteuning.
- Die afwesigheid van enige kwota vir huurders vanaf die platform.
Ek het ook 'n kenmerkversoek gedoen, wat ons aan die verkoper oorhandig het:
- gebruiksmonitering en -ontplooiing vanaf die Acura Management Console for Cloud Agents;
- beskikbaarheid van kwotas vir huurders;
- die vermoë om die aantal gelyktydige herhalings en spoed vir elke huurder te beperk;
- ondersteuning vir VMware vCloud Director;
- ondersteuning vir hulpbronpoele (is tydens toetsing geïmplementeer);
- die vermoë om die VMware-agent vanaf die kant van die agent self te konfigureer, sonder om geloofsbriewe vanaf die kliëntinfrastruktuur in die Acura-paneel in te voer;
- "Visualisering" van die proses om 'n VM te begin wanneer 'n DR-plan begin word.
Die enigste ding wat vir my groot klagtes veroorsaak het, was die dokumentasie. Ek hou nie regtig van "swart bokse" nie en verkies wanneer daar gedetailleerde dokumentasie is oor hoe die produk binne werk. En as die produk vir AWS en OpenStack nog min of meer beskryf word, dan is daar vir VMware baie min dokumentasie.
Daar is 'n installasiegids wat slegs die ontplooiing van die Acura-paneel beskryf, en waar daar nie 'n woord is oor die behoefte aan 'n Wolk-agent nie. Daar is 'n volledige stel spesifikasies vir die produk, wat goed is. Daar is dokumentasie wat die opstelling "van en na" beskryf deur AWS en OpenStack as 'n voorbeeld te gebruik (alhoewel dit my meer aan 'n blogpos herinner), en daar is 'n baie klein Knowledge Base.
Oor die algemeen is dit nie heeltemal die dokumentasieformaat waaraan ek gewoond is nie, byvoorbeeld van groter verskaffers, so ek was nie heeltemal gemaklik nie. Terselfdertyd het ek nie antwoorde gevind oor sommige van die nuanses van die stelsel se werking "binne" in hierdie dokumentasie nie - ek moes baie vrae met tegniese ondersteuning uitklaar, en dit het eerder die proses van die ontplooiing van die staanplek en toets.
Samevattend kan ek sê dat ek oor die algemeen van die produk en die maatskappy se benadering tot die implementering van die taak gehou het. Ja, daar is foute, daar is 'n baie kritieke gebrek aan funksionaliteit (in samewerking met VMware). Dit kan gesien word dat die maatskappy in die eerste plek steeds fokus op openbare wolke, veral AWS, en vir sommige sal dit genoeg wees. Om vandag so 'n eenvoudige en gerieflike produk te hê, wanneer baie maatskappye 'n multi-wolk-strategie kies, is uiters belangrik. Gegewe die baie laer prys in vergelyking met mededingers, maak dit die produk uiters aantreklik.
Ons soek 'n span . Miskien is dit jy?
Bron: will.com