Japan IBM Storage User Group

HBAのポートを複数ストレージで共有しても良いか?

By Keitaro Imai posted Sat June 13, 2020 12:17 PM

  
サーバーのHBAポートが足りないので、1つのポートに複数種類のディスクやテープストレージを繋げたい、というシチュエーションがあるかと思います。
そもそも、この様な構成はサポートされるのか、問題ないのかについてイマイの見解を書きたいと思います。


まず、サポートされるか?ということですが、この点はグレイです。
過去のIBMストレージ装置である、FAStT、DS4000(懐かしい!!)などでは、Readmeなどに他のストレージ装置とHBAを共有することはサポートしない、という明確な記述がありました。
そう書いてあれば判断は楽なのですが、最近のストレージのどのドキュメントを見てもその様な記述は見当たりません。。。
とはいえ、書いてなければオーケーなのかというと、むしろ書いてないのでオーケーではないと判断すべきと思います。
マニュアル等に書いてない構成をとったとして、問題が発生した際に、「その様な構成はマニュアルに書いてないからサポートしない」と言われればそれでおしまいですので。
ですので、確実にサポートを得たい場合はIBM営業経由でRPQ/SCORE申請を行ってください。
もちろん、IBM製品だけでなく他ベンダーのストレージが存在する場合は、そのベンダー側でもサポートが得られるようにしてください。


次に問題ないのか。多くのドキュメントにはテープとディスク装置は共有するべきではない、と書かれています。
以下いくつか抜粋します。
SAN Zoning Best Practices
Never mix tape and disk traffic on the same server Host Bus Adapter (HBA) port with one or more zone definitions. This issue is a source of confusion for many administrators due to a number of reasons. Some HBA vendors state that they support mixing tape and disk traffic on the same port. Based on the collective experience of the IBM SAN Central team, customer environments with tape and disk traffic on the same HBA port will eventually experience problems. 


IBM FlashSystem A9000, IBM FlashSystem A9000R, and IBM XIV Storage System: Host Attachment and Interoperability
Disk and tape traffic are ideally handled by separate HBA ports because they
have different characteristics. If both traffic types use the same HBA port, it can cause
performance problems, and other adverse and unpredictable effects.


IBM System Storage SAN Volume Controller and Storwize V7000 Best Practices and Performance Guidelines
Keep Fibre Channel tape (including Virtual Tape Libraries) and Fibre
Channel disks on separate HBAs. These devices have two different data patterns when
operating in their optimum mode. The switching between them can cause unwanted
processor usage and performance slowdown for the applications.

ざっくり言うとディスクとテープではI/Oの特性が異なるため、それが相乗りすることによりパフォーマンスの点で問題が起こりうるということです。
テープへのアクセスの場合は通常大容量のシーケンシャルRead/Writeがほとんどですが、一般的なディスクアクセスはランダムの小さいブロックサイズのアクセスがほとんどです。
テープの場合は特に顕著ですが、一定の速度でデータが流れる分には良いですが、転送が滞った場合極端に速度が遅くなることがあります。
それはテープの特性であるバックヒッチによるものです。一定の転送速度でデータを書き込んでいる場合は、テープを送る速度は一定ですが、データの転送が急に滞ったりするとテープは急に速度を落とせないため、書けない領域が出来ます。この書けない領域へデータを書くために、テープの巻き戻し処理(バックヒッチ)が発生します。この処理を待っている間はデータが書けないので極端にパフォーマンスが落ちるということになります。
そのため、テープへの書き込みを阻害する他の要因は相乗りすべきではありません。また、テープは帯域を大きく使用するために、他で使用できる帯域が少なくなってしまうという点もあります。


厳密に言えば、テープでなくとも異なるディスク装置の場合はそれぞれ用途が異なるわけでI/O特性というものは異なります。
それらを相乗りさせても大丈夫かといえば、それはその環境での負荷次第なので一概には判断ができません。
また、AIXでは、HBA(fcsデバイス)のデバドラの設定値として、num_cmd_elems、max_xfer_sizeといった値があります。これはポート単位に設定しますが、接続するストレージ装置や負荷に対して適切な値を設定すべきです。複数のストレージ装置や負荷が相乗りする場合は、適切な値を決定するのが難しいということにもなります。
そのあたりの判断が難しいようであれば、結局の所分けることが無難、というのがイマイの見解です。
もちろん、大した負荷はかからない、パフォーマンスは気にしない、負荷はバッティングしない、開発環境だ、ということであればサポートされるということが前提で接続しても良いかと思います。
私達のLab環境でも同時接続していますが、単に同時接続することによる問題は発生していません。
今後この様なシチュエーションがある場合の参考としてください。


#Storage
#tape
#hba
#share
0 comments
5 views

Permalink