Aracılığıyla paylaş

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

  • Makale

Ş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 birlikte 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 yöntemleri sağlanı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 . sinyal ve eşik ayarları. Windows Server 2012 ve üzeri için aşağıdaki önerilen değerleri kullanın:
    • SameSubnetDelay: 1 saniye
    • SameSubnetThreshold: 40 sinyal
    • CrossSubnetDelay: 1 saniye
    • CrossSubnetThreshold: 40 sinyal
  • 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 çekirdek oylamasını 3 veya daha fazla tek sayıda oy kullanacak şekilde yapılandırın. DR bölgelerine oy atayı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 geçin.

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ı dizesi belirtinMultiSubnetFailover = true.
    • İ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:
    • destekleyen bir istemci sürücüsü MultiSubnetFailover = Truekullanmanız ve bu parametrenin bağlantı dizesi olması gerekir.
    • Kullanılabilirlik grubu için DNN dinleyicisine bağlanırken bağlantı dizesi 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:

  • En düşük gecikme süresi için yakınlık yerleştirme gruplarını hızlandırılmış ağ ile birlikte kullanın.
  • Veri merkezi düzeyindeki hatalardan korumak için sanal makine kümesi düğümlerini ayrı kullanılabilirlik alanlarına veya aynı veri merkezinde daha düşük gecikme süreli yedeklilik için tek bir kullanılabilirlik kümesine yerleştirin.
  • Bir kullanılabilirlik kümesindeki VM'ler için premium yönetilen işletim sistemi ve veri diskleri kullanın.
  • Her uygulama katmanını ayrı kullanılabilirlik kümelerine yapılandırın.

Yetersayı

İki düğümlü bir küme çekirdek kaynağı olmadan çalışır, ancak müşterilerin üretim desteğine sahip olmak için bir çekirdek kaynağı kullanması kesinlikle gerekir. Küme doğrulama, çekirdek 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. Çekirdek kaynağının yapılandırılması, kümenin çevrimiçi olarak yalnızca bir düğümle çevrimiçi olarak devam etmesini sağlar.

Disk tanığı en dayanıklı çekirdek seçeneğidir, ancak Azure VM'de SQL Server'da disk tanığı kullanmak için, yüksek kullanılabilirlik çözümüne bazı sınırlamalar getiren 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 çekirdek 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ığı , birden çok site, birden çok bölge ve birden çok bölgede 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ığı en dayanıklı çekirdek seçeneğidir ve Azure Paylaşılan Diskleri (veya paylaşılan SCSI, iSCSI veya fiber kanal SAN gibi herhangi bir paylaşılan disk çözümü) kullanan tüm kümeler için tercih edilir. Kümelenmiş Paylaşılan Birim disk tanığı olarak kullanılamaz.
  • Dosya paylaşımı tanığı , disk tanığı ve bulut tanığının kullanılamadığı seçenekler için uygundur.

Başlamak için bkz . Küme çekirdeğini yapılandırma.

Çekirdek Oylaması

Windows Server Yük Devretme Kümesine katılan bir düğümün çekirdek oylarını değiştirmek mümkündür.

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

Çekirdek 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ı 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 sahipleri için oyları etkinleştirin. Otomatik yük devretmenin sonucu olarak birincil çoğaltmayı veya FCI'yi barındırabilecek her düğümün oyu olmalıdır.
Bir kullanılabilirlik grubunun birden fazla ikincil çoğaltması varsa, yalnızca otomatik yük devretmesi olan çoğaltmalar için oyları etkinleştirin.
İkincil olağanüstü durum kurtarma sitelerindeki düğümler için oyları devre dışı bırakın. İkincil sitelerdeki düğümler, birincil siteyle ilgili bir sorun yoksa kümeyi çevrimdışına alma kararına katkıda bulunmamalıdır.
En az üç çekirdek oyuyla tek sayıda oy elde edin. İki düğümlü bir kümede gerekirse ek oylama için bir çekirdek tanığı ekleyin.
Yük devretme sonrasında oy atamalarını yeniden değerlendirin. İyi durumdaki bir çekirdeği desteklemeyen bir küme yapılandırmasına yük devretmek istemezsiniz.

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 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 bkz . Çok alt ağlı AG ve Çok alt ağlı FCI.

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ı, 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 en aza indirir.
  • 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ı dizesi'leri güncelleştirmeye gerek kalmadan alt ağların daha sonra yayılmasını desteklemek üzere tek bir alt ağa yayılan HADR çözümleri için bile bağlantı dizesi MultiSubnetFailover = true parametresini ayarlayın.

