Remote Desktop ortamı için en bilinen pazarlama söylemi her yerden erişim her zaman erişim ve her cihazdan erişim. Aslında bu söylem günümüz şirketlerinin olmazsa olmaz gereksinimi. Beyaz yaka, mesai kavramını artık yitirdi ve sıcak bir kahve bulduğu her yerden işlerini yapabilmekte. Günümüz, rekabet dünyası da bu hızda çalışmak artık zorunlu oldu. Bu hız arka tarafta süreklilik ve kararlı bir mimariye de ihtiyaç duymakta.
Remote Desktop ortamları da son on seneden beri bu pazarlama söylemine yakışan bir mimariyle karşımızda ve iş ihtiyaçlarımızı karşılamakta. Bu çalışmamız da uzak masa üstü hizmetleri için yüksek erişilebilirlik çözümlerini inceliyoruz.
Sol tarafta görmüş olduğunuz bölüm, beyaz yaka olarak adlandırmış olduğumuz çalışanlarımız. Evden ofisten, kafeden, her zaman her yerden ve her cihazdan çalışmak isteyen kullanıcılarımız. Sağ tarafta görmüş olduğunuz bölüm ise çalışanlarımızın taleplerini karşılamak üzere hazır bekleyen Remote Desktop ortamı.
Mimariye dikkatli bir şekilde baktığımız zaman her bir Remote Desktop Role için ayrı sunucular bulunmakta ve tek düğüm hatasına sahip. Mevcut Remote Desktop mimarisi, kullanıcılarımızın sürekli ve kararlı bir şekilde çalışması için risk oluşturmakta.
Remote Desktop deployment ortamı ilk kurulduğu zaman her bir sunucu görevi için sadece bir tane kuruluma izin verir ve biz bu mimariye Basic RDS Deployment demekteyiz. Remote Desktop ortamı her bir sunucu üzelinde yatay büyüme imkanı vermekte ve Basic RDS Deployment ortamında Advanced RDs Deployment ortamına dönüştürebiliriz.
Basic RDS Deployment ortamını kurduktan sonra kullanıcıların RDS ortamına ilk bağlantıyı yapmış oldukları RD Web Access Role yedeklenebilir ve süreklilik sağlayabiliriz. RD Web Access Role arka tarafta IIS mimarisini kullanmakta ve IIS sunucuları için tasarlamış olduğumuz yazılımsal ve donanımsal yük dengeleme tasarımına uyumlu.
Remote Desktop Gateway Role ‘ da aynı RD Web Access Role gibi çalışmaktae ve bu sunucu da arka tarafta IIS servisini kullanmakta. RD Gateway ‘ da aynı RD Web Access Role gibi yedekli çalışabilmekte.
Kullanıcılarımız için oluşturmuş olduğumuz Session Base Desktop Deployment (Oturum Sanallaştırma) ortamı ve Virtual Machine Base Desktop deployment (Sanal Masaüstü) ortamı biraz farklı. Virtual Machine Base Desktop deployment ortamı arka tarafta HyperV Mimarisini kullanmakta ve sanal masaüstü sunucularımız için HyperV yeteneklerine ve özelliklerine bağımlıyız. HyperV mimarisini Failover Cluster mimarisiyle birleştirebilir ve her bir sanal masaüstü için iş sürekliliği oluşturabiliriz.
Session Based Desktop deployment da diğer sunucu rollerine göre farklıdır. Bu sahip olduğumuz kullanıcı profiline göre karar verilecek bir tasarımdır. Windows server 2012 ile birlikte RDS ortamları Coleksiyon mimarisine sahip olduğu ve bir takım özel kurallar geldi.
Özel kuralın en bilinen özelliği bir Coleksiyon içinde birden fazla Remote Desktop Session Host Role olabilir ve bir Remote Desktop Session Host Role birden fazla coleksiyon üyesi olamaz. Bu kural, Remote Desktop ortamını kullanacak olan kullanıcı profilinin iyi analiz edilmesini şart koşmakta.
Kullanıcılar ne zaman bağlantı yapacak, hangi cihaz türünü kullanacak, nereden bağlantı yapacak ve hangi uygulamaları kullanacak gibi bir çok soru bulunmaktadır.
Diğer en önemli soru ise kullanıcılar birden fazla ve bir-biri ile uyumsuz uygulamaları kullanmakta mı. Bu sorular Remote Desktop Session Host Role , iş kritik önemini belirlemekte ve bu sorular sonrasında süreklilik tasarımı yapılmalı.
Bu soruların cevaplarına RD Session Host Koleksiyon Tasarımı için hazırlamış olduğumuz çalışma da paylaştık. Karmaşık olmasa bile biraz özen isteyen bir iş yüküdür.
İster Session Base Desktop Deployment yapalım ister Virtual Machine base Desktop deployment yapalım, kullanıcıların sahip olduğu profilleri için de süreklilik planı yapmamız gerekmektedir.
Bu teknoloji için de birden fazla çözüm vardır. Eski çözümler Folder Redirection Mimarisi, File Server Cluster ve DFS mimarisi ilk akla gelen çözümler. Eğer Session Base Desktop Deployment yapılacaksa ve Koleksiyon tasarımında User Profile Ddisk yapılandırmasına etki eden nedenler yoksa hızlı ve kolay olan User profile Disk teknolojisini kullanmanızı öneririm. Ama tekrar ediyorum, Session Base Desktop deployment ortamı için bu kararı koleksiyon tasarımı belirlemekte.
Eğer, Virtual Machine base desktop deployment yapılacaksa zaten User Profile Disk mimarisini önermekteyim. User profile Disk mimarisi arka tarafta Virtual Harddisk mimarisini kullanmakta ve Virtual Harddisk mimarisi de HyperV teknolojisini kullanmaktadır.
Virtual Machine base desktop deployment ortamı için de HyperV teknolojisi zorunlu olduğu için çözüm kendiliğinden geldi.
Bir diğer yenilik ise Windows Server 2016 ‘da gelmişti ve Azure Blob Store kullanımı User Profile disk mimarisi için de kullanılabilir oldu. Bu yenilikte bizlerin iş yüklerini hafifletmekte.
Sıra son sunucu rolüne geldi. Remote Desktop Connection Broker Role. Bu rol özeldir ve özel özen istemektedir. #RDS Deep Dive çalışmalarımız da odaklanmış olduğumuz temel RDS Sunucu Role. Remote Desktop ortamlarının kalbidir.
Diğer Remote Desktop sunucu rolleri gibi hızlı bir şekilde yatay büyümeye imkan vermeyen bir sunucu rolüdür. RD Connection Broker sunucusu için süreklilik planlıyorsak RD Connection Broker veri tabanını değiştirmemiz gerekmektedir.
Veri tabanını ilk önce SQL sunucularına taşımamız gerekmekte. Remote Desktop ortamının kritik önemine bağlı olarak SQL Always On mimarisi kullanılmalıdır. Tek bir SQL sunucusu üzerinde asla bırakılmaması gereken bir veri tabanı. Remote Desktop Connection Broker için süreklilik planı oluşturuyorsak önce veri tabanı sunucularının yedekli çalışmasını planlamalıyız.
Windows server 2016 ile birlikte Azure SQL veri tabanı da kullanılmaya başlandı ve gereksinimlerde biraz esneme oldu.
Her kuruluşun beklentisi ve sahip olduğu varlıklar farklı ve Azure SQL veri tabanı yada yerel SQL veri tabanı seçimi için ayrı bir çalışmamız bulunmakta. Doğru seçimi yapabilmemiz için kuruluş ihtiyaçları ve varlıkları seçimlere etki etmekte.
