SANを検討すべき時期は？

誰もがSANの購入に飛びつきたがっているようで、時には非常に熱心です。SANは確かにかなりクールです。ほとんどのITプロフェッショナルが自分のショップで手にする機会のある、より楽しくエキサイティングな大規模ハードウェアの一つです。自分のSANを持ちたいという欲求は、SANの使用がある種のステータスシンボルになっているという「ジョーンズ家に追いつく」という問題であることが多く、大企業のITとして専用のサーバールームにしか見られないものとなっています（まあ、ほとんどの場合）。SANは大々的に宣伝・販売され、内部冗長性により無敵とされ、論理を超えたスピードを持ち、必要性を知らなかった機能で満載であるとされています。新しいシステムを設計するITプロフェッショナルと話す際、最もよく聞くデザインの一つは「最終的な設計についてはよくわからないけど、SANが必要なことはわかっている」というものです。

この記事の文脈では、SANという用語を最も一般的な意味、つまり「ブロックストレージデバイス」を意味するものとして使用し、ストレージネットワーク全体を指すものではありません。ストレージネットワークはNASのために存在することもできますが、SANブロックストレージデバイスをまったく使用しないこともあります。したがってこの記事では、SANはデバイスとしてのSANを指し、ネットワークとしてのSANを指しません。SANは異なる場面で複数の意味を持つ曖昧な用語であり、かなり混乱を招くことがあります。ネットワークなしで構成されたSANはDASになります。ネットワーク化されたDASはSANになります。

少し立ち止まりましょう。SANはバックエンドストレージです。その必要性は、すべての場合においてアーキテクチャの他の側面によって決定されます。他の多くの要素をまだ決定していない場合、最終的な設計においてSANが必要になるかどうか、あるいは有用であるかどうかさえ知ることはできません。危険信号です。至るところに危険信号があります。馬がチャリオットを押しているローマのチャリオットレースを想像してください（意味がわかれば）。

SANを実装したいという意欲は非常に強く、しばしばプロジェクト全体がSANの購入を正当化する以外にほとんど目的がないように見えることがあることは明らかです。どのプロジェクトでも、まず問わなければならない質問は「私たちが満たそうとしているビジネスニーズは何か？」です。そこから作業を進めるべきであり、「SANを購入したい、どこで使えるか？」という発想から進めるべきではありません。SANは複雑であり、複雑さには脆弱性が伴います。SANは多くの場合、高コストです。しかしSANの最も恐ろしい側面は、SANに関する深い業界知識が広く欠如していることです。SANは、その使用を正当化するために克服しなければならない大きな技術的・ビジネス的リスクをもたらします。SANは疑いなく非常にエキサイティングで非常に有用ですが、それだけでは望む理由として十分であることは滅多にありません。

私たちはSANを「最後の手段のストレージ」と呼んでいます。これが意味することは、ストレージの種類を選択する際、ローカルドライブ、DAS（Direct Attach Storage）、NAS（Network Attached Storage）などの他の代替手段を使用できることを望むということです。ほとんどの場合、他のオプションは見事に機能します。しかし、ビジネスニーズがSANでしか合理的に満たせない要件を求める場合があります。そのような場合は選択の余地がなく、SANを使用しなければなりません。しかし一般的には、より単純で通常はコストが低くリスクの少ないオプションを支持してSANを避けることができます。

SANを実装しようとしているほとんどの人が、多くの誤解のもとにそうしていることがわかります。

第一の誤解は、SANはその性質上、信頼性が高いというものです。確かに非常に信頼性の高いSANベンダーや特定のSAN製品がありますが、同じことはどのIT製品についても言えます。高価なSANと同価格帯の高エンドサーバーは、SANと同程度の信頼性を持っています。SANは通常のサーバーと同じハードウェアコンポーネントで構成されているため、より信頼性を高めるための魔法はありません。SANを信頼性の高いものにするために使用できるものはすべて、サーバーのRAS（信頼性、可用性、保守性）技術のトリクルダウンです。SANと同様に、NAS、DAS、ローカルディスクも非常に高い信頼性を持たせることができます。SANは他のタスクを実行するのではなく、ブロックストレージを提供するために使用されるデバイスを指すだけです。SANはただの非常にシンプルなサーバーです。SANは信頼性の全範囲をカバーしており、最高端ではメインフレームに匹敵する信頼性から、最低端ではネットワーク上で最も信頼性の低いデバイスである外付けハードドライブ程度のものまであります。したがってSANが信頼性を意味するのではなく、実際には最低の信頼性を想像できる特別なケースをいくつか提供します。しかし実際の目的においては、すべてのサーバーは概ね同等の信頼性上の懸念を共有しています。SANが信頼性の評判を得ているのは、多くの場合ビジネスがサーバーには投じないような極端な予算をSANに投じ、比較的高エンドのSANと比較的廉価なサーバーとの比較になるからです。

