Подписаться
Читать в телеграм
Проблемы традиционных хранилищ данных.
Когда нужно переходить на объектное решение?
Подводные камни в эксплуатации S3 и как на них не напороться?
Кто-то только раздумывает о применении объектных хранилищ в своей инфраструктуре, а кто-то уже 10 лет их эксплуатирует. Постараемся помочь разобраться с темой первым и рассказать что-то новое вторым.
Объектное хранение значительно отличается от общепринятого блочного и файлового доступа, концептуально оно больше похоже на базу данных. Объект — это файл и набор его метаданных (например, скан документа, который сопровождается информацией о его версии, владельце, уникальном номере, времени и месте создания и др.). Для скачивания объекта необходимо найти его по этим данным (по сути «Select» в БД) или полному адресу его местоположения.
Объектные протоколы доступа к данным необходимы для организации больших хранилищ на миллиарды файлов (в основном крупных изображений — медицинских сканов, электронных документов и др.) с возможностью оперативного поиска. В большинстве решений предполагается географически распределенный доступ к файлам с возможностью хранения множества их копий (для отказоустойчивости и локализации доступа).
ЧЕК-ЛИСТ
Проблемы традиционных файловых хранилищ
- Нет полноценных средств индексации и поиска содержимого.
- Фиксированная конфигурация метаданных для разных типов файлов.
- Листинг директорий с тысячами файлов выполняется с большими задержками.
- В случае аварийного завершения работы проверка целостности (fscheck) может затянуться на многие часы.
- Есть сложности с гранулярной межсайтовой репликацией и геораспределенным доступом.
- Сильный рост конфигурации по объемам и производительности зачастую требует смены архитектуры решения.
Для решения этих задач и был создан отдельный класс хранилищ. Да, объектные решения работают медленнее и с бо́льшими задержками, чем системы с блочным протоколом. У них меньшая гранулярность настроек прав доступа, пользовательских квот и правил совместной работы с файлами, чем у решений с файловым доступом. Но у объектных хранилищ есть свои плюсы: настраиваемые метаданные объектов и поиск по ним, доступ из любой точки мира, миллиарды крупных файлов в плоской неиерархической структуре хранения1Папки, видимые в браузерах объектных хранилищ, в большинстве случаев просто часть адреса (или, если точнее, часть имени объекта). Их нельзя сравнивать с папками в традиционных файловых системах.. Заменить их другими решениями практически невозможно.
В настоящий момент наиболее распространены объектные протоколы Swift и Amazon S3. При этом доля решений с применением протокола Amazon S3 несравнимо больше, и чаще всего, когда обсуждается объектное хранение, подразумевается именно он.
Тренд на объектные хранилища
За последние 5 лет интерес к объектным хранилищам растет в контексте не только облачных сервисов, но и классической on-premise-инфраструктуры. Популярность этих решений подогревается стремительным ростом количества неструктурированных данных: по оценкам консалтинговых агентств, динамика — не менее +80% в год. Сегодня необходимо не только хранить множество сообщений, электронных документов, сканов, фотографий и аудиофайлов, но и обеспечивать их поиск, выборку, а также доступ к ним из разных приложений. Повышаются требования к срокам хранения, разрабатываются внутренние регламенты, появляются требования регуляторов. Например, банки должны хранить персональные данные клиента не менее 5 лет с момента прекращения отношений с ним. Предполагается, что в ближайшие два года в России будет принят ряд законов по упорядочиванию работы с электронными документами, которые коснутся не только госструктур, но и коммерческих компаний. Например, новые меры повлияют на обработку кадровых документов, на налоговый и бухгалтерский учет.
Другая причина популярности объектных хранилищ — ускорение процесса создания приложений. Объектный доступ упрощает задачу разработчикам: им больше не нужно задумываться о файловой системе и организации хранения — работай себе с СХД простыми PUT/GET-запросами через API поверх стандартного HTTPS. А использование REST API позволяет автоматизировать работу с хранилищем.
Наши клиенты используют объектные хранилища для решения разных задач — от классических (хранение эталонных версий электронных документов и почтовых архивов) до отраслевых (хранение геологоразведочных данных). Кроме того, протокол S3 активно используется в контейнерных средах и в инфраструктуре 3.0 в целом.
Как выбрать подходящее решение
При выборе решения нужно учитывать особенности архитектуры ИС, необходимую производительность (для расчета используются средние размеры объекта и частота чтения и записи объектов в секунду), возможности балансировки доступа, мониторинга и резервного копирования. Также на стоимость решения в целом может повлиять выбор конкретной модели объектного хранилища. Например, не нужно разрабатывать биллинг ресурсов объектной СХД, можно не покупать лицензии на внешние балансировщики трафика. Можно взять стандартные серверы, закупить их по рамочному договору лизинга вместо покупки специализированных ПАК или использовать в виде корпоративного файлообменного ресурса (а-ля DropBox) и т.д. Кроме того, следует помнить о сложностях сайзинга Open Source и необходимости последующего обучения службы поддержки.
Чтобы первый блин не вышел комом, нужно сразу наладить взаимодействие разработчиков ПО и команды, отвечающей за инфраструктуру. У распределенного объектного хранилища, которое будет работать в корпоративном частном облаке, и архи вного одноузлового хранилища общим будет только протокол S3. При этом большинство объектных хранилищ не могут выполнить все операции, доступные в S3 API, поэтому следует проверять конечное решение на совместимость с вашим ПО.
НА ЗАМЕТКУ
Если вам нужно S3-хранилище для Enterprise СРК или распространенного решения архивации, в большинстве случаев взаимодействие с ним будет максимально простым. Когда при внедрении новой ИС к вам приходит архитектор со словами «Нам нужно продуктивное S3-хранилище», необходимо детально обсудить множество вопросов. Лучше сделать это в ходе пилота, когда решение собирают «из того что было». В 99% случаев разработчики будут использовать решения с открытым кодом Minio или Community редакции Ceph, очень редко — ресурсы облачного провайдера. Но как только ИС начинают готовить к работе в продуктиве, возникает масса вопросов по стабильности работы под нагрузкой и при аппаратных сбоях, интеграции с доменом, балансировке трафика, ограничениях доступа и т.д. В итоге сроки ввода в эксплуатацию срываются: приложения нужно дорабатывать, стоимость проекта растет.
В большинстве случаев вы сможете протестировать понравившееся решение. Не рассчитывайте на то, что вам в ЦОД привезут готовый ПАК на 1 ПБ и десяток узлов. Однако производители дают возможность провести удаленные испытания в специализированных центрах. Можно запустить объектную СХД на виртуальных машинах: обычно архитектура решения включает узлы управления и мониторинга, балансировки трафика (внутренние или внешние), клиентского доступа, хранения данных и обработки метаданных. При этом в рамках пилота возможно значительное сокращение числа и типа узлов — для некоторых систем достаточно одной виртуальной машины.
НА ЗАМЕТКУ
Современные объектные хранилища не только подходят для хранения архивов, но и могут обеспечить высокую производительность доступа. Если есть разноплановая нагрузка, лучше консолидировать ее в одном хранилище, организовав многоуровневое хранение с использованием политик жизненного цикла хранения данных. Нагрузка на объектные системы обычно прогнозируется лучше, чем на блочные (чаще всего запрашиваются свежезаписанные объекты), поэтому для ответственных продуктивных сред подойдет такая политика: наиболее востребованные объекты хранятся в двух копиях на узлах с flash-носителями. Если в течение трех месяцев к ним не будет запросов, они перемещаются на сайт с медленными дисками, а еще через полгода отправляются на ленточные картриджи. Если важнее производительность, используйте защиту данных с помощью дублирования объектов между площадками и/или узлами. Также повысить производительность поможет использование аппаратных RAID-контроллеров для защиты от выхода из строя отдельного диска. Если стоимость хранения важнее, то на крупных объектах используйте избыточное кодирование с распределением блоков с данными и четностью по разным узлам.
Не стоит забывать, что для любых многоузловых хранилищ необходим полноценный внешний балансировщик трафика. Правильно настроенных DNS-записей недостаточно для равномерной отказоустойчивой работы. Кроме того, далеко не у всех решений есть удобный встроенный мониторинг производительности. А отдельное внимание нужно уделить функционалу резервного копирования — это критично, если вы храните продуктивные данные.
системный архитектор отдела комплексных проектов компании «Инфосистемы Джет»
Исторически в банке использовались несколько решений для хранения файлов и их автоматизированной обработки. Где-то данные хранились на файловых серверах, где-то — на специально выделенных ВМ с NAS-каталогами. Такой «зоопарк» усложнял процесс администрирования и приводил к частым инцидентам. Мы посоветовали руководству банка выделить класс объектного хранения в отдельную инфраструктурную информационную систему и реализовать ее на базе NetApp StorageGrid Webscale.
Сначала мы развернули в имеющейся ИТ-инфраструктуре минимальную инсталляцию на базе виртуальных машин — для демонстрации и тестирования технологии. Решение удовлетворило заказчика, и система была переведена в продуктив. Сейчас банк перешел на аппаратную конфигурацию объектного хранилища. Миграция данных при этом не потребуется — достаточно инсталлировать аппаратные узлы и добавить их в существующий кластер. Ребалансировка пройдет в фоновом режиме, пользователи не заметят изменений. Ждем завершения проекта.
Сложности с обеспечением доступности. — Новое объектное хранилище собрано в единый кластер сразу в 3 ЦОДах. Высокая стоимость хранения. — С помощью политик жизненного цикла устаревшие данные автоматически удаляются, а мало используемые перемещаются на более дешевые «слои» хранения. Трудности с масштабированием. — Объектное хранилище легко наращивается дополнительными узлами, данные автоматически балансируются, почти линейно растут производительность и емкость. Трудоемкость администрирования и поддержки. — Вместо нескольких разных мест с файловым доступом организовано единое хранилище, управляемое из единой консоли и поддерживаемое одним партнером.
Подводные скалы
После успешного внедрения наступают суровые будни эксплуатации, во время которых можно, как при отливе, напороться на подводные скалы. После этого могут потребоваться спешный ремонт или полная замена решения.
У всех коммерческих решений есть особенности, о которых тяжело узнать «с улицы». И совсем не факт, что об этих нюансах расскажет вендор (пресейл-специалисты могут ничего не знать). Например, у одного решения есть особенность: чем больше узлов хранения, тем с большей задержкой будет обрабатываться каждый запрос. А у другого стоит ограничение в 250 сессий на удин узел доступа. Поделюсь с вами несколькими историями наших заказчиков.
Все дело в опыте
Заказчик планировал вводить в промышленную эксплуатацию объектную СХД, которая прошла внутренние испытания. По нашей рекомендации специалисты компании провели дополнительный тест: вынули диск хранения для имитации аппаратного сбоя. В результате производительность СХД упала в несколько раз, а при попытке снизить влияние задач восстановления на работу системы она окончательно вышла из строя. Ремонт длился более 24 часов. После этого заказчик отменил ввод решения в продуктив и отправил проект на пересмотр. Не хотели говорить кто, но это был слоненок Ceph.
Интересная особенность
Банк столкнулся с проблемой: после размещения в объектной СХД более 10 млн объектов в корне одного bucket и попытки их массового удаления производительность решения сильно упала. В ходе расследования инцидента и общения с вендорской поддержкой выяснилась интересная особенность, зарытая в рекомендациях по использованию API: производитель не рекомендует хранить более 100 000 объектов в рамках одной «папки».
Высокая нагрузка
Заказчик все хорошо рассчитал: внедрение и первые месяцы эксплуатации прошли отлично. Однако скорость появления новых объектов в объектной СХД в несколько раз превысила плановую. Система начала приближаться к рекомендованным пороговым значениям — 750 млн объектов на узел хранения (всего узлов было 9). Но проблем все же удалось избежать: по нашей рекомендации специалисты заказчика оперативно развернули несколько дополнительных узлов хранения на виртуальных машинах и провели балансировку без остановки доступа. Затем в плановом порядке закупили новые узлы с учетом текущих требований.
системный архитектор отдела комплексных проектов компании «Инфосистемы Джет»
У заказчика есть огромная информационная система (около 5 млрд объектов и 600 Тб данных), спроектированная под хранилище S3, которое изначально было реализовано на базе Open Source ПО Ceph и предоставлялось заказчику по IaaS-модели. В нем содержались неструктурированные данные: документы, фото, сканы, видео. Однажды произошел серьезный инцидент, который привел к полной недоступности системы в течение 60 с лишним часов. Новые данные перестали записываться, специалисты провайдера не могли решить проблему, а обратиться было некуда. В итоге аварию устранили путем создания нового кластера, в котором начали размещать новые данные. Но в ходе ближайшей модернизации было решено заменить систему. Заказчику требовалось надежное решение, которое не упадет под большой нагрузкой и сможет вместить порядка 5 млрд объектов с перспективой роста. Работающее в двух ЦОДах и поддерживающее межсайтовую репликацию, с сервисом и SLA от производителя.
Мы развернули решение в виде двух независимых аппаратных инсталляций — в основном и резервном ЦОДах провайдера. Синхронизация данных между хранилищами выполнялась средствами информационной системы. При этом заказчик развернул в собственном ЦОДе отдельное решение S3 на базе Scality RING, куда периодически копирует данные из облака. Миграция с кластера Ceph была выполнена в рекордные сроки: за 2 месяца мы перенесли в новую систему 5 млрд объектов. В итоге заказчик получил современную горизонтально масштабируемую систему. Так, когда данных стало слишком много, мы просто установили дополнительные узлы: решение расширяется без простоев и необходимости миграции.
Чек-лист
Признаки того, что вам необходимо объектное хранение
- Миллионы и миллиарды файлов преимущественно более 512 KB
- Географически распределенный доступ к одним и тем же данным
- Настраиваемый оперативный поиск файлов по метаданным
- Взаимодействие приложений с хранимыми файлами
- Простое управление локализацией файлов и количеством копий
- ИС, работающая с данными, имеет архитектуру гибридного облака
- Простое масштабирование размеров, числа файлов и скорости доступа без изменения архитектуры
По отдельности эти задачи можно успешно решить традиционными системами, но как только их становится много, лучше обратить внимание на объектные хранилища.
