Persistent Port

そんな中、ONTAPでは「Persistent Port」と「SnapMirror active sync」という機能を実装することにより、ビジネス継続性の向上を図っています。
「SnapMirror active sync」については次回のブログで紹介させていただくとして、今回は強力なネットワークの冗長化機能である「Persistent Port」についてご紹介いたします。

NetAppのSAN構成におけるネットワーク冗長化機能はストレージのシリーズによって仕組みが異なります。
FASやAFFシリーズではActive最適化/非最適化パスといい、LUNに対するパスが複数ある場合でもアクティブなパスは1つのみとなっており、ネットワークの切り替え時は非最適化状態のパスが最適化に切り替わることから待機時間が最大10秒程度発生します。



次にASAシリーズをiSCSI構成で利用する場合、対象Active最適化パスといい、LUNに対する全てのパスがアクティブかつ最適化の状態で動作するため、ネットワークの切り替え時でも切り替え先のパスが即座に利用できることから待機時間が2秒程度となる可用性の高い冗長構成となっています。



そして、今回ご紹介するPersistent Portですが、これはASAシリーズかつFC構成でのみサポートされる機能となっており、Active最適化パスをサポートしながらそれと同時にActiveなパスと全く同じポート情報を持つシャドウLIFと呼ばれる予備のネットワークが対向ノードに自動的に作成されます。

障害発生時はサーバー側がネットワーク断を検知する前にシャドウLIFが有効化され、さらにシャドウLIFは障害となったアクティブなパスと同じポート情報をもっているため、サーバーから見ると障害前と変わらない状態でネットワークが利用されます。
アクティブなパスの数も変わらなければ、WWPNなどのアクセス情報も変わらないため、複数パスによる負荷分散など、パフォーマンスに関する影響もなくシステムを継続できます。



ビジネス継続性というと災害などの大規模障害に備えるといった大きな部分に焦点が集まりがちですが、コントローラーやディスクなど、小さな部分のコンポーネント障害の方が確率としては高いと考えれるので、ネットワークの冗長化機能についても良いものを利用していただきたいと思います。

それでは、実機を用いてPersistent Portの設定状況やネットワーク切り替え時の動作を確認していきましょう。

本検証では、ASAシリーズのエントリーモデルである「ASA A150」を利用します。
その他の検証に関する条件は以下となっています。

【検証条件】
ストレージ：NetApp ASA A150
ストレージ接続プロトコル：FC / iSCSI
仮想環境：ESXi 7.0 / vCenter 8.0

今回の検証では、ASA A150の各ノードに対してLIFを2本作成します。
つまり、筐体全体でアクティブなLIFが4本、シャドウLIFが4本という構成になります。
サーバー側にはVMwareのESXiを使用しており、FC構成とiSCSI構成のデータストアを用意しております。

Persistent Portの設定内容を確認する

1. Teratermなどのターミナルソフトを経由してNetAppストレージへアクセスした後、
   以下のコマンドを実行し、diag権限へ移行します。
   >set diag
   >Do you want to continue? {y|n}：y
   
   
   
2. 以下のコマンドを実行し、Persistent Portの設定内容を確認します。
   >san config show
   
   
   デフォルトではPersistent Port Enabledの値が「true(有効)」となっていることが分かります。

Persistent Portの無効化

1. diag権限の状態で以下のコマンドを実行し、Persistent Portを無効化します。
   >san config modify -is-persistent-ports-enabled false
   
   
   
2. 次に以下のコマンドを実行し、シャドウLIFを削除します。
   >debug san pports resync -vserver [SVM名] -delete-shadow-lif true
   >debug san pports verify -vserver [SVM名] -expect-shadow-lif-deleted true
   
   
   
   以上でPersistent Portの無効化は完了です。

Persistent Portの有効化

1. diag権限の状態で以下のコマンドを実行し、Persistent Portを有効化します。
   >san config modify -is-persistent-ports-enabled true
   
   
   
2. 次に以下のコマンドを実行し、シャドウLIFを作成します。
   >debug san pports resync -vserver [SVM名] -lif-name [シャドウLIFを作成するLIF名]
   >debug san pports verify -vserver [SVM名] -lif-name [シャドウLIFを作成するLIF名]
   
   
   ※本コマンドをシャドウLIFを作成するLIFの数だけ実行します。
   
   この時、showコマンドやSystem Managerから確認してもシャドウLIFは表示されません。
   あくまでシステムのバックグラウンドで待機しているLIFという位置づけとなります。
   
   
   以上でPersistent Portの有効化は完了です。

iSCSI環境でのマルチパス動作確認(対象Active最適化パス)

まず、Persistent Portの比較対象としてiSCSI環境でマルチパスがどのような動作になるのか確認します。

1. System ManagerからボリュームとLIFの情報を確認します。
   本検証では、iSCSI用のLUNが1つ、iSCSI用のLIFが4つ構成されています。
   
   
   
   
2. 同様にvCenterからもデータストアとパスの情報を確認します。
   iSCSI用のデータストアが1つ、iSCSI Adapterがサーバーに対して2口搭載されているため、パスとしては8つ構成され、「アクティブ(I/O)」として認識されていることが分かります。
   
   
   
3. 今回は疑似的な障害として片側のノードを再起動します。
   System Managerからノード#1を選択し、「リブート」をクリックします。
   
   
   
4. ノード#1が再起動され、テイクオーバー(ノードのフェイルオーバー)が発生します。
   
   
   
5. vCenterを確認すると、8つのパスのうち4つが「アクティブ(I/O)」から「アクティブ」状態に変更され、パスとして見えてはいるもののI/Oのやり取りがない状態で認識されています。
   
   
   その後、vCenterからストレージアダプターを再読み込みすることで「アクティブ(I/O)」の状態に戻ることを確認しました。

FC環境でのマルチパス動作確認(Persistent Port)

次に、Persistent Portの動作を確認するため、FC構成で同様の検証を行います。

1. System ManagerからボリュームとLIFの情報を確認します。
   本検証では、FC用のLUNが1つ、FC用のLIFが4つ構成されています。
   
   
   ※Persistent Port構成では、シャドウLIFが作成されていますがSystem Managerには表示されません。
   
   
2. 同様にvCenterからもデータストアとパスの情報を確認します。
   FC用のデータストアが1つ、HBAがサーバーに対して2口搭載されているため、パスとしては8つ構成され、「アクティブ(I/O)」として認識されていることが分かります。
   
   
   
3. 先ほどと同様、疑似的な障害として片側のノードを再起動します。
   System Managerからノード#1を選択し、「リブート」をクリックします。
   
   
   
4. ノード#1が再起動され、テイクオーバー(ノードのフェイルオーバー)が発生します。
   
   
   
5. vCenterを確認すると、8つのパス全てが「アクティブ(I/O)」状態で認識されており、テイクオーバー前と変わらずデータアクセスが継続されていることが分かります。
   
   
   実際にはサーバー側がネットワーク断を認識する前にシャドウLIFが有効化されているため、そもそも障害が発生したという状態にならずにパスのステータスも変わらないという仕組みになっています。
   
   以上でPersistent Portの動作確認を完了します。