« 2015年7月 | メイン | 2015年9月 »

2015年8月

2015/08/31

ワンちゃん、通勤ラッシュ、そしてストレージI/Oのベンチマーク パート1

本ブログエントリーはPernixData社のSystems EngineerであるPete Koehler氏のブログの翻訳版です。彼はもともとPernixData社の製品の1号ユーザーで、ブログでユーザーとして素晴らしい記事を幾つも投稿してくださっています。本年からPernixData社の社員になったそうで、記事を翻訳してもよいか確認したところ、すぐに快諾してくれました。

今回はそんなPete氏の記事翻訳第5弾です。

本記事の原文はDogs, Rush hour traffic, and the history of storage I/O benchmarking–Part 1で閲覧可能です。

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

x86ベースのサーバやワークステーションのパフォーマンスの検証の実施は欠乏の歴史でした。20年前、システムのパフォーマンステストを行う管理者は50MhzのCPUを使ったら25Mhzのシステムよりどれだけ早くなるか、ということぐらいしかやっていませんでした。それ以上の検証はほとんどありません。哀愁が漂いますが、とてもシンプルな時代でした。

時代を少し進めます。テストは少しだけ洗練されてきました。システムの最も遅い部分(ストレージ)を検証するのが良いということに気がついてきます。ですから、手法やツールがそれに応じて創りだされてきます。ストレージはSAN装置内の専属のLUNを利用することで物理的なサーバの境界を超えて来ました。LUNは共有されてはいません、しかし、ストレージ装置の入り口であるファブリックは共有されています。にも関わらず、ストレージをテストすることは一般的には殆ど変わらずに進んできました。仮想化が単一システムの専属LUNについての気づきを与え、この状況は大きく変わってきます。今日、ファブリックやストレージシステムの全てのコンポーネントは共有されています。

検証のためのツールは移り変わります。あるものは傍流として打ち切りになり、あるツールは多くのダイアルでチューニングが出来ます。しかし、ほとんどのものは物理ホストとローカルの回転ディスクを検証する想定で動作しています。実際のワークロードを真似用途するものは多くありません。なぜそうしなくてはいけないかがわからないからです。殆どの場合、ツールは負荷を生成してパフォーマンスの計測値の最終値を導き出します。スタートとフィニッシュの間に何があろうとそれは気にする必要がないのです。

テストの手法もさほどは進化していません。「トップスピード」を探し出す事以外の方法というのは無いのです。様々な負荷や圧迫が共有されているということに対しての考慮は無いのです。ストレージアーキテクチャと利用されるメディアは進化してきました、しかし、検証についてはほとんど気にされてきませんでした。ほんとうに考えるべきこと ー仮想マシン内で動作しているアプリケーションのパフォーマンスー はスピードと多くの議論の中で迷子になっているのです。

この記事では人工的に負荷生成するストレージパフォーマンス検証(ツールやテクニック)の欠陥をお伝えします。しかし、受け取り方を間違うと、それらは全く使いものにならないと思ってしまうかもしれません。実際には真逆です。正しい用途で正しく使えば非常に有効なのです。詳しくは後ほど。

意味のある計測としてのベンチマークの欠陥

「私はベンチマークは使わない、ユーザーがいるから」 - 古のTwitterのことわざ

実際のパフォーマンス特性を観察する以上に優れたことはありません、しかし、そのパフォーマンス計測を繰り返し行うための良い方法を見つけ出すのは少し手間です。実際のワークロードは様々に移り変わり、環境やユーザーエクスペリエンスに異なった影響をあたえるものです。パフォーマンスのテストシステムは重要ですが、そのテストツールがどのような負荷を生成しているのかをダダしく理解してこそ意味があります。

人工的なベンチマークはいくつかのメリットを提供します。大抵は動作させやすい、そして、時にはダッシュボードで結果を表示し、あとから参照しやすくしてくれます。しかし、これらのツールとテスト手法はよくある特性を生成するだけで、実際のデータパターンを反映したものを生成することはありません。そうなると以下の様な特徴があります。

  • 生成されるI/Oは対話的なループの繰り返しではない(訳注:ユーザーが実際に操作している場合のI/Oではない)
  • 実際のワークロードのように動的な変数を真似てくれない
  • クラスタ化されたコンピューティング環境では適切なやり方ではない

これら全てについて詳細に説明が必要です。ではそれぞれ見て行きましょう。

生成されるI/Oは対話的なループの繰り返しではない

典型的なI/Oの対話は以下の様なものです。データを取得します。そしてそれに何らかの処理をします。そしてそれを送信します。ワークロードのI/Oの「個性」はどのようなパターンで、どれぐらい対話が行われるかにかかっています。ワークロードを長時間観察していると、しばしば何度も頻繁に繰り返されることもあります。

データを取得し、何らかの処理をし、そのデータを書き込むことを考えましょう。これは犬がボールを拾ってきて、あなたがボールに付いたよだれを拭いて、もう一度投げると考えればわかりやすいでしょう。何度も何度も、その順番で行われます。もちろん、シングルスレッドでの話です。

Fig272

人工的な負荷生成はこれとは全く違う攻撃を仕掛けてきます。人工的なI/O生成器の仕事は全CPUサイクルを利用してできる限り早くキューを埋めてしまうことです。I/O生成器は周りのことは何も気にしません。データの処理を行うことはありません。そうしてほしいとは言われていないからです。比較するのであれば人工的なI/Oは以下の様なものになるでしょう。

Fig273

人工的な負荷生成器では、すべてのCPUサイクルで単一のアクションを発行し続けます。全くもって意味のないReadが要求され、Writeが発行されます。もちろん、特定の生成器はReadとWriteをミックスして発生させることができますが、それでも問題は残っています。意味のある対話が反映されておらず、これでは実際のワークロードを真似ることができないのです。

実際のワークロードのように動的な変数を真似てくれない

実際のワークロードは人工的な負荷とは非常に異なったリソース(CPU、メモリ、ストレージ)消費を行います。あらゆる場合において、ストレージI/Oは様々で、ReadとWriteの割合、I/Oサイズ、そして1つのCPUから多くのCPUのスレッドへと変化します。以下の2つの画像は単一の本番か同環境の仮想マシンから実際のI/Oを6分半にわたって採取したものです(vscsiStatsとExcelのSurfaceチャートを使っています-リンク先は英語)。重たいアクティビティの最中、それだけのタイプのI/Oが生成されているかがわかります。

以下はReadのI/Oについてのものです。I/Oの数、中心となるI/Oのサイズなどを見ることができます。4Kと32Kの間のサイズが多いです。

Fig274

以下はWriteのI/O数、そしてI/Oのサイズを表しています。サイズは32Kから512Kまでにわたっています。これは同じ仮想マシンで同じタイミングで起こっています。

Fig275

見て頂いてお分かりのとおり、たったひとつの仮想マシンでもRead/Writeの割合が刻々と変化しています。更に重要なのはI/Oのサイズと数はありとあらゆる値を示していることです。I/Oのサイズはストレージパフォーマンスに非常に大きな影響を与えます。ですから、正確にこれを真似することは非常に困難です。VMwareのI/O Analyzerはトレースファイルを作成し、実際のワークロードを再生させることで忠実にこれを再現しようとしていますが、これでも複数のホスト上で複数の仮想マシンが様々に渡るI/Oパターンを生成しているような振る舞いを再現することはできません。ストレージ装置の解析にも期待することはできません。ストレージはこのようにデータのパターンを見ることはできないからです。

クラスタ化されたコンピューティング環境では適切なやり方ではない

大抵、ストレージのパフォーマンステストを行おうとしているほとんどの管理者は、単一のシステム(仮想マシン)をセットアップして、バックエンドのストレージのピークパフォーマンス(IOPS、スループット、レイテンシ)を検証しようとします。一見してこれは理にかなっているように見えますが、この方法ではクラスタ化されたコンピューティング環境でとりまわされているデータが通る道を反映することができません。クラスタとして配置されたコンピューティングから出てくるストレージI/Oは州をまたぐフリーウェイの通勤ラッシュのような状態になります。フリーウェイのパフォーマンスは車をその上で1台運転してみることでは検証することができません。パフォーマンスの計測ができるのは複数の車で、異なる意志、目的地、大きさを持ち、様々な密集具合で負荷をかけた時に初めて可能となるのです。近年の交通シミュレーションとモデリングソリューションはこれらの様々な変数を考慮に入れて、もっとも重要な結果を改善しています。それは実際の交通です。

残念ながら、ほとんどの検証を行う人やツールはこの「たった一台だけの車」のアプローチを取ります。そして、クラスタ化されたコンピューティングレイヤという近年の仮想化インフラストラクチャの最も重要な要素を考慮に入れていないのです。いまも、そしてこれからもずっと、高速なストレージインフラストラクチャは与えられた数のコンピューティングノード(物理ホスト)すべてを取り回せなければなりません。結局のところ、I/Oはいつも仮想マシンで生成されます。仮想マシンが動作している全てのホストで生成されるのであって、バックエンドのストレージで生成されるのではありません。これは大変なことです、そしてしばしば見落とされています。

以下を見てください。これは実際の環境(従来のクラスタ化されたコンピューティングとSANのアーキテクチャ)でのI/Oアクティビティをイラストにしたものです。緑のラインはReadのI/Oを表し、赤いラインはWriteのI/Oを表しています。

Fig276_2

では、従来の人工的な負荷を生成するベンチマークのアプローチのI/Oアクティビティを見てみましょう。以下を見て分かる通り、全く異なったものになります。

Fig277

実際の環境で生成されるストレージI/Oはワークロードが動作しているクラスターの数によってことなります。ですから、(完璧とは程遠いですが)最低でも以下のようなテストを行うほうがはるかに良いです。

Fig278

単一ホストで生成できる負荷だけではその能力を使いきれないようなストレージを使っている場合には、この方法でストレージがどれだけの高い性能を出せるのかを確認することはよく行われています。ほとんどのストレージベンダーはこの数字を利用しています。同じ計測手法で数字を並べるのがマーケティングマテリアルにとっては優れているからです。残念ながら、これは実際の数字を図ることができていません。数字は仮想マシンから見た際の値です。実際にはどんなパフォーマンスのテストを行う際にも忘れてはいけない真実があります。ストレージ装置はかならずどこかでストレージ装置の特性もしくは通過するファブリックによって限界を迎えます。

あらゆるクラスタ化されたコンピューティングシステムにおいて、単一の仮想マシンを利用するだけではコンピューティングプラットフォームの完全な能力を図ることはできません。同じことがあらゆる分散ストレージアーキテクチャにおいても当てはまります。PernixData FVPのような、クラスタ化されたホストでの高速化ソリューションやハイパーコンバージドソリューションでは、適切にパフォーマンスを計測するために同様のアプローチが必要です。従来のデータパスを変形させる異なるアーキテクチャでのため、上記のようなテストを実施した場合、パフォーマンスの評価に役立ちます。このアプローチはどこで何をするべきなのかという重要なポイントに集中できます。仮想マシンのパフォーマンスが重要であり、物理ストレージ装置に見当違いなことをいくつもやることではありません。

Fig279_2

全てのホストからのI/Oを適切にシミュレーションすることでストレージファブリックやすべての接続ポイントのパフォーマンスを把握するための重要な要素です。ほとんどのファブリックはトラフィックが全然ないときには非常に高速です。残念ながら、実際の環境ではそうではないのです。環境が拡張していくにつれてファブリック由来の影響が出てくるということを理解するのは非常に重要です。それはファブリックはすべてのホストへの接合点であり、ストレージからのデータ取得やデータの書き込みを行っているからです。すべて(HBA、ストレージ装置のコントローラー、スイッチなど)に負荷をかけてシミュレーションしてみる必要があります。もしそうしたことがないのでしたら、私の大好きなFrank Denneman氏の記事を読んでみてください。パート3 - データパスはクラスタリソースとして管理されていない

複数ホスト上の複数の仮想マシンでのテストを行うと、クラスタ化されたコンピューティング環境全域にわたって、仮想マシン毎に高速化(WriteのバッファリングとReadのキャッシング)が行えるFVPを最もよく活用することができます。これはなぜFVPの分離アーキテクチャが非常に拡張性が良いのかという理由を説明することにもなりますし、なぜ実際のワークロードがこのアーキテクチャから非常に大きなメリットを受けられるのかという説明にもなります。

これで終わり、と思ったんじゃないですか?

人工的なベンチマークの方法が間違って使われているということを解説するためには1つの記事では足りません。パート2では近年の環境において単一のテストを行うだけでは不十分であるということを更に詳しく見ていきます。そしてさらに重要な事はいつ、そしてどのように有効にそれを活用するかなのです。

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

2015/08/28

IBM IPS製品ブログ(第2回目):システム構成やサイジングについて

みなさん、こんにちは。
IBM IPS製品ブログ第2回目は、IBM IPS製品のシステム構成やサイジングについて記載します。

以下が、IBM IPS製品(物理アプライアンス:GXシリーズ、XGSシリーズ)のシステム構成例です。

Environment1_2

IBM IPSには、アプライアンスを管理するための管理インターフェースとトラフィックを監視するためのモニター・インターフェースがあります。

モニター・インターフェースは、ネットワークに透過的(ブリッジ)にインラインで接続します。そのため、既存ネットワーク構成を変更することなく容易に導入可能です。

接続するモニター・インターフェースには、1A、IBのようなインターフェース名がありますが、1A、IBどちらのポートがInside、Outsideといった決まりはありませんので、1Aをインターネット側、LAN側のどちらに接続しても問題ありません。

1つのモニター・インターフェースを監視したいネットワークに接続して、IDSとして利用することも可能です。

