Копаясь на хабре наткнулся на крик о помощи. Кому лень под ссылку, в двух словах опишу: у человека упал кластер, ноды на веб-морду не пускают при том, что сами виртуалки пашут штатно. В связи с тем, что у меня была похожая ситуация, очень хочется помочь страждущему, потому как представляю его состояние сейчас, каково это, когда САМЫЙ ГЛАВЫНЫЙ СЕРВЕР на котором крутиться вся инфраструктура предприятия начинает выделываться, или того хуже, отказывает.Но к сожалению рид-онли статус не позволяет комментировать посты, и это и вторая причина написания статьи, получить уже инвайт.
Сразу оговорюсь, это был мой первый опыт работы с виртуализацией такого уровня да ещё и на Linux, поэтому не пинайте сильно, а если где ошибусь, отпишите в комментах — поправлю.
В двух словах о моей ситуации:
1 Нода: Prox. IP 192.168.1.1
2 тома LVE: Data и Backup на RAID50 массиве из 6 дисков.
6 ВМ для различных нужд от кешируюшего прозрачного прокси до контроллера домена. (ОС Debian 6, Win2008, XP)
Железка не столь важна.
Симптомы: Веб морда не открывается. Виртуалки пашут штатно, по RDP и SSH пускают.
Что было проделано.
В процессе ковыряния выяснилось что апача то в общем-то запускается, но вот с https работать отказывается на проч, переустановки и настройки всего что только можно и нельзя ни к чему не привели. 192.168.1.1 — «It's works!», 192.168.1.1 — «Веб-сервер не найден».
Подгоняемый необходимостью внести изменение в конфигурацию виртуалок я пришел к единственному возможному варианту — переустановка. Но ведь ДЛАННЫЕ! Сохранность файлопомойки, а особенно баз 1С меня сильно беспокоила.
Первый вариант с бекапом всего сервера вместе с виртуалками и последующим ковырянием отвалился по причине томов LVE, с которыми ни одна из известных мне утилит резервного копирования не захотела работать. Даже те которые в принципе смогли увидеть RAID.
Второй вариант с бекапом данных из виртуалок (они-то работают штатно и пускают по RDP и VNC) и сносом подчистую отметён сразу за отстутствием времени. На подобную процедуру с восстановлением всех виртуалок уйдёт пару дней, которых, как водится нет, точнее временя есть, но остановить на два дня все сервера никто не даст.
Сутки ковыряния в сети закончились осознанием очевидной, в общем-то мысли, ведь это просто KVM со специфичными для Proxmoxa свистелками-перделками, а значит базовый функционал должен быть на месте как ни крути.
Таким образом схема простая:
1) Бекап ВМ штатными средствами KVM.
2) Сохраняем бекапы на сетевое хранилище.
2) Переустановка Proxmox
3) Восстановление машин
Уже позже я сообразил, что два первых пункта можно объединить и бекапить сразу на NAS в NFS-папку.
Первый пункт
где /backup — папка куда класть бекап, xxx@yyy.com — куда послать отчёт 516 — номер виртуалки которую бекапим. Справедливости ради скажу, что ключей у vzdump значительно больше, но этих более чем достаточно.
Таким образом для бекапа на сетевое хранилище его сначала надо смонтировать куда ни будь к корневой ФС, а уже потом туда бекапить.
Второй пункт
не должен представить проблем. Любой способ копирования, тот же UltraVNC позволяет отлично сливать любые файлы с удалённой машины а МС на флешку локально. (Это для ленивых. Настоящие гуру конечно воспользуются консолью)
Третий пункт.
Всё так же элементарно как с установкой любой десктопной ОС. Псевдографический интерфейс на человеческом английском языке, где белым по синему всё подробно описано и объяснено. Самый сложный нюанс выбрать файловую систему для будущих томов и прописать сетевые настройки. (И самое главное не забыть пароль на root)
Четвертое посложнее.
Рецепт был выкопан в сети, опять же к слову, описание коего гуглиться второй ссылкой на первой страницы после официального сайта Proxmox.
Ссылку на него не привожу за ненадобностью а рецепт в кратце опишу.
Распаковываем архив резервной копии:
В архива находится два файла:
qemu-server.conf — конфигурация виртуальной машины;
vm-disk-virtio0(1,2,3 и тд).raw — образ(ы) диска виртуальной машины.
Вот что представляет собой файл конфигурации:
name: mail
ide2: local:iso/debian-505-amd64-CD-1.iso,media=cdrom
vlan0: virtio=82:15:30:A4:65:E7
bootdisk: virtio0
virtio0: local:516/vm-516-disk-1.raw
ostype: l26
memory: 1024
onboot: 1
sockets: 1
vlan1: virtio=42:45:F5:F2:95:A8
cores: 1
boot: cad
freeze: 0
cpuunits: 2000
acpi: 1
kvm: 1
lock: backup
(По файлу думаю всё ясно и объяснять, что тут что не нужно)
Меняем имя файла образа:
Копируем его в указаное в конфигурации место.
Меняем имя файла конфигурации:
Копируем его в папку /etc/qemu-server/ и комментируем последнюю строчку lock: backup.
Все, запускаем виртуальную машину.
Сразу оговорюсь, это был мой первый опыт работы с виртуализацией такого уровня да ещё и на Linux, поэтому не пинайте сильно, а если где ошибусь, отпишите в комментах — поправлю.
В двух словах о моей ситуации:
1 Нода: Prox. IP 192.168.1.1
2 тома LVE: Data и Backup на RAID50 массиве из 6 дисков.
6 ВМ для различных нужд от кешируюшего прозрачного прокси до контроллера домена. (ОС Debian 6, Win2008, XP)
Железка не столь важна.
Симптомы: Веб морда не открывается. Виртуалки пашут штатно, по RDP и SSH пускают.
Что было проделано.
В процессе ковыряния выяснилось что апача то в общем-то запускается, но вот с https работать отказывается на проч, переустановки и настройки всего что только можно и нельзя ни к чему не привели. 192.168.1.1 — «It's works!», 192.168.1.1 — «Веб-сервер не найден».
Подгоняемый необходимостью внести изменение в конфигурацию виртуалок я пришел к единственному возможному варианту — переустановка. Но ведь ДЛАННЫЕ! Сохранность файлопомойки, а особенно баз 1С меня сильно беспокоила.
Первый вариант с бекапом всего сервера вместе с виртуалками и последующим ковырянием отвалился по причине томов LVE, с которыми ни одна из известных мне утилит резервного копирования не захотела работать. Даже те которые в принципе смогли увидеть RAID.
Второй вариант с бекапом данных из виртуалок (они-то работают штатно и пускают по RDP и VNC) и сносом подчистую отметён сразу за отстутствием времени. На подобную процедуру с восстановлением всех виртуалок уйдёт пару дней, которых, как водится нет, точнее временя есть, но остановить на два дня все сервера никто не даст.
Сутки ковыряния в сети закончились осознанием очевидной, в общем-то мысли, ведь это просто KVM со специфичными для Proxmoxa свистелками-перделками, а значит базовый функционал должен быть на месте как ни крути.
Таким образом схема простая:
1) Бекап ВМ штатными средствами KVM.
2) Сохраняем бекапы на сетевое хранилище.
2) Переустановка Proxmox
3) Восстановление машин
Уже позже я сообразил, что два первых пункта можно объединить и бекапить сразу на NAS в NFS-папку.
Первый пункт
vzdump --compress --dumpdir=/backup --mailto xxx@yyy.com 516где /backup — папка куда класть бекап, xxx@yyy.com — куда послать отчёт 516 — номер виртуалки которую бекапим. Справедливости ради скажу, что ключей у vzdump значительно больше, но этих более чем достаточно.
Таким образом для бекапа на сетевое хранилище его сначала надо смонтировать куда ни будь к корневой ФС, а уже потом туда бекапить.
Второй пункт
не должен представить проблем. Любой способ копирования, тот же UltraVNC позволяет отлично сливать любые файлы с удалённой машины а МС на флешку локально. (Это для ленивых. Настоящие гуру конечно воспользуются консолью)
Третий пункт.
Всё так же элементарно как с установкой любой десктопной ОС. Псевдографический интерфейс на человеческом английском языке, где белым по синему всё подробно описано и объяснено. Самый сложный нюанс выбрать файловую систему для будущих томов и прописать сетевые настройки. (И самое главное не забыть пароль на root)
Четвертое посложнее.
Рецепт был выкопан в сети, опять же к слову, описание коего гуглиться второй ссылкой на первой страницы после официального сайта Proxmox.
Ссылку на него не привожу за ненадобностью а рецепт в кратце опишу.
Распаковываем архив резервной копии:
tar xvfz vzdump-qemu-101-2010_08_28-13_41_10.tgzВ архива находится два файла:
qemu-server.conf — конфигурация виртуальной машины;
vm-disk-virtio0(1,2,3 и тд).raw — образ(ы) диска виртуальной машины.
Вот что представляет собой файл конфигурации:
name: mail
ide2: local:iso/debian-505-amd64-CD-1.iso,media=cdrom
vlan0: virtio=82:15:30:A4:65:E7
bootdisk: virtio0
virtio0: local:516/vm-516-disk-1.raw
ostype: l26
memory: 1024
onboot: 1
sockets: 1
vlan1: virtio=42:45:F5:F2:95:A8
cores: 1
boot: cad
freeze: 0
cpuunits: 2000
acpi: 1
kvm: 1
lock: backup
(По файлу думаю всё ясно и объяснять, что тут что не нужно)
Меняем имя файла образа:
mv vm-disk-virtio0.raw vm-516-disk-1.rawКопируем его в указаное в конфигурации место.
Меняем имя файла конфигурации:
mv qemu-server.conf 516.confКопируем его в папку /etc/qemu-server/ и комментируем последнюю строчку lock: backup.
Все, запускаем виртуальную машину.