Тысячи пользователей систем хранения NetApp успешно установили и используют СУБД Oracle на системах хранения NetApp для своих критически важных задач и приложений. NetApp и Oracle совместно работают несколько лет, для того, чтобы проверить и подтвердить корректную работу продуктов Oracle при использовании их на системах NetApp и широком спектре серверных платформ. NetApp и техподдержка Oracle создали совместную команду по отработке пользовательских задач, и проблем совместного использования наших продуктов. В процессе работы над такими проблемами удалось установить, что большинство их вызвано отклонениями от рекомендаций Best Practices при использовании Oracle на NetApp

Этот документ описывает наилучшие методы и решения задач по запуску СУБД Oracle на системах хранения NetApp, при использовании на серверных платформах OS Solaris™, HP/UX, AIX, Linux^®, и Windows^®. Этот документ отражает работу, проделанную NetApp, Oracle, и инженерами NetApp на различных пользовательских инсталляциях и задачах. Этот документ должен рассматриваться как стартовая точка и предлагает минимум требований, которые должны быть удовлетворены при развертывании Oracle на NetApp.

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

2. Конфигурирование NetApp

2.1. Сетевые настройки

При конфигурировании сетевых интерфейсов на новой системе, наилучшим решением будет запустить команду setup, чтобы автоматически настроить интерфейсы и обновить файлы /etc/rc и /etc/hosts. Команда setup потребует перезагрузки, для применения сделанных настроек.

Однако если система уже работает, и перезагрузка нежелательна, то интерфейсы могут быть сконфигурированы с помощью команды ifconfig. Если NIC уже включены и в онлайне, и требуют переконфигурирования, вы сначала должны перевести их в оффлайн. Для минимизации даунтайма интерфейса, группу последовательно выполняемых команд можно объединить в одну строку с помощи символа «точка с запятой» (semicolon, ' ; ').

Пример:

filer>ifconfig e0 down;ifconfig e0 'hostname'-e0 mediatype auto netmask

255.255.255.0 partner e0

При конфигурировании и реконфигурировании NIC или VIF в кластере, очень важно включить соответствующий partner <interface> name или VIF name в конфигурацию NIC или VIF партнера в кластере, чтобы обеспечить отказоустойчивость в случае кластерного takeover. Пожалуйста, проконсультируйтесь со специалистом в поддержке NetApp, чтобы получить необходимую помощь. NIC или VIF, которые используются базой данных не должны переконфигурироваться, когда база данных работает. Это может вызвать серьезное повреждение базы.

2.1.1. Ethernet — Gigabit Ethernet, Autonegotiation, и Full Duplex

Любая база данных, использующая систему хранения NetApp, должна использовать Gigabit Ethernet как на стороне системы хранения, так и на стороне сервера базы данных.

Адаптеры NetApp Gigabit II, III, и IV разработаны для автоматического определения конфигурации интерфейса, и имеют возможности интеллектуально самоконфигурироваться, если процесс autonegotiation не удался. По этой причине, NetApp рекомендует, чтобы линки Gigabit Ethernet на клиентах, коммутаторах, и системах NetApp, оставались в их состоянии по умолчанию, то есть «autonegotiation», если линк не поднимается, производительность низка, или существуют иные проблемы соединения. Это позволит минимизировать путь поиска источника проблем.

Значение flow control должно быть установлено в «full» на системе хранения, в файле /etc/rc, записью вида (предположим, что интерфейс Ethernet у нас e5):

ifconfig e5 flowcontrol full

Если вывод команды ifstat –a не показывает flow control типа full, то тогда порт коммутатора также должен быть настроен, для поддержки этого значения. (Команда ifconfig на системе хранения всегда покажет установленные в настройках значения; ifstat, напротив, покажет, как flow control был на самом деле распознан на коммутаторе.)

2.2. Настройки и опции Volume (том) и Aggregate

2.2.1. Базы данных

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

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

2.2.2. Aggregates и FlexVol Volumes или Traditional Volumes

Начиная с Data ONTAP™ 7G, системы хранения NetApp поддерживают объединение большого числа дисков в структуру «aggregate», и построение виртуальных томов ( так называемых томов типа FlexVol) поверх этих дисков. Все это имеет множество преимуществ для баз данных Oracle, см подробности в [1].

Для баз данных Oracle рекомендуется помещать все ваши диски в один большой aggregate и использовать тома FlexVol для датафайлов и логфайлов, как будет описано ниже. Это обеспечивает преимущества более простого администрирования, особенно для растущих или уменьшающихся томов без влияния на производительность. Для деталей относительно точных рекомендаций по разбивке, смотрите [2].

2.2.3 Размеры тома

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

2.2.4 Рекомендации по типам томов для баз данных и логов Oracle

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

В случае Flexible Volumes и Aggregates

Database binaries	Выделенный FlexVol volume
Database config files	Выделенный FlexVol volume	Multiplex with transaction logs
Transaction log files	Выделенный FlexVol volume	Multiplex with config files
Archive logs	Выделенный FlexVol volume	Используйте SnapMirror
Data files	Выделенный FlexVol volume
Temporary datafiles	Выделенный FlexVol volume	Выключите на нем снэпшоты
Cluster related files	Выделенный FlexVol volume

В случае Traditional Volumes

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

2.2.5. Oracle Optimal Flexible Architecture (OFA) на NetApp

Распределите файлы по различным томам на различных физических дисках, чтобы обеспечить балансировку нагрузки ввода-вывода:

Отделите файлы с высоким уровнем ввода-вывода от системных файлов, для лучшего времени отклика
Упростите резервное копирование и восстановление data- и log-файлов, поместив их в отдельные логические тома.
Убедитесь в возможности быстрого восстановления, для минимизации простоя после сбоя
Обеспечьте логическое разделение компонентов Oracle, для упрощения обслуживания и администрирования
Архитектура OFA хорошо работает со структурой multiple Oracle home (MOH)

Для дополнительных сведений про Oracle OFA для RAC или Non-RAC и для сведений об Oracle9i в сравнении с Oracle10g, посетите следующие ссылки:

OFA для Non-RAC:
http://download-west.oracle.com/docs/html/B14399_01/app_ofa.htm#i633126
Для RAC, OFA для ORACLE_HOME:
http://download-west.oracle.com/docs/cd/B19306_01/install.102/b14203/apa.htm#CHDCDGFE

Тип файлов	Описание	Точка монтирования OFA	Размещение
ORACLE_HOME	Oracle libraries and binaries	/u01/app/oracle/product/9.2.0/ /u01/app/oracle/product/10.1.0/db_unique_name	Локальная файловая система или система хранения
Database files	Oracle database files	/u02/oradata	Директория NFS на системе хранения
Log Files	Oracle redo archive logs	/u03/oradata	Директория NFS на системе хранения
CRS_HOME (For 10.1.x.x RAC)	Oracle CRS HOME	/u01/app/oracle/product/10.1.0/crs_1	Директория NFS на системе хранения
CRS_HOME (For 10.2.x.x RAC)	Oracle CRS HOME	/u04/crs/product/10.2.0/app/ (Oracle 10g™ R2)	Директория NFS на системе хранения

2.2.6. Размещение Oracle Home

Структура OFA достаточно гибка, чтобы размещать ORACLE_HOME на локальной файловой системе, или на смонтрованном томе NFS. Для Oracle 10g, ORACLE_HOME может быть совместно использован конфигурацией RAC, когда один набор программ (binaries) и библиотек (libraries) совместно используются различными экземплярами (instances) той же базы

