Çözüm Park’da Selim Bey tarafından yazılan HP serverin montaj makalesine ilave olarak IBM in x3650 serisi server’in ekstra donanımları ile birlikte montaj aşamalarını görelim istedim. IBM server sipariş ettiğinizde hangi modelse o modelin default donanımları ile gelir. Siz ihtiyacınıza göre ekstra donanımları ibm’in configurator programı ile cihazın modeline ve özelliklerine göre belirlersiniz.

Server üzerinde tek cpu ve 2GB Ram le birlikte geldi. İlave olarak 2. CPU, 32 GB Ram, 15000 Rpm’lik iki SAS disk (Raid 1 için), Storage (IBM DS4700 model 72) bağlamak için 2 adet HBA kartı, uzaktan yönetim için 1 adet Remote Supervisor Adapter ( RSA II) Kartı, ikinci bir power supply (redundant için). Bu kadar ilave donanıma ihtiyaç duyulmasının sebebi server’in üzerinde sanal makineler koşmasını planladığımız için.

Şimdi sırası ile IBM x3650 server’inin ve ilave donanımların kutulu halleri ile kutusundan çıkan orijinal hali ve aparatları ile ilave alınan donanımları ve bunların montaj aşamalarını birlikte göreceğiz.

Yukarıda Server kutusu ve kutusunun üzerin’de ise ilave donanımlar görülmekte.

Yukarıda 2. CPU, SAS Disklerimiz ve redundant powersupply görülmekte.

Yukarıda; Serverimizi storageye bağlamak için ve yedekli olması için 2 adet HBA

Uzaktan yönetim için RSA.II kartımız

32 GB olan Ram’lerimizin 8 GB lik modülü

Server kutumuzu açtığımız da yukarıda görüldüğü gibi bir şase ve 3 adet kutu çıkar. Bu kutulardan uzun olanında rack kabinete bağlantı aparatları, Ortanca olanda serverin arkası ve kabinete bağlanan kablo organizer’i küçük kutuda ise kablo ve kabloyu düzenleyen aparatlar bulunmakta. Kutunun içindekiler aşağıdadır.

Bu resimde ise server şasemiz ile ilave aldığımız donanımlar görülmektedir. CPU, HBA, RSA II, SAS Disk RAM ve powersupply ve tabiî ki extra takılan donanımlardan oluşacak olan ısı artışı için ilave fan’lar

Serverimizin kapağını açtığımızda karşımıza çıkan görüntü yukarıdaki gibidir. Ram slotlarının üzerinde bulunan metal aparat Riser Card tır. Default olarak serverin 4 adet PCI-Express slot u vardır bunların ikisi Riser Cardın üzerindedir. Bizde HBA larımızı Riser cardı n üzerine takacağız. Ayrıca ve RAM lerin hangi sıra ile hangi slotlara takılacağını gösteren bir diyagram mevcuttur. Ram ler ilk DIMM den başlayıp artan sıra ile takılmaz. Kaç adet ram modülü kullanacağımıza göre DIMM sıraları değişir

HP de olduğu gibi IBM serverinde üst kapağının alt kısmında bir diyagram mevcuttur. Bu diyagramda Ana kartın üzerinde bulunan bileşenler, CPU nun nasıl takılacağını, disklerin nasıl takılacağı, fanların yerleşimi, Ram DIMM lerinin sırası vs gibi ayrıntılar vardır.

Riser Cardı mızı söktük;  2.CPU umuzu, Ram lerimizi RSA II kartımızı ve redundant soğutucu fanlarımızıda monte ettikten sonraki görüntü bu şekildedir. CPU yu, RAM leri ve diğer bileşenleri yönergeleri okuyarak kolayca takabilirsiniz.

Serverimizi storageye bağlamak için gerekli olan HBA larımızı (yedekli olması için 2 adet) Riser Card’ın PCI Express slotlarına şekilde görüldüğü gibi takıyoruz. Daha sonra serverimizin kapağını kapatıp rack kabinete monte ediyoruz

Rack kabinete monte ettikten sonra SAS disklerimizi takıyoruz. Disklerimiz ayrı kutuda gelmişti. Disklerimiz Hot Plug olduğundan her hangi bir kablo bağlantısına ihtiyaç duymuyoruz buna benzer tüm yapılarda olduğu gibi. Kızaklı bir yapıya sahip mandalları yardımıyla yuvaya yerleştirip kilitliyoruz. Serverin üzerinde sadece işletim sistemi koşacağı için güvenlik amaçlı Raid 1 kuracağız. Kurduktan sonra storage’ye bağlayarak sanal işletim sistem bilgileri storage’de tutulacak. İstenirse bu konuda da makale yazabiliriz

Redundant power supply i de takıyoruz. Kritik uygulamaların çalıştığı yapılarda böyle bir estra güvenliğe ihtiyaç duyuyoruz. Her iki power in enerjisini farklı kaynaklardan sağlıyoruz. Ya iki ayrı güç kaynağı yada biri şebeke diğer güç kaynağı şeklinde. Powersupply lerimizden biri bozulduğunda yada enerji kaynaklarımızdan biri devre dışı kaldığında sistem ayakta kalmaya devam edecek.

Üst resimde RSA II girişimiz ve HBA girişleri görülmekte HBA lar fiber kablolar yardımı ile storageye bağlanmış durumdalar. Redandunt olması açısından çift kart kullanmıştık. Her iki HBA’yı iki farklı  SAN switch e bağlıyoruz. Bu kartların konfigürasyonu için IBM in SUNSurfer yazılımını kullanıyoruz.  RSA Girişimize takılan bir network kablosu yardımı ile bu kartın konfigürasyon menüsüne erişebilir ve gerekli ayarlamaları buradan yapabileceğimiz gibi Server’in açılışında setup’a girip benzer konfigürasyon menüsünden interface bilgilerini yada gerekli bilgileri değiştirebiliriz. İstenirse bu kartların ayarlanması ve kullanımı hakkında bir makale yazabilirim. Tek PS ile server üzerinde 5 tane soğutucu fanı gelir. İlave PS takıldığı zaman, redundant PS ile çalışmak üzere ilave 5 tane daha fan gelmektedir.- ve Redundant PS ler ile Fanlar birlikte entegre olur. PS takıldığı zaman fan sayısı 5 e tamamlanmazsa serverin ön panelinde ki dash
boardda uyarı belirecektir. Server üzerinde gelen 5 fan, diğer olması gereken ancak olmayan fanların yerine de performans harcar.

Serverimiz çalıştırılmaya hazır bir durumda. Serverimizi çalıştırdığımızda ön panelinde bulunan gösterge (light path)   yardımı ile serverdeki problemler hakkında gerekli uyarıları ledler yardımı ile alırız. Eğer bir sorun yoksa serverimiz çalışacaktır. Kurulum ve Raid ayarlamaları için serverle birlikte gelen Server Guide Setup ve Installation cd’sini takıp serverimizi çalıştırıyoruz.

Kamil ONAT

Ü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

IBM DS serisi tüm storage’lar, sahip oldukları karmaşık ve zor donanım altyapısına rağmen oldukça kullanışlı ve basit bir ara yüz ile yönetilebilmektedirler.  Önceki bölümlerde DS 4800’ün teknik özelliklerini ve sunucu bağlantılarını detaylı olarak incelemiştik.  Bu bölümde artık DS 4800 Storage’in yönetim arabiriminde ayarların yapılandırılmasını, host tanımlarını, raid array tanımlarını, disk LUN tanımlarını ve bu LUN’ların host’larımıza map edilmesini adım adım anlatacağız. Önceki bölümlerdeki anlatımlarımızdaki tüm teorik bilgiler artık burada uygulama katmanında görülebilecektir.

Yüklemesini yazı dizimizin ikinci bölümündeki gibi yaptıktan sonra Storage Manager Client yazılımı ilk çalıştırıldığında aşağıdaki gibi bir pencere gelecektir. Burada öncelikle disk storage’imizi yönetebilmemiz için programa tanıtmamız gerekmektedir.  “automatic” seçeneği ile otomatik olarak arama yaparak bulmasını sağlayabiliriz. Bunun için önceden storage’in network kablosunun takılı olması

gerekmektedir.   

Network üzerinde aradığı ve bulduğu disk sistemlerini yönetebilmemiz için sol tarafa atacaktır. Bulunan disk sistemine aşağıdaki resimdeki gibi üzerinde sağ tuş yaparak yönetimine başlayabiliriz. 

 
Konsol ekranında yönetmek istediğimiz storage sistemini seçerek “manage storage subsystem” ulaşılabilmektedir.

Kullanılan konsol Client programı storage bağlanacak ve storage’ın tüm yapılandırmayı karşımıza getirecektir,  bir sihirbaz ile en çok ihtiyaç duyulan işlevlere kısa yoldan ulaşmayı sağlayacaktır. İşlevler operatör tarafından elle yapılabileceğinden bu pencere çok sık kullanılmaz, kapatarak geçilebilir.  Karşımıza aşağıdaki gibi, storage’in tüm bilgileri gösteren pencere gelecektir. Buradaki örnekte görmekte olduğumuz, sol tarafta 1.36 TB’lik tanımlanmamış toplam alan ve daha önce tanımlanmış olan 5 raid array görülmektir. Yeni bir ünite için sadece toplam boş alan görülecektir. Pencerenin sağ bölümünde depolama ünitemizin tüm detaylarını görebilmekteyiz. Üst bölümde A ve B kontrol üniteleri görülmektedir, yan tarafta View butonuna basarak kontrol ünitesinin detayları görülebilmektedir. View’da bizim için önemli olabilecek detaylar; kontrol ünitesinin bataryası, ısı durumu, fan durumu, firmware bilgileridir. Uzun süreli bir elektrik kesintisinde (cihazın kapalı kalması durumunda) raid bilgilerinin korunması için içirisindeki batarya önemlidir. Hemen alt bölümde Kontrol ünitelerine bağlı olan disk çekmecelerini görebiliyoruz. Bu expansion unit’ler içerisindeki enclosure’lara diskler takılı durumdadır. 3 adet disk ünitesi görülmektedir. Bu disk ünitelerinde dolu olan slotları koyu olarak gorülmektedir, slotların en sağındaki + işaretli diskler hotspare olarak seçili olduklarını ifade etmektedir. Pencerenin üst bölümündeki menüler yer almaktadır. Bu menüler ile tüm işlevleri yapmak mümkündür. 

Adım Adım Yapılandırma

1. Raid Array tanımı: boş disklerin seçilerek raid yapısının oluşturulması
2. Logical Drive tanımı: raid array içerisinde fiziksel disk tanımlanması
3. Host tanımı: FC HBA’lar ile Storage’a bağlı server’ların Storage’a tanıtılması
4. Lun Mapping: Oluşturulan fiziksel disklerin server’lara local disk olarak map edilmesi  

Storage’lar üzerinde en çok ihtiyaç duyulan özellikler bunlardır. Operatör seviyesinde sizlerin en çok ihtiyaç duyabileceğiniz özellikler bunlardır. 

Raid Array tanımı :  Boş olan tanımlanmamış disk alanı seçilerek üzerinde sağ tuş yaparak yada üst bölümdeki Array menüsünden create seçeneği ile başlatılacak 3 adımlık bir sihirbaz ile array tanımı yapılabilmektedir. Öncelikle oluşturacağımız raid array’a karışmaması için isim vermemiz gerekmektedir. Client yazılımı otomatik olarak bir sayı atamaktadır, istenirse 30 karaktere kadar isim girmek mümkündür. Sihirbaza devam edildiğinde sonraki adımda raid seviyesini belirlememiz gerekmektedir.  0,1,3,5 vb. raid seviyelerinden istedilen seçilerek finish butonu ile raid array tanımlaması başarı ile tamamlanacaktır. Adım adım resimler aşağıdaki gibidir.

Logical Drive tanımı: boş kapasite içerisindeki disklerden Raid Array tanımlaması yapıldıktan sonra bu raid array’i içerisinde fiziksel disk tanımları yapabiliriz.  Logical Drive menüsü altından create seçeneği ile yapabileceğimiz gibi( aşağıdaki resimdeki gibi) sol tarafta oluşturduğumuz raid array içerisindeki “free capacity” seçili iken sağ tuş seçeneğinden de ulaşabiliriz. Birkaç adımlık bir sihirbaz başlayacaktır. Birinci adımda fiziksel diskin boyutunu belirliyoruz, sonraki adımda bu diskin kullanılacağı ortamda nasıl bir yapı olduğu seçilmelidir. Burada çok önemli olan, disk eğer bir cluster ortamında kullanılacaksa burada seçilmesi gerekmektedir. Eğer bir cluster ortamında kullanılmayacaksa non-clustered olarak seçilmesi gerekmektedir. Aradaki fark, disk bu seçeneğe göre yapılandırılacaktır. Cluster sistemler için diskin tanımlanmasını sağlamaktadır.

Bir storage üzerinde tanımlayabileceğiniz logical drive sayısı storage ile birlikte aldığınız partition lisansı ile sınırlıdır. Dolayısı ile raid array’leri içerisinde oluşturacağınız fiziksel disk adedini iyi belirlemeniz gerekmektedir.  

Logical Drive oluşturma için, free capacity seçili iken menüden create seçeneğini seçebilirsiniz. 

Sihirbazın ilk adımında disk için istediğimiz boyutu belirlememiz gerekmektedir. Array içerisinde birden fazla logical drive tanımlayabilirsiniz. ( raid array’iniz seçtiğiniz diskler ile belirlediğiniz seviyede bir raid oluşturur, bunun altında oluşturacağınız logical drive’lar birden fazla olabilir. Burada önemli olan tek husus, storage üzerinde oluşturacağınız toplam logical drive sayısı, ünite ile birlikte aldığınız partition lisansını geçemez.) 

