Есть вопрос?
Зайди на форум

Поиск на сайте: Advanced

Denix - новый дистрибутив Linux. Русификация Ubuntu и установка кодеков

dkws.org.ua
Форум сайта dkws.org.ua
 
Главная    ТемыТемы    АльбомАльбом    РегистрацияРегистрация 
 ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход 

Развитие средств виртуализации в ОС Solaris 10

 
Начать новую тему Ответить на тему    Список форумов dkws.org.ua -> Solaris
 
Автор Сообщение
den

Старожил


Зарегистрирован: 31.01.2006
Сообщения: 13714
Откуда: Кировоград, Украина

СообщениеДобавлено: Пн Июл 02, 2007 5:47 am    Заголовок сообщения: Развитие средств виртуализации в ОС Solaris 10
Ответить с цитатой

Введение


С ростом вычислительной мощности современных процессоров и серверов, особенно с учетом набирающей популярность у разработчиков процессоров многоядерности и многопоточности растет интерес со стороны ИТ сообщества к технологиям виртуализации серверов. Следствием такого интереса является активное развитие существующих технологий виртуализации, а так же появление новых, современных технологий. На данный момент времени существует несколько подходов к виртуализации серверов, их можно классифицировать следующим образом:

• виртуализация на аппаратном уровне
• виртуализация на уровне гипервизора
• виртуализация на уровне операционной системы

