NetApp ONTAP & VMware vVOL

У цій статті я хотів би розглянути внутрішній устрій і архітектуру технології vVol, реалізовану в системах зберігання даних NetApp з прошивкою ONTAP.

Чому з'явилася ця технологія і навіщо вона потрібна, чому вона буде затребувана в сучасних ЦОД?

Технологія vVol надала профілі, які при створенні ВМ створюють віртуальні диски з заданими характеристиками. У такому середовищі адміністратор віртуального середовища вже може з одного боку у себе в інтерфейсі vCenter легко і швидко перевірити, які віртуальні машини живуть на яких носіях і дізнатися їх характеристики на СГД: виконується там реплікація для DR, налаштована там компресія, дедупликация, шифрування і т. д. З технологією vVol, СГД стала просто набором ресурсів для vCenter, набагато більш глибше інтегрувавши їх один з одним, ніж це було раніше.

Проблема консолідації снепшотов і збільшення навантаження на дискову підсистему від снепшотов VMware може бути не помітна для невеликих віртуальних інфраструктур, але навіть вони можуть зустрічатися з їх негативним впливом у вигляді уповільнення роботи віртуальної машини або неможливості консолідації (видалення снепшота). vVol підтримує апаратний QoS для віртуальних дисків ВМ, а також Hardware-Assistant реплікацію і снепшоты NetApp, так як вони архітектурно влаштовані і принципово по-іншому працюють, не впливаючи на продуктивність, на відміну від COW снепшотов VMware.

image

vVol

Що взагалі таке vVol? vVol — це прошарок для датастора, тобто це технологія віртуалізації датастора. Раніше у вас був датастор, розташований на LUN'е (SAN) або файлової кулі (NAS); як правило, кожен датастор розміщував кілька віртуальних машин. vVol з одного боку уніфікувала роботу з протоколами NAS і SAN для віртуалізації середовища, адміністратору все-одно, це місяця або файли, з іншого боку, кожен віртуальний диск ВМ може жити в різних вольюмах, місяцях, дискових пулах (агрегатах), різних контролерах і можуть мати різні політики, які слідують за цим диском ВМ. У випадку із традиційним SAN все, що СГД «бачила» зі свого боку і те, чим вона могла керувати — цілком всім датастором, але не окремо кожним віртуальним диском ВМ. З vVol при створенні однієї віртуальної машини кожен її окремий диск може створюватися у відповідності з окремою політикою. Кожна політика vVol, в свою чергу, дозволяє вибирати вільний простір з доступного пулу ресурсів СГД, яке буде відповідати заздалегідь визначеним умовами в політиках vVol.

Це дозволяє більш ефективно і зручно використовувати ресурси і можливості системи зберігання. Таким чином, кожен диск віртуальної машини розташований на виділеному своєму віртуальному датасторе на подобі LUN RDM. З іншого ж боку, в технології vVol використання одного загального простору більше не є проблемою, адже апаратні снепшоты і клони виконуються не на рівні цілого датастора, а на рівні кожного окремого віртуального диска, при цьому не застосовуються COW снепшоты VMware. У теж час система зберігання тепер зможе «бачити» кожний віртуальний диск окремо, це дозволило делегувати можливості СГД в vSphere (наприклад, снепшоты), надаючи більш глибоку інтеграцію і прозорість дискових ресурсів для віртуалізації.

Компанія VMware почала розробку vVol у 2012 році та продемонстрував цю технологію через два роки в своєму превью, одночасно компанія NetApp оголосила про її підтримку у своїх системах зберігання даних з прошивкою ONTAP з усіма підтримуваними середовищем VMWare протоколами: NAS (NFS), SAN (iSCSI, FCP).



Protocol Endpoints
Давайте тепер відійдемо від абстрактного опису і перейдемо до конкретики. vVol'и розташовуються на FlexVol, для NAS і SAN це, відповідно, файли або місяця. Кожен VMDK диск живе на своєму виділеному vVol диску. Гіпервізор може запускати створення снепшота окремо для кожного диска віртуальної машини. Снепшот одного віртуального диска — це його повна копія, тобто ще один vVol. Кожна нова віртуальна машина без снепшотов складається з декількох vVol. В залежності від призначення vVol'и бувають наступних типів:

image

Тепер, власне, про PE. PE — це точка входу до vVol'ам, свого роду проксі. PE і vVol'и розташовуються на СГД. У разі NAS такою точкою входу є кожен Data LIF зі своїм IP адресою на порте СГД. У випадку з SAN це спеціальний 4МБ лун.

PE створюється на вимогу VASA Provider (VP). PE примапливает всі свої vVol за коштами Binging запиту від VP до СГД, прикладом найбільш частого запиту є старт VM.

ESXi завжди підключається до PE, а не безпосередньо до vVol. У випадку з SAN це дозволяє уникати обмеження 255 лунов на ESXi хост і обмеження в максимальній кількості шляхів на місяць. Кожна віртуальна машина може складатися з vVol тільки одного протоколу: NFS, iSCSI або FCP. Всі PE мають LUN ID 300 і вище.

Незважаючи на невеликі відмінності, NAS і SAN дуже схожим чином влаштовані з точки зору роботи vVol в середовищі віртуалізації.

cDOT::*> lun bind show -instance
Vserver: netapp-vVol-test-svm
PE MSID: 2147484885
PE Vdisk ID: 800004d5000000000000000000000063036ed591
vVol MSID: 2147484951
vVol Vdisk ID: 800005170000000000000000000000601849f224
Protocol Endpoint: /vol/ds01/vVolPE-1410312812730
PE UUID: d75eb255-2d20-4026-81e8-39e4ace3cbdb
PE Node: esxi-01
vVol: /vol/vVol31/naa.600a098044314f6c332443726e6e4534.vmdk
vVol Node: esxi-01
vVol UUID: 22a5d22a-a2bd-4239-a447-cb506936ccd0
Secondary LUN: d2378d000000
Optimal binding: true
Reference Count: 2


iGroup & Export Policy
iGroup і Export Policy — це механізми, що дозволяють приховувати від хостів доступну на СГД інформацію. Тобто надавати кожному хосту тільки те, що він повинен бачити. Як у випадку з NAS, так і SAN, мапінг лунов і експорт файлових куля відбувається автоматично з VP. iGroup мапится не на всі vVol, а тільки на PE, так як ESXi використовує PE як проксі. У разі NFS протоколу, експорт політика застосовується до файлової кулі. iGroup і експорт політика створюється та заповнюється автоматично за допомогою запиту з vCenter.

SAN & IP SAN
image

У разі протоколу iSCSI необхідно мати мінімум один Data LIF на кожній ноде СГД, який підключений до тієї ж мережі, що і відповідний VMkernel на ESXi хості. iSCSI і NFS LIF'и повинні бути розділені, але можуть співіснувати в одній IP мережі і одному VLAN. У разі FCP необхідно мати мінімум один Data LIF на кожній ноде СГД для кожної фабрики, іншими словами, як правило це два Data LIF'а від кожної ноди СГД, які живуть на своєму окремому таргет-порте. Використовуйте soft-zoning на свічі для FCP.

NAS (NFS)
image

У разі протоколу NFS необхідно мати мінімум один Data LIF з встановленим IP адресою на кожній ноде СГД, який підключений до тієї ж підмережі мережа, що і відповідний VMkernel на ESXi хості. Не можна використовувати IP-адресу для iSCSI і NFS одночасно, але вони обидва можуть співіснувати в одному VLAN, в одній підмережі і на одному фізичному Ethernet порт.

VASA Provider

VP є посередником між vCenter та СГД, він пояснює СГД, що від неї хоче vCenter і навпаки розповідає vCenter про важливих алертах і доступних ресурсах СГД, тих, які є фізично насправді. Тобто vCenter тепер може знати скільки вільного простору є насправді, це особливо зручно, коли СГД презентує гіпервізору тонкі місяця.

VP не є єдиною точкою відмови в тому сенсі, що при його виході з ладу віртуальні машини, як і раніше, будуть нормально працювати, але не можна буде створювати або редагувати політики і віртуальні машини на vVol, стартувати або зупиняти VM на vVol. Тобто у разі повного перезавантаження всієї інфраструктури, віртуальні машини не зможуть стартувати, так як не відпрацює Binding запит VP до СГД щоб примапить PE до своїх vVol. Тому VP однозначно бажано резервувати. І з тієї ж причини не дозволяється розташовувати віртуальну машину з VP на vVol, яким він керує. Чому «бажано» резервувати? Тому що, починаючи з версії NetApp VP 6.2, останній вміє відновлювати вміст vVol просто зчитуючи метаінформацію з самої СГД. Детальніше про налаштування та інтеграцію в документації VASA Provider і VSC.

