Привет, Хабр! Я Сергей Маслаков из команды администраторов SAP BASIS в «Северсталь-Инфоком». Хочу рассказать о том, как мы научились управлять всеми ландшафтами SAP-систем из единого интерфейса, автоматизировали значительную часть рутинных задач и ускорили их выполнение. Под катом история о нашем опыте внедрения SAP Landscape Management (LaMa) 3.0, а также подробный гайд по оптимизации процесса обновления систем HANA продуктивными данными.

Почему мы решили завести LaMa

Задача нашей команды — обслуживать SAP-системы, базы данных (SAP HANA) и серверы, на которых всё это работает. Трудов постоянно прибавлялось: у компании появлялись новые проекты, становилось больше систем, разрастались ландшафты. К концу 2018 года мы едва успевали поддерживать всё это хозяйство в работоспособном и актуальном состоянии. К тому же в процессе обслуживания доступ к отдельным системам приходилось закрывать на несколько дней, что не особо радовало пользователей. Нужно было ускорить эти рутинные процедуры, найти максимально простое решение для их автоматизации.

Мы регулярно общались с коллегами из SAP, поэтому уже знали про Landscape Management. Решение сразу подкупило тем, что с его помощью прямо из коробки, не изобретая велосипед, можно автоматизировать самые актуальные для нас сценарии. И все системы под контролем: подключённые ландшафты, их компоненты и статусы визуализируются в LaMa в виде списков и таблиц. Ранее о такой централизации мы только мечтали, к каждой из систем приходилось подключаться по отдельности. Да и работать с графическим интерфейсом удобнее, чем с командной строкой.

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

Как мы приручали LaMa

Начали мы с одной из систем на HANA с объёмом данных около 5 Тб. Раньше процедура обновления тестовых систем продуктивными данными выполнялась вручную и занимала 4–5 рабочих дней. Всё это время пользователям приходилось терпеливо ждать, пока администратор:

• восстанавливал систему на точную дату и время (point-in-time recovery);

• отключал все продуктивные связи с другими системами (фоновые задания, RFC);

• восстанавливал пользователей и их полномочия на состояние до копирования;

• переименовывал все логические системы с продуктивных на тестовые;

• восстанавливал интеграции с другими тестовыми системами.

И так примерно раз в квартал.

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

1. Сохранить текущие настройки.

2. Сохранить всех пользователей и их полномочия (экспорт клиента с профилем SAP_USER).

3. Выполнить восстановление из продуктивного бэкапа в целевую систему.

4. Обновить систему с помощью мастера System refresh.

5. Восстановить настройки (которые мы сохранили в п. 1).

6. Выполнить остальные настройки.

7. Импортировать данные пользователей (из п. 2).

Проанализировали список и решили, что попробуем оптимизировать этапы 1, 5 и 6. Остальные шаги решили пока не трогать: участие администратора в них минимально, время выполнения — около 30 часов — зависит от производительности серверов, параметров сети, объёма БД.

В два раза быстрее с помощью коробочной утилиты

Чтобы автоматизировать действия вроде тех, что мы собрали в чек-листе, в LaMa предусмотрена очень удобная утилита — Post-Copy Automation (PCA). К ней прилагается набор таск-листов, сформированных под конкретные задачи в соответствии с лучшими практиками SAP. Нам нужно только заполнить параметры, которые соответствуют системе, — и LaMa пошагово выполняет все действия.

Для использования PCA нам потребовалось два таск-листа:

• экспорт-импорт настроек и данных (SAP_BW_BASIS_COPY_REFRESH_CONFIG);

• переименование всех логических систем с продуктивных на тестовые (SAP_BASIS_COPY_BDLS).

С этими пресетами мы уже значительно ускорились. Но можно и ещё лучше: таск-листы PCA легко кастомизировать, добавлять или отменять действия. Например, если шаг не нужен — убираем галочку либо удаляем всю строку. И мы выявили ряд длительных шагов, которые можно исключить за ненадобностью. Так, в целевой тестовой системе не требуется история CCMS:

За счёт сокращения шагов в таск-листах экспорт и импорт настроек удалось сократить ещё на 30–40% от полученного результата. Чтобы не удалять лишние шаги перед каждым запуском, мы сохранили обновлённый список, а вводимые параметры сохранили как вариант запуска. 

Всё это сложили в запрос и протащили по всему ландшафту. Теперь при обновлении тестовой системы продуктивными данными мы не теряем ранее сконфигурированные списки и варианты их запуска.

Автоматизировав выполнение настроек и их сохранение, мы смогли обновляться в два раза быстрее, за 2–2,5 дня. Напомню, что вручную обновление делали 4–5 дней — отчасти из-за того, что приходилось прерывать процесс по окончании смены. LaMa, в отличие от живых админов, не возражает против режима 24/7 и не ставит работу на паузу.

