Comments 54
И, как мне кажется, мы собрали нечто
Вполне возможно, что так и есть! ) И, кстати, уверен, что читателям тут покажется, что они рекламный буклет внезапно почитали.
А с точки зрения практики, выбирать что-то в IT на 20 лет вперёд — крайне сомнительный тезис. Строить на такие строки нужно так, чтобы максимально просто можно было перестраивать, мигрировать данные и сервисы, и уж точно не закладываться на весь этот срок под какого-то вендора.
Согласен, что выбирать что-либо на 20 лет вперёд – не лучшая идея. Тем не менее задача стояла таким образом и нужно было подобрать дальнейший путь развития. Основной идеей было использовать объектное хранение с распространенным и проверенным протоколом доступа, а так же надежное он-премис решение, которое его реализует. С использованием S3 в дальнейшем можно будет перестроиться на любое другое решение или свободно смигрировать в то же облако при необходимости. Тем не менее сейчас есть надежная программно-аппаратная катастрофоусточивая реализация, с практически неограниченными возможностями масштабирования, которого хватит на долгий период. И даже если вдруг что-то пойдет не так – всегда будет альтернатива
Интересно, какой S3 у нетаппа под капотом. Ceph?
S3 - это протокол объектного доступа. Такие решения, как NetApp StorageGrid или тот же Ceph, являются программными или программно-аппаратными решениями, которые реализуют доступ в том числе по этому протоколу. Если речь про SDS – то внутри StorageGrid как такового Ceph нет. Сделана своя реализация, но с довольно схожими подходами.
Спасибо. В принципе, с точки зрения подходов — их ограниченное количество, и для такой довольно четкой задачи, как SDS с требованиями по отказоустойчивости итэдэ, возможных подходов не так и много, поэтому схожесть решений неудивительна. А то, что сами пилили код SDS — осилите поддержку кода в течение 50 лет?
Система разработана крупным международным вендором (NetApp). И находится в постоянном развитии уже 20 лет, во время которых некоторые вендоры неоднократно успели закрыть свои схожие продукты и открыть новые. Гарантировать развитие и поддержку кода в течение 50 лет, разумеется, никто не может и риск есть всегда, но планы по NetApp StorageGrid довольно дальновидные.
Добрый день, а в чем схожесть подходов?
Вопрос про боль для всех таких хранилищ: Как обеспечили требование:
Обеспечение юридической значимости документов с использованием электронной подписи на протяжении 50 и более лет (с учетом ситуаций, когда происходит компрометация ключа электронной подписи, а также компрометации (устаревания) самих алгоритмов ЭЦП - ведь одного наличия NENR и WORM для этого недостаточно)?
Проще и дешевле выбрать облачное решение. Через пяток лет окажется, что всё это устарело и нужно обновление и тд и тп.
Примерная похожая схема была реализована но обородовании другого вендора, недавно закончили перенос в облако. Какое то время работало норм.. потом стала лагать репликация, так как оказалось, что на репликацию нужен не слабый запас по месту.. при попытке докупить дисков в пустые слоты, нам предложили купить новые полки. Посчитали, смигрировали.
стоимость этой инсталяции врядли меньше полумилиона $ хранение 500TB данных в популярном облаке обойдётся от 16к до 100к в год в зависимости от типа хранения.
yandex - ?
Ну у меня aws терял машины. Я не вижу в этом проблем.
PS. А сколько железных серверов уже потеряно безвозвратно.
Я за baremetal, пусть и старомодно. Лишь в этом случае я могу свои данные «пощупать» руками в том числе физически.
Ну я думаю все такой обьём смогут. Цена и sla решают..
Да дофига каких. Но, как всегда, дьявол кроется в деталях. К облаку нужен канал передачи данных, желательно выделенный и защищённый СКЗИ. Если облака два, значит надо два канала. Если сотрудники территориально распределены, каналы нужны от каждого.
Далее услуги нотариуса, как сейчас принято говорить, не является «цифровым продуктом», информационные технологии тут нужны в качестве автоматизированной системы. Значит чтобы производственный процесс не встал в случае отказа облака, надо запустить внутренние процедуры при условии отсутствия автоматизации. А это тоже ещё тот квест на год работы.
Решение полностью соответствует всем требованиям в техническом задании.
Дык наверняка вы же его и писали))) и наверняка под этого вендора )))
Занимался я подобной задачей (длительное архивное хранение) несколько лет назад. Возможно, сегодня что-то и поменялось, но тогда не было ни одного доступного (т.е. такого которое можно было бы купить за разумные деньги, или вообще купить) ТЕХНИЧЕСКОГО решения, которое могдо бы обеспечить гарантированное хранение данных на столь длительный срок. Самое лучшее что могло быть — это ленточные библиотеки, но только в связке с кучей организационных мероприятий (причем именно организационные мероприятия тут главные). Причина — ни один вендор не подпишется, что их продуктовая линейка ХХХ будет доступна через 5-10 лет, или что для нее могут выпускаться совместимые железки, или что она вообще не окажется в статусе End-of-Life. Поэтому и не получится поставить железку, и потом по мере необходимости только докупать к ней модули — через пару-тройку лет выяснится, что совместимых винчестеров нет и нужно покупать новые полки, еще через годик окажется что менеджмент-ноды не поддерживают новые модели полок расширения и их нужно менять, а в процессе замены окажется что существующие полки уже не поддерживаются — и все, привет миграция на новенький массив.
И чтобы два раза не вставать — нет, хранение в облаке тут вообще не вариант. Если провайдер просрет ваши данные, то максимум что дождетесь — это письма в стиле «извините, мы тут потеряли ваши данные, вот вам в качестве компенсации скидка на следующий месяц».
Если in-house система просрёт эти данные, то даже письма не будет. ;)
Какой sla у всей этой инсталяции?
Хранение в облаке не исключает мероприятий по резервации.
Если in-house система просрёт эти данные, то даже письма не будет. ;)
Не просрет, для этого как раз правильная организация всего процесса и нужна.
Какой sla у всей этой инсталяции?
Достаточный:) Вынуть данные с ленты — это где-то полчаса времени, с учетом перекура. В случае конкретно архивного хранения, никто не ожидает on-line доступа к данным, тут в первую очередь важна именно надежность. А с надежностью все хорошо — 2 ЦОДа, 3 копии каждого куска данных, off-site хранение, плюс организационные мероприятия по регулярной проверке лент и замене поврежденных копий.
Хранение в облаке не исключает мероприятий по резервации.
Хранение в облаке — это перекладывание ответственности на третью сторону. Во всех договорах что я видел, провайдер обещал что он приложит максимум усилий чтобы сохранить данные, но если придет пушной зверек, то провайдер просто умоет руки со словами «так бэкапиться надо было!», и никаких претензий принимать не будет. Опять же, может быть, сейчас что-то и поменялось, но раньше в законодательстве не было такого понятия как хранение в облаке. И даже больше, такое длительное хранение (50+ лет) обычно касается такой информации и клиентов, которые в любом случае по закону вынуждены хранить данные in-house.
Не просрет, для этого как раз правильная организация всего процесса и нужна.
Все говорят - не просрёт.
Достаточный:)
До есть он даже не посчитан ;) всё на уровне - должно быть ок.
Хранение в облаке — это перекладывание ответственности на третью сторону.
Ну перекладывание ответствености это не всегда плохо.
обычно касается такой информации и клиентов, которые в любом случае по закону вынуждены хранить данные in-house.
Скорее всего это заблуждение.
Все говорят — не просрёт
Те организации где я видел — точно не про… теряют. Все было сделано как в армии, квадратно-гнездовым методом, с кучей контролей и персональной ответственностью:)
До есть он даже не посчитан ;) всё на уровне — должно быть ок
Повторюсь, для тех организаций с которыми я пересекался, онлайн доступ не требовался, и полчаса на получение информации было более чем достаточно. И да, все нормально работало (архивные данные не сильно часто требовались, но время от времени такая потребность возникала)
Скорее всего это заблуждение
Ошибаетесь. Навскидку вспоминается пинание всяких Гуглов и Фейсбуков на тему хранения данных локально. Вряд ли к местным компаниям будут относиться более лояльно/снисходительно.
Вы безусловно правы. Чтобы это понять можно заглянуть назад в историю даже не на 50 лет, а на 25... С точки зрения аппаратных решений совсем все другое.
Фактически их можно использовать просто как банку с данными, которую отдать по scsi\sas\fc в сервер с любым нужным софтом.
У меня стоит парочка p2000 выключеных. Отработали гарантийный период, следующий круг поддержки стоил немало. Проект под который их взяли эволюционировал и всё.
Вы уверены, что на p2000 ещё можно купить поддержку?
В каком-то смысле это получается самосбор, но используя довольно серьезное надежное железо.
Вы уверены, что на p2000 ещё можно купить поддержку?
была еще возможность купить на полгода 2021, теперь все, абсолютно любая поддержка недоступна для p2000.
А еще забыт аспект импортозамещения. А без учета ИЗ и с учетом открывающихся перспектив в долгосрочном планировании технической поддержки и сопровождегия может приключиться конфуз. Или я что-то пропустил в части международного позиционирования системы?
не было ни одного доступного (т.е. такого которое можно было бы купить за разумные деньги, или вообще купить) ТЕХНИЧЕСКОГО решения, которое могдо бы обеспечить гарантированное хранение данных на столь длительный срок.
Ну, хранение-то можно обеспечить, а вот чтение... Любая система хранения на такой срок подразумеват миграцию данных по мере того, как старые системы достигают EoS. Так что задача тут состоит в том, чтобы попытаться предсказать, какие интерфейсы не умрут в ближайшие -надцать лет, чтобы миграция на следующее хранилище была более-менее беспроблемной. NFS и S3 выглядят хорошими вариантами.
Сарказм: а почему для таких критически важных документов, содержащих массу чувствительной персональной информации, не выбраны православные отечественные программные и аппаратные продукты? А если завтра санкции введут, то как на 50 лет обеспечивается масштабируемость и поддержка?
Санкции - риск, который конечно всегда стоит учитывать. И здесь так же он был принят к сведению. Но передавать такой объём критичных данных на достаточно новые продукты на рынке никто не был готов. В любом случае в перспективе менее 10 лет все может измениться. Главное, что подход к хранению данных уже изменён и в дальнейшем масштабирование хранилища или полный переход даже на отечественные продукты будет проще,
к сожалению, для таких решений как правило обратного пути нет. во-первых, данные существуют не сами по себе - ими пользуются. это подразумевает сопряжение архивной системы с множеством других систем. во-вторых, объем данных не позволит мгновенно изменить формат их хранения. 10 лет для такой системы - только выйти из детских болезней. все это ведет к тому, что за ошибку при проектировании и выборе оборудования благодарные пользователи и обслуживающий персонал разработчиков будут поминать очень долго.
А если завтра санкции введут, то как на 50 лет обеспечивается масштабируемость и поддержка?
Текущее руководство страны проживёт, может быть, ещё лет 10--15, а потом проплывёт вниз по реке. Принимая стратегическое решение на 50 лет, не стоит учитывать вот эти краткосрочные переходные режимы. Это шум. Что важно -- это широко используемые интерфейсы, которые проживут дольше.
А почему не ленты-то, я так и не понял. Стоимость будет несравнима.
Скорость доступа к данным, время отклика. Это все-таки не архив, где положил и забыл, а при необходимости восстановил нужный файл в течение получаса. А активное хранилище, где с большинством данных регулярно работают и обновляют. Также регулярно требуется работа с большим количеством разрозненных мелких файлов, что с лентами совсем не применимо.
Используем CEPH, данных около 300 терабайт. Ушли с проприетарных хранилищ лет 10 назад. Бонусом получили независимое использование железа любого вендора, перестали платить за "лицензии" на дополнительные программные фичи, расширяемся по мере необходимости и бюджета.
Какие были проблемы с проприетарщиной? Все как у всех: вендор-лок, стоимость лицензий, комплектующие и вот это вот все...
Падения были?
Конечно были. Пару раз по нашей вине.
Первый раз в самом начала после отключения питания перепутали FC- кабели, пришлось восстанавливать из каши через самописный питоновский скрипт.
Второй - когда питание полностью грохнулось, но все восстановилось само.
Третий - непредвиденное, менялось руководство и доблестные новые начальники просто на горячую (SIC!) выдернули все провода под руководством охраны! Нас, естественно, никто не слушал, от серверной с кулаками отогнали. Веселое время было :) Но и здесь все штатно собралось, потом, для через три.
Еще пару раз аварии были, сервера отваливались, диски - но таких крупных вроде бы не было - все штатно восстанавливается.
Спасибо. Я цеф на стенде несколько раз тыкал палочкой, но от серьезного применения каждый раз отталкивают гуглящиеся ужасные истории что оно хорошо работает пока не упадет, а дальше достаточно нетривиальные методы его поднятия. Даже тут на хабре статьи по этой теме проскакивали
Наличие Ceph никак не отменяет бекап. Даже если оно не поднимется, вы просто запустите Terraform/Ansible/whatever конфигурации, чтобы сделать новый кластер, и зальёте данные из бекапа.
Есть случаи когда полный бэкап, скажем так невозможен. Вот есть у меня хранилка на 5ПБ горячих данных, как ее бэкапить. Сейчас ее целостность обеспечивается ХПшной проприетарщиной и 10 рейдом, в теории цеф может дать выигрыш по месту, но остается вопрос с надежностью этого цефа, почему я и поинтересовался падал ли он у товарища в боевых условиях, и как потом восстанавливался
Есть случаи когда полный бэкап, скажем так невозможен. Вот есть у меня хранилка на 5ПБ горячих данных, как ее бэкапить.
Если данные совсем разнородные и со стороны приложений их никак в консистентное состояние для снепшота не привести, то просто делать снепшоты частей системы по таймеру и их инкрементально бекапить. Упасть может всё, и географически распределённое хранилище тоже не панацея, потому что данные могут пропасть из-за ошибки приложения, злого умысла или ошибки в логике работы хранилищ.
Там архив видеонаблюдения, ценность этих данных в лучшем случае 2 недели, в худшем 3 дня, в среднем неделя; в зависимости от регламентов безопасников. Новые данные должны быть записаны, старые надежно потеряны чтобы не занимать место, никакие long term бэкапы тут не подразумеваются by design, они делаться будут дольше чем будут нужны. Ну и чтобы их хранить - нужно по факту хранилище x2 закладывать, а мы вроде наоборот подразумеваем уход от полного зеркала, с его потерей в сыром объеме к цефу, где в теории можно место выиграть.
Вообще-то тут подумалось, что для данной задачи нужно не хранилище документов, а что-то типа apache kafka. И кластер, и наращиваемость, и от вендора независимо, и хранение только добавлением с гарантией записи в несколько источников. Тут и вечное хранилище, и потоки и выборка по интервалам... Ляпота... Но в кафку нужно уметь, да...
Нотариусы, которые хранят кучу сканов 50 лет: выбираем хранилище на следующие лет 20–30