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

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

Günümüz dünyasında, felaketin gerçekleşmesi an meselesidir ve meydana geldiğinde SQL Server veritabanlarınızı kurtarmak ve sistemleri minimum veri kaybı ve aksama süresi ile çevrimiçi duruma getirmek esastır. SQL Server veritabanı erişimi kesintisine yanıt vermek ve bundan kurtulmak için yüksek kullanılabilirlik (High Availability – HA) ve felaket kurtarma (Disaster Recovery – DR) çözümleri kullanılır. Yüksek kullanılabilirlik çabaları, bir kesintiyi önlemek için ne yapılması gerektiğini; felaket kurtarma ise, bir kesintiden sonra yüksek kullanılabilirliği yeniden kurmak için ne yapılması gerektiğini ele alır. AWS, SQL Server iş yükleri için HA ve DR çözümlerinin maliyetini ve karmaşıklığını azaltmanıza yardımcı olabilir.

Birçok müşteri, AWS’te SQL Server için doğru HA veya DR çözümünü seçmek için rehberliğimize başvurur, ancak herkese uyan tek bir çözüm yoktur. Potansiyel veri kaybı, kurtarma süresi, operasyonel karmaşıklık ve operasyonel maliyet içeren değiş tokuşlar (trade-offs) vardır. Hatta bazı durumlarda, hem HA hem de DR özelliklerine sahip bir çözümü uygulamak için bu teknolojileri birleştirebilirsiniz.

Birçok genel amaçlı kullanım senaryosu için müşteriler, yönetilen bir hizmet olan SQL Server için Amazon Relational Database Service (Amazon RDS) ile çalışabilir ve bu da AWS’te SQL Server’ı kurmayı, çalıştırmayı ve ölçeklendirmeyi kolaylaştırır. Müşteriler ayrıca Amazon Elastic Compute Cloud (Amazon EC2) üzerinde kendi SQL Server veritabanlarını çalıştırabilir ve yönetebilir.

Bu blog dizisinde, Amazon EC2’da SQL Server için kullanılabilen DR çözümlerini kıyaslıyor ve karşılaştırıyoruz ve bu değiş tokuşların doğasını ve AWS’te SQL Server için DR iş yüklerini uygulamanın maliyetini ve karmaşıklığını anlamanıza yardımcı oluyoruz. SQL Server için Amazon RDS için benzer bir dizi yazmayı planlıyoruz, Amazon RDS esnekliği hakkında daha fazla bilgiyi kullanım kılavuzunda bulabilirsiniz.

Bu gönderi, farklı SQL Server versiyonları ve sürümleri için mevcut olan teknik terminoloji ve DR çözümlerini tanıtıyor. 2. bölümde, SQL Server yedekleme ve geri yüklemeyi, SQL Server log gönderimini ve SQL Server veritabanı yansıtmasını (mirroring) inceliyoruz. 3. bölümde, SQL Server Always on Failover Cluster Instances (FCI’lar) ve Always On kullanılabilirlik gruplarına derinlemesine dalıyoruz. Son olarak, 4. bölümde, AWS Database Migration Service (AWS DMS), CloudEndure Disaster Recovery’yi tanıtıyoruz ve seride tartışılan tüm teknolojileri özetliyoruz.

Teknik Terminoloji

Bu gönderi dizisi boyunca aşağıdaki terimleri kullanıyoruz:

• Yüksek kullanılabilirlik (High Availability – HA) – HA, işletmenizin kesinti olmadan çalışmasını sağlamak için veri merkezi, Erişilebilirlik Alanı, sunucu, ağ ve depolama alt sistemi arızalarına karşı koruma sağlar.
• Felaket kurtarma (Disaster Recovery – DR) – DR, bir felakete hazırlanmak ve felaketten kurtulmakla ilgilidir. İş sürekliliğiniz veya finansmanınız üzerinde olumsuz etkisi olan herhangi bir olay felaket olarak adlandırılabilir. Bu, donanım veya yazılım arızası, ağ kesintisi, elektrik kesintisi, yangın veya su baskını gibi bir binada fiziksel hasar, insan hatası veya başka bir yıkıcı olay olabilir.
• Kurtarma Süresi Hedefi (Recovery Time Objective – RTO) – RTO, hizmetin kesintiye uğraması ile hizmetin geri yüklenmesi arasındaki kabul edilebilir maksimum gecikmedir (kuruluşunuz tarafından tanımlanır). Bu, hizmetin kullanılamadığı durumlarda neyin kabul edilebilir bir zaman aralığı olarak kabul edildiğini belirler.
• Kurtarma Noktası Hedefi (Recovery Point Objective – RPO) – RPO, son veri kurtarma noktasından bu yana (kuruluşunuz tarafından tanımlanan) kabul edilebilir maksimum süredir. Bu, son kurtarma noktası ile hizmetin kesintiye uğraması arasında neyin kabul edilebilir bir veri kaybı olarak değerlendirildiğini belirler.
• Yük Devretme (Failover) – Birincil düğümün (primary node) artık uygulamalar tarafından erişilebilir olmaması durumunda hizmetin otomatik olarak bekleme düğümüne (standby node) geçiş sürecidir. Yük devretme, herhangi bir kullanıcı müdahalesi gerektirmez.
• Geçiş (Switchover) – Yük devretmenin aksine geçiş, test ve planlı bakım için hizmetin kasıtlı olarak birincil düğümden yedek düğüme (yeni birincil düğüm) geçiş sürecidir. Geçiş, kullanıcı müdahalesi gerektirir.
• Yeniden Çalışma (Failback) – Yeniden çalışma, orijinal düğüm sağlıklı duruma geri döndüğünde ve hizmete devam etmeye hazır olduğunda, yük devretme veya geçişin tersidir. Yeniden çalışma her zaman kullanıcı tarafından başlatılır.
• Aktif-pasif (Active-passive) – Hizmetin bir kesinti olmadığı sürece her zaman tek bir düğüm (birincil düğüm) tarafından servis edildiği bir aktif-pasif küme yapılandırmasıdır. Hizmet, kesinti algılandığında, ayrılmış bekleme düğümlerine aktarılır. Bu hizmet aktarımı, otomatik yük devretme veya kullanıcı tarafından başlatılan geçiş yoluyla olabilir.
• Aktif-aktif (Active-active) – Hizmetin aynı anda hem birincil hem de ikincil düğümler tarafından sağlandığı bir aktif-aktif küme konfigürasyonudur. Bu yapılandırmada, etkin düğümlerden yalnızca biri kullanılamaz hale gelirse yük devretme gerektirmez. Bir etkin düğüm kullanılamıyorsa, diğer etkin düğümler kullanılabilir olmaya devam eder.
• Pilot light – Verilerinizi bir bölgeden diğerine çoğaltın ve temel iş yükü altyapınızın bir kopyasını sağlayın. Veritabanları ve nesne depolama gibi veri çoğaltma ve yedeklemeyi desteklemek için gereken kaynaklar her zaman açıktır. Uygulama sunucuları gibi diğer öğeler, uygulama kodu ve yapılandırmaları ile yüklenir; ancak kapatılır ve yalnızca test sırasında veya Felaket Kurtarma yük devretmesi başlatıldığında kullanılır.
• Warm standby – Warm standby, her zaman DR Bölgesinde çalışan iş yükünüzün küçültülmüş ancak tamamen işlevsel bir sürümünü korur. İş açısından kritik sistemler tamamen kopyalanır ve her zaman çalışır, ancak filosu küçültülür. Kurtarma zamanı geldiğinde, üretim yükünün üstesinden gelmek için sistem hızla büyütülür. Warm standby ne kadar büyütülürse, RTO ve kontrol düzlemi güveni o kadar düşük olur. Tam ölçeğe yükseltildiğinde, bu, hot standby olarak bilinir.
• Cold standby – Cold standby, birincil düğümünüzün yedekliliğini korur. Bekleme düğümü kapatma modundadır ve birincil düğümle senkronizasyonu sürdürmek için manuel olarak açılması gerekir.
• Eşzamanlı çoğaltma (Synchronous replication) – Çoğaltma, veri değişikliklerinin bir veritabanından başka bir veritabanına kopyalanmasıdır. Çoğu eşzamanlı çoğaltma ürünü, verileri birincil depolamaya ve çoğaltmaya aynı anda yazar. Bu nedenle, birincil kopya ve çoğaltma her zaman senkronize kalmalıdır.
• Eşzamansız çoğaltma (Asynchronous replication) – Eşzamansız çoğaltma ürünleri, veriler zaten birincil depolamaya yazıldıktan sonra verileri kopyaya kopyalar. Çoğaltma işlemi, ikincil bir çoğaltmaya göre minimum gecikmeyle çalışır. Birincil eşzamansız mod olarak yapılandırılırsa, yalnızca manuel yük devretmeye izin verir. Bir yük devretme olayı durumunda, bazı veri kayıpları meydana gelebilir.

Aşağıdaki tablo, HA ve DR’dan ne beklemeniz gerektiğini özetlemektedir.

Server versiyon ve sürüm gereksinimleri

SQL Server kurulum gereksinimleri, uygulama gereksinimlerinize göre değişir. SQL Server’ın farklı sürümleri, kuruluşların ve bireylerin benzersiz performans, çalışma zamanı ve fiyat gereksinimlerini karşılar. Yüklediğiniz SQL Server bileşenleri de özel gereksinimlerinize bağlıdır. Aşağıdaki tablolar, SQL Server’da bulunan sürümler ve bileşenler arasında en iyi seçimi nasıl yapacağınızı anlamanıza yardımcı olur.

Aşağıdaki tablo, SQL Server sürümüne göre DR çözümlerini özetlemektedir. Bu blog dizisinde bu seçenekleri keşfedeceğiz.

Aşağıdaki tablo, SQL Server sürümüne göre DR çözümlerini özetlemektedir.

Özet

Felaket kurtarma çözümünün seçimi, gereksinimlerinize ve bütçenize ve ayrıca yüklediğiniz SQL Server ürününün versiyonuna ve sürümüne bağlıdır. Bazı kullanım durumlarında, birden fazla DR teknolojisini birleştirmek bile faydalıdır.

Bu gönderide, DR terminolojisini ve ayrıca DR özelliklerini AWS ile uygulamaya yönelik SQL versiyonlarını ve sürümlerini tartıştık. Bir sonraki yazımızda, DR kullanım durumları için SQL yedekleme ve geri yükleme, SQL log gönderimi ve SQL veritabanı yansıtma teknolojilerinden bahsedeceğiz.