Создание центра обработки данных

BIND - кроссплатформенный DNS сервис, работает под управлением операционных систем UNIX/Linux/windows.

Для работы всех перечисленных сервисов кроме службы каталогов надо выбрать операционную систему с открытым исходным кодом из семейства Linux/Unix.

Для этого подойдет 64-х разрядная операционная система Linux CentOS (актуальная версия 5.6). CentOS (Community ENTerprise Operating System) - дистрибутив Linux, основанный на коммерческом Red Hat Enterprise Linux компании Red Hat и совместимый с ним. Эта ОС - надежное и проверенное решение корпоративного уровня, успех и надежность которой во многом объясняются использованием ОС исходных кодов Red Hat Enterprise Linux.

CentOS способна работать со всеми необходимыми сетевыми сервисами.

4.1.7 Сервис для создания резервных копий

В комплекте с сетевым хранилищем Thecus N12000 идет 5 лицензий на продукт "Acronis Backup and Recovery Server OEM". Acronis Backup and Recovery - пакет программ для полного резервного копирования, позволяющий создавать точные образы жесткого диска и/или отдельных его разделов, а так же директорий и файлов. Образ раздела, включающий абсолютно все хранящиеся на нем данные, приложения и операционные системы, может быть восстановлен в случае сбоя старого диска и любых других фатальных ошибок программного и аппаратного обеспечения.

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

В ЦОД резервное копирование будет производиться для нескольких типов данных:

- Разделы серверных операционных систем (ОС гипервизоров и шлюза)

- Файлы (и/или разделы) виртуальных машин

- Информационные базы предприятия

Для резервного копирования каждого типа данных будет использована распространенная трехуровневая схема "дед-отец-сын".

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

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

-Инкрементная копия создается каждый день. В инкрементной резервной копии хранятся изменения данных по отношению к последнему

резервному копированию (в данном случае по отношению к последней дифференциальной копии). Хранится до создания следующей дифференциальной резервной копии. Инкрементная копия создается очень быстро (обычно несколько минут).

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

Все созданные резервные копии будут храниться в надежном RAID-6 массиве NAS хранилища Thecus 8800PRO. Хранилище будет сконфигурировано для предоставления доступа к собственному файловому пространству через протокол FTP (загрузочный клиент Acronis может работать с FTP-сервером). Хранилище будет расположено удаленно от основной инфраструктуры ЦОД, это минимизирует риски потери информации в случаях локального бедствия (пожар, разрушение здания, и.т.п.).

Для защиты допускается шифрование каждой резервной копии AES шифром с ключем 256 бит. Дополнительное шифрование всего дискового массива поддерживаться самим хранилищем данных Thecus 8800PRO.

Операции резервного копирования следует производить в период минимальной загрузки серверного оборудования (определяется эмпирически, обычно период минимальной загрузки - ночь).

4.2 Программное обеспечение для подсистемы доступа к внешним сетям

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

Функционально подсистема доступа к внешним сетям будет являться шлюзом в интернет с функциями сетевого экрана (брэндмауэра).

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

На эту роль наиболее подходит программная реализация данной подсистемы. С открытым исходным кодом данный сервис представлен мощным и надежным сетевым экраном Netfilter и утилитами управления "iptables" для ОС семейства UNIX. Поддержка других необходимых сетевых протоколов для доступа к сети и маршрутизации так же в полной мере реализована в ОС Linux/Unix.

Netfilter - это мощный межсетевой экран (фаервол или брэндмауэр), встроен в ядро Linux версий 2.4 и 2.6. iptables - название пользовательской утилиты (запускаемой из командной строки) предназначенной для управления системой netfilter. С её помощью создаются и изменяют правила, управляющие фильтрацией и перенаправлением пакетов. Для работы с семейством протоколов IPv6 существует отдельная версия утилиты iptables - ip6tables. Иногда весь проект (внутриядерный межсетевой экран вместе с пользовательской утилитой) просто именуется netfilter/iptables.

Схема применения правил цепочек показана на рисунке 6.1:

Рисунок 6.1

Функционирование фаерволла определяется набором правил, каждое из которых состоит из критерия и действия, применяемого к пакетам, подпадающим под этот критерий. Для организации правил применяется концепция цепочек - независимых списков правил. Отдельные цепочки применяются для фильтрации входящих (INPUT), исходящих (OUTPUT) и транзитных (FORWARD) пакетов. В продолжении этой идеи, в iptables появились таблицы - независимые группы цепочек. Каждая таблица решает свою задачу - цепочки таблицы filter отвечали за фильтрацию, цепочки таблицы nat - за преобразование сетевых адресов (NAT), к задачам таблицы mangle относились прочие модификации заголовков пакетов (например, изменение TTL).

Такая схема позволяет эффективно применять правила межсетевого экрана на различных уровнях фильтрации пакета.

Согласно требованиям ТЗ доступ в сеть должен предоставляться любому сегменту сети с сокрытием внутренней структуры сети предприятия. Для сокрытия внутренней структуры используется технология NAT (Network Address Translation - «преобразование сетевых адресов») - это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов.

Для трансляции сетевых адресов (NAT) в iptbles/netfilter реализованы специальные цепочки правил SNAT (для статических IP) и MASQUERADE (для динамических IP, требует бОльших вычислительных ресурсов).

