Etiket arşivi: hyper-v failover

Hyper-V FailOver Cluster Bolum 4 (Hyper-V NOD’ un Yapilandirilmesi)

 

FailOver Cluster Farmı içine dahil edecek olduğumuz Nod’ larımız üzerine Windows server 2008 FailOver Cluster Servisimizi yüklemeden önce , kontrol etmemiz gereken bir takım işlemler bulunmaktadır.

Daha önce ki makalelerimiz de, FailOver Cluster Servisini yuklemeden once NOD larımızın yapılandırmalarından bahsetmiştik. Bu Nod yapılandırmamıza geçmeden önce ki hazırlıklarımızı tekrardan hatırlayacak olursak ;

  • FailOver Cluster Farmı içine dahil edilecek olan her bir NOD’ umuz aynı ActiveDrictory ortamının üyesi,
  • Aynı DNS Servisini kullanmaktalar.
  • Ortak bir shared disk ile bağlantıları bulunmakta ve ortak olarak kullanmaktalar.
  • Aynı fiziksel Marka-Model /Aynı kaynaklara sahip serverlardan oluşmakta.
  • Her bir fiziksel serverimiz üzerinde Windows Server 2008 64 BIT ENT/DC (full/core) kurulumu gerçekleştirilmiştir.
  • Her bir NOD üzerine Hyper-V Servisi yuklu durumdadır.

Temel ihtiyaçlarımızın kontrolünü gerçekleştirdikten sonra Hyper-V Nod’ larımızın yapılandırılmasına başlayabiliriz.

MPIO (Microsoft Multipath Input/Output) Yapılandırılması.

 

MPIO yani MultiPathhing cözümü, Cluster Farmı içinde bulunan NOD ların, Ortak shared disk üzerinde oluşturulan Logical Drivers’ lara, redundant (yedekli) olarak bağlantısının kontrolü için kullanılmaktadır. Redundant bağlantıda kontrol edilen ekipmanlar,

Nod’ lar üzerinde ki ;

  • Host Bust Adapters
  • Fiziksel NOD ile Storage arasında ki kablo bağlantıları (SAS,FC, Network Kabloları)
  • ISCSI Storage kullanılıyorsa eğer ROUTER, SW,
  • SAN SW

Ekipmanları kontrol edilmektedir.

MPIO özelliğinin ana temel özelliği FailOver Cluster Servisinin sağlıklı bir şekilde çalışıp çalışmaması için kontrolleri yapmaktadır. Yukarıda bahsetmiş olduğumuz her bir bileşenin – ekipmanın, kuracak olduğumuz FailOver Cluster ortamı içinde birden fazla olması gerekemktedir.

Sebebi ise FailOver Cluster mantığını tekrardan hatırlarsak, aynı Servis ve Uygulama, birden fazla Fiziksel Server hizmet etmekte ve Fiziksel Serverlardan bir tanesi başarısız olursa, diğer Fiziksel Server görevi üstlenmesi ve iş sürekliliğini sağlamasıydı. MPIO özelliği bu noktada devreye girmekte olup, FailOver Cluster servisini kurmadan önce Her bir Fiziksel NOD üzerinde ki ekipmanların yedekli olup olmadığı ayrıca kontrol etmektedir.

image001

 

Yukarıdaki resimde, ISCSI storage için yapılandırılmış basit bir topolojiyi görebilmekteyiz.

Topolojide anlatılan;

  • Ortak Shared disk olan storage üzerine
  • İki farklı Routerden – ayrı ayrı bağlantılar gitmektedir.
  • Her bir Router üzerinden, her bir fiziksel server üzerine ayrı-ayrı fiziksel bağlantı gerçekleştirilmiştir.
  • Fiziksel Server üzerinde gösterilen HBA ‘ ler redundant yani bir den fazladır.
  • Düz çizgi ile gerçekleştirilen bağlantı Aktif
  • Kesik çizgi ile gerçekleştirilen bağlantı ise pasif olarak adlandırılmaktadır.

image002

 

Microsoft MPIO özelliği, oluşabilecek herhangi bir hata anında, hatayı otomatik olarak algılayacak şekilde dizayn edilmiştir.

Yukarıda ki topolojide Routerlardan bir tanesinin hataya mağruz kaldığını görebilmekteyiz. MPIO servisi, oluşan bu hatayı otomatik olarak algılamakta ve servis kesintisi yaşanmaması için bağlantıları diğer Router üzerinden gerçekleşmesini sağlayacaktır.

Resimde verilen örnek ISCSI Storage için kullanılan Routerlar için verilmiştir. Eğer bizler HBA, Cablo ve Storage üzerinde ki farklı controllerlar üzerinde hata yaşamış olsaydık, MPIO özelliği; yaşayacak olduğumuz bu hata içinde aynı işlemi gerçekleştirecek ve redundant ekipman üzerinden görevi sürdürecekti.

 

 

image003

 

MPIO özelliği, Fiziksel serverlarımızın üzerine bağlamış olduğumuz çoklu HBA lerin tanıtılmasının ardından, otomatik olarak kurulabildiği gibi (HBA ların özelliklerine göre değişkenlik gösterebilir), bizler FailOver Cluster hizmetini kurarken otomatik olarak kurulabilmektedir.

Tavsiye edilen, HBA ların tanıtılmasından sonra MPIO servisinin kurulup – kurulmadığının kontrol edilmesi. Kurulmadıysa eğer FailOver Cluster Servisi kurulmadan önce manuel olarak MPIO özelliğinin kurulmasıdır.

MPIO özelliğini Server manager içinde, features bölümüne girerek Multipath I/O bölümünü seçip kurabilmekteyiz.

 

image004

Kurulum sonrasında Administrator Tool bölümüne giriş yapıp, MPIO özelliği doğru bir şekilde kurulup kurulmadığını kontrol etmemiz gerekmektedir.

 

image005

MPIO Properties bölümü içine girdiğimiz zaman, MPIO-ed Devices bölümü altında, Ortak shared diskimiz olan Storagemizin özelliklerini, kodunu ve driverlarının yüklü olduğunu görebilmekteyiz.

Yukarıda ki kodlar IBM Ds 3000 Serisi Storage ye ait olup, Device Hardware ID bölümünde ki kodları, sahip olduğumuz storagenin üreticisinin sağlamış olduğu kaynaklardan elde edebiliriz.

Eğer bu kodlar yanlış ise doğru sürücüler ile üreticinin sağlamış olduğu sürücüleri ile yeniden yüklememiz gerekmektedir. Bu işlemlerin her birini FailOver cluster servisini kurmadan gerçekleştirmemiz gerekmektedir.

Cluster NOD Network Yapılandırılması

 

Nod’ larımız üzerinde ki yapılandırmada ikinci kontrol edecek olduğumuz ve yapılandırmasını yapacak olduğumuz bölüm Network özellikleridir.

