Помогите выбрать хранилище
Модераторы: Trinity admin`s, Free-lance moderator`s
-
- member
- Сообщения: 20
- Зарегистрирован: 21 май 2007, 15:56
- Откуда: Москва
Помогите выбрать хранилище
Добрый день!
Выбираем сейчас решение для хранилища для информационной системы нашей компании. У нас к хранилищу планируется подключать два сервера Oracle на Linux, каждый из них в установившемся режиме формирует поток запросов до 1000 IOP, до 10МБ/с (причём IOWait у нас сейчас бывает больше 12%), в пиках до 70МБ/с (IOP не замерял, но скорее всего пропорционально больше). Сейчас мы склоняемся к Infortrend EonStor FC to SAS/SATA S16F-R1430 - двухконтроллерный - и соединять каждый из контроллеров FC-линком с каждым из серверов (отказоустойчивость хранилища для нас важна). Для дальнейшего роста хотелось бы иметь по крайней мере двухкратный запас по мощности и пропускной способности контроллеров.
В связи с этим следующие вопросы:
1. Насколько работоспособна/достаточна данная конфигурация? Может быть возможны какие-то другие варианты, или решения от других производителей? В частности, можно ли подобную систему построить на основе SAS to SAS хранилища - насколько SAS поддерживает multipath (операционка у нас Linux x86_64, ядра 2.6.17 или выше)?
2. Основной массив под эти запросы мы собираемся строить как RAID10 из 8 винтов Seagate Cheetah 15K - какой запас по пропускной способности и по количеству операций у нас будет?
Заранее спасибо!
Выбираем сейчас решение для хранилища для информационной системы нашей компании. У нас к хранилищу планируется подключать два сервера Oracle на Linux, каждый из них в установившемся режиме формирует поток запросов до 1000 IOP, до 10МБ/с (причём IOWait у нас сейчас бывает больше 12%), в пиках до 70МБ/с (IOP не замерял, но скорее всего пропорционально больше). Сейчас мы склоняемся к Infortrend EonStor FC to SAS/SATA S16F-R1430 - двухконтроллерный - и соединять каждый из контроллеров FC-линком с каждым из серверов (отказоустойчивость хранилища для нас важна). Для дальнейшего роста хотелось бы иметь по крайней мере двухкратный запас по мощности и пропускной способности контроллеров.
В связи с этим следующие вопросы:
1. Насколько работоспособна/достаточна данная конфигурация? Может быть возможны какие-то другие варианты, или решения от других производителей? В частности, можно ли подобную систему построить на основе SAS to SAS хранилища - насколько SAS поддерживает multipath (операционка у нас Linux x86_64, ядра 2.6.17 или выше)?
2. Основной массив под эти запросы мы собираемся строить как RAID10 из 8 винтов Seagate Cheetah 15K - какой запас по пропускной способности и по количеству операций у нас будет?
Заранее спасибо!
-
- member
- Сообщения: 20
- Зарегистрирован: 21 май 2007, 15:56
- Откуда: Москва
Вообще то ничего плохого в нем нет.progressor писал(а):А по каким параметрам EonStor не подходит?
По всем параметрам подходит, IMHO.
Только начинать надо минимум с 16 дисков, о чем говорят ваши IOPS
Больше дисков - больше IOPS. R1430 расширяется еще двумя полками.
48 шпинделей дает вам неплохой запас.
Кстати, сколько дисков у вас сейчас на этих серверах и какого размера базы?
-
- member
- Сообщения: 20
- Зарегистрирован: 21 май 2007, 15:56
- Откуда: Москва
art Сейчас сервера несколько послабее, данные в каждом раскиданы по трём внутренним массивам 2+2+6 дисков SAS Fujitsu 15K, я привёл суммарные данные, потому что мы планируем для увеличения производительности все данные положить на объединённый массив.
А как IOPs связаны с количеством дисков? Я считал, что IOPs зависят от быстродействия и "разумности" алгоритмов контроллера, и пропускной способности отдельного диска, а количество дисков в массиве увеличивает только общую потоковую пропускную способность. Я неправ?
А как IOPs связаны с количеством дисков? Я считал, что IOPs зависят от быстродействия и "разумности" алгоритмов контроллера, и пропускной способности отдельного диска, а количество дисков в массиве увеличивает только общую потоковую пропускную способность. Я неправ?
если сейчас скорость работы для пользователей сколько-нибудь приемлема, на 16-ти дисках 15К вы будете чувстовать себя хорошо.progressor писал(а): Сейчас сервера несколько послабее, данные в каждом раскиданы по трём внутренним массивам 2+2+6 дисков SAS Fujitsu 15K, я привёл суммарные данные, потому что мы планируем для увеличения производительности все данные положить на объединённый массив.
upd Не смотрели iostat, сколько примерно iops приходится на каждый из этих 2+2+6? Если в каждом сервере 10 дисков и все 3 массива в каждом хорошо нагружены, то возможно, стоит подумать о более чем 16-ти для полного комфорта.
Мне кажется маловероятным, что эти 2+2+6 работают одинаково напряженно. Если так, нагрузка размажется хорошо и на 16 дисков.
Алгоритмы да, важны.progressor писал(а): А как IOPs связаны с количеством дисков? Я считал, что IOPs зависят от быстродействия и "разумности" алгоритмов контроллера, и пропускной способности отдельного диска, а количество дисков в массиве увеличивает только общую потоковую пропускную способность. Я неправ?
Но если размер БД не помещается в кеш контроллера, то надо лазить на диски. А тут уже прямая зависимость IOPS от количества дисков.
Именно хитрые алгоритмы позволяют шарить головами одновременно по всем дискам, одновременно собирая с каждого данные. Если у вас один диск, то головы в один момент времени летят за одним сектором ФС, если 48 дисков, то за 48 секторами разом.
Это очень грубо, потому что контроллер может отложить пробежку, поменять ее местами с другой и пр., чтобы оптимизировать метания головок, отложить в кеш, сбегать почитать еще незатребованное но, возможно, полезное. В этом суть тех самых алгоритмов.
Одного курьера по двум адресам разом не пошлешь. Можно оптимизировать перемещение между районами, не посылать с севера на юг и т.д. Но тупая курьерская служба с 48 курьерами уделает самую умную с 8-ю, если город достаточно велик -)
Несомненно одно, чем больше дисков, тем быстрее будут прочитаны/записаны случайно расположенные данные. И эта зависимость почти линейна.
На очень большом числе дисков и высоких IOPS контроллер может захлебнуться данными, но ваши 3 полки едва ли достигнут предела в данном случае.
-
- member
- Сообщения: 20
- Зарегистрирован: 21 май 2007, 15:56
- Откуда: Москва
Да, вы абсолютно правы - нагрузка делится между массивами очень неравномерно, я приводил суммарные цифры - обычно там один массив простаивает, а два остальных делят нагрузку в соотношении примерно 70/30 - 60/40. Так что я думаю, что 16 дисков нам хватит.art писал(а): Не смотрели iostat, сколько примерно iops приходится на каждый из этих 2+2+6? Если в каждом сервере 10 дисков и все 3 массива в каждом хорошо нагружены, то возможно, стоит подумать о более чем 16-ти для полного комфорта.
Мне кажется маловероятным, что эти 2+2+6 работают одинаково напряженно. Если так, нагрузка размажется хорошо и на 16 дисков.
Про IOPS и их зависимось от количества дисков я понял, спасибо за объяснения
-
- member
- Сообщения: 20
- Зарегистрирован: 21 май 2007, 15:56
- Откуда: Москва
А можно хоть вкратце про отличие вариантов от Infortrend, Xyratex и IBM? В частности, в Infortrend я могу ставить любые винты (не обязательно покупать их вместе с салазками от того же производителя), а в два остальных массива?gs писал(а):Варианты - Xyratex F5402E, IBM DS3400.
И буду благодарен, если вы пришлёте на мейл информацию по ценам и комплектации на решения от Xyratex и IBM.
- Tert
- Advanced member
- Сообщения: 4233
- Зарегистрирован: 19 янв 2003, 08:09
- Откуда: Москва
- Контактная информация:
progressor
Основное отличие в удобстве использования и цене.
Xyratex - самый простой в управлении массив.
IBM немного посложней.
Еще в Xyratex можно ставить SAS и SATA диски. Причем вместе. А в IBM 3400 только SAS.
Кроме того, покупая диски для Infortrend'а на стороне вы не можете быть уверенным, что они заработают без проблем с вашим массивом (хотя и есть лист совместимости, но он гарантирует работу только для дисков с определенными прошивками).
А предложения сейчас вышлем.
Основное отличие в удобстве использования и цене.
Xyratex - самый простой в управлении массив.
IBM немного посложней.
Еще в Xyratex можно ставить SAS и SATA диски. Причем вместе. А в IBM 3400 только SAS.
Кроме того, покупая диски для Infortrend'а на стороне вы не можете быть уверенным, что они заработают без проблем с вашим массивом (хотя и есть лист совместимости, но он гарантирует работу только для дисков с определенными прошивками).
А предложения сейчас вышлем.
-
- member
- Сообщения: 20
- Зарегистрирован: 21 май 2007, 15:56
- Откуда: Москва
gs
Ещё вопрос по SATA-винтам в Infortrend-е и Xeratex-е. Я так понял, что у Infortrend для работы с SATA-винтами, чтобы подключать их к redundant-контроллерам, нужен мультиплексор (MUX board). Таким образом он является единой точкой отказа - если он отказывает, то SATA-винты отваливаются? А SAS продолжают работать?
И как это организовано в Xeratex? Не появляется ли там из-за этого SPOF?
Ещё вопрос по SATA-винтам в Infortrend-е и Xeratex-е. Я так понял, что у Infortrend для работы с SATA-винтами, чтобы подключать их к redundant-контроллерам, нужен мультиплексор (MUX board). Таким образом он является единой точкой отказа - если он отказывает, то SATA-винты отваливаются? А SAS продолжают работать?
И как это организовано в Xeratex? Не появляется ли там из-за этого SPOF?
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 15 гостей