Sihirbazın son adımında oluşturulmakta olan drive’in bağlanacağı server’da ne tip kullanım olacağıdır. Yukarıda örnekte biz Windows platformu ve non-Clusterd olarak seçtik. Ve herhangi bir sunucuya daha sonra map etmek üzere Map later seçeneği ile logical drive oluşturmasını başarı ile tamamladık.

Host Tanımı: Storage-Server arasında FC HBA’lar kullanarak yapılan FC bağlantısının ardından server’ların storage üzerindeki diskleri kullanabilmeleri için storage’a host olarak tanıtılması gerekmektedir. Bunun için üstteki menülerden Mappings altından yada Mappings View pencere sekmesinde Storage Subsystem üzerinde sağ tuş DefineàHost seçenekleri ile yapılabilmektedir. Birkaç adımlık bir sihirbaz başlayacaktır. 

�

Birkaç adımlık bir sihirbaz başlayacaktır. Bu sihirbazda ilk adımda aşağıdaki gibi bir pencere gelecektir. Buraya dikkatle bakıldığında sol alt bölümde Know HBA host port identifiers altında storage’in gördüğü FC bağlantıların port ID’lerini görebilmekteyiz. Storage’lar üzerinde en dertli konulardan biri olan Host tanımlarında burada çok dikkat etmek gerekmektedir. Bu know HBA host port identifers altında hangi portun hangi server’a ait olduğunu sunucu üzerinde kuracağınız SanSurfer yazılımı ( ikinci bölümde yer almaktadır.) ile öğrenebileceğimiz gibi, genelde FC HBA kartların üzerine de fiziksel olarak etiketle yapıştırılmaktadır. Zaman zaman storage’lar bu bölümde FC HBA’lar port identifer bilgilerini yakalayamayabiliyor.Bu durumda port bilgisini sansurfer ile öğrendikten sonra bu pencerenin sağ alt bölümündeki NEW butonu ile elle eklememiz gerekmektedir.  Port Identifier bilgisini new seçeneğinden elle girerken yada otomatik bulduğu listeden seçerken server’a bir isim girilmesi gerekmektedir. Host name bölümüne istediğimiz ismi girebiliriz. Server’i ifade edeceğinden belirgin bir isim girilebilir. HBA port’u seçilirken bir sunucuda birden fazla HBA farsa bunların hepsi bu pencerede hostta ADD seçeneği ile yada NEW seçeneğinden elle eklenebilmektedir.  İkinci bölümde yer alan FC HBA modellerinden eğer çift kart kullanılması durumunda bu kartlar tek bir hostta tanımlanabilmektedir. 

Yukarıdaki ekranda görüldüğü gibi önce Host name’dan sunucumuz için anlaşılır bir isim giriyoruz, sol alttan port identifiers’tan portu seçerek ADD tuşu ile sağ tarafa geçiriyoruz. Eğer burada sunucumuzun port bilgisini göremiyorsak, sağ taraftaki NEW seçeneği ile portu 16 karakter olarak ( HEX) elle tanımlayabiliriz. 

Logical Disk Lub Mapping: Yukarıda diskleri seçerek raid array tanımı, bu array içerisinde logical drive tanımı, logical array’ı server’a bağlamak için server’in storage’a host olarak bağlanmasını uygulamalı olarak gördük. Şimdi tüm bunları yaptıktan sonra oluşturduğumuz fiziksel diski server’a bağlayarak operatör işleminin tamamlanması kaldı. Fiziksel diski server’a bağladıktan sonra artık Windows işletim sisteminde Disk yönetimini açarak Rescan işlemi yaparak diski görmesi sağlanacaktır. Logical diski host’umuza bağlamak için Mapping menüsü altından Define seçeneğini kullanabileceğimiz gibi penrenin sol tarafındaki undefined mapping bölümünüde kullanabiliriz. Bu bölümde storage içerisinde tanımladığınız ve henüz bir hotsa bağlamadığınız drive’ları görebilirsiniz.  

Yukarıdaki resimde 1 numara olarak işaretlenen bölümde henüz bir host’a tanımlanmamış drive’ları görebilmekteyiz. Bu drive’u seçerek sağ tuş ile mapping seçeneği yada en üstteki Mappings bölümünden define altından ulaşabileceğimiz mapping ile ulaşabileceğimiz pencerede tek hamlede işlemi yapabiliriz. Burada 2 numara ile işaretlediğimiz bölümde host’umuzu seçiyirouz( yukardaki örnekte host bölümünde web2 isimli oluşturduğumuz server seçilidir.) 3 numaralı bölümde disk için atayacağımız LUN numarasını seçiyoruz. Bu LUN numarası ile neler yapılabileceğini sonraki bölümde yer vereceğiz. 4 numaralı bölümde daha önce oluşturduğumuz logical drive’i seçili olarak görüyoruz, işlemi tamamlamak için ADD tuşuna basmamız yeterli olacaktır. Bu işlem sonrası web2 isimli host’umuzda windows’un disk yönetimini açtığımızda yeni bir diskin geldiğini görebileceğiz.

Bu bölümde en sık kullanılan operatör işlemlerini adım adım inceledik. Diğer menü ve konulara fazla girmemeye özen gösterdim, bir sonraki bölüm 4’te operatör işlemlerinin dışına çıkacağız, performans değerlerinin gözlemlenmesi, bakım, log toplama, firmware update işlemleri, alert tanımlama gibi konuları işleyeceğiz.

Yılmaz BARÇIN

Bir önceki makalemiz de Storage managerin kurulumu ve basit storage yapılandırılması hakkında bilgiler vermiş ve Inital Setup Task bolumunda ki 4 ve 5 numaralı adımlar olan Storage üzerine bağlı bulunan Host ların yapılandırılması, Storage üzerin de Array oluşturulması ve oluşturulan Array’ lerin Logical Driver lar olarak bolunmesini sonra ki makalemize yani bu makalemize bırakacağımızı soylemiştik. Sebebi ise bahsedecek olduğumuz yapılandırmadan sonra artık storagemizi kullanabilir duruma geleceğiz ve bu makalede yapacağımız işlemler detay ve özen isteyen kısımlar olduğu için, anlaşılabilirliğini arttırmak için detaylı olarak ikinci makaleye saklamayı uygun görmüştüm.

Yukarıda ki daygram da sahip olduğumuz donanımlar bulunmaktadır. Daha önce yayınlamış olduğumuz IBM DS Storage makalelerinde ki bilgilerimizi hatırlarsak ve yapımız içerisinde ki donanımları özetlersek bağlantı teknolojisini ve senaryomuzu özetleyelim ;

Sahip olduğumuz donanımlar 4 adet fiziksel serverimiz bulunmuş olup, bu serverlarımız üzerinde W2003 R2 STD ENG OS yuklu durumdadır. OS ler serverlarımız üzerinde ki kendi local diskleri üzerinde kurulu durumdadır (Dıskı bulunmayan serverlara, storagemizin diskini kullanarak OS yukleyebildiğimiz için bu açıklamayı yapma ihtiyacı duydum). Her bir serverimiz üzerinde iki farklı SINGLE Host Bus Adapter bulunmaktadır. İki farklı single HBA kullanarak HBA larımızın yedekli (redundant) olmasını gerçekleştirdik.

Elimizde 16 Porta sahip, ilk sekiz portu lisanslı durumda iki adet SAN SW bulunmaktadır. Diğer sekiz portumuz unlicanse olup kullanılmamaktadır. Her bir hostumuz üzerinde bulunan iki farklı Single HBA, iki farklı SAN Sw’ imizin aynı port numaralarına bağlı durumdadır. Farklı portlara da bağlayabiliriz, fakat diyagramın anlaşılabilirliği rahat olması adına bu şekilde bir dizayn her zaman için tavsiye ettiğim ve kullanmış olduğum bir yapıdır. Özet olarak örnek vermemiz gerekirse SENTEZ Serverimiz üzerinde bulunan 2100001B320A0802 numaralı  I/A ( İdentifiers / aliases ), SAN SW 1 ’ imiz üzerinde 2 numaralı porta bağlı durumdadır. İdentifiers / Aliases hakkında özet bir bilgi vermem gerekirse NIC kartlarımız üzerinde bulunan MAC adreslerine benzetebiliriz. Her bir HBA’ e ait, değişmeyen bir numaradır. Sentez Serverimiz üzerinde bulunan 2100001B320A3001 I/A’ ya sahip ikinci HBA’ mız ise SAN SW 2 ’ imiz üzerinde yine 2 numaralı porta bağlı durumdadır.

Yapımızda sahip olduğumuz Storagemiz IBM DS 3400 Dual Controller (yedekli – çift raid denetleyicili) bir storagedir. SAN SW ile Storage arasında ki bağlantı çaprazlama olarak bağlı durumda olup Fault Tolerance şansı devreye sokulmuştur.

SAN SW 1 den, 0 numaralı porttan , Storagemizin A controllerinın 1 numaralı FC girişine bağlantı yapılmıştır.

SAN Sw 2 ‘ den, 0 numaralı portu üzerinden storagemizin A controllerinin 2 numaralı FC girişine bağlantı yapılmıştır.

San SW 1 den, 4 numaralı porttan, storagemizin B controllerinin 1 numaralı FC girişine bağlantı yapılmıştır.

SAN SW 2 den, 4 numaralı porttan , Storagemizin B controllerinın 2 numaralı FC girişine bağlantı yapılmıştır.

FAULT Tolerance Senaryosu;

Yapmış olduğumuz Dizaynımıza göre bir senaryo üretmemiz gerekirse kazancımız nedir ?

Sentez Serverimiz üzerinde bulunan 2100001B320A0802 numaralı I/A’ ya sahip HBA’ ımız arıza durumuna düşerse, 2100001B320A3001 numaralı I/a ya sahip HBA mız üzerinden Storagemiz ile iletişimine devam edebilecektir. Keza aynı şekilde Sentez server ile SAN Sw arasında bulunan Fibre Channel kabloda bir arıza oluşursa diğer kablo üzerinden iletişime tekrardan devam edecektir.

SAN SW1 arıza durumuna düşerse, sentez serverimiz, 2100001B320A3001 numaralı I/A HBA nın bağlı bulunmuş olduğu SAN SW2 üzerinde ki 2 numaralı port üzerinden iletişime devam edecektir.

SAN SW2 arıza durumuna düşerse, Sentez serverimiz, 2100001B320A0802 numaralı I/A HBA nın bağlı bulunmuş olduğu SAN SW1 üzerinde ki 2 numaralı port üzerinden iletişime devam edecektir.

Storagemizin A Controllerina bir problem olduğu zaman SAN SW 1 üzerinde ki 4 numaralı porttan ve SAN SW 2 üzerinde ki 4 numaralı port üzerinden iletişime devam edecektir.

Storagemizin B Controllerina bir problem olduğu zaman SAN SW 1 üzerinde ki 0 numaralı porttan ve SAN SW 2 üzerinde ki 0 numaralı port üzerinden iletişime devam edecektir.

FAULT Toleranceiç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.

SAN SW’ lerimiz hakkında bilgi vermemiz gerekirse SAN SW lerimiz var sayılan olarak ilk  8 portu lisanslı olarak gelmektedir. Yapımıza ve ihtiyacımıza göre diğer portları lisanslamak bizim elimizdedir. Yukarıdaki SAN SW Manager ekranından alınmış görüntüden de anlaşılacağı üzere, 0 ve 7 numaralı portlar kullanılabilir olarak görünmektedir. Fiziksel olarak diğer portlara da bağlantılarımızı gerçekleştirebiliriz ama lisansımız olmadığı için kullanamayız.

0 ve 4 numaralı portlar üzerinde S harfi bulunmakta olup, Storagemizin bağlantısını bu portlar üzerine yapmamız gerektiğini bizlere söylemektedir.

Geri kalan 1,2,3,5,6,7 numaralı portlara host larımızı bağlayabiliriz ki zaten görüntüde H harfi bulunmaktadır.

SW’ imiz altında bulunan açıklamalardan da anlaşılacağı üzere lisanslı ve lisansız portlarımızın ne şekilde görüneceğini, Doğru (VALID) ve yanlış (INVALID) bağlantı yaptığımızın ekran görüntülerini bizlere göstermektedir. Örnek olarak, Eğer bizler SAN SW’ imizin 3 numaralı portuna Storagemizi bağlarsak SW üzerinde ki port üzerinde invalid bağlantısının sembolu bizlere çıkacaktır.

Missing Connections ( kayıp bağlantı ) ile doğru bağlamamıza rağmen SW ile host / Storage arasında iletişim olmaz ise alacak olduğumuz hatadır.

Yapılandırmamıza başlamadan önce son olarak HBA larımızın Serverimiz üzerine doğru bir şekilde tanıtılıp – tanıtılmadığını kontrol edebiliriz. Yukarıdan görüldüğü üzere HBA larımız, iki fiziksel single HBA mız serverimiza başarılı bir şekilde tanıtılmış durumdadır.

IBM DS 3000 Storage Managerdan, Configure bolumune girip Configure Host Access (MANUAL) seçiyoruz. ( Initial Setup Task içinde de 4 numaralı adımdır burası.)

Enter Host name bölümüne hostumuzun ismini vermekteyiz. En fazla 30 karakterlik bir isim ataması yapabilmekteyiz. Select Host type bölümünden ise hostumuzun üzerinde yuklu olduğu işletim sisteminin seçimini yapıyoruz. Yapımızda bir cluster uygulaması olmadığı için W2000/ Server 2003 Non-Cluster’ i seçiyorum. Linux gibi diğer OS lerine sahip isek seçimimizi ona göre değiştirmeliyiz. Ve cluster yapısı var ise OS mimize göre  bunu da belirtmeliyiz. Next ile ilerliyoruz.

Şimdiki ekranda ise Sol tarafta Known HBA host Ports bölümünde, storagemiz ile iletişim kurmakta olan HBA ları göremekteyiz. Sentez serverimiz üzerinde bulunan ilgili HBA ları seçip Add> butonu ile Selected HBA host port I/A bolumune aktarıyoruz.

