Gmsa Hesabı ile SQL Always On Yapılandırması – Step by Step

Always On Availability Groups, yüksek erişilebilirlik ve felaket kurtarma amacıyla kritik veritabanlarını birden fazla sunucu arasında senkronize etmeye yarar. Sadece veritabanı düzeyinde yedeklilik sağlar (Instance değil!).

Bu yazımda sizlere, MS SQL Always On kurulumunu ve bu süreçte Group Managed Service Account (gMSA) kullanımını anlatacağım. Umarım siz de bu adımları kendi yapınızda uygularken yol gösterici bulursunuz.

Kurulum yaptığım ortamda bir adet domain controller’ım (M3gDC01 – 10.10.10.10), iki SQL sunucum (M3gSQL01 – 10.10.10.101 ve M3gSQL02 – 10.10.10.102), bir failover cluster IP’si (M3gSQLCLS – 10.10.10.100) ve bir sql listener IP’si (M3gSQLLSN – 10.10.10.105) bulunuyor. Tüm sunucular aynı domain’e katılmış durumda ve Windows Server 2022 kullanıyorlar. Sunucuların tüm update’leri alarak domaine katılmış olmasına özen gösteriniz.

DC

Sql01

Sql02

 

İlk olarak, SqlAdmin adında bir domain kullanıcısı ve SQLAdmins adında bir security group tanımladım. Daha sonra kurulum vs işlemleri yapabilsin diye SqlAdmin kullanıcısını SQLAdmins grubunun üyesi yaptım. SQLAdmins grubunu da, SQL sunucular üzerinde builtin local administrators grubuna GPO ile ekledim. Bir diğer ayarım ise failover ve always on kurulumu yaparken herhangi bir engele takılmamak adına GPO üzerinden firewall disable işlemleri idi.

 

Öncelikle gMSA hesabı kullanacağım için domain tarafında bazı hazırlıklar yapmamız gerekiyor. gMSA hesabı şifresini Active Directory kendisi yönettiği için, önce domain controller üzerinde bir KDS (Key Distribution Service) root key oluşturmamız gerekiyor. Bunu M3gDC01 üzerinde aşağıdaki PowerShell komutuyla yapabiliriz:

Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Normalde bu anahtarın aktif hale gelmesi için 10 saat beklemek gerekir ama test ortamı olduğu için ben “geçmiş saatli” oluşturma yoluna gittim. (Prod ortamında bu komutu kullanmanız kesinlikle önerilmez. Prod ortamında Add-KdsRootKey – EffectiveImmediately komutunu çalıştırdıktan sonra 10 saat kadar yayılmasını beklemelisiniz.) Sonrasında, gMSA hesabını sadece SQL sunucularımın kullanmasını istediğim için, Active Directory’de “SQLServers” adında bir global security group oluşturup, içine M3gSQL01$ ve M3gSQL02$ makinelerini ekliyorum:

New-ADGroup -Name SQLServers -GroupScope Global -Path “OU=Groups,DC=m3g,DC=local”

Add-ADGroupMember -Identity SQLServers -Members M3gSQL01$, M3gSQL02$

Şimdi sıra geldi gMSA hesabını oluşturmaya. gMSA hesabımın adı “gmsaSQL” olacak şekilde şu komutla hesabı oluşturuyorum:

New-ADServiceAccount -Name gmsaSQL -DNSHostName gmsaSQL.m3g.local -PrincipalsAllowedToRetrieveManagedPassword SQLServers -KerberosEncryptionType AES256, AES128

Hesap Active Directory Users and Computers altındaki ilgili OU’da oluşturulmuş gözükmektedir.

Sonrasında her iki SQL sunucusunda da bu hesabı yüklememiz ve test etmemiz gerekiyor. Aşağıdaki işlemleri sırasıyla M3gSQL01 ve M3gSQL02 sunucuları üzerinde uyguluyoruz:

Install-ADServiceAccount -Identity gmsaSQL

Test-ADServiceAccount gmsaSQL

Her iki test de başarılıysa artık SQL Server servislerini bu hesapla çalıştırabiliriz. SQL Server kurulum adımlarını tamamlarken/tamamladıktan sonra bu hesabı servislerde aktif edeceğiz.

• Install-ADServiceAccount -Identity gmsaSQL komutunu çalıştırıken hata alabilirsiniz. Komutu SQL sunucularda çalıştırabilmeniz için makinenin Active Directory komutlarını anlıyor olması gerekiyor. Bunun için windows feature’lardan Active Directory module for Windows Powershell özelliğini yüklüyoruz.

Bunu yüklemek için ise SQL sunucuları üzerinde:

1. Install-WindowsFeature -Name "RSAT-AD-PowerShell" -IncludeAllSubFeature

Komutunu çalıştırabilirsiniz. Ben lab ortamında olduğumdan RSAT-ADDS yükledim siz prod ortamında yukarıdaki komutu kullanabilirsiniz.

• Active Directory module for Windows Powershell özelliği yüklü olmasına rağmen Install-ADServiceAccount komutunda hata alırsanız, (gmsaSQL hesabını kullanacak grup olarak SQLServers grubunu belirtip SQL Sunucuları bu gruba üye yapmıştık hatırlarsanız. Makinelerin ilgili üyelikten gelen yetkileri henüz almadılarsa gmsaSQL hesabını yetkilendirirken ACCESS DENIED hatası alabilirsiniz) makineler üzerinde restart/relogon işlemleri uygulayarak ilgili grup yetkilerini almasını hızlandırabilirsiniz.

Artık Failover-Cluster kurulumuna geçebiliriz. Peki Neden? Çünkü Always On, WSFC altyapısını kullanır. Bu, node’lar arası iletişimi ve quorum yönetimini sağlar. Her iki SQL sunucusunda da aşağıdaki komutu çalıştırabiliriz.

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

Microsoft, kümeye dahil etmeden önce tüm donanım ve yazılımın uyumluluğunun kontrol edilmesini önerir. Bu sebeple SQL sunucularının herhangi birinde;

Failover Cluster Manager konsolu üzerinden Validate Configuration tıklanarak Tüm testleri çalıştır seçeneği ile ortamımızdaki SQL sunucuları kümeye dahil etmeden önce uygunluğunu test etmiş olacağız.

Açılan pencerede Next ile ilerledikten sonra ikinci pencerede Browse butonundan SQL sunucularımızı ekleyerek devam ediyoruz.

Run all tests (recommended) seçimi ile devam ediyoruz.

Testler yapılırken çayımızı alıp arkamıza yaslanarak bitmesini bekliyoruz.

Test sonuçlarını görmek için gelen ekrandaki View Report… butonunu tıklayabilirsiniz. Ekranda html formatında bir rapor göreceksiniz. Herhangi bir hata almadıysanız devam edebilirsiniz.

• (Eğer yetki sorunu, delegasyon gibi sorunlar var ise, domainde cluster ismi ile disabled bir Computer Objesi oluşturularak security permissionlarında SQLAdmins kullanıcısına/grubuna Full Control verilerek aşağıdaki komut çalıştırılabilinir.)

New-Cluster -Name M3gSQLCLS -Node m3gSQL01,m3gSQL02 -StaticAddress 10.10.10.100

Failover Cluster kurulumu başarıyla tamamlandı.

Her iki SQL sunucunun Failover Cluster Manager konsolundan da cluster’ınızı görebilirsiniz. SQL Always On, bu cluster yapısını temel alarak node’lar arası failover yapar.

Active Directory tarafında da kurduğumuz cluster için hem dns kaydımızı hem Computer Account objemizi görebiliriz.

Failover Cluster kurulumu başarıyla tamamlandığına göre artık clusterımızın Quorum ayarlarını yapabiliriz.

Failover cluster sistemlerinde quorum, cluster’ın çalışmaya devam edebilmesi için gereken minimum oy sayısını ifade eder. Her node bir oy hakkına sahiptir ve cluster’ın sağlıklı çalıştığını kabul etmesi için toplam oyların yarısından fazlasına sahip olması gerekir. Yani örneğin iki node’lu bir sistemde bir node giderse, sistem hangisinin çalışmaya devam edeceğine karar veremez. İşte burada File Share Witness devreye girer. Basit bir paylaşılan klasör üzerinden oy hakkı tanımlayarak üçüncü bir taraf gibi davranır ve node’ların çoğunluğu elde etmesine yardımcı olur. Ben de bu yapıda domain controller olan M3gDC01 üzerinde bir file share oluşturdum (örneğin: \\m3gdc01\ClusterQuorum) ve bunu cluster’a tanımladım. Böylece cluster quorum modeli “Node and File Share Majority” olarak yapılandırılmış oldu.

