Comments 44
57-ю терабайтами… всего 2U
мегабакс в 2U?
У кого-нибудь на памяти есть девайсы такой замечательной ёмкости?
В деньгах или по объему?
По объему — ничего сверхъестественного, 12х 10ТБ если хардами уже достаточно давно в 2U лезет без всяких извращений.
Ну или вот: http://www.storagereview.com/seagate_announces_60tb_sas_ssd
60 ТБ в 3,5".
Сейчас гораздо веселее становится вопрос интерконнектов — между ли узлами, между сервером и хранилищем и т.п.
Что толку с адски низкой латентности NVMe и подобных девайсов, если она будет съедена сетью хранения данных где-то по дороге?
Как-то так…
По объему — ничего сверхъестественного, 12х 10ТБ если хардами уже достаточно давно в 2U лезет без всяких извращений.
Ну или вот: http://www.storagereview.com/seagate_announces_60tb_sas_ssd
60 ТБ в 3,5".
Сейчас гораздо веселее становится вопрос интерконнектов — между ли узлами, между сервером и хранилищем и т.п.
Что толку с адски низкой латентности NVMe и подобных девайсов, если она будет съедена сетью хранения данных где-то по дороге?
Как-то так…
Проблемы с производительностью из-за неэффективности жестких дисков пытаются решать несколькими способами, в частности,… или RAID (redundant array of independent disks — избыточный массив независимых дисков)
RAID не решает проблемы с производительностью HDD, он их создает, так как задача RAID — не повышение производительности, а сохранение информации в случае отказа одного или более HDD за счет дублирования этой информации. соответственно, у каждого RAID есть RAID-пенальти — фактор, который показывает отношение количества фактических операций записи на одну операцию, прилетевшую на массив. Для RAID5 фактор пенальти равен 4 — прилетела одна запись, а реально записали 4 раза.
Помимо пенальти (на запись) там есть такой фактор как количество шпинделей, так что еще как решает, бенчмарки хотя бы посмотрите прежде чем такое писать
я вас, если честно, не понял.
во-первых — если вы ссылаетесь на какие то бенчмарки — давайте сразу ссылки, это просто правило хорошего тона, чтобы мы могли говорить о одном и том же.
во-вторых — количество шпинделей — один HDD это один шпиндель, многошпиндельных HDD я не видел. Самыми быстрыми будут массивы JBOD, они же RAID0, он не избыточен, и его нельзя считать полноценным RAID.
Далее по скорости и по убыванию — RAID10, RAID5, RAID6.
Для примера — возьмем СХД с 24 дисками SFF 300 Гб 15 000 об.мин., отношение операций чтение/запись — 70/30, условия записи стандартные — блоками по 4 кб.
показатели производительности:
RAID0 = 4080 iops
RAID10 = 3600 iops
RAID5 = 2463 iops
RAID6 = 1872 iops.
При этом доступное место — зависимость обратная:
RAID10 = 3215 Гб
RAID5 = 5626 Гб
RAID6 = 5894 Гб
RAID0 = 7200 Гб.
цифры даны примерные, округленные.
во-первых — если вы ссылаетесь на какие то бенчмарки — давайте сразу ссылки, это просто правило хорошего тона, чтобы мы могли говорить о одном и том же.
во-вторых — количество шпинделей — один HDD это один шпиндель, многошпиндельных HDD я не видел. Самыми быстрыми будут массивы JBOD, они же RAID0, он не избыточен, и его нельзя считать полноценным RAID.
Далее по скорости и по убыванию — RAID10, RAID5, RAID6.
Для примера — возьмем СХД с 24 дисками SFF 300 Гб 15 000 об.мин., отношение операций чтение/запись — 70/30, условия записи стандартные — блоками по 4 кб.
показатели производительности:
RAID0 = 4080 iops
RAID10 = 3600 iops
RAID5 = 2463 iops
RAID6 = 1872 iops.
При этом доступное место — зависимость обратная:
RAID10 = 3215 Гб
RAID5 = 5626 Гб
RAID6 = 5894 Гб
RAID0 = 7200 Гб.
цифры даны примерные, округленные.
показатели производительности:
…
RAID10 = 3600 iops
...
теперь сравните это с 200 iops одного диска. Всё еще продолжаете утверждать что RAID не решает проблему производительности?
во-вторых — количество шпинделей — один HDD это один шпиндель, многошпиндельных HDD я не видел.
это вообще без комментариев
в примере приведены диски SFF 300 Гб 15 000 оборотов в минуту.
статистика для таких дисков с интерфейсом SAS — 188 — 203 iops, реальные показатели в установившемся режиме — 170, максимально 180 iops, ни о каких 200 речь не идет. Я считал, что показатель диска — 170.
но давайте пересчитаю с предположением, что с диска можно получить 200 iops, получаем:
RAID0 = 4800 iops
RAID10 = 3692 iops
RAID5 = 2526 iops
RAID6 = 1920 iops
и — интересно на бенчмарки посмотреть. вы про SPС-тесты?
статистика для таких дисков с интерфейсом SAS — 188 — 203 iops, реальные показатели в установившемся режиме — 170, максимально 180 iops, ни о каких 200 речь не идет. Я считал, что показатель диска — 170.
но давайте пересчитаю с предположением, что с диска можно получить 200 iops, получаем:
RAID0 = 4800 iops
RAID10 = 3692 iops
RAID5 = 2526 iops
RAID6 = 1920 iops
и — интересно на бенчмарки посмотреть. вы про SPС-тесты?
170, максимально 180Да какая разница? Я вижу разницу больше чем на порядок с одним диском, вы утверждаете что производительность не улучшается. Не вижу повода для обсуждения. А то что объем уменьшается — ну да, у каждого решения своя цена, но это не значит, что решения нет.
давайте еще раз — мы берем HDD с производительностью 200 iops, берем таких дисков 24 штуки (это удобное число, потому что можно составить разные комбинации RAID-групп), считаем производительность:
RAID0 = 4800 iops — производительность этой группы — 100% от суммарной производительности дисков, отказоустойчивость равно нулю, т.е. при выходе из строя одного любого диска мы теряем всю информацию на массиве
RAID10 = 3692 iops — производительность этой группы — 77 % от суммарной производительности дисков, отказоустойчивость равна одной группе (есть варианты групп 1+1, 2+2 и так далее).
RAID5 = 2526 iops — производительность этой группы — 53 % от суммарной производительности дисков, отказоустойчивость равна одному диску в группе группе (есть варианты групп 3+1, 4+1 и так далее).
RAID6 = 1920 iops — производительность этой группы — 40 % от суммарной производительности дисков.
RAID0 = 4800 iops — производительность этой группы — 100% от суммарной производительности дисков, отказоустойчивость равно нулю, т.е. при выходе из строя одного любого диска мы теряем всю информацию на массиве
RAID10 = 3692 iops — производительность этой группы — 77 % от суммарной производительности дисков, отказоустойчивость равна одной группе (есть варианты групп 1+1, 2+2 и так далее).
RAID5 = 2526 iops — производительность этой группы — 53 % от суммарной производительности дисков, отказоустойчивость равна одному диску в группе группе (есть варианты групп 3+1, 4+1 и так далее).
RAID6 = 1920 iops — производительность этой группы — 40 % от суммарной производительности дисков.
Давайте еще раз с вашего утверждения:
Утверждение ложно (о чем я и толкую) поскольку для повышения IOPS (для потребностей СУБД например) один терабайтный диск можно заменить на массив (RAID10) из двух десятков мелких дисков и получить IOPS на порядок больше чем было. Что собственно люди и делают, и о чем собственно автор и пишет в сабжевой статье.
RAID не решает проблемы с производительностью HDD, он их создает, так как задача RAID — не повышение производительности, а сохранение информации в случае отказа одного или более HDD
Утверждение ложно (о чем я и толкую) поскольку для повышения IOPS (для потребностей СУБД например) один терабайтный диск можно заменить на массив (RAID10) из двух десятков мелких дисков и получить IOPS на порядок больше чем было. Что собственно люди и делают, и о чем собственно автор и пишет в сабжевой статье.
я понял, о чем вы. ваш подход формально верен, но при проектировании СХД основным фактором является стоимость за iops или за время отклика, а не за объем — он обычно набирается как довесок к требуемым параметрам.
А автор пишет, простите, маркетинговую глупость, о чем я и говорю — например — «Третьим традиционным способом повысить производительность HDD является замена JBOD на RAID.»
RAID 0 — дисковый массив повышенной производительности с чередованием, без отказоустойчивости. Строго говоря, RAID-массивом не является, поскольку избыточность (Redundancy) в нём отсутствует. Все остальные массивы, при прочих равных, дают снижение производительности.
А автор пишет, простите, маркетинговую глупость, о чем я и говорю — например — «Третьим традиционным способом повысить производительность HDD является замена JBOD на RAID.»
RAID 0 — дисковый массив повышенной производительности с чередованием, без отказоустойчивости. Строго говоря, RAID-массивом не является, поскольку избыточность (Redundancy) в нём отсутствует. Все остальные массивы, при прочих равных, дают снижение производительности.
А автор пишет, простите, маркетинговую глупость, о чем я и говорю — например — «Третьим традиционным способом повысить производительность HDD является замена JBOD на RAID.»Автор такого не писал.
Ctrl+F и найти эту фразу, либо раздел «Недостатки традиционных путей обхода проблемы со скоростью HDD», начало третьего абзаца
Ок, нашел. Но почему глупость? Всё так и есть, к тому же менять JBOD именно на RAID0 автор вроде не призывал
Все остальные массивы, при прочих равных, дают снижение производительности.Минуточку, так вы считаете что RAID0 это то же самое что JBOD?
JBOD — дисковый массив, в котором единое логическое пространство распределено по жёстким дискам последовательно. Однако в некоторых RAID-контроллерах режимом «JBOD» назван режим, при котором контроллер работает как обычный IDE- или SATA-контроллер, не задействуя механизмы объединения дисков в массив, то есть в таком случае каждый диск будет виден как отдельное устройство в операционной системе. Этот факт указывает на то, что термин JBOD как режим функционирования дисков ещё окончательно не устоялся.
Так да или нет? Если да — то вы не понимаете что такое JBOD, если нет — тогда ваше утверждение
Все остальные массивы, при прочих равных, дают снижение производительности.— ложно
я говорю о JBOD в терминологии конкретно СХД IBM — его так же можно назвать spanned volume, т.е. информация пишется на все диски последовательно, без избыточности.
терминология IBM не противоречит общепринятой. В случае JBOD информация пишется со скоростью того единственного диска, на который она в данный момент пишется. Так что любой RAID из 24 дисков даже на запись будет работать быстрее JBOD, не говоря уже о чтение.
Видимо нащупали то место, которое мы называем одинаково, но вкладываем разные сущности, для меня это не так —
В случае JBOD информация пишется со скоростью того единственного диска, на который она в данный момент пишется.. в настройках всех RAID контроллеров, с которыми я лично работал, и СХД — режим JBOD это название RAID0.
> Самыми быстрыми будут массивы JBOD, они же RAID0,
Интересное кино. Это где такое извращение?
JBOD как отдельные диски — видел.
JBOD как простое объединение пространства дисков (сначала все пространство одного диска, потом другого и т.д) — видел.
JBOD как RAID0 (объединение пространства с чередованием блоков) — первый раз о таком читаю.
Интересное кино. Это где такое извращение?
JBOD как отдельные диски — видел.
JBOD как простое объединение пространства дисков (сначала все пространство одного диска, потом другого и т.д) — видел.
JBOD как RAID0 (объединение пространства с чередованием блоков) — первый раз о таком читаю.
«This video is unavailable» — по всем роликам
По сюжету фильма три американских космонавта отправляются на Луну
А, всё-таки не летали:)
Понятно что SSD диски (да ещё и в массиве, они ведь в СХД тоже в каком либо RAID массиве задействованы?) сильно быстрее HDD…
Никто и не сомневается…
Вопросы:
1. Как с надёжностью работы SSD при повышенной температуре? Были сведения, что надежность хранения данных при некоторой, достаточно низкой температуре очень сильно снижается… ссылки не подскажу, в гугле есть)
2. Сравнение стоимости примерно одинаковых СХД на HDD и SSD можете привести? очень сильно подозреваю, что стоимость также в РАЗЫ отличается!
Никто и не сомневается…
Вопросы:
1. Как с надёжностью работы SSD при повышенной температуре? Были сведения, что надежность хранения данных при некоторой, достаточно низкой температуре очень сильно снижается… ссылки не подскажу, в гугле есть)
2. Сравнение стоимости примерно одинаковых СХД на HDD и SSD можете привести? очень сильно подозреваю, что стоимость также в РАЗЫ отличается!
Легче, чем пересмотреть свои коды и вырезать из них то, что никакого отношения к выполнению задачи не имеет, построить кэш по ключам или вообще раскинуть мыслью перед тем как реализовывать продукт. Живы методы подключения Фреймворка, библиотеки из-за того, что вам нужна процедура в 2 строчки из них. Повсеместное логирование, удваивающее нагрузки на некоторые типы задач. Неплохо, чтобы задачу ставил конечный потребитель, а не тот, кто этим сервисом никогда в жизни не пользовался и не планирует, а решал её непосредственно конечный программист для себя сам, работая прямо с клиентами. Сперва используете xml с одному Богу ведомой избыточностью, парсите всё это с каждой стороны в нормальный код, готовыми библиотеками на языках, далёких от совершенства, скомпилированных несколько лет назад, что не поддерживают ни последних, ни предпоследних технологий, а после этого добавим скорости ещё?
Один простой вопрос, на который я как-то не вижу ответа ни у кого.
Вот, допустим, вы правда умеете миллион IOPS. Допустим, вы говорите про миллион IOPS чтения стандартными для типовой файловой системы блоком 4Kбайт. Это означает, что СХД создает трафик в направлении сервера, через свой интерфейс, в объеме:
1 000 000 х 4096 х 8 = 32 768 000 000 бита в секунду, что равно примерно 30,5 гигабит в секунду. Что за интерфейс вы используете, по которому сервер может «высосать» из СХД больше 30 гигабит в секунду?
И что будет дальше, с приходом NVMe и Xpoint?
Вот, допустим, вы правда умеете миллион IOPS. Допустим, вы говорите про миллион IOPS чтения стандартными для типовой файловой системы блоком 4Kбайт. Это означает, что СХД создает трафик в направлении сервера, через свой интерфейс, в объеме:
1 000 000 х 4096 х 8 = 32 768 000 000 бита в секунду, что равно примерно 30,5 гигабит в секунду. Что за интерфейс вы используете, по которому сервер может «высосать» из СХД больше 30 гигабит в секунду?
И что будет дальше, с приходом NVMe и Xpoint?
PCI express же
https://habrahabr.ru/company/hostkey/blog/271661/
https://habrahabr.ru/company/hostkey/blog/271661/
Разве PCI express можно использовать в качестве интерфейса для SAN? Сколько у этой шины максимальная дальность передачи и число линий в потенциальном кабеле?
Ну если считать это 2U SAN — клиентам можно раздавать через линкагрегации 10G ethernet. Клиентов то много, не одному же клиенту 30G обязательно чтоб влезло
С учетом, что уже сегодня бытового уровня (!) флэшка на терабайт (два самсунга по 512) дает больше, чем помещается в 10G, то как-то не видится мне тут будущего. Похоже SAN естественным образом пришел к своему концу.
А насчет «один клиент не прожует» — один может и не прожует (хотя SAP HANA и прочие memory-allocated db уже готовы поспорить с этим) но SAN-то это для множества клиентов. И все они упрутся в интерфейс СХД. Все, амба.
А насчет «один клиент не прожует» — один может и не прожует (хотя SAP HANA и прочие memory-allocated db уже готовы поспорить с этим) но SAN-то это для множества клиентов. И все они упрутся в интерфейс СХД. Все, амба.
Ну есть и 100GbE для самых жадных, только повторюсь зачем? SAN не для того делают чтоб одному клиенту всю полосу отдать. А по 10GbE на сервер (да еще и агрегацией, да еще и по несколько VM на каждом сервере) и несколько серверов запросто утилизируют SAN'овские ресурсы не выходя за ограничения 10GbE
100G еще в реальности нет. По крайней мере 100G в DC не вопрос ближайшего будущего, просто по причине запредельной цены решения.
А устройство, которое уже положит напрочь своим трафиком даже и 100G — есть, это пресловутый Xpoint, котоый Intel и Micron нам обещают уже практически завтра.
Вот и вопрос: SAN — все?
Я лично вижу во flash тупик для SAN как архитектурной идеи. Но может я чего-то не вижу?
А устройство, которое уже положит напрочь своим трафиком даже и 100G — есть, это пресловутый Xpoint, котоый Intel и Micron нам обещают уже практически завтра.
Вот и вопрос: SAN — все?
Я лично вижу во flash тупик для SAN как архитектурной идеи. Но может я чего-то не вижу?
Я что-то не пойму, с чего это SAN всё? Что вы предлагаете ей на замену? Вот мне шаред сторедж к кластеру подключить надо. 40G агрегация (из 4 шт 10GbE) на каждую ноду мне за глаза достаточно, SAN — то что мне нужно, почему он всё? Потому что Xpoint? Так его всё равно в лучшем случае через PCIe подключать будут в СХД. И случится она не завтра
Я пока ничего тут не «предлагаю на замену», я спрашиваю, правильно ли я вижу ситуацию.
SAN появился, технически, потому, что канал передачи данных, например FC, был заведомо быстрее одного отдельного, или даже группы объединенных дисков. Именно это позволяло нам взять сотню HDD, поставить их в один ящик, получить единый большой массив, сделать из них RAID, и гонять на них и с них рандомный ввод-вывод, просто потому, что «труба» к дискам, интерфейс FC, всегда заведомо, в разы шире, чем тот ввод-вывод, который на рандоме можно было получить с этих дисков. Все было ОК. Диски нагружены по максимуму, много серверов ходят по FC к ним за своими данными, и все равно интерфейса хватает на все.
Теперь появился flash, NVMe и Xpoint. Все кардинально поменялось. Теперь один диск, будучи совсем небольшим по емкости, уже превышает своей производительностью любой SAN-интерфейс. Это делает бессмысленным набивание этих дисков в большие коробки в SAN. Если даже один-два диска, будучи небольшой емкости, уже ограничиваются SAN-ом по пути к локальному серверу, то становится бессмысленным ставить их в СХД. Сам СХД на SAN будет ограничивать потенциальную производительность этих устройств. Даже один локальный сервер будет сталкиваться с «бутылочным горлом» интерфейса SAN, не говоря уж о нескольких серверах.
SSD flash МОГ БЫ, технически, дать больше, но, будучи в СХД — НЕ МОЖЕТ это дать серверам, потому что весь поток данных уперся в интерфейс ввода-вывода СХД и ограничение его производительности.
Отсюда мой вывод: появление и массовое распространение flash — архитектурный тупик для ныне существующей модели SAN и СХД как таковых.
Я не прав?
SAN появился, технически, потому, что канал передачи данных, например FC, был заведомо быстрее одного отдельного, или даже группы объединенных дисков. Именно это позволяло нам взять сотню HDD, поставить их в один ящик, получить единый большой массив, сделать из них RAID, и гонять на них и с них рандомный ввод-вывод, просто потому, что «труба» к дискам, интерфейс FC, всегда заведомо, в разы шире, чем тот ввод-вывод, который на рандоме можно было получить с этих дисков. Все было ОК. Диски нагружены по максимуму, много серверов ходят по FC к ним за своими данными, и все равно интерфейса хватает на все.
Теперь появился flash, NVMe и Xpoint. Все кардинально поменялось. Теперь один диск, будучи совсем небольшим по емкости, уже превышает своей производительностью любой SAN-интерфейс. Это делает бессмысленным набивание этих дисков в большие коробки в SAN. Если даже один-два диска, будучи небольшой емкости, уже ограничиваются SAN-ом по пути к локальному серверу, то становится бессмысленным ставить их в СХД. Сам СХД на SAN будет ограничивать потенциальную производительность этих устройств. Даже один локальный сервер будет сталкиваться с «бутылочным горлом» интерфейса SAN, не говоря уж о нескольких серверах.
SSD flash МОГ БЫ, технически, дать больше, но, будучи в СХД — НЕ МОЖЕТ это дать серверам, потому что весь поток данных уперся в интерфейс ввода-вывода СХД и ограничение его производительности.
Отсюда мой вывод: появление и массовое распространение flash — архитектурный тупик для ныне существующей модели SAN и СХД как таковых.
Я не прав?
Я пока ничего тут не «предлагаю на замену», я спрашиваю, правильно ли я вижу ситуацию.В технике что-то можно считать «умершим» только если ему на замену что-то пришло (более хорошее). На замену SAN пока ни чего не пришло.
SAN появился, технически, потому, что канал передачи данных, например FC, был заведомо быстрее одного отдельного, или даже группы объединенных дисков.
Нет. SAN появился потому, что людям нужны кластера, а кластерам нужны шаред стореджы. А транспортом для шаред стореджа является SAN.
На замену SAN вовсю уже идут конвергентные системы, например. Если вы этот поворот пропустили, то самое время посмотреть.
> Нет. SAN появился потому, что людям нужны кластера
Ну тут я просто не знаю, с чего вы так решили. Для SAN кластеры не только не причина их появления, но даже не основной их потребитель, даже сейчас, не говоря о времени появления SAN.
> Нет. SAN появился потому, что людям нужны кластера
Ну тут я просто не знаю, с чего вы так решили. Для SAN кластеры не только не причина их появления, но даже не основной их потребитель, даже сейчас, не говоря о времени появления SAN.
На замену SAN вовсю уже идут конвергентные системы, например. Если вы этот поворот пропустили, то самое время посмотреть.Применение Ethernet вместо FC тоже вполне себе конвергенция. Не понятно, какую из обсуждаемых проблем вы хотите с её помощью решить.
Ну тут я просто не знаю, с чего вы так решили. Для SAN кластеры не только не причина их появления, но даже не основной их потребитель, даже сейчасНе видел ни одного внедрения SAN что бы не ради подключения к кластеру. Во всех остальных случаях используют DAS, если конечно нет цели распилить бюджет небольшой страны. Откуда ваша статистика?
> Не видел ни одного внедрения SAN что бы не ради подключения к кластеру. Во всех остальных случаях используют DAS, если конечно нет цели распилить бюджет небольшой страны. Откуда ваша статистика?
Возможно потому, что я начал в этой области работать пораньше вас. И внедрял SAN не только под гипервизоры.
Возможно потому, что я начал в этой области работать пораньше вас. И внедрял SAN не только под гипервизоры.
Sign up to leave a comment.
Будущее за флэш-памятью: IBM FlashSystem