Кампусна Ферма — различия между версиями

Материал из Брацка Правки
Перейти к: навигация, поиск
(→‎Предложения услуг)
(→‎Связанные лектио)
 
(не показаны 224 промежуточные версии 4 участников)
Строка 1: Строка 1:
−
[[Кампусны Кластер]] -- это отказоустойчивый ([[high availability]]) кластер (здесь и далее по тексту -- ''Кластер'') на основе трёх "физических" ([[bare metal]]) узлов (здесь и далее по тексту -- ''Желез'') [[Брацки Фермы|Брацких Ферм]] (здесь и далее по тексту -- ''Ферм''), который обеспечивает высокую доступность услуг, предположительно, [[Брацка Правка|Брацкой Правки]] и [[Брацка Учебка|Брацкой Учебки]]. Оба приложения принадлежат [[Брацки Кампус|Брацку Кампусу]], однако их номенклатура и, соответственно, название ''Кластера'' могут измениться в результате его разработки.
+
[[Кампусна Ферма]] (здесь и далее -- ''Ферма'') -- это отказоустойчивый ([[high availability]]) кластер [[Брацки Фермы|Брацких Ферм]] (здесь и далее по тексту -- ''Ферм''), который обеспечивает обеспечивает работу и высокую доступность услуг приложений [[Брацки Кампус|Брацка Кампуса]], так называемых [[#Пользовательские прилады|кампусных прилад]].
  
  
−
==Платформа==
+
==Общее описание==
  
−
===Размещение===
+
===Общепринятые понятия===
−
:[[Hetzner]] является поставщиком услуг размещения, у которого "Железо" арендуется.
+
:На данной вики-странице, используются следующие термины для общепринятых понятий:
 +
:*'''[[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 адрес]], к которому это доменное имя привязано.
 +
:*'''[[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 запись]].
 +
:*'''[[VPS]]''' ([[virtual private server]] или [[виртуальный частный сервер]]). Виртуальное компьютерное устройство, имитирующее компьютерный сервер, создаваемое виртуальной средой. Аналогично обычному компьютерному серверу, на VPS устанавливается операционная система, обычно, из коробки, и, на неё, -- пользовательские приложения. По сути, VPS является [[виртуальная машина|виртуальной машиной]], созданной для работы в качестве сервера, то есть, с повышенными, чем у обычной машины, характеристиками.
 +
:*'''[[Высокая доступность]]''' ([[high availability]] или [[HA]]). Свойство системы иметь более высокую продолжительность исправного состояния ([[uptime]]) по сравнению с идентичной системой, которая не использует инструментов и методик высокой доступности. Ни одна система и ни одна часть системы не могут быть полностью защищены от угрозы нештатной работы или аварийной ситуации. Высокую доступность можно описать как продолжение предоставления услуг системой на каком-то "исправном" уровне при сбое её определённой части с одновременным восстановлением той самой части, которая пострадала от сбоя. Требование "исправного", пускай и аварийного, состояния отличает высокую доступность от концепции [[отказоустойчивость|отказоустойчивости]] ([[failure tolerance]]), которая стремится к тому, чтобы обычный пользователь системы отказа её части и не заметил.
 +
:*'''[[Доменное имя]]''' ([[domain name]], [[hostname]]). Воспринимаемое людьми название веб-сайта или иного ресурса, особенно в сети Интернет, например, "bskol.com". Веб-просмотрщики и другие устройства работают с [[IP адрес]]ами, но эти адреса трудны для запоминания и воспроизведения людьми; для них, созданы доменные имена. В зонах [[DNS]], доменные имена привязаны либо к [[IPv4 адрес]]у, либо к [[IPv6 адрес]]у, либо к обоим.
 +
:*'''[[Контейнер]]'''. Виртуальное компьютерное устройство, имитирующее компьютер с установленной операционной системой и пользовательскими приложениями, создаваемое виртуальной средой. Как правило, контейнеры задействуют облегчённую операционную систему, заточенную исключительно под работу установленных приложений.
 +
:*'''[[Операционная система]]''' ([[operating system]] или [[OS]]). Программное обеспечение, которое,  с одной стороны, взаимодействует либо с железным, либо с виртуальным компьютерным устройством и, с другой стороны, может взаимодействовать с пользовательскими приложениями.
 +
:*'''[[Отказоустойчивость]]''' ([[failure tolerance]]) -- это концепция такой работы системы, в которой конечный пользователь системы не может заметить отказа её части от штатной работы. Некоторые инструменты и методики отказоустойчивости аналогичны инструментам и методикам высокой доступности ([[high availability]]), которые способствуют предоставлению услуг системой при сбое её определённой части с одновременным восстановлением той самой части, которая пострадала от сбоя. Однако никакой набор не гарантирует, что любое восстановление будет моментальным и 100% полным. Потому "отказоустойчивость" -- это всё же концепция, к которой можно стремиться, но не конечная точка, которую можно достичь.
 +
:*'''[[Пользовательское приложение]]'''. Одна из установленных на ''Ферме'' [[деловы прилады|деловых прилад]].
 +
:*'''[[Поставщик услуг Интернета]]''' ([[Internet service provider]] или [[ISP]]). Организация, авторизованная администрацией сети Интернет на предоставление [[доменное имя|доменных имён]] и других услуг Интернета. С некоторыми исключениями, поставщики услуг Интернета предоставляют доступ к сети напрямую конечным пользователям или посредникам. Многие поставщики услуг Интернета являются также и [[поставшик услуг размещения|поставщиками услуг размещения]].
 +
:*'''[[Поставщик услуг размещения]]'''. Поставщик услуг Интернета ([[Internet service provider]] или [[ISP]]), предоставляющий свои подключённые к сети Интернет "VPS" сервера в аренду для размещения ''Фермы''.
  
−
===ПО платформы===
+
===Специальные термины===
−
:Платформа ''Кластера'' собрана на основе [[ProxmoxVE]], в данный момент, v.7.2. Сеть каждого ''Железа'' использует мост по модели выбираемой по умолчанию в [https://pve.proxmox.com/wiki/Network_Configuration#_default_configuration_using_a_bridge Network Configuration]
+
:На данной вики-странице, используются следующие термины, которые специфичны для этой страницы:
 +
:*'''[[Соединитель]]'''. Коммутационное устройство предоставляемое поставщиком услуг размещения ''Фермы'' и описанное в [[#Соединители|Соединителях]].
 +
:*'''[[Узел]]''' ([[node]]). Комбинация одного ''VPS'' и установленного на нём программного обеспечения, представленная в сети и описанная в [[#Узлы Фермы|Узлах Фермы]].
 +
:*'''Ферма'''. ''Кампусна Ферма'', для описания которой предназначена данная вики-страница.
 +
:*'''[[Хранилище]]'''. Система для хранения объектов, блоков и файлов, которые ''Ферма'' либо обрабатывает, либо предоставляет пользователям без обработки. Термины "хранилище Узла" или, во множественном числе, "хранилища", подразумевают системы хранения на отдельном ''Узле''. Система описана в [[#Хранилища Узлов|Хранилищах Узлов]].
  
−
:Для хранения данных используется платформа распределённого хранилища Ceph. Один подрядчик предлагает вместо Ceph задействовать TrueNAS.
+
===Архитектура===
 +
:'''Для предоставления услуг''' пользователям:
 +
:#Пользовательские приложения ''Фермы'' установлены:
 +
:#*либо в контейнерах, которые уже содержат подогнанные исключительно под нужды приложения операционные системы.
 +
:#*либо на виртуальных машинах. Для взаимодействия виртуальной машины и приложения, установлена операционная система.
 +
:#Контейнеры и виртуальные машины ''Фермы'' создаются в виртуальных средах.
  
−
:До начала проекта, один специалист предлагал использовать роутер [[Microtik]], чтобы на proxy сделать два IP адреса, первый использовать для внутренних виртуалок, если они нормально работают, а второй загнать в bridge для внешних серверов и средствами Линукса типа firewall делить тот трафик, который приходит. Кроме того, на том же proxy он предлагал поставить [[DHCP]] сервер для раздачи адресов машинам. Другой специалист считал, что безопасных [[DHCP]] серверов на рынке нет.
+
:'''Для высокой доступности''' ([[high availability]] или [[HA]]) и отказоустойчивости услуг:
 +
:*Задействуются три ''Узла'', объединённые в единые сети [[#Соединители|Соединителями]].  
  
−
:В результате, роутеры и [[DHCP]] сервер не устанавливались. Для раздачи адресов виртуальным машинам, используется программа [[iptables]].
+
:'''Отказоустойчивость требует''' пару дополнительных функций:
 +
:#Для обнаружения сбоя или другой нештатной ситуации, ''Ферма'' постоянно [[#Мониторинг|мониторится]].  
 +
:#Для восстановления данных в случае их потери из-за сбоя или другой нештатной ситуации, каждый Узел постоянно проводит [[#Резервное копирование|резервное копирование]].
  
−
===vSwitch===
+
===Доступы===
−
:Три ''Железа'' необходимы для обеспечения высокой доступности. Если одно ''Железо'' неспособно обслуживать клиентов, ''Кластер'' изолирует его и переключает клиентов на работающее ''Железо''. Для переключения на то ''Железо'', которое работает с клиентами, используется инструмент [[Hetzner vSwitch]].
+
:#Администраторский доступ к ''VPS'' осуществляется через административную панель и администраторские консоли. Они предоставлены непосредственно [[Contabo]] заказчику; заказчик лично может предоставить доступы ответственным администраторам.
 +
:#Администраторский доступ к виртуальным средам и, далее, файлам пользовательских приложений, осуществляется через привязанные к ''VPS'' [[IP адрес]]а. Данные доступов засекречены и хранятся в [[Брацка Крынка|Брацкой Крынке]].
 +
:#Доступы к пользовательским приложениям осуществляются через привязанные к приложениям [[IP адрес]]а. Доступы предоставляются [[Оплёт]]ом автоматически и, бюрократами [[Оплёт]]а, вручную.
 +
===Мониторинг===
 +
:Мониторинг систем включает мониторинг работы как вычислительных серверов, так и приложений.
 +
:#Для мониторинга систем, установлен [[Nagios Core]]. Используя агентов слежения, он отслеживает работу всех серверов системы, включая:<ul><li>Доступность сетевых услуг ([[SMTP]], [[POP3]], [[HTTP]], [[NNTP]], [[ICMP]], [[SNMP]], [[FTP]], [[SSH]]).</li><li>Использование ресурсов (processor load, disk usage, system logs, количество активных пользователей).</li><li>Доступность баз данных (в настоящее время -- [[MariaDB Server]], в перспективе -- отслеживание и других услуг кластеров).</li><li>Состояние сертификатов SSL. Для отслеживания  сертификатов, несколько инструментов не подошли, показывали срок действия один на все домены. Выбор был остановлен на check_ssl_cert. Отслеживаемые домены были объединены в host groups и единую сервисную группу. Результат удовлетворительный. Нужно будет подобавлять все нужные домены.</li></ul>Мониторинг осуществляется как через админовский интерфейс, так и через почтовые уведомления. Также был установлен [[Zabbix]], но его не получилось подключить к базам данных и если осуществлять повторную попытку, то необходимо заново устанавливать [[Zabbix]]. Планируется далее продолжить просмотр других специализированных приложений.
 +
:#Для мониторинга отдельных приложений и баз данных, помимо систем сетевого мониторинга, планируется использовать их внутренние функции, а также другие существующие решения.
  
−
==Поиск подрядчиков==
+
==Инфраструктура==
−
Для ускорения проекта, мы ищем подрядчиков на новый кластер или пару их. Объявление на разовую работу опубликовано на upwork, Каролина назначена рекрутером, заявки приходят.
+
:Инфраструктура Фермы -- это объединённые в единую связку три ''VPS''.
  
−
===Принцип отбора===
+
===Поставщик VPS===
−
Нам треба кластер з нуля и мы возьмём тех, кто сможет это сделать и чей бюджет будет наименьший. Имеется в виду весь бюджет, включая и оплату подрядчиков, и расходы на покупку и ежегодного поддержания ''Кластера''.
+
:Contabo является поставщиком услуг размещения, у которого ''VPS'' арендуется. Сотрудничество с данным поставщиком длится с 2017 года.
  
−
===Собеседования===
+
===Оптимизация VPS===
−
Если они ничего не добавляют на Правку, не обязательно. Мой собственный поиск постоянно добавлял нечто на Правку. Из моего опыта, найм людей -- отличный способ узнать о теме.
+
:Три арендованы у Contabo; два сервера и отдельное дисковое пространство для резервных копий располагаются в Сент-Луисе, Миссури, США, один -- в Германии. Планов уезжать с Contabo нет, но есть план заменить один сервер в Сент-Луисе, Миссури на сервер в Сингапуре;
  
−
===Полученные заявки===
+
===Соединители===
−
Мы не публикуем имена подрядчиков, так как они нам на публикацию разрешений не давали. С юридической точки зрения, мы не можем публиковать конфиденциальную информацию наших подрядчиков. Во время поиска подрядчика были предложены такие варианты:
+
:Заказчик видит сеть некой комбинацией [[SDN]], [[VPN]] и [[HAProxy]]
−
;MA1.
+
:Один из консультантов предлагает использовать в качестве соединителя [[HAProxy]] используя IP адреса узлов и один IP адрес под [[HAProxy]]. Используя имеющие IP адреса узлов для [[HAProxy]]. При этом нужно использовать [[keepalived]] для аварийного переключения IP адреса [[HAProxy]].
−
:There are 2 types of HA proxmox. First, unideal HA proxmox that has 2 proxmox servers. Second, ideal HA proxmox that use at least 3 proxmox servers. On Hetzner, we can use Vswitch to connecting all server nodes for HA.
+
:Какая должна быть внутренняя сеть? Какая должна быть внешняя сеть? Что с безопасностью таких сетей? С помощью чего должны быть синхронизированы узлы? (Учитывая тот что один VPS из США будет принесён в Сингапур)
−
;AF
 
−
:I will use Ceph storage to have full HA with nodes and latest Proxmox 7.x installed on Baremetal servers
 
−
;AA
 
−
:I can configure you a HA setup with at least 2 physical hosts and a shared storage. Storage is also provided by the hetzner. I will need hetzner cloud robot credentials to perform the tasks.
 
−
;MA2
 
−
:There are 2 types of HA proxmox. First, unideal HA proxmox that has 2 proxmox servers. Second, ideal HA proxmox that use at least 3 proxmox servers. On Hetzner, we can use Vswitch to connecting all server nodes for HA.
 
−
;GK
 
−
:Why you are using proxmox at Hetzner? Isn't better to use docker (you save a lot on ram usage). Anyway, do you want proxmox cluster HA, or you want a proxmox active backup server (backup server will cost you less and it is more reliable because I don't think that you have a NAS solution). Anyway, based on what I have understand you are looking for a very cheap solution to have a full backup of your VMs so I recommend to go with a backup server not HA. Yes, I know, docker in docker. But you are using proxmox aka VM not docker in docker. And if you want to use a docker you need to run it in a VM. And no backup server, so the only option is HA (High availability). But in this case you need a NAS solution to have a reliable environment. In my experience HA with 2 proxmox can produce a split brain, and I use HA with 2 proxmox without NAS in a lab environment not in a production environment. kindly find the proposal, I recommend to go with scenario/proposal 2. you can find it in the attached document - https://setka.bskol.com/index.php?r=file%2Ffile%2Fdownload&guid=6f4ca628-2011-4c1d-99c2-d77452051d68&download=1
 
  
−
==Порядок разработки==
+
===Безопасность===
  
−
===Распределение обязанностей===
+
==Характеристики VPS==
−
Заказчик платит за ''Кластер'' и согласовывает эту вики-страницу перед присуждением подряда. Заказчик подразумевает, что координатор отработает проект, в том числе, документируя требования на этой вики-странице и ставя задачи подрядчику. По доброте душевной и в целях профессиональной подготовки, заказчик может делать работу координатора временно до той поры, пока заказчик верит в то, что координатор когда-то сможет работать самостоятельно :)
 
  
−
===Как не надо===
+
===VPS 1===
−
Мало бути так: ... Знаходимо людину, яка нас задовільняє на даний проект (або декілька людей) - зв'язуємось (бажано дзвінком) для уточнення деталей і надання необхідних даних (в цей же етап можна задавати Ваші питання про сервера, які, куди, як..) і на цьому етапі обов'язково присутня Natly, бо я не айтішник, щоб розуміти всі ці тонкощі і надавати комусь якісь доступи - заслуховуємо його оцінку по бюджету цього проекту - розуміємо підходить нам чи ні - остаточно даємо роботу або відмовляємо.
+
:VPS M SSD (6 vCPU Cores; 16 GB RAM; 100 GB NVMe or 400 GB SSD; 2 Snapshots; 32 TB Traffic Unlimited Incoming)
 +
:*IPv4, IPv6
 +
:*Location: Nuremberg
 +
:*OS: Ubuntu 18.04 (64 Bit)
  
−
Продолжение известно на 99%. В одном случае из 100, мы получим то, что нам надо. В 99 остальных случаях, мы получим то, что нам не надо или за те деньги, на которые мы не рассчитываем. Если мы не определим, что мы должны получить и как мы о том узнаем, мы то и не получим.
+
===VPS 2===
 +
:VPS M SSD (6 vCPU Cores; 16 GB RAM; 100 GB NVMe or 400 GB SSD; 2 Snapshots; 32 TB Traffic Unlimited Incoming)
 +
:*IPv4, IPv6
 +
:*Location: St. Louis
 +
:*OS: Ubuntu 18.04 (64 Bit)
  
−
===Как надо===
+
:1000 GB FTP Storage
−
#Oпределить, что мы должны получить (так называемые "[[#Объёмы работ|Объёмы работ]]")
+
:*Location: USC1 St Louis [VPS M]
−
#Oпределить, как мы узнаем, получили ли мы то, что были должны (так называемая "[[#Приёмка|Приёмка]]")
 
−
#Далее всё по рубрике [[#Как не надо|Как не надо]]
 
  
−
==Вопросы для прояснения==
+
===VPS 3===
−
===Покупка железа===
+
:VPS M SSD (6 vCPU Cores; 16 GB RAM; 100 GB NVMe or 400 GB SSD; 2 Snapshots; 32 TB Traffic Unlimited Incoming)
−
Ми не купили сервер тільки тому, що не знайшли підрядчика. Зачем тратить денежки зазря?
+
:*IPv4, IPv6
 +
:*Location: St. Louis
 +
:*OS: Ubuntu 18.04 (64 Bit)
  
−
Однако представим, что мы присудим контракт сейчас. Подрядчик скажет, давайте доступ к рабочему месту, верно? По другому быть не может. А места-то нет, сервера надо покупать. Отсюда возникает вопрос -- как мы будем покупать сервера под этот проект? Объём, я думаю, выберем в 512Gb. Но какие сервера? Нам нужно выбрать три из тех сотен, которые сегодня на аукционе -- https://www.hetzner.com/sb?hdd_from=500&hdd_to=1000
+
:Panel: LAMP
 +
:*Location: USC1 St Louis [VPS M]
  
−
По какому принципу их отбирать? Они все должны быть одинаковыми? Ненад говорил, что нет. Один купить подороже и два -- подешевле? Они должны быть в одном датацентре или могут быть в разных?
+
==Пользовательские прилады==
 +
===Правка===
 +
*[[Брацка Правка]] -- система совместного создания документов, Правка построена на [[вики-движке]] под названием "[[МедиаВики]]"
  
−
Як ми купували раніше? Раньше мы садились с Натальей, шарили экран и покупали -- это надо оговорить с новым подрядчиком.
+
===Учебка===
 +
*[[Брацка Учебка]] -- это ресурс для организации учебных курсов и сертификационных программ, который построен на основе программного обеспечения [[Moodle]].
  
−
===Начало работы===
+
===Бачка===
−
Что надо от нас, кроме присуждения контракта и [[#Покупка железа|Покупки железа]]?
+
*[[Брацка Бачка]] -- это средство загрузки, хранения и просмотра видео-материалов. Бачка построена на основе программного обеспечения [[AVideo]]
 +
 
 +
===Вебка===
 +
*[[Брацка Вебка]]--это сеть веб-сайтов Брацкой Школы, которые представляют Школу в сети Интернет. Веб-сайты построены на основе программного обеспечения [[WordPress]]
 +
 
 +
==Данные в Облаке==
 +
 
 +
===Базы данных===
 +
:В качестве основной базы данных для всех приложений Кампусной Фермы используется MariaDB. Базы данных синхронизированы на всех трех узлах с помощью MariaDB Galera Cluster. Есть интерес в использования в качестве распределителя нагрузок [[MariaDB MaxScale]].
 +
 
 +
==Узлы Фермы==
 +
Работа ''Фермы'' обеспечивается тремя ''Узлами''. Каждый ''Узел'' представляет собой отдельный ''VPS'', приводимoe в действие несколькими видами программного обеспечения (ПО).
 +
 
 +
===Резервное копирование===
 +
:На каждом VPS узле Contabo использует [[Snapshots]] для резервного копирования всего узла. Осуществляться поставщик услуг размещения по запросу администратора, в случае необходимости.
 +
:Резервное копирование баз данных совершается путем их архивации. Для этого используется утилита mysqldump с помощью которого получаем дамп(архив) содержимого одной или нескольких баз данных — по сути делать резервную копию (бекап) баз данных. Развернуть базу данных из полученного дампа (sql-файла) можно также с помощью данной утилиты. При копировании баз данных используется метод при котором копируются только новые данные.
 +
 
 +
===Виртуальные среды===
 +
:На VPS серверах установлена Ubuntu 18.04 (64 Bit) операционная система.
 +
 
 +
==Сети Узлов==
 +
 
 +
===IP адреса===
 +
:На каждом VPS сейчас по два IP адреса, один IPv4 адрес и IPv6 адрес.
 +
:Нужна ли покупка дополнительных IP адресов? Какие именно, и как они будут применяться?
 +
 
 +
===Географическая доступность===
 +
:''Ферма'' распределена по нескольким континентам с тем, чтобы пользователь работал с тем приложением, которое более доступно для этого пользователя. Для этого будут планироваться [[DNS Anycast]], [[DNS Geocast]] и аналогичные распределительные системы. Есть план отправлять пользователя на тот сервер, который наиболее доступен конкретному пользователю.
 +
 
 +
==Объявление==
 +
:Upwork
 +
:Guys, we need to add HA (high availability) capacity, most affordably and well-documented, of the services of three applications -- MediaWiki (pravka.bskol.com), Wordpress (vebka.bskol.com) and Moodle (ucebka.bskol.com). Right now, they are run on the 3 VPS cluster that also hosts AVideo (backa.bskol.com), but AVideo is moving to a separate project. The VPS are located in various regions. All of the applications use MariaDB at the moment.
 +
:The current number of nodes -- three -- is not a requirement. We may buy new nodes and get rid of the current ones. Our current architecture may be adjusted to the HA solutions as well.
 +
:We are not going to use floating IPs or other paid services of hosting providers and other third parties. We don't plan to use Cloudflare for this project.
 +
:This project can be either hourly consultations or a fixed-price one. If we agree on the fixed price, we will change the terms, when we send you an offer.
 +
:If we do fixed-price, 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.
 +
:When you propose any technology, please mention what we would get and what the budget be. What else do you need?
 +
 
 +
:В данный момент, мы используем три VPS арендованных у Contabo для размещения трёх приложений -- MediaWiki, Moodle и AVideo. Два VPS размещены в США, один -- в Германии. Базой данных выбрана [[MariaDB]] и три базы синхронизованны [[MariaDB Galera Cluster]]. Основная решаемая проблема -- это высокая доступность. Дополнительная проблема -- это Geocast. После решения дополнительной проблемы, мы планируем отказаться от одного VPS в США и добавить один VPS в Сингапуре. Мы также открыты к разработке отдельного кластера под AVideo.
 +
 
 +
==Процесс разработки==
 +
===Условия разработки===
 +
:Узлы данного кластера обеспечивают работу функционирующих приложений и баз данных. Есть необходимость реализации HA кластера, так чтобы обеспечить непрерывную работу этих приложений на момент работ над кластером. Если вариант разработки не предусматривая изменений которые, могут повлиять на целостность данных и подрядчик может гарантировать это то роботы можно проводить сразу на всех узла. Либо оставить один из узлов на обеспечения функционирования приложений, а на других двух реализовать кластер HA. После реализации кластера перенести приложения на него и добавить третий узел.
 +
:Возможно решение, при котором мы арендуем новые VPS (сколько нужно?) и откажемся от тех что имеем.
 +
 
 +
==Предложения относительно реализации==
 +
===Пример 1===
 +
:Для развертывания использовать [[Docker]]. Кластер построен на 3 VPS на каждом из которых:
 +
*Базы данных MariaDB синхронизированы з помощью [[MariaDB Galera Cluster]].
 +
*Для разделения чтения - запись между между узлами, соответственно и балансировки нагрузки использовать [[MariaDB MaxScale]].
 +
*Для сертификатов cloudflare и пользовательских портов использовать [[NGINX]].
 +
*Пользовательские Прилады.
 +
Для мониторинга использовать [[Sensu Go]] и [[PMM]].
 +
 
 +
===Пример 2===
 +
:Для развертывания использовать Docker. Кластер построен на 5 VPS из которых:
 +
*Два небольших VPS для MariaDB и один нано-узел для [[MariaDB Arbiter]].
 +
*Два VPS для [[MariaDB MaxScale|Maxscale]], [[Moodle]], [[MediaWiki]] и [[NGINX]].
 +
Для MariaDB HA — мы будем использовать плагин Galera и Maxscale для маршрутизации.
 +
Для синхронизации данных  в реальном времени мы будем использовать lsyncd по мере необходимости, для некоторых изображений или чего-то подобного.
 +
Они будут использовать CloudFlare для маршрутизации к прокси-серверу Nginx и бесплатным сертификатам.
 +
:Для мониторинга использовать [[Sensu Go]] и [[PMM]].
 +
 
 +
===Пример 3===
 +
Кластер построен на 5 VPS из которых:
 +
*Перед приложениями на отдельном на отдельном VPS установить HAProxy.
 +
*3 VPS для Moodle, MediaWiki, MariaDB, galera/mysql.
 +
*Для мониторинга использовать отдельный VPS c простыми запросы ping или http.
 +
*Веб-сервер на узлах [[Apache]] либо [[NGINX]]
 +
 
 +
===Пример 4===
 +
:3 VPS c MediaWiki, Moodle и MariaDB и HA настроен с использованием пакетов [[Corosync]] и [[Pacemaker]].
 +
 
 +
===Пример 5===
 +
:3 VPS для баз данных и один для приложений. Для данного кластер предлагают использовать [[InnoDB]] с [[ProxySQL]] в качестве промежуточного программного обеспечения.
 +
===Пример 6===
 +
:Кластер на 5 VPS: 3 VPS для приложений и баз данных, 2 VPS - HAPoxy с использованием протокола [[VRRP]] (keepalived). Таким образом, в случае выхода из строя одного HAProxy, его место займет второй. Для мониторинга использовать [[Nagios]].
 +
 
 +
===Пример 7===
 +
:Развернуть кластер на percona XTRADB (в основном это кластер MYSQL, разработанный percona), а так же внедрить "heartbeat" так как это был бы лучший подход, нет необходимости менять IP-адреса ваших клиентов, поскольку у нас будет выделенный IP-адрес. Однако, это имеет ограничения.
 +
 
 +
==Передача и приёмка==
  
 
===Объёмы работ===
 
===Объёмы работ===
−
Что подрядчик нам представит (aka что будет объектом приёмки)?
+
:Мы предоставляем подрядчику [[#Инфраструктура|Инфраструктуру]] и изложенные на этой вики-странице требования. Подрядчик должен представить нам объект приёмки -- отлично задокументированные [[#Виртуальные среды|Виртуальные среды]] с установленными высокоустойчивыми [[#Пользовательские прилады|Пользовательскими приладами]].
 +
 
 +
===Приёмочные тесты===
 +
:Для того, чтобы убедиться в том, что то, что представлено подрядчиком -- это то, что нам надо (aka отвечает критериям приемлемости), порядок приёмочного тестирования установлен следующим:
 +
:#Созданную ''Ферму'' тестируем, насильно отключивши два случайно выбранные ''VPS'' из трёх доступных. Если ''Ферма'' продолжает работать, то сборка принимается.
 +
:#Программное обеспечение случайно выбранного ''Узла'' (одного из трёх) удаляется и наш специалист, восстанавливает его по созданной документации, одновременно записывая восстановление на видео. Восстановленная ''Ферма'' тестируется аналогично созданной. Если ''Ферма'' продолжает работать, то документация принимается. Если нет, то видео передаётся подрядчику для доработки документации или указания ошибок.
 +
 
 +
 
 +
===Контракт===
 +
We need to add HA (high availability) capacity, most affordably and well-documented, of the services of three applications -- MediaWiki (pravka.bskol.com), Wordpress (vebka.bskol.com) and Moodle (ucebka.bskol.com). Right now, they are run on the 3 VPS cluster that also hosts AVideo (backa.bskol.com), but AVideo is moving to a separate project. The VPS are located in various regions. The database selected is MariaDB and the three databases are synchronized with MariaDB Galera Cluster.
 +
 
 +
Development Terms:
 +
We have bought one more VPS for HAProxy and related software. We will create and provide empty proxmox machines on which you need to install programs: MediaWiki (pravka.bskol.com), Wordpress (vebka.bskol.com) and Moodle (ucebka.bskol.com). MariaDB databases are synchronized using MariaDB Galera Cluster.
 +
MediaWiki should be version 1.31.1.
 +
 
 +
The directories should be synchronized.
 +
You must:
 +
1. check and configure the sql cluster on all sql node.
 +
2. test sql cluster to see if data are well replicated.
 +
3. check the haproxy node to see version and confirm the configuration, ACL and front/backend config.
 +
4. check the haproxy node to see if firewall is installed and online to be configured.
 +
5. check the route from the haproxy to all nodes. Can it join all node without too much TTL.
 +
6. configure the front end on the haproxy.
 +
7. add the first backend on the haproxy to point to the first node.
 +
8. test the configuration by calling apps URL using haproxy IP.
 +
9. add another backend and test by calling the apps URL via haproxy IP.
 +
10. test to remove one node to see if calling the apps URL still working.
 +
11. if not, debug. If yes, add another node to test.
 +
12. write the most complete documentation
 +
 
 +
We will transfer your setup/findings/design to our current VPS servers ourselves.
 +
 
 +
We see two parts of acceptance testing. If both are successful, the contract shall be considered completed.
 +
a. During software testing, we will shut down 2 of 3 nodes to see whether the cluster is still available.
 +
b. 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.
 +
 
 +
The deadline for this project is October 23rd, 2022. If we don't complete the project by that time, all the access details will be changed, the project would be considered unsuccessful, and we would return back to the positions before the project.
  
−
Сетка
+
==Принцип отбора==
 +
:Нам нужен ''VPS'' кластер и мы отдадим подряд тому,
 +
:#кто сможет это сделать,
 +
:#в чьём графике завершение контракта не растянется на более, чем на 3 недели, и
 +
:#чей бюджет будет наименьший. Имеется в виду весь бюджет, включая и оплату подрядчиков, и расходы на покупку и ежегодного поддержания ''Кластера''
  
−
===Приёмка===
+
==Вопросы к подрядчику==
−
Как мы убедимся в том, что то, что представлено -- это то, что нам надо (aka что будет критериями приемлемости и как мы будем проводить приёмочное тестирование)?
+
:#Сколько нам обойдётся кластер с всеми дополнительными расходами?
 +
:#Сколько вам нужно времени для реализации кластера с докладной документацией?
 +
:#Как вы видите реализацию данного задачи? (Методы и приложения для реализации)
 +
:#Каждый узел имеет по два IP адреса: IPv4 и IPv6. Нужно ли нам докупать дополнительные IP адреса?
 +
:#Чем будет обеспечен мониторинг кластера?
 +
:#Что относительно безопасности, какие защитные стены (firewall) предусмотрены?
  
−
==Полезные рекоммендации==
+
==Связанные лектио==
−
*https://www.informaticar.net/how-to-setup-proxmox-cluster-ha/
+
*[[Что Есть Фермы]]
−
*https://community.hetzner.com/tutorials/hyperconverged-proxmox-cloud
+
*[[Получение Навыков]]
−
*https://pve.proxmox.com/wiki/High_Availability
 
−
*https://docs.hetzner.com/robot/dedicated-server/network/vswitch/
 

Текущая версия на 16:08, 14 сентября 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 адрес, к которому это доменное имя привязано.
  • 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 запись.
  • VPS (virtual private server или виртуальный частный сервер). Виртуальное компьютерное устройство, имитирующее компьютерный сервер, создаваемое виртуальной средой. Аналогично обычному компьютерному серверу, на VPS устанавливается операционная система, обычно, из коробки, и, на неё, -- пользовательские приложения. По сути, VPS является виртуальной машиной, созданной для работы в качестве сервера, то есть, с повышенными, чем у обычной машины, характеристиками.
  • Высокая доступность (high availability или HA). Свойство системы иметь более высокую продолжительность исправного состояния (uptime) по сравнению с идентичной системой, которая не использует инструментов и методик высокой доступности. Ни одна система и ни одна часть системы не могут быть полностью защищены от угрозы нештатной работы или аварийной ситуации. Высокую доступность можно описать как продолжение предоставления услуг системой на каком-то "исправном" уровне при сбое её определённой части с одновременным восстановлением той самой части, которая пострадала от сбоя. Требование "исправного", пускай и аварийного, состояния отличает высокую доступность от концепции отказоустойчивости (failure tolerance), которая стремится к тому, чтобы обычный пользователь системы отказа её части и не заметил.
  • Доменное имя (domain name, hostname). Воспринимаемое людьми название веб-сайта или иного ресурса, особенно в сети Интернет, например, "bskol.com". Веб-просмотрщики и другие устройства работают с IP адресами, но эти адреса трудны для запоминания и воспроизведения людьми; для них, созданы доменные имена. В зонах DNS, доменные имена привязаны либо к IPv4 адресу, либо к IPv6 адресу, либо к обоим.
  • Контейнер. Виртуальное компьютерное устройство, имитирующее компьютер с установленной операционной системой и пользовательскими приложениями, создаваемое виртуальной средой. Как правило, контейнеры задействуют облегчённую операционную систему, заточенную исключительно под работу установленных приложений.
  • Операционная система (operating system или OS). Программное обеспечение, которое, с одной стороны, взаимодействует либо с железным, либо с виртуальным компьютерным устройством и, с другой стороны, может взаимодействовать с пользовательскими приложениями.
  • Отказоустойчивость (failure tolerance) -- это концепция такой работы системы, в которой конечный пользователь системы не может заметить отказа её части от штатной работы. Некоторые инструменты и методики отказоустойчивости аналогичны инструментам и методикам высокой доступности (high availability), которые способствуют предоставлению услуг системой при сбое её определённой части с одновременным восстановлением той самой части, которая пострадала от сбоя. Однако никакой набор не гарантирует, что любое восстановление будет моментальным и 100% полным. Потому "отказоустойчивость" -- это всё же концепция, к которой можно стремиться, но не конечная точка, которую можно достичь.
  • Пользовательское приложение. Одна из установленных на Ферме деловых прилад.
  • Поставщик услуг Интернета (Internet service provider или ISP). Организация, авторизованная администрацией сети Интернет на предоставление доменных имён и других услуг Интернета. С некоторыми исключениями, поставщики услуг Интернета предоставляют доступ к сети напрямую конечным пользователям или посредникам. Многие поставщики услуг Интернета являются также и поставщиками услуг размещения.
  • Поставщик услуг размещения. Поставщик услуг Интернета (Internet service provider или ISP), предоставляющий свои подключённые к сети Интернет "VPS" сервера в аренду для размещения Фермы.

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

На данной вики-странице, используются следующие термины, которые специфичны для этой страницы:
  • Соединитель. Коммутационное устройство предоставляемое поставщиком услуг размещения Фермы и описанное в Соединителях.
  • Узел (node). Комбинация одного VPS и установленного на нём программного обеспечения, представленная в сети и описанная в Узлах Фермы.
  • Ферма. Кампусна Ферма, для описания которой предназначена данная вики-страница.
  • Хранилище. Система для хранения объектов, блоков и файлов, которые Ферма либо обрабатывает, либо предоставляет пользователям без обработки. Термины "хранилище Узла" или, во множественном числе, "хранилища", подразумевают системы хранения на отдельном Узле. Система описана в Хранилищах Узлов.

Архитектура

Для предоставления услуг пользователям:
  1. Пользовательские приложения Фермы установлены:
    • либо в контейнерах, которые уже содержат подогнанные исключительно под нужды приложения операционные системы.
    • либо на виртуальных машинах. Для взаимодействия виртуальной машины и приложения, установлена операционная система.
  2. Контейнеры и виртуальные машины Фермы создаются в виртуальных средах.
Для высокой доступности (high availability или HA) и отказоустойчивости услуг:
Отказоустойчивость требует пару дополнительных функций:
  1. Для обнаружения сбоя или другой нештатной ситуации, Ферма постоянно мониторится.
  2. Для восстановления данных в случае их потери из-за сбоя или другой нештатной ситуации, каждый Узел постоянно проводит резервное копирование.

Доступы

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

Мониторинг

Мониторинг систем включает мониторинг работы как вычислительных серверов, так и приложений.
  1. Для мониторинга систем, установлен Nagios Core. Используя агентов слежения, он отслеживает работу всех серверов системы, включая:
    • Доступность сетевых услуг (SMTP, POP3, HTTP, NNTP, ICMP, SNMP, FTP, SSH).
    • Использование ресурсов (processor load, disk usage, system logs, количество активных пользователей).
    • Доступность баз данных (в настоящее время -- MariaDB Server, в перспективе -- отслеживание и других услуг кластеров).
    • Состояние сертификатов SSL. Для отслеживания сертификатов, несколько инструментов не подошли, показывали срок действия один на все домены. Выбор был остановлен на check_ssl_cert. Отслеживаемые домены были объединены в host groups и единую сервисную группу. Результат удовлетворительный. Нужно будет подобавлять все нужные домены.
    Мониторинг осуществляется как через админовский интерфейс, так и через почтовые уведомления. Также был установлен Zabbix, но его не получилось подключить к базам данных и если осуществлять повторную попытку, то необходимо заново устанавливать Zabbix. Планируется далее продолжить просмотр других специализированных приложений.
  2. Для мониторинга отдельных приложений и баз данных, помимо систем сетевого мониторинга, планируется использовать их внутренние функции, а также другие существующие решения.

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

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

Поставщик VPS

Contabo является поставщиком услуг размещения, у которого VPS арендуется. Сотрудничество с данным поставщиком длится с 2017 года.

Оптимизация VPS

Три арендованы у Contabo; два сервера и отдельное дисковое пространство для резервных копий располагаются в Сент-Луисе, Миссури, США, один -- в Германии. Планов уезжать с Contabo нет, но есть план заменить один сервер в Сент-Луисе, Миссури на сервер в Сингапуре;

Соединители

Заказчик видит сеть некой комбинацией SDN, VPN и HAProxy
Один из консультантов предлагает использовать в качестве соединителя HAProxy используя IP адреса узлов и один IP адрес под HAProxy. Используя имеющие IP адреса узлов для HAProxy. При этом нужно использовать keepalived для аварийного переключения IP адреса HAProxy.
Какая должна быть внутренняя сеть? Какая должна быть внешняя сеть? Что с безопасностью таких сетей? С помощью чего должны быть синхронизированы узлы? (Учитывая тот что один VPS из США будет принесён в Сингапур)

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

Характеристики VPS

VPS 1

VPS M SSD (6 vCPU Cores; 16 GB RAM; 100 GB NVMe or 400 GB SSD; 2 Snapshots; 32 TB Traffic Unlimited Incoming)
  • IPv4, IPv6
  • Location: Nuremberg
  • OS: Ubuntu 18.04 (64 Bit)

VPS 2

VPS M SSD (6 vCPU Cores; 16 GB RAM; 100 GB NVMe or 400 GB SSD; 2 Snapshots; 32 TB Traffic Unlimited Incoming)
  • IPv4, IPv6
  • Location: St. Louis
  • OS: Ubuntu 18.04 (64 Bit)
1000 GB FTP Storage
  • Location: USC1 St Louis [VPS M]

VPS 3

VPS M SSD (6 vCPU Cores; 16 GB RAM; 100 GB NVMe or 400 GB SSD; 2 Snapshots; 32 TB Traffic Unlimited Incoming)
  • IPv4, IPv6
  • Location: St. Louis
  • OS: Ubuntu 18.04 (64 Bit)
Panel: LAMP
  • Location: USC1 St Louis [VPS M]

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

Правка

Учебка

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

Бачка

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

Вебка

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

Данные в Облаке

Базы данных

В качестве основной базы данных для всех приложений Кампусной Фермы используется MariaDB. Базы данных синхронизированы на всех трех узлах с помощью MariaDB Galera Cluster. Есть интерес в использования в качестве распределителя нагрузок MariaDB MaxScale.

Узлы Фермы

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

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

На каждом VPS узле Contabo использует Snapshots для резервного копирования всего узла. Осуществляться поставщик услуг размещения по запросу администратора, в случае необходимости.
Резервное копирование баз данных совершается путем их архивации. Для этого используется утилита mysqldump с помощью которого получаем дамп(архив) содержимого одной или нескольких баз данных — по сути делать резервную копию (бекап) баз данных. Развернуть базу данных из полученного дампа (sql-файла) можно также с помощью данной утилиты. При копировании баз данных используется метод при котором копируются только новые данные.

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

На VPS серверах установлена Ubuntu 18.04 (64 Bit) операционная система.

Сети Узлов

IP адреса

На каждом VPS сейчас по два IP адреса, один IPv4 адрес и IPv6 адрес.
Нужна ли покупка дополнительных IP адресов? Какие именно, и как они будут применяться?

Географическая доступность

Ферма распределена по нескольким континентам с тем, чтобы пользователь работал с тем приложением, которое более доступно для этого пользователя. Для этого будут планироваться DNS Anycast, DNS Geocast и аналогичные распределительные системы. Есть план отправлять пользователя на тот сервер, который наиболее доступен конкретному пользователю.

Объявление

Upwork
Guys, we need to add HA (high availability) capacity, most affordably and well-documented, of the services of three applications -- MediaWiki (pravka.bskol.com), Wordpress (vebka.bskol.com) and Moodle (ucebka.bskol.com). Right now, they are run on the 3 VPS cluster that also hosts AVideo (backa.bskol.com), but AVideo is moving to a separate project. The VPS are located in various regions. All of the applications use MariaDB at the moment.
The current number of nodes -- three -- is not a requirement. We may buy new nodes and get rid of the current ones. Our current architecture may be adjusted to the HA solutions as well.
We are not going to use floating IPs or other paid services of hosting providers and other third parties. We don't plan to use Cloudflare for this project.
This project can be either hourly consultations or a fixed-price one. If we agree on the fixed price, we will change the terms, when we send you an offer.
If we do fixed-price, 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.
When you propose any technology, please mention what we would get and what the budget be. What else do you need?
В данный момент, мы используем три VPS арендованных у Contabo для размещения трёх приложений -- MediaWiki, Moodle и AVideo. Два VPS размещены в США, один -- в Германии. Базой данных выбрана MariaDB и три базы синхронизованны MariaDB Galera Cluster. Основная решаемая проблема -- это высокая доступность. Дополнительная проблема -- это Geocast. После решения дополнительной проблемы, мы планируем отказаться от одного VPS в США и добавить один VPS в Сингапуре. Мы также открыты к разработке отдельного кластера под AVideo.

Процесс разработки

Условия разработки

Узлы данного кластера обеспечивают работу функционирующих приложений и баз данных. Есть необходимость реализации HA кластера, так чтобы обеспечить непрерывную работу этих приложений на момент работ над кластером. Если вариант разработки не предусматривая изменений которые, могут повлиять на целостность данных и подрядчик может гарантировать это то роботы можно проводить сразу на всех узла. Либо оставить один из узлов на обеспечения функционирования приложений, а на других двух реализовать кластер HA. После реализации кластера перенести приложения на него и добавить третий узел.
Возможно решение, при котором мы арендуем новые VPS (сколько нужно?) и откажемся от тех что имеем.

Предложения относительно реализации

Пример 1

Для развертывания использовать Docker. Кластер построен на 3 VPS на каждом из которых:
  • Базы данных MariaDB синхронизированы з помощью MariaDB Galera Cluster.
  • Для разделения чтения - запись между между узлами, соответственно и балансировки нагрузки использовать MariaDB MaxScale.
  • Для сертификатов cloudflare и пользовательских портов использовать NGINX.
  • Пользовательские Прилады.

Для мониторинга использовать Sensu Go и PMM.

Пример 2

Для развертывания использовать Docker. Кластер построен на 5 VPS из которых:

Для MariaDB HA — мы будем использовать плагин Galera и Maxscale для маршрутизации. Для синхронизации данных в реальном времени мы будем использовать lsyncd по мере необходимости, для некоторых изображений или чего-то подобного. Они будут использовать CloudFlare для маршрутизации к прокси-серверу Nginx и бесплатным сертификатам.

Для мониторинга использовать Sensu Go и PMM.

Пример 3

Кластер построен на 5 VPS из которых:

  • Перед приложениями на отдельном на отдельном VPS установить HAProxy.
  • 3 VPS для Moodle, MediaWiki, MariaDB, galera/mysql.
  • Для мониторинга использовать отдельный VPS c простыми запросы ping или http.
  • Веб-сервер на узлах Apache либо NGINX

Пример 4

3 VPS c MediaWiki, Moodle и MariaDB и HA настроен с использованием пакетов Corosync и Pacemaker.

Пример 5

3 VPS для баз данных и один для приложений. Для данного кластер предлагают использовать InnoDB с ProxySQL в качестве промежуточного программного обеспечения.

Пример 6

Кластер на 5 VPS: 3 VPS для приложений и баз данных, 2 VPS - HAPoxy с использованием протокола VRRP (keepalived). Таким образом, в случае выхода из строя одного HAProxy, его место займет второй. Для мониторинга использовать Nagios.

Пример 7

Развернуть кластер на percona XTRADB (в основном это кластер MYSQL, разработанный percona), а так же внедрить "heartbeat" так как это был бы лучший подход, нет необходимости менять IP-адреса ваших клиентов, поскольку у нас будет выделенный IP-адрес. Однако, это имеет ограничения.

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

Объёмы работ

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

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

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


Контракт

We need to add HA (high availability) capacity, most affordably and well-documented, of the services of three applications -- MediaWiki (pravka.bskol.com), Wordpress (vebka.bskol.com) and Moodle (ucebka.bskol.com). Right now, they are run on the 3 VPS cluster that also hosts AVideo (backa.bskol.com), but AVideo is moving to a separate project. The VPS are located in various regions. The database selected is MariaDB and the three databases are synchronized with MariaDB Galera Cluster.

Development Terms: We have bought one more VPS for HAProxy and related software. We will create and provide empty proxmox machines on which you need to install programs: MediaWiki (pravka.bskol.com), Wordpress (vebka.bskol.com) and Moodle (ucebka.bskol.com). MariaDB databases are synchronized using MariaDB Galera Cluster. MediaWiki should be version 1.31.1.

The directories should be synchronized. You must: 1. check and configure the sql cluster on all sql node. 2. test sql cluster to see if data are well replicated. 3. check the haproxy node to see version and confirm the configuration, ACL and front/backend config. 4. check the haproxy node to see if firewall is installed and online to be configured. 5. check the route from the haproxy to all nodes. Can it join all node without too much TTL. 6. configure the front end on the haproxy. 7. add the first backend on the haproxy to point to the first node. 8. test the configuration by calling apps URL using haproxy IP. 9. add another backend and test by calling the apps URL via haproxy IP. 10. test to remove one node to see if calling the apps URL still working. 11. if not, debug. If yes, add another node to test. 12. write the most complete documentation

We will transfer your setup/findings/design to our current VPS servers ourselves.

We see two parts of acceptance testing. If both are successful, the contract shall be considered completed. a. During software testing, we will shut down 2 of 3 nodes to see whether the cluster is still available. b. 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.

The deadline for this project is October 23rd, 2022. If we don't complete the project by that time, all the access details will be changed, the project would be considered unsuccessful, and we would return back to the positions before the project.

Принцип отбора

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

Вопросы к подрядчику

  1. Сколько нам обойдётся кластер с всеми дополнительными расходами?
  2. Сколько вам нужно времени для реализации кластера с докладной документацией?
  3. Как вы видите реализацию данного задачи? (Методы и приложения для реализации)
  4. Каждый узел имеет по два IP адреса: IPv4 и IPv6. Нужно ли нам докупать дополнительные IP адреса?
  5. Чем будет обеспечен мониторинг кластера?
  6. Что относительно безопасности, какие защитные стены (firewall) предусмотрены?

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

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