Windows Server 2012 Remote Desktop Rollerinin Dağılımı ve Kurumsal Yapılar İçin Dizayn Seçenekleri

Ws2012 Remote Desktop Services Rolleri ve Değişen Kurulum Seçenekleri makalemizde Windows Server 2012 ile birlikte değişen kurulum seçenekleri hakkında bilgiler paylaşmış ve Remote Desktop Servisinin sahip olduğu rolleri, rollerinin hizmet amacını ve hangi rolün, kurumumuz içinde bulunan hangi sunucu üzerine yüklenebileceğini veya yüklenemeyeceğini özetlemiştik.

 

Ws12 Remote Desktop Rollerinin Dağılımı ve Kurumsal Yapılar İçin Dizayn Seçenekleri makalemizde konuyu biraz daha detaylandırıyoruz ve kurulum seçeneklerimize Dizayn seçeneklerimizi ekliyoruz. Makalemiz içinde tek bir sunucu üzerinde bütün Windows Server 2012 Remote Desktop Servislerinin kurulmasına örnekler verdiğimiz gibi her bir rolün farklı fiziksel / sanal sunucular üzerine kurulabileceğinin örneklerini veya kurumumuz içinde hazır durumda bulunan ve farklı amaca hizmet eden sunucuların üzerine hangi Remote Desktop Services Rolünün yüklenebileceğini senaryolar haline getiriyoruz. Makalemizin sonlarına doğru iş süreklilik planlarımız için Remote Desktop Rollerinin High Availability seçenekleri de bulunmaktadır.

 

Bu makale teknik bir makale olmadığını belirtmekte fayda var. Makale teknik değil ama makale içinde aktarılan bilgilerle oluşabilecek birçok teknik problemin önüne geçmesi hedeflenmiştir.

 

Makale içinde Capacity Planning bilgileri bulunmamaktadır. Windows Server 2012 Sunucu işletim sistemi için böyle bir çalışma bulunmadığı için Windows Server 2008 R2 Sp1 için hazırlanmış olan Remote Desktop Session Host Capacity Planning in Windows Server 2008 R2 and Microsoft RemoteFX in Windows Server 2008 R2 with Service Pack 1dökümanını referans almanızı önermekteyim.

 

 

 

 

Makale içinde kullanmış olduğum simgelerin açıklamaları görülmektedir. Simgeler içinde görülen her bir beyaz şerit içinde bulunan Remote Desktop Sunucu Rolleri tek bir tane fiziksel / sanal sunucuyu işaret etmektedir. Kırmızı şerit içinde görmüş olduğunuz Remote Desktop Sunucu Rolleri Cluster veya Server Farmı içinde olduğunu işaret etmektedir. En son simgemizse Windows Server 2012 ile birlikte gelmiş olan Server Group simgesidir. Makale içinde bu simge çoklu Remote Desktop ortamlarında kullanıldığını görebileceksiniz.

 

 

 

 

Yukarıdaki topoloji içinde tek bir tane Remote Desktop Sunucusu üzerine RD Web Access, RD Session Host, RD Connection Broker ve RD Licensing rollerinin eklendiğini görebilmektesiniz. Bu dizayn 150 – 230 Uzak Kullanıcıya sahip olan bir kurum için dizayn edilmiştir. Gerekli sunucu kaynağını planladıktan sonra Remote Desktop Rollerin bulunmuş olduğu tek bir sunucu kurumumuzun isteklerine cevap verebilir. Bu ortamı kurmak Windows server 2012 ile birlikte çok kolay durumdadır. Ws2012 Remote Desktop Services Installation Quick Start seçimiyle yarım saat gibi bir sürede bu ortamı kurabilirsiniz, kullanıma hazır duruma getirebilirsiniz. Ws2012 Remote Desktop Services Installation Quick Start Kurulumundan sonra ortama RD Licensing Rolü eklenmiştir.

 

Bu dizayn seçiminde Remote Desktop’un temel özelliklerinin hepsi kullanılmaktadır. RD Session Host Rolü sayesinde oturum sanallaştırılması yapılabilmekte ve kullanıcılarımıza session base uzak masa üstü hizmet sağlanırken diğer taraftan yüklenen RD Web Access rolü ile RemoteAPP teknolojisi kullanılıyor ve aynı sunucumuz üzerinde session base erişim haricinde sadece uygulama seviyesinde erişim sağlanıyor ve kaynak kullanımında tasarruf ve güvenlik tarafında artış kazanılıyor.

 

 

 

 

Ws2012 Remote Desktop Services Installation Quick Start kurulumunu tamamladık ve RD Licensing Rolünü aktif duruma getirdik. Remote Desktop Hizmeti kurumumuz için çalışmaya hazır. Fakat yeni bir isteğimiz var. Bu isteğimiz kullanıcılarımızın Remote Desktop ortamlarına RDP TCP/IP Protokolüyle bağlanmaları değil, daha güvenli bir bağlantı olan RDP Over HTTPS protokolüyle bağlanmalarıdır. Sahip olduğumuz Remote Desktop sunucusu üzerine RD Gateway rolünü yüklüyoruz ve ardından kullanıcılarımızı daha güvenli bir şekilde remote desktop ortamına bağlanmasını sağlıyoruz. RD Gateway’in en güzel özelliği bağlantıları şirket networkü ve şirket dışı networkü olarak ayırmasıdır. Bu özellik ile şirket networkü içinde bulunan kullanıcılarımızı RDP TCP/IP Protokolüyle remote desktop ortamına erişmesini sağlarken şirket networkü dışında bulunan kullanıcılarımızı RD Gateway Protokolüyle yani RDP over HTTPS protokolüle remote desktop ortamına erişmesini sağlıyoruz. Dış dünyaya bakan firewallımız üzerinde sadece SSL Portu Remote Desktop sunucumuz üzerine yönlendirilmiş durumdadır.

 

 

 

 

En fazla dizaynını yapacağımız kurulum seçeneklerinden bir tanesini görmektesiniz. Bu dizayn seçiminde Remote Desktop Servisinin temel bileşenleri kurumumuz için yapılandırılmış durumdadır. RD Session Host, RD Web Access ve RD Connection Broker sunucusu tek bir sunucu üzerinde bulunmaktadır. Kurulum işlemi Ws2012 Remote Desktop Services Installation Quick Start işlemleriyle yerine getirilmiştir. Kurulum tamamlandıktan sonra networkümüz içinde bulunan bir tane sunucu (bu sunucu merkezi lisanslama sunucumuz veya bir domain controller sunucumuz olabilir) RD Licensing sunucusu olarak hizmet ettirilmiştir. Topolojide dikkat ederseniz iki sunucu windows server 2012 server group özelliğiyle birleştirilmiş durumdadır.

 

 

 

 

İki sunuculu Remote Desktop ortamına farklı bir dizayn görmektesiniz. Bu dizaynımızda Remote Desktop Temel Rollerinin her birisi tek bir sunucu üzerinde hizmet etmektedir. Güvenliğimizi arttırmak için RD Gateway sunucumuzu farklı bir sunucu üzerine yerleştiriyoruz ve Remote Desktop erişimlerimizin güvenliğini sağlıyoruz. Bu dizaynımızda ki amacımız şirket dışı remote desktop erişimleri için güvenliğin üst seviyeye çıkartılmasıdır. RD Gateway sunucumuz DMZ (arındırılmış) networkü içinde barınabileceği gibi Remote Desktop sunucularımızla aynı network içinde de barınabilmektedir.

 

 

 

 

İki sunuculu Remote Desktop ortamına verecek olduğum son örneği yukarıda görebilmektesiniz. Bu topoloji seçiminde RD Licensing, RD Session Host ve RD Connection Broker sunucusu tek bir sunucu üzerinde barınıyor. Bu sunucumuz Remote Desktop kullanıcılarına Session Base Masa üstü erişim imkanı sağlıyor. Bu seçimin tercih edilme nedeni Sunucu kaynaklarını daha etkili kullanabilmek için RemoteAPP teknolojisinin Remote Desktop ortamına uygulanmasıdır. Bu ihtiyaç için kurumumuz networkü içinde bulunan hazır durumdaki bir Web Sunucusu, Sharepoint portal sunucusu tercih edilebilir ve RemoteAPP teknolojisiyle kullanıcılarımıza uygulama seviyesinde oturum sanallaştırması sağlanır. Bu yapılandırma sonrasında Remote Desktop Kullanıcıları daha hızlı bir şekilde uygulamaları kullanabilir duruma geliyorlar.

 

 

 

 