Некоторые детали совместного использования ORACLE_HOME рассматриваются ниже.

Что такое совместно используемый (Shared) ORACLE_HOME?

Совместно используемый (shared) ORACLE_HOME это директория ORACLE_HOME, совместно используемая двумя или более хостами. Это директория установки ПО, и, обычно, содержит программы, библиотеки, сетевые файлы (listener, tnsnames, и т.д....), oraInventory, dbs, и т.д.
Совместно используемый ORACLE_HOME, это директория ПО Oracle, которая смонтирована с сервера NFS, и имеет доступ сразу с 2 или более хостов по одному и тому же пути.
Директория ORACLE_HOME будет выглядеть, в соответствии с OFA, примерно как (/u01/app/oracle/product/10.2.0/db_1).

Что поддерживает Oracle при использовании Oracle 10g?

Отдельный экземпляр (инстанс) Oracle 10g поддерживает использование смонтированного в NFS ORACLE_HOME на один хост.
Экземпляр (инстанс) Oracle RAC (Oracle 10g) поддерживает использование смонтированного в NFS ORACLE_HOME на 1 или более хостов.

Каковы преимущества совместно используемого ORACLE_HOME в Oracle 10g?

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

Каковы недостатки совместно используемого ORACLE_HOME в Oracle 10g?

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

Какие варианты совместного использования ORACLE_HOME поддерживает NetApp?

Мы ПОДДЕРЖИВАЕМ совместно используемый ORACLE_HOME для систем RAC.
Мы ПОДДЕРЖИВАЕМ совместно используемый ORACLE_HOME для одного экземпляра базы, когда он смонтирован на одну хост-систему.
Мы НЕ ПОДДЕРЖИВАЕМ совместно используемый ORACLE_HOME в продакшне, который требует высокой доступности для какого-либо из использующих его экземпляров базы. Другими словами, несколько баз не должны совместно использовать один NFS-раздел с ORACLE_HOME если хотя бы одна из баз работает в продакшне.

2.2.7. Наилучшие решения для Control и Log файлов

Online Redo Log Files

Распределите ваши лог-файлы по нескольким местам. Чтобы сделать это, следуйте рекомендациям:

Создайте как минимум две группы online redo log, каждую с тремя участниками (members). Поместите первую группу online redo log в один том, а следующую в другой том. Экземпляр процесса LGWR (Log Writer) сбрасывает REDO Log Buffer, который содержит как проведенные (committed), так и непроведенные (uncommitted) транзакции, для всех участников текущей группы online redo log, и когда группа заполнена, то переключает лог на следующую группу, при этом LGWR пишет во всех участников группы, до тех пор, пока они не заполнятся, и так далее. Чекпойнты не вызывают переключение логов, но на практике, много чекпойнтов возникают пока группа логов заполняется, также чекпойннт возникает при переключении логов.
Предлагаемый вариант:
Redo Grp 1: $ORACLE_HOME/Redo_Grp1 (на томе /vol/oralog)
Redo Grp 2: $ORACLE_HOME/Redo_Grp2 (на томе /vol/oralog)

Файлы архивных логов (Archived Log Files)

Установите ваш (init) параметр, ARCHIVE_LOG_DEST, на директорию в томе логов, такую, как $ORACLE_HOME/log/ArchiveLog (на томе /vol/oralog).

Control Files

Распределите ваши control files. Для этого:

Установите параметр CONTROL_FILE_DEST, чтобы он указывал, по меньшей мере на два разных тома:
Dest 1: $ORACLE_HOME/Control_File1 (на локальной файловой системе или на томе системы хранения /vol/oralog)
Dest 2: $ORACLE_HOME/log/Control_File2 (на томе системы хранения /vol/oradata)

2.3. RAID Group Size

Если время реконструкции (reconstruction rate) RAID-группы после сбоя это важный фактор, то должны использоваться RAID-группы из небольшого количества дисков. Далее даются рекомендации по наилучшему выбору размера RAID-группы при использовании как традиционного NetApp RAID тип 4 или RAID-DP™.

2.3.1 Традиционный RAID (RAID-4)

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

RAID-группа большего размера увеличивает влияние при дисковой реконструкции по следующим причинам:

Требуется большее количество чтений
Требуется большее количество ресурсов RAID
Удлиняется период, во время которого производительность ввода-вывода снижена (реконструкция RAID-группы большого размера занимает большее время, по этой причине, на время реконструкции большой RAID-группы, производительность ввода-вывода снижается на более длительный срок)

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

2.3.2 RAID-DP

С выходом версии Data ONTAP 6.5, появилась возможность использовать «RAID c двойной четностью» или RAID-DP. В RAID-DP, в каждую RAID-группу добавляется диск дополнительной четности. При использовании этой дополнительной защиты, вероятность потери данных в результате двойной ошибки дисков практически устраняется, поэтому появляется возможность использовать RAID-группы большего размера.

В Data ONTAP 6.5 и позднее, RAID-группа размером более 16 дисков может быть безопасно создана при использовании RAID-DP. Однако мы рекомендуем использовать размер RAID-группы по умолчанию, в 16 дисков, при использовании RAID-DP.

2.4. Snapshot and SnapRestore^®

NetApp настоятельно рекомендует использовать Snapshot и SnapRestore для резервного копирования баз Oracle. Snapshot предоставляет возможность моментальной копии всей базы данных, без ущерба для производительности системы хранения, а SnapRestore восстанавливает базу данных целиком, из любого предыдущего снэпшота.

Для того чтобы снэпшоты могли эффективно использоваться с базами данных Oracle, они должны быть скоординированы со средствами Oracle hot backup. По этой причине, NetApp рекомендует выключить автоматически создаваемые снэпшоты на томах, хранящих данные баз данных Oracle.

Для выключения автоматических снэпшотов для тома, используйте следующую команду:

vol options <volname> nosnap on

Если вы хотите сделать директорию .snapshot невидимой для клиентов, выполните следующую команду:

vol options <volname> nosnapdir on

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

Для дополнительных сведений о использовании Snapshot и SnapRestore для резервного копирования и восстановления Oracle Database, смотрите [3].

2.5. Резервирование места под снэпшоты (Snap Reserve)

Установка величины snap reserve на томе, выделяет часть пространства на томе под использование для хранения данных снэпшотов. Заметьте: снэпшоты могут использовать больше места на томе, чем задано в значении snap reserve, но пользователь не может использовать для своих данных место из зарезервированного под снэпшоты.

Чтобы посмотреть рамер резерва на томе, введите команду:

snap reserve

Для установки размера snap reserve для тома (значение по умолчанию 20%), введите команду:

snap reserve <volume> <percentage>

Не пишите знак процента (%) когда задаете величину в процентах.

Резервирование snap reserve должно быть настроено по размеру на величину, слегка превышающую максимальный объем снэпшотов для данного тома. Максимум объема снэпшотов можно установить наблюдая за системой в течении нескольких дней, при наличии в это время высокой рабочей нагрузки.

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

NetApp рекомендует регулярно наблюдать за размером использованного снэпшотами пространства в snap reserve. Не позволяйте им превышать выделенного в резерве места. Если snap reserve исчерпан, то увеличьте процент места, выделенного под snap reserve или удаляйте какие-то из снэпшотов, пока количество использованного на томе места не опустится ниже 100%. Программа NetApp DataFabric^® Manager (DFM) может помочь в мониторинге.

2.6. Настройки системы хранения

2.6.1. Опция minra

