PowerFlex：PFxMアップグレードおよびOS変換後のデータVLANタグ付けの標準化

CentOSからSLESへのOSの変換中に、もともとv1ネットワーキングを使用してPowerFlex Manager (PFxM) 3.xで構築されたノード(Data1およびData2ネットワークがタグなしでアクセスVLANスイッチポートに接続されている)がPFxM 4.xネットワーキング モデルに正常に移行しないことが確認されました。これらのレガシー ノードは引き続き、データ ネットワーク用のタグなしインターフェイスに依存していましたが、PFxM 4.xで追加された新しいノードは、データ ネットワーク用のVLANタグ付けを使用するインターフェイスとともに導入されました。

変換中に、PFxM 4.xは、これらのレガシー ノード上のデータ ネットワーク インターフェイスをVLANタグ付きSLESインターフェイスにアップデートしましたが、関連付けられているスイッチ ポートはアクセス ポートとして構成されたままでした。この状態により、変換中のノードがデータ ネットワークから分離され、変換プロセスを完了できませんでした。

この手順では、すべてのノード(特に元々は3.x v1ネットワーキングで構築されたノード)をPFxM 4.x VLANタグ付き設計に標準化し、一貫性と信頼性のあるデータ ネットワーク運用を確保するための、明確で再現性のあるフィールド対応の方法を提供します。

• 元々は、タグなしData1/Data2ネットワーク(アクセスVLAN)を備えたPFxM 3.xの下に導入されたPowerFlexクラスター。
• その後、クラスターはPFxM 4.xにアップグレードされ、VLANタグ付きデータ ネットワークが想定されます。
• トランク スイッチポート上のVLANタグ付きデータ ネットワークを備えたPFxM 4.xの下にノードが追加されました。
• アクセスVLANスイッチ ポートを使用している間、CentOSからSLESへのOS変換で、ノード上のタグなし構成が保持されませんでした。

クラスターには、タグなしデータ ネットワークを使用するノードと、VLANタグ付きデータ ネットワークを使用するノードが混在しています。VLANタグを使用していないインターフェイスで導入されたノードをアップグレードすると、インターフェイス設定がVLANタグを使用するように変換されました。スイッチ ポート インターフェイスの設定がアクセス モードからトランク モードに変換されませんでした。これにより、ノード インターフェイスとスイッチ ポート間のデータVLANのマッピングが正しく行われませんでした。これにより、影響を受けるノードのデータ ネットワークから分離されました。VLANの動作を標準化するために、制御されたノードごとの修復が環境に必要になります。

OS変換プロセスでは、ホストNICタグ付けはアップデートされますが、スイッチポート モードはアップデートまたは検証されないため、ホストVLAN構成とスイッチVLAN期待値の間に不整合が生じます。

影響を受けるノードごとに次の手順を実行します。クラスターの冗長性を維持し、不要な再構築を回避するために、一度に1つのノードのみを修正してください。

事前チェック

• クラスターが正常であることを確認します(進行中の再構築がなく、すべてのSDSがオンライン)。
• タグなしデータ ネットワークをまだ使用しているノードを特定します(例: なしで p2p2/em2 に直接設定された IP。VLANサフィックス)
• ノードのData1 IPアドレスとData2 IPアドレスを記録します。
• ホスト ネットワーク構成ファイル(例: /etc/sysconfig/network scripts/ifcfg-*) にあります。
• 必要に応じてロールバックするために、ノードのData1およびData2ポートの現在のスイッチポート設定をキャプチャします。
• Data1とData2に使用されているVLAN IDを確認します(例: Data1 = 152、Data2 = 160)

ネットワークとホストの変更:

ノードをメンテナンス モードにする

PowerFlex Managerを使用して、ノードをメンテナンス モードにします。

このノード上のSDSがメンテナンス中であり、再構築操作が開始されていないことを確認します。

スイッチ ポートのアクセスをトランクに更新します。

スイッチで、このノードのData1ポートとData2ポートを更新します。

Data1およびData2スイッチ ポートをアクセス モードからトランク モードに変換します。

• トランク許可VLANリストにデータVLAN(152や160など)が含まれていることを確認します。
• 正しいスイッチ ポートが特定されていることを確認します(たとえば、ノード インターフェイスp2p2がスイッチ ポートEthernet 1/1に接続されます)。
• スイッチでMTUが9216(または環境標準)に設定されていることを確認します。
• スパニングツリー エッジ トランク、bpduguard、ガード ルートを設計どおりに有効にします。

データ1(ビフォー)の例:

 Show running-config interface Ethernet 1/1
    switchport
    switchport access vlan 152
    spanning-tree port type edge
    mtu 9216

data1 の例 (変更後):

 Show running-config interface Ethernet 1/1
    switchport
    switchport mode trunk
    switchport trunk allowed vlan 152
    spanning-tree port type edge trunk
    spanning-tree bpduguard enable
    spanning-tree guard root
    mtu 9216

