NetApp Tech OnTap NetApp Logo NetApp Logo
NetApp Tech OnTap
     
【検証結果から理解するネットアップのフラッシュ技術】
第9回
フラッシュ デバイスの特徴(基本編) ~ フラッシュ デバイス構造から理解する書き込み量の増幅を改善する仕組み ~
NetApp Tech OnTap

はじめに

本Tech ONTAPのフラッシュ連載では、第3回から第8回に分けて、Oracleデータベース環境でのNetApp Flash CacheおよびFlash Pool、そしてOracle Database Smart Flash Cacheの特徴と効果についてご紹介してきました。また、これまでの検証結果は、『Oracleデータベース環境におけるNetAppバーチャル ストレージ ティアの有効性と次世代の統合インフラの実現』と題して、Technical Reportを公開しています。

  www.netapp.com/jp/media/tr-4162-ja.pdf

Flash CacheおよびFlash Poolは、FAS / VプラットフォームのストレージOSであるData ONTAPのフラッシュ機能でしたが、今回(第9回)からはEFシリーズ(FAS / Vとは異なるプラットフォーム)と呼ばれるネットアップのオール フラッシュ アレイの検証結果と、そこから導かれる失敗しないフラッシュ活用法についてご紹介したいと思います。

フラッシュの構造を書き込み処理の課題

オール フラッシュ アレイの導入を検討する上で、フラッシュ デバイスの使用に対する懸念があるかと思います。代表的な懸念は、書き込み性能が悪いのではないかという点と、書き込み回数の上限(寿命)です。そこで、本格的にAll Flash Arrayの検証結果のご紹介に入る前に、フラッシュ デバイスに対する不信感を払拭するために、フラッシュ デバイスの構造と書き込み処理における課題、そして、その課題を改善するために各ベンダが実装している仕組みについて簡単にご紹介したいと思います。

フラッシュ デバイスはNAND型フラッシュ メモリ(以降、NAND)として以下の通り、セル、ページ、ブロックという単位で構成されます。

最小単位としてデータを格納するセル(cell)
複数のセルから構成されたページ(page)
複数ページから構成されたブロック(block)


図1. フラッシュデバイスの構造

フラッシュ デバイスの構造

これらの単位で構成されたフラッシュ デバイスに対する書き込み処理は、以下のルールが存在するため、HDDのように直接上書きができません。

書き込み処理は「ページ」単位(読み込み処理も同様)
ページが「未使用」状態でない場合(使用済み)は「消去(erase)」処理が必要
         o    ページ内のデータが「無効」な状態であっても、消去処理は必要
消去処理は「ブロック」単位


ページが「未使用」状態であれば、書き込みたいデータをそのまま書き込めるのですが、そのページが「使用済み」である場合、書き込み処理をするために幾つかのステップが必要になり、この現象をWrite Amplificationと呼びます。

図2. Write Amplification による書き込み量の増幅

Write Amplificationによる書き込み量の増幅

Write Amplificationによる書き込み量の増幅

NAND上では前述した書き込み処理のルールによりそのまま上書きできないため、一旦、別の領域(図ではDRAM)に退避した上で変更を反映します。その後、NAND上で消去処理が実行されたブロックに書き込み処理が実行されます。このように、read → modify →(erase)→ writeという複数のステップが必要になるため、その結果、本来書き込みたいデータ量より、NAND上で実際に書き込まれるデータ量が増幅しています。このWrite Amplificationによる書き込み増幅量をWrite Amplification係数(以降、WAF)として表されます(係数が1であれば増幅しないという意味になります)。WAFの値が高くなると書き込み性能が劣化し、書き込み回数の上限(寿命)に達し易くなるため、WAFの増幅を改善する仕組みが重要になります。今回は代表的な技術として3つご紹介します。

Wear Leveling(ウェア レベリング)
Over Provisioning(オーバー プロビジョニング)
Garbage Collection(ガーベッジ コレクション)


寿命を最大化する仕組みWear Leveling

Wear Levelingを直訳すると摩耗の平準化となる通り、フラッシュ デバイス上のブロックに対して書き込み回数を平準化することで、フラッシュ デバイス全体の寿命を最大化する仕組みのことです。

例えば、ファイル システムやデータベースで考えてみると、アクセス(I/O)するファイルや(データベース)ブロックには偏りがあるため、OSからリクエストされたアドレスに対して直接I/Oをした場合、フラッシュ デバイス上の特定のブロックに書き込み処理が集中します。これに対し、コントローラ(およびファームウェア)等でアドレスを変換することで、フラッシュ デバイス内の各ブロックに書き込みを分散します。

図3. Wear Leveling

寿命を最大化する仕組み

スペア ブロックを確保するOver Provisioning

前述したWear Levelingにより書き込み処理がフラッシュ デバイス内の各ブロックに分散されたとしても、書き込み先のページが「使用済み」の状態であった場合、WAFが増幅してしまいます。そのため、フラッシュ デバイスは全体容量の中から一定の割合を「スペア ブロック」として確保してします(Over Provisioning)。スペア ブロックは「未使用(または消去済み)」の状態で、実効容量としてカウントされない領域です。

書き込み回数が少ないスペア ブロックを優先してWear Levelingで書き込むのが基本的なアルゴリズムと言えますが、書き込み処理を続けていれば、いつかはスペア ブロックが不足してしまいます。そこで、新しくスペア ブロックを確保するのが重要であり、そのプロセスをGarbage Collectionと言います。

新しくスペア ブロックを生成するGarbage Collection

ブロックの中には、「有効」なページと「無効」なページが混在します(例えば、Wear Levelingにより新規ページが別のブロックに書き込まれたことにより、元々のページは無効となります)。有効ページが含まれているとそのブロックは消去できないため、有効なデータと無効なデータを整理し、ブロック内の全ページが無効な状態にした上で消去処理を実効し、スペア ブロックを生成します。このプロセスをGarbage Collectionを言います。

図4. Garbage Collection

新しくスペア ブロックを生成する

フラッシュ デバイスの特性まとめとEF550 SSDの耐久性

今回は、WAFの増幅を改善する代表的な仕組みとして以下の通りの技術を紹介しました。

寿命を最大化する仕組み「Wear Leveling」
スペア ブロックを確保する「Over Provisioning」
新しくスペア ブロックを生成する「Garbage Collection」


これらの技術を組み合わせることは非常に複雑な処理で、書き込み性能の劣化具体や、どこまで寿命を最大化できるかは各フラッシュ ベンダ次第と言えます。

フラッシュ デバイスは、特定のワークロードをかけ続けた場合に、書き込み回数の上限に達する年数のデータが フラッシュ デバイスを製造するベンダより提供されています。ネットアップのEF550が採用するSSDは、例えWAFの値がワースト ケースとなる100% Random Writeを続けた場合でも、保守契約期間(最大5年)中に書き込み回数の上限に達することのない耐久性を備えます。

次回の内容

次回は、Oracle Database環境でのEF550検証結果から導かれるEF550だけの活用法をご紹介していきたいと思います。

岩本 知博(いわもと ともひろ)

システム技術本部 パートナーSE部 システムズ エンジニア
ネットアップ株式会社

会津大学大学院 コンピュータ理工学研究科卒、外資系データベース メーカを経て2012年パートナーSEとして入社。入社以来、パートナー支援とフラッシュ ソリューションおよびデータベース ソリューションを中心に活動。最近はオール フラッシュに夢中。写真は、今月に開催されたNetApp Innovation 2014 Tokyoから。
関連情報
関連情報
【検証結果から理解するネットアップのフラッシュ技術】
第1回:フラッシュ技術をリードするネットアップの
ポートフォリオとその棲み分け


第2回:バーチャル ストレージ ティアとオール
フラッシュ アレイでオーバーサイジングを解決

第3回:バーチャル ストレージ ティアの強み
~ Flash Cache と Flash Pool の検証結果~

第4回:Flash CacheとFlash Poolの特徴(詳細編)
~キャッシュ ヒット率とキャッシュの永続性に
ご注意を!!~

第5回: Flash Poolの特徴(応用編)
~マルチ ワークロード対応の最強の
ディスク プールを構成する~

第6回:NetApp Flash PoolとOracle Database Smart Flash
Cacheの検証結果から理解するサーバ側キャッシングソ
リューションの特徴

第7回:NetApp Flash PoolとOracle Database Smart
Flash Cacheの組み合わせ ~DB統合の密度を極限まで高める~

第8回:検証結果から導かれるFlash Cache、Flash Pool、Database Smart Flash Cacheの特徴
関連情報
 
 
Go further, faster TRUSTe
お問い合わせ   |   購入方法   |   フィードバック   |   採用情報  |   登録   |   プライバシーポリシー   |   © 2014 NetApp