Создание отказоустойчивой ИТ инфраструктуры. Часть 1. Подготовка к развёртыванию кластера oVirt 4.3

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


Вводная часть


Под ЦОДом (Центром Обработки Данных) может пониматься:


  • собственная стойка в своём «серверном помещении» на территории предприятия, удовлетворяющем минимальным требованиям по обеспечению электропитанием и охлаждением оборудования, а также имеющее выход в Интернет через двух независимых провайдеров;
  • арендуемая стойка с собственным оборудованием, расположенная в настоящем ЦОДе – т.н. collocation, который соответствует стандарту Tier III или IV, и в котором гарантируется надёжное электропитание, охлаждение и обеспечивается отказоустойчивый выход в Интернет;
  • полностью арендуемое оборудование в ЦОДе Tier III или IV.

Какой вариант размещения выбрать – в каждом случае всё индивидуально, и обычно зависит от нескольких основных факторов:


  • для чего предприятию вообще собственная IT инфраструктура;
  • чего именно хочет предприятие от IT инфраструктуры (надёжности, масштабируемости, управляемости и т.д.);
  • объёма начальных инвестиций в IT инфраструктуру, а также какого типа затраты на неё – капитальные (значит покупается своё оборудование), или операционные (оборудование обычно арендуется);
  • горизонта планирования самого предприятия.

Про факторы, влияющие на решение предприятия по созданию и использование его IT инфраструктуры, можно писать много, но наша цель в том, чтобы показать на практике, как создать эту самую инфраструктуру, чтобы она была и отказоустойчивая, и ещё можно было бы при этом сэкономить – снизить расходы на приобретение коммерческого ПО, или вообще их избежать.


Как показывает долгая практика, на железе экономить не стоит, так как скупой платит дважды, и даже гораздо больше. Но опять же – хорошее железо, это всего лишь рекомендация, и в конечном итоге что именно покупать и за сколько, зависит от возможностей предприятия, и "жадности" его руководства. Причём слово "жадность" следует понимать в хорошем смысле этого слова, так как лучше вложиться в железо на начальном этапе, чтобы потом не иметь серьёзных проблем по его дальнейшей поддержке и масштабированию, так как изначально неправильное планирование и чрезмерная экономия, могут привести в будущем к большим затратам, чем при запуске проекта.


Итак, исходные данные для проекта:


  • имеется предприятие, которое решило создать собственный веб-портал и вывести свою деятельность в Интернет;
  • предприятие решило арендовать стойку для размещения своего оборудования в хорошем датацентре, имеющем сертификацию по стандарту Tier III;
  • предприятие решило сильно не экономить на железе, и поэтому купило следующее оборудование с расширенными гарантиями и поддержкой:

Список оборудования
  • два физических сервера Dell PowerEdge R640 в таком составе:
  • два процессора Intel Xeon Gold 5120
  • 512 Gb RAM
  • два SAS диска в RAID1, для установки ОС
  • встроенная 4-х портовая сетевая карта 1G
  • две 2-х портовые сетевые карты 10G
  • один 2-х портовый FC HBA 16G.
  • 2-х контроллерная СХД Dell MD3820f, подключенная посредством FC 16G напрямую к хостам Dell;
  • два коммутатора второго уровня — Cisco WS-C2960RX-48FPS-L объединённые в стек;
  • два коммутатора третьего уровня — Cisco WS-C3850-24T-E (но они выйдут на сцену позже, в четвёртой статье);
  • Стойка, UPS, PDU, консольные сервера – предоставляются датацентром.


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


Какое оборудование мы можем добавить, если предприятие решит увеличить производительность нашего вычислительного кластера:


  • у нас есть большой резерв по количеству портов на коммутаторах 2960Х, значит можно добавить больше аппаратных серверов;
  • докупить два FC коммутатора, чтобы подключить к ним СХД и дополнительные сервера;
  • уже имеющиеся сервера можно проапгрейдить – добавить памяти, заменить процессоры на более производительные, подключить к сети 10G уже имеющимися сетевыми адаптерами;
  • к СХД можно добавить дополнительные дисковые полки с необходимым типом дисков – SAS, SATA или SSD, зависит от планируемой нагрузки;
  • после добавления FC коммутаторов можно докупить ещё одну СХД, чтобы добавить ещё больше дисковой ёмкости, а если к ней докупить специальную опцию Remote Replication, то можно будет настроить репликацию данных между СХД как в границах одного ЦОДа, так и между ЦОДами (но это уже за рамками статьи);
  • также имеются коммутаторы третьего уровня – Cisco 3850, которые можно задействовать в качестве отказоустойчивого ядра сети, для высокоскоростной маршрутизации между внутренними сетями. Это очень поможет в дальнейшем, по мере роста внутренней инфраструктуры. Также у 3850 имеются порты 10G, которые можно задействовать позже, при обновлении сетевого оборудования до скорости 10G.

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


К тому же виртуализация имеет многие другие преимущества, которые нам очень могут пригодиться: отказоустойчивость ВМ от сбоя аппаратного сервера, Live migration между аппаратными узлами кластера для их обслуживания, ручное или автоматическое распределение нагрузки между узлами кластера, и т.п.


Для железа, приобретённого предприятием, напрашивается развёртывание высоко-доступного кластера VMware vSphere, но так как любое ПО от VMware известно своими «конскими» ценниками, то мы будем использовать абсолютно бесплатное программное обеспечение для управления виртуализацией – oVirt, на основе которого создаётся известный, но уже коммерческий продукт — RHEV.


Программное обеспечение oVirt необходимо для объединения между собой всех элементов инфраструктуры в одно целое, чтобы получить возможность удобной работы с высоко-доступными виртуальными машинами – это базы данных, веб-приложения, прокси-сервера, балансировщики, сервера для сбора логов и аналитики и т.п., то есть то, из чего и состоит веб-портал нашего предприятия.


Подытоживая это введение, нас ожидают следующие статьи, которые на практике покажут, как именно развернуть всю аппаратно-программную инфраструктуру предприятия:



Часть 1. Подготовка к развёртыванию кластера oVirt 4.3


Базовая настройка хостов


Установка и настройка ОС – это самый простой этап. Статей как правильно установить и настроить ОС – великое множество, так что нет смысла пытаться выдать что-то эксклюзивное по этому поводу.


Итак, у нас имеется два хоста Dell PowerEdge R640, на которые необходимо установить ОС и выполнить предварительные настройки, для их использования в качестве гипервизоров для запуска виртуальных машин в кластере oVirt 4.3.


Так как мы планируем использовать бесплатное некоммерческое ПО oVirt, то для развёртывания хостов выбрана ОС CentOS 7.7, хотя на хосты для oVirt'а возможна установка и других ОС:


  • специального билда на основе RHEL, т.н. oVirt Node;
  • OS Oracle Linux, летом 2019 г. было объявлено о поддержке работы oVirt на ней.

