Yüksek Erişilebilirlik (HA) ve Felaketten Kurtarma (DR) Kavramları – Bölüm 1

Günümüzün kritik öneme sahip uygulamalarını çalıştıran 7×24 ortamlarda, işletmeler büyük ölçüde verilerinin kullanılabilirliğine / erişilebilirliğine güveniyor. Sunucular ve yazılımları genellikle güvenilir olsa da, her biri bir sunucuyu çökertebilecek bir donanım arızası veya yazılım hatası riski her zaman vardır. Bu riskleri azaltmak için iş açısından kritik uygulamalar, hata toleransı sağlamak için genellikle yedek donanıma güvenir. Birincil sistem başarısız olursa, uygulama otomatik olarak yedek sisteme yük devredebilir. Bu, yüksek erişilebilirliğin (HA – High Availability) altında yatan ilkedir.

HA teknolojilerinin uygulanmasıyla bile, uygulamanın kullanılamamasına neden olan küçük bir olay riski her zaman vardır. Bunun nedeni, bir veri merkezinin kaybı, doğal bir afet veya terör eylemi gibi büyük bir olay olabilir. Ayrıca, veri bozulması veya insan hatasından da kaynaklanabilir ve uygulamanın verilerinin kaybolmasına veya onarılamayacak şekilde hasar görmesine neden olabilir.

Bu durumlarda, bazı uygulamalar mümkün olduğu kadar çok veriyi kurtarmak için en son yedeği geri yüklemeye güvenebilir. Ancak, daha kritik uygulamalar, verilerin eşitlenmiş bir kopyasını ikincil bir konumda tutmak için yedek bir sunucu gerektirebilir. Bu, felaketten kurtarmanın (DR) temelini oluşturan kavramdır.

Erişilebilirlik Düzeyi

Bir çözümün son kullanıcılar için erişilebilir / kullanılabilir olduğu süre, erişilebilir / kullanılabilirlik düzeyi veya çalışma süresi olarak bilinir.  Gerçek bir çalışma süresinin hesaplanabilmesi için bir kullanıcıın gözünden olayı ölçmelisiniz. Yani SQL Server’ınız bir aydan uzun süredir kesintisiz çalışıyor olsa bile, kullanıcılar çözümlerinde farklı faktörlerin neden olduğu kesintiler yaşayabilirler. Bu faktörler, ağ kesintilerini veya bir uygulama sunucusu arızasını içerebilir.

Ancak bazı durumlarda, kullanılabilirlik düzeyini SQL Server düzeyinde ölçmekten başka seçeneğiniz yoktur. Bunun nedeni, kuruluş içinde uçtan uca sistemlerinizi izlemenize (monitor) etmenize imkan sağlayan ürünler olmayabilir. Bununla birlikte, çoğu zaman, bulut sunucusu düzeyinde kullanılabilirlik düzeyini ölçme gereksinimi, teknik olmaktan çok politiktir. Bilişim sektöründe,veri merkezlerinin yönetimini dış kaynak sağlayıcılara vermek bir trend haline geldi. Bu gibi durumlarda, SQL sunucularının yönetiminden sorumlu sağlayıcı, ağ veya uygulama sunucularından sorumlu sağlayıcı olmayabilir. Bu senaryoda, hizmet sağlayıcının performansını doğru bir şekilde değerlendirmek için SQL Server düzeyinde çalışma süresini izlemeniz gerekir.

Erişilebilirlik düzeyi, uygulamanın veya sunucunun kullanılabilir / erişilebilir olduğu zamanın yüzdesi olarak ölçülür. Şirketler genellikle %99, %99,9, %99,99 veya %99,999 erişilebilirlik elde etmeye çalışır. Sonuç olarak, erişilebilirlik düzeyi genellikle 9’larda ifade edilir. Örneğin, beş 9 erişilebilirlik %99,999 çalışma süresi anlamına gelir ve üç 9, %99,9 çalışma süresi anlamına gelir.

Tablo 1-1, her bir erişilebilirlik düzeyi için haftalık, aylık ve yıllık olarak kabul edilebilir kapalı kalma süresinin ayrıntıları verilmiştir.

Diğer kullanılabilirlik düzeylerini hesaplamak için aşağıdaki komut dosyasını kullanabilirsiniz. Bu betiği çalıştırmadan önce, hesaplamak istediğiniz çalışma süresi düzeyini temsil etmek için @Uptime değerini değiştirin. Haftalık, aylık veya yıllık çalışma süresini yansıtmak için @UptimeInterval değerini de değiştirmelisiniz.

