[Kaynak] SQL Server'da Yüksek Erişilebilirlik (1) ---- yüksek erişilebilirliğe genel bakış

SQL Server 2005'ten bu yana Microsoft, iş verilerinin korunmasını azaltmak ve kesinti süresini artırmak için çeşitli yüksek erişilebilirlik teknolojileri sağlamıştır ve SQL Server 2008, SQL Server 2008 R2 ve SQL Server 2012'nin sürekli sürümüyle SQL Server'da farklı senaryolara uygun birçok yüksek erişilebilirlik teknolojisi bulunmaktadır.

    Bu makaleye başlamadan önce, hangi yüksek erişilebilirlikli teknolojinin kullanılacağına dair kısa bir özetle başlayacağım.

    Birçok şirket, çevrimiçi alışveriş siteleri gibi verilerinin tamamının veya bir kısmının yüksek erişilebilir olması gerekir; örneğin çevrimiçi ürün veritabanları 7/24 çevrimiçi olmalı, aksi takdirde çok rekabetçi bir piyasa ortamında kesinti süresi müşteri kaybı ve gelir kaybı anlamına gelir. Örneğin, SQL Server'a güvenen bir çağrı merkezinde, veritabanı çökerse, tüm arayanlar sadece müşteriye "Üzgünüm, sistem arızası" diye yanıt verebilir ki bu da kabul edilemez.

    Elbette, ideal bir dünyada tüm kritik veriler her zaman çevrimiçi olur, ancak gerçek dünyada veritabanının erişilebilir olmaması için çeşitli nedenler olacaktır; çünkü felaketin zamanını ve şeklini tahmin etmek imkansızdır, çeşitli acil durumları önlemek için önceden önlemler almak gerekir, bu yüzden SQL Server çeşitli yüksek kullanılabilirlik teknolojileri sunar; bu teknolojiler başlıca: kümeleme, çoğaltma, aynalama, günlük teslimatı, AlwaysOn erişilebilirlik grupları ve dosya grubu yedekleme ve geri yükleme gibi diğer teknolojiler içerir. Çevrimiçi yeniden yapılandırma indeksleri gibi tek bir yüksek erişilebilirlik teknolojileri. Yüksek erişilebilirlik teknolojisinin kullanımı, doğrudan kullanım için tanıdık bir teknolojiyi seçmek değil, iş ve teknolojiyi kapsamlı bir şekilde değerlendirmektir. Çünkü tüm işlevleri başarabilecek tek bir teknoloji yoktur. Bu teknolojileri kendi işinize ve bütçenize göre nasıl benimseyeceğiniz, yüksek erişilebilirlik stratejisi olarak bilinir.

Yüksek erişilebilirlik stratejisi tasarlarken öncelikle aşağıdaki faktörleri göz önünde bulundurmalısınız:

• RTO (Recovery Time Objective) - yani iyileşme süresi hedefi, genellikle birkaç 9 ile ifade edilen izin verilen kesinti süresi anlamına gelir; örneğin, %99,999 erişilebilirlik yılda 5 dakikadan fazla kesinti demek, %99,99 erişilebilirlik yılda 52,5 dakikadan fazla kesinti demek, %99,99 erişilebilirlik ise yılda 8,75 saatten fazla kesinti anlamına gelir. RTO'nun hesaplama yönteminin sistemin 24*365 mi yoksa sadece 6:00-21:00 gibi olup olmadığını da dikkate aldığını belirtmekte fayda var. Ayrıca, bakım penceresinin kesinti olarak sayılıp sayılmadığına dikkat etmeniz gerekir ve bakım penceresinde veritabanı bakımı ve yamalama izin verilirse daha yüksek kullanılabilirlik elde etmek daha kolaydır.
• RPO (Recovery Point Objective) – Kurtarma noktası hedefi olarak da bilinir, ne kadar veri kaybına izin verildiği anlamına gelir. Genellikle, iyi bir yedekleme yaptığınız sürece kolayca sıfır veri kaybı elde edebilirsiniz. Ancak bir felaket olduğunda, veritabanı bozulmasının boyutuna bağlı olarak, yedekten veri geri yükleme süresi veritabanının erişilmez hale gelmesine ve bu da RTO'nun uygulanmasını etkiler. Daha erken ve daha ünlü bir örnek, Avrupa ve Amerika Birleşik Devletleri'ndeki bir bankacılık sistemidir; sadece RPO göz önüne alındığında, sistemde sadece tam yedeklemeler ve günlük yedeklemeler vardır, her 3 ayda bir tam yedekler, her 15 dakikada bir bir günlük yedeklemeleri vardır; bir felaket olduğunda sadece tam yedeklemeler ve günlük yedeklemeleri verileri geri getirebilir, yani veri kaybı olmasa da veri geri yüklemesi iki tam gün sürdüğü için bankacılık sistemi 2 gün kullanılamaz hale geldi ve çok sayıda müşteri kaybedildi. Bir diğer zıt örnek, SQL Server'ı arka uç ilişkisel veritabanı olarak kullanan, ön yüz No-SQL kullanan ve düzenli olarak No-SQL verilerini yedek olarak ilişkisel veritabanına aktaran yerel çevrimiçi video sitesidir.
  

    Bütçe – RTO ve RPO topluca SLA'lar (Hizmet Seviyesi Anlaşmaları) olarak bilinir ve yüksek erişilebilirlik stratejisi tasarlarken, işinize göre SLA'ları ne kadar iyi karşıladığınızı ölçmeniz gerekir; bütçenize bağlı olarak ve bir arıza durumunda farklı SLA'ların maliyetini ölçmeniz gerekir. Genel olarak, sınırlı bütçeyle yüksek SLA'lara ulaşmak zordur ve karmaşık mimarilerle yüksek SLA'lar elde edilse bile, karmaşık mimariler aynı zamanda yüksek işletme ve bakım maliyetleri anlamına gelir, bu nedenle SLA'ları karşılamak için bütçe içinde doğru teknolojiyi seçmek gereklidir.

Bu nedenle, genel olarak, yüksek erişilebilirlik için büyük çerçeve birkaç sipariş alma sorusu ile belirlenebilir:

• Hissedarlar ne kadar kesinti süresini kabul etmeye razı olur?
• Yöneticiler için hangi boş zaman kabul edilebilir?
• Yüksek erişilebilirlik senaryosu için sağlanan bütçe nedir?
• Kesinti nedeniyle saatlik kayıp ne kadar?
  

• Soğuk yedekleme: Bekleme sunucusu, birincil sunucunun verilerini kabul edecek şekilde yapılandırılır ve başarısız olduğunda, verileri manuel olarak birincil veritabanına geri getirir veya yedek veritabanını çevrimiçi hale getirmek için bağlantı dizisi veya programın izinlerini yeniden yapılandırır.
• Sıcak yedekleme: Birincil sunucu verisi, kayıtları sürekli olarak yedek sunucuya iletir (düzensiz aralıklarla, 15 dakika, 30 dakika, 1 dakika vb. olabilir), böylece birincil sunucudan yedek sunucuya genellikle asenkron olarak güncellenir, böylece birincil sunucu ile yedek sunucunun verileri garanti edilemez. Ayrıca, bu şema genellikle otomatik hata izleme ve yedekleme uygulamaz.
• Sıcak yedekleme: Birincil sunucunun verileri yedek sunucuda otomatik olarak senkronize edilir ve çoğu durumda otomatik hata izleme ve devretme dahil edilir; ana sunucu ile yedek sunucunun veri tutarlılığı garanti edilebilir.
  

    Soğuktan sıcaktan sıcak yedeklere kadar maliyetler fırlıyor.

    SQL Server'da desteklenen yüksek erişilebilirlik özellikleri sürümle yakından ilişkilidir ve Enterprise sürümü tüm yüksek erişilebilirlik özelliklerini destekler, bunlar arasında:

• Failover kümesi
• l Veritabanı görüntüsü
• l İşlem günlüğü iletimi
• l Veritabanı anlık görüntüleri
• l Yüksek kullanılabilirlik yükseltmeleri
• l Sıcak yükleme belleği
• l Çevrimiçi indeksleme işlemleri
• l Veritabanı kısmi çevrimiçi (sadece ana dosya grubu veya ana dosya grubu ve ek NDF dosyaları geri yüklenir)
  

    Yüksek erişilebilirlik özelliği olan belirli sürümler için bkz:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxÜcretsiz Express sürümünün veritabanı yansıtma için bir tanık sunucusu olarak hizmet verebileceği ve maliyet tasarrufu sağladığı belirtilmelidir.

Failover kümesi

    Failover kümeleri, tüm SQL Server örneği için yüksek erişilebilirlik desteği sağlar; bu da kümedeki bir düğümdeki SQL Server örneğinin, donanım hataları, işletim sistemi hataları vb. nedeniyle kümedeki diğer düğümlere geçiş yapması anlamına gelir. Yüksek kullanılabilirlik, birden fazla sunucu (düğüm) bir veya daha fazla diski paylaşarak sağlanır ve failover kümeleri ağda tek bir bilgisayar gibi görünür, ancak yüksek erişilebilirlik özelliklerine sahiptir. Başarısızlık kümeleri paylaşılan disklere dayandığı için tek bir disk arıza noktası olduğundan, SAN çoğaltımı gibi ek korumaların disk seviyesinde dağıtılması gerektiğini belirtmek önemlidir. En yaygın devre kümesi, ana ve slave dahil olmak üzere iki düğümlü bir failover kümesidir.

İşlem günlüğü iletimi

    İşlem günlüğü gönderimi, veritabanı düzeyinde yüksek erişilebilirlik koruması sağlar. Log, ilgili üretim veritabanının ("birincil veritabanı" olarak adlandırılır) bir veya daha fazla bekleme veritabanını ("ikincil veritabanları" olarak adlandırılır) tutmak için kullanılır. Bir failover gerçekleşmeden önce, ikincil veritabanı tüm geri yüklenmemiş günlük yedeklemeleri manuel olarak uygulanarak tamamen güncellenmelidir. Log teslimatı, birden fazla beklemede bulunan veritabanını destekleme esnekliğine sahiptir. Birden fazla alternatif veritabanı gerekiyorsa, log teslimatı ayrı ayrı veya veritabanı yansıtmalarına tamamlayıcı olarak kullanılabilir. Bu çözümler birlikte kullanıldığında, mevcut veritabanı yansıtma yapılandırmasının ana veritabanı aynı zamanda mevcut log gönderim yapılandırmasının birincil veritabanıdır.

    İşlem günlüğü teslimatı, soğuk ve sıcak yedeklemeler için kullanılabilir.

Veritabanı yansıtma

    Veritabanı yansıtma aslında veritabanı düzeyinde koruma sağlayan ve veritabanı kullanılabilirliğini artırmak için neredeyse anında yedekleme sağlayan bir yazılım çözümüdür. Veritabanı aynası, ilgili üretim veritabanı için tek bir bekleme veritabanını (veya "ayna veritabanı") tutmak için kullanılabilir ("ana veritabanı").