第二の誤解は、SANは「大きい」でNASは「小さい」というものです。そのような関連性はありません。SANとNASはどちらもほぼあらゆる規模や品質で存在できます。どちらも多様であり、選ばれた技術からデバイスが大きいかどうかを示すものは一切ありません。また上記のように、SANはその可能な単純さのために技術的にはNASソリューションより「小さく」なることもありますが、これは特殊なケースであり、ほとんど理論的です。ただし、この カテゴリーに入るSAN製品は市場に存在しますが、実際に使用されているものを見つけるのは非常にまれです。

第三の誤解は、SANとNASはシャーシ内部で劇的に異なるというものです。今日のSANおよびNASデバイスの大多数が「ユニファイドストレージ」と呼ばれるもの、つまりSANとNASの両方として同時に機能するストレージアプライアンスであるため、これは確かに当てはまりません。これは、2つの主要な違いがバックエンド技術、ハードウェア、サイズ、信頼性ではなく、ストレージを転送するために使用されるプロトコルにあることを示しています。SANはブロックストレージであり、ファイバーチャネル、iSCSI、SAS、ZSAN、ATA over Ethernet（AoE）、Fibre Channel over Ethernet（FCoE）などのプロトコルを使用してネットワーク上に生のブロックデバイスを公開します。一方NASはネットワークファイルシステムを使用し、NFS、SMB、AFP、HTTP、FTPなどのアプリケーション層プロトコルを使用してネットワーク上にファイルを公開し、それがTCP/IP上で実行されます。

第四の誤解は、SANは本質的にファイル共有技術だというものです。それはNASです。SANは単にブロックストレージ（ハードディスクサブシステム）を取ってネットワーク上でリモートから利用可能にするものです。ネットワークの性質上、そのストレージを複数のデバイスに同時に接続できることが示唆されており、実際に物理的には可能です。以前はSCSIリボンケーブルの両端に複数のコントローラーを物理的に接続し、中間にハードドライブをぶら下げることができたのと同様です。これは通常の状況では、互いのことを知らないコントローラーが互いのデータを上書きし、ほぼ即座に破損を引き起こし、ドライブ上のすべてのデータを破壊します。特殊なクラスター化ファイルシステムとそのドライバーにはこれを可能にするメカニズムがありますが、これにはSANを取得する多くの人々が、SANの最大の目的だと思っていることに必要とは知らない特別な知識と理解が必要です。SANは、ほとんどの人々がSANが設計されていると信じているまさにその使用ケースをリスクにさらし、求められるほぼ魔法のような保護を提供するどころか、逆にデータ損失の原因となります。これは、理解されていないストレージ技術を実装することがもたらすリスクのレベルを浮き彫りにしており、私はほぼ毎週誰かがこれを行った事例と話しています。

第五の誤解は、SANは高速だというものです。SANは高速であることもあれば、恐ろしく遅いこともあります。SAN技術を使用するだけで本質的な速度向上はありません。SANが置かれているネットワークによって生じる本質的なボトルネックを克服することは実際かなり困難です。DASなどの他のストレージオプションはSANと同じ技術をすべて使用しますが、実際のネットワークのボトルネックとレイテンシーがないため、同等のDASはそのSANの補完製品よりもわずかに高速になります。SANは一般的に同等のハードウェアのNAS製品より少し高速ですが、これも保証されているわけではありません。SANとNASは異なる動作をするため、異なる使用ケースではどちらかがより良いパフォーマンスを発揮することがあります。SANがパフォーマンスニーズに基づいてソリューションとして選ばれることはほとんどありません。

第六の誤解は、SANを使用することでストレージ選択に関連する本質的な問題がもはや適用されなくなるというものです。良い例はRAID 5の使用です。これはサーバーで行うには悪い慣行と考えられますが、SANを使用する場合（理論上はスタンドアロンサーバーよりもはるかに重要）、SANであることがこれらの問題を何らかの形で解決したか、あるいはそれらが適用されないという信念に基づいてストレージサブシステムの慎重な計画がしばしば省かれます。一部の高エンドSANには他では見られないリスク軽減機能がいくつかある場合もありますが、これらはまれであり、脆弱な設計がすでに一般的でない非常に高エンドなユニットに限られています。物理サーバーのストレージを計画する際には細心の注意と考慮を払うが、SANを使用する場合はSANが内部的にそれらをすべて処理するか単に必要なくなったという前提に基づいて、同じ計画と監視がスキップされることは危険ですが非常に一般的な慣行です。

SANに関する多くの誤解を打ち砕いた後、SANが適切な場合があるのかと思う方もいるでしょう。もちろん、正しく使用された場合には非常に重要で非常に価値があります。SANの最も強みとなる点は、統合と特定種類の共有ストレージにあります。

