Pull to refresh

Comments 26

Знатный велосипедик. Для кластеризации такого нет? :)
Именно для кластера нет, но отлично работает на каждой ноде в отдельности. Собственно так и настраивал.
Да нет, я немного иронизирую, имеется в виду скрипт, который реализует High Availability без vCenter.
Не натыкался. Но думаю, что при наличии общего хранилища велосипед сгородить можно. Просто машины с одной ноды на другую переносятся без проблем, осталось обвязать это некоторой автоматизацией.
Любопытно, а как там обстоят дела с кластерной файловой системой?
У 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
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 — отличная база для смелых, интересных и дешёвых экспериментов.
Любопытно, а как там обстоят дела с кластерной файловой системой?
Что вы имеете в виду?
GlusterFS поддерживается, но необходимости в ней нет, будет работать и с NFS. А обычно всё же образы шарят не на NAS а на SAN стореджах (блочных устройствах) по протоколам iSCSI или FC
С NFS понятно, а вот обычная кластерная файловая система, когда у вас один блочный сторейдж по протоколу iSCSI или FC подключен одновременно к, например, 4 хостам и машина А запущена на сервере А, Б на Б, и т.д. У Microsoft это CSV, у VMware — VMFS. А в мире где каждый сам выбирает себе что-нибудь подходящее, не глючное и не заброшенное 5 лет назад, что это?
Выглядит неплохо, не специалист в этой области, почитаем.
Спасибо.
когда у вас один блочный сторейдж по протоколу iSCSI или FC
Так там, AFAIK, не «кластерная ФС» а обычный LVM+костыль из метаданных.
В случае если все пропало это может не сработать из за технологии… хммм… монопольного использования файлов виртуальной машины при которой в папке с машиной создаются 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.

Это скорее шутка, после Clustering Deepdive в голову не придёт пытаться сделать такое самому :-)
Годное решение, если нет денег на самую простую версию лицензию VMware.
А так лучше купить vSphere Essentials за 20 тыр на 3 хоста для доступа к API и заскриптовать Start-VBRZip в бесплатной Veeam B&R.
Вообще-то уже давно не 20, а 50 с лишним (без подписки на год не продается).
Но я с вами согласен, если есть 2-3 хоста, то смысл купить VMware vSphere Essentials однозначно есть. И дело не только в Veeam, много сопутствующих полезных фишек.
А какая в Вас скорость копирования?
Я пробовал подключать 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Мб/с, что более чем достаточно.
Я тут усиленно повспоминал и пришел к выводу, что раньше мог просто не заметить возможные тормоза. До этого использовал ESXi 5.5 с последующим обновлением до 5.6 и сервер nfs на CentOS 6.x. Виртуальные машины были не большие и не критичные, особо статистику не собирал, бэкапятся — да и ладно.
На новом месте ESXi 5.1 и FreeNAS 9.3 — проблем не наблюдаю. Протестировать в других связках пока нет возможности. Но интересны результаты и решение. Надо будет поразбираться в вопросе.
Only those users with full accounts are able to leave comments. Log in, please.