Remote Desktop Services Yüksek Erişilebilirlik Çözümleri Bölüm 13 Collection Erişim Çözümleri

Remote Desktop Services Yüksek Erişilebilirlik Çözümleri makale serimizin bu bölümünde RDS farmımızın içinde oluşturmuş olduğumuz Collection ‘lara erişim çözümlerini sunacağız. Bu makalemizde bahsedecek olduğumuz konu Windows Server 2012 ile birlikte RDS ortamına erişimin değişmesinden kaynaklıdır.

Bilindiği gibi Windows Server 2008 ile birlikte Remoteapp teknolojisi ile tanışmış ve RD Session Host sunucularımızın daha performanslı ve daha az network kullanmaları için uygulama seviyesinde oturum sanallaştırılması teknolojisi kullanılması önerilmişti. Fakat bazı uygulamaların Remoteapp teknolojisi ile tam uyumlu çalışması zaman almış ve uygulamalarımızın uyumsuzluk problemleri nedeniyle Full Session yani masaüstü erişimleri kullanılması kaçınılmaz olmuştu.

Remoteapp teknolojisi Windows Server 2012 ve R2 ile birlikte devam etmek ve geliştirilmektedir. Ve artık Remoteapp teknolojisi Windows Server 2012 den sonra kullanılması için bir takım zorlamalar bulunmaktadır. Bu zorlamalar bizler için bir adaptasyon problemi oluştursa bile çözümlerimiz bulunmaktadır. Bu makalemiz içinde önerilen ve önerilmeyen çözümleri anlatacağız.

Üçüncü firmaların Donanımsal / Yazılımsal Yük Dengeleme Ürünlerini Kullanmak İstersek

Yukarıda gösterilen topoloji içinde üçüncü firmaların (f5, kemp) sağlamış olduğu yük dengeleme çözümü kullanılmak istenilirse yapmamız gerekli olan çözüm paylaşılmıştır. Eskiden yaptığımız gibi birden fazla RD Session Sunucusu kurmak ve yük dengeleme işlemini bu firmaların sağlamış olduğu yazılımlara bırakmaktır. Bu iki sunucu bir birinden bağımsız olarak çalışmakta ama üçüncü firmaların yük dengeleme cihazı tarafından küme içine dâhil edilmektedir. Bu iki RDS sunucusu bir birinden bağımsız olarak çalışacaktır ama bir birinin aynısı (collectionlar, uygulamalar, erişim izinleri vb.) olacaktır. Bu iki RDS sunucusu bir birinden farklı olsa bile aynı amaç için hizmet edecekleri için yapılandırmaları bire bir aynı olmak durumundadır. Rds ortamına kurabilmemiz için gerekli olan RDS rolleri (RD Web Access ve RD Connection Broker) bu sunucu üzerine kurulacak ve bu roller için bir yüksek erişilebilirlik çözümü uygulamayacağız. Bir sonraki makalemiz olan Bölüm 14 User Profile Disk Yapılandırılması ihtiyacı bu yapılandırma içinde zorunludur. Çünkü RDS kullanıcılarımız üçüncü firmanın yük dengeleme cihazındaki yapılandırmaya ve yük durumuna göre herhangi bir RDS farmına bağlantı yapabileceklerdir.

Microsoft Tarafından Önerilen Çözüm

Makalemizin başında belirttiğimiz gibi öncelikli olarak Remoteapp teknolojisini kullanılmasıdır. Eğer bizler Remoteapp teknolojisini yapılandırmazsak, web Access üzerinden uygulamalarımızı yayınlamazsak ne olacak?

Sorunun cevabı basit. Makale serimizi dikkatli bir şekilde okuyan kullanıcılarımız hatırlayacaktır. Collection oluşturma ekranında bulunan General bölümünde bir kutu vardı; Show the session collection in RD Web Accessseçimi.

Bu seçimi aktif duruma getirirsek RD Web Access üzerinde Collection erişimi için bir simge bulunacaktır ve kullanıcılarımız Collection ‘a bu simge üzerinden erişecektir.

Kullanıcımız RD Web Access üzerinde bulunan Collection simgesine tıkladığı zaman RDP aracı çalıştırılacak ve RDCB sunucusuna / cluster ismine bağlantı yapılacaktır. Oluşturmuş olduğumuz ortamımız içinde bağlantı yapılan RDCB00.live.local RDCB cluster ismini görüyorsunuz.

RDCB sunucularımıza gelen istek uygun RD Session Host sunucusuna yönlendirilecektir ve yük dengelemesi ve iş sürekliliği gerçekleştirilecektir. RDCB sunucusuna gelen istek RDCB02 isimli sunucumuza yönlendirildiğini görebiliyorsunuz.

Ve bağlantı başarılı bir şekilde gerçekleştiriliyor.

Bir başka soru.

RD Web Access sunucusu kullanılmadan RD Session Host farmına Erişilmek İstenilirse Bağlantılar Nasıl Sağlanacak? Kullanıcılarımız RDP aracı ile RD Session Host sunucularına bağlanmak isterlerse ne yapmamız gerekiyor.

İlk aklımıza gelen çözüm RDCB sunucusuna bağlantı verirsek, RDCB sunucusu kullanıcı isteğini uygun RD Session Host sunucusuna yönlendirecektir. Deneyelim. Sonuç ne olacak?

Kullanıcımız RDP aracı ile RD Web Access üzerinden yönlendirilen ismi bağlantı yapmak istiyor. Yani RD Web Access üzerinde yapılan isim RDCB00.live.local bağlantısını RDP aracına yazıyor.

Bağlantı sağlanıyor ve kimlik bilgilerini giriyor.

Bağlantının gerçekleştirildiği sunucuya dikkatli bir şekilde bakarsanız RD Session Host sunucularına değil RD Connection Broker sunucularından bir tanesine bağlantı yapıldı.

Ortamımız içinde RDCB rolü ile RDSH rolü farklı sunucular üzerinde bulunduğu için bağlantı başarısız oldu ve kullanıcımız bağlantıyı sağlayamadı. Çünkü bağlantı yapılmak istenilen sunucu kullanıcılarımızın uygulamalarını barındıran RD Session Host sunucusu değil RDS farmının yönetimini gerçekleştiren RD Connection Broker sunucularıdır.

Windows Server 2012 ve R2 üzerinde belirtmiş olduğumuz Collection erişimi burada farklılık göstermektedir.

Web Access üzerinden yapılmayacak bağlantılar için Önerilen çözüm ilk senaryodaki gibi Ortamda üçüncü bir donanımsal / yazılımsal yük dengeleme cihazı varmış gibi davranacağız ve makalemiz başında belirtilen çözümü kullanacağız. Ayrı-ayrı RDCB sunucusu yapılandıracağız. Veya RDCB rolü ile RDSH rollerini aynı sunucu üzerine kuracağız.

Karma bir yapımız varsa ne olacak? Bazı kullanıcılarımız RD Web Access kullanıyor bazı kullanıcılarımız RDP bağlantısı kullanıyor. Bu durumda çözüm ne olacaktır.

Önerilmeyen! Çözümü yukarıdaki topoloji içinde paylaştım. RD Web Access kullanıcılarımız için bir problem yok. Bu makaleye kadar yapmış olduğumuz bütün yapılandırma doğru. RDP kullanıcılarının problemini aşabilmek için ise DNS Round Robin hizmetini kullanacağız. İlk makalemizde bahsetmiştik. RD Session Host rolleri için artık Dns Round Robin ve Microsoft NLB kullanılmamaktadır. Yüksek erişilebilirlik ve yük dengeleme işlemleri RD Connection Broker sunucuları tarafından yapılmaktadır.

Bizler DNS Round Robin özelliği ile bir çözüm geliştirmiş olsak bile bu çözüm desteklenmemektedir. Bu tip RDP bağlantısında kullanıcılarımız RD Web Access rolünü ve RD Connection Broker rollerini kullanmadan RD Session Host rollerine direk bağlantı sağlamaktadırlar.

Karma yapılar için ne yapmamız gerekiyor? Yani Microsoft’ un istediği Remoteapp teknolojisi kullanmak ama uyumsuz uygulamalarımız için çözüm nedir?

Desteklenen uygulamaları Remoteapp ile yayınlamak. Örneğimiz içinde exel uygulaması desteklenen bir uygulamadır ve Remoteapp teknolojisi ile web Access üzerinden yaygınlaştırıldı.

Fakat web Access üzerine baktığımız zaman web Access üzerinden Collection erişiminin yok olduğunu görebilmektesiniz.

Collection erişiminin web Access üzerinden yok olmasının nedeni Show the Session Collection in RD Web Access kutusunun temizlenmesinden kaynaklıdır. Yukarıda görüldüğü gibi bizler Remoteapp ile herhangi bir uygulamayı yayınladığımız zaman bu kutu temizleniyor ve bir daha seçilemiyor.

Biraz sinir bozucu bir durum. Bu durumun Windows Server 2012 ‘ nin geçiş işletim sistemi olmasına bağlıyorum ve remoteapp teknolojisinin kullanılmasının Microsoft tarafından zorunlu bir duruma getirilmesi gerektiğini düşünüyorum.

Karma yapılar için biraz uğraştırsa bile çözüm bulunmaktadır. Remoteapp ile bir uygulama yaygınlaştırdığımız zaman RD Connection Broker sunucularımız üzerinde ShowInPortal  register anahtarı değiştiriliyor. Bu değer 1 değerinden 0’ a çekiliyor.

Eğer karma bir yapımız varsa Remoteapp ve masa üstü kullanımını sağlamak istiyorsak Remoteapp ortamına bir uygulama yaygınlaştırdığımız zaman her bir RD Connection Broker sunucumuz üzerinde ve her bir Collection için aşağıdaki anahtarı 0 ‘ dan 1 ‘e geri getirmemiz gerekmektedir.

HKLM\ SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ Terminal Server\ CentralPublishedResources\ PublishedFarms\ <collection name>\ RemoteDesktops\ <collection name>

ShowInPortal     REG_DWORD     0x00000001

Son sinir bozucu durumu daha paylaşmak istiyorum. Bu anahtarı bizler bir kez 1 durumuna getirdiğimiz zaman bu anahtar değeri sabit kalmıyor. Remoteapp bölümünde yapacak olduğumuz her bir değişiklikte (uygulama ekleme, uygulama özelliği değiştirme veya uygulama kaldırma sonrasında) bu anahtar tekrar 0 değerini alıyor.

Karma bir yapımız varsa bu anahtarı sürekli değiştirmemiz gerektiğini unutmamamız gerekmektedir.

Makalemizin başında belirttiğim gibi RDS mimarisi ciddi değişim gösteren bir rol ve bizlerin sahip olduğu eski alışkanlıkları biraz zorlayacak gibi görülüyor. Sürekli gelişim gösterdiğini düşünürsek bu probleminde önümüzdeki sunucu işletim sistemlerinde çözüme kavuşacağını beklemekteyim.