Ризикована віртуалізація, Директор інформаційної служби, Видавництво «Відкриті системи»

Як звести ризики при впровадженні ПЗ віртуалізації до мінімуму та зберегти інвестиції у це рішення

Ключові слова :
ІТ-інфраструктура

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

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

Кожен сервер компанії об'єднує кілька сервісів, які згруповані за принципом споживання ресурсів, забезпечення безпеки, можливості відключення і підтримки відмовостійкості. Сервер електронної пошти, DNS, файловий сервер, контролери домену, документообіг, бухгалтерія, технологічне та виробниче програмне забезпечення – все розподілено і побудовано таким чином, що збій та відключення сервера не позбавить компанію всіх ключових сервісів.

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

2. Розподіл критичних завдань з різних обчислювальних кластерів

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

3. Планування часу міграції у віртуальне середовище із запасом та врахуванням непередбачених обставин

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

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

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

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

4. Можливість провести випробування за деякими специфічними рішеннями та забезпечити період спільної роботи нової та колишньої системи

Також передбачте можливість випробувань за деякими рішеннями, період спільної роботи нової та колишньої системи та збереження можливості оперативно розгорнути колишню систему.

Деякі платформи віртуалізації залежать від конкретного апаратного забезпечення, можуть пред'являти до нього свої вимоги, мати обмеження або не мати можливості емуляції необхідних портів, контролерів, пристроїв захисту (наприклад, HASP, e-token) та ін. таких систем у віртуальному середовищі, перш ніж приймати рішення про купівлю та міграцію. В даний час більшість апаратних рішень підтримується ПЗ систем віртуалізації, проте можлива ситуація, коли доведеться відмовитися від віртуалізації деякого сервісу.

5. Навчання персоналу адмініструванню ПО віртуалізації

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

Таким чином, спільно з придбанням ПЗ віртуалізації доводиться закладати деякі кошти на навчання персоналу та, можливо, залучати додаткові людські ресурси для впровадження нової системи.

6. Додаткова мотивація персоналу, який обслуговує ПЗ віртуалізації

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

7. Суворий облік та контроль за витрачанням обчислювальних ресурсів

Розглянемо ситуацію з погляду системних адміністраторів: до застосування ПЗ віртуалізації вони мають у своєму розпорядженні деяку кількість серверів, на кожному з яких працює один або кілька сервісів. Кількість серверів, звичайно, сервіси згруповані в рамках фізичного сервера. Якщо адміністратори отримують завдання розгорнути нову інформаційну систему, вони проводять інвентаризацію існуючих обчислювальних потужностей і, у разі нестачі, порушують питання необхідності придбати додатковий сервер або модернізувати існуючий. ПісляВикористання системи віртуалізації процес створення нового віртуального сервера їм значно спрощується і здійснюється натисканням кількох кнопок. У такій ситуації контроль за витрачанням обчислювальної потужності слабшає, віртуальна платформа намагається задовольнити потреби компанії у розгортанні віртуальних машин і адміністратор починає вважати, що він має необмежену кількість серверів. З'являється новий діловий процес, під нього підбирається програмне забезпечення, яке ставиться на нову віртуальну машину. Можливість легкого розгортання віртуальних машин з часом призведе до неконтрольованого зростання кількості віртуальних серверів, і неминуче складеться ситуація, за якої обчислювальні ресурси закінчаться саме в той момент, коли вони найпотрібніші. Якийсь сервіс незаплановано забере більше обчислювальних потужностей і порушить роботу інших систем. Причому зупинка сервісів може статися лавиноподібно, а ланцюжок подій почнеться з абсолютно безневинної дії — електронною поштою прийде вітальна листівка, яка займе ресурси поштового сервера і навантажить антивірус, що порушить роботу SQL-сервера і т.д. , Потрібно розробити внутрішні нормативні документи, що регламентують облік обчислювальних ресурсів компанії та організують відповідний контроль.

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

8. Контроль за ліцензійною чистотою ПЗ в умовах віртуалізації

Бізнес регулярно вимагає автоматизації, і якщо раніше вартість апаратної частини служила стримуючим фактором, то з впровадженням віртуалізації ПЗ розгортання нової системи стало значно простіше. Потреба створення додаткового екземпляра системи, тимчасової інсталяції або у спільній роботі двох різних версій однієї системи задовольняється швидше. Внаслідок цього кількість віртуальних серверів компанії зростає і згодом управління інфраструктурою стає трудомістким завданням, що може спричинити ризики порушення політики ліцензування. Щоб уникнути таких ризиків, потрібен контроль за ліцензійною чистотою ПЗ, що використовується, і необхідно передбачити можливе збільшення кількості ліцензій. Деякі вендори ПЗ віртуалізації мають пакети ліцензій, які враховують зростання потреби в ліцензуванні системних додатків. Крім кількісного аналізу системних ліцензій, потрібно оцінити потребу у спеціальних ліцензіях під віртуальне середовище для систем резервного копіювання, систем моніторингу, антивірусного програмного забезпечення, систем управління та ін.

Всі ці ризики необхідно враховувати при ухваленні рішення про вибір та впровадження платформи віртуалізації у компанії. Про плюси міграції ЦОД на віртуальну платформу вам розкажуть вендори ПО віртуалізації, а вам потрібно врахувати мінуси при вирішенні зазначених вище завдань, і тоді запланована вартістьпроекту буде ближчим до реальності.

Поділіться матеріалом з колегами та друзями