SQL Server 2017 Yüksek Erişilebilirlik Çözümleri - 3 (High Availability Solutions)

Serinin bir önceki yazısında AlwaysOn Failover Cluster ve AlwaysOn Availability Group özelliklerine odaklanmıştık. 

Önceki yazıya şu linkten ulaşabilirsiniz:

http://www.abdullahkise.com/2019/03/sql-server-2017-yuksek-erisilebilirlik_16.html

SQL Server 2017 ile birlikte kullanılabiliecek Yüksek Erişebilirlik çözümleri özetle şöyle:

SQL Server 2017 editionları ve desteklenen özellikleri aşağıdaki linkten inceleyebilirsiniz:

https://docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2017?view=sql-server-2017#RDBMSHA

HA çözümleri birlikte kullanılarak farklı topolojiler elde edilebilir. Biz özetle temel topolojilere ve çözümlerin avantajlı-dezavantajlı yönlerine odaklanmaya kaldığımız yerden devam edelim.

Database Mirroring

Uzun zamandır var olan bir çözümdür ilerleyen versiyonlarda görmeyebiliriz. Her bir veritabanı için ayrıca uygulanır. Aktif olan Principal sunuculardan pasif olan Mirror sunucuya Senkron ve asenkron veri aktarımı yapabilir. Eğer Witness sunucu eklerseniz otomatik failoverı da destekler. Mirror sunuculardaki veritabanları doğrudan okunamaz. Ancak veritabanı snapshotları alınarak okuma yapılabilir.

Aynı versiyon ve edition olmasına dikkat etmelisiniz. Veritabanı adını sağ tıklayarak ulaştığınız Task/Mirror menüsüyle veya scriptler yardımıyla çözümü ilgili veritabanına uygulayabilirsiniz. Her edition Database Mirroring özelliğini farklı şekilde destekler. Witness sunucudaki versiyon aynı olmalıdır fakat edition farklı olabilir. Mesela Express edition kullanabilirsiniz. Witness sunucu iki sunucuyu takip edip yük devrinin otomatik yapılmasını sağlar. Witness olmadan da Database Mirroring kurulabilir.

Temel topolojisi:

Avantajlar:

• Senkron ve asenkron çalışabilir.
• Full Safety modeda senkron çalışır ve yük devrinde (failover) veri kaybı olmaz.
• Witness sunucu topolojiye dahil edilmişse saniyeler içerisinde otomatik yük devrinde (failover) yapılabilir.
• Mirror sunucularda veritabanının kopyaları (replica) olur ve bu kopyalar snapshotlar yardımıyla okunabilir.

Dezavantajlar:

• Otomatik yük devri (failover) yapılabilmesi için ek Witness sunucuya ihtiyaç duyulur.
• Tek pasif node aktarılabilir.
• Veritabanları tek tek ayarlanır. Uygulamalar birden fazla veritabanı kullanıyorsa failover sırasında veritabanlarının bir kısmı diğer tarafa geçmezse sorun oluşturur.
• Pasif nodelardaki veritabanları okunamaz. Sadece snapshot alınarak okunabilir.
• Veritabanlarının diğer nodelar üzerinde kopyası oluştuğu için daha fazla disk alanına ihtiyaç duyulur.
• Failover sonrası uygulama tarafında Connection Stringlerin değiştirilmesi gerekir. Bağlantı cümesine "Failover Partner" ibaresi eklenmelidir.
• Server seviyesinde tanımlanan nesnelerin (job, login vs.) diğer nodelara da tanımlanması gerekir.

Basic Availability Groups

Database Mirroring özelliğinin yerini alacak yeni bir özellik. Sadece Standart editionda 2 sunucu 1 veritabanı için kurulabilir. AlwaysOn Availability Group özelliğine benzer şekilde kurulsa da bir çok yetenekten mahrumdur. Mesela pasif sunuculardaki veritabanları okuma ve yedeklemede kullanılamaz, page bozukluklarını düzeltilmez. Enterprisea geçerken upgrade ile geçmek mümkün değildir. Availability Groupun yeniden kurulması gerekir. Bu hali daha çok Mirroringi andırır.

Windows Failover Cluster üzerinde kurulur ve Enterprisedaki AlwaysOn Availability Group ile aynı şekilde uygulanır. 

Temel topolojisi:

Avantajlar:

• Database Mirroringin yeni hali (yakında yerini alacak) ve AlwaysOn Availability Groupun kısıtlı halidir.
• Standart editionda 2 sunucu 1 veritabanı için oluşturulabilir.
• Senkron-asenkron çalışabilir.
• Otomatik yük devri (failover) yapılabilir.

Dezavantajlar:

• Yalnızca 2 sunucu arasında 1 db için oluşturulabilir.
• AlwasyOn Availability Groupa geçişte Basic Availability Groupun kaldırılması gerekir. AO AG kurulumu sıfırdan yapılır.
• Pasif nodeki veritabanı okuma için kullanılamaz, backup alınamaz.
• Page bozuklukları pasif nodea gönderilirken kontrol edilmez.
• Sadece SQL Server 2016 ve sonrası Standart editionda kullanılabilir.
• Server seviyesinde tanımlanan nesneler (job, login vs.) diğer nodelarda da tanımlanması gerekir.

