SQL Server Always On: Yüksek Erişilebilirlik ve Kiralama

SQL Server Always On sunucu kiralama, kritik veritabanlarını tek bir Windows veya SQL Server örneğine bağımlı bırakmamak amacıyla birden fazla sunucuda yüksek erişilebilirlik mimarisi oluşturulmasıdır. Özellikle muhasebe, ERP, üretim, sipariş ve kurumsal uygulama veritabanlarında kesinti etkisini azaltmak isteyen şirketler için değerlendirilebilir. Ancak iki SQL sunucusuna aynı veriyi kopyalamak tek başına otomatik geçiş, sıfır veri kaybı veya kesintisiz uygulama anlamına gelmez.

Kısa cevap: Önce uygulamanızın SQL Server sürümünü, veritabanı sayısını, işlem yoğunluğunu ve kabul edilebilir kesinti süresini ölçün. Ardından Standard Basic Availability Group, Enterprise Availability Group, Failover Cluster Instance veya yalnızca yedekleme ve felaket kurtarma modellerinden hangisinin gereksinimi karşıladığını seçin. Altyapı, lisans, WSFC, ağ, quorum, listener ve test kapsamını tek teklifte değerlendirin. SQL Server Always On altyapısı için teknik keşif ve teklif isteyin.

Bu rehber Türkiye'de SQL Server iş yükünü kendi ofisinden kiralık veri merkezi altyapısına taşımak, yüksek erişilebilirliğe geçirmek veya barındırma modelini değiştirmek isteyen BT yöneticileri ve satın alma ekipleri içindir. Anlatılan her tasarımın destek koşulları kullanılacak SQL Server sürümü, lisans modeli ve uygulama üreticisinin gereksinimleriyle ayrıca doğrulanmalıdır.

1. SQL Server Always On tam olarak nedir?

Always On, SQL Server'ın yüksek erişilebilirlik ve felaket kurtarma teknolojileri için kullanılan bir üst ifadedir. Availability Group (AG) yaklaşımı, birincil veritabanının işlem günlüğü değişikliklerini diğer SQL Server örneklerindeki kopyalara aktarır. Failover Cluster Instance (FCI) ise SQL Server örneğini kümeleme üzerinden erişilebilir kılmaya odaklanan farklı bir mimaridir. Her ikisini aynı teknoloji veya aynı lisans paketi sanmak yanlış karar doğurabilir.

Microsoft'un Always On availability groups genel bakışı, veri tabanı düzeyindeki replica, eşitleme ve failover ilişkisini açıklar. Her iş yüküne AG gerekli değildir: Kullanıcının bekleyebileceği kesinti süresi, yedekten dönüş hedefi ve uygulamanın çoklu sunucu uyumu, yatırım kararının başlangıç noktasıdır.

Özellikle tek bir SQL örneğinde farklı şirket veritabanları ve ortak kimlik doğrulama bileşenleri bulunuyorsa, yalnız bir veritabanının replike edilmesi uygulamanın tamamını korumayabilir. Uygulama bağlantılarının, dosya ve servis bağımlılıklarının ayrıca haritalanması gerekir.

2. Standard Basic AG ile Enterprise AG arasındaki fark

SQL Server Standard sürümlerinde sunulan Basic Availability Group, daha sınırlı bir yüksek erişilebilirlik yaklaşımıdır. Microsoft'un Basic AG resmî kısıtları, iki replica, tek availability database, secondary üzerinde okuma ve yedek alma kısıtları gibi temel sınırları belirtir.

Enterprise sürümündeki gelişmiş AG, desteklenen sürümün özelliklerine göre daha fazla veritabanını ve gelişmiş replica senaryolarını kapsayabilir. Ancak yalnız “Enterprise alınca her şey otomatik çalışır” denilemez: WSFC kurulumu, ağ ve quorum, failover politikası, güvenlik, işlem günlükleri ve uygulama bağlantı davranışı ayrı operasyon gerektirir.

Tablo, karar için bir ön elemedir; lisans ve teknik sınırlar kurulu sürümün resmî belgeleriyle karşılaştırılmalıdır. Microsoft'un SQL Server 2025 sürüm özellikleri tablosu, Standard ile Enterprise yüksek erişilebilirlik özelliklerini ayrı listeler.

