Bir sunucu makinesi arızalansa bile, veritabanı arka ucu olarak SQL Server 2012'ye dayanan uygulamanızın gün boyunca kullanılabilir olduğundan emin olmanız gerektiğini varsayalım.

Bir DBA değil bir geliştirici olarak, yerine çalışma / yüksek kullanılabilirlik durumum için hangi senaryoyu ne zaman kullanacağımı anlamakta zorlanıyorum:

• Windows Yük Devretme kümesindeki iki (veya daha fazla) sunucu, kümelenmiş bir örnek olarak SQL Server
• İşlemsel çoğaltma ile güncel tutulan iki (veya daha fazla) SQL Server örneği
• SQL Server Kullanılabilirlik Grubu'ndaki iki (veya daha fazla) SQL Sunucusu, senkronize bir işlem modunda yapılandırılmış

Bu senaryolardan hangisi ne tür bir iş yükü için işe yarıyor ve bu senaryolarda ne tür bir başarısızlık / kesinti ele alınabiliyor? Hatta karşılaştırılabilir / değiştirilebilir mi?

Yüksek kullanılabilirlik çözümlerini her zaman görselleştirmeyi sevdiğim yol şudur:

SQL Server Yük Devretme Kümesi Örneği (FCI)

Son derece müsait olan nedir? Tüm örnek. Tüm sunucu nesnelerini içerir (girişler, SQL Server Agent işleri vb.). Bu aynı zamanda veritabanlarını ve içerdikleri varlıkları da içerir. Oldukça uygun olan SQL Server örnekleri için mükemmel bir çözüm, çünkü bu verilen çözümle sınırlılık seviyesi olacak.

Peki ya raporlama? Yok, NULL, var olmayan. Yük devretme kümesi örneği, VNN, vb. Örneğini içeren küme grubunu sağlayan etkin bir düğüme sahiptir ve diğer tüm düğümler pasif, boşta (boş küme grubu söz konusu olduğunda) ve yerine çalışma için beklemededir.

Yük devretme olduğunda ne olur? Bir FCI'nın kapalı kalma süresi, pasif düğümün küme kaynağını almak ve SQL Server örneğini çalışan bir duruma getirmek için harcadığı zaman miktarına göre belirlenir. Bu genellikle zamanla asgari düzeydedir.

Herhangi bir müşteri soyutlama? Evet, bu başarısızlık küme örneği için sanal ağ adı ile yerleşik olarak inşa edilecek. Bu, her zaman şu anda SQL Server küme kaynağını sağlayan etkin düğüme işaret edecektir.

AlwaysOn Kullanılabilirlik Grupları

Son derece müsait olan nedir? Bir uygunluk grubu, burada yüksek kullanılabilirliğin mantıksal bir içeriği olacak, oysa bir kullanılabilirlik grubu bir dizi veri tabanından ve bir sanal ağ adından (dinleyici, isteğe bağlı bir küme kaynağı) oluşur. Girişler ve SQL Server Agent işleri gibi sunucu nesnelerinin HA çözümünün bir parçası olmayacağına ve bunların bir uygunluk grubuyla düzgün bir şekilde uygulanmasını sağlamak için özel dikkat gösterilmesi gerektiğine dikkat etmek önemlidir. Aşırı yük gerekliliği değil, dikkat edilmesi gerekenler.

Peki ya raporlama? Bu raporlama için harika bir çözüm olsa da, muhtemelen raporlama örneğimde senkronize bir kopya kullanmam. Senkronize ve asenkronize olmak üzere iki taahhüt ilişkisi vardır. Bence ve pratikte gördüğüm kadarıyla, eşzamanlı ikincil eşlemenizin orada bir felaketi beklediği. Bir sorun durumunda, veri kaybı yaşanmayan bir yük devretme almaya hazır olan kopya olarak düşünün. Sonra, bu raporlanan iş yükünü idare edebilecek eşzamansız kopyalar var. Bu kopyayı yukarıda belirtilen çözüm olarak kullanmıyorsunuz, raporlama gibi şeyler için de ustaca kullanıyorsunuz. Raporlama iş yükleri bu kopyaya gösterilebilir (doğrudan veya dolaylı olarak dinleyici aracılığıyla salt okunur yönlendirme yoluyla).