Перед установкой ОС рекомендуется:


  • настроить сетевой интерфейс iDRAC на обоих хостах;
  • обновить прошивки для BIOS и iDRAC до последних версий;
  • настроить System Profile сервера желательно в режиме Performance;
  • настроить RAID из локальных дисков (рекомендуется RAID1), для установки ОС на сервер.

Затем устанавливаем ОС на созданный ранее через iDRAC диск – процесс установки обычный, каких-то особых моментов в нём нет. Доступ к консоли сервера для начала установки ОС также можно получить через iDRAC, хотя ничто не мешает подключить монитор, клавиатуру и мышь напрямую к серверу и установить ОС с "флэшки".


После установки ОС, выполняем её начальные настройки:


systemctl enable network.service
systemctl start network.service
systemctl status network.service

systemctl stop NetworkManager
systemctl disable NetworkManager
systemctl status NetworkManager

yum install -y ntp
systemctl enable ntpd.service
systemctl start ntpd.service

cat /etc/sysconfig/selinux
SELINUX=disabled
SELINUXTYPE=targeted

cat /etc/security/limits.conf
 *               soft    nofile         65536
 *               hard   nofile         65536

cat /etc/sysctl.conf
vm.max_map_count = 262144
vm.swappiness = 1

Устанавливаем базовый набор ПО


Для начальной настройки ОС, нужно настроить любой сетевой интерфейс на сервере, чтобы можно было бы получить доступ в Интернет, для обновления ОС и установки необходимых пакетов ПО. Это можно сделать как в процессе установки ОС, так и после него.


yum -y install epel-release
yum update
yum -y install bind-utils yum-utils net-tools git htop iotop nmon pciutils sysfsutils sysstat mc nc rsync wget traceroute gzip unzip telnet 

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


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


systemctl enable tuned 
systemctl start tuned 
systemctl status tuned 

tuned-adm profile 
tuned-adm profile virtual-host 

Подробнее о профиле производительности можно почитать здесь: "Chapter 4. tuned and tuned-adm".


После установки ОС, переходим к следующей части – настройке сетевых интерфейсов на хостах, и стека коммутаторов Cisco 2960X.


Настройка стека коммутаторов Cisco 2960X


В нашем проекте будут использоваться следующие номера VLAN'ов — или широковещательных доменов, изолированных друг от друга, с целью разделения различных видов трафика:


VLAN 10 – public Internet
VLAN 17 – management network (iDRAC, СХД, switches management)
VLAN 30 – test network
VLAN 31 – test network
VLAN 32 – VM production network
VLAN 33 – interconnection network (to external contractors)
VLAN 34 – test network
VLAN 35 – test network
VLAN 36 – test network
VLAN 37 – test network
VLAN 38 – test network
VLAN 40 – VM test network


Перед началом работ, приведём схему на уровне L2, к которой мы в итоге должны прийти:



Для сетевого взаимодействия хостов oVirt и виртуальных машин между собой, а также для управления нашей СХД, необходима настройка стека коммутаторов Cisco 2960X.


У хостов Dell имеются встроенные 4-х портовые сетевые карты, следовательно, организовать их подключение к Cisco 2960X целесообразно с помощью отказоустойчивого сетевого подключения, используя для этого группировку физических сетевых портов в логический интерфейс, и протокол LACP (802.3ad):


  • первые два порта на хосте настраиваются в режиме бондинга и подключаются к коммутатору 2960X – на этом логическом интерфейсе будет настроен bridge с адресом для управления хостом, мониторинга, связи с другими хостами в кластере oVirt, также он будет использоваться для Live migration виртуальных машин;
  • вторые два порта на хосте также настраиваются в режиме бондинга и подключаются к 2960X – на этом логическом интерфейсе с помощью oVirt, в дальнейшем будут созданы bridge'и (в соответствующих VLAN'ах) к которым будут подключаться виртуальные машины.
  • оба сетевых порта, в рамках одного логического интерфейса, будут активными, т.е. трафик по ним может передаваться одновременно, в режиме балансировки.
  • сетевые настройки на узлах кластера должны быть абсолютно ОДИНАКОВЫМИ, за исключением IP адресов.

Базовая настройка стека коммутаторов 2960X и его портов


Предварительно наши коммутаторы должны быть:


  • смонтированы в стойку;
  • соединены посредством двух специальных кабелей нужной длины, например, CAB-STK-E-1M;
  • подключены к электропитанию;
  • подключены к рабочей станции администратора через консольный порт, для их начального конфигурирования.

Необходимое руководство для этого имеется на официальной странице производителя.


После выполнения вышеуказанных действий, выполняем настройку коммутаторов.
Что означает каждая команда, расшифровывать в рамках данной статьи не предполагается, при необходимости всю информацию можно найти самостоятельно.
Наша цель – максимально быстро настроить стек коммутаторов и подключить к нему хосты и управляющие интерфейсы СХД.


1) Подключаемся к ведущему коммутатору, переходим в привилегированный режим, далее заходим в режим конфигурирования и производим основные настройки.


Базовый конфиг коммутатора:
 enable
 configure terminal

 hostname 2960X

 no service pad
 service timestamps debug datetime msec
 service timestamps log datetime localtime show-timezone msec
 no service password-encryption
 service sequence-numbers

 switch 1 priority 15
 switch 2 priority 14
 stack-mac persistent timer 0

 clock timezone MSK 3
  vtp mode transparent
  ip subnet-zero

 vlan 17
  name Management

 vlan 32
  name PROD 

 vlan 33
  name Interconnect

 vlan 34
  name Test

 vlan 35
  name Dev

 vlan 40
  name Monitoring

 spanning-tree mode rapid-pvst
 spanning-tree etherchannel guard misconfig
 spanning-tree portfast bpduguard default
 spanning-tree extend system-id
 spanning-tree vlan 1-40 root primary
 spanning-tree loopguard default
 vlan internal allocation policy ascending
 port-channel load-balance src-dst-ip

 errdisable recovery cause loopback
 errdisable recovery cause bpduguard
 errdisable recovery interval 60

line con 0
 session-timeout 60
 exec-timeout 60 0
 logging synchronous
line vty 5 15
 session-timeout 60
 exec-timeout 60 0
 logging synchronous

 ip http server
 ip http secure-server
 no vstack

interface Vlan1
 no ip address
 shutdown

 exit 

Сохраняем конфиг командой «wr mem» и перезагружаем стек коммутаторов командой «reload» на ведущем коммутаторе switch 1.


2) Настраиваем сетевые порты коммутатора в режиме доступа (access) в VLAN 17, для подключения управляющих интерфейсов СХД и iDRAC серверов.


Настройка портов управления:
interface GigabitEthernet1/0/5
 description iDRAC - host1
 switchport access vlan 17
 switchport mode access
 spanning-tree portfast edge

interface GigabitEthernet1/0/6
 description Storage1 - Cntr0/Eth0
 switchport access vlan 17
 switchport mode access
 spanning-tree portfast edge