IBM IPSの設置箇所としては、FirewallやWANに接続するルータの背後や公開サーバを保護するためにDMZに設置するケースが多いと思われますが、社内サーバの保護や、IP-VPNなどで接続される各拠点との境界に設置するケースもあります。

スタンダードモデルのGX4000シリーズ(Version 2)やXGS 3100シリーズについては、標準で2つのセグメントの監視が行えますので、1台で、DMZやイントラネットの保護を行うことができます。

以下は、IBM IPS製品(仮想アプライアンス:GVシリーズ)のシステム構成例です。

Environment2_2

初めに、仮想アプライアンスイメージをVMwareホスト上に展開します。

仮想アプライアンスにも物理アプライアンスと同じように、アプライアンスを管理するための管理インターフェースとトラフィックを監視するためのモニター・インターフェースがあります。
展開する過程で、各インターフェースをvSwitchにマッピングします。

Virtual

保護するサーバは、上記システム構成例では、接続先をvSwitch-2に変更します。

IPS仮想アプライアンス設置時の注意点ですが、VMwareの設定で、モニター・インターフェースに接続されるポートグループは、全て無差別モードに設定します。
無差別モードは聞きなれない表現だと思いますが、プロミスキャスモードのことで、通常スイッチのポートは自分宛のフレームしか受信しませんが、プロミスキャスモードにすると、全てのフレームを受信することができます。

次の注意点ですが、仮想スイッチとはいえ、ネットワークはL2ループにならないように構成してください。
もし、以下のようにモニター・インターフェースを同じ仮想ネットワークに接続してしまうと、ループによりブロードキャストストームが発生して、ネットワークが使用不能になってしまいます。

Loop


サイジングについては、スループット、防御するセグメントの数、接続するネットワークインターフェースの形状などで概算の見積もりを行います。
一般的な100Mbpsの回線であれば、スループット200Mbpsのモデル(GX4004C v2-200)を選定していただければ通常は問題ありませんが、携帯サイトやECサイトなどのショートパケットが多い環境やコネクション数が多い環境においては2~4倍の余裕を持たせるような構成を取ります。
そのため、100Mbpsの回線でもスループット800Mbpsのモデル(GX4004C v2)を選定するケースもあります。
最近では、クラウドサービスを利用されるケースも多いと思いますが、クラウドサービスも使い方によってはコネクション数が増加しますのでサイジングにおいて注意が必要です。

また、IBM IPSの管理については、SiteProtectorにて行います。詳細は以下URLをご覧ください。

https://www.ibm.com/developerworks/community/groups/community/SiteProtector/


以下、弊社WebページにもIBM IPS製品について記載がありますので、ご覧になってください。
http://www.networld.co.jp/ibm/hw.htm

また、IBM IPS製品については、導入サービスをご提供しております。詳細は以下URLをご覧ください。
http://www.networld.co.jp/introduction/ibm.htm

担当:小室

2015/08/25

VXLANについて

Wara2

今回はVXLANについて~

 

 

ブイエックスラン?

Kuma1

Wara2

VXLANっていうのはね、ネットワークのセグメンテーション、スケーラビリティ、IPモビリティを提供可能に出来るの。例えば、


1.標準化されたオーバレイ技術 (RFC7348)

2.約1600万のセグメンテーション

3.離れたDC間でのL2ネットワークの延伸を実現  

4.マルチテナント

5.L3技術によるECMPの実現  物理と仮想の統合を実現

かな

 

 

ぴゃー

Kuma7

Wara2

また、魂抜けてる

 

 

もう少し簡単にお願いします

Kuma4

Wara2

ん~、VXLANって簡単に言えばオーバレイなんだけどそれだと分かりずらいから、、実際にはこうゆう使い方しないけどたとえば・・・

8階でVLAN10(172.16.10.0/24)のネットワークを構築していました。ある日、SEにこう言われました

 

8階の場所が足りなくてさ、6階でも構築していたんだけど、VLAN30(172.16.10.0/24)のGuest環境と8階の端末と通信がしたいけど出来る?

あっ、VLAN IDの変更は設定変更と周辺機器との調整が大変で変更ができないんでよろしく

Uon3

 

3

 クリックで拡大可

 

VLAN IDの変更できないのじゃTagで流せないから、、、

うーん。。

そうか、設定変更とまわりとの調整しないSEをボコボコにしてVLAN IDの変更をさせればいいんだ

Kuma10

Wara2

そうね、それが一番いいかしら

 

エッ・・

Uon2

Wara2

こうゆう場合の時にでも「VXLAN」を使えばL3ネットワーク上に仮想的なトンネルを張る事で通信が可能なの

 

 

VXLANすごいー

Kuma8

Wara2

でもVXLANを使うにあたって、既存のネットワーク(アンダーレイ)の部分がちゃんとVXLANの通信が出来るように構築してあげる必要があるの

Ciscoだと

1.Multicast 

2.EVPN

の2種類ね

 

 

EVPN?

Kuma9

Wara2

Ethernet VPNね

簡単に言うと

BGPを利用しVXLANを張るためのVTEPの場所を学習する感じかしら

 

 

BGPとかMulticastとか難しそうだなぁ。。

Kuma4

Wara2

使っている技術はもともとよく利用されているものよ。

ちなみにACI ファブリック内では VXLAN が自動的に動いているからアンダーレイネットワーク部分のBGPやMulticastといった構成を考える必要がないの

 

 

ACIすごいー

ACI以外でも動作するの?

Kuma8

Wara2

CiscoならNX-OSで動作させる場合は、Nexus9000、Nexus5600、Nexus1000v系ね

Cisco以外でも標準化されたオーバレイ技術だからVMwareのNSX、Arista、JuniperのEXスイッチでも動作できるの

ただ、メーカサポート状況や互換性は都度確認する必要があるかしら

 

 

VXLANってすごい

もっと色々知りたいな

Kuma8

Wara2

 データセンターのネットワークで求められている問題が

1.自動プロビジョニング

2.標準化された技術

3.物理と仮想の混在環境の統合管理

4.オーバレイ技術

5.ワークロードモビリティ

6.スケーラブルなマルチテナント

とあり、VXLANでは、、

 

 

うっ・・

アプセトデネブみたいに・・縦読みで覚えよ。

自標物オワス・・・・ 

Kuma4

Wara2

Nexusに興味のある方は 

http://www.networld.co.jp/cisco/

の「お問い合わせ・ご相談はこちらから」からお気軽にご連絡ください

 

Cisco担当 松野

2015/08/24

インメモリコンピューティング -今日までの実装の調査-

本ブログエントリーはPernixData社のプロダクトマネージャであるTodd Mace氏のブログ記事を翻訳しています。 

本記事の原文はIn memory computing - a survey of implementations to dateで閲覧可能です。

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

このシリーズの前の記事ではメモリレーンを散策し、この20~30年でのインメモリコンピューティング(IMC)の進化について復習しました。この記事ではいくつかのIMCの特殊な実装に深く入り込み、今日までに行われてきたイノベーションとその制限について理解していきます。

バッファキャッシュ

バッファキャッシュはページキャッシュと呼ばれることもあります。これはオペレーティングシステムとデータベースに数十年も前から実装されています。バッファキャッシュはディスクアクセスを避けるために頻繁にアクセスされるデータをキャッシュするメモリの一部と説明されます。もちろん、バッファキャッシュを活用することでデータのアクセスがディスクまでいくことを避けられるため、パフォーマンスも大きく向上します。

バッファキャッシュはリードオンリーのキャッシュです。別の言い方をするとバッファキャッシュでメリットを受けられる可能性があるのはリードのためのアクセスだけです。それとは逆に、ライトは常にその下のデータストアに書き込まれなければなりません。これはRAMが揮発性のメディアであり、電源が落ちると、バッファキャッシュに乗っていたデータは永遠に失われてしまうのです。ご想像のとおり、これはデータベースがACIDコンプライアンスに準拠する際に非常に大きなかけになってしまうのですhappy01

以下の図はバッファキャッシュがReadとWrite双方でどのように動作するかを表しています。

Readについては最初のアクセスは必ず下のデータストアに行きますが、2度目以降のアクセスはバッファキャッシュから行われます。

Fig270

Writeについては常に下のデータストアに対して行われます。バッファキャッシュはいかなるメリットも与えることはありません。

Fig271バッファキャッシュがReadだけにしか効果が無いため、非常に限定的です。例えば、OLTPアプリケーションは非常に多くのWrite操作を伴います。これらのWriteは下のデータストアのパフォーマンスに準じるため、殆どの場合、Readがバッファキャッシュから提供されているというメリットを隠してしまうのです。

次に、バッファキャッシュのサイジングもしっかりとしたものがありません。バッファキャッシュのサイズが小さすぎると、メリットは全く得られなくなります。逆にサイズを大きくし過ぎるとそれはメモリの無駄遣いになってしまうのです。もちろん、更に皮肉なことに仮想化環境ではサーバのリソースは仮想マシン間で共有され、インフラストラクチャチームによって管理されています。そうなのです。バッファキャッシュのサイジングはアプリケーション固有の要件で、インフラストラクチャの要件では無いのに、です。結果として、他に同じホストでどんなアプリケーションが動いているのかはわからないまま、そして、どれだけのメモリがサーバで利用できるかということはわからないままこれを行うことになるわけです。

APIベースのインメモリコンピューティング

他にIMCを活用する一般的な方法にアプリケーション内でライブラリやAPIを利用するということが挙げられます。これらのライブラリやAPIによってアプリケーションにメモリをキャッシュとしてつかうことができるようになります。例を挙げるとすればmemcachedでしょう。memcachedがどのようなものかは次に述べます。以下はmemcachedを利用してメモリをキャッシュとして利用するサンプルです。

function get_foo(foo_id)     
foo = memcached_get("foo:" . foo_id)     
return foo if defined foo      
foo = fetch_foo_from_database(foo_id)     
memcached_set("foo:" . foo_id, foo)     
return foo 
end

この例では適切な場所でAPIが呼ばれるようにアプリケーションを書き直しが必要だということを表しています。APIに対する変更やアプリケーションのロジックの変更はすべて書き直しが必要です。

SQLでの類似した例がこちらです。

CREATE TABLE FOO (…..) WITH (MEMORY_OPTIMIZED=ON);

SQLでの例はユーザーとしてどのテーブルがメモリにキャッシュされるべきなのかを指定しなくてはならないということを意味しています。これをテーブルを作成するときに行わなくてはなりません。もしくは、すでに存在しているテーブルであればALTER TABLEコマンドを用います。御存知の通り、DDLの変更にも王道はありません。そればかりか、ユーザーとしてどのテーブルをメモリに保持し、どのテーブルはそうしないかをどうやって決めたら良いのでしょうか?そして、静的なスキーマの定義は今日のような動的な環境で果たしてうまくいくのでしょうか?また、このSQLの拡張はANSI SQLに準拠になるかどうかの保証もないのです。

いずれのケースもIMCを行うために、アプリケーションに根本的な変更を加えなければなりません。これはつまり、必要なAPIをサポートしているデータベースやライブラリに仕方なくアップグレードしなくてはならないということも意味します。そして、最後に、APIの振る舞いが変更されるたびにアプリケーションをいじらないといけないということも意味しています。

インメモリアプライアンス

最近では、ISVが彼らのアプリケーションをメモリ上で動作させているアプライアンスを販売していることもあります。巨大なDRAMを搭載できるサーバが一般的になってきたことから、このタイミングは理にかなっています。これらのアプリケーションは基本的にはRAMをリードオンリーのキャッシュとして利用します。バッファキャッシュのところでお話したとおりで、リードオンリーキャッシュには制限があります。

さらに、多くのアプリケーションはデータベースをACID準拠で動作させており、一貫性が主要件です。これはつまり、一貫性を保証するために、Writeは不揮発性のメディアに書き込まれなければならないということを意味しています。システム内にWriteが多く発生すると、パフォーマンスはRAMではなく、不揮発性のメディアに準じてしまいます。機械式のドライブではなく、Flashを利用することである程度はこれを緩和することができますが、インメモリコンピューティングのためのアプライアンスを買おうとしている人が、Flashのパフォーマンスしか保証されないということは不幸なことに見えます。

ほとんどのアプリケーションは非常に長い起動時間があります。大抵はデータを起動時にRAMにデータをキャッシュとして読み込みます。「オンデマンド」ではなく、データをRAMに事前に読み込んでしまうアプローチです。これはデータのサイズが非常に大きい場合に起動時間は非常に長くなってしまうということを意味しています。

最後に、運用の面から特定の目的のためだけのアプライアンスを利用するということは更にサイロを増やし、特殊な監視や管理を行うということを意味します。これは仮想化によってもたらされた素晴らしい価値を取り払ってしまうことにつながります。

まとめ

今日のIMCはエンドユーザーやアプリケーションオーナーがストレージのパフォーマンスを改善するために提供されています。しかし、問題はインフラストラクチャの中にあるのです。結果として局所的なプロプライエタリの最適化を行うことで、インフラストラクチャを最適に使うことができなくない、もしくは全てが上手く行かなくなるということが起こります。インメモリコンピューティングでストレージのパフォーマンスの問題をインフラストラクチャレベルでちゃんと解決する正しい方法は無いのでしょうか?結局のところ、ストレージパフォーマンスはインフラストラクチャのサービスなのです。詳しくは http://www.pernixdata.com(日本語版は http://www.networld.co.jp/pernixdata/) をご参照ください。

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

2015/08/17

ビデオ:インフラストラクチャレベルのインメモリコンピューティング

本ブログエントリーはPernixData社のプロダクトマネージャであるTodd Mace氏のブログ記事を翻訳しています。 

本記事の原文はInfrastructure Level In Memory Computing Videoで閲覧可能です。

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

PernixDataのCTOのSatyam VaghaniとプロダクトのVPのBala Narasimhanがインフラストラクチャレベルのインメモリコンピューティングについてお話をしています。

