株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

トップ > PernixData > ストレージコントローラーのCPUサイクルを無駄遣いするのは止めよう!

ストレージコントローラーのCPUサイクルを無駄遣いするのは止めよう!

PernixData

本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。

本記事の原文はStop wasting your Storage Controller CPU cyclesで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。

大抵のストレージのパフォーマンス問題に対処しようとするとき、最初の質問はどのタイプのディスクを使っているの?どのぐらいの速さ?どのプロトコルを使ってる?です。しかしながら、ストレージアレイの入り口に問題があることがあります、つまり、ストレージコントローラーです!

大好きなストレージアレイのストレージコントローラーの構成を見なおしする際、手の出しようがなく、目を向けないのがCPUのスペックです。ストレージアレイのストレージコントローラーはバックエンドのディスクへの接続を確立するための多くのI/Oのポートを持ち、フロントエンドのホストとの接続インターフェイスを提供する普通のシンプルなサーバです。ストレージコントローラーはデータサービスや特別なストレージ機能を提供するためのプロプライエタリなソフトウェアを動作させます。データサービスを提供し、ソフトウェアを動作させるためにはCPUパワーが必要です。いろいろと調べていく中で、私はほとんどのストレージコントローラーが4～8つのコアをもつCPUを2つ搭載していることがわかってきました。もちろん、例外はありますが、代表的な構成にだけ目を向けましょう。これは大抵のエンタープライズストレージアレイは2つのストレージコントローラーを持っているとしても、全体で16～32コアしか搭載していないということです。16～32コアです!それだけです! このストレージコントローラーのCPUは何に使われるのでしょうか? 今日のストレージコントローラーは以下の様な動作と役割を持っています。

  • データパスのセットアップと維持
  • データの冗長性と可用性のためにWrite-Backキャッシュへの書き込みをストレージコントローラー間でミラー
  • データの移動とデータの統合
  • RAIDレベルの維持とパリティの計算･書き込み
  • スナップショットやレプリケーションのようなデータサービス
  • 重複排除や圧縮といった内部のデータサービス
  • 適切な階層へデータを移動させる階層化アルゴリズムの実行
  • アレイの管理･監視の機能を提供するソフトウェアを動作させる

歴史的にアレイはサーバの手に負えないデータを一元化するために設計されていました。多くのアレイがそれぞれの1つのサーバからのリクエストを簡単に処理出来たので、I/Oパフォーマンスは問題にはなりませんでした。そこへ仮想化が現れたのです。平均的に多くのI/Oを消費するサーバが1つのサーバ上に集まっているのです。これによってサーバはGeorge Crump氏がいう火の息を吐くI/Oの悪魔へと変えてしまいました。仮想マシンのモビリティは接続性の向上を要求します。つまり、利用できるストレージコントローラーのI/Oポートをまたがって手動でI/O負荷を分散するのは仮想的に(洒落ではなく)不可能なのです。パフォーマンスの必要性が増えるに連れて、異なるディスクのタイプと異なるスピードの非常に多くのディスクをストレージコントローラーが管理する必要が出て来ています。

仮想化ファーストポリシーはあらゆるタイプのサーバとそのI/Oパターンをストレージアレイの上に載せてきました。そして、ソフトウェア定義の経済(だれか、この言葉を使った人いる?)という新しい手法の必要性をもたらしています。すべての仮想マシンが週7日24時間最速のリソースを要求することがないのは明らかです、結果として階層化ソリューションが注目を集めます。階層化は必要な際に最高のパフォーマンスを提供しながら、組織に対して最高の経済性を実現させるためにデータを昇格、降格させるためのスマートなアルゴリズムを必要とします。スナップショット、重複排除、他の内部データサービスは更にCPUのサイクルを必要とします。I/O要求が大きくなり新しいデータサービスが必要とされるので、仮想化データセンタにおいてリソースが逼迫しているストレージコントローラーは珍しいものではなくなっているのです。

現在のパフォーマンスアーキテクチャを考えなおす

サーバサイド高速化プラットフォームはストレージアレイデータストアよりもアプリケーションに近接している高速なリソース(Flashやメモリ)を活用し仮想マシンのパフォーマンスを向上させます。データをサーバ層にとどめ、PernixData FVPのようなストレージ高速化プラットフォームはストレージエリアネットワークとストレージアレイに新たなメリットを提供します。

データの移動に対しての読み取り高速化のインパクト

ハイパーバイザーはI/O多重化、つまり、多くの仮想マシンからのランダムI/OストリームをストレージコントローラーのI/Oポートへと送ります。これらの読み取りと書き込みは必ず処理されなくてはなりません。書き込みはディスクに書き込まれなくてはなりませんし、ディスクから読み出されたデータは読み取り要求を満たす必要があります。これらの手続きはすべてCPUサイクルを消費します。書き込みを高速化する際には2回めのデータ読み取りはアプリケーションに最も近いFlashデバイスから提供されます。大抵のデータは複数回読み込まれます。これはアプリケーションのレイテンシを下げますが、逆にキャッシュが廃棄されることもあります。別の負荷に対してこのアーキテクチャを提供するためです。(訳注: 別のワークロードに高速化を提供するためにキャッシュを廃棄する) FVPはどれだけのI/Oがデータストアから節約され、Flashから提供されたかを示す値を提供しています。以下のスクリーンショットはデータベースのワークロードを6週間高速kされたあとに取られたものです。アーキテクチャについて詳しくはこちらを参照してください。