Not :

Kurulum sırasında zorluk yaşamamanız için, hangi HBA nın hangi Servera bağlı olduğunu, kurulum sırasında düşünmemeniz için nacizane tavsiyem HBA ların serverlarımıza montajını gerçekleştirmeden önce bir not defterine, her HBA üzerinde yazılı olan I/A numaralarını not etmenizdir ki bu bolumda hangi HBA, hangi Servera bağlıydı sorusunu ortadan kaldıralım J

Next diyerek devam ediyoruz.

Configure Host access (Manual) – Specify Host Group bolumunda ise, oluşturmuş olduğumuz Host grubu için atama yaptığımız logical driverin başka bir host içinde kullanılıp, kullanılmayacağının seçimini yapıyoruz. Özet olarak Sentez için oluşturmuş olduğumuz array üzerinde ki logical driveri EDS de kullanacak mı ? Yani aynı sürücüyü, iki farklı server ortak olarak kullanacak mı ? bizim cevabımız hayır olduğu için NO diyerek işlemimize devam ediyoruz.

Not :

Zaten dikkatinizi çekti ise eğer henüz bir array oluşturmadık ve logical driver lara bölmedik. HOST oluşturma bölümünden çıkıp array oluşlturma ekranına geleceğiz. Benim tavsiyem ilk önce HOST ve HOST grubların oluşturulması ve daha sonradan arrayın, logical sürücülerin oluşturulması ve bunların bir birlerine bağklantısıdır. Tavsiye edilen yöntem de bu olup, map etme ve paylaştırma işlemlerini Modify (düzenleme) bölümünden değiştirebilmekteyiz.

Host tanıtma işlemimizi başarılı bir şekilde yaptığımızın ekranı görünmekte olup, oluşturmuş olduğumuz host ve host grubu hakkında özet bilgi bizlere verilmektedir.

Finish diyerek Sentez server için host oluşturma işlemini tamamlıyoruz.

İşlemin tamamlandığını ve bizlere başka bir host, host grup oluşturacağımızın sorusu yöneltilmektedir. Cevabımız evet ki çünkü EDS, HQ ve Navigion Serverlarımızı storagemize tanıtmadık. Gerekli izinleri vermedik ki bunun için bu serverlarımız storagemiz ile iletişim kuramayacakıtr. YES diyerek aynı işlemleri diğer üç serverimiz içinde gerçekleştireceğiz.

Ve üç serverimizin da gerekli HBA tanıtımını başarılı bir şekilde yaptıktan sonda yukarıda ki ekrana o zaman NO diyerek HOST Access Manuel işlemini bitirmiş olacağız.

İşlemimizi bitirdikten sonra, ana menude ki Host&Mapping ekranında Configure edilmiş host sayısının 4 olduğunu görebileceğiz. İlk makalemizde bu adımları yapmadığımız için sayının 0 olduğunu biliyorduk.

Configure Host bolumune tıkladığımız zaman, storagemize tanıtılmış olan Host larımızı ve sahip oldukları I/A numaralarını görebilmekteyiz. HOST tanıtma işlemimizi doğruladıktan sonra Array oluşturmaya başlayabiliriz.

Ana ekranda Array / Logical Drivers bolumu içinde ki array ve Logical drivers sayıları 0 durumundadır ki sebebi ise herhangi bir yapılandırma yapmadığımızdandır.

IBM DS 3000 Storage Manager içinde Configure bolumune girdiğimiz zaman autometic configuration ile array oluşturabileceğimiz gibi Initial Setup Task görevlerinden 5 numaralı adımda da aynı işlemi gerçekleştirebileceğiz. İlgili bolumu seçip işleme başlıyoruz.

Create Logival Drivers bölümü içinde Automatic bölümünü seçersek Storagemiz üzerinde bulunan disk ve HOST sayısına göre managerimiz kendisi bir hesaplama yapacaktır ki örnek hesaplaması aşağıdadır.

Managerimizin hesaplamasında 10 adet fiziksel sabit sürücümüzü kullanarak 3 farklı array oluşturuyor ki ;

300×3 = 600 GB RAID 5 yapılmış diskleri bizlere sunuyor.Disklerimizden bir tanesini Raid 5 için Parity olarak ayrılmıştır.

RAID 5 yapılandırılmış 3 farklı ARRAY ile 1.673.379 GB kullanılabilir alan veriyor. Ve 3 farklı array için bir adet Hotspare disk ayırıyor.

Managerimizin bizlere vermiş olduğu alan bizim işimizi görmediği için cancel diyerek aynı işlemin manuel kısmını yapacağız.

Array oluşturma işlemini manuel yapacağımızı belirterek devam ediyoruz.

Create Logical Drivers – Manual Drive Selection bölümünde RAID Level olarak RAID 5 ‘ i seçiyoruz.
Unselected drivers bolumu içinde RAID 5 olarak yapılandırılacak array’ ın uyelerini (1 ile 9 njumaralı diskleri) seçip Add butonu ile Selected Disk (seçili diskler) bolumune aktarıyoruz.

Disklerimizi Selected dirivers (Seçilmiş diskler) bolumune aktardıktan sonra Calculate Capacity butonuna basarak kullanılabilri alanı hesaplıyoruz. Kullanabileceğimiz alan 2.179 TB büyüklüğündedir.

Yani 300×9 = 2.179 GB RAID 5 olup, Disklerimizden bir tanesini Raid 5 için Parity olarak ayrılmıştır.

Not : Rakamlar sizi aldatmasın ki disk üzerinde ki cache değerlerini hesaplamadan Raıd 5 sonucunu sizler ile paylaştım. Storage manager yazılımı disk cache değerlerini hesaplayarak bizlere gerçek kullanılabilir rakamları sunmaktadır.

Bu ekranda yapacağımız RAID seviyesi ve ihtiyacımız olan alan doğru ise ilerliyoruz ve Arrayımızı oluşturup, logical drivers atamalarına başlıyoruz, yok değil ise disklerimizi selected disk bolumunden silerek yeni bir hesaplama yapıyoruz ki istediğimiz sonucu aldıktan sonra next ile devam ediyoruz.

Daha sonrdan da mevcut arrayi silip, tekrardan oluşturabiliriz ama Arrayin, initializing işlemi uzun süreceği için boşa zaman harcarız.

Özet olarak doğru, ihtiyacımız olan alanı hesaplamadan ilerlemeyelim ve arrayı oluşturmayalım.

Ben ihtiyacım olan alanı sağladığım için next ile devam ediyorum.

Create Logical Drivers bölümü içinde, Sahip olduğumuz arrayı Logical driver lara bölerek, sahip olduğumuz her server için ihtiyacımız doğrultusunda kapasite dağıtımı yapacağız.

Sahip olduğumuz (Resim de 1 nci bolum ) RAID 5 seviyesinde ki array üzerinde, dağıtabilmemiz için 2 TB boyurunda bir alan bulunmaktadır. Nev Logical drive capacity bolumune 2 TB boyurunda ki arrayın, ne kadarını bu logical driverimizin kullanacağını belirliyoruz.  (Resim de 2 nci bolum ) Şimdi oluşturacak olduğum logical driver için 400 GB uygun gordum ve capacityi yazarak Resim de 3ncü bolumdebu oluşturmuş olduğum logical drivere isim atıyorum ki bu isim serverimizi nitelerse ileride yapacak olduğumz yonetimsel işlemlerde bizlere kolaylık sağlayacaktır.

Resim de 4 ncu bolum ise oluşturmuş olduğumuz logical driverin hangi özellikte ki bir server için kullanacağını belirliyoruz. Bu logical driver bir multimedia (TV, Radio kuruluşları) server için mi ?, Database (SQL, Oracle) sistem için mi ? yoksa bir File (word, exel, vb) System için mi ? kullanılacağını belirliyoruz. Bu logical driverimizda bu özelliği vermemizin nedeni, logical driverın özelliğine göre Input/Output değerlerini atayacak olmasından kaynaklanmaktadır. Logical driver özelliğine göre disk hızlarını, RAID Cache vb.. performansı etkileyecek olan özellikleri orantılayacaktır.

Map Logical Driver to host bölümü içinde oluşturmuş olduğumuz logical driveri hangi hostumuzun kullanacağını belirliyoruz. Makalemizin başında iki single HBA, Serverlarımızın ismi ile eşleştirerek grup oluşturmuştuk. Oluşturmuş olduğumuz bu HOST gruplarını, bu bolumde logical driverimiza bağlıyoruz. Diğer bir deyim ile oluşturmuş olduğumuz logical disklere, serverları erişmesi için izinler veriyoruz.

En basit anlatımıyla serverimiza disk takıyoruz J

Not : Oluşturmuş olduğumuz logical disklere izinler, sahip olduğumuz HBA ların üzerinde ki I/A numaralarına göre verilmektedir. Bir HBA üzerinde ki I/A lar benzersiz olduğu için doğal olarak bu HBA larımıza, HBA larımızın bağlı bulunmuş serverimiza erişim hakkı vermiş oluyoruz. İleride Serverimiza bir sıkıntı olduğu zaman, arızalı duırumda ki HBA larımızı, yeni serverimiza tanıtımını yapıp, storagemize bağlantısı yapıldıktan sonra, yeni serverimiz ilgili logical drivere erişmeye hak kazanacaktır. Ama bu şu demek olmuyor ki Logical drivere erişim hakkı olan bir server, logical driver üzerinde ki dataları da okuyacak. Bu anlama gelmemektedir. Bu izinleri OS mimiz ile sağlamaktayız.

Konuyu biraz daha basite indirirsek, arızalı serverimiz üzerinde ki diski alıp, bir başka çalışır durumda ki serverimiza taktık. Diski görebiliyoruz ama disk içinde ki verilere izinler boyutunda erişebiliyoruz.

Arrayımız üzerinde ki ilk mantıksal sürücü oluşturma işlemini başarılı bir şekilde tamamladık. Şimdiki ekranda başka bir mantıksal sürücü oluşturup-oluşturmayacağımız sorulmaktadır ki cevabımız evetdir. Yukarıda yapmış olduğumuz işlemleri diğer üç serverimiz olan EDS, HQ ve navigion içinde gerçekleştireceğiz. Bu sebepden yes diyerek yeni bir create logical driver oluşturma ekranına yonlendiriyoruz.

Dikkatinizi çektiyse eğer Sentez için oluşturmuş olduğumuz create logical drivers bolumu ile şimdi oluşturacak olduğumuz logical driver ekranları farklıdır. Nedeni ise Sentez ilk oluşturmuş olduğumuz logical driver olup, array ekranı gelmekteydi ve sentez için array de bolum ayırmasını gerçekleştirdik. Şimdiki oluşturacak olduğumuz logical driver da ve sonrakilerde yukarıda ki resimde ki gibi ekran gelip, array üzerinde boşta kalan Free Capacity bolumunu seçerek ilerleyeceğiz.

Free capaciyt bolumunu seçtikten sonra, Navigion için ihtiyaç duymuş olduğumuz alanı giriyoruz. Sentez Server için yapmış olduğumuz işlemi devam ettiriyoruz.

Oluşturmuş olduğumuz logical driveri Navigion Serverimiza bağlıyoruz. Sentez serverımıza logical driver bağlandığı için, görüntüsünün değişik olduğunu görebiliyoruz.

Array ve Logical driver oluşturma işlemlerimizi tamamladıktan sonra yapmış olduğumuz işlemleri kontrol edelim.

Storage manager ana ekranında ki Array & Logical driver bolumu içinde 1 adet Array ve bu arrayın Dörde bölündüğünü görebilmekteyiz.

Oluşturmuş olduğumuz Arrayımızın içine girdiğimiz zaman, hangi hostumuz için ne kadar alan ayırdığımızın detaylarını görüyoruz.

Hot Spare
Oluşturmuş olduğumuz array/ arraylar için, array üyesi disklerden her hangi bir tanesi arıza durumuna düştüğü zaman, arızalanan diskin yerine otomatik olarak geçebilecek ve herhangi bir arıza durumu yaşanmadığı sürece kullanılmayacak olan yedekde bekleyecek olan diskimizdir.

Arrayi oluştururken 1 ile 9 arasında ki diskleri seçmiş ve 10 numaralı diskimizi bekletmiştik. 10 numaralı diskimiz oluşturmuş olduğumuz array için şimdi Hot spare olarak yapılandırılacaktır.

Initial Setup bölümü içinden 5 numaralı adım veya ana ekranda ki hot spare ekranı yolu ile yukarıda ki hot spare oluşturma bölümüne geliyoruz. 10 numaralı diskimizi seçiyoruz ve locate butonuna basarak arrayimiz için hot spare olarak yapılandırıyoruz.

Hot spare diskimizi de yapılandırdıktan sonra, kullanımdan önce oluşan son değişiklikleri de kontrol edebiliriz.

Ana ekranda sahip olduğumuz mevcut kapasite , kullandığımız ve kullanabileceğimiz alan bilgileri görünmektedit. Bizler disklerimizin hepsini kullandığımız için 0 MB ebatında boş bir alanımız kalmış durumdadır.

Storage manager ana ekranında Status durum bilgisini görebilmekteyiz. Arrayimizi yeni oluşturmuş olduğumuz için disklerimiz henüz işlem içerisinde olduğunu bizlere söylemektedir. Ortalama olarak bu süre disk sayısı, array boyutuna göre 6  – 8 saat  arası ve üzeri sürmektedir.

Donanımımızda ki genel bilgilerde ki değişiklikler ise Storage sub system profile haricinde ki değişiklik goruunmektedir. 10 adet fiziksel diskimizden bir tanesi Hot spare için kullanılmış ve diğerleri array için kullanıldığını görebilmekteyiz.