インメモリコンピューティングの新しい業界標準の形について学びましょう。既存のアプリケーションは一切変更を加えることなく、この先進性のメリットを享受できますし、インフラストラクチャレベルのインメモリコンピューティングを活用することで、将来、アプリケーションの開発はより簡単になっていきます。

さぁ、コップにお茶を入れて楽しんでください!

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

2015/08/11

★Syncplicity Panorama導入への道!その①★

★Syncplicity Panorama導入への道!その①★

皆さんこんにちは!

ネットワールドでEMCを担当しております渡会と申します。

今回初めてブログに投稿します!

Wataraiのコンセプトは「とりあえず検証してみた!シリーズ」で行きたいと思っています!

EMC社には一番のメインであるストレージ製品の他に

バックアップソリューション・クラウドソリューション・ビッグデータソリューション・セキュリティソリューションなど様々な製品を取り扱っています。

この中から私は「とりあえず動かしてみる!」をモットーに様々な製品の検証をおこなっていきたいと思います。

※注:本検証はとりあえず動かしてみるということが目的のため運用・障害等に関しては考慮せず検証を行っていることあらかじめご了承ください。

 

さてまず記念すべき第一弾の製品は!

 

パチパチパチ!!!Syncplicity!!!!パチパチパチ

を検証してみたいと思います!

検証結果に関しては2回に分けて皆さんにお伝えして行きたいと思います!

検証にあたりまずはこのSyncplicityという製品について簡単に説明したいと思います。

 

SyncplicityとはEMC社のストレージ製品と連携可能な企業向けのオンラインファイル共有サービスを提供する製品です。

 

※Syncplicityの詳細に関しては以下URLをご参照ください。

http://www.atmarkit.co.jp/ait/articles/1305/29/news002.html

https://japan.emc.com/about/news/press/japan/2013/20130930-1.htm

 

また、SyncpliticyはDropBoxのように使用することも可能であり現在では10GBまでであればどなたでも無料で使用することが可能となっており以下URLより登録可能なため皆さんぜひ試してみてください。

URL:https://www.syncplicity.com/

さて今回検証するのはSyncplicity Panorama Connectorという機能の検証となります。

このPanorama ConnectorとはWindowsサーバにインストール・設定を行うことにより自社内にあるEMC社製ストレージに対してiPadのSyncplicityアプリからアクセスを可能にする機能となっています。

このPanorama Connectorを使用することによりVPN等を使用せずとも安全なアクセスが可能になり、SharePointとも連携することが可能となっております。

※残念ながら今回はSharePointとの連携まではできませんでした・・・

簡単な構成としては以下のようなイメージとなります。

000

今回の検証ではロードバランサー等を準備できない関係もあり以下のような構成で検証を行いました。

0001

さてSyncplicityを検証する前に各種要件を以下に記載しておきます。

Syncplicity Connectorインストール要件

★サーバハードウェア要件

0002_2

★ソフトウェア要件

0003

★Syncplicity App要件

0004

それでは早速検証に入って行きたいと思います!

※第1回目はSyncplicity Panoramaの構築までを掲載します。

 第2回目にiPadからのアクセスを掲載する予定です。

1    VNXe3200 CIFSサーバ構築

Syncplicity Panoramaを構築する前にVNXe3200をCIFSサーバとして構築を行います。

VNXe3200の構築に関しては以下URLに弊社作成の動画がありますのでこちらを参考に構築をします。

 URL:http://www.networld.co.jp/emc/movie_vnxeguide3200.htm

  ★設計のコツ

  • Syncplicityで使用する場合\\ファイルサーバという指定はできないのでroot直下にまず1つフォルダを作成しそこを隠し共有するのがコツとなります。
  • Syncplicityで使用する共有に日本語は使用できないため上記の隠し共有を英語で作成しておきます。

2    Syncplicity Connectorインストールサーバの構築(Windows)

Syncplicity Connectorインストール要件に従いWindowsサーバを構築します。

3    Syncplicity Connectorダウンロード

以下URLを開くとファイルダウンロードが開始されるのでSyncplicity Connectorをインストールサーバに保存します。

URL:http://www.syncplicity.com/xPanoramaConnectorInstaller

ファイル名:Syncplicity Panorama.msi

※URL・ファイル名に関しては予告無く変更される場合があります。

4    Syncplicity Connectorインストール

①     インストールファイルを実行します。

001

②     Syncplicity Panorama Installerの[Welcome to Syncplicity Panorama]画面が起動するので「Next」ボタンをクリックします。

002

③     [License Agreement]画面が表示されるので「I agree to the license agreement」チェックボックスをオンにします。

003

④     「NEXT >」ボタンが有効化されるのでクリックします。

※チェックボックスをオンにしないと「NEXT」ボタンは有効化されません。

004

⑤     [Syncplicity Panorama installation progress]画面が表示されインストールが開始されるのでインストールが完了するまで待ちます。

※数分程度でインストールは完了します。

005

⑥     [Panorama Connector Successfully installed]画面が表示されるとインストールが完了となりますので「Finish」ボタンをクリックして完了となります。

※「Configure Syncplicity Panorama Connector」チェックボックスるをオンにしたまま「Finish」ボタンをクリックすると[Syncplicity Panorama]設定画面が表示されます。

006

5    Syncplicity Panorama Connector設定

①     Internet Explorerを開きます。

007

②     URL欄に以下URLを入力しエンターを押します。

008

③     [Syncplicity Panorama Home]画面が表示されるので[Configuration Wizard]欄の「Begin Panorama Configuration Wizard」をクリックします。

 009

④     [Step1 of 6:Service Account]画面が表示されるので以下を入力し「NEXT」ボタンをクリックします。

  • Active Directory Domain:対象のCIFSサーバ参加しているドメイン名
  • User Name:Syncplicityアクセス用アカウント名
  • Password:上記に対するパスワード

010

⑤     [Step 2 of 6:End-user Support]画面が表示されるので以下を入力し「NEXT」ボタンをクリックします。

  • Company Support Email Address:ユーザ様が問い合わせ行う際のメールアドレスを登録します。
  • Support Issue Types:サポート時に受け付ける問題の区分を選択します。 

011

⑥     [Step 3 of 6:Register Network Share Whitelist]画面が表示されるので「Allow access to All Network Shares」にチェックを入れ「NEXT」ボタンをクリックします。

012

⑦     [Step 4 of 6:Home Directory Share Bookmark]画面が表示されるのでチェックを入れずに「NEXT」ボタンをクリックします。

014

⑧     [Step 5 of 6:Enter Network Share Bookmarks(Recommended)]画面が表示されるので以下項目を入力します。

  • Display Name:UNCパスの管理名を入力します。
  • UNC Path:Syncplicityでアクセスに使用する共有のUNCパスを入力します。
  • 本環境ではroot直下に作成した隠し共有を指定しています。

015

⑨     「ADD」ボタンが有効化されるので「ADD」ボタンをクリックします。

016

⑩     画面上部に[A new bookmark was successfully added]メッセージが表示されることを確認し「NEXT」ボタンをクリックします。

017

⑪     [Step 6 of 6:Default Access Level]画面が表示されるので「Default Allow」にチェックを入れ「NEXT」ボタンをクリックします。

018

⑫     [Diagnostic Test Results]画面が表示されるのでエラーが無いことを確認し画面下部の「SAVE」ボタンをクリックします。

※SSLに関しては本手順では使用しないためDisableのままで問題ありません。

01901

⑬     [Next Steps:Authorize Mobile Access Through Policies]画面が表示されるので「Go to Manage Repositories」をクリックします。

 01902

⑭     [Home]画面に移動するのでSyncplicity Panorama Connectorの設定は完了となります。

020

以上でSyncplicity Panorama Connectorの設定が完了しました。

後はiPadで設定をするだけでiPadからファイルサーバを見ることができる!!!

と思ったのですが最近連日の猛暑により夏ばて気味なのでiPadでの設定に関しては次回記載したいと思います!

一日でも早く皆さんにこの続きをお伝えできるよう夏ばて解消にいそしみたいと思います!

それでは皆さん次回まだもう少々お待ちください。

そしてSyncplicity Panorama乞うご期待!!

2015/08/10

ストレージをコンピューティングリソース管理ドメインに配置することでパフォーマンスを隔離する

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

本記事の原文はPerformance isolation by aligning storage with compute resource management domainsで閲覧可能です。

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

仮想化データセンタ(もしくはクラウド)の設計において最も難しい課題はパフォーマンスの隔離です。仮想マシン内で動作しているアプリケーションは適切に動作出来るだけのリソース量を期待しますし、要求もします。とある仮想マシンのリソースの消費は他の仮想マシンのパフォーマンスに影響しないというのが理想的な状況です。

動的なリソース管理をあらゆる意味で失うことなく、特定の仮想マシンにリソースを割り当てるということが課題なのです。コンピューティングの予約などのマイクロマネージメントのツールを利用することはクラスタレベルの動的さへ影響します。これは様々なリソース管理のドメインを超えて設定されてしまうからです。ある仮想マシンのコンピューティング(CPUとメモリ)の利用は単一ホスト上の利用可能なコンピューティングリソースのプールに影響を及ぼします。ストレージリソースのドメインはクラスタや(仮想)データセンタにまたがります。つまり、ある仮想マシンのストレージに対する活動は他のホストで動作している仮想マシンにまで波及効果を及ぼしてしまうということです。必要な共有ストレージのリソースを提供しようとすると、別の形での管理、設計のアプローチが必要です。その後、コンピューティングリソースを提供すべきなのです。

ストレージの設計をする場合、ストレージ装置のリソースを可能な限り隔離しようとします。しかし、ストレージ装置は最低1つのリソースのドメインとして残ってしまい、更に大きなvSphereクラスタや仮想化データセンタ全体という構造体に影響を与えてしまいます。従来我々はリソース管理のツールを利用することなく、その上位レイヤの動的な、変わりゆくアプリケーションからの要求に対応してきました。これはストレージシステムが単一、もしくは複数のvSphereクラスタ内で動作している仮想マシンのワークロードの総和に対応できなければならないということを意味しています。

昔から「生まれてから、死ぬまで全てを受け入れてくれるバケツ」を設定するというやり方が使われてきました。設計者としてこれに何度も立ち会ってきています。しかし、想定される限り最高のパフォーマンスのピークに対応可能なストレージ装置が全てのライフサイクルの間必要になってくるのです。うまく動くことを願っています。そうでなければCFOやCIOのオフィスに何度も赴き、言い訳のための時間をスケジュールしたり、ストレージシステムのリプレースの前に以前購入したストレージ装置のアップグレードや増設をお願いしなくてはならなくなります。

アプリケーションが変わり、アーキテクチャが変わり、要求が変わり、ほとんどすべての顧客の期待も変わっています。近年のデータセンタはリソース管理のドメインが配置できるアーキテクチャが求められています。成長についても同じような計画が求められます。我々がプライベートデータセンタ、プライベートクラウドという時には、ある意味で、(一貫した)サービスレベル管理を期待しているのです。新しい仮想マシンが展開された時には以下の2つが満たされていなければなりません。

  1. 既存のインフラストラクチャは求められる(支払っているだけの)リソースを提供できる
  2. 既存のインフラストラクチャは新しいワークロードについて、今までに使っていた仮想マシンのサービスレベルに影響を与えずに吸収ができる

簡単に拡張できる ー拡張性(スケーラビリティ)ーは動的なリソースとともになくてはなりません。ストレージ管理をコンピューティングの管理に依存してしまうことはストレージのキャパシティとストレージのパフォーマンスの食い違いを再認識することになります。ストレージのキャパシティは成長しますが、大抵は一定の割合で成長します。減ることはほとんどありません。更に重要な事は仮想マシンはストレージのキャパシティをアプリケーションの活動がどうであれライフサイクル全般にわたって消費します。ストレージパフォーマンスは仮想マシンが活動している時にしか必要とされません。つまり、ストレージのキャパシティ管理はストレージパフォーマンスとは異なる動きをしているのです。仮想マシンの活動がコンピューティングとストレージのパフォーマンスを消費すると、これらのリソース管理ドメインが別々に割り当てられます。ですから、この2つは同じ拡張性のモデルが必要なのです。

拡張性は必ずしも、アドホックな設計になるということではありません。期待されているワークロードに合わせていけるアーキテクチャであればよいのです。必要とされる適応性のレベルで拡張できるようなアーキテクチャです。ストレージパフォーマンスの管理ドメインをコンピューティングの管理ドメインに寄り添わせることで、よりよいパフォーマンスの隔離のモデルを作ることができるのです。

これのとても良い例がサーバサイドメディアを利用してストレージのパフォーマンスを提供することです。これは一石三鳥です。拡張性、パフォーマンスの隔離、そして最近のデータセンタテクノロジーの最先端を活用することができます。数多くのサーバサイドソリューションがありますが、私はPernixDataのチーフテクノロジストですから、PernixData FVPをこの検証に使っています。

ご理解しやすいように、単純な検証にしました。この検証では3つの仮想マシンがストレージ装置のパフォーマンスとキャパシティの双方を消費します。それぞれの仮想マシンは別々のホストで動作しています。ストレージ装置はだいたい30,000~40,000 IOPSで動作しています。ご注目いただきたいタイミングは10:10 am、10:17 am、10.28 am そして 10:34 amです。表示のとおり、負荷は一定的で変わっていません。

Fig262

上で列挙したタイミングで仮想マシンの電源をOn/Offしています。10:03~10:10の間、仮想マシンは30,000IOPSを消費しています。しかし、次の仮想マシンの電源がOnになるとパフォーマンスは半分になっています。10:17に3番目の仮想マシンがパワーオンされ、10:28にパワー・オフされるまで負荷をかけています。即座にストレージ装置は動作している仮想マシンに対して、利用可能なパフォーマンスを再配置しています。10:34に2つ目の仮想マシンが停止し、再び最初の仮想マシンがすべてのパフォーマンスを独り占めする状態に戻っています。

