Windows Server

Remote Desktop Services Yüksek Erişilebilirlik Çözümleri Bölüm 14 User Profile Disk Yapılandırılması

Remote Desktop Services Yüksek Erişilebilirlik Çözümleri Makale serimizin bu bölümünde RDS farmına bağlantıyı gerçekleştiren kullanıcılarımızın, sahip oldukları ve yeni oluşturacakları verilere kolay bir şekilde erişmelerini, sahip oldukları verilerinin güvenliğini, alt yapımız için sorun oluşturabilecek büyüyen kullanıcı verilerinin sınırlandırılmasını vb. birçok işlemi inceleyeceğimiz User Profile Disk kısaca UPD Yapılandırılmasını inceleyeceğiz.

Windows Server 2012 sürümüne kadar RDS çözümlerinde kullanıcı verileri için bir çözüm bulunmamaktaydı. Kullanıcı verilerinin güvenliğini ve alt yapımız için sınırlandırmayı farklı çözümler ile karşılayabiliyorduk. UPD teknolojisi Windows Server 2012 ile birlikte RDS mimarisine eklenen yeni bir teknoloji olup birçok kolaylığı bizlere sağladı ve çok fazla değişmemekle birlikte bu teknoloji Windows Server 2012 R2 ile birlikte kullanılmaya devam edilmektedir.

UPD teknolojisinden önce RDS ortamları içinde bulunan kullanıcıların verilerini saklamak için iki yöntem bulunmaktaydı. Bu yöntemler;

Folder Redirection teknolojisi ile RDS mimarisinden bağımsız gerçekleştirmiş olduğumuz File Server çözümüydü. Etki alanımız içinde bulunan bir File Sunucumuzu yapılandırıyorduk ve etki alanımız üzerinde RDS kullanıcılarımız için Folder Redirection Policy sini uyguluyorduk. Bu teknoloji sayesinde RDS kullanıcılarımızın sahip oldukları veriler güvenilir bir ortama taşınmış oluyorlar ve kullanıcılarımız verilerini yönlendirmiş olduğumuz file Server üzerinden kullanıyorlardı. Bu makalede yapılandıracak olduğumuz UPD yapılandırmasına göre çok benzeyen bir teknoloji olsa bile UDP’ nin sağlamış olduğu avantajları, yapılandırma kolaylığı yanında artık RDS ortamları için tercih edilecek bir teknoloji değildir. Fakat File Server çözümleri olarak kullanılmaya devam edilmektedir.

Folder Redirection yapılandırmasının UDP yapılandırmasına göre en büyük dezavantajı RDS kullanıcısı ile Etki alanı kullanıcısı aynı ise veri yönetimi tarafında bizlere ciddi zorluklar çıkartıyor olmasıydı. Bu zorlukların önüne geçebilmek için birçok kurum RDS kullanıcıları için etki alanında ayrı kullanıcılar açarak çözüm buluyorlar fakat bu çözüm ise kullanıcıların iki farklı hesabı kullanma güçlükleri ile karşı-karşıya bırakıyordu. UPD’ den önce RDS ortamları için bir çözüm olsa bile ihtiyaçlarımızı tam anlamıyla karşılamıyordu.

Bir diğer kullanmış olduğumuz teknoloji Roaming Profile özelliğiydi. Adından da anlayabileceğimiz gibi “Roaming User Profile”, kullanıcılarımızın organizasyon içindeki farklı bilgisayarlarda, aynı profil dosyaları ile oturum açabilmesine olanak sağlayan bir özelliktir. Yani kullanıcılarımız beş farklı bilgisayarda da oturum açsalar, aynı belgelerim klasörü, aynı kişisel ayarlar, desktop ve içeriği, gibi Profil tabanlı özellikleri kullanabiliyor olacaklardır.

Türkçe kelime karşılığı “Gezici Kullanıcı Profili” olan bu yapı, organizasyonumuz için oldukça kullanışlı olabileceği gibi, yanlış yapılandırmalar sonucunda tam bir kâbusa da dönüşebilir. Bu nedenle piyasada özel durumlar dışında pek sık rastlayamıyoruz. Çünkü terminal sayısı fazla olan yapılarda network’e getirdiği yük gerçekten can sıkıcı olabiliyor ve verinin yönetilmesi, problem durumunda çözümü gerçekten zor bir durum alıyordu.

UDP teknolojisinden önce Folder Redirection yapılandırmasını birçok kurum içinde yapılandırdım ama Roaming Profile yapılandırmasından her zaman için uzak durmuşumdur. Bu yapılandırmadan başı ağrıyan kişilerin bu makaleye yorum yapmasını özellikle isteyeceğim.

Bu iki teknolojinin haricinde kullanmış olduğumuz bir diğer çözüm ise hiçbir şey yapmamaktı. Yani kullanıcılarımızın sahip oldukları Profile bilgileri, verileri vb. birçok dosya/doküman bağlantı yaptıkları RD Session Host sunucusu üzerinde kalmasıydı. Varsayılan değerlerde bu klasör yolu RDS sunucumuzun OS Versiyonuna göre değişiklik göstermektedir. Bu son çözüm yüksek erişilebilirlik çözümü sağlanmamış ortamlarda verinin yönetimi için fazla bir sıkıntı oluşturmasa bile güvenliği için bizlere sıkıntı oluşturmaktaydı.

Özet olarak Folder Redirection Teknolojisi ve Roaming Profile Yapılandırması RDS yüksek erişilebilirlik çözümlerinde zorunlu olarak yapılandırılması gerekli olan teknolojidir. Hiçbir şey yapmamak yani RDS verilerini RD Session Host sunucusu üzerinde barındırmak ise tek sunuculu RDS ortamları için kullanılması gerekli olan bir teknolojidir.

Yukarıda paylaşmış olduğum veriler tecrübelerimin birikimi sonrasında aktarmış olduğum özet bilgilerdir. Tartışıldığı zaman, yeni senaryolar ve istekler oluştuğu zaman çoğaltılabilecek birçok nedenler bulabiliriz. Tecrübelerimizi bu makale içinde senaryo haline getirelim, paylaşalım ve UPD teknolojisinin nimetlerinden yararlanalım.

clip_image001

Yukarıdaki topoloji içinde aynı Collection içinde hizmet eden iki farklı RD Session Host sunucu görmektesiniz ve kullanıcılarımızın verileri local diskler üzerinde ortak bir havuzda tutulmuyor.

Bu yapılandırma içinde yaşayacak olduğumuz en büyük sıkıntı kullanıcımız RDSH01 isimli sunucuya bağlandı, işlemlerini yaptı, dokümanı kaydetti ve işlemini tamamlayıp oturumdan ayrıldı. Oluşturmuş olduğu dokuman RDSH01 isimli sunucu üzerinde kırmızı olarak görülen dokuman olsun. Aynı kullanıcı tekrardan RDS farmına bağlandığı. Bu sefer RDCB sunucumuz daha uygun durumda bulunan RDSH02 isimli sunucumuza kullanıcımızı yönlendirdi. Kullanıcımız dokümanını arıyor fakat kaydetmiş olduğu yerde bu dokuman yok. Çünkü bu dokuman RDSH01 isimli sunucu üzerinde kaldı. Kullanıcımız ancak tekrardan RDSH01 isimli sunucumuz üzerinde çalışmaya başladığı zaman bu dokumana ulaşabilecektir. Dokuman kaybı yok ama yönetimi bizler için çok fazla efor sarf ettirecek olan bir çözümdür ve yüksek erişilebilirlik çözümlerinde böylesine basit bir hata kabul edilemeyecek kadar büyüktür.

clip_image002

Oysaki Collection içinde bulunan kullanıcılarımıza Folder Redirection Policy’ si uygulamış olsaydık ve kullanıcı verilerini bir ortak havuz içine, file server üzerine göndermiş olsaydık, kullanıcımız Collection içinde bulunan herhangi bir RD Session Host sunucusuna bağlandığı zaman verilerine her zaman için ulaşabilecekti.

Folder Redirection özelliğini bilerek yazdım, bu bölümden sonra User Profile Disk yapılandırması ile devam edeceğim. UPD yapılandırma amacımız, Folder Redirection çözümünde yapmış olduğumuz amaçtan hiçbir farkı bulunmamaktadır. Amaç aynı, teknoloji ve yapılandırmalar farklılık göstermektedir.

clip_image003

Bu kadar teorik bilgiden sonra UPD yapılandırmasını yapmazsak yaşayacak olduğumuz problemleri gösterelim.

Col1Rds1 isimli RDS kullanıcımız RDSH01 isimli sunucumuz üzerine bağlandı ve masa üstünde görülen dokumanlar üzerinde değişiklik yaptı, oluşturdu. İşlemlerini bitirdi ve oturumunu kapattı.

clip_image004