Sinyal ve eşik

Küme sinyali ve eşik ayarlarını gevşek 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ğı, TCP'den çok daha az güvenilir ve tamamlanmamış konuşmalara daha yatkın olan UDP 3343 ile korunur.

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 toplam sistem durumu algılaması üzerinde birikmeli etkisi vardır. Örneğin, CrossSubnetDelay'ı her 2 saniyede bir sinyal gönderecek şekilde ayarlamak ve kurtarma işlemi yapılmadan önce CrossSubnetThreshold değerini 10 yanıtsız sinyal olarak ayarlamak, kurtarma eylemi gerçekleştirilmeden önce kümenin toplam ağ toleransı 20 saniye olabileceği anlamına gelir. Genel olarak, sık sinyal göndermeye devam etmek, ancak daha büyük eşiklere sahip olmak 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
SameSubnetDelay 1 saniye 2 saniye
SameSubnetThreshold 40 sinyal 10 sinyal (maksimum)
CrossSubnetDelay 1 saniye 2 saniye
CrossSubnetThreshold 40 sinyal 20 sinyal (maksimum)

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

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

Değişikliklerinizi doğrulamak için PowerShell'i kullanın:

get-cluster | fl *subnet*

Aşağıdaki topluluklara bir göz atın:

  • 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.
  • SameSubnetThreshold <= CrossSubnetThreshold
  • SameSubnetDelay <= CrossSubnetDelay

Uygulamanıza, iş gereksinimlerinize ve ortamınıza bağlı olarak bir düzeltme eyleminin ne kadar zaman önce gerçekleşeceğini ve ne kadar süreyle çalışılabilir olduğunu temel alarak gevşek 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:

Başvuru için aşağıdaki tabloda varsayılan değerler ayrıntılı olarak yer alır:

Ayar Windows Server 2019 Windows Server 2016 Windows Server 2008 - 2012 R2
SameSubnetDelay 1 saniye 1 saniye 1 saniye
SameSubnetThreshold 20 sinyal 10 sinyal 5 sinyal
CrossSubnetDelay 1 saniye 1 saniye 1 saniye
CrossSubnetThreshold 20 sinyal 10 sinyal 5 sinyal

Daha fazla bilgi için bkz . Yük Devretme Kümesi Ağ Eşiklerini Ayarlama.

Gevşek izleme

Küme sinyal ve eşik ayarlarınızı önerilen şekilde ayarlamak yeterli tolerans değilse ve gerçek kesintiler yerine geçici sorunlar nedeniyle yük devretmeleri görmeye devam ediyorsanız, AG veya FCI izlemenizi daha rahat 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 Default value Gevşek Değer Açıklama
Sistem durumu denetimi zaman aşımı 30000 60000 Birincil çoğaltmanın veya düğümün sistem durumunu belirler. Küme kaynak DLL'i sp_server_diagnostics sonuçları, sistem durumu denetimi zaman aşımı eşiğinin 1/3'lerine eşit bir aralıkta döndürür. Yavaşsa sp_server_diagnostics veya bilgi döndürmezse, kaynak DLL kaynağın yanıt vermediğini belirlemeden ve yapılandırıldıysa otomatik yük devretme başlatmadan önce sistem durumu denetimi zaman aşımı eşiğinin tam aralığını 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) kullanın.

Kullanılabilirlik grupları için:

ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT =60000);
ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 2);

