Мой вопрос: когда уместно просто создать один большой массив с высокой производительностью чтения и записи, такой как RAID 10, вместо создания меньших массивов для конкретных приложений?
Мне кажется, что если мои общие требования к вводу-выводу не слишком велики, единый массив с отличной производительностью чтения и записи мог бы обеспечить лучшую производительность в целом для всех приложений, за исключением тех (возможно, редких) случаев, когда приложения с разными шаблонами доступа достигают максимума в то же время (копирование большого количества больших файлов во время захлопывания базы данных).
Если я выделяю пару шпинделей для конкретной задачи, такой как журналы транзакций, и они даже не беспокоятся о рабочей нагрузке ... почему бы просто не перенести эту рабочую нагрузку на более крупный RAID 10? Тогда эти шпиндели смогут вносить свой вклад в другие рабочие нагрузки, вместо того, чтобы сидеть и чесаться 60% времени.
PS, в моем конкретном случае накладные расходы на RAID 10 не имеют значения, потому что я ищу создание нескольких массивов RAID 1 и одного небольшого RAID 5. Переход на RAID 10 с объемом необходимого мне места будет сопоставимым.
Знание того, как настроить хранилище, сводится к измерению и составлению бюджета IOPS и пропускной способности. (Я здесь упрощаюсь, потому что размер процентного соотношения чтения / записи, среднего количества операций ввода-вывода, размера полосы RAID и процента попаданий в кеш имеет большое значение. Если вы можете получить эти числа, вы сможете сделать свои вычисления еще более точными.)
Есть действительно хороший калькулятор ввода-вывода Вот которые я часто использую при планировании хранилища. каталог хранилища wmarow также хорош для получения довольно современных показателей производительности дисков.
Если я выделяю пару шпинделей для конкретной задачи, такой как журналы транзакций, и они даже не ломают голову над рабочей нагрузкой ... почему бы просто не поместить эту рабочую нагрузку на более крупный RAID 10?
Помните, что установка последовательного ввода-вывода на шпиндель со случайным вводом-выводом делает этот последовательный ввод-вывод случайным. Диски журнала транзакций могут выглядеть так, как будто они не потеют, потому что вы видите последовательные операции ввода-вывода. Последовательные чтения и записи в том RAID-1 будут довольно быстрыми, поэтому, если вы, например, «не беспокоитесь» о длине дисковой очереди, вы не получите всей картины.
Измерьте или вычислите максимально возможное количество случайных операций ввода-вывода в секунду для предполагаемого целевого тома, возьмите базовый уровень текущей рабочей нагрузки на этом томе и затем решите, достаточно ли у вас места, чтобы поместить эти операции ввода-вывода в секунду журнала транзакций в оставшийся случайный ввод-вывод в целевом томе. Кроме того, не забудьте выделить место, необходимое для работы (очевидно). Если вы так склонны, добавьте процент дополнительного «запаса» в вашу рабочую нагрузку ввода-вывода / распределение пространства.
Продолжайте использовать эту методику для всех других рабочих нагрузок, которые вы хотите поместить в целевой том RAID-10. Если у вас заканчиваются случайные IOPS, значит, вы слишком много загружаете том - добавьте больше дисков или перенесите часть рабочей нагрузки на выделенные тома. Если вам не хватает места, добавьте диски.
В последнее время я читал больше статей, в которых говорилось, что RAID 5 - плохой способ обеспечить надежность. Я верю в это больше после того, как диск вышел из строя в массиве RAID 5, заменил диск и не смог восстановить, потому что на втором диске была скрытая неисправимая ошибка чтения, которая вынудила нас переформатировать и восстановить из резервной копии.
По мере увеличения размера дисков вероятность наличия необнаруженной неисправимой ошибки чтения на этих огромных дисках также возрастает, а с RAID 5 надежность просто больше не сокращается. Если вы не зеркалируете, по-видимому, советуем использовать RAID 10.
Если вы не делаете что-то очень чувствительное к проблемам скорости, я бы не стал беспокоиться о разбиении вещей на небольшие массивы или что-то в этом роде. Поместите его в RAID 10 и посмотрите, насколько хорошо вы работаете. При правильном кешировании и памяти в системе все должно быть в порядке. Цифры для тестов никогда не будут тем, что вы действительно получите, потому что это зависит от вашего фактического использования, фактической нагрузки, производительности жесткого диска, кэширования контроллера, кэширования диска, фрагментации и т. Д.
Лучшее практическое правило - максимально упростить конфигурацию, потому что даже если вы потратите день или неделю на эту установку через год или два, вам придется устранять некоторые проблемы на этом сервере, которые останутся Вам интересно, почему вы так настроили, если вы добавили в конфигурацию ненужных сложностей.
Насколько предсказуемыми должны быть задержки для ваших приложений?
Скажем, например, у вас есть одно приложение, которое действительно чувствительно к задержкам, и оно использует файловую систему совместно с вашей финансовой базой данных. При закрытии финансового отчета вы внезапно получаете звонки о тайм-ауте приложения, чувствительного к задержке. Как ты собираешься это понять?
С другой стороны, я большой поклонник упрощения всего, поэтому я бы проверил, что у вас нет каких-либо исключительных требований, а также консолидировал и упростил ваши конфигурации, если ваши требования не попадают в какие-либо странные особые случаи.
Конечно - почему бы и нет. Дело в том, что не забудьте правильно построить свой большой многодисковый массив, сделайте это неправильно, и вам придется долго перестраивать.
RAID 10 бывает двух видов:
Как только диск умирает, вам просто нужно будет восстановить один массив raid1. С другим вам придется перестроить весь массив raid0.