Делова Ферма — различия между версиями

Материал из Брацка Правки
Перейти к: навигация, поиск
(→‎Объявление)
 
(не показано 239 промежуточных версий 2 участников)
Строка 1: Строка 1:
−
[[Деловы Кластер]] -- это отказоустойчивый ([[high availability]]) кластер (здесь и далее по тексту -- ''Кластер'') на основе трёх "физических" ([[bare metal]]) узлов (здесь и далее по тексту -- ''Желез'') [[Брацки Фермы|Брацких Ферм]] (здесь и далее по тексту -- ''Ферм''), который обеспечивает высокую доступность услуг, предположительно, [[Брацка Сетка|Брацкой Сетки]] и, возможно, других приложений, которые принадлежат [[Делово Бюро|Делово Бюро]].
+
[[Делова Ферма]] (ранее называемая [[Деловы Кластер]]; здесь и далее -- ''Ферма'') -- это отказоустойчивый ([[high availability]]) кластер [[Брацки Фермы|Брацких Ферм]] (здесь и далее по тексту -- ''Ферм''), который обеспечивает работу и высокую доступность услуг приложений [[Делово Бюро|Делово Бюро]], так называемых [[деловы прилады|деловых прилад]].
  
 +
 +
==Общее описание==
 +
 +
===Общепринятые понятия===
 +
:На данной вики-странице, используются следующие термины для общепринятых понятий:
 +
:*'''[[A запись]]''' ([[A record]]). Та [[DNS запись]], которая определяет соответствующий доменному имени ([[domain name]]) [[IPv4 адрес]]. Когда пользователь [[Всемирная Паутина|Всемирной Паутины]] набирает доменное имя, например, "bskol.com", веб-просмотрщик ищет в зоне [[DNS]] тот [[IPv4 адрес]], к которому это доменное имя привязано. Буква "А" в названии записи, так называемый тип записи, пришла в название от первой буквы английского слова "address" (адрес).
 +
:*'''[[AAAA запись]]''' ([[AAAA record]]). Та [[DNS запись]], которая определяет соответствующий доменному имени ([[domain name]]) [[IPv6 адрес]]. Когда пользователь [[Всемирная Паутина|Всемирной Паутины]] набирает доменное имя, например, "bskol.com", веб-просмотрщик ([[web browser]]) ищет в зоне [[DNS]] тот [[IPv6 адрес]], к которому это доменное имя привязано. Четыре буквы "A" в типе этой записи символизируют тот факт, что максимальное количество адресов протокола [[IPv6]] (128 бит) в четыре раза превышает максимальное количество адресов протокола [[IPv4]] (32 биты).
 +
:*'''[[IP адрес]]''' ([[IP address]]). Адрес компьютерного устройства, соответствующий либо протоколу [[IPv4]], либо протоколу [[IPv6]]. Доступные в сети Интернет адреса куплены у поставщика услуг размещения.
 +
:*'''[[IPv4 адрес]]''' ([[IPv4 address]]). [[IP адрес]], соответствующий протоколу [[IPv4]]. Эти адреса представляют собою 4 группы цифр, разделённых точками. Например, 88.99.71.85 -- это один из адресов ''Фермы''. Часть адресов зарезервированы для частных сетей и не могут появляться в сети Интернет. Количество адресов [[IPv4]] ограничено 4.3 триллионами, что на момент разработки казалось достаточным числом. Протокол [[IPv4]] был разработан в 1981. Чтобы разрешить проблему ограничения, в 1995 году был разработан протокол [[IPv6]], однако на лето 2022 года, 62% Интернета продолжает пользоваться протоколом [[IPv4]]. В [[DNS зона|DNS зоне]], этот адрес указывается в [[A запись|"A" записи]].
 +
:*'''[[IPv6 адрес]]''' ([[IPv6 address]]). [[IP адрес]], соответствующий протоколу [[IPv6]]. Эти адреса представляют собою несколько групп цифр и букв, разделённых двоеточиями. Некоторые группы могут быть пустыми. Например, 2a01:4f8:fff0:53::2 -- это один из адресов ''Фермы'' и группы между сдвоенными двоеточиями пусты. В [[DNS зона|DNS зоне]], этот адрес указывается в [[AААА запись|"AААА" записи]].
 +
:*'''[[DNS]]''' ([[Domain Name System]]) -- иерархическая и децентрализованная система доменных имён, которая была изначально создана для привязки человечески-разпознаваемым [[доменное имя|доменных имён]] к машинно-обрабатываемым адресам протокола Интернет ([[IP адрес]]ам), а позже стала использоваться для определения других данных этих имён и адресов. Например, в текстовые записи может быть добавлен открытый ключ к подписи почты. [[DNS запись|DNS записи]] содержатся в так называемых [[DNS зона|DNS зонах]], которые предоставляют поставщики услуг Интернета ([[Internet service provider]] или [[ISP]]).
 +
:*'''[[DNS запись]]''' ([[DNS record]]) -- Привязка стандартизованных данных к конкретному доменному имени. Запись состоит из типа (type), например , "AAAA" в [[AAAА запись|AAAА записи]], названия (resource record), например, jitsi.bskol.com, и привязанных к названию данных (data). Вместе, записи составляют [[DNS зона|DNS зону]].
 +
:*'''[[DNS зона]]''' ([[DNS zone]]). Ta часть системы доменных имён ([[DNS]]), которая управляется отвечающим в системе за конкретное доменное имя поставщиком услуг Интернета ([[Internet service provider]] или [[ISP]]) и которая определяет данные, связанные с этим доменным именем. Эти данные представлены в виде [[DNS запись|DNS записей]], таких, как [[A запись]] или [[AAAA запись]].
 +
:*'''[[Виртуальная машина]]''' ([[virtual machine]] или [[VM]]). Виртуальное компьютерное устройство, имитирующее компьютер, создаваемое виртуальной средой. Аналогично обычному компьютеру, на VM устанавливается операционная система, обычно, из коробки, и, на неё, -- пользовательские приложения.
 +
:*'''[[Высокая доступность]]''' ([[high availability]] или [[HA]]). Свойство системы иметь более высокую продолжительность исправного состояния ([[uptime]]) по сравнению с идентичной системой, которая не использует инструментов и методик высокой доступности. Ни одна система и ни одна часть системы не могут быть полностью защищены от угрозы нештатной работы или аварийной ситуации. Высокую доступность можно описать как продолжение предоставления услуг системой на каком-то "исправном" уровне при сбое её определённой части с одновременным восстановлением той самой части, которая пострадала от сбоя. Инструменты высокой доступности включают дублирующие части, готовые взять на себя роль основных, устройства мониторинга для обнаружения случаев отказа, а также управляющие устройства, которые огораживают ([[fencing]]) неработающие части и перенаправляют запросы на работающие. Требование "исправного", пускай и аварийного, состояния отличает высокую доступность от концепции [[отказоустойчивость|отказоустойчивости]] ([[failure tolerance]]), которая стремится к тому, чтобы обычный пользователь системы отказа её части и не заметил.
 +
:*'''[[Доменное имя]]''' ([[domain name]], [[hostname]]). Воспринимаемое людьми название веб-сайта или иного ресурса, особенно в сети Интернет, например, "bskol.com". Веб-просмотрщики и другие устройства работают с [[IP адрес]]ами, но эти адреса трудны для запоминания и воспроизведения людьми; для них, созданы доменные имена. В зонах [[DNS]], доменные имена привязаны либо к [[IPv4 адрес]]у, либо к [[IPv6 адрес]]у, либо к обоим.
 +
:*'''[[Контейнер]]'''. Виртуальное компьютерное устройство, имитирующее компьютер с установленной операционной системой и пользовательскими приложениями, создаваемое виртуальной средой. Как правило, контейнеры задействуют облегчённую операционную систему, заточенную исключительно под работу установленных приложений.
 +
:*'''[[Операционная система]]''' ([[operating system]] или [[OS]]). Программное обеспечение, которое,  с одной стороны, взаимодействует либо с железным, либо с виртуальным компьютерным устройством и, с другой стороны, может взаимодействовать с пользовательскими приложениями.
 +
:*'''[[Отказоустойчивость]]''' ([[failure tolerance]]) -- это концепция такой работы системы, в которой конечный пользователь системы не может заметить отказа её части от штатной работы. Некоторые инструменты и методики отказоустойчивости аналогичны инструментам и методикам высокой доступности ([[high availability]]), которые способствуют предоставлению услуг системой при сбое её определённой части с одновременным восстановлением той самой части, которая пострадала от сбоя. Однако никакой набор не гарантирует, что любое восстановление будет моментальным и 100% полным. Потому "отказоустойчивость" -- это всё же концепция, к которой можно стремиться, но не конечная точка, которую можно достичь.
 +
