Azure Cloud Mencapai Kanada

Azure Cloud Mencapai Kanada

Berita bagus untuk teman-teman Kanada saya karena adopsi Azure dihambat oleh kode kepatuhan penyimpanan data yang ketat. Sekarang dengan awan di tanah Kanada, seharusnya ada jalan yang jauh lebih mudah untuk sampai ke Azure.

Direproduksi dengan izin dari https://clusteringformeremortals.com/2015/06/02/azure-cloud-reaches-canada/

Clustering 101: Win 10 Technical Preview, Replica Penyimpanan, Cloud Witness …

Clustering 101: Windows 10 Pratinjau Teknis, Replica Penyimpanan, Saksi Cloud, Penghasilan Rolling Pendahuluan

Jika Anda melewatkan webinar saya kemarin, Anda bisa melihat rekamannya di sini. Dalam 30 menit saya memberikan gambaran umum tentang beberapa fitur ketersediaan yang paling menarik. Fitur mengagumkan ini akan tersedia di versi Windows Server berikutnya karena dikirimkan pada tahun 2016. Cloud Witness, Storage Replica dan Rolling Cluster OS Updates adalah tiga dari sekian banyak fitur baru yang dirilis dengan v.Next.

Direproduksi dengan izin dari https://clusteringformeremortals.com/2015/03/26/clustering-101-windows-10-technical-preview-storage-replica-cloud-witness-rolling-upgrade-introduction/

SQL Server Management Studio Dalam Cluster Multi-Situs

SQL Server Management Studio Dalam Cluster Multi-Situs

Saat membuat cluster multisite (node ​​pada subnet yang berbeda), Anda akan mendapati bahwa secara default cluster tersebut memungkinkan sumber cluster RegisterAllProvidersIP untuk nama jaringannya. Hal ini menghasilkan dua entri di DNS untuk sumber nama Cluster SQL. Satu untuk setiap alamat IP cluster. Jika Anda menggunakan parameter MultiSubnetFailover = True opsional dalam string koneksi, klien akan mencoba kedua alamat IP secara bersamaan. Setelah itu, koneksi akan terhubung ke server pertama yang merespon. Untuk SQL Server Management Studio Dalam Cluster Multi-Situs, tambahkan pengaturan itu di bawah Parameter Koneksi tambahan.

Direproduksi dengan izin dari https://clusteringformeremortals.com/2015/03/24/sql-server-management-studio-in-a-multi-site-cluster/

Mengapa Membangun Sebuah Server SQL Failover Cluster Instance Di Azure Cloud?

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/

Clustering 101: Mengkonfigurasi kuorum Cluster Windows

Clustering 101: Mengkonfigurasi Kuorum Windows Cluster – Yang Perlu Anda Ketahui

Jika Anda melewatkannya, saya mengadakan webinar mendalam ini di kuorum cluster. Dalam 30 menit saya membahas semua hal yang perlu Anda ketahui tentang kuorum, dari mayoritas simpul melalui Cloud Witness dan segala sesuatu di antaranya. Jika Anda memiliki pertanyaan tambahan tentang kuorum, pos tersebut sebagai komentar di artikel ini. Saya akan dengan senang hati membantu.