Aynı kullanıcımız farklı bir zamanda tekrar RDS farmına bağlandı. RDCB sunucumuz daha uygun durumda bulunan RDSH02 isimli sunucumuza kullanıcımızı yönlendirdir. RDCB sunucumuz kullanıcımızın verisi hangi RDSH sunucusu üzerinde olduğuna bakmaz, hangi RDSH sunucusu uygun durumdaysa oraya yönlendirir. Ve kullanıcımız RDSH02 sunucusu üzerine bağlandığı zaman verilerini göremiyor ve problem başlıyor.

Bu problemin önüne geçebilmek için UPD yapılandırmasını gerçekleştireceğiz.

clip_image005

Bu makale içinde RDS kullanıcılarımın verilerini bir file server üzerine yönlendireceğim. Yönlendirme işlemini gerçekleştirecek olduğum file server üzerinde bir klasör açıyorum ve RDS kullanıcılarım için gerekli olan izinleri veriyorum. Topoloji içinde File Server tek bir tane gösterilmiştir. Tek nokta hatasını almamak için gerçek ortamlarınızda Cluster özelliği yapılandırılmış bir file server olmasına dikkat ediniz.

Folder redirection teknolojisine göre UPD teknolojisinin farklarını konuşmaya devam edelim. Folder redirection teknolojisi için etki alanımız içinde üye durumda bulunan bir File server zorunlu durumdayken UPD teknolojisinde bu alanın bir UNC path olması yeterlidir. Yani RDS kullanıcılarımızın verilerini yönlendirecek olduğumuz havuz bir sunucu olabileceği gibi bir NAS cihazı, storage üzerinde ayırmış olduğumuz bir alan, HyperV cluster üzerinde yapılandırılmış bir CSV vb. Unc path yolu verebileceğimiz herhangi bir lokasyon olabilmektedir.

clip_image006

clip_image007

Yönlendirme işlemini gerçekleştirecek olduğumuz sunucumuz üzerindeki Unc path bilgisini görebilmekteyiz.

clip_image008

Oluşturmuş olduğumuz klasörün içeriğinin boş olduğunu görebilmekteyiz.

clip_image009

Remote Desktop Services yönetim arayüzüne geliyoruz ve Session Collection’u açıyoruz. Task bölümün de Edit Properties işlemiyle yapılandırmamıza başlayacağız.

Oluşturmuş olduğumuz Col1 özelliklerin de User Profile Disk bölümünü açıyoruz ve Enable User Profile Disk bölümünü aktif duruma getiriyoruz. Location olarak profillerin yönlendirilecek olduğu ve hazırlamış olduğumuz dizin olan \\DC01\Col1UserProfile UNC yolunu gösteriyoruz.

Bu bölüm de yönlendirilmesi gerekli duyduğumuz profil bilgilerini (desktop, documents, link, music vb…) seçiyoruz ve veya bütün profili olduğu gibi yönlendiriyoruz. Seçmediğimiz profil nesneleri makale başın da belirtmiş olduğumuz problemle karşılaşacaklardır. İhtiyaçlarımıza bağlı olarak profil nesnelerini seçebildiğimiz gibi profil içinde bulunan dosya türlerine izin verebiliyor veya yasaklayabiliyoruz. Örnek vermemiz gerekirse desktop klasörüne izin verdik ama bu klasör içinde bulunan mp3 uzantılı dosyalar taşınmasın gibi kuralları oluşturabiliyoruz. Folder redirection teknolojinden bildiğimiz özellikler. izin verdik ama bu klasör içinde bulunan mp3 uzantılı dosyalar taşınması gibi kuralları oluşturabiliyoruz.

Her bir RDS kullanıcısı için 20 GB boyutunda maximum disk boyutunu belirledik. Bundan daha fazla alana ihtiyacımız varsa yükseltebiliriz İhtiyaçlarımıza göre yapılandırmamızı bitiriyoruz ve bu bölümden çıkıyoruz.

clip_image010

User Profile disk bölümüne baktığımız zaman UVHD-template ismin de bir tane virtual harddiskin oluştuğunu görebilirsiniz.

clip_image011

Yapılandırma sonrasında kullanıcımız oturum açıyor.

clip_image012

Kullanıcımız oturumu açtıktan sonra dizinimiz de yeni bir tane vhdx dosyasının oluştuğunu görebilirsiniz. Bu vhdx dosyası UVHD-Kullanıcımızın benzersiz olan etki alanı SID numarasıdır.  Oluşturulan vhdx dosyası Dynamically teknolojisindedir. Belirlemiş olduğumuz 20 GB alana kadar büyüyecektir. Online olarak küçülmeyecektir. Bu sebepten ötürü maksimum size boyutunu iyi planlayıp vermemiz gerekmektedir.

