Автор Николай Гесс (C) для проекта GNU/Linux ХМАО-Югра
Работать системным администратором интересно, но со временем становится скучно и в какой то момент времени становится очевидным что вся работа свелась к четырем основным и главным функциям системных администраторов - спать, тупить, есть булки с чаем, и в свободное от этих мероприятий время лузгать семечки.

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

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

1. В обслуживании находится более 20 физических серверов. При меньшем количестве особого преимущества не будет с финансовой точки зрения, да и управиться с небольшим количеством можно безо всяких премудростей. В общем, администраторы небольших контор продолжают работать, не отвлекаясь на глупости, это не для них.
2. Есть в наличии грамотно построенная сетевая инфраструктура. Если у вас один, два коммутатора и буквы vlan для вас не понятны, пользуемся советом из предыдущего пункта. Так же для получения максимальной отдачи необходимо общее хранилище, если у вас такого нет, то очень сильно задумываемся, почему все так плохо.
3. Есть сервера в штатном режиме не использующие более 70 процентов ресурсов процессора сервера. Тут все просто - если у вас задача на сервере ПОСТОЯННО загружает ЦП на 70 процентов, то ее нет смысла переводить на виртуальную инфраструктуру. Хотя всегда есть возможность, что-то изменить. Был прецедент в практике, когда почтовый сервер использовал ресурсы почти на 90 процентов на двухпроцессорном сервере, но после проведения ряда мероприятий эта же задача стала практически невесомой, тихой и ласковой. Большинство же задач в штатном режиме редко используют ресурсы более чем на 20-30 процентов. Так что подойдите критически к задачам, которые выполняются на ваших серверах и задумайтесь, оптимально ли вы используете существующие мощности.
4. У всего есть свои минусы, данный случай не исключение - USB порты буду недоступны для сервера в виртуальной машине. И тут ни чего не поделаешь, гипервизор не предоставляет для ВМ доступ к USB портам. Так что обладатели USB ключей защиты принимают это во внимание и напрягают серое вещество как сие можно исправить (варианты всегда есть).
5. Наличие бюджета – если быть законопослушным, то решение влетит в копеечку.