Ayna veritabanı her zaman geri yükleme durumunda olduğu için ancak veritabanı geri yüklenmediği için, ayna veritabanına doğrudan erişilemez. Ancak, raporlar gibi sadece okunabilir yüklemeler için, yansıtılmış veritabanını dolaylı olarak kullanarak yansıtılmış veritabanının anlık görüntüsü oluşturabilirsiniz. Veritabanı anlık görüntüleri, anlık görüntü oluşturulduğunda istemcilere veritabanındaki verilere yalnızca okunma erişimi sağlar. Her veritabanı aynalama yapılandırması, ana veritabanını içeren bir "ana sunucu" içerir ve ayrıca aynalı veritabanını içeren bir ayna sunucusunu içerir. Ayna sunucusu, ana veritabanı ile ayna veritabanını sürekli günceller.
    Veritabanı yansıtma, yüksek güvenlik modunda senkron operasyonda veya yüksek performans modunda asenkron işlemde çalışır. Yüksek performans modunda, işlemler ayna sunucunun logları diske yazmasını beklemek zorunda kalmaz, bu da performansı en üst düzeye çıkarır. Yüksek güvenlik modunda, taahhüt edilen işlemler her iki ortak tarafından da yapılır, ancak işlem gecikmesi uzadır. Veritabanı yansıtmanın en basit yapılandırması yalnızca ana sunucu ve ayna sunucusunu içerir. Bu yapılandırmada, ana sunucu kaybolursa, ayna sunucusu bekleme sunucusu olarak kullanılabilir, ancak veri kaybına yol açabilir. Yüksek güvenlik modu, otomatik yedekleme ile yüksek güvenlik modunu destekliyor. Bu yapılandırma, aynalı sunucunun sıcak yedek sunucusu olarak kullanılmasını sağlayan "tanık sunucu" adı verilen üçüncü taraf bir sunucu örneği içerir. Birincil veritabanından aynaya geçiş genellikle birkaç saniye sürer.

    Veritabanı yansıtma hem sıcak hem de sıcak yedeklemeler için kullanılabilir.

kopya etmek

    Çoğaltma kesinlikle yüksek erişilebilirlik için tasarlanmış bir özellik değildir, ancak yüksek kullanılabilirliğe uygulanabilir. Çoğaltma, veritabanı nesne düzeyinde koruma sağlar. Çoğaltma, verilerin ana sunucu olan yayıncı tarafından bir veya daha fazla ikincil veya aboneye yayınlandığı yayın-abone modeli kullanılır. Çoğaltma, bu sunucular arasında gerçek zamanlı erişilebilirlik ve ölçeklenebilirlik sağlar. Abonelere bir alt veri kümesi sağlamak için filtreleme desteğini desteklerken, ayrıca bölüm güncellemelerini de destekler. Abone çevrimiçi olup sorgu kurtarma olmadan raporlama veya diğer işlevler için müavittir. SQL Server dört örnekleme türü sunar: anlık fotoğraf çoğaltma, işlem tabanlı çoğaltma, eşler arası çoğaltma ve birleştirme çoğaltma.

AlwaysOnKullanılabilirlik grubu

    AlwaysOn Erişilebilirlik Grupları, SQL Server 2012'de tanıtılan yeni bir özelliktir. Veritabanı düzeyinde koruma da sağlanmaktadır. Ayrıca, veritabanı yansıtmasının yalnızca 1:1 olabileceği sınırını genişletir; böylece bir birincil replika en fazla 4 ikincil replikaya karşılık gelebilir (SQL Server 2014'te bu limit 8'e genişletilmiştir), bunlardan 2 ikincil replika sıcak yedekleme ve birincil replikalar olarak gerçek zamanlı olarak senkronize edilebilir, diğer iki asenkron ikincil replika ise sıcak yedekleme olarak kullanılabilir. Ayrıca, ikincil replikalar yalnızca okunabilir olarak yapılandırılabilir ve yedekleme yükünü üstlenmek için kullanılabilir.

    Bu nedenle, veritabanı aynalama SQL Server 2012'de "modsolete" olarak işaretlenmiştir.

    Yüksek erişilebilirlik ve SQL Server'da sunulan yüksek kullanılabilirlik teknolojileri kavramlarını anladıktan sonra, yüksek erişilebilirlik stratejisinin tasarımına bakalım. Yüksek erişilebilirlik stratejisi planlaması dört aşamaya ayrılabilir:

