Мы в HOSTKEY сдаем клиентам в аренду вычислительные мощности на площадках в Амстердаме, Нью-Йорке и Москве, при этом набор инструментов (в т. ч. список доступных образов ISO) должен быть одинаковым во всех локациях. Дистрибутивы могут потребоваться для ручной установки операционной системы на сервер, для выбора особой разметки и/или набора ПО, для восстановления системы, изменения разбивки загрузочного диска, либо если инсталляцию нужной системы мы еще не автоматизировали. Как проблема решается в нашей распределенной инфраструктуре с помощью протокола BitTorrent, рассказывает специалист отдела DevOps Алексей Фомин.
Проблема
В современных серверах есть модули IPMI, позволяющие загрузить файл ISO с компьютера клиента через веб-интерфейс или Java-апплет, но в случае значительной удаленности и/или медленного клиентского канала установка операционной системы может затянуться на часы. Для ускорения процесса логично держать пул наиболее популярных образов в непосредственной близости от сервера, а поскольку большинство модулей IPMI поддерживают монтирование ISO, на каждой из трех площадок у нас есть такое хранилище. Команда на IPMI для монтирования конкретного файла отправляется из клиентской панели управления.
Пример списка образов:
Для поддерживаемых нашей HTML5-консолью серверов внутри контейнера доступен идентичный список файлов ISO.
Еще есть виртуальные серверы, где загрузочный образ монтируется с ISO storage domain соответствующего кластера oVirt, и в итоге мы получаем минимум три хранилища только на одной площадке. Необходимо, чтобы списки образов везде были одинаковыми (так проще поддерживать их актуальность), а также нам нужна уверенность, что выбранный в панели конкретный файл существует и будет смонтирован. Даже если пожертвовать отказоустойчивостью и попытаться повесить все функции по раздаче ISO в пределах датацентра на один сервер, все равно их потребуется не менее трех (по числу локаций).
Решение
Первой на ум приходит идея простого копирования образов по расписанию с некоего эталонного источника, например, через RSYNC. Мы пошли немного другим путем и стали передавать данные по протоколу BitTorrent, организовав между серверами-хранилищами сеть P2P.
Для использующегося в нашей инфраструктуре дистрибутива CentOS (да и под остальные популярные платформы) есть отличная программа Resilio Sync (бывш. BTSync). Процесс ее развертывания довольно прост: ставим на каждый сервер по экземпляру из пакета rpm и генерируем конфигурационный файл, а также секретный ключ для шифрования трафика между хостами (это мы делаем уже с помощью Ansible).
Также возможна установка бинарного файла из архива:
wget https://download-cdn.resilio.com/stable/linux-x64/resilio-sync_x64.tar.gz
tar -xf resilio-sync_x64.tar.gz
cp rslsync /usr/local/bin
ln -s /usr/local/bin/rslsync /usr/local/bin/btsync
btsync --dump-sample-config > btsync.config
btsync --generate-secret
Правим конфигурационные файлы под наши нужды и раскладываем их по серверам. Для каждого сервера задаем "device_name" и актуальный путь к директории с образами: веб-интерфейс для настройки общих директорий нам не нужен, ее можно сразу прописать в блоке shared_folders.
Пример конфигурации для нашего случая:
# cat btsync.config
{
"device_name": "isoserver01.example.com", // уникальное имя для каждого сервера
"listening_port" : 58889,
"pid_file" : "/var/run/resilio.pid",
"use_upnp" : false,
"disk_low_priority" : true,
"lan_encrypt_data" : true,
"lan_use_tcp" : true,
"folder_rescan_interval" : 60,
"download_limit" : 0,
"upload_limit" : 0,
"shared_folders" :
[
{
"secret" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXX", // сгенерированный нами ключ
"dir" : "/PATH/TO/ISO/", // путь к синхронизируемой директории
"use_relay_server" : false, // relay-сервера нам не нужны
"use_tracker" : false, // чтобы ничего не отправлялось в BitTorrent Inc
"use_dht" : false, // аналогично
"search_lan" : false, // тоже не нужно, ниже мы зададим хосты списком
"use_sync_trash" : true, // удалённые на другом сервер файлы будут попадать в «корзину»
"known_hosts" : // список хостов нашей сети P2P
[
"isoserver01.example.com:58889",
"isoserver02.example.com:58889",
"isoserver03.example.com:58889"
]
}
]
}
Также необходимо открыть порт в настройках межсетевого экрана (пример для firewalld):
firewall-cmd --zone=internal --add-port=58889/tcp --permanent
firewall-cmd --reload
Чтобы развернуть решение, остается только создать сервис, обеспечивающий автоматический запуск программы при старте ОС. Теперь достаточно добавить файл на любом из хостов (например, в локации, из которой поступил клиентский запрос на новый образ), и через короткое время он появится на остальных. Если файл удалить, на остальных хостах он попадет в поддиректорию .sync/Archive/, и при необходимости образ легко восстановить.
Что в итоге?
В результате реализации этого решения мы получили надежную рабочую систему управления файлами образов ISO, а также их доставки до клиентских серверов. Resilio Sync работает по протоколу BitTorrent, что снимает ограничения на размер файлов и значительно сокращает время их передачи. Данные при этом передаются в зашифрованном виде и хранятся только на наших инфраструктурных серверах, что повышает защищенность системы.
___________
А еще в HOSTKEY можно пользоваться всеми возможностями технологичного API для быстрого заказа и управления серверами. Выберите сетевые настройки, операционную систему и получите любой сервер в течение 15 минут. Вы также можете собрать сервер индивидуальной конфигурации, в том числе с профессиональными GPU-картами.
Еще у нас можно добавить NVIDIA А5500, а специальный промокод для наших читателей «Я С ХАБРА» дает дополнительную скидку на любую покупку. При размещении заказа назовите промокод консультанту — и скидка ваша.
13werwolf13
1) непонятно зачем тащить rslsync wget'ом если есть deb и rpm репозитории
2) непонятно зачем переименовывать бинарь rslsync в btsync (ностальгия замучила?)
3) rslsync для использования на предприятии требует покупки лицензии, не лучше ли использовать syncthing который умеет всё то же самое и даже больше, и при этом не имеет таких лицензионных ограничений как rslsync?