1С на Astra Linux и Альт: что работает, что ломается и во что обходится переезд

Приветствую вас, коллеги!

Тема, вокруг которой много и агитации, и паники. Одни говорят «переходите немедленно, Windows скоро отключат», другие - «на Linux ваша 1С встанет колом». Правда, как обычно, посередине и зависит от деталей.

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

Сразу про заинтересованность

Честно, как обычно: я на этом зарабатываю. Установка и настройка 1С на отечественных ОС - одна из наших услуг, и статья в том числе про то, что мы умеем.

Поэтому в тексте будет раздел «кому это не нужно» и раздел «чего мы не делаем». Если бы я хотел вам просто продать переезд, я бы их не писал.

Зачем вообще уходить с Windows

Причин по-настоящему три, и они очень разные по весу.

Первая: требование сверху. Госсектор, компании с государственным участием, субъекты КИИ. Здесь вопрос «зачем» не стоит - стоит вопрос «к какому сроку». Реестр отечественного ПО, требования ФСТЭК, аттестация информационной системы. Если вы в этой категории, вы это знаете и без меня.

Вторая: лицензии. Windows Server и клиентские лицензии RDS сейчас покупаются сложно, продлеваются еще сложнее, а купленное живет ровно до того момента, пока работает активация. Я про это уже писал в материале про терминальный сервер и 120-дневный льготный период. Linux эту проблему снимает целиком: платить за саму ОС либо не нужно вовсе (Debian, Ubuntu), либо это разовая покупка у российского вендора с понятной поддержкой.

Третья: обновления и безопасность. Обновления безопасности для Windows в России приходят непредсказуемо. Российские дистрибутивы обновляются штатно, а у Astra Linux Special Edition есть сертификат ФСТЭК - то, что в принципе невозможно получить для импортной ОС.

Вот эти три причины настоящие. Если ни одна из них к вам не относится - читайте следующий раздел.

И одна причина, которая не работает

«На Linux будет быстрее».

Не будет. Скажу прямо, потому что это главный миф, который мне приходится разбирать на первой же встрече.

Связка «1С + PostgreSQL на Linux» на одинаковом железе проигрывает связке «1С + MS SQL на Windows» примерно 5-15 процентов. Не в разы, не катастрофа - но проигрывает. На маленькой базе вы этого не заметите, на базе в 200 гигабайт с полусотней пользователей заметите.

Откуда берется разница: PostgreSQL под 1С требует отдельной настройки, которую MS SQL делает сам; планировщик запросов ведет себя иначе; часть типовых запросов 1С исторически оптимизирована под MS SQL.

Разницу можно почти полностью отыграть нормальной настройкой PostgreSQL и железом. Но именно отыграть, а не получить выигрыш. Я сам, если помните по прошлой статье, отношусь к миграции на PostgreSQL без восторга - и именно поэтому не буду вам врать, что вы что-то разгоните))

Правильная формулировка звучит так: переезд на Linux - это не про скорость. Это про независимость от лицензий и про соответствие требованиям.

Кому это не нужно

Раздел, после которого часть читателей уйдет. И хорошо.

Файловая база на 3-5 человек. Вы сидите на обычных Windows-компьютерах, база лежит в сетевой папке, все работает. Переезд принесет вам только новые проблемы. Не трогайте.

Нет никаких требований сверху и лицензии уже куплены. Если у вас лежит легально купленный Windows Server с оплаченными CAL и он работает - выжимайте из него все до конца срока. Переезд ради переезда - это потраченные деньги и месяц нервов.

У вас много самописных внешних компонент и COM-обмена. Каждая такая штука на Linux - отдельное расследование. Иногда это лечится за час, иногда упирается в «переписывать». Про это подробнее ниже.

Некому это сопровождать. Linux-сервер, за которым никто не смотрит, через полгода превращается в мину. Windows в этом смысле прощает больше. Если у вас нет ни своего админа, ни подрядчика, и вы не планируете ни того ни другого - лучше не начинать.

Три дистрибутива и как между ними выбирать

Официально поддерживаемых 1С отечественных систем несколько, но на практике выбор идет между тремя.

Astra Linux Special Edition 1.7 / 1.8. Единственная из трех, у которой есть сертификат ФСТЭК вплоть до первого уровня доверия. Если вам нужна аттестованная система - вопрос выбора закрыт, берите Astra SE. Плюс к тому это самый распространенный вариант, а значит больше документации и больше людей, которые с ней работали.

Нюанс: у Astra SE есть режимы защиты - базовый «Орел», усиленный «Воронеж» и максимальный «Смоленск». Чем выше режим, тем больше ограничений на то, как ведет себя система, и тем аккуратнее надо настраивать 1С. В «Смоленске» вещи, которые в обычном Linux делаются одной командой, требуют отдельной проработки. Это нормально, но это время.

ALT Сервер 10 / 11. Мой личный фаворит для среднего бизнеса без формальных требований. Своя репозиторная база, собственный менеджер пакетов, хорошая документация на русском, поддержка в том числе Эльбруса. Ставится и настраивается заметно проще, чем Astra в защищенном режиме, а для обычной компании защита уровня «Смоленск» и не нужна.

РЕД ОС 7.3 / 8. Из семейства RHEL. Сильно распространена в госсекторе и у субъектов КИИ. Если вы работаете с госзаказчиками и они уже на РЕД ОС - логично быть на ней же.

И честно про импортные. 1С официально работает на Debian, Ubuntu Server LTS и RHEL-совместимых. Технически это рабочий и бесплатный вариант. Но если мотив переезда - импортозамещение и реестр, то Ubuntu вам этот мотив не закрывает. Смысл есть только тогда, когда вы уходите от Windows ради лицензий, а не ради требований.

Как выбирать, если коротко: есть требования регулятора - Astra SE. Работаете с госзаказчиками на РЕД ОС - РЕД ОС. Во всех остальных случаях - ALT.

Что на Linux работает

Список короче, чем кажется по страшилкам.

• Сервер 1С:Предприятие - полностью, все режимы.
• PostgreSQL со сборкой от 1С или Postgres Pro - это штатный вариант, а не костыль.
• Тонкий клиент - есть нативная сборка под Linux.
• Конфигуратор - работает.
• Веб-клиент через Apache - работает, и это часто лучшее решение для рабочих мест. Модули расширения веб-сервера 1С выпускает только под Apache и IIS; nginx в этой схеме ставится перед Apache обратным прокси - под SSL и балансировку, - но саму публикацию делает все равно Apache.
• Сервер лицензирования, HASP-ключи - работают, через драйверы от Etersoft.
• Регламентные задания, обмены, публикация сервисов - работают.

То есть ядро системы переносится целиком. Проблемы начинаются на периферии.

Что не работает или работает не так

Вот здесь надо быть внимательным, потому что именно на этих пунктах проекты уходят в срок вдвое больше запланированного.

MS SQL остается на Windows. Тут есть тонкость, в которой путаются. MS SQL Server для Linux в системных требованиях 1С присутствует, но с оговоркой: он поддерживается только тогда, когда рабочие серверы самой платформы 1С работают на Windows. То есть связка «сервер 1С на Windows плюс MS SQL на Linux» допустима, а «сервер 1С на Linux плюс MS SQL» - нет.

Практический вывод от этого не меняется: если на Linux уезжает сам сервер 1С, то уезжает и база - на PostgreSQL. Две миграции одновременно, и это надо закладывать в план.

COM-соединения. Все, что построено на COM - внешние обработки, интеграции со сторонними программами, обмен через COM-объекты - на Linux не живет. Переделывается на веб-сервисы или HTTP-сервисы. Иногда это полдня, иногда неделя.

Внешние компоненты. Компонента, собранная под Windows, под Linux не запустится. Нужна сборка под Linux от разработчика компоненты. Если разработчик доступен - вопрос решается. Если компонента писалась восемь лет назад человеком, который давно ушел, - это может стать стоп-фактором для всего проекта.

Толстый клиент в обычном режиме. Под Linux он есть, но часть возможностей управляемого приложения там ведет себя иначе. Для типовых конфигураций это не проблема, для старых нетиповых - проверяйте отдельно.