Boşta bekleyen fiziksel bir diskimiz bulunmamaktadır.

Yapmış olduğumuz işlemleri tamamladıktan sonra storagemiz üzerinde ki işlemleri bitirmiş oluyoruz ki artık işlem tarafı hostumuza geçmektedir.

Hostumuz üzerinde aygıt yoneticisini açarak, disk bolumu içinde ki yeni diskimizi arattırıyoruz ve formatlama işlemini tamamladıktan sonra storagemizi kullanmaya başlayabiliyoruz.

Fatih KARAALİOGLU

IBM DS4800 Storage Unitesin SAN sınıfında ve 4 Gbps FC hızında erişim hızına sahip olduğunu makalenin birinci bölümünde incelemiştik. SAN Storage’larda en önemli konulardan biriside Storage’in sunuculara olan bağlantısıdır. Bu bağlantı standart olarak Fibre Channel ( FC ) teknolojisi kullanılarak yapılmaktadır. Bu bölümde Storage-Server bağlantısı, Server FC HBA seçimleri, FC HBA yönetimi, IBM Storage Manager Client software yazımının kurulumu inceleyeceğiz. Bu makaleyinin “Önemli” alt konu başlıklı bölümünü çok dikkatli okumanızı ve anlamanızı öneririm.

Server parkurunun storage bağlantısı FC Host Bus Adapter ( HBA)  kullanılarak yapılmaktadır. FC HBA’lar single ve dual olmak üzere iki çeşittir. FC HBA’lar 2 ve 4 Gbps I/O hızlarına sahiptirler. Gelişen teknoloji ile şuanda yeni yeni çıkmaya başlayan 8 Gbps hızında kartlarda mevcuttur. Genellikle 4 Gbps hızındaki FC HBA’lar kullanılmaktadır.  Temel olarak bir server’a takılan FC HBA’ya dışarıdan bağlanan bir FC kablonun storage üzerindeki FC portlarına ( 4 adet x 2 toplam 8 port mevcuttur. ) takılması ile bağlantı kurulmaktadır. Aşağıdaki resimde örnek bir bağlantı görülmektedir. ( aşağıdaki bağlantı method’larından 4.su) 

Sunucular üzerine takılacak FC HBA’nın Single( tek port ) yada Dual( çift port ) olmasının avantaj ve dezavantajları;

• Single port HBA’lar tek bir port üzerinden storage’a bağlanır, kabloda oluşabilecek bir hasar yada kartta meydana gelebilecek bir arıza yada sorunda server-storage bağlantısı kopacaktır. Diğer taraftan single port hba’lar dual kartlara göre çok daha ucuzdur.
• Dual port HBA’larda iki port üzerinden storage’a bağlanır, HBA’nın software yönetiminde yapılacak ayarlar ile FC HBA’lar birbirlerinin yedeği olarak çalışırlar, kablolardan herhangi birinin hasar görmesi yada arızalanması durumunda herhangi bir kesinti olmaksızın çalışmaya devam eder. Ayrıca portlar arasında load balancing yapmakta mümkündür. Dual port FC HBA’ların riski ise kartta meydana gelebilecek bir arızalanmada her iki port birden devre dışı kalacaktır.
• Single port HBA’ların önemli bir avantajı storage üzerinden sadece bir portu tüketmeleridir. Bir server’a iki adet single port hba takılarak bunların birbirinin yedeği olarak çalışması sağlanabilir, load balancing yapılabilir.  Bu sayede sunucu üzerinde hba kartta oluşabilecek bir hasarda diğer kart üzerinden veri akışının kesilmeden devam etmesi sağlanabilir. ( Sıklıkla Tercih edilir. ) Single port kartlar kullanıldığından maliyette daha düşük olmaktadır.
• Dual port HBA’larda storage veya FC Switch üzerinden iki port tüketilmektedir. Sunucu tarafında HBA kartta oluşabilecek bir arızanın önüne geçmek için iki kart takılması durumunda storage veya fc switch üzerinde 4 port tüketilecektir. Bu storage’a çok sayıda sunucu bağlanması durumunda port sıkıntısı yaşatacaktır. Ayrıca maliyeti biraz daha yukarı çekecektir.  

Storage Server bağlantı Methodları

• �
  1. Single port FC HBA to Storage
  2. Single port FC HBA x 2 to Storage
  3. Single port FC HBA x 2 to FC Switch to Storage
  4. Single port FC HBA x 2 to FC Switch x 2 to Storage ( sık tercih edilmektedir.)
  5. Dual port FC HBA to Storage
  6. Dual port FC HBA x 2 to Storage
  7. Dual port FC HBA x 2 to FC Switch to Storage
  8. Dual port FC HBA x 2 to FC Switch x 2 to Storage ( En Yüksek Güvenirlikli Tasarım)  

Server’lara taktığımız FC HBA’ları yönetimi için Qlogic için SanSurfer yazılımı kullanılabilir. HBA’ların driver cd’lerinde genellikle tool klasörü altında yer alan sansurfer yazılımını kullanarak yapılabilecekler;

• Merkezi olarak ve uzaktan FC HBA’lar ve FC switch’leri kontrol olanağı sağlar.
• Alarm log’larından kart yada kablo ile ilgili oluşabilecek hasarlar izlenebilir. Çeşitli alarmlar tanımlanarak sorun oluştuğunda bizi bilgilendirebilir.
• Node ve port name’leri buradan görülebilir. Storage manager client’ta server tanımlanırken port numaralarına ihtiyaç duyulmaktadır.
• Firmware,Bios,Rom,Nvram güncellemeleri buradan kolaylıkla yapılabilir.
• Failover tanımları buradan yapılabilir. ( FC HBA’larınızın failover desteklemesi gerekmektedir.)

SanSurfer FC Manager yazılımı

Yukarıdaki resimde görüldüğü SanSurfer ile ortamınızdaki tüm  FC HBA ve FC Switch’leri yönetebilirsiniz.( Desteklenen marka ve modelleri, qlogic gibi.). Burada HBA’lar ile ilgili tüm kontrolleri hardware seviyesinde yapmanız mümkündür. Ortamınızda herhangi birinin bu ve benzeri yazılımlar ile FC HBA’larınıza bağlanmaması için özellikle switch’inize şifre koymanız güvenlik adına yararlı olacaktır. FC Switch’inize bağlantı kurulmak istendiğinde aşağıdaki gibi bir ekran ile karşılaşılacaktır.

ÖNEMLİ:

Storage ile Server’lar arasındaki FC bağlantısı çok hassastır. Bu bağlantının projelendirmede iyi tasarlanması gerekmektedir. Bottleneck olarak ifade ettiğimiz darboğazların oluşmamasına dikkat edilmesi gerekmektedir. Bunun için erişim hızının her noktada dengede olması gereklidir. Aksi takdirde yüksek I/O miktarları oluştuğunda sistem yavaşlayacak, hizmette aksamalar yaşanacaktır. Bir Exchange server’in I/O değerleri ile bir SQL server’in I/O değerleri çok farklıdır. Dolayısı ile başarılı bir proje yapmak istiyorsanız öncelikle sunucu parkurunda işletim sisteminin counter değerlerini performans monitor araçlarını kullanarak ölçmeniz gereklidir. Bu I/O değerlerinin toplamı sizin Storage üzerinde yapacağınız toplam throughput değeridir. Buna göre storage’in desteklemesi gereken bandwidth miktarı ve FC HBA nitelikleri tespit edilebilir.

FC HBA’lar ile Storage’a SAN bağlantı kurulmasının en önemli sebebi hızdır. Yüksek I/O ve erişilebilirlik söz konusu olduğunda SAN Storage’lar kullanılır. Her ne kadar iScsi ve NAS destekli storage’lar yüksek hızlarda I/O değerlerine sahip olsalar da asla bir SAN kadar hızlı olmaları imkansızdır.  Network switch’leri üzerinden yapılan veri akışında, network’ün hızına göre network’teki broadcast vb. değerlere göre kayıplar olacaktır. Hiçbir zaman bir SAN storage’a FC HBA’lar ile yapılan bağlantı hızına ulaşamayacaktır ve SAN altyapısı kadar güvenilir olmayacaktır.

Storage Yönetimi

DS 4800 Fiziksel olarak kurduktan sonra arabirimleri ile kolaylıkla yönetilebilmektedir. Rakiplerine göre yönetim tarafında oldukça esnektir. DS 4800 üzerindeki network interface’i ile network’ünüze bağlanabilmektedir. Network üzerinden istediğiniz bir pc yada server üzerinden storage’inizi rahatlıka yönetebilirsiniz. Burada önemle vurgulamak istediğim IBM’in DS serisi storage’ları yönetim için kendisine doğrudan bağlı bir server’a ihtiyaç duymazlar. Bu rakip marka model ürünlerdeki en büyük dezavantajdır. Örnek vermek gerekirse HP EVA serisi ( mid-range’de HP EVA 8000 ) yönetim için kendisine doğrudan bağlı bir sunucuya ihtiyaç duymaktadır ve server ile yönetilebilmektedir. Dolayısı ile sunucuda oluşabilecek bir arıza ve hasarda storage yönetilemez bir hal almaktadır. Bildiğim kadarı ile HP EVA serisinde bunu gidermek için yeni versiyon çalışmaları yapmaktaydı, bu sorunu ya çok yeni aştılar yada yakında aşacaktırlar.

Storage yönetiminin önemini vurguladıktan sonra DS 4800 için Client yazılımı olan IBM Storage Manager Client ver 10 u download ederek yüklememiz gerekmektedir. Bu şuandaki en güncel versiyon sürümüdür. Firmware ve bios update işlemlerini storage üzerinde yaparsanız alt sürümler bağlantı kuramaz ve yönetemezsiniz.

Kuruluma başlamadan önce kullandığınız işletim sistemine göre gerekli yamaları yapmanız gerekmektedir. IBM DS serisi ürünler RDAC kullandıkları için güncellemeleri yapmanız gerekmektedir. İleriki bölümde RDAC ile neler yapıldığını işleyeceğiz.

Windows için gerekli RDAC güncellemesi http://support.microsoft.com/kb/932755 adresinden uygun sürümü indirebilirsiniz.
Storage Manager Client Yazımını http://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-5073739&brandind=5000008 adresinden çekebilirsiniz. Bu sürüm ile DS 4000 serisindeki diğer storage’larıda rahatlıkla yönetebilirsiniz.

Yukarıdaki gibi basit bir yükleme sihirbazı ile açılacaktır. Sihirbazı takip ederek kurulumu yapabilirsiniz. Yükleme seçenekleri adımında tipik kurulumu seçebilirsiniz. Tipik kurulumda tüm bileşenleri içermektedir. Kurulum sonrasında bilgisayarınızı yeniden başlatmanız gerekmektedir.

Not: Basit bir sihirbaz olduğu için Storage Manager Client için adım adım resim desteğine ihtiyaç duyulmayacağı için yer vermedim. Genel olarak Storage konusunda resimden daha ziyade teknik veriler ön plana çıktığı için makaleler daha çok metin içeriklidir.

Yılmaz BARÇIN

Bir datayı saklamak için günümüz teknolojisinde çok farklı çözümler bulunmaktadır. NAS ve SAN olarak bilinen bir çok ürün dataları saklamak ve korumak için ideal durumda olup yeri geldiği zaman şirketin sahip olduğu data boyutuna bağlı olarak network içine konuşlandırılan, RAID seviyesi ve güçlü RAID controlleri dizayn edilmiş bir FILE server ile çözüm üretilmektedir.

Günümüzde ki Storage Teknolojileri;

DAS (Direct,attached storage)

Tek bir server üzerine direk olarak bağlanan dahili veya harici depolama birimidir..

Bağlantı Teknolojisi SAS, ISCSI ve FC’ dir..

Shared DAS

Birden fazla servera Harici olarak direk bağlanan depolama birimidir…

Bağlantı Teknolojisi SAS, ISCSI ve FC’ dir..

NAS (Network-attached storage)

IP teknolojisi kullanılarak harici bir depolama birimidir.

Bağlantı Teknolojisi Ethernet , SW (network alt yapısı)’ dir..

San (Storage Area Network)

Özel olarak yapılandırılmış LAN veya WAN networkler için depolama birimidir.

Bağlantı Teknolojisi ISCSI ve FC’ dir.. DAS Teknolojisine göre avantajı Tape Backup uniteleri bağlanabilmekte, çoklu server yapısını desteklemekte ve performansının daha iyi olmasıdır.

Yukarıda ki resimde IBM DS 3000 Serisi Storageler için sahip oldukları teknolojiler örnekler verilmiştir.

Yanlız bahsetmiş olduğumuz bu çözümlerden herhangi bir tanesini seçmeden önce sormamız gereken basit sorular;

· Sahip olunan datanın boyutu,

· Sahip olunan datanın büyüme oranı

· Sahip olunan dataya erişim hızı

· Sahip olunan datanın korunması vb.. temel soruları sormamız gerekmektedir.

Yukarıda ki soruları sorduğumuz da cevaplarımız evet gereksinim var diyorsa çözümün yolu Storage Çözümlerinden geçmektedir.

Storage çözümü, Cluster yapıları içinde zorunlu bir ihtiyaçtır. Cluster yapılarında donanım ihtiyaçlarında ilk önde gelen ürün SCSI veya Fibre Channel bağlantıları ile, bir paylaşılmış (shared disk) diske yani bir storageye ihtiyaç duymasıdır. Cluster yapılarında Serverlar üzerinde herhangi bir şekilde veri bulunmayıp, Cluster içinde ki NOD’ lar, ortak paylaştırılmış bir diski kullanırlar ve kullanılan bu ortak disk çoğu zaman bir storage olmaktadır.

Yukarıda ki resimde IBM DS 3400 Storage ile yapılabilecek örnek bir topolojiyi görmekteyiz. Fabrikamız geniş bir alan üzerine dağılmış bulunup neredeyse olması gerekecek tüm Fault Torelance ihtimalleri Düşünülmüştür.