統合は、歴史的にお客様をSANソリューションに引きつけた原動力でした。SANにより、多くのファイルシステムを単一のディスクアレイに統合でき、ストレージリソースのより効率的な使用が可能になります。SANはブロックレベルであるため、従来のローカルディスクサブシステムが使用できる場合はいつでもこれを行うことができます。多くのサーバー、さらには多くのデスクトップでも、成長、計画、ディスク容量の粒度の必要性により、ストレージスペースが無駄になっています。各サーバーが300GBのドライブアレイを持ちながらそれぞれ80GBしか使用していないサーバーが20台あれば、大きな無駄が生じます。SANがあれば、わずかなオーバーヘッドを除いて1.6TBに統合でき、各サーバーが独自のストレージを維持している場合よりも物理ディスクに費やすコストを大幅に削減できます。

ストレージを統合し始めると、さらなる統合の機会を探し始めます。多くのサーバーファイルシステムを単一のSANに統合することで、SANの実装がサポートしている場合、そのデータを重複排除して圧縮する機会が生まれ、サーバーファイルシステムなど多くの場合に大幅な使用率削減がもたらされる可能性があります。上記の例の1.6TBが実際には800GB以下になるかもしれません。突然、統合の数字がどんどん良くなっています。

統合を効率的に活用するには規模が必要であり、これがSANが本当に輝く場面です。容量と、さらに重要なことに、接続ノードの数が非常に大きくなる場合です。SANは大規模なストレージ統合に最も適しています。これがSANの得意分野であり、大企業ではほぼ遍在していながら、小規模な企業では非常にまれな理由です。

SANはまた、単一の共有ファイルシステムアクセスを必要とする特定種類のクラスタリングと共有ストレージにも非常に重要です。これは実際には一つの特別な状況を除いてかなりまれなニーズです。その特別な状況とはデータベースです。ほとんどのアプリケーションは提供されたあらゆる種類のストレージを使用して満足していますが、データベースは自分のデータを最も効果的に操作するために低レベルのブロックアクセスを必要とすることが多いです。このため、NASやファイルサーバー上では使用できないか、効果的に使用できないことがあります。データベースクラスターのための高可用性ストレージ環境の提供は、SANストレージの主要な使用ケースとして長い歴史があります。

大多数のSANインストールを正当化するこれら二つの主要な使用ケース以外に、SANはまた物理的な移動や複雑な調達とプロビジョニングなしに大規模な環境でストレージを移動、拡大、変更することを潜在的に非常に簡単にする高レベルのストレージ柔軟性を提供します。ここでも統合と同様に、これは大規模環境の産物です。

非常に大規模な環境では、SANの使用はまた、ストレージとシステムエンジニアリングチームの間に境界線を設けるポイントを提供でき、ネットワーク層（一般的にファイバーチャネルまたはiSCSI）での引き渡しが可能になります。この明確な職務分担は、高度に離散的なストレージ、ネットワーク、システムチームを望む会社においてチームを高度に分離させることを可能にするために重要です。これにより、ストレージチームはストレージだけに集中でき、システムチームはシステムだけに集中でき、相手のチームの実装について知識を持つ必要がなくなります。

長い間、SANはまたストレージパフォーマンスを向上させる便利な手段として自身を提示してきました。これはSANの本質的なコンポーネントではなく、統合のための一般的な使用の副産物です。仮想化を統合として使用する場合と同様に、共有SANは利用可能なスピンドルのより良い利用率、集中化されたキャッシュ、多くの個別サーバーに分散した同等のストレージよりも大きなハードウェアという自然な優位性を持ちます。共有CPUリソースと同様に、SANが複数のクライアントからのリクエストを受信していない場合、単一のクライアントのリクエストにすべての容量を専念させる能力があり、個々のサーバーが単独で手頃な価格で達成できるものよりも潜在的にはるかに高い平均パフォーマンス体験を提供します。

しかし、パフォーマンスのためのSANの使用は急速に廃れてきています。これはSSDストレージが非常に一般的になってきたためです。非常に低レイテンシーと高IOPSパフォーマンスを持つSSDの価格が下がり、スタンドアロンサーバーにローカルキャッシュとして追加されたり、メインラインストレージとして使用されたりするようになるにつれて、SANのネットワークのボトルネックはますます大きな要因となり、SANの統合メリットがローカルSSDのパフォーマンスメリットを相殺することがますます困難になっています。SSDはローカルストレージ側にパフォーマンスの優位性をもたらすため、共有ストレージ市場にとって潜在的に非常に破壊的な存在です。これはストレージアーキテクチャ設計の満ち引きの中で最新のものにすぎません。

SAN使用において覚えておくべき最も重要な点は、SANはストレージ計画のデフォルトの出発点であるべきではないということです。SANは多くの技術的選択肢の一つであり、意図したとおりに機能しないことが多い選択肢であるか、機能するとしても金銭的または複雑性の観点から不必要に高いコストを伴うことが多い選択肢です。ビジネスの目標とニーズを定義することから始めましょう。SANがそれらのニーズを最も効果的に解決する場合にSANを選択しますが、オープンマインドを保ち、環境の全体的なストレージニーズを考慮してください。