Привет Хабр. Хотел бы описать решение проблемы с 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, на котором настроены все нужные сервисы. Почему ��ак? Решение было принято более опытным коллегой, который к сожалению уволился, а я не особо силен в системном администрировании. Опущу небольшую часть истории про смену пароля, которого я конечно же не знал :)
Подключился я к серверу физическому, и там:
Ок, сервер running, id 1. К терминалу не цепляется (с учетом небольшой паники, я забыл про vnc, но на тот момент он мне не очень бы помог, хотя и был настроен для гостевой OS).
Не ок, но что поделаешь:
Ждемс. К терминалу все еще не цепляется. ssh соединение не работает. Вобщем сервер не стартует. Многократные попытки destroy/start ни к чему не привели. Отчаявшись, я решил посмотреть на конфигурацию гостевой OS. А там:
Обрадовался и полез смотреть на это безобразие по vnc. Все дальнейшее выполняется внутри гостевой OS. А там:
После первого нажатия 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 ничего не менять, выводить многомусора интересной информации в консоль и проверить все, даже если файловая система не помечена как поврежденная. Из 5, на 3 оказались ошибки/повреждения ФС.
Дальше я рискнул, и попросил fsck все исправить:
В тоже время mdadm для всех устройств говорил:
/etc/fstab говорил:
Исправления прошли на ура. Осталось понять как заставить все это собраться опять. Перезагрузка не помогла. Сам по себе массив не собрался. Оказалось что названия и маппинг устройств вида /dev/md[xxx] в /dev/md/[yyy] менялись при каждой перезагрузке (в /dev/md/ создаются символические ссылки на /dev/md[xxx]). Поэтому устройства прописанные в /etc/mdadm.conf системой не находились и автоматически не монтировались.
На этом этапе я перестал задаваться вопросом «Как же это раньше работало?», и решительно стал искать какой-то способ связать прописанное в данном файле с тем что я видел в /dev/md/.
И таки нашел:
Связь найдена (UUID), дело за малым. Назначить найденным в /etc/fstab старым mount point’ам, новые устройства из списка /dev/md[xxx], что и было сделано:
Перезапустив mysql, apache и прочее, увидев, что содержимое /var/www вернулось и вообще все цветет и пляшет, я таки успокоился и пошел пить кофе. Как оказалось, сервер не дожил 4 дней до года аптайма. Однако нельзя сказать, что проблема решена на 100%. Непонятно поведения при перезагрузке, но теперь уж есть список манипуляций которые надо произвести чтобы все опять заработало. Вопрос к сообществу, а сталкивался ли кто-нибудь с подобным?
На этом вопросе я закончу свой рассказ. Советы, вопросы и комментарии приветствуются.
PS: После вышеописанных работ, у меня возникло желание избавиться от такой кхм, странной конфигурации дисков, но виртуализацию оставить. Заодно, будет повод развить навыки настройки сервера и выпросить у начальства апгрейд памяти для сервера, к которому по аппаратной части нареканий нет (Dell PowerEdge tower).
Пару дней назад, работал я, писал код на 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, я понял что все похоже очень плохо. После
Гугл подсказал, что fsck и mdadm мне в помощь:
fsck –nvf /dev/md/1_0
…
fsck –nvf /dev/md/5_0
Просим fsck ничего не менять, выводить много
Дальше я рискнул, и попросил 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).
