Делова Ферма

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

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

Размещение

Hetzner является поставщиком услуг размещения, у которого "Железо" арендуется.

Отказоустойчивость

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

Сеть инфраструктуры

Для объединения трёх Желез в сеть используется инструмент Hetzner vSwitch.

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

Железo для Инфраструктуры выбрано на аукционе -- https://www.hetzner.com/sb?hdd_from=500&hdd_to=1000 -- поделившись экраном с выбранным подрядчиком исходя из следующих соображений:

• Целевой рабочий объём жёсткого диска для этого Кластера -- 512Gb.
• Как минимум один, основной сервер выбран с SSD и, желательно, NVMe, и частотой процессора в 64Gb.
• Как минимум два "несущих" сервера выбраны в одном датацентре. Хотя Hetzner не берёт оплату за траффик, это обстоятельство повышает скорость работы Кластера. Если второй сервер не был бы доступен в том же датацентре, мы искали бы его в других датацентрах то же города или месторасположения.
• Подрядчик предпочёл сервер на процессоре Intel Xeon E3-1275v5 серверу на Intel Core i7-7700.
• Требования к третьему железу ниже, чем к "несущим". Один кандидат утверждал, что его объём может быть меньше, так как на нём может быть установлен только ProxmoxVE.

Железо 1

1 x Dedicated Root Server "Server Auction"

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

Железо 2

1 x Dedicated Root Server "Server Auction"

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

Железо 3

1 x Dedicated Root Server "Server Auction"

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

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

Виртуальная среда каждого Железа собрана на основе ProxmoxVE (здесь и далее -- "Среды), в данный момент, v.7.2.

Сети Сред

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

Хранилища Сред

Для хранения данных, каждая Среда использует платформу распределённого хранилища Ceph.

Защитные стены

Для раздачи адресов виртуальным машинам, каждая Среда использует программу iptables.

Поиск подрядчиков

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

Объявление

Объявление на разовую работу опубликовано на upwork:

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

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

Ceph, iptables, vSwitch. We plan that each node would have one VM or container for testing.

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

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

This project is a fixed-price one. When we send you an offer, we will change the terms. To complete the project, the selected contractor will be given an admin access, but not full robot credentials.

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

Нам нужен кластер с нуля и мы отдадим подряд тому,

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

Собеседования

Найм людей -- отличный способ узнать об аспектах проекта и получаемого в его процессе изделия. Идеально проведённые собеседования добавляют документации на Правку.

Полученные заявки

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

Порядок разработки

Кто и что

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

Как не надо

• Знаходимо людину, яка нас задовільняє на даний проект (або декілька людей), так как он или она хорошо говорит, пишет, выглядит, вовремя выходит на связь, быстро отвечает и так далее.
• Зв'язуємось (бажано дзвінком) для уточнення деталей і надання необхідних даних (в цей же етап можна задавати питання про сервера, які, куди, як..).
• Согласовываем полученные детали, щоб розуміти всі ці тонкощі і надавати комусь якісь доступи - заслуховуємо його или её оцінку по бюджету цього проекту - розуміємо підходить нам чи ні.
• Даємо роботу або відмовляємо.

Как надо

1. Задокументировать требования на этой вики-странице. Эти требования должны включать описание того, что мы должны получить (так называемые "Объёмы работ") и как мы о том узнаем (так называемая "Приёмка").
2. Перевести указанные в "Объёмы работ" секции и секцию "Приёмочные тесты" на английский и включить в контракт. Если они не включены, то мы получим то, что нам надо в одном случае из 100. В 99 остальных случаях, мы получим то, что нам не надо или за те деньги, на которые мы не рассчитываем.
3. Действовать далее по рубрике Как не надо; после выполнения предыдущих пунктов, она имеет смысл.

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

Объёмы работ

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

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

Для того, чтобы убедиться в том, что то, что представлено подрядчиком -- это то, что нам надо (aka отвечает критериям приемлемости), порядок приёмочного тестирования установлен следующим:

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

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

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

Есть две окончательно неразрешённые проблемы касаемые ПО платформы:

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

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

• Что надо от нас, кроме присуждения контракта, решений по Архитектуре платформы и данных Железа?
• Насколько полезны для этой разработки Полезные рекоммендации?

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

• https://www.informaticar.net/how-to-setup-proxmox-cluster-ha/ (using Ceph without Hetzner vSwitch)
• https://community.hetzner.com/tutorials/hyperconverged-proxmox-cloud (using Ceph with Hetzner vSwitch)
• https://pve.proxmox.com/wiki/High_Availability (general ProxmoxVE HA functionality)
• https://docs.hetzner.com/robot/dedicated-server/network/vswitch/ (general Hetzner vSwitch functionality)