Salah satu pemain muda di pasar solusi Pemulihan Bencana adalah Hystax, sebuah startup Rusia yang berdiri sejak tahun 2016. Karena topik pemulihan bencana sangat populer dan pasarnya sangat kompetitif, startup ini memutuskan untuk fokus pada migrasi antar infrastruktur cloud yang berbeda. Produk yang memungkinkan Anda mengatur migrasi sederhana dan cepat ke cloud juga akan sangat berguna bagi klien - pengguna Onlanta . Begitulah cara saya mengenal Hystax dan mulai menguji kemampuannya. Saya akan memberi tahu Anda hasilnya di artikel ini.
Fitur utama Hystax adalah fungsionalitasnya yang luas untuk mendukung berbagai platform virtualisasi, sistem operasi tamu, dan layanan cloud, yang memungkinkan untuk mentransfer beban kerja Anda dari mana saja, di mana saja.
Hal ini memungkinkan Anda untuk membuat tidak hanya solusi DR untuk meningkatkan toleransi kesalahan layanan, tetapi juga dengan cepat dan fleksibel memigrasikan sumber daya antara berbagai situs dan hyperscaler untuk meningkatkan penghematan biaya dan memilih solusi terbaik untuk layanan tertentu pada saat tertentu. Selain platform yang tercantum dalam gambar judul, perusahaan juga secara aktif bekerja sama dengan penyedia cloud Rusia: Yandex.Cloud, CROC Cloud Services, Mail.ru, dan banyak lainnya. Perlu juga dicatat bahwa pada tahun 2020 perusahaan membuka pusat Litbang yang berlokasi di Skolkovo.
Pilihan satu solusi oleh sejumlah besar pemain di pasar menunjukkan kebijakan harga yang baik dan penerapan produk yang tinggi, yang kami putuskan untuk diuji dalam praktiknya.
Jadi, tugas pengujian kami akan terdiri dari migrasi dari situs pengujian VMware saya dan mesin fisik ke situs penyedia, juga dikelola oleh VMware. Ya, ada banyak solusi yang dapat melakukan migrasi seperti itu, namun kami menganggap Hystax sebagai alat universal, dan menguji migrasi dalam semua kemungkinan kombinasi hanyalah tugas yang tidak realistis. Dan cloud Oncloud.ru dibuat khusus di VMware, jadi platform ini sebagai target lebih menarik minat kami. Selanjutnya saya akan menjelaskan prinsip dasar pengoperasiannya, yang umumnya tidak bergantung pada platform, dan VMware dari sisi mana pun dapat digantikan oleh platform dari vendor lain.
Langkah pertama adalah menerapkan Hystax Acura, yang merupakan panel kontrol sistem.
Itu terungkap dari template. Untuk beberapa alasan, dalam kasus kami ini tidak sepenuhnya benar dan alih-alih 8CPU yang direkomendasikan, 16Gb digunakan dengan setengah sumber daya. Oleh karena itu, Anda harus ingat untuk mengubahnya, jika tidak, infrastruktur kontainer di dalam VM, tempat semuanya dibangun, tidak akan dimulai dan portal tidak akan dapat diakses. DI DALAM Sumber daya yang diperlukan dijelaskan secara rinci, serta port untuk semua komponen sistem.
Ada juga kesulitan dalam mengatur alamat IP melalui template, jadi kami mengubahnya dari konsol. Setelah ini, Anda dapat masuk ke antarmuka web admin dan menyelesaikan wizard konfigurasi awal.
Titik Akhir β IP atau FQDN dari vCenter kami.
Login dan Password β ini jelas.
Nama host ESXi target adalah salah satu host di cluster kami yang akan direplikasi.
Penyimpanan data target adalah salah satu penyimpanan data di cluster kami tempat replikasi akan dilakukan.
IP Publik Panel Kontrol Hystax Acura β alamat di mana panel kontrol akan tersedia.
Diperlukan sedikit klarifikasi mengenai host dan datastore. Faktanya adalah replikasi Hystax bekerja di tingkat host dan penyimpanan data. Selanjutnya saya akan memberi tahu Anda bagaimana Anda dapat mengubah host dan datastore untuk penyewa, tetapi masalahnya berbeda. Hystax tidak mendukung bekerja dengan kumpulan sumber daya, mis. replika akan selalu menuju ke root cluster (pada saat penulisan materi ini, orang-orang dari Hystax merilis versi terbaru, di mana mereka dengan cepat mengimplementasikan permintaan fitur saya mengenai dukungan untuk kumpulan sumber daya). vCloud Director juga tidak didukung, mis. jika, seperti dalam kasus saya, penyewa tidak memiliki hak admin untuk seluruh cluster, tetapi hanya untuk kumpulan sumber daya tertentu, dan kami memberikan akses ke Hystax, maka dia akan dapat mereplikasi dan meluncurkan VM ini secara mandiri, tetapi dia akan melakukannya tidak dapat melihatnya di infrastruktur VMware, yang dapat diaksesnya dan, karenanya, mengelola mesin virtual lebih lanjut. Administrator klaster perlu memindahkan VM ke kumpulan sumber daya yang diinginkan atau mengimpornya ke vCloud Director.
Mengapa saya begitu fokus pada poin-poin ini? Sebab, sejauh yang saya pahami tentang konsep produknya, pelanggan harus bisa secara mandiri melakukan migrasi atau DR apa pun menggunakan panel Acura. Namun sejauh ini, dukungan VMware sedikit tertinggal dibandingkan dukungan OpenStack, di mana mekanisme serupa telah diterapkan.
Tapi mari kita kembali ke penerapan. Pertama-tama, setelah pengaturan awal panel, kita perlu membuat penyewa pertama di sistem kita.
Semua field di sini jelas, saya hanya akan memberi tahu Anda tentang bidang Cloud. Kami sudah memiliki cloud "default" yang kami buat pada konfigurasi awal. Namun jika kami ingin dapat menempatkan setiap penyewa pada penyimpanan datanya sendiri dan pada kumpulan sumber dayanya sendiri, kami dapat menerapkannya dengan membuat cloud terpisah untuk setiap pelanggan kami.
Dalam formulir untuk menambahkan cloud baru, kami menentukan parameter yang sama seperti pada konfigurasi awal (kami bahkan dapat menggunakan host yang sama), menunjukkan penyimpanan data yang diperlukan untuk pelanggan tertentu, dan sekarang dalam parameter tambahan kami dapat menentukan secara individual sumber daya yang diperlukan kumpulan {"resource_pool" : "YOUR_POOL_NAME"}
Seperti yang mungkin Anda ketahui, dalam formulir pembuatan penyewa tidak ada apa pun tentang alokasi sumber daya atau kuota apa pun - tidak ada hal seperti itu di sistem. Tidak mungkin membatasi penyewa dalam jumlah replika simultan, jumlah mesin untuk replikasi, atau parameter lainnya. Jadi, kami telah membuat penyewa pertama. Sekarang ada hal yang tidak sepenuhnya logis, tetapi wajib - menginstal agen Cloud. Ini tidak logis, karena agen diunduh pada halaman pelanggan tertentu.
Pada saat yang sama, ini tidak terikat dengan penyewa yang dibuat, dan semua pelanggan kami akan mengerjakannya (atau melalui beberapa, jika kami menerapkannya). Satu agen mendukung 10 sesi simultan. Satu mesin dihitung sebagai satu sesi. Tidak peduli berapa banyak disk yang dimilikinya. Sampai saat ini, tidak ada mekanisme untuk agen penskalaan di Acura sendiri di bawah VMware. Ada momen tidak menyenangkan lainnya - kami tidak memiliki kesempatan untuk melihat "pembuangan" agen ini dari panel Acura untuk menyimpulkan apakah kami perlu menerapkan lebih banyak atau apakah instalasi saat ini sudah cukup. Hasilnya, standnya terlihat seperti ini:
Langkah selanjutnya untuk mengakses portal pelanggan kami adalah membuat akun (dan pertama, peran yang akan berlaku untuk pengguna ini).
Sekarang pelanggan kami dapat menggunakan portal secara mandiri. Yang perlu dia lakukan hanyalah mengunduh agen dari portal dan menginstalnya di sisinya. Ada tiga jenis agen: Linux, Windows dan VMware.
Dua yang pertama diinstal pada fisika atau pada mesin virtual pada hypervisor apa pun selain VMware. Tidak perlu mengkonfigurasi tambahan apa pun, agen telah diunduh dan sudah tahu di mana harus mengetuk, dan dalam satu menit mobil akan terlihat di panel Acura. Dengan agen VMware, situasinya sedikit lebih rumit. Masalahnya adalah agen untuk VMware juga diunduh dari portal yang sudah disiapkan dan berisi konfigurasi yang diperlukan. Namun selain mengetahui tentang portal Acura kami, agen VMware juga perlu mengetahui tentang sistem virtualisasi yang akan digunakan.
Sebenarnya sistem akan meminta kita untuk memberikan data ini saat pertama kali mendownload agen VMware. Masalahnya adalah di zaman kita yang sangat mencintai keamanan, tidak semua orang ingin menunjukkan kata sandi admin mereka di portal orang lain, dan hal ini cukup bisa dimengerti. Dari dalam, setelah penerapan, agen tidak dapat dikonfigurasi dengan cara apa pun (Anda hanya dapat mengubah pengaturan jaringannya). Di sini saya memperkirakan kesulitan dengan pelanggan yang sangat berhati-hati.
Jadi, setelah menginstal agen, kita dapat kembali ke panel Acura dan melihat semua mobil kita.
Karena saya telah bekerja dengan sistem ini selama beberapa hari, saya memiliki mobil di berbagai negara bagian. Saya memiliki semuanya di grup Default, tetapi dimungkinkan untuk membuat grup terpisah dan mentransfer mobil ke grup tersebut sesuai kebutuhan. Ini tidak memengaruhi apa pun - hanya penyajian data yang logis dan pengelompokannya untuk pekerjaan yang lebih nyaman. Hal pertama dan terpenting yang perlu kita lakukan setelah ini adalah memulai proses migrasi. Kita bisa melakukannya secara manual atau dengan mengatur jadwal, termasuk secara massal untuk semua mesin sekaligus.
Izinkan saya mengingatkan Anda bahwa Hystax diposisikan sebagai produk untuk migrasi. Oleh karena itu, tidak mengherankan jika untuk menjalankan mesin replika kami, kami perlu membuat rencana DR. Rencananya dapat dibuat untuk mesin yang sudah dalam keadaan Tersinkronisasi. Anda dapat membuat untuk satu VM tertentu dan untuk semua mesin sekaligus.
Kumpulan parameter saat membuat paket DR akan berbeda bergantung pada infrastruktur tujuan migrasi Anda. Seperangkat parameter minimal tersedia untuk lingkungan VMware. IP ulang untuk mesin juga tidak didukung. Dalam hal ini, kami tertarik pada poin-poin berikut: dalam deskripsi VM, parameter "subnet": "VMNetwork", tempat kami mengikat VM ke jaringan tertentu di cluster. Peringkat β relevan ketika memigrasikan beberapa VM; ini menentukan urutan peluncurannya. Flavour β menjelaskan konfigurasi VM, dalam hal ini β 1CPU, RAM 2GB. Di bagian subnet kami mendefinisikan bahwa "subnet": "VMNetwork" dikaitkan dengan VMware "VM Network".
Saat membuat paket DR, tidak ada cara untuk βmenyebarkanβ disk ke berbagai penyimpanan data. Mereka akan ditempatkan di penyimpanan data yang sama yang ditentukan untuk cloud klien ini, dan jika Anda memiliki disk dengan kelas yang berbeda, ini mungkin menyebabkan beberapa kesulitan saat memulai mesin, dan setelah memulai dan "memisahkan" VM dari Hystax, itu juga akan terjadi. memerlukan disk migrasi terpisah ke penyimpanan data yang diperlukan. Maka yang harus kita lakukan hanyalah meluncurkan rencana DR dan menunggu mobil kita bangkit. Proses konversi P2V/V2V juga membutuhkan waktu. Pada mesin pengujian terbesar saya, 100GB dengan tiga disk, dibutuhkan waktu maksimal 10 menit.
Setelah ini, Anda harus memeriksa VM yang sedang berjalan, layanan di dalamnya, konsistensi data, dan melakukan pemeriksaan lainnya.
Lalu kita punya dua cara:
- Hapus β menghapus paket DR yang sedang berjalan. Tindakan ini hanya akan mematikan VM yang sedang berjalan. Replika ini tidak akan kemana-mana.
- Lepaskan β sobek mobil replika dari Acura, mis. benar-benar menyelesaikan proses migrasi.
Kelebihan dari solusinya:
- kemudahan instalasi dan konfigurasi baik dari klien maupun dari penyedia;
- kemudahan menyiapkan migrasi, membuat rencana DR, dan meluncurkan replika;
- dukungan dan pengembang merespons dengan cukup cepat terhadap masalah yang ditemukan dan memperbaikinya menggunakan pembaruan platform atau agen.
Kontra
- Dukungan Vmware tidak memadai.
- Tidak adanya kuota untuk penyewa dari platform.
Saya juga menyusun Permintaan Fitur, yang kami kirimkan ke vendor:
- pemantauan penggunaan dan penerapan dari konsol manajemen Acura untuk agen Cloud;
- ketersediaan kuota bagi penyewa;
- kemampuan untuk membatasi jumlah replikasi dan kecepatan simultan untuk setiap penyewa;
- dukungan VMware vCloud Director;
- dukungan untuk kumpulan sumber daya (diimplementasikan selama pengujian);
- kemampuan untuk mengonfigurasi agen VMware dari agen itu sendiri, tanpa memasukkan kredensial dari infrastruktur klien di panel Acura;
- βvisualisasiβ proses startup VM saat menjalankan rencana DR.
Satu-satunya hal yang menimbulkan kritik besar bagi saya adalah dokumentasinya. Saya tidak terlalu menyukai "kotak hitam" dan lebih suka jika ada dokumentasi mendetail tentang cara kerja produk di dalamnya. Dan jika untuk AWS dan OpenStack produknya dijelaskan kurang lebih, maka untuk VMware hanya ada sedikit dokumentasi.
Terdapat Panduan Instalasi yang hanya menjelaskan penerapan panel Acura, dan tidak ada satu kata pun yang menyatakan bahwa agen Cloud juga diperlukan. Spesifikasi produknya lengkap, bagus. Ada dokumentasi yang menjelaskan pengaturan βdari awal sampai akhirβ menggunakan AWS dan OpenStack sebagai contoh (walaupun bagi saya lebih mirip postingan blog), dan ada Basis Pengetahuan yang sangat kecil.
Secara umum, ini bukan format dokumentasi yang biasa saya gunakan, katakanlah, dari vendor yang lebih besar, jadi saya merasa kurang nyaman. Pada saat yang sama, saya tidak pernah menemukan jawaban tentang beberapa nuansa bagaimana sistem bekerja "di dalam" dalam dokumentasi ini - banyak pertanyaan yang harus diklarifikasi dengan dukungan teknis, dan ini cukup menunda proses penggelaran stand dan pelaksanaannya. pengujian.
Singkatnya, saya dapat mengatakan bahwa secara umum saya menyukai produk dan pendekatan perusahaan terhadap tugas tersebut. Ya, ada kekurangannya, ada kekurangan fungsionalitas yang sangat kritis (sehubungan dengan VMware). Jelas bahwa, pertama-tama, perusahaan masih fokus pada cloud publik, khususnya AWS, dan bagi sebagian orang, ini sudah cukup. Memiliki produk yang sederhana dan nyaman saat ini, ketika banyak perusahaan memilih strategi multi-cloud, sangatlah penting. Mengingat harganya yang jauh lebih rendah dibandingkan pesaing, hal ini membuat produk ini sangat menarik.
Kami sedang mencari anggota tim . Mungkin itu kamu?
Sumber: www.habr.com