Azure RDS Deep Dive – Bölüm 18 Extended RDS Deployment Test Procedure

Bir makale serimizin daha son bölümündeyiz. Bu makalemiz içinde Part 18 Extended RDS Deployment Test Procedure bölümlerinde Azure üzerinde bulunan RDS ortamımzın çalışmasını, Cloud seviyesinde yüksek erişilebilirliğini ve disaster seviyesinde iş süreklilik aşamalarını inceleyeceğiz ve testlerini gerçekleştireceğiz.

Öncelikli olarak ilk önce RDS Ortamımız içinde bulunan Cloud servislerini hatırlayalım. Makale serimiz içinde yapılandırmış olduğumuz iki farklı Cloud servisi ve bu cloud servisleri içinde bulunan RDS sunucularımızı hatırlayalım. Status bölümünde baktığımız zaman her iki cloud servisimizin Online olduğunu yani cloud’ umuz içinde bulunan sunucularımızın erişilebilir olduğunu görebilmekteyiz. Bütün RDS Sunucularımız problemsiz olarak çalışmakta.

Son kullanıcımız olan RDUser1 kullanıcımız https://azurerds.traficmanager.net adresini kullanıyor ve RDS Portalına erişim gerçekleştiriyor. RD Gateway manager üzerinde Monitoring sekmesine baktığımız zaman bağlantı gerçekleştiren kullanıcımızın hangi RD Gateway sunucusu üzerinden RDS ortamına bağlantı yaptığını görebilmekteyiz.

Kullanıcımız azld-rdgw01 isimli Cloud01 içinde bulunan RD Gateway sunucusu üzerinden RDS ortamına bağlantı yaptığını görebilmekteyiz.

Son kullanıcımız bağlı durumdayken azcld-rdgw01 sunucusunu, RDS ortamına bağlantı yapmış olduğu sunucuyu kapatıyoruz. Bu kapatma işlemini plansız bir down-time olarak düşünebilirsiniz. Sunucunun herhangi bir nedenden dolayı hizmet edemediğinin testlerini gerçekleştiriyoruz.

Azure Portalımız üzerinde bulunan RDS Sanal sunucularına baktığımızda ilgili sunucunun kapalı durumda olduğunu ve hizmet edemediğini görebilmektesiniz.

Azurerds Trafik Manager üzerinden cloud servislerimizi kontrol ediyoruz. Her bir Cloud servislerimiz içinde her bir sunucu rolü için yüksek erişilebilirlik sağladığımız için Azure RDS’ imiz erişilebilir durumunda ve Trafik manager da hata görülmemektedir.

RDUser1 isimli kullanıcımız kısa bir süre kesinti yaşadıktan sonra Azure Trafik Manager tarafından uygun durumda ki RD Gateway sunucusuna erişimi sağlamakta ve kısa süreli kesinti sonrasına kullanıcımız Session Bağlantısını Kaybetmeden! Çalışmaya devam etmektedir.

Bu testimiz Plansız Down-Time olduğunu belirtmiştik. Bu kesinti sırasında kullanıcımızın Remote Bağlantısını kapatmaması gerkmekte. ATM yönlendirmesi yapmış olduğumuz yapılandırmaya bağlı olarak en performanslı sunucuya yönlendirene kadar bağlantısı kesilecektir ve sonrasında eski sessionu (oturumu) geri gelecektir.

Kullanıcımız aynı oturum ile, mevcut oturumda yapmış olduğu işlemleri kaybetmeden Azure Trafik Manager tarafından daha performanslı sunucuya yönlendirildi.

Dikkat ederseniz yönlendirilen sunucu Azcld-RDGWA03 sunucusu. Yani bu sunucu Cloud2 içinde bulunuyordu. Bizler ATM yapılandırmasını performans olarak belirlediğimiz için mevcut bağlantıyı Cloud2 e yönlendirdi. Kesinti sırasında bu cloud’ un daha performanslı olduğunu sistem algılamıştır.

İhtiyaçlarımıza bağlı olarak bu yapılandırmayı değiştirebilir, öncelikli olarak aynı cloud içinede yapmasını belirleyebilirdik. Daha detaylı bilgiler için Part 16 Add Trafik Manager makalesini inceleyebilirsiniz.

RDS Farmımız içinde bulunan, RDUSER1 kullanıcımızın çalışmış olduğu azcld-rdgwa02 sunucusunu plansız bir şekilde kapatıyorum.

Azure Portal üzerinde bulunan RDS Sanal sunucularımı incelediğim zaman azcld-02 cloud’ u içinde bulunan azcld-rdgwa03 sunucusunun ve azcld-01 cloud’ u içinde bulunan azcld-rdgwa01 sunucusunun kapalı olduğunu görebilmekteyiz.

Azure Portalımız üzerinde Trafic Manager statusu degreded olarak değiştiğini ve bozulmuş olduğunun uyarısı görebilmekteyiz.

Trafik Manager içinde Endpoints bölümünde Cloud servislerimize baktığımız zaman hangi cloud’ un problemli olduğunu görebilmekteyiz. azcld-02 cloud’ u içinde sadece bir tane RDGW sunucusu olduğu için bu cloud’ un bozulduğunu ATM’ nin problemli olduğunu görebilmekteyiz.

Fakat azlcd-rdgwa02 sunucumuz RDS Farmımız içinde çalışır durumda ve kullanıcımızın bağlantısı kesilmeden çalışmaya devam edebilmektedir. Kullanıcımız bu problem sırasında plansız kesinti olduğu için geçişlerde kesinti yaşamış ama mevcut session’u kaybetmeden ATM tarafından yönlendirildikten sonra mevcut çalışmasına devam etmiştir.

Yaşamış olduğumuz problemleri çözdükten sonra (bizler plansız down time testini RDGW sunucularımızı kapatarak yapmıştık ve tekrar çalıştırdıktan sonda problemi çözmüş olduk) sistem tekrar online olarak çalışacaktır.

Kesintilerde Session’ u kaybolmadığını belirttim. Bunun sebebi RDGW, RDWA ve RDSH rollerini farklı sunucular üzerinde konumlandırmış olmamdır. RDGW ve RDWA rolleri RDS Bağlantılarını RDSH sunucularına yönlendirmektedir. Bu yönlendirmelerde herhangi bir session tutulmadığı için oturumlarda kayıp yaşanmamıştır. Eğer kesintiler RDSH sunucusu üzerinde olmuş olsaydı son kullanıcılarımızın oturumu sonlandırılmış olacaktır. RDS sunucu rollerinin farklı sunucular üzerine dağıtılması, optimizasyonu bilgileri için Windows Server 2012 Remote Desktop Rollerinin Dağılımı ve Kurumsal Yapılar İçin Dizayn Seçenekleri  ve Windows Server 2012 Remote Desktop Services RDS Rolleri ve Değişen Kurulum Seçenekleri makalelerini inceleyebilirsiniz.

Azure RDS Deep Dive makale serimizi 18 bölüm olarak tamamlamış bulunmaktayız. Bu makale serisine Azure RDS Deep Dive etiketi ile portalımız üzerinden hızlı erişim gerçekleştirebileksiniz.

Makalede gösterilen mimari yapının çizim dosyası Visio formatında aşağıdaki linkte yer almaktadır

http://www.cozumpark.com/files/folders/yuklemeler/entry479414.aspx