Merhaba

Bu yazı dizimizde Microsoft SQL Server 2025 Always On Availability Group mimarisinin kurulumunu ve yapılandırmasını detaylı şekilde inceleyecek, High Availability (Yüksek Erişilebilirlik) ve Disaster Recovery (Felaket Kurtarma) senaryolarını örnek bir mimari üzerinden açıklayacak ve üretim ortamları için gerekli tüm ön koşulları ele alacağız.

Yazı dizisi beş bölümden oluşuyor:

Bölüm 1 — Windows Server Failover Cluster (WSFC) Kurulumu (Bu Yazı)
Bölüm 2 — Microsoft SQL Server 2025 Kurulumu
Bölüm 3 — SQL Server 2025 Bileşenleri Rehberi
Bölüm 4 — Always On Ön Hazırlık ve Servis Ayarları
Bölüm 5 — Availability Group Kurulumu ve Failover Testi

Microsoft SQL Server 2025 Always On Availability Group Nedir

Microsoft SQL Server Always On Availability Group, hem High Availability (Yüksek Erişilebilirlik) hem de Disaster Recovery (Felaket Kurtarma) senaryolarını karşılayan kurumsal bir çözümdür. Modern uygulamalarda kesintisiz veritabanı erişimi kritik bir gereksinimdir. Always On mimarisi; Automatic Failover (Otomatik Yük Devretme), Synchronous (Senkron) veya Asynchronous (Asenkron) replikasyon, log aktarım mekanizmaları ve çok replikalı topolojiler ile bu gereksinimi karşılar.

SQL Server Always On’un Temel Amaçları

SQL Server Always On, Microsoft tarafından geliştirilen ve veritabanlarında kesintisiz hizmet sürekliliği sağlamayı amaçlayan bir High Availability ve Disaster Recovery çözümüdür.

Always On’un başlıca hedefleri şunlardır:

• Veritabanlarının 7/24 kesintisiz çalışmasını sağlamak
• Donanım veya yazılım arızalarında otomatik devralma (failover) gerçekleştirmek
• Farklı lokasyonlarda Disaster Recovery senaryoları oluşturmak
• Okuma yükünü secondary replikalara dağıtmak (read scale-out)
• Daha düşük RPO (Recovery Point Objective) ve RTO (Recovery Time Objective) değerleri elde etmek

Microsoft SQL Server 2025 ile Gelen Always On Yenilikleri

Microsoft SQL Server 2025 (17.x), Always On Availability Group mimarisine performans, failover davranışı ve güvenlik alanlarında çeşitli yenilikler getirmiştir. Öne çıkanlar:

Yedekleme (Backup) Yenilikleri

Secondary Replica üzerinde Full ve Differential Backup SQL Server 2025 ile birlikte, secondary replica üzerinde artık yalnızca COPY_ONLY yedek değil, Full ve Differential yedekler de alınabilir. Bu, primary replica üzerindeki yedekleme I/O yükünü azaltarak üretim performansını iyileştirir. Back up on secondary replicas

Failover ve Senkronizasyon Yenilikleri

• Kalıcı sağlık sorunlarında hızlı failover (Fast Failover): Bir Always On Availability Group için RestartThreshold değeri 0 olarak ayarlanabilir. Bu, kalıcı bir sağlık sorunu tespit edildiğinde Windows Server Failover Cluster’ın (WSFC) AG kaynağını yeniden başlatmayı beklemeden anında failover yapmasını sağlar. Fast failover for persistent health issues
• Asenkron sayfa isteği (page request) iyileştirmesi: Failover kurtarma sırasında sayfa istekleri artık asenkron ve toplu (batch) olarak işlenir. Varsayılan olarak etkindir ve failover sonrası kurtarma süresini kısaltır.  Asynchronous page request dispatching improvement
• Commit süresini milisaniye cinsinden ayarlama: availability group commit time değeri artık milisaniye cinsinden yapılandırılabilir. Bu sayede transaction’lar secondary replica’ya daha hızlı gönderilebilir. Configure AG group commit wait in milliseconds
• İyileştirilmiş sağlık kontrolü (health check) zaman aşımı tanılaması Health check timeout tanılamaları iyileştirildi; global primary ve forwarder replica’lar asenkron commit modundayken ağ doygunluğunu azaltarak senkronizasyon performansını artırır. Varsayılan olarak etkindir, yapılandırma gerektirmez. Improved health check timeout diagnostics
• HADR endpoint iletişim akış kontrolü Yeni bir sp_configure seçeneği, primary replica’nın secondary replica’nın geride kalıp kalmadığını belirlemesine olanak tanır ve HADR endpoint’leri arasındaki iletişimi optimize eder. Control communication flow for availability groups (UCS flow control)

Listener ve Routing Yenilikleri

• Listener IP adresini silme (REMOVE) ALTER AVAILABILITY GROUP komutuna eklenen yeni parametre ile, Listener’ı tamamen silmeden yalnızca bir IP adresini kaldırabilirsiniz. REMOVE listener IP address
• Read-only / Read-write routing için NONE ayarı READ_ONLY_ROUTING_URL ve READ_WRITE_ROUTING_URL değerleri NONE olarak ayarlanabilir; bu, tanımlı yönlendirmeyi geri alarak trafiğin otomatik olarak primary replica’ya dönmesini sağlar. Set NONE for read-only/read-write routing

Contained ve Distributed AG Yenilikleri

• Contained AG için Distributed AG desteği Artık iki Contained Availability Group arasında bir Distributed Availability Group yapılandırılabilir. Distributed AG support for a contained AG
• Distributed AG senkronizasyon iyileştirmeleri Global primary ve forwarder replica’lar asenkron commit modundayken ağ doygunluğu azaltılarak senkronizasyon performansı artırıldı. Distributed AG synchronization improvements

Güvenlik Yeniliği

