Kategori arşivi: IBM

IBM Spectrum Storage Suite

Software Defined Storage – Yazılım Temelli Depolama (SDS), herhangi bir donanım ve/veya atıl sunuculara kurulabilen, geleneksel depolama servislerinin sunabileceği tüm özellikleri sunabilme kapasitesine sahip, yazılım çözümüdür. Geleneksel mimari ile karşılayamadığımız ihtiyaçlarımız için IBM Spectrum Ürün Ailesini ile karşılayabiliyoruz.

IBM Spectrum Ürün Ailesi birçok farklı kabiliyeti ile ihtiyaçlarınızı tek bir lisans altında veya tek tek seçebileceğiniz ürünleri ile karşılıyor. Marka ve depolama teknolojinizden bağımsız olarak tüm analitik veri yönetimini, soğuk verileriniz ve güncel veri yönetiminiz dahil olmak üzere, arşivleme, sanallaştırma, izleme ve tüm ortamınızın ölçeklenebilir olmasını sağlayabilirsiniz.

Buraya kadar her şey güzel, peki kim kullanıyor bunu deyince aslında suite içerisinde aşağıdaki başlıkları pek çok müşterinin kullandığını ancak IBM ın ürün ismi değişikliği nedeni ile direkt spectrum diye sorunca pek bilinmediğini fark ettim. IBM benim için yeni bir alan yavaş yavaş öğreniyoruz 🙂

Spectrum:
Protect = TSM – Tivoli Storage Manager
Control = TPC
Scale =GPFS
Archive =LTFS
Virtualize =SVC
Accalerate = XiV

Tam olarak paket içerisinde aşağıdaki ürünler yer almaktadır;

IBM Spectrum Accelerate™ V11.5
IBM Spectrum Archive™ Enterprise Edition V1.2 (Linux™ edition)
IBM Spectrum Control™ Advanced Edition V5.2
IBM Spectrum Protect™ Suite V7.1
IBM Spectrum Scale™ Advanced and Standard Editions (Protocols) V4.2
IBM Spectrum Virtualize™ Software for SAN Volume Controller V7.6
IBM Spectrum Virtualize Software for SAN Volume Controller V7.6 (Real-time Compression™)
IBM Spectrum Virtualize Software for SAN Volume Controller V7.6 (Encryption Software)

Peki sizde benim gibi bu konuda yeni misiniz? Veya hali hazırda sağlam bir IBM kullanıcısı mısınız? Temel ve daha derin bilgi için sizleri 20 Aralık Çarşamba günü saat 11:00′ de Tech Data Uzmanları ile beraber gerçekleştireceğimiz Web seminerine bekliyoruz;

7 Önemli Çözüm Tek Lisansta – Rakipsiz Kabiliyetleriyle IBM Spectrum Ailesi

http://etkinlik.cozumpark.com/etkinlik/7-onemli-cozum-tek-lisansta-%E2%80%93-rakipsiz-kabiliyetleriyle-ibm-spectrum-ailesi/768

 

IBM Spectrum Storage Suite

IBM yazılım, donanım ve bulut konularındaki uzmanlığı ile BT yatırımlarınızın yönetimini kolaylaştırıyor ve gözle görülür bir maliyet avantajı sağlıyor. IBM Spectrum Ürün Ailesi birçok farklı kabiliyeti ile ihtiyaçlarınızı tek bir lisans altında veya tek tek seçebileceğiniz ürünleri ile karşılıyor. Marka ve depolama teknolojinizden bağımsız olarak tüm analitik veri yönetimini, soğuk verileriniz ve güncel veri yönetiminiz dahil olmak üzere, arşivleme, sanallaştırma, izleme ve tüm ortamınızın ölçeklenebilir olmasını sağlayabilirsiniz.  Yeni uygulamalar; gelişen teknoloji ile birlikte hayatımıza giren, ‘’big data’’, “mobil uygulamalar’’, ‘’sosyal media’’ ve bunun gibi inovatif ve farklı tipte farklı yapıda ve içerikte, analiz edilecek ve saklanacak yeni veri tipleri oluşturmaktadır. Software Defined Depolama (SDS), her hangi bir donanım ve/veya atıl sunuculara kurulabilen, geleneksel depolama servislerinin yapabildiği her şeyi yapabilme kapasitesine sahip yazılım çözümüdür. Geleneksel mimari ile karşılayamadığımız ihtiyaçlarımız için IBM Spectrum Ürün Ailesi için çözümlere linke tıklayarak ulaşabilirsiniz.

http://www.ts.avnet.com/tr/suppliers/ibm/spectrum.html

DBMoto Gercek Zamanli Veri Replikasyonu ve Veri Entegrasyonu

Replikasyon, verileri kaynak(lardan) alıp farklı hedef(lere) taşıma işlemidir. DBMoto, enterprise server ve desktoplarınızın ihtiyacı olan gerçek zamanlı veri replikasyonunu ve transformasyonunu sağlar. Günümüzün kurumsal iş uygulamalarının verileri çok sayıda veritabanı üzerinde olabilmektedir. Müşterilerinizi gerçek zamanlı cevaplarla destekleyebilmek, yöneticileri en son metric ve finansal raporlarla desteklemek, satıcılarınızı veya bayilerinizi anlık-kritik bilgilerle donatmak için gereken bilgiler core ilişkisel veritabanınızdan gelir. Bunun için kurumlar veritabanı platformları arasında veri taşınmasına ihtiyaç duyarlar. Uygulamaların performanslı çalışabilmesi için de ilişkisel veritabanları arasında hızlı veri aktarımına(delivery) ihtiyaç vardır. DBMoto bunların tümünü ve daha fazlasını gerçekleştirir.

image001

Nerede, Neden Kullanılır?

· Belli zaman dilimlerinde veya eş zamanlı(real-time) ve/veya eşlenik(syncronization) olarak veritabanınızın bir kısmını veya tümünü ve/veya yaptığınız tüm değişiklikleri başka bir veritabanına transfer ederek,

o Veriambarı(Datawarehouse) veritabanını oluşturabilirsiniz.

o Productiondaki veritabanının/veritabanların performansını yükseltmek için raporlamaları replike veritabanını kullanabilirsiniz.

o As/400lerinizdeki(iSeries) istediğiniz verileri DB2dan farklı bir veritabanına replike ederek kolay erişilebilirliği sağlayabilirsiniz.

o Vb.

Replikasyon Nedir Nerede kullanılır cevaplarını verdikten sonra dbmoto replikasyon programın kurulum desteklediği veritabanı modellerini inceleyelim.

Dbmoto Özellikleri

· Eş-Zamanlı veri replikasyonu ve dönüşümü

· Windows’ta çalışır ve replikasyonları uzaktan yönetebilir

· Kaynak ve hedef veritabanları herhangi bir platformda çalışabilir

· Kolay replikasyon kurulumu için adım adım kullanıcı sihirbazı

· Kolay kurulum, yapılandırma ve kullanım

· Eksiksiz replikasyon kontrolü için scriptleme ve filtreleme özellikleri

· Scripting ile kişiselleştirmeye izin veren tek real-time data replication yazılımıdır.

· Kaynak veritabanında program veya tablolarlarda hiçbir değişiklik gerektirmez.

· Stored Procedureler gerektirmez.

· Kendine has öğrenilmesi gereken yeni bir syntaxı yoktur.

· Kaynak sistemlerde herhangi bir program çalışması gerektirmez.

· Kullanıcı-dostu ara yüzü, olaylar(events), detaylı ve kişiselleştirilebilir loglama ve güçlü scripting özelliği ile replikasyonu kolaylaştırır.

· http://www.esc.com.tr/english/productdetay.aspx?no=240 sayfasından ücretsiz deneme versiyonu indirilebilir (30 günlük).

Dbmoto Faydaları

· Daha hızlı kararlar ve daha kazançlı ticari işlemler için veriyi şirket kullanıcılarına taşır (iletir).

· Veriyi düşük “Toplam Satın Alma” ve “Toplam Sahip Olma Maliyeti” ile veritabanlarına replike ederek şirketlerin bu veriyi production veritabanlarından çıkarmasına imkan verir.

· Eski bilgi sistemlerinin replikasyonu için uygun, yeni sistemlerle birlikte çalıştırabilen ve maliyet-etkin bir yapı sunar

· Kolay kurulum, konfigürasyon ve kullanım

· Kaynak ve hedef veritabanlarında ve uygulamalarda şeffaftır

Desteklediği Veritabanları

image002

image003

Dbmoto Replication Modelleri

3 farklı replikasyon söz konusudur. Replikasyon türlerinden bahsetmek gerekirse;

Full Refresh

Full refresh replikasyon manuel olarak veya zamanlanarak istenilen tarih ve zamanda başlatılabilir.

Bütün veri(filtre kriterlerine ve kolon seçimine bağlı olarak) kaynaktan hedef veritabanına transfer edilir.

image004

Gerçek Zamanlı Mirroring

Gerçek zamanlı mirroring sadece değişen transaction loglardan otomatik olarak yakalar ve hedef veritabanına yazar.

Sadece değişen kayıtları yönetmenin sağladıkları:

Gerçek zamanlı replication yapılabilir.

Kaynak ve hedef sistemlerde minimal CPU yükü

image005

Sekronizasyon

Gerçek zamanlı synchronization mirroring’in iki yönlü olarak uygulanmasıdır. image006

image007

VBScript Environment

