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

Материал из Брацка Правки
Перейти к: навигация, поиск
(Предложения относительно реализации)
(Пример 1)
Строка 145: Строка 145:
 
==Предложения относительно реализации==
 
==Предложения относительно реализации==
 
===Пример 1===
 
===Пример 1===
:Для развертывания использовать Docker. Кластер построен на трех VPS на каждом из которых:
+
:Для развертывания использовать Docker. Кластер построен на 3 VPS на каждом из которых:
 
*Базы данных MariaDB синхронизированы з помощью MariaDB Galera Cluster.
 
*Базы данных MariaDB синхронизированы з помощью MariaDB Galera Cluster.
 
*Для разделения чтения - запись между между узлами, соответственно и балансировки нагрузки использовать MariaDB MaxScale.
 
*Для разделения чтения - запись между между узлами, соответственно и балансировки нагрузки использовать MariaDB MaxScale.
 
*Для сертификатов cloudflare и пользовательских портов использовать Nginx Proxy.
 
*Для сертификатов cloudflare и пользовательских портов использовать Nginx Proxy.
 
*Пользовательские прилады.
 
*Пользовательские прилады.
 +
===Пример 2===
 +
:Для развертывания использовать Docker. Кластер построен на 5 VPS из которых:
 +
*Два небольших VPS для MariaDB и один нано-узел для MariaDB Arbiter.
 +
*Два VPS для Maxscale, Moodle, MediaWiki и Nginx Proxy.
 +
Для MariaDB HA — мы будем использовать плагин Galera и Maxscale для маршрутизации.
 +
Для синхронизации данных  в реальном времени мы будем использовать lsyncd по мере необходимости, для некоторых изображений или чего-то подобного.
 +
Они будут использовать CloudFlare для маршрутизации к прокси-серверу Nginx и бесплатным сертификатам.
  
 
==Передача и приёмка==
 
==Передача и приёмка==

Версия 14:26, 8 августа 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

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

Базы данных

В качестве основной базы данных для всех приложений Кампусной Фермы используется 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, to our 3 VPS cluster that hosts 3 applications -- MediaWiki (pravka.bskol.com), Moodle (ucebka.bskol.com), and AVideo (backa.bskol.com). 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. While talking about HA, we mean HA of the Moodle and MediaWiki primarily. AVideo may be moved to another project. Our current architecture may be adjusted to the HA solutions as well.
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.
What else do you need?
В данный момент, мы используем три VPS арендованных у Contabo для размещения трёх приложений -- MediaWiki, Moodle и AVideo. Два VPS размещены в США, один -- в Германии. Базой данных выбрана MariaDB и три базы синхронизованны MariaDB Galera Cluster. Основная решаемая проблема -- это высокая доступность. Дополнительная проблема -- это Geocast. После решения дополнительной проблемы, мы планируем отказаться от одного VPS в США и добавить один VPS в Сингапуре. Мы также открыты к разработке отдельного кластера под AVideo.

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

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

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

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

Пример 1

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

Пример 2

Для развертывания использовать Docker. Кластер построен на 5 VPS из которых:
  • Два небольших VPS для MariaDB и один нано-узел для MariaDB Arbiter.
  • Два VPS для Maxscale, Moodle, MediaWiki и Nginx Proxy.

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

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

Объёмы работ

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

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

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

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

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

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

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