Toplama gereksinimleri

    Yüksek erişilebilirlik stratejisine karar vermenin ilk adımı, kesinlikle SLA'lar oluşturmak için iş gereksinimlerini toplamaktır. RTO ve RPO en kritik parçalardır ve bu temelde erişilebilirlik gereksinimleri için gerçekçi beklentiler oluşturulur ve bu beklentilere dayalı gerçekçi yüksek erişilebilirlik stratejisi oluşturulur.

Değerlendirme Sınırları

    Değerlendirme sınırları yalnızca SQL Server'daki farklı yüksek erişilebilirlik teknolojilerinin sınırlamalarıyla sınırlı değildir, aynı zamanda teknik olmayanlarla da sınırlıdır. Sadece on binlerce yuan bütçeniz varsa ama saha dışı veri merkezleri ve SAN replikasyonuna dayalı yüksek erişilebilirlikli bir çözüm yapmak istiyorsanız, bu kesinlikle bir hayal. Teknik olmayan bir diğer kısıtlama ise operasyon personelinin seviyesidir ve çoğu zaman karmaşık mimariler daha yetenekli operasyon personeli anlamına gelir. Diğer teknik olmayan sınırlamalar arasında veri merkezinde disk alanının bulunabilirliği, güç kaynağı ve klimanın ihtiyaçları karşılayıp karşılayamayacağı ve kullanılabilirlik stratejisinin uygulanması için gereken süre yer alır.

    Teknik sınırlamalar arasında farklı yüksek erişilebilirlik fonksiyonları ve sınırlamaları, farklı SQL Server sürümleri tarafından desteklenen fonksiyonlar, CPU sayısı ve bellek boyutu yer alır. Yüksek erişilebilirlik politikası uygulamadan önce Microsoft MSDN web sitesindeki farklı SQL Server sürümleri ve özelliklerinin sınırlamalarına bakmanız şiddetle tavsiye edilir.

Seçilmiş teknoloji

    Gereksinimleri topladıktan ve kısıtlamaları değerlendirdikten sonra, bir sonraki adım, SLA gereksinimlerini karşılamak için bu makalede daha önce açıklanan teknolojileri veya teknolojilerin kombinasyonunu seçmektir. Seçilen teknoloji SLA'yı karşılamazsa, hangi sınırlamaların SLA'ya uymadığını bildirmek kolaydır ve böylece eksik kaynakları talep edebilir veya SLA'dan uzlaşma yapabilirsiniz.

Test edin, doğrulayın ve belgeleyin

    Yüksek erişilebilirlik politikaları, mevcut erişilebilirlik politikalarının SLA'lara uyduğundan emin olmak için baştan itibaren titizlikle test edilmeli ve doğrulanmalıdır. Ancak, yüksek erişilebilirlik stratejisi başlatıldığında, mevcut politikanın veri artışı, iş veya gereksinim değişikliklerine rağmen SLA'ları karşılayabileceğinden emin olmak için düzenli olarak test etmek ve doğrulamak da gereklidir. Aynı zamanda, kullanılabilirlik çözümünün yapılandırması, devretme yöntemi ve felaket kurtarma planı aynı anda belgelenmeli ki yüksek erişilebilirlik stratejisinin arızalanması veya gelecekteki ayarlanması durumunda izlenebilir.

Bu makale, yüksek erişilebilirliğin temel kavramlarını, SLA kavramını, SQL Server'da desteklenen farklı türde yüksek kullanılabilirlik özelliklerini ve yüksek kullanılabilirlik stratejisi tasarlamak için gereken adımları açıklar. Bu makale sadece veritabanı düzeyinde yüksek erişilebilirlikten bahsetse de, yüksek erişilebilirlik sadece DBA için değil, aynı zamanda sistem işletme ve bakım personeli, ağ yöneticileri, geliştiriciler ve yöneticiler gibi farklı rollerin iş birliğini de içeriyor; böylece SLA'lara daha iyi uyum sağlanır.