Azure VM'lerinde SQL Server ile Windows Server Yük Devretme Kümesi

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

Bu makalede, Always On kullanılabilirlik grupları (AG) veya yük devretme kümesi örnekleri (FCI) gibi yüksek kullanılabilirlik ve olağanüstü durum kurtarma (HADR) için Azure VM'lerinde SQL Server ile Windows Server Yük Devretme Kümesi özelliğini kullanırken yaşanan farklar açıklanmaktadır.

Windows özelliğinin kendisi hakkında daha fazla bilgi edinmek için Windows Server Yük Devretme Kümesi belgelerine bakın.

Genel Bakış

Windows'da Always On kullanılabilirlik grupları (AG) veya yük devretme kümesi örnekleri (FCI) gibi SQL Server yüksek kullanılabilirlik çözümleri, temel alınan Windows Server Yük Devretme Kümelemesi (WSFC) hizmetini kullanır.

Küme hizmeti, ağ bağlantılarını ve kümedeki düğümlerin durumunu izler. Bu izleme, SQL Server'ın kullanılabilirlik grubu veya yük devretme kümesi örneği özelliğinin bir parçası olarak yaptığı sistem durumu denetimlerine ek olarak gerçekleştirilir. Küme hizmeti düğüme ulaşamıyorsa veya kümedeki AG veya FCI rolü iyi durumda değilse, küme hizmeti uygulamaları ve hizmetleri kurtarmak ve kümedeki başka bir düğümde çevrimiçi duruma getirmek için uygun kurtarma eylemlerini başlatır.

Küme durumu izleme

Yüksek kullanılabilirlik sağlamak için kümenin kümelenmiş çözümü oluşturan farklı bileşenlerin sistem durumunu sağlaması gerekir. Küme hizmeti, hataları algılamak ve yanıtlamak için bir dizi sistem ve ağ parametresine göre kümenin durumunu izler.

Hata bildirme eşiğinin ayarlanması, bir hataya hemen yanıt verme ve hatalı hatalardan kaçınma arasında bir denge elde etmek için önemlidir.

İzlemeye yönelik iki strateji vardır:

İzleme	Description
Agresif	En yüksek kullanılabilirlik düzeylerini sunan hızlı hata algılama ve sabit hataların kurtarılmasını sağlar. Küme hizmeti ve SQL Server hem geçici hatadan daha az bağışlayıcıdır hem de bazı durumlarda geçici kesintiler olduğunda kaynakların yükünü erken devredebilir. Hata algılandıktan sonra, aşağıdaki düzeltici eylem fazladan zaman alabilir.
Rahat	Kısa süreli ağ sorunlarına daha fazla toleransla daha fazla affedici hata algılama sağlar. Geçici hataları önler, ancak aynı zamanda gerçek bir hatanın algılanmasında gecikme riski de ortaya çıkarır.

Buluttaki bir küme ortamındaki agresif ayarlar erken hatalara ve daha uzun kesintilere yol açabilir, bu nedenle Azure VM'lerindeki yük devretme kümeleri için gevşek bir izleme stratejisi önerilir. Eşik ayarlarını ayarlamak için daha fazla ayrıntı için bkz . küme en iyi yöntemleri .

Küme sinyali

Düğümler arasında kümenin kalp atışlarını ve sistem durumunu algılamayı etkileyen birincil ayarlar:

Ayar	Description
Gecikme	Bu, düğümler arasında küme sinyallerinin gönderilme sıklığını tanımlar. Gecikme, sonraki sinyal gönderilmeden önceki saniye sayısıdır. Aynı kümede, aynı alt ağ üzerindeki düğümler arasında ve farklı alt ağlardaki düğümler arasında farklı gecikme ayarları yapılandırılabilir.
Eşik	Eşik, küme kurtarma eylemi gerçekleştirmeden önce atlanacak sinyal sayısıdır. Aynı kümede, aynı alt ağ üzerindeki düğümler arasında ve farklı alt ağlardaki düğümler arasında yapılandırılmış farklı eşik ayarları olabilir.

