6.11. Shared Storage Architecture
Shared Storage Architecture
Shared Storage Architecture — это подход к организации хранения данных, при котором несколько вычислительных узлов или систем одновременно получают доступ к одному и тому же пулу хранилища. Такая архитектура позволяет централизовать управление данными, повысить их доступность, упростить резервное копирование и обеспечить согласованность информации в распределённой среде. Shared Storage Architecture активно применяется в корпоративных ИТ-инфраструктурах, облачных платформах, высоконагруженных приложениях и системах, требующих отказоустойчивости и масштабируемости.
Основная цель этой архитектуры — отделение данных от конкретного физического сервера, что даёт возможность гибко распределять рабочие нагрузки, переносить виртуальные машины между хостами без потери доступа к данным и поддерживать непрерывную работу сервисов даже при сбоях оборудования.
Основные принципы работы
В Shared Storage Architecture данные размещаются не на локальных дисках отдельных серверов, а на внешнем хранилище, к которому подключены все узлы системы. Это внешнее хранилище может быть реализовано как специализированное устройство (SAN, NAS), программно-определяемая система (Software-Defined Storage) или облачный сервис хранения. Каждый узел взаимодействует с этим общим хранилищем через стандартные протоколы передачи данных, такие как iSCSI, Fibre Channel, NFS, SMB/CIFS или более современные решения вроде NVMe over Fabrics.
Ключевой особенностью такой архитектуры является то, что все узлы видят один и тот же набор данных в реальном времени. Это требует строгого управления параллельным доступом: если несколько узлов одновременно пытаются записать в один и тот же файл или блок данных, система должна гарантировать целостность информации. Для этого используются механизмы блокировок, метаданных, журналирования операций и координации между узлами.
Типы shared storage
Shared Storage Architecture реализуется в нескольких основных форматах, каждый из которых имеет свои характеристики, области применения и ограничения.
Блочное хранилище (Block Storage)
Блочное хранилище предоставляет доступ к данным на уровне отдельных блоков фиксированного размера. Узел, подключённый к такому хранилищу, воспринимает его как обычный диск, который можно форматировать файловой системой и использовать напрямую. Протоколы, используемые для блочного доступа, включают Fibre Channel, iSCSI и NVMe-oF.
Особенность блочного shared storage заключается в том, что для корректной работы нескольких узлов одновременно требуется кластерная файловая система (например, VMFS в VMware, OCFS2 в Oracle, GFS2 в Linux). Обычные файловые системы, такие как NTFS или ext4, не поддерживают одновременный доступ с нескольких узлов и могут привести к повреждению данных.
Блочное хранилище часто используется в виртуализированных средах, базах данных и высоконагруженных приложениях, где важна производительность и низкая задержка.
Файловое хранилище (File Storage)
Файловое хранилище предоставляет доступ к данным через абстракцию файлов и каталогов. Узлы взаимодействуют с хранилищем по протоколам, таким как NFS (Network File System) или SMB/CIFS (Server Message Block/Common Internet File System). В этом случае сам сервер хранения управляет файловой системой, а клиенты просто запрашивают файлы по имени.
Преимущество файлового подхода — упрощённая совместная работа: несколько узлов могут читать и писать в один и тот же каталог без необходимости установки специальной файловой системы на каждом клиенте. Однако производительность такого решения обычно ниже, чем у блочного, особенно при работе с большим количеством мелких файлов или при высокой частоте операций записи.
Файловое shared storage широко применяется в веб-серверах, системах обработки медиа, CI/CD-платформах и других сценариях, где важна простота доступа и совместное использование файлов.
Объектное хранилище (Object Storage)
Объектное хранилище представляет данные в виде объектов, каждый из которых содержит сами данные, уникальный идентификатор и метаданные. Доступ к объектам осуществляется через RESTful API, чаще всего по протоколу HTTP/S, с использованием таких стандартов, как Amazon S3, OpenStack Swift или Azure Blob Storage.
Хотя объектное хранилище технически тоже является shared — любой авторизованный клиент может получить доступ к любому объекту — оно не предназначено для прямого монтирования как файловой системы или блочного устройства. Вместо этого приложения взаимодействуют с ним программно, загружая и скачивая объекты по мере необходимости.
Объектное хранилище отлично подходит для хранения больших объёмов неструктурированных данных: резервных копий, логов, медиафайлов, архивов. Оно масштабируется горизонтально почти без ограничений и обеспечивает высокую отказоустойчивость за счёт репликации или кодов коррекции ошибок.
Преимущества Shared Storage Architecture
Централизованное управление данными
Все данные находятся в одном месте, что упрощает администрирование, мониторинг, резервное копирование и восстановление. Администратор может применять политики безопасности, репликации и ретеншена единообразно ко всему пулу данных.
Повышенная доступность
При выходе из строя одного из вычислительных узлов другие узлы продолжают работать с теми же данными без прерывания сервиса. Это особенно важно для кластерных приложений и виртуализированных сред, где виртуальные машины могут быть быстро перенесены на другой хост.
Гибкость и масштабируемость
Ресурсы хранения можно добавлять независимо от вычислительных мощностей. При росте объёма данных достаточно расширить хранилище, не затрагивая серверы приложений. Аналогично, при увеличении вычислительной нагрузки можно добавить новые узлы, которые сразу получат доступ ко всем данным.
Упрощённая миграция и балансировка нагрузки
Виртуальные машины, контейнеры или процессы могут перемещаться между физическими серверами без необходимости переноса данных. Это позволяет эффективно балансировать нагрузку, проводить техническое обслуживание и оптимизировать использование ресурсов.
Снижение рисков потери данных
Shared storage-системы обычно включают встроенные механизмы защиты: RAID-массивы, репликацию между узлами, журналы изменений, снапшоты. Эти функции обеспечивают сохранность данных даже при аппаратных сбоях.
Вызовы и ограничения
Сложность конфигурации и управления
Настройка shared storage требует глубокого понимания сетевых протоколов, файловых систем, механизмов блокировок и особенностей конкретных приложений. Неправильная конфигурация может привести к снижению производительности или даже к повреждению данных.
Зависимость от сети
Производительность shared storage напрямую зависит от пропускной способности и задержек сети. Узкое место в сети может стать узким местом всей системы. Поэтому для высоконагруженных решений часто используются выделенные сети хранения (Storage Area Network, SAN) с высокоскоростными интерфейсами, такими как 10/25/100 Gigabit Ethernet или Fibre Channel.
Проблемы согласованности при параллельном доступе
Когда несколько узлов одновременно читают и пишут в одни и те же данные, необходимо обеспечить согласованность. Это требует использования специализированных файловых систем, менеджеров блокировок или прикладной логики. Не все приложения корректно работают в shared storage-среде без модификаций.
Стоимость
Высокопроизводительные shared storage-решения, особенно на базе Fibre Channel или enterprise-класса NAS/SAN, могут быть дорогостоящими. Хотя существуют программные альтернативы (например, Ceph, GlusterFS, MinIO), их развёртывание и поддержка также требуют значительных усилий и экспертизы.
Технологии и реализации Shared Storage
Shared Storage Architecture может быть реализована с использованием различных технологий, каждая из которых подходит для определённых сценариев использования. Выбор конкретного решения зависит от требований к производительности, масштабируемости, отказоустойчивости, совместимости и стоимости.
Enterprise-хранилища (SAN/NAS)
Традиционные enterprise-решения, такие как Dell EMC PowerStore, NetApp FAS, HPE Nimble или IBM FlashSystem, предоставляют высоконадёжные, управляемые аппаратно-программные комплексы для организации shared storage. Эти системы обычно поддерживают как блочный (через Fibre Channel или iSCSI), так и файловый (через NFS/SMB) доступ. Они включают встроенные функции репликации, снапшотов, дедупликации, сжатия и автоматической оптимизации размещения данных.
Преимущества таких решений — стабильность, предсказуемая производительность, техническая поддержка и интеграция с корпоративными ИТ-инфраструктурами. Недостатки — высокая стоимость, зависимость от поставщика и сложность масштабирования за пределы возможностей конкретной модели.
Программно-определяемые хранилища (Software-Defined Storage, SDS)
SDS-платформы, такие как Ceph, GlusterFS, MinIO, OpenEBS или VMware vSAN, позволяют создавать shared storage на стандартном серверном оборудовании. Вместо специализированного контроллера используется программное обеспечение, которое объединяет локальные диски множества узлов в единый пул хранения. Такие решения гибко масштабируются: для увеличения ёмкости или пропускной способности достаточно добавить новый сервер в кластер.
Ceph, например, поддерживает все три типа доступа: блочный (RBD), файловый (CephFS) и объектный (RADOS Gateway). Это делает его универсальным решением для гетерогенных сред. MinIO, напротив, специализируется исключительно на объектном хранилище и совместим с Amazon S3 API, что упрощает интеграцию с облачными приложениями.
Программно-определяемые хранилища особенно популярны в средах виртуализации, контейнеризации и облачных платформах, где важна гибкость и автоматизация.
Облачные shared storage-сервисы
Облачные провайдеры предлагают собственные реализации shared storage:
- Amazon EFS — файловое хранилище, доступное с любого количества EC2-инстансов одновременно.
- Azure Files — файловые ресурсы, монтируемые по SMB или NFS.
- Google Cloud Filestore — высокопроизводительное NFS-хранилище.
- Amazon S3, Azure Blob Storage, Google Cloud Storage — объектные хранилища, доступные через API.
Эти сервисы полностью управляемы, масштабируются автоматически и оплачиваются по модели pay-as-you-go. Они идеально подходят для распределённых приложений, аналитических систем, медиа-платформ и резервного копирования.
Сценарии применения
Виртуализация и облачные среды
В инфраструктурах на базе VMware vSphere, Microsoft Hyper-V или KVM shared storage является основой для работы кластеров высокой доступности. Виртуальные машины хранятся на общем хранилище, что позволяет переносить их между физическими хостами без остановки (vMotion, Live Migration). При сбое одного из хостов виртуальные машины автоматически запускаются на другом, обеспечивая непрерывность работы.
Базы данных
Некоторые СУБД, такие как Oracle RAC (Real Application Clusters) или Microsoft SQL Server Failover Cluster Instances, требуют shared storage для обеспечения согласованного доступа к данным с нескольких узлов. Это позволяет строить отказоустойчивые конфигурации, где приложение продолжает работать даже при выходе из строя одного из серверов базы данных.
Совместная работа и медиа-обработка
В системах видеомонтажа, обработки изображений или CI/CD-конвейерах shared storage позволяет нескольким рабочим станциям или агентам одновременно читать исходные материалы и записывать результаты в общий каталог. Это устраняет необходимость в постоянной передаче файлов между узлами и ускоряет обработку.
Контейнерные платформы
В Kubernetes тома (Persistent Volumes) могут быть реализованы поверх shared storage, чтобы несколько подов имели доступ к одним и тем же данным. Это необходимо, например, для stateful-приложений, таких как базы данных, очереди сообщений или распределённые файловые системы внутри кластера.
Рекомендации по выбору архитектуры
При проектировании shared storage-инфраструктуры следует учитывать следующие факторы:
- Тип доступа: требуется ли блочный, файловый или объектный интерфейс? От этого зависит выбор протокола и технологии.
- Производительность: какие требования к IOPS, пропускной способности и задержкам? Для высоконагруженных систем предпочтительны SSD-диски и выделенные сети хранения.
- Масштабируемость: нужно ли горизонтальное масштабирование? Если да, то SDS-решения или облачные сервисы будут более гибкими.
- Совместимость: поддерживает ли целевая операционная система и приложения выбранный протокол?
- Бюджет: enterprise-оборудование дорого, но надёжно; SDS требует экспертизы, но экономит на железе; облако удобно, но может стать дорогим при длительном использовании.
Правильно спроектированная Shared Storage Architecture становится фундаментом для современной, гибкой и отказоустойчивой ИТ-инфраструктуры. Она устраняет привязку данных к конкретному серверу, упрощает управление и открывает возможности для автоматизации, балансировки нагрузки и бесперебойной работы критически важных сервисов.