:*'''[[Поставщик услуг Интернета]]''' ([[Internet service provider]] или [[ISP]]). Организация, авторизованная администрацией сети Интернет на предоставление [[доменное имя|доменных имён]] и других услуг Интернета. С некоторыми исключениями, поставщики услуг Интернета предоставляют доступ к сети напрямую конечным пользователям или посредникам. Многие поставщики услуг Интернета являются также и [[поставшик услуг размещения|поставщиками услуг размещения]].
 +
 +
===Специальные термины===
 +
:На данной вики-странице, используются следующие термины, которые специфичны для этой страницы:
 +
:*'''[[Железo]]''' ([[bare-metal server]]). "Физический, железный" сервер, арендуемый у поставщика услуг размещения и описанный в [[#Инфраструктура|Инфраструктуре]].
 +
:*'''[[Пользовательское приложение]]'''. Одна из установленных на ''Ферме'' [[деловы прилады|деловых прилад]].
 +
:*'''[[Поставщик услуг размещения]]'''. Поставщик услуг Интернета ([[Internet service provider]] или [[ISP]]), предоставляющий свои подключённые к сети Интернет "железные" сервера в аренду для размещения ''Фермы''.
 +
:*'''[[Соединитель]]'''. Коммутационное устройство предоставляемое поставщиком услуг размещения ''Фермы'' и описанное в [[#Соединители|Соединителях]].
 +
:*'''[[Среда]]''' ([[virtual environment]]). Виртуальнaя среда на базе программного обеспечения [[ProxmoxVE]], описанная в [[#Виртуальные среды|Виртуальных средах]].
 +
:*'''[[Узел]]''' ([[node]]). Комбинация одного ''Железа'' и установленного на нём программного обеспечения, представленная в сети и описанная в [[#Узлы Фермы|Узлах Фермы]].
 +
:*'''Ферма'''. ''Делова Ферма'', для описания которой предназначена данная вики-страница.
 +
:*'''[[Хранилище]]'''. Система для хранения объектов, блоков и файлов, которые ''Ферма'' либо обрабатывает, либо предоставляет пользователям без обработки. Термины "хранилище Узла" или, во множественном числе, "хранилища", подразумевают системы хранения на отдельном ''Узле''. Система описана в [[#Хранилища Узлов|Хранилищах Узлов]].
 +
 +
===Архитектура===
 +
:'''Для предоставления услуг''' пользователям:
 +
:#Пользовательские приложения ''Фермы'' установлены:
 +
:#*либо в контейнерах, которые уже содержат подогнанные исключительно под нужды приложения операционные системы.
 +
:#*либо на виртуальных машинах. Для взаимодействия виртуальной машины и приложения, операционные системы "из коробки" установлены в машинах перед установкой приложений.
 +
:#Контейнеры и виртуальные машины ''Фермы'' создаются в виртуальных средах.
 +
:#Виртуальные среды ''Фермы'' требуют для работы "физические", так называемые "железные", сервера ([[bare-metal server]]; здесь и далее по тексту -- ''Железа'').
 +
:#Взаимодействие виртуальных сред с ''Железом'' осуществляется специально-ориентированной на это взаимодействие [[операционная система|операционной системой]]. В сети, комбинация одного ''Железа'' и установленного на нём программного обеспечения называется "узловым центром" (node; здесь и далее, ''Узлом'').
 +
 +
:'''Для высокой доступности''' ([[high availability]] или [[HA]]) и отказоустойчивости услуг:
 +
:*Задействуются три ''Узла'', объединённые в единые сети [[#Соединители|Соединителями]]. Два из трёх ''Узлов'' являются "несущими"; их базы синхронизованы и изменение в одной базе влечёт автоматическое изменение в другой. Из двух несущих, одно является основным. Третий ''Узел'' -- это требование используемого для создания виртуальных сред программного обеспечения [[ProxmoxVE]] для обеспечения кворума.
 +
:*В обычном режиме, веб-просмотрщик (web browser) пользователя обращается к [[IP адрес]]у [[Hetzner vSwitch]], который отправляет пользователя к основному ''Узлу''.
 +
:*Если основной ''Узел'' неспособен обслуживать клиентов, виртуальная среда изолирует его и переключает клиентов на второй несущий, работающий ''Узел''.
 +
 +
:'''Отказоустойчивость требует''' пару дополнительных функций:
 +
:#Для обнаружения сбоя или другой нештатной ситуации, ''Ферма'' постоянно мониторится. Сигнал о сбое поступает в виртуальную среду, которая ограждает (fencing) ''Узел'' со сбоем и запускает процесс восстановления данных с резервной копии.
 +
:#Для восстановления данных в случае их потери из-за сбоя или другой нештатной ситуации, каждый ''Узел'' постоянно проводит резервное копирование.
 +
 +
==Доступы==
 +
===Администраторские===
 +
:#Администраторский доступ к ''Железу'', а также к соединителям [[Hetzner vSwitch]] осуществляется через административную панель и администраторские консоли. Они предоставлены непосредственно [[Hetzner]] заказчику; заказчик лично может предоставить доступы ответственным администраторам.
 +
:#Администраторский доступ к виртуальным средам [[ProxmoxVE]] и, далее, файлам пользовательских приложений, осуществляется через привязанные к ''Железу'' [[IP адрес]]а. Данные доступов засекречены и хранятся в [[Брацка Крынка|Брацкой Крынке]].
 +
:#Администраторские доступы к пользовательским приложениям осуществляются через привязанные к приложениям [[IP адрес]]а. В данный момент, доступы предоставляются бюрократами [[Оплёт]]а вручную.
 +
 +
===Пользовательские===
 +
:#Те пользователи, которые администраторами не являются, не должны иметь доступ к ''Железу'' и ''Средам''.
 +
:#Доступы тех пользователей, которые администраторами не являются, к пользовательским приложениям осуществляются через привязанные к приложениям [[IP адрес]]а. Доступы предоставляются [[Оплёт]]ом автоматически и, бюрократами [[Оплёт]]а, вручную.
  
 
==Инфраструктура==
 
==Инфраструктура==
 +
Инфраструктура ''Фермы'' -- это объединённые в единую связку три ''Железа''.
 +
 +
===Поставщик Железа===
 +
:[[Hetzner]] является поставщиком услуг размещения, у которого "Железо" арендуется. Сотрудничество с данным поставщиком длится с 2016 года. Другие поставщики периодически рассматриваются, но никто другой не предлагал более низких цен на долгосрочной основе.
  
−
===Размещение===
+
===Выбор Железа===
−
:[[Hetzner]] является поставщиком услуг размещения, у которого "Железо" арендуется.
+
:Из-за меньшей стоимости, ''Железo'' выбрано на аукционе -- https://www.hetzner.com/sb?hdd_from=500&hdd_to=1000 исходя из следующих предпосылок:
 +
:*Целевой рабочий объём жёсткого диска для этой ''Фермы'' -- 512Gb.
 +
:*Как минимум один, основной сервер выбран с [[SSD]] и, желательно, [[NVMe]], и частотой процессора в 64Gb.
 +
:*Как минимум два "несущих" сервера выбраны в одном датацентре. Хотя [[Hetzner]] не берёт оплату за траффик, это обстоятельство повышает скорость работы ''Фермы''. Если второй сервер не был бы доступен в том же датацентре, мы искали бы его в других датацентрах то же города или месторасположения.
 +
:*Подрядчик предпочёл сервер на процессоре Intel Xeon E3-1275v5 серверу на Intel Core i7-7700.
 +
:*Требования к третьему ''Железу'' ниже, чем к "несущим". Один кандидат утверждал, что его объём может быть меньше, так как на нём может быть установлен только [[ProxmoxVE]].
 +
:[[#Характеристики Железа|Характеристики Железа]] представлены ниже.
  
−
===Отказоустойчивость===
+
===Соединители===
−
:Три ''Железа'' необходимы для обеспечения высокой доступности, из который два являются "несущими", из которых одно является основным. Если основное ''Железо'' неспособно обслуживать клиентов, ''Кластер'' изолирует его и переключает клиентов на второе несущее, работающее ''Железо''. Третье ''Железо'' -- это требование [[ProxmoxVE]] для обеспечения кворума. [[#Характеристики Железа|Характеристики Железа]] представлены ниже.
+
:Для объединения ''Узлов'' в сети, используются инструменты [[Hetzner vSwitch]]. Их хозяином является поставщик услуг размещения; команда может заказать присоединeние к одному ''Железу'' до 5 соединителей. Право на присоединение соединителей предоставляется вместе с арендой ''Железа''.
  
−
===Сеть инфраструктуры===
+
:На соединителях построены внутренняя и внешняя сети. Каждый из соединителей имеет свой [[IP адрес]], внутренний или внешний:
−
:Для объединения трёх ''Желез'' в сеть используется инструмент [[Hetzner vSwitch]].
+
:*Внутренние соединители обеспечивают передачу данных между ''Узлами''. Прежде всего, такая передача жизненно необходима синхронизации хранилищ отдельных ''Узлов''.
 +
:*Соединители с внешними, доступными из сети Интернет, [[IP адрес]]ами, распределяют запросы из сети Интернет между ''Узлами'' и возвращают ответы ''Узлов'' на запросы назад в сеть Интернет.
 +
:Инструменты ''Фермы'' не поддерживают и не могут поддерживать высокой доступности соединителей. За отказоустойчивость соединителей отвечает их хозяин, поставщик услуг размещения [[Hetzner]].
  
 
==Характеристики Железа==
 
==Характеристики Железа==
−
''Железo'' для [[#Инфраструктура|Инфраструктуры]] выбрано на аукционе -- https://www.hetzner.com/sb?hdd_from=500&hdd_to=1000 -- поделившись экраном с выбранным подрядчиком исходя из следующих соображений:
+
В результате процесса [[#Выбор Железа|Выбора Железа]], были выбраны сервера со следующими характеристиками:
−
:*Целевой рабочий объём жёсткого диска для этого ''Кластера'' -- 512Gb.
 
−
:*Как минимум один, основной сервер выбран с [[SSD]] и, желательно, [[NVMe]], и частотой процессора в 64Gb.
 
−
:*Как минимум два "несущих" сервера выбраны в одном датацентре. Хотя [[Hetzner]] не берёт оплату за траффик, это обстоятельство повышает скорость работы ''Кластера''. Если второй сервер не был бы доступен в том же датацентре, мы искали бы его в других датацентрах то же города или месторасположения.
 
−
:*Подрядчик предпочёл сервер на процессоре Intel Xeon E3-1275v5 серверу на Intel Core i7-7700.
 
−
:*Требования к третьему железу ниже, чем к "несущим". Один кандидат утверждал, что его объём может быть меньше, так как на нём может быть установлен только [[ProxmoxVE]].
 
  
 
===Железо 1===
 
===Железо 1===
Строка 51: Строка 117:
 
:* 1 x Primary IPv4
 
:* 1 x Primary IPv4
  
−
==Виртуальные среды==
+
===Железо 4===
−
Виртуальная среда каждого ''Железа'' собрана на основе [[ProxmoxVE]] (здесь и далее -- "Среды''), в данный момент, v.7.2.
+
:1 x Dedicated Root Server "Server Auction"
 +
:* Intel Xeon E5-1650V3
 +
:* 2x HDD SATA 2,0 TB Enterprise
 +
:* 8x RAM 16384 MB DDR4 ECC reg.
 +
:* NIC 1 Gbit Intel I210
 +
:* Location: FSN1
 +
:* Rescue system (English)
 +
:* 1 x Primary IPv4
 +
 
 +
==Узлы Фермы==
 +
Работа ''Фермы'' обеспечивается тремя ''Узлами''. Каждый ''Узел'' представляет собой отдельное ''Железо'', приводимoe в действие несколькими видами программного обеспечения (ПО).
  
−
===Сети Сред===
+
===Резервное копирование===
−
:Сеть каждой ''Среды'' использует мост по выбираемой по умолчанию в [https://pve.proxmox.com/wiki/Network_Configuration#_default_configuration_using_a_bridge Network Configuration] модели.
+
:[[OpenZFS]] или [[RAID]] создаёт резервные копии и может быть задействовано для восстановления данных ''Железа'' в случае аварий. Жёсткие диски каждого ''Железа'' сдвоены, как, например, 2x SSD SATA 512 GB. [[RAID]] или [[OpenZFS]] копирует данные основного диска ''Железа'' на резервный диск. Если основной диск теряет данные из-за сбоя, резервный диск будет использован для восстановления данных на основной диск. [[RAID]] или [[OpenZFS]] устанавливается непосредственно на ''Железо''.
  
−
===Хранилища Сред===
+
===Виртуальные среды===
−
:Для хранения данных, каждая ''Среда'' использует платформу распределённого хранилища Ceph.
+
:[[ProxmoxVE]], в данный момент, v.7.2, создаёт виртуальные среды (здесь и далее -- ''Среды''). Это программное обеспечение взаимодействует с ''Железом'' через [[операционная система|операционную систему]] [[Debian]], под которую оно настроено. Эта операционная система приходит в одной коробке с [[ProxmoxVE]].
  
−
===Защитные стены===
+
==Сети Узлов==
−
:Для раздачи адресов виртуальным машинам, каждая ''Среда'' использует программу [[iptables]].
+
Сеть каждого ''Узла'' использует мост по выбираемой по умолчанию в [https://pve.proxmox.com/wiki/Network_Configuration#_default_configuration_using_a_bridge Network Configuration] модели.
 +
 
 +
===Хранилища Узлов===
 +
:Для хранения данных, каждый ''Узел'' использует платформу распределённого хранилища [[Ceph]]. Хранилища отдельныx ''Узлов'' синхранизуются через внутреннюю сеть инфраструктуры.
 +
 
 +
:Таким образом, всё хранилище ''Фермы'' включает специально-зарезервированные дисковые пространства ''Желез'' и программное обеспечение, работа которого распределена по всем ''Узлам''. Благодаря этому обеспечению, хранилища отдельных ''Узлов'' синхранизованы между собою, чтобы исключить единую точку отказа.
 +
 
 +
===IP адреса===
 +
:В сетях [[ProxmoxVE]], мы задействуем три типа [[IP адрес]]ов:
 +
:#Для управления средами [[ProxmoxVE]], мы используем [[IPv4 адрес]]а и [[IPv6 адрес]]а отдельных ''Желез''.
 +
:#Для внутренней сети из трёх ''Желез'', собранной на одном [[Hetzner vSwitch]], задействуется частный [[IP адрес]]. Эта сеть не доступна из сети [[Интернет]]; прежде всего, через неё синхранизуются хранилища ''Желез''. Для этой сети, выбран адрес с типом "/24" .
 +
:#Внешняя сеть требует покупки дополнительных [[IP адрес]]ов, причём [[IPv4 адрес]]а дороги, а [[IPv6 адрес]]а, возможно, могут не обеспечивать стабильной работы. В данный момент, мы купили один [[IPv6 адрес]] и тестируем его. Этот [[IPv6 адрес]] будет присваиваться всем [[VM]] и [[контейнер]]ам, которые будут создаваться в инфраструктуре. Чтобы работать с ресурсами ''Фермы'', пользователи будут запрашивать именно этот адрес. Эта сеть также собрана на тех же ''Железах'' другим [[Hetzner vSwitch]].
 +
 
 +
===Веб-сервер===
 +
:В качестве веб-сервера одни приложения будут использовать [[apache]], а другие [[nginx]].
 +
 
 +
===DNS зона===
 +
:Для связи с сетью Интернет, следующие записи созданы в зоне [[DNS]]:
 +
:{|class="wikitable"
 +
!Resource record!!Type!!Data!!Комментарий (не являющийся частью записи)
 +
|-
 +
|pm1.bskol.com||AAAA||2a01:4f8:10a:439b::2||Среда 1
 +
|-
 +
|pm2.bskol.com||AAAA||2a01:4f8:10a:1791::2||Среда 2
 +
|-
 +
|pm3.bskol.com||AAAA||2a01:4f8:10b:cdb::2||Среда 3
 +
|-
 +
|pbs.bskol.com||AAAA||2a01:4f8:fff0:53::6||Сервер резервных копий Сред
 +
|-
 +
|pf.bskol.com||AAAA||2a01:4f8:fff0:53::6||rowspan="2"|pfsense
 +
|-
 +
|pf.bskol.com||A||88.99.71.85
 +
|-
 +
|npm1.bskol.com||A||88.99.218.172||NGINX Среды 1
 +
|-
 +
|npm2.bskol.com||A||88.99.71.85||NGINX Среды 2
 +
|-
 +
|npm3.bskol.com||A||94.130.8.161||NGINX Среды 3
 +
|-
 +
|jitsi.bskol.com||AAAA||2a01:4f8:fff0:53::2||[[Брацки Жици|Жици]] ([[Jitsi]])
 +
|-
 +
|jitsi1.bskol.com||A||88.99.218.172||Доступ по IPv4 к [[Брацки Жици|Жици]] ([[Jitsi]])
 +
|-
 +
|sprava.bskol.com||AAAA||2a01:4f8:fff0:53::3||[[Брацка Справа|Справа]] ([[Odoo]])
 +
|-
 +
|sprava2.bskol.com||A||88.99.71.85||Доступ по IPv4 к [[Брацка Справа|Справе]] ([[Odoo]])
 +
|-
 +
|setka.bskol.com||AAAA||2a01:4f8:fff0:53::4||[[Брацка Сетка|Сетка]] ([[HumHub]])
 +
|-
 +
|setka2.bskol.com||A||88.99.71.85||Доступ по IPv4 к [[Брацка Сетка|Сетке]] ([[HumHub]])
 +
|-
 +
|svazka.bskol.com||AAAA||2a01:4f8:fff0:53::5||[[Брацки Связка|Связка]] ([[SuiteCRM]])
 +
|-
 +
|svazka2.bskol.com||A||88.99.71.85||Доступ по IPv4 к [[Брацки Связка|Связке]] ([[SuiteCRM]])
 +
|}
  
 
==Пользовательские прилады==
 
==Пользовательские прилады==
−
===ПО прилад===
+
''Ферма'' обеспечивает высокую доступность [[Брацка Сетка|Брацкой Сетки]], [[Брацка Справа|Брацкой Справы]] и, возможно, других приложений, которые принадлежат [[Делово Бюро|Делово Бюро]].
  
−
===Содержимое прилад===
+
===Сетка===
 +
*[[Брацка Сетка]] -- это брацкая прилада, которая представляет собою систему поддержки социальной сети, построено на базе готового программного решения [[HumHub]].
  
−
==Поиск подрядчиков==
+
===Справа===
−
Для ускорения проекта и привлечения сторонней экспертизы, Каролина мы привлекаем подрядчиков на изготовление ''Кластера'' по разработанным на этой вики-странице требованиям.
+
*[[Брацка Справа]] -- это средство управления людскими и материальными ресурсами предприятия, построенное на основе программного обеспечения [[Odoo]].
  
−
===Объявление===
+
===Жици===
−
:Объявление на разовую работу опубликовано на [[upwork]]:<blockquote><p>Guys, we need the most affordable well-documented HA ProxmoxVE 7.2 cluster that is assembled on three Hetzner nodes: 2 Intel Xeon E3-1275v5/2x SSD M.2 NVMe 512 GB/4x RAM 16384 MB DDR4 ECC/NIC 1 Gbit Intel I219-LM and one Intel Core i7-7700/2x SSD SATA 512 GB/2x RAM 16384 MB DDR4/NIC 1 Gbit Intel I219-LM. Each has a primary IPv4.</p><p>Ceph, IPtables, vSwitch. We plan that each node would have one VM or container for testing.</p><p>We see two parts of acceptance testing. During software testing, we will shut down 2 of 3 nodes to see whether the cluster is still available. During documentation testing, we will erase the software from one, implement the rescue, and one expert will try to restore the software using your documentation. She will video-record her attempts and, if not successful, will provide you with the recording, so either you can show her errors or correct yours. If the restoration is successful, the contract shall be considered completed.</p><p>What else do you need? If nothing, please give your minimum project budget (your project fare + initial purchases + first year costs) and timeframe up to 2-3 weeks. To complete the project, the selected contractor will be given an admin access, but not full robot credentials.</p></blockquote>
+
*[[Брацки Жици]] -- это инструмент Брацкой Школы для организации видео- и аудио-конференций, построена на основе программного обеспечения [[Jitsi]].
  
−
===Принцип отбора===
+
===Связка===
−
:Нам нужен кластер с нуля и мы отдадим подряд тому,
+
*[[Брацка Связка]] --  это брацкая прилада, которая представляет собою систему управления взаимоотношениями с клиентами, построена на основе программного обеспечения SuiteCRM.
 +
 
 +
==Мониторинг==
 +
:Сейчас не используется специальные функции.
 +
:Предложения кандидатов:
 +
:#Стек -- [[prometheus]] + node-exporter + [[grafana]]
 +
:#[[Prometheus]] to monitor VMs, Influx to monitor Pve nodes , [[Grafana]] for Dashbord
 +
:#(M) [[grafana]] + [[influxdb]] + [[telegraf]], а также [[zabbix]]. Для мониторинга веб-сайта использовать [[uptimerobot]]
 +
 
 +
==История разработки==
 +
 
 +
===Предыстория===
 +
:Пользовательские приложения [[Делово Бюро|Делова Бюро]] изначально ставились на то, что сейчас называется [[Кампусна Ферма|Кампусной Фермой]]. При создании курса [[Брацки Техобзор]] появилась идея вынести их на отдельную платформу. Идея развилась, когда было решено создать кластер на "железных" серверах.
 +
 
 +
===Собственные попытки===
 +
:Весной 2022 года, в дополнение к железному серверу [[Опытна Ферма|Опытной Фермы]], был арендован второй "железный" сервер. Наталья и подрядчик Андрей собственными силами в течение пары месяцев пытались сделать из них кластер.
 +
 
 +
===Советы по созданию===
 +
:В результате собственных попыток, стало понятно, что компетенций команды для создания кластера не хватает. Для получения сторонней экспертизы, следующее объявление было размещено на [[Upwork]]:<blockquote><p><strong>Hetzner/RAID/Proxmox consultant is needed</strong>&nbsp;<i>Tech Support</i></p><p>Hey, guys, I need a consultant for this project - https://pravka.bskol.com/en/CNMC_bare-metal. I plan to buy a bare-metal server at hetzner.de, setup RAID and Proxmox, as well as start setting up the rest of technology</p></blockquote>
 +
:По итогам консультаций, были сформулированы задания на создание кластера. [[Деловы прилады]] были выбраны в качестве "жителей" этого кластера из-за того, что требования [[кампусны прилады|кампусных прилад]] к инфраструктуре ниже.
 +
 
 +
===Создание кластера===
 +
:Летом 2022-го, проект создания кластера был оформлен и Каролина была назначена координатором. Она привлекала подрядчиков на изготовление ''Фермы'' по разработанным на этой вики-странице требованиям.
 +
 
 +
:Объявление на разовую работу было опубликовано на [[Upwork]]:<blockquote><p><strong>HA Proxmox Hetzner cluster is needed</strong>&nbsp;<i>Systems Administration</i></p><p>Guys, we need the most affordable well-documented HA (high availability) ProxmoxVE 7.2 cluster that is assembled on three Hetzner nodes:</p><ul><li>2 Intel Xeon E3-1275v5/2x SSD M.2 NVMe 512 GB/4x RAM 16384 MB DDR4 ECC/NIC 1 Gbit Intel I219-LM and</li><li>One Intel Core i7-7700/2x SSD SATA 512 GB/2x RAM 16384 MB DDR4/NIC 1 Gbit Intel I219-LM.</li></ul><p>Ceph, iptables. We plan that each node would have one VM or container for testing. We will assign a domain name to that.</p><p>Each has a primary IPv4. However, there are some unresolved issues related to the network. Initially, we planned to use vSwitch; however, it seems to require additional IP addresses, from which IPv4 are expensive and IPv6 may not be able to deliver HA. Thus, we plan to offer two different contract prices -- one is if we need to buy additional IPv4 addresses for vSwitch and another is if we don't.</p><p>We see two parts of acceptance testing. If both are successful, the contract shall be considered completed.</p><ol><li>During software testing, we will shut down 2 of 3 nodes to see whether the cluster is still available.</li><li>During documentation testing, we will erase the software from one, implement the rescue, and one expert will try to restore the software using your documentation. She will video-record her attempts and, if not successful, will provide you with the recording, so either you can show her errors or correct yours.</li></ol><p>What else do you need? If nothing, please give your minimum project budget (your project fare + initial costs of additional purchases such as setup fees for additional IP addresses, if any, required by the contract + first year costs of additional purchases, if any) and timeframe up to 2-3 weeks.</p><p>This project is a fixed-price one. When we send you an offer, we will change the terms. To complete the project, the selected contractor will be given an admin access, but not full robot credentials, for three weeks. After three weeks, that access would be revoked; if you don't complete the project by that time, you will never finish it!</p></blockquote>
 +
 
 +
:Подрядчики отбирались по следующему принципу. Нам нужен кластер с нуля и мы отдадим подряд тому,
 
:#Кто сможет это сделать,
 
:#Кто сможет это сделать,
 
:#В чьём графике завершение контракта не растянется на более, чем два месяца, и
 
:#В чьём графике завершение контракта не растянется на более, чем два месяца, и
−
:#Чей бюджет будет наименьший. Имеется в виду весь бюджет, включая и оплату подрядчиков, и расходы на покупку и ежегодного поддержания ''Кластера''.
+
:#Чей бюджет будет наименьший. Имеется в виду весь бюджет, включая и оплату подрядчиков, и расходы на покупку и ежегодного поддержания ''Фермы''.
 +
 
 +
:Контракт был присуждён 8-го июля со сроком действия до 12 августа 2022 года.
 +
 
 +
:Подрядчик завершил роботу по контракту, результатом которой есть кластер ProxmoxVE 7.2 HA реализован на трех узлах Hetzner c помощью vSwitch. В процессе разработки и на этапе приемки было выявлено ряд проблем, решение которых было вынесено на следующий проект. Основная проблема с доступом до кластеру, на данный момент доступ реализован с помощью дополнительного IPv6. Однако это решение не дает достаточной доступности нашему кластеру, так как не все поставщики Интернет услуг работают с ним. Хорошим решением есть покупка IPv4 для этой цели, но это очень затратное. По этому было принято решения поискать другие варианты решения. Так же много вопросов осталось относительно улучшения безопасности, резервного копирования и мониторинг кластера.
 +
 
 +
===Доступ IPv4===
 +
:Кластер ProxmoxVE 7.2 HA реализован на трех узлах Hetzner c помощью vSwitch. Для внешнего доступа к кластеру используется IPv6, что ограничивает его доступность в Интернете. Можно использовать дополнительный IPv4. Нас интересуют другие способы решения на вход.
 +
 
 +
:Объявление на разовую работу было опубликовано на Upwork:
 +
:Guys, we need IPv4 access to our HA (high availability) ProxmoxVE 7.2 cluster that is assembled on three Hetzner nodes through vSwitch.
  
−
===Собеседования===
+
:We know that we can add a IPv4 net to vSwitch. Do we have other options?
−
:Найм людей -- отличный способ узнать об аспектах проекта и получаемого в его процессе изделия. Идеально проведённые собеседования добавляют документации на Правку.
 
  
−
===Полученные заявки===
+
:As the same or separate projects, we would also like to consider some improvements to its security (right now, we use iptables only), backup (right now, we deploy Proxmox backup only, no ZFS, no RAID1 nor anything else), and monitoring (no any special features is deployed).
−
:Мы можем публиковать полученные заявки, но не публикуем имена подрядчиков, так как они нам на публикацию разрешений не давали. С юридической точки зрения, мы не можем публиковать конфиденциальную информацию наших подрядчиков.
 
  
−
==Порядок разработки==
+
===Варианты на вход===
 +
:#На вход поставить [[HAProxy]] на отдельном VPS.
  
−
===Кто и что===
+
===Безопасность===
−
:Заказчик платит за ''Кластер'' и согласовывает эту вики-страницу перед присуждением подряда. Заказчик подразумевает, что координатор отработает проект, в том числе, документируя требования на этой вики-странице и ставя задачи подрядчику. По доброте душевной и в целях профессиональной подготовки, заказчик может делать работу координатора временно до той поры, пока заказчик верит в то, что координатор когда-то сможет работать самостоятельно :)
+
:На данный момент используются только [[iptables]]. Вопросы относительно улучшения безопасности вынесены на отдельный проект.
 +
:Предложение от кандидатов:
 +
:# [[ipset]] + [[fail2ban]] + [[iptables]]
 +
:# [[Pfsense FW]]
 +
:#(M) firewall + [[fail2ban]].
  
−
===Как не надо===
+
===Резервное копирования===
−
:*Знаходимо людину, яка нас задовільняє на даний проект (або декілька людей), так как он или она хорошо говорит, пишет, выглядит, вовремя выходит на связь, быстро отвечает и так далее.
+
:На данный момент используется резервное копирования Proxmox ([[Proxmox Backup Server]]). Рассматриваются  другие возможности резервного копирования.
−
:*Зв'язуємось (бажано дзвінком) для уточнення деталей і надання необхідних даних (в цей же етап можна задавати питання про сервера, які, куди, як..).
 
−
:*Согласовываем полученные детали, щоб розуміти всі ці тонкощі і надавати комусь якісь доступи - заслуховуємо його или её оцінку по бюджету цього проекту - розуміємо підходить нам чи ні.
 
−
:*Даємо роботу або відмовляємо.
 
  
−
===Как надо===
+
===Ввод в работу===
−
#Задокументировать требования на этой вики-странице. Эти требования должны включать описание того, что мы должны получить (так называемые "[[#Объёмы работ|Объёмы работ]]") и как мы о том узнаем (так называемая "[[#Приёмка|Приёмка]]").
 
−
#Перевести указанные в "[[#Объёмы работ|Объёмы работ]]" секции и секцию "[[#Приёмочные тесты|Приёмочные тесты]]" на английский и включить в контракт. Если они не включены, то мы получим то, что нам надо в одном случае из 100. В 99 остальных случаях, мы получим то, что нам не надо или за те деньги, на которые мы не рассчитываем.
 
−
#Действовать далее по рубрике [[#Как не надо|Как не надо]]; после выполнения предыдущих пунктов, она имеет смысл.
 
  
 
==Передача и приёмка==
 
==Передача и приёмка==
Строка 109: Строка 273:
 
===Приёмочные тесты===
 
===Приёмочные тесты===
 
:Для того, чтобы убедиться в том, что то, что представлено подрядчиком -- это то, что нам надо (aka отвечает критериям приемлемости), порядок приёмочного тестирования установлен следующим:
 
:Для того, чтобы убедиться в том, что то, что представлено подрядчиком -- это то, что нам надо (aka отвечает критериям приемлемости), порядок приёмочного тестирования установлен следующим:
−
:#Созданный ''Кластер'' тестируем, насильно отключивши два случайно выбранные ''Железа'' из трёх доступных. Если ''Кластер'' продолжает работать, то сборка принимается.
+
:#Созданную ''Ферму'' тестируем, насильно отключивши два случайно выбранные ''Железа'' из трёх доступных. Если ''Ферма'' продолжает работать, то сборка принимается.
−
:#Программное обеспечение случайно выбранного ''Железа'' (одного из трёх) удаляется и наш специалист, Natly, восстанавливает его по созданной документации, одновременно записывая восстановление на видео. Восстановленный ''Кластер'' тестируется аналогично созданному. Если ''Кластер'' продолжает работать, то документация принимается. Если нет, то видео передаётся подрядчику для доработки документации или указания ошибок Natly.
+
:#Программное обеспечение случайно выбранного ''Узла'' (одного из трёх) удаляется и наш специалист, Natly, восстанавливает его по созданной документации, одновременно записывая восстановление на видео. Восстановленная ''Ферма'' тестируется аналогично созданной. Если ''Ферма'' продолжает работать, то документация принимается. Если нет, то видео передаётся подрядчику для доработки документации или указания ошибок Natly.
  
 
==Вопросы для прояснения==
 
==Вопросы для прояснения==
 
===Архитектура платформы===
 
===Архитектура платформы===
 
:Есть две окончательно неразрешённые проблемы касаемые [[#ПО платформы|ПО платформы]]:
 
:Есть две окончательно неразрешённые проблемы касаемые [[#ПО платформы|ПО платформы]]:
−
:*Один подрядчик предлагает вместо Ceph задействовать TrueNAS.
+
:*Один подрядчик предлагает вместо [[Ceph]] задействовать [[TrueNAS]].
−
:*До начала проекта, один специалист предлагал использовать роутер [[Microtik]], чтобы на proxy сделать два IP адреса, первый использовать для внутренних виртуалок, если они нормально работают, а второй загнать в bridge для внешних серверов и средствами Линукса типа firewall делить тот трафик, который приходит. Кроме того, на том же proxy он предлагал поставить [[DHCP]] сервер для раздачи адресов машинам. Другой специалист считал, что безопасных [[DHCP]] серверов на рынке нет. В результате, роутеры и [[DHCP]] сервер не устанавливались.  
+
:*До начала проекта, один специалист предлагал использовать роутер [[Microtik]], чтобы на proxy сделать два IP адреса, первый использовать для внутренних виртуалок, если они нормально работают, а второй загнать в bridge для внешних серверов и средствами Линукса типа firewall делить тот трафик, который приходит. Кроме того, на том же proxy он предлагал поставить [[DHCP]] сервер для раздачи адресов машинам. Другой специалист считал, что безопасных [[DHCP]] серверов на рынке нет. В результате, роутеры и [[DHCP]] сервер не устанавливались.
  
 
===Начало работы===
 
===Начало работы===
Строка 127: Строка 291:
 
*https://pve.proxmox.com/wiki/High_Availability (general [[ProxmoxVE]] [[HA]] functionality)
 
*https://pve.proxmox.com/wiki/High_Availability (general [[ProxmoxVE]] [[HA]] functionality)
 
*https://docs.hetzner.com/robot/dedicated-server/network/vswitch/ (general [[Hetzner vSwitch]] functionality)
 
*https://docs.hetzner.com/robot/dedicated-server/network/vswitch/ (general [[Hetzner vSwitch]] functionality)
 +
 +
==Связанные лектио==
 +
*[[Что Есть Фермы]]

Текущая версия на 17:33, 11 сентября 2022

Делова Ферма (ранее называемая Деловы Кластер; здесь и далее -- Ферма) -- это отказоустойчивый (high availability) кластер Брацких Ферм (здесь и далее по тексту -- Ферм), который обеспечивает работу и высокую доступность услуг приложений Делово Бюро, так называемых деловых прилад.


Содержание

Общее описание

Общепринятые понятия

На данной вики-странице, используются следующие термины для общепринятых понятий:
  • A запись (A record). Та DNS запись, которая определяет соответствующий доменному имени (domain name) IPv4 адрес. Когда пользователь Всемирной Паутины набирает доменное имя, например, "bskol.com", веб-просмотрщик ищет в зоне DNS тот IPv4 адрес, к которому это доменное имя привязано. Буква "А" в названии записи, так называемый тип записи, пришла в название от первой буквы английского слова "address" (адрес).
  • AAAA запись (AAAA record). Та DNS запись, которая определяет соответствующий доменному имени (domain name) IPv6 адрес. Когда пользователь Всемирной Паутины набирает доменное имя, например, "bskol.com", веб-просмотрщик (web browser) ищет в зоне DNS тот IPv6 адрес, к которому это доменное имя привязано. Четыре буквы "A" в типе этой записи символизируют тот факт, что максимальное количество адресов протокола IPv6 (128 бит) в четыре раза превышает максимальное количество адресов протокола IPv4 (32 биты).
  • IP адрес (IP address). Адрес компьютерного устройства, соответствующий либо протоколу IPv4, либо протоколу IPv6. Доступные в сети Интернет адреса куплены у поставщика услуг размещения.
  • IPv4 адрес (IPv4 address). IP адрес, соответствующий протоколу IPv4. Эти адреса представляют собою 4 группы цифр, разделённых точками. Например, 88.99.71.85 -- это один из адресов Фермы. Часть адресов зарезервированы для частных сетей и не могут появляться в сети Интернет. Количество адресов IPv4 ограничено 4.3 триллионами, что на момент разработки казалось достаточным числом. Протокол IPv4 был разработан в 1981. Чтобы разрешить проблему ограничения, в 1995 году был разработан протокол IPv6, однако на лето 2022 года, 62% Интернета продолжает пользоваться протоколом IPv4. В DNS зоне, этот адрес указывается в "A" записи.
  • IPv6 адрес (IPv6 address). IP адрес, соответствующий протоколу IPv6. Эти адреса представляют собою несколько групп цифр и букв, разделённых двоеточиями. Некоторые группы могут быть пустыми. Например, 2a01:4f8:fff0:53::2 -- это один из адресов Фермы и группы между сдвоенными двоеточиями пусты. В DNS зоне, этот адрес указывается в "AААА" записи.
  • DNS (Domain Name System) -- иерархическая и децентрализованная система доменных имён, которая была изначально создана для привязки человечески-разпознаваемым доменных имён к машинно-обрабатываемым адресам протокола Интернет (IP адресам), а позже стала использоваться для определения других данных этих имён и адресов. Например, в текстовые записи может быть добавлен открытый ключ к подписи почты. DNS записи содержатся в так называемых DNS зонах, которые предоставляют поставщики услуг Интернета (Internet service provider или ISP).
  • DNS запись (DNS record) -- Привязка стандартизованных данных к конкретному доменному имени. Запись состоит из типа (type), например , "AAAA" в AAAА записи, названия (resource record), например, jitsi.bskol.com, и привязанных к названию данных (data). Вместе, записи составляют DNS зону.
  • DNS зона (DNS zone). Ta часть системы доменных имён (DNS), которая управляется отвечающим в системе за конкретное доменное имя поставщиком услуг Интернета (Internet service provider или ISP) и которая определяет данные, связанные с этим доменным именем. Эти данные представлены в виде DNS записей, таких, как A запись или AAAA запись.
  • Виртуальная машина (virtual machine или VM). Виртуальное компьютерное устройство, имитирующее компьютер, создаваемое виртуальной средой. Аналогично обычному компьютеру, на VM устанавливается операционная система, обычно, из коробки, и, на неё, -- пользовательские приложения.
  • Высокая доступность (high availability или HA). Свойство системы иметь более высокую продолжительность исправного состояния (uptime) по сравнению с идентичной системой, которая не использует инструментов и методик высокой доступности. Ни одна система и ни одна часть системы не могут быть полностью защищены от угрозы нештатной работы или аварийной ситуации. Высокую доступность можно описать как продолжение предоставления услуг системой на каком-то "исправном" уровне при сбое её определённой части с одновременным восстановлением той самой части, которая пострадала от сбоя. Инструменты высокой доступности включают дублирующие части, готовые взять на себя роль основных, устройства мониторинга для обнаружения случаев отказа, а также управляющие устройства, которые огораживают (fencing) неработающие части и перенаправляют запросы на работающие. Требование "исправного", пускай и аварийного, состояния отличает высокую доступность от концепции отказоустойчивости (failure tolerance), которая стремится к тому, чтобы обычный пользователь системы отказа её части и не заметил.
  • Доменное имя (domain name, hostname). Воспринимаемое людьми название веб-сайта или иного ресурса, особенно в сети Интернет, например, "bskol.com". Веб-просмотрщики и другие устройства работают с IP адресами, но эти адреса трудны для запоминания и воспроизведения людьми; для них, созданы доменные имена. В зонах DNS, доменные имена привязаны либо к IPv4 адресу, либо к IPv6 адресу, либо к обоим.
  • Контейнер. Виртуальное компьютерное устройство, имитирующее компьютер с установленной операционной системой и пользовательскими приложениями, создаваемое виртуальной средой. Как правило, контейнеры задействуют облегчённую операционную систему, заточенную исключительно под работу установленных приложений.
  • Операционная система (operating system или OS). Программное обеспечение, которое, с одной стороны, взаимодействует либо с железным, либо с виртуальным компьютерным устройством и, с другой стороны, может взаимодействовать с пользовательскими приложениями.
  • Отказоустойчивость (failure tolerance) -- это концепция такой работы системы, в которой конечный пользователь системы не может заметить отказа её части от штатной работы. Некоторые инструменты и методики отказоустойчивости аналогичны инструментам и методикам высокой доступности (high availability), которые способствуют предоставлению услуг системой при сбое её определённой части с одновременным восстановлением той самой части, которая пострадала от сбоя. Однако никакой набор не гарантирует, что любое восстановление будет моментальным и 100% полным. Потому "отказоустойчивость" -- это всё же концепция, к которой можно стремиться, но не конечная точка, которую можно достичь.
  • Поставщик услуг Интернета (Internet service provider или ISP). Организация, авторизованная администрацией сети Интернет на предоставление доменных имён и других услуг Интернета. С некоторыми исключениями, поставщики услуг Интернета предоставляют доступ к сети напрямую конечным пользователям или посредникам. Многие поставщики услуг Интернета являются также и поставщиками услуг размещения.

Специальные термины

На данной вики-странице, используются следующие термины, которые специфичны для этой страницы:

Архитектура

Для предоставления услуг пользователям:
  1. Пользовательские приложения Фермы установлены:
    • либо в контейнерах, которые уже содержат подогнанные исключительно под нужды приложения операционные системы.
    • либо на виртуальных машинах. Для взаимодействия виртуальной машины и приложения, операционные системы "из коробки" установлены в машинах перед установкой приложений.
  2. Контейнеры и виртуальные машины Фермы создаются в виртуальных средах.
  3. Виртуальные среды Фермы требуют для работы "физические", так называемые "железные", сервера (bare-metal server; здесь и далее по тексту -- Железа).
  4. Взаимодействие виртуальных сред с Железом осуществляется специально-ориентированной на это взаимодействие операционной системой. В сети, комбинация одного Железа и установленного на нём программного обеспечения называется "узловым центром" (node; здесь и далее, Узлом).
Для высокой доступности (high availability или HA) и отказоустойчивости услуг:
  • Задействуются три Узла, объединённые в единые сети Соединителями. Два из трёх Узлов являются "несущими"; их базы синхронизованы и изменение в одной базе влечёт автоматическое изменение в другой. Из двух несущих, одно является основным. Третий Узел -- это требование используемого для создания виртуальных сред программного обеспечения ProxmoxVE для обеспечения кворума.
  • В обычном режиме, веб-просмотрщик (web browser) пользователя обращается к IP адресу Hetzner vSwitch, который отправляет пользователя к основному Узлу.
  • Если основной Узел неспособен обслуживать клиентов, виртуальная среда изолирует его и переключает клиентов на второй несущий, работающий Узел.
Отказоустойчивость требует пару дополнительных функций:
  1. Для обнаружения сбоя или другой нештатной ситуации, Ферма постоянно мониторится. Сигнал о сбое поступает в виртуальную среду, которая ограждает (fencing) Узел со сбоем и запускает процесс восстановления данных с резервной копии.
  2. Для восстановления данных в случае их потери из-за сбоя или другой нештатной ситуации, каждый Узел постоянно проводит резервное копирование.

Доступы

Администраторские

  1. Администраторский доступ к Железу, а также к соединителям Hetzner vSwitch осуществляется через административную панель и администраторские консоли. Они предоставлены непосредственно Hetzner заказчику; заказчик лично может предоставить доступы ответственным администраторам.
  2. Администраторский доступ к виртуальным средам ProxmoxVE и, далее, файлам пользовательских приложений, осуществляется через привязанные к Железу IP адреса. Данные доступов засекречены и хранятся в Брацкой Крынке.
  3. Администраторские доступы к пользовательским приложениям осуществляются через привязанные к приложениям IP адреса. В данный момент, доступы предоставляются бюрократами Оплёта вручную.

Пользовательские

  1. Те пользователи, которые администраторами не являются, не должны иметь доступ к Железу и Средам.
  2. Доступы тех пользователей, которые администраторами не являются, к пользовательским приложениям осуществляются через привязанные к приложениям IP адреса. Доступы предоставляются Оплётом автоматически и, бюрократами Оплёта, вручную.

Инфраструктура

Инфраструктура Фермы -- это объединённые в единую связку три Железа.

Поставщик Железа

Hetzner является поставщиком услуг размещения, у которого "Железо" арендуется. Сотрудничество с данным поставщиком длится с 2016 года. Другие поставщики периодически рассматриваются, но никто другой не предлагал более низких цен на долгосрочной основе.

Выбор Железа

Из-за меньшей стоимости, Железo выбрано на аукционе -- https://www.hetzner.com/sb?hdd_from=500&hdd_to=1000 исходя из следующих предпосылок:
  • Целевой рабочий объём жёсткого диска для этой Фермы -- 512Gb.
  • Как минимум один, основной сервер выбран с SSD и, желательно, NVMe, и частотой процессора в 64Gb.
  • Как минимум два "несущих" сервера выбраны в одном датацентре. Хотя Hetzner не берёт оплату за траффик, это обстоятельство повышает скорость работы Фермы. Если второй сервер не был бы доступен в том же датацентре, мы искали бы его в других датацентрах то же города или месторасположения.
  • Подрядчик предпочёл сервер на процессоре Intel Xeon E3-1275v5 серверу на Intel Core i7-7700.
  • Требования к третьему Железу ниже, чем к "несущим". Один кандидат утверждал, что его объём может быть меньше, так как на нём может быть установлен только ProxmoxVE.
Характеристики Железа представлены ниже.

Соединители

Для объединения Узлов в сети, используются инструменты Hetzner vSwitch. Их хозяином является поставщик услуг размещения; команда может заказать присоединeние к одному Железу до 5 соединителей. Право на присоединение соединителей предоставляется вместе с арендой Железа.
На соединителях построены внутренняя и внешняя сети. Каждый из соединителей имеет свой IP адрес, внутренний или внешний:
  • Внутренние соединители обеспечивают передачу данных между Узлами. Прежде всего, такая передача жизненно необходима синхронизации хранилищ отдельных Узлов.
  • Соединители с внешними, доступными из сети Интернет, IP адресами, распределяют запросы из сети Интернет между Узлами и возвращают ответы Узлов на запросы назад в сеть Интернет.
Инструменты Фермы не поддерживают и не могут поддерживать высокой доступности соединителей. За отказоустойчивость соединителей отвечает их хозяин, поставщик услуг размещения Hetzner.

Характеристики Железа

В результате процесса Выбора Железа, были выбраны сервера со следующими характеристиками:

Железо 1

1 x Dedicated Root Server "Server Auction"
  • Intel Xeon E3-1275v5
  • 2x SSD M.2 NVMe 512 GB
  • 4x RAM 16384 MB DDR4 ECC
  • NIC 1 Gbit Intel I219-LM
  • Location: FSN1-DC1
  • Rescue system (English)
  • 1 x Primary IPv4

Железо 2

1 x Dedicated Root Server "Server Auction"
  • Intel Xeon E3-1275v5
  • 2x SSD M.2 NVMe 512 GB
  • 4x RAM 16384 MB DDR4 ECC
  • NIC 1 Gbit Intel I219-LM
  • Location: FSN1-DC1
  • Rescue system (English)
  • 1 x Primary IPv4

Железо 3

1 x Dedicated Root Server "Server Auction"
  • Intel Core i7-7700
  • 2x SSD SATA 512 GB
  • 2x RAM 16384 MB DDR4
  • NIC 1 Gbit Intel I219-LM
  • Location: FSN1-DC1
  • Rescue system (English)
  • 1 x Primary IPv4

Железо 4

1 x Dedicated Root Server "Server Auction"
  • Intel Xeon E5-1650V3
  • 2x HDD SATA 2,0 TB Enterprise
  • 8x RAM 16384 MB DDR4 ECC reg.
  • NIC 1 Gbit Intel I210
  • Location: FSN1
  • Rescue system (English)
  • 1 x Primary IPv4

Узлы Фермы

Работа Фермы обеспечивается тремя Узлами. Каждый Узел представляет собой отдельное Железо, приводимoe в действие несколькими видами программного обеспечения (ПО).

Резервное копирование

OpenZFS или RAID создаёт резервные копии и может быть задействовано для восстановления данных Железа в случае аварий. Жёсткие диски каждого Железа сдвоены, как, например, 2x SSD SATA 512 GB. RAID или OpenZFS копирует данные основного диска Железа на резервный диск. Если основной диск теряет данные из-за сбоя, резервный диск будет использован для восстановления данных на основной диск. RAID или OpenZFS устанавливается непосредственно на Железо.

Виртуальные среды

ProxmoxVE, в данный момент, v.7.2, создаёт виртуальные среды (здесь и далее -- Среды). Это программное обеспечение взаимодействует с Железом через операционную систему Debian, под которую оно настроено. Эта операционная система приходит в одной коробке с ProxmoxVE.

Сети Узлов

Сеть каждого Узла использует мост по выбираемой по умолчанию в Network Configuration модели.

Хранилища Узлов

Для хранения данных, каждый Узел использует платформу распределённого хранилища Ceph. Хранилища отдельныx Узлов синхранизуются через внутреннюю сеть инфраструктуры.
Таким образом, всё хранилище Фермы включает специально-зарезервированные дисковые пространства Желез и программное обеспечение, работа которого распределена по всем Узлам. Благодаря этому обеспечению, хранилища отдельных Узлов синхранизованы между собою, чтобы исключить единую точку отказа.

IP адреса

В сетях ProxmoxVE, мы задействуем три типа IP адресов:
  1. Для управления средами ProxmoxVE, мы используем IPv4 адреса и IPv6 адреса отдельных Желез.
  2. Для внутренней сети из трёх Желез, собранной на одном Hetzner vSwitch, задействуется частный IP адрес. Эта сеть не доступна из сети Интернет; прежде всего, через неё синхранизуются хранилища Желез. Для этой сети, выбран адрес с типом "/24" .
  3. Внешняя сеть требует покупки дополнительных IP адресов, причём IPv4 адреса дороги, а IPv6 адреса, возможно, могут не обеспечивать стабильной работы. В данный момент, мы купили один IPv6 адрес и тестируем его. Этот IPv6 адрес будет присваиваться всем VM и контейнерам, которые будут создаваться в инфраструктуре. Чтобы работать с ресурсами Фермы, пользователи будут запрашивать именно этот адрес. Эта сеть также собрана на тех же Железах другим Hetzner vSwitch.

Веб-сервер

В качестве веб-сервера одни приложения будут использовать apache, а другие nginx.

DNS зона

Для связи с сетью Интернет, следующие записи созданы в зоне DNS:
Resource record Type Data Комментарий (не являющийся частью записи)
pm1.bskol.com AAAA 2a01:4f8:10a:439b::2 Среда 1
pm2.bskol.com AAAA 2a01:4f8:10a:1791::2 Среда 2
pm3.bskol.com AAAA 2a01:4f8:10b:cdb::2 Среда 3
pbs.bskol.com AAAA 2a01:4f8:fff0:53::6 Сервер резервных копий Сред
pf.bskol.com AAAA 2a01:4f8:fff0:53::6 pfsense
pf.bskol.com A 88.99.71.85
npm1.bskol.com A 88.99.218.172 NGINX Среды 1
npm2.bskol.com A 88.99.71.85 NGINX Среды 2
npm3.bskol.com A 94.130.8.161 NGINX Среды 3
jitsi.bskol.com AAAA 2a01:4f8:fff0:53::2 Жици (Jitsi)
jitsi1.bskol.com A 88.99.218.172 Доступ по IPv4 к Жици (Jitsi)
sprava.bskol.com AAAA 2a01:4f8:fff0:53::3 Справа (Odoo)
sprava2.bskol.com A 88.99.71.85 Доступ по IPv4 к Справе (Odoo)
setka.bskol.com AAAA 2a01:4f8:fff0:53::4 Сетка (HumHub)
setka2.bskol.com A 88.99.71.85 Доступ по IPv4 к Сетке (HumHub)
svazka.bskol.com AAAA 2a01:4f8:fff0:53::5 Связка (SuiteCRM)
svazka2.bskol.com A 88.99.71.85 Доступ по IPv4 к Связке (SuiteCRM)

Пользовательские прилады

Ферма обеспечивает высокую доступность Брацкой Сетки, Брацкой Справы и, возможно, других приложений, которые принадлежат Делово Бюро.

Сетка

  • Брацка Сетка -- это брацкая прилада, которая представляет собою систему поддержки социальной сети, построено на базе готового программного решения HumHub.

Справа

  • Брацка Справа -- это средство управления людскими и материальными ресурсами предприятия, построенное на основе программного обеспечения Odoo.

Жици

  • Брацки Жици -- это инструмент Брацкой Школы для организации видео- и аудио-конференций, построена на основе программного обеспечения Jitsi.

Связка

  • Брацка Связка -- это брацкая прилада, которая представляет собою систему управления взаимоотношениями с клиентами, построена на основе программного обеспечения SuiteCRM.

Мониторинг

Сейчас не используется специальные функции.
Предложения кандидатов:
  1. Стек -- prometheus + node-exporter + grafana
  2. Prometheus to monitor VMs, Influx to monitor Pve nodes , Grafana for Dashbord
  3. (M) grafana + influxdb + telegraf, а также zabbix. Для мониторинга веб-сайта использовать uptimerobot

История разработки

Предыстория

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

Собственные попытки

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

Советы по созданию

В результате собственных попыток, стало понятно, что компетенций команды для создания кластера не хватает. Для получения сторонней экспертизы, следующее объявление было размещено на Upwork:

Hetzner/RAID/Proxmox consultant is needed Tech Support

Hey, guys, I need a consultant for this project - https://pravka.bskol.com/en/CNMC_bare-metal. I plan to buy a bare-metal server at hetzner.de, setup RAID and Proxmox, as well as start setting up the rest of technology

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

Создание кластера

Летом 2022-го, проект создания кластера был оформлен и Каролина была назначена координатором. Она привлекала подрядчиков на изготовление Фермы по разработанным на этой вики-странице требованиям.
Объявление на разовую работу было опубликовано на Upwork:

HA Proxmox Hetzner cluster is needed Systems Administration

Guys, we need the most affordable well-documented HA (high availability) ProxmoxVE 7.2 cluster that is assembled on three Hetzner nodes:

  • 2 Intel Xeon E3-1275v5/2x SSD M.2 NVMe 512 GB/4x RAM 16384 MB DDR4 ECC/NIC 1 Gbit Intel I219-LM and
  • One Intel Core i7-7700/2x SSD SATA 512 GB/2x RAM 16384 MB DDR4/NIC 1 Gbit Intel I219-LM.

Ceph, iptables. We plan that each node would have one VM or container for testing. We will assign a domain name to that.

Each has a primary IPv4. However, there are some unresolved issues related to the network. Initially, we planned to use vSwitch; however, it seems to require additional IP addresses, from which IPv4 are expensive and IPv6 may not be able to deliver HA. Thus, we plan to offer two different contract prices -- one is if we need to buy additional IPv4 addresses for vSwitch and another is if we don't.

We see two parts of acceptance testing. If both are successful, the contract shall be considered completed.

  1. During software testing, we will shut down 2 of 3 nodes to see whether the cluster is still available.
  2. During documentation testing, we will erase the software from one, implement the rescue, and one expert will try to restore the software using your documentation. She will video-record her attempts and, if not successful, will provide you with the recording, so either you can show her errors or correct yours.

What else do you need? If nothing, please give your minimum project budget (your project fare + initial costs of additional purchases such as setup fees for additional IP addresses, if any, required by the contract + first year costs of additional purchases, if any) and timeframe up to 2-3 weeks.

This project is a fixed-price one. When we send you an offer, we will change the terms. To complete the project, the selected contractor will be given an admin access, but not full robot credentials, for three weeks. After three weeks, that access would be revoked; if you don't complete the project by that time, you will never finish it!

Подрядчики отбирались по следующему принципу. Нам нужен кластер с нуля и мы отдадим подряд тому,
  1. Кто сможет это сделать,
  2. В чьём графике завершение контракта не растянется на более, чем два месяца, и
  3. Чей бюджет будет наименьший. Имеется в виду весь бюджет, включая и оплату подрядчиков, и расходы на покупку и ежегодного поддержания Фермы.
Контракт был присуждён 8-го июля со сроком действия до 12 августа 2022 года.
Подрядчик завершил роботу по контракту, результатом которой есть кластер ProxmoxVE 7.2 HA реализован на трех узлах Hetzner c помощью vSwitch. В процессе разработки и на этапе приемки было выявлено ряд проблем, решение которых было вынесено на следующий проект. Основная проблема с доступом до кластеру, на данный момент доступ реализован с помощью дополнительного IPv6. Однако это решение не дает достаточной доступности нашему кластеру, так как не все поставщики Интернет услуг работают с ним. Хорошим решением есть покупка IPv4 для этой цели, но это очень затратное. По этому было принято решения поискать другие варианты решения. Так же много вопросов осталось относительно улучшения безопасности, резервного копирования и мониторинг кластера.

Доступ IPv4

Кластер ProxmoxVE 7.2 HA реализован на трех узлах Hetzner c помощью vSwitch. Для внешнего доступа к кластеру используется IPv6, что ограничивает его доступность в Интернете. Можно использовать дополнительный IPv4. Нас интересуют другие способы решения на вход.
Объявление на разовую работу было опубликовано на Upwork:
Guys, we need IPv4 access to our HA (high availability) ProxmoxVE 7.2 cluster that is assembled on three Hetzner nodes through vSwitch.
We know that we can add a IPv4 net to vSwitch. Do we have other options?
As the same or separate projects, we would also like to consider some improvements to its security (right now, we use iptables only), backup (right now, we deploy Proxmox backup only, no ZFS, no RAID1 nor anything else), and monitoring (no any special features is deployed).

Варианты на вход

  1. На вход поставить HAProxy на отдельном VPS.

Безопасность

На данный момент используются только iptables. Вопросы относительно улучшения безопасности вынесены на отдельный проект.
Предложение от кандидатов:
  1. ipset + fail2ban + iptables
  2. Pfsense FW
  3. (M) firewall + fail2ban.

Резервное копирования

На данный момент используется резервное копирования Proxmox (Proxmox Backup Server). Рассматриваются другие возможности резервного копирования.

Ввод в работу

Передача и приёмка

Объёмы работ

Мы предоставляем подрядчику Инфраструктуру и изложенные на этой вики-странице требования. Подрядчик должен представить нам объект приёмки -- отлично задокументированные Виртуальные среды с установленными высокоустойчивыми Пользовательскими приладами.

Приёмочные тесты

Для того, чтобы убедиться в том, что то, что представлено подрядчиком -- это то, что нам надо (aka отвечает критериям приемлемости), порядок приёмочного тестирования установлен следующим:
  1. Созданную Ферму тестируем, насильно отключивши два случайно выбранные Железа из трёх доступных. Если Ферма продолжает работать, то сборка принимается.
  2. Программное обеспечение случайно выбранного Узла (одного из трёх) удаляется и наш специалист, Natly, восстанавливает его по созданной документации, одновременно записывая восстановление на видео. Восстановленная Ферма тестируется аналогично созданной. Если Ферма продолжает работать, то документация принимается. Если нет, то видео передаётся подрядчику для доработки документации или указания ошибок Natly.

Вопросы для прояснения

Архитектура платформы

Есть две окончательно неразрешённые проблемы касаемые ПО платформы:
  • Один подрядчик предлагает вместо Ceph задействовать TrueNAS.
  • До начала проекта, один специалист предлагал использовать роутер Microtik, чтобы на proxy сделать два IP адреса, первый использовать для внутренних виртуалок, если они нормально работают, а второй загнать в bridge для внешних серверов и средствами Линукса типа firewall делить тот трафик, который приходит. Кроме того, на том же proxy он предлагал поставить DHCP сервер для раздачи адресов машинам. Другой специалист считал, что безопасных DHCP серверов на рынке нет. В результате, роутеры и DHCP сервер не устанавливались.

Начало работы

Полезные рекоммендации

Связанные лектио

Источник — «https://pravka.bskol.com/w1/index.php?title=Делова_Ферма&oldid=26369»