Ketersediaan tinggi pada server virtual: panduan lengkap

Informatec Digital » Sumber daya » Ketersediaan tinggi pada server virtual: panduan lengkap

Ketersediaan tinggi pada server virtual telah menjadi persyaratan dasar bagi setiap organisasi yang tidak mampu menanggung gangguan layanan, bahkan hanya untuk beberapa menit. Kita berbicara tentang memastikan bahwa mesin virtual, aplikasi, dan data Anda tetap dapat diakses bahkan jika server fisik, disk, jaringan, atau bahkan seluruh pusat data mengalami kegagalan. Ini bukan hanya tentang memiliki cadangan, tetapi tentang menjaga agar layanan tetap berjalan apa pun yang terjadi.

Ketika kita menggabungkan virtualisasi , klaster, penyimpanan, dan pemulihan bencana , banyak teknologi muncul (KVM, Xen, Hyper-V, RHEL HA, RHEV, CSV, NAS, JBOD, replika, dll.), dan tidak selalu jelas mana yang harus dipilih atau bagaimana cara menggabungkannya. Artikel ini memberikan tinjauan mendalam tentang opsi dan pendekatan utama: dari klaster tradisional dengan penyimpanan bersama hingga solusi modern berdasarkan replikasi waktu nyata antar node, termasuk contoh spesifik dengan arsitektur Red Hat, Microsoft Hyper-V, QNAP, dan HA-DAS.

Konsep dasar ketersediaan tinggi di lingkungan virtualisasi

Dalam lingkungan virtualisasi, ketersediaan tinggi (HA) berarti bahwa VM tetap dapat diakses bahkan jika satu atau lebih komponen sistem (server, disk, pengontrol, jaringan, catu daya, dll.) mengalami kegagalan. Ini berbeda dengan pemulihan bencana (DR): HA bertujuan untuk meminimalkan atau mendekati nol waktu henti, sedangkan DR biasanya menerima beberapa waktu henti untuk memulihkan layanan dari cadangan.

Untuk mencapai perilaku ini, beberapa komponen digabungkan: redundansi perangkat keras, perangkat lunak klaster, penyimpanan yang toleran terhadap kesalahan , serta mekanisme pemantauan dan failover . Tujuannya adalah untuk menghindari titik kegagalan tunggal: jika satu komponen rusak, komponen lain akan mengambil alih tanpa intervensi manual (atau dengan intervensi minimal).

Dalam dunia virtualisasi, ini biasanya berarti memiliki beberapa host fisik yang berbagi atau mereplikasi penyimpanan , dan sistem yang memantau status node dan VM. Ketika satu host gagal, mesin virtual akan memulai di host lain, idealnya tanpa disadari pengguna atau dengan gangguan yang sangat singkat.

Penting juga untuk membedakan antara solusi yang dirancang untuk lingkungan "mirip cloud" yang elastis dan platform HA klasik. Produk cluster tertentu memiliki konfigurasi yang relatif statis dan jumlah node maksimum yang relatif rendah, sehingga tidak cocok untuk membangun cloud besar-besaran, meskipun sangat baik untuk melindungi serangkaian layanan penting yang terdefinisi dengan baik.

Dalam lingkungan cloud atau hybrid, disarankan untuk meninjau strategi migrasi dan kontinuitas spesifik: misalnya, migrasi cloud dapat menjadi bagian dari strategi pemulihan bencana, tetapi tidak menggantikan HA lokal.

Ketersediaan tinggi pada platform Red Hat Enterprise Linux dan KVM/Xen

Ekosistem Red Hat menawarkan beberapa opsi untuk melindungi mesin virtual menggunakan klaster dan add-on ketersediaan tinggi . Versi seperti Red Hat Enterprise Linux 5 dan 6 mendukung berbagai kombinasi hypervisor dan add-on klaster.

RHEL 5 mendukung dua platform virtualisasi: Xen (mulai dari RHEL 5.0) dan KVM (mulai dari RHEL 5.4) . Add-on RHEL 5 Advanced Platform (AP) Cluster memungkinkan Anda untuk mengelola VM Xen dan KVM sebagai sumber daya cluster, sehingga infrastruktur ketersediaan tinggi host mengontrol proses startup, shutdown, dan failover mesin virtual antar node.

