AWS’te SQL Server için Felaket Kurtarma Mimarisi Oluşturun: 2. Bölüm

Orijinal makale: Link (Ganapathi Varma Chekuri, Database Specialist Solutions Architect ve Baris Furtinalar, Senior Solutions Architect)

Bu gönderi dizisinde (Bölüm 1, Bölüm 2, Bölüm 3 ve Bölüm 4), Amazon Elastic Compute Cloud (Amazon EC2) üzerinde Microsoft SQL Server için mevcut olan felaket kurtarma (DR) çözümlerini kıyaslıyor ve karşılaştırıyoruz. Bu gönderi, AWS’te SQL Server için DR uygulamak için üç yöntem sunuyor: SQL Server yedekleme ve geri yükleme, SQL Server günlük (log) gönderimi ve SQL Server veritabanı yansıtma.

SQL Server Yedekleme ve Geri Yükleme

Bir tür yüksek kullanılabilirlik (High Availability – HA) ve DR teknolojisine sahip olsanız bile, verilerin yanlışlıkla silinmesi veya veri bozulması gibi bu teknolojinin başarısız olması durumunda yine de yedek almanız gerekir. Yedeklemeler, herhangi bir DR stratejisinin temelidir. Yedekleme stratejisi, SQL Server veritabanının kurtarma modeline bağlıdır. Kurtarma modeli, işlemlerin nasıl günlüğe kaydedildiğini, işlem günlüğünün yedekleme gerektirip gerektirmediğini (ve buna izin verip vermediğini) ve ne tür geri yükleme işlemlerinin mevcut olduğunu denetleyen bir veritabanı özelliğidir.

Veritabanının kurtarma modeline bağlı olarak, SQL Server içinde üç tür yedekleme alabilirsiniz:

• Tam yedekleme (Full backup) – Tüm veritabanını, tüm veri dosyalarından tüm uzantıları yedekler ve bir geri yükleme işleminden sonra veritabanını kurtarmak için gereken işlem günlüklerini yedekler. Bu yedekleme, tüm kurtarma modellerinde desteklenir.
• Diferansiyel yedekleme (Differential backup) – Son tam yedeklemeden bu yana değiştirilen uzantıları yedekler. Tam yedeklemeler gibi bu yöntem de tüm kurtarma modellerinde desteklenir.
• Günlük yedekleme (Log backup) – İşlem günlüğünün etkin bölümünü yedekler. İşlem günlüğü yedeklemeleri, özellikle OLTP’yi (çevrimiçi işlem işleme) destekleyen veritabanlarında önemlidir, çünkü bunlar felaket meydana gelmeden hemen önceki noktaya bir noktada kurtarmaya (Point-in-time Recovery – PITR) izin verirler.

RTO ve RPO

SQL sunucusu için DR seçiminiz için yedekleme kullanıyorsanız, kurtarma işleminin maksimum süresi ve dolayısıyla kapalı kalma süresi Kurtarma Süresi Hedefi’dir (Recovery Time Objective – RTO). RTO, yedekleme dosyalarının ağ üzerinden aktarılması için ne kadar zaman gerektiğini ve yedek dosyalarının boyutunu ve sayısını belirleyen ağ verimi gibi birden çok faktöre bağlıdır. Birden çok diferansiyel ve günlük yedeğine sahip bir veritabanı için kurtarma senaryosunda, kurtarmanın ilk adımı olarak son tam yedeği, en son diferansiyel yedeği ve daha sonra alınan tüm günlük yedeklerini geri yüklemelisiniz. Genel olarak konuşursak, Kurtarma Noktası Hedefiniz (Recovery Point Objective – RPO), günlük yedekleme aralıklarını belirler. DR için yedekleme stratejilerinizi tasarlarken günlük yedekleme süresini de dikkate almalısınız.

En İyi Uygulamalar

Yedeklemeler için depolama alanı olarak Amazon Simple Storage Service’ı (Amazon S3) kullanmayı düşünebilirsiniz. Amazon S3, son derece dayanıklı nesne depolaması sağlar ve Bölgeler (Regions) içinde ve genelinde yerleşik çoğaltma özelliklerini destekler. Amazon S3, katmanlı depolama seçeneğiyle yedeklemeler gibi seyrek erişilen veriler için uygun maliyetli depolama sağlar. Ayrıca Amazon S3 için bir ağ geçidi VPC uç noktası kurmanızı öneririz. VPC uç noktası, VPC’niz ile desteklenen AWS hizmetleri ve AWS PrivateLink tarafından desteklenen VPC uç nokta hizmetleri arasında özel bağlantılar sağlar.

