Брацки Фермы

Материал из Брацка Правки
Версия от 13:46, 20 мая 2022; Gary (обсуждение | вклад) (→‎Разработка Ферм)
Перейти к: навигация, поиск

Брацки Фермы (здесь и далее по тексту -- Фермы) -- это инфраструктура Брацка Облака (здесь и далее по тексту -- Облака). Архитектура облачной инфраструктуры не определена. Скорее всего, когда работа Школы войдёт в привычный режим, инфраструктура должна состоять из некой комбинации частного и общественных облаков.


Частное облако

Если частное облако будет признано необходимым, оно будет построено на OpenStack технологии. Требования: существование резервной модели работы и возможность восстановления работоспособного состояния, включая бэкапы на все собственные данные и разработки.

Существующие сервера

Hetzner EX40-SSD

Описание URL Технология Предназначение Проблемы
DC 21, 32GB, 30 TB, IP 148.251.188.31, €49.58 в месяц careernetworkministry.org Odoo Административный учёт (а) Нет центральной авторизации пользователей; (б) практически никто не пользуется; (в) непонятно, что, если что-то, было выполнено по безопасности, (г) не описан порядок создания и восстановления резервных копий, (д) не описана структура системы (связана ли эта инсталляция с другими и, если да, то как), (е) не описана структура первичных и вторичных баз данных, (ж) не описан порядок обновления версий, (з) не описан порядок обслуживания
theeconomicgroup.org
friendsofcnm.com
theeconomicgroup.com HTML5 Прототип вэбсайта. Надо развивать прототип.
friendsofcnm.org MediaWiki Открытый источник знаний и, одновременно, работа для новичков. (а) Нет центральной авторизации пользователей; (б) неверное размещение -- вики занимают место вэбсайта представляющего Друзей СПС, (в) непонятный URL -- обеспечение добавляет /index.php/, которое может сбить с толку посетителей; (г) невозможно загружать иллюстрации; (д) отсутствие логотипа; (е) не поддерживается многоязычность; (ж) официально не прописаны правила создания, хранения и восстановления запасной версии, если таковые имеются, и так далее.
Не определено. Moodle Программное обеспечение курсов и других учебных операций типа экзаменов, опросов, семинаров и так далее. (а) Нет центральной авторизации пользователей; (б) непонятное размещение; (в) отсутствие описания; (г) отсутствие логотипа и так далее.

DigitalOcean droplets

Описание URL Технология Предназначение Проблемы
NYC1, 2GB, 50GB disk, IP 159.89.93.1, $10 в месяц Новый дроплет под Оплёт
  • Opplet на opplet.net -- самописанная на Yii система управления пользователями
 Проблем нет; это -- один из двух активно используемых дроплетов на данный момент -- Backups are currently enabled
NYC1, 2GB, 50GB disk, IP 159.89.230.212, $10 в месяц Новый дроплет под систему для работы с Оплётом
  • Инсталляция Redmine -- она стоит отдельно от всего для использования исключительно администраторами.
  • Инсталляция Moodle на https://wiki.ksacerts.com

Общественное облако

Общественное облако типа AWS должно быть использовано первым из-за меньших расходов по его вводу в эксплуатацию.

Железо 1

Физическая oснова (1)

Железный сервер (bare metal) арендован на hetzner.de. Он имеет такие характеристики:
  • Dedicated Root Server SB35
  • Intel Core i7-3930
  • 2x HDD SATA 3,0 TB
  • 8x RAM 8192 MB DDR3
  • NIC 1 Gbit - Intel 82579LM
  • Location: FSN1 (Falkenstein/Vogtland, Germany) -- DC7
  • Rescue system (English)

IP адреса (1)

Основной IP адрес Железа -- наш-IP . На начало февраля 2022, Железо использует один дополнительный IP адрес 4-го протокола (IPv4):
  • IP: 5.9.40.133
  • Gateway: 5.9.40.129
  • Netmask: 255.255.255.224
Не предпринималось попыток работать с IP адресами 6-го протокола (IPv6).

Виртуализация (1)

Два инструмента задействованы для виртуализации:
  1. На уровне основного сервера, виртуализация выполнена средствами RAID, то есть два жёстких диска HDD SATA действуют как один диск на 3,0 TB, обеспечивая сохранение данных в случае отказа одного из дисков.
  2. Для создания виртуальных машин и работы с контейнерами, установлена среда ProxmoxVE.

Железо 2

Физическая oснова (2)

