Etiket arşivi: Hyper-v

Hyper V

View more presentations from hakan uzuner.

Hyper-V Failover Cluster Kurulumu (Bölüm-7)

Önceki bölümler doğrultusunda failover cluster yapımızı hazırladığımıza göre, artık cluster yeteneklerini test edebiliriz.

10. Hyper-V Failover Cluster Sonrası Gelen Yetenekler

10.1. Quick Migration – QM (Hızlı Taşıma)

10.1.1. Quick Migration Nedir?

Quick Migration yani hostlar arası Hızlı Taşıma özelliği cluster temelli bir özelliktir. Kullanım amacı ise bir fiziksel node üzerinde çalışan sanal makineyi, hızlı bir şekilde diğer fiziksel node üzerine taşımaktır. Yani QM, sanal makine seviyesinde hızlı taşıma sağlıyor.

Konuyu küçük bir senaryo ile örneklendirelim.

Yukarıda bir failover cluster yapısı kurduk ve üzerinde Cluster-XP isimli bir VM var. Bu VM şu an HV-Node1 fiziksel sunucusu üzerinde çalışıyor. Herhangi bir nedenden dolayı HV-Node1’in kapatılması gerekiyor (Örneğin sunucuya fiziksel olarak ram ilavesi yapacağız). Bu durumda Quick Migration özelliğini kullanarak birkaç küçük tıklama ile HV-Node1 üzerinde çalışan Cluster-XP isimli VM’i, tüm içeriği ile birlikte cluster’ın diğer üyesi olan HV-Node2 üzerine taşımamız mümkün. İşimiz bittikten sonra HV-Node2 üzerinde çalışan VM’i tekrar Quick Migration ile eski konumuna geri alabiliriz.

Bu özellik Live Migration yani Canlı Taşıma özelliği ile karıştırılmamalı ki bu sık yapılan hatalardan birisi.

Quick Migration ile taşıma sırasında VM network üzerinde hizmet veremez ve taşıma sonrasında hizmet verdiği session’lar kapanmış, connection’lar kesilmiş durumdadır. QM’in en önemli karakteristiği budur, taşıma esnasında VM’e erişim kesilir!

Quick Migration aşağıdaki ürünler ile kullanılabilir (cluster üyesi node’lar bu işletim sistemlerinden biri olmalı):

· Windows Server 2008 (Enterprise, Datacenter)

· Hyper-V Server 2008

· Windows Server 2008 R2 (Enterprise, Datacenter)

· Hyper-V Server 2008 R2

Live Migration ise tamamen canlı bir taşıma teknolojisidir. Taşıma sırasında VM network üzerinde hizmet verebilir durumdadır ve taşıma süresince üzerindeki servis ve uygulamalara erişim kesilmez. Taşıma tamamlandıktan sonra session’lar ve tüm connection’lar hala bağlı ve açık durumdadır. LM’in en önemli karakteristiği ise taşıma esnasında VM’e ve üzerindeki servislere erişilebiliyor olmasıdır.

Live Migration R2 ile gelen bir özelliktir ve aşağıdaki ürünler ile kullanılabilir (cluster üyesi node’lar bu işletim sistemlerinden biri olmalı):

· Windows Server 2008 R2 (Enterprise, Datacenter)

· Hyper-V Server 2008 R2

Quick Migration ile taşıma sırasında VM’e erişim durduğu için taşıma işleminin süresi önem kazanıyor çünkü süre ne kadar uzarsa, VM o kadar hizmet dışı kalacaktır. Peki bu süre ne kadardır ve süreye etki eden faktörler nelerdir?

Aslında bu konuyu fazla detaylandırmak istemiyorum çünkü önümüzdeki makalelerde ayrıntılı olarak ele alacağız. Ama ön bilgi olması açısından şunları söyleyelim.

VM’in memory miktarı başta olmak üzere, node’lar ile storage arasındaki bağlantı tipi ve storage üzerindeki disklerin tipi/hızı Quick Migration işleminin süresine direkt olarak etki eden temel faktörlerdir.

Bunun nedenini anlamak için Quick Migration işleminin background’una bakmak gerekir.

Quick Migration esnasında gerçekleşen işlemler sırası kabaca şöyle.

1. VM saved state duruma alınır.

2. VM durumu (VSV ve BIN bilgisi) diğer node üzerine taşınır.

3. VM diğer node üzerinde start edilir. VSV ve BIN dosyaları sayesinde kaldığı yerden çalışmaya devam eder.

Bir VM için QM (Quick Migration) komutunu verdikten sonra, VM bulunduğu host üzerinde saved state dediğimiz bir duruma alınır (VM’in o anki durumu ile dondurulduğunu düşünün). VM’in o anki durumunu (başta sanal memory içeriğini ve process bilgilerini) tutan dosyalar ise VSV ve BIN dosyalarıdır. QM işleminin süresine etki eden temel faktör bu dosyaların boyutlarıdır. Bu dosyaların boyutları ise VM’e atadığımız sanal memory miktarı ile doğru orantılıdır.

Örneğin 256MB memory’e sahip bir VM için yaklaşık 256mb boyutunda bir BIN dosyası vardır ve bunun QM sırasında save edilmesi, bilgisinin diğer node üzerine taşınması gerekir.

Ama 2GB memory’e sahip bir VM için 2048mb boyutunda bir BIN dosyası vardır ve haliyle taşıma işlemi daha uzun sürecektir.

