Бесплатный кластер (Proxmox + Nexenta)

в 6:03, , рубрики: Infortrend, nexenta, nexentastor, proxmox ve, stss, Блог компании STSS, виртуализация, ит-инфраструктура, кластер, отказоустойчивый кластер, Тестирование IT-систем

Наверное многие из нас, решая задачу организации небольшой IT-инфраструктуры, сталкивались с проблемой выбора гипервизора. Каким функционалом должен обладать софт и сколько за это стоит платить? А будет ли та, или иная часть решения совместима с тем, что уже есть?
И как бы, всё это погонять на стенде, чтобы убедиться в правильности выбора?
С учетом курса одной, всем известной валюты, хочется чего-то простого, без излишеств и, по возможности, бесплатного. Тем более, когда речь идет о малой или средней компании (стартапе), ограниченной в бюджете.

Что нам требуется?

image

  • Совместимый с оборудованием гипервизор
  • Кластер, с доступом к админке через веб-интерфейс
  • High Availability для виртуальных машин в кластере
  • Функция бэкапа и восстановления из коробки
  • Доступность для понимания и работы среднему администратору (вчерашнему школьнику-студенту).

Из Open-Source решений, наиболее простым в установке и настройке является Proxmox. Чтобы не оскорблять любителей oVirt и пр. (это не рекламная статья), оговорюсь, что изначальное требование к простоте установки и администрирования, на мой взгляд, у Proxmox все же более выражено. Также, повторюсь, у нас не ЦОД, а всего лишь кластер из 2-3-х нод для небольшой компании.
В качестве гипервизоров он использует KVM и LXC, соответственно держит KVM ОС (Linux, *BSD, Windows и другие) с минимальными потерями производительности и Linux без потерь.

Итак, поехали:

Установка гипервизора простейшая, качаем его отсюда:
Инсталлируется буквально в несколько кликов и ввод пароля админа.
После чего, нам выдается окно консоли с адресом для веб-интерфейса вида

172.16.2.150:8006

(здесь и далее адресация тестовой сети).
Далее, устанавливаем вторую и третью ноды, с аналогичным результатом.

Запускаем кластер:

1. Настраиваем hosts на pve1.local:

root@pve1:~# nano /etc/hosts
127.0.0.1 localhost.localdomain localhost
172.16.2.170 pve1.local pve1 pvelocalhost
172.16.2.171 pve2.local pve2

2. Настраиваем hosts на pve2.local:

root@pve2:~# nano /etc/hosts
127.0.0.1 localhost.localdomain localhost
172.16.2.171 pve2.local pve2 pvelocalhost
172.16.2.170 pve1.local pve1

3. По аналогии настраиваем hosts на pve3.local
4. На сервере pve1.local выполняем:

root@pve1:~# pvecm create cluster

5. На сервере pve2.local выполняем:

root@pve2:~# pvecm add pve1

6. Точно так же, настраиваем и добавляем в кластер третий хост pve3.local.

Обновляем все ноды:

Приводим в соответствие репозиторий:

root@pve1:~# nano /etc/apt/sources.list
deb http://ftp.debian.org.ru/debian jessie main contrib
# PVE pve-no-subscription repository provided by proxmox.com, NOT recommended for production use
deb http://download.proxmox.com/debian jessie pve-no-subscription
# security updates
deb http://security.debian.org/ jessie/updates main contrib

Комментируем ненужный репозиторий:

root@pve1:~# nano /etc/apt/sources.list.d/pve-enterprise.list
# deb https://enterprise.proxmox.com/debian jessie pve-enterprise

И обновляемся (на каждой ноде соответственно):

root@pve1:~# apt-get update && apt-get dist-upgrade

Все, кластер готов к бою!

image

Здесь, мы уже из коробки имеем функцию бэкапа (называется резервирование), что подкупает практически сразу же!

Хранилище:

Далее, возникает вопрос выбора общего хранилища.
Выбираем ISCSI (как наиболее бюджетный вариант) Storage:
В принципе, при настройке можно ограничиться одним интерфейсом, однако в кластере нельзя иметь одну точку отказа, поэтому лучше использовать multipath от Proxmox, либо объединение интерфейсов от самой хранилки.

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

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

  • Unified storage: NAS/SAN
  • iSCSI target functionality
  • CIFS, NFS, HTTP, FTP Protocols
  • RAID 0,1,5,6,10 support
  • Bare metal or virtualization installation
  • 8TB+ Journaled filesystems
  • Filesystem Access Control Lists
  • Point In Time Copy (snapshots) support
  • Dynamic volume manager
  • Powerful web-based management
  • Block level remote replication
  • High Availability clustering
  • Основные функции должны присутствовать в Open-Cource/Community версии.

После некоторых мук выбора, остались OpenFiler и NexentaStor.
Хотелось бы конечно, использовать Starwind или FreeNAS (NAS4Free), но если одному для работы нужен Windows и шаманство с ISCSI, то у другого функция кластеризации не предусмотрена вообще.
OpenFiler к сожалению, имеет скудный GUI и последняя версия у него от 2011 года. Так что остается NexentaStor.
У неё, конечно же, схема работы active-active в кластере Nexenta уже платная, если вам такой понадобится в дальнейшем. Также если в хранилище 2 ноды (контроллера) то поддержка второго тоже за деньги! Собственно, все плагины доступны только в Enterprise версии.
Однако то, что доступно в Community версии, покрывает большинство начальных потребностей. Это и 18ТБ объема хранилища, и ZFS со снэпшотами, и возможность репликации из коробки!

