Хотел бы описать решение проблемы с Software RAID на Ubuntu Server 11.04 с которой я столкнулся неправильно перезагрузив сервер.
Пару дней назад, работал я, писал код на php, сервер офисный сильно не грузил. Вообще у нас принято как серверный так и клиентский код писать на собственных машинах и версировать при помощи git, разве что база данных mysql иногда бывает общей, с того самого сервера. А если надо, то git push в помощь. Для многих разработок на сервере настроены vhosts обновляемые из git и доступные из просторов интернетов.
Перезагрузив какую-то страницу с сервера, я почуял, что что-то не так, часть страницы загрузилась, а дальше все… Ситуацию усугубляло то, что коллега подошел и сказал что у него перестал работать доступ на сервер по smb, а у меня еще и отвалилось соединение по ssh. Стало ясно, что повис не только apache.
«Не проблема», подумал я, «ведь у нас виртуализация, перезагружу vm и дело в шляпе». Да, да именно так. Стоит себе физический сервер, на Ubuntu Server 11.04, внутри которого под qemu запущен еще один Ubuntu Server 11.04, на котором настроены все нужные сервисы. Почему так? Решение было принято более опытным коллегой, который к сожалению уволился, а я не особо силен в системном администрировании. Опущу небольшую часть истории про смену пароля, которого я конечно же не знал :)
Подключился я к серверу физическому, и там:
virsh:
list
Ок, сервер running, id 1. К терминалу не цепляется (с учетом небольшой паники, я забыл про vnc, но на тот момент он мне не очень бы помог, хотя и был настроен для гостевой OS).
virsh:
reboot 1
error: this function is not supported by the hypervisor: virDomainReboot
Не ок, но что поделаешь:
virsh:
destroy 1
start 1
Ждемс. К терминалу все еще не цепляется. ssh соединение не работает. Вобщем сервер не стартует. Многократные попытки destroy/start ни к чему не привели. Отчаявшись, я решил посмотреть на конфигурацию гостевой OS. А там:
<graphics type='vnc' port='5901' autoport='no' listen='0.0.0.0'/>
Обрадовался и полез смотреть на это безобразие по vnc. Все дальнейшее выполняется внутри гостевой OS. А там:
The disk drive for /some/mounted/folder is not ready yet or not present
Continue to wait; or Press S to skip mounting or M for manual recovery
После первого нажатия S, я понял что все похоже очень плохо. После импульсивного нажамания S 100500 раз удержания S в течение секунды, OS продолжил загрузку, но mysql, apache и многие другие демоны не запустились, так как папки вроде /var/lib/mysql оказались непримонтированы. Преодолев логин, я попытался понять, куда все пропало (бекапы у нас есть, вот только очень уж не хотелось весь остаток недели заниматься восстановлением). Присутствие в /etc/fstab и в /dev/ странных записей вроде /dev/md/1_0 меня насторожило. Гугл подсказал, что это части Software RAID массива. Внутри Ubuntu, Ubuntu, внутри Ubuntu Software RAID… Вот. Частей оказалось 5.
Гугл подсказал, что fsck и mdadm мне в помощь:
fsck –nvf /dev/md/1_0
…
fsck –nvf /dev/md/5_0
Просим fsck ничего не менять, выводить много мусора интересной информации в консоль и проверить все, даже если файловая система не помечена как поврежденная. Из 5, на 3 оказались ошибки/повреждения ФС.
Дальше я рискнул, и попросил fsck все исправить:
fsck –vf /dev/md/1_0
…
fsck –vf /dev/md/1_0
В тоже время mdadm для всех устройств говорил:
mdadm --detail /dev/md/1_0
…
Raid Level : raid1
…
/etc/fstab говорил:
…
/dev/md/1_0 /var/www ext3 defaults,noatime 1 2
…
Исправления прошли на ура. Осталось понять как заставить все это собраться опять. Перезагрузка не помогла. Сам по себе массив не собрался. Оказалось что названия и маппинг устройств вида /dev/md[xxx] в /dev/md/[yyy] менялись при каждой перезагрузке (в /dev/md/ создаются символические ссылки на /dev/md[xxx]). Поэтому устройства прописанные в /etc/mdadm.conf системой не находились и автоматически не монтировались.
На этом этапе я перестал задаваться вопросом «Как же это раньше работало?», и решительно стал искать какой-то способ связать прописанное в данном файле с тем что я видел в /dev/md/.
И таки нашел:
mdadm --detail /dev/md/123_0
…
UUID : 4e9f1a60:4492:11e2:a25f:0800200c9a66
…
less /etc/mdadm.conf
ARRAY /dev/md/1_0 level=raid1 metadata=0.90 num-devices=2 devices=/dev/sda5,/dev/sdb5 UUID=4e9f1a60:4492:11e2:a25f:0800200c9a66
Связь найдена (UUID), дело за малым. Назначить найденным в /etc/fstab старым mount point’ам, новые устройства из списка /dev/md[xxx], что и было сделано:
mount –a
#Монтирует все описанное в /etc/fstab
Перезапустив mysql, apache и прочее, увидев, что содержимое /var/www вернулось и вообще все цветет и пляшет, я таки успокоился и пошел пить кофе. Как оказалось, сервер не дожил 4 дней до года аптайма. Однако нельзя сказать, что проблема решена на 100%. Непонятно поведения при перезагрузке, но теперь уж есть список манипуляций которые надо произвести чтобы все опять заработало. Вопрос к сообществу, а сталкивался ли кто-нибудь с подобным?
На этом вопросе я закончу свой рассказ. Советы, вопросы и комментарии приветствуются.
PS: После вышеописанных работ, у меня возникло желание избавиться от такой кхм, странной конфигурации дисков, но виртуализацию оставить. Заодно, будет повод развить навыки настройки сервера и выпросить у начальства апгрейд памяти для сервера, к которому по аппаратной части нареканий нет (Dell PowerEdge tower).
Автор: sparksounds