Характеристики второго(bare metal)сервера:
  • Dedicated Root Server
  • Intel Xeon E3-1245
  • 2x HDD SATA 3,0 TB Enterprise
  • 4x RAM 8192 MB DDR3 ECC
  • NIC 1 Gbit Intel 82574L
  • RAID Controller 4-Port SATA PCI-E LSI MegaRAID SAS 9260-4i
  • Location: FSN1 (Falkenstein/Vogtland, Germany) -- DC7
  • Rescue system (English)

IP адреса (2)

На основном сервере используется либо локальный IP, либо частный диапазон IP с DHCP. Если не возникнет особых проблем, мы планируем использовать 2 адреса IPv4. Мы также открыты для изучения IPv6. Если мы используем адреса About ipv4, нам нужно 5 ips: один для основного сервера, два для шлюза, три для любого vps или контейнера и четыре для Wordpress vps, и 5 для любого другого, который нам понадобится в будущем.

Виртуализация (2)

ProxmoxVE поставляется с OpenZFS, поэтому мы настоятельно рекомендуем использовать его. Также будут обсуждаться другие реализации программных RAID на различных уровнях. На данном этапе мы не рассматриваем аппаратные решения, чтобы избежать зависимости от проприетарных карт RAID.

Доступы

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

Управление виртуальными машинами и контейнерами производится через интерфейс ProxmoxVE. Остальные доступы организованы по SSH.

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

Для доступов пользователей к виртуальным машинам используется Apache Guacamole, на котором построен узел удаленных рабочих столов. Пользователь заходит на машину и работает на ней аналогично работе на собственном компьютере или друго устройстве.

Защита

Для предотвращения так называемых brute-force attack, то есть попыток подобрать пароли методом перебора множества вариантов, был установлен Fail2Ban.
При предоставлении доступа через SSH к тем машинам, на которых был установлен WordPress и Moodle, там постоянно что-то происходило, не давало зайти по SSH. Именно на этих 2-х машинах Fail2Ban был отключен первым.
Далее, Fail2Ban делал записи в iptables, из-за которых невозможно было получить доступ к серверам по SSH для Apache Guacomole. После этого Fail2Ban был заблокирован.

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

Аварийное восстановление

Инструкция по восстановлению инфраструктуры после аварии должна позволить восстановить отдельные:

Вычислительные сервера

В настоящее время, используется пять виртуальных частных серверов (virtual private server; VPS):
  1. Три арендованы у Contabo; два сервера и отдельное дисковое пространство для резервных копий располагаются в Сент-Луисе, Миссури, США, один -- в Германии. Планов уезжать с Contabo нет, но есть план заменить один сервер в Сент-Луисе, Миссури на сервер в Сингапуре;
  2. Два VPS (они зовут их "дроплетами") арендованы у DigitalOcean; один располагается в Нью-Йорке, США, один -- во Франции. Планов уезжать с DigitalOcean нет.
Для создания собственных виртуальных серверов, скорее всего, будет арендован физический сервер (bare metal) у hetzner.de в Германии.

Мониторинг

Мониторинг систем включает мониторинг работы как вычислительных серверов, так и приложений.
  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, но его пока не получилось подключить к базам данных. Планируется далее продолжить просмотр других специализированных приложений.
  2. Для мониторинга отдельных приложений и баз данных, помимо систем сетевого мониторинга, планируется использовать их внутренние функции, а также другие существующие решения.

Почтовый сервер

Команда планирует поднять highload мультидоменный почтовый сервер на основе существующего. На данный момент установлены чистые Postfix, Dovecot и Roundcube без каких-либо коробок. Они позволяют:
  1. Зарегестрироваться на opplet с почтовым адресом *@cnmcyber.com
  2. С этим адресом зайти на RoundCube
  3. Отправить почту себе на email
Настроены следующие DNS-записи:
  • DomainKeys Identified Mail (DKIM)
  • Sender Policy Framework (SPF)
  • Domain-based Message Authentication, Reporting and Conformance (DMARC)
Не известно, шифруется ли почта TLS протоколом. Количество пользователей не определено -- все, кто имеет право на почту, должен её иметь. В перспективе в Оплёте будет добавлено одно поле для корпоративного имейла. Проблемы с дисковыми пространствами будут решаться отдельно.
Требуется:
  • Выбрать, установить, настроить, провести нагрузочное тестирование, отмониторить продакшн и откоректировать параметры такого решение для почты, которое бы дружило с нашим WSO2 IS, через который идёт управление пользователями.
  • Добиться того, чтобы почта приходила не в спам, а во входящие.
  • Задокументировать работающие решения и настройки.
В качестве подходящего обеспечения рассматривались три варианта:
  1. Оставить чистые Postfix, Dovecot и Roundcube без каких-либо коробок.
  2. Переключить на пакет iRedMail, который включает в себя Postfix, Dovecot, Roundcube. Когда Облако строилось на OpenLDAP, был найден подрядчик, требования которого были: 1. Что бы у всех пользователей было заполнено поле mail 2. Новый пользователь vmail (пароль скажут после установки пакета iRedmail) 3. Поле для квоты. Также обсуждался безопасный тунель между сервером почты и сервером OpenLDAP. Найденный подрядчик считал, что лучшее решение -- это использование VPN, чтобы и OpenLDAP, и Dovecot виртуально были бы в одной сети. Авторизация почтового сервера идёт через Dovecot. Другой специалист называл такое решение идиотским. После решения о переходе с OpenLDAP на WSO2 IS подрячиков не искали.
  3. Добавить OnlyOffice, который включает в себя всё тот же iRedMail, но только с авторизацией уже на платформе OnlyOffice. Похоже,OnlyOffice предоставляет возможность синхронизации пользователей с LDAP, но пока не известно, как он интегрируется с WSO2 IS.
Почтовые ящики работают на основе построенного сервера.

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

В Облаке, к резервному копированию применяется несколько подходов. Копируются приложения и сервера; сохраняются базы и делаются снимки.
  • Изначально использовался rsync для копирования файлов, еженедельно полный бэкап и ежедневно incremental бэкап заливались на backup space на Contabo. Была идея использовать rsnapshot для снимков, но эту идею пока не получилось реализовать.
  • Весной-летом 2021 года, начались эксперименты с Veeam Agent for Linux, для которого был установлен VNC® Viewer. Это обеспечение позволило копировать полный сервер. Сервера копируются на себя, что вначале это вызывало проблему нехватки места. В настоящее время, копируются только новые данные (increment). Таким образом избегается дублирование и экономится место. Далее планируется научиться копировать сервера на backup space.
Надо создать:
  1. Подробное описание существующей системы.
  2. Процедуру проверки надёжности бэкапов.

Склад файлов

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

Базы данных

Облако задействует большой спектр систем управления базами данных, некоторые из которых структурированы, а некоторые ориентированы на документы.
  1. Наибольшая часть пользовательских приложений использует базы управления данными на основе MariaDB Server. Администраторское приложение PhpMyAdmin используется для администрирования каждого из них.
  2. Отдельные приложения, например, Брацка Крынка и Брацка Справа, задействуют базы управления данными на основе PostgreSQL.
  3. Обособленная установка MariaDB Server, отличная от той, что поддерживает большую часть пользовательских приложений, также вовлечена в управление пользователями Оплёта.
  4. Идентификационный сервер Оплёта, то есть та его часть, которая работает с другими приложениями, построен на базе сервера WSO2 IS и задействует три базы H2 DBMS.
  5. NoSQL и структурированные распределённые базы будут задействованы в работу будущей интеграционной платформы Оплёта.

Интеграция данных

  1. Сейчас, база каждого пользовательского приложения установлена на трёх нодах и синхронизована через Кластерное копирование. Есть план сделать одну распределённую базу и интегрировать её в Оплёт с тем, чтобы базы приложений забирали данные оттуда. В качестве интеграционного решения серъёзно рассматривается WSO2 Enterprise Integrator. Этот интегратор работает и как ESB, и платформа для микросервисов. В качестве распределонной базы один специалист рекоммендовал NoSQL -- Apache Cassandra. Другой вариант -- распределённую SQL типа CockroachDB.
  2. Наиболее приоритетная задача -- создать архитектуру базы клиентов. Сейчас клиенты учитываются в нескольких независимых приложениях. Они имеют CRM модули, которые призваны учитывать работу с клиентами, которые могут является, но скорее всего не являются пользователями. Надо создать базу, в которую каждое приложение заливало новые данные и брало старые. Предложение заключалось в общей master базе, информация в которую может вбиваться с любого приложения, но отображаться в зависимости от её публичности.
  3. Есть также предложение создать собирать данные с различных приложений и хранить их в NoSQL базе. Ранее обсуждалась единая неосновная база данных для всей системы. Разговор шёл о комбинации Hadoop, ESB Mule и MongoDB. Идея была в сборе данных с разных приложений через ESB Mule, причёсывание их Hadoop'ом и размещение в MongoDB как дополнительной базе данных, откуда они могут браться для для личного кабинета (dashboard) пользователя. То есть, заходя в кабинет, пользователь мог бы в идеале видеть свою активность в разных приложениях и искать по всем системам сразу.
  4. Надо стабилизировать загрузку, хранение и использование картинок на MediaWiki. Сейчас они спорадически не загружаются или не отображаются. Например, 7 декабря картинки выбились, перестав отображаться. После клика на редактирование и сохранение, картинки появлялись -- этот сценарий повторялся на нескольких страницах. Затем всё само восстановилось. Аналогичные сбои происходили и раньше. Сама Википедия использует другую схему. Мы рассматриваем перенос картинок в хранилище.