Dengan RHEL 6, dukungan virtualisasi disederhanakan: hanya KVM yang didukung sebagai hypervisor . Namun, plugin High Availability RHEL 6 masih memungkinkan mesin virtual KVM diperlakukan sebagai sumber daya klaster yang dikelola oleh infrastruktur HA host. Manajer sumber daya klaster (rgmanager dalam versi klasik) bertanggung jawab untuk memantau node dan memindahkan guest antar server fisik ketika terjadi kegagalan.

Pendekatan ini sering disebut sebagai “ Klaster RHEL/HA yang berjalan pada host fisik yang bertindak sebagai platform virtualisasi .” Klaster RHEL itu sendiri mengelola di mana setiap VM berjalan dan mengambil alih jika terjadi kegagalan node, memastikan bahwa mesin virtual yang dikonfigurasi sebagai kritis akan dihidupkan kembali pada host yang sehat.

Aspek menariknya adalah, dari perspektif klaster, sistem operasi tamu VM kurang penting . Sistem operasi tamu apa pun yang kompatibel dengan Xen atau KVM di RHEL dapat diperlakukan sebagai mesin virtual yang memiliki ketersediaan tinggi: berbagai versi RHEL (3, 4, 5, dll.) dan berbagai edisi Microsoft Windows, selama didukung oleh hypervisor. Hal ini memberikan fleksibilitas yang cukup besar saat mengamankan lingkungan campuran.

Namun, Red Hat sendiri menyarankan kehati-hatian saat memilih antara menggunakan RHEL High Availability Add-on atau platform virtualisasi yang lebih komprehensif seperti Red Hat Enterprise Virtualization (RHEV) untuk menyediakan ketersediaan tinggi bagi VM. Keduanya menawarkan fungsionalitas ketersediaan tinggi, tetapi kasus penggunaannya berbeda, dan ukuran lingkungan serta model operasinya harus dipertimbangkan.

Kapan menggunakan RHEL HA dibandingkan RHEV untuk ketersediaan tinggi?

Saat memutuskan apakah akan menggunakan RHEL HA Add-on atau platform seperti RHEV untuk melindungi mesin virtual, salah satu kriteria utama adalah jumlah host fisik dan jenis penggunaan yang akan diberikan pada lingkungan virtualisasi tersebut.

Add-on ketersediaan tinggi RHEL dirancang untuk klaster yang relatif kecil dan dikonfigurasi secara statis . Secara tradisional, klaster ini memiliki batas maksimum sekitar 16 node fisik, yang cukup untuk banyak lingkungan perusahaan tetapi tidak cocok dengan arsitektur seperti cloud dengan puluhan atau ratusan host yang terus berubah.

Oleh karena itu, dokumentasi Red Hat sendiri menunjukkan bahwa penggunaan RHEL HA secara eksklusif untuk membangun infrastruktur mirip cloud tidak disarankan , justru karena sifatnya yang statis dan batasan jumlah node. Untuk skenario cloud, lebih masuk akal untuk menggunakan platform yang dirancang khusus untuk model tersebut, dengan pengelola sumber daya yang lebih elastis dan skalabel.

Di sisi lain, jika tujuannya adalah untuk melindungi sejumlah VM kritis pada sekumpulan host yang terdefinisi dengan baik , add-on HA RHEL adalah solusi yang andal: ia terintegrasi dengan baik dengan sistem operasi, mengandalkan teknologi clustering yang matang, dan menyediakan logika yang diperlukan untuk memantau dan memindahkan VM jika terjadi kegagalan.

Bagaimanapun, disarankan untuk meninjau dokumentasi RHEL terbaru tentang sistem operasi tamu yang didukung serta kombinasi hypervisor dan cluster , karena dukungan terus berkembang dengan setiap rilis dan penting untuk tetap berpegang pada matriks resmi.

Ketersediaan tinggi di Hyper-V: klaster, replika, dan migrasi langsung.

Dalam lingkungan Microsoft, ketersediaan tinggi pada dasarnya didasarkan pada kemampuan Hyper-V yang dikombinasikan dengan Windows Server Failover Clustering . Tujuannya adalah untuk memiliki akses yang konsisten ke mesin virtual bahkan jika terjadi kegagalan perangkat keras, masalah jaringan, atau kesalahan perangkat lunak.

Komponen intinya adalah klaster failover Hyper-V . Klaster semacam itu adalah sekumpulan server (node) yang berbagi penyimpanan dan bekerja secara terkoordinasi: jika satu node gagal, VM yang dijalankannya akan secara otomatis dimulai ulang pada node lain dalam klaster. Semua ini didukung oleh teknologi disk bersama dan komunikasi internal khusus.

