Віртуалізація на Oracle SPARC T7-2 – результати наших тестів

Головною метою тестування сервера Oracle SPARC T7-2 було знайомство з новими технологіями апаратного прискорення роботи СКБД Oracle засобами нового процесора Oracle M7, на базі якого побудований сервер (про це — в наших наступних статтях). Паралельно ми протестували функції віртуалізації гіпервізора Oracle VM for SPARC на сервері, про що і піде мова нижче.

Сервери лінійки Oracle SPARC T-series позиціонуються як машини Enterprise-рівня для консолідації кількох систем на одному фізичному сервері. Для цього вони мають вбудований гіпервізор Oracle VM for SPARC, розвинені можливості ОС Solaris 11 за підтримки віртуальних середовищ, а також многоядерную багатопотокову архітектуру. Попередні моделі лінійки – сервери Oracle T4/T5 – застосовуються для схожих завдань. Замовники досить часто використовують сервери Т4/Т5-series в якості заміни кількох застарілих SPARC-серверів. Саме тому Oracle SPARC T7-2 в першу чергу цікавив нас з точки зору можливостей по віртуалізації.

Принципових відмінностей в частині віртуалізації між лінійками T7 і T5 немає. Використовується той же гіпервізор Oracle VM for SPARC, але більш свіжої версії. Архітектурно сервер T7-2 дозволяє більш гнучко розподіляти свої ресурси вводу-виводу між окремими віртуальними машинами (Logical domain, LDom) у зв'язку з появою виділених I/O-контролерів (раніше вони були інтегровані безпосередньо в CPU). Однак по суті загальний підхід до налаштування віртуальної середовища залишається колишнім, а наявний функціонал актуальний і повністю працездатний. Одним з найбільш значимих нюансів є те, що від застарілих версій ОС доведеться відмовлятися: T7-2 накладає певні обмеження на версії використовуваних ОС Solaris 10 і 11.


Рис. 1. Загальна конфігурація віртуального середовища сервера Oracle SPARC T7-2 в рамках наших тестів

В ході тестування ми також перевірили нові функції, які з'явилися в останніх версіях гіпервізора. Одна з них – OVM templates (так звані «шаблони» для швидкого створення віртуальних машин). Можна створювати свої шаблони або використовувати вже наявні. Шаблон включає в себе налаштування віртуальної машини (LDom), необхідну версію ОС, пакети встановленого ПЗ, користувальницькі оточення і т. д. Раз створивши такий шаблон можна розгортати аналогічні віртуальні машини на інших серверах набагато швидше і ефективніше, ніж створювати їх з нуля. Ця функція може значно полегшити завдання розгортання великої кількості схожих віртуальних машин. Це може бути актуально для тих адміністраторів, яким необхідно перенести у віртуальну середу велика кількість невеликих середовищ і систем в стислі терміни.

Інше нововведення – технологія virtual HBA (vHBA). Цей механізм дозволяє повністю емулювати на віртуальній машині повноцінний SCSI-адаптер (FC HBA), який фізично належить одному з керівників доменів (наприклад, primary-домену). Таким чином, всередині віртуальної машини безпосередньо доступні всі ті пристрої, які підключені до цього фізичній адаптера. Тобто дискові пристрої, стрічкові накопичувачі і т. д. можуть бути безпосередньо призначені конкретного гостьовому домені. Раніше такий функціонал був відсутній – дискові пристрої «пробрасывались» в домен через створення пар virtual disk client – server virtual disk, стрічкові приводи не можна було презентувати в гостьовій домен в принципі. Необхідно відзначити, що механізм на поточний момент має ряд обмежень. Основне з них полягає в тому, що пристрої, підключені до фізичного адаптера, будуть доступні всім гостьовим доменів, яким призначено відповідний «віртуальний HBA». Це може створити проблеми з ізоляцією ресурсів між різними гостьовими доменами. Тим не менш, наявність такої функції є ще одним кроком до спрощення налаштування віртуальної середовища на серверах T-series. Радує, що функціонал розвивається. Сподіваємося, що це обмеження буде якимось чином усунуто в наступних версіях прошивок. В цілому механізм vHBA має сенс використовувати в тих випадках, коли потрібна простота в налаштуванні дискових пристроїв або необхідний доступ до специфічних SCSI-пристроїв безпосередньо з гостьових доменів. Як приклад – резервне копіювання безпосередньо на стрічкові приводи.

Окрема увага при тестуванні ми приділили функціоналу автоматизованого управління сервером і його середовищем віртуалізації. В першу чергу, цікавило наявність графічних коштів управління налаштуваннями гіпервізора OVM for SPARC. Ця задача може бути цікава замовникам, широко використовують віртуалізацію Oracle SPARC і бажають зменшити обсяг «ручних» процедур, виконуваних тільки засобами командного рядка. На сьогодні для графічного управління засобами віртуалізації OVM for SPARC доступні 2 варіанти. Ми позначали їх для себе як «легкий» і «важкий». «Легкий» варіант – це ПО Oracle VM Manager. «Важкий» – Oracle Enterprise Manager Ops Center. Обидва інструменту дозволяють з графічної консолі виконувати операції з налаштування віртуальних машин на сервері. Але при цьому зазначені продукти мають принципово різну парадигму управління.

ПО Oracle VM Manager спочатку розвивалося як консоль управління для Oracle VM for x86, функціональність частини SPARC була додана пізніше. OVM Manager зберігає всю конфігурацію у своїй вбудованій базі даних, при цьому сам гіпервізор сервера фактично нічого не знає про віртуальних машинах. У разі виходу з ладу сервера OVM Manager або пошкодження цієї БД конфігурація доменів буде загублена. Крім того, ряд операцій по початкової настройки сервера (створення primary / secondary доменів, поділ фізичних ресурсів) засобами OVM Manager неможливий в принципі, потрібно виконати їх руками. У цілому застосування OVM Manager цілком виправдано для тих компаній, яким необхідно побудова рішень виду «приватне хмара на SPARC», тобто там, де потрібна велика кількість легких середовищ і додатків, при цьому відмовостійкість забезпечується на рівні сервісу, а не гіпервізора.


Рис. 2. Архітектура Oracle VM Manager

ПО Oracle Enterprise Manager Ops Center пропонує інший підхід. По своїй суті Ops Center – це комплексне конвергентне рішення для управління всієї ІТ-інфраструктурою, включаючи сервери, ОС, мережі, системи зберігання даних, кластерні конфігурації, СУБД і т. д. Воно має набагато більш широкий перелік підтримуваного устаткування і ПО, ніж OVM Manager. Управління віртуалізацією є лише невеликою його частиною.

Ops Center цілком використовує конфігурацію з гіпервізора OVM при створенні та управлінні віртуальними машинами. Кількість ручних операцій фактично зводиться до нуля. Таким чином, це рішення може використовуватися тими компаніями, яким потрібні складні, нестандартні конфігурації віртуальних машин. Зазначимо, що протяжність функціональних можливостей Ops Center – почасти і його недолік: продукт досить розлогий», його вивчення вимагає певного часу і наполегливості. Тим не менш, рішення дозволяє звести подання всієї ІТ-інфраструктури компанії в одній консолі.


Рис. 3. Архітектура Oracle Enterprise Manager Ops Center

Висновок за підсумками нашого тестування: сервер Oracle SPARC T7-2 добре підходить для консолідації та віртуалізації середовищ, що функціонують на платформі SPARC. З застосуванням цього обладнання досить ефективно можуть вирішуватися задачі побудови розподілених ферм віртуалізації з динамічним перерозподілом ресурсів і забезпеченням високої надійності. Послідовне розвиток засобів віртуалізації підвищує стабільність платформи, функціональність і зручність застосування для кінцевих користувачів. Наявність автоматизованих засобів управління також спрощує повсякденні завдання по експлуатації і дозволяє підвищити віддачу від використання. З урахуванням нових можливостей у частині продуктивності, вбудованих в CPU (Oracle Database In-Memory), сервер є досить вигідним вкладенням в ІТ-інфраструктуру.

Стаття підготовлена Юрієм Семенюковым, керівником відділу корпоративних рішень Центру проектування обчислювальних комплексів, компанії «Інфосистеми Джет». Ми будемо раді вашим конструктивним коментарям.
Джерело: Хабрахабр

0 коментарів

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