管理者の負担が減る　Software Defined Storageの利点を考える

最近IT業界では、Software Defined○○で始まる用語をよく聞きます。

ソフトウェアにより定義、制御をする○○という意味合いですが、現場の視点からするとどのような利点があるかを考えてみたいと思います。

話を具体化する上で、今回はSoftware Defined Storageをベースに話をします。
VMwareで言えばvSANが該当製品ですね。

f:id:instructor8010:20170325212649p:plain

”ソフトウェアにより定義、制御するストレージ”、漠然としていてわからないという人も多いと思います。

逆にハードウェア制御のストレージと言うと何があるかというと、次のようなものが該当します。

ハードウェアRAIDコントローラー
SAN ストレージ(iSCSIやFibre Channel)

（新しいDell EMCのベゼルかっこいいなぁ・・・）

これらを使ったことがある人は、こんな悩みがあるのではないでしょうか？

RAIDレベルを変更したいが、既存のRAIDボリューム上のデータを移動させないといけない
或いはオンライン変更が出来てもパフォーマンスがその間落ちたり、失敗リスクを想定せざるを得ない
(バックアップ時間、バックアップ先の準備、リストア後のデータマウントなどを考慮する必要がある)
データ保存時に、データ単位で必要なRAIDレベルをアサインしづらい
単一のRAID LUNしか持たないサーバーの場合、優先度が低いデータをRAID10のような高価なスペースに保存しないといけないケースが生まれる(つまりスペースの非有効活用)
これを打開するにはもう一つ別のRAID5や6のLUNを作る必要が出てくる。そうなるとLUNの管理タスク、パスマネジメント、追加ディスクの用意などの工数が増える
SANストレージを取り扱うのに、専用のツールの操作性を身につける必要がある
ストレージの操作GUIはベンダーで違う場合が多く操作に慣れるのが大変
また先日まで使っていたストレージ管理ソフトも、ファームウェア更新などがきっかけで、
UIが変化するケースなどもあり、管理者間で操作手順を共有するのも手間になるケースがあります
マルチベンダー環境の場合SANストレージごとの機能特性を覚える必要がある
スナップショット、レプリケーションなどの機能はベンダーを超えて一般化されましたが、同一の機能とは言えベンダーごとに微妙な機能差や特性を把握する必要があります
SANストレージの場合、ラック背面のケーブルが増え、ケーブルマネジメントタスクが増えます
Fibre Channelの場合は、Fibreスイッチのマネジメント工数が増え、イーサネット環境のみサポートしてきたエンジニアからすれば新しいスキル学習を余儀なくされます
IT管理者は製品ごとに分けられている場合、トラブル応対はもちろん、サーバーやストレージのデプロイに時間がかかるケースがある
トラブル発生時は、製品担当範囲が責任分界点となる
多くの製品ドメインが存在するIT環境の場合、社内調査などでも自分の範囲外の事は調査ができず、トラブルへの応対スピードが長くなってしまう

また新規のLUNをサーバーにマウントしたい場合、まずサーバー管理チームからストレージ管理チームに新規LUNの切り出しを依頼
その後承認を受けてからサーバーにマウントが出来るようになりますが、この意思決定や承認取得などで時間がかかる場合がある。ビジネスはスピードが命ですがここがボトルネックになると言えます
そもそも管理者が少人数しかおらず、一人で担当する製品が多すぎて十分に製品を理解できないまま不安を抱えて管理業務を行っている
一人あるは少人数で出来る事、覚えられることは個人差はありますが限度もあります

もちろん、これらの悩みを社内ルールなどでカバーが出来る、許容出来る仕組みがあれば、SANストレージは大変素晴らしいソリューションです。

ですが、こうした悩みを抱えつつ日々を過ごす方も0ではないと思います。

そこでSoftware Defined Storage、vSANを使えばどうなるか？次のようになると予想できます。

RAIDレベル変更は、オンラインで変更可能です
複数のディスクをネットワーク経由で、単一のプールに合体させる仕組みであり、
中に保存するデータごとに"RAID1ポリシー"や"RAID5ポリシー"を設定出来る
つまり複数のLUNを管理する必要性が無くなる

簡単に手書きしてみました。初めての方にイメージを掴んでもらうため書きました。
ですので本来のvSANを説明するためにはもう少し加筆が必要な絵ではありますがご容赦ください。
また、長文記事になるのを避けるため、色々前提条件を省いても居ますのでこの点もご容赦願います。

VM Aは重要度が低く、ダウンしても問題ない開発環境用のVMだとします。
こうした場合、RAID 0ポリシー(耐障害性無し)を適用することで、プール化されたデータストア内にVM A用のデータが1つ配置されます。

VM Bは重要度が高く、本番環境であり、ダウンが許容されないので冗長構成が必要だとします。
こうした場合、RAID 1ポリシー(障害1つまで対応可能)を適用することで、プール化されたデータストア内にVM B用のデータが2つ配置されます。
また、このデータストア内の2つの赤いデータは、複数のホストに配置されるため、単一ホストレベルの障害が起きたとしても、VM Bは保護され、結果稼働を継続出来るというイメージです。

図には存在しませんが、RAID 5などのルールを設定したい場合は、新たにポリシーを作成し、
新たに作成されるVM Cに紐付けても良いですし、既存のVM Aに紐付ける場合は、データストア内部で動的にVM A用のデータがRAID 0からRAID 5に変換され、複数の青いデータが作成され、ノードごとに配置される動きとなります。
(vSAN 6.5の段階では、RAID 5/6はErasure Codingと呼ばれ、最低ノード数がRAID 5だと4台でRAID 6だと6台ですから、この図にはあと追加のサーバーノードは必要です)
ストレージの操作は、vSphere Web Clientを使用するため、新しいツールを覚える必要が無い
極端に言ってしまえば最低限のインフラ管理であればサーバーの管理ツール、ネットワークの管理ツール、vSphere Web Clientの3つで環境管理はまとまってしまうと言えます
vSphereではスナップショットやレプリケーションも利用可能である、高価なストレージを用意しなくても良くなる。またどのベンダーを選んでも、VMwareベースのこれらの機能が使えるのでVMwareの機能特性を把握しておけば良い。
管理対象ケーブルが減る場合がある
SANストレージを利用しないため、ケーブルはサーバーから伸びる電源ケーブルとネットワークケーブルのみとなる。
サーバー管理者のみで管理が出来るので、ストレージ管理者を介在させる必要がない
覚える製品が減るため、管理者の技術的不安が減る