Проблема

Я в конторе развернул ScaleIO на тестовом кластере. 4 гипервизора esxi, по 4 жёстких диска в каждом. И сегодня случился какой-то внезапный отвал двух нод последовательно. Машина с Primary MDM по сети отвечает, но находится в несознанке — по SSH зайти нельзя, локальная консоль тоже мёртвая. А secondary MDM выпал вместе с гипервизором. При этом непосредственно в момента вылета я внимательно втыкал в GUI ScaleIO, и, как говорится, ничто не предвещало.

Ребутнул сбойнувший гипервизор, виртуалка с secondary MDM поднялась и на вид даже как живая. Зашёл в консоль, говорю там:

Беглый осмотр слушаемых на машины портов показал, что реально, на порту 6611 никого нет:

# ss -l
Recv-Q Send-Q           Local Address:Port               Peer Address:Port
0      128                          *:9099                          *:*
0      128                          *:6611                          *:*
0      128                          *:9011                          *:*
0      128                          *:25620                         *:*
0      128                         :::ssh                          :::*
0      128                          *:ssh                           *:*
0      100                  127.0.0.1:smtp                          *:*
0      128                          *:25660                         *:*
0      128                          *:7072                          *:*
0      128                          *:25640                         *:*

А это нам намекает, что MDM на не стартовал. Не делает он этого в двух случаях — либо когда primary MDM в кластере поднят и работает, либо если что-то сломалось. Ситуация довольно идиотская, и напоминает пресловутую шутку про /pkunzip.zip/. Чтобы починить MDM, нужно сначала залогиниться в MDM, так как все команды scli выполняются через активный MDM. А чтобы залогиниться, нужен рабочий MDM.

Но хвала небесам, за то что они придумали коллективный разум. И белых людей, делящихся знаниями с другими людьми. Внезапно был обнаружен топик на хабре, где в комментариях один товарищ поделился тайными и скрытыми знаниями, почерпнутыми из секретной сервисной, не-доступной публично документации EMC. И вот эта цитата помогла разобраться с проблемой подключения при отсутствии работающего MDM:

Я проделал описанное и реально, это помогло — смог подключиться к MDM и проверить, что кластер хоть в каком-то виде жив. После этого удалось подключиться с помощью GUI, и увидеть, что не всё так плохо, как могло бы быть на самом деле:

Похоже, потерь данных не будет, но пока дальше разбираться с причинами проблем и пытаться ребутать машину, где работал primary MDM, лучше не торопиться. Дождёмся сначала полного ребилда томов.

Но радость была преждевременной

Тома ребилдились, и я решил разобраться с бывшим primary MDM. Ребутнул зависший хост, соответственно, виртуалка тоже ребутнулась, и все настроенные пулы выпали в состояние Failed. В общем, долго ли, коротко ли, но мораль сей басни такова — мало войти в rescue mode для MDM, нужно грамотно из него ещё и выйти. В моём случае нужно было бы делать так: оставить работать только secondary MDM в rescue mode, дождаться ребилда томов и эвакуировать все виртуалки оттуда. После этого попытаться переключить ScaleIO из cluster mode в single mode, снести на бывшем первом MDM пакет с MDM и переустановить его заново. Затем добавить его как secondary MDM и попытаться включить обратно cluster mode.

Мой дисковый пул рассыпался, так как после введения в rescue mode того MDM, который был secondary, он в авторитарном режиме стал primary. И пока он был один — всё работало. А как только я ребутнул зависший primary MDM, он отказался становиться secondary после ребута, и в итоге получилась ситуация split brain — два MDM в кластере, и оба primary, и с разной версией БД с метаданными. Ну в итоге они там и наребилдили выпавшие дисковые пулы, перемешав все блоки в кучу. Из-за этого всё рассыпалось.

Попытался сейчас на одной виртуалке с Ubuntu заапргейдить VMware tools в «non-interactive mode». Это когда оно, по идее, должно само подключиться к виртуалке, и само всё сделать. Но операция «Initiated VMware tools install or upgrade» зависла на 0%, и больше ничего нельзя было с виртуалкой сделать — ни отмонтировать диск с VMware tools, ни мигрировать виртуалку, ни отменить операцию установки. При попытке выбрать «End Install/upgrade VMware tools» выскакивала ошибка «Call „VirtualMachine.UnmountToolsInstaller“ for object „Usergate-Webfilter“ on vCenter Server „vcenter.vsphere.local“ failed», а в логах появлялось сообщение: «The operation is not allowed in the current state».

