Rollback, який не треба пам’ятати: confirmed commits у мережі

Кожен мережевий інженер знає це відчуття: ви натискаєте enter на access list або на зміні маршрутизації, і сесія SSH перестає відповідати. Тепер питання в тому, чи встигне хтось дістатися до консолі, перш ніж це помітять клієнти. Краще питання інше: чому зміна взагалі змогла вас відрізати. Більшість серйозних мережевих платформ уміють скасувати зміну самостійно, якщо ви перестанете її підтверджувати. Ця стаття показує, як саме, платформа за платформою, і які звички роблять це надійним.

Принцип: зміна має заслужити свою постійність

Зміна має ставати постійною лише після того, як ви довели, з робочої сесії, що пристрій і далі доступний і поводиться правильно. Якщо ви так і не дійшли до підтвердження, бо зміна вас відрізала, пристрій має повернутися сам. Це перетворює найгірший випадок невдалої зміни з «їхати в дата-центр» на «зачекати кілька хвилин».

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

Juniper: commit confirmed

Junos має найчистішу модель. Зміни готуються в candidate configuration і застосовуються через commit. Confirmed commit відкочується сам, якщо ви не зробите commit ще раз:

commit confirmed 5
# verify reachability, routing, the thing you changed
commit

Якщо сесія обривається, маршрутизатор повертається до попередньої конфігурації через п’ять хвилин. show system commit і rollback <n> дають історію та швидке повернення вручну.

Cisco IOS-XR: також commit confirmed

IOS-XR дотримується тієї самої ідеї:

commit confirmed 300
# verify
commit

Використовуйте show configuration commit list, щоб побачити останні commits, і rollback configuration last 1, щоб свідомо зробити крок назад.

Cisco IOS-XE: revert timers

IOS-XE застосовує команди наживо, тож запобіжник треба звести заздалегідь. Його дає функція archive:

archive
 path bootflash:archive
 maximum 14
!
configure terminal revert timer 5
! make the change
configure confirm

Якщо ви не підтвердите протягом п’яти хвилин, пристрій повертається до конфігурації, яку мав на момент входу в configuration mode. Для заміни цілої конфігурації з файлу поєднайте replace з автоматичним відкатом у разі помилки замість того, щоб примусово його застосовувати:

configure replace bootflash:known-good.cfg revert trigger error timer 5

Повний replace з force пропускає запобіжні запити, тож залишайте його для відновлення snapshot, який створив той самий пристрій, а для всього іншого віддавайте перевагу merge або застосуванню секція за секцією.

Cisco NX-OS: checkpoints

NX-OS пропонує іменовані checkpoints і атомарний rollback:

checkpoint before-change-001
! make the change
show diff rollback-patch checkpoint before-change-001 running-config
rollback running-config checkpoint before-change-001 atomic

Вбудованого таймера підтвердження немає, тож на Nexus дисципліна важить більше: перевірте hostname перед першою командою, застосовуйте по одній команді за раз, перевіряйте результат і тримайте checkpoint разом із копією конфігурації поза пристроєм, доки зміна не доведе себе.

Firewall і Linux: зберіть таймер самі

Там, де платформа не має механізму підтвердження, зведіть його поза межами зміни. На хості Linux systemd може запланувати скасування ще до того, як ви торкнетеся чогось ризикованого:

systemd-run --on-active=240 --unit=net-safety /usr/local/sbin/restore-previous-network.sh
# make the change, then verify with a brand new SSH session
systemctl stop net-safety.timer

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

Snapshots і diffs: чи не зрушило щось інше?

Зміна може досягти того, що мала, і все одно зачепити щось інше. До і після кожного кроку більшого розгортання фіксуйте стан, який має значення (зведення сесій маршрутизації, стан інтерфейсів, overlay peers), і порівнюйте:

show bgp all summary > before.txt
# change
show bgp all summary > after.txt
diff before.txt after.txt

Якщо змінилося щось, що не мало змінитися, відкочуйте, поки причина ще очевидна. Автоматизуйте це, і зможете вимагати його на кожному пристрої розгортання, з автоматичним rollback, коли diff не чистий.

Звички, завдяки яким інструменти працюють

• Одна половина резервної пари за раз. Змініть standby, перевірте, потім active. Помилка тоді коштує резервування на кілька хвилин, а не сервісу.
• Перевіряйте з нової сесії. Наявна сесія SSH може пережити зміну, яка блокує нові. Відкрийте свіжу, перш ніж підтверджувати.
• Зберігайте останнім. Записуйте running configuration у startup лише після перевірки. До того перезавантаження теж є rollback.

Запитайте власну команду

• Які з ваших платформ підтримують confirmed commits або revert timers, і чи використовуються вони щоразу?
• Чи є копія конфігурації кожного пристрою поза пристроєм, зроблена до останньої зміни?
• Чи порівнюють розгортання стан маршрутизації до і після кожного кроку?
• Чи змінюється колись щось на обох членах резервної пари одночасно?

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

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

Related

• /what-we-do/network/change-discipline/
• /what-we-do/network/datacenter-fabric/
• /what-we-do/network/perimeter-firewalls/