← All posts tagged VMware

В Пскове и Находке в процессе интеграций приобретённых активов нашлись Dell R410/R610/R710, преобразившиеся в гипервизоры.

И тут я понял, что Dell не нужно.

Установленные "Dell OpenManageServer Administrator vSphere Installation Bundle (VIB) for ESXi 5.5, V7.4" не доставляют racadm в комплектацию ESXi. Ручные приготовления из пакетов для RHEL5/6 x86 с добавлением требующихся им библиотек тоже не принесли особых успехов:

# strace -f -T /opt/dell/srvadmin/bin/racadm5 2>&1 | grep ' = 3'
open("/lib/libdl.so.2", O_RDONLY) = 3 <0.000025>
open("/lib/libpthread.so.0", O_RDONLY) = 3 <0.000025>
open("/lib/libstdc++.so.6", O_RDONLY) = 3 <0.000028>
open("/usr/lib/libargtable2.so.0", O_RDONLY) = 3 <0.000032>
open("/lib/libgcc_s.so.1", O_RDONLY) = 3 <0.000027>
open("/lib/libc.so.6", O_RDONLY) = 3 <0.000025>
open("/lib/libm.so.6", O_RDONLY) = 3 <0.000030>
Segmentation fault

Из коробки на хост после установки OMSA Bundle приезжает idracadm. Ощущает он себя идентично racadm.

Забыли/не знали доступы до OOB iDRAC? Перезагрузка и локальный доступ к серверу, и страдашки.

В интернетах не расскажут этого.

lo100cfg от RHEL6 работает и в VMware ESXi 5.5, достаточно его загрузить на гипервизор по scp. Последний набор HP STK, в котором ещё наличествовала утилита lo100cfg доступен по downloads.linux.hp.com в пакете hp-scripting-tools-9.50-97.rhel6.i686.rpm. Документация утилиты доступна по h20565.www2.hp.com

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

Так случилось, что ещё одна изумительная история вынудила нас обновить VMware vSphere c 5.1U2 до 5.5U2. Обновление до 5.5U2 вынудило обновить Symantec NetBackup с версии 7.6.0.1 до 7.6.0.3, которая уже научилась vSphere 5.5.

Не трудно представить себе топологию кусочка среды резервного копирования: Master-сервер NetBackup (VM), который, к тому же, является и backup-host, то есть гоняет через себя весь трафик от VMware ESXi (а значит и с их Datastore, подключенных по Fibre Channel) к Media-серверу (тоже VM) с томами NFS, экспортированными, например, с какой-нибудь low-entry СХД Huawei или HP MSA. Используется обычный в NetBackup тип передачи данных по LAN — NBD (Network Block Device).

Упрощённая схема хождения данных при резервном копировании VM может быть такая, например:

HP 3PAR --FCP--> HP c7000 (VirtualConnect --FCoE--> BLXXX) --FCP--> VMware ESXi 5.5U2 --NFC--> NB Master --TCP/UDP--> NB Media --NFS--> Huawei OceanStor FileEngines --FC--> Huawei OceanStor Enclosure

Где

FCP — Fibre Channel Protocol
FCoE — Fibre Channel over Ethernet
NFC — VMware Network File Copy Protocol
TCP/UDP — подразумевается проприетарный стек протоколов NetBackup.
NFS — Network File System

(Продолжение в комментариях)

VMware vSphere терминология --> XenServer терминология:

VMware vSphere Client --> XenCenter (the management console for XenServer)
Cluster / Resource Pool --> Resource Pool
Data Store --> Storage Repository
vMotion --> XenMotion
Distributed Resource Scheduling (DRS) --> Workload Balancing
High Availability (HA) --> High Availability (HA)
vCenter Converter --> XenConvert, XenServer Conversion Manager
Role Based Access Control (RBAC) --> Role Based Access Control (RBAC)

VMware vSphere очень многострадальный продукт. Обновление с 5.1 U1 до 5.1 U2 затянулось на две ночи.

