Aynı Sunucuya Birden Fazla SQL Server Instance’ı Kurmalı mısınız? Artılar, Eksiler ve Alternatifler

Aynı Windows sunucusuna birden fazla SQL Server instance’ı kurmak (instance stacking) cazip görünür: tek işletim sistemi, tek sunucu, bazen tek lisans. Farklı uygulamalar farklı collation, farklı sürüm ya da ayrı sysadmin yetkisi istediğinde de akla ilk gelen çözümdür. Ancak aynı donanımı paylaşan instance’lar, bir gün birinin diğerinin kaynaklarını tüketmesiyle sonuçlanabilir; yamalar ve yeniden başlatmalar da hepsini birden etkiler.

Bu yazıda instance stacking’in gerçek avantajlarını, risklerini, birden fazla instance kaçınılmazsa nasıl yönetileceğini ve alternatifleri anlatıyoruz.

Neden Birden Fazla Instance Kurulur?

• Farklı sunucu ayarları: Sunucu collation’ı, tempdb yapılandırması ya da sp_configure ayarları uygulamalar arasında çakışıyorsa.
• Yetki ayrımı: Bir uygulama ekibi sysadmin yetkisi istiyor ve diğer veritabanlarına erişmemesi gerekiyorsa.
• Farklı sürümler: Eski bir uygulama yalnızca eski bir SQL Server sürümünü destekliyorsa.
• Maliyet: Tek bir Windows lisansı ve yönetilecek tek bir sunucu.

Lisans açısından: fiziksel bir sunucu ya da sanal makine çekirdek bazında lisanslandığında, o işletim sistemi ortamında istediğiniz sayıda instance çalıştırabilirsiniz. Ayrıntılar lisanslama rehberimizde.

Riskler

• Bellek rekabeti: Her instance, kendisine bir sınır verilmezse kullanılabilir belleğin tamamını almaya çalışır. İki instance aynı belleği isteyince biri diğerini sıkıştırır ve işletim sistemi de baskı altına girer.
• CPU ve disk paylaşımı: Bir instance’ta çalışan ağır bir rapor ya da index bakımı, diğerindeki kritik uygulamayı yavaşlatır. Disk gecikmesi tüm instance’lara yansır.
• Ortak bakım penceresi: Windows yaması ya da sunucu yeniden başlatması tüm instance’ları aynı anda etkiler.
• Tek arıza noktası: Donanım ya da işletim sistemi sorunu tüm uygulamaları birlikte durdurur.
• Sorun giderme zorluğu: “Sunucu yavaş” şikâyetinde hangi instance’ın neden olduğunu bulmak daha uzun sürer.
• Port ve ağ yönetimi: Adlandırılmış instance’lar dinamik port kullanır; güvenlik duvarı ve bağlantı dizeleri için sabit portlar planlamak gerekir.

Birden Fazla Instance Kaçınılmazsa

Belleği paylaştırın

Her instance için max server memory ayarlayın. Tüm instance’ların toplamı, işletim sistemine ve diğer servislere yeterli pay kalacak şekilde fiziksel belleğin altında olmalıdır. Kritik instance’a min server memory ile bir taban da verebilirsiniz.

-- Her instance'ta ayrı ayrı çalıştırın; değerleri iş yüküne göre belirleyin
EXEC sys.sp_configure N'show advanced options', 1;
RECONFIGURE;
EXEC sys.sp_configure N'max server memory (MB)', 40960;   -- örnek: 64 GB sunucuda 1. instance
RECONFIGURE;

CPU’yu değerlendirin

Çoğu durumda MAXDOP’u her instance için ayrı ayarlamak yeterlidir. Kritik bir instance’ın CPU’sunu kesin olarak korumak gerekiyorsa process affinity kullanılabilir; ancak bu, boşta kalan çekirdeklerin diğer instance tarafından kullanılmasını da engeller ve dikkatli bir planlama gerektirir.

Diski ve TempDB’yi ayırın

Mümkünse her instance’ın veri, log ve TempDB dosyalarını ayrı volume’lara yerleştirin; en azından TempDB’leri paylaşmayın.

Sabit port ve belgeleme

Her instance’a sabit bir port atayın, güvenlik duvarı kurallarını buna göre yazın ve hangi uygulamanın hangi instance’ta olduğunu belgeleyin.

Alternatifler

Sunucudaki Instance’ları Görmek

# Bu sunucudaki tüm SQL Server Database Engine servisleri
Get-Service -Name 'MSSQLSERVER', 'MSSQL$*' -ErrorAction SilentlyContinue |
    Select-Object Name, Status, StartType

Kullanılmayan instance’ları ve servisleri (Reporting Services, Analysis Services, Browser) kapatmak, kaynakları serbest bırakır ve saldırı yüzeyini küçültür. Ayrıntılar yapılandırma rehberimizde.