Mengkonfigurasi SQL Server Alwayson Beban Internal Balancer Untuk Pendengar Klien Di Azure Resource Manager (ARM) Deployment Model #Sqlpass

Ambil Pick Anda dengan Dua Model Penerapan

Apa yang akan kita lalui dalam artikel ini adalah mengonfigurasi penyeimbang beban internal SQL Server Alwayson pada model penerapan Resource Manager.

Jika Anda tidak tahu, Azure memiliki dua model penyebaran: Resource Manager (ARM) dan Classic Deployment. Penyebaran klasik adalah cara "lama" dalam melakukan sesuatu dan ARM adalah cara baru dalam melakukan sesuatu. Ada banyak manfaat untuk menggunakan ARM seperti yang dijelaskan dalam artikel Azure Memahami penyebaran Resource Manager dan penerapan klasik. Namun, salah satu fitur baru ARM favorit saya adalah kemampuan untuk memiliki tiga Domain Fault per Set Ketersediaan daripada hanya dua Domain Fault yang Anda dapatkan dengan model penyebaran Klasik. Ini adalah fitur penting untuk SQL Server High Availability.

Model Penyebaran Resource Manager

Dengan tiga domain kesalahan, Anda dapat memastikan bahwa setiap node cluster di cluster dua node dan saksi berbagi file semuanya berada dalam domain kesalahan yang berbeda. Ini mengeliminasi kemungkinan kegagalan Domain Fault tunggal akan berdampak lebih dari satu kuorum vote di cluster Anda.

Model Penerapan Klasifikasi

Pada model Classic Deployment dengan dua domain kesalahan Anda hanya bisa meletakkan dua node cluster dalam set ketersediaan. Untuk ketersediaan maksimal, Anda benar-benar perlu menempatkan saksi berbagi file Anda di lokasi geografis yang berbeda. Tidak ada jaminan bahwa itu tidak akan berakhir dalam domain kesalahan yang sama dengan salah satu dari simpul cluster dan jika Anda menyimpannya di lokasi geografis yang sama. Ini berarti bahwa kegagalan satu domain kesalahan bisa mempengaruhi 2 dari 3 kuorum suara Anda. Ini akan menurunkan seluruh kelompok Anda. Tiga Domain Fault ARM menghilangkan kemungkinan itu.

Manajer Sumber Daya Azure

ARM pasti cara untuk pergi sebagai fitur Azure baru hanya diperkenalkan di ARM. Namun, dokumentasi itu ringan dan beberapa fitur belum cukup sampai.  Termasuk hal-hal seperti dukungan terdokumentasi untuk ExpressRoute. Kedua masalah ini menjadi lebih baik hampir setiap hari. Tapi pengadopsi awal benar-benar harus bekerja ekstra keras sampai Azure menyusul. Satu masalah lainnya adalah Anda tidak bisa mencampuradukkan penyebaran Classic dan ARM. Jadi jika Anda memulai menyusuri jalan dengan penerapan Klasik, pada dasarnya Anda harus memulai dari awal dengan Resource Manager saat Anda beralih. Jika Anda bisa mengatasi sedikit rasa sakit sekarang, ini akan membantu Anda menghindari sakit kepala yang lebih besar tahun depan. Terutama, ketika Anda menemukan bahwa Anda ingin beberapa fitur baru hanya tersedia di ARM.

Mendapatkan Ketersediaan Tinggi SQL Server

Saya harap artikel ini membantu Anda dalam setidaknya satu aspek penerapan ARM Anda – mendapatkan SQL Server yang sangat banyak digunakan. Seperti yang telah saya dokumentasikan di artikel sebelumnya, penggelaran AlwaysOn Availability Groups dan AlwaysOn Failover Cluster Instances di Azure "Classic" memerlukan penggunaan Azure Load Balancer (internal atau eksternal) untuk redirection klien. Mendapatkan yang dikonfigurasi di Classic Azure tidak lurus ke depan. Tapi itu didokumentasikan dengan baik bahwa administrator yang cukup familiar dengan Azure, Failover Clustering, SQL Server dan PowerShell bisa mendapatkannya bekerja.

Mengkonfigurasi ILB dan memperbarui SQL cluster IP Resource

AlwaysOn Availability Groups dan AlwaysOn Failover Cluster Instances menggunakan model ARM deployment masih memerlukan penggunaan Azure Load Balancer untuk redirection klien. Namun langkah-langkah untuk membuat dan mengonfigurasi penyeimbang beban sama sekali berbeda. Sampai hari ini, juga tidak didokumentasikan dengan baik.

Pada artikel ini, saya akan menyoroti langkah-langkah yang diperlukan untuk mengkonfigurasi SQL Server AlwaysOn Internal Load Balancer dan memperbarui SQL cluster IP Resource. Pada artikel berikutnya saya akan memandu Anda melalui keseluruhan proses selangkah demi selangkah dari awal ke atas untuk menciptakan vNet untuk menginstal SQL dan menciptakan cluster.

