【NetApp】SAS接続と通信経路に関する基礎

2023年10月28日

こんにちは、キクです。

当ブログでは、これまで仕事で経験させていただきながら学んだNetAppに関する技術情報を何度か発信してきました。
今回も同様に、NetAppに関する記事を書いていこうと思うのですが、NetAppをそれなりに触っていたにも関わらず、あまり意識できていなかったなと感じたことがありました。
それはNetAppのコントローラとシェルフ間の｢SAS接続経路｣についてです。

そんなわけで、本記事ではNetAppを扱う上での土台とも言える『SAS接続と通信経路』について書いていこうと思います。

それでは、よろしくお願いします。

動作環境

本記事の内容は、下記の環境で実施したものになります。
・ONTAP 9.3
・ONTAP 9.8

注意事項

本記事は僕が経験した内容をもとに記載しておりますが、実行環境や設定内容によっては動作が異なる場合があります。
そのため『参考程度』にお読みいただけますと幸いです。

背景

本記事の冒頭では、SAS接続の経路に関して｢あまり意識できていなかった｣と書きました。
今までNetAppのクラスタをいくつか構築してきましたが、この｢SAS接続｣の部分については恥ずかしながら基本的に右にならえの状態だったのです。
その接続にすることでノードとシェルフ間の経路が冗長化されるということは理解しつつも、より詳細な内部的な経路までは把握できていませんでした。

きっかけはシェルフの障害

今回、SAS接続経路を意識するきっかけになったのは｢シェルフの障害｣でした。
障害の詳しい内容については、本記事の本題と逸れるのでまた別の機会に記事にしようと思いますが、障害復旧のためにはシェルフに搭載されたIOMモジュールの再起動が必要となり、これに伴い｢どの経路がダウンするのか｣を把握する必要がありました。

｢冗長化されているため、A系の再起動時もB系で通信の継続が可能｣という情報だけでは少し不十分という状態でした。
そのような経緯もあり、SAS接続の経路についてもう少し深堀することになりました。

障害発生時のSAS接続状態

シェルフの障害が発生した時点では、以下のような接続状態でした。

この接続方法は基本的なものであり、NetApp公式情報でも「標準シェルフ/シェルフ間接続」として記載があります。
参考：SASケーブル接続のルールと概念- IOM12 / IOM12Bモジュールを搭載したシェルフ
参考：FASシステム-設置とセットアップ詳細ガイド

SAS接続と通信経路について

本稿では、先述の「障害発生時のSAS接続状態」でご紹介した接続状態における通信経路についてお話しします。

各ポートの接続意図

今回の接続においては、以下のポートが利用されています。

今回の利用ポート

コントローラA, B（共通）
　1. 0a
　2. 0d

シェルフ#1 - #5（共通）
　1. IOMポート1
　2. IOMポート3

これは「標準シェルフ/シェルフ間接続」における以下のようなルールに則っているためです。

  1. 0aと0cは常にスタックのプライマリパスである
  2. 0bと0dは常にスタックのセカンダリパスである
  3. 0aと0cは常にスタック内の論理的に最初のディスクシェルフに接続する
  4. 0bと0dは常にスタック内の論理的に最後のディスクシェルフに接続する
  5. 0aと0cは常にディスクシェルフのIOMポート1とIOMポート2に接続する
  6. 0bと0dは常にディスクシェルフのIOMポート3とIOMポート4に接続する
  7. コントローラAの0aと0cは常にIOMモジュールAに接続する
  8. コントローラAの0bと0dは常にIOMモジュールBに接続する
  9. コントローラBの0aと0cは常にIOMモジュールBに接続する
  10. コントローラBの0bと0dは常にIOMモジュールAに接続する
  11. 各シェルフ間の接続にはIOMポート3とIOMポート1を使用する

各ポートについて改めて整理すると、以下のようになります。

各ポートに関する説明

コントローラA
　1. 0a
　　 - プライマリパスとして利用
　　 - スタック内の論理的に最初のディスクシェルフのIOMモジュールAに接続
　2. 0d
　　 - セカンダリパスとして利用
　　 - スタック内の論理的に最後のディスクシェルフのIOMモジュールBに接続

コントローラB
　1. 0a
　　 - プライマリパスとして利用
　　 - スタック内の論理的に最初のディスクシェルフのIOMモジュールBに接続
　2. 0d
　　 - セカンダリパスとして利用
　　 - スタック内の論理的に最後のディスクシェルフのIOMモジュールAに接続

シェルフ#1（先頭）
　1. IOMポート1
　　 - 各コントローラのプライマリパス用ポート「0a」と接続
　2. IOMポート3
　　 - スタック内の次のシェルフと接続

シェルフ#2 - #4
　1. IOMポート1
　　 - スタック内の前のシェルフのIOMポート3と接続
　2. IOMポート3
　　 - スタック内の次のシェルフのIOMポート1と接続

シェルフ#5（終端）
　1. IOMポート1
　　 - スタック内の前のシェルフと接続
　2. IOMポート3
　　 - 各コントローラのセカンダリパス用ポート「0d」と接続

各ルールと各ポートの関係性を図にすると以下のようになります。

追加情報

今回の構成では、各コントローラのSASポート「0b, 0c」および各シェルフのIOMポート「2, 4」は利用していませんが、余っているポートは他のスタックを追加したい場合や、更に強固な冗長構成にしたい場合などに利用できます。

通信経路について