TLS 1.3 ve TDS 8.0 ile şifreli iletişim WSFC ile Always On Availability Group replica’sı arasındaki iletişim artık TLS 1.3 şifrelemesi ve TDS 8.0 desteği ile yapılandırılabilir. Bu, replikalar arası trafiğin en güncel şifreleme standardıyla korunmasını sağlar. Configure TLS 1.3 encryption with TDS 8.0

Failover’da resolving state’e geçiş

Ağ kesintisinde resolving state Ağ servisi kesintisi nedeniyle kalıcı yapılandırma verisi okunamadığında, veritabanının resolving durumuna geçmesine izin verilir — bu, kesinti senaryolarında daha kontrollü bir davranış sağlar. Allow database to switch to resolving state

High Availability (Yüksek Erişilebilirlik) Nedir

High Availability, aynı veri merkezi içerisinde en az iki SQL Server Node’unun Windows Server Failover Cluster (WSFC) üzerinde birlikte çalışmasıyla sağlanır.

Primary Replica (Node) üzerinde bir sorun oluştuğunda:

• Servis otomatik olarak Secondary Replica (Node)’a devredilir
• Kullanıcı tarafında kesinti yaşanmaz
• Senkron çalışma sayesinde veri kaybı oluşmaz

High Availability senaryolarında kullanılan yapılandırma: Synchronous Commit + Automatic Failover

Disaster Recovery (Felaket Kurtarma) Nedir

Disaster Recovery, ana veri merkezinin tamamen devre dışı kalması durumunda verilerin farklı bir coğrafi lokasyondan devam ettirilmesini sağlar.

Yaygın Disaster Recovery Topolojileri:

Kaynak → Hedef	Çalışma Modu	Failover
On-Prem → On-Prem	Asynchronous	Manual
On-Prem → Azure	Asynchronous	Manual
On-Prem → AWS	Asynchronous	Manual

Disaster Recovery senaryolarının temel amacı; veri kaybını minimum seviyede tutmak ve hizmeti mümkün olan en kısa sürede farklı bir lokasyonda devam ettirmektir.

Always On Availability Group Mimarisi

Availability Group (AG), bir veya daha fazla veritabanını kapsayan mantıksal bir High Availability grubudur.

Temel bileşenler:

• Primary Replica (Node)
• Secondary Replica (Node) — Synchronous (Senkron) veya Asynchronous (Asenkron)
• Availability Group Listener — Uygulama bağlantı noktası
• Endpoint / Sertifika Yapısı — Varsayılan TCP 5022

Synchronous (Senkron) ve Asynchronous (Asenkron) Replika Modları
Synchronous Commit (Senkron)

• Commit tamamlanmadan kullanıcıya dönüş yapılmaz
• Veri kaybı sıfırdır
• Automatic Failover desteklenir
• Yoğun transaction ortamlarında latency artabilir

Asynchronous Commit (Asenkron)

• Primary log’u gönderir, sonucu beklemeden commit eder
• Network gecikmesinden etkilenmez
• DR senaryoları için idealdir
• Automatic Failover desteklemez

Failover Türleri

Failover Tipi	Çalışma Modu	Açıklama
Automatic Failover	Synchronous	Kesintisiz geçiş sağlar
Manual Failover	Sync / Async	Yönetici müdahalesi gerekir

Önemli Not: Failover, replika seviyesinde gerçekleşir. Tek bir veritabanındaki sorun failover tetiklemez.

Microsoft SQL Server 2025 Always On Kurulum Ön Koşulları

• Windows Server Failover Cluster (WSFC) kurulmuş olmalı
• Tüm Node’larda aynı SQL Server 2025 sürümü ve patch seviyesi kullanılmalı
• SQL servisleri aynı Domain hesabı ile çalışmalı (veya gMSA)
• Disk yapısı tüm Node’larda birebir aynı olmalı
• AG Listener oluşturabilmek için OU üzerinde Create Computer Objects yetkisi tanımlı olmalı
• Quorum yapılandırması planlanmış olmalı
• Gerekli Firewall portları açık olmalı

Örnek disk yapısı:

• E:\DATA
• F:\LOG
• G:\TEMP
• H:\BACKUP

Örnek Mimari

Bu yazı dizisinde kuracağımız mimari 2 Node’lu Synchronous Commit + Automatic Failover yapısıdır:

• W25DC: Active Directory Domain, DNS ve Quorum için iSCSI Target
• W25SQL25NOD1: Primary Replica (Node) — Synchronous Commit
• W25SQL25NOD2: Secondary Replica (Node) — Synchronous Commit + Automatic Failover

Always On İçin En İyi Uygulamalar

• AlwaysOn Health Extended Events mutlaka aktif olmalı
• Automatic Seeding, orta ölçekli veritabanları için tercih edilmeli
• Read-Intent Routing yapılandırılmalı
• Log transport bant genişliği izlenmeli
• Uygulamalar mutlaka AG Listener üzerinden bağlanmalı
• Quorum için Witness mutlaka yapılandırılmalı

Windows Server Failover Cluster (WSFC) Kurulumu

W25SQL25NOD1 ve W25SQL25NOD2 isimli Windows Server 2025 sunucularımız üzerinde Windows Server Failover Cluster (WSFC) yapısının kurulum ve yapılandırma adımlarına geçiyoruz.

Ön Hazırlık: Active Directory Yetkilendirmesi

🟢 EKLENMESİ GEREKEN BÖLÜM — RESİM ÇEKİLMELİ – burayıkontrolet (Burada adımları açıklamamız gerekiyor. Örneğin nedenl SQL-Clusters olarak bir OU açtık. Computers üzerinde yapmadık. ) Aşağıda sana sorduğum ve cevapladığın yönteme göre açıklama eklenecek )

Cluster henüz kurulmadıysa CNO da henüz yok — dolayısıyla wizard’da CNO’yu seçemezsin zaten. Bu durumda iki geçerli yaklaşım var:

Yaklaşım 1 — Cluster kurulumunu yapan hesabı yetkilendir (senin şu anki ekran görüntülerinin yaptığı şey).
Lab ortamında tek hesap Administrator olduğu için cluster’ı da o kuracak. Windows, cluster’ı kurarken CNO’yu bu OU içinde otomatik oluşturur; bunu yapabilmesi için kurulumu yürüten hesabın (Administrator) OU’da “Create Computer objects” yetkisine sahip olması gerekir. Administrator zaten domain admin olduğu için teknik olarak bu yetkiye zaten sahip — ama makalenin öğretmek istediği mantık “kuran hesaba bu yetkiyi delege et” olduğundan, ekran görüntülerin bu yaklaşımla tutarlı ve geçerli.

Yaklaşım 2 — CNO’yu pre-stage et, sonra CNO’yu yetkilendir.
Cluster kurulmadan önce OU içinde devre dışı bir computer object olarak CNO’yu elle oluşturursun, delegasyonu ona verirsin. Daha production’a uygun ama lab için fazladan adım.

Senin durumun (lab + tek hesap + cluster henüz yok) için Yaklaşım 1 doğru ve ekran görüntülerin uygun. Önceki mesajımdaki “hesabı CNO ile değiştir” uyarısı production senaryosu içindi; senin bağlamında geçerli değil.

Sadece makaleye küçük bir açıklayıcı not eklemeni öneririm ki okuyucu kafası karışmasın:

“Bu lab ortamında cluster kurulumu Administrator hesabıyla yapılacağı için delegasyon bu hesaba verilmiştir. Production ortamında ise en az yetki prensibi gereği, bu yetkinin doğrudan Administrator yerine cluster kurulumunu yürütecek özel bir hizmet hesabına veya güvenlik grubuna verilmesi önerilir. Alternatif olarak CNO pre-stage edilerek yetki doğrudan CNO’ya tanımlanabilir.”

1. Active Directory Users and Computers → ilgili OU üzerinde sağ tık → Delegate Control

 

1. Delegation of Control Wizard → Users or Groups ekranı (Cluster CNO veya yetkilendirilecek hesap)

 

1. Tasks to Delegate → Create a custom task to delegate

1. Active Directory Object Type → Computer objects + Create selected objects in this folder

1. Permissions → Create All Child Objects işaretli hali

 

Alternatif olarak OU → Properties → Security → Advanced üzerinden Create Computer Objects izninin verildiği tek bir ekran da yeterli olabilir.

Firewall Yapılandırması

Port	Protokol	Kullanım Amacı
5022	TCP	Always On Endpoint (replikalar arası log transport)
1433	TCP	SQL Server Database Engine / Listener
1434	UDP	SQL Server Browser (Named Instance kullanılıyorsa)
135	TCP	WSFC — RPC Endpoint Mapper
3343	TCP/UDP	WSFC — Cluster Service (heartbeat)
445	TCP	SMB (File Share Witness kullanılıyorsa)
49152-65535	TCP	WSFC — Dinamik RPC port aralığı

Windows Defender Firewall → Inbound Rules ekranında 5022 portu için oluşturulan kural ekran görüntüsü aşağıdaki gibidir.  – burayıkontrolet (Herhangi bir açıklama yapmak gerekiyormu)

Veya PowerShell çıktısı olarak:

New-NetFirewallRule -DisplayName "SQL Server AG Endpoint" `
  -Direction Inbound -Protocol TCP -LocalPort 5022 -Action Allow

W25SQL25NOD1 Üzerinde Failover Clustering Kurulumu

W25SQL25NOD1 isimli sunucumuzun Computer name (Sunucu İsmi) düzenlenerek, Ethernet0 ve Ethernet1 network kartları üzerinde IP adresi yapılandırılarak Active Directory Domain yapısına dahil edildi.

Server Manager konsolunu açıyoruz. Dashboard ekranında Add roles and Features seçeneğine tıklıyoruz ya da sağ üst köşedeki Manage menüsünden Add Roles and Features seçeneğine tıklayarak sihirbazı açabilirsiniz.

Before you begin ekranında Windows Server Failover Cluster (WSFC) özelliğinin kurulumu için gerekli ön bilgileri görüyoruz:

• Administrator hesabının güçlü bir parolası olmalıdır
• Network ayarları Statik IP adresi olarak yapılandırılmalıdır
• Sunucu üzerinde Windows Update ile en güncel güvenlik güncelleştirmeleri yüklenmelidir

Before you begin ekranında Next seçeneğine tıklayarak devam ediyoruz.

Select Installation Type ekranında Role-based or feature-based installation seçeneğini tercih ediyoruz. Bu seçenek, Windows Server üzerinde ihtiyaç duyulan rollerin ve özelliklerin manuel olarak seçilerek kurulmasını sağlar ve WSFC gibi altyapı bileşenleri için kullanılan standart kurulum yöntemidir.

Select Installation Type ekranında Next seçeneğine tıklayarak devam ediyoruz.

Select destination server ekranında Select a server from the server pool seçeneği ile kurulumun yapılacağı W25SQL25NOD1 sunucusunu seçiyoruz.

Select destination server ekranında Next seçeneğine tıklayarak devam ediyoruz.

Select server roles ekranında Always On mimarisi için herhangi bir rol kurulumu yapmıyoruz. Always On altyapısı için gerekli bileşenler rol bazlı değil özellik (Feature) bazlı kurulmaktadır.

Select server roles ekranında herhangi bir seçim yapmadan Next ile devam ediyoruz.

Select features ekranında Failover Clustering özelliğini işaretliyoruz.

Failover Clustering: Windows Server üzerinde birden fazla sunucuyu (Node) tek bir Cluster altında birleştirerek uygulamaların High Availability ile çalışmasını sağlayan özelliktir. Küme içerisindeki bir sunucunun arızalanması durumunda ilgili servis otomatik olarak diğer Node üzerine aktarılır (failover). SQL Server Always On Availability Group mimarisinin temelini bu WSFC altyapısı oluşturur.

 

NOT — MPIO Hakkında: – burayıkontrolet (Burası lab ortamı ama Prod ortamda bunu neden kurduğumuzu açıklayalım. ) Bu çalışmadaki ortamımız bir LAB ortamı olduğu için Quorum (Disk Witness) amacıyla kullanılacak disk alanı iSCSI Target yapılandırması ile sağlanmaktadır.

Multipath I/O (MPIO), Always On Availability Group mimarisi için gerekli değildir. Always On yapısında veri diskleri paylaşımlı değildir; her replica kendi lokal disklerini kullanır ve senkronizasyon disk seviyesinde değil, SQL Server engine tarafından transaction log stream üzerinden sağlanır.

MPIO yalnızca şu durumlarda gündeme gelir: Failover Cluster Instance (FCI) mimarisi kuruyorsanız (paylaşımlı disk kullanılır) – Quorum için Disk Witness kullanıyorsanız ve bu disk çok yollu bir storage üzerinden sunuluyorsa

Quorum için Cloud Witness veya File Share Witness kullanıyorsanız MPIO’ya hiç ihtiyaç duymazsınız.

Failover Clustering özelliğini seçtiğimizde, gerekli yönetim araçlarının da kurulması gerektiğini bildiren Add Roles and Features Wizard ekranı gelir:

• Feature Administration Tools
• Failover Clustering Tools
  • Failover Clustering Module for Windows PowerShell
  • Failover Clustering Management Tools

Add Required Features seçeneğine tıklayarak devam ediyoruz.

Select features ekranında Failover Clustering özelliğinin kurulum ve yapılandırma için hazır olduğunu görüyoruz. Gerekli bağımlı bileşenler (Remote Server Administration Tools ve ilgili Failover Clustering Tools) otomatik olarak eklenmiş durumdadır.

Bu aşamada Failover Clustering özelliği, Microsoft SQL Server 2025 Always On Availability Group mimarisi için gerekli olan Windows Server Failover Cluster (WSFC) altyapısını oluşturmak üzere kuruluma hazır hale gelmiştir.

Select features ekranında Next seçeneğine tıklayarak devam ediyoruz.

Confirm installation selections ekranında seçtiğimiz Failover Clustering özelliğinin özetini görüyoruz.

Bu ekranda Restart the destination server automatically if required seçeneği bulunmaktadır. Failover Clustering gibi altyapı seviyesinde çalışan özelliklerin kurulumu sonrasında sunucunun yeniden başlatılması gerekebilir. Bu nedenle Restart the destination server automatically if required seçeneği işaretliyoruz.

Confirm installation selections ekranında Failover Clustering özelliğinin kurulumu tamamlandıktan sonra sunucunun otomatik olarak yeniden başlatılabilmesi için Restart the destination server automatically if required seçeneğini işaretliyoruz. Bu ayar, kurulum sırasında veya sonrasında yeniden başlatma gereksinimi oluştuğunda sürecin kullanıcı müdahalesi olmadan tamamlanmasını sağlar.

Kurulum işlemi başlatıldıktan sonra, Add Roles and Features Wizard ekranında Failover Clustering özelliğinin kurulumu tamamlandığında sunucunun otomatik olarak yeniden başlatılacağına dair bilgilendirme mesajı görüntülenir. Bu uyarı ekranında Yes seçeneğine tıklayarak işlemi kabul ediyoruz.

Bu onay ile birlikte, kurulum süreci tamamlandığında Windows Server gerekli gördüğü anda sunucuyu otomatik olarak yeniden başlatır ve Failover Clustering yapılandırmalarının eksiksiz şekilde devreye alınmasını sağlar.

Confirm installation selections ekranında seçtiğimiz Failover Clustering özelliğinin özetini görüyoruz.

Bu ekranda Restart the destination server automatically if required seçeneği bulunmaktadır. Failover Clustering gibi altyapı seviyesinde çalışan özelliklerin kurulumu sonrasında sunucunun yeniden başlatılması gerekebilir. Bu nedenle Restart the destination server automatically if required seçeneği işaretledik ve Install ile kurulumu başlatıyoruz.

Installation progress ekranında kurulumun başladığını görüyoruz.

Installation progress ekranında Failover Clustering özelliğinin kurulumunun başarıyla tamamlandığını görüyoruz. Close seçeneğine tıklayarak sihirbazı kapatıyoruz.

W25SQL25NOD2 Üzerinde Failover Clustering Kurulumu

Failover Cluster mimarisinde yer alacak tüm Node’lar üzerinde kullanılan özelliklerin birebir aynı şekilde kurulmuş olması büyük önem taşır. Bu yaklaşım; cluster stabilitesi, failover senaryolarının sağlıklı çalışması ve olası uyumsuzlukların önüne geçilmesi açısından best practice kabul edilir.

W25SQL25NOD2 isimli sunucumuzun Computer name (Sunucu İsmi) düzenlenerek, Ethernet0 ve Ethernet1 network kartları üzerinde IP adresi yapılandırılarak Active Directory Domain yapısına dahil edildi.

Server Manager konsolunu açıyoruz.

Dashboard ekranında Add roles and Features seçeneğine tıklıyoruz yada sağ üst köşedeki Manage menüsünden Add Roles and Features seçeneği tıklayarak Roles (Roller) ve Features (Özellikler) ekleme sihirbazını açabilirsiniz.

W25SQL25NOD2 sunucusu üzerinde de W25SQL25NOD1 ile birebir aynı adımları uygulayarak Failover Clustering özelliğini kuruyoruz:

1. Server Manager → Add Roles and Features
2. Role-based or feature-based installation
3. Hedef sunucu olarak W25SQL25NOD2
4. Rol seçimi yapılmadan geçilir
5. Features → Failover Clustering + Add Required Features
6. Restart the destination server automatically if required işaretlenir
7. Install

Windows Server Failover Cluster Yapılandırması

W25SQL25NOD1 ve W25SQL25NOD2 isimli sunucularımız üzerinde Windows Server Failover Cluster (WSFC) yapılandırmasını başlatıyoruz.

Yapılandırma Öncesi Kontrol Listesi

Tüm sunucular Cluster’a katılmaya uygun olmalıdır:

• Aynı Active Directory Domain’e join edilmiş olmalı
• Aynı Windows Server sürümüne sahip olmalı
• Gereken tüm Windows güncellemeleri yapılmış olmalı
• Network yapılandırmaları doğru şekilde yapılmış olmalı
• Failover Clustering özelliği her Node’da kurulu olmalı

Donanım ve yazılım yapılandırmasının uyumluluğu doğrulanmalıdır. Microsoft, cluster kurulumundan önce Validate Configuration Wizard çalıştırılmasını önerir. Bu validasyon testi ağ, depolama, sistem yapılandırması, sürücüler ve donanım uyumluluğunu kontrol eder. SQL Server Always On Availability Group gibi kritik bir yapıda validasyon çalıştırmak best practice kabul edilir.

Cluster için kullanılacak bilgisayar adı ve IP adresi hazır olmalıdır:

• Cluster Name (Küme Adı)
• Cluster IP Address (Küme IP Adresi)

Active Directory Domain üzerinde Cluster adı için Computer Object (CNO) oluşturulabilmesi adına Create Computer Objects yetkisi verilmiş olmalıdır. (Bu yetkinin nasıl verileceği yazının başındaki “Ön Hazırlık: Active Directory Yetkilendirmesi” bölümünde anlatılmıştır.)

Depolama ve Quorum yapılandırması planlanmış olmalıdır:

• Disk Witness
• File Share Witness
• Cloud Witness (Azure)

Failover Cluster Manager konsolunu açıyoruz.

Failover Cluster Manager konsolunda Failover Cluster Manager üzerinde sağ tuş Create Cluster yada Actions menüsü altında Create Cluster seçeneğine tıklayarak Failover Cluster yapılandırmasını başlatabilirsiniz.

Create Cluster Wizard ekranı açıldığında ilk olarak Before You Begin adımı karşımıza gelir. Bu ekran yalnızca bilgilendirme amaçlıdır. Next ile devam ediyoruz.

Select Servers ekranında Enter server name alanına W25SQL25NOD1 sunucusunun adını giriyoruz ve Add seçeneğine tıklıyoruz.

W25SQL25NOD1 sunucusunun Selected servers bölümüne başarıyla eklendiğini görüyoruz. Aynı yöntemle W25SQL25NOD2 sunucusunu da ekliyoruz.

Select Servers ekranında Enter server name alanına W25SQL25NOD2 sunucusunun adını giriyoruz ve Add seçeneğine tıklıyoruz.

W25SQL25NOD2 sunucusunun Selected servers bölümüne başarıyla eklendiğini görüyoruz.

Select Servers ekranında W25SQL25NOD1 ve W25SQL25NOD2 isimli sunucuların Windows Server Failover Cluster (WSFC) yapılandırması için Selected servers bölümüne eklendiğini görüyoruz.

Select Servers ekranında her iki sunucunun da Selected servers bölümüne eklendiğini görüyoruz. Next ile devam ediyoruz.

Validation Warning ekranında Failover Cluster oluşturma sürecinde Microsoft tarafından önerilen Configuration Validation Tests adımının atlanmak üzere olduğunu bildiren bir uyarı ekranıdır. Bu aşamada sunulan Yes ve No seçenekleri, cluster kurulumunun nasıl devam edeceği belirleyebiliriz.

• Yes – When I click Next, run configuration validation tests, and then return to the process of creating the cluster: Bu seçenek tercih edildiğinde, Next seçeneğine tıklanmasıyla birlikte yapılandırma doğrulama testleri başlatılır. Testler tamamlandıktan sonra sihirbaz otomatik olarak Failover Cluster oluşturma sürecine geri döner. Microsoft tarafından desteklenen yöntem bu olduğu için, özellikle üretim ortamlarında validasyon testlerinin mutlaka çalıştırılması önerilir. Bu testler sayesinde ağ, depolama, sürücüler ve Active Directory Domain izinleri gibi Failover Cluster için kritik bileşenler önceden doğrulanır.
• No – I do not require support from Microsoft for this cluster, and therefore do not want to run the validation tests: Bu seçenekte ise validasyon testleri çalıştırılmadan doğrudan Failover Cluster oluşturma işlemine devam edilmesini sağlar. Ancak bu tercih, oluşturulan Failover Cluster yapısının Microsoft tarafından desteklenmemesine ve ilerleyen aşamalarda ağ, depolama, DNS veya Failover süreçlerinde beklenmedik sorunların yaşanmasına neden olabilir. Özellikle Microsoft SQL Server Always On Availability Group gibi kritik yapılarda bu adımın atlanması önerilmez; bu nedenle No seçeneği yalnızca test veya lab ortamları için uygun bir yaklaşımdır.

SQL Server Always On Availability Group gibi kritik yapılarda bu adımın atlanması önerilmez. Yes seçeneğini işaretleyerek Next ile devam ediyoruz.

Validate a Configuration Wizard ekranı açıldığında Before You Begin ekranı karşımıza gelir. Validation işlemi sistem üzerinde herhangi bir değişiklik yapmaz; yalnızca mevcut ortamı analiz ederek olası uyumsuzlukları raporlar. Next ile devam ediyoruz.

Before You Begin ekranında Failover Cluster kurulumu öncesinde çalıştırılacak doğrulama testlerinin amacını özetleyen bir bilgilendirme ekranıdır. Failover Cluster’a dahil edilecek sunucuların donanım, ağ, depolama ve genel yapılandırma açısından Microsoft standartlarına uygunluğu bu testler ile kontrol edileceği belirtilir.

Testing Options ekranında Windows Server Failover Cluster (WSFC) yapılandırması için Run all tests (recommended) ve Run only tests I select seçeneklerini görüyoruz.

• Run all tests (recommended) seçeneği, Failover Cluster için gerekli olan tüm doğrulama testlerinin eksiksiz şekilde çalıştırılmasını sağlar. Microsoft tarafından önerilen bu yöntem ile ağ, depolama, disk yapılandırması, sistem ayarları ve donanım uyumluluğu gibi Cluster’ın kararlı çalışması için kritik tüm bileşenler kapsamlı olarak test edilir. Tüm testlerin çalıştırılması, oluşturulacak cluster yapısının Microsoft destek kriterlerine uygun olmasını sağlar.
• Run only tests I select seçeneği ise yalnızca yöneticinin belirlediği testlerin çalıştırılmasına imkan tanır. Bu yöntem daha hızlı ilerlemeyi sağlasa da tüm bileşenler test edilmediği için olası sorunların gözden kaçmasına neden olabilir ve Cluster yapısı Microsoft tarafından tam desteklenen bir konfigürasyon haline gelmeyebilir. Bu nedenle bu seçenek genellikle test veya özel senaryolar için tercih edilmelidir.

Testing Options ekranında Run all tests (recommended) seçeneğini işaretliyoruz. Microsoft tarafından önerilen bu yöntem ile ağ, depolama, disk yapılandırması, sistem ayarları ve donanım uyumluluğu kapsamlı olarak test edilir.

Confirmation ekranında Windows Server Failover Cluster (WSFC) yapısı için W25SQL25NOD1 ve W25SQL25NOD2 sunucuları üzerinde gerçekleştirilecek tüm doğrulama kontrollerinin listesini görüyoruz.

Confirmation ekranında Windows Server Failover Cluster (WSFC) yapısı için W25SQL25NOD1 ve W25SQL25NOD2 sunucuları üzerinde yapılacak tüm kontrollerin listesini inceledikten sonra, doğrulama işlemlerini başlatmak için Next seçeneğine tıklayarak bir sonraki adıma geçiyoruz.

Validating ekranında doğrulama kontrollerinin başlatıldığını görüyoruz.

Summary ekranında çalıştırılan tüm doğrulama kontrollerinin özet raporunu görüyoruz.

• Node bölümünde, Windows Server Failover Cluster (WSFC) yapısının W25SQL25NOD1 ve W25SQL25NOD2 sunucuları üzerinde yapılandırılacağını görüyoruz.
• Result bölümünde ise Cluster oluşturma öncesinde kontrol edilen tüm testlerin sonucunu listelenmiş şekilde görüyoruz. Eğer tüm kontroller Success olarak görünüyorsa Windows Server Failover Cluster (WSFC) kurulumu için bir engel bulunmadığını anlıyoruz. Herhangi bir hata veya uyarı ile karşılaşırsak ilgili sonucu detaylı inceleyip gerekli düzeltmeleri yaptıktan sonra doğrulama testlerini yeniden çalıştırıyoruz.

Tüm kontroller Success olarak görünüyorsa kurulum için engel bulunmadığını anlıyoruz. Detaylı çıktıyı incelemek için View Report seçeneğini kullanabilirsiniz.

Summary ekranında Result Summary bölümünde, W25SQL25NOD1 ve W25SQL25NOD2 isimli sunucular üzerinde Windows Server Failover Cluster (WSFC) yapılandırması öncesinde gerekli tüm kontrollerin başarıyla tamamlandığını ve herhangi bir sorun bulunmadığını görüyoruz.

Finish seçeneğine tıklayarak Validate a Configuration Wizard ekranını kapatıyoruz.

Access Point for Administering the Cluster ekranında Cluster Name ve Cluster Address bilgilerini tanımlıyoruz.

• Cluster Name: Oluşturulan Failover Cluster’ın Active Directory Domain ve ağ üzerinde tanımlanan benzersiz kimliğidir. Bu isim ile Active Directory üzerinde Cluster için bir Computer Object (CNO) oluşturulur.
• Networks: Cluster’a dahil olan networklerin nasıl kullanılacağını belirlediğimiz alandır. Cluster, node’lar üzerinde tanımlı tüm ağ arayüzlerini otomatik algılar ve her networkü belirli rollerle ilişkilendirir.
• Cluster Address: Failover Cluster’a erişim sağlamak için kullanılan sanal IP adresidir. Bu IP node’lar arasında taşınabilir yapıdadır.

Access Point for Administering the Cluster ekranında Cluster Name ve Cluster Address bilgilerini tanımlıyoruz.

• Cluster Name: Oluşturulan Failover Cluster’ın Active Directory Domain ve ağ üzerinde tanımlanan benzersiz kimliğidir. Bu isim ile Active Directory üzerinde Cluster için bir Computer Object (CNO) oluşturulur.
• Networks: Cluster’a dahil olan networklerin nasıl kullanılacağını belirlediğimiz alandır. Cluster, node’lar üzerinde tanımlı tüm ağ arayüzlerini otomatik algılar ve her networkü belirli rollerle ilişkilendirir.
• Cluster Address: Failover Cluster’a erişim sağlamak için kullanılan sanal IP adresidir. Bu IP node’lar arasında taşınabilir yapıdadır.

Not: Bu adımda yapılandırılan Cluster Name ve Cluster Address bilgilerinin ortamda başka bir sunucu veya cihaz tarafından kullanılmıyor olmasına dikkat edilmelidir. Aksi durumda DNS kayıtları ve ağ erişiminde sorunlar yaşanabilir.

 

Confirmation ekranında yapılandırmaya ait özet bilgileri görüyoruz:

• Cluster: Oluşturulan SQLFOC isimli Cluster Name
• Node: Cluster’a dahil edilecek W25SQL25NOD1 ve W25SQL25NOD2 sunucuları
• Cluster registration: DNS Server ve Active Directory Domain Services üzerinde yapılacak kayıt işlemleri
• IP Address: Cluster’ın kullanacağı sanal IP adresi

Add all eligible storage to the cluster: Bu seçenek, cluster tarafından kullanılmaya uygun tüm paylaşımlı disklerin otomatik olarak cluster yapısına eklenmesini sağlar. Quorum diski için kullanılabilir.

Confirmation ekranında gerekli kontrolleri sağladıktan sonra, Windows Server Failover Cluster (WSFC) yapılandırmasını başlatmak için Next seçeneğine tıklayarak devam ediyoruz.

Creating New Cluster ekranında yapılandırmanın başlatıldığını görüyoruz.

Summary ekranında cluster yapılandırmasının sorunsuz tamamlandığını görüyoruz:

• Node: Cluster yapısına dahil edilen sunucular
• Cluster: Oluşturulan SQLFOC isimli cluster yapısının AD ve DNS üzerinde kaydedildiği
• Quorum: Seçilen Quorum yapılandırması
• IP Address: Cluster’a atanan sanal IP adresi

Finish seçeneğine tıklayarak Create Cluster Wizard ekranını kapatıyoruz.

EKLENMESİ GEREKEN BÖLÜM: Quorum Yapılandırması – burayıkontrolet – ( Burada ekledim kontrol edelim)

⚠️ BU YAZI DİZİSİNİN EN BÜYÜK EKSİĞİ

Orijinal yazıda “Quorum’un doğru yapılandırılması failover başarısı açısından kritiktir” deniyor, ancak Configure Cluster Quorum Settings sihirbazı hiç anlatılmıyor.

Neden kritik: 2 node’lu bir cluster’da Witness olmadan, bir node düştüğünde kalan node quorum’u kaybeder ve cluster tamamen kapanır. Yani Always On yapınız hiç çalışmaz. Bu, teorik bir risk değil — kesin sonuçtur.

Aşağıdaki bölümü yazıp ekran görüntülerini çekmeniz gerekiyor.

Quorum Nedir

Quorum, Windows Server Failover Cluster’ın hangi node’ların cluster’ı çalıştırmaya devam edeceğine karar vermek için kullandığı oylama mekanizmasıdır. Her node bir oy (vote) hakkına sahiptir. Cluster’ın ayakta kalabilmesi için oyların çoğunluğunun mevcut olması gerekir.

2 node’lu bir cluster’da: Toplam 2 oy vardır. Bir node düştüğünde kalan 1 oy, çoğunluğu (2/2+1 = 2) sağlayamaz ve cluster kapanır. Bu nedenle üçüncü bir oy kaynağı (Witness) eklenmesi zorunludur.

Witness Türleri

Witness Türü	Kullanım Senaryosu	Avantaj
Disk Witness	Tüm node’ların eriştiği paylaşımlı disk (SAN/iSCSI)	Cluster veritabanı kopyası tutar
File Share Witness	Ayrı bir sunucuda SMB paylaşımı	Paylaşımlı disk gerektirmez
Cloud Witness	Azure Storage Account	Üçüncü lokasyon gerektirmez, DR için ideal

Always On Availability Group mimarisinde paylaşımlı disk kullanılmadığı için genellikle File Share Witness veya Cloud Witness tercih edilir.

Çekilecek Ekran Görüntüleri – burayıkontrolet. ( Burada açıklamaları detaylandırmamız gerekiyor. Örnek Disk / File Share / Cloud Witness seçenekleri,Select Quorum Configuration Option ekranındaki seçenekler gibi. )

1. [🟢 EKLE] Failover Cluster Manager → Cluster üzerinde sağ tık → More Actions → Configure Cluster Quorum Settings
2. [🟢 EKLE] Before You Begin ekranı
3. [🟢 EKLE] Select Quorum Configuration Option → Select the quorum witness
4. [🟢 EKLE] Select Quorum Witness → Disk / File Share / Cloud Witness seçenekleri
5. [🟢 EKLE] Seçilen witness türüne göre yapılandırma ekranı (disk seçimi veya UNC path veya Azure Storage bilgileri)
6. [🟢 EKLE] Confirmation ekranı
7. [🟢 EKLE] Summary — yapılandırmanın başarılı olduğu ekran
8. [🟢 EKLE] Failover Cluster Manager ana ekranında Cluster Core Resources → Witness kaynağının Online göründüğü ekran

Doğrulama Komutu

Yapılandırma sonrası aşağıdaki PowerShell komutuyla oy dağılımını doğrulayın:

Get-ClusterNode | Select-Object Name, State, NodeWeight
Get-ClusterQuorum

burada

Failover Cluster Manager → Cluster üzerinde sağ tık → More Actions → Configure Cluster Quorum Settings seçeneğine tıklıyoruz.

Before You Begin ekranı

Select Quorum Configuration Option → Select the quorum witness

Select Quorum Witness → Disk / File Share / Cloud Witness seçenekleri

 

Confirmation ekranı

Seçilen witness türüne göre yapılandırma ekranı (disk seçimi veya UNC path veya Azure Storage bilgileri)

Summary — yapılandırmanın başarılı olduğu ekran

Failover Cluster Manager ana ekranında Cluster Core Resources → Witness kaynağının Online göründüğü ekran

Doğrulama Komutu

Yapılandırma sonrası aşağıdaki PowerShell komutuyla oy dağılımını doğrulayın:

Get-ClusterNode | Select-Object Name, State, NodeWeight

Get-ClusterQuorum

 

 

Failover Cluster Manager Konsolu

Failover Cluster Manager konsoluna geri döndüğümüzde, Windows Server Failover Cluster yapımıza ait bilgilerin Summary of Cluster SQLFOC bölümünde görüntülendiğini görüyoruz.

SQLFOC.bakicubuk.local isimli cluster’ı genişlettiğimizde Failover Cluster mimarisinin temel bileşenlerini görüyoruz:

• Roles (Roller): Cluster üzerinde çalışan servisler, uygulamalar ve roller bu bölümden yönetilir
• Nodes (Düğümler): WSFC yapısına üye olan sunucular listelenir. Node’ların sağlık durumu ve bakım işlemleri buradan yönetilir
• Storage (Depolama): Cluster tarafından kullanılan paylaşımlı depolama kaynakları. Diskler, Cluster Shared Volumes (CSV) ve Quorum (Disk Witness) yapılandırmaları bu alandan görüntülenir
• Networks (Ağlar): Cluster içi iletişim (heartbeat) ve istemci erişimi için kullanılan ağlar

Roles (Roller) menüsünde User Manager Group yapılandırmasının yer aldığını görüyoruz. – burayıkontrolet. ( Sen burayı çıkardın ancak açıklama olarak User Manager Group ne olduğu bilgi açısından kalsın. Buradaki benim açıklamayı kısaltabilirsin belki ama kalsın çıkarma neden göründüğünü açıklayalım ama bunun Always On bir etkisinin olmadığını belirtelim )

User Manager Group: Windows Server Failover Cluster (WSFC) yapısı içerisinde tanımlı olan bir Cluster rolüdür ve uygulama veya servislerin High Availability (Yüksek Erişilebilir) şekilde çalışmasını sağlamak amacıyla kullanılır. Bu rol; belirli bir uygulama ya da servis grubunun hangi node üzerinde aktif olduğunu, hangi cluster kaynaklarına (IP adresi, Ağ adı, Servisler vb.) bağlı çalıştığını ve failover durumunda bu kaynakların nasıl taşınacağını yönetir. User Manager Group, tek başına bir kullanıcı grubu değildir. Aksine, birden fazla Cluster kaynağını mantıksal olarak bir araya getirerek bunların birlikte hareket etmesini sağlayan bir rol yapısıdır. Olası bir Node arızası veya Servis kesintisi durumunda, bu gruba bağlı tüm kaynaklar otomatik olarak başka bir Node’a taşınır ve uygulamanın kesintisiz çalışması sağlanır.

Microsoft SQL Server Always On Availability Group mimarisinde User Manager Group, doğrudan SQL Server bileşenlerini temsil eden bir cluster rolü değildir. Server Always On Availability Group yapılarında High Availability (Yüksek Erişilebilirlik); Availability Group, Availability Replica ve SQL Listener gibi birbirinden bağımsız Cluster kaynakları üzerinden yönetilir.

Bu mimaride SQL Listener, Windows Server Failover Cluster (WSFC) üzerinde bağımsız bir rol olarak tanımlanır ve istemci bağlantıları bu rol üzerinden yönlendirilir. Uygulamalar ve kullanıcılar, doğrudan SQL Server Node’larına değil, Listener adı ve IP adresi üzerinden erişim sağlar.

Bu nedenle User Manager Group, Server Always On Availability Group yapılarında genellikle SQL dışı uygulamalar, özel servisler veya üçüncü parti yazılımlar için kullanılan bir Cluster rolü olarak konumlanır. SQL Always On bileşenleriyle doğrudan ilişkili olmasa da, aynı Windows Server Failover Cluster (WSFC) altyapısını paylaştığı için Quorum yapısı, ağ yapılandırması ve Cluster genel sağlığı gibi temel bileşenlerden dolaylı olarak etkilenir.

Bu sebeple Windows Server Failover Cluster (WSFC) üzerinde tanımlanan tüm roller gibi, User Manager Group’un da doğru şekilde yapılandırılması ve izlenmesi; cluster stabilitesi, failover davranışlarının sağlıklı çalışması ve genel sistem sürekliliği açısından önemli bir best practice olarak değerlendirilmelidir.

Nodes menüsünde W25SQL25NOD1 ve W25SQL25NOD2 sunucularının Status bölümünde Up durumda olduğunu görüyoruz.

Storage menüsü altındaki Disks bölümünde, Quorum yapılandırması için kullanılan Disk Witness diskinin cluster tarafından tanındığını görüyoruz.

Disk Witness, Cluster Quorum mekanizması kapsamında ek bir Quorum Vote (Oy Hakkı) sağlayarak cluster’ın Quorum State‘ini korumasına yardımcı olur. Özellikle node veya network kesintilerinde cluster’ın Split-Brain durumuna düşmesini engeller.

Failover Cluster Instance (FCI) mimarisinde Data, Log, Temp ve Backup dizinleri Cluster Shared Volume (CSV) diskleri üzerinde konumlandırılır. Failover gerçekleştiğinde ilgili diskler aktif node’a taşınır.

Buna karşılık Always On Availability Group mimarisinde Data, Log, Temp ve Backup dizinleri paylaşımlı depolama yerine her SQL Server Node’unun lokal diskleri üzerinde konumlandırılır. Veri senkronizasyonu disk seviyesinde değil; Transaction Log Stream‘lerinin replica’lar arasında iletilmesi yoluyla, tamamen SQL Server engine tarafından sağlanır.

Networks menüsü altında cluster’a ait networkleri görüyoruz:

• Cluster Only: Yalnızca node’lar arası cluster iletişimi (Heartbeat ve Cluster State) için kullanılır, istemci erişimine kapalıdır
• Cluster and Client: Hem cluster içi iletişim hem de istemci bağlantıları için kullanılır. Uygulama, servis ve SQL Listener erişimleri bu ağ üzerinden sağlanır

Bu ayrım sayesinde cluster trafiği ile istemci trafiği izole edilerek daha kararlı bir yapı elde edilir.

Sonuç

W25SQL25NOD1 ve W25SQL25NOD2 isimli Windows Server 2025 sunucularımız üzerinde Windows Server Failover Cluster (WSFC) yapısının kurulum ve yapılandırma adımlarını tamamladık. Bu yapı, High Availability ve Disaster Recovery senaryolarının temelini oluşturan kritik bir altyapı bileşenidir.

Bir sonraki yazımızda, aynı sunucular üzerinde Microsoft SQL Server 2025 kurulum adımlarını detaylı şekilde ele alacağız.

➡️ Bölüm 2 — Microsoft SQL Server 2025 Kurulumu

Bir sonraki yazımızda görüşmek dileğiyle…