SAN за 30k$

[akimovp]

Как-то Оракл RAC и бюджет в 30К на SAN сеть плохо между собой соотносятся, мне так кажется.

Это я конечно преувеличил в данный момент - пока будет только standby, который может принимать запросы на чтение из DB . Но в последствии можно перейти на RAC, главное что-бы при этом СХД не пришлось менять , а только может быть проапгрейдить.

[exLH]

статистика нагрузки oracle есть, статистика нагрузки дисков тоже есть, но это все сечас на локальных дисках.

Замечательно.

[akimovp]

статистика нагрузки oracle есть, статистика нагрузки дисков тоже есть, но это все сечас на локальных дисках.

Замечательно.

Спасибо что посоветовали множество вариантов организации СХД.

[exLH]

Спасибо что посоветовали множество вариантов организации СХД.

А как Вы себе представляете советы, если Вы пишите, что "посылка у меня есть, но я ее вам не отдам"? Как без тех данных, которые есть у Вас, но которых нет у нас, мы можем сказать хватит Вам какой-то системы или нет???

[akimovp]

Спасибо что посоветовали множество вариантов организации СХД.

А как Вы себе представляете советы, если Вы пишите, что "посылка у меня есть, но я ее вам не отдам"? Как без тех данных, которые есть у Вас, но которых нет у нас, мы можем сказать хватит Вам какой-то системы или нет???

ну вот суммарные нагрузки на всех дисках на сервере базы данных
1600 iops read, 1550 iops write
read_max 110 Мбайт/с; write_max: 80 Мбайт/с
read_avg 16 Мбайт/с; write_avg: 12 Мбайт/с

что-то типа такого - админ примерно такие цифры предоставил по загруженности дисковой системы.

[exLH]

1600 iops read, 1550 iops write
read_max 110 Мбайт/с; write_max: 80 Мбайт/с
read_avg 16 Мбайт/с; write_avg: 12 Мбайт/с

Ну вот видите, как хорошо. Уже можно предметно говорить. Но не об лефтхэнде. Ну или по крайней мере не о том, о котором Вы думали.
Спросите, как же так? А очень просто: у Вас суммарно дисковая система выдает 3200 (для грубости) иопсов (операций ввода-вывода), если конечно в первой строчке средние значения, а не пиковые. Много это? Да не то чтобы уж очень много, но и не так уж и мало. Исходя из средних данных по трансферу получается, что операции идут блоками 8КБ, что для оракла вполне логично. Обычный 15к жесткий диск выдаст ну иопсов 200, ну 250 на блоках 8КБ. Итого на 3200 иопсов нужно примерно 13 дисков. Так как операций чтения примерно вровень с записью, то RAID10 будет в самый раз. Итого, получается 26 дисков, чтобы удовлетворить потребности. Скажете, что "да у нас сейчас меньше, как же оно работает?!" И будете правы - расчет выше довольно грубый. Он дает оценку "сверху", базируясь на многих предположениях. Что же он не учитывает? Кэш на контроллере конечно помогает - дает небольшой бенефит в производительности. Потом, не все записи идут случайно - при последовательных операциях производительность тоже будет выше (запись в лог, например, всегда идет последовательно). Если оценивать нужно более точно, то и нужно смотреть на нагрузку на каждой дисковой группе.
Но в любом случае ответ будет очевиден. Менять то, что есть сейчас на систему с 8ю дисками нельзя. Производительность упадет в разы.
В какую сторону двигаться? Зависит от бюджета. Если 30к это лимит - докупите полку с дисками и сливайте логи на удаленную площадку дальше. Максимум что за такие деньги получится сделать - купить относительно нормальную дисковую систему на одну из площадок. Причем без запаса по производительности - только чтобы перекрыть текущие мощности.
Если же 30к это "вот сейчас на столе лежат", а завтра, если показать проект, дадут еще 50, а потом еще 100, если запустить пилот, а если пойдет, то ... то число вариантов возрастает. Масштабируемые системы есть. Разные. Lefthand как раз здесь (в Вашем случае) будет самым слабым, на мой взгляд, вариантом. Я бы начал смотреть на связку из IBM SVC EE и DS3400. Если это слишком дорого (хотя из решений от вендора первого эшелона это весьма экономичный вариант), то есть конечно и более бюджетные решения, например, в этом году Infortrend двинулся в сегмент среднего класса с системами ESVA. Железки интересны как раз тем, что могут масштабироваться как горизонтально (при добавлении систем в пул), так и вертикально (при добавлении дисков к одной ESVA). Немного я про это писал уже.
Да, чуть не забыл, iSCSI, сам по себе, для Вас не так уж и плох. Плохо - иметь мало дисков и не иметь возможности (бюджета) получить их достаточно.

[akimovp]

1600 iops read, 1550 iops write
read_max 110 Мбайт/с; write_max: 80 Мбайт/с
read_avg 16 Мбайт/с; write_avg: 12 Мбайт/с

