Главной целью тестирования сервера 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 – применяются для схожих задач. Заказчики довольно часто используют серверы T4/Т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 – virtual disk server, ленточные приводы нельзя было презентовать в гостевой домен в принципе. Необходимо отметить, что механизм на текущий момент имеет ряд ограничений. Основное из них заключается в том, что устройства, подключенные к физическому адаптеру, будут доступны всем гостевым доменам, которым назначен соответствующий «виртуальный 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), сервер представляется весьма выгодным вложением в ИТ-инфраструктуру.
Статья подготовлена Юрием Семенюковым, руководителем отдела корпоративных решений Центра проектирования вычислительных комплексов, компании «Инфосистемы Джет». Мы будем рады вашим конструктивным комментариям.
Серверы линейки Oracle SPARC T-series позиционируются как машины Enterprise-уровня для консолидации нескольких систем на одном физическом сервере. Для этого они имеют встроенный гипервизор Oracle VM for SPARC, развитые возможности ОС Solaris 11 по поддержке виртуальных сред, а также многоядерную многопоточную архитектуру. Предыдущие модели линейки – серверы Oracle T4/T5 – применяются для схожих задач. Заказчики довольно часто используют серверы T4/Т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 – virtual disk server, ленточные приводы нельзя было презентовать в гостевой домен в принципе. Необходимо отметить, что механизм на текущий момент имеет ряд ограничений. Основное из них заключается в том, что устройства, подключенные к физическому адаптеру, будут доступны всем гостевым доменам, которым назначен соответствующий «виртуальный 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), сервер представляется весьма выгодным вложением в ИТ-инфраструктуру.
Статья подготовлена Юрием Семенюковым, руководителем отдела корпоративных решений Центра проектирования вычислительных комплексов, компании «Инфосистемы Джет». Мы будем рады вашим конструктивным комментариям.
Поделиться с друзьями
Комментарии (5)
Tomatos
27.09.2016 12:02Ранее такой функционал отсутствовал – дисковые устройства «пробрасывались» в домен через создание пар virtual disk client – virtual disk server, ленточные приводы нельзя было презентовать в гостевой домен в принципе.
А NPIV не позволяет такого, разве?VK_practice
27.09.2016 18:01NPIV позволяет немного другое. NPIV в Solaris 11, примерно как и SR-IOV в OVM for SPARC, позволяют на основе одного физического адаптера создать несколько виртуальных в root-домене. VHBA позволяет создать в гостевом домене виртуальный адаптер, подключенный к физическому или виртуальному адаптеру root-домена через виртуальный SAN. При этом гостевой домен получает полноценный адаптер с поддержкой SCSI-команд и может работать с блочными устройствами.
Использование NPIV или SR-IOV позволяет решить проблему с разграничением доступа к ресурсам нескольких гостевых доменов. VHBA подключенный не к физическому, а к виртуальному адаптеру, будет видеть только те устройства, которые отданы этому адаптеру. Для каждого гостевого домена можно сделать отдельные виртуальные адаптеры в root-домене — в пределах ограничений, конечно.
Seboreia
28.09.2016 00:15Возможно ламерский вопрос, но хотелось бы узнать: по поводу разворачивания ВМ из готового образа — имеется ли какой-нибудь механизм для разворачивания машин с определенными настройками сети? Или это приходится делать отдельными ручными/полу ручными методами?
coolspot
Было бы хорошо сравнить с Oracle x86 на intel+linux такой же ценовой категории и получить графики, таблицы.
А то результат тестов «хорошо подходит для консолидации и виртуализации сред» это не результат.
VK_practice
Небольшое уточнение: в статье рассматривалась не абстрактная виртуализация и консолидация, а на платформе SPARC. Средства управления платформой «OVM for SPARC» стали достаточно гибкими и удобными для построения больших ферм виртуализации.
Сравнение с Oracle x86 на intel+linux (как я понимаю, имеется ввиду OVM for x86) можно проводить для конкретных задач, а не вообще. Результат зависит от требований пользователей прикладной системы, требований самого приложения, от выделяемого бюджета и других факторов. Это сильно влияет на получаемые «графики, таблицы».