Azure VM'lerinde SQL Server'da Always On kullanılabilirlik grubu

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

Bu makalede, Azure Sanal Makinelerinde (VM) SQL Server için Always On kullanılabilirlik grupları (AG) tanıtılıyor.

Başlamak için kullanılabilirlik grubu öğreticisine bakın.

Genel Bakış

Azure Sanal Makineler'de Always On kullanılabilirlik grupları, şirket içi AlwaysOn kullanılabilirlik gruplarına benzer ve temel alınan Windows Server Yük Devretme Kümesine güvenir. Ancak sanal makineler Azure'da barındırıldığından, VM yedekliliği ve Azure ağında trafiği yönlendirme gibi bazı ek noktalar da vardır.

Aşağıdaki diyagramda Azure VM'lerinde SQL Server için kullanılabilirlik grubu gösterilmektedir:

Availability Group

Not

Artık Azure Geçişi'nin kullanıldığı Azure VM'lerde kullanılabilirlik grubu çözümünüzü kaldırıp SQL Server'a kaydırmanız mümkündür. Daha fazla bilgi için bkz . Kullanılabilirlik grubunu geçirme.

VM yedekliliği

Yedekliliği ve yüksek kullanılabilirliği artırmak için SQL Server VM'leri aynı kullanılabilirlik kümesinde veya farklı kullanılabilirlik alanlarında olmalıdır.

Bir vm kümesinin aynı kullanılabilirlik kümesine yerleştirilmesi, donanım hatasının neden olduğu veri merkezindeki kesintilere (Kullanılabilirlik Kümesindeki VM'ler kaynakları paylaşmaz) veya güncelleştirmelerden (kullanılabilirlik kümesindeki VM'ler aynı anda güncelleştirilmez) korur.

Kullanılabilirlik Alanları, tüm veri merkezinin başarısız olmasına karşı koruma sağlar ve her Bölge bir bölge içindeki bir veri merkezi kümesini temsil eder. Kaynakların farklı Kullanılabilirlik Alanlarına yerleştirildiğinden emin olarak, hiçbir veri merkezi düzeyinde kesinti tüm VM'lerinizi çevrimdışına alamaz.

Azure VM'leri oluştururken Kullanılabilirlik Kümelerini yapılandırma ile Kullanılabilirlik Alanları arasında seçim yapmanız gerekir. Azure VM her iki sanal makineye de katılamaz.

Kullanılabilirlik Alanları Kullanılabilirlik Kümelerinden (%99,99 ile %99,95) daha iyi kullanılabilirlik sağlayabilir ancak performansın da dikkate alınması gerekir. Kullanılabilirlik Kümesi içindeki VM'ler birbirine yakın olmalarını garanti ederek aralarındaki ağ gecikme süresini en aza indiren bir yakınlık yerleştirme grubuna yerleştirilebilir. Farklı Kullanılabilirlik Alanlarında bulunan VM'ler, aralarında daha fazla ağ gecikme süresine sahiptir ve bu da verileri birincil ve ikincil çoğaltmalar arasında eşitleme süresini artırabilir. Bu, birincil çoğaltmada gecikmelere neden olabileceği gibi planlanmamış yük devretme durumunda veri kaybı olasılığını da artırabilir. Önerilen çözümü yük altında test etmek ve hem performans hem de kullanılabilirlik için SLA'ları karşıladığından emin olmak önemlidir.

Bağlantı

Kullanılabilirlik grubu dinleyicinize 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.

SQL Server VM'lerinizi tek bir alt ağa dağıtırsanız, trafiği kullanılabilirlik grubu dinleyicinize yönlendirmek için bir sanal ağ adı (VNN) ve bir Azure Load Balancer ya da dağıtılmış ağ adı (DNN) yapılandırabilirsiniz. İkisi arasındaki farkları gözden geçirin ve ardından kullanılabilirlik grubunuz için dağıtılmış ağ adı (DNN) veya sanal ağ adı (VNN) dağıtın.

Çoğu SQL Server özelliği, DNN kullanılırken 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 . AG ve DNN birlikte çalışabilirliği .