Ну вот видите, как хорошо. Уже можно предметно говорить. Но не об лефтхэнде. Ну или по крайней мере не о том, о котором Вы думали.
Спросите, как же так? А очень просто: у Вас суммарно дисковая система выдает 3200 (для грубости) иопсов (операций ввода-вывода), если конечно в первой строчке средние значения, а не пиковые. Много это? Да не то чтобы уж очень много, но и не так уж и мало. Исходя из средних данных по трансферу получается, что операции идут блоками 8КБ, что для оракла вполне логично. Обычный 15к жесткий диск выдаст ну иопсов 200, ну 250 на блоках 8КБ. Итого на 3200 иопсов нужно примерно 13 дисков. Так как операций чтения примерно вровень с записью, то RAID10 будет в самый раз. Итого, получается 26 дисков, чтобы удовлетворить потребности. Скажете, что "да у нас сейчас меньше, как же оно работает?!" И будете правы - расчет выше довольно грубый. Он дает оценку "сверху", базируясь на многих предположениях. Что же он не учитывает? Кэш на контроллере конечно помогает - дает небольшой бенефит в производительности. Потом, не все записи идут случайно - при последовательных операциях производительность тоже будет выше (запись в лог, например, всегда идет последовательно). Если оценивать нужно более точно, то и нужно смотреть на нагрузку на каждой дисковой группе.
Но в любом случае ответ будет очевиден. Менять то, что есть сейчас на систему с 8ю дисками нельзя. Производительность упадет в разы.
В какую сторону двигаться? Зависит от бюджета. Если 30к это лимит - докупите полку с дисками и сливайте логи на удаленную площадку дальше. Максимум что за такие деньги получится сделать - купить относительно нормальную дисковую систему на одну из площадок. Причем без запаса по производительности - только чтобы перекрыть текущие мощности.
Если же 30к это "вот сейчас на столе лежат", а завтра, если показать проект, дадут еще 50, а потом еще 100, если запустить пилот, а если пойдет, то ... то число вариантов возрастает. Масштабируемые системы есть. Разные. Lefthand как раз здесь (в Вашем случае) будет самым слабым, на мой взгляд, вариантом. Я бы начал смотреть на связку из IBM SVC EE и DS3400. Если это слишком дорого (хотя из решений от вендора первого эшелона это весьма экономичный вариант), то есть конечно и более бюджетные решения, например, в этом году Infortrend двинулся в сегмент среднего класса с системами ESVA. Железки интересны как раз тем, что могут масштабироваться как горизонтально (при добавлении систем в пул), так и вертикально (при добавлении дисков к одной ESVA). Немного я про это писал уже.
Да, чуть не забыл, iSCSI, сам по себе, для Вас не так уж и плох. Плохо - иметь мало дисков и не иметь возможности (бюджета) получить их достаточно.

Спасибо большое за развернутые комментарий.
Если судить по этой логике то сейчас у нас дисковая система нагружена на ~200%. Два RAID5 по 3 диска 144G 15k.
Админ говорит что дисковая система загружена на 70-80%. Либо он данные неправильные дал.

[akimovp]

Спасибо большое за развернутые комментарий.
Если судить по этой логике то сейчас у нас дисковая система нагружена на ~200%. Два RAID5 по 3 диска 144G 15k.
Админ говорит что дисковая система загружена на 70-80%. Либо он данные неправильные дал.

Короче админ немножко ошибся)))
по iostat
первый RAID5 нагрузка iops - avg_read - 32, avg_write - 17, max_read - 1252, max_write - 1050
чтение запись - avg_rMB/s - 1.81, avg_wMB/s - 0.89, max_rMB/s - 87, max_wMB/s - 41
второй RAID5 нагрузка iops - avg_read - 25, avg_write - 47, max_read - 1178, max_write - 487
чтение запись - avg_rMB/s - 0.8, avg_wMB/s - 0.4, max_rMB/s - 74, max_wMB/s - 22

[exLH]

Короче админ немножко ошибся)))

И даже в этом случае Вы хотите уменьшить производительность дисковой системы в два раза. Наверное не стоит...

[akimovp]

Короче админ немножко ошибся)))

И даже в этом случае Вы хотите уменьшить производительность дисковой системы в два раза. Наверное не стоит...

Объясните плиз почему с lefthand производительность дисковой системы будет ниже в 2 раза, дисков вроде больше,
масштабируется вроде она хорошо - добавили модуль - добавилось дисков пропускной способности и объема.

[exLH]

Объясните плиз почему с lefthand производительность дисковой системы будет ниже в 2 раза, дисков вроде больше,

Сейчас у Вас 6 дисков. Будет 8, но на два узла, т.е. реально 3 (за минусом четности).

[hitower]

На месте автора я бы подумал не о RAC, а о logical standby+оперативное перебрасывание подключений из одной базы в другую.
Просто подумайте о том, какие неприятности могут произойти с вашей базой - RAC и network RAID не спасут, например, от битого блока в базе, который исправлять нужно будет явно не 5-10 минут...

[akimovp]

Объясните плиз почему с lefthand производительность дисковой системы будет ниже в 2 раза, дисков вроде больше,

Сейчас у Вас 6 дисков. Будет 8, но на два узла, т.е. реально 3 (за минусом четности).

так некорректно считать,
- во-первых по такой логике с учетом четности сейчас не 6 дисков , а 4.
- во-вторых в 2-х модулях lefthand 16 дисков и на чтение они балансируют нагрузку, будет заметное увеличение производительности.(как мне кажется)
- в-третьих почему на 2 узла? один узел будет primary работать в полном режиме читать и писать, второй standby будет только читать. При поломке primary standby переводится в рабочий режим.
- в четвертых , допустим в последствии мы добавляем еще один модуль lefthand, получается уже 24 диска и полоса пропускания сети 6x1Gbit (в каждом модуле по 2 карты 1Gbit)

[exLH]

...во-первых...

Ну и к чему все это? Вы хотите меня уговорить купить P4300? Так мне он не нужен. Если Вы уверены, что Вам эта система подойдет - берите, в чем проблема?

[exLH]

AT013A HP LeftHand P4300 2.4TB SAS Storage System

Да, я вот как совсем даже не специалист по левым рукам, хотел бы Вам вот еще что посоветовать. Подойдите к продавцу, ласково возьмите его за лацкан пиджака, посмотрите в глаза и спросите "А правда, что под этим p/n поставляются два узла?" и, на всякий случае, пару раз повторите вопрос, чтобы добиться полного взаимопонимания.