Internet Infrastructure Review（IIR）Vol.55
2022年6月30日

3. フォーカス・リサーチ（2）

サービス基盤でのストレージに関する課題と対応

3.1 はじめに

IIJでは、2000年にクラウドサービス「IIJ GIO」の前身であるリソースオンデマンドサービス「IBPS」を開始した当時からサービス基盤にはストレージアレイシステムを採用しています。そして現在もIIJ GIOと自社サービス向けクラウド「次世代ホストネットワーク：NHN（Next Host Network）」においては、それぞれの基盤にストレージアレイシステムを採用しており、ストレージの容量は日々増え続けています。

本稿では、まずストレージについて理解を深めていただくために一般的なストレージについて紹介します。そして、お客様に安心してサービスをご利用いただくための取り組みとして、IIJがどのようなストレージ及びストレージネットワークを採用しているのかについて紹介します。

3.2 ストレージの一般的な話

3.2.1 ストレージとは？

ストレージとは、データやプログラムを保管するものの総称です。身近なコンシューマ向けストレージの例は、パソコンに入っているハードディスクドライブ（HDD）やソリッド・ステート・ドライブ（SSD）、データを持ち運ぶときに使うUSBメモリ、スマートフォンやデジタルカメラに挿入されているSDカード、CDやBlu-rayなど映像・音楽で使用されるメディア、ネットワーク対応HDDと呼ばれるNASなどが挙げられます。パソコンなどを長年使用し続けていれば、一度はHDDやSSDの故障によりパソコンが使えなくなった経験があるのではないでしょうか。

IIJのサービス基盤でも採用しているエンタープライズ向けストレージは、故障でストレージが止まることがないように、HDDやSSD、その他部品が複数搭載され、どれか1つ故障したとしてもデータの消失やストレージへのアクセスが停止しない可用性の高い構成となっています。このような構成のストレージを、「ストレージアレイシステム」や「ディスクアレイシステム」「エンタープライズストレージ」と呼んだりしますが、通常我々は単純に「ストレージ」と呼んでいます。

この節では、ストレージの部品として使用されるHDDとSSDに的を絞り、ストレージアレイシステムの仕組みや、ストレージアレイシステムとサーバを繋ぐネットワークについて解説します。

3.2.2 HDDとSSDの違い

HDDやSSDは、どちらもブロックストレージに分類されるストレージで、通常PCやサーバで利用する場合、インストールされているOSで使用するファイルシステムでフォーマットした後、利用するのが一般的です。

HDDは、プラッタと呼ばれる磁性体が塗布された円盤を高速回転させ、磁気ヘッドからプラッタにデータを読み書きします。プラッタと磁気ヘッドの隙間は人間の髪の毛の太さよりも狭いことから衝撃に弱く、動作中にHDDを移動させると故障することもあります。また、モーターなど機械的に駆動する部分があるため、これら駆動部分の動作不良もドライブ故障の要因となります。

HDDの速度はプラッタの回転数により決まります。ご存じのとおり、つい数年前まで販売されていたパソコンはストレージにHDDが使用されていたため、パソコンの電源を入れてWindowsなどのOSが起動するまで長く待たされるのが普通でした。このようにHDDは昨今のシステムにおいてボトルネックとなることがあります。この速度を高速化する製品として、最近はSSDを使用することが多くなりました。

SSDはフラッシュメモリと呼ばれる半導体素子を用いており、HDDと比較すると機械的な駆動部分がないため静かで衝撃に強く、発熱も比較的少なく、何よりHDDに比べると読み書き速度が高速です。SSDはHDDに比べると故障は少ない傾向ですが、使用しているフラッシュメモリの特徴として書き換え回数による寿命が存在します。

HDD及びSSDのコンシューマ向けとエンタープライズ向けの違いですが、エンタープライズ向け製品は、部品の精度や耐久性、寿命といった点でコンシューマ向けより上であるといえます。またエンタープライズ向けは出荷前にエージングを行って初期不良を排除するような製品もあるようです。