Fig2632番めの仮想マシンのスクリーンショットも同じ傾向を示しています。30K IOPSまでは出ていませんが、3番目の仮想マシンが起動してくるまでは19K IOPSほど利用できていました。

Fig264今回の検証は定常的な負荷ですが、共有リソースを利用している際の他の仮想マシンの波及効果をうまく説明しています。同じようなことはバーストするOLTPのワークロードを仮想マシン内で動作させている際にも起こります。グラフの左側は1台の仮想マシンでワークロードを動作させていますが、グラフの右側は3つの仮想マシンで同じワークロードを時間差で動作させて負荷が何度もピークに達するようにしています。

Fig265パフォーマンスは適切なワークロードの分散が行われていたとしても、ストレージシステムの内部動作によってパフォーマンスが低下します(キャッシュオフロード、データパス管理、データの受取、I/O完了通知、など)。

Fig266サーバサイドリソースを利用してストレージパフォーマンスを提供する場合、それはホストレベルのリソース管理ドメインにもたらされます。スケールアウトはホストレベルでなされ、あるホストで動作している仮想マシンは他のホストで動作している仮想マシンへは影響しません。サーバサイドメディアを利用することで、共有のキュー(待ち行列)、ストレージエリアネットワークコンポーネント、そして、絶対的な物理の法則(距離がある=遅い)ということも避けられます。

同じ検証内容で、最初の仮想マシンはサーバサイドメディアのパフォーマンスを利用できるようにしました。今回はIntel DC P3700のNVMeカードを利用しています。仮想マシンはアプリケーションが生成するIOPS全体をストレージから消費します。注目いただきたいのはボトルネックがストレージから取り除かれているということです。これまではストレージ装置が生成可能なだけのIOPSに制限されていたのです。これは大きな違いです!今日のフラッシュテクノロジーによって、ほとんどのIntel DC P3700のようなサーバサイドリソースはほとんどのミドルレンジのストレージ装置と互角に渡り合い、圧倒することができます。それに加えて、ワークロードに非常に近いことから、非常に一貫したパフォーマンス(レイテンシ)を提供することが可能です。今回の場合、アプリケーションは70,000IOPSよりちょっと大きいIOPSを要求しています。2:29PMに面白いことが起こっています。2番目の仮想マシンが別のホストで動作を開始しても、同じパフォーマンスを維持しています。つまり、他のホストで動作しているワークロードから、完全に隔離されたのです。

Fig267

2番目の仮想マシンも必要なリソースを利用することができています。クラスタ内の他のワークロードに影響をあたえることなく、この仮想マシンは最大で90,000 IOPSを生成できています。

Fig268

サーバサイドメディアのリソースがそれ自身でリソース管理のドメインをもち動作するので、クラスタは継続的にパフォーマンスを拡張できます。FVPは耐障害性モビリティを提供するためにクラスタ機能をもちいますから、このパフォーマンスの隔離は他の重要なストレージ機能にくらべ言及されることがすくなくなっています。他の重要なストレージ機能については今回の記事の範囲を超えてしまいます。

Fig269素晴らしい点は、パフォーマンスがスケールできているということです。あたらしい仮想マシンが展開されても、それらは他のワークロードからは隔離されています。既存のアプリケーションのSLAには影響を与えないのです。既存のシステムが導入されてくるワークロードに十分なリソースを割り当てられなかった場合、スケールアップする、つまりリソースをホストに追加するか、更にクラスタにホストを追加してスケールアウトすることができます。サーバサイドメディアを追加することで、ストレージパフォーマンスの能力がコンピューティングのリソースと同じ様に向上します。活動中の要求に対して美しく寄り添うのです。フラッシュ技術の今日の先進性によって、もしくはRAMを高速化リソースとして使うことによって、パフォーマンスは今日ハイパーバイザーにサポートされている、利用可能な最も新しいモノを活用してパフォーマンスを向上させることが可能です。サーバサイドハードウェアの新しいものへの対応はストレージハードウェアの何倍も早いのです。

このアーキテクチャは仮想化データセンタ(クラウド)でのパフォーマンスの隔離を実現します。そして、ストレージシステムへのワークロードのオフロードを抑えることができます。つまり、これはキャパシティに捕まってしまっていた(GBあたりのIOPSの制限)状態から自由になれるということです。そして、よりよい拡張していくキャパシティ管理のモデルを提供します。多くのFVPの顧客はRAIDレベルを変更するようになってきています。それはパフォーマンスによって制限を受けることがなくなり、もっとキャパシティを経済的に利用するモデルへと移行できるからです。ストレージ装置の設計はキャパシティ主導になっているからなのです。

2015/08/03

仮想化データセンターに透明性をもたらす

本ブログエントリーはPernixData社のVP MarketingであるJeff Aaron氏のブログ記事を翻訳しています。 

本記事の原文はBringing Clarity to the Virtual Data Centerで閲覧可能です。

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

いつから始まったのか、正確にはわかりませんが、見る限りほとんどすべてのアクション映画は3Dとして撮影されるようになっています。どこか ー おそらくはアバターがシナリオは2流にもかかわらず、制作会社に改革をもたらしたあと ー 3Dでの映画のほうが、視聴体験が良く、多くの市場において受け入れられると実証されたのしょう。結果として、我々は今、大ヒットアクション映画は3Dオプション付きで封切りされるようになっています。

Fig259

しかし、適切なメガネを装着せずに3D映画を見るとどうなりますか?みんなやったことがありますよね? 映像はぼやけてしまいます。すべての素晴らしい映像効果は完全に失われてしまいます。

仮想化はデータセンタに同じことをもたらしました。比類なき柔軟性、統制、そしてコスト削減をもたらしたのです。しかし、これは可視性については枷をもたらすことになりました。

言葉を変えると、仮想マシンが動的になればなるほど、仮想化データセンタを効率的に設計、監視、トラブルシュートするのが難しくなるのです。正しい管理ツールがなければ、すべてのものがぼやけてごちゃごちゃになってしまい、最初に仮想化を導入した時のメリットは薄れていくことになるのです。

アプリケーションとインフラストラクチャの間のキャズム(巨大な亀裂)

従来から、仮想化データセンタ内のアプリケーションのパフォーマンスを最適化するのには2つの方法があります。ワークロードをチューニングし、インフラストラクチャの制限を隠してしまう(memcachedのような特殊なインメモリコンピューティングのテクニック等)か、特定のアプリケーション向けの専用のサイロ(プロプライエタリのデータベースアプリケーションやNoSQLのクラスタ)を作成することです。前者を採用した場合、各々のアプリケーションのオーナーは、下にあるインフラストラクチャについて、不完全な情報しか持たないままに決定を下すことになるため、意図せずして、恐るべき「ノイジーネイバー(やかましいご近所さん)」効果を引き起こすことがあります。後者を採用した場合、アプリケーションのサイロが運用と管理のオーバーヘッドを引き起こし、追加コストと複雑性につながってしまいます。

