Anasayfa » Azure’da Yüksek Erişilebilir Active Directory Federation Services 2019 Kurulumu – Bölüm 2

Makaleyi Paylaş

Microsoft Azure

Azure’da Yüksek Erişilebilir Active Directory Federation Services 2019 Kurulumu – Bölüm 2

Network gereksinimleri ve veri tabanı sunucularının kurulumu

Makale serimizin bu kısmında ADFS sunucumuzun veri tabanını barındıracak yüksek erişilebilir bir SQL Server Availaility Group kurulumu ve konfigürasyonu yapacağız. Yüksek erişilebilirliğin büyük bir kısmı birden çok sunucu üzerinde çalışan iş yükleri olsa da bu iş yüklerinin kullandığı servislerin bağlı olduğu domain hesapları da büyük önem teşkil ediyor. Bir SQL veya ADFS servisini, kolaya kaçmak için şifresi sınırsız süreli geçerli bir domain hesabı da kullanabiliriz veya “best practice” yöntemlere baş vurarak Microsoft’un bu iş için geliştirdiği Group Managed Service Account (gMSA) kullanabiliriz. gMSA hesaplarını şifresini sizin yönetmediğiniz servis hesapları olarak düşünebilirsiniz. Şifresi değişmiyor mu, elbette değişiyor fakat bunu siz değil Active Directory hallediyor. Bu hesapların şifresini asla bilmiyorsunuz; sadece kullanmaya yetkili olacak objeleri (Service Principals) belirliyorsunuz.

Her servisi gMSA ile kullanamıyoruz ne yazık ki ve her servisin gMSA’i kullanma şekli de farklı. Mesela SQL Server için bu hesabı önceden AD üzerinde oluşturup SQL sunuculara yetki vermek gerekiyor; fakat ADFS’te şayet kurulumu domain admin yetkili bir kullanıcı ile yaparsanız kurulum anında da oluşturulup konfigüre edilmesini sağlayabiliyorsunuz.

İşimize Azure portalına girip SQL Server için 2 adet sanal makine açmakla başlayalım. Sunucuları kurarken dikkat etmemiz gereken nokta Availability Options kısmında “Availability set” seçip buna bir isim vermemiz. Eğer olurda bunu unutursanız sunucuları tekrar kurmanız gerekiyor, zira Availability set sadece kurulum anında ayarlanabiliyor. Yeni bir Availability set oluşturup sunucunun diğer ayarlarını istediğiniz şekilde yaptıktan sonra devam edebiliriz. 2. SQL sunucuyu kurarken bir önceki kurulumda oluşturduğunuz Availability set’i seçmeyi unutmayın. Zira SQL sunucuların önüne koyacağımız load balancer, Availability set üzerinden sunuculara erişecektir.

Sponsor

Her iki sunucuyu da kurduktan sonra sunucuları AD’ye dahil edelim ve yeniden başlatalım. Sonrasında SQL AlwaysOn AG’nin Listener objesi için kullanacağımız load balancer’ı oluşturalım. Azure panelinde “Create a resource”a tıklayıp load balancer’ı seçelim.

Load balancer tipini “Internal” olarak seçelim ve IP adresini statik olarak ayarlayalım. Sonrasında load balancer’ın oluşturulmasını bekleyelim. Load balancer oluştuktan sonra paneline girelim ve “Backend pools”tan bir backend pool oluşturalım.

Burada sanal makinelerimizi ve bağlı oldukları Ethernet arayüzlerini seçerek kaydedelim. Bu adımdan sonra Health Probe’u seçip bir health probe oluşturalım. Probe port olarak ben 59999’u seçtim. Siz isterseniz farklı bir portu seçebilirsiniz. Probe’un amacı bu port üzerinden arkadaki sunucuların ayakta olup olmadığını kontrol etmek. Probe’dan sonra son olarak “Load Balancing Rule” oluşturuyoruz. Port olarak SQL servisinin varsayılan portu 1433’ü, backend pool’umuzu ve health probe’umuzu seçelim. SQL Server AG Listener konfigürasyonuna özel olarak “Floating IP” seçeneğini açık konuma getirelim ve ayarlarımızı kaydedelim.

SQL Server AlwaysOn AG için Azure network gereksinimleri burada bitiyor. Artık sunucularımızdan birine bağlanıp kurulum ve konfigürasyonlara başlayabiliriz.

SQL servisi için kullanacağımız gMSA’yi normalde domain controller üzerinden oluşturmamız gerekiyor fakat, şayet gerekli yetkiye sahipseniz bunu SQL sunucu üzerinde de yapabilirsiniz. İhtiyacınız olan şey AD Powershell ve bunu da Server Manager’da kurabiliriz.

Ekran görüntüsündeki özelliği kurduktan sonra bir powershell açıp aşağıdaki komutları sırayla çalıştırıyoruz.

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) -Verbose