Виртуализация на аппаратном уровне, для обозначения которой обычно используется термины раздел (partition) и домен (domain) является наиболее старым и распространенным видом виртуализации серверов. Виртуализация на аппаратном уровне и виртуализация на уровне гипервизора ведут свое начало от мейнфремов. В настоящий момент времени обе этих технологии реализованы практически всеми разработчиками многопроцессорных серверов на основе RISC процессоров. Кроме того, технологии гипервизоров успешно перешли в мир x86, наиболее ярким примером чего является VMware ESX Server.
В случае использования виртуализации на аппаратном уровне разделение ресурсов на домены или раздела производится путем программирования коммутатора, посредством которого объединяются между собой компоненты многопроцессорных серверов. При этом достигается такой уровень изоляции разделов при котором сбой в одном разделе, на каком бы "низком" уровне этот сбой не происходил не может отразиться на работе оставшихся разделов. Такое положение вещей достигается посредством дублирования всех общих для разделов компонентов сервера, в частности самих коммутаторов и системных часов. Данный способ виртуализации требует минимального модификации кода ОС, работающей в разделе. Фактически необходимо только сделать драйвер сетевого интерфейса, объединяющего разделы с системным контроллером. Последний нужен для управления платформой, например для конфигурирования и переконфигурирования разделов, а так же для их запуска и останова. Развитием виртуализации на аппаратном уровне является технология динамического переконфигурирования (Dynamic Reconfiguration, DR), позволяющая изменять набор ресурсов, выделенных разделам, без прерывания работы выполняющейся в разделе ОС. Для использования этой технологии ОС, работающая в разделе, должна поддерживать динамическое управление ресурсами, например возможность динамического добавления процессоров, памяти и устройств ввода-вывода. В Solaris данная технология реализована начиная с Solaris 9.
Технология виртуализация на аппаратном уровне обладает как радом достоинств, так и рядом недостатков. Основным достоинством этой технологии является почти физическая независимость разделов, а так же отсутствие накладных расходов на виртуализацию. Накладных расходов нет так как нет промежуточного между ОС и аппаратным обеспечением слоя, который скрывал бы аппаратные компоненты от ОС и разделял бы доступ к одним и тем же компонентам от разных разделов, то есть выполнял бы роль некого виртуального коммутатора. Это же является и основным недостатком аппаратной виртуализации. Ведь аппаратные ресурсы, например процессорные платы или платы ввода-вывода передаются разделу целиком, то есть в монопольное владение, что приводит к необходимости иметь существенный запас аппаратных ресурсов в случае построения конфигурации с большим количеством разделом. Другой важный недостаток аппаратной реализации так же является следствием использования программируемого коммутатора. В современных процессорах устойчиво наметилась тенденция многопоточности и многоядерности, следствием чего является увеличение мощности процессорных плат, подключаемых к коммутатору. И если например раньше в случае конфигурирования домена с одной процессорной платой USIII под управление раздела передавалось четыре одноядерных процессора, то в случае использования USIV/IV+ под управление раздела передается уже восемь ядер, а учитывая еще необходимость дублирования аппаратных компонентов в разделе для защиты от отказа - то и все 16 ядер, что может оказаться великовато для некоторых приложений. То есть инкремент, на который можно увеличивать ресурсы домена, оказывается достаточно велик. Стоит заметить, что у некоторых производителей многопроцессорных серверов разделы устроены таким образом, что под управление раздела можно передать например часть процессорной платы, но так как при этом теряется основное и наиболее важное преимущество аппаратной виртуализации - физическая изоляция доменов - такое решение не стоить рассматривать как реально используемое в повседневной практике и серьезно брать в расчет.
Технологии виртуализации на уровне гипервизора можно считать развитием технологии виртуализации на аппаратном уровне. В данном случае появляется некий промежуточный между ОС и аппаратным обеспечением слой - гипервизор. Функция гипервизора - разделение одного набора аппаратных ресурсов - процессоров, памяти и PCI адаптеров между несколькими разделами. При этом разделом является уже на аппаратная сущность как в случае аппаратной виртуализации, а некое подобие виртуальной машины, то есть некое подмножество аппаратной платформы, на которой работает гипервизор, специально ограниченное искусственным образом. При этом снимается основное ограничение аппаратной виртуализации - выделение ресурсов разделу возможно на уровне ядра (или аппаратного потока) в случае процессоров или одного адаптера PCI. Правда это же является и основным недостатком гипервизора по сравнению с аппаратной виртуализацией - понятно, что в случае выхода их строя процессора пострадают все разделы, использующие ядра или аппаратные потоки этого процессора. То же можно сказать например про сбой контроллера PCI шины и разделы, использующие PCI адаптеры на этой шине. Кроме того, в отличие от нулевых затрат на виртуализацию в случае аппаратной виртуализации затраты на виртуализацию через гипервизор уже не могут быть нулевыми так как доступ например к адаптерам PCI из разделов происходит уже через виртуальные устройства, на трансляцию обращения которых в запросы к аппаратным устройствам уже нудны процессорные ресурсы. Еще хуже обстоит дело при использовании гепервизоров, которые виртуализируют и процессоры, то есть представляют под управление разделов или виртуальных машин виртуальные процессоры, которые потом транслируются в аппаратные через диспетчер задач. Примером таких гипервизоров могут служить VMware ESX server и XEN. Тем не менее реалии развития мира ИТ таковы, что с течением времени процент использования гипервизоров по сравнению с аппаратной виртуализацией будет увеличиваться, равно как и будет расти популярность еще одной технологии виртуализации - виртуализации на уровне ОС.
Основная особенность виртуализации на уровне ОС состоит в том, что в этом случае на аппаратной платформе (или разделе) работает только один экземпляр ОС, под управлением которого существует несколько операционных окружений, которые имеют все или почти все атрибуты независимой ОС, но пользуются ядром материнской ОС. Реализацией этой технологии можно назвать OpenVZ/Virtuozzo, Linix-VServer, FreeBSD Jails, FreeVPS и Solaris 10 Containers (или Solaris 10 Zones). Основным преимуществом этой технологии является минимизация накладных расходов на виртуализацию за счет использования одного ядра ОС, при этом исчезают расходы на поддержку виртуальных устройств, например виртуальных процессоров и адаптеров PCI, а так же более эффективно используется оперативная память аппаратной платформы - ведь по сравнению например с виртуализацией на основе гипервизора или аппаратной виртуализацией существует только одно ядро ОС, а зачастую и один дистрибутив ОС. Основной недостаток этой технологии является как водится следствием и основного преимущества - так как на аппаратной платформе работает только один экземпляр ОС то все разделы работают под управлением этого экземпляра, то есть все разделы имеют одну и ту же версию ОС и один и тот же набор патчей. Кроме того, в случае проблем на уровне ОС или например необходимости перезагрузки ОС после обновления или изменения конфигурации пострадают все разделы внутри этой ОС. Поэтому наиболее логичным выгладит использование виртуализации на уровне ОС для тех приложений, которые и так бы смогли работать в одном экземпляре ОС, но для эффективной работы которых нужно разделение ресурсов между этими приложениями. При этом приложения, которые требуют разных версий ОС, лучше запускать под управлением гипервизора, создавая разделы на уровне ОС внутри разделов гипервизора в случае необходимости.
В данной статье будут рассмотрены средства виртуализации на уровне ОС, заложенные в ОС Solaris 10 и OpenSolaris - Solaris 10 Containers и XEN.


Solaris 10 Containers, BrandZ и SCLA



31-го января 2005 года вышел последний на данный момент времени релиз ОС Solaris - Solaris 10. Этот релиз открыл новую эпоху в развитии ОС Solaris. Во первых после полугода своего существования, а именно с 14 июня 2005 года Solaris 10 стал "открытым", то есть исходные коды ОС были открыты Sun'ом и доступны всем желающим на условиях лицензии CDDL [1]. Этот проект получил отдельное имя - OpenSolaris. С этого момента вся активная разработка Solaris 10, как силами разработчиков Sun, так и силами сторонних разработчиков ведется в рамках проекта OpenSolaris, на основе которого уже формируются апдейты Solaris 10 и будущих версий Solaris.
Что же касается непосредственно Solaris 10, то в нем появилось достаточно большое количество нововведений, например:

• DTrace
• SMF
• ZFS

Ну и самое главное нововведение - Solaris 10 Containers, технология позволяющая запускать внутри одного ядра несколько независимых операционных окружений. Данному окружению - контейнеру - можно выделять ограниченные аппаратные ресурсы, выполняя таким образом одно из основных условий виртуализации - изоляцию одной виртуальной среды от других с точки зрения используемых ресурсов.
Итак, контейнер - это ОС внутри ОС, которая использует ядро материнской ОС, но имеет следующие собственные атрибуты:


• изолированный от других контейнеров набор процессов
• собственные файловые системы включая корневую файловую систему, и как следствие собственные конфигурационные файлы
• пакеты и патчи, не относящиеся к системным
• свой набор сервисов SMF (за исключением NFS сервера)
• сетевые интерфейсы
• устройства


Таким образом с точки зрения запущенных внутри контейнера процессов контейнер выглядит как полноценная ОС. При этом материнская ОС - первоисточник всех контейнеров - называется глобальным контейнером, а остальные контейнеры, созданные внутри глобального, называются соответственно неглобальными. Зачастую вместо термина контейнер используется термин зона (zone), однако с точки зрения современного русского языка слово контейнер выглядит более благозвучным, поэтому дальше в статье будет использоваться только термин контейнер. Итак, глобальный контейнер, являясь первоисточником для неглобальных контейнеров, выполняет роль управления неглобальными контейнерами, и позволяет:


• конфигурировать (configure) и инсталлировать (install) новые неглобальные контейнеры
• запускать (boot), перезапускать (reboot) и останавливать (shutdown) неглобальные контейнеры
• управлять аппаратными ресурсами, выделенными неглобальным контейнерам
• осуществлять мониторинг неглобальных контейнеров, например количество процессорных ресурсов и памяти, используемых неглобальными контейнерами


Лучше всего продемонстрировать работу с неглобальным контейнером на простом примере. Итак, находясь внутри глобального контейнера (по сути просто в Solaris 10) сначала запускаем команду для конфигурирования неглобального контейнера:

# zonecfg -z testzone 'create; set zonepath=/export/testzone'
# zoneadm list -vc

ID NAME STATUS PATH
0 global running /
- testzone configured /export/testzone

Далее созданный контейнер надо проинсталлировать:

# zoneadm -z testzone install

Preparing to install zone <testzone>.
Creating list of files to copy from the global zone.
Copying <2520> files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize <1026> packages on the zone.
Initialized <1026> packages on zone.
Zone <testzone> is initialized.
Installation of <1> packages was skipped.
The file </export/testzone/root/var/sadm/system/logs/install_log> contains a log of the zone installation.

# zoneadm list -vc

ID NAME STATUS PATH
0 global running /
- testzone installed /export/testzone


После инсталляции контейнер готов к использованию, и его можно запустить:

# zoneadm -z testzone boot

ID NAME STATUS PATH
0 global running /
1 testzone running /export/testzone

Затем можно начинать работу с контейнером:

# zlogin testzone

[Connected to zone 'testzone' pts/3]
Sun Microsystems Inc. SunOS 5.10 Generic January 2005

# zonename
testzone

# ptree

4620 /sbin/init
4622 /lib/svc/bin/svc.startd
4686 /sbin/sh /lib/svc/method/manifest-import
4822 /usr/sbin/svccfg import /var/svc/manifest/network/ftp.xml
4624 /lib/svc/bin/svc.configd
4746 -sh
4823 ptree