Первым отказался обновиться SSO. Псоле обновления сервис не стартова и весь комплекс управления vSphere оказался недоступен. Решение:
1. Остановить все сервисы VMware на сервере с SSO. Наша инсталляции является не Simple и роли разнесены на несколько серверов.
2. Переименовать директорию jre по пути C:\Program Files\VMware\Infrastructure\ в jre_old, например.
3. Запустить обновление SSO.
4. Проверить успешный запуск сервиса и удалить jre_old.

Обновление Inventory Service прошло без нареканий.
Обновление vCenter на следующем сервер прошло с единственной ошибкой о невозможности запуска веб-сервисов (health/ServiceStatus/CIM monitoring), но vCenter запустился и заработал корректно с SSO и Inventory Service. Замена директории jre спасла и веб-сервисы.

Следующим проблемным обновлением был VUM (Update Manager). В самый ответственный момент он не смог "обновить базу данных". Решение частично описано в kb.vmware.com и сводится к вводу изменившихся реквизитов доступа к MSSQL-серверу для пользовательского DSN odbc32.

WebClient и толстый vSphere Client обновились без проблем. Log Insight 1.5 и vCOPS 5.5 продолжили работать без проблем.

Откровением на этот раз было понимание механизма работы vSphere. Внутри vSphere мало чем отличается в организации от Cisco Unified Communications Manager (на базе RHEL): набор разнообразных "демонов" на java, которые запускаются разнообразными врапперами как сервисы. Откуда все болезни Java при обновлениях между ветками JRE 1.6 -> 1.7 -> 1.8, совместимости плагинов и сетевых библиотек.

Теперь я вижу возможность поэтапной миграции комплекса с W2K8R2 на W2K12R2 без тотальной переинсталляции. Надо пробовать.

Вновь "Enterprise" лишь миф, именно за притёртость друг к другу, лоск костылей компании и платят такие деньги вендорам.

Как известно, Symantec NetBackup — это архисложная система костылей и подпорок, которая гордо именует себя Enterprise Backup and Restore System. И существует уже почти 30 лет.

Сегодня (уже вчера) мы обновились с 7.5.0.6 до 7.6.0.1, затаив дыхание после прочтения почти 50 страничного гайда аж второй версии (Upgrade Guide v2!). На первый взгляд ничего не отвалилось.

В 7.6 версии появилось очень много нового и интересного, ориентированного на виртуализацию, и, в первую очередь, на VMware экосистему. Самым вкусным, помимо обещанного ускорения бэкапирования VM, нововведением можно считать, конечно же, плагин для vCenter. Оный не только показывает красивую и информативную статистику, но и позволяет через визард восстанавливать машины прямо из интерфейса vCenter.

Плагин представляет собой обычный VM Appliance с CentOS 6.4 и софтом Symantec на борту. Обновление до 6.5 поломало некоторые функции, потому оставим как есть.

Самая магия случилась после перезагрузки этой VM. Так как оно игнорирует настройки хостнейма со стороны системы и применяет свои собственные с помощью инит-скрипта vaos, после перезагрузки я получил систему с localhost.localdomain. Не слишком продолжительное копание в очередном наборе bash скриптов с сомнительными зависимостями друг от друга привели меня к гениальному порождению сотрудников Symantec (а вдруг это аутсорсеры писали?) — скрипту vami_set_hostname. Он честно смотрел интерфейс, забирал IP и проверял обратную зону. Если обратная зона не резолвилась, то назначал localhost.localdomain в качестве имени хоста. Гениально же! К сожалению, они как-то совсем не учли, что хост может жить в серой сети и обратной зоны у него может и не быть.

Обыскал всю документацию по плагину и не нашёл никаких уточнений на такой случай. Будьте бдительны к сборищу костылей и подпорок по имени Symantec NetBackup. Эх, а ведь все мы отлично понимаем, что этому продукту нет замены на рынке по набору функционала, к сожалению.

Ну, как всегда, новая инсталляция. Учитываем все предыдущие ошибки. Есть шанс осуществить "вчера, скорее, всё пропало, менеджеры, менеджеры", и шанс осуществить "best practices, сделал, поломал, best practices".

Обратный отсчёт в 30 дней:
разумное, вечное, инженерное vs эффективность, эффективность, эффективность

Так как VMware Syslog Collector переродился в 2013 году в VMware vCenter Log Insight и стал платным совсем, в виде замены оного был развёрнут Graylog2. К сожалению, разработчики VMware не очень следуют RFC и формат сообщений отличается от стандартного.

Для автоматизации инсталляции приложения хороший человек создал Git репозиторий со скриптами для Debian/Ubuntu/CentOS: github.com

Для CentOS не всё прошло как по маслу, но я не гордый, я поправил руками.

Если у вас не используется vSphere Management Assistant (vMA) для коллекционирования логов со всех ESXi, то можно задать настройки Syslog для самих ESXi-серверов, участвующих в HA кластере, с помощью PowerCLI:

get-cluster 'CLUSTER-NAME' | get-vmhost | Set-VMHostAdvancedConfiguration -NameValue @{'Config.HostAgent.log.level'='info';'Vpx.Vpxa.config.log.level'='info';'Syslog.global.logHost'='udp://11.22.33.44:514'}

где CLUSTER-NAME — имя кластера, 11.22.33.44 — IP хоста c Graylog2.

Также необходимо не забыть в правилах фаервола на каждом хосте разрешить выпускать пакеты по портам Syslog:

get-cluster 'CLUSTER-NAME' | get-vmhost | Get-VMHostFirewallException |?{$_.Name -eq 'syslog'} | Set-VMHostFirewallException -Enabled:$true

где CLUSTER-NAME — имя кластера.

Почему так важно собирать данные Syslog с хостов ESXi? Сегодня мы закончили ликвидацию 3-х дневного трипа восстановления сервисов после деградации и разрушения VMFS5 на 3 LUN'ах внутри кластера датасторов. И безумно удивительно, что никаких внешних признаков начала порчи метаданных VMFS5 не было замечено ни одним из мониторингов. Единственное место, в котором были хотя бы какие-то данные в виде

Volume 52603f1b-1e61ba94-282b-101f7433eca0 ("DATASTORE-NAME") might be damaged on the disk. Resource cluster metadata corruption has been detected.

были лишь в файле vmkernel.log на хостах.

Я ненавижу VMware.

Я ненавижу все до одного их продукты и технологии виртуализации. Я ненавижу ESXi, я ненавижу vCenter, VMFS5, HA, DRS, sDRS, vMotion, VAMP, VAAI, SIOC, vDS, систему блокировок на уровне VMFS тома ненавижу как кровного врага. Я ненавижу их систему снапшотов, которая может поломаться на ровном месте.

Именно из-за продуктов VMware последние 2 года я сплю, в среднем, 5-6 часов в сутки.

24 сентября зарелизилась Ideco ICS 5.2.0, в которой, по заявлениям Changelog, они сумели:

Устранены слёты активации в виртуальных машинах (VMware, Hyper-V и др.)

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

Сегодня принял ужасное.
Комбинация из HP BL c7000 + VMware vSphere (vCenter + Ent Plus лицензии HP Custom ESXi, vNetwork Distributed Switch, sDRS/vMotion Enabled, HA), HP Insight Control + vCenter Plugin (Server/Storage), Brocade DCFM сильно сокращают штат инженеров до трёх-двух. А порой, возможно, и до одного, но крайне высокооплачиваемого.
Правда, в этом случае сильно вырастают риски за замыканием всех бизнес-процессов в руках одного человека, но это ведь уже другая история.

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

Удивителен и волшебен мир VMware. Ну а мир troubleshooting'а VMware почти полностью состоит из грибов. Всё нижесказанное актуально для томов VMFS, файловый доступ мы не рассматриваем.

После реанимации СХД не все машины успешно стартуют, некоторые зависают в процессе инициализации перед включением, некоторые на 95-100%. С нами играют злую шутку блокировки файлов виртуальной машины конкретным хостом.

Исторически, существует два типа блокировок — блокировка на уровне виртуальной машины и блокировка на уровне тома VMFS. Механизм первого типа достаточно прост и практически не менялся со времен ESX-серверов:

У VMFS тома существует heartbeat область, в которую каждый хост, исполняющий какую-либо машину, пишет свой ID. Каждый хост создаёт lock файл, информация о котором описывается в вышеуказанной области. Каждые 3 секунды хост обновляет timestamp у lock. При обращении какого-либо другого хоста к vmdk виртуальной машины, он первым делом проверит наличие блокировок vmdk другим хостом, обратившись к heartbeat области тома. Если блокировка существует, но timestamp не обновлялся уже 15 секунд, хост, ранее обслуживающий машину, считается недоступным, включается механизм HA и начинаются выборы нового хоста в качестве кандидата принять машину. Когда хост выбран, все остальные хосты в кластере ожидают обновления меток после снятия хостом старой блокировки и накатывания новой.

Вышеописанный алгоритм и дал сбой, хотя, с точки зрения виртуальной инфраструктуры, видимо, всё было корректно. После реанимации СХД, DRS и vMotion раскидали выключенные машины по другим хостам в кластере, но блокировки машин так и остались. Таким образом, с файлами машин невозможно было что-либо сделать, даже прочитать vmware.log. Перезапуск агентов на ESXi также не помогал.

Решение проблемы нижеописанным способом возможно в случае присутствующего shared хранилища, наличия кластера и работоспособного хоста, который поставил блокировку:

Первым делом необходимо уточнить какой именно хост поставил блокировку, на примере файла vmware.log:

/vmfs/volumes/4f9929a6-582ee2de-8c33-101f74338c9a/cook.XX.XX # vmkfstools -D vmware.log
Lock [type 10c00001 offset 82552832 v 6062, hb offset 3600384
gen 27, mode 1, owner 519b4d54-f4436aac-f0d4-101f74328d48 mtime 1046936
num 0 gblnum 0 gblgen 0 gblbrk 0]
Addr <4, 149, 141>, gen 6061, links 1, type reg, flags 0, uid 0, gid 0, mode 644
len 118095, nb 1 tbz 0, cow 0, newSinceEpoch 1, zla 1, bs 1048576

Где 101f74328d48 являет собой MAC-адрес сетевой карты (обычно vmnic0) блокирующего хоста. Найти хост по MAC-адресу адаптера обычно не составляет труда. Следующим шагом является создание жесткого правила DRS для кластера. В правиле необходимо указать, что виртуальная машина всегда должна запускаться на хосте, держащем блокировку.

После включения машины, vMotion переместит её на указанный хост, зарегистрирует там, машина запустится. Не забудьте после удалить созданное ранее правило DRS.

Подробнее про правила DRS можно почитать, например, blog.clearpathsg.com

Постановка задачи: необходим shared RDM диск, поверх которого уже будет работать ocfs2.

Стандартная ошибка при создании такого диска заключается в парковке диска на одном из портов того же SCSI контроллера, на котором расположен диск с операционной системой.

Например, диск с операционной системой находится на SCSI 0:0, соответственно, RAW Mapped LUN мы должны отдавать уже на SCSI 1:0. При этом будет создан новый контроллер SCSI типа VMware Paravirtual, в настройках которого стоит сразу же выбрать Pyshical в филдсете SCSI Bus Sharing.

На второй, третьей, N машине при добавлении shared RDM диска, необходимо выбрать на хранилище уже имеющийся RDM диск первой машины и повторить действия со SCSI контроллером.

Кстати, для машин с Windows при такой схеме рекомендуется изменять тип контроллера SCSI с VMware Paravirtual на LSI Logic SAS.

Вконец задумался о том, что пора бы уже и VCP5-DCV получить. Это стартовый сертификат в сфере виртуализации VMware а-ля ранее CCNA, ныне CCENT для Cisco. Как известно, чтобы получить возможность сдать VCP5-DCV, необходимо пройти авторизованные обязательные курсы VI5 ICM (VMware vSphere: Install, Configure, Manage). Стандартная цена курса на текущий момент составляет 60к рублей в Мск. 60к за разрешение для попытки войти в сообщество.

Они упоролись?