Bunun dışında storage ve node’lar arasındaki bağlantı teknolojisi de bu taşıma işleminin hızına direkt olarak etki edecektir.

Dediğim gibi ayrıntılar daha sonra 🙂

Bizim kurmuş olduğumuz iSCSI cluster yapısında 1GB ram’e sahip makineyi 10sn gibi bir sürede QM ile diğer node’a taşıyabiliyoruz.

Aşağıdaki tablo ise storage bağlantı teknolojileri ve VM üzerindeki ram miktarına göre bazı ortalama rakamları yansıtmaktadır. iSCSI tarafındaki rakamlara takılmayın, süreler çok daha aşağılara çekilebiliyor.

VM Memory

1 GbE iSCSI

2 Gb FC

4 Gb FC

512 MB

~8 seconds

~4 seconds

~2 seconds

1 GB

~16 seconds

~8 seconds

~4 seconds

2 GB

~32 seconds

~16 seconds

~8 seconds

4 GB

~64 seconds

~32 seconds

~16 seconds

8 GB

~2 minutes

~64 seconds

~32 seconds

Quick Migration işlemi biz yöneticiler tarafından başlatılır ve geçiş süresince VM’in erişilemez durumda olacağı bilinir. Bu nedenle QM’i planlı kesintiler sınıfına sokabiliriz.

Şimdi kurmuş olduğumuz failover cluster yapısında QM (Quick Migration)’i nasıl yapıyoruz bir bakalım. Hem de yapıyı test etmiş olalım.

10.1.2. Quick Migration Nasıl Yapılır?

HV-Node1 üzerinde Failover Cluster Management konsolunu açıyoruz.

QM işlemini Failover Cluster konsolu üzerinden yapabileceğimiz gibi SC Virtual Machine Manager 2008 ile de yapabiliriz.

Services and Applications altındaki Virtual Machine servisine sağ tıklıyoruz ve Move virtual machine(s) to another node altındaki Move virtual machine(s) to node ‘HV-Node2’ seçiyoruz.

Bu komut ile Virtual Machine servisi içerisinde eklemiş olduğumuz ve şu an HV-Node1 tarafından sahiplenilmiş olan VM’i/VM’leri, HV-Node2 üzerine QM yapıyoruz (biz bir adet eklemiştik: Cluster-XP).

Komutu verdikten sonra işlem hemen başlıyor. Aşağıda da gördüğüz gibi öncelikle VM save ediliyor yani saved state durumuna geçiyor.

Bu esnada ilgili VM’in sahibi (Current Owner) HV-Node1. VM HV-Node1 üzerinde çalışıyor. Bunu da aşağıda görebiliyoruz.

Saving işlemi saniyeler içinde tamamlandıktan sonra ilgili VM artık diğer node’a (bizim yapımızda HV-Node2) devrediliyor ve owner’lık değişiyor.

VM HV-Node2 üzerinde start olmaya başladı. Artık Current Owner HV-Node2.

Kısa bir süre içerisinde işlem tamamlanıyor ve Cluster-XP isimli makine diğer HV-Node2 üzerinde çalışmaya devam ediyor.

Bu noktada HV-Node1 yani Cluster-XP’nin eski sahibi olan node üzerinde Hyper-V Manager konsolunu açarsanız, Cluster-XP’nin yer almadığını görebilirsiniz. Çünkü artık diğer node üzerinde.

HV-Node2 üzerinde ise Hyper-V Manager konsolunu açtığınızda Cluster-XP’nin yer aldığını görebilirsiniz.

Hatırlarsanız Cluster-XP VM’i HV-Node1 üzerinde çalışırken, clustered diskler de HV-Node1 üzerinde direkt olarak erişilebilir durumdaydı.

Şu an ise clustered diskler den birisi (VM’in yer aldığı disk) otomatik olarak HV-Node2 üzerinde erişilebilir duruma geçti.

Diğer clustered disk yani quorum bilgisinin tutan disk ise hala HV-Node1 üzerinde çalışıyor çünkü HV-Node1 up durumda. QM işleminde quorum diskin yeri değişmez.

Disk sahiplik durumlarını Failover Cluster Management konsolunda Storage bölümünde daha net görebilirsiniz.

Quick Migration başlatmadan hemen önce network üzerinden Cluster-XP sanal makinesine ping atmaya başlamıştım.

QM bitene kadar olan ping istatistiği aşağıdaki gibidir.

Görüldüğü gibi 5 ping paketi kaybı sonrasında VM tekrar network üzerinde erişilebilir hale gelmiş.

Şimdi VM’i tekrar eski yerine taşıyalım. Yani HV-Node2 üzerinden yine HV-Node1 üzerine alalım.

Yine Failover Cluster Management konsolu üzerinde Services and Applications altındaki Virtual Machine servisine sağ tıklıyoruz ve Move virtual machine(s) to another node altındaki Move virtual machine(s) to node ‘HV-Node1’ seçiyoruz.

Eğer cluster yapımızda başka node’lar olsaydı onları da burada görüyor olacaktık.

Bu komut sonrası yine VM hızlıca save ediliyor.

Ve HV-Node1 üzerinde tekrar start ediliyor.

Taşıma işlemi bittiğinde current owner olarak HV-Node1 görünüyor ve VM online/running durumda.