Так же с неглобальным контейнером можно работать как и с обычной ОС Solaris 10 через выделенный контейнеру сетевой интерфейс, то есть заходя через сетевой интерфейс контейнера например с помощью например telnet или ssh.
Для определения текущего контейнера, то есть того контейнера под управлением находится в данный момент запущенная сессия telnet/ssh сложит команда zonename.
В основе системы управления аппаратными ресурсами, выделяемыми неглобальным контейнерам, лежит появившийся еще в Solaris 8 Solaris Resource Manager - SRM. В Solaris 10 функциональность SRM "растворилась" внутри ядра Solaris, то есть перестала иметь собственное имя и стала частью ядра Solaris. Кроме того управление выделением аппаратных ресурсов было существенно доработано, а доступная функциональность была существенно расширена.
В основе системы управления ресурсами Solaris 10 лежит понятие пула ресурсов - Resource Pool (RP), а так же механизма динамического изменения выделенных пулам ресурсов - Dynamic Resource Pool (DRP). Оба механизма реализованы с виде служб SMF (наследника системы rc-скриптов) о основаны на технологии Processor Sets.
Основное назначение пула ресурсов - разграничение множества виртуальных процессоров (потоков для US T1, ядер для USIV и многоядерных Opteron/Xeon и непосредственно процессоров для USIII/USII и одноядерных Opteron/Xeon) между различными наборами приложений. В данный момент времени управление процессорами это в принципе основная и единственная задача, за которую отвечает пул ресурсов. В следующих релизах Solaris планируется расширение функциональности ресурсных пулов за счет добавления механизма управления памятью на уровень пула.
Виртуальные процессоры могут иметь как статическую привязку к тому или иному пулу, так и динамическую. При этом в случае статической привязки процессора к пулу этот процессор не может использоваться в других пулах без непосредственного перевода этого процессора посредством выполнения команд динамической реконфигурации пулов. В случае же динамической привязки процессоров к пулам процессоры выделяются и освобождаются по мере необходимости.
Помимо пула ресурсов есть еще две сущности Solaris10 участвующие в управлении ресурсами. Это проект (project) и задача (task). Обе эти сущности представляют собой группы процессов, объединенные вместе для выделения им ресурсов и предназначены для более точного управления ресурсами внутри контейнера.
Как уже говорилось ранее основным недостатком виртуализации на уровне ОС является то, что все разделы ОС вынуждены использовать фактически одну ОС - материнскую, то есть работать под одной версией ОС с одним набором патчей. Этот недостаток присущ всем реализациям на основе технологии виртуализации на уровне ОС, однако технология Solaris 10 Containers является некоторым исключением из этого ряда. Если внимательно посмотреть на список атрибутов контейнера то можно увидеть, что там есть все кроме ядра ОС. А почему тогда бы не позволить создавать контейнеры с операционными системами, отличными от ОС глобального контейнера путем перенаправления системных вызовов приложений таких неглобальных контейнеров ядру ОС глобального контейнера. И такая идея была реализована в ОС Solaris 10 и получила название BrandZ, или Branded Zones [2]. И уже в рамках этой технологии была реализована поддержка первого "неродного" неглобального контейнера Solaris 10 - контейнера Linux. Эта реализация получила название Solaris Containers for Linux Applications (SCLA) [3]. SCLA по понятным причинам поддерживается только в Solaris 10/OpenSolaris x86 и позволяет создавать, инсталлировать и запускать контейнеры с ядром Linux 2.4.21 и glibc 2.3.2. Этому условию соответствуют например дистрибутивы CentOS и RHEL 3.x. При этом на данный момент времени в SCLA могут запускаться только 32-х битные приложения, хотя сам Linux может быть как 32-х битным, так и 64-х битным. Для инсталляции SCLA нужен дистрибутив Linux, из которого реально используется библиотека glibc, init и rc-скрипты. При этом во время работы контейнера SCLA ядро Linux не запускается и не работает а все системные вызовы приложений Linux транслируются ядру Solaris. При этом контейнер SCLA позволяет использовать для приложений Linux, запущенных внутри контейнера SCLA, все преимущества ОС Solaris 10, такие как:

• DTrace, в том числе и для приложений Linux
• SVM/VxVM/MPxIO
• ZFS

Таким образом контейнер SCLA позволяет собрать под управлением ОС Solaris приложения двух различных операционных систем - Linux и Solaris. При этом технология SCLA накладывает следующие ограничения на приложения, выполняющиеся в контейнере SCLA:

• приложение не должно использовать прямой доступ я ядру Linux
• приложение не должно содержать в себе или требовать специфичных модулей или драйверов Linux

Эти ограничения не мешают запускать в контейнерах SCLA такие приложения, как Oracle Server или Thunderbird. При этом приложения Linux, запущенные под управлением SCLA, работают в среднем примерно с той же скоростью, что и под управлением ОС Linux на том же аппаратном обеспечении. SCLA в данный момент времени существует только в рамках проекта OpenSolaris, то есть не перенесен пока в дистрибутив Solaris, однако дистрибутив SCLA может быть загружен с сайта opensolaris.org и инсталлирован в Solaris 10/OpenSolaris. Включение SCLA в официальный дистрибутив Solaris 10 планируется в следующем апдейте Solaris 10 - Solaris 10 U4. Так же к моменту включения SCLA в Solaris 10 вероятно будет реализована поддержка 64-х битных приложений, а так же поддержка дистрибутивов Linux RHEL 4 и SuSE.



OpenSolaris and XEN


Solaris 10 Containers позволяют запускать в виртуальной среде приложений Solaris и Linux под управлением одного ядра ОС Solaris. Однако зачастую этого бывает мало - существует множество приложений, которые официально сертифицированы только с определенной версией Solaris или Linux, при этом иногда для работы приложений требуется определенный набор патчей ОС. Ну и конечно же в контейнере ОС Solaris нельзя запустить приложений Windows. Все это привело к необходимости реализации в ОС Solaris еще одного механизма виртуализации, на этот раз на основе гипервизора. Точнее в данном случае речь идет не о реализации, а о переносе [4] в Solaris гипервизора, который изначально разрабатывался для ядра Linux и NetBSD - XEN. XEN - это свободно распространяемый на условиях лицензии GPL гипервизор разработанный в Кембриджском университете [5]. Сам гипервизор XEN тесно интегрируется с ядром той ОС, на которой он запущен. Кроме того, так как XEN изначально разрабатывался для поддержки паравиртуализации, то он требует модификации ОС, запускаемой под своим управлением - гостевой ОС. Паравиртуализацией называется такой способ виртуализации на основе чаще всего гипервизора при котором гостевая ОС содержит в себе некоторые модификации, которые позволяют ей работать под управлением гипервизора. То есть в случае паравиртуализации гипервизор не пытается полностью заменить собой аппаратный уровень, а является неким передаточным звеном между ОС и аппаратной платформой, расчитывая при этом на то что гостевая ОС умеет работать с предоставляемыми гипервизором интерфейсом. В рамках своих паравиртуализационных возможностей XEN позволяет запускать следующие гостевые ОС:

• Linux
• Net/Free/OpenBSD
• OpenSolaris
• NetWare
• GNU/Hurd/Mach

При этом в качестве материнской ОС XEN может использовать различные дистрибутивы Linux, Net/Open/FreeBSD и OpenSolaris.

Кроме того, после поддержки обоими разработчиками процессоров архитектуры x86 технологии виртуализации на уровне команд процессора - VT-x Intel'ом и AMD-V соответственно AMD - в XEN была реализована "полноценная" виртуализация гостевых ОС, при которой не требуется доработка исходного кода гостевой ОС. В качестве такой немодифицированной ОС может выступать Linux и Windows.
На данный момент XEN перенесен в ОС OpenSolaris с некоторыми ограничениями:


• OpenSolaris поддерживается как материнская и гостевая ОС начиная с OpenSolaris Nevada build 44
• В качестве гостевых ОС так же поддерживается Linux и FreeBSD
• На данный момент отсутствует поддержка немодифицированных гостевых ОС, например Windows


В ближайших планах развития проекта XEN в OpenSolaris - реализация возможности запуска немодифицированных ОС через использование технологии Inet VT-x/AMD-V (соответственно только для OpenSolaris x86). Так же в течении 2007 года планируется появление нового апдейта Solaris 10 на основе OpenSolaris с поддержкой XEN. После появления этого апдейта Solaris 10 станет поистине уникальной операционной системой, сочетающей в себе возможности виртуализации на основе гипервизора и на основе ОС.


[1] http://www.sun.com/cddl/
[2] http://opensolaris.org/os/community/brandz/
[3] http://opensolaris.org/os/community/brandz/brandz_lae_faq/
[4] http://opensolaris.org/os/community/xen/
[5] http://www.cl.cam.ac.uk/research/srg/netos/xen/
Вернуться к началу
Посмотреть профиль Отправить личное сообщение dhsilabs@jabber.ru
den

Старожил


Зарегистрирован: 31.01.2006
Сообщения: 13714
Откуда: Кировоград, Украина

СообщениеДобавлено: Пн Июл 02, 2007 5:47 am    Заголовок сообщения:
Ответить с цитатой

Забыл добавить взято отсюда: http://blogs.sun.com/vbe/entry/развитие_средств_виртуализации_в_ос
Вернуться к началу
Посмотреть профиль Отправить личное сообщение dhsilabs@jabber.ru
Показать сообщения:   
Начать новую тему Ответить на тему    Список форумов dkws.org.ua -> Solaris Часовой пояс: GMT
Страница 1 из 1
 Главная страница сайта
 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
© Колисниченко Денис