В общем, оставался вариант только попробовать потушить машину, чего делать очень не хотелось — машина в продакшене, и ею пользуются клиенты.

В итоге на просторах отыскался рецепт:

1. Включить SSH на том хосте, на котором работает виртуалка;
2. Зайти в консоль хоста и выполнить там команду vim-cmd vmsvc/getallvms. Эта команда покажет список работающих виртуалок. В левой колонке будет ID соответствующей виртуалки. Ищем в списке виртуалку, на которой завис инсталлятор VMware tools, и определяем её ID;
3. Выполняем команду vim-cmd vmsvc/tools.cancelinstall , где VM_ID — идентификатор виртуалки, определённый на шаге 2. После этого операция установки VMware tools завершается с ошибкой и освобождает виртуалку;
4. Не забываем снова отключить службу SSH на хосте.

Коллега недавно наткнулся на забавный косяк. Прописывает он задание в кроне, а оно не отрабатывает. Он уже и так, и так, и всё проверил — в логах запись об очередном запуске других (периодических) заданий крона есть, а его задание не отрабатывает.

Полезли смотреть всей толпой. Выявили, что в логах факт отработки крона логируется с указанием времени, на час опережающем текущее. Т. е. если, например, выполнить date, то получаем 17 часов, а крон в лог пишет, что запустился в 18 часов. Вспомнили, что мы этот сервак не перезагружали после обновления time zone data. Я сделал service syslogd restart. Смотрю в логи — ну, вроде как факт очередного редактирования crontab записался с правильным временем . Должно задание отработать. Однако нифига :-) В логах стало вот так:

Т. е. время скачет очень внезапно :-) Перезапуск крона этот вопрос решил, и время везде синхронизировалось. Т. е. задание не отрабатывало потому, что коллега устанавливал срабатывание задания на 17 часов, а крон считал, что уже 18 часов.

Предисловие

В конторе мы вынужденно используем FreeBSD 9.3 на BRAS'ах. Вызвано это тем, что на 10-ой фре есть какой-то косяк с mpd (у нас с его помощью PPPoE-соединения от клиентов обслуживаются). И mpd периодически виснет при значительном изменении числа подключений. Т. е. когда много клиентов одновременно подключается или отключается, mpd зависает в состоянии umtxn. Я писал по этому поводу в уже открытый PR, но движухи по нему нет.

О проблеме

Но речь не об этом. В общем, на фре 9.3 в файрволе pf обнаружился занятный баг. Баг относится к работе NAT на pf. Проявляется так:

1. Клиент шлёт через NAT запрос на какой-то сервер в интернете;
2. Сервер ему отвечает;
3. Но за время ответа у клиента этот порт, с которого он отправлял свой запрос, почему-то закрылся;
4. Клиент примет пакет от сервера и ответит серверу ICMP пакетом с типом port unreachable

Тут-то и проявляется баг — pf'овский NAT некорректно натит этот ответный ICMP-пакет, и в итоге с внешнего интерфейса улетает ICMP-пакет с серым SRC IP клиента и белым DST IP того сервера, куда этот пакет должен быть доставлен.

Т. е. допустим, у вас адрес NAT-интерфейса — 1.1.1.1, адрес сервера в интернете 2.2.2.2. И адрес клиента 192.168.0.1. В итоге с ВНЕШНЕГО интерфейса NAT'a улетит пакет с адреса 192.168.0.1 на адрес 2.2.2.2. Т. е. трансляции адреса клиента во внешний адрес NAT (1.1.1.1) не произойдёт.

Кровавые подробности

Если быть совсем точным, то трансляция ICMP-пакета таки происходит. Но не везде и не до конца :-)

Немного теории

ICMP-пакеты подразделяются на несколько типов. Причём в каждом типе есть ещё несколько подтипов. В данном случае клиент генерирует пакет типа 3 «destination unreachable». И подтипа тоже 3 — «port unreacable». Подробности можно почитать в man icmp, там есть табличка с типами и подтипами (подтипы называются codes, коды). В пакет типа port unreacahble клиент вкладывает заголовок того пакета, который вызвал генерацию сообщения ICMP «port unrecahable» (назовём для краткости такой пакет «пакетом-инициатором»). Ну, чтобы сервер, получивший от клиента ICMP destination unreachable понимал, на какой конкретно его пакет клиент ответил, что порт недоступен. И вот расследование показало, что как раз этот заголовок, пакета-инициатора транслируется файрволом нормально. Но сам ICMP-пакет — нет.

