Технологія PowerFlex: Мережеві адаптери SVM можуть бути неправильно призначені під час перетворення SVM

Summary: Під час процесу перетворення SVM мережеві адаптери SVM можуть призначатися неправильно.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

Користувач не може оновити або конвертувати основний MDM (останній MDM) під час перетворення SVM, оскільки підмережі не можуть обмінюватися даними.

 

Сценарій

Мережеві адаптери було неправильно впорядковано після перетворення 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]:

  1. Переведіть кластер в єдиний режим (ми повинні видалити і знову додати з правильним порядком IP)
  2. Відредагуйте сценарії /etc/sysconfig/network-scripts/ifcfg-eth* у вторинному MDM, щоб вони відповідали поточному порядку первинного MDM (MGMT для eth0, DATA1 для eth1, DATA2 для eth2)
  3. Переведіть SDS, який знаходиться на поточному вторинному MDM, у режим обслуговування (MM), оскільки ми змінюємо IP-адреси з перезавантаженням
  4. Перезавантажте SVM, який було поміщено в MM
  5. Після повторного підключення до цього вузла переконайтеся, що IP-адреси розташовані в тому ж порядку, що й поточний основний MDM, як зазначено в кроці #2
  6. Переконайтеся, що SDS знову підключено, а потім вийдіть з MM
  7. Видаліть додатковий MDM, який ми щойно перезавантажили з кластера MDM
  8. Повторно додайте в режим очікування MDM, переконавшись, що порядок IP-адрес у полі «new_mdm_ip» збігається з поточним основним (DATA1, DATA2)
  9. Поверніться до 3-вузлового/5-вузлового режиму
  10. Переконайтеся, що кластер справний і синхронізований
  11. Зміна власника MDM
  12. Після успішного переходу права власності на 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

 

Affected Products

PowerFlex rack, PowerFlex Appliance, PowerFlex custom node, PowerFlex Software
Article Properties
Article Number: 000225313
Article Type: Solution
Last Modified: 30 Dec 2025
Version:  3
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.