Ayrıca, VNN dinleyicisinin işlevselliği ile DNN dinleyicisi arasında dikkat edilmesi gereken bazı davranış farklılıkları vardır:

  • Yük devretme süresi: Ağ yük dengeleyicinin hata olayını algılamasını ve yönlendirmesini değiştirmesini beklemeye gerek olmadığından, DNN dinleyicisi kullanılırken yük devretme süresi daha hızlıdır.
  • Mevcut bağlantılar: Yük devretme kullanılabilirlik grubu içindeki belirli bir veritabanına yapılan bağlantılar kapanır, ancak yük devretme işlemi sırasında DNN çevrimiçi kaldığından birincil çoğaltmaya yönelik diğer bağlantılar açık kalır. Bu, kullanılabilirlik grubu yük devredildiğinde, dinleyici çevrimdışı olduğunda ve birincil çoğaltma ikincil role geçtiğinde birincil çoğaltmaya yönelik tüm bağlantıların genellikle kapatıldığı geleneksel bir VNN ortamından farklıdır. DNN dinleyicisi kullanırken, yük devretme sırasında bağlantıların yeni birincil çoğaltmaya yönlendirildiğinden emin olmak için uygulama bağlantı dizelerini ayarlamanız gerekebilir.
  • Açık işlemler: Yük devretme kullanılabilirlik grubundaki bir veritabanına karşı açık işlemler kapatılır ve geri alınır ve el ile yeniden bağlanmanız gerekir. Örneğin, SQL Server Management Studio'da sorgu penceresini kapatın ve yenisini açın.

Azure'da VNN dinleyicisi ayarlamak için yük dengeleyici gerekir. Azure'da yük dengeleyiciler için iki ana seçenek vardır: dış (genel) veya iç. Dış (genel) yük dengeleyici İnternet'e yöneliktir ve İnternet üzerinden erişilebilen bir genel sanal IP ile ilişkilendirilir. İç yük dengeleyici yalnızca aynı sanal ağ içindeki istemcileri destekler. Her iki yük dengeleyici türü için de Direct Server Return'i etkinleştirmeniz gerekir.

Hizmet örneğine doğrudan bağlanarak her kullanılabilirlik çoğaltmasına ayrı olarak bağlanmaya devam edebilirsiniz. Ayrıca, kullanılabilirlik grupları veritabanı yansıtma istemcileriyle geriye dönük uyumlu olduğundan, çoğaltmalar veritabanı yansıtmaya benzer şekilde yapılandırıldığı sürece veritabanı yansıtma iş ortakları gibi kullanılabilirlik çoğaltmalarına bağlanabilirsiniz:

  • Bir birincil çoğaltma ve bir ikincil çoğaltma vardır.
  • İkincil çoğaltma okunamaz (Okunabilir İkincil seçeneği Hayır olarak ayarlanır) olarak yapılandırılır.

Aşağıda, ADO.NET veya SQL Server Yerel İstemcisi kullanılarak bu veritabanı yansıtma benzeri yapılandırmaya karşılık gelen örnek bir istemci bağlantı dizesi verilmiştir:

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

İstemci bağlantısı hakkında daha fazla bilgi için bkz:

Tek alt ağ yük dengeleyici gerektirir

Geleneksel bir şirket içi Windows Server Yük Devretme Kümesinde (WSFC) kullanılabilirlik grubu dinleyicisi oluşturduğunuzda, sağladığınız IP adresiyle dinleyici için bir DNS kaydı oluşturulur ve bu IP adresi, şirket içi ağdaki anahtar ve yönlendiricilerin ARP tablolarındaki geçerli Birincil çoğaltmanın MAC adresiyle eşlenir. Küme bunu, yük devretme sonrasında yeni bir Birincil seçildiğinde ağa en son IP-MAC adres eşlemesini yayınlayan Gratuitous ARP (GARP) kullanarak yapar. Bu durumda, IP adresi dinleyiciye yöneliktir ve MAC geçerli Birincil çoğaltmanındır. GARP, anahtarlar ve yönlendiriciler için ARP tablosu girişlerine güncelleştirme yapmaya zorlar ve dinleyici IP adresine bağlanan tüm kullanıcılar geçerli Birincil çoğaltmaya sorunsuz bir şekilde yönlendirilir.

