Распределенные файловые хранилища: как это работает
Разберитесь в распределенных файловых хранилищах, таких как IPFS и Ceph. Репликация, согласованность и отказоустойчивость в современных системах.
Распределённое файловое хранилище распределяет данные по множеству узлов так, чтобы ни одна машина не была узким местом или единственной точкой отказа. Архитектурные решения — как размещать данные, как реплицировать, как обрабатывать сбои узлов, как поддерживать согласованность — отличают системы вроде Ceph (объектное/блочное/файловое), GlusterFS (POSIX), HDFS (пакетная обработка больших данных), MinIO (S3-совместимое) и системы с адресацией по содержимому, как IPFS и Filecoin. Каждая нацелена на разные рабочие нагрузки, и компромиссы вполне реальны. Вот конкретный разбор того, как эти системы работают.
Репликация против стирающего кодирования
Два подхода защищают от сбоя узла. Репликация хранит несколько полных копий: по умолчанию в Ceph это 3-кратная репликация, то есть объект в 1 ГБ использует 3 ГБ сырого хранилища. Просто рассуждать, быстро читать, дорого по месту. Стирающее кодирование делит данные на k информационных чанков плюс m контрольных с использованием кодов Рида-Соломона: схема (10,4) хранит 14 чанков и допускает 4 отказа с накладными расходами всего 40% вместо 200%. MinIO использует стирающее кодирование по умолчанию; Backblaze Vaults применяют Reed-Solomon 17+3. Чтение при стирающем кодировании медленнее, потому что восстановление может потребовать нескольких чанков — поэтому горячие данные часто используют репликацию, а холодные — стирающее кодирование.
Консистентное хеширование и размещение данных
Как система решает, какой узел хранит какой объект? Консистентное хеширование, введённое в академической работе Карджера и др. (1997) и популяризированное DynamoDB и Cassandra, хеширует ключи в кольцо и сопоставляет каждый диапазон с узлом. Добавление или удаление узла перемещает лишь долю ключей, а не весь набор данных. Ceph использует CRUSH (Controlled Replication Under Scalable Hashing) — детерминированный алгоритм, размещающий объекты на основе карты топологии (стойка, ряд, дата-центр), так что реплики попадают в разные домены отказов. Виртуальные узлы (vnode) на физический узел сглаживают неравномерность нагрузки.
Модели согласованности: строгая, конечная и причинно-следственная
Теорема CAP гласит, что нельзя одновременно иметь согласованность, доступность и устойчивость к разделению — нужно выбрать два. Строгая согласованность (линеаризуемость) означает, что чтения всегда видят последнюю запись; системы вроде Spanner и etcd обеспечивают это через протоколы консенсуса Paxos или Raft. Конечная согласованность (DynamoDB, Cassandra, S3 для некоторых операций) означает, что реплики сходятся со временем, но возможны устаревшие чтения. Причинно-следственная согласованность сохраняет порядок причина-следствие без полной линеаризуемости. Файловое хранилище часто принимает конечную согласованность для метаданных (листинг, размер) при строгой согласованности для чтений-после-записи того же объекта.
Архитектура Ceph: OSD, Monitor, Manager и MDS
Ceph работает с четырьмя типами демонов. OSD (Object Storage Daemon) хранят объекты и реплицируют их; кластер обычно содержит 10–1000 OSD на HDD или NVMe. Мониторы (MON) поддерживают состояние кластера через Paxos; 3 или 5 MON обеспечивают кворум. Менеджеры (MGR) экспонируют метрики и хостят дашборды. MDS (Metadata Server) обслуживают POSIX-уровень CephFS. Объектное хранилище через RADOS Gateway (RGW) предоставляет S3 и Swift API. Блочное хранилище через RBD поддерживает тома OpenStack и диски ВМ. Одна кодовая база, три ипостаси, настраиваемые через /etc/ceph/ceph.conf и редактирование CRUSH-карты.
HDFS и его наследие Hadoop
HDFS (Hadoop Distributed File System) нацелен на большие последовательные чтения для задач MapReduce и Spark. Файлы делятся на блоки по 128 МБ или 256 МБ; каждый блок реплицируется 3 раза по умолчанию через DataNode. NameNode держит все метаданные в памяти, ограничивая масштаб примерно 500 миллионами файлов на NameNode. HDFS Federation и HDFS Router добавляют поддержку нескольких пространств имён. HDFS плохо справляется с маленькими файлами (метаданные доминируют) и POSIX-совместимостью, но отлично — с аналитикой терабайтных наборов данных. Его также вытесняет объектное хранилище (S3, GCS) по мере разделения вычислений и хранения в облачную эпоху.
Адресация по содержимому: IPFS и Filecoin
IPFS (InterPlanetary File System) идентифицирует содержимое по его хешу (CID, Content Identifier), а не по расположению. Любой хранящий файл с тем же содержимым получает тот же CID. Поиск использует DHT (Distributed Hash Table, на основе Kademlia) для нахождения узлов, хранящих содержимое. Filecoin добавляет экономические стимулы: майнеры доказывают хранение через PoRep (Proof-of-Replication) и PoSt (Proof-of-Spacetime) и зарабатывают токены FIL. IPFS подходит для архивирования и децентрализованной публикации (метаданные NFT, web3-сайты); медленно для интерактивных нагрузок из-за задержки поиска DHT (сотни миллисекунд до секунд).
Объектное хранилище: S3, R2, B2 и MinIO
Объектное хранилище предоставляет плоский API «ключ-значение»: PUT объекта с ключом, GET обратно. Нет директорий, нет POSIX-семантики. Эта простота обеспечивает огромный масштаб: AWS S3 хранит триллионы объектов с долговечностью 11 девяток. Клоны — Cloudflare R2, Backblaze B2, Wasabi, DigitalOcean Spaces — реализуют S3 API на разных бэкендах. MinIO работает локально как open source под AGPL v3, часто в Kubernetes как StatefulSet, обеспечивая S3-совместимое хранилище на обычном оборудовании. Объектное хранилище в основном выиграло рынок облачного хранения: API прост, цены понятны, надёжность заслуживает доверия.
Стирающее кодирование на практике: как работает восстановление
При сбое узла в системе со стирающим кодированием оставшиеся узлы восстанавливают потерянные чанки. Для кода Рида-Соломона (10,4) любые 10 из 14 чанков восстанавливают исходные 10 информационных через матричную алгебру над конечным полем. Нагрузка восстановления ложится на выжившие узлы: потеря 1 узла в кластере из 100 запускает чтение с 10 других узлов на каждый потерянный чанк. Пропускная способность при перестройке — главная операционная проблема. Системы типа Ceph ограничивают скорость перестройки, чтобы не влиять на производительность. Новые коды — LRC (Local Reconstruction Codes, используемые Azure) и Hitchhiker — уменьшают полосу пропускания при восстановлении, допуская частичное чтение.
Хвостовые задержки и хеджированные запросы
Распределённые системы имеют длинные хвосты. Запрос, попавший на медленный диск или перегруженную сеть, может занять в 10 раз больше медианы. Статья Google «The Tail at Scale» (Дин и Барросу, 2013) формализовала техники: хеджированные запросы отправляют дублирующие чтения двум узлам и отменяют проигравшего; связанные запросы координируются так, чтобы реально выполнялся только один. Ceph, DynamoDB и Spanner используют вариации этого. Для сервисов передачи файлов параллельное чтение объекта через несколько реплик с взятием первого ответа кардинально снижает задержку p99 ценой незначительно большего трафика.
Домены отказов и разнообразие данных
Три реплики не помогут, если все три в одной стойке, а коммутатор этой стойки сломался. Учёт домена отказов означает, что реплики попадают в разные стойки, ряды или дата-центры. Правила CRUSH в Ceph кодируют: «минимум 2 копии в разных стойках, 1 в другом дата-центре». Облачное объектное хранилище обрабатывает это прозрачно: S3 Standard хранит данные в 3+ зонах доступности. Для кросс-региональной репликации S3 Cross-Region Replication (CRR) асинхронно зеркалирует объекты в другой регион — полезно для аварийного восстановления и соответствия требованиям о локализации данных (в России — по 152-ФЗ, требующему хранения персональных данных на серверах внутри страны).
Практические следствия для сервисов передачи файлов
Сервис передачи файлов обычно строится на объектном хранилище, а не на файловой системе POSIX. S3-совместимые бэкенды (AWS S3, Cloudflare R2, MinIO) обеспечивают долговечность и масштаб без необходимости запускать Ceph или GlusterFS самостоятельно. Сервис добавляет аутентификацию, presigned URL, метаданные и функции для пользователей. HexaTransfer использует S3-совместимый бэкенд с клиентским шифрованием AES-256-GCM: распределённый слой хранилища обеспечивает долговечность, а прикладной уровень сохраняет содержимое файлов конфиденциальным для каждого уровня.
Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.
Безопасная отправка больших файлов со сквозным шифрованием
Передавайте файлы до 10 ГБ бесплатно со сквозным шифрованием. Регистрация не требуется. Ваши файлы шифруются в браузере перед загрузкой — никто другой не может их прочитать.
Отправить файл