Суровая практическая реальность

Итак, мы приняли, что локальный IP клиента у нас 192.168.0.1, а внешний IP, в который NAT'ится клиентский трафик — 1.1.1.1. Таким образом, получается примерно такой формат ICMP-пакета от клиента обратно на сервер 2.2.2.2 (до трансляции):

То есть, клиент со своего адреса 192.168.0.1 оповещает сервер 2.2.2.2, что типа, «бро, ты мне отправил пакет со своего IP 2.2.2.2 и порта 80 на мой адрес 192.168.0.1 и порт 12345. Ну так вот, довожу до твоего сведения, что этот порт у меня закрыт».

После трансляции через NAT пакет должен модифицироваться следующим образом:

То есть, NAT уже от своего имени проговаривает серверу 2.2.2.2: «бро, ты мне отправил пакет со своего IP 2.2.2.2 и порта 80 на мой адрес 1.1.1.1 и порт 54321. Ну так вот, довожу до твоего сведения, что этот порт у меня закрыт».

Обращаю внимание, что порт на клиентской стороне ДО и ПОСЛЕ трансляции могут отличаться. Т. е. то, что у клиента слушает на порту 12345, на NAT'е будет на порту 54321 (ну, или на любом другой, который будет свободен на момент установки соединения клиентом, и который NAT выберет для трансляции). Ну это так, для сведения, сейчас это роли не играет.

Так вот, из-за бага в pf пакет транслируется следующим образом:

Т. е. NAT в pf транслирует только заголовок пакета-инициатора, идущий нагрузкой в ICMP-пакете типа «destination unreachable», но не транслирует заголовок самого ICMP-пакета.

Заключение

Написал сообщение в рассылку freebsd-net. Там товарищ Kristof Provost попросил проверить, есть ли такое же поведение в -CURRENT, и если да, то он посмотрит, в чём там проблема. Ну, соберу -CURRENT на досуге, попробую.

А, кстати, ещё один момент. pf не только некорректно натит такие пакеты, но и также не может блокировать этот трафик. Т. е. правило вида

тоже не работает для таких пакетов. Похоже, pf анализирует только содержащийся в нагрузке заголовок пакета-инициатора, а не самого ICMP-пакета.

UPDATE

Собрал -CURRENT, проверил. Это поведение полностью повторяется и в -CURRENT. Нарисовал багрепорт по этому поводу, авось когда-нибудь починят. На текущий момент подобный пытающийся улететь наружу трафик блокируется с помощью IPFW.

Решил побаловаться с SCVMM 2012 R2, посмотреть, что это такое и с чем его едят. Развернул два хоста с Hyper-V Server 2012 R2, и один хост с Win2012 R2 под общее хранилище кластера виртуализации.

Первым делом поставил в виртуалку фрю, чтобы посмотреть, как оно себя там чувствует. Оказалось, что чувствует фря себя там относительно неплохо. Прямо из коробки есть синтетический сетевой, и синтетический же дисковый адаптер. Правда, с последним возник касичок, о чём и пойдёт речь ниже.

Суть косяка в том, что фря видит ДВА диска там, где по факту он всего один. На этапе установки это выглядит так:

Я выбрал при установке da0, и поставил систему туда, и всё отлично заработало. Но решил разобраться, в чём тут дело. Первое предположение было, что фря видит два диска из-за проблем в драйвере. И ada0 — это эмулируемый дисковый контроллер, а da0 — синтетический. Гуглинг ничего не показал, кроме указаний на статью в MSDN. Но там никакого внимания этой проблеме не уделено, просто скриншот (это как раз он выше) представлен, и всё. И пользователь в комментариях задаёт вопрос, типа, «why attached virtual disk to guest is visible twice? It's visiblle as ada0 and da0». Или, иными словами, а почему диск виден дважды под разными именами? Но ответа на этот вопрос не последовало.

Больше никакой информации найти не удалось, поэтому я решил написать команде разработчиков в Microsoft, которые пилят поддержку гостевых компонентов Hyper-V во фре. Написал безо всякой надежды на ответ, однако на следующий день мне ответили.

