Как стать автором
Обновить

Комментарии 23

[Сжатие] 10:1 позволяет уменьшить размер хранимых данных (reduction ratio) на 90%, в то время как коэффициент в 50:1 увеличивает этот показатель на 8% и дает 98% reduction ratio (см. график ниже). Но это только 8% разницы…

Вот бы вам зарплату платили по таким формулам!
Курс рубля к доллару 60:1 дает reduction rate 98.3%, но мы вам пересчитали зарплату по курсу 6000 рублей за доллар, который увеличивает reduction rate до 99.98%.
Обратите внимание, это даже больше на целых 1.68%!
Вот держите ваши 30 долларов.

Про зарплату — спасибо)
Ссылка на разъяснение percent increase and decrease: http://www.mathgoodies.com/lessons/percent/change.html
Math is fun)

Вроде бы с пропорциями у меня всегда все ОК было. Посмотрел вашу ссылку и понял, что в этом мире пока ничего не изменилось. Имеем 100Tb исходных данных. При коэффициенте дедупликации 10:1 получаем соотношение 10/1=100/X, т.е X=100*1:10=10Tb хранимых данных. Берем коэффициент дедупликации 50:1 и получаем соотношение 50/1=100/X, т.е. X=100*1/50=2Tb хранимых данных. Итого ровно в 5 раз меньше требуется пространства для данных на оборудовании "второго" вендора по сравнению с "первым". А дальше вся ваша "магия" чисел сводится к тому, что мы будем считать за 100%.


Клиент платит за реальный дисковый объем. Т.е. нужно купить или 10Tb дискового пространства одного вендора, или 2Tb другого вендора (допустим при примерно равной стоимости "за Tb"). Считаем экономию денег заказчика, ваш percent decrease = (10 — 2) / 10 = 0,8 = 80%. Т.е. взяв оборудование "второго" вендора с коэфициентом дедупликации 50:1 мы "внезапно" получаем снижение в 5 раз требований к реальному дисковому пространству и экономию денежных средств заказчика на 80%.


Ваше утверждение о 8% так же легко подтвердить математически, приняв за 100% размер исходных данных, которые нужно хранить, те. те же 100Tb. Для 10:1 получаем percent decrease = (100 — 10) / 100 = 0.9 = 90%. Для 50:1 получаем decrease = (100 — 2) / 100 = 0.98 = 98%.


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

Как с сохранностью данных? Если пострадает несколько килобайт, а то и мегабайты обычных данных, вред будет зачастую не самым большим, пострадают только поврежденные участки нескольких файлов. А что будет с данными подвергшимися дедупликации?
Нужно проверять хэш суммы записанных данных и того, что было передано.
В 3PAR, например, осуществляется постоянная проверка целостности данных по нескольким направлениям (persistent checksum):
• CRC/parity checks on all internal CPU and serial buses
• Control cache ECC checks
• Data cache ECC checks
• PCIe I2C bus CRC/parity checks
• HPE 3PAR ASIC connection CRC/parity checks
• Protocol (Fibre Channel/iSCSI/FCoE) CRC checks at the frame level (hardware accelerated via the HPE 3PAR ASICs)
• Disk devices CRC checks at the block level, occurring once the data has landed and throughout the lifecycle of the data once it’s stored to disk
Подробнее https://www.hpe.com/h20195/v2/getpdf.aspx/4aa3-3516enw.pdf
Данные повредились, скажем скачок по питанию + последующее выключение ИБП (редко, но бывают в жизни подобные случаи и ИБП не всегда помогает) они как-то восстанавливаются или только резервная копия?
Если приложение подтвердило транзакцию, а массив не успел записать (что в практически невозможно) или записал с ошибкой в силу помех в канале передачи (это уже вполне реально), то в этом случае восстанавливаться из резервной копии. Но приложение всегда ждет пока массив на «том конце» сообщит ок, после этого приложение подтверждает запись.
Опять же, в силу того, что есть помехи в канале передачи данных — спасает механизм persistent checksum — массив 3PAR не подтвердит запись, если отправленные хостом данные будут отличаться от пришедших на контроллеры массива.
Я беру хуже ситуацию. Описывалась когда-то, всплеск напряжения ИБП пропустили, БП справились, но ИБП тут же вырубились, на диске возникла ошибка, уже на записанном месте к примеру. Какие есть механизмы восстановления такой информации? Не во время записи, а из-за вины внешних фаткоров.
К примеру, у конкурентов довольно давно используется так называемая NVRAM, которая энергозависима и питается от обычного мини аккумулятора. Черене nvram проходит вся запись на диски. В случае отключения питания все данные на дисках валидны, потом при включение питания остатки скидываются на диск и все данные консистентны.
Это опять контроль во время записи. Начнем с другого края. На винчестере появилась серия бедов (не нужно писать про самоконтроль, все равно бывает), в бедах и данные нужные для дедупликации. Какие механизмы восстановления имеются?
Рэйд же.
Вот с рейда (самый простой рейд зеркалом), 20 минут назад это было.
Запись 2 из 3: Логические кластеры [0x4857bc, 0x4857c0) принадлежат как файлу…
Запись 3 из 3: Неиспользуемые метаданные файла, помеченные как используемые… обнаружено непредвиденное повреждение…

И таких записей с десяток за два дня образовалось по неведомой причине. Поэтому и интересует есть ли механизмы восстановления при повреждении данных необходимых для дедупликации данных? Или при использовании дедупликации с данными можно попрощаться в такой ситуации?
Сейчас пытаюсь понять что вызывает такие проблемы.
Привет!
По-моему, вы смешиваете два сценария — ошибку записи в результате помех в канале и нарушение целостности данных из-за исчезновения питания (что-то дестейджилось на диск, что-то — нет). Защиту кэш-памяти сейчас обеспечивают все производители, не только конкуренты :)
В разделе «У компании HPE есть набор утилит и сайзеров» первая и третья ссылка битые.
Спасибо, поправили

Хранилище с полезной ёмкостью в 50TiB обходится нам, допустим, в 150 000$.
Без дедупликации мы сможем 50TiB своих данных. При коэффициенте дедупликации 10:1 мы сможем хранить 500TiB данных. И нам это по-прежнему будет стоить 150К$. При коэффициенте дедупликации 50:1 мы уже будем хранить 2500TiB данных
В первом случае мы тратим 3000$ за TiB, во втором 300$, а в третьем всего 60$.
Так к чему говорить про разницу в reduction ratio в 8%? Клиент считает свои деньги и в третьем случае получит возможность хранить в 5 раз больше данных.


Дедупликация, компрессия, уплотнение. HPE поддерживает что-то кроме дедупликации?
Кто из вендоров уплотнением называет дедупликацию+компрессию?
Есть данные для которых хорошо работает дедупликация — виртуальные среды, есть данные для которых лучше сработает компрессия — OLTP DB. И большинство извстных мне вендоров эти понятия разделяют.


Рис 6. Зависимость коэффициента дедупликации от количества виртуальных машин в пуле и размеров блока данных.
Немного бесполезный и вводящий в заблуждение график. Судя по тому, что заметный рост коэффициента дедупликации заметен при размере блока 16К и кратных ему, речь идёт про HP 3Par. При этом другие вендоры, использующие другую гранулярность при дедупликации могут получить другие результаты.
Вы правы в том, что всегда нужно считать совокупную стоимость владения, а не только стоимость за ГБ, приведенные примеры показывают, что дедупликация позволяет сэкономить на хранилище, а ниже в статье описываются причины, к этому приводящие.

Из практики многих внедрений OLTP DB как раз-таки лучше сжимают сами DB, включенная компрессия на хранилище не дает дополнительных преимуществ, а иногда даже вредит производительности самой БД. Здесь нужно сравнивать на практике.

Компрессия на хранилище часто доступна бесплатно в отличии от компрессии в БД. Включение компрессии на хранилище и выключение на самом сервере БД позволяет тратить ресурсы CPU сервера БД на более нужные операции. Есть вендоры, у которых компрессия на хранилище не только не замедляет работу всего решения в целом, но и в некоторых случаях даёт прирост в производительности.

Коэффициенты дедупликации на основном массиве такие же, как и на массиве с резервными копиями.