SQL sunucusu için başka bir yedekleme depolama seçeneği, Windows Dosya Sunucusu için Amazon FSx‘tir. Windows Dosya Sunucusu için FSx, tamamen yerel bir Windows dosya sistemi tarafından desteklenen, tam olarak yönetilen Microsoft Windows dosya sunucuları sağlar. Bir donanım veya işletim sistemi hatası durumunda, verileriniz erişilemeyen SQL Server’daki yerel bir sürücüdeyse, geri yüklemenin gerçekleştirilmesi çok daha uzun sürer. Bunun yerine, yedekler bir ağ paylaşımındaysa, bu yedekleri hemen başka bir sunucuya geri yüklemeye başlayabilirsiniz.

AWS’i bir DR sitesi olarak kullanıyorsanız, yedek dosyaları AWS’teki bir S3 klasörüne iletmek için veri merkezinizde yedek depolamanız olarak AWS Storage Gateway kullanmayı düşünebilirsiniz.

Çözüme Genel Bakış

Aşağıdaki şema, bir yedekleme ve geri yükleme çözümünün mimarisini göstermektedir.

Figür: Yedekleme ve Geri Yükleme

Bu senaryoda, SQL Server veritabanınızı bir EC2 bulut sunucusunda yapılandırır ve tam, diferansiyel ve işlem günlüğü yedeklerini şirket içi veritabanınız ile AWS Cloud’daki SQL Server arasında aktarırsınız. Yedekleme ve geri yükleme sürecini hızlandırmak için Storage Gateway kullanmayı düşünebilirsiniz. Storage Gateway, ağınızda dağıttığınız bir hibrit depolama cihazıdır. Storage Gateway, ağınızda SQL Server yedeklemeleri için hedef olarak kullanabileceğiniz bir dosya paylaşımı sunar. Yedekleme işlemlerini hızlandırmak için Storage Gateway, yapılandırılabilir bir yerel önbellek içerir. En iyi uygulama, bu önbelleği tüm yedeği depolayacak kadar büyük ayarlamaktır. Önbelleğe alınmış yedeklemeler, VPN veya Direct Connect üzerinden AWS’teki bir S3 demetine (bucket) sorunsuz bir şekilde yüklenir.

Bu demetten, tam, diferansiyel veya işlem günlüğü yedekleri bir dosya sistemine indirilebilir ve ardından EC2 üzerindeki SQL Server’a geri yüklenebilir. Bu nedenle, AWS’e geçiş yapmaya hazır olana kadar şirket içi ve bulut veritabanlarınızı senkronize halde tutabilirsiniz.

Yük Devretme (Failover) ve Yeniden Çalışma (Failback)

Felaket durumunda, geri yükleme işlemini (RTO) başarıyla tamamladıktan sonra SQL veritabanınızın yükünü devredebilirsiniz. Bu manuel bir işlemdir. Bunu olası felaket kurtarma stratejilerinden biri olarak kullanabilirsiniz.
Yedeklemeler, otomatik olarak yeniden çalışma sağlamaz. Veritabanlarını tutarlı duruma getirmek için veritabanı yedeklerini manuel olarak geri yüklemeniz gerekir.

Avantajlar

Yedekleme ve geri yükleme çözümü aşağıdaki avantajlara sahiptir:

• DR teknolojisini uygulamak basit ve kolaydır
• Tüm yedekleme türleri, tüm SQL Server sürümlerinde desteklenir
• Yedekleme dosyaları AWS Bölgeleri arasında kopyalanabilir

Göreceli Maliyet

SQL Server yedeklemeleriniz için AWS Storage Gateway ile yedekleme işlemlerinizi basitleştirebilir ve yedekleme dosyalarınızı Amazon S3’ye taşıyarak depolama maliyetlerinizi azaltabilirsiniz. Tam, diferansiyel ve işlem günlüğü yedeklemeleri, tüm SQL Server sürümlerinde desteklenir.

SQL Server Günlük Gönderimi