В общем, по итогам общения выяснилось, что действительно, два диска представляют по сути один диск, но видимый через разные дисковые контроллеры. ada0 — это эмулируемый контроллер, da0 — синтетический. Разработчики рекомендовали использовать da0, так как будет выше производительность и ниже нагрузка на процессор. И можно слегка поправить исходники соответствующего модуля, чтобы система перестала видеть диск ada0 вообще, и остался только da0. Для этого нужно сделать следующее: в файле /usr/src/sys/dev/hyperv/stordisengage/hv_ata_pci_disengage.c необходимо найти функцию v_ata_pci_probe(), и заменить в ней возвращаемое значение (return value) с BUS_PROBE_DEFAULT на BUS_PROBE_VENDOR. После этого пересобрать и установить ядро. Я проделал это, и проблема исчезла.

Также был затронут вопрос про KVP daemon. Это процесс, который умеет из гостевой фри общаться с гипервизором, и принимать/передавать туда-сюда key-values pairs. Т. е. какие-то параметры конфигурации. В частности, он используется для того, чтобы в Hyper-V manager можно было видеть IP-адрес, который имеет гостевая фря. И, по слухам, также может получать статические IP из пула, назначаемого из SCVMM, и прописывать его в гостевую систему. Но это я ещё не проверял, поэтому не знаю.

В общем, с KVP (процесс hv_kvp_daemon) тоже проблемка — он стартует только один раз после установки системы, а потом отказывается. Я порылся, и выяснил, что при запуске hv_kvp_daemon пытается создавать директорию /var/db/hyperv/pool. И если эта директория уже существует, (и следовательно, создать её не удаётся), то hv_kvp_daemon не запускается. Налицо просто некорректная обработка ошибки при попытке создания каталога. Т. е. вместо проверки на существование каталога делается попытка создания, и если она неудачная, то fail. Удаление каталога руками проблему решает — hv_kvp_daemon запускается. Непонятно, почему в системе нет стартового скрипта для этого демона, и его нужно запускать ручками. Возможно, считается, что демон ещё не доведён до ума, поэтому и стартового скрипта нет. В принципе, эту проблему с создание каталога можно обойти в стартовом скрипте — удалять каталог после остановки демона, и проверять каталог на существование при старте, и если он есть — опять таки, удаляем, hv_kvp_daemon его создаст себе сам.

Мораль: фрю вполне можно использовать в качестве гостевой ОС внутри Hyper-V. Я вижу в коммитах фрёвых исходников, что какая-то работа потихоньку, поддержка Hyper-V во фре допиливается, медленно, но верно. Остаётся дождаться только работы динамической памяти в гостевой фре, и можно совершенно смело гостевать фрю на Hyper-V. Сейчас оно всё работает — сетка и диски видны из коробки (на фре 10.1), крутится довольно стабильно. Правда, я нагрузки большой не давал, но в рамках той нагрузки, что есть, всё работает.

На домашнем сервере крутится Unbound, на котором я включил DNSSEC для корневых зон. Для смелых и столь же бесчеловечных экспериментов поднял в виртуалках виндовый домен homelab.local. И решил прописать в Unbound локальные зоны. Точнее — stub-зоны, чтобы с домашних компов можно было обращаться к компам из зоны homelab.local по именам.

Прописал всё как положено:

Но имена так и не резолвились. Начал копать вокруг файрволов — нет, не файрволы, все запросы проходят, сервера отвечают. То есть, я вижу, как идёт запрос с Unbound на DNS-сервер 192.168.2.3 (это контроллер домена homelab.local), и даже вижу, как на Unbound с контроллера приходит ответ, но фактически же Unbound мне возвращает SERVFAIL.

Что, в общем-то, логично, если подумать. Корневая зона .local не имеет подписи, соответственно, Unbound трактовал её как паленую. Указание в конфиге:

указанную проблему сняло, и имена зоны homelab.local начали разрешаться.

Поимел сейчас неясного происхождения баг — домашнее хранилище, организованное на основе неттопа, зависло. Система там стоит на флэшке, на винте только своп и юзерские файлы. Перезагрузил, начал чинить ошибки на файловой системе флэшки. Ну, всё как обычно:

после одного из разделов fsck доложил, что часть ошибок исправлена, но filesystem is still dirty, please rerun fsck. Я перезапустил, а в ответ мне:

