Самоучитель системного администратора. 5-е издание

Глава 8 
Особенности выключения виртуальных машин 
Существует несколько возможностей выключения виртуальной машины. Во-
первых, можно завершить работу, выключив виртуальную машину с сохранением 
данных при помощи ее внутренней команды 
Завершить работу
. Во-вторых, мож-
но сохранить состояние виртуальной машины из консоли управления гипервизора. 
В этом случае ее работа как бы «заморозится», и после восстановления вы сможете 
продолжить операции. Такой способ напоминает переход в режим «сна» 
(hybernate). В-третьих, можно просто «выключить» питание виртуальной машины, 
выполнив команду 
turn off
. Однако при последующем запуске может обнаружить-
ся потеря несохраненной информации. 
Если на вашем компьютере размещено несколько виртуальных машин, причем 
часть из них настроена на автоматический запуск при включении питания, то при 
выключении хостовой системы осуществляется сохранение состояния виртуальных 
машин. Этот процесс может существенно затянуться, если система будет сохранять 
много информации. В результате основная операционная система воспримет такую 
ситуацию как зависание прикладной программы с отсутствием ответа в течение 
заданного промежутка времени. Тогда виртуальная машина будет аварийно завер-
шена, что может вызвать проблемы при ее следующей загрузке. Чтобы зарезерви-
ровать время на сохранение параметров виртуальных машин в случае перезагрузки 
хостовой системы, измените значение параметра реестра: 
WaitToKillServiceTimeout
в ветви: 
HKLM\SYSTEM\CurrentControlSet\Control\
установив необходимое время ожидания. 
В
НИМАНИЕ
! 
На некоторых «облачных» платформах необходимо двойное выключение виртуальной 
машины. Сначала нужно выключить виртуальную машину средствами операционной 
системы (т. е. использовать команду shutdown или средства графического интерфейса 
пользователя), а затем нажать кнопку 
Выключить
в панели управления виртуальной 
машиной. Если просто выключить «виртуалку», но не сообщить об этом панели 
управления, то за якобы использование виртуальной машины будут продолжать на-
числяться деньги. Если же нажать кнопку 
Выключить
и не произвести выключение 
средствами ОС, то есть риск потери обрабатываемых данных. 
Виртуальные рабочие станции 
Развитие технологий виртуализации позволило применить эти решения не только 
для серверов, но и для пользовательских рабочих станций (так называемые 
desktop-
решения
). Технологии виртуализации рабочих станций получили названия VDI 
(Virtual Desktop Interface). 

---

Виртуализация и «облачные» технологии 
361 
Сравниваем VDI-решения
с терминальными клиентами 
VDI-решения во многом напоминают терминальные подключения пользователей. 
Поэтому следующие основные преимущества терминалов свойственны и виртуаль-
ным рабочим столам: 
VDI-решения существенно снижают затраты на администрирование, поскольку 
вместо нескольких десятков рабочих станций работать приходится с нескольки-
ми серверами; 
конфигурации систем унифицированы, любые обновления выполняются быст-
рее и проще и т. п.; 
сокращаются суммарные затраты на электроэнергию, оборудование использует-
ся более эффективно; 
все данные обрабатываются на сервере, и их легко защитить как для случая
работы внутри локального сегмента, так и при доступе из публичной сети. 
Так же, как и у терминальных клиентов, у пользователей виртуальных рабочих сто-
лов могут возникнуть следующие сложности: 
невозможность использования функций аппаратных ускорителей (обработки 
графики на современных видеокартах, модулей аппаратного шифрования 
и т. п.); 
проблемы с использованием USB-устройств: видеокамер, сканеров, смарткарт 
и т. п.). Лучше использовать принтеры, имеющие сетевой (Ethernet) порт под-
ключения. 
При этом у пользователей виртуальных рабочих столов есть, на взгляд авторов, 
только одно, но весьма существенное преимущество. Каждый пользователь полу-
чает собственный виртуальный компьютер, который может быть настроен только 
для него и при этом совершенно не будет мешать другим сотрудникам. На вирту-
альный компьютер можно поставить любое необходимое программное обеспече-
ние, что практически нереализуемо в условиях жестких настроек терминального 
сервера. 
Немного об экономике VDI 
Как и в любом ИТ-проекте, желательно сначала оценить, сколько будет стоить вне-
дряемое решение и какую экономию (или убыток) оно принесет. Для сравнения 
приведем параметры, на которые ориентируются западные менеджеры и результа-
ты расчета по которым приводятся на наших семинарах (табл. 8.3). 
Как видно из данных табл. 8.3, экономия от внедрения решений VDI может быть 
достигнута только за счет разницы в стоимости рабочих станций и затрат на их об-
служивание (электропитание, стоимость ремонта и т. п.). Поэтому экономически 
эффективным VDI-решение будет только при существенном числе рабочих стан-
ций и учете, например, не менее 3-летнего периода эксплуатации. Так, калькуля- 

