Hatalar ve hataya dayanıklılık
Günlük hayatta, sistemlerin başarısız olma nedenleri hakkında daha çok geniş çerçevede konuşuruz. Genellikle oluşan durumların hepsini hata veya kusur diye adlandırırız. Ancak veri merkezinde profesyoneller bunlar için farklı karşılıklar kullanır. Hataya dayanıklılık tartışmalarıyla alakalı terimlerin kesin tanımları aşağıda verilmiştir:
Hata (bug), sistem davranışının, gereksinimlerden veya beklentilerden tutarlı şekilde farklılık göstermesine neden olan, sistem tasarımındaki bir anomalidir. Bu bir anlamda, sistemin veya yazılımın beklentileri karşılamaması olabilir, ancak hata (bug) bir sistem hatası değildir. Aslına bakılırsa çoğu hata (bug), sistemlerin amaçlananın aksine, tam olarak tasarlandığı şekilde performans göstermesinin sonucunda oluşur. Buradaki anahtar sözcük "tutarlı bir şekilde"dir. Bir hatanın davranışı sistemin tüm örneklerinde yeniden oluşturulabilir. Hata ayıklama (debugging), hataların (bug) ortadan kaldırılması için sistemi yeniden tasarlama işlemidir.
Hata (fault), sistemin, tasarımının aksi şekilde çalışmasına veya çalışmayı tamamen durdurmasına neden olan, sistemdeki bir anomalidir. Burada, sistemin tasarımında bir kusur olmayabilir, ancak bu tasarımın bir uygulamasında veya örneğinde sistem düzgün çalışmayabilir. Hata (fault), sistemin başka bir örneğinde yeniden oluşturulamayacak bir işleme yol açar. Bu tür bir hatayı (fault) ortadan kaldırma işlemine onarım adı verilir. Bir sistem hatası (fault) üç farklı şekilde kendisini gösterebilir:
Kalıcı hata, sorumlu bileşen tamamen değiştirilmeden nedeni giderilemeyen bir sistem kesintisidir
Geçici hata, nedeni onarılabilen veya düzeltilebilen ya da müdahale olmadan kendi kendine temizlenebilen, geçici olan ancak genellikle yinelenmeyen bir sistem kesintisidir
Aralıklı hata, genellikle bir bileşenin performans düşüşünden veya uygunsuz tasarımından kaynaklanan ve düzeltilmezse kalıcı bir hataya neden olabilecek, geçici olan ve genellikle yinelenen bir sistem kesintisidir.
Hata (failure), genellikle nedeni bilinmeyen bir hata (fault) ile tetiklenen, bir sistemin tümünün veya bir kısmının tamamen çökmesidir. Burada hata (fault) neden, hata (failure) ise sonuçtur. Hataya dayanıklı (FT) bir sistem, olumsuz koşullarda beklendiği şekilde veya hizmet düzeyi sözleşmesi (SLA) beklentilerine uygun şekilde çalışan ve bu nedenle hatalar (fault) olması durumunda hataları (failure) engelleyen bir sistemdir.
Kusur (defect), bir donanım bileşeni üretiminde veya yazılım bileşeninin örnek oluşturmasında bulunan ve büyük ihtimalle bunların çalışmasında hataya (fault) ve söz konusu bileşeni uygulayan bir sistemde hataya (failure) yol açan anomalidir. Bu tür bir anomali yalnızca değişim yoluyla düzeltilebilir.
Hata (error), istenmeyen veya hatalı bir sonuç üreten bir işlem sonucudur. Bilgi işlem cihazında hata (error), cihazın tasarımındaki bir hatayı (bug) veya uygulamasındaki bir hatayı (fault) belirtebilir ve bu, olası bir hatanın (failure) etkili bir göstergesi olabilir.
Hataya dayanıklı sistemlerin bakımı için bir BT uzmanı, yöneticisi veya operatörünün bu kavramları kavraması ve bunlar arasındaki farkları anlaması gerekir. Bulut bilişim platformu, tanımı gereği hataya dayanıklı bir sistemdir. Hataların (fault) olacağı tahminine dayanılarak tasarlanıp oluşturulmuştur ve hizmet hatasını (failure) engellemek için çalışır. Mühendislik açısından bakıldığında, “bulut” kavramı tam olarak dayanıklılık anlamına gelir. Telefon mühendisleri, sistem diyagramlarında ilk kez bulut şeklini kullandığında bu, görülmesi veya anlaşılması gerekmeyen, ancak hizmet düzeyleri yeterince güvenilir olduğu için diyagramda yer alması gerekmeyip bir bulutla kapatılabilecek ağ bileşenlerini temsil ediyordu.
Kurumsal BT ağı gibi bir bilgi sistemi, genel bulut platformuyla iletişim kurduğunda, bu platformun hataya dayanıklı bir sistem olarak çalışması gerekir. Ancak bu, kendisiyle iletişim kuran sistemi, halihazırda olduğundan daha fazla hataya dayanıklı hale getirmez, getiremez. Hataya dayanıklılık, bir sistemde hata (fault) olmayacağına karşı garanti veya hataya karşı koruma anlamına gelmez. Kısacası hataya dayanıklı bir sistem mutlaka hatasız olmak zorunda değildir. Hataya dayanıklılık daha çok bir sistemin hatalar mevcut olduğunda beklenen hizmet düzeylerini koruyabilme yeteneğidir.
Tüm bilgi sistemlerinin amacı, bilgileri kullanan işlevleri otomatikleştirmektir. Hataya dayanıklılık yalnızca sınırlı bir ölçüde otomatikleştirilebilir. ARPANET olarak vücut bulan İnternet’in asıl hedeflerinden biri hataya dayanıklılık sağlamaktır. Bir olağanüstü durumda, adresi artık ulaşılamaz olan bir sistemi atlamak için dijital iletişimler yeniden yönlendirilebilir. Ancak İnternet, kendi kendini koruyan bir makine değildir; aslına bakılırsa hiçbir bilgi sistemi böyle değildir.
Tüm bilgi sistemlerinin hizmet hedeflerini gerçekleştirip koruması için sürekli olarak insan çabası gerekir. En iyi sistemler, insan müdahalesinin ve düzeltmesinin kolay, hızlı ve plan doğrultusunda olmasını sağlar.
Bulut platformlarında hataya dayanıklılık
Dürüst olmak gerekirse, ilk zamanlardaki bulut hizmeti platformları, mimarlarının amaçladığından daha az hataya dayanıklıydı. Örneğin, bir müşterinin birden çok veritabanı örneği veya yinelenen önbellekler gibi kaynaklar için fazla alan sağlama yeteneğinin, yetersiz izleme ile karşılaşıldığında etkili olmadığı kanıtlandı; bu da bazen yedeklerin veya çoğaltmaların olağanüstü durumlarda kullanılamaz olmasına yol açtı. Üstelik fazla alan sağlama, bulut iş modelinin temel ilkelerinden biriyle de ters düşer: yalnızca ihtiyaç duyulan kaynaklar için ödeme yapılması. Bir kuruluş, birincil sanal makinenin çalışamaz duruma gelmesi halinde ek sanal makine örnekleri kiralıyorsa işletim maliyetinden tasarruf yapamaz.
Hataya dayanıklı bir sistem yedekliliğe izin vermez, ancak makul ve dinamik bir şekilde mevcut anın ihtiyaçlarına ve kaynak kullanılabilirliği sınırlarına göre ayarlama yapar. İstemci/sunucu çağında, hem yerel veri depolama alanı hem de bağlandıkları ağ depolama birimleri de dahil olmak üzere tüm sunucular periyodik aralıklarla yedekleniyordu. "Her şeyi yedekleme" başlı başına bir kurumsal etik haline geldi. Genel bulut hizmetleri hem uygun fiyatlı hem de pratik hale geldikten sonra kuruluşlar bunları "her şeyi yedeklemek" için kullanmaya başladı. Zamanla bulutun eski yöntemleri kalıcı hale getirmekten daha fazlasını yapabileceğini fark ettiler. Bulut platformları, uygulandıkları anda hataya dayanıklı olacak şekilde değil, başlangıçta hataya dayanıklılık için tasarlanmış olabilir.
Reaktif teknikler
Sistem ne kadar dikkatlice tasarlanırsa tasarlansın, hataya dayanıklılık büyük ölçüde, sistemin ve sistemi yöneten kişilerin bir hatanın ilk belirtisine ne kadar iyi yanıt verdiğine bağlıdır. Aşağıda, kuruluşların oluşan hataları azaltmak için kullanacağı bazı reaktif teknikler verilmiştir.
Önleyici olmayan iş geçişi
Önleyici olmayan iş geçişi tekniği, bir hata içerdiği bariz olan bir iş yükü için konağın, bu aynı iş yükünü barındırmak üzere yeniden atanmamasını sağlar. Bu avantaj ile, sistemin bir hata (fault) kanıtı olarak bir hatanın (error) yinelenen örneklerini toplayabilmesi (düzgün kaydedilmiş bir yolla izlenmesi daha kolay olabilecek) engelleniyor olabilse de, “iş” korunmuş olur.
Görev çoğaltma
Birçok dağıtılmış bilgi sistemi, aynı anda bir görevin birden çok örneğini (veya Kubernetes düzenlemesi için çoğaltmaları) çalıştırır. İlke temelli yönetim sistemleri, bariz veya şüphelenilen bir sistem hatası olması durumunda bir görevi çoğaltması için tetiklenebilir.
Denetim noktaları ve geri yükleme noktaları
En basit haliyle denetim noktaları ve geri yükleme noktaları, zaman içindeki çeşitli anlarda bir sistemin anlık görüntülerinin alınmasını ve geri yüklemenin gerekli olması halinde yöneticilerin belirtilen bir ana “geri alma” işlemi yapmasına olanak sağlanmasını kapsar. İşlemler söz konusu olduğunda; örneğin bir uygulama, bir birim olarak başarılı veya başarısız olması gereken bir veritabanında iki ya da daha fazla eylem (bir “işlem”) gerçekleştirdiğinde bu strateji daha karmaşık bir hal alır. Yaygın bir örnek olarak, bir hesaptan parayı alacak yazarken diğer hesaptan parayı borç yazan bir uygulama verilebilir. Finansal varlıkların oluşturulmasını veya yok edilmesini engellemek için bu işlemler bir birim olarak başarılı ya da başarısız olmalıdır.
İşlem yapılan bir denetim noktası kurtarma sisteminde, işlemlerin yakalanabilen kayıtları, bellekte bir işlem ağacında depolanır. Bir işlem sırasında belirli noktalarda, bunun kullandığı bellek kaynakları çoğaltılır ve bir geri yükleme havuzunda tutulur. Günlük analizinin büyük ihtimalle yazılım nedeniyle bir hatayı (fault) belirtmesi durumunda işlem ağacının çatalı oluşturulur, işlem durumu önceki bir noktaya geri döner ve yeni bir işlem denenir. Yeni işlem, hatalı bir işlemden daha iyi başarı üretiyorsa (örneğin, bir hata düzeltme testi temiz çıkıyorsa), eski işlem dalı ayıklanır ve ağaçta bu noktadan itibaren yeni dal izlenir; mühendisler buna bağlam değiştirme adını verir.1
Bu yöntemin gelişmiş bir sürümünde, işlem ağacının içinde bir izleme sistemi uygulanır; böylece bir hata yeniden oluştuğunda, sistem geriye dönük olarak işlem üzerinde çalışarak hatanın nedenini izleyebilir. Daha sonra hata tetiklenmeden önce uygun bir geri yükleme noktası veya “kurtarma noktası” seçebilir.[2]
Washington Üniversitesi’ndeki araştırmacılar ve Microsoft Research tarafından büyük veri akışlarının hataya dayanıklı şekilde işlenmesi için SGuard adlı başka bir uygulama oluşturuldu. SGuard, işleme sırasında veri akışlarının birkaç anlık görüntüsünün eşzamanlı yazılmasını zamanlamak için Hadoop Dağıtılmış Dosya Sistemi’nden (HDFS) yararlanır. Bu anlık görüntüler gerektiğinde küçük parçalara bölünerek bunun sonucunda akış işlemi de daha küçük segmentlere bölünür. Denetim noktaları, HDFS’de depolanır. Bu sistem, akış verileri işlemlerinin bir kaydını ve akış verilerinin birden çok uygulanabilir çoğaltmasını yüksek oranda dağıtılmış konumlarda koruma özelliğine sahiptir. SGuard’ı uygulamak için çok miktarda hazırlık çalışması gerekli olsa da, ana işlemi bir hata olayına yanıt olarak tetiklendiğinden bu, reaktif bir hataya dayanıklılık tekniği olarak değerlendirilir.3
Proaktif teknikler
Proaktif hataya dayanıklılık tekniği, herhangi bir hata mevcut olmadan önce uygulanır. Amacı koruyucu önlem sağlamaktır, ancak modern uygulamada bu bir mantradan çok bir yöntem haline gelmiştir. Şu anda modern bulut platformları tarafından kullanılan tekniklerden bazıları aşağıda verilmiştir.
Kaynak çoğaltma
Etkili bir kaynak çoğaltma stratejisinin anahtarı yalnızca "her şeyi yedeklemek" olmayabilir. Sistem analisti, bir sistemdeki hangi kaynakların (örneğin, veritabanı altyapısı, Web sunucusu veya sanal ağ yönlendiricisi) bir hata olayından sonra kendilerini geri yükleyebileceğini ve hangilerinin kurtarılamaz olabileceğini tespit edebilmelidir. Hataya dayanıklı bir sistemdeki ilk savunma hattı, akıllı çoğaltma olabilir.
Kaynak çoğaltmayı uygulamak için kullanılan dört genel strateji vardır; bunların tümü Şekil 1’de gösterilmektedir:
Etkin çoğaltma - Tüm çoğaltılan kaynaklar eşzamanlı olarak etkin olup her biri bağımsız olarak kendi durum verisini, başka bir deyişle çalışır durumda olmasını sağlayan yerel verilerini korur. Bu özellik, bir sınıfta çoğaltılan tüm kaynaklar tarafından bir istemci isteğinin alındığını ve tüm kaynakların bir yanıtı işlediğini belirtir. Ancak bu, yanıtı istemciye teslim edilen bu sınıfta atanan birincil kaynaktır. Birincil düğüm de dahil, bir kaynak başarısız olursa başka bir kaynak onun yedeği olarak atanır. Bu sistem, birincil ve çoğaltma düğümleri arasında işlemenin belirlenimci olmasını, başka bir deyişle, belirlenen bir yol haritasında birlikte gerçekleşmesini gerektirir.
Yarı etkin çoğaltma - Yarı etkin çoğaltma, etkin çoğaltmaya benzer; farkı, çoğaltma düğümlerinin istekleri belirlenimci olmadan veya birincil düğümle birlikte olmadan işleyebilmesidir. İkincil kaynakların çıktıları gösterilmeyip günlüğe kaydedilir ve birincil kaynağın hatası oluştuğu anda geçiş yapmaya hazır olur.
Pasif çoğaltma - Yalnızca birincil düğüm, istekleri işlerken diğer düğümler (çoğaltmalar), durumu korur ve hata oluşması durumunda birincil olarak atanmayı bekler. İstemcinin iletişim içinde olduğu birincil kaynak, tüm durum değişikliklerini tüm çoğaltmalara geçirir. Bir sınıfa ait olan tüm özgün kopyalar ve çoğaltmalar, bir grubun "üyeleri" olarak değerlendirilir ve bir üyenin başarısız olduğu düşünülürse (gerçekten başarısız olmasa bile) o üye gruptan çıkarılabilir. Pasif çoğaltma, normal çalışma sırasında daha az kaynak tüketse de, bir hata olayı sırasında gecikme veya hizmet kalitesi (QoS) düşüşü olasılığı vardır.
Yarı pasif çoğaltma - Bu yöntem, pasif çoğaltmayla aynı ilişki desenine sahiptir; tek fark, kalıcı bir birincil kaynak olmamasıdır. Bunun yerine, sırayla her bir kaynağa koordinatör rolü atanır; sıralama koordinasyonu, dönen koordinatör paradigması adlı belirteç geçirme modeli tarafından belirlenir.
Şekil 1: Çoğaltılmış bilgi sisteminde istemci düğümleri, birincil düğümler ve çoğaltma düğümleri.
Yük dengeleme
Yük dengeleyiciler, çeşitli istemcilerden gelen istekleri, aynı uygulamada çalıştırılan birden çok sunucu arasında dağıtarak iş yükünün dağıtımını yapar ve sistem bileşenleri üzerindeki stresi azaltır. Yük dengeleyici kullanmanın olumlu bir yan etkisi, bazılarının yanıt vermeyen sunuculardan trafiği otomatik olarak yönlendirmesi ve nihayetinde tamamen hata oluşma olasılığını azaltmasıdır. Yazılımın bir bulut platformunda (örneğin, mikro hizmetler) dağıtılmak üzere tasarlandığı daha modern modellerde iş yükleri ayrı işlevler arasında bölünür ve bunlar da eşit dağıtım ve orta düzeyli kullanım düzeyi elde edilmesi amacıyla sunucu tarafı işlemciler arasında dağıtılır.
Sanallaştırma (bulut bilişimin temel unsuru), işlemciler arasında daha eşit şekilde dağıtılmış iş yükleri sağlayarak bunların taşınabilir olmasını sağlar; böylece iş yükleri, onları en iyi şekilde kullanabilecek fiziksel işlemciye taşınabilir. Kapsayıcı kullanımı, sanallaştırılmış iş yüklerini sanal işlemcilerden ayırıp işletim sistemi kendilerine en iyi şekilde hazır olan sunucu düğümünde kalmalarını sağlayarak bu tekniği iyileştirir. Bu ilke, Kubernetes gibi sistemler tarafından gösterilen iş yükü düzenlemesinde kilit rol oynar.
Yenileme ve yeniden yapılandırma
Yazılım örneklerinin uzun süre boyunca dağıtıldığı bilgi sistemlerinde, bu yazılımın yeniden başlatılması gerekli olabilir. Önceki bazı bulut platformları, ne zaman yeniden başlatmanın gerekli olduğunu belirlemek için zaman içinde yazılım örneklerinin hizmet düzeylerini örneklemeye çalışıyorken sonraki oluşumlar, periyodik yeniden başlatmaları zamanlamanın daha kolay yöntemini hayata geçirmiştir. Bu yeniden başlatma aşamalarında, başlatma yapılandırma dosyaları, değişen sistem koşullarına göre veya başlatmadan sonraki olası bir hataya karşı hazırlıklı olmak için otomatik olarak ayarlanabilir.
Önleyici geçiş
Sanallaştırma ilk kez veri merkezlerinin ayrılmaz bir parçası haline geldiğinde, önleyici geçişin, belki de rövanşlı maça benzer şekilde, iş yüklerinin ataması işlemcilere döndürülerek, sunucu üzerinde oluşan stresin eşitlenmesi yöntemi olduğu varsayılıyordu. Bulut platformlarının, iş yüklerini sanal altyapı arasında yeterli sıklıkla yeniden dağıtması sonucunda bu yöntem gereksiz bir hale gelmiştir. Ancak çeşitli bilgi sistemlerindeki iş yükü stresini tahmin etmek için yapay zeka yöntemleriyle birlikte yakın zamanda yapılan tartışmalarda tekrar bu konu ele alınmıştır. Bu tür sistemler, daha kritik iş yüklerini, daha yüksek hata riski taşıdığı tahmin edilen sunucu düğümlerinden yönlendirmek için kendi kurallarını oluşturabilir.
Kendi kendini onarma
İçerik teslim ağı (CDN) veya sosyal medya platformu gibi yaygın olarak dağıtılan bir bilgi sisteminde, her bir sunucunun işlevleri, özellikle de farklı konumlarda veya veri merkezlerinde bulunan birden çok adres arasında dağıtılabilir. Kendi kendini onaran bir ağ, çeşitli bağlantıları düzenli aralıklarla trafik akışı ve yanıt hızı açısından yoklar (performans yönetimi platformu gibi). Her performans uyumsuzluğu olduğunda, yönlendiriciler şüpheli bileşenlerden istekleri uzaklaştırarak bu bileşenlerden trafik akışını durdurabilir. Daha sonra bu bileşenin çalışma durumu, hata işaretleri açısından test edilebilir. Ardından bu davranışın devam edip etmediğini görmek için bileşen yeniden başlatılabilir ve yalnızca tanılama bir hatanın yeniden ortaya çıkma olasılığı olmadığını gösterirse bileşen etkin duruma geri döndürülür. Bu tür otomatikleştirilmiş işlem tabanlı yanıtlama, yüksek düzeyde dağıtılmış veri merkezlerindeki modern bir kendi kendini onarma örneğidir.4
Barter tabanlı işlem zamanlaması
Bulut platformu (genel bulut tabanlı hizmetleri kapsar, ancak şirket içi altyapıyı da kapsayabilir), benzersiz şekilde kendi durumunu bildirme özelliğine sahiptir. Amazon 2009’da düzeltilmiş bir SaaS modelini uygulamaya başladığında, mühendisleri spot örneği zamanlama adlı bir kavram geliştirdi. Bu sistemde, müşteri adına hareket eden sessiz bir ara sunucu, belirtilen bir iş için kaynak gereksinimlerini tanıtır ve özellikle de bulut platformu genelindeki sunucu düğümlerinden bir tür teklif isteği yayınlar. Her düğüm, kendisi için zaman ve harcanan kaynaklar bakımından teklifin gereksinimlerini karşılayabilme yeteneğini bildirir. En düşük maliyetli teklifi veren, sözleşmeyi kazanır ve kendisine iş için spot örneği (SI) atanır. Bu zamanlama şekli şu anda Amazon Elastic Compute Cloud için bir seçenektir.5
Başvurular
Ioana, Cristescu. A Record-and-Replay Fault Tolerant System for Multithreading Applications. Technical University of Cluj Napoca. http://scholar.harvard.edu/files/cristescu/files/paper.pdf.
Sidiroglou, Stelios, ve diğerleri.ASSURE: Kurtarma Noktalarını Kullanarak Otomatik Yazılım Kendi Kendini İyileştirme. Columbia Üniversitesi, 2009.
Kwon Yong-Chul, ve diğerleri. Dağıtılmış, Çoğaltılmış Dosya Sistemi Kullanarak Hataya Dayanıklı Akış İşleme. Association for Computing Machinery, 2008. https://db.cs.washington.edu/projects/moirae/moirae-vldb08.pdf.
Yang, Chen. Docker Kapsayıcılarında Mikro Hizmetin Denetim Noktası ve Geri Yüklenmesi. School of Information Security Engineering, Shanghai Jiao Tong University, Çin, 2015. https://download.atlantis-press.com/article/25844460.pdf.
Amazon Web Services, Inc. Spot Instance Requests Amazon, 2020. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html.