Vmware ESX, hayatımıza girdi gireli tüm faydaları bizleri cezp etmekte. Sanallaştırma teknolojileri Türkiyede yavaş yavaş yaygınlaşmaya başladı. Firmalarda ki fiziksel serverlar üzerinde koşan işletim sistemlerini VMware ESX Server üzerine almak yani sanallaştırmak için, VMware firması, “ Vmware Converter ” adlı toolu çıkarmıştır. Bu bağlamda fiziksel sunucumuzu, disk tipi ve işletim sistemi gözetmeksizin convert edebilir yani sanallaştırabiliriz.

VMware Converter tool, ister çalıştığınız sistemi(online olarak), ister acronis, symantec vs. İle alınmış imajı veya başka bir yerde duran sanal işletim sistemini (ms virtual pc’lerde dahil) ya da uzaktaki bir bilgisayarı network üzerinden alıp ESX Server üzerine sanallaştırabiliyoruz.

Bende bunun nasıl yapılacağını adım adım anlatmaya çalıştım.

Belirtmem gereken önemli bir nokta var,

VMware Converter iki tiptir ve dolayısıyla lisanslaması farklıdır. Bunlar;

VMware Converter Enterprise: Bu, ek lisans gerektirir. VMware Workstation, VMware ESX Server üzerine fiziksel makine üzerinde koşan işletim sistemlerini convert edebiliriz.

VMware Converter Starter Edition: Ücretsizdir, ancak convert etmek istediğimiz işletim sistemini sadece VMware Workstation üzerine sanallaştırabiliriz, VMware ESX için Enterprise Edition satın alınmalıdır.

Benim senaryomda kullandığım, VMware Converter Enterprise Edition 3.0.1

VMware Converter giriş ekranı. Bütün ayarlar buradan yapılıyor. Girişte de bahsettiğim gibi;

Physical machines (Fiziksel Makineler)

Virtual appliances (Sanal cihazlar)

Virtual Machines (Sanal Makineler)

Third-party backup images ( 3. Parti yedekleme programları ile alınmış olan imajlar, VMware üzerine sanallaştırılabiliyor. )

Sol üstten “ Convert Machine “ e tıklıyoruz.

Yine yapılabilecekler geliyor. Next deyip devam ediyoruz.

 

Hedef göstermemizi istiyor. Ben şuan için üzerinde çalıştığım online olan makineyi sanallaştırıyorum ve onu anlatacağım. Next deyip devam ediyoruz. Üzerinde çalıştığınız makineyi değil de uzakta ki bir makineyi convert edebilirsiniz. Bu anlamda uzak bilgisayara vmware convert agent ı yüklenecektir.

Physical Computer seçip devam ediyoruz.

Fiziksel makinenin bize uzakta mı yoksa üzerinde çalıştığımız bu bilgisayar mı olduğunu soruyor. Bu bilgisayar olduğundan “This local machine” seçiyorum. Logon credentials ‘lar otomatik geliyor. Şayet A remote machine deseydin logon credentials bilgilerini girmemiz gerekecekti. Ve bu gireceğimiz kullanıcı admin haklarına sahip olmalıydı. Next deyip devam ediyoruz.

Kaynak data bilgilerini gösteriyor burada var olan disklerimi görüyorum. İstersem sadece c portition ımı alabilirim. Renk bilgilerinden de anlaşıldığı gibi “ C “  portition ım hem system hemde aktif. Eğer yine istersem diskimde sadece belirttiğim alan kadar (GB ya da MB cinsinden) alabilirim. Örneğin, C diskim gözüktüğü gibi toplam 34.18 GB, ama kullanılan 5,61. Ben bunu 5.61 den yukarı istediğim boyuta getirip öyle ESX üzerine alabilirim. VMware ESX üzerine aktarılırken şayet varsa hibernation dosyasını görme diyebiliyorum. Ayrıca, eğer formatlanmamış taze bir bölüm varsa bilgisayarınızda (resimde ki d portition ı gibi) bunların bölme işlemlerini “ Create a separate disk for each volume” kısmından yapabiliriz. Yani her her volume için bölümlenmiş diskler oluşturabilirim. Ben onu hiç hesaba katmadan devam ediyorum.