Когда включена опция minra (minimize read-ahead), то в процессе чтения минимизируется количество блоков, которые считываются в кэш с упреждением (read-ahead). По умолчанию, minra выключена, и система хранения производит активное упреждающее чтение в кэш для каждого тома. Эффект от упреждающего чтения зависит от характера ввода-вывода приложения. Если данные считываются последовательно, например, когда база данных проводит полный просмотр таблиц и индексов (full scan), упреждающее чтение увеличит производительность ввода-вывода. Если доступ к данным происходит с полностью случайным характером, то упреждающее чтение должно быть выключено, так как оно снижает производительность за счет лишнего чтения дисковых блоков, и непроизводительно загружает системные ресурсы.

Следующая команда используется для включения опции minra для тома, и вылючения упреждающего чтения:

vol options <volname> minra on

В общем случае упреждающее чтение выгодно для баз данных, и включать minra не следует. Однако NetApp рекомендует поэкспериментировать с опцией minra, и пронаблюдать за влиянием на производительность, так как заранее невозможно строго определить то, какое приложение использует более случайный, нежели последовательный доступ к данным. Эта опция прозрачна в плане доступа клиентов к данным, и может переключаться без прерывания процесса ввода-вывода данных. Убедитесь, что вы выждали две или три минуты, прежде чем оценивать изменения значения производительности.

2.6.2. Обновление значения File Access Time

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

vol options <volname> no_atime_update on

2.6.3. Настройки NFS

Для файлов баз данных и mountpoints, NetApp поддерживает использование TCP в качестве механизма передачи данных в текущем клиенте NFS V3.0. Не поддерживается UDP для файлов баз данных и mountpoints.

3. Операционные системы

Для полного, актуального списка платформ, сертифицированных для Oracle, смотрите:
http://www.netapp.com/partners/oracle/tech.html

3.1. Linux

Для дополнительной информации об использовании Linux и технологий NetApp, см. [4].

3.1.1. Linux — рекомендованные версии

Различные дистрибутивы OS Linux основаны на том или ином ядре (kernel). Для любого дистрибутива важно сосредоточить внимание на его ядре, чтобы понять возможные особенности применения и совместимости.

Kernel 2.4

Клиент NFS в этом ядре имеет множество улучшений, по сравнению с клиентом для ядра 2.2, большинство из которых относится к производительности и стабильности. Клиент NFS ядра после 2.4.16 имеет значительные улучшения производительности и стабильности.

Некоторые спорные изменения были внесены в ветку 2.4, что было препятствием для разработчиков дистрибутивов использовать поздние версии ядер этой ветки. Хотя некоторые заметные улучшения NFS были сделаны в версии 2.4.15, Торвальдс изменил часть подсистемы VM, сделав версии ядра 2.4.15, 2.4.16, и 2.4.17 нестабильными на большой нагрузке.

При использовании ядер 2.4 на оборудовании с более чем 896MB памяти, в них нужно включать при компиляции опцию CONFIG_HIGHMEM, которая необходима для доступа к памяти выше 896MB. Клиент NFS в Linux ядра 2.4 имеет известную проблему в этой конфигурации, выражающуюся в случайном подвисании приложения, или всей клиентской системы в целом. Эта проблема была устранена в ядре 2.4.20, но по прежнему может проявляться в дистрибутивах Red Hat и SUSE, использующих более ранние ядра.

Рекомендации по выбору ядра Linux

В NetApp протестирован множество вариантов дистрибутивов, и основанные на ядрах ветви 2.6 в настоящий момент рекомендуются к применению.

Рекомендованные дистрибутивы включают в себя Red Hat Enterprise Linux Advanced Server 3.0 и 4.0, а также SUSE Enterprise Linux 9.0 (SLES9).

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

Manufacturer	Version	Tested	Recommended
Red Hat	Advanced Server 2.1	Yes	No
Red Hat	Advanced Server 3.0	Yes	Yes
Red Hat	Advanced Server 4.0	Yes	Yes
SUSE	7.2	Yes	No
SUSE	SLES 8	Yes	No
SUSE	SLES 9	Yes	Yes

3.1.2. Linux — патчи ядра

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

Патч для использования режима uncached I/O (некэшированного ввода-вывода) впервые появился в Red Hat Advanced Server 2.1, update 3, с kernel errata e35 и выше. Необходимо в обязательно применять uncached I/O при использовании Oracle9i™ RAC с системами хранения NetApp в NAS-режиме. Uncached I/O не кэширует данные в буферах файловой системы Linux, во время проведения операций ввода-вывода для тома, смонтированного с опциями монтирования noac. Для включения uncached I/O, добавьте следующие записи в файл /etc/modules.conf, и перезагрузите узлы кластера:

options nfs nfs_uncached_io=1

Тома, используемые для хранения файлов баз данных, по-прежнему требуют использования опции монтирования noac для баз Oracle9i RAC.

Патч uncached I/O был разработан Red Hat и протестирован Oracle, NetApp, и Red Hat.

3.1.3. Linux — настройки OS

3.1.3.1. Увеличение буферов Transport Socket Buffers на клиенте NFS

Увеличение буферов транспортных сокетов (transport socket buffers), которые Linux использует для трафика NFS, помогает снизить использование ресурсов на клиенте, снизить колебания в производительности, и увеличить максимальные показатели пропускной способности для данных и операций. В будущих релизах клиентов, следующие процедуры не будут необходимы, так как клиент сможет выбрать самостоятельно оптимальные размеры буферов сокета.

Будучи пользователем root на клиенте, выполните следующие команды:

cd into /proc/sys/net/core

echo 1048576 > rmem_max

echo 262143 > wmem_max

echo 1048576 > rmem_default

echo 262143 > wmem_default

Перемонтируйте файловую систему NFS на клиенте.

Дистрибутив Red Hat после 7.2 содержит файл с именем /etc/sysctl.conf куда могут быть добавлены эти изменения, так, что их не нужно будет вводить после каждой перезагрузки. Добавьте следующие строки в файл /etc/sysctl.conf на системе под Red Hat:

net.core.rmem_max = 1048576

net.core.wmem_max = 262143

net.core.rmem_default = 1048576

net.core.wmem_default = 262143

3.1.3.2. Прочие улучшения TCP

Следующие настройки могут помочь снизить объемы работы клиентов и системы хранения, когда вы используете NFS по TCP:

echo 0 > /proc/sys/net/ipv4/tcp_sack

echo 0 > /proc/sys/net/ipv4/tcp_timestamps

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

Когда вы компилируете ядро, то убедитесь, что опция CONFIG_SYNCOOKIES отключена. SYN cookies замедляют соединение TCP, добавляя небольшое количество операций на обоих концах сокета. Некоторые дистрибутивы Linux поставляют ядро с включенными SYN cookies.

Ядра Linux 2.2 и 2.4 поддерживают большие окна TCP (large TCP windows RFC 1323) по умолчанию. Изменения по включению поддержки больших окон не требуются.

3.1.4. Сеть в Linux — Full Duplex и Autonegotiation

Большинство сетевых карт используют автоопределение, для оптимальной настройки, доступной карте и порту коммутатора, к которой она подключена. Иногда встречающиеся несовместимости приводят к постоянным процессам переопределения настроек (renegotiation), ошибочному включению half duplex или низкой скорости. Когда вы ищете причины сетевых проблем, убедитесь, что настройки Ethernet соответствуют ожидаемым, прежде чем искать глубже. Избегайте использовать принудительные установки, вместо решения проблемы автоопределения, так как они могу только маскировать более глубинную проблему. Производители карт и коммутаторов должны помочь вам в решении таких проблем.

3.1.5. Сеть в Linux — адаптеры Gigabit Ethernet