DECLARE @Uptime	DECIMAL(5,3) ;
DECLARE @UptimeInterval VARCHAR(5) ;
DECLARE @SecondsPerInterval FLOAT ;
(
SELECT CASE
WHEN @UptimeInterval = 'YEAR' THEN 60*60*24*365.243
WHEN @UptimeInterval = 'MONTH' THEN 60*60*24*30.437
WHEN @UptimeInterval = 'WEEK' THEN 60*60*24*7
END
) ;
DECLARE @UptimeSeconds DECIMAL(12,4) ;
SET @UptimeSeconds = @SecondsPerInterval * (100-@Uptime) / 100 ;
CONVERT(VARCHAR(12), FLOOR(@UptimeSeconds /60/60/24))	+ ' Day(s), '
+ CONVERT(VARCHAR(12), FLOOR(@UptimeSeconds /60/60 % 24)) + ' Hour(s), '
+ CONVERT(VARCHAR(12),  FLOOR(@UptimeSeconds /60 % 60))	+ ' Minute(s), '
+ CONVERT(VARCHAR(12),  FLOOR(@UptimeSeconds % 60))	+ ' Second(s).' ;

Gerçek Erişilebilirlik

Artık bir uygulamanın gerektirdiği kullanılabilirlik / erişilebilirlik düzeyini nasıl hesaplayacağımızı anladığımıza göre, bir uygulamanın gerçek kullanılabilirliğini nasıl hesaplayacağımızı da anlamalıyız. Bunu, MTBF (Arızalar Arasındaki Ortalama Süre – Mean Time Between Failures ) ve MTTR (Mean Time to Recovery – Mean Time to Recover) metriklerini keşfederek yapabiliriz.

MTBF metriği, arızalar arasındaki ortalama süreyi tanımlar. Örneğin, geçen hafta hizmet günlüklerini incelediğimizi ve uygulamamızın üç kesinti yaşadığını hayal edelim. Haftada 168 saat var ve üç başarısızlık oldu. Bizim zaman periyodumuzdaki saat sayısını arıza sayısına bölmemiz yeterlidir. Bu bizim MTBF’mizi üretecek. Bu durumda, 56 saatlik bir MTBF’miz var.

MTTR ‘nin aslında iki farklı anlamı olabilir: Ortalama İyileşme Süresi veya Ortalama Onarım Süresi. Yerinde HA veya DR olmadığında, MTTR metriği bozulan bir şeyin onarılması için geçen ortalama süreyi tanımlar. Bir servis mühendisinin arızalı donanımı değiştirmesini beklememiz gerekebileceğinden, bu potansiyel olarak uzun bir süre olabilir. Ancak HA ve DR hakkında düşünürken MTTR kullanıyoruz

Kesinti süresini kaydetmek için Ortalama Kurtarma Süresi anlamına gelir. Örneğin, üç nodlu bir clusterımız varsa ve nodelardan biri bir donanım hatası yaşarsa, elbette bu sunucuyu düzeltmemiz gerekir, ancak uygulama kesintisi açısından, yalnızca birkaç saniye veya dakika kesintisi yaşarız. , hizmet yük devrettiğinde ve esnekliğimiz devam ederken, bu da uygulamanın işlevsel olmayan gereksinimlerinin etkilenmediği anlamına gelir. Bu nedenle, bu örnekte, MTTR’nin “İyileşme için Ortalama Süre”ye atıfta bulunduğunu varsayacağım.

MTTR’yi, süremiz içindeki toplam kesinti süresinin toplamını alıp arıza sayısına bölerek hesaplayabiliriz. Bu durumda, 168 saatlik süremiz boyunca üç arıza yaşadık ve toplam kesinti süresi 12 dakika oldu. Bu nedenle Foo uygulamamız için MTTR 4 dakikadır.

Artık uygulamamızın MTBF ve MTTR’sini bildiğimize göre, uygulamamızın gerçek kullanılabilirliğini hesaplamak için bu metrikleri kullanabiliriz. Bunun formülü (MTBF/ (MTBF+MTTR))*100’dür. Bu durumda, önce MTTR değerimizi saatlere çevirmemiz gerekiyor, bu yüzden tutarlı birimimiz saatlerimiz var. Dört dakika 0.06667 saattir. Dolayısıyla hesaplamamız (56/(56+0.6667))*100 olacaktır. Bu, gerçek uygulama kullanılabilirliğimizi %99.8811 yapar.

Hizmet Düzeyi Anlaşmaları (SLA) ve Hizmet Düzeyi Hedefleri (SLO)

Sunucuların yönetiminden bir üçüncü taraf sağlayıcı sorumlu olduğunda, sözleşme genellikle hizmet düzeyi sözleşmelerini (SLA’lar) içerir. Bu SLA’lar, ne kadar kapalı kalma süresinin kabul edilebilir olduğu, bir sunucunun arıza durumunda maksimum kapalı kalabileceği süre ve arıza meydana gelirse ne kadar veri kaybının kabul edilebilir olduğu gibi birçok parametreyi tanımlar. Normalde, bu SLA’ların karşılanmaması durumunda sağlayıcı için mali cezalar vardır.

Sunucuların şirket içinde yönetilmesi durumunda, DBA’lar müşteri kavramına sahiptir. Bunlar genellikle uygulamanın son kullanıcılarıdır ve birincil ilgili kişi işletme sahibidir.

Şirket içi bir senaryoda, SLA’ları tanımlamak hala mümkündür ve böyle bir durumda BT Altyapısı veya Platform departmanları, bu SLA’ların karşılanmaması durumunda iş ekiplerine ters ibrazdan sorumlu olabilir. Ancak dahili senaryolarda, BT departmanlarının hizmet düzeyi hedeflerini (SLO’lar) iş ekipleriyle SLA’ların aksine müzakere etmesi çok daha yaygındır. SLO’lar doğası gereği SLA’lara çok benzer, ancak kullanımları, karşılanmamaları durumunda işletmenin BT departmanına mali cezalar uygulamadığı anlamına gelir.

Proaktif Bakım

Kesinti süresinin yalnızca arızadan değil, proaktif bakımdan da kaynaklandığını hatırlamak önemlidir. Örneğin, işletim sistemini veya SQL Server’ın kendisini en son hizmet paketiyle yamalamanız gerekiyorsa, yükleme sırasında biraz kapalı kalmanız gerekir.

Uyguladığınız yükseltmeye bağlı olarak, böyle bir senaryoda kapalı kalma süresi önemli olabilir – bağımsız bir sunucu için birkaç saat. Bu durumda, iş açısından kritik birçok uygulama için yüksek kullanılabilirlik esastır – planlanmamış arıza sürelerine karşı koruma sağlamak değil, planlı bakım sırasında uzun süreli kesintileri önlemek için.

Kurtarma Noktası Hedefi (RPO – Recovery Point Objective)  ve Kurtarma Süresi Hedefi (RTO – Recovery Time Objective)

Bir uygulamanın kurtarma noktası hedefi (RPO), bir arıza durumunda ne kadar veri kaybının kabul edilebilir olduğunu gösterir. Raporlamayı destekleyen bir veri ambarı için örneğin, bir ETL süreci tarafından günde yalnızca bir kez güncellenebileceği ve diğer tüm faaliyetlerin salt okunur raporlama olduğu dikkate alındığında, bu süre 24 saat gibi uzun bir süre olabilir. Bununla birlikte, ticaret platformlarını veya web uygulamalarını destekleyen bir OLTP veritabanı gibi yüksek düzeyde işlemsel sistemler için RPO sıfır olacaktır. Sıfır RPO, hiçbir veri kaybının kabul edilemez olduğu anlamına gelir.

Uygulamalar, yüksek kullanılabilirlik ve olağanüstü durum kurtarma için farklı RPO’lara sahip olabilir.

Örneğin, maliyet veya uygulama performansı nedenleriyle, site içinde bir yük devretme için sıfır RPO gerekli olabilir. Ancak aynı uygulama bir DR veri merkezine yük devrederse, beş veya on dakikalık veri kaybı kabul edilebilir. Bunun nedeni, site içi kullanılabilirliği ve siteler arası kurtarmayı uygulamak için kullanılan teknoloji farklılıklarıdır.

Bir uygulama için kurtarma süresi hedefi (RTO), kurtarma tamamlanmadan ve kullanıcılar yeniden bağlanmadan önce bir uygulamanın kapalı kalabileceği maksimum süreyi belirtir. Bir uygulama için ulaşılabilir RTO’yu hesaplarken birçok yönü göz önünde bulundurmanız gerekir. Örneğin, bir kümenin bir düğümden diğerine yük devretmesi ve SQL Server hizmetinin geri gelmesi bir dakikadan az sürebilir; ancak, veritabanlarının kurtarılması çok daha uzun sürebilir. Veritabanlarının kurtarılması için geçen süre,veritabanlarının boyutu, bir örnek içindeki veritabanlarının miktarı ve yük devretme gerçekleştiğinde kaç işlemin uçuşta olduğu dahil olmak üzere birçok faktöre bağlıdır. Bunun nedeni, taahhüt edilmeyen tüm işlemlerin geri alınması gerektiğidir.

