Windows Server 2012 R2'de Hyper-V Failover Cluster Kurulumu

Windows Server 2012 R2 ile birlikte gelen Hyper-V rolü ve Failover Cluster özelliği, sanallaştırma altyapılarını daha esnek, daha yüksek erişilebilirlik sağlayacak şekilde yapılandırmak isteyenler için oldukça gelişmiş seçenekler sunuyor. Özellikle fiziksel donanım arızalarına karşı hizmet sürekliliği sağlamak ve sanal makinelerin kesintisiz çalışmasını garanti altına almak isteyenler için Failover Cluster mimarisi, yapılandırmasıyla birlikte derinlemesine anlaşılması gereken bir teknoloji haline geliyor.

Geleneksel yapıların sınırlarına takılan sistemlerde, donanım ya da yazılım tabanlı bir aksaklık anında sanal makinelerin manuel müdahale olmadan farklı bir fiziksel host üzerinde otomatik olarak devam etmesi, iş sürekliliği açısından oldukça önemli bir fark yaratıyor. Hyper-V ile entegre çalışan bu mimari sayesinde, yalnızca sanal makinelerin değil, aynı zamanda SQL Server, File Server gibi Cluster-Aware uygulamaların da yüksek erişilebilirliği sağlanabiliyor.

Kurulum sürecinde karşılaşılan IP yapılandırmaları, Storage bağlamaları, Network trafiğinin yönetimi gibi detaylar göz ardı edildiğinde, Failover Cluster yapısının stabil çalışmaması kaçınılmaz hale geliyor. Bu yüzden yalnızca rol eklemekle yetinmeyip, Cluster Validation gibi adımlarla altyapının uyumluluğunu test etmek, ileride oluşabilecek senaryoların önüne geçmek açısından büyük bir önem taşıyor. Bu süreçte kullanılan Shared Storage mimarisi ve Cluster Shared Volumes (CSV) yapılandırmaları da dikkatli yönetilmesi gereken adımlar arasında.

Active Directory ortamıyla tam entegre çalışan bu yapı, DNS kayıtlarından, Cluster Name Object (CNO) oluşturulmasına kadar bir dizi adıma bağlı kalıyor. Cluster kurulumunun tamamlanabilmesi için gerekli olan tüm servislerin doğru şekilde çalıştığından emin olmak gerekiyor. Aksi durumda, yalnızca bir Cluster kurulmuş olur ama olası bir Failover durumunda beklenen davranışı göstermeyen bir yapı elde edilir. Ayrıca Quorum ayarlarının ortamın topolojisine uygun şekilde belirlenmesi, seçim algoritmalarının doğru çalışabilmesi açısından yapılandırmanın omurgasını oluşturuyor.

İşin püf noktası, bu yapının sadece birkaç sihirbaz ekranıyla kurulabilecek kadar yüzeysel olmadığını anlamakta yatıyor. Her adımın ardında, sistemin davranışlarını şekillendiren mekanizmalar yer alıyor. Bu mekanizmaların nasıl çalıştığını bilmeden yapılan her işlem, ileride daha büyük karmaşaların habercisi olabilir. Sanal makinelerin taşınabilirliği (Live Migration), depolama senaryolarında karşılaşılan erişim problemleri ve Cluster üzerindeki bakım senaryoları, tüm bu bileşenlerin birbiriyle kusursuz şekilde entegre edilmesini zorunlu kılıyor.

Anlatılacak çok fazla detay, dikkat edilmesi gereken sayısız teknik unsur var. Ama en önemlisi, bu yapıyı kurarken sadece başarıyla kurulmuş olmasını değil, olası bir sorun anında nasıl davranacağını da önceden test ederek öğrenmek gerekiyor. Çünkü gerçek anlamda çalışan bir Failover Cluster, yalnızca kurulmuş bir yapı değil, doğru test edilmiş, senaryolarla doğrulanmış ve gerektiğinde müdahale edilebilir bir yapı demek.

Ön Hazırlıklar

Kurulum ve yapılandırmaya geçmeden önce senaryomda kullanacağım yapı ile ilgili bilgi vermek istiyorum.

⚡SRVDC001

firatboyan.com Domain adı altında Active Directory Domain yapımın kurulu olduğu ve bu Server üzerinde File and Storage Service üzerinde iSCSI Target servisini yapılandırarak Failover Cluster Quorum alanı ve Cluster Volume yapılandırmasını bu Server üzerinde yapılandıracağız.

➥ Domain: SRVDC001.firatboyan.com
➥ Rol: Domain Controller, Storage (yapımda Storage bulunmadığı için)
➥ Yüklenecek Servisler: Active Directory Domain Services (AD DS), DNS, iSCSI Target
➥ Network:
1. Network Kartı- LAN: 10.10.10.200 /24
2. Network Kartı- iSCSI: 10.10.11.200 /24
3. Network Kartı- VM: 10.10.10.150 /24

⚡SRVNODE1

Senayom gereği bu Server üzerindeki Failover Cluster Manager üzerinde sanal makimalarımı bu Server üzerinde kuracağım.

➥ Domain: SRVNODE1.firatboyan.com
➥ Rol: Domain Member
➥ Yüklenecek Servisler: Hyper-V, Failover Clustering, Multipatch I/O
➥ Network:
1. Network Kartı- LAN: 10.10.10.201 /24
2. Network Kartı- iSCSI: 10.10.11.201 /24
3. Network Kartı- VM: 10.10.10.151 /24

⚡SRVNODE2

Senaryom gereği Failover anında sanal makinaların migration'larını alacak olan sevrerdır. Bu Server üzerindeki Failover Cluster Manager'da hiçbir sanal makina kurulumu yapmayacağım. Sadece ilgili Servisler ve yapılandırmalar kurulacaktır.

➥ Domain: SRVNODE2.firatboyan.com
➥ Rol: Domain Member
➥ Yüklenecek Servisler: Hyper-V, Failover Clustering, Multipatch I/O
➥ Network:
1. Network Kartı- LAN: 10.10.10.202 /24
2. Network Kartı- iSCSI: 10.10.11.202 /24
3. Network Kartı- VM: 10.10.10.152 /24

👉 Yapılandırmak istediğim sistem, kabaca aşağıdaki gibi olacak:

Tüm sanal makinalar SRVNODE1 üzerindeki fiziksel makikada kurulu olacak ve Down durumuna geçmesi halinde SRVNODE2'ye otomatik tetiklenerek taşınması ve sistemin otomatik olarak UP duruma geçmesi sağlanacak.
 

Network Interface Card (NIC) Yapılandırma

Network Interface Card (NIC) yapılandırması, bir Failover Cluster topolojisinde yalnızca bağlantı sağlamakla kalmaz, aynı zamanda sistemin tutarlı ve senkron çalışmasını doğrudan etkileyen bir altyapı bileşeni haline gelir. Özellikle Cluster içi Heartbeat (iletişim), Live Migration ve Storage trafiği gibi farklı veri akışlarının birbirinden izole şekilde yönetilmesi gerektiğinde, her Network Interface Card'ın taşıdığı trafik tipine göre ayrıştırılması işleri oldukça kolaylaştırır.

Tek bir fiziksel NIC üzerinden tüm trafiği geçirmeye çalışmak, Failover senaryolarında bağlantı sorunlarına, paket kayıplarına ya da gereksiz gecikmelere neden olabilir. Bu yüzden SRVNODE1 ve SRVNODE2 gibi Cluster Node'ları üzerinde en az üç ayrı sanal ya da fiziksel NIC tanımlanarak, biri Management, biri Cluster Heartbeat, biri de Storage bağlantısı için yapılandırıldığında sistemin genel davranışı gözle görülür şekilde daha kararlı çalışır hale gelir.

DNS kaydı, Default Gateway ve Subnet gibi temel parametrelerin her bir NIC için ayrı ayrı ve tutarlı şekilde girilmesi önemli. Ayrıca, Live Migration trafiği için belirlenen NIC üzerinde Bandwidth Limit tanımlamak ya da sadece belirli Subnet’lerdeki trafiği kabul etmesini sağlamak gibi ince ayarlar, trafiğin beklenmedik şekilde diğer NIC'lere dağılmasını engeller. Bu noktada yapılan her yanlış yapılandırma, sadece performans değil, aynı zamanda Cluster üyeleri arasındaki güvenilirliği de doğrudan etkiler.

Her şey yerli yerinde gibi görünse bile, Ipconfig ve ROUTE PRINT gibi komutlarla NIC yapılandırmalarının son halini mutlaka kontrol etmek gerekir. Çünkü bazen DHCP'den alınan gereksiz bir IP ya da yanlış yapılandırılmış bir Metric değeri, Live Migration sırasında bağlantıların çakışmasına ya da Storage erişiminde zamanlamalı hatalara sebep olabilir. Uçtan uca tüm yapılandırmanın gözlemlenebilir, yönetilebilir ve gerektiğinde hızlıca müdahale edilebilir olması, buradaki tüm çabanın amacını özetler.

Hyper-V Role, Failover Clustering ve Multipatch I/O Feature Kurulumu

Hyper-V Role, Failover Clustering ve Multipath I/O Feature kurulumları, sadece birkaç Feature eklemekten ibaretmiş gibi görünse de aslında arka planda çok daha fazla detaya dokunan bir süreç. Bu bileşenlerin birlikte çalışabilmesi için hem işletim sisteminin bileşenleri arasında hem de donanım düzeyinde tam bir senkron yakalanması gerekiyor. Her ne kadar kurulum adımları GUI veya PowerShell üzerinden birkaç tıklamayla yapılabilse de, her bileşenin sisteme entegre olduktan sonra kendi içinde tetiklediği servisler, sürücüler ve arka plan işlemleri, tüm yapının kararlılığını doğrudan etkiliyor.

Hyper-V kurulumunun ardından gelen yeniden başlatma gerekliliği, çoğu zaman göz ardı edilse de aslında bu sırada çekirdek seviyede devreye giren bileşenlerin sistemle uyumlanması sağlanıyor. Failover Clustering özelliği ise sadece bir Feature değil, aynı zamanda Active Directory üzerinden kimlik doğrulama, DNS üzerinden kayıt yönetimi ve Cluster Shared Volumes ile Disk erişimi gibi çok katmanlı işlemleri beraberinde getiriyor. Dolayısıyla, Cluster servisini yükleyip geçmek değil, yükledikten sonra onun yapıyla ne şekilde entegre olduğunu gözlemlemek çok daha anlamlı hale geliyor.

Multipath I/O ise çoğu zaman sadece Storage tarafıyla ilgili gibi görülse de, aslında Storage erişim sürekliliğini garanti altına almak için kullanılan en stratejik Feature’lardan biri. Aynı Disk'e birden fazla fiziksel ya da mantıksal yol tanımlanarak olası bağlantı kesintilerinde alternatif yol üzerinden erişimin devam etmesi sağlanıyor. Bu da doğrudan performans, gecikme süresi ve veri sürekliliğiyle ilgili bir konu haline geliyor.

Yüzeysel bakıldığında hepsi ayrı birer kutucuk gibi duran bu bileşenler, aslında arka planda çok daha büyük bir yapbozun parçalarını oluşturuyor. Doğru şekilde kurulduklarında birbirine kenetlenen bu modüller, yapı üzerindeki her hareketin bir diğerini nasıl etkilediğini açıkça gösteriyor. Yapılan her kurulumun sadece başarılı olarak işaretlenmiş olması değil, birbirleriyle olan etkileşimlerinin test edilip anlaşılması da yapı bütünlüğü açısından göz ardı edilmemesi gereken bir nokta.

SRVNODE1 Üzerinde Kurulum İşlemleri

1- Server Manager konsolununda Manage menüsü altında Add roles and Features seçeneğine tıklayarak Add roles and Features Wizard'ı açıyorum.



2- Add Roles and Features Wizard penceresinde NEXT butonuna basarak devam ediyorum.