Kita mulai

Sebelum memulai, saya membuat asumsi berikut bahwa Anda telah melakukan hal berikut:

• Membuat vNet menggunakan ARM
• Provisioned 3 ARM berbasis VMs (DC, SQL1, SQL2)
• Masukkan DC, SQL1 dan SQL2 di Set dan Resource Group yang sama
• Membuat cluster dengan SQL1 dan SQL2 dan menggunakan DC untuk file share saksi
• Membuat AlwaysOn Availability Group atau AlwaysOn Failover Cluster misalnya dengan SIOS DataKeeper Cluster Edition. Dalam kedua kasus ini Anda akan berakhir dengan pendengar klien, yang terdiri dari sumber nama dan sumber daya IP. Konfigurasi AlwaysOn AG dan Failover Cluster Instances sampai pada titik pembuatan penyeimbang beban sama persis seperti pada model penyebaran Azure Classic. Hal ini didokumentasikan di web di banyak tempat termasuk posting blog saya sendiri

Tip Cepat

Sekarang setelah Anda memiliki AlwaysOn AG atau Failover Cluster Instances yang sepenuhnya dikonfigurasi, Anda mungkin memperhatikan bahwa Anda tidak dapat terhubung ke nama cluster dari server manapun selain node yang saat ini host sumber nama cluster SQL. Saya sudah diberitahu bahwa ini karena jaringan Azure tidak mendukung ARPS yang serampangan. Makanya, klien tidak bisa berkomunikasi langsung dengan cluster IP address. Sebaliknya, klien perlu berkomunikasi dengan ILB dan ILB akan mengarahkan lalu lintas ke simpul aktif. Jadi langkah 1 adalah menciptakan ILB. Sampai sekarang ini tidak bisa dilakukan melalui Portal Azure, jadi kita akan menggunakan perintah Azure PowerShell berikut.

[1/6/2016 Update – The directions below assume you are using Azure PowerShell pre-version 1. The script if you are using Azure PowerShell Version 1 or later is detailed in my blog post here.]

Switch-AzureMode -Name AzureResourceManager

Pilih-AzureSubscription -SubscriptionName "MSDN Azure"
# nama langganan mana pun yang Anda gunakan untuk membuat vNet dan VMs Anda

#Diskare variabel Anda menggunakan nilai yang relevan dengan penerapan Anda

$ ResourceGroupName = 'SIOS-EAST-RG'
# Resource Group Name dimana node SQL digunakan

$ FrontEndConfigurationName = 'FE'
#Call itu apa pun yang Anda suka

$ BackendConfiguratioName = 'BE'
#Call itu apa pun yang Anda suka

$ LoadBalancerName = 'ILB'
#Memberikan Nama untuk objek keseimbangan Internal Internal

$ Lokasi = 'eastus2'
# Masukkan lokasi data center VM SQL Anda

$ subname = 'PUBLIK'
# Berikan nama Subnet tempat SQL Nodes ditempatkan

$ ILBIP = '10 .0.0.201 '
# Berikan alamat IP untuk pendengar atau Load Balancer

$ subnet = Dapatkan-AzureVirtualNetwork -ResourceGroupName $ ResourceGroupName |
Get-AzureVirtualNetworkSubnetConfig –name $ subname

$ FEConfig = New-AzureLoadBalancerFrontendIpConfig 
-Nama $ FrontEndConfigurationName -PrivateIpAddress $ ILBIP -SubnetId $ subnet.Id

$ BackendConfig = New-AzureLoadBalancerBackendAddressPoolConfig 
-Nama $ BackendConfiguratioName

#Buat ILB
New-AzureLoadBalancer -Name $ LoadBalancerName -ResourceGroupName 
$ ResourceGroupName -Lokasi $ Lokasi
-FrontendIpConfiguration $ FEConfig -BackendAddressPool $ BackendConfig

ILB Dibuat

Kita harus melihatnya di Azure Portal jika kita mencantumkan semua objek di Resource Group seperti yang ditunjukkan di bawah ini.

Sisa konfigurasi saya yakin juga bisa dilakukan melalui PowerShell. Tapi aku akan menggunakan GUI di teladan saya. Jika Anda ingin menggunakan PowerShell, Anda mungkin bisa mengumpulkan naskah dengan melihat artikel Memulai pengimbangan penyeimbang beban internal menggunakan Azure Resource Manager. Jujur artikel itu membuatku pusing. Aku akan mencari tahu suatu hari dan mencoba untuk mendokumentasikannya dalam format yang mudah digunakan. Untuk saat ini saya pikir GUI baik untuk langkah selanjutnya.

Ikuti juga dengan screen shot di bawah ini. Jika Anda tersesat, ikuti petunjuk navigasi di bagian atas Portal Azure untuk mencari tahu di mana kita berada.

Klik tab Setting Backend Pool. Memilih kolam backend untuk memperbarui Ketersediaan Set dan Mesin Virtual. Simpan perubahan Anda

