Відсутні структурні елементи OpenStack рівня підприємства: Частина 1 - висока ступінь доступності

Автор: Дмитро Новаковський

Зараз відмінний час для того, щоб бути компанією-учасницею ініціативи OpenStack — ви отримуєте більшу частину даних для маркетингу і управління продукцією, просто розмовляючи щодня з клієнтами і партнерами. Як би те ні було, конкуренція в цій сфері досить висока, тому і для спільноти, так і для окремих вендорів важливо грамотно створити заділ функціональних можливостей і розставити їх пріоритети, при цьому чітко усвідомлюючи, хто і чого хоче. Я виступлю в ролі «капітана очевидність», але все ж скажу, що потреби Підприємства дуже відрізняються від потреб сервіс-провайдера, органу влади або якого-небудь IT-підрозділу, який працює в масштабі World Wide Web.

В цьому пості (і в декількох майбутніх) я поділюся своїми думками щодо функціональних можливостей — фактично «будівельних блоків», які все ще відсутні у OpenStack, але необхідні для того, щоб платформа успішно використовувалася на рівні Підприємства. Крім того, ви дізнаєтеся, ведеться в даний час робота над усуненням цього пробілу і, якщо так, то які рішення існують.

Відсутній структурний елемент №1: висока доступність/відмовостійкість на рівні Підприємства


Висока доступність (High Availability, або HA): для Підприємства це, мабуть, дві найважливіші букви в контексті віртуалізації/хмари. У двох словах, її наявність означає, що у випадку якщо з якої-небудь причини станеться збій у роботі віртуальної машини (VM), наприклад, через відмову операційної системи, виходу з ладу всього вузла гіпервізора і т.п., то центр обробки даних/платформа управління хмарою «поверне її до життя» в найкоротший час. Це може бути зроблено за допомогою швидкого запуску на тому ж хості гіпервізора або термінового перенесення (евакуації) на інший хост гіпервізора. «Екстремальним» режимом для VIP віртуальних машин є «Відмовостійкість», або функціонування двох VM на різних гипервизорах з віддзеркаленням стану CPU/пам'яті таким чином, щоб завжди залишалася хоча б одна зберегла працездатність VM, до якої можна було б звернутися у разі катастрофи.

Чому Підприємству необхідна підтримка високого ступеня доступності?


Історично успіх vSphere на рівні Підприємства в основному будувався на сприйнятті існуючих додатків належать до класу «pets». Такі програми активно розроблялися протягом багатьох років, вони працюють на «голе залізо» і підтримуються в робочому стані спеціальними командами. Програми такого типу, як правило, не готові до роботи на хмарі. Їм практично не притаманна вбудована інтелектуальна обробка відмов, але вони успішно використовуються для задоволення потреб бізнесу і бюджету на їх розробку спланований на багато років вперед.

Крім консолідації на меншій кількості фізичних серверів, vSphere підвищує «якість життя» даних додатків, допомагаючи їм відновлюватися після збоїв, при цьому не вимагаючи від них якогось «обліку роботи віртуалізація/хмарних сервісів». Щоб мати успіх, платформа OpenStack повинна вміти виконувати ту ж функцію.

Як йдуть справи із забезпеченням високого ступеня доступності в OpenStack?


Хороші новини полягають в тому, що «шматочки», необхідні для підтримки високого ступеня доступності вже є, так що для побудови загальної «доступність-послуги» для OpenStack потрібно менше зусиль, ніж можна було б очікувати.

У OpenStack підтримано кілька спільно використовуваних+розподілених серверних систем зберігання даних, які підходять для здійснення динамічної міграції/екстреного перенесення (у нас в Mirantis улюбленої системою є Ceph), а в Nova навіть реалізована команда «nova evacuate», яка призводить до виклику ряду API для екстреного перенесення VM на інший хост гіпервізора.

Чого не вистачає, так це компонента управління+моніторингу (і, звичайно, гарного інтерфейсу і потужного PR ). Якийсь процес повинен ретельно стежити за роботою VM з підтримкою високої доступності на різних рівнях (доступність гіпервізора, працездатність nova-compute, відповідь на пінг VM тощо), і після прийняття рішення «все, вона померла» запускати екстрений перенесення через Nova. Крім того, безумовно, така система повинна гарантувати успіх виконуваного екстреного переносу.

Погані новини полягають у тому, що спільнота OpenStack було (і в деякій мірі до цих пір залишається) непослідовним у визначенні вектора розвитку OpenStack в контексті забезпечення доступності додатків. На щастя, останній Саміт в Атланті зміцнив думку щодо необхідності «Завоювання Підприємств» і, зберігаючи повагу до початкових принципів OpenStack, що передбачає «застосування методології DevOps/готовність до використання хмари», багато які висловлюються відкрито члени спільноти підтримують ідею «створення сервісу, який би використовував API-функції Nova для моніторингу інших сервісів або всіх VM і автоматично виконував певні дії, такі як запуск другого примірника з останнього снапшота тома, створення додаткових примірників тощо».

Найнеприємнішим (або, можливо, просто невдалим) моментом є те, що поки співтовариство не виробило послідовної позиції, деякі потенційні клієнти, які розглядають можливість запровадження OpenStack, могли отримати неправильний меседж і думають: «OpenStack ніколи не буде піклуватися про забезпечення високої доступності, що виходить за рамки власної інфраструктури контролерів». Цікаво, чи є у нас ще час, щоб повернути довіру цих людей.

А тепер настає момент істини: хто буде писати код, і коли він перетвориться в корисну функціональність?

Тимчасове рішення


Хтось може стверджувати, що можливим рішенням є налаштування систем Nagios або Zabbix, виконують інтенсивний опитування віртуальних машин класу «pet», і скриптів, які запускають екстрений перенесення. Це може спрацювати в якійсь дивній середовищі типу «зроби сам», але, я думаю, що в контексті управління це дуже громіздко для рівня підприємства. Не варто забувати про те, що IT найчастіше досі є місцем виникнення витрат на підприємстві, тому нам потрібно полегшити роботу працівникам IT, а не навпаки. Далі, можна також розглянути можливість використання Heat в якості «машини станів», а Ceilometer в якості аварійного адміністратора, але, принаймні, на даний момент немає яких-небудь відповідних історій успіху, про яких можна було б говорити.

Реальний компроміс в даному випадку — почати впроваджувати OpenStack з одночасним використанням гіпервізора KVM і vSphere (за умови наявності у підприємства певних ліцензій vSphere). OpenStack може бути корисною для самообслуговування/колективної оренди/оркестровки та хостингу додатків, готових до роботи з хмарою на базі KVM, а vSphere буде робити те, що вона робить краще за все, — виконувати роль ведучого вузла для додатків класу «pet» і дбати про те, щоб вони залишалися задоволені віртуалізацією «зразок голого заліза».

На щастя, компанія VMWare вклала чимало коштів у розробку драйвера vCenter для Nova, і, як роз'яснив Kenneth Hui в серії своїх відмінних постів, функціональні можливості типу HA, DRS і vMotion функціональні, навіть працюючи під OpenStack. Ви навіть можете з легкістю скористатися перевагами такої установки — див. наші останні пости на тему того, як використовувати Mirantis OpenStack для побудови свого першого комплексу OpenStack+vSphere.

Які ще функціональні можливості, на ваш погляд, потрібні OpenStack для того, щоб домогтися успіху на рівні Підприємства?

PS: Не забувайте про те, що підтримка високого ступеня доступності включена в vSphere, починаючи з виходу Essentials Plus Kit, другого найменш дорогого пропозиції VMWare після ESXi-only Essentials Kit, але для його використання вам також буде потрібна ліцензія на vCenter.

Оригінал статті на англійській мові.

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

0 коментарів

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