[DevOps, IT-компании] Миграция production сервиса из одного ЦОД в другой

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
07-Дек-2020 13:30

Цитировать

В современных реалиях существует много стартапов, которые постепенно так или иначе сливаются с крупными компаниями. В итоге перед инженерами стоит задача перенести сервис из одного дата-центра в другой. Причем чаще всего нужно, чтобы сервисы переехали без даунтайма. Михаил Кобзев — ответственный за предоставление сервиса по модели SaaS в Rambler Group. В своем докладе на конференции «DevOps Live 2020» он подробно рассказал про типичные ошибки при миграции и поделился действенными лайфхаками.

Нужно помнить, что переносить мы можем только хорошо описанные сервисы, в которых разбираемся, и по которым составлена документация. Они не должны быть черным ящиком. Наоборот, у нас должно быть понимание о том, как функционирует сервис, четкая связь, выстроенные схемы и исчерпывающий мониторинг по каждому компоненту. Кроме того, хорошо бы иметь в наличии блок-схемы и маркеры, которые позволяют вынести решение о том, что тот или иной компонент сервиса работает, и работает именно так, как нужно. То есть один из основополагающих факторов, предшествующих миграции, – это исчерпывающий, максимально детализированный и замониторенный сервис, в котором мы разбираемся.Чего не стоит делать в момент миграции?Как бы ни хотелось момент миграции совместить с обновлением дистрибутивов, библиотек и т.д., лучше этого избегать. Иначе мы можем сами себе подготовить грабли, на которые наступим. В целом, обновление может привести к тому, что из достаточно детерминированного, известного и полностью прозрачного сервиса мы получим нечто неуправляемое, где невозможно предугадать поведение той или иной системы.Также желательно приостановить все изменения (выкатку релизов, новых фич, изменение каких бы то ни было архитектурных нюансов и особенностей сервиса). Остановив эту работу, мы частично парализуем или передвинем деятельность разработки на срок миграции. Но, тем не менее, получаем управляемый, известный и прозрачный сервис.Изменение схемы деплоя аналогично первым двум пунктам. У нас есть известный, хорошо описанный и задокументированный сервис. Мы не делаем из него что-то новое и непонятное. Изменения в SCM примерно соответствуют первым пунктам, потому что благодаря им можно получить что-то непонятное, неконтролируемое. Любое изменение в любой части сервиса так или иначе — потенциальный риск получения обратной реакции, которую мы можем не предусмотреть.Необходимые и достаточные условияСреди условий, которые нужны для качественной миграции, можно выделить несколько пунктов.

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

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

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

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

Что обязательно нужно для успешной миграции

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

одна часть команды непосредственно участвует в переключении;
после того, как первая команда исчерпает свои физические силы и отправится отдыхать, подключится вторая.

Переключать трафик целиком на все компоненты разом не всегда возможно, но можно раздробить трафик и переключать покомпонентно.Дальше нужно дополнительно провести тесты перед точкой невозврата (под ней в данном случае подразумевается изменение контента на новой площадке). Когда мы переключаем трафик, изменение контента пойдет на новую площадку. Если дальше по какой-то причине нам придется откатить трафик на старую, мы столкнемся с кучей головной боли по возвращению измененного контента.В момент полного переключения трафика на новую площадку было бы здорово отследить статистику и сверить бизнесовые метрики до и после. После успешного завершения миграции команда, которая ее осуществляла и контролировала процесс, отправляется на заслуженный отдых, а вторая часть команды продолжает работать и наблюдать за перемещенным сервисом. Миграция произошла успешно, и по результатам наблюдений с сервисом все хорошо. Остается самая интересная часть работы, которая касается нормализации процессов разработки и эксплуатации сервиса. Зачастую, если речь идет о местном поглощении, а не просто о миграции сервиса между дата-центрами, то, как правило, в каждой компании существуют свои реалии эксплуатации или свои требования к эксплуатации. Поэтому в силу того, что сервис переехал в новый дата-центр, в другую команду эксплуатации, начинается уже адаптация сервиса к новым реалиям разработки и эксплуатации.Проблемы при миграцииКак правило, большая часть контента, который нужно перевезти, приличного размера. И через канал связи между дата-центрами он будет переливаться целую вечность. Нам приходилось перегружать контент на жесткие диски и возить их пачками.Также при миграции одного из сервисов было большое изменение статики, картинки и пользовательский контент менялись, но существующая система хранения не подразумевала кросс-дата-центровую репликацию. То есть репликация внутри дата-центра была нормальной, а репликация, которая бы не разваливалась с большим Round Trip Time или Time To First Byte, не была адаптирована к таким реалиям. Пришлось вносить в архитектуру систему хранения изменений и организовывать кросс-дата-центровую репликацию.Кроме того, обнаружилась проблема с версиями библиотек. Их пришлось сменить и тестировать на свежем дистрибутиве, потому что старый давным-давно был deprecated suspended. Обновление дистрибутивов прошло не совсем гладко.Современные системы мониторинга при переездеСовременный технологический стек мониторинга, мне кажется, гораздо проще смапить на любую архитектуру сервиса, чем с решениями по мониторингу Zabbix, Icinga, Cacti, которые были много лет назад. С современными системами мониторинга проблем «негибкости» нет. В нашей компании подразумевается составление структурированного плана, благодаря которому происходит организация всего мониторинга. Для простоты назовем этот план источником информации. Это некий сервис, в котором есть API. В него стучится мониторинг и получает информацию. В момент исследования черного ящика проекта документация ложится на концепцию инфраструктуры как код. Благодаря этому проблем при проведении мониторинга не возникает. Изначально в момент моего знакомства с сервисом он мониторился Cacti, Icinga, Zabbix, частично была еще парочка проприетарных систем. Все это благополучно уехало в Prometheus, с тех пор глобальных проблем нет. В момент переключения все, что нужно было сделать, – добавить в service discovery новые компоненты.От разработчиков среди прочего потребовалось внесение правок в код для того, чтобы отдавать бизнесовые метрики в Prometheus. Наблюдение и сбор этих метрик за несколько месяцев позволили получить после переезда достаточно прозрачную картину.Что сделать, чтобы переезд прошел легче На мой взгляд, было бы удобнее переносить сервис, который максимально перевезен и управляется SСМ, например, под управлением Chef, Puppet, Salt, Ansible. Главное, чтобы ничего не пришлось делать руками. Это бы позволило существенно сократить время на настройку новой площадки. Важно и наличие кэширующих репозиториев на стороне проекта, чтобы не приходилось спустя длительный промежуток времени собирать все по кусочкам. А еще лучше, чтобы большая часть библиотек была собрана и обернута во что бы то ни было – будь то Docker или любой пакет. С репозиториями история отдельная: перевозить сервис, на котором их нет, достаточно проблемно. Кроме того, необходимо наличие документации, чтобы сервис не казался неким черным ящиком и не приходилось самостоятельно двигаться сверху вниз или снизу вверх.На мой взгляд, гораздо проще перевезти сервис, который обновлен практически по всему стеку. Это совет, проверенный на собственном опыте: мы перевозили сервис, в котором был старый Elastic, и по пути решили его обновить. В итоге на этот сервис было подвязано определенное количество роботов, которые пришлось переписывать на другой query language. Если бы было свежее обновление, этого бы делать не пришлось. Перевозить нужно что-то актуальное. Сетапить старый Elastic – то еще удовольствие. Гораздо проще перевезти сервис, который изначально адаптирован под работу в нескольких дата-центрах (под ней я имею в виду работу сервиса в дата-центрах, между которыми RTT и TTFB зашкаливают). Если это не так, появляются некоторые ограничения. Организация репликаций должна быть в районе LR7, и ее нужно хорошо протестировать. Это все могло бы максимально увеличить скорость миграции из одного дата-центра в другой.

Даже во время пандемии мы готовим для вас кое-что интересное, продолжая встречи онлайн.Сегодня в 16:00 вас ждет митап «Stateful-приложения в 2020 году». Поговорим о Stateful в 2020. Сейчас много всяких методологий, подходов и новых принципов работы. Но они больше ложатся на stateless. А что в это время происходит с БД? Как жить и поступать с ними сейчас, в 2020 году? И какие перспективы и тренды нас ждут?Следите за новостями — Telegram, Twitter, VK и FB и присоединяйтесь к обсуждениям.

===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_devops, #_itkompanii (IT-компании), #_devops, #_konferentsii (конференции), #_migratsija (миграция), #_datatsentry (дата-центры), #_blog_kompanii_konferentsii_olega_bunina_(ontiko) (
Блог компании Конференции Олега Бунина (Онтико)
), #_devops, #_itkompanii (
IT-компании
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 07:09
Часовой пояс: UTC + 5