Для путешествия в мир виртуализации была выбрана реализация от VMWare. Почему именно она? Ну на мой взгляд из присутствующих на рынке решений именно решение этой компании наиболее удобное ,гибкое и мощное. Сразу надо сказать - НЕБЕСПЛАТНОЕ. Но данный факт пока не вводит в депрессию, так как для наших целей знакомства с виртуальной средой, мы вполне легально имеем возможность пользоваться полнофункциональной версией с ограничением в 60 дней. Необходимо только лишь зарегистрироваться и ... скачать с сайта фирмы-производителя. Что же представляет собой и это решение. Это, прежде всего сам гипервизор VMWare ESX server, который существует в двух вариантах - с консолью управления и без оной. Версия с консолью управления называется ESX и предназначена для установки на серверное оборудование по образу и подобию традиционной операционной системы. Вторая версия ESXi предназначена для загрузки со съемных накопителей, например, с обыкновенной флешки. Немного отступив, могу сказать, что HP заключила договор на поставку этого гипервизора совместно со своими серверами в качестве дополнительной опции. От себя могу добавить, что такое решение мне показалось весьма изящным, так как при приобретении можно быть уверенным, что система заработает на данной конфигурации сразу после включения сервера. Немаловажен еще и тот фактор, что для работы с ESXi версией гипервизора не требуется наличие жестких дисков, что дает нам дополнительную экономию в случае работы с внешними хранилищами и исключает одно слабое звено - накопитель. В общем, данный вариант просто идеален для использования в blade серверах (про использование которых можно писать отдельную немаленькую статью). Далее производитель нам предлагает продукт с гордым названием Virtual Center, это программное обеспечение которое поможет нам централизованно управлять несколькими гипервизорами и предоставляет нам несколько довольно полезных функций. Так же только посредством его можно управлять хостами с установленной версией гипервизора ESXi. Но об его использовании немного позже. Так же на сайте есть несколько полезных дополнений, на которые в предвкушении манны небесной нет времени обращать внимание.
И так, идея есть, необходимо теперь все это воплотить в несколько более осязаемый вид, для этого нам потребуется, прежде всего, скачать тот вариант гипервизора, с которым будут проходить наши дальнейшие эксперименты. Для своих изысканий был выбран полный вариант с консолью управления, который был представлен в виде файла образа размером почти 600 мегабайт. Да... за все приходится платить, за удобство размером, но в нынешние времена такой размер уже не представляет большой проблемы. Далее, свободная машина, на которую все это добро надо поставить. Тут главным критерием выступает объем оперативной памяти, который в наше время не является большой проблемой, для экспериментов будет более чем достаточно 2 гигабайт. Процессор - какой есть, но на Р4-3.2 все работает просто идеально, в дальнейшем объясню почему. И вот диск вставлен система начинает загружаться ... скоро, скоро будет счастье, но что же мы видим? В нашем компьютере системой не была обнаружена сетевая карта!!! А в виду того что для работы системы сетевая карта является ключевым объектом то и установщик решает что дальше нет смысла продолжать о чем он и говорит. Физическое наличие одной интегрированной карты на материнской плате и второй установленной дополнительно в данном случае, не сыграло ни какой роли. Что поделать, отправляемся читать, что и как - узнаем, что данная система работает только на ограниченном ассортименте сетевых карт. О списке оборудования, на котором система точно будет работать, можно прочитать на сайте. Ну да это не явилось преградой, так как в наличии было несколько серверных сетевых карт формата PCI-x, которые замечательно заработали в обычном PCI. После установки дополнительных сетевых карт установка прошла без проблем. Детально описывать установку нет смысла, так как она проста и незамысловата, тот, кто устанавливал Linux, меня поймет - все тоже самое только меньше телодвижений - язык, часовой пояс, пароль root`а и естественно настройка сетевой карты. Ни чего неожиданного и специфичного, нет выбора пакетов и каких-то хитроумных настроек, все просто и довольно быстро. Есть куча рекомендаций по распределению файловых систем по физическим накопителям и рекомендуемое пространство для каждой из веток, но для целей эксперимента и ознакомления можно принять настройки по умолчанию. Ставится сам гипервизор, минимальный набор утилит для консоли , да, в списке дополнительный пакетов нет midnight commander`а так что возможность насладиться командной строкой тут представлена для всех желающих. Установка прошла, что ж грузимся ... Идет привычный запуск Linux системы, только загрузчик вместо выбора варианта ядра нам предлагает выбрать режим запуска сервера вcего три - стандартный, отладочный с расширенным протоколированием событий и загрузка только управляющей консоли без загрузки самого гипервизора. Выбираем вариант по умолчанию - стандартный и продолжаем загрузку, все до боли привычно ядро, службы. Вот на отдельной консоли нам говорят что теперь сервер доступен через стандартный веб-браузер по сетевому адресу, который мы настроили при установке. Однако что-то сани не едут, переключаемся знакомой комбинацией кнопок (Alt+F1) в первую консоль и наблюдаем, система загрузилась не полностью и остановилась на загрузке службы ipmi, причем остановилась наглухо. Делать нечего, перегружаем. Картина не меняется, останавливается на том же месте. Плюем и идем домой в расстроенных чувствах. На следующий день наблюдаем картину - система загрузилась! Как выяснилось при разборе логов загрузки, система пыталась запустить злополучную службу в течение 2 часов! Во избежание дальнейших казусов просто выключаем ее из загрузки - chkconfig вам в руки, в следующий раз система грузится стандартно шустро. После загрузки системы на консоли наблюдаем стандартное для Linux приглашение зарегистрироваться в системе, но что-то нам подсказывает, что пора рулить системой серьезно и мы пытаемся обратиться к серверу через браузер ... Фиаско! Нет соединения, сервер не найден, команда ping также нам сообщает об отсутствии устройства с таким адресом. Ну что же, добро пожаловать в консоль проводим стандартную процедуру проверки - смотрим наличие сетевых карт, их статус - все нормально! Но сани не едут, нет связи с сетью! Становится понятно, что шаманский бубен будет совсем нелишним, поэтому достаем, отряхивая пыль, и исполняем привычный ритуал. После разговора с духами смиренно продолжаем изучение системы из сервисной консоли, команды, команды, смотрим на специфичные, как нетрудно догадаться они начинаются на esx*, команд немного - всего пара дюжин. После недолгого разбирательства и выяснения их работы мы находим подходящие esxcfg-nic, esxcfg-vswitch. немного забегая вперед , скажу что система не только предполагает наличие виртуальных машин но еще и наличие виртуальных коммутаторов в которые подключаются наши ВМ. И команда esxcfg-vswitch как раз таки позволяет нам конфигурировать эту виртуальную железку. Набираем esxcfg-vswitch -l и лицезреем описание работающего на данный момент виртуального коммутатора так - имя, количество портов (по умолчанию 64) , количество использованных портов , MTU и Uplink. Все просто замечательно, но опыт подсказывает что для коммутатора необходимо соединение с внешним миром через uplink - порты , но в нашем случае в этой колонке пусто. Не долго думая, выясняем командой esxcfg-nics -l какие сетевые карты присутствуют в нашей системе и производим их подключение в uplink виртуального коммутатора посредством команды esxcfg-vswitch -L <имя сетевой карты из предыдущей команды в нашем случае 'vmnic1'> <Имя виртуального коммутатора, в нашем случае 'vSwitch0'>.

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

Есть смысл подробнее остановится на типах групп портов. В данной системе есть три типа VM port Group, VMKernel, Service Console. Первый тип используется для работы ВМ, замечательно дружит с vlan группами на реальных коммутаторах. Второй тип используется для нужд самого гипервизора, необходим для работы в кластере и для доступа к внешнему хранилищу через NFS(важный момент). Третий тип используется для доступа к серверу для управления, на работу ВМ не влияет.

Все, система установлена и готова к испытаниям.

_____________________________________

Копирование материала разрешено только при наличии ссылки на источник:
неофициальный проект GNU/Linux ХМАО-Югра www.oslinux.ru