Storage Box, объектное хранилище или HA-NAS: какую архитектуру выбрать?

Ящик для хранения, хранилище объектов и HA-NAS решают различные проблемы доступа. Storage Box – это простой удаленный объект для хранения файлов и резервных копий. Хранилище объектов предоставляет объекты через API и масштабируется по пространству имен, а не по смонтированной файловой системе. HA-NAS представляет общий доступ к файлам для серверов, которым требуется знакомая семантика файлов и высокая доступность.

Сравнение помогает командам выбирать хранилище резервных копий сервера, файловое хранилище, уровни мультимедиа, архивы и общие данные приложений, не объединяя каждую рабочую нагрузку в одной модели продукта.

Используйте хранилище для хранения и объектное хранилище в качестве рабочего процесса планирования: определите рабочую нагрузку, соберите нормальный и пиковый базовый уровень, определите первый ограничивающий ресурс, составьте список двух жизнеспособных проектов и протестируйте их с использованием производственных данных. Сохраняйте предположения видимыми, чтобы будущий обзор мог обновить модель без повторного открытия.

Коммерческие варианты, упомянутые в этом руководстве: storage box (https://unihost.com/storage-box/); HA-NAS (https://unihost.com/nas/); файловый хостинг (https://unihost.com/dedicated/hosting-for-files/)

Связаные статьи по Unihost: Хранилище Unihost как альтернатива AWS S3 (https://unihost.com/blog/unihost-object-storage-an-alternative-to-aws-s3/); контрольный список настройки резервного копирования (https://unihost.com/blog/backups-setup-checklist/); RAID руководство по выбору (https://unihost.com/blog/raid-made-simple-choose-level/)

Ящик для хранения, хранилище предметов и HA-NAS в практическом плане

Storage Box ведет себя как емкость удаленного файла, достигаемая посредством поддерживаемых протоколов передачи. Объектное хранилище организует данные в виде объектов в сегментах, и доступ к ним обычно осуществляется через S3-совместимый API. Хранилище HA-NAS предоставляет общие файлы одному или нескольким серверам через такие протоколы, как NFS или SMB/CIFS, в то время как платформа хранения обеспечивает доступность за конечной точкой.

Собирайте количество объектов, средний размер объектов, операции с каталогами, сочетание операций чтения и записи, параллелизм, задержку, пропускную способность и совместимость клиентов во время обычного трафика и во время характерного пика. Совместите временные метки инфраструктуры с трассировками приложений, чтобы команда могла связать медленный запрос или неудачное задание с ресурсом, который был ограничен. Средние значения полезны для планирования затрат, но p95, p99 и рост очереди показывают, наносят ли уже короткие всплески вреда службе.

Начните с того, как приложения читают и записывают данные, а затем выберите сервис, протокол и модель согласованности которого подходят без хрупкого уровня трансляции. Основной риск при планировании – выбор по стоимости за терабайт при игнорировании семантики приложений, требований к загрузке метаданных или восстановлению. Подтвердите свой выбор с помощью теста совместимости клиента с размерами рабочих файлов, разрешениями и параллелизмом. Сохраните условия тестирования и порог приемлемости в модуле Runbook, чтобы последующие изменения можно было проверить по тому же базовому состоянию.

Полезное решение имеет масштабный путь. Укажите, что можно расширить на месте, что требует перезапуска или миграции и какой порог запускает эту работу. Время выполнения закупок, продолжительность копирования данных и окна изменений относятся к планированию мощности, поскольку ресурс, который может быть добавлен в следующем месяце, может не помочь во время пика на следующей неделе.

Ящик для хранения, хранилище объектов и сравнительная таблица HA-NAS

Категории ниже представляют собой архитектурные тенденции. Конкретная реализация может добавлять управление версиями, моментальные снимки, частную сеть или репликацию, поэтому подтвердите объем продукта. Подбор протокола обычно сужает выбор быстрее, чем необработанная емкость: устаревшим файловым приложениям требуется файловая система, а облачные сервисы часто интегрируются напрямую с объектными API.

Создайте базовый уровень на основе поддерживаемого протокола, поведения пространства имен, распределения задержек, ограничений масштабирования, избыточности, контроля доступа и модели оплаты. Записывайте одни и те же сигналы до и после каждой настройки или изменения инфраструктуры. Если пропускная способность возрастает, а задержка и ошибки остаются под контролем, это изменение создает полезную емкость. Если очереди растут или задержка увеличивается, значит, система достигла предела, даже если один из основных показателей использования все еще выглядит удовлетворительным.

Исключите любой вариант, который требует, чтобы приложение действовало в соответствии со своей собственной моделью данных, а затем сравните надежность и стоимость оставшихся вариантов. Следите за тем, чтобы предположить, что NAS и объектное хранилище – это всего лишь сравнение производительности. Перед заказом или миграцией используйте доказательство концепции, охватывающее операции создания, составления списка, переименования, перезаписи, удаления, хранения и восстановления. Документированный критерий отклонения так же важен, как и критерий успеха, поскольку он сообщает команде, когда следует остановить развертывание или перейти на следующий уровень мощности.

Стоимость должна быть привязана к единице успешной работы, такой как заказ, запрос, завершенное задание, восстановленный терабайт или принятый ответ модели. Такое представление не позволяет дешевой конфигурации выиграть, когда она не достигает целевого показателя задержки или восстановления, а также не позволяет рассматривать неиспользованный запас мощности как бесплатный.

Сравнение архитектуры хранилища

Сравните Storage Box (https://unihost.com/storage-box/), шаблоны хранения объектов и HA-NAS (https://unihost.com/nas/).

Лучший вариант для резервных копий, носителей, архивов, баз данных и общих файлов.

Резервные копии требуют неизменяемости или сохранения версий, независимых учетных данных и предсказуемого восстановления. Медиа и архивы ценят емкость, параллельное чтение и политику жизненного цикла. Для общих файлов требуются разрешения и семантика файловой системы. Большинству транзакционных баз данных следует хранить активные данные в локальном или выделенном хранилище с низкой задержкой и использовать удаленное хранилище для резервного копирования, экспорта или определенных общих ролей. Сервер хранения резервных копий отдает приоритет пропускной способности восстановления и изоляции, тогда как хостинг медиахранилищ отдает приоритет шаблонам доставки и политике жизненного цикла. Хранилищу базы данных требуется постоянная задержка, четкий контроль долговечности и путь резервного копирования с учетом приложений.

Используйте время восстановления, срок хранения, размер объекта, частоту доступа, скорость метаданных, базу данных IOPS и поведение блокировки файлов в качестве модели небольшой емкости, а не снимка информационной панели. Разделите устойчивый спрос, плановую работу и исключительные пики. Модель должна объяснять, какой ресурс насыщается первым, как долго длится это насыщение и какой клиентский или операционный результат меняется в этот момент.

Используйте Storage Box для прямых удаленных копий, объектное хранилище для API-родного масштабирования и распространения и HA-NAS когда нескольким серверам требуется общая файловая система. Проект по-прежнему может дать сбой из-за размещения чувствительных к задержке файлов базы данных в удаленном хранилище без поддержки поставщика и тестирования рабочей нагрузки. Подтвердите предполагаемое поведение с помощью восстановления по времени, теста доставки носителя или теста согласованности приложения, соответствующего выбранному варианту использования. Включите в тест мониторинг, резервное копирование и средства контроля безопасности, поскольку производственные издержки не должны появляться в первый раз после запуска.

Выберите Storage Box, HA-NAS или файловый хостинг.

Вопросы доступности, шифрования и восстановления

Доступность – это больше, чем резервные диски. Проверьте резервирование контроллера и сети, поведение при обслуживании, логику повторных попыток клиента, снимки или версии, шифрование хранящихся и передаваемых данных, изоляцию учетных данных и процесс восстановления удаленных или поврежденных данных. Репликация может скопировать ошибку, поэтому создайте независимую точку восстановления.

Измеряйте доступность службы, частоту повторных попыток, возраст моментальных снимков, точку восстановления, время восстановления, ротацию ключей и события неудачного доступа с достаточным разрешением для захвата всплесков и достаточной продолжительностью для выявления утечек, эффектов кэша и фоновых заданий. Держите структуру рабочей нагрузки видимой. Тест, в котором преобладают простые запросы, может показать хорошие средние значения, в то время как дорогостоящий путь уже стоит в очереди.

Прежде чем выбирать уровень продукта, сопоставьте каждый класс данных с RPO, RTO политикой хранения и доступа. Не игнорируйте обработку RAID или синхронизированных реплик в качестве резервной копии. Подтвердите рекомендацию с помощью тренировки по восстановлению, которая удаляет, повреждает и восстанавливает репрезентативные данные в документированные сроки. Запишите, какое предположение имеет наименьшую достоверность, и сначала повторно проверьте это предположение при изменении трафика, данных или программного обеспечения.

Три эталонные архитектуры хранения данных

При резервном копировании зашифрованные копии сервера отправляются в Storage Box и при необходимости сохраняется отдельная копия, контролируемая политикой. Медиа-дизайн хранит метаданные приложения в базе данных, в то время как объекты находятся в хранилище объектов и доставляются через кэш или CDN. Многосерверное приложение может монтировать HA-NAS через частную сеть для общих файлов, сохраняя при этом независимые резервные копии.

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

Сохраняйте «горячий путь» простым и размещайте потоки резервного копирования или архивирования за пределами одного домена сбоя. Самой дорогостоящей ошибкой была бы маршрутизация всех типов данных через одну общую конечную точку и превращение хранилища в универсальное узкое место. Уменьшите эту неопределенность с помощью анализа диаграммы, за которым следуют пиковые нагрузки и тесты на отказ компонентов. Сохраняйте путь обновления или отката, который не зависит от уже ограниченного компонента.

Эталонные архитектуры

Контрольный список решений по хранению и следующий шаг

Протокол доступа к документу, размеры объектов и файлов, параллелизм, необходимое местоположение, частное подключение, разрешения, шифрование, рост, хранение, RPO/RTO, метод восстановления и ежемесячная передача. Спросите, как служба ведет себя во время обслуживания, расширения емкости и случайного удаления. Оставьте второй вариант, если приложение может поддерживать более одной модели данных.

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

Запрашивайте рекомендации по архитектуре только после того, как будут определены требования к приложению и восстановлению. Распространенной причиной отказа является заказ хранилища до того, как команда согласует, какие данные являются достоверными и как они будут восстановлены. Используйте подписанное приемочное тестирование производительности, контроля доступа и восстановления, прежде чем считать конфигурацию готовой к эксплуатации. Обсудите результат с владельцем приложения, а также с командой инфраструктуры.

Запросите рекомендацию по архитектуре хранилища

Часто задаваемые вопросы

NAS лучше объектного хранилища?

Ни то, ни другое не лучше в целом. NAS подходит для приложений, которым требуется смонтированная общая файловая система, привычные разрешения и файловые операции. Объектное хранилище подходит для API-родных приложений, больших пространств имен и параллельного доступа к объектам. Выбирайте по семантике доступа и конструкции восстановления.

Какое хранилище лучше всего подходит для резервных копий?

Используйте хранилище, которое не зависит от источника, поддерживает необходимое хранение и может быть восстановлено в пределах RTO. Storage Box может быть прямой удаленной целью, а объектное хранилище может добавлять элементы управления версиями или жизненным циклом. Проверьте скорость восстановления и изоляцию учетных данных.

Можно ли использовать Storage Box для медиафайлов?

Да, если поддерживаемый шаблон передачи и доступа соответствует рабочему процессу. Для массовой публичной доставки объектное хранилище плюс CDN может масштабироваться более естественно. Измеряйте параллелизм, пропускную способность и то, как приложение сопоставляет URL-адреса или разрешения к хранимым файлам.

Какое хранилище подходит для баз данных?

Для активных транзакционных баз данных обычно требуется локальная NVMe с малой задержкой или специально созданная общая платформа, протестированная для этой базы данных. HA-NAS может подойти для поддерживаемых случаев использования общих файлов, тогда как Storage Box или объектное хранилище лучше использовать для резервного копирования и экспорта. Перед началом производства проверьте согласованность и задержку.