Aracılığıyla paylaş

HADR yapılandırması en iyi yöntemleri (Azure VM’leri üzerinde SQL Server)

Şunlar için geçerlidir:Azure VM'de SQL Server

Windows Server Yük Devretme Kümesi, Azure Sanal Makineler(VM) üzerinde SQL Server ile yüksek kullanılabilirlik ve olağanüstü durum kurtarma (HADR) için kullanılır.

Bu makalede, Azure VM'lerinde SQL Server ile kullandığınızda hem yük devretme kümesi örnekleri (FCI) hem de kullanılabilirlik grupları için küme yapılandırması en iyi uygulamaları sunulmaktadır.

Daha fazla bilgi edinmek için bu serideki diğer makalelere bakın: Denetim listesi, VM boyutu, Depolama, Güvenlik, HADR yapılandırması, Temel toplama.

Denetim listesi

Makalenin geri kalanında daha ayrıntılı olarak ele alınan HADR en iyi yöntemlerine kısa bir genel bakış için aşağıdaki denetim listesini gözden geçirin.

Always On kullanılabilirlik grubu ve yük devretme kümesi örneği gibi yüksek kullanılabilirlik ve olağanüstü durum kurtarma (HADR) özellikleri, temel alınan Windows Server Yük Devretme Kümesi teknolojisini temel alır. HadR ayarlarınızı değiştirerek bulut ortamını daha iyi desteklemek için en iyi yöntemleri gözden geçirin.

Windows kümeniz için şu en iyi yöntemleri göz önünde bulundurun:

  • Azure Load Balancer'a veya dağıtılmış ağ adına (DNN) bağımlılığından kaçınmak için SQL Server VM'lerinizi mümkün olduğunda birden çok alt ağa dağıtarak trafiği HADR çözümünüzle yönlendirin.
  • Geçici ağ hatalarından veya Azure platformu bakımlarından kaynaklanan beklenmeyen kesintileri önlemek için kümeyi daha az agresif parametrelerle değiştirin. Daha fazla bilgi için bkz kalp atışı ve eşik ayarları. Windows Server 2012 ve üzeri için aşağıdaki önerilen değerleri kullanın:
    • SameSubnetDelay: 1 saniye
    • SameSubnetThreshold: 40 nabız
    • CrossSubnetDelay: 1 saniye
    • CrossSubnetThreshold: 40 heartbeat sinyalleri
  • VM'lerinizi bir kullanılabilirlik kümesine veya farklı kullanılabilirlik alanlarına yerleştirin. Daha fazla bilgi edinmek için bkz . VM kullanılabilirlik ayarları.
  • Küme düğümü başına tek bir NIC kullanın.
  • Küme çoğunluk oylamasını en az 3 tek sayıdaki oyları kullanacak şekilde yapılandırın. DR bölgelerine oy atamayın.
  • Kaynak kısıtlamaları nedeniyle beklenmeyen yeniden başlatmaları veya yük devretmeleri önlemek için kaynak sınırlarını dikkatle izleyin.
    • İşletim sistemi, sürücüler ve SQL Server'ın en son derlemelerde olduğundan emin olun.
    • Azure VM'lerinde SQL Server performansını iyileştirin. Daha fazla bilgi edinmek için bu makaledeki diğer bölümleri gözden geçirin.
    • Kaynak sınırlarını önlemek için iş yükünü azaltın veya dağıtin.
    • Kısıtlamaları önlemek için daha yüksek sınırları olan bir VM'ye veya diske gidin.

SQL Server kullanılabilirlik grubunuz veya yük devretme kümesi örneğiniz için şu en iyi yöntemleri göz önünde bulundurun:

  • Sık sık beklenmeyen hatalarla karşılaşıyorsanız, bu makalenin geri kalanında açıklanan en iyi performans yöntemlerini izleyin.
  • SQL Server VM performansını iyileştirmek beklenmeyen yük devretme işlemlerinizi çözmezse, kullanılabilirlik grubu veya yük devretme kümesi örneği için izlemeyi gevşetmeyi göz önünde bulundurun. Ancak, bunu yapmak sorunun temel kaynağını ele almayabilir ve hata olasılığını azaltarak belirtileri maskeler. Yine de temel alınan kök nedeni araştırmanız ve ele almanız gerekebilir. Windows Server 2012 veya üzeri için aşağıdaki önerilen değerleri kullanın:
    • Kira zaman aşımı: En yüksek kira zaman aşımı değerini hesaplamak için şu denklemi kullanın:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      40 saniyeyle başlayın. Daha önce önerilen gevşek SameSubnetThreshold ve SameSubnetDelay değerleri kullanıyorsanız kiralama zaman aşımı değeri için 80 saniyeyi aşmayın.
    • Belirtilen dönemdeki en fazla hata sayısı: Bu değeri 6 olarak ayarlayın.
  • HADR çözümünüzle bağlantı kurmak için sanal ağ adı (VNN) ve Azure Load Balancer kullanırken, kümeniz yalnızca bir alt ağa yayılmış olsa bile, bağlantı dizesinde MultiSubnetFailover = true belirtin.
    • İstemci desteklemiyorsa MultiSubnetFailover = True , istemci kimlik bilgilerini daha kısa süreler için ayarlamanız RegisterAllProvidersIP = 0 ve HostRecordTTL = 300 önbelleğe almanız gerekebilir. Ancak, bunu yapmak DNS sunucusunda ek sorgulara neden olabilir.
  • Dağıtılmış ağ adını (DNN) kullanarak HADR çözümünüze bağlanmak için aşağıdakileri göz önünde bulundurun:
    • MultiSubnetFailover = True destekleyen bir istemci sürücüsü kullanmanız ve bu parametrenin bağlantı dizesinde bulunması gerekir.
    • DNN dinleyicisine bağlanırken, kullanılabilirlik grubu için bağlantı dizesinde benzersiz bir DNN bağlantı noktası kullanın.
  • Yük dengeleyici veya DNN gereksinimini atlamak için temel kullanılabilirlik grubu için veritabanı yansıtma bağlantı dizesi kullanın.
  • Yanlış hizalanmış G/Ç'lerden kaçınmak için yüksek kullanılabilirlik çözümünüzü dağıtmadan önce VHD'lerinizin kesim boyutunu doğrulayın. Daha fazla bilgi edinmek için bkz . KB3009974 .
  • SQL Server veritabanı altyapısı, Always On kullanılabilirlik grubu dinleyicisi veya yük devretme kümesi örneği sistem durumu araştırması 49.152 ile 65.536 ( TCP/IP için varsayılan dinamik bağlantı noktası aralığı) arasında bir bağlantı noktası kullanacak şekilde yapılandırılmışsa, her bağlantı noktası için bir dışlama ekleyin. Bunu yapmak, diğer sistemlerin dinamik olarak aynı bağlantı noktasına atanmasını engeller. Aşağıdaki örnek, 59999 numaralı bağlantı noktası için bir dışlama oluşturur:
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

