Какая рекомендуемая конфигурация RAID для базы данных Oracle?

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

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

Рассмотрим обсуждение на AskTom , OTN форум , OTN Форумы 2 и OTN Форумы 3 .

Не существует единого правильного способа справиться с вещами, и ответы меняются в зависимости от множества аппаратных и сетевых факторов. Чтобы открыть для себя, предварительно загрузите пример хранилища данных (всего один или два гигабайта, с которым достаточно поиграть) на машине на базе ASM, в сети SAN с виртуализацией Raid под Linux и на аппаратной рейд-машине.

По времени результаты запросов во всех трех средах, вы сможете определить, какая методология работает лучше для вас с точки зрения производительности. Я развернул базы данных, используя ASN и виртуальные рейды на основе Linux, и виртуальный рейд вел себя немного лучше (несколько лет назад). Однако, я подозреваю, что это отчасти было способом установки дисков.

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

--Редактировать--

Каждая « группа дисков » может состоять из одного или нескольких дисков, каталогов или файлов в соответствующей подсистеме. Oracle рекомендует: «Для лучшей производительности и надежности выберите устройство RAID или логический том на нескольких физических устройствах и внедрите методологию чередования и зеркалирования (SAME)». при размещении файлов в файловой системе. Это выглядит так, как будто оракул рекомендует RAID 1 + 0.

ASM управляемые группы дисков, однако: «Для группы дисков с избыточным резервированием требуется как минимум две группы отказов (или два дисковых устройства), если вы используете двустороннее зеркалирование. Эффективное дисковое пространство в группе дисков с избыточным резервированием составляет половину суммы дисковое пространство во всех его устройствах ", по-видимому, автоматически обеспечивает зеркалирование.

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

Если у вас есть два физических диска:

RAID0: быстрый, но без резервирования. Любая ошибка диска уничтожит весь массив. Некоторые люди помещают временное хранилище на RAID0 (то есть, tempdb под MSSQL), но я все равно считаю это опасным, так как пока вы не потеряете значимые данные, если массив упадет, у вас будет отключение сервера до тех пор, пока ситуация не будет восстановлена.

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

Если у вас есть три физических диска:

Вы можете выбрать RAID5, нестандартный RAID10 с тремя дисками (или RAID1E, как на это указывают контроллеры IBM), если он поддерживается. Конечно, вы могли бы использовать RAID1 и оставить дополнительный диск в качестве запасного на случай отказа одного из других, но вы все равно должны хранить запасные части в критически важной среде, так что это само собой разумеется.

RAID5 предлагает больше места, чем RAID10 (два диска вместо полутора), но имеет потенциальную проблему с производительностью записи, поскольку для каждого записанного блока контроллер должен прочитать блок четности, обновить его и записать обратно. Эта проблема производительности записи может быть удвоена для записей базы данных, так как для каждого обновления существует как минимум две записи: одна в журнал транзакций и одна в фактические области данных. Поскольку в наши дни пространство дешевое, я бы порекомендовал 3-дисковый RAID10, если он поддерживается, для лучшей производительности записи. Программный RAID Linux предлагает это, как и многие контроллеры IBM (они называют его RAID1E). Вы можете найти его и под другими именами, поскольку оно не считается стандартным, поэтому не имеет стандартного имени.

И R5, и R10-over-three обеспечивают одинаковую избыточность (любой диск может выйти из строя за раз, и массив выживет) и аналогичные показатели производительности чтения (аналогично массиву RAID0 с двумя дисками).

Если у вас есть четыре физических диска:

Если создается только один массив, то есть два варианта (игнорируя варианты с «горячим резервированием»): RAID6 и «традиционный» RAID10 (RAID0 из RAID1).

Оба дают одинаковое пространство (два диска из четырех). RAID6 обеспечивает лучшую избыточность, так как любые два диска могут выходить из строя в тот момент, когда RAID10 может выжить только в четырех из шести возможных ситуаций с двумя дисками. Оба дают производительность чтения simialr, но RAID6 имеет проблему с производительностью записи, аналогичную производительности RAID5 (то же самое на хорошем контроллере, хотя он может быть медленнее, чем RAID5 на плохом контроллере или с программным RAID в зависимости от ОС и возможностей управления вводом / выводом. RAID10 является обычно предпочтительнее для баз данных из соображений производительности - если вам нужна дополнительная избыточность, вы можете использовать шесть дисков и иметь RAID0 или два 3-дисковых RAID1.

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

Если у вас более четырех дисков:

Ваши параметры становятся здесь широко открытыми, и это действительно зависит от того, какие у вас есть данные и каковы ожидаемые обновления / прочитанные загрузки / шаблоны. Например, одна из наших служб работает на дисках 12 ~ 70 Гб:

• 4x как RAID10 для системных областей (ОС, SQL Server (в нашем случае MSSQL), swap, tempdb).
• 4x как RAID10 для файлов данных
• 4x как RAID10 для журналов транзакций

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

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

Если у вас шесть дисков, вы можете рассмотреть три массива RAID1 или два массива RAID10 с тремя дисками.

Обычно

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

• избегайте RAID5 и 6, если только вы не знаете, что проблема производительности записи не окажет на вас существенного влияния
• с четырьмя или более дисками на основе вращающегося диска рассмотрите возможность разделения вещей на несколько массивов, чтобы уменьшить перемещения головы (полное преимущество нескольких массивов не будет применимо к хорошим твердотельным накопителям, поскольку нет необходимости учитывать физические движения головы, хотя вы можете увидеть некоторые различия в зависимости от стратегия комбинирования записи контроллера SSD и т. д.)
• тестируйте, тестируйте и тестируйте снова: всегда полезно попытаться найти время, чтобы убедиться, что выбранное вами расположение действительно оптимально

Аппаратный или программный RAID?

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

Хороший аппаратный RAID может предложить и другие преимущества: некоторые высокопроизводительные контроллеры имеют кэш записи с резервным питанием от батареи, так что ожидающие записи не теряются при отключении питания, даже если, например, происходит сбой вашего ИБП.

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

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

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

« Руководство по настройке производительности базы данных Oracle » содержит главу, посвященную настройке ввода-вывода . Короче говоря:

• Используйте чередование (аппаратный RAID, программный RAID, ASM)
• Не используйте RAID5 для архивации и повторения журналов
• Выровнять размер блока файловой системы и размер блока БД

В некоторых случаях JBOD является правильным ответом (т.е. не RAID).

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

Вы можете использовать чередование (RAID0), чтобы сбалансировать записи, но если это одна большая группа, вы не можете отделить индексы от записей.

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

Я бы никогда не пошел RAID5 или RAID6 на базу данных. Если данные важны, купите больше дисков и используйте RAID1; RAID5 / 6 медленный (особенно в программном обеспечении), и с учетом сегодняшних размеров жесткого диска может потребоваться несколько дней для восстановления после замены неисправных дисков для большой группы дисков ... не говоря уже о том, что большинство систем RAID5 / 6 исправляют ошибки четности просто пересчитать четность ... но есть вероятность, что ошибка в данных, а не четность, но вы не знаете, где была ошибка. (к сожалению, я не думаю, что есть что-то вроде LOCKSS для баз данных)

...

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

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

...

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

Базы данных, с которыми я имею дело, - это то, что мой босс называет «WORN»: «Пиши один раз, читай никогда»; он шутит, но «хранилище данных» может означать любой уровень активности ... Я видел некоторые, которые загружались с ленты каждую ночь / каждую неделю (и были просто копиями экземпляра OLTP, и помогли нам убедиться, что ленты были хорошими) и на них выполнялись массовые аналитические задания, а также другие, где постоянный поток входных и случайных чтений, но нет реальной конкуренции за ресурсы.

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

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

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

Основы идут так:

RAID0

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

RAID1

Отлично подходит для надежности. Не много расширяемости. Довольно хорошо по скорости.

RAID5

Предпочтительное сочетание между RAID0 и RAID1 (вроде).

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