Добавлю к списку еще несколько вариантов реализации объектных СХД: Scality, Cleversafe. Да, у систем своя ниша, принцип работы: данные воспринимаются как объекты, каждая порция со своим хэш адресом, по которому происходит поиск уже записанной информации. Из интересного — Erasure Coding в объектных СХД эта одна из реализаций подхода к избыточности имени Reed-Solomon'а, тот же подход к устройству избыточности и принципу разбиения всего поступающего набора данных, с некими изменениями, применяется в технологии RAID 6. Теория разработана еще в 1960г. :)
Можно еще к выводу: тестируйте свои реальные данные на СХД перед покупкой. Некоторые маркетинговые «фичи» работают только в узком диапазоне данных и смотрите «наперед»: то, что важно сегодня (объем, скорость, функционал) слабо коррелируется с тем набором данных, который будет на ваших СХД через 2-3 года.
А, локальный менеджмент остался, даже лучше стал. Мы писали о нем: habr.com/ru/company/hpe/blog/333800 в разделе Intelligent Provisioning, суть в том, что локально управлять сервером можно и без лицензии, для удаленного управления есть своя лицензия.
Вопрос, наверное, сродни вопросу «Почему затопили станцию МИР».
Superdome X, кстати, был первой аппаратной системой, на которой SAP в своих лабораториях тестировал первые релизы HANA. Далее, он отлично себя показывал в составе аппаратных комплексов под HANA. Но…
Подход Superdome Flex оказывается проще и дешевле, на его основе получаем уже совершенно другие по объемам спецификации под HANA.
Вы правы в том, что всегда нужно считать совокупную стоимость владения, а не только стоимость за ГБ, приведенные примеры показывают, что дедупликация позволяет сэкономить на хранилище, а ниже в статье описываются причины, к этому приводящие.
Из практики многих внедрений OLTP DB как раз-таки лучше сжимают сами DB, включенная компрессия на хранилище не дает дополнительных преимуществ, а иногда даже вредит производительности самой БД. Здесь нужно сравнивать на практике.
Опять же, в силу того, что есть помехи в канале передачи данных — спасает механизм persistent checksum — массив 3PAR не подтвердит запись, если отправленные хостом данные будут отличаться от пришедших на контроллеры массива.
Если приложение подтвердило транзакцию, а массив не успел записать (что в практически невозможно) или записал с ошибкой в силу помех в канале передачи (это уже вполне реально), то в этом случае восстанавливаться из резервной копии. Но приложение всегда ждет пока массив на «том конце» сообщит ок, после этого приложение подтверждает запись.
Нужно проверять хэш суммы записанных данных и того, что было передано.
В 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
Нельзя же всех пользователей и все данные равнять к одним и тем же ссылкам.
Поэтому мы активно используем средства оценки, замера бэкапов, предоставляем оборудование в демо и таким образом вместе с заказчиком определяем необходимые политики бэкапа. В каких-то случаях о дедупликации приходится забыть, но без финансовых потерь для заказчика.
По ссылкам можете конфигурацию StoreOnce прокомментировать и отчеты нам прислать? Может, действительно, в этом случае нужно было систему по-другому настраивать. Сейчас без подробностей оценить тонкое место в производительности сложно.
Superdome X, кстати, был первой аппаратной системой, на которой SAP в своих лабораториях тестировал первые релизы HANA. Далее, он отлично себя показывал в составе аппаратных комплексов под HANA. Но…
Подход Superdome Flex оказывается проще и дешевле, на его основе получаем уже совершенно другие по объемам спецификации под HANA.
Из практики многих внедрений OLTP DB как раз-таки лучше сжимают сами DB, включенная компрессия на хранилище не дает дополнительных преимуществ, а иногда даже вредит производительности самой БД. Здесь нужно сравнивать на практике.
В 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
Ссылка на разъяснение percent increase and decrease: http://www.mathgoodies.com/lessons/percent/change.html
Math is fun)
Поэтому мы активно используем средства оценки, замера бэкапов, предоставляем оборудование в демо и таким образом вместе с заказчиком определяем необходимые политики бэкапа. В каких-то случаях о дедупликации приходится забыть, но без финансовых потерь для заказчика.
По ссылкам можете конфигурацию StoreOnce прокомментировать и отчеты нам прислать? Может, действительно, в этом случае нужно было систему по-другому настраивать. Сейчас без подробностей оценить тонкое место в производительности сложно.
Про рекламу HP Inc (лого HP) — не жалко :)