Приходят к нам нотариусы (в штате больше восьми тысяч человек). У них буквально каждый пользователь ежедневно грузит в корпоративный архив множество сканов и файлов, из-за чего этот самый архив стремительно разрастается. Все хранимые документы по требованиям регуляторов должны храниться не менее 50 лет, а некоторые — и дольше. Хотят новое хранилище для этого. Вводных совсем мало: для старта нужны два маленьких инстанса по 500 ТБ в двух разных ЦОДах и безлимитное масштабирование — в общем, всё выглядит хорошо. Вопрос только один: какое, собственно, хранилище выбрать?
Нам нужно было решить, что же им подойдёт лучше всего, то есть провести подбор решений и сравнить их. Начали мы с методологии — очень подробно собрали требования:
- Масштабируемое неограниченно (главная особенность — количество «холодных» данных будет постоянно нелинейно расти).
- Нечувствительное к потере частей, то есть катастрофоустойчивое и устойчивое к поломкам. Почти как хранилище на космический корабль.
- Способность экономически оправданно эволюционировать вместе с частями информационной системы, то есть в идеале — замена железа и обновление софта, а не переход к другим архитектурам и переносы в другие форматы хранения.
- Единообразный доступ к данным независимо от платформы исполнения.
Текущая инфраструктура развёрнута на двух площадках на расстоянии 10 км друг от друга. Стоят по две ленточные библиотеки, два драйва LTO 7, хранилище Oracle ZFS-2, дисковая полка. Дисковые хранилища используются для работы БД, ленточные хранилища — для хранения резервных копий. Для уменьшения объёмов БД необходимо редко запрашиваемые данные перемещать на более дешёвые и медленные устройства хранения с возможностью автоматического извлечения с доступом по API. Плюс централизованное управление конфигами и мониторинг.
В общем, пришлось немного почесать голову. Но выбор мы сделали, и сейчас это всё уже переходит в продакшн. Так что заходите в пост, обстоятельно расскажу, что и как.
Шаг 1: требования к системе
Первое, что нужно сделать, — это сформировать техзадание на хранилище. У заказчика его на самом деле нет, потому что они не знают финального состояния системы, которая будет эволюционировать десятилетиями. Мы тоже не знаем, но нам нужно получить хоть какой-то план, чтобы потом закладывать варианты отклонений от него.
До того как они решили делать объектное хранилище, они шли в сторону классического хранения на базе Oracle. Но в процессе стало понятно, что данные растут быстрее, чем это может обеспечить существующая система. В начале работ мы поехали на аудит площадки, и выяснилось, что они в целом не планируют идти дальше таким путём и подходы нужно менять.
Анамнез осложняется ПО собственной разработки, которое пишет сейчас в базу данных. Главный вопрос был в том, по каким протоколам с ним работать в будущем. К счастью, когда разработчики услышали знакомую фразу «S3», выбор быстро был сделан. Оставалось только выбрать зарекомендованное вендорское решение и оставить на первое время возможность переносить данные по стандартным файловым протоколам CIFS/NFS.
В результате были составлены довольно подробные требования для сравнения решений на рынке и выбора нужного варианта. Перечень приводить не буду, но интересующиеся могут запросить отдельно по почте в подписи.
Шаг 2: подбор вариантов реализаций на базе доступных на рынке вендоров с поддержкой
Сразу было поставлено условие, что система должна довольно долго поддерживаться и развиваться, поэтому нужно рассматривать только зарекомендованные и проверенные годами вендорские решения от крупных компаний, существующие не первый год и обладающие качественной техподдержкой. В связи с этим были выбраны три основных решения, существующие на рынке.
Первый вариант (от вендора А) — платформа для распределённого хранилища контента.
Она может быть разделена на множество виртуальных логических разделов (tenants), каждый из которых будет иметь свои пространства имён, хранить свои группы объектов со своими политиками хранения. Доступ к каждому такому разделу и объектам, так же как и управление ими, может осуществляться независимо.
Каждый хранящийся в системе файл представляет собой объект. Помимо самих данных, в системе хранятся различные метаданные — как системные, например, время создания, размер и срок хранения, так и пользовательские, которые могут формироваться пользователями или приложениями, оперирующими этим объектом. Подлинность хранящихся данных гарантируется специальными алгоритмами: при записи объекта в систему происходит расчёт хэш-функции этого объекта, после чего эта информация записывается в метаданные. Каждый раз при обращении происходит сверка хэш-функций. Механизм расчёта хэш-функций может быть сконфигурирован исходя из требований предприятия к стандартам шифрования.
Диски объединены в массив RAID-6 для сохранности данных при выходе из строя любых двух дисков в группе. Дополнительно для целостности информации и защиты от катастроф проводится периодический аудит хранящихся объектов и используются технологии репликации на уровне объектов через глобальную сеть. Срок хранения данных задаётся специальными политиками, которые позволяют определить критерии для сроков доступности объектов. Политики могут формироваться приложениями или пользователями, например, можно установить, что файлы определённого типа должны храниться определённый ограниченный период времени.
Система обеспечивает хранение нескольких версий одного и того же объекта, что, например, позволяет отслеживать весь жизненный цикл документа. Механизмы NENR (невозможность перезаписи и удаления) и WORM (одна запись, многократное чтение), которые можно задействовать, способны гарантировать неизменяемость объектов. Это важно для хранения информации, подлежащей нормативному регулированию.
Решение частично соответствует требованиям заказчика. Оно строится отказоустойчиво с дублированием данных и возможностью их последующей репликации, позволяет автоматически перемещать объекты внутри и вне системы в зависимости от частоты обращения к ним, а также обладает продвинутыми механизмами сжатия и дедупликации. Предполагает полноценный доступ по HTTP/REST API и обладает нужной масштабируемостью.
Но система не предусматривает подключения существующих библиотек в качестве архивного уровня хранения. Часть требований может быть выполнена только при использовании дополнительного ПО.
Второй вариант — объектное хранилище NetApp StorageGrid:
- Обеспечивает непрерывный доступ к данным в любое время.
- Устраняет физические границы хранения и поддерживает большие объёмы данных.
- Упрощает аварийное восстановление независимо от физического расположения.
- Поддерживает хранение данных в облаке.
- Поддерживает протоколы S3, Swift RESTful API, NFS, CIFS, HTTP/HTTPS.
Очень упрощая, весь сторедж грид — это в самом начале три сервака (или виртуалки) с подключёнными дисками, которые объединены в единую объектную СХД. И все данные размазаны между этими тремя узлами. Любой из этих трёх узлов может страдать, в них могут вылететь любые диски, но данные сохранятся. Может вылететь узел целиком, и всё продолжит работать.
SG использует четыре типа нод: Admin Node обеспечивает управление сервисами, например, системная конфигурация, мониторинг и логгирование, распределение трафика по Storage Node. Storage Node управляет объектным хранением и хранит метаданные, обеспечивая отказоустойчивость данных. API Gateway Node (опционально) выполняет роль балансировщика между разными приложениями и нодами хранения данных, разгружая админ-ноды. Archive Nodes (опционально) обеспечивает архивацию данных на ленты. NAS Bridge — виртуальная машина, которая позволяет использовать NFS/SMB-шары и конвертирует запросы в S3 API.
Возможно расположение на одной или на нескольких геораспределённых площадках.
Управление данными обеспечивается с помощью политик жизненного цикла (ILM, Information lifecycle management). Каждый объект, который попадает в систему SG, проверяется в соответствии с правилами и активной политикой ILM. Правила ILM по метаданным объекта определяют, какие действия предпринять при их хранении и копировании.
ILM-правило определяет расположение объекта, тип используемого хранилища, тип защиты от потери, применяемый к объекту (репликация или erasure coding), количество сделанных копий, изменения со временем расположения, хранения и защиты от потери.
Репликация — один из двух механизмов, используемых решением для хранения объектных данных. Когда оно с помощью ILM-правила определяет, что объект необходимо реплицировать, система создаёт копию объекта и сохраняет её на другую Storage Node.
Возможна репликация как на одной площадке на разные ноды в едином пуле, так и на разные площадки на разные ноды. Распределение по разным площадкам повышает катастрофоустойчивость.
Erasure coding — это ещё один способ хранения данных, альтернатива обычным копиям. Когда поступает объект, с помощью ILM-политики определяется, на сколько фрагментов он будет разделён, рассчитываются дополнительные парити-фрагменты и сохраняются на разные ноды. Когда происходит обращение к этому объекту, он собирается из фрагментов обратно.
Если фрагмент данных или парити будет испорчен или потерян, то алгоритм erasure-coding восстановит недостающий фрагмент и восстановит целостность данных. Принцип работы похож на RAID из дисков.
На рисунке показан пример работы алгоритма. На этом примере ILM-правило использует 6+3 erasure coding-схему. Каждый объект делится на шесть одинаковых фрагментов, и три парити-фрагмента вычисляются из данных. Каждый из девяти фрагментов сохраняется на разных нодах и даже разных площадках, что позволяет защититься от выхода из строя ноды или площадки целиком.
На данном примере может быть потеря до трёх фрагментов без потери данных.
Решение полностью соответствует всем требованиям в техническом задании. Система хранения на его основе высокодоступна и производительна, с простой настройкой, встроенным мониторингом, гибкой настройкой политик под сроки хранения и расположение файлов, репликацией и доступом по API.
Помимо этого, для заказчика обнаружились критически важные вещи:
- Синхронная репликация между площадками даже при задержках, которые накладывают шифровальщики.
- Возможность задублировать каждый компонент именно железом (ноду управления, свитчи, диски, всё что можно).
Третий вариант (от вендора С) — универсальная объектная платформа хранения данных. Решение можно использовать по одной из нескольких моделей: как программно-определяемую систему или как готовое устройство. Оно позволяет хранить неструктурированные данные и управлять ими с минимальными затратами в любых масштабах и в течение любого периода времени.
Есть поддержка нескольких протоколов — одна система хранения с поддержкой всех объектных протоколов (S3, CAS, Atmos, OpenStack и т. п.). Есть встроенная поддержка файлов — встроенная поддержка HDFS и NFS без необходимости использовать шлюзы. Управление метаданными — поддержка расширенных метаданных, индексирования и аналитики с помощью встроенного механизма поиска и управления метаданными. Плюс высокая эффективность системы хранения: благодаря использованию алгоритма распространения информации повышается эффективность системы хранения, и появляется возможность подключения большего количества площадок.
Архитектура решения состоит из нескольких основных компонентов:
- Основанный на API web-интерфейс и CLI для автоматизации, отчётности и управления нодами ECS. Этот уровень также позволяет выполнять операции, связанные с лицензированием, аутентификацией, предоставлением ресурсов и созданием пространства имён.
- Cервисы, инструменты и API для доступа к объектам и файлам в системе.
- Основной сервис, отвечающий за хранение и извлечение данных, управление транзакциями, защиту и репликацию данных локально и между сайтами.
- Служба кластеризации для управления работоспособностью, конфигурацией, обновлением и оповещениями.
- ОС, SLES 12 или другие поддерживаемые.
- Appliance или другое сертифицированное оборудование.
С точки зрения клиента схема взаимодействия выглядит следующим образом:
- Запрос на чтение объекта отправляется от клиента к ноде 1.
- Нода 1 использует хэш-функцию, используя имя объекта, чтобы определить, какой узел является владельцем раздела логической таблицы, в которой находится информация об этом объекте. В этом примере нода 2 является владельцем, и таким образом она выполнит поиск в логических таблицах, чтобы определить местоположение фрагмента. В некоторых случаях поиск может происходить на двух разных узлах, например, когда местоположение не кэшируется в логических таблицах ноды 2.
- На предыдущем шаге местоположение чанка предоставляется ноде 1, которая затем отправит запрос чтения смещения байтов узлу, который содержит данные, в этом примере — ноде 3, и отправит данные ноде 1.
- Нода 1 отправляет данные запрашивающему клиенту.
Решение частично соответствует требованиям ТЗ, платформа обладает достаточной отказоустойчивостью и гибкостью. Использует программно-определяемую архитектуру, и за счёт этого вычислительные ресурсы и ресурсы хранения гибко масштабируются. Все данные в ECS контейнеризированы; нет аппаратной зависимости, необходимости перекодировать или перенастраивать приложения, поскольку ECS обеспечивает поддержку нескольких протоколов.
Дальше мы показываем таблицу заказчику и предлагаем выбор:
NetApp StorageGrid:
- Мультипротокольный доступ к системе.
- Отказоустойчивое решение (erasure decoding).
- Полная поддержка Amazon S3 API.
- Автоматическое определение типа данных по их метаданным.
- Поддержка ленточных библиотек.
- Синхронная запись данных на две площадки.
- Дедупликация.
- Возможности масштабирования наращиванием объёмов (только полками в 6000-йсерии).
- Возможность увеличения производительности (SSD pool).
- 4 x 25 GBs-порта для клиентского трафика и репликации.
Но часть функционала возможна только при использовании дополнительных виртуалок.
Вендор А:
- Расширенный набор протоколов для доступа к системе.
- Отказоустойчивое решение.
- Встроенная поддержка HDFS и NFS.
- Поддержка расширенных метаданных.
- Поддержка нескольких namespace (=tenant).
Но отсутствуют возможности использования ленточных библиотек; часть критичного функционала (HA-режим, отказоустойчивость NFS) доступна только при использовании балансировщиков нагрузки.
Вендор С:
- Мультипротокольный доступ к системе.
- Отказоустойчивое решение.
- Продвинутые механизмы компрессии и дедупликации.
- Механизмы NENR (невозможность перезаписи и удаления) и WORM (однократная запись — многократное чтение).
Но часть функционала возможна только при использовании специализированного ПО, что влечёт дополнительные финансовые издержки; отсутствуют возможности использования ленточных библиотек. А также отсутствие синхронной репликации данных между площадками.
NetApp StorageGRID собрал все плюсы по требованиям заказчика. Особенность выбора ещё в том, что мы не топили ни за какого вендора (что стало шоком для клиентов, потому что они привыкли, что ИТ-компании и интеграторы всегда стараются продать какое-то конкретное решение).
В итоге заказчик решает, что если строить систему на века, то лучше взять то, где больше соответствия цели. И останавливается на Гриде.
Шаг 3: ещё больше деталей
На самом деле для каждого решения оценивалась архитектура куда более детально. Позже она ещё больше прорабатывалась до уровня «а как мы это потом будем эксплуатировать». Поэтому тут я расскажу про особенности эксплуатации выбранного решения.
StorageGrid работает с разделёнными неструктурированными данными, управляется из одной панели. Есть CDMI, S3 и Swift для интеграции с облачными провайдерами, есть поддержка ленточных библиотек. Данные свободно ходят между всеми инстансами независимо от их реализации: лента, облако и дисковое/ssd хранилище имеют одинаковые интерфейсы.
Erasure Coding (EC) — аналог RAID, обеспечивающий сохранность данных по Риду-Соломону. Система дробит объекты на k фрагментов, из которых два или более — избыточные. При потере любых двух фрагментов возможно восстановление чистой копии. Затем система распределяет данные по инстансам так, чтобы при потере, например, одной из геоплощадок данные можно было восстановить на другой. На практике используются различные схемы, например, 6 + 3, где шесть частей — это фрагменты исходных данных, а ещё три части — избыточные данные для восстановления, построенные на основе вычислений над первыми шестью частями.
Аналогично есть 3 + 1, 4 + 2 и так далее с разными значения полезных блоков и блоков чётности. Читать при этом можно сразу с двух площадок. Есть Geo Distributed Erasure Coding — это тот же EC, но снижающий трафик: данные не передаются между площадками, а восстанавливаются из избыточных на текущей, что позволяет снижать трафик. К примеру, для четырёх геоточек можно использовать схему 9 + 3. Следующий уровень — Hierarchical Erasure Coding, который делает глобальный GDEC и локальный EC на уровне конкретных устройств.
Ещё ниже в аппаратной реализации лежит Dynamic Disk Pools — аналог RAID в группе на локальной системе, где данные дробятся и распределяются между множеством физических носителей для быстрого чтения. Это позволяет сохранять скорость при просадке части дисков и значительно быстрее восстанавливать сломанные диски, чем классический RAID. При размере дисков в 16 ТБ это действительно имеет значение. Сама технология хорошо сочетается с алгоритмами EC.
Есть эмуляция NAS, что даёт обычный файловый доступ поверх объектного. При этом сам Грид двигает файлы по уровням хранения в зависимости от настроек ILM полностью прозрачно для пользователя.
Лицензирование решения — по сырому дисковому пространству, количество узлов на цену не влияет, в коробке сразу много нужных вещей вроде интеграции с Active Directory.
Протокол для приложений — стандартный S3 Restful API, то есть все бэкапы и другой софт автоматизации подключаются без проблем.
При ограниченном бюджете части или весь StorageGrid можно развернуть/задублировать и на виртуалках, так как это софт. В нашем случае заказчик сначала настаивал, что ему необходимо всё на железе, но, проверив работу НА между физической и виртуальной Admin Node, решил не докупать вторую железку.
К тому же, если у компании уже есть NetApp FAS/AFF, то они могут с помощью технологии FabricPool тирить в автоматическом режиме холодные данные с продуктивной СХД на StorageGrid.
- Размещение файлов на хранение и запрос ранее размещённых файлов (очевидно).
- Метки «не использую».
- Необходимый набор поддерживаемых систем хранения данных: ленточные накопители, дисковые массивы различной скорости доступа и размещения, существующие решения компании, облачные сервисы.
- Гибкие политики хранения.
- Фоновая миграция.
- Удаление файлов в соответствии с политиками (просроченных документов).
- Понятный API.
- Единая точка управления распределённой системой.
- Подходит для хранения сканов, видео, архивов документов, прочих бинарных данных.
- Обеспечение 99,999 % гарантии сохранности данных в течение всего срока их хранения. Предельный срок хранения данных — 75 лет или более.
- Масштабирование системы по числу и объёму используемых СХД.
- Масштабирование системы по производительности запросов на обслуживание.
- Геораспределение.
- Защита от устаревания. Возможность масштабирования (расширения) с учётом новых поколений оборудования. Уже закупленное оборудование должно использоваться до истечения полного срока амортизации (защита инвестиций).
- Отказ части контроллеров не приводит к недоступности массива или потере данных. Отказ всех контроллеров не должен приводить к потере данных. Выход из строя одного из «уровней хранения» не должен приводить к потере данных или отказу в обслуживании системы.
- Статистика и прогнозы утилизации. Мониторинг. JSON для выгрузок. Поддержка SMTP и системы уведомлений о проблемах. И так далее.
Теперь переходим к железу!
NetApp StorageGrid может собираться из различных Storage и Admin-нод.
В нашей реализации использовался узел StorageGRID SG1000, который выполняет роль Gateway Node или Admin Node для обеспечения отказоустойчивости и балансировки нагрузки. Ниже — SG1000 без передней панели. Два SSD-диска, выделенные рамкой, используются для ОС StorageGRID и используют RAID1 для отказоустойчивости. Оставшиеся дисковые слоты остаются пустыми. Когда SG1000 настроен как Admin Node, диски используются для хранения аудит логов, метрик и таблиц БД.
Порты для подключения с задней стороны SG1000:
StorageGRID SG6060 — сюда интегрированы вычислительный контроллер и контроллер хранения. Устройство может быть использовано в гибридной структуре с физическими и виртуальными Storage Node. Дополнительно можно расширить дисковой полкой с 60 дисками.
На рисунке изображён SG6060 с передней стороны с вычислительным контроллером и контроллером хранения с красивой «мордой» и без.
Вид сзади на полку расширения для SG6060 с IOM-модулями, вентиляторами и блоками питания:
Если подробнее — каждый StorageGRID SG6000 состоит из вычислительного 1U-контроллера SG6000-CN и двух E-series-контроллеров хранения в корзине 2U или 4U в зависимости от модели. Ниже описана более подробная информация о каждом контроллере.
Вычислительный контроллер SG6000-CN: предоставляет вычислительные ресурсы для системы; включает в себя StorageGRID Appliance Installer; может подключаться ко всем трём сетям, включая Grid Network, Admin Network, Client Network; подключается к контроллерам хранения и выступает инициатором.
Контроллер хранения Е2800: два контроллера для обеспечения отказоустойчивости; управляет хранением данных на дисках; включает в себя SANtricity OS (ОС контроллера); включает в себя SANtricity System Manager для мониторинга состояния оборудования и оповещений, автосаппорта и функции Drive Security; подключается к SG6000-CN и обеспечивает доступ к хранилищу данных.
На рисунке изображён контроллер Е2800 с задней стороны:
IOM (input/output) — модули для расширения полок:
Если вы ещё тут, то поздравляю, вы гик! Ну или IT-специалист по огромным архивам.
Шаг 4: взлетаем
В итоге для старта установлено по три узла SG6060 и одному SG1000 в каждый ЦОД. Всё это объединено продуктивной и менеджмент-сетками. Для репликации используется обычная сеть заказчика с шифрованием трафика между сайтами. Повозившись немного с монтажом и аккуратной коммутацией, запустилось всё гораздо проще, чем ожидали. И спустя буквально час после монтажа уже можно было загружать тестовые объекты.
Дальше смотрим на софт.
Tenant Manager или Tenant Management API могут быть использованы для управления консистентностью операций, выполняемых с объектами в S3-бакетах. Уровень консистентности устанавливает баланс между доступностью объектов и их консистентностью на различных узлах хранения и сайтах. В целом следует использовать правило Read-after-new-write для всех бакетов. Если данный уровень (Read-after-new-write) не удовлетворяет потребностям приложений, то уровень консистентности можно поменять в заголовке Consistency-Control. Данный заголовок имеет приоритет над уровнем консистентности, установленным на бакете.
Дашборд:
Платформенные сервисы StorageGRID позволяют реализовать стратегию гибридного облака. Если данные сервисы разрешены в рамках тенанта, то существует возможность интеграции следующих сервисов для S3-бакетов:
1. CloudMirror replication: StorageGRID CloudMirror — это сервис репликации, который используется для зеркалирования отдельных объектов из бакета в отдельное внешнее хранилище.
Например, есть возможность использовать CloudMirror для зеркалирования отдельных пользовательских записей во внешнее S3-облако, чтобы потом использовать облачные сервисы для аналитики данных.
2. Notifications: Нотификации, устанавливаемые на уровне бакетов, используются для того, чтобы отправлять оповещения об определённых действиях, которые выполняются над объектами.
Например, есть возможность сконфигурировать оповещения администратора о каждом объекте определённого типа, добавляемого в бакет, к примеру, при добавлении логов, связанных с определёнными критическими событиями.
3. Search integration service: интеграция с поисковым сервисом используется для отправки метаданных S3-объектов в указанный Elasticsearch-индекс, где они могут быть использованы для поиска либо анализа при помощи внешнего сервиса.
Например, можно сконфигурировать бакеты для отправки S3-метаданных объектов во внешний Elasticsearch-сервис. После этого можно будет выполнять поиск в различных бакетах, а также анализ паттернов, присутствующих в метаданных объектов.
По причине того, что целевая система для платформенных сервисов является, как правило, внешней по отношению к StorageGRID, платформенные сервисы дают возможность использовать мощь и гибкость комбинации внешних ресурсов и поисковых запросов для хранимых данных.
Шаг 5: Полёт
Как масштабировать эту систему? Докупать ещё узлы, включать их в синхронизацию и ждать несколько часов. Потолка, сколько этих узлов может быть, практически нет. Из известных максимумов это 16 сайтов, 400 ПБ ёмкости и 100 миллиардов объектов.
Обновление — узлами нового поколения. Покупаются новые узлы, данные сами мигрируются, старые выводятся из эксплуатации.
Сейчас всё это проверяется на практике. И, как мне кажется, мы собрали нечто, способное выдержать довольно долгий космический перелёт, обновление запчастями на новых планетах и перелёт дальше. В общем, знакомьтесь с технологиями межзвёздных торговых корпораций, использующих релятивистские движки. И спасибо, что дочитали до этого места).
Если вдруг есть вопросы или вы через год-другой захотите узнать, как там наш полёт, — вот моя почта: mk@croc.ru.
Комментарии (54)
vesper-bot
12.10.2021 10:26Интересно, какой S3 у нетаппа под капотом. Ceph?
MKostsov Автор
12.10.2021 11:41S3 - это протокол объектного доступа. Такие решения, как NetApp StorageGrid или тот же Ceph, являются программными или программно-аппаратными решениями, которые реализуют доступ в том числе по этому протоколу. Если речь про SDS – то внутри StorageGrid как такового Ceph нет. Сделана своя реализация, но с довольно схожими подходами.
vesper-bot
12.10.2021 11:44Спасибо. В принципе, с точки зрения подходов — их ограниченное количество, и для такой довольно четкой задачи, как SDS с требованиями по отказоустойчивости итэдэ, возможных подходов не так и много, поэтому схожесть решений неудивительна. А то, что сами пилили код SDS — осилите поддержку кода в течение 50 лет?
MKostsov Автор
12.10.2021 12:06
Система разработана крупным международным вендором (NetApp). И находится в постоянном развитии уже 20 лет, во время которых некоторые вендоры неоднократно успели закрыть свои схожие продукты и открыть новые. Гарантировать развитие и поддержку кода в течение 50 лет, разумеется, никто не может и риск есть всегда, но планы по NetApp StorageGrid довольно дальновидные.
tas
12.10.2021 10:29+7Вопрос про боль для всех таких хранилищ: Как обеспечили требование:
Обеспечение юридической значимости документов с использованием электронной подписи на протяжении 50 и более лет (с учетом ситуаций, когда происходит компрометация ключа электронной подписи, а также компрометации (устаревания) самих алгоритмов ЭЦП - ведь одного наличия NENR и WORM для этого недостаточно)?
MKostsov Автор
12.10.2021 12:01+1
На самом деле очень интересный вопрос. В нашем случае стояла реализация самого хранилища, но не пользовательского приложения по хранению документов. Обеспечение юридической значимости документов и ЭЦП реализуется заказчиком. А возможности и пути реализации – хватит на большую отдельную статью)
ufoton
12.10.2021 10:39-5Проще и дешевле выбрать облачное решение. Через пяток лет окажется, что всё это устарело и нужно обновление и тд и тп.
Примерная похожая схема была реализована но обородовании другого вендора, недавно закончили перенос в облако. Какое то время работало норм.. потом стала лагать репликация, так как оказалось, что на репликацию нужен не слабый запас по месту.. при попытке докупить дисков в пустые слоты, нам предложили купить новые полки. Посчитали, смигрировали.
ufoton
12.10.2021 11:50+2стоимость этой инсталяции врядли меньше полумилиона $ хранение 500TB данных в популярном облаке обойдётся от 16к до 100к в год в зависимости от типа хранения.
yoz
12.10.2021 13:57+2На Амазоне они хранить это не могут. В РФ даже близко сравнимых услуг нет.
ufoton
12.10.2021 14:42yandex - ?
yoz
12.10.2021 14:48+1Им до AWS как раком до Китая. Не так давно у людей просто пропали машины в облаках Яндекса, в ответ «ну сорян, делайте бэкапы». У AWS не помню такого. Падения и отключения да, были. Но безвозвратная потеря…
ufoton
12.10.2021 15:01Ну у меня aws терял машины. Я не вижу в этом проблем.
PS. А сколько железных серверов уже потеряно безвозвратно.
yoz
12.10.2021 15:39Железные сервера обычно сами себе резервируют и точно знают свои точки отказа. В российские облака, да и не в российские наверное тоже, сливать данные как в единственное место у нас очень многие не хотят. Утечки, уязвимости, путающие ssh прода и теста админы, маски шоу, софтовые глюки, блокировки.
Я за baremetal, пусть и старомодно. Лишь в этом случае я могу свои данные «пощупать» руками в том числе физически.
JerleShannara
12.10.2021 14:51А накидайте сюда облаков, которые умеют в 152-ФЗ «О персональных данных» и которые могут такой объём?
vvpoloskin
12.10.2021 19:52Да дофига каких. Но, как всегда, дьявол кроется в деталях. К облаку нужен канал передачи данных, желательно выделенный и защищённый СКЗИ. Если облака два, значит надо два канала. Если сотрудники территориально распределены, каналы нужны от каждого.
Далее услуги нотариуса, как сейчас принято говорить, не является «цифровым продуктом», информационные технологии тут нужны в качестве автоматизированной системы. Значит чтобы производственный процесс не встал в случае отказа облака, надо запустить внутренние процедуры при условии отсутствия автоматизации. А это тоже ещё тот квест на год работы.
sergeyns
12.10.2021 11:33+13Решение полностью соответствует всем требованиям в техническом задании.
Дык наверняка вы же его и писали))) и наверняка под этого вендора )))
drobzik
12.10.2021 12:08+8Как реклама решения NetApp — сойдет, но только если убрать требование про 50 лет хранения.
Занимался я подобной задачей (длительное архивное хранение) несколько лет назад. Возможно, сегодня что-то и поменялось, но тогда не было ни одного доступного (т.е. такого которое можно было бы купить за разумные деньги, или вообще купить) ТЕХНИЧЕСКОГО решения, которое могдо бы обеспечить гарантированное хранение данных на столь длительный срок. Самое лучшее что могло быть — это ленточные библиотеки, но только в связке с кучей организационных мероприятий (причем именно организационные мероприятия тут главные). Причина — ни один вендор не подпишется, что их продуктовая линейка ХХХ будет доступна через 5-10 лет, или что для нее могут выпускаться совместимые железки, или что она вообще не окажется в статусе End-of-Life. Поэтому и не получится поставить железку, и потом по мере необходимости только докупать к ней модули — через пару-тройку лет выяснится, что совместимых винчестеров нет и нужно покупать новые полки, еще через годик окажется что менеджмент-ноды не поддерживают новые модели полок расширения и их нужно менять, а в процессе замены окажется что существующие полки уже не поддерживаются — и все, привет миграция на новенький массив.
И чтобы два раза не вставать — нет, хранение в облаке тут вообще не вариант. Если провайдер просрет ваши данные, то максимум что дождетесь — это письма в стиле «извините, мы тут потеряли ваши данные, вот вам в качестве компенсации скидка на следующий месяц».ufoton
12.10.2021 12:50Если in-house система просрёт эти данные, то даже письма не будет. ;)
Какой sla у всей этой инсталяции?
Хранение в облаке не исключает мероприятий по резервации.drobzik
12.10.2021 13:58Если in-house система просрёт эти данные, то даже письма не будет. ;)
Не просрет, для этого как раз правильная организация всего процесса и нужна.Какой sla у всей этой инсталяции?
Достаточный:) Вынуть данные с ленты — это где-то полчаса времени, с учетом перекура. В случае конкретно архивного хранения, никто не ожидает on-line доступа к данным, тут в первую очередь важна именно надежность. А с надежностью все хорошо — 2 ЦОДа, 3 копии каждого куска данных, off-site хранение, плюс организационные мероприятия по регулярной проверке лент и замене поврежденных копий.Хранение в облаке не исключает мероприятий по резервации.
Хранение в облаке — это перекладывание ответственности на третью сторону. Во всех договорах что я видел, провайдер обещал что он приложит максимум усилий чтобы сохранить данные, но если придет пушной зверек, то провайдер просто умоет руки со словами «так бэкапиться надо было!», и никаких претензий принимать не будет. Опять же, может быть, сейчас что-то и поменялось, но раньше в законодательстве не было такого понятия как хранение в облаке. И даже больше, такое длительное хранение (50+ лет) обычно касается такой информации и клиентов, которые в любом случае по закону вынуждены хранить данные in-house.ufoton
12.10.2021 14:26-2Не просрет, для этого как раз правильная организация всего процесса и нужна.
Все говорят - не просрёт.
Достаточный:)
До есть он даже не посчитан ;) всё на уровне - должно быть ок.
Хранение в облаке — это перекладывание ответственности на третью сторону.
Ну перекладывание ответствености это не всегда плохо.
обычно касается такой информации и клиентов, которые в любом случае по закону вынуждены хранить данные in-house.
Скорее всего это заблуждение.
drobzik
12.10.2021 16:42+1Все говорят — не просрёт
Те организации где я видел — точно не про… теряют. Все было сделано как в армии, квадратно-гнездовым методом, с кучей контролей и персональной ответственностью:)До есть он даже не посчитан ;) всё на уровне — должно быть ок
Повторюсь, для тех организаций с которыми я пересекался, онлайн доступ не требовался, и полчаса на получение информации было более чем достаточно. И да, все нормально работало (архивные данные не сильно часто требовались, но время от времени такая потребность возникала)Скорее всего это заблуждение
Ошибаетесь. Навскидку вспоминается пинание всяких Гуглов и Фейсбуков на тему хранения данных локально. Вряд ли к местным компаниям будут относиться более лояльно/снисходительно.
susa
12.10.2021 13:07Вы безусловно правы. Чтобы это понять можно заглянуть назад в историю даже не на 50 лет, а на 25... С точки зрения аппаратных решений совсем все другое.
yoz
12.10.2021 13:47+1Для примера можно взять обычные СХД HP P2000. Вышли они на рынок более 10 лет назад. До сих пор нет проблем с комплектующими. Думаю и не будет еще лет 10 точно. Пока никто не даст рынку альтернативных протоколов и формфакторов для хранения. SATA\SAS и LFF\SSF никуда не уходит.
Фактически их можно использовать просто как банку с данными, которую отдать по scsi\sas\fc в сервер с любым нужным софтом.ufoton
12.10.2021 14:47У меня стоит парочка p2000 выключеных. Отработали гарантийный период, следующий круг поддержки стоил немало. Проект под который их взяли эволюционировал и всё.
Вы уверены, что на p2000 ещё можно купить поддержку?yoz
12.10.2021 14:57Поддержку от вендора? Не знаю, сомнительно. Но новые детали есть.
В каком-то смысле это получается самосбор, но используя довольно серьезное надежное железо.
Renaissance
12.10.2021 20:18Вы уверены, что на p2000 ещё можно купить поддержку?
была еще возможность купить на полгода 2021, теперь все, абсолютно любая поддержка недоступна для p2000.
drobzik
12.10.2021 16:47Ага, только там еще есть поколения. Под рукой нет конфигуратора, но я сомневаюсь, что на MSA2000 (как они раньше назывались) вы сейчас найдете хоть что-нибуть, разве что из Refurbished компонент.
beerchaser
12.10.2021 15:18А еще забыт аспект импортозамещения. А без учета ИЗ и с учетом открывающихся перспектив в долгосрочном планировании технической поддержки и сопровождегия может приключиться конфуз. Или я что-то пропустил в части международного позиционирования системы?
Gutt
14.10.2021 14:39+1не было ни одного доступного (т.е. такого которое можно было бы купить за разумные деньги, или вообще купить) ТЕХНИЧЕСКОГО решения, которое могдо бы обеспечить гарантированное хранение данных на столь длительный срок.
Ну, хранение-то можно обеспечить, а вот чтение... Любая система хранения на такой срок подразумеват миграцию данных по мере того, как старые системы достигают EoS. Так что задача тут состоит в том, чтобы попытаться предсказать, какие интерфейсы не умрут в ближайшие -надцать лет, чтобы миграция на следующее хранилище была более-менее беспроблемной. NFS и S3 выглядят хорошими вариантами.
susa
12.10.2021 13:05+3Сарказм: а почему для таких критически важных документов, содержащих массу чувствительной персональной информации, не выбраны православные отечественные программные и аппаратные продукты? А если завтра санкции введут, то как на 50 лет обеспечивается масштабируемость и поддержка?
MKostsov Автор
12.10.2021 14:48+1Санкции - риск, который конечно всегда стоит учитывать. И здесь так же он был принят к сведению. Но передавать такой объём критичных данных на достаточно новые продукты на рынке никто не был готов. В любом случае в перспективе менее 10 лет все может измениться. Главное, что подход к хранению данных уже изменён и в дальнейшем масштабирование хранилища или полный переход даже на отечественные продукты будет проще,
beerchaser
12.10.2021 16:01+1к сожалению, для таких решений как правило обратного пути нет. во-первых, данные существуют не сами по себе - ими пользуются. это подразумевает сопряжение архивной системы с множеством других систем. во-вторых, объем данных не позволит мгновенно изменить формат их хранения. 10 лет для такой системы - только выйти из детских болезней. все это ведет к тому, что за ошибку при проектировании и выборе оборудования благодарные пользователи и обслуживающий персонал разработчиков будут поминать очень долго.
Gutt
14.10.2021 14:48+1А если завтра санкции введут, то как на 50 лет обеспечивается масштабируемость и поддержка?
Текущее руководство страны проживёт, может быть, ещё лет 10--15, а потом проплывёт вниз по реке. Принимая стратегическое решение на 50 лет, не стоит учитывать вот эти краткосрочные переходные режимы. Это шум. Что важно -- это широко используемые интерфейсы, которые проживут дольше.
FlashHaos
12.10.2021 13:46А почему не ленты-то, я так и не понял. Стоимость будет несравнима.
yoz
12.10.2021 13:48Лента с автоматизированными роборуками и камерами хранения с нужными условиями будет дороже. А лента «попроще» требует человеческого обслуживания и это Х фактор риска.
drobzik
12.10.2021 15:59Сомневаюсь, на длинной дистанции TCO лент будет больше чем у хранилок аналогичного объема. Плюс, у лент есть такие приятные плюшки как невозможность какого-нить WannaCry зашифровать данные :)
MKostsov Автор
12.10.2021 14:49Скорость доступа к данным, время отклика. Это все-таки не архив, где положил и забыл, а при необходимости восстановил нужный файл в течение получаса. А активное хранилище, где с большинством данных регулярно работают и обновляют. Также регулярно требуется работа с большим количеством разрозненных мелких файлов, что с лентами совсем не применимо.
Dmitry88
12.10.2021 15:24+1Ленты - единственное решение (ну или bd диски), которое позволяет хранить данные по 20-30 лет и более. Никакие ssd и тем более жесткие диски не дают таких сроков. Получить данные с лент в течении минимального времени зависит только от количества приводов и количества запросов. Мало того, регуляторы требуют хранение на worm носителях, потому как даже, если вам повезет и ничего не сломается, вы предварительно закупитесь дисками на 30 лет вперед, то это не значит что-то кто-то не удалит и не изменит ваши данные.
А пока у вас обычное типовое решение к долгосрочному хранению не имеющее никакого отношения.
FlashHaos
12.10.2021 18:12+4Сканы документов - обновляют? Со сканами документов, хранящимися по 30 лет - регулярно работают? Из описания задачи складывается впечатление о совсем ином профиле взаимодействия.
leahch
12.10.2021 14:04+3Используем CEPH, данных около 300 терабайт. Ушли с проприетарных хранилищ лет 10 назад. Бонусом получили независимое использование железа любого вендора, перестали платить за "лицензии" на дополнительные программные фичи, расширяемся по мере необходимости и бюджета.
Какие были проблемы с проприетарщиной? Все как у всех: вендор-лок, стоимость лицензий, комплектующие и вот это вот все...
CherryPah
12.10.2021 16:22Падения были?
leahch
12.10.2021 17:48+2Конечно были. Пару раз по нашей вине.
Первый раз в самом начала после отключения питания перепутали FC- кабели, пришлось восстанавливать из каши через самописный питоновский скрипт.
Второй - когда питание полностью грохнулось, но все восстановилось само.
Третий - непредвиденное, менялось руководство и доблестные новые начальники просто на горячую (SIC!) выдернули все провода под руководством охраны! Нас, естественно, никто не слушал, от серверной с кулаками отогнали. Веселое время было :) Но и здесь все штатно собралось, потом, для через три.
Еще пару раз аварии были, сервера отваливались, диски - но таких крупных вроде бы не было - все штатно восстанавливается.
CherryPah
13.10.2021 18:50Спасибо. Я цеф на стенде несколько раз тыкал палочкой, но от серьезного применения каждый раз отталкивают гуглящиеся ужасные истории что оно хорошо работает пока не упадет, а дальше достаточно нетривиальные методы его поднятия. Даже тут на хабре статьи по этой теме проскакивали
Gutt
14.10.2021 14:54Наличие Ceph никак не отменяет бекап. Даже если оно не поднимется, вы просто запустите Terraform/Ansible/whatever конфигурации, чтобы сделать новый кластер, и зальёте данные из бекапа.
CherryPah
14.10.2021 15:15Есть случаи когда полный бэкап, скажем так невозможен. Вот есть у меня хранилка на 5ПБ горячих данных, как ее бэкапить. Сейчас ее целостность обеспечивается ХПшной проприетарщиной и 10 рейдом, в теории цеф может дать выигрыш по месту, но остается вопрос с надежностью этого цефа, почему я и поинтересовался падал ли он у товарища в боевых условиях, и как потом восстанавливался
Gutt
14.10.2021 19:27Есть случаи когда полный бэкап, скажем так невозможен. Вот есть у меня хранилка на 5ПБ горячих данных, как ее бэкапить.
Если данные совсем разнородные и со стороны приложений их никак в консистентное состояние для снепшота не привести, то просто делать снепшоты частей системы по таймеру и их инкрементально бекапить. Упасть может всё, и географически распределённое хранилище тоже не панацея, потому что данные могут пропасть из-за ошибки приложения, злого умысла или ошибки в логике работы хранилищ.
CherryPah
15.10.2021 13:18Там архив видеонаблюдения, ценность этих данных в лучшем случае 2 недели, в худшем 3 дня, в среднем неделя; в зависимости от регламентов безопасников. Новые данные должны быть записаны, старые надежно потеряны чтобы не занимать место, никакие long term бэкапы тут не подразумеваются by design, они делаться будут дольше чем будут нужны. Ну и чтобы их хранить - нужно по факту хранилище x2 закладывать, а мы вроде наоборот подразумеваем уход от полного зеркала, с его потерей в сыром объеме к цефу, где в теории можно место выиграть.
leahch
12.10.2021 23:00Вообще-то тут подумалось, что для данной задачи нужно не хранилище документов, а что-то типа apache kafka. И кластер, и наращиваемость, и от вендора независимо, и хранение только добавлением с гарантией записи в несколько источников. Тут и вечное хранилище, и потоки и выборка по интервалам... Ляпота... Но в кафку нужно уметь, да...
poige
Вполне возможно, что так и есть! ) И, кстати, уверен, что читателям тут покажется, что они рекламный буклет внезапно почитали.
А с точки зрения практики, выбирать что-то в IT на 20 лет вперёд — крайне сомнительный тезис. Строить на такие строки нужно так, чтобы максимально просто можно было перестраивать, мигрировать данные и сервисы, и уж точно не закладываться на весь этот срок под какого-то вендора.
MKostsov Автор
Согласен, что выбирать что-либо на 20 лет вперёд – не лучшая идея. Тем не менее задача стояла таким образом и нужно было подобрать дальнейший путь развития. Основной идеей было использовать объектное хранение с распространенным и проверенным протоколом доступа, а так же надежное он-премис решение, которое его реализует. С использованием S3 в дальнейшем можно будет перестроиться на любое другое решение или свободно смигрировать в то же облако при необходимости. Тем не менее сейчас есть надежная программно-аппаратная катастрофоусточивая реализация, с практически неограниченными возможностями масштабирования, которого хватит на долгий период. И даже если вдруг что-то пойдет не так – всегда будет альтернатива