Güvenlik nedeniyle, herhangi bir genel bulutta (Azure, Google, AWS) yayına izin verilmez, bu nedenle Azure'da ARP ve GARP'lerin kullanımı desteklenmez. Ağ ortamlarındaki bu farkı aşmak için, tek bir alt ağ kullanılabilirlik grubundaki SQL Server VM'leri, trafiği uygun IP adreslerine yönlendirmek için yük dengeleyicileri kullanır. Yük dengeleyiciler dinleyiciye karşılık gelen bir ön uç IP adresiyle yapılandırılır ve Azure Load Balancer'ın kullanılabilirlik grubundaki çoğaltmaların durumunu düzenli aralıklarla yoklaması için bir yoklama bağlantı noktası atanır. TCP yoklamasına yalnızca birincil çoğaltma SQL Server VM'sinin yanıt vermesi nedeniyle gelen trafik, yoklama işlemine başarıyla yanıt veren VM'ye yönlendirilir. Buna ek olarak, karşılık gelen yoklama bağlantı noktası WSFC kümesi IP'si olarak yapılandırılır ve Birincil çoğaltmanın TCP yoklamasına yanıt vermesini sağlar.

Tek bir alt ağda yapılandırılan kullanılabilirlik gruplarının, trafiği uygun çoğaltmaya yönlendirmek için yük dengeleyici veya dağıtılmış ağ adı (DNN) kullanması gerekir. Bu bağımlılıkları önlemek için, kullanılabilirlik grubu dinleyicisinin her alt ağdaki bir çoğaltmanın IP adresiyle yapılandırılması ve trafiği uygun şekilde yönlendirebilmesi için birden çok alt ağda kullanılabilirlik grubunuzu yapılandırın.

Kullanılabilirlik grubunuzu zaten tek bir alt ağda oluşturduysanız, bunu çok alt ağlı bir ortama geçirebilirsiniz.

Kiralama mekanizması

SQL Server için AG kaynak DLL'i AG kiralama mekanizmasına ve Always On sistem durumu algılamasına göre AG'nin sistem durumunu belirler. AG kaynak DLL'i, IsAlive işlemi aracılığıyla kaynak durumunu kullanıma sunar. Kaynak izleyicisi, Küme genelindeki CrossSubnetDelay ve SameSubnetDelay değerleri tarafından ayarlanan küme sinyal aralığında IsAlive'i yoklar. Birincil düğümde, kaynak DLL'ye yapılan IsAlive çağrısı AG'nin iyi durumda olmadığını döndürdüğünde küme hizmeti yük devretme başlatır.

AG kaynak DLL'i iç SQL Server bileşenlerinin durumunu izler. Sp_server_diagnostics, HealthCheckTimeout tarafından denetlenen bir aralıkta bu bileşenlerin sistem durumunu SQL Server'a bildirir.

Diğer yük devretme mekanizmalarından farklı olarak, SQL Server örneği kiralama mekanizmasında etkin bir rol oynar. Kiralama mekanizması, Küme kaynak konağı ile SQL Server işlemi arasında LooksAlive doğrulaması olarak kullanılır. Mekanizma, iki tarafın (Küme Hizmeti ve SQL Server hizmeti) sık sık iletişim halinde olduğundan emin olmak, birbirlerinin durumunu denetlemek ve sonuçta bölünmüş beyin senaryosunu önlemek için kullanılır.

Azure VM'lerinde ag yapılandırılırken bu eşiklerin şirket içi ortamda yapılandırılmalarından farklı şekilde yapılandırılması gerekir. Eşik ayarlarını Azure VM'lerine yönelik en iyi yöntemlere göre yapılandırmak için bkz. Küme en iyi yöntemleri.

Ağ yapılandırması

Trafiği kullanılabilirlik grubu dinleyicinize yönlendirmek üzere bir Azure Load Balancer veya dağıtılmış ağ adına (DNN) bağımlılıktan kaçınmak için mümkün olduğunda SQL Server VM'lerinizi birden çok alt ağa dağıtın.

