SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Date: Maret 13, 2018
Tag:

Mengapa Anda Ingin Membangun Server SQL Failover Cluster Instance Di Azure Cloud?

Ada diskusi menarik yang terjadi hari ini di Twitterverse. Pada dasarnya, seseorang mengajukan pertanyaan "Adakah yang mengatur SQL Server Failover Cluster Instance di Azure?" Pembicaraan berikutnya melibatkan beberapa pakar SQL Server yang sangat dihormati. Dan hal itu menyebabkan pertanyaan berikut, "Mengapa Anda ingin membangun contoh Cluster Server Alwaysfeld Failover SQL di awan?"

Pertanyaan itu dapat ditafsirkan dalam dua cara: "Mengapa Anda membutuhkan Ketersediaan Tinggi di Cloud" atau "Mengapa Anda tidak akan menggunakan Grup Ketersediaan AlwaysOn alih-alih Mesin Virtual Failover Cluster?"

Mari kita membahas setiap pertanyaan satu per satu.

Pertanyaan 1 – Mengapa Anda memerlukan Ketersediaan Tinggi di Azure Cloud?

  • Anda mungkin berpikir bahwa hanya karena Anda meng-host contoh SQL Server Anda di Azure, Anda dilindungi oleh SLA uptime 99,95% mereka. Jika Anda berpikir demikian, Anda akan salah. Untuk memanfaatkan SLA 99,95%, Anda harus memiliki setidaknya dua contoh SQL yang berjalan di Set Ketersediaan. Dengan satu contoh menjalankan SQL, Anda pasti bisa berharap bahwa akan ada downtime minimal selama periode pemeliharaan. Tapi, Anda juga rentan terhadap kegagalan yang tidak direncanakan.
  • Dua contoh SQL Server umumnya tidak dapat diimbangi beban. Anda harus menerapkan semacam mekanisme agar server tetap sinkron. Untuk memastikan bahwa jika ada masalah dengan salah satu server, server lain akan dapat terus melayani permintaan. Solusi Ketersediaan Tinggi seperti AlwaysOn Availability Groups, AlwaysOn Failover Cluster Instances dan bahkan Database Mirroring yang tidak berlaku lagi dapat menyediakan ketersediaan SQL Server yang tinggi dalam skenario itu. Solusi lain seperti pengiriman log dan replikasi transaksional mungkin dapat membantu menjaga sinkronisasi data antar server. Tapi mereka biasanya tidak dianggap solusi ketersediaan tinggi dan tidak akan menjamin ketersediaan SQL Server Anda.
  • Microsoft kadang-kadang perlu melakukan perawatan pada Azure yang bisa menjatuhkan seluruh Domain Upgrade dan semua hal berjalan di Domain Upgrade itu. Anda tidak memiliki mengatakan kapan hal ini akan terjadi. Jadi, Anda perlu memiliki mekanisme untuk memastikan bahwa jika mereka harus menjatuhkan contoh SQL Server utama Anda, Anda dapat mengharapkan contoh SQL Server sekunder Anda akan mengambil alih beban kerja tanpa kehilangan sedikit pun. Semua solusi ketersediaan tinggi yang disebutkan di atas dapat memastikan bahwa Anda akan terus berjalan jika Microsoft melakukan perawatan di Domain Upgrade server utama Anda. Microsoft hanya akan melakukan maintenance pada satu Upgrade Domain sekaligus. Ini memastikan bahwa server sekunder Anda akan tetap online dengan asumsi Anda meletakkan keduanya di Set Sisa yang sama.
  • Apa yang Anda lakukan jika ANDA ingin perawatan kinerja pada produksi Anda SQL Server? Mungkin Anda ingin menginstal Service Pack atau hotfix lainnya? Tanpa server sekunder gagal, Anda harus menjadwalkan waktu henti yang direncanakan. Salah satu manfaat utama dari solusi ketersediaan tinggi adalah kemampuan melakukan upgrade rolling, meminimalkan dampak dari downtime yang direncanakan.

Pertanyaan 2 – Mengapa Anda tidak menggunakan AlwaysOn Availability Groups daripada Failover Cluster Instances?

  • Hemat! SQL Server AlwaysOn Ketersediaan Groups membutuhkan Enterprise Edition dari SQL Server. Mengapa tidak menghemat uang dan menggunakan SQL Server Standard Edition dan membangun Failover Clute Instance 2-node sederhana? Kecuali Anda memerlukan Edisi Enterprise karena alasan lain, ini tidak menjadi masalah.
  • Lindungi ENTIRE SQL Server misalnya. AlwaysOn Availability Groups hanya melindungi basis data yang ditentukan pengguna; Anda tidak dapat melindungi database Sistem dan MSDB. Jika Anda membangun SQL Server Failover Cluster Instance sebagai gantinya, Anda melindungi instance ENTIRE, termasuk database System and MSDB.
  • Kemudahan Administrasi. Di Azure, Anda terbatas hanya pada pendengar klien. Ini membatasi Anda hanya pada satu Grup Ketersediaan. Sebaliknya, dengan Failover Cluster Instance satu pendengar klien adalah semua yang Anda butuhkan, jadi tidak ada batasan.
  • Kelelahan Thread Pekerja. Dengan AlwaysOn AG, Anda harus mengawasi thread pekerja yang tersedia. Benang pekerja yang tersedia membatasi jumlah database yang dapat Anda proteksi dengan AlwaysOn AG. Sebaliknya, AlwaysOn Failover Clustering dengan replikasi tingkat blok DataKeeper tidak mengkonsumsi lebih banyak sumber daya untuk setiap database yang Anda tambahkan. Ini berarti Anda dapat mengukur ratusan database tanpa biaya tambahan yang terkait dengan AlwaysOn AG.
  • Bagikan Dukungan Transaksi. AlwaysOn AG tidak mendukung transaksi terdistribusi (DTC). Jika aplikasi Anda memerlukan dukungan DTC, Anda harus melihat AlwaysOn Failover Cluster Instance sebagai gantinya.
  • Dukungan Teknologi Replikasi Lainnya. Jika Anda berencana untuk memasang replikasi Peer to Peer antara dua database yang dilindungi oleh AlwaysOn AG, Anda dapat melupakannya. Sebenarnya, ada banyak batasan yang harus Anda sadari setelah Anda menyebarkan AlwaysOn Availability Groups. AlwaysOn FCI tidak memiliki batasan tersebut.

Kesimpulan

Mengetahui apa yang Anda ketahui di atas, bukankah seharusnya pertanyaan itu benar-benar menjadi "Mengapa saya ingin menerapkan AlwaysOn AG di Cloud ketika saya dapat memiliki solusi yang jauh lebih kuat dan murah untuk membangun contoh Cluster AlwaysOn Failover?"

Jika Anda tertarik untuk membangun Mesin Virtual Cluster AlwaysOn Failover di Azure, lihat posting blog saya Langkah-demi-Langkah: Cara mengkonfigurasi Mesin Virtual SQL Server Failover Cluster (FCI) di Microsoft Azure IaaS #SQLServer #Azure #SANLess

Diproduksi ulang dengan izin dari https://clusteringformeremortals.com/2015/03/05/why-would-you-want-to-build-a-sqlserver-failover-cluster-instance-instance-in-the-azure-cloud/