Обслуживающие кластеры

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

Облако задействует четыре кластерa; стойкость Облакаскладывается из стойкости отдельных кластеров. Кластеры Облака должны быть переделаны в отказоустойчивые (high-availability cluster). Каждый кластер должен поддерживать свойства географической доступности. Усилия по построению кластеров называются Кластерными проектами.

Кластер Жици

Основная вики-страница: Устойчивость для Жици
Вместе с Брацкой Вебкой, наиболее критическое приложение для маркетинга всего проекта -- это Брацки Жици на Jitsi. Эта видео-конференционная система пока установлена вместе с пользовательскими системами. Возможно, для него должен быть построен отдельный кластер, задействующий все имеющиеся в наличии сервера. Также обсуждается план увести её отдельно на CDN типа Cloudflare или глобальные облачные решения -- Microsoft Azure или AWS -- участники конференций могут находиться на разных континентах и требование к качеству особо высокое.

Кластер MariaDB

Основная вики-страница: Кластер MariaDB

Кластер Оплёта

Основная вики-страница: Кластер Оплёта
Кластер Оплёта -- это связка ресурсов Облака, обеспечивающая отказоустойчивость Оплёта, а также распределителей нагрузки (load balancer) остальных кластеров.

Кластер PostgreSQL

Основная вики-страница: Кластер PostgreSQL

Стойкость Облака

Архитектура Обслуживающих кластеров, то есть связок нескольких однотипных приложений или их баз данных с распределителями нагрузки между этими приложениями или базами, используется для обеспечения отказоустойчивости (high availability) Облака.

Принципы отказоустойчивости

  • Все пользовательские приложения дублируются -- копии каждого из них установлены как минимум на трёх вычислительных серверах в разных центрах.
  • Базы данных разных установок одного и того же приложения синхранизуются. Таким образом, обращаясь к любому из них, пользователь получает аналогичные данные и результаты вычислений.
  • Когда пользователь хочет обратиться к приложению, пользователь направляется на распределитель нагрузки (load balancer). Распределитель нагрузки постоянно связывается со всеми установками приложений, чтобы знать, какие из них находятся в наличии. От распределителя нагрузки, пользователь перенаправляется к той установке, которая работоспособна и доступнее для конкретного пользователя. Если какая-то из установок выходит из строя, пользователь этого не должен заметить. Как только распределитель нагрузки замечает отсутствие какого-либо ресурса, он запускает механизм отладки.

Кластеры и приложения

Ярус Название Основное ПО ПО базы данных Кластер
Связующее обеспечение Оплёт (ядро) Yii MariaDB Server Кластер Оплёта
Идентификация WSO2 IS H2 DBMS
Пользовательские приложения Бачка AVideo MariaDB Server Кластер MariaDB
Вебка WordPress
Жици Jitsi Отсутствует Устойчивость для Жици
Крынка GitLab PostgreSQL Кластер PostgreSQL
Пошта Roundcube
Правка MediaWiki MariaDB Server Кластер MariaDB
Связка SuiteCRM
Сетка HumHub
Справа Odoo PostgreSQL Кластер PostgreSQL
Учебка Moodle MariaDB Server Кластер MariaDB
  Арендованное обеспечение
Эксперементальные приложения Campus OpenEdX
  • MariaDB Server для данных пользователей;
  • MongoDB для непользовательских данных.
Agile Taiga software PostgreSQL
Project ProjecQtOr

Разработка Ферм

Основная вики-страница: Разработка Ферм
Источник — «https://pravka.bskol.com/w1/index.php?title=Брацки_Фермы&oldid=23693»