Зміни zoning у Fibre Channel, по одному fabric за раз

Два fabric Fibre Channel захищають вас від мертвого switch. Вони не захищають вас від необережної зміни zoning, застосованої до обох fabric в одну й ту саму хвилину. Дисципліна, яка закриває цю прогалину, проста в описі і легко пропускається: змініть один fabric, доведіть результат, і лише тоді торкайтеся іншого.

Чому zoning є найризикованішою рутинною роботою в SAN

Zoning вирішує, які initiators (порти HBA хостів) можуть спілкуватися з якими targets (портами масиву). Його змінюють щоразу, коли сервер додають, замінюють або виводять з експлуатації, тож це рутинна робота, а рутинна робота є саме тим місцем, де увага розсіюється. У fabric Brocade активна конфігурація zoning є єдиним об’єктом. Коли ви вмикаєте її нову версію, весь fabric приймає нову версію одразу. Друкарська помилка, яка прибирає зону, член, вставлений не в ту зону, або конфігурація, увімкнена до того, як її завершили, можуть миттєво відібрати в робочого хоста доступ до його дисків у цьому fabric.

В одному fabric це простій. У правильно побудованому подвійному fabric це втрата шляху, за умови, що інший fabric не змінили так само в той самий час. Багато операторів готують один скрипт і запускають його на обох switch один за одним. Це перетворює два незалежні fabric на одну спільну точку відмови: людину, яка тримає скрипт.

Проєктуйте зони так, щоб помилки були видимі

Single initiator zoning. Кожна зона містить один порт HBA хоста і порти масиву, які він має бачити. Хости ніколи не ділять зону, тому HBA, яка поводиться неправильно, не може потурбувати сусідів, а вилучення хоста означає вилучення його зон і більше нічого.

Aliases, а не сирі WWPN. Кожен порт отримує alias, і зони будуються з aliases.

Правило іменування, яке несе в собі fabric. Ставте літеру fabric у кожне ім’я alias і зони, щоб зона для Fabric A, вставлена у Fabric B, була очевидно неправильною для кожного, хто читає зміну. Тримайте імена у великих літерах, цифрах і підкресленнях. Деякі fabric відмовляються приймати дефіси та інші символи в іменах об’єктів, а імена чутливі до регістру, тож одна конвенція, що використовується всюди, усуває цілий клас помилок.

alias:  WEB01_HBA_A          -> <host port WWPN, fabric A>
alias:  ARRAY1_N0_P1_A       -> <array port WWPN, fabric A>
zone:   Z_WEB01_A__ARRAY1    -> WEB01_HBA_A; ARRAY1_N0_P1_A; ARRAY1_N1_P1_A
config: CFG_FABRIC_A

Перед початком: передпольотна перевірка

Збережіть поточний стан обох fabric, перш ніж щось змінювати:

cfgshow
cfgactvshow
zoneshow
alishow
nsshow
cfgtransshow

nsshow (name server) підтверджує, що порти нового хоста справді залогінилися у fabric, і показує WWPN такими, якими їх бачить switch, і саме з них треба будувати aliases, а не з наклейки на корпусі. cfgtransshow каже вам, чи хтось інший має відкриту транзакцію zoning у цьому fabric. Якщо вона відкрита і вона не ваша, зупиніться і з’ясуйте, чия вона.

На кожному наявному хості, якого зміна може торкнутися, запишіть кількість шляхів (multipath -ll), щоб потім довести, що для них нічого не змінилося.

Сама зміна, по одному fabric за раз

Починайте з того fabric, який вам менш шкода втратити. Зберіть усю зміну в одній сесії, як одну транзакцію:

alicreate "WEB01_HBA_B", "<host port WWPN, fabric B>"
zonecreate "Z_WEB01_B__ARRAY1", "WEB01_HBA_B; ARRAY1_N0_P2_B; ARRAY1_N1_P2_B"
cfgadd "CFG_FABRIC_B", "Z_WEB01_B__ARRAY1"
cfgenable "CFG_FABRIC_B"

cfgenable зберігає конфігурацію і робить її активною за один крок, і перед фіксацією просить підтвердження. Якщо ви це скриптуєте, скрипт має відповісти на цей запит, а потім прочитати у виводі повідомлення про фіксацію, а не вважати успіхом те, що команда повернулася. Ніщо не стає живим, доки enable не завершиться, і це ваш останній шанс ще раз прочитати підготовлену зміну через cfgshow.

Потім перевірте, з трьох місць:

1. Switch. cfgactvshow містить нову зону, і кожна зона, яка була там раніше, досі на місці.
2. Масив. Порт нового хоста в цьому fabric тепер показується як під’єднаний до очікуваних портів масиву.
3. Хости. Новий хост бачить свої томи через порт HBA цього fabric. Наявні хости показують точно ту кількість шляхів, яку ви записали на передпольотній перевірці.

На новому хості з Linux достатньо повторного сканування і погляду на HBA:

cat /sys/class/fc_host/host*/port_state
rescan-scsi-bus.sh
multipath -ll

Лише коли всі три сходяться, ви повторюєте ту саму зміну на іншому fabric, побудовану так само і перевірену так само. Якщо на першому fabric щось виглядає не так, ви зупиняєтеся там. Робоче навантаження досі працює на недоторканому fabric, і у вас є збережена конфігурація для відновлення.

Після зміни

Оновіть інвентар у тій самій сесії, щоб fabric і запис ніколи не розходилися.

Як це робимо ми

Наші fabric побудовані як два повністю незалежні fabric Brocade, від core switch до switch, вбудованих у наші блейд-шасі HPE. Партію нових серверів можна додати в зони по одному fabric за раз за лічені хвилини часу зміни fabric, тоді як зони, що несуть робоче навантаження, залишаються точно такими, якими були.

Якщо ваша наступна зміна storage передбачає торкнутися обох fabric, ми радо переглянемо план разом з вами, перш ніж він запуститься.

Поговоріть з інженером

Related (rows[1])

Пов’язане: Dual-fabric Fibre Channel SAN на Brocade · Enterprise SAN storage на HPE 3PAR, all-flash · Bare metal сервери на HPE і Dell