Який поріг затримки для запуску термінального сервера (RDS) через WAN?

Я бачив: продуктивність сервера терміналів через високі латентні посилання

Але у мене є клієнт, який зацікавлений перенести їх системну інфраструктуру в центр обробки даних, який має ~ 62 мс затримки від їхнього головного штабу.

Навколишнє середовище складається з трійки серверів RDS для Windows Server 2008 R2, служб файлів і друку та Microsoft Exchange 2010. Це все в даний час віртуалізовано на кластері vSphere 5.5. В даний час 80 користувачів, які локально підключаються до систем RDS за допомогою тонких клієнтів HP.

Через проблеми з об'єктом та збільшення кількості користувачів, що працюють у мережі, та віддалених користувачів, є необхідність перемістити системи до центру обробки даних. На новому сайті будуть розміщені хости vSphere вищого класу та пам’яті з усіма флешками.

Підключення до об'єкта локального розташування буде встановлено через VPN від сайту до сайту з декількома провайдерами послуг і відмовою від місця.

Хоча це погана ідея? Я часто підключаюсь до цього веб-сайту для проведення робіт з обслуговування RDP та SSH, продуктивність цілком прийнятна для мого використання. Користувачі використовують базовий пакет MS Office та пару легких терміналів на основі терміналів SSH ERP.

Чи доцільно 62 мс для цього типу завантаження користувачів та Microsoft RDS?

У мене є кілька тисяч людей по всьому світу, які щодня підключають та використовують програмне забезпечення для бухгалтерії / офісу. Поки час їх відповіді становить менше 300 мс, ми не отримуємо скарг, але ymmv.

Як доказ концепції, я встановив один з комутаторів нашого користувача за допомогою linux / netem box і продовжував підштовхувати затримку / втрату пакету, поки у мене не виникли скарги. Це було багато простішого копіювання мережевих умов локально, а потім переміщення моїх програм двічі.

Я відчуваю, що це щось на зразок суб’єктивного характеру, оскільки деякі користувачі не будуть задоволені, якщо затримка не подібна до локального робочого столу, а інші користувачі будуть раді та не скаржаться, навіть якщо затримка становить 300 мс.

Це правда, що затримка - це вбивця користувальницького досвіду, хоча саме те, наскільки це залежить від індивідуального сприйняття.

Це досить хороше відео з TechEd 2014 про досвід користувачів у подібних до цього сценаріях (це відео про VDI, але це схожий досвід із службами віддаленого робочого столу.)

https://www.youtube.com/watch?v=CcKAwzebHoc&feature=youtu.be

Отже, ви можете сказати, ніколи не перевищуйте 300 мс. 62ms, ймовірно, "добре".

На це питання не можна відповісти по-справжньому універсально та об'єктивно. Результати дійсно залежать від типу завантаженості та потреб користувачів. Тут нічого не може бути краще, ніж тести на UX.

Я часто працюю віддалено над RDP з різних локацій, більшу частину часу підключаюсь через мережу LTE (4G), яка пропонує затримки, схожі на 62 мс. В цей час я перебуваю в готелі з повільним з'єднанням ~ 1 Мбіт / с та затримками ~ 27-28 мс - менше половини значення у вашому випадку. Навіть при останньому значенні мені важко переглядати веб-сайти чи переглядати велику графіку (особливо без AdBlock, сайти, багаті графікою, можуть відображатись у Firefox на кілька секунд!). Також спроба написати простий документ, що використовує Microsoft Word, викликала певну розчарування через нижчу середню відповідальність за інтерфейс (у свою чергу LibreOffice Writer почувався набагато краще). Навіть не кажучи вже про будь-яку роботу з відеороликами ... З якими я можу досить комфортно працювати - це MMC, Outlook пошта (певною мірою), перегляд файлів і загалом завдання системного адміністрування.

Це значення повинно бути добре для віддаленого адміністрування системи та подібних завдань, які ви виконуєте звичайно та маєте досвід роботи. Але якщо це повністю замінить локальний екран, я очікував би розчарування і скарг.

Ще одне, що потрібно додати - я працюю в Ubuntu, коли rdesktop 1.7.1 є моїм клієнтом RDP на вибір. У оригінальному клієнті Майкрософт (або в інших) можуть бути деякі оптимізації, які можуть підвищити продуктивність при високому затримці.

Затримка на відстань до 100 мс, ймовірно, не буде проблемою, якщо ваші клієнти не будуть грати через цю мережу . Але у деяких, графічно інтенсивних додатків (особливо для відтворення відео) вам може не вистачити пропускної здатності, які негативно впливатимуть на затримку та висунуть її понад 100 мс, дратуючи користувачів.

RDP 8 (Server 2012 і пізніші версії) постачається з оптимізаціями (читайте: алгоритми стиснення втрат) для цих сценаріїв. Крім того, підтримка транспорту UDP покращить користувацький досвід роботи над посиланнями із значно різними затримками або помітними втратами пакетів (> 0,1%). Тож якщо у вас є щось із цього, ви можете оновити хости своїх сеансів RD.