Віртуалізація робочого столу: догляд за віртуальними середовищами та їх живлення

Віртуалізація робочого столу: догляд за віртуальними середовищами та їх живлення

Віртуалізація перетворилася з аномалії, яка потребувала пояснення, до життєздатної технології, без якої більшість із нас не може жити. Можливо, ви використовуєте його для перевірки якості, розробки, веб-дизайну чи навчання. Можливо, ви є частиною авангарду — встановлюєте тенденції, розгортаючи віртуальну інфраструктуру, або навіть один із мас, які використовують «хмарну» віртуалізацію від Amazon.com, Rackspace Inc. чи іншого хмарного постачальника.

Незалежно від того, як ви використовуєте віртуалізацію, якщо ви користуєтеся нею протягом певного періоду часу, ви, безсумнівно, розумієте, що вона пов’язана зі своїми проблемами — так само, як обслуговування фізичного обладнання має свої власні дилеми. Багато питань різні; інші подібні.

Обробка гіпервізорів

Ви, мабуть, чули слово «гіпервізор» якийсь час використовувався. Це став крутий термін у віртуалізації. Однак гіпервізори не є чимось новим. Ми використовуємо їх стільки, скільки використовуємо віртуальні машини (VM). Насправді IBM ввела термін гіпервізор у 1970-х роках.

Гіпервізор — це програмне забезпечення, яке представляє гостям, що працюють «віртуально» в системі з набором віртуалізованого обладнання. Він абстрагує фізичне обладнання для гостьових ОС. Плутанина виникає через великий поштовх до «гіпервізорів типу 1», що працюють на платформі x86 протягом останніх кількох років, включаючи Microsoft Hyper-V і VMware ESX Server. Гіпервізор, який використовує більшість людей, особливо для клієнтських систем, називається «гіпервізором 2 типу». яка різниця

  1. Гіпервізор типу 1 працює безпосередньо на апаратному забезпеченні хоста і не потребує «основної ОС». Microsoft Hyper-V і VMware ESX Server є типовими прикладами гіпервізора типу 1.
  2. Для роботи гіпервізора типу 2 потрібна головна ОС. Як правило, гіпервізор типу 2 працює в основному як програма в режимі користувача на своїй хост-ОС. Microsoft Virtual PC і VMware Workstation є типовими прикладами гіпервізора типу 2.

Найчастіше ви хочете використовувати гіпервізор типу 1 для будь-якого «завжди ввімкненого» робочого навантаження, такого як віртуалізований SQL або файловий сервер. Як мінімум, він використовуватиме менше ресурсів, ніж тип 2. Однак, залежно від хоста, для запуску може знадобитися вхід користувача, що не є гарним варіантом для критично важливої ​​системи. Гіпервізор типу 2, з іншого боку, має більше сенсу для віртуальних машин «на вимогу». Цей тип ролі включає віртуальні машини для тестування, сумісності програм або безпечного доступу.

Що економить віртуалізація?

Очевидною відповіддю є те, що віртуалізація економить гроші на апаратному забезпеченні, але це не так просто. Звісно, ​​якщо у вас є дві серверні системи у форм-факторах 1U для встановлення в стійку, і ви берете ці два однакові робочі навантаження та завантажуєте їх на одну систему 1U, ви заощаджуєте на початкових витратах на апаратне забезпечення, але в цьому є хитрість. Якщо ви візьмете ті самі дві серверні системи, обидві успішно працюють на двох окремих серверах 1U, кожен з яких має двоядерні процесори, 2 ГБ оперативної пам’яті та жорсткий диск SATA на 160 ГБ.

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

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

Скільки коштує віртуалізація?

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

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

Навіть якщо ви просто віртуалізуєте купу гостьових ОС для тестування або розробки на гіпервізорі типу 2, вам все одно потрібно виділити достатньо оперативної пам’яті для запуску однієї або кількох із цих гостьових систем одночасно (поверх головної ОС). Проблема, яка найчастіше забувається в управлінні віртуалізацією, – це використання дискового простору.

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

Одна з віртуальних машин, якою я регулярно користуюся, має образ жорсткого диска на 50 ГБ — я не усвідомлював, як він вийшов з-під контролю, доки не спробував його перемістити (на ньому було шість знімків VMware), а диск був значно більшим за 125 ГБ.

 Нижче наведено кілька найкращих методів, щоб мінімізувати вплив/вартість віртуалізації.

  • Якщо ви використовуєте клієнтську ОС Windows на гіпервізорі типу 2 із функцією «скасування», то обов’язково вимкніть відновлення системи Windows . Інакше ви матимете зростання диска кожного разу, коли ви змінюватимете систему.
  • Якщо ви виконуєте крок 1, будьте релігійними щодо розмежування, коли ви хочете створити точку скасування.
  • Якщо ви проводите тестування на безпеку/експлойт, не покладайтеся на Windows, щоб повернути вас до попереднього моменту. Використовуйте функцію скасування свого гіпервізора, оскільки його зазвичай не можна зіпсувати, як точки відновлення.
  • Запускайте гостьові ОС з мінімальною кількістю необхідних ресурсів.
  • Переконайтеся, що ви виділили достатньо оперативної пам’яті, щоб клієнтські ОС не замінювали оперативну пам’ять постійно на диск. Це може уповільнити роботу вашого господаря та всіх ваших гостей.
  • Виконайте внутрішню дефрагментацію своїх гостей, а потім дефрагментуйте їх зовні (див. розділ про дефрагментацію пізніше). Робіть обидва з певною регулярністю.

Поширення ВМ

Як бачите, керування віртуальними машинами може швидко стати проблемою. Легкість копіювання віртуальної машини може бути великою перевагою, але це також може створити величезні проблеми з керуванням і захистом гостей, відстеженням ліцензій ОС у Windows (до Windows Vista, де нове керування ключами може стати в нагоді), і стежити за тим, щоб комерційні таємниці не вислизнули з ваших рук. Співробітнику-шахраю набагато простіше отримати віртуальну машину через флеш-накопичувач USB або жорсткий диск USB, ніж спробувати взяти всю настільну систему.

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

Управління системами

Цілі компанії почали зосереджуватися на допомозі відновити контроль над віртуалізованими системами. І Microsoft, і VMware свідомо зосереджувалися менше на цінності самої віртуалізації, а більше на системному управлінні. Це важливо, оскільки ви не позбавляєтеся систем — ви просто віртуалізуєте їх.

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

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

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

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

Програмне забезпечення безпеки

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

Але велика різниця полягає в тому, що некритичні віртуальні машини (ті, які не завжди ввімкнені) часто мають затримку для виправлення та оновлень AV. У результаті вони можуть стати набагато більшою, невідстежуваною ціллю для експлойтів нульового дня. Це ще одна причина, щоб переконатися, що ви використовуєте зріле рішення для керування системами, яке може врахувати це та виправити віртуальні системи.

Вихідні загрози – це інша справа. Віртуальні машини можуть бути дверима до крадіжки інтелектуальної власності. Це важливо розуміти, оскільки віртуальні машини, що працюють на неконтрольованих хостах, можуть створити лазівку для ваших даних. По-перше, якщо віртуальне середовище можна легко скопіювати, це проблема, особливо якщо ви маєте справу з будь-якими вимогами відповідності, які контролюють доступ до даних (як я обговорював у статті ще в 2008 році, ( https://technet.microsoft. com/magazine/2008.06.desktopfiles ).

По-друге, як ви, мабуть, пам’ятаєте з моєї статті про RMS та IRM ( https://technet.microsoft.com/magazine/2008.11.desktopfiles ), ці елементи керування покладаються на ОС, щоб запобігти захопленню екрана, друку тощо. Однак ці елементи керування не поширюються на гіпервізор — це означає, що якщо вміст, захищений RMS, відображається в гостьовій ОС, хост-ОС все ще може друкувати окремі знімки екрана або створювати відеозйомку екрана.

Хоча технічно це не аналог, він не зовсім відрізняється від «аналогового отвору». Я не знаю жодного способу захисту вмісту, контрольованого DRM, від використання таким чином. Реально, навіть якби ви змогли, ви знову повернетесь до проблеми захисту від користувачів із камерами чи відеокамерами, які можуть вдатися до такого ж «експлойту».

Дефрагментація диска

Дефрагментація диска є унікальною проблемою для віртуальних машин з кількох причин:

  1. Зазвичай ви матимете два рівні фрагментації — у самому контейнері віртуалізованого диска (фрагментація, яку кожен з гостей бачить від свого імені) — те, що я називаю «первинною фрагментацією», і фрагментація фактичного файлу, що містить віртуалізований диск, на дисках хост-ОС, або «вторинна фрагментація».
  2. Продукти віртуалізації з дисками мінімального необхідного розміру, які збільшуються «на вимогу», можуть призвести до вторинної фрагментації.
  3. Функція скасування може швидко призвести не лише до розвантаження диска, але й до масивної вторинної фрагментації, оскільки, споживаючи додатковий простір на диску ОС хоста, кожен гость починає конкурувати за доступні сектори.
  4. З дисками, які збільшуються за вимогою, більшість не мають можливості зменшуватися, коли попит зменшується. Якщо ви виділяєте 40 ГБ, спочатку використовуєте лише 10 ГБ, але зростете до 35 ГБ, диск не відновиться сам по собі, тобто у вас є великий файл, імовірність вторинної фрагментації якого набагато більша.

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

Ось один із підходів до захисту ваших файлів:

  1. Зведіть до мінімуму використання будь-якої технології скасування, оскільки це призведе до надмірного збільшення файлів диска в цілому та не може бути легко дефрагментовано в гостьовій системі, хоча хост може дефрагментувати файли, які складають віртуальний диск.
  2. Для початку використовуйте для гостей хороший продукт для дефрагментації диска та запускайте його регулярно.
  3. Якщо ви використовуєте технологію розширення диска за вимогою:
    a. Використовуйте утиліту Sysinternals sdelete.exe таким чином: sdelete –c буква_диска , де буква_диска — це том, який потрібно обнулити. Наприклад, sdelete –c C: звільнить весь невикористаний дисковий простір після дефрагментації.
    b. Використовуйте будь-яку технологію стиснення віртуального диска (якщо надається вашим постачальником), щоб зменшити контейнер віртуального диска до мінімального розміру
  4. Дефрагментуйте томи головної ОС, що містять віртуальні машини.

Багато людей нехтують дефрагментацією диска. Величезний обсяг пошти читачів, яку я отримав із моєї статті про дефрагментацію диска в 2007 році (technet.microsoft.com/magazinebeta/2007.11.desktopfiles), довів, що цю тему часто неправильно розуміють, але її не слід ігнорувати — навіть у віртуалізованих системах.

У міру того, як віртуалізація продовжує зростати у важливості та застосуванні, може стати надто легко захопитися повідомленням про «консолідацію», не розуміючи витрат і ненавмисних складнощів. Це має допомогти вам виявити деякі додаткові витрати, які потрібно враховувати під час переходу на віртуалізацію або життя з нею.

Translate »