Günlük gönderimi, felaket kurtarmayı uygulamak için kullanabileceğiniz bir teknolojidir. Birincil, şirket içi SQL Server veritabanınızdan EC2 bulut sunucularında veya AWS Cloud’daki SQL Server DB sunucuları için Amazon RDS‘te dağıtılan bir veya daha fazla ikincil (sıcak bekleme) SQL Server veritabanına işlem günlüğü yedeklemeleri göndermek için günlük gönderimini kullanabilirsiniz. Her bir veritabanı için günlük gönderimini ayarlamanız gerekir. Amazon RDS for SQL Server’da günlük gönderimini ayarlamak için kendi özel komut dosyalarınızı kullanmanız gerekir.

RPO ve RTO

İşlem günlüğü gönderimi genellikle bir felaket kurtarma çözümü olarak kullanılır, ancak birincil veritabanı ile ikincil veritabanı arasındaki durum farkı çok daha büyük olduğundan, esnek RTO ve RPO gereksinimleriniz olduğunda yüksek kullanılabilirlikli bir çözüm olarak da kullanılabilir. İşlem günlüğü dosyaları eşzamansız olarak gönderildiğinden ve bütünüyle ikincil bir veritabanına uygulanmaları gerektiğinden, çoğaltma gecikmesi daha büyüktür. Günlük gönderimi, dakikalar arasında bir RPO ve dakikalar ila saatler arasında bir RTO sağlar. Günlük gönderimi, yansıtma veya Her Zaman Açık (Always On) kullanılabilirlik gruplarıyla mümkün olmadığından, yükleme gecikmesine ihtiyaç duyduğunuz DR senaryolarında daha uygundur.

En İyi Uygulamalar

Aşağıdaki en iyi uygulamaları aklınızda bulundurun:

• Veritabanı kurtarma modelini asla basit veya toplu olarak günlüğe kaydetmeye ve tam kurtarmaya döndürmeye değiştirmeyin. Bunu yapmak, günlük gönderiminin çalışmasını durdurmak için işlem günlüğü zincirini bozar.
• Günlük gönderimi için kullanılanlardan başka hiçbir işlem günlüğü yedeği alamazsınız. Bunu yapmak, günlük gönderim zincirini kırar.
• Geri yüklemeyi sık sık kuruyorsanız (örneğin, her 15 dakikada bir), geri yüklemeden önce mevcut tüm bağlantıların her 15 dakikada bir durdurulması gerekir. İkincil veritabanından okumak istediğinizde, ancak bir geri yükleme işlemi sırasında okunabilirliğe ihtiyacınız olmadığında günlük sevkiyatını seçin.

Çözüme Genel Bakış

Aşağıdaki şema, hibrit bir günlük gönderim çözümünün mimarisini göstermektedir.

Figür: Günlük Gönderimi

Bu senaryoda, bir EC2 sunucusunda sıcak yedek SQL Server veritabanı yapılandırır ve şirket içi veritabanınız ile AWS Cloud’daki sıcak bekleme sunucusu arasında eşzamansız olarak işlem günlüğü yedekleri gönderirsiniz. İşlem günlüğü yedekleri daha sonra sıcak bekleme veritabanına uygulanır. Tüm günlükler uygulandığında, manuel olarak yük devretme gerçekleştirebilir ve buluta geçiş yapabilirsiniz.

AWS’te çalışan bir birincil veritabanı için Bölge içi DR’ı yapılandırmak istiyorsanız, birincil ve ikincil veritabanı bulut sunucularını ayrı Erişilebilirlik Alanlarında çalıştırmanızı öneririz ve isteğe bağlı olarak, günlük gönderiminin tüm ayrıntılarını izlemek için bir izleme bulut sunucusu yapılandırabilirsiniz. Ayrıca, AWS’te çok Bölgeli DR’ı yapılandırmak istiyorsanız, iki farklı Bölgede çalışan bulut sunucuları arasında günlük gönderimi ayarlayabilirsiniz.

Yük Devretme (Failover) ve Yeniden Çalışma (Failback)

Günlük gönderim yapılandırması, birincil sunucudan ikincil sunucuya otomatik yük devretme sağlamaz. Birincil veritabanı kullanılamaz hale gelirse, ikincil veritabanlarından herhangi biri manuel olarak çevrimiçi hale getirilebilir. Yük devretme, ikincil sunucuda manuel olarak başlatılmalıdır. Bir miktar idari çaba gerektirir. Yük devretmeyi koordine eden bir izleme aracısı yoktur. Veritabanlarını ikincil sunucuda ne zaman çevrimiçi hale getireceğinize esasen siz karar verirsiniz.

Yük devretme işleminden sonra üretim veritabanlarınız artık DR veritabanlarıyla senkronize olmaz. Veritabanlarınızı geri yükleyemezsiniz, bu nedenle günlük gönderiminin yeniden yapılandırılması gerekir. DR veritabanlarından tam ve günlük yedekleme almanız ve bunları üretim veritabanlarınıza geri yüklemeniz gerekir.

Avantajlar

Günlük gönderimi aşağıdaki avantajlara sahiptir:

• Kurulumu ve yönetimi kolaydır
• Nispeten ucuz bir çözümdür
• Gecikmeli kurtarma – Zamanda önceki bir noktadan kurtarma yeteneği
• Active Directory ve Windows Server yük devretme kümelemesi gerektirmez
• Birden çok ikincil yapılandırılabilir
• Bekleme veritabanları salt okunur sorgular için kullanılabilir
• Diğer HA ve DR teknolojileri ile birleştirilebilir
• Express sürümü hariç tüm SQL sürümlerinde desteklenir

Göreceli Maliyet

Günlük gönderimi, SQL Server Web sürümü ve sonraki sürümleri gerektirir. Kurulum ve çalıştırma nispeten basittir ancak idari ek yük gerektirir. Ek olarak, bir felaketten sonra uç nokta değişikliği operasyonların karmaşıklığını artırır. Yeniden çalışma, günlük gönderiminin sıfırdan ters yönde yeniden yapılandırılmasını gerektirir.

SQL Server Veritabanı Yansıtma

Veritabanı yansıtma, birincil sunuculardan ikincil sunuculara bir günlük kaydı akışı göndererek çalışır. Veritabanı yansıtmada bu sunuculara ana sunucu ve yansıtma adı verilir. Tüm veri değişiklikleri birincil sunucuda yapılmalıdır. Veritabanı yansıtma ile, yansıtma sunucusundaki veritabanı geri yükleme modundadır ve istemciler tarafından erişilemez. Veritabanı yansıtma, SQL Server’ın en son sürümünde kullanımdan kaldırılmıştır.

Teknoloji, senkron ve asenkron taahhütler olarak da adlandırılan eşzamanlı veya eşzamansız modlarda çalışabilir. Eşzamanlı veritabanı yansıtma iki farklı modda mevcuttur: yüksek koruma ve yüksek kullanılabilirlik. Bu iki mod arasındaki tek fark, otomatik yük devretme desteğidir. SQL Server, yüksek kullanılabilirlik modunda otomatik yük devretmeyi destekler; bununla birlikte, konfigürasyonda yeterli çoğunluğu desteklemeye yardımcı olan tanık olarak adlandırılan üçüncü bir SQL Server sunucusuna sahip olmanızı gerektirir.

SQL Server veritabanlarınız için bir hibrit bulut ortamı kurmak için veritabanı yansıtmayı kullanabilirsiniz. Bu seçenek, SQL Server Enterprise sürümünü gerektirir. Bu senaryoda, ana SQL Server veritabanınız şirket içinde çalışır ve bulutta sıcak bir bekleme oluşturursunuz. Verilerinizi eşzamansız olarak çoğaltır ve kesmeye hazır olduğunuzda manuel yük devretme gerçekleştirirsiniz. Veritabanını AWS Cloud’a taşıdıktan sonra, yüksek kullanılabilirlik ve dayanıklılık amaçları için Her Zaman Açık (Always On) kullanılabilirlik grubu kullanarak ikincil bir çoğaltma ekleyebilirsiniz.

RPO ve RTO

Çoğaltma eşzamansızdır. RPO, asıl ve yansıtma veritabanı arasındaki gecikmeye ve ağ bant genişliğine bağlıdır.
Asıl veya yansıtma sunucular ağır bir yük altındaysa gecikme büyük olabilir. RTO, yansıtma sunucusunu sıcak bekleme sunucusu olarak kullanan hizmeti zorlamak için geçen süreye bağlıdır. Veritabanı yansıtma, dakika cinsinden bir RPO ve RTO sağlar.

En İyi Uygulamalar

Veritabanı yansıtma ile, veri değişikliklerinin hem ana hem de ikincil düğümler tarafından onaylanması gerektiğinden, yazma ağırlıklı iş yüklerinin çalıştırılması bir performans etkisi görebilir. Ayrıca, yansıtma, yazma ağırlıklı iş yükleri için ikincil üzerinde daha yüksek bir G/Ç yüküne veya dizin yeniden oluşturma gibi yüklerin patlamasına neden olabilir. Bu nedenle, depolama performansını buna göre planlamanız gerekir.

