« 2015年4月 | メイン | 2015年6月 »

2015年5月

2015/05/25

DB ディープダイブ part 6 : クエリプラン、中間結果、一時DBとストレージパフォーマンス

本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はDB Deepdive part 6: Query Plans, Intermediate Results, tempdb and Storage Performanceで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

データベースのワークロード特性シリーズのパート6へようこそ。データベースは仮想化データセンタ内では最も多くのI/Oを消費するものの一つであると考えられています。データベースの操作とデータベースの設計はそれ自身が研究に値するものですが、データベースの設計の世界を少しかいま見てみるだけでも非常に面白いものだと考えています。データベースのエキスパートで、同僚でもある PernixData社の製品担当VPの Bala Narasimhan 氏のもとへ赴き、データベースの設計とそのI/Oの特徴について教えてもらいました。

このシリーズの過去の回 :

Part 1 - データベースの構造

Part 2 - データパイプライン

Part 3 - データベースチューニングのための補助機構

Part 4 - NoSQLプラットフォーム

Part 5 - クエリ実行プラン

以前の記事の中で、データベースのクエリオプティマイザを取り上げ、それがどのように動作しているかを紹介したしました。その際には TPC-H のようなクエリとSQLサーバのデータベースを用いて、クエリオプティマイザを利用する場合のクエリのストレージの要件について解説を行っています。

今日の記事ではストレージのパフォーマンスに影響のあるクエリ実行について切り込んでいきます。そのひとつは中間結果処理です。今日の内容ではPostgreSQLデータベース内のクエリオプティマイザを使用します。その理由はこれらの問題が特定のデータベース固有のものではないということをお見せしたいからです。言い換えると、ご紹介するものはデータベースが動作しているすべての環境で発生しているストレージのパフォーマンスの問題だということです。この話題を通して、これらのストレージパフォーマンスの問題はインフラストラクチャレベルで解決するのがもっとも良く、プロプライエタリのインフラにおける裏ワザやデータベース内部を書き直すべきではないということをお伝えしたいと考えています。

PostgreSQLのオプティマイザのツアーのあとは、もう一度SQLサーバへと戻り、SQLサーバでの処理の中間結果における恒常的な問題について取り上げます。これは一時DBと呼ばれます。ここではこれまでにどのような一時DBのパフォーマンスの問題を解消しようとする試みがあったかと、更に良い方法をご紹介します。

続きを読む »

2015/05/18

データベースワークロードの特徴とそのストレージアーキテクチャへの影響 part 5 - クエリ実行プラン

本ブログエントリーはPernixData社のシステムズエンジニアであるTodd Mace氏のブログ記事で、同社のテクノロジーエバンジェリストであるFrank Denneman氏がこの記事を自身のブログに転載したものを翻訳しています。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はDatabase workload characteristics and their impact on storage architecture design – part 5 - Query Execution Plansで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

データベースワークロードの特徴シリーズのパート5へようこそ。データベースは仮想化データセンタ内では最も多くのI/Oを消費するものの一つであると考えられています。データベースの操作とデータベースの設計はそれ自身が研究に値するものですが、データベースの設計の世界を少しかいま見てみるだけでも非常に面白いものだと考えています。データベースのエキスパートで、同僚でもある PernixData社の製品担当VPの Bala Narasimhan 氏のもとへ赴き、データベースの設計とそのI/Oの特徴について教えてもらいました。

このシリーズの過去の回 :

Part 1 - データベースの構造

Part 2 - データパイプライン

Part 3 - データベースチューニングのための補助機構

Part 4 - NoSQLプラットフォーム

データベースは企業にとってクリティカルなアプリケーションで、大抵はストレージの性能要件として高いものを要求します。このブログ記事ではデータベースツールを利用して、クエリレベルでデータベースがどのようにストレージパフォーマンスを要求するのか解説していきます。そして、PernixData FVPがデータベースのストレージパフォーマンス問題だけでなく、ストレージのパフォーマンスがボトルネックになってきた場合に発生するデータベースの管理性の問題までもをどのようにして解決するのかをご説明いたします。全編を通してデータベースのサンプルとしてSQLサーバを利用しますが、内容は幅広く応用可能です。

続きを読む »

2015/05/11

PernixData FVPの I/O プロファイリングの PowerCLI コマンド

本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はPernixData FVP I/O Profiling PowerCLI commandsで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

キャッシュ汚染を解消する」という記事の中で、管理者が一時的に仮想マシンのRead、Writeのいずれか、もしくは双方をキャッシュしないようにするPowerCLIコマンドがあるということをお伝えしました。

Read操作が発生した際、FVPはデータがホストから提供されるのか、それともストレージから提供されるのかを判断します。もしもキャッシュミスが生じたら(2)、データはストレージからの取得となります(3)。データのパフォーマンスを改善するためには、データはローカルの高速化リソースにコピーされてからアプリケーションに渡される必要があります(4)。これはフォールスライト(false write)と呼ばれる手順です。

Fig222

これらのコマンドを利用することで、FVPは頻繁にアクセスされるデータを高速化リソース上に残したまま、ストレージに対して直接Writeを発行することができます。FVPはキャッシュミスによってストレージから取得されるバックアップジョブやアンチウィルススキャンのためのデータをキャッシュ上のホットデータを上書きすることなく無視することができるのです。

Fig223

仮想マシン上のFVPの高速化を一時的に止めるためには、WindowsのPowerShellセッションを開き、FVP管理サーバへ接続します。Windows PowerShellプロンプトから以下のFVPコマンドレットを実行します :

Suspend-PrnxReadDataPopulation: このコマンドレットは特定の仮想マシンに対して、FVPがフォールスライトを行わないようにする際に利用します。

Suspend-PrnxWriteDataPopulation:このコマンドレットは特定の仮想マシンに対して、FVPがトゥルーライト(True Write)を行わないようにする際に利用します。トゥルーライトは仮想マシンがWrite-Backモードになっている際に発生します。

Suspend-PrnxReadWriteDataPopulation:このコマンドレットは特定の仮想マシンに対して、FVPがフォールスライトおよびトゥルーライトを行わないようにする際に利用します。

例えばSQL01という名前の仮想マシンのフォールスライトを停止するには以下のコマンドを利用します : 

Suspend-PrnxReadDataPopulation –Name "SQL01"

一つのコマンドで複数の仮想マシンに対しての停止も行えます :

"SQL01","SQL02","SQL03" | ForEach-Object {SuspendPrnxReadDataPopulation –Name $_}

$_ という変数にSuspend-PrnxReadDataPopulationに対して、データをパイプさせて利用されています。最初にこのコマンドが呼び出された時にはコマンドレットは SQL01という名前に対して実行され、二回目にはコマンドレットはSQL02に対して実行されます。以降同じです。

バックアップジョブが終了すれば、それに対応する再開のコマンドレットを呼び出します。

  • Resume-PrnxReadDataPopulation
  • Resume-PrnxWriteDataPopulation
  • Resume-PrnxReadWriteDataPopulation

例えば :

Resume-PrnxReadDataPopulation –Name "SQL01"

仮想マシンのフォールスライトやトゥルーライトが停止されていても、FVPはすべての操作を継続して実行可能です。例えば、Suspend- PrnxReadDataPopulationが有効になっていても、データがキャッシュされていれば、すべてのReadのI/Oは高速化リソースから提供されます。

ほとんどすべてのバックアップソリューションはPre-およびPost-コマンドを設定することができるようになっています。これらのコマンドを利用して、アプリケーションから頻繁にアクセスされるデータを残しながら、フラッシュデバイス上にバックアップによって発生する不必要な消耗や劣化を発生させないことができるようになっています。

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

2015/05/04

パート5 - キャッシュの汚染の解消

本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はPart 5 - Solving Cache pollutionで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

従来型共有ストレージでの仮想化データセンターの拡張性についての問題」シリーズではなぜ、相互接続された(ストレージの)各コンポーネントがうまく強調せず、一環したパフォーマンスを提供することが難しいのかの詳細をお話しています。根本的な問題としてはグローバルなコントロールプレーンが存在しないということがあげられます。消費者(仮想マシン)とその分散の具合、そして優先順位に基づいたリソースの配分を決定づけるための共通言語が存在しないということです。

すべてのものを織り込めるユニバーサルな言語の登場を待つ代わりに、業界はソフトウェアのコントロールプレーンのトレンドに湧いています。インテリジェンスをアーキテクチャの境界部分へと動かし、そしてリソースはコモディティ化されていきます。ストレージリロースを直接コンピューティングレイヤーに入れることは素晴らしいコントロール性を実現するだけでなく、リソースの消費と分散についての優れた洞察を行えるようにもします。このモデルが業界をキャッシュの汚染問題などの解決が難しい問題を解決に導いてくれます。

