УДК 004.45

Аннотация

Власенко А.П., Самощенко А.В. Модульная реализация веб-ресурсов. Рассмотрены варианты организации веб-ресурсов. Предложен вариант реализации модульной виртуализированной системы, основанный на использовании свободного ресурса Xen, с указанием ее преимуществ и недостатков.

Постановка задачи

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

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

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

Целью работы является разработка концепции построения компьютерной системы, реализация которой основана на модульной структуре с учетом особенностей ее использования в учебных заведениях.

Основные методы реализации

При реализации хостинга нескольких ресурсов в настоящее время существуют следующие подходы:

1. Выделение каждому ресурсу по физической машине.

2. Выделение каждому ресурсу по виртуальному хосту одного веб-сервера.

3. Смешанный подход.

4. Выделение каждому хосту по собственной OpenVZ машине.

5. Выделение каждому хосту полноценной виртуальной машины.

Методы под номерами 1, 4, 5 предоставляют, фактически, услугу «выделенный сервер», то есть при необходимости пользователям может быть предоставлен полный или частичный контроль над машиной.

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

Второй подход имеет достоинства, аналогичные четвертому и пятому, но абсолютно лишает возможности пользователям использовать машину для каких-либо других нужд (установка модулей для Python потребует вмешательства администрации). Практически, можно удовлетворить требования всех желающих и предоставлять нужное программное обеспечение и порты, однако, каждое новое программное обеспечение компрометирует безопасность всей системы, сайтов, ресурсов, а любая уязвимость сайта может быть использована для манипуляции над всей системой [1].

Третий подход имеет преимущества и недостатки первого и второго метода.

Современным вариантом является OpenVZ, т.е. Linux-система виртуализации, которая реализует машины при помощи одного ядра. Преимуществом OpenVZ, по сравнению с более универсальными инструментами виртуализации, такими как Xen и KVM, является прозрачный доступ из внешней системы к процессам, файлам и прочим ресурсам [2].

Такая система производительна и универсальна и она рассматривалась, например, как метод реализации новой компьютерной инфраструктуры факультета КНТ в 2010 году. Но тогда же была найдена новая свободная система — Xen, которая постепенно вытесняет OpenVZ с рынка VS-услуг [3]. Xen предоставляет полное разделение виртуальных систем друг от друга, каждая система может использовать собственное ядро (в том числе OS Windows, при крайней необходимости), модули — все как на физической машине, но без излишнего энергопотребления и затрат. Наоборот, применение нескольких машин на одной физической позволит рациональнее использовать серверные ресурсы, т. к. большинство сайтов кафедр не имеют нагрузок, достаточных для загрузки более чем на 10% даже устаревшей аппаратной системы.

Разработка системы на примере факультета КНТ

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

Создание системы виртуальных машин начало реализацию модульной виртуализированной системы. Начало обустройства пришлось на наиболее легкой в интеграции области — хостинге веб-ресурсов факультета.

Аппаратная платформа была предоставлена факультетом — серверная платформа HP Proliant с комплексной системой вентиляции и поддержкой до двух процессоров на плате.

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

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

Для базовой системы выбрана ОС Debian, которая известна своей стабильностью и популярностью в различных вузах и научных проектах [4].

В качестве базовой системы для виртуальных машин используется Xen, которая устанавливается на базовую систему из стандартного репозитория и оттуда же получает регулярные обновления безопасности до тех пор, пока дистрибутив поддерживается (в случае с текущей версией Debian Stable — как минимум до 2014 года). После этого система переводится в новую стабильную ветку.

Для удобного и быстрого создания виртуальных машин в Debian и Xen есть соответствующие утилиты, которые в традиционном UNIX стиле кооперируют друг с другом. В первую очередь стоит отметить утилиту Debootstrap.

В Debian ее установка осуществляется через репозиторий:

aptitude install debootstrap

Эта утилита позволяет создавать образы операционных систем Debian и Ubuntu, скачивая весь необходимый набор данных с серверов обновлений и извлекая их в целевую папку.

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

Ниже представлен набор команд, по которому можно проанализировать этапы работы. Это стандартные Linux-утилиты, подробная информация о параметрах которых доступна в системном справочнике man.

Создание образов:

dd if=/dev/zero of=/xen/domains/name/disk.img bs=1k seek=30G count=1

Создание файла подкачки:

dd if=/dev/zero of=/xen/domains/name/swap.img bs=1k seek=1G count=1

Разметка файлов, создание файловой системы:

mkswap /xen/domains/name/swap.img

mkfs.ext4 /xen/domains/name/disk.img

Образы подготовлены, можно загрузить в них виртуальную машину.

Создается директория для монтирования:

mkdir /xen/domains/name/mount

Монтирование образов:

mount -o loop /xen/domains/name/disk.img /xen/domains/name/mount

Скачивание и установка дистрибутива в директорию.

debootstrap --arch amd64 {distro-name} /xen/domains/name/mount {repository-name}

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

Для распознавания файла системой Xen необходим конфигурационный файл, для примера ниже представлен конфигурационный файл, сгенерированный для машины кафедры компьютерной инженерии:

# Configuration file for the Xen instance ki, created

# by xen-tools 4.2 on Wed Feb 29 12:18:01 2012.

# Kernel + memory size

bootloader = '/usr/lib/xen-default/bin/pygrub'

vcpus = '1'

memory = '512'

# Disk device(s).

root = '/dev/xvda2 ro'

disk = [

'file:/xen/domains/ki/disk.img,xvda2,w',

'file:/xen/domains/ki/swap.img,xvda1,w',

]

# Hostname

name = 'ki'

# Networking

vif = [ 'ip=10.0.0.16,mac=XX:XX:XX:XX:XX:XX' ]

# Behaviour

on_poweroff = 'destroy'

on_reboot = 'restart'

on_crash = 'restart'

В результате (рис. 1), система готова к запуску и наполнению — пользователь может выбрать, представить систему для веб-ресурсов или для каких-либо иных задач. Дальнейшие действия выполняются всего лишь один раз — базовую систему можно и нужно клонировать, после того, как ей будет предоставлен весь функционал.

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

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

Выводы

Получена легко масштабируемая модульная компьютерная система, использующая последние наработки в области виртуализации, и предоставляющая практически максимальную отдачу по производительности. Например, компьютерная система факультета КНТ представляет собой набор из виртуальных машин для кафедр, конференции, одна машина является обратным прокси-сервером, который распределяет запросы и кеширует ответы. Итого — более 10 виртуальных машин, представленных в одной физической.

Литература

1. Ищем и лечим web shell на взломанном сайте / Интернет-ресурс. - Режим доступа : www/ URL: http://wiki.linux.ru/wiki/index.php/ищем_и_лечим_web_shell_на_взломанном_сайте

2. Евсеев И. Система виртуализации OpenVZ [IBM developerWorks Россия] / Интернет-ресурс. - Режим доступа : www/ URL: http://www.ibm.com/developerworks/ru/library/l-openvz_1/index.html

3. OpenHosting - XEN vps против OpenVZ / Интернет-ресурс. - Режим доступа : www/ URL: http://openhosting.ru/vps/xen-vs-openvz.jsp

4. Debian Project - Who's using Debian? / Интернет-ресурс. - Режим доступа : www/ URL: http://www.debian.org/users/