Agar hal ini berfungsi, node biasanya berbagi penyimpanan melalui SAN (Storage Area Network) atau scale-out file server (SOFS) . Cluster Shared Volumes (CSV) kemudian dibuat di atas lapisan ini , memungkinkan semua node untuk secara bersamaan mengakses disk yang sama tempat file mesin virtual berada.

Node-node tersebut juga berkomunikasi melalui jaringan khusus yang dikenal sebagai detak jantung klaster . Jaringan ini terpisah dari jaringan data produksi dan memungkinkan setiap server untuk melaporkan bahwa server tersebut aktif. Jika klaster berhenti menerima detak jantung dari sebuah node, node tersebut dianggap telah gagal, dan prosedur failover akan dimulai.

Elemen fundamental lainnya adalah konfigurasi kuorum . Kuorum menentukan berapa banyak suara (node ​​atau saksi eksternal) yang harus aktif agar klaster dapat terus berfungsi. Ini mencegah skenario "split brain", di mana kelompok node yang terisolasi secara keliru percaya bahwa mereka adalah klaster utama dan menyebabkan kerusakan data. Memilih model kuorum yang tepat (node, saksi disk, saksi berbagi file, dll.) adalah kunci stabilitas.

Berdasarkan hal ini, Hyper-V memanfaatkan kemampuan klaster untuk memungkinkan migrasi langsung mesin virtual antar node dengan waktu henti minimal . Selama pemeliharaan atau penyeimbangan beban, VM dapat dipindahkan dari satu host ke host lain tanpa gangguan layanan, mentransfer memori, status, dan koneksi aktif secara transparan.

Jika, alih-alih pemeliharaan terencana, terjadi kegagalan perangkat keras atau perangkat lunak aktual pada sebuah node, klaster akan melakukan failover otomatis . Mesin virtual yang berjalan di sana akan dihidupkan pada host lain dengan akses ke penyimpanan bersama yang sama. Gangguan yang terjadi lebih besar daripada migrasi langsung (VM perlu dimatikan dan dihidupkan kembali), tetapi kontinuitas layanan tetap terjaga dengan intervensi manusia minimal.

Replika Hyper-V dan Migrasi Langsung “Tanpa Berbagi Apa Pun”

Selain klaster SAN klasik, Hyper-V menggabungkan teknologi lain yang berfokus pada ketersediaan tinggi dan pemulihan bencana, terutama Hyper-V Replica dan migrasi langsung tanpa penyimpanan bersama.

Hyper-V Replication adalah fitur replikasi mesin virtual asinkron yang mereplikasi mesin virtual antara host utama dan satu atau lebih host replika, yang biasanya terletak di lokasi atau pusat data yang berbeda. Perubahan dikirim ke VM target secara berkala, menciptakan titik pemulihan yang memungkinkan VM dipulihkan ke keadaan terkini jika situs utama mengalami bencana.

Mekanisme ini menggunakan agen replikasi Hyper-V yang mengkoordinasikan lalu lintas replikasi, mengelola titik pemulihan, dan memusatkan operasi failover. Ini memungkinkan failover yang direncanakan (misalnya, untuk memindahkan produksi ke situs lain) dan failover yang tidak direncanakan (ketika situs utama mengalami gangguan secara tiba-tiba).

Karena sifatnya yang asinkron, replikasi lebih berorientasi pada pemulihan bencana ( DR) daripada ketersediaan tinggi (HA) dengan waktu henti mendekati nol . Setelah terjadi insiden, failover harus dimulai pada VM replika, dan meskipun prosesnya cukup gesit, proses ini melibatkan beberapa waktu henti dan potensi kehilangan data beberapa detik atau menit terakhir, tergantung pada interval replikasi yang dikonfigurasi.

Secara paralel, Hyper-V menawarkan migrasi langsung Shared Nothing , yang memungkinkan Anda memindahkan VM antar host yang tidak berbagi penyimpanan. Dalam model ini, setiap host memiliki penyimpanan lokalnya sendiri, tetapi migrasi langsung secara transparan menyalin disk mesin virtual ke tujuan sementara VM tetap online, dan kemudian mengalihkan eksekusi ke server baru.

Fungsi ini sangat berguna di lingkungan tanpa SAN atau infrastruktur penyimpanan bersama , mengurangi biaya awal bagi UKM atau skenario di mana pemeliharaan jaringan penyimpanan khusus tidak diinginkan. Misalnya, memungkinkan penataan ulang host atau migrasi ke perangkat keras baru dengan dampak minimal, tanpa perlu mematikan mesin yang ada.

Kombinasi teknologi-teknologi ini (klaster failover, CSV, migrasi langsung dengan atau tanpa penyimpanan bersama, dan replikasi Hyper-V) menyediakan berbagai pilihan untuk merancang strategi kesinambungan bisnis dan toleransi kesalahan yang disesuaikan dengan anggaran dan tingkat permintaan yang berbeda.

Solusi ketersediaan tinggi dengan HA-DAS dan Windows Server

Selain lingkungan dengan SAN berukuran besar, terdapat arsitektur yang dirancang untuk ketersediaan tinggi pada sistem penyimpanan yang terhubung langsung ke server (HA-DAS) . Solusi ini memanfaatkan Windows Server (misalnya, 2012) dan pengontrol RAID/HBA canggih untuk menghadirkan klaster ketersediaan tinggi tanpa perlu menyiapkan SAN iSCSI atau FC tradisional.

Pendekatan ini menggunakan dua node klaster HA dengan penyimpanan JBOD bersama (hanya sekumpulan disk tanpa kecerdasan bawaan). JBOD terhubung ke kedua server melalui pengontrol Host RAID HBA redundan, sehingga setiap node melihat kumpulan disk yang sama dan dapat mengakses array RAID yang sama secara bersamaan.

Solusi ini dapat mencapai kapasitas hingga 180 TB dalam sasis bersama , bekerja dengan drive magnetik atau SSD hot-swap dalam berbagai level RAID. Pengontrol RAID biasanya menggabungkan cache 1 GB masing-masing, dengan cache yang dicerminkan di seluruh pengontrol untuk menjaga konsistensi dan meningkatkan kinerja, serta perlindungan cache berdasarkan superkapasitor sebagai pengganti baterai tradisional.

Komunikasi antar pengontrol biasanya dilakukan melalui tautan SAS , sehingga menghilangkan kebutuhan akan tautan Ethernet heartbeat untuk sinkronisasi status disk. Hal ini menyediakan jalur komunikasi langsung dan sangat andal antara kedua node penyimpanan.

Fitur penting lainnya adalah arsitektur ini biasanya beroperasi dalam mode aktif/aktif pada susunan RAID yang sama . Ini berarti kedua node menyediakan layanan secara bersamaan dan memanfaatkan daya komputasi kedua server, alih-alih membiarkan satu "dalam mode siaga" sampai yang lain gagal. Hal ini menghindari pemborosan 50% investasi perangkat keras yang biasanya terjadi pada klaster aktif/pasif.

Dengan membangun di atas Windows Server 2012 (atau versi yang lebih baru), administrator mendapatkan manfaat dari lingkungan manajemen yang familiar: alat, wizard, konsol manajemen, dan model izin yang sudah dikenal. Waktu pembelajaran diminimalkan, yang juga mengurangi biaya operasional dan risiko selama implementasi.

Solusi HA-DAS ini ditujukan untuk berbagai penggunaan: virtualisasi server Hyper-V, Windows VDI, penyimpanan SAN/NAS, basis data transaksional (OLTP) , gudang data, dan layanan web ketersediaan tinggi . Semua ini dicapai dengan memanfaatkan satu sasis penyimpanan bersama, dua node redundan, dan logika pengelompokan Windows.

Ketersediaan tinggi khusus untuk array QNAP NAS dan Virtualization Station 4.

Di sektor NAS, produsen seperti QNAP telah mengembangkan fitur-fitur canggih untuk mencapai ketersediaan tinggi baik untuk penyimpanan maupun mesin virtual yang dihosting pada perangkat mereka . Secara khusus, mereka menggabungkan sistem operasi QuTS hero (berbasis ZFS) dengan Virtualization Station 4 untuk menawarkan replikasi dan failover secara real-time antara dua perangkat NAS.

Di satu sisi, sistem QuTS hero mengintegrasikan teknologi ketersediaan tinggi (HA) ke dalam NAS itu sendiri , memungkinkan dua perangkat identik (atau serupa) dikonfigurasi sebagai pasangan ketersediaan tinggi. Jika satu NAS gagal, yang kedua akan mengambil alih, dan layanan tetap beroperasi. Ini melindungi penyimpanan dan layanan inti NAS.

Berlandaskan fondasi tersebut, fungsionalitas ketersediaan tinggi yang baru di Virtualization Station 4 (tersedia dalam versi beta di versi terbaru) melangkah lebih jauh: memungkinkan mesin virtual yang berjalan di NAS untuk memiliki toleransi kesalahan tingkat lanjut melalui replikasi waktu nyata antara dua perangkat QNAP.

Fitur ini hanya tersedia pada perangkat QNAP NAS dengan prosesor x86 yang menjalankan QuTS hero dan versi Virtualization Station 4 yang sesuai. Penggunaan teknologi ZFS dan SnapSync sangat penting, karena menyinkronkan data VM antara kedua perangkat NAS secara real-time, memastikan bahwa VM yang direplikasi selalu mutakhir.

Skema pengoperasiannya didasarkan pada dua perangkat NAS yang saling mendukung : NAS A dan NAS B bertindak sebagai node cadangan satu sama lain, secara dua arah. Masing-masing dapat memiliki mesin virtualnya sendiri, dan untuk mesin virtual yang ditandai sebagai terlindungi HA (High Availability), replika dibuat pada NAS lainnya. Jika salah satu perangkat mengalami kegagalan, perangkat lainnya akan mengambil alih dan memulai mesin virtual yang terpengaruh.

Hal ini memungkinkan peralihan server NAS yang mulus . Perlindungan Ketersediaan Tinggi (HA) dapat diaktifkan hanya untuk VM kritis tertentu tanpa memengaruhi layanan NAS lainnya (misalnya, pencadangan, berbagi file, dll.). Setiap NAS dapat terus menjalankan fungsi aslinya sambil secara bersamaan melindungi mesin virtual yang ditunjuk untuk ketersediaan tinggi.

Sinkronisasi waktu nyata berbasis SnapSync memastikan bahwa, jika terjadi insiden, failover berlangsung hampir seketika dan tanpa kehilangan data . Tidak seperti arsitektur tradisional yang bergantung pada area penyimpanan bersama (SAN) pusat, solusi ini menghilangkan titik kegagalan tunggal tersebut: setiap NAS menyimpan salinan lengkap dan konsisten dari VM yang dilindunginya.

Selain itu, QNAP mendefinisikan beberapa kondisi kegagalan yang dapat memicu failover : beban CPU yang berlebihan dalam jangka waktu lama (di atas ambang batas tertentu, misalnya, 80% untuk jangka waktu tertentu), suhu sistem yang berlebihan, kegagalan disk bahkan dalam konfigurasi RAID, hilangnya salah satu catu daya redundan, dan lain-lain. Sistem mengevaluasi kondisi ini dan, jika NAS dianggap tidak andal, akan mengalihkan beban ke node lain.

Sistem ini juga menawarkan opsi migrasi manual , yang sangat berguna ketika tim teknis ingin memindahkan mesin virtual ke NAS lain secara terkontrol untuk tugas pemeliharaan seperti mengganti disk, memperbarui firmware, mengubah pengaturan lanjutan, dll. Migrasi ini sangat cepat (kurang dari satu detik), sehingga prosesnya hampir tidak terlihat oleh pengguna.

Hal menarik lainnya adalah tidak ada biaya lisensi tambahan : fungsionalitas ketersediaan tinggi di Virtualization Station 4 merupakan bagian dari aplikasi itu sendiri dan termasuk dalam sistem, tanpa pembayaran tambahan per node atau per VM. Hal ini membuatnya sangat menarik bagi UKM dan lingkungan yang mencari ketersediaan tinggi dengan biaya yang wajar.

Persyaratan dan keterbatasan ketersediaan tinggi di QNAP

Untuk berhasil menerapkan solusi ini pada QNAP, sangat penting untuk memenuhi persyaratan perangkat lunak, perangkat keras, dan jaringan tertentu . Persyaratan tersebut tidak terlalu rumit, tetapi penting untuk memahaminya dengan sangat jelas sebelum merancang lingkungan.

Mengenai perangkat lunak, diperlukan QuTS hero versi h5.3 atau lebih tinggi dan Virtualization Station 4.1 atau lebih baru. Hanya versi-versi ini yang menyertakan fungsionalitas HA VM berbasis SnapSync. Fitur ini tidak tersedia pada perangkat NAS dengan QTS "klasik" atau versi Virtualization Station sebelumnya.