Quick Migration işlemi bu kadar. Gördüğünüz gibi birkaç küçük tıklama ile VM’leri cluster üyesi sunucular arasında rahatlıkla dolaştırabiliyoruz 🙂

10.2. VM Failover (Sanal Makine Hata Telafisi)

10.2.1. VM Failover Nedir?

Cluster yapısına eklenmiş Host ve VM’ler için failover yeteneği temelde bir HA (High Availability) özelliğidir.

Cluster üyesi Node’lardan birinin başına bir şey geldiğinde (donanımsal bir başarısızlık nedeni ile sunucunun down olması gibi), down olan node üzerindeki servis ve uygulamanın (bizim yapımızda Virtual Machine servisi) up durumda olan diğer node üzerinde hizmet vermeye devam etmesi durumudur.

Yine küçük bir senaryo ile örneklendirelim.

Yapımızdaki Cluster-XP makinesi şu an HV-Node1 üzerinde çalışıyor. Diğer cluster üyesi node ise HV-Node2 ve şu an pasive node konumunda bekliyor.

Gün içerisinde HV-Node1 üzerinde bir donanım arızası oluşuyor ve sunucu bir anda down oluyor. Kısa bir süre içerisinde telefonlar yağmaya başlıyor çünkü HV-Node1 üzerinde hizmet veren VM ve servislere erişilemiyor ve bu hizmetleri kullanan kullanıcılarımız hemen telefona sarılıyor 🙂

Hatırlarsanız makalenin ilk bölümlerinde heartbeat isimli bir network ten bahsetmiştik. Bu network için farklı bir ip config yaparak public networkten ayırmış ve cluster üyesi sunucuların bu network üzerinden birbirlerini yokladıklarını, up durumda olup olmadıklarını kontrol ettiklerini söylemiştik. İşte bu network üzerinden yapılan kontroller sırasında down olmuş bir node tespit edilirse, otomatik olarak gerekli aksiyon alınabiliyor.

Senaryomuza dönersek, HV-Node1 down olduğu zaman HV-Node2 bunu kısa süre içerisinde fark edebiliyor çünkü sunucular heartbeat network üzerinden sürekli birbirlerini kontrol ediyor. Daha sonra HV-Node2 gerekli cluster kaynaklarını ve HV-Node1 üzerinde çalışan servisleri otomatik olarak kendi üzerine alıyor yani VM’ler otomatik olarak HV-Node2 üzerinde failover oluyor (hata telafisi).

Bu noktada geçen süre, node’un down olduğuna karar verilmesi ve ilgili kaynakların diğer node üzerine taşınması gibi işlemler ile birlikte ortalama 1-2 dakikadır (değişkenlik gösterir). Node’lar arası kontrol süresini çok kısa tutmak sağlıklı değildir çünkü heartbeat network üzerinde meydana gelebilecek anlık ve ya kısa süreli geçici problemlerde node’lar birbirine ulaşamaz ise ortalık bir anda karışabilir 🙂

Bir sunucunun down olması durumu biz yöneticilerin isteği dışında gerçekleşen bir olay olduğu için plansız kesintiler sınıfına sokuyoruz.

Şimdi failover aksiyonunu test edelim.

10.2.1. VM Failover Nasıl Yapılır?

Yapılması gereken ekstra bir ayar yok. Daha önceden kurmuş olduğumuz failover cluster yapısı dahilinde bu özellik otomatik olarak etkin durumdadır. Cluster yapısına Services and Applications olarak Virtual Machine servisinin eklenmesi ve ilgili VM’lerin seçilmesi yeterli (biz bunu zaten yapmıştık).

HV-Node1 üzerinde Failover Cluster Management konsolunu açtığımızda Virtual Machine servisinin sahibinin HV-Node1 olduğunu görebiliyoruz ve servis şu an online durumda.

Nodes altında HV-Node1’e baktığımızda her iki clustered disk’in ve virtual machine servisinin HV-Node1 üzerinde olduğunu açıkça görebiliyoruz. Yani aktive node durumunda.

Ayrıca node up durumda.

Şu an HV-Node2 ye baktığımızda ise üzerinde hiçbir cluster kaynağının olmadığını görüyoruz. Yani pasive node durumunda.

Ayrıca o da up durumda.

Şimdi herhangi bir nedenden dolayı HV-Node1’in down olduğunu düşünelim. Ben test için HV-Node1’in fişini çekiyorum 🙂

Cluster ortamı hemen HV-Node1 de bir problem olduğunu anlıyor. Aşağıdaki görüntüde HV-Node-1 üzerindeki küçük kırmızı uyarıyı görebilirsiniz.

Ayrıca şu an Virtual Machine servisinin sahibi hala HV-Node1.

Saniyeler içerisinde servis pending duruma geçiyor ve HV-Node2’ye aktarılıyor.

İşlem tamamlandığında servisin yeni sahibi HV-Node2 ve Cluster-XP online olmuş durumda.

HV-Node1 şu an kapalı durumda bekliyor ve üzerinde hiçbir cluster kaynağı olmadığını görebiliyorsunuz.

HV-Node2 ise tüm cluster kaynaklarını kendi üzerine almış durumda ve sistem çalışmaya devam ediyor.

Storage bölümünden baktığımızda ise iki diskin de HV-Node2 tarafından sahiplenildiğini görüyoruz.

QM işlemini hatırlayın, sadece VM’in olduğu diskin sahipliği değişiyordu çünkü planlı bir kesintiydi ve diğer Node up durumdaydı.

Failover da ise HV-Node1 down olduğu için quorum diski de diğer node üzerine taşınmış durumda.

Şimdi down durumda olan HV-Node1’i tekrar açıyorum.

Cluster yapısı hemen HV-Node1’in up olduğunu anlıyor ve bu durumu Failover Cluster Management konsolu üzerinde görebiliyoruz.

Şu an VM’i QM ile eski yerine yani HV-Node1 üzerine alabiliriz yada bu şekilde bırakabiliriz.

HV-Node1 üzerine almak için Move virtual machine(s) to node ‘HV-Node1’ dememiz yeterli.

Saving …

Ve Starting…

Sonrasında Virtual Machine servisinin sahibi tekrar HV-Node1 olur.

Quorum disk ise hala HV-Node2 üzerindedir çünkü QM ile quorum yada diğer clustered disklerin taşınmadığını söylemiştik.

Quick Migration ve Failover(HA) özelliklerini test ettikten sonra iSCSI Storage ile Hyper-V Failover Cluster makalemizin sonuna gelmiş olduk.

Bu makalede öğrendikleriniz ile fiber channel storage kullanarak ta aynı yapıyı kurmanız mümkün. Belki bazı konfigürasyon adımlarında değişiklikler olabilir ancak olayın mantığı tamamen aynı.

Bu yapı üzerinde Hyper-V R2 ile gelen Live Migration özelliğini de kullanabilirsiniz. Ekstra bir şeye gerek yok. QM yaparmış gibi LM yapabilirsiniz. Sadece Host sistemlerin Windows Server 2008 R2 yada Hyper-V Server 2008 R2 olması gerekiyor.

Herkese iyi çalışmalar.

Serhat AKINCI – IT Pro.

Hyper-V Failover Cluster Kurulumu (Bölüm-6)

Önceki bölümde failover cluster kurulumunu gerçekleştirmiştik. Bu bölümde ise cluster yapımıza sanal makineleri yani Virtual Machine servisini ekliyoruz.

9. Hyper-V Sanal Makinelerini Cluster Yapısına Dahil Etmek

Failover Cluster kurulumunu tamamlamış ve nodeları cluster yapısı içerisinde görüyor olmamız, sanal makinelerin cluster ortamında çalışmaya başlaması için yeterli değil.

Cluster kurulumu sonrasında ilgili servisin yada uygulamanın cluster yapısına ayrıca eklenmesi gerekiyor. Failover Cluster yönetim konsolunu açarsanız henüz herhangi bir uygulama/servis olmadığını görebilirsiniz.

Yani cluster kurulumu yapmak, sanal makinelerin High Available olması için yeterli değil. Ayrıca henüz Nodelar üzerine Hyper-V kurulumu da yapmadık.

9.1. Nodelar Üzerine Hyper-V Kurulumu

Biz Hyper-V üzerinde çalışan sanal makineleri failover cluster yapısına almak istediğimiz için, servis ve uygulama olarak Virtual Machine ekleyeceğiz. Ama bunun öncesinde fiziksel Node’lar üzerine Hyper-V rolünü eklemeliyiz yani Hyper-V kurulumunu yapmalıyız. Hatırlarsanız Hyper-V kurulumunu cluster öncesinde veya cluster sonrası yapabileceğimizi söylemiştik.

Server Manager konsolunda, Roles bölümünde, Hyper-V rolünü seçerek ileri dedikten sonra wizard yardımı ile birkaç ayar yaparak Hyper-V rolünü eklemeniz mümkün.

Hyper-V kurulumu ile ilgili fazla detaya girmiyorum. Bu konunun ayrıntıları için daha önceki makalelerime bakabilirsiniz.

Her iki fiziksel node üzerine (HV-Node1 ve HV-Node2) Hyper-V kurulumunu doğru olarak yaptıktan ve çalıştığından emin olduktan sonra devam edebiliriz.

9.2. Test için Sanal Makine (VM) Yaratılması

Test amaçlı yeni bir VM (sanal makine) yaratalım ve nodeların bu VM’i çalıştırıp çalıştıramadığını kontrol edelim.

Failover Cluster yapısına almak istediğimiz VM’lerin storage üzerindeki ortak birimlerde duruyor olması ve cluster nodelarının bu birime/birimlere erişebiliyor olması gerektiğinden daha önce bahsetmiştik.

Hatırlarsanız storage üzerinde iki Virtual Disk yaratıp bunları node’lar üzerine atamıştık. Birini cluster bilgisini tutan Quorum için kullandık (2GB olan). Diğer disk ise hala boşta (30GB olan). Boşta olan diski VM için kullanacağız.

Öncelikle HV-Node1 üzerinde Disk Management’ı açıyoruz ve bu disk üzerinde NTFS formatlı bir partition oluşturuyoruz.

Wizard yardımı ile partition oluşturma işlemini tamamlayalım.

HV-Node1 üzerinde Computer penceresinde oluşan volume’u görebiliriz. Ben ismini VMs olarak değiştirdim.

Dikkat ederseniz Type olarak Clustered Disk görünüyor.

Hemen üstünde ise daha önce biçimlendirdiğimiz ve quorum bilgisinin tutan Quorum bölümünü de görebiliyoruz.

Peki şu an HV-Node2 üzerinde durum ne?

HV-Node2 üzerinde Server Manager> Disk Management bölümüne gelirseniz, HV-Node1 üzerinde biçimlendirdiğimiz disklerin HV-Node2 üzerinde Reserved durumda olduğunu görebilirsiniz.

Yine HV-Node1’e dönelim ve Cluster Management konsolundaki duruma bakalım.

Gördüğünüz gibi iki diskte storage bölümünde listeleniyor. Disklerin şu anki sahibi ise HV-Node1.

Şimdi HV-Node1 üzerinde yeni bir VM yaratalım ve bu VM storage üzerinden atadığımız diskte bulunan VMs (H:\) partition’ı içerisinde dursun.

Sıradan bir VM yaratmaktan farkı yok. Sadece VM’in duracağı yer olarak storage üzerinden gelen clustered disk’i göstermemiz gerekiyor.

VM yaratmak ile ilgili ayrıntıya girmiyorum. Eğer nasıl yaratılacağını bilmiyorsanız, bu konu için daha önce yazmış olduğum makalelere göz atabilirsiniz.

VM’i yarattıktan ve içerisine Guest OS kurduktan sonra aşağıdaki gibi görünüyor olmalı.

Yukarıda gördüğünüz gibi Cluster-XP isimli sanal makine, HV-Node1 üzerinde çalışıyor. Ama sanal makinenin vhd formatlı sanal diski ve diğer ilgili dosyaları H:\ yani clustered disk üzerinde duruyor.

Şimdi Failover Cluster yapımıza Services and Apllications olarak Virtual Machine ekleyeceğiz ve yarattığımız VM’i High Available yapacağız.

9.3. Failover Cluster Yapısına Virtual Machine Servisini Eklemek

HV-Node1 üzerinden Failover Cluster Management konsolunda Services and Apllications üzerinde sağ tıklıyoruz ve Configure a Service or Application diyoruz.

High Availability Wizard açılıyor.

Next diyoruz.

Select Service or Application penceresinde gördüğünüz gibi çok sayıda servis ve uygulama var.

Biz Virtual Machine seçerek devam ediyoruz. Bu noktada listedeki farklı uygulamalar için de cluster yapıları oluşturmanız mümkün.

Next dedikten sonra gelen Select Virtual Machine penceresinde ise cluster yapısına dahil edeceğimiz VM’i/VM’leri seçiyoruz. Yani Node’lar üzerindeki tüm VM’ler hemen cluster yapısına dahil olmuyor. Hangi VM’in cluster içerisinde çalışacağına bu ekranda seçim yaparak biz karar veriyoruz. Tabii ki tümünü seçme şansımız da var.

Dikkatinizi çekmek istediğim bir diğer nokta ise bu pencerede cluster node’ları üzerindeki tüm VM’lerin listeleniyor olması (aşağıda da görünüyor). Yani HV-Node1 ve HV-Node2 üzerindeki tüm VM’ler bu listede yer alıyor ve hepsini seçebiliyoruz. Ama seçtiğimiz VM’in clustered disk üzerinde olması gerektiğini unutmayın. Yani burada listeleniyor olması, cluster yapısına dahil edebileceğimiz anlamına gelmiyor. Clustered disk şart.

Bizim clustered disk üzerinde duran VM’in ismi Cluster-XP. Bu nedenle onu seçerek devam ediyorum.

Ama Cluster-XP seçtiğimde bir hata alıyorum.

Bunun anlamı şu: bu konfigürasyonu, cluster yapısına dahil edeceğimiz VM çalışır durumdayken yapamıyoruz. VM’in off durumda olması gerekiyor.

VM’i Hyper-V Manager konsolundan ya da ilgili ara yüz üzerinden off yaptıktan sonra tekrar High Availability Wizard’ı açıyoruz ve aynı yere kadar ilerliyoruz.

Cluster-XP’i seçerek Next diyoruz.

Next ile konfigürasyonu başlatıyoruz.

İşlem sürüyor.

Summary penceresinde Success mesajını gördükten sonra yapılandırma başarılı bir şekilde tamamlanmış oluyor.

Finish diyerek bitiriyoruz.

Artık Failover Cluster Management konsoluna döndüğümüz zaman Services and Applications altında Virtual Machine servisini görebiliriz ve şu an offline durumda.

Bu servis için Current Owner olarak ise HV-Node1 görünüyor.

Hemen start edelim.

Bu komut ile Virtual Machine servisi içerisinde ekli olan tüm VM’leri start etmiş oluruz.

Biz tek bir VM eklediğimiz için şu an tek bir VM start oldu.

Böylece Virtual Machine servisi ve eklediğimiz bir adet VM için failover cluster yapılandırmasını tamamlanmış olduk.

Şu an Cluster olarak çalışan Virtual Machine servisi içerisindeki 1 adet VM’in ve Clustered disklerin Current Owner’ı HV-Node1 makinesi. Bu nedenle HV-Node1’i aktive node olarak adlandırıyoruz.

HV-Node1 üzerinde Computer penceresine geldiğinizde ise iki diski erişilebilir şekilde görebilirsiniz.

HV-Node2 ise şu an için herhangi bir cluster kaynağının sahibi değil yani pasive node konumunda.

Ayrıca clustered diskler şu an HV-Node2 üzerinde partition anlamında erişilebilir durumda değil.

Şimdi cluster’ın doğru olarak çalışıp çalışmadığını görmek için bir takım testler yapacağız.

Bu testleri Bölüm-7 de gerçekleştiriyoruz.

Serhat AKINCI – IT Pro.

Microsoft System Center Urun Ailesi

Microsoft işletmelerin sistem yönetimi ihtiyaçlarını karşılamak için geçmişten günümüze bir çok ürün piyasaya sürmüştür.Tabi ki çıkartılan her ürünün de getirmiş olduğu yenilikler mevcuttur.Ancak gelişen ve büyüyen IT alt yapılarını yönetmek giderek daha zor ve karışık bir hal almaktadır.En basit olarak her network senaryosunda mutlaka kullanılması gereken belli başlı sunucu rolleri mevcuttur.Şirket büyüdükçe, ihtiyaçlar arttıkça da yeni server rolleri bu yapının içerisine dahil olmaktadır.Bundan dolayı IT yöneticileri,kaynakları daha kullanışlı bir hale getirmek için yeni entegre çözümlere ihtiyaç duymaktadır.Microsoft’un bu konuda sunmuş olduğu entegre çözüm System Center ürün ailesidir.Genel başlık olarak aşağıdaki işlevlere sahiptir.

Microsoft System Center ürün ailesi,yukarıda bahsetmiş olduğum işletmelerin karışık ve zor yönetimlerini basitleştirmek ve her yerden yapılabilmesini sağlıyabilmek için hayatımza katılmış olan entegre çözümler serisidir.İşletmelerin kullanmış olduğu her türlü server,client,mobil cihazlarının güvenlik,yönetim ve konfigürasyon gibi fonksiyonlarının tek bir merkezden yönetilebilmesini sağlamaktadır.Yine System Center ürün ailesi ile,kendi alt yapınız ve kullandığınız her türlü sistem hakkında bilgi toplayarak maximum verimliliği yakalıyabilmek,masrafları azaltabilmek,uygulama kullanılabilirliliğini geliştirmek için raporlar oluşturabilmekteyiz.Oluşturulan bu detaylı raporlar sayesinde sistem yöneticileri,işlemlerin öncelik sırasına koyulmasında,problemlerin kısa yoldan en basit şekilde çözümlenebilmesinde,özellikle problemin kaynağının belirlenmesinde kendilerinin belirlemiş olduğu standartları kullanmaktadırlar.Bu sayede,IT süreçlerinin etkin bir şekilde yerine getirilip getirilmediği ile bütün performansı merkezi raporlama sayesinde takip edebilmektedir.Yaşanan bir sıkıntıda anında müdahale yapılarak son derece etkin bir sistem yönetimi yapılabilmektedir.

System Center ailesi ile her ölçekteki kuruma destek verilmektedir.Siz sadece hangi ürün’e ihtiyacınız olduğunu belirleyin yeter.Yani KOBİ’lerde dahil olmak üzere ister 5 server,ister 500 server’lık bir IT altyapısına destek verebilir,iyileştirebilir ve her türlü konfigürasyonu yönetimini daha kolay yapabiliriz.System Center çözümleri,Third party çözümler ile de uyumlu bir şekilde çalışarak daha önceden yapmış olduğunuz yatırımlardan maksimum seviyede faydalanmanızı sağlamaktadır.Yani daha önceden yapılan bu tür bir hedefle yapılan herhangi bir yatırım atıl kalmıyacaktır.Microsoft ürünleri için en iyi çözüm olan System Center ile hedeflediğiniz alt yapı optimizasyonunda şu anda neredeyim ve nerede olmak istiyorum gibi soruların cevaplarını daha kolay bulabilirsiniz.Yine bu ürün ailesi ile,işiniz sürekli çalışır durumda olduğundan emin olabilir,gereksiz karmaşıklığa engel olabilir,her türlü değişikliğede hazır olabilirsiniz.

System Center ailesinin sunmuş olduğu tüm bu çözümler sayesinde kendi kendini yöneten dinamik bir IT alt yapısına sahip oluyoruz.Aynı zamanda neredeyse Bilgi İşlem tarihinde ilk olan,şirket altyapısının tek bir merkezden yönetilebilmesi,yapılandırılabilmesi, denetlenmesi,izlenmesi ve korunması sağlanmaktadır.Bilgi odaklı IT yönetimi her sistem yöneticisinin şüphesiz ki işlemlerini daha da kolaylaştıracaktır.Şimdi gelin System Center ürün ailesi ile gelen çözümlere bakalım.

Microsoft System Center Ürün Ailesi

System Center çözümleri ile IT yöneticileri,sistem üzerine gerçekleşen her türlü karmaşık görevi kolay ve hızlı bir şekilde yerine getirebilirler.Aynı zamanda bütün Windows sistemleriniz ile entegre bir şekilde çalışabilmektedir.Sharepoint’den Vista’ya kadar.IT kaynaklarımızı tutarlı bir şekilde tanımlamamıza,yaygınlaştırmamıza,izlememize ve yönetmemize olanak sağlayan System Center ailesi ürünleri aşağıdaki gibidir.

Mobil,Sanallaştırma,Destek,Değişim ve Operayon olarak 4 ana başlıl altında sayabileceğimiz 8 adet ürün ile her türlü IT yönetim çözümlerine sahip olmaktayız.Şimdi teker teker bu ürünleri inceleyelim.

System Center Operation Manager(SCOM)