Для доступа к внутренним сетевым сервисам (FTP, HTTP-сервер, SSH и VNC службы терминалов) из внешних сетей надо пробросить пакеты с внешних портов шлюза на внутренние порты серверов в сети ЦОД. Для этого в iptables/netfilter предусмотрены цепочки правил c механизмами DNAT (destination network address translation).

Функции маршрутизации в операционных системах Linux/Unix реализованы на уровне ядра. Необходимые функции агрегации каналов в ОС Linux можно осуществить с помощью утилит "ifenslave Control Utility". Объединить интерфейсы в мост можно утилитой "brctl". Управление сетевыми интерфейсами и маршрутизацией осуществляется при помощи утилит "ifconfig" и "route". Управление vlan осуществляется при помощи утилиты "vconfig".

В соответствии с техническим заданием надо поместить ПО шлюза и брэндмауэра на изолированном физическом хосте. Чтобы изолировать эту подсистему от локальной сети ЦОД на сетевом уровне можно поместить ее в отдельной подсети, разделив узлом маршрутизации от пространства остальной сети.

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

Для внешней сети, эти требования можно выполнить, добавив и сконфигурировав дополнительный физический сетевой интерфейс и добавив скрипты проверки состояния канала связи (например, используя ICMP протокол для проверки состояния шлюза провайдера). Сетевые интерфейсы должны иметь различные каналы подключений. Это означает, что для подключения к внешним сетям следует использовать подключения двух различных провайдеров.

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

Перечисленное программное обеспечение, необходимое для организации подсистемы доступа к внешним сетям, существует с открытым исходным кодом и доступно в операционных системах Linux.

Для этого подойдет 64-х разрядная операционная система Linux CentOS (актуальная версия 5.6). ОС CentOS способна полностью реализовать функционал подсистемы доступа к внешним сетям (утилиты и модули отсутствующие в базовом дистрибутиве возможно загрузить с внешних репозиториев CentOS).

4.3 Программная среда для реализации системы виртуализации

В соответствии с требованием технического задания, сервисное программное обеспечение должно быть с открытым исходным кодом. Монитор виртуальных машин должен быть надежным и производительным и обеспечивать работу необходимых сетевых сервисов ЦОД.

На сегодняшний день существует множество решений полной виртуализации, среди которых VirtualBox, VMware, Parallels Workstation, Qemu, OpenVZ,VDSmanager, Microsoft Hyper-V, XEN,Kernel-based Virtual Machine.

Количество систем полной виртуализации промышленного уровня, с открытым исходным кодом относительно невелико, это OpenVZ, KVM (Kernel-based Virtual Machine) и XEN. Краткое сравнение систем виртуализации отображено в таблице 6.1.

Таблица 6.1

Название	Создатель	Процессор хост-машины	ОС хост-машины	Официально поддерживаемые гостевые ОС	Типичное применение	Скорость работы гостевой ОС в сравнении с ОС хоста
Xen	Кембриджский университет, Intel, AMD	Intel x86, AMD64, ((ведётся портирование на PowerPC и IA-64))	NetBSD, Linux	Linux, NetBSD, FreeBSD, OpenBSD, Windows XP & 2003 Server (требует версию не ниже 3.0 и процессор поддерживающий технологию Vanderpool или Pacifica),Plan 9	консолидация серверов, хостинг, разделение сервисов, безопасность, изоляция	Почти без потерь
KVM	Red Hat	Процессор Intel/AMD с поддержкой аппаратной виртуализации	Linux	Linux, HURD, Windows, xBSD, Darwin, QNX, MINIX, Haiku, Amiga Research OS, ReactOS, Plan 9, MS DOS, Free DOS, Solaris	?	Близка к производительности хост-системы
OpenVZ	Проект сообщества, поддерживаемый Parallels, Inc.	Intel x86, AMD64, IA-64	Linux	Различные дистрибутивы Linux	Изоляция виртуализированных серверов, хостинг.	Почти без потерь

OpenVZ - это реализация технологии виртуализации на уровне операционной системы, которая базируется на ядре Linux. OpenVZ позволяет на одном физическом сервере запускать множество изолированных копий операционной системы, называемых Виртуальные Частные Серверы (Virtual Private Servers, VPS) или Виртуальные Среды (Virtual Environments, VE).

Поскольку OpenVZ базируется на ядре Linux, в отличие от виртуальных машин (напр. VMware) или паравиртуализационных технологий (напр. Xen), в роли «гостевых» систем могут выступать только дистрибутивы Linux.

