Строим сетевую инфраструктуру на основе VMware Server::Журнал СА 3.2007
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 5101
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 6343
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 7599
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 7922
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 6979
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Строим сетевую инфраструктуру на основе VMware Server

Архив номеров / 2007 / Выпуск №3 (52) / Строим сетевую инфраструктуру на основе VMware Server

Рубрика: Администрирование /  Продукты и решения

Алексей Бережной

Строим сетевую инфраструктуру на основе VMware Server

Современные требования к IT-структуре, особенно такие, как быстрая переносимость сервисов с одного сервера на другой, упрощение резервного копирования, компактность, а также безопасность и делегируемость полномочий, порой не являются простыми для системного администратора. На помощь приходит VMware Server.

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

Преимущество метода

  • Упрощается процесс резервного копирования и восстановления из резервной копии в связи с тем, что серверы служб получают независимость от железа, на котором работают.
  • На одном физическом компьютере можно разместить несовместимые между собой приложения. Достаточно лишь выделить каждому из них свой виртуальный сервер.
  • На одном компьютере возможно использование серверов под управлением различных операционных систем, например, Windows и FreeBSD.
  • Виртуальные машины можно легко перемещать между физическими серверами. Особенно эта возможность полезна при модернизации аппаратной части системы, а также для лучшего распределения нагрузки на физические серверы.
  • Накладные расходы на поддержание аппаратного обеспечения виртуальной машины как таковые отсутствуют. Не нужно менять кулеры на процессорах, ремонтировать вышедший из строя блок питания и т. д. и т. п. С другой стороны, повышается требовательность к аппаратным ресурсам (см. раздел «Минусы метода»).

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

  • Оборудование для системы занимает меньше места в стойке. Зачем устанавливать в стойку 3-4 маломощных сервера, если вместо них можно установить один сервер, который будет выполнять те же самые функции. Особенно это критично, если оборудование размещается на арендуемой площадке провайдера, или не хватает места в стойке. Для виртуальных машин, размещенных на одном сервере, требуется меньше портов на KVM-switch (Keyboard-Video-Mouse).
  • Добавляются дополнительные возможности администрирования. Например, появляется возможность при зависании приложения не только перезапустить нужный процесс, а перезагрузить виртуальный сервер целиком, не влияя на работу приложений, размещенных на других виртуальных серверах.
  • Улучшается система безопасности. Даже при успешном несанкционированном проникновении по сети на один виртуальный сервер, другие виртуальные серверы остаются нетронутыми.
  • Значительно упрощается процесс делегирования полномочий. Можно передать права на администрирование виртуальным сервером доверенному лицу, не переживая о пересечении полномочий при управлении процессами, размещенными на других серверах.

Минусы метода

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

В целом, описание разнообразных аспектов лицензирования выходит за рамки данной статьи. Всем, кого заинтересует данный вопрос, рекомендую прочесть цикл статей Дмитрия Бутянова «Как купить ПО от Microsoft?» в журнале «Системный администратор», выпуски: №12 за 2006 г. №1 за 2007 г. и в этом номере на стр. 6-11.

Второй минус – снижение быстродействия при использовании системы виртуальных машин на VMware Server. В частности это касается объема оперативной памяти, скорости обмена дисковой подсистемы и т. д. Но развитие аппаратной части компьютерной техники происходит достаточно интенсивно (вспоминаем законы Мура), и поэтому деньги, потраченные на покупку дополнительных модулей памяти или более быстрого RAID-контроллера уже не кажутся баснословными затратами на фоне повышения отказоустойчивости, безопасности и других важных характеристик.

Описание примера

Поскольку утверждения, не подкрепленные практикой, недорогого стоят, то нужно провести некий показательный эксперимент, чтобы показать всю простоту данного решения. Мы запустим систему виртуальных машин на одном компьютере и разместим различные операционные системы: Windows 2003 Server и FreeBSD на виртуальных серверах. На виртуальной Windows-машине разместим контроллер домена Active Directory. Потом установим на другую машину FreeBSD и настроим на ней сетевой интерфейс.

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

Компьютер, на котором будет устанавливаться система виртуальных машин, имеет следующую конфигурацию: AMD Athlon 2600+, 1 Гб RAM, HDD UDMA133, 100 Мб/с LAN. Несмотря на то что оборудование весьма скромное, оно прекрасно справится с поставленной тестовой задачей.

Кроме того, мы будем использовать другой компьютер в качестве рабочей станции, вводимой в домен. Так как конфигурация этой машины не играет существенной роли, ее лучше опустить. Отметим только, что на данном компьютере будет установлена версия Windows XP Pro.

Я специально не буду касаться всех деталей установки. О программных продуктах Windows 2003 Server и VMware написано достаточно много статей и книг, чтобы еще раз подробно описывать все аспекты установки и настройки в этой статье.

Установка необходимого ПО

Скачаем с сайта http://www.vmware.com свежую версию VMware Server. Потом необходимо зарегистрироваться. После чего необходимо заполнить форму по адресу http://register.vmware.com/content/registration.html, чтобы получить серийный номер.