Daha önce ki makalemizde Heartbeat yapılandırmasından bahsetmiştik. Şimdi ise bu Heartbeat network yapılandırılmasının nasıl yapıldığını inceleyelim.

 

image006

Yukarıda ki resimde 2 tane fiziksel 1 tane sanal (Hyper-V Servisinin kurulumu ile birlikte oluşan Virtual Network) Network Interface Card  görebilmekteyiz.

İki tane fiziksel kartlarımız;

10.10.10.X networkünde bulunan kartımız  LAN (1)’ dir. Local Area networkümüze bağlantısı gerçekleştirilen kartımızdır. Serverlarımız Clientlarımıza bu NIC üzerinden hizmet edecektir.

Hyper-V servisinin kurulması ile birlikte bu kartımıza ayrılan bir tane de Sanal olarak Virtual Network oluşturulmuş olup bu kartımız ise Local Area Connections 2 (1) ismini almıştır.

 

image007

Heartbeat olarak yapılandıracak olduğumuz kartımızı kontrol edecek olursak Local Networkümüzden farklı IP bloğunda olduğunuz görebilmekteyiz. Heartbeat hattımız 192.168.10.X Bloğundadır. Diğer fiziksel Serverimiz ile Cros Kablo ile bağlantısı gerçekleştirilmiştir.

Not : Heartbeat olarak yapılandırılacak olan NIC’ lerin isimleri aynı olmak zorundadır.

 

 

image008

 

 

Serverimiz üzerinde Network Connections bölümüne gelip, Advanced Settings bölümüne giriş yapıyoruz.

 

image009

Advanced Setting bölümünde, öncelikli olarak kontrol edilecek NIC’ in Heartbeat kartının olacağını belirtiyoruz.

Bu işlemleri her iki NOD’ u muz üzerinde yapmamız gerekmektedir.

 

image010

Heartbeat networkümüz, Local Networkümüze hizmet etmeyecektir.  Local Networkümüz içinde barınan hiç bir kullanıcımız bu NIC’ ler üzerinden Serverimiza erişmeyeceği için, bu NIC ‘ imize atayacak olduğumuz IP adresinin DNS kayıtları içinde yer almasına gerek bulunmamaktadır. Bu sebepten ötürü NIC karımız üzerinde Register this connection’s addresses in DNS seçimini temizliyoruz.

 

image011

Heartbeat olarak yapılandırmış olduğumuz NIC’ ler üzerinde gerçekleştirecek olduğumuz diğer bir işlem ise Disable NetBIOS over TCP/IP seçimini temizlememizdir.

NIC lerimiz üzerinde yapmış olduğumuz bu işlemlerde ki amaç, Heartbeat networkumuzun performansını arttırmak içindir. Zorunlu bir seçim olmamak ile birlikte – performans açısından yapılması gerekli uygulamalardır.

 

 

image012

 

Network topopojimizi toparlayacak olursak, yukarıda ki resimde görüldüğü gibi

Heartbeat Networkü için ayrılmış fiziksel olarak iki tane NIC görebilmekteyiz. Bu NIC’ ler birbirleri ile CROS kablo yardımıyla bağlanmış durumdadır. Eğer Cluster Farmı içinde bulunan serverlarımızın Sayısı iki ve üzeri olursa burada ki networkümüzü SW/Router’ lar ile çoğaltabilmekteyiz. Windows FailOver cluster servisi 16 serverlık bir farma izin verebilmektedir.

Fiziksel Serverlarımızın üzerinde bulunan ikinci Network Kartı ise Local areamıza hizmet etmekte olup – farklı bir Network ID’ sine sahiptir.

Fatih KARAALIOGLU

Hyper-V FailOver Cluster Bolum 1 (Nedir – Kullanim Amacimiz Nedir)

Sanallaştırma için bu güne kadar sürekli olarak geleceğin teknolojisi olarak sıfatlandırdık. Değişen ve hızlı bir şekilde büyüyen teknoloji sayesinde artık bu sıfat Geleceğin Teknolojisi sıfatından kurtulup, Günümüzün Teknolojisi sıfatını almış durumdadır.

Bu güne kadar bir çok kez, gerek portalımız üzerinde gerekse diğer paylaşım ortamları ve sanallaştırma ürün üreticilerinin yapmış olduğu bilgilendirmelerde Sanallaştırmanın yararları, Toplam Sahip olma maaliyetlerinde ki avantajları gibi nedenleri konuştuk-tartıştık ve bunların neticesinde Networklerimizin içine dahil ettik.

Sanallaştımanın avantajları biliniyor. Bu sebepten ötürü sanallaştırmanın avantajlarından ziyade, sanal ortamlarımızı iyi bir şekilde yapılandırmazsak eğer yaşayacak olduğumuz problemlerden bahsedeceğiz. Geçmiş zamanda Microsoft Türkiye Ofisinde Gerçekleştirilen Sanallaştırma Etkinliğinde Intel’ in bir sunumu vardı ve ufak bir kelime oyunu ile bu konumuza çok güzel ışık tutuyordu. Sunum içinde ufak bir kelime oyunu ile Sanallaştır-MA ! diyor ve kelime oyunundan sonra dinleyicilerin nabzını-tepkisini kontrol edip, Plansız-Programsız Sanallaştırma diyerek sunuma devam ediyordu. Sanallaştırma kelime oyununun altında yatan nedenleri bu yazımız ile başlayıp, yazı diziminizn ilerleyen kısımlarında devam edeceğiz. Yazı dizimizin içeriğinde  ;

  1. Hyper-V FailOver Cluster Bolum 1 (Nedir ? Kullanım Amacimiz nedir ?)
  2. Hyper-V FailOver Cluster Bolum 2 (FailOver Cluster Senaryoları ve Lisanslamasi)
  3. Hyper-V FailOver Cluster Bolum 3 (Donanım ve Yazılım İhtiyaçlarımız)
  4. Hyper-V FailOver Cluster Bolum 4 (Hyper-V NOD’ un Yapılandırılması)
  5. Hyper-V FailOver Cluster Bolum 5 (Kurulum ve Yapılandırma Adımları)
  6. Hyper-V FailOver Cluster Bolum 6 (Sanal Makine Yapılandırılması)
  7. Hyper-V FailOver Cluster Bolum 7 (Planlı ve Plansız Down Time)

Paylaşımlarını barındıracağız ve bu paylaşımlarımızı WebCastler – Videolar ve Forumlarımızın yardımları ile sağlamlaştıracağız.

image001

Yukarıda ki resim Intel’ in yapmış olduğu sunumdan referans alarak hazırlanmıştır. Resmin bizlere anlatmak istediği ise Sanallaştırma ile birlikte kazanmış olduğumuz Toplam Sahip olma maaliyetlerini göstermektedir.

