物理ストレージディスク全体から論理的に容量の切り分けを行なってデータ保存用領域を作成する方法としてLUN(論理ユニット番号)の話を以前した。
今回はそのLUNはどのような仕組みで作成されるのか、ということについて触れたい。作成の方法は大きく2つある。
シックLUNとシンLUN
・シックLUN：将来的な容量の需要を踏まえて大容量のスペースをあらかじめ確保した形で作成されたLUN
・シンLUN：はじめはいったん最低限の容量を確保した形で作成されたLUN
シックLUNとシンLUNの作成はエンタープライズ向けストレージ製品に搭載されているソフトウェアやWindows、LinuxのようなOSでも対応しているため、他のソフトウェアを準備・用意する必要はない。
シックLUNとシンLUNの大きな違いは、途中からの容量拡張の部分にある。
シックLUNの場合は例えばストレージディスクの追加などで容量の拡張をする際、既存データの事前バックアップがまず推奨されて、LUNを使用している仮想マシンの再起動が必要になるなど途中での容量拡張に手間が影響が大きすぎるに対して、シンLUNはストレージ領域さえ余裕があれば途中からの容量拡張に弊害は少ない。
容量の上限に達してしまったら
シックLUNでもシンLUNでも容量の上限に達した場合は、当たり前だがデータ書き込みの処理はできなくなる。
データ読み取りに関しては基本的に可能だが、T10 SCSI unmapコマンド(削除したブロックからスペースの再利用が実現できる)がサポートされていないホストOSでは、LUNがオフラインになった際のデータ読み取りが不可になる仕様となっており、NetAppではストレージでシンLUNを利用する際はこのリスクに注意するような案内を入れるようにしている。
管理用GUIツールで各LUNの容量利用状況が確認でき、容量が上限に達する前段階で通知を飛ばす機能もあるので気づかないうちに容量が上限に達していた、ということはないはず。それでもいかなる状況でもデータ読み取りができ、ストレージリソースを効率的に使えるシンLUNの作成の方がユーザにとってメリットは大きいだろう。
シンLUN一択なのか
ではもうシックLUNの出番はないのか、と言うとそうとも限らない。シンLUNは基本的にRAID6によって作成されるLUNでストレージ容量効率がアップする反面、それなりの本数の物理ストレージディスクを必要とする。
効率的でないかもしれないが、あらゆるRAIDタイプからLUNの作成ができるシックLUNの方が選択肢が広がることもある。
またシックLUNはあらかじめワークロードの予測がつくようなサービスにおいては高いパフォーマンスを発揮できる。シンLUNの場合は仕様上、パフォーマンスにばらつきが出やすいデメリットがある。複数のシンLUNが共有ストレージリソースを競合するようなことがあればパフォーマンスの低下を招くことがあるからだ。
使うアプリケーションがどういった性質を持っているのか。それを踏まえてどのLUNを使うのかを考えていく必要がある。
ひとりごと
東京優駿(日本ダービー)はクロワデュノールが優勝。出走馬の中で力が抜けた存在だったため順当な結果と言えると思う。
クラシック第1戦の皐月賞でレースそのものが破壊されてしまい、そこでクロワデュノールが敗れたため、ダービーは直前までは群雄割拠の様相を呈していたが、実際は1強の勢力図だった。
それはレース前の最終オッズにも反映されていたので、事前の見方と比べて思ったよりも配当がつかずに拍子抜けした馬券的中者もいたのでは。
東京優駿が終わった瞬間に本格的な夏の到来を感じる。今夏も暑くなるみたいです。