Buraya kadar değindiğimiz özellikler otomatik yük devrini (failover) destekleyen tam manasıyla Yüksek Erişilebilirlik çözümleri nitelemesini hak eden özelliklerdi. Şimdi ise otomatik yük devrini desteklemeyen sadece kopya veritabanı oluşturmak için kullanılan kısmen Yüksek Erişilebilirlik çözümlerinden sayılan diğer özellikleri inceleyelim. Bu özelliklerin topolojilerini çizmeden direk avantaj ve dezavantajlarına değineceğim.

Bu arda serimizde Replication özelliğini odağımızın dışında tutuyorum. Çünkü Replication tablo seviyesinde yayıncı, dağıtıcı ve abone rollerinde gazete dağıtım mantığında veri kopyalamak için kullanılır. Yüksek erişilebilirlik çözümü sayılmaz.

Clusterless Availability Group

Hem Enterprise hem Standart editionda destekleniyor. Windows Failover Cluster kurulumuna ihtiyaç olmuyor. Ancak bu bir zayıflığı da beraberinde getiriyor. sadece Windows Server 2016 ve SQL Server 2017 versiyonlarında geçerli bu özellikte bir Yüksek Erişebilirlik Çözümünden beklenen pek az şey mevcut. Bu haliyle Log Shippingi andırıyor diyebilirim. Clusterless Availability Group özelliğinin amacı kopya veritabanları oluşturmaktır. Read-Scale Availability Group olarak da anılır.

Avantajlar:

• Windows Failover Cluster kurulmaz diğer yönleriyle Availability Group özelliklerine benzer şekilde yönetilir.
• Veritabanı kopyası oluşturmak için kullanılır. Kopyalar okuma ve yedekleme için kullanılabilir.
• Senkron-asenkron veri aktarımı yapılabilir.

Dezavantajlar:

• Windows Failover Cluster üzerine kurulmamıştır. Yüksek erişilebilirlik için gerekli mekanizma mevcut değildir.
• Otomatik yük devri (failover) olmaz
• Page bozuklukları pasif nodea gönderilirken kontrol edilmez.
• Minimum Windows Server 2016, SQL Server 2017 gereklidir.
• Server seviyesinde tanımlanan nesneler (job, login vs.) diğer nodelarda da tanımlanması gerekir.

Log Shipping

Uzun zamandır var olan bir çözümdür. Temelde Backup/Restore ile diğer sunucularda kopya veritabanı oluşturur. En basit ve ucuz yöntemdir diyebiliriz. Ancak zamanlanmış backupları takip etmek gerekir. Bu yöntemle kopya veritabanının belli bir süre geriden gelmesini sağlayabilirsiniz.

Avantajlar:

• Kurulumu basittir. Temel olarak Backup/restore işlemi otomatik yapılır.
• Pasif nodelarda veritabanının kopyaları oluşur.
• Pasif nodeların ne kadar geriden geleceği ayarlanabilir.
• Farklı edition ve üst versionlar arasında kurulabilir.

Dezavantajlar:

• Otomatik yük devri (failover) desteklemez. Failover dakikalar hatta saatler alabilir.
• Dakikalar seviyesinde veri kaybı olur.
• Veritabanları tek tek ayarlanır.
• Backup/restore işlemleri takip edilmelidir.
• Log shipping aktifken pasif nodelarda veritabanları restoring modeda olduğu için okuma yapılamaz.
• Diğer nodelar üzerinde veritabanlarının kopyası olduğu için daha fazla disk alanına ihtiyaç duyulur.
• Failover sonrası uygulama tarafında connection stringlerin değiştirilmesi gerekir.
• Server seviyesinde tanımlanan nesneler (job, login vs.) diğer nodelarda da tanımlanması gerekir.

AlwaysOn Availability Groups yaygınlaşmadan önce Database Mirroring yaygın şekilde kullanılmaktaydı. Log Shipping ise yıllar önce tercih ediliyordu. Şimdilerde ise Yüksek Erişilebilirlik denince akla ilk gelen AlwaysOn Availability Groups olmaktadır. Belki özetlediğimiz çözümlerden bazıları sizin için diğerlerinden daha uygundur. Belki çözümleri bir arada kullanmak istersiniz. Seçim sizin.

Sistemi ayakta tutmak büyük uğraş ister. Maliyetler, eldeki kaynaklar ve özetlediğimiz çözümler sayesinde sisteminizi 7/24 ayakta tutabilirsiniz. Biz temel topolojilere odaklandık. Sizler bu çözümleri bir arada kullanarak daha büyük topolojiler elde edebilirsiniz.

SQL Server 2017 Yüksek Erişilebilirlik Çözümleri - 2 (High Availability Solutions)