Quorum yapılandırma ekranında Failover Cluster Manager bize birkaç seçenek daha sunar:

• Disk Witness: Ortak erişilebilir bir diski quorum tanığı olarak kullanır. Daha çok shared storage (paylaşımlı disk) kullanılan yapılarda tercih edilir.
• File Share Witness: Yukarıda kullandığımız gibi, erişilebilir bir klasörü tanık olarak kullanır. Özellikle küçük yapılarda ve 2 node’lu mimarilerde en çok önerilen modeldir.
• Cloud Witness: Azure üzerinde bir blob storage tanığı kullanır. Hibrit yapılarda ya da tüm sunucular bulutta değilse bile en az bir Azure bağlantısı varsa mantıklıdır.
• Do Not Configure a Witness: Hiçbir tanık kullanmamak anlamına gelir. Ancak bu durumda cluster’ın quorum kaybıyla çökme riski daha fazladır. Genellikle önerilmez.

Her yapının ihtiyacı farklıdır ama benim gibi 2 node’lu bir yapıda ve LAB ortmaında çalışıyorsanız “File Share Witness” hem basit hem güvenilir bir tercih oluyor.

Failover Cluster kurulumu bittikten sonra sıra geldi Always On Availability Group’u oluşturmaya. Eğer SQL kurulumlarınız var ise kurulum ekranlarını atlayarak Always On Availability Group oluşturma ksımına ilerleyebilirsiniz.

Öncelilkle her iki SQL sunucusuna Microsoft SQL Server kurulumlarını yapıyoruz. Bu kurulumu daha önce de yapmış olabilirsiniz. Ben tüm yapımı hali hazırda sıfırdan oluşturduğum için failover cluster yapılandırmasını SQL’den önce kurmayı tercih ettim. SQL Server 2022 kurulum adımlarını aşağıdaki gibi takip edebilirsiniz. Always on kurabilmek için gerekli olan sql sürümlerini Editions and supported features of SQL Server 2022 – SQL Server | Microsoft Learn linkinden kontrol edebilirsiniz.

• SQL Server kurulum adımlarında sadece değişiklik yaptığım ekranları paylaşıyor olacağım.

Sql Features ksımından aşağıdaki gibi özellikleri seçerek devam ediyorum.

Default instance seçeneğini seçerek devam ediyor ve aşağıdaki gibi servisleri çalıştıracak hesaplara daha önce oluşturduğum gmsaSQL$ hesabını tanımlıyorum.

(Burayı olduğu gibi bırakıp ilerlerseniz daha sonra services.msc konsolu üzerinden ulaşacağınız servis üzerinde Logon sekmesinde yine yetkili hesabı değiştirebilirsiniz. Aynı işlemi SQL Server Configuration Manager konsolu üzerinde SQL Server Services altındaki SQL Server (MSSQLSERVER) servisinin özelliklerinden de ayarlayabilirsiniz.)

Bir sonraki adımda SA şifresi belirleyip, prod ortamında sunucuya erişim yapabilsinler diye daha önce oluşturduğumuz SQLAdmins grubunu giriş yapabilen yetkili hesaplara ekliyoruz.

Eğer prod ortamınızda isterler, Data diski ayrı Log diski ayrı kurulum yapılması şeklinde ise; bunu bu ekrandaki sekmelerden değiştirmeniz gerekmektedir.

---

Ben herhangi bir değişiklik yapmadan devam diyerek kurulumu tamamlıyorum. Diğer SQL sunucusunda da aynı şekilde kurulumları tamamlıyorum.

Her iki SQL Server üzerinde SQL Server Configuration Manager’a girip, SQL Server ve SQL Agent servislerinin logon hesabının “m3g\gmsaSQL$” olduğundan emin oluyoruz. Eğer kurulum esnasında belirtmediyseniz gmsaSQL$ hesabının atamasını yapabilirsiniz. Şifre alanını boş bırakıyoruz çünkü gMSA zaten şifreyi kendisi yönetiyor.

Ardından Always On özelliğini aktifleştirmek için SQL Server Configuration Manager’da her iki sunucuda da  “Enable Always On Availability Groups” kutusunu işaretliyorum ve SQL servislerini yeniden başlatıyorum. Bu adım olmazsa Always On sekmesi SSMS’te görünmez.