Не собирались, но оптимизировали. Правда, пришлось написать скрипт 

С PCA мы сократили время, которое затрачивалось на этапах 1, 2, 5, 6 и 7. А ведь мы даже не предполагали, что наша оптимизация затронет второй и седьмой этапы. Возможно, LaMa поможет улучшить процесс и на остальных этапах — 3 (восстановление из продуктивного бэкапа в целевую систему) и 4 (обновление системы с помощью мастера System Refresh)?

В LaMa есть стандартные функции работы с файловыми бэкапами, но готового решения для необходимого нам восстановления системы на конкретную точку во времени (point-in-time recovery) разработчики не предусмотрели.

Для автоматизации этого этапа мы использовали возможность переопределения шага. Написали простой скрипт, который запускал восстановление целевой системы HANA из систем резервного копирования (Backint), а в качестве параметра принимал дату и время, на которую требуется восстановление. Скрипт регистрируется через Host Agent.

В последующих версиях LaMa появилась поддержка восстановления HANA из систем резервного копирования, но выбирать пока что можно только из списка доступных бэкапов. Использовать бэкап-логи для восстановления на нужную точку времени по-прежнему нельзя. Ждём эту возможность в новых версиях. 

Последний апгрейд и стопроцентная автоматизация процесса

Все необходимые настройки и параметры для System Refresh должны быть сконфигурированы в LaMa: настройки сети, репозитории с дистрибутивами, логины, пароли для служебных учетных записей, необходимые соединения с управляемыми системами. Помимо этого, для систем, с которыми планируется использовать сценарий System Refresh, должна быть активирована опция Copying:

При добавлении исходной и целевой системы в LaMa указываются все необходимые для управления пароли. Эти же пароли могут быть использованы и в рамках нашей задачи. Теперь наш 4-й этап, System Refresh, можно выполнить из LaMa. Большая часть параметров для запуска мастера, через который выполняется System Refresh, в LaMa уже есть. На этапе запуска достаточно подтвердить логины и пароли технических пользователей, указать дату и время восстановления, а также указать таск-листы для утилиты PCA. Итак, запускаем мастер уже внутри LaMa:

Проходим все шаги, указав точку восстановления и кастомизированные таск-листы с готовыми вариантами запуска на этапе с PCA:

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

Так мы избавили коллег от вынужденных простоев: процедуру можно запустить на выходные, вмешательство администратора в процесс не требуется.

Что ещё умеет LaMa

Описанную выше утилиту Post-Copy Automation удалось применить для оптимизации большого числа рутинных операций — в том числе проверки состояния и перезагрузки систем, серверов приложений, баз данных и пр.

С помощью LaMa мы упростили процедуру Rolling Kernel Switch, которая обновляет ядро системы на каждом из серверов приложения, сохраняя доступность системы для пользователей в целом. Принцип состоит в том, чтобы заранее вывести один из серверов из группы и изолировать его до тех пор, пока на нём не завершатся все пользовательские сессии. Затем делается обновление ядра либо изменяются некие статические параметры, которые применяются системой только после перезапуска. Перезапускаем сервер, возвращаем его в группу — и он снова доступен для пользователей. Такая процедура повторяется по очереди для остальных серверов.

Технология не новая, но раньше мы запускали процесс через консоль. В LaMa у Rolling Kernel Switch появился графический интерфейс — для управления и мониторинга хода выполнения. Плюс теперь есть возможность запланировать процесс одновременно на нескольких системах.

Обновление с минимальной недоступностью системы (Near Zero Downtime Upgrade) — стандартная процедура для систем HANA с репликацией, но с LaMa мы смогли запускать её по готовому сценарию: обновление пассивной ноды, установка репликации — чтобы ноды снова «сдружились», перенос активной ноды на пассивную, обновление второй ноды. Ручные действия администратора не требуются, LaMa подключает систему к базе данных, указывает дистрибутив, из которого нужно выполнить компоненты, — и система обновляется самостоятельно.

Стоит отметить, что мы используем системные ландшафты на HANA с настроенной репликацией только в продуктивных системах. Дублировать «железо» такого класса — слишком дорого для систем теста и разработки, где нет высоких требований по доступности и отказоустойчивости.

Итоги и планы

Этап внедрения можно считать завершённым, инструмент перешёл в эксплуатацию, доступ к нему получили все наши администраторы. Есть написанные ранбуки по сценариям, которые мы уже протестировали. Коллеги постепенно пробуют работать с новым инструментом, применяют его в своей работе.