HADR denetim listesini diğer en iyi yöntemlerle karşılaştırmak için bkz. Kapsamlı Performans en iyi yöntemleri denetim listesi.

VM kullanılabilirlik ayarları

Kapalı kalma süresinin etkisini azaltmak için aşağıdaki VM en iyi kullanılabilirlik ayarlarını göz önünde bulundurun:

  • Yakınlık yerleştirme gruplarını en düşük gecikme süresi için hızlandırılmış ağ ile birlikte kullanın (isteğe bağlı, üretim için önerilir).
  • Veri merkezi düzeyindeki hatalardan korumak için sanal makine kümesi düğümlerini ayrı kullanılabilirlik alanlarına veya aynı veri merkezi içinde daha düşük gecikme süreli yedeklilik için tek bir kullanılabilirlik kümesine yerleştirin (üretim SLA'sı için gereklidir).
  • Kullanılabilirlik kümesindeki VM'ler için premium yönetilen işletim sistemi ve veri diskleri kullanın (üretim için önerilir).
  • Her uygulama katmanını ayrı kullanılabilirlik kümelerine yapılandırın (uygulama düzeyinde yedeklilik için gereklidir).

Yetersayı

İki düğümlü bir küme quorum kaynağı olmadan çalışabilir, ancak müşterilerin üretim Microsoft desteğine sahip olabilmesi için kesinlikle bir quorum kaynağı kullanması gereklidir. Küme doğrulama, kuorum kaynağı olmayan herhangi bir kümeyi geçirmez.

Teknik olarak, üç düğümlü bir küme çekirdek kaynağı olmadan tek düğüm kaybından (iki düğüme kadar) kurtulabilir, ancak küme iki düğüme düştükten sonra başka bir düğüm kaybı veya iletişim hatası olursa kümelenmiş kaynakların bölünmüş beyin senaryolarını önlemek için çevrimdışı duruma geçme riski vardır. Quorum kaynağının yapılandırılması, kümenin yalnızca bir düğümle çevrimiçi olarak devam etmesini sağlar.

Disk tanığı, en dayanıklı çoğunluk seçeneğidir, ancak Azure VM üzerinde bir SQL Server'da disk tanığı kullanmak için, yüksek kullanılabilirlik çözümünü bazı sınırlamalarla kısıtlayan bir Azure Paylaşılan Disk kullanmanız gerekir. Bu nedenle, yük devretme kümesi örneğinizi Azure Paylaşılan Diskler ile yapılandırırken bir disk tanığı kullanın, aksi takdirde mümkün olduğunda bir bulut tanığı kullanın.

Aşağıdaki tabloda, Azure VM'lerinde SQL Server için kullanılabilir çoğunluk seçenekleri listelenmiştir.

Bulut tanığı Disk tanığı Dosya paylaşım tanığı
Desteklenen işletim sistemi Windows Server 2016+ Tümü Tümü
  • Bulut tanığı (Windows Server 2016+, küme yöneticisi gerekli) birden çok site, birden çok alan ve birden çok bölgeye sahip dağıtımlar için idealdir. Paylaşılan depolama kümesi çözümü kullanmıyorsanız mümkün olduğunca bulut tanığı kullanın.
  • Disk tanığı (tüm Windows Server sürümleri, küme yöneticisi gereklidir) en dayanıklı çekirdek seçeneğidir ve Azure Paylaşılan Diskleri (veya paylaşılan SCSI, iSCSI veya fiber kanal SAN gibi paylaşılan disk çözümleri) kullanan tüm kümeler için tercih edilir. Kümelenmiş Paylaşılan Birim disk tanığı olarak kullanılamaz.
  • Dosya paylaşımı tanığı (tüm Windows Server sürümleri, küme yöneticisi gerekli), disk tanığı ve bulut tanığının seçenekler arasında olmadığı durumlar için uygundur.

Başlamak için bkz Küme çoğunluğunu yapılandırma.

Çoğunluk Oylaması

Windows Server Yük Devretme Kümesi'ne katılan bir düğümün çoğunluk oyu değiştirmek mümkündür (küme yöneticisi gerekli, gelişmiş yapılandırmalar için opsiyonel).

Düğüm oy ayarlarını değiştirirken şu yönergeleri izleyin:

Toplantı yeter sayısı oylama yönergeleri
Her düğümün varsayılan olarak oy vermemeye başlaması gerekir. Her düğümün yalnızca açık gerekçeli bir oyu olmalıdır.
Kullanılabilirlik grubunun birincil çoğaltmasını barındıran veya bir yük devretme kümesi örneğinin tercih edilen sahiplerini barındıran küme düğümleri için oyları etkinleştirin.
Otomatik yük devretme sahiplerinin oylarını etkinleştirin. Otomatik yük devretme sonucunda bir birincil çoğaltma veya FCI'yi barındırabilecek her düğümün oy hakkına sahip olması gerekir.
Bir kullanılabilirlik grubunda birden fazla ikincil çoğaltma varsa, yalnızca otomatik yük devretme yeteneğine sahip olan çoğaltmalar için oyları etkinleştirin.
İkincil olağanüstü durum kurtarma sitelerindeki sunucu düğümleri için oy kullanımı devre dışı bırakılsın. İkincil sitelerdeki düğümler, birincil siteyle ilgili bir sorun yoksa kümeyi çevrimdışına alma kararına katkıda bulunmamalıdır.
Tek sayıda oya sahip olmak, en az üç çoğunluk oyu olması gerekir. İki düğümlü bir kümede gerekirse ek bir oy için bir quorum tanığı ekleyin.
Yük devretme sonrasında oy atamalarını yeniden değerlendirin. Destekleyici yeterli bir çoğunluğu olmayan bir küme yapılandırmasına geçiş yapmak istemezsiniz.

Yük Devretme Kümesi Yöneticisi'ni veya PowerShell'i kullanarak quorum oylamasını ayarlayabilirsiniz.

Import-Module FailoverClusters  
  
$node = "AlwaysOnSrv1"  
(Get-ClusterNode $node).NodeWeight = 0  
  
$cluster = (Get-ClusterNode $node).Cluster  
$nodes = Get-ClusterNode -Cluster $cluster  
  
$nodes | Format-Table -property NodeName, State, NodeWeight

cluster.exe yükseltilmiş komut isteminde de kullanabilirsiniz:

cluster.exe Cluster001 node AlwaysOnSrv1 /prop NodeWeight=0

Bağlantı

Kullanılabilirlik grubu dinleyicinize veya yük devretme kümesi örneğine bağlanmaya yönelik şirket içi deneyimi eşleştirmek için SQL Server VM'lerinizi aynı sanal ağ içindeki birden çok alt ağa dağıtın. Birden çok alt ağın olması, trafiğinizi dinleyicinize yönlendirmek için bir Azure Load Balancer'a veya dağıtılmış ağ adına (DNN) ek bağımlılık gereksinimini azaltır.

HADR çözümünüzü basitleştirmek için SQL Server VM'lerinizi mümkün olduğunca birden çok alt ağa dağıtın. Daha fazla bilgi edinmek için Çok alt ağlı AG ve Çok alt ağlı FCI bölümlerine bakın.

SQL Server VM'leriniz tek bir alt ağdaysa, hem yük devretme kümesi örnekleri hem de kullanılabilirlik grubu dinleyicileri için sanal ağ adı (VNN) ve Azure Load Balancer ya da dağıtılmış ağ adı (DNN) yapılandırabilirsiniz.

Dağıtılmış ağ adı (DNN), kullanılabilir olduğunda önerilen bağlantı seçeneğidir:

  • Yük dengeleyici kaynağını korumak zorunda kalmadığınızdan uçtan uca çözüm daha sağlamdır.
  • Yük dengeleyici yoklamalarının ortadan kaldırılması yük devretme süresini azaltır.
  • DNN, Azure VM'lerinde SQL Server ile yük devretme kümesi örneğinin veya kullanılabilirlik grubu dinleyicisinin sağlanmasını ve yönetimini basitleştirir.

Aşağıdaki sınırlamaları göz önünde bulundurun:

  • İstemci sürücüsünün parametresini desteklemesi MultiSubnetFailover=true gerekir.
  • DNN özelliği, Windows Server 2016 ve sonraki sürümlerde SQL Server 2016 SP3, SQL Server 2017 CU25 ve SQL Server 2019 CU8 ile başlayarak kullanılabilir.

Daha fazla bilgi edinmek için bkz. Windows Server Yük Devretme Kümesine genel bakış.

Bağlantıyı yapılandırmak için aşağıdaki makalelere bakın:

SQL Server özelliklerinin çoğu, DNN kullanılırken FCI ve kullanılabilirlik gruplarıyla saydam bir şekilde çalışır, ancak özellikle dikkat edilmesi gereken bazı özellikler vardır. Daha fazla bilgi edinmek için bkz . FCI ve DNN birlikte çalışabilirliği ve AG ve DNN birlikte çalışabilirliği .

İpucu

Bağlantı dizisini güncellemek zorunda kalmadan gelecekteki alt ağların yayılımını desteklemek amacıyla, tek bir alt ağda bulunan HADR çözümleri için bile bağlantı dizesinde MultiSubnetFailover=true parametresini ayarlayın.

Nabız ve eşik

Küme kalp atışı ve eşik ayarlarını gevşetilmiş ayarlar olarak değiştirin. Varsayılan sinyal ve eşik kümesi ayarları, yüksek oranda ayarlanmış şirket içi ağlar için tasarlanmıştır ve bulut ortamında gecikme süresini artırma olasılığını göz önünde bulundurmaz. Sinyal ağı, geleneksel olarak TCP'ye göre çok daha az güvenilir ve tamamlanmamış konuşmalara daha yatkın olan UDP 3343 ile sürdürülür.

Bu nedenle, Azure VM yüksek kullanılabilirlik çözümlerinde SQL Server için küme düğümlerini çalıştırırken, ağ gecikmesi veya hatası, Azure bakımı veya kaynak performans sorunlarına neden olma olasılığının artması nedeniyle geçici hataları önlemek için küme ayarlarını daha rahat bir izleme durumuna değiştirin.

Gecikme ve eşik ayarlarının genel durum tespiti üzerinde birikimli etkisi vardır. Örneğin, CrossSubnetDelay'ı her 2 saniyede bir sinyal gönderecek şekilde ayarlamak ve kurtarma eylemi gerçekleştirilmeden önce CrossSubnetThreshold değerini 10 yanıtsız sinyal olarak ayarlamak, kümenin toplam ağ toleransının, kurtarma eylemi yapılmadan önce 20 saniye olabileceği anlamına gelir. Genel olarak, sık sinyal göndermeye devam etmek, ancak daha yüksek eşikleri korumak tercih edilir.

Geçici sorunlara daha fazla tolerans sağlarken yasal kesintiler sırasında kurtarmayı sağlamak için, gecikme ve eşik ayarlarınızı aşağıdaki tabloda ayrıntılı olarak belirtilen değerlerle gevşetin:

Ayar Windows Server 2012 veya üzeri Windows Server 2008 R2
Aynı Altnet Gecikmesi 1 saniye 2 saniye
AynıAltAğEşiği 40 kalp atışı 10 kalp atışı (maksimum)
Alt Ağlar Arası Gecikme 1 saniye 2 saniye
Alt Ağlar Arası Eşik 40 kalp atışı 20 kalp atışı (maksimum)

Küme parametrelerinizi değiştirmek için PowerShell'i kullanın:

(get-cluster).SameSubnetThreshold = 40
(get-cluster).CrossSubnetThreshold = 40

Beklenen çıkış: Komutlar hata iletisi olmadan başarıyla tamamlanır.

Değişikliklerinizi doğrulayın:

get-cluster | fl *subnet*

Beklenen çıkış:

CrossSubnetThreshold  : 40
SameSubnetThreshold   : 40

Aşağıdakileri göz önünde bulundurun:

  • Bu değişiklik anında gerçekleşir, kümeyi yeniden başlatmak veya herhangi bir kaynak gerekmez.
  • Aynı alt ağ değerleri çapraz alt ağ değerlerinden büyük olmamalıdır.
  • SameSubnetEşiği <= CrossSubnetEşiği
  • SameSubnetDelay < eşittir CrossSubnetDelay

Uygulamanıza, iş ihtiyaçlarınıza ve çevrenize bağlı olarak, iş kesintisinin ne kadar tolere edilebileceğini ve bir düzeltici eylemin ne kadar süre içinde gerçekleştirilmesi gerektiğini göz önünde bulundurarak, rahat değerler seçin. Varsayılan Windows Server 2019 değerlerini aşamazsanız, mümkünse en azından bunları eşleştirmeyi deneyin:

Referans olması için, aşağıdaki tabloda varsayılan değerler ayrıntılı olarak verilmektedir.

Ayar Windows Server 2019 Windows Server 2016 Windows Server 2008 - 2012 R2
Aynı Altnet Gecikmesi 1 saniye 1 saniye 1 saniye
AynıAltAğEşiği 20 kalp atışı 10 kalp atışı 5 kalp atışı
Alt Ağlar Arası Gecikme 1 saniye 1 saniye 1 saniye
Alt Ağlar Arası Eşik 20 kalp atışı 10 kalp atışı 5 kalp atışı

Daha fazla bilgi için Yük Devretme Kümesi Ağ Eşiklerini Ayarlama bölümüne bakınız.

Gevşek izleme

Küme sinyal ve eşik ayarlarınızı önerilen ayarlara göre ayarlamak yeterli tolerans değilse ve gerçek kesintiler yerine geçici sorunlar nedeniyle otomatik geçişler görmeye devam ediyorsanız, AG veya FCI izlemenizi daha esnek olacak şekilde yapılandırabilirsiniz. Bazı senaryolarda, etkinlik düzeyi göz önüne alındığında izlemeyi geçici olarak rahatlatmak yararlı olabilir. Örneğin, veritabanı yedeklemeleri, dizin bakımı, DBCC CHECKDB gibi GÇ yoğunluklu iş yükleri yaparken izlemeyi rahatlatmak isteyebilirsiniz. Etkinlik tamamlandıktan sonra izlemenizi daha az rahat değerlere ayarlayın.

Uyarı

Bu ayarların değiştirilmesi temel bir sorunu maskeler ve hata olasılığını ortadan kaldırmak yerine azaltmak için geçici bir çözüm olarak kullanılmalıdır. Temel sorunlar hala araştırılmalı ve giderilmelidir.

İlk olarak, aşağıdaki parametreleri gevşek izleme için varsayılan değerlerinden artırıp gerektiği gibi ayarlayın:

Parametre Varsayılan değer Gevşek Değer Açıklama
Sağlık denetimi zaman aşımı 30000 milisaniye (30 saniye) 60000 milisaniye (60 saniye) Birincil replikanın veya düğümün sağlık durumunu belirler. Küme kaynak DLL'i sp_server_diagnostics, sağlık kontrolü zaman aşımı eşiğinin 1/3'üne eşit bir aralıkta sonuçları döndürür. Kaynak DLL, sp_server_diagnostics yavaş çalışıyorsa veya bilgi döndürmüyorsa, kaynağın yanıt vermediğini belirlemeden ve yapılandırılmışsa otomatik yük devretmeyi başlatmadan önce sistem durumu denetimi zaman aşımı eşiğinin tam süresince bekler.
Hata Koşulu Düzeyi 3 2 Otomatik yük devretmeyi tetikleyen koşullar. En az kısıtlayıcı (birinci düzey) ile en kısıtlayıcı (beşinci düzey) arasında değişen beş hata koşulu düzeyi vardır

Hem AG'ler hem de FC'ler için sistem durumu denetimi ve hata koşullarını değiştirmek için Transact-SQL (T-SQL, sysadmin veya ALTER AVAILABILITY GROUP izni gerekir) kullanın.

Kullanılabilirlik grupları için:

ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT = 60000);  -- 60000 milliseconds (60 seconds)
ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 2);

