Comments 26
Знатный велосипедик. Для кластеризации такого нет? :)
Именно для кластера нет, но отлично работает на каждой ноде в отдельности. Собственно так и настраивал.
Да нет, я немного иронизирую, имеется в виду скрипт, который реализует High Availability без vCenter.
Не натыкался. Но думаю, что при наличии общего хранилища велосипед сгородить можно. Просто машины с одной ноды на другую переносятся без проблем, осталось обвязать это некоторой автоматизацией.
Если бы у меня стояла цель выбрать бесплатное кластерное решение, я бы выбрал CentOS 7.1 + опенсорсный oVirt
wiki.centos.org/HowTos/oVirt
www.ovirt.org/Home
wiki.centos.org/HowTos/oVirt
www.ovirt.org/Home
Любопытно, а как там обстоят дела с кластерной файловой системой?
У 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
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
RedHat с его стоимостью лицензий и политикой поддержки может и дальше продвигать, уж лучше Nutanix какой-нибудь. :)
Не совсем корректное сравнение. oVirt или RedHat cluster, который никто не мешает использовать на базе соответствующего CentOS с одной стороны и платная поддержка за сервис или решения из коробки с другой.
То есть Red Hat Cluster входит в дистрибутив CentOS?
Вы только не смейтесь, наберитесь чуть терпения, эта область мне совершенно неизвестна.
Вы только не смейтесь, наберитесь чуть терпения, эта область мне совершенно неизвестна.
Все компоненты, из которых он состоит, входят. RedHat продаёт поддержку.
Сам я cluster на базе KVM не разворачивал, но в документации по разворачиванию не вижу привязки именно к RedHat-у, всё необходимое есть и в CentOS.
Я собирал HA Cluster по документации RedHat-а с использованием Pacemaker-а на CentOS и тоже в какие-либо ограничения не наткнулся.
Правда, есть RedHat Linux Atomic Host, ориентированный на использование Docker контейнеров, и тут в документации они акцентируются на подписке. Но опять же не ясно, на сколько будет ограничено использование без неё. Есть подозрение, что подписка даёт только доступ к RedHat-репозиторию docker-контейнеров.
В общем, документация RedHat-а + CentOS — отличная база для смелых, интересных и дешёвых экспериментов.
Сам я cluster на базе KVM не разворачивал, но в документации по разворачиванию не вижу привязки именно к RedHat-у, всё необходимое есть и в CentOS.
Я собирал HA Cluster по документации RedHat-а с использованием Pacemaker-а на CentOS и тоже в какие-либо ограничения не наткнулся.
Правда, есть RedHat Linux Atomic Host, ориентированный на использование Docker контейнеров, и тут в документации они акцентируются на подписке. Но опять же не ясно, на сколько будет ограничено использование без неё. Есть подозрение, что подписка даёт только доступ к RedHat-репозиторию docker-контейнеров.
В общем, документация RedHat-а + CentOS — отличная база для смелых, интересных и дешёвых экспериментов.
Любопытно, а как там обстоят дела с кластерной файловой системой?Что вы имеете в виду?
GlusterFS поддерживается, но необходимости в ней нет, будет работать и с NFS. А обычно всё же образы шарят не на NAS а на SAN стореджах (блочных устройствах) по протоколам iSCSI или FC
С NFS понятно, а вот обычная кластерная файловая система, когда у вас один блочный сторейдж по протоколу iSCSI или FC подключен одновременно к, например, 4 хостам и машина А запущена на сервере А, Б на Б, и т.д. У Microsoft это CSV, у VMware — VMFS. А в мире где каждый сам выбирает себе что-нибудь подходящее, не глючное и не заброшенное 5 лет назад, что это?
В случае если все пропало это может не сработать из за технологии… хммм… монопольного использования файлов виртуальной машины при которой в папке с машиной создаются lck файлы говорящие о том что файлы уже используются, соответственно если все пропало (например хост потерял связь с NFS сервером), эти lck файлы останутся лежать в папке и при добавлении машины хост выругается на то что файлы машины уже используются. Хотя в целом что то такое сделать можно. Вот статья vmware где рассматривается решение подобной проблемы с удержанием файла http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=10051
там как раз есть отдельный раздел для NFS:
там как раз есть отдельный раздел для 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.
Годное решение, если нет денег на самую простую версию лицензию VMware.
А так лучше купить vSphere Essentials за 20 тыр на 3 хоста для доступа к API и заскриптовать Start-VBRZip в бесплатной Veeam B&R.
А так лучше купить vSphere Essentials за 20 тыр на 3 хоста для доступа к API и заскриптовать Start-VBRZip в бесплатной Veeam B&R.
Вообще-то уже давно не 20, а 50 с лишним (без подписки на год не продается).
Но я с вами согласен, если есть 2-3 хоста, то смысл купить VMware vSphere Essentials однозначно есть. И дело не только в Veeam, много сопутствующих полезных фишек.
Но я с вами согласен, если есть 2-3 хоста, то смысл купить VMware vSphere Essentials однозначно есть. И дело не только в Veeam, много сопутствующих полезных фишек.
На сайте просят 37к, интересно чем вызвана такая разница?
А какая в Вас скорость копирования?
Я пробовал подключать 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мбайт/с для гигабитной сети.
Я пробовал подключать 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мбайт/с для гигабитной сети.
Странно. Я на нескольких серверах и разных версиях разворачивал подобную схему, но нигде не натыкался на проблемы со скоростью. Сервером выступал как 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Мб/с, что более чем достаточно.
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Мб/с, что более чем достаточно.
Я тут усиленно повспоминал и пришел к выводу, что раньше мог просто не заметить возможные тормоза. До этого использовал ESXi 5.5 с последующим обновлением до 5.6 и сервер nfs на CentOS 6.x. Виртуальные машины были не большие и не критичные, особо статистику не собирал, бэкапятся — да и ладно.
На новом месте ESXi 5.1 и FreeNAS 9.3 — проблем не наблюдаю. Протестировать в других связках пока нет возможности. Но интересны результаты и решение. Надо будет поразбираться в вопросе.
На новом месте ESXi 5.1 и FreeNAS 9.3 — проблем не наблюдаю. Протестировать в других связках пока нет возможности. Но интересны результаты и решение. Надо будет поразбираться в вопросе.
Sign up to leave a comment.
Резервное копирование виртуальных машин ESXi с помощью скриптов ghettoVCB