Bu makale serisi Windows Server 2008 Hyper-V platformunun failover cluster yeteneğini anlatmak için hazırlanmıştır.

Makaleler içerisinde Hyper-V Failover Cluster yapılarındaki ihtiyaçların neler olduğu, bu ihtiyaçlar doğrultusunda yapılan seçimlerin yapı üzerindeki etkileri, temel storage bilgileri, cluster nodelarının ve diğer serverların topoloji içerisindeki konumları gibi teorik bilgilerin yanı sıra, storage ve nodeların yapılandırılması, failover cluster kurulumu, sanal makinelerin failover cluster yapısına dahil edilmesi gibi teknik konular da uygulamalı olarak ele alınmıştır.

Bu makale serisi ile organizasyonunuz içerisindeki iki Hyper-V Host’unu yazılım tabanlı bir iSCSI storage ile birlikte failover cluster yapısına dahil edip, sistemi fiziksel başarısızlıklara karşı koruma altına alabilecek, high available sanal makineler oluşturabileceksiniz.  Bununla birlikte Quick Migration ve VM Failover gibi konuların nasıl gerçekleştiğini de öğrenmiş olacaksınız.

Hyper-V failover cluster konusu uzun ve kapsamlı bir konu olduğu için makaleyi bölümler halinde hazırlamayı uygun gördüm. Bu doğrultuda makalelerde yer alan konu başlıkları ve bu başlıkların hangi bölümler içerisinde yer aldığını görmek için aşağıdaki içerik bölümü ile başlayalım.

 

 

(Bölüm-1) 1. Failover Cluster Nedir?

 

(Bölüm-1) 2. Fiber Channel ve iSCSI Storage’ler

 

(Bölüm-1) 3. Hyper-V Failover Cluster Yapılarında Storage’ın Önemi

 

(Bölüm-1) 4. Örnek Topoloji ve Temel Gereksinimler

 

 

(Bölüm-2) 5. iSCSI Storage Konfigürasyonu

 

(Bölüm-2) 5.1. IP ve Domain Ayarları

 

(Bölüm-2) 5.2. Microsoft iSCSI Software Target Kurulumu

 

(Bölüm-2) 5.3. Microsoft iSCSI Software Target Üzerinde Virtual Disk Yaratmak

 

 

(Bölüm-3) 6. Cluster Nodeların Konfigürasyonu

 

(Bölüm-3) 6.1. IP ve Domain Ayarları

 

(Bölüm-3) 6.2. HV-Node1 Üzerine Gerekli Feature’ların Yüklenmesi

 

(Bölüm-3) 6.3. HV-Node2 Üzerine Gerekli Feature’ların Yüklenmesi

 

(Bölüm-3) 6.4. iSCSI Initiator ile HV-Node1 için iSCSI Storage Discovery

 

(Bölüm-3) 6.5. iSCSI Initiator ile HV-Node2 için iSCSI Storage Discovery

 

 

(Bölüm-4) 7. Cluster için Disk Atamak

 

(Bölüm-4) 7.1. iSCSI Storage üzerinde HV-Node1 için Target Tanımı

 

(Bölüm-4) 7.2. iSCSI Storage üzerinde HV-Node2 için Target Tanımı

 

(Bölüm-4) 7.3. iSCSI Storage üzerinde HV-Node1 için Disk (virtual disk) Eklemek

 

(Bölüm-4) 7.4. iSCSI Storage üzerinde HV-Node2 için Disk (virtual disk) Eklemek

 

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

 

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

 

 

(Bölüm-5) 8. Failover Cluster Kurulumu

 

(Bölüm-5) 8.1. Cluster Kurulumu Öncesi Kontrol

 

(Bölüm-5) 8.2. Cluster Kurulumu

 

(Bölüm-5) 8.3. Quorum Disk Konfigürasyonu

 

 

(Bölüm-6) 9. Hyper-V Sanal Makinelerini Cluster Yapısına Dahil Etmek

 

(Bölüm-6) 9.1. Nodelar Üzerine Hyper-V Kurulumu

 

(Bölüm-6) 9.2. Test için Sanal Makine (VM) Yaratılması

 

(Bölüm-6) 9.3. Failover Cluster Yapısına Virtual Machine Servisini Eklemek

 

 

10. Hyper-V Failover Cluster Sonrası Gelen Yetenekler

 

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

 

10.1.1. Quick Migration Nedir?

 

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

 

10.2. VM Failover (Sanal Makine Hata Telafisi)

 

10.2.1. VM Failover Nedir?

 

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

 

 

1. Failover Cluster Nedir?

 

Failover Cluster (Küme) teknolojisi (servisi), organizasyonumuz içerisindeki sunucuların ve bu sunucular üzerinde çalışan çeşitli uygulamaların/servislerin fail olması durumunda (genelde donanımsal başarısızlıklar yüzünden), hizmet veremez duruma geçen ilgili servis ve uygulamaların cluster üyesi diğer sunucu/sunucular üzerinde hizmet vermeye devam etmesini sağlayan bir teknolojidir.

 

Anlamlı bir Failover Cluster yapısı için genelde fiziksel sunucular ile temsil edilen (bazı senaryolarda sanal da olabilir) ve node olarak adlandırılan en az iki sunucu olmak zorundadır. Bununla birlikte çoğu zaman node’ların erişebildiği ortak bir storage (hardware/software) şartı da vardır.

 

Cluster yapıları mission-critical olarak tanımlanan birçok uygulama ve servis için önemlidir ancak sanallaştırma tarafındaki önemi çok daha büyüktür.

 

Sanallaştırmanın temel amaçlarından olan konsolidasyon yani çok sayıdaki fiziksel sunucuyu daha az sayıdaki fiziksel sunucu üzerinde sanal olarak konumlandırma işlemi sonucunda, aynı fiziksel host üzerinde birden fazla sanal iş yükü çalışmaya başlar ve host’un down olması durumunda üzerindeki tüm iş yükleri bu durumdan olumsuz etkilenir. Yani cluster ile güvenceye alınmamış ortamlarda çalışan sanal sistemlerde risk çok daha büyüktür.

 

Cluster yapılarıyla amaçlanan ise, beklenmedik bir anda meydana gelen arızalara ve genelde donanımsal sorunlar yüzünden yaşanan servis kesintilerine karşı önlem almak, bu doğrultuda  ilgili uygulamaları/servisleri otomatik olarak diğer cluster üyesi sunucular üzerinden hizmete sunabilmektir.

 

Konuyu basit bir örnekle biraz daha açmak istiyorum.

 

İlk senaryomuzda sanallaştırma olmayan bir ortamda çalıştığımızı düşüyoruz ve organizasyonumuz içerisinde 5 fiziksel sunucu bulunuyor.

 

Bu sunucuların rolleri ise şu şekilde:

 

1. DC + DNS + DHCP (Domain Controller)

2. SQL Server

3. Exchange Server

4. ISA Server

5. Application Server (üzerinde herhangi bir ticari uygulama olabilir)

 

Bu ortamdaki fiziksel sunuculardan birisi herhangi bir nedenden dolayı down olduğu zaman, üzerinde çalışan uygulamalar ve servisler de fail olur ve hizmet veremez.

 

Örneğin SQL Server makinesinin down olduğunu düşünelim. Eğer SQL Server için oluşturulmuş cluster senaryonuz yoksa (ki bizim örnek yapımızda yok), bu durumda ilgili DB’lere erişi durur ve SQL Serverı ayağa kaldırmak ya da DB’leri başka bir sunucu üzerinde online hale getirmek için stresli bir süreç başlar. Organizasyon içerisindeki diğer sunucular ise kendi işlerini yapmaya devam edebilirler. Örneğin DC hala ayaktadır, mail trafiği devam ediyordur, internet erişimi vardır vs.. Sorun yapının sadece bir bölümüne etki etmiştir.

 