Но уже сейчас за счёт внедрения LaMa нам удалось:

• сократить время по обновлению HANA на 20%;

• обновлять тестовые системы во внерабочее время, за выходные;

• исключить человеческий фактор при выполнении ручных действий;

• объединить в одном интерфейсе все системы SAP;

• выполнять большое число однотипных операций одновременно;

• выполнять регулярные сценарии автоматически, по расписанию.

Конечно, инструмент не универсален: его достаточно сложно использовать для задач, не связанных с продуктами SAP. Но мы всё-таки попробуем: с этим связаны планы интегрировать LaMa с другими инструментами, в частности с Ansible.

Кроме того, собираемся наращивать количество используемых сценариев из коробки — мы опробовали далеко не всё. Хотим решать и инфраструктурные задачи — например, устанавливать обновления на ОС. Если у вас есть опыт подобной интеграции или другие идеи относительно использования LaMa — приглашаю обсудить это в комментариях.

В сентябре 2020 года в вечернем питерском небе можно было наблюдать множество разноцветных светящихся точек, которые собирались в фигуры и перестраивались как по команде. Это было одно из шоу дронов, которые организует местная компания «Геоскан». 

Тогда они побили рекорд компании Intel и вошли в Книгу рекордов России со зрелищной программой в честь 75-летия Победы, в которой задействовали почти 2200 квадрокоптеров собственной разработки.

Под катом — о техническом закулисье и том, насколько сложно запустить одновременно пару тысяч дронов, когда даже для одного нужно оформлять специальное разрешение.

Наш интерес к рассказу про этот проект традиционно подогревается тем, что он попал в топ-50 проектов технологического прорыва НТИ.

Вечером 3 сентября для участия в шоу «Мирное небо» над Питером поднялись одновременно 2198 дронов «Геоскана». Несмотря на популяризацию термина «рой дронов», как такового «роя» не было. 

Это был групповой полет автономных летательных аппаратов, в каждый из которых заранее заложили собственное полетное задание.

В отличие от Intel — предыдущего обладателя рекорда по количеству дронов, одновременно находящихся в небе, — «Геоскан» запустил летательные аппараты собственного производства.

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

Подготовка рекордного — как и любого другого шоу дронов — идет одновременно по трем направлениям:

• планирование и расчет анимации;

• согласование полета над городом;

• непосредственно полет.

Обо всем этом и поговорим.

Расчет анимации

Это большая часть работы, которую выполняет целая команда аниматоров. Именно они продумывают, какие фигуры будут демонстрироваться и как дроны будут перестраиваться. 

Подготовка шоу «Мирное небо» заняла у команды из 15 человек около трех месяцев (если не учитывать, что компания по мере развития технологий шла к этому несколько лет). Заказчиком проекта выступил Фонд памяти поколений, он же рекомендовал часть фигур. Но перестроения, а также прогремевший на весь TikTok голубь мира, — идеи команды «Геоскана».

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

Но отрисовать анимацию не сложно. Главное перенести ее в реальный мир, где есть множество ограничений.

Ограничения реального мира

Первое, что приходится учитывать, — скорость дронов ограничена. Максимум составляет около 22 м/с.

С учетом того, что летательные аппараты будут компенсировать ветер до 15 м/с, расчетную скорость перемещения при анимации закладывают не больше 5 м/с.

Так «картинка» будет устойчивее при неожиданных порывах.

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

Вокруг каждого дрона аниматоры оставляют свободное пространство для предотвращения столкновений. С учетом точности позиционирования и возможного ветра минимальное расстояние между ними — около 3 метров. Так что во время расчета траекторий дроны рассматривают как сферические частицы, которые не могут взаимодействовать друг с другом. Фактически на этом этапе и закладывается защита от столкновений, поскольку дроны не имеют связи друг с другом и не могут контролировать расстояние до соседей во время полета.

Учтя скорость и габариты дронов, аниматоры оптимизируют полет каждого: чтобы все точки двигались быстро и по оптимальным маршрутам, но не в ущерб зрелищности. Эта квадратичная математическая задача, а поэтому чем больше дронов, тем больше нужно ресурсов. Для расчета оптимальных траекторий используют стандартное ПО для киношной визуализации на рабочих станциях с мощными графическими картами, дополненное собственными библиотеками с математикой.

«Геоскан» не параллелит эту задачу по сети. Однако как раз при подготовке рекордного шоу команде пришлось кардинально поменять алгоритмы собственных библиотек. Со старым подходом анимацию 1000 дронов рассчитывали так долго, что поняли: с 2000 команда просто не успеет в срок. В итоге софт серьезно оптимизировали, сейчас анимацию на несколько сотен дронов считают за час. 