Если сервера Linux используют высокопроизводительную сеть (gigabit или быстрее), обеспечьте достаточно ресурсов CPU и полосы пропускания память, чтобы обработать прерывания и поток данных. ПО клиента NFS и драйвер гигабитного адаптера уменьшает количество доступных приложению ресурсов, так что позаботьтесь, чтобы запас был адекватен. Большинство карт Gigabit Ethernet поддерживают 64-bit PCI или новее, и должны показывать хорошую производительность.

Все базы данных, использующие систему хранения NetApp, должны использовать Gigabit Ethernet на обоих концах соединения, как на системе хранения, так и на сервере, для достижения оптимальной производительности.

NetApp считает, что следующие сетевые карты Gigabit Ethernet хорошо работают под Linux:

SysKonnect. Карты серии SysKonnect SK-98XX работают очень хорошо с Linux и поддерживают как single- так и dual-fiber, а также «медный» интерфейс для лучшей производительности и доступности. Стабильный и отлаженный драйвер для этих карт входит в ядро 2.4 и позднее.
Broadcom. Многие карты и коммутаторы используют этот чипсет, включая вездесущий 3Com. Это предоставляет высокий уровень совместимости между сетевыми коммутаторами и клиентами Linux. Драйвер для этого чипсета появился в ядре 2.4.19 и включался в дистрибутивы Red Hat с ранними ядрами 2.4. Убедитесь, что firmware чипсета обновлено.
AceNIC Tigon II. Некоторые карты, такие как Netgear GA620T, используют этот чипсет, но больше они не производятся. Стабильный и активно поддерживаемый драйвер для этого чипсета включен в дистрибутив ядра.
Intel^® EEPro/1000. Это, возможно, быстрейший гигабитный сетевой адаптер, но драйвер включен только в наиболее свежие дистрибутивы ядра (2.4.20 и позднее) и может быть иногда нестабильным. Сообщают, что jumbo frame MTU для карт Intel равен только 8998 байт, а не стандартные 9000 байт.

3.1.6. Сеть в Linux — Jumbo Frames в GbE

Все карты, описанные выше, поддерживают опцию jumbo frames для Gigabit Ethernet. Использование jumbo frames может повысить производительность системы, использующей Linux NFS clients и системы хранения NetApp в немаршрутизируемой сети. Удостоверьтесь, что проверили в документации на каждый используемый коммутатор его возможности по работе с jumbo frames. Существует несколько известных проблем в драйверах Linux при использовании максимального размера фрейма (9000 байт). Если вы столкнулись с неожиданными замедлениями при использовании jumbo frames, то попробуйте уменьшить размер MTU до 8960 байт.

3.1.7. Протокол NFS в Linux — опции монтирования

Для базовых знаний о NFS и краткому описанию того, что делают разные опции монтирования в клиенте NFS, прочтите документ NetApp TR: Using the Linux NFS Client with NetApp [4]

Таблица по следующей ссылке суммирует в наиболее свежем виде список рекомендованных опций монтирования для клиентов NFS, для различных версий Oracle и платформ OS.

http://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb7518 (требуется логин на NOW)

3.1.8. iSCSI Initiators для Linux

Поддержка iSCSI для Linux недавно стала доступной во множестве различных форм. Начали появляться аппаратные и программные инициаторы, но они пока не достигли уровня, пригодного для безоговорочного принятия. Объем тестирования пока недостаточен, чтобы рекомендовать какие-то безусловно наилучшие решения в этой области. Этот раздел будет переработан в будущем, для включения в него рекомендаций и практических решений по запуску баз данных Oracle на Linux с iSCSI initiators.

3.1.9. FCP SAN Initiators для Linux

NetApp поддерживает протокол доступа Fibre Channel для баз данных Oracle, работающих на Linux. Подключение к системе хранения NetApp может быть сделано через коммутатор Fibre Channel (SAN) или напрямую (direct-attached). NetApp в настоящий момент поддерживает Red Hat Enterprise Linux 2.1 и 3.0 а также SUSE Enterprise Server 8, работающие с системой хранения NetApp с OS Data ONTAP 6.4.1 и выше.

Для подробностей о требованиях к системе и инсталляции, смотрите [4].

NetApp рекомендует использовать Fibre Channel SAN для Oracle Databases на Linux, там, где имеются существующие капиталовложения в инфраструктуру Fibre Channel, или когда постоянная загрузка канала передачи данных превышает 1Gbit в секунду (~110 мегабайт в секунду).

3.2. Sun™ Solaris Operating Systems

3.2.1. Solaris — рекомендованные версии

Manufacturer	Version	Tested	Recommended
(Sun) Solaris	2.6	устарела	No
	7	Yes	No
	8	Yes	No
	9	Yes	Yes
	10	Yes	Yes

NetApp рекомендует использовать Solaris 9 Update 5 и выше, для оптимальной производительности сервера.

3.2.2. Solaris — патчи ядра

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

NetApp рекомендует устанавливать наиболее свежие ревизии каждого патча Sun.

Эти рекомендации дополняют, но не заменяют рекомендации о патчах Solaris, включенные в инсталляцию Oracle или release notes.

Список желательных патчей Solaris 8 на 16 марта 2006:

Solaris 8

117000-05 SunOS 5.8: kernel patch (obsoletes 108813-17)

108806-20 SunOS 5.8: Sun Quad FastEthernet qfe driver

108528-29 SunOS 5.8: kernel update patch

116959-13 SunOS 5.8: nfs and rpcmod patch

(116959-05 относится к багу Solaris NFS client caching [wcc] bug 4407669: ОЧЕНЬ важный патч для производительности)

111883-34 SunOS 5.8: Sun GigaSwift Ethernet 1.0 driver patch

Список желательных патчей Solaris 9 на 16 марта 2006:

Solaris 9

112817-27 SunOS 5.9: Sun GigaSwift Ethernet 1.0 driver patch

113318-21 SunOS 5.9: nfs patch

