Grup Ketersediaan Selalu Aktif Failover Otomatis tidak berfungsi


10

Bermain dengan pengaturan AG Saya memiliki WSFC dan dikonfigurasi dengan dua node dalam satu grup ketersediaan yang disebut DevClusterOnline. Kedua node (DEV-AWEB5 primer, DEV-AWEB6 sekunder) menjalankan Windows Server 2008 R2.

Jika saya memeriksa kesehatan AG saya, saya mendapatkan ini:

Deskripsi Kesehatan Kelompok Ketersediaan

Menjalankan kueri di bawah ini akan mengembalikan set hasil ini: Sinkronisasi komit dan pengaturan failover otomatis

select
    ar.replica_server_name,
    availability_group_name = ag.name,
    ar.availability_mode_desc,
    ar.failover_mode_desc
from sys.availability_replicas ar
inner join sys.availability_groups ag
on ar.group_id = ag.group_id
order by availability_group_name, replica_server_name;

Jika saya memutuskan DEV-AWEB5, saya tidak dapat terhubung ke Group Listener (DevListener), tetapi saya bisa melakukan ping dan itu akan menanggapi ping saya. Replika - DEV-AWEB6 masuk ke keadaan PENYELESAIAN dan DB saya tidak dapat diakses. Namun saya bisa, secara manual masuk ke Management Studio dan mengatur Failover ke DEV-AWEB6 dan kemudian saya berdiri dan berjalan lagi dan DevListener akan sekali lagi menerima koneksi.

Menimbang bahwa fakta-fakta ini mengkonfirmasi bahwa failover benar-benar berfungsi, bahwa saya telah melakukan sinkronisasi dan failover otomatis dikonfigurasi, saya tidak tahu bagaimana jika tidak berfungsi dalam pengaturan saya.

Ketika saya memutuskan DEV-AWEB5 saya berharap bahwa replika saya akan mempertahankan koneksi dan dengan demikian, DevListener juga. Saya berharap bahwa failover otomatis akan memungkinkan saya untuk terhubung ke AG Listener secara transparan. Dari perspektif pengguna akhir, menggunakan sistem Web seharusnya tidak terlihat bahwa salah satu server DB turun.

Saya terjebak di sini, dapatkah ada yang memberi tahu saya tentang apa yang saya lakukan salah?


1
Seperti apa model kuorum Anda? Apakah ini mayoritas simpul sederhana? Jika demikian, itu bisa menjadi masalah Anda. Dari technet.microsoft.com/en-us/library/cc731739.aspx , model kuorum itu hanya dapat mempertahankan hilangnya (setengah dari simpul dalam gugus) -1. Jadi, jika Anda memiliki dua simpul cluster dengan kuorum simpul mayoritas, Anda dapat mempertahankan 0 simpul kegagalan.
Ben Thul

2
@ BenTul Jika cluster kehilangan kuorum maka OP tidak akan bisa gagal secara manual.
Thomas Stringer

Jawaban:


6

Jika saya lepaskan DEV-AWEB5

Tentukan "putuskan", jika Anda mau. Dugaan saya adalah Anda menyimpan kotak tetapi mengambil SQL Server.

Saya tidak dapat terhubung ke Group Listener (DevListener), tetapi saya dapat melakukan ping dan itu akan menanggapi ping saya

Itu karena pendengar hanyalah nama jaringan virtual (VNN) dalam grup sumber daya WSFC untuk grup ketersediaan yang diwakili. Node DEV_AWEB5 Anda masih memiliki grup sumber daya gugus, tetapi hanya sumber daya gugus AG yang kemungkinan besar dalam kondisi gagal. VNN harus tetap online (perilaku yang diharapkan). Itu hanya menunjuk ke simpul apa pun yang memiliki grup sumber daya itu (dalam hal ini, DEV-AWEB5). Bahkan, jika Anda mengaktifkan PowerShell remoting, dan Anda menjalankan yang berikut:

Invoke-Command -ComputerName "YourListenerName" -ScriptBlock { $env:computername }

