Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Мы продолжаем рассказывать про решения независимых разработчиков, которые представлены на облачной платформе Azure и в Azure Marketplace. Сегодня о сценариях применения бесплатных инструментов компании Veeam, представленных в Azure Marketplace, рассказывает Александр Ширманов – R&D Director в Veeam. Вы всегда можете найти больше историй по ссылке на Хабре. – Владимир Юнев, Microsoft
Сегодня я хочу разобрать несколько сценариев использования публичного облака, продемонстрировав, как с их помощью можно выполнять те виды работ, которые до сих пор откладывались «в долгий ящик».
Я возьму такой пример инфраструктуры: имеется некоторый программный продукт, приложение, над которым постоянно трудятся инженеры (естественно, с целью довести его до совершенства). Основными компонентами являются:
- сервер баз данных (Backend)
- «среднее звено», т.е. сервис, выполняющий основные рабочие задачи (Middle-Tier)
- веб-сайт, с которым непосредственно работают пользователи (Front-Tier)
Рис.1
Раньше для работы над продуктом нужно было развернуть как раз 3 виртуальные машины – по одной для каждого из компонентов. Но продукт совершенствуется, и каждый из компонентов теперь может включать несколько ролей – так, например, веб-сайт теперь задействует не одну, а несколько ВМ, и, соответственно, требует балансировки нагрузки (Load balancer). Нагрузка в «среднем звене» также распределяется. Ну и сервер баз данных теперь использует SQL Server AlwaysOn Availability Groups. В итоге инфраструктура, с которой работают инженеры, приобретает вид, показанный на рисунке 2.
Рис. 2
Понятно, что среда, в которой выполняются тесты, которая используется разработчиками и другими членами продуктовой команды, мало напоминает ту, в которой обычно работают конечные пользователи. А ведь именно ее, пользовательскую среду, нужно уметь воссоздать в производственных целях.
Вот я и решил поделиться примерами задач, которые мне регулярно приходится выполнять в ходе создания тестовой инфраструктуры для производственных нужд.
1. Создание инфраструктуры для разработки, тестирования и проверки качества ПО
Проблема
Потребность в инфраструктуре для выполнения задач разработки, тестирования и проверки качества ПО является насущной и для компаний-производителей, и для небольших команд-отделов внутренней разработки. Она актуальна и во всех случаях, когда крупное предприятие приобретает софт у сторонних поставщиков, которые должны обеспечить его работу в производственных условиях.
В идеальном мире, конечно, можно рассчитывать на детально скопированную пользовательскую инфраструктуру. Но наш мир реален, и в нем, в том числе, существует ряд причин «против» развертывания такой копии: трудно управлять изменениями, поскольку команды, у которых есть полноправный доступ к ОС, вносят изменения буквально «на лету». Развертывание такой инфраструктуры отнимает время и силы, а ресурсы на поддержку лимитированы. Ну и зачастую у компании просто нет аппаратных ресурсов для развертывания.
Рассмотрим такую ситуацию применительно к нашему примеру - допустим, что ИТ-администратор весьма ограничен в ресурсах. До сей поры достаточно было развернуть 3 виртуальных машины (по одной на каждый компонент). Но теперь задача усложнилась, и из-за того, что не была смоделирована производственная среда, и решение не было в ней протестировано, последствия вывода в продакшен были довольно-таки безрадостными, включая необходимость полного отката к предыдущей версии. Кроме того, в условиях таких ограничений разработчики и бета-тестеры из числа пользователей не могли испытать продукт в работе с реальными данными, что также привело к неожиданным результатам уже после релиза.
Но даже если и вышеописанная ситуация никак не относится к разряду тех, с которыми вам доводилось встречаться, то вы наверняка слышали о случаях, когда тот или иной проект в компании приостанавливается по причине недостатка ресурсов, которые не высвободил какой-то из текущих проектов.
А что если для решения подобных проблем задействовать публичные облачные ресурсы?
Вариант решения
Естественно, для всех машин, входящих в производственную инфраструктуру, которой я пользуюсь, регулярно создаются точки восстановления. И вот я попробовал восстановить один из сервисов из резервной копии напрямую в облачную инфраструктуру Microsoft Azure’s Infrastructure as a Service (IaaS)
В итоге я получил не только все те же необходимые ресурсы, но также и практически свежие реальные данные (всего 2-часовой давности), что позволило инженерам без помех завершить свою работу перед тем, как выдавать решение в продакшен.
Для этого мне понадобилось вот что (см. рис.3):
- Резервная копия (VBK), созданная с помощью Veeam® Backup & Replication™ (или Veeam Backup Free Edition или Veeam Endpoint Backup™)
- Подписка Microsoft Azure
- Veeam Direct Restore to Microsoft Azure
- Veeam FastSCP™ for Microsoft Azure ( я использовал его для загрузки данных в\из ВМ Azure)
После восстановления в облако пользователи моего сервиса были обеспечены доступом к инфраструктуре ровно такой же, как если бы это была реальная производственная инфраструктура, к тому же они могли работать с реальными, живыми данными.
2. Тестирование патчей и обновлений
Вот еще один хорошо знакомый всем сценарий. В идеальном мире для тестирования патчей, хотфиксов и обновлений и т.п. я бы использовал точную копию производственной инфраструктуры, где и опробовал бы новинки до применения их в продакшене. В реальности, конечно, большинство ИТ-специалистов не может похвастаться такой копией, имеющейся в их распоряжении. Вместо этого возможны следующие варианты:
· патчи и обновления проверяются на нескольких тестовых серверах. На основе полученных результатов пишутся планы по внедрению изменений и предоставляются на одобрение руководству. Такой вариант имеет ряд потенциально опасных моментов, в частности, обновления не всегда тестируются вместе со всеми имеющимися зависимостями.
· вариант с «волновым обновлением», т.е. сначала патч ставится на 10% серверов, и за их состоянием ведется наблюдение в течение недели. Затем патчатся другие 10%, и еще через неделю – все оставшиеся. Плюс такого подхода в том, что в случае критической ошибки она затронет не всю инфраструктуру, но минус в том, что инфраструктура все же находится под угрозой, и этот риск не всегда оправдан.
Вариант решения
Снова применяю ресурсы публичного облака, где создаю копии производственной инфраструктуры, которые после завершения тестирования я могу отключить или снести. Я могу протестировать и задокументировать свой план внесения изменений, который затем будет отправлен руководству. При этом я могу снимать скриншоты, собирать записи журналов, записывать видео, и т.д. и т.п., то есть выполнять сбор необходимой информации любым удобным способом. Записи журналов понадобятся инженерам, чтобы понять, как ведет себя инфраструктура после установки патча, а скриншоты подтвердят менеджерам, что процесс внедрения изменений задокументирован. А хорошая документация по процессу, в свою очередь, станет подспорьем для коллег, когда кому-то из них понадобится внедрить аналогичные изменения.
Собственно процедура, которую я выполнил для создания тестовой среды, аналогична описанной в предыдущем разделе – разве что может понадобиться восстановить в Microsoft Azure меньше ВМ (в зависимости от ряда настроек). Например, если у вас 3 идентичных веб-сервера, то вы можете протестировать один из них. То же относится и к БД, и к «среднему звену» (см. рис.4).
3. Тестирование резервных копий и планов послеаварийного восстановления
Зададимся простым вопросом: как часто мы тестируем бэкапы? А план послеаварийного восстановления? Раз в неделю, в месяц, в год, или вообще ни разу?
Конечно, всегда найдутся веские причины – нет времени, нет людских ресурсов, нет возможности предоставить выделенную среду для этих целей. В идеальном мире, безусловно, эти тесты выполнять необходимо, но в реальности так происходит не всегда.
И снова на помощь может прийти публичное облако. Восстановление из резервной копии в облачную инфраструктуру имеет ряд преимуществ, например:
- Нет нужды в локальном оборудовании (распределители нагрузок, роутеры, свичи и пр.)
- Как только тестирование закончено, можно очень быстро избавиться от неиспользуемых более ресурсов
- Дополнительное оборудование (брандмауэры, роутеры и пр.) настраивается в том же облаке
- План послеаварийного восстановления тщательно проверен и задокументирован
- Отличный шанс проверить и задокументировать возможность восстановления инфраструктуры в публичное облако на случай, если вся инфраструктура пострадает в результате аварии
Вариант решения
Собственно, все то, о чем я уже писал выше, поэтому не буду повторяться. Но есть еще кое-что, о чем я не упомянул ранее. Компоненты инфраструктуры: брандмауэры, распределители нагрузки, серверы DNS и т.п., - в публичном облаке придется также настроить. Это делается раз и навсегда (то есть на все время действия подписки) – разумеется, за исключением случаев какой-то глобальной реструктуризации. Зато в случае аварии у вас есть идентичная инфраструктура, стоимость содержания которой базируется на стоимости подписки, а не на капиталовложениях в дорогостоящее оборудование.
ИТ-специалисты не всегда склонны использовать публичное облако для поддержки производственной инфраструктуры. Однако стоит подумать о такой возможности при составлении плана аварийного восстановления. Ведь если придется переключиться на резервную копию, то в вашем распоряжении почти моментально окажутся необходимые ресурсы, включая сетевые и аппаратные – и только точная копия инфраструктуры, развернутая на удаленной площадке в филиале, смогла бы составить им конкуренцию.
Заключение
Не всегда нужно полностью переносить инфраструктуру целиком в публичное облако, во многих случаях более эффективно использовать гибридный подход. Использование публичного облака для решения некоторых типовых задач, рассмотренных в этой статье, может стать хорошим подспорьем в рутинной работе и сослужить хорошую службу как инженерам-разработчикам, так и конечным пользователям ПО.
Об авторе
Александр Ширманов, R&D Director, Veeam
Azure Marketplace
Более 3300 разнообразных решений вы всего сможете найти на странице Azure Marketplace. Вы можете найти больше информации о магазине решений Azure Marketplace на нашем русскоязычном портале.
Пользователи Azure могут получить быстрой доступ к решениям Veaam через удобный Azure Marketplace. Начните работать с Veeam уже сегодня!