Вікна обслуговування: що натомість робиться під навантаженням

Два види планових робіт

Планові роботи діляться на дві групи. Першу поглинає дизайн: контролер сховища отримує нове firmware, замінюється leaf-комутатор, хост гіпервізора виводиться заради пам’яті, пара firewall накочує оновлення. Друга змінює щось, що в той момент не має партнера: cutover платформи, фінальна синхронізація міграції сховища, незворотна зміна схеми. Перша група робиться під навантаженням. Друга отримує вікно, і вікно проєктується, а не просто оголошується.

Що поглинає дизайн

Масив HPE 3PAR несе два вузли-контролери, які обслуговують ті самі томи, і кожен хост під’єднаний через дві незалежні fabric Brocade. Firmware ставиться на один вузол за раз; поки він перезапускається, рівень multipath хостів тримає I/O у русі шляхами, що лишилися, і вузол повертається до того, як торкнуться другого. Та сама схема застосовується на кожному рівні, побудованому парами. Leaf-комутатори Cisco Nexus 9000 розгорнуті парами, кожен хост з bond через обидва, тож комутатор може прийняти оновлення або заміну, поки інша лінія несе трафік. Хости гіпервізора спорожнюються через live migration до того, як із ними щось роблять, і віртуальні машини повертаються після. Edge routers тримають сесії з більш ніж одним оператором, і сесія виводиться до того, як торкнуться її router.

Ніщо з цього не є незвичним у серйозному дата-центрі. Що має значення, це чи вправляються пари. Партнер, який існує на схемі, але не ніс production, є припущенням, і момент виявити, що це було припущення, не є моментом зміни.

Перевірте партнера, перш ніж торкатися основного

Корисна дисципліна є перевіркою, що відбувається до зміни. Перш ніж вивести контролер, кожен під’єднаний хост питають, скільки активних шляхів до масиву він тримає; хост, який повідомляє про один шлях, спершу виправляють, бо для цього хоста вікно інакше прийшло б непроханим. Перш ніж торкнутися комутатора, читають bond на кожному хості, щоб підтвердити, що обидва учасники up і передають трафік, і підтверджують, що другий комутатор пересилає, а не просто живиться. Перш ніж спорожнити хост, підтверджують, що ціль міграції має запас для того, що на неї йде.

# on each attached host, before controller work: every LUN should show two or more active paths
$ multipath -ll | grep -c 'active ready'

# before switch work: both bond members up and passing traffic
$ grep -E 'Slave Interface|MII Status' /proc/net/bonding/bond0

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

Зміни, які заслуговують на вікно

Вікно є правильною відповіддю, коли крок незворотний, коли компонент за своєю природою в той момент не має партнера, або коли процедура вендора вимагає зупинки сервісу. Cutover платформи є поширеним випадком: у момент, коли трафік переходить зі старого середовища на нове, є проміжок, зазвичай обмежений поширенням DNS або переїздом VIP, у якому сервіс перебуває в дорозі.

Добре спроєктоване вікно впізнаване. Воно називає компонент і механізм, тож ви знаєте, що змінюється і чому це не можна зробити під навантаженням. Воно зазначає очікуваний видимий для клієнта вплив окремо від тривалості операції; двогодинна операція може мати видимий вплив у хвилини, і повідомлення каже, що є що. Воно має точку рішення і rollback, який відрепетирували, а не описали. Воно погоджене з вами: якщо зміна може торкнутися вашого трафіку, ми спершу погоджуємо з вами час. І воно завершується звітом, який порівнює фактичне з оголошеним.

Як читати повідомлення про обслуговування

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