Always-On Mimarisinde gMSA Hesabı Tanımlama

Always-On Mimarisinde gMSA Hesabı Tanımlama

Bu makalede Always-On mimarisinde SQL Server Engine ve Agent kullanıcı hesaplarının domainde gMSA kullanıcı hesabı olarak değiştirme işlemlerinin yapılması anlatılmıştır.

Step 1: gMSA kullanıcı Tanımlamak için ilk önce tanımlanacak cluster’a bağlı sunucularda server manager kısmında role administration kısmından tanımlama yapılır.

Step 2: Active Directory den gMSATEST (Kullanıcı adı SQL Server Engine üzerinde görüneceğinden bu ad tamamen sizin isteğinize bağlıdır.) kullanıcısı oluşturulur.

Step 3: Active Directory’den aşağıdaki komutla gMSA kullanıcıları için yeni oluşturulacaklar dâhil otomatik SPN yapılması için ayar yapılır.

Step 4: PowerShell üzerinden (Her bir clustera bağlı sunucular üzerinden tek tek yapmaya gerek yok tek birinde yapmamız tüm cluster’a bağlı sunucularda ayar uygulanmakta)

Step 5: Server Manager’dan Role feature’lardan Remote Server Administration altında ad-ds kısmı yüklenir.

True

Yukarıdaki scriptlerden dönüş alınması önemli alınmadığı takdirde;

script ile sunucu isimleri kontrol edilir. Sunucular doğru ise devam edilir (değer olarak 0’lı bir guid Id basacaktır) farklı ise AD Ekibinden değişiklik istenir.

Script Çıktısı Örn.

DistinguishedName : CN=gMSATEST,CN=Managed Service Accounts,DC=intranet,DC=intra

Enabled: True

Name: gMSATEST

ObjectClass: msDS-GroupManagedServiceAccount

ObjectGUID: 2z1c887ep-52a5-4dd2-3125-101s6c8c1453

PasswordLastSet: 07.06.2021 10:58:42 AM

SamAccountName: gMSATEST$

SID: S-8-2-31-2884678545-789615522-620645608-1474186

Step 6: SQL Server Configuration Manager’dan sunucu için servis hesapları değiştirilecektir. Değişim sonrası engine restart edilir.

Step 7: gMSA hesabı oluşturulan Instance’da kullanıcıları oluşturup endpoint ayarı yapılması gerekiyor. (Bu ayar yapılmazsa AlwaysOn endpoint’ler değiştirmeden önce disconnect oluyor);

ALTER AUTHORIZATION ON ENDPOINT:: Hadr_endpoint TO [DomaingMSATEST$];

Step 8: Kullanıcının (Engine Kullanıcısı, bizim Engine Kullanıcımız ‘Domaintestuser’) tüm sahiplikleri kaldırıldıktan sonra aşağıdaki işlemler yapılır.

-1-) Database Owner Change Script; Kullanıcının sahip olduğu tüm database sahiplikleri [sa] olarak değiştirilir.

 

–2-) Database Jobs Change Script; Agent kullanıcısında gMSA yapacağımız için buradaki tüm sahiplikleri [sa] olarak değiştirilir.

 

–3-) Availability Group Sahiplik Scripti; ile eski kullanıcı eğer availability group sahibi ise sahiplikleri değiştirilir.

 

–4-) Schema ve Object Sahiplik Scripti; ile eski kullanıcı eğer schema ve object sahibi ise sahiplikleri değiştirilir. Bu değişikliği loop döngüsünde yapan sistem sp’si ile yapılır.

 

–5-) Login Açık olan Kullanıcı Scripti; aşağıdaki script ile tespit edilip kill edilir.

 

Step 9: Tüm bu işlemler bittikten sonra aşağıdaki adımlar kontrol edilir, varsa değiştirilmesi gereken adımlar değiştirilir.

  • Eski servis kullanıcısın bilgisayarlarda sign off olduğundan emin olunmalı.
  • Alınan Son backup kontrollerinin çalışması için credential hesabının değiştirilmesi ve bu kullanıcı veri tabanlarında sysadmin olarak eklenmeli.
  • Backup Alınan dosyalarda eski servis kullanıcısın yetkisi olduğundan yeni bir folder oluşturulup advance share yaparak. Yeni servis hesabına full control verilmeli ve everyone yetkisi kaldırılmalı.
  • Eski servis hesabının, yeni servis hesabı eklenen sunucuların computer management=>Local User and Groups kısmından kaldırılması.
