Введение

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

Применительно к продукту IBM Informix Dynamic Server виртуализация полезна в качестве механизма отделения сервера данных от серверов приложений в двух- или в трехуровневой среде. Кроме того, виртуализация существенно упрощает имитационное моделирование сред с несколькими экземплярами сервера данных на нескольких компьютерах, например, сред репликации с использованием технологии ER, HDR или MACH11.

Гипервизор Xen – это менеджер виртуальных машин (VM) с открытым исходным кодом, предлагаемый по лицензии GNU Public License GPL2. Изначально этот продукт было создан в Кембриджском университете, а его дальнейшее развитие осуществлялось компанией XenSource, Inc. В августе 2007 г. компания XenSource, Inc была приобретена компанией Citrix Systems, Inc. В настоящее время гипервизор Xen поддерживается несколькими аппаратными архитектурами, в том числе Intel x86, Intel x86_64, IA64 и Power PC, и несколькими операционными платформами, включая Linux, Solaris, Microsoft Windows® и несколько BSD-версий UNIX®. Гипервизор Xen представляет собой тонкую программную «прослойку», которая функционирует между аппаратными средствами и операционной системой. Такая организация обеспечивает исполнение нескольких различных экземпляров операционной системы на одном и том же наборе аппаратных средств.

Применения виртуализации Xen

• Повышение коэффициента использования

  Технология виртуализации Xen избавляет от забот о функциональной совместимости и позволяет развертывать совершенно разные и независимые друг от друга приложения на одних и тех же аппаратных средствах. Если существующие аппаратные средства недозагружены, то их свободные ресурсы могут быть использованы виртуальными машинами. Вопрос о приобретении новых аппаратных средств возникает только тогда, когда коэффициент использования существующих средств приближается к максимуму.

• Консолидация

  В распределенной и гетерогенной среде «разрастание» систем и приложений может выйти из-под контроля, особенно в периоды быстрого роста. В некоторый момент такие среды становятся настолько переплетенными и взаимозависимыми, что это приводит к существенному усложнению и удорожанию управления и технической поддержки. Это означает, что пришло время для консолидации. Гипервизор Xen позволяет централизовать различные системы (операционные системы и прикладное программное обеспечение) на небольшом числе компьютеров, что существенно упрощает управление системами и снижает расходы на техническую поддержку. Кроме того, во многих случаях консолидация обеспечивает дополнительную экономию за счет сокращения энергопотребления (например, на кондиционирование воздуха, на охлаждение и на энергоснабжение).

• Повышение гибкости

  Гипервизор Xen обеспечивает быстрое развертывание новых виртуальных машин. Пока существующие аппаратные средства имеют свободные ресурсы, можно обойтись без приобретения новых аппаратных средств (которому может предшествовать весьма длительный процесс утверждения). Например, при необходимости проведения тестирования можно создать новую виртуальную машину в течение нескольких минут, включая защищенный доступ уровня root. С помощью гипервизора Xen можно смоделировать на одном компьютере даже такие сложные среды тестирования, как кластерные машины или сценарии IDS MACH11. Поставщики услуг используют виртуализацию для оперативного предоставления своим клиентам полных систем или для быстрого реагирования на изменившиеся потребности.

Как работает Xen?

До появления Xen виртуализация обычно реализовывалась с использованием т.н. микроядра. По существу, микроядро – это операционная система, функционирующая «под» другой операционной системой. Микроядро содержит драйверы устройств и осуществляет обмен двоичными данными между основной операционной системой и драйверами устройств. Таким образом, с точки зрения операционной системы микроядро играет роль нативного чипсета, что, однако, существенно повышает непроизводительные издержки. Вследствие взаимозависимостей между микроядром и операционной системой для этих объектов необходимы раздельные графики технического обслуживания. Кроме того, микроядро уязвимо к отказам драйверов устройств, а общая сложность требует для уровня виртуализации большого объема кода.

В гипервизоре Xen используется т.н. метод паравиртуализации (paravirtualization). Этот передовой метод, впервые реализованный в Xen, сразу обеспечил гипервизору Xen существенное преимущество. При использовании паравиртуализации виртуализация охватывает только базовые ресурсы платформы, включая центральные процессоры, блок управления памятью, память и низкоуровневые прерывания. На некоторых архитектурах (например, Intel VT-x и AMD Pacifica) эта возможность реализована аппаратными средствами. Драйверы устройств отделены от гостевых операционных систем. Поддерживаются все нативные Linux-драйверы устройств.

Это позволило существенно уменьшить объем кода Xen, а также повысить его эффективность и надежность. Гостевые операционные системы должны взаимодействовать с Xen, однако это весьма незначительно снижает производительность. Кроме того, отделение драйверов устройств от гостевых операционных систем обеспечивает независимость между циклами выпуска программного обеспечения и избавляет от необходимости раздельного технического обслуживания.

В качестве аппаратных средств используется стандартный персональный компьютер (ПК) с одним двухъядерным процессором Intel. Кроме того, этот процессор поддерживают технологию аппаратной виртуализации Intel VT-x. Удостоверьтесь в том, что у вас установлена операционная система SUSE Enterprise Linux Server (SLES) 10.1 (от Novell); эта система устанавливается вместе с гипервизором Xen 3.0. Поскольку гипервизор Xen 3.0 входит в состав SLES 10, необходима всего одна процедура установки. Достаточно убедиться в том, что во время установки SLES был установлен и гипервизор Xen.

Для тестирования зависящих от операционной системы функциональные возможностей IDS было выделено два дисковых раздела для блочных устройств, предназначенных для использования в виртуальной машине. Один из этих разделов необходим для файловой системы, другой – для чанков (chunk) IDS на raw-устройствах. После установки необходимо создать виртуальную машину (VM).

В качестве привилегированного пользователя (root) с помощью инструмента установки yast2 выберите опции Virtualization и Virtual Machine Manager. Затем выберите опцию New для создания VM. В следующем установочном меню выберите I need to install an operating system (Необходимо установить операционную систему), а затем SUSE Linux Enterprise Server 10. В качестве метода виртуализации выберите опцию Paravirtualization (Паравиртуализация). Поскольку у данного компьютера имеется всего два физических процессорных ядра, виртуальная машина VM конфигурируется всего с одним центральным процессором. Это означает, что на исполнение VM будут задействоваться только ресурсы, соответствующие одному из двух имеющихся ядер, а другое ядро останется свободным для использования основной системы и диспетчера виртуальных машин. Теоретически возможно сконфигурировать VM с числом процессоров, превышающим число физических процессоров (или ядер) в компьютере. Однако так поступать не рекомендуется, поскольку это приводит к снижению производительности.

Важнейшие команды для управления виртуальной машиной (VM) Запуск VM: xm start <VM name> Доступ к работающей VM: xm console <VM name> Просмотр конфигурации VM: xm list -l <VM name> Уведомление об изменении конфигурационного файла: xm new -F <VM name> Остановка VM: xm shutdown <VM name>

Существует несколько команд для управления вновь созданной VM из окна терминала. Обычно эти команды выполняются от имени привилегированного пользователя (root). Команда start (xm start <VM name>) запускает виртуальную машину VM и загружает в нее экземпляр операционной системы Linux. Для доступа к системе, работающей в VM, используется команда console (xm console <VM name>). Для просмотра текущей конфигурации VM используется команда list (xm list -l <VM name>). Если в конфигурационный файл были внесены изменения, виртуальная машина уведомляется об этих изменениях с помощью команды new (xm new -F <VM name>). И, наконец, для остановки VM используется команда shutdown (xm shutdown <VM name>). Эти команды также могут быть выполнены из инструмента yast2 (для этого необходимо в меню выбрать пункты Virtualization и Virtual Machine Manager).

Теперь, когда VM исполняется на нашем компьютере, на нем установлено два экземпляра операционной системы Linux. Основной экземпляр, функционирующий непрерывно и обеспечивающий деятельность диспетчера виртуальных машин, в общем случае имеет имя Dom0 (domain 0). Ссылки на виртуальную машину (VM) осуществляются по имени, поскольку на компьютере может быть запущено более одной VM. Однако в нашей ситуации работает только одна виртуальная машина, поэтому в дальнейшем она называется просто VM.

Для многих задач (например, для передачи файлов) наиболее простым способом подключения к VM является сетевое соединение TCP/IP. С этой целью настройте свои сетевые соединения, сконфигурировав сетевые платы для доступа к Dom0 и к VM. На автономном компьютере для этой сетевой конфигурации можно использовать частные IP-адреса. После установки сетевого соединения вы сможете использовать, для подключения к VM и обмена файлами между Dom0 и VM такие команды, как ssh и scp.

Конфигурирование блочных устройств для VM

Для работы с чанками IDS в VM нужны блочные устройства. Чтобы сделать блочные устройства доступными для какой-либо VM, необходимо в конфигурационный файл этой VM добавить информацию о конфигурации соответствующих устройств. Сначала выполните команду xm list -l <VM name> > <VM name.sxp> для сохранения текущей конфигурации VM в конфигурационном файле этой VM в каталоге /etc/xen/vm. Затем отредактируйте этот файл /etc/xen/vm/<VM name>.spx, добавив в него следующих элементов:

• (dev <partition>:disk)
• (uname phy:/dev/<partition>)
• (mode w)

Пример представления блочных устройств в конфигурационном файле VM:

 device
 (vbd
 (uuid 506cebr8-0a9e-c391-b34e-58768afc2f27)
 (devid 51728)
 (driver paravirtualised)
 (dev sda8:disk)
 (uname phy:/dev/sda8)
 (mode w)
 (type disk)
 (backend 0)
 )

 device
 (vbd
 (driver paravirtualised)
 (dev sda7:disk)
 (uname phy:/dev/sda7)
 (mode w)
 (type disk)
 (backend 0)
 )

После редактирования конфигурационного файла необходимо известить VM о внесенных в него изменениях. Для этого выполните команду xm new -F <VM name>.

Из двух блочных устройств, сконфигурированных в предшествующем примере, первое (с именем раздела sda8) позднее будет использовано для конфигурирования чанков IDS на raw-устройстве. Второе устройство (с именем раздела sda7) будет использовано для создания файловой системы.

Для raw-устройства какого-либо дальнейшего конфигурирования не требуется. Тем не менее согласно общепринятой практике работы с IDS рекомендуется создать в файловой системе (и затем использовать) символическую ссылку, указывающую на соответствующее raw-устройство. Например, команда ln -s /dev/sda8 ~informix/rawdisk1 создает в основном каталоге пользователя informix символическую ссылку с именем rawdisk1, которая указывает на raw-устройство /dev/sda8. При создании чанков IDS используйте имя символической ссылки (а не имя raw-устройства). Узнать о том, использует ли IDS raw-устройства, можно по существованию потоков IDS с именем KAIO. Для этого выполните команду onstat -g ath.

Подобные изменения в конфигурацию VM рекомендуется вносить с помощью описанного выше метода. Кроме того, изменения в конфигурацию VM можно вносить в интерактивном режиме. Однако изменения, внесенные в интерактивном режиме, не являются постоянными. После остановки и перезапуска VM такие изменения будут утеряны.

Установка IDS на виртуальной машине не имеет каких-либо особенностей и ничем не отличается от установки IDS на нативной платформе SLES 10 Linux.

Некоторые функциональные возможности IDS зависят от конкретной операционной системы (ОС), под управлением которой работает IDS. Нас интересует, сможет ли IDS использовать все эти ОС-специфические функциональные возможности при работе в VM под управлением гипервизора Xen, который представляет собой программную «прослойку» между операционной системой и аппаратными средствами.

• Raw-устройства

  В отличие от доступа к файлам в файловой системе доступ к raw-устройствам осуществляется непосредственно, без использования какого-либо программного уровня между драйвером устройства и приложением. Поэтому raw-устройства обходятся без буферизации, которая обычно применяется при доступе к файлам файловой системы. Вследствие этого, сообщение об успешном выполнении системного вызова записи на raw-устройство – это гарантия того, что данные действительно были записаны на диск, а не переданы на тот или иной уровень буферизации, где данные могут быть полностью потеряны в случае какого-либо разрушительного события (например, отключения электропитания). Это чрезвычайно важно с точки зрения транзакционной концепции IDS. В условиях, когда IDS полностью контролирует дисковую деятельность, raw-устройства обычно используются более эффективно и, соответственно, с более высокой производительностью.

• KAIO

  Операции ввода/вывода с дисковыми устройствами обычно занимают определенное время. Другими словами, после генерации системного вызова чтения или записи проходит определенное время до завершения соответствующей операции ввода/вывода и возврата системного вызова. На протяжении этого времени вызывающий процесс не может выполнять другую работу, поскольку он «застрял» в системном вызове ввода/вывода. По указанной причине в IDS всегда используется асинхронный ввод/вывод. В этом случае рабочий процесс не должен ждать завершения операции ввода/вывода, а может в это время выполнять другие необходимые действия. Как только операция ввода/вывода завершится, вызывающий процесс будет оповещен об этом. В сочетании с поточной архитектурой IDS это обеспечивает очень эффективное использование центрального процессора.

  Технология KAIO (Kernel Asynchronous I/O) еще более эффективна, чем асинхронный ввод/вывод. При использовании этой технологии операционное ядро осуществляет асинхронный ввод/вывод от имени вызывающего процесса. При использовании KAIO у IDS отсутствует необходимость в дополнительных процессах для выполнения асинхронного ввода/вывода, что избавляет от соответствующих непроизводительных издержек, обуславливаемых подобными процессами. KAIO используется с raw-устройствами и обеспечивает тот же уровень эффективности и контролируемости операций ввода/вывода.

