Salah satu pemain muda dalam pasaran untuk penyelesaian Pemulihan Bencana ialah Hystax, syarikat permulaan Rusia dari 2016. Memandangkan topik pemulihan bencana sangat popular dan pasaran sangat kompetitif, syarikat permulaan memutuskan untuk menumpukan pada penghijrahan antara infrastruktur awan yang berbeza. Produk yang membolehkan anda mengatur pemindahan mudah dan cepat ke awan juga akan sangat berguna untuk pelanggan Onlanta - pengguna . Begitulah cara saya berkenalan dengan Hystax dan mula menguji keupayaannya. Saya akan memberitahu anda apa yang berlaku dalam artikel ini.
Ciri utama Hystax ialah kefungsiannya yang luas untuk menyokong pelbagai platform virtualisasi, sistem pengendalian tetamu dan perkhidmatan awan, yang memungkinkan untuk memindahkan beban kerja anda dari mana-mana, di mana-mana sahaja.
Ini membolehkan anda mencipta bukan sahaja penyelesaian DR untuk meningkatkan toleransi kesalahan perkhidmatan, tetapi juga untuk memindahkan sumber dengan cepat dan fleksibel antara tapak dan hyperscaler yang berbeza untuk meningkatkan penjimatan kos dan memilih penyelesaian terbaik untuk perkhidmatan tertentu pada masa tertentu. Sebagai tambahan kepada platform yang disenaraikan dalam gambar tajuk, syarikat itu juga secara aktif bekerjasama dengan penyedia awan Rusia: Yandex.Cloud, Perkhidmatan Awan CROC, Mail.ru dan banyak lagi. Perlu juga diperhatikan bahawa pada tahun 2020 syarikat itu membuka pusat R&D yang terletak di Skolkovo.
Pilihan satu penyelesaian oleh sebilangan besar pemain di pasaran menunjukkan dasar penetapan harga yang baik dan kebolehgunaan produk yang tinggi, yang kami memutuskan untuk menguji dalam amalan.
Jadi, tugas ujian kami akan terdiri daripada pemindahan dari tapak ujian VMware saya dan mesin fizikal ke tapak pembekal, juga diuruskan oleh VMware. Ya, terdapat banyak penyelesaian yang boleh melakukan penghijrahan sedemikian, tetapi kami menganggap Hystax sebagai alat universal, dan menguji penghijrahan dalam semua kombinasi yang mungkin hanyalah tugas yang tidak realistik. Dan awan Oncloud.ru dibina khusus pada VMware, jadi platform ini sebagai sasaran menarik minat kami pada tahap yang lebih besar. Seterusnya, saya akan menerangkan prinsip asas operasi, yang secara amnya bebas daripada platform, dan VMware dari mana-mana pihak boleh digantikan oleh platform daripada vendor lain.
Langkah pertama ialah menggunakan Hystax Acura, yang merupakan panel kawalan sistem.
Ia terbentang dari templat. Atas sebab tertentu, dalam kes kami ia tidak betul sepenuhnya dan bukannya 8CPU yang disyorkan, 16Gb telah digunakan dengan separuh sumber. Oleh itu, anda perlu ingat untuk menukarnya, jika tidak, infrastruktur kontena di dalam VM, di mana segala-galanya dibina, tidak akan bermula dan portal tidak boleh diakses. DALAM Sumber yang diperlukan diterangkan secara terperinci, serta port untuk semua komponen sistem.
Terdapat juga kesukaran menetapkan alamat IP melalui templat, jadi kami menukarnya daripada konsol. Selepas ini, anda boleh pergi ke antara muka web pentadbir dan melengkapkan wizard konfigurasi awal.
Titik akhir β IP atau FQDN vCenter kami.
Log masuk dan Kata Laluan - ini jelas.
Nama hos Sasaran ESXi ialah salah satu hos dalam kluster kami yang replikasi akan dilakukan.
Simpanan data sasaran ialah salah satu stor data dalam kluster kami yang mana replikasi akan dilakukan.
IP Awam Panel Kawalan Hystax Acura β alamat di mana panel kawalan akan tersedia.
Sedikit penjelasan diperlukan mengenai hos dan stor data. Hakikatnya ialah replikasi Hystax berfungsi pada peringkat hos dan stor data. Seterusnya saya akan memberitahu anda bagaimana anda boleh menukar hos dan stor data untuk penyewa, tetapi masalahnya berbeza. Hystax tidak menyokong bekerja dengan kumpulan sumber, i.e. replika akan sentiasa pergi ke akar kluster (pada masa menulis bahan ini, lelaki dari Hystax mengeluarkan versi yang dikemas kini, di mana mereka dengan cepat melaksanakan permintaan ciri saya mengenai sokongan untuk kumpulan sumber). Pengarah vCloud juga tidak disokong, i.e. jika, seperti dalam kes saya, penyewa tidak mempunyai hak pentadbir untuk keseluruhan kluster, tetapi hanya kepada kumpulan sumber tertentu, dan kami memberikan akses kepada Hystax, maka dia akan dapat mereplikasi dan melancarkan VM ini secara bebas, tetapi dia akan tidak dapat melihatnya dalam infrastruktur VMware , yang dia mempunyai akses dan, dengan itu, menguruskan mesin maya lagi. Pentadbir kluster perlu mengalihkan VM ke kumpulan sumber yang dikehendaki atau mengimportnya ke vCloud Director.
Mengapa saya banyak memberi tumpuan kepada perkara ini? Kerana, sejauh yang saya faham tentang konsep produk, pelanggan sepatutnya boleh melaksanakan sebarang migrasi atau DR secara bebas menggunakan panel Acura. Tetapi setakat ini, sokongan VMware sedikit di belakang tahap sokongan untuk OpenStack, di mana mekanisme serupa telah pun dilaksanakan.
Tetapi mari kita kembali ke penempatan. Pertama sekali, selepas persediaan awal panel, kami perlu mencipta penyewa pertama dalam sistem kami.
Semua medan di sini adalah jelas, saya hanya akan memberitahu anda tentang medan Awan. Kami sudah mempunyai awan "lalai" yang kami buat semasa konfigurasi awal. Tetapi jika kami mahu dapat meletakkan setiap penyewa pada stor datanya sendiri dan dalam kumpulan sumbernya sendiri, kami boleh melaksanakannya dengan mencipta awan berasingan untuk setiap pelanggan kami.
Dalam borang untuk menambah awan baharu, kami menentukan parameter yang sama seperti semasa konfigurasi awal (malah kami boleh menggunakan hos yang sama), menunjukkan stor data yang diperlukan untuk pelanggan tertentu, dan kini dalam parameter tambahan kami boleh menentukan sumber yang diperlukan secara individu kolam {"resource_pool" : "YOUR_POOL_NAME"}
Seperti yang anda mungkin perasan, dalam borang penciptaan penyewa tiada apa-apa tentang peruntukan sumber atau sebarang kuota - tiada satu pun daripada ini dalam sistem. Adalah mustahil untuk mengehadkan penyewa dalam bilangan replika serentak, bilangan mesin untuk replikasi, atau oleh mana-mana parameter lain. Jadi, kami telah mencipta penyewa pertama. Kini terdapat perkara yang tidak logik sepenuhnya, tetapi wajib - memasang ejen Cloud. Ia tidak logik, kerana ejen dimuat turun pada halaman pelanggan tertentu.
Pada masa yang sama, ia tidak terikat dengan penyewa yang dibuat, dan semua pelanggan kami akan berusaha melaluinya (atau melalui beberapa, jika kami menggunakan mereka). Satu ejen menyokong 10 sesi serentak. Satu mesin dikira sebagai satu sesi. Tidak kira berapa banyak cakera yang ada. Sehingga kini, tiada mekanisme untuk menskala ejen dalam Acura sendiri di bawah VMware. Terdapat satu lagi saat yang tidak menyenangkan - kami tidak mempunyai peluang untuk melihat "pembuangan" ejen ini dari panel Acura untuk membuat kesimpulan sama ada kami perlu menggunakan lebih banyak atau sama ada pemasangan semasa sudah mencukupi. Akibatnya, pendirian kelihatan seperti ini:
Langkah seterusnya untuk mengakses portal pelanggan kami ialah membuat akaun (dan pertama, peranan yang akan digunakan untuk pengguna ini).
Kini pelanggan kami boleh menggunakan portal secara bebas. Apa yang dia perlu lakukan ialah memuat turun ejen dari portal dan memasangnya di sebelahnya. Terdapat tiga jenis ejen: Linux, Windows dan VMware.
Dua yang pertama dipasang pada fizik atau pada mesin maya pada mana-mana hypervisor selain VMware. Tidak perlu mengkonfigurasi apa-apa tambahan, ejen dimuat turun dan sudah tahu di mana hendak mengetuk, dan secara literal dalam satu minit kereta akan kelihatan di panel Acura. Dengan ejen VMware keadaannya sedikit lebih rumit. Masalahnya ialah ejen untuk VMware juga dimuat turun dari portal yang telah disediakan dan mengandungi konfigurasi yang diperlukan. Tetapi selain mengetahui tentang portal Acura kami, ejen VMware juga perlu mengetahui tentang sistem virtualisasi yang akan digunakan.
Sebenarnya, sistem akan meminta kami menyediakan data ini apabila kami mula-mula memuat turun ejen VMware. Masalahnya ialah pada zaman kita yang cinta sejagat untuk keselamatan, tidak semua orang mahu menunjukkan kata laluan pentadbir mereka pada portal orang lain, yang agak mudah difahami. Dari dalam, selepas penggunaan, ejen tidak boleh dikonfigurasikan dalam apa jua cara (anda hanya boleh menukar tetapan rangkaiannya). Di sini saya meramalkan kesukaran dengan pelanggan yang berhati-hati.
Jadi, selepas memasang ejen, kita boleh kembali ke panel Acura dan melihat semua kereta kita.
Memandangkan saya telah bekerja dengan sistem selama beberapa hari sekarang, saya mempunyai kereta di negeri yang berbeza. Saya mempunyai kesemuanya dalam kumpulan Lalai, tetapi adalah mungkin untuk membuat kumpulan berasingan dan memindahkan kereta kepada mereka seperti yang anda perlukan. Ini tidak menjejaskan apa-apa - hanya persembahan logik data dan pengelompokan mereka untuk kerja yang lebih mudah. Perkara pertama dan paling penting yang perlu kita lakukan selepas ini ialah memulakan proses migrasi. Kita boleh melakukan ini sama ada secara manual atau dengan menyediakan jadual, termasuk secara pukal untuk semua mesin sekaligus.
Biar saya ingatkan anda bahawa Hystax telah diletakkan sebagai produk untuk migrasi. Oleh itu, tidak menghairankan bahawa untuk menjalankan mesin replika kami, kami perlu membuat pelan DR. Pelan boleh dibuat untuk mesin yang sudah berada dalam keadaan Synced. Anda boleh menjana kedua-duanya untuk satu VM tertentu dan untuk semua mesin sekaligus.
Set parameter apabila menjana pelan DR akan berbeza bergantung pada infrastruktur yang akan anda pindahkan. Set minimum parameter tersedia untuk persekitaran VMware. IP semula untuk mesin juga tidak disokong. Dalam hal ini, kami berminat dengan perkara berikut: dalam perihalan VM, parameter "subnet": "VMNetwork", di mana kami mengikat VM ke rangkaian tertentu dalam kelompok. Kedudukan β relevan apabila memindahkan beberapa VM; ia menentukan susunan ia dilancarkan. Flavour β menerangkan konfigurasi VM, dalam kes ini β 1CPU, 2GB RAM. Dalam bahagian subnet, kami mentakrifkan bahawa "subnet": "VMNetwork" dikaitkan dengan VMware "VM Network".
Apabila membuat rancangan DR, tiada cara untuk "menyebarkan" cakera merentasi stor data yang berbeza. Ia akan terletak pada stor data yang sama yang ditakrifkan untuk awan pelanggan ini, dan jika anda mempunyai cakera kelas yang berbeza, ini mungkin menyebabkan beberapa kesukaran semasa memulakan mesin, dan selepas memulakan dan "memisahkan" VM daripada Hystax, ia juga akan memerlukan cakera pemindahan berasingan ke stor data yang diperlukan. Kemudian apa yang kita perlu lakukan ialah melancarkan rancangan DR kami dan tunggu kereta kami naik. Proses penukaran P2V/V2V juga mengambil masa. Pada mesin ujian terbesar saya, 100GB dengan tiga cakera, ia mengambil masa maksimum 10 minit.
Selepas ini, anda harus menyemak VM yang sedang berjalan, perkhidmatan di atasnya, konsistensi data, dan menjalankan pemeriksaan lain.
Kemudian kita mempunyai dua cara:
- Padam β padamkan pelan DR yang sedang berjalan. Tindakan ini hanya akan mematikan VM yang sedang berjalan. Replika ini tidak akan ke mana-mana.
- Tanggalkan β carik kereta replika dari Acura, i.e. sebenarnya menyelesaikan proses migrasi.
Kelebihan penyelesaian:
- kemudahan pemasangan dan konfigurasi dari kedua-dua pelanggan dan dari pembekal;
- kemudahan menyediakan migrasi, mencipta rancangan DR dan melancarkan replika;
- sokongan dan pembangun bertindak balas dengan cepat terhadap masalah yang ditemui dan membetulkannya menggunakan kemas kini platform atau ejen.
Kekurangan
- Sokongan Vmware tidak mencukupi.
- Ketiadaan sebarang kuota untuk penyewa dari platform.
Saya juga menyusun Permintaan Ciri, yang kami serahkan kepada vendor:
- pemantauan dan penggunaan penggunaan daripada konsol pengurusan Acura untuk ejen Cloud;
- ketersediaan kuota untuk penyewa;
- keupayaan untuk mengehadkan bilangan replikasi dan kelajuan serentak bagi setiap penyewa;
- Sokongan Pengarah vCloud VMware;
- sokongan untuk kumpulan sumber (dilaksanakan semasa ujian);
- keupayaan untuk mengkonfigurasi ejen VMware daripada ejen itu sendiri, tanpa memasukkan bukti kelayakan daripada infrastruktur pelanggan dalam panel Acura;
- "visualisasi" proses permulaan VM semasa menjalankan rancangan DR.
Satu-satunya perkara yang menyebabkan saya mendapat kritikan besar ialah dokumentasi. Saya tidak begitu suka "kotak hitam" dan lebih suka apabila terdapat dokumentasi terperinci tentang cara produk berfungsi di dalamnya. Dan jika untuk AWS dan OpenStack produk diterangkan lebih kurang, maka untuk VMware terdapat sedikit dokumentasi.
Terdapat Panduan Pemasangan yang hanya menerangkan penggunaan panel Acura, dan tidak ada sebarang perkataan tentang fakta bahawa ejen Cloud juga diperlukan. Terdapat satu set lengkap spesifikasi produk, yang bagus. Terdapat dokumentasi yang menerangkan persediaan "dari awal hingga akhir" menggunakan AWS dan OpenStack sebagai contoh (walaupun ia kelihatan lebih seperti catatan blog kepada saya), dan terdapat Pangkalan Pengetahuan yang sangat kecil.
Secara umum, ini bukan format dokumentasi yang biasa saya gunakan, katakan, daripada vendor yang lebih besar, jadi saya tidak selesa sepenuhnya. Pada masa yang sama, saya tidak pernah menemui jawapan tentang beberapa nuansa bagaimana sistem berfungsi "di dalam" dalam dokumentasi ini - banyak soalan perlu dijelaskan dengan sokongan teknikal, dan ini agak melambatkan proses menggunakan pendirian dan menjalankan ujian.
Untuk meringkaskan, saya boleh mengatakan bahawa secara umum saya menyukai produk dan pendekatan syarikat terhadap tugas itu. Ya, terdapat kekurangan, terdapat kekurangan fungsi yang sangat kritikal (berkaitan dengan VMware). Adalah jelas bahawa, pertama sekali, syarikat itu masih menumpukan pada awan awam, khususnya AWS, dan untuk sesetengahnya ini akan mencukupi. Mempunyai produk yang ringkas dan mudah hari ini, apabila banyak syarikat memilih strategi berbilang awan, adalah amat penting. Memandangkan harga yang jauh lebih rendah berbanding pesaing, ini menjadikan produk itu sangat menarik.
Kami sedang mencari ahli pasukan . Mungkin awak?
Sumber: www.habr.com