НАСТРОЙКА » История » Версия 33
Версия 32 (Олег Пеньков, 07.11.2019 10:49) → Версия 33/36 (Михаил Шарков, 10.01.2020 20:00)
h1. НАСТРОЙКА
{{toc}}
[[OVERVIEW]] | [[INSTALL]] | [[SETUP]] | [[OPERATIONS]] | [[LICENSE]]
[[ОБЗОР]] | [[УСТАНОВКА]] | [[НАСТРОЙКА]] | [[ОПЕРАЦИИ]] | [[ЛИЦЕНЗИЯ]]
Перед началом настройки убедитесь, что обе ноды включены и функционируют.
Если Вы планируете использовать второй сетевой адаптер для drbd линка, перед инициализацией кластера Вы должны настроить его.
Войдите на первую ноду через консоль или по ssh. (При соединении по ssh, из-за недоступности в этот момент DNS-сервиса, перед запросом пароля возможна
пауза до минуты).
h2. Настройка сети
Схемы настройки сети могут сильно различаться в зависимости от условий установки и назначения кластера.
Здесь приведена типовая схема с двумя интерфейсами - один для интерлинка (ganeti и drbd), а другой для локальной сети.
Эта схема предпочтительна для большинства ситуаций.
Она не требует наличия гигабитных коммутаторов, предоставляет неплохую надежность и производительность при низких затратах.
Два гигабитных интерфейса на узлах подключены друг к другу напрямую или через гигабитный коммутатор(если Вы хотите более чем 2 узла в кластере).
Два других интерфейса подключаются к LAN.
В этой схеме сбой в локальной сети не влияет на работоспособность кластера.
Пример конфигурации /etc/network/interfaces:
<pre>auto backbone
iface backbone inet static
address 192.168.236.1
netmask 255.255.255.0
network 192.168.236.0
broadcast 192.168.236.255
bridge_ports eth0
bridge_stp off
bridge_fd 0
# uncomment it to enable jumbo frame
# up ifconfig eth0 mtu 9000
auto lan
iface lan inet static
address 192.168.5.55
netmask 255.255.255.0
network 192.168.5.0
broadcast 192.168.5.255
gateway 192.168.5.1
bridge_ports eth1
bridge_stp off
bridge_fd 0
</pre>
Мост backbone используется для drbd и ganeti обмена, он автоматически настраивается при установке узлов.
Также адрес DNS сервера настроен установщиком - это будет адрес нашей сервисной машины(sci).
Мост lan используется для подключения к локальной сети и должен быть настроен вручную (в файле interfaces есть заготовка).
В такой конфигурации Вы должны заполнить следующие переменные в sci.conf:
NODE1_IP - Уже настроено установщиком.
NODE1_NAME - Уже настроено установщиком.
NODE2_IP - укажите ip адрес второй ноды на интерлинке (например, 192.168.236.2)
NODE2_NAME - укажите имя второй ноды (напр. gnt2)
NODE1_LAN_IP - ip адрес первой ноды в локальной сети. Он будет доступен в днс под именем $NODE1_NAME-lan.$DOMAIN(напр. 192.168.5.55)
NODE2_LAN_IP - ip адрес второй ноды в локальной сети. Он будет доступен в днс под именем $NODE2_NAME-lan.$DOMAIN(напр. 192.168.5.56)
CLUSTER_IP - Адрес кластера в локальной сети. НЕ должен совпадать с любым другим существующим адресом. Напр. 192.168.5.35.
CLUSTER_NAME - Имя кластера в локальной сети. Будет доступно в днс под $CLUSTER_NAME.
SCI_LAN_IP - если Вы хотите, чтобы виртуальная машина sci присутствовала в lan, назначьте этот адрес, напр. 192.168.5.95
На странице [[Настройка сети]] вы можете посмотреть и выбрать другие схемы на разные случаи жизни.
h2. Задание параметров для кластера
Для задания параметров следует отредактировать @/etc/sci/sci.conf@
Большинство параметров уже было описано выше в секции "Настройка сети".
Здесь указаны дополнительные замечания по поводу настройки:
* Вы должны указывать параметры двух узлов в соответствии с тем, как Вы их настроили.
* *ПРИМЕЧАНИЕ*: Вы можете настроить кластер и с одним узлом. В этом случае оставьте переменные NODE2_* пустыми.
По факту это опасная конфигурация, о чем Вы и будете предупреждены во время инициализации кластера.
Обязательные параметры:
* CLUSTER_IP - Вы обязательно должны указать ip адрес кластера. Это адрес, по которому можно всегда попасть на мастер ноду кластера.
* NODE2_NAME и NODE2_IP - Вы обязательно должны вписать имя и ip адрес второго узла, если он присутствует.
Необязательные параметры:
* NODE#_SAN_IP - ip адрес узлов в отдельной сети для drbd. Используется, если в сети присутствует отдельный сегмент для drbd. Должен быть указан для обоих нод или ни для одной.
* NODE#_LAN_IP - ip адрес узлов в LAN подсети. Должен быть указан для обоих нод или ни для одной.
* Если Вы не имеете подключения к интернету или имеете локальные зеркала для apt, скорректируйте переменные APT_*
* Если Вы хотите передавать запросы на сторонние DNS сервера, заполните DNS_FORWARDERS (не забудьте на конце ';').
* MASTER_NETDEV - имя сетевого интерфейса для поднятия ip адреса кластера. По умолчанию определяется автоматически.
* LAN_NETDEV - Сетевой интерфейс по умолчанию для виртуальных машин. По умолчанию определяется автоматически.
* RESERVED_VOLS - Список lvm томов, игнорируемых ganeti. Разделяется запятой. Следует указывать VG для каждого элемента списка.
h2. Инициализация кластера
Удостоверьтесь, что на обоих узлах установлено одинаковое время.
<pre>
# date
Thu Mar 12 12:23:10 MSK 2015
</pre>
Если нет - установите его командой
<pre>
# date -s "12 MAR 2015 12:23:00"
</pre>
Запустите:
<pre>
# sci-setup cluster
</pre>
Проверьте выведенные настройке и примите их, либо скорректируйте и запустите скрипт еще раз.
После принятия настроек запустится процесс инициализации кластера.
Далее Вы должны принять ssh ключ для второй ноды и набрать root пароль для второй ноды.
В конце Вы увидите вывод команды диагностики кластера. Он будет выглядеть наподобие этого:
<pre>
Verify
Wed Jan 12 15:36:10 2011 * Verifying global settings
Wed Jan 12 15:36:10 2011 * Gathering data (1 nodes)
Wed Jan 12 15:36:11 2011 * Verifying node status
Wed Jan 12 15:36:11 2011 * Verifying instance status
Wed Jan 12 15:36:11 2011 * Verifying orphan volumes
Wed Jan 12 15:36:11 2011 * Verifying orphan instances
Wed Jan 12 15:36:11 2011 * Verifying N+1 Memory redundancy
Wed Jan 12 15:36:11 2011 * Other Notes
Wed Jan 12 15:36:11 2011 * Hooks Results
Node DTotal DFree MTotal MNode MFree Pinst Sinst
gnt1.ganeti.example.org 100.0G 100.0G 1020M 379M 625M 0 0
gnt2.ganeti.example.org 100.0G 100.0G 1020M 379M 625M 0 0
If all is ok, proceed with /usr/local/sbin/sci-setup service
</pre>
h2. Установка сервисной виртуальной машины
Имя хоста для нашей сервисной виртуальной машине - sci, также имеются несколько алиасов.
Ее основной ip адрес берется из @/etc/resolv.conf@ на первой ноде.
Эта виртуальная машина должна присутствовать в @/etc/hosts@ на обоих нодах.
Запустите:
<pre>
# sci-setup service
</pre>
Вы увидите индикатор процесса синхронизации drbd дисков, затем:
<pre>
* running the instance OS create scripts...
</pre>
appears. The further may take a while. The process finishes with
<pre>
* starting instance...
</pre>
Теперь Вы можете подключиться к консоли виртуальной машины:
<pre>
# gnt-instance console sci
</pre>
Логиньтесь под рутом, пароль пустой.
*ПРИМЕЧАНИЕ*: Т.е. рутовый пароль пуст, ssh соединения запрещены. Установите пароль и установите @openssh-server@.
h2. Автонастройка сервисной машины
Система будет настроена автоматически посредством puppet.
Вы можете следить за процессом выполнения в @/var/log/daemon.log@.
Поначалу в системе не будет команды @less@, но Вы можете использовать @more@, @cat@, @tail@ или @tail -f@
пока @less@ не будет автоматически установлен.
В процессе автонастройки может потребоваться перезапустить puppet. По умолчанию он запускается каждые полчаса.
При желании можно перезапустить его руками:
<pre>
# /etc/init.d/puppet restart
</pre>
Повторяйте это раз в несколько минут, пока не увидите, что puppet больше ничего не делает.
h2. Установка новых виртуальных машин
Новые виртуальные машины добавляются стандартными командами ganeti:
<pre>
gnt-instance add -t drbd -o debootstrap+default -s 10g -B memory=256m -n NODE1_NAME:NODE2_NAME INSTANCE_NAME
</pre>
Однако, наш проект дополняет процесс несколькими специфичными хуками:
# На каждую машину ставится @puppet@ для автоконфигурации, @openssh-client@ для обмена файлами и т.д.
# На каждую машину ставится pygrub.
# Сетевые настройки для машины могут быть назначены автоматически(см. ниже).
h3. Автонастройка сети на виртуальных машинах.
Если Вам необходимо, чтобы виртуальные машины могли быть подключены к нескольким сетям и Вам необходимы статичные
настройки сети на них, Вы должны заполнить файл @/etc/ganeti/networks@ всеми нужными для подключения машин сетями.
Каждая строчка файла имеет формат:
|NETWORK|NETMASK|BROADCAST|GATEWAY|
Ganeti instance debootstrap хук смотрит в этот файл, находит сеть для заданного ip и настраивает сеть
на виртуальной машине автоматически.
*ПРИМЕЧАНИЕ*: Этот файл заполняется при инициализации кластера, так что в большинстве случаев Вам не потребуется
туда что-то добавлять.
*ПРИМЕЧАНИЕ*: файл networks должен присутствовать на каждой ноде (еще не автоматизировано).
h2. Добавление фильтра в настройки lvm:
При дефолтных настройках lvm многие операции с кластером могут быть сильно замедленными при большом количестве lvm томов.
Поэтому в sci по умолчанию используется фильтр в /etc/lvm/lvm.conf, который ищет vg только на md:
<pre>
filter = [ "a/md/", "r/.*/" ]
</pre>
Если Вы не используете md, фильтр нужно заменить на:
<pre>
filter = [ "a/.*/" ]
</pre>
и выполнить
<pre>
vgscan
</pre>
h2. Добавление дополнительной VG
Если в сервере есть два типа дисков, например 4xSATA 2xSATA + 2xSSD, 8xSAS, то необходимо иницииализировать вторую VG и (при необходимости) сделать ее основной для создания виртуальных машин:
Действия выполняются на каждой ноде:
Разметить диск:
</pre>
выбираем диск
<pre>
parted /dev/sdX
</pre> fdisk /dev/sdc
выбираем в чем выводиться будет размер диска (в данном примере MiB)
<pre>
unit MiB
</pre>
создаем метку диска в нашем случае это msdos
<pre>
mklabel msdos
</pre>
Размечаем создать primary раздел на весь диск
<pre>
Растиражировать разбивку на все диски (будьте осторожны, не промахнитесь дисками):
(parted) mkpart
</pre>
Выбираем тип раздела диска в нашем случае это primary
<pre>
Partition type? primary/extended? primary for i in d e f g h i j; do sfdisk -d /dev/sdc|sfdisk /dev/sd$i; done
</pre>
Выбираем файловую систему в нашем случае ext2
<pre>
File system type? [ext2]?
</pre>
Начало диска у нас с 4MiB
<pre>
Start? 4
</pre>
Конец диска так как это ссд мы оставляем 1-2GB в MiB
<pre>
End? 954000
</pre>
Проинициализировать md, vg
<pre>
#-n2 (количество дисков в рейде) -l1 (какой рейд, в данном варианте рейд1) /dev/md3 (смотрим командой cat /proc/mdstat, свободный md в нашем случае это md3)
mdadm --create -n2 -l1 -n8 -l10 /dev/md3 /dev/sda1 /dev/sdb1
/dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 /dev/sdi1 /dev/sdj1
pvcreate /dev/md3
vgcreate ssd /dev/md3</pre> sas /dev/md3
</pre>
Так же необходимо добавить новый рейд в конфиг mdadm, чтобы он виделся после перезагрузки
Узнаем его UUID
<pre>
mdadm --examine --scan
</pre>
Добавляем строчку с нужным массивом в файл
<pre>
/etc/mdadm/mdamd.conf
</pre>
И пересобираем initrd
<pre>
dpkg-reconfigure mdadm
</pre>
И, наконец, настроить кластер по умолчанию на использование новой vg, а также на использование этой vg для метаданных drbd (выполняется 1 раз, на мастере):
<pre>
gnt-cluster modify --vg-name=sas --disk-parameters=drbd:metavg=sas
</pre>
По умолчанию для всех дисков в кластере устанавливается шедулер deadline
В случае, если используется аппаратный raid контроллер или отдельное хранилище, подключенное по FC/Infiniband/iSCSI, то, ВОЗМОЖНО, будет иметь смысл поставить шедулер noop. Однако, deadline подходит для всех типов дисков.
Статья про сравнение трех вариантов offset в raid10 (в SCI используется дефолтный, NEAR):
http://www.ilsistemista.net/index.php/linux-a-unix/35-linux-software-raid-10-layouts-performance-near-far-and-offset-benchmark-analysis.html?start=1
h2. [[Настройка Hugepages]]
h2. Операции с кластером
Читайте в [[ОПЕРАЦИИ]].
{{toc}}
[[OVERVIEW]] | [[INSTALL]] | [[SETUP]] | [[OPERATIONS]] | [[LICENSE]]
[[ОБЗОР]] | [[УСТАНОВКА]] | [[НАСТРОЙКА]] | [[ОПЕРАЦИИ]] | [[ЛИЦЕНЗИЯ]]
Перед началом настройки убедитесь, что обе ноды включены и функционируют.
Если Вы планируете использовать второй сетевой адаптер для drbd линка, перед инициализацией кластера Вы должны настроить его.
Войдите на первую ноду через консоль или по ssh. (При соединении по ssh, из-за недоступности в этот момент DNS-сервиса, перед запросом пароля возможна
пауза до минуты).
h2. Настройка сети
Схемы настройки сети могут сильно различаться в зависимости от условий установки и назначения кластера.
Здесь приведена типовая схема с двумя интерфейсами - один для интерлинка (ganeti и drbd), а другой для локальной сети.
Эта схема предпочтительна для большинства ситуаций.
Она не требует наличия гигабитных коммутаторов, предоставляет неплохую надежность и производительность при низких затратах.
Два гигабитных интерфейса на узлах подключены друг к другу напрямую или через гигабитный коммутатор(если Вы хотите более чем 2 узла в кластере).
Два других интерфейса подключаются к LAN.
В этой схеме сбой в локальной сети не влияет на работоспособность кластера.
Пример конфигурации /etc/network/interfaces:
<pre>auto backbone
iface backbone inet static
address 192.168.236.1
netmask 255.255.255.0
network 192.168.236.0
broadcast 192.168.236.255
bridge_ports eth0
bridge_stp off
bridge_fd 0
# uncomment it to enable jumbo frame
# up ifconfig eth0 mtu 9000
auto lan
iface lan inet static
address 192.168.5.55
netmask 255.255.255.0
network 192.168.5.0
broadcast 192.168.5.255
gateway 192.168.5.1
bridge_ports eth1
bridge_stp off
bridge_fd 0
</pre>
Мост backbone используется для drbd и ganeti обмена, он автоматически настраивается при установке узлов.
Также адрес DNS сервера настроен установщиком - это будет адрес нашей сервисной машины(sci).
Мост lan используется для подключения к локальной сети и должен быть настроен вручную (в файле interfaces есть заготовка).
В такой конфигурации Вы должны заполнить следующие переменные в sci.conf:
NODE1_IP - Уже настроено установщиком.
NODE1_NAME - Уже настроено установщиком.
NODE2_IP - укажите ip адрес второй ноды на интерлинке (например, 192.168.236.2)
NODE2_NAME - укажите имя второй ноды (напр. gnt2)
NODE1_LAN_IP - ip адрес первой ноды в локальной сети. Он будет доступен в днс под именем $NODE1_NAME-lan.$DOMAIN(напр. 192.168.5.55)
NODE2_LAN_IP - ip адрес второй ноды в локальной сети. Он будет доступен в днс под именем $NODE2_NAME-lan.$DOMAIN(напр. 192.168.5.56)
CLUSTER_IP - Адрес кластера в локальной сети. НЕ должен совпадать с любым другим существующим адресом. Напр. 192.168.5.35.
CLUSTER_NAME - Имя кластера в локальной сети. Будет доступно в днс под $CLUSTER_NAME.
SCI_LAN_IP - если Вы хотите, чтобы виртуальная машина sci присутствовала в lan, назначьте этот адрес, напр. 192.168.5.95
На странице [[Настройка сети]] вы можете посмотреть и выбрать другие схемы на разные случаи жизни.
h2. Задание параметров для кластера
Для задания параметров следует отредактировать @/etc/sci/sci.conf@
Большинство параметров уже было описано выше в секции "Настройка сети".
Здесь указаны дополнительные замечания по поводу настройки:
* Вы должны указывать параметры двух узлов в соответствии с тем, как Вы их настроили.
* *ПРИМЕЧАНИЕ*: Вы можете настроить кластер и с одним узлом. В этом случае оставьте переменные NODE2_* пустыми.
По факту это опасная конфигурация, о чем Вы и будете предупреждены во время инициализации кластера.
Обязательные параметры:
* CLUSTER_IP - Вы обязательно должны указать ip адрес кластера. Это адрес, по которому можно всегда попасть на мастер ноду кластера.
* NODE2_NAME и NODE2_IP - Вы обязательно должны вписать имя и ip адрес второго узла, если он присутствует.
Необязательные параметры:
* NODE#_SAN_IP - ip адрес узлов в отдельной сети для drbd. Используется, если в сети присутствует отдельный сегмент для drbd. Должен быть указан для обоих нод или ни для одной.
* NODE#_LAN_IP - ip адрес узлов в LAN подсети. Должен быть указан для обоих нод или ни для одной.
* Если Вы не имеете подключения к интернету или имеете локальные зеркала для apt, скорректируйте переменные APT_*
* Если Вы хотите передавать запросы на сторонние DNS сервера, заполните DNS_FORWARDERS (не забудьте на конце ';').
* MASTER_NETDEV - имя сетевого интерфейса для поднятия ip адреса кластера. По умолчанию определяется автоматически.
* LAN_NETDEV - Сетевой интерфейс по умолчанию для виртуальных машин. По умолчанию определяется автоматически.
* RESERVED_VOLS - Список lvm томов, игнорируемых ganeti. Разделяется запятой. Следует указывать VG для каждого элемента списка.
h2. Инициализация кластера
Удостоверьтесь, что на обоих узлах установлено одинаковое время.
<pre>
# date
Thu Mar 12 12:23:10 MSK 2015
</pre>
Если нет - установите его командой
<pre>
# date -s "12 MAR 2015 12:23:00"
</pre>
Запустите:
<pre>
# sci-setup cluster
</pre>
Проверьте выведенные настройке и примите их, либо скорректируйте и запустите скрипт еще раз.
После принятия настроек запустится процесс инициализации кластера.
Далее Вы должны принять ssh ключ для второй ноды и набрать root пароль для второй ноды.
В конце Вы увидите вывод команды диагностики кластера. Он будет выглядеть наподобие этого:
<pre>
Verify
Wed Jan 12 15:36:10 2011 * Verifying global settings
Wed Jan 12 15:36:10 2011 * Gathering data (1 nodes)
Wed Jan 12 15:36:11 2011 * Verifying node status
Wed Jan 12 15:36:11 2011 * Verifying instance status
Wed Jan 12 15:36:11 2011 * Verifying orphan volumes
Wed Jan 12 15:36:11 2011 * Verifying orphan instances
Wed Jan 12 15:36:11 2011 * Verifying N+1 Memory redundancy
Wed Jan 12 15:36:11 2011 * Other Notes
Wed Jan 12 15:36:11 2011 * Hooks Results
Node DTotal DFree MTotal MNode MFree Pinst Sinst
gnt1.ganeti.example.org 100.0G 100.0G 1020M 379M 625M 0 0
gnt2.ganeti.example.org 100.0G 100.0G 1020M 379M 625M 0 0
If all is ok, proceed with /usr/local/sbin/sci-setup service
</pre>
h2. Установка сервисной виртуальной машины
Имя хоста для нашей сервисной виртуальной машине - sci, также имеются несколько алиасов.
Ее основной ip адрес берется из @/etc/resolv.conf@ на первой ноде.
Эта виртуальная машина должна присутствовать в @/etc/hosts@ на обоих нодах.
Запустите:
<pre>
# sci-setup service
</pre>
Вы увидите индикатор процесса синхронизации drbd дисков, затем:
<pre>
* running the instance OS create scripts...
</pre>
appears. The further may take a while. The process finishes with
<pre>
* starting instance...
</pre>
Теперь Вы можете подключиться к консоли виртуальной машины:
<pre>
# gnt-instance console sci
</pre>
Логиньтесь под рутом, пароль пустой.
*ПРИМЕЧАНИЕ*: Т.е. рутовый пароль пуст, ssh соединения запрещены. Установите пароль и установите @openssh-server@.
h2. Автонастройка сервисной машины
Система будет настроена автоматически посредством puppet.
Вы можете следить за процессом выполнения в @/var/log/daemon.log@.
Поначалу в системе не будет команды @less@, но Вы можете использовать @more@, @cat@, @tail@ или @tail -f@
пока @less@ не будет автоматически установлен.
В процессе автонастройки может потребоваться перезапустить puppet. По умолчанию он запускается каждые полчаса.
При желании можно перезапустить его руками:
<pre>
# /etc/init.d/puppet restart
</pre>
Повторяйте это раз в несколько минут, пока не увидите, что puppet больше ничего не делает.
h2. Установка новых виртуальных машин
Новые виртуальные машины добавляются стандартными командами ganeti:
<pre>
gnt-instance add -t drbd -o debootstrap+default -s 10g -B memory=256m -n NODE1_NAME:NODE2_NAME INSTANCE_NAME
</pre>
Однако, наш проект дополняет процесс несколькими специфичными хуками:
# На каждую машину ставится @puppet@ для автоконфигурации, @openssh-client@ для обмена файлами и т.д.
# На каждую машину ставится pygrub.
# Сетевые настройки для машины могут быть назначены автоматически(см. ниже).
h3. Автонастройка сети на виртуальных машинах.
Если Вам необходимо, чтобы виртуальные машины могли быть подключены к нескольким сетям и Вам необходимы статичные
настройки сети на них, Вы должны заполнить файл @/etc/ganeti/networks@ всеми нужными для подключения машин сетями.
Каждая строчка файла имеет формат:
|NETWORK|NETMASK|BROADCAST|GATEWAY|
Ganeti instance debootstrap хук смотрит в этот файл, находит сеть для заданного ip и настраивает сеть
на виртуальной машине автоматически.
*ПРИМЕЧАНИЕ*: Этот файл заполняется при инициализации кластера, так что в большинстве случаев Вам не потребуется
туда что-то добавлять.
*ПРИМЕЧАНИЕ*: файл networks должен присутствовать на каждой ноде (еще не автоматизировано).
h2. Добавление фильтра в настройки lvm:
При дефолтных настройках lvm многие операции с кластером могут быть сильно замедленными при большом количестве lvm томов.
Поэтому в sci по умолчанию используется фильтр в /etc/lvm/lvm.conf, который ищет vg только на md:
<pre>
filter = [ "a/md/", "r/.*/" ]
</pre>
Если Вы не используете md, фильтр нужно заменить на:
<pre>
filter = [ "a/.*/" ]
</pre>
и выполнить
<pre>
vgscan
</pre>
h2. Добавление дополнительной VG
Если в сервере есть два типа дисков, например 4xSATA 2xSATA + 2xSSD, 8xSAS, то необходимо иницииализировать вторую VG и (при необходимости) сделать ее основной для создания виртуальных машин:
Действия выполняются на каждой ноде:
Разметить диск:
</pre>
выбираем диск
<pre>
parted /dev/sdX
</pre> fdisk /dev/sdc
выбираем в чем выводиться будет размер диска (в данном примере MiB)
<pre>
unit MiB
</pre>
создаем метку диска в нашем случае это msdos
<pre>
mklabel msdos
</pre>
Размечаем создать primary раздел на весь диск
<pre>
Растиражировать разбивку на все диски (будьте осторожны, не промахнитесь дисками):
(parted) mkpart
</pre>
Выбираем тип раздела диска в нашем случае это primary
<pre>
Partition type? primary/extended? primary for i in d e f g h i j; do sfdisk -d /dev/sdc|sfdisk /dev/sd$i; done
</pre>
Выбираем файловую систему в нашем случае ext2
<pre>
File system type? [ext2]?
</pre>
Начало диска у нас с 4MiB
<pre>
Start? 4
</pre>
Конец диска так как это ссд мы оставляем 1-2GB в MiB
<pre>
End? 954000
</pre>
Проинициализировать md, vg
<pre>
#-n2 (количество дисков в рейде) -l1 (какой рейд, в данном варианте рейд1) /dev/md3 (смотрим командой cat /proc/mdstat, свободный md в нашем случае это md3)
mdadm --create -n2 -l1 -n8 -l10 /dev/md3 /dev/sda1 /dev/sdb1
/dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 /dev/sdi1 /dev/sdj1
pvcreate /dev/md3
vgcreate ssd /dev/md3</pre> sas /dev/md3
</pre>
Так же необходимо добавить новый рейд в конфиг mdadm, чтобы он виделся после перезагрузки
Узнаем его UUID
<pre>
mdadm --examine --scan
</pre>
Добавляем строчку с нужным массивом в файл
<pre>
/etc/mdadm/mdamd.conf
</pre>
И пересобираем initrd
<pre>
dpkg-reconfigure mdadm
</pre>
И, наконец, настроить кластер по умолчанию на использование новой vg, а также на использование этой vg для метаданных drbd (выполняется 1 раз, на мастере):
<pre>
gnt-cluster modify --vg-name=sas --disk-parameters=drbd:metavg=sas
</pre>
По умолчанию для всех дисков в кластере устанавливается шедулер deadline
В случае, если используется аппаратный raid контроллер или отдельное хранилище, подключенное по FC/Infiniband/iSCSI, то, ВОЗМОЖНО, будет иметь смысл поставить шедулер noop. Однако, deadline подходит для всех типов дисков.
Статья про сравнение трех вариантов offset в raid10 (в SCI используется дефолтный, NEAR):
http://www.ilsistemista.net/index.php/linux-a-unix/35-linux-software-raid-10-layouts-performance-near-far-and-offset-benchmark-analysis.html?start=1
h2. [[Настройка Hugepages]]
h2. Операции с кластером
Читайте в [[ОПЕРАЦИИ]].