Tıpkı RPO gibi, site içi veya siteler arası yük devretme durumunuza bağlı olarak farklı RTO’ların olması yaygındır. Yine, bu öncelikle teknolojilerdeki farklılıklardan kaynaklanmaktadır, ancak aynı zamanda birincil veri merkezi kaybolursa DR veri merkezindeki tüm mülkü ortaya çıkarmak için ihtiyaç duyduğunuz süreyi de etkiler.

Bir uygulamanın RPO’su ve RTO’su, veri bozulması durumunda da değişebilir.

Bozulmanın doğasına ve uygulanan HA/DR teknolojilerine bağlı olarak, veri bozulması, bir veritabanını bir yedekten geri yüklemeniz gerekmesine neden olabilir.

Bir veritabanını geri yüklemeniz gerekiyorsa, en kötü durum senaryosu, ulaşılabilir kurtarma noktasının son yedekleme zamanı olabilmesidir. Bu, bir faktörü hesaba katmanız gerektiği anlamına gelir

Belirli bir RPO için zorlu iş gereksinimini yedekleme stratejinize dahil edin. Ancak, veritabanının yalnızca bir kısmı bozuksa, canlı veritabanından bazı verileri kurtarabilir ve yalnızca bozuk verileri geri yüklenen veritabanından geri yükleyebilirsiniz.

Veri bozulmasının RTO üzerinde de etkisi olması muhtemeldir. En büyük etkileyen faktörlerden biri, yedeklerin sunucuda yerel olarak depolanıp depolanmadığı veya bunları teypten almanız gerekip gerekmediğidir. Yedekleme dosyalarının teypten, hatta tesis dışı konumlardan alınması, kurtarma sürecine büyük olasılıkla önemli ölçüde zaman kazandırabilir.

Bir başka etkileyen faktör ise yaşanabilecek corruption süreçleridir. Depolama ürünleri üzerinde yaşanabilecek bir corruption(bozulma) sonrasında windows sistem yöneticileri tarafından bir çalışma yapılması gerekmektedir ve bu süreç disk boyutuna, yapısına göre değişkenlik göstermektedir. Doğal olarak bu tarz bir durumda daha fazla kesinti zamanını hesaba katmanız gerekir. Tabi bu corruptionın birde sizin veritabanı dosyalarınınız olduğu alanda olduğunu ve veri kaybı yaşayabileceğinizi de düşürseniz durumun ne kadar önemli olduğunu görebilirsiniz.

Kesinti Maliyeti

Herhangi bir işletme sahibine, uygulamaları için ne kadar kesintinin kabul edilebilir olduğunu ve ne kadar veri kaybının kabul edilebilir olduğunu sorarsanız, ki sormayın soracak olursanız da hiçbir zaman kesinti olmasını istemezler ve cevaplar sırasıyla sıfır ve sıfır olarak gelecektir. Elbette, sıfır kesinti süresini garanti etmek hiçbir zaman mümkün değildir ve farklı erişilebilirlik düzeyleriyle ilişkili maliyetleri açıklamaya başladığınızda, karşılıklı olarak kabul edilebilir bir hizmet düzeyi üzerinde anlaşmak daha kolay hale gelmeye başlar.

Kaç tane 9 elde etmeye çalışmanız gerektiğine karar vermede kilit faktör, arıza süresinin maliyetidir. Kesinti süresiyle ilişkili iki maliyet kategorisi vardır: maddi maliyetler ve maddi olmayan maliyetler. Maddi maliyetlerin hesaplanması genellikle oldukça basittir. Örnek olarak bir satış uygulamasını kullanalım. Bu durumda, satış personeli sipariş alamadığı için en belirgin maddi maliyet gelir kaybıdır. Maddi olmayan maliyetler daha zordur.Örneğin bir müşteri sizin firmanıza sipariş veremeyecek durumda ise rakip firmaya sipariş verebilir ve bir daha geri dönmeyebilir. Diğer maddi olmayan maliyetler, daha yüksek personel devir hızına ve hatta şirket itibarının kaybına yol açan personel moral kaybını içerebilir. Maddi olmayan maliyetler, doğası gereği yalnızca tahmin edilebildiğinden, endüstrinin temel kuralı, maddi maliyetleri üç ile çarpmak ve bu rakamı maddi olmayan maliyetlerinizi temsil etmek için kullanmaktır.

