RDS, VDI ve Azure Virtual Desktop: Masaüstü Sanallaştırma Seçimi

Masaüstü sanallaştırma projeleri genellikle yanlış sorudan başlar: “RDS mi, VDI mı, AVD mi?” Doğru soru, sunulacak uygulamanın çok kullanıcılı Windows Server üzerinde çalışıp çalışmadığı ve profilin nerede duracağıdır. Üç model, yani Windows Server üzerinde oturum tabanlı Remote Desktop Services (RDS), kullanıcıya ayrı Windows istemci VM’i veren VDI ve Microsoft’un yönetilen hizmeti Azure Virtual Desktop (AVD), bu iki soruya farklı cevap verir. Aşağıda üçünü uygulama uyumluluğu, profil yönetimi, lisans ve altyapı yükü üzerinden karşılaştırıyor, sonda bir kapasite hesabı örneği veriyoruz.

Masaüstü sanallaştırma modelleri

Temel ayrım, bir işletim sistemi örneğini kaç kullanıcının paylaştığıdır:

• Oturum tabanlı (RDS Session Host): Tek bir Windows Server örneğinde çok sayıda kullanıcı eşzamanlı oturum açar. Kaynak verimliliği en yüksek modeldir; ama tüm kullanıcılar aynı işletim sistemini, aynı kurulu uygulamaları ve aynı kaynakları paylaşır.
• Havuz VDI (pooled): Kullanıcı her oturumda havuzdaki uygun bir Windows istemci VM’ine bağlanır; VM’ler ortak bir görüntüden türetilir, kullanıcıya özgü veri profil çözümünde tutulur.
• Kişisel VDI (personal): Her kullanıcıya kalıcı olarak atanmış bir VM vardır. Kullanıcı kendi uygulamasını kurabilir; yönetim yükü ve kaynak tüketimi en yüksek modeldir.
• Azure Virtual Desktop: Bağlantı aracısı, ağ geçidi ve web erişimi gibi kontrol katmanını Microsoft işletir; oturum hostları Azure’da (veya Azure Local üzerinde) çalışır. Hem çok oturumlu hem kişisel masaüstü sunabilir.

Kararı çoğu zaman uygulama verir. Çok kullanıcılı Windows Server’ı desteklemeyen, kullanıcı başına donanım kilidi kullanan veya yerel yönetici hakkı isteyen bir uygulama RDS’i baştan eler. Tek bir ERP istemcisini ya da ofis uygulamalarını onlarca kullanıcıya sunmak ise oturum tabanlı modelin en güçlü olduğu yerdir. Pilotu uygulamayla başlatın, altyapıyla değil.

RDS mimarisi ve rol hizmetleri

Windows Server’daki RDS dağıtımı birbirine bağlı rol hizmetlerinden oluşur:

Küçük bir dağıtımda Connection Broker, Web Access ve Licensing aynı sunucuda çalışabilir; ancak o sunucu tek arıza noktası olur. Connection Broker yüksek erişilebilirliği için ortak bir SQL Server veritabanı (veya Azure SQL Database) ve DNS kaydı gerekir. RD Gateway, internete açık bırakılan bir RDP portunun yerine kullanılmalı ve çok faktörlü doğrulamayla birleştirilmelidir. RDP’nin (TCP 3389) doğrudan internete yayımlanması kabul edilebilir bir yöntem değildir. Tartışmaya da açık değildir.

# Temel oturum tabanlı dağıtım (RemoteDesktop modülü)
New-RDSessionDeployment -ConnectionBroker "rdcb01.corp.local" `
  -WebAccessServer "rdweb01.corp.local" `
  -SessionHost "rdsh01.corp.local","rdsh02.corp.local"

New-RDSessionCollection -CollectionName "Ofis" `
  -SessionHost "rdsh01.corp.local","rdsh02.corp.local" `
  -ConnectionBroker "rdcb01.corp.local"

