Storage Federation або всі СГД підприємства об'єднуйтеся в федерацію



У сучасному світі, де дані/інформація вже давно стали життєво важливими для будь-якого бізнесу, можливість вільно переміщувати дані між системами зберігання підприємства стає все більш важливою, ніж будь-коли. Необхідність простого та гнучкого переміщення даних може бути продиктована різними завданнями, наприклад:

  • оптимізація використання ємності більш продуктивних дискових масивів; так дані, для яких більше не потрібна дуже висока швидкість обробки, повинні бути переміщені з all-flesh масиву масив з жорсткими дисками, для того щоб звільнити дорогу ємність на SSD накопичувачах під інші завдання;

  • підвищення ефективності використання дискових і обчислювальних ресурсів масивів: якщо на одному масиві вам не вистачає якихось ресурсів (ємності або продуктивності), а на іншому масиві (розташованому поруч або в сусідньому корпусі) такі ресурси є в надлишку, то переміщення частини даних з одного масиву на інший дозволить вирішити цю проблему і при цьому не потрібно витрачати гроші на апгрейд масивів; тобто, тут мова йде фактично про балансування навантаження між декількома масивами;

  • виведення застарілого масиву з експлуатації і переміщення даних з цього масиву на новий масив.
І тут, звичайно, важлива не стільки сама можливість переміщення даних, скільки простота цього процесу, можливість переміщати дані в будь-якому напрямку, можливість переміщати дані без зупинки бізнес-процесів (тобто, прозоро для серверів і додатків). Також важливо щоб все це можна було реалізувати без додаткових витрат на спеціальне апаратне або програмне забезпечення.

HPE 3PAR Storage Federation як раз і дозволяє реалізувати все викладене вище. HPE 3PAR Storage Federation дозволяє об'єднати декілька масивів HPE 3PAR StoreServ в єдину логічну систему з метою підвищення утилізації дискових ресурсів всієї системи і балансування навантаження між різними компонентами системи. Передача даних виконується одним кліком мишки. Крім того, інші масиви (тобто, масиви не відносяться до сімейства HPE 3PAR StoreServ) також можуть бути включені в загальну систему, але з одним винятком: перенесення даних в цьому випадку буде можливий лише в одному напрямку – в масив StoreServ з масиву не-StoreServ.

Далі я спробую коротко описати, як працює федерація дискових масивів і що потрібно для її налаштування.

Топологія
У федерацію сьогодні можна об'єднати до 4 масивів НРЕ 3PAR StoreServ, це можуть бути різні моделі, як сучасні, так і попередніх поколінь, скажімо, 7400, 8450 і 20800. Федерація дозволяє переміщувати дані між будь-якою парою масивів в обох напрямках, для цього на масивах повинен стояти мікрокод не нижче 3.2.2 MU1. До масивів, включеним у федерацію (далі такі масиви будуть іменуватися «зовнішніми»), також можна підключити й інші масиви, з яких потрібно робити односторонню міграцію (такі масиви називаються «джерела міграції» migration sources). Одностороння міграція підтримується як з масивів НРЕ 3PAR StoreServ, так і з інших масивів HPE: EVA/P6000 і P9500 / XP10000 / XP12000 / XP20000 / XP24000, а також і з масивів третіх виробників: EMC CX4 / VNX / vMAX, HDS USP / USP-V / USP-VM / VSP, IBM XiV. Таких джерел міграції може бути до 6, але сумарна кількість масивів, федеративних і джерел міграції не може перевищувати 8. Нижче наведено 2 варіанти можливих конфігурацій. Стрілочками на цих малюнках показані можливі напрямки міграції даних.


Рис.1. два федеративних масиву і 6 джерел міграції


Рис.2. чотири федеративних масиву та 4 джерела міграції

Далі в цьому блозі я буду говорити тільки про федеративний масивах. Про перенесення даних на масиви НРЕ 3PAR StoreServ з інших масивів я розповім в наступних публікаціях.

Порти і зони
На федеративному масиві потрібно виділити 2 порти FC, через які на цей масив буде виконуватися міграція даних, такі порти називаються peer. Порти, через які буде виконуватися міграція на інший/інші масиви називаються host портами. Host порти можуть бути як виділених, так і не виділеними. Peer і host порти федеративних масивів потрібно об'єднати в зони і в даному випадку можна використовувати спрощену схему зонування, в якій на всі порти можна використовувати тільки 2 зони (див. рис. 3 нижче): в кожну зону об'єднується по одному peer порту і по одному host порту від кожного масиву.


Рис. 3. Схема зонування для дискових масивів, об'єднаних у федерацію.

Варіанти міграції
Підтримуються 3 варіанти міграції:

  • Онлайн міграція можлива якщо серверна ОС і ПО multipath підтримують додавання шляхів доступу до томів в онлайні. При онлайн міграції сервер (сервери) не втрачає доступ до своїх томів і обробка масивом запитів вводу/виводу від сервера не переривається.
Для онлайн міграції можливі два варіанти:

— міграція на рівні сервера – в цьому випадку всі томи, експортовані певного серверу (або групі серверів) будуть мигрированы одночасно.