3. İki SQL sunucusu ve WSFC neden birlikte planlanır?

Windows üzerindeki klasik yüksek erişilebilirlik AG tasarımında iki SQL Server replica'sının ayrı Windows Server Failover Clustering (WSFC) düğümlerinde çalışması gerekir. Bu, “iki sanal makine kurduk, Always On hazır” yaklaşımından daha fazlasını gerektirir. Cluster kimliği, AD/DNS, ağ iletişimi, uygun servis hesapları, replica endpoint'leri ve desteklenen işletim sistemi sürümleri kontrol edilmelidir.

Microsoft'un WSFC ile AG ilişkisini açıklayan dokümanı, cluster sağlığının ve quorum kararlarının failover için önemini açıklar. Bazı read-scale veya Linux senaryoları farklı önkoşullar kullanabilir; bunlar normal Windows yüksek erişilebilirlik AG'siyle eşdeğer sayılmamalıdır.

İki sanal makine aynı fiziksel host, aynı depolama arızası veya aynı enerji yoluna bağlıysa, işletim sistemi seviyesinde iki düğüm bulunması fiziksel tek nokta arızasını çözmeyebilir. Teklif aşamasında düğümlerin fiziksel yerleşimi, depolama bağımsızlığı ve ağın ortak arıza alanları sorgulanmalıdır.

4. Quorum ve witness tasarımında hangi sorular önemlidir?

WSFC quorum, kümenin sağlıklı çoğunluğu belirlemesini ve ağ bölünmesi gibi durumlarda aynı anda iki tarafın kendisini yetkili sanması riskini yönetmesini sağlar. İki düğümlü tasarımda tanık (witness) ihtiyacı, kullanılan quorum modu ve arıza alanlarına göre değerlendirilir. Tanık erişiminin kaybolması, her zaman tek başına üretim veritabanını anında durdurur gibi basit bir genelleme yapmak doğru değildir.

Tanığın ayrı bir hata alanında bulunması, DNS erişimi, gerekli ağ izinleri ve operasyon sorumlusu planlanmalıdır. Örneğin iki SQL düğümü farklı sanallaştırma hostlarındayken witness'ı aynı host veya ortak depolama üzerine yerleştirmek, fiziksel arıza bağımsızlığını beklenenden düşük tutabilir.

Bir teklif hazırlığında “iki sunucu + cluster” satırı yeterli değildir. Cluster düğümleri, oy hakkı, witness tipi, arıza alanları ve failover kararının kim tarafından gözleneceği yazılı olmalıdır. Planlanan kurulumun iş yüküne uygunluğu test ortamında gösterilmelidir.

5. Synchronous ve asynchronous commit hangi durumda seçilir?

Synchronous commit modunda birincil SQL Server, uygun koşullarda işlemi tamamlamadan önce senkron ikincil replica'nın günlük kaydını kalıcı depolamaya yazdığına dair onayı bekler. Bu veri dayanıklılığını güçlendirirken gecikmeyi etkileyebilir. Aynı veri merkezi içinde dahi ağ gecikmesi ve log I/O performansı ölçülmeden performans taahhüdü verilmemelidir.

Asynchronous commit, uzak lokasyon veya yüksek gecikmeli bağlantılarda tercih edilebilecek bir yöntemdir. Ancak birincil sunucu kaybedildiğinde henüz ikincile aktarılmamış işlemler nedeniyle veri kaybı riski bulunabilir. Microsoft'un availability mode karşılaştırması, senkron ve asenkron davranışların farkını açıklar.

Otomatik failover için gerekli senkronizasyon sağlığı, uygun replica failover ayarı ve WSFC quorum koşulları gerekir. Sadece synchronous seçeneğinin etkin olması otomatik geçişi garanti etmez. Bu nedenle RPO/RTO hedefi, test edilen işlem süresi ve gerçek uygulama hata toleransı birlikte değerlendirilmelidir.

6. Listener, DNS ve uygulama bağlantıları nasıl çalışır?

Availability Group listener, uygulamaların tek bir bağlantı adı üzerinden geçerli birincil replica'ya ulaşmasına yardımcı olur. Uygulama tüm bağlantıları tek bir fiziksel SQL sunucusunun adına sabitlemişse, AG kurulmuş olsa da failover sonrası bağlantı sorunu devam edebilir.

