Remote Desktop Connection Broker Role ilk kurulduğu zaman Windows Internal Database kullanmakta ve Basic RD Deployment ortamları için ihtiyaçlarımızı karşılmakta. Fakat Advanced RDS Deployment alt yapısına ihtiyaç duyduğumuz zaman Remote Desktop Connection Broker Database üzerinde değişiklik yapılmalı ve bu değişiklik için de bir çok sorunun cevaplanması gerekmekte.
Uzakmasa üstü mimarisinin hizmet verdiği kullanıcı profili, kullanıcı erişim noktaları ve şirketlerin sahip olduğu mevcut bilgi işlem varlıkları Remote Desktop Connection Broker Database seçimine etki edecek sorulardır.
Öncelikle performansdan bahsedelim. Windows internal database mimarisi küçük ölçekli Remote Desktop ortamlarına cevap verse bile mimari büyüdüğü zaman yetersiz duruma gelecek. Performans nedeniyle ve daha kararlı çalıştığı için Windows Internal Database mimarisinden SQL veri tabanına geçiş işlemini yapmalıyız. Bu geçiş işlemi Remote Desktop High Availability ihtiyacı değil, daha kararlı ve daha performanslı olduğu için yapılması önerilmekte.
Performans için yapılan dönüşümde SQL Server ‘in ücretisz sürümü SQL Express sürümü kullanılabilir. Bu mimaride RD Connection Broker sunucusu Remote Desktop ortamında tek bir tane olacak ve yedekli mimariye sahip olmayacaktır. Bu öneri de sadece Remote Desktop Connection Broker veri tabanını SQL Express üzerine aktardık.
RD Connection Broker seviyesinde yedekli bir mimariye sahip olmak istiyorsak Remote Desktop ortamına ikinci Remote Desktop Connection Broker Role ekleyebilir ve bu rol seviyesinde yedekli bir yapıya sahip olabiliriz. SQL Express bu ihtiyaca da cevap verecektir. Fakat, bu mimaride SQL sunucunun tek olması büyük bir risktir. Bu risk, Connection Broker seviyesinde yedekli bir mimariye sahip olsak bile veri tabanı sunucu seviyesinde tek düğüm hatasına bağlı kalacağız.
Bu riskin önüne geçebilmek için SQL Server Express mimarisi yerine SQL Server Standart sürümünün yada Azure SQL Database kullanılması gerekmekte.
SQL Server 2017 ile birlikte Standart sürümü de SQL AlwaysON ‘u desteklemekte ve Enterprise sürümüne geçiş yapmadan sürekliliğe sahip olabiliriz.
Fakat burada ki diğer bir problem, Remote Desktop ortamında bulunan sunucu sayısı artmış olacak ve Remote Desktop ortamına SQL sunucuları da eklenecek ve SQL sunucusu da infrastructure katmanında çalıştığı için bizlere ek bir iş yükü getirecektir.
Bu gereksinimler Windows Server 2016 ile bitti ve Azure SQL Database artık Remote Desktop ortamları için desteklenebilir duruma geldi. Azure SQL Database Bulut bilgi işlem modelleri arasında yer alan bir Platform as a Services hizmeti ve Infrastructure gereksinimlere göre bakımı ve iş eforları çok daha azdır.
Remote Desktop Connection Broker için Azure SQL Database seçimi yada SQL Server seçimi konusunda bizleri yol ayrımına sokan nedenler de bulunmakta.
Azure SQL Database bir Platform As as Services hizmeti olduğu için ciddi bir tasarruf sunuyor olsa bile en büyük risk RD Connection Broker Role ‘nin sahip olduğu önemdir. Remote Desktop Connection Broker Role; Remote Desktop platformuna erişim yapacak olan her bir kullanıcının sahip olduğu yetkileri, bağlantı yapacak olduğu platformu, daha önce bağlantı yapmış mı, bağlantısı kopmuşmu, ne kadar süre çalışmış ve bunun gibi bir çok veriyi barındıran sıcak bir veri tabanıdır.
RD Connection Broker Role veri tabanına erişemediği zaman ön bellekten hizmet veremez. Bu gereksinim göz önüne alındığı zaman ve Azure SQL Database ’nin Azure bilgi işlem üzerinde çalıştığını düşündüğümüz zaman başka bir riske daha sahip olacağız.
Sahip olduğumuz veri merkezi ile Azure veri merkezleri farklı fiziksel veri merkezlerindey ve bağlantının kopma ihtimali Remote Desktop ortamları için büyük bir risk olacak.
Performans tarafında yetersiz duruma gelmeyiz. Sahip olacağımız en düşük seviyede ki band genişliği bile Remote Desktop Connection Broker sorguları için yeterli olacak ve Sahip olacak olduğumuz risk performans değil erişimin kopma ihtimali.
Remote Desktop Connection Broker Role ile Connection Broker Database, farklı veri mezkezlerinde barınacak ve iletişim kuramadığı zaman Remote Desktop ortamı hizmet veremeyecek.
Bu risk faktörünü sorguladığımız zaman alt sorular ortaya çıkmakta. Remote Desktop ortamına bağlantı yapan kullanıcılarımızın barınmış olduğu yerleşkeler…
Eğer Remote Desktop ortamını kullanan kullanıcılar uzak ofis yada yerleşkesi belirsiz noktalardan bağlantı yapıyorsa zaten internet alt yapımız sağlıklı ve Azure SQL database kullanımını bu sorudan sonra karar verebiliriz.
Eğer, Bağlantı yapacak olan kullanıcılar Remote Desktop ortamına yerel ağdan erişim yapıyorlarsa bu durumda önerim yerel SQL Server kullanılması.