Bu ayarların varsayılan değerleri bulut ortamları için çok düşük olabilir ve geçici ağ sorunları nedeniyle gereksiz hatalara neden olabilir. Daha toleranslı olmak için Azure VM'lerinde yük devretme kümeleri için gevşek eşik ayarlarını kullanın. Daha fazla ayrıntı için bkz . küme en iyi yöntemleri .

Çekirdek

İki düğümlü bir küme çekirdek kaynağı olmadan çalışacak olsa da, müşterilerin üretim desteğine sahip olmak için bir çekirdek kaynağı kullanması kesinlikle gerekir. Küme doğrulama, çekirdek kaynağı olmadan herhangi bir kümeyi geçirmez.

Teknik olarak, üç düğümlü bir küme çekirdek kaynağı olmadan tek düğüm kaybına (iki düğüme kadar) hayatta kalabilir. Ancak küme iki düğüme düştükten sonra, düğüm kaybolursa veya düğümler arasında bir iletişim hatası olursa kümelenmiş kaynakların bölünmüş beyin senaryolarını önlemek için çevrimdışı olması riski vardır. Çekirdek kaynağının yapılandırılması, küme kaynaklarının yalnızca bir düğümle çevrimiçi kalmasını 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ü
Açıklama	Bulut tanığı, küme çekirdeği üzerinde oy vermek için Microsoft Azure kullanan bir yük devretme kümesi çekirdek tanığı türüdür. Varsayılan boyut yaklaşık 1 MB'tır ve yalnızca zaman damgasını içerir. Bulut tanığı birden çok site, birden çok bölge ve birden çok bölgede dağıtımlar için idealdir. Paylaşılan depolama alanına sahip bir yük devretme kümesi çözümünüz olmadığı sürece mümkün olduğunca bir bulut tanığı kullanın.	Disk tanığı, Küme Kullanılabilir Depolama grubundaki küçük bir kümelenmiş disktir. Bu disk yüksek oranda kullanılabilir ve düğümler arasında yük devredebilir. Küme veritabanının varsayılan boyutu 1 GB'tan küçük olan bir kopyasını içerir. Disk tanığı, Azure Paylaşılan Diskleri (veya paylaşılan SCSI, iSCSI veya fiber kanal SAN gibi herhangi bir paylaşılan disk çözümü) kullanan kümeler için tercih edilen çekirdek seçeneğidir. Kümelenmiş Paylaşılan Birim disk tanığı olarak kullanılamaz. Azure paylaşılan diskini disk tanığı olarak yapılandırın.	Dosya paylaşımı tanığı, genellikle Windows Server çalıştıran bir dosya sunucusunda yapılandırılmış bir SMB dosya paylaşımıdır. Kümeleme bilgilerini bir witness.log dosyasında tutar, ancak küme veritabanının bir kopyasını depolamaz. Azure'da, aynı sanal ağ içindeki ayrı bir sanal makinede dosya paylaşımı yapılandırabilirsiniz. Ortamınızda bir disk tanığı veya bulut tanığı kullanılamıyorsa dosya paylaşımı tanığı kullanın.

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

Sanal ağ adı (VNN)

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ği HADR çözümünüzle yönlendirmek için Azure Load Balancer'a ek bağımlılık gereksinimini azaltır. Daha fazla bilgi edinmek için bkz . Çok alt ağlı AG ve Çok alt ağlı FCI.

Geleneksel bir şirket içi ortamda, yük devretme kümesi örnekleri veya AlwaysOn kullanılabilirlik grupları gibi kümelenmiş kaynaklar, trafiği uygun hedefe (yük devretme kümesi örneği veya Always On kullanılabilirlik grubunun dinleyicisi) yönlendirmek için Sanal Ağ Adı'nı kullanır. Sanal ad, DNS'deki IP adresini bağlar ve istemciler, şu anda kaynağın sahibi olan düğümden bağımsız olarak yüksek kullanılabilirlik hedeflerine bağlanmak için sanal adı veya IP adresini kullanabilir. VNN, küme tarafından yönetilen bir ağ adı ve adresidir ve küme hizmeti bir yük devretme olayı sırasında ağ adresini düğümden düğüme taşır. Hata sırasında, adres özgün birincil çoğaltmada çevrimdışına alınır ve yeni birincil çoğaltmada çevrimiçi duruma getirilir.