Законченную анимацию трансформируют в полетные задания для дронов. Так каждый дрон имеет данные о том, в какой момент и где он должен находиться. А заставить дронов летать четко по прописанной траектории — уже инженерная задача. О ней расскажем ниже.

Пара слов о бюрократии и логистике

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

Команда умудряется переходить закрытые из-за COVID-19 границы, возить авиарейсами большое количество аккумуляторов (что обычно не допускается) и ездить с шоу даже в Саудовскую Аравию, куда ввоз квадрокоптеров запрещен.

С точки зрения бюрократических и логистических барьеров каждый проект уникален. Естественно, в Санкт-Петербурге — приграничном и втором по важности городе страны — были свои сложности. Чтобы летать в центре, необходимо получить разрешение огромного количества служб, включая ФСБ и ФСО.

«Мы поднимем в центре города 2000 беспилотников», — звучит угрожающе, даже когда команда начинает со слов: «Разрешите нам полетать с маленьким квадрокоптером без камеры весом всего 250 граммов».

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

Полет

«Геоскан» занимается беспилотниками с 2006 года. И дроны, которые участвовали в шоу, разрабатывались специально для выступления.

Дроны

Разработчики сделали ставку на минимальные габариты дрона. Это сокращает и вес, и энергозатраты, и запас по расстоянию между аппаратами, а заодно упрощает логистику зарубежных поездок. Дроны штабелируют по 10 штук и упаковывают в ящики по 40 или 60 дронов.

Тысячу дронов можно спокойно перевозить в багаже самолета: ящики на 40 дронов помещаются в стандартные габариты авиабагажа, а 300–400 дронов едут к месту проведения шоу в большой легковой машине.

Обратная сторона компактности — электромагнитная совместимость. Сигнал, который принимает GPS-приемник, слабый — 120 дБм (спутник находится на расстоянии 20 000 км), а все электронные компоненты находятся очень близко. При создании дронов только с третьего раза удалось разместить компоненты так, чтобы сигнал проходил корректно. И 500 уже собранных дронов пришлось в свое время пересобирать. 

Производство деталей дрона по большей части заказывают на стороне. Например, пластиковые элементы корпуса делал Starline, о котором мы рассказывали в одной из предыдущих статей. Тот факт, что линия партнера находится под боком, как раз помог при подготовке к шоу. В Starline согласились быстрее отлить пластиковые корпуса. И «Геоскан» смог начать сборку весьма оперативно.

Всю электронику размещают на одной плате. Чтобы дрон летал четко по предписанной траектории, нужна надежность, а каждый разъем — это потенциальная точка отказа. 

Связь используют самую простую. Все дроны принимают широковещательные сообщения базовой станции. Достаточно скомандовать запуск — дальше они летают автономно.

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

На борту дрона размещено 50 сверхъярких диодов (в пиках они дают мощность излучения 10–50 Вт), которые, кстати, и потребляют большую часть энергии аккумулятора, так что его хватает минут на 15 полета.

Здесь компактность пошла на пользу — маленький корпус и обдув позволили не устанавливать радиаторы и сэкономить на весе.

На дроне установлена электроника в промышленном исполнении с диапазоном рабочих температур от −80 до 85 °C. Кстати, чтобы проверить работоспособность в этом диапазоне, устройства дополнительно тестируют в термокамере. 

Но летать в экстремальный мороз не позволяет аккумулятор. Пока самое «холодное» шоу проводили при −18 °C. А вот сырость дрону не помеха. За время тестов «Геоскан» успел полетать и в туман, так и в дождь.

Автопилот

Каждый дрон оборудован стандартным комплектом датчиков — высокоточным GPS, трехосевым акселерометром, гироскопами и барометром. Для повышения точности GPS базовая станция в широковещательном режиме транслирует с земли поправки.

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

Обычно квадрокоптеры оснащают еще и магнитометром. Но автопилот «Геоскана» умеет обходиться без него. В городских условиях — при старте среди железобетона — магнитометр дает большую погрешность определения направления полета: магнитное поле поворачивается, в результате математическая задача определения местоположения перестает сходиться.

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

Разобравшись в ситуации, магнитометр отключили и изменили в автопилоте алгоритм определения местоположения. Он использует не только текущие показания, но и историю собранных данных, — сравнивает текущее положение по датчикам и то, куда он должен был прилететь с учетом параметров движения. Фактически алгоритм подстраивает свое представление о местоположении по мере его изменения.

Кстати, при отладке этого механизма «погибли» 60 дронов. После симуляции перешли к запускам в поле, где неожиданный порыв ветра «запутал» алгоритм. Дроны думали, что летят направо, а по факту перемещались налево — появилась ошибка в определении ориентации.

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

Расчеты автопилота не настолько ресурсоемкие, как можно подумать. Ему достаточно контроллера 400 МГц. А для сохранения полетного задания и логов достаточно памяти в 1 Гб.

Предполетные проверки

Каждый дрон перед «боевым вылетом» проходит серию тестов. Чтобы упростить логистику, на старте теста просто зажигают подсветку дрона разными цветами в зависимости от результата. С проблемными дронами (они подсвечиваются красным) не разбираются, чтобы не терять время, а просто меняют их. Любопытно, что на рекордном шоу у «Геоскана» было всего три запасных дрона на подмену.

Отдельная проверка — световая змейка, ее запускают по стартовому полю. У каждого дрона свой номер, и на взлетном поле они должны стоять строго по порядку, иначе в анимации будут ошибки. Змейка — это простой способ проверить, что дроны не перепутали местами.

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

Черные ящики

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

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

Иногда анализ логов дает интересную информацию. Так, на тестовом запуске перед рекордным шоу одновременно у всех 2000 дронов упала точность позиционирования. Команда предположила, что это военные включили свои глушилки, и перед основным запуском пришлось вместе с радиочастотной службой разбираться, что произошло. К счастью, удалось договориться и отключить трансляции на смежных частотах.

Логи дают ответы на вопросы, почему отдельные точки занимают ложные позиции. Кстати, это видно на съемках рекордного шоу. 

Высокоточный GPS получает не только сами данные со спутников, но и фазы сигналов. Анализ этой информации дает что-то вроде дискретного множества вероятных позиций дрона. Для каждой точки вероятность отличается. Эти решения находятся на расстоянии примерно 20 см друг от друга. Их конфигурация и распределение вероятностей зависят от созвездия спутников, наличия помех для распространения сигнала, отраженных лучей. 

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

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

Логи скачивают даже с тех дронов, которых заменили на старте из-за того, что они не прошли проверки. Данные с них помогают понять, какая часть предполетного теста была завалена.

Данные всех полетов сохраняют на будущее. Да и само шоу всегда снимают и с земли, и с воздуха. В воздухе, естественно, с помощью собственных дронов других моделей.

Технически команда «Геоскана» готова запустить одновременно 4000 дронов. Вопрос только в поводе и заказчике. Кстати, команда считает, что гонка за количеством — бессмысленный путь развития. Гораздо интереснее включить в анимацию беспилотные самолеты, которые могли бы летать быстрее, или добавить что-то более экзотическое: например, дроны, зажигающие в небе пиротехнику. Осталось только узнать, что на это скажут люди, согласующие полеты.

При работе с базами данных (БД) в установщике, про который мы уже писали в прошлой статье (Пишем установщик на WixSharp. Плюшки, проблемы, возможности), в первую очередь, были реализованы проверка доступности СУБД по логину/паролю, добавление и обновление собственно БД (в нашем приложении их несколько) накатыванием миграций, a также добавление пользователей. Все это реализовано для двух СУБД Microsoft SqlServer и PostgreSql.
На первый взгляд этого достаточно, но иногда есть необходимость удалять БД и пользователей, а это влечет за собой создание резервных копий. Сразу выявили две необходимые задачи:

1. Удаление БД и пользователей при откате приложения в случае ошибки при первичной установке. При установке приложения, если возникает ошибка, происходил откат всех настроек, кроме БД. Добавленные БД и пользователи оставались. И, если при боевой эксплуатации, после серии тестирования эта ситуация непредвиденной ошибки маловероятна, то в процессе разработки и доработки установщика, ошибки возникают часто. Их, однозначно, нужно удалять.

2. Создание резервных копий (бэкапов) и удаление БД и пользователей при полном удалении приложения установщиком. Правильно ли оставлять БД после полного удаления приложения? Мы решили, что нет. Но бэкапы, конечно, сохранять нужно.

Из второго пункта возникла новая задача:

3. Создание бэкапов БД при обновлении приложения. Если мы сохраняем бэкапы при удалении, неплохо создавать их и перед обновлением, накатыванием миграций и прочими изменениями. Подстраховка еще никому не мешала. 🙂

Удаление БД и пользователей при откате приложения в случае ошибки при первичной установке

Если что-то пошло не так и при установке возникли ошибки, мы сразу же позаботились об удалении добавленных директорий и настроек, а также об очистке реестра. Но БД и пользователей также нужно удалять. В WixSharp для этого предусмотрен механизм роллбэка для CustomActions. Для существующего пользовательского действия нужно добавить еще один параметр — название пользовательского действия откатывающего изменения. Необходимо учесть, что данный механизм доступен только для deferred action (отложенных действий).

new ManagedAction(AddDatabaseAction, Return.check, When.After, Step.PreviousAction, Condition.NOT_Installed, DeleteAddedDatabasesAction)              {      UsesProperties = $@"{DATABASE_PROPERTIES}={database_properties}",      Execute = Execute.deferred,     ProgressText = $"Выполняется создание БД {databaseName}"               };

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

Создание бэкапов и удаление БД при полном удалении приложения установщиком

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

Пользовательское действие для создания бэкапа желательно выполнять до того, как начнут вноситься изменения установщиком, для этого предусмотрен тип immediate. В отличие от deferred, он выполняется сразу. Чтобы данное действие выполнялось только при удалении приложения, укажем условие Condition.BeingUninstalled:

new ManagedAction(BackupDatabaseAction, Return.check, When.After, Step.PreviousAction, Condition.BeingUninstalled) {    Execute = Execute.immediate,    UsesProperties = DeleteAddedDatabases,    ProgressText = $"Выполняется скрипт по созданию резервных копий БД"  }

Бэкапы решено было сохранять по пути, доступному текущему пользователю. Так как у нас несколько БД, группировку проводили по версии приложения. Название БД формировалось классически, с указанием имени и даты-времени создания.
\Users\{CurrentUser}\AppData\Local\{ApplicationName}\Backups\{VersionNumber}

Создаем этот путь:

Version installedVersion = session.LookupInstalledVersion();    string localUserPath = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);   string backupPath = Path.Combine(localUserPath, "ApplicationName", "Backups", installedVersion.ToString());    Directory.CreateDirectory(backupPath);

И если для Microsoft SqlServer создание бэкапов заключалось в выполнении банального sql-скрипта:

$" USE master" +                     $" BACKUP DATABASE [{databaseName}]" +                     $" TO DISK = N'{path}'" +                     $" WITH NOFORMAT, NOINIT, " +                     $" NAME = N'{backupName}', SKIP, NOREWIND, NOUNLOAD,  STATS = 10 ";

То для PostgreSql одним скриптом не обойтись. Бэкап можно создать запуском команды через командную строку. Понадобится выполнение следующих действий:

• Запускать pg_dump.exe из соответствующей папки PostgreSql
  C:\Program Files\PostgreSQL\{Version}\bin
  Мы не знаем какая версия установлена у заказчика (обычно в документации мы указываем версию, не ниже которой требуется), какой путь был выбран. Поэтому основной путь с указанием версии получим из реестра:

const string KEY_MASK = @"SOFTWARE\PostgreSQL\Installations\"; var currentVersion = Registry.LocalMachine.OpenSubKey(KEY_MASK)?.GetSubKeyNames()[0]; if (currentVersion == null) {   return ActionResult.Failure; } var keyName = $@"HKEY_LOCAL_MACHINE\{KEY_MASK}{currentVersion}"; var postgresPath = (string)Registry.GetValue(keyName, "Base Directory", string.Empty);

• Проверять, добавлены ли переменные среды для PostgreSql. И в случае необходимости добавить.
C:\Program Files\PostgreSQL\12\bin
C:\Program Files\PostgreSQL\12\lib

  Если они отсутствуют, запуск pg_dump будет невозможен.

string binEnv = $@"{postgresPath}\bin"; string path = "PATH"; var scope = EnvironmentVariableTarget.User; var currentEnvironmentVariable = Environment.GetEnvironmentVariable(name, scope); if (!currentEnvironmentVariable.ToUpper().Contains(binEnv.ToUpper())) {   var newEnvironmentVariable = $@"{currentEnvironmentVariable};{binEnv}";   Environment.SetEnvironmentVariable(name, newEnvironmentVariable, scope); }

• Сформировать аргументы создания бэкапа с помощью командной строки. Здесь необходимо указать параметры подключения, имя БД и путь сохранения бэкапа. Так как ранее нам не приходилось создавать бэкапы для PostgreSql, несложный поиск в интернете показывал примерно такое решение:

  pg_dump -h {host} -p {port} -U {username} {database_name} > {backuppath}


  Если в конфиг файле pg_hba не указано для local connections безусловное подключение trust, то будет требоваться введение пароля. В данном случае, требуется добавление файла .pgpass для текущего пользователя. Тогда, можно добавить в команду атрибут -w и пароль будет считываться оттуда. Так как вновь возникает ситуация, когда мы не знаем, как это организовано у заказчика, была найдена универсальная запись, с помощью которой можно передать все параметры в рамках одной команды:

  pg_dump --dbname=postgresql://{username}:{password}@{address}:{port}
/{databaseName} -f {backupPath}

После того, как бэкапы созданы, можно удалить БД и пользователей. Здесь будет использоваться то же пользовательское действие DeleteAddedDatabasesAction, что и для отката из пункта 1. Оно будет отложенным и будет запускаться при условии деинсталляции Condition.BeingUninstalled:

new ManagedAction(DeleteAddedDatabasesAction, Return.check, When.After, Step.PreviousAction, Condition.BeingUninstalled) {   Execute = Execute.deferred,   UsesProperties = $@"{DATABASE_PROPERTIES}={database_properties}",   ProgressText = $"Выполняется удаление БД {databaseName} и роли {role}"  };

Операции с БД при обновлении приложения

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

Вывод

Для PostgreSql и Microsoft SqlServer в нашем установщике удалось наладить:

• механизм удаления БД и пользователей;

• создание резервных копий в случае полного удаления;

• создание резервных копий в случае обновления приложения;

• реализацию отката добавленных БД в случае неудачной первичной установки, либо ее отмене.

  Продолжаем пилить msi 😉

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

В этом посте я попробовал собрать историю архитектуры Учи.ру. В нем нет фрагментов кода и исчерпывающих технических подробностей. О нашем опыте выделения микросервисов для решения некоторых задач образовательной платформы — в следующих публикациях.

«Геометрическое совершенство монолита воспринималось людьми как некий безмолвный вызов, оно поражало не меньше, чем другие свойства загадочной находки».

Артур Чарльз Кларк. 2001: Космическая одиссея (1968)

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

Начиналось же все с маленького сайта около десяти лет назад.

С чего все начиналось

Эра мини-монолитов

Первые версии Учи.ру появились в начале второго десятилетия ХХI века. Это были очень простые сайты с отдельными базами данных, образовательным контентом и менеджментом: старая платформа Учи.ру с уроками, «Учи.ру Столбики» и «Учи.ру Колонки». Спустя десятилетие они выглядят немного старомодно, но все равно мило — мы храним их во внутреннем музее славы Учи.ру и публичный доступ к ним не предоставляем.

Еще несколько исторических документов.

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

Эра зарождения первого монолита

До 2012 года сайты существовали обособленно. Затем мы создали новую платформу с единой точкой входа — Login, которая поглотила старую Учи.ру и «Колонки». «Столбики» ждало скорое забвение. 

Изменения и перенос контента породили проблемы вроде конфликта стилей, что сказывалось на качестве. Тогда команда впервые задумалась о создании эталонной системы управления контентом — CMS.

Эра CMS

Через два года системная архитектура выглядела скромно: CMS, основная платформа, а также разные прикладные модули, например, для аудита, управления персоналом, временного трекинга.   

Довольно простая CMS помогала в совместном создании и версионировании контента для пользователей, основу которого составили интерактивные карточки (задания) для детей, разработанные совместно с методистами.

Расширение функционала основного модуля

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

Изначально мы старались разделить ответственность. Так, часть задач мы реализовали в виде функций CMS, таких как управление уроками или разработка методических материалов. Но когда темпы выросли, практически все новое стало добавляться в uchiru-login, просто потому что так было быстрее. Постепенно усложняя этот компонент, мы получили монолит. Чем дальше, тем больше его размеры и высокая степень связности затрудняли дифференциацию различных функциональных элементов. 

Из-за сложностей с любыми модификациями в монолите в начале 2019 года мы работали с устаревшими версиями Rails (4.1) и Ruby (2.1.5). Webpack с небольшими вкраплениями React-компонентов не позволял легко обновить зависимости без существенных рисков отказа в обслуживании. Нужно было что-то делать…

Выделение функций из состава монолита

Чтобы прощупать возможности разделения, мы начали проводить эксперимент по разъединению фронтенда и бэкенда. К этому моменту интерфейс представлял собой классические Rails-шаблоны с примесью старого Webpack. И хотя мы не ставили глобальной задачи по переходу на микросервисы, этот опыт все же стал большим шагом для нашей команды сразу в техническом, инфраструктурном и организационном плане. Но самое главное, мы начали выделять компоненты из uchiru-login. Стало понятно, что обуздать монолит реально. Отправной точкой стало выделение откровенно обособленного функционала с минимальной степенью связности. На подобных некорневых блоках мы и сосредоточили усилия.

1. Генератор PDF-сертификатов. Попрактиковались мы на микросервисе, который должен выдавать готовый документ по входным параметрам. Фактически мы сделали классический распределенный монолит с синхронным сетевым взаимодействием.

