Меня зовут Алексей Климашенко, я в компании Avito занимаюсь обеспечением качества продуктов на платформе 1С. Моя работа включает в себя QA, мониторинг, повышение стабильности и производительности – все, что нужно для обеспечения качества.
Расскажу о проекте по переходу на PostgreSQL и Linux у нас в компании.
Небольшая ремарка: до этого я во всех своих выступлениях делился опытом о том, что делал сам – разбирался, делал и потом об этом рассказывал. Этот же проект огромен: он длился 9-10 месяцев, его делала большая команда – несколько наших внутренних продуктовых команд, системные администраторы, подрядчики, даже фирма «1С» была туда вовлечена. И я сейчас с большим уважением и благодарностью ко всем, кто делал этот проект, попытаюсь о нем рассказать.
В докладе будет:
-
Техническая часть перехода на Linux+PostgreSQL – что делали и как настраивали.
-
Нюансы лицензирования и архитектуры – какое программное обеспечение мы выбрали, как оно лицензируется и что желательно учесть.
-
Опыт, опыт, опыт – что мы узнали за 10 месяцев реализации этого проекта в Avito.
Чего в докладе точно не будет:
-
Я не буду рассказывать о процессе управления этим проектом с точки зрения организации работы команд и их взаимодействия.
-
Не будет оценки и сравнения подрядчиков – мы в рамках этого проекта общались с большим количеством компаний, но это оставим за скобками.
-
Не будет непреложной истины. Любое внедрение крупной информационной системы – это всегда уникальная история. Я расскажу о нашем опыте перехода. У вас что-то может не взлететь или будет работать по-другому – к этому нужно быть готовыми.
Подготовка к переходу
Проект перехода на Linux и PostgreSQL у нас стартовал летом 2022 года. Но зачем мы решили что-то менять, если все и так классно работало на MS SQL? Наверное, ответ очевиден, но я бы хотел его озвучить:
-
Мы боялись столкнуться с ограничениями на использование ПО – что в какой-то момент наши виндовые сервера с MS SQL превратятся в тыкву и вообще ничего не смогут обрабатывать.
-
Мы в тот момент уже столкнулись со сложностями при попытке оплатить продление лицензий MS SQL на ядра – у нас перестали ставиться обновления.
-
Мы боялись столкнуться с рисками остановки бизнес-процессов – если, не дай Бог, когда-нибудь неожиданно остановится MS SQL, у нас не будет возможности прыгнуть куда-то быстро с нашей базой 2 терабайта, и мы не сможем сдать вовремя какую-нибудь реготчетность.
-
И отдельно я упомянул здесь ценности компании, потому что Avito всегда старается действовать масштабно и смело – это записано у нас прямо в ценностях. К нам пришли руководители AvitoTech и сказали: «Мы переходим на PostgreSQL и Linux. Меняем все сразу и оптом – заверните, пожалуйста».
Вот так мы решаем проблемы – приняли решение и пошли делать.
Расскажу отправную точку – с чего проект начался.
В названии моего доклада говорится об одной базе на 2 терабайта. На самом деле переезжали сразу все продовые базы – у нас шесть основных баз, их параметры представлены на слайде. Есть еще несколько мелких, но я их здесь не учитываю.
-
Основная, самая большая и проблемная база – это Управление холдингом. Ее текущий размер – 1,77 терабайта. В начале проекта она была 2 терабайта, потом мы ее немного подрезали. Непосредственно в системе через тонкий клиент работает 300 пользователей.
-
В ДО по факту работают все сотрудники Avito – более 6000 человек. Но они в основном работают через интеграцию – для этого у нас есть отдельный фронт. А в саму систему ДО ходят только 500 пользователей.
-
Серверы приложений 1С были на Windows Server 2019. Они были не отказоустойчивые, не резервированные – просто 5 серверов, на которых располагались эти 6 баз.
-
И был MS SQL в виде отказоустойчивого кластера Always on – это такая связка серверов, где один работает, а при его падении подключается второй.
Мы собрались летом 2022 года и решили переходить. Наш план был таким:
-
переносим базы на PostgreSQL;
-
разворачиваем серверы 1С на Linux;
-
и идем праздновать, потому что PostgreSQL и Linux официально поддерживаются 1С, и проблем быть не должно.
Но, как оказалось, знали мы далеко не все.
PostgreSQL – тяжелые будни админов
Мы разделили проект на две крупных части:
-
переезд с СУБД MS SQL на PostgreSQL;
-
и перенос сервера 1С на Linux.
Как потом оказалось, такое разделение было правильным решением.
Свое погружение в обширный мир PostgreSQL мы начали с выбора редакции. Неожиданно оказалось, что у PostgreSQL есть как минимум два варианта, которые нам пришлось рассмотреть:
-
«Ванильный» PostgreSQL – непосредственно доступный всем open source проект, он еще называется Vanilla.
-
Postgres Pro – коммерческий продукт, разрабатываемый нашими российскими коллегами.
Здесь важно отметить, что работа в продакшене крупной информационной системы 1С на PostgreSQL практически невозможна, потому что концепция изначального PostgreSQL не подразумевает такую архитектуру базы данных – что в базе данных будет несколько тысяч таблиц и сумасшедшее количество индексов, как мы любим в нашей самой лучшей платформе в мире. Из-за этого обычный PostgreSQL при стандартных настройках с платформой 1С работает исключительно плохо.
Забегая вперед, Postgres Pro работает хорошо. Основные его плюсы можно рассказать четырьмя пунктами:
-
Сжатие данных на уровне строк. Он очень хорошо жмет данные, база у нас не растет так, как на PostgreSQL, занимает меньше места на диске. Это очень хорошо – и с точки зрения бэкапирования, и для эксплуатации системы.
-
Postgres Pro намного лучше держит в СУБД большое количество соединений, когда сервер 1С создает их в огромных количествах.
-
Он лучше работает с бэкапами – у него есть встроенная утилита pg_probackup, об этом расскажу позже.
-
Главное в Postgres Pro – это русская поддержка 24/7. Когда вы будете внедрять новую СУБД для крупной информационной системы, вам обязательно понадобится поддержка. И когда есть люди, которые при проблемах с СУБД могут помочь здесь и сейчас – это суперценно.
Пару слов про деньги и ядра. Особенности лицензирования:
-
Postgres Pro – платный продукт. Наверное, это единственный его минус по сравнению с «ванильным» PostgreSQL.
-
При этом Postgres Pro стоит намного дешевле MS SQL, и лицензируется разово – мы платим только за ядра, которые хотим лицензировать.
-
Поддержка приобретается отдельно, и ее покупка не обязательна.
Когда мы выбирали СУБД, у нас было требование по отказоустойчивости – мы хотели иметь такой же отказоустойчивый кластер, как у нас был на MS SQL, чтобы при падении одной из нод подключалась вторая, и все продолжало работать. Забегая вперед, мы хотели сделать отказоустойчивое решение не только на уровне СУБД, но и на уровне сервера 1С.
Перед переносом базы 1С на PostgreSQL нужно будет проанализировать в ней производительность запросов. Правда информации об этом у самой фирмы «1С» совсем немного. На «ИТС» есть раздел «Особенности эксплуатации PostgreSQL», и там только две рекомендации касаемо кода:
-
Особенности использования виртуальной таблицы СрезПоследних – нам запрещают использовать соединение с виртуальной таблицей СрезПоследних. Совсем запрещают. Говорят, что в большинстве случаев это будет работать медленно и плохо. Если вспомнить самый холиварный вопрос, который постоянно всплывает на форумах: «Можно ли в запросе делать соединение с виртуальной таблицей?», то здесь дан ответ – нельзя.
-
Использование конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ – коллеги из фирмы «1С» рекомендуют не использовать полное внешнее соединение. Если честно, когда я это увидел, то пытался вспомнить, использовал ли я вообще когда-то за свою 15-летнюю практику полное внешнее соединение в запросе 1С и не смог такого вспомнить. Тем не менее, если у вас такое было, вам придется это переписать.
По поводу всего остального фирма «1С» ничего не говорит, подразумевая, что все должно работать на PostgreSQL так же, как и на MS SQL. Но, как обычно, есть нюансы – с этими нюансами мы столкнулись, когда перекатили базу на PostgreSQL.
Часть запросов, особенно больших и тяжелых, у нас стали работать медленнее. Они не отвалились, база не упала, все продолжало работать, но они стали работать медленнее.
И это самый важный момент, который нужно помнить при переходе – PostgreSQL гораздо требовательнее к качеству написания запросов по сравнению с MS SQL. PostgreSQL не прощает ошибок, которые прощает MS SQL – нельзя бездумно создавать в запросах десятки соединений или использовать составные поля. На PostgreSQL придется запросы оптимизировать.
Что мы сделали: Прогнали в тестах наши ключевые операции, посмотрели, где стало медленней и отрефакторили запросы. На этом подготовка и наш переход на PostgreSQL был завершен. Кроме рефакторинга запросов и настройки самого PostgreSQL (его окружения и настроечного файла), мы больше ничего с ним не делали.
Если у вас в системе уже настроен APDEX – есть список ключевых операций и инструменты замеров – вам будет намного легче. Вы перенесете базу на PostgreSQL, увидите, где у вас стало медленнее, и пойдете это рефакторить.
У нас APDEX в готовом виде не было, поэтому мы делали просто сплошной тест, и по ощущениям искали, где стало медленнее.
База переносится на PostgreSQL через DT-шник, плюс сейчас фирма «1С» сделала в утилите ibcmd отдельную команду replicate, которая позволяет перенести данные напрямую из MS SQL в PostgreSQL, минуя конфигуратор и выгрузку в DT.
После запуска прода на PostgreSQL мы столкнулись с несколькими нюансами.
Первый нюанс – это бэкапы. У PostgreSQL есть утилита pg_dump, которая позволяет делать бэкапы. Причем ее возможности отличаются для «ванильного» PostgreSQL и для Postgres Pro.
-
В стандартном варианте pg_dump для ванильного PostgreSQL есть очень интересный нюанс – если у вас данные в одной ячейке превышают 512 мегабайт, бэкап никогда не выгрузится. А платформе 1С все равно, сколько сложить в ячейку – она в хранилище значений может сложить хоть сколько. Например, в типовых конфигурациях БП КОРП и УХ в хранилищах значений хранятся реготчеты, и один реготчет в виде двоичных данных может запросто занимать гигабайт, а то и полтора. При этом «ванильный» PostgreSQL не может выгрузить больше 512 мегабайт через pg_dump – у вас не будет бэкапа. База будет работать, все будет функционировать, но бэкапа не будет.
-
У Postgres Pro в 2022 году было ограничение в 1 гигабайт, в 2023 году они сделали 2 Гб – в принципе, все 1С-ные потребности покрываются.
Мы продолжили рефакторинг запросов, это стало для нас некоей рутиной. Мы находили медленные запросы уже на проде, их рефакторили и тем самым делали нашу систему лучше.
Мы работали с настройками самого PostgreSQL. Здесь большое спасибо нашим админам, которые первые полгода после перехода прода на PostgreSQL крутили всевозможные настройки. Одна из них даже вынесена на слайд – random_page_cost, потому что она в какой-то момент нам очень сильно помогла. Этот параметр помогает планировщику запросов устанавливать цену для поиска оптимального запроса.
Мы разбирались с бэкапами. Наверное, на эту тему можно сделать отдельный доклад, но скажу очень коротко:
-
Утилита pg_probackup делает бэкапы целыми инстансами – например, в одном инстансе 5 баз, у вас будет бэкап всех 5 баз сразу. Таким же образом он его и разворачивает. Поэтому сначала у нас был один инстанс для всех баз, а потом мы разнесли его на несколько.
-
И утилита PTRACK, с которой пришлось разобраться, – это инкрементальный бэкап. Если в MS SQL инкрементальный бэкап настраивается внутри кора, то здесь это отдельные утилиты, с которыми вашим админам тоже придется поработать.
В целом мы перевели СУБД на PostgreSQL примерно за два месяца с небольшим. Полет был отличный.
Мы хорошо ускорили запросы – понятно, что тут сыграл роль рефакторинг, но без перехода на PostgreSQL мы вряд ли занялись бы им в таком объеме. Причем когда у нас система уже работала на PostgreSQL, мы смогли ее сделать в некоторых моментах еще быстрее.
Сервер 1С на Linux или суровые реалии разработки
Дальше начался переход сервера 1С на Linux. И тут разработчикам, конечно, досталось работы.
При переходе сервера 1С на Linux есть несколько важных моментов:
-
Отдельно отмечу, что мы перевели на Linux только серверную часть. Клиенты у нас работают кто откуда хочет – кто-то на Linux, кто-то на Windows, а кто-то даже на Mac OS. Плюс веб-клиент, естественно. Поэтому мы говорим о переходе только в контексте серверной части 1С.
-
Как бы это банально ни звучало, но когда вы переносите сервер 1С на Linux, вам нужен Linux-администратор. В большинстве компаний с 1С на Windows роль сисадминов выполняют сами 1С-ники, которые админят эти сервера, потому что Windows все кнопается, и все классно. Но когда вы запускаете сервер 1С на Linux, у вас в большинстве случаев нет даже графического интерфейса. При этом вам нужно подключать тома, смотреть логи, настраивать Apache. Об этом лучше подумать заранее – найти админа, взять на аутсорс или обучить своего.
-
Естественно, вместо IIS (Internet Information Services) нужно будет использовать Apache.
-
И, конечно же, потребуется рефакторинг кода. Если в контексте перехода на PostgreSQL мы говорили про возможное замедление системы, то при переезде сервера 1С на Linux у нас возможен полный отказ и неработоспособность кода, потому что он просто не предназначен для выполнения в среде Linux.
Так выглядит наша новая связка в части публикации веб-клиента:
-
Nginx;
-
Apache;
-
и авторизация пользователя на Keycloak и OpenID протокол.
Опять же, до свидания Active Directory и IIS – они больше не работают.
Теоретически возможна авторизация через AD-шный протокол на Apache плюс Kerberos, но, честно, мы всей командой не смогли ее настроить. Мы пытались, привлекали фирму «1С», но эта авторизация корректно так и не заработала. Это был суперинтересный эксперимент: когда пользователь пытался авторизоваться, он получал в системе рандомный логин. Мы даже в какой-то момент запустили это на проде, и там начался хаос и шатание.
Nginx здесь – это балансировщик для корректнрой работы отказоустойчивого кластера 1С, чтобы пользователи не замечали смену серверов для публикации баз, HTTP-сервисов или любой другой функциональности, которая торчит наружу через веб.
Мы провели обследование кода, посмотрели, что не будет работать на Linux, и определили для себя следующие направления рефакторинга:
-
Конечно же, нужно рефакторить любую функциональность, которая реализована через вызов командной строки либо powershell – она на Linux работать не будет. VBS-скрипты для вызова паузы, батники и другие внешние программы, которые у вас вызывались из кода – все это сразу же отвалится.
-
Любые внешние компоненты, зависящие от ОС – наверняка в ваших конфигурациях есть куча вызовов внешних компонент, которые привязаны к Windows. Для Linux им нужно искать альтернативу. У нас в ДО такой компонентой, например, был Image magic.
-
COM-объекты. Наверняка их много кто еще использует. Соединение с другими базами через COM, работа с Excel через COM, работа с любым объектом через COM – все это работать перестанет.
-
Использование локальных каталогов в серверном коде. Разработчики 1С очень любят написать в серверном коде: «Возьми файл в каталоге C:\Temp». Соответственно, никакого C:\Temp на Linux нет, и больше это использовать не получится.
-
Отдельным пунктом выделено использование не универсальных разделителей пути. У Linux и у Windows разные разделители пути: «/» (прямой слэш) и «\» (обратный слэш). Если вы задаете разделители пути в коде, на Linux это работать не будет. Вместо этого используйте типовую функцию БСП «ПолучитьУниверсальныйРазделительПути» – она возвращает корректный слэш, потому что привязана к операционке.
-
И рефакторинг работы с Excel/Word – это самые частоиспользуемые внешние компоненты, с которыми работает 1С. Здесь нужно либо использовать механизмы платформы, либо переходить на взаимодействие с этими продуктами через XML-формат без всяких COM-объектов.
Я обещал не говорить в докладе про взаимодействие внутри команды, но, видимо, руководитель разработки во мне жив, и я не могу это не упомянуть.
Буквально несколько рекомендаций для руководителя разработки и тех, кто будет управлять разработкой в проекте:
-
Заранее готовить библиотеки. Под библиотеками имеются в виду универсальные методы для часто используемых возможностей: пауза, работа с FTP и все остальное, что может быть в ваших системах. Эти библиотеки нужно приготовить заранее. Потому что потом, если библиотека у вас не готова, каждый начнет костылить свое, говорить: «Ой, они же не приготовили мне библиотеку, я сейчас напишу свою, она будет лучше».
-
Максимально переиспользовать код. Раз уж мы начали рефакторинг, делаем максимально переиспользуемый код.
-
Договориться, где и как разработчики синхронизируются. Это была боль на первых этапах, когда у нас разработчики разных систем придумывали свои методики для работы с чем-либо. Приходилось их синхронизировать. Это задача руководителя разработки либо того, кто этим управляет.
-
Самые сложные участки нужно делать в первую очередь, их нельзя оставлять на потом – здесь принцип Парето не работает. По секрету вам скажу, что у нас интеграция с одним из банков жила на Windows еще полгода после перехода сервера 1С на Linux. Там выполнялся скрипт, и он с Linux не хотел работать до последнего. Мы этот кусок кода мучили, наверное, год, потому что вначале его пропустили и сказали: «Там же скрипт, мы его как-нибудь в Linux запустим». Обратите на это внимание, пожалуйста.
Как вы думаете, какая библиотека была самая жарко обсуждаемая? Пауза. Мы собрали, по-моему, пять совещаний, чтобы решить, как сделать паузу на Linux.
РКЛ и большой брат
Немного про нашего большого брата – фирму «1С».
Мы получаем КОРП-обслуживание в фирме «1С», и нам с ними, наверное, чуть проще общаться. Тем не менее в фирму «1С» обращаться надо. Есть кейсы, которые вы сами не решите никак. Ни вы, ни подрядчики, ни франчайзи. Есть проблемы, с которыми может вам помочь только фирма «1С».
На слайде приведены три кейса, которые фирма «1С» нам помогла решить на этом проекте:
-
Проблемы с аутентификацией. Они настроили нам стенд, мы проработали все логи и решили проблему с аутентификацией через веб.
-
Падение rphost.
-
Зависание http-отладки в тех версиях платформы, которые мы сначала использовали.
Текущий статус и первые итоги эксплуатации спустя 6 месяцев
Итоговая схема, которая у нас получилась, показана на слайде. Мы завершили переход на Linux – у нас сейчас Linux Debian 11 и Postgres Pro.
-
У нас отказоустойчивый кластер серверов 1С в двух дата-центрах.
-
Для PostgreSQL у нас тоже отказоустойчивый кластер в двух дата-центрах – есть мастер и реплика.
-
Справа вы видите отдельный островок, который подписан как сервер для журнала регистрации и полнотекстового поиска. На самом деле это большая сеть виртуальных серверов на Linux, построенная на среде виртуализации Proxmos. Они также сделаны отказоустойчивыми и разнесены на два дата-центра. Туда через ТНФ вынесена функциональность журнала регистрации и сервиса полнотекстового поиска, плюс там живут всякие мелкие базы.
Заключение
Итак, что мы сделали?
-
Перевели весь рабочий контур на PostgreSQL и Linux.
-
Сделали отказоустойчивый кластер 1С.
-
Сделали отказоустойчивый кластер Postgres Pro.
-
Замерили производительность: она выросла, системы стали работать быстрее.
-
Провели учения по отказоустойчивости.
Все это реально работает.
Здесь на слайде – мои рекомендации.
Самый важный пункт здесь – привлекайте экспертов, если есть возможность. С некоторыми проблемами вы будете разбираться неделями, если у вас нет человека, который это знает.
Здесь я отдельно хотел бы сказать огромное спасибо Антону Дорошкевичу и его команде за помощь в реализации этого проекта. Думаю, что их помощь сократила нам время реализации этого проекта на несколько месяцев.
Вопросы и ответы
Расскажите подробнее про авторизацию – как вы ее в итоге сделали?
У нас большинство пользователей ходит в систему через веб-клиент, у них все просто:
-
Они переходят по единой ссылке, которая не привязана к конкретному серверу – эта ссылка живет в Nginx.
-
Потом они попадают на страницу авторизации Keycloak – это просто клиент авторизации, который соединен с OpenLDAP.
-
Вводят там свою обычную учетку от компа, и дальше токен пробрасывается в 1С и бесшовно авторизует пользователя.
Авторизация по большому счету такая же, как и была на Windows, только теперь это другой провайдер.
Автоматизировали ли вы какое-то сценарное или нагрузочное тестирование?
Нагрузочное тестирование мы делали локально – какие-то куски кода, которые нам нужно было под нагрузкой протестить, под них писались отдельно обработки, чтобы нагрузить систему.
И дополнительно мы использовали дымовые тесты – Vanessa-ADD и Vanessa Automation, чтобы просто прогнать в системе и посмотреть, где чего отвалилось.
Вы сказали то, что «ванильный» PostgreSQL от 1С плохо работает с 1С. Но у нас в «Почтатехе» все работает на «ванильном» PostgreSQL от 1С. И у нас все работает хорошо. На основании чего сделаны такие выводы? Какое-то тестирование проводилось, какие-то замеры?
Именно здесь Postgres Pro оказалось очень эффективным решением. – мы просто попали в сценарий, где Postgres Pro лучше.
В «Управлении холдингом» есть особенность – две огромных таблицы. С ними «ванильная» PostgreSQL очень тяжело шевелилась, Postgres Pro Enterprise справился в разы лучше. Да, можно было изменить структуру базы данных, всем убиться, переписать все запросы, но по стоимости оказалось проще перейти на Enterprise-версию Postgres Pro.
Еще сыграло свою роль сжатие, потому что при переходе с MS SQL на PostgreSQL не столько страшен рефакторинг кода – его сделают, в любом случае все будет работать. Страшнее потом обслуживать без сжатия систему бэкапирования а-ля pro_backup для терабайтных баз. Вам для разработки придется закупить много 10-терабайтных полок – это просто застрелиться.
И стратегически Postgres Pro иногда быстрее – у него другой планировщик. Слава Богу, нам не пришлось применять pg_hint_plan и reload_plan, но думали, что придется еще и это делать – это то, чего вообще в «ванильной» версии в принципе не существует.
Самое главное – техподдержка. Потому что проблемы точно будут. Но если не будет, то отлично, повезло.
А как перетаскивали базу?
Через .dt.
Сколько времени заняла выгрузка?
Выгрузка самой большой базы у нас заняла 7 часов.
На тот момент работоспособной возможности выгрузки через ibcmd не было, но уже была многопоточная заливка .dt. Поэтому долго .dt сливался, но заливался гораздо быстрее.
7 часов – это нормальное техокно, база в 2 терабайта успела уехать.
Вы затронули у авторизации сервис Keycloak. Он у вас уже существовал или вы его разворачивали для интеграции?
Существовал, он изначально использовался клиент авторизации почти для всех сервисов внутри Avito.
Вы в докладе обратили особое внимание на параметр стоимости рандомного поиска. Вам помогло увеличение или уменьшение этого параметра? И как вы его меняли?
Нам помогло уменьшение с 4 до 1,1. У нас СХД было на твердотельных накопителях All-Flash, и производительность с уменьшением параметра резко выросла.
Вы сказали, что рефакторили код при переходе на Linux и оптимизировали запросы под PostgreSQL. А была ли работа именно по изменению структуры базы данных? Изменение полей объектов, может быть, создание новых вместо старых?
Разработчики 1С любят складывать в поля таблиц двоичные данные очень большого объема. Мы эту возможность ограничили на уровне кода – сделали из хранилища данных сжатое хранилище. По нему искать теперь нельзя, но зато оно занимает 80 мегабайт.
Рассматривали ли вы другие виды PostgreSQL? Например, у Astra Linux есть свой Tantor.
Нет, не рассматривали. На тот момент Tantor 1С-ом вообще не поддерживался. Он поддерживается только с платформы 8.3.22, а на момент перехода не поддерживался.
И Tantor идет в составе Astra, которая не является корпоративным стандартом у Avito. У Avito корпоративный стандарт – Debian 11, и отдельно нет особого смысла ставить Tantor.
Внедрение было в 2022 году, а тогда было намного меньше возможностей для внедрения чего-либо другого. И было меньше информации. Сейчас информации и поддерживаемых дистрибутивов больше.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT.
