Ранее тут и тут я уже рассказывал про файловеры и их настройку. Теперь перейдем к различным тонкостям, нюансам и проблемам.
Возникла необходимость создать такую систему на базе Active\Standby файловерной пары, в которой активной всегда должен быть первичный юнит (primary failover unit), а вторичный (secondary failover unit) всегда должен быть резервным, кроме случаев, когда первичный юнит имеет какие-либо проблемы. Для решения поставленной задачи было перерыто множество форумов и сайтов, прочитано куча документации. Собранную информацию можно резюмировать следующим образом:
- Cisco не имеет встроенного функционала типа приоритета или аналогов preempt (к сожалению не могу найти аналогию данного термина с чем-нибудь из русского языка, а перевод не приводит ни к чему хорошему) для системы Active\Stanby (далее A\S);
- IP SLA тоже работать не будет из-за особенности топологии;
- Было высказано мнение использовать какие-либо скрипты. TCL не поддерживается ASA, только EEM;
- При этом EEM, имеющий очень хороший функционал на IOS вплоть до написания полноценного скрипта с условиями и прочими интересными вещами из области элементарного программирования, на ASA представлен очень урезанной версией, имеющий в качестве условия срабатывания либо ID сислог-сообщения и количество их повторений, либо некую временную характеристику, которая больше похожа на планировщик задачи.
Имея все вышеперечисленные условия на руках, можно пробовать составить простейший EEM-скрипт, выполняющий автоматический возврат на первичное устройство статуса Active после восстановления его работоспособности.
Для начала необходимо было выбрать триггер, который будет запускать скрипт. Естественно, что это должно быть некоторое сообщение, которое позволило бы однозначно утверждать, что ранее проблемный юнит в данный момент полностью работоспособен. После наблюдения за поведением файловерного кластера было найдено такое сообщение:
Error Message %ASA-1-104004: (Primary) Switching to OK.
ID этого сообщения 104004. Расшифровать сообщение можно так (взято из описания сислог-сообщений для ASA): A previously failed unit reports that it is operating again. Primary can also be listed as Secondary for the secondary unit.
Отлично. На основании этого был написан скрипт:
!
event manager applet BackToActive //создаем апплет с именем BackToActive
event syslog id 104004 //указываем сообщение 104004 в качестве условия срабатывания
action 0 cli command "failover active" //в качестве действия указываем команду failover active
output none //строка, указывающая, что скрипт не должен выдавать никакой информации
!
Теперь наш файловер будет работать так:
1) В начальный момент времени ASA-primary - Active, ASA-secondary - Standby.
2) Произошли какие-либо проблемы с первичной ASA - в результате переключения вторичная стала активной, первичная - резервной с индикацией Failed в выводе комaнды show failover.
3) Проблемы устранены, но по правилам файловера первичная ASA изменила состояние с Failed на Ready, но осталась резервной. При этом в момент изменения состояния генерируется сообщение 104004.
4) Так как нужное сообщение сгенерировано, происходит срабатывание скрипта. При этом данное сообщение генерируется только на том узле, состояние которого поменялось, т.е. в нашем случае на первичной ASA.
Все бы было замечательно, если бы не одно "но" - буферы сислога у каждой ASA в файловере собственные, а скрипт работает на обеих ASA. В итоге получаем следующую ловушку (по шагам):
1) Начальные условия - как в предыдущем случае, описанном выше.
2) Произошла ошибка на резервной устройстве - переключения не произошло в соответствии с документацией.
3) Проблемы устранены.
4) Но состояние-то на резервной ASA тоже поменялось по принципу, описанному ранее. В результате появляется наше триггерное сообщение, которое ведет к срабатыванию скрипта, и ASA-secondary переходит в режим Active.
Для решения этой проблемы был создан "костыль", который будет требовать к себе внимания и лишает нашу систему самостоятельности. Суть решения в следующем: необходимо на secondary, находящейся в режиме Standby отключить журналирование данного сообщения:
!
no logging message 104004
!
Минусы такого решения очевидны. Введенная команда будет находится только в running-config вторичной ASA, и любое действие, приводящее к синхронизации конфига (перезагрузка или команда write standby, выполненная на первичной ASA в режиме Active) удалит эту команду. Другая проблема - если вдруг вторичная ASA станет активной, а после этого произойдет синхронизация с ней первичного устройства - данная команда наоборот перейдет в конфигурацию первичной ASA.
Тем не менее, зная об этих минусах, можно полуавтоматизировать имеющееся решение, при этом добавив в чек-лист оборудования проверку наличия в нужном месте данного пункта и отсутствие его в противоположном месте.
FOR ENGLISH SPEAKING: If you are interesting in this article and need any comments to understand it, tell me please in comments or through email.
Возникла необходимость создать такую систему на базе Active\Standby файловерной пары, в которой активной всегда должен быть первичный юнит (primary failover unit), а вторичный (secondary failover unit) всегда должен быть резервным, кроме случаев, когда первичный юнит имеет какие-либо проблемы. Для решения поставленной задачи было перерыто множество форумов и сайтов, прочитано куча документации. Собранную информацию можно резюмировать следующим образом:
- Cisco не имеет встроенного функционала типа приоритета или аналогов preempt (к сожалению не могу найти аналогию данного термина с чем-нибудь из русского языка, а перевод не приводит ни к чему хорошему) для системы Active\Stanby (далее A\S);
- IP SLA тоже работать не будет из-за особенности топологии;
- Было высказано мнение использовать какие-либо скрипты. TCL не поддерживается ASA, только EEM;
- При этом EEM, имеющий очень хороший функционал на IOS вплоть до написания полноценного скрипта с условиями и прочими интересными вещами из области элементарного программирования, на ASA представлен очень урезанной версией, имеющий в качестве условия срабатывания либо ID сислог-сообщения и количество их повторений, либо некую временную характеристику, которая больше похожа на планировщик задачи.
Имея все вышеперечисленные условия на руках, можно пробовать составить простейший EEM-скрипт, выполняющий автоматический возврат на первичное устройство статуса Active после восстановления его работоспособности.
Для начала необходимо было выбрать триггер, который будет запускать скрипт. Естественно, что это должно быть некоторое сообщение, которое позволило бы однозначно утверждать, что ранее проблемный юнит в данный момент полностью работоспособен. После наблюдения за поведением файловерного кластера было найдено такое сообщение:
Error Message %ASA-1-104004: (Primary) Switching to OK.
ID этого сообщения 104004. Расшифровать сообщение можно так (взято из описания сислог-сообщений для ASA): A previously failed unit reports that it is operating again. Primary can also be listed as Secondary for the secondary unit.
Отлично. На основании этого был написан скрипт:
!
event manager applet BackToActive //создаем апплет с именем BackToActive
event syslog id 104004 //указываем сообщение 104004 в качестве условия срабатывания
action 0 cli command "failover active" //в качестве действия указываем команду failover active
output none //строка, указывающая, что скрипт не должен выдавать никакой информации
!
Теперь наш файловер будет работать так:
1) В начальный момент времени ASA-primary - Active, ASA-secondary - Standby.
2) Произошли какие-либо проблемы с первичной ASA - в результате переключения вторичная стала активной, первичная - резервной с индикацией Failed в выводе комaнды show failover.
3) Проблемы устранены, но по правилам файловера первичная ASA изменила состояние с Failed на Ready, но осталась резервной. При этом в момент изменения состояния генерируется сообщение 104004.
4) Так как нужное сообщение сгенерировано, происходит срабатывание скрипта. При этом данное сообщение генерируется только на том узле, состояние которого поменялось, т.е. в нашем случае на первичной ASA.
Все бы было замечательно, если бы не одно "но" - буферы сислога у каждой ASA в файловере собственные, а скрипт работает на обеих ASA. В итоге получаем следующую ловушку (по шагам):
1) Начальные условия - как в предыдущем случае, описанном выше.
2) Произошла ошибка на резервной устройстве - переключения не произошло в соответствии с документацией.
3) Проблемы устранены.
4) Но состояние-то на резервной ASA тоже поменялось по принципу, описанному ранее. В результате появляется наше триггерное сообщение, которое ведет к срабатыванию скрипта, и ASA-secondary переходит в режим Active.
Для решения этой проблемы был создан "костыль", который будет требовать к себе внимания и лишает нашу систему самостоятельности. Суть решения в следующем: необходимо на secondary, находящейся в режиме Standby отключить журналирование данного сообщения:
!
no logging message 104004
!
Минусы такого решения очевидны. Введенная команда будет находится только в running-config вторичной ASA, и любое действие, приводящее к синхронизации конфига (перезагрузка или команда write standby, выполненная на первичной ASA в режиме Active) удалит эту команду. Другая проблема - если вдруг вторичная ASA станет активной, а после этого произойдет синхронизация с ней первичного устройства - данная команда наоборот перейдет в конфигурацию первичной ASA.
Тем не менее, зная об этих минусах, можно полуавтоматизировать имеющееся решение, при этом добавив в чек-лист оборудования проверку наличия в нужном месте данного пункта и отсутствие его в противоположном месте.
FOR ENGLISH SPEAKING: If you are interesting in this article and need any comments to understand it, tell me please in comments or through email.
Комментариев нет:
Отправить комментарий