3- Select Installation Type bölümünde Role-based or Features-based Installation kurulum, standart rol ve özelliklerin kurulumunu yapabileceğimiz bölümdür. Hyper-V rolünün kurulumu yapacağımı için, Role-based or Features-based Installation seçerek NEXT butonuna basarak devam ediyorum.



4- Select destination server bölümünde kurulum hangi Server üzerinde yapılacak ise, ilgili Server'ı seçmemiz gerekiyor. Ben SRVNODE01 üzerinde Hyper-V role kurulumu yapıp, yapılandıracağım için, bu Server'ımı seçiyorum ve NEXT butonuna basarak devam ediyorum.



5- Select server roles bölümünde Hyper-V rolünün kurulumunu gerçekleştireceğimiz için Hyper-V rolünü işaretliyorum.



6- Hyper-V rolünü seçtiğimizde karşımıza Add Roles and Features Wizard penceresi geliyor. Hyper-V rolü ile birlikte Remote Server Administration Tools özelliği içinde bulunan Hyper-V Management Tools özelliği altında bulunan Hyper-V Module for Windows PowerShell, Hyper-V GUI Management Tools özelliklerinin kurulması gerektiğini belirtiyor. Add Features butonuna basıyorum.



7- Hyper-V role, kurulum içi hazır. NEXT butonuna basarak devam ediyorum.



8- Select Features ekranı, sadece birkaç Feature’ı işaretleyip geçilecek bir adım gibi görünse de aslında kuracağın yapının tüm davranış biçimini doğrudan etkileyen, kritik kararların verildiği bir eşik noktası. Hyper-V rolü kendi başına yüklendiğinde sanallaştırma altyapısı için temel işlevleri sağlar ama senin burada yapmak istediğin şey, bu altyapıyı yüksek erişilebilirlik sağlayacak bir yapıya dönüştürmek. Bu yüzden Failover Clustering ve Multipath I/O özelliklerini doğrudan bu aşamada işaretlemek, ileride çıkabilecek konfigürasyon karmaşalarının önüne geçmek için en doğru adımdır.

Yapıyı sadece Hyper-V ile sınırlandırmak, senin bu Cluster senaryosunda hedeflediğin Live Migration, Storage Failover, otomatik servis devri gibi yüksek erişilebilirlik özelliklerini kısıtlar. Bu noktada Failover Clustering özelliğini kurarak, Node'lar arası iletişim, Quorum yapısı ve ortak kaynak yönetimi gibi Cluster altyapısının gerektirdiği tüm sistem bileşenlerinin devreye girmesini sağlıyorsun. Bu yapı olmadan kurulacak bir Hyper-V ortamı, sadece tekil çalışabilen sanal makineler barındırır ve bu da birden fazla fiziksel Node’un senkron çalıştığı senaryolarla uyumlu değildir.

Özellikle dikkat edilmesi gereken diğer bir bileşen ise Multipath I/O özelliği. Bu Feature, iSCSI ya da HBA üzerinden erişilen Storage senaryolarında, aynı LUN’a birden fazla fiziksel ya da mantıksal yol üzerinden erişim sağlanmasına olanak tanır. Böylece herhangi bir yol devre dışı kaldığında, erişim diğer yollar üzerinden devam eder. Gerçek kurumsal yapılarda Storage bağlantıları genellikle HBA adaptörleri ya da Storage’ların kendi üzerindeki iSCSI Target servisleriyle gerçekleştirilir. Ancak senin bu senaryonda olduğu gibi LAB ortamlarında Windows Server işletim sistemi üzerinde iSCSI Target yapılandırılarak bir sanal Storage oluşturulması da mümkün. Bu durumda, veri kaybı ya da yol çakışması yaşamamak için Multipath I/O özelliği mutlaka yüklenmelidir.

Bunun sadece bir laboratuvar ortamı olduğunu göz önünde bulundurmak önemli. Çünkü burada tercih edilen yapılandırmalar, gerçek üretim ortamlarında birebir aynı olmayabilir. Fakat temel yaklaşım değişmez: Cluster mimarisinin stabil çalışması için altyapıyı taşıyacak tüm bileşenlerin doğru sırayla, doğru kombinasyonlarla kurulmuş olması gerekir. Select Features ekranında yapılan her seçim, arka planda hizmetlerin nasıl davranacağını, hangi bileşenlerin nasıl tepki vereceğini belirler. Bu yüzden işin en başında doğru adımlarla ilerlemek, sistemin geri kalan mimarisini çok daha sorunsuz inşa edebilmeni sağlar.



9- Failover Clustering özelliğini seçtiğimizde, Add Roles and Features Wizard penceresi karşımıza geliyor. Failover Clustering özelliği ile birlikte Remote Server Administration Tools özelliği, Failover Clustering Tools ve Failover Clustering Module for Windows PowerShell, Failover Clustering Management Tools özelliklerinin kurulması gerektiğini belirtiliyor. Kuruluma devam etmek için Add Required Features butonuna basarak, Remote Server Administration Tools altındaki bu özelliğinde kurulmasını sağlıyoruz.







10- Hyper-V rolü ile ilgili özet bilgi ekranına göz atarak, Hyper-V rolünün kurulumuna devam etmek için NEXT butonuna basıyorum.



11- Create Virtual Switches bölümü, Hyper-V altyapısı içerisinde sanal makinelerin Network üzerinden nasıl haberleşeceğini belirleyen en temel yapılandırma adımlarından biri. Sanallaştırılmış ortamda fiziksel bir Network kartı üzerinden dış dünya ile bağlantı kurulacaksa ya da sanal makineler kendi aralarında izole bir haberleşme gerçekleştirecekse, tüm bu iletişim trafiğinin yönlendirilmesi bir Virtual Switch aracılığıyla sağlanıyor. Bu da demek oluyor ki burada yapılan seçimler, sanal makinelerin erişim yeteneklerini doğrudan şekillendiriyor.

Hyper-V, Virtual Switch mimarisini External, Internal ve Private olmak üzere 3 temel tipte sunmaktadır.

Eğer sanal makinelerin hem birbiriyle hem de fiziksel Network ile iletişim kurması isteniyorsa External Virtual Switch seçilir ve bu Switch, doğrudan fiziksel bir NIC'e bağlanır. Bu durumda, Hyper-V fiziksel NIC’i sanal bir Switch’e dahil eder ve ilgili NIC, artık doğrudan işletim sistemi tarafından değil, Hyper-V tarafından yönetilir. Bu noktada fiziksel NIC'in Network konfigürasyonlarının değişeceğini ve bu Switch'e bağlanan sanal makinelerin, artık dış dünyaya erişim için bu sanal katmandan geçeceğini unutmamak gerekiyor.

Eğer amaç sadece sanal makinelerin birbiriyle haberleşmesini sağlamak ama dış dünya ile bağlantı kurmasını engellemekse, Private Virtual Switch tercih edilir. Bu Switch, izole bir Network ortamı sağlar ve dış dünyayla bağlantısı olmayan test senaryoları için oldukça kullanışlıdır.

Öte yandan Internal Virtual Switch, hem sanal makineler arasında hem de Host işletim sistemi ile sanal makineler arasında iletişim kurmak isteyen senaryolar için kullanılır. Özellikle bazı LAB ortamlarında, Host üzerinden RDP ya da dosya paylaşımı gibi servislerin test edilmesi planlanıyorsa oldukça işlevseldir.

Virtual Switch yapılandırması, sadece kurulum esnasında değil, kurulum sonrasında da Hyper-V Manager üzerinden yeniden düzenlenebilir. Ancak burada dikkat edilmesi gereken şey, özellikle External Virtual Switch kullanıldığında fiziksel NIC'in kontrolünün Hyper-V’ye devredildiği ve bu süreçte bazı varsayılan ağ bağlantılarının kesilebileceğidir. Yani bir Switch tanımlarken sadece bağlantının kurulması değil, bu bağlantının sistem genelindeki etkisi de hesaba katılmalı.

Her senaryoya uygun tek bir yapılandırma olmadığını unutmadan ilerlemek en doğrusudur. Çünkü bir sunucunun üretim ortamında ihtiyaç duyduğu Network trafiği ile bir test ortamında çalışan sanal makinenin beklentisi aynı değildir. Bu yüzden Virtual Switch yapılandırmasını yaparken her bir Network yolunun ne amaçla kullanılacağını bilmek ve fiziksel altyapıya en uygun mantıksal kurguyu oluşturmak, tüm sanal altyapının verimli çalışabilmesi adına önemli bir adım olur.

Ben, bu adımda herhangi bir Network Adapter seçimi yapmadan Next botonuna basarak devam ediyorum. Bunun sebebi, Virtual Switch yapılandırma işlemimi daha sonra yapacak olmam ve sanal makinalara tanımlayacak olmamdır.

12- Virtual Machine Migration bölümünde söz konusu Host için Shared-Nothing Live Migration (Paylaşımsız Canlı Aktarım) gönderimlerinin kabul edilip edilmeyeceği ile ilgili seçim yapabilirsiniz. Bu seçenekte daha sonra yapılandırılabilir. bu sebeple Virtual Machine Migration konusunda yeteri kadar bilgi sahibi değilseniz, herhangi bir seçim yapmadan devam etmenizi öneririm.



13- Default Stores ekranı, sanallaştırma altyapısının gelecekteki yönetim kolaylığını doğrudan etkileyen ama çoğu zaman gelişi güzel geçilen bölümlerden biri. Burada yapılan seçimler, yalnızca sanal makinelerin kurulum sırasında nereye yazılacağıyla sınırlı kalmaz; aynı zamanda o sanal makinelerin ileride taşınması, yedeklenmesi ya da Failover Cluster ortamında ortak alanda konumlandırılması gibi senaryolarda büyük kolaylık sağlar.

Kurulum aşamasında Hyper-V, sanal Disk'lerin .VHDX formatında kaydedileceği klasörü ve sanal makine yapılandırma dosyalarının tutulacağı dizini varsayılan olarak sunar. Bu dizinler genellikle sistem Disk'i üzerinde yer alır ve LAB ortamları için kısa vadeli kullanımda yeterli görülebilir. Ancak biraz daha ileriye dönük düşünmek gerekiyorsa, özellikle üretim ortamına yakın simülasyonlar yaparken, bu dizinlerin sistem Disk'inden ayrıştırılması büyük önem taşır. Çünkü sistem Disk'i üzerinde yoğun I/O yükü oluşturmak, hem performans düşüklüğüne hem de kontrolsüz alan tüketimine yol açabilir.

Failover Cluster kurulumu sonrasında sanal makinelerin ortak bir alanda konumlanabilmesi için tüm Node'lar tarafından erişilebilir bir dizin altyapısı oluşturmak şart. Bu noktada, Cluster Shared Volume üzerinde yer alacak klasörlerin başlangıçtan itibaren planlı şekilde oluşturulması, ileride manuel taşıma veya yeniden konfigürasyon gibi zahmetli işlemlerin önüne geçer. Özellikle birden fazla sanal makinenin aynı klasörde konumlandırılması gibi alışkanlıklardan uzak durarak, her makine için izole dizinler belirlemek, yönetim tarafında işleri çok daha düzenli hale getirir.

Bu ekranı geçmeden önce yapılandırılacak klasörlerin isimlendirmesi, Disk tipi, yedekleme stratejileri ve olası senkronizasyon ihtiyaçları da düşünülmeli. Bir noktada sanal makineler Snapshot ile yedeklenecekse veya Replication yapılacaksa, varsayılan dizinlerin yeterli alan sunup sunmadığı da göz önünde bulundurulmalı. Ayrıca Volume Shadow Copy veya üçüncü parti Backup yazılımları bu klasörlere erişim sağlayacağı için, bu dizinlerin sistemle nasıl entegre olacağı da netleştirilmiş olmalı.

Kurulum sihirbazı bu aşamada sana iki basit klasör yolu sunuyor olabilir ama asıl mesele o klasörlerin arkasındaki planlama. Sanal makinelerin konumlandırılacağı her alan, aynı zamanda performans, erişilebilirlik ve güvenlik gibi parametrelerin de yönetileceği bir yapı sunar. Bu nedenle bir sonraki adıma geçmeden önce klasörlerin sadece konumu değil, işlevi de net olarak belirlenmiş olmalı.



14- Confirm installation selections bölümünde Install butonuna basarak Hyper-V rol kuruluma başlıyoruz. Hyper-V rol kurulumu tamamlandıktan sonra Server'ı otomatik olarak restart etmek istersek, Restart the destination Server automatically if required seçeneğini işaretlemeliyiz.



15- Installation progress bölümünde Hyper-V rol, Failover Clustering ve Multipatch I/O Feature'larının kurulmaya başladığını görüyoruz.



16- Server'ım Restart olduktan sonra Hyper-V rolü ile birlikte Failover Clustering ve Multipatch I/O Feature'larının başarılı bir şekilde kurulduğunu görüyoruz.

SRVNODE2 Üzerinde Kurulum İşlemleri

SRVNODE01 için yaptımız Hyper-V, Failover Clustering ve Multipatch I/O kurulumlarını SRVNOD02 üzerinde de kurmamız gerekiyor. SRVNODE02 üzerindeki Role ve Feature kurulumları SRVNODE01 üzerinde yaptığımız kurulum ile aynı olduğu için, burada tekrar ekran görüntüsü yansıtmayacağım. Lütfen, SRVNODE01 üzerinde yaptığımız kurulum adımlarını SRVNODE02 üzerinde de uygulayınız.

Virtual Switch (Sanal Switch) Yapılandırma

Hyper-V Manager üzerinden Virtual Switch oluşturmak, sanal makinelerin fiziksel Network altyapısıyla nasıl entegre olacağını tanımlayan en önemli adımlardan biridir. Sanallaştırma altyapısında her bir sanal makinenin dış dünya ile haberleşmesini, başka sanal makinelerle veri alışverişi yapmasını ya da izole bir ortamda yalnızca belirli amaçlar için çalışmasını sağlayan tüm bu bağlantı senaryoları, oluşturulacak Virtual Switch yapılandırmasıyla şekillenir.

Virtual Switch Manager arayüzüne ulaştığında, karşına External, Internal ve Private olmak üzere üç farklı Virtual Switch tipi çıkar. Burada verilecek karar, tamamen senin oluşturacağın sanal altyapının ihtiyaçlarına göre değişir. Eğer sanal makinelerin hem birbiriyle hem de dış Network ile iletişim kurması gerekiyorsa External Switch ile doğrudan fiziksel NIC'e bağlanmak gerekir. Bu adımda fiziksel NIC artık Hyper-V tarafından sanal bir Switch'e entegre edilir ve yönetimi işletim sistemi yerine Hyper-V devralır. Dolayısıyla bu Switch’in yapılandırması sırasında var olan Network bağlantısının kesilmesi mümkündür ve bu da yapılandırma sonrası bağlantının yeniden sağlanmasını gerektirebilir.

Internal Switch oluşturduğunda, sanal makinelerle Host arasında haberleşme sağlanır ama dış dünya ile bağlantı kurulamaz. Bu yapı daha çok Host işletim sistemi ile test, dosya paylaşımı ya da basit hizmet entegrasyonlarını gerçekleştirmek isteyen senaryolarda tercih edilir. Diğer yandan Private Switch yalnızca sanal makineler arasında bir iletişim sağlar, Host dahil hiçbir dış bileşen bu iletişime dahil edilmez. LAB ortamlarında test amaçlı kullanılan, dış etkileşim gerektirmeyen izole senaryolarda bu yapı oldukça kullanışlıdır.

Switch oluşturulurken dikkat edilmesi gereken bir diğer detay da VLAN ID yapılandırmasıdır. Sanal makineleri aynı fiziksel Switch üzerinden geçen trafiğe yönlendirecek olsan bile, VLAN segmentasyonunu tanımlayarak ağ trafiğini daha güvenli ve izole hale getirebilirsin. Bu, özellikle sanal makinelerin farklı servis rollerini üstlendiği durumlarda, Network güvenliği açısından ciddi avantaj sağlar. Ayrıca performans tarafında da her bir Switch’in hangi fiziksel NIC'e bağlı olduğu, Bandwidth sınırlamaları ve trafik önceliklendirmeleri gibi detaylar göz önünde bulundurulmalıdır.

Virtual Switch Manager ile yapılandıracağın her Switch, aslında birer sanal ağ altyapısıdır ve bu altyapının nasıl kurgulandığı, ileride yaşanacak tüm bağlantı ve erişim senaryolarının temelini oluşturur. Birkaç tıklamayla tamamlanan bu işlem, aslında çok daha derin planlama gerektiren bir yapılandırmanın ilk adımıdır.

SRVNODE1 Üzerinde Virtual Switch Yapılandırma

1- Üzerinde Hyper-V rol kurulumunu yaptığım, Host Name'i SRVNODE1 Fiziksel Server'ıma ait Actions bölümü alanında öncelikle Virtual Swtich Manager... kullanarak bir Virtual Switch (Sanal Switch) oluşturacağım. Sanal Switch (Virtual Swtich) oluşturmak için, sol kısımda, Actions altında, Virtual Swtich Manager... seçeneğine tıklıyorum.



1.1- Virtual Switch Manager... tıkladıktan sonra karşıma Virtual Switch Manager for SRVNODE1 penceresi açılıyor. Ben, sanal sunucuların dış Network ile de haberleşmesini istediğim için External Virtual Switch tanımlayacağım. External seçili halde iken Create Virtual Switch butonuna basıyorum ve Sanal Switch (Virtual Swtich) yapımı kuruyorum.



3- Sanal Switch (Virtual Swtich) yapımı oluşturduktan sonra, Virtual Switch Properties altında Sanal Switch (Virtual Swtich) ayarlarımı yapılandıracağım.

3.1- Name metin kutusuna Sanal Switch (Virtual Swtich) için bir isim tanımlıyorum. Hyper-V Replica ve Failover Cluster mimarilerinde çalışacak tüm Hyper-V Host Server'lar üzerinde oluşturulacak Sanal Switch (Virtual Swtich) adının mutlaka aynı olması gerekiyor.

3.2- Connection type alanında External Network seçili iken sanal işletim sistemleri tarafından dış Network'e erişim için kullanılacak ağ kartını seçiyorum. Eğer aynı ağ içerisindeki Hyper-V Host Server'lar birbirleri ile haberleşecekse, Virtual Swtich kurulumu sırasında Private Switch seçip, bu alanda da iç ağ (LAN) ile haberleşecek ağ kartını seçmem gerekiyor.

3.3- Eğer ortamda Switch üzerinde yapılandırılmış bir VLAN numara sistemi varsa, VLAN ID kutucuğunu işaretleyip, numarayı girmeniz gerekmektedir.

3.4- Yapılandırmalarımı bitirdikten sonra Apply butununa basarak konfigürasyon ayarlarımı uyguluyorum ve Sanal Switch (Virtual Swtich) oluşturma sürecini tamamlamış oluyorum. Hyper-V Replica ve Hyper-V Failover Cluster mimarilerinde çalışacak tüm Hyper-V Host Server'lar üzerinde aynı yapılandırmalarda Sanal Switch (Virtual Swtich) oluşturulması gerekmektedir.

SRVNODE2 Üzerinde Virtual Switch Yapılandırma

SRVNODE1 Üzerinde Virtual Switch yapılandırma adımlarının aynısını SRVNODE2 üzerinde de aynı Virtual Switch name ile yapılandırmamız gerekmektedir. İşlem adımları bire bir aynı olduğu için, SRVNODE2 üzerindeki Virtual Switch yapılandırma görsellerini SRVNODE2 için yayınlamayacağım. 

SRVDC001 Üzerinde iSCSI Target Server Kurulum ve Yapılandırması

SRVNOD01 ve SRVNOD02 Server'larım üzerinde Hyper-V, Failover Clustering ve Multipatch I/O özelliklerinin kurulum ve yapılandırmasını tamamladıktan sonra, SRV_DC001 isimli DC Server'ım üzerinde iSCSI Target Server servis kurulum ve yapılandırmasına başlıyorum.

SRVDC001 üzerinde iSCSI Target Server kurulumu yapmak, özellikle LAB ortamlarında fiziksel bir Storage cihazı olmadan ortak Disk ihtiyacını karşılamanın en pratik yollarından biri. Windows Server’ın sunduğu iSCSI Target rolü sayesinde, sanal ya da fiziksel olarak oluşturulmuş VHDX dosyaları farklı sunuculara iSCSI üzerinden paylaştırılabiliyor. Bu da özellikle Hyper-V ile yapılandırılan bir Cluster ortamında, ortak kullanılacak Disk'lerin sanallaştırılması için oldukça esnek bir çözüm sunuyor.

Kurulum adımı oldukça net. Server Manager üzerinden Roles and Features sihirbazı ile iSCSI Target Server rolü seçilip yükleniyor. Yükleme tamamlandıktan sonra File and Storage Services altındaki iSCSI sekmesi, bu servisin yönetileceği arayüz oluyor. Buradan yeni bir iSCSI Virtual Disk oluşturularak, hedef Volume seçiliyor ve Disk dosyası tanımlanıyor. Bu Disk, aslında fiziksel bir Storage gibi davranacak sanal bir yapı ve tüm işlemler VHDX üzerinden yürütülecek.

Disk oluşturulduktan sonra iSCSI Target tanımlanıyor. Bu aşamada Disk'e erişim yetkisi verilecek olan sunucular belirleniyor. Hedef olarak tanımlanan sunucuların iSCSI Qualified Name (IQN) adresleri giriliyor ve sadece bu adres üzerinden erişim sağlanması istenirse, erişim güvenliği açısından ekstra bir katman oluşturulmuş oluyor. Gerekirse CHAP ya da IP tabanlı filtreleme de devreye alınabilir. Bu adımlar yalnızca erişim değil, aynı zamanda yapılandırılan iSCSI trafiğinin güvenli ve stabil çalışması açısından da önemli.

Paylaştırılan bu sanal Disk'ler, daha sonra Hyper-V üzerinde Failover Cluster yapılandırmasına dahil edilecek olan SRVNODE1 ve SRVNODE2 sunucularına iSCSI Initiator aracılığıyla bağlanarak kullanılabilir hale geliyor. Yani SRVDC001 üzerindeki bu yapılandırma, Hyper-V Cluster için ortak Disk mimarisinin merkezini oluşturuyor. Fiziksel Storage yerine bu yöntem tercih edildiğinde, yapılandırmanın özenli yapılması, her bağlantı adımının test edilmesi ve Disk'lerin sürekli erişilebilir olduğunun doğrulanması önemli hale geliyor.

Kurulum tamamlandığında geriye kalan adım, bu Disk'lerin hedef sunucular tarafından doğru şekilde algılanması ve ileride Failover Cluster ortamında kullanılabilecek duruma getirilmesi oluyor. Her ne kadar bu yapı bir LAB ortamında tasarlanmış olsa da, yapılan adımlar gerçek senaryoların birebir ön izlemesi niteliğinde. Yapının nasıl davrandığını gözlemlemek, ileride fiziksel Storage altyapısına geçildiğinde çok daha bilinçli ve kontrollü bir kurgu oluşturmanı kolaylaştırır.

iSCSI-Internet Small Computer System Interface Kurulumu

iSCSI, yani Internet Small Computer System Interface, Storage sistemlerini TCP/IP protokolü üzerinden erişilebilir hale getiren oldukça esnek bir yapı sunar. Geleneksel olarak Storage Area Network mimarisinde kullanılan Fibre Channel altyapısının yerine, daha maliyetsiz ve sade bir yapı sağladığı için sıkça tercih edilir. Bu teknoloji sayesinde fiziksel olarak uzak bir sunucuya bağlı Disk'ler, yerel Diskmiş gibi işletim sistemi tarafından algılanır. Bu da dağıtık ortamlarda merkezi Storage yönetimi sağlamak isteyen yapılar için önemli bir avantaj yaratır.

Temel olarak iki uç bileşen üzerinden çalışır: Initiator ve Target. Initiator, iSCSI oturumunu başlatan taraftır ve genellikle veri erişimi sağlamak isteyen sunucular tarafından kullanılır. Target ise, genellikle fiziksel ya da sanal Disk kaynaklarını ağa sunan Storage tarafını temsil eder. Bu iki bileşen arasında kurulan iletişimde SCSI komutları, IP protokolü üzerinden paketlenip gönderilir. Bu yapı, fiziksel bağlantı kısıtlarını ortadan kaldırarak, aynı altyapı üzerinde birçok sunucunun merkezi Disk'lere erişebilmesine olanak tanır.

iSCSI’nin dikkat çeken özelliklerinden biri de Layer 3 Network'lerde çalışabilmesidir. Yani bir sunucu, aynı Subnet'te olmayan başka bir sunucunun sunduğu iSCSI Target'a sorunsuz bir şekilde bağlanabilir. Bu özellik, özellikle çok lokasyonlu yapılarda Disk kaynaklarının merkezi olarak sunulmasını mümkün kılar. Aynı zamanda VLAN veya IPsec gibi yapılandırmalarla, bu trafiğin güvenliği ve ayrıştırılması da kolayca sağlanabilir. Burada performansı doğrudan etkileyen faktör ise kullanılan Network altyapısıdır. Yüksek I/O trafiği oluşturacak yapılarda mutlaka dedicated bir NIC kullanmak ya da trafiği farklı bir fiziksel yol üzerinden geçirmek gerekir.

Modern işletim sistemlerinin neredeyse tamamı, iSCSI Initiator bileşeniyle birlikte gelir. Bu da konfigürasyon sürecini ciddi oranda kolaylaştırır. Target tarafı ise ister fiziksel bir Storage cihazı, isterse bir Windows Server üzerinde çalışan iSCSI Target Service olabilir. Özellikle LAB ortamlarında fiziksel donanım ihtiyacını ortadan kaldırması, bu teknolojiyi fazlasıyla cazip hale getirir. Kurulumu sonrası yapılan yapılandırmalarla birlikte, veri yolları tanımlanır, güvenlik filtreleri belirlenir ve erişim kuralları set edilir.

Karmaşık görünen ama mantığını kavradığında oldukça sezgisel ilerleyen bu yapı, doğru tasarlandığında hem esnekliği artırır hem de fiziksel altyapıya bağımlılığı azaltır. Kullanım senaryosuna göre planlandığında, iSCSI ile oluşturulmuş sanal Storage altyapısı, çoğu fiziksel çözümden daha verimli sonuçlar bile üretebilir.

Buradaki ortamım Lab ortamı olduğu için, kullanacağım ortak Disk alanını Windows Server 2012 R2 üzerinde ISCSI Target yapılandırması ile yapacağım. Şirket ortamında bu işleme gerek duyulmaz.

1- Server Manager konsolunu açıyorum. Dashboard ekranında File and Storage Service bölümü altından bulunan iSCSI tab'ını seçiyorum.



2- iSCSI bölümünden To install iSCSI Target Server,start Add Roles And Features Wizard'ı tıklayarak iSCSI Target Server servisinin kurulum ve yapılandırmasını başlatıyorum.

3- Select Features ekranında iSCSI Target Server servisi ile birlikte kurulacak olan Features'ları görüyoruz. iSCSI Target Server servisinin kurulumu için herhangi bir Features kurulumuna ihtiyacımız olmadığı için bu ekranda herhangi bir şeçim yapmıyor, NEXT butonuna basarak devam ediyorum.



4- Confirm installation selections ekranında Install butonuna basarak iSCSI Target Server servisinin kuruluma başlıyoruz. iSCSI Target Server servisinin kurulumu tamamlandıktan sonra, gerek duyulursa Server'ımızı otomatik olarak restart etmek istersek, Restart the destination Server automatically if required seçeneğini işaretlememiz gerekmektedir.



5- Installation progress ekranında iSCSI Target Server servisinin kurulduğunu görebiliyoruz.



6- iSCSI Target Server servisinin kurulumu tamamlandı.



7- iSCSI Target Server servisi kurulduktan sonra, iSCSI Targer Server üzerinde Virtual Disk'lerimizi oluşturmak için To create an iSCSI Virtual Disk, start the New iSCSI Virual Disk Wizard'ı tıklayarak iSCSI Target Server üzerinde iSCSI Disk yapılandırma işlemini başlatıyorum.



8- Select iSCSI Virtual Disk location ekranında, Server Name kısmında iSCSI Target Server kurulumu yaptığımız Server'ın adını, Select by Volume seçeneğinde ise, Disk'imiz üzerindeki Volume bilgilerini görüyoruz. Oluşturacak olduğumuz iSCSI Disk, varsayılan olarak \ISCSIVirtualDisk dizini içerisine oluşturulacak.

Eğer istersek, oluşturacağınız Disk ya da Disk'lerin bu dizin dışında başka bir dizin içinde oluşturulması için Type a custom path bölümünden bir dizin belirtebiliriz. Ben, varsayılan olarak gelen ayarlarda herhangi bir değişiklik yapmadan NEXT butonuna basarak devam ediyorum.



9- Specify iSCSI Virtual Disk name ekranında oluşturacağım iSCSI Virtual Disk için Name kısmında bir isim belirtiyorum. Ben, ilk olarak Failover Cluster yapımızın bilgilerinin tutulacağı Quorum alanını oluşturacağım için, Quorum ismini veriyorum. Patch kısmında oluşturulacak olan Quorum.vhd uzantılı Disk'in hangi dizin altinda oluşturulacağını görüyoruz. NEXT butonuna basarak devam ediyorum.



10- iSCSI Virtual Disk Size ekranında oluşturulacağız Virtual Disk’in boyutunu belirleyebiliyoruz. Disk boyutunu MB,GB, ve TB cinsinden belirleyebiliyoruz. Ben Quorum alanı oluşturacağım için, Virtual Disk boyutunu 1 GB olarak belirtiyorum.

Quorum alanı için 1 GB'lık sanal Disk boyutu teknik olarak yeterlidir çünkü bu Disk, yalnızca Cluster konfigürasyonu, durum bilgileri ve küçük Metadata verilerini tutar. Bu alanda uygulama verisi, büyük Log dosyaları ya da yoğun I/O gerektiren içerikler bulunmaz. Quorum Disk, Cluster Node’ları arasında oy çokluğunu belirlemek ve yapının erişilebilirliğini doğrulamak amacıyla kullanılır.

Disk'in içeriğinde tutulan bilgiler Kilobayt (KB) seviyesinde bile olabilir. Yapılandırma verileri, Cluster tanımlayıcıları ve basit güncellemeler dışında bu Disk üzerinde herhangi bir geniş depolama gereksinimi oluşmaz. Bu nedenle 1 GB sabit boyutta bir Fixed size Disk, fazlasıyla yeterli olur. Üstelik gereğinden fazla büyük bir Disk tanımlamak, sadece boş alan tüketimi yaratır ve herhangi bir ek fayda sağlamaz.

Fixed yapı seçildiğinde Disk baştan tamamen tahsis edilir. Bu da Quorum için istenen tutarlılığı destekler çünkü boyutu sabit ve erişim davranışı öngörülebilirdir. Quorum Disk'i için Dynamic ya da Differencing gibi yapılar önerilmez çünkü bu tür Disk'lerin performans veya istikrar açısından Cluster mantığına uygun olmayan durumlar üretme riski vardır.

Disk'in barındırıldığı Volume de önemlidir. Quorum Disk'i yalnızca boyutuyla değil, erişim güvenilirliğiyle de değerlidir. Bu nedenle Cluster Node’larının hepsinden eş zamanlı erişilebilir bir alan üzerinde, örneğin bir iSCSI Target ya da Cluster Shared Volume üzerinden tanımlanmalı ve başka amaçlarla paylaşılmamalıdır.

Fiziksel kaynaklar kısıtlı değilse 1 GB yerine 512 MB da yeterlidir, ancak günümüzde 1 GB hem kabul gören bir standarttır hem de tüm kullanım senaryoları için güvenli bir tampon sağlar. Daha fazlası gereksiz, daha azı ise belirsiz senaryolarda sıkıntı yaratabilir. O yüzden net ve dengeli bir tercih olarak bu değer oldukça uygundur.

Failover Cluster yapımızın bilgisinin tutulacağı Quorum alanı için 1 GB alan yeterli olduğunu belirtmek isterim. NEXT butonuna basarak devam ediyorum.



11- Assign iSCSI Target ekranında, iSCSI Server'ımız için hedef isim ataması gerçekleştiriyoruz. Burada belirleyeceğimiz hedef isim Server'ımızın iSCSI initiator üzerinden Server'ımız üzerindeki Virtual Disk'lere erişimini gerçekleştirebileceklerdir. Existing iSCSI Target seçeneğinde, Server'ımız üzerinde daha önceden herhangi bir Target belirlenmiş ise, o Target’a ait bilgileri görebiliyor, aynı zamanda yine bu Target üzerinden işlem yapabiliyoruz.

Biz, yeni bir iSCSI Target oluşturmak istediğimizde ise, New iSCSI Target seçeneğini seçiyor, NEXT butonuna basarak devam ediyorum.



12- Specify Target name ekranında, oluşturulacak Quorum Target için yeni bir isim belirliyorum.



13- Specify access Servers ekranında, iSCSI bağlantısı için erişim sağlayacak Server'ımızı belirliyorum. Erişim Server'ını belirlemek için Add butonuna basıyorum.



14- Add initiator ID ekranında erişimi gerçekleştirecek olan Server'ı belirliyorum. Enter a value for the selected tpye kısmında iSCSI bağlantısında kullanabileceğimiz değerleri belirliyoruz. Değer olarak, IQN,DNS Name, IP Adress ve MAC Adress gibi değerleri kullanabiliyoruz. Ben, Ip Adress olarak belirliyorum.







14.1- İkinci Server'ımı (SRVNODE2) da aynı şekilde ekliyorum.





15- Enable Authentication ekranında isteğe bağlı olarak, Authentication method'larını belirleyebiliyoruz. Ben herhangi bir yapılandırma yapmıyorum ve NEXT butonuna basarak devam ediyorum.



16- Confirmation ekranında iSCSI Server Server'ımızı oluşturulacak olan Quorum Virtual Disk'imizi ve iSCSI Target'a erişim sağlayacak olan Server'larımızın IP Adresini ve iSCSI Server erişimi sırasında kullanılacak olan kimlik doğrulama methodlarına ait bilgileri görüyoruz. Create butonuna tıklayarak sanal iSCSI Disk'imizi oluşturmaya başlıyorum.



17- Yapılandırmamız başarılı bir şekilde tamamlanıyor.



18- Server Manager bölümüne geri döndüğümüzde, oluşturduğumz ve Quorum adını verdiğimiz iSCSI Virtual Disk'imizin oluşturulduğunu görüyoruz.

iSCSI Virtual Disk Oluşturma

iSCSI Virtual Disk oluşturma işlemi, fiziksel bir Storage donanımı kullanmadan, Network üzerinden erişilebilen sanal Disk alanları tanımlamanı sağlar. Bu yapı, özellikle LAB ortamlarında ya da merkezi Disk sunumu gerektiren senaryolarda fazlasıyla esneklik sunar. Süreç oldukça yalındır ancak atlanan küçük bir adım bile ileride erişim sorunlarına, Disk eşleşme problemlerine ya da performans sıkıntılarına yol açabilir.

İlk olarak Disk barındırılacak Volume seçilir ve bu Volume üzerine bir .VHDX dosyası tanımlanır. Bu dosya, aslında iSCSI istemcilerine fiziksel Disk gibi sunulacak olan sanal Disk görevini görür. Disk ismi, boyutu ve saklanacağı klasör dikkatli belirlenmeli çünkü bu bilgiler hem iSCSI Target hem de bağlanacak Initiator tarafında referans olarak kullanılacaktır. Disk tipi olarak Fixed, Dynamically Expanding ya da Differencing yapılandırmalarından biri tercih edilir ve bu yapılandırma, Disk'in performans, güvenlik ve genişleme kabiliyetini belirler.

Disk oluşturulduktan sonra bir iSCSI Target’a atanır. Bu noktada Disk'in kendi başına hiçbir anlamı yoktur; mutlaka bir hedefe bağlanması gerekir ki dışarıdan erişilebilir hale gelsin. Target ile eşleştirilen Disk, bu yapı üzerinden bağlanacak sunuculara tanıtılır. Hedefe erişim sağlanacak sunucuların IP adresi ya da IQN bilgisi tanımlanarak erişim sınırlandırılır ve sadece tanımlanan kaynakların bağlantı kurmasına izin verilir. Gerekirse CHAP ile kimlik doğrulama ya da IP filtrelemesi gibi ek güvenlik adımları da uygulanabilir.

Bu aşamada yapılandırmanın sağlamlığı, sadece Disk'in oluşturulmasıyla değil, onun ağ üzerindeki erişim davranışıyla da ilgilidir. Çünkü burada yapılan her seçim, ileride Hyper-V Cluster yapısı altında ortak Disk kullanımı gibi karmaşık senaryolarda kendini tekrar gösterecektir. Planlı, ölçülü ve senaryoya uygun ilerlemek, yapı bütünlüğü açısından büyük fark yaratır. Tek seferde düzgün kurgulanan bir sanal Disk altyapısı, onlarca sunucunun sorunsuz çalışmasına olanak tanır.

19- Şimdi Failover Cluster yapımız için sanal Server'larımızın VHDX Disk dosyalarının tutulacağı Cluster Volume için iSCSI Virtual Disk yapılandırmasını yapılandırıyorum. iSCSI bölümünde sağ tıklayarak New iSCSI Virtual Disk seçeneğini seçiyorum.



20- Select iSCSI Virtual Disk location ekranında, Server Name kısmında iSCSI Target Server kurulumunu yaptığımız sunucunun ismi, Select by Volume seçeneğinde ise Disk'imiz üzerindeki Volume bilgilerini görüyoruz. Oluşturacak oldğumuz iSCSI Disk Default olarak \ISCSIVirtualDisk dizini içerisine oluşturulacak.

Eğer dilersek, oluşturacağınız Disk ya da Disk'lerin bu dizin dışında başka bir dizinde içinde oluşturulması için Type a custom path bölümünden bir dizin belirtebiliriz. Ben, varsayılan olarak gelen ayarlarda herhangi bir değişiklik yapmadan NEXT butonuna basarak devam ediyorum.



21- Specify iSCSI virual Disk name ekranında oluşturacağım iSCSI Virtual Disk için Name kısmında bir isim belirtiyoruz. Ben, ClusterVolume alanını oluşturacağım için ClusterVolume adını veriyorum. Patch kısmında oluşturulacak olan ClusterVolume.vhd uzantılı Disk'in hangi dizin altında oluşturulacağını görüyoruz. NEXT butonuna basarak devam ediyorum.

22- Specify iSCSI Virtual Disk Size ekranında oluşturulacak olan Virtual Disk boyutunu belirleyebiliyoruz.

iSCSI Virtual Disk oluşturulurken Disk tipi seçimi yapılır ve bu seçim, performans beklentisi, kullanılacak ortam ve genişleme stratejisine göre doğrudan sistem davranışını etkiler. Bu aşamada karşımıza üç farklı Disk tipi çıkar ve her biri kendi kullanım senaryosuna göre avantaj ya da sınırlamalar sunar. Aşağıda bu seçenekler teknik olarak madde madde açıklanmıştır:

1. Fixed size

✅ Tanımlanan boyutta Disk, oluşturma anında fiziksel alanın tamamına yerleşir.

✅ Disk boyutu sonradan artmaz ya da azalmaz; sabittir.

✅ En yüksek performansı sunar çünkü Disk erişimi sırasında dinamik genişleme yapılmaz.

✅ Disk, ilk oluşturulurken fiziksel Disk'te baştan sona sıfırlarla doldurulur.

✅ Clear the virtual Disk on allocation seçeneği aktif bırakıldığında, daha önce kullanılan alanlardaki veri parçacıkları temizlenir, bu da bilgi sızıntısını engeller.

✅ Yüksek I/O’ya sahip üretim sistemleri için önerilen yapıdır.

👉 Best practice: Disk büyüklüğü, beklenen veri kapasitesinin en az %20–30 fazlası olarak tanımlanmalı; ayrıca Disk'in bulunduğu Volume’de en az %15 boş alan bırakılmalıdır.

2. Dynamically expanding

✅ Disk ilk oluşturulduğunda fiziksel olarak minimum yer kaplar, yalnızca Metadata boyutundadır.

✅ İçine veri yazıldıkça boyutu otomatik olarak büyür.

✅ Depolama alanının daha verimli kullanılmasını sağlar ama performans sabit değildir çünkü Disk zamanla fiziksel olarak parçalanabilir.

✅ Düşük I/O yoğunluğuna sahip senaryolarda veya LAB ortamlarında kullanılabilir.

✅ Gerçek zamanlı Disk genişlemesi nedeniyle ani performans taleplerinde gecikmeler yaşanabilir.

👉 Best practice: Bu Disk tipi kullanıldığında Volume’ün Disk büyümesini karşılayacak şekilde planlanması ve Storage tarafında yeterli alan uyarılarının yapılandırılmış olması gerekir.

3. Differencing

✅ Bu tip, mevcut bir sanal Disk'in üzerine değişiklikleri yazan katman olarak çalışır.

✅ Parent Disk sabit kalır, yapılan tüm değişiklikler fark Disk'i üzerinde tutulur.

✅ Test ortamlarında, değişiklikleri geri alabilmek istenen geçici yapılar için uygundur.

✅ Parent Disk’e bağımlı çalışır, bu nedenle her iki Disk aynı Storage üzerinde olmalıdır.

✅ Üretim ortamı için önerilmez çünkü parent Disk’e olan bağımlılık hem performans hem erişilebilirlik riski taşır.

👉 Best practice: Parent ve differencing Disk’ler aynı fiziksel Volume üzerinde konumlandırılmalı ve dosya bütünlüğü, yedekleme stratejisiyle birlikte düşünülmelidir.

Her bir Disk tipi yalnızca depolama stratejisini değil, aynı zamanda sistemin genel davranışını ve gelecekteki bakım süreçlerini de şekillendirir. Bu yüzden seçim yapılırken sadece anlık ihtiyaç değil, uzun vadeli kullanım ve genişleme planları da dikkate alınmalıdır. Geriye dönüp yapıyı düzeltmek her zaman mümkün olmaz ama baştan doğru planlanmış bir Disk yapısı, her zaman daha az sürprizle ilerler.

Disk boyutunu, MB,GB, ve TB cinsinden belirleyebiliyoruz. Ben, ClusterVolume alanı oluşturacağım için Virtual Disk'in boyutunu 30GB olarak belirtiyor, NEXT butonuna basarak devam ediyorum.



23- Assign iSCSI Target ekranında, iSCSI sunucumuz için hedef isim ataması gerçekleştiriyoruz. Burada belirleyeceğimiz hedef isim Server'larımızın iSCSI Initiator üzerinden sunucumuz üzerindeki Virtual Disk'lere erişimini gerçekleştirebileceklerdir. Existing iSCSI Target seçeneğinde, eğer Server'ımız üzerinde daha önceden herhangi bir Target belirlenmiş ise, o Target’e ailt bilgileri görebiliyoruz ve aynı zamanda yine bu Target üzerinden işlem yapabiliyoruz.

Biz, ClusterVolume alanı için yeni bir iSCSI Target oluşturmak istediğimizde ise, New iSCSI taget seçeneğini seçiyorum ve NEXT diyerek devam ediyorum.



24- Specify Target name ekranında oluşturulacak olan ClusterVolume Target için yeni bir isim belirleyip NEXT butonuna basarak devam ediyorum.



25- Specify access Servers ekranında, iSCSI bağlantısı için erişim sağlayacak sunucularımızı belirliyoruz. Erişim sunucusu belirlemek için Add butonuna tıklıyoruz.

26- Add initiator ID ekranında, erişimi gerçekleştirecek olan Server'ları belirliyoruz. Enter a value for the selected type kısmında iSCSI bağlantısında kullanabileceğimiz değerleri belirliyoruz. IQN,DNS Name, IP Adress ve MAC Adress gibi değerleri kullanabiliriz. Ben, Ip Adress değerini kullanıyorum.





26.1- İkinci Server'ımı (SRVNODE2) da yanı şekilde ekliyorum.





27- Enable Authentication ekranında isteğe bağlı olarak, Authentication Method'larını belirleyebiliriz. Ben, herhangi bir yapılandırma yapmadan NEXT butonuna basarak devam ediyorum.



28- Confirmation ekranında iSCSI Server'ımızı oluşturulacak olan ClusterVolume ismindeki Virtual Disk'imizi (sanal Disk) ve iSCSI Target erişimi gerçekleştirecek Serverlar'ımızın IP adreslerini ve iSCSI Server erişimi sırasında kullanılacak olan kimlik doğrulama methodlarına ait bilgileri görebiliyoruz.

Son aşamada Create butonuna basarak iSCSI Virtual Disk'imizi oluşturmaya başlıyorum.



28.1- View results ekranında yapılandırmamın başladığını görüyorum.



28.2- Yapılandırmamız başarılı bir şekilde tammamlanmıştır. Close butonuna basarak Wizard'ı kaptabiliriz.



29- Server Manager ekranına geri geldiğimizde, oluşturmuş olduğumuz Quorum ve ClusterVolume isimlerindeki iSCSI Virtual Disk'lerimizin oluşturulduğunu görüyoruz.

SRVNODE1 ve SRVNODE2 Üzerinde iSCSI Initiator Yapılandırması

Sıra, SRVDC001 üzerindeki iSCSI Target Server kurulum ve yapılandırmaları bitirdikten sonra oluşturmuş olduğum iSCSI Virtual Disk'lerimi SRVNODE01 ve SRVNODE2 Server'larıma bağlama işlemine geldi.

SRVDC001 üzerinde oluşturulmuş iSCSI Target ve Virtual Disk yapısının SRVNODE1 ile SRVNODE2 üzerindeki iSCSI Initiator bileşeniyle ilişkilendirilmesi, sanal Disk'lerin bu sunucular tarafından fiziksel Disk gibi algılanabilmesi için yapılması gereken en temel adımdır. Bu yapılandırma tamamlandığında, Target tarafında tanımlanmış olan sanal Disk'ler, her iki sunucunun Disk Management konsolunda çevrimdışı bekleyen bir Disk gibi görüntülenir ve ortak kullanıma hazır hale gelir.

iSCSI Initiator, modern Windows Server kurulumlarıyla birlikte gelen yerleşik bir bileşendir ve ilk kez çalıştırıldığında servisi başlatmak için bir onay ister. Buradan sonra, karşı tarafta tanımlanmış Target’ın FQDN ya da IP adresi girilerek hedefe bağlanılır. Discovery işlemi sırasında Target üzerindeki tüm uygun Disk'ler listelenir ve bağlantı kurulması için oturum oluşturulur. Oturumun her yeniden başlatmada otomatik bağlanabilmesi için Enable multi-path ve Add this connection to the list of Favorite Targets gibi seçeneklerin işaretli bırakılması önerilir.

Initiator yapılandırması sırasında bağlantı şeklinin doğrudan IP mi yoksa DNS üzerinden mi kurulduğu da önemlidir. DNS altyapısı sağlıklı değilse bağlantı kurulamaması ya da beklenmedik zamanlarda kopmalar yaşanabilir. Ayrıca aynı Target’a birden fazla yol tanımlanacaksa, Multipath I/O (MPIO) desteğinin önceden yapılandırılmış olması gerekir. Bu durum sadece erişim sürekliliği değil, aynı zamanda performans açısından da fark yaratır.

Yapılandırma tamamlandığında Disk Management ekranından yeni tanınan Disk çevrimiçi yapılır ve Initialize edilerek kullanılmaya hazır hale getirilir. Ancak bu işlem yalnızca bir sunucu üzerinde yapılmalı, diğer sunucuya bu Disk doğrudan erişim için değil, Failover Cluster yapısında ortak erişim sağlamak amacıyla tanıtılmalıdır. Çünkü aynı anda iki sunucu tarafından doğrudan erişilen bir Disk, veri bütünlüğü açısından ciddi sorunlara yol açabilir.

Tüm yapı doğru şekilde tanımlandığında, SRVNODE1 ve SRVNODE2 sunucuları aynı fiziksel Disk'e erişebilen ama bunu kontrollü ve senkronize biçimde yöneten bir mimaride buluşur. Bu da yapılandırmanın yalnızca doğru değil, aynı zamanda sürdürülebilir olmasını sağlar.

SRVNODE1 Üzerinde iSCSI Initiator Yapılandırması

1- iSCSI Initiator'ı çalıştırdıktan sonra, karşıma iSCSI Initiator Properties ekranı çıkıyor. Bu ekranda Quick Connect altında Target bölümünde, iSCSI Target kurulum ve yapılandırmasını gerçekleştirdiğim SRV_DC001 Server'ımın IP Adresini giriyor, Quick Connect butonuna basıyorum.

2- Quick Connect ekranında görüldüğü gibi, iSCSI Target Server üzerinde oluşturmuş olduğum Quorum ve ClusterVolume isimlerindeki Virtual Disk'lerim görüyorum.



2.1- Quorum ve ClusterVolume isimlerindeki iSCSI Virtual Disk'lerimin SRVNODE1 Server'ım üzerindeki bağlantısını sağlamak için sırsıyla her ikisini de seçerek Connect botonuna basıyorum.

2.2- Connect botonuna basarak iSCSI Virtual Disk bağlantılarımı SRVNODE1 Server'ım üzerinde gerçekleştirdikten sonra Done butonuna basarak kapatıyorum.

3- iSCSI Initiator Properties ekranında görüldüğü gibi, iSCSI Virtual Disk bağlantımı SRVNODE1 Server'ım üzerinde gerçekleştirdim.

SRVNODE2 Üzerinde iSCSI Initiator Yapılandırması

iSCSI Virtual Disk bağlantısını SRVNODE1 Server'ım üzerinde yaptığım gibi aynı şekilde yapılandırmam yeterlidir. Bu nedenle aynı adımları tekrar etmeyeceğim.

Virtual Disk'lerin Connection Durumu

SRVNODE1 ve SRVNODE2 üzerinde iSCSI Initiator ile Disk'lerin SRVDC001 Server'ımda yapılandırdığım, ClusterVolume ve Quorum olarak isimlendirdiğim ve oluşturduğum Virtual Disk'lere bağlantının SRVDC001 üzerindeki Server Manager > File and Storage Services > iSCSI altında gerçekleştiğini, bağlantı durumunun da Connected olarak değişmesinden görebiliriz.

Disk Management Üzerinde Disk Yapılandırma

Disk Management üzerinden yapılacak yapılandırma, iSCSI Target'a bağlanan sunucuların bu Disk'i nasıl göreceğini belirler. SRVNODE1 ve SRVNODE2 üzerindeki iSCSI bağlantıları başarıyla kurulduktan sonra, sanal Disk fiziksel bir Disk gibi tanınır fakat varsayılan olarak Offline ve Unknown durumdadır. Bu davranış, Disk'in veri kaybı yaşanmadan ve yanlışlıkla erişime açılmadan önce yönetici onayıyla kullanılmasını sağlamak için tasarlanmıştır.

Disk Management ekranında ilgili Disk satırı sağ tıklanarak önce Online duruma getirilir. Bu işlemden sonra, sistem Disk'in yapısını tanımlayabilir hale gelir ancak henüz kullanıma açık değildir. Sonraki adım Initialize etmektir. Bu aşamada Disk formatı seçimi yapılır ve genellikle GUID Partition Table (GPT) tercih edilir çünkü büyük boyutlu Volume’ler ve modern yapılar için daha uygundur. Master Boot Record (MBR) ise daha eski sistemler ve 2 TB altı senaryolar için sınırlı bir alternatiftir. Aşağıda detaylı teknik içeriklerine göz atalım.

1- GPT (GUID Partition Table)

✅ Her bir Partition için benzersiz bir tanımlayıcı olan GUID (Globally Unique Identifier) kullanır.

✅ 128 adede kadar Partition tanımlanabilir.

✅ 2 TB sınırı yoktur; Disk kapasitesi 256 TB ya da daha fazlaysa kullanılabilir.

✅ UEFI tabanlı sistemlerle çalışmak üzere tasarlanmıştır.

✅ Yedek Partition tablosu içerdiği için MBR’ye kıyasla daha güvenilirdir.

✅ Modern donanımlar, sanallaştırma platformları ve büyük kapasiteli Storage sistemleri ile daha uyumludur.

GPT Ne zaman tercih edilir?

✅ 2 TB’tan büyük Disk'ler kullanılacaksa.

✅ UEFI destekli sunucularda çalışılıyorsa.

✅ Failover Cluster, Hyper-V, SAN veya yüksek kapasiteli Volume yapıları tasarlanıyorsa

2- MBR (Master Boot Record)

✅ Diskin ilk sektörü içerisinde bulunan ve Disk bölümlerinin tanımlandığı eski nesil bir Partition yapısıdır.

✅ En fazla 4 adet Primary Partition tanımlanabilir.

✅ 2 TB’tan büyük Disk'lerde çalışmaz. 2 TB üzerinde kalan alanı göremez ve kullanamaz.

✅ BIOS tabanlı sistemlerle çalışmak üzere tasarlanmıştır.

✅ Eski donanımlarla ya da 32-bit işletim sistemleriyle çalışan yapılarda hala tercih edilebilir.

✅ Basit, uyumlu ve düşük kapasiteli Disk'ler için yeterlidir.

MBR Ne zaman tercih edilir?

✅ 2 TB’tan küçük Disk'ler kullanılacaksa.

✅ BIOS destekli sunucularda çalışılıyorsa. 

✅ Eski işletim sistemi uyumluluğu gerekiyorsa.
 

MBR daha eski ve sınırlı bir yapı sunarken, GPT çok daha esnek, ölçeklenebilir ve modern sistemler için uygundur. Kurulum yapılan ortamın mimarisine, işletim sistemi sürümüne ve Disk boyutuna göre seçim yapılmalıdır. Baştan doğru yapılandırılmazsa, ileride Diski yeniden biçimlendirmek gerekebilir ki bu da veri kaybı anlamına gelir. O yüzden ilk seçim her şeyi belirler.

Disk, Initialize edildikten sonra henüz formatlanmış değildir. Sadece kullanılmaya hazır hale getirilmiştir. Eğer bu Disk, Failover Cluster ortamında ortak kullanılacaksa, bu noktada hiçbir biçimlendirme yapılmamalı, işlem doğrudan Cluster yapılandırmasında devam ettirilmelidir. Aksi halde Disk üzerinde yapılacak bir biçimlendirme, diğer node’ların Disk'i tanımasını ya da erişmesini engelleyebilir.

Bu ekran üzerinde yapılan her tıklama, doğrudan Disk yapısını etkilediği için hızlıca geçilmemeli; her karar yapıdaki diğer sunucularla olan senkronizasyonu da dikkate alacak şekilde verilmelidir. Başta yapılan bu küçük ama anlamlı adımlar, ileride çok daha büyük yapıların temelini taşıyacak olan ortak Disk erişimini mümkün kılar.

SRVNODE1 ve SRVNODE2 Server'ları üzerinde iSCSI Initiator yapılandırmalarımı Storage üzerindeki Disk'e bağlantı yaparak Connected konumuna geçtikten sonra, Disk Management Üzerinden Disk'lerimi yapılandıracağım. Bunun için, SRVNODE1 üzerinde Computer Management konsolunda içinde Disk Management konsolunu açıyorum.

SRVNODE1 Üzerinde Disk Yapılandırma

Disk Management ekranında görüldüğü gibi; Disk'lerimiz Offline ve Unknown durumundalar. Bu Disk'lerimizi sırası ile, Online duruma getirdikten sonra Initialize edeceğiz.



1- ClusterVolume ve Quorum Disk'lerimi Online duruma getiriyorum.





2- Şimdi ise, Initialize Disk seçeneği ile her iki Disk'imi de aktif hale getiriyorum.



2.1- Disk2'yi de aynı şekilde Initialize Disk seçeneği ile Initialize ettikten sonra, Disk1 üzerinde sağ tıklayarak New Simple Volume... seçeneği ile Simple Volume oluşturacağım.



2.1.1- Oluşturacağım Simple Volume için bir isim veriyorum. Simple Volume yapıma ClusterVolume adını veriyorum.



2.1.2- Şimdi de Disk2 üzerinde sağ tıklayarak New Simple Volume... seçeneği ile Simple Volume oluşturacağım.



2.2.3- Oluşturacağım Simple Volume için bir isim veriyorum. Simple Volume yapıma Quorum adını veriyorum.

SRVNODE2 Üzerinde Disk Yapılandırma 

Disk işlemlerini sadece bir sunucu üzerinde yapılandırmamız gerekmektedir. Diğer Server(lar) üzerinde bu işlemi gerçekleştirmeye gerek yoktur. Bu nedenle, SRVNODE1 üzerindeki Disk yapılandırmasını bitirdikten sonra, SRVNODE2 üzerinde Disk'lerimizi sadece Online konumuna almamız yeterli olacaktır.

Failover Cluster Kurulum ve Yapılandırması

Failover Cluster kurulumuna başlarken atılması gereken ilk adım, yapının donanımsal ve yazılımsal olarak Cluster gereksinimlerini karşılayıp karşılamadığını test etmektir. Bu nedenle sihirbaz, Validate Configuration adımıyla başlar. Bu bölümde, Cluster’a dahil edilecek tüm sunucular üzerinde yapılan denetimlerle Network bağlantılarından Storage erişimine, Active Directory kayıtlarından Cluster servis yapılandırmalarına kadar pek çok unsur test edilir. Rapor detaylıdır ve ileride oluşabilecek sorunlara önceden müdahale şansı verir.

Doğrulama tamamlandıktan sonra Create Cluster Wizard ile yapılandırma süreci başlatılır. Bu aşamada hangi sunucuların Cluster’a dahil edileceği belirlenir. Cluster adı ve IP adresi tanımlanarak, yapının DNS üzerinde kayıt işlemi yapılır. Bu ad, ileride sanal makinelerin yüksek erişilebilirlik senaryolarında kullanılacağı servis noktası olacağı için dikkatle seçilmelidir. Ek olarak Cluster Name Object (CNO) otomatik olarak oluşturulur ve bu nesnenin Active Directory üzerinde yazma yetkisi olduğundan emin olunması gerekir.

Kurulum tamamlandığında, Failover Cluster yapısı teknik olarak hazır hale gelir fakat yapı henüz kaynak içermediğinden, sanal makineler ya da servislerin yüksek erişilebilirlik kapsamında taşınmasına başlamaz. Ortak Storage, Quorum yapılandırması ve varsa Cluster Shared Volumes gibi ek adımlar yapılandırılmadıysa bu yapı, sadece ismen Cluster olarak kalır. Bu yüzden kurulum adımı sadece bir başlangıç noktasıdır; yapı tam anlamıyla hayata geçirilmeden önce performans, güvenlik ve senkronizasyon açısından birkaç adım daha dikkatlice planlanmalıdır.

Kurgu doğru ilerlediğinde, Failover Cluster sadece yüksek erişilebilirlik değil, aynı zamanda merkezi yönetim, servis geçiş senaryoları ve bakım kolaylığı gibi avantajları da beraberinde getirir. O yüzden bu sihirbaz ekranlarında yapılan her seçim, aslında yapının gelecekteki davranışını sessizce şekillendirir.

1- SRVNODE1 Server üzerinde Failover Cluster Manager konsolu açıp, Management altında bulunan Create Cluster başlığını tıklayarak Failover Cluster yapısını oluşturmaya başlıyoruz.



2- Before You Begin bilgilendirme ekranı karşımıza çıkıyor. NEXT butonuna basarak devam ediyorum.



3- Select Servers ekranında Failover Cluster yapısına dahil edilecek Server'ları Browse butonuna tıklayarak ekliyorum.







4- Validation Warning ekranında Failover Cluster oluşturma sürecine geçmeden önce yapılandırma testlerinin tamamlanıp tamamlanmadığı sorgulanır. Yes seçeneği, sihirbazın seni yeniden Validate a Configuration adımına yönlendirerek detaylı bir donanım ve yapı uyumluluk testi yapmasına olanak tanır. Bu test, Cluster yapısında yer alacak her bir Node’un Network, Storage, Active Directory ve sistem bileşenleri açısından birlikte sorunsuz çalışıp çalışamayacağını analiz eder.

No seçeneği ise, doğrulama testini atlayarak doğrudan Cluster kurulum adımlarına geçmeni sağlar. Ancak bu seçenek yalnızca yapı test ortamında çalıştırılıyorsa veya yapı zaten manuel olarak test edilmişse anlamlıdır. Aksi durumda testin atlanması, ileride karşılaşılacak hatalarda analiz sürecini zorlaştırır. Ayrıca Microsoft Support, yalnızca tüm testleri başarıyla geçmiş Cluster’lar için resmi destek sağlar.

Bu noktada yapılacak tercih, sadece bir adımı geçmek değil, kuracağın yapının sağlamlığına dair karar vermektir. Baştan doğru doğrulanmamış bir yapı, günün birinde seni hiç beklemediğin bir yerde ters köşe bırakabilir.



5- Before You Begin bilgilendirme ekranı karşımıza çıkıyor. NEXT butonuna basarak devam ediyorum.



6- Testing Options ekranında, Failover Cluster yapımız için bütün testleri ya dasistem ile ilgili sizin belirleyeceğimiz testleri çalıştıracağımız kısmı burada belirliyoruz. Ben, yapılandırma esnasında herhangi bir sorunla karşılaşmamak için Run all tests seçeneğini seçerek bütün testleri gerçekleştirmesini istiyorum. Test işlemini başlatmak için NEXT butonuna basarak devam ediyorum.



7- Confirmation ekranında, Failover Cluster yapımız için sunucular üzerinde yapılacak olan bütün testlerin bir listesini veriyor testi başlatmak için NEXT butonuna basarak devam ediyorum.



7.1- Validating ekranında, Failover Cluster yapımız için gerekli testlerin başladığını görüyoruz.





7.2- Summary ekranında, Failover Cluster ortamımız için hazırlanış test raporları görülüyor. Küçük uyarı mesajları dışında herhangi bir sorun olmadığını görüyoruz. View Report butonuna basarak test raporunu ayrıntılı olarak inceleyebilirsiniz.



8- Access Point for Administering the Cluster ekranında, test işlemleri bittikten sonra Failover Cluster yapımız için bir isim ve IP Adresi belirtmemiz gerekiyor.

8.1- Cluster Name bölümüne Failover Cluster yapımız için bir isim veriyorum. Address bölümüne Failover Cluster yapım için iSCSI Network'üne ait bir IP Adresi yazıyor, NEXT butonuna basarak devam ediyorum.

9- Confirmation ekranında, Failover Cluster yapımızın ismini, yapımızda kullanılacak olan Server'larımızın ve yapımızın IP Adresini görüyoruz. NEXT butonuna basarak devam ediyorum.



10- Creating New Cluster ekranında, Failover Cluster yapımızın oluştuğunu görüyoruz.



11- Summary ekranında, Failover Cluster yapımızın sorunsuz bir şekilde oluşturulduğu görüyoruz. Finish butonuna basarak Failover Cluster Wizard ekranını kapatıp, işlemi bitiriyorum.



12- Tekrar Failover Cluster Manager konsolu üzerinden Failover Cluster yapımızla ilgili Roles, Nodes, Storages, Networks ve Cluster Events bölümlerinin geldiğini görebiliyoruz.



13- Nodes bölümünde, Failover Cluster bölüme dahil etmiş olduğumuz sunucularimizin Up olarak geldiğini görüyoruz.



14- Storage altındaki Disks bölümünde Quorum ve ClusterVolume alanlarının Online olarak görüyoruz.

Failover Cluster Üzerinde Virtual Machine Oluşturulması

Failover Cluster yapısı kurulduktan sonra, bu altyapı üzerinde çalışacak ilk Virtual Machine’in oluşturulması, yapının işlerliğini test etmenin en pratik yollarından biri olur. Bu işlem için Failover Cluster Manager konsolunda Roles alanına sağ tıklanarak Virtual Machines > New Virtual Machine adımı izlenir. Açılan sihirbaz, klasik Hyper-V Virtual Machine oluşturma ekranıyla aynıdır, ancak buradaki fark, oluşturulan sanal makinenin doğrudan Cluster kaynaklarına bağlı bir rol olarak yapılandırılmasıdır.

Makine hangi Node üzerinde oluşturulursa oluşturulsun, Cluster bu kaynak üzerinde yüksek erişilebilirlik senaryolarını aktif hale getirir. Yani ilgili Host ulaşılamaz hale geldiğinde, makine diğer Node üzerinden otomatik olarak devreye alınabilir. Buradaki en önemli detaylardan biri, Virtual Machine’in sanal Disk'lerinin mutlaka ortak erişilebilir bir lokasyonda, yani Cluster Shared Volume ya da iSCSI ile tanımlanmış paylaşımlı bir Storage üzerinde olması gerektiğidir. Aksi takdirde sanal makine yalnızca oluşturulduğu Node üzerinde çalışabilir, diğer Node’lar erişim sağlayamaz.

Bu işlemi tamamladığında aslında yalnızca bir sanal makine oluşturmamış olursun; aynı zamanda Cluster kaynakları içinde taşınabilir, izlenebilir, otomatik olarak Failover edilebilir bir sanal altyapı nesnesi tanımlamış olursun. Bundan sonrası, yapının gerçek yükünü taşıyacak olan servisleri bu makine üzerine inşa etmek ve senaryoya uygun geçiş testleriyle devam etmektir. Baştaki bu ilk adım ne kadar sağlıklı ilerlerse, yapının kalan kısmı da o kadar kontrollü büyür.

1- Failover Cluster yapımızı oluşturduktan sonra, Failover Cluster Manager'da Roles alanına sağ tıklayarak Virtual Machines > New Virtual Machine... seçeneğini seçerek yeni bir sanal makina (Virtual Machine) oluşturmamız gerekiyor. 



2- Sana Makianımı hangi Server NODE üzerinde oluşturmak istediğimi seçiyorum. SRVNODE1'i seçiyor, OK butonuna basıyorum.



3- Before You Begin adımında Next butonuna basarak devam ediyorum.



4- Specify Name and Location adımında sanal makinam için bir isim veriyorum. Ben, ClusterVM01 adını veriyorum.



5- Yine Specify Name and Location adımında Store the Virtual machine in different location kutucuğunu seçip, aktif hale getiriyorum. Bu seçeneğin aktif hale gelmesi ile, Cluster yapım için Storage Disk'im üzerinde sanal makina kurulum dosyaları bulunacak.



6- Browse butonuna basarak Storage Disk'imi seçiyorum.



7- Storage Disk'imin içine girdiğimde Disk'imde daha önceden oluşturuğum FiloverClusterVMs klasörünü seçiyorum. Sanal makina kurulum dosyalarım bu klasörde tutulacak.



8- Location, Storage Disk'imdeki FailoverClusterVMs klasörünü gösteriyor.



9- Specify Generation alanında değişiklik yapmadan Next butonuna basarak devam ediyorum.



10- Assign Memory ekranında yapılacak bellek tanımı, sanal makinenin nasıl çalışacağını belirler. Burada girilen Startup Memory değeri, sanal makine açıldığında fiziksel RAM'den rezerve edilecek minimum miktardır. Bu değerin çok düşük olması, işletim sistemi başlatılırken yetersiz kaynak uyarılarına neden olabilir. Aşırı yüksek değer verilmesi durumunda ise fiziksel RAM’in verimsiz kullanılması söz konusu olur.

Use Dynamic Memory for this virtual machine seçeneği aktif hale getirilirse, sanal makine başlangıçta verilen değerle çalışmaya başlar ancak çalışma süresince ihtiyaca göre daha düşük ya da daha yüksek miktarda bellek kullanabilir. Örneğin başlangıç 2048 MB ise, kullanım ihtiyacına göre 512 MB'a kadar düşebilir ya da üst sınıra kadar çıkar. Wizard üzerinde bu üst sınır teknik olarak 1048576 MB (1 TB) olarak tanımlanabilir. Bu seçenek devre dışı bırakıldığında, girilen Startup Memory miktarı sanal makine için rezerve edilir ve sabit kalır. Başlangıçta ne tanımlanmışsa çalışma süresince hep o kadar RAM kullanılır. Böyle bir yapı tercih edildiğinde kaynak tahsisi daha kontrollü ilerler ancak bellek tasarrufu yapılamaz.

Dynamic Memory kullanılacaksa, toplam fiziksel RAM kapasitesi ve üzerinde çalışan diğer sanal makinelerin bellek ihtiyacı dikkate alınarak planlama yapılmalıdır. Platformda bellek çakışmaları oluşmaması için özellikle minimum ve maksimum sınırlar doğru tanımlanmalı ve tek bir sanal makinenin sistemdeki tüm kaynakları tüketmesi engellenmelidir.



11- Configure Networking bölümünde, Connection alanındaki listede, Hyper-V Host üzerinde daha önce oluşturulmuş olan tüm Virtual Network'ler (sanal ağlar) yer alır. Şimdi bir sanal ağ seçebilirsiniz veya bu işi daha sonraya da bırakabilirsiniz. Bu bilgilere dayanarak Configure Networking bölümünde, Connection alanındaki listede, FailoverVirtualSwitch isimli sanal bir Virtual NIC (sanal ağ kartı) seçiyorum.



12- Connect Virtual Hard Disk adımında, sanal makinenin hangi sanal Disk dosyasını kullanacağı belirlenir. Varsayılan olarak Create a virtual hard Disk seçeneği işaretlidir. Bu seçenek aktif olduğunda, sihirbaz yeni bir .VHDX dosyası oluşturur ve dinamik olarak büyüyen bir yapı kullanır. Dosya ismi, Name alanında tanımlanır. Örneğin burada ClusterVM01.vhdx olarak verdim. Bu isim, sanal Disk'in tanımlanabilirliğini kolaylaştırmak adına anlamlı ve yapıdaki diğer makinelerle karışmayacak şekilde seçilmelidir.

1. Create a virtual hard Disk

✅ Yeni bir sanal Disk (.VHDX) oluşturur.

✅ Dinamik olarak büyüyen Disk tipi kullanılır. Yani Disk başlangıçta fiziksel olarak az yer kaplar, veri yazıldıkça büyür.

✅ Performans açısından daha az kararlı olsa da depolama verimliliği sağlar.

✅ Bu seçenek seçiliyken aşağıdaki üç alan doldurulmalıdır:

 a. Name:

 ✔ Oluşturulacak .VHDX dosyasının adını belirler.
 ✔ Örneğin: ClusterVM01.vhdx
 ✔ Ad anlamlı olmalı, sanal makine ile ilişkilendirilebilir olmalıdır.

 b. Location:

 ✔ Sanal Disk dosyasının fiziksel olarak saklanacağı klasördür.
 ✔ Varsayılan dizin C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks\ olarak gelir.
 ✔ Failover Cluster ortamında bu dizin kullanılmamalıdır, çünkü bu dizin yalnızca ilgili fiziksel sunucuya özeldir.
 ✔ Cluster Node’ları tarafından erişilebilecek ortak bir Volume ya da Cluster Shared Volume tercih edilmelidir.

 c. Size:

 ✔ Sanal Disk'in maksimum kapasitesini tanımlar.
 ✔ Varsayılan değer: 20 GB
 ✔ Maksimum desteklenen değer: 64 TB
 ✔ Disk dinamik olarak genişleyeceğinden, gerçek fiziksel alan yalnızca veri yazıldıkça kullanılır.

2. Use an existing virtual hard Disk

✅ Daha önce oluşturulmuş bir .VHD veya .VHDX dosyasını bu sanal makineye bağlamanı sağlar.

✅ Bu yöntem genellikle klonlama, yedekten geri dönme ya da taşınan makineleri yeniden bağlama amaçlı kullanılır.

✅ Dosya yolu manuel olarak gösterilmelidir.

✅ Disk'e erişimin kesintisiz olması için path mutlaka sabit ve erişilebilir bir lokasyon olmalıdır.

3. Attach a virtual hard Disk later

✅ Bu adımı atlar ve sanal makineyi Disk'siz olarak oluşturur.

✅ Genellikle Disk daha sonra manuel olarak eklenecekse tercih edilir.

✅ Bu seçenekle oluşturulan sanal makineye işletim sistemi kurulamaz; sadece yapılandırma veya test amacıyla anlamlıdır.

✅ Disk eklenmeden sanal makine başlatılamaz.

Her seçeneğin, altyapı planlamasına göre farklı sonuçları olur. Cluster, taşınabilirlik, yedekleme ve performans gereksinimleri netleştirilmeden seçim yapılmamalıdır. Yapı doğru kurulduğunda sorun çıkarmaz, ama yüzeysel seçimler en basit adımda bile darboğaz yaratır.





12.1- Storage Disk'imin içine girdiğimde Disk'imde daha önceden oluşturuğum FiloverClusterDisks klasörünü seçiyorum. Sanal makina Disk'im bu klasörde tutulacak.



12.2- Location, Storage Disk'imdeki FiloverClusterDisks klasörünü gösteriyor.



12.3- Use an existing Virtual hard Disk seçeneği ile daha önce oluşturduğunuz bir Disk'i tercih edebilirsiniz. Örneğin bir Fixed Size veya içinde bir işletim sistemi imajı olan bootable bir VHDX gibi.

12.4- Attach a Virtual hard Disk later seçeneği, Disk ekleme işlemini sanal makine oluşturulduktan sonra da gerçekleştirme olanağı sunar.

12.5- Installation Options alanında, Install an operating System from a boot CD/DVD-ROM seçeneği ile Hyper-V Host üzerindeki bir optik sürücüyü veya erişilebilen bir ISO kurulum dosyasını gösterebiliriz. Ben, Install an operating System from a boot CD/DVD-ROM seçeneğini seçiyorum.

12.6- Image file (.iso) yolu olarak Storage Disk'imin içinde ISO ismindeki klasörümü gösteriyorum.



12.7- Yapılan tanımların gösterildiği özet ekranında bir problem varsa geri dönüpdeğiştirilebilir. Problem yoksa, Finish butonuna basarak sanal makine oluşturma işlemini tamamlayabiliriz. Finish butonuna basarak işlemi sonlandırıyorum.



12.8- Summary ekranında sanal makinamın başarılı bir şekilde kurulduğu bilgisini alıyorum. Kurulumu bitirdiğime göre Finish butonuna basarak Wizard'ı kapatabilirim.



12.9- Kurulum bittikten sonra sanal makina, Sol bölümde Failover Cluster Manager altındaki Roles içinde yer alıyor olacaktır.



12.10- Sanal makinam üzerinde sağ tıklayarak Connect seçneğini seçiyor, sanal makinama bağlanıyorum.



12.11- Start butonuna basarak sanal makinamı başlattım. Windows Server 2012 R2 kurulum penceresi ile karşılaşıyoruz. Kurulum yapılacak dil, saat ve para birimi ayalarları ile klavye dil seçeneklerini ayarladıktan sonra Next botonuna basarak devam ediyorum.



12.12- Install now botununa basarak kurulumu başlatıyorum.











12.13- Kurulum tamamlandı. Klavyedeki Crtl+Alt+Delete tuşlarına barasarak login penceresine erişiyorum.





12.14- Oturum açtıktan sonra Pencerenin yukarısında ClusterVM01 on SRVNODE1- Virtual Machine Connection kısmına dikkat ederseniz, sanal makinam SRVNODE1 üzerinde çalışmaktadır. Sanal makinam SRVNODE1 üzerinde çalışır durumda iken, test amaçlı iki adet klasör oluşturuyorum.

Bu klasörleri oluşturmamdaki sebep, ileriki adımda SRVNODE1 Server'ımı fişini çektiğimde ve dolayısı ile SRVNODE1 Server'ı Down duruma getirdiğimde bu klasörlerin SRVNODE2'ye taşındığını, yani Migrate olduğu görmek içindir.

SRVNODE1 Server'ı Down Durumuna Getirme

1- Sol bölümde bulunan Failover Cluster Manager altındaki Nodes içinde SRVNODE1 Server'ım üzerinde sağ tıklayarak More Actions altında Stop Cluster Service seçeneğini seçerek SRVNODE1 Server'ımı Down durumuna getiriyorum.



2- SRVNODE1 Server'ım Down durumuna geldi.

SRVNODE2 Server Üzerindeki VM'in Durumu

3- Stop Cluster Service seçeneğini seçerek SRVNODE1 Server'ımı Down durumuna getirdikten sonra, sanal makimanım Sol bölümde Failover Cluster Manager altındaki Roles içinde Up & Running durumda olduğunu görüyorum. SRVNODE1 Server'ım Down durumuna geldiğinde, SRVNODE2 Server'ım Down state durumunu algılayarak migration işletimini yapmak için tetikleme başlattı ve sanal makinamı olduğu gibi taşıdı, yani Migrate etti.



4- Sanal makinam üzerinde sağ tıklarak Connect... seçeneğini seçip, sanal makinama bağlanıyorum. Pencerenin yukarısında daha önceden ClusterVM01 on SRVNODE1- Virtual Machine Connection yazarken bu sefer, Pencerenin yukarısında ClusterVM01 on SRVNODE2- Virtual Machine Connection yazmaktadır. Sanal makinam SRVNODE1 Server'da çalışırken oluştuduğum Folder'larımın da tüm data transferlerinin olduğu gibi SRVNODE2 Server'a taşındığını ve Data'larla birlikte eksiksiz biçimde çalıştığını görüyoruz.





5- Bundan sonraki adımda SRVNODE2 Server'ı Down durumuna getireceğiz ancak öncesinde Sanal makina üzerinde daha önce yaptığımız gibi, Sanal makinam SRVNODE2 üzerinde çalışır durumda iken, mevcut olanlara ek olarak test amaçlı birkaç adet dahaklasör oluşturuyorum.

Bu klasörleri oluşturmamdaki sebep, ileriki adımda SRVNODE2 Server'ı Down duruma getirdiğimde bu klasörlerin SRVNODE1'e mevcuttaki Data'lara ek olarak yeni eklediğim Data'lar ile birlikte taşındığını, yani Migrate olduğu görmek içindir.

SRVNODE2 Server'ı Down Durumuna Getirme

1- Sol bölümde Failover Cluster Manager altındaki Nodes içinde SRVNODE2 Server'ım üzerinde sağ tıklayarak More Actions altında Stop Cluster Service seçeneğini seçerek SRVNODE2 Server'ımı Down durumuna getiriyorum.



2- SRVNODE2 Server'ımı Down durumuna geldi.

SRVNODE1 Server Üzerindeki VM'in Durumu

3- Stop Cluster Service seçeneğini seçerek SRVNODE2 Server'ımı Down durumuna getirdikten sonra, sanal makimanım Sol bölümde Failover Cluster Manager altındaki Roles içinde Up & Running durumda olduğunu görüyorum. SRVNODE2 Server'ım Down durumuna geldiğinde, SRVNODE1 Server'ım Down state durumunu algılayarak migration işletimini yapmak için tetikleme başlattı ve sanal makinamı olduğu gibi taşıdı, yani Migrate etti.



4- Sanal makinam üzerinde sağ tıklarak Connect... seçeneğini seçip, sanal makinama bağlanıyorum. Pencerenin yukarısında daha önceden ClusterVM01 on SRVNODE2- Virtual Machine Connection yazarken bu sefer, Pencerenin yukarısında ClusterVM01 on SRVNODE1- Virtual Machine Connection yazmaktadır. Sanal makinam SRVNODE2 Server'da çalışırken, SRVNODE1 Server'dayken oluştuduğum Folder'lara ek Folder'larımın da tüm data transferlerinin olduğu gibi SRVNODE1 Server'a taşındığını ve Data'larla birlikte eksiksiz biçimde çalıştığını görüyoruz.





Tüm Failover Cluster işlemlerini doğru yapılandırdıysanız, Server'ınız Down durumuna geldiği anda SRVNODE1 üzerindeki VM'iniz, SRVNODE2'ye Migrate olacakır.

Sonuç

Cluster yapılarının doğru planlanması ve kurulum adımlarının eksiksiz tamamlanması, Failover Cluster senaryolarında istenilen yüksek erişilebilirlik beklentisini karşılamanın en sağlam yoludur. Hyper-V Role'ünün düzgün bir şekilde yapılandırılması, Storage altyapısının Cluster Shared Volume mantığına uygun kurgulanması ve Node'lar arasındaki iletişimin tutarlı çalışması, tüm sistemin stabilitesini doğrudan etkiler.

Kurulum sırasında kullanılan Validate Configuration Wizard, genellikle göz ardı edilen ama aslında yapının tutarlılığını baştan test etmek için en önemli araçlardan biridir. Bu adımın atlanmadan tamamlanması, sonraki aşamalarda karşılaşılabilecek senkronizasyon ve quorum problemlerinin önüne geçer.

Failover Cluster Manager üzerinden yapılan testler ve Live Migration senaryoları, ortamın operasyonel yeterliliğini doğrudan gösterir. Ayrıca Cluster Network ayarlarının optimize edilmemesi, zamanla performans sorunları veya beklenmedik kesintilere sebep olabilir. Bu yüzden Management, Cluster ve Live Migration trafiğinin fiziksel olarak ayrıştırılması, network segmentasyonu açısından büyük önem taşır.

Genel yapı incelendiğinde, Windows Server 2012 R2 ile gelen Failover Clustering yetenekleri, Hyper-V sanallaştırma platformunu daha esnek ve dayanıklı hale getiriyor. Ancak asıl farkı yaratan şey, doğru yapılandırılmış bir mimari ile birlikte gelen operational tutarlılıktır. Bu tutarlılık sağlandığında, sistem kendi içinde sorunlara hızlı yanıt verebilen bir yapı haline gelir ve servislerin sürekliliği doğal olarak korunmuş olur.

Faydalı olması dileğiyle...