Установка NexentaStor Community Edition:

Прежде всего, необходимо изучить Compatibility List.
Дистрибутив качаем отсюда (понадобится регистрация, чтобы получить ключ для установки).
Процедура установки проста, насколько это возможно, в ее процессе настраиваем IP-адрес с портом для настройки в GUI.
Далее, последовательно кликая по запросам визарда, задаем в GUI пароль и массив (в Nexenta он называется Volume).
Далее идем в раздел SCSI Target и последовательно создаем:

  1. Target Portal Groups
  2. Targets
  3. Remote Initiators — для каждой ноды:

image

Далее, в соответствии с мануалом:

root@pve1:~# mkdir /etc/pve/priv/zfs
root@pve1:~# ssh-keygen -f /etc/pve/priv/zfs/172.16.2.150_id_rsa
root@pve1:~# ssh-copy-id -i /etc/pve/priv/zfs/192.16.2.150_id_rsa.pub root@172.16.2.150

Копируем ключ на каждую ноду:

root@pve1:~# ssh -i /etc/pve/priv/zfs/172.16.2.150_id_rsa root@172.16.2.150

Подцепить ISCSI хранилище в Proxmox, можно двумя способами:
Через меню ISCSI в добавлении хранилища (придется создавать дополнительный LVM) — см.мануал.
Через меню ZFS over ISCSI — см.мануал.
Мы пойдем вторым путём, так как он даёт нам возможность создания и хранения снэпшотов. Также, это может делать и Nexenta.
Процесс настройки в GUI выглядит вот так:

image

В итоге получается:

image

При настройке не перепутайте имя пула (в nexenta он аналогичен Datastore):

root@nexenta:~# zpool status
pool: volume1
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
volume1 ONLINE 0 0 0
c0t1d0 ONLINE 0 0 0
errors: No known data errors

Теперь мы можем выбирать, как и что бэкапить.
Можем сделать автоматический бэкап VM на удаленное хранилище прямо из Proxmox:
Т.е. заходим во вкладку «Хранилище» и добавляем NFS-массив. Это может быть как обыкновенная NAS-хранилка, так и xNIX-сервер с папкой доступной через NFS (кому что удобнее). Затем, указываем содержимое (backup).

Или же, можно сделать репликацию средствами Nexenta:
Реализуется в GUI вкладками Data Management -> Auto Services -> Auto-Tier Services -> Create.
Здесь мы имеем в виду удаленное хранилище (или просто Linux-машина) с запущенной службой Rsync. Поэтому, перед этим нам необходимо создать связь между хостами.
Вкладки Settings -> Network -> SSH-bind помогают поднять коннект.

Настройка HA:

Настраивается полностью через GUI.

  1. Выделяем Датацентр, кликаем вкладку HA сверху.
  2. Жмем Группы снизу и создаем группу из хостов, на которые может мигрировать VM.
  3. Далее жмем Ресурсы и там добавляем VM, которую мы хотим.

Можно также посмотреть статус в консоли:

root@pve1:~# ha-manager status
quorum OK
master pve1 (active, Sun Mar 20 14:55:59 2016)
lrm pve1 (active, Sun Mar 20 14:56:02 2016)
lrm pve2 (active, Sun Mar 20 14:56:06 2016)
service vm:100 (pve1, started)

Теперь проверим работоспособность кластера.
Устанавливаем VM, с Windows, с диском в общем хранилище, и пробуем миграцию вручную:

Работает!
Отлично, теперь проверяем его отказоустойчивость, выключаем сервер через IPMI. Ждем переезда. Машина автоматически мигрирует через полторы минуты.
В чём проблема? Здесь необходимо понимать, что механизм fencing в версии 4.х поменялся. Т.е. сейчас работает Whatchdog fencing, который не имеет активной поддержки оборудования. Будет исправлено в версии 4.2.

Заключение

Итак, что же мы получили в итоге?
А получили мы Production-ready кластер, поддерживающий большинство ОС, с простым интерфейсом управления, возможностью кратного резервирования данных (это и сам Proxmox и Nexentastor со снэпшотами и репликацией).
Плюс ко всему, мы всегда имеем возможности масштабирования и добавления функций, как со стороны Proxmox, так и со стороны Nexenta (в этом случае придется таки купить лицензию).
И все это совершенно бесплатно!
По моему мнению, настройка всего этого не требует ни особых временных затрат, ни детального изучения разнообразных мануалов.
Конечно же, без некоторых грабель не обходится, тут сравнение с ESXi + VMWare vCenter будет в пользу последнего. Однако, всегда можно задать вопрос на форуме поддержки!
В итоге, почти 100% функционала, чаще всего используемого админом небольшого проекта (компании), мы получили сразу из коробки. Поэтому, рекомендую каждому задуматься, а стоит ли тратиться на излишние возможности, лишь бы они были лицензированы?

P.S. В вышеописанном эксперименте использовалось оборудование:

4 х Сервера STSS Flagman RX237.4-016LH в составе:

  • X9DRi-LN4F+
  • 2 х Xeon E5-2609
  • 8 х 4GB DDR-III ECC
  • ASR-6805 + FBWC

Три сервера из четырёх использовались как ноды, один — был забит 2ТБ-дисками и использовался в качестве хранилки.

В первом эксперименте в качестве NAS использовалась готовая СХД Infortrend EonNAS 3016R

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

Спасибо за внимание, жду Ваших комментариев!

Автор: STSS

Источник

Поделиться новостью

* - обязательные к заполнению поля