Serinin bir önceki yazısında da belirttiğimiz gibi; ihtiyaç duyduğumuz hizmetlerin her an erişilebilir olması son derece önemlidir. Özellikle kurumsal firmalar müşteri memnuniyeti, kurumsal imaj, rekabet ve karlılık gibi daha bir çok nedenden dolayı hızlı ve sürekli erişebilir olmaktan vazgeçemezler.

Sürekli erişilebilir olmak sizin için önemliyse ve olası bir felakette hizmet kesintisini saniyeler, hatta mili saniyeler seviyesinde tutmak isterseniz; yüksek erişilebilirlik - HA çözümlerine odaklanmanız gerekir.

SQL Server 2017 ile birlikte felaket öncesi alınabilecek önlemler (Yüksek Erişilebilirlik Çözümleri) şunlardır:

1. AlwaysOn Failover Cluster (Uzun zamandır var. Bazı versiyonlarda geliştirildi.)
2. AlwasyOn Availabilty Groups (SQL Server 2012 ile birlikte geldi ve her versiyonda geliştirildi.)
3. Database Mirroring (Uzun zamandır var. Yeni versiyonlarda görmeyebiliriz.)
4. Basic Availability Groups (Mirroringin yerini alıyor. Standart editionda 2 Server 1 DB için kurulabilir.)
5. Clusterless Availability Group (Yüksek erişilebilirlik çözümü sayılmaz. DB kopyası oluşturur.)
6. Log Shipping (Uzun zamandır var. Backup-restore ile DB kopyası oluşturulur.)

Serinin bir önceki yazısına şu linkten ulaşabilirsiniz:

http://www.abdullahkise.com/2019/03/sql-server-2017-yuksek-erisilebilirlik.html

Bu yazımızda SQL Server 2017 ile birlikte kullanılabilen Yüksek Erişilebilirlik - HA çözümlerini karşılaştıralım ve temel topolojilere bir göz atalım.

SQL Server 2017 Enterprise ve Standart Editionda desteklenme durumu şöyle demiştik:

SQL Server 2017 editionları ve desteklenen özellikleri aşağıdaki linkten inceleyebilirsiniz:

https://docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2017?view=sql-server-2017#RDBMSHA

HA çözümleri birlikte kullanılarak farklı topolojiler elde edilebilir. Biz özetle temel topolojilere ve çözümlerin avantajlı-dezavantajlı yönlerine odaklanacağız.

AlwaysOn Failover Cluster

Uzun zamandır var olan bir teknolojidir. Bazı versiyonlarda bir takım geliştirmeler yapıldı ancak temel mantık aynı. Öncelikle sunucularda arasında Windows Failover Cluster kurulur. Hemen ardından bir sunucuya SQL Server kurulumu yapılır ve diğer sunuculara da SQL Server kurulumları Cluster olarak eklenerek yapılır.

Bu çözüm servis seviyesine odaklanır. Bir aktif sunucu olur ve bu sunucuda yazma okuma yapılabilir. Bir felaket anında pasif sunucular elle veya otomatik olarak aktif hale gelebilir. pasif sunucular aktif olana kadar atıldır. Çapraz şekilde aktif-aktif olacak bir tasarım yapılabilir. Ancak pasif kalan makine üzerinden aynı veritabanı yazma/okuma amaçlı kullanılamaz. 

Sunucular ortak diske baktığı için disk bazlı bir felaket olduğunda bu çözüm işe yaramaz.

Temel topolojisi:

Avantajlar:

• Standart editionda 2 makine desteklenir.
• Windows Cluster alt yapısı kullanılır ve Clientlar Public IP üzerinden eriştiği için yük devri (failover) sonrası uygulama tarafında değişiklik gerekmez.
• Saniyeler/dakikalar (20 sn + Recovery süresi kadar) içerisinde diğer makineye otomatik yük devri (failover) yapılabilir.

Dezavantajlar:

• SQL Server 2012 sonrası kullanımı azaldı. Yerine AlwaysOn Availability Group trend oldu.
• Pasif nodelar üzerinden okuma yapılamaz. Pasif nodelar tamamen atıl kalır.
• Pasif nodelarda veritabanı kopyası (replica) yoktur.
• Nodelar (sunucular) ortak disk kullandığı için disk hatalarına karşı veri korunmaz. Veritabanı değil servis seviyesinde erişilebilirlik sağlar.

AlwasyOn Availabilty Groups

SQL Server 2012 ile birlikte geldi. Her versiyonda geliştirildi ve yeni özellikler eklendi. Bir çok açıdan güçlü ve başarılı bir çözüm. Eskiden beri kullanılan Database Mirroring ve Log Shipping'in iyi tarafları birleştirilmiş ve Windows Failover Cluster alt yapısı üzerine inşa edilmiş bir çözüm. Database Mirroring gibi senkron/asenkron veri aktarımı yapılabilir. Felaket anında bir kaç saniyede görevi diğer sunucuya otomatik olarak devredebilir. Log Shipping gibi birden fazla sunucu/veritabanı için kurulabilir. Hatta pasif olan nodelardaki veritabanları özel bir çaba gerektirmeden veri okuma ve backup alma amaçlı kullanılabilir.