Destination kısmını belirteceğiz. Next deyip devam ediyoruz.

Hedef tipi seçmemizi istiyor. Eğer VMware ESX üzerine alacaksak sistemi bu tipte yani “ Vmware Infrastructure Virtual Machine” da kalıyor. Eğer bir VMware Workstation a alacaksak onu da seçebiliriz. Biz Vmware Infrastracture üzerinden ESX’e alacağımızdan bu şekilde devam edelim.

ESX Server’a sistemi direkt olraak taşıması için ESX server a bağlanmamız gerekiyor Logon Credential bilgilerini giriyorum.  Blade1 ESX host un üzerine alacağım işletim sistemin. Buraya Virtual Center’ın logon bilgilerinide girebilirim. Devam ediyoruz girdikten sonra.

Sanallaştıracağımız makinenin ismini girmemizi istiyor. Yazıp devam ediyoruz

Host’umuzu seçip devam ediyoruz.

Sanal makinemizi Datastore içinde ki hangi storage’e almak istediğimizi soruyor. Sizin için hangisi uygunsa onu seçip devam ediyoruz. Eğer Virtual Center seçmiş olsaydık ve uygun bir storage tanıtmışsak sotrage disklerinide( Lun ) burada görebilirdik. Şuan gördüğümüz ESX hostunun kendi diskleri.

ESX üzerinde ki seçtiğimiz Host’ta bu sunucu için en fazla kaç tane ethernet kartı olmasını ve hangi networke bağlı olduğunu görüp seçebiliyoruz. Sunucu açıldığında network bağlansın/bağlanmasın diyebiliyoruz.

VMware Tools’un yüklenmesini soruyor evet aktarırken onuda yükle diyorum ben.

“ Customize the identity of the virtual machine” bu checkbox’ı doldurursak, makinenin host kimliğini, kısacası tüm network ayrıntılarını devam ederken değiştirebiliriz. Sanallaştırdığım makinenin sağlıklı aktarılması ve çalışması için sistem geri yükleme noktalarının silinmesi gerektiğini öneriyor Vmware Converter Tool. Bende önerisine uyup devam ediyorum.

Fiziksel OS’i sanallaştırmak için hazır olduğunu söylüyor ve özeti geçiyor. Sanallaştırma işlemi bittikten sonra makine otomatik açılsın istiyoranız “ Power on the new virtual machine after creation “ checkbox’ı doldurun. Log Info butonuna bastığımızda ise bize log dosyalarının nerede tutulduğunu gösterecek.  Dönüştürme işleminde herhangi bir hata olursa yahut ayrıntılara göz atmak istersen burada ki logları inceleyebileceğiz. Finish diyoruz.

Dönüştürme işlemi başladı. Task Progress kısmında da loglar gözükmekte. Makinenin donanımına ve HDD doluluk oranına bağlı olarak bu işlem belli bir süre içinde bitecektir.

Ve varolan fiziksel işletim sisteminin sanallaştırması başarılı bir şekilde tamamlandı. C:\Windows\Temp\vmware-temp\vmware yoluna giderek Loglara ulaşıp ayrıntılara göz atabiliriz. Artık burayı kapatıyoruz ve Virtual Center’a bağlı olduğumuz VMware Infrastructre Client’ımızı açıyoruz.

Gördüğümüz gibi Blade1 hostumuzun üzerine makinenin geldiğini görüyoruz. Summary altında OS, CPU Memory bilgileri gözükmekte. Şurayı da atlamadan edemeyeceğim. İşlemci, ram ve kullandığı ram miktarı fiziksel makinede nasılsa aynen bu şekilde ayrılmış vaziyette buraya geliyor. Bunları değiştirebiliyoruz. Hemen makineyi açıp bir problem olup olmadığını kontrol ediyoruz.