2004 yılında, saniyede 5.1 Milyon işlemi 126 adet sunucu gerçekleştirirken, günümüzde ise aynı işlemi, aynı süre içerisinde 17 sunucu başarabilmektedir. Bizler 126 sunucudan kurtulup, aynı işlemi Sanallaştırma teknolojisi yardımı ile 17 sunucu üzerinde gerçekleştirebilmekteyiz. Ve bunların neticiseinde kazanmış olduğumuz toplam sahip olma maaliyetleri, bizlerin şirket bütçelerine getirmiş olduğu avantaj ve bilgi işlem departmanlarının iş yükünün ve kısıtlı alan hacimlerinden tasarruf etmesi olarak geri dönmektedir.

image002

Intel’ in aynı sunumu içinde yer alan bir diğer ekran görüntüsü ise yukarıda ki resimde görünmektedir. Yukarıda ki resimde anlatılan, Intel firmasının Senelere oran ile büyümesinden bahsedilmektedir.

Intel Firmasının,

  • 2007 Yılında çıkartmış olduğu Xeon 3.16 12 M L2 işlemcisi
  • 2001 yılı içinde çıkartmış olduğu Xeon 1.26 512 Kb L2 işlemcisine göre

19.8 Kat daha hızlı çalışmaktadır.

Bu resim ile birlikte Konumuza giriş yapmak üzereyiz. Yukarıda ki resimde Intel’ in Sunum içinde yaptığı gibi işlemci sektöründe ki büyümesini paylaşmayacağım. Benim bu resimde bahsedecek olduğum konu, intelin bu resmini kullanarak FailOver Cluster hizmetinin kullanım amacından bahsedeceğim.

Yukarıda ki resime göre, örnek bir şirket server yapısını masaya yatırıyoruz.

Bahsetmiş olduğumuz firma 2001 yılında, çeşitli kullanım amacı için, farklı görevlerde çalışmak üzere 19 tane Xeon 1.26 512KB L2 Cache CPU özelliğine sahip serverlar almış.

Firmamız; Sanallaştırmanın yararları, yani toplam sahip olma maaliyetlerini göz önünde bulundurduğu zaman, elektirik, destek ve yer problemlerini ortadan kaldırmak istediği zaman 19 tane farklı Sunucuyu,  Xeon 3.16 12M L2 Cache özelliğinde ki bir CPU ya sahip 1 tane sunucu üzerinde sanallaştırma teknolojisini kullanarak  tasarrufa gidebilir.

