3.4 Размер массива

Применение чередования для хранения данных позволяет равномерно распределить нагрузку на ввод/вывод между всеми доступными дисками, что побуждает использовать большие дисковые массивы. Однако увеличение числа дисков в массиве ведет к росту частоты отказов. Рассмотрим эти два вопроса вместе для определения метода выбора оптимального числа дисков в массиве.

3.4.1 Пропускная способность

Чередование, при корректном использовании, является прекрасным инструментом для увеличения пропускной способности. Чередование предоставляет прозрачное распределение операций ввода/вывода между относительно недорогими дисками. Это, с одной стороны, дает возможность обслуживать одновременно большое число небольших операций ввода/вывода, а с другой, — увеличить в разы скорость обмена больших операций ввода/вывода по сравнению со скоростью самого быстрого диска [Chen et al. (1993), 151].

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

1. Определите устойчивую максимальную пропускную способность каждого из Ваших жестких дисков. Этот показатель оценивается как устойчивое максимальное число операций ввода/вывода для каждого жесткого диска ¹⁰. Обозначим этот показатель как c, размерность — число операций ввода/вывода в секунду.
2. Оцените общее число t операций ввода/вывода, которое будут генерировать одновременно работающие транзакции.
3. Рассчитайте общее число r физических операций ввода/вывода в секунду, которые требуются от Вашего RAID-массива, с учетом размера сегмента чередования, используя формулу:

   

   где k — размер сегмента чередования деленный на размер блока ввода/вывода (описание см. выше в обсуждении размера сегмента чередования). К примеру, если Ваше приложение генерирует 300 операций ввода/вывода в секунду на массиве, а размер сегмента чередования в два раза больше запросов на ввод/вывод, то Ваш массив должен в состоянии поддержать обработку 450 физических операций ввода/вывода в секунду.
4. Рассчитайте минимальное число дисков g = r/c, которые необходимо включить в дисковый массив, для поддержания требуемой нагрузки:

   

5. Обратите внимание, что требуемая пропускная способность r (определенная на шаге 2) может зависеть от размера Вашего дискового массива g (рассчитанного на шаге 4). Например, половина дисков от необходимого числа, могут обслужить примерно половину запросов на ввод/вывод от транзакций. Поставщик оборудования может дать информацию о максимальном рекомендуемом числе дисков в дисковом массиве.

Приведенные формулы могут использоваться для расчета дисковых массивов RAID 0 и RAID 0+1. Если Вы будете использовать эту технику для расчета массива RAID 5, то Вам необходимо увеличить оценку необходимого числа запросов на ввода/вывода на одну транзакцию для отражения того факта, что этот массив имеет большие издержки при выполнении каждой операции записи. Влияние дискового кэша, уменьшающего степень этих издержек, несколько усложняет эти вычисления.

3.4.2 Доступность

Расчет правильного размера дискового массива в случае использования RAID 3 или RAID 5 является несколько более трудоемким, чем просто расчет необходимых устройств для поддержки требуемой пропускной способности. Дополнительные сложности связаны с падением производительности конфигураций RAID 3 и RAID 5 во время отказа одного из дисков.

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

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

3.4.3 Резюме

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

Для массивов RAID 1 и RAID 0+1, бОольшие размеры массивов увеличивают производительность без снижения устойчивости к отказам, конфигурации RAID 3 и RAID 5 при увеличении размера показывают лучшую производительность, но при этом их устойчивость к отказам падает.

3.5 Линейные устройства

Линейные устройства являются важным инструментом, который использует архитектор VLDB, для снижения загрузки ЦПУ приложениями с высокой интенсивностью записи. Линейное устройство (raw device) — это неформатированный раздел диска в UNIX, который сервер Oracle может открыть как файл данных или как оперативный журнал минуя службы буферизации ввода/вывода UNIX-системы. Возможность сервера Oracle обходить буферизацию UNIX уменьшает объем кода операционной системы, который будет выполнен при вызове операций записи. В связи с этим, линейные устройства рекомендуются для хорошо спроектированных VLDB с высокими требованиями транзакционной пропускной способности.

Линейные устройства, на сегодняшний день, являются необходимыми, если Вы планируете использовать параллельный сервер Oracle (Oracle Parallel Server) под UNIX. Большинство UNIX-реализаций не позволяют двум узлам кластера иметь одновременный доступ к смонтированной файловой системе.

Стоимость обслуживания линейных устройств выше, чем для файловых систем UNIX (ufs) [4, Millsap (1995a), 15–17]. Но для VLDB с интенсивной записью эта цена крайне мала в сравнении со стоимостью ненужной загрузки ЦПУ и уже без того высокой ценой администрирования системы с сотнями или тысячами дисковых устройств.

