Про модулі multipahing. PSA, NMP, MMP, SATP, PSP

До одного LUN у нас можуть вести кілька шляхів Через різні HBA і різні контролери в СГД За рахунок декількох шляхів до LUN ми отримуємо дублювання і можливість продовжити роботу при виході з ладу якогось компонента інфраструктури SAN за рахунок переходу до працюючого шляху Ще наявність декількох шляхів може допомогти підвищити продуктивність за рахунок розподілу навантаження між шляхами Налаштування multipathing визначають:

Q коли перемикатися – через яку кількість непрочітанних/незапісан-

вих блоків порахувати використовуваний шлях збійних

Q-який target використовувати – будь-який або явно вказаний

Q-який HBA використовувати – будь-який, явно вказаний або найменш завантажений

Після назви політик multipathing, описаних трохи вище, в дужках написано «VMware» Це тому, що це налаштування вбудованого модуля multipathing, розробленого VMware А в ESX (i) версії 4 зявилася можливість вико вать сторонні модулі

При читанні документації на цю тему вам можуть зустрітися наступні терміни:

Q  PSA – Pluggable  Storage Architecture

Q  NMP – Native Multipathing

Q  SATP – Storage Array Type Plugins

Q  PSP  – Path  Selection Plugins

Як вони співвідносяться, см на рис 310

PSA – це загальна назва архітектури, яка дозволяє ESX (i) використовувати сторонні модулі для роботи з SAN Також PSA – це назва набору API для VMkernel Вони були додані до складу гіпервізора і виконують такі завдання, як:

Рис 310 Схема звязків модулів гіпервізора для роботи з дисковою підсистемою Джерело: VMware

Q завантаження і вивантаження модулів MPP

Q виявлення і видалення шляхів до LUN

Q перенаправлення запитів вводу-виводу до потрібного MPP

Q поділ пропускної здатності між ВМ

Q збір статистики по вводу-висновку

Q координація дій Native Multipathing Module і сторонніх плагінів, розроблених за допомогою PSA API

NMP – стандартний модуль роботи з системою зберігання, використовуваний за замовчуванням і включає multipathing Асоціює набір шляхів з LUN NMP підтримує всі системи зберігання зі списку сумісності vSphere NMP містить в собі два компоненти – SATP і PSP

SATP – управляє перемиканням шляхів, відстежує доступність шляхів і повідомляє про зміни в NMP, і все це – для конкретного типу СГД Тобто NMP працює з усіма типами підтримуваних сховищ за рахунок того, що для кожного типу у нього в складі є свій SATP, обізнане про те, як працювати з тією чи іншою моделлю СГД Кожен SATP для конкретної моделі може володіти можливістю виконувати специфічні для моделі дії з виявлення відмови шляху і переходу на резервний шлях VMware поставляє SATP для всіх підтримуваних систем зберігання – generic Storage Array Type Plugins для типових систем зберігання та local Storage Array Type Plugin для DAS

Побачити інформацію про SATP та їх налаштування можна за допомогою команд:

esxcli nmp  satp  list esxcli nmp  satp listrules

esxcli nmp satp listrules-s <конкретний SATP>

PSP (Path selection plugin) – вибирає кращий шлях По суті, цей компонент відпрацьовує настройку multipathing (ту, що Fixed / MRU / Round Robin) Сторін ний PSP може вміти балансувати навантаження за більш складним алгоритмам, ніж стандартний Зокрема, задіяти всі шляхи одночасно, а не послідовно

Найголовніше – архітектура PSA припускає можливість використання сторонніх модулів multipathing, які можуть працювати замість або разом зі стандартними Їх VMware називає MPP

MPP – multipathing plugin Сторонній модуль роботи з системою зберігання (сторонній модуль multipathing) є альтернативою NMP, тобто стандартному модулю роботи з системами зберігання Розробляється MPP постачальниками СГД, які можуть удосконалити способи визначення збоїв і переходу на інші шляхи за рахунок використання специфічних можливостей системи зберігання Також за допомогою цих сторонніх модулів можлива робота ESX (i) з масивами, спочатку не підтримуваними

Сторонні модулі діляться на три категорії (рис 311):