Primary node üzerinden yazma okuma taleplerinize cevap bulabilirsiniz. Secondary nodeları da raporlama ve yedekleme amaçlı kullanabilirsiniz. Bu şekilde 8 nodeu birden fazla veritabanı için yüksek erişilebilirlik kapsamına alabilirsiniz.

Öncelikle Windows Failover Cluster kurmanı gerekir. Sonra sunuculara ayrı ayrı SQL Server  Enterprise kurulumları normal şekilde yapılır. Hemen ardından SQL Server Database Engine servislerinden AlwaysOn Availability Group aktif edilir ve Availability Grouplar arayüzlerden veya scriptler yardımıyla oluşturulur.

Temel topolojisi:

Avantajlar:

• Senkron ve asenkron çalışabilir. 10 saniyeden kısa sürede otomatik yük devri (failover) yapılabilir.
• Senkron olduğunda veri kaybı sıfırdır.
• Pasif nodelarda veritabanı kopyaları (replica) oluşur.
• Primary nodea yazma/okuma diğer nodelarda sadece okuma yapılabilir. Pasif nodelar raporlama ve backup amaçlı kullanılabilir.
• Birden fazla veritabanı tek bir availability group altınta toplanabilir. Felaket anında tüm veritabanları için yük devri (failover) yapılır.
• Windows Failover Cluster alt yapısı kullanılır ve istemciler listener adı ile erişim sağladığı için failover sonrası uygulama tarafında değişiklik gerekmez.
• Pagelerde oluşan tutarsızlıklar pasif nodelara düzeltilerek aktarılır.

Dezavantajlar:

• Enterprise edition gereklidir.
• Veritabanlarının diğer nodelar üzerinde kopyası (replica) olduğu için daha fazla disk alanına ihtiyaç duyulur.
• Server seviyesinde tanımlanan nesneler (job, login vs.) diğer nodelarda da tanımlanması gerekir.
• Secondary sunucular primary sunucu kadar güçlü olmazsa senkron modda ciddi yavaşlıklar oluşur.

Serinin bu yazısında bir biri ile karıştırılan iki farklı çözümü ele aldık. Diğer çözümlere sonraki yazımızda odaklanacağız.

SQL Server 2017 Yüksek Erişilebilirlik Çözümleri - 1 (High Availability Solutions)

Hizmet aldığımız veya verdiğimiz firmaların ihtiyaç duyulduğu her an erişilebilir olması son derece önemlidir. Özellikle kurumsal firmalar müşteri memnuniyeti, kurumsal imaj, rekabet ve karlılık gibi daha bir çok nedenden dolayı hızlı ve sürekli erişebilir olmaktan vazgeçemezler.

Bazı kuruluşlar için hizmet kesintilerinin bedeli çok ağır olabilir. Gartner'ın yapmış olduğu bir araştırmaya göre büyük ölçekli bir kuruluşun 1 saatlik kesintisinin bedeli 42 bin dolar civarındadır. Geçtiğimiz senelerde InformationWeek dergisinde yayınlanan bir analize göre IT kesintilerinin bedeli 26,5 milyar dolara çıkmıştır.

Çoğu kuruluşun hayatı tümüyle kesintisiz devam etmesi gereken hizmetlere bağlıdır. Bu hizmetlerin devamlılığı için fiyat-performans analizleri iyi yapılmış güvenilir sistemler kurmak gerekir.

Sistemlerin durduğu, hizmetin devam edemediği anı felaket anı olarak kabul edersek; felaketten sonra sistemi tekrar işler hale getirmek için yapılacak işlemlere Felaket Kurtarma - Disaster Recovery (DR), felaket olmadan önce alınacak önlemlere de Yüksek Erişilebilirlik - High Availability (HA) deriz.

Felaket olup sistem tekrar işler hale gelene kadar iki tür kayıp yaşanır; bunların ilki hasar gören verinizle veya verinizin yedeklenmemiş kısmıyla ilgilidir. ikincisi ise sistemi tekrar işler hale getirene kadar geçen sürede yakalayamadığınız verilerle ilgilidir.  Her ikisinin de maliyeti maddi ve manevi açılardan çok ciddi seviyelere ulaşabilir.

DR adına yapılacak işlemler temelde sağlıklı şekilde alınmış backuplardan ve snapshotlardan dönmekle ilgilidir.  HA adına alınan önlemler ise temelde birden fazla server için cluster yapısı kurmak ve kopya-replica veritabanları oluşturmakla ilgilidir. 

HA felsefesinde server yönetimi her ne kadar görece daha pahalı olsa da, DR felsefesinde server yönetiminde karşılaşılan kayıplar çok daha pahalıya mâl olabilmektedir.

