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

  • Tutorial
Наверное многие из нас, решая задачу организации небольшой 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
96.38
STSS — отечественный производитель и интегратор
Share post

Comments 71

    +1
    Неплохая статья, очень в тему для меня сейчас.
    У нас крутиться кластер из 4 нод, правда на локальных дисках, так что из всех плюшек кластера получаем только единый интерфейс управления. Как раз задумываемся об ISCSI таргете, что бы уже ни что не мешало пользоваться всеми прелестями кластера на полную.

    А как на счёт производительности?
    Было бы очень интересно взглянуть на резульаты каких-никаких тестов на производительность дисковой подсистемы из самого Proxmoxa и из виртуалки. Это очень обогатло бы вашу статью.
      +1
      По производительности, это тянет на отдельную статью.
      Повторюсь, решение собрано из того что было под рукой, поэтому на тестах дисковой подсистемы не акцентировались.
      Здесь, конечно можно поиграться с SSD, агрегированием каналов и пр. И будут разные результаты.
      Предложите Ваши варианты конфигурации дисковой подсистемы, мы постараемся реализовать и протестировать.
        0
        RAID1 — массив. WD диски. Из железа — широкодоступное что-то. Например D-link (Cisco) гигабитные свичи. Остально оставить как есть.
        С агрегацией, ну скажем 2 (или 4) каналов.
          +1
          Имхо, RAID-массив избыточен(и даже вреден), если используется ZFS.
            +1
            А что ZFS скажет на падение диска. Падение от слова "совсем", сдох контроллер, например. У меня тут на днях как раз таким образом SAS Hitachi помер. Если бы не RAID пришлось бы мне АТС разворачивать. так что RAID — наше всё.
              +1
              Я Вас не совсем понял — всё-таки, выход из строя контроллера, что приведёт к отвалу всех подключенных к нему дисков, или падение одного диска в пуле из нескольких? Это разные ситуации.

              В первом случае за сбоем контроллера последует отказ всего хранилища, RAID обеспечивает избыточность только на уровне группы дисков. И если вдруг в ЗИПе не найдётся такой же железки вплоть до совпадения версии фирмвари (представим такую ситуацию), то кому-то предстоит отправиться дорогой приключений (примета такая, говорят).

              В случае выхода одного диска из пула ZFS отработает так же как и RAID контроллер — выкинет из пула сбойный диск, добавит горячий резерв и начнёт ребилд.

              P.S. В целях проверки "запаса прочности" проверял дистрибутив Nas4Free — вынимал "на горячую" диски из корзины, ставил обратно, делал hard reset серверу и т.д. — и пришёл к выводу что ZFS удивительно устойчива к нештатным ситуациям подобного рода.
                0
                Предположу, что имелся в виду контроллер диска, а не RAID-контроллер...
                  0
                  Удивительные вещи вы расказываете) И всё это на уровне файловой системы??? Надо бы освежить свои знания на счёт ZFS)
                    0
                    Коротко говоря — ZFS совмещает в себе функции файловой системы и менеджера томов.
                    Софт-рейд, как-бы. Бонусом идёт несколько разных алгоритмов прозрачного сжатия данных "на лету", дедупликация, контроль целостности (и всё это работает на блочном уровне), механизм квот, мгновенные снапшоты, и прочая, и прочая. Вкусно, короче.

                      +1
                      Вспомним: каждый инструмент делает только свою задачу, и делает её хорошо. Это Unix-way.
                      ZFS в эту идеологию совсем не укладывается. В нём все слои (отказоустойчивость, сжатие, менеджер томов, файловая система) в одном. Не очень-то вкусно.

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

                        0
                        Не вполне согласен с вами.
                        Юниксвей — это всего лишь один из подходов к построению операционных систем, и отнюдь не "серебряная пуля". Монолитная архитектура тоже имеет право на реализацию, потому что уступая в универсальности раздробленой, может быть спроектирована оптимальнее.
                        Чем более unix-way система, тем больше у неё слоёв абстракции, и тем длиннее тянется за ней шлейф legacy-совместимости и костылей. Имхо.
                        Возвращаясь к обсуждению ZFS — Вы, однако, не привели никаких аргументов против использования ZFS кроме идеологических. Приведите практический пример, который бы продемонстрировал неудобство использования этой ФС именно в силу её "неверной" идеологической реализации.

                        Не претендую на правоту, возможно мой взгляд однобокий, прошу не агриться, а то потом мне будет неудобно постить прилично оформленные комментарии — "ни картинку не вставить, ни болдом написать".
                          +1
                          (Был на хабре вой про то, что нельзя высказать мнение, отличное от мнения т.н. "толпы". Ну вот оно, я высказал — тут ведь принято боготворить ZFS. Я уже не в первый раз его высказываю. И как-то ничего.)

                          Практических примеров не будет. Я по своей воле даже пробовать использовать систему, структура которой мне заведомо не нравится, не буду. Я не вижу кардинальных преимуществ ZFS перед связкой, скажем, MD+LVM+ext4, по крайней мере таких, чтобы можно было пробовать её использовать в качестве альтернативы. Зато у указанной связки вижу явные преимущества:

                          Во-первых, я очень хорошо с ней знаком. Я практически руками читаю суперблоки MD. Был случай, что я вносил в суперблок изменения руками, чтобы собрать сломавшийся массив ("не себе", принесли для восстановления данных). Существует уйма утилит для восстановления данных со сбойнувшей ext4.

                          Во-вторых, ZFS нет ни в ванильном ядре, ни в популярных дистрибутивах (Debian). Чтобы её использовать, требуются дополнительные телодвижения. Я не могу просто взять и поставить систему сразу на ZFS. А вот все указанные компоненты связки есть.

                          В третьих, вот эта слоёная структура, которая вся уложена в один инструмент. Бывают случаи, когда я какой-либо функционал могу не использовать, либо наоборот — хочу туда что-то встроить. Есть у меня аппаратный RAID — и я не использую MD. Бывают случаи, когда не нужно управление томами — и я исключаю LVM. Сервер виртуализации? ext4 будет только в качестве корневой ФС системы хоста — LVM-тома как блочные устройства виртуальными дисками. Потребуется мне шифрование — добавится LUKS между MD и LVM; потребуется кэширование на SSD — появится и оно, в зависимости от ситуации — между MD и LVM (bcache) либо внутри LVM (DM-cache). При этом, неиспользуемые слои реально отсутствуют — они не тратят никакие ресурсы. Несмотря на это, я всегда могу достаточно быстро и просто "добавить" отсутствующий слой. С ZFS такое невозможно — для всех перечисленных облегчённых случаев она является over-engineered структурой, из которой ничего не убрать, а для случаев с наворотами — наоборот, если уж ZFS не поддерживает что-то, добавить нельзя. Например, в ZFS не получится добавить шифрование каноническим способом: слои менеджера томов и зеркалирования у неё внутри, я не могу вставить LUKS между ними (как между MD и LVM).

                          Далее. Вспомним, что приходится работать не только с локальными дисками. Вариантов конфигурации становится море, в работу включается сначала multipath, а потом и кластерные сервисы. Есть у ZFS функционал, аналогичный cLVM? Это когда я добавляю логический том в общую группу на одной ноде кластера, а он сразу же видится на всех нодах. Этот функционал — базовый для обеспечения, скажем, миграции виртуальных машин. Да хотя бы что станет с ZFS, если я размещу её на DRBD и буду одновременно обращаться с двух нод? Про LVM всё ясно: можно, если cLVM настроен; про ext4 — известно, что нельзя, зато есть OCFS и другие кластерные ФС, которые монтировать можно сразу на нескольких нодах (при правильной настройке демонов синхронизации).

                          P.S. что-то сломали в хабре. Писать комментарии стало неудобно, он как-то стал вольно образщаться с newline и т. п.
                            +1
                            Кстати, только хотел предложить аналогичную альтернативу ZFS.
                            конечно я не знаю всех вкусностей ZFS, но на мой взгляд аппаратный RAID + LVM много надежнее.
                              0
                              Адепты ZFS скажут, что эта связка морально устарела т.к. рейд контроллер ничего не знает о файлах. Например если у вас есть Raid0 на обычном контроллере и у вас произойдет ошибка чтения с диска — то все данные — пропали. В случае с ZFS она отрапортует вам что такой-то файл поврежден и продолжит работать дальше. Кроме того аппаратные рейд контроллеры от модели к модели ведут себя сильно по-разному (читай не предсказуемо).

                              Если в силу каких-то обстоятельств случиться ребилд массива, то ZFS будет ребилдить только блоки с данными. Тогда как рейд в виду того, что он ничего не знает о файлах, будет ребилдить все подряд (что в свою очередь может разрушить рейд. Например если при ребилде 5го рейда произойдет ошибка чтения). Ну еще можно вспомнить про Write hole, ZFS этой проблеме не подвержен.
                                0
                                То, что связка MD+LVM+фс морально устарела вовсе не означает, что ZFS лучше и годится на замену.
                                И по поводу RAID5: так же точно и при ребилде RAID1, если единственная живая реплика отказывает в процессе ребилда. И вы, и адепты ZFS заблуждаетесь по поводу поведения массива в этой ситуации, видимо, потому, что не знаете, что там произойдёт при ошибке чтения.
                                Ничего не разрушится, ребилд правда тоже до конца не дойдёт — наткнувшись на ошибку чтения, MD начинает ребилд с начала, потом дойдя до ошибки процесс снова перезапустится и т. д. Не очень хорошее поведение, однако на моей памяти сервер с такой проблемой и MD RAID1 выжил: на оставшейся полуживой реплике перезаписали hdparm-ом сектор с ошибкой чтения, в результате чего накопитель переназначил блок. Репликация MD прошла через этот блок и успешно завершилась. Да, данные в этом блоке испортились (блок затёрт нулями), но в итоге ни на что это не повлияло.
                                А вот как себя поведёт в аналогичном случае ZFS — что она сделает, если в процессе восстановления отказоустойчивости один из уникальных источников будет выдавать ошибки — вы знаете? Интересно. И если в случае MD сам честно сказал, какой блок сбоил, то как в случае ZFS вычислить точку, в которую писать?
                                  0
                                  ZFS отрапортует наверх что такой-то файл поврежден и будет ребилдить дальше. На моем домашнем рейд0 такое было однажды — я просто получил сообщение, примерно такого вида:

                                  The volume my-volume (ZFS) state is ONLINE: One or more devices has experienced an error resulting in data corruption. Applications may be affected.
                                  Device: /dev/ada3, 2 Currently unreadable (pending) sectors

                                  Через CLI можно посмотреть какой файл побился. Больше ни на чем это не сказалось. Так что нет необходимости выяснять в какую точку нужно что-то писать.
                              0
                              Довольно странный в технической дискуссии аргумент: "Практических примеров не будет. Я по своей воле даже пробовать использовать систему, структура которой мне заведомо не нравится, не буду."
                              Я не могу просто взять и поставить систему сразу на ZFS.

                              ZFS есть не только на Линукс. Точнее, как раз на линукс ZFS ещё довольно сырой, и многие функции отсутствуют вообще. FreeBSD, например, спокойно ставится на ZFS.
                              Про шифрование — вам нужно шифрование, или вам нужен LUKS? Если всё-таки во главу угла ставится "получить шифрование", а не "запилить LUKS", то есть GELI, поверх которого спокойно разворачивается ZFS. Или наоборот — поверх ZVOL разворачивается GELI с любой файловой системой внутри криптоконтейнера.
                              Никаких "неиспользуемых слоёв" в ZFS нет — когда вы запускаете ZFS, то практически все слои используются, за малым исключением и в отдельных сценариях.
                              Есть у ZFS функционал, аналогичный cLVM? Это когда я добавляю логический том в
                              общую группу на одной ноде кластера, а он сразу же видится на всех нодах.

                              Именно на ZFS такого функционала нет — пул, подключенный к одной системе, будет виден только ей. Но есть многое другое.
                              Как насчёт компрессии на лету?
                              Дедупликации?
                              Простых средств расширения дискового пространства?
                              "Тонких" блочных устройств (разумеется, также с компрессией и дедупликацией, на базе ZVOL)
                              С двухуровневым кэшем (SLOG/ARC/L2ARC)?
                              С возможностью сохранять более одной копии файлов на датасете, с автоматическим выбором не-битых блоков в случае сбоя носителя?
                              С автоматическим scrub'ом?
                              Сколько ещё уровней нужно накрутить будет в связку MD+LVM+ext4 (что влечёт за собой отдельные разборки с каждым из уровней — набор команд, ключей, структура сущностей, что поверх чего должно применяться и т. п.), чтобы получить весь вот этот функционал? Я даже дома использую его ВЕСЬ, за исключением дедупликации и SLOG. Не говоря уже про продакшн. Так что не очень понятно, какие "неиспользуемые" слои можно выделить в ZFS.
                              Да хотя бы что станет с ZFS, если я размещу её на DRBD и буду одновременно
                              обращаться с двух нод?

                              Да не вопрос, если вы будете обращаться к ZVOL. Причём все функции — кэши, компрессия, дедупликация, чексуммы — всё это будет работать.
                +1
                Добавлю свое имхо, для виртуализации всегда использую 10й, так как raid1,5,6 начинают жутко проседать при активном использовании ВМ больше 3х.
                  0
                  Не думали про кеширование. У меня проседаний не наблюдается, WD1002F9YZ в RAID1 с 4-мя виртуалками честно выдают заявленные производителем 600 Мб/сек
                    0
                    Ну тут смотря какие ВМ и для каких задач, если нагрузка не большая, вполне и первый raid справится. В моем случае — это виртуалки для разработчиков, на которые постоянно деплоятся приложения и активно используется postgresql. Был неприятный опыт, когда попортилась БД при отлючении питания, хотя raid controller был с батарейкой. Возможно какой-то сбой в железе, но с тех пор для надежности стараюсь не использовать кеширование на raid. Хотя с того времени много воды утекло и может сейчас все изменилось в лучшую сторону. Нужно проверять…

                      0
                      Батарейка на RAID это конечно хорошо, но страховки, как известно, много не бывает. Поэтому только LVM и правильно настроенная ext4 (шлагбаумы там всякие и кеши)
                      Кстати в пользу этого решения говорит и то, что корпорация добра в числе многих других рекомендует такой подход и сами его используют.
                        +1
                        Никакие шлагбаумы он спасут вашу ext4, если RAID-контроллер, хотя бы и в режиме HBA, ей отчитался "записано", а сам записал в свой гигабайтный кэш. Смысл батарейки на контроллере — поддерживать работу этого кэша.
                        Решит проблему тут режим WriteThrough, но вы быстро заметите что оно как-то небыстро работает.
                  –1
                  Delaem software raid, v srednem (zavisit ot kolichestva diskov)
                  performance = RAID10
                  capacity = RAIDz-2

                  Diski grupiruutsia v vDevs, naprimer RAID10 na 6 diskah s dvoinim zerkalom = 3 vDev, i t.d.
                  v Srednem chem bolshe vDev tem lu4she performance
              +4
              Скажите: Nexenta не имеет ограничений на объем хранилища?

              Еще хочу рассказать про CEPH. Это тоже неплохой вариант организации хранения образов виртуальных машин.
              Здесь вам не нужно отдельное физическое хранилище, вы можете настроить распределенное хранилище прямо на нодах, оно также будет отказоустойчевым и к тому же поддерживается Proxmox.

              Если интересно, вот ссылка на wiki-страничку на сайте Proxmox и на мою статью.

                +1
                Однако то, что доступно в Community версии, покрывает большинство начальных потребностей. Это и 18ТБ объема хранилища, и ZFS со снэпшотами, и возможность репликации из коробки!
                  +1
                  Каюсь, как-то проглядел, прошу прощения! :)
                  +1
                  Интересный это вариант. Мы пробовали вплоть до запуска Ceph на самих нодах виртуализации. В сухом минимальном остатке требуется три компа и коммутатор.
                    0
                    Подскажите как работа с Ceph?
                      +2
                      В рамках тестирования производительности — реализуем и Ceph.
                      Результаты выложим отдельной статьей.
                        0
                        Ещё на этапе проектирования кластера задумывались о Ceph, но потом подумалось, что производительности всё таки может не хватить.
                        Будет интересно узнать, били ли наши опасения обоснованы или нет)
                  +1
                  Спасибо за статью. Побольше бы такого материала на хабре.
                    +1
                    Спасибо за статью, было интересно прочитать.
                    А вы не подскажете вариант настройки отказоустойчивого кластера (на какой угодно программной платформе) который бы обеспечивал 100% времени доступа к ресурсам (т.е. при выходе из строя одной ноды — сам кластер работал бы как ни в чем не бывало)?
                      +1
                      Первое что приходит в голову — это VMWare Fault Tolerance. См. ссылку. Там суть в том что на определенном вами ресурсе (VM) всегда работает резервная копия на другой ноде.
                      При падении рабочей ноды, ресурс работать не прекращает.
                      Опять же, в этом случае надо покупать лицензию!
                        +1
                        Также похожий функционал, есть у XenServer, скорее всего дешевле чем у VMWare, но там надо уточнять.
                        Вот кстати интересная штука.
                        У Proxmox, VM переезжает на другую ноду с рестартом.
                          0
                          Не, вы не правы. При использовании ISCSI — таргета и правильной настройки тригеров HA, виртуалка продолжает работать как ни в чём не бывало.
                            +1
                            Буду рад ошибиться, к сожалению онлайн-миграция бывает только при старте вручную.
                            Это показано в ролике, в конце статьи.
                            Если нода по каким-то причинам падает, то VM рестартуют на другом хосте в соот-и с настройками HA.
                            Если же у вас работает по другому, давайте подробнее про ваши настройки?!
                              0
                              Да где-то тут на хабре была статья про HA на Proxmox. По ней и настраивал. Машинки мигрировали наживую, только в dmesg выкидывали предупреждение, что-то там с таймерами связанное и всё. Правда в качестве гостя Linux был. Может с Windows что-то по другому, не проверял.
                                +1
                                Всё там нормально с Windows.

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

                                А если нода с виртуалкой вышла из строя, и виртуалка обслуживалась HA, то она снова запустится на другой ноде. Но для ОС виртуалки это будет как будто нажали на Reset.

                                  0
                                  А, ну тогда естественно да, по другому никак, только держать в горячем резерве полный дубль виртуалки для подхватывания.
                                  Хотя многое зависит от самих сервисов нап виртуалках. Например ту же 1С можно запустить на двух виртуалках, которые в свою очередь разнести на разные ноды в кластере Proxmox, а вот сами виртуалки уже объединить в кластер 1С.
                                  С одной стороны они поделять нагрузку, а с другой стороны при падении любой из них сервис не остановится.
                                  Лично я так и сделал.
                                    0
                                    Речь в ветке о том, что VMWare и XenServer в принципе умеют выполнять виртуалку синхронно на двух нодах. Если одна из нод отказывает, виртуалка ничего не замечает. Она как бы постоянно мигрирует на вторую ноду в процессе выполнения.
                                    В своё время это была прорывная фича Xen под названием Kemari, так что видимо Citrix в итоге коммерциализовал это в своём XenServer. Когда и как это появилось в VMWare я не знаю, наверняка недавно.
                                    Proxmox такого не умеет, хотя принципиально в нём это тоже вполне возможно реализовать.
                        –1
                        Все нормальные гипервизоры предлогают такой функционал — VMWare, Hyper-V, KVM, Xen
                        Работает всё примерно одинаково — все ноды обращаются к одному хранилищу, а актуальное состояние реплицируется через сеть. Всё в принципе уперается в общее хранилище. Под линукс или виндовс есть возможноси объеденить локальные диски в одно хранилище.
                        У VMWare есть дополнительная опция. Если у вас к примеру нету общего хранилища, то можно образовать одно из дисков в нодах, что-то типа рейда через сеть, название забыл. Делали, работает не очень быстро и доступно только половина памяти.
                        В линуксе можно сделать к примеру ceph кластер, можно на те же сервера где proxmox установить, поэтому не понятно нафига огорот с iscsi городить.

                        Hyper-v с отдельным хранилищем работает как кластер очень хорошо, виртуальные машины перекидываются без проблем и без обрывов, во всяком случае версия начиная с 2012
                          0
                          Настраивал (по инструкциям в интернете, в том числе с хабра) кластер на Hyper-V (сервер AD + две ноды + СХД от IBM) везде стояла 2012 R2, СХД была настроена как общий ресурс с кворумом, MPIO и т.д. При выключении "активной" ноды виртуальные машины мигрировали и были недоступны примерно с минуту. Хотелось бы узнать как всетаки правильно создать кластер, чтобы виртуальные машины не перезагружались при выходе из строя "активной" ноды, какие ПО и железо использовать.
                            0
                            на hyper-v пока такое не возможно самим гипервизором, да и наврятли microsoft сделает в ближайшее время такую возможность.
                            если у вас виртуальная машина на windows, то поднимайте кластер майкрософта уже на виртуальных машина. если у вас linux то смотрите в сторону keepalived
                              0
                              Несовсем понял про кластер внутри "виртуалок", не могли ли бы вы поподробнее объяснить, пожалуйста? А за keepalived спасибо, нашел статью на хабре, вроде бы понятную :)
                                +1
                                Многий корпоративный софт на данный момент имеет функционал кластеризации на уровне сервисов. То есть, на примере 1С:
                                1) Два сервера 1С, обединяются в кластер, с одинаковым набором баз, с подключением к одному SQL-серверу и делят нагрузку от клиентов между собой. В случае падения одного из них, клиенты сами переподключаются на оставшийся сервер и вся нагрузка ложится на него. При этом сам сервис 1С ни на секунду не останавливается.
                                2) Исходя из вышесказанного, что нам нужно. Две виртуалки, на разных нода кластера Proxmox. Внутри каждой из них установлено по одному желтому серверу, которые уже механизмами самой 1С объеденены в кластер серверов 1С. Они делят между собой нагрузку, а не дублируют состояние друг друга. То есть ресурсы железа не простаивают не расходуются вхолостую
                                3) Таким образом при падении одной из нод Proxmox падает и виртуалка, расположенная на нём. Но в строю остаётся вторая виртуалка с сервером 1С, так-как она расположена на второй ноде. Тоесть сервис 1С продолжает работать. Просто оставшийся в строю теперь всю нагрузку берёт на себя.
                                Аналогиный механизм можно применить и к SQL-серверу, и разместить две sql-ноды на тех же хостах что 1с-сервера.
                                Получится отказоустойчивая связка 1с-sql.

                                  0
                                  Про кластер SQL-сервера в курсе, но он не особо поможет, 1С для меня совсем не в тему. хотелось бы отказоустойчивую именно виртуалку, а не определенный "чужой" софт. Но за комментарий спасибо :) Только мне в вашем комментарии непонятно зачем вообще вам кластер Proxmox. Берем 2 физических сервера "фигак один SQL-сервер, фигак второй, и в продакшен" :)
                                  0
                                  Товарищ имел в виду так называемую «гостевую кластеризацию». Например, вам нужен отказоустойчивый MS SQL. Тогда делаете два виртуальных сервера с MS SQL, и далее собираете кластер средствами Windows и MS SQL. А в правилах размещения машин указываете, что они должны выполняться строго на разных узлах. Тогда при выходе из строя одного узла сервис у вас не пострадает — на другом узле останется работать второй виртуальный узел кластера MS SQL.
                                  И high availability, вообще говоря, так и строится — если гипервизор падает, то машины переподнимаются на остальных оставшихся узлах, но для виртуалок это равносильно нажатию reset.
                                  Если же речь о технологии, которую VMware называет fault tolerance, то она имеет определённые особенности экслуатации и приличные ограничения. До версии VMware 6 с помощью FT можно было зарезервировать только машину с 1 vCPU и с ограничением по объёму памяти (вроде бы, не более 16 Гб). И линк между узлами обязательно должен был быть 10G. В VMware 6 можно резервировать машины с не более чем 4 vCPU и 64 GB RAM. Ну и надо понимать, что фактически такая машина превращается в две машины аналогичной конфигурации — на другом узле будет работать теневая копия, равная по объёму ресурсов защищаемой машине.
                                    0
                                    Я понимаю что имел в виду "товарищ", но мне бы хотелось "отказоустойчивую виртуалку" :)
                                    А про VMware вы имели в виду vSphere 6.0?
                                    И у вас таже "проблема" что и у "товарища". Зачем мне кластер Proxmox, который как оказывается нефига не отказоустойчивый, зачем мне заводить в нем виртуалки, зачем разносить из на разные ноды? В данном случае или вообще не париться и поставить на железо без виртуалок, или использовать два обособленных гипервизора.
                                      +1
                                      Да, я имел в виду vSphere 6.
                                      Это вопрос терминологии. То, что у нас обычно называется "отказоустойчивостью", по-английски называется HA — high availability. Что в буквальном переводе означает "высокая доступность". В этом смысле рестарт виртуалок на оставшихся в живых гипервизорах — гораздо более высокая доступность, нежели отвал сервиса на физическом сервере.
                                      Из более-менее production-ready технологий, обеспечивающих совсем уж "отказоустойчивые виртуалки", я знаю только VMware Fault Tolerance. Есть ещё Xen Remus, но там всё сыро, большие проблемы с производительностью, и главное, как ни странно — проблемы с устойчивостью таких отказоусточивых виртуалок — они часто крэшатся из-за вносимых технологией задержек исполнения инструкций.
                                      Поэтому если вам реально нужно "ехать", а не просто шашечки, то для обеспечения отказоустойчивого СЕРВИСА можно использовать кластер HA из трёх и более хостов + гостевую кластеризацию. Логика будет такая:
                                      • у вас гостевой кластер работает на разных гипервизорах;
                                      • если гипервизор падает, работающий на нём узел гостевого кластера автоматически рестартует на любом из оставшихся узлов;
                                      • гостевой кластер синхронизируется;
                                      • у вас опять получается полный гостевой кластер.
                                        +1
                                        Бесшовная отказоустойчивость a la VMware FT — это же не единственный бонус виртуализации. В большинстве случаев виртуализацией занимаются ради упрощения обслуживания за счёт отвязки от железа. Та же самая миграция ВМ между хостами нужна не только в случае падения хоста (да и в случае падения хоста поднять ВМ проще), миграция может быть запланированной — хост требует обслуживания или нужно изменить распределение ВМ по хостам.
                                  0
                                  Я точно такой-же делал (сервер AD + две ноды + СХД от IBM) всё работало. Делается failover cluster, настраиваете одну сеть для репликации (live migration), потом подключаете схд и делаете cluster shared storage (этот массив появляется в c:\cluster volume...) и потом все виртуалки складываете в эту папку. Виртуальные машины надо потом создавать как ресурсы кластера или конвертировать существующие в такие ресурсы.
                                    +1
                                    Тоже самое делал и я :) И у вас при этом "не было ни единого разрыва" при отключении активной ноды?
                                      +1
                                      Примерно на пальцах, говорим про винду
                                      у вас есть уже кластер hyper-v из двух нод и общего строрейджа
                                      поднимаете две виртуальные машины, и к обоим подключаем виртуальный диск кворума (сейчас не вспомню как в hyper-v это опция звучит в настройках жёсткого диска)
                                      далее на виртуальным машинах поднимайте роль кластера с общим IP адресом ну и настраивайте его под свои нужны.
                                      при выключении одной из физических нод, у вас в виртуальном кластере выпадет одна из нод и у вас отработает ваш виртуальный кластер, простоя минимум в худшем случае пару пакетов
                                        –1
                                        А можно с вами связаться по почте или как-то еще? Более детально обсудить.
                                        0
                                        я ещё раз поковырял кластер, да вы правы — жму шляпу, снимаю руку )
                                0
                                Используем в работе, при обновлениях иногда меняется протокол (может нам повезло) и с одних нод уже не получается управлять другими, пока не обновишь все ноды.
                                  +1
                                  Отличная статья, спасибо.
                                    +2
                                    Хорошая статья, но в подобных решениях часто зацикливаются на отказоустойчивости узлов виртуализации и забывают про отказоустойчивость СХД (или всей SAN). В данном случае мы получаем кластер, работа которого зависит от одиночного сервера с Нексентой и одиночного свитча.
                                    Конечно, если по условиям задачи клиента устраивает соответствующее RTO, то почему бы и нет. Только RTO нужно просчитать заранее:
                                    — время замены свитча (взять новый из запасов на складе, или дожидаться замены по гарантии от поставщика, находящегося в 500 км)
                                    — время восстановления СХД при различных сценариях. Например, переустановить Нексенту + восстановить данные из бэкапа или переключиться на использование резервной СХД на время диагностики/ремонта основной СХД.
                                      +2
                                      Все правильно, здесь мы упростили схему по максимуму.
                                      Время простоя, можно минимизировать даже в бесплатном варианте.
                                      Т.е. добавить в схему второй свитч(это недорого) + сделать в качестве Secondary Storage такую же Nexenta.
                                      Переключение на другой сторадж, займет какое-то время, но это не сравнить с его заменой.
                                      Схема работы двух хранилищ NexentaStor в режиме Active-Active конечно же есть, но уже за деньги.
                                      Все зависит от желания и возможностей клиента. Можно сделать по разному.
                                      0
                                      Спасибо, интересная статья.
                                        0
                                        Товарищи, насколько сложно построить такую систему на базе «гиперконвергентной» платформы Supermicro 2022TG-HTRF?
                                        Я так понимаю, в таком случае можно будет отказаться от Nexenta и задействовать Ceph, но я с ним ни разу не сталкивался.
                                          +1
                                          Эта платформа (как и все остальные Supermicro Twin / 2U Twin2 / Fat Twin) сама по себе является не более «гиперконвергентной», чем аналогичный набор из 2/4/8 отдельных серверах. Строить что-нибудь гиперконвергентное на основе бесплатного софта — не сложнее и не проще.
                                          Если требование бесплатности/открытость не на первом месте, то существуют готовые решения с поддержкой — тот же Nutanix, например, работает на Supermicro 2U Twin2 (с другой стороны, в случае готового решения — какая разница, на чем оно работает).
                                            0
                                            Задача стоит переехать в виртуальную и отказоустойчивую среду в условиях крайне ограниченнго бюджета.
                                            По большей части мне интересно узнать про две вещи:
                                            1) имеют ли эти или подобные блэйды какой-то внутренний интерконнект, чтобы не гонять трафик Ceph по гигабитным сетевым картам.
                                            2) есть ли уже такие реализации на Proxmox + Ceph и маны по ним?
                                              0
                                              В том-то и дело, что у этих штук из общего с блейдами только плотность размещения и консолидация питания, т.е. никаких модульных свитчей. В некоторых 2U Twin2 и FatTwin есть один набортный порт InfiniBand, в некоторых — два порта 10GBASE-T вместо гигабитных + есть низкопрофильный слот PCI-E.
                                              Шаг в сторону блейдов в небольших шасси — это MicroBlade в 3U варианте: 14 серверных модулей (в т.ч. и под 2x E5-2600v3 с двумя 10GbE) + пара свитчей.
                                              У Супермикры есть список конфигураций для цефостроения, но именно у меня опыта с реализацией нет. В таких случаях наши заказчики занимаются самовнедрением. В вики у Proxmox есть описание решения с Ceph, в том числе гиперконвергентного.
                                              Но самое главное — супермикровские Twin, Microcloud и другую экзотику нельзя использовать в небольших проектах, где речь идёт об 1-2 шасси, т.е. когда вы не готовы внезапно потерять на месяц 1–2 сервера или даже всё шасси целиком. Мы, например, держим на складе ЗиП для блейдов, а экзотику — только под крупные проекты и/или при наличии договора на расширенную поддержку. Примеры:
                                              1) У заказчика два FatTwin 4-в-1. Выходит из строя PDB (плата распределителя питания). Их два в шасси, каждый питает два сервера. Заказчик расстроен потерей двух серверов. Через 4 недели приходит замена, но к шасси не подходит. За это время Supermicro успела сменить ревизию шасси и ревизию этих PDB. Приходится ждать ещё 4 недели.
                                              2) В Твине выходит из строя контроллер SAS. Заказчик от нас далеко, сервисный контракт или ЗиП для самостоятельной замены не покупал. Мы бы и рады помочь, выслав подменный контроллер но форм-фактор у RAID-контроллера для Твинов нестандартный, придётся ждать.
                                          +1
                                          Хотелось бы конечно, использовать Starwind или FreeNAS (NAS4Free), но если одному для работы нужен Windows и шаманство с ISCSI, то у другого функция кластеризации не предусмотрена вообще.

                                          Однако, у Nas4Free (или FreeNAS) есть кластеризация. Называется HAST (+ CARP).
                                          Пару лет назад тоже выбирал платформу для бюджетного софтового дискового хранилища, пробовал нексенту и нас4фри. Остановился на последнем варианте, потому что нексента показалась мне бедной по функционалу, при том тяжеловесной и чрезмерно требовательной к ресурсам.
                                            +1
                                            Эта схема в продакшене работала?

                                            Я пробовал около полугода назад на VMware поднять тестовый кластер из nas4free.
                                            Собирается, реплицирует между собой данные, но вот добиться автоматического восстановления или устойчивой работы не удалось.
                                            Возможно, из-за некорректной настройки виртуальных сетевых интерфейсов. Железа для теста на физике не хватило.
                                              0
                                              Пару лет использую Nas4Free в качестве Shared Storage для виртуалок, для бэкапов и в качестве Samba-шар, однако HAST не пользовался, т.к. эта фича довольно долгое время была в состоянии экспериментальной.
                                              Тоже пробовал поднимать хранилище из-под виртуалки, но понял что это не есть гуд — страдает производительность, и как пишут — файловая система ZFS лучше работает с физическими накопителями, нужно как минимум пробрасывать HBA-контроллер в гостевую систему.
                                                0
                                                P.S.

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

                                                Для работы CARP в виртуальных окружениях требуется доп. настройка гипервизора.
                                                Для примера вот описание настройки CARP в Pfsense под гипервизором.
                                                  0
                                                  Среди перечисленных пунктов были выполнены с 1 по 3:
                                                  1) Enable promiscuous mode on the vSwitch
                                                  2) Enable "MAC Address changes"
                                                  3) Enable "Forged transmits"
                                                  4) If multiple physical ports exist on the same vswitch, the Net.ReversePathFwdCheckPromisc option must be enabled to work around a vswitch bug where multicast traffic will loop back to the host, causing CARP to not function with "link states coalesced" messages. (See below)
                                                +2
                                                Спасибо за замечание, исправлю. Здесь акцент на то, что доступно из коробки и Production-Ready.
                                                Действительно, их(FreeNAS (NAS4Free)) можно допилить до кластера.
                                                Но можно ли рекомендовать получившееся решение в Production?
                                                Лично я бы не стал.
                                                –1
                                                Действительно, несколько человек отметили единую точку отказа — СХД. Почему бы не воспользоваться DRBD, который поддердивается ProxMoxом из коробки?

                                                Only users with full accounts can post comments. Log in, please.