Etkin yük devretme kümesi üyeliğinden kaldırılan düğümlerle ilgili sorun yaşıyor

Bu makalede, düğümlerin etkin yük devretme kümesi üyeliğinden rastgele kaldırılması sorunlarının nasıl çözüleceğini açıklar.

Belirtiler

Sorun oluştuğunda, bu olay gibi olayların sistem olay günlüğünüzde günlüğe kaydedilerek olduğunu görüyorsunuz:

Bu olay, kaldırılan düğüm dışında Kümedeki tüm düğümlerde günlüğe kaydedilir. Bu olayın nedeni, Kümedeki düğümlerden birinin bu düğümü aşağı olarak işaretlemesidir. Ardından olayın diğer tüm düğümlerini bildirir. Düğümler bilgilendirildiğinde, kesilen düğüme yönelik sinyal bağlantılarını sonlandırır ve yok eder.

Düğümün işaretlenmesine neden olan şey

Windows 2008 veya 2008 R2 yük devretme kümesindeki tüm düğümler, bu ağdaki küme ağı iletişimine izin verecek şekilde ayarlanmış ağlar üzerinden birbirleriyle konuşur. Düğümler bu ağlar arasında diğer tüm düğümlere sinyal paketleri gönderir. Bu paketlerin diğer düğümler tarafından alınması gerekir ve ardından bir yanıt geri gönderilir. Kümedeki her düğümün, ağın açık ve diğer düğümlerin çalışır durumda olduğundan emin olmak için izleyeceği kendi sinyalleri vardır. Aşağıdaki örnek bu davranışın netleştirilmesine yardımcı olmalıdır:

Bu paketlerden herhangi biri döndürülmezse, belirli bir sinyal başarısız olarak kabul edilir. Örneğin, W2K8-R2-NODE2 bir istek gönderir ve W2K8-R2-NODE1'den bir sinyal paketine yanıt alır, böylece ağı belirler ve düğüm çalışır durumda olur. W2K8-R2-NODE1 W2K8-R2-NODE2'ye bir istek gönderirse ve W2K8-R2-NODE1 yanıtı almazsa, kayıp sinyal olarak kabul edilir ve W2K8-R2-NODE1 bunu izler. Bu cevapsız yanıt, W2K8-R2-NODE1'in başka bir sinyal isteği alınana kadar ağı devre dışı olarak göstermesini sağlayabilir.

Varsayılan olarak, bağlantı işaretlenmeden önce Küme düğümleri 5 saniye içinde beş hata sınırına sahiptir. Bu nedenle, W2K8-R2-NODE1 yanıtını zaman aralığında beş kez almazsa, W2K8-R2-NODE2'ye giden belirli bir yolun devre dışı bırakıldığını dikkate alır. Diğer yolların hala çalışır durumda olduğu kabul edilirse, W2K8-R2-NODE2 etkin üye olarak kalır.

Tüm yollar W2K8-R2-NODE2 için işaretlenmişse, etkin yük devretme kümesi üyeliğinden kaldırılır ve ilk bölümde gördüğünüz Olay 1135 günlüğe kaydedilir. W2K8-R2-NODE2'de Küme Hizmeti sonlandırılır ve kümeye yeniden katılmayı deneyebilmesi için yeniden başlatılır.

Üç veya daha fazla düğümle belirli yolları nasıl işlediğimiz hakkında daha fazla bilgi için Jeff Hughes tarafından yazılan "Bölümlenmiş" Küme Ağları bloguna bakın.

Sinyal işleminin nasıl çalıştığını bildiğimize göre işlemin başarısız olması için bilinen nedenlerden bazıları nelerdir?

1. Gerçek ağ donanım hataları. Paket düğümler arasında bir yerde kabloda kaybolursa sinyaller başarısız olur. Her iki düğümden de gelen bir ağ izlemesi bunu ortaya çıkaracaktır.

2. Ağ bağlantılarınızın profili Etki Alanından Genel'e ve yeniden Etki Alanı'na geri dönüyor olabilir. Bu değişikliklerin geçişi sırasında ağ G/Ç engellenebilir. Ağ Profili İşlem günlüğüne bakarak durumun böyle olup olmadığını kontrol edebilirsiniz. Olay Görüntüleyicisi açıp Uygulama ve Hizmet Günlükleri\Microsoft\Windows\NetworkProfile\Operational adresine giderek bu günlüğü bulabilirsiniz. Olay Kimliği 1135'te bahsedilen düğümdeki bu günlükteki olaylara bakın ve profilin şu anda değişip değişmediğini görün. Bu durumda bkz. Windows 7 veya Windows Server 2008 R2'de ağ konumu profili "Etki Alanı" yerine "Genel" olarak değişir.