続きを読む »

2015/05/01

なぜなに Data Domain - 番外編その1 - ESXiのデータストアとして使ってみよう

たいへんごお邪魔をして恐れ入りますが、バブルの再来を祈願しましてまずは第3回となりましたバースさん情報をお伝えしたいと思います。バブルとバースさんは関係あるのか?第3回と言うけど過去2回の記憶がないな?という方はご面倒をおかけしますが当ブログの2014年5月1日の回および 2014年11月1日の回をご確認ください。 プロ野球・阪神タイガースが日本一になった昭和60年、巨人戦で、ランディ・バースさんの打席を皮切りに阪神のクリーンアップが放った3者連続ホームランは「伝説の!バックスクリーン3連発」 として今も語り継がれていることは皆さんご存知の通りです。 あの日からちょうど30年の今年4月17日、現在はアメリカ・オクラホマ州議会の上院議員であられますランディ・バースさんが大阪・梅田の阪神百貨店を訪れ阪神ファンとともに 「六甲おろし」を熱唱したのです。このタイミングでのまさかの来日に感涙です。 これはバブルの再来、好景気の兆候ではないでしょうか。

さて、好景気になれば今にも増して販売好調となるDataDomainをESXiサーバーのデータストアとして使ってみましょ うという企画です。 いいの?そんなことして?と、いいーんです。NFSエクスポートしたDataDomainの領域をデータストアとして利用することは公式にサポートされています。対応しているESXiサーバーとDataDomainOSのバージョンは下記のスクリーンショットを確認してみてください。

1

今回はDataDomainをVMのクローン先領域として利用するのはどうでしょう?というご提案です。クローンはバックアップとしての役割が大きいですので、プライマリストレージの領域を消費するのは少々もったいない気がします。なぜなに本編でご紹介しておりますように、優れた重複排除ストレージであるDataDomainに保存されたデータはとても小さくなります。そのため、DataDomainをクローンの領域として利用することはとても理にかなうのです。

次に、クローン運用を自動化する簡易的な手順を考えてみましょう。クローンはvCenterのスケジュール設定により自動化することができますし、ホットクローンなら起動しているVMにも対応できます。但し、同一のVMインベントリ名は1つしか使えませんので、毎日同一のVM名でクローンしたい場合は、クローン前にクローンVMを削除しておく必要があります。VMの削除はPower CLIで削除することにして、コマンド発行はWindowsのタスクスケジューラでスケジュール設定しておきましょう。

それでは、実際に既存VMのクローンをDataDomainに置いてみたいと思いますが、

まずは、DataDomainの管理画面からDataDomainにNFSエクスポートを設定します。(例:/backup/vm)

2

エクスポートが完了してもディレクトリは存在しませんので、LinuxなどNFSアクセスができるOSからDataDomainの/backup配下にvmディレクトリを作成します。

mount -t nfs 10.10.40.40:/backup /mnt
cd /mnt
mkdir vm

続きまして、vSphere Web Clientにログインしてデータストアを設定します。

3

4

5

完成したデータストアをターゲットにして、VMを一つクローンしてみます。

今回クローンするVMは、下記のようにプロビジョニング済サイズ120GBのシン仮想ディスクと、プロビジョニング済サイズ500GBのシックEager仮想ディスクを持つ計620GBのVMです。こちらを重複排除機能を備えないストレージによるデータストアにクローンしますと、1回のクローン毎に620GBの容量を消費します。1週間で約4.3TBになってしまいます。

では、今回用意したDataDomain上のデータストアを使用すると、どうなるでしょう。

Photo_2

1回目のクローンで約194GBの消費、10回のクローンで約403GBの消費となりました。素晴らしい結果ではないでしょうか?

最後に注意点を2つ。今回はVMのデータに変更を加えずにクローンを10回実施していますが、運用環境であれば、次回クローンまでに発生する差分ブロック分は増加すること、クローン領域の節約にはなりますがクローン時間の短縮になるわけではないという点にご注意ください。

弊社の営業担当にコンタクトできる方は、DataDomainの貸し出し機をご提供可能です。ぜひご検証ください。

たくやとまもる