Comments 8
Вы не учитываете того факта, что описанная система предназначена в первую очередь для резервного копирования. А например при ежесуточном резервном копировании сегодняшняя и вчерашняя копия отличаются друг от друга обычно на какие-то еденицы процентов. Т.е. бОльшая часть данных между ними не отличается. А значит дедупликация позволяет прилично сэкономить дисковое пространство при хранении этих копий.
Что произойдет при оверповиженинге и физическом заполнении системы на 100%? Тут нужно скорее у вендора спросить. Но могу предположить, что файловые системы созданные на кластере перейдут в Read-only режим и ваш следующий бэкап не будет записан в кластер, пока вы его не расширете новыми нодами или не удалите часть старых данных или целиком файловых систем.
P.s. по ряду причин я не сторонник использования дедупликации для первичных данных, что ныне вошло в тренд у всех производителей современных СХД.
Я тоже, потому мой вопрос и возник. Обычно у вендоров есть специальное двоемыслие для таких вещей: "дедупликация сохраняет вам деньги! посмотрите на эту волшебную 99% экономию места на миллионе пустых файлов", а потом "в случае оверпровиженинга это ваша обязанность следить за свободным местом, чтобы система стабильно работала мы рекомендуем иметь в резерве 100% провиженного места".
При этом тактично обходится вопрос, какая там дедупликация и какова вероятность получить предъявление оверпровиженинга (понятно, что вендор может сказать, что тут только бэкапы, и никакода дедуплицируемые данные не становятся модифицированными).
Ведь проблема в чём — вот у нас дедупликация 500%. А потом в файлы пишут, причём разное, и оказывается, что откуда-то надо взять и вынуть из воздуха 200% от места хранилки. После чего вендор это и начинает про "резервирование".
Из моего опыта (а я занимаюсь СРК примерно с 2002 года) в природе гораздо чаще встречаются ухокрылые администраторы, которые либо не настраивают уведомления о событиях на СХД, либо игнорируют их, что заканчивается плавным переполнением системы с последующим переходом её в read-only и последующим спринтом от разъярённых пользователей, которым срочно надо было восстановить совершенно нечаянно удалённый самый важный файл.
Думаю понимаете правильно. Так как внешние интерфейсы, в том числе, могут находиться и в разных немаршрутизируемых между собой подсетях или и вовсе в физически в разделенных сетях. Так что по ним восстанавливать защиту данных может быть физически не возможно. Они нужны именно для подлючения серверов/клиентов к системе хранения.
Если же вы намекаете на скорость internal интерфейсов, то мне тоже немного странно, что в настоящее время там до сих пор используется 1Gbit. С другой стороны, как я упоминал в статье, реальная производительность на запись 12 SATA дисков в одной ноде упирается в 450MB/s и восстанавливать нам нужно уже дедуплицированные и сжатые данные. А значит текущего количества internal интерфейсов должно хватать. Опять же в общем случае восстановление будет идти не с одной ноды на какую-то другую ноду и упираться в эти самые 450MB/s, а в режиме "от многих нод на многие ноды" и по этому восстанавливаться защита данных должна относительно быстро.
Технический обзор систем NEC HYDRAstor HS8 и не только