Topolojiden bahsetmemiz gerekirse; Şirketimizin datalarını barındıran IBM Ds 3400 Storagemiz ve SAN SW’ lerimiz Sistem odasında barınmakta olup, SQL Cluster Nod’ larımızdan bir tanesi yönetim binasında ve uzaklık mesafesi 10 Km’ dir. Diğer SQL Nod’ umuz ise Uretim binasında olup buradaki mesafede 10 Km uzunluğundadır. Bağlantılar fiber kablo ile yapılmıştır. Sistem odamıza 8 Km uzaklıkta ki Depo içerisinde EXP300 Ürünü bulunup, Storage üzerinde ki datalar Flash Copy ve Volume Copy özelliği ile yedeklenmektedir. Verilerimizin Fabrika dışarısına çıkartılması düşünülmüş olup SAN Sw’imizden Fiber kablo yardımı ile Yönetim binasında ki Tape backup unitesine, zamanlanmış görevler ile kasetlerimize yedeklerimiz alınmıştır.

Burada bilinmesi gereken en önemli konu IBM DS 3000 Serisi Storagelerde, storage içinde ki veri, bir tek DS 3400 Ürünü için Tape Backuplara alınmaktadır. Sebebi ise sadece Ds 3400 ürünleri Fiber Chanel teknolojisi ile çalışmaktadır. Diğer ürünlerimiz de Server üzerine veya SAS, SCSI Kablolar vasıtasıyla bağlanmış bir Tape backup unitesine yedeklerimizi alabiliriz. Tape Backuplarımızı Storage üzerinde ki SAS kablolara bağlayamadığımız gibi örnek topolojide SAN SW’ ler kullanılmasaydı eğer Tape Backup’ımızı Fiber Teknolojisi ile bağlayamayacaktık. Hiç bir Storage üzerine, bağlantı yuvaları olsa dahi direk Tape Backup teknolojisi kullanamamaktayız.

Cluster yapıları ile ilgili detaylı bilgiyi http://technet.microsoft.com/en-us/library/bb727114.aspx#EGAA ilgili linkinden temin edebilirsiniz.

IBM’ in küçük, orta ve büyük boyutda ki datalara sahip her firma için farklı storage çözümleri olup, bizler bu makalemizde IBM ‘in Giriş seviyesi Storage çözümü olan IBM DS3000 Serisi Storageleri inceleyeceğiz.

IBM firmasının 3000 serisi adı altında DS 3200, DS 33000 ve DS 3400 olmak üzere üç farklı özellikte storagesi olup, bu üç farklı storageyi genişletmek adına EXP3000 ürünü bulunmaktadır.

IBM DS 3000 Serisi tüm storagelerin fiziksel özellikleri birebir aynı olup, temel ortak özellikleri aşağıdaki gibidir.

IBM DS 3000 Serisi Storageler ;

· 12 adet SAS veya SATA 10.000, 15.000 Rpm disk yuvası bulunmaktadır.

o 3 Adet EXP3000 ürünü ile birlikte 48 Adet Disk takılabilmektedir.

· 512 Mb, 1 Gb ve 2 GB batarya cache bulunmaktadır.

· Raid Seviyesi olarak 1,3,5,10 seviyelerini desteklemekteidr.

· Fan ve Power ekipmanları Dual Redundant ve Hot Swapple (storage çalışıyorken, elektirik kesintisi yapmaksızın ürünü kapatmadan arızalı ürünü değiştirebiliyoruz)’ dir.

· Storage ve EXP3000 uniteleri 2 U ebatındadır.

· IBM DS3000 Serisi Storage Manager Yazılımı ile yönetilmekte ve yapılandırılmaktadır.

· Flash Copy ve Volume Copy’ yi desteklemektedir.

· Partition Expansion

FlashCopy mantıksal sürücülerinin oluşturulmasını ve yönetilmesini destekler. Flash Copy, storagemiz içinde barınan bir mantıksal sürücünün anlık görüntüsünü (bire bir fiziksel kopyasını), storage ve/veya Exp ürünlerin de belirtmiş olduğumuz alanlara aktarmak için kullanılmaktadır. Flash Copy’ in en büyük özelliği, almış olduğu anlık görüntüyü, storage üzerinde ki başka bir noktaya, mantıksal değer aynı olsa dahi, storage üzerinde daha az alan kaplayacak şekilde yedeklemesidir. Ve daha az alan kullanarak yedeklemesi, mevcut datanın hızlı bir şekilde yedeklemesi ile paralellik göstermektedir. Bu işlemleri yapmasında ki temel neden bir flash copy adreslenebilir bir mantıksal sürücüsü olmasıdır. Yedekleme yapılırken Source (kaynak) veri çevrim içi durumda kalır ve kullanıcı bu işlemden etkilenmez.

Alınan bir Flash copy uygulama, sınama ve test işlemleri içinde kullanılabilmektedir. Alınan bir Flash copy üzerine veri yazılabilir ve değişiklik yapılabilmektedir. Ve bu sayede canlı datamız işlemlerimizden etkilenmeyecektir.

İzin verilen en fazla FlashCopy mantıksal sürücüsü sayısı, sahip olunan Controller’in desteklediği mantıksal sürücü toplam sayısının yarısı kadardır.

Volume Copy Özelliği, storage üzerinde ki bir mantıksal sürücü verilerini kopyalamak için kullanılan özelliktir. Volume Copy kullanım amacı donanım büyütmeleri ihtiyacında, mantıksal sürücü içinde ki verileri tekrardan dağıtmak ve kopyalamak ve yedeklemek için kullanılmatadır. Flash copy’e göre en büyük farkı, görevlendirilen bir volume copy özelliği kalıcıdır. Bu görevlerin olay günlüklerini storage manager üzerinden sürekli olarak izleyebilir ve hataları, eventleri takip edebiliriz. Kopyalama ile ilgili tüm sonuçları bizlere bildirir. Yedekleme çözümü olarak düşünülebilir.

Flash copye göre source (kaynak) mantıksal sürücü ile, target (hedef) mantıksal sürücü alanları bir biri ile uyumlu, aynı olmak zorundadır. Flash copyde ki gibi alan tasarrufu yapmamaktadır ve veri boyutuna göre hızı belirlenmektedir.

Partition Expansion IBM DS 3000 Serisi Storagelerimiz en fazla 4 Partition’a kadar izin vermekte olup partition expansion lisansı yuklendiği zaman en fazla 16 partition’a kadar izin vermektedir. Eğer yapımız gereği 16 Partition’a topolojimize uygun değilse Ds 4000 Serisi ürünler tercih edilmelidir.

IBM DS 3000 Serisi Storage ve EXP ürünlerinde iki adet Raıd Controller (Raid Denetleyicisi ) bulunmaktadır. Bu denetleyiciler Single ve Dual Path konigurasyonlarında ihtiyaca ve dizayna göre kullanılmakta olup denetleyicilerden bir tanesi üzerinde bir hata oluştuğu zaman otomatik olarak diğer denetleyici devreye girmektedir. Ckuster yapılarında Dual Path (çift denetliyici) Storageler kullanılmaktadır.

Storagenin arkasından bakıldığı zaman Sol taraftaki denetleyici A, sağ taraftaki denetleyici B olarak nitelendirilir.

Her bir Controller’ in üzerinde Controlleri yonetebilmemiz için Ethernet portları vardır ve bu ethernet portları DHCP Bootp’ dır. IP adreslerini otomatik olarak DHCP Server üzerinden almak üzere yapılandırılmıştır. Eğer ortamda bir DHCP server yok ise default ıp adresleri

· Controller A 192.168.128.101

· Controller B 192.168.128.102 olarak yapılandırılmıştır.

Her bir Controllerin arkasında, Controlleri yönetebilmek için

· Ethernet kartı, host expansion

· Sas Expansion Port (Storage üzerinde ki mevcut disk alanını genişletmek için ihtiyaç duymuş olduğumuz modulun bağlantı Portu)

· Storagenin serisine göre Hostlar için SAS (DS3200), ISCSI (DS3300) ve Fiber Chanel (DS3400) portları bulunmaktadır.

· Diagnostics Port (Konsol bağlantı olarak düşünebiliriz, şifre sıfırlama ve konsoldan erişmek için)

· Açma-Kapatma düğmesi ve Güç ünitesi bulunmaktadır.

Her bir RAID Controller üzerinde 512 MB’lik miktarını Cache bulunmaktadır. İhtiyacımıza göre bu Cache Bataryaları 1 ve 2 Gb olarak arttırabiliriz. Bu bataryalar verilerin sabit sürücülere yazılmadan önce cachelemesi için kullanılmakta olup veriler cachelendikten sonra disklere yazılmaktadır. Bu cachenin kullanım amacı DS3000 RAID denetleyicilerindeki okunur ve yazılır verilerin ara depolanması için kullanılan bellektir ve Storagenin performansını arttırmaktadır.

Bir Cachenin yani RAM’ in bir diske göre daha hızlı bir teknolojiye sahip olmasından kaynaklanmaktadır. Ayrıca, güç kesintisi durumunda önbellekteki verileri üç güne kadar saklayan, kapalı yeniden doldurulabilir lityum iyon pil bulunmaktadır.

Ortalama olarak bir pilin ömrü 2 yıl olarak belirlenmiştir. Storagenin verimli çalışabilmesi için sahip olunan pilin en az iki yılda bir değiştirilmesi gerekemktedir veya cache özelliğinin iptal edilerek kullanılmasına devam edilmelidir.

Raid Level
Array
Hot Spare
HDD Kapasite
HDD Türü
Storage ile
(12 Ad Disk)
1 Ad.EXP 3000 ile
(24 Ad Disk)
2 Ad.EXP 3000 ile
(36 Ad Disk)
3 Ad.EXP 3000 ile
(48 Ad Disk)

Raid 5
1
1
73 Gb
SAS
730 Gb
1.6 TB
2.4 Tb
3.3 Tb

Raid 5
1
1
146 Gb
SAS
1.4 Tb
3.2 Tb
4.9 Tb
6.7 Tb

Raid 5
1
1
300 Gb
SAS
3 Tb
6.6 Tb
10.2 Tb
13,8 Tb

Raid 5
1
1
700 GB
SATA
7 Tb
7,2 Tb
23,8 Tb
32.2 Tb

Raid 5
1
1
1 Tb
SATA
10 Tb
22 Tb
34 Tb
46 Tb

Storagemiz 73 Gb, 146 gb ve 300 Gb lık SAS diskleri , 700 Gb ve 1 Tb boyutunda SATA diskleri kullanabilmektedir.

Sata diskleri daha çok Canlı olmayacak, sürekli olarak kullanılmayacak datalar için kullanabiliriz. Sebebi ise SAS diskler SATA disklere mimarisi gereği daha sağlıklı ve hızlı çalışmaktadır. Kullanım amacı olarak Volume copy ve/veya Flsh Copy ile alacak olduğumuz yedekleri SATA diskler ile oluşturmuş olduğumuz ayrı bir arraya yedekleyebiliriz. Çünkü SATA diskler Performansı, throughput değerlerini bire bir etkilemktedir. Yedeklerimiz sürekli olara kullanılmayacağı için, ölü nokta olacağından performansa bir tek geri dönüşlerde ihtiyacımız olacaktır.

Sata ve SAS disk kullanılmış storagelerimizde bilinmesi gereken ana kural, bir array’ın üyesi olan diskler asla ve asla farklı teknolojilere sahip olmamalıdır. Örnek vermemiz gerekirse 3 Disk ile RAID 5 yapılandırılmış bir Arrayımızın 2 diski SAS bir tanesi SATA olamaz. Arrayın üyesi olacak olan tüm diskler aynı disk teknolojisini kullanmak zorundadır. Ve bunun haricinde arrayın üyesi olacak olan disklerin Boyutları aynı olmak durumundadır. Her array için ayrılmış olacak olan Hot Spare disk, array hangi disk teknolojisi ile uygulandı ise eğer o teknolojiye sahip disk ile yapılmalıdır. SAS disk ile oluşturmuş olduğumuz bir array’e SATA diskden bir Hotspare atayamayız.

Performans Değerleri
DS 3200
DS 3300
DS 3400

Brust I/O rate – cache reads
90,000 IOPS
64,000 IOPS
114,000 IOPS

Sustained I/O rate – disk reads
22,000 IOPS
22,000 IOPS
22,000 IOPS

Sustained I/O rate – disk writes
4,500 IOPS
4,200 IOPS
4,600 IOPS

Sustained Throughput disk read
900 MB/s
380 MB/s
925 MB/s

Sustained Throughput disk write
690 MB/s
300 MB/s
720 MB/s

Yukarıda ki tabloda ki değerler 512 MB Cache Memory ve 48 Adet SAS Disklerin vermiş olduğu değerlerdir.

Kullanacak olduğunuz disk Teknolojisi SATA olursa, disk sayısı daha az olursa ve Cache Memory’ niz farklı olduğu zamanlarda değerler değişkenlik gösterecektir. Bunların haricinde DS3300 ürünlerinde network dizaynına göre değerler değişkenlik gösterebilmektedir.

IBM Storage DS 3000 Serisi Storagelerin X Series System ve IBM Server ve Blade Serverlar için uyumluluk tablosu bulunmuş olup, storagelerimiz IBM olmayan diğer vendor (satıcıların) üretmiş olduğu Intel Pentium 450 Mhz ve daha üst micro işlemcili serverlarda, AMD 450 Mhz ve daha hızlı işlemcili serverlara uygun HBA bağlantısı ile kullanılabilmektedir. Ram ihtiyacı olarak minimum 256 Mb (Tavsiye edilen 512 Mb) ihtiyaç duymaktadır.

IBM DS 3000 Serisi Storagelerimizi kullanabileceğimiz işletim sistemi tablosu yukarıda belirtilmiştir.

