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

Как реализован рейд на уровне * диска *?

Если на дисках есть 512-байтовые физические сектора, и у вас есть 10 дисков, использующих RAID 50 с размером полосы 1 МБ, как это работает? на уровне диска?

Поправьте меня, если я ошибаюсь, но концептуально было бы 2 участка, каждый из которых состоял бы из массива RAID-5 из 5 дисков, один зеркально отображаемый на другой. Следовательно, «полоса» будет состоять из блоков данных 4x256 КБ плюс одного 256 КБ данных четности на полосу? или в "полосу" входит четность?

Что, если вы рассмотрите массив RAID 10 с 12 дисками? Было бы 6 пар зеркальных дисков с полосами поверх этих зеркал. Таким образом, для полосы размером 1 МБ полоса будет разделена на 6, чтобы получить 174 762 666 байт на диск, что соответствует 341 333 физических сектора на полосу. Это действительно 342 физических сектора на полосу?

Для тех, кто задается вопросом, почему я спрашиваю; Я пытаюсь определить наиболее эффективное количество дисков по отношению к типу RAID с наилучшим размером полосы.


Также я видел https://en.wikipedia.org/wiki/Nested_RAID_levels прежде чем задать этот вопрос. Фактически, я проделал тонну работы в поисках деталей низкоуровневого дизайна на огромном количестве сайтов поставщиков SCSI / SAS / RAID / SAN и не видел ничего, что говорило бы о реальном формате полос на диске. О полосах говорят только на очень концептуальном уровне, что нормально, но на самом деле не отвечает на вопрос.

Вы найдете всю необходимую информацию Вот.

По сути, все ваши предположения верны: RAID 50 - это чередование (RAID 0) массивов RAID 5, а RAID 10 - чередование массивов RAID 1.

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

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

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

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

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


Простой пример: Exchange последовательно записывает журналы транзакций базы данных в виде файлов размером 1 МБ; они в основном пишутся и редко читаются при нормальной работе; они могут занимать некоторое пространство, но никогда не слишком много, если выполняется регулярное резервное копирование, потому что они усекаются (т.е. самые старые удаляются) каждый раз, когда завершается полное резервное копирование базы данных.

Наилучшим подходом для хранения данных такого типа было бы использование массива RAID 1 из двух дисков с размером полосы 1 МБ, кэшем записи с резервным питанием от батареи, одним томом, отформатированным с файловой системой NTFS, и размером 1 МБ. размер кластера; о, и конечно тебе придется хранить только журналы транзакций для не замужем база данных на этом томе; если у вас больше БД, вам придется использовать другие тома и дисковые массивы, иначе вы потеряете все преимущества последовательного ввода-вывода. (Кстати, фактические данные базы данных должны быть отправлены в совершенно другое место, и не только из-за производительности, но в основном из-за безопасности данных; посмотрите документацию по Exchange, если вы хотите получить более подробную информацию; но основные моменты в том, что они совершенно разные. / O паттерны, и вы абсолютно не хотите проигрывать обе базу данных и журналы транзакций одновременно.)

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

Тонкая настройка хранилища - это искусство, и для его правильной работы требуется много анализа и опыта.

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

Кроме того, большую роль играют контроллеры и их прошивка. Например, дома у меня есть 8-портовый SAS / SATA HBA LSI, который можно прошить для работы в качестве RAID-контроллера. Такое же оборудование используется Dell, но микропрограмма устанавливает другую глубину очереди для поддержки определенных дисков Dell. Моя OEM-прошивка превосходит прошивку Dell примерно на 30% при использовании 5 потребительских дисков WD по 4 ТБ на моем домашнем компьютере. Если я прошью карту Dell OEM-прошивкой, производительность будет одинаковой.

ConcernedOfTunbridgeWells отмечает, что у вас крутится диск ...

Если вы можете запустить эту рабочую нагрузку в Linux / Unix, вы можете рассмотреть одну из файловых систем, которая позволяет SSD-кэширование магнитных дисков.

Дома я запускаю ZFS в Linux, и он чрезвычайно надежен благодаря гибкой проверке четности и непрерывной проверке согласованности на основе хешей. Он изначально поддерживает кэширование SSD и его молниеносную скорость с помощью только скромного SSD-накопителя. Массив ZFS с LSI в режиме HBA работает быстрее, чем использование LSI в качестве аппаратного массива. Рабочая нагрузка - виртуализация Openstack (моя лабораторная машина).

Еще лучше просто использовать надлежащий SAN или даже NAS, который знает, как адаптировать контроллеры, кеширование, чередование и т. Д. Для конкретных рабочих нагрузок.