Konfigurasikan Probe Load Balancer dengan mengklik Add pada tab Probe. Berikan probe sebuah nama dan konfigurasikan untuk menggunakan TCP Port 59999. Saya telah meninggalkan interval probe dan ambang yang tidak sehat diatur ke pengaturan default. Ini berarti akan memakan waktu 10 detik sebelum ILB menghapus simpul pasif dari daftar simpul aktif setelah failover. Ini juga berarti klien Anda mungkin memerlukan waktu hingga 10 detik untuk dialihkan ke node aktif yang baru. Pastikan untuk menyimpan perubahan Anda.

Arahkan ke Tab Load Balancing Rule dan tambahkan aturan baru. Beri aturan itu nama yang masuk akal (SQL1433 atau sejenisnya). Pilih port protokol TCP 1433 (dengan asumsi Anda menggunakan contoh default SQL Server). Pilih 1433 untuk port Backend juga. Untuk Backend Pool, kita akan memilih Backend Pool yang kita buat tadi (BE). Selanjutnya, untuk Probe kita akan memilih Probe yang kita buat tadi. Kami tidak ingin mengaktifkan persistensi Sesi tapi kami ingin mengaktifkan IP Terapung (Direct Server Return). Saya telah meninggalkan batas waktu idle yang ditetapkan ke pengaturan default. Tapi Anda mungkin ingin mempertimbangkan untuk meningkatkan nilai maksimal itu. Saya telah melihat beberapa aplikasi seperti pesan kesalahan log SAP setiap kali koneksi dijatuhkan dan perlu didirikan kembali.

Pada titik ini ILB dikonfigurasi. Hanya ada satu langkah terakhir yang perlu dilakukan. Kita perlu memperbarui Sumber Daya Cluster SQL SQL dengan cara yang persis sama dengan model penerapan Klasik. Untuk melakukan itu Anda perlu menjalankan script PowerShell berikut hanya pada salah satu dari node cluster. Dan membuat catatan, SubnetMask = "255.255.255.255" bukanlah sebuah kesalahan. Gunakan topeng 32 bit terlepas dari apa sebenarnya subnet mask Anda.

# Script ini harus dijalankan pada node cluster primer setelah 
load balancing internal dibuat
# Tentukan variabel

$ ClusterNetworkName = "Jaringan Cluster 1"
# nama jaringan cluster

$ IPResourceName = "SQL IP Address 1 (SQLCluster1)"
# nama sumber alamat IP

$ CloudServiceIP = "10.0.0.201"
# Alamat IP dari Load Balancer Internal Anda

Modul Impor FailoverClusters

# Jika Anda menggunakan Windows 2012 atau lebih tinggi, 
gunakan perintah Get-Cluster Resource. 
Jika Anda menggunakan Windows 2008 R2, 
gunakan perintah kluster res yang dikomentari.

Dapatkan-ClusterResource $ IPResourceName
Set-ClusterParameter -Multiple @ {"Address" = "$ CloudServiceIP";
"ProbePort" = "59999"; SubnetMask = "255.255.255.255";
"Network" = "$ ClusterNetworkName"; "OverrideAddressMatch" = 1; "EnableDhcp" = 0}

# cluster res $ IPResourceName / priv diaktifkanhcp = 0 
overrideaddressmatch = 1 alamat = $ CloudServiceIP probeport = 59999 
subnetmask = 255.255.255.255

Satu Catatan Akhir

Dalam tes awal saya, saya masih tidak dapat terhubung ke nama sumber daya SQL bahkan setelah saya menyelesaikan semua langkah di atas. Setelah membenturkan kepala ke dinding selama beberapa jam, saya menemukan bahwa untuk beberapa alasan, Sumber Nama Cluster SQL tidak terdaftar di DNS. Saya tidak yakin bagaimana itu terjadi atau apakah itu akan terjadi secara konsisten. Jika Anda mengalami masalah dalam menghubungkan saya pasti akan memeriksa DNS. Selain itu, tambahkan nama cluster SQL dan alamat IP sebagai catatan baru jika belum ada di sana.

Dan tentu saja jangan lupa ole baik Windows Firewall. Anda harus membuat pengecualian untuk 1433 dan 59999 atau hanya mematikannya sampai Anda mendapatkan semuanya dikonfigurasi dengan benar seperti yang saya lakukan. Anda mungkin ingin memanfaatkan Grup Keamanan Jaringan Azure, bukan Windows Firewall lokal untuk pengalaman yang lebih terpadu di semua sumber daya Azure Anda.

Semoga berhasil dan beritahu saya bagaimana pengalaman Anda mengonfigurasi SQL Server AlwaysOn Internal Load Balancer dengan Resource Manager.

Direproduksi dengan izin dari https://clusteringformeremortals.com/2015/10/29/configuring-the-sql-server-alwayson-ilb-for-the-client-listener-in-azure-resource-manager-arm-deployment- model-sqlpass /