RedHat/Oracle Linux з NetApp FAS (SAN)

У цій статті я хотів би розглянути більш вузьку тему оптимізації RedHat/Oracle Linux (з віртуалізацією і без) з використанням СГД NetApp FAS в середовищі SAN.

Для пошуку і усунення вузьких місць в такій інфраструктурі, потрібно визначитись з компонентами інфраструктури, серед яких їх варто шукати. Розділимо інфраструктуру на наступні компоненти:

  • Налаштування хоста c SAN (FC/Fco)
  • Налаштування мережі 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, коли за однією фізики можуть ходити одночасно Fco, 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.
image

Гостьова ОС так і хост BareMetal Linux

Хочу звернути вашу увагу на те, що в більшості дистрибутивів Linux в якості віртуальної машини так і BareMetal параметр I/O scheduling встановлений в значення не підходяще для FAS систем, це може призводити до високої утилізації CPU.
image
Зверніть увагу на висновок команди 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, для того, щоб гнучко встановлювати настрйки для кожного окремого блочного пристрою.
Приклад скрипта встановлення scheduler в noop для sdbНе забудьте поміняти sdb на ім'я вашого блочного пристрою
cat /etc/rc.local | grep-iv "^exit" > /tmp/temp
echo-e "echo noop > /sys/block/скб/queue/scheduler\nexit 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
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
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

Інтерпретація iostatДокладніше тут.
Iostat Windows, аналог
rrqm/s (The,number of merged read requests queued per second.) read I/O per second LogicalDisk(*)\Disk Transfers/sec = rrqm/s+wrqm/s., Для Linux машин додати колонку rrqm/s, а LogicalDisk(*)\Disk Transfers/sec пропускати
wrqm/s (The number of merged write requests,queued per second.) write I/O per second LogicalDisk(*)\Disk Transfers/sec = rrqm/s+wrqm/s., Для Linux машин додати колонку wrqm/s, а LogicalDisk(*)\Disk Transfers/sec пропускати
r/s (The number of read requests sent to the device per,second.) Disk,reads/sec
w/s (The number of write requests sent to the device per,second.) Disk,writes/sec
rsec/s (The number of sectors read per second.) потрібно знати розмір сектора, зазвичай,512 байт. rsec/s*512=,"\LogicalDisk(*)\Disk,Read Bytes/sec",
wsec/s (The number of sectors written per second.) потрібно знати розмір сектора, зазвичай,512 байт. wsec/s*512=,"\LogicalDisk(*)\Disk Write Bytes/sec",
avgrq-sz (The request size in sectors.) потрібно знати розмір сектора, зазвичай 512 байт. avgrq-sz — середній розмір оперованого блоку — потрібен. Додати колонку, в Windows він вираховується з інших параметрів.
avgqu-sz (The number of,requests waiting in the device's queue.) "\LogicalDisk(*)\Avg.,Disk Queue Length". Окремо за Read і Write виходить немає, але цього достатньо. Співвідношення читання запису буде вираховуватися за «rrqm/s», з «wrqm/s» або «r/s», з «w/s., Тобто, для Linux пропускати:,LogicalDisk(*)\Avg.,Disk Read Queue Length,LogicalDisk(_Total)\Avg.,Disk Write Queue Length.
await (The number of milliseconds required to respond to,requests) Середня,Latency, в Windows це значення не видає, вираховується з інших, пареметров, додати колонку, параметр потрібен.
svctm (The number of milliseconds spent servicing,requests from beginning to end) Час виконання запиту. Додати окрему колонку для Linux машин, стане в нагоді
%util (The percentage of CPU time during which requests were,issued) "\Processor(_total)\%,Processor Time", навантаження на CPU нехай буде (додати колонку), з неї опосередковано зрозуміло перевантаження дискової підсистеми.


Програми


В залежності від конфігурації, протоколів, навантажень та інфраструктури ваші програми можуть мати різні рекомендації налаштування і тонкого тюнінга. Для цього звертайтеся за Best Practice Guide для відповідних додатків для вашої конфігурації. Найпоширенішими можуть бути


Драйвера


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

Сумісність


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

Впевнений, що з часом мені буде що додати цю статтю з оптимізації Linux хоста, через час, так що заглядайте сюди час від часу.

Зауваження щодо помилок у тексті та пропозиції прошу направляти в ЛС.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.