Комментарии 34
Насколько я знаю, тут стоят 2 процессора Xeon 5520. Не мешало бы упоминать хотя бы основные детали конфигурации. Тем более использование процессоров Intel повышает привлекательность этой системы, по крайней мере для меня. Кстати, те же процессоры от Intel вносят свой вклад в снижение TCO.
А так спасибо большое за обзор!
А так спасибо большое за обзор!
М-да. Блог компании HP все больше напоминает трансляцию фида пресс-релизов. Много слов и мало по делу.
Простой вопрос: какие иопсы вы гарантируете? (гарантированный минимум).
Все равно, что спросить «Какая минимальная скорость у феррари?».
На этот параметр влияет куча факторов — от типа рейда до поддержки коммутатором jumbo frames.
А вообще, десятая страница спецификации как бы содержит ответ на вопрос: h18000.www1.hp.com/products/quickspecs/13254_div/13254_div.pdf
На этот параметр влияет куча факторов — от типа рейда до поддержки коммутатором jumbo frames.
А вообще, десятая страница спецификации как бы содержит ответ на вопрос: h18000.www1.hp.com/products/quickspecs/13254_div/13254_div.pdf
Извините, гарантированный максимум. Описался.
J/F на иопсы сколь-либо сильно не влияет.
И я реально хочу увидеть производителя полок, который сможет сказать «гарантированные иопсы при размере блока от 0 до 16к — не менее 5000 (10к, 100к и т.д.)».
Потому что когда дело доходит до реального подсчёта конфигурации, все интеграторы, которых я видел, начинали от вполне чётких апроксимаций по памяти/процу переходить к вялому «ну, один SAS даёт порядка 150 иопсов..., рейд максимум может 100к, так что взяв 50 винтов и рейд мы наверное получим 7500 иопсов».
J/F на иопсы сколь-либо сильно не влияет.
И я реально хочу увидеть производителя полок, который сможет сказать «гарантированные иопсы при размере блока от 0 до 16к — не менее 5000 (10к, 100к и т.д.)».
Потому что когда дело доходит до реального подсчёта конфигурации, все интеграторы, которых я видел, начинали от вполне чётких апроксимаций по памяти/процу переходить к вялому «ну, один SAS даёт порядка 150 иопсов..., рейд максимум может 100к, так что взяв 50 винтов и рейд мы наверное получим 7500 иопсов».
Стоп-стоп-стоп!
Гарантированный максимум — это круто!
Р4000 — решение, состоящее из отдельных нодов, на которых организуется (по желанию Заказчика) сетевой RAID. Иными словами, чем больше нодов участвует, тем выше скорость. Опять же от количества репликаций данных и уровня рейда зависит. Хотите скорости — вэлкам — без репликации!
Если Вам производитель полок хе-хе скажет «я гарантирую столько иопсв», а Вы счастливый уйдете, купите и… получите неизвестно что.
Касательно массивов — есть четкие методики и рекомендации вендора сколько иопов надо ожидать (именно так) от одного шпинделя или от одного процессора в массиве ХР24000 (например). Если Ваши интеграторы Вам этого не говорили — просто Вы неправильно выбираете друзей. Считать надо под Ваши задачи.
И последний вопрос: а Вы с какой целью интересуетесь? Самообразование? Тогда вэлкам в учебный центр НР (есть курс по Р4000). Хотите купить? Вэлкам к интегратору — он должен посчитать.
На уровне оценки — мало дисков — узкое место именно они, много дисков — уское место может быть в контроллерах. Р4000 — добавление дисков с интеллектом.
Продолжение следует… И про производительность тоже
Гарантированный максимум — это круто!
Р4000 — решение, состоящее из отдельных нодов, на которых организуется (по желанию Заказчика) сетевой RAID. Иными словами, чем больше нодов участвует, тем выше скорость. Опять же от количества репликаций данных и уровня рейда зависит. Хотите скорости — вэлкам — без репликации!
Если Вам производитель полок хе-хе скажет «я гарантирую столько иопсв», а Вы счастливый уйдете, купите и… получите неизвестно что.
Касательно массивов — есть четкие методики и рекомендации вендора сколько иопов надо ожидать (именно так) от одного шпинделя или от одного процессора в массиве ХР24000 (например). Если Ваши интеграторы Вам этого не говорили — просто Вы неправильно выбираете друзей. Считать надо под Ваши задачи.
И последний вопрос: а Вы с какой целью интересуетесь? Самообразование? Тогда вэлкам в учебный центр НР (есть курс по Р4000). Хотите купить? Вэлкам к интегратору — он должен посчитать.
На уровне оценки — мало дисков — узкое место именно они, много дисков — уское место может быть в контроллерах. Р4000 — добавление дисков с интеллектом.
Продолжение следует… И про производительность тоже
Он хочет понять за что конкретно деньги в теории будут уплачены.
Я знаю, что круто. Но нужно.
Я понимаю, что там синхронизирующиеся ноды и т.д. Но ведь есть возможность сказать, сказать «N нод» — M иопсов? Или нет?
Я задачей интересуюсь с следующей позиции… Уже не секрет, что мы пилим облако с продажей ресурсов по потреблению. Одна из проблем, с которой я столкнулся — я не могу понять, как рассчитывать стоимость дисковой операции для клиента. С памятью/процом всё ясно. Мы закладываем ожидаемую сумму в месяц, делим её на наличествующие ресурсы и количество минут/секунд/часов в месяце, получаем цену минуты/секунды/часа использования ресурса. Я точно могу сказать, сколько у меня может выдать процессор секунд машинного времени. Я точно знаю, сколько гигабайто-часов у меня может выдать память. Я точно знаю, какой ширины у меня аплинки в инет. Я даже точно знаю, сколько у меня есть дискового пространства. Но я не знаю, сколько у меня есть дисковых операций/полосы.
Т.е. у меня есть сумма, которую я хочу получить за сторедж в месяц (амортизация, деньги за обслуживание). Я готов выставить ценник клиенту как сумма/доступные_ресурсы.
И тут вопрос: а какие мне ресурсы доступны? Я точно знаю, сколько дисковых операций сделает каждый клиент, сколько гигабайт он запишет.
Но я совершенно не знаю, сколько у меня есть ресурсов на продажу.
Каким образом вы (допустим, вы) можете мне подсчитать, сколько ресурсов вы мне продали (т.е. на какое количество ресурсов я могу рассчитывать)? Если у вас есть конкретные предложения под нашу задачу, мы готовы их рассматривать. Заметим, это как раз та самая задача для облаков и виртуализации, о которой в начале текста написано.
Я понимаю, что там синхронизирующиеся ноды и т.д. Но ведь есть возможность сказать, сказать «N нод» — M иопсов? Или нет?
Я задачей интересуюсь с следующей позиции… Уже не секрет, что мы пилим облако с продажей ресурсов по потреблению. Одна из проблем, с которой я столкнулся — я не могу понять, как рассчитывать стоимость дисковой операции для клиента. С памятью/процом всё ясно. Мы закладываем ожидаемую сумму в месяц, делим её на наличествующие ресурсы и количество минут/секунд/часов в месяце, получаем цену минуты/секунды/часа использования ресурса. Я точно могу сказать, сколько у меня может выдать процессор секунд машинного времени. Я точно знаю, сколько гигабайто-часов у меня может выдать память. Я точно знаю, какой ширины у меня аплинки в инет. Я даже точно знаю, сколько у меня есть дискового пространства. Но я не знаю, сколько у меня есть дисковых операций/полосы.
Т.е. у меня есть сумма, которую я хочу получить за сторедж в месяц (амортизация, деньги за обслуживание). Я готов выставить ценник клиенту как сумма/доступные_ресурсы.
И тут вопрос: а какие мне ресурсы доступны? Я точно знаю, сколько дисковых операций сделает каждый клиент, сколько гигабайт он запишет.
Но я совершенно не знаю, сколько у меня есть ресурсов на продажу.
Каким образом вы (допустим, вы) можете мне подсчитать, сколько ресурсов вы мне продали (т.е. на какое количество ресурсов я могу рассчитывать)? Если у вас есть конкретные предложения под нашу задачу, мы готовы их рассматривать. Заметим, это как раз та самая задача для облаков и виртуализации, о которой в начале текста написано.
Берите в тест и меряйте на вашей конкретной задаче.
Как вы утомили, честное слово… Мы продавать ресурсы будем. Чужим дядям. Откуда мы знаем, какие у НИХ задачи будут?
И вопрос простой: сколько есть дискового ресурса, который мы продаём? Но никто не отвечает — и именно про эту проблему я и говорил. Ни один интегратор, ни один производитель не может пообещать какой-либо уровень производительности в цифрах. Так, чтобы «не меньше ххх».
И вопрос простой: сколько есть дискового ресурса, который мы продаём? Но никто не отвечает — и именно про эту проблему я и говорил. Ни один интегратор, ни один производитель не может пообещать какой-либо уровень производительности в цифрах. Так, чтобы «не меньше ххх».
Это вы сами себя утомили. НИКТО вам на этот вопрос не ответит кроме вас самих.
Вот про это я и говорю: ни один производитель полок/стореджев не может гарантировать какой-либо производительности, только best efforts.
Гарантировать производительность могут не производители полок, а производители дисков :)
А от стораджа и его конфигурации уже будет зависеть, какой процент этой производительности вы тратите на отказоустойчивость, на бекапы и т.д.
Рассчитать пусть не минимальные гарантии, но статистическое среднее/стандартное отклонение можно довольно просто.
А от стораджа и его конфигурации уже будет зависеть, какой процент этой производительности вы тратите на отказоустойчивость, на бекапы и т.д.
Рассчитать пусть не минимальные гарантии, но статистическое среднее/стандартное отклонение можно довольно просто.
Есть ли производитель, который может пообещать конкретные цифры для конкретных дисков внутри своих полок?
а вы от производителей корпусов тоже требуете гарантий частоты процессора?
Нет, я обычно требую это от поставщика решения. И более того, любой производитель с лёгкостью гарантирует указанную частоту ЦП при использовании его корпуса с указанными рекомендованными комплектующими.
Может ли HP назвать комплектующие и гарантировать на них заданную (заранее названную) производительность?
Может ли HP назвать комплектующие и гарантировать на них заданную (заранее названную) производительность?
Конкретные цифры очень сильно зависят от конкретной конфигурации массива. Кроме того IOPS это параметр, сильно подверженный влиянию случайных факторов.
Поэтому гарантировать минимум для него — так же нереально, как, к примеру, гарантировать минимум скорости передвижения автомобиля по городу.
Но это ничуть не мешает сделать SLA по статистическим показателям, например среднее значение за минуту с нормированным среднеквадратичным отклонением.
Правда есть еще такой фактор, как аварийные ситуации. Вам придется либо закладываться на нужную производительность, даже в случае ребилда массива, либо обговаривать их отдельно.
Поэтому гарантировать минимум для него — так же нереально, как, к примеру, гарантировать минимум скорости передвижения автомобиля по городу.
Но это ничуть не мешает сделать SLA по статистическим показателям, например среднее значение за минуту с нормированным среднеквадратичным отклонением.
Правда есть еще такой фактор, как аварийные ситуации. Вам придется либо закладываться на нужную производительность, даже в случае ребилда массива, либо обговаривать их отдельно.
Вот именно об этой проблеме я и думаю. «Среднее» меня не устраивает. Вендоры ничего внятного предложить не могут, так что мне придётся изобретать свой метод учёта нагрузки и рассчёта наличествующего ресурса.
Я бы с радостью эту увлекательную работу переложил на вендора — но, увы, их нет.
Я бы с радостью эту увлекательную работу переложил на вендора — но, увы, их нет.
Простите, а вы частоту процессора считаете хорошим показателем ресурса, который вы продаете? И действительно считаете, что виртуалка на одном ядре, скажем 2800 Nocona дает столько же производительности, сколько nehalem X5560?
Однако вы это просто перекладываете на вендора, и не хотите внедрять более объективной системы измерений.
Однако вы это просто перекладываете на вендора, и не хотите внедрять более объективной системы измерений.
Послушайте. Вопрос «что лучше» я решаю отдельно от учёта.
Когда я продаю человеку час машинного времени я точно знаю, сколько тактов я ему продаю — мне известна частота. И ещё мне известно, сколько всего тактов в час способен обслужить конкретный процессор.
Когда я продаю человеку дисковые операции, я точно знаю, сколько дисковых операций сделал человек. Я реализовал систему учёта. Теперь вопрос: а сколько дисковых операций у меня есть?
Это не связано с производительностью системы. Разные диски дают разную скорость, разные полки тупят над разными задачами. Но вопрос в том, не «как они быстры», а «сколько именно операций они могут обслужить в данной конкретной конфигурации». Производители процессоров дали объективный ответ на этот вопрос. Производители хранилищ — нет.
Потому я сейчас, вместо того, чтобы лоббировать покупку хранилища от HP, трахаюсь над этой задачей сам. Я бы рад купить готовое — но его нет.
Про это я и говорю — предлагаемое решение от HP не соответствует потребностям системы виртуализации.
Когда я продаю человеку час машинного времени я точно знаю, сколько тактов я ему продаю — мне известна частота. И ещё мне известно, сколько всего тактов в час способен обслужить конкретный процессор.
Когда я продаю человеку дисковые операции, я точно знаю, сколько дисковых операций сделал человек. Я реализовал систему учёта. Теперь вопрос: а сколько дисковых операций у меня есть?
Это не связано с производительностью системы. Разные диски дают разную скорость, разные полки тупят над разными задачами. Но вопрос в том, не «как они быстры», а «сколько именно операций они могут обслужить в данной конкретной конфигурации». Производители процессоров дали объективный ответ на этот вопрос. Производители хранилищ — нет.
Потому я сейчас, вместо того, чтобы лоббировать покупку хранилища от HP, трахаюсь над этой задачей сам. Я бы рад купить готовое — но его нет.
Про это я и говорю — предлагаемое решение от HP не соответствует потребностям системы виртуализации.
В таком случае продавайте кол-во оборотов шпинделя диска, его вам гарантируют
Я об этом уже думал — но я не могу считать точное время выполнения конкретной операции конкретного человека — NCQ, дисковые кеши, кеши рейдов, кеш хранилища… Если бы я действительно видел, сколько времени диск занят конкретной операцией, да, это было бы справедливо. Но, насколько я знаю, ни один из производителей хранилищ таких интерфейсов и данных не предоставляет.
Сик между операциями разных клиентов был бы подобен накладным расходам на переключение контекста процессора (и относился бы к оверхеду).
Проблема в том, что у нас нет точных данных о поведении головки жёсткого диска, т.е. мы не имеем данных о том, чей запрос сейчас мурыжит винт.
Были бы софтовые скедулеры для дисков…
Сик между операциями разных клиентов был бы подобен накладным расходам на переключение контекста процессора (и относился бы к оверхеду).
Проблема в том, что у нас нет точных данных о поведении головки жёсткого диска, т.е. мы не имеем данных о том, чей запрос сейчас мурыжит винт.
Были бы софтовые скедулеры для дисков…
сик между операциями является основной стоимостью дисковой операции.
Как легко догадаться IOPS = 1000/(latency+seek)
Табличка из IBM-овского редбука:
Disk speed Latency Seek time IOPS
15 000 RPM 2.0 ms 3.8 ms 147
10 000 RPM 3.0 ms 4.9 ms 112
7 200 RPM 4.2 ms 9 ms 75
Причем для SSD seek=0, но IOPS тоже не бесконечные, поскольку latency присутствует. Но latency по крайней мере напрямую зависит от объема передаваемых данных.
При необходимости учитывать такое кол-во параметров, включающих к тому же сильную зависимость от workload, единственный разумный способ учета — это статистический.
Как легко догадаться IOPS = 1000/(latency+seek)
Табличка из IBM-овского редбука:
Disk speed Latency Seek time IOPS
15 000 RPM 2.0 ms 3.8 ms 147
10 000 RPM 3.0 ms 4.9 ms 112
7 200 RPM 4.2 ms 9 ms 75
Причем для SSD seek=0, но IOPS тоже не бесконечные, поскольку latency присутствует. Но latency по крайней мере напрямую зависит от объема передаваемых данных.
При необходимости учитывать такое кол-во параметров, включающих к тому же сильную зависимость от workload, единственный разумный способ учета — это статистический.
На практике я могу точно сказать, насколько загружена дисковая подсистема серверов, которые мы обслуживаем и какая именно виртуалка насколько их загружает. Пока не сталкивался с задачей обеспечения SLA, но видел несколько механизмов их обеспечения. В них используется принцип приоритезированной очереди.
Насколько я понял вашу задачу, вам требуется дать гарантированное кол-во IOPS в условиях приоритетов, это возможно только в условиях большого запаса производительности, 5-10 кратного
Насколько я понял вашу задачу, вам требуется дать гарантированное кол-во IOPS в условиях приоритетов, это возможно только в условиях большого запаса производительности, 5-10 кратного
Нет, нет, не так. Наша концепция — продажа ресурсов по потреблению. Т.е. за иопсы и объём дисковых операций мы будем брать деньги с клиентов. Для того, чтобы понять, какие деньги брать, нужно понимать, сколько может дать наше хранилище. (Цена=сумма/количество, сумму мы знаем, «количество» я как раз и хочу узнать).
Вот я сейчас игрался с iozone, там такой неописуемый разброс параметров при тесте, что мне становится страшновато…
Вот я сейчас игрался с iozone, там такой неописуемый разброс параметров при тесте, что мне становится страшновато…
Отлично, первую цифру мы получили. Мы знаем, что винчестер способен обеспечить комбинацию из иопсов и передачи данных (чем больше иопсов, тем меньше трансфер). Допустим, что мы это знаем точно.
А теперь главная проблема: каким образом из N дисков с X иопсами мы получаем характеристики рейда? Мы не можем линейно полагать, что все все операции будут распараллелены, есть вероятность, что _ВСЕ_ операции, которые предназначались для 50-100 дисков в полке на самом деле придутся на один диск.
И если с дисками мы хоть как-то можем рассчитывать на более-менее фиксированную производительность (в заданных пределах), то с полками — нет. И нижний предел для полки получается равным пределу диска…
Если я не прав, буду рад, если докажете (назовёте) обратное.
А теперь главная проблема: каким образом из N дисков с X иопсами мы получаем характеристики рейда? Мы не можем линейно полагать, что все все операции будут распараллелены, есть вероятность, что _ВСЕ_ операции, которые предназначались для 50-100 дисков в полке на самом деле придутся на один диск.
И если с дисками мы хоть как-то можем рассчитывать на более-менее фиксированную производительность (в заданных пределах), то с полками — нет. И нижний предел для полки получается равным пределу диска…
Если я не прав, буду рад, если докажете (назовёте) обратное.
почти правы, объект измерения производительности не диск, а массив.
Полка может и обычно содержит несколько массивов, в зависимости от задачи они могут быть разных уровней. Например 2 RAID10 массива из 4 sas 15k rpm дисков + 2 RAID6 из 8 5900 sata, на каждом массиве свои потребители(сервисы) и свои задачи.
Полка может и обычно содержит несколько массивов, в зависимости от задачи они могут быть разных уровней. Например 2 RAID10 массива из 4 sas 15k rpm дисков + 2 RAID6 из 8 5900 sata, на каждом массиве свои потребители(сервисы) и свои задачи.
почитайте исходники mdadm, найдете много интересного :)
RAID1E сделан таким образом, что вероятность считывания с одного диска 1/N, что дает практически идеальную балансировку по шпинделям для любой задачи. IOPS массива = сумме IOPS дисков для чтения и IOPS худшего для записи.
в RAID5/6 для считывания/записи блока данных нужно считать со всех дисков, т.е.для чтения IOPS массива равны IOPS худшего диска в массива.
ИМХО для облака нет смысла строить мега-массивы из сотен дисков.
Идеальный вариант это 1 клиент на 1 массив.
RAID1E сделан таким образом, что вероятность считывания с одного диска 1/N, что дает практически идеальную балансировку по шпинделям для любой задачи. IOPS массива = сумме IOPS дисков для чтения и IOPS худшего для записи.
в RAID5/6 для считывания/записи блока данных нужно считать со всех дисков, т.е.для чтения IOPS массива равны IOPS худшего диска в массива.
ИМХО для облака нет смысла строить мега-массивы из сотен дисков.
Идеальный вариант это 1 клиент на 1 массив.
стоимость дисковой операции очень сильно зависит от ее параметров и загрузки диска. Разница может быть на порядок.
Параметры можно ограничить. Например, я спокойно отнесусь к спеку в виде «40000 иопсов при размере блока не более 4к». А вопрос «зависит от загрузки диска» — это как раз вопрос к хранилищу, которое не должно доводить до такого.
я имею в виду, что если один дисковый массив загружается последовательным чтением несколькими клиентами, то это уже полностью рандомное чтение :)
Но конечно, если вы даете каждому клиенту свой дисковый массив, то этот фактор исключается.
Хранилище ничего не изменит, узкое место — это механика диска.
Но конечно, если вы даете каждому клиенту свой дисковый массив, то этот фактор исключается.
Хранилище ничего не изменит, узкое место — это механика диска.
Это хороший аргумент. Хотя, наверное, правильный стор для облака должен учитывать специфику многопользовательской системы и распределять нагрузку таким образом, чтобы последовательные операции от пользователей были бы последовательными.
Вряд ли это возможно, если только вы не сделаете свою реализацию облачной ФС, которая сама будет гарантировать целостность данных и балансировку нагрузки по дискам, не задействуя для этого возможности стораджа, либо очень тесно с ними интегрируясь.
Собственно мы для своих потребностей это и сделали :)
Собственно мы для своих потребностей это и сделали :)
Я записался на тест этой штуки на сентябрь.
По бумажкам вещь вроде неплохая, особенно радует стартовый набор фич, которые у более других производителей продаются за существенно более другие деньги. Из узких мест там лейтенси между нодами не должно быть выше 20ms (по оригинальной спецификаци lefthand, когда они еще были отдельной конторой вообще не более 8ms). В остальном это x86 based iscsi со всеми плюсами и минусами. Т.е. в виртуалке работает (4500 решение именно так и сделано).
Есть у кого-нибудь на этих коробках кластер под vmware? Если есть напишите. Как оно плюсы минусы.
На данных момент слышал что у Оверсана вроде в эксплуатации есть.
По бумажкам вещь вроде неплохая, особенно радует стартовый набор фич, которые у более других производителей продаются за существенно более другие деньги. Из узких мест там лейтенси между нодами не должно быть выше 20ms (по оригинальной спецификаци lefthand, когда они еще были отдельной конторой вообще не более 8ms). В остальном это x86 based iscsi со всеми плюсами и минусами. Т.е. в виртуалке работает (4500 решение именно так и сделано).
Есть у кого-нибудь на этих коробках кластер под vmware? Если есть напишите. Как оно плюсы минусы.
На данных момент слышал что у Оверсана вроде в эксплуатации есть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HP StorageWorks P4000 G2 и оптимизация расходов на SAN