AlwaysOn Kullanılabilirlik Grubu Otomatik Yük Devretme çalışmıyor


10

AG kurulumu ile oynama WSFC'yi kurdum ve DevClusterOnline adlı bir kullanılabilirlik grubunda iki düğümle yapılandırıldım. Her iki düğüm de (DEV-AWEB5 birincil, DEV-AWEB6 ikincil) Windows Server 2008 R2 çalıştırıyor.

AG'nin sağlığını kontrol edersem şunu elde ederim:

Kullanılabilirlik Grubu Sağlık açıklaması

Aşağıdaki sorguyu çalıştırmak, bu sonuç kümesini döndürür: Senkron kesinleştirme ve otomatik yük devretme kurulumu

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;

DEV-AWEB5'in bağlantısını kesersem, Grup Dinleyicisine (DevListener) bağlanamıyorum, ancak ping atabiliyorum ve ping'ime yanıt verecek. DEV-AWEB6 çoğaltması ÇÖZÜNÜRLÜK durumuna geçer ve DB'm erişilemez. Ancak, el ile Management Studio'ya gidip Yük Devretme'yi DEV-AWEB6'ya ayarlayabilirim ve sonra tekrar çalışır durumda olurum ve DevListener bir kez daha bağlantıları kabul eder.

Bu gerçeklerin yük devretmenin gerçekten çalıştığını doğruladığı göz önünde bulundurularak, senkronize edilmiş taahhütler ve otomatik yük devretme yapılandırılmış olduğumu göz önünde bulundurarak kurulumumda arıza olup olmadığını bilmiyorum.

DEV-AWEB5'in bağlantısını kestiğimde çoğaltmamın bağlantıyı ve dolayısıyla DevListener'ı koruyacağını umuyorum. Otomatik yük devretmenin AG Listener'a şeffaf bir şekilde bağlanmama izin vermesini bekliyorum. Son kullanıcı bakış açısından, bir Web sistemi kullanarak DB sunucularından birinin çöktüğü fark edilmemelidir.

Burada sıkışıp kaldım, kimse yanlış yaptığım şey hakkında beni aydınlatabilir mi?


1
Yetersayı modeliniz neye benziyor? Basit bir düğüm çoğunluğu mu? Eğer öyleyse, bu senin sorunun olabilir. Kaynaktan technet.microsoft.com/en-us/library/cc731739.aspx , bu çekirdek model (kümedeki düğüm yarısı) bir kaybı sürdürebilen -1. Bu nedenle, düğüm çoğunluğu çekirdek sayısına sahip iki düğümlü bir kümeniz varsa, 0 düğüm hatasını devam ettirebilirsiniz .
Ben Thul

2
@BenThul Küme çekirdeği kaybederse, OP el ile yük devretme yapamaz.
Thomas Stringer

Yanıtlar:


6

DEV-AWEB5'in bağlantısını kesersem

İsterseniz "bağlantıyı kes" i tanımlayın. Sanırım kutuyu yukarıda tuttunuz ama SQL Server'ı indirdiniz.

Grup Dinleyicisine (DevListener) bağlanamıyorum, ancak ping atabiliyorum ve ping'ime yanıt verecek

Bunun nedeni, dinleyicinin temsil edilen kullanılabilirlik grubu için WSFC kümesi kaynak grubunda yalnızca bir sanal ağ adı (VNN) olmasıdır. DEV_AWEB5 düğümünüz hala küme kaynak grubunun sahibidir, ancak başarısız durumda olan büyük olasılıkla yalnızca AG küme kaynağıdır. VNN hala çevrimiçi olmalıdır (beklenen davranış). Sadece bu kaynak grubuna sahip olan herhangi bir düğüme işaret eder (bu durumda DEV-AWEB5). Aslında, PowerShell uzaktan kumandasını etkinleştirdiyseniz ve aşağıdakileri çalıştırdıysanız:

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

Benzer şekilde, DEV-AWEB5'e RDP (yetenek ve erişilebilirlik vb. Varsa) dinleyebiliyorsanız, dinleyici adını ( mstsc /v:YourListenerName) kullanarak RDP yapabilirsiniz . Bu sadece bir VNN.

