Gambar diambil dari https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview Kasus penggunaan utama yang ditargetkan adalah infrastruktur hyper-converged untuk penyebaran Hyper-V. Namun, ada kasus penggunaan lainnya, termasuk memanfaatkan penyimpanan SMB ini untuk menyimpan Data SQL Server yang akan digunakan dalam SQL Server Failover Cluster Instance

Kenapa ada yang mau melakukan itu?

Nah, sebagai permulaan Anda sekarang dapat membangun SQL Server Failover Cluster Instance 2-node yang sangat tersedia (FCI) dengan SQL Server Standard Edition, tanpa perlu penyimpanan bersama. Sebelumnya, jika Anda ingin HA tanpa SAN Anda cukup terdorong untuk membeli SQL Server Enterprise Edition dan memanfaatkan Always On Availability Groups atau membeli SIOS DataKeeper dan memanfaatkan solusi pihak ke-3 yang memungkinkan Anda membangun cluster SANless dengan versi Windows apa pun atau SQL Server. SQL Server Enterprise Edition benar-benar dapat menaikkan biaya proyek Anda, terutama jika Anda hanya membeli untuk fitur Ketersediaan Grup. Selain biaya yang terkait dengan Grup Ketersediaan, ada sejumlah alasan teknis lainnya mengapa Anda mungkin lebih memilih Failover Cluster daripada AG. Kompatibilitas aplikasi, misalnya terhadap perlindungan tingkat basis data, sejumlah besar basis data, dukungan DTC, staf terlatih, dll., Hanyalah sebagian dari alasan teknis mengapa Anda mungkin ingin tetap menggunakan Mesin Virtual Failover.

SIOS DataKeeper Solusi Vs S2D Untuk SQL Server Failover Cluster Instances 

Microsoft mencantumkan solusi SIOS DataKeeper dan solusi S2D sebagai dua solusi yang didukung untuk SQL Server FCI dalam dokumentasinya di sini. https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-high-availability-dr Ketika membandingkan dua solusi, Anda harus mempertimbangkan bahwa SIOS telah memungkinkan Anda membangun Cluster SANAST sejak 1999. Tetapi S2D Untuk SQL Server Failover Cluster Instances masih dalam masa pertumbuhan.  Karena itu, pasti ada beberapa area di mana S2D memiliki beberapa hal yang harus dilakukan. Atau, sekadar fitur yang tidak akan pernah mereka dukung semata-mata karena keterbatasan teknologi.

Sebelum Memilih Solusi Cluster SANless Anda

Silahkan lihat tabel berikut untuk ikhtisar tentang beberapa hal yang harus Anda pertimbangkan sebelum Anda memilih solusi cluster SANless Anda. Jika kita melihat grafik ini, kita melihat bahwa SIOS DataKeeper jelas memiliki beberapa keuntungan yang signifikan. Untuk satu, DataKeeper mendukung berbagai platform yang lebih luas, akan kembali ke Windows Server 2008 R2 dan SQL Server 2008 R2. Solusi S2D hanya mendukung rilis terbaru Windows dan SQL Server 2016/2017. S2D juga membutuhkan Edisi Datacenter Windows, yang dapat menambah biaya penyebaran Anda secara signifikan. Selain itu, SIOS memberikan solusi HANYA HA / DR untuk SQL Server di Linux yang berfungsi baik on-prem maupun di cloud.

Analisis Perbedaan

Tapi di luar batasan biaya dan platform, saya pikir kesenjangan yang paling mencolok datang ketika kita mulai mempertimbangkan opsi pemulihan bencana untuk cluster SANless Anda. Allan Hirt, SQL Server Cluster guru dan sesama Microsoft Cloud dan Manajemen Datacenter MVP, baru-baru ini diposting tentang keterbatasan S2D ini. Dalam artikelnya, Revisiting Storage Spaces Direct dan SQL Server FCIs Allan menunjukkan bahwa karena kurangnya dukungan untuk memperluas cluster S2D di seluruh situs atau termasuk cluster berbasis S2D sebagai kaki dalam Always On Availability Group, pilihan terbaik untuk DR di Skenario S2D adalah pengiriman log! Jangan salah paham. Pengiriman kayu telah ada selamanya dan mungkin akan lama setelah saya pergi. Tapi itu mengambil langkah BESAR mundur ketika kita berpikir tentang semua solusi pemulihan bencana yang telah kita kuasai, seperti kluster multi-situs, Grup Ketersediaan, dll. Sebaliknya, solusi SIOS DataKeeper sepenuhnya mendukung Always On Availability Groups. Lebih baik lagi – ini dapat memungkinkan Anda untuk memperluas FCI Anda di seluruh situs untuk memberikan solusi HA / DR terbaik yang dapat Anda harapkan untuk dicapai dalam hal RTO / RPO. Di lingkungan Azure, DataKeeper juga mendukung Azure Site Recovery (ASR), memberi Anda lebih banyak pilihan untuk pemulihan bencana. Sisa dari grafik ini cukup jelas. Ini pada dasarnya terdiri dari daftar perangkat keras, penyimpanan dan persyaratan jaringan yang harus dipenuhi sebelum Anda dapat menyebarkan gugus S2D. Daftar lengkap persyaratan S2D dipertahankan di sini.  https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-hardware-requirements

SIOS Datakeeper. Apa yang baik

Solusi SIOS DataKeeper jauh lebih lunak. Mendukung penyimpanan lokal apa pun dan selama perangkat keras melewati validasi klaster, itu adalah konfigurasi klaster yang didukung. Solusi replikasi block level telah bekerja hebat sejak 1 Gbps dianggap sebagai LAN cepat dan koneksi T1 WAN dianggap mewah. Pemetaan SANless sangat menarik untuk penyebaran cloud. Cloud tidak menawarkan opsi penyimpanan bersama tradisional untuk kluster. Jadi bagi pengguna di tengah "angkat dan bergeser" ke awan yang ingin membawa kelompok mereka dengan mereka, mereka harus melihat solusi penyimpanan alternatif. Untuk penyebaran cloud, SIOS disertifikasi untuk Azure, AWS, dan Google dan tersedia di pasar cloud yang relevan. Meskipun tampaknya tidak ada yang memblokir penyebaran gugus berbasis S2D di Azure atau Google, ada kurangnya dokumentasi atau pernyataan dukungan yang jelas dari Microsoft untuk platform tersebut.

Buat Pilihan yang Aman

SIOS DataKeeper telah melakukan ini sejak tahun 1999. SIOS telah mendengar semua permintaan fitur, menemukan semua bug, dan memiliki solusi padat batuan untuk cluster SANless yang telah teruji dan terbukti. Sementara Microsoft S2D adalah teknologi yang menjanjikan, sebagai produk generasi pertama saya akan menunggu sampai debu mengendap dan beberapa celah fitur menutup sebelum saya mempertimbangkannya untuk aplikasi bisnis penting saya.