Sistemin ayakta olduğu süreye uptime, kesinti olup cevap veremediği süreye downtime denir. Sistemin hizmet vermeye başladığı andan itibaren felaket olup cevap veremediği ve tekrar hizmet vermeye başladığı ana kadar geçen toplam süreye total elapsed time adı verilir. Bu değişkenler üzerinden sistemin erişilebilirlik yüzdesi hesaplanır.  Özellikle bulut hizmeti veren firmalar sistemleri ne kadar ayakta tutabildiklerini bu yüzdelerle ifade ederler.

Bir örnek üzerinden açıklayalım:

Haftalık olarak bakım, onarım ve yükseltme adına bir takım çalışmalar yaptığımızı düşünelim. Bu çalışmalar için serverı en müsait zamanlarda toplamda haftada 2 saat kadar erişime kapattığımızı düşünelim. 

Haftada 2 saat kesinti, kabaca ayda 8 saat kesinti yapar. Bu yılda 96 saat demektir.

Tüm yılda 24*365 yani 8760 saat bulunsun.

Erişilebilirlik Yüzdesi = (( toplam geçen süre - toplam kesinti süresi ) / toplam geçen süre ) * 100

EY = ((8760 - 96)/8760)*100

EY= 98.9

Bu durumda böyle bir sistem yılda %98.9'luk uptime ile hizmet vermektedir deriz.

Haftada 2 saatlik kesinti bazı hizmetler için makul görünebilir. Ancak bazı hizmetler için asla kabul edilemez. Dahası gerçek manada ölümcül sonuçlar doğurabilir.

Rekabette avantajı elden bırakmak istemeyen firmalar için ise yüksek performans ve yüksek erişilebilirlik zorunluluktur. Amazon'un yapmış olduğu bir açıklamaya göre 100 ms gecikmeleri satışarını %1 düşürmektedir. Başka bir açıklamalarına göre her saniyenin değeri 1.6 milyar dolar civarındadır.

Sistemlerin %100 uptimea sahip olması pratikte pek mümkün değildir. Bakım, onarım ve yükseltme her sistemde bir şekilde olur. Kesintiler insan algısının altına düşse de mevcuttur. Bu sebeple sistemlerin uptime yüzdeleri %99.999 biçiminde olur ve kaç dokuz olduğuna göre isimlendirilir.

Mesela; iki dokuzluk yani %99.0'lık uptimea sahip bir sistem yılda 3.65 gün haftada 1.68 saat downtimea sahiptir. Beş dokuzluk yani %99.999'luk uptimea sahip bir sistem ise yılda sadece 5.26 dakika, haftada ise 6.06 saniye downtime sahiptir. Sistemler genelde üç dokuzluk yani %99.9'luk uptimea sahip olur. Bu da yılda 8.76 saat, ayda 43.8 dakika, haftada 10.1 dakika downtime demektir.

Sürekli erişilebilir olmak sizin için önemliyse ve olası bir felakette hizmet kesintisini saniyeler, hatta mili saniyeler seviyesinde tutmak isterseniz; yüksek erişilebilirlik - HA çözümlerine odaklanmanız gerekir.

SQL Server 2017 ile birlikte felaket öncesi alınabilecek önlemler şunlardır:

1. AlwaysOn Failover Cluster (Uzun zamandır var. Bazı versiyonlarda geliştirildi.)
2. AlwasyOn Availabilty Groups (SQL Server 2012 ile birlikte geldi ve her versiyonda geliştirildi.)
3. Database Mirroring (Uzun zamandır var. Yeni versiyonlarda görmeyebiliriz.)
4. Basic Availability Groups (Mirroringin yerini alıyor. Standart editionda 2 Server 1 DB için kurulabilir.)
5. Clusterless Availability Group (Yüksek erişilebilirlik çözümü sayılmaz. DB kopyası oluşturur.)
6. Log Shipping (Uzun zamandır var. Backup-restore ile DB kopyası oluşturulur.)
7. Replication (Yüksek erişilebilirlik çözümü sayılmaz. Tablo seviyesinde kopya oluşturulur)

Replication tablo seviyesinde yayıncı, dağıtıcı ve abone rollerinde gazete dağıtım mantığında veri kopyalamak için kullanılır. Yüksek erişilebilirlik çözümü sayılmaz. Biz de bu sebeple Replicationı serimizin odağı dışında tutuyoruz.

SQL Server 2017 Enterprise ve Standart Editionda desteklenme durumu şöyle:

Serinin devamında bu çözümlerin hangi editionlarda ne şekilde desteklendiğine, temel topolojilere ve çözümlerin avantajlı-dezavantajlı yönlerine odaklanacağız.

Yüksek Erişebilirlik ve Felaketten Kurtarma Çözümleri (High Availability and Disaster Recovery)

Hizmet aldığımız veya verdiğimiz sistemlerin ihtiyaç duyulduğunda erişilebilir olması son derece önemlidir. Özellikle kurumsal firmalar müşteri memnuniyeti, kurumsal imaj ve karlılık gibi daha bir çok neden dolayı sürekli erişebilir olmayı arzularlar.

Bazı kuruluşlar için hizmet kesintilerinin bedeli inanılmaz boyutlara ulaşabilir. Son zamanlarda yapılmış bir kaç araştırma sonucuna göz atalım; Gartner'ı n araştırmasına göre büyük işletmelerin plansız hizmet kesintilerinin saatlik maliyeti $42,000 civarı olmaktadır. Ponemon Institute bu değeri dakikada $5,600 olarak tespit etmiştir. InformationWeek de IT kesinti maliyetinin yılda $26.5 milyar gelir kaybına yol açtığını vurgulamıştır.

InternetWeek (4/3/2000) ve Fibre Channel tarafından yayınlanan bir kaç sonuca göz atalım:

2000 yılı	Saatlik Kesinti Maliyeti
Brokerage operations	$6,450,000.00
Credit card authorization	$2,600,000.00
Ebay (1 outage 22 hours)	$225,000.00
Amazon.com	$180,000.00
Package shipping services	$150,000.00
Home shopping channel	$113,000.00
Catalog sales center	$90,000.00
Airline reservation center	$89,000.00
Cellular service activation	$41,000.00
On-line network fees	$25,000.00
ATM service fees	$14,000.00

Ek olarak Dell'in bir açıklamasına göre 10 saatlik kesintilerinin bedeli $83 milyona, bir online komisyonculuk (simsarlık, brokerlık) firması olan eTrade'in açıklamasına göre ise 1 saatlik kesintilerinin bedeli $8 milyona tekabül etmekteymiş.

Siz de kendi işletmeniz için kesinti maliyetini hesaplayabilirsiniz. Bunun için basitçe şu formülü uygulayabilirsiniz: 

(Yıllık Brüt Gelir/Yıllık Toplam Çalışma Saati) x Kesintinin Etki Yüzdesi x Toplam Kesinti Saati

Veya bu konuda farklı parametrelerle çalışan hesap makinelerine İnternet üzerinden erişebilirsiniz. Ben birini kullanarak sizin için hesaplama yaptım. Sonuçlar şöyle :

http://downtimecost.com/

Bu hesaba göre yıllık $20 milyon dolar geliri olan 15 kişilik bir işletme dakikada $218, saatte $13 bin'lık bir maliyetle karşı karşıya kalıyor görünüyor.

Burada doğrudan parasal kayıp üzerine istatistikler verdik. Ancak tekrar hatırlatmak isterim müşteri memnuniyetsizliğinden ve imaj zedelenmesinden dolayı ortaya çıkacak dolaylı maliyetlerin acısı daha fazla olabilir. Güven giderse, pazar da para da gider.

Erişebilirlik Yüzdesi

Kuruluşlar hizmetleri kesintiye uğramadan, sistemin 24*365 çalışır durumda olmasını isterler. Ancak bu mümkün değildir. Yazılımsal, donanımsal beklenmedik hatalardan tutun da doğal felaketlere kadar bir çok sebeple plansız kesintiler olabilir. Bunun yanısıra zaman içerisinde bakım, güncelleme, yükseltme gibi planlı kesintiler de yapmamız gerekebilir. 

Sistemlerin hizmet verir durumda olduğu zamana uptime hizmet veremediği zamana downtime adı verilir. Downtimeın sıfır olması mümkün değil. Ancak sıfıra yaklaştırabilmek mümkün.

Sistemlerin hizmet verir durumda olduğu sürenin (Server Uptime) kalitesi yani erişebilirlikleri (Availability) yüzdelerle ifade edilir. 

Yaygın söylemleri aşağıdaki gibi bir araya getirebiliriz:

Dokuzlu Adedi	Erişebilirlik Yüzdesi	Yıllık Kesinti	Aylık Kesinti	Haftalık Kesinti
2 dokuzlu	99,00%	3,65 gün	7,30 saat	1,68 saat
3 dokuzlu	99,90%	8,76 saat	43,8 dakika	10,1 dakika
4 dokuzlu	99,99%	52,6 dakika	4,38 dakika	1,01 dakika
5 dokuzlu	99,999%	5,26 dakika	26,28 saniye	6,06 saniye

Tablodaki erişebilirlik yüzdelerine göz attığımızda herkesin gönlü 5 dokuzlunun performansından yana olabilir. Tabi ki bu performansın bir maliyeti var. Dokuz sayısı arttıkça birden fazla cihaz ve yazılım lisansı ihtiyacı ortaya çıkar. Dolayısıyla fiyat performans hesabını iyi yapmak ve optimum topolojiyi belirlemek gerekir. Aksi halde cihaz ve lisansa ödenen miktar kesinti halinde ortaya çıkacak olan kayıptan daha yüksek meblağlara ulaşabilir.

Erişebilirlik yüzdesini şu şekilde hesaplayabilirsiniz:

Erişebilirlik Yüzdesi = ([(Toplam Süre - Kesinti Süresi)]/Toplam Süre)x100

Bunu bir örnekle açıklayalım: haftada 2 saat, ayda 8 saat kesinti olmasına tahammül edilebilecek bir sistem için erişebilirlik yüzdesi şöyle hesaplanır: 

(8.760 - (8 x 12) / 8.760) x 100 = 98,9 (yani %98,9 erişilebilir bir sistem.)

(Not: 1 yıl yaklaşık olarak 8.760 saattir.)

Kesintiler ve Çözümler

Sistemin kesintiye uğradığı ana Felaket anı (Disaster Point) adı verilir. Eğer hiç bir önlem alınmadıysa felaket olup bittikten sonra yapacak pek bir şey yoktur. İlk iş elimizdeki yedekleri kullanarak sistemi biran önce en son çalışır olduğu noktaya geri getirmek olur. Bazen yedekleri kullanmak sistemi son çalışır olduğu noktaya kadar getiremez. Bazen felaketin türüne göre yedekleri kullanmadan da sistemi kurtarmak mümkün olabilir.  Bu noktada korkulan ve asıl sancılı olan veri kaybını sineye çekerek çok eski yedeklerden geri dönmek zorunda kalınan senaryolardır.

Eğer bir takım önlemler almışsak kesintileri sancısız atlatmak mümkün olabilir. Bu önlemler maliyetli olsa da kesinti zamanlarında problemleri bertaraf etmeyi oldukça kolaylaştırır. Çoğu zaman hiç bir müdahale yapmaya gerek kalmadan sistem kendi kendine, hissettirmeden, milisaniyeler içerisinde felaketi atlatır. 

Planlı ve plansız kesintiler olabilir. Bu kesintilerden önce alınacak önlemlere Yüksek erişebilirlik (High Availability) çözümleri, sonra yapılan müdahalelere de Felaketten Kurtarma (Disaster Recovery) çözümleri adı verilir.

Felaketten Kurtarma (Disaster Recovery) Çözümleri

Felaketin boyutuna göre çok çeşitli çözümler uygulanabilir. Korkulan çözümler yedekler kullanılarak uygulanan çözümlerdir. O yüzden yedeklere odaklanalım.

Yedeklerin bir şekilde bozulduğu durumlarda zaten yapılacak pek bir şey kalmaz. Yedeklerin kullanılabildiği durumlarda da bilinçsiz müdahaleler yüzünden kurtarılacak kısımlarda veri kaybı yaşanabilir.

Uzun uzun konuşmak mümkün ancak temelde üç şekilde veri kaybı yaşanır:

1. Önceden alınmış yedekler bozulmuş olabilir veya plansız alınan yedekler yüzünden yedekleme zinciri bozulmuş olabilir.
2. Veritabanına başarıyla kaydedilmiş ancak henüz yedeklenememiş bilgiler kaybedilebilir.
3. Sistem hizmet dışı iken gönderilen talepler yakalanamaz.

Yedekleme (Backup) ve yedekten dönme(Restore) konusu oldukça geniş. Bu yazımızda küçük ve önemli bir kaç ipucu verip geçelim istiyorum:

• Yedek alma planınızı optimize edin ve bunu dökümante edin. Full, Diff, Log, T-Log, Partial vs. yöntemlerini gerekirse harmanlayın. Yönetilebilir ve güvenli olsunlar. Bunun için şu soruların cevabını göz önünde bulundurun.
• RPO: Recovery Point Objective (Ne kadarlık bir zaman aralığındaki verinin kaybolmasını tahammül edebilirim?)
• RTO: Recovery Time Objective (Sistemi ayağa kaldırmak için ne kadarlık bir zaman aralığına tahammül edebilirim?)
• Yedeklerinizin bozulup bozulmadığını test ortamlarında geri dönüşler yaparak kontrol edin. Başırıyla dönülebildiği teyit edilmemiş bir yedek hiç alınmamış gibidir. 
• Yedeklerinizi üçüncü parti sıkıştırma yazılımları ile değil SQL Server'ın kendi sıkıştırma özelliği ile sıkıştırın. 
• Yedeklerinizin kopyalarını uzak lokasyonlara da alın. SQL Server ile aynı cihaz üzerinde duran yedeklere güvenmeyin.
• Belli aralıklarla test ortamlarında felaket senaryoları oluşturun ve pratik yapın. Sonuçları direktifler listesine dönüştürün. Bu gerçek bir problem esnasında soğuk kanlı ve idraki açık olmanızı sağlar. 

Yüksek Erişebilirlik (High Availability) Çözümleri

Felaket (kesintiler diye düşünelim) önce bir takım önlemler alınırsa hizmet kalitesinde hissedilir derecede bir eksilme görülmeyebilir. Buradaki çözümler birden fazla instanceın, yerine göre cihazın birlikte kullanımıyla ilgili çözümlerdir. Bu konuya ne kadar yatırım yapılırsa o kadar verim alınabilir. Ancak cihaz, lisans ve bakım maliyetleri göz önünde bulundurularak optimum çözümü belirlemek gerekir. Aksi halde yatırım anlamsız dahası zararlı olabilir.

