19.08.2015 02:39
Lelik13a 26 6078 Источник
В этой статье я пошагово опишу настройку автоматического резервного копирования и пример восстановления виртуальных машин, работающих на платформе ESX(i) с помощью свободных скриптов ghettoVCB. Акцентироваться буду на версии ESXi 5.x, но эти же средства работают и на версиях 3.5-6.x, правда для ранних версий настройки несколько отличаются. Бэкап будет производиться на NFS сервер. Отчёт о работе будет направлен в почту. Во время бэкапа делается снимок (snapshot) виртуальной машины (в том числе и работающей), сохраняются VMDK диски машины и снимок удаляется.
Проект ghettoVCB отлично документирован, но в процессе внедрения появились нюансы, которые и вылились в эту инструкцию. Надеюсь, статья будет полезна начинающим администраторам.



  1. Настройка резервного копирования
  2. Сохранение конфигурации сервера ESXi
  3. Восстановление машины из резервной копии
  4. Ссылки


Настройка резервного копирования


Первым делом приготовьте NFS сервер по вкусу, куда будут производится бэкапы. В моём случае это FreeNAS (Freebsd 9.3) и ZFS dataset с включённой дедубликацией и сжатием, что существенно экономит место. Настройка на ESXi сервере производится по SSH от пользователя root. Можно и под другим пользователем с административными правами, но тогда не получится запустить скрипты для проверки из консоли. Приступим.

1. Для настройки необходим доступ на сервер по SSH, включаем через vSphere client:
Configuration -> security profile -> properties -> SSH


2. Берём скрипты из github репозитория и помещаем содержимое на сервер. Обязательно ставим бит исполнения, иначе скрипты работать не будут:
# chmod u+x /ghettoVCB-master/ghettoVCB.sh
# chmod u+x /ghettoVCB-master/ghettoVCB-restore.sh


3. Бэкапить будем раз в неделю, с циклом 4 недели. Просроченные бэкапы будут удаляться. Прописываем соответствующий config-файл:
# cat /ghettoVCB-master/4week.conf
VM_BACKUP_VOLUME=/vmfs/volumes/backup
DISK_BACKUP_FORMAT=thin
#количество хранимых бэкапов
VM_BACKUP_ROTATION_COUNT=4
POWER_VM_DOWN_BEFORE_BACKUP=0
ENABLE_HARD_POWER_OFF=0
ITER_TO_WAIT_SHUTDOWN=3
POWER_DOWN_TIMEOUT=5
ENABLE_COMPRESSION=0
ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0
ENABLE_NON_PERSISTENT_NFS=1
UNMOUNT_NFS=1
# NFS сервер, куда будут лететь бэкапы
NFS_SERVER=10.1.3.101
NFS_MOUNT=/mnt/backup/vmware
NFS_LOCAL_NAME=backup
# папка на NFS сервере (для каждого ESXi своя)
NFS_VM_BACKUP_DIR=autobackup/vm01
SNAPSHOT_TIMEOUT=15
#настройки логирования в почту
EMAIL_LOG=1
EMAIL_SERVER=mail.core.local
EMAIL_SERVER_PORT=25
EMAIL_DELAY_INTERVAL=1
EMAIL_TO=admins@mail.local
EMAIL_FROM=ghettoVCB@vm01.core.local
WORKDIR_DEBUG=0
VM_SHUTDOWN_ORDER=
VM_STARTUP_ORDER=
Где ключевые параметры:
  • VM_BACKUP_VOLUME — путь на сервере ESXi, куда будет монтироваться nfs раздел;
  • DISK_BACKUP_FORMAT=thin — формат VMDK диска, который будет создан при бэкапе;
  • VM_BACKUP_ROTATION_COUNT — количество хранимых бэкапов;
  • POWER_VM_DOWN_BEFORE_BACKUP=0 — не выключаем машину перед бэкапом;
  • ENABLE_COMPRESSION=0 — не жмём данные, оставляем это на zfs;
  • ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0 – бэкап машин со снапшотами (последние версии скриптов это умеют, но нам не надо);
  • ENABLE_NON_PERSISTENT_NFS=1 — nfs диск будет подключатся только на время бэкапа;
  • UNMOUNT_NFS=1 — а после отключатся;
  • NFS_SERVER и NFS_MOUNT – координаты nfs диска;
  • NFS_LOCAL_NAME — имя, которое будет присвоено подключенному массиву (datastores identification);
  • NFS_VM_BACKUP_DIR — путь, куда будут складываться копии (относительно VM_BACKUP_VOLUME);
  • EMAIL_LOG=1 — включаем отправку отчёта по почте;
  • EMAIL_* — настройки параметров почты.

