Downtime! Siapa yang Harus Membawa Tanggung Jawabnya?

Memastikan Pilihan Ketersediaan Tinggi Untuk SQL Server sepanjang waktu mungkin merupakan alasan utama kami menggunakan Layanan Cloud. Namun, melindungi terhadap waktu henti yang terkait dengan penghentian cloud adalah sesuatu yang perlu ditangani siapa pun yang menggunakan layanan cloud APAPUN. Sangat mudah untuk hanya menyebarkan aplikasi Anda di "awan" dan menganggap bahwa itu adalah masalah orang lain yang harus dikelola sekarang. Penyedia cloud mungkin memiliki lebih banyak sumber daya dan keahlian untuk memastikan server Anda tetap terjaga. Tetapi tanggung jawab utama untuk memastikan bahwa aplikasi kritis Anda tersedia berada di pundak Anda.

Opsi Ketersediaan Tinggi Untuk SQL Server Tidak Semudah ABC

Percaya atau tidak, cukup menggelar SQL Server Anda di Windows Azure tidak membuatnya "sangat tersedia". Untuk membuatnya sangat tersedia, Anda harus menggunakan alat dan teknik tradisional yang mungkin Anda gunakan di datacenter Anda sendiri. Meskipun ada beberapa perbedaan pendapat tentang topik ini, saya percaya bahwa Opsi Ketersediaan Tinggi untuk SQL Server 2012/2014 adalah sebagai berikut:

• Contoh Cluster AlwaysOn Failover
• Kelompok Ketersediaan AlwaysOn
• Cluster Multisite (ketersediaan tinggi DAN pemulihan bencana)

Terlepas dari pilihan mana yang Anda pilih, Anda akan ingin menjadi akrab dengan Windows Azure Fault Domain seperti yang dijelaskan di bawah ini:

"Meskipun demikian, di Windows Azure rak komputer memang diidentifikasi sebagai domain kesalahan. Dan alokasi domain kesalahan ditentukan oleh Windows Azure pada waktu penyebaran. Pemilik layanan tidak dapat mengendalikan alokasi domain kesalahan, namun secara pemrograman dapat mengetahui domain kesalahan mana yang menjalankan layanan. Windows Azure Hitung layanan SLA menjamin tingkat uptime konektivitas untuk layanan yang dikerahkan hanya jika dua atau lebih contoh dari setiap peran layanan dikerahkan "

Miliki SQL Server Anda berada di Domain Fault yang berbeda

Saat Anda mulai menerapkan Windows Azure VMs, pastikan setiap SQL Server dan server "saksi" ada di Domain Fault yang berbeda. Anda melakukan ini dengan meletakkan semua VMs di "Availability Set" yang sama. Intinya, setiap server di Set Ketersediaan yang sama berada di Domain Fault yang berbeda, mudah-mudahan menghilangkan kegagalan.

Masukkan semua VM di Domain Fault yang berbeda dan konfigurasikan Cluster Failover SQL Server atau Grup Ketersediaan untuk melindungi dari jenis pemadaman biasa yang mungkin terlokalisasi ke rak server tunggal, AKA, Fault Domain. Saya telah menulis sebuah artikel selangkah demi selangkah yang berjudul Menciptakan SQL Server 2014 AlwaysOn Failover Cluster (FCI) Instance di Windows Azure IaaS dengan DataKeeper yang seharusnya membantu dalam usaha Anda untuk membangun ketahanan di dalam awan Azure untuk SQL Server Anda.

Tapi Apa Yang Terjadi Jika Windows Azure Memiliki Pemadaman Besar yang Membawa Wilayah Utuh?

Bencana alam atau kesalahan manusia kemungkinan akan menjadi penyebab pemadaman semacam itu. Sayangnya, pada titik ini tidak ada cara untuk meregangkan Jaringan Pribadi Azure Virtual antara dua wilayah Azure yang berbeda. Ini termasuk Asia Tenggara. Namun, Azure Virtual Private Network dapat mendukung koneksi VPN dari situs ke situs dengan sejumlah perangkat VPN terbatas. Perangkat ini berasal dari Cisco, Juniper dan bahkan Microsoft RRAS.

Bagaimana tentang suatu tempat di luar Azure?

Itu membawa kita untuk memikirkan lokasi alternatif di luar Azure, bahkan pusat data pribadi kita sendiri. Baru-baru ini saya menulis sebuah artikel selangkah demi selangkah yang menjelaskan bagaimana cara memperpanjang datacenter premis Anda ke Azure Cloud. Sambungkan datacenter ke Windows Azure, konfigurasikan AlwaysOn Availability Groups atau AlwaysOn Failover Clustering (multisite) untuk perlindungan dari kegagalan Azure yang dahsyat. Saya telah menulis sebelumnya tentang Keuntungan dari Multisite Clustering vs. Grup yang Tersedia. Jadi di lab saya, saya memutuskan untuk membuat contoh SQL Failover Cluster 2-simpul di Azure dan kemudian menambahk^an simpul ke-3 di pusat data utama saya. Saya telah menulis langkah-langkah konfigurasi terperinci di posting blog saya yang berjudul Creating a Multisite Cluster di Windows Azure for Disaster Recovery.

Jika Anda lebih suka menggunakan AlwaysOn Availability Groups, Anda mungkin ingin mengunjungi tutorial yang disebut AlwaysOn Availability Groups di Windows Azure (GUI) dan Konfigurasi Pendengar untuk AlwaysOn Availability Groups di Windows Azure. Jika Anda menggunakan SQL 2008 R2 atau sebelumnya saya yakin Anda bisa mengkonfigurasi mirroring database. Pada titik ini jika Anda pindah ke Azure, saya menduga Anda mungkin menerapkan SQL Server 2012 atau 2014. Teknologi lain seperti Log Shipping dan Replication adalah pilihan untuk memindahkan data, namun saya tidak menganggapnya sebagai solusi ketersediaan tinggi.

Direproduksi dengan izin dari https://clusteringformeremortals.com/2014/01/15/windows-azure-high-avilities-options-for-sql-server-azure-cloud-iaas/