---

362 
Глава 8 
тор эффективности от Oracle — Oracle Desktop Virtualization TCO Calculator —
устанавливает минимальную границу числа рабочих станций в 25 единиц 
(см. 
http://www.oracle.com/us/media/calculator/vdi/vdi-tco-calculator-detailed-
406401.html
). 
Таблица 8.3. 
Показатели экономической эффективности технологии VDI 
Параметр Эффект 
Примечание 
Стоимость приобре-
таемого ПО (сервер-
ной и клиентских
лицензий) 
Затраты 
Сумма варьируется для решений различных
вендоров. Стоимость клиентских лицензий 
обычно составляет $100–150 
Стоимость рабочей 
станции 
Экономия, зави-
сит от периода 
использования 
В качестве рабочих станций можно использовать 
упрощенные варианты («тонкие» клиенты и т. п.). 
Возможен отказ от приобретения индивидуальных 
источников аварийного питания. Кроме того,
необходимо учесть разницу в ежегодных расхо-
дах на обслуживание (составляет примерно от 5 
до 10% от стоимости станций) 
Стоимость 
электропитания 
Экономия, зави-
сит от периода 
использования 
Экономия на электроснабжении рабочей станции 
(меньшая мощность), затраты на электропитание 
серверов, систем хранения 
Стоимость оборудо-
вания: серверы, СХД, 
фермы 
Затраты 
Минимально от одного сервера и системы хране-
ния, оптимально — отказоустойчивые решения
с выделенными серверами управления, обеспе-
чения доступа из Интернета и т. п. 
Структура VDI-решений 
VDI-решения объединяют различные элементы ИТ-структуры предприятия 
(рис. 8.3). Так, из службы каталогов берется информация о пользователях и груп-
пах. Например, некоторой группе пользователей можно поставить в соответствие 
определенный шаблон виртуального рабочего стола — в результате новому поль-
зователю будет автоматически предоставляться конфигурация компьютера в соот-
ветствии с его функциональными обязанностями. 
Программное обеспечение VDI может управлять (обеспечивать подключение)
к виртуальным рабочим столам различных гипервизоров или к сессиям терминаль-
ных серверов. 
Поскольку VDI-решения обслуживают большое количество рабочих столов, то они 
должны быть весьма надежными. Поэтому в производственной среде следует реа-
лизовывать отказоустойчивые решения: наряду с основным сервером управления 
необходимо предусматривать резервные (один или несколько), нужно установить 
несколько серверов, на которых будут запускаться виртуальные рабочие столы, 
выбрать надежную систему хранения, построить резервированную сеть передачи 
данных (рис. 8.4). 

---

Виртуализация и «облачные» технологии 
363 
Рис. 8.3. 
Логическая структура VDI-решения 
Рис. 8.4. 
Вариант аппаратной реализации VDI-решения 
Некоторые особенности VDI-решений 
VDI-решения обычно настраиваются на автоматическое создание виртуальных ра-
бочих столов. Для этого администратором предварительно создаются шаблоны 
различной конфигурации, которые ставятся в соответствие группам пользователей 
из службы каталогов предприятия. При попытке подключения нового пользователя 
ПО предоставляет ему виртуальный рабочий стол, сформированный по соответст-
вующему шаблону (для повышения производительности по шаблонам предвари-
тельно создается некоторое количество рабочих столов, которые находятся в неак-
тивном состоянии). После отключения пользователя виртуальная машина, в зави-
симости от настроек, может сохраняться или уничтожаться для высвобождения
ресурсов. 
Поскольку однотипные конфигурации содержат значительное количество одинако-
вой информации на дисках и в памяти системы, то ПО VDI позволяет настроить 
совместное использование таких ресурсов. 

---

