Сценарии применения бесплатных инструментов Veeam для разработки и тестирования в Microsoft Azure

в 7:23, , рубрики: #isvcloudstory, azure, azure marketplace, dev & test, Microsoft Azure, Veeam, Блог компании Microsoft, инфраструктура, Облачные вычисления, разработка, тестирование

Мы продолжаем рассказывать про решения независимых разработчиков, которые представлены на облачной платформе Azure и в Azure Marketplace. Сегодня о сценариях применения бесплатных инструментов компании Veeam, представленных в Azure Marketplace, рассказывает Александр Ширманов – R&D Director в Veeam. Вы всегда можете найти больше историй по ссылке на Хабре. – Владимир Юнев, Microsoft

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

Я возьму такой пример инфраструктуры: имеется некоторый программный продукт, приложение, над которым постоянно трудятся инженеры (естественно, с целью довести его до совершенства). Основными компонентами являются:

  • сервер баз данных (Backend)
  • «среднее звено», т.е. сервис, выполняющий основные рабочие задачи (Middle-Tier)
  • веб-сайт, с которым непосредственно работают пользователи (Front-Tier)

Сценарии применения бесплатных инструментов Veeam для разработки и тестирования в Microsoft Azure - 1

Рис.1

Раньше для работы над продуктом нужно было развернуть как раз 3 виртуальные машины – по одной для каждого из компонентов. Но продукт совершенствуется, и каждый из компонентов теперь может включать несколько ролей – так, например, веб-сайт теперь задействует не одну, а несколько ВМ, и, соответственно, требует балансировки нагрузки (Load balancer). Нагрузка в «среднем звене» также распределяется. Ну и сервер баз данных теперь использует SQL Server AlwaysOn Availability Groups. В итоге инфраструктура, с которой работают инженеры, приобретает вид, показанный на рисунке 2.

Сценарии применения бесплатных инструментов Veeam для разработки и тестирования в Microsoft Azure - 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

Сценарии применения бесплатных инструментов Veeam для разработки и тестирования в Microsoft Azure - 3

Azure Marketplace

Более 3300 разнообразных решений вы всего сможете найти на странице Azure Marketplace. Вы можете найти больше информации о магазине решений Azure Marketplace на нашем русскоязычном портале.

Пользователи Azure могут получить быстрой доступ к решениям Veaam через удобный Azure Marketplace. Начните работать с Veeam уже сегодня!

Автор: Microsoft

Источник

Поделиться новостью

* - обязательные к заполнению поля