Навіщо ж потрібна віртуалізація, комп’ютерна допомога

Раз вже ми говоримо про віртуалізації - напевно у кого-то виникає цілком резонне питання: а для чого ж це взагалі потрібно? Обмовлюся, що далі мова піде про віртуалізації серверів. Про віртуалізації подань і додатків - можливо, напишу трохи пізніше.

Я, зізнатися чесно, є технарем «до мозку кісток», і модні абревіатури на зразок TCO, ROI, etc. якими дуже люблять оперувати панове маркетологи - для мене є «китайською грамотою». Відповідно - буду писати про те, що я бачу як технар.

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

Але тут виникає нова проблема: кожен окремий сервер - коштує грошей, причому не малих (якщо мова йде про брендових серверах). Кожен окремий сервер споживає електроенергію, і займає місце на столі або в стійці. Можливо, комусь це здасться не особливо актуальним, проте - це є важливою перевагою. Особливо, якщо сервера розміщуються в сторонньому датацентрі, де стягують плату за займані юніти в стійках і енергоспоживання строго обмежується. До того ж, в європейських країнах існує якийсь податок, який безпосередньо залежить від обсягів електроенергії, спожитих компанією. Не пам'ятаю, як цей податок називається - щось пов'язане з екологією і викидом CO2.

Крім цього, кожне з додатків рідко споживає багато системних ресурсів: ті ж контролери доменів і інтернет-шлюзи - на них рідко завантаження процесора перевищує 10%. Використання під кожну таку задачу окремого сервера виглядає нераціонально. Поєднувати все на одному сервері - як ми вже з'ясували, неправильно з точки зору безпеки. Де ж золота середина? Як же зробити, щоб і вовки були ситі, і вівці цілі (і пастуху - вічна пам'ять!) Відповідь дає саме технологія віртуалізації.

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

Простий приклад: якщо у нас є два додатки, яким для роботи необхідно 128Мб оперативної пам'яті, і які не можна встановлювати на один фізичний сервер, можна:

1) Купити два сервера з 128M RAM;
2) Купити один сервер з 256M RAM (плюс ще якась кількість «про запас» і для запуску хостовой ОС) і запустити обидва додатки в окремих віртуальних машинах.

Як видно, у другому випадку ресурси сервера (зокрема, CPU) використовується більш раціонально, і вартість рішення набагато нижче, тому що один сервер з трохи більшим об'ємом RAM завжди дешевше двох серверів.

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

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

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

Як відомо, розгортання нового сервера займає певний час. Це - установка ОС, установка драйверів, установка додатків і т.п. Так, звичайно, всі параметри установки ОС можна задати у файлі відповідей автоматичної установки, драйвера можна інтегрувати в дистрибутив, додатки встановити, наприклад, через RunOnce, але все одно установка займає час. Навіть якщо створити повний образ системи - по-перше, його розгортання все одно займе близько 10-15 хвилин просто через його обсягу і швидкості читання з мережі або з DVD-ROM, по-друге - для створення такого образу, як правило, необхідно вдаватися до допомоги стороннього ПО. З віртуальними ж машинами все набагато простіше: можна створювати абсолютно ідентичні «клони» віртуальної машини за пару кліків мишею, і процес займе близько декількох хвилин - адже швидкість роботи дискової підсистеми сервера набагато вище, ніж пропускна здатність мережі або швидкість читання DVD-ROM.

Наведу приклад з власного досвіду. Контора, де я одного разу працював, займалася, крім іншого, і розробкою програмного забезпечення. Природно, розробникам було необхідно десь тестувати і налагоджувати свої програми. Як не можна краще для цього підходили віртуальні машини. Завдяки клонування - вдалося створити еталонний образ, в результаті якого розгортання нової віртуальної машини займало близько 3 хвилин. А у нас було цілих два сервера, на кожному з яких працювало приблизно по 20 віртуальних машин. До слова сказати - використовувався VMWare ESX Server, було просто два окремих сервера - без VMotion і кластерів. Правда, для управління використовувався Virtual Center.

Навіть якщо робиться бекап, то не завжди можна дати 100% гарантію, що з нього можна буде відновити ОС на «голому залізі», і вона буде працювати без помилок. Особливо - якщо конфігурація апаратного забезпечення буде трохи відрізнятися від попередньої. Близьку до 100% -ної гарантії дають системи резервного копіювання, мають функцію «Bare Metal Restore» - наприклад, Symantec BackupExec, CA ArcServe, IBM Tivoli Storage Manager, HP Data Protector. Але саме це ПО варто цілком пристойних грошей, і за функцію «Bare Metal Restore» доведеться заплатити окремо: для її використання, як правило, необхідна окрема ліцензія.

З віртуальними ж машинами набагато простіше: всі «залізо» там стандартне, бо емульованого, і для повного бекапа досить просто скопіювати один або кілька файлів. Усе. Для відновлення досить просто скопіювати файл (и) на новий сервер, де вже встановлена хостової ОС із середовищем віртуалізації, і «підчепити» їх - і віртуальна машина буде працювати як ні в чому не бувало.

Ще необхідно згадати так звані моментальні знімки (snapshots): це - грубо кажучи - бекап віртуальної машини, що зберігається всередині неї самої. При необхідності можна просто «відкотити» виртуалку на момент зняття моментального знімка - і вона буде працювати, як ніби з того моменту нічого не змінилося. Причому, в однієї віртуальної машини може бути багато таких snapshot'ов, і вони можуть утворювати деревоподібну структуру. Це дозволяє «відкочувати» систему рівно до необхідного моменту. Такий функцією можуть користуватися, наприклад, системні адміністратори, роблячи snapshot до і після будь-яких важливих змін, і, якщо знадобитися, наприклад - відкотитися до моменту змін. Або ще раніше. А потім, якщо треба - пізніше. І не потрібно розгортати систему з нуля і знову повторювати всі свої дії. Наші розробники, до речі, по достоїнству оцінили таку можливість: раніше, коли вони використовували VirtualPC на своїх робочих станціях - робити такі «відкати» було важко, часто доводилося створювати машину заново з еталонного образу.

Отже, підбиваючи підсумок, коротко - чому все ж віртуалізація серверів - це гуд:

Раціональне використання апаратних ресурсів серверів;
Економія грошей на покупку нових серверів, економія електроенергії та фізичного простору;
Економія ліцензій на віртуальні ОС (якщо мова про Microsoft);
Простота адміністрування: легкість переміщення віртуальних машин з одного фізичного сервера на інший, швидкість розгортання нової машини з еталонного образу, простота створення резервної копії та відновлення з неї, використання «моментальних знімків».

Власне, на цьому хотілося б завершити цю статтю.

Олександр Косівченко, MVP