Офисные документы. Печатные формы, выгрузки в Excel, обмен с Word - на Linux это LibreOffice, и совпадение форматирования с Microsoft Office не стопроцентное. Сложные печатные формы надо проверять глазами.

Мое правило: до начала проекта составляется список всех внешних компонент, всех COM-интеграций и всех нетиповых печатных форм. Это первое, что мы делаем на обследовании, и именно этот список определяет, будет проект простым или тяжелым.

Оборудование и печать - главная боль

Если в проекте что-то и срывает сроки, то это оно.

Принтеры. Драйверы под Linux есть не у всех моделей, особенно у офисных МФУ среднего класса и у старых лазерников. Часть решается через CUPS и универсальные драйверы, часть - через сервер печати на отдельной машине, часть - только заменой принтера.

Торговое оборудование. Онлайн-кассы, сканеры штрихкодов, терминалы сбора данных, весы, принтеры этикеток. Драйверы под Linux у большинства крупных производителей есть, но версии отстают, и работают они не всегда так же, как под Windows. Сканер как «клавиатурное» устройство заработает почти всегда; сканер, который должен общаться с 1С через драйвер, - как повезет.

Криптография и электронная подпись. КриптоПро CSP под Linux существует и работает, но настраивается иначе, и токены (Рутокен, JaCarta) требуют отдельных драйверов. Работоспособно, но это отдельный этап работ, а не «поставили и забыли».

Как мы это обходим. В половине проектов оборудование остается на Windows-машине, а на Linux уезжает только сервер с базой. Пользователи при этом работают через тонкий клиент или через веб-клиент, а касса и сканер подключены к обычному компьютеру рядом. Такой гибрид дает 90 процентов выгоды при 30 процентах головной боли, и я предлагаю его чаще, чем полный переход.

Правда про производительность

Цифры, чтобы разговор был предметным.

На одинаковом железе PostgreSQL под 1С уступает MS SQL примерно 5-15 процентов. На тяжелых отчетах и закрытии месяца разрыв больше, на повседневных операциях почти незаметен.

Почему разрыв сокращается после настройки. PostgreSQL из коробки настроен консервативно - под маленькую машину. Основное, что делается руками:

• shared_buffers - 25-30 процентов оперативной памяти;
• work_mem - в районе объема памяти, деленного на 32-64, с поправкой на число соединений;
• max_connections - 500-1000, и это рекомендация вендора, а не «побольше на всякий случай»: сервер 1С держит на одного пользователя не одно соединение с базой, а несколько - рабочие процессы, фоновые задания, регламентные операции;
• отключение или тонкая настройка online_analyze и plan_cache_mode под 1С;
• настройка autovacuum - на активной базе 1С дефолтный autovacuum не справляется, и база начинает пухнуть;
• pg_stat_statements и auto_explain - чтобы потом было по чему разбирать медленные запросы.

Без этой настройки PostgreSQL проигрывает MS SQL не 10 процентов, а в разы. И вот отсюда растут все истории про «поставили Linux, и 1С встала». Обычно вставала не 1С и не Linux, а PostgreSQL с заводскими параметрами на 128 гигабайтах памяти, из которых он использовал 128 мегабайт.

Минимальные требования по железу, чтобы не было сюрпризов: 4 гигабайта памяти - это абсолютный минимум для тестового контура, 8 - рабочий минимум, реально считайте от 16 и выше в зависимости от базы. Два ядра от 2 ГГц - минимум, нормально - от четырех. Диск - только SSD, и не меньше 80 гигабайт под систему плюс место под базу с трехкратным запасом.

Как это ставится на самом деле

Без скриншотов и без копипасты команд - расскажу логику, чтобы вы понимали, за что платите, если отдаете это подрядчику.

Шаг первый: сеть и имена. Сервер должен корректно разрешать собственное имя. Звучит банально, но именно на этом спотыкается половина самостоятельных установок: сервер 1С не стартует, а в логе невнятное. Правится в /etc/hosts за минуту - если знать, где искать.