Fatih KARAALİOGLU

DS3200 ürünü, bağlı olduğu serverlara SAS (Serial Attached SCSI) teknolojisi ile iletişim kurmaktadır.

Sas; SCSI’ nin bir seri iletişim protokolu olarak bilinmektedir ve veri ile aygıt noktadan noktaya birbirine bağlanmaktadır. Sas teknolojisi SCSI’ nin yavaş kaldığı durumlarda Fiber Teknolojisinin pahalı olması sebebiyle ara ürün olarak geliştirilmiş bir teknolojisdir.

Günümüzde Ultra SCSI’ nin veri yazma hızı 320 MB/sec’ iken yapılandırılmasına göre bir SAS teknolojisi 1200 MB/sec’ ye ulaşabilmektedir. Bu hızlara ulaşmasının tek nedeni kullanmış olduğu seri iletişim protokoludur.

Bir SAS bağlantısı 8 Km uzaklıkta ki bağlı bulunmuş olduğu aygıt ile iletişim kurabilmektedir.Bir sas Cablo üzerinden 3Gbs hızında iletişim kurabilmektedir.

SAS teknolojisinin SCSI teknolojisine göre avantajları özet olarak yukarıda ki gibi olsa da ISCSI ve Fiber Bağlantı teknolojisine göre bağlanılacak host sayısının sınırlı olması, performans ve mesafe konusunda diğer iki teknolojiye göre daha yeteneksiz durumdadır. Fakat diğer teknolojilere göre maaliyeti acısından cazip durumdadır.

Yukarıda IBM DS3200 Storagemizin arka modulunu görmekteyiz.

Ds3200 Serisi storagemiz diğer Ds3300 ve Ds 3400 Storagemize farklı olarak Daughter ekipmanı bulunmaktadır.

DS3200 Storagemiz eğer Single Controller’a sahip ise sadece bir server bağlantısı gerçekleştirebiliyoruz. Eğer ikinci bir Controller maaliyeti şirketimizin ayırmış olduğu bütçeyi aşıyorsa eğer daha ucuz çözüm ile bir controller almaktansa bir adet daughter card alınarak ilave iki server daha bağlayarak tek bir controller üzerine toplam üç server bağlantısı gerçekleştirebiliyoruz.

Aynı işlemi ikinci controllerimiz üzerine yaparsak Dual olarak (iki Controller ile) toplam 3 adet server bağlayabiliyoruz. Server ile Storage arasında ki bağlantı teknolojisini Single (tek kablo) olarak yaparsak en fazla 6 adet serveri, DS3200 Storagemize bağlayabilmekteyiz.

DS3200 Single Controller Entry Level: Single Server, Single Path (DS3200 Giriş Seviyesi Tek Kontroller: Tek Server, Tek Bağlantılı yapılandırma)

Single Server Single Path yapılandırmamız IBM DS3000 Serisi Storage Ailesinin ilk giriş seviyesi yapılandırılması olup bu yapılandırma ile hiç bir Fault Torelance (hata şansı) olmaksızın bir tek serverimizi bağlayabilmekteyiz. Yapılandırma için ihtiyaç duymuş olduğumuz ürünler;

Yapılandırma için ihtiyaç duymuş olduğumuz ürünler;

S: IBM System Storage Ds3200 Single Controller

H: IBM Sas HBA Controller (1 Adet)

C: IBM Sas Cable (1 Adet)

DS3200 Single Controller: Single Server, Dual Path with Redundant HBAs (İki Fiziksel HBA ile İki Bağlantılı yapılandırma)

İlk yapılandırmamıza göre, Single Controller Dual Path bağlantımızda Serverimiz ile Storagemiz arasında ki bağlantıyı Fault Torelance için çift HBA ile bağlantısı gerçekleştirilmiştir. Böylelikle Serverimiz ile Storagemiz arasında ki bağlantı çift SAS kablo ile yapılmış olup, HBA veya SAS Kablolarımızdan herhangi bir tanesi arıza durumuna düşerse diğer bağlantıdan işlemlerimiz devam edecektir. Fault Torelance haricinde bu yapılandırma ile Serverimiz üzerinden bir veri iki farklı bağlantı ile storagemiz üzerine yazılırken performans kazanacağız. Bir veri ikiye bölünerek iki farklı yol üzerinden Storagemize yazılacaktır.

Yapılandırma için ihtiyaç duymuş olduğumuz ürünler;

S: IBM System Storage Ds3200 Single Controller

H: IBM Sas HBA Controller (2 Adet)

C: IBM Sas Cable (2 Adet)

D: DS3200 Daughter Kart

DS3200 Dual Controller: Single Server, Dual Path with Redundant HBAs (Tek Server, iki fiziksel HBA ile iki farklı kontrollera bağlantılı yapılandırma)

Dual Controller, iki RAID kontroller ile yapmış olduğumuz bu yapılandırmada RAID Denetleyicimiz için Fault Torelance düşünülmüş olup Controllerlarımızdan bir tanesi arıza durumuna düştüğü zaman diğer kontrollerimiz devreye girecektir.

Yapılandırma için ihtiyaç duymuş olduğumuz ürünler;

S: IBM System Storage Ds3200 Dual Controller

H: IBM Sas HBA Controller (2 Adet)

C: IBM Sas Cable (2 Adet)

DS3200 Single Controller: Two Servers, Single Path (Tek Kontroller üzerine iki farklı Server Bağlantısı)

İki farklı Serverimizi, hiç bir fault torelance alt yapısı oluşturmadan Serverlarımızın bağlantı çeşididir.

Storagemiz üzerinde ki Host girişi ile aynı bağlantı teknolojisi kullanılarak üçüncü bir serveri bağlayabilmekteyiz.

Yapılandırma için ihtiyaç duymuş olduğumuz ürünler;

S: IBM System Storage Ds3200 Single Controller

H: IBM Sas HBA Controller (2 Adet)

C: IBM Sas Cable (2 Adet)

D: DS3200 Daughter Kart

DS3200 Dual Controller: Two Servers, Dual Path with Redundant HBAs (iki fiziksel HBA ile iki farklı kontrollera çift bağlantılı yapılandırma)

İki farklı serverimizi, iki farklı HBA ile iki farklı RAID denetleyicimize bağlantı yaparak Serverlarımızın Storagemiz ile olan ilişkisini tam bir Fault Torelance teknolojisine göre yapılandırıyoruz. Yapmış olduğumuz bu dizayn ile Serverlarımız üzerinde ki iki farklı HBA’ yı Storagemiz üzerinde ki iki farklı Controller’a Cros (ÇAPRAZ) bağlantı yaparak, gerek server üzerinde bulunan HBA’ larımızın, gerek SAS Kabloların gerekse Raıd Denetleyicisi Controllerımiz için olması muhtemel hatayı minimize duruma getirmiş oluyoruz.

Yapılandırma için ihtiyaç duymuş olduğumuz ürünler;

S: IBM System Storage Ds3200 Dual Controller

H: IBM Sas HBA Controller (4 Adet)

C: IBM Sas Cable (4 Adet)

D: DS3200 Daughter Kart (2 Adet)

DS3200 Dual Controller: Three Servers, Dual Path with Redundant HBAs (üç Server iki farlı HBA ile iki farklı Controller üzerine çift yollu bağlantısı)

DS 3200 Storagemiz üzerine yapabileceğimiz son bağlantı teknolojisi olup, bir önce ki yapılandırmamız gibi Fault Torelance düşünülmüştür.

Dual olarak bağlantı yapmaz ise Single olarak 6 tane Server bağlayabiliyoruz. Teknolojimizi single olarak yaparsak ihtiyaç duyacağımız diğer bir ürün ise Partition Expansion Lisansıdır. Sebebi ise DS 3000 Storage Ailesi en fazla dört partitiona kadar destek vermekte olup Partition lisansı ile 16 partition’a kadar çıkartabilmekteyiz.

Yapılandırma için ihtiyaç duymuş olduğumuz ürünler;

S. IBM System Storage Ds3200 Dual Controller

H. IBM Sas HBA Controller (6 Adet)

C. IBM Sas Cable (6 Adet)

D. DS3200 Daughter Kart (2 Adet)

Fatih KARAALİOGLU

DS 4800 Özellikleri: 4 Gbps Fiber Kanal arabirime sahip olan DS 4800 yüksek data transferinin olduğu yerlerde 1724 MBps bandwidth’e kadar çıkabilen birbirine yedekli 2 kontrol ünitesine sahip SATA ve FC Disk destekleyen disk sistemidir.

Bu disk depolama sistemi kendisine yine fiber kanaldan bağlı Expansion Unit’leri yöneterek çalışmaktadır. Expansion unit’lere 16 adet disk takılabilmektedir, bu diskler SATA yada Fiber Disk olabilir, hatta aynı Expansion Unitte istenirse hem SATA hemde FC Diskler birlikte çalıştırılabilir. 14 expansion Unit kullanılarak 224 disk takılarak max. Kapasitesi olan 168 TB raw kapasiteye ulaşılabilir.

                                   Genel Teknik Özellikleri

RAID controller

Dual, redundant ve hot-swap, write cache mirroring destekli 

Hız

4 Gbps

Bellek

4, 8, 16 GB cache  bellek modelleri vardır.

Raid Seçenekleri

0, 1, 3, 5, 10

Host Bağlantı Sayısı ( Server)

8 SAN bağlantısı direk yapılabilir. Üstü için FC Switch gereklidir.

Disk Desteği

SATA, FC Disk

Max. Disk Sayısı

224

Kontroller Özellikleri

Intel Xeon 2.4 Ghz, 512MB RAM,

Partition Sayısı

8,16,32,64 partition(lisans satın alınması gereklidir)

Rastgele Disk Okuma IO değerleri

62.000 / 85.000 IOPS

Rastgele Disk Yazma IO değerleri

16.000 / 22.000 IOPS

Kopyalama Özellikleri

FlashCopy®, Enhanced Remote Mirroring, VolumeCopy

İşletim Sistemi Desteği

Windows Server 2000 / 2003 / 2008
Novell Netware 6.5w/SP5
Red Hat Enterprise Linux 3.0 U7, 4.0 U3
Suse Linux Enterprise
VMWare ESX 2.5.2 ve 2.5.3
AIX 5.1, 5.2, 5.3
HP-UX 11.0, 11i, 11.23
Solaris 8, 9, 10

EXP810 Disk çekmecesi ( Expansion Unit )

İşletmelerin büyüyen yapıları beraberinde veri depolama alanında yeni ihtiyaçlara gereksinim doğurmuştur.  BT altyapılarında değişik ihtiyaçlara farklı senaryolarda cevap verecek nitelikteki bu storage sistemi çok basit olarak bir server’a fiber kanaldan bağlantı yapılarak SAN olarak konumlandırılarak kullanılabilir. Storage üzerindeki disklerden bir raid level’i seçilerek oluşturulan partition host’a ( server’a) map edilerek server’da local disk olarak görülebilir ve format atılarak kullanılabilir. Bu şekilde birden fazla server’a FC bağlantıları yapılarak, oluşturulan partitionlar(lun’lar) map edilerek kullanılabilir.

Tipik kullanımın dışında bu SAN Storage Disk sistemi Blade sunuculara bağlı olarak çalışabilir, Sanallaştırma ortamlarında konumlandırılabilir. Blade Sunuculara 4 GB hızında bir FC bağlantı yapılarak blade içerisindeki tüm sunuculara hizmet verilebilir. Sanallaştırma ortamlarında sanal makinelerin image dosyalarını buradaki lun’lardan boot ederek kullanabilirsiniz. İmage’larınız server’dan bağımsız bir storage üzerinden boot edildiğinden, server parkurunuzda oluşabilecek bir arıza durumunda hizmetlerin aksamadan devam etmesini sağlayabilirsiniz. Bir server’inizin fiziksel arızalanması ve kullanılamaz durumda olması durumunda sanal sunucularınızı farklı server’lar üzerine yönlendirerek boot ettirebilirsiniz, veri kaybına uğramadan kaldığınız yerden çalışmaya devam edebilirsiniz.

Storage sistemlerindeki en zor konulardan birisi de yedeklenmeleridir. Ciddi yatırımlar yaparak bir storage konumlandırması yapıldıktan, tüm yapı kurulduktan sonra, storage üzerinde yapılacak bir hatada yedeklerinizin olması gerekmektedir. Storage üzerinde yedekleme için FlashCopy, VolumeCopy ve Remote Mirroring kullanılabilir.

Farklı bir makalede yer aldığı için fazla üzerinde durmadan kısaca işlevlerini anlatacak olursak;
FlashCopy: Storage ortamında belli zaman aralıkları ile checkpoint’ler oluşturarak, geri dönüş yapmak için kullanılır.
VolumeCopy: Fiziksel klone’lar yaratmak için kullanılır.
Remote Mirroring: Disaster Recovery projelerinde farklı bir lokasyonda storage üzerindeki partition’u anlık olarak ve sürekli güncel olarak kopyalamak için kullanılır.

Tasarım: Bir storage projesi planlanırken gereksinimlerin iyi tespit edilmesi gerekmektedir. Tüm ihtiyaçlar çıkartıldıktan sonra en uygun tasarım ve planlama yapılabilir. En önemli unsur ihtiyaç duyulan kapasite olmakla birlikte cevaplanması gereken sorular; İhtiyaç duyulan kapasite miktarı, disk tipleri,  bağlantı kurulacak server sayısı, tanımlanacak olan partition sayısı, raid level’i, flashcopy vb. yazılım lisanslarına ihtiyaç duyulup duyulmadığıdır. Konuyu daha da açacak olursak;

· İhtiyaç duyulan veri depolama kapasitesini brüt ve net olarak çıkartılmadır.

· Raid Level’ları seçimi yapılırken dikkat edilmeli en uygun raid seviyesi seçilmelidir.