Fiziksel işletim sisteminin Vmware ESX Server’da ki bir host üzerine Convert / dönüştürme işlemimizin başarıyla sonuçlandığını görmekteyiz.

Buğra KESKİN

 

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

 

 

 

 

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.

 

 

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

Önceki bölümlerde iscsı storage’i konfigüre ettik ve nodelar üzerinde gerekli olan adımları uyguladık. Bu bölümde ise failover cluster kurulumunu gerçekleştiriyoruz.

 

8. Failover Cluster Kurulumu

 

Failover Cluster kurulumunu (konfigürasyonunu) tek bir node üzerinde yapacağız ve bu yapılandırma her iki node’a da etki edecek.

 

Ben kurulum için ilk node’u seçiyorum (özel bir nedeni yok). HV-Node1 üzerinde Failover Cluster Management konsolunu açıyoruz.

 

 

8.1. Cluster Kurulumu Öncesi Kontrol

 

 

 

Windows Server 2008’deki bu konsol ve üzerindeki wizard’lar sayesinde cluster kurulumu gerçekten çok basit bir hal almış.

 

Cluster yaratmadan önce Validate a Configuration… wizard yardımı ile cluster için kullanacağımız Nodelar üzerinde kapsamlı bir kontrol gerçekleştirebiliyoruz. Bu kontrol ile Cluster için gerekli olan ihtiyaçlar her iki Node üzerinde kontrol ediliyor ve eksik bir şeyler varsa rapor olarak bize bildiriliyor. Bizde bu sorunlar için önceden önlem alıyor ve gerekli konfigürasyonları yapıyoruz. Böylece hata yapma şansımız minimuma inmiş oluyor.

 

Örnek olması açısından Validate a Configuration… wizard’ı çalıştırıyorum.

 

 

 

Browse butonu ile kontrol yapacağımız yani cluster üyesi yapmayı düşündüğümüz nodeları ekliyoruz.

 

 

 

Gördüğünüz gibi bilgiler active directory ortamından geliyor ve domain’e aldığımız iki node’u görüyoruz.

 

 

 

Her iki node’u aynı anda seçip Ok diyoruz.

 

 

 

Ve nodelar selected servers bölümüne ekleniyor.

 

 

 

Next dedikten sonra gelen Testing Options penceresinde Run all tests diyerek gerekli tüm testlerin yapılmasını sağlayabileceğimiz gibi, Run only tests I select diyerek seçim yapıp, network, storage, os configuration gibi belirli özelliklerin test edilmesini de sağlayabiliyoruz.

 

Run all tests ile devam edelim.

 

 

 

Next diyerek doğrulamayı başlatıyoruz.

 

 

 

Kontrol işlemi biraz zaman alabilir. Süreci izleyebiliyorsunuz.

 

 

 

Kontrol tamamlandıktan sonra successfully bilgisini görüyoruz. Bu testin başarılı bir şekilde tamamlandığını gösteriyor.

 

 

 

Ama bir uyarı var. Bu uyarının anlamı şu: kontrollerde bazı noktalarda eksikler tespit edildi ama bu noktalar cluster kurulumu için engel değil çünkü bunlar cluster sonrasında da düzeltilebilecek eksikler (ihtiyaç halinde).

 

View Report butonuna basarak raporun detaylarını görebilir, eksiklerin nerede olduğunu listeleyebilirsiniz.

 

View Report tıkladıktan sonra browser üzerinde bir rapor geliyor. Bu sayfada aşağı doğru ilerleyerek bilgileri inceleyebilirsiniz.

 

 

 

Finish ile wizard’ı kapatıyoruz.

 

 

 

Eğer ki cluster için büyük bir sorun olsaydı successed mesajı yerine hatalar görecektik ve bu da cluster öncesi mutlaka düzeltilmesi gereken sorunlar anlamına gelecekti.

 