İkinci senaryomuzda ise ilk senaryodaki fiziksel ortamı başarılı bir konsolidasyon süreci sonunda tek bir Host üzerinde sanallaştırdığımızı düşünelim. Yani artık elimizde 5 fiziksel sunucu yerine tek ve daha güçlü bir fiziksel sunucu var. Üzerinde ise 5 ayrı sanal makine (VM yada sanal iş yükü) çalışıyor.

 

Fiziksel – Windows Server 2008 Hyper-V Host

Sanal – DC + DNS + DHCP (Domain Controller)

Sanal – SQL Server

Sanal – Exchange Server

Sanal – ISA Server

Sanal – Application Server (ticari bir uygulama olabilir)

 

Gördüğünüz gibi aynı hizmetler sanal olarak çalışmaya devam ediyor. Derken host (fiziksel) sistem donanımsal bir sorunla karşılaşıyor ve down oluyor. İşte bu an felaketin başladığı andır çünkü host sistem ile birlikte üzerindeki tüm sanal makineler (sanal iş yükleri) de fail olmuştur. Yani 5 sanal sunucu ve üzerindeki uygulamalar/servisler hizmet veremez duruma geçmiştir. Bir anda firmanın tüm işleri durur ve o an için hızlı bir geri dönüş senaryonuz yoksa sanal makineleri ayağa kaldırmak oldukça zaman alabilir. Bu durumda yaşanan stres ve durumun iş süreçlerine etkisi tamamı fiziksel olarak çalışan ortamdan çok çok daha fazladır.

 

Toparlarsak; tamamı fiziksel olarak çalışan yapılardaki donanımsal başarısızlık genelde down olan tek bir sunucuyu ve üzerindeki uygulamaları/servisleri etkiler (dolaylı yoldan farklı etkileri olabilir). Ama sanallaştırılmış ve önlem alınmamış ortamlardaki donanımsal başarısızlıklar birden fazla sanal iş yükünü etkiler ve sonuçları çok daha fazla hissedilir.

 

Sanallaştırılmış ortamlarda bu gibi felaketlerin önüne geçebilmek adına Hyper-V teknolojisi Windows Server Cluster servisini kullanabilme yeteneğine sahiptir ve en az iki fiziksel host ile kümelenerek başarısızlık durumunda failover (hata telafisi) sağlayabilmektedir.

 

Failover Cluster yapıları temelde mission-critical uygulama ve servisler için downtime’ı en aza indirmeyi amaçlar ve cluster üyesi node’lar üzerindeki uygulama ve servisler için High Availability – HA (Yüksek Erişilebilirlik) sağlar. Hyper-V üzerinde çalışan sanal makineler ise Windows Failover Cluster servisi ile High Available şekilde çalışabilirler.

 

 

2. Fiber Channel ve iSCSI Storage’ler

 

Failover Cluster özel bir teknoloji olduğu için yazılımsal ve donanımsal anlamda bir takım ihtiyaçları vardır. Özellikle storage tarafında seçeceğimiz bağlantı tipi (iSCSI/FC), disk özellikleri (SCSI, SAS, Sata vs..) ve ürünün donanımsal yada yazılımsal olması yapının maliyetine ve performansına direkt olarak etki eden faktörlerdir.

 

Storage aslında depolama anlamına gelmektedir. Örneğin server üzerindeki local bir diski de storage olarak adlandırabiliriz. Bizim cluster yapılarında bahsettiğimiz storage ise serverların ortak olarak erişebildiği depolama alanları sağlayan cihazlar/yazılımlardır. Bu nedenle yazıda geçen storage kelimesini ortak depolama alanı olarak algılamalısınız (ör: SAN).

 

FC yani Fiber Channel bağlantılı storage’lerin sahip olma ve ekipman maliyetleri iSCSI storage’lere göre daha yüksektir. Bununla birlikte FC storage’ler iSCSI’e göre daha performanslıdır.

 

Bu gün 4 ya da 8GB’lık FC HBA’ler var ve bu HBA’ler dual olarak çalışabiliyor. Yani 8Gb x 2 şeklinde. Ayrıca bu yapılarda serverlar ile storage arasındaki bağlantı fiber optik kablolar ile gerçekleşiyor ve bu ürünler uygun disk’ler ile desteklendiği taktirde çok yükse hızlarda okuma/yazma (disk i/o) değerleri sağlayabiliyor.

 

iSCSI ise network (ethernet) üzerinden çalıştığı için storage erişim hızı network bandwidth ile doğru orantılı durumdadır. Yaygın olarak kullanılan hız ise 1Gbps dir. 10Gbps NIC ve network donanımları da kullanılabilmektedir ancak bu donanımlar şimdilik 1Gbps ürünler kadar yaygın değiller. Ayrıca ethernet teknolojisinin gelecekteki hali olan 100Gbps üzerinde çalışmalar devam ediyor ve bu teknoloji şu an çalışır durumda. Yılların teknolojisi ethernet ilerleyen senelerde de hız kesmeden yoluna devam edecek ve bu gelişim iSCSI bağlantılı storage’ler açısından oldukça iyi olacak gibi görünüyor.

 

Bağlantı tipi ve hızı dışında okuma/yazma performansını etkileyen bir diğer nokta ise storage üzerindeki disklerdir. Genelde Sata, SAS, SCSI diskler kullanılır ve bu diskler her iki bağlantı teknolojisi için de kullanılabilmektedir. Bu fiziksel disklerin rpm değerleri ve bağlı bulundukları kontroller kartların donanımsal özellikleri de okuma/yazma performansına direkt etki etmektedir. Bu gibi çok sayıda fiziksel diski bulunan, bu disklerin çeşitli bus yapıları ile birbirine bağlı olduğu storage’ler genelde SAN (Storage Area Network) olarak adlandırılırlar.

 

İnsanların kafasında Fiber Channel = SAN şeklinde bir eşleşme yer etmiş durumda ama bu doğru değil çünkü SAN bir topolojidir. Protokolü fiber channel olabileceği gibi TCP/IP de olabilir.

 

Tüm bunların dışında storage üzerinde konumlanacak uygulamanın tipi ve disk kullanım karakteristiği de performans ve storage seçimi açısından önemli kriterlerdir Sanallaştırma ortamlarınızda yoğun çalışan VM’leriniz varsa ve maliyeti karşılayabiliyorsanız, her zaman için Fiber Channel storage’ler kullanmanızı öneririm.

 

Eğer FC arabirimi olan bir storage kullanmayı planlıyorsanız, storage ve diskler dışında temin edilmesi gereken bazı ek donanımlar da vardır. Fiziksel sunucuların Örneğin Serverların FC storage’e erişebilmesi ve üzerindeki LUN’ları kullanabilmesi için gerekli HBA’ler (Server’lara Fiber Optik arabirim sağlar) ve ihtiyaç halinde SAN switch’ler ek donanımlar için verilebilecek en güzel örnekleridir. Bu donanımlar tabi ki maliyete etki eder.

 

iSCSI arabirimli storage’lara ise daha düşük maliyetler ile sahip olmak mümkün. Yine serverların iSCSI storage’lere erişmesi için kullanılabilecek özel HBA’ler var ancak bunların maliyeti FC HBA’ler kadar yüksek değil. Ayrıca sıradan network kartlar ile de iSCSI Storage’lere erişmek mümkün. Ama yukarıda da bahsettiğimiz gibi performans Fiber Channel kadar yüksek olmayacaktır.

 

(FC) Fiber Channel: Aslında bir protokoldür. Bizi ilgilendiren taraftan baktığımızda ise fiber optik bağlantı arabirimi olduğunu söyleyebiliriz. Yani ethernet gibi bir arabirim. Kabaca server ile storage arasında çekilmiş fiber optik bir kablo (gerekli durumlarda arada bir fiber switch olabilir) ve bu kablonun server ve storage üzerinde uygun FC HBA’ler ile sonlandırıldığı sistemlerdir. Server üzerinde tanımlanan storage birimlerine (LUN) iletilmesi gereken disk i/o requestlerinin, yine bu kanal yani fiber optik hat üzerinden geçerek uygun protokol ile iletildiği yapılar olarak düşünebilirsiniz.

 

(iSCSI) Internet Small Computer System Interface: iSCSI de bir protokoldür ve temel amacı SCSI paketlerini TCP/IP networkleri üzerinde taşımaktır. İsminin başındaki (i) de buradan gelmektedir. iSCSI sistemleri zaten var olan bir teknoloji ile başka bir teknolojinin birleşimi gibi düşünebilirsiniz. SCSI paketlerini alıyoruz, ip trafiği üzerine bindiriyoruz… Ama performans FC’e göre daha düşüktür çünkü TCP/IP yüksek blok i/o için tasarlanmış bir protokol değildir ve normal bir networkte (ethernet) max. 1512kb frame size sahip paketler taşıyabilir, yani yaklaşık 1,5kb blok i/o yapılabilir. TCP/IP mimarisi gereği ortaya çıkan bu durum iSCSI tarafındaki verimi düşüren en önemli etkendir. Günümüzde yaygınlaşan ve Windows Server 2008 R2’nin de desteklediği Jumbo Frame özelliği sayesinde TCP/IP üzerinde yaklaşık 8-9kb’lik blok i/o yapılabilmektedir. Tabi bu özelliğinin işletim sistemi, ethernet kartları ve switch’ler tarafından destekleniyor olması gerekir.

 

Peki, storage’in ve bağlantı teknolojisinin Hyper-V Cluster senaryolarındaki önemi nedir?

 

 

3. Hyper-V Failover Cluster Yapılarında Storage’ın Önemi

 

Host to Host Failover Cluster senaryosunda VM’ler (sanal makineler) host sistemler üzerinde değil, her iki node’un da erişebildiği ortak bir storage üzerinde durur. Burada storage üzerinde duran VM’den kastımız VM’in background dosyalarıdır. Yani VM’ler host’lar üzerinde çalışıyor ama XML, VHD, VSV, BIN gibi ilgili dosyaları storage üzerinde duruyor.

 

Aşağıda örnek bir topology var.

 

Buradaki storage FC yada iSCSI olabilir. Her iki fiziksel host -ki biz bunları node olarak adlandırıyoruz- storage’e üzerindeki ilgili birimlere (LUN) erişebiliyor.  Storage üzerinde 4 ayrı LUN var ve her bir LUN içerisinde ayrı bir VM duruyor. Bu 4 VM, 2 Hyper-V Host’u üzerinde çalışıyor.

 

 

 

Bu yapıda storage’in önemi ise şu: Node’lar üzerinde çalışan ama arka planda storage üzerinde konumlanan VM’ler işletim sistemi(sanal) ve uygulama(sanal) process’lerini gerçekleştirdikçe, ilgili veriler storage üzerindeki ilgili dosyalara yazılır (VHD, BIN, VSV vs..). Bu durumda storage bağlantı teknolojisi ve cihaz üzerindeki diskler ne kadar hızlı ise, bu işlemler de o kadar rahat ve hızlı gerçekleşir ve bu doğrultuda VM’ler o derece performanslı çalışır.

 

Örneğin elimizdeki storage’in iSCSI arabirimi kullandığını düşünelim ve 1gbps hızında bir networkümüz olsun. Bu durumda storage erişim hızı max. 1gbps ile sınırlıdır. Yani elimizde sanal makine aksiyonlarına ait verilerin aktığı tek şeritli bir yol varmış gibi düşünebilirsiniz. Ama storage arabirimi olarak Fiber Channel kullanmış ve örneğin yapıyı 8gbps HBA’ler ile kurmuşsanız, elinizde 8 şeritli bir otoban olduğunu söyleyebiliriz. Ayrıca desteklendiği durumlarda dual HBA kullanmanız demek, 8gbps x 2 şeklinde 16 şeritli bir otoban demek 

 

Sonuç olarak host’lar ile storage arasındaki bağlantı teknolojisi ne kadar hızlı ise veri aktarımı o kadar hızlı gerçekleşir. Bu da anlık okuma/yazma gerçekleştiren VM’ler için daha performanslı bir çalışma ortamı sağlar.

 

Bağlantı teknolojisi dışında storage üzerindeki disklerin tipi ve hızlarının da önemli olduğunu söylemiştik. SATA, SCSI, SAS ve 7200rpm, 10000rpm, 15000rpm gibi disk tipleri de performansa etki edecektir.

 

Ayrıca disklerin çalıştığı kontroller kartlar, bu kartların memory durumları ve disklerin raid yapılandırmaları da performans için belirleyici olmaktadır.

 

Bu noktada daha önce de bahsettiğimiz maliyetler devreye giriyor çünkü sağlam bir Fibe Channel yapısı kurmak gerçekten ciddi rakamlara mal oluyor.

 

Biz bu makalemizde yazılımsal bir iSCSI storage kullanarak daha düşük maliyetli failover cluster senaryolarını nasıl oluşturabiliriz ve kurduğumuz bu yapıyı nasıl makismum performans ile kullanabilirize bakacağız. Ayrıca bu makale size Hyper-V tarafındaki failover cluster mantığını öğretecek ve aynı konfigürasyonları fiber channel storage’ler ile de gerçekleştirebileceksiniz.

 

Tekrar hatırlatmakta fayda görüyorum. Özellikle yüksek performans ihtiyacı olan sanallaştırma ortamlarda ve mission-critical rollerin barındığı sunucularda Fiber Channel Storageler kullanmak performans ve güvenilirlik açısından daha doğru bir karar olacaktır. Bu makalede ele alacağımız software tabanlı iSCSI storage’leri production ortamlarda kullanırken dikkatli olmanızı, testlerini iyi yaparak beklentilerinizi karşılayıp karşılamadığını analiz etmenizi ve kesinlikle best practice yöntemlerine uymanızı öneriyorum.

 

iSCSI arabirimine sahip bir storage, appliance yani donanımsal ürünler olabileceği gibi software yani yazılımsal ürünler de olabilir. Belki software de bir donanım üzerinde çalışıyor ama burada takılmamız gereken nokta bu değil 

 

Software temelli storageler genelde bir işletim sistemi üzerine kurulan tool’lar sayesinde çalışır ve zemindeki işletim sistemine bağımlıdır. İşletim sisteminin çalıştığı server üzerindeki fiziksel diskleri ve ya bu diskler üzerinde yaratılan birimleri iscsi protokolü ile uzak kullanıcıların hizmetine sunarlar.

 

Örneğin Windows Storage Server, üzerindeki iSCSI Software Target sayesinde local disk üzerindeki birimleri (ör: VHD) network üzerindeki sistemlerin kullanımına sunabilmektedir. Openfiler gibi opensource uygulamalarda aynı işi rahatlıkla yapabilirler.

 

Amacımız Hyper-V tarafındaki failover cluster yapısını incelemek ve düşük maliyetli bir çözüm üretmek olduğu için biz bu makalede iSCSI Storage olarak Windows Server 2003 Standard Ed. Üzerinde çalışan Microsoft iSCSI Software Target yazılımını kullanacağız.

 

 

4. Örnek Topoloji ve Temel Gereksinimler

 