interface GigabitEthernet2/0/5
 description iDRAC - host2
 switchport access vlan 17
 switchport mode access
 spanning-tree portfast edge

interface GigabitEthernet2/0/6
 description Storage1 – Cntr1/Eth0
 switchport access vlan 17
 switchport mode access
 spanning-tree portfast edge
 exit

3) После перезагрузки стека, проверяем, чтобы он работал корректно:


Проверка функционирования стека:
2960X#show switch stack-ring speed

Stack Ring Speed        : 20G
Stack Ring Configuration: Full
Stack Ring Protocol     : FlexStack

2960X#show switch stack-ports
  Switch #    Port 1       Port 2
  --------    ------       ------
    1           Ok           Ok
    2           Ok           Ok

2960X#show switch neighbors
  Switch #    Port 1       Port 2
  --------    ------       ------
      1         2             2
      2         1             1

2960X#show switch detail
Switch/Stack Mac Address : 0cd0.f8e4.ХХХХ
Mac persistency wait time: Indefinite
                                           H/W   Current
Switch#  Role   Mac Address     Priority Version  State
----------------------------------------------------------
*1       Master 0cd0.f8e4.ХХХХ    15     4       Ready
 2       Member 0029.c251.ХХХХ     14     4       Ready

         Stack Port Status             Neighbors
Switch#  Port 1     Port 2           Port 1   Port 2
--------------------------------------------------------
  1        Ok         Ok                2        2
  2        Ok         Ok                1        1

4) Настройка SSH доступа к стеку 2960X


Для удаленного управления стеком через SSH, будем использовать IP 172.20.1.10, настроенный на SVI (switch virtual interface) VLAN17.


Хотя для целей управления желательно использовать специальный выделенный порт на коммутаторе, но это дело личных предпочтений и возможностей.


Настройка SSH доступа к стеку коммутаторов:
ip default-gateway 172.20.1.2

interface vlan 17
 ip address 172.20.1.10 255.255.255.0

hostname 2960X
 ip domain-name hw.home-lab.ru
 no ip domain-lookup

clock set 12:47:04 06 Dec 2019

crypto key generate rsa

ip ssh version 2
ip ssh time-out 90

line vty 0 4
 session-timeout 60
 exec-timeout 60 0
 privilege level 15
 logging synchronous
 transport input ssh

line vty 5 15
 session-timeout 60
 exec-timeout 60 0
 privilege level 15
 logging synchronous
 transport input ssh

aaa new-model
aaa authentication login default local 
username cisco privilege 15 secret my_ssh_password

Настраиваем пароль для входа в привилегированный режим:


enable secret *myenablepassword*
service password-encryption

Настраиваем NTP:


ntp server 85.21.78.8 prefer
ntp server 89.221.207.113
ntp server 185.22.60.71
ntp server 192.36.143.130
ntp server 185.209.85.222

show ntp status
show ntp associations
show clock detail

5) Настраиваем логические интерфейсы Etherchannel и физические порты, подключаемые к хостам. Для простоты конфигурации, все имеющиеся VLAN'ы будут разрешены на всех логических интерфейсах, но обычно рекомендуется настраивать только то, что нужно:


Настройка интерфейсов Etherchannel:
interface Port-channel1
 description EtherChannel with Host1-management
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 spanning-tree portfast edge trunk

interface Port-channel2
 description EtherChannel with Host2-management
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 spanning-tree portfast edge trunk

interface Port-channel3
 description EtherChannel with Host1-VM
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 spanning-tree portfast edge trunk

interface Port-channel4
 description EtherChannel with Host2-VM
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 spanning-tree portfast edge trunk

interface GigabitEthernet1/0/1
 description Host1-management
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 1 mode active

interface GigabitEthernet1/0/2
 description Host2-management
  switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 2 mode active

interface GigabitEthernet1/0/3
 description Host1-VM
  switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 3 mode active

interface GigabitEthernet1/0/4
 description Host2-VM
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 4 mode active

interface GigabitEthernet2/0/1
 description Host1-management
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 1 mode active

interface GigabitEthernet2/0/2
 description Host2-management
  switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 2 mode active

interface GigabitEthernet2/0/3
 description Host1-VM
  switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 3 mode active

interface GigabitEthernet2/0/4
 description Host2-VM
 switchport trunk allowed vlan 10,17,30-40
 switchport mode trunk
 channel-protocol lacp
 channel-group 4 mode active

Первичная настройка сетевых интерфейсов для виртуальных машин, на хостах Host1 и Host2


Проверяем наличие необходимых для работы бондинга модулей в системе, устанавливаем модуль для управления бриджами:


modinfo bonding
modinfo 8021q
yum install bridge-utils

Настройка на хостах логического интерфейса BOND1 для виртуальных машин, и его физических интерфейсов:
cat /etc/sysconfig/network-scripts/ifcfg-bond1
#DESCRIPTION - management
DEVICE=bond1
NAME=bond1
TYPE=Bond
IPV6INIT=no
ONBOOT=yes
USERCTL=no
NM_CONTROLLED=no
BOOTPROTO=none
BONDING_OPTS='mode=4 lacp_rate=1 xmit_hash_policy=2'

cat /etc/sysconfig/network-scripts/ifcfg-em2
#DESCRIPTION - management
DEVICE=em2
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
MASTER=bond1
SLAVE=yes
USERCTL=no 
NM_CONTROLLED=no 

cat /etc/sysconfig/network-scripts/ifcfg-em3
#DESCRIPTION - management
DEVICE=em3
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
MASTER=bond1
SLAVE=yes
USERCTL=no 
NM_CONTROLLED=no 

После завершения настроек на стеке 2960Х и хостах, рестартуем сеть на хостах, и проверяем работоспособность логического интерфейса.


  • на хосте:

systemctl restart network

cat /proc/net/bonding/bond1
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2+3 (2)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
...
802.3ad info
LACP rate: fast
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
...
Slave Interface: em2
MII Status: up
Speed: 1000 Mbps
Duplex: full
...
Slave Interface: em3
MII Status: up
Speed: 1000 Mbps
Duplex: full

  • на стеке коммутаторов 2960Х:

2960X#show lacp internal
Flags:  S - Device is requesting Slow LACPDUs
        F - Device is requesting Fast LACPDUs
        A - Device is in Active mode       P - Device is in Passive mode

Channel group 1
                            LACP port     Admin     Oper    Port        Port
Port      Flags   State     Priority      Key       Key     Number      State
Gi1/0/1   SA      bndl      32768         0x1       0x1     0x102       0x3D
Gi2/0/1   SA      bndl      32768         0x1       0x1     0x202       0x3D

2960X#sh etherchannel summary
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      N - not in use, no aggregation
        f - failed to allocate aggregator

        M - not in use, minimum links not met
        m - not in use, port not aggregated due to minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port

        A - formed by Auto LAG

