После ввода в эксплуатацию хоста с ESXi и миграции на него нескольких серверов сразу же встал вопрос о резервном копировании виртуальных машин. Много подводных камней встретилось на пути, да и гугл подсказывал малыми порциями, поэтому и решил поделиться опытом.
Итак, нужна NFS шара, чтоб подключить её как storage. На единственном сервере, у которого есть свободные три с лишним терабайта, установлен MS Server 2008 — чтож, устанавливаем службы для NFS, расшариваем папку, подключаем storage, пробуем скопировать на него выключеную виртуалку… Результат, мягко говоря, печальный. Ищем решение проблемы — оказывается службы для NFS можно «тюнинговать» (почему я не удивлён), но по отзывам «тюнинг» даёт лишь 20-25% прирост скорости. Мы пойдём другим путём — берём первый попавшийся под («горячую») руку комп, устанавливаем в него три терабайтника (к слову далеко не лучших — WD Caviar Green, но других не было). Инсталлируем debian 6 на родной хард, раздел подкачки не используем, три терабайтника объединяем в RAID 0 (программный), форматируем в XFS и монтируем в /mnt/backup. Обясняю такой выбор: debian — так как уже работал с этим дистрибутивом (на вкус и цвет ...), RAID 0 — естественно для скорости, XFS — образы виртуальных дисков имеют внушительный размер, а XFS лучше других файловых систем работает с большими файлами (сравнивал на том же RAID 0 с EXT3 и EXT4 (largefile4) — на XFS скорость записи файлов выше, а именно скорость записи нас в данном случае и интересует), так как XFS активно использует оперативную память было решено отказатся от раздела подкачки, за правильность рассуждений не ручаюсь, но предположил, что он может служить тормозом. Выполняем в консоли «dd if=/dev/zero of=/mnt/backup/temp bs=1M count=10K» и видим скорость записи ~200 МВ/s что меня приятно удивило, я ожидал худших результатов. Создаём пользователя backup, делаем его владельцем /mnt/backup, устанавливаем nfs-kernel-server, добавляем в /etc/exports строку "/mnt/backup 192.168.1.5(rw,async,all_squash,anonuid=1001,anongid=1001,no_subtree_check)" где 192.168.1.5 это ip хоста с ESXi, async и no_subtree_check уменьшают время отклика сервера (лучше использовать sync и subtree_check, но в данном случае я гнался за скоростью), all_squash, anonuid=1001 и anongid=1001 указывают пользователя и его группу, с правами которого будет работать клиент (в нашем случае пользователь backup и группа backup). Перезагружаем службу nfs и подключаем шару как storage, пробуем скопировать виртуалку — совсем другое дело, копирование прошло в разы быстрее, нежели на виндовую nfs шару.
Небольшой тест:
Локальная сеть — гигабит.
На локальное хранилище (аппаратный RAID 10 из 4 дисков 10К) — «time dd if=/dev/zero of=/vmfs/volumes/datastore/temp bs=1M count=1K» 8 секунд.
На «linux» хранилище (программный RAID 0 из 3 дисков 7,5К) — «time dd if=/dev/zero of=/vmfs/volumes/linbackup/temp bs=1M count=1K» 12 секунд.
На «windows» хранилище (аппаратный RAID 5 из 10 дисков 10К) — «time dd if=/dev/zero of=/vmfs/volumes/winbackup/temp bs=1M count=1K» 1 минута 44 секунды (сам в шоке).
Результаты говорят сами за себя. Да, на win-хранилище RAID 5, но врядли он один виноват в таком результате.
С СХД разобрались, теперь надо автоматизировать резервное копирование. Лучшим бесплатным средством является скрипт ghettoVCB, чтобы им воспользоваться, надо получить доступ к хосту ESXi по SSH. Как оказалось есть очень простой способ включения и выключения доступа прямо из vShere Client: Configuration > Software > Security Profile > Properties… > Remote Tech Support (SSH) > Options… > Start или Stop. По этим скриншотам думаю будет нагляднее:
Скачиваем последнюю версию скрипта. Можно пойти «тру» путём сделать как написано на страничке скрипта в секции «Setup:», но я поступил проще — распаковал архив у себя на компьютере, вместо редактирования конфигурационного файла — отредактировал сам скрипт, скопировал его на локальное хранилище (через «Browse Datastore»).
Вот основные параметры:
VM_BACKUP_VOLUME — путь к папке бэкапов, в моём случае /vmfs/volumes/linbackup
DISK_BACKUP_FORMAT — формат диска, thin для бэкапов подходит лучше всего
VM_BACKUP_ROTATION_COUNT — количество хранимых бэкапов (для каждой виртуальной машины), у меня 2
ADAPTER_FORMAT — тип адаптера, у меня lsilogic
Остальные параметры можно и не править, но если интересно — на страничке скрипта все параметры подробно описаны, правда на английском, вот тут почти все параметры расписаны по русски.
Итак, скрипт скопирован на локальное хранилище, подключаемся по ssh, переносим скрипт куда нибудь ближе к корню, например в /ghettovcb/ghettovcb.sh, если вам не нужно бэкапить все виртуальные машины — необходимо создать файл со списком бэкапируемых виртуалок:
cd /ghettovcb
vi vmlist
жмём «a» вписываем имена виртуалок, каждое на новой строке, нажимаем «esc» и чтобы сохранить изменения ":wq" или чтоб выйти без сохранения ":q"
Переносы строк должны быть "\n", при переносах "\r\n" скрипт будет выдавать ошибку, поэтому не стоит создавать список в блокноте, с последующим копированием на хранилище, если вы ни разу не пользовались Notepad+ или EmEditor и не знаете что такое "\n" и "\r\n" — лучше создавайте список в vi.
Пробуем запустить скрипт:
./ghettovcb.sh -f ./vmlist -l ./log.txt
или если вы создали файл конфигурации
./ghettovcb.sh -f ./vmlist -g ./ghettovcb.conf -l ./log.txt
Скрипт отрабатывает, выдавая много информации, если в конце вывода видим "###### Final status: All VMs backed up OK! ######" значит всё хорошо, иначе — читаем log.txt и разбираемся что сделали не так.
Теперь надо создать расписание для бэкапов.
cd /var/spool/cron/crontabs
chmod u+w root
vi root
жмём «a», пишем расписание, только учтите — время указывается в UTC, т.е. для Москвы это локальное время минус три часа
00 20 * * * /ghettovcb/ghettovcb.sh -f /ghettovcb/vmlist -l /vmfs/volumes/linbackup/logs/`date +%F`.txt
или если вы создали файл конфигурации
00 20 * * * /ghettovcb/ghettovcb.sh -f /ghettovcb/vmlist -g /ghettovcb/ghettovcb.conf -l /vmfs/volumes/linbackup/logs/`date +%F`.txt
жмём «esc» и сохраняемся ":wq"
в заключении
chmod u-w root
Теперь ежедневно в 20:00 по UTC (в 23:00 по Москве) будет запускаться скрипт, логи о его выполнении будут сохранятся на хранилище в папке logs, отдельный лог на каждый день.
По логам у меня на бэкап уходит примерно 4 часа, посчитал скорость — примерно 4ГБ в минуту, т.е. примерно 70МБ в секунду, весьма не плохо. Хранилища в 2,7ТБ хватает на хранение двух копий каждой виртуалки, этого вполне достаточно, плюс остаётся свободное место, а оно нужно, т.к. сначала делается третья резервная копия и только после её создания удаляется самая старая копия.
Ну и ещё один камень в огород «windows» хранилища — пробовал делать бэкапы скриптом на него, storage просто отваливался, ну и собственно скрипт завершался с ошибкой. Понимаю, что всё дело в неверной настройки записи по NFS, но настройки были по умолчанию и разбираться в «тюнинге» не очень то и хотелось.
Эксперимент прошёл удачно, можно закупать сервер с хорошими дисками, планируется RAID 10 на 5ТБ, этого должно с запасом хватить и на будущие виртуалки.
Итак, нужна NFS шара, чтоб подключить её как storage. На единственном сервере, у которого есть свободные три с лишним терабайта, установлен MS Server 2008 — чтож, устанавливаем службы для NFS, расшариваем папку, подключаем storage, пробуем скопировать на него выключеную виртуалку… Результат, мягко говоря, печальный. Ищем решение проблемы — оказывается службы для NFS можно «тюнинговать» (почему я не удивлён), но по отзывам «тюнинг» даёт лишь 20-25% прирост скорости. Мы пойдём другим путём — берём первый попавшийся под («горячую») руку комп, устанавливаем в него три терабайтника (к слову далеко не лучших — WD Caviar Green, но других не было). Инсталлируем debian 6 на родной хард, раздел подкачки не используем, три терабайтника объединяем в RAID 0 (программный), форматируем в XFS и монтируем в /mnt/backup. Обясняю такой выбор: debian — так как уже работал с этим дистрибутивом (на вкус и цвет ...), RAID 0 — естественно для скорости, XFS — образы виртуальных дисков имеют внушительный размер, а XFS лучше других файловых систем работает с большими файлами (сравнивал на том же RAID 0 с EXT3 и EXT4 (largefile4) — на XFS скорость записи файлов выше, а именно скорость записи нас в данном случае и интересует), так как XFS активно использует оперативную память было решено отказатся от раздела подкачки, за правильность рассуждений не ручаюсь, но предположил, что он может служить тормозом. Выполняем в консоли «dd if=/dev/zero of=/mnt/backup/temp bs=1M count=10K» и видим скорость записи ~200 МВ/s что меня приятно удивило, я ожидал худших результатов. Создаём пользователя backup, делаем его владельцем /mnt/backup, устанавливаем nfs-kernel-server, добавляем в /etc/exports строку "/mnt/backup 192.168.1.5(rw,async,all_squash,anonuid=1001,anongid=1001,no_subtree_check)" где 192.168.1.5 это ip хоста с ESXi, async и no_subtree_check уменьшают время отклика сервера (лучше использовать sync и subtree_check, но в данном случае я гнался за скоростью), all_squash, anonuid=1001 и anongid=1001 указывают пользователя и его группу, с правами которого будет работать клиент (в нашем случае пользователь backup и группа backup). Перезагружаем службу nfs и подключаем шару как storage, пробуем скопировать виртуалку — совсем другое дело, копирование прошло в разы быстрее, нежели на виндовую nfs шару.
Небольшой тест:
Локальная сеть — гигабит.
На локальное хранилище (аппаратный RAID 10 из 4 дисков 10К) — «time dd if=/dev/zero of=/vmfs/volumes/datastore/temp bs=1M count=1K» 8 секунд.
На «linux» хранилище (программный RAID 0 из 3 дисков 7,5К) — «time dd if=/dev/zero of=/vmfs/volumes/linbackup/temp bs=1M count=1K» 12 секунд.
На «windows» хранилище (аппаратный RAID 5 из 10 дисков 10К) — «time dd if=/dev/zero of=/vmfs/volumes/winbackup/temp bs=1M count=1K» 1 минута 44 секунды (сам в шоке).
Результаты говорят сами за себя. Да, на win-хранилище RAID 5, но врядли он один виноват в таком результате.
С СХД разобрались, теперь надо автоматизировать резервное копирование. Лучшим бесплатным средством является скрипт ghettoVCB, чтобы им воспользоваться, надо получить доступ к хосту ESXi по SSH. Как оказалось есть очень простой способ включения и выключения доступа прямо из vShere Client: Configuration > Software > Security Profile > Properties… > Remote Tech Support (SSH) > Options… > Start или Stop. По этим скриншотам думаю будет нагляднее:
Скачиваем последнюю версию скрипта. Можно пойти «тру» путём сделать как написано на страничке скрипта в секции «Setup:», но я поступил проще — распаковал архив у себя на компьютере, вместо редактирования конфигурационного файла — отредактировал сам скрипт, скопировал его на локальное хранилище (через «Browse Datastore»).
Вот основные параметры:
VM_BACKUP_VOLUME — путь к папке бэкапов, в моём случае /vmfs/volumes/linbackup
DISK_BACKUP_FORMAT — формат диска, thin для бэкапов подходит лучше всего
VM_BACKUP_ROTATION_COUNT — количество хранимых бэкапов (для каждой виртуальной машины), у меня 2
ADAPTER_FORMAT — тип адаптера, у меня lsilogic
Остальные параметры можно и не править, но если интересно — на страничке скрипта все параметры подробно описаны, правда на английском, вот тут почти все параметры расписаны по русски.
Итак, скрипт скопирован на локальное хранилище, подключаемся по ssh, переносим скрипт куда нибудь ближе к корню, например в /ghettovcb/ghettovcb.sh, если вам не нужно бэкапить все виртуальные машины — необходимо создать файл со списком бэкапируемых виртуалок:
cd /ghettovcb
vi vmlist
жмём «a» вписываем имена виртуалок, каждое на новой строке, нажимаем «esc» и чтобы сохранить изменения ":wq" или чтоб выйти без сохранения ":q"
Переносы строк должны быть "\n", при переносах "\r\n" скрипт будет выдавать ошибку, поэтому не стоит создавать список в блокноте, с последующим копированием на хранилище, если вы ни разу не пользовались Notepad+ или EmEditor и не знаете что такое "\n" и "\r\n" — лучше создавайте список в vi.
Пробуем запустить скрипт:
./ghettovcb.sh -f ./vmlist -l ./log.txt
или если вы создали файл конфигурации
./ghettovcb.sh -f ./vmlist -g ./ghettovcb.conf -l ./log.txt
Скрипт отрабатывает, выдавая много информации, если в конце вывода видим "###### Final status: All VMs backed up OK! ######" значит всё хорошо, иначе — читаем log.txt и разбираемся что сделали не так.
Теперь надо создать расписание для бэкапов.
cd /var/spool/cron/crontabs
chmod u+w root
vi root
жмём «a», пишем расписание, только учтите — время указывается в UTC, т.е. для Москвы это локальное время минус три часа
00 20 * * * /ghettovcb/ghettovcb.sh -f /ghettovcb/vmlist -l /vmfs/volumes/linbackup/logs/`date +%F`.txt
или если вы создали файл конфигурации
00 20 * * * /ghettovcb/ghettovcb.sh -f /ghettovcb/vmlist -g /ghettovcb/ghettovcb.conf -l /vmfs/volumes/linbackup/logs/`date +%F`.txt
жмём «esc» и сохраняемся ":wq"
в заключении
chmod u-w root
Теперь ежедневно в 20:00 по UTC (в 23:00 по Москве) будет запускаться скрипт, логи о его выполнении будут сохранятся на хранилище в папке logs, отдельный лог на каждый день.
По логам у меня на бэкап уходит примерно 4 часа, посчитал скорость — примерно 4ГБ в минуту, т.е. примерно 70МБ в секунду, весьма не плохо. Хранилища в 2,7ТБ хватает на хранение двух копий каждой виртуалки, этого вполне достаточно, плюс остаётся свободное место, а оно нужно, т.к. сначала делается третья резервная копия и только после её создания удаляется самая старая копия.
Ну и ещё один камень в огород «windows» хранилища — пробовал делать бэкапы скриптом на него, storage просто отваливался, ну и собственно скрипт завершался с ошибкой. Понимаю, что всё дело в неверной настройки записи по NFS, но настройки были по умолчанию и разбираться в «тюнинге» не очень то и хотелось.
Эксперимент прошёл удачно, можно закупать сервер с хорошими дисками, планируется RAID 10 на 5ТБ, этого должно с запасом хватить и на будущие виртуалки.