Disaster Recovery

VP підтримує функціонал Disaster Recovery: у разі втрати або пошкодження VP, база даних оточення vVol може бути відновлена: Мета інформація про оточенні vVol зберігатися в дубльованому вигляді: в базі даних VP, а також разом з самими об'єктами vVol на ONTAP. Для відновлення VP достатньо від-реєструвати старий VP, підняти новий VP, зареєструвати в ньому ONTAP, там же виконати команду vp dr_recoverdb і підключити до vCenter, в останньому виконати «Rescan Storage Provider». Детальніше KB.

Функціонал DR для VP дозволить ореплицировать vVol засобами апаратної реплікації SnapMirror і відновити сайт на DR-майданчику, коли vVol почне підтримувати реплікацію СГД (VASA 3.0).

Virtual Storage Console

VSC — це плагін для СГД в графічний інтерфейс vCenter, в тому числі для роботи з політиками VP. VSC є обов'язковим компонентом для роботи vVol.

image

Snapshot & FlexClone

Давайте проведемо межу між снепшотами з точки зору гіпервізора і снепшотами з точки зору СГД. Це дуже важливо для розуміння внутрішнього устрою того, як працює vVol на NetApp з снепшотами. Як багато хто вже знають, снепшоты в ONTAP завжди виконуються на рівні вольюма (та агрегату) і не виконуються на рівні файлу/місяць. З іншого ж боку vVol, це файли або місяця, тобто з них можна для кожного окремо VMDK файлу знімати снепшоты коштами СГД. Тут на допомогу приходить технологія FlexClone, яка вміє робити клони не тільки вольюмов цілком, але і файлів/лунов. Тобто коли гіпервізор знімає снепшот віртуальної машини, яка живе на vVol, то під капотом відбувається наступне: vCenter контактує з VSC і VP, які в свою чергу знаходять, де саме живуть потрібні VMDK файли і дають команду ONATP зняти з них клон. Так, то що з боку гіпервізора виглядає як снепшот, на СГД це клон. Іншими словами, для того, щоб на vVol працювали Hardware-Assistant Snapshot необхідна ліцензія FlexClone. Саме для такої або подібних цілей у ONTAP з'явився новий функціонал FlexClone Autodelete, який дозволяє задати політики видалення старих клонів.

Так як снепшоты виконуються на рівні СГД, проблема консолідації снепшотов (ESXi) і негативний вплив снепшотов на продуктивність дискової підсистеми, повністю усунені завдяки внутрішньому устрою механізму клонування/снепшотирования в ONTAP.

Консистентним

Так як сам гіпервізор знімає снепшоты коштами СГД, то вони вже автоматично консистентні. Що дуже добре вписується в парадигму резервного копіювання NetApp ONTAP. vSphere підтримує снепшотирование пам'яті ВМ на виділений vVol.

Клонування і VDI

Функція клонування найчастіше дуже затребувана в VDI оточенні, де є необхідність швидко розгортати безліч однотипних віртуальних машин. Для того, щоб використовувати Hardware-Assistant клонування необхідна ліцензія FlexClone. Важливо відзначити, що технологія FlexClone не тільки кардинально прискорює розгортання копій великої кількості віртуальних машин, кардинально зменшуючи споживання дискового простору, але і побічно прискорює їх роботу. Клонування по суті виконує функцію подібну дедуплікаціі, тобто зменшує обсяг займаного простору. Справа в тому, що NetApp FAS завжди поміщає дані в системний кеш, а системний і SSD кеші в свою чергу є Dedup-Aware, тобто вони не затягує дублікати блоків від інших віртуальних машин, які вже там є, логічно вміщуючи набагато більше ніж фізично системний і SSD кеш можуть. Це кардинально покращує продуктивність під час експлуатації СГД і особливо в моменти Boot-Storm завдяки збільшенню попадання/читання даних з кеш(а).

UNMAP

Технологія vVol починаючи з версії VMware 6.0, VM Hardware версії 11 і Windows 2012 з файловою системою NTFS підтримує вивільнення простору всередину тонкого місяць на якій розташована дана віртуальна машина автоматично. Це істотно покращує утилізацію корисного простору в SAN інфраструктурі, що використовує Thing Provisioning і Hardware-assistant снепшоты. А починаючи з VMware 6.5 і гостьової ОС Linux з підтримкою SPC-4 також дозволить звільняти простір зсередини віртуальної машини, тому у СГД, дозволяючи істотно економити дороге простір на СГД. Детальніше про UNMAP.