HA çözümleri ciddi yönetim becerisi gerektirir. Fakat planlı ve plansız kesintileri de milisaniyeler seviyesine indirir, yedekliliği arttırır ve daha büyük problemlerle yüzleşme ihtimalini azaltarak işleri kolaylaştırır. 

SQL Server 2012 ve sonrasında şu HA çözümleri kullanılabilmektedir.

Resmi tıklayarak büyütebilirsiniz.

• AlwaysOn FailOver Cluster
• Birden fazla server için donanım bazlı bir çözüm sunar. 
• Instance (SQL Server kurulumu diyelim) seviyesindeki nesneler için erişebilirliği mümkün kılar
• Bir server aktif diğerleri yazma ve okumaya kapalı şekilde pasif modda durur.
• Aktif server kapandığında pasif olan diğer server otomatik olarak devreye girer.
• Serverlar veritabanının olduğu aynı depolama birimine bağlıdırlar. Depoalama birimi zarar görürse veritabanına serverlar üzerinden erişilemez. Bu sistemin zayıf tarafı disk hatalarıdır.
• Özel donanımlar ve yazılım gerektirdiği için pahalı bir çözümdür.
• Databases Mirroring
• Veritabanı seviyesinde bir çözümdür. 
• Veritabanının birden fazla kopyası tutulur. Biri arızalansa diğeri ile hizmet devam eder.
• Sistem senkron veya asenkron veri eşleştirmesi yapabilir.
• Otomatik veya manual görev değişimi (FailOver) yapılabilir.
• İkincil serverdan (Database Snapshots ile) raporlama amaçlı erişim sağlanabilir.
• Network yavaş ile özellikle senkron modda hizmet yavaşlar.
• Birden fazla veritabanı kopyası olacağı için daha fazla depolama alanına ihtiyaç duyulur.
• Log Shipping
• Fakir adamın mirroring yaklaşımı olarak ifade edilir.
• Birden fazla servera veritabanının kopyasını istenen gecikme süreleri ile göndermek mümkün olur.
• Farklı editionlarla birlikte çalışmak mümkündür.
• Temelde backup/restore planları ile çalışır.
• Otomatik failover özelliği yoktur. 
• Veritabanı kopyaları oluştuğu için daha fazla depolama alanına ihtiyaç duyulur.
• AlwaysOn Availability Groups
• Windows Cluster alt yapısını kullanan, Mirroring ve Log Shipping özelliklerini bir araya getiren SQL Server 2012 sonrası duyurulan bir çözümdür.
• Birden fazla veritabanını bir arada farklı serverlar ile eşleştirmek mümkündür. Log Shipping gibi birden fazla server arasında eşleştirme yapılabilir (SQL Server 2016 ile 9 servera kadar).
• Database Mirroring gibi senkron ve asenkron modda çalışabilir.
• Otomatik Failover desteği vardır. 
• İkincil veritabanları okumaya açık olarak tanımlanabilir. Böylece raporlama ve yedekleme iş yükü birincil sunucudan ikincil sunuculara dağıtılabilir.
• Replication
• Pek de HA çözümü olarak kabul edilmez. Daha çok veri senkronizasyonundan sorumludur.
• Kendi için de çeşitleri vardır. Konumuzla kısmen ilgilidir ancak çoğunlukla farklı başlıklar altında ele alınır.

Bu çözümleri aynı topolojide belli kurallar çerçevesinde birlikte kullanmak da mümkün.

Hepsini bir arada görelim (SQL Server 2012 bakış açısı ile) :

http://download.microsoft.com/download/0/F/B/0FBFAA46-2BFD-478F-8E56-7BF3C672DF9D/Microsoft%20SQL%20Server%20AlwaysOn%20Solutions%20Guide%20for%20High%20Availability%20and%20Disaster%20Recovery.pdf

Bu konuda SQL Server 2016'nın edition desteği de şöyle:

http://msdn.microsoft.com/en-us/library/cc645993(v=sql.110).aspx

Özetle;

Çoğu kuruluşun hayatı kesintisiz devam etmesi gereken kritik hizmetlere bağlıdır. Bu hizmetlerin devamlılığı için fiyat performans hesapları iyi yapılmış optimum sistemler kurmak gerekir. Hem felaketten önce alınacak Yüksek Erişebilirlik (High Availability) çözüm önlemleri hem felaketten sonra yapılacak Felaketten Kurtarma (Disaster Recovery) aksiyonları veritabanı yönetiminin titizlikle üzerinde durması gereken bedeli ağır konulardır. 

Bu konularla ilgili test ortamları oluşturmalı ve belli aralıklar muhtemel senaryolar üzerinde tatbikatlar yapılmalıdır. Bu tatbikatlardan acil durumlarda yapılacaklar listesi hazırlanmalı ve gerekli taraflar ile paylaşılmalıdır. Ve tabi ki belli aralıklarla stratejileri gözden geçirmeye devam etmek gerekir. Bu efor, veri kaybından doğan hasar giderilirken stres altında sarf edilecek eforun yanında hiç bir şey değildir.