Если на сервере ESXi уже есть подключенный nfs диск с такими же координатами (сервер/путь), то диск не подключится.

Тело письма формируется во время работы скрипта, а затем отсылается утилитой nc. Это может вызвать отказ со стороны почтового сервера, с аргументом "Recipient address rejected: Improper use of SMTP command pipelining". Нужно исключить соответствующую проверку для серверов ESXi (у postfix-а это будет reject_unauth_pipelining).

4. Создаём список машин, которые необходимо бэкапить. Получить его можно с помощью команды esxcli vm process list. Каждая строчка списка — одна машина:
# cat /ghettoVCB-master/week.list
win7
win10
vCenterUpdate
Если нужно несколько планов бэкапов, с разной периодичностью и параметрами — создаём необходимое количество конфигураций.

5. Настраиваем cron на выполнение периодической задачи:
# cat /var/spool/cron/crontabs/root
#min hour day mon dow command
#……………………….

3    18   *   *   6     /ghettoVCB-master/ghettoVCB.sh -g /ghettoVCB-master/4week.conf -f /ghettoVCB-master/week.list > /var/log/ghettoVCB-backup-week-$((($(date +\%d)-1)/7+1)).log

Системное время идёт в UTC, потому необходимо делать поправку на текущий часовой пояс. В моём случае +7 часов — бэкап запустится в воскресенье в 1 час ночи. Логи писать обязательно (или переправлять в /dev/null), иначе при переполнении буфера, отведённого для пользователя, скрипт может зависнуть. Конструкция $((($(date +\%d)-1)/7+1)) выдаёт номер недели в месяце, таким образом не наплодим мусора.

6. Перезапускаем cron:
# kill $(cat /var/run/crond.pid)
# crond


7. Для отправки почты необходимо добавить разрешение на исходящий трафик в firewall сервера ESXi:
  • создаём файл настройки с содержимым:
    # cat /etc/vmware/firewall/email.xml
<ConfigRoot>
  <service>
    <id>email</id>
    <rule id="0000">
      <direction>outbound</direction>
      <protocol>tcp</protocol>
      <porttype>dst</porttype>
      <port>25</port>
    </rule>
    <enabled>true</enabled>
    <required>false</required>
  </service>
</ConfigRoot>

  • перечитываем правила файрвола проверяем:
    # esxcli network firewall refresh
# esxcli network firewall ruleset list | grep email
email                  true
# nc mail.core.local 25
220 mail.core.local SMTP Postfix
quit
221 2.0.0 Bye



Запустить тестовую проверку бэкапа машины с именем «vCenterUpdate» можно следующим образом:
# /ghettoVCB-master/ghettoVCB.sh -g /ghettoVCB-master/4week.conf -d dryrun -m vCenterUpdate
Вывод:
# /ghettoVCB-master/ghettoVCB.sh -g /ghettoVCB-master/4week.conf -d dryrun -m vCenterUpdate
Logging output to "/tmp/ghettoVCB-2015-08-18_07-15-08-23516502.log" ...
2015-08-18 07:15:09 -- info: ============================== ghettoVCB LOG START ==============================

2015-08-18 07:15:09 -- info: CONFIG - USING GLOBAL GHETTOVCB CONFIGURATION FILE = /ghettoVCB-master/4week.conf
2015-08-18 07:15:09 -- info: CONFIG - VERSION = 2015_05_06_1
2015-08-18 07:15:09 -- info: CONFIG - GHETTOVCB_PID = 23516502
2015-08-18 07:15:09 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/backup/autobackup/vm01
2015-08-18 07:15:09 -- info: CONFIG - ENABLE_NON_PERSISTENT_NFS = 1
2015-08-18 07:15:09 -- info: CONFIG - UNMOUNT_NFS = 1
2015-08-18 07:15:09 -- info: CONFIG - NFS_SERVER = 10.1.3.101
2015-08-18 07:15:09 -- info: CONFIG - NFS_VERSION = nfs
2015-08-18 07:15:09 -- info: CONFIG - NFS_MOUNT = /mnt/backup/vmware
2015-08-18 07:15:09 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 4
2015-08-18 07:15:09 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2015-08-18_07-15-08
2015-08-18 07:15:09 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2015-08-18 07:15:09 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2015-08-18 07:15:09 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2015-08-18 07:15:09 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2015-08-18 07:15:09 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2015-08-18 07:15:09 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2015-08-18 07:15:09 -- info: CONFIG - LOG_LEVEL = dryrun
2015-08-18 07:15:09 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2015-08-18_07-15-08-23516502.log
2015-08-18 07:15:09 -- info: CONFIG - ENABLE_COMPRESSION = 0
2015-08-18 07:15:09 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2015-08-18 07:15:09 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2015-08-18 07:15:09 -- info: CONFIG - ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP = 0
2015-08-18 07:15:09 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2015-08-18 07:15:09 -- info: CONFIG - VM_SHUTDOWN_ORDER =
2015-08-18 07:15:09 -- info: CONFIG - VM_STARTUP_ORDER =
2015-08-18 07:15:09 -- info: CONFIG - RSYNC_LINK = 0
2015-08-18 07:15:09 -- info: CONFIG - EMAIL_LOG = 1
2015-08-18 07:15:09 -- info: CONFIG - EMAIL_SERVER = mail.core.local
2015-08-18 07:15:09 -- info: CONFIG - EMAIL_SERVER_PORT = 25
2015-08-18 07:15:09 -- info: CONFIG - EMAIL_DELAY_INTERVAL = 2
2015-08-18 07:15:09 -- info: CONFIG - EMAIL_FROM = ghettoVCB@vm02.core.local
2015-08-18 07:15:09 -- info: CONFIG - EMAIL_TO = admins@mail.local
2015-08-18 07:15:09 -- info: CONFIG - WORKDIR_DEBUG = 0
2015-08-18 07:15:09 -- info:
2015-08-18 07:15:10 -- dryrun: ###############################################
2015-08-18 07:15:10 -- dryrun: Virtual Machine: vCenterUpdate
2015-08-18 07:15:10 -- dryrun: VM_ID: 588
2015-08-18 07:15:10 -- dryrun: VMX_PATH: /vmfs/volumes/ds3524_ds/vCenterUpdate/vCenterUpdate.vmx
2015-08-18 07:15:10 -- dryrun: VMX_DIR: /vmfs/volumes/ds3524_ds/vCenterUpdate
2015-08-18 07:15:10 -- dryrun: VMX_CONF: vCenterUpdate/vCenterUpdate.vmx
2015-08-18 07:15:10 -- dryrun: VMFS_VOLUME: ds3524_ds
2015-08-18 07:15:10 -- dryrun: VMDK(s):
2015-08-18 07:15:10 -- dryrun:  vCenterUpdate.vmdk      40 GB
2015-08-18 07:15:10 -- dryrun: INDEPENDENT VMDK(s):
2015-08-18 07:15:10 -- dryrun: TOTAL_VM_SIZE_TO_BACKUP: 40 GB
2015-08-18 07:15:10 -- dryrun: ###############################################

2015-08-18 07:15:10 -- info: ###### Final status: OK, only a dryrun. ######

2015-08-18 07:15:10 -- info: ============================== ghettoVCB LOG END ================================



Запустить в ручную для списка машин:
# /ghettoVCB-master/ghettoVCB.sh -g /ghettoVCB-master/4week.conf -f /ghettoVCB-master/week.list

Каждая копия машин будет хранится в директориях, вида: 
autobackup/vm01/VMNAME/VMNAME-FULL_DATE/

И представлять из себя диск машины в формате *.vmdk и файл конфигурации машины *.vmx.

Сохранение конфигурации сервера ESXi


Настройки ESXi, произведённые выше, будут жить до первой перезагрузки. Для сохранения конфигурации нужно сделать ещё ряд действий.

1. Добавим в загрузочный скрипт команды на изменение настроек cron-а:
# cat /etc/rc.local.d/local.sh
#...................
/bin/kill $(cat /var/run/crond.pid)
/bin/echo "3    18   *   *   6     /ghettoVCB-master/ghettoVCB.sh -g /ghettoVCB-master/4week.conf -f /ghettoVCB-master/week.list > /var/log/ghettoVCB-backup-week-$((($(date +\%d)-1)/7+1)).log" >> /var/spool/cron/crontabs/root
/bin/busybox crond


2. Для сохранения настроек файрвола сделаем собственный VIB пакет и установим его на сервер. Для этого используем утилиту VIB Author. К сожалению, она только для 32-х битной архитектуры, поэтому мне пришлось воспользоваться lxc контейнером. При установке может страшно ругаться на зависимости вида:
# rpm -ivh vmware-esx-vib-author-5.0.0-0.0.847598.i386.rpm
error: Failed dependencies:
        libc.so.6()(64bit) is needed by vmware-esx-vib-author-5.0.0-0.0.847598.i386
        libc.so.6(GLIBC_2.2.5)(64bit) is needed by vmware-esx-vib-author-5.0.0-0.0.847598.i386
        libc.so.6(GLIBC_2.3)(64bit) is needed by vmware-esx-vib-author-5.0.0-0.0.847598.i386
        libc.so.6(GLIBC_2.4)(64bit) is needed by vmware-esx-vib-author-5.0.0-0.0.847598.i386
        libdl.so.2()(64bit) is needed by vmware-esx-vib-author-5.0.0-0.0.847598.i386
        libdl.so.2(GLIBC_2.2.5)(64bit) is needed by vmware-esx-vib-author-5.0.0-0.0.847598.i386
        libpthread.so.0()(64bit) is needed by vmware-esx-vib-author-5.0.0-0.0.847598.i386
        libpthread.so.0(GLIBC_2.2.5)(64bit) is needed by vmware-esx-vib-author-5.0.0-0.0.847598.i386

Но это не беда, и ключ rpm --nodeps нас спасёт.

Подготавливаем дерево директорий для сборки VIB пакета:
# mkdir -p stage/payloads/payload1/etc/vmware/firewall/

И создаём два файла. Первый — описание нашего пакета:
# cat stage/descriptor.xml
<vib version="5.0">
  <type>bootbank</type>
  <name>mailFirewall</name>
  <version>5.0.0-0.0.1</version>
  <vendor>Lelik.13a</vendor>
  <summary>Custom VIB from Lelik.13a</summary>
  <description>Adds custom firewall rule for mail sender to ESXi host</description>
  <relationships>
    <depends>
    </depends>
    <conflicts/>
    <replaces/>
    <provides/>
    <compatibleWith/>
  </relationships>
  <software-tags>
  </software-tags>
  <system-requires>
    <maintenance-mode>false</maintenance-mode>
  </system-requires>
  <file-list>
  </file-list>
  <acceptance-level>community</acceptance-level>
  <live-install-allowed>true</live-install-allowed>
  <live-remove-allowed>true</live-remove-allowed>
  <cimom-restart>false</cimom-restart>
  <stateless-ready>true</stateless-ready>
  <overlay>false</overlay>
  <payloads>
    <payload name="payload1" type="vgz"></payload>
  </payloads>
</vib>
Подробную инструкцию к параметрам можно посмотреть на сайте утилиты.

И второй файл — email.xml, содержимое которого приведено выше. А находится он будет по пути stage/payloads/payload1/etc/vmware/firewall/email.xml, где путь после "payload1" – желаемый путь на целевом сервере.

Собираем VIB пакет:
# vibauthor -C -t stage -v mailFirewall.vib

И проверяем его содержимое
# vibauthor -i -v mailFirewall.vib
**** Info for VIB: mailFirewall.vib ****
VIB Format:             2.0.0
VIB ID:                 Lelik.13a_bootbank_mailFirewall_5.0.0-0.0.1
VIB Type:               bootbank
Name:                   mailFirewall
Version:                5.0.0-0.0.1
Vendor:                 Lelik.13a
Summary:                [Fling] Custom VIB from Lelik.13a
Description:            Adds custom firewall rule for mail sender to ESXi host
Creation Date:          2015-08-12 09:47:07.199735+00:00
Provides:
        mailFirewall = 5.0.0-0.0.1
Depends:
Conflicts:
Replaces:
        mailFirewall << 5.0.0-0.0.1
Software Tags:          []
MaintenanceMode:        remove/update: False, installation: False
Signed:                 False
AcceptanceLevel:        community
LiveInstallAllowed:     True
LiveRemoveAllowed:      True
CimomRestart:           False
StatelessReady:         True
Overlay:                False
Payloads:
  Name            Type        Boot Size        Checksums
  payload1        vgz         0    347         sha-256 69aa821faa4ccd5a5e34e487ecf6049aa6bf55652ffffbfaae1257e40610c405
                                               sha-1 4d77e529c8da74e82d4aa4e816bcf193e29ab8de


При нужде, можете воспользоваться моим пакетом (на свой страх и риск).

3. Копируем наш пакет на сервер ESXi, устанавливаем и проверяем, что получилось:
# esxcli software vib install -v /tmp/mailFirewall.vib -f
# esxcli software vib list | grep mail
# esxcli network firewall refresh
Так как пакет добавляет свои файлы в систему, то необходимо использование ключа "-f".
И на всякий случай, перечитываем правила файрвола.

Таким образом можно собрать и зафиксировать и другие полезные настройки сервера.

4. И в завершение, запускаем в ручную бэкап настроек сервера ESXi:
# /sbin/auto-backup.sh


Восстановление машины из резервной копии


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

1. Подключаем хранилище с бэкапом на целевой ESXi сервер по NFS, либо просто копируем туда данные по ssh.

2. Создаём конфигурационный файл «vms_to_restore» такого вида:
# cat /ghettoVCB-master/vms_to_restore
#"<DIRECTORY or .TGZ>;<DATASTORE_TO_RESTORE_TO>;<DISK_FORMAT_TO_RESTORE>"
# DISK_FORMATS
# 1 = zeroedthick
# 2 = 2gbsparse
# 3 = thin
# 4 = eagerzeroedthick
# e.g.
"/vmfs/volumes/restore/autobackup/vm01/vCenterUpdate/vCenterUpdate-2015-08-13_07-55-50/;/vmfs/volumes/local_vm01/;3;vCenterUpdate-restore"
Где по порядку через ";":
  • путь, где лежит восстанавливаемая машина;
  • путь, куда восстановить машину (директория под неё будет создана);
  • тип диска машины для восстановления;
  • новое имя машины (не обязательно).


3. Запускаем тестовый прогон:
# /ghettoVCB-master/ghettoVCB-restore.sh  -c /ghettoVCB-master/vms_to_restore -d 1

И боевой:
# /ghettoVCB-master/ghettoVCB-restore.sh  -c /ghettoVCB-master/vms_to_restore -l /var/log/vms-restore.log
################## Restoring VM: vCenterUpdate-restore  #####################
Start time: Fri Aug 14 06:05:06 UTC 2015
Restoring VM from: "/vmfs/volumes/restore/autobackup/vm01/vCenterUpdate/vCenterUpdate-2015-08-13_07-55-50/"
Restoring VM to Datastore: "/vmfs/volumes/local_vm01/" using Disk Format: "thin"
Creating VM directory: "/vmfs/volumes/local_vm01//vCenterUpdate-restore" ...
Copying "vCenterUpdate.vmx" file ...
Restoring VM's VMDK(s) ...
Updating VMDK entry in "vCenterUpdate-restore.vmx" file ...
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/restore/autobackup/vm01/vCenterUpdate/vCenterUpdate-2015-08-13_07-55-50//vCenterUpdate.vmdk'...
Clone: 100% done.
Registering vCenterUpdate-restore ...
12
End time: Fri Aug 14 06:11:19 UTC 2015

4. Радуемся.

Второй вариант. Так как бэкап представляет собой дамп машины с конфигурационным файлом, то можно просто:

1. Cкопировать его куда-нибудь на ESXi сервер.

2. Исправить файл конфигурации машины (*.vmx), изменив поля имени и местоположения диска машины:
displayName = vCenterUpdate-restore
extendedConfigFile = "vCenterUpdate-restore.vmxf"
scsi0:0.fileName  = "vCenterUpdate-restore-0.vmdk"
sched.swap.derivedName = "vCenterUpdate-ff0c3749.vswp"
Пути до файлов можно (и нужно) указывать относительно директории машины.

3. Через vSphereClient идём в хранилище:
Configuration -> storage -> ПКМ -> "browse datastore"

и добавляем новую машину в список:
ПКМ -> "Add to inventory" на файле *.vmx

4. Если сервер восстановления другой, то в настройках машины меняем «Network Connection».

5. При первом запуске оно спросит, от куда нарисовалась машина, нужно ответить, что перенесли.
Если ответить, что клонировали — изменит уникальные данные, в том числе mac адрес сетевой карты.

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

Спасибо за внимание.

Cсылки