Yük devretme kümesi örnekleri için:

ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY HealthCheckTimeout = 60000;
ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY FailureConditionLevel = 2;

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

Parametre Default value Gevşek Değer Açıklama
Kira zaman aşımı 20000 40000 Bölünmüş beyinleri önler.
Oturum zaman aşımı 10000 20000 Çoğaltmalar arasındaki iletişim sorunlarını denetler. Oturum zaman aşımı süresi, kullanılabilirlik çoğaltmasının bağlantının başarısız olduğu düşünülmeden önce bağlı bir çoğaltmadan ping yanıtı bekleme süresinin (saniye cinsinden) ne olduğunu denetleyen 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. Bir değerin çok düşük olması AG'nin başarısız durumda olmasına neden olabileceğinden performans sorunlarından kısa kesintileri önlemek için değeri artırın.

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 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.
  • Zaman uyumlu işleme çoğaltmaları için, oturum zaman aşımının yüksek bir değerle değiştirilmesi HADR_sync_commit beklemeleri artırabilir.

Kira zaman aşımı

Kullanılabilirlik grubunuzun kira zaman aşımı ayarlarını değiştirmek için Yük Devretme Kümesi Yöneticisi'ni kullanın. 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) kullanın:

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

Belirtilen dönemdeki en fazla hata sayısı

Belirtilen dönem değerindeki Maksimum hataları değiştirmek için Yük Devretme Kümesi Yöneticisi'ni 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önem değerindeki en büyük hataları 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 sınırlarıyla ilgili sorunlarla karşılaşıyorsanız aşağıdakileri göz önünde bulundurun:

  • Yük devretmeye neden olabilecek disk performansı sorunlarını belirlemek için Azure portalında G/Ç Analizi 'ni (Önizleme) kullanın.
  • İşletim sistemi, sürücüler ve SQL Server'ın en son derlemelerde olduğundan emin olun.
  • Azure'da SQL Server için performans yönergelerinde açıklandığı gibi Azure VM ortamında SQL Server'Sanal Makineler iyileştirme
  • Kullanma
  • Kaynak sınırlarını aşmadan kullanımı azaltmak için iş yükünü azaltma veya dağıtma
  • Herhangi bir fırsat varsa SQL Server iş yükünü ayarlayın, örneğin
    • Dizinleri ekleme/iyileştirme
    • Gerektiğinde ve mümkünse Tam tarama ile 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.
  • İş 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ığı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.

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 çevrimiçi olmaz.
  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 ve çekirdek kaybeder ve kümeyi kapatır.
  6. NODE1, NODE2'ye paket gönderebilir, ancak NODE2 yanıtlayamaz. NODE1 çekirdek 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.

SQL Server veritabanı altyapısı, Always On kullanılabilirlik grubu dinleyicisi, yük devretme kümesi örneği sistem durumu yoklaması, veritabanı yansıtma uç noktası, küme çekirdek IP kaynağı veya başka bir SQL kaynağı 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. Bunun yapılması, diğer sistem işlemlerinin 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

Bağlantı noktası kullanımda olmadığında bağlantı noktası dışlama yapılandırması önemlidir, aksi takdirde komut "Başka bir işlem tarafından kullanıldığından işlem dosyaya erişemiyor" gibi bir iletiyle başarısız olur.

Dışlamaların doğru yapılandırıldığını onaylamak için şu komutu kullanın: netsh int ipv4 show excludedportrange tcp.

Kullanılabilirlik grubu rolü IP yoklaması bağlantı noktası için bu dışlamanın ayarlanması Olay Kimliği: 1069 ve durum 10048 gibi olayları engellemelidir. Bu olay, Windows Yük Devretme kümesi olaylarında aşağıdaki iletiyle görülebilir:

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**
Status [**10048**](/windows/win32/winsock/windows-sockets-error-codes-2) refers to: **This error occurs** if an application attempts to bind a socket to an **IP address/port that has already been used** for an existing socket.