Про NetApp.
Некоторые интересующиеся люди знают, что у NetApp есть симулятор полнофункциональной версии Data ONTAP, который можно развернуть на любом гипервизоре как ova/vmx и начать исследовать возможности текущей версии OS NetApp'а. Не так давно NetApp выпустили полнофункциональный virtual appliance под названием Data ONTAP Edge.

По моим ощущениям, это решение очень сильно перекликается с EVA Command View от HP, который инсталлирован изначально непосредственно в модуль управления СХД, но возможен и к инсталляции на standalone хосте с перехватом управления контроллеров и полок удалённого СХД.

И всё бы хорошо в этой истории про NetApp Data ONTAP Edge/Simulator, если бы не одно но:

Edge доступен к свободному скачиванию с 90-дневной пробной лицензией, а вот Simulator доступен только для пользователей статуса Customer/End User (уже имеющих продукты NetApp) с now.netapp.com.

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

Продолжая #2337268.
Давно уже не секрет, что 80% акций VMware принадлежит компании EMC Corporation. Понимая, что VMware сейчас один из ведущих вендоров виртуализации, очень много компаний в сотрудничестве с создают продукты под эту платформу. Вот и EMC не оказались в стороне. Ещё в 2011 году они анонсировали VPLEX — технологию агрегации и дистрибьюции SAN. Чем-то похоже на уже существующее решение VSA от VMware, но, в данном случае, разговор идёт о Metro-сетях и возможности объединять в один логический том SAN-устройства нескольких ЦОД, разнесённых географически. По сути, это дополнительный уровень абстракции над SAN, который представляется для VMware target, для физических SAN — initiator. Естественно, всё это с vMotion, c HA и прочими стандартными технологиями благодаря vSphere Metro Storage Cluster. Эта технология появилась в vShpere 5 и доступна сейчас только для EMC VPLEX.

Что касается Nicira NVP — технологии виртуализации сетей. Похоже, все наработки уйдут в продукт по имени VMware NSX: blogs.vmware.com Поскольку NVP была основана на технологиях VXLAN, мы можем видеть продолжение развития свободных стандартов в корпоративных продуктах (http://www.googlesyndicatedsearch.com/u/ietf?q=vxlan).

Итого: виртуализация маршрутизаторов (Cisco CSR1000V/Juniper Olive), фаерволов (Cisco ASA 1000V), коммутаторов (Cisco Nexus 1000V/Open vSwitch), виртуализация SAN сетей (EMC VPLEX). Надеюсь, все это, рано или поздно, но будет уметь OpenFlow. Тем более, реализации OpenFlow контроллеров от вендоров мы видим уже сегодня (Nicira NVP, Cisco ONE Software Controller, Juniper JunosV Contrail).

В случае такого расцвета SDN, типовой ЦОД можно будет свести к одному гибридному Eth/FC коммутатору (Cisco Nexus 6000/Juniper QFX3500), Blade-шасси и N внешних СХД.

Не знаю как вас, а меня бы такое будущее ЦОД вполне бы устроило.

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

Всё нижесказанное верно для серверов, у которых отсутствует iLO/iDRAC. В противном случае дополнительные люди в процессе не требуются.

В нашей практике инсталляция нового кластера ESXi заключается в отсутствии необходимости ехать на площадку и самому лично инсталлировать серверы, которые уже после будут собраны в кластер и подключены в vCenter. Инсталляцию производят инженеры, отвечающие непосредственно за площадки. Инженер должен уметь базовый английский и понимание, что такое сетевые настройки в виде IP адреса, маски, шлюза, DNS, etc...

Если Вы ни разу не устанавливали VMware ESXi, то пронаблюдать за процессом можно по ссылке youtube.com

Весь процесс занимает не более 10 минут за несколько простых шагов, предварительно инженеру лишь необходимо записать на USB Flash с помощью Unetbootin образ ESXi.

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

По похожему пути пошёл Google со своим Google Global Cache, максимально упростив инсталляцию серверов до "вставьте usb flash с образом, укажите IP адрес/маску/шлюз, после инсталляции сервер перезагрузится". А вот уже поднятием LACP/BGP-сессии с нодой должен заниматься квалифицированный персонал.