Шаг второй: PostgreSQL. Ставится не любой, а сборка с патчами от 1С или Postgres Pro. Дальше - разрешение подключений в pg_hba.conf, listen_addresses, пароль для роли postgres. И сразу настройка параметров из раздела выше, а не «потом, когда будет медленно».

Шаг третий: платформа 1С. Ставится из установщика с явным перечислением компонентов - сервер, языки, при необходимости клиент. Отдельно - шрифты, иначе печатные формы будут разъезжаться, и обновление кэша шрифтов.

Шаг четвертый: служба сервера 1С. Регистрируется в systemd, включается автозапуск. Здесь же - права на каталоги и на пользователя usr1cv8. Это место, где чаще всего оставляют дыру: сервис работает под лишними правами, потому что так быстрее заработало.

Шаг пятый: лицензии. HASP-ключ - драйверы от Etersoft. Программная лицензия - привязка к железу, и вот тут внимательно: смена конфигурации виртуальной машины может ее сбить. Резервный пин-код должен быть у вас на руках до начала работ, а не после.

Шаг шестой: оборудование, печать, криптография. Самый длинный этап, см. раздел выше.

Шаг седьмой: перенос базы, проверка, нагрузочный тест. Выгрузка-загрузка через dt на большой базе может идти много часов, и это надо планировать на выходные.

И шаг восьмой, который пропускают почти все: резервное копирование. На Linux это pg_probackup или pg_dump по расписанию плюс архивирование WAL, если нужна точка восстановления на любой момент. База без проверенного бэкапа - это не работающая система, а отложенная авария. Я про это писал отдельно и повторю здесь: бэкап, который ни разу не разворачивали, бэкапом не считается.

Безопасность: то, ради чего все и затевается

Раз уж переезжаете - логично сделать сразу нормально, а не «как было, только на Linux».

Что мы делаем на таких проектах по умолчанию:

• Разделение прав. Сервис 1С работает под отдельным пользователем с минимально необходимыми правами. PostgreSQL - под своим. Никаких работ под root в повседневном режиме.
• Сетевая изоляция. Порт PostgreSQL закрыт снаружи полностью, доступен только серверу 1С. Порт сервера 1С доступен только из вашей сети или через VPN. Это делается один раз и снимает целый класс проблем.
• Доступ администраторов - по ключам, а не по паролям. Парольный вход по SSH отключается, авторизация по ключу, вход под root запрещен.
• Мандатное разграничение доступа в Astra SE, если режим защиты этого требует. Это как раз то, чего в принципе нет в Windows, и то, ради чего берут Astra.
• Журналирование. Логи сервера 1С, PostgreSQL и системы собираются и хранятся. Когда что-то случится, разбираться будем по ним, а не по воспоминаниям.
• Обновления безопасности по расписанию, а не «когда сломается».
• Бэкапы в два места, одно из которых недоступно с самого сервера. Это единственная защита от шифровальщика, которая работает по-настоящему.

Отдельно скажу: безопасность - это не разовая настройка. Это состояние, которое надо поддерживать. Поэтому у нас это часть сопровождения, а не пункт в акте приемки.

Случай из практики

Типичная картина, и повторяется она у разных компаний почти дословно.

Приходит компания - оптовая торговля, 1С:УТ, база около 90 гигабайт, 25 пользователей, плюс склад со сканерами и принтером этикеток. Задача: уйти с Windows, потому что заканчиваются CAL и продлить их не получается.

Обследование занимает два дня и приносит три новости. Хорошая: конфигурация почти типовая, доработок мало и все они в расширениях. Средняя: есть две внешние компоненты - обмен с банком и работа с ТСД, и по обеим надо узнавать у разработчиков, есть ли сборки под Linux. Плохая: принтер этикеток трехлетней давности, драйверов под Linux у производителя нет и не планируется.

Что решили. Сервер переезжает на ALT Сервер с PostgreSQL - требований регулятора нет, аттестация не нужна, ALT проще в сопровождении. Компонента обмена с банком имеет сборку под Linux, вопрос закрыт. Компонента ТСД - нет, но ТСД работает через отдельную машину, и ее оставляют на Windows. Принтер этикеток остается на этой же машине.

Итог: сервер на Linux, база на PostgreSQL, пользователи через тонкий клиент, склад работает как работал. Лицензии Windows нужны только на одну машину вместо двадцати пяти.

Чего это стоило по времени: два дня обследование, один выходной на перенос базы, и еще примерно три недели с момента запуска на донастройку PostgreSQL и мелочи - печатные формы, права, расписание бэкапов. Первые две недели после переезда всегда идет поток мелких вопросов, и это нормально; ненормально, когда подрядчик после подписания акта перестает брать трубку.

Вывод, который я вынес из таких проектов: больше всего времени съедает не 1С и не Linux, а периферия. Планируйте исходя из этого.

Сколько это занимает по времени

Ориентиры, а не оферта - конкретика считается после обследования.

• Обследование и список рисков - 1-3 дня. Без этого этапа любая названная цена будет враньем.
• Установка и базовая настройка сервера - 1-2 дня.
• Настройка PostgreSQL под вашу базу - 1 день, плюс возвраты к ней после нагрузки.
• Перенос базы и проверка - от нескольких часов до полных выходных, зависит от размера.
• Оборудование, печать, криптография - от одного дня до трех недель. Разброс огромный, и это честно: он определяется вашим списком железа, а не нашей скоростью.
• Сопровождение первых недель - обязательно. Без него переезд считать законченным нельзя.

Мой практический совет: не назначайте переезд на конец месяца, конец квартала и на любой период сдачи отчетности. Звучит очевидно, но просят именно так примерно каждый второй раз))

Чего мы не делаем

Чтобы вы не тратили время, если вам нужно именно это.

Не занимаемся аттестацией информационных систем. Мы настроим Astra SE так, чтобы система соответствовала требованиям технически, но аттестацию проводит лицензиат ФСТЭК, и это не мы. Работать с ним в паре - да, делать его работу - нет.

Не пишем внешние компоненты с нуля под Linux. Если ваша компонента не имеет Linux-сборки, мы найдем обходной путь или скажем прямо, что его нет. Разработка компоненты - отдельная задача и отдельный исполнитель.

Не даем круглосуточной дежурной смены. Если авария в 3:40 должна разбираться в 3:45 - вам нужна организация с ночным дежурством.

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

Кто мы и почему берем такие проекты

Коротко и по делу.

У нас команда из десяти программистов. Это принципиальный момент для проектов такого типа: переезд на Linux - это одновременно системное администрирование, база данных, конфигурация 1С и оборудование. Один человек не бывает одинаково хорош во всем сразу, и именно поэтому мы такие задачи и берем, а частный специалист обычно нет.

Мы сопровождаем много компаний и берем новых. Работаем в формате долгого сопровождения, а не разовых визитов. Мне это выгодно ровно по той же причине, по которой выгодно вам: на своей системе, которую ведешь годами, разбираешься за минуты, а на чужой - за дни.

Что конкретно делаем по этой теме:

• обследование перед переездом со списком рисков и стоп-факторов;
• подбор дистрибутива под вашу ситуацию, а не под наши предпочтения;
• установка и настройка сервера 1С и PostgreSQL, включая настройку производительности;
• перенос базы и проверка;
• оборудование, печать, криптография и электронная подпись;
• настройка безопасности - разграничение прав, сетевая изоляция, журналирование, бэкапы в два места;
• дальнейшее сопровождение.

Подробнее про обслуживание: 1c.akernel.ru/services/it-podderzhka

Группа по 1С: https://t.me/russia1c_corp

И предложение, которое ничего вам не стоит. Напишите, какая у вас конфигурация, какого размера база, сколько пользователей и какое оборудование подключено - скажу, насколько тяжелым будет переезд и есть ли в вашем случае стоп-факторы. Иногда ответ будет «вам это не нужно», и такой ответ я тоже даю)

Читайте также: MS SQL или PostgreSQL: стоит ли мигрировать, Терминальный сервер и 120 дней, Перенос 1С на новый сервер и Ваш бэкап 1С точно рабочий?

Материал носит информационный характер. Требования к защите информации для вашей организации определяются ее статусом - уточняйте у специалиста по информационной безопасности или у лицензиата ФСТЭК.