Bir olağanüstü durum anında hizmetlerin normal veya kabul edilebilir bir seviyede sürdürülmesi beklenir. Böyle bir beklentinin karşılanması için üretim ortamının modellenmesinde bir takım hususlara dikkat edilmesi kaçınılmazdır. Tabii ki olağanüstü durumun tarifine göre öncelikler ve önemlilik sıralamaları ya da yöntemler değişkenlik gösterecektir. En genel tarifinde bir felaket anında bizden beklenen kullanılamaz duruma gelen bir Genel Merkez binasının bir olağanüstü durumda sunucu ve network altyapısıyla birlikte alternatif bir lokasyondan ayağa kaldırılmasıdır. Elbette sadece donanımların alternatif bir lokasyondan ayağa kaldırılması tek başına yeterli olmayacaktır. Çünkü donanımları kullanan personelin ve tabii ki donanımları ayağa kaldırmak için gerekli süreçlerin de hazır olması gerekmektedir. Kısacası bir felaket anında sistemin kabul edilebilir minimum düzeyde devam edebilmesi için sadece Bilgi Teknolojileri birimlerinin teyakkuza geçmesi yeterli olmayacaktır. Standartla belirlenmiş İş Sürekliliği (BS-25999) kavramının yukarıda da bahsedildiği gibi birçok saç ayağı bulunmaktadır. Bu yazıda İş Sürekliliği yaşam döngüsünde Bilgi Teknolojileri birimlerinin kullanabileceği enstrümanları ele alıp inceleyeceğiz.
Üretim ortamında uygulama, veritabanı gibi farklı rol ve özelliklere sahip sunucular bulunur. Bu sunucuların bir olağanüstü durumda alternatif bir lokasyondan ayağa kaldırılmasında bir takım gelişmiş özelliklerin ve yöntemlerin kullanılması kaçınılmazdır. Bir veritabanı sunucusunun felaketin oluşabileceği bir “t” anında üretim ortamı ile aynı yapılandırma ve veri düzeyinde hazır olması için yapılacak modellemede sistem mühendisinin üzerinde durması gereken en önemli faktörlerden biri senkronizasyonun ne şekilde yapılacağıdır. Örnek olarak bir SQL sunucunun uzak bir lokasyona yollanmasında Log Shipment yöntemi kullanılabilir veya bir enterprise kurumda verilerin SAN üzerinde tutulması tercih edilebilir. Doğal olarak SAN-to-SAN replikasyon ile verilerin uzak bir lokasyona yollanması da kullanılabilir bir yöntem olacaktır. Ama bu konuştuğumuz yöntemler veriyi karşı tarafa yollarken belki de resmin en önemli parçasını yani sık sık yamalar, service pack yüklediğimiz işletim sistemi değişikliklerinin alternatif lokasyona yollanmasını sağlamayacaktır. Böyle bir durumda da üretim ortamında bir SQL sunucunun “service pack” veya patch yüklemesinin alternatif lokasyonda da manüel yapılması kaçınılmaz olacaktır. Bu yöntem de insan faktörü sebebiyle bir “t” anında yapının birebir şekliyle alternatif lokasyona yollanmış olması gerekliliğini tehlikeye atacaktır.
Bahsi geçen manüel operasyonun insan faktöründen bağımsız bir otomasyona bağlanması için piyasada çeşitli çözümler bulunmaktadır. Bu çözümler donanımsal ve yazılımsal olmak üzere iki bölümde incelenebilir.
Yazılımsal çözümler
DoubleTake, PlateSpin, Softek gibi çözümler bu kategoride incelenebilir. Bu ürünlerin birbirlerine karşı avantaj veya dezavantajlarını karşılaştırmaktan ziyade bu çözümlerin çalışma mantıkları bu bölümde aktarılacaktır. Yukarıda isimleri zikredilen yazılımlar kuruldukları sunucunun istenilen disk bölümlerini istenilen bir başka platforma aktarabilirler. Bu şekilde fiziksel bir sunucunun tüm diskini sistem çalışır durumdayken bir sanal sunucu olarak bir başka lokasyonda oluşturabilirsiniz. Ve fiziksel yani master olan sunucuda yapılan tüm değişiklikler anlık olarak karşı tarafa aktırabilecektir. Burada bu aktarmanın istenirse İşletim sisteminin de yüklü olduğu bölümü de içerebileceği hususu önemli bir noktadır. Çünkü bir olağanüstü durumda master olarak kullanılan sunucuda yapılan İşletim sistemini etkileyen değişiklikler düzenli bir şekilde takip edilerek diğer lokasyona aktarılamazsa sistemin çalışırlığı veya düzgün çalışırlığı tartışmalı hale gelecektir. Genelde piyasada bir takım uygulamalar uygulamaların verilerini belirtilen lokasyona aktarırlar. Örneğin bir SQL sunucunun SQL datasını veya bir Exchange sunucunun Exchange verittabanını bu şekilde aktarabilirler. Fakat SQL tarafında yapılan bir takım değişikliklerin yine manuel olarak takip edilmesi gerekmektedir. Yani verinin güncelliği sağlanabilirken sunucuda yüklü uygulama güncelliğini yitirecektir. Özetle yazılımsal bir ürünle bir sunucunun bir lokasyondan bir başka lokasyona anlık olarak yollanması mümkündür. Bu türden bir ürün genel olarak aşağıda belirtilen üç ana senaryoda kullanılabilir. Bunlar;
a) Fiziksel sunucudan fiziksel sunucuya
b) Fiziksel sunucudan sanal sunucuya
c) Sanal sunucudan sanal sunucuya
Bu senaryoların her biri ayrı olarak veya birlikte bir proje içerisinde değerlendirilebilir.
Bahsi geçen senaryolarda kullanılmak üzere yazılımsal bir çözüm seçilirken bir takım hususların göz önünde bulundurulması gerekmektedir. Bunlardan belki de en önemlisi bu türden bir yazılımsal çözümün seçilmesi lisanslama maliyetini dikkate almanızı gerektirecektir. Çıkabilecek problemlerde hızlı destek alınabilmesi de sorgulanması gereken bir husustur. Çünkü bir yazılımsal problemde hiç bir üretici sınırlandırılmış bir zaman zarfında çözüm garantisi veremeyecektir. Örneğin yazılımdan kaynaklanan bir problemin 2 saat içerisinde çözülmesini hiç bir üretici garanti edemeyecektir. Bir olağanüstü projesinde bu türden bir verinin göz önüde bulunudurulması önemli olacaktır. Bir başka husus da eğer eşitleme senaryonuz fiziksel bir makinadan fiziksel bir makinaya senaryosuna uygunsa iki tarafta da bulunan sunucu bileşenlerinin birbirleriyle aynı özelliklerde olmasına dikkat edilmesidir. Piyasada bulunan bazı eşitleme yazılımları farklı fiziksel sunucularda da çalışabilmek için bir takım özellikler geliştirmişlerdir. Bu özellik sayesinde burada tamamen farklı sürücülere sahip sunucuyu karşı tarafta öncden belirtilen sürücülerle ayağa kaldırılması mümkün olacaktır. Elbette tavsiye edilenin aynı marka ve model sunucularla bu tür işlemlerin yapılması olacaktır. Sırası gelmişken bazı yazılımsal ürünlerde karşı tarafta oluşturulan sunucunun açılışta kullanacağı makina ismini, IP adresini dahi değiştirtmeniz mümkündür. Bir diğer önemli husus da master sunucunun üstüne karşı sunucuya veri yollamak üzere kurulan agent uygulamasının performans olarak verdiği stres iyi etüd edilmelidir.
Donanımsal çözümler (Boot from SAN)
Yukarıda anlatılan yazılımsal çözümlere alternatif olarak bir de donanımsal çözümler konuşulabilir. Bu çözümlerin en başında Boot from SAN kullanımı gelmektedir. Bu çözüm enterprise bir yapıda kullanılan SAN (Storage Area Network) üzerinde tanımlı bir LUN alanının işletim sistemi kurulumunda kullanılması mantığına dayanmaktadır. Bir başka deyişle sunucuların kullandığı diskler lokal değil de fiber olarak bağlı oldukları SAN üzerinde tanımlıdır. Böylece SAN üzerindeki bu diskler Sotage-to-Storage bir replikasyonla Olağanüstü Durum Merkezine yollandığında aynı marka/model donanıma bu disk tanımlandığında üretim ortamının birebir aynısı olan bir sunucunun “t” anında uzak bir lokasyondan çalışması sağlanmış olacaktır. Bu yazıda bu teknolojinin bir örnek yapılandırılması ele alınacaktır. Öncelik ile çalışma mantığı hakkında bir takım açıklamalarda bulunmak gerekmektedir.
Resim-1 Boot from SAN çalışması
Resim-1’deki şekil bir Boot from SAN yapısını anlatmaktadır. ServerA, ServerB, ServerC sunucularının boot edildikleri diskler bir storage ünitesinde konumlandırılmıştır. Verilerde storage ünitesinde bulunduğundan bu disklerin asenkron veya senkron bir replikasyon ile uzak lokasyondaki storage ünitesine yollanması, uzak lokasyondaki sunucuların üretim ortamıyla birebir aynı olacak şekilde çalışmasını sağlayacaktır. Burada dikkat edilmesi gereken önemli hususlardan birincisi mutlak suretle iki lokasyondaki sunucuların aynı marka/model olması gerekliliğidir. Storage üreticilerinin disk replikasyon yazılımları sektör sektör tüm değişiklikleri karşı tarafa yollamaktadır. Bir başka deyişle bu yazılımlar diskin üzerinde verinin ne olduğundan ziyade sektörel bazda değişikliklerin ne olduğuyla ilgilidirler. Bu sayede disklerde yapılan tüm değişiklikler replikasyon yönteminize bağlı olarak anlık olarak uzak lokasyona yollanabilecektir. Böylece bir “t” anında sunucuların aynı yapılandırma bilgileriyle uzak lokasyondaki Olağanüstü Durum Merkezinden çalışması sağlanabilmektedir. Şimdi bu yapının bir HP platformda kullanımının örnek yapılandırmasına geçeceğiz.
Boot from SAN yapısının bileşenlerini şu şekilde sıralayabiliriz;
a) Aynı marka/model sunucular
b) HBA (Host Bus Adapter)
c) SAN Switch
Sunuculara üzerlerinde takılı HBA kartları üzerinden fiber kabloyla SAN switch ismiyle adlandırılan network cihazlarında sonlandırılırlar. Yine storage cihazları da fiber kablolarla bu cihaza bağlanırlar. Bu ürünlerin birbirleriyle görüşebilmeleri için de bu SAN switch üzerinde bir takım işlemlere ihityaç duyulur. Elbette sadece bu yapılandırma yeterli olmayacak aynı şekilde storage ünitesinde ve sunucu tarafında da bir takım ayarların gerçekleştirilmesi gerekecektir. Bu yazıda bahsi geçen ortamda HP Blade sunucular kullanılmıştır. Blade yapısına özel olan Virtual Connect ayarları ve HBA ayarları ele alınacaktır.
Öncelik ile Boot from SAN ayarları için SAN Switch de “zone” ayarları, storage tarafında da Masking/presentation ayarları yapılmalıdır. İşletim sistemi ilk başta olmadığından sunucu açıldığında HBA dan SAN switch cihazına ve storage cihazına giden bir istek olmayacaktır. Bu sebeple HBA kartın WWN’leri buralarda görüntülenemeyecektir. HBA kartlarda WWN, ethernet teknolojisinde bulunan MAC adresine denk gelir. HBA kartlarının WWN’lerinin tespitini sağlamak için sunucu açılırken HBA kartın BIOS kısmına girilerek ((Resim-2). Ctrl+Q), fiber HBA’ler bulunur (Resim-8). Böylece SAN switch cihazında WWN adreslerinin görüntülenmesi sağlanır. Görünen WWN ile Zone tanımları yapılır. Yapılan Zone tanımlaması ile HBA kartların storage ünitesine erişebilmesi mümkün olur. Ama henüz HBA karttan bir istek gelmediğinden dolayı storage ünitesi tarafında da WWN görünmez. HBA kartın BIOS menüsünden fiber HBA tekrar taratıldığında storage tarafına istek gönderilmiş olacak ve WWN adresleri de görünecektir. Storage tarafında da WWN göründükten sonra LUN tanımlaması yapılır. LUN storage ünitesi üzerinde oluşturulmuş disk parçası olarak tanımlanabilir. Doğal olarak sunucunun hangi LUN’u kullanarak açılacağının belirlenmesi gerekmektedir. Bu bir PC’de sistemin hangi diskten boot edeceğinin belirlenmesi olarak düşünülebilir. Daha sonra HBA kartın BIOS’unda tekrar bir tarama daha yaptırılır. Buradan elde edilen disk bilgisi Blade sistemin Virtual connect profiline tanımlanacaktır. Profil tanımlanınca Profil baskın olur HBA kartın BIOS’unda tanımladığınız değerler başkada olsa Profil’deki bilgiler etkin olacaktır. Şimdi Qloqic marka HBA kartın üzerinde yukarıda kısaca değindiğimiz işlemlerin hangi menülerle gerçekleştirildiğine gözatalım.
Resim-2
Öncelik ile Sunucu açılırken CTRL+Q ile HBA kartın biosuna girilir (Resim-2).
Resim-3
Gelen ekranda HBA kartın üzerinde bulunan 2 porttan biri seçilir.
Resim-4
Port seçiminden sonra “Configuration Settings” menüsüne giriş yapılır.
Resim-5
Adapter Settings seçilerek giriş yapılır.
Resim-6
“Selectable boot enable” seçeneği Enable duruma getirilir (Resim-6).
Resim-7
“Selectable Boot” Enable duruma alındıktan sonra “Primary Boot Port Name,LUN” (Birincil açılacak sistem bağlantı adı) seçeneğinin üzerine aşağı yön tuşuyla gelinip Enter’a basılır. Böylece “Fiber Device” ekranına gelinerek tarama yapmak mümkün olur (Resim-7).
Resim-8
Ekranda varsa bulunan fiber cihazların listesi görülecektir. Henüz zone ve mask/presentation tanımları yapılmadıysa boş bir listeyle karşılaşılması normal olacaktır. Bu menüden ESC tuşu ile çıkılır. Bu yazıda SAN Switch ayarlarına değinilmeyecektir.
Resim-9
ESC tuşuyla bir üst menüye çıkılır.
Resim-10
ESC tuşuyla bir üst menüye çıkılır.
Resim-11
Değişiklikler kayıt edilir.
Resim-12
Kayıt işleminden sonra yine Select Host Adapter seçeneği seçilerek geri kalan diğer port için yukarıda yapılan işlemler tekrarlanır.
Resim-13
Resim-13’te görülen ekranda diğer port seçilir.
Resim-14
“Select Host Adapter” seçeneği seçilerek aynı işlem bu port için de yapılır. Şu ana kadar anlatılan işlemler sonucunda SAN Switch cihazında WWN adresleri görüntülecektir.
Resim-15
Aynı işlemler Storage ünitesinin de WWN adreslerini görmesi için bir kere daha yapılır. LUN tanımından sonra taratma işlemi bir kere daha yapılır.
Resim-16
Sonuç itibarıyla yukarıda anlatılan işlemler neticesinde SAN switch üzerinde sunucuya ait HBA kartın WWN adresleri görüntülenebilecektir. Bu sayede de switch üzerinde storage WWN adresi ile sunucu HBA WWN adresi arasında gerekli tanımlamalar yapıldığında sunucu storage ünitesiyle iletişime geçebilecektir (Resim-15)
Resim-17
Resim 17’de görüntülenen değerler bir yere not edilmelidir. Çünkü HP Blade Virtual Connect Manager sayfasında Profile tanımlamasında bu değerler “Target Port” değeri olarak kullanılacaktır (Resim-18).
Resim-18
Yukarıdaki adımların gerçekleştirilmesiyle sunucunun HBA kartının SAN switch üzerinde WWN olarak belirmesini ve yine daha öncden Storage Admin yetkililerinin oluşturduğu LUN biriminin HBA ile ilişkilendirilip sunucunun bu LUN biriminden boot edebilmesi ayarlandı.
Doğal olarak şu ana kadar anlatılanlar bir HBA kartına sahip sunucunun bir disk ünitesi üzerinden boot edebilmesi için gerekli ayarlardır. Elbette yukarıda anlatılamayan SAN Switch ve Storage ayarlarının da yapılması gerekmektedir. Burada farklı model ve marka ürünlerin yapılandırmalarının farklı olması sebebiyle sadece mantıksal olarak bilgiler verilmekle yetinilmiştir. Yine de özetlenecek olursa bu yapının kurulumunda HBA karta sahip bir sunucu, bu kartın bir fiber kabloyla bağlı olduğu SAN switch ve yine fiber ile SAN switch cihazına bağlı storage ünitesi gerekmektedir. Sunucu HBA kartının Storage kartıyla SAN switch üzerinden haberleşebilmesi için iki ürüne ait WWN ve port bilgilerinin SAN switch üzerinde ilişkilendirilmesi gerekmektedir. Öte yandan yukarıda da bahsettiğimiz gibi sunucunun HBA kartı ayarlarında storage ünitesine ait bilgilerin ilişkilendirilmesi yapılmalıdır.
Yazının devamında ise eğer Boot from SAN kurulumu bir Blade sistemde gerçekleştiriliyorsa enclosure içinde bulunan sunuculara atanacak profil ayarlarının da yapılması gerekliliğidir. Basitçe bu ayarlar yazının devamında anlatılacaktır.
Bir web browser ile HP Blade Onboard Admin konsoluna ait IP adresi yazılarak yönetim ekranına ulaşılır (Resim-19).
Kullanıcı adı ve parola bilgisi yazıldıktan sonra HP Onboard Admin ekranına login olunur .
Resim-19
Gerekli yapılandırmalarda bir sıkıntı yoksa Resim-20’de kırmızı ile işaretlenmiş Virtual Connect Manager linki tıklanarak yönetim konsolunun açılması sağlanır.
Resim-20
Belirtilen linke tıklandığında Virtual Connect Manager konsoluna ulaşmak için gerekli kullanıcı adı/parola bilgilerinin sorulduğu ekrana ulaşılır (Resim-21). Burada gerekli bilgiler girildiğinde “Profile” yapılandırmak için gerekli yönetim ekranına ulaşılır (Resim-22).
Resim-21
Resim-22
Yeni bir sunucu profili tanımlamak için Resim-22’de işaretli “Define Server Profile” linki tıklanır. Link tıklandığında Profil tanımlama sayfası açılır.
Resim-23
Profile Adı verilip, istenen network objeleri (VLAN) seçilir. Gerekirse bu networklerin hızları tanımlanır. Ardından çalışılacak SAN network seçilir. Server kapalı ise profili bir Bay’a assign edebilir. Fakat henüz WWN adreslleri beli olmadığı, zoneları ve mask/presentasyonu yapılmadığı için profile’ın böyle kayıt edilmesi uygunu olacaktır. SAN tarafındaki işlemler tamamlandıktan sonra Profile’ı assign etmek daha uygun olur.
Resim-24
Kayıt edildikten sonra çıkan ekranda profilin WWN ve MAC adresleri görülebilir. SAN ayarlarını yapıldıktan sonra sunucu kapalı durumdayken Profile Edit edilerek bir Bay’a assign edilebilir.
Mevcut profilin edil edilmesi istenirse Virtual server’a login durumdayken kırmızı ile işaretlenmiş “Assigned Server Profiles” linkine girilir (Resim-25).
Resim-25
Resim-26
Resim-26’da işaretle gösterilen linkten edit edilecek Profile üzerine gelinerek tıklanır. Açılan pencerede istenilen ayarları değiştirildikten sonra kaydedilerek çıkılabilir. Önceden Assign edilmeyen Profile sunucu kapalıyken Resim-26’da gösterildiği gibi bir Bay’a assign edebilir.
Resim-27
Target Port Name kısmına Resim-17’de gösterilen bilgilerin girilmesi gerekmektedir. Unutulmaması gereken Blade yapısında profil kısmında girilen bilgilerin sunucudaki ayarlara baskın olacağıdır. Sonuç itibarıyla bir Blade sistemin storage üzerinden boot edebilmesi için gerekli temel yapılandırma profil ayarlamasıyla tamamlanmış olmaktadır.