Tek bir alt ağdaki Azure Sanal Makineleri'nde, istemciden gelen trafiği kümelenmiş kaynağın Sanal Ağ Adı'na (yük devretme kümesi örneği veya kullanılabilirlik grubunun dinleyicisi) yönlendirmek için ek bir bileşen gerekir. Azure'da yük dengeleyici, kümelenmiş SQL Server kaynaklarının güvendiği VNN'nin IP adresini tutar ve trafiği uygun yüksek kullanılabilirlik hedefine yönlendirmek için gereklidir. Yük dengeleyici ayrıca ağ bileşenlerindeki hataları algılar ve adresi yeni bir konağa taşır.

Yük dengeleyici, ön uca ulaşan gelen akışları dağıtır ve ardından bu trafiği arka uç havuzu tarafından tanımlanan örneklere yönlendirir. Yük dengeleme kurallarını ve sistem durumu yoklamalarını kullanarak trafik akışını yapılandırabilirsiniz. SQL Server FCI ile arka uç havuzu örnekleri SQL Server çalıştıran Azure sanal makineleridir ve kullanılabilirlik gruplarıyla arka uç havuzu dinleyicidir. Durum yoklaması varsayılan olarak her 10 saniyede bir canlı denetimler yürüttüğünden yük dengeleyiciyi kullanırken hafif bir yük devretme gecikmesi yaşanıyor.

Başlamak için yük devretme kümesi örneği veya kullanılabilirlik grubu için Azure Load Balancer'ı yapılandırmayı öğrenin.

Desteklenen işletim sistemi: Tümü
Desteklenen SQL sürümü: Tümü
Desteklenen HADR çözümü: Yük devretme kümesi örneği ve kullanılabilirlik grubu

VNN yapılandırması zahmetli olabilir, ek bir hata kaynağıdır, hata algılamada gecikmeye neden olabilir ve ek kaynağı yönetmeyle ilişkili bir ek yük ve maliyet vardır. Bu sınırlamalardan bazılarını gidermek için SQL Server, Dağıtılmış Ağ Adı özelliği için destek kullanıma sunulmuştur.

Dağıtılmış ağ adı (DNN)

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ğa sahip olmak, trafiği HADR çözümünüzle yönlendirmek için bir DNN'ye ek bağımlılık gereksinimini azaltır. Daha fazla bilgi edinmek için bkz . Çok alt ağlı AG ve Çok alt ağlı FCI.

Tek bir alt ağa dağıtılan SQL Server VM'leri için dağıtılmış ağ adı özelliği, SQL Server istemcilerinin yük dengeleyici kullanmadan SQL Server yük devretme kümesi örneğine veya kullanılabilirlik grubu dinleyicisine bağlanması için alternatif bir yol sağlar. DNN özelliği Windows Server 2016 ve sonraki sürümlerde SQL Server 2016 SP3, SQL Server 2017 CU25, SQL Server 2019 CU8 ile başlayarak kullanılabilir.

Bir DNN kaynağı oluşturulduğunda, küme DNS adını kümedeki tüm düğümlerin IP adresleriyle bağlar. İstemci, hangi kaynağa bağlanacağını bulmak için bu listedeki her IP adresine bağlanmayı dener. Bağlantı dizesinde belirterek MultiSubnetFailover=True bu işlemi hızlandırabilirsiniz. Bu ayar sağlayıcıya tüm IP adreslerini paralel olarak denemesini bildirir, böylece istemci anında FCI'ya veya dinleyiciye bağlanabilir.

Mümkün olduğunda yük dengeleyici üzerinden dağıtılmış ağ adı önerilir çünkü:

• 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.

Çoğu SQL Server özelliği, DNN kullanılırken FCI ve kullanılabilirlik gruplarıyla saydam bir şekilde çalışır, ancak özellikle dikkat edilmesi gereken bazı özellikler vardır.

Desteklenen işletim sistemi: Windows Server 2016 ve üzeri
Desteklenen SQL sürümü: SQL Server 2019 CU2 (FCI) ve SQL Server 2019 CU8 (AG)
Desteklenen HADR çözümü: Yük devretme kümesi örneği ve kullanılabilirlik grubu