Bunun geri dönüşü, sahip olduğunuz düğümün bilgisayar adı olacaktır.

Tüm belirtilerinizle, yük devretme eşiğinize ulaştığınıza bahse girmeye hazırım. Yük devretme eşiği, kümenin belirli bir zaman diliminde kaynak grubunuzu kaç kez yük devretmeye çalışacağını belirler. Bu değerlerin varsayılan değeri 6 saatlik bir sürede maksimum yük devretme n - 1 (burada n düğüm sayısıdır) . Bunu aşağıdaki WSFC PowerShell komutuyla görebilirsiniz:

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

Bu sadece ayarları verir (tabii ki seçerseniz değiştirebilirsiniz).

Bunun sizin için geçerli olduğunu kanıtlamanın en iyi yolu, küme günlüğünü oluşturmanız gerekir (sistem olay günlükleri yalnızca "başarısız" kadar ayrıntıya girer veya böyle bir şey).

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

Bu, varsayılan olarak "C: \ Windows \ Cluster \ Reports" klasörüne yerleştirilir ve dosyaya "Cluster.log" adı verilir.

Bu küme günlüğünü açacak olsaydınız, tam olarak ne olduğunu ve neden olduğunu gösteren aşağıdaki dizeyi bulabilmelisiniz:

Grubu üzerinde başarısız değil [YourClusterGroupName] , failoverCount [gerçekleştirilen Yük #] , yerine eşik [başarısızlık eşik değeri] , nodeAvailCount [düğümü mevcut sayım ].

Yukarıdaki mesaj basitçe WSFC'nin çok fazla olduğu için grubunuza yük devretmeyeceğini söyler (eşiği vurdunuz).

Bu neden oluyor? Küme kaynaklarının Ping-Pong efektinin düğümler arasında çok sık ileri ve geri gitmesini önlemek için.

Yük devretme testinde bu eşik değerlere ulaşmak yaygın olsa da, üretimde tipik olarak araştırılması gereken bir soruna işaret eder.


2
Yardımınız için teşekkür ederim, talimatlarınızı takip ettim ama sonunda bunun sorun olmadığını gördüm. AG'nin otomatik olarak yük devretme yapamamasının nedeni, WSFC bağımlılıklarını doğru şekilde yapılandırmamış olmamdı. Anlaşıldığı üzere MSSQL'i bir küme kaynağı olarak (Genel Hizmet) eklemem ve Failover Cluster Manager'da AG dinleyicisiyle birlikte bağımlılık olarak eklemem gerekiyordu. Ayrıca, 'Yeniden başlatma başarısız olursa, bu hizmet veya uygulamadaki tüm kaynaklar üzerinde başarısız olun' onay kutusunu işaretlemeniz gerekir. Eminim bunu zaten yaptığım izlenimine kapıldınız.
Marcus

1

MSSQL'i Genel Hizmet Kaynağı olarak eklemek Cevap değildir.

Bu sadece Küme Yöneticisi'ni SQL Server Hizmetinden sorumlu tutacaktır, tamam, evet otomatik olarak başarısız olacaktır, ancak SQL Server Yapılandırma Yöneticisi'nde artık hizmetlerinizin "Manuel" olarak ayarlandığını ve Küme Yöneticisi'nin şimdi SQL sunucu Hizmetinizin kontrolü altında.

Küme Yöneticisi'ni Kümelenmemiş Uygulamadan sorumlu tutuyorsunuz.

Gözyaşlarıyla bitecek.

Doğru yaklaşım, SQL Server kullanılabilirlik gruplarını MS belgelerine göre doğru yapılandırmak için.

Ayrıca, Küme Yöneticisi> Roller> Başarısızlık Sekmesinde Tanımlanan Başarısızlık Parametrelerini aşmadığınızdan emin olun.

Bu sınırları aşarsanız, küme kaynaklarınızın üstesinden gelmez ve Uygulama Olay Günlüğüne bir hata gönderilir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.