UPD Yapılandırmamızdan sonra kullanıcı deneyimini inceleyelim.

clip_image013

Col1Rds1 isimli RDS kullanıcımız RDSH01 isimli sunucumuza bağlandı, işlemlerini yaptı, verilerini oluşturdu-değiştirdi ve işlemlerini bitirdikten sonra RDS oturumunu kapattı.

clip_image014

Başka bir zamanda Col1Rds1 isimli RDS kullanıcımız RDSH02 isimli sunucumuza bağlandı. Kullanıcımızın verileri ortak bir havuz içinde barındığı için kullanıcımızın oturumuna bu veriler tekrardan geldi ve kullanıcımız veri yönetiminde bir zorluk yaşamadı.

Kullanıcımızdan bağımsız olarak RDS ortamını yönetecek olan kişilerin yapması-yapmaması gerekli olan işlemlerden bahsedelim.

clip_image015

RDS kullanıcımız RDS ortamına bağlı durumdayken RDS kullanıcımız için oluşturulan vhdx dosyasını mount edemezler.

clip_image016

Eğer bu vhdx dosyasını mount etmeye çalışırlarsa karşılaşacakları hata yukarıdadır. Mount edilmek istenilen vhdx dosyası RDS kullanıcısı tarafından kullanılmaktadır.

clip_image017

RDS kullanıcımız RDS farmına bağlı durumda değilken kullanıcımızın vhdx dosyasını mount edebilirler ve RDS kullanıcımızın verilerini görebilirler.

clip_image018

RDS ortamının yöneticisi verileri gördü ve yapması gerekli olan işlemleri yaptı. Bu işlemler bittikten sonra mutlak suretle mount edilen diski eject etmek durumundadır.

clip_image019

Eğer mount edilen vhdx dosyası eject edilmezse, RDS kullanıcımız RDS farmına bağlandığı zaman verilerine ulaşamayacak, vhdx dosyasını açamadığı için (başka bir yerde mount olduğu için) kullanıcımız oturumda kaldığı süre içinde geçici profil ile kullanımını sağlayacaktır.

UPD yapılandırmasında yaşanılan en büyük problemlerin başında bu gelmektedir. Özel bir durum olmadığı sürece kullanıcı vhdx dosyasının mount edilmesini önermemekteyim.

Folder Redirection teknolojisine göre yaşayacak olduğumuz bir diğer problem ise kullanıcı verilerinin yedeklenmesi. Kullanıcılarımızın verilerinin yedeklenmesi bir file server yedeklenmesi kadar kolay değil. Bizler için kullanıcı verisi artık bir vhdx olduğu için dosya, dokuman bazında yedekleme işlemi yapmak bir hayli zor durumda. Bu durum ise yedeklemede ve veri havuzunda ciddi yer kayıplarını getirmektedir.

Windows Server 2012 R2 ile birlikte RDS ortamları üzerinde de Online Data deduplication ve Tiered storage spaces teknolojisi kullanılabilir duruma geldi, R2 öncesi Windows server 2012 için bu teknoloji desteklenmemektedir.

clip_image020

Etki alanımız içinde bulunan Col1RDS1 kullanıcımızın SID bilgisini kontrol ediyoruz.

clip_image021

Bu sid bilgisini öğrendikten sonra hangi vhdx dosyasının hangi kullanıcımız için oluşturulduğunu görebilmek için hazırlanan bir Windows Power Shel komutunu sizler ile paylaşıyorum. Bu PS komutunu Retrieve usernames for a User Profile Disks (UPD) share in VDI environment yolu üzerinden temin edebilirsiniz. Daha basit bir ara yüzün hazırlanmasını bende beklemekteyim.

Bu makale içinde RDS ortamı içinde bulunan kullanıcılarımızın verilerinin yönetimi ve güvenliğinin sağlanması için yapılması gerekli olan teknolojileri, artıları-eksileri, yapımıza göre tercihleri sunmaya çalıştım ve kullanabileceğimiz son güncel teknoloji olan UPD yapılandırmasını sizlere paylaştım. Yedekleme, alan büyümesi, güvenliği, erişimi, harcayacak olduğumuz çabayı ve en önemlisi ihtiyaçlarımızı belirledikten sonra en uygun çözümü bulabileceğinizi düşünüyorum.

İlgili Makaleler

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Başa dön tuşu