Benzer Yazılar

SQL SERVER SERViS RESTART HATASI

SQL Server 2 gün önce

Bu haftaki yazımızda karşılan bir hata üzerindeki; logları ve çözümünü anlatacağım. Aşağıdaki GÖRSEL-1’de görüldüğü üzere SQL servisini restart ettiğimiz sırada bir hata ile karşılaşıyoruz. Servis running state’e geçemiyor. “The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details” şeklinde bir uyarı veriyor. Hatanın çözümüne doğru ilerlerken farklı servis hesaplarıyla veya “Local System” hesabı ile restart etmeye çalıştığınızda servis ilginç bir şekilde ayağa kalkıyor. Ancak Always on sistem çalışıyorsanız farklı servis hesaplarını kullandığınızda always on size haberleşme izni vermiyor. Aynı hesabın şifresi ile ilgili sorunlar olduğu düşünüp hesabın şifresini de değiştirdiğiniz de yine sonuç alamıyorsunuz. Burdan yola çıkıldığında sıkıntı servis hesabında gibi görünüyor olabilir ancak çözüme geçildiğinde regedit üzerinde yapacağımız bir işlem ile sorunu çözüyoruz. Servis hesabının kaydının olduğu regedit kaydını siliyoruz. Regedit üzerindeki servis hesap bilgisi güncellendiğinde sorun çözülmüş olmakta. GÖRSEL-1  Servis restart edildiğinde SQL’in verdiği Error […]

SQL’DE İKİ NODE’UN RESOLVING DURUMA DÜŞMESİ VE ÇÖZÜMÜ

SQL Server 3 hafta önce

Bu yazımızda failover olma işlemi esnasında karşılaşılan bir durumdan kısaca bahsedeceğim. Kısa bir yazı olacak ama önemli olduğunu düşünüyorum. Bazen failover olmak istediğinizde cluster secondary’e node’a failover olamaz, hem secondary hem de primary node’unuz resolving durumuna geçer. Bu durumla daha çok otomatik failover olma durumlarında karşılaşılır çünkü sistem failover’a aslında hazır değildir ancak cluster bunu bir şekilde bilemez. Failover olma gerçekleşemez bir anlamda sql cluster askıda kalır ve hiçbir sunucu da sql engine çalışmaya devam edemez. (GÖRSEL-1) GÖRSEL-1 GÖRSEL-1 üzerinde gördüğünüz üzere availability group resolving duruma düşer. Availability replica’lar üzerinde de gördüğünüz üzere primary ve secondary tüm node’lar resolving state’e düşer. Böyle bir durumunda iki farklı çözüm yolumuz var;   Çözüm: ikinci node’a sunucu restart’ı atmak. Bu noktada secondary sql node’a servis restart atmak işe yaramıyor. Zaten db’ler iki taraflı resolving modda. O sebeple ancak sunucu restart atıldığında cluster ayakta olan sunucuyu görüyor ve askıda kalma durumundan ilk başta primary […]

Query Store Nedir?

SQL 4 hafta önce

Query Store ile birlikte execution planın seçimi ve bu sürecin performansa etkisini anlayabiliriz. SQL Server içerisinde bulunan Query Store özelliği, çalıştırılan sorguların execution planını ve bu sırada oluşan istatistiklerini otomatik olarak yakalar. Böylece query plan değişikliği ile oluşan problemleri de hızlı ve kolay şekilde fark edebiliriz. Elinizde bulunan bir sorguya ait query plan zamanla değişebilir. Bunun birçok sebebi vardır. Tablo yapısına yeni bir column eklenmesi Veri tipinin değiştirilmesi Sorgularda yeni parametrelerin eklenip çıkarılması Verilerde, schemalarda veya sorgu parametrelerindeki değişiklik Burada önemli olan ise bazen bu değişimler sorgunun yavaş çalışmasına neden olur. Query Store ile beraber bu yavaşlığın kök nedenine inmek daha kolay oldu. Ayrıca query store sayesinde ilgili sorguya ait read-write bilgileri ve cpu tüketimi bilgilerine de erişebilirsiniz. Query Store’u veritabanı seviyesinde aktif edebiliyoruz. Veritabanı üzerine sağ tıklayarak properties diyoruz ve Query Store sekmesine geliyoruz. Operation Mode alanından Read Write’ı seçiyoruz. Böylelikle Query Store gerekli bilgiyi toplayabilir ve size ilgili sonuçları […]

0 Yorum

Yorum Yaz

Rastgele