3.2.3 RAID

HDDやSSDに限った話ではありませんが、どちらも故障の要因が存在している以上、故障に伴うデータロストの可能性があります。このデータロストを防ぐ方法として、一般的なストレージ装置ではRAID（Redundant Array of Independent Disks）という手法を用いて、データの可用性を高めています。RAIDにはいくつかの種類があり、現在の主流は「RAID 1」、「RAID 5」、「RAID 6」です。

RAID 1は最低2台のドライブにデータをミラーリングし、どちらかのドライブに故障が発生してもデータを保護できます。RAID 5は最低3台のドライブを使い、パリティ（誤り訂正符号）をそれぞれのドライブに分散記録します。1台のドライブ故障までデータを保護することができ、2台壊れるとデータ破損が発生します。RAID 6は最低4台のドライブを使い、2種類のパリティをそれぞれのドライブに分散記録します。2台のドライブ故障までデータを保護することができ、3台壊れるとデータに破損が発生します。

余談ですが、データ保護の目的ではなくパフォーマンスを上げる目的の「RAID 0」があり、通常はRAID 0単体で使用することはなく、前述のRAID 1、RAID 5、RAID 6と組み合わせて使います。

RAIDは作成されたRAIDの領域から一部分、もしくは全体を使用してLogical Unit（LU）やVolumeを作成し、サーバにディスクデバイスとして提供するのが一般的です。

またRAIDはスペアドライブという機能を持っており、通常は未使用のドライブですが、ドライブ故障が発生したら自動的にデータを退避させる、もしくは残っているドライブとパリティから計算しデータをスペアドライブに復元させます。RAIDのスペアドライブ機能はずいぶん前から一般的に利用されている技術ですが、この構成の欠点として、ドライブ故障時にスペアドライブにI/Oが集中し性能低下が発生してしまいます。そこで、最近のストレージアレイシステムでは、搭載されているドライブすべてにスペアの領域を設け、ドライブ故障時の性能低下を軽減する機能を持つ製品も販売されています。

RAID 1は一番容量効率が悪く、次いでRAID 6、そしてRAID 5は一番容量効率が良いことが分かります。IIJで使用しているストレージでは、利用効率と可用性を加味し、RAID 5またはRAID 6を採用しています。

3.2.4 ストレージアレイシステム

ストレージアレイシステムは、ストレージの機能を司るコントローラと各種ドライブ・電源ユニットが複数搭載され、どれか1つ故障が発生したとしてもストレージへの読み書きが継続して行えるよう冗長構成になっています。通常ストレージアレイシステムとサーバなどを接続して利用するためには、ネットワークで接続する必要があり、データのやりとり方法の違いによってプロトコルが異なります。具体的には、ファイルアクセスに使用するプロトコル、ブロックアクセスに使用するプロトコル、Amazon AWSのS3などオブジェクトアクセスに使用するプロトコルがあります。このうちファイルアクセスとブロックアクセスに絞って解説します。

3.2.5 ファイルアクセスのプロトコル

まず、ファイルサーバ（NAS）など良く耳にするストレージについて解説します。NASで使用されるプロトコルの種類としては、UNIX/Linux系OSで使用されるNetwork File System（NFS）や、Windowsなどで使用されるServer Message Block （SMB）及びCommon Internet File System（CIFS）があります。一般的なサーバでファイルストレージを構成した場合、RAIDから切り出したボリュームをフォーマットし、その領域をNFSやSMBの共有設定により他のサーバでマウントして利用します。ファイルストレージの用途としては、Webサーバのコンテンツ格納や、各種アプリケーション間のデータ共有、オフィスでのファイル共有などがあります。

3.2.6 ブロックアクセスのプロトコル

次に、HDDやSSDと同様のブロックストレージをネットワーク経由で利用する方法があり、プロトコルの種類はiSCSIやFibre Channel（FC）、最近登場したNVMe over Fabrics （NVMe-oF）があります。主にブロックストレージとサーバを繋ぐネットワークをStorage Area Network（SAN）と呼び、FCを利用したストレージネットワークをFC-SAN、iSCSIなどイーサネットを利用したストレージネットワークをIP-SANと呼ぶのが一般的です。

iSCSIとFCについて簡単に説明すると、1993年にFCを用いた製品の販売が開始され、iSCSIについては2003年にIETFによってRFCとして公開され、その後製品が出荷されました。

iSCSIは、ストレージのプロトコルであるSCSIをイーサネットのプロトコルであるTCP/IP上で使用する規格で、専用のハードウェアを用意する必要はなく、イーサネットスイッチ及びサーバに標準搭載されているNICで構成することが可能です。ストレージ技術に長けている人であれば、ご家庭のネットワークでiSCSIを利用しているかもしれません。

FCは、ストレージのプロトコルであるSCSIを、ストレージ専用に設計されたFCの上で使用する規格で、専用のハードウェアが必要となり、スイッチはFCスイッチ、サーバにはFC-HBAが必要です。かつ、これら製品に対する専門知識が必要になります。

3.3 非常に大規模なFC-SAN

ブロックストレージとサーバを接続するプロトコルとして、「IIJ GIOインフラストラクチャーP2」及び「IIJ GIOインフラストラクチャーP2 Gen.2」では、サーバとストレージの接続にFC SANを導入しています。

2節で解説したとおり、FCは専用のハードウェアが必要かつ専門知識が必要となり、一般的にはハードルが高い印象ですが、IIJでは2003年から自社でFC-SANの構築及び運用を行ってきており、FC-SANとIP-SANの性質について理解し、それぞれの環境において適切に選択できるようになりました。

例えば、FC-SANを導入する理由として、FC-SANで使用するスイッチは、IP-SANで実現するには難しい機能を標準搭載しています。

3.3.1 マルチテナンシー

1つのネットワークに複数のシステムを収容する場合、IP-SANで各システム間のセキュリティを担保する方法として、イーサネットのVLANを利用しネットワークを論理的に分断することが一般的かと思います。図-1のように1つのシステムにそれ専用のストレージを接続する場合は特に難しい構成ではありません。しかし、図-2のように複数のシステムに単一のストレージを接続する場合、ストレージ側のインタフェースで複数のVLAN（VLAN Tagging、IEEE 802.1Q）をサポートする必要が出てきます。

現在販売されているストレージアレイシステムで、VLAN Taggingをサポートしている製品が豊富かというと、NAS製品については多数存在していますが、iSCSIなどIP-SAN向けの製品はごく少数しか存在しておらず、対応していてもVLAN数に制約があり、多数のシステムの収容が困難である場合が少なくありません。

次にFCについて説明すると、FC-SANを流れるプロトコルはイーサネットで使うプロトコルではなくストレージに特化されたプロトコルのみで、FC-SANの目線で見ると各サーバ間のセキュリティは保たれます。また、FCのセキュリティを高める方法として、図-3のようにストレージ（ターゲット）とサーバ（イニシエータ）を紐付けるゾーニングという機能を用いて、他システムが利用するストレージへのアクセスを遮断する方式を取っています。またイーサネットとは異なり、複数システムで単一のストレージを共有する場合は図-4のようにそれぞれのゾーニングを設定すれば良いだけなので、アレイシステムの選択に苦慮しません。他にFC-SANを使うと、サーバとストレージの間のIPアドレス設計が不要になることでしょうか。

また、この例ではFC-SAN、IP-SANとも、スイッチの台数は1台ですが、ストレージとサーバの間に複数台のスイッチがある場合、IP-SANはすべてのスイッチに対してVLANの設定が必要になるのに対し、FC-SANはゾーニング情報が接続されるスイッチすべてで共有される仕組みがあるため、どれか1台だけ設定をすれば良く、作業量を比較するとFC-SANの方が少なくなります。

3.3.2 ロスレスなネットワーク

FCは標準で高性能、低遅延、ロスレス伝送を実現します。イーサネットでは仮にパケットロスが発生した場合、TCPの再送制御を用いてデータの整合性を保っています。このような場合ストレージでパケットロスが頻発する環境下はストレージパフォーマンスの低下に繋がり、アプリケーションの動作に致命的な不具合が発生することもあるため、イーサネットでIP-SANを構成する場合はネットワークの設計などに注意を払う必要があります。

また、FCと同様のロスレスなイーサネットを構成する場合、Data Center Bridging（DCB）などの機能が利用できるスイッチ製品を選択すれば可能となりますが、追加でサーバのNICとストレージにDCBの設定を施すことが必要です。

3.3.3 FC Fabric

まずはスイッチ1台で構成した場合の構成です。小規模からスタートできるので、まずはこの構成をIIJでも採用していました。この構成の欠点は、サーバやストレージが増えてくると拡張が難しくなり、拡張しようにも大規模なメンテナンスを余儀なくされてしまうことです。

次にCore-Edge、Edge-Core-Edge、Full Meshの構成を図-6に示します。

拡大する

図-6 複数のスイッチを使ったFC Fabric Topology

Core-Edgeは、データセンターの1フロアでストレージ及びサーバが密集している場合においては有効となる構成で、GIO P2の一部、GIO P2 Gen.2で採用しています。図-6ではFCスイッチ間を1本のケーブルで接続しているように見えますが、実際は1本切断しても影響を軽減するために2本以上で接続しています。これは、FCスイッチに備わるInter Switch Link（ISL）という機能を用いており、イーサネットスイッチのPort Channelと似た機能ですが、イーサネットスイッチとは異なりFCスイッチにISL Trunkライセンスが投入されていればひとまとめのLinkに自動設定されます。例えば32GbpsのFCスイッチ同士で4本をISL Trunkで接続する場合、スイッチ間の帯域は32 x 4 = 128Gbpsとなります。

Edge-Core-Edgeは、データセンターの複数フロアにストレージ及びサーバが分かれて設置されている場合に採用しています。例えば、Coreの近くにストレージが設置できない状況において、ストレージ用Edgeスイッチを配置してCoreと接続する必要があるといった理由によります。また、大規模になるとEdge-Core-Core-EdgeというCoreを別々のフロアに設置する構成もありますが、その場合Core間のトラフィックが多くなると見込めますので、ISL Trunkの本数を予め多めに設計するよう心がけています。

Full Meshは、小規模な構成でデータセンターのラックにストレージ及びサーバが混載されている場合に採用しています。
Full Meshの特筆すべき点は、通常のイーサネットスイッチでFull Meshを構成する場合、高度な設定を要する場合が多い点です。FCスイッチでは自動的にストレージ～サーバの経路を適切に設定する機能があるため、この構成にしたとしても特別な設定は不要となり、非常に簡単に構成を組むことが可能です。

3.3.4 FCのファブリックサービス

FCスイッチではファブリックサービスがあり、これはFC-SANに接続されているすべてのデバイスや、サーバとストレージを接続するために必要な情報を管理します。ファブリックサービスのほんの1例を挙げると、ストレージとサーバを繋ぐゾーニングを適切に設定していれば、サーバに特別な設定をせずともストレージと自動的に接続する仕組みです。IP-SANに同様の機能はInternet Storage Name Service（iSNS）として存在はしていますが実装は限定的で利用されている環境はほぼありません。そのため、IP-SANではサーバに接続対象のストレージを記憶させて接続させる方法を取ります。違いをまとめたのが図-7です。

拡大する

図-7 FC-SANとIP-SANの接続形態の違い

例えばサーバ台数が数台程度であるなら、FC-SANもIP-SANも接続するためのオペレーションの量に大差はないと思いますが、サーバ台数が数十台～100台のような環境の場合、すべてのサーバに接続対象のストレージを記憶させる必要があるため、サーバを管理しているエンジニアの作業量は多くなる傾向です。