Виртуализация на уровне операционной системы в OpenVZ даёт лучшую производительность, масштабируемость, плотность размещения, динамическое управление ресурсами, а также лёгкость в администрировании, чем у альтернативных решений (http://www.hpl.hp.com/techreports/2007/HPL-2007-59R1.pdf). Согласно сайту OpenVZ, накладные расходы на виртуализацию очень малы, и падение производительности составляет всего 1-3 %, по сравнению с обычными Linux-системами. OpenVZ является базовой платформой для Virtuozzo - проприетарного продукта Parallels, Inc. OpenVZ распространяется на условиях лиценции GNU GPL v.2.

KVM (Kernel-based Virtual Machine) - это программное решение, обеспечивающее виртуализацию в среде Linux на платформе x86, которая поддерживает аппаратную виртуализацию на базе Intel VT (Virtualization Technology) либо AMD SVM (Secure Virtual Machine). Программное обеспечение KVM состоит из загружаемого модуля ядра (называемого kvm.ko), предоставляющего базовый сервис виртуализации, процессорно-специфического загружаемого модуля kvm-amd.ko либо kvm-intel.ko, и компонентов пользовательского режима (модифицированного QEMU). Компонент ядра, необходимый для работы KVM, включен в основную ветку Linux начиная с версии 2.6.20 (February 2007). KVM был также портирован на FreeBSD как модуль ядра. KVM требует наличия x86-совместимого процессора с поддержкой одной из технологий аппаратной виртуализации - Intel VT либо AMD SVM. На данный момент KVM в состоянии запускать в качестве гостевых ОС GNU/Linux (32-битные и 64-битные), Windows (32-битные и 64-битные) и другие системы.

Xen - кросс-платформенный гипервизор, разработанный в компьютерной лаборатории Кембриджского университета и распространяемый на условиях лицензии GPL. Основные особенности: поддержка режима паравиртуализации помимо аппаратной виртуализации, минимальность кода самого гипервизора за счёт выноса максимального количества компонент за пределы гипервизора. Xen обладает функциональностью ПО корпоративного уровня; в нём, в частности, обеспечивается:

- Производительность виртуальных машин близкая к производительности при непосредственном исполнении на железе;

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

- Поддержка до 32 виртуальных процессоров на одну гостевую машину с возможностью горячего добавления (hotplug) процессоров;

- Поддержка платформ x86/32, x86/32 с PAE, x86/64, IA64, а также частичная поддержка платформ ARM и PPC;

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

- Поддержка аппаратной виртуализации для запуска немодифицированных операционных систем (включая Microsoft Windows, Linux, Unix, OS/2, Novell Netware и многие другие ОС);

- Отличная поддержка оборудования (поддерживаются практически все драйверы устройств Linux).

Исходя из описания виртуальных машин, можно исключить использование OpenVZ, потому как данная система виртуализации не поддерживает другие операционные системы, кроме Linux (в проектируемом ЦОД ОС Microsoft Windows используется для сервисов AD DS).

KVM на данный момент - относительно молодая система виртуализации, в сравнении с XEN она имеет гораздо меньший опыт внедрения в промышленные информационные системы. XEN на данный момент обладает большей гибкостью конфигурирования, настройки и организации виртуальной среды.

В отличие от KVM, XEN поддерживает технологию живой миграции, что на данном этапе развития недоступно для KVM. Применение технологии миграции гостевых ОС увеличит доступность сетевых сервисов ЦОД. Требование к доступности сервисов оговорено техническим заданием удовлетворяется возможностями XEN: в случае отказа одной из гостевых систем будет возможность возобновления работы предоставляемых им сервисов на другом мониторе виртуальных машин XEN.

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

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

Два основных типа доменов, это dom0 и domU:

dom0 - первый запущенный Xen домен, обычно он автоматически создаётся и загружается сразу после загрузки и инициализации гипервизора. Этот домен имеет особые права на управление гипервизором и по-умолчанию всё аппаратное обеспечение компьютера доступно из dom0. Фактически, dom0 - это место жизни управляющего ПО. dom0 всегда один.

domU - рядовой домен (сокращение от User domain), содержащий в себе домен выполняющихся виртуальных машин. Обычно не имеет доступа к реальному оборудованию и является «полезной нагрузкой» системы виртуализации. В отличие от dom0, domU может быть множество.

Несомненным плюсом XEN является поддержка технологии паравиртуализации, которая обеспечивает очень большую скорость работы гостевых UNIX-подобных операционных систем. Для проектируемого центра обработки данных подобная технология является очень актуальной ввиду большого количества сервисов, работающих на UNIX-подобных ОС.

До установки гипервизора XEN важно иметь ввиду возможности работы гипервизора с 32-х и 64-х разрядными ОС:

-32-х разрядный гипервизор XEN поддерживает работу только 32-х разрядных гостевых доменов.

- 64-х разрядный гипервизор поддерживает работу 32-х разрядных гостевых доменов без PAE (Physical Address Extension) и 64-х разрядных доменов без ограничений.

Для сервисов проектируемого центра обработки данных нужно применить 64-х разрядную версию XEN.

XEN загружается до ядра операционной системы, ввиде собственного образа ядра, которое после собственной инициализации управляет загрузкой ядра и модулей операционной системы. XEN в качестве гипервизора может работать на ОС Linux, OpenSolaris, BSD. Наибольшую практику внедрения имеет связка XEN&Linux.

Для работы XEN в сегменте виртуализации проектируемого ЦОД полностью подходит 64-разрядный дистрибутив операционной системы Linux CentOS (Community ENTerprise Operating System) - дистрибутив, основанный на открытых исходных кодах Red Hat Enterprise Linux и совместимый с ним. CentOS может быть сконфигурирован как гипервизор XEN на этапе установки операционной системы.



4.4 Программная защита

Система обеспечения информационной безопасности при создании и развитии ЦОД, включает в себя ряд подсистем, обеспечивающих многоуровневую эшелонированную защиту наиболее важных внутренних ресурсов дата-центра, таких, как прикладные системы, системы управления базами данных, веб-серверы и пр. Такая защита охватывает следующие области:

1. Межсетевое экранирование;

Подсистема межсетевого экранирования предназначена для предотвращения атак на сетевом уровне ЦОД. Она обеспечивает надежную защиту как сетевого периметра, так и сетей управления.

Подсистема межсетевого экранирования реализует следующие функции:

a) сегментация сети передачи данных;

b) контроль доступа на сетевом уровне;

c) регистрация событий информационной безопасности на сетевом уровне.

2. Обнаружение и предотвращение вторжений;

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

3. Защита веб-серверов и серверов СУБД;

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

Подсистема защиты веб-приложений и СУБД обеспечивает следующие функции:

a) аудит доступа к данным различных типов пользователей;

b) блокировка при атаках на базу данных или при аномальных запросах к базе данных в реальном времени;

c) обнаружение и исправление уязвимостей базы данных;

d) идентификация превышенных и редко используемых прав доступа пользователей к данным.

4. Защита среды виртуализации и виртуальных машин;

Подсистема защиты виртуализации предназначена для обеспечения безопасности систем виртуализации (гипервизоров) и виртуальных машин.

Компоненты в составе подсистемы защиты среды виртуализации выполняют следующие функции:

a) мандатное управление доступом;

b) усиленная аутентификация;

c) разделение ролей и делегирование полномочий;

d) управление конфигурацией системы безопасности и контроль изменений настроек безопасности;

e) защита от утечек через специфические каналы среды виртуализации;

f) межсетевое экранирование виртуальных машин;

g) обнаружение и предотвращение вторжений;

h) контроль целостности файловой системы и реестра;

i) защита от вредоносных программ, в том числе без использования антивирусного агента.

5. Криптографическая защита каналов связи;

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

Для защиты трафика применяются сертифицированные средства криптографической защиты информации, которые позволяют организовать удаленный доступ пользователей к ресурсам ЦОД, используя как стандартный стек протоколов организации VPN (в частности, IPSec), так и инкапсуляцию VPN-трафика в более высокоуровневые протоколы (SSL-VPN).

6. Защита от атак типа DoS и DDoS;

Подсистема защиты от DoS и DDoS предназначена для защиты от атак типа «отказ в обслуживании» за счет применения средств защиты, направленных на исчерпание емкости каналов и аппаратных ресурсов серверов.

Подсистема защиты от DoS и DDoS предназначена для решения следующих задач:

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

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

c) уведомление операторов о нештатных ситуациях с предоставлением подробной информации о характере аномалии;

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

7. Обнаружение уязвимостей;

Подсистема обнаружения уязвимостей предназначена для выявления уязвимостей критически важных систем и сервисов ЦОД путем их сканирования. Данная подсистема обеспечивает своевременное оповещение об обнаруженных уязвимостях, а также предоставляет расширенные описания и инструкции для их устранения.

8. Подсистема управления инцидентами.

Подсистема управления инцидентами информационной безопасности предназначена для решения следующих задач:

a) сбор и обработка необходимой информации, поступающей из различных источников событий информационной безопасности;

b) выявление инцидентов информационной безопасности на основе анализа поступивших событий;

c) долгосрочное хранение информации об инцидентах для обеспечения возможности проведения исторического анализа (расследования инцидентов);

d) проверка корпоративных систем на соответствие требованиям стандартов и политик безопасности;

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



5. Реализация безопасной виртуальной инфраструктуры

Все сетевые сервисы, за исключением подсистемы доступа к внешним сетям будут располагаться в виртуальном пространстве XEN. Надо спланировать размещение сетевых сервисов в виртуальном пространстве и распределить между ними аппаратные ресурсы. Для взаимодействия между гостевыми доменами в пределах одного гипервизора, между гипервизорами, а так же работы гостевых доменов с другими сегментами сети надо выбрать модель сетевого взаимодействия в этих средах. Согласно ТЗ надо предусмотреть возможность возобновления работы сетевых сервисов в случае выхода из строя одного из серверов на физическом или программном уровне. Условно можно разбить планирование виртуальной среды на следующие подзадачи:

-Размещение сетевых сервисов в виртуальном пространстве.

-Распределение аппаратных ресурсов между гостевыми доменами.

-Модель сетевого взаимодействия гостевых доменов в пределах гипервизора.

-Сетевое взаимодействие гипервизоров.

-Планирование взаимодействия гостевых доменов между гипервизорами, а так же с остальными сегментами сети.

-Обеспечение возобновления работы сетевых сервисов при аппаратных и программных сбоях системы.

5.1 Размещение сетевых сервисов в виртуальном пространстве

Основным требованием к размещению сетевых сервисов в виртуальном пространстве будет определение, в каком режиме виртуализации будет работать ОС виртуализируемого сервиса. XEN поддерживает два режима виртуализации: паравитруализация и аппаратная виртуализация.