Listener için uygun DNS kaydı, IP adresleme, port, firewall kuralı, uygulama bağlantı dizgesi ve sürücü desteği planlanmalıdır. Farklı alt ağdaki replica'lar kullanıldığında istemci sürücü davranışı ve bağlantı süreleri ayrıca test edilmelidir. Gereksiz biçimde SQL portunu herkese açık internete yayınlamak yerine ağ ve güvenlik hizmetleri kapsamında özel ağ veya VPN erişimi kullanılmalıdır.

Microsoft'un AG listener açıklaması, failover sırasında mevcut bağlantıların kopabileceğini ve istemcinin yeniden bağlanması gerektiğini belirtir. Son kullanıcı açısından gerçek başarı, SQL rol değişimi değil uygulamanın desteklenen yeniden bağlantı mantığıyla işlemine devam edebilmesidir.

7. SQL Server Always On neden tek başına yedek değildir?

AG, yüksek erişilebilirlik sağlar; ancak yanlışlıkla silinen kayıtların, mantıksal uygulama hatalarının ya da yetkili hesabın gerçekleştirdiği zararlı değişikliklerin ayrı bir tarihsel kopyasını otomatik sunmaz. Birincildeki bazı mantıksal veri değişiklikleri ikincile de yansıyabilir. Bu nedenle AG veya cluster, bağımsız geri yüklenebilir yedek yerine geçmez.

İş yüküne göre tam, fark ve işlem günlüğü yedekleri; saklama politikası, şifreleme, ayrı güvenlik alanı ve geri yükleme testiyle planlanmalıdır. Sadece yedek işi “başarılı” yazdı diye iş sürekliliği doğrulanmış sayılmaz. Yedekleme ve felaket kurtarma çözümleri, HA sisteminin dışında da gerekli olan bir koruma katmanıdır.

Ayrıca AG'nin veri tabanı düzeyinde çalışması SQL login, Agent işi, linked server, sertifika veya belirli örnek düzeyi yapılandırmalarının otomatik olarak aynı hâle geleceği anlamına gelmez. Failover sonrasında uygulamanın gerçekten çalışması için bu öğelerden hangilerinin iki düğümde bulunması gerektiği envanterlenmelidir.

8. Kiralık SQL Server için VPS mi dedicated sunucu mu?

SQL Server Always On mimarisi sanal ya da fiziksel sunucular üzerinde kurulabilir; desteklenen platform ve lisans koşullarının karşılanması gerekir. VPS ve bulut sunucu modeli kapasiteyi esnek ayarlama avantajı sağlayabilir. Sürekli yoğun işlem, özel depolama veya sıkı fiziksel izolasyon gereksiniminde dedicated sunucu kiralama değerlendirilebilir.

Asıl karar yalnız CPU/RAM değildir. Birincil ve ikincil replica için disk gecikmesi, log yazma kapasitesi, tempdb davranışı, ağ bant genişliği, latency ve arıza alanları birlikte ölçülmelidir. İki fiziksel sunucunun farklı şase olması yeterli olmayabilir; ortak SAN, ortak firewall veya tek operatör gibi bağımlılıklar işletme gereksinimine göre ayrıca sınıflandırılmalıdır.

Daha önce SQL boyutlandırması yapılmadıysa SQL Server kiralama: IOPS, RAM ve lisans rehberindeki metrikleri başlangıç listesi olarak kullanabilirsiniz. Üretimdeki işlem hacmi ölçülmeden sabit disk hızı veya kesin failover süresi vaat edilmemelidir.

9. SQL Server Standard, Enterprise ve failover lisans maliyeti

SQL Server lisanslama; Edition, sürüm, fiziksel veya sanal çekirdek, Server+CAL imkânı, Software Assurance ya da abonelik kapsamı ve sağlayıcı modeline göre değişebilir. Yüksek erişilebilirlik için ikinci replica bulunması, onun koşulsuz ve ücretsiz lisans hakkı olduğu anlamına gelmez.

