← All posts tagged fail

В Пскове и Находке в процессе интеграций приобретённых активов нашлись 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? Перезагрузка и локальный доступ к серверу, и страдашки.

Как известно, 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. Эх, а ведь все мы отлично понимаем, что этому продукту нет замены на рынке по набору функционала, к сожалению.

Вот и minjust.ru снова пропал с радаров DNS. Ну как по расписанию последние месяцы.

$ host minjust.ru.
Host minjust.ru not found: 2(SERVFAIL)

$ whois minjust.ru | grep nserver
nserver: ns1.scli.ru.
nserver: ns2.scli.ru.

$ ping ns1.scli.ru.
PING ns1.scli.ru (87.245.163.21) 56(84) bytes of data.
^C
--- ns1.scli.ru ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2776ms

$ ping ns2.scli.ru.
PING ns2.scli.ru (94.79.50.34) 56(84) bytes of data.
^C
--- ns2.scli.ru ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2848ms

У меня создаётся впечатление, что xml дампы РКН пишут от руки. Ну как ещё оправдать

<content id="69088" includeTime="2014-02-28T18:29:17">
<decision date="2013-11-15" number="2-435/2013" org="суд"/>
<url><![CDATA[http://ru.scribd.com/doc/43706359/дубров-Г-К-Генералы-о-еврейской-мафии]]></url>
<ip>50.97.140.66</ip>
</content>

без <domain></domain>.

После очередного обновления списка и генерации конфигураций по дампу автомат выгрузил список блокировок на весь Anycast кластер DNS. Unbound очень удивился формулировке stub зоны с пустым именем домена и отказался запускаться после попытки перезапуска. Во всём NetByNet наступила тишина, у ВСЕХ абонентов, независимо от региона, кончились DNS провайдера :)

Хорошо ещё успел заметить в течение минуты и поправить ручными коммитом.

Спасибо, РКН, добра вам!

Сделал заказ в "Империя Пиццы" через сайт. Прошло 30 минут, оператор не перезванивает. Позвонил сам, сделал заказ, в личном кабинете заказ через сайт отменил. Через 40 минут привезли пиццу. Пицца почти съедена. И тут звонок от оператора по заказу с сайта.

Oook.

Приехал брендовый HP для конкретных задач с двумя SAS контроллерами для подключения дисковых полок. У каждого контроллера эпичный hand made на обратной стороне. Когда сняли первый, подумали, что багфикс. Когда сняли второй — ан нет, партия.

В жизни каждого среднего и крупного ЦОДа бывают случаи, когда 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

Уже ставшая стандартной рубрика "из жизни Ideco ICS". Оно попыталось обновиться по расписанию до 5.1.2 144 билда. После чего мы увидили сие прекрасные опусы в текстах для конечного пользователя. Особенно порадовало про Sleeping forever.

Использовать Oracle в компании без штатного DBA — всё равно что подарить человеку из прошлого Gillette Fusion Power. Вроде бы и бреет, а ощутить полный функционал не получается. Батарейки-то ещё не изобрели.

Отписался на launchpad в треде про теряющийся ethernet линк при использовании Qualcomm Atheros AR8152. Внезапно ответили

the Ubuntu Kernel team, Ubuntu Bug Control team, and Ubuntu Bug Squad would like you to please file a new report by executing the following in a terminal:
ubuntu-bug linux

И тут я понял — мне банально лень тратить время на описание бага и способа его воспроизвести, а также способа его решения. Мне уже лень тратить своё время на неприоритетное для меня в будущем занятие.

А всё почему? Потому что в этих ваших линуксах до сих пор нет вменяемого инструментария багрепоротов, который хотя бы в виде wizard проводил человека по опроснику, не заставляя его читать весь этот многокилометровый мануал — help.ubuntu.com

Никогда не доверяйте технической поддержке HP, особенно, если техподдержка — болгарин. "Мы выслали вам новый второй контроллер, просто вставьте его и всё заработает". После "просто вставьте" 5 минут нормального полёта и, затем, полностью деградировавшее СХД, утянувшее с собой добрую часть сервисов компании на базе VMware. На следующий лаконичный вопрос "wtf?" болгарин парировал "Мы же не говорили вставлять на горячую. Теперь вам надо выключить СХД, полностью расскомутировать, скоммутировать вновь и после включить" *facepalm
Саппорт HP был послан в дальние ебеня и своими силами дошли до момента конфликта версий прошивок контроллера нового с контроллером старым, из-за которого они и поставили колом всю СХД. Несколько магических пассов в консоли контроллеров решили проблему, LUN'ы радостно увиделись и подцепились к ESXi. Кроме одного.

Далее следует около 5 часов танца с бубном в попытке восстановить VMFS5. Что дало положительный результат уже трудно сказать: то ли это пересобравшийся raid, то ли это vmfs-fuse, которая за одно монтирование починила таблицу разделов, то ли это voma -f check. Но, в итоге, последний LUN пришёл в сознание и vCenter радостно подсосал оставшиеся машины, которые, казалось бы, канули в Лету.

Надо сказать, такие fuck up'ы очень полезны для больших компаний с эффективным менеджментом. Они позволяют сразу же обнаружить узкие места, где, порвавшись единожды, обязательно порвётся в следующий раз. И да, сразу же обнаруживаешь для каких именно mission critical сервисов ты всё ещё не создаёшь резервные копии.

Бэкапы, бэкапы, и ещё раз — бэкапы. Ну а в этот раз просто повезло.

Приехал в Воронеж, в Сбербанк. Я отчаянно не понимаю, откуда саппорт на телефоне и, затем, операторы в московском отделении Сбербанка лепетали мне об аресте счетов. За 1 час до конца рабочего дня в пятницу прекрасный администратор из отделения воронежского Сбербанка по телефону в течение 10 минут узнал все подробности операций за последние n месяцев по всем моим картам, независимо от их принадлежности к региону. Оказывается, оператор, что 9 марта делала вывод средств в наличные, умудрилась провести операцию два раза: с подтверждением через POS-терминал и с голосовой авторизацией. Голосовая авторизация легла в минус на снятую сумму по всем счетам. В следующие 5 минут этот прекрасный человек при мне сам заполнил бланк претензии от моего лица и попросил подписаться. Затем, при мне же, оформил эту претензию в воронежское отделение, рассказал номер претензии и подарил номера телефонов, по которым я могу звонить, минуя саппорт, и уточнять статус рассмотрения претензии. Единственное, маршрут рассмотрения удручает:

воронежское отделение -> запрос в московское отделение -> письмо-запрос из московского отделения в воронежское -> воронежское отделение -> откат одной из транзакций.

Это, как мне пообещали, не одна неделя. Ну что ж, будем надеяться на зарплатную менеджера, к которой вновь придётся обратиться.

Персоналу московского отделения Сбербанка за их компетентность в вопросе "неуд и завтра в школу с родителями".