Güçlü bir scripting environment kullanıcının fonksiyonlara ve/ya prosedürlere karar vermesini sağlar. VBScript fonksiyonu üç alanda kullanılabilir:

Mapping kriteri

DestinationField = VBSFunction (SourceFields)

Replikasyon olayları

Kaynak veritabanındaki değişiklikler yakalanır

– DBMoto VBScript olayları yaratır

Olay VBScript kodu tarafından yönetilir

E-posta Yollama

– Herhangi bir VBScript diyalogundan yollanabilir.

DBMoto ve diğer çözümlerin karşılaştırılması

image008

Kurulum Gereksinimleri

· DBReplicator çalışacağı sunucunun işlemcisi En az 2 GH veya daha üstü olmalıdır. (Pentium 4 veya Yükseği)

· DBReplicator çalıştırmak için en az 512 mb memory önerilir. Minimum 256 mb memory’dir

· NET framework 2.0 veya üzeri kurulu olmalıdır.

· Kullanmak istediğiniz replikasyon için, database bağlantısı için .NET OLE DB veya ODBC gerekmektedir.

· Eğer Oracle kaynak hedef veya metadata database olarak kullanıyor ise oracle client dbmotonun sistem üzerinde kurulu olmalıdır.

· Eğer iseries/as400 üzerinde ibm db2 kullanıyorsanız işletim sistemi en az v3r2 olmalıdır.

· Eğer IBM db2 source database olarak kullanacaksanız aşağıdaki versionlar desteklenmektedir.

· DB2 UDB v.7.2 veya üstü

· DB2 for OS390 v6 veya üstü

· Windows Server 2008

· Windows 2003/2000/NT Server

· .NET Framework 1.1 or higher

Kurulum işlemine başlıyoruz.

Resim–1

image009

Resim–2

Lisans sözleşmesini kabul edip devam ediyoruz.

image010

Resim–3

image011

Resim–4

Daha önceden http://www.hitsw.com/products_services/register/register_dbmoto.html?utm_campaign=download&utm_medium=webpage&utm_source=button&utm_content=dbmoto adresinden aldığım 30 günlük deneme lisansını import ediyorum.

image012

Resim–5

image013

Resim–6

image014

Resim–7

Kurulum işlemi tamamlandıktan sonra programı çalıştırıyoruz.

image015

Resim–8

Başlat-çalıştır-services. msc yazıp dbmoto servisini kontrol ediyoruz.

image016

Sonraki makalemde birden fazla farklı kaynak veritabanından bir veya birden fazla hedef veritabanına Dbmoto ile replikasyon işlemini inceleyeceğiz.

Kaynak: http://www.hitsw.com/cgi-bin/hitsw_kbase.pl

Onur CAN

IBM X 3650 Server Montaj Asamaları

Çö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.

image001

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

image002

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

image003

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

image004

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

image005

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

image006

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.

image007

image008

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

image009

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

image010

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.

image011

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.

image012

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

image013

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

image014

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.

image015

Ü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

Fault Tolerance Senaryoları (High Availability – Yuksek Erişebilirlik Çözümleri)

Üstatlarımızın, bizden önce ki sisteme gönül veren, ömür adayan büyüklerimizin güvenlik ile ilgili olarak söylemiş oldukları temel söz ve ilk güvenlik temeli , mevcut sahip olunan datalarımızın Backup’ larını almaktır. Büyüklerimiz yavaş yavaş emekliye ayrılarak yerlerini bizlere, günümüz sistemcilerine devrettiler. Ve büyüklerimizin bizlere bırakmış oldukları bu temel felsefe aklımızda – zihnimizde barınmakta olup, hemen hemen her sistem dizaynımızda sürekli yer bulmaktadır. Mutlak suretle her projemiz içine bir backup çözümü barındırsakta bizler için öncelikli bir güvenlik çözümü değildir. Artık bir gereklilik –  zorunluk haline gelmiştir.

Nedeni ise onlar ile birlikte güvenlik anlayışının ölçüleri değişmiş olmasından kaynaklanmaktadır. Üstatlarımızın bizlere göre yaşamış olduğu en belirgin sıkıntılar, sistemin çökmesi, çalışmanın durması, data kaybının yaşanmasıydı. Şimdiki sistemciler, onların yaşamış olduğu sıkıntıları günümüzde de yaşasak dahi, bizleri bekleyen daha çok gelişmiş problemler yer almakdır.

Internet dünyasının , günümüzde neredeyse zorunlu bir hal alması ve hemen hemen her ihtiyacımızın bu internet denen teknoloji ile yapılması, evlerimize ve hatta çocuklarımızın – bebelerimizin bir çok ihtiyacını dahi bu teknoloji ile görür hala gelmemiz, bunun yanında bir çok dez avantajı da yanında birlikte getirdi.

Intenet dünyasında, virüslerin, spamların, spy yazılımların ortalıkta çok rahatlıkla dolaşırken, kötü amaçlı yazılımcılar ortalıkta cirit atarken, bizler de büyüklerimizden gelen güvenlik aylayışını değiştirdik ve kendi, günümüzün gerektirmiş olduğu çözümleri güvenlik dalına soktuk, ve büyüklerimizin temel güvenlik anlayısını, güvenlik dalından çıkararak bir gereklilik olarak farklı bir çözüm olarak sunmaya başladık.

Bizler, günümüzün yeni sistemcileri Güvenlik anlayışımızı her ne kadar günümüz şartlarının gerektirdiği şekilde yapmaya özen göstersekte, büyüklerimizden , bizlere miras kalan backup çözümünü her zaman için kullanmaktayız.

Elbetteki bu çözümler günümüz şartlarına göre değişkenlikler göstermekte olup Cluster yapıları, Farmlar ,  Sistem odası ve Network alt yapımızda ki ürünler ile çeşitli dizaynlar ile yapımızı geliştirmekteyiz.

Bu saymış olduğumuz hiç bir teknoloji (Cluster, Farm, NLB ) ismi ne bir backuplama çözümüdür , nede bir güvenlik çözümüdür. Ama sistemin sürekliliğini ve kararlılığını sağlamak adına yapılması gereken zorunlu çözümlerdir.

 

image001

 

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.

 

image002

 

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.

 

image003

 

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.

 

image004

 

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.

 

image005

 

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.

 

image006

 

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.

 

image007

 

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 4800 Disk Storage System – Bölüm 3

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.   

image001 

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. 

image002 
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. 

image003  

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.

image004  

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.  

image005  

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

image006  

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.) 

image007  

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. 

image008

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. 

image009  

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.  

image010  

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

IBM System Storage DS3000 Storage Manager PART 2 ( Host – Array – Logical Driver ve Hot Spare )

 

 

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.

 

 

 

image001

 

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.

image002

 

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.

 

image003

 

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.

 

image004

 

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ı.)

 

image005

 

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.

 

image006

 

Ş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.

 

image007

 

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.

 

image008

 

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.

 

image009

 

İş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.

 

image010

 

İş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.

 

image011

 

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.

 

image012

 

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.

 

image013

 

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.

 

image014

 

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.

 

image015

 

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.

 

image016

 

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

 

image017

 

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.

 

image018

 

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.

 

image019

 

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.

 

image020

 

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.

 

image021

 

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.

 

image022

 

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.

 

image023

 

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.

 

image024

 

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.

 

image025

 

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.

 

image026

 

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.

 

image027

 

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.

 

image028

 

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.

 

image029

 

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.

 

image030

 

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.

 

image031

 

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 DS 4800 Disk Storage System – Bölüm 2

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) 

image001  

Yukarıdaki resimde örnek resimde en yüksek güvenilirlikli bağlantıyı single port ile görmekteyiz. 1 ve 2 numara ile adlandırılan DS 4800 Storage’ımızın kontrol ünüteleridir. Orta bolumde FC Switch’leri görmekteyiz. Ve 3-4 te iki farklı server’ın FC HBA’larının FC Switch’e çapraz bağlarını görebilmekteyiz. Bu bağlantı da storage ile sunucu arasında ki bağlantı her noktada birbirine yedeklenmiştir.

 

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.)

 

image002  

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.

 

image003  

Ö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.

image004

 

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

Storage Nedir ? ve IBM DS 3000 Storage Ailesi

Günümüz de şirketlerin artan dataları ve bu datalara gerektiği zaman hızlı bir şekilde erişim ihtiyaçları, küçük-büyük her şirketin ihtiyaç duymuş olduğu önemli bir gereksinimdir. Günümüz iş hayatında, rekabetçi piyasa koşulları içinde, sahip olduğumuz data en büyük kozumuzdur. Ve sahip olduğumuz bu datalarımız, zamanı geldiği zaman rakiplerimizi yenmemiz için en büyük silah olmaktadır. Bu silahı iyi bir şekilde saklamak ve yeri geldiği zaman hızlı ve etkin bir biçimde kullanmak şirketin büyümesinde ki en etkin rol olmaktadır.

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

IBM DS 3200 Serisi Storage ve Bağlantı Teknolojisi (SAS Serial Attached SCSI )

IBM DS 3200 Ürünü IBM Storage ve Ds Ailesinin giriş seviyesinde ürünü olup storage teknolojisinde External DAS teknolojisini kullanmaktadır.

 

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.

 

image001

 

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

 

image002

 

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)

 

image003

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)

 

image004

 

İ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)

 

image005

 

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ı)

 

image006

 

İ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)

 

image007

 

İ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ı)

 

image008

 

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