問題の一部は今日、データセンタの設計や管理に利用しているソフトウェアのツールが、構造上の制限を継承していることにも由来します。

例えば:

  1. サードパーティのデータにだけ多く依存している。結果として、データが取得可能なものについては効果を発揮しますが、それ以外には効果がありません。例を挙げると、サーバサイド運用管理製品はvCenterの統計に依存しており、CPUの利用率のようなコンポーネントレベルの計測値だけにフォーカスしています。
  2. ほとんどがレポーティング中心です。問題が発生した時に、「LEDが光った」などの通知を提供しますが、すぐに問題を解決する方法を提供できるわけではありません。
  3. ほとんど大多数が受け身型です。どのように様々な問題を解決していくのか推奨してくれるものはほとんどありません。

アプリケーションのプロファイルや仮想マシンの振る舞いのパターンを効果的に可視化する方法ないことで、インフラストラクチャとしての決定として最高のもの(「オールフラッシュ装置なら絶対にパフォーマンスの問題を解決してくれるに違いない。」)を選ぶことも少なくありませんし、もしくは、近視眼的に特定の問題を修正するための決断(「一時データベースのために別のLUNを作って負荷を逃してやろう。」)もあるでしょう。これの結果としては、終わることのない問題発生、そしてそれを治すということを続けていくという状況になります。このような一時的な対処を続けていくという対処は結果として「業界のベストプラクティス」に支配されていくということになるわけですが、これは全ての環境にとって理想的というわけではありません。

PernixData Architect ソフトウェアのご紹介

Fig260_3

理想的には、データセンタの設計者は設計、展開、運用、改善のライフサイクルを繰り返していくことになります。これが動作し続けている、仮想マシンを完璧に設計するための動的なやり方です。

史上初、完全に単一のソフトウェアプラットフォームでこれを実現できることができるようになりました。PernixData Architectです。

PernixData Architectはサーバサイドのハードウェアに依存しないソフトウェアで、仮想化データセンタ内のアプリケーションとインフラストラクチャの計画、監視、そして最適化に利用することができます。あらゆる仮想化データセンタにおいて、仮想マシンとインフラストラクチャ双方の振る舞いについて比類なき視認性をもたらし、それら2つを俯瞰しながら相関づけたり、ストレージとアプリケーションのパフォーマンスをどのように最適化するのがベストなのか、リアルタイムに推奨することができます。我々は赤いチカチカする光を皆様にお見せするのに興味が有るわけでなないのです。我々はそうしなくてもいいように皆様をお助けしたいのです。

Fig261

我々はただ単に様々なストレージやアプリケーションのデータを集めて統計を表示することには興味はありません。我々はこの「ビッグデータ」を統合し、実際のアーキテクチャの決定に必要なだけのナレッジを提供したいのです。

詳しく知りたいという方には我々のCTOであるSatyam VaghaniがVirtualization Field Day 5で行ったプレゼンテーションを聞いてみてください。その場で彼はPernixData Architectの更に詳細をお話しています。このビデオについては大ヒットの素晴らしいソフトウェアにもうすぐもたらされる面白いこととして考えてください。さぁ、ポップコーンを抱えて、リラックスしてください。データセンタ設計の新しい波がスクリーン(コンピュータ)のすぐ近くまで来ています!

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

2015/08/01

クラウドにバックアップするには?(API編)

こんにちは。バックアップ製品担当の臼井です。弊社では色々なメーカーのバックアップソフトを扱っておりますが、最近は、クラウドにバックアップしたい!というご要望をいただく機会が増えてきました。そこで、この場を借りて、クラウドにバックアップする方法や製品をご紹介していきます。


クラウドにバックアップと言っても、色々な方法がありますが、まずご紹介したいのは、バックアップソフトからクラウドのAPI(REST API)を使用してバックアップする方法です。バックアップソフトを使わずにAPI連携となると、スクリプトをガリガリ書く必要があり、APIやプログラミングに精通している人でないと難しいかもしれません。


しかし、バックアップソフトと組み合わせれば、難しいことは裏でバックアップソフトがやってくれるため、バックアップ管理者はAPIを意識する必要がありません。ただし、それには、バックアップソフトがクラウドを理解している(=クラウドに対応している)必要がありますが、Symantec/VERITAS NetBackup は、いち早くクラウドに対応しています。

Nbu77_4

7月9日に新バージョンであるNetBackup 7.7がリリースされましたので、7.7をベースに設定を見ていきましょう。クラウドの設定もウィザード形式で簡単に設定できるようになっています。「Configure Cloud Storage Server」をクリックします。

Nbu771


NetBackup 7.7では、Amazon S3やGoogle Cloudなど複数のパブリッククラウドに対応していますが、ここではAmazon S3で選択します。
Nbu772
  
Amazon側の[Access key ID]と[Secret access key]を入力します。

Nbu773


クラウドへのバックアップとなると、心配なのがセキュリティですが、NetBackup はAES256bitでの暗号化もできるので安心です。設定も暗号化のチェックを入れて、パスフレーズとIDを入力するだけです。

Nbu774_2
ウィザードを進めていくと、S3に作成済みのバケットが見えてきます。

Nbu775


ウィザードの実行前にバケットを作成していない場合でも[Add New Volume]をクリックして、NetBackupからS3のバケットを作成することもできます。リージョンも指定可能です。

Nbu776

バックアップ先のバケットを指定したら、バケット用の暗号化パスフレーズを入力します。

Nbu777
次に、NetBackup上からS3のバケットをバックアップ先として管理するための設定をします。S3をバックアップ先とするディスクプールを作成し、そのディスクプールに割り当てるストレージユニットを作成します。
Nbu778

Nbu779
これで、ウィザードは終了し、クラウド(Amanzon S3)へバックアップする設定は完了です。

Nbu7710


後は、バックアップジョブの中の[Policy Storage]で、作成したストレージユニットを指定するだけです。これだけでクラウド(Amazon S3)へバックアップできます。
クラウドへのバックアップとなると、データ量(料金)やバックアップ時間が心配な方もいるかもしれませんが、NetBackupのアクセラレーター機能と組み合わせれば、フルバックアップは最初の1回だけで、後は永久に増分だけにすることが可能です。コスト削減やバックアップ時間の短縮も実現できます。アクセラレーターの設定も[Use Acceralator]のチェックを付けるだけ簡単です。

Nbu7711

NetBackupならクラウドへのバックアップも簡単・確実です。クラウドへのバックアップをお考えの方は、NetBackupを検討の価値ありです!NetBackupを試してみたいという方は、下記から評価版をご依頼ください。
http://www.networld.co.jp/symantec-dp/call.htm

次回は別の方法でのクラウドへのバックアップをご紹介する予定です。それでは、また。

※参考情報