• Непосредственный ввод/вывод

  Непосредственный ввод/вывод – это сравнительно новый метод ввода/вывода, предлагаемый операционной системой Linux. Этот метод обеспечивает такой же контроль над операциями ввода/вывода, как и при использовании raw-устройств, но при этом поддерживает операции ввода/вывода с файловой системой. По указанной причине использование raw-устройств больше не является обязательным требованием для эффективной работы IDS в среде Linux. Кроме того, использование непосредственного ввода/вывода вместо raw-устройств избавляет от необходимости сложного конфигурирования таких устройств.

• Отсутствие «старения»

  Как правило, операционная системы, включая Linux, снижает назначенный приоритет длительного процесса по мере его исполнения. Это называется «старением» процесса (process aging). Данный подход благоприятствует недавно запущенным или коротким процессам, исходя из допущения, что долго работающие процессы не предполагают быстрого получения результатов. Однако для сервера данных (в том числе для IDS), который должен быть доступен постоянно, подобное управление назначаемыми приоритетами контр продуктивно. Особенно в тех случаях, когда IDS исполняется на выделенном компьютере, отсутствуют основания для снижения приоритета IDS, поскольку этот компьютер не выполняет каких-либо других задач, сопоставимых по важности.

  Чтобы избежать такого назначаемого по умолчанию поведения планировщика процессов операционной системы, механизм старения для определенного процесса можно отключить. Приоритет этого процесса не будет уменьшаться с течением времени. Напротив, этот процесс всегда будет планироваться с одним и тем же неизменным приоритетом, что гарантирует ему получение достаточного объема процессорных ресурсов.

• Родственность процессоров

  На многопроцессорном (или многоядерном) компьютере процессы распределяются между доступными процессорами (ядрами). Если число процессов превышает число процессоров (т.н. «нормальный сценарий»), то тот или иной процесс может быть назначен для исполнения на любом процессоре, не обязательно на том, на котором этот процесс работал прежде. Когда происходит подобная ситуация, необходимо т.н. «переключение контекста процессора». Другими словами, прежде чем данный процесс сможет работать на новом процессоре, необходимо перезагрузить регистры, процессорную кэш-память и другие элементы состояния этого процессора. Это приводит к дополнительным накладным расходам, которые способны свести на нет все выгоды от исполнения данного процесса на первом доступном процессоре. Особенно в тех случаях, когда IDS исполняется на выделенном компьютере, его собственные процессы могут планироваться для циклического исполнения на различных процессорах. Это обуславливает наличие непроизводительных издержек на контекстное переключение процессора для каждого процесса IDS.

  С целью избежания этих непроизводительных издержек среда Linux позволяет «прикрепить» определенный процесс к определенному процессору. В этом случае готовый к исполнению процесс будет ждать доступности своего собственного процессора, а не будет перемещен на другой процессор, который в текущий момент времени может оказаться свободным. Этот механизм получил название «родственность процессоров» (processor affinity). Поддержка этого механизма в IDS активируется с помощью параметра VPCLASS файла onconfig.

Сценарии тестирования

С использованием описанной конфигурации VM была проведена серия тестов, позволяющих убедиться в том, что вышеупомянутые ОС-специфические функции IDS работают надлежащим образом. Для практического выполнения указанных тестов была использована внутренняя тестовая утилита IBM под названием IDStest. Эта утилита принимает конкретные предварительные установки, задаваемые пользователем для конфигурирования и запуска экземпляра IDS. Затем эта утилита исполняет несколько базовых сценариев тестирования, включая небольшой сценарий со стандартным тестом TPC-C. Следует отметить, что эта утилита используется не для измерения реальной производительности, а скорее в качестве удобного механизма для генерации набора SQL-операторов, выполняемых посредством нескольких параллельных пользовательских сеансов. Это т.н. базовые сценарии, призванные охватить элементарные функциональные возможности и обеспечить автоматизированный анализ результатов тестирования. По указанной причине более сложные сценарии с использованием определяемых пользователем типов или определяемых пользователем процедур не выполнялись. Тем не менее это тестирование позволяет судить о корректности работы ОС-специфических функций IDS.

Для охвата различных ОС-специфических функций утилита IDStest исполнялась несколько раз со следующими предварительными установками:

• Нормальная конфигурация:
  чанки IDS в файловой системе (cooked-файлы) и на raw-устройствах с использованием KAIO

• IDS с непосредственным вводом/выводом:
  чанки IDS в файловой системе и на raw-устройствах
  Предустановки для конфигурации IDS:

  • параметр DIRECT_IO файла onconfig включает (1) или отключает (0) непосредственный ввод/вывод для чанков.
    DIRECT_IO 1

