Назад | Перейти на главную страницу

7.2K Near Line SAS с большим кешем RAID-контроллера против 10 / 15K SAS

Я работаю над приложением для сбора большого количества (более 10 миллионов) действительно небольших блоков данных (16 байт) каждый день. Данные не являются последовательными (то есть много попыток написать), и это не постоянный поток (бывают периоды тишины).

Перед приложением расположены кэширующие серверы, поэтому чтение - это не такая уж проблема, и я предполагаю, что только 1% данных будет представлять интерес в определенный день, и этот 1% будет находиться в кеше. Только первое чтение должно быть медленным.

У меня хороший, но ограниченный бюджет, и я хочу RAID 1, который удваивает стоимость моего диска.

Мой выбор:

Что бы вы сделали? Или, другими словами, компенсирует ли большой кеш на контроллере с точки зрения записи более медленное время поиска?

Мы магазин DELL, и я смотрю на R410 / R510.

Я не уверен, что вы получите здесь полезный ответ. Я бы проводил тесты с приложением и предполагаемым оборудованием, чтобы получить представление о том, как оно работает, потому что я подозреваю, что существует достаточно сложностей, поэтому попытка смоделировать его «изнутри», вероятно, будет слишком упрощенной.

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

Похоже, вы не используете стандартную систему управления базами данных, а, скорее, сами управляете хранилищем данных. Вам нужно будет оценить, как ваше приложение взаимодействует с диспетчером кеш-памяти ОС и базовой файловой системой (при условии, что вы не храните данные на необработанных дисковых блоках), а также с контроллером RAID. Если вы используете систему управления базами данных, то, очевидно, вам также придется увидеть, как она взаимодействует.

Когда вы говорите «работаю над», мне интересно, участвовали ли вы в разработке приложения. Если это так, я думаю, что стоит посмотреть на архитектуру приложения, которая буферизует входящие записи в последовательно записываемый журнал, а затем выполняет отложенную запись этого последовательного журнала в структуру хранилища с произвольным доступом. Фактически вы будете выполнять то же самое, что и кэширование контроллера, но у вас будет более детальный контроль над процессом (вы можете явно разделить хранилище для последовательного журнала по сравнению с журналом произвольного доступа).

Или, другими словами, компенсирует ли большой кэш контроллера с точки зрения записи более медленное время поиска?

В некоторой степени. Следует учитывать несколько факторов:

  • кэш будет иметь желаемый эффект только до тех пор, пока он не будет переполнен - ​​если ваши данные поступают пакетами или с постоянной скоростью, когда диски не могут справиться с нагрузкой, кеши будут заполнены, в худшем случае - ввод-вывод блокировать, пока кеши не опустятся до отметки низкого уровня воды для дальнейшей работы
  • Алгоритмы кэширования часто гарантируют, что данные в кеше не могут быть старше "X", инициируя сброс для них, даже когда еще есть место для большего количества
  • кэширование происходит «блоками», поэтому даже если ваши записи имеют размер всего 16 байт, это не означает, что вы можете хранить 67 миллионов записей в 1 ГБ кэш-памяти.
  • смешанная произвольная нагрузка чтения / записи трудна даже для большого кеша
  • вы вполне можете столкнуться с заполнением очередей команд даже с большими кешами, поэтому, если ваши требования к хранилищу включают не только IOPS и требования к пропускной способности, но и низкую задержку (низкое время обслуживания), этого будет сложно достичь с помощью данных параметров настройки

Некоторые математические вычисления: если предположить, что типичное время обслуживания для одного запроса составляет 20 мс для близких к сети дисков SATA, подсистеме ввода-вывода потребуется 200000 секунд, чтобы записать 10000000 на диски - это более 55 часов 100% использования диска. Если вы получаете такое количество запросов на запись в день, вы, вероятно, переполните свою подсистему ввода-вывода.

Насколько сильно вы столкнетесь с тем или иным граничным условием, во многом зависит от реализации контроллера и его механизма кэширования. Вам нужно будет провести тщательные тесты, чтобы не было неприятных сюрпризов.

Если кеш RAID является ограничивающим фактором (один из предыдущих ответов указывает на то, что это может быть), я бы подумал о добавлении некоторых умных средств к кешированию впереди, чтобы чередовать записи по отдельным массивам - скажем, 4 зеркала по 2 диска каждый - и хешировать место назначения, чтобы равномерно распределить нагрузку.

Это не улучшит использование кеша как таковое, но предоставит вам 4 набора независимых шпинделей для записи, что позволит избежать большей части задержки, связанной с необходимостью записи на все шпиндели одновременно.

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

Вы думали о H700 с кеш-памятью 512 или 1 ГБ, а затем добавляли один или два SSD для использования в качестве дополнительного кеша для дисков. Dell называет это своей технологией Cachecade.

Посмотреть здесь: http://www.dell.com/downloads/global/products/pedge/en/perc-h700-cachecade.pdf