TAF or not TAF
Поставили мы с коллегой 4-х узловой кластер 11g, Linux x32 (EL5) на вот таком железе HP Blade System c3000.
Настроили TAF и конечно же его попробовали.
На одном из узлов останавливаем instance с помощью shutdown abort - сессии немедленно переезжают на другие узлы.
Все замечательно ?
"Неет, сказали суровые сибирские мужики" (C)
И остановили публичный интерфейс (ifconfig eth0 down)
На этой ноде остановился listener, в течении ~30 сек VIP адрес переехал на другой узел.
БД и ASM остались без изменений, все как надо (если кто не знает, так работает начиная с 10.2.0.3)
А что-же TAF ? А ничего. Сессии намертво "залипают" и висят. Ждали 15 минут потом надоело.
Мы догадались, что сессии не перезжают потому, что получают никакой ошибки. В первом случае (с shutdown abort) ошибка приходит немедленно, а в этом - не приходит и все.
Metalink нашел массу багов, когда в такой ситуации даже VIP не перезжает. Но у нас с VIP все хорошо.
Отгадка была не очень сложной. Но, как-то не слишком известной что-ли.
Называется она tcp_keepalive.
Т.е. сессий oracle не получает ошибки потому, что по умолчанию нижележащий tcp/ip стек пытается восстановить соединение.
Решение пришло в виде добавления ENABLE=BROKEN в tnsnames - это обозначает доверять настройкам ОС - и изменению параметров tcp в Linux:
Добавил в /etc/sysctl.conf
# tcp tuning
net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=5
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_syn_retries=1
net.ipv4.tcp_retries2=3
и выполнил sysctl -p
Сесси стали получать ошибку в течении ~30 сек.
Прекрасные ссылки:
Как работает TAF и какие ошибки бывают на каких платформах
http://www.oracle.com/technology/tech/oci/pdf/taf_10.2.pdf
Кстати в описанной ситуации, клиент на MS Windows Server 2003 получает
ORA-12571: TNS:packet writer failure и достаточно быстро без доп. тюнинга
Как с подобной проблемой разобрались ребята из Церна:
https://twiki.cern.ch/twiki/bin/view/PSSGroup/OCIClientHangProtection
Они кстати приводят простой но очень правильный пример приложения на С c собственным таймером (!)
Окончательный вид конфигурации
TAF =
(DESCRIPTION =
(ENABLE = BROKEN)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(host = rac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(host = rac2-vip)(PORT = 1521))
(LOAD_BALANCE = yes)
(FAILOVER = true)
)
(CONNECT_DATA =
(failover_mode=
(type=session)
(method=basic)
(retries=2)
)
(SERVICE_NAME = racdb.ru.oracle.com)
)
)
PS
Кстати, если опустить интерфейс с интерконнектом, в течении 30 секунд узел идет в перезагрузку и это
правильное, документированное поведение.
Умиляет только, что же он перед перезагрузкой не попробует поднять интерфейс-то :)
Буду это изучать.
Здравствуйте Дмитрий! Мы тестируем поведение RAC кластера 12С, клиентом выступает SAP приложение. Мы столкнулись с абсолютно тем же поведением, что и вы в этом блоге, есть ли у вас какие нибудь новые советы по этому поводу ?
ОтветитьУдалитьСпасибо.
Сергей, я не понял вопроса. Чтобы преодолеть описанную проблему я поправил параметры OC и создал новый TNS. Вы все это попробовали и вам не помогает?
ОтветитьУдалитьДмитрий, спасибо за быстрый ответ, нет изменение параметров помогает так же как и у вас в данном примере, но как то не хотелось бы перекладывать данную задачу на уровень ядра+ в некоторых документах от Oracle есть такая информация:
ОтветитьУдалить"If you choose to use Net Services alone to provide failover, you may want to consider tuning the above parameters to reduce failover time. Unfortunately, this
will have possibly undesirable performance effects on network traffic and also may cause false failovers."
В итоге получилось настроить и без этого, в нашем случае клиент смотрел на IP машины , а не на VIP инстанции после того как проходил через SCAN и смотрел в листенер, получилось поправить изменением имени хоста для параметра local_listener для каждой из нод (сейчас они смотрят на VIP а не на Physical IP).
После поднятия VIP уже все отрабатывает вполне ожидаемо, коннекты переходят на следующую ноду.
Примерно как тут описано : http://oracleinaction.com/need-for-vip/
Тут уже мое сообщение в профильном форуме, где мне ответили, что должно обрываться и без tcp таймаутов - http://scn.sap.com/thread/3809618
Я просто хотел бы услышать ваши соображения по вашему блогу , может что нибудь изменилось с 2007 года :)
Спасибо.