Yük devretme olduğunda ne olur? Otomatik yük devretme ile eşleştirilmiş olan senkronize bir ikincil ikincil çoğaltma için bu, SECONDARY_NORMAL öğesinden PRIMARY_NORMAL sürümüne eşlenen çoğaltma rolü durumu olacaktır. Otomatik yük devretme yapabilmek için, şu anda senkronize olan eşzamanlı bir ikincil çoğaltmanız gerekir ve gerçekte bu yük devretmenin ne zaman gerçekleşeceğini belirlemek için uygulanan Esnek Yük Devretme Politikası'dır . Bu politika gerçekten yapılandırılabilir.

Herhangi bir müşteri soyutlama? Evet, isteğe bağlı olarak bir AlwaysOn Uygunluk Grubu dinleyicisini yapılandırabilirsiniz. Bu temelde mevcut birincil kopyalamaya işaret eden yalnızca sanal bir ağ adıdır (WSFC aracılığıyla AG'nin küme grubunda küme kaynağı olarak görülebilir). Bu, raporlama iş yükünüzü değiştirmenin ve ReadOnly trafiğini yönlendirmek istediğiniz sunucularda salt okunur bir yönlendirme listesi ayarlamanın (bu, SQL için .NET Framework Sağlayıcısı ile bağlantı dizesiyle ayarlanır) önemli bir parçasıdır Sunucu, bu ReadOnly olarak ayarlanan Application Intent parametresi olacaktır . Ayrıca, ikincil çoğaltma rolündeyken bu raporlama iş yükünü almak istediğiniz her kopya için salt okunur bir yönlendirme URL'si ayarlamanız gerekir.

İşlem çoğaltma

Son derece müsait olan nedir? Bu tartışmalı, ama hiçbir şey söylemeyeceğim . Çoğaltmayı herhangi bir şekilde kullanılabilirliği yüksek bir çözüm olarak görmüyorum. Evet, veri değişiklikleri abonelere iletiliyor, ancak yayın / makale düzeyinde konuşuyoruz. Bu, verilerin bir alt kümesi olacak (tüm verileri içerebilir, ancak bu uygulanmayacak. Yani, yayıncı veritabanında yeni bir tablo oluşturursunuz ve bu otomatik olarak abonelere gönderilmez). HA gittikçe, bu varilin dibidir ve onu kaya gibi bir HA çözeltisiyle oraya gruplayamayacağım.

Peki ya raporlama? Bir veri alt kümesinde raporlama için harika bir çözüm, bunun hakkında soru yok. Çok işlemli bir 1 TB veritabanınız varsa ve bu raporlanan iş yükünü OLTP veritabanından uzak tutmak istiyorsanız, işlem çoğaltması raporlama iş yükü için bir alt veri grubunu bir aboneye (veya abonelere) itmenin harika bir yoludur. Raporlama iş yükünüz yaklaşık 50 GB ise, bu 1 TB’lık veri dışında ne olur? Bu akıllı bir çözümdür ve iş gereksinimlerinizi karşılamak için nispeten yapılandırılabilir.

özet

(Kısmen işletme tarafından) cevaplanması gereken birkaç soru var.

1. Neyin yüksek oranda erişilebilir olması gerekiyor ?
2. SLA , HA / DR için neyi belirler?
3. Ne tür raporlamalar olacak ve hangi gecikmeler kabul edilebilir?
4. Coğrafi olarak dağınık HA ile başa çıkmak için neye ihtiyacımız var ? (depolama çoğaltması pahalıdır, ancak bir FCI’da olması zorunludur. AG’ler, bağımsız örneklerden paylaşılan depolama gerektirmezler ve paylaşılan depolama gereksinimini ortadan kaldıracak yeterlilikte bir dosya paylaşımına şahit olabilirsiniz)

Windows Yük Devretme kümesinde iki (veya daha fazla) sunucu, kümelenmiş bir örnek olarak SQL Server

1. Ne tür bir iş yükü? "Bağlıdır" - ancak ciddiyetle, bu veri merkezinde Yüksek Erişilebilirlik yerel olması gereken bir çevrimiçi uygulama için kullanışlıdır. Bir makinenin veya bir işletim sisteminin arızasına karşı korunursunuz. Girişler, işler, yeni veritabanları, bakım vb. Hepsi, aynı depolamayı paylaşan ve aynı sistem veritabanlarına sahip olan aynı düğüme sahip iki düğüme sahip bir küme olması nedeniyle otomatik olarak senkronize tutulur. Çok hızlı yerine çalışma, ancak yerine çalışma gerçekleştiğinde bir SQL Server yeniden başlatma gibi görünen bir hıçkırık var.

2. Eksileri / Endişeleri - Tek başarısızlık noktası deponuz ve tüm bileşenlerinizdir. SAN satıcıları her zaman "SAN'lar başarısız olmaz" der, ancak bir depolama alanı ağında birçok hareketli parça vardır ve burada blog yazdığım gibi yapabilirler. Ayrıca - hiçbir şey yapamayan ikincil bir sunucu için ödeme yapıyorsunuz ve beklemekten başka bir şey beklemiyorsunuz. Artık Aktif / Aktif / Çok Düğümlü işlem yapabilir ve her iki yönde yerine geçip ikinci düğümü kullanabilecek iki etkin örneğiniz olabilir.

3. Otomatik Yük Devretme? "En" otomatik. Tanığa gerek yok, bu bir küme. Bu, bir kümenin işi, mümkün olduğunca sorunsuz hale getirmektir. Şimdi bunlardan herhangi biriyle, bir yük devretme gerçekleştiğinde, bunu "hissedeceksiniz" çünkü SQL'in başlatılması veya bağlantıların işaret etmesi gerekir. Burada gerçekleştiği zaman, temel olarak SQL'i yeniden başlatmak gibi hissedeceksiniz, DB'ler geri geldi ve kurtarma / etc komutunu çalıştırın.

Bir müşterim varsa, yerel veri merkezimdeki Yüksek Kullanılabilirlik ortamındaki "Tüm veritabanlarına, tüm girişlere, vb. Tamamen bağlı olmak istiyorum" diyebilirsem, çalışma dışı kalma süresinde inanılmaz derecede düşük bir toleransa sahibim; Bahsettiğiniz son seçenek güçlü bir yarışmacı, bazı genel gider yönetimi yapmak zorunda kaldığınızdan tasarruf edin). Muhtemelen yerel bir FCI ve site arızası veya SAN arızasına karşı korunmak için ikincil bir AG async yapacağım.