• Производительность при случайном чтении — Крайне незначительно лучше по сравнению с ufs.
• Производительность при случайной записи — Значительно лучше, в сравнение с ufs, изза уменьшения объема выполняемого кода. Линейные устройства также позволяют реализовать асинхронный ввод-вывод, если он поддерживается операционной платформой.
• Производительность при последовательном чтении — Незначительно хуже в сравнение с ufs. Использование линейных устройств может катастрофически снизить производительность плохо оптимизированных SQL-приложений по сравнению с ufs-реализацией, поскольку UNIX-кэширование работает лучше кэширования сервера Oracle при полном сканировании таблиц.
• Производительность при последовательной записи — Значительно лучше, в сравнение с ufs, из-за уменьшения объема выполняемого кода и возможности асинхронного ввода/вывода.
• Частота отказов — Риск возникновения возрастает из-за необходимости в более опытном администраторе.
• Длительность простоя — Риск увеличения возрастает из-за необходимости в более опытном администраторе.
• Снижение производительности в течение отказа — Отличия от нормальной производительности обусловлены замечаниями приведенными выше.
• Стоимость приобретения — Та же, что для ufs.
• Стоимость обслуживания — Хуже, чем для ufs. Требуется большее обучение и оплата труда персонала для конфигурирования и обслуживания линейных устройств. Конфигурирование линейных устройств также требуют закупки или разработки программных средств для упрощения управления подсистемой ввода/вывода. Различие стоимости администрирования линейных устройств и ufs незаметны на фоне общей стоимости системы ввода/вывода для VLDB с тысячами дисков. Стоимость обслуживания оперативных журнальных файлов не изменяется, поскольку эти файлы архивируются также как на ufs процессом ARCH.

3.6 Конфигурация Oracle

Не существует такой вещи, как единая оптимальная конфигурация СУБД Oracle для всех VLDB-приложений. Ваша оптимальная смесь скорости, надежности и экономичности зависит от Ваших конкретных задач. Однако мы может сделать некоторые заключения о том, как Вы могли бы выполнить оптимизацию Вашей конфигурации VLDB, если бы Вы не были связаны экономическими ограничениями:

• Контрольные файлы
  • n-кратное дублирование RAID 0+1
  • размещение на независимых подсистемах ввода/вывода
  • линейные устройства в случае OPS
• Оперативные журнальные файлы
  • все файлы одного размера
  • линейные устройства
  • n-кратное дублирование RAID 0+1
  • малый размер сегмента чередования
  • размещение на выделенных дисках
• Архивные журнальные файлы
  • ufs
  • n-кратное дублирование RAID 0+1
  • малый размер сегмента чередования
  • размещение на выделенных дисках отдельно от оперативных журнальных файлов
• Файлы данных
  • все файлы одного из трех стандартных размеров
  • линейные устройства, если файл активно изменяется, либо используется OPS
  • ufs, если используется полное сканирование таблиц
  • n-кратное дублирование RAID 0+1
  • размер сегмента чередования равен, как минимум, 2 × размер ввода/вывода, если высокий уровень параллелизма
  • размер сегмента чередования меньше чем 2 × размер ввода/вывода, если низкий уровень параллелизма
  • RAID 5, если низкая активность изменений файла
• Другие файлы
  • ufs
  • n-кратное дублирование RAID 1
  • размещение согласно стандарту OFA

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

3.6.1 Примеры конфигураций

Вы можете смешивать и оценивать технологии большим числом способов. Три простых конфигурации БД сервера Oracle представлены в таблице 3.

Каждая из них требует разного уровня инвестиций для достижения заданных целей, определенных в конфигурации.

• Конфигурация A — Дублирование (n = 2, 3) RAID 0+1 для всех файлов, линейные устройства везде, где это возможно. Может использоваться для решения критически важных задач, OPS, очень высокая скорость транзакций, очень высокая скорость выполнения запросов, сложность обслуживания, высокая стоимость.
• Конфигурация B — RAID 0+1 на линейных устройствах для файлов с интенсивным уровнем изменений, RAID 5 на ufs для нечасто изменяемых файлов. Сравнительно высокая доступность, непригодна для OPS, средняя скорость выполнения транзакций, очень высокая скорость выполнения запросов, средняя сложность обслуживания, средняя стоимость.
• Конфигурация C — RAID 0+1 на линейных устройствах для файлов с интенсивным уровнем изменений, RAID 0 на ufs для всех остальных файлов Oracle. Непригодна для решения критически важных задач, непригодна для OPS, средняя скорость выполнения транзакций, очень высокая скорость выполнения запросов, низкая сложность обслуживания, низкая стоимость.

---

10(к тексту)

Указанный устойчивый уровень операций ввода/вывода рассчитывается поставщиком жесткого диска как наивысший уровень которого может достичь диск с коэффициентом утилизации, не превышающем 60%–70%. Приведенное ограничение на утилизацию дает возможность удерживать время ожидания в предсказуемых границах.

---

Назад Содержание Вперёд