RAID для «чайников» и не только

KDV, iBase.ru, 26.11.2004, последнее обновление – 27.02.2009.

Со времени первой публикации статьи, на forum.ibase.ru в ее обсуждении появилась масса интересных сообщений. Так что после чтения статьи рекомендую обязательно просмотреть топик на форуме.

В интернете есть масса статей с описанием RAID. Например, эта описывает все очень подробно. Но как обычно, читать все не хватает времени, поэтому надо что-нибудь коротенькое для понимания – а надо оно или нет, и что лучше использовать применительно к работе с СУБД (InterBase, Firebird или что то иное – на самом деле все равно). Перед вашими глазами – именно такой материал.

Примечание. Сейчас есть хорошая статья о RAID в Википедии.

В первом приближении RAID это объединение дисков в один массив. SATA, SAS, SCSI, SSD – неважно. Более того, практически каждая нормальная материнская плата сейчас поддерживает возможность организации SATA RAID. Пройдемся по списку, какие бывают RAID и зачем они. (Хотел бы сразу заметить, что в RAID нужно объединять одинаковые диски. Объединение дисков от разных производителей, от одного но разных типов, или разных размеров – это баловство для человека, сидящего на домашнем компьютере).
 

RAID 0 (Stripe)

Грубо говоря, это последовательное объединение двух (или более) физических дисков в один "физический" диск. Годится разве что для организации огромных дисковых пространств, например, для тех, кто работает с редактированием видео. Базы данных на таких дисках держать нет смысла – в самом деле, если даже у вас база данных имеет размер 50 гигабайт, то почему вы купили два диска размером по 40 гигабайт, а не 1 на 80 гигабайт? Хуже всего то, что в RAID 0 любой отказ одного из дисков ведет к полной неработоспособности такого RAID, потому что данные записываются поочередно на оба диска, и соответственно, RAID 0 не имеет средств для восстановления в случае сбоев.

Конечно, RAID 0 дает ускорение в работе из-за чередования чтения/записи.

RAID 0 часто используют для размещения временных файлов.
 

RAID 1 (Mirror)

Зеркалирование дисков. Если Shadow в IB/FB это программное зеркалирование (см. Operations Guide.pdf), то RAID 1 – аппаратное зеркалирование, и ничего более. Упаси вас от использования программного зеркалирования средствами ОС или сторонним ПО. Надо или "железный" RAID 1, или shadow.

При сбое тщательно проверяйте, какой именно диск сбойнул. Самый частый случай погибания данных на RAID 1 – это неверные действия при восстановлении (в качестве "целого" указан не тот диск).

Насчет производительности – по записи выигрыш 0, по чтению – возможно до 1.5 раз, т. к. чтение может производиться "параллельно" (поочередно с разных дисков) . Для баз данных ускорение мало, в то время как при параллельном обращении к разным (!) частям (файлам) диска ускорение будет абсолютно точно.
 

RAID 1+0

Под RAID 1+0 имеют в виду вариант RAID 10, когда два RAID 1 объединяются в RAID 0. Вариант, когда два RAID 0 объединяются в RAID 1 называется RAID 0+1, и "снаружи" представляет собой тот же RAID 10.
 

RAID 2-3-4

Эти RAID являются редкими, т. к. в них используются коды Хэмминга, либо разбиение байт на блоки + контрольные суммы и т. п., но общее резюме таково – эти RAID дают только надежность, при 0-вом увеличении производительности, и иногда даже ее ухудшении.
 

RAID 5

Для него нужно минимально 3 диска. Данные четности распределяются по всем дискам массива

Обычно говорится, что "RAID5 использует независимый доступ к дискам, так что запросы к разным дискам могут выполняться параллельно". Следует иметь в виду, что речь идет, конечно, о параллельных запросах на ввод-вывод. Если такие запросы идут последовательно (в SuperServer), то конечно, эффекта распараллеливания доступа на RAID 5 вы не получите. Разумеется, RAID5 даст прирост производительности, если с массивом будут работать операционная система и другие приложения (например, на нем будет находиться виртуальная память, TEMP и т. п.).

Вообще RAID 5 раньше был наиболее часто используемым массивом дисков для работы с СУБД. Сейчас такой массив можно организовать и на SATA дисках, причем он получится существенно дешевле, чем на SCSI. Цены и контроллеры вы можете посмотреть в статьях

• http://old.computerra.ru/2004/540/204913/
• http://www.thg.ru/storage/20040625/index.html

Причем, следует обратить внимание на объем покупаемых дисков – например, в одной из упомянутых статей RAID5 собирается из 4-х дисков объемом 34 гиг, при этом объем "диска" получается 103 гигабайта.

Тестирование пяти контроллеров SATA RAID – http://www.thg.ru/storage/20051102/index.html.

Adaptec SATA RAID 21610SA в массивах RAID 5 – http://www.ixbt.com/storage/adaptec21610raid5.shtml.

Почему RAID 5 - это плохо - https://geektimes.ru/post/78311/
  Объем дискового массива RAID5 расчитывается по формуле (n-1)*hddsize, где n – число дисков в массиве, а hddsize – размер одного диска. Например, для массива из 4-х дисков по 80 гигабайт общий объем будет 240 гигабайт.

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

Статья RAID-5 must die. И еще о потерях данных на RAID5.
   

RAID 10, 50

Дальше идут уже комбинации из перечисленных вариантов. Например, RAID 10 это RAID 0 + RAID 1. RAID 50 – это RAID 5 + RAID 0.

Интересно, что комбинация RAID 0+1 в плане надежности оказывается хуже, чем RAID5. В копилке службы ремонта БД есть случай сбоя одного диска в системе RAID0 (3 диска) + RAID1 (еще 3 таких же диска). При этом RAID1 не смог "поднять" резервный диск. База оказалась испорченной без шансов на ремонт.

Для RAID 0+1 требуется 4 диска, а для RAID 5 – 3. Подумайте об этом.
 

RAID 6

В отличие от RAID 5, который использует четность для защиты данных от одиночных неисправностей, в RAID 6 та же четность используется для защиты от двойных неисправностей. Соответственно, процессор более мощный, чем в RAID 5, и дисков требуется уже не 3, а минимум 5 (три диска данных и 2 диска контроля четности). Причем, количество дисков в raid6 не имеет такой гибкости, как в raid 5, и должно быть равно простому числу (5, 7, 11, 13 и т. д.)

Допустим одновременный сбой двух дисков, правда, такой случай является весьма редким.

По производительности RAID 6 я данных не видел (не искал), но вполне может быть, что из-за избыточного контроля производительность может быть на уровне RAID 5.

См. неплохую статью про RAID 6.
 

Rebuild time

У любого массива RAID, который остается работоспособным при сбое одного диска, существует такое понятие, как rebuild time. Разумеется, когда вы заменили сдохший диск на новый, контроллер должен организовать функционирование нового диска в массиве, и на это потребуется определенное время.

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

Время восстановления функционирования массива в нормальном режиме напрямую зависит от объема дисков. Например, Sun StorEdge 3510 FC Array при размере массива 2 терабайта в монопольном режиме делает rebuild в течение 4.5 часов (при цене железки около $40000). Поэтому, при организации массива и планировании восстановления при сбое нужно в первую очередь думать именно о rebuild time. Если ваша база данных и бэкапы занимают не более 50 гигабайт, и рост в год составляет 1-2 гигабайта, то вряд ли имеет смысл собирать массив из 500-гигабайтных дисков. Достаточно будет и 250-гигабайтных, при этом даже для raid5 это будет минимум 500 гигабайт места для размещения не только базы данных, но и фильмов. Зато rebuild time для 250 гигабайтных дисков будет примерно в 2 раза меньше, чем для 500 гигабайтных.
 

Резюме

Получается, что самым осмысленным является использование либо RAID 1, либо RAID 5. Однако, самая частая ошибка, которую делают практически все – это использование RAID "подо все". То есть, ставят RAID, на него наваливают все что есть, и ... получают в лучшем случае надежность, но никак не улучшение производительности.

Еще часто не включают write cache, в результате чего запись на raid происходит медленнее, чем на обычный одиночный диск. Дело в том, что у большинства контроллеров эта опция по умолчанию выключена, т.к. считается, что для ее включения желательно наличие как минимум батарейки на raid-контроллере, а также наличие UPS.

Текст
В старой статье hddspeed.htmLINK (и в doc_calford_1.htmLINK) показано, как можно получить существенное увеличение производительности путем использования нескольких физических дисков, даже для IDE. Соответственно, если вы организуете RAID – положите на него базу, а остальное (temp, OS, виртуалка) делайте на других винчестерах. Ведь все равно, RAID сам по себе является одним "диском", пусть даже и более надежным и быстродействующим.
признан устаревшим. Все вышеупомянутое вполне имеет право на существование на RAID 5. Однако перед таким размещением необходимо выяснить – каким образом можно делать backup/restore операционной системы, и сколько по времени это будет занимать, сколько времени займет восстановление "умершего" диска, есть ли (будет ли) под рукой диск для замены "умершего" и так далее, т. е. надо будет заранее знать ответы на самые элементарные вопросы на случай сбоя системы.

Я все-таки советую операционную систему держать на отдельном SATA-диске, или если хотите, на двух SATA-дисках, связанных в RAID 1. В любом случае, располагая операционную систему на RAID, вы должны спланировать ваши действия, если вдруг прекратит работать материнская плата – иногда перенос дисков raid-массива на другую материнскую плату (чипсет, raid-контроллер) невозможен из-за несовместимости умолчательных параметров raid.

Размещение базы, shadow и backup

Несмотря на все преимущества RAID, категорически не рекомендуется, например, делать backup на этот же самый логический диск. Мало того что это плохо влияет на производительность, но еще и может привести к проблемам с отсутствием свободного места (на больших БД) – ведь в зависимости от данных файл backup может быть эквивалентным размеру БД, и даже больше. Делать backup на тот же физический диск – еще куда ни шло, хотя самый оптимальный вариант – backup на отдельный винчестер.

Объяснение очень простое. Backup – это чтение данных из файла БД и запись в файл бэкапа. Если физически все это происходит на одном диске (даже RAID 0 или RAID 1), то производительность будет хуже, чем если чтение производится с одного диска, а запись – на другой. Еще больше выигрыш от такого разделения – когда backup делается во время работы пользователей с БД.

То же самое в отношении shadow – нет никакого смысла класть shadow, например, на RAID 1, туда же где и база, даже на разные логические диски. При наличии shadow сервер пишет страницы данных как в файл базы так и в файл shadow. То есть, вместо одной операции записи производятся две. При разделении базы и shadow по разным физическим дискам производительность записи будет определяться самым медленным диском.

Обсудить статью на форуме