Beklenen çıkış: Komutlar başarıyla tamamlandı.

Küme yük devretme örnekleri için (sysadmin veya ALTER SETTINGS iznine sahip olmanız gerekir):

ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY HealthCheckTimeout = 60000;  -- 60000 milliseconds (60 seconds)
ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY FailureConditionLevel = 2;

Beklenen çıkış: Komutlar başarıyla tamamlandı.

Kullanılabilirlik gruplarına özgü olarak, aşağıdaki önerilen parametrelerle başlayın ve gerektiği gibi ayarlayın:

Parametre Varsayılan değer Gevşek Değer Açıklama
Kiralama zaman aşımı 20000 milisaniye (20 saniye) 40000 milisaniye (40 saniye) Bölünmüş beyinleri önler.
Oturum zaman aşımı 10000 milisaniye (10 saniye) 20000 milisaniye (20 saniye) Çoğaltmalar arasındaki iletişim sorunlarını denetler. Oturum zaman aşımı süresi, bir kullanılabilirlik çoğaltmasının, bağlantının başarısız olduğunu düşünmeden önce, bağlı bir çoğaltmadan ping yanıtı beklediği sürenin saniye cinsinden uzunluğunu kontrol eden bir çoğaltma özelliğidir. Varsayılan olarak, bir çoğaltma ping yanıtı için 10 saniye bekler. Bu çoğaltma özelliği yalnızca belirli bir ikincil çoğaltma ile kullanılabilirlik grubunun birincil çoğaltması arasındaki bağlantı için geçerlidir.
Belirtilen dönemdeki en fazla hata sayısı 2 6 Kümelenmiş bir kaynağın birden çok düğüm hatası içinde süresiz hareketini önlemek için kullanılır. Bir değerin çok düşük olması, kullanılabilirlik grubunun başarısız durumda olmasına neden olabilir. Performans sorunlarından kaynaklanan kısa kesintileri önlemek için değeri artırın çünkü çok düşük bir değer AG'nin başarısız durumda olmasına yol açabilir.

Herhangi bir değişiklik yapmadan önce aşağıdakileri göz önünde bulundurun:

  • Hiçbir zaman aşımı değerini varsayılan değerlerinin altına düşürmeyin.
  • En fazla kira zaman aşımı değerini hesaplamak için şu denklemi kullanın: Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
    40 saniye (40000 milisaniye) ile başlayın. Daha önce önerilen gevşek SameSubnetThreshold ve SameSubnetDelay değerleri kullanıyorsanız kiralama zaman aşımı değeri için 80 saniyeyi (80000 milisaniye) aşmayın.
  • Eşzamanlı çoğaltmalar için, oturum zaman aşımı süresinin yüksek bir değerle değiştirilmesi veya artırılması HADR_sync_commit beklemelerini artırabilir.

Kiralama zaman aşımı

Yük Devretme Kümesi Yöneticisi'ni (küme yöneticisi gereklidir, ayarlama için isteğe bağlı) kullanarak, kullanılabilirlik grubunuzun kira zaman aşımı süresi ayarlarını değiştirin. Ayrıntılı adımlar için SQL Server kullanılabilirlik grubu kira durumu denetimi belgelerine bakın.

Oturum zaman aşımı

Kullanılabilirlik grubu için oturum zaman aşımını değiştirmek için Transact-SQL (T-SQL, sysadmin veya ALTER AVAILABILITY GROUP izni gerekli, ayarlama için isteğe bağlı) kullanın:

ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON 'INSTANCE01' WITH (SESSION_TIMEOUT = 20);  -- 20 seconds