3.3.5 FC-SANを選択する判断基準

運用面では、FCスイッチのファームウェアバージョンアップ時にFCのトラフィックを止めずにバージョンアップができる機能や、スイッチの各PortでSFP+モジュールの障害やケーブルの劣化によるエラーカウントが一定数超えた場合に強制的にPortをオフラインし、これ以上FC Fabricに悪影響を与えないようにする機能があります。

これらを鑑みて、IIJでは現状ストレージアレイシステムを複数のシステムで利用する要件がない場合はFC-SANもしくはIP-SANどちらでも良く、複数のシステムで共用利用をする要件がある場合はFC-SANを選択するのが望ましいという判断基準をもっています。

しかし将来IP-SANで利用するストレージアレイシステムでVLANなどの対応が柔軟になった製品が増えていく場合、100Gbps以上の伝送速度をもつイーサネットを利用したIP-SANに軍配が上がると予想されるため、今後の判断基準は変更になる可能性もあります。

3.4 運用技術について

IIJではストレージを安定運用するために、以下のような取り組みを行っています。

3.4.1 サービス提供の自動化

「IIJ GIO」で、お客様からストレージを利用したいという申し込みがあった場合、2010年頃まではストレージをメインで運用しているエンジニアがストレージ及びFCスイッチの設定変更を行っていました。この頃まではストレージの設定変更を行う業務は多くても週に1回程度と頻度が少なかったため、エンジニアによる手動の設定変更でも十分期限に間に合いました。

しかし、2010年を過ぎると週に1回の業務が週に数回、更には1日に数回発生するようになり、人手を介して作業するのが困難になると予想されたため、ストレージの設定変更をすべて自動化するようなシステムを設計・構築しました。

ストレージ設定の自動化を行うためには、市販のアプリケーションなどを利用すれば簡単なのですが、市販のアプリケーションはストレージの自動化だけでなく、それ以上の機能を有するものが多く（かつ高価なため）、ストレージを制御する部分は自作としました。

ストレージ制御はPythonやRubyなどの言語を使って記述しています。本来、各種言語からストレージの構成変更を行う場合、ストレージ管理の仕様であるStorage Management Initiative - Specification（SMI-S）や独自APIを経由して構成変更を行うことが望ましいのですが、当時使用していたストレージやFCスイッチそれぞれ単体ではSMI-SやAPIに対応しておらず、別途専用の（高価な）アプリケーションが必要であったため、標準でストレージを制御するコマンドラインを使用しました。

コマンドラインの入出力は人間が確認することには長けていますが、各種言語で結果から適切な値を取り込むには非常に扱いづらい形式で出力されているため、作成したプログラムも相当面倒な文字列処理を使う必要がありました。また、使用していた機器の一部は、コマンド及びパラメータに誤りがあってもリターンコードが0（正常終了）を返すため、独自のエラー処理を追加する必要もありました。

最も手間がかかるのは、ストレージアレイシステムやFCスイッチのファームウェアをバージョンアップする際です。バージョンアップ後のコマンドライン出力結果がバージョンアップ前と比較して若干の変更が発生する製品もあり、本番でバージョンアップする前に開発環境で事前のテストを行う必要がありました。

最近のストレージ及びFCスイッチは、構成管理を行うソフトウェアであるAnsibleなどの対応が進んできていることから機器単体でのAPI実装が進み、かつ、Pythonなどでストレージ制御に使えるモジュールを各ストレージベンダーが提供するようになったため、当時と比べると非常に簡単にプログラムを組むことが可能となっています。

3.4.2 ストレージ基盤の監視

ストレージシステムの監視方法として、ping、syslog、SNMPなどを利用して監視を行うほか、メーカ独自の監視ツールを利用して、メーカから遠隔の監視を行う方法があります。当初はIIJが提供している監視サービスを利用して監視を行っていました。その頃はストレージ1台に接続されるサーバの台数も少ないため、この方法でも障害発生からストレージ運用チームが障害を認知するまで時間はかかりませんでした。

