Load Balancer yani yük dengeleyici basitçe özetlemek gerekirse birden fazla kaynağın arasında iş yüklerinin dağıtımı olarak ifade edebiliriz. Kaynakların kullanımı iyileştirmek , yanıt sürelerini aşağıya çekebilmek ve tek bir kaynak üzerine aşırı yük bindirmekten ziyade yüklerin dağılımını yapmamızı sağlayan bir araçtır.
Azure Load Balancer ailesi aslında dört farklı yük dengeleyeci olarak kendine yer bulur. Aslında bunu yine iki boyutlu olarak değerlendirmek gerekmektedir. HTTP(S) ve HTTP(S) olmayanlar şeklinde. Azure üzerinde bahsettiğimiz yük dengeleme seçeneklerinin tamamı yazılım tabanlıdır.
Azure Load Balancer bir veya daha fazla ön uç public ya da private IP adresleri ile istekleri karşılar. Aslında bizlerin hizmet verecek olan ve isteklerin karşılanacağı bir yüze sahiptir. Backend Pool olarak isimlendirilen yani arka tarafta aynı hizmeti vermek üzere birebir aynı konfigürasyonlara sahip sunucular ya da uygulama servisleri olarak yapılandırılmış havuzumuz mevcuttur.
Azure Load Balancer arkasında yani backend tarafımıza bakan uçlarımızda Sağlık (Health) proplar bulunur. Bu problarımız arka havuzumuzda hizmet veren sunucular ya da uygulamalarımızın erişilebilirlik durumlarını kontrol eder. Eğer ki bir sorun var ise hizmet noktasında erişimi problemli olan uçlara yönlendirme işlemini gerçekleştirmez.
Bunların dışında, Azure Load Balancer kurallarımızı içeren bileşenleri de mevcuttur. Bu kurallarımız ise karşıladığımız istekleri yani hangi tür trafiğin karşılanacağını ve karşılanan bu trafiğin yönlendirilmesi gibi kuralları ifade eder.
Bu noktada eğer ki bir web havuzumuza yük dengeleme yapıyor isek bu son derece kolay anlaşılabilecek ve yaygın bir kullanımı olan senaryodur. Çünkü bizler biliyoruz ki 80 veya 443 numaralı portlarla web hizmet veririz.
Azure Load Balancer üzerinde Inbound Nat Rules ve Snat kuralları da desteklenmektedir. İşte bu noktada bir web yük dengeleyicinin dışında kalan ve son derece önemli olan faydalarından rahatlıkla bahsedebiliriz.
Azure Load Balancer frontend tarafında bulunan public veya private IP adresine erişimlerin karşılandığı yer olduğundan bahsetmiştik. Gelen bu isteklerde backend tarafındaki sunucular ya da uygulamalara yönlendirildiğini de biliyoruz. Bu yönlendirmeler yani stickiness’ler ne şekilde çalışır birazda bunlara değinelim.
Diyagramda da göreceğiniz üzere Azure Load Balancer Layer 4 katmanında çalışır ve Hash Based olarak gelen istekleri yönlendirir. Varsayılan olarak yük dağılımını da 5 farklı (Tuple) tanımlama grubuna göre gerçekleştirir.
- Source IP
- Source Port
- Destination IP
- Destination Port
- Protocol
Bu yük dağıtım modeli varsayılan olarak böyledir. Peki bu başlıklarda bulunan yöntemlerin dışında custom olarak belirlemek istiyor isek, Azure Load Balancer buna da izin vermektedir. Powershell komutları ile bahsettiğimiz metotları rahatlıkla değiştirebiliriz.
Bunlar aslında bizlerin iş ihtiyaçlarına göre farklılıklar gösterebilir ve farklı yük dengeleme metotlarına duyacağımız ihtiyaç ile ilgilidir.
Örnek vermek gerekirse Source IP Affinity iki kontrol noktasını içerir. Source IP adresi ve Destination IP olacak şekildedir. Ve bizler buna özel tanımlamalar yapabiliriz. Vermiş olduğum Source IP Affinity olarak kullanım amacımız genelde Azure üzerinde RDS Gateway için yapılandırılması önerilen bir dağıtım metodur.
Azure Load Balancer Standart SKU;
Standart Azure Load Balancer, Basic Azure Load Balancer üzerinde genişletilmiş ve daha detaylı özellikleri barındırır. Özellik olarak aralarında benzerlikler olsa da yetenekleri ve desteklediği yapılar özelinde farklılıklar mevcuttur. Bu sebeple eğer bir yapılandırma yapılacak ise öncelikle iş ihtiyaçları belirlenmeli ve bu ihtiyaçlara göre Azure Load Balancer SKU’ların seçimi yapılmalıdır.
Yukarıdaki görselde Temel farklıkları görebilirsiniz. Eğer daha detaylı görmek isterseniz aşağıda bulunan link üzerinden farkları ve sınırlandırmaları inceleyebilirsiniz.
https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview
Azure Internal Load Balancer
Azure Internal Load Balancer hangi amaçla ve sebeple kullanıldığından bahsetmek gerekirse bizlerin public tarafta yer alan uçlardan gelen istekleri aldığımızı ve uygulama havuzumuza gönderdiğimizi biliyoruz. Fakat uygulamalarımız veri tabanı kullanımının olduğunu ve güvenlik adına da aynı network üzerinde tutmak istemeyebiliriz. Böyle bir yapıda aşağıdaki diyagramda da göreceğiniz üzere Database network arka tarafta Internal Azure Load Balancer arkasına alabiliriz. Bu yapı bizlere ekstra güvenlik sağlayacağı gibi network olarak da arka tarafta bulunan SQL sunucularımızın da erişilebilirliğini artıracak bir yapıdır.
Azure Internal Load Balancer için kullanım alanları ile örneklemeye devam edecek olursak. Azure üzerinde bütün işlerini ya da Yukarıdaki diyagram özelinde Azure Load Balancer ve Azure Internal Load Balancer kullanarak güvenlik seviyesini her ne kadar yukarı çektiğimizi söyleyecek olsak da bilinmesi gerekir ki Load Balancer bir güvenlik duvarı değildir.
Şimdi artık senaryomuzu oluşturmaya ve dağıtım işlemlerine başlayalım.
Yukarıdaki diyagram da göreceğimiz üzere bir adet Public Azure Load Balancer ve arka havuzumuzda bulunan sanal sunucularımız üzerinde IIS rolünün yapılandırıldığı bir sunucu havuzu bulunmakta.
Senaryonumuz ise bilindik ve kolayca yapılandırabileceğimiz 80 portuna gelen isteklerin yine arka havuzumuzda bulunan sanal sunucularımız üzerinde yük dağılımının gerçekleştirilmesi. Bununla birlikte yine daha önce belirttiğimiz NAT kurallarını oluşturmak olacak. NAT kuralı olarak da yine hızlı olması açısından Remote Desktop Protokolü (3389) NAT kuralı oluşturacak ve uygulayacağız.
Burada önemli bir detay paylaşmak istiyorum. Bizler bu senaryoyu oluşturmak için arka havuzumuzda bulunan sanal sunucularımızın oluşturulduğunu varsayarak devam edeceğiz. Arka havuzumuzda bulunan sunucularımızın da bir Azure Availability Sets grupları içerisinde yer aldığını bilmeniz gerekmektedir. Dolayısı ile sizler eğer mevcut ortamınızda Azure Load Balancer için bir planlamaya gidecekseniz ve daha önce oluşturmuş olduğunuz sanal sunucular bir Availability Sets grupları içerisinde değil ise burada yönlendirmeleri yapamayabilirsiniz.
Böyle bir durum var ise Azure üzerinde ne yazık ki daha önce oluşturulmuş olan ve servis veren sunucularımızı Azure Portal üzerinde sonradan Availability Sets gruplarına almanıza imkân sağlamamaktadır.
Böyle bir durum var ise aşağıda paylaştığım Powershell komut setleri ile bu işlemi gerçekleştirebilir ve oluşturmuş olduğumuz Azure Availability Sets grupları altına bu sunucularımızı tanımlayabiliriz.
Bunun için öncelikle galeriden ilgili komut setini import ederek işleme başlıyoruz.
Install-Module AzureRm.AvailabilitySetManagement
Bu adımdan sonra aşağıdaki komut seti ile hesabımıza bağlanıyor ve giriş yapıyoruz.
Add-AzureRmAccount
Bu adımdan sonra Azure SubscriptionID ‘ye ihtiyaç duyacağız. Azure SubscriptionID alabilmek için aşağıdaki komut setini çalıştırıyoruz. Komut çıktısı olarak SubscriptionID numarasını alıyoruz.
Get-AzureRmSubscription | fl
Bir sonraki adımımızda almış olduğumuz ID numarasını aşağıda belirttiğim komut seti içerisinde kullanıyoruz.
Select-AzureRmSubscription -SubscriptionID “your subscription ID”
Aşağıda göreceğiniz komut seti yeni bir Azure Availability Set oluşturmak için kullanacağımız bir komut seti. Eğer ki sizler bunu Azure Portal üzerinden oluşturduysanız bu komut setine ihtiyacınız bulunmamaktadır.
New-AzureRmAvailabilitySet -Location “West Europe” -Name “CPAvailabilityGroup” -ResourceGroupName “CPLoadB” -Sku aligned -PlatformFaultDomainCount 3 -PlatformUpdateDomainCount 3
Bir önceki komut setimiz ile Availability Set grubumuzu oluşturmuş olduk. Bundan sonra mevcut durumda olan sunucularımızı , bir önce ki adımda oluşturmuş olduğumuz grup içerisine dahil edeceğiz. Bunun için aşağıda belirtilen komut setleri ile ilerleyeceğiz.
Add-AzureRmAvSetVmToAvailabilitySet -ResourceGroupName “CPLoadB” -VMName “Sunucu İsmi” -OsType windows -AvailabilitySet “CPAvailabilityGroup”
Yukarıdaki komut setimizi ilk başta oluşturmuş olduğumuz Azure Availability Set grubuna kaç adet Azure sanal sunucumuzu ekleyecek isek ona göre çalıştırmamız gerekmektedir. Ben bu grubu oluştururken üyesinin üç tane olacağını tanımladım. Sizler daha fazla sunucu ile hizmet verecek ve havuzunuza ekleyecekseniz ona göre komut setini düzenlemeniz gerekmektedir.
Bu noktada en önemli detay buradaki komut setlerinizi çalıştırdıktan sonra, yürütülen komut öncelikle sanal sunucunuzun Disk olarak çıktısını alır ve mevcut sunucumuzu ortamdan kaldırır. Daha sonra tekrardan dışarıya Template olarak çıkardığı diskimizden yeniden sanal sunucu oluşturur. Bu işlemi yaparken sunucumuz zarar görmez. Oluşturulan yeni sunucu Azure Availability Sets grubu içerisinde dahil eder. Fakat sizler bu sunucular üzerinde herhangi bir şekilde veya ihtiyaç duyduğunuz herhangi bir extension’u Marketplace üzerinden ya da Azure Policy ile aktifleştirdiyseniz Availability Group içerisinde aldıktan sonra aktif hale getiremez. Dolayısı ile daha önce herhangi bir eklenti konfigürasyonu yapmışsanız bunu yeniden konfigüre etmeniz gerekmektedir.
Buraya kadar hepimizin aynı noktada olduğunu düşünerek artık Azure Load Balancer dağıtımını bir sonraki makalemiz de gerçekleştirebiliriz.