Azure VM yük devretme kümesinde, sunucu başına tek bir NIC (küme düğümü) öneririz. Azure ağı, bir Azure VM yük devretme 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 erişilebildiğine dair bir uyarı yayınlasa da, bu uyarı Azure VM yük devretme kümelerinde güvenle yoksayılabilir.

Temel kullanılabilirlik grubu

Temel kullanılabilirlik grubu birden fazla ikincil çoğaltmaya izin vermediğinden ve ikincil çoğaltmaya okuma erişimi olmadığından, temel kullanılabilirlik grupları için veritabanı yansıtma bağlantı dizelerini kullanabilirsiniz. Bağlantı dizesinin kullanılması dinleyicilerin olması gereksinimini ortadan kaldırır. Yük dengeleyici gereksinimini ortadan kaldıran veya ek veritabanları için birden çok dinleyiciniz olduğunda yük dengeleyiciye ek IP'ler eklemek zorunda kalarak, dinleyici bağımlılığının kaldırılması Azure VM'lerindeki kullanılabilirlik grupları için yararlıdır.

Örneğin, BIR Temel AG'nin (veya yalnızca bir ikincil çoğaltması olan ve ikincil çoğaltmada okuma erişimine izin verilmeyen herhangi bir AG'nin) Replica_A veya Replica_B ÜZERINDE ADVENTUREWorks AG veritabanına TCP/IP kullanarak açıkça bağlanmak için, istemci uygulaması AG'ye başarıyla bağlanmak için aşağıdaki veritabanı yansıtma bağlantı dizesini sağlayabilir

Server=Replica_A; Failover_Partner=Replica_B; Database=AdventureWorks; Network=dbmssocn

Dağıtım seçenekleri

Bahşiş

Sql Server VM'lerinizi aynı Azure sanal ağı içinde birden çok alt ağda oluşturarak Always On kullanılabilirlik grubunuz için Azure Load Balancer veya dağıtılmış ağ adı (DNN) gereksinimini ortadan kaldırın.

Azure VM'lerinde SQL Server'a bir kullanılabilirlik grubu dağıtmak için bazıları diğerlerinden daha fazla otomasyona sahip birden çok seçenek vardır.

Aşağıdaki tabloda kullanılabilir seçeneklerin karşılaştırması sağlanır:

Azure portal, Azure CLI / PowerShell Hızlı Başlangıç Şablonları El ile (tek alt ağ) El ile (birden çok alt ağ)
SQL Server sürümü 2016 + 2016 + 2016 + 2012 + 2012 +
SQL Server yayını Kurumsal Kurumsal Kurumsal Enterprise, Standard Enterprise, Standard
Windows Server sürümü 2016 + 2016 + 2016 + Tümü Tümü
Sizin için kümeyi oluşturur Yes Yes Yes Hayır Hayır
Sizin için kullanılabilirlik grubunu ve dinleyiciyi oluşturur Yes Hayır Hayır Hayır Hayır
Dinleyiciyi ve yük dengeleyiciyi bağımsız olarak oluşturur Yok Hayır Hayır Yes Yok
Bu yöntem kullanılarak DNN dinleyicisi oluşturmak mümkün mü? Yok Hayır Hayır Yes Yok
WSFC çekirdek yapılandırması Bulut tanığı Bulut tanığı Bulut tanığı Tümü Tümü
Birden çok bölgesi olan DR Hayır Hayır Hayır Yes Yes
Birden çok alt ağ desteği Yes Hayır Hayır YOK Evet
Mevcut AD için destek Yes Yes Yes Yes Yes
Aynı bölgede birden çok alanı olan DR Yes Yes Yes Yes Yes
AD olmadan dağıtılmış AG Hayır Hayır Hayır Yes Yes
Küme olmadan dağıtılmış AG Hayır Hayır Hayır Yes Yes
Yük dengeleyici veya DNN gerektirir Hayır Yes Yes Yes Hayı

Sonraki adımlar

Başlamak için HADR en iyi yöntemlerini gözden geçirin ve kullanılabilirlik grubu öğreticisi ile kullanılabilirlik grubunuzu el ile dağıtın.

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