Uygulamanız için toplam kapalı kalma süresinin saatlik bir rakamına sahip olduğunuzda, bu rakamı uygulamanızın öngörülen yaşam döngüsü boyunca ölçeklendirebilir ve farklı erişilebilirlik düzeylerini uygulamanın maliyetlerini karşılaştırabilirsiniz. Örneğin, toplam kesinti maliyetinizin 2.000 $/saat olduğunu ve uygulamanızın öngörülen yaşam döngüsünün üç yıl olduğunu hesapladığınızı düşünün. Tablo 1-2, uygulamanız için kapalı kalma süresinin maliyetini farklı erişilebilirlik seviyesilerine göre hesaplanıp gösterilmiştir.

Erişilebilirlik Çözümünün Maliyeti (TCO); Donanım, lisanslar, güç, kablolama, ek depolama ve yeni raflar, yönetim maliyetleri vb. gibi ek destekleyici donanımları hesaba kattıktan sonra bir çözüme sahip olmak için ihtiyacınız olan maliyet olarak bilinir.

Bu tabloda, beş 9’luk kullanılabilirlik uygulamasının iki-9’luk bir çözüme göre 525.074 ABD doları tasarruf sağladığını görebilirsiniz, ancak çözümü uygulama maliyeti ek 802.000 ABD dolarıdır, yani uygulanması ekonomik değildir. Dört adet 9’luk kullanılabilirlik, iki-9’luk bir çözüme göre 520.344$ tasarruf sağlar ve yalnızca uygulanması için ek 354.000$’a mal olur. Bu nedenle, bu özel uygulama için, tasarım için en uygun hizmet düzeyi dört-9’luk bir çözümdür.

Yedek Sunucuların Sınıflandırılması

Bekleme çözümünün üç sınıfı vardır. Birden çok yedek sunucu sınıfını uygulamak için bazı teknolojileri kullanabilmenize rağmen, her birini farklı teknolojiler kullanarak uygulayabilirsiniz. Tablo 1-3, uygulayabileceğiniz farklı bekleme sınıflarını özetlemektedir.

Özet

Uygulamanızın erişilebilirlik düzeyi, uygulamanın kullanıcılara açık olduğu sürenin yüzdesi olarak ölçülür. Erişilebilirlik düzeyi genellikle dokuz ile ifade edilir. Örneğin, %99,9 çalışma süresi gereksinimi, üç 9’luk kullanılabilirlik olarak bilinir. Çalışma süresi gereksinimi ne kadar yüksek olursa, uygulama maliyeti de o kadar yüksek olur. Bu nedenle, elde etmeye çalıştığınız çalışma süresi düzeyi, SLA’lar ve hizmet dışı kalma süresinin maliyeti tarafından yönlendirilmelidir.

Kurtarma noktası hedefi, bir felaket durumunda ne kadar veri kaybının kabul edilebilir olduğunun bir ölçüsüdür. Örneğin, tek DR çözümünüz yedeklemelerin her saat başı alınması planlanıyorsa, bir saatlik kurtarma noktası hedefine ulaşabilirsiniz.

Kurtarma süresi hedefi, bir hatadan sonra bir çözümü kurtarmanın ne kadar süreceğinin bir ölçüsüdür. Örneğin, 30 dakikalık bir kurtarma süresi hedefiniz varsa, hizmeti yarım saat içinde geri yükleyebilmeniz gerekir.

Uygulamalarınız için kesinti süresinin maliyeti erişilebilirlik düzeyinizi belirleyen ana etkenlerden bir tanesidir. Kesinti süresinin maliyeti hem maddi hem de maddi olmayan maliyetlerden oluşur. Maddi maliyetler hesaplanabilirken, maddi olmayan maliyetlerin tahmin edilerek elde edilmesi gerekir.

Yedekli altyapı, uygulamalarınızın ve hizmetlerinizin kullanılabilirliğini korumanıza yardımcı olur. Yedekli bir sunucu hot warm veya cold olarak sınıflandırılabilecek yedekleme çeşitliğiliği bulunmaktadır. Hot yedekleme yapısı, canlı sunucu ile senkronize tutulan ve otomatik yük devretmeye izin verecek şekilde yapılandırılan bir sunucudur. Bu, HA senaryoları için uygundur. Warm yedekleme yapısı, canlı sunucuyla senkronize tutulan, ancak otomatik olarak yük devretecek şekilde yapılandırılmayan bir sunucudur. Bunun yerine, bir mühendisin yük devretmeyi manuel olarak gerçekleştirmesi gerekir. Bu, DR senaryoları için uygundur. Cold yedekleme yapısı ise , canlı sunucu ile senkronize tutulmaz ve bu nedenle otomatik olarak yük devretilemez.Tüm verilerin salt okunur olduğu ve hiçbir zaman değiştirilmediği DR senaryoları için uygundur.