しかし、規模が大きくなると1台のストレージに接続されるサーバの台数も増え、そのストレージに障害が発生すると、1つの障害に対しIIJの監視サービスで検知するアラートの数が数百件を超えることが発生、ストレージ運用チームが障害を認識する時間がかかるようになりました。

そこで、ストレージ運用チームで独自の監視システムを構築し、ストレージシステムのアラートを直接ストレージ運用チームに通知する方式としました。これにより、数十分かかっていた障害検知を数分レベルに短縮することができました。

3.4.3 データ移行

ストレージアレイシステムに搭載されているHDDやSSDは、おおむね5年間ほど連続稼働すると故障の頻度が増えてきます。IIJでは、1台のストレージアレイシステムの利用期間が5年を経過する頃に機器の入れ替えを検討しています。その際に避けて通れないのがデータ移行です。

この方法は非常に単純でIIJでもよく利用していましたが、常時ストレージに対して書き込みが行われる環境では1回だけの移行ではファイル全体の不整合が発生してしまいます。そこでIIJでファイル単位のコピーを行う際は、複数回にかつ数日に分けて移行する方法をとりました。具体的な方法としてはまず全体をコピーし、その後1日おきに差分でコピー、平行して書き込みが頻繁に行われるディレクトリを特定し、最後に書き込みを止めるためにアプリケーションを停止し、最後に書き込まれたファイルのみをコピーして移行します。

次に、物理サーバなどで論理ボリュームマネージャを使っている場合は、その論理ボリュームマネージャの機能を使って移行します。移行の流れは図-9のとおりです。

拡大する

図-9 論理ボリュームの機能で移行

論理ボリュームマネージャの知識は必要になりますが、データの移行方法としては前述のファイル単位で移行する方法よりも影響が少なく済んでいます。また、ストレージ上で動いているアプリケーションへの影響も、若干の性能低下はあるものの、大幅な性能劣化はありません。具体的な例としては、LinuxやHP-UXで利用している論理ボリューム（LVM）を用いて移行元ストレージと移行先ストレージでミラーを一時的に組んで同期が取れたら移行元ストレージを切り離すという方法や、Linuxに限定するとLVMのpvmoveコマンドを用いて移行する方法などが挙げられます。

ただし、もともと論理ボリュームマネージャを使用していない環境では、この方法を用いることはできないため、そのような環境では前述のファイル単位の移行を行うほかに、後述するストレージの移行機能を用いるしかありません。

最後にストレージの移行機能を使う方法です。移行の流れは図-10のとおりです。

拡大する

図-10 ストレージの機能で移行

昨今のミッドレンジクラス以上のストレージには、同機種もしくは同系統のストレージ間でデータ移行ができる機能を備えた製品があり、一部では異なるベンダー間での一方向データ移行を行える製品も出てきました。この方法を使うと、ストレージを使っている環境に左右されず、ほぼすべてのデータ移行を行うことが可能です。ここでの注意点として、例えば移行元ではFCを利用し移行先でiSCSIを利用したいなど、サーバとストレージ間のプロトコルを変えることはできず、移行元と移行先で同じプロトコルを利用することが前提です。また、ストレージを利用している環境によっては、移行作業の前後でサーバの停止を必要とする場合もあります。

3.5 まとめ

本稿では、IIJのストレージの取り組みの紹介として、一般的なストレージ機能、ストレージアレイ及びストレージネットワーク採用の技術説明、ストレージ運用技術について述べました。IIJでは引き続き、お客様にストレージを安心かつ確実にご利用いただけるように努めてまいります。

3. フォーカス・リサーチ（2） サービス基盤でのストレージに関する課題と対応

• 3.1 はじめに
• 3.2 ストレージの一般的な話
• 3.3 非常に大規模なFC-SAN
• 3.4 運用技術について
• 3.5 まとめ