işlem çoğaltması ile güncel tutulan iki (veya daha fazla) SQL Server örneği

1. Ne tür bir iş yükü? Dürüst olmak gerekirse, ilk seçenek olarak Yüksek Kullanılabilirlik veya Olağanüstü Durum Kurtarmaya ihtiyaç duyulan birçok durum için buraya gitmem. SQL 2012'de kesin değil. Ancak, temelde bu, yakın olmayan bir veri merkezine gitmek zorundaysanız, bir AG kullanamadığınızda (belki de AG için gerekli olan Windows kümesini kullanmanızı engelleyen bir etki alanı olabilir) iyi olabilir, belki de istediniz SQL Server standardında çoğaltma yapabilen ancak AG'leri yapamayacağınız halde yine de ikinci tarafta okuma ve asenkron olma yeteneğine sahip olmak istediniz.
2. Eksileri / Endişeler - Bu çoğaltma. Genel gider, senkronizasyondan kurtulabilir, kaynak tarafında performansla ilgili problemler geliştirebilir, vb.
3. Otomatik Yük Devretme - Hayır. Kendiniz yönetmeniz gerekir. Ya birini ya da diğerini işaret eden CNAME'ler aracılığıyla ve bunu yapmak için teorik olarak kendi sürecinizi yazabilirsiniz, ancak kutunun dışında? Buraya not edin.

SQL Server Kullanılabilirlik Grubu'ndaki iki (veya daha fazla) SQL Sunucusu, senkronize bir işlem modunda yapılandırılmış

