Кластер терминальных серверов 1С: как не положить всех бухгалтеров одним сбоем

Я почти пятнадцать лет вижу одну и ту же картину: компания покупает нормальный сервер, ставит на него терминальную службу, сажает туда бухгалтерию, отдел продаж, кладовщиков — и живёт спокойно. Пока сервер не падает. А он падает всегда не вовремя: в конце квартала, перед сдачей отчётности, в день инвентаризации. Дальше расскажу, почему один терминальный сервер — это мина замедленного действия, и как мы у клиентов эту мину обезвреживаем через кластер из нескольких RDS-хостов.

Почему один сервер — это всегда вопрос времени

Смотрите, как устроен типичный терминальный сервер в компании на 20-30 рабочих мест. Один физический сервер или одна виртуалка. На нём Windows Server, роль RDS, база 1С, иногда SQL Server тут же рядом. Все сотрудники заходят по RDP на один и тот же хост. Удобно, дёшево, один админ всё понимает. И это работает годами — ровно до того момента, пока что-то не сломается.

А ломается многое. Слетела лицензия RDS CAL после планового обновления — и вход запрещён всем разом. Упал диск в RAID-массиве без резерва — сервер не грузится, а бэкап последний раз проверяли полгода назад. Зависла служба терминалов из-за утечки памяти в каком-то фоновом процессе — придётся перезагружать сервер посреди рабочего дня, и все 25 человек одновременно теряют несохранённые документы в 1С. У одного клиента, юрфирмы на 18 человек, ровно так и было: в четверг в 15:40 сервер завис намертво, юристы час сидели без единого документа, а срок по делу был в этот же день до 18:00. Успели, но нервы потрепали всем.

Проблема не в том, что сервер плохой. Проблема в архитектуре — вернее, в её отсутствии. Один сервер = одна точка отказа. И неважно, насколько дорогое железо вы купили: если это единственная точка входа для всех, рано или поздно она откажет, и остановится весь бизнес одновременно.

Что такое кластер RDS-хостов на практике

Идея простая, как в любой нормальной инженерии: не складывать все яйца в одну корзину. Вместо одного сервера на 30 пользователей делаем два-три сервера поменьше, объединённых в ферму (в терминологии Microsoft — RD Session Host farm, или коллекция сессий). Пользователь подключается не напрямую к конкретной машине, а через RD Connection Broker — брокер подключений, который сам решает, на какой хост его пустить, с учётом текущей загрузки.

Если один хост из фермы падает — пользователи, которые были на нём, переподключаются и попадают на живые серверы. Заново логинятся, теряют максимум последний несохранённый документ, а не весь рабочий день. Остальные сотрудники вообще ничего не замечают, потому что сидели на других хостах. База 1С при этом чаще всего живёт отдельно, на выделенном сервере SQL — и это тоже важно, я к этому вернусь.

У нас в компании подобная схема стоит на собственной инфраструктуре ITfresh Finance: восемь RDS-хостов под бухгалтерию, распределённых на разных площадках. Когда на одном из хостов вылезает проблема — а она вылезает, железо и софт не идеальны нигде — остальные семь продолжают работать, и клиенты этого просто не видят. Ровно тот эффект, который мы продаём заказчикам.

Сколько это стоит и когда окупается

Вот тут начинается самое интересное — деньги. Клиенты сразу спрашивают: получается, вместо одного сервера нужно покупать два-три? Да, но не обязательно таких же мощных. Смысл не в дублировании один в один, а в грамотном распределении нагрузки. Условно: вместо одного сервера с 32 ядрами и 128 ГБ памяти можно взять три сервера послабее, каждый по 12 ядер и 64 ГБ, и раскидать по ним пользователей группами по 10-15 человек.

По деньгам для компании на 40-50 рабочих мест переход с одного мощного сервера на кластер из трёх обычно добавляет 250-400 тысяч рублей единовременно на железо или облачные мощности, плюс небольшая наценка за настройку фермы и брокера подключений — у нас это в среднем 60-90 тысяч рублей работ. Звучит как трата. Но давайте посчитаем, во что обходится простой. Если встаёт терминальный сервер на 40 человек на четыре часа в разгар рабочего дня — это, по грубой прикидке, 40 человеко-часов простоя. При средней стоимости часа сотрудника в 800-1000 рублей это уже 32-40 тысяч рублей прямых потерь, не считая сорванных сделок, просроченных платежей, недовольных клиентов на телефоне. А если сбой пришёлся на день сдачи отчётности в ФНС или Соцфонд? Там счёт может пойти на штрафы, а это совсем другие суммы.

Отдельно скажу про облако. Многим клиентам не нужно покупать три физических сервера — мы разворачиваем ферму на виртуальных машинах в дата-центре, и там доплата за отказоустойчивость получается ещё скромнее, потому что не надо резервировать железо целиком, хватает грамотного распределения VM по разным хостам виртуализации.

Что дублировать, а что нет — не всё нужно размножать в три раза

Тут важный нюанс, который часто упускают, когда сами пытаются что-то такое настроить. Терминальные хосты — не единственное узкое место. Есть ещё сервер баз данных, сервер лицензий 1С, файловое хранилище. Если вы раскидали RDS на три машины, а SQL Server остался один-единственный без резерва — вы просто перенесли точку отказа на шаг дальше, а не убрали её.

Мы обычно советуем такую логику: терминальные хосты дублируем всегда, это дёшево и даёт максимальный эффект на количество затронутых пользователей. Сервер 1С и SQL — тут смотрим на бюджет клиента. Полноценный отказоустойчивый кластер SQL Server (AlwaysOn) — это уже совсем другие деньги, от 150 тысяч рублей и выше только по лицензиям, плюс сложность администрирования. Для компании на 30-40 человек чаще достаточно просто настроенного резервного копирования с малым RPO — раз в 15-30 минут через Veeam или штатные средства SQL — и чёткого плана восстановления за 20-30 минут на резервное железо, а не постоянно работающего второго боевого SQL-сервера.

Ключевые серверы, которые точно нельзя дублировать в лоб, но нужно защищать иначе — это контроллер домена. У одного клиента, производственной компании, был единственный DC, и когда он лёг, перестала работать не только 1С, но и вообще вход в Windows у всех, включая RDS-хосты — служба Kerberos развалилась целиком. После этого случая мы всем клиентам ставим минимум два контроллера домена, это отдельная тема, но она напрямую связана с отказоустойчивостью терминального кластера — без второго DC вся ваша красивая ферма RDS всё равно ляжет вместе с единственным контроллером.

Лицензии CAL — про что все забывают, пока не выключат

Отдельная головная боль при переходе на несколько хостов — лицензирование. RDS CAL (клиентские лицензии на доступ к терминальному серверу) считаются на пользователя или на устройство, и в кластере их нужно раздавать через централизованный сервер лицензирования RD Licensing, а не привязывать к каждому хосту отдельно. Я видел случаи, когда компания честно купила CAL-лицензии, но настроила их криво — каждый хост фермы пытался выдавать лицензии сам по себе, и через 120 дней грационного периода начинались случайные отказы в подключении у отдельных пользователей. Со стороны это выглядит как необъяснимый глюк, а на деле — банальная нехватка лицензий на конкретном хосте.

Возьмите за правило при переходе на кластер сразу выделять отдельный сервер лицензирования (можно виртуальный, ресурсов много не надо) и подключать к нему активированный ключ лицензирования от Microsoft через открытый интернет или прокси. Это займёт полдня работы админа, а сэкономит вам месяцы странных жалоб от бухгалтерии на то, что «иногда не пускает».

Как мы переводим клиента с одного сервера на кластер без остановки работы

Пугает клиентов обычно не сама идея кластера, а мысль «а вдруг во время миграции всё встанет ещё сильнее, чем сейчас». Понимаю, сам бы переживал. Поэтому расскажу, как это делаем мы, чтобы было спокойнее.

Сначала разворачиваем новые терминальные хосты параллельно старому серверу — он продолжает работать как обычно, никто его не трогает. На новых хостах ставим и настраиваем 1С, проверяем производительность, гоняем тестовых пользователей вечером или в выходной. Потом настраиваем брокер подключений и коллекцию сессий, подключаем сервер лицензирования. Дальше переводим пользователей группами — сначала пять-семь человек из отдела, который проще всего перенести, смотрим неделю, как работает. Если всё гладко — переводим следующую группу. Старый сервер держим в резерве ещё месяц-полтора, вдруг что-то всплывёт с правами доступа или печатью документов.

На практике у клиента среднего размера, 30-40 рабочих мест, весь переход занимает от двух до четырёх недель, и почти всё это время текущая работа идёт без сбоев — люди даже не всегда замечают момент переключения, кроме того, что при следующем входе видят новый адрес подключения или новый ярлык RDP на рабочем столе.

Частые вопросы

Сколько минимум серверов нужно, чтобы это называлось кластером?
Формально достаточно двух терминальных хостов и брокера подключений, но на практике для компании от 20 человек мы рекомендуем три — так при выходе из строя одного нагрузка на оставшиеся два не становится критической. Для 10-15 человек иногда хватает и двух хостов с ручным резервным сценарием без полноценного брокера.

Можно ли сделать такой кластер в облаке, а не на своём железе?
Да, и мы чаще именно так и делаем — виртуальные машины в дата-центре обходятся дешевле собственного резервного железа, а физически они уже размещены на разных хостах виртуализации у провайдера, что само по себе добавляет отказоустойчивости. Единственное условие — уточнить у провайдера SLA и реальное распределение VM по разным физическим узлам, а не просто поверить на слово.

Что будет с открытыми документами 1С у пользователя, если его хост упадёт?
Несохранённые изменения в текущем документе, скорее всего, потеряются — это особенность любой терминальной сессии, не только кластера. Но пользователь за 10-20 секунд переподключится через брокер на другой хост фермы и продолжит работу с той же базой 1С, не дожидаясь, пока кто-то вручную поднимет упавший сервер.

Стоит ли переходить на кластер, если у нас всего 10-12 рабочих мест?
Обычно для такого размера я советую сначала укрепить резервное копирование и план быстрого восстановления упавшего сервера за 30-40 минут — это дешевле и часто достаточно. Полноценный кластер начинает окупаться по деньгам и нервам где-то с 20-25 одновременных пользователей, когда простой одного сервера означает реальный удар по всей компании разом.