PowerFlex 3.5. Отключение однорангового узла при использовании репликации
Summary: После настройки репликации PowerFlex одноранговая система переходит в состояние «Отсоединено» с сообщением об ошибке «REMOTE_PEER_MDM_DENIED_MESSAGE_AS_NO_WORKING_CLIENT_CONNECTION_TO_THIS_PEER». ...
Symptoms
Эта проблема может возникнуть сразу после настройки репликации PowerFlex, но также может наблюдаться после некоторых изменений сети или при смене главного MDM с любой стороны на определенный узел.
scli --query_replication_peer_system на одной стороне (SiteA) возвращает:
query-all-Replication Peer System returned 1 Replication Peer System nodes. Replication Peer System ID: 045a1aa61167b20f Replication Peer System internal ID: eef8648500000000 Name: SiteB State: Decoupled, REMOTE_PEER_MDM_DENIED_MESSAGE_AS_NO_WORKING_CLIENT_CONNECTION_TO_THIS_PEER IP: 192.168.89.14,192.168.89.13,192.168.89.18 Port: 7611 Version: N/A SDR-SDR connectivity status: All connected
Вывод команды "netstat" выглядит следующим образом:
tcp 0 0 192.168.86.19:50470 192.168.89.14:7611 ESTABLISHED 36766/mdm-3.5.1100. tcp 0 0 192.168.86.19:50464 192.168.89.14:7611 ESTABLISHED 36766/mdm-3.5.1100. tcp 0 0 192.168.86.19:50216 192.168.89.14:7611 ESTABLISHED 36766/mdm-3.5.1100. tcp 0 0 192.168.86.19:50458 192.168.89.14:7611 ESTABLISHED 36766/mdm-3.5.1100.
Обратите внимание, что имеется четыре исходящих подключения к порту 7611 на одноранговом MDM, но нет входящих подключений с сайта SiteB к порту 7611 на локальном хосте.
Другая сторона (SiteB) отображается как Decoupled, NOT_CONN, например:
Query-all-Replication Peer System returned 1 Replication Peer System nodes. Replication Peer System ID: 0966250f2fae770f Replication Peer System internal ID: c0f3862b00000000 Name: SiteA State: Decoupled, NOT_CONN IP: 192.168.86.20,192.168.86.13,192.168.86.19 Port: 7611 Version: 3.5.1100 SDR-SDR connectivity status: All connected
Вывод команды «netstat» на этой стороне может выглядеть следующим образом:
B -> A tcp 0 157 192.168.89.14:7611 192.168.86.19:50470 ESTABLISHED 446371/mdm-3.5.1100 tcp 0 0 192.168.89.14:7611 192.168.86.19:50216 ESTABLISHED 446371/mdm-3.5.1100 tcp 0 0 192.168.89.14:7611 192.168.86.19:50464 ESTABLISHED 446371/mdm-3.5.1100 tcp 0 0 192.168.89.14:7611 192.168.86.19:50458 ESTABLISHED 446371/mdm-3.5.1100 tcp 0 0 192.168.89.14:54460 192.168.86.19:7611 SYN_SENT 446371/mdm-3.5.1100 tcp 0 0 192.168.89.14:54456 192.168.86.19:7611 SYN_SENT 446371/mdm-3.5.1100 tcp 0 0 192.168.89.14:54458 192.168.86.19:7611 SYN_SENT 446371/mdm-3.5.1100 tcp 0 0 192.168.89.14:54454 192.168.86.19:7611 SYN_SENT 446371/mdm-3.5.1100
Есть соединения, поступающие с площадки A (192.168.89.14), и номера портов источника совпадают с выходными данными «netstat» на сайте A, но исходящие соединения находятся в состоянии SYN_SENT, что означает, что они не могут завершить подтверждение TCP с сайтом A и, по сути, не могут установить пиринг MDM.
Удар
Репликация не работает В зависимости от основной причины она может не работать вообще или работать только тогда, когда определенный узел становится главным MDM на одной из сторон.
Cause
Эта проблема вызвана либо неправильной настройкой IP-адреса MDM, либо проблемами сети между площадками. Например, если для сайта SiteA настроены правильные IP-адреса, а для сайта SiteB были настроены IP-адреса, которые не принадлежат MDM сайта A, эта проблема может возникнуть.
При наличии проблем с сетевым подключением (межсетевым экраном, маршрутизацией и т. д.) между площадками заказчик также может столкнуться с аналогичной проблемой. Другая причина — дублирование IP-адресов на обеих сторонах (то есть есть два MDM, работающих с одним и тем же IP-адресом) или какое-то сетевое устройство, перехватывающее исходящие TCP-сессии (прокси).
В этом конкретном случае MDM SiteB держал TCP-сокеты открытыми напротив одного из MDM на SiteA, но не был подключен к этому MDM, а скорее соединение искусственно поддерживалось одним из маршрутизаторов на пути между сайтами:
Вот как выглядел вывод netstat на обоих сайтах:
A -> B tcp 0 0 192.168.86.19:50470 192.168.89.14:7611 ESTABLISHED 36766/mdm-3.5.1100. tcp 0 0 192.168.86.19:50464 192.168.89.14:7611 ESTABLISHED 36766/mdm-3.5.1100. tcp 0 0 192.168.86.19:50216 192.168.89.14:7611 ESTABLISHED 36766/mdm-3.5.1100. tcp 0 0 192.168.86.19:50458 192.168.89.14:7611 ESTABLISHED 36766/mdm-3.5.1100. B -> A tcp 0 0 192.168.89.14:54460 192.168.86.19:7611 ESTABLISHED 446371/mdm-3.5.1100 tcp 0 0 192.168.89.14:54456 192.168.86.19:7611 ESTABLISHED 446371/mdm-3.5.1100 tcp 0 0 192.168.89.14:54458 192.168.86.19:7611 ESTABLISHED 446371/mdm-3.5.1100 tcp 0 0 192.168.89.14:54454 192.168.86.19:7611 ESTABLISHED 446371/mdm-3.5.1100 tcp6 0 157 192.168.89.14:7611 192.168.86.19:50470 ESTABLISHED 446371/mdm-3.5.1100 tcp6 0 0 192.168.89.14:7611 192.168.86.19:50216 ESTABLISHED 446371/mdm-3.5.1100 tcp6 0 0 192.168.89.14:7611 192.168.86.19:50464 ESTABLISHED 446371/mdm-3.5.1100 tcp6 0 0 192.168.89.14:7611 192.168.86.19:50458 ESTABLISHED 446371/mdm-3.5.1100
Заметьте, что SiteB (192.168.89.14) показывает четыре УСТАНОВЛЕННЫХ соединения с IP-адресом SiteA (192.168.86.19) на порту 7611, но мы не видим того же в выводе "netstat" на SiteA - какой-то сетевой прокси-сервер поддерживал эти TCP-сессии.
Resolution
Исправьте конфигурацию IP-адреса однорангового MDM. Проверьте возможность подключения между площадками через порт TCP/7611. Переключите владение главным модулем MDM на другие узлы в кластере и/или перезапустите службу MDM, чтобы закрыть старые разъемы.
Затронутые версии
PowerFlex 3.5 и более поздние версии
Исправлено в версии
Н/Д — не проблема PowerFlex