Надёжность и управление передачами

Граница обещаний

Реализованное клиентское восстановление при обрывах описано отдельно: TRANSFER_RECOVERY. Оно дополняет сохранение multipart-частей на сервере, но не заменяет резервирование узлов.

Ниже проектные требования. Ни один профиль HA пока не реализован и не испытан. Рабочая гипотеза — пережить одиночный отказ сервера в одной площадке; окончательная топология и RPO/RTO требуют исходных данных.

Standalone: один узел с backup, без доступности при его потере. HA: резервируются API/шлюзы, входной адрес, БД, содержимое и ключи. Один NAS/DB/LB остаётся единственной точкой отказа. Отдельная площадка требует отдельной схемы репликации и аварийного переключения.

Запись

Временное содержимое → проверка → устойчивый blob → фиксация доступной версии. Между blob-store и БД нет общей транзакции. Reconciliation восстанавливает промежуточные состояния; cleanup удаляет только проверенные осиротевшие объекты после grace period.

Подтверждённая часть и публикация должны переживать заявленный класс отказа. Local staging на единственном шлюзе не выполняет HA-гарантию. При асинхронной репликации нельзя обещать нулевую потерю подтверждённых записей.

При потере безопасного кворума новые публикации приостанавливаются. Автоматическое снижение долговечности запрещено без явной политики. Failover БД и storage реализуется проверенными инфраструктурными средствами с fencing, а не собственным голосованием приложения.

Очереди

Реализованная локальная часть: TRAFFIC_CONTROL — общий и per-principal payload budget, bounded admission, отмена и preClose, агрегаты readiness. Фиксированные доли download-бюджета и конечные leases уже реализованы для общего storage: READ_GATEWAYS. Динамическая распределённая координация, подтверждённые реплики и HA ниже остаются целевыми.

Раздельные upload/download/background очереди. PostgreSQL сохраняет задания, попытки, резервы и leases; короткие транзакции захвата, TTL, heartbeat, fencing generation и повторяемые операции. Фактическая передача не удерживает SQL-транзакцию.

Планировщик учитывает полосу площадки/шлюза/клиента, чтение/запись дисков, staging и параллелизм. Справедливость — по принципалу, а не только по IP. Приоритеты имеют aging и минимальную долю ресурса, чтобы миграция или большие файлы не голодали бесконечно.

Очередь ограничена по размеру и времени. Неактивные резервы истекают. При сетевом разделении просроченный lease не должен позволять старому шлюзу работать безлимитно параллельно с новым владельцем.

Сеть

Streams с backpressure/отменой и ограниченным буфером на поток. Раздача не проходит через внешние приложения. Least connections недостаточно для распределения байт/с; глобальный лимит нельзя заменить per-request лимитом Nginx.

Измеряемый первый алгоритм: допуски по параллелизму и консервативные бюджеты на узел/класс с перераспределением. Upload shaping и суммарные ограничения всех потоков одного клиента проверяются отдельным прототипом. Число шлюзов не увеличивает скорость общего uplink.

При падении узла TCP-поток обрывается; новый запрос может обслужить другой узел, а клиент продолжает через Range/If-Range. Не обещаем незаметный перенос соединения. API поддерживает задачи и resume; клиенты без Range/retry проверяются отдельно.

Деградация и безопасность

Ранее выданные ограниченные допуски могут работать в пределах TTL при недоступности API/БД, если это разрешено профилем. Задержка отзыва прав должна быть явно принята. Новым запросам без допуска нельзя выдавать байты в обход ACL.

При недостатке места блокируем новые uploads до повреждения рабочей ёмкости. Чтение и управление должны сохранять резерв ресурсов. Метрики/аудит не требуют записи в БД каждого блока файла.

Наблюдаемость и восстановление

Службы поднимаются сами после падения, незапрошенного выхода, потери владения хранилищем или аренды и зависания главного потока: systemd, службы Windows и Docker перезапускают процесс, а зависание превращает в выход сторожевой поток. Матрица по платформам — ADR 0067.

Нужны live/ready health, глубина и возраст очередей, p95/p99 управления, throughput, память на поток, свободное место/staging, отказы допуска, checksum errors, лаг репликации, возраст backup и результат restore.

Backup БД и содержимого согласован по точке восстановления; cleanup не уничтожает нужные старые blob. Backup хранится вне основного домена отказа. Регулярно восстанавливаемся на чистую среду: репликация не защищает от логического удаления.

Испытания: остановка процессов в каждой фазе upload; потеря ответа после commit; отказ узла БД/storage; сетевое разделение; заполненный staging; повтор части; конфликт перезаписи; отзыв доступа; удаление во время download; работа при отключённых внешних приложениях.

Last-N автоочистка фиксирует только tombstones и audit под repository gate; physical bytes остаются до успешного online GC; блокировки читателей и гарантии. Квоты сериализуют upload reservations с policy update и учитывают retired bytes. Scheduler bounded, с live key recheck; диагностика best-effort с ограничением памяти, не блокирует transfer на ожидании записи логов. Гарантии и ограничения.