New-ADServiceAccount sqlsvc -DisplayName “SQLManaged” -DNSHostName sqlsvc.bulutmekani.com

Set-ADServiceAccount sqlsvc -PrincipalsAllowedToRetrieveManagedPassword SQLServers

İkinci komutta kullandığımız DNSHostName parametresi opsiyoneldir. sqlsvc ve SQLManaged, benim hesap isim olarak kullandığım parametrelerdir. PrincipalsAllowedToRetrieveManagedPassword parametresi bu hesabı hangi objelerin kullanmaya yetkisi olduğunu belirler. Bu, bir AD grubu veya bilgisayar/kullanıcı objesi olabilir. Bu hesabı birden çok SQL sunucu kullanacağı için AD’de SQLServers isminde bir grup açtım ve SQL server sunucularını bu grubun üyesi yaptım. Siz kendi ortamınıza göre bu parametreleri değiştirebilirsiniz. Grup üyeliklerinin aktif hale gelmesi için her iki SQL sunucuyu da yeniden başlatmanız gerekli. Bu yeniden başlatma işlemini SQL sunucu kurulumuna başlamadan önce yapmanız gerekiyor, yoksa kurulum sırasında yetki hatası alırsınız.

SQL sunucuları yeniden başlattıktan sonra gMSA yetkisinin aktif hale gelip gelmediğini test etmek için biraz önce AD powershell kurduğumuz sunucuda şu komutu çalıştıralım.

Test-ADServiceAccount sqlsvc | fl

Sonuç “true” olarak dönüyorsa gMSA yetkilendirmesi tamamdır.

AlwaysOn AG için gerekli Failover Cluster rolünü her iki sunucuya da kuralım.

Kurulumdan sonra sunuculardan birinde FC konsolunu açarak Cluster’ımızı oluşturalım.

Cluster üyesi olacak SQL sunucularımızı seçelim, Cluster’ımıza bir isim verelim ve kurulum adımlarını tamamlayalım.

Azure sanal makinelerinde FC kurulumuna özel dipnot:

Normalde Azure’da Windows Server 2016 üzerinde konsol üzerinden bir FC kurmaya çalıştığınızda kurulum sırasında Cluster, IP’sini otomatik olarak DHCP üzerinden almaya çalışır ve genellikle de kurulumu yaptığınız node’un iç IP adresini alır. Siz cluster oluştuktan sonra cluster IP’sini konsoldan elle değiştirip tekrar “online” konuma almanız gerekir. Bu durum sadece Azure sanal makinesi ve Windows Server 2016 (ve öncesi) işletim sistemleri beraber kullanıldığında geçerli olup, Windows Server 2019’da buna gerek kalmamıştır. Windows Server 2019 tabanlı bir Azure sanal makinesinde Failover Cluster oluşturduğunuz zaman AD DNS tarafında Failover Cluster için belirlediğiniz DNS ismi için her bir cluster node’unun IP adresine karşılık gelen birer A kaydı otomatik olarak açılır . Bu özellik Windows Server 2019 ile beraber gelen “Azure-aware clusters” özelliğinin sonucudur. Daha fazla bilgi için aşağıdaki linki inceleyebilirsiniz.

https://docs.microsoft.com/tr-tr/windows-server/failover-clustering/whats-new-in-failover-clustering

Cluster’ımız için bir Quorum Witness oluşturmamız gerekiyor. Burada standart Quorum seçeneklerinden farklı olarak Cloud Witness’i tercih edeceğiz. Bunun için öncelikle Azure’da bir storage account oluşturmamız gerekiyor.

Storage account oluştuktan sonra paneline girip ismini ve “Access keys” altından key1 veya key2 değerini bir kenara not edelim.

Failover Cluster Manager konsolunu açalım. Cluster ismine sağ tıkladıktan sonra “More actions” ve sonrasında “Configure Cluster Quorum Settings” yolunu takip edelim.

“Advanced quorum configuration”ı seçip sonrasında “Configure cloud witness”i seçelim ve önceki adımlarda oluşturduğumuz storage account ismini ve access key’ini girelim.

Cluster’ımız AlwaysOn AG kuruluma başlamak için hazır. Kuruluma başlamadan önce Windows Firewall üzerinde SQL ve AlwaysOn AG için gerekli olan 1433, 5022 ve 59999 portları için bir Inbound Rule oluşturalım:

Artık SQL Server 2017 kurulumuna başlayabiliriz. Test ortamı olduğu için SQL Server’ın bütün özellik setini barındıran ve ücretsiz olarak indirilebilen Developer Edition’ı kuruyoruz.

Database Engine’i işaretleyip kuruluma devam edelim. Server Configuration aşamasında “Service Accounts” kısmına geldiğimizde daha önceden oluşturduğumuz gMSA’yi “SQL Server Agent” ve “SQL Server Database Engine” için kullanalım. AD’ye göz atıp söz konusu hesabı seçtiğimizde herhangi bir parola girmemize gerek kalmadan parolanın otomatikman geldiğini görüyoruz.

