Технологія PowerFlex: Мережеві адаптери SVM можуть бути неправильно призначені під час перетворення SVM
Summary: Під час процесу перетворення SVM мережеві адаптери SVM можуть призначатися неправильно.
Symptoms
Користувач не може оновити або конвертувати основний MDM (останній MDM) під час перетворення SVM, оскільки підмережі не можуть обмінюватися даними.
Сценарій
Мережеві адаптери було неправильно впорядковано після перетворення SVM:
Можливі два варіанти розвитку подій:
Сценарій #1 - Первинні мережеві мережі даних комутовані в різних підмережах (без можливості маршрутизації):
При погляді на query_cluster вихідні дані ми можемо побачити, що IP-адреси первинного MDM розташовані в порядку, протилежному вторинним:
Primary MDM:
Name: Secondary_MDM2, ID: 0x6a3e3168772f4322
IP Addresses: 10.128.8.62, 10.128.0.62, Management IP Addresses: 10.63.193.162, Port: 9011, Virtual IP interfaces: eth1, eth2
Secondary MDMs:
Name: Secondary_MDM1, ID: 0x3faea7c32806b951
IP Addresses: 10.128.0.61, 10.128.8.61, Management IP Addresses: 10.63.193.161, Port: 9011, Virtual IP interfaces: eth1, eth2
Name: Primary_MDM, ID: 0x02d885dd7c5fc180
IP Addresses: 10.128.0.60, 10.128.8.60, Management IP Addresses: 10.63.193.160, Port: 9011, Virtual IP interfaces: eth1, eth2
Вихідні дані інтерфейсу MDM, які можуть відрізнятися залежно від операційної системи (ОС), показують, що eth1 знаходиться в підмережі 10.128.0.x, а eth2 — у підмережі 10.128.8.x, у тому самому порядку, що й вторинні компоненти:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.63.193.162 netmask 255.255.255.128 broadcast 10.63.193.255
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet 10.128.0.62 netmask 255.255.248.0 broadcast 10.128.7.255
eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet 10.128.8.62 netmask 255.255.248.0 broadcast 10.128.15.255
Сценарій #2 - Первинні IP-адреси MGMT і DATA з комутацією NIC:
Вихід основного інтерфейсу MDM, який може відрізнятися залежно від ОС, показує, що eth0 містить IP-адресу MGMT, а eth[1|2] — IP-адреси DATA1 і DATA2:
eth0 Link encap:Ethernet HWaddr 00:50:56:91:97:CD
inet addr:10.202.5.13 Bcast:10.202.5.255 Mask:255.255.255.0
eth1 Link encap:Ethernet HWaddr 00:50:56:91:3A:FB
inet addr:192.168.152.28 Bcast:192.168.159.255 Mask:255.255.248.0
eth2 Link encap:Ethernet HWaddr 00:50:56:91:4E:57
inet addr:192.168.160.28 Bcast:192.168.167.255 Mask:255.255.248.0
Вихідні дані вторинних інтерфейсів MDM, які можуть відрізнятися залежно від ОС, показують, що eth0 містить IP-адресу DATA1 , а eth[1|2] — IP-адреси DATA2 та MGMT:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet 192.168.152.27 netmask 255.255.248.0 broadcast 192.168.159.255
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet 192.168.160.27 netmask 255.255.248.0 broadcast 192.168.167.255
eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.202.5.12 netmask 255.255.255.0 broadcast 10.202.5.255
При погляді на query_cluster output, кожен вузол очікує використовувати eth1 та eth2 для VIP-персон:
Master MDM:
Name: agent-svm-de1801vmwesx002, ID: 0x52cd360827eb8e63
IPs: 192.168.152.28, 192.168.160.28, Management IPs: 10.202.5.13, Port: 9011, Virtual IP interfaces: eth1, eth2
Version: 2.6.11000
Slave MDMs:
Name: agent-svm-de1801vmwesx001, ID: 0x361d56fd178799e0
IPs: 192.168.160.27, 192.168.152.27, Management IPs: 10.202.5.12, Port: 9011, Virtual IP interfaces: eth1, eth2
Status: Normal, Version: 2.6.11000
Вплив
Оскільки підмережі не можуть обмінюватися даними, якщо виникає паніка або збій, це може призвести до DU.
Cause
Ця проблема може виникнути, якщо шаблон змінено перед запуском процедури оновлення/перетворення.
Resolution
Визначте правильне вирівнювання та змініть мережеві адаптери, щоб вони відповідали йому. За замовчуванням PowerFlex зазвичай використовує:
ETH0=sio_mgmt ETH1=sio_data1 ETH2=sio_datat2
Кроки для змін eth[0|1|2]:
- Переведіть кластер в єдиний режим (ми повинні видалити і знову додати з правильним порядком IP)
- Відредагуйте сценарії /etc/sysconfig/network-scripts/ifcfg-eth* у вторинному MDM, щоб вони відповідали поточному порядку первинного MDM (MGMT для eth0, DATA1 для eth1, DATA2 для eth2)
- Переведіть SDS, який знаходиться на поточному вторинному MDM, у режим обслуговування (MM), оскільки ми змінюємо IP-адреси з перезавантаженням
- Перезавантажте SVM, який було поміщено в MM
- Після повторного підключення до цього вузла переконайтеся, що IP-адреси розташовані в тому ж порядку, що й поточний основний MDM, як зазначено в кроці #2
- Переконайтеся, що SDS знову підключено, а потім вийдіть з MM
- Видаліть додатковий MDM, який ми щойно перезавантажили з кластера MDM
- Повторно додайте в режим очікування MDM, переконавшись, що порядок IP-адрес у полі «new_mdm_ip» збігається з поточним основним (DATA1, DATA2)
- Поверніться до 3-вузлового/5-вузлового режиму
- Переконайтеся, що кластер справний і синхронізований
- Зміна власника MDM
- Після успішного переходу права власності на MDM перейдіть до останнього вузла, що залишився, для оновлення/перетворення SVM
Версії, на які вплинули
VxFlex OS 3.0.x
Виправлено у версії
VxFlex OS 3.0.1.5
PowerFlex 3.5.1.3
PowerFlex 3.6.0.327
PowerFlex 4.0.0.1003