— міграція на рівні тома (групи томів) – в цьому випадку тільки частина томів, експортованих певного серверу (або групі серверів) будуть мигрированы одночасно. При цьому інші томи сервера будуть продовжувати обслуговуватися масивом. Саме цей варіант міграції дозволяє перерозподіляти навантаження вводу/виводу між кількома масивами, сервер може одночасно звертатися до всіх своїх томів: до томів, які вже смигрированы на інший масив, до томів, які знаходяться в процесі міграції, і до томів, які не повинні бути смигрированы.

  • Міграція з мінімальним часом простою (Minimally Disruptive Migration). Якщо варіант з онлайн міграцією не можливий, тоді можна виконати міграцію з мінімальним часом простою. Час простою визначається тимчасовими витратами, необхідними для зміни конфігурації сервера – щоб він бачив target-масив замість source-масиву. Під час міграції сервера будуть доступні всі його дані. Цей варіант міграції можливий тільки на рівні сервера (див. вище).

  • Оффлайн міграція. Цей варіант міграції використовується, якщо потрібно мігрувати не-презентовані тома.
Можливість того чи іншого варанта міграції залежить від операційної системи сервера (серверів), дані якого потрібно буде переміщати. Онлайн міграція можлива, наприклад, для таких ОС: Windows Server 2008/2012, RedHat Enterprise 5/6/7, SuSE Enterprise 10/11/12, VmWARE 5.x/6.0.

Процес міграції
Початкова настройка Storage Federation зводиться до декількох простих кроків, які виконуються з графічної керуючої консолі SSMC (StoreServ Management Console):

  • вибираємо масиви, які хочемо об'єднати у федерацію;
  • призначаємо peer і host порти на цих масивах і включаємо їх у зони (зони на комутаторах потрібно буде створити заздалегідь)
Міграція на рівні тома (групи томів) і міграція на рівні хоста (коли мигрируются всі томи, презентовані хосту) реалізовані по-різному. Справа в тому, що при міграції на рівні тома масив-джерело повинен продовжувати обслуговування всіх інших томів даного хоста, які не мигрируются. Для міграції на рівні тома потрібно, щоб хост підтримував SCSI-протокол ALUA multipathing.

Процес міграції на рівні тома виглядає наступним чином:

  • Вибирається група томів, які потрібно мігрувати. При цьому кожен том-сточник автоматично експортується (презентується) таргет-масиву і далі таргет-масив автоматично експортує ці томи хосту. Тома-копії (на таргет-масиві) будуть мати рівно ті ж WWN, що і відповідні томи-джерела.

  • У підсумку хост побачить нові шляхи доступу для кожного тома і запросить статус (за допомогою Report Target Port Group (RTPG) SCSI command) цих нових шляхів у масиву. В результаті хост буде бачити кожен том за двома групами шляхів (Target Port Groups): перша група – через порти масиву-джерела і друга група – через порти таргет-масиву. При цьому перша група буде знаходиться в режимі active optimized, а друга група – в режимі standby.

  • Далі стартує процес міграції, при цьому спочатку змінюється режим TPG: перша група шляхів переходить в режим standby, а друга – в режим active optimized (див. рис. 4). Після цього всі запити вводу/виводу підуть вже на таргет масив. Запускається копіювання даних з тома-джерела в тому-копію, копіювання, природно, виконується безпосередньо між двома масивами без участі хостів.

  • У процесі міграції запис нових даних виконується копію, при цьому нові дані також копіюються таргет-масивом у вихідний (на той випадок, якщо раптом щось піде не так, щоб дані не були втрачені). При цьому читання буде виконуватися локально (тобто, з тома-копії) – якщо запитувані блоки вже були смигрироанны. Якщо ж запитувані блоки ще не були смигрироанны, то вони будуть смигрированны «поза чергою». Природно очікувати деякого зниження продуктивності в процесі міграції.

  • Після завершення міграції тома (групи томів) – він буде остаточно перебувати на таргет-масиві. Тому-джерело може бути автоматично видалений після успішного завершення міграції або залишений на масиві-джерелі – в залежності від обраних налаштувань міграції. Якщо налаштування такі, що те-джерело автоматично не віддаляється – ніякого дзеркальних томів після завершення міграції виконуватися вже не буде. В процесі міграції і після завершення міграції тома на масиві-джерелі, які не брали участь в міграції, доступні хосту без будь-яких обмежень/змін.

Рис. 4. Стан шляхів доступу до мигрируемому того (V-B) під час міграції даних.

На закінчення хочу додати, що федерацію можна використовувати також і в тому випадку, якщо використовуються катастрофостійкі рішення і рішення високої доступності. Тобто, можна мігрувати томи, з якими працює серверний кластер. Можна мігрувати томи, які беруть участь в реплікації між масивами HPE StoreServ (в цьому випадку тома з одного масиву з репликационной пари мігрують на третій масив – зі збереженням реплікації цих томів; мігрувати можна або тома-source, або тому-target). Так, і ще потрібно додати, що при міграції підтримуються консистентні групи (consistency group): якщо додаток працює з декількома томами, то такі томи слід мігрувати як консистентне групу томів. Консистентне група означає, що віддзеркалення томів між таргет-масивом і вихідним масивів буде тривати до тих пір, поки всі томи з консистентним групи не будуть смигрированы на таргет-масив.

Ліцензії
Ліцензія для Storage Federation називається зовсім не Storage Federation… а Peer Motion. Ліцензувати потрібно все масиви, включені в федерацію – якщо вам потрібна можливість двобічної міграція. Якщо ж потрібна тільки однонаправлена міграція, тоді можна ліцензувати тільки таргет-масиви.

Так що, якщо ви адміністратор декількох масивів HPE StoreServ – можете відразу скористатися перевагами Storage Federation, не відкладаючи в довгий ящик. Кажучи скористатися відразу – я маю на увазі можливість використовувати тріальні (trial) ліцензії для оцінки можливостей Storage Federation.

Об'єднуйте масиви у федерацію, воно того варте!
Джерело: Хабрахабр

0 коментарів

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