Bunun nedeni, yoklama bağlantı noktası olarak tanımlanan aynı bağlantı noktasını alan bir iç işlem olabilir. Yoklama bağlantı noktasının Azure Load Balancer'dan bir arka uç havuzu örneğinin durumunu denetlemek için kullanıldığını unutmayın.
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 bağlantı gönderilmez.

Bilinen sorunlar

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

Kaynak çekişmesi (özellikle GÇ) yük devretmeye neden oluyor

VM için G/Ç veya CPU kapasitesinin tükenmesi, kullanılabilirlik grubunuzun yük devretmesine 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/Ç Analizini Kullanma

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

VM depolama GÇ ölçümleriyle izleme

VM veya disk düzeyinde gecikme süresini anlamak için Depolama GÇ Kullanımı ölçümlerine bakmak için Azure Sanal Makineler izleyin.

Azure VM Genel GÇ Tükenmesi olayını gözden geçirmek için şu adımları izleyin:

  1. SQL sanal makinelerinde değil Azure portalında Sanal Makinenize gidin.

  2. Ölçümler sayfasını açmak için İzleme'nin altında Ölçümler'i seç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 Önbelleğe Alınan Bant Genişliği Tüketilen Yüzdesi
    • VM Tarafından Tüketilen Önbelleğe Alınmamış Bant Genişliği 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. Bir Azure VM HostEvent'in yük devretmeye neden olduğunu düşünüyorsanız Azure İzleyici Etkinlik günlüğünü ve Azure VM Kaynak Durumu genel bakışını de kontrol edebilirsiniz.

Azure İzleyici etkinlik günlüğü, Azure'da abonelik düzeyinde olaylar hakkında içgörü sağlayan bir platform günlüğüdür. Etkinlik günlüğü, bir kaynağın ne zaman değiştirildiği veya bir sanal makinenin başlatılmış olması gibi bilgileri içerir. 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ü 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. Zaman aralığı'nı seçin ve ardından kullanılabilirlik grubunuzun yük devredileceği zaman dilimini seçin. Uygula’yı seçin.

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

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.

  1. Azure portalında Sanal Makinenize gidin
  2. Sistem Durumu bölmesinin altındaki Kaynak Durumu seçin.

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

Bu sayfadan sistem durumu 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, 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.

Kiranın süresi doldu / Kira artık geçerli değil

İ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. Ayrıca 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.

Bağlantı zaman aşımı

Oturum zaman aşımı kullanılabilirlik grubu ortamınız için çok agresifse, 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.

Grup yük devredmiyor

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. Daha geçici hataları tolere etmek için bu değeri artırın.

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

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

  • 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. Yoksa, DNS Sunucusunda 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 sahip adı aynı olan DNS Kayıtlarını güncelleştirmesine izin ver seçeneğini işaretleyin.
  • IP Kaynağına sahip Kaynak "Küme Adı"nı çevrimdışına alın ve düzeltin.

Olay 157 - Disk kaldırıldı.

AG ortamı için Depolama Alanları AutomaticClusteringEnabled özelliği True olarak ayarlandığında bu durum oluşabilir. Bunu False olarak değiştirin. Ayrıca Depolama seçeneğiyle bir Doğrulama Raporu çalıştırmak disk sıfırlamayı veya beklenmedik kaldırılma olayını tetikleyebilir. Depolama sistemi Azaltması da diski beklenmedik kaldırma olayını tetikleyebilir.

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

Kaynakla ilişkilendirilmiş bilgisayar nesnesi etki alanında güncelleştirilemedi. Etki alanı üzerinde uygun izinlere sahip olduğunuzdan emin olun

Windows Kümeleme hataları

İletişim için Açık Küme Hizmeti Bağlantı Noktalarınız yoksa Windows yük devretme kümesini veya bağlantısını ayarlarken sorunlarla karşılaşabilirsiniz.

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

Diğer Windows Yük Devretme Kümeleme Olayları Hatalarını ve çözümlerini burada gözden geçirin

Sonraki adımlar

Daha fazla bilgi edinmek için şu makalelere bakın: