Windows Server Alt Sürümünden Üst Sürümü Geçiş

Bu makalede winsows sunucularında alt sürümden üst sürüme geçerken nelere dikkat edilmesi gerektiğini detaylı bir şekilde görmüş olacağız.

Uzun vadeli ve sağlıklı bir Failover Cluster için tüm node’ların aynı Windows sürümüne sahip olması şarttır. Ancak bu durumun tek bir istisnası vardır: Cluster OS Rolling Upgrade.

İşte bilmen gereken kritik detaylar:

Windows Server 2016’dan beri hayatımızda olan bu özellik sayesinde, mevcut bir Cluster’ı bozmadan yeni sürüme geçirebilirsiniz. Örneğin:

• Elinizde 2 adet Windows Server 2019 node var.
• Bunlardan birini silip Windows Server 2022 kurup tekrar cluster’a dahil edebilirsiniz.
• Bu süreçte cluster “Mixed Mode” (Karma Mod) dediğimiz yapıda çalışır.

Neden Kalıcı Olarak Kullanılamaz:

• Microsoft, “Mixed Mode” yapısını sadece yükseltme (upgrade) süresince geçici olarak destekler.
• Cluster, en düşük sürümdeki node’un yeteneklerine göre çalışır. Yani 2022’in yeni özelliklerini kullanamazsınız.
• Tüm node’ları 2022 yapana kadar kümenin versiyonunu yükseltemezsiniz.
• Farklı kernel yapıları ve driver farklılıkları beklenmedik kilitlenmelere (failover hatalarına) yol açar.

Sürüm Farkı Kuralları

• Biri Standard diğeri Datacenter edisyonu olamaz. İkisi de aynı olmalıdır.
• Node’ların işletim sistemi dilleri (örneğin biri Türkçe, diğeri İngilizce) aynı olmalıdır.

Eğer amacın eski sunucuyu yenisiyle değiştirmekse (Upgrade), bu farka izin verilir. Ancak “biri 2019 kalsın, diğeri 2022 olsun, böylece yıllarca çalışsınlar” derseniz, sisteminiz hem Microsoft tarafından desteklenmez hem de ilk ciddi yük altında hata verir.

Microsoft’un kuralı nettir: Cluster içinde versiyon farkı en fazla n+1 olabilir.

• Geçerli: Windows Server 2019 ve Windows Server 2022 aynı cluster’da (geçici olarak) bulunabilir.
• Geçersiz: Windows Server 2016 ve Windows Server 2025 aynı cluster’da bulunamaz (arada çok fazla versiyon farkı var).

Kritik Not: Bu “karma mod” (Mixed Mode) sadece yükseltme süreci için tasarlanmıştır. Tüm node’lar aynı sürüme geçene kadar cluster’ın yeni özelliklerini kullanamazsın.

Adım Adım Rolling Upgrade (2019 -> 2022)

Eğer 2 node’lu bir yapın varsa şu sırayı takip etmelisiniz:

Adım 1: Tahliye (Pause & Drain)

İlk node üzerindeki tüm rolleri (sanal makineler veya SQL servisleri) diğer node’a taşıyın ve sunucuyu bakıma alın.

• Failover Cluster Manager > Nodes > Sağ Tık (Node 1) > Pause > Drain Roles.

Adım 2: İşletim Sistemi Kurulumu

Node 1’i cluster’dan çıkarın (Evict) ve üzerine Windows Server 2022 Clean Install (Sıfır kurulum) yapın. Yükseltme (In-place upgrade) yerine temiz kurulum her zaman daha sağlıklıdır.

Adım 3: Node’u Geri Ekleme

Yeni kurulan Windows Server 2022 node’una “Failover Clustering” özelliğini kurulduktan sonra mevcut 2019 cluster’ına dahil edilir.

• Şu an cluster “Mixed Mode” çalışıyor.

Adım 4: Roller’i Geri Taşıma

Cluster’ı yeni kurduğunuz 2022 node’una taşıyın. Şimdi aynı işlemi diğer 2019 node’u için (Adım 1-3 arası) tekrarlayın.

Adım 5: Cluster Functional Level Yükseltme

Her iki node da artık Windows Server 2022 olduğunda, cluster hala 2019 modunda çalışmaya devam eder. Bunu kalıcı olarak 2022’ye çekmek için PowerShell’i yönetici olarak açıp şu komutu çalıştırın:

Update-ClusterFunctionalLevel