364 
Глава 8 
Для подключения к VDI на рабочие места устанавливается клиентское ПО. При 
этом подключение к различным конфигурациям (различным виртуальным рабочим 
столам или терминальным сессиям) осуществляется через одну точку. Если пользо-
вателю разрешено подключение к нескольким рабочим столам/конфигурациям, то 
право соответствующего выбора предоставляется на экране подключения к VDI. 
KVM и OpenVZ 
Разница между KVM и OpenVZ 
В Linux поддерживаются две технологии виртуализации на уровне ядра: KVM 
(Kernel Virtual Machine) и OpenVZ. У каждой из этих технологий есть свои пре-
имущества и свои недостатки. При желании вы можете ознакомиться с ними в Ин-
тернете, где найдете множество статей, сравнивающих эти две технологии. 
Но есть между ними одно очень важное отличие — это возможность «оверселить» 
ресурсы OpenVZ. Слово «оверселить» происходит от английского «oversell». Если 
вы совсем не знаете английского, поясним, что это означает «продать больше, чем 
было». Как такое возможно? 
Рассмотрим пример. Представим, у вас есть сервер с 32 Гбайт оперативной памяти. 
Вы решили, что 2 Гбайт потребуется физическому серверу, а оставшиеся 30 Гбайт 
можно распределить между виртуальными машинами, — скажем, по 1 Гбайт на 
каждый сервер. Вы создаете 30 серверов, каждому из которых отводите по 1 Гбайт 
оперативки. Но со временем вы обнаруживаете, что большинство серверов исполь-
зуют 500–600 Мбайт оперативной памяти, а то и меньше. Следовательно, можно 
попытаться «продать» эту недобранную память. Вы делаете предположение, что
в пики максимальной загрузки потребление оперативной памяти составит 
750 Мбайт (не нужно забывать, что речь идет не о рабочей станции Windows, где 
последняя версия Skype легко забирает 500 Мбайт ОЗУ, а о Linux-сервере, который 
весьма скромно потребляет ресурсы компьютера). Оставшиеся 250 Мбайт можно 
«продать» еще раз. В итоге к имеющимся 30 серверам у вас добавится еще 7: 
250 
×
30 / 1024 ≈ 7 
Все это будет выглядеть как 37 серверов по 1 Гбайт (максимально возможное по-
требление памяти), в то время как у вас есть всего 30 Гбайт доступной оперативной 
памяти. Это и есть оверселлинг. 
О перерасходе памяти заботиться не нужно. Даже если сервер S1 израсходует 
850 Мбайт оперативной памяти, то сервер S2 — всего 430. В итоге общее потреб-
ление оперативной памяти составит по 640 Мбайт на сервер. Если же все-таки про-
изойдет ситуация, когда серверы начнут потреблять больше памяти, чем есть
на самом деле, будет задействована подкачка. Да, это снизит производительность, 
но вся информационная система останется в работоспособном состоянии. 
Чтобы не попасть на оверселлинг, желающие обзавестись виртуальным сервером 
(VPS) стараются приобрести KVM-сервер. Технология KVM жестко распределяет 

---

Виртуализация и «облачные» технологии 
365 
ресурсы сервера, и оверселлинг здесь невозможен. Поэтому хостеры чаще предла-
гают именно KVM-серверы, поскольку желающих на такой сервер больше. 
Тем не менее, если вы создаете подобную информационную систему для своего 
предприятия, OpenVZ позволит вам более эффективно использовать ресурсы сер-
вера. Да, можно было бы и в KVM создать 37 серверов — по 750 Мбайт оператив-
ной памяти на каждый. Но тут суть в распределении ресурсов: максимальный ли-
мит — 1 Гбайт, и если серверу S23, скажем, понадобится 990 Мбайт, он в условиях 
OpenVZ их получит. Произойдет это за счет сервера, который не использует много 
ОЗУ, — например, за счет сервера S37, который потребляет всего 530 Мбайт. Об-
щее потребление ОЗУ на два сервера не превысило 1,5 Гбайт, поэтому все в норме. 
А в случае с KVM, если бы всем было жестко выделено по 750 Мбайт, то сервер 
S23 «ушел бы в своп», но при этом в системе остались бы 220 Мбайт свободной 
оперативной памяти, которую можно было задействовать в OpenVZ на условиях 
оверселлинга. 
Установка ядра OpenVZ 
Теперь перейдем к настройке виртуализации. Опишем мы ее на примере дистрибу-
тива CentOS, хотя при желании вы можете использовать любой другой. Поскольку 
речь идет о технологии виртуализации на уровне ядра, первым делом нужно уста-
новить ядро с поддержкой OpenVZ. Конечно, такое ядро можно откомпилировать 
самостоятельно, но зачем тратить на это время, если уже есть готовые ядра с под-
держкой OpenVZ. 
Итак, от имени пользователя root или от имени любого другого пользователя с пра-
вами root введите команды: 
wget -P /etc/yum.repos.d/ http://ftp.openvz.org/openvz.repo 
rpm --import http://ftp.openvz.org/RPM-GPG-Key-OpenVZ 
yum install vzctl vzquota ploop 
reboot 
Первая команда получает GPG-ключ репозитория, вторая — импортирует его,
третья — устанавливает необходимые пакеты, а последняя — перезагружает хост. 
Как видите, все просто, и никаких танцев с бубнами, как в случае с компиляцией 
ядра. 
Создание и запуск виртуальной машины OpenVZ 
После установки OpenVZ-ядра нужно скачать шаблоны виртуальных машин. На 
сайте 
http://openvz.org/Download/template/precreated
есть множество разных 
шаблонов, поэтому вам даже не придется создавать виртуальные машины само-
стоятельно и тратить на это время. Среди шаблонов вы найдете виртуальные
машины с уже предустановленными последними или предпоследними версиями 
следующих дистрибутивов: CentOS, Debian, Ubuntu, Fedora, openSUSE, ALT Linux, 
Arch, Gentoo, Slackware и др. Выбор более чем впечатляет. 

---

366