Üç sunuculu Remote Desktop ortamına ilk örneğimiz RD Session Host, RD Licensing ve RD Connection Broker sunucularımız tek bir sunucu üzerinde barınıyorlar. RD Web Access Sunucumuzu ayrı bir sunucu üzerine yüklüyoruz veya ortamımız içinde bulunan bir web sunucusunu veya kurumsal portalımızı bu görev için yapılandırıyoruz ve temel sunucumuzun sahip olduğu iş yükünü hafifletiyoruz. Diğer bir rolümüz olan RD Gateway sunucumuz için başka bir sunucuyu dizayn ediyoruz ve Remote Desktop ortamımız için güvenliği üst seviyeye çıkartıyoruz.

 

 

 

 

Üç sunuculu Remote Desktop ortamı için yapacak olduğumzu bir başka dizayn RD Session Host ve RD Connection Broker sunucularımız için tek bir sunucu kullanıyoruz. RD Licensing Rol ihtiyacımızı ortamımız içinde bulunan bir Lisanslama sunucusunu kullanıyoruz. Remote Desktop ortamımız için güvenlik ve performansı artışı kazanmak için RD Web Access ve RD Gateway sunucularımız için ayrı bir sunucuyu ortamımız içine dahil ediyoruz. RD Gateway ve RD Web Access sunucumuz DMZ bölgesinde hizmet edebilir durumda olduğunu hatırlatmak isterim.

 

 

 

 

Üç sunuculu dizaynlarımız ile birlikte High Availability seçeneklerimizide kullanabilir duruma gelebiliyoruz. RD Connection Broker ve RD Session Host Rollerimiz aynı sunucu üzerinde ve iki farklı sunucu üzerinde bulunmaktadır. Ortamımız içinde bulunan SQL database sunucusunu RD Connection Broker sunucumuzun ihtiyacı olan Database için yapılandırıyoruz ve RD Connection Broker sunucularını RDCB High Availability Mode yani iş sürekliliği için yapılandırıyoruz. RD session Host sunucularımız ise bu farm içinde üye bir sunucu olarak hizmet ediyorlar. Sahip olduğumuz SQL sunucumuz RD Licensing rolü için uyumlu bir sunucudur ve Remote Desktop ortamının çalışabilmesi için temel bir rol olduğu için SQl sunucumuz üzerinde RD Licensing sunucumuzu yüklüyoruz.

 

 

 

 

Bir önce ki üç sunuculu Remote Desktop ortamında mevcut SQL database sunucumuzu kullanmıştık. Kurumumuz içinde bulunan SQL sunucumuz üzerine RD Web Access ve RD Gateway rollerini yükleyememiştik. Çünkü bu SQL sunucumuz kurumumuz için kritik bir database sunucusu olabilir. Fakat bizler üçüncü sunucumuzu Remote Desktop ortamı için hazırlarsak yani bu sunucumuz sadece Remote Desktop ortamına hizmet edecekse RD Gateway ve RD Web Access Rollerini yükleyebiliriz.

 

Bu topolojimizi özetlersek RD Connection broker ve RD Session Host sunucusu aynı sunucu üzerinde barınıyor ve bu sunucudan Remote Desktop ortamımız içinde iki tane var. RD Connection Broker Sunucumuz için SQL sunucu ihtiyacımız bulunmakta ve üçüncü başka bir sunucu üzerine SQL server kurulumunu yapıyoruz ve RDCB High Availability Mode Database ihtiyacını bu sunucumuz ile karşılıyoruz. Yeni kurduğumuz SQL sunucumuz Remote Desktop ortamı için hazırlandı ve üzerinde kurumumuz için kritik bir database bulunmuyor. Bu özelliği kullanıyoruz ve Remote Desktop ortamımızı daha hızlı çalışabilmesi için RD Web Access ve daha güvenli bağlantılar gerçekleştirmek için RD Gateway Rollerini yüklüyoruz.

 

 

 

 

Yukarıdaki resimde yer alan dört sunuculu örnek Remote Desktop Topolojisi içinde hedefimiz RD Session Host Sunucularımızın iş sürekliliğini sağlamaktır. Bu yapımız içinde bulunan RD Session Host sunucuları aynı RD Farmının içinde bulunan, iş sürekliliğini ve yük dengeleme işlemini gerçekleştiren bir yapı içindedir.

 

