RedHat-Oracle Linux с NetApp FAS (SAN)

В этой статье я хотел бы рассмотреть более узкую тему оптимизации RedHat/Oracle Linux (с виртуализацией и без) с использованием СХД NetApp FAS в среде SAN.

Для поиска и устранения узких мест в такой инфраструктуре, нужно опредилиться с компонентами инфраструктуры, среди которых их стоит искать. Разделим инфраструктуру на следующие компоненты:

• Настройки хоста c SAN (FC/FCoE)
• Настройки Ethernet сети на хосте для IP SAN ( iSCSI ).
• Собственно сам хост с ОС
• Приложениями на Хосте
• Проверка совместимости драйверов и версий ПО

Для поиска узкого места обычно выполняют методику последовательного исключения. Предлагаю перво-наперво начать с СХД. А дальше двигаться СХД -> Сеть (Ethernet / FC) -> Хост -> Приложение. Сейчас остановимся на Хосте.

SAN Multipathing

В случае подключения LUN на прямую к ОС без виртуализации желательно установить NetApp Host Utility. В случае же использования виртуализации с RDM или VMFS, необходимо настроить Multipathing на гипервизоре.

Multipathing должен по-умолчанию использовать предпочтительные пути — пути к LUN через порты контроллера на котором он расположен. Сообщения в консоли СХД FCP Partner Path Misconfigured будут говорить о неправильно настроенном ALUA или MPIO. Это важный параметр, не стоит его игнорировать, так как был один реальный случай, когда взбесившийся драйвер мультипасинга хоста безостановочно переключался между путями создавая таким образом большие очереди в системе ввода-вывода. Подробнее про SAN Booting смотрите соответствующую статью: Red Hat Enterprise Linux / Oracle Enterprise Linux, Cent OS, SUSE Linux Enterprise

Ethernet

Jumbo frames

В случае использования iSCSI крайне рекомендуется использовать Jumbo Frames в Ethernet со скоростью выше или равно 1Gb. Подробнее в статье про Ethernet с NetApp FAS.

ifconfig eth0 mtu 9000 up
echo MTU=9000 >> /etc/sysconfig/network-scripts/ifcfg-eth0

ESXi & MTU9000

В случае использования окружения ESXi, не забудьте создать правильный сетевой адаптер — E1000 для 1GB сетей или VMXNET3 если у вас сеть выше чем 1Gb. E1000 и VMXNET3 поддерживают MTU 9000, а стандартный виртуальный сетевой адаптер типа «Flexible» не поддерживает.

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

Converged Network

Учитывая «универсальность» 10GBE, когда по одной физике могут ходить одновременно FCoE, NFS, CIFS, iSCSI, на ряду с применением таких технологий как vPC и LACP, а также простоту обслуживания Ethernet сетей выгодно отличает протокол и коммутаторы от FC таким образом предоставляя возможность «манёвра» и сохранения инвестиций в случае изменения бизнес потребностей.

FC8 vs 10GBE: iSCSI, CIFS, NFS

Внутренние тестирования СХД NetApp (у других вендоров СХД эта ситуация может отличаться) FC8G и 10GBE iSCSI, CIFS и NFS показывают практически одинаковую производительность и латенси, характерным для OLTP и виртуализации серверов и десктопов, т.е. для нагрузок с мелкими блоками и случайным чтением записью.
Рекомендую ознакомится со стаьёй описывающей сходства, отличия и перспективы Ethernet & FC.

В случае когда инфраструктура заказчика подразумевает два коммутатора, то можно говорить об одинаковой сложности настройки как SAN так и Ethernet сети. Но у многих заказчиков SAN сеть не сводится к двум SAN коммутаторам где «все видят всех», на этом как правило, настройка далеко не заканчивается, в этом плане обслуживание Ethernet намного проще. Как правило SAN сети заказчиков это множество коммутаторов с избыточными линками и связями с удалёнными сайтами, что отнюдь не тривиально в обслуживании. И если что-то пойдёт не так, Wireshark'ом трафик не «послушаешь».

Современные конвергентные коммутаторы, такие как Cisco Nexus 5500 способны коммутировать как трафик Ethernet так и FC позволяя иметь большую гибкость в будущем благодаря решению «два-в-одном».

Thin Provitioning

В случае использования «файловых» протоколов NFS и CIFS очень просто получать преимущество от использования технологии Thin Provitioning, возвращая высвобожденное пространство внутрь файловой шары. А вот в случае с SAN использование ThinProvitioning приводит к необходимости постоянного контроля над свободным пространством плюс высвобождение свободного пространства (механизм доступен для современных ОС) происходит не «внутрь» того же LUN, а как бы внутрь Volume содержащий этот LUN. Рекомендую ознакомиться с документом NetApp Thin-Provisioned LUNs on RHEL 6.2 Deployment Guide.

Хост ESXi