Паравиртуализация (PV) - адаптация ядра исполняемой ОС для работы совместно с Xen. Позволяет достичь очень высокой производительности за счёт отсутствия эмуляции "настоящего железа", простоты интерфейсов и учёта существования гипервизора при выполнении системных вызовов в коде ядра. Выполнение привилегированных операций запрещено, вместо них совершаются гипервызовы (hypercalls) - обращения ядра гостевой ОС к гипервизору с просьбой о выполнении тех или иных операций. В большинстве случаев изменения при портировании ОС под Xen затрагивают только ядро ОС, хотя могут предполагать и незначительные изменения в системных библиотеках (например, в библиотеке "libc").

Процесс адаптации сводиться к изменению ядра и встроенных драйверов операционной системы. Драйвера в Xen состоят из двух частей - одна исполняется вне виртуальной машины, вторая находится внутри неё. Часть драйвера в гостевой системе крайне примитивна и служит лишь транслятором запросов во вторую часть. В PV-режиме не поддерживаются «вложенные» режимы работы процессора, например, real-86, virtual-86, переключение между 32-битным и 64-битным режимом, поддержка эмуляции аппаратной виртуализации.

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

В режиме аппаратной виртуализации (HVM) гостевая ОС "не знает" про существование гипервизора. С помощью модулей QEMU (QEMU - свободная программа с открытым исходным кодом для эмуляции аппаратного обеспечения различных платформ) XEN эмулирует реальное аппаратное обеспечение и позволяет провести начальную загрузку ОС. По её окончании для повышения производительности можно использовать PV-драйвера, которые реализуют быстрый интерфейс с виртуальными устройствами, подобно тому, как это работает в PV-режиме.

Схема работы XEN с гостевыми доменами, показана на рисунке 7.1:

Рисунок 7.1 "Модель работы гипервизора XEN"

В настоящее время в паравиртуальном режиме работают следующие

операционные системы: Linux, NetBSD, OpenSolaris, FreeBSD (начиная с версии 7, без поддержки PAE и с большим количеством ограничений), OpenBSD (без PAE) и Plan9 (без PAE).

Таким образом, для виртуализации операционных систем windows 2008 r2 (на которых размещены сервисы службы каталогов) должен использоваться режим аппаратной виртуализации.

Режим паравиртуализации будет использован для всех сервисов, работающих под ОС Linux.



5.2 Распределение аппаратных ресурсов между гостевыми доменами

За счет минимизации кода XEN, сам гипервизор для работы требует незначительное количество аппаратных ресурсов компьютера. Установленная связка Linux+XEN без подгрузки оконной системы X-window потребляет около 128 MB оперативной памяти, загрузка процессора порядка 1%. С дополнительной сервисной нагрузкой гипервизор может требовать 256 Mb ОЗУ. После установки гипервизора желательно отключение демонов, работа которых не требуется.

Основное распределение ресурсов требуется для распределения между гостевыми доменами. При распределении следует учитывать требование технического задания о доступности сервисов в случае аппаратных либо программных сбоев. Это означает, что в случае выхода из строя одного физического сервера, все виртуальные сервисы должны быть распределены на прочие гипервизоры и системных ресурсов этих гипервизоров должно хватить для обеспечения стабильной работы сервисов.

Все управление гостевыми доменами, а так же самим гипервизором осуществляется из специального управляющего домена "Dom0".

XEN может манипулировать различными аппаратными ресурсами, для передачи этих ресурсов гостевым доменам: количеством ядер CPU, процессорным временем каждого ядра, объемом ОЗУ, PCI, USB, SCSI и прочими ресурсами. Дисковое пространство для использования гостевыми доменами может распределятся, как на уровне файлов, так и на уровне блочных устройств (либо разделов LVM).

Для распределения ресурсов следует посчитать требования к системным ресурсам всех сервисов. Так как в каждом из серверов сегмента виртуализации установлено два мощных шестиядерных CPU Intel Xeon X5660 2.8 ГГц (итого 12 ядер), процессорных ресурсов одного сервера хватит, чтобы с запасом удовлетворить рекомендуемые требования всех сервисов ЦОД.

Основное требование при распределении памяти - суммарный объём текущей оперативной памяти всех доменов не должен превышать объём оперативной памяти физической системы, на которой домены исполняются.

По умолчанию, домен 0 (то есть сам гипервизор) получает весь доступный объём оперативной памяти.

Для каждого домена можно выделять требуемое и максимальное количество ОЗУ. Максимум будет выделяться динамически, по требованию самих гостевых доменов.

Оценочные требования к оперативной памяти следующие (реальные требования сильно зависят от нагрузки на сервисы и определяются эмпирически в процессе работы):

Windows Server 2008 r2 требует (официально) 4GB ОЗУ. С учетом нагрузки можно добавить еще 2GB, итого 12GB для обоих контроллеров.

DHCP, DNS, FTP, SAMBA, NFS - это сервисы очень экономичные в плане системных ресурсов. Каждому из сервисов этих с даже учетом сильной нагрузки достаточно 1 GB ОЗУ, итого 5GB на все эти сервисы.

Загрузка HTTP-сервера Apache обычно зависит от количества посещений сайта. Сайт средней величины требует приблизительно 200 MB на 100 подключений. Определим для Apache 4GB оперативной памяти.