Bu, insanların son zamanlarda gittikçe daha fazla uygulama yapmalarına yardımcı olduğum şeydi, yine de bazen kümelenmeye gidiyorum.

1. Ne İş Yükü? Ben senkronize tutmak için veritabanlarının yönetilebilir bir set var, bu harika ve kaynaklar ve zaman işler, oturum açma, yeni veritabanları, senkronize vb konaklama (ekibi olsa emin olmak için SQL Becerileri büyük bir eklenti inşa etmek Bir seçeneği daha güçlü hale getirmeniz için, bunların bir kısmını otomatize edin). Bunları tamamen ayrı tutmak istediğimde bunu seviyorum. Donanım sorunları, işletim sistemi sorunları, SQL kurulum sorunları, yama sorunları ve SAN / Depolama sorunlarına karşı koruma sağlıyorum. Ayrıca, okuyabileceğim, yedekleyebileceğim, yedekleyebileceğim aktif bir ikincil olma (bunun için bir işletme lisansı ödemek istersem) imkanından da faydalanıyorum. Ayrıca, gelecekte üçüncü ikincil uzak bir sitede zaman uyumsuz olan ve yerine çalışma / DR olan ikincil.
2. Eksileri / Endişeleri Lisanslama, maksimum kopya sayısı, en büyük faydadan bazılarından yararlanmak için lisanslama maliyetleri (aktif ikincil), işletme gerektirir, kümelemeden iki kat daha fazla depolama alanı gerektirir.
3. Otomatik Yük Devretme - Evet. Bu, bir tanık kurulumuyla oluşabilir ve uygulama geliştiricileriniz bir düğüm yerine dinleyiciye bağlanabilir, böylece yük devretme, dinleyicinin işaret ettiği yerde olur ve orada iyi olmalısınız. Yani evet, burada yapabilirsin - ve yapmalısın - ama elbette iyi test etmelisin.

özet

HA ve DR farklıdır. Ve bu teknolojiler de ikisinin parçaları sağlamaya yardımcı olur. Yüksek Kullanılabilirlik (benim için), bir makineye kötü bir şey gelirse hızlıca kurtarabileceğiniz anlamına gelir, kısa bir Kurtarma Noktası Amacı ve Kurtarma Süresi Amacı ile işiniz biter. Bu kümeleme ve senkronize bir AG'dir.

Olağanüstü Durum Kurtarma, "HA çözümünüzde bile bir hata olduğunda kalkabilirsiniz. Bana göre, başka bir veri merkezine gittiğinizde, aynalama ve hatta çoğaltma işlemlerinde, AG olabilir.

Neyin paylaşıldığını düşünmek de önemlidir .

Yük Devretme Kümelemesi, bir disk dizisini paylaşan iki veya daha fazla sunucu düğümü kullanır . Disk dizisi inerse, kaç tane sunucu düğümü olduğuna bakılmaksızın servisini kaybedersiniz. Bu disk dizisinin bulunduğu sunucu odası yangın çıkarıyorsa veya su bastırıyorsa, servisi kaybedersiniz.

AlwaysOn Kullanılabilirlik Grupları ve Veritabanı Aynalama, "paylaşılan hiçbir şey" kümeleme teknolojisidir. Veritabanı, birden çok sunucudaki birden çok disk dizisinde bulunur. Eğer iyi bir ağ bağlantınız varsa, çoklu servisler birden fazla sunucu odasında olabilir ve sizi yangın ve sellere karşı koruyabilir.

Sadece bütünlük için düz eski yansıtma kullanma seçeneği vardır. Buradaki avantajlar, Kullanılabilirlik Gruplarını kullanma karmaşıklığı olmadan ve Yük Devretme Kümelemesi için paylaşılan depolamaya ihtiyaç duymadan, veritabanının iki kopyasının bulunmasını içerir. Dezavantajı, hafif olmasına rağmen, yansıtma kaldırılır.

Yansıtma ile yük devretme süreleri, 10 saniyelik sıradadır, ancak uygulama kodunun yük devretme sırasında gerçekleşen işlemleri yeniden denemesi gerekir.