- PVSM.RU - https://www.pvsm.ru -

6 ошибок переноса инфраструктуры в «облако»

6 ошибок переноса инфраструктуры в «облако» Сейчас мы будем переносить физические и виртуальные серверы со всеми запущенными на них службами и прикладным ПО и аккуратно обходить все разложенные грабли.

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

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

Инвентаризация

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

Тестовый стенд

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

Если не тестировать, может сложиться ощущение, что всё можно перенести без сложностей. Часто это ощущение неверное, и масштаб «нарисовавшихся» сложностей может неприятно удивить.

Безопасность

Как минимум — надо уточнить возможность защиты от DDOS-атак, оценить пропускную способность каналов связи и наличие системы обнаружения вторжений. Для ряда заказчиков эти опции могут сильно сэкономить время и нервы. Подробнее про безопасность я и мои коллеги ещё будем рассказывать в корпоративном блоге, как, например, вот в этом чеклисте [1].

Хороший план

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

Правильное время

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

Процесс миграции

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

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

Автор: maksimov_andrei


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/virtualizatsiya/4295

Ссылки в тексте:

[1] чеклисте: http://habrahabr.ru/company/croc/blog/140044/