Реализация распределённого файлового хранилища с GlusterFS в Termux: кластеризация, репликация и отказоустойчивость

Автор: Усачёв Денис Евгеньевич, ведущий эксперт РыбинскЛАБ

Введение

В последние годы Termux превратился из «песочницы для команд» в полноценную среду для экспериментов с сетевыми сервисами. Один из наиболее практичных сценариев — создание распределённого файлового хранилища на базе GlusterFS прямо в пользовательской инфраструктуре: на нескольких смартфонах/устройствах под управлением Android можно собрать кластер, включить репликацию и проверить поведение при сбоях узлов.

Ниже — практический подход к реализации GlusterFS в Termux без «магии»: как подготовить узлы, как организовать локальную сеть, как создать пул и volume, как добиться репликации и как оценить отказоустойчивость. В тексте акцент сделан на развёртывание в рамках локальной сети (например, через Wi‑Fi).

Что важно учесть заранее

Перед стартом нужно понять ограничения и подготовить основу:

Сеть: узлы должны видеть друг друга по IP-адресам. Проще всего — одна локальная сеть Wi‑Fi; при необходимости можно создать локальную сеть через VPN-сервис (строго для объединения устройств в одну локальную сеть, а не для обхода блокировок).
Порты: GlusterFS использует набор портов (в зависимости от конфигурации). Если у вас Wi‑Fi с агрегацией клиентов/изоляцией, потребуется настройка сети.
Хранилище данных: на Android доступ к каталогу может отличаться. Лучше использовать Termux-хранилище (каталоги в домашней директории пользователя Termux) или подготовленный mount.
Стабильность: мобильные устройства подвержены «убийству» фоновых процессов. Следует включить исключения/неограниченный режим для Termux и отключить агрессивную оптимизацию батареи.

Архитектура: кластер, репликация и отказоустойчивость

GlusterFS опирается на понятия:

Peer — узлы кластера. Вы добавляете устройства в пул.
Том (volume) — логическое хранилище поверх дисковых директорий.
Brick — часть хранилища на конкретном узле (каталог).
Репликация — например, replica 2 или replica 3. Это и есть основа отказоустойчивости: данные хранятся на нескольких узлах.
Самовосстановление — при возвращении узла после сбоя GlusterFS репарирует данные в рамках настроек rebalancing/repair.

Для демонстрации отказоустойчивости обычно достаточно replica 2 (допускает потерю одного узла без потери доступности записей/данных в зависимости от режима). Для более устойчивого варианта — replica 3.

Подготовка среды Termux

Ниже приведён типовой набор шагов для подготовки Termux на каждом узле. Точные пакеты могут отличаться в зависимости от версии Termux и архитектуры устройства, поэтому используйте этот фрагмент как основу.

Предположим, у вас есть 3 узла в локальной сети: gluster-node1, gluster-node2, gluster-node3. У каждого будет свой IP в локальной сети.

Шаг 1. Обновление и установка базовых пакетов

pkg update
pkg upgrade -y
pkg install -y wget curl net-tools openssh termux-services

Примечание: некоторые сборки GlusterFS под Android могут требовать специфичных зависимостей. Если в вашей среде есть ограничения по сборке из исходников, имеет смысл заранее проверить доступность пакетов или использовать контейнеризацию/сторонние сборки.

Шаг 2. Размещение каталогов под bricks

Создайте каталоги, которые будут выступать в роли bricks. Например, на каждом узле:

mkdir -p ~/gluster/brick1
mkdir -p ~/gluster/brick2

В простом сценарии можно использовать только один brick на узел (например, ~/gluster/brick1).

Шаг 3. Организация локальной сети между узлами

Устройства должны видеть друг друга по IP. Вариантов несколько:

Один Wi‑Fi: убедитесь, что клиенты находятся в одной подсети.
VPN для создания локальной сети: если устройства не могут быть объединены через Wi‑Fi (например, разные VLAN/сети), используйте VPN только чтобы получить локальную сеть между узлами.

Для проверки доступности выполните на одном узле:

ping -c 3 <IP-узла>

Установка и запуск GlusterFS в Termux

На практике здесь чаще всего упираются в вопрос доступности GlusterFS в вашей сборке Termux/архитектуре. Самый надёжный подход — использовать один и тот же метод установки на всех узлах (либо готовые сборки, либо единый процесс сборки/установки из исходников).

Ниже — логическая схема дальнейших шагов, поскольку команды установки могут отличаться. Главное — получить работающий демон GlusterFS и возможность управлять кластером через gluster-клиент.

Шаг 4. Старт service (концептуально)

После установки GlusterFS запустите демон. В Termux это может быть как ручной запуск, так и через механизмы автозапуска.

# Примерная логика (названия сервисов зависят от реализации установки):
# systemctl start glusterd
# или запуск glusterd вручную
# glusterd -f

# Затем проверьте статус/слушание портов:
netstat -tulpn | grep -E 'gluster|24007|24008'

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

Создание кластера: пул и peer

Дальше выстраиваем кластер. Типовой сценарий: выбираете «первый» узел как координатор (на практике — любой, но для ясности назовём node1).

Шаг 5. Добавление узлов в пул

На node1 создайте пул (или начните с уже инициализированного peer). На последующих узлах выполните добавление peer.

gluster peer probe <IP-node2>
gluster peer probe <IP-node3>