Veritabanı yansıtmaya dahil olan sunucular arasında özel bir ağınız olmalıdır. Sunucular diğer sunucularla ortak bir ağı paylaşıyorsa, iletişimi yansıtmak için kullanılabilen etkin bant genişliği performansı etkiler. Yüksek bant genişliğine sahip bir ağda veritabanı yansıtmayı yapılandırmanızı önemle tavsiye ederiz. Ağ bant genişliği, uygulamanızın günlük oluşturma hızı tarafından belirlenir. Daha düşük bant genişliği ağları, veritabanı yansıtma performansını olumsuz etkileyebilir.

Bir sunucuda birden çok veritabanınız varsa, her bir veritabanını ayrı ayrı yansıtmanız gerekir. Her veritabanı için farklı bir yansıtma sunucusu seçmek mümkün olsa da, tek bir uygulamaya ait tüm veritabanları için bir yansıtma sunucusu seçmek en iyi uygulamadır. Bir sunucudaki veritabanları farklı uygulamalara aitse, onlar için farklı yansıtma sunucuları seçebilirsiniz, ancak bunu yapmak yapılandırmaya karmaşıklık getirir.

Çözüme Genel Bakış

Aşağıdaki diyagram, hibrit veritabanı yansıtma mimarisini gösterir.

Figür: Veritabanı Yansıtma

Bu senaryoda, bir EC2 sunucusundaki SQL Server veritabanınız ile şirket içi veritabanınız arasında eşzamansız veritabanı yansıtmayı yapılandırırsınız. Asıl veritabanı, bir işlemin günlüğünü eşzamansız olarak AWS Cloud’daki bir yansıtma veritabanına gönderir. Asıl sunucu, yansıtma sunucusundan bir onay beklemeden istemciye bir onay gönderir. İşlemler, yansıtma sunucusunun günlüğü diske yazmasını beklemeden gerçekleşir.

Yük Devretme (Failover) ve Yeniden Çalışma (Failback)

Bir tanıkla eşzamanlı yansıtma kullanıyorsanız, otomatik yük devretme gerçekleşir ve böylece veritabanı kesinti süresi en aza indirilir. Yansıtma ana veritabanı olur ve eski asıl veritabanı yansıtma rolünü üstlenir.

Tanık olmadan eşzamanlı yansıtma kullanıyorsanız, bu seçenek otomatik yük devretme sağlamaz. Yük devretmeyi manuel olarak çalıştırmamız ve yansıtma veritabanını yeni asıl veritabanı haline getirmemiz gerekir.

Eşzamansız yansıtma kullanıyorsanız, bu seçenek otomatik yük devretme sağlamaz. Asıl veritabanının arıza anında yansıtmaya yansımayan işlemleri varsa bu işlemler kaybedilir. Veri kaybı olasılığını kabul ederek yük devretme işlemini manuel olarak çalıştırmamız gerekir.

Birincil taraftaki veritabanı çalışır duruma geldiğinde otomatik olarak yansıtma rolünü üstlenir. Ancak, yansıtma oturumu askıda kalır ve yansıtma oturumunu el ile devam ettirmeniz gerekir.

Avantajlar

Veritabanı yansıtma aşağıdaki avantajlara sahiptir:

• Otomatik veritabanı yük devretme mekanizmasını destekler (tanık sunucu ile)
• Veritabanı yansıtma çözümünü yapılandırmak için Windows yük devretme kümesi gerekmez

Göreceli Maliyet

SQL veritabanı yansıtmanın çalışması için SQL Server Standard sürümü veya Enterprise sürümü gerekir. Bu teknolojinin satıcı tarafından kullanımdan kaldırıldığı bildirilmiş olmasına rağmen, hala yaygın olarak kullanılmaktadır.

Özet

Bu yazıda, DR’ı AWS’te uygulamak için SQL Server yedekleme ve geri yükleme, SQL Server günlük gönderimi ve SQL Server veritabanı yansıtma teknolojilerini tartıştık. Bir sonraki yazımızda SQL Server yük devretme kümelemesinden, SQL Server Always On kullanılabilirlik gruplarından, dağıtılmış kullanılabilirlik gruplarından ve AWS’te DR kullanım örnekleri için birden çok DR teknolojisi konusunu birleştirmekten bahsedeceğiz.