iSCSI Software Storage kullanacağımız failover cluster yapısı için oluşturacağımız topology’i ve server’ların konumunu görelim.

 

 

 

Diagramı inceledikten sonra Topology’i biraz açalım ve nelere ihtiyacımız olduğuna bakalım.

 

Gördüğünüz gibi arka planda çalışan bir storage var (iSCSI Software Target) ve söylediğimiz gibi bu hizmeti Windows Server 2003 STD üzerinde çalışan Microsoft iSCSI Software Target yazılımı veriyor. VM’ler bu storage üzerinde duruyor olacak.

 

VM’lerin çalışacağı iki fiziksel Node var. Hyper-V Node1 ve Hyper-V Node2. Bu iki Node üzerinde Windows Server 2008 Enterprise Edition 64bit işletim sistemi çalışıyor. Biliyorsunuz sadece Enterprise ve Datacenter sürümler Cluster destekler (Ayrıcı HPC).

 

Her iki node üzerinde 3’er adet fiziksel NIC var. Doğru ve performanslı bir iSCSI cluster yapısı için bu NIC’ler gerekli.

 

1nci NIC: Public network’e bakıyor yani kullanıcıların ve diğer server’ların birbiri ile konuştuğu, domain iletişiminin gerçekleştiği network.

 

2nci NIC: Heartbeat network’e bakıyor. Bu network, cluster üyesi iki Node’un birbirlerini yokladığı, ayakta olup olmadıklarını (up) kontrol ettikleri network olacak ve diğer networklerden bağımsız olacak.

 

3ncü NIC: iSCSI network’e bakıyor. Bu network üzerinde sadece ve sadece iSCSI trafiği akacak ve birer NIC bu işi için dedicate edilmiş olacak.

 

Ayrıca Node’lar Hyper-V çalıştıracak 🙂 Yani 64bit ve hardware virtualization destekli processor’ler şart.

 

Yapımızda bir Domain Controller yani active directory domain’i ve DNS olmak zorunda. Cluster için domain ortamı şart.

 

Topology deki ihtiyaçları maddeler halinde toparlarsak:

 

Storage:

– Windows Server 2003 STD Ed.

– Microsoft iSCSI Software Target

– En az iki yada daha fazla sayıda NIC (1gbps tavsiye edilir)

– İhtiyaç kadar fiziksel disk alanı

– Domain üyeliği

 

Hyper-V Node’lar:

– Hyper-V uyumlu donanım ve processor

– Windows Server 2008 Enterprise Edition 64bit

– Hyper-V’nin RTM olmasını sağlayan KB950050 paketi yüklenmiş olmalı (Windows server 2008 SP1 için).

– SP2 önerilir. (Her iki node üzerindeki SP durumu aynı olmalı)

– En az 3 adet fiziksel NIC (performans için tavsiye edilir)

– Domain üyeliği

– iSCSI initiator (Win2008 içerisinde geliyor)

– Storage üzerinden atanmış disk birimleri (Quorum ve VM’ler için)

 

Domain Controller:

– Windows Server 2008 (2003te olabilir)

– AD Domain Services ve DNS rolleri

 

Network:

– 1nci network: 192.168.5.x – 255.255.255.0 (public network)

– 2nci network: 11.1.1.x – 255.0.0.0 (heartbeat network)

– 3ncü network: 192.168.10.x – 255.255.255.0 (iSCSI network)

 

Topology’nin domain ortamına oturtulmuş ve ip’lendirilmiş hali aşağıdaki gibidir. Ayrıntıya girdiğim için ilk bakışta karışık görünebilir ama dikkatli incelerseniz kolayca anlayabildiğinizi göreceksiniz.

 

 

Teorik bilgiler bu kadar.

 

Bölüm-2 de iSCSI Software Storage yapılandırması ile devam ediyoruz.

 

 

Serhat AKINCI – IT Pro.