Q сторонні MPP забезпечують підтримку специфічною моделі СГД і роблять роботу з нею більш продуктивної і надійною Модуль або модулі MPP працюють одночасно з NMP – стандартним модулем роботи з системами зберігання, якщо той використовується ESX (i) для інших систем зберігання (наприклад, локальних дисків)

Рис 311 Схема співіснування вбудованого і сторонніх модулів multipathing Джерело: VMware

Q сторонні SATP інтегруються в NMP, забезпечують його роботу з системами зберігання, яких той не підтримує

Q сторонні PSP інтегруються в NMP Містять в собі описи більш

складних алгоритмів балансування I / O

Коли сервер завантажується, PSA виявляє всі шляхи до LUNам Відповідно до правил, описаними у файлі налаштування (esxconf), PSA визначає, який з модулів multipathing повинен управляти шляхами до того чи іншого сховища Цими модулями можуть бути NMP від ​​VMware або MPP від ​​стороннього виробника

NMP, знову ж таки в залежності від налаштувань, вибирає, який з доступних SATP використовувати для моніторингу шляхів, асоціює потрібний модуль PSP для управління цими шляхами Наприклад, для сімейства EMC CLARiiON CX за замовчуванням використовуються SATP-модуль «VMW_SATP_CX» і PSP-модуль

«Most Recently Used»

За допомогою vSphere CLI і команди

esxcli  corestorage  claimrule list

можна подивитися на завантажені модулі і вказати настройки (claim rules) для PSA, NMP SATP, налаштувати маскування LUN

Командою

esxcli nmp  satp list

можна побачити список SATP для NMP А командою

esxcli nmp  psp  list

можна побачити список PSP для NMP

Ці налаштування зберігаються у файлі / etc / vmware / esxconf, і їх можна переглянути Побачите сходинку види:

/storage/plugin/NMP/config[VMW_SATP_SYMM]/defaultpsp =  «VMW_PSP_FIXED»

Цей рядок файлу налаштувань повідомляє:

Для SATP з імям «VMW_SATP_SYMM» використовувати PSP з імям

«VMW_PSP_FIXED» Цей SATP застосовується для роботи з EMС Symmetrix, цей PSP припускає політику шляхів «Fixed»

З графічного інтерфейсу ми можемо побачити наступне: Configuration

Storage Adapters ⇒ потрібний HBA ⇒ кнопка Paths (Рис 312)

Тут ми бачимо інформацію про доступні шляхах і про те, які з шляхів яв-

ляють активними Для ESX (i) четвертої версії під «Active» шляхом розуміється той, який можна задіяти для доступу до LUN Задіяний у даний момент шлях позначається як «Active (I / O)» «Standby» – Такий шлях можна

Рис 312 Інформація про доступні шляхах

задіяти в разі збою активного шляху «Broken» (на малюнку таких немає) – збійний шлях Зірочкою позначено бажаний (Preferred) шлях у разі політики multipathing «Fixed»

Configuration Storage ⇒ кнопка Devices ⇒ цікавить LUN (рис 313)

Рис 313 Інформація про шляхи

Тут можна побачити, який модуль управляє доступом до LUN У даному прикладі це NMP, тобто стандартний модуль від VMware

Ну і нарешті, до чого все це

Постачальник вашої системи зберігання може запропонувати вам модуль multipa thing, що працює краще стандартного зі складу ESX (i) Якщо так, має сенс його встановити Подробиці шукайте в документації конкретного виробника Наприклад, EMC пропонує PowerPath for VMware vSphere 4 – це і є MPP

Резюме: для ESX (i) 4 VMware надає можливість і механізми для розробки сторонніх модулів роботи з системами зберігання, які можуть працювати ефективніше стандартного

Кілька слів про NMP, стандартний модуль multipathing Досить важливе питання: скільки часу потрібно, щоб перейти на інший шлях у разі відмови використовуваного NMP починає задіяти інший шлях відразу ж, як тільки драйвер HBA поверне відмова I / O У разі Fibre Channel цей час менше 30 секунд Потім NMP потрібно менше 30 секунд, щоб переключитися на інший шлях Таким чином, час недоступності LUN для ESX (i) буде менше 60 секунд Всі запити до дискової підсистеми від ВМ ESX (i) помістить в чергу Але саме через можливість такої паузи VMware рекомендує встановлювати час очікування реакції введення-виведення для гостьової ОС в 60 секунд (подробиці див в розділі 524 «Рекомендації для еталонних ВМ»)