Demikian juga, jika Anda dapat RDP ke DEV-AWEB5 (asalkan Anda memiliki kemampuan dan aksesibilitas, dll.) Maka Anda akan dapat RDP menggunakan nama pendengar ( mstsc /v:YourListenerName). Itu hanya VNN.

Kembalinya itu akan menjadi nama komputer dari simpul yang Anda miliki.

Dengan semua gejala Anda, saya berani bertaruh bahwa Anda telah mencapai ambang kegagalan Anda. Ambang failover menentukan berapa kali kluster akan mencoba untuk failover grup sumber daya Anda dalam periode waktu tertentu. Default dari nilai-nilai ini max failovers n - 1 (di mana n adalah jumlah node) dalam periode 6 jam . Anda dapat melihatnya melalui perintah PowerShell WSFC berikut:

Get-ClusterGroup -Name "YourAgName" |
    Select-Object Name, FailoverThreshold, FailoverPeriod

Itu hanya memberi Anda pengaturan (yang dapat Anda modifikasi jika Anda memilihnya, tentu saja).

Cara terbaik untuk membuktikan bahwa ini adalah kasus untuk Anda, Anda perlu membuat log cluster (log peristiwa sistem hanya masuk ke detail sejauh "telah gagal", atau sesuatu seperti itu).

Get-ClusterLog -Node "YourClusterNode" -TimeSpan <amount_of_minutes_since_failure>

Itu secara default akan dimasukkan ke dalam folder "C: \ Windows \ Cluster \ Reports", dan file tersebut disebut "Cluster.log".

Jika Anda membuka log cluster, Anda harus dapat menemukan string berikut di sana, menunjukkan dengan tepat apa yang terjadi dan mengapa itu terjadi:

Tidak gagal di atas grup [YourClusterGroupName] , failoverCount [# failovers] , ambang failover [nilai ambang failover] , nodeAvailCount [jumlah simpul tersedia ].

Pesan di atas hanya WSFC memberitahu Anda bahwa itu tidak akan gagal dari grup Anda karena itu terjadi terlalu banyak (Anda mencapai ambang batas).

Mengapa ini terjadi? Hanya untuk mencegah efek Ping-Pong dari sumber daya cluster bolak-balik terlalu sering antara node.

Sedangkan ini akan umum untuk mencapai ambang ini dalam pengujian failover, dalam produksi biasanya akan menunjuk ke masalah yang harus diselidiki.


2
Terima kasih atas bantuan Anda, saya mengikuti arahan Anda tetapi saya akhirnya menemukan bahwa ini bukan masalah. Alasan saya tidak bisa membuat AG gagal secara otomatis adalah karena saya belum mengkonfigurasi dependensi WSFC dengan benar. Ternyata saya perlu menambahkan MSSQL sebagai sumber daya klaster (Layanan Generik) dan menambahkannya sebagai ketergantungan pada Failover Cluster Manager bersama dengan pendengar AG. Juga, perlu untuk mencentang kotak centang 'Jika restart tidak berhasil, gagal semua sumber daya dalam layanan atau aplikasi ini'. Saya yakin Anda mendapat kesan bahwa saya sudah melakukan ini.
Marcus

1

Menambahkan MSSQL sebagai Sumber Daya Layanan Umum bukanlah Jawabannya.

Itu hanya akan menempatkan Cluster Manager bertanggung jawab atas Layanan SQL Server, OK, ya itu akan gagal secara otomatis, tetapi Anda akan melihat di SQL Server Configuration Manager bahwa layanan Anda sekarang diatur ke "Manual" yang menunjukkan bahwa Cluster Manager adalah sekarang mengendalikan Layanan SQL server Anda.

Anda menempatkan Cluster Manager untuk Aplikasi NON Clustered.

Itu akan berakhir dengan air mata.

Pendekatan yang benar untuk mengkonfigurasi dengan benar Grup ketersediaan SQL Server sesuai dengan dokumentasi MS.

Dan juga memastikan Anda tidak melebihi Parameter Kegagalan seperti Ditetapkan dalam Manajer Cluster> Peran> Tab Kegagalan.

Jika Anda melebihi batas ini, gugus tidak akan gagal atas sumber daya Anda dan kesalahan akan diposting ke Log peristiwa aplikasi.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.