Number of channel-groups in use: 11
Number of aggregators:           11

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         LACP      Gi1/0/1(P)  Gi2/0/1(P)

Первичная настройка сетевых интерфейсов для управления ресурсами кластера, на хостах Host1 и Host2


Настройка на хостах логического интерфейса BOND1 для управления, и его физических интерфейсов:
cat /etc/sysconfig/network-scripts/ifcfg-bond0
#DESCRIPTION - management
DEVICE=bond0
NAME=bond0
TYPE=Bond
BONDING_MASTER=yes
IPV6INIT=no
ONBOOT=yes
USERCTL=no
NM_CONTROLLED=no
BOOTPROTO=none
BONDING_OPTS='mode=4 lacp_rate=1 xmit_hash_policy=2'

cat /etc/sysconfig/network-scripts/ifcfg-em0
#DESCRIPTION - management
DEVICE=em0
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no 
NM_CONTROLLED=no 

cat /etc/sysconfig/network-scripts/ifcfg-em1
#DESCRIPTION - management
DEVICE=em1
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no 
NM_CONTROLLED=no 

После завершения настроек на стеке 2960Х и хостах, рестартуем сеть на хостах, и проверяем работоспособность логического интерфейса.


systemctl restart network
cat /proc/net/bonding/bond1

2960X#show lacp internal
2960X#sh etherchannel summary

Настраиваем управляющий сетевой интерфейс на каждом хосте в VLAN 17, и привязываем его к логическому интерфейсу BOND1:


Настройка VLAN17 на Host1:
cat /etc/sysconfig/network-scripts/ifcfg-bond1.17
DEVICE=bond1.17
NAME=bond1-vlan17
BOOTPROTO=none
ONBOOT=yes 
USERCTL=no 
NM_CONTROLLED=no 
VLAN=yes
MTU=1500  
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
IPADDR=172.20.1.163
NETMASK=255.255.255.0
GATEWAY=172.20.1.2
DEFROUTE=yes
DNS1=172.20.1.8
DNS2=172.20.1.9
ZONE=public

Настройка VLAN17 на Host2:
cat /etc/sysconfig/network-scripts/ifcfg-bond1.17
DEVICE=bond1.17
NAME=bond1-vlan17
BOOTPROTO=none
ONBOOT=yes 
USERCTL=no 
NM_CONTROLLED=no 
VLAN=yes
MTU=1500  
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
IPADDR=172.20.1.164
NETMASK=255.255.255.0
GATEWAY=172.20.1.2
DEFROUTE=yes
DNS1=172.20.1.8
DNS2=172.20.1.9
ZONE=public

Делаем рестарт сети на хостах и проверяем их видимость между собой.


На этом настройка стека коммутаторов Cisco 2960X закончена, и если всё было сделано правильно, то теперь мы имеем сетевую связанность всех элементов инфраструктуры между собой на уровне L2.


Настройка СХД Dell MD3820f


Перед началом работ по настройке СХД, она уже должна быть подключена к стеку коммутаторов Cisco 2960Х управляющими интерфейсами, а также к хостам Host1 и Host2 через FC.


Общая схема, как СХД должна быть подключена к стеку коммутаторов, приводилась в предыдущей главе.


Схема подключения СХД по FC к хостам, должна выглядеть так:



Во время подключения, необходимо записать WWPN адреса для FC HBA хостов, подключенных к FC портам на СХД – это будет необходимо для последующей настройки привязки хостов к LUN'ам на СХД.


На рабочую станцию администратора скачиваем и устанавливаем утилиту для управления СХД Dell MD3820f – PowerVault Modular Disk Storage Manager (MDSM).
Подключаемся к ней через её IP адреса по умолчанию, и затем настраиваем наши адреса из VLAN17, для управления контроллерами через TCP/IP:


Storage1:


ControllerA IP - 172.20.1.13, MASK - 255.255.255.0, Gateway - 172.20.1.2
ControllerB IP - 172.20.1.14, MASK - 255.255.255.0, Gateway - 172.20.1.2

После настройки адресов, заходим в интерфейс управления СХД и задаём пароль, настраиваем время, обновляем прошивки для контроллеров и дисков, если это необходимо и т.п.
Как это делается – описано в руководстве по администрированию СХД.