(addresses Solaris NFS client caching [wcc[ bug 4407669: также относится к багу Solaris

4960336 fdio: ОЧЕНЬ важный патч для производительности)

113459-03 SunOS 5.9: udp patch

112233-12 SunOS 5.9: kernel patch

112854-02 SunOS 5.9: icmp patch

117171-17 SunOS 5.9: patch /kernel/sys/kaio

112764-08 SunOS 5.9: Sun Quad FastEthernet qfe driver

Список желательных патчей Solaris 10 на 16 марта 2006:

Solaris 10

120030-01 SunOS 5.10: mountd patch

118375-06 SunOS 5.10: nfs patch

118822-30 SunOS 5.10: kernel patch

Неустановка перечисленных выше патчей может вызывать отказы в работе базы данных, «падения» и замедление работы. Они должны обязательно быть установлены. Пожалуйста, отметьте, что «Sun EAGAIN bug» — SUN Alert 41862, на который ссылается патч 108727—может вызывать аварийное завершение Oracle Database с сообщением ошибки:

SVR4 Error 11: Resource temporarily unavailable

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

3.2.3. Solaris — настройки OS

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

Дескрипторы файлов в Solaris:

rlim_fd_cur. "Soft"-лимит числа файловых дескрипторов (и сокетов), которые может открыть один процесс.

rlim_fd_max. "Hard"-лимит числа файловых дескрипторов (и сокетов), которые может открыть один процесс.

Установка этих величин в 1024 НАСТОЯТЕЛЬНО рекомендуется, для того, чтобы избежать «падений» базы данных в результате нехватки ресурсов в Solaris.

Установки "maxusers" в Solaris kernel:

Параметр ядра Solaris maxusers управляет распределением некоторых важных ресурсов ядра, таких, как максимальный размер таблицы процессов (process table) и максимального числа процессов на пользователя (processes per user).

3.2.4. Сеть в Solaris — Full Duplex и Autonegotiation

Следующие настройки верны для случая непосредственного включения сервера Sun в систему хранения NetApp, без использования коммутатора.

Карты GbE под Solaris должны иметь выключенную установку autonegotiation, а параметр transmit flow control - включенным. Это так для карт Sun «ge», и скорее всего верно и для более новых карт Sun «ce».

NetApp рекомендует отключить autonegotiation, принудительно задать тип flow control, и принудительно задать режим full duplex.

3.2.5. Сеть в Solaris — адаптеры Gigabit Ethernet

Sun предлагает карты Gigabit Ethernet как для PCI, так и для SBUS. Карты на PCI имеют более высокую производительность чем версии на SBUS.

NetApp рекомендует использовать карты на PCI, когда это возможно.

SysKonnect это независимый производитель NIC, поставляющий карты Gigabit Ethernet. Версия карт на PCI обеспечивает наивысшую производительность.

Необходимо убедиться в том, что сервера Sun с картами Gigabit Ethernet работают в режиме full flow control (некоторые требуют независимой установки режимов для «send» и «receive»).

На сервере Sun установка flow control может быть произведена добавлением следующих строк в инициализационный скрипт (такой как, например, /etc/rc2.d/S99*) или изменением этих значений, если они уже существуют:

ndd –set /dev/ge instance 0

ndd –set /dev/ge ge_adv_pauseRX 1

ndd –set /dev/ge ge_adv_pauseTX 1

ndd –set /dev/ge ge_intr_mode 1

ndd –set /dev/ge ge_put_cfg 0

Внимание: instance может отличаться от 0, если на системе более одного интерфейса Gigabit Ethernet.

Продублируйте установки для каждого instance, который подключен к NetApp.

Для серверов, использующих /etc/system, добавьте следующие строки:

set ge:ge_adv_pauseRX=1

set ge:ge_adv_pauseTX=1

set ge:ge_intr_mode=1

set ge_ge_put_cfg=0

Отметьте, что помещение этих настроек в /etc/system влияет на все Gigabit-интерфейсы сервера. Коммутаторы, и другие подключаемые устройства, также должны быть соответствующим образом сконфигурированы.

3.2.6. Сеть в Solaris — Jumbo Frames в GbE

SysKonnect поставляет карты типа SK-98xx, поддерживающие jumbo frames. Для включения jumbo frames, выполните следующие шаги:

1. Отредактируйте /kernel/drv/skge.conf и раскомментируйте строку:
JumboFrames_Inst0=”On”;

2. Отредактируйте /etc/rcS.d/S50skge и добавьте строку:
ifconfig skge0 mtu 9000

3. Перезагрузите систему.

Если вы используете jumbo frames с картами SysKonnect NIC, используйте коммутаторы, которые поддерживают jumbo frames и включите поддержку jumbo frames на сетевом интерфейсе системы хранения NetApp.

3.2.7. Сеть в Solaris — Увеличение производительности сети

Настройка приведенных ниже параметров может дать выигрыш в производительности сети. Большинство из этих настроек отображается с помощью команды Solaris ndd, и устанавливается при использовании ndd или редактировании файла /etc/system.

/dev/udp udp_recv_hiwat. Определяет максимальную величину приемного буфера UDP. Это количество места в буферах, выделенное под принимаемые данные UDP. Значение по умолчанию 8192 (8kB). Должно быть установлено в 65535 (64kB).

/dev/udp udp_xmit_hiwat. Определяет максимальную величину буфера передачи UDP. Это количество места в буферах, выделенное под передаваемые данные UDP. Значение по умолчанию 8192 (8kB). Должно быть установлено в 65535 (64kB).

/dev/tcp tcp_recv_hiwat. Определяет максимальную величину приемного буфера TCP. Это количество места в буферах, выделенное под принимаемые данные TCP. Значение по умолчанию 8192 (8kB). Должно быть установлено в 65535 (64kB).

/dev/tcp tcp_xmit_hiwat. Определяет максимальную величину буфера передачи TCP. Это количество места в буферах, выделенное под передаваемые данные TCP. Значение по умолчанию 8192 (8kB). Должно быть установлено в 65535 (64kB).

/dev/ge adv_pauseTX 1. Задает принудительный контроль потока (flow control) на передачу для адаптера Gigabit Ethernet. Transmit flow control provides a means for the transmitter to govern the amount of data sent; Значение «0» это величина по умолчанию для Solaris, до тех пор, пока он не будет включен, в результате процесса автоопределения (autonegotiation) между NIC-ами. NetApp настоятельно рекомендует чтобы контроль потока на передачу был включен. Установка этой величины в «1» поможет избежать потерь пакетов или повторной и передачи, так как эта величина заставляет NIC включить контроль потока передачи. Если NIC переполняется данными, она сигналит передающему установить паузу. Иногда бывает нужно установить это параметр в «0», чтобы определить ситуацию, когда посылающий (NetApp system) переполняет потоком клиента. Рекомендованные настройки описаны в разделе 2.2.6 этого документа.

/dev/ge adv_pauseRX 1. Принудительно устанавливает контроль потока (flow control) приема для адаптера Gigabit Ethernet. Receive flow control provides a means for the receiver to govern the amount of data received. Установка «1» это значение по умолчанию для Solaris.

/dev/ge adv_1000fdx_cap 1. Задает принудительный full duplex для адаптера Gigabit Ethernet. Full duplex позволяет данным передаваться и приниматься одновременно. Это нужно установить одинаков как на стороне сервера Solaris, так и на системе хранения NetApp. Ошибки в определении режима duplex приводят к сетевым ошибкам и ошибкам базы данных.

sq_max_size. Устанавливает максимальное количество сообщений (messages), допустимых для каждой очереди IP (IP queue) (STREAMS synchronized queue). Увеличение этого параметра улучшает сетевую производительность. Безопасная величина для этого параметра 25 для каждых 64MB физической памяти на системе Solaris, вплоть до максимального значения в 100. Параметр следует оптимизировать начав с 25 и увеличивая на 10, пока сетевая производительность не достигнет пика.

Nstrpush. Определяет максимальное количество модулей, которые могут быть отправлены в поток, и должен быть установлен в 9.

Ncsize. Определяет размер DNLC (directory name lookup cache). DNLC хранит информацию о файлах на томе NFS. Непопадание в кэш может вызвать дисковую операцию ввода-вывода чтения директории.

Чтение этой информации из кэша может значительно улучшить производительность NFS; getattr, setattr, и lookup обычно составляют более 50% всех вызовов NFS. Если запрошенная информация не нашлась в кэше, то запускается дисковая операция, что в результате негативно сказывается на общей производительности. Единственное ограничение размера кэша DNLC это доступная ядру память. Каждый элемент DNLC занимает примерно 50 bytes дополнительной памяти ядра.

NetApp усановить величину ncsize на 8000.

nfs:nfs3_max_threads. Максимальное число потоков (threads), которые может использовать клиент NFS V3. Рекомендумая величина 24.

nfs:nfs3_nra. Размер упреждающего чтения (read-ahead count) для клиента NFS V3. Рекомендуемая величина 10.

nfs:nfs_max_threads. Максимальное число потоков (threads), которые может использовать клиент NFS V2. Рекомендумая величина 24.

nfs:nfs_nra. Размер упреждающего чтения (read-ahead count) для клиента NFS V2. Рекомендуемая величина 10.

3.2.8. Solaris IP Multipathing (IPMP)

Solaris имеет средства, обеспечивающие использование нескольких соединений IP в конфигурации, похожей на NetApp virtual interface (VIF). В некоторых случаях использование этой возможности может быть выгодным.

IPMP может быть сконфигурировано или в отказоустойчивой (failover configuration) или в совместно работающей (load-sharing) конфигурации.

Отказоустойчивая (failover) конфигурация достаточно очевидно устроена и несложно устанавливается. Два интерфейса используют один IP-адрес, один из интерфейсов находится в «standby» (в документации на Solaris это называется «deprecated»), а другой интерфейс - активный. Если соединение обрывается, то Solaris прозрачно перенаправляет трафик на второй интерфейс. Когда это проделано ядром Solaris, то приложение просто использует интерфейс, и не заботится о том, как производится переключение.

NetApp протестировал конфигурацию failover для Solaris IPMP и рекомендует ее использование в тех случаях, когда нужна отказоустойчивость, есть достаточное количество интерфейсов, а стандартный транкинг (например Cisco Etherchannel) не доступен.

Конфигурация load-sharing использует трюк, при котором исходящий трафик на отдельные IP-адреса разделяется по интерфейсам, но весь исходящий трафик содержит обратный адрес одного, «primary» интерфейса. При больших объемах записи на систему хранения эта конфигурация может дать определенную выгоду в производительности. Но, так как весь обратный трафик проходит только через один интерфейс, то, в случае большого объема чтения, преимуществ в ускорении нет.

Кроме этого, механизм, который Solaris использует для обнаружения ошибок и переключения failover на работающую NIC несовместим с кластером NetApp.

NetApp не рекомендует использовать IPMP в режиме load-sharing, по причине текущей несовместимости с кластерной конфигурацией NetApp, ограниченной возможностью улучшения производительности на чтении, сложностью и вызванными этим дополнительными рисками.

3.2.9. Протокол NFS в Solaris — опции монтирования

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

Опции монтирования могут быть установлены вручную, когда файловая система монтируется в Solaris, или, обычнее, определяются в /etc/vfstab для тех монтирований, которые осуществляются в момент загрузки. Последний способ настоятельно рекомендуется, так как вы можете быть уверены, что система запустится после перезагрузки по любой причине, и войдет в рабочее состояние без необходимости ручного вмешательства оператора. Чтобы настроить опции монтирования:

1. Отредактируйте /etc/vfstab.

2. Для каждого NFS mount, участвующего в высокоскоростной инфраструктуре, убедитесь, что опции монтирования задают TCP V3 с размером передачи 32kB: …hard,bg,intr,vers=3,proto=tcp, rsize=32768, wsize=32768,…

Внимание: Эти величины являются значением по умолчанию в NFS для Solaris 8 и 9. Определение их не является безусловно необходимым, но рекомендуется для определенности.

Hard. Опция «soft» не должна никогда использоваться для баз данных. Это может вызвать неполную запись данных, и проблемы с файлами базы данных. Опция «hard» определяет, что запросы ввода-вывода будут посланы повторно, в случае, если они были неудачны при первой попытке. Это принуждает приложение производить операцию ввода-вывода через NFS, пока затребованный файл не окажется доступным. Это особенно важно в случае использования отказоустойчивых и избыточных сетей и серверов (например, в случае кластера NetApp).

Bg. Определяет, что операция монтирования должна выполняться в фоновом режиме, если система хранения NetApp недоступна, что позволяет загрузке Solaris продолжаться в этом случае. Так как процесс загрузки системы может быть выполнен даже при недоступности всех необходимых файловых систем, позаботьтесь о том, чтобы нужные файловые системы были смонтированы и присутствовали до начала запуска Oracle Database.

Intr. Эта опция позволяет операциям ожидать прерывания NFS. Если эта опция не используется, и соединение NFS смонтированное с опцией «hard» оборвано и не восстановлено, то единственный способ восстановить работу для Solaris в таком случае это перезагрузка сервера.

rsize/wsize. Определяет размер запроса NFS для чтения/записи. Величины этих параметров должны соответствовать значению nfs.tcp.xfersize на системе хранения NetApp. Величина 32768 (32kB) рекомендуется для максимальной производительности базы данных при использовании NetApp и Solaris. По меньшей мере размер NFS read/write size должен быть равен или больше, чем размер блока (block size) Oracle. Например, определив DB_FILE_MULTIBLOCK_READ_COUNT в 4 умножаем на размер database block size равный 8kB, получаем размер read buffer size (rsize) равный 32kB.

NetApp рекомендует установить DB_FILE_MULTIBLOCK_READ_COUNT в значение от 1 до 4 для баз типа OLTP, и от 16 до 32 для DSS.

Vers. Устанавливает используемую версию NFS. Version 3 обеспечивает оптимальную производительность баз данных под Solaris.

Proto. Говорит Solaris использовать TCP или UDP для соединения. В настоящий момент только TCP поддерживается для файлов Oracle по NFS. Ранее, UDP давал лучшую производительность, но был ограничен в применении только очень надежными соединениями. TCP имеет больший overhead, но обрабатывает ошибки и лучше управляет потоком. В действующих версиях Solaris (8, 9 и 10) разница в производительности незначительна.

Forcedirectio. Новая опция, появившаяся в Solaris 8. Она позволяет приложению обходить кэш ядра Solaris, что оптимально для Oracle. Эта опция должна использоваться для томов, содерержащих файлы данных. На не должна использоваться для томов, содержащих исполняемые файлы. Использование этой опции с томом, содержащим исполняемые файлы Oracle будет препятствовать запуску всех исполняемых файлов, хранящихся на томе. Если программа, которая обычно нормально запускается, не хочет стартовать, или немедленно падает в «core dump», проверьте, не находится ли она на томе, смонтированном с опцией «forcedirectio».

NetApp recommended mount options for Oracle single-instance database on Solaris:

rw,bg,vers=3,proto=tcp,hard,intr,rsize=32768,wsize=32768,forcedirectio

NetApp recommended mount options for Oracle9i RAC on Solaris:

rw,bg,vers=3,proto=tcp,hard,intr,rsize=32768,wsize=32768,forcedirectio,noac

Появление forced direct I/O в Solaris 8 было огромным шагом вперед. Direct I/O обходит кэш файловой системы Solaris. Когда блок данных считывается с диска, он читается непосредственно в буфера кэша Oracle, а не в кэш файловой системы. Без direct I/O, блок данных сперва заносится в кэш чтения файловой системы, откуда затем переносится в кэш-буфера Oracle, двойное буферирование непродуктивно тратит память и ресурсы CPU. Oracle не использует кэш файловой системы OS.

Используя средства мониторинга и статистики, NetApp обнаружил, что без включенного direct I/O на смонтированном томе NFS, большое количество страниц файловой системы попадают в своп. Это добавляет системе оверхеда на переключение контекстов (context switches), и использование CPU увеличивается. Со включенным direct I/O, эти параметры заметно снижаются. В зависимости от нагрузки, заметно значительное увеличение обшей производительности. В некоторых случаях она превышала 20%.

Direct I/O for NFS это новинка Solaris 8, однако он был представлен в UFS еще в Solaris 6. Direct I/O должен использоваться для томов, которые хранят файлы Oracle Database, но не для прочих файлов или программ Oracle, или когда выполняются обычные файловые операции ввода-вывода, такие как «dd». Обычные файловые операции используют преимущества от кэширования на уровне файловой системы.

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

NetApp рекомендует использовать «forcedirectio» на отдельных томах, на которых характер паттерна ввода-вывода не требует кэширования на клиенте NFS. In general these will be data files with access patterns that are mostly random as well as any online redo log files and archive log files. Опция «forcedirectio» не должна использоваться для томов, содержащих исполняемые файлы, такие, как директория ORACLE_HOME. Использование опции «forcedirectio» на томах, содержащих исполняемые файлы, вызовет их неверную работу.

Множественные точки монтирования (Multiple Mountpoints)

Чтобы достичь максимальной производительности транзакционная база типа OLTP может использовать возможности множественного монтирования базы данных и распределения нагрузки по этим точкам монтирования. Улучшение производительности в среднем оказывается в районе от 2% до 9%.

Чтобы это настроить, создайте дополнительную точку монтирования на ту же файловую систему на системе хранения NetApp. После чего переименуйте датафайлы базы данных (при помощи команды ALTER DATABASE RENAME FILE) или создайте символьный линк со старой точки монтирования на новую.

3.2.10. iSCSI Initiators для Solaris

В настоящий момент, NetApp не поддерживает iSCSI initiators на Solaris. Этот раздел будет обновлен в будущем, когда станут доступны iSCSI initiators на Solaris.

3.2.11. Fibre Channel SAN для Solaris

NetApp поставляет первую в отрасли систему унифицированного доступа, позволяющую обслуживать данные как NAS или SAN. NetApp предлагает решения Fibre Channel SAN для всех платформ, включая Solaris, Windows, Linux, HP/UX, и AIX. Решение NetApp Fibre Channel SAN предлагает тот же фреймворк управления, и богатую функциональность, что отличает наши NAS системы.

Пользователь может выбрать NAS или FC SAN для использования в Solaris, в зависимости от нагрузки и имеющегося оборудования. Для конфигурации FC SAN, настоятельно рекомендуется использовать SAN host attach kit 1.2 for Solaris. Комплект поставляется с Fibre Channel HBA, драйверами, firmware, утилитами и документацией. Для инсталляции и конфигурации консультируйтесь с документацией, поставляемой с комплектом.

NetApp проверил и одобрил решение FC SAN с Solaris под Oracle. Консультируйтесь с руководством Oracle integration guide и NetApp FC SAN in a Solaris environment ([6]) для подробностей. Для выполнения резервного копирования и восстановления Oracle Database в SAN, см [7].

NetApp рекомендует использовать Fibre Channel SAN для Oracle Databases на Solaris там, где уже присутствует развитая инфраструктура Fibre Channel. NetApp также рекомендует обратить внимание на решение с использованием Fibre Channel SAN для Solaris там, где величины постоянного трафика ввода-вывода для сервера Oracle превышают 1Gb в секунду (~110MB в секунду).

3.3. Microsoft^® Windows Operating Systems

3.3.1. OS Windows — Рекомендованные версии

Microsoft Windows NT^® 4.0, Windows 2000 Server и Advanced Server, Windows 2003 Server

3.3.2. OS Windows — Сервиспаки

Microsoft Windows NT 4.0: Service Pack 5

Microsoft Windows 2000: SP2 или SP3

Microsoft Windows 2000 AS: SP2 или SP3

Microsoft Windows 2003: Standard или Enterprise

3.3.3. OS Windows — Настройки реестра

Следующие настройки в реестре улучшат производительность и надежность Windows. Эти установки потребуют перезагрузки сервера:

Опция /3GB не должна быть установлена в C:\boot.ini.

\\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\MaxMpxCt

Datatype: DWORD

Value: установить соответствующую значению cifs.max_mpx

\\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindow

Datatype: DWORD

Value: 64240 (0xFAF0)

Таблица описывает некоторые из этих ключей и некоторые принципы их тонкой настройки:

Ключ

Описание

MaxMpxCt

Максимальное количество одновременных запросов, которые создает клиент Windows к системе хранения NetApp. Должен соответствовать cifs.max_mpx.

Проследите по performance monitor величину параметра redirector/current. Если она постоянно находится в районе заданной величины MaxMpxCt, то увеличьте его значение.

TcpWindow

Максимальный размер окна передачи данных по TCP-сети. Значение должно быть установлено в 64240 (0xFAF0).

3.3.4. Сеть в Windows — Autonegotiation и Full Duplex

Перейдите в Control Panel -> Network -> Services tab -> Server и щелкните кнопку Properties. Установите опцию «maximize network applications» для максимальной сетевой производительности.

3.3.5. Сеть в Windows — Gigabit Ethernet Network Adapters

Все базы данных, использующие системы хранения NetApp должны использовать Gigabit Ethernet на обоих концах, как на стороне системы хранения, так и на стороне сервера баз данных, для достижения максимально возможной производительности.

NetApp тестировал Intel PRO/1000 F Server Adapter. Следующие настройки могут быть установлены для этого адаптера. Каждая настройка должна быть протестирована и настроена для достижения максимальной производительности.

Параметр	Описание
Coalesce buffers = 32	Число буферов, используемых для ускорения передачи.
Flow control = receive pause frame	Используемый метод контроля потока (flow control). Должен соответствовать установленному для адаптера Gigabit Ethernet в системе хранения NetApp.
Jumbo frames = disable	Разрешает передачу больших пакетов Ethernet. NetApp поддерживает их с версии Data ONTAP 6.1 и позднее.
Receive descriptors = 32	Число буферов передачи и дескрипторов, которые создает драйвер для приема пакетов.
Transmit descriptors = 32	Число буферов передачи и дескрипторов, которые создает драйвер для посылки пакетов.

3.3.6. Сеть в Windows — Jumbo Frames и GbE

Внимание: Будьте очень осторожны, когда используете jumbo frames с Microsoft Windows 2000. Если включены jumbo frames на системе хранения, и Oracle работает на сервере Windows, а аутентификация осуществляется в домене Windows 2000 domain, то процесс аутентификации может пойти через интерфейс со включенными jumbo frames к контроллеру домена, который, как обычно бывает, не сконфигурирован на использование jumbo frames. Это приведет к тому, что возникнут большие задержки или ошибки процесса аутентификации при использовании CIFS.

3.3.7. iSCSI Initiators для Windows

NetApp рекомендует использовать Microsoft iSCSI initiator или NetApp iSCSI host attach kit 2.0 for Windows по выделенной высокоскоростной сети Gigabit Ethernet на таких платформах, как Windows 2000, Windows 2000 AS, и Windows 2003 с Oracle Databases. Для платформ, например Windows NT, которые не имеют iSCSI, NetApp поддерживает CIFS для использования с Oracle Database и хранилища приложений. Однако рекомендуется обновиться до Windows 2000 или новее, и использовать iSCSI initiator (программный или аппаратный). NetApp в настоящий момент поддерживает Microsoft iSCSI initiator 1.02 и 1.03, доступный на www.microsoft.com.

3.3.8. FCP SAN Initiators для Windows

NetApp поддерживает использование Fibre Channel SAN в Windows для Oracle Databases. NetApp рекомендует использовать Fibre Channel SAN для Oracle Databases под Windows там, где уже присутствует развитая инфраструктура Fibre Channel. NetApp также рекомендует обратить внимание на решение с использованием Fibre Channel SAN для Windows там, где величины постоянного траффика ввода-вывода для сервера Oracle превышают 1GB в секунду (~110MB в секунду).

4. Настройки Oracle

Этот раздел описывает настройки, которые делаются в Oracle Database, обычно через установки в файле init.ora. Подразумевается, что у читателя есть соответствующие знания того, как правильно устанавливать эти опции, и о том, какой эффект они вызывают. Установки, описанные здесь, одни из наиболее часто используемых при настройке систем хранения NetApp с Oracle Databases.

4.1. DISK_ASYNCH_IO

Разрешение или запрещение режима асинхронного ввода-вывода (asynchronous I/O) в Oracle. Режим асинхронного ввода-вывода позволяет процессам выполнять следующую операцию, не ожидая завершения выполнения операции записи, что улучшает производительность системы и уменьшает время ожидания (idle time). Эта установка может улучшить производительность, в зависимости от характера базы данных. Если параметр DISK_ASYNCH_IO установлен в TRUE, тогда DB_WRITER_PROCESSES и DB_BLOCK_LRU_LATCHES (версии Oracle до 9i) или DBWR_IO_SLAVES должны использоваться так, как написано ниже. Правило вычисления значения таково:

DB_WRITER_PROCESSES = 2 * number of CPUs

Тесты для Solaris 8 с наложенным патчем 108813-11 и позднее, и для Solaris 9, показывают, что настройки:

DISK_ASYNCH_IO = TRUE

DB_WRITER_PROCESSES = 1

могут давать лучшие результаты, по сравнению с DISK_ASYNCH_IO установленным в FALSE.

NetApp рекомендует использовать ASYNC_IO для Solaris 2.8 и новее.

4.2. DB_FILE_MULTIBLOCK_READ_COUNT

Определяет максимальное количество блоков базы данных, читаемое за одну операцию ввода-вывода во время full table scan. Число читаемых байтов базы данных вычисляется умножением DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT. Установка этого параметра уменьшает число вызовов операции ввода-вывода, требуемых для full table scan, что улучшает производительность. Увеличение этого значения может улучшить производительность базы данных, которая совершает много full table scans, но ухудшает производительность для баз данных OLTP, где full table scans довольно редок.

Установка этого числа кратным величине NFS READ/WRITE, определенным при монтировании, уменьшит величину фрагментации, которая возникает при вводе-выводе. Обратите внимание, что этот параметр определен в «блоках базы данных», а установки NFS - в «байтах», так что необходимо выравнивание значений с учетом этого. Например, установка значения DB_FILE_MULTIBLOCK_READ_COUNT в 4, умноженное на DB_BLOCK_SIZE равное 8kB, даст размер буфера чтения в 32kB.

NetApp рекомендует, чтобы значение DB_FILE_MULTIBLOCK_READ_COUNT было установлено от 1 до 4 для OLTP-баз, и от 16 до 32 для DSS.

4.3. DB_BLOCK_SIZE

Для наилучшей производительности базы данных, DB_BLOCK_SIZE должен быть кратен размеру блока в OS. Например, если размер блока в Solaris равен 4096:

DB_BLOCK_SIZE = 4096 * n

Опции NFS rsize и wsize, определяемые при монтировании файловой системы, также должны быть кратны этой величине. Ни в коем случае они не должны быть меньше. Например, если DB_BLOCK_SIZE в Oracle равен 16kB, то NFS rsize и wsize (размеры блоков чтения и записи) должны быть 16kB или 32kB, но не 8kB или 4kB.

4.4. DBWR_IO_SLAVES и DB_WRITER_PROCESSES

DB_WRITER_PROCESSES важен для систем, которые изменяют много данных. Он определяет исходное число процессов записи базы данных (DBWR – database writer processes), для соответствующего экземпляра (instance). Если используется DBWR_IO_SLAVES, то будет разрешен только один процесс записи (database writer process), независимо от величины DB_WRITER_PROCESSES. Множественные DBWR и DBWR IO slaves не могут существовать в системе одновременно. Рекомендуется использовать или ту или другую опцию для компенсации снижения производительности при выключении DISK_ASYNCH_IO. Статья на Metalink 97291.1 дает руководство по их использованию.

NetApp рекомендует использовать DBWR_IO_SLAVES для систем с одним CPU, и

DB_WRITER_PROCESSES для многопроцессорных систем.

Главное правило настройки опций – всегда включать DISK_ASYNCH_IO, если это поддерживается операционной системой. Следующим шагом проверьте, поддерживается ли это в NFS, или только для блочного доступа (FC/iSCSI). Если поддерживается в NFS, тогда включите async I/O на уровне Oracle, и на уровне OS и замерьте изменение производительности. Если прирост заметен, то используйте async I/O для NFS. Если async I/O не поддерживается для NFS, или прирост производительности незначителен, то тогда попробуйте вулючить множественные DBWRs и DBWR IO slaves, как описано далее.

4.5. DB_BLOCK_LRU_LATCHES

Число DBWRs не может превышать величину в параметре DB_BLOCK_LRU_LATCHES:

DB_BLOCK_LRU_LATCHES = DB_WRITER_PROCESSES

Начиная с версии Oracle9i, параметр DB_BLOCK_LRU_LATCHES отсутствует, и не требует установки.

5. Резервное копирование, восстановление, катастрофоустойчивость

Для дополнительной информации о разработке стратегии резервного копирования, восстановления и катастрофоустойчивости, смотрите [8], [9], и [10].

Для дополнительной информации об организации быстрого резервного копирования и восстановления Oracle Database под UNIX^®, смотрите [3] и [7].

5.1. Как создать резервную копию данных с системы хранения NetApp

Данные, хранящиеся на системе хранения NetApp, могут быть скопированы на другую систему хранения, на систему типа nearline, или магнитную ленту. Всегда следует учитывать протокол, используемый для доступа к данным, когда создается резервная копия. Когда для доступа к данным используются NFS и CIFS, то использование Snapshot и SnapMirror^® всегда даст в результате консистентную копию файловой системы. Но они должны координироваться с состоянием базы данных Oracle, чтобы получить консистентность также и для базы данных.

В случае использования протоколов Fibre Channel или iSCSI, снэпшот-копии и команды SnapMirror должны также быть скоординированы с сервером. Файловая система на сервере должна быть залокирована, и все данные в памяти сброшены на диски, до того, как мы отдадим команду на создание снэпшота.

Данные могут быть сохранены на ту же систему хранения, на другую такую же, на систему NearStore^® или на устройство хранения на магнитной ленте. Устройство на ленте может быть подключено как непосредственно к системе хранения, так и находиться в сети, SAN (Fibre Channel) или LAN (Ethernet), и система хранения может проводить резервное копирование своих данных через сеть на такое устройство.

Возможные варианты для резервного копирования данных системы хранения NetApp таковы:

Использовать SnapManager for Oracle для создания онлайн- или оффлайн-бэкапа
Использовать авоматически создаваемые снэпшоты для создания онлайн-бэкапа
Использовать скрипты на сервере, работающие на системе хранения по rsh, для того, чтобы создавать снэпшоты и производить онлайн-бэкап
Использовать SnapMirror для репликации данных на другую систему хранения или систему типа NearStore
Использовать SnapVault^® для сохранения данных на другой системе хранения NetApp или системе NearStore
Использовать команды серверной OS для копирования данных и создания резервной копии
Использовать команды NDMP для сохранения данных на другой системе хранения NetApp или системе NearStore
Использовать команды NDMP для резервного копирования на устройство хранения на магнитной ленте
Использовать дополнительные «third-party» инструменты резервного копирования, для копирования данных с системы хранения или NearStore на ленты или другие устройства хранения

5.2. Создание онлайн-копий с помощью Snapshot

Технология NetApp Snapshot

1. Введение