Remote Desktop farmını yönetmek için ihtiyaç duymuş olduğumuz RD Connection broker ayrı bir sunucu üzerinde bulunmaktadır ve bu sunucumuz üzerinde RD Connection broker sunucumuz ile birlikte çalışlan RD Licensing rolünü görebilmekteyiz. Ortamımız içinde birden fazla RD Session Host sunucusu bulunuyorsa eğer RD Licensing sunucusu bu sunucuların üzerine kurulmaması gerektiğini anlatan bir topoloji bulunmaktadır. Aynı sunucumuz üzerinde RD Web Access sunucumuz yüklü durumda ve RD Session Host sunucularımız üzerinde bulunan uygulamaları Web Access arayüzünden RemoteAPP teknolojisiyle son kullanıcılarımızın uygulamalara erişmesini gerçekleştirecektir ve RD Session Host sunucumuzun iş yükünü azaltacaktır. RD Session Host sunucu farmı içinde RD Web Access sunucumuzun ayrı bir sunucu üzerinde olması gerektiğini tekrar hatırlatıyorum. Son sunucu rolümüz RD Gateway sunucumuz olup Remote Desktop ortamına bağlantıyı sağlayacak olan uzak kullanıcılarımız için bağlantıların güvenli bir şekilde olmasını ve bağlantıları merkezi bir noktadan görmemizi sağlayan bir sunucu rolü olarak topolojimiz içinde bulunmaktadır.

 

 

 

 

Dört sunuculu bir başka topoloji içinde bu kez RD Connection Broker sunucularımız için iş sürekliliğini hedefledik. Bu yapımız içinde RD connection Broker ve RD Session Host sunucuları aynı sunucu üzerinde bulunmaktadır ve iş sürekliliği / yük dengelemesi ihtiyacını karşılamaktadır. RD Connection broker ve RD Session host sunucuları aynı sunucu üzerinde çalışabilen uyumlu rollerdir. Kurumumuz içinde bulunan SQL sunucumuzu, RD Connection Broker farmının ihtiyaç duymuş olduğu database için yapılandırdık ve aynı sunucumuz üzerine RD Licensing Rolünü yükledik. Kurumumuz içinde bulunan Web Sunucumuzu RD Ortamını daha performansılı çalıştırabilmek için RD Web Access sunucusu olarak yapılandırdık ve RD Session Host sunucularımız üzerindeki iş yükünü hafiflettik.

 

 

 

 

Bir önceki topolojimiz ile aynı dizayna sahip durumdayız. Fakat bu topolojimizde RD Web Access sunucumuzun bulunmuş olduğu sunucu üzerine RD Gateway sunucumuzu ekledik ve Remote Desktop bağlantılarını daha güvenli bir şekilde olmasını sağladık. Bu topolojimiz, bir önceki topolojimize göre en büyük farkı RD Gateway sunucumuzun eklenmesidir. Bir önceki topoloji içinde kurum içinde bulunan Web sunucumuzu kullanabiliyorduk fakat bu topolojide kurum içinde bulunan web sunucumuzun kullanılması değil, ayrı bir sunucunun bu görevler için yapılandırılmasını önermekteyiz.

 

 

 

 

Dört sunuculu yapılar bir birine çok benzemektedir. RD Connection broker ve RD Session host sunucularımız aynı sunucular üzerinde yüklü, aynı farm içinde ve ortamda ikişer adet bulunmakta. Amacımız aynı, iş sürekliliği ve yük dengelenmesi. RD Connection broker sunucumuz için ihtiyaç duymuş olduğumuz SQL databasesi için kurumumuz içinde bulunan SQL sunucumuzu kullanabiliriz. Bu yapının bir önceki yapıya göre en büyük farkı, kurumumuz içinde bulunan SQL sunucumuz üzerine RD licensing rolünü yükleyememe ihtimaline karşı dizayn edilmiştir. Bu topolojimizde RD licensing sunucumuz RD Gateway ve RD Web Access sunucularımız ile aynı sunucu üzerinde bulunmaktadır. Fakat bu yapının bir önceki yapıya göre en büyük farkı bu topolojinin DMZ bölgesi içinde barınması önerilmemektedir. Son sunucumuzu DMZ bölgesinde barındırırsak RD Licensing rolünün sağlıklı çalışmasında problemler yaşayabiliriz.

 

 

 

 