gluster peer status

Важно: имена/ID узлов в GlusterFS часто формируются из hostname и настроек. При несовпадениях проверьте, что узлы имеют уникальные идентификаторы и корректно резолвятся.

Шаг 6. Подготовка bricks и добавление дисков

На каждом узле убедитесь, что путь к brick существует и доступен службе. Затем создайте/объявите brick в терминах GlusterFS volume. В большинстве примеров делается единым вызовом при создании volume.

Создание volume с репликацией

Рассмотрим пример replica 2 на трёх узлах. Тогда при желании вы можете выбрать 2 узла для репликации. В более «учебном» варианте — создать replica 3 на трёх узлах.

Вариант A: replica 3 (устойчивее)

Допустим bricks: node1:~/gluster/brick1, node2:~/gluster/brick1, node3:~/gluster/brick1.

gluster volume create gv0 replica 3 \
  node1:~/gluster/brick1 \
  node2:~/gluster/brick1 \
  node3:~/gluster/brick1 \
  force

gluster volume set gv0 diagnostics.client-log-level ERROR

gluster volume start gv0

gluster volume status

Здесь replica 3 означает, что данные реплицируются на 3 узла. На отказоустойчивость это влияет заметно: при потере одного узла кластер всё ещё имеет копии данных на остальных.

Вариант B: replica 2 (на двух узлах)

Если вы хотите минимизировать потребление места и сети, используйте два узла:

gluster volume create gv0 replica 2 \
  node1:~/gluster/brick1 \
  node2:~/gluster/brick1 \
  force

gluster volume start gv0

gluster volume status

Подключение клиента и проверка записи

Проверять лучше на отдельном узле (или хотя бы на одном из узлов кластера) как клиентский mount. На Termux «смонтировать» GlusterFS может быть сложно из‑за ограничений ядра и поддержки FUSE. Часто всё упирается в наличие fuse и прав. Если ваше окружение поддерживает FUSE, выполните:

pkg install -y fuse
mkdir -p ~/mnt/gv0

# Примерная команда (параметры могут отличаться):
# mount -t glusterfs node1:gv0 ~/mnt/gv0

# Проверка:
# cp somefile ~/mnt/gv0/
# ls -lah ~/mnt/gv0/

Если mount невозможен из-за ограничений FUSE/ядра, надёжнее проверять работоспособность через Gluster CLI и доступ к brick-каталогам на узлах (а также через команды статуса и событий).

Тестирование репликации и согласованности

После успешного создания volume сделайте тест:

Создайте тестовый файл через клиент (если монтирование доступно).
Сравните наличие файла/версий на brick-каталогах каждого узла.
Проверьте, что Gluster считает volume healthy.

Практические команды контроля

gluster volume heal gv0 full

gluster volume status gv0

gluster peer status

gluster volume info gv0

# Состояние репликации/healing (зависит от версии):
# gluster volume heal gv0 info

Если вы наблюдаете «неисправности» или отставание, не спешите с перезапусками: сначала выясните причину через логирование и status.

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

Чтобы оценить отказоустойчивость, смоделируйте отключение одного узла и проверяйте, что кластер сохраняет работоспособность volume.

Шаг 7. Нормальное состояние

gluster volume status gv0

gluster volume heal gv0 info

Шаг 8. Отключение узла

Выберите узел (например, node2). Отключите сеть или остановите службу GlusterFS на нём.

# Примерно (зависит от того, как вы запускали glusterd):
# kill <pid>
# или остановка сервиса
# pkill -f glusterd

# После этого проверьте на node1:
gluster peer status

gluster volume status gv0

Для replica 3 потеря одного узла обычно не приводит к полной потере доступности, но поведение зависит от режима распределения и текущих операций (запись/чтение/кворум).

Шаг 9. Возврат узла и восстановление

Снова включите node2, дайте времени на реконфигурацию и repair. Затем проверьте healing.

gluster peer status

gluster volume heal gv0 full

# Проверка:
gluster volume heal gv0 info

gluster volume status gv0

Типовые проблемы на Android/Termux и как их избежать

Фоновые ограничения батареи: настройте исключения для Termux, чтобы узлы не «засыпали» внезапно.
Разная «временная» картина: убедитесь, что системное время близко синхронизировано (ручная коррекция часто помогает).
Резолвинг имён: если Gluster ожидает имена, проверьте, что используете корректные hostnames/переопределения DNS/hosts (в пределах локальной сети).
Несовпадение путей: кирпичи должны указывать на реальные каталоги на каждом узле. Ошибка в одном пути ломает равномерность.
Порты и изоляция клиентов: некоторые Wi‑Fi сети не дают клиентам общаться напрямую.

Заключение

Реализация распределённого файлового хранилища на GlusterFS в Termux — вполне достижимая задача для лабораторных стендов и обучения кластерным технологиям. Ключевые элементы успеха: корректная локальная связность узлов, единообразная установка GlusterFS в среде Termux, правильная настройка volume с репликацией и регулярная проверка состояния через status/heal. Смоделировав отключение узла и вернув его обратно, вы на практике увидите, как работает отказоустойчивость и восстановление данных.

Если хотите быстрее пройти путь от идеи до рабочего кластера, настройка «под ключ» и консультации по выбору архитектуры, репликации и тестированию отказоустойчивости доступны в РыбинскЛАБ.