Загрузка терминальных сервисов тоже зависит от количества подключенных пользователей. SSH крайне экономичен в плане системных ресурсов, VNC несколько более требователен. С запасом определим для терминальных сервисов 4GB ОЗУ.

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

Итого, для работы всех сервисов (приблизительно) нужно 25GB оперативной памяти. На каждом сервере из сегмента виртуализации установлено 48GB ОЗУ. Этого с запасом хватит для обеспечения работы всех сервисов, даже в случае размещения на одном гипервизоре.

Объем памяти, который может поддерживать сам XEN ограничивается по сути только аппаратной поддержкой серверов проектируемого ЦОД (компания IBM успешно провела тестирование инсталляции Xen с 1TB ОЗУ).

В случае увеличения требований к памяти одного из сервисов XEN позволяет оперативно добавить необходимое количество ОЗУ из свободной области.

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

На первом гипервизоре будут выполняться следующие серверы, с учетом количества ядер CPU и ОЗУ.

-Windows 2k8r2, первый контроллер домена, N-ядер, 6 GB ОЗУ.

-Linux CentOS, DHCP-сервер, 1-ядро, 1 GB ОЗУ.

-Linux CentOS, DNS-сервер, 1-ядро, 1 GB ОЗУ.

-Linux CentOS, NFS-сервер, 1-ядро, 1 GB ОЗУ.

-Linux CentOS, Сервер терминального доступа (SSH,VNC) , 2-ядра, 4 GB ОЗУ.

На втором гипервизоре будут выполняться следующие серверы:

-Windows 2k8r2, второй контроллер домена, 2-ядра, 6 GB ОЗУ.

-Linux CentOS, SAMBA-сервер, 1-ядро, 1 GB ОЗУ.

-Linux CentOS, HTTP-сервер Apache, N-ядер, 4 GB ОЗУ.

-Linux CentOS, FTP-сервер, 1-ядро, 1 GB ОЗУ.

"N-ядер" - означает, что гостевой домен получит доступ ко всем оставшимся процессорным ресурсам, независимо от их количества.

Расположение серверов на гипервизорах и аппаратные ресурсы для каждого гостевого домена могут быть перераспределены в любое время.

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

Для более гибкого распределения системных ресурсов XEN позволяет определять количество процессорного времени и а так же приоритет доступа для каждого домена. Приоритет (cpu_weight) определяется "весом" домена (от 1 до 65535). Значение лимита (cpu_cap) определяется в процентах: 100 это 1 физический процессор, 50 это половина процессора, 400 - 4 процессора и т.д. Важно иметь ввиду, что одному виртуальному процессору не может соответствовать больше чем один реальный процессор.

Настройки процессорного времени и "веса" определим для каждого домена, как настройку по умолчанию (256).

Для каждого гостевого домена можно определять приоритеты ввода/вывода с помощью внешней утилиты "ionice". ionice применяется к процессам виртуальных машин XEN-QEMU (которые можно увидеть командой "ps aux | grep qemu-dm").

XEN позволяет транслировать (пробрасывать) PCI и USB устройства в гостевой домен. Это может быть актуально, например, для взаимодействия виртуализированной ОС с USB-ключем защиты.