После выполнения вышеуказанных настроек, нам нужно будет сделать всего несколько действий:


  1. Настроить идентификаторы хостовых FC портов – Host Port Identifiers.
  2. Создать группу хостов – Host group и добавить в неё два наших хоста Dell.
  3. Создать дисковую группу и в ней виртуальные диски (или LUN'ы), которые будут презентованы хостам.
  4. Настроить презентацию виртуальных дисков (или LUN'ов) для хостов.

Добавление новых хостов и привязка к ним идентификаторов хостовых FC портов, делается через меню – Host Mappings -> Define -> Hosts…
WWPN адреса FC HBA хостов можно найти, например, в iDRAC сервера.


В результате у нас должна получиться примерно такая картинка:



Добавление новой группы хостов и привязка к ней хостов, делается через меню – Host Mappings -> Define -> Host Group…
Для хостов выбираем тип ОС – Linux (DM-MP).


После создания группы хостов, через вкладку Storage & Copy Services, создаём дисковую группу – Disk Group, с типом зависящим от требований к отказоустойчивости, например, RAID10, а в ней виртуальные диски нужного размера:



И наконец, финальный этап — презентация виртуальных дисков (или LUN'ов) для хостов.
Для этого через меню – Host Mappings -> Lun mapping -> Add… делаем привязку виртуальных дисков к хостам, назначая им номера.


Всё должно получиться так, как на этом скриншоте:



На этом с настройкой СХД мы заканчиваем, и если всё сделано было правильно, то хосты должны увидеть презентованные им LUN'ы через свои FC HBA.
Заставим систему обновить информацию о подключенных дисках:


ls -la /sys/class/scsi_host/
echo "- - -" > /sys/class/scsi_host/host[0-9]/scan

Посмотрим, какие устройства видны на наших серверах:
cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 02 Id: 00 Lun: 00
  Vendor: DELL     Model: PERC H330 Mini   Rev: 4.29
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi15 Channel: 00 Id: 00 Lun: 00
  Vendor: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi15 Channel: 00 Id: 00 Lun: 01
  Vendor: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi15 Channel: 00 Id: 00 Lun: 04
  Vendor: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi15 Channel: 00 Id: 00 Lun: 11
  Vendor: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi15 Channel: 00 Id: 00 Lun: 31
  Vendor: DELL     Model: Universal Xport  Rev: 0825
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi18 Channel: 00 Id: 00 Lun: 00
  Vendor: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi18 Channel: 00 Id: 00 Lun: 01
  Vendor: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi18 Channel: 00 Id: 00 Lun: 04
  Vendor: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi18 Channel: 00 Id: 00 Lun: 11
  Vendor: DELL     Model: MD38xxf          Rev: 0825
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi18 Channel: 00 Id: 00 Lun: 31
  Vendor: DELL     Model: Universal Xport  Rev: 0825
  Type:   Direct-Access                    ANSI  SCSI revision: 05

lsscsi
[0:2:0:0]    disk    DELL     PERC H330 Mini   4.29  /dev/sda
[15:0:0:0]   disk    DELL     MD38xxf          0825  -
[15:0:0:1]   disk    DELL     MD38xxf          0825  /dev/sdb
[15:0:0:4]   disk    DELL     MD38xxf          0825  /dev/sdc
[15:0:0:11]  disk    DELL     MD38xxf          0825  /dev/sdd
[15:0:0:31]  disk    DELL     Universal Xport  0825  -
 [18:0:0:0]   disk    DELL     MD38xxf          0825  -
[18:0:0:1]   disk    DELL     MD38xxf          0825  /dev/sdi
[18:0:0:4]   disk    DELL     MD38xxf          0825  /dev/sdj
[18:0:0:11]  disk    DELL     MD38xxf          0825  /dev/sdk
[18:0:0:31]  disk    DELL     Universal Xport  0825  -

На хостах также дополнительно можно настроить multipath, и хотя при установке oVirt он может сделать это и сам, но лучше проверить корректность работы MP заранее самим.


Установка и настройка DM Multipath


yum install device-mapper-multipath
mpathconf --enable --user_friendly_names y

cat /etc/multipath.conf | egrep -v "^\s*(#|$)"
defaults {
    user_friendly_names yes
            find_multipaths yes
}

blacklist {
  wwid 26353900f02796769
  devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"     
  devnode "^hd[a-z]"
 }

Устанавливаем сервис MP в автостарт и запускаем его:


systemctl enable multipathd && systemctl restart multipathd

Проверка информации о загруженных модулях для работы MP:
lsmod | grep dm_multipath
dm_multipath           27792  6 dm_service_time
dm_mod                124407  139 dm_multipath,dm_log,dm_mirror

modinfo dm_multipath
filename:       /lib/modules/3.10.0-957.12.2.el7.x86_64/kernel/drivers/md/dm-multipath.ko.xz
license:        GPL
author:         Sistina Software <dm-devel@redhat.com>
description:    device-mapper multipath target
retpoline:      Y
rhelversion:    7.6
srcversion:     985A03DCAF053D4910E53EE
depends:        dm-mod
intree:         Y
vermagic:       3.10.0-957.12.2.el7.x86_64 SMP mod_unload modversions
signer:         CentOS Linux kernel signing key
sig_key:        A3:2D:39:46:F2:D3:58:EA:52:30:1F:63:37:8A:37:A5:54:03:00:45
sig_hashalgo:   sha256

Просматриваем сводную информацию о существующей конфигурации multipath:


mpathconf
multipath is enabled
find_multipaths is disabled
user_friendly_names is disabled
dm_multipath module is loaded
multipathd is running

После добавления нового LUN на СХД и презентации его хосту, на нём нужно выполнить сканирование подключенных к хосту HBA.


systemctl reload multipathd
multipath -v2

Ну и наконец, проверяем, все ли LUN'ы были презентованы на СХД для хостов, и ко всем ли ведут два пути.


Проверка работы MP:
multipath -ll
3600a098000e4b4b3000003175cec1840 dm-2 DELL    ,MD38xxf
size=2.0T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='service-time 0' prio=14 status=active
| `- 15:0:0:1  sdb 8:16  active ready running
`-+- policy='service-time 0' prio=9 status=enabled
  `- 18:0:0:1  sdi 8:128 active ready running
3600a098000e4b48f000002ab5cec1921 dm-6 DELL    ,MD38xxf
size=10T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='service-time 0' prio=14 status=active
| `- 18:0:0:11 sdk 8:160 active ready running
`-+- policy='service-time 0' prio=9 status=enabled
  `- 15:0:0:11 sdd 8:48  active ready running
3600a098000e4b4b3000003c95d171065 dm-3 DELL    ,MD38xxf
size=150G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='service-time 0' prio=14 status=active
| `- 15:0:0:4  sdc 8:32  active ready running
`-+- policy='service-time 0' prio=9 status=enabled
  `- 18:0:0:4  sdj 8:144 active ready running

Как видно, все три виртуальных диска на СХД видны по двум путям. Таким образом все подготовительные работы выполнены, а значит можно переходить к выполнению основной части – настройке кластера oVirt, что будет рассмотрено в следующей статье.

Lenvendo
Разработка и техподдержка онлайн-проектов

Комментарии 55

    0
    Чем FC лучше iSCSI?
    Скрытый текст
    Чем грузины.
      +1
      Для статьи использовалось то, что было под рукой — FC, к тому же oVirt из коробки умеет с ним работать, впрочем как и с iSCSI (Data domains of multiple types: iSCSI, NFS, FC, POSIX, and Gluster).

      FC 16G будет побыстрее чем iSCSI 10G, меньше накладных расходов, но и подороже, особенно если подключать СХД к FC коммутаторам и настраивать фабрику.

      Если стоит цель совсем бюджетного решения, то можно использовать и СХД с SAS интерфейсами, но такая конфигурация с oVirt не тестировалась.
        0
        Теоретически, если используется multipath, можно получить до 20G, но сам такого не видел.
        Использую похожую схему с R730, MD3820, 10G Ethernet и Proxmox
          0
          чем больше путей — тем всегда лучше — кроме бОльшего количества кабелей конечно :))
      • НЛО прилетело и опубликовало эту надпись здесь
        0
        У вас в конфиге описка. 512 мб рам. Маловато будет)

        Эх, где вы были год назад, когда я прыгал по граблям) Данная статья бы сильно помогла) Жду следущую.

        Возможно, если всё оборудование брать делл в составе с esxi на микросд картах без винтов и с висферой (без лицензии на фоулт толеранс, дистрибьютед свитч и т.д.), только ha, то можно получить хороший дискаунт, который покроет лицензию на сферу, раз вмваре сейчас принадлежит деллу. Еще возможно можно сэкономить на дополнительных сетевухах 10 гб и l3 цисках. Т.е. оставить 1 idrac, 2x 10 гбит с лацп, 2x 1 гбит с лацп и парой виртуальных роутеров на линуксе.
          0
          поправил на Gb, спасибо :)

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

          Не все могут себе позволить нормальные управляемые 10 гбитные коммутаторы на 24 порта, поэтому используются гигабитные коммутаторы и FC подключения к СХД.
          Опять же возвращаясь к вопросу почему именно FC — это будущие возможности для расширения, а также Remote Replication между СХД.

          L3 коммутатор — можно вполне прожить без него, вся маршрутизация будет делаться на программных виосах, которые вполне со своей задачей справляются, что будет показано в последующих статьях. L3 коммутаторы нужны на вырост, когда рост внутрисетевого трафика станет узким местом для виосов.
            0
            Нене, FC выкидывать не надо, я не это имел ввиду) Я скорее к «две 2-х портовые сетевые карты 10G» взять одну, а не две.
            По поводу экономии и ovirt будем надеяться, что когда-нибудь опишите кейс при котором у вас 5-7 старых супермикро, набитых разными дисками, без fc, полки и 10 гбит интерфейса. Вообще интересует момент есть ли жизнь на 1гбит при гиперконвергентной инфраструктуре, или бомж вариант вариантом быть не может).
              0
              жизнь есть, но лучше так жить в тестовом окружении :)))
                0
                Я пробовал развернуть ceph на пачке старых серверов. По началу просто скорость уперлась в гигабит одного сервера, а потом все развалилось из-за нехватки RAM на серверах по отношению к объему дисков.
                habr.com/en/company/oleg-bunin/blog/431536/#comment_19435254
                  0
                  Я скорее про gluster думал.
                  Памяти на серверах от 32 до 128 гбайт, винчестера собранные в 10 рейды везде разной скорости и объёма, а сетевой интерфейс 1гбит (. Вот и думаю…
            0

            По железу сначала увидел при белом просмотре Xeon 5120, подумал что за барахло из уже двух десятилетий назад, и только потом вчитался в модель R640. Приписывайте Gold


            А по сути — интересен вариант с SDS типа Gluster или что-то типа self mounted iSCSI HA Cluster а ля StarWind для VMware. Хотя в случае с оригинальными дисками Dell часть ценовой прелести потеряется…

              +1
              спасибо, поправил описание конфига

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

              Обычно железное решение в виде СХД — надёжнее, стабильнее и даже бывает дешевле некоторых SDS (особенно в сравнении с VMware vSAN), при сравнимом функционале.
              +1

              OVirt это очень сложный, многослойный продукт, не прощающий мелких ошибок. Он моструозен и больше подходит для 10+ серверов. Буду рад почитать про него, но горе админу и фирме внедрившей его.

                +2
                Насчёт ошибок — да, согласен, пришлось по граблям поскакать :)))
                Но приготовив его один раз, потом уже гораздо легче. Насчёт монструозности — не согласен, хотя сервисов он ставит на хостовую машину многовато, это есть.

                Вот где монстр — так это OpenStack :)))

                В пром. эксплуатации кластер овирта находится более полугода, особых каких-то нареканий нет, хотя конечно есть свои нюансы, постараюсь описать их в следующей статье
                  0
                  я бы поставил Вам минус, да не имею права. Имею пару хостов, овирт, гластер — проблем с доступностью ВМ пока не имеем даже с учетом того что сплитбрен в автомтическом режиме не переживем. Да, есть проблемы, которых можно было избежать на этапе проектирования, но тогда не было достаточно опыта. И проблемы эти решаемы, руки просто не доходят.
                    0
                    так я же написал, что:
                    Но для хранения большого количества виртуальных машин особенно высоконагруженных, овирт в связке с гластером лично не тестировал, и не знаю как он себя будет вести под нагрузкой.

                    Поэтому вполне вероятно, что гластер и овирт это ок. Сам использовал его в другом проекте, вещь трудноубиваемая, но про сплитбрейн правильно замечено — в проде он недопустим…
                      0
                      не. Это я ответил на коммент oller
                        0
                        т/е поставите минус за мое мнение от применения)
                        Валить нужно с этого ресурса, загнивает он от такого отношения
                        то что у вас круто-поздравляю
                        А я вот обжегся…
                  0
                  В начале вы пишете, что хотите вложиться в железо и тут же покупаете 2960X которые предназначены для пользовательских сетей и имеют достаточно большую переподписку по портам. Зачем покупать карты 10G в сервера если их некуда включить. порты 10G d 2960 и 3850 предназначены для аплинков. Vlan1 для интернета??? Стек или VSS из коммутаторов это вообще не про надежность, имеется единая точка отказа т.к. логически это один коммутатор. В данной конфигурации можно было не покупать 2960x и обойтись 3850. А если хочется сделать действительно по-взрослому, то нужно смотреть на серию nexus которая предназначена для ЦОДов.
                    0

                    Эммм… так то по сути всё в общем верноо, но не всегда есть возможность использовать правильные железки, к сожалению… :)
                    Зачастую приходится брать или то, что дают, или делать из того что уже имеется — заказчику не всегда можно объяснить, что если он уже сам купил какое-то железо по своему разумению, то оно немного неправильное, и надо его выкинуть и купить немного другое, особенно если оно подороже. Поэтому приходится работать с тем, что есть — думаю, что такие ситуации встречаются довольно часто.


                    В частности, для этой статьи было под руками: 2 х WS-C2960RX-48FPS-L и 2 х Cisco 3850-24T-E.
                    Так как серверов много (это за рамками статьи), и портов на 3850 по-любому на всех не хватит, то хосты подключены к стеку 2960, и вроде он справляется со своими обязанностями без нареканий. В итоге получаем примерно такую логическую схему сети:



                    3850 используются для своих основных целей — маршрутизации внутреннего трафика, но как написал выше, можно вполне обойтись и без них, особенно на начальном этапе.
                    Они в этот конфиг включены специально, чтобы показать (в последующих статьях) что можно сделать, когда объёмы внутреннего межсетевого трафика становятся причиной того, что программные маршрутизаторы не справляются с нагрузкой на них.


                    VLAN1 использовать на проде конечно не рекомендуется, поправил на 10, спасибо.

                    0

                    А почему не использовать Hyper-v? Ну т.е понятно, что это не совсем бесплатное решение, но по сравнению с тем же Vsphere безусловно куда более дешёвое. По мне в продакшн для небольших организации куда более выгодное с точки зрения стабильности и обслуживания решение. Или я ошибаюсь?

                      0

                      Можно наверное и Hyper-V, почему бы и нет, тем более что в последних его версиях, даже не требуется AD для работы Failover Clustering.


                      Возможно, в дальнейшем подумаем над этим, но при написании статьи как-то даже не пришла в голову такая мысль :)
                      Как правило, у заказчика желательно делать однородное окружение, в смысле если использовать какую-то OS, то желательно везде одну и ту же, кроме конечно каких-то специфических задач. Это делается, в первую очередь, для удобства поддержки, поэтому и был выбран oVirt и CentOS.

                        0

                        Понял, я просто частенько прихожу на помощь людям когда уже все сломалось, и в целом если нет каких-то конкретных требований (предубеждений) у клиента, использую Hyper-v, по деньгам не так и дорого по сравнению с "лидерами рынка", при этом вполне адекватно и предсказуемо все работает. На небольших проектах типа аутсорсинг бухгалтерий где много однотипных данных очень хорошо работает дедупликация, что очень хорошо сказывается на бюджете проекта.

                        • НЛО прилетело и опубликовало эту надпись здесь
                            +1

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


                            Если имеем два хоста, СХД c FC, то на них можно установить OL 7 и KVM, презентовать диск хостам и настроить OCFS2 кластер с общим диском на СХД. Но так как у нас два хоста, то легко можно получить сплитбрейн, поэтому лучше чтобы было 3 хоста в кластере ocfs2. В том числе из-за этого и был выбран овирт, так как он поддерживает FC из коробки без лишних прослоек в виде ocfs, ну и сплитбрейна на 2-х узловой конфигурации овирта добиться так и не удалось.


                            Это да, облака… с ними можно и нужно работать если нам неинтересен закон о ПД — облака Azure, AWS, Goohle Cloud, находятся вне российской юрисдикции


                            Но, самолично проверено и не раз, что гораздо дешевле арендовать железо где-нибудь в РФ, или у того же OVH, чем арендовать виртуальные машины в облаке, сопоставимые по характеристикам с ВМ, размещаемым на арендованном железе.


                            Здесь конечно есть нюансы:


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

                        Перед reload циски хорошо бы сделать copy run start

                          0

                          Да, без этого никак нельзя :)
                          Спасибо за замечание


                          Добавил wr mem

                            0
                            Я правильно понимаю, в данном варианте, СХД будет единой точкой отказа?
                              0

                              Совершенно верно, впрочем и размещение всего хозяйства в одном датацентре — тоже несёт в себе риски, даже если ставить параллельно рядом вторую СХД, настраивать фабрику FC и remote replication, катастрофоустойчивость это не повысит :(


                              Хотя в СХД все компоненты задублированы, всё же риск её отказа существует (на моей памяти не сталкивался с полным выходом СХД из строя, кроме случайного выключения питания), но бэкапы никто не отменял, и желательно складировать их ещё и в другой локации, хотя бы в облако.


                              Распределённый датацентр, BGP, геобалансировка… Как много приятного в этих словах, надеюсь что и до этого доберусь :))

                                0
                                Просто в заголовке написано про отказоустойчивость. Возможно, в таком случае, заголовок не совсем верен. Катастрофоустойчивость — это уже несколько иной термин.
                                Может вариант с технологиями типа Storage Spaces Direct был бы более отказустойчивым. Не обязательно s2d, можно любое другое решение для создания гиперковергентной IT-инфраструктуры.
                                  0

                                  Storage Spaces Direct это софтварная штуковина, в проекте же используется настоящая железная СХД, пусть и не самая крутая. Железо по любому проще обслуживать, да и в плане производительности она даст фору sds при равных исходных данных, плюс имеются возможности расширения, как вертикально, так и горизонтально (конечно, за всё придётся заплатить :))


                                  Касаемо определения отказоустойчивости по отношению к аппаратной СХД с полностью дублированными компонентами…
                                  В моём понимании 2-х контроллерная СХД достаточна отказоустойчива, хотя конечно не помешало бы поставить рядом вторую такую же и сделать реплику, но бюджет не всегда резиновый :)


                                  Безусловно, вариант с SDS может быть интересен, но в каждом случае всё индивидуально и его надо ещё суметь правильно приготовить.
                                  Касаемо аппаратной СХД — точно известно, что она умеет, а чего нет, а в плане настройки, мониторинга и поддержки, с этим нет никаких проблем.

                              +1
                              На самом интересном месте :) Когда можно ожидать продолжения?

                              Так, как не терпится, хочу спросить наперёд, как вообще в принципе oVirt работает с СХД по FC? Так как это блочное устройство, как оно дальше представляется в oVirt-е? Там используется какая-то кластерная ФС (типа, как VMFS)? Либо напрямую блок отдается всей ВМ (в виде RAW)?

                              Есть ли в таком случае снепшоты, тонкие диски? Куда они кладут свои данные?

                              Спасибо, если будет ответ, даже очень краткий — просто по концепции, как это всё устроено.
                                0

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


                                Как известно, все нормальные кластерные файловые системы для блочных устройств — платные :(
                                По условиям проекта, мы за ПО принципиально не хотим ничего платить, и поэтому можем использовать только opensorce.
                                Самые известные бесплатные кластерные файловые системы — это OCFS2 и GFS2. Овирт с ними умеет работать, и ничто не мешает подключить LUN'ы на СХД к хостам через OCFS и далее подключить их к овирту как POSIX compliant file systems. Это вполне рабочий вариант, с одним но — для OCFS2 количество хостов в кластере желательно делать более чем 2, чтобы исключить сплитбрейн.


                                В нашем случае используется Fibre Channel Protocol (FCP) для подключения к LUN'ам на СХД.
                                С т.з. ovirt, при использовании СХД (FC или iSCSI) каждый виртуальный диск, снэпшот или шаблон — это логический диск.
                                Блочные устройства собираются в одно целое с помощью Volume Group и затем разделяются с помощью LVM на логические тома, используемые как виртуальные диски для ВМ.


                                В принципе всё это хозяйство из множества томов LVM можно увидеть на хосте с помощью команд vgs и lvs. Естественно, все действия с такими дисками нужно делать только из консоли овирта.


                                Виртуальные диски могут быть двух типов — QCOW2 или RAW. Диски могут быть "тонкими" или "толстыми". Снэпшоты всегда создаются как "тонкие".


                                В двух словах, способ управления Storage domains или доменами хранения, доступ к которым осуществляется через FC, довольно логичен — для каждого виртуального диска ВМ существует отдельный логический том, который доступен для записи только одному хосту.
                                В общем виде овирт использует в случае подключений через FC, что-то навроде кластерного LVM.

                                  0
                                  Спасибо за ответ, буду ждать вторую часть.

                                    0
                                    Вот очень интересно у вас: вы нагородили не сказать чтобы мега-, но довольно сложную схему, которая имеет для бизнеса смысл в виде уменьшения простоя ценой резервирования железа — но принципиально не хотите ко вложенным миллионам ни копейки добавить на платные решения, которые известно что работают и поддерживаются. Хотя железо у вас весьма недешево, и даже сам факт недоиспользования его (не то что простоя) стоит бизнесу недополучения счастья за вложенные деньги.

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

                                    Ну и да, есть больная тема, что кто будет обслуживать схему, случись вам отказаться/уволиться/сработал фактор автобуса? Не то что фирменные решения при этом помогают, но там часто все собирается на стандартных компонентах, под которые можно нового «стандартного» админа найти, а в самопостроенный зоопарк найти знатока с руками сложнее, хотя он и более сведущим будет (сможет смотреть не только в сторону сурово платных решений).

                                    Не критикую, пытаюсь понять.
                                      0

                                      Да, железо не самое дешёвое, но и не самое навороченное, зато вполне качественное. Главная цель для бизнеса — резервирование всех аппаратных элементов инфраструктуры, для минимизации простоев из-за железа.
                                      С cisco и dell организация работает очень давно, поэтому выбор был очевиден.


                                      Почему схема то сложная?!
                                      Cisco вполне себе нормальное и известное решение, vyos — это тот же джунипер.
                                      С сетевыми делами даже средний админ вполне справится.
                                      СХД — с ней вообще проблем не должно быть, всё настраивается через GUI, у неё нет вообще никаких заморочек.
                                      С овирт? Ну, там тоже GUI, знай себе тыкай мышкой, создавай виртуалки — это не с голым KVM в консоли работать, гораздо удобнее, как в vsphere почти.
                                      Разворачивается он не то чтобы сложно… Впрочем, это уже тема следующей статьи ;))

                                        0

                                        … про голый KVM выше дополню.
                                        На самом деле в консоли проще работать (только конечно привыкнуть надо), и при желании можно заскриптовать многие вещи, или даже тот же ансибл прикрутить вместе с cobbler — тогда по быстродействию будет весьма неплохо, для решения админских задач. Хотя потребует в начале каких-то затрат по времени, это да.

                                          0
                                          vyos — это тот же джунипер.

                                          Вот ни разу тот же джунипер, да командлайн по максимому похожий, на этом и все.
                                            0

                                            да, конечно, по CLI он похож, это и имелось в виду
                                            под капотом там кастомизированный дебиан, явно не тоже самое что и JunOS на ядре FreeBSD :)

                                          +1
                                          Для нормального линукс админа вполне понятная и рабочая схема.
                                          FC только экзотика для большинства.
                                          Предложите свои варианты.
                                            0

                                            FC очень неплох, уже писали выше почему именно, ну да, немного подороже чем iSCSI, но мы же и фабрику пока не делаем, а самый простой direct attach к СХД, проще некуда в принципе…
                                            А вот в дальнейшем можно будет и фабрику создать, и подключить вторую СХД и т.п., чтобы было всё по-взрослому.

                                      0

                                      В сторону Proxmox не смотрели? Там из коробки все получше затюнено, да и интерфейс посимпатичнее.

                                        0
                                        + за PVE.
                                        Для проекта ТС Proxmox-а хватило бы за глаза. PVE и с Openvswitch из-коробки дружит.
                                        Если же PVE «мелковат» для ТС, то смотреть в сторону Opennebula (в телеге есть чат с одним из лучших спецов по ней). oVirt, ИМХО, монстр (

                                        Зы. И почему VyOS? Есть же гораздо более удобные pfsense\opnsense — CARP умеют, AES-GCM пользуют (при наличие подходящих CPU), с BGP + OSPF — тоже ОК, snort + suricata в пакетах присутствуют — установка 3 нажатиями.
                                          0

                                          Нет, на Proxmox не смотрел, в первую очередь потому, что она на дебиане, а в организации используются дистрибутивы основанные на RHEL (CentOS, OL).
                                          Ничего против конечно не имею, можно рассмотреть конечно, но времени нет на всё :)
                                          Овирт из коробки тоже работает, ну может чуть сложнее заводится, но для этого статья и пишется, чтобы помочь с ним разобраться

                                            0
                                            А раз Вы за Proxmox, как на нем организовать подобную схему, как у автора в статье?
                                            Общая хранилка, общий LUN, отказоустойчивость, тонкие диски, снепшоты. Чем это организуется в PVE? Какая файловая система?
                                              0
                                              Ну тут без изучения матчасти никуда *смайлик*. Всё есть, все работает, давно и надежно. По ФС посмотрите здесь статью в их wiki (обратите внимание на таблицу, и на поле shared в ней), от себя скажу, что поддержка из коробки zfs дает очень интересные возможности, напр., асинхронную репликацию хранилки на второй сервер раз в N минут/часов средствами zfs. Да, с Ceph дружит, но с которых пол поддержку нужно сознательно поставить, и тогда управление будет из той же веб-консоли, что и Proxmox.

                                              Ну и да, и то, и то — это Линукс, так что будет работает всё, что в Линуксе работает. Разница только что один продукт на CentOS, другой на Debian, ну и PVE кажется из коробки чуть более тюнингованным (это готовый дистрибутив, который ставится быстро и просто, и в котором свое ядро с полезными патчами.

                                              Да, вот история развития версий: pve.proxmox.com/wiki/Roadmap#Proxmox_VE_6.1 — первая версия вышла в 2008 году.
                                                0

                                                Странно, что FC в табличке нет, не поддерживается что ли?
                                                Можно конечно обойтись и Posix совместимой файловой системой, но в таком случе, например, для ocfs2 нужно три хоста в кластере, чтобы не попасть с сплитбрейном.

                                                  0
                                                  FC не написан, потому что его нельзя настроить штатно из интерфейса в отличие от iSCSI. Те ручками из консоли придется настраивать подключения, multipath. Потом из интерфейcа уже можно использовать готовый диск.
                                                  НО Cluster LVM не поддерживает самое интересное как снапшоты, thin volumes, как вариант делать lvm-раздел, который форматировать уже в кластерную ФС.
                                                    0
                                                    «форматировать уже в кластерную ФС.» это в какую, например?
                                                    OCSF2? GFS2?
                                                    Что документация по ним в связке с PVE скудная, что используют их, похоже, 2.5 человека в такой конфигурации. На форумах PVE пяток тем может наскребётся, где сами и сами разработчики отплёвываются от таких вариантов.
                                                    Хотя это самый что ни на есть ынтырпрайз. Вот и получается, что PVE особо в энтерпрайзе не энтерпрайзит.
                                                      0

                                                      А других бесплатных кроме OCSF2 и GFS2 то особо не найти.
                                                      Причём вроде бы PVE в явном виде не умеет в OCSF2, и нужно будет компилировать ядро для её поддержки.
                                                      Или ставить OL7, где OCFS2 пока поддерживается, но не поддерживается PVE :))

                                                        0
                                                        Ага, об чём и речь…
                                                        0
                                                        А много кто в ентерпрайзе использует DRBD?
                                                        Как кто-то сказал: highload это нищебродство, в настоящем суровом ентерпрайзе, если нагрузка на сервере больше 30 процентов, то просто покупают новый сервер и ставят его рядом, или покупают новое хранилище и тд
                                                          0
                                                          Так дело не в покупке железок, а в том, что на них крутится. Какой толстый сервер не купи, если нужна отказоустойчивость или катастрофоустойчивость, их всё равно надо 2+. И чем-то эту *-устойчивость надо обеспечивать.
                                                          И вот что-то на Linux это всё как-то строится из костылей и палок.

                                                          Как я понимаю, нынешний Linux true-way — это отказоустойчивость на уровне приложения. Но вот с таким энтерпрайз сильно опаздывает. Привыкли к другим средствам.
                                              0

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


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


                                              С опеннебулой в своё время пришлось поработать немного, в году 2015, впечатления остались негативными (может из-за того, что с ceph они не подружились крепко) поэтому на неё даже смотрел, хотя наверняка что-то и поменялось, надеюсь в лучшую сторону.


                                              Опять овирт монстр :))) да всё нормально с ним, не монстрее он той же опеннебулы или какого клаудстака :))

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.