Dell R320 RAID 10 с CacheCade

Я ищу более производительную сборку для наших серверов Dell R320 высотой 1RU с точки зрения IOPS.

Прямо сейчас я вполне определился:

• 4 x 600 ГБ, 3,5 дюйма, 15 тыс. Об / мин SAS
• RAID 1 + 0 массив

Это должно дать хорошую производительность, но, если возможно, я хочу также добавить кэш SSD, но я не уверен, достаточно ли места?

Согласно технические характеристики, всего доступно до 4 отсеков для 3,5-дюймовых дисков.

Есть ли способ разместить хотя бы один SSD-накопитель рядом с 4x3,5-дюймовыми дисками? Я надеялся, что есть специальное место для размещения SSD-накопителя с кешем (хотя по памяти, я сомневаюсь, что там будет место). Или Правильно ли я думаю, что кэш-диски - это просто диски, подключенные «нормально», как и любой другой диск, но назначенные в качестве дисков CacheCade в контроллере PERC?

Существуют ли какие-либо варианты использования массива RAID 10 размером 4x600 ГБ, а также SSD-кеш-накопителя?

Судя по техническим характеристикам (до 8x2,5-дюймовых дисков), возможно, мне нужно использовать 2,5-дюймовые диски SAS, оставив еще 4 свободных отсека, достаточно места для кэш-накопителя SSD.

Кто-нибудь как-нибудь добился этого с помощью 3,5-дюймовых дисков?

Изменить: дополнительная информация о требованиях

Чтобы дать представление об использовании / требованиях к этому оборудованию:

• В настоящее время у нас есть несколько «внутренних» виртуальных машин, работающих на хосте VMWare ESXi 5.x. Но на данный момент у нас всего несколько хостов, это базовая настройка.

• Недавно мы начали развертывание Dell R320 в качестве стандартного оборудования для общих хостов ESXi. Я бы предпочел придерживаться R320, чтобы сохранить наше оборудование (и, следовательно, нашу потребность в запасных частях, обновлениях, поддержке мониторинга и т. Д.) Как можно более стандартизированным. Лучше держать другой набор дисков в качестве запасного, чем хранить запасное шасси целиком поверх того, что у нас уже есть.

• Эти виртуальные машины несут основную ответственность за наши внутренние инструменты (такие как мониторинг, учет звонков, сайты в интрасети). Или общая инфраструктура; такие как: DNS, SMTP Relay / Filtering, небольшой набор общих веб-сайтов; общая VOIP АТС.

• Каждая из этих ролей при необходимости разделена на виртуальные машины относительно небольшого размера. Почти все из них - коробки Linux. У некоторых из них есть загрузка базы данных, но я бы посчитал их очень маленькими (достаточно, чтобы я согласился с размещением отдельных экземпляров MySQL на каждой виртуальной машине для изоляции, где это необходимо).

• В целом производительность в порядке. По иронии судьбы, главным катализатором появления этого нового оборудования является SMTP-реле. Всякий раз, когда мы получаем письмо от клиента приличного размера, это вызывает большое отставание в наших фильтрах. Я подтвердил, что это связано с дисковым вводом-выводом.

• Учитывая характер других виртуальных машин, работающих на этом хосте, несмотря на очевидную конкуренцию за дисковый ввод-вывод, никакого реального воздействия не наблюдается, за исключением отставания почты - VOIP в основном находится в памяти; посещаемость всех внутренних сайтов настолько низка, что загрузка страниц остается приемлемой; у нас не было никаких отчетов о проблемах клиентов, с которыми сталкиваются виртуальные машины на этом конкретном хосте.

Цели этого оборудования

К сожалению, у меня нет точных цифр с точки зрения того, какой IOPS я хочу достичь. Я чувствую, что это будет сложно протестировать, учитывая различную природу виртуальных машин, которые я хочу там разместить - это не значит, что у меня есть одно приложение, с которым я могу провести сравнительный анализ для гарантированной цели.

Я полагаю, что лучше всего было бы настроить тест с наихудшими нарушителями (например, веб-сайты с поддержкой DB и реле SMTP) и имитировать некоторую высокую нагрузку. Возможно, я этим займусь на следующей неделе.

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

В любом случае я постараюсь дать вам приблизительное представление о целях:

• Чтобы разумно пережить падение производительности во время рассылки, инициированной крупным заказчиком (чего они не должны делать!). Конечно, я понимаю, что это превращается в «каков длина веревки?» Поскольку вы не можете точно предсказать, насколько большой может быть данная рассылка. Но в основном я знаю, что это проблема с дисковым вводом-выводом, поэтому я пытаюсь добавить несколько дополнительных операций ввода-вывода в секунду на этом конкретном наборе хостов, чтобы иметь возможность обрабатывать внезапный всплеск почты.

• Я думаю, что при большом количестве небольших электронных писем это обычно будет в основном случайный ввод-вывод, который лучше всего подходит для SSD. Хотя я уверен, что в обозримом будущем мы могли бы обойтись без них.

• ** Как было сказано ранее, вышесказанное действительно является катализатором этого. Я понимаю, что могу поместить SMTP-реле на их собственное физическое оборудование и в основном с этим покончить. Но я стремлюсь к более общему решению, чтобы позволить всем нашим внутренним виртуальным машинам иметь доступ к вводу-выводу, если это необходимо).

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

• Мой план состоит в том, чтобы иметь как минимум два хоста (на данный момент) с одними и теми же виртуальными машинами и настроить активное / пассивное резервирование для каждой пары (не будет использовать vCenter, а скорее отказоустойчивость конкретного приложения).

• Я потенциально буду развертывать больше виртуальных машин на этом хосте в будущем. Одна вещь, которую я ищу, - это пара общих виртуальных машин MySQL и MS SQL. Если бы я поступил так, я бы определенно посмотрел на твердотельные накопители, чтобы у нас была центральная пара серверов БД, которые были бы избыточными и высокопроизводительными. Но это будет дальше, и в этом случае я, вероятно, выделил бы отдельное оборудование для каждого узла.