Beş sunuculu topolojimizde ki ilk örnek Remote Desktop Servisinin en üst düzeyde olan optimizasyonundan bahsetmektedir. Bir sunuculu topolojilerde vermiş olduğumuz örnekte, bütün Remote Desktop rolleri tek bir sunucu üzerinde barınıyordu. Bu topolojimizdeyse bütün rolleri ayrı sunucular üzerine yerleştirdik ve en üst seviyede performansı elde ettik. Bu topolojimiz içinde bulunan bazı rolleri kurumumuz içinde bulunan sunucular üzerine yükleyebiliriz. RD Licensing rolünü lisanslama sunucumuz üzerine RD Web Access sunucumuzu web sunucumuz veya sharepoint portal sunucumuz üzerinde çalıştırabilir durumdayız.

 

 

 

 

beş sunuculu topoloji dizaynımıza bir başka örnek iş sürekliliği. RD Session Host ve RD Connection broker sunucumuz aynı sunucu üzerinde çalışılıyor ve iş sürekliliği ve yük dengelemesi ihtiyacını karşılıyor. RD Connection Broker sunucumuzun ihtiyaç duymuş olduğu database kurumumuz içinde bulunan SQL databasesi üzerinde çalışıyor ve bu sql sunucumuz cluster kümesi olarak kurum içinde hizmet ediyor. Remote Desktop ortamının ihtiyaç duymuş olduğu RD licensing rolü lisanslama sunucumuz üzerinde ve Remote Desktop ortamının lisanslarını kontrol etmektedir.

 

 

 

 

Bir önceki topolojimizde aynı topolojiye sahibiz. Fakat bu yapımızda RD Web Access sunucusu Remote Desktop ortamı içine dahil edildi ve RD Session Host sunucumuzun iş yükünü hafifletti. RD Licensing rolünü beş sunuculu yapı içinde RD Web Access sunucumuzun üzerine yerleştirmemiz önerilmektedir. Bu topolojide RD Web Access sunucusu rolünü kurum içinde bulunan Web serverlarımıza veya portal sunucularımız üzerine yükleyebiliriz.

 

 

 

 

Beş sunuculu topolojiler bir birine benzerlik göstermektedir. RD Farm sunucularımız ve SQL Cluster mimarisinde bir değişiklik bulunmuyor. Fakat RD Licensing ve RD Web Access sunucularımızın bulunmuş olduğu sunucumuza RD Gateway sunucumuz eklendi ve Remote Desktop bağlantıları için güvenlik gereksinimini karşıladı. Bu topolojinin bir önceki topolojiye göre en büyük farkı seçimini yapacak olduğumuz sunucu kurumumuz içinde bulunan bir web sunucusu veya portal sunucusunun olmamasıdır. Çünkü RD Gateway sunucusunun eklenmesiyle birlikte bu seçimimiz ortadan kalkmış bulunmaktadır. Aytı bir sunucu bu ortam için hazırlamamız gerekmektedir.

 

 

 

 

Beş sunuculu bu topolojimizde iş süreklilik planını RD Web Access sunucularımız için tercih ediyoruz. RD Connection Broker ve RD Session Host sunucuları önceki topolojiler gibi aynı farm içinde ve iş sürekliliği, yük dengelemesi ihtiyacımızı karşılıyor. Kurumumuz içinde bulunan SQL sunucusu RD Connection Broker sunucumuz için database ihtiyacını karşılarken aynı sunucumuz üzerine RD Licensing rolünü aktif duruma getiriyoruz. RD Web Access sunucusu olarak kurumumuz içinde bulunan Web Server Farmını aktif duruma getiriyoruz ve RD Session Host sunucularımız üzerinde ki iş yükünü hafifletiyoruz.

 

 

 

 

Beş sunuculu topoloji örneklerimizde son topolojimiz yukarıda görülmektedir. Bu topoloji içinde RD Session Host sunucumuz ile RD connection Broker sunucularımız ayrı-ayrı sunucular üzerinde barınıyorlar ve Remote Desktop ortamı içinde iki şer adet olarak yer alıyor. RD Connection Broker sunucularımız ile RD Connection Broker High Availability Mode yapılandırıyoruz ve RD Session Host sunucularımızı bu farmın içine üye yapıyoruz. Kurumumuz içinde bulunan SQL sunucumuz RD Connection Broker High Availability Mode için database ihtiyacımızı karşılıyor ve aynı zamanda Remote Desktop ortamımız için RD licensing rolünü yerine getiriyor.

 

 

 

 

Altı Sunuculu Remote Desktop Services ortamları için RD Web Access Sunucularımız için iş sürekliliğini planlayailiyoruz. Bu topolojide ki temel amacımız Remote Desktop ortamlarının temel rolleri olan RD Session Host, RD Connection Broker ve RD Web Access Sunucuları için iş sürekliliği ve yük dengelemesini gerçekleştirmemizdir. Yapımız içinde RD Connection Broker ve RD Session Host Rolleri aynı sunucular üzerinde yüklü durumda ve topolojimiz içinde iki tane bulunmaktadır. Kurumumuz içinde bulunan SQL sunucusu RD Connection Broker High Availability Mode yapılandırılması için Database ihtiyacımızı karşılıyor ve tekrardan kurumumuz içinde bulunan lisanslama sunucusu RD licensing Rolümüzü barındırıyor. Bu yapımız içinde kurumumuz içinde bulunan Web Server farmını RD Web Access Rolü için yapılandırabileceğimiz gibi Remote Desktop ihtiyaçlarımızın büyüklüğüne bağlı olarak RD Web Access sunucuları için yeni bir farm oluşturabiliriz.

 

 

 

 

Bu topoloji örneğimizde, Altı sunuculu topolojilerimize RD Gateway sunucumuzu ekledik. Daha önceki topoloji örneğimizde olduğu gibi RD Connection Broker sunucularımız ve RD Session Host sunucularımız aynı sunucu üzerinde barınıyorlar. Rd Web Access sunucularımız bir önceki topolojide olduğu gibi yerlerini almış durumdalar. Bu topolojinin, bir önceki topolojiye göre en temel farkı RD gateway sunucumuzun Remote Desktop ortamına katılmasıdır. RD Gateway sunucumuz için kullanmış olduğumuz sunucumuz RD Web Access sunucumuzdur ve ihtiyaçlarımıza bağlı olarak ve güvenlik seviyesini arttırmak için DMZ bölgesinde barındırabileceğimiz bir sunucudur.

 

 

 

 

Altı sunuculu Remote Desktop topolojisinde bu sefer RD Gateway Rolünü dışarıda bırakıyoruz. RD Connection Broker Sunucularımızın Database ihtiyacını karşılayan SQL serverlarımız cluster kümesi içinde hizmet ediyorlar ve RD Connection Broker sunucumuzun databasesini bu cluster kümesi içinde barındırdık. RD Web Access Rolümünü kurumumuz içinde bulunan Web sunucumuzun üzerine yüklüyoruz ve RD Session Host sunucularımızın iş yükünü azaltıyoruz. RD Licensing, temel remote desktop sunucu rolümüzü kurumumuz içinde bulunan lisanslama sunucumuzun üzerinde çalıştırabilir durumdayız.

 

 

 

 

Bu makalemiz içinde Remote Desktop ortamları için örnek topolojileri, kurumumuz içinde bulunan mevcut sunucular kullanılarak ihtiyaç duymuş olduğumuz Remote Desktop Rollerinin yüklenmesini, iş sürekliliği ve performans artışları sağlamak için örnekler vermeye çalıştım. İhtiyaçlarımıza bağlı olarak bütün remote desktop rollerini tek bir sunucu içinde çalıştırabildiğimiz gibi her bir rolü ayrı fiziksel veya sanal sunucu ortamlarında çalıştırabiliriz.

 

Son örneğimizde bütün remote desktop rollerinin ayrı sunucular üzerinde ve yedekli olarak çalışan mimarisini görmektesiniz. Bu makale içinde kendi örneklerimi ve kurumlara uygulamış olduğum dizaynları aktarmaya çalıştım ve bizlere bağlı olarak bu dizaynları arttırmak bizlerin elindedir. Dikkat etmemiz gerekli olan en önemli nokta uyumlu sunucular üzerine uyumlu rollerin yüklenmesidir.