Başlamak için yük devretme kümesi örneği veya kullanılabilirlik grubu için dağıtılmış ağ adı kaynağı yapılandırmayı öğrenin.

DNN'yi diğer SQL Server özellikleriyle kullanırken dikkat edilmesi gereken ek noktalar vardır. Daha fazla bilgi edinmek için bkz . FCI ve DNN birlikte çalışabilirliği ve AG ve DNN birlikte çalışabilirliği .

Kurtarma eylemleri

Küme hizmeti bir hata algılandığında düzeltici eylem gerçekleştirir. Bu, mevcut düğümdeki kaynağı yeniden başlatabilir veya kaynağı başka bir düğüme devredebilir. Düzeltici önlemler başlatıldıktan sonra tamamlanması biraz zaman alır.

Örneğin, yeniden başlatılan bir kullanılabilirlik grubu aşağıdaki sırayla çevrimiçi olur:

1. Dinleyici IP'leri çevrimiçi oluyor
2. Dinleyici ağ adı çevrimiçi geliyor
3. Kullanılabilirlik grubu çevrimiçi olur
4. Tek tek veritabanları kurtarma işleminden geçer ve bu da yineleme günlüğünün uzunluğu gibi bir dizi faktöre bağlı olarak biraz zaman alabilir. Bağlantılar, yalnızca veritabanı tamamen kurtarıldıktan sonra dinleyici tarafından yönlendirilir. Daha fazla bilgi edinmek için bkz . Yük devretme süresini tahmin etme (RTO).

Kurtarma biraz zaman alabileceğinden, 20 saniye içinde bir hatayı algılamaya yönelik agresif izleme kümesi, geçici bir olay oluşursa (bellek koruma Azure VM bakımı gibi) dakika kesintisine neden olabilir. İzlemeyi 40 saniyelik daha rahat bir değere ayarlamak, hizmetin daha uzun süre kesintiye uğramasını önlemeye yardımcı olabilir.

Eşik ayarlarını ayarlamak için daha fazla ayrıntı için bkz . küme en iyi yöntemleri .

Düğüm konumu

Azure'daki sanal makinelerdeki bir Windows kümesindeki düğümler, fiziksel olarak aynı Azure bölgesinde veya farklı bölgelerde olabilir. Uzaklık, küme düğümlerinin kendi tesislerinizdeki konumlar arasında yayılması gibi ağ gecikme süresine neden olabilir. Bulut ortamlarında fark, bir bölge içinde düğümler arasındaki mesafenin farkında olmayabilirsiniz. Ayrıca, fiziksel ve sanal bileşenler, atlama sayısı vb. gibi diğer bazı faktörler. daha fazla gecikme süresine de katkıda bulunabilir. Düğümler arasındaki gecikme süresi önemliyse, ağ yakınlığını garanti etmek için kümenin düğümlerini yakınlık yerleştirme grubuna yerleştirmeyi göz önünde bulundurun.

Kaynak sınırları

Azure VM'sini yapılandırırken CPU, bellek ve GÇ için bilgi işlem kaynakları sınırlarını belirlersiniz. Satın alınan Azure VM'den daha fazla kaynak gerektiren iş yükleri veya disk sınırları VM performans sorunlarına neden olabilir. Performans düşüşü küme hizmeti veya SQL Server yüksek kullanılabilirlik özelliği için sistem durumu denetiminin başarısız olmasına neden olabilir. Kaynak performans sorunları düğümün veya kaynağın kümede veya SQL Server'da görünmesine neden olabilir.

Yoğun SQL GÇ işlemleri veya yedeklemeler, dizin veya istatistik bakımı gibi bakım işlemleri VM veya diskin IOPS veya MBPS aktarım hızı sınırlarına ulaşmasına neden olabilir ve bu da SQL Server'ın IsAlive/LooksAlive denetimine yanıt vermesine neden olabilir.

SQL Server'ınız beklenmeyen yük devretmelerle karşılaşıyorsa, tüm performans en iyi yöntemlerini izlediğinizden emin olun ve sunucuyu disk veya VM düzeyinde sınırlama için izleyin.

