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

Ми продовжуємо розповідати про рішення незалежних розробників, які представлені на хмарній платформі Microsoft і в Azure. Сьогодні про сценарії застосування безкоштовних інструментів компанії Veeam, представлених в Azure, розповідає Олександр Ширманов – 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 forMicrosoftMicrosoft(я використовував його для завантаження даних в\з ВМ Azure)
Після відновлення в хмару користувачі мого сервісу були забезпечені доступом до інфраструктури рівно такий же, як якщо б це була реальна виробнича інфраструктура, до того ж вони могли працювати з реальними, живими даними.

2. Тестування патчів і оновлень
Ось ще один добре знайомий всім сценарій. В ідеальному світі для тестування патчів, хотфиксов та оновлень і т. п. я б використав точну копію виробничої інфраструктури, де і випробував би новинки до застосування їх в продакшені. У реальності, звичайно, більшість ІТ-фахівців не може похвалитися такою копією, наявної в їх розпорядженні. Замість цього можливі наступні варіанти:

  • патчі і оновлення перевіряються на декількох тестових серверах. На основі отриманих результатів пишуться плани по впровадженню змін і надаються на схвалення керівництва. Такий варіант має ряд потенційно небезпечних моментів, зокрема, оновлення не завжди тестуються разом з усіма наявними залежностями.
  • варіант з «хвильовим оновленням», тобто спочатку патч ставиться на 10% серверів, і за їх станом ведеться спостереження протягом тижня. Потім патчатся інші 10%, і ще через тиждень – все решта. Плюс такого підходу в тому, що в разі критичної помилки вона торкнеться не всю інфраструктуру, але мінус в тому, що інфраструктура все ж знаходиться під загрозою, і цей ризик не завжди виправданий.

Варіант вирішення

Знову застосовую ресурси публічного хмари, де створюю копії виробничої інфраструктури, які після завершення тестування я можу відключити або знести. Я можу протестувати і задокументувати свій план внесення змін, який потім буде відправлений керівництву. При цьому я можу знімати скріншоти, збирати записи журналів, записувати відео, і т. д. і т. п., тобто виконувати збір необхідної інформації будь-яким зручним способом. Записи журналів знадобляться інженерам, щоб зрозуміти, як веде себе інфраструктура після установки патча, а скріншоти підтвердять менеджерам, що процес впровадження змін задокументований. А хороша документація по процесу, у свою чергу, стане підмогою для колег, коли комусь з них знадобиться запровадити аналогічні зміни.

Власне процедура, яку я виконав для створення тестової середовища, аналогічна описаній в попередньому розділі – хіба що може знадобитися відновити Microsoft Azure менше ВМ (в залежності від ряду параметрів). Наприклад, якщо у вас 3 ідентичних веб-сервера, ви можете протестувати один з них. Те ж відноситься і до БД, і до «середньої ланки» (див. рис.4).

3. Тестування резервних копій і планів післяаварійного відновлення
Задамося простим питанням: як часто ми тестуємо бекапи? А план післяаварійного відновлення? Раз у тиждень, на місяць, на рік, або взагалі жодного разу?

Звичайно, завжди знайдуться вагомі причини – немає часу, ні людських ресурсів, ні можливості надати виділену середовище для цих цілей. В ідеальному світі, безумовно, ці тести необхідно виконувати, але в реальності так відбувається не завжди.

І знову на допомогу може прийти публічна хмара. Відновлення з резервної копії у хмарну інфраструктуру має ряд переваг, наприклад:
  • Немає потреби в локальному обладнанні (розподільники навантажень, роутери, свічі та ін)
  • Як тільки тестування закінчено, можна дуже швидко позбутися від зайвих більше ресурсів
  • Додаткове обладнання (брандмауери, роутери тощо) настроюється в тому ж хмарі
  • План післяаварійного відновлення ретельно перевірений і задокументований
  • Відмінний шанс перевірити і задокументувати можливість відновлення інфраструктури в публічна хмара на випадок, якщо вся інфраструктура постраждає в результаті аварії


Варіант вирішення

Власне, все те, про що я вже писав вище, тому не повторюватимуся. Але є ще дещо, про що я не згадав раніше. Компоненти інфраструктури: брандмауери, розподільники навантаження, сервери DNS і т. п., — в публічному хмарі доведеться також налаштувати. Це робиться раз і назавжди (тобто на весь час дії підписки) – зрозуміло, за винятком випадків якоїсь глобальної реструктуризації. Зате у випадку аварії у вас є ідентична інфраструктура, вартість утримання якої базується на вартості підписки, а не на капіталовкладеннях у дороге обладнання.

ІТ-фахівці не завжди схильні використовувати публічна хмара для підтримки виробничої інфраструктури. Проте варто подумати про таку можливість при складанні плану аварійного відновлення. Адже якщо доведеться перейти на резервну копію, то у вашому розпорядженні майже моментально виявляться необхідні ресурси, включаючи мережеві і апаратні – і тільки точна копія інфраструктури, розгорнута на віддаленій майданчику у філії, змогла б скласти їм конкуренцію.

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

Про автора
Олександр Ширманов, R&D Director, Veeam



Azure
Понад 3300 різноманітних рішень ви зможете знайти на сторінці Azure. Ви можете знайти більше інформації про магазині рішень Azure на нашому російськомовному порталі.

Користувачі Online можуть отримати швидкий доступ до рішень Veaam через зручний Azure. Почніть працювати з Veeam вже сьогодні!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.