Хотя визуально все разделы на месте, о чём подтверждали все утилиты. Поиск по интернету конкретного рецепта не принёс, но навёл на размышления о повреждённом суперблоке. В итоге вылечил таки.

Сначала надо выяснить, где размещаются копии суперблока. Делаем раз:

Нужно починить файловую систему с правильным суперблоком. Сделать это можно командой fsck_ffs:

Ключ -b 1573248 указывает, что нужно при ремонте ФС нужно использовать не первый суперблок, а тот, который лежит по смещению 1573248. После этого система починилась нормально.

Попытался тут оторвать все модули и жёстко впаять необходимое в ядро. Система грузится с ZFS, а также используется AIO для самбы, ибо сильно увеличивает скорость работы самбовых шар. Проверил как-то ради шутки — без AIO гиговый файл копировался 9 минут 10 секунд, с включенным AIO — 1 минуту 45 секунд. Разница примерно 6 раз.

В общем, пока (на момент версии FreeBSD 9.2) выясняется, что zfs.ko и opensolaris.ko в ядро не включить, можно только модулями ядра грузить. Добавил в ядро только AIO:

И прописал в make.conf:

Собрал ядро, установил, попытался перезагрузиться и получил облом. При загрузке система стала утверждать, что не знает, откуда смонтировать root. Оказывается, нужен ещё модуль krpc.ko, отвечающий за реализацию RPC в солярке (откуда и портирована ZFS). Причём судя по обрывочным сведениям, нужен он только на 64-битной фре, на 32-битной вроде как нет. Проверять, честно говоря, влом :-)

Правим make.conf:

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

Внезапно сервак стал жаловаться на здоровье, а именно — на то, что по данным SMART одного из дисков, стало этому диску плохеть. Диск у нас этот трудится в HP Proliant DL380 G5, в RAID-5, собранном на контроллере Compaq SmartArray P400.

Ну, винты на замену были, но диск пока вроде работает. Решили подоткнуть новый диск и пометить его как hot spare, на случай если диск из массива самозапилится, то будет подхвачен новый HS-диск. Диск подоткнули, но вот с hot spare получился облом — оказывается, этот контроллер умеет в массив вставлять HS только в момент создания. А в уже существующий массив — нет.

Так что надо менять диск. Я старательно всё забэкапил, тщательно прицелился, из какого отсека диск вынимать, запалил там лампочку-индикатор, и товарищ, находящийся на месте, диск заменил. Всё вроде понялось, спросило у меня «тут это, новый диск. Будем ребилдить массив?» Я грю — конечно, бро, надо ребилдить! И процесс пошёл. Поскольку на сервере стоит FreeBSD, а там особо никаких утилит нет, позволяющих получить кровавые подробности о состоянии массива, то удовольствоваться пришлось командой:

Я так полагаю, что VOLUME reco должно индицировать, что volume recovering. Ну, сидим курим, ждём окончания ребилда. Час, два ждём... И тут кончается рабочий день.

В общем, на следующий день к часу дня статус массива так и не изменился. Тут-то я и насторожился. И обратился к коллективному разуму с вопросом — а нормально ли это, для 150-гигового винта в RAID-5 такое время ребилда? Коллективный разум однозначно решил, что ненормально, но посоветовал использовать утилиту sysutils/cciss_vol_status, каковую я немедленно и проинсталлировал. Утилита английским по белому сказала:

То есть, она считает, что массив уже вполне ОК. Но это расходится с показаниями camcontrol. В общем, похоже, camcontrol не перечитал данные с контроллера. Почему-то. Пришлось ему принудительно сделать

Только после этого camcontrol ответил, что

Вот и думай теперь, как ему после этого доверять. Придётся, видимо, в мониторинге переделывать получение данных о состоянии массива с camcontrol на cciss_vol_status :-(

При обновлении системы и и всего софта до распоследних версий столкнулся с тем, что в zabbix-frontend при использовании PHP 5.5 появляется в красной рамочке надпись перед каждой таблицей с выборками из базы:

mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead [include/db.inc.php:77]

Думал, что это PHP warning (простительно после вторых суток колупания в конфигах). ПОтом дошло, что не, что-то тут нечисто. Полез искать, нашёл описание баги в багтрекере заббикса. Баг имеет статус unresolved, но там приложен некий патч (от 11.07.2013), который проблему вроде как решает. Возможно, там какие-то косяки потом всплывут, но бегло пощёлкав по страничкам фронтэнда, ничего такого не выявилось.