Так же существует возможность динамического распределения памяти между доменами XEN. Для этого используется механизм "selfballooning" (с помощью демона xenballoond и специальных balloon-драйверов, устанавливаемых в ОС гостевых доменов.

5.3 Модель сетевого взаимодействия гостевых доменов в пределах гипервизора

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

Виртуальные интерфейс создается автоматически при старте гостевого домена и именуется следующим образом vif<domid>, <vifid>, где domid -идентификатор домена, vifid-идентификатор сетевого интерфейса в домене.

Подобный интерфейс (vif) создается и для управляющего домена (Dom0), который отображается как, например eth0.

Виртуальные интерфейсы внутри гипервизора взаимодействуют через специальный сетевой мост, "xenbr" , который для доменов XEN является обычным сетевым коммутатором 2-о уровня. Мост xenbr0 создается гипервизором XEN автоматически и коммутируется на реальный сетевой интерфейс. Интерфейс, на который ссылаться xenbr настраивается в файле конфигурации XEN, "/etc/xen/xend-config.sxp".

Например, если xenbr ссылается на интерфейс eth0, сетевой мост по умолчанию называется xenbr0, и все домены XEN, в пределах самого гипервизора будут общаться через этот мост:

dom0: fake eth0 ----------> vif0.0

|

(xenbr0) -> real eth0(peth0) -> the network

|

domU: fake eth0(tapN) -> vifN.0

При этом IP-адрес для физического интерфейса можно не задавать. Для внешней сети этот интерфейс будет являться, по сути портом коммутатора, к которому подключены другие узлы сети (гостевые домены XEN). Во время старта гостевого домена, при коммутации на мост xenbr0, домену выдается IP-адрес из диапазона 192.168.100.0/24 собственным DHCP-сервером XEN. Впрочем, ничего не мешает задать любой статический IP-адрес вручную.

Использование сетевого моста для гостевых доменов изолирует сами гипервизоры от остальных узлов на сетевом уровне: интерфейсы мостов прозрачно транслируют трафик до гостевых доменов (ip адрес на этих интерфейсах у гипервизора отсутствует).

Сетевые мосты можно создавать средствами утилит Linux (brctl). Для каждого из сетевых мостов можно добавить интерфейс гостевому домену, добавив в конфигурационный файл этого домена соответствующую строку.

Мост в свою очередь можно скоммутировать на соответствующий vlan, созданный средствами утилиты vconfig (vlan отображается подобно псевдониму (алиасу) сетевого интерфейса, создаваемого ifconfig):

+ ------ tagged0

/

eth1 - vlan4094 - br0

\ vlan4093 - br1

Взаимодействие гостевых доменов в одном из гипервизоров проектируемого центра обработки данных показано на рисунке 7.2:

Рисунок 7.2 "Сетевая структура гипервизора XEN"



Чтобы гостевые домены взаимодействовали через соответствующий vlan надо создать сетевой мост для каждой группы гостевых доменов. Для каждого такого моста надо создать соответствующий виртуальный VLAN-интерфейс, который будет транслировать передачу на физический интерфейс. Внутренний канал "сетевой мост - vlan" надо тегировать соответствующим идентификатором vlan. Гостевые домены надо скоммутировать на соответствующий мост в собственном файле конфигурации.

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

5.4 Сетевое взаимодействие гипервизоров

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

Два интерфейса будут объединены в единый канал (2 ГБ/с), который будет использован для прозрачной связи гостевых доменов с внешней сетью. Но к подсети самих гипервизоров и сетевых хранилищ через этот канал обратиться нельзя.

Поэтому, два оставшихся интерфейса будут также объединены в единый канал (2 ГБ/с), который будет использован для связи гипервизоров между собой и с внешним сетевым хранилищем.

Каждый из этих двух интерфейсов будет соединен с одним из коммутаторов серверного сегмента в стеке коммутации. Сетевые интерфейсы для связи гипервизоров надо поместить в собственный vlan, а так же настроить vlan на стороне коммутационного стека, а так же на стороне сетевых хранилищ (единое пространство vlan необходимо для изоляции этого сегмента от остальной сети). Таким образом будет реализован отказоустойчивый канал связи между коммутационным стеком и гипервизорами. Через этот канал гипервизоры будут передавать между собой состояния и дампы виртуальных машин, файлы конфигурации XEN . Через эти же каналы будет происходить управление гипервизорами, "живая миграция" гостевых доменов и обращение к сетевым хранилищам (NAS).

5.5 Планирование взаимодействия гостевых доменов между гипервизорами, а так же с остальными сегментами сети

Взаимодействие гостевых доменов между гипервизорами и с остальной сетью происходит через единый канал (2 ГБ/с), в который объединены два из четырех интерфейсов гипервизоров. Каждый из этих двух интерфейсов будет соединен с одним из коммутаторов серверного сегмента в стеке коммутации. Внутренние сетевые мосты, к которым подключены гостевые домены, нужно поместить в отдельный сегмент vlan и сделать соответствующие настройки со стороны коммутационного стека. Таким образом, будет реализован отказоустойчивый канал связи между коммутационным стеком и гостевыми доменами. Между гипервизорами связь гостевых доменов будет происходить именно через коммутационный стек с "прозрачных" интерфейсов, подключенных к внутренним мостам (например, xenbr). С остальными сегментами сети гостевые домены будут взаимодействовать через коммутационный стек и узел маршрутизации.

Чтобы группы гостевых доменов были изолированы соответствующим сегментом vlan надо настроить сетевые мосты и виртуальные vlan -интерфейсы. Всего надо определить два сегмента vlan, для следующих групп сетевых сервисов:

- Гостевые домены, обеспечивающие работу сервисов локальной сети.

- Гостевые домены, к которым имеется доступ из внешних сетей.

Для каждой их этих групп надо создать собственный внутренний сетевой мост (который функционально представляет собой коммутатор 2-о уровня). Далее, группы надо сконфигурировать на использование этих мостов, в собственных файлах конфигурации XEN.

Для обоих мостов создаются виртуальные VLAN-интерфейсы, которые будет транслировать передачу в канал, объединяющий реальные интерфейсы. Внутренний канал "мост - vlan" надо тегировать соответствующим идентификатором vlan. Гостевые домены надо скоммутировать на соответствующий мост в собственном файле конфигурации.

Гостевые домены, к которым имеется доступ из внешних сетей, надо поместить в сегмент vlan, в котором расположена подсистема доступа к внешним сетям. Таким образом, эти домены будут изолированы от остальной сети сегментом vlan. Для взаимодействия внутри сети каналы надо тегировать как на уровне гипервизоров, так и на уровне коммутационного сетевого оборудования.

Схема виртуальной среды для взаимодействия гостевых доменов между гипервизорами, а так же самих гипервизоров показана на рисунке 7.3:

Рисунок 7.3 " Сетевое взаимодействие гипервизоров XEN "

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

Для проектируемого ЦОД все виртуальные машины, под которыми работают сетевые сервисы, надо поместить в соответствующую подсеть и задать им статические IP-адреса.

Таким образом, данная конфигурация сетевых интерфейсов гипервизоров (как на физическом, так и на логическом уровне) обеспечивает эффективное взаимодействие сетевых сервисов ЦОД.



5.6 Обеспечение возобновления работы сетевых сервисов при аппаратных и программных сбоях системы

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

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

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

Единая система управления может быть обеспечена, например, через менеджер виртуальных машин "virt-manager". Для этого должен быть создан защищенный туннель с помощью OpenSSH. Настройка туннеля в OpenSSH происходит после генерации открытого и закрытого ключа утилитой "ssh-keygen", далее настраивается аутентификация по ключам shh. Настройки управления осуществляются самой утилитой virt-manager, в которой надо добавить туннели на соответствующие сетевые адреса гипервизоров XEN.

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

- DRBD (Distributed Replicated Block Device - распределённое реплицируемое блочное устройство). Это блочное устройство, предназначенное для построения отказоустойчивых кластерных систем для ОС Linux. DRBD занимается полным отражением (mirroring) по сети всех операций с блочным устройством.

- AoE (ata over ethernet) и vbalde. Это набор утилит, позволяющих "пробросить" ATA устройства через ethernet.

- Средства iSCSI для подключения носителей хранилища к гипервизору в качестве блочного устройства.

- NFS (Network File System) - самый простой вариант единого хранилища (но при этом несколько медленнее iSCSI).

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

iSCSI (Internet Small Computer System Interface) - протокол, который базируется на TCP/IP и разработан для установления взаимодействия и управления системами хранения данных, серверами и клиентами. iSCSI работает на блочном уровне. Объектом, к которому предоставляется доступ, является область данных, интерпретируемая инициатором как блочное устройство (диск). Доступ является монопольным (за исключением специально рассчитанных на это файловых систем и файловых систем в режиме "только для чтения"). Обязанность создавать и обслуживать файловую систему возлагается на инициатора; сервер (цель, target) лишь обслуживает низкоуровневые запросы, аналогичные запросам, которые обслуживает драйвер диска при работе с локальными дисками. Выбранные для проектируемого ЦОД сетевые хранилища (NAS) в полной мере поддерживают протокол iSCSI, что позволит подключать раздел основного хранилища как блочное устройство.

Для размещения виртуальных машин XEN в пространстве сетевого хранилища как файлов следует использовать специальную кластерную файловую систему GFS (Global File System), которая поддерживается дистрибутивами Red Hat Enterprise Linux (соответственно и CentOS).

Высокая скорость работы с сетевым хранилищем (до 5Гбит/s) , обусловлена агрегацией каналов на уровне NAS <=> коммутационный стек.

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

XEN поддерживает возможность работы виртуальной машины непосредственно на блочном устройстве (файловая система создается уже самой виртуализированной ОС, но XEN про это ничего "не знает"). Поэтому второй способ работы с виртуальными машинами в едином хранилище, это размещение их непосредственно в разделах NAS, подключенных средствами iSCSI.

Последний этап настройки гипервизоров, для объединения в кластер, это правка файлов конфигурации XEN и открытие необходимого TCP порта под номером "8002" на всех гипервизорах.

Схема виртуальной среды в пространстве кластера XEN показана на рисунке 7.4:

Рисунок 7.4 "Концепция кластера XEN"

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

-Остановка выполнения ВМ.

-Передача параметров ВМ с сервера исходного расположения ВМ на сервер целевого расположения.

-Передача образа оперативной памяти с сервера исходного расположения ВМ на сервер целевого расположения.

-Создание виртуально домена и размещение образа оперативной памяти в RAM сервера целевого расположения.

-Запуск выполнения ВМ на сервере целевого расположения.

-Уничтожение ВМ на сервере исходного расположения.

(этот процесс занимает меньше секунды)

Загрузочные разделы операционных систем гостевых доменов следует разместить на быстрых твердотельных накопителях SSD основного хранилища NAS. Для хранения прочих файлов следует использовать менее быстрые накопители SAS.

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

При разрыве связи между узлами каждый узел определяет, по какой причине он не видит второй узел. Здесь возможны два варианта:

-Узел видит, что он изолирован (то есть, не видит не только свою вторую половину, но и вообще никого). В этом случае он выключает все домены.

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

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

Схема сети, с учетом коммутационного оборудования в стеке и использованных систем виртуализации показана на рисунке 7.5:

Рисунок 7.5 "Схема сети ЦОД"

Звено управляющих компьютеров надо расположить в сетевом сегменте гипервизоров и сетевых хранилищ. Из этого сегмента можно получить доступ как к управлению гипервизоров (SSH,virt-manager) и сетевых хранилищ, так и к управлению ОС виртуальных машин (xen-console, VNC или собственные терминальные клиенты установленных ОС). При этом для всей остальной сети (пользовательские сегменты) прямой доступ к гипервизорам и сетевым хранилищам будет закрыт.



6. Конфигурирование и настройка

Задача конфигурирования сводится к настройке, как оборудования, так и программного обеспечения, необходимого для обеспечения работы ЦОД.

Эту задачу можно разделить на следующие этапы:

- Конфигурирование сетевого оборудования

- Настройка сетевых хранилищ

- Настройка ОС гипервизоров и среды виртуализации XEN

- Настройка гостевых доменов XEN

- Настройка подсистемы доступа к внешним сетям

...