Bir sonraki aşamada SQL Server’da “sa” (system administrator) yetkisine sahip olacak kullanıcıları seçelim ve kurulumu başlatalım.

Kurulumu her iki sunucuda da  bitirdikten sonra ilk yapacağımız iş sunucularda SQL Server Configuration Manager’da AlwaysOn AG’yi aktif hale getirmek. Başlat menüsünden ilgili konsolu açalım, SQL Server Services altında SQL Instance’ının üzerine sağ tıklayıp “Properties”e girelim. “AlwaysOn High Availability” sekmesinde “Enable…” kutucuğunu işaretleyelim.

Değişikliğin aktif hale gelmesi için SQL servisini yeniden başlatmanız gerektiği bildirilecektir. Yine aynı pencerede SQL Server’ın üzerine sağ tıkayıp “Restart” diyelim. SQL Server’ı ikinci sunucuya kurduktan sonra da aynı işlemi orada da tekrar edelim.

SQL Server’ımızı yönetmek için node’lardan birine SQL Server Management Studio’yu kuralım. Aşağıdaki adresten ücretsiz olarak indirebilirsiniz.

https://docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-2017

Kurulum bittikten sonra SSMS’i açalım ve SQL servisine bağlanalım. AlwaysOn kurulumu için halihazırda bir veri tabanına ihtiyacımız var. Testi tamamlamak SQL Server’da boş bir veri tabanı açalım ve veri tabanını açtıktan sonra üzerine sağ tıklayalım. Options kısmında Recocery Model’in Full olmasına dikkat edelim.

Ardından bu veri tabanının yedeğini (full backup) alalım. Yedek alma işlemi bittikten sonra AlwaysOn High Availability sekmesinin altından Availability Groups’a tıklayıp New Availability Group’u seçelim ve ilk aşamada AG’mize bir isim verelim.

Veri tabanımız AlwaysOn AG’ye dahil edilmek için gerekli şartları sağlıyor. Devam edelim ve ve Specify Replicas adıma geçelim.

Add Replica butonuna basıp ikinci SQL sunucumuza bağlanalım. Bu pencere Automatic Failover’ı her iki sunucu için de aktif hale getirelim. Availability Mode’da Synchronous commit seçelim ve Readable Secodary’yi “Yes” olarak işaretleyelim.

Listener sekmesinde daha önceden bu işi için oluşturduğumuz Azure Load Balancer’ın IP adresini girelim ve Listener’a bir isim verelim. Port olarak 1433’ü seçelim.

Select Data Synchronization bölümünde Automatic seeding seçip devam edelim ve ilerleyerek AlwaysOn AG kurulumunu bitirelim.

AlwaysOn AG’miz neredeyse hazır. Failover Cluster Manger’ın Azure Load Balancer’dan trafiği SQL Server’a yönlendirebilmesi için cluster’a bunu bir kaynak olarak kaydettirmemiz gerekiyor. Eğer bunu yapmazsak Listener’ımız çalışmayacaktır.

Failover Cluster konsolunu açalım ve Roles sekmesine gelelim. Burada Availibility Group objesinin ismini göreceğiz. Üzerine bir kere tıklayıp aşağıdaki kısımda Resources sekmesine gelelim. Burada Server Name’in altındaki IP Addresss objesine sağ tıklayalım ve Properties’e gelelim.

Properties penceresinde Name kutusunda yazan ifadeyi bir kenara not edelim.

Bir powershell penceresi açalım şu komutu çalıştıralım:

Get-ClusterNetwork

Burada çıkan sonucu bir kenara not edelim. Sonrasında şu komutları sırayla çalıştıralım. Parantez içerisindeki bilgiler açıklamadır:

$ClusterNetworkName = “ClusterNetworkAdı” (Get-ClusterNetwork komutunun sonucu)

$IPResourceName = “IPKaynakAdı” (FC konsolundan not aldığımız kaynak ismi)

$ILBIP = “LoadBalancerIPAdresi”

$ProbePort = “ProbePortu”

Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{“Address”=”$ILBIP”;”ProbePort”=$ProbePort;”SubnetMask”=”255.255.255.255″;”Network”=”$ClusterNetworkName”;”EnableDhcp”=0}

Çıktıları bu şekilde gözükecektir.

SQL AlwaysOn konfigürasyonumuz bitti. Artık AG listener ismi veya IP adresi ile aynı network’teki herhangi bir makineden bağlantı oluşturabiliriz. Makalemizin bir sonraki bölümünde ADFS hizmetinin veri tabanını belirlerken AG Listener ismini kullanacağız.

Bir sonraki bölümde görüşmek üzere.

Makaleyi Paylaş

1 Yorum

  1. Eline sağlık, çok değerli bir makale serisi olmuş.

Cevap bırakın