Date: Februari 14, 2021
Tag: SQL Server Failover Cluster Instance
Menggunakan Amazon FSX untuk Instans Cluster Failover SQL Server – Yang Perlu Anda Ketahui!
Jika Anda sedang mempertimbangkan untuk menerapkan instans Microsoft SQL Server Anda sendiri di AWS EC2, Anda harus mengambil beberapa keputusan terkait ketahanan solusi. Tentu, AWS akan menawarkan 99,99% SLA pada sumber daya Compute Anda jika Anda menerapkan dua atau lebih instans di zona ketersediaan yang berbeda. Namun jangan tertipu, ada banyak faktor lain yang perlu Anda pertimbangkan saat menghitung ketersediaan aplikasi Anda yang sebenarnya. Baru-baru ini saya membuat blog tentang cara menghitung ketersediaan aplikasi Anda di cloud. Anda mungkin harus membaca artikel itu dengan cepat sebelum melanjutkan.
Ketika datang untuk memastikan instans Microsoft SQL Server Anda sangat tersedia, itu benar-benar tergantung pada dua pilihan dasar: Always On Availability Group (AG) atau SQL Server Failover Cluster Instance (FCI). Jika Anda membaca artikel ini, saya berasumsi bahwa Anda sangat memahami kedua opsi ini dan secara serius mempertimbangkan untuk menggunakan Instans Cluster Failover SQL Server, bukan SQL Server Always On AG.
Manfaat Instans Cluster Failover Microsoft SQL Server
Daftar berikut meringkas apa yang dikatakan AWS sebagai manfaat dari SQL Server FCI:
FCI umumnya lebih disukai daripada AG untuk penerapan ketersediaan tinggi SQL Server ketika berikut ini adalah masalah prioritas untuk kasus penggunaan Anda:
Efisiensi biaya lisensi: Anda memerlukan lisensi Edisi Perusahaan dari SQL Server untuk menjalankan AG, sedangkan Anda hanya memerlukan lisensi Edisi Standar untuk menjalankan FCI. Ini biasanya 50–60% lebih murah daripada Edisi Perusahaan. Meskipun Anda dapat menjalankan AG versi Dasar pada Edisi Standar mulai dari SQL Server 2016, versi ini memiliki batasan untuk hanya mendukung satu database per AG. Ini bisa menjadi tantangan saat berhadapan dengan aplikasi yang membutuhkan banyak database seperti SharePoint.
Perlindungan tingkat instance versus perlindungan tingkat database: Dengan FCI, seluruh instance dilindungi – jika node utama tidak tersedia, seluruh instance akan dipindahkan ke node standby. Ini menangani login SQL Server, pekerjaan Agen Server SQL, sertifikat, dll. Yang disimpan di database sistem, yang secara fisik disimpan di penyimpanan bersama. Sebaliknya, dengan AG, hanya database dalam grup yang dilindungi, dan database sistem tidak dapat ditambahkan ke AG – hanya database pengguna yang diizinkan. Ini adalah tanggung jawab administrator database untuk mereplikasi perubahan ke objek sistem pada semua replika AG. Ini menyisakan kemungkinan kesalahan manusia yang menyebabkan database menjadi tidak dapat diakses oleh aplikasi.
Dukungan fitur DTC: Jika Anda menggunakan SQL Server 2012 atau 2014, dan aplikasi Anda menggunakan Distributed Transaction Coordinator (DTC), Anda tidak dapat menggunakan AG karena tidak didukung. Gunakan FCI dalam situasi ini.
Tantangan Dengan FCI In The Cloud
Tentu saja. Tantangan dalam membangun FCI yang mencakup zona ketersediaan adalah kurangnya perangkat penyimpanan bersama yang biasanya diperlukan. Karena node cluster didistribusikan di beberapa pusat data, SAN tradisional bukanlah pilihan yang layak untuk penyimpanan bersama. Itu membuat kami memiliki dua pilihan untuk penyimpanan klaster: sumber daya kelas penyimpanan pihak ketiga seperti SIOS DataKeeper atau Amazon FSx baru.
Mari kita lihat apa yang perlu Anda ketahui sebelum Anda membuat pilihan.
PERSETUJUAN TINGKAT LAYANAN
Seperti yang saya tulis di cara menghitung ketersediaan aplikasi Anda, SLA aplikasi Anda secara keseluruhan hanya sebagus tautan terlemah Anda. Dalam hal ini, FSx SLA 99,9%.
Biasanya 99,99% ketersediaan mewakili titik awal dari apa yang dianggap "sangat tersedia". Inilah yang dijanjikan AWS untuk sumber daya komputasi Anda ketika dua atau lebih disebarkan di zona ketersediaan yang berbeda.
Jika Anda tidak tahu perbedaan antara tiga sembilan dan empat sembilan…
- Ketersediaan 99,9% memungkinkan waktu henti 43,83 menit per bulan
- Ketersediaan 99,99% hanya memungkinkan waktu henti 4,38 menit per bulan
Dengan menghosting penyimpanan cluster Anda di FSx terlepas dari 99,99% ketersediaan komputasi Anda, ketersediaan aplikasi Anda secara keseluruhan akan menjadi 99,9%. Sebaliknya, volume EBS yang menjangkau zona ketersediaan, seperti dalam penerapan DataKeeper, memenuhi syarat untuk 99,99% SLA di lapisan penyimpanan dan komputasi. Ini berarti ketersediaan aplikasi Anda secara keseluruhan adalah 99,99%.
LOKASI PENYIMPANAN
Saat mengonfigurasi FSx untuk ketersediaan tinggi, Anda mungkin ingin mengaktifkan dukungan multi-AZ. Dengan mengaktifkan multi-AZ Anda memiliki AZ "pilihan" dan AZ "siaga" secara efektif. Saat Anda menerapkan node SQL Server FCI, Anda akan ingin mendistribusikan node tersebut ke AZ yang sama.
Sekarang dalam situasi normal, Anda ingin memastikan node cluster aktif berada di AZ yang sama dengan node penyimpanan FSx pilihan. Ini untuk meminimalkan jarak dan latensi ke penyimpanan Anda. Tetapi juga untuk meminimalkan biaya yang terkait dengan transfer data di seluruh AZ. Sebagaimana ditentukan dalam panduan harga FSx, "Biaya transfer data standar berlaku untuk akses antar-AZ atau antar-wilayah ke sistem file."
Dalam keadaan yang tidak menguntungkan di mana Anda mengalami kegagalan SQL Server FCI, tetapi bukan kegagalan FSx, tidak ada mekanisme untuk mengikat penyimpanan dan penghitungan bersama. Jika FSx gagal, secara otomatis gagal kembali ke zona ketersediaan utama. Namun, praktik terbaik menentukan SQL FCI tetap berjalan di node sekunder hingga analisis akar masalah dilakukan dan kegagalan kembali biasanya dijadwalkan untuk terjadi selama periode pemeliharaan. Ini membuat Anda berada dalam situasi di mana penyimpanan Anda berada di AZ yang berbeda, yang akan menimbulkan biaya tambahan. Saat ini biaya untuk mentransfer data di seluruh AZ, baik masuk maupun keluar, adalah $ 0,01 / GB.
Tanpa memperhatikan status FSx dan SQL Server FCI Anda, Anda bahkan mungkin tidak menyadari bahwa keduanya berjalan di wilayah yang berbeda hingga Anda melihat biaya transfer data di akhir bulan.
Sebaliknya, dalam konfigurasi yang menggunakan SIOS DataKeeper, penyimpanan failover adalah bagian dari pemulihan SQL Server FCI, memastikan bahwa penyimpanan selalu gagal dengan contoh SQL Server. Ini memastikan SQL Server selalu membaca dan menulis ke volume EBS yang langsung terpasang ke node aktif. Perlu diingat, DataKeeper akan dikenakan biaya transfer data terkait dengan operasi tulis yang direplikasi antara AZ atau wilayah. Biaya transfer data ini dapat diminimalkan dengan penggunaan kompresi yang tersedia di DataKeeper.
MENGONTROL KEGAGALAN
Dalam konfigurasi multi-subnet FSx, terdapat zona ketersediaan pilihan dan ketersediaan siaga. Jika server file FSx di zona ketersediaan yang disukai mengalami kegagalan, server file di AZ siaga akan pulih. AWS melaporkan bahwa waktu pemulihan ini membutuhkan waktu sekitar 30 detik dengan pembagian standar. Dengan penggunaan berbagi file yang tersedia secara terus menerus, Microsoft melaporkan waktu failover ini dapat mendekati 15 detik. Selama waktu failover ini, terjadi penurunan yang terjadi saat pembacaan dan penulisan dijeda, tetapi akan berlanjut setelah pemulihan selesai.
Multi-situs FSx mengaktifkan failback otomatis. Ini berarti bahwa untuk setiap failover FSx yang tidak direncanakan, Anda juga memiliki failback yang tidak direncanakan. Sebaliknya, biasanya saat SQL Server FCI mengalami failover yang tidak direncanakan, Anda akan membiarkannya berjalan di sekunder atau menjadwalkan failback setelah jam kerja atau selama periode pemeliharaan berikutnya.
SQL SERVER ANALYSIS SERVICES CLUSTER TIDAK DIDUKUNG DENGAN FSX
Jika Anda ingin mengelompokkan SSAS, Anda memerlukan sumber daya disk berkerumun seperti SIOS DataKeeper. Buku putih Cara Mengelompokkan SQL Server Analysis Server dengan jelas menyatakan bahwa SMB tidak dapat digunakan dan pengandar kluster dengan huruf kandar harus digunakan. Sebaliknya, sumber daya Volume DataKeeper menampilkan dirinya sebagai disk berkerumun dan dapat digunakan dengan SSAS.
Ringkasan
Meskipun FSx dapat dimengerti untuk penggunaan UKM biasa seperti file pengguna Windows dan layanan non-kritis lainnya di mana 99,9% ketersediaan SLA mencukupi, FSx adalah pilihan yang sangat baik Jika aplikasi Anda membutuhkan ketersediaan tinggi (99,99%) atau solusi HA / DR yang juga mencakup wilayah, SIOS DataKeeper adalah pilihan yang tepat.