Microsoft'un SQL Server 2025 lisanslama rehberi, pasif yüksek erişilebilirlik ve felaket kurtarma sunucularına ilişkin hakları Software Assurance/abonelik yararları ve Product Terms bağlamında açıklar. Paylaşılan kiralık altyapıda mevcut lisansları taşıma hakkının da sağlayıcıya ve sözleşmeye göre doğrulanması gerekir. Nihai lisanslama kararı güncel üretici koşulları ve yetkili uzman incelemesiyle verilmelidir.

Teklifin dört kalemini ayrı görün: sunucuların kendisi, SQL ve Windows lisansları, HA cluster/AG kurulumu, operasyon ve destek. Ek replica ve Windows lisans bedelleri ile veri tabanı uygulamasının bakım masrafları aynı rakamın içine saklanmamalıdır. Sahte başlangıç fiyatı yerine doğrulanmış ihtiyaca göre teklif hazırlanması doğru karşılaştırmayı sağlar.

10. ERP ve muhasebe uygulamalarında Always On gerekli mi?

Logo, Mikro, Zirve, SAP veya başka bir ERP'nin SQL Server üzerinde çalışması, AG kullanımını otomatik olarak desteklediği anlamına gelmez. Üretici sürüm uyumu, lisans ve bağlantı dizgesi davranışı, yerel dosya bağımlılıkları, zamanlanmış entegrasyonlar ve servis başlangıcı kontrol edilmelidir. Uygulama, SQL bağlantısı kesildiğinde yeniden oturum açılmasını veya hizmetin yeniden başlatılmasını gerektirebilir.

Kurumlara yönelik ERP ve muhasebe altyapısı projelerinde gerçek kesinti maliyetiyle HA yatırımı karşılaştırılmalıdır. Örneğin satış, depo ve finans kullanıcılarının tamamı SQL kesintisinden etkileniyorsa kurtarma hedefleri daha sıkı olabilir. Sadece düşük kullanıcı sayısı bulunması ise otomatik olarak HA gereksizdir sonucuna götürmez; kritik işlem takvimi ve mevzuat etkisi önemlidir.

Yazılım üreticisi AG'yi desteklemiyorsa failover tasarımında farklı bir yaklaşım veya test edilmiş daha hızlı geri yükleme stratejisi gerekebilir. Desteklenmeyen bir yapı müşteriye “yüksek erişilebilirlik” etiketiyle sunulmamalıdır.

11. Devreye alma öncesi ve sonrasında hangi testler yapılmalı?

Sağlıklı bir proje, yalnız SSMS üzerinde AG durumunun yeşil görünmesiyle teslim edilmez. İş birimi temsilcisi, DBA, ağ ekibi ve sistem yöneticisi birlikte planlı failover, düğüm arızası, ağ kesintisi, uygulama yeniden bağlantısı, yedek geri yükleme ve eski duruma dönüş testlerini kabul kriterlerine bağlamalıdır.

Aşağıdaki kontrol listesini teklif ve devreye alma belgesine ekleyin:

1. SQL ve Windows sürümlerinin üretici uyumluluğu doğrulandı mı?
2. Standard Basic AG veya Enterprise özelliği ihtiyaca göre seçildi mi?
3. Her replica için ayrı host/depolama/ağ arıza alanları belgelendi mi?
4. WSFC quorum ve witness senaryoları test edildi mi?
5. Senkron/asenkron modelin RPO ve işlem gecikmesi ölçüldü mü?
6. DNS, listener, firewall ve uygulama bağlantıları gerçek kullanıcıyla denendi mi?
7. Login, Agent işi, sertifika ve diğer bağımlılıklar iki tarafta doğrulandı mı?
8. Yedeklerden bağımsız bir test ortamına geri yükleme yapıldı mı?
9. Failover sonrası veri tutarlılığı, rapor ve ERP işlemleri sınandı mı?
10. İzleme, alarm, bakım penceresi ve sorumluluk matrisi kabul edildi mi?

Yönetilen sunucu hizmetleri kapsamında hangi alarmın işletim ekibine, hangisinin DBA'ya, hangisinin ERP üreticisine iletileceği açık olmalıdır. İşletme tarafından onaylanan bir tatbikat raporu olmadan “otomatik felaket kurtarma hazır” ifadesi kullanılmamalıdır.