Azure platform bakımı

Diğer tüm bulut hizmetlerinde olduğu gibi Azure da sanal makineler için konak altyapısının güvenilirliğini, performansını ve güvenliğini artırmak için platformunu düzenli aralıklarla güncelleştirir. Bu güncelleştirmelerin amacı, barındırma ortamındaki yazılım bileşenlerine düzeltme eki uygulamadan ağ bileşenlerini yükseltmeye veya donanımı kullanımdan kaldırmaya kadar değişiklik gösterir.

Çoğu platform güncelleştirmesi müşteri VM'lerini etkilemez. Etkisi olmayan bir güncelleştirme mümkün olmadığında Azure, müşteri VM'leri en az etkileyen güncelleştirme mekanizmasını seçer. Sıfırdan etkilenmeyen bakımların çoğu VM'yi 10 saniyeden kısa bir süre duraklatır. Azure bazı durumlarda bellek koruyucu bakım mekanizmalarını kullanır. Bu mekanizmalar VM'yi 30 saniyeye kadar duraklatır ve BELLEĞI RAM'de korur. Ardından VM sürdürülür ve saati otomatik olarak eşitlenir.

Bellek koruma bakımı, Azure VM'lerinin yüzde 90'ından fazlası için çalışır. G, M, N ve H serileri için çalışmaz. Azure, dinamik geçiş teknolojilerini giderek daha fazla kullanır ve duraklatma sürelerini azaltmak için bellek koruma bakım mekanizmalarını geliştirir. VM farklı bir konağa canlı geçirildiğinde, SQL Server gibi bazı hassas iş yükleri, VM'nin duraklatıldığı birkaç dakika içinde hafif bir performans düşüşü gösterebilir.

Platform bakımı sırasında oluşan bir kaynak sorunu AG veya FCI'nin küme hizmetinde görünmesine neden olabilir. Daha fazla bilgi edinmek için bu makalenin kaynak sınırları bölümüne bakın.

Agresif küme izleme kullanıyorsanız, genişletilmiş bir VM duraklatılması yük devretmeyi tetikleyebilir. Yük devretme genellikle bakımın duraklatılmasından daha fazla kapalı kalma süresine neden olur, bu nedenle vm bakım için duraklatılırken yük devretmeyi tetiklememek için gevşek izleme kullanılması önerilir. Azure VM'lerinde küme eşiklerini ayarlama hakkında daha fazla bilgi için bkz. küme en iyi yöntemleri .

Sınırlamalar

Azure Sanal Makineler'de FCI veya kullanılabilirlik grupları ve SQL Server ile çalışırken aşağıdaki sınırlamaları göz önünde bulundurun.

MSDTC

Azure Sanal Makineleri, Windows Server 2019'da Kümelenmiş Paylaşılan Birimler (CSV) ve Azure Standart Yük Dengeleyici veya Azure paylaşılan diskleri kullanan SQL Server VM'lerinde depolama ile Microsoft Dağıtılmış İşlem Düzenleyicisi'nin (MSDTC) desteklenmesine neden olur.

Azure Sanal Makineler'de MSDTC, Kümelenmiş Paylaşılan Birimlere sahip Windows Server 2016 veya önceki sürümlerinde desteklenmez çünkü:

• Kümelenmiş MSDTC kaynağı paylaşılan depolamayı kullanacak şekilde yapılandırılamaz. Windows Server 2016'da bir MSDTC kaynağı oluşturursanız, kullanılabilir depolama alanı olsa bile kullanılabilir paylaşılan depolama alanı gösterilmez. Bu sorun Windows Server 2019'da düzeltilmiştir.
• Temel yük dengeleyici RPC bağlantı noktalarını işlemez.

Sonraki adımlar

Azure VM'lerinde SQL Server ile Windows Yük Devretme Kümesi kullanırken farklılıklar hakkında bilgi edindiğinize göre, yüksek kullanılabilirlik özellikleri kullanılabilirlik grupları veya yük devretme kümesi örnekleri hakkında bilgi edinin. Kullanmaya başlamaya hazırsanız yapılandırma önerileri için en iyi yöntemleri gözden geçirmeyi unutmayın.