Azure RDS Deep Dive – Bölüm 13 Availability Set and VM Size Change
Azure RDS Deep Dive makale serimizin ilk bölümü olan Part 1 Topology Overview bölümünde Azure üzerinde barınan RDS sunucularının avantajlarını aktarmış, yatay büyüme ve dikey büyüme arasındaki farklardan bahsetmiş ve makale serimizin bu bölümüne kadar olan bölümde RDGW ve RDWA sunucu rollerinin yatay büyüme işlemlerini gerçekleştirmiştik.
Bu makalemiz içinde RDS sunucularımız için dikey büyüme işlemini, Availability Set tanımını ve sonraki makalede Cloud Services Scale işlemlerini yerine getireceğiz.
Oluşturmuş olduğumuz azcld-01 isimli cloud servisi üzerinde Scale işlemlerini yapabilmemiz için öncelikli olarak bir AVAİLABİLİTY SET’ e ihtiyacımız bulunmaktadır. Bu yapılandırma olmadan Scale işlemlerini yerine getirememekteyiz.
Cloud Services içinde Instance bölümüne gittiğimiz zaman cloud servisi içinde bulunan sanal makinelerimizi ve sahip oldukları Size boyutları görebilmekteyiz.
Örnek senaryomuzda azcld-rdgwa isimli sunucularımız Standart D3 Seize’sine sahip durumda ve mevcut kaynaklar ihtiyaçlarımızı karşılamamaktadır.
Kaynaklarını artırıp, Size sınıfını değiştireceğimiz sanal sunucuya tıkladığımız zaman sanal sunucumuzun içine gidiyoruz ve Configure kısmından Virtual Machine Size bölümüyle ihtiyaç duymuş olduğumuz size arttırma işlemini yerine getiriyoruz.
Bu işlem sunucunun barındığı data centera bağlı olarak 5 dk ve biraz daha uzun süre almaktadır. Sonrasında sanal sunucu yeniden başlatılacak ve seçmiş olduğumuz yeni size ile hizmet etmeye devam edecektir.
Bu işlem yeniden başlatma ile son bulduğu için sanal sunucunun hizmet etmediği zaman dilimlerini seçmenizi önermekteyim.
Size değiştirme işlemi başarılı bir şekilde tamamlandıktan sonra sanal sunucumuz yeniden açılacak ve hizmet etmeye devam edecektir.
İlk makalemiz içinde bahsetmiş olduğumuz dikey büyüme operasyonu bu makale içinde yaptığımız gibi 5 dakikalık bir operasyondur ve bu işlemden sanal sunucunun işletim sistemi ve işletim sistemi bileşenleleri, yapılandırmamız vb… hiç bir bileşen etkilenmemektedir.
Dikey büyüme işleminden sonra azcld-rdgwa sunucularım için bir Availablity Set oluşturacağım. İşlemi gerçekleştirecek olduğum azcld-rdgwa01 isimli sunucumun içine girip, Configure bölümüne gidiyorum ve Availablity Set bölümünde Create an Availablity Set kutusunu seçiyorum. Yan tarafta açılacak olan bölüme oluşturulacak olan Availablity Set’ in ismini yani azcld-rdgwa ismini veriyorum.
Availablity Set oluşturma işlemi 5 dakika gibi bir sürede oluşmuş olacaktır.
Availablity Set oluşturkan sonra sunucumuz üzerinde Availablity Set bölümünde oluşturmuş olduğumuz Availablity Set ismi ve üyesi olarak eklediğimiz, işlemleri gerçekleştirdiğimiz azure sanal sunucumuzu azcld-rdgwa01 görmekteyiz.
Sunucumuzu bir Availablity Set kümesini üyesi olduktan sonra portal üzerinde bu sunucumuz için önemli bir uyarı oluşmaktadır.
The availability set for this virtual machine has only one running instance, which affects the service level agreement (SLA). The SLA requires at least two running virtual machine instances. Learn more
İlk makalemizde Azure SLA kuralları ve Best Efor ‘ dan özet olarak bahsetmiştik. Tekrar hatırlatmakta fayda var. Eğer bir Azure Sanal sunucsu availability set olarak yapılandırılmazsa bu sunucu için SLA süresi bulunmamaktadır. Bu sanal sunucu için Microsoft Best Efor uygulayacaktır ve bu efor için bir süre bulunmamaktadır! Microsoft’ un taahüt etmiş olduğu 99.95% Azure Sanal Sunucu SLA süresinden yararlanabilmemiz için bir Availablity Set oluşturmamız gerekmektedir.
Availablity Set oluşturmamız ile bereber portal üzerinde Important uyarısınız almaktayız. Almış olduğumuz uyarının nedeni ise Availablity Set oluşturduk ama oluşturmuş olduğumuz bu Availablity Set içinde sadece tek bir tane sunucu bulunmaktadır. Bu sebepten ötürü ikinci sunucumuzu eklememiz gerektiğinin uyarısı yapılmaktadır.
Oluşturmuş olduğumuz azcld-rdgwa isimli Availablity Set içine azcld-rdgwa02 isimli azure sanal sunucumuzu ekleyebilmek için azcld-rdgwa02 isimli sunucumuzun içine giriyoruz ve configurasyon bölümüne gidip Availablity Set bölümünde oluşturmuş olduğumuz azcld-rdgwa isimli Availablity Set’i seçiyoruz ve işlemi onaylıyoruz.
Bu işlem daha önce bahsettiğimiz gibi 5 dakika gibi bir süre içinde tamamlanacaktır.
İşlem tamamlandıktan sonra oluşturmuş olduğumuz azcld-rdgwa isimli Availablity Set ‘ in üyesi iki tane sunucumuz yani azcld-rdgwa01 ve azcld-rdgwa02 sunuculrımız eklenmiş oldu ve portalımız üzerinde bulunan Important uyarısı gitmiş oldu.
Oluşturmuş olduğumuz bu Availablity Set nasıl çalışmaktadır.
Availablity Set üyesi yapmış olduğumuz bu sanal sunucular, aynı datacenter içinde fakat farklı rack kabinlerinin içinde bulunmaktadır ve böylelikle kabin, güç beslemesi, storage, network vb… bütün bileşenleri farklı kabinler içinde dağılmaktadırlar. Availablity Set ile sunucularımızı farklı fiziksel bağlantılar ile desteklemiş olduk.
Şimdi çalışma mantığını konuşalım. Yaşayacak olduğumuz kesintiler Planlı Kesinti ve Plansız kesintiler olarak ayrılmaktadır. Microsoft azure tarafında bu terimler Update Domain (UD) ve Fault Domain (FD) olmak üzere isimlendirilmektedir.
Update Domain (UD) demiş olduğumuz azure sanal sunucularımızın barınmış olduğu fiziksel kabinlerdir. Çalışma mantığı, Azure sanal sunucularımızın ihtiyaç duymuş olduğu güncelleştirmelerinin yükleneceği domain içindeki sunuculardır.
Hemen-Hemen her kritik güncelleştirme, açık kapatma işlemleri, yeniden başlatma ile son bulduğu için biz bunlara planlı kesinti demekteyiz.
Eğer azure sanal sunucularımız Availablity Set olarak yapılandırılmazsak, Microsoft tarafında bu sunucular kritik sunucu değildir olarak işaretleniyor ve herhangi bir sıralamaya bakılmaksızın günceleştirmeleri yükleniyor ve açıkları kapatılıyor. Bu işlem sonrasında bir yeniden başlatma olduğu için işlem planlanmış bir kesinti ile son buluyor.
Microsoft’ un Availablity Set yapılandırılmamış sunucular için vermiş olduğu taahüt best efor demiştik. Best efor’un uygulanması verilen taahüt’ ün açıklaması “Güncelelleştirmeyi en kısa zaman ve en problemsiz şekilde gerçekleştireceğiz” yasal bağlayıcı bir süre bulunmamaktadır. Hata durumunda ise en kısa zamanda gidereceğiz.
Eğer bu sunucularımızı Availablity Set olarak yapılandırırsak Microsoft bu işlemi nasıl gerçekleştiriyor. Güncelleştirme ve açıkların kapatılacağı zaman, bu işlemleri yapmadan önce sunucuların Availablity Set kontrolünü gerçekleştiriyor. Eğer sunucular üzerinde Availablity Set ayarı yapılandırıldıysa Microsoft bu sunucuların iş kritik bir sunucu olarak işaretliyor ve güncelleştirme işleminden önce bu sunucuları farklı Update Domainler (farklı kabinler) içine canlı olarak aktarıyor. Senaryomuzda Availablity Set içinde bulunan sunuculardan bir tanesi UD1 içinde diğeri ise UD2 içinde barınıyor. Microsoft öncelikli olarak UD1’ i güncelleştiriyor, yamaları geçiyor, açıkları kapatıyor ve bütün işlemlerin testlerini gerçekleştirdikten sonra, işlemler başarılı olduktan sonra UD2’ nin güncelleştirme işlemlerine başlıyor. Ve böylelikle bizler sıfır kesinti yaşıyoruz. Eğer olası bir kesinti yaşarsak, Microsot’ un bize taahüt etmiş olduğu Azure Sanal Sunucu SLA sözleşmesini devreye alma hakkımız bulunuyor.
Fault Domain (FD) demiş olduğumuz azure sanal sunucularımızın barınmış olduğu fiziksel kabinlerdir. Availablity Set olarak yapılandırmış olduğumuz sanal sunucularımız aynı datacenter içinde bulunsalar bile hiç bir zaman için aynı rack kabin içinde barınmayacaklardır. Ve yaşanılması muhtemel herhangi bir kabin probleminde (güç kesintisi, fiziksel sunucunun işlemci, ram vb… hatası, network, storage problemleri vb…) azure sanal sunucularımız farklı rack kabinetler içinde bulunduğu için bir hizmet kesintisi yaşamıyoruz.
Availablity Set yapılandırmasını, Azure Load Balancer ile birlikte birleştirdiğimiz zaman en üst seviyede iş sürekliliğini sağlamış olmaktayız. Availablity Set ve Azure Load Balancer yapılandırılmış bir sanal sunucularımız, planlı bir kesinti veya plansız bir kesinti durumunda hiç bir zaman için hatalı durumdaki sanal sunucuya istekleri göndermemektedir.
Cloud services içine Instance bölümünü kontrol ettiğimiz zaman Availablity Set üyesi olarak seçmiş olduğumuz sanal sunucularımızın Update Domain ve Fault Domain olarak yapılandırıldığını görebilmekteyiz.