Beklenen çıkış: Komut başarıyla tamamlıyor.

Belirtilen dönemdeki en fazla hata sayısı

Belirtilen dönem için en fazla hata değerini değiştirmek için Yük Devretme Kümesi Yöneticisi'ni (küme yöneticisi gereklidir, ayarlama isteğe bağlıdır) kullanın.

  1. Gezinti bölmesinde Roller'i seçin.
  2. Roller'in altında kümelenmiş kaynağa sağ tıklayın ve Özellikler'i seçin.
  3. Yük Devretme sekmesini seçin ve Belirtilen Dönemdeki Maksimum Hata Sayısı değerini istediğiniz şekilde artırın.

Kaynak sınırları

VM veya disk sınırları, kümenin durumunu etkileyen ve sistem durumu denetimini engelleyen bir kaynak performans sorununa neden olabilir.

Kaynak performans sorunlarını tanımlama

  • Yük devretmeye neden olabilecek disk performansı sorunlarını belirlemek için Azure portalında G/Ç Analizi'ni kullanın.
  • VM veya disk düzeyi gecikme süresini anlamak için Depolama GÇ Kullanımı ölçümlerini izleyin.
  • İşletim sistemi, sürücüler ve SQL Server'ın en son derlemelerde olduğundan emin olun.

