Администрирование VMware V-Sphere 4.1 - 2011
Upcoming SlideShare
Loading in...5
×
 

Администрирование VMware V-Sphere 4.1 - 2011

on

  • 12,117 views

Михеев м.о.

Михеев м.о.

Statistics

Views

Total Views
12,117
Views on SlideShare
12,116
Embed Views
1

Actions

Likes
1
Downloads
64
Comments
3

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

13 of 3 Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Администрирование VMware V-Sphere 4.1 - 2011 Администрирование VMware V-Sphere 4.1 - 2011 Document Transcript

    • Михеев М. О.АдминистрированиеVMware vSphere 4.1 Москва, 2011
    • УДК 32.973.26-018.2ББК 004.4 М69 Михеев М. О.М69 Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил. ISBN 978-5-94074-685-0 Новое издание книги посвящена работе с семейством продуктов послед- ней версии VMware vSphere 4.1 В ней рассмотрены установка vSphere, настройка сети виртуальной ин- фраструктуры, системы хранения данных, виртуальные машины, управле- ние ресурсами сервера, защита данных в виртуальных машинах. Кроме того, приводятся сведения о принципах работы, способах мониторинга и диагно- стики неполадок. Наконец, дается информация по дополняющим сторон- ним продуктам, которые могут помочь в работе или решении возникающих перед администратором проблем. Материал книги подается в виде пошаго- вых инструкций с подробной детализацией. Издание будет полезно как начинающим, так и опытным системным ад- министраторам, которые могут использовать книгу как справочник по пара- метрам и командам VMware vSphere. УДК 32.973.26-018.2 ББК 004.4 Все права защищены. Любая часть этой книги не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения вла- дельцев авторских прав. Материал, изложенный в данной книге, многократно проверен. Но поскольку вероятность технических ошибок все равно существует, издательство не может гарантировать абсолютную точность и правильность приводимых сведений. В связи с этим издательство не несет ответ- ственности за возможные ошибки, связанные с использованием книги. © Михеев М. О., 2011ISBN 978-5-94074-685-0 © Оформление, ДМК Пресс, 2011
    • СодержаниеВведение ................................................................................................ 8 Для кого? ........................................................................................... 8 О какой версии продукта? .................................................................. 8 Как книга организована? .................................................................... 8 Обратная связь ................................................................................ 10Предисловие ...................................................................................... 11Глава 1. Установка vSphere ........................................................... 12 1.1. Обзор ............................................................................................. 12 1.2. Установка и начало работы с ESX(i) ................................................ 13 1.2.1. Чем отличаются ESX и ESXi ..................................................... 13 1.2.2. До установки .......................................................................... 15 1.2.3. Установка ESXi ........................................................................ 18 1.2.4. Установка ESX ......................................................................... 21 1.2.5. Автоматическая установка ESX ............................................... 26 1.2.6. Автоматическая установка ESXi............................................... 32 1.3. Начало работы ............................................................................... 33 1.3.1. Начало работы без vCenter...................................................... 33 1.3.2. Установка и начало работы с vCenter Server ............................ 35 1.4. Интерфейс клиента vSphere, vCenter, ESX(i). Веб-интерфейс ......... 41 1.4.1. Элементы интерфейса клиента vSphere при подключении к vCenter........................................................................................... 41 1.4.2. Первоначальная настройка vCenter и ESX(i) ............................ 48 1.4.3. Работа через веб-интерфейс .................................................. 53 1.5. Обновление ESXi, ESX и vCenter с версий 3.x .................................. 55 1.5.1. Обновление до vCenter Server 4 и Update Manager 4 ............... 56 1.5.2. Обновление ESX(i) с помощью Update Manager ....................... 59 1.5.3. Обновление виртуального оборудования ВМ и VMware tools ... 60 1.5.4. Установка обновлений из командной строки ........................... 62 1.5.5. Отмена обновления ESX 3.x на ESX 4 ...................................... 63 1.6. Основы работы из командной строки ............................................. 64 1.6.1. Локальная командная строка ESX, SSH .................................. 64 1.6.2. Локальная командная строка ESXi, SSH .................................. 66 1.6.3. vSphere CLI, работа с vMA ....................................................... 67 1.6.4. Полезные команды ................................................................. 69
    • 4 Содержание 1.6.5. Полезные сторонние утилиты ................................................. 70 1.7. Сайзинг и планирование ................................................................ 74 1.7.1. Процессор .............................................................................. 75 1.7.2. Память .................................................................................... 79 1.7.3. Дисковая подсистема ............................................................. 79 1.7.4. Сетевая подсистема ............................................................... 83 1.7.5. Масштабируемость: мало мощных серверов или много небольших?...................................................................................... 85Глава 2. Настройка сети виртуальнойинфраструктуры ................................................................................ 88 2.1. Основы сети ESX(i), объекты виртуальной сети .............................. 88 2.1.1. Физические сетевые контроллеры, vmnic ............................... 91 2.1.2. Виртуальные контроллеры Service Console и VMkernel ............ 93 2.2. Стандартные виртуальные коммутаторы VMware – vNetwork Switch..................................................................................... 98 2.3. Распределенные коммутаторы –vNetwork Distributed Switch, dvSwitch. Настройки ........................................................................... 101 2.3.1. Основа понятия «распределенный виртуальный коммутатор VMware» ...................................................................... 102 2.3.2. Добавление сервера в dvSwitch, настройки подключения vmnic .............................................................................................. 105 2.3.3. Группы портов на dvSwitch, добавление интерфейсов Service Console и VMkernel ............................................................. 109 2.3.4. Уникальные настройки dvSwitch ........................................... 111 2.3.5. Уникальные настройки портов dvSwitch: Miscellaneous и Advanced ..................................................................................... 112 2.3.6. Миграция со стандартных виртуальных коммутаторов на распределенные ....................................................................... 113 2.3.7. Технические особенности распределенных виртуальных коммутаторов VMware .................................................................... 117 2.4. Настройки Security, VLAN, Traffic Shaping и NIC Teaming ................ 118 2.4.1. VLAN, виртуальные локальные сети. Настройка VLAN для стандартных виртуальных коммутаторов ................................. 118 2.4.2. Настройка VLAN для dvSwitch. Private VLAN ........................... 123 2.4.3. Security ................................................................................. 126 2.4.4. Ограничение пропускной способности (Traffic Shaping) ....... 128 2.4.5. NIC Teaming. Группировка сетевых контроллеров ................. 128 2.4.6. Cisco Discovery Protocol, CDP ................................................ 134 2.5. Разное ......................................................................................... 135 2.5.1. Jumbo Frames ....................................................................... 135 2.5.2. TSO – TCP Segmentation Offload, или TOE – TCP offload engine ............................................................................................ 137 2.5.3. VMDirectPath ......................................................................... 138
    • Содержание 5 2.5.4. Отдельные порты .................................................................. 139 2.6. Рекомендации для сети ................................................................ 140Глава 3. Системы хранения данных и vSphere ..................... 141 3.1. Обзор типов СХД .......................................................................... 142 3.2. DAS .............................................................................................. 144 3.3. NAS (NFS)..................................................................................... 145 3.3.1. Настройка и подключение ресурса NFS к ESX(i) .................... 147 3.4. SAN, Fibre Channel ........................................................................ 149 3.4.1. Адресация и multipathing ....................................................... 152 3.4.2. Про модули multipahing. PSA, NMP, MMP, SATP, PSP............... 155 3.4.3. Про зонирование (Zoning) и маскировку (LUN masking, LUN presentation) .............................................................................. 160 3.5. SAN, iSCSI .................................................................................... 162 3.5.1. Как настроить программный инициатор или аппаратный зависимый iSCSI на ESX(i) .............................................................. 164 3.5.2. iSCSI Multipathing .................................................................. 169 3.6. VMFS, Virtual Machine File System .................................................. 172 3.6.1. Увеличение размера хранилища VMFS. Grow и Extent ........... 178 3.6.2. Доступ к клонированному разделу VMFS, или к разделу VMFS с изменившимся номером LUN ............................................. 181 3.7. RDM, Raw Device Mapping ............................................................. 183 3.8. NPIV ............................................................................................. 186 3.9. Адресация SCSI............................................................................ 188 3.10. vSphere API for Array Integration, VAAI. Интеграция и делегирование некоторых операций системам хранения данных ..... 191Глава 4. Расширенные настройки, безопасность,профили настроек .......................................................................... 194 4.1. Расширенные настройки (Advanced settings) ................................ 194 4.2. Безопасность ............................................................................... 195 4.2.1. Общие соображения безопасности ...................................... 196 4.2.2. Брандмауэр ESX ................................................................... 198 4.2.3. Аутентификация на серверах ESX(i), в том числе через Active Directory ............................................................................... 200 4.2.4. Контроль доступа, раздача прав при работе через vCenter ... 201 4.3. Настройка сертификатов SSL ....................................................... 208 4.4. Host Profiles .................................................................................. 210 4.5. Использование SNMP .................................................................. 217 4.5.1. Настройка SNMP для vCenter ................................................ 218 4.5.2. Настройка SNMP для серверов ESX(i) ................................... 221Глава 5. Виртуальные машины .................................................. 222 5.1. Создание ВМ. Начало работы с ней .............................................. 222
    • 6 Содержание 5.2. Клонирование и шаблоны ВМ (Clone и Template) .......................... 227 5.2.1. Клонирование виртуальных машин ....................................... 227 5.2.2. Шаблоны виртуальных машин (template) ............................... 229 5.2.3. Обезличивание гостевых ОС, SysPrep ................................... 231 5.2.4. Рекомендации для эталонных ВМ ......................................... 234 5.3. Виртуальное оборудование ВМ .................................................... 236 5.3.1. Memory ................................................................................. 237 5.3.2. CPUs ..................................................................................... 237 5.3.3. IDE, PS2 controller, PCI controller, SIO controller, Keyboard, Pointing device ................................................................................ 238 5.3.4. Video card ............................................................................. 238 5.3.5. VMCI device, VM Communication Interface .............................. 239 5.3.6. Floppy drive ........................................................................... 239 5.3.7. CD/DVD Drive ........................................................................ 239 5.3.8. Network Adapter .................................................................... 240 5.3.9. SCSI controller ....................................................................... 247 5.3.10. Hard Disk ............................................................................. 249 5.3.11. Parallel port .......................................................................... 250 5.3.12. Serial port ............................................................................ 250 5.3.13. SCSI device.......................................................................... 251 5.3.14. USB controller и USB device.................................................. 251 5.3.15. VMDirectPath ....................................................................... 252 5.4. Все про диски ВМ......................................................................... 254 5.4.1. Виртуальные диски – файлы vmdk ........................................ 254 5.4.2. Изменение размеров дисков ВМ .......................................... 260 5.4.3. Выравнивание (alligment) ...................................................... 266 5.4.4. Raw Device Mapping, RDM ..................................................... 270 5.5. Настройки ВМ .............................................................................. 272 5.6. Файлы ВМ, перемещение файлов между хранилищами ............... 276 5.7. Снимки состояния (Snapshot) ....................................................... 284 5.8. VMware tools ................................................................................. 292 5.9. vAPP ............................................................................................. 296Глава 6. Управление ресурсами сервера.Мониторинг достаточности ресурсов. Живаямиграция ВМ. Кластер DRS......................................................... 299 6.1. Настройки распределения ресурсов для ВМ. Пулы ресурсов ....... 299 6.1.1. Настройки limit, reservation и shares для процессоров и памяти......................................................................................... 299 6.1.2. Пулы ресурсов ...................................................................... 307 6.1.3. Рекомендации по настройкам Limit, Reservation и Shares ..... 311 6.1.4. Storage IO Control, SIOC, для дисковой подсистемы .............. 314 6.1.5. Network IO Control, NIOC и traffic shaping для сети ................. 317 6.2. Механизмы перераспределения ресурсов в ESX(i) ....................... 319
    • Содержание 7 6.2.1. CPU ...................................................................................... 320 6.2.2. Memory ................................................................................. 323 6.2.3. Disk ....................................................................................... 340 6.2.4. Net ........................................................................................ 340 6.3. Мониторинг достаточности ресурсов ........................................... 340 6.3.1. Источники информации о нагрузке ....................................... 341 6.3.2. Какие счетчики нас интересуют и пороговые значения ......... 352 6.3.3. Несколько общих рекомендаций ........................................... 358 6.4. Механизм Alarm ........................................................................... 359 6.5. Миграция выключенной (или suspend) виртуальной машины ....... 363 6.6. Storage vMotion – живая миграция файлов ВМ между хранилищами ..................................................................................... 365 6.7. vMotion – живая миграция ВМ между серверами .......................... 366 6.8. Кластер DRS. DPM........................................................................ 372Глава 7. Защита данных и повышение доступностивиртуальных машин ....................................................................... 388 7.1. Высокая доступность виртуальных машин .................................... 388 7.1.1. VMware High Availability, HA .................................................... 389 7.1.2. VMware Fault Tolerance, FT ..................................................... 406 7.2. Управление обновлениями виртуальной инфраструктуры, VMware Update Manager ...................................................................... 417 7.2.1. esxupdate и vSphere CLI vihostupdate ..................................... 417 7.2.2. vSphere Host Update Utility ..................................................... 417 7.2.4. VMware Update Manager ........................................................ 419 7.3. Резервное копирование и восстановление................................... 431 7.3.1. Резервное копирование ESX(i) и vCenter ............................... 431 7.3.2. Резервное копирование виртуальных машин ........................ 432 7.3.3. VMware Data Recovery ........................................................... 438 7.3.4. Использование VMware Consolidated Backup и vStorage API for Data Protection..................................................... 445
    • ВведениеПоследние несколько лет тема серверной виртуализации привлекает вниманиевсе большего количества компаний и технических специалистов. Виртуализацияпозволяет добиться финансовых выгод для компании, значительного упрощенияработы для системных администраторов. Сегодня самым интересным решениемдля виртуализации серверов является флагманское семейство продуктов компа-нии VMware – VMware vSphere 4. Гипервизор ESX или ESXi, часть vSphere, обладает очень интересными воз-можностями по виртуализации, балансировке нагрузки на подсистемы одного сер-вера и балансировке нагрузки между серверами, а также повышению доступностиприложений, выполняемых в виртуальной среде. Однако чтобы начать в полноймере пользоваться всеми функциями vSphere, понадобятся определенные знания.Еще до того, как даже начать установку ESX на сервер, стоит задуматься о многихвещах, например об ограничениях по выбору оборудования и от чего зависят тре-бования к производительности. Кроме того, не лишними будут знания из некоторых смежных областей, такихкак системы хранения данных, сети, особенности серверного оборудования. Всеэти темы в достаточной мере раскрываются в данной книге простым и понятнымязыком. Для кого? Данная книга касается большинства аспектов серверной виртуализации, по-дача материала рассчитана на неподготовленных системных администраторов.В силу полноты описываемых тем интересна она будет и администраторам с опы-том работы в области виртуализации, в частности как справочное пособие. О какой версии продукта? На момент написания данной книги актуальной версией являлась vSphere 4.1.Тем не менее большая доля и, скорее всего, вся информация книги будет актуаль-на для всех обновлений четвертой версии виртуальной инфраструктуры VMware. Как книга организована? Глава 1. Установка vSphere. Первая глава посвящена самому началу – чтотакое VMware vSphere 4? Какие продукты входят в это семейство? Какие вспо-могательные продукты предлагает нам VMware? Какие существуют сторонние
    • Введение 9продукты, способные облегчить жизнь администратору? Объясняется, каким ню-ансам следует уделить внимание при выборе оборудования для vSphere. Даютсяосновные ответы на один из наипопулярнейших вопросов – «Сервер какой про-изводительности (или сколько серверов) необходимо для запуска на нем ESX?».Разбирается установка с нуля или обновление до vSphere 4 предыдущей версиивиртуальной инфраструктуры VMware. Автоматизация установки для упроще-ния массового развертывания. После установки – этап первоначальной настрой-ки. Дается основная информация по элементам графического интерфейса и вы-полнению манипуляций с vSphere из командной строки. Глава 2. Настройка сети виртуальной инфраструктуры. В этой главе приво-дится полная информация об организации сети для виртуальной инфраструкту-ры. Что собой представляют для гипервизора физические сетевые контроллеры?Виртуальные коммутаторы, стандартные и распределенные – что необходимознать для уверенного использования этих объектов? Какие настройки для нихвозможны? Рассказывается про виртуальные сетевые контроллеры, принадле-жащие самому гипервизору. Дается необходимая информация для планированиясхемы сети виртуальной инфраструктуры. Глава 3. Системы хранения данных и vSphere. Для большинства инфраструк-тур VMware vSphere используется внешнее хранилище данных, SAN или NAS.Администратору vSphere следует понимать, какими возможностями обладают си-стемы хранения Fibre Channel, iSCSI и NFS относительно ESX(i). Есть нюансы,которые необходимо знать для планирования и начала работы с системой хране-ния того или иного типа. Это возможности и настройки multipathing, программ-ный инициатор iSCSI, нюансы адресации SCSI. ESX(i) размещает виртуальные машины на своей собственной файловой си-стеме VMFS. В этой главе приводится подробная информация по нюансам, воз-можностям и ограничениям этой файловой системы. Глава 4. Расширенные настройки, профили настроек и безопасность. До-статочно важной темой является безопасность. В данной главе описываются ос-новные аспекты обеспечения безопасности виртуальной инфраструктуры. Приво-дится процедура настройки брандмауэра, описывается модель контроля доступа ираздачи прав. Также приводится основная информация касательно сертификатови их установки для ESX(i), vCenter Server и Update Manager. Отдельным подразделом описывается механизм Host Profiles, задачами кото-рого являются тиражирование настроек и отслеживание соответствия назначен-ному профилю настроек для серверов ESX(i). Глава 5. Виртуальные машины. В данной главе приводится вся информа-ция о виртуальных машинах. Способы их создания, в первую очередь механизмыvCenter для работы с шаблонами и клонирования. Подробная информация о вир-туальном оборудовании, его возможностях и ограничениях. Особенно подробноразбираются возможности виртуальных дисков, в частности thin provisioning. Виртуальная машина – это набор файлов. Разумеется, в этой главе есть от-дельный раздел, посвященный описанию того, из каких файлов состоит виртуаль-ная машина.
    • 10 Введение Приводятся список доступных для виртуальной машины настроек и их описа-ние. Дается подробная информация о том, что такое снимки состояния виртуаль-ной машины и в каких ситуациях ими стоит пользоваться, а в каких – избегать. Глава 6. Управление ресурсами сервера. Мониторинг достаточности ресур-сов. Живая миграция ВМ. Кластер DRS. В этой главе подробно рассматривается потребление ресурсов инфраструкту-ры, притом со всевозможных сторон. Сильной стороной продуктов vSphere являются очень гибкие возможности поработе с ресурсами. Притом существуют как механизмы эффективной утилиза-ции и перераспределения ресурсов одного сервера, так и возможность создать кла-стер DRS, который будет балансировать нагрузку между серверами ESX(i) припомощи живой миграции виртуальных машин между ними. У администраторовсуществуют весьма гибкие настройки того, как ESX(i) должен перераспределятьресурсы сервера или серверов. Наконец, vSphere предоставляет весьма гибкиевозможности по анализу текущей ситуации потребления ресурсов и нахождениюузких мест. Все эти темы последовательно и подробно разбираются в данной главе. Глава 7. Защита данных и повышение доступности виртуальных машин. За-щита данных и повышение доступности – это те темы, без обсуждения которыхобойтись невозможно. И для того, и для другого администраторы виртуальнойинфраструктуры могут применять разнообразные средства. В данной главе приводится подробная информация по настройке, использова-нию и нюансам работы с теми средствами повышения доступности, что предлагаеткомпания VMware.Кроме того, разбираются разнообразные решения и подходык резервному копированию. Обратная связь Адрес моей электронной почты – Mikhail.Mikheev@vm4.ru. Смело пишите.
    • ПредисловиеС момента первого чтения курса по VMware ESX Server (еще второй тогда вер-сии) в 2005 году я наблюдаю все более широкий интерес к теме виртуализации.В сентябре 2007 года я начал вести свой блог (http://vm4.ru), с помощью которогоделился новой информацией, особенностями и нюансами работы с виртуальнойинфраструктурой VMware. Этот опыт получился достаточно удачным, росли ипосещаемость блога, и число специалистов, с которыми устанавливался контакт,как онлайн, так и оффлайн. Однако, несмотря на хорошую посещаемость блога ипостоянную переписку с читателями блога и слушателями курсов, я видел, чтосуществует нехватка доступного и полного источника информации по даннойтеме. Так родилась идея написать книгу, которая смогла бы стать как средствомзнакомства с виртуализацией для новичков, так и настольным справочником дляпрофессионалов. Собственно, ее вы и держите в руках, и это уже второе издание,исправленное и дополненное. Я хочу выразить благодарность людям, чьи отзывы помогли мне сделать этукнигу лучше: Артему Проничкину, Роману Хмелевскому, Родиону Тульскому, Андрею Цы-ганку, Виталию Савченко, Владиславу Кирилину, Дмитрию Тиховичу, ДмитриюПрокудину, Антону Жбанкову. Отдельное спасибо хочу выразить моей супругеАнюте, которая была вынуждена делить меня с работой над книгой в течение года.
    • Глава 1. Установка vSphereЭта часть книги посвящена установке VMware vSphere 4, некоторых сопутствую-щих программ и связанным с установкой вопросам. 1.1. Обзор Под vSphere понимаются следующие продукты: VMware ESX(i) и VMwarevCenter Server. «ESX(i)» означает «ESX или ESXi». ESX и ESXi – это гипервизор. Так называется программное обеспечение, со-здающее виртуализацию. Разница между ESXi и ESX подробно раскрывается чутьдалее. В подавляющем большинстве аспектов разницы просто нет, поэтому есливы видите «что-то там ESX(i)...», то понимать это надо как «что-то там ESXi (илиESX)». Я использую первую фразу просто потому, что она короче. Там же, где раз-ница есть, я буду это явно указывать. Какой из этих дистрибутивов использовать,остается на ваш выбор. Свои рекомендации я дам. vCenter Server – это приложение под Windows, являющееся средством цент-рализованного управления виртуальной инфраструктурой, то есть всеми ESX(i),созданными на них сетями, виртуальными машинами и прочим. Под сопутствующими программами в первую очередь понимается разногорода официальное ПО VMware под vSphere: vSphere CLI (Command Line Interface) – удаленная командная строка. Предоставляет централизованный интерфейс командной строки к ESXi и ESX. Командная строка может понадобиться для решения проблем, для автоматизации каких-то действий через сценарии. vSphere CLI доступен в вариантах под Linux и под Windows; vSphere Management Assistant (vMA) – что-то вроде централизованной Service Console. vMA – это Virtual Appliance, то есть готовая к работе вирту- альная машина с Linux, которая в себе содержит разного рода компоненты, призванные упростить некоторые задачи администрирования виртуальной инфраструктуры. Например, в ее состав входит vSphere CLI; VMware Data Recovery – решение VMware для резервного копирования; VMware Consolidated Backup (VCB) – решение для резервного копирова- ния, доставшееся в наследство от VMware Infrastructure 3 (предыдущей версии vSphere). Будет актуально до тех пор, пока VMware Data Protection API не будут в полной мере интегрированы в решения резервного копиро- вания сторонних поставщиков; VMware Converter – эта программа поможет нам получить ВМ из: • другой ВМ, в формате другого продукта VMware, не ESX(i);
    • Установка и начало работы с ESX(i) 13 • другой ВМ, в формате продукта виртуализации другого производителя; • другой ВМ, в формате ESX. Это может потребоваться для удобного из- менения некоторых свойств этой ВМ. Например, для уменьшения раз- мера ее диска; • образа диска, снятого с физического сервера. Поддерживаются образы, созданные при помощи Norton Ghost, Symantec LiveState, Symantec Back- up Exec System Recovery, StorageCraft ShadowProtect, Acronis True Image; • резервной копии ВМ, полученной с помощью VCB; • наконец, из физического сервера. То есть осуществить его миграцию в ВМ. Такой процесс часто называют p2v – physical to virtual. (По ана- логии существуют процессы v2v – первые три пункта этого списка – и v2p – для миграции с виртуальных машин на физические. Средств последнего рода VMware не предоставляет); vCenter Update Manager – утилита для удобного обновления ESX(i), госте- вых ОС и приложений в гостевых ОС. Также упомяну про некоторые сторонние продукты и утилиты, которые ка-жутся интересными лично мне. Наконец приведу соображения по сайзингу – подбору конфигурации сервера(и не только, еще коснемся СХД). У vSphere существуют несколько вариантов лицензирования, в том числе бес-платная лицензия для ESXi. В книге я рассказываю про все существующие функ-ции, так что делайте поправку на ограничения используемой вами лицензии. Иногда я буду упоминать как первоисточник информации документацию вобщем, или конкретные документы. Подборка пяти основных источников инфор-мации доступна по ссылке http://www.vm4.ru/2010/11/vsphere.html. 1.2. Установка и начало работы с ESX(i) Здесь мы поговорим про требования к оборудованию и дистрибутивы – этимивопросами следует озаботиться до установки как таковой. Далее разберем важныешаги установки ESX(i), начало работы. Затем – более сложные варианты установ-ки: обновление с предыдущих версий и автоматическую установку ESX. ESX(i) – это операционная система. Установка ее мало чем отличается от уста-новки других ОС, разве что своей простотой – вследствие узкой специализацииэтой ОС. Тем не менее на некоторые моменты обратить внимание стоит. 1.2.1. Чем отличаются ESX и ESXi Перед тем как говорить про различия в установке, поговорим о различиях во-обще. Их немного. ESX состоит из двух основных компонентов – гипервизора и Linux.
    • 14 Установка vSphere Гипервизор – это написанный программистами VMware компонент, которыйи «делает» виртуализацию. Его еще называют «VMkernel». Linux – это сокращенный Red Hat Enterprise Linux. «Сокращенность» заклю-чается в удалении всех не нужных для ESX компонентов. Например, нет сервераFTP. Этот Linux используется для получения локального интерфейса команднойстроки, в нем работают службы типа веб-сервера для веб-интерфейса ESX, и естьвозможность запустить в нем какие-то сторонние приложения. Что имеет смыслустанавливать в этот Linux (его, кстати, называют Service Console, SC) – так этоагенты мониторинга оборудования, агенты резервного копирования, программынастройки оборудования, модули стороннего ПО, интегрирующиеся с vSphere.Если вы планируете использовать какое-то подобное решение, то изучите его со-вместимость с «i» версией ESX. ESXi состоит из тех же двух компонентов – тот же самый гипервизор и Linux.Но Linux чертовски маленький (дистрибутив называется Busybox), функций ло-кально практически никаких не позволяющий. Зато без большого Linux весь ESXiпомещается буквально в несколько десятков мегабайт, а не в 1,5 гигабайта, как ESX.(Для установки на диск ESXi требует от 1 Гб свободного места, ESX – от 10 Гб). Вытекающие отсюда различия в следующем: с точки зрения функционалавиртуализации, разницы, использовать ESX или ESXi, нет. Все функции, включаяvMotion, Fault Tolerance, DRS, работать будут. У ESX есть еще и Linux – туда можем что-нибудь установить, получить при-вычную (для тех из вас, кто имеет опыт работы с Linux) командную строку. Темне менее получить интерфейс командной строки возможно и для ESXi. А еслиучесть, что VMware настоятельно рекомендует использовать средства удаленнойкомандной строки (в первую очередь это vSphere CLI, сами по себе или в составеvMA), то становится очевидно – разницы между ESX и ESXi нет и с точки зренияуправления из командной строки. Плюс к тому, для кого-то из вас вероятно желание использовать в качествеязыка сценариев PowerShell, потому что это удобно. Такая возможность есть,VMware выпустила VMware PowerCLI – набор командлетов (cmd-let) для управ-ления виртуальной инфраструктурой через PowerShell. С ее помощью (так же, каки с помощью vSphere CLI) можно управлять и ESX, и ESXi, и даже vCenter. В ESXi нет среды для запуска веб-сервера, как на ESX. Поэтому для доступак виртуальным машинам, работающим на ESXi, невозможно использовать веб-интерфейс (если у вас нет vCenter. Если vCenter есть, то к виртуальным машинамна ESXi можно обращаться через веб-интерфейс сервера vCenter). Зато с «i»-версией, при прочих равных: локально нельзя установить ничего. Часто устанавливать что-то на ESXi необходимости нет – а с точки зрения безопасности и надежности работы, это несомненный плюс. Чем проще, чем меньше программ и функций со- держит ОС (а ESXi это ОС, точно так же, как и ESX), тем надежнее; в качестве диска под сам ESXi можно использовать флэш-накопитель USB. За счет этого удобно распределять данные операционной системы сервера (ESXi) и данные виртуальных машин по разным хранилищам;
    • Установка и начало работы с ESX(i) 15 возможна организация загрузки ESXi по PXE. Разве что на момент напи- сания эта функция и реализующий ее бесплатный продукт VMware Auto Deploy находятся в экспериментальном статусе; можно приобрести сервер, в который флэшка с ESXi уже встроена, и про- пустить, таким образом, этап установки. Возвращаясь к установке: ESX почти на целый Linux больше, чем ESXi. И это означает, что этот Linuxтоже надо установить. Отсюда растут ноги у различий в процессе установки. Да-лее я опишу процесс установки, упоминая о различиях в этом процессе для «i»- ине «i»-версий продукта. 1.2.2. До установки Перед разговором об установке ESX(i) имеет смысл поговорить об оборудова-нии, на котором он будет работать. Первое – неплохо, если ESX(i) будет поддерживать это оборудование. Этогарантирует наличие драйверов и возможность обращаться за поддержкой в слу-чае возникновения проблем. На сайте VMware легко находятся HCG – HardwareCompatibility Guides, списки совместимости (http://vmware.com/go/hcl). Такихсписков несколько: 1. System CG – перечисление поддерживаемых моделей серверов. 2. I/O CG – список поддерживаемых контроллеров. 3. SAN CG – список поддерживаемых систем хранения. Большая часть «брендового» оборудования в этих списках присутствует,проблемы обычно возникают при желании сэкономить. Кроме того, в Интернетеможно отыскать неофициальные списки совместимости. Они не могут повлиятьна поддержку производителя, но помогут не выбрать заведомо несовместимыекомпоненты. Основная проблема – в поддержке дискового контроллера. Здесь надо иметьв виду: сам ESX(i) 4 можно установить на разнообразные контроллеры ATA,SATA, SAS и SCSI, а также HBA FC и iSCSI. Заметьте, не «на любые», а на «раз-нообразные». Список поддерживаемых легко найти в документе «Getting Startedwith ESX 4». Однако использовать дисковые ресурсы для работы ВМ можно на более огра-ниченном количестве моделей контроллеров. То есть возможна ситуация, когда увас сам ESX установлен на локальные диски сервера, подключенные к дешевомуи/или встроенному контроллеру. Но оставшееся свободным место на этих дис-ках задействовать под ВМ не получится. Так что поддержка контроллеров ATAи SATA, появившаяся и расширившаяся в ESX(i) 4, не означает, что ими можноограничиться. В большинстве случаев при использовании встроенных контроллеров ESX(i) за-работает с ними как с дисковыми контроллерами, но не как с контроллерами RAID. Вывод: читайте внимательно списки совместимости и руководства для начи-нающих. Или заранее пробуйте, если образец комплектующих есть под рукой.
    • 16 Установка vSphere Я не привожу конкретных списков лишь потому, что такие списки имеют обык-новение меняться с выходом обновлений ESX(i). Напомню, что искать следует поадресу http://vmware.com/go/hcl. Особняком стоит возможность установить ESXi на флэш-накопитель. Такойвариант интересен тем, что все место на дисках мы отводим под виртуальные ма-шины, сама ОС (ESXi) установлена отдельно. Локальных дисков вообще можетне быть – достаточно флэш-накопителя. Еще такой вариант иногда интересен дляобслуживания удаленных площадок. При необходимости установить там серверыESXi можно: вначале установить ESXi локально на накопитель USB (в ВМ подуправлением VMware Workstation или Player), а затем отправить на удаленнуюплощадку лишь флэшку с установленным и настроенным ESXi. Перед тем как устанавливать ESX(i) на сервер, имеет смысл обновить всевоз-можные BIOS и firmware сервера и всех контроллеров. Это действительно можетпомочь решить (или избежать) проблем. В идеале, конечно, имеет смысл обра-титься на сайт производителя сервера и посмотреть – вдруг есть рекомендации ис-пользовать (или ни в коем случае не использовать) какую-то конкретную версиюпрошивки под вашу версию ESX(i). Еще один небольшой совет: в моей практике были ситуации, когда на вродебы совместимом сервере ESX(i) работал не так, как ожидалось (на этапе установ-ки в том числе). Несколько раз в таких ситуациях помогал сброс настроек BIOSна значения по умолчанию. Иногда помогал только аппаратный сброс настроек,перестановкой джамперов. Еще несколько слов следует сказать про процессор. Если мы хотим использоватьна сервере ESX(i) 4, то процессоры этого сервера должны быть 64-битными (x86-64).Это неактуально для новых серверов (последние года три, если не больше, все илипочти все процессоры Intel и AMD поддерживают работу в 64-битном режиме), ноесли вы планируете задействовать какой-то сервер в возрасте – этот момент необхо-димо учесть. Проверить 64-битность процессора можно несколькими путями: узнать его модель и посмотреть описание на сайте производителя; попробовать запустить на этом сервере установку – если процессор не под- ходит, установщик сообщит нам об этом; наконец, с сайта VMware можно загрузить небольшую утилиту под на- званием CPU Identification Utility. Найти ее можно в разделе Download ⇒ Drivers and tools. Эта утилита сообщит вам о возможности работы про- цессора в 64-битном режиме, поможет узнать, совместимы ли процессоры нескольких серверов для vMotion, о поддержке EVC (Enhanced vMotion Compatibility). Кроме 64-битного режима, процессоры могут обладать аппаратной поддерж-кой виртуализации – Intel-VT или AMD-V. Она является необходимой для за-пуска 64-битных гостевых ОС. Небольшой нюанс здесь в следующем: поддержкаэтой функции включается и выключается в BIOS сервера, так что возможна ситу-ация, когда процессор ее поддерживает, но запустить 64-битную ВМ вы не можетеиз-за того, что эта функция выключена. Разные производители в разных BIOS на-зывают ее по-разному. Обычно «Hardware Virtualization», «Intel-VT», «AMD-V».
    • Установка и начало работы с ESX(i) 17 Проверить состояние аппаратной поддержки виртуализации можно, выпол-нив в локальной командной строке ESX командуesxcfg-info | grep HV Выводы интерпретируются следующим образом: 0 – поддержка Intel VT / AMD-V недоступна на данном сервере; 1 – технология Intel VT / AMD-V доступна, но не поддерживается на дан- ном сервере; 2 – поддержка Intel VT / AMD-V доступна для использования, но не вклю- чена в BIOS; 3 – поддержка Intel VT / AMD-V включена в BIOS и доступна для исполь- зования. Еще нюанс: для функции VMware Fault Tolerance необходимы процессоры изсписка http://kb.vmware.com/kb/1008027. Далее для Fault Tolerance и vMotion не-обходимо, чтобы набор поддерживаемых процессорами инструкций был одинаковдля серверов, между которыми мы хотим использовать эти функции. Более под-робно эти вопросы будут разобраны в разделе, посвященном сайзингу. Варианты дистрибутивов Правильное место для обзаведения дистрибутивами продуктов – сайтVMware. Доступ к ним можно получить после бесплатной регистрации. Ссылкина загрузку придут на указанный адрес электронной почты. Эти дистрибутивы полнофункциональны, то есть никаких ограничений посроку действия в дистрибутив как таковой не встроено. Однако для того, чтобыхоть что-то заработало, нам потребуется лицензия. Это означает, что без лицензиидля ESX(i) у вас все установится и почти все настроится (кроме функций, требу-ющих отдельных лицензий, типа DRS). Вы сможете создать и настроить ВМ наESX(i) без действующей лицензии – но не сможете эти ВМ включить. Для ознакомительных и демонстрационных целей можно воспользоватьсявременной лицензией. Она «встроена» в дистрибутив как ESX(i), так и vCenter.Это означает, что для ESX(i) или vCenter можно указать тип лицензии «Evalu-ation». И 60 дней абсолютно все функции будут работать (как если бы к этимпродуктам была применена максимальная лицензия Enterprise Plus). По истече-нии этих 60 дней необходимо указать купленную лицензию или переустановитьESX(i) или vCenter (они лицензируются независимо друг от друга). VMware выделяет несколько функций, которые требуют наличия лицензий.Самая базовая из них – включение ВМ. Остальные – это разного рода функции.Общее представление можно получить на официальном сайте (или подборка ссы-лок вот тут: http://www.vm4.ru/2010/10/vsphere-licensing.html). Еще одна небольшая тонкость, касающаяся ESXi. C сайта вы можете загрузить«Installable» версию ESXi, которая предназначена для установки на HDDLUNFlash. Но еще один вариант – приобрести сервер со встроенной флэшкой или от-дельно флэш-накопитель, где ESXi уже установлен. Такой вариант называется«ESXi Embedded».
    • 18 Установка vSphere При выборе между вариантами Installable и Embedded (то есть между уста-новкой ESXi на HDDLUNфлэш-накопитель или готовый флэш-накопитель)ориентируйтесь на свои вкусы и привычки. Хочу акцентировать ваше внимание на то, что версия Installable устанавли-вается не только на локальные диски, но и на флэш-накопитель или USB-HDD.Также из версии Installable можно самостоятельно извлечь образ, который затемзалить на флэшку и загружать ESXi с нее. Последний вариант является офици-ально не поддерживаемой конфигурацией. Но с его помощью можно подготовитьзагрузочную флэшку, даже если целевой сервер недоступен (подробности можнонайти по ссылке http://www.vm4.ru/2010/01/all-about-esxi.html). Еще одной не поддерживаемой на данный момент конфигурацией являетсязагрузка ESXi по PXE. Так как возможность официально не поддерживается, ука-жу лишь ссылку на информацию: http://www.vm4.ru/2010/08/auto-deploy.html. Последний нюанс – в списке дистрибутивов на сайте VMware или на сайтахтаких производителей оборудования, как Dell, IBM и HP, можно найти что-то вро-де «ESXi HP (IBM, DELL и прочее) Edition». Кратко это означает сборку ESXi,в которую входят нестандартные CIM Provider – компоненты, предоставляющиеинтерфейс для мониторинга оборудования серверов конкретного производителя.Благодаря этому данных мониторинга будет больше, чем если на сервере будетустановлена обычная версия ESXi от VMware, и эти данные могут быть собраныцентральным сервером управления и мониторинга оборудования (если таковойиспользуется в вашей инфраструктуре). 1.2.3. Установка ESXi ESX – это операционная система. Установка ее мало чем отличается от уста-новки других ОС, разве что своей простотой – вследствие узкоспециализирован-ности ESX. Тем не менее на некоторые моменты обратить внимание стоит. Для установки ESXi вам потребуются диск с дистрибутивом и доступ к ло-кальной консоли сервера. Загружаем сервер с этого диска, запускается мастер установки. Вопросов онзадаст всего ничего. Первый из них – это выбор диска, на который будем инсталлировать ESXi.Проблема здесь может возникнуть в том случае, если инсталлятору видно большеодного диска/LUN. Такое обычно происходит в инфраструктурах покрупнее, ког-да сервер, на который мы устанавливаем ESX(i), подключен к системе храненияданных, СХД. В силу условий работы vMotion и других функций vSphere частьLUN системы хранения должна быть доступна всем серверам – см. рис. 1.1. СХД используется несколькими серверами ESX(i) и сервером Windows.Притом в некоторых ситуациях мы вынуждены будем сделать так, что серверамESX(i) будут доступны все четыре LUN с этой СХД – даже тот, с которым ра-ботает физический Windows-сервер. Например, такая конфигурация потребует-ся, если используется отказоустойчивый кластер Майкрософт в конфигурацииphysical-2-virtual. Таким образом, при установке ESX(i) на один из этих серверов
    • Установка и начало работы с ESX(i) 19 Рис. 1.1. Схема использования СХД несколькими серверамион увидит все четыре LUN (а еще и локальные диски сервера, если они есть) –и минимум один (тот, который используется Windows-сервером) инсталляторупокажется пустым. Так вот, если инсталлятору ESXi доступны несколько дисков, то не всегда бы-вает тривиально на этапе установки определить, на какой же из них нам необхо-димо проинсталлировать ESXi, а на какой/какие ставить нельзя, потому что эторазрушит данные на них, а нам оторвут за это голову. Обратите внимание: ESXi наэтом этапе покажет нам физический адрес устройства – вида «vmhba0:C0:T0:L0».Последняя цифра здесь – номер LUN, по которому, как правило, и можно сориен-тироваться. Порядок именования контроллеров (vmhba#) зависит от порядка, в которомстоят контроллеры в сервере, от настроек BIOS. Поэтому полагаться на порядок,в котором поименованы контроллеры, нельзя – далеко не факт, что локальныеконтроллеры будут в списке раньше контроллеров для доступа на СХД. В итоге проблема в том, что по ошибке мы можем выбрать диск, на которомуже лежат данные, и эти данные затереть. Эта проблема актуальна в подавляющем большинстве случаев, если мы ис-пользуем внешнюю СХД. Отсюда вывод:
    • 20 Установка vSphere Если доступных для ESXi дисков/LUN мало и мы гарантированно отличимпредназначенный для установки – просто устанавливаем на него ESXi. Иначе лучше подстраховаться. Если у нас внешняя СХД и слова «зонирова-ние» и «маскировка» (zoning, LUN masking/presentation) нам ни о чем не говорят,то надежнее физически отключить сервер от всех LUN, кроме того одного, на ко-торый будем устанавливать ESX(i). Если маскировку мы используем, то можно с ее помощью спрятать все LUN,кроме нужного, на время установки. Есть пара нюансов, связанных с дисковой подсистемой: для файловой системы VMFS нельзя использовать диски/LUN размером более 2 Тб минус 512 байт, однако надежнее ограничиваться размером од- ного LUN порядка 1,8–1,9 Тб; установщик создает VMFS по умолчанию с размером блока в 1 Мб. Это означает, что на созданном по умолчанию разделе VMFS не получится соз- дать виртуальную машину с файлом-диском больше 256 Гб. Если вам необ- ходимо размещать ВМ с диском большего размера на создаваемом по умол- чанию разделе VMFS, то воспользуйтесь установкой ESX с файлом ответов, в котором можно будет указать необходимый размер блока для VMFS (под- робности см.: http://www.vm4.ru/2010/06/default-vmfs-block-size.html). Сразу после установки ESXi необходимо настроить сеть. Делается это оченьпросто: нажимаем F2, попадаем в меню а-ля BIOS. Нам нужен пункт ConfigureManagement Network. Там выставляем правильные настройки IP, DNS-имя и до-мен. Но самое главное – нам нужен пункт Network Adapters, в котором мы вы-берем один сетевой контроллер, через который будет выходить наружу управляю-щий интерфейс ESXi (рис. 1.2). Рис. 1.2. Выбор контроллера для сети управления ESXi
    • Установка и начало работы с ESX(i) 21 Ошибиться мы можем, в случае если в сервере несколько сетевых карт и онисмотрят в разные сети, – см. рис. 1.3. Рис. 1.3. Схема подключения физических сетевых контроллеров ESX(i) к разным сетям Нам необходимо выбрать тот физический сетевой контроллер (они именуют-ся vmnic#), который ведет в сеть управления. На рис. 1.3 я изобразил, что в этойсети находится ноутбук – с которого, предполагается, вы будете управлять ESX(i).Или в этой сети находится vCenter, через который вы будете управлять ESX(i). VLAN – если вы не знаете, зачем нужен этот механизм, то проконсультируй-тесь со специалистами, которые обслуживают вашу сеть. Если VLAN вам не нуж-ны, то ничего не вводите в соответствующее поле. Немного теории про VLAN бу-дет дано в посвященном сетям разделе. На свежеустановленном ESXi пароль root пустой. Лучше бы его задать: 1. Выбрать Configure root password. 2. Указать новый пароль. Далее переходите к разделу Начало работы. 1.2.4. Установка ESX ESX устанавливается с чуть большим количеством вопросов, нежели ESXi. Самое первое, о чем нас спросят, – какой тип установки выбрать. Варианты«Scripted Install что-то там дальше» мы рассмотрим чуть далее, в разделе про ав-томатическую установку. Сейчас коснемся первых двух вариантов: «Install ESX
    • 22 Установка vSpherein graphical mode» и «Install ESX in text mode». Первый – вариант по умолчанию,и он сам запустится через 30 секунд. Второй отличается от него лишь тем, чтоустановщик будет вам показывать не красивые картинки, на которых привычнонадо жать Next, Next, а меню, отображаемые текстом. А нам нужно будет выбиратьнужные пункты нажатием цифр 1, 2, 3. Но сами пункты будут теми же самыми.Нужен режим текстовой установки в случае, если вы устанавливаете сервер уда-ленно, пользуясь средствами типа HP iLO, Fujitsu iRMC, IBM RSA, Dell DRACили коммутатора IP KVM. В случае текстовой установки по сети будет переда-ваться намного меньше информации – это весомый плюс для тонких каналов.Я буду описывать установку графическую – но вся разница с текстовой будет со-стоять, например, в том, что надо читать не «вызовите выпадающее меню и выбери-те нужный контроллер», а «нажмите 2 – Change и выберите нужный контроллер». Язык оставляем по умолчанию – английский. Русский нам не понадобится. Принимаем лицензионное соглашение. Важный вопрос – будем ли мы использовать дополнительные драйверы. Мо-жет быть, драйверов для вашего оборудования не окажется в дистрибутиве. В этомслучае найти драйверы можно будет на сайте VMware или на сайте производите-ля контроллера (это справедливо для устройств, поддерживаемых официально).Если мы не будем указывать дополнительные драйверы на этом этапе, то следую-щим шагом будет подтверждение загрузки стандартного набора драйверов. Дальше будет вопрос по ключ продукта. Сейчас его можно не вводить – тогдаESX будет установлен в режиме «Evaluation», то есть ознакомительном. В этомрежиме ESX абсолютно полнофункционален, но работать будет лишь 60 днейс момента установки – после чего потребуется или все-таки ввод ключа продукта,или переустановка. Следующий шаг потенциально проблемный – выбор сетевого контроллерадля управления. Мы выбираем тот контроллер, через который будет выходитьв сеть управляющий интерфейс ESX. Ошибиться мы можем, в случае если в сервере несколько сетевых карт и онисмотрят в разные сети, – см. рис. 1.3. Нам необходимо выбрать тот физический сетевой контроллер (они именуют-ся vmnic#), который ведет в сеть управления. На рис. 1.3 я изобразил, что в этойсети находится ноутбук, с которого, предполагается, вы будете управлять ESX(i).Или в этой сети находится vCenter, через который вы будете управлять ESX(i). Вызовем выпадающее меню в графическом режиме (рис. 1.4) и выберем нуж-ный нам контроллер. Ориентироваться можно по его статусу (подключен или неподключен), по названию драйвера (если сетевые карты в сервере используютразные драйверы) и по MAC-адресу. Если ошиблись, затем можно поправить че-рез локальную командную строку. Для этого обратитесь к разделу, посвященномукомандной строке. VLAN – если вы не знаете, зачем нужен этот механизм, то проконсультируй-тесь со специалистами, которые обслуживают вашу сеть. Если VLAN вам не нуж-ны, то ничего не вводите в соответствующее поле. Немного теории про VLAN бу-дет дано в посвященном сетям разделе.
    • Установка и начало работы с ESX(i) 23 Рис. 1.4. Выбор сетевого контроллера для управления ESX Дальше – самый, наверное, важный шаг. Важный, потому что потенциальноопасный. Итак, нам необходимо выбрать диск, на который будем устанавливать ESX. Для начала нас спросят, хотим ли мы по-простому установить ESX на одинкакой-то диск или вручную указать, каким разделам где лежать. В любом случае нам нужно будет выбрать диск, на который хотим устанавли-вать. Соображения здесь следующие. Установщик может увидеть несколько дисков. Такое обычно происходит в инф-раструктурах покрупнее, когда сервер, на который мы устанавливаем ESX(i), под-ключен к системе хранения данных, СХД. В силу условий работы vMotion и дру-гих функций vSphere часть LUN системы хранения должна быть доступна всемсерверам. См. рис. 1.1 – СХД используется несколькими серверами ESX и сер-вером Windows. Притом в некоторых ситуациях серверам ESX будут видны всечетыре LUN, доступных на этой СХД, – даже тот, с которым работает физическийWindows-сервер (например, если используется отказоустойчивый кластер Май-крософт в конфигурации physical-2-virtual). Таким образом, при установке ESX(i)на один из этих серверов он увидит все четыре LUN (и локальные диски сервера,если они есть) – и минимум один (тот, который используется Windows-сервером)инсталлятору покажется пустым. К счастью, в отличие от установщика ESX 3, установщик ESX 4 показываетнам физический адрес LUN. Например, такой: «vmhba0:C0:T0:L0». Последняяцифра здесь – номер LUN. А первая – номер контроллера, через который серверработает с этим LUN.
    • 24 Установка vSphere Так вот, ваша задача – выбрать именно тот диск, на который планируется уста-новить ESX. В случае ошибки и выбора для установки уже используемого диска(например, диска, с которым работает сервер Windows на рис. 1.1) вся информацияна нем будет уничтожена. Единственное исключение – если переустанавливать ESXповерх ESX, то мастер установки предложит оставить нетронутым раздел VMFS, тоесть все виртуальные машины на том диске, куда устанавливаем ESX (рис. 1.5). Рис. 1.5. Уведомление о существующем разделе VMFS на диске для установки Еще один связанный с дисками нюанс: диск, на который мы будем устанавли-вать ESX(i), может находиться на контроллере локальных дисков, на контроллереFibre Channel или iSCSI (FC или iSCSI HBA, Host Bus Adapter). Так вот, для тогочтобы загрузить сервер с диска/LUN на внешней СХД, может потребоваться из-менить настройки BIOS сервера, связанные с процедурой загрузки (Boot): 1. С точки зрения BIOS сервера, контроллер HBA (FC или iSCSI) должен стоять в списке дисковых контроллеров первым. 2. Для того чтобы контроллер мог выступать загрузочным, необходима его активация на этапе загрузки сервера. С точки зрения BIOS, это означает примерно следующее: разъем PCI, в котором стоит этот контроллер, дол- жен быть просканирован на наличие загрузочного микрокода – BIOS кон- троллера. В некоторых серверах такая возможность называется «Option Rom Scan». Для разъема, в котором стоит контроллер, она должна быть включена, то есть выставлена в положение «Yes».
    • Установка и начало работы с ESX(i) 25 3. Может потребоваться настройка в BIOS самого контроллера. В случае выбора «Standard Setup» указываем диск для установки – и все. Дискдолжен быть размером как минимум 8,5 Гб. На нем будут созданы разделы, не-обходимые для гипервизора: «/boot» и «/vmcore», в сумме примерно 1250 Мб. Наоставшемся месте будет создан раздел, отформатированный в файловую системуVMFS, и на нем будет создан файл «esxconsole.vmdk» – виртуальный диск, со-держащий Service Console. То есть, в отличие от ESX 3, Service Console в ESX 4 неимеет своих разделов на диске. «/» (root), «/swap» и прочие разделы SC находятсявнутри этого виртуального диска. А если вы выберете вариант «Advanced Setup», то вам предложат выбрать, гдесоздать хранилище VMFS под файл виртуального диска Service Console. Либоможно будет выбрать уже существующее хранилище VMFS. Этот вариант нужентогда, когда сам ESX мы хотим установить на один диск/LUN, а esxconsole.vmdk,виртуальный диск SC – разместить на другом диске/LUN. В таком случае на за-грузочном диске будут только разделы «/boot» и «/vmcore». Обратите внимание. Загрузочный LUN должен быть доступен только тому одному серверу, который с него загружается. Далее можно будет выбрать, какие разделы создаем для Service Console. Поумолчанию это раздел под виртуальную память «/swap», раздел «/» и «/var/log».Напомню, что располагаются эти разделы внутри vmdk-файла из предыдущегопункта. Почему нам может захотеться менять схему разделов, предлагаемую по умол-чанию? Потому что по умолчанию все данные SC будут попадать на раздел «/».И если на нем закончится место, ESX может остановиться или начать работатьнестабильно (например, описаны случаи, когда недостаточно качественно напи-санный агент мониторинга оборудования генерировал несколько гигабайт фай-лов журналов). Для того чтобы свести эту вероятность к минимуму, будет целе-сообразно создать отдельные разделы под те каталоги, которые могут заниматьмного места. Таким образом, добавить нам стоит все или часть из следующих раз-делов: «/», читается как «root» – корневой раздел. Без него не обойтись, размер его – от 5 Гб до 10 Гб (5 Гб нормально, когда созданы дополнительные раз- делы, о которых ниже); «/swap» – под виртуальную память Service Console. Делаем размером в 1600 Мб – лишних нескольких сотен мегабайт нам не жалко, зато вероят- ность того, что SC не хватит памяти, мы сводим к минимуму; «/home», ориентировочный размер от 512 Мб. По этому пути хранятся про- фили и данные пользователей Service Console. Правда, вряд ли вам потре- буется заводить пользователей для мало-мальски регулярной работы в SC. Однако на случай если вы будете их создавать, наличие отдельного раздела «/home» – это правильно; «/tmp», 2048 Мб – для хранения временных файлов;
    • 26 Установка vSphere «/opt» – аналог «Program Files» в Windows. Если планируем устанавливать какие-то приложения в SC, то лучше будет создать отдельный раздел под «/opt», опять же чтобы минимизировать риск нехватки места на корневом разделе; «/var/log», 2048 Мб – предлагается по умолчанию в режиме графической и текстовой установки. Рекомендуется точкой монтирования указать даже не «/var/log», а «/var» целиком. Еще рекомендуется увеличить размер это- го раздела на 512 Мб в случае использования автоматической установки; «/vmimages» – в этот каталог можно класть образы iso, и они станут доступ- ны для подключения к ВМ. Для хранения этих образов обычно использу- ются другие места для хранения iso (NAS или SAN) – так как образы с них можно использовать на любом из подключенных серверов ESX(i). Однако если вы планируете размещать образы iso локально на ESX или опасаетесь, что это может быть сделано по ошибке, создайте под «/vmimages» отдель- ный раздел. Обратите внимание: изменять размер разделов ESX («/boot» и «/vmcore»),а также раздела VMFS вы не можете из графического или текстового режимаустановки. Но размеры можно указать произвольные при установке с файлом от-ветов – см. соответствующую главу. Однако причин изменять размеры этих раз-делов, в общем случае, нет. Есть нюанс, связанный с создаваемым по умолчанию разделом VMFS. Уста-новщик создает VMFS по умолчанию, с размером блока в 1 Мб. Это означает, чтона созданном по умолчанию разделе VMFS не получится создать виртуальнуюмашину с файлом-диском больше 256 Гб. Если вам необходимо размещать ВМс диском большего размера на создаваемом по умолчанию разделе VMFS, то оз-накомьтесь со статьей базы знаний VMware № 1012683 (http://kb.vmware.com/kb/1012683). На следующем шаге мастера установки ESX укажем часовой пояс и настройкивремени – вручную или через сервер NTP. Затем укажем пароль для root и создадим еще одного пользователя. Он нампонадобится в случае обращения к ESX по SSH. Идея в том, чтобы авторизоватьсяпод непривилегированным пользователем и лишь потом, при необходимости, под-нять свои привилегии до root. Это правильно с точки зрения безопасности, и наESX по умолчанию запрещено подключаться по SSH пользователем root. Поэтомуавторизоваться по SSH пользователем root без дополнительных телодвижений неудастся. Далее переходите к разделу «Начало работы». 1.2.5. Автоматическая установка ESX ESX всегда можно было установить автоматически, используя файл ответов.По-английски это называется «Scripted install with kickstart file». Файл ответов для ESX очень напоминает оный для Red Hat – но между собойони не совместимы. В файле ответов для ESX есть как секции от Red Hat, так и
    • Установка и начало работы с ESX(i) 27секции от VMware. Все параметры, которые мы можем указать в файле ответов,перечислены и описаны в документе «ESX and vCenter Server Installation Guide».Здесь я укажу лишь самые интересные, на мой взгляд, возможности автоматиче-ской установки, чтобы вы могли понять, нужна она вам или нет. Файл ответов для автоматизации установки ESX можно взять из несколькихисточников: после установки ESX в интерактивном режиме на нем автоматически создается файл /root/ks.cfg, в котором содержатся те ответы на вопросы установщика, которые вы давали по ходу установки данного сервера ESX. Данный файл хорошо подходит для такой же переустановки ESX на этот сервер – в каком-то роде резервная копия. Еще – как основа для создания универсального файла ответов; в дистрибутив ESX входят два готовых файла ответов с настройками по умолчанию; создать файл ответов самостоятельно с самого начала или взяв за основу вариант из Интернета. Чтобы задействовать существующие по умолчанию файлы ответов, выберитесоответствующий пункт в первом меню установщика ESX (рис. 1.6). Рис. 1.6. Выбор типа установки ESX Если выбрать ESX Scripted Install to first disk, то установка без лишних во-просов будет произведена на первый из дисков сервера, с сохранением на нем раз-дела VMFS и виртуальных машин. Имя этого файла ответов – ks-first-safe.cfg. Для автоматической установки на первый диск без сохранения раздела VMFSвыберите ESX Scripted Install to first disk (overwrite VMFS). Имя этого файлаответов – ks-first.cfg.
    • 28 Установка vSphere Пароль пользователя root будет «mypassword». Дальнейшая настройка ESXдолжна проводиться с помощью клиента vSphere. При создании произвольного файла ответов один файл может использоватьсядля установки ESX на разные серверы, даже различной конфигурации. В сетевыхнастройках необходимо будет указать использование DHCP. Мы можем указатьправила выбора дисков для установки. Например: устанавливать ESX на первыйиз локальных дисков, а если локальных установщик не найдет – на первый из уда-ленных. Можем указать модели дисков и их приоритет при выборе для установкина них ESX. Можем указать источник дистрибутива. Им может быть локальный DVD-ROM, накопитель USB с дистрибутивом или образом ISO, или ресурс в сети (про-токолы доступа – HTTP, HTTPS, NFS, FTP). В отличие от интерактивной установки, здесь мы можем указать размеры раз-делов, создаваемых для установки ESX (не разделов Service Console, а самого ги-первизора). Кроме того, можно указать произвольный размер блока для создавае-мого установщиком раздела VMFS. На самом деле, по моему мнению, самое важное в автоматической установкеESX – это автоматизировать еще и настройки. Для этого нам пригодится секция«%post» файла ответов. В секции «%post» мы можем указать произвольные команды для исполненияпосле завершения установки ESX – это открывает интересные возможности поавтоматизации еще и любых настроек серверов ESX. Например, если вы хотите прописать на всех серверах какую-нибудь из Ad-vanced Settings, то можно указать это изменение в данной секции, и оно будет вы-полнено сразу после установки ESX. То же самое касается создания виртуальныхкоммутаторов, внесения изменения в любой конфигурационный файл. Баналь-ный пример: вам может потребоваться разрешать имена других серверов ESX нетолько через DNS, но и используя содержимое файла «hosts», – и вот здесь опятьже можно задать необходимое содержание этого файла. Что нужно знать для автоматизации настроек ESX? Можно создать текстовый файл с какими-то командами. Например, при рабо-те в командной строке ESX это можно сделать командойnano script_name Этой командой вы откроете в текстовом редакторе nano файл с именем «script_name», который будет создан, если еще не существует. Создан в том каталоге, гдевы сейчас находитесь, – по умолчанию это домашний каталог вашего пользовате-ля. Сразу первой строкой пропишем обработчик команд:#!/bin/bash Теперь в этом файле мы в строчку можем перечислить команды, и они будутпоследовательно выполнены при выполнении этого сценария. Кроме того, мы мо-жем указать конструкции следующего вида:
    • Установка и начало работы с ESX(i) 29 Command > filename – вывод команды будет записан в файл «filename»; Command >> filename – вывод команды будет добавлен к файлу «filename»; Command < filename – команде подается на вход содержимое файла «file- name»; Command < filename > newfile – «filename» подается на вход, вывод команды пишется в «newfile»; Command << delimiterапрап – на вход подавать следующие за командой стро- ки, пока не встретится строка «delimiter». Сама строка может быть любой – см. примеры. В качестве такого разделителя частенько удобно использо- вать «EOF» – End of file, то есть до конца файла. Пример:#!/bin/bashcat > /etc/resolv.conf << DNS search mydomain.com nameserver <primary_DNS_server> nameserver <secondary_DNS_server> DNS Выход команды cat записывается в файл /etc/resolv.conf. На вход ей подаютсястроки, следующие до строки «DNS», которая является разделителем (delimiter).Вывод команды cat в данном случае – это те строки, что мы даем ей на вход. Навход мы ей даем настройки DNS – имя домена и адреса двух серверов DNS. И этинастройки запишутся в нужный конфигурационный файл сервера ESX. Таким об-разом, эту конструкцию мы применяем всегда, когда в обычный текстовый конфи-гурационный файл нужно записать или добавить какие-то строки. Обратите внимание на то, что команды и их параметры регистрозависимы. Но так можно править не все конфигурационные файлы. Самый важный кон-фигурационный файл ESX – /etc/vmware/esx.conf – напрямую править нельзя,необходимо пользоваться специальными командами. Например, так: Пример 2:#!/bin/bash; Создаем вКоммутатор с именем vSwitch2 и 32 портами.esxcfg-vswitch –a vSwitch2:32; Добавляем на него группу портов с названием vMotion.esxcfg-vswitch –A vMotion vSwitch2; В качестве аплинка для него используем NIC vmnic2.esxcfg-vswitch –L vmnic2 vSwitch2; В группе портов vMotion создаем интерфейс VMkernel и указываем для него сетевые настройки.esxcfg-vmknic –a –i 10.1.72.156 –n 255.255.255.0 vMotion; Настраиваем файрвол Service Console для открытия портов службы ntpClient.esxcfg-firewall –e ntpClient; Изменяем настройки модуля авторизации.esxcfg-auth --passmaxdays=90 --passmindays=30 --passwarnage=15 :
    • 30 Установка vSphere Далее выходим из текстового редактора (в случае nano – комбинацией Ctrl+X),сохраняем файл. Делаем его исполняемым:chmod +x scriptname Теперь запуск этого файла командой./script_nameвыполнит все, указанное нами в этом файле. Только что вы создали сценарий ав-томатической настройки ESX. Таким образом, если в файл script_name вы прописали оба моих примера, то,выполнив его, вы настроите DNS на ESX и создадите виртуальный коммутатор,группу портов vMotion и прочее из второго примера. Теперь у вас есть два варианта использования подобного сценария. Один ва-риант описан только что – простое выполнение на проинсталлированном ESX-сервере. Такой вариант тесно перекликается с функционалом «Host profiles» – мысоздаем один раз нужные настройки (вернее, сценарий, выполняющий нужныенастройки) и простым его выполнением делаем нужные настройки на свежеуста-новленных серверах. Вариант 2 – содержимое этого файла (заранее отлаженное, конечно) мы по-мещаем в секцию «%post» файла ответов, тогда настройки будут выполнены сразупри установке ESX. Единственный нюанс – эти сценарии будут выполнены после установки, но доперезагрузки ESX. В этот момент гипервизор еще не работает – а команды esxcfg-*работают только при запущенном гипервизоре. Таким образом, нам команды, по-добные описанным во втором примере, нужно не выполнять в секции «%post»,а прописать их выполнение при загрузке ESX. Сделать это несложно:cat > /etc/rc.d/rc3.d/S99myconfig << CFGesxcfg-vswitch –a vSwitch2:32esxcfg-vswitch –A vMotion vSwitch2esxcfg-vswitch –L vmnic2 vSwitch2esxcfg-vmknic –a –i 10.1.72.156 –n 255.255.255.0 vMotionesxcfg-route 10.1.137.253esxcfg-firewall –e ntpClientesxcfg-auth --passmaxdays=90 --passmindays=30 --passwarnage=15 CFG Эти строки, прописанные в «%post», создадут сценарий с именем S99myconfig,который выполняется при старте ESX. И команды esxcfg-* выполнятся уже приштатном старте ESX, когда гипервизор будет загружен. Теперь последнее: как же нам передать этот файл ответов установщику ESX?Очень просто – положив его на накопитель USB, на DVD или сделав доступнымпо сети.
    • Установка и начало работы с ESX(i) 31 Для обращения к файлу ответов на USB-накопителе вам необходимо: 1. Отформатировать накопитель в файловую систему EXT2, EXT3 или FAT32. 2. Скопировать на него файл ответов с именем ks.cfg. 3. Выбрать «ESX scripted install using USB ks.cfg». Для обращения к файлу ответов НЕ на USB-накопителе необходимо: 1. Загрузить сервер с дистрибутива ESX. Это можно сделать с локального DVD или по PXE. 2. Курсором (не нажимая Enter) выбрать пункт «Install ESX in graphical mode» или «Install ESX in text mode». Нажать F2. 3. В нижней части экрана появится команда запуска установщика. К ней нуж- но дописать какую-то из следующих опций: • ks=cdrom:/ks.cfg – если файл ответов расположен на CD/DVD, под- ключенном к серверу; • ks=ftp://<path>/ks.cfg – если файл ответов расположен на ftp-сервере; • ks=http://<server>/<path>/ ks.cfg – если файл ответов расположен на сервере HTTP; • ks=nfs://<server>/<path>/ks.cfg – если файл ответов расположен на nfs-сервере; • ks=UUID:<disk-uuid>:/<path>/ks.cfg – если файл ответов расположен на разделе VMFS с известным вам uuid. Обратите внимание на то, что расположение дистрибутива ESX указано в фай-ле ответов. Дистрибутив может располагаться на DVD или сетевом ресурсе. Для того чтобы файл ответов был поистине универсальным, нам следует ре-шить проблему уникальности имен и IP-адресов, если они назначаются статиче-ски. Вариант решения проблемы: в файле ответов мы указываем запуск сценариянастройки, в котором для указания имени и IP-адресов используется переменная.А значение переменной (идентификатор конкретного ESX сервера) мы передаемна этапе запуска установки. Выглядит последовательность действий так (на при-мере файла ответов с USB): 1. Отформатировать накопитель в файловую систему EXT2, EXT3 или FAT32. 2. Скопировать на него файл ответов с именем ks.cfg и файл со сценарием, который надо выполнить после перезагрузки ESX. 3. Загрузить сервер с дистрибутива ESX. Выбрать (не нажимая Enter) «ESX scripted install using USB ks.cfg», нажать F2 и дописать в конец командной строки что-то вроде «ESXID=<номер устанавливаемого ESX>». Предпо- лагается, что переменная ESXID используется в сценарии, и в зависимости от значения переменной устанавливаемому ESX даются уникальное имя и IP-адрес. Пример этой пары файлов вы можете найти на http://www.vm4.ru/2010/10/esx-esxi-kickstart.html. Описанное здесь – лишь малая часть возможностей. Автоматизировать можнопрактически все. С другой стороны, даже описанного здесь достаточно для авто-матизации всех стандартных настроек.
    • 32 Установка vSphere 1.2.6. Автоматическая установка ESXi Начиная с версии 4.1 возможность установки с файлом ответов появилась идля ESXi. Притом, как и для ESX, в состав дистрибутива ESXi входит готовыйфайл ответов. Чтобы задействовать его, следует после загрузки установщика нажать Tab и кпараметрам дописать строку ks=file://etc/vmware/weasel/ks.cfg. В документе VMware ESXi 4.1 Installable and vCenter Server 4.1 Setup Guideприводится информация о возможных параметрах файла ответов. Некоторые примеры и полезные ссылки удобно посмотреть здесь: http://www.vm4.ru/2010/07/esxi-kickstart-file.html. При организации автоматической установки ESXi самое важное – опреде-литься с некоторыми организационными вопросами: это месторасположение фай-ла ответов и дистрибутива ESXi. Один из граничных вариантов, самый простой, – это дистрибутив на CD-ROMили в образе iso и в нем же расположенный файл ответов. Есть способы даже в ме-ню установщика вывести пункты для начала установки с тем или иным файломответов (см. http://www.vm4.ru/2010/09/esxi-kickstart.html и рис. 1.7). Рис. 1.7. Меню установщика ESXi с добавленными пунктами Другой вариант – это расположить дистрибутив в сети, сделать доступ-ным по, например, протоколу ftp и в файле ответов указать путь к дистрибути-ву. Затем, как-то загрузив установщик ESXi, параметром (примерно вот таким:ks=ftp://192.168.10.10/ks) указать ему расположение файла ответов, которыйтакже может располагаться на сетевом ресурсе. Если еще и осуществить загрузкусервера по PXE, то получится самый гибкий вариант установки, без каких-либодисков или образов вообще. Разумеется, доступны и промежуточные между этими двумя варианты.
    • Начало работы 33 1.3. Начало работы Дальнейшая работа одинакова для и ESXi, и для ESX. Вариантов два: у насесть управляющий vCenter Server или его нет. Если есть – сразу переходите к раз-делу «Установка и начало работы с vCenter Server». 1.3.1. Начало работы без vCenter C локальной консоли ESX(i) мы его функциями воспользоваться не сможем.На локальном мониторе отображается лишь немного информации, в частностиIP-адрес сервера ESX(i). Для работы нам понадобится другая машина с Windows,куда необходимо установить клиента vSphere. Поддерживаются следующие вер-сии Windows: XP, Vista, 7, Server 2003, Server 2008, в 32- и 64-битных версиях. Этой внешней машиной, допустим, будет ваш компьютер. Далее я его буду на-зывать клиентским компьютером. На него устанавливаем vSphere Client (клиент vSphere). Взять дистрибутивследует с веб-интерфейса ESX(i). Браузером обращаемся на IP-адрес сервера, настраничке щелкаем по ссылке «Download vSphere Client». Загружаем, устанав-ливаем. Обратите внимание на то, что начиная с версии 4.1 ссылка на загрузкуклиента ведет на сайт VMware, а в составе ESX(i) дистрибутива клиента большене поставляется. Этот клиент может быть найден на сайте VMware не только попрямой ссылке с описываемой странички, но и в доступном после регистрацииразделе download. Если вы будете использовать vCenter Server, то дистрибутивклиента vSphere проще всего найти в дистрибутиве или на веб-странице сервераvCenter. Запускаем установленный клиент vSphere, указываем имя или IP-адрес серве-ра ESX(i) и подключаемся. Увидим предупреждающее сообщение о неподписанном сертификате. Если выне понимаете, что это такое, проконсультируйтесь со специалистом по безопасно-сти вашей компании. Нужен этот сертификат для подтверждения легитимностисервера. Подключившись первый раз, следует выполнить минимальную настройку.После подключения вы попадете на страничку Home. На ней выберите иконкуInventory и выделите свой сервер. Затем пройдите на закладку Configuration длясервера (рис. 1.8). Из начальных настроек представляют наибольший интерес: 1. Licensing Features – здесь необходимо указать ключ продукта. Напомню, что без него на сервере будут доступны все функции в течение 60 дней озна- комительного периода. 2. Time Configuration – настройки NTP. Настроек минимум – включить кли- ент NTP и указать адрес сервера NTP. 3. DNS and Routing – настройки DNS и шлюзов по умолчанию. 4. Networking – сеть. Подробности по настройке сети см. в соответствующем большом разделе.
    • 34 Установка vSphere Рис. 1.8. Подключение клиентом vSphere напрямую к серверу ESX(i) 5. Storage – система хранения. Подробности по настройке дисковой подси- стемы см. в соответствующем большом разделе. После этого можно создавать и включать виртуальные машины. Если мы планируем использовать vCenter Server, то так никогда не делаем ☺. Под «так» имеется в виду «подключаясь напрямую к серверу». Если естьvCenter, стараемся все действия производить через него. И только если совсем неполучается, лишь в этом случае подключаемся к ESX(i) напрямую. «Не получает-ся» означает какого-то рода проблемы. Установке и работе с vCenter посвящен один из следующих разделов. Обзорэлементов интерфейса клиента vSphere при работе напрямую с ESX(i) и черезvCenter – чуть далее. Есть маленький список действий, которые доступны вам только при работес сервером ESX(i) напрямую, а не через vCenter Server. В частности, это создание иуправление локальными пользователями ESX. Большинству из вас дополнитель-ные локальные пользователи на ESX(i) не нужны.
    • Начало работы 35 1.3.2. Установка и начало работы с vCenter Server Здесь поговорим про вторую часть vSphere – VMware vCenter Server, проинтерфейс работы с ESX(i) через vCenter, а также про шаги первоначальной на-стройки. Также последовательно поговорим про все шаги установки этого продукта. Системные требования VC Системные требования текущей версии vCenter Server 4 имеет смысл смот-реть в документации (здесь и далее документацию ищите по адресу http://pubs.vmware.com. Информацию именно о совместимости следует искать в документеVMware vSphere Compatibility Matrixes). Я же скажу, на что имеет смысл обратитьвнимание. У сервера vCenter должно быть достаточно ресурсов: процессор 2 ГГц, 2 ГбОЗУ, 1–2 Гб места на диске. Обратите внимание: это только для службы vCenterServer, но кроме нее будет установлен веб-сервер для веб-интерфейса vCenter, ко-торый будет дополнительно потреблять от 128 до 1500 Мб ОЗУ (в зависимости отинтенсивности использования). Этот веб-интерфейс дает нам возможность взаи-модействовать с ВМ при помощи только браузера. В списке совместимых браузе-ров – IE6 и 7, Mozilla Firefox 2.x и 3.x. vCenter – это приложение под Windows. В качестве ОС vCenter может ис-пользовать Windows Server 2003 SP2 – 2008 R2 (начиная с версии 4.1 – только64-битные) и 64-битную Windows XP Pro. Впрочем, за точным списком для теку-щей версии имеет смысл обращаться все-таки в документацию. Также для работы vCenter необходима база данных. Если она будет работатьна том же сервере или ВМ, что и vCenter, то для нее потребуются дополнительныересурсы, включая место на диске. vCenter Server требует физического сервера или ВМ, в которую мы будем егоустанавливать. ВМ может работать на одном из ESX(i) серверов, который будетуправляться этим vCenter Server. Есть некоторые соображения по использованию для установки vCenter Serverфизической или виртуальной машины. Очевидно, что в первом случае потребует-ся сервер, – это финансовые затраты. Какие соображения есть кроме этого? Плюсы использования для vCenter виртуальной машины на одном из ESX(i): нет необходимости в выделенном сервере под vCenter; ВМ с vCenter может быть защищена механизмами HA (High Availability), FT (Fault Tolerance); ВМ с vCenter можно мигрировать на другой сервер, в случае необходимо- сти обслуживания сервера ESX(i), где эта ВМ работает; к ВМ с vCenter применимы снимки состояния (snapshot), дающие очень простую возможность обеспечить точку возврата перед потенциально опасными действиями.
    • 36 Установка vSphere Минусы использования для vCenter виртуальной машины на одном из ESX(i): в некоторых ситуациях проблемы с виртуальной инфраструктурой могут вызвать недоступность vCenter, а без него не будет централизованного до- ступа к виртуальной инфраструктуре, что может усложнить решение ис- ходной проблемы. Если вы приняли решение использовать под vCenter виртуальную машину,то каких-то особых нюансов такой установки нет. Устанавливаем ESX(i) сервер,на свою машину устанавливаем клиент vSphere, подключаемся с его помощьюк ESX(i) и создаем там ВМ. Устанавливаем в нее ОС, затем vCenter Server. Все. БД для vCenter Server В состав дистрибутива vCenter входит дистрибутив SQL Server 2005 Express,бесплатной версии СУБД от Microsoft. Ее идеально использовать для тестовых идемонстрационных стендов, а также можно применять и в производственной сре-де. Правда, сама VMware не рекомендует использовать SQL Server 2005 Express вслучае, если размер вашей инфраструктуры превышает 5 серверов и 50 ВМ. Из коммерческих СУБД поддерживаются разные версии следующих про-дуктов: IBM DB2; Microsoft SQL Server 2005; Microsoft SQL Server 2008; Oracle 10g; Oracle 11g. Точный список для вашей версии ищите в документации. БД может распо-лагаться как на одном сервере с vCenter, так и на выделенном сервере. Из стан-дартных соображений надежности и производительности рекомендуется второйвариант. Впрочем, такая рекомендация начинает иметь смысл лишь если размеринфраструктуры достигает хотя бы десятка-другого физических серверов. Все версии БД, кроме SQL Server 2005 Express, требуют дополнительной на-стройки – см. документ «ESX and vCenter Server Installation Guide». Если серверБД не выделен под хранение базы vCenter, то рекомендуется перед установкойvCenter сделать резервную копию остальных БД. Совместимость vCenter Server 4 и vSphere Client с предыдущими версиями ESX и vCenter C помощью vCenter Server 4 вы можете управлять ESX серверами любых вер-сий, кроме ESX 2.0 и 2.1. C помощью vSphere Client вы можете напрямую управлять ESX серверамиверсий, начиная с 2.5 включительно, и Virtual Center, начиная с версии 2.5 вклю-чительно. Напомню, что соответствие версий ESX и Virtual Center следующее: 1. ESX 2.0 – Virtual Center 1; 2. ESX 2.5 – Virtual Center 1.5; 3. ESX 3.0 – Virtual Center 2.0; 4. ESX(i) 3.5 – Virtual Center 2.5; 5. ESX(i) 4.# – vCenter Server 4.#.
    • Начало работы 37 При подключении к ESX(i) версий 3.x вам предложат загрузить с него VI Cli-ent и управлять этим ESX(i) через клиент родной для него версии. Клиент преды-дущей версии установится в вашей системе параллельно с vSphere Client. Для получения полной и актуальной информации о совместимости ком-понентов vSphere разных версий рекомендую обратиться к документу vSphereCompatibility Matrixes. Актуальная на момент написания версия располагается поадресу www.vmware.com/pdf/vsphere4/r40/vsp_compatibility_matrix.pdf. Установка vCenter Server Сервер для установки vCenter может быть членом как домена, так и рабочейгруппы. В последнем случае компонент vCenter Guided Consolidation Service несможет автоматически обнаруживать серверы для анализа и миграции их в ВМ ине будет поддерживаться vCenter Linked Mode. Для сервера vCenter рекомендуется настроить статический IP-адрес. Статич-ность адреса для сервера vCenter обусловлена тем, что агенты vCenter сохраняютIP-адрес сервера vCenter в своем конфигурационном файле (vpxa.cfg). Если адрессервера vCenter изменится, серверы ESX(i) будут отображаться как недоступные, ипридется для каждого выполнить операцию удаления из vCenter с последующим до-бавлением обратно, после чего агенты vCenter узнают и запомнят уже новый адрес. Между серверами ESX(i) и vCenter не должен использоваться NAT. Далее я перечислю, что вам следует знать для прохождения мастера установкиvCenter. Для запуска службы vCenter можно использовать как пользовательскуюучетную запись, так и встроенную учетную запись Local System. Использованиепользовательской учетной записи нужно в основном при использовании Windowsauthentication на SQL Server. Компоненты, входящие в состав дистрибутива vCenter Server: VMware vCenter Server – сама служба vCenter, именно ее мы устанавливаем; vSphere Client – клиент для подключения к vCenter и доступа ко всем на- стройкам и функциям. Его следует установить на те машины, с которых мы будем непосредственно администрировать виртуальную среду (это то же при- ложение, что используется для управления ESX(i) напрямую, без vCenter); Microsoft.NET Framework – необходимый компонент для работы vCenter и vSphere Client. Будет установлен автоматически, если отсутствует в системе; Microsoft SQL Server 2005 Express – бесплатная версия СУБД от Micro- soft, может использоваться в качестве БД для vCenter. Если указать ее ис- пользование в мастере установки – будет установлена автоматически. Если вы планируете использовать существующую БД, то выбирать использова- ние SQL Server 2005 Express не надо; VMware vCenter Converter Enterprise for vCenter Server – опциональный компонент vCenter, позволяющий вам конвертировать физические серве- ры в виртуальные машины и многое другое – см. посвященный ему раз- дел. Может быть установлен как на машину с vCenter, так и на выделенный сервер или ВМ;
    • 38 Установка vSphere vCenter Guided Consolidation Service – дополнительный компонент vCen- ter, позволяющий обнаружить и обследовать физические серверы в вашей сети с целью анализа целесообразности переноса их в ВМ; VMware vCenter Orchestrator – дополнительный продукт, предназначен- ный для автоматизации задач администрирования виртуальной инфраструк- туры. Устанавливается автоматически, в случае если ОС использует IPv4, и недоступен в случае использования IPv6. Начиная с версии 4.1, vCenter Orchestrator предлагает новые предустановленные процессы для автомати- зации задач администрирования, такие как управление снимками состояния, забытыми VMDK-файлами, множественные операции конвертирования thick-дисков в thin и отключение съемных устройств через vCenter. Об этом продукте в книге я писать не буду, базовую информацию можно подчерпнуть по ссылке http://www.vm4.ru/2010/03/vmware-orchestrator.html; vCenter Update Manager – дополнительный компонент vCenter, предна- значенный для обновления серверов ESX(i) и ВМ (некоторых гостевых ОС и приложений). См. посвященный ему раздел. Может быть установлен как на машину с vCenter, так и на выделенный сервер или ВМ. vCenter может использоваться сам по себе, в независимом (Standalone) ва-рианте, или в составе группы серверов vCenter – последний режим называется«Linked Mode». Данный режим может быть интересен, если в вашей компании экс-плуатируются несколько серверов vCenter – для разных групп серверов ESX(i).В случае использования Linked Mode вы сможете управлять всей инфраструкту-рой из одного окна. Варианту Linked Mode посвящен следующий раздел, сейчасмы говорим про установку в варианте Standalone. Из важных вопросов установщика – выбор БД. Или используйте SQL Server2005 Express (тогда она будет установлена автоматически) либо какую-то сущест-вующую БД. В последнем случае необходимо отдельно настроить подключениек ней – см. подробности для вашей версии БД в «ESX and vCenter Server InstallationGuide». SQL Express не рекомендуется использовать для инфраструктуры размеромболее 5 серверов/50 виртуальных машин. Обусловлено это техническими ограниче-ниями для данной версии БД: один процессор – 1 Гб памяти, до 4 Гб – размер базы. Укажите учетную запись – System или пользовательскую, если вы используетеWindows Authentication для SQL Server. Выберите, будет ли это отдельный vCenter Server, или он будет входить в со-став группы – Linked Mode. Второй вариант разбирается в следующем разделе. После установки vCenter для работы с ним необходим клиент vSphere. Дистри-бутив клиента можно взять из дистрибутива vCenter Server или с веб-интерфейсаvCenter и ESX(i). Если этот сервер vCenter должен управлять ESX(i) серверами версий 3.x, тонеобходимо сохранить (или установить) сервер лицензий (тот, что использовал-ся в VI 3). Linked Mode vCenter версии 4 позволяет объединять несколько серверов vCenter в группу.Подключившись к одному серверу vCenter из такой группы, мы можем видеть и
    • Начало работы 39управлять объектами каждого сервера vCenter из группы. Это очень удобно, если увас есть несколько серверов vCenter. Например, отдельные серверы для производ-ственной и тестовой инфраструктур или разные vCenter в разных ЦОД компании. Подключить сервер vCenter к группе можно как на этапе установки, так ив произвольный момент позже. Серверы vCenter, объединенные в группу, используют децентрализованнуюсистему совместной работы (Peer-to-Peer). Если один сервер vCenter может об-служивать до 1000 серверов ESX(i) и 10 000 включенных ВМ (рекомендательноеограничение), то до десяти vCenter в одной группе Linked Mode позволят вам мо-ниторить и управлять до 3000 серверами ESX(i) и 30 000 ВМ. Обратите внимание: эту возможность включает только vCenter Server с лицен-зией «Standard». То есть vCenter Server Foundation не получится добавить в груп-пу Linked Mode. В объединенной таким образом инфраструктуре вам доступны: 1) назначение глобальных ролей – то есть раздача прав по всей инфраструк- туре; 2) глобальный поиск объектов; 3) управление всеми лицензиями. Выглядит это так (рис. 1.9): Рис. 1.9. Работа с несколькими vCenter в одном окне
    • 40 Установка vSphere Для хранения и синхронизации данных между экземплярами vCenter Serverв группе Linked Mode использует Microsoft Active Directory Application Mode(ADAM). Сегодня ADAM известен как Microsoft Active Directory Lightweight Di-rectory Services (AD LDS). ADAM устанавливается автоматически при установкеvCenter Server. Каждый экземпляр ADAM хранит данные всех серверов vCenterодной группы. Эти данные содержат: информацию для соединения – IP-адреса и номера портов; сертификаты и их отпечатки (Thumbprints); лицензионную информацию; роли пользователей. Один раз в день данные из ADAM выгружаются в резервную копию, котораяхранится в БД сервера vCenter. В случае повреждения ADAM vCenter будет ис-пользовать данные из последней резервной копии для его восстановления. Подключить vCenter к группе Linked Mode можно как на этапе установки, таки в любой другой момент. Пользователь, который запускает процесс присоедине-ния сервера vCenter к группе, должен обладать правами локального администра-тора и на локальной системе, и на системе (системах), где установлены прочиесерверы vCenter этой группы. Требования к инфраструктуре следующие. Все серверы vCenter должны находиться в одном домене AD или в разных до-менах с двухсторонними доверительными отношениями. Само собой, важна пра-вильная настройка синхронизации времени и DNS. Но vCenter Server не должен быть установлен на контроллере домена – этовоспрепятствует его добавлению в группу. Также не получится добавить vCenterв группу, если он установлен на терминальном сервере. Если вы хотите объединить в группу несколько (например, три) серверовvCenter на этапе их установки, то ваши действия следующие. 1. Установить первый из них. Так как на этом этапе он является единствен- ным, никакой группы для него не указываем. 2. Установить второй, когда установщик задаст вопрос про Linked Mode – ука- зать FQDN сервера с первым vCenter. Теперь первые два vCenter в группе. 3. Третий vCenter, предположим, мы не устанавливаем с нуля, а обновляем с Virtual Center 2.5 до vCenter 4. Наши действия – сначала обновить, затем добавить к группе, указав FQDN первого или второго сервера vCenter. Теперь все три сервера vCenter принадлежат одной группе. Если вы хотите добавить к группе уже установленный vCenter, то это такжевесьма не сложно: Start ⇒ All Programs ⇒ VMware ⇒ vCenter Server LinkedMode Configuration. Выберите пункт Modify Linked-Mode configuration и укажите FQDN любогосервера vCenter, в группу с которым вы хотите добавить текущий. Для удаления сервера vCenter из группы следует воспользоваться приложе-нием «Programs and Features» (Программы и компоненты) или «Add or Removeprogram» (Установка и удаление программ) для Windows Server 2008 или бо-
    • Интерфейс клиента vSphere, vCenter, ESX(i). Веб-интерфейс 41лее ранних версий соответственно. Выбрать там VMware vCenter Server, нажатьChange и в мастере отказаться от членства в группе Linked Mode. Прочие подробности, рекомендации и инструкции см. в актуальной версии«ESX and vCenter Server Installation Guide». 1.4. Интерфейс клиента vSphere, vCenter, ESX(i). Веб-интерфейс Здесь я опишу основные элементы интерфейса. Упор будет сделан на работучерез vCenter. Впрочем, при работе с ESX(i) напрямую все очень похоже, простонедоступна часть объектов (например, кластер HA/DRS) или функций (vMotion). 1.4.1. Элементы интерфейса клиента vSphere при подключении к vCenter Итак, вы подключились к vCenter с помощью клиента vSphere. Дистрибутивклиента входит в дистрибутив vCenter. Также клиент vSphere доступен для за-грузки на веб-интерфейсе vCenter и ESX(i). Устанавливаем клиент на свой ком-пьютер, получив дистрибутив из удобного источника. В самом начале вам потребуется учетная запись, имеющая права локальногоадминистратора на системе, где установлен vCenter Server. Это может быть как ло-кальная, так и доменная учетная запись. Впоследствии вы можете назначать раз-личные роли и давать права в vCenter любым учетным записям (не обязательноимеющим административные права в ОС). Подключив к vCenter сервер, вы увидите примерно такую картину, котораяизображена на рис. 1.10. Как видите, элементы интерфейса поделены на четыре большие категории. Inventory – здесь сгруппированы основные элементы интерфейса по работе совсеми объектами виртуальной инфраструктуры: 1. Hosts and Clusters – без преувеличения, самый главный пункт. В нем мы настраиваем наши серверы, кластеры, виртуальные машины. 2. VMs and Templates – в этом представлении интерфейса отображаются виртуальные машины и шаблоны, а также папки для них – иерархия вир- туальных машин здесь не зависит от их физического размещения на тех или иных серверах и кластерах. Удобно, когда необходимо работать с вир- туальными машинами, и только с ними, особенно если требуется их как-то сгруппировать по организационному признаку. 3. Datastores – здесь отображаются все хранилища, подключенные хотя бы к одному ESX(i) нашей инфраструктуры. 4. Networking – здесь отображаются группы портов для виртуальных ма- шин на стандартных виртуальных коммутаторах, и, главное, здесь и только здесь можно создавать и настраивать распределенные виртуальные комму- таторы VMware.
    • 42 Установка vSphere Рис. 1.10. Интерфейс vCenter Administration – задачи администрирования: 1. Roles – отсюда настраиваем и получаем информацию о раздаче прав в вир- туальной инфраструктуре. 2. Sessions – просмотр текущих сеансов работы с vCenter, рассылка сообще- ний подключенным пользователям и отключение сессий. 3. Licensing – настройка лицензирования vCenter и ESX(i). Именно здесь указываем ключи продукта и назначаем их разным серверам. 4. System Logs – журналы событий vCenter (когда клиент vSphere подклю- чен к vCenter) и ESX(i) (когда клиент подключен к ESX(i) напрямую). Пригодятся при решении проблем. Это намного удобнее, чем искать фай- лы журналов самостоятельно. Так доступны не все, но основные журналы. 5. vCenter Server Settings – настройки самого vCenter Server. Именно здесь можно указать, например, почтовый сервер для рассылки оповещений или настройки оповещения по SNMP. Management – вспомогательные возможности vCenter: 1. Scheduled Tasks – планировщик задач vCenter Server. Обратите на него внимание – с его помощью можно запланировать на удобное время многие операции, такие как включение и выключение ВМ, развертывание ВМ из шаблона, миграция ВМ, снимки состояния ВМ и др.
    • Интерфейс клиента vSphere, vCenter, ESX(i). Веб-интерфейс 43 2. Events – все события, которые vCenter получает с серверов и генерирует сам. 3. Maps – этот механизм позволяет строить графические схемы связей между объектами инфраструктуры. Если стоит задача посмотреть, какие ВМ ле- жат на тех или иных хранилищах или на каких серверах существуют те или иные сети, то вам сюда. 4. Host Profiles – однажды созданный профиль настроек доступен для редак- тирования в этом разделе интерфейса. 5. Customization Specification Manager – vCenter позволяет обезличивать не- которые гостевые ОС при клонировании или развертывании из шаблона. Сохраненные файлы ответов мастера развертывания попадают сюда. Здесь же можно их импортировать или экспортировать, создавать и редактировать. Solution and Application – сюда попадают функции, которые появляютсяв vSphere через установку дополнительных приложений-плагинов. На рис. 1.8 вывидите иконки для управления VMware Update Manager, VMware Data Protection,VMware Guided Consolidation и плагин, добавляющий пункт «Подключение поRDP» в контекстное меню виртуальных машин. Когда вы переходите к какому-то элементу интерфейса со страницы Home,то адресная строка меняется соответствующим образом. Также через нее можнополучать быстрый доступ к другим частям интерфейса (рис. 1.11). Рис. 1.11. Меню адресной строки
    • 44 Установка vSphere По умолчанию для каждого объекта клиент vSphere показывает закладку Get-ting Started. Я рекомендую отключить эту закладку, потому что без нее вам сразубудет показываться несравнимо более информативная закладка Summary. От-ключить показ закладок Getting Started для объектов всех типов зараз можно вменю Edit ⇒ Client Settings ⇒ снять флажок Show Getting Started Tab. Еще немного подробностей про интерфейс на примере отдельного сервера.Пройдите в раздел Hosts and Clusters, выделите сервер и обратите внимание назакладки (рис. 1.12). Рис. 1.12. Элементы интерфейса для сервера Большинство закладок доступны для объекта vCenter любого типа. Перечис-лю закладки и их функции: 1. Summary – сводная информации об объекте. Содержит секцию Commands, в которой доступны основные манипуляции с объектом. Например, для виртуальных машин отсюда удобно попадать в настройки, доступные по строке Edit Settings. Впрочем, все пункты отсюда (и другие) доступны че- рез контекстное меню объекта. 2. Virtual Machines – отображает виртуальные машины и шаблоны, являю- щиеся дочерними к данному объекту. Закладка доступна для большинства
    • Интерфейс клиента vSphere, vCenter, ESX(i). Веб-интерфейс 45 типов объектов vCenter. Для сервера на этой закладке отображаются вир- туальные машины, размещенные непосредственно на нем. Для хранили- ща – чьи файлы располагаются на данном хранилище. Для распределенной группы портов – подключенные к ней ВМ. 3. Performance – на этой закладке мы смотрим графики нагрузки на объект по разнообразным счетчикам производительности. Для объектов разных типов доступны разные наборы счетчиков. 4. Configuration – здесь мы настраиваем серверы. Эта закладка существует только для них. 5. Tasks & Events – события и задачи выбранного объекта или его дочерних объектов. 6. Alarms – на этой закладке настраиваются и отображаются сработавшие предупреждения (alarm) vCenter. 7. Permissions – на этой закладке отображаются пользователи и группы, име- ющие права на данный объект. 8. Maps – отображается схема связей данного объекта с другими объектами vCenter. Для виртуальных машин на этой закладке отображается так на- зываемая vMotion map (карта vMotion), которая показывает возможность или невозможность живой миграции этой ВМ на другие серверы. 9. Storage Views – здесь отображается разнообразная информация про под- систему хранения в контексте выделенного сейчас объекта. То есть на этой закладке для виртуальной машины отображается информация о хранили- щах, занятых ее файлами. Для сервера – всех его хранилищ. Для кластера – всех хранилищ всех его узлов. У меня частенько будут попадаться конструкции вида «Пройдите Configuration⇒ куда-то далее и сделайте то-то и то-то». Это означает, что для описываемых ма-нипуляций вам нужна закладка Configuration. Существует она только для серве-ров; чтобы ее найти, пройдите Home ⇒ Hosts and Clusters ⇒ Configuration. Также обратите внимание на кнопки Tasks и Alarms в нижней левой частиэкрана. Они отображают или скрывают панель текущих задач и активных преду-преждений. Особенно полезно окно Tasks – здесь видно, закончилось или нет тоили иное действие, успешно закончилось или нет, и некоторые действия можноотменить (рис. 1.13). Рис. 1.13. Панель Tasks Для виртуальных машин есть несколько специфических элементов интерфей-са. В контекстном меню ВМ выберите пункт Open Console. Откроется консольк этой виртуальной машине (рис. 1.14).
    • 46 Установка vSphere Рис. 1.14. Консоль ВМ Здесь вы видите: пиктограммы управления питанием ВМ. Обратите внимание: пиктограм- мы выключения и перезагрузки настроены на корректное выключение и корректную перезагрузку. Эти операции требуют VMware tools. Если их нет или они еще не загрузились, то для выполнения «жестких» операций с питанием пользуйтесь пунктами меню VM ⇒ Power; пиктограммы работы со снимками состояния (snapshot) – создание, воз- врат к ранее созданному снимку и запуск диспетчера снимков состояния (Snapshot Manager); пиктограммы подключения FDD и DVD. Если вызвать меню VM, то в нем интерес представляют пункты: Power – управление питанием ВМ; Guest – из этого меню инициируется установка VMware Tools и посылает- ся комбинация Ctrl+Alt+Del. Чтобы отправить внутрь ВМ такую комбина- цию с клавиатуры, следует нажать Ctrl+Alt+Ins.
    • Интерфейс клиента vSphere, vCenter, ESX(i). Веб-интерфейс 47 Когда в ВМ не установлены VMware Tools, то после щелчка мышью внутриконсоли фокус ввода принадлежит уже ей, а не вашей «внешней» ОС. Чтобы «из-влечь» курсор из консоли, нажмите Ctrl+Alt. Отличительными чертами этой консоли являются то, что она «аппаратная», тоесть ее работоспособность не зависит от ПО внутри ВМ, и то, что ее трафик идетпо управляющей сети ESX(i). Таким образом, чтобы открыть консоль к виртуаль-ной машине, вам нет необходимости находиться в одной с ней сети (однако еслисервер ESX(i) добавлен в vCenter по имени, то необходимо еще, чтобы это имяразрешалось с машины клиента). Обратите внимание на Home ⇒ Administration ⇒ System Logs. C помощьюэтого элемента интерфейса вы можете получить доступ к журналам vCenter(когда клиент vSphere подключен к vCenter) и ESX(i) (когда клиент подключенк ESX(i)). Это намного удобнее, чем искать эти файлы журналов самостоятельно.Так доступны не все, но основные журналы. Нажав в любом окне интерфейса Ctrl+Shift+F, вы попадете в окно расширен-ного поиска. Отсюда возможен поиск объектов любого типа, по любым критериями с учетом условий. Например: все выключенные виртуальные машины; все виртуальные машины с устаревшей версией VMware tools; все виртуальные машины со строкой «x» в поле Description (описание); все виртуальные машины, для которых в качестве гостевой ОС указан Linux; все серверы ESX(i) во включенном или выключенном состоянии; все хранилища, свободного места на которых меньше указанного значе- ния. Обратите внимание, что поиск возможен и по так называемым Custom Attri-butes (произвольным атрибутам). Задать такие атрибуты можно для хостов и вир-туальных машин. Сначала в настройках vCenter: меню Administration ⇒ CustomAttributes ⇒ Add. А затем на закладке Summary ⇒ ссылка Edit в поле Annotations(рис. 1.15). Наконец, обращаю ваше внимание на то, что со списком объектов в правойчасти окна клиента vSphere (например, список виртуальных машин на закладкеVirtual Machines) можно осуществлять разные операции: сортировать по любому столбцу, кликом по его заголовку; изменять набор отображаемых столбцов. Для этого в контекстном меню пустого места выберите пункт View Column; фильтровать по подстроке в некоторых столбцах (например, имя, состоя- ние, тип гостевой ОС). В этом поможет поле в правой верхней части окна клиента vSphere, присутствующее на соответствующих закладках; экспортировать список объектов (предварительно отфильтрованный, упо- рядоченный и с нужным набором столбцов). Для экспорта обратитесь к пункту меню File ⇒ Export ⇒ Export List. В списке поддерживаемых форматов присутствуют html, csv, xls, xml.
    • 48 Установка vSphere Рис. 1.15. Дополнительные поля для виртуальной машины Базовые шаги для решения проблем с клиентом vSphere В случае возникновения ошибки при подключении клиентом vSphere к сер-веру vCenter первое, что необходимо проверить, – запущена ли служба VMwareVirtual Center Server. Иногда при использовании локальной СУБД (особенно прииспользовании SQL Server Express) после перезагрузки сервера эта служба не за-пускается из-за того, что она пытается стартовать до того, как заработает БД. Ре-шением проблемы является выставление зависимости службы vCenter от службыСУБД. К сожалению, даже выставление зависимости не всегда помогает. Одно из решений для тестовой или демонстрационной инфраструктуры – на-стройка отложенного старта для служб vCenter и vCenter Management WebServices. 1.4.2. Первоначальная настройка vCenter и ESX(i) Итак, у вас есть свежеустановленный сервер или серверы ESX(i) и vCenter. Выустановили на свою рабочую станцию клиент vSphere и подключились к vCenter.Типовой список действий для подготовки виртуальной инфраструктуры к полно-ценной работе выглядит примерно так: 1. Добавление серверов ESX(i) в консоль vCenter. 2. Настройка лицензирования серверов ESX(i) и vCenter.
    • Интерфейс клиента vSphere, vCenter, ESX(i). Веб-интерфейс 49 3. При необходимости настройки некоторых служб Service Console, таких как firewall, ntp, SSH, syslog. А также настройки DNS и маршрутизации (шлю- зов по умолчанию). 4. Настройка сети. Это и настройка интерфейсов VMkernel, и настройка групп портов для виртуальных машин, и создание распределенных виртуальных коммутаторов. 5. Настройка хранилищ. Подключение систем хранения данных, создание раз- делов VMFS, проверка корректного обнаружения уже существующих VMFS. 6. Создание и настройка пулов ресурсов, кластеров HA и DRS. Добавление серверов в консоль vCenter Для добавления серверов в консоль vCenter необходимо, чтобы в ней суще-ствовал объект типа «Datacenter». Такой объект суть папка для объектов всех про-чих типов – серверов, кластеров, виртуальных машин, хранилищ, сетей и прочего.Таким образом, с помощью папок Datacenter вы можете сгруппировать части ин-фраструктуры. Это пригодится в тех случаях, когда в вашей компании существу-ют несколько административных групп, управляющих независимыми виртуаль-ными инфраструктурами. Все эти инфраструктуры управляются одним vCenter,из одной консоли, но на уровне прав можно ограничивать области видимости дляразных пользователей. Если у вас нет филиалов со своей инфраструктурой и администраторами, еслиу вас в компании нет отдельного отдела безопасности, который сам управляетсвоими ESX, или подобных вариантов – то несколько Datacenter вам не нужно.Но хотя бы один создать придется – это требование vCenter. Для создания вызовите контекстное меню для корневого объекта иерархииvCenter – его самого и выберите в нем пункт New Datacenter. Имя объекта вы-берите по своему усмотрению. Теперь в контекстном меню уже созданного Datacenter выберите пункт AddHost. В запустившемся мастере укажите имя или IP-адрес сервера ESX(i), поль-зователя root и его пароль. Предпочтительнее добавлять серверы по имени, при-чем по полному доменному имени (FQDN). Пароль пользователя root необходимvCenter, чтобы создать на этом ESX(i) своего собственного пользователя vpxuser,из-под которого в дальнейшем vCenter и будет подключаться к этому ESX(i). Та-ким образом, последующая смена пароля root на ESX(i) сервере не оказывает наvCenter никакого влияния. Настройка лицензирования При установке ESX и vCenter вы можете указать ключ продукта. А можетене указывать – тогда эти продукты начнут работать в «Evaluation» (оценочном)режиме. Для ESXi это вообще является единственно возможным вариантом – наэтапе его установки ключ ввести нельзя. Но после установки даже для бесплатнойверсии ключ ввести необходимо. Таким образом, если в вашей инфраструктуре есть объекты, для которых ли-цензия не была указана, то через 60 дней ознакомительная лицензия закончится иони работать перестанут.
    • 50 Установка vSphere vCenter лицензируется поштучно, так что ключ для него должен содержатьстолько лицензий, сколько серверов vCenter вы планируете использовать. Обыч-но один. ESX(i) лицензируется по процессорам, и в ключе должно содержаться ли-цензий на столько процессоров (сокетов), сколько их совокупно во всех вашихESX(i). Разные серверы ESX(i) одной инфраструктуры могут лицензироватьсяразными ключами. Для указания лицензии пройдите Home ⇒ Licensing. В этом окне вам необ-ходимо добавить один или несколько ключей продукта. В каждом 25-символьномключе зашифровано, какие лицензии он содержит и на какое количество объектов.В типовом случае у вас есть сервер vCenter и несколько серверов ESX(i) с лицен-зией какого-то одного типа. Значит, у вас будет минимум два ключа – для vCenterи для ESX(i). Запустите мастер Manage vSphere Licenses и пройдите по шагам: 1. Add License Keys – введите свои ключи здесь. Можно добавлять сразу не- сколько ключей, по одному в строку. Для каждого ключа можно ввести про- извольную метку (Label), для упрощения управления лицензиями. 2. Assign Licenses – здесь вам покажут серверы vCenter и ESX(i) вашей ин- фраструктуры, и вы сможете указать, какой из них каким ключом необхо- димо отлицензировать. 3. Remove License Keys – здесь вы можете удалить какие-то ключи. Одновременно под управлением одного сервера vCenter могут находиться сер-веры ESX(i), лицензированные различными типами лицензий. Если вы обновля-ли какие-то лицензии, например со Standard на Enterprise Plus, то вам необходимодобавить новый ключ, указать его использование для серверов и удалить старый,если он стал не нужен. Если вы перевели сервер с лицензии ознакомительной накакую-то из коммерческих с меньшим функционалом, то часть функций переста-нет работать без предупреждения. Если сервер перестал быть лицензирован, на-пример из-за окончания срока действия лицензии, то на таком сервере перестанутвключаться виртуальные машины (хотя запущенные работать продолжат). Рекомендуемые начальные настройки ESX(i) Основные кандидаты на настройку из служб ESX(i) – это Firewall (тольков ESX), клиент NTP и, возможно, сервер SSH. В версии 4.1 все это настраивается из графического интерфейса. ПройдитеHome ⇒ Hosts and Clusters ⇒ Configuration для настраиваемого сервера. В спи-ске вас интересуют: 1. Security Profile – для ESX это настройки firewall. Этот, основанный на ip- tables межсетевой экран работает в Service Console сервера ESX и защища- ет лишь ее. Обратите внимание: для настройки из командной строки вам пригодится команда esxcfg-firewall. Для централизованной настройки fire- wall вам пригодится механизм Host Profiles, см. посвященный ему раздел. Однако для ESXi пункт Security Profile позволяет совсем другие настрой- ки, о них см. чуть ниже.
    • Интерфейс клиента vSphere, vCenter, ESX(i). Веб-интерфейс 51 2. Time Configuration – в этом пункте вы можете включить клиент NTP на ESX(i) и указать ему настойки синхронизации времени. 3. Licensed features – здесь вы можете просмотреть информацию о действу- ющих для этого сервера лицензиях. Также здесь можно настраивать лицен- зирование сервера, однако если сервер управляется через vCenter и лицен- зирование для этого сервера уже настроено через vCenter, то настройка, заданная на уровне сервера, будет отменена. 4. DNS and Routing – здесь можно указать имя сервера, суффикс домена DNS, адреса серверов DNS и шлюзы по умолчанию для Service Console и VMkernel. 5. Virtual Machine Startup and Shutdown – здесь настраиваются автозапуск виртуальных машин при включении сервера, порядок их включения и пау- зы между включениями разных ВМ. Также здесь можно указать, что де- лать с виртуальными машинами, когда сам сервер выключается. Вариан- ты – корректное выключение, принудительное выключение, приостановка (Suspend). 6. Authentication Services – настройка аутентификации на ESX(i) при помо- щи учетных записей из Active Directory. Подробности см. в посвященной безопасности главе. Пункт Security Profile для ESXi 4.1 довольно многофункциональный (см.рис. 1.16). Здесь вы сможете включить или выключить такие функции, как: Local Tech Support – доступность локальной командной строки в консоли ESXi; Рис. 1.16. Настройки Security Profile для ESXi 4.1
    • 52 Установка vSphere Remote Tech Support – включение и отключение сервера SSH на ESXi; Direct Console UI – включение и отключение БИОС-подобного меню в ло- кальной консоли ESXi. Из настроек SSH для сервера ESX вам может потребоваться отменить запретна вход под пользователем root. По умолчанию этот запрет действует, рекомендуется поступать следующимобразом: 1. Авторизоваться под непривилегированной учетной записью (ее можно создать на этапе установки или впоследствии – из локальной командной строки или клиента vSphere при подключении напрямую). 2. При необходимости повысить свои привилегии до root командой su – обратите внимание на минус через пробел. Без него не будет загружена переменная PATH, что потребует прописывания полного пути для запуска любой команды. Либо же выполнять все команды, требующие повышенных привилегий, допи-сывая перед ними «sudo». Последний вариант считается наиболее безопасным, нопотребует дополнительной настройки. Однако использовать учетные записи пользователя root непосредственно приустановке сессии SSH может все-таки оказаться совершенно необходимо. Напри-мер, для использования некоторых сторонних инструментов, которым требуетсяудаленный доступ к серверу с полными правами и разработчики которых несиль-но задавались проблемами соответствия требованиям безопасности. Для разрешения аутентификации сразу под пользователем root на ESX от-кройте в текстовом редакторе файл настроек SSH следующей командой:nano –w /etc/ssh/sshd_config В строкеPermit root login noпоменяйте «no» на «yes». Перезагрузите службу SSH:service sshd restart Теперь вы можете подключаться к ESX по SSH пользователем root. Для ESXi такой настройки нет, но для ESXi существует настройка LockdownMode, обладающая схожим предназначением. Возвращаясь к базовым настройкам серверов ESX(i): пройдите Configuration⇒ Storage. В этом окне отображаются разделы, отформатированные в VMFS. Ско-рее всего, здесь вы увидите раздел под названием Local1 или Storage1 – он былсоздан установщиком. Рекомендую переименовать этот раздел, например, так: «lo-
    • Интерфейс клиента vSphere, vCenter, ESX(i). Веб-интерфейс 53cal_esx1». В дальнейшем это сильно поможет вам ориентироваться в сводных спис-ках разделов VMFS в интерфейсе vCenter. Напоминаю, что в названиях лучше неиспользовать пробелы и спецсимволы, имена вида «local@esx1» – это плохая идея. Когда на ваших серверах уже созданы виртуальные машины, имеет смысл про-думанно настроить порядок их автозапуска для служб и приложений, которые за-висят друг от друга. Например, вот так: сначала ВМ с AD и DNS, затем СУБД,потом уже vCenter (если он установлен в ВМ). Однако если у вас будут использо-ваться кластеры HA и/или DRS, настройка автостарта лишается смысла, так какона выполняется для ВМ конкретного сервера – а в кластерах ВМ не привязанык конкретному серверу. В небольших внедрениях я предпочитаю в файл /etc/hosts на каждом серверепрописывать адреса всех остальных серверов ESX(i) и vCenter. Это служит длялокального разрешения имен на случай возникновения проблем с DNS – впрочем,поступать ли таким образом, каждый сможет решить сам – конечно, лучше обе-спечить бесперебойную работу DNS. Для ESXi вы можете включить так называемый Lockdown-режим, режим ло-кальной блокировки (Configuration ⇒ Security Profile). VMware рекомендует сде-лать это для тех ESXi, которые управляются через vCenter. Включение этого режи-ма будет препятствовать любому обращению на ESXi по сети с учетной записьюroot. То есть если включить этот режим, то, используя учетную запись root, вы несможете обратиться на ESXi даже клиентом vSphere. Это хорошо, потому что дажепо ошибке вы и ваши коллеги доступа на ESXi из-под привилегированной учетнойзаписи не получите. Это может быть плохо в случае недоступности vCenter, когда все-таки возник-нет необходимость подключиться к ESXi напрямую. Например, чтобы включитьвиртуальную машину с vCenter. Есть три варианта решения такой потенциальнойпроблемы: до включения режима Lockdown подключиться клиентом vSphere напря- мую на ESXi, пройти на закладку Users and Groups и создать произволь- ного пользователя. Назначить ему необходимые права. Или ввести ESXi в Active Directory, и получить возможность авторизоваться локально поль- зователем AD. В дальнейшем подключаться на ESXi по сети из-под учет- ной записи уже этого пользователя. Сделать это следует для каждого ESXi; выключить Lockdown-режим с его локальной консоли; не включать Lockdown-режим. Обратите внимание на то, что включение режима Lockdown оказывает влия-ние на подключение из-под учетной записи root с помощью клиента vSphere, Pow-erCLI, vSphere CLI, vMA, vSphere API. Прочие упомянутые мной в начале раздела настройки – сети, системы хране-ния – подробно разбираются в соответствующих разделах позже. 1.4.3. Работа через веб-интерфейс Обратите внимание: на ESX и vCenter работает веб-интерфейс для работыс виртуальными машинами. Для доступа к нему обратитесь браузером на адресvCenter или ESX и выберите ссылку Log in to Web Access (рис. 1.17).
    • 54 Установка vSphere Рис. 1.17. Вход в веб-интерфейс vCenter Авторизуйтесь соответствующей учетной записью (учетная запись Windowsдля vCenter и учетная запись Service Console для ESX). Веб-интерфейс vSphere 4 можно назвать инструментом оператора. Он не даетдоступа ни к каким задачам администрирования vSphere, но дает практическиполный доступ к работе с виртуальными машинами. С помощью веб-интерфейсавы можете: получать доступ к операциям с виртуальными машинами без установки клиента vSphere; создавать новые ВМ; изменять настройки существующих ВМ; добавлять ВМ в консоль ESX или vCenter (add to inventory); удалять ВМ из консоли ESX или vCenter; включать, выключать, перезагружать виртуальные машины, а также оста- навливать (suspend) и возобновлять их работу; отслеживать события и выполняемые действия; получать доступ к консоли виртуальных машин; генерировать уникальную ссылку для получения прямого доступа к консо- ли ВМ, минуя прочие элементы веб-интерфейса;
    • Обновление ESXi. ESX и vCenter с версий 3.х 55 создавать и выполнять все прочие действия, со снимками состояния вир- туальных машин; подключать к ВМ устройства CD/DVD клиентских компьютеров. Все эти манипуляции могут быть осуществлены из систем с Windows и с Linux,с использованием поддерживаемых версий браузеров. 1.5. Обновление ESXi, ESX и vCenter с версий 3.x Виртуальная инфраструктура VMware предыдущей версии (VMware Infra-structure 3) состоит из двух основных компонентов – Virtual Center 2.x и какого-то количества серверов ESX(i) 3.x. Мы хотим их обновить до vCenter Server 4 иESX(i) 4 соответственно. У вас есть несколько серверов, на них запущены ВМ. Логично поступать сле-дующим образом: 1. Обновить Virtual Center 2 до vCenter 4, затем обновить Update Manager 1 до Update Manager 4. Обратите внимание: возможно, вам потребуется об- новление СУБД и/или увеличение ресурсов для сервера vCenter в связи с изменившимися системными требованиями. 2. Освободить один сервер, перенеся с него ВМ на другие серверы. Если какие-то ВМ расположены на его локальных дисках – их можно просто выключить на время, процесс обновления серверов не затрагивает разде- лов VMFS. Обратите внимание: при обновлении ESX вам будет доступна загрузка сервера как в ESX 4, так и в ESX 3. Это что-то вроде подстраховки на случай возникновения проблем. 3. Обновить освободившийся сервер. 4. Освободить следующий сервер, притом обновленные ранее серверы уже можно задействовать вновь. ВМ, созданные на ESX(i) 3.x, работают на ESX(i) 4 без проблем. Версия VMFS для ESX(i) 4 очень мало отличается от версии VMFS для ESX(i) 3.x, поэтому необходимости обновлять VMFS сразу нет, можно этим заняться в удобное время. Для обновления версии раздела VMFS нужно будет его пересоздать – то есть ВМ придется времен- но перенести на другие хранилища. Для этого отлично подойдет процесс Storage vMotion (см. соответствующий раздел). Даже если ваша лицензия на vSphere не позволяет использовать эту функцию, можно воспользовать- ся тем, что сразу после обновления и vCenter, и ESX(i) начинают рабо- тать в режиме Evaluation, и 60 дней вам доступны абсолютно все функции vSphere, включая и Storage vMotion. Ну а ввести свой ключ продукта вы сможете и после завершения всех процессов обновления. 5. Если серверов ESX(i) версии 3.x у вас не остается, то сервер лицензий вам больше не нужен. Выполните следующие шаги: в клиенте vSphere перейди- те в раздел Home ⇒ Administration ⇒ Licensing. Там удалите упоминание о сервере лицензий. Затем удалите это приложение с сервера vCenter через «Add-or-Remove Program» (Установка и удаление программ).
    • 56 Установка vSphere 6. Теперь целесообразно будет обновить ВМ. Обновления потребуют версия виртуального оборудования и VMware Tools. Если есть отдельно стоящий ESXi, для обновления которого не получится ис-пользовать Update Manager, то придется использовать или командную строку, илиустановку новой версии поверх. Обновление версии виртуального оборудованияи VMware Tools для каждой ВМ в таком случае нужно будет провести вручную. Про все эти шаги теперь поговорим более подробно. 1.5.1. Обновление до vCenter Server 4 и Update Manager 4 Итак, у нас есть сервер (ВМ) с Virtual Center 2.x и Update Manager 1. Онимогут быть установлены на одной машине или разных – это не принципиально.Последовательность наших действий следующая: 1. Обновляем Virtual Center 2.x до vCenter 4. 2. Устанавливаем клиент vSphere – ПО для управления ESX(i) 4 и vCenter 4. Он пришел на смену клиенту для ESX3 и VC2 – Virtual Infrustructure Cli- ent, VIC. 3. Обновляем Update Manager 1 до Update Manager 4 (или устанавливаем VUM 4 с нуля, если раньше он не использовался). 4. Устанавливаем надстройку (plug-in) Update Manager 4 в клиент vSphere. Обновление Virtual Center 2.x до vCenter 4 Допустим, у вас есть сервер (ВМ) с установленным Virtual Center 2.5 (в случаедругой версии все примерно так же, если для этой версии в принципе поддержива-ется обновление до vCenter 4, – уточните это в документации). Обратите внимание. vCenter начиная с версии 4.1 может быть установлен лишь на 64-битную ОС. Если текущая версия vCenter использует 32-битную ОС, то про- цедура обновления будет немного сложнее описанной ниже – так как придется устанавливать новую версию vCenter в 64-битную ОС и затем обеспечить доступ- ность для этого vCenter старой базы данных. Подробности см. в статье базы знаний http://kb.vmware.com/kb/1022104. Если обновление vCenter сопряжено с миграци- ей на другую ОС, то конфигурацию, сертификаты и содержимое базы данных (если она расположена локально на сервере vCenter) можно легко переместить при по- мощи VMware Data Migration Tool (http://pubs.vmware.com/vsphere-esx-4-1/wwhelp/ wwhimpl/js/html/wwhelp.htm#href=upgrade/t_back_up_data_migration.html или http:// link.vm4.ru/tmqjw). Ваш первый шаг – остановить службу «VMware VirtualCenter Server». Далее,в производственной среде, рекомендуется создать резервную копию БД VirtualCenter. Затем запускайте мастер установки vCenter Server 4 – файл autorun.exeв корне дистрибутива. Выберите vCenter Server. Запустится мастер, большинство вопросов которого будут весьма стандартны: 1. Welcome Screen – нажмите Next . 2. EULA – отметьте I agree to the terms in the license agreement.
    • Обновление ESXi. ESX и vCenter с версий 3.х 57 3. Customer Information – укажите, на кого (User Name) и какую организа- цию (Organization) зарегистрирован этот экземляр vCenter. 4. Поле License key – здесь мы или указываем ключ продукта (его следует приобрести), или оставляем поле пустым, тем самым устанавливая vCen- ter в ознакомительном (Evaluation) режиме. В последнем случае мы полу- чим абсолютно полнофункциональный vCenter на 60 дней. По истечении этих 60 дней vCenter потребует ключ продукта и без него работать от- кажется. 5. Database Options – здесь необходимо указать настройки доступа к БД – пользователя, пароль. См. в «ESX and vCenter Server Installation Guide» подробности про требования и настройки БД для vCenter. Обратите вни- мание: возможна ситуация, когда Virtual Center 2.x работает с СУБД такой версии, которая не поддерживается vCenter 4.x. Тогда потребуется пред- варительно обновить еще и СУБД. Так что проверьте совместимость вашей СУБД и vCenter 4. Если в качестве БД используется локальная СУБД, на- пример SQL Server 2005 Express, то поля Database Username и Database password оставляем пустыми. 6. Если Update Manager стоит на этом же сервере, то нам покажут сообщение о несовместимости Update Manager 1 и vCenter 4. Нажмем OK. 7. Напомню, что рекомендуется выполнить резервное копирование БД Vir- tual Center 2.x до начала обновления его до vCenter 4. 8. Database upgrade warning – выберите Yes, I want to upgrade my vCen- ter database и I have taken a backup of the existing vCenter database. 9. vCenter Service – выберите в зависимости от требования БД. Например, если вы хотите использовать Windows authentication для SQL Server – то вам не подойдет значение этой настройки по умолчанию – учетная запись «System». 10. Configure Ports – какие сетевые порты использовать. 11. Ready to Complete – жмите Install. vCenter 4 требует больше ресурсов, чем Virtual Center 2.x. При числе серверов до 50 рекомендуется чтобы у сервера vCenter было дваядра и 4 Гб ОЗУ. До 300 серверов – четыре ядра и 8 Гб ОЗУ. До 1000 серверов – восемь процессоров и 16 Гб ОЗУ. Установка клиента vSphere Далее вам нужно установить vSphere Client на свой рабочий компьютер. Дис-трибутив клиента берется с любого из следующих мест: из дистрибутива vCenter – запустите autorun.exe и выберите пункт vSphere Client; с веб-интерфейса установленного vCenter 4; с веб-интерфейса установленного ESX(i) 4 (начиная с версии 4.1 ссылка на этой странице ведет на сайт VMware, а не на сам сервер ESX(i)). Сама по себе его установка проста, здесь останавливаться на ней не буду.
    • 58 Установка vSphere Обновление VMware Update Manager 1.0 до VMware vCenter Update Manager 4 Следующий шаг – обновление Update Manager 1.0 до Update Manager 4. Up-date Manager – это дополнительный компонент vCenter. Дополнительный в томсмысле, что вы можете его не устанавливать, но он всегда поставляется в комплек-те с vCenter, и дистрибутив Update Manager входит в дистрибутив vCenter. На сервере, где установлен Update Manager 1.0, запустите autorun.exe из корнядистрибутива vCenter. В списке компонентов выберите «vCenter Update Manag-er». Пройдите по шагам мастера (эти шаги одинаковы что при обновлении с VUM1 до VUM4, что при установке VUM 4 с нуля): 1. Welcome Screen – нажмите Next. 2. EULA – согласитесь с лицензионным соглашением. 3. vCenter Server Information – укажите данные для подключения к серве- ру vCenter: IP – IP-адрес сервера vCenter, Username/Password – имя и пароль пользователя, имеющего права администратора на сервере vCenter. 4. Database Information – настройки подключения к БД. Имя пользователя и пароль. В случае использования SQL 2005 Express эти поля оставляйте пустыми. 5. Database Upgrade – выберите Yes, I want to upgrade my Update Manager database и I have taken a backup of the existing Update Manager database. 6. vCenter Update Manager Port Settings – выберите IP-адрес, который бу- дет использоваться Update Manager (если их несколько на этом сервере). Этот адрес должен быть доступен с сервера vCenter и серверов ESX(i). При необходимости измените сетевые порты, которые должен использо- вать Update Manager. Если Update Manager будет обращаться в Интернет за обновлениями прямо с этой машины, поставьте флажок Yes, I have Inter- net connection and I want to configure proxy settings now. 7. Proxy Settings – укажите настройки прокси-сервера для доступа Update Manager в Интернет, если они необходимы. 8. Ready to Install the Program – нажмите Install. Установка надстройки (plug-in) Update Manager в клиент vSphere На предыдущем этапе мы установили Update Manager 4, а точнее сказать – егосерверную часть. Для работы же с ней потребуется часть клиентская. В данномслучае ей является plugin, надстройка – модуль расширения для клиента vSphere.После установки надстройки Update Manager в интерфейсе клиента vSphere по-явятся кнопки, закладки и пункты контекстного меню от Update Manager. Для установки надстройки запустите клиент, подключитесь к vCenter, выбе-рите меню Plug-ins ⇒ Manage Plug-ins. В открывшемся окне нажмите Download and install for the Update Managerplug-in. Завершите мастер установки надстройки.
    • Обновление ESXi. ESX и vCenter с версий 3.х 59 1.5.2. Обновление ESX(i) с помощью Update Manager Для обновления ESX(i) с помощью Update Manager выполните следующее. Запустите клиент vSphere. Пройдите Home ⇒ Solutions and Applications ⇒Update Manager. Создайте «Baseline» (объект Update Manager, являющийся списком обновле-ний) для обновления ESX(i) до версии 4. Для этого на закладке Baselines and Groupsвыберите Upgrade Baselines и нажмите ссылку Create в правом верхнем углу. От-кроется мастер создания нового baseline: 1. Baseline Name and Type Name – укажите имя создаваемого baseline, напри- мер ESX4. Baseline Type – укажите тип baseline. Мы планируем перейти на новую версию ESX(i), так что тип указываем Host Upgrade. 2. Select Upgrade Files ESX upgrade iso – через Browse укажите путь к за- ранее загруженному образу ISO дистрибутива ESX4 и/или к zip-архиву дистрибутива ESXi. 3. ESX Upgrade – COS VMDK Location – выберите, где будет расположен файл vmdk с файловой системой Service Console. 4. ESX Upgrade – Post upgrade options – здесь мы можем указать, надо ли пробовать откатить обновление в случае его неудачи, по умолчанию фла- жок установлен. Также если мы используем сценарии для автоматизации настройки ESX, то можем здесь указать их выполнение. Подробности про такие сценарии ищите в разделе про автоматизацию установки ESX. Теперь созданный Baseline необходимо назначить на серверы ESX(i). Можноназначать как на сервер, так и на папку (folder) или кластер серверов – последнее,скорее всего, будет для вас удобнее. Не волнуйтесь за кластер – саму установкуобновления мы можем делать на каждом сервере последовательно, необязательносразу на всех. Для назначения Baseline выполните следующее: 1. В клиенте vSphere выберите Hosts and Clusters, выберите объект, на кото- рый будете назначать baseline (например, кластер), и перейдите на заклад- ку Update Manager. 2. Нажмите Attach… в правом верхнем углу. Выберите созданный ранее base- line и нажмите кнопку Attach. 3. Теперь надо просканировать серверы на возможность и необходимость их обновления. 4. На сервере, папке с серверами или кластере вызовите контекстное меню и выберите пункт Scan for Updates. В появившемся окне установите фла- жок Upgrades и нажмите Scan. 5. В поле Recent Tasks появится новая задача Scan Entity. После ее заверше- ния можно переходить далее.
    • 60 Установка vSphere Выделите объект, на который вы назначали Baseline. Перейдите на закладкуUpdate manager. Выберите Baseline, созданный ранее. В окне пониже увидитесписок просканированных серверов и применимость к ним этого обновления. Об-новить получится те из них, что имеют статус Non-Compliant (не соответствуют). Теперь обновим эти серверы. Для начала необходимо будет освободить выбранный сервер (или несколько)от запущенных виртуальных машин. Выключите их или мигрируйте. Затем: 1. Вызовите контекстное меню для сервера или группы серверов в иерархии vCenter и выберите пункт Remediate. 2. В правой части открывшегося окна выберите наш baseline. 3. Примите лицензионное соглашение. 4. На шаге Host Remediation Options можно указать время запуска обнов- ления – прямо сейчас или позже, а также количество и интервал между попытками ввести сервер в режим обслуживания (maintenance). Чтобы сервер вошел в этот режим, необходимо, чтобы на нем не осталось ни од- ной работающей ВМ – возможно, вам придется вручную выключить или мигрировать часть виртуальных машин с этого сервера. 5. Нажимаем Finish и ждем окончания задачи Remediate Entity. На время об- новления обновляемый сервер приобретет статус disconnected – это нор- мально. После окончания процесса обновления сервер должен появиться в иерархииvCenter в обычном режиме, без статуса disconnected. Когда это произошло, можнопереходить к следующему этапу. Обратите внимание на то, что при таком обновлении ESX 3 на ESX 4 возможенвозврат обратно к третьей версии (соответствующее меню доступно при загрузкеESX). В частности, это означает, что разделы ESX 3 продолжают существовать изанимать место. 1.5.3. Обновление виртуального оборудования ВМ и VMware tools VMware рекомендует обновить версию виртуального оборудования ВМ и об-новить VMware tools. Это именно рекомендация – если перезагружать какие-тоВМ для вас проблематично, они будут продолжать работать и необновленными.Само собой, для них не будут доступны новые возможности ESX 4, зависящиеот виртуального оборудования, например горячее добавление памяти и другихустройств. Также не торопитесь обновлять версию оборудования, если вы предполагаетевероятность отката на 3-ю версию ESX, – ВМ с последней версией оборудованиябудут работать только на ESX версии 4. Для ВМ, созданных на ESX(i) версии 3, версия виртуального оборудова-ния – 4. Для ВМ ESX(i) 4 версия оборудования – 7. Обновить эту версию можно ивручную – в контекстном меню выключенной ВМ выбрать пункт Upgrade VirtualHardware. Но перед этим необходимо для включенной ВМ выбрать в контекст-
    • Обновление ESXi. ESX и vCenter с версий 3.х 61ном меню пункт Guest ⇒ Install/Upgrade VMware tools и пройти в гостевой ОСмастер установки/обновления VMware tools (мастер доступен для гостевых ОСWindows, для Linux см. документацию). Также можно выделить родительский объект для группы виртуальных машин(например, папку) и перейти на закладку Virtual Machines. Там можно рамкой вы-делить сразу группу ВМ и выбрать вышеуказанные пункты в контекстном менюсразу для всей группы. Однако если ВМ много, лучше эту задачу автоматизировать. Для этого опять воспользуемся Update Manager. Перейдем в клиенте vSphereв Home ⇒ Solutions and Applications ⇒ Update Manager. В левой нижней частиокна выберите Create… для создания Baseline Group. Запустится мастер: 1. Name and Type – укажите имя (например, Hardware&tools Upgrade) и тип – Virtual Machines and Virtual Appliance Baseline Group. 2. Upgrades: • VM Hardware Upgrades – выберите VM Hardware Upgrade to Match Host; • VM Tools Upgrades – выберите VMware tools Upgrade to Match Host. 3. Patches – не выбирайте ничего. 4. Ready to Complete – нажмите Finish. Теперь, как и в случае с обновлением серверов, эту Baselline Group необходимоназначить на те ВМ, которые будем обновлять. Затем просканировать ВМ на соот-ветствие этой Baseline Group. Для этого: 1. Перейдите в иерархию VMs and Templates, выделите ВМ или группу ВМ. Если вы планируете, пусть не сразу, обновить все ВМ – то удобнее всего выбрать Datacenter. 2. На закладке Update Manager нажмите Attach… и выберите созданную ра- нее Baseline Group (Hardware&tools Upgrade). 3. В контекстном меню этого объекта выберите Scan for Updates. В открыв- шемся окне оставьте только флажки VM Hardware upgrades и VMware Tools upgrades. Теперь ВМ со статусом Not-Compliant можно обновить. Для этого выберитеВМ или их группу, в контекстном меню нажмите Remediate. Запустится мастер: 1. Remediation Selection – выберем Baseline Group Hardware&tools Upgrade, созданную ранее. Если мастер запущен для нескольких ВМ, то в нижней ча- сти окна будет показан их список, и флажками можно будет выбрать лишь некоторые из них. Процесс обновления будет запущен для выбранных, и только для них. В столбце Version указывается версия виртуального обору- дования – по нему можно ориентироваться, какие машины уже обновлены. Напомню, что для ESX 4 штатной является версия 7. 2. Schedule – здесь мы указываем имя и описание задачи, а также расписа- ние ее запуска для работающих ВМ, выключенных ВМ и ВМ в состоянии паузы (suspend). Обратите внимание, что данное обновление применяется, только когда ВМ выключена. 3. Rollback Options – здесь мы указываем, делать ли снимок состояния ВМ перед применением этих обновлений. Если делать, то через какое время этот
    • 62 Установка vSphere снимок будет автоматически удален. Снимок состояния здесь является точ- кой возврата на случай, если обновление вызовет неработоспособность ВМ. Почему предлагают задать время его существования – чтобы вам не при- шлось помнить, что его надо удалить вручную. Снимки состояния для ВМ в производственной среде нужно применять аккуратно, и не рекомендуется оставлять снимок, если нужда в нем уже отпала. Подробности ищите в раз- деле, посвященном снимкам состояния (Snapshot). Рекомендации конкрет- но для данной задачи следующие: если у вас нет иных способов резервного копирования обновляемых ВМ – снимок состояния лучше сделать, чтобы можно было просто вернуться в исходное состояние в случае проблем. Вре- мя существования их лучше задать такое, чтобы вам хватило времени про- верить, все ли обновленные ВМ работают корректно, не надо ли какие-то возвращать на состояние до снимка. И успеть с этой проверкой до того, как созданные перед обновлением снимки состояния начнут удаляться. 4. Ready to Complete – нажмите Finish. Сначала следует обновить VMware tools, затем виртуальное оборудование.Для обновления версии оборудования ВМ должна быть выключена – и UpdateManager сам ее выключать НЕ будет. А для обновления VMware Tools ВМ должнабыть включена, и если вы задание Remediate назначили на выключенную или при-остановленную ВМ, то Update Manager сам включит их, обновит VMware Toolsи вернет в исходное состояние. Обратите внимание на шаблоны – если задачаRemediate назначена на шаблон ВМ, то Update Manager конвертирует его в ВМ,обновит VMware Tools и конвертирует обратно. Но если гостевая ОС в шаблонеу вас запечатана с помощью Sysprep (или какая-то аналогичная ситуация) – такоесамоуправство со стороны Update Manager не пригодно, и Remediate для такихшаблонов делать не следует. Обратите внимание. Для каких-то виртуальных машин статус VMware tools может быть указан как Unmanaged. Этот статус специально предусмотрен для тех ВМ, са- мостоятельное обновление VMware Tools для которых не рекомендуется, – для Virtual Appliance. Например, VMware Data Recovery. Если потребуется обновление, то будет выпущена новая версия этого Virtual Appliance. Важно: после обновления виртуального оборудования у сетевых контролле-ров ВМ поменяются MAC-адреса. Это может быть проблемой в случаях типа ре-зервирования IP на DHCP по MAC-адресу – так что учтите это заранее. Такжегостевая ОС будет воспринимать обновленные сетевые карты как новые, поэтомуих настройки не сохранятся (включая статически заданные IP-адреса). 1.5.4. Установка обновлений из командной строки В составе vSphere CLI есть утилита vihostupdate. С ее помощью можно уста-навливать обновления на ESX(i). Кроме того, с ее помощью могут быть установ-лены или обновлены компоненты ESXi, например HP CIM Providers.
    • Обновление ESXi. ESX и vCenter с версий 3.х 63 В локальной командной строке ESX работает утилита esxupdate с очень по-хожим синтаксисом. Перед обновлением выключите или переместите ВМ с обновляемого сервераи переведите его в режим обслуживания (Maintenance mode). Загрузите пакет об-новлений. Затем выполните следующие команды. Определите, какие из обновлений применимы: Если пакет расположен на сервере HTTP:vihostupdate.pl --server <server> --scan --bundle http://<webserver>/rollup.zip Если пакет размещен локально:vihostupdate.pl --server <server> --scan --bundle <local_path>/rollup.zip После аргумента --server следует имя или IP-адрес ESX(i). Кроме протоколаHTTP, могут использоваться HTTPS и FTP. Установите обновления на сервер:vihostupdate.pl --server <server> --install --bundle http://<webserver>/rollup.zip--bulletin bulletin1,bulletin2илиvihostupdate.pl --server <server> --install --bundle <local_path>/rollup.zip –bulletinbulletin1,bulletin2 Если не использовать аргумент –bulletin, то команда установит все содержи-мое из пакета. Проверьте, что обновления установились:vihostupdate.pl --server <server> --query Подробности доступны в документе «vSphere Upgrade Guide». 1.5.5. Отмена обновления ESX 3.x на ESX 4 В случае если обновление сервера прошло неудачно и вы делали именно об-новление, а не установку поверх, то есть возможность вернуться к работающейсистеме. Для этого в локальной консоли ESX (не ESXi, в нем такой возможностинет) выполните командуrollback-to-esx3 После этого перезагрузите сервер. Все упоминания о ESX 4 должны быть уда-лены, загрузится старый ESX 3. Файл виртуального диска (VMDK) Service Con-sole – esxconsole-<UUID> – необходимо будет удалить вручную.
    • 64 Установка vSphere Обратите внимание на ВМ, для которых вы успели обновить версию вирту-ального оборудования до 7, – они не заработают на ESX предыдущей версии. Есливам потребуется понизить версию виртуального оборудования с 7 на 4 (Down-grade), то для этой цели вам поможет VMware Converter. 1.6. Основы работы из командной строки Большинство операций с виртуальной инфраструктурой производятся из гра-фического интерфейса клиента vSphere. Однако и командная строка может нампригодиться: для некоторых операций, которые не возможны из графического интер- фейса; для автоматизации действий с помощью сценариев; для диагностики и решения проблем. У нас есть несколько способов для получения интерфейса командной строкик серверу ESX(i): локальная командная строка, доступная с локальной консоли или через iLO/IP KVM; сессия SSH к ESX(i); vSphere CLI. 1.6.1. Локальная командная строка ESX, SSH Этот небольшой раздел призван помочь тем из вас, у кого не было опыта рабо-ты с системами *nix. На хоть какую-то полноту я, разумеется, не претендую. Если на локальной консоли сервера ESX нажать Alt+F1, ввести имя пользо-вателя root и пароль, то вы попадете в командную строку. Это командная строкаService Console, модифицированного Red Hat Enterprise Linux 5. Это означает, что в этой командной строке работают все или большинствостандартных команд Linux. Те из них, что периодически мне пригождаются, я пе-речислил в табл. 1.1. Обратите внимание на то, что команды и ключи регистрозависимы. Небольшая иллюстрация действий из командной строки на примере настрой-ки доступа по SSH. На своем компьютере запустите клиент SSH, например PuTTY.Подключитесь к серверу ESX. Вам будет необходимо войти в систему, но пользо-вателем root сделать это по SSH нельзя – так по умолчанию настроен сервер SSHна ESX. Вариантов два: создать непривилегированного пользователя и входить в систему с его учетными данными; разрешить вход с учетными данными пользователя root. Первый вариант более правилен с точки зрения безопасности, второй частоболее удобен.
    • Основы работы из командной строки 65Таблица 1.1. Список основных команд Linux Команда Описаниеcd Смена текущей директорииcp Копирование файла. cp [файл 1] [файл2]find Поиск файлов по критериямls Список файлов и директорий в текущей или явно указанной директории. ls /vmfs/volumes/ ключи: -l подробная информация -a отображение скрытых файловmkdir Создание директорииmv Перемещение файла. Переименование файла. mv [путь и имя файла] [путь, куда перемещать]ps Информация о запущенных процессах. ps -efrm Удаление файловshutdown Выключение или перезагрузка сервера shutdown now shutdown –r nowvi Текстовый редакторnano Дружелюбный к новичкам текстовый редактор, отсутствует на ESXi nano /etc/hostscat Вывод содержимого файла на экран. cat /etc/hostsmore Вывод содержимого файла на экран, по странице за раз. more /etc/hostsman Справка по командам man <команда, по которой есть вопрос> для некоторых команд помощь выводится при запуске самой команды без пара- метровuseradd Создание пользователя. useradd <имя пользователя>passwd Задание пароля пользователю passwd <имя пользователя> Дополнительного пользователя вы можете создать: на этапе установки ESX; из клиента vSphere, подключенного напрямую к ESX. Home ⇒ Inventory ⇒ выделите сервер ⇒ закладка Users and Groups в контекстном меню вы- берите Add. Чтобы пользователь мог заходить по SSH, установите флажок Grant shell access; из командной строки, командами useradd и passwd; ввести сервер в домен Active Directory и авторизовываться учетными за- писями AD (см. главу 4). Когда у вас есть дополнительный пользователь, вы можете входить под нимв систему при подключении по SSH. После этого выполните команду
    • 66 Установка vSpheresu –и введите пароль пользователя root. В результате вы получаете привилегии root. Если же вы приняли решение просто разрешить пользователю root авторизациюпо SSH, то потребуется отредактировать конфигурационный файл сервера SSHnano /etc/ssh/sshd_config Найдите строкуPermitRootLogin noи поменяйте ее наPermitRootLogin yes. После этого перезапустите службу SSH командойservice sshd restart В состав Service Console входят некоторые специфичные для ESX команды.Список большинства из них вы можете получить, набрав в командной строкеesxcfg-и два раза нажав Tab. Информацию об этих командах и их соотношение с командами удаленной ко-мандной строки см. в разделе 1.6.4. 1.6.2. Локальная командная строка ESXi, SSH VMware не рекомендует открывать доступ к командной строке и SSH дляESXi – из общих соображений безопасности. Однако если вы приняли решениепренебречь этой рекомендацией, сделать это несложно. Для доступа в командную строку в локальной консоли ESXi эта возможностьдолжна быть разрешена. В интерфейсе клиента vSphere сделать это можно, пройдяConfiguration ⇒ Security Profile ⇒ Properties ⇒ Local Tech Support. Через локальное БИОС-подобное меню также можно открыть доступ к ло-кальной командной строке, пройдите Troubleshooting Options ⇒ Enable LocalTech Support. После нажатия Enter название пункта меню должно поменяться наDisable Local Tech Support – это значит, что локальная командная строка вклю-чена, а этим пунктом ее можно отключить обратно. Так или иначе разрешив доступ к локальной командной строке, нажмитеAlt+F1 и авторизуйтесь. Появится приглашение к вводу команд~#
    • Основы работы из командной строки 67 Вы вошли в локальную консоль. Включение SSH выполняется точно так же (в БИОС-подобном меню илив пункте настроек Security Profile), только теперь вас интересует пункт RemoteTech Support. Теперь вы можете подключаться по SSH. В состав ESXi входит маленький дистрибутив Linux под названием Busybox.Основные команды Linux (табл. 1.1) в нем работают. Подсмотреть прочие доступные для Busybox команды можно, выполнив/usr/bin/busybox В состав ESXi входят некоторые из команд, специфичных для ESX(i). Списокбольшинства из них вы можете получить, набрав в командной строкеesxcfg-и два раза нажав Tab. Однако информацию об этих командах и их соотношение с командами удален-ной командной строки см. в разделе 1.6.4. Список специфичных команд на ESXi меньше, чем на ESX. Для ESXi следуетпользоваться vSphere CLI, в состав которых входит большее количество команд. Впрочем, в составе ESXi существуют некоторые специфические инструменты. Один из полезных – командаvim-cmd vmsvc Набрав эту команду, вы увидите все возможные варианты ее использования.Например, командойvim-cmd vmsvc/power.getstate <ID виртуальной машины>вы узнаете статус питания виртуальной машины с указанным ID. Увидеть список ВМ и их ID вы можете при помощи командыvim-cmd vmsvc/getallvms 1.6.3. vSphere CLI, работа с vMA vSphere CLI – это инструмент, который позволяет централизованно управ-лять из командной строки серверами ESX и ESXi. Более того, некоторые командыможно и удобно направлять на vCenter Server. vSphere CLI представляют собой набор сценариев, которые выполняются натом компьютере, где vSphere CLI установлен. При выполнении сценарий обраща-ется к API на указанном сервере ESX(i) или сервере vCenter и выполняет своюработу на этом сервере. vSphere CLI являются удобным интерфейсом командной строки для ESXi иESX. Однако на ESXi с бесплатной лицензией vSphere CLI работают в режиме
    • 68 Установка vSphereтолько чтения (read-only). Это означает, что вы можете использовать ее для про-смотра каких-то свойств и значений, но не сможете их изменять. vSphere CLI поставляются в трех вариантах: дистрибутив под Windows; дистрибутив под Linux; в составе vSphere Management Appliance, vMA. Здесь я подробнее остановлюсь на последнем варианте. vMA – это виртуальная машина с предустановленной ОС и набором продук-тов. Она очень похожа на централизованную Service Console. В ней установленыvSphere CLI, которые позволяют централизованно выполнять команды команд-ной строки на нескольких серверах ESX(i). Начать пользоваться vMA очень просто: 1. Загружаем сам продукт с сайта VMware (http://communities.vmware.com/ community/vmtn/vsphere/automationtools/vima). Распаковываем из архи- ва файл ovf (Open Virtualization Format). 2. Запускаем клиент vSphere и импортируем виртуальную машину vMA в нашу виртуальную инфраструктуру. Это делается из меню File ⇒ Deploy OVF Template. 3. Включаем импортированную ВМ. Открываем консоль к ней. При первом включении от нас спросят настройки IP и пароль пользователя vi-admin. Теперь выполним начальную настройку в локальной консоли vMA или под-ключившись к ней по SSH. Авторизуйтесь пользователем vi-admin. С помощьюкомандыvifp addserver <servername>добавьте свои серверы ESX(i) и vCenter. От вас попросят указать пароль пользова-теля (root для ESX(i) или учетную запись Windows, имеющую административныеправа для vCenter). В дальнейшем вводить учетные данные при запуске сценариевне придется. Проверить список зарегистрированных серверов можно командойvifp listservers Затем самым удобным, на мой взгляд, будет следующее: укажите целевой сер-вер командойvifptarget -s <servername> Теперь любая команда vSphere CLI будет выполнена в отношении указанногосервера. Проверьте работоспособность сделанных настроек:vicfg-nics --list Эта команда должна отобразить список физических сетевых контроллеровсервера ESX(i).
    • Основы работы из командной строки 69 Выполняя командуvifptarget -s <servername>вы можете менять целевые серверы. Чтобы обнулить указание целевого сервера иопять работать только в командной строке vMa, выполните командуbash Это не единственный вариант настройки аутентификации на серверах ESX(i)при выполнении команд vSphere CLI, в первую очередь обратите внимание на воз-можность ввести vMA в домен Active Directory и использовать его возможностидля аутентификации в vSphere. Но остальные кажутся мне более специфичнымии/или менее удобными в повседневной работе, так что приводить здесь их не буду. Обратите внимание. Если вам потребуется изменить сетевые настройки для vMA, то проще всего это осуществить, выполнив в локальной консоли vMA команду sudo/ opt/vmware/vima/bin/vmware-vima-netconf.pl. За дополнительной информацией обращайтесь в документ «vSphere Manage-ment Assistant Guide», доступный на http://vmware.com/go/vma4. 1.6.4. Полезные команды В тексте книги я иногда буду приводить какие-то команды для выполнениятех или иных действий. Большинство этих команд можно запустить как в локаль-ной командной строке (или через SSH), так и через vSphere CLI. В табл. 1.2 я перечислил многие из полезных команд. В столбцах «Локальнов ESXi» и «Локально в ESX» я указал доступность той или иной команды в ло-кальной командной строке, в столбце «Аналог в CLI ESX» – какое имя имеет ко-манда в локальной командной строке. Несложно заметить, что большинство локальных команд начинаются на esx-cfg-, аналогичные им команды vSphere CLI – на vicfg-. Однако команды esxcfg-в vSphere CLI также доступны, и запускают они соответствующую команду vicfg-.Так сделано для упрощения совместимости ранее созданных сценариев. Синтаксис команд в локальной командной строке и в vSphere CLI практиче-ски идентичен. Многие команды отличаются только тем, что при запуске их изvSphere CLI необходимо указать целевой сервер (ESX(i) или сервер vCenter).Имя сервера указывается после ключа --server (если выполнено указание целево-го сервера на сеанс командой vifptarget -s <servername> то явно указывать серверв самой команде необходимости нет). Для получения справки большинство команд достаточно запустить без параме-тров. Правда, как правило, объем справочной информации значительно превышаетодин экран. Так что для ее просмотра вам пригодится команда «more» из табл. 1.1.В случае же если вы предпочитаете читать красиво форматированный текст – най-дите подробную справку по синтаксису команд в документации VMware.
    • 70 Установка vSphereТаблица 1.2. Список полезных команд vSphere CLI и локальной командной строки Команда Локально Локально Аналог Описание vSphere CLI в ESXi в ESX в CLI ESXesxcli + + esxcli Управление PSA и Multipathingresxtop + + esxtop Мониторинг системных ресуровsvmotion – – Запуск Storage VMotionvicfg-advcfg + + esxcfg-advcfg Изменение расширенных настроекvicfg-cfgbackup + – esxcfg- Резервная копия настроек ESXi cfgbackupvicfg-dns – – esxcfg-dns Настройка DNSvicfg-dumppart + + esxcfg- Доступ к диагностическим dumppart даннымvicfg-iscsi + + esxcfg-hwiscsi Настройка iSCSI (программного и esxcfg-swiscsi и аппаратного)vicfg-module + + esxcfg-module Управление модулями VMkernelvicfg-mpath + + esxcfg-mpath Вывод информации о путях к LUNvicfg-nas + + esxcfg-nas Настройка доступа к NASvicfg-nics + + esxcfg-nas Настройка физических NICvicfg-ntp + + esxcfg-ntp Настройки сервера NTPvicfg-rescan + + esxcfg-rescan Сканирование СХД, обнаружение новых LUN и разделов VMFSvicfg-route + + esxcfg-route Настройка маршрутизацииvicfg-scsidevs + + esxcfg-scsidevs Информация об устройствах храненияvicfg-snmp + + esxcfg-snmp Управление агентом SNMPvicfg-vmknic + + esxcfg-vmknic Управление интерфейсами VMkernelvicfg-volume + + esxcfg-volume Перемонтирование разделов VMFSvicfg-vswitch + + esxcfg-vswitch Управление виртуальными коммутаторамиvihostupdate + + esxupdate Установка обновленийvmkfstools + + vmkfstools Управление разделами. VMFS Управление файлами vmdkvmware-cmd + + vmware-cmd Управление состоянием ВМ. Включение, выключение, снапшоты и прочее 1.6.5. Полезные сторонние утилиты При работе с ESX(i) нам могут потребоваться некоторые действия, невозмож-ные при помощи клиента vSphere. Это такие действия, как: командная строка, в том числе для изменения конфигурационных файлов и просмотра журналов;
    • Основы работы из командной строки 71 графический файловый менеджер для работы с файлами ESX(i), в первую очередь изменения конфигурационных файлов и просмотра журналов; графический файловый менеджер для работы с файлами виртуальных ма- шин. Копирование, перемещение, изменение, загрузка на ESX(i), выгрузка с ESX(i). Перечислю основные бесплатные утилиты, которые могут вам помочь в этихоперациях. Командная строка Для работы в командной строке могу посоветовать две утилиты – клиент SSHпод названием PuTTY и небольшую оболочку к нему PuTTY Connection Manager,добавляющую интерфейс закладок. PuTTY можно загрузить с веб-сайта по адресу http://www.putty.org/. Запусти-те программу, укажите адрес вашего сервера ESX, ESXi (если вы включили серверSSH на нем) или vMA (рис. 1.18). Рис. 1.18. Подключение с помощью PuTTY Добавить удобства в работе с несколькими серверами вам поможет утилитаPuTTY Connection Manager (рис. 1.19). Сайт этой утилиты – http://puttycm.free.fr. Файловый менеджер На случай, когда вам необходимы манипуляции с файлами виртуальных ма-шин, самым удобным средством я считаю Veeam FastSCP (http://www.veeam.com/ru/product.html). Это специализированный файловый менеджер именно дляvSphere. C его помощью вы легко и удобно получите доступ к файлам виртуаль-
    • 72 Установка vSphere Рис. 1.19. Окно PuTTY Connection Managerных машин. Вернее, к любым файлам на хранилищах VMFS и NFS-хранилищахваших серверов (рис. 1.20). С помощью этой утилиты легко организовать копирование файлов между хра-нилищами разных серверов или между серверами ESX(i) и Windows (в первуюочередь имеется в виду резервное копирование). Еще одна утилита, о которой хочу здесь упомянуть, – файловый менеджерWinSCP (http://winscp.net). C его помощью можно подключиться к серверу ESX,а к ESXi – лишь при условии включения сервера SSH (рис. 1.21). После подключения этой утилитой вы увидите двухпанельный файловый ме-неджер. В левом окне всегда система Windows, с которой вы подключились, а в пра-вом – ESX(i), к которому вы подключились. Примечательно, что с помощью этойутилиты вы получаете доступ к файловой системе Linux из состава ESX(i). Этоозначает, что, зайдя в каталог /etc, вы найдете большинство конфигурационныхфайлов. В каталоге /var/logs вам доступны файлы журналов. В каталог /vmfs/volumes подмонтируются хранилища. Вспомогательные утилиты Последняя утилита, о которой хотелось бы тут упомянуть, – утилита RVtools.Подключившись с ее помощью к серверу vCenter, вы сможете в удобном виде по-
    • Основы работы из командной строки 73 Рис. 1.20. Окно FastSCP Рис. 1.21. Настройки подключения WinSCPлучить полезные данные об инфраструктуре. Особо интересной может оказатьсявкладка vHealth с информацией о потенциальных проблемах (рис. 1.22). Утилита доступна по адресу http://www.robware.net.
    • 74 Установка vSphere Рис. 1.22. Утилита RVTools 1.7. Сайзинг и планирование В этом разделе мне бы хотелось обозначить некоторые вопросы сайзинга ап-паратного обеспечения под vSphere. Вопрос вида «какой сервер выбрать под лю-бимый гипервизор» – один из популярных и самых раздражающих – потому чтотакая формулировка вопроса не корректна. То, что написано далее, ни в коей мере не «Полное и абсолютное руководствопо подбору оборудования всегда», нет. Это немного теории про то, что такое про-изводительность, – как показывает мой пятилетний опыт ведения ИТ-курсов,даже у самых опытных людей бывают пробелы в обыденных для кого-то другоговещах. Это небольшие нюансы выбора оборудования, связанные именно с вирту-ализацией. Это вопросы, на которые нельзя давать ответ абстрактно, но о которыхстоит задуматься, имея на руках данные конкретного случая. Итак – нам нужно оборудование под ESX(i). Что дальше? Самое главное для понимания, пусть и очевидное до невозможности, – этоследующее соображение: Количество ресурсов, которыми должен обладать сервер под ESX(i), зависитот суммы требований для выполнения всех задач, которые мы собираемся выпол-нять в ВМ на этом сервере. И еще от того, будем ли мы использовать некоторыефункции vSphere (в первую очередь HA/FT), так как эти функции требуют ресур-сов сверх необходимых для работы ВМ. Поговорим про все подсистемы – процессор, память, диски, сеть. Самая боль-шая и сложная тема – это дисковая подсистема. Должна ли она быть представленасистемой хранения данных (СХД) или обойдемся локальными дисками сервера –
    • Сайзинг и планирование 75это вопрос относительно простой. Есть бюджет на СХД – она нам нужна ☺. На нети суда нет. Какую именно СХД использовать – будет ли это система с подключе-нием по оптике, Fibre Channel SAN? Или достаточно будет 1 Гбит подключенияEthernet и это будет iSCSI SAN? Или это будет iSCSI, но с 10 Гбит подключением?Или NFS? Вариантов масса. Какие диски там будут стоять? Или стоит задуматьсяне о дисках, а о SSD-накопителях? В любом случае, вам необходимо опираться на цифры. Цифры по нагрузкесуществующих систем, которые вы планируете переносить в виртуальную среду.Или цифры по планируемой нагрузке приложений, которые вы собираетесь до-бавлять в виртуальную среду. Для уже существующей инфраструктуры статистику использования той илииной подсистемы имеет смысл получать с помощью соответствующих средствмониторинга. Мне известно решение от Майкрософт – System Center OperationsManager (OpsMgr, SCOM). Ну а наиболее правильно и удобно использовать специализированное сред-ство анализа инфраструктуры для ее виртуализации – VMware Capacity Planner.Услуги по обследованию с его помощью оказывают компании-партнеры VMware. Для планируемых систем цифры по предполагаемой нагрузке берутся из техже источников, что и при сайзинге физических серверов, – из соответствующейдокументации, нагрузочных тестов и опыта. 1.7.1. Процессор Мне видятся два момента, связанных с выбором процессоров в сервер подESX(i). Первый – какой производительностью они должны обладать, и второй – на-кладываются ли на процессоры какие-то условия с точки зрения некоторых функ-ций vSphere. Про производительность поговорим чуть позже, сейчас про функционал. Выбор процессоров с точки зрения функционала Процессор – это единственный компонент сервера, который не виртуализи-руется. Это означает, что гостевая ОС видит тактовую частоту и, самое главное,наборы инструкций (типа SSE4 и т. п.) физического процессора. Если ВМ простои без затей работает на каком-то ESX-сервере, то от такого положения вещей намни холодно, ни жарко. Проблемы начинаются, если мы хотим осуществить живуюмиграцию (ту, что у VMware называет vMotion) этой ВМ на другой ESX(i). Вывод: если мы предполагаем использование vMotion, то ЦП на этих серверахдолжны быть одинаковыми. Раскроем нюансы. «Одинаковость» здесь должна быть по функциям этих процессоров. Напри-мер, набор инструкций SSE 4.2 – если их поддерживает ЦП сервера, то наличиеэтих инструкций увидит и гостевая ОС. Если на ЦП другого сервера этих инструк-ций не будет, а мы мигрируем включенную ВМ на этот сервер, то гостевая ОСчрезвычайно удивится невозможности использовать то, что только что было до-
    • 76 Установка vSphereступно. И может умереть, сама ОС или приложение. Чтобы такого не было, vCen-ter в принципе не даст нам мигрировать ВМ между серверами с разными ЦП. Резюме: не важны тактовая частота, размер кеш-памяти и количество ядер.Важны поддерживаемые функции, то есть поколение ЦП, версия прошивки и(важно!) настройки BIOS. Некоторые функции могут включаться/выключать-ся из BIOS, поэтому вроде бы одинаковые ЦП могут оказаться несовместимымис точки зрения vMotion. Кстати говоря, не всегда легко найти отличия в настрой-ке. В моей практике в таких ситуациях помогал сброс настроек BIOS на значенияпо умолчанию. Далее. Забудьте предыдущий абзац. ☺ Еще в ESX 3.5 Update 2 и тем более в версии 4 VMware реализовала и пред-лагает нам функцию EVC – Enhanced vMotion Compatibility. Суть этой функции –в том, что мы можем «привести к единому знаменателю» разные ЦП на группесерверов. Например, у нас есть серверы с ЦП поновее – поддерживающие наборыинструкций до SSE 4.2. И есть серверы с ЦП постарше, поддерживающие наборинструкций SSE 4. Если мы объединим две эти группы серверов и включим дляних EVC, то более новые ЦП выключат у себя SSE 4.2. И все эти серверы (их ЦП)станут совместимы для vMotion. Однако для работы EVC требуется, чтобы все процессоры поддерживали тех-нологию «AMD-V Extended Migration» или «Intel VT FlexMigration». Это: для AMD: процессоры Opteron™ начиная с моделей Rev. E/F; для Intel: начиная с Core™ 2 (Merom). Подробную информацию о моделях можно почерпнуть или в списке совме-стимости, или в статье базы знаний http://kb.vmware.com/kb/1003212. Резюме: если мы приобретаем процессоры с поддержкой этой технологии, томы можем не волноваться – совместимость для vMotion будет обеспечена. Ценойэтому будет недоступность части новых функций в новых ЦП. Как правило, этоболее чем допустимая жертва. Надо понимать, что vMotion между серверами с процессорами разных произ-водителей (c AMD на Intel и обратно) невозможен ни при каких условиях. Попытаюсь резюмировать. 1. Если вы выбираете процессоры в сервер под ESX, предполагаете использо- вание живой миграции aka vMotion и • это будут первые ESX(i) серверы вашей инфраструктуры – то выбирать можно достаточно свободно (см. еще соображения по производитель- ности). Если в среднесрочной перспективе планируется докупать еще серверы, то лучше сейчас выбирать процессоры поновее (из последней группы совместимости EVC), чтобы в будущих серверах еще были до- ступны к заказу такие же (или представители той же группы); • у вас уже есть несколько ESX(i)-серверов, к ним надо докупить еще. Процессоры с поддержкой EVC можно использовать в одном «класте- ре EVC» с процессорами, не поддерживающими Extended Migration / FlexMigration. В таком случае процессоры без поддержки EVC должны быть одинаковы между собой.
    • Сайзинг и планирование 77 2. Если vMotion не предполагается к использованию, то обращать внимание нужно лишь на соображения производительности. Однако в силу того, что на момент написания у VMware остались только две редакции vSphere, не включающие vMotion, – Free и Essentials, лучше исходить из возможного включения vMotion в будущем. Если процессоры у нас не поддерживают EVC, то совместимость ЦП можнообеспечить на уровне настроек ВМ. По эффекту это похоже на EVC, но выпол-няется вручную и на уровне отдельной ВМ, а не группы серверов. Правда, этавозможность является неподдерживаемой. Вас интересует настройка Options ⇒CPUID Mask ⇒ Advanced. Наконец, можно просто отключить проверку совме-стимости ЦП на уровне настроек vCenter. Подробности см. в соответствующемразделе – про vMotion. Вторая после vMotion функция, которая обладает собственными требования-ми к процессорам, – это VMware Fault Tolerance, FT. Для серверов, на которых работает VMware Fault Tolerance, должны выпол-няться все условия для vMotion. Плюс к тому тактовые частоты процессоров наразных серверах не должны отличаться более чем на 300 МГц. Наконец, эта функ-ция работает только на процессорах из списка: Intel 31xx, 33xx, 34xx, 35xx, 36xx, 52xx, 54xx, 55xx, 56xx, 65xx, 74xx, 75xx; AMD 13xx, 23xx, 41xx, 61xx, 83xx. Актуальную информацию о моделях процессоров для FT ищите в статье базызнаний VMware № 1008027 (http://kb.vmware.com/kb/1008027). Выбор процессоров с точки зрения производительности На производительность процессорной подсистемы оказывают влияние: 1) количество ядер (ну и самих процессоров, само собой); 2) их тактовая частота; 3) размер кеш-памяти; 4) поддерживаемые инструкции. В идеале мы покупаем самый новый процессор (с максимумом поддерживае-мых инструкций), с максимальным размером кеша, максимальными тактовой ча-стотой и количеством ядер. В реальности же это не всегда возможно, да и не всегдаоправдано. Самое эффективное в общем случае – использовать меньше процессорных со-кетов и больше ядер, из тех соображений, что ESX(i) лицензируется на процессо-ры. Получим более эффективное соотношение цены и производительности. Но незабываем о том, что ESXi с бесплатной лицензией заработает на сервере не болеечем с двумя процессорами, и для всех лицензий, кроме Advanced и Enterprise Plus,возможно использование процессоров не более чем с шестью ядрами (информа-ция верна на момент написания). Еще один нюанс: один виртуальный процессор равен одному ядру физическо-го сервера как максимум. Нельзя взять два физических ядра и объединить в одно
    • 78 Установка vSphereвиртуальное, можно только «поделить» одно физическое на несколько виртуаль-ных. Поэтому чем большей частотой будут обладать выбранные вами процессоры,тем большей максимальной производительностью будет обладать один виртуаль-ный процессор. Остальное, по моему мнению, менее критично. Что такое и зачем надо Intel-VT / AMD-V. Аппаратная поддержка виртуализации Процессор исполняет инструкции. Эти инструкции выполняются с тем илииным приоритетом, который традиционно называется «кольцом» (ring). Кольцо0 имеет наибольший приоритет, и именно в этом кольце работает ядро ОС, управ-ляющее всеми ресурсами. Но. В случае использования виртуализации ОС несколько, и ресурсами серве-ра должен управлять гипервизор, распределяя эти ресурсы между ОС в ВМ. Вы-ходов несколько: в ESX(i) реализована технология под названием «Binary translation» – про- граммный механизм «вытеснения» ядра гостевой ОС из нулевого кольца. ESX(i) на лету подменяет инструкции процессора таким образом, что рабо- тают они на уровне выше нулевого кольца, а ядру гостевой операционной системы кажется, что оно на самом деле в нулевом кольце. Таким образом, ESX(i) может работать на процессорах без аппаратной поддержки виртуали- зации. Гипервизор работает в кольце 0. Это самый старый механизм, который в наше время считается унаследованным. Он обладает самыми высокими на- кладными расходами и вообще не работает для 64-битных гостевых ОС; паравиртуализация ОС. Ядро гостевой ОС может быть изменено для кор- ректной работы в ВМ – тогда гипервизору не требуется принудительно «вы- гонять» ядро из нулевого кольца. В силу необходимости изменения кода ОС на уровне ядра, притом изменения разного рода для разных гипервизоров, паравиртуализация не стала массовой. Тем не менее использование паравир- туализованных ОС в ВМ на современных гипервизорах позволяет снизить накладные расходы на виртуализацию. Известные мне источники говорят о примерно 10%-ной разнице по сравнению с непаравиртуализованными ОС. Для запуска паравиртуализованных гостевых ОС нет необходимости в аппаратной поддержке виртуализации. Паравиртуализация де-факто мало актуальна для ESX(i), поэтому здесь упоминается для полноты картины; та самая аппаратная поддержка виртуализации. Она реализуется с помо- щью технологий Intel VT (Virtualization Technology) или AMD-V. Если процессор обладает этой возможностью, то это означает, что он предостав- ляет для гипервизора специфический приоритет. Этот приоритет обычно называют кольцо –1 (минус один). Специфичность проявляется в том, что исполняемые в этом кольце инструкции, с одной стороны, еще приоритет- нее, чем инструкции кольца нулевого; а с другой – в минус первом кольце могут исполняться не все инструкции. Впрочем, все, необходимые гипер- визору, в наличии. Таким образом, если процессоры сервера обладают аппа- ратной поддержкой виртуализации, то гипервизор на таком сервере может
    • Сайзинг и планирование 79 запускать любые гостевые операционные системы без необходимости их модификации. Этот режим является штатным для ESX(i). Уже несколько лет все выпускаемые серверные (да и не только серверные) про-цессоры аппаратно поддерживают виртуализацию. Если вы работаете с не оченьсовременным сервером, обратите внимание на этот аспект отдельно. Дело в том,что поддержка аппаратной виртуализации должна быть реализована не тольков процессоре, но и в материнской плате (возможно, потребуется обновление BIOS). Однако возможность реализовать виртуальную инфраструктуру даже на сер-верах без аппаратной поддержки виртуализации является архиполезной, если по-добная задача перед вами все-таки встала. 1.7.2. Память К ОЗУ требований особо нет. Ее просто должно быть достаточно. Грубая оцен-ка достаточного объема: 1. Берем информацию о том, сколько памяти необходимо каждой ВМ. Сум- мируем. Округляем до удобного для установки в сервер объема. 2. Хотя при сайзинге это учитывать не следует, но часть памяти окажется сво- бодной. В этом помогут механизмы ESX(i) по работе с памятью. Учитывать же при планировании эти механизмы не рекомендуется по причине того, что в общем случае эффект экономии не гарантируется. Впрочем, вы може- те вывести и использовать свой коэффициент в зависимости от собствен- ного опыта, понимания специфики планируемой нагрузки и готовности идти на риск не полностью сбывшихся прогнозов. 3. Кроме того, разные ВМ могут действительно использовать свою память полностью в разное время. Следовательно, суммарный объем занятой па- мяти на сервере в среднем окажется меньше суммарного объема памяти, выделенной для всех виртуальных машин. На этот эффект тоже не реко- мендуют полагаться при сайзинге. 4. По причинам из пунктов 2 и 3 делать большой запас по памяти не следует. Впрочем, большинство инфраструктур имеют обыкновение расти и в сторо- ну увеличения количества ВМ, и в сторону увеличения нагрузки на суще- ствующие ВМ, так что при такой перспективе памяти лучше взять больше. 1.7.3. Дисковая подсистема Когда мы говорим про ресурсы дисковой подсистемы, то назвать их можнотри: объем места, скорость чтения и записи в Мб/сек и скорость чтения-записив количестве операций ввода-вывода в секунду (Input/Output per second, IOPS,или просто I/O). Поговорим сначала про объем. Я приведу соображения, на которые следуеториентироваться, и пример расчета. Соображения следующие: место на диске занимают сами файлы-диски виртуальных машин. Следова- тельно, нужно понять, сколько места нужно им;
    • 80 Установка vSphere если для всех или части ВМ мы планируем использовать тонкие (thin) дис- ки, то следует спланировать их первоначальный объем и последующий рост (здесь и далее под thin-дисками понимается соответствующий тип vmdk- файлов, то есть функция thin provisioning в реализации ESX(i). Дело в том, что функционал thin provisioning может быть реализован на системе хране- ния независимо от ESX(i), и я имею в виду не функционал систем хранения); по умолчанию для каждой ВМ гипервизор создает файл подкачки, по раз- мерам равный объему ее оперативной памяти. Этот файл подкачки распо- лагается в папке ВМ (по умолчанию) или на отдельном LUN; если планируются к использованию снимки состояния, то под них тоже следует запланировать место. За точку отсчета можно взять следующие со- ображения: • если снимки состояния будут существовать короткий период после соз- дания, например только на время резервного копирования, то под них запасаем процентов десять от размера диска ВМ; • если снимки состояния будут использоваться со средней или непрогно- зируемой интенсивностью, то для них имеет смысл заложить порядка 30% от размера диска ВМ; • если снимки состояния для ВМ будут использоваться активно (что ак- туально в сценариях, когда ВМ используются для тестирования и разра- ботки), то занимаемый ими объем может в разы превышать номинальный размер виртуальных дисков. В этом случае точные рекомендации дать сложно, но за точку отсчета можно взять удвоение размера каждой ВМ. (Здесь и далее под снимком состояния понимается соответствующий функционал ESX(i). Дело в том, что снимки состояния (snapshot) могут быть реализованы на системе хранения независимо от ESX(i), и я имею в виду не функционал систем хранения.) Примерная формула выглядит следующим образом: Объем места для группы ВМ = Количество ВМ × (Размер диска × T + + Размер диска × S + Объем памяти – Объем памяти × R). Здесь: T – коэффициент тонких (thin) дисков. Если такие диски не используются, равен 1. Если используются, то абстрактно оценку дать сложно, зависит от характера приложения в ВМ. По сути, thin-диски занимают места на си- стеме хранения меньше, чем номинальный размер диска. Так вот – этот коэффициент показывает, какую долю от номинального размера занимают диски виртуальных машин; S – размер снимков состояния. 10/30/200 процентов, в зависимости от про- должительности непрерывного использования; R – процент зарезервированной памяти. Зарезервированная память в файл подкачки не помещается, файл подкачки создается меньшего размера. Раз- мер его равен: объем памяти ВМ минус объем зарезервированной памяти. Оценочные входные данные, для примера, см. в табл. 1.3.
    • Сайзинг и планирование 81Таблица 1.3. Данные для планирования объема дисковой подсистемы Размер Исполь- Средний Примерный Резерви- Количе- дисков зуются размер Группа ВМ размер рование ство ВМ одной тонкие ОЗУ ВМ, снапшотов ОЗУ, % в группе ВМ, Гб диски? ГбИнфраструктура 20 Нет 10% 2 0 15Серверы приложений 20 + 20 Нет 10% 2 0 20Критичные серверыприложений 20 + 80 Нет 10% 6 50 10Тестовые и временные 20 Да 200% 2 0 20 Получаем оценку требуемого объема: инфраструктурная группа – 15 × (20 + 20 × 10% + 2 – 2 × 0) = 360 Гб; серверы приложений – 20 × (40 + 40 × 10% + 2 – 2 × 0) = 920 Гб; критичные серверы – 10 × (100 + 100 × 10% + 6 – 6 × 0.5) = 1130 Гб; тестовые и временные – 20 × (20 × 30% + (20 × 30%) × 200% + 2 – 2 × 0) = = 400 Гб. Всего получаем 2810 Гб. Обычно рекомендуется размещать 8–15 ВМ на одинLUN. Размер одного LUN ограничен как абсолютный максимум 2 Тб минус 512 байт. Следовательно, мы можем создать два LUN по 1,4 Тб и примерно поровнураспределить между ними виртуальные машины. Или создать 4–5 LUN по 600–800 Гб и поместить машины разных групп на разные LUN. Оба варианта (и про-межуточные между ними) приемлемы. Выбор между ними делается, исходя изпрочих предпочтений (например, организационных). Еще одним ресурсом дисковой подсистемы является производительность.В случае виртуальных машин скорость в Мб/сек не является надежным критери-ем, потому что при обращении большого количества ВМ на одни и те же диски об-ращения идут непоследовательно. Для виртуальной инфраструктуры более важ-ной характеристикой является количество операций ввода-вывода (IOPS, Input/Output per second). Дисковая подсистема нашей инфраструктуры должна позво-лять больше этих операций, чем их запрашивают виртуальные машины. Какой путь проходят обращения гостевой ОС к физическим дискам в общемслучае: 1. Гостевая ОС передает запрос драйверу контроллера SAS/SCSI (который для нее эмулирует гипервизор). 2. Драйвер передает его на сам виртуальный контроллер SAS/SCSI. 3. Гипервизор перехватывает его, объединяет с запросами от других ВМ и передает общую очередь драйверу физического контроллера (HBA в слу- чае FC и аппаратного iSCSI или Ethernet-контроллер в случае NFS и про- граммного iSCSI). 4. Драйвер передает запрос на контроллер. 5. Контроллер передает его на систему хранения, по сети передачи данных. 6. Контроллер системы хранения принимает запрос. Запрос этот – операция чтения или записи с какого-то LUN или тома NFS.
    • 82 Установка vSphere 7. LUN – это «виртуальный раздел» на массиве RAID, состоящем из физиче- ских дисков. То есть запрос передается контроллером СХД на диски этого массива RAID. Где может быть узкое место дисковой подсистемы: скорее всего, на уровне физических дисков. Важно количество физических дисков в массиве RAID. Чем их больше, тем лучше операции чтения-запи- си могут быть распараллелены. Также чем быстрее (в терминах I/O) сами диски, тем лучше; разные уровни массивов RAID обладают разной производительностью. За- конченные рекомендации дать сложно, потому что, кроме скорости, типы RAID отличаются еще стоимостью и надежностью. Однако базовые сооб- ражения звучат так: • RAID-10 – самый быстрый, но наименее эффективно использует про- странство дисков, отнимая 50% на поддержку отказоустойчивости; • RAID-6 – самый надежный, но страдает низкой производительностью на записи (30–40% от показателей RAID-10 при 100% записи), хотя чте- ние с него такое же быстрое, как с RAID-10; • RAID-5 компромиссен. Производительность на запись лучше RAID-6 (но хуже RAID-10), выше эффективность хранения (на отказоустойчи- вость забирается емкость лишь одного диска). Но RAID-5 страдает от серьезных проблем, связанных с долгим восстановлением данных пос- ле выхода из строя диска в случае использования современных дисков большой емкости и больших RAID-групп, во время которого остается незащищенным от другого сбоя (превращаясь в RAID-0) и резко теряет в производительности; • RAID-0, или «RAID с нулевой отказоустойчивостью», для хранения значимых данных использовать нельзя; настройки системы хранения, в частности кеша контроллеров системы хра- нения. Изучение документации СХД важно для правильной ее настройки и эксплуатации; сеть передачи данных. Особенно если планируется к использованию IP СХД, iSCSI или NFS. Я ни в коем случае не хочу сказать, что не надо их использовать, – такие системы давно и многими эксплуатируются. Я хочу сказать, что надо постараться убедиться, что переносимой в виртуальную среду нагрузке хватит пропускной способности сети с планируемой про- пускной способностью. Результирующая скорость дисковой подсистемы следует из скорости дискови алгоритма распараллеливания контроллером обращений к дискам (имеютсяв виду тип RAID и аналогичные функции). Также имеет значение отношение чис-ла операций чтения к числу операций записи – это отношение мы берем из статис-тики или из документации к приложениям в наших ВМ. Разберем пример. Примем, что наши ВМ будут создавать нагрузку до 1000 IOps,67% из которых будет составлять чтение, а 33% – запись. Сколько и каких дисковнам потребуется в случае использования RAID-10 и RAID-5?
    • Сайзинг и планирование 83 В массиве RAID-10 в операциях чтения участвуют сразу все диски, а в опе-рации записи – лишь половина (потому что каждый блок данных записываетсясразу на два диска). В массиве RAID-5 в чтении участвуют все диски, но при запи-си каждого блока возникают накладные расходы, связанные с подсчетом и изме-нением контрольной суммы. Можно считать, что одна операция записи на массивRAID-5 вызывает четыре операции записи непосредственно на диски. Для RAID-10: чтение – 1000 × 0,67% = 670 IOps; запись – 1000 × 0,33% = 330 × 2 (так как в записи участвует лишь половина дисков) = 660 IOps. Всего от дисков нам надо 1330 IOps. Если поделить 1330 на количество IOps,заявленное в характеристиках производительности одного диска, получим требуе-мое количество дисков в массиве RAID-10 под указанную нагрузку. Для RAID-5: чтение – 1000 × 0,67% = 670 IOps; запись – 1000 × 0,33% = 330 × 4 = 1320 IOps. Всего нам от дисков надо 1990 IOps. По документации производителей один жесткий диск SAS 15k обрабатывает150–180 IOps. Один диск SATA 7.2k – 70–100 IOps. Однако есть мнение, что лучшеориентироваться на несколько другие цифры: 50–60 для SATA и 100–120 для SAS. Закончим пример. При использовании RAID-10 и SATA нам потребуется 22–26 дисков. При использовании RAID-5 и SAS нам потребуется 16–19 дисков. Очевидно, что приведенные мною расчеты достаточно приблизительны. В си-стемах хранения используются разного рода механизмы, в первую очередь кеширо-вование – для оптимизации работы системы хранения. Но как отправная точка дляпонимания процесса сайзинга дисковой подсистемы эта информация пригодна. За кадром остаются методики получения требуемого для ВМ количества IOPSи отношение чтения к записи. Для уже существующей инфраструктуры (при пере-носе ее в виртуальные машины) эти данные можно получить с помощью специаль-ных средств сбора информации, например VMware Capacity Planner. Для инфра-структуры планируемой – из документации к приложениям и собственного опыта. 1.7.4. Сетевая подсистема По поводу сети. Здесь соображений три: 1. Необходимая пропускная способность для наших задач. Для какой-то зада- чи будет необходимо выделить сетевой контроллер в личное пользование одной ВМ. Если не хватает одного контроллера, используем группировку сетевых контроллеров, или teaming. 2. Требуемая доступность. Здесь нам поможет дублирование – опять же за счет группировки сетевых контроллеров (Teaming). 3. Безопасность. Здесь может помочь физическая изоляция трафика по раз- ным сетевым контроллерам и/или использование VLAN.
    • 84 Установка vSphere Для реализации всех соображений нам может потребоваться несколько (мно-го ☺) сетевых контроллеров. Абсолютный минимум – 1. Идеальный минимум –4 или даже 6, в зависимости от планируемых к использованию функций vSphere.Такие функции, как vMotion, Fault Tolerance, работа с системами хранения поверхпротокола IP, требуют ресурсов сети, и под них рекомендуется выделять отдель-ные физические контроллеры. Как посчитать, сколько требуется в конкретном случае? Сеть нам нужна для: 1. Управления. Интерфейс Service Console (для ESX) или интерфейс VMker- nel, настроенный для Management traffic (для ESXi). 2. vMotion. 3. Fault Tolerance. 4. iSCSI и/или NFS, если они будут использоваться. 5. ВМ. Среди ВМ может быть несколько групп ВМ, каждой из которых может потребоваться выделенный сетевой интерфейс (или не один). Для управления нам минимально необходим один сетевой контроллер. С тех-нической точки зрения, он не обязан быть выделенным – но этого может требоватьполитика вашей компании. Конечно, лучше бы нам управляющий интерфейс раз-местить на парочке контроллеров – для надежности. Для vMotion нам необходим выделенный сетевой интерфейс. С техническойточки зрения он может быть невыделенным – живая миграция будет происходить,и если через тот же физический контроллер идет еще какой-то трафик. Но поддер-живаемая конфигурация сервера для vMotion предполагает выделение контрол-лера под трафик vMotion. Нужно ли его дублировать, зависит от того, насколькодля вас критична невозможность какое-то время мигрировать ВМ с сервера в слу-чае проблем в сети, используемой для vMotion. Для Fault Tolerance соображения примерно те же, что и для vMotion. Но, ско-рее всего, необходимость наличия дублирующего контроллера для FT более ве-роятна. Однако нагрузка на сетевой контроллер со стороны других задач можетпомешать нормальной работе Fault Tolerance. Верно и в обратную сторону: еслитрафик Fault Tolerance будет достаточно велик, он может мешать другим задачам,если они разделяют один и тот же физический сетевой интерфейс. Если активно будет использоваться система хранения iSCSI или NFS, то с точкизрения производительности ее трафик лучше выделить в отдельную сеть. И в любомслучае рекомендуется это сделать с точки зрения безопасности. Для надежности,очевидно, следует выделить под данный трафик несколько сетевых контроллеров. Для ВМ – зависит от ваших нужд. Какой предполагается организация вирту-альной сети? Смогут ли все ВМ использовать один и тот же контроллер (группуконтроллеров)? Необходимо ли дублирование? По результатам ответов на эти вопросы определяемся с необходимым числомсетевых контроллеров на каждый сервер ESX(i). Также в зависимости от планируемой нагрузки можно задуматься над оправ-данностью применения контроллеров 10 Гб Ethernet. В первую очередь это можетоказаться актуально для трафика СХД по протоколу IP и для Fault Tolerance.
    • Сайзинг и планирование 85 1.7.5. Масштабируемость: мало мощных серверов или много небольших? Заключительный вопрос. Допустим, вы определились с конфигурацией СХД.Посчитали, сколько процессорной мощности и оперативной памяти необходимо вамдля размещения всех ВМ. Но как распределить их по серверам? Например, 16 про-цессоров и 256 Гб ОЗУ можно разместить в 4 четырехпроцессорных серверах по64 Гб в каждом или 8 двухпроцессорных по 32 Гб. Что выбрать при прочих равных? Здесь (как и везде в этом разделе) сложно дать однозначные рекомендации,поэтому привожу свои соображения. 1. Модельный ряд того поставщика серверного оборудования, с которым вы работаете. Если все ваши используемые серверы (пусть других моделей) произведены фирмой XYZ и вы ими довольны, настоятельно рекомендую не «разводить зоопарк» и не пускаться в эксперименты с другими постав- щиками. Потом сами будете не рады. 2. Конечно, предыдущий совет не включает ситуации, когда вас не устраивает качество или уровень поддержки имеющихся серверов, или ваш поставщик не предлагает серверов нужной конфигурации. 3. При прочих равных обратите внимание на дополнительные функции. На- пример, крупные серверы уровня предприятия обычно обладают полез- ными возможностями вроде горячей замены или развитыми функциями удаленного управления. 4. Крупные серверы создают меньшие накладные расходы, а также позволя- ют вместить суммарно больше ВМ. В нашем примере это можно проиллю- стрировать следующим образом. В каждый из четырех серверов по 64 Гб вы сможете с достаточным комфортом разместить по 21 ВМ по 3 Гб ОЗУ каждая (всего получается 4 × 21 = 84 ВМ). В каждый из восьми серверов по 32 Гб – по десять таких же ВМ, всего получается 8 × 10 = 80. Итого полу- чается, что в более крупных серверах плотность размещения ВМ выше и, соответственно, в то же суммарное количество ОЗУ можно вместить боль- ше ВМ. Если же учесть экономию от Transparent Page Sharing, то разница станет еще более заметна. 5. С другой стороны, нельзя забивать все серверы под завязку. Надо подумать и о доступности своих служб. Разумно запланировать, что один из серверов может отказать, а еще один в это время может находиться на обслуживании (например, обновлении ПО или оборудования). Итого мы хотим, чтобы наше решение сохраняло доступность при одновременном выходе из строя двух узлов. В первом случае мы таким образом лишаемся половины (4 – 2 = 2) серверов. И получается, что мы можем задействовать с пользой лишь 256 – (2 × 64) = 128 Гб ОЗУ и разместить в них только (4 – 2) × 21 = 42 ВМ. Во втором случае нам остается уже 8 – 2 = 6 серверов с 256 – (2 × 32) = = 194 Гб, в которых поместится (8 – 2) × 10 = 60 ВМ! Как видим, с учетом планирования доступности преимущество в нашем примере оказывается уже на стороне более модульной архитектуры.
    • 86 Установка vSphere 6. С третьей стороны, вы ни под каким видом не сможете разделить нагрузку одной ВМ между несколькими серверами (по крайней мере, на текущем этапе развития технологий виртуализации). Иными словами, если вам вдруг однажды потребуется создать ВМ с объемом ОЗУ 40 Гб, то второй сценарий (серверы по 32 Гб) вам просто не подойдет (без учета возможно- стей по оптимизации использования памяти, которые мы здесь не станем учитывать для наглядности). А вот первому варианту (серверы по 64 Гб) такой сценарий окажется вполне под силу. 7. Все вышесказанное в равной степени применимо и к другим ресурсам сер- вера (процессор, подсистемы ввода-вывода). Просто с памятью это выгля- дит наиболее наглядно. 8. Серверы-лезвия (Blade servers) обладают массой преимуществ с точки зре- ния стоимости владения (затраты на управление, обслуживание, питание и охлаждение). Они также отлично отвечают пятому соображению, при- веденному выше, – ведь каждое лезвие является сравнительно небольшой составляющей инфраструктуры. В результате выход из строя сразу не- скольких из них вряд ли сильно уменьшит суммарную мощность системы. Блейд-серверы также крайне эффективны с точки зрения уменьшения проблем и головной боли – куда девать все эти кабели? Предположим, что, следуя соображениям отказоустойчивости, мы будем использовать 6 одно- гигабитных сетевых интерфейсов (2 = управление + vMotion, 2 = iSCSI, 2 = виртуальные машины). Не забудем о сети IPMIiLO – в итоге 7 интер- фейсов (и кабелей) на сервер. 8 серверов виртуализации в итоге дают нам 56 кабелей, которые к тому же надо куда-то подключать, то есть потребует- ся еще и 56 сетевых портов. В случае с блейд-серверами количество кабелей (и портов) сокращается до 10–12. 9. С другой стороны, стоит задуматься о сбоях не только на уровне каждого лезвия в отдельности, но и каждой корзины (шасси). А вот выход из строя целой корзины окажется все-таки более существен, чем даже пары обыч- ных стоечных серверов, хотя, конечно, куда менее вероятен. 10. С третьей стороны, увеличивая нашу инфраструктуру и поднимая требо- вания к доступности, может потребоваться вести счет уже не на потерю от- дельных серверов или корзин, а целых стоек. И здесь нет особой разницы, потеряли вы стойку с лезвиями или стойку с обычными серверами. То есть преимущества лезвий могут снова выйти на первый план. В общем, надеюсь, что общую идею и способы оценки привлекательности раз-ных подходов к выбору типа серверов вы поняли и это оказалось для вас полезным.Дальше вам придется решать самим, руководствуясь подобными или какими-тосовершенно другими соображениями. Но, как это ни странно, аналогичные соображения могут действовать не толь-ко на оборудование и доступность служб, но и на лицензирование ПО, которое выпланируете запускать в виртуальных машинах. Рекомендую заранее ознакомить-ся с тонкостями лицензирования этого ПО и нюансами, связанными с виртуали-зацией.
    • Сайзинг и планирование 87 Например, некоторые версии серверного ПО требуют приобретения лицензийпо количеству всех процессоров в физическом сервере – даже в том случае, еслидля ВМ с этим ПО вы выделили всего один виртуальный процессор. В этом случаеболее маленькие серверы с небольшим количеством процессоров очевидно оказы-ваются выгоднее. Правда, в последнее время с развитием популярности виртуа-лизации в промышленных инфраструктурах поставщики ПО стали постепенноотказываться от этой крайне невыгодной схемы лицензирования. Другие производители могут накладывать ограничения на перепривязку ли-цензий между серверами и считают таким переносом операции миграции ВМ (на-пример, vMotion). И здесь, уже наоборот, крупные серверы, которые снижают час-тоту (или необходимость) переноса ВМ, могут оказаться выгоднее.
    • Глава 2. Настройка сети виртуальнойинфраструктурыВ этой главе будет рассказано про то, как работают с сетью серверы ESX(i), проорганизацию сети в виртуальной инфраструктуре vSphere. Ключевой элемент сетив vSphere – это виртуальный коммутатор, virtual switch или vSwitch. Виртуальныекоммутаторы делятся на несколько типов: стандартный виртуальный коммутаторVMware, распределенный виртуальный коммутатор VMware (dvSwitch, distributedvSwitch) и виртуальный коммутатор стороннего производителя (на данный мо-мент такой предлагает только Cisco, модель Nexus 1000V). Стандартный вирту-альный коммутатор VMware доступен во всех вариантах лицензирования vSphere,включая бесплатный ESXi. Распределенный и третьесторонний виртуальные ком-мутаторы – лишь в дорогих лицензиях. Поговорим про них последовательно. 2.1. Основы сети ESX(i), объекты виртуальной сети Основное соображение, которое необходимо уяснить: физические сетевыеконтроллеры сервера ESX(i) не являются «активными сетевыми устройствами».Это означает, что у физического сетевого контроллера нет своего IP-адреса, егоMAC-адрес фигурирует лишь в техническом трафике. А являются активными се-тевыми устройствами сетевые контроллеры виртуальные. Очевидно, что виртуальные сетевые контроллеры гипервизор создает для вир-туальных машин. Но и для себя самого гипервизор тоже использует виртуальныесетевые контроллеры (рис. 2.1). На данном рисунке фигурируют и объекты внешней сети – физические ком-мутаторы. Если вы используете сервер без виртуализации, устанавливаете на него какую-то ОС и настраиваете подключение к сети, то настраиваете вы физические сетевыеконтроллеры, IP-адреса, группировку контроллеров, VLAN и прочее, что можетпонадобиться для сети этого сервера. Если же мы настраиваем сеть на ESX(i), то физические сетевые контролле-ры являются лишь каналами во внешнюю сеть (Uplink). Через один физическийсетевой контроллер в сеть могут выходить и управляющий интерфейс (виртуаль-ная сетевая карта Service Console), и интерфейс для подключения NFS/iSCSI/vMotion/Fault Tolerance (виртуальная сетевая карта VMkernel, гипервизора), иразные виртуальные машины. (Здесь имеется в виду принципиальная возмож-ность. Трафик разных назначений следует разделять по разным физическим сете-вым контроллерам, см. раздел, посвященный сайзингу.)
    • Основы сети ESX(i), объекты виртуальной сети 89 Рис. 2.1. Основные объекты сети «внутри» ESX(i) Источник: VMware Связующим звеном между источниками трафика (виртуальными сетевымиконтроллерами ВМ и гипервизора) и каналами во внешнюю сеть (физическимисетевыми контроллерами) являются виртуальные коммутаторы (рис. 2.2). Рис. 2.2. Связь между объектами сети «внутри» ESX(i) Источник: VMware
    • 90 Настройка сети виртуальной инфраструктуры На данном рисунке фигурируют и объекты внешней сети – физические ком-мутаторы. Перечислим объекты виртуальной сети: физические сетевые контроллеры (network interface card, NIC) – те, что установлены в сервере. ESX(i) дает им имена вида vmnic#. Таким образом, когда вам по тексту попадется термин «vmnic», знайте: речь идет о физиче- ском сетевом контроллере сервера. Они же имеются в виду под словосоче- танием «канал во внешнюю сеть»; виртуальные коммутаторы (vSwitch или вКоммутаторы) – основные объ- екты сети на ESX(i); группы портов (Port groups) – логические объекты, создаваемые на вКомму- таторах. Виртуальные сетевые контроллеры подключаются именно к груп- пам портов; виртуальные сетевые контроллеры. Они могут принадлежать виртуальным машинам, Service Console и VMkernel. Обратите внимание на то, что интерфейс vSphere весьма наглядно показы-вает вам связь между объектами виртуальной сети – пройдите Configuration ⇒Networking (рис. 2.3). Сравните со схемой на рис. 2.2. Рис. 2.3. Объекты виртуальной сети на ESX(i) в интерфейсе клиента vSphere Если зайти в свойства виртуального коммутатора, то мы получим доступ к егонастройкам и настройкам групп портов на нем (рис. 2.4). Выделив нужный объект и нажав кнопку Edit, мы попадем в его настройки.
    • Основы сети ESX(i), объекты виртуальной сети 91 Рис. 2.4. Свойства виртуального коммутатора 2.1.1. Физические сетевые контроллеры, vmnic Про физические сетевые контроллеры сказать особо нечего – они использу-ются просто как каналы во внешнюю физическую сеть, у них нет собственного IP-адреса, и их MAC-адрес можно отследить лишь в техническом, вспомогательномтрафике ESX(i) (см. beaconing). Единственное, что мы можем для них настроить, –это скорость и дуплекс. Делается это из GUI так: Configuration ⇒ Networking ⇒Properties для vSwitch (к которому подключен физический контроллер) ⇒ за-кладка Network Adapters ⇒ выбираем нужный vmnic и нажимаем Edit. Каждый физический сетевой контроллер нам надо привязать к вКоммутатору.Можно, конечно, и не привязывать – но это имеет смысл, лишь если мы хотимотдать этот vmnic напрямую ВМ. Подробности о таком варианте см. в разделе, по-священном виртуальным машинам, вас интересует функция VMDirectPath.
    • 92 Настройка сети виртуальной инфраструктуры Итак, если мы не планируем использовать VMDirectPath, то не привязанныйк вКоммутатору сетевой контроллер сервера у нас не используется никак. Это бес-смысленно, поэтому, скорее всего, все vmnic будут привязаны к тем или иным вир-туальным коммутаторам. Правило логичное – один физический сетевой контрол-лер может быть привязан к одному, и только одному вКоммутатору. Но к одномувКоммутатору могут быть привязаны несколько vmnic. В последнем случае мы мо-жем получить отказоустойчивую и более производительную конфигурацию сети. Получить информацию обо всех vmnic одного сервера можно в пункте Confi-guration ⇒ Network Adapters (рис. 2.5). Рис. 2.5. Информация обо всех физических сетевых контроллерах сервера ESX(i) В столбце vSwitch мы видим, к какому виртуальному коммутатору они привя-заны. В столбце Observed IP ranges – пакеты из каких подсетей получает ESX(i)на этом интерфейсе. Это информационное поле, его значения не всегда точны иактуальны, но часто оно помогает нам сориентироваться. Например, из рис. 2.5ясно, что сетевые контроллеры vmnic0 и vmnic1 перехватывают трафик из однойподсети, а vmnic2, vmnic3 и vmnic4 – из другой. Скорее всего, это означает, чтоони подключены к другому физическому коммутатору или принадлежат другомуVLAN на физическом коммутаторе.
    • Основы сети ESX(i), объекты виртуальной сети 93 Обратите внимание. Физическим сетевым контроллерам ESX(i) дает имя вида vmnic. Командой esxcfg-nics –l вы выведете на экран список всех физических кон- троллеров сервера ESX и информацию о них. Фактически эта команда покажет на ту же информацию, что и соответствующее окно графического интерфейса (рис. 2.5). Теперь поговорим о прочих компонентах виртуальной сети – виртуальных се-тевых контроллерах и виртуальных коммутаторах с группами портов. 2.1.2. Виртуальные контроллеры Service Console и VMkernel Первое, чем отличаются виртуальные сетевые контроллеры, – это принад-лежность. Принадлежать они могут Service Console (для ESX, у ESXi нет ServiceConsole), VMkernel (самому гипервизору) и виртуальным машинам. Если виртуальный контроллер принадлежит ВМ, то он может быть разныхтипов – Flexible, vmxnet2, vmxnet3, E1000. Но про них поговорим в разделе, посвя-щенном свойствам и оборудованию виртуальных машин, а здесь сконцентрируемвнимание на виртуальных сетевых контроллерах для Service Console и VMkernel. Управляющий интерфейс ESX, виртуальный контроллер для Service Console (vswif) Виртуальный сетевой контроллер для Service Console используется для управ-ления сервером ESX. Один такой контроллер создается установщиком сервераESX, именно ему принадлежит тот IP-адрес, который вы указывали при установ-ке. Именно на IP-адрес Service Console вы подключаетесь клиентом vSphere, черезнего с сервером работает vCenter, на этот IP подключаются утилиты для работыс ESX. Также через интерфейс Service Console идут сигналы пульса (heartbeat)при работе кластера VMware HA. Наконец, некоторые варианты резервного копи-рования виртуальных машин осуществляются через интерфейсы Service Console. Вам следует резервировать управляющий интерфейс, сделать это можно дву-мя путями, см. рис. 2.6. В левой части рисунка вы видите дублированную конфигурацию единствен-ного интерфейса Service Console. Она задублирована за счет того, что к вКоммута- Рис. 2.6. Два варианта дублирования управляющего интерфейса ESX
    • 94 Настройка сети виртуальной инфраструктурытору подключены два сетевых контроллера. Таким образом, выход из строя однойфизической сетевой карточки (а если они подключены к разным физическим ком-мутаторам – то и одного из них) не приведет к недоступности управления серве-ром ESX по сети. В правой части рисунка вы тоже видите дублированную конфигурацию, нодублированную по-другому – созданы два интерфейса Service Console, на разныхвКоммутаторах, следовательно, на разных vmnic. Если выйдет из строя один изканалов во внешнюю сеть (сам vmnic или порт в физическом коммутаторе, к ко-торому он подключен, или сам физический коммутатор), то один из интерфейсовSC станет недоступен, но останется другой. Первый вариант удобнее в использовании, но если мы не можем себе позво-лить выделить два vmnic на вКоммутатор с Service Console, то он будет невоз-можен. Выделить может не получиться, если количество сетевых контроллеровв сервере недостаточно под все наши задачи. Тогда имеет смысл пойти по второмупути. Само собой, на вКоммутаторах интерфейсы Service Console могут соседство-вать с любыми другими виртуальными интерфейсами в любых количествах – нарис. 2.6 их нет для простоты. Однако первый вариант резервирования не защитит от двух дополнительныхтипов проблем: ошибки настроек интерфейса SC; проблемы во внешней сети. Во втором примере двум разным интерфейсам SC даны адреса из разных сетей, и это защитит в том случае, если одна из этих сетей начнет испытывать проблемы (например, перегрузка паразит- ным трафиком или сбой маршрутизатора). Создать еще один интерфейс очень просто: Configuration ⇒ Networking ⇒Аdd Networking (для создания нового вКоммутатора – то есть резервированиепо правому варианту с рис. 2.6). Нас спросят, группу портов для чего мы хотимсоздать на этом вКоммутаторе. Несложно догадаться, что сейчас нас интересуетService Console. Выбираем, жмем Next. Выберем, какие vmnic привязать к соз-даваемому сейчас вКоммутатору. Next. Указываем имя (Network Label) – это на-звание группы портов. Это название – для человека, так что рекомендую давать говорящие названия.«Service_Console_2» вполне подойдет. Однако при чем здесь группа портов, мы ведь создаем виртуальный сетевойинтерфейс Service Console? Дело в том, что любой виртуальный сетевой контрол-лер числится подключенным именно к группе портов, поэтому при создании ин-терфейса SC из GUI мы создаем и интерфейс Service Console, и группу портовдля него. На стандартном виртуальном коммутаторе интерфейс Service Console всегдазанимает свою группу портов целиком (или, что то же самое, группа портов дляService Console всегда состоит из одного порта). Этот факт не является ограни-чением – на одном вКоммутаторе могут сосуществовать любые виртуальные ин-терфейсы в любых комбинациях, просто под каждый интерфейс Serice Console(и, забегая вперед, VMkernel) создается отдельная группа портов.
    • Основы сети ESX(i), объекты виртуальной сети 95 Обратите внимание. Я не рекомендую использовать пробелы и спецсимволы в ка- ких бы то ни было названиях. Это не смертельно, но может создать дополнительные проблемы при работе в командной строке и сценариях. Затем для виртуального контроллера указываем настройки IP. В принципе,все. Единственный, наверное, нюанс – если хотим создать интерфейс SC не на но-вом, а на уже существующем вКоммутаторе. Тогда делаем так: Configuration ⇒Networking ⇒ для нужного вКоммутатора нажимаем Properties ⇒ и на вкладкеPorts нажимаем Add. Дальше все так же. Наконец, в случае распределенных виртуальных коммутаторов пройди-те Configuration ⇒ Networking ⇒ кнопка Distributed Virtual Switch ⇒ ссылкаManage Virtual Adapters ⇒ Add. Будьте аккуратны в случае изменения настроек интерфейса SC, когда онодин, – в случае ошибки (например, опечатки в IP-адресе) доступ к управлениюESX по сети станет невозможен. Решается такая проблема из командной строкидля ESX или из BIOS-подобного локального интерфейса ESXi. В любом случаепонадобится доступ к локальной консоли сервера – физически или по iLO и ана-логам. Обратите внимание. Виртуальный сетевой контроллер для Service Console называ- ется vswif – при создании их из GUI им даются имена вида vswif#, в командной строке мы управляем этими объектами с помощью esxcfg-vswif. Управляющий интерфейс ESXi Для ESX управление идет через интерфейс Service Console. Но в составе ESXiнет Service Console. Поэтому для ESXi в качестве интерфейсов управления ис-пользуются виртуальные сетевые контроллеры VMkernel, те из них, в свойствахкоторых установлен флажок «Management traffic» (рис. 2.7). Таким образом, организационные соображения здесь те же самые, что и дляинтерфейсов Service Console в ESX, но в качестве самих интерфейсов выступаютинтерфейсы VMkernel с соответствующим флажком в свойствах. Виртуальный сетевой контроллер для VMkernel (vmk) И в ESX, и в ESXi мы можем создать виртуальные сетевые адаптеры дляVMkernel, для гипервизора. Нужны они для: vMotion – по этим интерфейсам будет передаваться содержимое оператив- ной памяти переносимой ВМ; подключения дисковых ресурсов по iSCSI в случае использования про- граммного инициатора iSCSI; подключения дисковых ресурсов по NFS; Fault Tolerance – по этим интерфейсам будут передаваться процессорные инструкции на резервную ВМ в Fault Tolerance-паре; (только на ESXi) управления сервером (на ESX для этого используется сеть Service Console).
    • 96 Настройка сети виртуальной инфраструктуры Рис. 2.7. Управляющий интерфейс ESXi См. подробности и требования к сети для соответствующих функций в раз-делах, им посвященных. Таким образом, работа гипервизора с сетью немного двойственна, потому чтопроисходит на двух уровнях. С одной стороны, гипервизор имеет доступ и управ-ляет физическими контроллерами; с другой – сам для себя, для своего доступав сеть создает контроллеры виртуальные. Тем не менее такая схема весьма удобнадля понимания: физические контроллеры – это всегда «ресурс», всегда только ка-нал во внешнюю сеть. А как источник трафика, как активные объекты сети всегдавыступают контроллеры виртуальные, в том числе для трафика гипервизора. Виртуальные сетевые контроллеры для гипервизора создаются точно так же,как для Service Console (на ESX): Configuration ⇒ Networking ⇒ и затем: либо Аdd Networking для создания нового вКоммутатора и интерфейса VMkernel на нем; либо для существующего вКоммутатора Properties ⇒ Add на закладке Ports; в случае распределенных виртуальных коммутаторов пройдите Confi- guration ⇒ Networking ⇒ кнопка Distributed Virtual Switch ⇒ ссылка Manage Virtual Adapters ⇒ Add. В любом случае как тип добавляемого интерфейса выбираем VMkernel. Ука-жем имя группы портов и настройки IP для создаваемого интерфейса. Обратите внимание на то, что для интерфейса VMkernel у нас есть возмож-ность установить три флажка (рис. 2.8). Каждый из флажков разрешает передачу соответствующего трафика черезданный интерфейс. Технически допускается любая комбинация флажков на од-
    • Основы сети ESX(i), объекты виртуальной сети 97 Рис. 2.8. Настройки интерфейса VMkernel на ESXiном виртуальном интерфейсе. Однако рекомендуется трафик разных типов раз-носить по разным физическим сетевым контроллерам, из чего следует созданиеотдельного интерфейса VMkernel под разные типы трафика гипервизора. Уста-навливать флажки следует только по необходимости. К тому же в случае использования ESXi через интерфейс с флажком «Manage-ment traffic» по умолчанию не пересылается трафик iSCSI и NFS. Если вы плани-руете использовать один интерфейс для управления и обращения к IP-СХД, толучше всего создать несколько интерфейсов, пусть даже из одной подсети и наодном и том же виртуальном коммутаторе. Обратите внимание. Виртуальные сетевые контроллеры этого типа называются vmk – при создании их из GUI им даются имена вида vmk#, в командной строке мы управляем этими объектами с помощью команды esxcfg-vmknic.
    • 98 Настройка сети виртуальной инфраструктуры 2.2. Стандартные виртуальные коммутаторы VMware – vNetwork Switch Если вы перейдете на закладку Configuration ⇒ Networking, то увидите вашувиртуальную сеть (кстати, из командной строки можно увидеть все то же самоекомандой esxcfg-vswitch –l). Виртуальная сеть – это: виртуальные сетевые контроллеры, принадлежащие Service Console, VMker- nel и виртуальным машинам; группы портов; виртуальные коммутаторы; физические сетевые контроллеры. Про первые и последние мы говорили чуть ранее, теперь коснемся остального. Начну с аналогии. ESX(i) с работающими на нем ВМ можно представитьв виде серверной стойки или серверного шкафа. В стойке работают серверы, этисерверы подключены к коммутаторам, смонтированным в этой же стойке, и в не-которые порты коммутаторов подключены выходящие за пределы стойки сетевыекабели – Uplinks. Это прямая аналогия. Вся стойка и есть ESX(i), серверы внутри – ВМ, комму-таторы – виртуальные коммутаторы, подключения ко внешней сети (Uplinks) –это физические сетевые контроллеры. Что же тогда «ports group»? В общем-то,группами портов они и являются. Смотрите – допустим, у вас есть несколько физических серверов, подклю-ченных к одному коммутатору. Согласитесь, что у вас может возникнуть желаниесделать на коммутаторе разные настройки для этих серверов. Указать им разныеVLAN, указать разные настройки ограничения пропускной способности сети(traffic shaping), что-нибудь еще… На коммутаторе физическом большинство та-ких настроек выполняются для порта, некоторые – для группы портов. То естьв настройках вы указываете – хочу создать группу портов, в нее включить портыс 1-го по 12-й и им задать значение VLAN = 34. В коммутаторе виртуальном стандартном все так же. Единственное, наверное,различие – в том, что вы не указываете настроек на уровне порта – только на уров-не групп портов, и не указываете номера портов, входящих в группу, и даже ихколичество. Таким образом, для настройки тех же самых VLAN или ограничения пропуск-ной способности сети (traffic shaping) вам достаточно создать на вКоммутатореобъект «группа портов» с каким-то говорящим (для вашего удобства) именем.Например: «Production», «Test_Project_SCOM» и т. п. Затем задать для нее не-обходимые настройки и, наконец, в свойствах ВМ указать – сетевой контроллерподключен к группе портов «Production». Все. Нам не надо выбирать, к порту с ка-ким номером мы хотим подключить ВМ. Не надо добавлять еще портов в группу.Группа портов – логическое образование, количество портов в группе не ограниче-но – она будет расти по мере добавления в нее ВМ. Ограничено только количество
    • Стандартные виртуальные коммутаторы VMware – vNetwork Switch 99портов на весь вКоммутатор, то есть количество виртуальных сетевых контролле-ров (не ВМ, так как в одной ВМ может быть несколько виртуальных адаптеров),подключенных ко всем группам портов на этом вКоммутаторе. Отсюда выводы: Если вы хотите вывести во внешнюю сеть ВМ через определенные физическиесетевые контроллеры, то вам надо выполнить следующее: 1. Создать вКоммутатор, к нему привязать эти vmnic. Configuration ⇒ Networking ⇒ Аdd Networking. 2. В запустившемся мастере первым вопросом будет тип первой группы пор- тов на создаваемом вКоммутаторе. Следует указать тип «Virtual Machine». 3. Выбрать vmnic. Это дело потенциально не простое – о нем пара слов чуть позже. Кстати, вы можете создать вКоммутатор без единого привязанного физического контроллера. Это пригодится для помещения ВМ в изоли- рованную сеть. Например, для использования того или иного рода прок- си-сервера или брандмауэра. Если последнее вас интересует, обратите внимание на VMware vShield Zones (http://www.vmware.com/products/ vshield-zones/). 4. Укажите название группы портов. Еще раз повторюсь, вам будет удобнее сделать его максимально понятным для человека. Также здесь вы можете указать VLAN ID – о VLAN я расскажу чуть позже. По поводу п. 3 – выбора физического сетевого контроллера, который будет ка-налом во внешнюю сеть для создаваемого вКоммутатора, поговорим немного под-робнее. Представьте ситуацию, что у вас в сервере несколько vmnic, и они ском-мутированы в разные сети (подключены к разным физическим коммутаторами/или в разные VLAN на физических коммутаторах). И вот вам из, например, ше-сти свободных необходимо выбрать два правильных. См. рис. 2.9 и 2.10. Рис. 2.9. Пример организации сети
    • 100 Настройка сети виртуальной инфраструктуры На рис. 2.9 вы видите сервер с шестью сетевыми картами. Они попарно под-ключены к разным физическим коммутаторам и работают в разных сетях. Ониуже подключены к каким-то коммутаторам виртуальным – или вам как раз сейчаснадо это сделать. Предположим, вам надо подключить ВМ в сеть к шлюзу с ука-занным IP-адресом. Как вы поймете, к какому виртуальному коммутатору и черезкакие vmnic ее надо подключить? Нам может помочь Configuration ⇒ NetworkAdapters. См. рис. 2.10. Рис. 2.10. Информация о физических сетевых контроллерах ESX(i) Что нам поможет? Обратите внимание на столбец Observed IP ranges в этом окне. ДиапазоныIP-адресов в нем – это подсети, пакеты из которых получает ESX на соответствую-щем интерфейсе. Это не настройка, не рекомендация – это информационное поле.То есть если вы знаете, что vmnic, который вам сейчас надо подключить, ском-мутирован в сеть с известной вам подсетью, то вы сможете сориентироваться попредставленной здесь информации. Итак, глядя на рис. 2.9 и 2.10, к каким vmnic надо подключить эту ВМ? Пра-вильный ответ – vmnic0 и vmnic1. В моем примере они подключены к вКомму-
    • Распределенные коммутаторы – vNetwork Distributed Switch, dvSwitch 101татору с именем vSwitch0. Значит, надо посмотреть, какая группа портов дляВМ существует на этом виртуальном коммутаторе, и именно к ней подключатьВМ. Второй вариант – если вам известен MAC-адрес искомых физических кон-троллеров, то вы можете сопоставить MAC-адреса и названия физических кон-троллеров (вида vmnic#) и – как следствие – название vSwitch и групп портов. Если вы хотите добавить группу портов для ВМ на существующий вКоммута-тор, то делается это очень просто: 1. Configuration ⇒ Networking ⇒ Properties, но НЕ в верхней правой части окна, а справа от названия нужного вКоммутатора. 2. На закладке Ports кнопка Add. Далее укажите, что вновь добавляемая группа портов – для ВМ, и ее название. Зачем вам может понадобиться на один вКоммутатор добавлять несколькогрупп портов для ВМ? Ответ прост – чтобы разные ВМ выходили в сеть черезодни и те же физические контроллеры, но при этом с разными настройками. Здесьпод настройками понимаются следующие из них: настройки VLAN; настройки Security (безопасности); настройки Traffic Shaping (управления пропускной способностью); настройки NIC Teaming (группировки контроллеров). Эти настройки могут задаваться на уровне вКоммутатора – тогда они на-следуются всеми группами портов. Однако на уровне группы портов любую изнастроек можно переопределить. Еще один нюанс – настройка Number of Ports(количества портов) существует только для вКоммутатора, группы портов у нас«безразмерные». А настройка VLAN существует только для групп портов, не длякоммутатора целиком. Поговорим про эти настройки более подробно чуть далее. 2.3. Распределенные коммутаторы – vNetwork Distributed Switch, dvSwitch. Настройки Виртуальные коммутаторы VMware – штука хорошая. Однако нет предела со-вершенству, и в больших инфраструктурах вам могут быть интересны распреде-ленные виртуальные коммутаторы – vNetwork Distributed Switch, или dvSwitch. Обратите внимание на то, что настройки распределенных виртуальных ком-мутаторов описываются в разных разделах: в разделах 2.3.4 и 2.3.5 описаны уникальные настройки dvSwitch; в разделе 2.4 описаны настройки, доступные и для стандартных, и для рас- пределенных виртуальных коммутаторов, это группы настроек «Security», «VLAN», «Traffic shaping» и «NIC Teaming».
    • 102 Настройка сети виртуальной инфраструктуры 2.3.1. Основа понятия «распределенный виртуальный коммутатор VMware» Идея их заключается в следующем: в случае использования стандартныхвКоммутаторов у вас разные (пусть очень часто и идентично настроенные) вирту-альные коммутаторы на каждом сервере. Акцент я хочу сделать вот на чем: создатьи поддерживать эту, пусть даже идентичную, конфигурацию придется вам. Принеобходимости, например, создать еще одну группу портов для еще одного VLANвам потребуется повторить это простое действие на всех серверах ESX(i). А в случае создания распределенного коммутатора вы получаете один-един-ственный (логически) коммутатор, существующий сразу на всех серверах ESX(i). Вы настраиваете только этот, логически единый коммутатор. Новую группупортов из примера выше вы создадите один раз, и она появится для всех серверовESX(i), входящих в распределенный коммутатор. ВМ, даже при миграции с сервера на сервер, остаются не только на том жекоммутаторе, но и даже на том же порту распределенного виртуального комму-татора (это называют Network vMotion). Это позволяет проще настраивать поли-тики безопасности, осуществлять мониторинг трафика ВМ, привязываясь дажек отдельному порту вКоммутатора. В отличие от стандартных виртуальных коммутаторов VMware, distributedvSwitch поддерживают Private VLAN и двухсторонний traffic shaping (о том, чтоэто такое, см. в разделах 2.4.2 и 2.4.4). В версии 4.1 в список уникальных возмож-ностей распределенных коммутаторов добавились такие функции, как: Network IO Control – возможность гибко настраивать минимально и мак- симально доступные ресурсы пропускной способности для трафика раз- ных типов. Подробности о NIOC см. в главе 6, посвященной распределе- нию ресурсов; Load Based Teaming – балансировка нагрузки между физическими кон- троллерами одного вКоммутатора в зависимости от нагрузки на каждый контроллер. Еще один плюс – распределенный вКоммутатор доступен в реализациях отVMware и от Cisco. Вариант от Cisco, распределенный виртуальный коммутатор Cisco Nexus1000V, приобретается независимо от vSphere (но подойдет не любая лицензияvSphere, на момент написания – только Enterprise Plus). Он обладает всеми воз-можностями, присущими сетевому оборудованию от Cisco. Позволяет добитьсятого, что все используемые коммутаторы в сети компании созданы одним произ-водителем (здесь имеется в виду Cisco), и сетевые администраторы могут управ-лять ими точно так же, как коммутаторами физическими, снимая, таким образом,эти задачи с администратора vSphere. Однако рассмотрение настроек и возмож-ностей этого решения в данной книге описано не будет. Здесь будет описан распределенный виртуальный коммутатор от VMware.Возможность им пользоваться появляется после активации лицензии, дающей на
    • Распределенные коммутаторы – vNetwork Distributed Switch, dvSwitch 103него право, – сегодня это vSphere Enterprise Plus (и ее ознакомительный 60-днев-ный период после установки vSphere, Evaluation-лицензия). Как я уже сказал, dvSwitch – объект скорее логический, как таковой существу-ющий только для vCenter. Мы создали один распределенный вКоммутатор, но накаждом сервере, для которых он существует, автоматически создаются стандарт-ные вКоммутаторы, скрытые от нас (рис. 2.11). Таким образом, де-факто распре-деленный коммутатор является шаблоном настроек. Мы создаем его и указываемнастройки в vCenter – это control plane по документации VMware, то есть уровеньуправления. А после включения в созданный распределенный коммутатор серве-ров ESX(i) vCenter создает на них стандартные коммутаторы, скрытые от нас. Подокументации VMware это IO Plane, прикладной уровень. За всю работу отвечаютскрытые коммутаторы на серверах ESX(i), все управление осуществляется толькочерез vCenter. Рис. 2.11. Иллюстрация сути распределенного виртуального коммутатора Источник: VMware Минусом такой схемы распределенного виртуального коммутатора VMwareявляется возросшая сложность, в частности зависимость от vCenter. vCenter яв-ляется управляющим элементом для dvSwitch, и при недоступности vCenter у ад-министратора нет возможности менять настройки распределенного коммутатораи даже переключать виртуальные машины на другие группы портов. Однако дажепри недоступности vCenter сеть будет продолжать работать – ведь за техническуюсторону вопроса отвечают скрытые от нас коммутаторы на каждом ESX(i), теряет-ся только возможность изменения настроек.
    • 104 Настройка сети виртуальной инфраструктуры Кстати, подключение самого vCenter к распределенному коммутатору не под-держивается VMware. Подключитесь клиентом vSphere к vCenter. Предполагается, что в иерархииvCenter уже создан объект Datacenter, уже добавлены серверы. Распределенныйвиртуальный коммутатор создается для объекта Datacenter, и существовать длясерверов из разных Datacenter один dvSwitch не может. Пройдите Home ⇒ Networking. В контекстном меню объекта Datacenter вы-берите пункт New vNetwork Distributed Switch. В запустившемся мастере нас спросят: Name – имя создаваемого вКоммутатора. Влияет только на удобство; Number of dvUplink ports – максимальное количество подключений ко внешней сети – привязанных vmnic – на каждом сервере. Обратите внима- ние: один такой вКоммутатор может существовать для серверов с разной конфигурацией, с разным количеством доступных сетевых контроллеров – а здесь мы ограничиваем максимальное число используемых для данного dvSwitch контроллеров на одном сервере; дальше вам предложат выбрать серверы, для которых будет существовать создаваемый вКоммутатор. Выбор можно осуществить или изменить поз- же. Если будете выбирать серверы сейчас, то вам покажут свободные физи- ческие сетевые контроллеры на каждом выбранном сервере – и вы сможете выбрать те из них, что будут использоваться для создаваемого вКоммута- тора. По ссылке View Details вам покажут исчерпывающую информацию о физическом сетевом контроллере – драйвер, производитель, статус под- ключения (link status), PCI-адрес, доступные через него подсети IP – не покажут здесь только MAC-адрес; на последнем шаге можно будет снять флажок Automatically create a de- fault port group. Если он стоит, то автоматически будет создана группа портов со 128 портами и именем по умолчанию. Имя по умолчанию мало- информативно, поэтому я рекомендую этот флажок снимать и создавать группу портов самостоятельно, после создания вКоммутатора. Обратите внимание. У стандартных вКоммутаторов число портов настраивается для них самих, группы портов «безразмерные». У распределенных вКоммутаторов наоборот. Вы можете создать до 248 распределенных виртуальных коммутаторов для сервера. На одном сервере может быть до 4096 портов стандартных и распре- деленных вКоммутаторов. Это означает, что если не задавать заведомо огромных значений числа портов, то с ограничениями с этой стороны вы не столкнетесь. Когда вы создали dvSwitch, то на странице Home ⇒ Inventory ⇒ Networkingвы видите картинку примерно как на рис. 2.12. Здесь «Demo_dvSwitch» – это сам объект – распределенный вКоммутатор.Объект «Demo_dvSwitch-DVUplinks-28» – это группа портов, в которую объеди-нены его подключения ко внешним сетям. То есть те порты вКоммутатора, к ко-
    • Распределенные коммутаторы – vNetwork Distributed Switch, dvSwitch 105 Рис. 2.12. Свежесозданный dvSwitchторым подключены физические сетевые контроллеры серверов, на которых этотdvSwitch существует. Нужен этот объект для получения информации о внешнихподключениях – обратите внимание на столбцы в закладке Ports для данной груп-пы портов. Число 28 в названии – это случайным образом сгенерированное число,для уникальности имени этого объекта. Ну и «Demo_dvPortGroup» – созданная вручную группа портов, туда мож-но подключать ВМ, а также виртуальные сетевые контроллеры Service Console иVMkernel. Обратите внимание. При использовании стандартных виртуальных коммутато- ров невозможно поместить в одну группу портов виртуальные машины и интер- фейс VMkernel или Service Console. На распределенных виртуальных коммутаторах VMware это возможно, на dvSwitch в одной группе портов могут сосуществовать и ВМ, и интерфейсы SC и VMkernel в любых сочетаниях. Кстати говоря, объект «VM Network» на этом рисунке – это группа портов настандартных виртуальных коммутаторах серверов этого vCenter. 2.3.2. Добавление сервера в dvSwitch, настройки подключения vmnic У вас есть серверы, на них создан распределенный коммутатор. Появился ещеодин сервер, необходимо задействовать и его. Идем Home ⇒ Networking ⇒ вызы-ваем контекстное меню нужного dvSwitch ⇒ Add Host. В запустившемся мастеревам покажут список серверов этого Datacenter, для которых выбранный dvSwitchне существует, и их vmnic. Выберите нужный сервер и те из его vmnic, что хо-тите задействовать под этот dvSwitch (последнее можно сделать и потом). Если
    • 106 Настройка сети виртуальной инфраструктурывы выберете vmnic, которая уже используется, вам покажут предупреждение, чтовыбранный контроллер будет отсоединен от старого вКоммутатора и подключенк данному dvSwitch. После выбора Add Нost в контекстном меню вам может быть показано не окновыбора сервера, а мастер добавления сервера в vCenter (поле для ввода адреса сер-вера и учетных данных). Такое происходит в том случае, если все существующиесерверы в Datacenter уже подключены к этому dvSwitch – вот вам и предлагаютдобавить в Datacenter какой-то новый сервер. Нюансы задействования внешних подключений (Uplinks) dvSwitch У dvSwitch есть несколько портов для внешних подключений (dvUplink) – ихчисло мы указываем при создании. Например, в настройках этого dvSwitch ука-зано, что у него максимум три внешних подключения (рис. 2.13). Еще раз напом-ню, что это означает «до трех подключенных физических сетевых контроллеровна каждом сервере, для которого существует этот распределенный виртуальныйкоммутатор». Рис. 2.13. Настройки dvSwitch
    • Распределенные коммутаторы – vNetwork Distributed Switch, dvSwitch 107 По умолчанию они называются «dvUplink1», «dvUplink2» и т. д. Увидеть ихи их заполнение для конкретного сервера можно, пройдя Configuration ⇒ Net-working ⇒ кнопка Distributed Virtual Switch (рис. 2.14). Если здесь развернутьсписок дочерних объектов для dvUplink (нажав +), мы увидим названия сетевыхконтроллеров серверов (вида vmnic#), подключенных к этому dvSwitch. Рис. 2.14. Внешние подключения распределенного коммутатора на конкретном сервере В данном окне мы видим ту часть и те настройки распределенного виртуаль-ного коммутатора, что существуют для данного сервера. Увидеть же все физические сетевые контроллеры, подключенные к это-му dvSwitch на каждом из серверов, мы можем, пройдя Home ⇒ Networking ⇒dvSwitch ⇒ закладка Configuration. Эти объекты можно назвать «абстрактными подключениями». Проиллюстри-рую их суть на примере. Есть распределенный вКоммутатор, на нем несколько групп портов и не-сколько внешних подключений. Для какой-то группы портов мы указали исполь-зовать только первое подключение (dvUplink1). Отлично – виртуальные маши-ны, подключенные к этой группе портов, пользуются только первым внешнимподключением этого коммутатора. Но на каждом сервере этому «абстрактному»подключению номер один соответствует какой-то конкретный физический сете-вой интерфейс. Вот откуда берется нужда в абстракции. Получается, что одномуабстрактному dvUplink# соответствуют столько физических контроллеров, дляскольких серверов существует распределенный коммутатор. Поменять названия «dvUplink» на произвольные можно в свойствах dvSwitch,закладка Properties ⇒ General ⇒ Edit dvUplink port, изменять эти названия имеетсмысл лишь для нашего удобства. Например, в наших серверах установлено подва сетевых контроллера, один из которых 10 Гбит, а второй гигабитный. Пра-вильно будет 10 Гбит контроллеры с каждого сервера подключать в один и тотже «абстрактный порт» распределенного коммутатора. Если эти абстрактные
    • 108 Настройка сети виртуальной инфраструктурыпорты будут называться не «dvUplink1» и «dvUplink1», а «dvUplink_10Gb» и«dvUplink_1Gb», то нам будет проще не ошибиться. Если какой-то dvUplink# уже занят хотя бы одним физическим сетевым кон-троллером – вы увидите его имя (вида vmnic#) под именем порта (вида dvUplink#).Здесь имеются в виду настройки dvSwitch целиком: Home ⇒ Networking ⇒ за-кладка Configuration – для распределенного виртуального коммутатора. Далее на каждом сервере мы можем указать, какой же из физических сетевыхконтроллеров этого сервера является каким из внешних подключений dvSwitch.Обратите внимание: эта настройка делается именно на уровне каждого сервера,а не распределенного коммутатора. Поэтому, для того чтобы увидеть то, о чем яговорю, надо пройти Home ⇒ Hosts and Clusters ⇒ настраиваемый сервер ⇒Configuration ⇒ Networking ⇒ нажать кнопку Distributed Virtual Switch ⇒ длянастраиваемого dvSwitch нажать ссылку Manage Physical Adapter. Откроетсяокно как на рис. 2.15. Рис. 2.15. Настройки привязки физических контроллеров сервера к dvSwitch vmnic# на этом рисунке – это те vmnic, которые вы видите для сервера на стра-нице Configuration ⇒ Network Adapters. Нажатие Remove удалит vmnic из этогораспределенного виртуального коммутатора, нажатие Add NIC позволит выбрать,какой из свободных vmnic добавить и каким из абстрактных внешних подключе-ний сделать. Щелкнув на уже подключенный vmnic, вы увидите информацию о нем и смо-жете настроить скорость и дуплекс (рис. 2.16).
    • Распределенные коммутаторы – vNetwork Distributed Switch, dvSwitch 109 Рис. 2.16. Окно настроек vmnic Какой vmnic к какому порту (dvUplink) подключен, может оказаться принци-пиально, потому что в свойствах групп портов на dvSwitch вы можете выбирать,какое из абстрактных внешних подключений dvSwitch является активным, запас-ным или не используемым для данной группы портов (рис. 2.17). То есть на одном dvSwitch мы можем сделать несколько групп портов, чей тра-фик выходит наружу через разные физические контроллеры, – точно так же, как ина стандартных вКоммутаторах VMware. 2.3.3. Группы портов на dvSwitch, добавление интерфейсов Service Console и VMkernel Для создания группы портов на dvSwitch вручную необходимо пройти Home⇒ Networking и в контекстном меню нужного dvSwitch выбрать New Port Group.Потребуется указать имя (опять же в ваших интересах сделать его максимальнопонятным), количество портов в этой группе и тип VLAN (про VLAN для dvSwitchчуть позже). На dvSwitch и виртуальные машины, и интерфейсы гипервизора мо-гут существовать в одной и той же группе портов, поэтому о типе создаваемойгруппы портов нас не спросят (как это происходит при создании группы портовна стандартных виртуальных коммутаторах). Обратите внимание на то, что если вы зайдете в настройки уже созданнойгруппы портов, то количество настроек будет больше. В частности, мы можем на-
    • 110 Настройка сети виртуальной инфраструктуры Рис. 2.17. Настройки использования внешних подключений для группы портов на dvSwitchстроить Port binding. Эта настройка связана с количеством портов в группе пор-тов распределенного вКоммутатора. Варианты этой настройки: Static binding – в этой группе портов столько портов, сколько указано на- стройкой Number of ports. Порты существуют вне зависимости от того, подключены ли к ним ВМ. Порт закрепляется за ВМ в тот момент, когда она подключается к этой группе портов, – вне зависимости от того, включе- на ВМ или нет. То есть если в этой группе 16 портов, то подключить к ней можно не более 16 ВМ (со всех серверов – коммутатор-то распределен- ный), даже если все они пока выключены; Dynamic binding – в этой группе столько портов, сколько указано настрой- кой Number of ports. Порты существуют вне зависимости от того, подклю- чены ли к ним ВМ. Порт занимается ВМ в момент запуска и освобождается после выключения. То есть к группе портов с 16 портами может быть под- ключено хоть 100 ВМ, но лишь 16 из них включены одновременно. К со- жалению, при включении 17-ой ВМ вы не получите сообщения о том, что нет свободных портов. ВМ включится, но с ее сетевого контроллера будет снят флажок «Connected»; Ephemeral – no binding – нет ограничения на количество портов для груп- пы. Порт создается и закрепляется за ВМ в момент включения и существу- ет, только пока ВМ включена.
    • Распределенные коммутаторы – vNetwork Distributed Switch, dvSwitch 111 Менять эту настройку группы портов можно, только если нет ни одной под-ключенной ВМ. Про прочие настройки, доступные для групп портов и отдельных портов рас-пределенных виртуальных коммутаторов VMware, см. следующий раздел. Добавление интерфейса Service Console и VMkernel на dvSwitch Разумеется, с распределенным коммутатором могут работать как ВМ, так иинтерфейсы самого ESX(i) – интерфейсы Service Console и VMkernel. Определи-те (или создайте) группу портов, в которую будет подключен созданный адаптер.Напоминаю, что для распределенных вКоммутаторов интерфейсы VMkernel иService Console могут сосуществовать в одной и той же группе портов друг с дру-гом и с виртуальными машинами, в любых комбинациях (хотя из организацион-ных соображений я бы так не поступал). Интерфейсы SC и VMkernel – это объекты конкретного сервера. Поэтому дляуправления ими пройдите на вкладку Configuration для выбранного сервера ⇒Networking ⇒ кнопка Distributed Virtual Switch ⇒ Manage Virtual Adapters. Вам покажут список существующих интерфейсов SC и VMkernel этого сер-вера на каком-либо dvSwitch. В верхней левой части открывшегося окна активнассылка Add. После ее нажатия запустится мастер с вопросами: создать новый интерфейс или мигрировать существующий с обычного вКоммутатора. Здесь мы говорим про создание нового; интерфейс для VMkernel или SC хотим создать; Select port group – выберите ранее созданную группу портов, в которую подключится создаваемый интерфейс. Select Standalone port – в какой отдельный порт подключить создаваемый интерфейс. Standalone-порты можно создать, лишь задействуя SDK, так что в большинстве случаев этот вариант вам не пригодится. В случае добавления интерфейса VMkernel здесь вы можете указать, что этот интерфейс можно использовать для vMotion (флажок Use this virtual adapter for vMotion) и для Fault Tolerance (Use this virtual adapter for Fault Tolerance logging); IP Settings – укажите настройки IP для создаваемого интерфейса; все. 2.3.4. Уникальные настройки dvSwitch Если вы зайдете в Home ⇒ Networking ⇒ контекстное меню dvSwitch, выбе-рите Edit Settings, то сможете изменить настройки распределенного виртуальногокоммутатора. Настройки General: Name – имя dvSwitch; Number of dvUplink ports – максимальное количество физических сете- вых контроллеров, которое может быть подключено к этому коммутатору на одном сервере;
    • 112 Настройка сети виртуальной инфраструктуры Edit dvUplink port – нажав эту кнопку, можно изменить название абстракт- ного внешнего подключения. Например, имя по умолчанию «dvUplink1» заменим на более информативное «Primary_vMotion_uplink»; Notes – произвольные примечания. Настройки Advanced: Maximum MTU – Maximum Transmission Unit, размер поля с данными в паке-те IP. Используется для включения/выключения Jumbo Frames. Эта функция по-зволяет снизить долю технического трафика в IP-сетях, то есть значительно сни-зить накладные расходы на передачу данных по сети. Может использоваться дляiSCSI/NFS-трафика, трафика vMotion, для ВМ. Подробности про Jumbo Framesи их настройку см. далее. Cisco Discovery Protocol – протокол от Cisco, позволяющий обнаруживать иполучать информацию о сетевых устройствах. В отличие от стандартных вКомму-таторов VMware, для dvSwitch его использование настраивается из GUI. Значе-ния этой настройки: Down – CDP не используется; Listen – ESX обнаруживает и показывает информацию о коммутаторах Cisco, к которым подключен. На коммутаторы информация о вКоммутато- рах не отправляется; Advertise – ESX отправляет информацию о вКоммутаторах наружу, но не слушает и не принимает информацию о физических коммутаторах; Both – ESX и обнаруживает подключенные физические коммутаторы, и отправляет на них информацию о коммутаторах виртуальных; Administrator Contact Information – это информационные поля, информациюотсюда CDP будет сообщать внешним коммутаторам при настройке Advertise илиBoth. Закладка Network Adapters чисто информационная, изменить настройки от-сюда мы не можем. На закладке Private VLAN мы можем настроить Private VLAN. В чем сутьэтой функции, см. далее. 2.3.5. Уникальные настройки портов dvSwitch: Miscellaneous и Advanced Здесь поговорим о том, какие бывают настройки для портов распределенныхкоммутаторов. Обратите внимание на то, что на dvSwitch настройки могут приме-няться как на уровне групп портов, так и индивидуально к порту. Многие из ниходинаковы для виртуальных коммутаторов обоих типов. Одинаковые настройкиздесь я лишь упомяну, подробному их описанию посвящен следующий подраздел. Security – эта настройка одинакова для стандартных и распределенных вКом-мутаторов. Подробнее о ней далее. Traffic shaping – эта настройка почти одинакова для стандартных и распреде-ленных вКоммутаторов. Отличие в том, что на dvSwitch этот механизм работает
    • Распределенные коммутаторы – vNetwork Distributed Switch, dvSwitch 113и для исходящего (Egress), и для входящего (Ingress) трафиков. На стандартныхвКоммутаторах – только для исходящего. VLAN – на dvSwitch функционал работы с VLAN немного расширен по срав-нению со стандартными вКоммутаторами. Основное отличие – поддерживаютсяPrivate VLAN. Немного отличаются сами окна настройки – все подробности далее. Teaming and Failover – эта настройка одинакова для стандартных и распреде-ленных вКоммутаторов. Miscellaneous – уникальная настройка для dvSwitch. В этом пункте мы можемзаблокировать все или один порт, в зависимости от того, делаем ли мы эту на-стройку в свойствах группы портов или порта. Advanced – здесь можем настроить: Override port policies – можно ли переназначать вышеназванные настройки на уровне портов. Если флажок стоит, то Home ⇒ Inventory ⇒ Networking ⇒ выделяем группу портов на dvSwitch и переходим на закладку Ports. Ви- дим порты с указанием номеров и того, чьи виртуальные контроллеры под- ключены к тому или иному порту. Из контекстного меню порта вызываем пункт Edit Settings и редактируем настройки, которые разрешено изменять соответственно настройке Override port policies; Live port moving – разрешает или запрещает переносить независимый (standalone) порт dvSwitch в группу портов dvSwitch и в обратную сторону. Эти переносы (и создание независимого порта) могут выполняться толь- ко из SDK, в планах VMware дать возможность делать это из командной строки vSphere CLI. В графическом интерфейсе нет настроек для этих ма- нипуляций; Configure reset at disconnect – когда ВМ отключается от распределенно- го вКоммутатора, порт, к которому она была подключена, сбрасывает на- стройки на настройки по умолчанию, то есть заданные на уровне вКомму- татора или переопределенные на уровне группы портов. Данная функция нужна, только если настройка Override port policies разрешает изменение каких-то настроек на уровне отдельного порта; Port Name Format – шаблон именования портов этого распределенного виртуального коммутатора. 2.3.6. Миграция со стандартных виртуальных коммутаторов на распределенные Если у вас уже есть сеть на стандартных виртуальных коммутаторах VMware ивы хотите переместить ее (частично или полностью) на распределенные виртуаль-ные коммутаторы VMware, то это несложно. У вас есть два варианта проведенияэтой операции: 1. Используя стандартные механизмы по работе с сетями на ESX(i), в пер- вую очередь настройки в окне Home ⇒ Inventory ⇒ Network. Метод при-
    • 114 Настройка сети виртуальной инфраструктуры меним в любых случаях, но требует большого количества повторяющихся действий при большом количестве серверов. 2. Используя механизм Host Profiles, когда использование распределенных виртуальных коммутаторов на первом сервере мы настраиваем вручную и копируем эту настройку на остальные с помощью Host Profiles. Метод хо- рош автоматизацией. Второй способ предполагает автоматизацию всех действий, что правильно. Ноесть ограничения в его применимости: конфигурации серверов по сетевым кон-троллерам должны быть одинаковы, для применения профиля настроек серверыпереводятся в режим обслуживания, что требует выключения или переноса ВМна другие серверы. Здесь под «конфигурацией» понимаются количество сетевыхадаптеров и порядок их подключения к разным физическим сетям (например,первый адаптер каждого сервера – Management VLAN, со второго по третий –Production и т. д.). Зато функционал Host Profiles отлично подходит для отслеживания отходанастроек сети на серверах от заданных – если кто-то, по ошибке, к примеру, меняетконфигурацию сети на каком-то сервере, то этот сервер перестает удовлетворятьназначенному ему шаблону настроек, о чем мы получаем уведомление. Также функционал Host Profiles интересен для настройки новодобавленныхсерверов ESX(i). Сначала разберем первый способ. Итак, вы имеете несколько серверов ESX(i)под управлением vCenter с уже существующей виртуальной сетью (рис. 2.18). Для перевода всей или части виртуальной сети на распределенные коммутато-ры выполните следующую процедуру. Рис. 2.18. Порядок миграции на dvSwitch Источник: VMware
    • Распределенные коммутаторы – vNetwork Distributed Switch, dvSwitch 115 Первое. Создайте распределенный коммутатор. Создайте необходимые груп-пы портов на нем. Второе. Добавьте сервер к этому распределенному вКоммутатору. Перенеситена dvSwitch часть физических сетевых интерфейсов сервера. Как вы понимаете,один физический контроллер не может принадлежать одновременно двум ком-мутаторам. В идеале на каждом вашем стандартном коммутаторе внешних под-ключений хотя бы два (для дублирования) – и один из них мы сейчас можем ос-вободить. Освобождаем один из них и переносим на распределенный коммутатор.Этот шаг повторите для каждого сервера. Если внешнее подключение только одно,тогда придется сначала его отключить от обычного вКоммутатора, затем подклю-чить к распределенному. Разница только в том, что во время переключения ВМбудут отрезаны от сети. Однако имейте в виду, что добавлять vmnic к распределен-ному вКоммутатору можно без предварительного отключения его от стандартноговКоммутатора. Третье. Перенесите ВМ на группы портов распределенного вКоммутатора.Проще всего это сделать, пройдя Home ⇒ Inventory ⇒ Networking ⇒ и в кон-текстном меню dvSwitch выбрать пункт Migrate Virtual Machine Networking – см.рис. 2.19. Рис. 2.19. Миграция ВМ между группами портов Здесь следует указать: 1. Source Network – виртуальные машины из какой группы портов будут переноситься. 2. Destination Network – затем выбрать группу портов, в которую они будут перенесены. 3. Далее нажать кнопку Show Virtual Machines и выбрать конкретные вирту- альные машины для переноса. После нажатия ОК они будут последовательно перенастроены на использова-ние новой группы портов.
    • 116 Настройка сети виртуальной инфраструктуры Другой вариант: пройти Home ⇒ Inventory ⇒ Networking ⇒ выделить группупортов стандартного коммутатора и перейти на закладку Virtual Machines. Здесьвыделите нужные ВМ (можно просто рамкой) и перетащите их в нужную группупортов распределенного виртуального коммутатора. ВМ будут последовательно перенастроены на использование dvSwitch. Послепереноса ВМ (и при необходимости интерфейсов SC и VMkernel) на распреде-ленные вКоммутаторы обычные вКоммутаторы вам следует удалить, а все физи-ческие сетевые контроллеры переназначить на dvSwitch. Отдельно расскажу про перенос на dvSwitch интерфейсов Service Console иVMkernel. Эта миграция выполняется для каждого сервера индивидуально. Нараспределенном коммутаторе должна быть группа портов, в которую вы плани-руете подключать переносимые интерфейсы. Для выполнения самой миграциипройдите Home ⇒ Hosts and Clusters ⇒ Configuration для сервера ⇒ Networking⇒ кнопка Distributed Virtual Switch ⇒ ссылка Manage Virtual Adapters. В от-крывшемся окне нажмите ссылку Add, в запустившемся мастере выберите Migrateexisting virtual adapters (рис. 2.20). Рис. 2.20. Миграция интерфейсов ESX(i) на dvSwitch С помощью этого мастера вы можете перенести существующие и создать но-вые интерфейсы SC и VMkernel для сервера на dvSwitch. Это не только проще,чем создание нового интерфейса и удаление старого, – это еще и удобнее, потомучто сохраняются старые MAC-адреса (а на них могут быть назначены резервациив DHCP, например). Теперь поговорим про решение той же задачи с помощью Host Profiles.
    • Распределенные коммутаторы – vNetwork Distributed Switch, dvSwitch 117 Использование Host Profiles поможет нам автоматизировать создание dvSwitchи назначение внешних подключений. Последовательность действий такова: 1. Мы делаем dvSwitch. Создаем группы портов. 2. Добавляем к нему один сервер. Переносим его внешние подключения на dvSwitch. Удаляем ненужные теперь стандартные виртуальные коммута- торы. 3. Затем снимаем с этого сервера профиль настроек. Для этого идем в Home ⇒ Management ⇒ Host Profiles и нажимаем Create Profile. 4. И назначаем на следующий сервер. Для этого идем в Home ⇒ Management ⇒ Host Profiles, выбираем ранее созданный профиль и нажимаем Attach Host/Cluster. Применение профиля требует режима обслуживания – это значит, на серверене должно быть включенных ВМ. Таким образом, если мы не хотим выключать всеВМ, то придется применять профиль настроек к серверам последовательно. Получается, что использование профиля настроек удобно для первоначальноодновременной настройки множества серверов, когда ВМ еще нет. Или при до-бавлении в существующую инфраструктуру нового сервера. 2.3.7. Технические особенности распределенных виртуальных коммутаторов VMware Настройки dvSwitch хранятся в базе данных сервера vCenter. Но каждый сер-вер ESX(i) имеет локальную копию настроек dvSwitch. Эта локальная копия находится в файле /etc/vmware/dvsdata.db. Обновля-ется она каждые 5 минут. Также многие относящиеся к dvSwitch настройки хра-нятся в основном конфигурационном файле ESX(i) – /etc/vmware/esx.conf. Ещеодно место хранения настроек – каталог с именем .dvsData на одном из VMFS-хранилищ сервера (рис. 2.21). Данная информация приведена в основном для справки – у нас практиче-ски нет способов взаимодействовать с описанными объектами и, самое главное,вряд ли возникнет необходимость. Необходимость может возникнуть разве чтопри диагностике и решении проблем. Единственный инструмент, который намв этом может помочь, – утилита /usr/lib/vmware/bin/net-dvs, дающая доступ кдампу настроек распределенного виртуального коммутатора на конкретном сер-вере ESX(i). В некоторых ситуациях возможна рассинхронизация локальных данных с хра-нящейся в vCenter информацией. Это может привести к тому, что распределенныйкоммутатор будет считать некоторые свои порты занятыми со стороны сервера,который на самом деле их уже не занимает. В такой ситуации vCenter не позволит удалить распределенный коммутаторили сервер из него. Для решения такой проблемы следует уменьшить время, в те-
    • 118 Настройка сети виртуальной инфраструктуры Рис. 2.21. Каталог с настройками dvSwitchчение которого порт считается заблокированным (по умолчанию это 24 часа). Под-робности об этой операции см. в статье базы знаний VMware – http://kb.vmware.com/kb/1010913. Если вы используете систему хранения iSCSI с программным инициатором,избегайте размещения этой папки на iSCSI LUN. Иначе вы рискуете оказатьсяв ситуации, что при старте ESX(i) для поднятия сети потребуются эти файлы, адля доступа за ними на хранилище iSCSI потребуется сеть, которой еще нет из-занедоступности этих файлов. 2.4. Настройки Security, VLAN, Traffic Shaping и NIC Teaming Здесь будет рассказано о настройках, которые применимы и к стандартным (заредким исключением), и к распределенным виртуальным коммутаторам VMware.Напомню, что часть настроек распределенных виртуальных коммутаторов уни-кальна и доступна только для них. Такие настройки описаны в разделах 2.3.4 и 2.3.5. 2.4.1. VLAN, виртуальные локальные сети. Настройка VLAN для стандартных виртуальных коммутаторов Немножко общей теории о виртуальных локальных сетях. VLAN поддержива-ются как стандартными, так и распределенными виртуальными коммутаторами.Суть их в том, чтобы возложить на коммутатор работу по анализу и контролютрафика на втором уровне модели OSI с целью создавать не связанные между со-бой сети без физической их изоляции друг от друга.
    • Настройки Security, VLAN, Traffic Shaping и NIC Teaming 119 Рис. 2.22. Серверы (ВМ) подключены к одному коммутатору, но к разным VLAN Что мы здесь видим? Все серверы (в нашем случае это ВМ, но для VLAN это не принципиально)подключены к одному коммутатору (слева), но на этом коммутаторе настроенынесколько VLAN, и все ВМ подключены к разным (справа). Это означает, что накоммутаторе (в случае виртуальных машин – на вКоммутаторе) мы сделали на-стройку – порт для ВМ1 принадлежит виртуальной сети 1 (с идентификаторомVLAN ID = 1), порт для ВМ2 принадлежит VLAN 2 и т. д. Это означает, что этиВМ друг с другом взаимодействовать не могут, им не даст такой возможности самкоммутатор. Изоляция между серверами (ВМ) получается практически такой же,как если бы они были подключены к разным коммутаторам. Небольшое примечание: на коммутаторе физическом, к которому подключе-ны коммутаторы виртуальные, также в обязательном порядке должны быть на-строены VLAN. В общем случае VLAN – это разделение всей нашей сети на несколько какбудто бы не связанных сегментов. Именно всей сети, а не отдельно взятого ком-мутатора. Зачем это надо: для того чтобы уменьшить домены широковещательной рассылки, следо- вательно, снизить нагрузку на сеть; для того чтобы повысить безопасность – хотя устройства подключены в одну сеть физически, находясь в разных vlan, они не смогут взаимодей- ствовать по сети. Если используются VLAN, то коммутаторы (обычно этим занимаются именнокоммутаторы) добавляют в каждый кадр поле, в которое записывают так назы-ваемый «vlan id» (тег VLAN, идентификатор VLAN) – число в диапазоне от 1 до
    • 120 Настройка сети виртуальной инфраструктуры4094. Получается, для каждого порта указано, кадры с каким vlan id могут пройтив порт, а в кадрах прописано, к какому vlan относится каждый кадр. Эту операциюназывают «тегированием», добавлением в кадр тега vlan. Обычно VLAN настраиваются на коммутаторах, и только коммутаторы о нихзнают – с точки зрения конечного устройства (такого, как физический сервер иливиртуальная машина) в сети не меняется ничего. Что означает настроить vlan накоммутаторе? Это означает для всех или части портов указать vlan id, то есть vlanс каким номером принадлежит порт. Теперь если сервер подключен к порту с vlanid = «10», то коммутатор гарантированно не перешлет его трафик в порты с другимvlan id, даже если сервер посылает широковещательный трафик. Один VLAN может распространяться (и, как правило, распространяется) нанесколько коммутаторов. То есть устройства, находящиеся в одном VLAN, могутфизически быть подключены к разным коммутаторам. Если за настройки сети отвечаете не вы, то формально, с точки зрения админи-стрирования ESX(i), нам достаточно знать: ESX(i) поддерживает VLAN. Мы мо-жем настроить vlan id для групп портов на вКоммутаторе, и они будут тегироватьи ограничивать проходящий через них трафик. Если тема настройки VLAN вас касается, то несколько слов подробнее. У вас есть три принципиально разных варианта настройки vlan: external switch tagging, EST – установка тегов VLAN только на внешних, физических, коммутаторах. За VLAN отвечают только физические комму- таторы, на вКоммутаторы трафик приходит без тегов VLAN; virtual switch tagging, VST – установка тегов VLAN на виртуальных ком- мутаторах. Коммутаторы физические настраиваются таким образом, чтобы теги VLAN не вырезались из кадров, передаваемых на физические интер- фейсы серверов ESX(i), то есть виртуальным коммутаторам; virtual guest tagging, VGT – установка тегов VLAN на гостевой ОС в вир- туальной машине. В этом случае коммутаторы (и виртуальные, и физиче- ские) не вырезают тег VLAN при пересылке кадра на клиентское устрой- ство (в нашем случае на ВМ), а теги VLAN вставляются в кадры самим клиентским устройством (в нашем случае виртуальной машиной). EST – схема на рис. 2.23. Рис. 2.23. External switch tagging
    • Настройки Security, VLAN, Traffic Shaping и NIC Teaming 121 Этот подход хорош тем, что все настройки VLAN задаются только на физиче-ских коммутаторах. Вашим сетевым администраторам не придется задействоватьв этом вКоммутаторы ESX(i) – порты физических коммутаторов, куда подклю-чены физические сетевые контроллеры ESX, должны быть настроены обычнымобразом, чтобы коммутаторы вырезали тег VLAN при покидании кадром порта.Минус подхода EST в том, что на каждый VLAN нам нужен выделенный физиче-ский сетевой контроллер в ESX(i). Таким образом, при реализации схемы EST уже физические коммутаторы про-пускают в порты к ESX(i) пакеты только из нужных VLAN (5 и 15 в моем примере).Виртуальные машины и виртуальные коммутаторы про VLAN ничего не знают. VST – схема на рис. 2.24. Рис. 2.24. Схема Virtual switch tagging Этот подход предполагает настройку VLAN и на вКоммутаторах. Удобентем, что на один вКоммутатор (и на одни и те же vmnic) может приходить тра-фик множества VLAN. Из минусов – требует настройки на стороне и физических,и виртуальных коммутаторов. Те порты физических коммутаторов, к которымподключены контроллеры серверов ESX(i), следует настроить «транковые», тоесть пропускающие пакеты из всех (или нескольких нужных) VLAN, и не выре-зающие теги VLAN при проходе кадра сквозь порт. А на вКоммутаторах надо со-поставить VLAN ID соответствующим группам портов. Впрочем, это несложно –Configuration ⇒ Networking ⇒ свойства vSwitch ⇒ свойства группы портов ⇒в поле VLAN ID ставим нужную цифру. VGT – схема на рис. 2.25. Этот подход хорош в тех редких случаях, когда одна ВМ должна взаимодей-ствовать с машинами из многих VLAN одновременно. Для этого вКоммутатормы настроим не вырезать теги VLAN из кадров к этой ВМ (фактически сделаемтранковый порт на вКоммутаторе). Чтобы настроить транковый порт на стандарт-ном виртуальном коммутаторе VMware, необходимо для группы портов, к кото-рой подключена ВМ, в качестве VLAN ID прописать значение «4095». ПройдитеConfiguration ⇒ Networking ⇒ свойства vSwitch ⇒ свойства группы портов ⇒в поле VLAN ID.
    • 122 Настройка сети виртуальной инфраструктуры Рис. 2.25. Схема Virtual guest tagging Минус конфигурации в том, что внутри ВМ должно быть ПО, обрабатыва-ющее VLAN, – так как вКоммутатор теги VLAN вырезать не будет и они будутдоходить прямо до ВМ. На физических серверах очень часто этим ПО являетсядрайвер сетевых контроллеров. Это актуально и для ВМ. Для реализации схемы VGT виртуальные машины должны использовать вир-туальные сетевые карты типа e1000 или vmxnet3. Драйверы vmxnet3 для Windows из состава VMware Tools позволяют настраи-вать VLAN, но какой-то один – см. рис. 2.26. Рис. 2.26. Настройка VLAN в драйвере vmxnet3
    • Настройки Security, VLAN, Traffic Shaping и NIC Teaming 123 Виртуальный контроллер E1000 эмулирует контроллер Intel Pro1000, и еслиустановить соответствующий драйвер Intel (http://www.intel.com/design/network/drivers/), то получим все его возможности, в частности возможность настраиватьVLAN – см. рис. 2.27. Рис. 2.27. Настройка VLAN в драйвере e1000/Intel Pro 1000 К сожалению, Intel не предоставляет специального драйвера для 64-битныхоперационных систем. Кроме стандартных виртуальных коммутаторов VMware, некоторые лицен-зии позволяют использовать распределенные виртуальные коммутаторы VMware.У них немного больше возможностей работы с VLAN (они позволяют использо-вать Private VLAN) и чуть-чуть по-другому выглядят окна настройки. Подробно-сти см. в следующем разделе. 2.4.2. Настройка VLAN для dvSwitch. Private VLAN Настройка VLAN для dvSwitch выглядит немного по-другому, нежели дляобычного vSwitch (рис. 2.28). Увидеть эту настройку можно, зайдя в свойство группы портов на dvSwitch.Как вы видите на рисунке, для настройки VGT, или транкового порта (группыпортов), вы не указываете значение VLAN ID = 4095 (как для стандартных вир-туальных коммутаторов), а выбираете из выпадающего меню «VLAN Trunking».
    • 124 Настройка сети виртуальной инфраструктуры Рис. 2.28. Варианты настройки VLAN для групп портов на распределенном виртуальном коммутаторе VMwareКроме того, вы можете явно указать, пакеты с какими VLAN ID могут попадатьв эту группу портов, – в то время как для обычных коммутаторов такой выбор невозможен. Для групп портов на dvSwitch появилась возможность настроить использова-ние Private VLAN. Тайный смысл здесь в следующем: у нас есть какой-то VLAN(например, в моем примере это VLAN 5), какие-то наши ВМ в нем. Но мы хотим,чтобы часть из этих ВМ не могла взаимодействовать друг с другом. Можно этотодин десятый VLAN разбить на несколько – но это усложнит конфигурированиеVLAN в нашей сети, да и при большом количестве виртуальных машин такой ва-риант решения проблемы невозможен технически. Механизм Private VLAN по-зволяет сделать несколько «вторичных» (Secondary) VLAN «внутри» нашего ос-новного, Primary VLAN 5. Обратите внимание на рис. 2.29. Устройства внешней сети считают, что все (здесь – виртуальные) серверы при-надлежат одному VLAN с номером 5. И лишь коммутаторы, непосредственно с ко-торыми эти ВМ работают, знают о разделении основного VLAN 5 на нескольковнутренних, вторичных (Secondary) VLAN, с определенными правилами взаимо-действия между ними.
    • Настройки Security, VLAN, Traffic Shaping и NIC Teaming 125 Рис. 2.29. Пример использования Private VLAN Источник: VMware Вторичные VLAN могут быть трех типов: Community – ВМ в этом Secondary VLAN могут взаимодействовать друг с другом и с виртуальными машинами в VLAN Promiscuous (ВМ Е и F), но не могут с ВМ C и D. Isolated – ВМ в этом Secondary VLAN могут взаимодействовать только с машинами из Promiscuous VLAN (ну и, разумеется, с внешним миром). То есть виртуальные машины C и D могут работать с ВМ E и F, но не могут с ВМ A и В и друг с другом; Promiscuous – когда ВМ находятся в этом Secondary VLAN, они могут взаимодействовать со всеми ВМ на этом dvSwitch и всеми физическими и виртуальными компьютерами в данном Primary VLAN. То есть для вирту- альных машин E и F доступны все ВМ. На распределенном вКоммутаторе вторичный VLAN этого типа создается автоматически. Его VLAN ID со- впадает с VLAN ID Primary VLAN. Настраиваются Private VLAN в свойствах распределенного коммутатора, назакладке Private VLAN. В левой части окна добавляем номер Primary VLAN (их может быть несколькона одном dvSwitch). Затем, выделив этот Primary VLAN, в правой части вводимномер Secondary VLAN с указанием их типа – Isolated или Community (рис. 2.30). А потом, зайдя в свойства группы портов на dvSwitch, мы можем указать длянее Secondary VLAN – см. рис. 2.31.
    • 126 Настройка сети виртуальной инфраструктуры Рис. 2.30. Окно настроек Private VLAN для распределенного вКоммутатора Если ВМ в одном Private VLAN работают на разных серверах ESX(i), то в об-мене трафиком между ними участвуют физические коммутаторы. На них такжедолжны быть настроены Private VLAN, если мы хотим, чтобы эта схема работала. 2.4.3. Security Зайдя в свойства вКоммутатора или какой-то группы портов, мы увидим за-кладку Security и там три настройки: Promiscuous Mode – режим прослушивания. Если значение настройки Accept, то сетевой контроллер ВМ можно переводить в режим promiscuous, и он будет принимать все проходящие через вКоммутатор кадры (с по- правкой на VLAN – кадры из других VLAN доступны не будут). Если зна- чение настройки Reject, то переводить сетевой контроллер ВМ в режим прослушивания бесполезно – вКоммутатор будет пересылать в ее порт только ей предназначенные кадры. Эта настройка может пригодиться, если вы в какой-то ВМ хотите запустить анализатор трафика (sniffer), для пере- хвата и анализа сетевого трафика. Или наоборот, гарантировать, что такой анализатор не заработает для вашей сети. Значение по умолчанию Reject;
    • Настройки Security, VLAN, Traffic Shaping и NIC Teaming 127 Рис. 2.31. Настройки Private VLAN для группы портов MAC Address Changes – изменение MAC-адреса. Reject – при этом зна- чении настройки гипервизор проверяет совпадение MAC-адреса виртуаль- ных сетевых контроллеров ВМ в конфигурационном файле vmx этой ВМ и в пакетах, приходящих по сети. Если пакет предназначен для MAC-адреса, не существующего в конфигурационном файле ни одной ВМ, он будет от- клонен. Такое происходит в тех случаях, когда MAC-адрес переопределен средствами гостевой ОС. Accept – при таком значении настройки провер- ка не производится. Если ваша ВМ отключилась от сети – то проверьте, возможно, для вКоммутатора или группы портов этой ВМ MAC Address Changes = Reject, а кто-то зашел в диспетчер устройств гостевой ОС и по- менял MAC-адрес сетевого контроллера; Forged Transmits – если в исходящих кадрах MAC-адрес источника отли- чается от MAC-адреса ВМ (прописанного в файле vmx), то такие кадры будут отброшены. Само собой, это в случае значения настройки = Reject. В случае Accept проверки не производится. Настройка Accept необходима для некоторых режимов работы NLB кластера Microsoft – это из известных мне примеров. По сути, и MAC Address Changes, и Forged Transmits делают одно и то же –отсекают ВМ от сети, если ее MAC-адрес отличается от указанного в ее файле
    • 128 Настройка сети виртуальной инфраструктурынастроек (*.vmx). Но первая настройка блокирует входящий трафик, а вторая –исходящий. 2.4.4. Ограничение пропускной способности (Traffic Shaping) Для вКоммутатора целиком или для какой-то одной группы портов у нас естьвозможность ограничить пропускную способность его портов. Обратите внимание на то, что ограничению не подвергается трафик, остаю-щийся только на виртуальном коммутаторе. Если виртуальные машины работаютна одном сервере и подключены к одному вКоммутатору, то трафик между ними невыходит за пределы данного вКоммутатора (за исключением случая, когда эти ВМв разных VLAN). В таком случае ограничения пропускной способности канала натрафик между этими двумя виртуальными машинами распространяться не будут. Зайдя в окно настроек Traffic shaping (Configuration ⇒ Network ⇒ Propertiesдля нужного вКоммутатора ⇒ Edit для самого вКоммутатора или одной группыпортов), мы увидим три настройки: Average Bandwidth – столько килобит в секунду в среднем может прохо- дить через каждый порт этого коммутатора/группы портов. Фактически – средняя, обычная скорость сети; Peak Bandwidth – столько килобит в секунду может проходить через порт, если полоса пропускания занята не полностью. Фактически – максималь- ная скорость сети. Это значение всегда должно быть не меньше Average Bandwidth; Burst Size – если ВМ пытается передавать данные со скоростью большей, чем average bandwidth, то превышающие это ограничение пакеты помеща- ются в специальный буфер, размер его как раз и задается этой настройкой. Когда буфер заполнится, то данные из него будут переданы со скоростью Peak Bandwidth (если у коммутатора есть свободная полоса пропускания). Обратите внимание: эти настройки применяются к каждому виртуальномусетевому контроллеру (на самом деле – к порту вКоммутатора, куда те подключе-ны). Таким образом, если ВМ имеет 2 виртуальных сетевых контроллера в однойгруппе портов, то для каждого из них эти настройки применяются независимо. Для распределенных виртуальных коммутаторов возможно ограничение какисходящего, так и входящего трафика. 2.4.5. NIC Teaming. Группировка сетевых контроллеров Если зайти в настройки вКоммутатора или группы портов, то последней за-кладкой мы увидим «NIC Teaming», группировка контроллеров. Она нам потре-буется в том случае, если к вКоммутатору у нас подключен более чем один физи-ческий сетевой контроллер сервера (vmnic).
    • Настройки Security, VLAN, Traffic Shaping и NIC Teaming 129 А зачем мы можем захотеть, чтобы к одному вКоммутатору были подключенынесколько vmnic? Ответ прост: для отказоустойчивости в первую очередь и дляповышения пропускной способности сети – во вторую. Обратите внимание. Если мы подключаем к одному виртуальному коммутатору, стандартному или распределенному, несколько физических сетевых контролле- ров, то они должны быть из одного домена широковещательной рассылки. VMware не рекомендует подключать к одному вКоммутатору сетевые карты, подключенные в разные физические сети или разные VLAN: коммутаторы виртуальные обрабаты- вают только кадры Ethernet (второй уровень модели OSI) и не могут осуществлять маршрутизацию. Если у вКоммутатора только один физический сетевой контроллер, то самэтот контроллер, его порт в физическом коммутаторе и физический коммутаторцеликом являются единой точкой отказа. Поэтому для доступа в сеть критичныхВМ более чем правильно использовать два или более vmnic, подключенных в раз-ные физические коммутаторы. Но здесь встает вопрос политики их использования. Мы можем использоватьконфигурацию, дающую лишь отказоустойчивость – когда работает только одинvmnic, а остальные ожидают его выхода из строя, чтобы подменить его. Или мыможем задействовать сразу несколько сетевых контроллеров сервера, тем илииным образом балансируя между ними нагрузку. Взглянем на окно настроек – рис. 2.32. Failover Order. Самое нижнее поле позволяет выбрать используемые (ActiveAdapters), запасные (Standby Adapters) и неиспользуемые (Unused Adapters) фи-зические сетевые контроллеры из подключенных к этому вКоммутатору. Если выхотите, чтобы какие-то vmnic стали резервными и не были задействованы в нор-мальном режиме работы, тогда перемещайте их в группу Standby. Все (или не-сколько) оставляйте в Active, если хотите балансировку нагрузки. Ну а Unusedобычно нужна на уровне групп портов – когда у вКоммутатора много каналов вовнешнюю сеть, но трафик именно конкретной группы портов вы через какие-топускать не хотите ни при каких обстоятельствах. Failback. Эта настройка напрямую относится к Failover Order. Если у васvmnic3 Active, а vmnic2 Standby, то в случае выхода из строя vmnic3 его подменитvmnic2. А что делать, когда vmnic3 вернется в строй? Вот если Failback выставленв Yes, то vmnic2 опять станет Standby, а vmnic3 – опять Active. Соответственно,если Failback = No, то даже когда vmnic3 опять станет работоспособным, он ста-нет Standby. Каким образом ESX(i) понимает, что vmnic неработоспособен? См.пункт Network Failover Detection. Notify Switches. Эта настройка включает (Yes) или выключает (No) опове-щение физических коммутаторов об изменениях в MAC-адресах ВМ на ESX(i).Когда вы создаете новую ВМ и подключаете ее к группе портов (как вариант –добавляете в ВМ еще один виртуальный сетевой контроллер) или когда трафикВМ начинает идти через другой vmnic из-за сбоя ранее задействованного – тогдаESX(i) отправит пакет rarp с оповещением вида «Такой-то MAC-адрес теперь до-ступен на этом порту».
    • 130 Настройка сети виртуальной инфраструктуры Рис. 2.32. Окно настроек группировки контроллеров – NIC Teaming Рекомендуется выставлять в Yes для того, чтобы физические коммутаторымаксимально быстро узнавали о том, на каком их порту доступен MAC-адрес ВМ.Однако некоторые приложения потребуют выключения этой функции, напримеркластер Microsoft NLB. Network Failover Detection. Каким образом ESX(i) будет определять, что фи-зический сетевой контроллер неработоспособен? Вариантов два: Link Status Only – когда критерием служит лишь наличие линка, сигна- ла. Подобный режим позволит обнаружить такие проблемы, как выход из строя самого vmnic, отключенный сетевой кабель, обесточенный физиче- ский коммутатор. Такой подход не поможет определить сбой сети в случае неправильной на- стройки порта, например внесение его в неправильный VLAN и т. п. Также
    • Настройки Security, VLAN, Traffic Shaping и NIC Teaming 131 он не поможет в случае, если обрыв сети произошел где-то за физическим коммутатором; Beacon Probing – эта функция нужна только тогда, когда у вКоммутатора несколько внешних подключений (рис. 2.33) к разным физическим комму- таторам. При этой настройке, кроме проверки статуса подключения, вир- туальный коммутатор еще рассылает (с интервалом порядка 5–10 секунд) через каждый свой vmnic широковещательные пакеты, содержащие MAC- адрес того сетевого интерфейса, через который они ушли. И ожидается, что каждый такой пакет, посланный с одного vmnic, будет принят на других vmnic этого вКоммутатора. Если этого не происходит – значит где-то по каким-то причинам сеть не работает. Рис. 2.33. Пример конфигурации сети, при которой имеет смысл использовать Beacon Probing В этом примере пакеты, посланные через vmnic5, не дойдут до клиентов, под-ключенных к «дальним» физическим коммутаторам. Если для определения отка-зов сети используется «Link status only» – то ESX(i) не сможет определить такуюнеработоспособность сети. А beaconing сможет – потому что широковещательныепакеты от vmnic5 не будут приняты на vmnic3 и vmnic2. Но обратите внимание: если beacon-пакеты отправляются и не принимаютсяв конфигурации с двумя vmnic на вКоммутаторе, то невозможно определить, ка-кой из них не надо использовать – ведь с обоих beacon-пакеты уходят и на оба неприходят. Тогда вКоммутатор начинает работать в режиме «Shotgun», что здесь можноперевести как «двустволка», – начинает отправлять весь трафик через оба под-ключения, мол, через какой-то да дойдет. Конечно, такой ситуации лучше избегать. Сделать это можно правильнойструктурой физической сети, чтобы какие-то проблемы в ней решались за счетSpanning Tree. Вообще, механизм beaconing позиционируется как крайнее сред-
    • 132 Настройка сети виртуальной инфраструктурыство – если вы не можете повлиять на правильность конфигурации сети на физи-ческой стороне, то подстрахуйтесь от сбоев с помощью beaconing. Но эффектив-нее, когда подобные сбои в сети устраняются средствами этой сети и beaconing вамне нужен. Наконец, самая интересная настройка. Load Balancing. В этом выпадающем меню вы можете выбрать, по какому ал-горитму будет балансироваться трафик виртуальных машин между каналами вовнешнюю сеть виртуального коммутатора, к которому они подключены. Вариант настройки Use explicit failover order указывает не использовать ба-лансировку нагрузки. Используется первый vmnic из списка Active – см. чутьвыше описание Failover Order. А прочие три варианта настройки – это как развыбор того, по какому принципу будет балансироваться нагрузка. Суть в чем –есть трафик, и есть несколько каналов наружу (vmnic#). Надо трафик поделитьмежду каналами. Три варианта настройки отличаются тем, каким образом будетделиться трафик: Route based on the originating port ID – балансировка по номеру порта. У каждой ВМ (у каждого виртуального сетевого контроллера в ВМ) есть порт в вКоммутаторе, к которому она подключена. При данном варианте настройки балансировки нагрузки трафик будет делиться по этим пор- там – весь трафик от одного порта вКоммутатора будет идти в какой-то один vmnic; трафик из другого порта – через другой vmnic и т. д. Выбор очередного vmnic осуществляется случайным образом, не по его загрузке. Данный метод балансировки нагрузки используется по умолчанию и явля- ется рекомендуемым. Рекомендуемым он является потому, что дает какую- никакую балансировку нагрузки, а накладные расходы на анализ трафика минимальны. Однако трафик от одного виртуального контроллера не по- лучит полосы пропускания больше, чем дает один физический интерфейс, выступающий каналом во внешнюю сеть. Косвенный вывод отсюда – вир- туальная машина с несколькими виртуальными сетевыми контроллерами сможет задействовать несколько каналов во внешнюю сеть; Route based on source MAC hash – балансировка по MAC-адресу источни- ка. В этом случае трафик делится на основе MAC-адреса источника пакета. Таким образом, исходящий трафик делится точно так же, как и в случае балансировки по портам. На практике метод практически не применяется; Route based on ip hash – балансировка по хэшу (контрольной сумме) IP. Здесь критерием разделения трафика считается пара IP-источника – IP- получателя. Таким образом, трафик между одной ВМ и разными клиен- тами, в том числе за маршрутизатором, может выходить по разным vmnic. Этот метод балансировки нагрузки является самым эффективным, однако он может вызвать большую нагрузку на процессоры сервера, так как имен- но на них будет вычисляться хэш IP-адресов для каждого пакета. Также этот метод балансировки требует настроенной группировки портов (известной как link aggregation, Ether-Channel, Ethernet trunk, port channel, Multi-Link Trunking) на физическом коммутаторе, к которому подключен
    • Настройки Security, VLAN, Traffic Shaping и NIC Teaming 133 коммутатор виртуальный. Это вызвано тем, что при данном методе балан- сировки нагрузки MAC-адрес одной ВМ может одновременно числиться на нескольких vmnic, как следствие – на нескольких портах коммутатора физического. Что не является допустимым в штатном режиме работы, без группировки портов. В обратную сторону – если вы хотите настроить группировку портов меж- ду физическим и виртуальным коммутаторами, то вы настраиваете ее на физическом; а на виртуальном ставите балансировку по хэшу IP для нуж- ных групп портов – и все. Последний нюанс: если у вас один коммутатор виртуальный подключен к нескольким физическим (из соображений отказоустойчивости), то дале- ко не с любыми физическими коммутаторами получится использовать этот тип балансировки нагрузки в такой конфигурации. ESX(i) не поддерживает автоматической настройки группировки портов с помощью Link Aggregation Control Protocol (LACP). Link Aggregation (Etherchannel) на физическом коммутаторе должен быть настроен, только если на виртуальном коммутаторе используется баланси- ровка нагрузки по IP; Route based on physical NIC load – этот метод балансировки нагрузки доступен только для распределенных коммутаторов и только начиная с ESX(i) версии 4.1. Суть данного механизма напоминает работу перво- го варианта балансировки – по Port ID. Однако есть и значительные раз- личия. Во-первых, при принятии решения, через какой pNIC выпускать очередную «сессию», выбор осуществляется в зависимости от нагрузки на этот pNIC, а не случайным образом. Во-вторых, выбор повторяется каждые 30 секунд (в то время как во всех прочих вариантах однажды осуществлен- ный выбор не меняется до выключения ВМ). Резюме: рекомендуемым в общем случае является Route based on the physicalNIC load – по совокупности характеристик. Он дает балансировку нагрузки с ми-нимальными накладными расходами (но использовать этот метод балансировкивозможно только на распределенных коммутаторах, и только начиная с версии4.1). В случае если вы твердо уверены, что вам необходима большая эффектив-ность балансировки, используйте Route based on ip hash. Пример такой ситуа-ции – одна ВМ, генерирующая большой объем трафика и работающая с большимколичеством клиентов. Однако если нет возможности настроить etherchannel нафизическом коммутаторе, то Route based on ip hash использовать невозможно. Если не подходят и Route based on ip hash, и Route based on physical NICload, используйте Route based on the originating port ID. Более эффективную балансировку нагрузки рекомендуется ставить лишь длятой группы портов, для которой она необходима, – с целью свести к минимумунакладные расходы в виде нагрузки на CPU сервера. Для распределенных виртуальных коммутаторов все так же, с поправкой наабстрактность каналов во внешнюю сеть, для которых выполняется эта настройка.
    • 134 Настройка сети виртуальной инфраструктуры 2.4.6. Cisco Discovery Protocol, CDP CDP – протокол от Cisco, позволяющий обнаруживать и получать информа-цию о сетевых устройствах. ESX(i) 4 поддерживает этот протокол. Чтобы изменить настройки CDP для стандартных вКоммутаторов, вам пона-добится командная строка. Командаesxcfg-vswitch -b <vSwitch>покажет текущую настройку CDP для вКоммутатора <vSwitch>. Командаesxcfg-vswitch -B <mode> <vSwitch>поможет изменить значение настройки CDP для вКоммутатора <vSwitch>. До-ступные значения параметра <mode>: Down – CDP не используется; Listen – ESX получает и отображает информацию о коммутаторах Cisco, к которым подключен. На коммутаторы информация о вКоммутаторах не отправляется; Advertise – ESX отправляет информацию о вКоммутаторах наружу, но не принимает и не отображает информацию о физических коммутаторах; Both – ESX и обнаруживает подключенные физические коммутаторы, и отправляет на них информацию о коммутаторах виртуальных. Когда CDP настроен в listen или both, нам доступна информация о коммутато-рах Cisco. Для просмотра пройдите Configuration ⇒ Networking ⇒ иконка справаот vSwitch (рис. 2.34). Рис. 2.34. Просмотр информации от CDP
    • Разное 135 Для распределенных коммутаторов эта настройка выполняется из графиче-ского интерфейса. 2.5. Разное Несколько слов о разнообразных отдельных функциях, таких как Jumbo Fra-mes, TSO, генерация MAC-адресов ВМ. 2.5.1. Jumbo Frames Функция Jumbo Frames позволяет увеличить размер поля для данных в па-кете IP. Получается, что мы тем же числом пакетов (то есть с теми же наклад-ными расходами) передаем больше полезной информации. Если в стандартномIP-пакете поле для данных имеет размер 1500 байт, то при использовании JumboFrame – до 9000 байт. Jumbo Frames должны поддерживаться всеми узлами сети, то есть должныбыть включены на физических коммутаторах, виртуальных коммутаторах илираспределенных вКоммутаторах, а также в физических и виртуальных серве-рах. Jumbo Frames могут использоваться с сетевыми контроллерами 1 Гбит и10 Гбит. Jumbo Frames могут использоваться виртуальными машинами и портамиVMkernel для трафика NFS, iSCSI и vMotion. Для начала использования JumboFrames нам необходимо включить их поддержку на физических коммутаторах, за-тем для vSwitch и dvSwitch, а далее настроить их использование внутри ВМ илидля виртуального контроллера VMkernel. Проще всего включить их использование для распределенного коммутато-ра: Home ⇒ Networking ⇒ в контекстном меню dvSwitch пункт Edit Settings ⇒Advanced ⇒ Maximum MTU. Указываем размер поля для данных. Чаще всего ис-пользуется максимальный – 9000. Для стандартных коммутаторов VMware включение Jumbo Frames делаетсяв два этапа. Сначала подключитесь с помощью ssh или vSphere CLI к серверу ESX(i). Выполните командуesxcfg-vswitch -m <MTU> <vSwitch> Посмотреть текущие настройки можно командойesxcfg-vswitch –l Итак, первый шаг – включение поддержки Jumbo Frames на виртуальных ком-мутаторах – вы сделали. Шаг номер два – включить эту функцию на ВМ и/или наинтерфейсах VMkernel.
    • 136 Настройка сети виртуальной инфраструктуры Чтобы использовать Jumbo Frames с ВМ, в качестве гостевых ОС должны ис-пользоваться Windows Server (2003 или 2008, Enterprise или Datacenter Edition),Red Hat Enterprise Linux 5.0, SUSE Linux Enterprise Server 10. Тип виртуальногосетевого адаптера должен быть vmxnet2 или vmxnet3. В документации VMwareнаписано «Для включения Jumbo Frames смотрите документацию гостевой ОС».Но для Windows это делается примерно так, как показано на рис. 2.35. Рис. 2.35. Настройки Jumbo Frames в драйвере vmxnet3 Для проверки работы Jumbo Frames отправьте большой пакет соседней ВМ:ping -f -l 8972 <адрес ВМ> На выходе должно получиться что-то вроде:ping <IP ВМ> 8972(9000) bytes of data.8980 bytes from <адрес ВМ>: icmp_seq=1 ttl=128 time=3.36 ms Jumbo Frames и VMkernel Для использования Jumbo Frames с интерфейсами VMkernel необходимовключить эту функцию на них. Выполните командуesxcfg-vmknic –l Будет отображен список существующих интерфейсов VMkernel. Если в столб-це MTU стоит значение 1500, значит, Jumbo Frames не используется. К сожале-
    • Разное 137нию, изменить эту настройку для уже существующего интерфейса нельзя, можнотолько его пересоздать. Для этого удалите существующий интерфейс, для которо-го хотите включить Jumbo Frames. Когда удаляемый интерфейс подключен к стан-дартному виртуальному коммутатору, синтаксис команды следующий:esxcfg-vmknic –d <название группы портов, куда подключен удаляемый интерфейс>Затем создайте новый командойesxcfg-vmknic -a -i <ip address> -n <netmask> -m <MTU> <название группы портов, кудадолжен быть подключен создаваемый интерфейс > Замечание по поводу синтаксиса вышеприведенных команд: у каждого ин-терфейса VMkernel есть собственное имя вида vmk#. Каждый такой интерфейсчислится подключенным к группе портов. При выполнении вышеприведенныхкоманд под <название группы портов, куда подключен удаляемый интерфейс>понимается как раз название группы портов, а не интерфейса. Будьте осторожны – удаление интерфейса VMkernel может привести к раз-рыву сессий vMotion, FT, iSCSI или NFS. Убедитесь в том, что интерфейс не ис-пользуется, перед его удалением. Также имейте в виду, что после пересозданияMAC-адрес интерфейса изменится. Обратите внимание. Jumbo Frames нельзя включить на ESXi с бесплатной лицензией. Те команды по удалению и созданию интерфейса VMkernel, что были показа-ны выше, даны в варианте для стандартных вКоммутаторов. В случае использова-ния распределенных вКоммутаторов есть небольшой нюанс. В актуальной на момент написания версии vSphere CLI не оказалось способасоздать интерфейс VMkernel на распределенном виртуальном коммутаторе. По-этому следует поступить следующим образом. 1. Создать интерфейс VMkernel с MTU = 9000 на каком-то стандартном вир- туальном коммутаторе описанным выше способом. 2. Перенести этот интерфейс на распределенный виртуальный коммутатор. Для этого пройдите Configuration ⇒ Networking ⇒ кнопка Distributed Virtual Switch ⇒ ссылка Manage Virtual Adapter ⇒ Add ⇒ Migrate existing virtual adapter. Jumbo Frames имеет смысл использовать для интерфейсов VMkernel, задейство-ванных под любые задачи. Единственное исключение – трафик управления ESXi. 2.5.2. TSO – TCP Segmentation Offload, или TOE – TCP offload engine TOE (TCP offload engine) – функция физического сетевого контроллера, ког-да часть работы по обработке стека TCP/IP, такая как формирование и подсчетконтрольной суммы пакетов, выполняется не службой в ОС, а самим контрол-
    • 138 Настройка сети виртуальной инфраструктурылером. Часть этого механизма – TSO, TCP Segmentation Offload, функция такжеизвестна как «large segment offload», или LSO. TSO позволяет обрабатывать боль-шие пакеты (до 64 Кб) при любом размере MTU, формируя из большого пакетабольшее количество пакетов меньшего размера. В документации VMware обычно употребляется термин TSO, прочие назва-ния приведены для справки. Включение этой функции позволяет снизить нагрузку на процессоры сервераи повысить скорость работы сети. Заметная разница в нагрузке на процессорысервера будет, скорее всего, лишь в инфраструктурах со значительным сетевымтрафиком. Формально мы можем задействовать эту функцию для трафика ВМ и VMker-nel. «Формально» – потому, что мне встречались утверждения инженеров VMware,что в vSphere (в первых версиях, по крайней мере) сетевые контроллеры с TSOработают, но для трафика ВМ TSO не используется, так как внутренние тестыне показали значимой эффективности на разнообразных задачах (см. http://communities.vmware.com/thread/217825). Для трафика ВМ эту функцию можнозадействовать, прокинув физический сетевой контроллер в ВМ с помощью функ-ции VMDirectPath. Может потребоваться включение TSO в BIOS сетевого контроллера. Обрати-те внимание, что если контроллер с поддержкой TSO значится в списке совмести-мости ESX(i), то это означает, что ESX(i) заработает с этим сетевым контролле-ром, но не гарантирует работу с его функциями TSO. Если вас интересует именнофункционал TSO, то совместимость контроллера с ESX(i) нужно проверять имен-но с упором на TSO (по документации к сетевому контролеру). Для интерфейсов VMkernel TSO включен по умолчанию. Проверить это мож-но, выполнив командуesxcfg-vmknic –l Если в столбце TSO MSS значение 65535, то TSO включен. Если он выключен,то единственный способ его включить – пересоздать интерфейс заново (как этосделать, описано в разделе про Jumbo Frames). Выключить использование TSO для ESX(i) можно через расширенные на-стройки. Пройдите в настройки сервера: Configuration ⇒ Advanced Settings дляSoftware ⇒ настройке UseHwTSO вам нужно присвоить значение нуль. Скорее всего, выключение может потребоваться лишь в случае проблем с ис-пользованием этой функции с вашими сетевыми контроллерами. В случае проб-лем перед отключением TSO обновите прошивку контроллера и ESX(i) (или от-дельно драйвер для контроллера). 2.5.3. VMDirectPath Функция VMDirectPath позволяет выделять в приватное пользование ВМконтроллер в слоте PCI сервера. Таким контроллером может быть сетевая карта.Подробности см. в разделе про компоненты ВМ.
    • Разное 139 2.5.4. Отдельные порты На распределенном виртуальном коммутаторе виртуальные машины подклю-чаются к группам портов и к портам с конкретным номером. Например, в свой-ствах ВМ вы можете увидеть возможность подключения виртуального сетевогоконтроллера к конкретному порту – рис. 2.36. Рис. 2.36. Настройка сетевого подключения ВМ к отдельному порту dvSwitch Это может быть важно по той причине, что для распределенных виртуальныхкоммутаторов изменять настройки (такие как VLAN, traffic shaping, security и др.)можно и для отдельного порта.
    • 140 Настройка сети виртуальной инфраструктуры 2.6. Рекомендации для сети Рекомендации в общем случае следующие. Разделяйте разные виды трафика для повышения безопасности и/или произ-водительности. Разные виды трафика – это: управляющий трафик, то есть сеть Service Console для ESX или интерфейс VMkernel с флажком «management network». Изоляция управляющего трафика весьма важна с точки зрения безопасности, ибо компрометация ESX(i) означает компрометацию всех работающих на нем ВМ; трафик vMotion – более того, выделенная гигабитная сеть (в смысле выде- ленный гигабитный физический контроллер) под vMotion – это обязатель- ное условие для того, чтобы конфигурация была поддерживаемой. Плюс к тому трафик vMotion передается незашифрованным. Получается, что его перехват потенциально дает доступ к содержимому оперативной памяти мигрируемой ВМ или возможность изменить это содержимое; трафик Fault Tolerance. Более того, выделенная гигабитная (или больше) сеть под Fault Tolerance – это обязательное условие для того, чтобы конфи- гурация была поддерживаемой; трафик систем хранения – iSCSI/NFS; разумеется, трафик ВМ. Притом деление может быть и среди них, так что если у вас есть группа ВМ, трафик от которых может быть большим или к безопасности которого есть особые требования, имеет смысл подумать об изоляции их трафика. Для разделения трафика используются VLAN или разграничение на уровнефизических сетевых контроллеров. Последнее является более рекомендуемым –когда сетевых контроллеров у нас достаточное количество. Однако нередко сете-вых контроллеров меньше, чем по два на каждую задачу, и очень часто разграни-чение идет только по VLAN. Разграничение на уровне сетевых контроллеров следует делать созданием от-дельных виртуальных коммутаторов под разные задачи. В любом случае нельзя пренебрегать типичными для невиртуализированныхсистем средствами сетевой безопасности, такими как межсетевые экраны. Напом-ню, что у VMware есть собственное решение с таким функционалом – VMwarevShield Zones (http://www.vmware.com/products/vshield-zones/).
    • Глава 3. Системы хранения данныхи vSphereКак администраторы vSphere мы являемся потребителями дисковых ресурсов,предоставляемых системами хранения данных. Поэтому я буду про них рассказы-вать в потребительском ключе – что надо потребовать от администратора системыхранения данных, о чем надо знать для этого. Само администрирование СХД, тоесть «как делается создание LUN (или volume)», «как делается их “презентование”(presentation)» и т. п., – об этом говорить не буду ничего. Сначала выскажу соображения по выбору системы хранения. Затем – подроб-ности по использованию и настройке работы с СХД разных типов. Потом – пронекоторые специфические особенности и функции ESX(i) в области работы с си-стемами хранения. Ну а прямо сейчас – пара слов о специфике работы ESX(i)с дисковой системой (рис. 3.1): Рис. 3.1. Схема работы ВМ с дисковой подсистемой
    • 142 Системы хранения данных и vSphere На этом рисунке вы видите несколько виртуальных машин, к которым под-ключены дисковые ресурсы. Для всех ВМ, кроме третьей, диск является виртуаль-ным. В том смысле, что содержимое такого диска находится в файле типа «VirtualMachine Disk» (*.vmdk). Такой файл размещается на разделе, отформатированномв файловую систему «VMware File System», VMFS. В VMFS форматируются дис-ковые ресурсы (LUN) блочных систем хранения (на рисунке это системы хране-ния FC и iSCSI). Кроме того, к ESX(i) может быть подмонтирован сетевой ресурс по протоколуNFS – и на таком сетевом ресурсе также могут быть размещены файлы виртуаль-ных машин. На разделах VMFS и NFS могут быть расположены файлы виртуальных дис-ков сразу нескольких других ВМ, файлы настроек ВМ и файлы иных типов. Диском третьей виртуальной машины является весь диск (LUN), который под-ключен к серверу ESX(i) и затем подключен напрямую к этой ВМ. Такое подключе-ние называется RDM, Raw Device Mapping. Гостевая ОС обращается с этим LUN также, как если была бы установлена на физически сервер, которому презентован данныйLUN. Однако гипервизор скрывает от гостевой ОС тип системы хранения – и дажев случае RDM гостевая ОС воспринимает свой RDM-диск как локальный SCSI-диск.RDM-подключение возможно для дисков, подключенных по FibreChannel и iSCSI. HBA – это Host Bus Adapter, контроллер в сервере, через который идет об-ращение к системе хранения. Это могут быть Fibre Channel HBA для доступа кFibre Chanel SAN, локальный контроллер RAID для доступа к локальным дисками др. Вне зависимости от того, какой контроллер (и СХД какого типа) использу-ется, любая ВМ всегда видит свои диски как локальные диски SCSI, подключен-ные к локальному контроллеру SCSI. Этот контроллер SCSI гипервизор создаетдля ВМ наравне с прочим виртуальным оборудованием (единственный нюанс –ESX(i) 4 может подключать виртуальные диски к контроллеру IDE, а не SCSI).Доступом именно к СХД обладает только сам гипервизор, на рис. 3.1 показанныйкак «VMware vitualization layer». Гипервизор не сообщает ВМ о том, что ее дискомявляется файл, расположенный на локальном диске сервера; или файл на сетевомресурсе NFS; или LUN на iSCSI, подключенный как RDM. ВМ всегда видит своимдиском локальный диск SCSI (или IDE) – и изнутри нее нельзя понять, СХД какоготипа используется. Когда гостевая ОС адресует команды SCSI своему диску, эти об-ращения перехватываются гипервизором и преобразуются в операции с файлами наVMFS. Более подробно про VMFS (файловую систему для хранения виртуальныхмашин) и RDM (прямой доступ к диску) расскажу после рассказа о типах СХД. 3.1. Обзор типов СХД Для начала поговорим о том, какие бывают и что из себя представляют разныетипы систем хранения данных. Итак, мы можем воспользоваться: SAN, Storage Area Network – данный тип систем хранения предполагает блочный доступ. Возможен доступ к одним и тем же ресурсам нескольких серверов одновременно. В качестве среды передачи данных может исполь-
    • Обзор типов СХД 143 зоваться Fibre Channel и iSCSI (строго говоря, возможны подобные вари- анты с интерфейсами SAS/SCSI, но встречаются они гораздо реже); NAS, Network Attach Storage – системы хранения этого типа предоставля- ют доступ на уровне файлов. Возможен доступ к одним и тем же ресурсам нескольких серверов одновременно. ESX(i) поддерживают NAS только с протоколом NFS; DAS, Direct Attach Storage – данный тип систем хранения предполагает блочный доступ. Доступ к одним и тем же ресурсам нескольких серверов одновременно не возможен – это чрезвычайно снижает интерес к ним для инфраструктур vSphere. Обычно СХД этого типа представлены локальны- ми дисками сервера. Системы хранения данных разных типов отличаются по следующим характе-ристикам: стоимость. Очевидно, сравнение СХД по этому параметру выходит за пре- делы книги; функциональность самой системы хранения, например возможность созда- ния снимков состояния (snapshot) на уровне СХД. Про это тоже говорить здесь бессмысленно, потому что в каких-то решениях эти средства будут востребованы, а в каких-то – нет. Также различием являются функцио- нальные особенности того или иного подхода, например файловый доступ на NAS или блочный на SAN; производительность. Производительность – непростое понятие, много от каких факторов зависящее. Думаю, оправданно будет сказать, что главным отличием в производительности СХД разных типов является скорость ис- пользуемого интерфейса/среды передачи данных. Впрочем, темы произво- дительности дисковой подсистемы я касался в первой главе; функционал относительно vSphere – а вот по этому поводу поговорим под- робнее сейчас. Сравнение по поддерживаемым функциям я попытался отразить в табл. 3.1.Таблица 3.1. Сравнение функционала СХД для vSphere Тип Загрузка Включение VMotion HA API for VMFS MSCS SIOC СХД ESX ВМ sVMotion DRS Data RDM MFC FT ProtectionFibre + + + + + + + +ChanneliSCSI + + + + + + – +NAS – + + + + – – –DAS + + –/+ – + + +/– – Примечания к таблице: загрузка ESX(i) с iSCSI системы хранения возможна только с использова- нием аппаратного инициатора или сетевого контроллера, поддерживающе- го «iSCSI boot»;
    • 144 Системы хранения данных и vSphere если оба узла кластера MSCS/MFC работают на одном ESX(i), то СХД мо- жет быть любой; MSCS/MFC кластер возможно реализовать с системой хранения iSCSI, но такая конфигурация не будет поддерживаться VMware; VMFS и RDM показаны в одном столбце потому, что они являются альтер- нативами друг другу. Дисковые ресурсы (LUN) системы хранения с блоч- ным доступом ESX(i) может отформатировать в VMFS или подключить к виртуальной машине как RDM; SIOC расшифровывается как Storage IO Control, механизм контроля про- изводительности СХД относительно виртуальных машин. Подробнее о нем рассказывается в главе 6. Обратите внимание, что основные функции доступны для СХД любого типа. Таким образом, если стоит вопрос по выбору системы хранения, то примерныйплан может быть таким: 1. Определиться с необходимыми функциями (в первую очередь имеется в виду табл. 3.1). Например, если нам нужен RDM, то NAS не подойдет. С другой стороны, у систем хранения может быть свой собственный ин- тересный для вас функционал, например упрощающий резервное копиро- вание. 2. Определиться с необходимой производительностью. О чем стоит задумать- ся и что стоит принять во внимание, см. в первой главе в разделе, посвящен- ном сайзингу. 3. Если после пунктов 1 и 2 выбор типа системы хранения еще актуален, срав- ниваем варианты по цене. 3.2. DAS Direct Attach Storage, DAS – самый простой тип систем хранения. Характер-ной чертой этого типа хранилищ является то, что их дисковые ресурсы доступнылишь одному серверу, к которому они подключены. Наиболее характерный при-мер – локальные диски сервера. Да, да – их можно считать хранилищем DAS. ТеDAS, что являются отдельными устройствами, часто представляют из себя простокорзину (Enclosure) для дисков в отдельном корпусе. В сервере стоит контроллерSAS или SCSI, к которому и подключается полка DAS. Однако даже если вы ис-пользуете СХД Fibre Channel, но пара серверов подключена к ней без использо-вания коммутатора FC – некоторые (как правило, старые) модели СХД не смогутвыделить один и тот же LUN сразу обоим серверам. Такая конфигурация полно-стью подпадает под определение DAS. Для администраторов ESX(i) этот тип СХД обычно малоинтересен, потомучто такие системы не предоставляют доступа к файлам одной ВМ нескольким сер-верам: в крупных внедрениях это необходимо для живой миграции (VMware VMotion), для автоматической балансировки нагрузки (VMware DRS), для функций повышения доступности VMware HA и VMware FT;
    • NAS (NFS) 145 если речь идет про небольшие внедрения, где эти функции и так не предпо- лагаются к использованию, то ситуация примерно следующая: допустим, у нас есть несколько ESX(i). Если ВМ расположены на каком-то разделяе- мом хранилище, то администратор может пусть вручную, но очень быстро и с минимальными усилиями переносить ВМ между серверами. Если же у нас только DAS (например, несколько больших дисков локально в серве- ре) – то перенос ВМ возможен лишь по сети, что медленно. А если выйдет из строя сервер, к которому подключен DAS, – то ВМ будут недоступны. По сути, DAS используются в тех случаях, когда на разделяемое хранилищес достаточной производительностью нет бюджета, ну или под наши задачи не нуж-ны ни живая миграция, ни высокая доступность, ни прочие «продвинутые» функ-ции. Возможен вариант, когда мы используем под ESX(i) серверы с локальнымидисками, но программно реализуем доступ к этим дисковым ресурсам по iSCSI илиNFS. Обычно соответствующая служба работает внутри ВМ, которая доступныедля нее дисковые ресурсы ESX(i) предоставляет ему же, но уже по iSCSI/NFS.А еще есть возможность с помощью сторонних программных средств реализоватьрепликацию файлов ВМ между серверами. В таком случае мы получим дешевуюинфраструктуру без СХД, с одной стороны, но с достаточно высоким уровнем до-ступности – в случае выхода из строя сервера есть возможность запустить репликуВМ с него на другом сервере, с потерей данных с момента последней репликации. Впрочем, реализация такого рода вариантов, с привлечением программногообеспечения третьих фирм, в данной книге рассматриваться не будет. Кто-то может заметить, что на рынке присутствуют модели систем хранения,которые предполагают соединение с серверами по интерфейсу SAS, но позволяютмножественный доступ. Такие варианты, по данной классификации, имеет смыслотнести к SAN. 3.3. NAS (NFS) Network Attached Storage, NAS – устройство хранения, подключенное к сети.Этот тип систем хранения также весьма несложен. Его характерные черты: доступ к дисковым ресурсам по локальной сети. На стороне сервера требу- ются обычные сетевые контроллеры; доступ к одним и тем же дисковым ресурсам возможен одновременно с не- скольких серверов; доступ на уровне файлов – то есть файловая система создается и обслу- живается системой хранения, а не сервером. Это ключевое отличие NAS от DAS и SAN, где доступ к СХД идет на уровне блоков и серверы имеют возможность использовать собственную файловую систему. Характерный пример – файловый сервер. Он предоставляет по сети доступ науровне файлов к разделяемой (Shared) папке сразу многим клиентам (серверам).Однако есть и специализированные системы хранения, использующие собствен-ную ОС. Весьма сильные позиции в этом сегменте систем – у компании NetApp.
    • 146 Системы хранения данных и vSphere Существуют два основных протокола инфраструктур NAS – NFS для *nix иSMB для систем Windows. ESX позволяет запускать ВМ с NAS, использующих протокол NFS. Подклю-чение по протоколу SMB с ESX возможно, однако использовать его получитсялишь для обмена данными, резервного копирования, но не для запуска ВМ. По сравнению с iSCSI с программным инициатором, NFS вызывает меньшуюнагрузку на процессоры сервера. Если сравнивать NAS с системами хранения других типов по функционалуотносительно vSphere, то NFS система хранения, с одной стороны, обеспечиваетвесь основной функционал. Такие функции, как VMotion, DRS, HA, FT, работаютс хранилищем NFS. С другой стороны, системы хранения NAS способны обеспечить достаточноинтересный дополнительный функционал. На примере систем хранения NetAppбудут доступны следующие функции: больший максимальный размер одного хранилища. Если брать NetApp как наиболее применимое NFS-хранилище, то в зависимости от уровня и по- коления системы хранения ограничения на размер одного тома данных на- чинаются от 16 Тб и заканчиваются 100 Тб; дедупликация на уровне системы хранения; кроме увеличения размера хранилища (что возможно и для VMFS), допу- стимо осуществить уменьшение его размера (чего для VMFS невозможно); cнимки состояния (snapshot) средствами системы хранения. Сами по себе снимки не прерогатива NFS, однако в случае NFS мы получаем грануляр- ность на уровне отдельных файлов vmdk. То есть в снимке системы хране- ния у нас будут не LUN со множеством vmdk вместе, а отдельные vmdk. Так как снимок в NetApp доступен как простая копия, сделанная в определен- ный момент времени, то мы можем просто подключить эту копию по NFS только на чтение. Затем можно осуществить резервное копирование или восстановление файлов vmdk, а также подключить vmdk из снимка к ВМ и восстановить отдельные файлы «изнутри» этого vmdk. То есть при вос- становлении одной ВМ из снимка состояния хранилища средствами СХД нет необходимости откатывать все хранилище целиком, со всем его содер- жимым. Можно восстановить или отдельный виртуальный диск, или даже отдельный файл; vmdk Thin Provisioning – вне зависимости от типа vmdk файла с точки зре- ния ESX(i), система хранения сама способна обеспечить thin provisioning; Single-file FlexClone – функция систем хранения в NetApp, в чем-то сход- ная с работой дедупликации, только для конкретных файлов. Позволяет получить значительную экономию места и скорости развертывания для однотипных виртуальных машин; при использовании репликации как средства повышения доступности инфраструктуры в случае возникновения необходимости переключения ESX(i) на копию хранилища NFS требуется меньше шагов для этого, и сами шаги более просты. Для FC/iSCSI LUN требуется так называемый «resig-
    • NAS (NFS) 147 naturing», NFS-хранилище же просто подключается без дополнительных условий. Здесь NetApp упомянут лишь для примера того, какого рода функциями могутобладать системы хранения данного класса. 3.3.1. Настройка и подключение ресурса NFS к ESX(i) Для того чтобы подключить дисковые ресурсы по NFS, на стороне ESX необ-ходимо настроить интерфейс VMkernel, через который и будет передаваться тра-фик NFS. Схема сети должна быть примерно такой, как на рис. 3.2. Рис. 3.2. Интерфейс VMkernel на стандартном или распределенном виртуальном коммутаторе Почему «примерно такой»? Потому что на этом же вКоммутаторе могут рас-полагаться и любые другие виртуальные сетевые контроллеры – и для ServiceConsole, и для ВМ, и для VMkernel под другие нужды. А также у этого вКомму-татора может быть больше одного канала во внешнюю сеть (как в правой частирисунка) – это даже рекомендуется, для больших надежности и скорости (multipa-thing для NFS реализуется через Link Aggregation или через статичные маршрутык разным IP-адресам одной СХД). Проверить правильность настройки IP, VLAN (если используются) и вообщедоступность системы хранения NFS по сети можно следующим образом: для ESX командой vmkping <IP NFS сервера> Используется специальная команда по той причине, что простой ping идет через интерфейсы SC, чего в данном случае нам не надо; для ESXi соответствующим пунктом локального меню (рис. 3.3). Альтернатива этому меню – или команда ping из локальной консоли, или ко-манда ping в подключении по SSH. После создания интерфейса VMkernel необходимо подключить ресурс NFS.Для этого в настройках сервера пройдите Configuration ⇒ Storage ⇒ Add Storage,на первом шаге мастера выберите подключение Network File System. На следую-
    • 148 Системы хранения данных и vSphere Рис. 3.3. Проверка доступности NFS-сервера из локальной консоли ESXiщем шаге необходимо указать IP или имя системы хранения NFS и имя сетевогоресурса (см. рис. 3.4). В самом нижнем поле вы указываете метку, название хра-нилища – под этим именем этот ресурс NFS будет отображаться в интерфейсеESX(i) и vCenter. Обратите внимание на флажок «Mount NFS read only». Он вам пригодитсядля подключения сетевого ресурса в режиме только чтения. Однако для запускаВМ ESX(i) требует разрешений read/write на NFS. Так что NFS только для чтенияпригодится для неизменяемых данных, таких как файлы шаблонов ВМ, образы iso. По умолчанию вы можете подключить к ESX(i) до восьми ресурсов NFS. Есливам необходимо больше, пройдите в Configuration ⇒ Advanced Settings для Soft-ware (рис. 3.5). Там вам нужны раздел NFS и настройка NFS.MaxVolumes. Опи-сание прочих расширенных настроек для NFS см. в базе знаний VMware, статьяhttp://kb.vmware.com/kb/1007909. Обратите внимание. ESX(i) использует для блокировки файлов не средства NFS, а собственную систему. Когда сервер открывает файл ВМ на NFS, создается файл с именем вида .lck-XXX, препятствующий открытию этого же файла ВМ с другого сер- вера. Не удаляйте файлы .lck-XXX, если не считаете, что файл существует по ошибке (теоретически возможна ситуация, что из-за какого-то сбоя файл блокировки не уда- лен и мы не можем получить доступ к вроде бы выключенной ВМ).
    • SAN, Fibre Channel 149 Рис. 3.4. Подключение ресурса NFS к серверу ESX(i) 3.4. SAN, Fibre Channel Storage Area Network, SAN – сеть хранения данных. Инфраструктура SANпредполагает создание выделенной сети только под данные. В случае Fibre Chan-nel SAN такая сеть строится на оптоволокне. Требуются специальные Fibre Chan-nel коммутаторы и специальные Fibre Channel контроллеры в серверы. Обычно,и в этой книге в частности, их называют FC HBA, Host Bus Adapter. Как правило,приобретение всего этого плюс покупка и прокладка оптоволокна приводят к удо-рожанию инфраструктуры FC SAN по сравнению с другими решениями. К плю-сам FC SAN можно отнести все остальное – максимальная производительность,минимальные задержки, полный функционал относительно ESX(i). Схема Fibre Channel SAN показана на рис. 3.6. Здесь мы никак не будем касаться настроек со стороны SAN. После того какадминистраторы SAN презентуют нашим серверам ESX(i) какие-то новые LUN
    • 150 Системы хранения данных и vSphere Рис. 3.5. Расширенные настройки (Advanced Settings) для NFS(или отключат старые), администраторам ESX(i) надо выполнить команду Rescan(на странице Configuration ⇒ Storage Adapters ⇒ справа наверху rescan), и вуа-ля – со стороны ESX мы увидели дисковые ресурсы (рис. 3.7). HBA, с точки зрения ESX(i), представляет собой контроллер SCSI, и гиперви-зор с ним обращается как с обычным контроллером SCSI. Этот контроллер прини-мает на вход команды SCSI, их же отдает на выход. В SAN же HBA отдает командыSCSI, обернутые в пакеты Fibre Channel. Дисковые ресурсы, предоставляемые FCСХД, для серверов выглядят как обычные диски – см. рис. 3.7. На рисунке вы видите выделенный FC HBA (наверху) и видимые через негодиски (LUN), а также локальный контроллер SCSI (внизу) с видимыми ему дис-ками. В случае локального контроллера мы видим, скорее всего, созданный на немRAID из локальных дисков сервера. А теперь взгляните на рис. 3.8. Здесь вы видите список хранилищ (то есть разделов для хранения файловВМ), доступных так или иначе. И диски локальные здесь отображаются (да и ис-
    • SAN, Fibre Channel 151 Рис. 3.6. Схема FC SAN Источник: VMwareпользуются) так же, как и FC LUN (впрочем, то же справедливо и для LUN iSCSI,и для NFS). Что нам полезно будет знать про SAN как администраторам ESX? Топологию хотя бы с одним коммутатором FC называют SAN fabric, иногдапрямо по-русски говорят «фабрика». Альтернатива этому – подключение СХДнапрямую к HBA сервера. Как правило, конфигурации без коммутатора FC пред-полагают подключение двух серверов к двум контроллерам одного дискового мас-сива – для экономии на стоимости коммутатора. Однако здесь возможна пробле-ма следующего рода: некоторые FC СХД, особенно начального уровня, обладаютвозможностью работать только в режиме Active-Passive. Такой режим означает,что один LUN в какой-то момент времени может принадлежать только одномуконтроллеру системы хранения. И если разные серверы будут пытаться обратить-ся к одному LUN через разные контроллеры, СХД будет непрерывно переключатьLUN между контроллерами, что может привести к их зависанию или, по крайнеймере, к сильному падению производительности. Кстати, по этой же причине не ре-комендуется использовать для систем хранения Active-Passive настройку round-robin multipathing. В общем-то, я это к чему – читать документацию системы хранения необходи-мо и в случаях попроще, могут быть специфические нюансы. Что же мы можем настроить в случае Fibre Channel SAN на стороне ESX(i)?Именно настроить, по большому счету, совсем немного.
    • 152 Системы хранения данных и vSphere Рис. 3.7. Диски на FC и локальном SCSI-контроллере 3.4.1. Адресация и multipathing Вернитесь к схеме SAN на рис. 3.6. На нем вы видите, что в каждом сервередва HBA (или один двухпортовый), подключенных каждый к своему коммутаторуFC, и в СХД тоже два контроллера. Это – рекомендованная конфигурация, когда
    • SAN, Fibre Channel 153 Рис. 3.8. Список хранилищ ESX(i)у нас все компоненты SAN задублированы. Следствием дублированности явля-ется наличие нескольких путей от каждого сервера к каждому LUN. Например,первый сервер со схемы может добраться до LUN 1 четырьмя путями: 1. HBA 1 : SP 1 : LUN1. 2. HBA 1 : SP 2 : LUN1. 3. HBA 2 : SP 1 : LUN1. 4. HBA 2 : SP 2 : LUN1. (Строго говоря, для того чтобы заработали пути 2 и 3, необходимо соединитьмежду собой коммутаторы FC на рис. 3.6, чего на этом рисунке не показано.) Модуль multipathing есть в ESX(i) по умолчанию, поэтому он определит,что видит не четыре разных LUN, а один с несколькими путями. См. пример нарис. 3.9. Рис. 3.9. Пример LUN с двумя путями к нему
    • 154 Системы хранения данных и vSphere Здесь вы видите два пути к LUN под названием FC_LUN_7. Это записиvmhba2:C0:T1:L0 и vmhba2:C0:T0:L0. Расшифровываются эти обозначения следу-ющим образом: vmhba# – это имя контроллера в сервере. Физического контроллера (или порта на многопортовом HBA), который используется в сервере ESX(i), а не виртуального контроллера SCSI, который создается для ВМ. Их спи- сок можно увидеть в настройках сервера Configuration ⇒ Storage Adapter; C# – номер канала SCSI. Обычно равен 0, но некоторые контроллеры каж- дую сессию SCSI выделяют в отдельный «канал». Более актуально для про- граммного инициатора iSCSI – он отображает разными каналами разные интерфейсы VMkernel, через которые может подключиться к LUN; T# – номер «target», таргета, контроллера в СХД (Storage Processor). Раз- ные ESX(i), обращаясь к одним и тем же контроллерам, могут нумеровать их по-разному; L# – номер LUN. Эта настройка задается (или в простейших случаях вы- бирается автоматически) со стороны системы хранения. Таким образом, в примере мы видим, что оба пути к FC_LUN_7 проходятчерез один контроллер сервера, но через разные контроллеры в системе хране-ния. Косвенный вывод – HBA в сервере является единой точкой отказа в данномслучае. Когда путей к LUN несколько, в отдельно взятый момент времени ESX(i) мо-жет работать только с каким-то одним (используемый в данный момент помеченстрокой «(I/O)» в столбце Status, рис. 3.9). Переключение на другой произойдетлишь в случае отказа используемого. Для выбора того, какой путь использоватьдля доступа к LUN, у нас есть настройка политики (обратите внимание на выпа-дающее меню в верхней части рис. 3.9): Fixed (VMware) – если выбрана эта настройка, то сервер всегда будет ис- пользовать путь, выбранный предпочитаемым для доступа к LUN. Если путь выйдет из строя, произойдет переключение на другой, но когда пред- почитаемый вернется в строй – опять начнет использоваться он; Most Recently Used (VMware) – если выбрана эта настройка, то сервер будет использовать текущий путь для доступа к LUN. Если путь выйдет из строя, произойдет переключение на другой, и он продолжит использовать- ся, даже когда предыдущий вернется в работоспособное состояние; Round Robin (VMware) – в случае round robin большой поток данных делится на части и передается через разные пути поочередно. Теоретиче- ски это позволяет повысить производительность на участке между дис- ками и драйверами в ОС. Но это не спасет от задержек, если не хватает производительности дисков. Также чтобы использовать эту функцию, массив должен быть полностью active/active. По умолчанию другой путь начинает использоваться после передачи 1000 команд. Эта политика не используется по умолчанию по той причине, что она недопустима при реализации кластеров Майкрософт (MSCS/MFC) между виртуальными машинами.
    • SAN, Fibre Channel 155 Обратите внимание. В названии политик multipathing в скобках указано «VMware» по той причине, что это реализация данных политик от VMware. Но при установке на ESX(i) сторонних модулей multipathing возможно появление реализаций этих же по- литик от поставщика модуля multipathing. В общем случае дать рекомендацию по выбору политики сложно, ищите ре-комендации в документации вашей системы хранения. Однако пару соображенийвыскажу. Политика Fixed жестко задает путь к каждому LUN. Это хорошо для массивовActive-Active и не рекомендуется для массивов Active-Passive. Также Fixed по-зволяет вручную сбалансировать нагрузку на каналы путем указания для разныхLUN разных предпочитаемых путей. Не изменяйте настройку multipathing, если не понимаете зачем. Внимательноизучайте документацию производителя системы хранения и ищите рекомендациипо этим настройкам там. 3.4.2. Про модули multipahing. PSA, NMP, MMP, SATP, PSP К одному LUN у нас могут вести несколько путей. Через разные HBA и разныеконтроллеры в СХД. За счет нескольких путей до LUN мы получаем дублиро-вание и возможность продолжить работу при выходе из строя какого-то компо-нента инфраструктуры SAN за счет перехода к работающему пути. Еще наличиенескольких путей может помочь повысить производительность за счет распреде-ления нагрузки между путями. Настройки multipathing определяют: когда переключаться – через какое количество непрочитанных/незаписан- ных блоков посчитать используемый путь сбойным; какой target использовать – любой или явно указанный; какой HBA использовать – любой, явно указанный или наименее загру- женный. После названия политик multipathing, описанных чуть выше, в скобках напи-сано «VMware». Это потому, что это настройки встроенного модуля multipathing,разработанного VMware. А в ESX(i) версии 4 появилась возможность использо-вать сторонние модули. При чтении документации на эту тему вам могут встретиться следующие тер-мины: PSA – Pluggable Storage Architecture; NMP – Native Multipathing; SATP – Storage Array Type Plugins; PSP – Path Selection Plugins. Как они соотносятся, см. на рис. 3.10. PSA – это общее название архитектуры, которая позволяет ESX(i) использо-вать сторонние модули для работы с SAN. Также PSA – это название набора API дляVMkernel. Они были добавлены в состав гипервизора и выполняют такие задачи, как:
    • 156 Системы хранения данных и vSphereРис. 3.10. Схема связей модулей гипервизора для работы с дисковой подсистемой Источник: VMware загрузка и выгрузка модулей MPP; обнаружение и удаление путей к LUN; перенаправление запросов ввода-вывода к нужному MPP; разделение пропускной способности между ВМ; сбор статистики по вводу-выводу; координация действий Native Multipathing Module и сторонних плагинов, разработанных с помощью PSA API. NMP – стандартный модуль работы с системой хранения, используемый поумолчанию и включающий multipathing. Ассоциирует набор путей с LUN. NMPподдерживает все системы хранения из списка совместимости vSphere. NMP со-держит в себе два компонента – SATP и PSP. SATP – управляет переключением путей, отслеживает доступность путей исообщает об изменениях в NMP, и все это – для конкретного типа СХД. То естьNMP работает со всеми типами поддерживаемых хранилищ за счет того, что длякаждого типа у него в составе есть свой SATP, осведомленный о том, как работатьс той или иной моделью СХД. Каждый SATP для конкретной модели может об-ладать возможностью выполнять специфичные для модели действия по обнару-жению отказа пути и переходу на резервный путь. VMware поставляет SATP длявсех поддерживаемых систем хранения – generic Storage Array Type Plugins длятиповых систем хранения и local Storage Array Type Plugin для DAS. Увидеть информацию о SATP и их настройках можно при помощи команд:esxcli nmp satp listesxcli nmp satp listrulesesxcli nmp satp listrules –s <конкретный SATP>
    • SAN, Fibre Channel 157 PSP (Path selection plugin) – выбирает лучший путь. По сути, этот компонентотрабатывает настройку multipathing (ту, что Fixed/MRU/Round Robin). Сторон-ний PSP может уметь балансировать нагрузку по более сложным алгоритмам, не-жели стандартный. В частности, задействовать все пути одновременно, а не по-следовательно. Самое главное – архитектура PSA предполагает возможность использованиясторонних модулей multipathing, которые могут работать вместо или вместе состандартными. Их VMware называет MPP. MPP – multipathing plugin. Сторонний модуль работы с системой хранения(сторонний модуль multipathing) является альтернативой NMP, то есть стандарт-ному модулю работы с системами хранения. Разрабатывается MPP поставщикамиСХД, которые могут усовершенствовать способы определения сбоев и перехода надругие пути за счет использования специфичных возможностей системы хране-ния. Также с помощью этих сторонних модулей возможна работа ESX(i) с масси-вами, изначально не поддерживаемыми. Сторонние модули делятся на три категории (рис. 3.11): сторонние MPP обеспечивают поддержку специфичной модели СХД и де- лают работу с ней более производительной и надежной. Модуль или моду- ли MPP работают одновременно с NMP – стандартным модулем работы с системами хранения, если тот используется ESX(i) для других систем хранения (например, локальных дисков); Рис. 3.11. Схема сосуществования встроенного и сторонних модулей multipathing Источник: VMware
    • 158 Системы хранения данных и vSphere сторонние SATP интегрируются в NMP, обеспечивают его работу с систе- мами хранения, которых тот не поддерживает; сторонние PSP интегрируются в NMP. Содержат в себе описания более сложных алгоритмов балансировки I/O. Когда сервер загружается, PSA обнаруживает все пути к LUN’ам. В соответ-ствии с правилами, описанными в файле настройки (esx.conf), PSA определяет,какой из модулей multipathing должен управлять путями к тому или иному хра-нилищу. Этими модулями могут быть NMP от VMware или MPP от стороннегопроизводителя. NMP, опять же в зависимости от настроек, выбирает, какой из доступныхSATP использовать для мониторинга путей, ассоциирует нужный модуль PSPдля управления этими путями. Например, для семейства EMC CLARiiON CXпо умолчанию используются SATP-модуль «VMW_SATP_CX» и PSP-модуль«Most Recently Used». С помощью vSphere CLI и командыesxcli corestorage claimrule listможно посмотреть на загруженные модули и указать настройки (claim rules) дляPSA, NMP SATP, настроить маскировку LUN. Командойesxcli nmp satp listможно увидеть список SATP для NMP. А командойesxcli nmp psp listможно увидеть список PSP для NMP. Эти настройки хранятся в файле /etc/vmware/esx.conf, и их можно просмот-реть. Увидите строчку вида:/storage/plugin/NMP/config[VMW_SATP_SYMM]/defaultpsp = «VMW_PSP_FIXED» Эта строка файла настроек сообщает: Для SATP с именем «VMW_SATP_SYMM» использовать PSP с именем«VMW_PSP_FIXED». Этот SATP применяется для работы с EMС Symmetrix,этот PSP предполагает политику путей «Fixed». Из графического интерфейса мы можем увидеть следующее: Configuration ⇒Storage Adapters ⇒ нужный HBA ⇒ кнопка Paths (рис. 3.12). Здесь мы видим информацию о доступных путях и о том, какие из путей яв-ляются активными. Для ESX(i) четвертой версии под «Active» путем понимаетсятот, который можно задействовать для доступа к LUN. Задействованный в дан-ный момент путь помечается как «Active (I/O)». «Standby» – такой путь можно
    • SAN, Fibre Channel 159 Рис. 3.12. Информация о доступных путяхзадействовать в случае сбоя активного пути. «Broken» (на рисунке таких нет) –сбойный путь. Звездочкой помечается предпочитаемый (Preferred) путь в случаеполитики multipathing «Fixed». Configuration ⇒ Storage ⇒ кнопка Devices ⇒ интересующий LUN (рис. 3.13). Рис. 3.13. Информация о путях
    • 160 Системы хранения данных и vSphere Здесь можно увидеть, какой модуль управляет доступом к LUN. В данном при-мере это NMP, то есть стандартный модуль от VMware. Ну и наконец, к чему все это. Поставщик вашей системы хранения может предложить вам модуль multipa-thing, работающий лучше стандартного из состава ESX(i). Если так, имеет смыслего установить. Подробности ищите в документации конкретного производителя.Например, EMC предлагает PowerPath for VMware vSphere 4 – это и есть MPP. Резюме: для ESX(i) 4 VMware предоставляет возможность и механизмы дляразработки сторонних модулей работы с системами хранения, которые могут ра-ботать эффективнее стандартного. Несколько слов про NMP, стандартный модуль multipathing. Достаточно важ-ный вопрос: сколько времени требуется, чтобы перейти на другой путь в случаеотказа используемого? NMP начинает задействовать другой путь сразу же, кактолько драйвер HBA вернет отказ I/O. В случае Fibre Channel это время меньше30 секунд. Затем NMP нужно менее 30 секунд, чтобы переключиться на другойпуть. Таким образом, время недоступности LUN для ESX(i) будет меньше 60 се-кунд. Все запросы к дисковой подсистеме от ВМ ESX(i) поместит в очередь. Ноименно из-за возможности такой паузы VMware рекомендует устанавливать вре-мя ожидания реакции ввода-вывода для гостевой ОС в 60 секунд (подробности см.в разделе 5.2.4 «Рекомендации для эталонных ВМ»). 3.4.3. Про зонирование (Zoning) и маскировку (LUN masking, LUN presentation) В администрировании SAN есть два понятия: Zoning и LUN Masking. Ониважны, поэтому их коснусь чуть подробнее. Вот смотрите – у вас есть система хранения, и к ней подключены серверы.Скорее всего, это серверы с разными задачами. Какие-то используются подвиртуальные машины, и на них установлен ESX(i). Какие-то используются безвиртуализации, и на них установлены Windows, Linux и другие операционныесистемы. И на системе хранения мы создаем отдельные LUN’ы для этих серверов. В по-давляющем большинстве случаев нам не надо, чтобы LUN, на котором ESX хранитсвои ВМ, был доступен с физического сервера с, к примеру Windows, и наоборот.Более того, если он будет доступен – это очень опасно, так как может привести кповреждению данных. ESX на таком LUN создаст свою файловую систему, VMFS,а Windows понятия не имеет, что это за файловая система. И будет считать этотдиск пустым. И даст нам его отформатировать в NTFS. А это уничтожит VMFS иВМ на ней. Вот для предотвращения подобных эксцессов и необходимы правиль-ное зонирование и маскировка. Зонирование – процесс настройки доступности СХД со стороны серверов.Выполняется на уровне коммутатора FC, в котором мы указываем видимость пор-тов друг другом. То есть мы настраиваем, какие HBA к каким SP смогут обращать-ся. Некоторые коммутаторы FC требуют настройки зонирования всегда, вне зави-
    • SAN, Fibre Channel 161симости от того, необходима ли эта настройка нам. Но как правильно настраиватьзоны – надо смотреть документацию конкретного производителя. Зонировать можно по портам или по WWN. WWN, World Wide Name – этоуникальный идентификатор устройства в сети SAN, аналог MAC-адреса Ethernet.Например, если вы посмотрите на рис. 3.14, то увидите в нижней части рисункаWWN контроллера в сервере (HBA) и контроллера в системе хранения (SP). Рис. 3.14. Информация о путях к LUN VMware рекомендует зонировать по портам, а не по WWN. Связано это с тем,что одному порту ESX(i) могут соответствовать несколько WWN. Такое можетпроизойти в случае, если мы назначаем уникальные собственные WWN каким-товиртуальным машинам. Позволяющий это механизм называется NPIV – N-PortID Virtualization. Если наше оборудование FC поддерживает данный стандарт, тов свойствах ВМ мы можем активировать соответствующую настройку. Подроб-ности см. в разделе, посвященном ВМ. Маскировка – настройка, выполняемая на системе хранения. Суть настрой-ки – в указании того, какому HBA (следовательно, серверу) какие LUN должныбыть видны. Делается на уровне WWN, то есть в интерфейсе управления систе-мы хранения мы должны выбрать LUN и выбрать WWN тех серверов (их HBA),которые должны его увидеть. В интерфейсах разных систем хранения эта опера-
    • 162 Системы хранения данных и vSphereция может называться по-разному; где-то она называется «презентованием LUN»,LUN Presentation. Настройки зонирования и маскировки являются взаимодополняющими.С точки зрения администратора ESX(i), необходимо, чтобы корректно было вы-полнено зонирование – наши серверы ESX(i) имели доступ к СХД. И на этих СХДбыла сделана маскировка – то есть серверы ESX(i) имели доступ к выделеннымпод ВМ LUN, не имели доступа ни к каким другим LUN и чтобы к их LUN не име-ли доступа никакие другие серверы. Обратите внимание. Маскировка может выполняться на самом сервере ESX(i). Это необходимо в том случае, когда мы хотим скрыть какой-то LUN от ESX(i), но сделать это на SAN мы по каким-то причинам не можем. Для того чтобы замаскировать LUN со стороны ESX(i) (фактически спрятать самому от себя), нам понадобятся vSphere CLI и раздел Mask Paths в документе Fibre Channel SAN Configuration Guide. 3.5. SAN, iSCSI Storage Area Network, SAN – сеть хранения данных. Инфраструктура SANпредполагает создание выделенной сети только под данные. В случае iSCSI SANтакая сеть строится поверх обычной инфраструктуры IP. Используются обычные коммутаторы Ethernet, а в серверах в качестве кон-троллеров используются более или менее специализированные аппаратные ини-циаторы iSCSI(iSCSI HBA) или обыкновенные сетевые контроллеры (за счетиспользования программного инициатора – службы, входящей в состав ESX(i) лю-бых редакций). За счет использования стандартной, относительно дешевой и частоуже имеющейся инфраструктуры IP, iSCSI SAN может оказаться дешевле FC SAN. Меньшая цена, простота внедрения, практически все те же функции, что и у FCSAN, – это плюсы iSCSI. В минусы записывают меньшую максимальную скорость ′и, возможно, большие задержки (при использовании дешевого 1 Гб Ethernet). Для iSCSI актуально практически все, что выше написано для Fibre ChannelSAN. Теперь напишу про моменты, специфичные именно для iSCSI. В контексте iSCSI часто употребляется термин «инициатор», initiator. В ши-роком смысле инициатор iSCSI – это тот, кто инициирует обращение к ресурсам(здесь – дисковым), то есть сервер. В нашем случае ESX(i)-сервер. Инициатор iSCSI в более узком смысле – это контроллер, который обеспечи-вает подключение к iSCSI СХД. Инициатор iSCSI – это контроллер SCSI, который принимает команды SCSI отVMkernel, упаковывает их в пакеты IP и отправляет по Ethernet на хранилище. По-лучает в ответ пакеты IP, извлекает из них команды SCSI и отдает их гипервизору. iSCSI инициатор бывает аппаратный, с аппаратной поддержкой и программ-ный (рис. 3.15). В случае аппаратного инициатора ESX(i) видит его как обычный дисковыйконтроллер, HBA. Гипервизор отдает SCSI команды его драйверу, тот передает ихконтроллеру, и контроллер на своем чипе инкапсулирует их в IP, которые сам от-дает в сеть.
    • SAN, iSCI 163 Рис. 3.15. Иллюстрация разницы между вариантами инициатора iSCSI Источник: VMware В случае программной реализации гипервизор передает команды SCSI навход службе программного инициатора iSCSI, та запаковывает SCSI в IP, а IPотдает стеку TCP/IP VMkernel. А VMkernel через обычные сетевые контрол-леры отдает эти пакеты в сеть. Однако во множестве случаев производитель-ности и обеспечиваемой скорости у программного iSCSI оказывается вполнедостаточно. В случае промежуточной реализации у нас есть контроллеры, которые одно-временно и являются сетевыми, и предоставляют функционал iSCSI инициатора.Отличие таких сетевых контроллеров от аппаратных инициаторов iSCSI – в том,что каждый такой контроллер отображается одновременно и как сетевой, и какдисковый контроллер в интерфейсе ESX(i). Зависимые инициаторы требуют на-стройки сети такие же, как и программный инициатор, то есть создание виртуаль-ных сетевых интерфейсов VMkernel, назначение их на соответствующие физиче-ские сетевые контроллеры, настройка Discovery. Плюсы программного инициатора – для его использования можно ничего до-полнительно не приобретать или приобретать лишь дополнительные сетевые кон-троллеры. Но максимальная скорость может быть меньше, и возрастает нагрузкана процессоры сервера. В принципе, для использования iSCSI с ESX(i), кроме самой СХД с поддерж-кой iSCSI, не надо ничего – в составе ESX(i) есть программный инициатор, то естьсерверу достаточно иметь обычные сетевые контроллеры, подключенные к обыч-ным коммутаторам. Однако для использования iSCSI в производственной среде
    • 164 Системы хранения данных и vSphereобычно оправдано организовать выделенную под iSCSI инфраструктуру IP – ком-мутаторы и сетевые контроллеры серверов. ′ Плюсы аппаратного и зависимого инициаторов – потенциально большая про-изводительность, меньшая нагрузка на процессоры сервера. Минусы – его надопокупать. С точки зрения ОС (здесь – ESX(i)), аппаратный iSCSI HBA – это кон-троллер SCSI, не отличающийся от FC HBA. То, что FC HBA оборачивает SCSIв пакеты fibre channel, а iSCSI HBA – в пакеты IP, для ОС прозрачно, и она ихвоспринимает одинаково. То есть если у вас есть аппаратный инициатор, то нуж-но настроить только его – указать ему собственный IP-адрес и IP-адреса СХД(iSCSI target). Но, в отличие от FC HBA, инициатор iSCSI может быть программный. Самоедля нас главное – в ESX(i) такой программный инициатор есть. 3.5.1. Как настроить программный инициатор или аппаратный зависимый iSCSI на ESX(i) Краткий план настройки программного инициатора iSCSI таков. 1. Настраиваем вКоммутатор, включаем Jumbo Frames. (При необходимости включаем использование Jumbo Frames на физическом сетевом оборудо- вании.) Включение Jumbo Frames является не обязательным, но рекомен- дуемым. 2. Назначаем на вКоммутатор физические сетевые контроллеры, крайне же- лательно хотя бы два (из обычных соображений отказоустойчивости). Из соображений производительности их может быть и больше. Если речь идет о настройке аппаратного зависимого инициатора iSCSI, то привязывать к вКоммутатору необходимо именно те сетевые контроллеры, которые яв- ляются еще и контроллерами iSCSI. 3. Добавляем порты VMkernel по числу физических сетевых контроллеров на этом виртуальном коммутаторе. См. раздел про сеть – для задействования Jumbo Frames их придется создавать из командной строки. Контроллеров больше одного необходимо для того, чтобы задействовать механизмы mul- tipathing для программного инициатора iSCSI. 4. В настройках NIC Teaming привязываем каждый интерфейс VMkernel из п. 3 к какому-то одному физическому сетевому контроллеру. 5. Включаем VMware iSCSI Software Initiator (только для чисто программно- го инициатора). 6. Привязываем порты VMkernel к iSCSI Software Initiator (см. ниже, как). 7. Настраиваем подключение ESX(i) к системе хранения iSCSI, для этого на- страиваем Discovery и, при необходимости, аутентификацию. 8. Создаем хранилище VMFS. Теперь подробнее.
    • SAN, iSCI 165 Настройка сети для iSCSI Первое, что необходимо сделать, – это настроить сеть для работы iSCSI. Вер-нитесь на рис. 3.15 – служба инициатора iSCSI формирует пакеты IP, а в сеть онипопадают через сетевой стек VMkernel. Это значит, что нам понадобится вирту-альный сетевой контроллер VMkernel. Примерная конфигурация показана на рис. 3.16. Рис. 3.16. Необходимая настройка виртуальной сети для программного инициатора iSCSI «Примерная» потому, что на этом же вКоммутаторе могут располагаться и лю-бые другие группы портов. Потому что физических сетевых интерфейсов лучшебы использовать хотя бы два, чтобы не было единой точки отказа. Потому чтоинтерфейсов VMkernel нужно несколько, если вас интересуют балансировка на-грузки. Небольшой нюанс. Взгляните на рис. 3.17. Рис. 3.17. Пример настройки сети на ESXi. Выделены все порты VMkernel
    • 166 Системы хранения данных и vSphere Здесь вы видите пример настройки сети на ESX(i), и в этой сети есть три ин-терфейса VMkernel. Если я попытаюсь подключить к этому серверу ESX(i) хра-нилище iSCSI с IP-адресом 192.168.75.1, то через какой из этих трех интерфейсовгипервизор попытается обратиться на этот адрес? Ответ на этот вопрос прост. Ги-первизор представляет собой операционную систему (отдельную, не путать с Ser-vice Console). Эта операционная система использует три сетевые карты (в данномпримере это интерфейсы vmk0, vmk4, vmk5). Какую из них выбрать, она решаетв соответствии с таблицей маршрутизации. Очевидно, что в моем примере онавыберет vmk4, находящийся в той же подсети. Поэтому я и назвал его «VMker-nel_iSCSI», так как предполагал, что через него пойдет iSCSI-трафик. И привя-зал к его вКоммутатору сразу три физических сетевых контроллера, так как длятрафика IP-СХД рекомендуется несколько выделенных сетевых контроллеров. Для настройки маршрутизации для гипервизора существует специальная ко-манда esxcfg-route. Обратите внимание. Для серверов ESXi существует небольшая особенность – про- граммный инициатор iSCSI не будет задействовать для своей работы интерфейсы VMkernel с флажком «Management» в свойствах, так что под iSCSI следует всегда соз- давать выделенные интерфейсы VMkernel. Впрочем, даже если бы так делать было можно, это все равно было бы плохой идеей. Крайне желательно, чтобы доступ с сервера на iSCSI СХД не требовал марш-рутизатора. Однако при необходимости реализовать и такую конфигурацию воз-можно. Включение iSCSI инициатора и настройка Discovery Следующий шаг – необходимо включить службу программного инициатораiSCSI. Для этого перейдите Configuration ⇒ Storage Adapters ⇒ и выберите тотvmhba#, который находится в группе iSCSI Software Adapter ⇒ нажмите Proper-ties ⇒ кнопка Configure ⇒ установите флажок Enabled (рис. 3.18). После этого нажмите ОК. Обратите внимание на строку «iSCSI Name» на рисунке выше. Это iSCSI qual-ified names (IQN), уникальный идентификатор устройства iSCSI, аналог WWNдля Fibre Channel. Формируется он автоматически. Хотя мы можем его изменить,обычно это нам не нужно. Если вдруг изменяем – тогда в наших интересах озабо-титься его уникальностью в нашей инфраструктуре. Однако подробности об име-новании iSCSI ищите в разделе 3.9 «Адресация SCSI». Таким образом, в случае iSCSI у каждого устройства есть несколько иден-тификаторов – IP-адрес (часто несколько) и iSCSI Name вида iqn.* или другого.В случае ESX(i) IP-адрес мы задаем в свойствах интерфейса VMkernel, через ко-торый собираемся выпускать трафик iSCSI. Следующий шаг – это настройка Discovery. Сессии discovery – это часть протокола iSCSI, возвращающая список targetс системы хранения iSCSI. Discovery бывают динамическими (иногда называемыеSend Targets) и статическими.
    • SAN, iSCI 167 Рис. 3.18. Включение программного инициатора iSCSI В случае динамического мы указываем адрес системы хранения, и после dis-covery нам возвращается список LUN, доступных на ней. Найденные LUN запи-сываются на закладке Static Discovery. В случае статического discovery ESX(i) пытается обратиться к конкретномуLUN, не опрашивая систему хранения о других доступных. Для настройки того или иного метода discovery надо зайти в свойства про-граммного iSCSI HBA (Configuration ⇒ Storage Adapters) и перейти на закладкуDynamic Discovery или Static Discovery. Нажимаем кнопку Add, указываем IP-адрес системы хранения iSCSI, используемый сетевой порт и, в случае статичногоdiscovery, имя таргета. Обратите внимание. LUN, найденные через Dynamic Discovery, ESX(i) автомати- чески помещает в Static Discovery для ускорения обращения к ним при следующих включениях. Не забудьте удалить из списка Static Discovery записи о LUN, доступ к которым для ESX(i) был отменен. Далее надо настроить аутентификацию, но про нее чуть позже.
    • 168 Системы хранения данных и vSphere После нажатия ОК появится окно с сообщением о том, что после изменениянастроек HBA требуется пересканировать систему хранения, согласимся с этим.Если все было сделано правильно, выделив HBA, в нижней части окна мы увидимдоступные LUN. Теперь про аутентификацию. На стороне системы хранения нам необходимопрезентовать LUN серверу. Обычно в случае iSCSI это делается по его идентифи-катору (IQN или другому). Кроме того, ESX(i) 4 поддерживает аутентификациюпо протоколу CHAP, в том числе взаимную. Чтобы указать имя и пароль на стороне ESX(i), при задании таргета надо на-жать кнопку CHAP – см. рис. 3.19. Рис. 3.19. Настройки аутентификации CHAP Здесь настраиваем аутентификацию CHAP в соответствии с нашими требо-ваниями. Если там же нажать кнопку Advanced, то попадем в окно указания расширен-ных настроек iSCSI (рис. 3.20).
    • SAN, iSCI 169 Рис. 3.20. Расширенные настройки для iSCSI Здесь следует что-то изменять, лишь если вы хорошо понимаете, что делае-те. Обычно поменять какие-то из этих настроек советует поддержка VMware вслучае возникновения каких-либо проблем. Для справки см. http://www.vm4.ru/2010/08/vsphere-41-iscsi-advanced-settings.html. 3.5.2. iSCSI Multipathing А теперь пару слов про iSCSI multipathing для программного инициатора. Во-первых, у одной системы хранения iSCSI может быть (и обычно бывает)несколько контроллеров, каждый со своим IP-адресом. Надо добавить их все, иESX(i) сам разберется, что эти несколько таргетов показывают на самом деле наодни и те же LUN. Во-вторых, ESX(i) может использовать multipathing между своими контрол-лерами. А раз речь идет про Ethernet (поверх которого передается iSCSI), этиконтроллеры будут сетевыми. Но есть один нюанс. Программный инициатор iSCSI – это служба. Для доступа в сеть она ис-пользует виртуальные сетевые интерфейсы VMkernel. Эти интерфейсы под-
    • 170 Системы хранения данных и vSphereключены к вКоммутаторам, а к тем подключены несколько физических сетевыхконтроллеров. Рассмотрим два варианта: 1. На вКоммутаторе несколько каналов во внешнюю сеть, но только один ин- терфейс VMkernel. 2. На вКоммутаторе несколько каналов во внешнюю сеть и несколько интер- фейсов VMkernel (рис. 3.21). Рис. 3.21. Настройки сети для multipathing в случае программного инициатора iSCSI В первом случае multipathing может быть обеспечен только на уровне вирту-ального коммутатора. Но в силу логики работы алгоритмов балансировки нагруз-ки далеко не всегда трафик iSCSI будет балансироваться оптимальным образом.Даже если вКоммутатор настроен на балансировку нагрузки по хэшу IP, то черезразные физические сетевые контроллеры будет пересылаться трафик к разнымIP-адресам системы хранения. Более тонкого разделения проводиться не будет. А вот во втором случае трафик iSCSI наверняка сможет задействовать не-сколько каналов во внешнюю сеть за счет того, что балансировать нагрузку смо-жет storage стек VMkernel между интерфейсами VMkernel. Последним шагом бу-дет ассоциировать каждый интерфейс VMkernel с каким-то одним физическимсетевым интерфейсом – чтобы балансировка между виртуальными интерфейсамиVMkernel означала и балансировку между физическими сетевыми контроллера-ми. В таком случае через разные контроллеры могут быть установлены соедине-ния при обращении на разные LUN, не только на разные контроллеры СХД. Для организации такой конфигурации multipathing нам необходимо на вКом-мутатор назначить несколько физических интерфейсов и создать на нем же столь-ко же портов VMkernel (напомню, что на рис. 3.21 приведен пример описанноймной конфигурации). Затем следует сопоставить их один к одному, то есть длякаждого порта VMkernel указать свой vmnic как единственный активный. Для осуществления этого зайдите в свойства виртуального коммутатора, вы-берите группу портов с первым из интерфейсов VMkernel и нажмите Edit. Заклад-ка NIC Teaming ⇒ флажок Override vSwitch failover order ⇒ все vmnic, кромеодного выбранного, перенесите в группу Unused Adapters (рис. 3.22). Повторите этот шаг для каждого интерфейса VMkernel, выбирая каждый разследующий vmnic.
    • SAN, iSCI 171 Рис. 3.22. Настройка NIC Teaming для портов VMkernel, используемых инициатором iSCSI Теперь необходимо выполнить настройку из командной строки через vShepreCLI:esxcli swiscsi nic add -n <port_name> -d <vmhba> Повторите для каждого интерфейса vmk#. Эта настройка привязывает интерфейс VMkernel к программному инициато-ру iSCSI. После завершения настройки подключения к системе хранения iSCSI выувидите несколько путей к каждому LUN. Те пути, что отличаются каналом (C#),идут через разные vmk# (и, как следствие, через разные vmnic). Для моего примера это будут две команды:
    • 172 Системы хранения данных и vSphereesxcli swiscsi nic add -n vmk1 -d vmhba33esxcli swiscsi nic add -n vmk3 -d vmhba33 Обратите внимание. Эта команда не отработает, если есть используемые в дан- ный момент пути через эти интерфейсы VMkernel. Таким образом, лучшего все эти настройки делать перед тем, как настраивать Discovery и подключаться к iSCSI СХД. Проверить, какие vmknic назначены для iSCSI-инициатора, можно командойesxcli swiscsi nic list --adapter vmhba33 Следующий нюанс – система хранения iSCSI может по-разному адресоватьLUN. Вспомним физический адрес LUN, путь к нему вида vmhba#:C#:T#:L#.Какие-то системы хранения могут презентованные LUN показывать как разныеLUN одного таргета или как разные LUN разных таргетов. То есть мы увидим путивида: vmhba33:C0:T0:L0; vmhba33:C0:T0:L1; vmhba33:C0:T0:L2. Или: vmhba33:C0:T0:L0; vmhba33:C0:T1:L0; vmhba33:C0:T2:L0. Программный iSCSI-инициатор ESX(i) устанавливает одно соединение натаргет. Таким образом, в первом случае, когда сервер работает с одним таргетом итремя LUN на нем, весь трафик iSCSI пойдет через один внешний интерфейс. Вовтором случае, когда три LUN подключены через три таргета, – через несколько.С точки зрения производительности, второй вариант может быть интереснее. Последний шаг – задать настройку политики multipathing. C модулем multipa-thing по умолчанию вам доступны политики Fixed, Most Recently Used и Round-Robin (их описание доступно в разделе 3.4.1). Обязательно читайте документациювашей системы хранения и следуйте ее рекомендациям. 3.6. VMFS, Virtual Machine File System Дисковые ресурсы, к которым осуществляется блочный доступ, – а это локаль-ные диски (или другие DAS) и LUN на системах хранения FC и iSCSI – ESX(i)может отформатировать в файловую систему VMFS. Это проприетарная, закры-тая файловая система от VMware, обладающая полезным под нужды виртуализа-ции функционалом: кластерность. VMFS является кластерной файловой системой. Это озна- чает, что с отформатированным в эту файловую систему разделом могут работать одновременно несколько серверов. VMFS обладает системой бло- кировок, которая обеспечивает целостность данных;
    • VMFS, Virtual Machine File System 173 поддержка файлов больших размеров. В разделе VMFS могут быть распо- ложены файлы размером до 2 Тб. Это, кстати, ограничение на размер одно- го диска ВМ – не больше 2 Тб минус 512 байт; VMFS является журналируемой файловой системой; минимальные накладные расходы – при размещении файла виртуального диска в разделе VMFS какого-то LUN мы получаем производительность, практически идентичную тому, как если бы этот же LUN отдавали ВМ как RDM, напрямую. Создать раздел VMFS достаточно просто. Если у нас есть видимые ESX(i)-диски (LUN) и на каком-то из них мы хотим создать VMFS, то для этого идемConfiguration ⇒ Storage ⇒ Add Storage. Запустится мастер. По шагам: Мы хотим отформатировать в VMFS какой-то диск/LUN, а не подмонтиро-вать NFS. Оставляем вариант «Disk/LUN» (рис. 3.23). Затем выбираем, на каком из LUN мы хотим создать VMFS. Нам будут пред-ложены только те, на которых раздела VMFS еще не создано, потому что на одномLUN мы можем создать только один раздел VMFS (рис. 3.24). Рис. 3.23. Добавление хранилища VMFS
    • 174 Системы хранения данных и vSphere Рис. 3.24. Выбор LUN для создания раздела VMFS Обратите внимание: на этом этапе мы можем попасть в крупные неприятно-сти, потому что в пустых незадействованных LUN в этом списке могут находить-ся LUN’ы с данными, но подключенные как RDM. Если мы выберем такой LUNи создадим на нем VMFS, то данные гостевой ОС будут уничтожены. Поэтомуочень важно наверняка знать адрес LUN, который мы создали под VMFS. Иден-тификатором может служить номер LUN в первую очередь. Путь к LUN – так какиз него можно понять, через какой контроллер ESX(i) этот LUN видит. Наконец,косвенным идентификатором может служить размер. В общем, будьте вниматель-ны. К счастью, для каждого LUN мы можем указать произвольный, легкий в вос-приятии идентификатор – см. раздел 3.9 «Адресация SCSI». На следующем шаге нам покажут информацию о выбранном диске. Затем предложат ввести «Datastore Name», имя хранилища. По сути, это меткатома, которую мы затем будем видеть в интерфейсе vSphere Client. В ваших ин-тересах сделать ее максимально информативной, это опять же сведет к минимумувероятность ошибок в будущем. Имеет смысл указать тип СХД, задачу, если LUNвыделен под конкретные цели. Например, «fc_lun_db_ production». В этом именитакже имеет смысл избегать пробелов и спецсимволов.
    • VMFS, Virtual Machine File System 175 Рис. 3.25. Выбор размера блока для создаваемого раздела VMFS Шаг Formatting – самый интересный, см. рис. 3.25. Здесь мы указываем размер блока создаваемого VMFS, от этого зависит мак-симальный размер одного файла на этом разделе. По умолчанию предлагаетсяразмер блока в 1 Мб. При таком блоке максимальный размер файла может быть256 Гб. Это означает, что в таком разделе VMFS не получится расположить вирту-альный диск для ВМ (файл vmdk) размером, например, 300 Гб. Рекомендация простая – выбирайте такой размер блока, чтобы диски вашихВМ помещались. Какого размера будут диски ваших ВМ? А это зависит от задачи нагрузки, в общем случае сказать нельзя, это вопрос планирования. Некоторыесоображения приведены в первой главе в разделе, посвященном сайзингу. С появлением ESX(i) версии 4.1 и функции V AAI (см. раздел 3.10) для васможет быть важно все или некоторые разделы VMFS создать с одинаковым раз-мером блока – чтобы работал механизм V AAI. Также на этом шаге мастера вы можете указать размер создаваемого раздела –занимает ли он LUN целиком или только его часть. Думаю, вы всегда будете остав-лять вариант по умолчанию – и VMFS будет занимать все место на LUN. Причинпоступать по-другому я не вижу.
    • 176 Системы хранения данных и vSphere Обратите внимание. Несмотря на размер блока от мегабайта, при операциях чте- ния-записи VMFS оперирует «субблоками» размером в 64 Кб. Если вам нужно удалить раздел VMFS, то в этом поможет ссылка Remove,расположенная рядом с описанной выше Add Storage. Нажатие Remove для раз-дела VMFS именно удалит раздел и все данные на нем. Если необходимо не уда-лять раздел, а сделать его недоступным конкретному серверу, то это делается с по-мощью операции LUN Masking, выполняемой на системе хранения или на сервереESX(i). Технические особенности VMFS Если посмотреть свойства только что созданного хранилища VMFS, то мыувидим, что несколько сотен мегабайт на нем сразу заняты. Заняты они под такназываемые метаданные, «metadata», описание раздела. Сами файлы метаданных расположены в корне раздела: .fdc.sf – file descriptor system file; .sbc.sf – sub-block system file; .fbb.sf – file block system file; .pbc.sf – pointer block system file; .vh.sf – volume header system file. В этих метаданных хранится информация о самом разделе: Block Size – размер блока; Number of Extents – количество расширений раздела VMFS (extent), то есть на какие еще LUN распространен этот том VMFS; Volume Capacity – размер раздела; VMFS Version – версия VMFS; Volume Label – метка раздела VMFS; VMFS UUID – уникальный идентификатор раздела VMFS. Просмотреть эту информацию можно командойvmkfstools -P -h /vmfs/volumes/<метка тома VMFS> Обратите внимание. Метаданные раздела VMFS занимают тем больше, чем боль- ше сам раздел. Как максимум метаданные могут занимать до 1200 Мб на разделе. Еще в метаданных хранится информация о файлах на разделе. О том, что онисуществуют, о том, какие блоки под них выделены, о том, с какого сервера они от-крыты. Важный момент здесь в следующем. VMFS предлагает совместный доступ с нескольких серверов одновременноза счет блокировки на уровне файлов. Когда сервер запускает какую-то ВМ, онблокирует лишь принадлежащие ей файлы. Информация об их блокировке запи-сывается в метаданные.
    • VMFS, Virtual Machine File System 177 Вот у вас есть две ВМ, их файлы расположены на одном хранилище VMFS,и они работают на разных серверах. В этом случае производительность данногоLUN просто делится между этими ВМ, с минимальными накладными расходами.Эти ВМ одновременно читают и пишут данные на одном и том же VMFS, каждаяв свои файлы. Но если необходимо внести изменения в метаданные, то для внесения измене-ний LUN отдается в монопольное пользование серверу, который вносит изменения.Делается это с помощью команды Reservation (блокировка) протокола SCSI 2. SCSI Reservation происходит при: включении и выключении ВМ – потому что в метаданных надо прописать, что файлы этой ВМ теперь открыты или закрыты; создании файлов. Это такие операции, как создание виртуальной машины или шаблона, клонирование ВМ, Storage VMotion и миграция выключен- ной виртуальной машины на другое хранилище, добавление диска ВМ, соз- дание снимков состояния; удалении файла; смене владельца файла; установке метки времени последнего обращения/изменения; увеличении раздела VMFS; изменении размера файлов – а это происходит регулярно при работе ВМ со снимков состояния и если ее диски (файлы vmdk) находятся в формате thin. Файлы изменений (*-delta.vmdk) снимков состояния растут блоками по16 Мб. Тонкие диски увеличиваются по одному блоку VMFS. Мы записали внутрьВМ еще сколько-то мегабайт, файл vmdk стало необходимо увеличить, для ука-зания нового размера файла в метаданных раздела произошел SCSI reservation.Затем vmdk-файл еще увеличился, SCSI reservation повторился. И так далее. И что может получиться: на одном VMFS расположен десяток ВМ, все работа-ют на разных серверах, у всех снимки состояния. И каждый раз, когда у какой-тоВМ надо увеличить размер файла-дельты, происходит SCSI reservation, и какое-томаленькое время (обычно ~10 миллисекунд) девять других серверов с этим LUNне работают, потому что десятый вносит изменения в метаданные. Разово эта опе-рация вообще нестрашна и нормальна. По данным VMware, и при средней нагруз-ке негативный эффект на производительность от этих блокировок нулевой. Нов граничных случаях, когда на одном хранилище много ВМ, у всех диски растущиеи эти ВМ работают на многих разных серверах, мы можем недополучить частьпроизводительности LUN. Вывод: лучше стараться избегать постоянной работы при существующих сним-ках состояния (snapshot) для производственных ВМ, а если для каких-то из нихэто необходимо – стараться держать их на отдельных LUN от тех производствен-ных ВМ, которым особенно важна производительность дисковой подсистемы. Отследить потери производительности из-за регулярных блокировок мы мо-жем, проанализировав соответствующий журнал. Это файл /var/log/vmkernel, гдемы можем отследить произошедший «reservation conflict»:
    • 178 Системы хранения данных и vSphereApr 24 15:59:53 esx35-1 vmkernel: 5:14:57:01.939 cpu0:1083)StorageMonitor: 196:vmhba1:0:3:0 status = 24/0 0x0 0x0 0x0Apr 24 15:59:53 esx35-1 vmkernel: 5:14:57:01.939 cpu0:1041)SCSI: vm 1041: 109: Sync CRat 64Apr 24 15:59:56 esx35-1 vmkernel: 5:14:57:04.982 cpu0:1151)StorageMonitor: 196:vmhba1:0:3:0 status = 24/0 0x0 0x0 0x0Apr 24 15:59:56 esx35-1 vmkernel: 5:14:57:04.982 cpu3:1041)SCSI: vm 1041: 109: Sync CRat 16Apr 24 15:59:56 mel-esx-02 vmkernel: 5:14:57:05.050 cpu0:1161)StorageMonitor: 196:vmhba1:0:3:0 status = 24/0 0x0 0x0 0x0Apr 24 15:59:57 esx35-1 vmkernel: 5:14:57:06.047 cpu3:1041)SCSI: vm 1041: 109: Sync CRat 0Apr 24 15:59:57 esx35-1 vmkernel: 5:14:57:06.047 cpu3:1041)WARNING: SCSI: 119: FailingI/O due to too many reservation conflicts Если вы столкнулись с ситуацией, когда блокировки оказывают негативноевлияние на работу дисковой подсистемы, можно попробовать следующую конфи-гурацию: Сделать расширение раздела (extent) из нескольких LUN, где первый LUNбудет небольшим, порядка 2 Гб. Тогда на нем не будет файлов-дисков ВМ (невлезут), а останутся только метаданные. И блокировки SCSI не будут оказыватьвлияния на скорость работы виртуальных машин на прочих LUN. Также на VMFS есть так называемый «Heartbeat Region». В этой области сер-веры периодически обновляют записи с целью сообщить о своей работоспособно-сти. Если сервер вышел из строя или потерял связь с хранилищем и своевременноне обновил свою запись, блокировки файлов этим сервером считаются недействи-тельными. 3.6.1. Увеличение размера хранилища VMFS. Grow и Extent При создании раздела VMFS мы указываем его размер. Если обстоятельствасложились неудачно, мы можем оказаться в ситуации, когда места на этом VMFSхватать перестанет. Для преодоления данной проблемы есть два пути – использо-вать операцию Grow или Extent. Grow – это когда у нас на том же LUN появилось еще свободное место, тогдамы увеличиваем размер раздела VMFS за счет него. Если наша система храненияне позволяет нам увеличивать размер LUN, тогда Grow нам не пригодится. Extent – это когда мы берем раздел VMFS и «натягиваем» его на еще одинLUN, где VMFS нет. VMFS Grow Если мы добавили место на LUN, чтобы его задействовать под VMFS, то идитеConfiguration ⇒ Storage ⇒ раздел VMFS с этого LUN ⇒ Properties ⇒ кнопка In-crease. Нам покажут список LUN (рис. 3.26), и в этом списке мы должны увидеть
    • VMFS, Virtual Machine File System 179 Рис. 3.26. Увеличение VMFS за счет свободного места того же LUNтот из них, VMFS на котором хотим увеличить. В столбце Expandable для негодолжно быть «Yes» – это значит, на нем есть не занятое под VMFS место. Выбираем его, Next, Next – и все. VMFS Extent Один раздел VMFS может существовать сразу на нескольких LUN. Вам можетпотребоваться такая конфигурация: когда вам надо увеличить размер раздела VMFS, а увеличение LUN (и по- следующий grow раздела) не возможно. Например, если вы не имеете до- ступа к управлению SAN. А ваши администраторы систем хранения не мо- гут или не намерены увеличивать ранее созданные LUN; когда вам нужен один раздел VMFS размером больше 2 Тб. Если VMFS размещен на одном LUN, его максимальный размер 2 Тб минус 512 байт. А если такой VMFS расширить на второй LUN, тех же 2 Тб размером, то увидите, что ваш логически единый раздел VMFS стал размером 4 Тб. И так далее – один VMFS может быть распространен на до 32 LUN. Однако даже если у вас есть VMFS размером 64 Тб, максимальный размер одного файла (то есть диска ВМ) продолжает быть ограниченным 2 Тб. Для добавления в существующий том VMFS еще одного LUN следует пройтиConfiguration ⇒ Storage ⇒ раздел VMFS, который хотим увеличить ⇒ Properties⇒ кнопка Increase. Нам будет показан список LUN, которые можно задействоватьдля увеличения выбранного раздела VMFS. В этом списке будут те LUN, на ко-торых нет VMFS. Обратите внимание: кроме пустых, среди них могут быть LUN,задействованные как RDM, а то и вообще LUN посторонних серверов при непра-вильном зонировании или маскировке. То есть мы можем расширить том VMFSна LUN с данными, что приведет к их уничтожению. Будьте внимательны при вы-
    • 180 Системы хранения данных и vSphereборе. После завершения мастера по выбору LUN для расширения размер разделаVMFS будет увеличен (рис. 3.27). Рис. 3.27. До и после выполнения extent Обратите внимание: операция extent необратима. Если вы расширили VMFSна какой-то LUN, освободить этот LUN невозможно. Только если удалить весьрасширенный VMFS целиком. Как вы понимаете, это потребует перемещенияфайлов ВМ на другие хранилища, что не всегда приемлемо. Недостатком extent, по сравнению с grow, является усложнение администри-рования SAN. В случае grow у нас один VMFS занимает один LUN. 10 VMFS за-нимают 10 LUN. А в случае extent 10 VMFS могут занимать большее количествоLUN. Банально, количество LUN больше – и повышается вероятность ошибкиадминистратора SAN. Даже если у нас всего 10 LUN, но все они принадлежат одному VMFS, всеравно вероятность ошибки и потери данных всего VMFS выше. Все метаданные объединенного раздела VMFS хранятся на первом LUN. Еслипо ошибке или из-за сбоя выходит из строя именно первый LUN одного распре-
    • VMFS, Virtual Machine File System 181деленного VMFS, то мы теряем все данные на всем томе VMFS. Если выходит изстроя любой LUN, кроме первого, мы теряем данные только с него. Впрочем, вероятность отказа именно LUN (а не отдельного диска или RAID-группы) мне видится крайне низкой – исключая человеческий фактор. Обратите внимание. ESX(i) 4 поддерживает увеличение VMFS, RDM и vmdk. Умень- шить VMFS невозможно. Уменьшить vmdk можно при помощи VMware Converter. ESX(i) 4 поддерживает уменьшение RDM, так как оно обрабатывается лишь госте- вой ОС. 3.6.2. Доступ к клонированному разделу VMFS, или к разделу VMFS с изменившимся номером LUN В метаданных VMFS хранятся уникальный идентификатор (UUID, universallyunique identifier) раздела VMFS и номер LUN, на котором он был создан. Еслив силу каких-то причин изменился номер LUN (или имя iqn.*, для iSCSI), то ESXперестанет работать с этим VMFS – в списке Configuration ⇒ Storage вы его неувидите. Ситуация, при которой номер LUN отличается от номера, записанного наразделе VMFS, может быть штатной, когда: ESX(i) обращается к клону раздела VMFS. Обычно такое происходит, ког- да настроена репликация LUN или вы клонировали LUN вручную; вы подключили к ESX(i) снапшот LUN (здесь имеется в виду функция си- стемы хранения «snapshot»). То есть, оказавшись в такой ситуации, ESX(i) предполагает, что видит репликуLUN. А раз это реплика, то записывать что-то на нее означает разрушить целост-ность реплики. Если же вы оказались в такой ситуации незапланированно, например: изменились какие-то настройки на стороне системы хранения и у какого-то LUN поменялся номер; или у вас произошел какой-то программный сбой, установленный на диски ESX(i) не загружается и вы загружаете сервер с флэшки с ESXi. Для этого ESXi номер LUN может поменяться. Так вот, в такой ситуации обратитесь к мастеру создания VMFS – Configura-tion ⇒ Storage ⇒ Add Storage. Вы должны увидеть проблемный LUN и в столбцеVMFS Label – метку существующего (но не отображаемого) на нем раздела VMFS(рис. 3.28). Затем вы увидите вопрос «как поступить с этим разделом VMFS?» (рис. 3.29). Варианты следующие: Keep the existing signature – подключить VMFS как есть, без изменений. Используется в случае, когда вы хотите подключить реплику LUN и полу- чить к ней доступ. Например, в случае сбоя основной площадки запустить
    • 182 Системы хранения данных и vSphere Рис. 3.28. Восстановление доступа к разделу VMFS на LUN с изменившимся номером виртуальные машины на резервной площадке, из реплики. Изменений метаданных не происходит. Однако не получится подключить к ESX(i) и исходный том, и его реплику одновременно, потому что UUID у них совпа- дает. В таком случае выбор данного варианта будет недоступен. Однажды подключенные таким образом разделы VMFS в дальнейшем будут подклю- чаться к серверам и после их перезагрузок; Assign a new signature – сгенерировать и записать новый UUID для этого VMFS. Все ВМ и шаблоны с этого хранилища придется заново добавить в иерархию vCenter (ESX(i)); Format the disk – заново создать VMFS на этом LUN. Уничтожит все име- ющиеся данные. Обратите внимание. Из командной строки эти операции возможны с помощью ко- манды esxcfg-volumes. Вам пригодятся ключики –l для просмотра информации о разделах и –m или –M для их подмонтирования. При использовании –M раздел VMFS останется подмонтированным и после перезагрузки.
    • RDM, Raw Device Mapping 183 Рис. 3.29. Восстановление доступа к разделу VMFS на LUN с изменившимся номером 3.7. RDM, Raw Device Mapping RDM – это альтернатива VMFS. В случае хранилища VMFS мы создаем надиске/LUN раздел, форматируем его в VMFS и храним там файлы ВМ. Обыч-но – многих ВМ на одном VMFS. Однако мы можем какой-то LUN выделитьнапрямую одной ВМ. И даже не одной, например для диска с данными кластераМайкрософт может и должен использоваться как раз RDM, подключенный к двумвиртуальным машинам сразу. При таком подключении LUN гипервизор будет пропускать SCSI командыгостевой ОС прямо на него. Таким образом, на LUN, подключенном как RDM,будет создана файловая система гостевой ОС (NTFS, к примеру). При создании RDM создается файл vmdk, который выполняет роль ссылкидля открытия, – фактически же чтение и запись идут на сам LUN. См. рис. 3.30. Размер этого файла vmdk отображается равным объему RDM LUN (объемуLUN 14 в моем примере), однако на самом деле он занимает 1–8 Мб (в зависимо-сти от размера блока VMFS).
    • 184 Системы хранения данных и vSphere Рис. 3.30. Иллюстрация подключения RDM Источник: VMware RDM вам интересен в случае, если: происходит миграция физической инфраструктуры на виртуальную. Пе- реносимый физический сервер использует LUN для хранения своих дан- ных. Мы можем не копировать данные с этого LUN внутрь файла vmdk на каком-то VMFS, а прямо этот LUN подключить к перенесенному в ВМ серверу как RDM; вы хотите поднять кластер Майкрософт с переходом по отказу (MSCS/ MFC), хотя бы одним из узлов которого будет ВМ. В таком случае кворум- ным диском и диском с общими данными должен выступать RDM; вы хотите использовать механизм снапшотов или какие-то другие функ- ции на уровне системы хранения для данных виртуальных машин. Напри- мер, мы можем средствами системы хранения создать снапшот LUN и этот снапшот подключить к серверу резервного копирования. В случае VMFS + vmdk такая схема, скорее всего, не заработает, потому что сервер резервного копирования не сможет забрать данные с проприетарной файловой систе- мы VMFS. А если этот LUN подключен как RDM к виртуальной машине, то файловую систему на нем создает гостевая ОС, и эта файловая система может быть знакома серверу резервного копирования; из политических соображений – хранение каких-то данных в проприетар- ном формате (VMFS + vmdk) противоречит корпоративным политикам или предписаниям регулирующих органов. Однако использование RDM не дает заметных изменений в скорости работыс дисковой подсистемой. По данным VMware, разница в скорости доступа к одно-му и тому же LUN как к RDM или к файлу vmdk на нем различается на проценты,и иногда VMFS + vmdk даже быстрее. Чтобы добавить RDM к ВМ: зайдите в свойства виртуальной машины, на закладе Hardware нажмите Add. Вам нужно добавить Hard Disk;
    • RDM, Raw Device Mapping 185 Device Type – выберите Raw Device Mapping; Select a Disk – выберите LUN из списка. В этом списке только те LUN, на которых нет VMFS. Важно! Среди них могут быть уже задействованные как RDM с другими ВМ, обращайте внимание на адреса и номера LUN во избежание ошибок и потери данных; Select Datastore – здесь вы выбираете, на каком хранилище VMFS будет располагаться файл виртуального диска (vmdk), являющийся ссылкой на этот LUN. Скорее всего, вариант по умолчанию вас устроит; Compatibility Mode – тип RDM-подключения, о нем чуть ниже; Advanced Options – здесь мы, как и для файлов виртуальных дисков, указы- ваем адрес SCSI добавляемого диска с точки зрения ВМ. SCSI (0:1) означает, что диск будет подключен на первый SCSI ID контроллера 0. А если мы вы- берем SCSI (1:0), то диск будет подключен как ID 0 контроллера 1. В частно- сти, второй вариант означает, что в ВМ будет добавлен и второй контроллер SCSI – это часто нам надо для MSCS/MFC (первый SCSI-контроллер с но- мером 0 обычно уже существует, если добавляемый RDM – не первый диск этой ВМ). Если RDM Virtual, то мы можем поставить флажок Independent. Если он стоит, то к этому диску ВМ не будут создаваться снимки состояния (snapshot). Дополнительные настройки в режиме Independent: • Persistent означает монолитный диск, к которому не применяются снимки состояния (snapshot). Все изменения сразу пишутся на диск; • Nonpersistent означает, что при включении ВМ именно для этого ее диска создается файл дельты, в который записываются все изменения. После выключения ВМ эта дельта отбрасывается. То есть диск в режиме nonpersistent автоматически возвращается в исходное состояние после выключения ВМ. RDM бывает двух типов: Physical означает, что гипервизор подавляющее большинство команд SCSI пропускает до LUN без изменений; Virtual разрешает перехватывать и изменять команды SCSI. С точки зрения использования, Virtual RDM не препятствует снятию снимковсостояния (средствами ESX(i)) и позволяет клонировать и создавать шаблон изВМ. То есть позволяет RDM LUN использовать так же, как файл виртуальногодиска. Физические характеристики диска (LUN) будут скрыты. Physical RDM дает прямой доступ к LUN. Пригодится для кластера MSCS/MFC в варианте cluster-across-boxes и physical-to-virtual. Однако если внутри ВМу вас будет ПО, которому требуются прямой доступ на диск и работа с физически-ми характеристиками системы хранения, physical RDM – ваш выбор. Выбирайте Virtual, если задача, под которую создается RDM, явно не требуетиспользования physical RDM. Если к ВМ подключен RDM, то с ней можно осуществлять большинство опе-раций типа VMotion, Storage VMotion и др. Также для VMotion необходимо, что-бы отдаваемый как RDM LUN был виден всем серверам (виден с точки зренияzoning и masking). Невозможно как RDM подключить раздел – только LUN целиком.
    • 186 Системы хранения данных и vSphere Управлять путями к RDM LUN можно точно так же, как к LUN с VMFS. Толь-ко доступ к этим настройкам осуществляется из другого места – зайдите в свой-ства ВМ, выделите ее диск RDM и нажмите кнопку Manage Path. Иногда ESX(i) не позволяет подключить LUN как RDM. Обычно это проис-ходит, когда LUN подключен к локальному контроллеру. Тогда может выручитькомандная строкаvmkfstools -r /vmfs/devices/disks/naa.5xxxxxxxxxxx VM1_rdm.vmdk С помощью этой команды вы создадите файл-vmdk с именем VM1_rdm.vmdk, который будет являться ссылкой на LUN/диск с идентификаторомnaa.5xxxxxxxxxxx. Затем следует подключить этот файл-vmdk к виртуальной ма-шине через Add HDD ⇒ Use Existing vmdk. Идентификатор устройства (вида naa., eui., vpx.) можно посмотреть через кли-ент vSphere: Configuration ⇒ Storage Adapters ⇒ выбираем нужный контроллер⇒ в нижней части экрана смотрим на доступные через него диски. Обратите внимание. Подключенный к виртуальной машине RDM LUN не является препятствием для VMotion. Однако если у виртуальной машины по умолчанию из- менено значение настройки SCSI Bus Sharing (это настройка виртуального контрол- лера SCSI), то тогда VMotion для нее будет невозможен. RDM LUN подключается к контроллеру SCSI с таким значением настройки SCSI Bus Sharing, если виртуальная машина является узлом кластера Майкрософт и узлы этого кластера запущены на разных физических серверах. 3.8. NPIV NPIV – это стандарт, описывающий, как один порт FC HBA может регистри-ровать несколько WWN на коммутаторах FC. ESX(i) поддерживает NPIV, чтоозначает возможность сгенерировать для каждой ВМ уникальный WWN. Теоретически эта функция пригодится нам для: анализа нагрузки на SAN со стороны отдельной ВМ, чтобы отделить тра- фик одной ВМ от всего остального по ее уникальному WWN; осуществления зонирования и презентования LUN для отдельных ВМ; предоставления определенного качества обслуживания для отдельных ВМ; улучшения производительности для отдельных виртуальных машин путем индивидуальной настройки кеширования на уровне СХД. На практике же я вижу данную функцию малоиспользуемой. Причин томунесколько: уникальным WWN помечается только трафик к RDM LUN, который так и так презентован одной (за исключением кластерных конфигураций) ВМ; эти LUN все равно должны быть доступны (с точки зрения зонирования и презентования) каждому серверу ESX(i), где использующая LUN вирту- альная машина может оказаться; для представления оговоренного качества обслуживания появилась эф- фективная и простая в использовании функция SIOC (доступна не для всех лицензий vSphere);
    • NPIV 187 для виртуальной машины от включения NPIV не меняется ничего. Как ВМ работала с локальным SCSI-контроллером, так и продолжает. NPIV – это указание гипервизору, какой WWN подставлять в соответствующие обра- щения на СХД. Однако два применения NPIV мне кажутся более оправданными: если SIOC мы не можем использовать (например потому что наша лицен- зия этого не позволяет), то некоторые FC HBA позволят нам указать при- оритет для трафика с тем или иным WWN. Таким образом, мы можем при- оритезировать трафик некоторых виртуальных машин; если мы используем RDM, то без настроенного NPIV для ВМ с RDM нам сложно массово сопоставить виртуальные машины и прокинутые как RDM LUN с СХД. Чтобы ESX(i) позволил настраивать NPIV для виртуальных машин, необхо-димо, чтобы HBA и коммутаторы FC поддерживали NPIV. Сама настройка осуществляется в свойствах конкретной ВМ, на вкладке Op-tions (рис. 3.31). Если для ВМ не указан свой уникальный WWN, ее обращения кRDM LUN исходят от WWN сервера. Рис. 3.31. Настройка NPIV
    • 188 Системы хранения данных и vSphere ВМ с включенным NPIV можно мигрировать с помощью VMotion, но нельзяс помощью Storage VMotion. Есть еще некоторые мелкие нюансы, но их имеет смысл уточнять уже в доку-менте Fibre Channel SAN Configuration Guide. 3.9. Адресация SCSI Для каждого LUN существуют несколько идентификаторов. Увидеть их мож-но, например, пройдя Configuration ⇒ Storage ⇒ кнопка Devices. Вы увидите несколько столбцов с идентификаторами LUN: Name – это имя, сгенерированное для LUN самим ESX(i). Для удобства его можно поменять на произвольное; Identifier – это имя LUN, сообщаемое системой хранения. Обычно одного из следующих форматов: • naa – Network Addressing Authority id, формат именования SCSI- устройств. Таким именем обычно представляются FibreChannel-устрой- ства. Такое имя всегда начинается со строки naa.; • t10 – еще один стандарт именования, некоторые системы хранения ис- пользуют его. Такое имя всегда начинается со строки t10.; • iqn – для iSCSI используются имена стандартов iqn. В отличие от naa и t10, идентификатор IQN не обязан быть уникальным глобально (naa и t10 уникальны глобально, как MAC-адреса), однако, однажды настроен- ное на системе хранения iSCSI, это имя не должно меняться; • eui – для iSCSI может использоваться имя стандарта eui. Как и naa с t10, идентификатор eui уникален глобально; • mpx – для тех устройств, которые не представились именем по одному из стандартов naa/t10/iqn/eui, ESX(i) дает имя mpx (от VMware mul- tipath X). Эти имена не являются уникальными глобально, и они могут меняться после перезагрузок. Обычно такие имена присваиваются ло- кальным устройствам, чаще CD-ROM. Runtime name – активный путь к LUN вида vmhba#:C#:T#:L#. Здесь: • vmhba# – физически дисковый контроллер сервера; • C# – номер канала. Программный iSCSI инициатор использует разные номера каналов для отображения разных путей к LUN; • T# – номер SCSI target. Номер таргета определяется сервером и может поменяться в случае изменений в настройках видимости таргетов серве- ром. Один таргет для разных ESX(i) может показываться под разными номерами; • L# – номер LUN. Сообщается системой хранения. Знание имени LUN пригодится вам для каких-либо настроек, на стороне СХДили в командной строке сервера ESX(i). Найти эти идентификаторы можно в графическом интерфейсе и в команднойстроке. В графическом интерфейсе пройдите на закладку Storage Views для сервера ивыберите в выпадающем меню Show all SCSI Volumes (LUNs) (рис. 3.32).
    • Адресация SCSI 189 Рис. 3.32. Закладка Storage Views Из командной строки можно выполнить командуls -l /vmfs/devices/disks/и увидеть диски, доступные с этого сервера (рис. 3.33). Рис. 3.33. Данные о дисках, полученные из командной строки
    • 190 Системы хранения данных и vSphere Также если перейти в Configuration ⇒ Storage ⇒ и в контекстном меню хра-нилища выбрать Copy to Clipboard, то в буфер обмена скопируется информацияоб этом разделе. Это простой способ связать имя VMFS и идентификатор (типаnaa) LUN. Однако есть способ упростить идентификацию LUN. Пройдите Configuration⇒ Storage Adapters ⇒ выделите контроллер ⇒ в нижней части окна отобразятсяLUN. Если кликнуть два раза в столбце Name, то можно будет задать произволь-ное имя (рис. 3.34). Рис. 3.34. Указание произвольного имени для LUN Теперь это имя будет фигурировать в таких мастерах, как: создание хранилища VMFS; Extent или grow для хранилища VMFS; подключение LUN к ВМ как RDM. Например, см. рис. 3.35.
    • vSphere API for Array Integration, VAAI. Интеграция и делегирование 191 Рис. 3.35. Мастер добавления RDM к виртуальной машине Теперь не ошибиться при выборе диска в подобных операциях намного проще. 3.10. vSphere API for Array Integration, VAAI. Интеграция и делегирование некоторых операций системам хранения данных В ESX(i) версии 4.1 VMware реализовала поддержку так называемых vSphereAPI for Array Integration, программных интерфейсов для интеграции с системамихранения. Суть этой технологии – в том, что если ваши серверы работают с систе-мой хранения, поддерживающей этот интерфейс, то некоторые операции серверымогут не выполнять сами, а передать работу на СХД.
    • 192 Системы хранения данных и vSphere Такими атомарными операциями являются: создание полной копии файла – поможет при операциях vSphere, связан- ных с копированием; многократная запись одинакового фрагмента данных – поможет при обну- лении виртуальных дисков; блокировка отдельной области данных – поможет снизить вероятность того, что блокировки метаданных раздела VMFS окажут негативное влия- ние на производительность. Перечислим операции vSphere, которые получат выигрыш от использованияVAAI: Storage vMotion; развертывание ВМ из шаблона и клонирование ВМ; ускорение работы виртуальных машин, использующих «тонкие» диски, thin provisioning; ускорение создания «предобнуленных», eagerzeroedthick-дисков – они не- обходимы для защиты виртуальных машин при помощи VMware Fault Tol- erance или Microsoft Failover Cluster. В некоторых случаях возможны 10–20-кратное ускорение операций и зна-чительное сокращение нагрузки на канал между системой хранения и сервером,а также на процессоры сервера. Определить поддержку V AAI со стороны системы хранения можно в интер-фейсе клиента vSphere (см. рис. 3.36). Рис. 3.36. Информация о поддержке VAAI в интерфейсе vSphere Есть определенные ограничения для использования этого механизма: на момент написания VAAI не были доступны для NFS; ESX(i) не сможет использовать V AAI при копировании данных между хра- нилищами с блоками разного размера. В таком случае копирование будет осуществлено по старинке, через сервер; если содержимое RDM LUN копируется не на RDM LUN; если исходный vmdk типа eagerzeroedthick, а целевой – thin;
    • vSphere API for Array Integration, VAAI. Интеграция и делегирование 193 если LUN, между которыми осуществляется операция, принадлежат раз- ным системам хранения. Все операции, доступные через V AAI, возможны лишь между LUN одной системы хранения. Хранилища VMFS с extent поддерживаются также, лишь если все составляющие их LUN принадле- жат одной СХД; если ваша инфрастуктура мигрировала на версию 4.1 с какой-то из пре- дыдущих версий, то потребуется обновить (то есть пересоздать) разделы VMFS, чтобы версия VMFS была максимальной, с поддержкой V AAI.
    • Глава 4. Расширенные настройки,безопасность, профили настроек 4.1. Расширенные настройки (Advanced settings) Если вы пройдете Configuration ⇒ Advanced Settings для Software, то увиди-те список разнообразных расширенных настроек ESX(i) (рис. 4.1). Рис. 4.1. Расширенные настройки (Advanced Settings) сервера ESX(i) Изменять эти настройки нужно очень аккуратно, и только те из них, в назначе-нии которых вы уверены. Как правило, рекомендации по их изменению вам можетдать поддержка VMware как средство решения каких-то проблем. Или какая-тостатья в базе знаний VMware (http://kb.vmware.com). Небольшая часть этих на-строек описана в документации.
    • Безопасность 195 Например: Disk.MaxLun – в этом параметре мы указываем максимальный номер LUN, докоторого ESX(i) опрашивает систему хранения при операции rescan. Если мак-симальный номер LUN, который мы используем, например, 15, то, указав Disk.MaxLun = 16, мы сократим время rescan. В частности, в документации неплохо описаны расширенные настройки дляiSCSI. Они, кстати, единственные, которые доступны в другом месте интерфейса(рис. 4.2). Рис. 4.2. Расширенные настройки (Advanced Settings) для программного инициатора iSCSI 4.2. Безопасность Как и везде, в виртуальной инфраструктуре безопасность очень важна. В этомразделе поговорим про разные аспекты безопасности. И в общем – что нужноиметь в виду при разговоре о безопасности в контексте vSphere, и в частности –
    • 196 Расширенные настройки, безопасность, профили настроекпро брандмауэр, который есть у ESX; про системы раздачи прав, которые реализо-ваны на ESX(i) и vCenter; про настройки там и здесь, которые имеют отношениек безопасности. 4.2.1. Общие соображения безопасности Здесь мне кажется оправданным дать представление об отличиях виртуальнойинфраструктуры с точки зрения безопасности. Естественно будет выделить несколько уровней виртуальной инфраструкту-ры, подход к защите которых различается: уровень виртуализации (гипервизор, VMkernel); уровень виртуальных машин; ESX Service Console; виртуальная сеть на ESX(i); системы хранения; vCenter Server. Виртуальные машины. Подход к обеспечению безопасности ВМ (гостевыхОС и приложений) такой же, как и при развертывании тех же ОС и приложенийна физической инфраструктуре, – антивирусы, сетевые экраны и прочее. Однаконе все из привычных средств применимы – аппаратные межсетевые экраны мало-эффективны, так как трафик между виртуальными машинами одного сервера непокидает пределов этого сервера и не доходит до физической сети. Скомпрометированная виртуальная машина может перемещаться между сер-верами и компрометировать виртуальные машины на других серверах. Обратите внимание. VMware предлагает свое решение межсетевого экрана для ВМ – vShield Zones. Кроме того, есть достаточное количество средств обеспечения безопасности от других производителей. Также VMware предлагает набор программных интерфейсов (API) под назва-нием VMSafe. C его помощью приложение из одной ВМ может получать доступк другим ВМ на этом ESX(i) через гипервизор. Например, мы можем иметь однуВМ с антивирусом, которая будет сканировать память всех прочих ВМ на этомсервере. В каких-то продуктах могут быть реализованы и другие полезные функ-ции, например сканирование выключенных ВМ. Несмотря на то что несколько ВМ работают на одном сервере, как-то пере-распределяют его память, их совместная работа не ухудшает ситуацию с безопас-ностью. Изнутри одной ВМ нет способа получить доступ внутрь другой черезгипервизор, кроме специализированных API VMsafe. Использование этих APIтребует четкого понимания