3. Sunucularda IPv6 etkinleştirildi, ancak Windows Güvenlik Duvarı'nda Gelen ve Giden için aşağıdaki iki kural devre dışı bırakıldı:

   • Çekirdek Ağ - Komşu Bulma Tanıtımı
   • Çekirdek Ağ - Komşu Bulma İsteği

4. Virüsten koruma yazılımı da bu süreci engelliyor olabilir. Bundan şüpheleniyorsanız yazılımı devre dışı bırakarak veya kaldırarak test edin. Bu noktada virüslerden korunmadığınız için bunu kendi riskinizle yapın.

5. Ağınızdaki gecikme bunun olmasına da neden olabilir. Paketler düğümler arasında kaybolamayabilir, ancak zaman aşımı süresi dolmadan önce düğümlere yeterince hızlı ulaşamayabilirler.

6. IPv6, Yük Devretme Kümelemesi'nin sinyalleri için kullanacağı varsayılan protokoldür. Sinyal, Bağlantı Noktası 3343 üzerinden iletişim kuran bir UDP tek noktaya yayın ağ paketidir. Bu trafiğe izin vermek için düzgün yapılandırılmamış anahtarlar, güvenlik duvarları veya yönlendiriciler varsa, bunun gibi sorunlarla karşılaşabilirsiniz.

7. IPsec güvenlik ilkesi yenilemeleri de bu soruna neden olabilir. Özel sorun, IPSec grup ilkesi güncelleştirmesi sırasında tüm IPsec Güvenlik İlişkilendirmelerinin (SA) Gelişmiş Güvenlik Özellikli Windows Güvenlik Duvarı (WFAS) tarafından yıkılmasıdır. Bu durum yaşanırken tüm ağ bağlantısı engellenir. Active Directory ile kimlik doğrulaması gerçekleştirmede gecikmeler varsa Güvenlik İlişkilendirmeleri'ni yeniden tartışırken, bu gecikmeler (tüm ağ iletişiminin engellendiği durumlarda) küme sinyallerinin geçmesine engel olur ve küme durumu izlemesinin düğümleri 5 saniyelik eşik içinde yanıt vermezse kapalı olarak algılamasına neden olur.

8. Eski veya güncel olmayan ağ kartı sürücüleri ve/veya üretici yazılımı. Bazen ağ kartının veya anahtarın basit bir yanlış yapılandırılması sinyal kaybına da neden olabilir.

9. Modern ağ kartları ve sanal ağ kartları paket kaybı yaşıyor olabilir. Bu, Performans İzleyicisi açılıp "Ağ Arabirimi\Alınan Paket Atıldı" sayacı eklenerek izlenebilir. Bu sayaç kümülatiftir ve yalnızca sunucu yeniden başlatılana kadar artar. Burada çok sayıda paketin bırakıldığını görmek, ağ kartındaki alma arabelleklerinin çok düşük ayarlandığının veya sunucunun yavaş performans sergilediğinin ve gelen trafiği işleyemediğinin işareti olabilir. Her ağ kartı üreticisi bu ayarların ağ kartının özelliklerinde kullanıma açılıp kullanılmayacağını seçer, bu nedenle bu değerlerin nasıl artırılacağı ve önerilen değerlerin nasıl kullanılacağını öğrenmek için üreticinin web sitesine başvurmanız gerekir. VMware'de çalıştırıyorsanız, aşağıdaki blogda sorunun bu olup olmadığını nasıl anladığınız da dahil olmak üzere bu konu hakkında biraz daha ayrıntılı bir şekilde anlatılır ve sizi değiştirecek ayarlarla ilgili VMware makalesine işaret eder.

   VMware ESX'te Yük Devretme Kümesi üyeliğinden kaldırılan düğümler

Bu olayların günlüğe kaydedilmesinin en yaygın nedenleri bunlardır, ancak başka nedenleri de olabilir. Bu blogun amacı size süreçle ilgili bazı içgörüler sağlamak ve ayrıca neleri aramanız gerekenler hakkında fikir vermekti. Bazıları, bu sorunun durmasını sağlamak için aşağıdaki değerleri en yüksek değerlerine yükseltir.

Parametre	Varsayılan	Aralığı
SameSubnetDelay	1000 milisaniye	250-2000 milisaniye
CrossSubnetDelay	1000 milisaniye	250-4000 milisaniye
SameSubnetThreshold	5	3-10
CrossSubnetThreshold	5	3-10

Bu değerlerin üst sınırına yükseltilmesi olayın ve düğümün kaldırılmasının ortadan kaldırılmasına neden olabilir, yalnızca sorunu maskeler. Hiçbir şeyi düzeltmez. Yapılacak en iyi şey, sinyal hatalarının kök nedenini bulmak ve düzelttirmektir. Bu değerleri artırmak için tek gerçek ihtiyaç, düğümlerin farklı konumlarda bulunduğu ve ağ gecikme süresinin aşılabildiği çok siteli bir senaryodur.