Disaster Recovery həlləri bazarında gənc oyunçulardan biri 2016-cı ildən Rusiya startapı olan Hystax-dır. Fəlakətin bərpası mövzusu çox populyar olduğundan və bazar son dərəcə rəqabətli olduğundan, startap müxtəlif bulud infrastrukturları arasında miqrasiyaya diqqət yetirmək qərarına gəlib. Buluda sadə və sürətli miqrasiyanı təşkil etməyə imkan verən məhsul Onlanta müştəriləri - istifadəçilər üçün də çox faydalı olardı. . Beləliklə, mən Hystax ilə tanış oldum və onun imkanlarını sınamağa başladım. Bunun nədən gəldiyini bu məqalədə sizə deyəcəyəm.
Hystax-ın əsas xüsusiyyəti onun müxtəlif virtuallaşdırma platformalarını, qonaq əməliyyat sistemlərini və bulud xidmətlərini dəstəkləmək üçün geniş funksionallığıdır ki, bu da iş yüklərinizi istənilən yerdən, istənilən yerdən ötürməyə imkan verir.
Bu, xidmətlərin nasazlığa dözümlülüyünü artırmaq üçün təkcə DR həlləri yaratmağa deyil, həm də xərclərə qənaəti artırmaq və müəyyən bir anda konkret xidmət üçün ən yaxşı həlli seçmək üçün müxtəlif saytlar və hiperskalerlər arasında resursları tez və çevik köçürməyə imkan verir. Başlıq şəklində sadalanan platformalara əlavə olaraq, şirkət Rusiyanın bulud provayderləri ilə də fəal əməkdaşlıq edir: Yandex.Cloud, CROC Cloud Services, Mail.ru və bir çox başqaları. Onu da qeyd etmək lazımdır ki, 2020-ci ildə şirkət Skolkovoda yerləşən Ar-Ge mərkəzini açıb.
Bazarda çoxlu sayda oyunçu tərəfindən bir həll seçimi yaxşı qiymət siyasətini və praktikada sınaqdan keçirməyə qərar verdiyimiz məhsulun yüksək tətbiqini göstərir.
Beləliklə, test tapşırığımız mənim VMware test saytımdan və fiziki maşınlarımdan VMware tərəfindən idarə olunan provayderin saytına köçməkdən ibarət olacaq. Bəli, belə bir köçürməni həyata keçirə biləcək bir çox həll yolu var, lakin biz Hystax-ı universal bir vasitə hesab edirik və miqrasiyanın bütün mümkün birləşmələrdə sınaqdan keçirilməsi sadəcə olaraq qeyri-real bir işdir. Oncloud.ru buludu isə xüsusi olaraq VMware üzərində qurulub, ona görə də bu platforma hədəf kimi bizi daha çox maraqlandırır. Sonra, ümumiyyətlə platformadan asılı olmayan əsas iş prinsipini təsvir edəcəyəm və istənilən tərəfdən VMware başqa bir satıcının platforması ilə əvəz edilə bilər.
İlk addım sistemin idarəetmə paneli olan Hystax Acura-nı yerləşdirməkdir.
Şablondan açılır. Nədənsə, bizim vəziyyətimizdə bu tamamilə düzgün deyildi və tövsiyə olunan 8CPU əvəzinə 16Gb resursların yarısı ilə yerləşdirildi. Buna görə də, onları dəyişdirməyi xatırlamaq lazımdır, əks halda hər şeyin qurulduğu VM daxilində konteyner infrastrukturu sadəcə işə düşməyəcək və portal əlçatmaz olacaq. IN Tələb olunan resurslar, eləcə də bütün sistem komponentləri üçün portlar ətraflı təsvir edilmişdir.
Şablon vasitəsilə IP ünvanını təyin etməkdə də çətinliklər var idi, ona görə də onu konsoldan dəyişdirdik. Bundan sonra, admin veb interfeysinə keçə və ilkin konfiqurasiya sihirbazını tamamlaya bilərsiniz.
Son nöqtə – vCenterimizin IP və ya FQDN.
Giriş və Şifrə - bu aydındır.
Hədəf ESXi hostname replikasiyanın həyata keçiriləcəyi klasterimizdəki hostlardan biridir.
Hədəf məlumat anbarı replikasiyanın həyata keçiriləcəyi klasterimizdəki məlumat anbarlarından biridir.
Hystax Acura İdarəetmə Paneli İctimai IP – idarəetmə panelinin mövcud olacağı ünvan.
Host və məlumat anbarı ilə bağlı bir az aydınlıq tələb olunur. Fakt budur ki, Hystax replikasiyası host və məlumat anbarı səviyyəsində işləyir. Sonra sizə kirayəçi üçün host və məlumat anbarını necə dəyişə biləcəyinizi söyləyəcəyəm, lakin problem fərqlidir. Hystax resurs hovuzları ilə işləməyi dəstəkləmir, yəni. replika həmişə klasterin kökünə gedəcək (bu materialı yazarkən Hystax-dan olan uşaqlar yenilənmiş versiyanı buraxdılar, burada resurs hovuzlarına dəstək ilə bağlı xüsusiyyət tələbimi tez bir zamanda həyata keçirdilər). vCloud Director də dəstəklənmir, yəni. mənim vəziyyətimdə olduğu kimi, kirayəçinin bütün klasterə deyil, yalnız müəyyən bir resurs hovuzuna admin hüquqları varsa və biz Hystax-a giriş icazəsi vermişiksə, o, bu VM-ləri müstəqil şəkildə təkrarlaya və işə sala biləcək, lakin onları VMware infrastrukturunda görə bilmir, onun daxil olduğu və müvafiq olaraq virtual maşınları daha da idarə edir. Klaster administratorunun VM-ni istədiyiniz resurs hovuzuna köçürməsi və ya onu vCloud Director-a idxal etməsi lazımdır.
Niyə bu məqamlara bu qədər diqqət yetirirəm? Çünki məhsulun konsepsiyasını başa düşdüyüm qədər, müştəri Acura panelindən istifadə edərək istənilən miqrasiya və ya DR-ni müstəqil şəkildə həyata keçirə bilməlidir. Lakin indiyə qədər VMware dəstəyi oxşar mexanizmlərin artıq tətbiq olunduğu OpenStack üçün dəstək səviyyəsindən bir qədər geridədir.
Ancaq yerləşdirməyə qayıdaq. Əvvəla, panelin ilkin qurulmasından sonra sistemimizdə ilk kirayəçi yaratmalıyıq.
Buradakı bütün sahələr aydındır, mən sizə yalnız Bulud sahəsi haqqında məlumat verəcəyəm. Artıq ilkin konfiqurasiya zamanı yaratdığımız "defolt" buludumuz var. Ancaq hər bir icarəçini öz məlumat anbarına və öz resurs hovuzuna yerləşdirmək istəyiriksə, hər bir müştərimiz üçün ayrıca buludlar yaradaraq bunu həyata keçirə bilərik.
Yeni bulud əlavə etmək üçün formada biz ilkin konfiqurasiya zamanı olduğu kimi eyni parametrləri təyin edirik (hətta eyni hostdan istifadə edə bilərik), müəyyən bir müştəri üçün tələb olunan məlumat anbarını göstəririk və indi əlavə parametrlərdə tələb olunan resursu fərdi olaraq təyin edə bilərik. hovuz {"resource_pool" : "YOUR_POOL_NAME"}
Diqqət etdiyiniz kimi, kirayəçinin yaradılması formasında resurs bölgüsü və ya hər hansı kvota haqqında heç bir şey yoxdur - sistemdə bunların heç biri yoxdur. İcarəçini eyni vaxtda replikaların sayı, təkrarlama üçün maşınların sayı və ya hər hansı digər parametrlərlə məhdudlaşdırmaq mümkün deyil. Beləliklə, ilk kirayəni yaratdıq. İndi tamamilə məntiqli deyil, məcburi bir şey var - Bulud agentinin quraşdırılması. Bu məntiqsizdir, çünki agent konkret müştərinin səhifəsində yüklənir.
Eyni zamanda, o, yaradılan kirayəçiyə bağlı deyil və bütün müştərilərimiz onun vasitəsilə işləyəcəklər (və ya bir neçəsi vasitəsilə, əgər biz onları yerləşdirsək). Bir agent 10 eyni vaxtda seansı dəstəkləyir. Bir maşın bir seans kimi sayılır. Nə qədər diskin olmasının əhəmiyyəti yoxdur. Bu günə qədər, VMware altında Acura-nın özündə agentləri miqyaslaşdırmaq üçün heç bir mexanizm yoxdur. Daha bir xoşagəlməz məqam var - daha çox yerləşdirməyə ehtiyacımız olub-olmaması və ya hazırkı quraşdırmanın kifayət olub-olmadığı barədə nəticə çıxarmaq üçün bu agentin Acura panelindən "satılmasına" baxmaq imkanımız yoxdur. Nəticədə stend belə görünür:
Müştəri portalımıza daxil olmaq üçün növbəti addım hesab yaratmaqdır (və ilk növbədə bu istifadəçiyə aid olacaq rol).
Artıq müştərimiz portaldan müstəqil istifadə edə bilər. Onun etməli olduğu yeganə şey agentləri portaldan yükləmək və onu öz tərəfinə quraşdırmaqdır. Üç növ agent var: Linux, Windows və VMware.
İlk ikisi fizikada və ya VMware-dən başqa istənilən hipervizorda virtual maşınlarda quraşdırılır. Əlavə bir şey konfiqurasiya etməyə ehtiyac yoxdur, agent yüklənir və artıq harada döyüləcəyini bilir və bir dəqiqədən sonra avtomobil Acura panelində görünəcək. VMware agenti ilə vəziyyət bir az daha mürəkkəbdir. Problem ondadır ki, VMware üçün agent də artıq hazırlanmış və lazımi konfiqurasiyaya malik portaldan yüklənir. Lakin bizim Acura portalımız haqqında bilməklə yanaşı, VMware agenti onun yerləşdiriləcəyi virtuallaşdırma sistemi haqqında da bilməlidir.
Əslində, VMware agentini ilk dəfə yükləyəndə sistem bizdən bu məlumatları təqdim etməyimizi xahiş edəcək. Problem ondadır ki, təhlükəsizliyə ümumbəşəri məhəbbət əsrimizdə hamı öz admin parolunu başqasının portalında göstərmək istəməz, bu olduqca başa düşüləndir. İçəridən, yerləşdirmədən sonra agent heç bir şəkildə konfiqurasiya edilə bilməz (yalnız onun şəbəkə parametrlərini dəyişə bilərsiniz). Burada xüsusilə ehtiyatlı müştərilərlə çətinliklərin olduğunu görürəm.
Beləliklə, agentləri quraşdırdıqdan sonra Acura panelinə qayıdıb bütün avtomobillərimizi görə bilərik.
Artıq bir neçə gündür ki, sistemlə işlədiyim üçün müxtəlif ştatlarda avtomobillərim var. Məndə onların hamısı Default qrupunda var, lakin ayrı-ayrı qruplar yaradaraq onlara lazım olan kimi maşınları köçürmək mümkündür. Bu, heç bir şeyə təsir etmir - yalnız məlumatların məntiqi təqdimatı və daha rahat iş üçün onların qruplaşdırılması. Bundan sonra etməli olduğumuz ilk və ən vacib şey miqrasiya prosesinə başlamaqdır. Biz bunu ya əllə, ya da bütün maşınlar üçün toplu da daxil olmaqla bir cədvəl qurmaqla edə bilərik.
Nəzərinizə çatdırım ki, Hystax miqrasiya məhsulu kimi yerləşdirilmişdi. Buna görə də, təkrarlanan maşınlarımızı işə salmaq üçün DR planı yaratmağımız təəccüblü deyil. Plan artıq Sinxronlaşdırılmış vəziyyətdə olan maşınlar üçün hazırlana bilər. Siz həm bir xüsusi VM, həm də bütün maşınlar üçün eyni anda yarada bilərsiniz.
DR planını yaradan zaman parametrlər toplusu köçəcəyiniz infrastrukturdan asılı olaraq fərqlənəcək. VMware mühiti üçün minimal parametrlər dəsti mövcuddur. Maşınlar üçün yenidən IP də dəstəklənmir. Bu baxımdan bizi aşağıdakı məqamlar maraqlandırır: VM təsvirində “alt şəbəkə” parametri: “VMNetwork”, burada biz VM-ni klasterdəki xüsusi şəbəkəyə bağlayırıq. Rank – bir neçə VM-i köçürərkən müvafiqdir; onların işə salınma sırasını müəyyən edir. Flavor – VM konfiqurasiyasını təsvir edir, bu halda – 1CPU, 2GB RAM. Alt şəbəkələr bölməsində biz müəyyən edirik ki, "alt şəbəkə": "VMNetwork" VMware "VM Network" ilə əlaqələndirilir.
DR planı yaratarkən diskləri müxtəlif məlumat anbarlarında "yaymaq" üçün heç bir yol yoxdur. Onlar bu müştəri buludu üçün müəyyən edilmiş eyni məlumat anbarında yerləşəcək və müxtəlif sinif diskləriniz varsa, bu, maşını işə salarkən bəzi çətinliklərə səbəb ola bilər və VM-i işə saldıqdan və Hystax-dan “ayırdıqdan” sonra o, həmçinin tələb olunan məlumat anbarlarına ayrıca köçürmə diskləri tələb edir. Sonra etməli olduğumuz tək şey DR planımızı işə salmaq və avtomobillərimizin yüksəlməsini gözləməkdir. P2V/V2V çevrilmə prosesi də vaxt aparır. Ən böyük sınaq maşınımda, üç diskli 100 GB, maksimum 10 dəqiqə çəkdi.
Bundan sonra, işləyən VM-i, üzərindəki xidmətləri, məlumatların ardıcıllığını yoxlamalı və digər yoxlamaları həyata keçirməlisiniz.
Sonra iki yolumuz var:
- Sil - işləyən DR planını silin. Bu hərəkət sadəcə işləyən VM-ni bağlayacaq. Bu replikalar heç yerə getmir.
- Detach – təkrarlanan avtomobili Acura-dan qoparın, yəni. əslində miqrasiya prosesini tamamlayır.
Həllin üstünlükləri:
- həm müştəridən, həm də provayderdən quraşdırma və konfiqurasiya asanlığı;
- miqrasiyanın qurulması, DR planının yaradılması və replikaların işə salınması asanlığı;
- dəstək və tərtibatçılar tapılan problemlərə olduqca tez cavab verir və platforma və ya agent yeniləmələrindən istifadə edərək onları həll edir.
Eksiler
- Qeyri-kafi Vmware dəstəyi.
- Platformadan kirayəçilər üçün heç bir kvotanın olmaması.
Mən həmçinin satıcıya təqdim etdiyimiz Xüsusiyyət Sorğunu tərtib etdim:
- Bulud agentləri üçün Acura idarəetmə konsolundan istifadə monitorinqi və yerləşdirmə;
- kirayəçilər üçün kvotaların mövcudluğu;
- hər bir kirayəçi üçün eyni vaxtda təkrarlamaların sayını və sürəti məhdudlaşdırmaq imkanı;
- VMware vCloud Director dəstəyi;
- resurs hovuzlarına dəstək (sınaq zamanı həyata keçirilir);
- Acura panelində müştəri infrastrukturundan etimadnaməsini daxil etmədən VMware agentini agentin özündən konfiqurasiya etmək imkanı;
- DR planını işlədən zaman VM işəsalma prosesinin “vizuallaşdırılması”.
Mənə böyük tənqidi səbəb olan yeganə şey sənədlər idi. Mən "qara qutuları" çox sevmirəm və məhsulun içərisində necə işlədiyinə dair ətraflı sənədlər olduqda üstünlük verirəm. AWS və OpenStack üçün məhsul daha çox və ya daha az təsvir edilirsə, VMware üçün çox az sənəd var.
Yalnız Acura panelinin yerləşdirilməsini təsvir edən Quraşdırma Bələdçisi var və Bulud agentinin də lazım olduğu barədə bir söz yoxdur. Məhsulun texniki xüsusiyyətlərinin tam dəsti var, bu yaxşıdır. Nümunə olaraq AWS və OpenStack-dən istifadə edərək quraşdırmanı "başdan-başa" təsvir edən sənədlər var (baxmayaraq ki, bu, mənə daha çox bloq yazısı kimi görünür) və çox kiçik Bilik Bazası var.
Ümumiyyətlə, bu, məsələn, daha böyük satıcılardan alışdığım sənədləşdirmə formatı deyil, ona görə də mən tamamilə rahat deyildim. Eyni zamanda, bu sənədlərdə sistemin "daxili" necə işlədiyinə dair bəzi nüanslar haqqında heç vaxt cavab tapa bilmədim - bir çox suallara texniki dəstək ilə aydınlıq gətirilməli idi və bu, stendi yerləşdirmə və aparma prosesini xeyli gecikdirdi. sınaq.
Ümumilikdə deyə bilərəm ki, ümumilikdə məhsulu və şirkətin işə yanaşmasını bəyəndim. Bəli, çatışmazlıqlar var, həqiqətən kritik funksional çatışmazlıq var (VMware ilə əlaqədar). Aydındır ki, ilk növbədə, şirkət hələ də ictimai buludlara, xüsusən də AWS-ə diqqət yetirir və bəziləri üçün bu kifayət edəcəkdir. Bir çox şirkətin çoxlu bulud strategiyasını seçdiyi bu gün belə sadə və rahat məhsula sahib olmaq son dərəcə vacibdir. Rəqiblərlə müqayisədə çox aşağı qiymət nəzərə alınmaqla, bu, məhsulu olduqca cəlbedici edir.
Komanda üzvü axtarırıq . Bəlkə sənsən?
Mənbə: www.habr.com