Установка и настройка отказоустойчивого кластера. — различия между версиями
WikiLight (обсуждение | вклад) (→Создание Glusterfs) |
WikiLight (обсуждение | вклад) |
||
| Строка 346: | Строка 346: | ||
'''cd /media/glusterfs/wbackup | '''cd /media/glusterfs/wbackup | ||
for I in ‘attr -lq .`; do setfattr -x trusted.$i .; done attr -lq ./''' | for I in ‘attr -lq .`; do setfattr -x trusted.$i .; done attr -lq ./''' | ||
| − | |||
| − | |||
| − | |||
| − | |||
Версия 13:30, 24 мая 2017
Содержание
Введение
Virtual Environment (VE) (виртуальня среда) Proxmox является многоузловым кластерным гипервизоро с открытым исходным кодом, построенным на Debian Linux и способным работать на общедоступных аппаратных средствах, те самым устраняя любые блокировки вендора. Proxmox свободно доступен без каких-либо блокированных особенностей.
Proxmox это мультиузловая среда, и это означает, что многие узлы могут образовывать единый кластер в котором виртуальная машина может быть перемещена на любой узел в кластере, тем самым делая возможной избыточную виртуальную среду. Весь Proxmox кластер может управляться через надежный графический интерфейс пользователя (GUI).
Установка Proxmox на голом узле (на каждую Нод) на RAID1
1) Жесткие диски обязательно должны быть «очищены» перед установкой Proxmox! Для работы с программным RAID1 обязательно использование дисков HGST (было протестировано на них). На дисках Toshiba программный RAID1 сделать не удалось. После настройки Bios (режим SATA – ACHI), монтируем образ proxmox-ve_4.4-eb2d6f1e-2 с «Внешнего HDD» и загружаемся с него (без UEFI), либо через IPMI Supermicro utilities смонтировать образ proxmox-ve_4.4-eb2d6f1e-2 (для этого нужно знать ip адрес IPMI и быть в одной подсети с ним)
Процесс установки Proxmox полностью управляется графическим интерфейсом с помощью различных подсказок. В этом разделе мы последуем следующими шагами в создании нашего первого узла Proxmox. Включите питание и загрузите физический узел, используя установочный диск или USB-носитель. На следующий снимок экрана показывает как выглядит экран после загрузки:
2) Install proxmox VE
3) В экране End User License Agreement (EULA) кликните согласие:I agree.
4) Нажимаем options и меняем на файловую систему zfs-raid1) – next (не применимо для дисков Toshiba)
5) Russia – Europe/Moscow – U.S.English
6) Введите и подтвердите пароль для пользователя root. Затем введите адрес е-mail, на который отсылать все уведомления кластера Proxmox. Вводим пароль для root:000000 повторяем, mail любой —next
7) На данном шаге вы должны ввести имя хоста и сетевую информацию, такую как IP Address, Gateway, DNS Server. Введите необходимую информацию для вашей среды, а затем нажмите Next. Следующий экранный снимок показывает экран с сетевой информацией:
Hostname: dir_номер сервера.integra-s.com (доменное имя обязательно) Сеть указываем свою, ВАЖНО IP должен быть с прямым выходом в интернет, хотя бы на время обновления; в нашем случае (в офисе Интегра-С) настройки сети следующие:
192.168.10.66 (IP с инетом)
255.255.254.0 (маска)
192.168.10.9 (шлюз)
192.168.10.2 (DNS)
Нажмите Next
8) Дождаться завершения установки На данный момент была собрана вся необходимая информация и была запущена основная установка. После ее выполнения удалите установочный диск или носитель USB и кликните на Reboot. Следуйте шагам с 1 по 8 на втором и третьем узле узле. (Для Proxmox кластера минимально требуются два узла.)
ВНИМАНИЕ
Если требуется менять ip адрес делать только через web-интерфейс, имя сервера (нод) нельзя менять через nano /etc/hosts .
Обновление Proxmox и установка компонентов
1) Необходимо поменять платный репозиторий Proxmox, требующий подписки, на бесплатный, логинимся от root и вбиваем строку:
#nano /etc/apt/sources.list.d/pve-enterprise.list
Комментируем строку и вбиваем новую строку ниже:
deb http://download.proxmox.com/debian jessie pve-no-subscription
(можно использовать копирование строки ctrl+K (копировать) ctrl+U (вставить)
Нажимаем ctrl+X затем Y и Enter
2) Далее обновляем Proxmox:
#apt update && apt dist-upgrade
соглашаемся Y
“q to quit” нажимаем Q
3) Вбиваем и устанавливаем по очереди:
#pveceph install -version jewel
- apt install htop mc attr glusterfs-server pv ntp
Если требуется сменить имя сервера или ip адрес необходимо менять в двух местах, командами:
nano /etc/hostname — не желательно, возможны ошибки после
nano /etc/hosts
Веб-интерфейс, смена ip, редактирование hosts и добавление нодов
С другого компьютера в общей локальной сети (или ноутбука) заходим через браузер на веб-интерфейс proxmox:
в нашем случае https://192.168.10.66:8006
Выбираем сначала язык Russia затем root и пароль 000000
Выбираем сервер в левом столбце, затем System – сеть и в строке wmbr0 по двойному клику меняем в открывшемся окне IP адрес, маску и шлюз – ок. Так же меняем DNS сервер если требуется
Нажимаем на кнопку «Перезапуск» в верхнем правом углу веб-интерфейса (в некоторых случаях необходимо перезагружать дважды)
Ждем какое то время, пробуем зайти по новому адресу https://Х.Х.Х.Х:8006
Х.Х.Х.Х — ваш новый IP адрес, порт всегда 8006
Так же нужно поменять IP адрес в строке файла hosts, для корректного отображения IP в шапке консоли
Это можно сделать через веб-интерфейс нажав «Консоль» логинимся от root и вбиваем команду:
#nano /etc/hosts
меняет IP, а так же обязательно прописываем на каждой Ноде (сервере) ip и hostname Нод будущего кластера
Нажимаем ctrl+X затем Y и Enter
Повторяем у всех Нодов (серверов), pvelocalhost в конце строки остается на каждом из нодов в соответствии с тем, на котором настраиваем (см. скриншот). Обратить внимание на ip адрес и имя сервера. Включая четвертый dir4 - ZIP сервер.
Объединение в кластер
Создаем кластер и прописываем на главном Ноде (допустим на dir1):
#pvecm create <clustername> (например dircluster)
Проверяем, что все нормально и смотрим список Нод
#pvecm status
На второстепенных Нодах пишем
#pvecm add dir1 (dir1 это наш главный Нод)
yes, пароль от root главной Нода
Проверяем, что все нормально и смотрим список Нод в кластере
#pvecm status
Перезагружаем все Ноды и заходим в веб-интерфейс главного Нода (в нашем случае https://192.168.11.211:8006)
Должны увидеть все добавленные Ноды (серверы) в «Датацентр» - «Сводка» Online 3
CEHP (вводная часть)
Ceph является распределенной системой хранения, которая предоставляет блочные устройства хранения объектов RADOS (RBD, RADOS Block Device) Безотказное автономное распределенное хранилище объектов, Reliable Autonomic Distributed Object Store, файловую систему Ceph и хранилище объектов Ceph. Ceph построена с учетом потребностей в очень высоких уровнях надежности, масштабируемости и производительности. Кластер Ceph может быть расширен до масштабов данных в несколько Петабайт без ущерба для целостности данных и может быть настроен с применением общедоступного оборудования. Все записываемые в хранилище данные получают репликации по всему кластеру Ceph. Ceph с самого начала разрабатывался исходя из потребностей больших данных. В отличие от других типов хранилищ, чем больше становится кластер Ceph, тем выше его производительность. Тем не менее, он также может быть использован для резервирования данных с такой же легкостью в небольших средах. Низкая производительность может быть смягчена с применением SSD для хранения журналов Ceph. Встроенные средства самовосстановления Ceph обеспечивают беспрецедентную устойчивость при отсутствии единой точки отказа. В кластере Ceph со многими узлами хранилище может переносить не только отказ жесткого диска, но и выход из строя всего узла без потери данных. Ceph включает ряд компонентов имеющих решающее значение для вашего понимания того, как настраивать и эксплуатировать хранилище. Следующие компоненты это то, и чего состоит Ceph:
- Демон монитора (MON)
- Демон хранения объектов (OSD)
- Журнал OSD
- Сервер метаданных (MSD)
- Карта Управляемых масштабируемым хешированием репликаций (CRUSH map, Controlled Replication Under Scalable Hashing map)
- Группы размещения (PG, Placement Group)
- Пулы (Pool)
MON
Демоны монитора формируют кворум распределенного кластера Ceph. Должно присутствовать как минимум три настроенных демона монитора на различных узлах для каждого кластера. Демоны монитора также могут быть настроены как виртуальные машины вместо применения физических узлов. Мониторы требуют очень мало ресурсов для функционирования, следовательно выделяемые ресурсы могут быть очень незначительными. Монитор может быть установлен через графический интерфейс Proxmox после начального создания кластера.
OSD
Демоны хранения объектов OSD, Object Storage Daemons отвечают за хранение и извлечение действительных данных кластера. Обычно одно физическое устройство подобное жесткому диску, или твердотельному диску настраивается как отдельный OSD. Хотя несколько различных OSD может быть настроено на одном физическом диске, это не рекомендуется делать совсем ни для каких промышленных применений. Каждый OSD требует устройство журнала, где вначале записываются данные, которые позже переносятся на реальный OSD. Сохраняя данные в журналах на высокопроизводительных SSD мы можем значительно увеличивать производительность ввода/ вывода Ceph. Благодаря архитектуре Ceph, чем больше и больше OSD добавляется в кластер, тем больше возрастает производительность ввода/ вывода. Журнал OSD работает очень хорошо на малых кластерах при примерно восьми OSD на узел. OSD могут быть установлены с помощью графического интерфейса Proxmox после начального создания MON.
OSD Journal
Каждый фрагмент данных предназначенный для OSD Ceph вначале записывается в журнал. Журнал позволяет демонам OSD записывать меньшие фрагменты, позволяя реальным дискам фиксировать запись, которая требует больше времени. Проще говоря, все данные будут записаны в журналы, а затем журнальная файловая система отправляет данные на фактический диск для постоянной записи. Так, если журнал хранится на диске с высокой производительностью, например SSD, входящие данные будут записаны с гораздо более высокой скоростью, в то время как за сценой более медленные диски SATA могут фиксировать запись с более медленной скоростью. Журналы на SSD могут на самом деле улучшать производительность кластера Ceph, особенно, если кластер небольшой, всего с несколькими терабайтами данных.
Замечание
Следует также отметить, что если происходит отказ журнала, это приведёт к выходу из строя всех OSD, которые обслуживает данное устройство журнала. В некоторых средах может быть необходимо помещать два устройства SSD для зеркального RAID и уже его применять для журнала В больших средах с более чем 12 OSD на узел производительность может быть на самом деле получена путём размещения журнала на том же диске OSD вместо применения SSD для ведения журнала.
MDS
Демон сервера метаданных MDS, Metadata Server отвечает за предоставление файловой системы Ceph (CephFS) в распределенной системе хранения Ceph. MDS может настраиваться на отдельных узлах или сосуществовать с уже существующими узлами монитора или виртуальными машинами. Хотя CephFS прошла долгий путь, она по прежнему не в полной мере рекомендуется к применению в промышленной среде. Стоит упомянуть, что многие виртуальные среды активно работают с MDS без каких- либо проблем. В настоящее время не рекомендуется настраивать более двух MDS в одном кластере Ceph. В настоящее время CephFS не поддерживается подключаемым модулем хранения Proxmox. Однако она может быть настроена как монтируемая локально с последующим соединением через хранилище Directory. MDS не может быть установлен через графический интерфейс Proxmox, по крайней мере, в версии 3.4.
CRUSH map
Карта Управляемых масштабируемым хешированием репликаций (CRUSH map) является сердцем распределенной системы хранения Ceph. Алгоритм для сохранения и извлечения пользовательских данных в кластерах Ceph планируется в карте CRUSH. CRUSH делает возможным прямой доступ клиента к OSD. Это устраняет единую точку отказа и любые физические ограничения масштабирования, поскольку не существует централизованных серверов или контроллеров для управления операциями чтения и записи хранимых данных. Во всех кластерах Ceph CRUSH поддерживает карту всех MON и OSD. CRUSH определяет как данные должны быть разбиты и реплицированы среди OSD распределяя их среди локальных узлов или даже среди удаленно расположенных узлов. Карта CRUSH по умолчанию создается на только что установленный кластер Ceph. Она может дополнительно настраиваться дальше на основе потребностей пользователей. Для небольших кластеров Ceph эта карта должна работать просто прекрасно. Однако, когда Ceph развертывается для очень больших данных, эту карту необходимо настраивать дополнительно. Настроенная карта позволит лучше управлять массивными кластерами Ceph. Для успешной работы с кластерами Ceph любых размеров обязательно ясное понимание карты CRUSH.
PG
В хранилище Ceph объекты данных собираются в группы определяемые с помощью алгоритмов CRUSH. Они называются группами размещения (PG, Placement Group), поскольку CRUSH помещает эти группы в различные OSD в зависимости от установленного в карте CRUSH уровня репликации и количества OSD и узлов. Отслеживая группы объектов вместо самих объектов можно сохранять огромное количество аппаратных ресурсов. Было бы невозможно отслеживать миллионы отдельных объектов в кластере. Следующая диаграмма показывает как объекты объединяются в группы и, как PG связаны к OSD:
Для балансировки доступных аппаратных ресурсов необходимо назначать правильное число групп размещения. Число групп размещения должно меняться в зависимости от число OSD в кластере. Следующая таблица предлагаемых групп размещений выполнена разработчиками Ceph:
Pools
Пулы Ceph аналогичны разделам жесткого диска. Мы можем создать множество пулов в кластере Ceph для разделения хранимых данных. Например, пул с названием accounting может хранить данные всего подразделения бухгалтерского учета, а другой пул может хранить данные о персонале компании. При создании пула необходимо назначение числа групп размещения. При начальной настройке Ceph создаются три пула по умолчанию. Это data, metadata и rbd. Удаление пула навсегда удалит все хранимые объекты. Следующий рисунок демонстрирует основы кластера Proxmox+Ceph
Предыдущий рисунок показывает узлы Proxmox, три узла монитора, три узла OSD и два узла MDS составляющие кластер Proxmox+Ceph. Заметим, что Ceph располагается в сети, которая отличается от общедоступной сети. В зависимости от установки числа репликаций все приходящие данные объектов должны записываться более одного раза. Это вызывает высокую потребность в пропускной способности. {Прим. пер.: еще большую нагрузку создают автоматическая балансировка, сохраняющая примерно равным процент заполнения всех OSD в кластере Ceph, и восстановление копий в случае выхода из строя некоего оборудования}. Выделяя Ceph в отдельную сетевую среду мы будем уверены, что сеть Ceph может полностью использовать всю полосу пропускания.
В более продвинутых кластерах третья сеть создается исключительно между узлами Ceph для репликаций кластера, тем самым еще больше улучшая производительность. В Proxmox VE 3.4. один и тот же узел может использоваться и для Proxmox, и для Ceph. Это предоставляет больший способ управляемости всеми узлами из одного графического интерфейса Proxmox. Не рекомендуется размещать виртуальные машины Proxmox на узле который также настроен как Ceph. Во время повседневных операций узлы Ceph не потребляют больших объемов ресурсов подобных процессорам или памяти. Однако, когда Ceph переходит в режим балансировки вследствие отказа узла OSD возникают большие объемы реплицируемых данных, что требует больших объемов ресурсов. Если ресурсы совместно используются виртуальными машинами и Ceph, производительность значительно ухудшится.
Настройка основного хранилища
Вы можете настроить хранилище в кластере Proxmox как с применением GUI, так и с помощью CLI. Настройка хранилища сохраняется в файле
/etc/pve/storage.cfg.
Вы можете изменить этот файл непосредственно чтобы добавить хранилища через графический интерфейс Proxmox, а настройки сохранятся автоматически. Следующий снимок экрана является файлом настроек хранилищ в том виде, как он возникает после чистой установки Proxmox:
Настройка хранилищ обычно имеет следующий многострочный формат: <type of storage> : <storage_id> <path_to_storage> <enable/disable share> content types maxfiles <numeric value of maximum backups to keep> На основании данной настройки существует локальное хранилище подключенное к кластеру Proxmox, причем все файлы будут сохраняться в каталоге /var/lib/vz. Данное хранилище может хранить типы содержания, включающие образы дисков, ISO, шаблоны контейнеров и файлы резервных копий. Хранилище будет хранить максимум три последних файла резервных копии. Следующий снимок экрана показывает хранилище из графического интерфейса Proxmox:
Изменение настройки хранилища не требует перезагрузки и вступает в действие немедленно.
CEHP (Настройка)
Добавляем внутреннюю сеть в веб-интерфейсе proxmox для каждого из нодов (eth1)
System – сеть
Перезагружаем каждую нод (сервер) два раза, должно быть yes в столбце «Активно»
На главной Ноде (dir1) пишем команду:
pveceph init --network 10.17.0.0/24
(нужно помнить что 10.17.0.0/24 это для адресов 10.17.Х.Х с маской 255.255.255.0, в вашем случае может быть иначе)
Создание мониторов делаем через консоль, для каждого нода командой:
pveceph createmon
Должны получить следующее:
Далее подготавливаем HDD для OSD, для этого их необходимо перевести в GPT
в консоле пишем команду:
fdisk /dev/sdc
g
w
Тоже самое проделываем для sdd, и так на каждой Ноде
После подготовки к созданию OSD, переходим в веб-интерфейсе в строку Ceph – OSD и нажимаем создать OSD
Выбираем sdc и в строке журналирования так же sdc
Для sdd так же журналирование на sdd
И так на каждой из нод. В итоге получаем 6 шт OSD
Далее удаляем «Пул» и создаем новый с такими параметрами:
Далее создаем RBD
Датацентр — Хранилище — добавить — RBD
Мониторы отделяем запятой без пробела
Затем на любой из Нод через консоль делаем следующее:
cd /etc/pve/priv/
mkdir ceph
cp /etc/ceph/ceph.client.admin.keyring ceph/iperbd.keyring (используйте Табуляцию)
где iperbd — это имя нашего RBD
Создание Glusterfs
Проверить на главной ноде gluster всех трех нод, командой:
gluster peer probe dir1
gluster peer probe dir2
gluster peer probe dir3
на всех нодах создаем папку wbackup командой:
mkdir -p /media/glusterfs/wbackup
Далее на главной ноде dir1 пишем:
gluster volume create wbackup replica 3 dir1:/media/glusterfs/wbackup
dir2:/media/glusterfs/wbackup dir3:/media/glusterfs/wbackup force (одной строкой)
Стартуем
gluster volume start wbackup (на главной ноде)
Проверяем на каждой ноде командой
gluster volume info
Затем в веб-интерфейсе Датацентр — Хранилище — Добавить - GlusterFS
Если требуется удалить volume
gluster volume stop wbackup
gluster volume delete wbsckup
cd /media/glusterfs/wbackup for I in ‘attr -lq .`; do setfattr -x trusted.$i .; done attr -lq ./