Отдавать гостевой ОС все ресурсы сервера не стоит, во первых гипервизору нужно оставить минимум 4ГБ ОЗУ, во вторых иногда наблюдается обратный эффект при добавлении ресурсов гостевой ОС, это нужно подбирать эмпирическим путём.
Плагин NetApp VSC, который сам по себе является бесплатным ПО, устанавливает рекомендуемые настройки на ESXi хосте и HBA адаптере: очередь, задержки и другие. Сам плагин устанавливается в vCenter. Экономит время и устраняет во время теста человечиский фактор при настройке около двух десятков параметров на ESXi хосте для более эффективной работы с NetApp.

Гостевая ОС так и хост BareMetal Linux

Хочу обратить ваше внимание на то, что в большинстве дистрибутивов Linux как в качестве виртуальной машины так и BareMetal параметр I/O scheduling установлен в значение не подходящее для FAS систем, это может приводить к высокой утилизации CPU.

Обратите внимание на вывод команды top, на высокую утилизацию CPU вызванную процессом dd, который в общем-то должен генерировать нагрузку только на систему хранения.

Теперь посмотрим на состояние системы хранения

iostat -dx 2 
Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util 
sda               0.00     0.00    0.00  454.00     0.00 464896.00  1024.00    67.42  150.26   2.20 100.00 

Обратите внимание на высокое значение wait. Эти два косвенных признака, высокая утилизация CPU и высокие задержки, могут нам подсказывать, что необходимо более оптимально настроить ОС и СХД для взаимодействия. Проверить стоит, к примеру: адекватность работы мультипасинга, ALUA, предпочтительных путей и очередей на HBA.

Linux elevator

Теперь про значения для elevator/scheduler:

По-умолчанию оно установлено в значение cfq или deadline:

cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq] 

Рекомендуется устанавливать его в значение noop:

echo noop > /sys/block/sda/queue/scheduler
cd /sys/block/sda/queue
grep .* * 
scheduler:[noop] deadline cfq 

Для того, чтобы настройки были постоянными, добавьте “elevator=noop” в параметры загрузки ядра в файле /etc/grub.conf, они будут применены ко всем блочным устройствам. Или добавьте соответствующий скрипт в /etc/rc.local, для того, чтобы гибко устанавливать настрйки для каждого отдельного блочного устройства.

cat /etc/rc.local | grep -iv "^exit" > /tmp/temp
echo -e "echo noop > /sys/block/sdb/queue/schedulernexit 0" >> /tmp/temp
cat /tmp/temp > /etc/rc.local; rm /tmp/temp

Настройки Sysctl с работой Virtual Memory

Стоит опытным путём подобрать наиболее оптимальные значения работы виртуальной памяти ОС — параметры sysctl: vm.dirty_background_ratio, vm.dirty_ratio и vm.swappiness.

sysctl -a | grep dirty
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500

sysctl -a | grep swappiness
vm.swappiness = 60

Так у одного заказчика наиболее оптимальными значениями для RedHat Enterprice Linux 6 с СХД NetApp с SSD кешем и подключением по FC8G были: vm.dirty_ratio = 2 и vm.dirty_background_ratio = 1, которые существенно снизили нагрузку CPU хоста. Для проверки оптимальных настроек Linux хоста воспользуйтесь утилитой Linux Host Validator and Configurator. Во время тестирования утилиты SnapDrive под Linux (или другими Unix-like) ОС воспользуйтесь SnapDrive Configuration Checker for Unix. Подробнее про подбор оптимальных параметров vm.dirty* смотите здесь. В случае использования БД Oracle или виртуализации, внутри такой Linux машины рекомендуется устанавливать значение vm.swappiness=0. Это значение даст использовать swap только когда физическая память действительно закончиться, что является наиболее оптимальным для таких задач.

sysctl -w vm.dirty_background_ratio=1
sysctl -w vm.dirty_ratio=2
echo vm.dirty_background_ratio=1 >> /etc/sysctl.conf
echo vm.dirty_ratio=2 >> /etc/sysctl.conf

#for Guest VMs or Oracle DB
sysctl -w vm.swappiness=0
echo vm.swappiness=0 >> /etc/sysctl.conf

#Reload data from /etc/sysctl.conf
sudo sysctl –p

I/O queue size или длинна очереди ввода-вывода на HBA

Значение по-умолчанию обычно 128, его нужно подбирать вручную. Увеличение длинны очереди имеет смысл при случайных операциях ввода-вывода, генерирующих множество операций disk seek на дисковой подсистеме. Изменяем так:

echo 100000  > /sys/block/[DEVICE]/queue/nr_requests

Иногда изменение этого параметра может не давать результатов, к примеру в случае с InnoDB (из-за особенностей работы этого приложения, которое само оптимизирует данные перед их записью) или в случае увеличения параметра выше дефолтного при работе с SSD дисками (так как в них нет операций disk seek).

Гостевая ОС

В некоторых случаях VMFS показывает лучшую производительность по сравнению с RDM. Так в некоторых тестах c FC4G можно получить 300 MByte/sec при использовании VMFS и около 200 MByte/sec с RDM.

Файловая система

