Yüksek Hizmet Sürekliliği (High Availability)
Elime Blueprints of High Availability (Evan Marcus ve Hal Stern) 2nd Ed. adlı kitap geçti.
Buradan bazı kısımların özetini sizlerle de paylaşmak istedim.
Ayakta kalabilirlik (Availability) bizde ne yazık ki, çoğu kurum tarafından göz ardı edilir. Halbuki küçük işletmeden, devasa holdinglere kadar her tip kurum kendi ihtiyaçlarına uygun bir HA çözümüne sahip olmalıdır.
Önce temel kavramlar..
HA için ölçümlerden birisi 9 metodudur. Burada HA, yüzde olarak ifade edilir.
Servis sürekliliği yüzdesi, yıllık zamanın ne kadarında servis verileceğini belirtiyor. Mesela %99 HA demek, 365 günün %1'i kadar servis aksaması demek. Bu da yıllık 3.5 gün servis kesintisi demektir. Burada 9'ların sayısı önemli. En altta 6 adet 9, en büyük kurumlar için bile oldukça kabul edilebilir bir HA'dır.
%100 HA, ancak en karlı kurumlar tarafından düşünülebilr. Ve bu da uzun zaman dilimi içerisinde sağlanamaz.
HA'da Daha üst seviyelere çıkarken, maliyet hızla artar. Mesela %99 HA'ya sahip bir makineye (Fatih), yine %99 HA'ya sahip diğer bir makine (Yavuz) failOver küme olarak ekleniyor. Bu durumda küme sistemin HA'sı %99.99 olur. Çünkü Fatih makinesi zamanın sadece %1'inde çalışmayacaktır. Bu durumda Yavuz makinesi görevi devralır. Bu da %1x%99 olur. Yani 0.99.. Toplamda HA %99.99 olur.
Teoride boyle olurken gerçkte boyle olmaz. Küme sistemi failOver sırasında, kısa da olsa, bir süre çalışamaz durumda olacaktır. Ayrıca dışarıdan gelen hatalar (elektrik kesintisi, sistem odası soğutmasının yetersiz kalması vb) için de sistem korunmasızdır.
Gerçekte sistem bileşen zinciri oldugu için (uç birim, ağ, Sunucu donanımı, Veritabanı yazılımı) her birine ait Downtime toplanarak sisteme ait net HA hesaplanıyor.
downtime, tanım olarak bir bileşenin görevini yapamaması anlamına geliyor. Bunun sebepleri Dataquest/Gartner'a göre
Yazılım hataları ise çoğalacak gibi görünüyor. Çunku yazılım gittikçe daha karmaşık bir hal almakta.
İnsan hatalarının sebebi 2 tane
Bunu gidermek için teknik personel eğitime gönderilmeli ve sistem yapısı dokumante edilerek mumkun oldugunca basitlestirilmelidir.
Mesela MTBF 100,000 saat ve MTTR 1 saat ise. A %99.999 olur.
Bu demektir ki, parça 11 yıldan fazla ortalama ömre sahip olacak ve oluşan hata 1 saat içerisinde giderilebilecek
En sıktan daha az olana doğru
Çevresel ve fiziksel faktörler
Yöneticilere HA çözümlerini kabul ettirebilmek için onların dilinden konuşmak lazım. Yani felaket durumunun maliyetinden.
Doğrudan maliyet: Çalışamaz haldeki sistemin kullanıcıları iş yapamayacaktır. Bu durumda kayıp, yapılan işe göre değişir. Eğer sadece yazılım geliştirme faaliyeti yapılıyorsa, kayıp, geliştiricilerin boş kalmasıdır. Bu sürede onlara boşuna ödenen paradır. Eğer bir e-ticaret sitesiyse, o zaman diliminde yapılacak olan gelir kaybedilir.
Dolaylı maliyet: Müşteri tatminsizliği ve rakip şirkete kaçması olasılığı.Ayrıca şirket itibarı zedelenir..
Her sistem için Ayakta kalabilirlik seviyesi farklıdır ve böyle de olmalıdır. Mesela bir banka ile universite labı aynı HA'yı istemez. Bu durumda kullanılacak teknolojiler de farklı olmalıdır. Bunun için kitapta Availability Index öneriliyor.
Bu figürden çıkarabileceğimiz bazı sonuçlar şöyle:
Sistem normal çalışması sırasında, bilgiler yedeklenir. Fakat bu yedekleme belli zamanlarda (mesela her gece) yapılacağı için, felaket anına kadar olan veri kaybedilir. Ne kadar verinin kaybedileceği RPO (Recovery Point Objective) olarak bilinir. Bunu kısaltmanın yolu daha sık yedek almak veya kopyalama(replication) teknolojisine geçmektir.
Felaket olduğu andan itibaren, sistemin tekrar ayağa kaldırılmasına kadar geçen süre RTO (Recovery Time Objective) olarak bilinir. Mesela yedeklerden geri dönülecekse ve elde başka bir bilgisayar sistemi yoksa bu iş günler alabilir. Küme sistemlerde RTO, saniye/dakika seviyesine indirilebilir.
Tabii grafikten de görebileceğimiz gibi, ne kadar kuruş, o kadar köfte.
Buradan bazı kısımların özetini sizlerle de paylaşmak istedim.
Ayakta kalabilirlik (Availability) bizde ne yazık ki, çoğu kurum tarafından göz ardı edilir. Halbuki küçük işletmeden, devasa holdinglere kadar her tip kurum kendi ihtiyaçlarına uygun bir HA çözümüne sahip olmalıdır.
Önce temel kavramlar..
- Güvenilirlik (Reliability):
- Bir bileşenin beklendiği şekilde çalışmasını ifade eder. Yani hata yapmamasını
- Ayakta Kalabilirlik (Availability):
- Servisin sürekliliğini fade eder. Yani bir bileşen arızalansa bile servis keintisiz sürdürülmeye devam eder. Bunun için fazladan güç kaynakları ve fanlar kullanılabilir. Veya başka bir bilgisayar, küme teknolojisi sayesinde, arızalanan bilgisayarın görevini devralabilir.
- Çabuk İyileşen(Resilient):
- Bir sorun ortaya çıktığında, normal servise kabul edilebilir sürede geri dönmeyi ifade eder.
- Yüksek Ayakta kalabilirlik (High Availability -HA):
- Bilgisayar sistemlerinin, kurumun işleyişini kabul edilebilir biçimde sürdürebilecek şekilde çalışacağını ifade eder. Yüksek hizmet/servis sürekliliği, yüksek erişilebilirlik, yüksek bulunurluk (TDK sağolsun) gibi eş anlamlıları da var!
HA için ölçümlerden birisi 9 metodudur. Burada HA, yüzde olarak ifade edilir.
| Servis Sürekliliği % | Yıllık Kesinti | Haftalık Kesinti |
| 99 | 5250 dk (3.5 gün) | 100 dk |
| 99.9 | 525 dk (8.5 s) | 10 dk |
| 99.99 | 52.5 dk | 1 dk |
| 99.999 | 5 dk | 6 sn |
| 99.9999 | 30 sn | 0.6 sn |
Servis sürekliliği yüzdesi, yıllık zamanın ne kadarında servis verileceğini belirtiyor. Mesela %99 HA demek, 365 günün %1'i kadar servis aksaması demek. Bu da yıllık 3.5 gün servis kesintisi demektir. Burada 9'ların sayısı önemli. En altta 6 adet 9, en büyük kurumlar için bile oldukça kabul edilebilir bir HA'dır.
%100 HA, ancak en karlı kurumlar tarafından düşünülebilr. Ve bu da uzun zaman dilimi içerisinde sağlanamaz.
HA'da Daha üst seviyelere çıkarken, maliyet hızla artar. Mesela %99 HA'ya sahip bir makineye (Fatih), yine %99 HA'ya sahip diğer bir makine (Yavuz) failOver küme olarak ekleniyor. Bu durumda küme sistemin HA'sı %99.99 olur. Çünkü Fatih makinesi zamanın sadece %1'inde çalışmayacaktır. Bu durumda Yavuz makinesi görevi devralır. Bu da %1x%99 olur. Yani 0.99.. Toplamda HA %99.99 olur.
Teoride boyle olurken gerçkte boyle olmaz. Küme sistemi failOver sırasında, kısa da olsa, bir süre çalışamaz durumda olacaktır. Ayrıca dışarıdan gelen hatalar (elektrik kesintisi, sistem odası soğutmasının yetersiz kalması vb) için de sistem korunmasızdır.
Gerçekte sistem bileşen zinciri oldugu için (uç birim, ağ, Sunucu donanımı, Veritabanı yazılımı) her birine ait Downtime toplanarak sisteme ait net HA hesaplanıyor.
downtime, tanım olarak bir bileşenin görevini yapamaması anlamına geliyor. Bunun sebepleri Dataquest/Gartner'a göre
- %27: Yazılım
- %23: Donanım
- %18: İnsan Hatası
- %17: Ağ problemleri
- %8 : Doğal Felaketler
Yazılım hataları ise çoğalacak gibi görünüyor. Çunku yazılım gittikçe daha karmaşık bir hal almakta.
İnsan hatalarının sebebi 2 tane
- dikkatisizlik
- sistemin işleyişini tam anlamamak
Bunu gidermek için teknik personel eğitime gönderilmeli ve sistem yapısı dokumante edilerek mumkun oldugunca basitlestirilmelidir.
Matematiksel Olarak HA (sadece meraklısına)
A=MTBF/MTBF+MTTR- A (Availability):
- Ayakta kalabilirlik
- MTBF (Mean Time Between Failures):
- Hata yapma süresi veya ortalama ömür. Bu tıpkı ulkemiz için olan ortalama insan ömrüne benzer. Bileşen daha once veya sonra da bozulabilir. Eğer bir diskin MTBF degeri 100,000 saat ve sizin sistem odasında 100 adet diskiniz varsa, sistem odasında her 100,000 /100 yani 1000 saatte bir disk bozulmasıyla karşılaşmanız olasıdır. (Gerçekte disk bozulmaları çan eğirisi gibi MTBF sonlarına doğru yoğunlaşır.) Yani disk sisteminizin ömrü 1000 saate (41 gun) düşer
- MTTR (mean time to repair):
- Parçayı onarmak için geçen süre
Mesela MTBF 100,000 saat ve MTTR 1 saat ise. A %99.999 olur.
Bu demektir ki, parça 11 yıldan fazla ortalama ömre sahip olacak ve oluşan hata 1 saat içerisinde giderilebilecek
Hata Noktaları
DonanımEn sıktan daha az olana doğru
- Mekanik/ Dönen bileşnler: diskler, teyp sürücüleri
- Fanlar
- Güç kaynağı
Çevresel ve fiziksel faktörler
- Elektrik kesintisi
- Soğutma sistemi
- Yangın : Yangın sistemleri için Halon gazı kullanımı (Allah'a şükür) giderek azalmakta. neden diye merak ederseniz cevabı şu; Halon gazı, oksijenin yerini alarak yangını söndürüyor. yani ortamdan oksijen gazını uzaklaştırıyor. Fakat bu sırada ortamda insan varsa, havasızlıktan ölmesi kuvvetle olası. Yani sistem yöneticisi sistem odasını kurtarmak için girdiğinde halon gazı yüzünden ölebilir!
- doğal felaketler
HA Maliyet
Yöneticilere HA çözümlerini kabul ettirebilmek için onların dilinden konuşmak lazım. Yani felaket durumunun maliyetinden.
Doğrudan maliyet: Çalışamaz haldeki sistemin kullanıcıları iş yapamayacaktır. Bu durumda kayıp, yapılan işe göre değişir. Eğer sadece yazılım geliştirme faaliyeti yapılıyorsa, kayıp, geliştiricilerin boş kalmasıdır. Bu sürede onlara boşuna ödenen paradır. Eğer bir e-ticaret sitesiyse, o zaman diliminde yapılacak olan gelir kaybedilir.
Dolaylı maliyet: Müşteri tatminsizliği ve rakip şirkete kaçması olasılığı.Ayrıca şirket itibarı zedelenir..
Availability Continuum
Her sistem için Ayakta kalabilirlik seviyesi farklıdır ve böyle de olmalıdır. Mesela bir banka ile universite labı aynı HA'yı istemez. Bu durumda kullanılacak teknolojiler de farklı olmalıdır. Bunun için kitapta Availability Index öneriliyor.
Bu figürden çıkarabileceğimiz bazı sonuçlar şöyle:
- HA basamakları arası geçişte, yukarılara çıktıkça maliyet artıyor. Yani Güvenilir yedeklerden (Reliable Backups) Disk ve birim yönetimine (Disk and Volume Management) geçmenin maliyeti 1 birim ise, FailOvers'tan Replication'a gecmek >1 birim oluyor
- HA teknolojisi bir yığın teşkil ediyor ve bunları aşağıdan yukarıya doğru sırayla uygulamak daha mantıklı.
Bir felaket olduğunda nasıl bir senaryo yaşanır ?
Sistem normal çalışması sırasında, bilgiler yedeklenir. Fakat bu yedekleme belli zamanlarda (mesela her gece) yapılacağı için, felaket anına kadar olan veri kaybedilir. Ne kadar verinin kaybedileceği RPO (Recovery Point Objective) olarak bilinir. Bunu kısaltmanın yolu daha sık yedek almak veya kopyalama(replication) teknolojisine geçmektir.
Felaket olduğu andan itibaren, sistemin tekrar ayağa kaldırılmasına kadar geçen süre RTO (Recovery Time Objective) olarak bilinir. Mesela yedeklerden geri dönülecekse ve elde başka bir bilgisayar sistemi yoksa bu iş günler alabilir. Küme sistemlerde RTO, saniye/dakika seviyesine indirilebilir.
Tabii grafikten de görebileceğimiz gibi, ne kadar kuruş, o kadar köfte.
Yorumlar
Yorum Gönder