Salah sahiji pamaén ngora di pasar solusi Disaster Recovery nyaéta Hystax, ngamimitian Rusia di 2016. Kusabab topik pamulihan bencana populer pisan sareng pasar pisan kompetitif, ngamimitian mutuskeun pikeun difokuskeun migrasi antara infrastruktur awan anu béda. Produk anu ngamungkinkeun anjeun ngatur migrasi anu saderhana sareng gancang ka méga bakal mangpaat pisan pikeun palanggan Onlanta - pangguna . Éta kumaha kuring terang Hystax sareng ngamimitian nguji fitur-fiturna. Sareng naon anu sumping, kuring bakal nyarios dina tulisan ieu.
Fitur utama Hystax nyaéta fungsionalitas anu lega pikeun ngadukung rupa-rupa platform virtualisasi, OS tamu sareng jasa awan, anu ngamungkinkeun anjeun mindahkeun beban kerja anjeun ti mana waé sareng dimana waé.
Ieu ngidinan Anjeun pikeun nyieun teu ukur DR solusi pikeun ngaronjatkeun kasabaran sesar tina jasa, tapi ogé gancang, flexibly migrasi sumberdaya antara situs béda jeung hyperscalers pikeun ngaronjatkeun tabungan ongkos tur pilih solusi pangalusna pikeun layanan tinangtu dina momen. Salian platform anu didaptarkeun dina gambar judul, perusahaan ogé aktip gawé bareng sareng panyadia awan Rusia: Yandex.Cloud, CROC Cloud Services, Mail.ru sareng seueur anu sanésna. Perhatos ogé yén dina 2020 perusahaan dibuka pusat R&D anu aya di Skolkovo.
Pilihan hiji solusi ku angka nu gede ngarupakeun pamaén dina pasaran nunjukkeun kawijakan harga alus tur applicability tinggi produk, nu urang mutuskeun pikeun nguji dina praktekna.
Janten, tugas uji kami bakal diwangun ku migrasi ti situs uji VMware kuring sareng mesin fisik ka situs panyadia ogé ngajalankeun VMware. Leres, aya seueur solusi anu tiasa ngalaksanakeun migrasi sapertos kitu, tapi kami nganggap Hystax salaku alat universal, sareng nguji migrasi dina sadaya kombinasi anu mungkin ngan saukur tugas anu teu realistis. Leres, sareng awan Oncloud.ru diwangun khusus dina VMware, janten platform ieu, salaku udagan, dipikaresep ku urang langkung ageung. Salajengna, kuring bakal ngajelaskeun prinsip dasar operasi, anu sacara gembleng henteu gumantung kana platform, sareng VMware tiasa digentos tina sisi mana waé sareng platform ti vendor anu sanés.
Léngkah munggaran nyaéta nyebarkeun Hystax Acura, nyaéta panel kontrol sistem.
Ieu expands ti citakan. Kanggo sababaraha alesan, dina hal urang, éta henteu leres-leres leres sareng tibatan 8CPU anu disarankeun, 16Gb disebarkeun kalayan satengah sumberdaya. Ku alatan éta, anjeun teu kudu poho pikeun ngarobah éta, disebutkeun infrastruktur di jero VM, nu sagalana geus diwangun, ngan moal dimimitian ku peti jeung portal bakal sadia. DI sumberdaya diperlukeun digambarkeun di jéntré, kitu ogé palabuhan pikeun sakabéh komponén sistem.
Sareng aya ogé kasusah sareng netepkeun alamat IP ngalangkungan citakan, ku kituna kami robih tina konsol. Saatos éta, anjeun tiasa angkat ka antarmuka wéb admin sareng ngalengkepan wizard konfigurasi awal.
Endpoint - IP atanapi FQDN tina vCenter kami.
Login sareng Sandi - éta jelas di dieu.
Target ESXi hostname mangrupakeun salah sahiji host dina klaster urang nu bakal replicated ka.
Target datastore mangrupikeun salah sahiji datastores dina kluster urang anu bakal direplikasi.
Hystax Acura Control Panel Public IP - alamat dimana panel kontrol bakal sayogi.
A klarifikasi saeutik dina host na datastore diperlukeun. Kanyataanna nyaéta réplikasi Hystax tiasa dianggo dina tingkat host sareng datastore. Salajengna, abdi bakal ngabejaan ka maneh kumaha anjeun bisa ngarobah host na datastore pikeun tenant nu, tapi masalahna béda. Hystax teu ngarojong pooling sumberdaya, i.e. replica bakal salawasna kajadian ka akar klaster (dina waktu nulis bahan ieu, guys ti Hystax ngarilis versi diropéa, dimana maranéhna gancang dilaksanakeun pamundut fitur abdi ngeunaan rojongan pikeun pools sumberdaya). Ogé vCloud Diréktur teu dirojong, nyaéta. lamun, sakumaha dina kasus kuring, tenant nu teu boga hak admin pikeun sakabéh klaster, tapi ngan ka kolam renang sumberdaya husus, sarta kami masihan aksés ka Hystax, lajeng anjeunna bakal tiasa bebas ngayakeun réplikasi tur ngajalankeun VMs ieu, tapi anjeunna bakal. teu bisa ningali aranjeunna dina infrastruktur VMware , nu anjeunna boga aksés jeung, sasuai, salajengna ngatur mesin virtual. Administrator klaster kedah ngalihkeun VM ka sumber daya anu leres atanapi ngimpor kana Diréktur vCloud.
Naha kuring museurkeun pisan kana momen ieu? Kusabab, sajauh kuring ngartos konsép produk, nasabah kedah tiasa mandiri ngalaksanakeun migrasi atanapi DR nganggo panel Acura. Tapi sajauh ieu, pangrojong VMware rada tinggaleun tingkat dukungan pikeun OpenStack anu sami, dimana mékanisme sapertos kitu parantos dilaksanakeun.
Tapi balik deui ka deployment. Anu mimiti, saatos setelan awal panel, urang kedah nyiptakeun panyewa munggaran dina sistem urang.
Sadaya widang di dieu jelas, abdi ngan bakal ngabejaan Anjeun tentang widang Awan. Urang geus boga "standar" awan nu urang dijieun salila konfigurasi awal. Tapi upami urang hoyong tiasa nempatkeun unggal panyewa dina datastore sorangan sareng di kolam renang sumberdaya sorangan, urang tiasa ngalaksanakeun ieu ku nyiptakeun awan anu misah pikeun unggal konsumén urang.
Dina bentuk nambahkeun awan anyar, urang tangtukeun parameter anu sarua sakumaha dina mangsa konfigurasi awal (urang malah bisa ngagunakeun host anu sarua), tangtukeun datastore diperlukeun pikeun customer husus, sarta ayeuna dina parameter tambahan urang geus bisa nangtukeun individual. diperlukeun sumberdaya kolam renang {"resource_pool" : "YOUR_POOL_NAME"}
Sakumaha anjeun tiasa perhatikeun, dina bentuk nyiptakeun panyewa teu aya nanaon ngeunaan alokasi sumber daya atanapi sababaraha jenis kuota - teu aya nanaon ieu dina sistem. Anjeun teu bisa ngawatesan tenant dina Jumlah réplika simultaneous, jumlah mesin pikeun réplikasi, atawa ku parameter séjén. Janten, kami parantos nyiptakeun panyewa munggaran. Ayeuna aya hal anu henteu logis, tapi wajib - masang agén Cloud. Éta henteu logis, sabab agén diunduh dina halaman palanggan khusus.
Dina waktos anu sami, éta henteu dihijikeun ka panyewa anu diciptakeun, sareng sadaya palanggan urang bakal ngaliwat éta (atanapi saatos sababaraha, upami urang nyebarkeunana). Hiji agén ngarojong 10 sesi simultaneous. Hiji sési diitung salaku hiji mobil. Henteu masalah sabaraha disk eta boga. Nepi ka ayeuna, teu aya mékanisme pikeun agén skala di Acura sorangan pikeun VMware. Aya hiji deui momen pikaresepeun - urang teu bisa nempo "utilization" agén ieu ti panel Acura dina urutan pikeun menyimpulkan naha urang kudu nyebarkeun leuwih atawa instalasi ayeuna cukup. Hasilna, stand kasampak kawas kieu:
Léngkah salajengna pikeun ngaksés portal palanggan kami nyaéta nyiptakeun akun (sareng mimiti, ogé peran anu bakal diterapkeun ka pangguna ieu).
Ayeuna palanggan urang tiasa nganggo portal sacara mandiri. Sadaya anu anjeunna kedah laksanakeun nyaéta unduh agén tina portal sareng pasang di sisi na. Aya tilu jinis agén: Linux, Windows, sareng VMware.
Dua anu munggaran dipasang dina fisika atanapi dina mesin virtual dina hypervisor non-VMware. Henteu aya konfigurasi tambahan anu diperyogikeun di dieu, agén ngaunduh sareng parantos terang dimana sambel, sareng sacara harfiah dina sakedap mobil bakal katingali dina panel Acura. Kalawan agén VMware, kaayaan téh saeutik leuwih pajeulit. Masalahna nyaéta Agen pikeun VMware ogé diunduh tina portal anu parantos disiapkeun sareng gaduh konfigurasi anu diperyogikeun. Tapi agén VMware, salian terang ngeunaan portal Acura kami, ogé kedah terang ngeunaan sistem virtualisasi dimana éta bakal disebarkeun.
Sabenerna, sistem bakal naroskeun kami pikeun nangtukeun data ieu nalika anjeun mimiti ngaunduh agén VMware. Masalahna nyaeta dina umur urang cinta universal pikeun kaamanan, teu sadaya jelema bakal hoyong nunjukkeun sandi admin maranéhanana dina portal batur, nu rada kaharti. Ti jero, sanggeus deployment, agén teu bisa ngonpigurasi sagala cara (anjeun ngan bisa ngarobah setelan jaringan na). Di dieu kuring foresee kasusah jeung konsumén utamana cautious.
Janten, saatos masang agén, urang tiasa uih deui ka panel Acura sareng ningali sadaya mobil urang.
Kusabab kuring geus gawé bareng sistem pikeun leuwih ti sapoé, Kuring boga mesin di sagala rupa nagara bagian. Sakabéh éta dina grup Default, tapi kasebut nyaéta dimungkinkeun pikeun nyieun grup misah tur mindahkeun mesin ka aranjeunna, sakumaha nu peryogi. Ieu teu mangaruhan nanaon - ngan ngagambarkeun logis data jeung grup maranéhna pikeun gawé leuwih merenah. Hal kahiji jeung pangpentingna urang kudu ngalakukeun sanggeus éta pikeun ngamimitian prosés migrasi. Urang tiasa ngalakukeun ieu duanana forcibly sacara manual, tur nyetel jadwal a, kaasup dina bulk pikeun sakabéh mesin sakaligus.
Hayu atuh ngingetan yén Hystax diposisikan salaku produk pikeun migrasi. Ku alatan éta, teu heran mun ngajalankeun mesin replicated urang, urang kudu nyieun rencana DR. Anjeun tiasa nyieun rencana pikeun mesin anu geus dina kaayaan Synced. Anjeun tiasa ngahasilkeun duanana pikeun hiji VM husus, sarta pikeun sakabéh mesin sakaligus.
Set parameter nalika ngahasilkeun rencana DR bakal béda-béda gumantung kana infrastruktur anu anjeun badé migrasi. Hiji set minimal tina pilihan sadia pikeun lingkungan VMware. Re-IP pikeun mesin ogé teu dirojong. Dina hal ieu, urang museurkeun titik di handap ieu: dina pedaran VM, "subnet" parameter: "VMNetwork", dimana urang meungkeut VM ka jaringan husus dina klaster. Rengking - relevan nalika migrasi sababaraha VM, nangtukeun urutan dimana aranjeunna diluncurkeun. Flavor ngajelaskeun konfigurasi VM, dina hal ieu 1CPU, 2GB RAM. Dina bagian subnets, urang nangtukeun yén "subnet": "VMNetwork" pakait sareng "VM Network" tina VMware.
Nalika nyieun rencana DR, teu aya deui jalan pikeun "meulah" disk di toko data anu béda. Éta bakal ayana dina datastore sarua nu ditetepkeun pikeun awan klien ieu, sarta lamun boga disk tina kelas béda, ieu bisa ngabalukarkeun sababaraha kasusah nalika ngamimitian mesin, sarta sanggeus dimimitian tur "misahkeun" VM ti Hystax, éta ogé bakal. merlukeun hiji disk migrasi misah ka datastores diperlukeun. Teras urang kedah ngajalankeun rencana DR urang sareng ngantosan mobil urang naék. Prosés konversi P2V/V2V ogé butuh waktu. Dina mesin uji 100GB panggedéna sareng tilu disk, ieu nyandak maksimal 10 menit.
Saatos éta, anjeun kedah parios VM anu ngajalankeun, jasa dina éta, konsistensi data sareng cek anu sanés.
Urang lajeng boga dua pilihan:
- Hapus - ngahapus rencana DR jalan. Peta ieu ngan saukur bakal mareuman VM jalan. Réplika ieu henteu kamana-mana.
- Copot - cimata mobil replicated ti Acura, i.e. sabenerna ngalengkepan prosés migrasi.
Kaunggulan tina solusi:
- betah instalasi tur konfigurasi duanana di sisi klien tur di sisi panyadia;
- betah nyetel migrasi, nyieun rencana DR jeung launching réplika;
- rojongan tur pamekar ngabales rada gancang kana masalah kapanggih sarta ngalereskeun aranjeunna kalayan platform atawa apdet agén.
Минусы
- Henteu cekap dukungan Vmware.
- Henteuna kuota kanggo panyewa tina platform.
Kuring ogé ngadamel Paménta Fitur, anu kami pasrahkeun ka anu ngajual:
- ngawaskeun pamakean sareng panyebaran tina Konsol Manajemén Acura pikeun Agén Awan;
- kasadiaan kuota pikeun panyewa;
- kamampuhan pikeun ngawatesan jumlah réplikasi simultaneous sarta speed pikeun tiap tenant;
- rojongan pikeun VMware vCloud Diréktur;
- rojongan pikeun pools sumberdaya (ieu dilaksanakeun salila nguji);
- kamampuhan pikeun ngonpigurasikeun agén VMware ti sisi agén sorangan, tanpa ngasupkeun Kapercayaan ti infrastruktur klien dina panel Acura;
- "Visualisasi" prosés ngamimitian VM nalika ngamimitian rencana DR.
Hiji-hijina hal anu nyababkeun kuring keluhan ageung nyaéta dokuméntasi. Abdi henteu resep "kotak hideung" sareng langkung resep nalika aya dokuméntasi lengkep ngeunaan kumaha produkna dianggo di jero. Sareng upami pikeun AWS sareng OpenStack produkna dijelaskeun langkung seueur atanapi kirang, maka pikeun VMware aya sakedik dokuméntasi.
Aya hiji Guide Instalasi nu ngajelaskeun ukur deployment tina panel Acura, na dimana teu aya kecap ngeunaan butuh agén Awan. Aya set pinuh ku spésifikasi pikeun produk, nu alus. Aya dokuméntasi anu ngajelaskeun setelan "ti jeung ka" ngagunakeun AWS na OpenStack sabagé conto (sanajan reminds kuring leuwih ti hiji pos blog), sarta aya pisan leutik Pangaweruh Base.
Sacara umum, ieu teu cukup format dokuméntasi anu kuring biasa, sebutkeun, ti ngical paralatan gedé, jadi kuring teu sagemblengna nyaman. Dina waktos anu sami, kuring henteu mendakan jawaban ngeunaan sababaraha nuansa operasi sistem "di jero" dina dokuméntasi ieu - kuring kedah netelakeun seueur patarosan kalayan dukungan téknis, sareng ieu rada nyeret prosés panyebaran stand sareng nguji.
Nyimpulkeun, abdi tiasa nyebatkeun yén sacara umum kuring resep produk sareng pendekatan perusahaan pikeun palaksanaan tugas. Sumuhun, aya flaws, aya kakurangan bener kritis fungsionalitas (dibarengan ku VMware). Éta tiasa katingali yén, mimitina, perusahaan masih museurkeun kana awan umum, khususna AWS, sareng pikeun sababaraha ieu bakal cekap. Gaduh produk anu saderhana sareng gampang ayeuna, nalika seueur perusahaan milih strategi multi-awan, penting pisan. Dibikeun harga anu langkung handap dibandingkeun pesaing, ieu ngajantenkeun produkna pikaresepeun pisan.
Kami milarian tim . Meureun éta anjeun?
sumber: www.habr.com