ФС может вносить существенные коррективы при тестировании производительности.
Размер блока ФС должен быть кратным 4КБ. К примеру, если мы запускаем синтетическую нагрузку подобную генерируемой OLTP, где размер оперируемого блока в среднем равен 8КБ, то ставим 8КБ. Хочу также обратить внимание что как сама ФС, её реализация для конкретной ОС и версия может очень сильно влиять на общую картину производительности. Так для при записи 10 МБ блоками в 100 потоков командой dd файлов от БД на ФС UFS расположенной на LUN отданный по FC4G с СХД FAS 2240 и 21+2 дисками SAS 600 10k в одном агрегате показывал скорость 150 МБ/сек, тогда как та же конфигурация но с ФС ZFS показывала в два раза больше (приближаясь к теоретическому максимуму сетевого канала), а параметр Noatime вообще никак не влиял на ситуацию.

Noatime на Хосте

На уровне файловой системы можно настроить параметр при монтрировании noatime и nodiratime, который не даст обновлять время доступа к файлам, что часто очень положительно сказывается на производительности. Для таких ФС как UFS, EXT3 и др. У одного из заказчиков установка noatime при монтировании файловой системы ext3 на Red Hat Enterprise Linux 6 сильно уменьшило нагрузку на CPU хоста.

Таблица загрузки

Для Linux машин нужно при создании LUN'а выбрать геометрию диска: "linux" (для машин без xen) или "xen" в случае если на этот лун будет установлен Linux LVM с Dom0.

Misalignment

Для любой ос нужно при создании LUN'а выбрать правильную геометрию. В случае неправильно указанного размера блока ФС, неправильно указанной геометрии LUN, не правильно выбранного на хосте параметра MBR/GPT мы будем наблюдать в пиковые нагрузки сообщения в консоли о неком событии "LUN misalignment". Иногда эти сообщения могут появляться ошибочно, в случае редкого их появления просто игнорируйте их. Проверить это можно выполнив на системе хранения команду lun stats.

NetApp Host Utilities

Не игнорируйте этот пункт. Набор утилит устанавливает правильные задержки, размер очереди на HBA и другие настройки на хосте. Отображает подключённые LUN и их детальную информацию со стороны СХД. Набор утилит бесплатный и может быть скачан с сайта техподдержки нетапа. После установки запустите утилиту

host_config <-setup> <-protocol fcp|iscsi|mixed> <-multipath mpxio|dmp|non> [-noalua]

Она находиться
/opt/netapp/santools/
После чего, скорее всего, понадобится перезапустить хост.

Сбор статистики на хосте

Linux и другие Unix-like:

iostat -xn 1
top

Приложения

В зависимости от конфигурации, протоколов, нагрузок и инфраструктуры ваши приложения могут иметь различные рекомендации настройки и тонкого тюнинга. Для этого обращайтесь за Best Practice Guide для соответствующих приложений для вашей конфигурации. Самыми распространёнными могут быть

• NetApp SnapManager for Oracle & SAN сеть
• Oracle DB on Clustered ONTAP, NetApp for Oracle Database, Best Practices for Oracle Databases on NetApp Storage, SnapManager for Oracle
• Oracle VM
• DB2, DB2 and FlexClone, Deploying an IBM DB2 Multipartition Database
• MySQL
• Infrastructure for Web 2.0/LAMP Applications powered by NetApp and MySQL
• Red Hat Enterprise Linux 6, KVM
• Lotus Domino 8.5 for Linux
• Citrix XenServer
• Deploying Red Hat Enterprise Linux OpenStack Platform 4 on NetApp Clustered Data ONTAP
• и др.

Драйвера

Не забудьте установить драйвера для вашего HBA адаптера (собрав их под ваше ядро), до того, как установите NetApp Host Utility. Следуйте рекомендациям настройки HBA адаптера. Часто необходимо изменить длинну очереди и время таймаута для наиболее оптимального взаимодействия с NetApp. В случае использования виртуализации VMware ESXi или другой, не забудьте включить NPIV в случае необходимости проброса виртуальных HBA адапторов внутрь виртуальных машн. В некоторых адаптерах на базе технологии NPIV может быть настроен QoS, таких как Qlogic HBA серии 8100.

Совместимость

Не секрет что далеко не всё всегда 100% совместимо, хотя казалось бы все протоколы, разъёмы, API приложений стандартизированы, что ещё нужно для нормальной работы инфраструктуры ЦОД? Даже если иметь два компонента взаимодействующих друг с другом, произведённых одним производителем само по себе работать оно не обязано, если туда не залить точно проверенные именно для вашего случая прошивки и соответствующе не настроено. Все производители имеют матрицу совместимости, где собрано множество оттестированных комбинаций оборудования, их прошивок, подключений и приложений. Настройка ЦОД'ов далеко не тривиальный процесс и для его упрощения рекомендуется во-первых следовать лучшим практикам, во-вторых пользоваться матрицей совместимости, которые уменьшают количество потенциально проблемных мест. Так использование проверенных и оттестированых конфигураций упрощает и ускоряет процесс запуска и эксплуатации ЦОД, уменьшает фактор человеческой ошибки. Широко применяйте этот подход в вашей практике для уменьшения потенциальных проблем в инфрастурктуре ЦОД.

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

Замечания по ошибкам в тексте и предложения прошу направлять в ЛС.

Автор: bbk

Источник