(Sanallaştır-MA kelime oyununa bu parantez içinde ayrıca bilgi vermek isterim. Sahip olduğumuz, bu 19 tane sunucunun sanallaştırma ortamında hizmet edip edemeyeceğini daha önceden planlamamız gerekmektedir.

Yani Plansız-Programsız sanallaştırma ortamına geçiş yapmadan önce Hyper-V’ nin desteklemiş olduğu sunucu rollerini ve servislerini , daha önceden aşağıda ki makaleden inceleyerek hayata geçirmenizi tavsiye edeceğim.

http://support.microsoft.com/kb/957006/ )

Sahip olduğumuz 19 Farklı sunucunun üzerinde çalışan Görev ve hizmetlerin Sanallaştırma ortamı için uyumlu olduğu bilgisini aldık. Intel’ in raporuna göre 19 tane sunucumuzu – 1 tane sunucu üzerinde konsolide edebilmekteyiz. Sanallaştırma teknolojisi ile birlikte bunuda başardık. Peki ama bizi bekleyen Risk – Problemler nedir ?

19 tane sunucumuzu, 1 tane sunucu olarak konsolide etmeden önce, sahip olduğumuz bu 19 sunucudan her hangi bir tanesi Fiziksel olarak arızalı duruma düştüğü zaman, arızalı duruma düşen Görev için hizmet kesintisi yaşamaktaydık.

Şimdi ise 19 fiziksel sunucu  , tek 1 tane fiziksel sunucumuz üzerinde bulunamkta ve sahip olduğumuz bu fiziksel sunucu hata durumuna düştüğü zaman hizmet kesintisinden 19 tane sanal sunucumuz etkilenecek ve iş sürekliliğimiz kesintiye uğrayacaktır.

Belik de, bu şekilde bir  Felaket senaryosu ile karşılaştığımız zaman, sanallaştırma ile birlikte kazanmış olduğumuz büyüyenn maaliyetlerimizi düşürme amacımız, hizmet kesintisi ile birlikte bizlere zarar olarak geri dönecektir. Plansız-Programsız sanallaştırma yapmayalım derken, ikinci olarak bahsedecek olduğumuz asıl konuda budur.

Bizlerin, Sektörün ve Ürün üreticilerin önerdiği, her zaman için böylesine çoklu platform sanallaştırmalarını, sahip olduğumuz tek bir sunucu desteklese dahi yapmamızdır.

Hyper-V servisi, arka tarafta Windows Server 2008’ in FailOver Cluster Servisini kullanmakta olup, sanal ortamlarımız için High Available (Yüksek Erişilebilirlik) Teknolojisi üzerinde çalışabilmektedir.

Sanal ortamlarımızı FailOver Cluster Servisi ile destekleyerek sanal ortamlarımızın yaşam süresini sürekli olarak UP-Time olarak tutmamız önerilmektedir.

image003

FailOver Cluster Servisi ; Cluster, hizmet ve uygulamaların kullanılabilirliğini artırmak için birlikte çalışan bağımsız bilgisayarların oluşturduğu bir gruptur. Kümelenmiş sunucular (Cluster Servers adı verilir) fiziksel kablolarla ve yazılımlarla bağlanır. Sunuculardan biri başarısız olursa, başka bir sunucu Failover adı verilen bir işlem sayesinde hizmet sunmaya başlar.

http://www.cozumpark.com/blogs/windows_server/archive/2009/03/22/microsoft-failover-cluster.aspx

Windows Server 2008 FailOver Cluster Servisi ile birlikte kazanacak olduğumuz avantajlar;

image004

· High Available (Yuksek Erişilebilirlik) (Plansız Donw Time)

Cluster Farmı içinde hizmet eden sunuculardan bir tanesi başarısız durumda olduğu zaman (Donanımsal hata, Yazılımsal hata, Elektirik hatası), cluster farmı içinde bulunan Sunuculardan bir tanesi, hatalı durumda olan Sunucunun görevlerini üzerine otomatik olarak almaktadır.

Hatalı durumda bulunan sunuculardan bir tanesi , hatalı duruma geldiği zaman, üzerinde barınan Sanal sunucular kapanacak ve Cluster farmı içinde bulunan, en uygun durumda ki sunucu üzerinde ve/veya özel bir kural oluşturduysak Cluster farmı içinde bulunan istemiş olduğumuz sunucu üzerine tekrardan açılacaktır.

Yaşanılacak olan hizmet kesintisi ortalama olarak 3 dakikadır. 3 dakika sonra, kesintiye uğrayan hizmet tekrardan hizmet etmeye devam edecektir. Elbbette ki bu süre, sahip olduğumuz fiziksel sunucular, shared disk ve bağlantı teknolojileri ve sanal sunucu üzerinde ki hizmetlerin rollerine bağlı olarak değişkenlik gösterecektir.

image005

· Quick Migration (Planlı Down Time)

HA daki Plansız Hizmet Kesintisinin aksine, Planlı olarak bizlerin isteği doğrultusunda , Quick Migration özelliğini iş sürekliliğimizi, sürekli olarak çalışır durumda tutmak istediğimiz zaman kullanacak olduğumuz bir özelliktir.

Cluster Farmı içinde bulunan Sunucularımız üzerinde planlı olarak hizmet kesintisi yapacağımız zaman kullanılacaktır.

Quick Migration Kullanım amaçları;

  • Donanımsal Server Bakımı
  • Donanım Güncelleştirmesi
  • Yazılım Güncelleştirmesi
  • Yazılımsal Server Bakımı

Yapacağımız zaman, yukarıda ki maddeleri yapacak olduğumuz Cluster farmı üyesi olan sunucu üzerinde ki,  sanal sunucularımızı, cluster farmı içinde bulunan, en müsait durumda olan sunucu üzerine transfer etmemize demektedir.

Bakım yapacak olduğumuz fiziksel sunucu üzerinde ki bütün sanal sunucuları, Cluster farmı içinde ki başka bir sunucuya aktardığımız zaman bakım işlemlerine başlayabiliriz.

Quick Migration Özelliğinde ki hizmet kesintisi ortalama olarak 30 Saniyedir.

Elbbette ki bu süre, sahip olduğumuz fiziksel sunucular, shared disk ve bağlantı teknolojilerilere bağlı olarak değişkenlik gösterecektir.

Taşıyacak olduğumuz Sanal sunucu, bir sunucudan, diğer bir sunucuya taşınırken, barınmış olduğu sunucu üzerine Save State durumunda beklemekte ve diğer fiziksel sunucu üzerine taşındıktan sonra tekrardan çalışmaya devam etmektedir. Sanal sunucu re-start işlemine uğramamaktadır.

Not :

FailOver cluster Farmı içinde bulunan her bir Fiziksel Sunucunun aynı özellikte olması gerekememektedir. Farklı marka-modele sahip, ve sanallaştırma teknolojisini destekleyen her bir sunucu FailOver Cluster Farmının üyesi olarak yapılandırılabilir. Fakat her zaman için önerilen Cluster Farmı içinde bulunan Sunucuların Aynı Marka-Model ve özelliklerde, kaynaklarda olması tavsiye edilmektedir.

Quick Migration özelliğini kullanacağımız zaman, eğer Cluster farmı içinde bulunan bir sunucudan – diğer bir sunucuya taşıma işlemini yaptığımızda, işlemi yapılan fiziksel sunucuların CPU ları aynı değil ise taşınma işlemi sırasında Sanal sunucu Save State durumunda olmayacaktır. Taşınacak olan Fiziksel sunucu üzerinde Re-start olacak ve taşınan fiziksel sunucu üzerinde tekrardan başlatılacaktır.

· Live Migration (Planlı Down Time)

Live Migration Özelliği Windows Server 2008 R2 ile birlikte hayatımıza giren yeni bir özellik olup, R2 kurulmamış bulunan Hyper-V Serverlar üzerinde çalışmamaktadır.

Kullanım amacı Quick Migration özelliği ile aynı olup, Live migration Özelliği ile kazanacak olduğumuz avantaj Hizmet Kesintisinin 0 (sıfır) saniye olmasıdır. Taşıma işlemi yapılırken iş sürekliliğinde bir kesinti olmamakta ve aynı zamanda taşınma işlemi sırasında bizler çalışmalarımızı sürdürebilmekteyiz.

Bu özelliklerin her biri, diğer sanallaştırma ürün üreticilerinde ki gibi ücretli olmayaıp, Microsoft’ un ücretsiz olarak sunmuş olduğu bir hizmetdir.

Fatih KARAALIOGLU

Hyper-V FailOver Cluster Bolum 1 (Nedir – Kullanim Amacimiz Nedir)

Sanallaştırma için bu güne kadar sürekli olarak geleceğin teknolojisi olarak sıfatlandırdık. Değişen ve hızlı bir şekilde büyüyen teknoloji sayesinde artık bu sıfat Geleceğin Teknolojisi sıfatından kurtulup, Günümüzün Teknolojisi sıfatını almış durumdadır.

Bu güne kadar bir çok kez, gerek portalımız üzerinde gerekse diğer paylaşım ortamları ve sanallaştırma ürün üreticilerinin yapmış olduğu bilgilendirmelerde Sanallaştırmanın yararları, Toplam Sahip olma maaliyetlerinde ki avantajları gibi nedenleri konuştuk-tartıştık ve bunların neticesinde Networklerimizin içine dahil ettik.

Sanallaştımanın avantajları biliniyor. Bu sebepten ötürü sanallaştırmanın avantajlarından ziyade, sanal ortamlarımızı iyi bir şekilde yapılandırmazsak eğer yaşayacak olduğumuz problemlerden bahsedeceğiz. Geçmiş zamanda Microsoft Türkiye Ofisinde Gerçekleştirilen Sanallaştırma Etkinliğinde Intel’ in bir sunumu vardı ve ufak bir kelime oyunu ile bu konumuza çok güzel ışık tutuyordu. Sunum içinde ufak bir kelime oyunu ile Sanallaştır-MA ! diyor ve kelime oyunundan sonra dinleyicilerin nabzını-tepkisini kontrol edip, Plansız-Programsız Sanallaştırma diyerek sunuma devam ediyordu. Sanallaştırma kelime oyununun altında yatan nedenleri bu yazımız ile başlayıp, yazı diziminizn ilerleyen kısımlarında devam edeceğiz. Yazı dizimizin içeriğinde  ;

  1. Hyper-V FailOver Cluster Bolum 1 (Nedir ? Kullanım Amacimiz nedir ?)
  2. Hyper-V FailOver Cluster Bolum 2 (FailOver Cluster Senaryoları ve Lisanslamasi)
  3. Hyper-V FailOver Cluster Bolum 3 (Donanım ve Yazılım İhtiyaçlarımız)
  4. Hyper-V FailOver Cluster Bolum 4 (Hyper-V NOD’ un Yapılandırılması)
  5. Hyper-V FailOver Cluster Bolum 5 (Kurulum ve Yapılandırma Adımları)
  6. Hyper-V FailOver Cluster Bolum 6 (Sanal Makine Yapılandırılması)
  7. Hyper-V FailOver Cluster Bolum 7 (Planlı ve Plansız Down Time)

Paylaşımlarını barındıracağız ve bu paylaşımlarımızı WebCastler – Videolar ve Forumlarımızın yardımları ile sağlamlaştıracağız.

image001

Yukarıda ki resim Intel’ in yapmış olduğu sunumdan referans alarak hazırlanmıştır. Resmin bizlere anlatmak istediği ise Sanallaştırma ile birlikte kazanmış olduğumuz Toplam Sahip olma maaliyetlerini göstermektedir.

2004 yılında, saniyede 5.1 Milyon işlemi 126 adet sunucu gerçekleştirirken, günümüzde ise aynı işlemi, aynı süre içerisinde 17 sunucu başarabilmektedir. Bizler 126 sunucudan kurtulup, aynı işlemi Sanallaştırma teknolojisi yardımı ile 17 sunucu üzerinde gerçekleştirebilmekteyiz. Ve bunların neticiseinde kazanmış olduğumuz toplam sahip olma maaliyetleri, bizlerin şirket bütçelerine getirmiş olduğu avantaj ve bilgi işlem departmanlarının iş yükünün ve kısıtlı alan hacimlerinden tasarruf etmesi olarak geri dönmektedir.

image002

Intel’ in aynı sunumu içinde yer alan bir diğer ekran görüntüsü ise yukarıda ki resimde görünmektedir. Yukarıda ki resimde anlatılan, Intel firmasının Senelere oran ile büyümesinden bahsedilmektedir.

Intel Firmasının,

  • 2007 Yılında çıkartmış olduğu Xeon 3.16 12 M L2 işlemcisi
  • 2001 yılı içinde çıkartmış olduğu Xeon 1.26 512 Kb L2 işlemcisine göre

19.8 Kat daha hızlı çalışmaktadır.

Bu resim ile birlikte Konumuza giriş yapmak üzereyiz. Yukarıda ki resimde Intel’ in Sunum içinde yaptığı gibi işlemci sektöründe ki büyümesini paylaşmayacağım. Benim bu resimde bahsedecek olduğum konu, intelin bu resmini kullanarak FailOver Cluster hizmetinin kullanım amacından bahsedeceğim.

Yukarıda ki resime göre, örnek bir şirket server yapısını masaya yatırıyoruz.

Bahsetmiş olduğumuz firma 2001 yılında, çeşitli kullanım amacı için, farklı görevlerde çalışmak üzere 19 tane Xeon 1.26 512KB L2 Cache CPU özelliğine sahip serverlar almış.

Firmamız; Sanallaştırmanın yararları, yani toplam sahip olma maaliyetlerini göz önünde bulundurduğu zaman, elektirik, destek ve yer problemlerini ortadan kaldırmak istediği zaman 19 tane farklı Sunucuyu,  Xeon 3.16 12M L2 Cache özelliğinde ki bir CPU ya sahip 1 tane sunucu üzerinde sanallaştırma teknolojisini kullanarak  tasarrufa gidebilir.

(Sanallaştır-MA kelime oyununa bu parantez içinde ayrıca bilgi vermek isterim. Sahip olduğumuz, bu 19 tane sunucunun sanallaştırma ortamında hizmet edip edemeyeceğini daha önceden planlamamız gerekmektedir.

Yani Plansız-Programsız sanallaştırma ortamına geçiş yapmadan önce Hyper-V’ nin desteklemiş olduğu sunucu rollerini ve servislerini , daha önceden aşağıda ki makaleden inceleyerek hayata geçirmenizi tavsiye edeceğim.

http://support.microsoft.com/kb/957006/ )

Sahip olduğumuz 19 Farklı sunucunun üzerinde çalışan Görev ve hizmetlerin Sanallaştırma ortamı için uyumlu olduğu bilgisini aldık. Intel’ in raporuna göre 19 tane sunucumuzu – 1 tane sunucu üzerinde konsolide edebilmekteyiz. Sanallaştırma teknolojisi ile birlikte bunuda başardık. Peki ama bizi bekleyen Risk – Problemler nedir ?

19 tane sunucumuzu, 1 tane sunucu olarak konsolide etmeden önce, sahip olduğumuz bu 19 sunucudan her hangi bir tanesi Fiziksel olarak arızalı duruma düştüğü zaman, arızalı duruma düşen Görev için hizmet kesintisi yaşamaktaydık.

Şimdi ise 19 fiziksel sunucu  , tek 1 tane fiziksel sunucumuz üzerinde bulunamkta ve sahip olduğumuz bu fiziksel sunucu hata durumuna düştüğü zaman hizmet kesintisinden 19 tane sanal sunucumuz etkilenecek ve iş sürekliliğimiz kesintiye uğrayacaktır.

Belik de, bu şekilde bir  Felaket senaryosu ile karşılaştığımız zaman, sanallaştırma ile birlikte kazanmış olduğumuz büyüyenn maaliyetlerimizi düşürme amacımız, hizmet kesintisi ile birlikte bizlere zarar olarak geri dönecektir. Plansız-Programsız sanallaştırma yapmayalım derken, ikinci olarak bahsedecek olduğumuz asıl konuda budur.

Bizlerin, Sektörün ve Ürün üreticilerin önerdiği, her zaman için böylesine çoklu platform sanallaştırmalarını, sahip olduğumuz tek bir sunucu desteklese dahi yapmamızdır.

Hyper-V servisi, arka tarafta Windows Server 2008’ in FailOver Cluster Servisini kullanmakta olup, sanal ortamlarımız için High Available (Yüksek Erişilebilirlik) Teknolojisi üzerinde çalışabilmektedir.

Sanal ortamlarımızı FailOver Cluster Servisi ile destekleyerek sanal ortamlarımızın yaşam süresini sürekli olarak UP-Time olarak tutmamız önerilmektedir.

image003

FailOver Cluster Servisi ; Cluster, hizmet ve uygulamaların kullanılabilirliğini artırmak için birlikte çalışan bağımsız bilgisayarların oluşturduğu bir gruptur. Kümelenmiş sunucular (Cluster Servers adı verilir) fiziksel kablolarla ve yazılımlarla bağlanır. Sunuculardan biri başarısız olursa, başka bir sunucu Failover adı verilen bir işlem sayesinde hizmet sunmaya başlar.

http://www.cozumpark.com/blogs/windows_server/archive/2009/03/22/microsoft-failover-cluster.aspx

Windows Server 2008 FailOver Cluster Servisi ile birlikte kazanacak olduğumuz avantajlar;

image004

· High Available (Yuksek Erişilebilirlik) (Plansız Donw Time)

Cluster Farmı içinde hizmet eden sunuculardan bir tanesi başarısız durumda olduğu zaman (Donanımsal hata, Yazılımsal hata, Elektirik hatası), cluster farmı içinde bulunan Sunuculardan bir tanesi, hatalı durumda olan Sunucunun görevlerini üzerine otomatik olarak almaktadır.

Hatalı durumda bulunan sunuculardan bir tanesi , hatalı duruma geldiği zaman, üzerinde barınan Sanal sunucular kapanacak ve Cluster farmı içinde bulunan, en uygun durumda ki sunucu üzerinde ve/veya özel bir kural oluşturduysak Cluster farmı içinde bulunan istemiş olduğumuz sunucu üzerine tekrardan açılacaktır.

Yaşanılacak olan hizmet kesintisi ortalama olarak 3 dakikadır. 3 dakika sonra, kesintiye uğrayan hizmet tekrardan hizmet etmeye devam edecektir. Elbbette ki bu süre, sahip olduğumuz fiziksel sunucular, shared disk ve bağlantı teknolojileri ve sanal sunucu üzerinde ki hizmetlerin rollerine bağlı olarak değişkenlik gösterecektir.

image005

· Quick Migration (Planlı Down Time)

HA daki Plansız Hizmet Kesintisinin aksine, Planlı olarak bizlerin isteği doğrultusunda , Quick Migration özelliğini iş sürekliliğimizi, sürekli olarak çalışır durumda tutmak istediğimiz zaman kullanacak olduğumuz bir özelliktir.

Cluster Farmı içinde bulunan Sunucularımız üzerinde planlı olarak hizmet kesintisi yapacağımız zaman kullanılacaktır.

Quick Migration Kullanım amaçları;

  • Donanımsal Server Bakımı
  • Donanım Güncelleştirmesi
  • Yazılım Güncelleştirmesi
  • Yazılımsal Server Bakımı

Yapacağımız zaman, yukarıda ki maddeleri yapacak olduğumuz Cluster farmı üyesi olan sunucu üzerinde ki,  sanal sunucularımızı, cluster farmı içinde bulunan, en müsait durumda olan sunucu üzerine transfer etmemize demektedir.

Bakım yapacak olduğumuz fiziksel sunucu üzerinde ki bütün sanal sunucuları, Cluster farmı içinde ki başka bir sunucuya aktardığımız zaman bakım işlemlerine başlayabiliriz.

Quick Migration Özelliğinde ki hizmet kesintisi ortalama olarak 30 Saniyedir.

Elbbette ki bu süre, sahip olduğumuz fiziksel sunucular, shared disk ve bağlantı teknolojilerilere bağlı olarak değişkenlik gösterecektir.

Taşıyacak olduğumuz Sanal sunucu, bir sunucudan, diğer bir sunucuya taşınırken, barınmış olduğu sunucu üzerine Save State durumunda beklemekte ve diğer fiziksel sunucu üzerine taşındıktan sonra tekrardan çalışmaya devam etmektedir. Sanal sunucu re-start işlemine uğramamaktadır.

Not :

FailOver cluster Farmı içinde bulunan her bir Fiziksel Sunucunun aynı özellikte olması gerekememektedir. Farklı marka-modele sahip, ve sanallaştırma teknolojisini destekleyen her bir sunucu FailOver Cluster Farmının üyesi olarak yapılandırılabilir. Fakat her zaman için önerilen Cluster Farmı içinde bulunan Sunucuların Aynı Marka-Model ve özelliklerde, kaynaklarda olması tavsiye edilmektedir.

Quick Migration özelliğini kullanacağımız zaman, eğer Cluster farmı içinde bulunan bir sunucudan – diğer bir sunucuya taşıma işlemini yaptığımızda, işlemi yapılan fiziksel sunucuların CPU ları aynı değil ise taşınma işlemi sırasında Sanal sunucu Save State durumunda olmayacaktır. Taşınacak olan Fiziksel sunucu üzerinde Re-start olacak ve taşınan fiziksel sunucu üzerinde tekrardan başlatılacaktır.

· Live Migration (Planlı Down Time)

Live Migration Özelliği Windows Server 2008 R2 ile birlikte hayatımıza giren yeni bir özellik olup, R2 kurulmamış bulunan Hyper-V Serverlar üzerinde çalışmamaktadır.

Kullanım amacı Quick Migration özelliği ile aynı olup, Live migration Özelliği ile kazanacak olduğumuz avantaj Hizmet Kesintisinin 0 (sıfır) saniye olmasıdır. Taşıma işlemi yapılırken iş sürekliliğinde bir kesinti olmamakta ve aynı zamanda taşınma işlemi sırasında bizler çalışmalarımızı sürdürebilmekteyiz.

Bu özelliklerin her biri, diğer sanallaştırma ürün üreticilerinde ki gibi ücretli olmayaıp, Microsoft’ un ücretsiz olarak sunmuş olduğu bir hizmetdir.

Fatih KARAALIOGLU

Hyper-V Failover Cluster Senaryoları

Önceki yazılarımızda Hyper-V kurulumu, özellikleri, sanal makine işlemleri gibi temel konuları ayrıntılı bir şekilde incelemiştik.

 

Bildiğiniz gibi Hyper-V RTM durumda ve pruduction networklerde kullanıma hazır. Kısa bir süre sonra Virtual Machine Manager 2008 ‘inde release olması ile birlikte Hyper-V sanallaştırma yapılarımız çok daha esnek, güçlü ve kullanışlı hale gelecek.

 

Şimdiye kadar olan makalelerimizde genellikle tek başına çalışan Hyper-V sunuculardan bahsettik. Ama birçok sistemde olduğu Hyper-V sunucular için de kullanılabilecek Cluster (Failover) senaryoları mevcut.

 

Bu makalemizde, Hyper-V sunucular için uygulayabileceğimiz Failover Cluster senaryolarından bahsedeceğiz.  Bu senaryoların uygulama yöntemlerini ise ilerleyen günlerde ele alacağız.

 

Bildiğiniz gibi Cluster yapılarında bir takım kıstaslar mevcut ki en önemli iki kıstas, ortak bir storage ve Cluster destekli (Enterprise, Datacenter, HPC) bir işletim sistemidir. Çünkü cluster yapılarında depolama biriminin (storage) ortak kullanılması gerekmektedir.

 

Hyper-V üzerinde uygulayabileceğimiz temelde 6 Farklı Failover Cluster senaryosundan bahsedebiliriz.

 

 

1. Fail Server Based Failover Cluster

 

Bu senaryoda storage olarak kullanabileceğimiz birim bir File Server dır. Evet yanlış okumadınız, File Server üzerinde share edilmiş bir dizini kullanacağız.

 

Aşağıdaki diagram’ı inceleyelim.

 

image001

 

 

Görmüş olduğunuz gibi iki adet fiziksel Hyper-V sunucumuz var. Bu yapıdaki her bir sunucuyu Node olarak adlandırabiliriz. Yani iki Node’a sahibiz. Ayrıca networkte çalışan bir File Server var (FServer1). Network iletişimi ise IP yani Ethernet üzerinden sağlanıyor. SAN (FC yada İSCSI) tarzı bir depolama birimi kullanılmıyor.

 

Daha önceki makalelerimizde, VM’lerin (Sanal makine) sanal disklerinin VHD formatında (Virtual Hard Disk) olduğundan bahsetmiştik. Fail Server Based Failover Cluster senaryosunda VHD dosyaları, networkte çalışan File Server üzerinde tutulmaktadır.

 

Diagram’a göre devam edersek; FServer1 üzerinde C: sürücüsünde VMDisks isimli bir dizin yaratılır ve paylaşıma açılır. Gerekli share ve security izinleri tanımlanır. Daha sonra VHD dosyaları bu dizin içerisine taşınır.

 

Bir sonraki adım olarak Hyper-V1 yani ilk node üzerinde \\FServer1\VMDisks yolu ağ sürücüsü olarak MAP edilir ve içerisindeki VHD dosyası VM’e gösterilebilir. 

 

Eğer MAP yapmak istemiyorsak, VM üzerinde kullanılacak VHD dosyasını direk \\FServer1\VMDisks olarak ta gösterebiliriz.

 

Sonuç itibarı ile VM’lerin kullanacağı sanal diskler (VHD) File Server üzerindeki bir paylaşımda duruyor.

 

Yukarıdaki diagramda görüldüğü gibi  \\FServer1\VMDisks\VM1 içerisindeki D1.VHD dosyası, Hyper-V1 üzerindeki VM1 tarafından kullanılmakta.

 

İkinci Node (Hyper-V2) üzerinde ise herhangi bir VM çalışmıyor. Tabi buradan çalışamayacağı gibi bir sonuç çıkmasın. Kafa karıştırmaması açısından eklemedim. İkinci node üzerinde de VM’ler çalışabilir.

 

Yapımızı bu şekilde tasarladıktan sonra Windows Server 2008 Failover Cluster Management konsolu ile gerekli configuration’ı yapıyoruz. Yazımın başında da bahsettiğim gibi configuration konusuna bu makalede girmeyeceğiz.

 

Şimdi tasarladığımız yapı üzerinde bir sorun olduğunu var sayalım. Örneğin Hyper-V1 yani ilk node down oldu!

 

Bu durumda diagram’ı aşağıdaki gibi değiştiriyoruz.

 

image002 

 

 

Görmüş olduğunuz gibi Hyper-V1 üzerindeki VM’de çalışan D1.VHD diski, Hyper-V2 üzerindeki bir VM’de start oldu ve hizmet vermeye devam ediyor. Bir başka tarif ile, Hyper-V1 üzerindeki VM1 sanal makinesi, Hyper-V2 üzerinde VM2 olarak hizmete devam ediyor.

 

Storage ve Fiber ekipmanları açısından oldukça basit ve maliyetsiz bir yapı.

 

Tabi buradaki önemli noktalardan biriside performanstır. Bu yapıda yani network üzerinden çalışan VM’ler, asla FC yada iSCSI Storage üzerindeki VM’ler kadar performanslı çalışmaz. Ama 1gbps (1000mbit) network yapısı ile rahatlıkla kullanılabilir. Henüz çok yaygın olmasa da standart olarak kabul edilmiş ve Ethernet üzerinden 10gbps veri iletimi sunan CAT7 (15mt.) ve uyumlu NIC’ler ile (Intel), bu yapı çok daha performanslı olarak kullanılabilir.

 

 

2. Parent Based Failover Cluster

 

Bu senaryo Hyper-V Parent yani host seviyesinde bir Cluster yapısıdır. Bu senaryoda ortak storage olarak kullanacağımız birim bir SAN’dir (Storage Area Network). Bu SAN Fiber Channel yada İSCSI yapıda olabilir. Önemli olan fiziksel Hyper-V sunucularının aynı storage’a erişiyor olması ve VM (Sanal Makine) ‘lerin bu storage üzerindeki uygun LUN’lar üzerinde duruyor olmasıdır.

 

Aşağıdaki diagram’ı inceleyelim.

 

image003

 

 

Görmüş olduğunuz gibi SAN üzerinde yaratılmış 3 adet LUN bulunuyor. Her iki Hyper-V sunucusu da (Hyper-V1 ve Hyper-V2) bu SAN üzerindeki LUN’lara erişebiliyor ve aralarında Cluster yapılandırılmış şekilde çalışıyor.

 

SAN üzerindeki LUN2 bölümü, Hyper-V1 üzerinde H:\ sürücüsü olarak çalışıyor ve LUN2 içerisindeki D1.VHD (Sanal Disk) dosyası da Hyper-V1 üzerinde çalışan VM1 tarafından kullanılıyor. Yani VM1 sanal makinesi Hyper-V1 üzerinde çalışıyor ama disk dosyası SAN üzerindeki LUN2 de duruyor.

 

SAN üzerindeki LUN1 ise yine Hyper-V1 üzerinde M:\ sürücüsü olarak çalışıyor.

 

Yine tasarladığımız yapı üzerinde bir sorun olduğunu var sayalım ve Hyper-V1 fiziksel sunucumuzun down olduğunu düşünelim. Bu noktada durum aşağıdaki gibi olacaktır.

 

image004

 

 

Görmüş olduğunuz gibi Hyper-V1 üzerinde çalışan LUN1, LUN2 ve VM1 isimli sanal makinemiz, otomatik olarak Hyper-V2 üzerinde erişilebilir duruma geçti. Yani LUN’lar içerisindeki her türlü veriye erişebilirken, VM1 sanal makinemizde hizmet vermeye devam ediyor.

 

Rahat anlaşılması açısından tek bir VM kullandım ama bu yapıda 10’larca VM yer alabilir. Tamamen fiziksel yapının (donanım) yeterliliği ile alakalı bir durum.

 

SAN üzerideki VM’ler (özellikle FC SAN üzerindekiler) oldukça hızlı çalışırlar. Özelliklerine, kapasitesine ve iletişim teknolojilerine göre değişiklik gösterse de SAN yapıları genelde maliyetlidir ama bir okadar da performanslıdır.

 

 

3. Child Based Failover Cluster

 

Bu senaryo ise Hyper-V Child yani child partition seviyesinde bir Cluster senaryosudur. VM’ler üzerindeki diskler için, ama Hyper-V sunucular arasındaki bir cluster senaryosu olarak tanımlayabiliriz. Bu yapıdaki ortak storage ise yine bir SAN dir ve iSCSI yapıdadır.

 

Yine aşağıdaki diagram’ı inceleyelim.

 

image005

 

 

Görmüş olduğunuz gibi iki adet fiziksel sunucumuz yani Node’umuz var (Hyper-V1 ve Hyper-V2) ve her iki node aynı SAN’e erişiyor. Her iki node üzerinde de birer adet VM çalışıyor ve VM’lerin sanal diskleri (system disk) SAN üzerinde değil, direk Hyper-V sunucular üzerindeki local disklerde duruyor.

 

SAN üzerindeki LUN1 ve LUN2 bölümleri, Hyper-V1 üzerindeki VM1 tarafından sürücü olarak kullanılıyor.

 

LUN1 -> E:

LUN2 -> D:

 

Yani biz, SAN üzerindeki bir LUN’ı Hyper-V sunucusu üzerinde bir sürücü olarak kullanabileceğimiz gibi, VM üzerinde de kullanabiliriz.

 

Bu yapıdaki Hyper-V1 fiziksel sunucusu yada VM1 sanal makinesi üzerinde meydana gelebilecek herhangi bir problemde, LUN1 ve LUN2 bölümleri diğer node üzerindeki VM2 de kullanılabilir olacaktır.

 

Aşağıdaki diagram’ı inceleyelim.

 

image006 

 

 

Görmüş olduğunuz gibi VM1 down oluyor ama üzerindeki LUN1 ve LUN2 bölümleri, diğer node’da çalışan VM2 üzerinde hizmete devam ediyor.

 

 

4. Physical/Virtual Failover Cluster

 

Bu senaryoda herhangi bir fiziksel sunucu ile Hyper-V üzerinde çalışan VM arasındaki failover cluster durumu örneklenmiştir. Yani cluster yapısına sadece Hyper-V sunucuları ya da VM’leri almak gibi bir zorunluluk yok.

 

Aşağıdaki diagram’ı inceleyelim.

 

image007

 

 

Görmüş olduğunuz gibi Server1 isimli sunucu Hyper-V çalıştıran ya da üzerinde VM tutan bir sunucu değil. iSCSI yani IP networkü üzerinden veri ileten bir SAN’in LUN’larını, kendi üzerinde disk sürücü olarak kullanıyor ( E: ve D: ).

 

İkinci node olan Hyper-V1 ise, VHD dosyası local diskler üzerinde duran ve VM1 isimli bir sanal makine çalıştırıyor.

 

Bu senaryoda koruma altına aldığımız birimler, Server1 üzerindeki E: ve D: sürücüleri. Bu sürücüler firmanın ortak belgelerinin tutulduğu, önemli paylaşımların yapıldığı yada bir uygulamanın verilerinin yazıldığı diskler olabilir.

 

Bu yapıda Server1 üzerinde meydana gelebilecek herhangi bir problem durumda sistem aşağıdaki gibi kendisini koruyacaktır.

 

Diagram’ı inceleyelim.

 

image008

 

 

Görmüş olduğunuz gibi Server1 üzerinde hizmet veren (ama aslında SAN üzerinde duran) E: ve D: sürücüleri, Server1’in down olması ile birlikte otomatik olarak VM1 üzerinde kullanılabilir oluyor.

 

Bu yapı fiziksel sistem ile sanal sistem arasında oluşturulabilecek failover senaryoları için güzel bir örnektir.

 

 

5. Virtual/Virtual Failover Cluster (Aynı Fiziksel Sunucu Üzerinde)

 

Bu senaryoda farklı fiziksel sunucular yerine aynı fiziksel sunucu üzerindeki farklı VM’leri kullanacağız. Yani aynı Hyper-V sunucusu üzerindeki iki child partition arasında oluşturabileceğimiz bir failover cluster senaryosudur.

 

Aşağıdaki diagram’ı inceleyelim.

 

image009

 

 

Görmüş olduğunuz gibi Hyper-V isimli bir sunucumuz ve tek fiziksel node olarak çalışan bir yapımız var. Bu sunucu üzerinde ise iki adet VM çalışıyor. VM’lerin sanal diskleri (system disk ) Hyper-V sunucusu üzerindeki local disklerde duruyor. Ayrıca Hyper-V sunucusunun kullanabildiği iSCSI yapısında bir SAN’imiz var.

 

VM1 üzerinde F: ve G: olarak çalışan iki sürücü, SAN üzerinde duruyor ve VM1 üzerinde kullanılıyor.

 

Eğer VM1 üzerinde herhangi bir problem yaşanırsa (yazılımsal yada işletim sisteminden kaynaklanan sorunlar gibi.), F: ve G: sürücüleri VM2 üzerinde hizmet vermeye devam eder.

 

Aşağıdaki diagram’ı inceleyelim.

 

image010

 

 

Görmüş olduğunuz gibi F: ve G: sürücüleri VM2 üzerinde kullanılabilir durumdalar.

 

Eğer fiziksel sunucu yani Hyper-V1 down olursa yapacak bir şey yok. Her iki VM ve doğal olarak cluster yapısı çalışmaz. Bu gibi fiziksel durumların önlemlerini yukarıdaki senaryolarda incelemiştik. Bu senaryo aynı fiziksel sunucu üzerindeki VM’ler arasında kullanılan bir senaryodur.

 

 

6. Virtual iSCSI SAN Failover Cluster (Aynı Fiziksel Sunucu Üzerinde)

 

Bu senaryo Technet bloglarında ele alınmış ve production networklerde fazla kullanılmayacak bir senaryodur. Notebook üzerinde yapılan Hyper-V demolarında küçük bir cluster senaryosu göstermek için kullanılabilir.

 

Bu senaryo tek bir fiziksel Hyper-V sunucusu üzerindeki child partitionlar arasında uygulanıyor ve yine altını çiziyorum; amaç demo ortamlarında basit bir senaryo göstermekten öte değil.

 

Yapıyı anlamak için aşağıdaki diagram’ı inceleyelim.

 

image011

 

 

Görmüş olduğunuz gibi tek bir Hyper-V sunucusu üzerinde E: olarak çalışan fiziksel bir disk var. Fiziksel E: sürücüsü içinde D1, D2 ve D3 olmak üzere üç adet sanal disk var. VM1, VM2, VM3 olmak üzere bu üç sanal diski kullanan üç adet VM var.

 

VM1 üzerinde sanal bir iSCSI SAN oluşturulur. Sanal iSCSI SAN için Microsoft iSCSI Software Target kullanılabilir. VM2 üzerindeki F: ve G: sürücüleri, VM1 üzerinde olşuturduğumuz sanal iSCSI SAN üzerinde durur.

 

Eğer VM2 üzerinde herhangi bir problem olursa (Yazılımsal yada işletim sistemi kaynaklı) F: ve G: sürücüleri VM3 üzerinde kullanılabilir duruma geçer.

 

Aşağıdaki diagram’ı inceleyelim.

 

image012

 

 

Görmüş olduğunuz gibi F: ve G: VM3 üzerinde çalışır durumda.

 

Bu senaryoda VM1 down olursa, cluster yapısı işe yaramaz. Aynı şekilde Hyper-V1 yani fiziksel sunucu üzerinde bir problem yaşanırsa yine cluster senaryosu işe yaramaz.

 

Başta da söylediğim gibi bu senaryoda amaç performans yada kullanımdan öte demo ortamlarında küçük bir gösteri yapmaktan ibarettir.

 

Şimdilik inceleyeceğimiz failover cluster senaryoları bu kadar. Görmüş olduğunuz gibi cluster konusunda bir çok seçenek var. İlerleyen günlerde bu senaryoların kurulum ve uygulama yöntemlerine değineceğiz.

 

Hepinize iyi çalışmalar.

 

Serhat AKINCI – IT Professional