スイッチ ポート設定を変更するためのサンプル実行スクリプト。

configuration terminal
 interface ethernet 1/1
    switchport mode trunk
    switchport trunk allowed vlan 152
    no switchport access vlan 152
    spanning-tree port type edge trunk
    spanning-tree bpduguard enable
    spanning-tree guard root
    end
copy running-config startup-config

ホストOSネットワーク構成の更新

• 現在のネットワーク files.cd をバックアップします /etc/sysconfig/network-scripts/
• ネットワーク インターフェイス ファイルを編集して名前を変更します。
• ネットワークを再起動します。
• データ ネットワーク パスを検証します。

• 最初のSDSノードにログインします
• 使用されているインターフェイスを確認します。
• 現在のインターフェイスとIPアドレスを表示します。

ip address

• 静的ルートを確認し、記録します。
• ネットワーク ファイル ディレクトリーに移動します。

cd /etc/sysconfig/network-scripts/

現在のネットワーク ファイルを確認します。

ls -ltr

現在のネットワーク ファイルのバックアップ

cp /etc/sysconfig/network-scripts/ifcfg-<devicename>  /etc/sysconfig/network-scripts/ifcfg-<devicename>.bak

現在のネットワークファイルの名前を変更します。

mv /etc/sysconfig/network-scripts/ifcfg-<devicename> /etc/sysconfig/network-scripts/ifcfg-<devicename>.<vlan>

Example:

mv /etc/sysconfig/network-scripts/ifcfg-em2 /etc/sysconfig/network-scripts/ifcfg-em2.152

ネットワーク ファイルを編集します。

vi /etc/sysconfig/network-scripts/ifcfg-<devicename>.vlan

Example:

vi /etc/sysconfig/network-scripts/ifcfg-em2.152

デバイス名を<dot>vlan IDで更新し、VLAN=yesを挿入します。

DEVICE=em2.152

VLAN=yes

終了してファイルを保存します。

:wq!

他のデータ ネットワークに対しても同じ手順を繰り返します

ネットワークを再起動して検証する

ホストでネットワーク サービスを再起動するか、制御された再起動を実行します。

静的ルート構成

SDSノードに対してSSHを実行します。

次のコマンドを実行します。

ip route

タグなしインターフェイス(em2、p2p2など)を参照するルートがないことを確認します。すべてのルートは、VLANタグ付き同等のものを参照する必要があります。

例 

default via 172.18.133.1 dev bond0.1352

172.18.133.0/24 dev bond0.1352 proto kernel scope link src 172.18.133.100

192.168.152.0/21 dev p2p2.152 proto kernel scope link src 192.168.152.100

192.168.160.0/21 dev em2.160 proto kernel scope link src 192.168.160.100

ネットワーク検証

VLANインターフェイス(p2p2.152やem2.160など)が稼働していることを確認します。

例

 ip address

インターフェイスをソースとするpingを使用して、ホストから既知のピアまたは各VLANにpingを実行します。

例

ping -I p2p2.152 <peer>

オプション：大きなペイロードでpingを使用してジャンボフレームMTUをテストします。

例

ping -I p2p2.152 -s 8972 -M do <peer>

メンテナンス モードの終了

 PowerFlex Managerで、ノード上のSDSとデバイスの正常性を確認します。

 ノードのメンテナンス モードを終了します。

 アラート、SDSの再起動、リンク フラップを数分間監視します。

残りのノードに対して同じ手順を繰り返します

PFxM 4.x設計と一致するVLANタグ付きデータ インターフェイスにクラスター全体が標準化されるまで、タグなしデータ ネットワークを使用する残りの各ノードに対して繰り返します。

検証テスト計画書(概要)

• MTU検証: VLANインターフェイスがMTU 9000を使用し、ジャンボpingテストがData1とData2のピアに成功することを確認します。
• SDSの検証: SDSが接続されていること、再起動が発生していないこと、デバイス パスがアラインされていることを確認します。
• ネットワーク接続: 両方のデータVLANで複数のピアへのEast-West接続を確認します(p2p2.152およびem2.160からのping)。
• フェールオーバー：Data1インターフェイスとData2インターフェイスを一度に1つずつ一時的に無効にして、残りのパスを使用してSDSがオンラインのままであり、再有効化後に冗長性が復元されることを確認します。
• SCR/PFxM: SCRおよびPowerFlex Managerのヘルス チェックを実行して、VLAN/MTU/ネットワーク関連のエラーがないことを確認します。

影響を受けるプラットフォーム/バージョン

- PowerFlex 3.6.x/3.7.x/3.8.xノードは、もともとアクセスモードVLANで導入されていました
- PowerFlex 4.x PFMPからSLESへの変換
- Dell R640/R740サーバー
- Cisco Nexusスイッチ、Dell OS10ベースのスイッチ

修正バージョン

4.6.2.1