· Eğer bir MsSql, MySql, Oracle vb. bir veritabanı barındırılacaksa, yüksek performans için FC diskler seçilmelidir. Bir File Server olarak konumlandırılacaksa yada her türlü backup amaçları için SATA diskler seçilmelidir. SATA ve FC diskleri birlikte kullanılabilmesi bu storage’in büyük bir avantajıdır.

· Raid seviyelerinizi belirlerken hot spare disk tanımları yaparak fiziksel disk arızalanmalarına karşı önlem alınabilir. Hot Spare disk tanımlarındaki bir avantajda Global host spare tanımı yaparak bir diski birden fazla raid array’i için hot spare olarak bekletebilir ve gerektiğinde kullanabilirsiniz.

· İhtiyaç duyulan Partition sayısının tespiti ( lisans gerektirdiği için)

· Bağlantı yapılacak sunucu sayısının tespit edilmesi ( sunucu sayısı 8 in üzerinde ise FC Switch’e ihtiyaç duyulacaktır.)

· FlashCopy,VolumeCopy,Remote Mirroring gibi storage yazılımlarına ihtiyacın tespit edilmesidir.

· Sunuculara takılacak olan FC HBA’ların Single mı Dual mi olacakları ve sunucuya kaç adet FC HBA takılacağıdır.

Tasarım için gereksinimleri çıkarttıktan sonra storage projesi netleştirilerek fiyatlandırılabilir. Fiyat çalışmasında projenin büyüklüğüne göre belli oranlarda indirimler sizleri bekliyor olacak.  Gereksinimler doğru tespit edilirse, eksik ya da fazla projelendirmeye kurban gidilmez.

İhtiyaçlar doğrultusunda kaç disk, expansion unit ihtiyacınız çıktığında aşağıdaki gibi bir bağlantıyı tasarlayabilirsiniz. Bu tasarım; server’lardan bağımsız storage’in kendi içerisinde birbirine yedekli iki disk denetleyici ünitesinin expansion unit’lere olan bağlantı içindir.

DS4800 Expansion Module Cabling – Full bir DS 4800 için birbirine yedekli iki denetliyicinin(en üstteki), Expansion’lara kesintisiz bağlantısı. Bu bağlantı Fiber kablolama ile yapılmaktadır.

Bölüm 2’de Server bağlantısı, HBA’lar, Manager yazılımının tanıtımı ve kurulum bilgileri ile devam edeceğiz.

Kaynak: Resimler ve Teknik Değerler IBM’den Temin Edilmiştir

Yılmaz BARÇIN

IBM System Storage DS3000 Storage Manager yazılımı, sahip olduğumuz IBM DS3000 (3200, 3300,3400) Storage ürünlerimizi yapılandırmamıza, kullanıma hazır hale getirmemize ve kullanım sırasında ki hataları tespit etmemize yardımcı olacak bir yazılımdır. Donanımdan bağımsız olarak dizaynımızı tamamlandıktan sonra, storagemizi yapılandırmamız için ihtiyaç duymuş olduğumuz yazılımdır.

IBM System Storage DS3000 Storage Manager’imizi

• Windows XP
• Windows Server 2003 (SP1)
• Red Hat Enterprise Linux 3 ya da 4 (RHEL 3 yada 4)
• SUSE Linux Enterprise Server 9 yada 10 (SLES 9 yada 10)
• Not : Storage Manager yazılımı, NetWare işletim sistemi ortamı için henüz kullanılmamaktadır.

İşletim sistemlerimize yukleyerek yapılandırabiliriz. Yazılımımız ve sahip olduğu bileşenlerimizin ihtiyaç duymuş olduğu disk alanı ortalama olarak 150 MB’ dır.

Kurulum arayüzü çok basit olup, yazılımımızı Storagemiz içinden çıkan kurulum Cd’ si ile veya IBM’ in internet sitesinden ücretsiz olarak indirebileceğiniz kurulum dosyası ile yapılabilmektedir. İlk kurulum ekranında, Dil ayarlarını seçip ve sözleşmesini okuduktan sonra ilerliyoruz.

Storage Manager Yazılımımızı 4 farklı tipde kurabiliyoruz. Bunlar ;

Typical (Full Installation)            : Bu kurulum storage manager yazılımımız için ihtiyaç duymuş olduğumuz bütün bileşenleri sistemimize kurmaktadır.
Managment Station                      : Bu kurulum storagemizi yapılandırmak ve hataları izlemek için kurulmalıdır. Managment Station Kurulumu ile sadece SMClient programını kurmuş oluyoruz.
Host                                             : Storagemize bağlı serverlara kurmamız gerekmektedir. Bu Seçenek SMClient programı haricinde tüm bileşenleri kurmaktadır.
Custom                                        : Özel kurulum seçeneği olup, Cluster yapılarında ve bir Logical Driveri, birden fazla Host (server)’a bağlama ihtiyacımız olduğu durumlarda kurulmalıdır.

Custom Seçeneğini Seçerek kuruluma devam ediyoruz.

Custom Seçeneğinde Storage Manager 2 RDAC Driver’i seçili durumda değildir. Storagemiz üzerinde birden falza Controller (denetleyici) bulunuyorsa bu kutuyu seçmemiz gerekemktedir. Storage Manager 2 RDAC yazılımı storagemiz ile host’ lar arasında ki çoklu bağlantılarda, bağlantılardan bir tanesinde hata oluştuğu zaman diğer yol üzerinden sistem duraklamaksızın geçişin devam etmesini sağlayan bileşendir.

Eğer yukleyecek olduğumuz sistemde storport.sys yuklu değil ise yukarıda ki gibi hata ile karşılaşacaksınız ve kuruluma devam edemeyeceksiniz. RDAC yazılımı için ihtiyaç duyulan( W2003 Server) hotfixlerin adresi aşağıdadır.

Update for Windows Server 2003 x64 Edition (KB932755)
http://www.microsoft.com/downloadS/details.aspx?FamilyID=5ff8c152-9114-458f-86f9-01c2b8cac450&displaylang=en

Update for Windows Server 2003 x86 (KB932755)
http://www.microsoft.com/Downloads/details.aspx?FamilyID=dead950b-da47-4dc2-abcd-40f61bd4d1aa&displaylang=en

Gerekli hotfixleri yukledikten ve sistemimizi yeniden başlattıkdan sonra kurulumu yeniden başlatarak devam edebiliriz.

İhtiyaç duymuş olduğumuz bileşenleri yukledikten sonra Automatically Start Monitor kutusunu işaretleyip devam ediyoruz. Bu seçenek SMClient Programımız çalışmadığı zamanlar da, Storagemiz üzerinde ki hataları otomatik olarak algılamasına yardımcı olacaktır. Eğer ortamımızda birden fazla Storage Manager Yazılımı yuklu olan bilgisayar var ise bu seçeneği sadece sürekli olarak aktif durumda çalışan bilgisayar üzerinde seçilmesi gerekmektedir. Bunun nedeni ise aynı hatalar , sürekli olarak birden fazla bilgisayarda izlenilecek ve yanlış yorumlamalara sebep olması muhtemeldir.

Kurulum tamamlandıktan sonra sistemimizi yeniden başlatmamız gerekmektedir.

Storage Manager serverimiz açıldıktan sonra IBM System Storage DS3000 Storage Manager 2 (Enterprise Management) konsolu üzerinden, network içinde bulunan tüm IBM DS3000 Ailesi Storagelerimizi yönetebiliriz.

Konsolumuz ilk açıldığı zaman da Networkümüz içerisine Broadcast işlemi yaparak, network içinde ki bütün storageleri arıyor ve bulduklarını listesine eklemektedir. Daha önceki Storage Makalemizde bahsetmiş olduğumuz gibi Storagemiz üzerinde bulunan Controllerlar DHCP Bootable olup, ortamımızda bir dhcp var ise eğer DHCP Server üzerinden IP almak üzere dizayn edilmişlerdir. Eğer ortamımızda bir DHCP Server yok ise Storagemizin Controller A : 192.168.128.101 Controller B ise 192.168.128.102 olup, Storage Manager Serverimizin IP Bloğunu , Storaga Manager’ ımızın IP bloklarına getirip, Storaga Managerimizi Sahip olduğumuz Network bloğuna çektikten sonra Storagemizi kullanabiliriz.

DS3000 Storaga Manager 2 (Enterprise Managment) yazılımımızın, bulmuş olduğu Storagemizi yonetmek için ilgili storage üzerinde Manage Storage Subsystem bölümünü tıklıyouruz.

Karşımıza çıkan ekran, seçmiş olduğumuz storagemizin yönetimsel işlemlerini gerçekleştirecek olduğumuz IBM System Storage DS3000 Storage Manager 2 (Subsystem Managment)’ dır. Yani Enterprise managment bölümünün bir alt bölümü olan, seçmiş olduğumuz storagemizi yönetebileceğimiz programdır.

Yukarıda ki ekrandan da anlaşılacağı üzere storagemiz üzerinde hiç bir işlem yapılmamış ve yapılandırılmak üzere hazır beklemektedir. Menulerimizi inceleyecek olursak ;

Status : Bölümünde Storagemiz üzerinde yapmış olduğumuz işlemlerin durumunu inceliyoruz. Örnek olarak bir Array veya hot spare disk oluşturduğumuz zaman işlemin hangi aşamada olduğunu, işlemin devam edip etmediğini bu ekrandan görebilmekteyiz. Herhangi bir işlem yapmadığımız için şu anda Operation in Progress : 0 olarak görünmektedir.

Hardware Components : Bölümünde sahip olduğumuz donanımı görebilmekteyiz. 2 adet Controlleri olan bir adet Storage’  (enclosures) ye sahip durumdayız. Eğer storagemize EXP3000 ürünlerinin montajı yapılmış olsaydı bu sayıyının arttığını görebilecektik. 10 adet SAS diskimizin ve HotSpare olarak hiç birisinin ayrılmadığını görebilmekteyiz.

Capacity : Bölümü içinde sahip olduğumuz toplam disk sayısı ile yapabileceğimiz maksimum kapasiteyi – alanı görebilmekteyiz. 2788 Gb bölü 10 eşittir 270 Gb lık disklerimizin olduğunu ilgili bölümden görebiliyoruz ve herhangi bir yapılandırma yapmış durumda değiliz.

Host & Mappings : Bölümü içinde Storagemize bağlı bulunan serverları görebilmekteyiz. Daha doğrusu Storagemize bağlı ve tanımlanmış olan serverları – hostları görebilmekteyiz. Özetlemek gerekirse şu anda storagemize 4 adet server bağlı fakat bunların hiç birisini storagemize tanıtmış durumda olmadığımız için Host sayısı 0 olarak görünmektedir. Yapılandırmadan sonra değişiklikler gösterecektir. Storage Partition Hazır olarak 4 görünmektedir. Storagemiz ile birlikte varsayılan olarak 4 adet partition lisansı gelmektedir. Satın alacak olduğumuz partition lisansları ile bu sayıyı DS3000 ailesi içni en fazla 16 yapabilmekteyiz.

Arrays&Logical Drivers : Şuanda hiç bir array ve logical drivers oluşturulmadığını görebilmekteyiz.

Information Center : Bölümünde ise anlık olarak destek, yapılandırma için örnek dizaynlar ve yapılandırma adımlarını, planlama vb.. bilgileri alabilmemiz için geniş bir yardım menüsü bulunmaktadır.

Storagemizi menuler arasında gezinerek manuel olarak yapılandırabileceğimiz gibi Yazılımımızın en üst bölümünde bulunan Initial Setup Tasks bölümünden adım adım storagemizi yapılandırabiliriz.

Initial Setup Tasks Menusu Managerimiz ilk açıldığında zaten bizleri otomatik olarak karşılamaktadır.

1 nci işlem olarak Locate The Storage Subsystem bolumunu seçerek storagemizi etkinleştiriyoruz.

2 nci bölüm olarak Rename th Storage Subsystem bölümünden storagemize isim verebilmekteyiz. Aynı işlemi Tools bölümü içinden de yapabiliyoruz.

3 ncu bolum olarak Set a Storage Subsystem Password ile storagemiz üzerinde yapacak olduğumuz yonetimsel işlemler için parola ataması istiyoruz. Varsayılan olarak Parola Yoktur.

Not : Bilinmesi gerken en önemli konu, eğer vermiş olduğumuz parolayı unutursak, izleme haricinde hiç bir yonetimsel işlemi gerçekleştiremiyoruz. Parola sıfırlama işlemi ise Storagemiz arkasında bulunan Diagnostig Port Servicing bölümünden yapılmakta olup, bu portun kablosu Storagemiz ile çıkmamaktadır. İlgili Kablo IBM Turk ve IBM Garanti Hizmetleri Çözüm Ortakları ve IBM Çözüm ortaklarında bulunmaktadır. İşlem Garanti dışında yapılmaktadır. Özet olarak verecek olduğunuz parolayı unutmamanızı tavsiye etmekteyim.

Eğer vermiş olduğunuz parolayı unutursanız yürütecek olduğunuz komutlar kırmızı kalem ile yazılı olan komutlardır. Ve bilmeniz gereken en önemli konu komutları yazarken yazmış olduğunuz hiç bir şey görünmüyor, komutlar küçük-büyük harf duyarlı ve ilgili bölüme girdiğiniz zaman 5 saniye içerisinde komutları koşturmak zorundasınız. Zamanında komutları yazamazsanız bağlantı sonra ermektedir (time out). Ve en önemlisi komut yanlış koşturulursa Storageye zarar vemrekte olup, storage ofline duruma gelecektir.  Tekrardan hyper terminal bağlantısı ile online duruma getirmeniz gereklidir.

Yukarıda sayılan sebeplerden ötürü, işlem özel bir uygulama olduğu için konsol kablosu storage kutusu içinden çıkmamakta olup, satışı yoktur.