Büyük bir sorun olmadığına göre Cluster’ı oluşturalım.

 

 

8.2. Cluster Kurulumu

 

HV-Node1 üzerinde, Failover Cluster Management konsolunda Ceate a Cluster diyerek wizard’ı açıyoruz.

 

 

 

Next ile ilerliyoruz.

 

 

 

Nodeları ekleyip devam ediyoruz.

 

 

 

Aşağıdaki Access Point penceresi önemli bir bölüm.

 

Burada öncelikle cluster için bir isim veriyoruz. Bu isim active directory içerisinde bir computer olarak tanımlanacak (otomatik olarak). Bu nedenle var olmayan ve cluster’ı temsil etmesini istediğiniz bir isim vermelisiniz.

 

Yine aşağıdaki pencerede seçmiş olduğumuz network üzerinde uygun bir IP veriyoruz. Bu ip adresi de nodelardan farklı ve network üzerinde var olmayan bir IP olmalı çünkü cluster’ı temsil eden IP bu olacak.

 

İkinci network üzerinde cluster hizmeti vermeyeceğiz, onun için seçimini kaldırıyorum. 3ncü network ise özel bir durumdan dolayı bende gözükmüyor.

 

Next ile ilerliyoruz.

 

 

 

Confirmation penceresinde Next diyerek kurulumu başlatıyoruz.

 

 

 

Kurulum fazla uzun sürmeyecektir.

 

 

 

Kurulum tamamlandıktan sonra Successfully mesajını görüyoruz ve Finish ile wizard’ı kapatıyoruz.

 

 

 

Failover Cluster Management konsoluna dönüyoruz ve eğer bir sorun yoksa her iki Node un da eklenmiş olduğunu görebiliyoruz.

 

 

 

Artık iki fizksel sunucumuz aynı cluster’ın üyesi olarak çalışıyor ancak henüz herhangi bir servis yada uygulama ekli değil.

 

Nodes bölümüne gelirseniz iki node’un da up durumda olduğunu görebilirsiniz.

 

 

 

Storage bölümünde ise Node’lar üzerine iSCSI initiator ile eklediğimiz ve storage üzerinde duran iki adet diski görebiliyoruz. Bu diskler şu an clustered ve online durumda.

 

 

 

Networks bölümünde ise node’lar üzerindeki cluster networkler yer alıyor. Burada 3 network yer alıyor olmalı ama dediğim gibi benim sistemimdeki özel bir durum nedeniyle ikisi listeleniyor.

 

 

 

Biz cluster yapılandırmasını HV-Node1 üzerinde yaptık. Aynı işlemi ikinci node üzerinde yapmaya gerek yok. İkinci yani HV-Node2 üzerinde de Failover Cluster Management konsolunu açarsanız, nodeların ve varsa diğer cluster kaynaklarının aynı şekilde orada da listelendiğini görebilirsiniz.

 

 

8.3. Quorum Disk Konfigürasyonu

 

Quorum her cluster yapısında bulunmaz. Sadece failover-server olarak geçen clusterlarda bulunur. Temel amacı cluster bilgisini tutmak ve bu bilgiyi o an cluster kaynaklarının sahibi olan (doğal olarak quorum’un da sahibi) nodeun kullanımına sunmaktır.

 

Hyper-V üzerinde çalışan sanal makineler için oluşturduğumuz cluster yapısı da bir failover cluster olduğu için quorum ihtiyacı vardır.

 

Hatırlarsanız storage üzerinde quorum için kullanılmak üzere 2GB boyutlu bir Virtual Disk oluşturup bunu nodelara atamıştık.

 

Cluster kurulumunu HV-Node1 üzerinde yaptığımız ve clustered disklerin şu anki sahibi HV-Node1 olduğu için Quorum yapılandırmasına da HV-Node1 üzerinde devam ediyorum.

 

Önce HV-Node1 üzerinde NTFS formatlı bir partition yaratmalıyız. Bunun için Disk Management’ı açıyoruz.

 

Öncelikle ilgili diski online yapıyoruz.

 

 

 

New Simple Volume diyerek yeni bir volume yaratmak için wizardı başlatıyoruz.

 

 

 

 

 

Volume size’ı değiştirmeden devam ediyorum.

 

 

 

 

NTFS olarak formatlıyoruz.

 

 

 

Finish ile bitiriyoruz.

 

 

 

Bu işlem sonrası volume Computer altına geliyor ve dikkat ederseniz Type olarak Clustered Disk görünüyor. İsmini ise ben quorum olarak set ettim.

 

 

 

Aynı disk HV-Node2 üzerinde Computer altında görünmez çünkü aynı anda sadece bir node cluster kaynaklarına (disk, uygulama/servis vs..) sahip olabilir.

 

Quorum konfigürasyonu için yine HV-Node1 üzerinde Failover Cluster Management konsolunu açıyoruz ve Configure Cluster Quorum Settings diyoruz.

 

 

 

Next ile devam ediyoruz.

 

 

 

Node and Disk Majority seçiyoruz.

 

 

 

Quorum bilgisinin hangi volume üzerinde duracağını belirtiyoruz. Aşağıdaki pencerede clustered diskler üzerindeki volume’lar listelenir. Şu an için iki clustered diskimiz var ancak sadece birisi üzerinde volume oluşturduk bu nedenle sadece o listeleniyor.

 

İlgili diski seçerek devam ediyoruz.

 

 

 

Next ile konfigürasyonu başlatıyoruz.

 

 

 

Quorum settings yapılıyor.

 

 

 

Successfully bilgisini görüyoruz ve quorum settings başarılı bir şekilde tamamlanmış oluyor.

 

 

 

Failover Cluster Management konsoluna döndüğümüzde quorum tipini ve hangi disk üzerinde olduğu bilgisini cluster summary bölümünde görebiliyoruz.

 

 

Failover cluster kurulumu ve quorum disk konfigürasyonu bu kadar. Cluster yapısına servis ekeleme konusunu Bölüm-6 da bulabilirsiniz.

 

 

Serhat AKINCI – IT Pro.

Temel node konfigürasyonunu Bölüm-3 te tamamlamıştık. Bu bölümde ise nodelar için cluster yapısında kullanılmak üzere disk atama işlemini gerçekleştiriyoruz.

 

7. Cluster Nodeları için Disk Atamak

 

Storage yani organizasyonumuzda storage.bemar.corp olarak yer alan ve Microsoft iSCSI Software Target yazılımını çalıştıran makineye geçiyoruz.

 

Microsoft iSCSI Software Target yönetim konsolunu açalım.

 

İlk işimiz az önce storage’i gösterdiğimiz Node’lar için Target tanımlamak. Bunu Nodelara storage’i gösterme işleminin tam tersi olarak düşünebilirsiniz. Yani bu sefer de Storage’e diyoruz ki “Bak burada sana gelen iki adet node var ve bunları senin üzerinde target olarak tanımlayalım ki atayacağımız diskleri kullanabilsinler ”

 

 

7.1. iSCSI Storage üzerinde HV-Node1 için Target Tanımı

 

Storage makinesinde iSCSITarget konsolu üzerinde Create iSCSI Target diyerek Create iSCSI Target Wizard’ı açıyoruz.

 

 

 

Next ile devam ediyoruz.

 

 

 

İlk target için bir isim giriyoruz: HV-NODE1

 

 

 

Sonraki pencerede ilgili target için IQN identifier tanımlıyoruz.

 

Browse butonuna tıkladığımızda iki farklı IQN listeleniyor olacak. Bu IQN’ler, az önce iSCSI initiator ile storage’e bağladığımız (storage’i gösterdiğimiz) node’ların kendisidir. Yani node’lar üzerinde yaptığımız discover işleminin amacı buydu. Eğer o işlemi yapmasaydık, IQN listesinde bu iki node’u göremeyecektik.

 