Установим на тестовый компьютер Windows 2003 Server. В данном случае устанавливаем Standard Edition, но система VMware будет неплохо работать на любой другой версии Windows 2003 Server.

После установки операционной системы и необходимых драйверов устанавливаем VMware Server. Установка данного программного продукта практически ничем не отличается от других.

Создание виртуальной машины Windows 2003 Server

После установки операционной системы и VMware Server создаем виртуальную машину Windows 2003 Server Standard Edition. В окне «Network Type» нужно установить переключатель на «Use bridged networking».

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

Рисунок 1. Окно выбора интерфейса для создания «моста» виртуальной машины

Рисунок 1. Окно выбора интерфейса для создания «моста» виртуальной машины

Устанавливаем соответствующую операционную систему. В качестве установочного CD-ROM можно использовать физическое устройство, а можно выбрать ISO-образ диска (который предварительно нужно создать).

Настраиваем и тестируем наше виртуальное «оборудование», в частности – сетевой интерфейс. Мы будем использовать для всех компьютеров IP-адреса одной подсети, поэтому при правильных настройках можно проверить при помощи команды ping доступ к виртуальной машине с реального интерфейса и наоборот.

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

Рисунок 2. Виртуальный интерфейс находится в нерабочем состоянии вследствие того, что физический интерфейс, используемый в качестве bridge, также не подключен

Рисунок 2. Виртуальный интерфейс находится в нерабочем состоянии вследствие того, что физический интерфейс, используемый в качестве bridge, также не подключен

Создание контроллера домена Active Directory на базе виртуальной машины

После установки на виртуальную машину Windows 2003 Server поднимаем на ней контроллер домена Active Directory. Процедура эта ничем не отличается от обычной стандартной процедуры установки контроллера на физическом компьютере (см. рис. 3).

Рисунок 3. Виртуальный компьютер в качестве контроллера домена с запущенной оснасткой  «Active Directory Users and Computers»

Рисунок 3. Виртуальный компьютер в качестве контроллера домена с запущенной оснасткой  «Active Directory Users and Computers»

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

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

Для этого в окне настроек виртуальной машины «Virtual Machine settings» во вкладке «Options» установим параметры автоматического запуска: «On host start up -> Power on virtual machine» и «On host shutdown -> Power off virtual machine» (см. рис. 4).

Рисунок 4. Настройки автостарта виртуальной машины

Рисунок 4. Настройки автостарта виртуальной машины

Кроме этого, необходимо проследить, чтобы службы VMware Server запускались автоматически.

Создание и установка виртуальной машины FreeBSD

Ну здесь все просто. Как обычно, вначале создаем виртуальную машину. Примечательно, что при создании виртуальной машины соответствующий пункт меню нужно искать в окне «Select a Guest Operation System», переставив переключатель в положение «Other».

После создания виртуальной машины устанавливаем на нее соответствующую OS.

Совет: в данном случае особенно актуально использовать для виртуальной машины в качестве CD_ROM ISO-образ первого диска, скачанного с сайта http://www.freebsd.org. Во-первых, потому что не нужно записывать инсталляционный диск из данного образа, а во-вторых, система так устанавливается быстрее.

Создав виртуальную машину и установив на ней операционную систему, мы настроим сетевой интерфейс. После этого мы будем считать свою задачу выполненной.

В дальнейшем на этом компьютере можно будет создать, к примеру, почтовый сервер (см. рис. 5).

Рисунок 5. Настройка интерфейса посредством программы sysinstall в окне виртуальной машины FreeBSD

Рисунок 5. Настройка интерфейса посредством программы sysinstall в окне виртуальной машины FreeBSD

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

Искусственный крах и восстановление из резервной копии

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

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

В качестве метода «уничтожения» сервера я просто отформатировал диск C. После этого вновь переставил Windows 2003 Server и VMware Server.

Для «чистоты» эксперимента я восстановил виртуальные машины в другую папку.

После восстановления из резервной копии и попытки открыть восстановленную виртуальную машину я получил сообщение, говорящее о том, что у виртуальной машины изменился уникальный идентификатор и предложение создать новый или сохранить старый идентификатор. Я выбрал «сохранить старый» – Keep (см. рис. 6).

Рисунок 6. Сообщение об измененном идентификаторе с предложением выполнить необходимые действия

Рисунок 6. Сообщение об измененном идентификаторе с предложением выполнить необходимые действия

Вновь запущенная система продолжила отлично работать. Я спокойно зарегистрировался в Active Directory с рабочей станции и получил доступ ко всем ресурсам, в том числе к папкам, расположенным на виртуальном сервере.

Время восстановления 10 Гб виртуального раздела заняло 33 минуты. Для ситуации, когда подразумевается полный выход контроллера домена Active Directory из строя, это не самый плохой вариант. При этом следует учесть, что данная процедура восстановления виртуального сервера с контроллером домена требует гораздо более скромной квалификации системного администратора (достаточно лишь обладать основными навыками работы с VMware), чем при восстановлении контроллера домена стандартными средствами.

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

Заключение

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

Самое лучшее – это прочесть документацию от производителя, размещенную на http://www.vmware.com/support/pubs. Здесь вы найдете много интересного, в том числе и выходящего за рамки данной статьи.


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru