Fault Tolerance Senaryoları (High Availability – Yuksek Erişebilirlik Çözümleri)
Üstatlarımızın, bizden önce ki sisteme gönül veren, ömür adayan büyüklerimizin güvenlik ile ilgili olarak söylemiş oldukları temel söz ve ilk güvenlik temeli , mevcut sahip olunan datalarımızın Backup’ larını almaktır. Büyüklerimiz yavaş yavaş emekliye ayrılarak yerlerini bizlere, günümüz sistemcilerine devrettiler. Ve büyüklerimizin bizlere bırakmış oldukları bu temel felsefe aklımızda – zihnimizde barınmakta olup, hemen hemen her sistem dizaynımızda sürekli yer bulmaktadır. Mutlak suretle her projemiz içine bir backup çözümü barındırsakta bizler için öncelikli bir güvenlik çözümü değildir. Artık bir gereklilik – zorunluk haline gelmiştir.
Nedeni ise onlar ile birlikte güvenlik anlayışının ölçüleri değişmiş olmasından kaynaklanmaktadır. Üstatlarımızın bizlere göre yaşamış olduğu en belirgin sıkıntılar, sistemin çökmesi, çalışmanın durması, data kaybının yaşanmasıydı. Şimdiki sistemciler, onların yaşamış olduğu sıkıntıları günümüzde de yaşasak dahi, bizleri bekleyen daha çok gelişmiş problemler yer almakdır.
Internet dünyasının , günümüzde neredeyse zorunlu bir hal alması ve hemen hemen her ihtiyacımızın bu internet denen teknoloji ile yapılması, evlerimize ve hatta çocuklarımızın – bebelerimizin bir çok ihtiyacını dahi bu teknoloji ile görür hala gelmemiz, bunun yanında bir çok dez avantajı da yanında birlikte getirdi.
Intenet dünyasında, virüslerin, spamların, spy yazılımların ortalıkta çok rahatlıkla dolaşırken, kötü amaçlı yazılımcılar ortalıkta cirit atarken, bizler de büyüklerimizden gelen güvenlik aylayışını değiştirdik ve kendi, günümüzün gerektirmiş olduğu çözümleri güvenlik dalına soktuk, ve büyüklerimizin temel güvenlik anlayısını, güvenlik dalından çıkararak bir gereklilik olarak farklı bir çözüm olarak sunmaya başladık.
Bizler, günümüzün yeni sistemcileri Güvenlik anlayışımızı her ne kadar günümüz şartlarının gerektirdiği şekilde yapmaya özen göstersekte, büyüklerimizden , bizlere miras kalan backup çözümünü her zaman için kullanmaktayız.
Elbetteki bu çözümler günümüz şartlarına göre değişkenlikler göstermekte olup Cluster yapıları, Farmlar , Sistem odası ve Network alt yapımızda ki ürünler ile çeşitli dizaynlar ile yapımızı geliştirmekteyiz.
Bu saymış olduğumuz hiç bir teknoloji (Cluster, Farm, NLB ) ismi ne bir backuplama çözümüdür , nede bir güvenlik çözümüdür. Ama sistemin sürekliliğini ve kararlılığını sağlamak adına yapılması gereken zorunlu çözümlerdir.
Cluster Çözümleri ;
Büyümekte olan şirket yapımızda, sahip olduğumuz şirket uygulamalarında, networkumuz içinde bulunan kritik serverlarımıza uygulamış olduğumuz sistem teknolojisidir. Enterprise yapıların vazgeçilmez çözümlerinden bir tanesidir. Cluster çözümleri uygulama serverlarında desteklemektedir ki bu uygulama serverleri Database Serverlar, Messaging Serverlar, File Server ‘ lardır. Uygulama serverlarını Microsoft Server ailesi ürünleri içinde sadece Enterprise ve Datacenter ürünlerinde yapabilmekteyiz.
Cluster yapılarının çalışma mantığı, bir cluster grubu içinde bulunan en az iki ve daha fazla serverin, fiziksel olarak bağlı bulunmuş olduğu Shared Disk (Paylaştırılmış disk) üzerinde ki uygulama datalarını ortak olarak kullanılması ile çalışmaktadır. Cluster yapıları genellikle Failover için yapılmakta olup Microsoft Cluster (MSCS) yapıları Aktif – Pasif mod olarak desteklemektedir.
Yani uygulamalarımız Cluster yapısı içinde bulunan Master serverimiz üzerinde gerçekleşmekte olup, Master serverimiz ile cluster yapısı içinde bulunan diğer serverlarımız ile sürekli olarak iletişim halindedir. Eğer cluster içinde ki NOD’ lardan bir tanesi, uygulama veya bakım işlemi sırasında erişilemez duruma gelirse, bu hatadan kullanıcılarımız etkilenmeden Cluster içinde ki diğer NOD’ umuz derhal görevi üstlenmektedir. Kullanıcılarımız bu hatadan etkilenmeyecek / hissetmeyecek şekilde dizayn edilmiş yapılardır.
Cluster yapıları için, Shared diskler zorunluluk durumundadır. SCSI, ISCSI, FC ve SAS bağlantı teknolojileri ile ortak bir disk kullanmak zorunluluğu bulunmaktadır. Network yapımıza ve kullanmış olduğumuz bağlantı teknolojilerine göre farklı coğrafi bölgeler ile yapımızı, çözümümüzü genişletebilmekteyiz.
Network Load Balancing (NLB) Çözümleri;
NLB çözümü, fault tolerance teknolojisinin yanında performans için geliştirilmiş bir yuksek erişebilirlik teknolojisidir. NLB çözümlerini Servis bazlı çalışan serverlarda desteklemektedir. Microsoft server ailesinin hepsi Web Server, Standart Server, Enterprise Server ve Datacenter ürünlerinde yapabilmekteyiz. NLB teknolojisini uygulayabileceğimiz temel servislere Terminal Servis, Web Servis, Streaming Media Servis vb.. servislerde uygulayabilmekteyiz.
NLB teknolojisi ile hata anında servisin duraksamaması avantajını yaşadığımız gibi, performans içinde kullanabilmekteyiz. NLB servisi, arka tarafta DNS Servisini kullanarak, Farm içinde bulunan NLB serverlarının, o anki performans değerlerine göre mevcut yükü, yeni gelen isteği daha az performansta çalışan server üzerine pay ederek dengelemektedir.
FARM içinde bulunan NLB serverlarımızdan bir tanesi hatalı duruma düştüğü zaman, diğer NLB serverimiza/serverlarımıza gelecek olan istekleri yönlendirmektedir. Eğer NLB çözümünü fault tolerance mimarisi yerine performans için yaptıysak, kullanıcılarımız servis kesikliğini yaşamayacaklardır AMA uygulamalarını çalıştırdıkları zaman süresi içinde, hatalı serverın FARM içinde olmadığını hissedeceklerdir. Çünkü hatalı servera gidecek olan bağlantılarıda, sistemin sürekliliğini sağlamak adına çalışır durumda ki serverimiza yönlendirilecektir.
Cluster ve Nlb Teknolojisinin Yararları ;
High Availability : Turkçe karşılığı olarak Yuksek Erişebilirlik olarak çevirebiliriz. Bu demek oluyor ki sistem her durumda çalışmak üzere dizayn geliştirilmiştir. Çalışmış olduğumuz Uygulamalarımızı, servislerimizi birden fazla server üzerine yayarak, herhangi bir serverüzerinde oluşabilecek hatadan dolayı , çalışan sistemin etkilenmemsi için kullanılmaktadır.
Scalability : Türkçe karşılığı olarak Ölçeklendirilebilirlik, Genişletilebilirlik olarak çevirebiliriz. Cluster ve NLB yapıları, mevcut sistem üzerinde her hangibir değişiklik yapılamdan ve çalışan sistemin devamlılığını bozmadan büyütmemize olanak sağlayan özelliğidir. Sistemimiz çalışır durumdayken, Cluster ve NLB içinde bulunan NOD lardan herhangi bir tanesinin RAM, CPU vb.. parçaları üzerinde değişiklik yapmamıza imkan tanımaktadır.
Manageability : Türkçe karşılığı olarak yönetilebilirlik olarak çevirebiliriz. Geliştirilen Cluster yapıları içinde ki NOD larımızı yonetmemiz bu teknoloji ile çok kolay bir hal almaktadır. Cluster uygulamalarımızı sanallaştırma üzerine yoğunlaştırdıysak mevcut serverlarımızın imagesini almamız, backuplamamız çok daha rahat olmaktadır. Cluster veya FARM içinde bulunan NOD larımızı tek bir noktadan, merkezi olarak yönetmemiz gibi bir çok avantajları bizlere sunmaktadır.
Bu bölüme kadar anlatmış olduğumuz uygulamalar tamamen bilinen ve yapılan uygulamlar olup, Cluster ve NLB hakkında detaylı teknik bilgiyii portalımızdan ve bir çok erişim kaynağından edinebilirsiniz.
Bu bolumden sonra paylaşacak olduğumuz bilgiler Cluster ve Nlb çözümleri ile birlikte düşünülen, bilinen, yapılan uygulamalar olup Donanımdan bağımsız olan çözümlerdir. Yazımızın bundan sonra ki kısmı yazılımdan bağımsız olarak tamamen donanıma bağlı olarak mevcut hazırlamış olduğumuz Fault Tolerance alt yapımızın donanım tarafını inceleyeceğiz. Bu bolumden sonra ki paylaşacak olduğumuz bilgi tamamen Donanım, Elektirik, Network alt yapımızın Yuksek erişebilirliği ile alakalı olup Yuksek Erişebilirlik Senaryolarının bilinen diğer yüzünü paylaşacağım.
Daha önce ki IBM DS Storage makalelerimizde sürekli olarak, tüm donanım ekipmanlarımızın mutlak suretle bir yedeğinin olduğundan bahsetmiştik ve dikkatli okurlarımın gözünden kaçmayacak bir satırı bu makale için ip ucu olarak vermiştim. “ FAULT Tolerance için tek sıkıntımız elektirik kesintisinden başka bir şey olmayıp, storage bağlantı teknolojisi üzerine düşen bütün görevleri yaptırmış durumdayız” demiştik.
Yukarıda çizmiş olduğum diyagram genel olup, sistemin nasıl çalıştığını, hata anında nasıl bir yol izleyerek sistemimizin sürekliliğinin sağlandığını inceleyelim.
Elektirik Alt Yapımızın Dizaynı :
Günümüzün Sistem odası, Datacenter ürünleri genellikle Yedekli ürünlerden oluşmaktadır. Uygulama, Database vb.. server çözümleri içni geliştirilmiş olan bir çok server ve storage üzerinde her bir ekipmanın yedeği bulunmaktadır. Bu yedekli ürünlerin arasında Güç üniteleri de yer almakta olup REDUNDANT özellikli serverlar demekteyiz.
Redundant kelimesinin her ne kadar Türkçe karşılığı olarak Gereksiz, Luzumsuz, Aşırı fazla olarak kelime manası olmuş olsada, sistem dizaynımızı sağlıklı bir şekilde, olması gerektiği şekilde yapıldığı zaman ki durumlar da gerekliliğine değineceğiz.
Yukarıda ki Diyagramdan da anlaşılacağı üzere iki farklı fiziksel sunucumuz olup bunların üzerinde ki Güç üniteleri de ayrı ayrı olmak üzere iki tanedir. Redundant özelliğine sahip güç ünitelerimizi Power 1 ve Power iki olarak isimlendirdim. Yine serverlarımız altında bulunan Storagemiz Dual Controller özelliğine sahip olup iki farklı Güç girişine sahiptir. Bu Controller da Controller A ve Controller B olarak adlandırılmaktadır. Bu Güç girişlerini TEK bir UPS kaynağına bağladığımız zaman, olası bir elektirik kesintisinde tüm güç bu UPS’ imiz üzerine yuklenecektir ve UPS’ in verebileceği kaynak yeterli olduğu için zamanımız kısıtlı olacakıtr. Elbetteki Elektirik kesintisi yaşandığı zaman ve bu kesintinin uzun vadede olacağı düşünüldüğü zaman sistem sıralı bir şekilde kapatılarak güvenli duruma alınabilinir. Peki ama bu UPS’ imiz üzerinde oluşacak bir hatada, anlık olarak hiç beklemediğimiz bir zamanda UPS’ imiz hataya geçtiği zaman, elektirik beslemesini kestiği zaman ne olacak ? Cevap: Sistemimiz ani bir şekilde duracaktır. Sistemimiz bir anda düşecektir.
Fakat sistem dizaynımızı sahip olduğumuz Redundant özellikli serverların istemiş olduğu gibi şekillendirirsek türkçe karşılığı Gereksiz olan bir unitenin nasıl hayat kurtardığını görebileceğiz.
Elektirik aksamımız da olan bir hata. UPS’ imiz anlık olarak durdu ve beslemeyi kesti. Fakat bizler dizaynımızı olması gerektiği gibi yaptığımız için UPS’ den kaynaklı bir hata sistemimizi eklemediğini görebilmekteyiz. Senaryomuza göre Ana Beslemeden, Jeneratör’ den beslenen Server UPS 2 adlı unitemizde hata oluştu ve beslemeyi anlık olarak durdurdu. Fakar ortaamımızda bulunan Server UPS 1 üzerinde her hangi bir problem olmadığı için sistemimiz çalışmaya devam etmektedir.
Diyagramdan anlaşılacağı üzere Server UPS 2 adlı unitemiz, Nod 2 Serverimizin Power 2 adlı güç ünitesini , Storagemizin Controller B sini ve Nod 1 serverimizin Power 1 ini beslemekteydi. Server 2 UPS üzerinde oluşan bir hatada sistemimiz Server UPS 1 üzerinden hiç bir hata olmamış gibi çalışmaktadır. Server 1 UPS imiz NOD 2 serverimizin Poer 1 adlı güç ünitesine, Storagemizin Controller A sini ve NOD 1 serverimizin Power 2 adlı güç unitesini beslediği için sistemimiz olası bir UPS hatasından etkilenmemiştir.
Keza aynı şekilde, olası bir Güç ünitesi hatasında yani NOD 2 üzerinde ki Power 2 adlı Güç unitemiz, Power kablomuz da da bir hata oluşursa diğer unite ve elektirik kablosundan sistemimiz sürekliliğini devam ettirecektir. Bu hata Storagemiz içinde geçerli olup Controllerdan bir tanesi arızalanırsa sistemimiz diğer controller üzerinden çalışmaya devam edbilecek şekilde dizayn edilmiştir.
Redundant özelliğinin gerekliliğini bu senaryol ile kanıtlamış durumdayız.
Network Alt Yapısının Dizaynı :
Uç nokta olmayan Serverlarımız üzerinde bulunan NIC kartları iki tane olup, ve bu NIC kartları aynı donanım üreticisine ait ise ve Virtual NIC (TEAM) oluşturabilmekteyiz. Daha önce ki IBM X 3650 Server üzerinde BASP Virtual Adapter adlı makalemizde bu konuya değinmiş ve NIC kartlarımızdan bir tanesinde bir hata oluştuğu zaman diğeri üzerinde iş sürekliliğimiz devam etmişti.
Yine Diyagram daki Serverlarımızdan senaryomuzu anlatırsak, iki fiziksel NIC ama aynı ürün üreticisine ait iki tane NIC kartını, tek bir Virtual NIC haline dönüştürmüş durumdayız. Ve DMZ networkumuz içinde bulunan iki farklı SW’e ayrı ayrı bağlamış durumdayız.
Yapmış olduğumuz bu dizaynımıza göre kazancımız, DMZ SW1’ miz , ortamda hata durumuna düştüğü zaman sistemimiz DMZ SW2 üzerinden sürekliliğine devam etmektedir. Çünkü DMZ SW1’ Nod 2 serverimizin Fiziksel NIC 1’ ine , NOD 1 Serverimiz NIC 2’ sine bağlı durumdaydı. Storagenizin ise Controller A sina bağlı durumdaydı.
DMZ SW 1 üzerinde oluşan bir hatada, NOD 2 Serverimiz NIC 2 üzerinden, NOD 1 serverimiz NIC 1 üzerinden çalışmasına devam etmektedir.
DMZ SW 1 ve DMZ SW 2 adlı SW lerimizi, UPS 1 ve UPS 2 adlı güç ünitelerimize bağlayarak elektirk aksamında oluşabilecek olası bir hatayı da tolere etmiş olacağız.
Network dizaynımız için vermek istediğim diğer bir bilgi ise, Networkumuz içinde bulunan SW lerimizin bir birlerine olan bağlantılarıdır. Bir SW, diğer bir Sw ile Access (eski ismi UPLINK) yada Trunk hat olarak bağlanabilmektedir. Trunk hatlar ile mevcut iki SW arasında ki iletişim kuran portları yedeklemiş oluyoruz. Misal olarak SW 1 den, SW 2 ye 1 numaralı port üzerinden iletişim kurduk. Ve bu 1 numaralı porta herhangi bir arıza meydana gelirse, bağlantı kablosunda bir sıkıntı olursa artık iki SW arasında ki iletişim olmayacaktır. Bu sebepleren oturu SW1 ve SW2 üzerinde ki Port1 ilen olan iletişimi SW üzerinde olan diğer bir port ile TRUNK hat vasıtasıyla yedekliyoruz. Bu trunk hattımız iki SW arasındaki iletişimi kontrol ediyor ve Port/Kablo üzerinde olası muhtemel bir arıza durumunda devreye girerek sürekliliği sağlamaktadır.
Bu dizaynda bilinmesi gereken en önemli nokta, SW imiz Trunk hattı algılayabilecek bir SW değilse yani yonetilebilir bir SW değilse Networkumuzde LOOP’ un oluşması yuksek yüzdelikli bir olaydır.
Bütün bu dizaynlarımız, hata anında doğabilecek iş kesintileri vb. Amaçların hepsi Sistem odamız, Serverlarımız vb. Ürünlerimiz için geçerlidir. Makalemizde Dikkati edildiyse ve gerçek hayatta uygulanmalarına bakılırsa Uç noktada olan İstemcilerimiz için bu ve benzeri herhangi bir teknolojiler yapılmamaktadır. Clientlarımızda olabilecek arızlar ile client kullanıcımızın çalışmasını durdurmamak genellikle kurulan sistemlerde ön plana çıkmaktadır. Terminal Server uygulamaları, Folder Redirection ile yapılmış File Server uygulamaları , Softgrid tarzı yazılım, uygulama sanallaştırma teknolojileri ile son kullanıcılarımızın kullanmış olduğu bilgisayarlar, clientlarımızı bir Aptal terminale dönmesine, üzerinde veri bulunmamasına sebebiyet vermiştir. Ve böylesine dizayn edilen sistemlerde, dizayn edilen sisteme göre , kullanıcı tarafında oluşabilecek bir hata anında kullanıcı boşta bekleyen başka bir bilgisayar ile işlemlerini yapmaya devam etmektedir. Nedeni ise Datalar , her türlü hata anında çalışabilecek şekilde dizayn edilmiş olan datacenterlarımızda , sistem odalarımızın içindedir.
Fatih KARAALİOGLU