Если не ошибаюсь, у IBM вся линейка Spectrum Storage использует один движок для компрессии.
Много интересного, но про ряд подводных камней не расскали.
Например, про скорость дедупликации.
Тестовый стенд DL380p G8 12 ядер 3.5ГГц, 64ГБ, 6 SSD RAID 10, 10GbE с единственной виртуальной машиной, на которой развернута всего 1 база SQL на 1 терабайт.
Бэкапим с помощью Symantec Backup Exec 15 на
StoreOnce VSA 4 ядра 3ГГц, 16ГБ, 2 SSD RAID 0 (только для теста), 10 GbE.
Производительность SSD сервера 4ГБ/с
Производительность SSD VSA 1ГБ/с
Никакой нагрузки кроме теста бэкапа нет.
Надо забэкапить только базу SQL.
Как вы думаете, какая будет скорость бэкапа?
Упрется в сеть 10 гигабит?
Увы нет, скорость бэкапа составила 200-300 килобайт в секунду. База на 1 терабайт будет дедуплицироваться…
Ваши предположения?
1 час?
За ночь?
Точно за выходные управится?
Я вас сильно удивлю. Бэкап на дедуплицированное хранилище займет около 2 месяцев! У меня вначале вообще показывало один год. Естественно я не стал ожидать.
Специфика продукта такова, что дедупликация — однопотоковый процесс (странно в 2016-м году). Что чтобы иметь заявленные скорости, нужно разбивать бэкап на множество одновременных заданий, чтобы загрузить все ядра. Т.е. если вы бэкапите кучу виртуалок и раньше у вас было одно задание, которое их по очереди делает, то сейчас нужно создавать задание на каждую и желательно в нем еще кучу подзаданий (отдельно система, отдельно SQL, отдельно папку 1 в шаре 1, отдельно папку 2 в шаре 1 и т.д. Но вы же знаете как влияет лень и сложности на человека…
Выход? Есть.
Нужно бэкапить на отдельное хранилище без дедупликации и уже с него не спеша переносить данные на дедуплицированное хранилище.
Минусы? Тоже есть.
Нужно иметь (и платить) сразу за оба хранилища.
Может быть дедупликация не выгодна с финансовой точки зрения?
StoreOnce 3540 на 24TB стоит в РФ около 15 000$ (миллион рублей).
За такие деньги можно купить
— двухсокетную платформу 4U на 36 дисков
— процессор 8 ядер
— 128 гиг оперативки
— 12 дисков по 10 терабайт
— сетевушку 10GbE
— лицензию на гипервизор и ОС Windows для SBE

В итоге за эти же деньги мы имеем гарантию на железо, гарантию записать 100 терабайт бэкапов в RAID 5 в группах от 3 до 6 дисков. Ну и самое главное — база бэкапится за 1-3 часа и реально упирается в сеть 1GbE (поэтому использую 10GbE). Система легко масштабируется еще в 2 раза.
Более того, можно использовать дедупликацию самого Symantec и получить как минимум не хуже результаты.

Далее самое интересное. Допустим мы все-таки забэкапили. И тут вам надо поднять эту базу.
С дедуплицированного хранилища восстановить 1 терабайт займет недели. С моего решения — менее часа.

ОК, скажете вы, мне не нужна скорость, хочу дешево хранить и не пользоваться бэкапами
Пожалуйста. Тот же SBE умеет складывать в облако и там еще дедуплицировать.
Например, хранение в Google Storage Nearline 100 терабайт стоит около 1000 долларов в месяц. Т.е. только железо, без развертывания, аренды стойки, питания, охлажнения, обслуживания стоит как 15 месяцев использования облака сразу на 100 терабайт, что не бывает.

Все идет к облаку. Но все-таки есть применение для StoreOnce. Например, вы купили Veeam, а там дедупликация только в пределах одного задания и места бэкапы занимают очень много. Вот тут вам и поможет StoreOnce.

Интересно будет сравнить дедупликацию StoreOnce vs Windows Server 2016. Жду статью.

Буду рад помочь с консультацией по бэкапу, дедупликации, облачному хранению, серверам HP.

Подскажите почему Raid5, а не Raid6? Прикидывали сколько времени займет ребилд одного вышедшего из строя диска, заполненного хотя бы на 50-70%? На моей памяти 1Tb диски могли ребилдится по 12 часов и более. За это время вероятность потерять второй диск в том же Raid сильно возрастает. Учитывая то, что партия скорее всего у дисков одна и нагрузка на оставшиеся в живых диски высокая в процессе ребилда.


Ну и с облаками в нашей стране, особенно в регионах, основная проблема это ширина канала. А отсюда и скорость бэкапа/восстановления этих данных. Это даже если не брать в расчет стоимость (де-факто абонентскую плату).

Я не только считал, но и делал. Проводил расширение емкости путём последовательной замены дисков с 2 ТБ на 4TB, и 4 ТБ на 8 ТБ.
Под нагрузкой ребилд 1 ТБ занимает от суток до недели. Без нагрузки — сутки.
Замена 10 дисков 4TB в одной группе в фоновом режиме заняло почти квартал.
RAID 6 использовал в системе с большим количеством дисков в группе. Минус — низкая скорость записи из высокого пенальти. Если скорость бэкапа не является критичной, то да -RAID6.
Делал много раз так, ибо эксплуатирую множество таких систем.
У меня стоят такие решения в 5 регионах РФ от Краснодара до Хант. Проблем с Инетом нет. Даже больше. Для юр. лиц он там дешевле чем в Москве. В Астрахани вообще чуть ли не домашний тариф.
Заливаю в неделю 1 терабайт в облако без особых проблем.
Плюс решения — не хранить важные бэкапы на одном сайте (ЦОДе) с данными.
У одного клиента в был потоп и затопило серверную. Бэкап дублировался в облако. Пришлось поднимать ещё раз SBE (целый квест с ключами шифрования, базой данных с набором резервного копирования). А дальше подняли в арендованном ЦОДе на IaaS самое важное. Сервера на 100 000$ на свалку. Хотя потом что-то со страховкой вернули обратно.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий