Здесь немного гибридных систем, так что несите меня. По сути, у меня возникают проблемы с использованием агента Backup Exec для Oracle при попытке резервного копирования удаленного сервера Linux. Агент BE использует RMAN для резервного копирования баз данных.
Сервер резервного копирования находится в одной VLAN, а целевой сервер - в другой, а брандмауэр Cisco ASA обеспечивает единственную связь между ними. Это сделано намеренно, поскольку сервер резервного копирования должен поддерживать множество клиентов, и каждый клиент должен находиться в своей собственной VLAN, чтобы предотвратить доступ друг к другу. Я добавил рекомендуемые порты к брандмауэру, чтобы, по крайней мере, позволить агенту общаться с медиа-сервером.
Резервное копирование запускается достаточно хорошо (действительно, база данных Oracle меньшего размера на том же сервере завершается без проблем), но база данных объемом 200 ГБ, которая явно займет несколько часов, не может быть завершена.
Я считаю, что проблема связана с http://www.symantec.com/business/support/index?page=content&id=TECH59632, в котором говорится, что сеанс CORBA устанавливается на порту 5633 в начале резервного копирования и используется перед каждой операцией RMAN, но, пока данные передаются, сокет сеанса CORBA не получает пакетов. Поскольку тайм-аут соединения на брандмауэре составляет 60 минут, сеанс CORBA прерывается, и, когда агент RMAN пытается выполнить свое следующее действие, весь процесс взрывается. Symantec заявляет, что эта проблема была исправлена в более ранней версии Backup Exec, но не описывает никаких дополнительных настроек для ее принудительного применения.
Установка тайм-аута соединения на брандмауэре на что-то достаточно большое, чтобы покрыть окно резервного копирования (например, 12 часов), кажется неправильным, поскольку это изменение для всего хозяйства, которое также повлияет на время жизни соединения (например, ) веб-запросы к веб-серверу другого клиента.
О переносе сервера Linux в ту же локальную сеть, что и сервер резервного копирования, не может быть и речи.
Я не гуру Linux, но примерно знаю свой путь. Пока что я пробовал начать использовать libkeepalive (http://libkeepalive.sourceforge.net/), чтобы принудительно создать сокет удаленного процесса с флагом KEEPALIVE TCP, но быстро netstat -top указывает, что не принимает. Либо я неправильно использую libkeepalive, либо он не работает для двоичного файла beremote
Думаю, я ищу вариант, который подходит к окружающей среде, в которой я нахожусь. Я полагаю, что ищу одно или несколько из следующего:
Любые / все (другие) идеи приветствуются ...
Дж.
Как просили, class-map, policy-map и service-map записи ...
class-map CLS_INSPECTION_TRAFFIC
match default-inspection-traffic
class-map CLS_ALL_TRAFFIC
match any
class-map CLS_BACKUPEXEC_CORBA
description Oracle/DB2 CORBA port for BackupExec traffic
match port tcp eq 5633
!
!
policy-map type inspect dns PMAP_DNS_INSPECT_SETTINGS
parameters
message-length maximum client auto
message-length maximum 1280
policy-map PMAP_GLOBAL_SERVICE
class CLS_INSPECTION_TRAFFIC
inspect dns PMAP_DNS_INSPECT_SETTINGS
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ipsec-pass-thru
inspect icmp
inspect snmp
class CLS_BACKUPEXEC_CORBA
set connection timeout idle 1:00:00 dcd
class CLS_ALL_TRAFFIC
set connection decrement-ttl
!
Справочная информация о тайм-ауте / таймерах ASA:
Глобальный тайм-аут соединение - это таймер простоя виртуального канала (сеанса) TCP, значение по умолчанию - 60 минут. Глобальный таймаут UDP предназначен для дырок UDP и по умолчанию составляет 2 минуты. Глобальный тайм-аут xlate для очистки переводов, которые задерживаются после истекло время ожидания соединения. Таймаут conn (TCP) имеет приоритет над таймаутом xlate. В следующем абзаце объясняется взаимосвязь между таймерами conn и xlate.
Если соединение успешно разорвано через TCP teardown, conn и xlate идут вместе с ним (если динамический xlate, статический NAT и статический PAT xlate никогда не удаляются). Если время соединения истекает, то учитывается таймер xlate. Если время ожидания xlate истекает первым (вы устанавливаете его очень низким), он будет не отключите соединение, пока не истечет время ожидания соединения.
У ASA есть несколько методов работы с различными таймаутами. Conn - это параметр, в котором глобальный параметр может быть переопределен на основе карты классов - это должно быть предпочтительнее увеличения глобального параметра, если это возможно.
Другой интересной особенностью ASA является обнаружение мертвого соединения - DCD. DCD позволяет поддерживать [глобальный] тайм-аут подключения на уровне 60 минут (по умолчанию), а когда 60 минут достигнут - «человек посередине» ASA подменяет ACK нулевых данных каждой конечной точке как другой конечной точке. Нулевые данные препятствуют увеличению порядковых номеров. Если обе стороны ответят, таймер простоя соединения сбрасывается на 0 и запускается снова. Если какая-либо из сторон не отвечает после заданного количества попыток (настраиваемых) в заданный период, соединение удаляется, и таймер xlate становится актуальным, как описано выше.
Я бы рекомендовал настроить карту классов и добавить ее в вашу политику, которая включает DCD. Вы можете использовать ACL или порт (доступны и другие). Использование порта выполняется быстро, легко и будет хорошо работать, если вы уверены, что проблема в TCP / 5633.
Я использовал global_policy ниже, но не стесняйтесь изменять его по мере необходимости.
class-map BE-CORBA_class
description Backup Exec CORBA Traffic Class
match port tcp eq 5633
policy-map global_policy
class BE-CORBA_class
-->::Choose one below::<--
set connection timeout idle 1:00:00 dcd --> for 8.2(2) and up
set connection timeout tcp 1:00:00 dcd --> for prior to 8.2(2)
service-policy global_policy global
@Комментарий
Согласно справочнику - "Пакет может соответствовать только одной карте классов в карте политик. для каждого типа функции. "
Ключевая фраза выделена жирным шрифтом. Пакет, пересекающий интерфейс, может соответствовать нескольким классам внутри карты политик, но только если эти классы используют разные «функции». Если вы прокрутите чуть-чуть вверх по вышеупомянутой ссылке, вы увидите различные перечисленные функции. Вся эта страница - золотая жила для лакомых кусочков MPF.
Как вы упомянули, у вас есть match any карта классов определена, а затем указана как класс внутри карты политик - если вы выполняете какие-либо другие ограничения и тайм-ауты соединений TCP и UDP в этом классе карты политик, то последующие карты классов, которые соответствуют трафику - если установлен в policy-map - не будет выполнять ограничения TCP и UDP соединений и изменения тайм-аута для этого пакета.
Если вы разместите все ACL, class-maps, policy-maps, и service-policyэто мы можем определить наверняка.
Хотя я не фанат приложений, которые берут свои игрушки и возвращаются домой (и не выполняют резервное копирование), когда один единственный сеанс TCP прерывается, в этом случае я бы сказал, что просто увеличьте время ожидания сеанса TCP ASA.
Установка жесткого ограничения на длину сеанса на самом деле является просто продуктом потребности ASA отслеживать все соединения для поддержания состояния (и обычно NAT) - если вы работаете с ограничением подключения вашего устройства, это может быть проблемой, но в противном случае просто проверните его до 6 часов или около того.
Если оба узла на концах TCP-сеанса не отключатся, ASA будет свидетельствовать об окончании соединения на одном или другом конце, когда оно завершится естественным образом, и затем разорвет соединение (или вызовет более короткий тайм-аут полузакрытого соединения), так что вы вряд ли в конечном итоге получите кучу мертвых соединений, засоряющих вещи. Конечные устройства также заинтересованы в разрыве бесполезных соединений - хороший пример - веб-серверы, поскольку они обычно имеют гораздо более короткие тайм-ауты соединения, чем ваш ASA.
Вы можете рассмотреть возможность использования общего TCP-прокси на удаленном компьютере Linux, который отвечает и перенаправляет соединения от Backup Exec на локальный порт CORBA. (Вы можете легко настроить подключение сервера Backup Exec к этому прокси-серверу с помощью правил NAT на вашем брандмауэре.) Для этого TCP-прокси потребуется установить параметр SO_KEEPALIVE для создаваемого прослушивающего сокета. Мой доверенное лицо Rinetd, но беглый взгляд на исходный код показывает, что они не устанавливают опцию SO_KEEPALIVE для своего слушающего сокета (так что вам придется изменить его, чтобы получить желаемое поведение). Возможно, существует еще один общий TCP-прокси, который устанавливает SO_KEEPALIVE по умолчанию (или в качестве опции), но я не знаю ни о каком из них.
Другой вариант - запустить SSH-туннель к удаленному компьютеру как часть сценария перед выполнением задания с SSH-клиентом, настроенным на использование либо SO_KEEPALIVE, либо нулевых пакетов SSH для поддержания соединения.