У адмініструванні SAN є два поняття: Zoning і LUN Masking Вони важливі, тому їх торкнуся трохи докладніше

Ось дивіться – у вас є система зберігання, і до неї підключені сервери Швидше за все, це сервери з різними завданнями Якісь використовуються під віртуальні машини, і на них встановлений ESX (i) Якісь використовуються без віртуалізації, і на них встановлені Windows, Linux та інші операційні системи

І на системі зберігання ми створюємо окремі LUNи для цих серверів У переважній більшості випадків нам не треба, щоб LUN, на якому ESX зберігає свої ВМ, був доступний з фізичного сервера з, приміром Windows, і навпаки Більш того, якщо він буде доступний – це дуже небезпечно, оскільки може призвести до пошкодження даних ESX на такому LUN створить свою файлову систему, VMFS, а Windows поняття не має, що це за файлова система І буде вважати цей диск порожнім І дасть нам його відформатувати в NTFS А це знищить VMFS і ВМ на ній Ось для запобігання подібних ексцесів і необхідні правиль ное зонування і маскування

Зонування – Процес налаштування доступності СГД з боку серверів Виконується на рівні комутатора FC, в якому ми вказуємо видимість портів один одним Тобто ми налаштовуємо, які HBA до яких SP зможуть звертатися Деякі комутатори FC вимагають настройки зонування завжди, поза зави-

ності від того, чи необхідна ця настройка нам Але як правильно налаштовувати зони – треба дивитися документацію конкретного виробника

Зонировать можна по портах або по WWN WWN, World Wide Name – це унікальний ідентифікатор пристрою в мережі SAN, аналог MAC-адреси Ethernet Наприклад, якщо ви подивитеся на мал 314, то побачите в нижній частині малюнка WWN контролера в сервері (HBA) і контролера в системі зберігання (SP)

Рис 314 Інформація про шляхи до LUN

VMware рекомендує зонувати по портах, а не по WWN Повязано це з тим, що одному порту ESX (i) можуть відповідати кілька WWN Таке може статися в разі, якщо ми призначаємо унікальні власні WWN якимось віртуальним машинам Дозволяє це механізм називається NPIV – N-Port ID Virtualization Якщо наше обладнання FC підтримує даний стандарт, то у властивостях ВМ ми можемо активувати відповідне налаштування Докладніше дивіться у розділі, присвяченому ВМ

Маскування – Налаштування, виконувана на системі зберігання Суть настройки – у вказівці того, якому HBA (отже, серверу) які LUN повинні бути видні Робиться на рівні WWN, тобто в інтерфейсі управління системи зберігання ми повинні вибрати LUN і вибрати WWN тих серверів (їх HBA), які повинні його побачити У інтерфейсах різних систем зберігання ця опера-

ція може називатися по-різному десь вона називається «представленої LUN», LUN Presentation

Налаштування зонування і маскування є взаємодоповнюючими З точки зору адміністратора ESX (i), необхідно, щоб коректно було виконано зонування – наші сервери ESX (i) мали доступ до СГД І на цих СГД була зроблена маскування – тобто сервери ESX (i) мали доступ до виділених під ВМ LUN, не мали доступу ні до яких інших LUN і щоб до їх LUN не мали доступу ніякі інші сервери

Зверніть увагу Маскування може виконуватися на самому сервері ESX (i) Це необхідно в тому випадку, коли ми хочемо приховати якийсь LUN від ESX (i), але зробити це на SAN ми з якихось причин не можемо Для того щоб замаскувати LUN з боку ESX (i) (фактично заховати самому від себе), нам знадобляться vSphere CLI і розділ Mask Paths в документі Fibre Channel SAN Configuration Guide

Джерело: Міхєєв М О Адміністрування VMware vSphere 41 – М: ДМК Пресс, 2011 – 448 с: Ил

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*