SQL Server Management Studio vasıtasıyla node’larımızdan herhangi birine bağlanarak bir TESTDB database’i oluşturuyorum.

TESTDB oluştururken Options sekmesinden Recovery model seçeneğinin Full olduğundan emin oluyoruz. (Gereklilik)

Oluşturduğumuz TESTDB’sine sağ tıklayarak Task kısmından Full Backup alıyoruz. (Gereklilik)

Always On High Availability sekmesini genişleterek Availability Groups üzerinde sağ click ile New Availability Group Wizard… seçeneğini seçiyorum ve gelen pencere üzerinde Availability group name yazarak Cluster Type seçeneğini Windows Server Failover Cluster seçiyorum. Database Level Health Detection seçeneğinin seçili olduğundan emin oluyorum.

• Windows Server Failover Cluster (WSFC): En yaygın kullanılan modeldir. Temelinde Windows Server Failover Cluster kullanılarak oluşturulan bir yapıdır. Yüksek erişilebilirlik ve otomatik failover senaryoları için tercih edilir. Bizim senaryomuzda da kullandığımız seçenek budur.
• None (Stand-Alone Availability Group): Cluster gerektirmeyen, failover özelliği olmayan tek bir instance içinde kullanılabilecek bir AG yapısıdır. SQL Server 2017+ ile gelen bu özellik, daha çok geliştirme ve test ortamlarında tercih edilir.
• External: Bu seçenek SQL Server’ı Kubernetes gibi dış bir yönetime sahip platformlarda kullanmak isteyenler içindir. Bu durumda failover gibi kararlar SQL dışındaki sistemler tarafından verilir.

Yine bu ekrandaki checkbox seçeneklerinin anlamları da oldukça önemlidir:

• Database Level Health Detection: Bu kutu işaretlendiğinde, sadece instance değil, veritabanı seviyesindeki sağlık durumu da izlenir. Örneğin veritabanı suspect moda düşerse otomatik failover tetiklenebilir. Yüksek erişilebilirlik için önerilir.
• Per Database DTC Support: Distributed Transaction Coordinator (DTC) kullanan uygulamalar için, her veritabanı için ayrı DTC desteği sağlar. Özellikle finansal sistemler gibi transaction bütünlüğünün kritik olduğu yapılarda kullanılır.

Gelen ekrandan oluşturduğumuz TESTDB database’ini seçerek devam ediyorum.

Always On Availability Group’u oluştururken sihirbazda önemli bir aşama da “Specify Replicas” penceresidir. Bu pencere birkaç sekmeden oluşur ve her biri replikaların nasıl çalışacağını detaylıca yapılandırmamıza olanak tanır. Bu pencerenin detaylarını aşağıdaki gibi özetleyebiliriz.

1. Replicas Sekmesi

Bu sekmede hangi sunucuların AG içinde yer alacağını tanımlarız. Her sunucu için:

• Availability Mode: Synchronous commit (anlık veri eşitleme) ya da Asynchronous commit (gecikmeli eşitleme) seçilebilir.
• Failover Mode: Automatic (sadece synchronous için mümkündür) ya da Manual.
• Readable Secondary: Secondary sunucuya sadece read-only bağlantı yapılmasına izin verilip verilmeyeceğini belirtir. Örneğin raporlama amaçlı kullanımlarda faydalıdır.

2. Endpoints Sekmesi

AG replikaları arasındaki iletişim “Database Mirroring Endpoint” üzerinden gerçekleşir. Bu sekmede her bir sunucunun endpoint URL’si ve port numarası tanımlanır. Genellikle TCP 5022 kullanılır. Eğer özel bir port tanımı yaptıysanız burada kontrol edebiliriz.

3. Backup Preferences Sekmesi

Yedekleme işlemlerinin hangi sunucuda yapılacağını belirlemek için kullanılır. Seçenekler:

• Prefer Secondary: Mümkünse secondary sunucularda backup alınır.
• Secondary Only: Sadece secondary sunucularda backup alınır.
• Primary: Yalnızca primary sunucu backup alır.
• Any Replica: Uygun olan herhangi bir sunucu backup alabilir. Her seçeneğin altında ayrıca “backup priority” sıralaması yapabilirsiniz. Bu, SQL Server’ın hangi node’a öncelik vereceğini belirler.

