Перенос серверной инфраструктуры 1С — это задача, требующая ювелирной точности, особенно если компания работает в режиме 24/7. Основные опасения системных администраторов связаны не только с физическим копированием данных, но и с поведением лицензий: не заблокируется ли старый сервер раньше времени и как обеспечить бесшовный переход пользователей. В этой статье мы подробно разберем алгоритм миграции, особенности программного лицензирования и технические нюансы настройки SQL Server на новом месте.
Рассмотрим сценарий: у нас есть работающий сервер с лицензионной 1С и SQL Server 2016. Нам необходимо поднять аналогичную среду на новом оборудовании. Главный вопрос — сколько времени у нас есть после активации лицензии на новом сервере до того, как она перестанет работать на старом? Проанализируем механизм проверки. Программные лицензии 1С при активации нового пин-кода из того же комплекта помечают предыдущий код как неактуальный в базе центра лицензирования. Старый сервер обращается к этому списку примерно раз в сутки. Это означает, что после запуска нового сервера у вас будет от 1 до 24 часов стабильной работы старой системы. Однако полагаться на случай нельзя, поэтому разберем максимально безопасный алгоритм.
Прежде чем отключать пользователей, подготовим "плацдарм". На новом сервере необходимо установить операционную систему и развернуть SQL Server. Важно помнить: версия SQL на новом сервере должна быть либо идентичной, либо выше (например, переход с 2016 на 2019 версию допустим, но не наоборот). Сразу настроим параметры памяти, чтобы SQL не конфликтовал с рабочими процессами 1С. Для этого в свойствах сервера SQL ограничим Max Server Memory, оставив ОС и серверу 1С минимум 4-8 ГБ оперативной памяти.
Также не забудем про настройку портов в брандмауэре. Для корректной работы нам потребуются:
SQL Server.rphost.Разберем, почему способ переноса через выгрузку в формат .dt не является оптимальным для больших баз. Выгрузка и последующая загрузка .dt — это ресурсоемкая операция, которая перестраивает индексы и может занять много времени. Кроме того, при записи в .dt иногда возникают ошибки в данных, которые "всплывают" только при загрузке. Профессиональный подход — использование средств SQL Server.
Выполним резервное копирование базы на старом сервере:
BACKUP DATABASE [Имя_Вашей_Базы]
TO DISK = N'C:\Backup\FullBackup.bak'
WITH FORMAT, INIT, SKIP, NOREWIND, NOUNLOAD, STATS = 10
Перенесем файл на новый сервер и восстановим его. Если мы хотим минимизировать простой, рассмотрим стратегию Log Shipping (перенос журналов логов) или простое восстановление с флагом NORECOVERY, чтобы в момент финального переключения докатить только последний инкрементальный бэкап.
Важный нюанс — перенос пользователей SQL. При восстановлении базы на новом сервере "логины" (учетные записи SQL) не переносятся автоматически. Чтобы не создавать их вручную и сохранить пароли, воспользуемся системной процедурой sp_help_revlogin. Это позволит нам получить скрипт создания пользователей с сохранением их уникальных идентификаторов (SID). Выясним причину важности SID: если SID пользователя в базе данных не совпадает с SID в системных таблицах сервера SQL, возникнет ошибка "orphan users" (осиротевшие пользователи).
Установим платформу 1С. Рекомендуется использовать тот же релиз, что и на старом сервере, чтобы избежать принудительного обновления тонких клиентов у пользователей в момент перехода. Теперь перейдем к самому ответственному моменту — лицензированию.
Программная лицензия 1С "привязывается" к ключевым параметрам сервера. К ним относятся:
Совет: если вы используете виртуализацию (Hyper-V, VMware), обязательно установите статический MAC-адрес для сетевой карты. В противном случае после перезагрузки гипервизора лицензия может "слететь", так как система посчитает, что оборудование изменилось.
Если у вас закончились резервные пин-коды, не паникуйте. Проанализируем ситуацию: вы имеете право запросить дополнительный пин-код в Центре лицензирования 1С (lic@1c.ru), объяснив причину замены сервера. Как правило, новый код предоставляется оперативно. Кроме того, на официальном портале 1С можно получить временную лицензию на 60 дней для проведения технических работ.
Чтобы переход прошел максимально бесшовно, применим методику "гибридного" использования. Мы можем сначала перенести только базу SQL на новый сервер, а сервер приложений 1С оставить на старом. В консоли администрирования 1С на старом сервере просто изменим адрес сервера баз данных. Это позволит проверить производительность дисковой подсистемы нового сервера без активации новых лицензий 1С.
Когда мы убедились, что SQL работает стабильно, приступаем к финальному этапу:
1C:Enterprise 8.3 Server Agent на старом сервере.nethasp.ini или обновляем списки баз у пользователей через 1CEStart.После запуска системы на новом месте обязательно выполним регламентные операции. Разберем основные шаги:
Во-первых, обновим статистику SQL, так как после миграции планы запросов могут быть неоптимальными. Выполним скрипт:
EXEC sp_msforeachtable 'UPDATE STATISTICS ? WITH FULLSCAN'
Во-вторых, настроим системную базу TempDB. Рекомендуется разделить её на несколько файлов (обычно по количеству ядер процессора, но не более 8), чтобы снизить конкуренцию за доступ к страницам данных. Это значительно ускорит работу временных таблиц, которые активно использует 1С.
В-третьих, проконтролируем работу службы rphost. Посмотрим на потребление памяти и при необходимости настроим перезапуск рабочих процессов в консоли кластера (параметры Допустимый объем памяти и Интервал перезапуска).
Резюме: Перенос сервера 1С в режиме 24/7 — задача выполнимая. Главное — помнить про 24-часовой запас жизни старой лицензии и заранее подготовить SQL-среду. Использование временных лицензий и правильная настройка параметров сервера (статические MAC-адреса, лимиты памяти SQL) гарантируют, что "переезд" пройдет успешно и без нервов.