Fig97

ストレージアレイはこの80億IOPSを提供する必要はありません、それだけではなく、520.63TBものデータ転送がストレージエリアネットワークへと転送されなくなり、ストレージコントローラーのI/Oポートを占領することがなくなります。これはつまり、他のワークロード、例えば仮想化済みだが、まだ高速化されていないワークロードや、同じアレイを利用している他のワークロードがI/Oの占有から影響をうけることがなくなるということです。ストレージコントローラーへ流入してくるI/Oが減ると、他のI/Oがよりストレージコントローラーを自由に使えるようになります。ディスクからのデータ読み取りが減ると、ディスクからI/OポートへのI/Oの読み上げが減り、ストレージコントローラーの上でアプリケーションへと引き返す経路をたどります。データサービスや内部処理むけの大量のCPUサイクルの節約はアレイのレスポンスのためにCPUサイクルをより活用できるという状況を実現します。

スクリーンショットは私の大好きなお客さんの1社から提供されたものです。ですが、我々は今、どんなアプリケーションが高速化されており、他のお客さんがどれだけのIOPSを出しているのかを見るためのクールなコンテストを開催中です。

ストレージコントローラのWrite Cacheによる書き込みの高速化の影響(ミラーリング)

現在ほとんどすべてのストレージアレイが読み取りと書き込みの高速化のためのキャッシュ構造を内蔵しています。書き込みを高速化させることはアプリケーションにとっても、アレイ自身にとってもメリットが有るのです。大抵のwrite cacheで利用されているNVRAMへの書き込みは(RAID構成の)ディスク構成に書き込むよりもはるかに高速で、早い書き込みの完了通知を返すことができます。完了通知はアプリケーションへ通知され、アレイは｢のんびり｣と最適な方法でバックエンドのディスクへ書き込みのデータをコミットすればよいのです。

ストレージコントローラーが単一障害点になり、データを失うことを避けるため、冗長性は必須です。いつくかのベンダーは冗長性目的でジャーナルと一貫性保証点を提供します。ほとんどのベンダーは両方のコントローラー間で書き込みのデータをミラーリングします。ミラー書き込みキャッシュはデータの一貫性を保証するための連携が必要です。大抵バックプレーンを経由するメッセージングが利用され、コントローラー間で正確性を保証します。データのミラーリングとメッセージングはいずれもコントローラーのCPUサイクルを利用します。

残念ながら、これらのNVRAMの構造を利用していても、書き込みの問題は毎日のように発生します。NVRAMのサイズやスピードではなく、バックエンドのディスクが膨れ上がる書き込みを処理できる能力の問題です。コントローラーレイヤのキャッシュのサイズを増やすことはできますが、どこで書き込みのパフォーマンス問題が起こるのかを遅らせることしかできません。大抵の場合、これはWriteのI/Oがスパイクした際に発生します。記憶にとどめておいて欲しいのですが、ほとんどのESX環境では定常的なI/Oに加え、スパイクのI/Oが発生し、すでに満身創痍のストレージコントローラを追い込みます。いくつかのコントローラーは固定的にこの書き込みのミラーのためにリソースを予約し、この予約が満タンになった際にはコントローラーからディスクへデータを書き出すことを強制するようになっています。I/Oが継続して注がれてくると、Write Cacheは現在のデータのディスクへのコミットが完了するまでデータの入力を待つことになり、結果としてアプリケーションのレイテンシが高くなってしまいます。キャッシュ間でミラーし、一貫性を保証しなくてはならない入ってくるI/Oが多くなる、ストレージコントローラーのCPUは混雑してきます。大事なCPUサイクルを(とても多くの)コントローラー間のメッセージングに利用し、重要なデータサービスや機能に使わずに、無駄にしてしまうのことになるのです。

Fig98

FVPのWrite-Backでは、完了通知はFlashクラスタ内のFlashリソースにI/Oのデータ書き込みが完了したタイミングで通知されます。FVPはデータストアを置き換えることはしません、まだ、ストレージアレイにデータが書き込まれなくてはならない状態です。アレイに対してのデータ書き込みのプロセスはアプリケーションが既に完了通知をFVPから受け取っているので、透過的になります。これによってFVPはアレイが手順を実行しやすい形に変更できるようになります。殆どの場合はFVPは可能な限りデータを早く書き込もうとします、しかし、アレイが高負荷になっている場合に、FVPはI/Oの時間を自由にずらすことができるのです。この結果はIOパターンを一緒に表示したものです(上のデータストアの書き込みのパフォーマンスグラフ)。スパイクを平準化しすることで、例えば同じ数のI/Oをもっと長い時間にかけて分散することで、ストレージのコントローラーは入力されてくるストリームをより良く取り扱うことができます。結果としてキャッシュを強制廃棄することや、CPUのボトルネックを避けられます。

FVPはワークロードの高速化を実現します、読み取りと書き込みの高速化はアレイに対してのI/Oを削減し、ワークロードのパターンも削減します。FVPを導入したお客様は高速化したワークロードを体験するだけでなく、ストレージコントローラーのりよう率を改善し、外部や高速化していないワークロードに対してもいい効果を得ることができるのです。

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)