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 Makineler(VM) üzerinde 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'da AlwaysOn 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:
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ı, her Bölge bir bölge içindeki bir veri merkezi kümesini temsil eder ve veri merkezinin tamamının hataya karşı korunmasını sağlayın. Kaynakların farklı Kullanılabilirlik Alanları 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 da dikkate alınmalıdır. 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ı bulunan VM'ler arasında daha fazla ağ gecikme süresi vardır 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ı dizesi 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.
Not
Aynı kümede birden çok AG veya FC'niz varsa ve bir DNN veya VNN dinleyicisi kullanıyorsanız, her AG veya FCI'nin kendi bağımsız bağlantı noktasına ihtiyacı vardır.
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:
- SQL Server Yerel İstemcisi ile Bağlantı Dizesi Anahtar Sözcüklerini Kullanma
- İstemcileri Veritabanı Yansıtma Oturumuna (SQL Server) Bağlama
- Karma BT'de Kullanılabilirlik Grubu Dinleyicisine Bağlanma
- Kullanılabilirlik Grubu Dinleyicileri, İstemci Bağlantısı ve Uygulama Yük Devretme (SQL Server)
- Kullanılabilirlik Gruplarıyla Veritabanı Yansıtma Bağlantı Dizelerini Kullanma
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ı dizesi kullanabilirsiniz. bağlantı dizesi kullanmak 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 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ı dizesi sağlayabilir
Server=Replica_A; Failover_Partner=Replica_B; Database=AdventureWorks; Network=dbmssocn
Dağıtım seçenekleri
İpucu
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 | Evet | Evet | 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 | Evet | Yok |
| Bu yöntem kullanılarak DNN dinleyicisi oluşturmak mümkün mü? | Yok | Hayır | Hayır | Evet | 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 | Evet | Yes |
| Birden çok alt ağ desteği | Yes | Hayır | Hayır | YOK | Evet |
| Mevcut AD için destek | Yes | Evet | Evet | Evet | Yes |
| Aynı bölgede birden çok alanı olan DR | Yes | Evet | Evet | Evet | Yes |
| AD olmadan dağıtılmış AG | Hayır | Hayır | Hayır | Evet | Yes |
| Küme olmadan dağıtılmış AG | Hayır | Hayır | Hayır | Evet | Yes |
| Yük dengeleyici veya DNN gerektirir | Hayır | Evet | Evet | Evet | Hayır |
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: