【Ask the Expert】エキスパートに聞こう！ストレージの原則と技術

さあ皆さん、

エキスパートに聞こう！2014年最初のテーマは「基本に戻ろう」です。

『ストレージの原則と技術』を題材とはしていますが、今までなかなか聞きにくかったこと、いつも使っているけど実は

説明しろと言われるとむずかしい・・・などストレージにまつわることならなんでもここで話しましょう！

知らない事は恥じゃありません！むしろはじまりなのです。

上原です。

ストレージ業界に入ってからサポートで約5年間電話を取りまくり、ほぼ全てのEMC機器に関わりを持った後、VNXeのサポートを経て現在フォーラムの運用を行っています。（そして日頃のフォーラム対応を時々ブツブツとhttps://twitter.com/ueharausでつぶやいてます）

EMCで働きはじめて最初に感じたことは「基本を知っていても、理解をしていないとエンジニアの人達と話をするのが難しい」ということでした。

ストレージ関連の言葉が会話に出てきて、どこかに書いてあったのをなんとなく覚えてはいるのだけれども、きちんと理解していなかったりするとそこで思考停止が起きたりします。（これはスポーツで言う「体で覚える」に近いのかもしれないなぁなんて時々思ったりします。）

そして、ストレージの技術に関してはネットや本屋さんで見つけることが（比較的）難しいために、基本を理解するのに結構苦労したことも覚えているので、今回は少しでも基本の理解の手助けになれたらいいなぁと考えています。

ちなみに僕はストレージ業界に来てからしばらくして、先輩に質問した時に

「おまえの言っている意味がわからない。きちんと質問をしたらきちんと答えてやる。こっちは忙しいんだ」

と言われて「きー」とか言っていた人間なので、どんな質問に対しても冷たくは返さないように心掛けてるつもりです（と語尾がだいぶ弱くなってしまったかも）。

なので、「質問をしたいのだけれども、そもそも○○の理解が困難で質問ができない。○○って一体何？」というような質問は大歓迎です！（実際のところかなりテクニカルな質問をされるよりも歓迎です。多分答えられないし。）

とりあえず今回は2週間という決められた期間ですが適当に思いついたことを書き込んでみてもらえると嬉しいです。

ディスクドライブの構成要素として出てくるものの中で、トラックとセクタがあります。

そして、それと関係してよく出てくる話にブロック（アクセス）というものもあります。

時々聞く質問。

「トラックとセクタとブロックはどれが一番小さいのですか？」

まずトラックは脱落です。トラックよりもセクタのが小さいのは確かです。

陸上競技のトラックがレーンごとに競技場を一周していることを思い浮かべてもらうと忘れにくいと思いますが、トラックはディスク（プラッタ）の表面に360度にわたって存在しています。

そしてそのトラックを細かく分けているのがセクタです。

その為に「どちらが小さい？」議論はセクタとブロックの比較になるのですが、これには回答できません。

何故ならば、大雑把に言うとセクタはディスクからみた単位であるのに対して、ブロックはホストから見た単位だからです。

セクタはディスクの観点からはかなり小さいです。でもそれよりも細かい単位のブロックでホストからの書き込みがきたら、ブロックの方が小さくなります。逆 に、ホストから大きなブロック単位でディスクへと書き込みが来た場合には複数のセクタにまたがりブロックが書かれるために、セクタの方が小さくなります。

ただ、最近はブロックの単位が大きくなっているので、小ささ勝負にはセクタが勝利（？）することが多いみたいです。

初歩的な話ですがキャッシュに関してご教授ください。

１．ダーティページとは何のことでしょうか。

２．キャッシュ上に書かれたデータをディスクに書くタイミング・頻度はどの程度でしょうか。

３．MCCでよく出てくるWrite Throttlingとはどのような機能でしょうか。

４．Cacheのパフォーマンス情報の中にあるHits/sとMisses/sとは何を表すのでしょうか。

よろしくお願い致します。

自分もディスクに携わって10年以上なのですが、

以前から気になっていたディスクにまつわる都市伝説についてご教授下さい。

現在、ディスクドライブの「タイプ」としてSAS、SATA、NL-SAS、MLC、SLCと複数あります。

このうち、SATA/NL-SASについてはよく「壊れやすい」と言うことを耳にします。

そのためなのか、サーバベンダでは「24/365稼働のシステムでの利用は想定していない」と明記さえしているところがあります。

しかしながら自分には、SASよりもSATA/NL-SASの方が壊れやすい、と言う実体験がありません。

SATA/NL-SASにはRAID6を、と言う推奨は壊れやすいからではなく、リビルド時間の長大化が最大の理由だと思っています。

EMC社製品では、と言う観点で構いませんので、この都市伝説について解説頂けると嬉しいです。

あと、MLCとSLCについてですが、何故SLCの方が高速アクセス向けなのでしょうか。

こちらもMLCの方が壊れやすくてSLCの方がエンタープライズ向け、と言う噂も耳にしますがその真偽は如何でしょうか。

本色々とすごく参考にさせていただいております。

本で読んだことへの質問ではないのですが、

SSDはwriteに弱いとききますが、

SSDの寿命を延命させるために、EMCのSSD（VNXやVNXeに搭載しているもので）はなにか特別なことをしているのでしょうか？

King@NWさん

イベントへの最初の質問をありがとうございます。

それぞれの質問に対する回答は以下の通りです。

1. ホストからストレージシステムのキャッシュには書き込みが完了しているが、ストレージシステム内でディスクにまで書き込みが終わっていないデータ（ページ）
2. キャッシュ上にあるデータ量や書き込みデータの種類（ランダムかシーケンシャルか）などによって異なるために一概に言うことはできません。。
3. ホストからキャッシュに書き込みが行われたタイミングではなく、キャッシュのデータがディスクへフラッシュされた後に、ホストに対して書き込み終了（ACK）を返すことによりホストからの書き込み負荷を低減させる手法/機能です
4. ホストからのRead命令の対象データがキャッシュにあった場合にはHit、キャッシュになく、バックエンドのディスクからいちいち取ってこなければならなかった場合にはMiss。これらがどれくらいの割合あったのかを示している指標です

【1.と2.の説明】

多くの方が会社の個人用PC等で利用しているハードディスクはキャッシュを活用していないので、ホストからの書き込み（Write）があると、ディスクへ書き込みが終わってから書き込み終了の報告（ack）をホストに返します。

以下の絵の左側です。

それに対して、ストレージシステムは内部キャッシュを大活用します。

ホストからのwriteがあると、その書き込まれたデータがストレージ内のキャッシュに書き込まれた時点ですぐにackを返します。

これにより、「ストレージの原則と技術」（p.69）曰く「ホストへの応答は迅速で、だいたい1ミリ秒ほどである。」です。

ちなみにこれは上記右側の絵です。

ただ、この時ちょっと大げさな言い方をするとストレージはホストに対して嘘を言っています。

上の絵の左と右は、ホストから見るとどちらも大きな違いはなく、両方とも単にディスクに対して書き込み依頼をかけているだけです。そして、ホストは両方ともディスクからackをもらったので、

「あぁよかった。僕のデータはもうディスクに書き込まれた。これで安心だ」

と思っているわけです。

しかしながら、ストレージ（右側）のデータはまだキャッシュに残っていてディスクには書かれていません。にもかかわらずストレージはホストに対して書き込み終了の報告（ack）を返すという嘘をついているわけです。

そしてストレージは暇（隙？）を見て適当な時間に効率的に（と、この部分が実は質問2.に関する部分なのですが、この詳細仕様は公開されていません）キャッシュの中のデータをディスクに（コソコソと）書いています。

このディスクへの書き込みが終わって初めて本当にディスクの中にデータが入るので、安心な状態になります。

ちなみにここで言う安心な状態とは何でしょうか？

それは「電源が切れたとしてもデータが無くならない状態」を意味します。

ディスクにデータが書かれてしまえば、そこで電源が突然切れてもデータは無くならないのに対して、例えば以下の絵のような状態、まだキャッシュにしかデータが無く、ディスクに書き込みがなされていない場合に電源が突然落ちたりしたらデータはなくなってしまいます。

このような状態、ストレージがホストに対しては「もうディスクに書いたよ！安全！」と言いつつ実はまだディスクに書きこみを行っていない、ずる汚い状態のデータを「ダーティ」と呼んでいます。

ちなみに質問ではダーティページという表現が出てきていますが、ここで言うページは恐らくキャッシュの最少単位として利用されるページの意味で使っているのだと思います。

他にも社内でよく聞く言葉で「ダーティキャッシュ」や「キャッシュダーティ状態」などがありますが、意味は同じです。

【3.の説明】

これは最新の次世代VNXのMulti Core Cacheの話で今回のトピックとは少し異なるので詳細説明は割愛させてください。。。

大体の概念はこれ⇒ライトスロットル（書き込みスロットル）【Ranbo対話シリーズ】を読むとつかめると思います。

【4.の説明】

1.や2.の書き込み（write）の場合と異なり、今度は読み込み（Read）の話です。ただ、基本的な考え方はとても似ていて、読み込むデータがキャッシュに存在していたらかなり早くホストからのread要求に応えられる（下図左）のに対して、キャッシュに無い場合にはいちいちディスクから読みだしてこなければならない（下図右）ために、時間がかかってしまいます。

そしていきなり結論なのですが、左がキャッシュヒットで右がキャッシュミスです。恐らく今回の質問にあるHits/sとMisses/sはこの率を表しているのだと思います。

meさん

ご質問ありがとうございます。

確認してみましたが、EMCとしては特にSSDに対して特別なことは行っていなさそうです。EMCが利用しているディスクメーカーは1社だけではないのですが、メーカーごとに読み書きの動作を変えているとも思えないですし。。。

ただ、SSDが書き込み回数に依存して劣化することは確かなので、「ストレージの原則と技術」（p.44）にある「ライトレベリング技術」、同じセルへの書き込み（書き換え）を極力控え、最も書き込みが少ないものを使うという技術はディスクにて具備・実施されていそうです。

norick@nwさん

都市伝説情報をありがとうございます。

すごく大雑把に言ってしまうとディスクは詰め込み（Density)が大きいものの方が遅いし壊れやすいということが出来ると思うので、都市伝説もそこそこ正しいのだと思います。

例えばSASとNL-SAS/SATAは同じ物理サイズでもNL-SAS/SATAの方が詰め込みが大きい（容量が多い）ために、処理が遅い上に壊れやすいと言えそうです。（これまた大雑把ですが、NL-SASとはインタフェースだけSASで、中身はSATAディスクだと思っているので、以降の記述からSATAは抜きます）

実際に、もしもSASとNL-SASに同じ処理をさせて動作をし続けたらNL-SASの方が先に故障する可能性が圧倒的に高いです。

また、実際にはディスクの稼働時間だけではなく、実際の処理の量についても考慮する必要がありそうです。

例えばNL-SASの2倍の処理の能力を持つSASディスクが100%で常に稼働して100時間でダウンしたとした場合と、NL-SASディスクが100%で常に稼働して100時間でダウンした場合、一見同じく「100時間程度で壊れる」ように見えるかもしれませんが、実際に行った処理はSASの方が2倍多いので、SASの方が壊れにくいということが出来そうです。

とはいっても、EMCとしてVaultディスク（VNXのOS領域などが入っているアクセスが頻繁に行われるディスク）にNL-SASの利用も許可しているところを見ると、NL-SASの信用度もかなり上がってきているのだと思います。（以前のFCディスクとSATAディスクのような違いは感じられません）

そして同じようなことをMLCとSLCにも言うことが出来ます。

Multi Level Cell（MLC）のディスクには一つのCellに複数のビット情報が詰め込まれているのに対して、Single Level Cell (SLC）は1ビットだけです。そのために詰め込み（Density）の小さいSLCの方が高速で壊れにくくエンタープライズ向け、EMCで言うとFast Cacheにも利用できるということになるのだと思います。

ちなみに。「ストレージの原則と技術」（p.44）によると「SLCデバイスの読み取り速度は一般的にMLCデバイスの2倍であり、書き込み速度は最大で4倍になる」のだそうです。

「ディスクはシークエンシャルアクセスに比べてランダムアクセスを苦手にしてるよね。」

というような話をどこかで聞いたことがあるかもしれません。

それをウィーン、シュルシュル、ジーッっと実感できるようになると時々役に立つと思うのでここに書いてみます。

以下の絵はディスクのプラッタを上からみたところで、水色のところにデータがあるとします。

左のパターンでは3ヶ所に分かれてデータがあるのでランダムアクセスが必要。

右のパターンでは1つのトラックの上（のセクタ）にデータが連続してあるのでシークエンシャルアクセスが必要。

ここではまず左のランダムアクセスのパターンを考えます。

3ヶ 所のデータをそれぞれData A～Cと名付け、例えば最初にData Aにアクセスすることになるとアクチュエーターアームが「ウィーン」と動いてData Aがあるトラックまでアームが動き、その次にData Aがあるセクタまでプラッタが「シュルシュル」と動き、Data Aがアクチュエータアームの上に来ると、あとは「ジーッ」とデータを読みます。

そして次にData Bにアクセスするためにまた「ウィーン」とアームが動き、「シュルシュル」とプラッタがまわり、「ジーッ」とデータを読み、最後にまたData Cに対してウィーン、シュルシュル、ジーッとやっておしまいです。

それに対して右のシーケンシャルアクセスのパターンの場合は「ウィーン」「シュルシュル」「ジーーーーーーッ」でおしまいです！（←すいません、かなり手を抜いてます。。）

なんとなく実感が湧くでしょうかね。。。

ちなみにここで言っているそれぞれは、教科書(ストレージの原則と技術）的に言うと

ウィーン・・・シークタイム、もしくはアクセスタイム (p.33)

シュルシュル・・・回転遅延 (p.34)

ジー・・・データ転送レート (p.34)

です。

本の中に2.8に「データへのホストアクセス」というセクションがありますが、そこに書いてある絵はちょっと不満です。

もちろん間違えているわけではないのですが、ファイルレベルのリクエストだって、最終的にはブロックレベルのリクエストを行っているはずなので、並列に書かずに入れ子状態にするべきであって、以下のような絵の方が分かりやすい気がします。

ち なみに右の絵のファイルサーバー（NAS）と書かれている部分はWindowsのファイルサーバーやLinuxのSAMBAサーバ、NFSサーバなどをイ メージしてもらうとイメージが湧きやすいかもしれません。また、VNXやCelerraのファイルアクセスの場合はこの部分がData Moverです。

※少し切り口は違いますが、ブロックアクセスとファイルアクセスの違いとは？【Ranboシリーズ】も参考になるかも

最近のストレージUnifiedになり1台のストレージでNASもSANも使用できるようになってきています。

ここで疑問なのですが、

よく同じ領域（たとえばVNXなら1つのPool）にSANとNASのボリュームを一緒にするのは推奨されないと聞くのですが、

なぜ1つのPool内にSANとNASを共存させるのはよくないのでしょうか。

せっかくUnifiedなので1つの領域で両方使用したほうが効率がいいと思うのですが。

King@NWさん

そうですね。ディスクの利用効率を考えると一つの領域でBlockとFileを使えると便利なので将来的にそういう運用を推奨出来るようになるといいなぁと私も思います。もしかすると今盛り上がってきているSoftware Defined Storage、EMCで言うとViPRなどがそのソリューションになるのかもしれません。

とはいえ現状ではEMCとしては最大限のパフォーマンスを出してもらうためにFileとBlockのPool混在を推奨していません（技術的には出来るので実際に混ぜて運用しているユーザもいるようですが。。）。

ファイルPoolの作成にはパフォーマンスを出すためにThinはそもそも推奨しない、Thickを使ったとしても異なるLUNタイプ（Thin、Thick等）を混在させないなどの色々な推奨を出しているのですが、Blockでの利用とPoolを混在させると、その推奨を守るのが難しくなってしまいそうですし、ランダムアクセスで小さなIOが多いBlockアクセスと、比較的シークエンシャルアクセスで大きなIOが多いFileアクセスが同じPoolに入っていると、ストレージキャッシュの効率性が落ちるとも言われているので、Best PracticeガイドなどではファイルPoolの作成時には「AVOID mixing with Block workloads」なんて台詞が書かれていたりします。

今回は仮想化に関するメリットを一つ。

仮想化には色々なメリットがあるのですが、その中で個人的に一番パワフルだと思うのは、リソースの共有だと思います。

CPUやメモリ、ネットワーク帯域などは日々進化していますが、果たしてこれを常に100%使っている人はいるのでしょうか？

恐らくいないと思いますし、もしもいたとしたらその方はすぐにコンピューターを買い替えるべきです。

仮想化はリソースをプール化することで、リソースの効率的な利用を実現しています。

例えば、極端な例ですが、CPUの利用率が4秒間に１秒だけ100%になるシステム（PC）があるとします。

これは1秒で完了しなければならない処理なので、CPUの処理スピードを落とす（例えば1/4にして4秒かけて処理をさせる）ことは許されないとします。

そしてそのような処理をしているシステムが4台あると、4台のPCを準備する必要があります。

ただ、実はそれぞれのシステムが利用するCPU時間が1秒ずつ綺麗にずれていたとしたら、仮想化のテクノロジー（※）を使いシステムを統合すると1つのCPU＝1つのシステム（PC)で同じことを実現することができます。

まぁ、これは極端な例ですが、このリソース共有は仮想化をすることの大きなメリットだと考えています。

そして今回の例ではCPUリソースの話でしたが、これはメモリリソースにも、ネットワーク帯域リソースにも当てはまります。

ただ、面白いのがディスクリソースは異なり、書き込み処理が終わっても書かれたデータが消えないので、このリソース共有のうまみが出にくかったりします。

※仮想化のテクノロジーと言いながら、絵はVMware社のESXiサーバーにしちゃいました。ここは別にKVMでもXenとかでもOKです。