İlk target ekleme işlemini HV-Node1 için yapıyoruz, bu nedenle Hv-node1.bemar.corp olan’ı yani ilk node’u temsil eden IQN’i seçerek devam ediyorum.

 

iqn.1991-05.com.microsoft.hv-node1.bemar.corp

 

 

 

OK dedikten sonra Next ile devam ediyoruz.

 

 

 

Ve Finish ile Target ekleme işlemini bitiriyoruz.

 

 

 

HV-Node1 için target ekleme işlemi bitti. Şimdi aynı işlemi HV-Node2 için de yapalım.

 

 

7.2. iSCSI Storage üzerinde HV-Node2 için Target Tanımı

 

Aynı şekilde iSCSI Targets’a sağ tıklıyoruz ve Create iSCSI Target diyerek wizard’ı açıyoruz.

 

 

 

Next ile ilerliyoruz.

 

 

 

İkinci target için bir isim giriyoruz: HV-NODE2

 

 

 

Sonraki pencerede ilgili target için IQN identifier seçiyoruz.

 

Yine Browse butonuna tıkladığımızda iki farklı IQN listeleniyor olacak. Biri az önce tanımladığımız HV-Node1’e ait. Diğeri ise HV-Node2’ye ait.

 

Bu seferki ekleme işlemini HV-Node2 adına yaptığımız için Hv-node2.bemar.corp olan’ı yani ikinci node’u seçerek devam ediyorum.

 

iqn.1991-05.com.microsoft.hv-node1.bemar.corp

 

 

 

Next ile devam ediyoruz.

 

 

 

Ve Finish ile ikinci target ekleme işlemini de bitiriyoruz.

 

 

 

Target ekleme işlemi bu kadar.

 

Her iki node’u iSCSI Target olarak tanımladığımıza göre, konsol üzerindeki görüntü aşağıdaki gibi olmalı.

 

 

 

Artık eklediğimiz bu target’lara yani cluster node’larına Virtual Disk’ler ekleyebiliriz.

 

 

7.3. iSCSI Storage üzerinde HV-Node1 için Disk (virtual disk) Eklemek

 

iSCSI Targets bölümünde HV-Node1’e sağ tıklıyoruz ve Add Existing Virtual Disk to iSCSI Target diyoruz.

 

 

 

Eklemek istediğimiz Virtual Disk’leri seçeceğiz. Henüz yarattığımız iki adet disk olduğu için, listede iki Virtual Disk yer alıyor. Yazımızın ilk bölümlerinde uyguladığımız yöntemle yeni Virtual Disk’ler yaratabilir, bu şekilde target’lar’a ekleyebilirsiniz.

 

 

 

Bir diski Quorum, diğer diski ise sanal makineler için kullanacağız. Bu nedenle iki adet virtual disk yaratmıştık ve ikisini de seçtik.

 

Ok diyerek işlemi tamamlıyoruz.

 

Konsol üzerinde aşağıdaki gibi görünüyor olmalı.

 

 

 

Aynı işlemi HV-Node2 için de yapmamız gerekiyor.

 

 

7.4. iSCSI Storage üzerinde HV-Node2 için Disk (virtual disk) Eklemek

 

iSCSI Targets bölümünde bu sefer HV-Node2’ye sağ tıklıyoruz ve Add Existing Virtual Disk to iSCSI Target diyoruz.

 

 

 

İki Virtual Disk’i de seçip Ok diyoruz.

 

 

Dikkat ederseniz yukarıdaki pencerede Access By bölümünde HV-Node1 var çünkü bu diskleri az önce HV-Node1’e eklemiştik. Bu işlemden sonra buraya HV-Node2 de gelecek.

 

Ekleme işleminden sonra konsolda aşağıdaki gibi görünüyor olmalı.

 

 

 

Devices kısmında ise her iki Virtual Disk’in, her iki node tarafından erişilebileceği bilgisini görüyor olmalıyız.

 

 

 

Her şey örtüşüyor ise storage üzerindeki işimiz bitti diyebiliriz

 

 

7.5. HV-Node1 üzerinde Disk (virtual disk)’i Görmek

 

Node’ları storage üzerinde target olarak tanımlamıştık ve önceden yarattığımız Virtual Disk’leri bu target’lara eklemiştik. Bu Virtual Disk’leri fiziksel node’lar üzerinde kullanabilmek için, yine node’lar üzerinde çalışan iSCSI initiator yazılımında son bir konfigürasyon daha yapmamız ve Virtual Disk’leri fiziksel node’lara göstermemiz gerekiyor.

 

Bu işlemi yine her iki node üzerinde de yapacağız.

 

Öncelikle HV-Node1’e gidiyoruz ve iSCSI initiator yazılımını açıyoruz.

 

 

 

Targets tabına geçip refresh diyoruz ve bu node için oluşturduğumuz target’ın listede görünmesini sağlıyoruz.

 

 

Eğer Refresh dediğinizde Target gelmiyor ise, storage üzerinde yaptığınız target tanımında yada storeage’e erişimde bir sorun vardır.

 

Yukarıda listelenen target’ın durumu inactive olarak görünüyor. Bu durum şimdilik normaldir.

 

Target’ı seçtikten sonra Log On.. diyoruz ve gelen pencerede Automatically restore this connection when the computer starts kutucuğunu tıklayıp Ok diyoruz.

 

Bu ayar ile sistem başladığında ilgili target bağlantısının otomatik olarak yapılmasını sağlamış olduk.

 

 

 

Bu işlemden sonra, inactive olan durum bilgisini connected olarak görünüyor olmalı.

 

 

 

Son olarak Volumes and Devices tabına gelip Autoconfigure diyoruz ve storage üzerinde bu target için tahsis edilen Virtual Disk’lerin gelmesini sağlıyoruz.

 

Bu diskler, az önce eklediğimiz disklerdir (iSCSI Storage üzerinde HV-Node1 için disk (virtual disk) eklemek bölümünde).

 

 

 

HV-Node1 için disk ekleme işlemi bitti.

 

Artık Server üzerinde Disk Management bölümünden baktığımızda eklediğimiz iki diski görebiliriz.

 

 

 

Birisi 2GB, diğeri ise 30GB boyutunda. Bunlar bizim storage üzerinde yaratmış olduğumuz Virtual Diskler. Henüz üzerlerinde partition ve dosya sistemi yok. Ayrıca offline durumdalar.

 

Aynı işlemleri HV-Node2 için de yapalım.

 

 

7.6. HV-Node2 üzerinde Disk (virtual disk)’i Görmek

 

HV-Node2 üzerinde iSCSI initiator’ı açıyoruz ve Targets tabına geçip Refresh diyoruz.

 

Target listeye geldikten sonra seçerek Log On… diyoruz ve Automatically restore this connection when the computer starts kutucuğunu işaretleyerek tekrar Ok diyoruz.

 

 

 

Ok dedikten sonra Connected bilgisini görüyor olmalıyız.

 

 

 

Daha sonra Volumes and Devices tabına geçiyoruz ve Autoconfigure diyerek storage üzerinde bu target için eklediğimiz disklerin gelmesini sağlıyoruz.

 

 

 

Ok dedikten sonra HV-Node2 üzerindeki disk ekleme işlemi de bitmiş oluyor.

 

 

 

Yine Disk Management bölümünden kontrol ettiğimizde her iki diski de görüyor olmalıyız.

 

Böylece storage üzerinde duran iki diski, Hyper-v node’ları üzerine eklemiş olduk ve ortak kullanıma sunduk.

 

Artık yapımız cluster kurulumu için hazır.

 

Failover cluster kurulumunu Bölüm-5 te inceliyoruz.

 

 

Serhat AKINCI – IT Pro.