今回の接続方法「標準シェルフ/シェルフ間接続」においては、以下4つの通信経路があります。

  1. コントローラAの0aポートから各シェルフのIOMモジュールAを利用する経路（プライマリパス）
  2. コントローラAの0dポートから各シェルフのIOMモジュールBを利用する経路（セカンダリパス）
  3. コントローラBの0aポートから各シェルフのIOMモジュールBを利用する経路（プライマリパス）
  4. コントローラBの0dポートから各シェルフのIOMモジュールAを利用する経路（セカンダリパス）

これらの経路は大きく以下2つに分類することができるかと思います。

  1. 上から下（シェルフ#1 -> シェルフ#5）への経路・・・プライマリパス
  2. 下から上（シェルフ#5 -> シェルフ#1）への経路・・・セカンダリパス

恥ずかしながら僕の中では「下から上への経路（セカンダリパス）」に関する認識がだいぶ抜け落ちていたということに、今回の件で気付くことができました。
これまでは正直「A系とB系」という大きな括りでしか見えていませんでした。
しかし、実際には「コントローラ1からのA系経路（ = A系のプライマリ）」「コントローラ2からのA系経路（ = A系のセカンダリ）」のようにA系だけでも2経路あるということを強く認識しました。

今回はシェルフ障害からの復旧のためにIOMモジュールの再起動が必要ということでしたが、対象シェルフの各IOMモジュールを再起動した場合の通信経路は以下のようになります。

シェルフ#4 - IOMモジュールAの再起動時

SASポートシェルフ#1シェルフ#2シェルフ#3シェルフ#4シェルフ#5
A系 - コントローラA（0a）○○○××
A系 - コントローラB（0d）××××○
B系 - コントローラB（0a）○○○○○
B系 - コントローラA（0d）○○○○○

シェルフ#4 - IOMモジュールBの再起動時

SASポートシェルフ#1シェルフ#2シェルフ#3シェルフ#4シェルフ#5
A系 - コントローラA（0a）○○○○○
A系 - コントローラB（0d）○○○○○
B系 - コントローラB（0a）○○○××
B系 - コントローラA（0d）××××○

上から下（シェルフ#1 -> シェルフ#5）への経路については、シェルフ4の再起動時にそれ以降のシェルフ#5への通信ができなくなることは直感的にもイメージしやすいです。
加えて、下から上（シェルフ#5 -> シェルフ#1）への経路において、シェルフ#4以降のシェルフ#1～シェルフ#3についても影響があることを忘れてはいけないというのがポイントでした。

各通信経路のステータス確認方法

最後に、各コントローラと各シェルフのSAS接続がOS（ONTAP）からどのように認識しているかを確認する方法について触れておこうかと思います。

以下のコマンドを実行することで、指定したコントローラの各SASポートから接続されているシェルフ情報を確認できます。

::> system node run -node コントローラ名 -command sasadmin expander_map
[実行例]
::> system node run -node cluster-01 -command sasadmin expander_map

Expanders on channel 0a:
Level  1: WWN xxxxx, ID 1, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot A
Level  2: WWN xxxxx, ID 2, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot A
Level  3: WWN xxxxx, ID 3, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot A
Level  4: WWN xxxxx, ID 4, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot A
Level  5: WWN xxxxx, ID 5, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot A

Expanders on channel 0b:
Cannot Complete operation on channel 0b; Status Not Available

Expanders on channel 0c:
Cannot Complete operation on channel 0c; Status Not Available

Expanders on channel 0d:
Level  1: WWN xxxxx, ID 5, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot B
Level  2: WWN xxxxx, ID 4, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot B
Level  3: WWN xxxxx, ID 3, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot B
Level  4: WWN xxxxx, ID 2, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot B
Level  5: WWN xxxxx, ID 1, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot B
[実行例]
::> system node run -node cluster-02 -command sasadmin expander_map

Expanders on channel 0a:
Level  1: WWN xxxxx, ID 1, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot B
Level  2: WWN xxxxx, ID 2, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot B
Level  3: WWN xxxxx, ID 3, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot B
Level  4: WWN xxxxx, ID 4, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot B
Level  5: WWN xxxxx, ID 5, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot B

Expanders on channel 0b:
Cannot Complete operation on channel 0b; Status Not Available

Expanders on channel 0c:
Cannot Complete operation on channel 0c; Status Not Available

Expanders on channel 0d:
Level  1: WWN xxxxx, ID 5, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot A
Level  2: WWN xxxxx, ID 4, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot A
Level  3: WWN xxxxx, ID 3, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot A
Level  4: WWN xxxxx, ID 2, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot A
Level  5: WWN xxxxx, ID 1, Serial Number 'xxxxx', Product 'シェルフ型番IOMxx  ',Rev 'xxxx', Slot A

表示結果からも分かるように、各SASポートが直接接続されているシェルフを先頭にして以降のシェルフも表示されています。
これにより｢上から下｣｢下から上｣という各経路についても把握しやすいかと思います。
シェルフの障害時や再起動時においては、対象シェルフおよびそれ以降のシェルフが表示されなくなることが確認できます。

おわりに

いかがだったでしょうか。
今回はNetAppにおけるコントローラとシェルフのSAS接続と通信経路についてご紹介しました。

コントローラ-シェルフ間の接続は土台であるにもかかわらず一度構築してしまえばそれ以降はあまり意識することもない部分なので、今回改めて整理できて個人的にも良かったです。
僕と同様に「あまり意識できていなかった」という方に少しでも参考になる情報をお届けできていれば嬉しいです。

本記事を最後まで読んでいただき、ありがとうございました。
ではでは！

-NetApp
-