4 ncü ve 5 nci konular Serverların, hostların  erişimi ve izinler ile ilgili olduğu için diğer makalede anlatılmak üzere Optional bölüme geçiyoruz.

Optional Bölümde ki ilk bölüm View and Enable Premium Features olup bu bölüm içerisinde Storagemize bağlamış olduğumuz EXP 3000 ürünlerinin tanımlanması, Partition Expansion Lisansının yuklenmsi, Flash copy ve Volume Copy işlemlerinin aktif duruma getirilmesini yapabilmekteyiz.

Configure Ethernet Managment bölümünde ise DHCP Bootable olan Storagemizin IP adresini sabitleştiriyoruz. Controller A ve Controller B olarak İç networkumuzden iki farklı IP ataması gerçekleştiriyoruz.

Storagemiz üzerinde ki Controller’ ların IP atamalarını tamamladıktan sonra Subsystem Managment bölümünde yapacak olduğumuz temel yönetimsel işlemlerin bir çoğunu bitirmiş oluyoruz. Subsystem Managment bölümünden çıkıp, Enterprise managment bölümünde yeni atamış olduğumuz IP adresleri ile storagemizi yapılandıracağız.

Enterprise Managment Modulunda bulunan Storagemiz, DHCP Bootable olarak yapılandırılmıştı. Konsolumuz ilk açıldığı zaman kendisi otomatik olarak storagemizi bulmuş ve listemize eklemişti. Bu ve benzeri ürünlerin yönetimsel kolaylık ve ileride problem olmaması adına sabit IP adresine sahip olmaları gerektiği bilinmekte ve tavsiye edilmektedir. Bu sebeplerden ötürü IP mizi manuel’e çekmiştik ve Enterprise managment bölümü içinde de gerekli değişiklikleri yapmak üzere DHCP Bootable olan Storagemizi yonetim konsolundan siliyoruz.

Enterprise managment üzerinde Add Storage subsystem bölümünü tıklayarak storagemizi manuel olarak Enterprise managment bölümümüze yukluyoruz.

Controllerlarımıza vermiş olduğumuz manuel IP atamasını,  Firs (A Controller) ve Second (B Controller) bölümlerine yazarak storagemize bağlantımızı gereçekleştiriyoruz.

Enterprise managment bölümüne atama işlemi başarılı bir şekilde tamamlandıktan sonra başka bir storage ekleyip eklemeyeceğimiz konusunda bilgi vermektedir. Eğer networkümüzde birden fazla storagemiz var ise bu bölümde eklemeye devam edebiliriz.

Enterprise managment konsolu makalemizin başında söylemiş olduğumuz gibi çoklu storagelerimizi listelememize, görmemize ve uygun storage üzerinde işlemlerimizi yapmamız için yonlendiren bir bölümdür.

Storagemizi Enterprise managment bölümüne ekleme işlemi tamamlandıktan sonra manage Storage Subsystem bölümünden yönetimsel işlemlerimizi yapabiliriz.

Konu ile ilgili ikinci makalemizde HBA tanıtımı, Array ve Logical Disk oluşturulması ve paylaştırılması ve Serverlarımızın bu sürücüleri kullanmaları için gerekli yapılandırmaları yapazağız.

Fatih KARAALİOGLU

IBM DS 3300 Ürünü IBM Storage ve IBM Storage DS3000 Ailesinin ISCSI teknolojisini kullanan IP San Attach ürünüdür.

DS3300 ürünü, bağlı olduğu serverlara ve networke ISCSI (Internet Small Computer System Interface) teknolojisi ile iletişim kurmaktadır.

ISCSI Teknolojisi; TCP/IP alt yapısı kullanılan networklerde, SCSI Teknolojisinin IP Protokolü ile birleşmesi sonucu oluşmuş bir teknolojidir. IP ve SCSI teknolojisi için bir ara teknolojiside. İlk çıkmış olduğu zamanlarda sağlayacak olduğu performans süphe ile karşılanmıştır. Bunun sebebi ise TCP/IP Protokolü, Inbound/Outbound Bloğu için tasarlanmış bir teknoloji değildir. Fakat bütün bunlara rağmen gerek güvenlik gerekse performans açısından göstermiş olduğu değerler sayesinde bir çok networkde yer bulmuştur ve günümüzde sözünü geçiren bir teknolojidir. Performans değerleri, tamamen Network alt yapımızın hızına ve yol haritasına (roadmap) bağlı olarak değiştiği için değerlerinde net bir rakam verilememektedir. Ama bilinen bir gerçek 1 Gb/s ile 10 Gb/s arasında performanslar görülmektedir.

IBM DS ürünleri arasında tercih edilme sebebi olarak Network altyapımıza ve büyüme olasılığına karşın çok esnek olmasıdır. Network alt yapımız büyüdükçe, Storagemizi değişen network alt yapımıza göre çok kolaylık ile uyum sağlatabiliyoruz.

Fakat yapacak olduğumuz dizayn işleminde olası bir bottlenecks (darboğazı) ve loop’u ve paket droplanmasını hesaplanmamız gerekmektedir. Zaten bu sebeplerden ötürü ISCSI Teknolojilerinden sahip olduğumuz LAN Networkü ile ISCSI networkünü ayırmamız önerilmektedir. Gigabit portu olan ve clientlar ile aynı network içinde bulunan SW’ lere bağlanabilse de bu yapılandırma tavsiye edilmemektedir.

ISCSI Teknolojisinde, güvenliği üst düzeyde tutan tasarımcılar VLAN, VPN, IPSEC VPN gibi TCP/IP için dizayn edilmiş güvenlik teknolojilerini ISCSI Teknolojisi için de kullanabilmektedirler.

DS3300’ ün görünümü ve Fiziksel özellikleri diğer IBM DS 3000 Storage ailesi ürünleri ile aynı özelliklerde olup, enclosures’ın (kasa) arka bağlantı modulleri yukarıda ki resimde görünmektedir.

Storagemize Single (Tek) ve Dual (Çift) olma üzere iki ayrı ihtiyaca göre Raid Controller’i bulunmaktadır. Her bir Controller üzerinde iki ayrı Host giriş portu bulunmakta olup, Storagemizi ve Raid Controllerimizi yönetebilmek ve yapılandırmak için Ethernet giriş portu, Consol erişim portu ve Storagemizi büyütmek için HOST Expansion SAS girişi bulunmaktadır.

DS 3300 için bağlantı ve yapılandırma örnekleri ;

DS3300 Single Controller Entry Level: Single Server, Single Path (Giriş Seviyesi Tek Denetleycili Tek Server bağlantılı)

Yapılandırma için ihtiyaç duymuş olduğumuz ürünler;

S. IBM System Storage DS3300

H. IBM Qlogic iSCSI Single-Port PCI-e HBA for IBM System x

F. 1 G Ethernet Switch

C. Ethernet Cable

Yukarıda ki dizayn içinde Tek Bir Serverimizi (host), hiç bir fault torelance teknolojisi kullanmaksızın dizaynını gerçekleştiriyoruz. Ethernet SW den Storagenin Controllerina gerçekleştirilen bağlantı hız ve kablo için fault torelance için gerçekleştirilmiştir. Bu bağlantı Tek bir kablo ile de yapılabilmektedir.

DS3300 Single Controller: Single Server, Dual Path with Dual Port HBA (Giriş Seviyesi, Tek denetleyicili Dual HBA ile bağlantı)

Yapılandırma için ihtiyaç duymuş olduğumuz ürünler;

S. IBM System Storage DS3300

H. IBM Qlogic iSCSI Dual-Port PCI-e HBA for IBM System x

F. 1 G Ethernet Switch

C. Ethernet Cable

Bağlantı çeşidi, ilk dizaynımıza göre aynı olup tek fark HBA (Host Bus Adapter)’ dedir. Daha önce yayınlamış olduğumuz DS 3200 makalemizde Dual HBA örneği verilmemişti. Sebebi ise DS 3200 için Dual HBA Bulunmamasıdır. Bu seviyeden sonra Tek bir tane HBA üzerinden, storagemize bağlantıyı Dual (çift) kablo ile gerçekleştirebileceğiz.

Bu yapılandırmada ki amacımız Serverimiz (host) üzerinde ki HBA’ ların fault torelancesini sağlamak değil Storage ile yapmış olduğumuz kablo bağlantısının Fault torelancesini sağlamaktır. Kullanım amacı daha çok ilgili Host üzerinde uygun sayıda giriş yuvası yok ise tercih edilecek bir teknolojidir. Eğer Hostumuz da yeterli sayıda yuva bulunmakta ise Single (tek) çıkışlı, iki adet fiziksel HBA nın kullanılmasıdır ki bu bağlantı sayesinde HBA’ larımızın da Fault torelance teknolojisinden yararlandırmamız olmasıdır.

Dual HBA kullanılan yapılarda bilinmesi gereken en önemli hususlardan bir tanesi HBA üzerinde gelen port girişlerinden bir tanesi Pasif durumda olmasıdır. Diğer portumuzu aktif duruma getirebilmek için fiziksel bağlantı gerçekleştikten sonra, serverimiz açılırken, HBA’ nın BIOS’ una girebilmemiz için bizi yönlendirecektir. Bu yonlendirem sonrasında HBA’ nızın diğer portunu aktif duruma getirebiliriz. Ayrıntılı bilgiyi http://publib.boulder.ibm.com/infocenter/systems/scope/hw/topic/iphcz/iphczbook.pdf ilgili linkinden temin edebilirsiniz.

Konu dışı bir bilgi vermek gerekirse, hiç bir fiziksel diski bulunmayan serverlarımızı Storagemize bağlayabiliyoruz. Bu bağlantı sonrasında Storagenin disklerini yine bu BIOS bölümünden serverlarımızı gösterebilmekteyiz.

DS3300 Single Controller: Three Servers, Single Path (3 Server Tek Denetleyicili bağlantı)

Yapılandırma için ihtiyaç duymuş olduğumuz ürünler;

S. IBM System Storage DS3300

H. IBM Qlogic iSCSI Single-Port PCI-e HBA for IBM System x

F. 1 G Ethernet Switch

C. Ethernet Cable

Yukarıda ki bağlantıda 3 farklı serverimizi hiç bir fault torelance mimarisi kullanılmaksızın Storagemize bağlantısını görmekteyiz.

DS3300 Single Controller: Three Servers, Dual Path with Dual Port HBAs (3 server, Dual HBA ile bağlantısı)

Yapılandırma için ihtiyaç duymuş olduğumuz ürünler;

S. IBM System Storage DS3300

H. IBM Qlogic iSCSI Dual-Port PCI-e HBA for IBM System x N/A

F. 1 G Ethernet Switch N/A 1

C. Ethernet Cable

Yukarıda ki bağlantıda 3 farklı serverimizi, HBA lerimizden Serverlarımıza olan bağlantı kablosunun yedekli olduğunu görebilmekteyiz. HBAS larımız için bir Fault Torelance düşünülmemiştir.

DS3300 Dual Controller: Single Server, Single Path (Tek Server, Tek HBA, Çift Raid Denetliyicili bağlantı)

Yapılandırma için ihtiyaç duymuş olduğumuz ürünler;

S. IBM System Storage DS3300

H. IBM Qlogic iSCSI Single-Port PCI-e HBA for IBM System x

F. 1 G Ethernet Switch

C. Ethernet Cable

Yukarıda ki bağlantıda Storagemiz üzerinde ki RAID Denetleyicimiz için Fault Torelance mimarisi kullanılmıştır. İlgili bağlantıda Storagemiz üzerinden her bir bağlantı Storagemizin iki ayrı Controllerina bağlanarak , kontrollerimizin (RAID Denetleyicimizin) hata şansı düşünülmüştür.

DS3300 Dual Controller: Single Server, Dual Path with Dual Port HBA (Tek server, Dual HBA, Çift Denetleyicili bağlantı)

Yapılandırma için ihtiyaç duymuş olduğumuz ürünler;

S. IBM System Storage DS3300

H. IBM Qlogic iSCSI Dual-Port PCI-e HBA for IBM System x

F. Ethernet Switch

C. Ethernet Cable

Bir önceki dizaynımıza göre HBA’ dan Storagemize olan kablo bağlantısının Dual HBA ile yedeklendiğini görebilmekteyiz.

DS3300 Dual Controller: Three Servers, Dual Path with Redundant Switches (3 server, Çift Raid Denetleyicisi, Yedekli SW bağlantısı)

Yapılandırma için ihtiyaç duymuş olduğumuz ürünler;

S. IBM System Storage DS3300

H. IBM Qlogic iSCSI Dual-Port PCI-e HBA for IBM System x

F. 1 G Ethernet Switch

C. Ethernet Cable

Yukarıda ki teknolojide DS3300 ürün ailesi için olabilecek en iyi fault torelance mimarisini görebilmekteyiz.

Host (Server)’ larımız üzerinde bulunan HBA lar Redundant (yedekli) olup, her bir portundan , SW’i mize olan bağlantı ayrı ayrı gitmektedir.

İki ayrı SW’ imizden Storagemiz üzerinde ki iki ayrı denetleyiciye bağlantı farklı gitmektedir.

Fault Torelance için dizayn edilmiş bu  yapıda Capraz (Cros) lama bağlantılar gerçekleştirilerek, Gerek HBA’ dan SW’ e olan kablo arızasında, HBA üzerinde ki Port arızasında, Ethernet SW ve Storage üzerinde ki Denetleyicilerimizin arıza durumuna karşın olması muhtemel bütün senaryolar düşünülerek dizayn edilmiş bir yapıdır.

Bu yapıya ilave olarak HBA’ larımızı Single olarak yapıp, serverlarımız üzerinde uygun slot sayısı var ise eğer Tek bir Server, İki fiziksel HBA ile yapımıza HBA larımız için olası bir arıza durumunda iş sürekliliği katmış oluruz.

Fatih KARAALİOGLU