ハードウェア中級 #7 ストレージネットワーク — iSCSI・FC・NVMe-oF・マルチパス

インフラ ハードウェア
読了 6分

第6回までのディスクはサーバーの中にありました。しかし 基礎 #5 で見たように、規模が大きくなるとストレージはサーバーの外の共用機材 (SAN) へ出ていき、サーバーはネットワークの向こうのディスクを自分のもののように使います。今回はその「ネットワークの向こうのブロックデバイス」を実際につなぐ技術の話です。同じ SAN でも、何でつなぐかによってコストと運用が大きく変わります。

まず境界を 1 つはっきりさせておきます。この記事はブロックストレージ (サーバーにディスクのように見えるもの) の話です。ファイル単位で共有する NFS・Samba は RHEL 中級 #3 の領域で、層が違います。

iSCSI — 普通のネットワークでつなぐ SAN #

iSCSI はディスクの命令 (SCSI) を普通の TCP/IP ネットワークに載せて運ぶプロトコルです。サーバー (イニシエータ) がストレージ (ターゲット) にログインすると、ネットワークの向こうのボリュームがローカルディスクのように (/dev/sdX) 現れます。

強みは何といっても汎用性です。専用機材なしで既存のイーサネットとスイッチから始められ、運用の知識も一般的なネットワークの延長です。その代わり、一般的なネットワークの問題をそのまま受け継ぎます。他のトラフィックとの競合や TCP の遅延変動が、そのままディスクのレイテンシに直結します。だから iSCSI 運用の第一原則は ストレージトラフィックの分離 です。専用 NIC と専用ネットワーク (最低でも専用 VLAN) を与え、サービストラフィックと混ぜないことです。

FC — ストレージ専用に生まれたネットワーク #

FC (Fibre Channel) は最初からストレージ用に設計された別のネットワークです。専用アダプタ (HBA) と専用スイッチで SAN ファブリックを組み、どのサーバーがどのボリュームを見るかをゾーニング (zoning) で統制します。

iSCSIFC
ネットワーク既存のイーサネット専用ファブリック (HBA、FC スイッチ)
コスト・導入低い高い
レイテンシの一貫性構成によって変動安定
運用の知識ネットワークチームの延長別の専門領域 (ゾーニングなど)

要点は優劣ではなく取引です。FC は一貫したレイテンシと分離をお金と専門性で買う選択で、iSCSI は汎用性を取る代わりにネットワーク設計の責任を運用者が持つ選択です。ミッションクリティカルな DB の伝統的な定位置が FC だった理由と、仮想化や一般的なワークロードで iSCSI が広く使われる理由が、この表の中にあります。

NVMe-oF — 速いディスクには速い道を #

基礎 #4 で、NVMe が SATA の命令体系を捨ててフラッシュに合わせて設計し直されたインターフェースだということを見ました。同じことがネットワークでも繰り返されます。SCSI を運ぶ iSCSI/FC の上に NVMe ディスクを置くとプロトコル変換が挟まりますが、NVMe-oF (NVMe over Fabrics) は NVMe の命令を変換なしでネットワーク (イーサネットの RDMA、FC、または普通の TCP) へ拡張してその隙間をなくします。ローカル NVMe に近いレイテンシをネットワーク越しに出すことが目標です。

運用者から見た立ち位置はこうです。オールフラッシュの最新ストレージと低遅延が重要なワークロードの組み合わせで標準になりつつあり、その中でも NVMe/TCP は特別な NIC なしでも動くため、iSCSI の後継として普及が進んでいます。新しい SAN を設計するなら、「iSCSI か FC か」に「NVMe-oF ではないか」を一緒に問う時代です。

マルチパス — 道が切れてもディスクは生きていなければならない #

何でつなぐにせよ、ネットワークの向こうのディスクには新しい故障モードが生まれます。ディスクは無事なのに 道 (ケーブル、スイッチ、アダプタ) が切れるケースです。だから SAN は道を 2 本以上持つのが基本で、その道を 1 つのディスクとして束ねて管理するのがマルチパス (multipath、同じボリュームへ向かう複数の経路を束ね、障害時の切り替えと負荷分散を行う機能) です。

multipath -ll（要約） 
mpatha (3600a0980...) dm-2 VENDOR,MODEL
size=2.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:1  sdb  8:16  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:1  sdc  8:32  active ready running

Linux の device-mapper multipath が 2 つの経路 (sdb、sdc) を mpatha という 1 つに束ねた様子です。運用のポイントは 3 つです。

  • アプリケーションは必ず束ねたデバイス (mpatha) を使います。 sdb を直接使うと、その経路が切れた瞬間に I/O が止まります。
  • 経路が 1 本死んだ状態は、第6回のデグレードと同じ意味です。 サービスは動いていますが余裕が消えた状態なので、経路の状態もアラートの対象です。
  • ポリシーを理解して設定します。 すべての経路を一緒に使う分散型が基本ですが、ストレージによっては優先経路を持つ構成 (ALUA) もあるため、ストレージベンダーの推奨設定に従うのが安全です。

クラウドでは — 同じ構造の置き換え #

クラウドのブロックストレージ (EBS のような) は、まさにこの記事の構造物です。インスタンスに付くボリュームはローカルディスクではなく ネットワークの向こうのブロックデバイス で、冗長化された経路とストレージ機材をクラウドが代わりに運用してくれているのです。第5回で見た「ボリュームとインスタンスの両側の上限」もこの構造の結果です。ディスク I/O が結局ネットワーク帯域を通るからです。オンプレミスの SAN の知識が、クラウドではスペック表の読み方へ形を変えて生き残るわけです。

よく出会う落とし穴 #

  • iSCSI をサービスネットワークに混ぜる — トラフィックが集中した瞬間、ディスクのレイテンシも一緒に跳ねます。専用 NIC/VLAN の分離が iSCSI 運用の半分です。
  • マルチパスの下の生デバイスを直接使う — /dev/sdb を fstab に書いた瞬間、冗長化が無効になります。束ねたデバイスとその識別子 (WWID) を使います。
  • 経路障害を静かに見過ごす — 経路が 1 本死んでもサービスは無事なので気づきにくいです。2 本目まで死んでから発見する事故を、アラートで防ぎます。

まとめ #

今回つかんだ絵です。

  • iSCSI は汎用性、FC は一貫性と分離、NVMe-oF はフラッシュ時代の低遅延という、それぞれの持ち場があります。
  • ネットワークストレージの新しい故障モードは道の断絶で、マルチパスがその答えです。束ねたデバイスを使い、経路の状態を監視します。
  • クラウドのブロックストレージはこの構造の置き換えです。ネットワークの向こうという本質が、上限とレイテンシの特性として現れます。

次回 — GPU サーバー #

次回の「ハードウェア中級 #8 GPU とアクセラレータ — AI 時代の 5 つ目のリソース」では、シリーズの 4 つのリソースに 5 人目の客を迎えます。AI ワークロードの主役である GPU がサーバーの中でどう働くのか、VRAM がなぜ新しいボトルネックなのか、nvidia-smi の数字の読み方と GPU を分けて使う技術 (パススルー、vGPU、MIG) まで扱います。

X