Microsoft Operations Manager(MOM) ürününün en son hali olarak karşımıza gelmektedir.IT ortamlarında oluşan sorunları önlemek ve verimliliği artırmak için kullanılabilecek olan bir üründür.Amaç IT servislerini izlemek.Yaşanacak herhangi bir problemi önceden tespit edip,diğer servisleri kesintiye uğratmadan giderebilmektir.Üzerinde 50’den fazla yönetim paketi bulunmaktadır.SCOM rol tabanlı olarak kullanılabildiği gibi,her rolün tek bir makinadaymış gibi düşünülmesi de sağlanabilmektedir.Bu şekilde uçdan uca bir yönetim sağlamaktadır.Seçilen bilgisayarların logları merkezi bir yerde saklanır ve raporlar oluışturulur.Bu sayede daha hızlı hata tespit ve izolasyonu yapılabilmektedir.Microsoft dışındaki Third Party çözümler ile de entegre bir şekilde çalışabilmektedir.Enterprise yapılar için’de kullanabiliri.Yani 1000’lerce sunucuyu yönetebiliriz.

System Center Configuration Manager(SCCM)

Eski ismiyle System Management Server(SMS) olan SCCM ile,IT organizasyonu içerisinde rutin işleyen her türlü görevi otomatik olarak gerçekleştirebiliriz.Kolay ve hızlı bir şekilde Windows server ve client işletim sistemlerinin kurulumunu gerçekleştirebiliriz.Güvenlik açıklarının giderilmesi için update ihtiyaçlarını belirliyebilmekteyiz.Eğer bir yükseltme yapılacaksa sistemlerin uyumluluğunu kolay bir şekilde test edebiliriz.SCCM,şirket içerisindeki bilgisayarlarımızın envanter bilgilerini hazırlamak için bize kaynak olmaktadır.Uzak ofis senaryolarının güvenli bir şekilde yönetilebilmesi için de tercih edebiliriz.SCCM,bütün bunların soncu olarak tabi ki yönetim maliyetlerini düşürmeye yardımcı olmaktadır.

System Center Data Protection Manager(SCDPM)

Windows tabanlı çalışan işletim sistemlerindeki datalarımızın güvenliğini sağlamak ve herhangi bir problem senaryosunda geri dönüşünü hızlı bir şekilde yapabilmek için Data Protection Manager’ı(DPM) kullanabiliriz.DPM ile hem Tape tabanlı hem de Disk tabanlı olarak yedekleme ve recover işlemlerini yapabilmekteyiz.Özellike Active Directory domainlerinde hayati öneme sahip olan Exchange Server,File Server,Sharepoint Server,SQL Server gibi server rollerinin yedekleme işlemlerini yapabiliriz.Yine Windows Server 2008 gibi işletim sistemlerinin üzerine yüklü olan server rollerinin System State olarak yedeklerini alabilir ve dakikalar içerisinde bu yedekleri restore yapabiliriz.Bu şekilde Mevcut IT altyapısını duraksatmadan yapının devamlılığını sağlıyabiliriz.

System Center Virtual Machine Manager(SCVMM)

Sanallaştırma günümüzde ve gelecekte sıkça adından söz ettirecektir.Özellikle maliyetleri düşürmeye yardımcı olması ve her türlü platformu desteklemesi ise artılarındandır.Bunun yanında hem server hem de client konsolidasyonu yapılabilmektedir.Birden fazla server rolünü tek bir fiziksel makinada çalıştırarak donanım maliyetlerini düşürmektedir.Tabi ki maliyet tasarrufu böyle bir durumda sadece donanımda değil lisanslamada da karşımıza bir artık olarak çıkmaktadır.Hyper-V.Örneğin,64 BIT kullanmış olduğunuz bir Windows Server 2008 üzerinde herhangi bir lisans ödemeden bedava olan Hyper-V çözümünü kuruyorsunuz ve yine herhangi bir lisans almadan üzerinden 4 tane(Host işletim sistemi ile birlikte toplamda 5 adet)Windows Server 2008 çalıştırabilirsiniz.Bu tip yararların dışında,her türlü platform üzerinde istediğimiz testleri gerçek yapılar üzerinde denemeden önce sanal makinalarımız üzerinden deneyebiliriz.SCVMM ise,şirket ortamlarımızda fiziksel makinalarımız üzerinde çalıştırdığımız sanal server rollerimizi tek bir merkezden yönetebilmek için sunulmuş olan bir çözümdür.SCVMM ile Görsel,Uygulama,Masaüstü ve Sunucu sanallaştırmalarının tamamını yani her türlü sanallaştırma çözümünü yönetebilmekteyiz.SCVMM üzerinde sanal makinalarımızı tanımlayıp hangi fiziksel makinada hangi sanal sistem çalışıyor gibi soruların cevaplarını daha kolay bulabiliriz.Bu şekilde istediğimiz sanal makinayı vereceğimiz utilization kararına göre istediğimiz fiziksel makinada çalışmasını sağlıyabiliriz.SCVMM üzerine SCOM eklentisini kurarak daha detaylı raporlama yapabilme imkanımız mevcut.Yine bu eklenti sayesinde makinalarımızın sağlık durumunu izliyebiliriz.SCVMM üzerinde sanal makinalarımızı oluştururken yapmış olduğumuz ayarları profil olarak kaydedip bundan sonra oluşturacağımız bütün makinalara aynı ayarların uygulanmasını sağlıyabiliriz.

System Center Capacity Planner(SCCP)

System Center ailesinin bu ürünü ismindende anlaşılacağı gibi tamamen planlama üzerine geliştirilmiş olan bir üründür.Şirket networkünüze kurmayı planladığınız Exchange,SCOM,SQL,vb.. gibi server rollerinin kurulumunu planlamak için bize sunulan donanım tabanlı bir kılavuzdur.Bu şekilde daha verimli kurulumlar planlayıp masraflarımızı ve hata toleransını minimize edebiliriz.Bu arada sadece sıfır kurulumlar için planlama değil aynı zamanda upgrade senaryoları içinde planlama yapabiliriz.Özellikle upgrade senaryosunda,donanım,mimari ve yazılım üzerinde analizler yapabiliriz.Dağıtık olarak yapacağımız kurulumlarda alt yapı ölçeklendirmesi yapabiliriz.Bu şekilde mevcut yapımızın performansını da modelliyebiliriz.SCCP ile,ileride oluşabilecek olan darboğazları belirliyebilir kendimize raporlar hazırlıyabiliriz.SCCP’ı kullanarak şirket networkümüzde yaptığımız değişikliklerin etkisini anlıyabiliriz.Ve bütün sunucularımızın verimli bir şekilde çalışıp çalışmadığından emin olabiliriz.

System Center Service Manager(SCSM)

IT organizasyonlarının birincil amacı son kullanıcılardan gelen problemlerinin analiz edilip giderilmesidir.Tabi ki her şirketin butür problemleri izleyip,raporlardığı belli başlı çözümler mevcuttur.SCSM,IT içerisinde bu şekilde süregelen iş akışlarını takip etmek ve izlemek için kullanılabilmektedir.İş akışları oluşturmak için sihirbaz tabalı formlar kullanılabilir.Third party uygulamalar ile entegre bir şekilde çalışabilmektedir.Aynı zamanda Microsoft Operation Framework(MOF) süreçleri de bu şekilde otomatikleştirilebilmektedir.SCSM,IT organizasyonunda uçtan uca bir yönetim sağlamaktadır.System Center bileşenlerinin bir arada çalışmasını sağlayan komplike bir çözümdür.

System Center Mobile Device Manager(SCMDM)

SCMDM,Windows Mobile cihazlarının şirket networküne erişimlerini kontrol eden bir çözümdür.Bu şekilde mobile olarak çalışan cihazlara BT ağımıza erişmeden önce bizim belirlediğimiz Group Policy ayarlarının uygulanmasını sağlıyabilliriz.Herhangi bir uygulamaya izin verebilir veya yasaklıyabiliriz.Mobile cihazlarda veri güvenliği ön plandadır.Çünkü çalınması kolay cihazlardır.SCMDM ile, çalınan cihazları uzaktan fabrika ayarlarını geri döndürüp içeriğini silebiliriz.System center ailesinin bu ürünü ile kurumun bütün mobile cihazlarını tek bir arayüz üzerinden kontrol edebiliriz.SCMDM,WSUS 3.0 tabanlı çalışarak otomatik update,hotfix dağatma işlemlerini gerçekleştirmektedir.SCMDM’ı MMC ile çalıştırabildiğimiz gibi Powershell’deki cmdlet’ler ile de yönetebilmekteyiz.Mobile cihazların yapacağı VPN bağlantılarını Cihaz yetkilendirme ile daha kararlı internetwork dolaşımını gerçekleştirebiliriz.Ve en güzeli ise SQL Server 2005 tabanlı olarak raporlar alabiliriz.Aynı zamanda bütün mobile cihazların envanterinide oluşturabilmekteyiz.SCMDM,günümüzde bir çok mobile cihazın desteklediği OMA-DM standartlarına uygundur.

System Center Essentials(SCE)

SCE,orta ölçekli yani en fazla sunucu ve 500 istemciye sahip olan IT organizasyonlarının tercih edebileceği system center ailesi ürünüdür.IT ortamının daha etkin bir biçimde izlenebilmesi,güncelleştirmelerinin takip edilmesi ve karşılaşılabilecek olan sorunların tespit edilmesi amacıyla kullanılabilmektedir.SCE,tüm IT ortamında kullanılabilecek proaktif yönetim,birleşik deneyim ve yüksek verimlilik sağlamaktadır.Bu şekilde bütün yazılım,donanım,server ve clientlarınızı izlemenize ve görüntülemenizi sağlayan tek bir konsol sunmaktadır.Bu şekilde IT organizasyonunuzdan veri toplamak otomatil bir hal alır.Karmaşık yönetim görevleri basitleşir.Sonuç olarak daha verimli,günvel ve güvenilir bir IT ortamına kavuşuyoruz.

System Center Yol Haritası

Evet arkadaşlar,yukarıda System Center ürün ailesine ait 8 adet ürüne gene bir bakış yapıp,neler yapıtğına baktık.Bundan sonraki System Center ile alakalı yazı dizisinde her ürünü teker teker inceleyeceğiz.System Center ile alakalı başka bir makalede görüşmek üzere…

Hoşçakalın…

Kaynak:

https://www.microsoft.com/systemcenter/en/us/default.aspx

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Hakan Uzuner

Sharing knowledge is a lifestyle

Etiket arşivi: Hyper-v

Hyper V

Hyper-V Failover Cluster Kurulumu (Bölüm-7)

Hyper-V Failover Cluster Kurulumu (Bölüm-6)

Microsoft System Center Urun Ailesi

Hyper-V Failover Cluster Senaryoları