Совмещение терминального сервера с “1С”

Сначала самое главное. Для “нормальных” IT служб этот вопрос не существуют. Люди с опытом на практике выясняют почему плохо на терминальные сервера помещать другие задачи и так не делают. Но мы все прекрасно понимаем, что есть маленькие компании, а так же всегда есть те кто начинают и соответственно этого опыта не имеют. Поэтому возможно даже кому то дальше и покажется объяснение банальным, но его надо озвучить.
Рассмотрим совмещение терминалки с остальными ролями серверов с “обеих” сторон.

1. “За совмещение”.
Основная НАСТОЯЩАЯ причина совмещения ролей — это экономия денег. А если быть точным — КАЖУЩАЯСЯ экономия на старте эксплуатации.
Конечно многие сторонники приводят другие аргументы. Но они как правило в итоге всё равно “конвертируются” в дешевизну. Кстати, что будет дальше после начала эксплуатации в этот момент сторонники совмещения плохо просчитывают — позиция проста — “прорвемся как-нибудь”.

Прежде чем мы перейдем к аргументам противоположной стороны, углубимся немного в теорию.

Есть такая вещь как запас мощности оборудования в пиковые моменты. К сожалению многим администраторам не очевидно, что когда он смотрит в диспетчер задач он видит моментальный снимок (несколько минут) текущий загруженности и не видит «пиков». И не увидит.
У разных ролей сервера максимальная амплитуда между «пиком» и средним значением может сильно отличаться. В среднем по больнице, роль терминального сервера характеризуется наибольшей разницей между нагрузкой в пике и средней нагруженностью. Можно дать условное объяснение, но оно условное: руками вбивая данные (один документ раз в пять минут) очень тяжело на стороне клиентской части 1С вообще что либо нагрузить, так как манипуляции с данными, обсчет и т.п. выполняется на другом сервере (сервере 1С и субд). Т.е. пользователи делая что то руками, а это большая часть рабочего дня не сильно то и грузят терминальный сервер. Зато когда возникает некоторая локальная задача не на весь день — скопировать фильм, скачать дистрибутив, выполнить загрузку данных на клиент, да хоть тореннтом порно скачать — все это неплохо кушает ресурсы, пусть и не длительное время, но часто несколько ядер процессора грузятся целиком. А еще есть антивирус, который не должен стоять на сервере 1С (куда нет локального доступа у пользователей) , но зато антивирус обязательно должен стоять на терминальном сервере. Еще на терминальном сервере хорошим тоном последние годы должен стоять антишифровальщик. Такие «штуки» хоть и не постоянно, но иногда что то начинают проверять — новый файл, атаку портов и т.п. Вообщем, называйте это как хотите, но периодически на терминалки бывают ситуации, особенно когда железка загруженна сверхсильно. Это ведь пулл терминалок — это лишь опытные админы делают, балансируя соединения и нагрузку. Я уж молчу про dfss, квотирование ресурсов, виртуализацию и т.п. обрезающие любому потоку максимальную скорость.

1. “За разнесение”. Получается что не только надо говорить о регулировании нагрузки между ролями. Регулировать нагрузку надо между терминальными пользователями. А при количестве превышающим разумное для одного сервервера надо строить несколько терминальных серверов, раскидывая пользователей между ними.
Не совсем теория, но тоже интересный факт. Наша практика показала (а мы делаем порядка 100 аудитов в год), что пики загруженности терминальных серверов при совмещение с сервером 1С — это очень популярный вариант и оказалось что терминальные сервера не мониторятся вообще или делается это условно, но главное сильно влияют на работу других ролей сервера (сервера 1С в данном случае). Причем это не теоретическое рассуждение — выносили нагрузку на отдельный сервер и клиент подтверждал положительный результат.
2. “За разнесение”. Еще один фактор — это лицензирование. На одно и тоже количество пользователей (понятно что мы говорим не про трех человек) с учетом большой разницы в стоимости между стандартом и энтерпрайзом выгоднее собирать в пул несколько недорогих серверов, чем одну мощную “железку”. Наример, если вы лицензируете MS SQL Server, то Вам надо лицензировать ВСЕ ядра сервера, а не те, которые вы аффинити маской назначите использовать. Получается, что Вы переплатите за пользователей, который будут съедать процессоры терминальными сессиями.

3. “За разнесение”. Настоящий аргумент это безопасность. Причем это многогранная вещь. Терминальные сервера стоит активно мониторить антивирусом. Это наиболее вероятно место атаки для троянов, шифровальщиков, брутфорсов и т.п. А вот на сервер с ролью сервера 1С и субд локально лучше вообще не заходить. Консоли правления лучше запускать с другого сервера. Активно проверять антивирусом сервера 1С, их соединения — бррр. Вы скорее всего пожалеете об этом. И уж тем более “грех” на сервере 1С или субд устраивать “файловую помойку”. Впрочем в России безопасностью пока не клюнет — не занимаются, поэтому идем дальше.

4. “За разнесение”. Обычно в момент покупки сервера задача “кто будет разбираться с проблемами конкуренции за ресурсы” серьезно не воспринимается. Но на практике еще можно понять тех, кто роль сервера 1С и субд сажает на “физику”, а рядом ставит виртуалку и в неё помещает “терминальный сервер”, так хотя бы терминальные пользователи имеют меньше приоритет в борьбе за ресурсы, и их легче заквотировать. Но почему не очевидно, что чтобы квотировать надо понимать НА ОСНОВАНИИ КАКИХ МЕТРИК КАКИЕ ПРАВИЛА ПРИМЕНЯТЬ. А кто серьезно мониторит нагрузку терминальных пользователей. А тек кто могут настроить ,например “заббикс”, все равно не могут интерпретировать правильно собранные значения. Другими словами, лень — это нормальная черта админа, но надо правильно оценивать свои силы. Заизолировать нагрузку физически гораздо реалистичней, чем думать, что в процессе эксплуатации у вас вдруг откроется второе дыхание и вы найдете потайные галочки которые вернут нагрузку в норму.
Взять аналогию с кораблями. У них есть “переборки”, для того чтобы в случая пробоя ниже ватерлинии попавшая внутрь вода не распространилась по всему объему корабля и не привела к затоплению. Наивно думать, что когда этот пробой произойдет, то вы займетесь созданием этих самых перегородок. Да ни черта у Вас не будет времени/денег/знаний/желания на это занятие.

А если Вы — маленькая компания, то рядом с клиент-серверным вариантом частенько бывает файловая версия например 1С:Бухгалтерии. И эту базу надо размещать не на сервере субд, а на терминальном сервере на локальных дисках, а не по сети. Иначе вы ухудшите работу файлового варианта.

Хотите поступить правильно — лучше выбейте денег на отдельную терминалку.
Ну а если хотите глубже погрузиться в эту тему, приходите на наш тренинг http://www.gilev.ru/training/ .
Не согласны с материалом — напишите slava@gilev.ru ваши аргументы. Согласны, но у вас свои доводы, напишите их нам slava@gilev.ru. Обе позиции включим в обзорный материал выше.