Комментарии (26)


  1. gotch
    19.08.2015 09:18
    #8541787

    Знатный велосипедик. Для кластеризации такого нет? :)


    1. Lelik13a
      19.08.2015 09:31
      #8541801

      Именно для кластера нет, но отлично работает на каждой ноде в отдельности. Собственно так и настраивал.


      1. gotch
        19.08.2015 09:39
        #8541807

        Да нет, я немного иронизирую, имеется в виду скрипт, который реализует High Availability без vCenter.


        1. Lelik13a
          19.08.2015 09:51
          #8541817

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


        1. ls1
          19.08.2015 10:17
          #8541843

          Если бы у меня стояла цель выбрать бесплатное кластерное решение, я бы выбрал CentOS 7.1 + опенсорсный oVirt
          wiki.centos.org/HowTos/oVirt
          www.ovirt.org/Home


          1. gotch
            20.08.2015 16:18
            #8543537

            Любопытно, а как там обстоят дела с кластерной файловой системой?


            1. Lelik13a
              20.08.2015 16:44
              #8543603

              У CentOS-а хорошо.
              access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/High_Availability_Add-On_Overview/index.html
              Тот же gfs2 из коробки, CLVM.
              Правда, как и чем работает oVirt пока не знаю — не изучал.

              RedHat продвигает своё решение на базе kvm — тоже большой простор для изучения.
              access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/index.html


              1. gotch
                20.08.2015 18:20
                #8543715

                RedHat с его стоимостью лицензий и политикой поддержки может и дальше продвигать, уж лучше Nutanix какой-нибудь. :)


                1. Lelik13a
                  20.08.2015 18:35
                  #8543733

                  Не совсем корректное сравнение. oVirt или RedHat cluster, который никто не мешает использовать на базе соответствующего CentOS с одной стороны и платная поддержка за сервис или решения из коробки с другой.


                  1. gotch
                    20.08.2015 19:34
                    #8543821

                    То есть Red Hat Cluster входит в дистрибутив CentOS?
                    Вы только не смейтесь, наберитесь чуть терпения, эта область мне совершенно неизвестна.


                    1. Lelik13a
                      21.08.2015 05:16
                      #8544271

                      Все компоненты, из которых он состоит, входят. RedHat продаёт поддержку.
                      Сам я cluster на базе KVM не разворачивал, но в документации по разворачиванию не вижу привязки именно к RedHat-у, всё необходимое есть и в CentOS.

                      Я собирал HA Cluster по документации RedHat-а с использованием Pacemaker-а на CentOS и тоже в какие-либо ограничения не наткнулся.

                      Правда, есть RedHat Linux Atomic Host, ориентированный на использование Docker контейнеров, и тут в документации они акцентируются на подписке. Но опять же не ясно, на сколько будет ограничено использование без неё. Есть подозрение, что подписка даёт только доступ к RedHat-репозиторию docker-контейнеров.

                      В общем, документация RedHat-а + CentOS — отличная база для смелых, интересных и дешёвых экспериментов.


            1. ls1
              20.08.2015 17:17
              #8543623

              Любопытно, а как там обстоят дела с кластерной файловой системой?
              Что вы имеете в виду?
              GlusterFS поддерживается, но необходимости в ней нет, будет работать и с NFS. А обычно всё же образы шарят не на NAS а на SAN стореджах (блочных устройствах) по протоколам iSCSI или FC


              1. gotch
                20.08.2015 18:23
                #8543719

                С NFS понятно, а вот обычная кластерная файловая система, когда у вас один блочный сторейдж по протоколу iSCSI или FC подключен одновременно к, например, 4 хостам и машина А запущена на сервере А, Б на Б, и т.д. У Microsoft это CSV, у VMware — VMFS. А в мире где каждый сам выбирает себе что-нибудь подходящее, не глючное и не заброшенное 5 лет назад, что это?


                1. Lelik13a
                  20.08.2015 18:30
                  #8543727

                  GFS2?


                  1. gotch
                    20.08.2015 19:33
                    #8543815

                    Выглядит неплохо, не специалист в этой области, почитаем.
                    Спасибо.


                1. ls1
                  20.08.2015 19:50
                  #8543835

                  когда у вас один блочный сторейдж по протоколу iSCSI или FC
                  Так там, AFAIK, не «кластерная ФС» а обычный LVM+костыль из метаданных.


                  1. ls1
                    20.08.2015 20:05
                    #8543847

                    www.ovirt.org/Vdsm_Block_Storage_Domains


    1. navion
      19.08.2015 19:33
      #8542571

      If (всё пропало)
      {
      New-VM -VMFilePath $_.DatastoreFullPath
      Start-VM
      }


      1. kumbr_87
        20.08.2015 01:02
        #8542791

        В случае если все пропало это может не сработать из за технологии… хммм… монопольного использования файлов виртуальной машины при которой в папке с машиной создаются lck файлы говорящие о том что файлы уже используются, соответственно если все пропало (например хост потерял связь с NFS сервером), эти lck файлы останутся лежать в папке и при добавлении машины хост выругается на то что файлы машины уже используются. Хотя в целом что то такое сделать можно. Вот статья vmware где рассматривается решение подобной проблемы с удержанием файла http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=10051

        там как раз есть отдельный раздел для NFS:

        Removing the .lck file (NFS only)

        The files on the virtual machine may be locked via NFS storage. You can identify this by files denoted with .lck-#### (where #### is the value of the fileid field returned from a GETATTR request for the file being locked) at the end of the file name. This is an NFS file lock and is only listed when using the ls -la command because it is hidden file (in versions of ESX/ESXi prior to 5.x). For more information, see Powering on a virtual machine on NFS or trying to remove an NFS Datastore fails with errors «Unable to access a file since it is locked» or «Resource is in use» (1012685).

        For more information on NFS file locking, see the VMware NFS Best Practices Whitepaper.

        Caution: These can be removed safely only if the virtual machine is not running.

        Note: VMFS volumes do not have .lck files. The locking mechanism for VMFS volumes is handled within VMFS metadata on the volume.


        1. navion
          20.08.2015 01:26
          #8542805

          Это скорее шутка, после Clustering Deepdive в голову не придёт пытаться сделать такое самому :-)


  1. navion
    19.08.2015 19:25
    #8542551

    Годное решение, если нет денег на самую простую версию лицензию VMware.
    А так лучше купить vSphere Essentials за 20 тыр на 3 хоста для доступа к API и заскриптовать Start-VBRZip в бесплатной Veeam B&R.


    1. yosemity
      19.08.2015 23:03
      #8542711

      Вообще-то уже давно не 20, а 50 с лишним (без подписки на год не продается).
      Но я с вами согласен, если есть 2-3 хоста, то смысл купить VMware vSphere Essentials однозначно есть. И дело не только в Veeam, много сопутствующих полезных фишек.


      1. navion
        20.08.2015 00:46
        #8542769

        На сайте просят 37к, интересно чем вызвана такая разница?


  1. mihmig
    20.08.2015 12:16
    #8543121

    А какая в Вас скорость копирования?
    Я пробовал подключать NFS-шару как хранилище к FreeNAS 8.2 (FreeBSD+ZFS) — скорость записи ~300 кбайт/с. (по iSCSI на этот же NAS — чуть быстрее, но меньше мегабайта в секунду)
    Выяснил, что:
    1. Проблема не в NAS (async на ZFS включён и запись со сторонней линуксовой машины ограничивается скоростью сети)
    2. Проблема в ESXi, т.к. шару он подключает принудительно в sync, и пишет блоками по 512 байт (не настраивается)
    Рекомендации:
    а) поставить кеширующий SSD
    б) пропатчить NFS-сервер на предмет игнорирования команды синхронной записи
    для меня невыполнимы…

    Посмотрел скрипт — там монтирование осуществляется командой:
    ${VMWARE_CMD} hostsvc/datastore/nas_create "${NFS_LOCAL_NAME}" "${NFS_SERVER}" "${NFS_MOUNT}" 0
    там нигде нет параметров async или размера блока…

    Сейчас остановился на варианте копирования по scp (авторизация по ключам) на linux-сервер — 33мбайт/с для гигабитной сети.


    1. Lelik13a
      20.08.2015 13:02
      #8543193
      +1

      Странно. Я на нескольких серверах и разных версиях разворачивал подобную схему, но нигде не натыкался на проблемы со скоростью. Сервером выступал как FreeNAS, так и CentOS разных версий. На FreeNAS сейчас работает сжатие и дедубликация. Параметры монтирования на FreeNAS:
      backup/vmware on /mnt/backup/vmware (zfs, NFS exported, local, noatime, nfsv4acls)

      Последний бэкап машин объёмом 159Г прошел за 3:30, то есть ~ 12.9Мб/с.

      Специально протестировал скорость на тот же сервер:
      # time dd if=/vmfs/volumes/local_vm02/iso/CentOS-6.5-x86_64-minimal.iso of=/vmfs/volumes/backup/tmp.data bs=1M
      398+0 records in
      398+0 records out
      real 0m 7.80s

      # du -h /vmfs/volumes/backup/tmp.data
      381.3M /vmfs/volumes/backup/tmp.data

      То есть 48Мб/с, что более чем достаточно.


    1. Lelik13a
      20.08.2015 15:25
      #8543391

      Я тут усиленно повспоминал и пришел к выводу, что раньше мог просто не заметить возможные тормоза. До этого использовал ESXi 5.5 с последующим обновлением до 5.6 и сервер nfs на CentOS 6.x. Виртуальные машины были не большие и не критичные, особо статистику не собирал, бэкапятся — да и ладно.
      На новом месте ESXi 5.1 и FreeNAS 9.3 — проблем не наблюдаю. Протестировать в других связках пока нет возможности. Но интересны результаты и решение. Надо будет поразбираться в вопросе.