Dari segi perangkat keras, kedua perangkat NAS tidak harus persis sama modelnya, tetapi keduanya harus menggunakan prosesor dengan arsitektur dan merek yang sama (baik Intel atau AMD) . Hal ini menyederhanakan kompatibilitas dan memastikan bahwa VM yang direplikasi dapat berjalan lancar di kedua perangkat.

Terkait jaringan, sangat penting bahwa kedua perangkat NAS berada pada segmen jaringan yang sama dan terdapat koneksi langsung di antara keduanya menggunakan kabel jaringan fisik khusus untuk sinkronisasi data mesin virtual. Tautan khusus ini bertindak sebagai saluran "di luar jalur" untuk replikasi, mencegah gangguan pada lalu lintas pengguna normal.

Pada praktiknya, persyaratan perangkat keras sebenarnya bermuara pada hal ini: keluarga CPU yang sama dan koneksi langsung antara perangkat NAS . Segala hal lainnya (kapasitas disk, RAM, dll.) disesuaikan berdasarkan jumlah VM yang akan dilindungi dan kinerja yang diharapkan. Jika kondisi ini terpenuhi, pengaturan HA QNAP relatif mudah dan sangat andal.

Perbedaan antara ketersediaan tinggi dan replikasi/pemulihan bencana sederhana pada mesin virtual.

Solusi replikasi mesin virtual sebagai mekanisme pemulihan bencana seringkali disalahartikan dengan ketersediaan tinggi sejati tanpa waktu henti (atau waktu henti minimal). Keduanya penting, tetapi mereka menyelesaikan masalah yang berbeda.

Sebagai contoh, dalam lingkungan VMware vSphere, umum untuk mengkonfigurasi replikasi VM ke situs pemulihan bencana (DR) , sehingga citra disk server utama disalin ke node pemulihan bencana. Ini melindungi dari kehilangan total situs utama, tetapi ketika gagal, pemulihan manual biasanya diperlukan: menghidupkan VM di situs DR, mengkonfigurasi ulang jaringan, memvalidasi integritas data, dan sebagainya.

Proses ini, meskipun sebagian dapat diotomatisasi, melibatkan waktu henti yang dapat berkisar dari menit hingga jam, tergantung pada kompleksitas lingkungan dan prosedur internal. Ini adalah strategi DR yang sangat baik, tetapi tidak memenuhi tujuan ketersediaan hampir terus-menerus yang diharapkan dari solusi HA yang ketat.

Ketersediaan tinggi sejati memerlukan mekanisme failover otomatis atau hampir otomatis dengan waktu henti yang sangat rendah dan tanpa perlu operasi manual yang kompleks ketika suatu komponen gagal. Selain itu, sinkronisasi data antara node aktif dan cadangan harus cukup ketat untuk mencegah atau meminimalkan hilangnya informasi terkini.

Oleh karena itu, saat merancang lingkungan VM yang sangat tersedia, sangat penting untuk menggabungkan teknologi clustering, replikasi mendekati waktu nyata, penyimpanan redundan, dan pemantauan proaktif dengan benar . Hanya dengan cara ini pengguna dapat terus mengakses situs web, basis data, atau aplikasi perusahaan dengan gangguan minimal, bahkan jika seluruh server atau NAS tiba-tiba mati.

Dalam praktiknya, pendekatan yang paling umum adalah melengkapi ketersediaan tinggi lokal (misalnya, klaster dalam pusat data yang sama) dengan strategi pemulihan bencana di lokasi yang berbeda . Dengan cara ini, baik kegagalan sehari-hari (disk, server, catu daya, dll.) maupun kejadian yang lebih serius (kebakaran, pemadaman listrik yang berkepanjangan, bencana alam) dapat ditangani.

Beragam solusi ini—kluster RHEL dan Hyper-V, arsitektur HA-DAS tanpa SAN, ketersediaan tinggi khusus pada QNAP NAS dengan Virtualization Station, dan replikasi VM tingkat lanjut—menunjukkan bahwa kini dimungkinkan untuk merancang lingkungan virtualisasi yang sangat toleran terhadap kesalahan yang disesuaikan dengan berbagai ukuran dan anggaran perusahaan . Pemahaman menyeluruh tentang perbedaan antara setiap pendekatan, keterbatasannya (seperti jumlah node maksimum atau kebutuhan penyimpanan bersama), dan persyaratan teknisnya sangat penting untuk memilih kombinasi yang tepat dan menjaga agar layanan penting tetap berjalan hampir tanpa hambatan.