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

SDS vs традиционные СХД: почему мы редко применяем программно-определяемые хранилища?

Время на прочтение4 мин
Количество просмотров4.2K
Всего голосов 21: ↑18 и ↓3+17
Комментарии16

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

Аааатличные картинки. :) Особенно с водосточной трубой. Ну и за пост спасибо. Я как-то не задумывался, что СХД выгоднее хотя бы с точки зрения плотности.

НЛО прилетело и опубликовало эту надпись здесь

А на сколько Ceph получился дороже, интересно? И по каким параметрам было сравнение (IOPS, емкость, что-то еще)?

Если смотреть на Гугл с Амазоном, то на сколько могу судить у них есть локальные диски (быстрые) и видимо SDS. У Mail, я так понял, активно используется Ceph для продажи клиентам.

Есть ли ограничения на рассуждения о высокой стоимости SDS? Например "сказанное справедливо для продажи классической виртуализации, когда важны IOPS, а для холодного отказоустойчивого хранения не справедливо".

В стоимости железа цена сопоставима, ну плюс минус. Но если брать стоимость содержания и обслуживания. Персонал, тестовые кластера и т.п. Тут стоимость, при учете малого и среднего размера кластера SDS, ниже у СХД.

При больших и очень больших размерах инсталляций преимущество Ceph увеличивается.

Поэтому сказанное справедливо для малых и средних инсталляций, с высоким уровнем IOPS и с высокими требованиями к надежности.

Стоимость решения считается не от стоимости оборудования и поддержки.

Стоимость решения считается от стоимости информации. И там как по учебнику, сколько вы можете потерять информации и сколько вы можете допустить простой при восстановлении.

Проще говоря, если в вашей фирме все продажи идут через сайт, а падение сайта остановит работа склада, менеджеров, водителей, бухгалтерии... И убытки будет в 20 миллионов в сутки. То вам уже все равно сколько стоит сервер, программа, поддержка, персонал.

И строить решение на прокмокс и ceph можно при условии что стоимость информации у вас равна зарплате админа, в 30-40 тысяч. В случаи ЧП просто его уволите и наймете нового

В статье хорошо бы упомянуть,что данная статья актуальна в расчете того что используются коммерческие SDS,стоимость лицензий которых приближается к стоимости железных хранилок.

Совершенно верно.
Но и открытые SDS, при высоких требованиях к отказоустойчивости, начинаю дорого стоить. В первую очередь это персонал и тестовые среды.

для VSAN персонал тоже нужен,помню сколько в первых версиях было проблем у них,не знаю как сейчас,но раньше и там не все так просто...

Когда у тебя публичное облако на VMware то персонал по vSAN идет сразу из коробки))))

Когда у тебя публичное облако на VMWare, к тебе приходят <рестрикции со стороны вендора вызванные текущей политической коньюнктурой>.

Используем гиперконвергентную архитектуру на базе Proxmox VE + Ceph.

https://pve.proxmox.com/wiki/Hyper-converged_Infrastructure

Всё хорошо - реально (!), только если помнить главный минус любой SDS системы что сеть - это "не быстро". Это так же автоматически означает, что дисковый I/O у виртуальных машин никогда не может быть лучше поверх классических СХД. Вечно стараться приближаться к их показателям IOPS, latency и т.д., но никогда не достигать. Лучше всего это расписано в статье

https://yourcmc.ru/wiki/index.php?title=Производительность_Ceph

На практике же, если задача требует сервер с хорошими показателями на запись, то просто такое решение развёртывается на отдельных физических серверах. Другими словами, не зацикливаться на SDS и не решать ею абсолютно все вопросы.

Так как Proxmox VE + Ceph - это open source, дающий shared storage, то в целом получаешь много админских плюшек (переезд в онлайн ВМ с ноды на ноду, "ночной администратор" High Availability) и даром, не считая своих знаний и труда.

В SDS Ceph есть возможность создавать пулы типы erasure code, что оптимально под надёжное хранение холодных данных с минимальными "потерями" дискового пространства. Такое решение тоже имеет право на существование.

https://docs.ceph.com/en/latest/rados/operations/erasure-code/

не могу удержаться, хоть и не пикабуха

Hidden text

НЛО прилетело и опубликовало эту надпись здесь

Вообще, у вас какие-то странные вещи написаны про гиперконвергентность. В частности вот тут:

В один сервер 1U, как правило, можно установить до 8 дисков (реже до 12) формата 2,5-дюйма. Таким образом, мы получаем 6 или 10 дисков (2 диска уходят на кеш) на 1U. На 2U мы получим 12 или 20 соответственно. Тем временем, дисковая полка или система хранения может вместить до 36 дисков, занимая те же самые 2U

Суть гиперконвергентности в том, что вы размещаете диски в уже имеющемся оборудовании (как правило, в гипервизорах). И если у вас есть 15 гипервизоров, то у вас есть бесплатное место на 90 дисков внутри этих гипервизоров. В то время как с СХД вам как раз и потребуется 6U на три полки.

А если у вас еще и какая-нибудь любимая адептами классических СХД FC SAN, то вам потребуется дополнительная коммутация под неё, еще пара юнитов под FC фабрики - в то время как гиперконвергентное решение будет работать поверх то сети которая уже есть.

Так что всё намного интересней если говорить именно о гиперконвергентных решениях а не просто об SDS.

Судя по статье, такое ощущение что сейчас 2008 год. И мы вкатывается в ИТ с помощью изоленты и windows 98

Что вы имеете в виду?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий