 |
 |
 |
||||||
 |
 |
 |
 |
 |
 |
|||
 |
||||||||
 |
|
 |
 |
- カラムストア型データベースとSolid State Storage - |
|
|
- Flash Memory Errors ? It's Not Just About Write Endurance - - フラッシュメモリのエラーについて（書き込み回数だけが問題ではない。） - |
|
|
- Linux Elevator Settings Impact on SSDs - - （LinuxのI/Oスケジューラ設定とSSDの性能について）- |
|
|
- Understanding Storage Performance - - （ストレージのレスポンスタイム、IOPS、Bandwidth（帯域）の関係性について）- |
|
|
- A Pragmatist’s view of PCIe SSD - - （PCIe接続のSSDについての実際的な視点について） - |
|
|
- SAN Shared File Systems with SSDs - - （SSDを使ったSANファイル共有システムについて） - |
- カラムストア型データベースとSolid State Storage -
Texas Memory Systems社のJamon Bowen氏は大容量SSDの普及や64bit化による大容量メモリの利用に伴い、カラムストア型データベースによるOLTPとOLAPの両システムの統合が実現するのではないかと予想しています。
Columnar Databases and Solid State Storage（カラムストア型データベースとソリッドステートストレージ）
上記の記事は、Credit Suisse社作成によるホワイトペーパーに対するTexas Memory Systems社のJamon Bowen氏の私見です。
Credit Suisse社のホワイトペーパー
The Need for Speed（document-871549241.pdf）
ローストア型データベースでは、テーブル内のレコードの全ての情報は一緒に保存されています。そのためOLTPで行われているような、トランザクションを記録したり、アカウントの詳細を閲覧したりといった、レコード中心のアクティビティーに対して、ローストア型データベースは非常に高速に動作します。
一方、カラムストア型データベースでは、テーブル内のデータは区切られていて、テーブル内の全てのフィールドが一緒に保存されています。そのためOLAPで行われているような、全てのレコードの特定のフィールドのみを結合するといったクエリーが実行される、分析的なアクティビティーに対して、カラムストア型データベースは非常に高速に動作します。
これは、実行されるクエリーにとって不要なフィールドの読み込みを回避できるからですが、一方で、新しいレコードが追加された場合、全てのフィールドが個々に更新されなければならないため、その際には大量のディスクI/Oが発生するというデメリットがあります。
しかし、I/O性能が非常に高速なSSDやインメモリでの処理により、このディスクI/Oで発生するボトルネックを回避する事ができます。
一方で、SSDや大量のシステムメモリの導入コストに関しても、カラムストア型データベースの特徴である、レコード毎ではなく、フィールド毎にグルーピングされたテーブル構成により、圧縮の効果が非常に高く、またインデックス構造もとらないため、データベースの容量を劇的に抑えることができ、更にSSDやRAMメモリの低価格化によって、十分に相殺が可能です。
懸念される問題点として、大量のディスクI/Oが発生する事から、SSDの並列I/Oに対する処理能力が挙げられますが、この点はTexas Memory Systems社のRamSanシリーズのような、高性能SSDの利用により十分に解決が可能です。
次に挙げられる最も大きな問題点は、トランザクションの整合性を保ちながら、効率的に複数のロケーションに対する更新を行える仕組みを備えたロッキング機構へのシフトです。
これにはソフトウェア側の改善が必要となり、時間や人材といったリソースが必要とはなりますが、SSDの誕生がハードウェア業界へ革新をもたらしたように、ソフトウェア側のパラダイムシフトも時間の問題と考えます。
最後に、Credit Suisse社作成によるホワイトペーパーで述べられているような、SSDはインメモリデータベースへの完全な移行までの踏み台ではないかという論旨に対しては反対を唱えます。
特に巨大なシステムに関して、この予測が当てはまらないと考える理由は、コスト、性能、（容量あたりの）電力、そしてリスタート時の永続性です。
コスト、電力、そしてリスタート時の永続性について、SSDがインメモリ処理よりも優れているという点は議論の余地はないと思いますので、やはり性能面のみがSSDに対するインメモリ処理の優位性という事がいえるでしょう。
単純に考えれれば、RAMはフラッシュに比べてレイテンシーも小さく、より高速です。これは確かに正しいですが、もしソフトウェア側が改善され、効率よく大量のインサートやアップデートの並列処理が可能となるロッキング機構が実装されれば、レイテンシーに於ける性能差も十分にカバーできるはずです。
つまり高性能なSSDであれば、並列処理性能の点に於いても、インメモリ処理と十分に互角の性 能を発揮する事が可能と考えます。
ページトップに戻る
- Flash Memory Errors ? It’s Not Just About Write Endurance -
- フラッシュメモリのエラーについて（書き込み回数だけが問題ではない） -
Flash Memory Errors ? It’s Not Just About Write Endurance
フラッシュのチップあたりの容量が増加の一途を辿っていますが、その背景には次のような問題が隠されています。
フラッシュのチップがより高密度になる程、チップ毎のダイの個数が増加します（今日では4個が一般的）。4個のダイを1個のフラッシュチップに搭載すると、チップ毎のパッケージングのコストが抑えられ、PCB（プリント回路基板）の消費面積も小さくなります。
また、より小さいダイを使う事も、製造過程で欠陥が見つかった場合、無駄になるウェーハのエリアもより小さく抑えられますので、生産性の向上に繋がります。
更に、それぞれのダイは2個のプレーンと呼ばれるエリアに分けられます。これらのプレーンは効率良く、独立したオペレーションを実行できますが、ダイへのインターフェースは共有されています。
*詳しくは、SNIAの"NAND Flash Solid State Storage for the Enterprise"の3ページを参照
この内部構成を利用し、フラッシュのコントローラはガーベージコレクションと書き込みのハンドリングをより効率良く行っています。
例えば、ライト性能を稼ぐ際に重要な、イレース済みの領域を確保するためのページの移動（ムーブ）オペレーション等をプレーンの個数分、同時並列に処理ができます。
つまり、現在の一般的なフラッシュチップは8個のプレーンで構成されていますが、その場合、最終的に性能を制限するのはフラッシュチップと接続される外部ピンという事になります。
次に、余り取り上げられない話題ですが、フラッシュチップの故障モードで比較的に頻度が高いのは、実はフラッシュチップ全体の故障ではなく、チップ内のダイやプレーンが1個だけ故障するといった、局所的な障害で、そのような障害が発生した場合も、実は残りのフラッシュチップは正常に稼動します。
一方で、エンタープライズクラスのSSDも含め、一般的なフラッシュチップの耐障害性へのアプローチはフラッシュチップ間でのRAIDの実装です。
但し、フラッシュチップはサイズとしては丁度ハガキ程度ではありますが、FRU（フィールドでの交換可能ユニット）として扱うには現実的には様々な困難を伴うため、フラッシュチップ故障の際は通常、そのフラッシュチップを含む、より大きなユニット毎での交換となり、それがディスクドライブのフォームファクタが主流になっている大きな要因の一つとなっています。
しかし、たった1個のチップ（更にその内部のプレーンやダイといったコンポーネントの）故障にも関わらず、ディスクドライブのフォームファクタ毎での交換を強いられるというのは（ディスクドライブのフォームファクタに起因するレイテンシー等の性能劣化の問題を除いても）、非常に不経済であると言わざるを得ません。
そこで、Texas Memory Systems社はこの問題に関する革新的なソリューション、Variable Stripe RAID（VSR）を開発し、特許を取得しました。
このテクノロジーはTexas Memory Systems社の最新の製品であるRamSan-70（PCIe接続）とRamSan-710（SAN接続）に実装されています。
Variable Stripe RAID（VSR）とは、10個のフラッシュチップ間で、可変的なストライピング構成ができるRAID方式で、ダイやプレーンといったフラッシュチップ内の局所的な故障が発生した際も、フラッシュチップ全体を故障とマーキングせずに、RamSan-70とRamSan-710に搭載された余剰チップを効率的に使用し、フラッシュチップの寿命を大幅に改善します。
先ず、Variable Stripe RAID（VSR）では、1個のフラッシュチップ容量を全て使用するのではなく、その一部のみを薄く使用してRAIDを構成しているため、RAID故障が発生した際も、対象となるフラッシュチップの1/4または1/8の範囲だけがオフラインになります。
また、部分的なフラッシュチップ障害が発生した際も、ストライピングを（非常に複雑なプロセスですが）9+1から8+1に動的に可変することができるため、RAID保護に柔軟性が生まれ、より効率良くフラッシュチップの経年劣化や単一故障に対応できます。
このようなテクノロジーの実装は、PCIe接続のカードタイプのRamSan-70といった製品にとっては特に重要で、耐障害性を高めるのみではなく、余剰チップ数の低下等による機器全体の保全交換等のメンテナンスによるダウンタイムを最小限に抑える事ができます。
ページトップに戻る
- Linux Elevator Settings Impact on SSDs -
- （LinuxのI/Oスケジューラ設定とSSDの性能について） -
Oracle 11g上でディスクドライブとSSDの性能比較をするというプロジェクトに関わった時の出来事です。
SSDと48本で構成されたアレイに対してASMの障害グループを構成し、そこにデータベースを作成し、ASMのPreferred Readの機能を利用し、SSDと48本で構成されたアレイに対して交互に、ローに対してランダムにクエリをかける簡単なスクリプトを実行しました。
すると不思議な結果となりました。
SSDは確かに48本のディスクドライブよりも速かったのですが、その差はたったの3倍でした。
この程度の性能差は実際のプロダクション環境であればあり得るとは思ったのですが、今回のベンチマークでは少なくても10倍以上の性能差がでないと理屈に合いませんでした。
OSはLinuxだったため、IOstat等を利用して統計情報から調査すると、SSDへのスクリプト実行時にも関わらず、10,000IOPS前後で2msもの遅延が発生していました。
10,000IOPSという数値は本来、SSDにとっては全く問題にならない負荷レベルですので2msの遅延は大き過ぎました。
そこで一旦、Oracle 11g上でのスクリプト実行を中止し、単純なI/OベンチマークにてSSDに対して同じようなランダムリードのI/O負荷をかけると、今度は10,000IOPS時の遅延は0.3ms、想定通りの数値が得られました。
再度、Oracle 11g上でのスクリプトを実行すると、やはり結果は最初と同じ、10,000IOPSで2msでした。何がOracle 11gと単純なI/Oベンチマークとの差を生んでいたのでしょうか？
するとTexas Memory Systems社のエンジニアは、自社で作成しているRamSanの構築ガイドに記載の、とある内容を思い出しました。
「Linux上でRamSanの性能を更に向上させるには、カーネルパラメータに"elevator=noop"の記述を追加し、I/Oスケジューラを無効にします。この記述により、I/O長の小さいリクエスト時のレスポンスが向上します。また、この記述はファイルシステムに対する、リードとライトが同時に発生するミックスI/Oに対する性能向上にも繋がります。」
*以下、/boot/grub/menu.lst（又は/etc/grub.conf）の記述例：
title Red Hat Enterprise Linux Server (2.6.18-164.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-164.el5 ro root=LABEL=/ elevator=noop rhgb quiet
initrd /initrd-2.6.18-164.el5.img
そこで、早速、上記の記述をカーネルパラメータに追記すると、SSDにて50,000IOPSオーバー時で0.3msの遅延という、期待通りの性能を実現する事ができました。そしてシステムのボトルネックがCPUに移行したため、RACのノードを1ノード追加すると、システム全体として100,000IOPSの性能が得られました。
LinuxのI/OスケジューラはディスクドライブへのI/Oを並べ替える事によってディスクドライブのレスポンスタイムの平均値を低下させるという目的があります。単純なI/Oベンチマークを実行した際のI/Oパターンは、ランダムでありながらも、一定の間隔で発生していたため、I/Oの並べ替えというスケジューラの挙動がSSDの性能に対して悪影響は与えませんでした。
一方で、Oracle 11g上でのスクリプト実行の際は、ランダム性がそれ程ではなく、I/Oの間隔もより不均等（よりBurst的）で、更にリードだけではなく、コントロールファイルへの書き込みも発生していました。にも関わらず、I/OスケジューラはI/Oの並べ替えを行う事が（それによってI/Oに遅延が発生してしまう事が）レスポンスタイムの平均値に貢献すると判断していたのです。
言うまでもなく、このI/Oスケジューラの判断は、高速で遅延の少ないI/Oが可能なSSDには当てはまらず、ディスクドライブのI/O性能を前提とした、全く逆効果の、時代遅れの最適化という事ができます。
ページトップに戻る
- Understanding Storage Performance -
- （ストレージのレスポンスタイム、IOPS、Bandwidth（帯域）の関係性について） -
ストレージの性能を比較するのは思ったよりも難しい事です。
特にRAMベースのSSDとフラッシュベースのSSDの違いを説明する時など、しばしば持ち上がる問題です。
Texas Memory Systems社製の製品を例に挙げると、RAMベースのフラグシップモデルであるRamSan-440とフラッシュベースのフラグシップモデルであるRamSan-630を比較した場合、フラッシュベースのRamSan-630の方がIOPS性能が高く、RAMベースのRamSan-440の方がレスポンスタイムが高速です。
ストレージの性能を比較する際、その指針になるのは次の3つです。
・IOPS
・Bandwidth（帯域）
・レスポンスタイム
これら3つの指針の関係性を把握する事がストレージの性能を理解する上で非常に重要です。
Bandwidth（帯域）とは、単純にストレージを接続する際の設計や規格上の物理的な制限です。
特定の時間枠（例: 毎秒）に転送できるデータ量（バイト数）で、ここではレスポンスタイムのオーバーヘッドやI/Oの並列性は関連がありません。
IOPSとは、こちらも単純に1秒間に実行できるI/Oトランザクションの総和です。特定のI/Oサイズに於ける理論上の最大IOPSを求めるには、単純に最大Bandwidth（帯域）をI/Oサイズで割るだけです。
例えば、Gigabit Ethernetが1本（=最大100MB/s）で構成されたiSCSIの環境にて64KBのI/Oサイズにてファイル転送を行うと、最大のIOPSは約1,500IOPSとなります。I/Oサイズが512Bであれば、約200,000IOPSとなりますし、単純にこのIOPS性能を稼ぐのであれば、Bandwidth（帯域）が制限になる事はまず起こりません。
一方、レスポンスタイムと並列性を関連付けるもう一つの関係性があります。それは「リトルの法則」です。
特定の要件を満たす性能を達成する場合に必要とされるシステムの並列性（並列処理性能）はリトルの法則によって決定されます。
ストレージに関していえば、リトルの法則とは、Outstanding I/O ÷ レスポンスタイム = IOPSという事ができます。ストレージの性能を語る上で、この法則が最も重要ではないかと思います。
つまり最終的には、IOPS性能の限界というのは、あるストレージシステムが、Outstanding I/Oをどの程度の並列性をもって処理できるかという事に尽きます。この部分が限界に達した時点でI/O処理が滞り、レスポンスタイムが急激に上昇し始めます。そこで、ストレージの性能を改善する手法として、従来まではハードディスクドライブを追加し、I/Oの並列性を向上させるアプローチが採用されてきました。
興味深い事に、IOPS性能はレスポンスタイムには制限されません。つまり、レスポンスタイムが低い、高速であるというのは、特定のIOPS性能をより低い並列性で処理できるという事を意味するだけです。
勿論、ストレージのインターフェースが処理できる並列性は現実的には限界があり（例: FCのHBAに於ける"execution throttle"値）、また多くのアプリケーションに於いても、並列処理のレベルはそれ程高くもありませんが、レスポンスタイム自体がIOPS性能を制限する事はありません。
そのため、フラッシュベースのSSDはRAMベースのSSDに比べてレスポンスタイムの点では劣るものの、RamSan-620やRamSan-630、あるいは最新ラインナップのRamSan-710といった並列処理性能に優れたフラッシュベースのSSDを利用する事で、RAMベースのSSDと同等、あるいはそれ以上のIPOS性能を実現する事ができるのです。
ページトップに戻る
- A Pragmatist’s view of PCIe SSD -
- （PCIe接続のSSDについての実際的な視点について） -
Texas Memory System社のRamSanシリーズのラインナップに、これまでの主力製品であったSAN接続タイプのSSDに加えて、RamSan-70というPCIe接続タイプのSSDが加わりましたが、多くの方がPCIe接続タイプのSSDで実現できる事、実現できない事、混同されているのを見受けますので、ここで少し説明してみたいと思います。
Q1. PCIe接続タイプのSSDとは何でしょうか？
A1. PCIe接続タイプのSSDを一言で表すのであれば、超高速なDAS（Direct-Attached Storage）という事ができるでしょう。
Q2. PCIeバスに直結という事は、他の接続形態に比べてCPUにより近いという意味でより高速なのでしょうか？
A2. 確かにその通りですが、より正確に理解するには若干の説明が必要です。
Texas Memory System社のRamSanシリーズはSAN接続（FC接続）のモデルであっても、HBAを経由する事のオーバーヘッドは実はたったの10 μsしかありません。
一方で多くの他社製のSAN接続タイプのSSDのレイテンシーが1-2msと非常に大きい一番の要因は、HBA自身の（PCIe <-> FCのプロトコル変換による）オーバーヘッドではなく、各社がストレージシステムに実装している仮想化機能等のソフトウェアレイヤーのレイテンシーなのです。
Texas Memory Systems社製のRamSanシリーズを検討されているお客様にとって、SAN接続タイプを選択するのか、PCIe接続タイプを選択するのか、この判断は単純にアプリケーションが共有ストレージを必要としているか否かという点に尽きます。
Q3. それではTexas Memory Systems社製のPCIe接続タイプのSSDを共有ストレージとして利用できるようにする計画はあるのでしょうか？
A3. いえ。Texas Memory Systems社には既に共有ストレージとして利用できるSAN接続タイプのSSDがありますので、そのような計画はありません。
Q4. それでは何故、PCIe接続タイプのSSDが今、非常に注目されているのでしょうか？
DAS vs SANの論争についてはSAN有利という事で決着している筈ですが。
A4. その論争は次の2つの出来事によって振り出しに戻りました。
それはサーバの低価格化と、大規模なクラスタシステム導入が始まった事です。
共有ストレージモデルに於いては、各サーバが高速にストレージにアクセスするため大規模なコアネットワークが必要となり、これがシステム専用の高性能なSANを構築する主な理由の一つです。
しかしサーバの台数が数千、数万と膨大になってくると、SAN環境の構築コストが莫大になってしまい、金銭面に於いて非現実的となります。
そこで注目されているのが、シェアードナッシング（Shared Nothing）タイプのスケールアウトクラスタです。
基本的な考え方は、各サーバはデータの一部のみを処理して、その結果は自身のローカルディスクに保存されます。この処理を大量なサーバが並列的に実行し、その後のステップにて結果がコンパイルされます。
この方法なら重いデータ処理はサーバ内部のみで発生し、その後、処理結果がネットワーク経由で送信されコンパイルされます。
この考え方がHadoopやDWH系のアプリケーションでも採用されています。言うなれば、何らかのSAN（またはNAS）システムに基づいた仮想ストレージ、仮想サーバ、大規模ネットワーク、という考え方ではなく、膨大なCPUリソースと高速なDASの組み合わせによって、1台のサーバ内にサーバとストレージがシングルステップで仮想化されてしまったという事でしょうか。
このようなフレームワークに於いて、PCIe接続タイプのSSDの性能は非常に重要になってきます。何故なら、相応の価格帯のサーバであればCPU等のリソースは非常にパワフルであるため、十分なストレージ性能がなければ、そのサーバリソースを活かし切れないからです。
例えばTexas Memory Systems社製のRamSan-70であれば、1枚のカードで2GB/sの性能を内蔵ディスクとして提供できます。これだけの性能があれば、ストレージとCPUリソースのバランスも申し分がなく、シェアードナッシングタイプのクラスタシステムが合理的にスケールアウト可能となります。このようなSSDを使わないとなると、大量のディスクドライブが各サーバに必要となるか、各サーバのCPUリソースを十分に活かし切れず、電力消費の点、占有スペースの点、両方において望ましい状況ではありません。
SSDの台頭によって、SSDの容量、性能、価格のバランスがより望ましい方向に向かってきており、新しいシェアードナッシングタイプのフレームワークがメインストリームのアプリケーションにも普及しつつあります。これらSSDとシェアードナッシングタイプのフレームワークの発展はITコミュニティに於いてもまだ熟考段階にあり、ストレージの巨大ベンダーもこの分野にて主導権を握ろうと競い合っている段階であると言えるでしょう。
Texas Memory Systems社に於いても、超高速なDAS（Direct-Attached Storage）による新しいフレームワークのニーズを見込んでおり、Texas Memory Systems社が長年培ってきたハードウェアエンジニアリングの技術を駆使したDASソリューションの開発を進めています。
ページトップに戻る
- SAN Shared File Systems with SSDs -
- （SSDを使ったSANファイル共有システムについて） -
前回の記事ではPCIe接続タイプのSSDがシェアードナッシングタイプのスケールアウトクラスタに適しているという内容に触れましたが、このフレームワークが上手くいくには2つの要件があります。
それは、論理的なデータの分割方法と、それらの分割されたパーティションから大きなチャンクにてデータをスキャンする事の必要性です。
これらの要件は多くのアプリケーションで見受けられますが、全てのアプリケーションに当てはまる訳でもありません。
アプリケーションの種類によっては、所謂「データへのトータルアクセス」が必須になる場合もあり、その際、シェアードナッシングタイプのアーキテクチャでは必要なデータをローカルからではなくネットワーク越しに取得する事になってしまい、アーキテクチャとしては不適切です。
データへのトータルアクセスが必須になるアプリケーションは科学技術計算、フィナンシャルモデリング、政府系アプリケーションに多く見られます。
これらのアプリケーションの特徴としてはプロセスを効率的に並列処理できる一方で、各プロセスが必要とするデータは巨大なデータセットの何処にあるのか、絞り込む事が難しいという点が挙げられます。
その結果、一般的なディスクアレイが最も不得意とする、I/O長の小さい、ランダムアクセスが発生する事になります。この問題をクリアするため、これまでは次の3種類のアプローチが採用されてきました。
1. I/Oのランダム化を抑えるための前段階的なプロセスの追加。
2. 各ノードのシステムメモリをネットワーク越しにアクセスできるようなクラスタの設計。
3. 1台の大量のメモリを搭載したSMPサーバによるアプリケーションの実装です。
これらのアプローチに加えて最近、頻繁に目にするのが、大容量のSSDを使ったSAN構成の共有ファイルシステムです。共有ファイルシステムにはロッキング機構が備わっているため、複数サーバから同時に特定のブロックに対するダイレクトアクセスが可能になり、ブロックレベルストレージの高性能を活かした、利便性にも優れた共有ファイルシステムを提供できます。
基本的に構成は以下のようになります。
SSDをプライマリのストレージとして利用する事で、これまでのストレージが得意としてきた広帯域系のワークロードに加えて、小さいI/O長が主体のランダムアクセス系のワークロードにも対応できるようになります。
また、数百コア程度のプロセスパワーと数十～数百TBのFLASHベースのSSDを利用したシステムの構築が比較的容易なため、これまでは1台の大量のメモリを搭載したSMPサーバでの処理でしか実現できなかったようなワークロードにも対応できるようになります。
巨大なデータセットへのトータルアクセスが必須となるワークロードに於いては、CPUやメモリといったコンピューティングリソースとストレージを接続する、ネットワークとプロセスステップがシステムの性能限界を決定してしまいます。
SAN環境での共有ファイルシステムの大きなメリットは第一に、シンプルなブロックレベルでのデータのやり取りと、複数の広帯域のインターフェースを利用する事で実現できる高い性能と低遅延、次に、コーディネーションのプロセスはストレージではなくサーバ側に実装されているため、Texas Memory Systems社製のRamSanシリーズ等の高性能なSSDを利用しストレージ側のボトルネックを排除すれば、ノードを追加していく事でほぼリニアに性能がスケールする点です。
Texas Memory Systems社でも、非常に高いアプリケーション性能を要求されるお客様がいる場合、先ずこの共有ファイルシステムタイプのアーキテクチャから検討します。
ページトップに戻る