2. Олимпиадная платформа. Ее отделение от «большого брата» стало важным шагом. Стоит пояснить, что олимпиады выросли в отдельное направление: они бурно расширялись, и разработчикам приходилось постоянно оглядываться на другие части системы из-за большого риска сломать имеющийся функционал. Эта скованность мешала развиваться —  хотелось независимости. В итоге команда олимпиад повысила свои компетенции и создала прецедент выделения реально большого куска из монолита.

3. Развивающие игры. Используя опыт «олимпиадников», мы создавали игры как отдельный компонент, связанный с монолитом авторизацией, но способный развиваться самостоятельно.

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

   Сначала монолит и новый сервис использовали общую базу данных. Мы старались по возможности переносить операции записи ответственных данных в новые БД, а из монолита использовать их в режиме чтения. 

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

   Для разработки этого модуля мы использовали библиотеку JSONAPI Resources, которая сочетает в себе гибкость, низкую скорость и синтаксис, очень похожий на классический ActiveRecord. Залогом успеха стало стремление группы энтузиастов, которые во что бы то ни стало хотели достичь нужного эффекта.

Справляемся с высокими нагрузками

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

1. Кеширование. Это было первое, что пришло в голову. В качестве инструмента мы использовали Redis. Чтобы не заниматься поддержкой кластера в облаке, мы решили заменить его урезанной версией Redis от Envoy с шардированием по ключу хранения. В результате система стала держать нагрузку лучше, но это было только начало.

2. Реплики БД. После очередного скачка трафика мы уперлись в лимит пула соединений с БД. Теоретически работа с микросервисами должна была помочь в масштабировании самых нагруженных частей системы или вовсе избежать этой проблемы. Но это в идеальном мире. 

   Мы попытались выйти из ситуации с помощью реплик БД, к которым поступали бы запросы на чтение. Звучит просто и круто, но те, кто знаком с «рельсовой» кухней и большой связностью данных, моделей и ассоциаций, назвали бы нас психами. Все дело в контекстах инициализации объектов и механизме ассоциаций. Поэтому первым делом под нож пошли запросы статистического характера, большие списки и отчеты.

3. Octopus. К счастью, на помощь нам пришел Octopus, но и он не обрабатывал все случаи, особенно те версии, которые были совместимы с устаревшей платформой. Например, мы обнаружили, что запись в режиме «реплики» тянет за собой все ассоциативные связи в том же режиме. Это порождает конфликты, связанные с попытками записи в read-only-транзакциях. Пришлось заниматься monkey-патчингом ORM-компонентов. Методом проб и ошибок проблему решили.

4. Оптимизация обработки запросов. Следующим отказало синхронное межсервисное взаимодействие. Поскольку основная часть трафика традиционно проходила через главную страницу сайта и кабинет ученика, сборка страницы осуществлялась на сервере. При формировании страничек подобного типа приходится дергать несколько сервисов для получения нужной информации, например, недавно выделенный олимпиадный. 

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

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

   Более того, внешние сервисы не обладали необходимыми данными для обработки входящих запросов типа «сервер — сервер» и были вынуждены запрашивать их. Все это приводило к появлению каскадных зависимостей, образованию очередей и, как следствие, отказу в обслуживании.

Но зато, набив эти шишки, мы познакомились с Circuit Breaker и научились его применять, что позволило стабилизировать ситуацию. В этот момент мы поняли, что более гибкая асинхронная архитектура с дублированием данных значительно бы улучшила положение вещей, хотя и не решила бы проблемы полностью.

Разделение на микросервисы действительно возможно

«Но ведь верилось же! Казалось, еще немного усилий — и то самое светлое будущее, которое каждый представлял себе по-разному, в зависимости от воспитания и фантазии, обязательно наступит».

Артур Чарльз Кларк. 2001: Космическая одиссея (1968)

Хочу еще раз подчеркнуть, что разделение системы на микросервисы пока проходит в экспериментальном режиме — это инициатива нескольких команд, которые делают продукт практически с нуля. Но мы уже получили положительные результаты, которые помогут платформе развиваться в ближайшем будущем. Конечно, помимо перечисленных трудностей возникают и другие — о них я постараюсь рассказать в следующих постах.

В любом случае мы оценили преимущества асинхронной архитектуры и распределенных систем, а главное — убедились на своем опыте, что распилить запутанный монолит вполне реально. При этом стало понятно, что ответственность — это не одностороннее понятие и для успешного развития платформы бизнес должен с пониманием относиться к проблемам технических отделов, оставляя время и ресурсы на устранение долгов. А IT-специалистам не стоит скромничать — нужно заявлять о такой потребности, чтобы была возможность вовремя провести «субботник». Лично я теперь убежден, что выявление некоторого стабильного фундамента системы из нескольких сервисов позволит нам унифицировать платформы, а также решить проблему мертвого кода.