PowerFlex 3.5: Відключення однорангового зв'язку при використанні реплікації
Summary: Після налаштування реплікації PowerFlex статус системи peer називається «Decoupled» з повідомленням про помилку «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.
Зверніть увагу, що на одноранговому MDM є чотири вихідні з'єднання з портом 7611, але немає вхідних з'єднань з 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
Є з'єднання, що надходять від SiteA (192.168.89.14), а номери портів джерела відповідають виходу "netstat" на SiteA, але вихідні з'єднання перебувають у SYN_SENT стані, що означає, що вони не можуть завершити TCP-потискання з SiteA і фактично не можуть встановити MDM-піринг.
Вплив
Реплікація не працює Залежно від корінної причини, вона може взагалі не працювати або лише тоді, коли певний вузол стає Master MDM з одного з боків.
Cause
Ця проблема виникає або через неправильну конфігурацію IP-адреси MDM, або через проблеми з мережею між сайтами. Наприклад, якщо SiteA налаштований з правильними IP-адресами, але SiteB налаштований на IP-адреси, які не належать MDM SiteA, ця проблема може виникнути.
Якщо між сайтами виникають проблеми з мережевим з'єднанням (фаєрвол, маршрутизація тощо), клієнт також може зіткнутися з подібною проблемою. Ще одна причина — дубльовані 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-адреси peer MDM. Тестуйте з'єднання між сайтами на порту TCP/7611. Переключіть володіння Master MDM на різні вузли кластера та/або перезапустіть MDM-сервіс, щоб закрити старі сокети.
Впливові версії
PowerFlex 3.5 і вище
Виправлено у версії
N/A — це не проблема PowerFlex