12. SQL Server Always On sunucu kiralama teklifi nasıl alınır?

Ön değerlendirme için SQL Server Edition/sürüm, mevcut veritabanı sayısı ve boyutları, eşzamanlı kullanıcı, tepe CPU/RAM/IOPS, uygulama bağımlılıkları, veri merkezi tercihleri, RPO/RTO, lisans durumu ve hedef başlangıç tarihini toplayın. Ayrıca tek lokasyon HA mı, uzak lokasyon DR mı ya da ikisi birlikte mi istendiğini belirtin.

Netsun Bilişim'in hazırlayacağı teklif, kullanıcının onayladığı iş yükü bilgilerine göre altyapı, lisans varsayımı, yüksek erişilebilirlik tasarımı, test ve operasyon sorumluluğu başlıklarında değerlendirilmelidir. İki sunuculuk fiziksel veya sanal konfigürasyon, kullanılabilirlik hedefi ve kabul süreci ön analiz yapılmadan garanti gibi sunulmamalıdır.

Kritik SQL veritabanınız için SQL Server Always On sunucu kiralama ve HA mimari teklifi isteyin. Karar vermeden önce yalnız kaç sunucu gerektiğini değil, gerçek arıza anında hangi verinin, uygulamanın ve iş akışının hangi koşullarla döneceğini netleştirin.

Sık sorulan sorular

1. SQL Server Always On nedir ve sunucu kiralamayla nasıl kullanılır?

Always On availability group, SQL veritabanı kopyalarını ayrı sunucularda yöneterek yüksek erişilebilirlik ve bazı felaket kurtarma senaryolarını destekler. Kiralık altyapıda replica, cluster, ağ ve lisans koşulları hizmet kapsamına göre oluşturulur.

2. SQL Server Standard sürümüyle Always On yapılabilir mi?

Desteklenen Standard sürümlerinde Basic Availability Group kullanılabilir. Ancak iki replica, tek veritabanı ve ikincil üzerinde okuma/yedek sınırlamaları gibi koşullar vardır. İhtiyaç bu sınırlara göre kontrol edilmelidir.

3. İki SQL sunucusu kurarsak otomatik failover kesin çalışır mı?

Hayır. Uygun WSFC quorum, replica senkronizasyonu, failover ayarları ve uygulama bağlantı tasarımı gerekir. Kurulum ve arıza testleri geçmeden kesin failover süresi veya otomatik toparlanma sözü verilemez.

4. Always On kullanıldığında veri kaybı tamamen ortadan kalkar mı?

Senkron ve sağlıklı replica koşulları veri kaybı riskini azaltabilir. Asenkron replikasyon ya da zorlanmış failover senaryolarında veri kaybı olabilir. Mantıksal silinmeler için ayrıca tarihsel yedek gereklidir.

5. SQL Server Always On için shared storage veya SAN zorunlu mu?

Availability Group modeli normalde her replica'nın kendi veri kopyasına dayanır; FCI ile aynı paylaşılan depolama yaklaşımını varsaymak doğru değildir. Seçilen mimarinin depolama, quorum ve sürüm koşulları ayrıca doğrulanmalıdır.

6. Yüksek erişilebilirlik için ikinci SQL Server lisansı ücretsiz mi?

Otomatik olarak ücretsiz değildir. Pasif failover hakları SQL sürümüne, lisans programına, Software Assurance/abonelik durumuna ve hizmet sağlayıcı koşullarına bağlıdır. Güncel Product Terms üzerinden teyit edilmelidir.

7. ERP yazılımında Always On kurarsak uygulama kesintisiz çalışır mı?

Her zaman değil. Veritabanı rol değiştirse bile uygulamanın listener ve yeniden bağlantı davranışı, servis bağımlılıkları ve üretici desteği gerekir. Gerçek kullanıcı kabul testi yapılmalıdır.

8. SQL Server Always On teklifi için hangi bilgileri paylaşmalıyım?

Mevcut SQL Edition/sürümü, veritabanı sayısı ve boyutu, yoğun işlem saatleri, kullanıcı sayısı, uygulama adı, lisans durumu, RPO/RTO hedefleri ve lokasyon gereksinimlerini bildirin. SQL Server Always On teklif formunu doldurun.