4. Listener Sekmesi

Bu sekmede uygulamaların AG’ye bağlanmak için kullanacağı Listener adı, portu ve IP bilgileri tanımlanır. Listener, Always On’un sunduğu yüksek erişilebilirlik için en kritik noktalardan biridir. Uygulama hangi node aktif olursa olsun aynı adresle bağlantı kurabilir.

Bu ayarlar doğru yapılandırıldığında, hem veri güvenliği hem de yüksek erişilebilirlik açısından oldukça sağlam bir altyapı kurmuş oluruz.

Bu ekrandaki değişikliklerim aşağıdaki gibidir. Bu değişiklikleri uyguladıktan sonra Next ile devam ediyorum.

Sonraki pencerede Automatic seeding seçeneğini seçerek devam ediyorum.

Gerekli yetkileriniz olması durumunda SQL Listener’a ait Virtual Computer Object’in, Cluster Computer Objesinin olduğu OU içinde oluşmasını bekleriz. DNS üzerinde de m3gSQLLSN kaydımızın oluşması gerekiyor.

Fakat yine yetki sorunu ve delegasyon gibi sorunlar var ise, (Cluster Computer objesinin SQL sunucularının bulunduğu OU’ da delegasyonu) Listener oluşturulurken hata almış olabilirsiniz. Bu durumda SQL Listener’a ait Virtual Computer Object’ ini manuel oluşturarak, security permissionları üzerinde Cluster Computer Account objeniz için (bizim örneğimizde m3gSQLCLS$) full control yetkisi vererek SQL Server Management Studio üzerinde oluşturduğunuz Availability Group Name üzerinde sağ click yaparak Add Listener menusunden tekrar SQL Listener’ınızı ekleyebilirsiniz.

Böylelikle Always on yapılandırmamızı tamamlamış oluyoruz. SQL Server Management Studio üzerinden oluşturduğunuz Availability Group’ a sağ click Failover… tıklaması ile testlerinizi yapabilirsiniz.

 

Görüldüğü üzere m3gSQL01 üzerinde Primary olan TESTDB database’i m3gSQL02 üzerinde Primary durumuna gelmiştir.

 

Edit: Bazı Always On kurulum makalelerinde SQL Configuration Manager üzerinde Named Pipes özelliğini enable ederek kurulum yapılması gerekliliğine dair vurgular gördüm. Peki Named Pipes özelliğini açmaya gerek var mı?

Hayır, SQL Server Always On kurulumu için Named Pipes protokolünün etkin olması zorunlu değildir. Yani disabled durumda olsa bile Always On Availability Groups yapılandırılabilir ve sorunsuz şekilde çalışır.

🔍 Detay:

• SQL Server protokolleri (TCP/IP, Named Pipes, Shared Memory), istemci bağlantılarıyla ilgilidir. Always On AG ise sunucular arası veri replikasyonunu SQL Server’ın kendi iç mekanizmalarıyla (Database Mirroring altyapısı) TCP üzerinden yapar.
• Microsoft’un resmi dökümantasyonunda Always On için yalnızca TCP/IP‘nin etkin olması gerektiği belirtilir.
• Yani Configuration Manager’da:
  • TCP/IP: Enabled ✅
  • Named Pipes: Disabled ❌ (olabilir)

Ancak bazı özel durumlar olabilir:

Ne Zaman Named Pipes Açılır?

• Ortamınızda legacy uygulamalar varsa ve bu uygulamalar SQL’e Named Pipes üzerinden bağlanıyorsa,
• Ya da SQL bağlantısı testleri sırasında SSMS veya bazı scriptler varsayılan olarak Named Pipes kullanıyorsa, (özellikle local bağlantılarda)

o zaman devreye alınabilir.

 

Öneri : Always On için sadece TCP/IP’nin açık olması yeterlidir. Diğer protokoller ortamın özel ihtiyaçlarına göre açılabilir ama Always On’un çalışması için gerekli değildir.

 

Yeni bir yazıda, Always On izleme ve log analizi konularına da girmeyi planlıyorum. Siz de kendi tecrübelerinizi paylaşmak isterseniz yorumlarda buluşalım. Görüşmek üzere!