• IDS без старения:
  чанки IDS в файловой системе и на raw-устройствах
  Предустановки для конфигурации IDS:

  • параметр VPCLASS cpu cpu файла onconfig конфигурирует виртуальные процессы.
    VPCLASS cpu,num=<#>[,max=<#>][,aff=<#>],noage

• IDS с родственностью процессоров:
  чанки IDS в файловой системе и на raw-устройствах
  В этом сценарии тестирования конфигурация VM имела два центральных процессора. (Тестирование родственности процессоров при доступности для VM только одного процессора не имеет большого смысла).

  При тестировании родственности процессоров использовалась несколько более сложная конфигурация. Важные параметры настройки:

  • Измененная конфигурация VM имела два процессора.
    Нумерацию этих процессоров можно увидеть с помощью параметра cpuinfo:cat /proc/cpuinfo.

  • Предустановки для конфигурации IDS:

    • MULTIPROCESSOR 1
    • SINGLE_CPU_VP 0
    • VPCLASS cpu,num=2[,max=<#>],aff=0-1[,noage]

Результаты тестирования

Результаты тестирования подтвердили, что все ОС-специфические функции IDS корректно работают в виртуальной машине под управлением гипервизора Xen. В процессе тестирования не было выявлено каких-либо проблем. Проверенные функциональные возможности IDS могут без ограничений использоваться в виртуальной машине под управлением гипервизора Xen.

Несколько слов о производительности

Как указывалось выше, цель данного тестирования состояла в проверке функциональных возможностей, а не в измерении или подтверждении производительности (как относительной, так и абсолютной). Для получения значимых выводов о производительности необходимо серьезно заниматься ее измерением. Это не являлось целью данного тестирования. Кроме того, потребовалась бы иная аппаратная конфигурация с гораздо большим количеством ресурсов (процессоры, память, дисковое пространство, сетевые ресурсы и т.д.). Наличие дополнительных ресурсов позволило бы переносить вычислительную нагрузку приложения (например, пакета TPC-x) на одну из нескольких клиентских машин. Более масштабный экземпляр IDS мог бы исполняться в виртуальной машине, использующей большее число процессоров и больше памяти, или несколько экземпляров IDS могли бы исполняться в различных виртуальных машинах, каждая из которых использовала бы свою выделенную долю ресурсов. Это было бы реалистичным сценарием использования виртуализации для нескольких экземпляров IDS. Поэтому подобное тестирование производительности запланировано для будущего проекта.

Тем не менее в качестве «побочного продукта» при проведении вышеописанного функционального тестирования можно отметить, что временные характеристики при исполнении IDS в VM и в Dom0 различаются весьма незначительно. С учетом небольшого числа выполненных тестов выявить реальную тенденцию не представляется возможным. Наблюдаемые различия находятся в пределах статистической погрешности результатов. По крайней мере полученные результаты не опровергли утверждения о том, что гипервизор Xen обеспечивает виртуальным машинам почти нативную производительность.

Гипервизор Xen в среде Linux – это передовая технология управления виртуальными машинами на основе метода паравиртуализации. Поскольку это технология с открытым исходным кодом, Xen является менее дорогой системой по сравнению с другими подобными системами. Таким образом, можно ожидать, что низкие расходы на гипервизор Xen приведут в среднесрочной перспективе к росту популярности этого продукта и к созданию значительной пользовательской базы.

ОС-специфические функциональные возможности Informix Dynamic Server для Linux действуют в виртуальной машине под управлением гипервизора Xen без каких-либо ограничений. Выполненные тесты не выявили каких-либо проблем или трудностей. Как показано в данной статье, гипервизор Xen для Linux – это весьма эффективная опция для сред с виртуальными машинами, на которых исполняются экземпляры IDS. Возможные сценарии применения: консолидация аппаратных ресурсов, сложные среды тестирования, нуждающиеся в нескольких экземплярах ОС Linux, выделенные виртуальные машины для хостинговых услуг и т.д.

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

Об авторах

		Николь Нойбюргер (Nicole Neubuerger) является студенткой Мюнхенского университета прикладных наук (Германия). Она изучает информационные системы и в качестве практического применения своих знаний провела исследование и тестирование, результаты которого легли в основу этой статьи.

		Мартин Фюрдерер (Martin Fuerderer) - разработчик программного обеспечения, работает с продуктом IBM Informix Database Server на протяжении последних девяти лет. Он был руководителем Н. Нойбюргер при выполнении проекта, описанного в данной статье.