Bu komuttan sonra artık cluster’a tekrar bir Windows Server 2019 node ekleyemezsiniz. Geri dönüşü yoktur.

Dikkat Etmen Gerekenler

• Yedekleme: İşleme başlamadan önce mutlaka Cluster konfigürasyonunun ve verilerinin yedeğini alın.
• Active Directory: Domain Functional Level’ın güncel olduğundan emin olun (Genelde sorun olmaz ama kontrol etmekte fayda var).
• Donanım Driver’ları: Sunucu donanımınızın (Dell, HP, Lenovo vb.) Windows Server 2022 sürücülerini desteklediğini kontrol edin.

Canlı bir sistemde (Production) bu işlemi yapacak olman, hata payını sıfıra indirmeyi gerektiriyor. Cluster konfigürasyonunun yedeğini almak, aslında tek bir dosyayı kopyalamaktan biraz daha karmaşıktır çünkü bu veri hem Active Directory üzerinde hem de her bir Node’un Registry kayıtlarında tutulur.

PowerShell ile Konfigürasyon Çıktısı Almak

Olası bir felaket anında (Cluster tamamen çökerse), hangi ayarların olduğunu bilmek hayat kurtarır. Mevcut yapının “röntgenini” şu komutla çekebilirsin:

Get-ClusterResource | Select-Object Name, ResourceType, OwnerGroup, State > C:\Backup\Cluster_Resources.txt
Get-ClusterNetwork >> C:\Backup\Cluster_Resources.txt
Get-ClusterQuorum >> C:\Backup\Cluster_Resources.txt

Bu komutlar sana hangi diskin hangi grupta olduğunu, IP adreslerini ve Quorum yapısını metin olarak verir.

Cluster servisi çalışırken C:\Windows\Cluster\CLUSDB dosyası kilitlidir. Ancak manuel bir kopya almak istersen:

• Checkpoint-Cluster komutunu kullanarak cluster kayıtlarının güncel bir kopyasını oluşturabilirsin.

Canlı sistemde risk almamak için şu 3 noktayı mutlaka kontrol et:

A. Quorum (Çoğunluk) Yapısını Kontrol Et

Yükseltme sırasında node’lardan birini kapatacağın için Cluster’ın “ayakta kalma” oyu düşecektir.

• Eğer 2 node’lu bir yapın varsa, mutlaka bir Witness (Disk veya File Share) yapılandırılmış olmalıdır. Aksi takdirde bir node’u kapattığın an tüm sistem (ve diğer node) çöker.

En hızlı ve en detaylı kontrol yöntemi PowerShell’dir. Yönetici olarak şu komutu çalıştırın:

Get-ClusterQuorum

B. SQL Server / Hyper-V Uyumluluğu

Eğer üzerinde SQL Server varsa, SQL’in Windows Server 2022 üzerinde çalışıp çalışmadığını kontrol etmelisin.

• SQL Server 2012, Windows Server 2022 üzerinde resmi olarak desteklenmez. Bu durumda OS yükseltmesi yaparsan servislerin başlamayabilir.

C. Önce “Passive” Node’dan Başla

Her zaman aktif yükü (rolleri) üzerinde tutmayan, boşta bekleyen node ile işe başla. Rollere sahip olan “Active” node en son güncellenmelidir.

Yükseltme yaparken bir sunucuyu devreden çıkaracağınız için oy dengesi bozulacaktır. Güvenli bir geçiş için şu kurallara uyun:

• 2 Node’lu Yapı: Mutlaka bir Witness (Disk veya File Share) olmalıdır. Eğer yoksa, bir sunucuyu kapattığınızda diğer sunucu “tek başıma çoğunluk sağlayamam” diyerek servisleri durdurur.
• 3 veya Daha Fazla Node: Eğer tek sayıda node varsa (3, 5 vb.), teorik olarak witness olmadan da bir node’u kapatabilirsiniz. Ancak yine de bir Witness olması her zaman daha güvenlidir.

Yükseltme sırasında “File Share Witness” kullanıyorsanız, bu paylaşımın bulunduğu sunucunun kesinlikle kapanmaması gerekir. Eğer şahit disk veya klasör ulaşılamaz hale gelirse ve siz de bir node’u bakıma alırsanız, cluster “Split-Brain” riskine karşı kendini kapatacaktır.

Başka bir makalede görüşmek dileğiyle..

“Gurura kapılarak insanlara burun kıvırma, ortalıkta çalım satarak yürüme; unutma ki Allah gurura kapılıp kendini beğenen hiç kimseyi sevmez.”Lokman-18