У меня есть заказчик, который планирует развернуть приложение на одном сервере и иметь около 100 удаленных рабочих столов пользователей на этом сервере. В настоящее время планируется 4 ГБ оперативной памяти.
Очевидно, что есть проблемы, которые можно объяснить этой идеей, но заказчик, похоже, желает масштабировать оборудование (и свои лицензии) по мере необходимости и переводить всех в автономный режим для выполнения новых развертываний ночью. Мое предложение было веб-сайтом вместо winform. Заказчик сказал, может быть, позже.
Теоретически, учитывая стандартное оборудование Windows Server - допустим, он может масштабировать до четырех четырехъядерных процессоров HT Xeon с 32 ГБ - А также учитывая, что само программное обеспечение не представляет проблемы -
Чтобы точно спланировать емкость для этого, вам необходимо изучить характеристики приложения и нагрузку, которую оно возлагает на терминал.
Во-первых, если это критически важное бизнес-приложение, которое потеряет бизнес-деньги, если оно будет недоступно в течение нескольких часов, вам следует обратить внимание на 2+ терминальных сервера, работающих параллельно. Базовая балансировка нагрузки пользователей на нескольких терминальных серверах на самом деле очень проста, вы просто выполняете циклический DNS. Преимущество здесь заключается в том, что если один TS выходит из строя по какой-либо причине, пользователи, которым срочно требуется доступ, могут продолжать получать доступ к системе. Я бы рекомендовал взглянуть на 2 или 3 сервера и убедиться, что у вас достаточно мощности в среде, чтобы выдержать потерю одного из серверов.
Что касается емкости / нагрузки, проверьте объем памяти, который сеанс пользователя занимает в TS, когда они запускают приложение. Умножьте это на количество пользователей, которых вы ожидаете разместить, добавьте, возможно, гигабайт для собственного использования системой, а затем добавьте еще 20% для удобства. Именно столько оперативной памяти вам нужно в качестве отправной точки для поддержки такого количества пользователей, запускающих это приложение на вашем TS. Вы должны рассчитывать на основе фактического пользователя, подключенного к фактическому примеру сеанса TS, потому что каждый пользователь будет занимать дополнительную оперативную память для других пользовательских процессов в дополнение к самому приложению. Эти дополнительные маленькие процессы складываются.
Затем проверьте нагрузку на обработку и характеристики приложения. Сообщают ли пользователи приложению, что нужно запускать отчеты, которые могут на короткое время привязать ЦП к 100%? Если так, то большая проблема. Масштабирование до 60 пользователей (даже на 16-ядерной машине) означает, что у вас будут пиковые периоды, когда несколько человек пытаются создавать отчеты, и все страдают.
Также учитывайте любые дополнительные приложения, необходимые пользователям системы. Довольно часто пользователи хотят выводить данные из бизнес-приложений в офисные приложения, такие как Excel. Собираются ли они для этого перетасовать вещи через общие диски, или есть требование запускать офис на самом сервере терминалов. Если это так, вам нужно знать, что а) офис лицензируется совершенно по-другому в терминальной среде, и обычные версии не будут установлены. б) Несколько сеансов Excel скоро съедают всю вашу оперативную память.
tl; dr масштабируется на нескольких серверах, а не на одном сервере
Способ на многие переменные дать окончательный ответ.
Это единственное приложение? Какие ресурсы требуются для каждого пользователя и т. Д. И т. Д.
Здесь мы запускаем TS с двумя четырехъядерными процессорами и 16 ГБ, на которых, к счастью, работает до 65 пользователей.
Теоретически вы можете решить любые проблемы с ресурсами, добавив больше оборудования, а когда одного сервера недостаточно, вы добавляете больше серверов. Но поддерживать неэффективное решение путем кормления его деньгами в какой-то момент становится непрактичным.
С одной стороны, переписывание существующего приложения в виде масштабируемой службы стоит дорого, поэтому простое развертывание его в качестве решения служб терминалов кажется более простым путем. Но, с другой стороны, решение масштабируется значительно хуже, чем что-то вроде веб-приложения.
Во-первых, решение TS «тяжелое» и стойкое. Для каждого пользователя запускается набор новых процессов, которые сохраняются до тех пор, пока этот пользователь не выйдет из системы, каждый из которых потребляет память и процессорное время сверх того, что потребляется вашим фактическим приложением. И, конечно же, приложение TS гораздо более интенсивно использует сервер, чем веб-приложение, потому что вся работа, даже рендеринг пользовательского интерфейса, выполняется на стороне сервера.
Фактические пределы сложно предсказать заранее, но вы должны иметь возможность провести некоторые стресс-тесты, наблюдая за потреблением ресурсов, чтобы получить представление о тенденциях. Но имейте в виду, что есть затраты на переключение контекста, которые действительно начинают проявляться только тогда, когда у вас есть много запущенных процессов одновременно. В какой-то момент, в зависимости от характера вашего приложения, вы можете «натолкнуться на стену» до того, как ваш процессор будет перегружен, что не может быть решено путем добавления дополнительной оперативной памяти. Это сложно предсказать заранее.
Во-вторых, что, возможно, более важно, злоупотребить сеансом TS значительно проще, чем приложением клиент-сервер. Разница настолько значительна, что часто даже не упоминается. Если бы вы планировали поездку в Антарктиду, люди не стали бы напоминать вам, что нужно собирать теплую одежду; аналогично, если вы планируете публично развернуть решение TS, люди будут просто предполагать, что вы понимаете, как защитить его, и планируете худшее. Возможностей, по которым такое решение может стать ужасно плохим, настолько велико, что их не стоит перечислять.
Тем не менее, если вы не собираетесь масштабироваться так далеко, это может быть вашим наиболее экономичным решением.