SQL Server ortamını iyileştirme

  • Azure Sanal Makinelerinde SQL Server performans yönergelerinde açıklandığı gibi Azure VM ortamında SQL Server'ınızı iyileştirin.
  • Kaynak sınırlarını aşmadan kullanımı azaltmak için iş yükünü azaltın veya dağıtın.

SQL Server iş yükünü ayarlama

SQL Server iş yükü performansını geliştirme fırsatı olduğunda:

  • Sorgu verimliliğini artırmak için dizinleri ekleyin veya iyileştirin.
  • Tam tarama ile gerekirse ve mümkünse istatistikleri güncelleştirin.
  • Yedeklemeler veya dizin bakımı gibi belirli iş yükleri sırasında kaynak kullanımını sınırlamak için resource governor (yalnızca SQL Server 2014'ten başlayarak) gibi özellikleri kullanın.

VM veya disk kaynaklarını ölçeklendirme

İş yükünüzün taleplerini karşılamak veya aşmak için daha yüksek sınırları olan bir VM'ye veya diske geçin.

Ağ

Azure Load Balancer'a veya dağıtılmış ağ adına (DNN) bağımlılığı önlemek için SQL Server VM'lerinizi birden çok alt ağa dağıtma yönergeleri için Bağlantı bölümüne bakın.

Sunucu başına tek bir NIC kullanın (küme düğümü). Azure ağı, bir Azure sanal makinesi konuk kümesinde ek NIC'leri gereksiz hale getiren fiziksel yedekliliğe sahiptir. Küme doğrulama raporu, düğümlere yalnızca tek bir ağ üzerinden ulaşabileceğiniz konusunda sizi uyarır. Azure sanal makinesi konuk yük devretme kümelerinde bu uyarıyı yoksayabilirsiniz.

Belirli bir VM'nin bant genişliği sınırları NIC'ler arasında paylaşılır ve ek bir NIC eklemek, Azure VM'lerinde SQL Server için kullanılabilirlik grubu performansını iyileştirmez. Bu nedenle, ikinci bir NIC eklemeniz gerekmez.

Azure'daki RFC uyumlu olmayan DHCP hizmeti, belirli yük devretme kümesi yapılandırmalarının oluşturulamamasına neden olabilir. Küme ağ adına küme düğümlerinden biriyle aynı IP adresi gibi yinelenen bir IP adresi atandığı için bu hata ortaya çıkar. Bu, Windows yük devretme kümesi özelliğine bağlı olan kullanılabilirlik gruplarını kullandığınızda oluşan bir sorundur.

İki düğümlü bir kümenin oluşturulup çevrimiçine getirildiği senaryoyu düşünün:

  1. Küme çevrimiçi olur ve ardından NODE1, küme ağ adı için dinamik olarak atanmış bir IP adresi istemektedir.
  2. DHCP hizmeti isteğin NODE1'den geldiğini tanıdığından, DHCP hizmeti NODE1'in kendi IP adresi dışında bir IP adresi vermez.
  3. Windows, yinelenen bir adresin hem NODE1'e hem de yük devretme kümesinin ağ adına atandığını algılar ve varsayılan küme grubu faal hale gelmez.
  4. Varsayılan küme grubu NODE2'ye geçer. NODE2, NODE1'in IP adresini küme IP adresi olarak ele alır ve varsayılan küme grubunu çevrimiçine getirir.
  5. NODE2, NODE1 ile bağlantı kurmaya çalıştığında NODE1'e yönlendirilen paketler NODE1'in IP adresini kendi kendine çözümlediğinden NODE2'den asla ayrılmaz. NODE2, NODE1 ile bağlantı kuramaz, ardından yeter sayıyı kaybeder ve kümeyi kapatır.
  6. NODE1, NODE2'ye paket gönderebilir, ancak NODE2 yanıtlayamaz. NODE1 çoğunluğunu kaybeder ve kümeyi kapatır.

Küme ağ adını çevrimiçi hale getirmek ve IP adresini Azure Load Balancer'a eklemek için küme ağ adına kullanılmayan bir statik IP adresi atayarak bu senaryodan kaçınabilirsiniz.

Prob bağlantı noktasını yapılandırın

Sanal ağ adı (VNN) kaynağını desteklemek için Azure Load Balancer kullanırken (yalnızca tek alt ağ dağıtımları, küme yöneticisi gereklidir), Kümeyi Always On kullanılabilirlik grubu dinleyiciniz veya yük devretme kümesi örneğinin sistem durumu yoklama isteklerini yanıtlamak üzere yapılandırmanız gerekir. Sistem durumu yoklaması bir arka uç örneğinden yanıt alamazsa, sistem durumu yoklaması yeniden başarılı olana kadar bu arka uç örneğine yeni bir bağlantı gönderilmez.

Bağlantı noktası dışlamayı yapılandırın

Azure Load Balancer (tek alt ağ dağıtımları, Windows Server 2012+, küme yöneticisi gereklidir) ile bir sanal ağ adı (VNN) kaynağı kullanıyorsanız, 49.152 ile 65.536 ( TCP/IP için varsayılan dinamik bağlantı noktası aralığı) arasında bir sistem durumu yoklaması bağlantı noktası kullanırken Always On kullanılabilirlik grubu dinleyiciniz veya yük devretme kümesi örneğiniz için bağlantı noktası dışlaması yapılandırmanız gerekir.

Port dışlaması yapılandırması, Olay Kimliği: 1069 ve Durum 10048 gibi olayları önler; bunun nedeni, yoklama bağlantı noktası olarak tanımlanan bağlantı noktasını alan bir iç işlem olabilir.

Aşağıdaki örnekte, küme günlüklerinde durum 10048 olan Olay Kimliği 1069 gösterilmektedir:

Cluster resource '<IP name in AG role>' of type 'IP Address' in cluster role '<AG Name>' failed.
An Event ID: 1069 with status 10048 can be identified from cluster logs with events like:
Resource IP Address 10.0.1.0 called SetResourceStatusEx: checkpoint 5. Old state OnlinePending, new state OnlinePending, AppSpErrorCode 0, Flags 0, nores=false
IP Address <IP Address 10.0.1.0>: IpaOnlineThread: **Listening on probe port 59999** failed with status **10048**

Durum 10048 , bir uygulama bir yuvayı zaten var olan bir yuva için kullanılmış bir IP adresine/bağlantı noktasına bağlamaya çalışırsa gerçekleşir.

Bilinen sorunlar

Yaygın olarak bilinen bazı sorunlar ve hatalar için çözümleri gözden geçirin.

Kaynak çekişmesi yük devretmeye neden oluyor

VM için G/Ç veya CPU kapasitesinin tükenmesi, kullanılabilirlik grubunuzun geçiş yapmasına neden olabilir. Yük devretmeden hemen önce gerçekleşen çekişmelerin tanımlanması, otomatik yük devretmeye neyin neden olduğunu belirlemenin en güvenilir yoludur.

G/Ç darboğazlarını belirleme

Yük devretmeye neden olabilecek disk performansı sorunlarını belirlemek için Azure portalında G/Ç Analizi'ni kullanın.

VM depolama ölçümlerini izleme

Azure Sanal Makineleri İzleyin ve Depolama GÇ Kullanımı ölçümlerine bakın ki VM veya disk düzeyinde gecikme süresini anlayın.

Azure VM Genel IO Tükenmesi olayını (Azure Katkıda Bulunan veya Okuyucu rolü gereklidir) gözden geçirmek için şu adımları izleyin:

  1. Azure portalında Sanal Makinelerinize gidin - SQL sanal makinelerine değil.

  2. Ölçümler sayfasını açmak için İzleme'nin altında Ölçümler'iseçin.

  3. İlgilendiğiniz zaman aralığını ve vm'de yerel saat dilimini veya UTC/GMT saat dilimini belirtmek için Yerel saat'i seçin.

    Azure portalında grafın zaman dilimini değiştirmeyi seçen Ölçümler sayfasının ekran görüntüsü.

  4. Grafiği görmek üzere aşağıdaki iki ölçümü eklemek için Ölçüm ekle'yi seçin:

    • VM Önbellekli Bant Genişliği Kullanım Yüzdesi
    • VM Önbelleğe Alınmamış Bant Genişliği Tüketim Yüzdesi

Azure portalındaki Ölçümler sayfasının ekran görüntüsü.

Azure VM HostEvents, yük devretmeye neden oluyor.

Azure VM HostEvent, kullanılabilirlik grubunuzun yük devretmesine neden olabilir.

Azure Monitor Etkinlik günlüğünü kontrol et

Azure İzleyici etkinlik günlüğü, bir kaynağın ne zaman değiştirildiği veya sanal makinenin başlatılmış olduğu da dahil olmak üzere abonelik düzeyi olaylar hakkında içgörü sağlar. Etkinlik günlüğünü Azure portalında görüntüleyebilir veya PowerShell ve Azure CLI ile girdileri alabilirsiniz.

Azure İzleyici etkinlik günlüğünü (Azure Okuyucu rolü gerekli) denetlemek için şu adımları izleyin:

  1. Azure portalında Sanal Makinenize gidin

  2. Sanal Makine bölmesinde Etkinlik Günlüğü'nü seçin

  3. Timespan'i seçin ve ardından kullanılabilirlik grubunuzun devre dışı kaldığı zaman dilimini seçin. Uygula’yı seçin.

    Etkinlik günlüğünü gösteren Azure portalının ekran görüntüsü.

Kaynak Sağlığını Kontrol Et

Azure'da platform tarafından başlatılan bir kullanılamama durumunun kök nedeni hakkında daha fazla bilgi varsa, bu bilgiler ilk kullanılamama durumundan 72 saat sonrasına kadar Azure VM - Kaynak Durumu genel bakış sayfasına gönderilebilir. Bu bilgiler şu anda yalnızca sanal makineler için kullanılabilir.

Kaynak Sağlığını kontrol etmek için şu adımları izleyin:

  1. Azure portalında Sanal Makinenize gidin
  2. Sağlık bölmesinin altındaki Kaynak Durumu'nu seçin.

Azure portalındaki Kaynak Durumu sayfasının ekran görüntüsü.

Bu sayfadan sağlık olaylarını temel alan uyarılar da yapılandırabilirsiniz.

Küme düğümü üyelikten kaldırıldı

Windows Kümesi sinyal ve eşik ayarları ortamınız için çok agresifse, küme üyeliği sorunlarıyla karşılaşabilirsiniz.

Belirti -leri

Sistem olay günlüğünde sık sık aşağıdaki iletiyi görebilirsiniz:

Error 1135
Cluster node 'Node1' was removed from the active failover cluster membership.
The Cluster service on this node may have stopped. This could also be due to the node having
lost communication with other active nodes in the failover cluster. Run the Validate a
Configuration Wizard to check your network configuration. If the condition persists, check
for hardware or software errors related to the network adapters on this node. Also check for
failures in any other network components to which the node is connected such as hubs, switches, or bridges.

Daha fazla bilgi için Olay Kimliği 1135 ile ilgili küme sorununu giderme konusunu gözden geçirin.

Kiralama süre sonu hataları

İzleme ortamınız için çok agresifse sık sık kullanılabilirlik grubu veya FCI yeniden başlatmaları, hatalar veya yük devretmeler görebilirsiniz.

Belirti -leri

Kullanılabilirlik grupları için SQL Server hata günlüğünde aşağıdaki iletileri görebilirsiniz:

Error 19407: The lease between availability group 'PRODAG' and the Windows Server Failover Cluster has expired.
A connectivity issue occurred between the instance of SQL Server and the Windows Server Failover Cluster.
To determine whether the availability group is failing over correctly, check the corresponding availability group
resource in the Windows Server Failover Cluster

Error 19419: The renewal of the lease between availability group '%.*ls' and the Windows Server Failover Cluster
failed because the existing lease is no longer valid.

Çözüm

İzleme ayarlarınızı Gevşek izleme bölümünde açıklandığı gibi ayarlayın.

Bağlantı zaman aşımı hataları

Oturum zaman aşımı kullanılabilirlik grubu ortamınız için çok agresifse bağlantı hatalarıyla karşılaşabilirsiniz.

Belirti -leri

Sık sık aşağıdaki iletileri görebilirsiniz:

Error 35201: A connection timeout has occurred while attempting to establish a connection to availability
replica 'replicaname' with ID [availability_group_id]. Either a networking or firewall issue exists,
or the endpoint address provided for the replica is not the database mirroring endpoint of the host server instance.

Error 35206
A connection timeout has occurred on a previously established connection to availability
replica 'replicaname' with ID [availability_group_id]. Either a networking or a firewall issue
exists, or the availability replica has transitioned to the resolving role.

Çözüm

Oturum zaman aşımınızı Gevşek izleme bölümünde açıklandığı gibi ayarlayın.

Grup devretmiyor

Belirtilen Dönemdeki En Fazla Hata Sayısı değeri çok düşükse ve geçici sorunlardan dolayı aralıklı hatalarla karşılaşıyorsanız, kullanılabilirlik grubunuz başarısız durumda sona erebilir.

Belirti -leri

Not failing over group <Resource name>, failoverCount 3, failoverThresholdSetting <Number>, computedFailoverThreshold 2.

Çözüm

Daha fazla geçici hatayı tolere etmek için izlemenizi, oturum zaman aşımınızı ve Belirtilen Süredeki Maksimum Hata değerini ayarlayın.

Olay 1196 - Ağ adı kaynağı DNS kaydı başarısız oldu

Çözüm

  • Dış DNS kayıtlarının mevcut olmadığından emin olmak için küme düğümlerinizin her birinde NIC ayarlarını denetleyin.
  • İç DNS sunucularınızda kümeniz için A kaydının mevcut olduğundan emin olun. Aksi takdirde, Dns Sunucusu'nda Küme Erişim Denetimi nesnesi için el ile yeni bir A Kaydı oluşturun ve Kimliği doğrulanmış kullanıcıların DNS Kayıtlarını aynı sahip adıyla güncelleştirmesine izin ver'i işaretleyin.
  • Kaynak "Küme Adı"nı ve IP Kaynağını çevrimdışı duruma getirip düzeltin.

Olay 157 - Disk beklenmedik şekilde kaldırıldı

Nedenler

Bu durum aşağıdaki senaryolarda gerçekleşebilir:

  • Depolama Alanları özelliği AutomaticClusteringEnabled bir AG ortamı için True olarak ayarlanır.
  • Depolama ile Doğrulama Raporu Çalıştırılması, diskin sıfırlanması veya beklenmedik şekilde çıkarılma olayını tetikleyebilir.
  • Depolama sistemi Kısıtlama, disk sürpriz kaldırma olayını tetikleyebilir.

Çözüm

Depolama Alanları özelliğini AutomaticClusteringEnabled olarak Falsedeğiştirin.

Olay 1206 - Küme ağ adı kaynağı çevrimiçi duruma getirilemiyor

Nedeni

Kaynakla ilişkilendirilmiş bilgisayar nesnesi etki alanında güncelleştirilemedi.

Çözüm

Etki alanı üzerinde uygun izinlere sahip olduğunuzdan emin olun.

Windows Kümeleme hataları

Küme bağlantı sorunları

Windows yük devretme kümesini veya bağlantısını ayarlarken sorunlarla karşılaşabilirsiniz, eğer Küme Hizmeti Bağlantı Noktaları iletişim için açık değilse.

Windows Server 2019'da Eksik Windows Kümesi IP'si

Windows Server 2019'daysanız ve Windows Kümesi IP'sini görmüyorsanız, yalnızca SQL Server 2019'da desteklenen Dağıtılmış Ağ Adı'yı yapılandırdınız. SQL Server’ın önceki sürümlerini kullanıyorsanız, Ağ Adını Kullanarak Kümeyi Kaldırıp Yeniden Oluşturabilirsiniz.

Ek kaynaklar

Diğer Windows Yük Devretme Yük Devretme Kümelemesi sistem günlüğü olaylarını ve çözümlerini gözden geçirin.

İlgili içerik

Her iyileştirme alanı hakkında ayrıntılı yönergeler için:

HADR hakkında daha fazla bilgi için:

  • Last updated on