Set-RDLicenseConfiguration -LicenseServer "rdlic01.corp.local" `
  -Mode PerUser -ConnectionBroker "rdcb01.corp.local"

RDS lisans sunucusu etkinleştirilmeden dağıtım 120 günlük başlangıç süresiyle çalışır. Süre bittiğinde lisans dağıtılamayan bağlantılar reddedilir. Sahada sık rastlanan senaryo budur: Kurulum aylar önce yapılmış, lisans sunucusu unutulmuş, bir pazartesi sabahı kimse bağlanamıyor. Lisans sunucusunu kurulumun ilk haftasında etkinleştirip CAL’leri yükleyin.

VDI: kişisel ve havuz masaüstleri

Şirket içi VDI kullanıcıya gerçek bir Windows 10/11 istemci deneyimi verir. Masaüstü uygulamaları istemci işletim sisteminde test edildiği için uyumluluk sorunları azalır, kullanıcılar birbirinin kaynak tüketiminden daha az etkilenir. Bedeli sunucu ve sistem altyapısı ile işletim yüküdür:

• Her VM kendi işletim sistemi belleğini ve diskini taşır; aynı kullanıcı sayısı için oturum tabanlı modele göre belirgin biçimde daha fazla kaynak gerekir.
• Görüntü (image) yönetimi, güncelleme dalgaları ve aynı anda başlayan antivirüs taramaları “boot storm” ve “update storm” etkisi yaratır; depolama tasarımı ortalamaya değil bu tepelere göre yapılır.
• Kişisel masaüstlerinde her VM ayrı bir yönetim nesnesidir; yama, yedekleme ve envanter bir masaüstü filosu gibi yönetilmelidir.

Windows Server Hyper-V üzerinde Microsoft’un tam VDI aracı RDS’in Virtualization Host rolüdür; büyük ölçekli havuz yönetimi, görüntü dağıtımı ve otomatik ölçekleme gereken projelerde üçüncü taraf VDI platformları da değerlendirilir. Platform ne olursa olsun VM boyutlandırma ilkeleri değişmez; ayrıntılar sanal makine boyutlandırma yazısında.

Azure Virtual Desktop

AVD’de bağlantı aracısı, ağ geçidi, web istemcisi ve tanılama katmanı Microsoft tarafından işletilir; siz oturum hostlarını, depolamayı ve ağı yönetirsiniz. Oturum hostları ters bağlantı (reverse connect) kullandığı için hostlara internetten gelen port açmanız gerekmez.

AVD’de karar verirken bakılacak noktalar:

• Windows 11 Enterprise multi-session: Birden fazla kullanıcının aynı anda oturum açabildiği istemci işletim sistemi yalnızca Azure’da ve Azure Local’de desteklenir. RDS’in kaynak verimliliğini istemci uygulama uyumluluğuyla birleştirir.
• Host havuzları: Havuz (pooled) veya kişisel olarak tanımlanır; havuzda yük dengeleme “breadth-first” (kullanıcıları hostlara yay) veya “depth-first” (bir hostu doldurup sonrakine geç) olarak seçilir. Depth-first, otomatik ölçeklemeyle boştaki hostları kapatıp maliyeti düşürmeye uygundur.
• Kimlik: Oturum hostları Active Directory’ye veya Microsoft Entra ID’ye katılabilir; kullanıcı kimliği her iki durumda Entra ID üzerinden doğrulanır.
• Maliyet kalemleri: Hesaplama (VM saatleri), diskler, profil depolaması (Azure Files veya Azure NetApp Files), ağ çıkışı ve isteğe bağlı yedekleme. Kontrol katmanı için ayrıca ücret alınmaz; lisans koşulu sağlanmalıdır.

Güncel özellik ve gereksinimler için Azure Virtual Desktop dokümantasyonu esas alınır.

Lisans ve profil yönetimi

Lisans gereksinimleri

Ofis uygulamalarını paylaşımlı ortamda çalıştırmak ayrı bir başlıktır: Microsoft 365 Apps’in RDS veya çok oturumlu hostta kullanılması “shared computer activation” gerektirir ve bu özellik yalnız belirli abonelik planlarında vardır. Projede sonradan fark edilen lisans eksiği çoğunlukla budur. Kuralların ayrıntısı ve plan karşılaştırması için Microsoft 365 lisans seçimi ve sanallaştırmada Windows Server lisanslama yazılarına bakın. Lisans koşulları değişebildiği için satın almadan önce Microsoft’un güncel ürün koşullarını doğrulayın.

FSLogix ile profil yönetimi

Havuz modellerinde (RDS, havuz VDI, çok oturumlu AVD) kullanıcı her seferinde farklı bir hosta düşebilir; profilin hosttan bağımsız olması gerekir. FSLogix, kullanıcı profilini bir SMB paylaşımındaki VHDX dosyasında tutar ve oturum açılışında yerel profil gibi bağlar. Klasik roaming profile’a göre oturum açılışı daha hızlıdır; Outlook önbelleği, OneDrive ve Teams verisi gibi büyük içerikleri sorunsuz taşır. FSLogix kullanım hakkı, yukarıdaki tablodaki uygun lisanslara sahip kullanıcılar için ek ücret gerektirmez.

reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VHDLocations /t REG_MULTI_SZ /d "\\fs01.corp.local\profiles$" /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VolumeType /t REG_SZ /d VHDX /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v SizeInMBs /t REG_DWORD /d 30000 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v DeleteLocalProfileWhenVHDShouldApply /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v FlipFlopProfileDirectoryName /t REG_DWORD /d 1 /f

Profil paylaşımının NTFS izinleri, kullanıcının yalnızca kendi klasörünü oluşturup erişebileceği şekilde ayarlanır. Geniş “Everyone: Full Control” izniyle açılmış profil paylaşımı sahada hâlâ karşımıza çıkıyor; bu, her kullanıcının başkasının profil diskine erişebilmesi demektir. Profil depolaması tek bir dosya sunucusuna bağlıysa o sunucu bütün masaüstü ortamının tek arıza noktasıdır. Yüksek erişilebilir SMB (Scale-Out File Server, Azure Files) veya FSLogix Cloud Cache değerlendirilmelidir. Ayarların tam listesi FSLogix dokümantasyonunda.

Karşılaştırma tablosu

AVD seçildiğinde şirket içi uygulama ve dosya sunucularına erişim gecikmesi belirleyici olur. Masaüstü Azure’da, ERP veritabanı şirket içindeyse her sorgu WAN bağlantısını geçer; kullanıcı bunu “AVD yavaş” diye bildirir. Masaüstü suçsuzdur. Uygulama sunucularının da buluta taşınması veya kaliteli bir site-to-site bağlantı planı kararın parçasıdır.

Kapasite hesabı örneği

Aşağıdaki hesap yöntemi göstermek içindir; değerler varsayımdır ve gerçek projede pilot ölçümle değiştirilir.

• Toplam kullanıcı: 150; aynı anda bağlı en yüksek kullanıcı (varsayım): 120.
• Oturum hostu boyutu: 8 vCPU, 48 GB bellek.
• Pilot sonucu (varsayım): Bir host, hedef yanıt süresini koruyarak 20 eşzamanlı ofis kullanıcısı taşıyor.

Hesap: 120 ÷ 20 = 6 host. Bir host bakımda veya arızalıyken hizmetin sürmesi için N+1 ile 7 host gerekir. Toplam kaynak 7 × 8 = 56 vCPU ve 7 × 48 = 336 GB bellektir. Profil depolaması için kullanıcı başına 30 GB üst sınırla teorik tavan 150 × 30 = 4,5 TB’dir; ancak VHDX dinamik büyüdüğü için başlangıç kapasitesi pilot kullanıcıların gerçek profil boyutlarından hesaplanır, tavan kota planına girer.

Pilot sırasında oturum hostunda işlemci kuyruğu, bellek kullanımı, disk gecikmesi ve oturum açılış süresi birlikte izlenir. Video konferans, tarayıcı tabanlı yoğun uygulamalar ve Teams kullanımı kullanıcı başına kaynak ihtiyacını belirgin biçimde artırır; Teams için VDI optimizasyonunun (medya işlemenin istemci cihaza aktarılması) etkin olduğunu doğrulayın. Optimizasyon kapalıysa video çağrısı oturum hostunun CPU’sunu yer.

Şirket içi RDS ve VDI altyapısının tasarımı için sanallaştırma ve veri yönetimi, Azure Virtual Desktop projeleri için Microsoft 365 ve Azure hizmetleri sayfamıza bakabilirsiniz.

Sık sorulan sorular

RDS için hangi lisanslar gerekir?

Oturum hostlarının çalıştığı sunucular için Windows Server lisansı, sunucuya erişen her kullanıcı veya cihaz için Windows Server CAL ve ek olarak RDS CAL gerekir. RDS CAL kullanıcı veya cihaz başına alınabilir ve RD Licensing sunucusu üzerinden dağıtılır.

Windows 11 çok oturumlu sürümünü kendi Hyper-V sunucuma kurabilir miyim?

Hayır. Windows 11 Enterprise multi-session yalnızca Azure Virtual Desktop kapsamında Azure’da ve Azure Local üzerinde desteklenir. Şirket içi Hyper-V üzerinde çok kullanıcılı masaüstü için Windows Server tabanlı RDS kullanılır.

FSLogix kullanmak için ayrı lisans almak gerekir mi?

Hayır. FSLogix, uygun Microsoft 365, Windows Enterprise, Windows VDA veya RDS CAL/RDS kullanıcı aboneliği lisansına sahip kullanıcılar için ek ücret olmadan kullanılabilir. Güncel uygunluk listesini Microsoft’un FSLogix dokümantasyonundan doğrulayın.

RDS mi AVD mi daha ucuzdur?

Tek bir doğru cevap yoktur. RDS’te donanım, lisans ve işletim maliyeti peşin ve sabittir; AVD’de hesaplama ve depolama kullanım bazlı ödenir, kontrol katmanının işletimi ortadan kalkar. Çalışma saatleri belirli ve otomatik ölçekleme kullanılabiliyorsa AVD avantajlı olabilir; sürekli tam yükte çalışan ortamlarda şirket içi RDS maliyeti daha öngörülebilirdir.