Мінімальні системні вимоги

  • NetApp VASA Provider 5.0 і вище
  • VSC 5.0 і вище.
  • Clustered Data ONTAP 8.2.1 і вище
  • VMware vSphere 6.0 і вище
  • VSC і VP повинні мати однакові версії, приміром, обидва 5.х або обидва 6.х.
Детальніше уточнюйте у авторизованого партнера NetApp або матриці сумісності.

SRM і апаратна реплікація

Site Recovery Manager, на жаль, поки що не підтримує vVol так як в поточній реалізації VASA протоколу з боку VMware не підтримується реплікація і SRM. Системи NetApp FAS мають інтеграцію з SRM і працюють без vVol. Технологія vVol також підтримується з vMSC (MetroCluster) для побудови для побудови, гео-розподіленого високо-доступного сховища.

Резервне копіювання

Технологія vVol кардинально змінить підхід до резервного копіювання, зменшивши час резервного копіювання і більш ефективно використовуючи простір сховища. Однією з причин того є принципово інший підхід снепшотирования і резервного копіювання, так як vVol використовує апаратне снепшотирование, з-за чого питання консолідації і видалення снепшотов VMware відпадає. З-за усунення проблеми з консолідацією снепшотов VMware, зняття application-aware (апаратних) снепшотов і резервних копій перестає бути головним болем адмінів. Це дозволить більш часто знімати резервні копії і снепшоты. Апаратні снепшоты не впливають на продуктивність дозволять їх зберігати багато прямо на продуктивній середовищі, а апаратна реплікація дозволить більш ефективно відтворити дані для архівування або на DR-сайт. Використання снепшотов порівняно з Full-backup дозволить більш економно використовувати простір сховищ.

VASA 3.0

Не плутайте плагін від вендора СГД (наприклад NetApp VASA Provider 6.0) та API інтерфейс VMware VASA (наприклад VASA 3.0). Найважливішим і очікуваним нововведенням в vVol, найближчим часом, стане підтримка апаратної реплікації. Саме підтримки апаратної реплікації так не вистачає для того, щоб технологія vVol почала широко застосовуватися. У новій версії буде підтримується апаратна реплікація vVol дисків коштами СГД для забезпечення функції DR. Реплікацію можна було виконати і раніше коштами СГД, але гіпервізор раніше не міг працювати з отреплицированными даними через відсутність підтримки такого функціоналу в VASA 2.X (і більш молодшої) з боку vSphere. Також з'являться PowerShell командлети для управління DR на vVol, і що важливо, можливість запуску для тестування отреплицированных машин. Для запланованої міграції з DR сайту може буде запитана реплікація віртуальної машини. Це дозволить використовувати SRM разом з vVol.

Oracle RAC буде валидирован для запуску на vVol, що не може не радувати.

Ліцензування

Для роботи vVol необхідні наступні компоненти: VP, VSA і сховище з необхідною прошивкою, підтримує vVol. Ці компоненти не вимагають яких-небудь ліцензій для роботи vVol. Для того щоб підтримувалися апаратні снепшоты або клони (зняття і відновлення) необхідна ліцензія NetApp FlexClone, а для реплікації даних потрібна буде ліцензія NetApp SnapMirror/SnapVault (на обох СГД: на основної та резервної майданчиках). З боку vSphere необхідні ліцензії Standard або Enterprise Plus.

Висновки

Технологія vVol була спроектована для ще більш тісної взаємодії гіпервізора ESXi з СГД та спрощення управління. Це дозволило більш раціонально використовувати можливості та ресурси СГД, такі як Thing Provisioning, де завдяки UNMAP простір з тонких лунов може вивільнятися. При цьому гіпервізору повідомляється про реальний стан простору та ресурсів СГД, все це дозволяє застосовувати Thing Provisioning не тільки для NAS, але і використовувати його в «бойових» умовах з SAN, абстрагуватися від протоколу доступу і забезпечити прозорість інфраструктури. А політики роботи з ресурсами СГД, тонке клонування і снепшоты не впливають на продуктивність дозволять ще більш швидко і зручно розгортати віртуальні машини у віртуалізованому інфраструктурі.
Джерело: Хабрахабр

0 коментарів

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