Обновление Glarus BI. Обзор вариантов¶
Данный материал рассчитан в первую очередь на технических руководителей.
Обновления Glarus BI публикуются на серверах разработчика в репозитории образов Docker. Доступ к репозиторию администратор получает в рамках процесса развёртывания системы. Информацию о выходе новой версии системы можно получить в открытых источниках (официальный сайт продукта, тематические группы в социальных сетях, каналы разработчика на видеохостингах), а также при взаимодействии с технической поддержкой.
Способ обновления Glarus BI зависит от вашей инфраструктуры и выбирается техническим руководителем или системным администратором.
Независимо от выбранного способа, перед обновлением в обязательном порядке требуется выполнить резервное копирование БД метаданных приложения Glarus BI и проверить работоспособность полученной копии. Эти действия необходимо выполнить в каждом из контуров, если их несколько.
Также рекомендуется убедиться в наличии и работоспособности резервной копии витрин данных и других подключенных источников данных. Обновление не всегда затрагивает витрины данных в ClickHouse и не затрагивает другие подключенные источники данных, но возможен человеческий фактор при работе с консолью.
Внимание
Запрещено выполнять обновление экземпляра промышленной эксплуатации без создания резервной копии БД метаданных приложения, так как откат на предыдущую версию без работоспособной резервной копии в большинстве случаев невозможен.
Примечание
В ходе испытаний новой версии мы рекомендуем просмотреть все созданные ранее визуализации на дашбордах и убедиться в их корректном отображении.
Далее рассмотрены 3 подхода к обновлению Glarus BI. Вы можете использовать их или разработать свой собственный подход, исходя из особенностей вашей инфраструктуры и требований.
Классическое обновление¶
Подходит, если:
- у вас два или более контура Glarus BI (например, испытательный TEST и промышленный PROD);
- серверы в контурах имеют значительные различия по производительности, доступности и возможностям. Например, TEST не сможет обеспечить работу всех пользователей сети;
- лицензии на TEST выпущены на меньшее число пользователей, чем на PROD;
- витрина данных на TEST содержит упрощённый набор данных по сравнению с витриной на PROD или применяется маскирование данных на TEST;
- у кажого контура своё назначение, и вы не хотите менять их роли.
Вы организуете испытания новой версии на TEST, анализируете результаты и решаете, можно ли обновлять PROD.
Если спустя какое-то время вы передумаете и решите вернуться к предыдущей версии системы, системному администратору придётся развернуть базу метаданных из резервной копии.
Это относительно простой, быстрый и логичный способ. Пользователи в ходе испытаний могут создавать любые объекты в системе. Изменения не попадут на PROD. Но классическое обновление имеет и слабые стороны:
-
более высокие требования к испытаниям. Решение об обновлении должно быть взвешенным и основываться на результатах испытаний. Если вы обновили PROD, пользователи успели создать новые объекты в системе (запросы с визуализациями, модели, коллекции, дашборды), но позже решили вернуться к предыдущей версии Glarus BI, новые объекты будут утеряны, так как их нет в резервной копии, из которой будет восстановлена предыдущая версия;
-
не гарантируется обновление без простоя. Поиск и развёртывание БД метаданных, перезапуск системы может занять какое-то время. Сколько именно — зависит от объёма метаданных. Система во время проведения работ будет неактивна. Поэтому следует оценивать это время и проводить работы в нерабочие для большинства пользователей часы.
Если серверы сопоставимы по производительности, и вы не применяете маскирование данных на TEST, мы рекомендуем усложнить процесс, чтобы повысить качество испытаний:
- развернуть витрины данных и БД метаданных PROD на TEST;
- восстановить лицензию на TEST в нашей техподдержке;
- подумать о кэшировании моделей в вашей инфраструктуре — возможно, изменить время в расписании кэширования на TEST, чтобы избежать накладки с кэшированием на PROD.
При этом контур TEST не меняет своей роли после завершения испытаний.
В статье "Обновление Glarus BI в Docker Compose" приведены технические детали обновления одного контура.
Если у вас только один сервер с Glarus BI, вы также сможете обновить систему по этой статье.
Обновление со сменой ролей контуров (blue-green deployment)¶
Более трудоёмкий способ, который должен обеспечить максимально быстрое переключение пользователей на новую версию и быстрый откат к предыдущей версии (в случае необходимости).
Подходит, если:
- вы не допускаете простоев в работе — даже несколько минут критичны;
- у вас на TEST и PROD сопоставимая конфигурация серверов. Серверы одинаково эффективно могут обслуживать всех потенциальных пользователей, включая входной трафик;
- вы приобрели лицензии на одинаковое число пользователей для TEST и PROD;
- витрины данных на TEST и PROD — в руках одних и тех же людей, вы не используете маскирование данных для TEST;
- с вами сотрудничает достаточно квалифицированный системный администратор.
Администратор получает дамп БД метаданных на PROD, разворачивает его на неактивном TEST. Проводятся предварительные испытания. Если они успешны, администратор переключает трафик пользователей на TEST.
Если после переключения на TEST пользователи находят критичные проблемы, которые не позволяют использовать обновлённую систему, у администратора остаётся работоспособный PROD с предыдущей версией Glarus BI, к которому можно быстро вернуть пользователей, перенаправив трафик.
Если пользователи не находят критичных проблем, TEST становится активным (промышленным) после испытаний, а PROD "замораживается" и используется в качестве резервной копии.
Преимущества данного метода:
- минимизация простоя;
- снижение рисков при развёртывании;
- более достоверные результаты испытаний, так как они всегда проводятся на копии данных PROD;
- возможность быстрого отката путём перенаправления трафика.
Недостатки метода:
- более трудоёмкий: нужно переносить дампы БД между экземплярами и активировать лицензию;
- требует одинакового числа лицензий на промышленном и тестовом серверах;
- вам придётся обратиться в нашу техподдержку для восстановления лицензии после переноса БД метаданных;
- "железо" на серверах должно быть идентично или сопоставимо;
- ограничивает пользователей во время испытаний: они могут добавлять тестовые объекты в систему, но их придётся удалить вручную, так как БД метаданных потенциально промышленная;
- остаётся риск потери объектов, созданных пользователями в период обновления системы: после создания дампа БД промышленного сервера — до решения об успешном завершении испытаний.
В статье "Обновление Glarus BI в Docker Compose со сменой ролей контуров" приводятся технические детали этого процесса.
Обновление подменой jar и другие нестандартные варианты¶
Если вы запускаете Glarus BI в виде jar-файла на сервере или в контейнере, но без Docker Compose, эта информация может быть полезной.