サーバ仮想化

夢はまだ夢

ひさびさにITネタ(笑)

マルチデータセンター、仮想DC、active-activeデータセンターなど、いろいろ言い方はあるものの、やろうとしていることは同じです。今まではactiveなセンターとstandbyなセンターを分けていましたが、リソース配分がうまくできない、切り替えに失敗するなど、問題がいくつかありました。基本的にstandbyセンターは止まっています。開発環境として利用することもありますが、ビジネスサイドからするともっと有効活用したいリソースです。また、切り替えについても、いざという時に実際に役に立つのかわからず、しかも不安なシステムほど切り替えについてはアンタッチャブルだったりして、不安要素になっていました。active-activeならいつも動いているので切り替えはうまくいく(若しくは切り替える必要もない)という漠然とした希望もあります。

みんな、なんとかならないかなあと思っていながらも、かかるコストが膨大なためなかなか手がつけられませんでした。一つの契機として東日本大震災があったのは否定しませんが、そんなモヤモヤを解決したいという思惑が元々あり、最近にわかに注目されてきています(そんな雰囲気を感じ取ったベンダーの営業戦略もあります)。

マルチデータセンターと言ってまず思いつくのが、GoogleやAmazonです。といっても彼らのサービスも実は限定的です。ワールドワイドレベルで同期通信は困難なので非同期通信を駆使します。当然非同期になると、アメリカのサーバーとヨーロッパのサーバーではデータが異なるタイミングがあるので、できることは限られてきます。結論をいうと、現状では企業の最も大事な基幹系システムは動かせません。

にもかかわらず、最近流行りつつあるのは、ネットワークが高速化してきたため、実現性が見えてきたことによります。同期通信の場合、まだ東阪は厳しいですが、200キロくらいまでなら実現性があります。東京から沼津が約100キロなので、結構遠くまでいけます。

また、ネットワーク単体が進化したというよりも、相性のいいソリューションがいろいろ出てきたというところが大きいです。特に重複排除や圧縮は相性がいいです。サーバー、アプライアンス、ストレージのどれも似たような技術を組み合わせ、キャッシュを駆使する流れです。

では、そこそこの距離までならば、今までのモヤモヤが払拭できるのでしょうか?私の感覚では、やってやれなくはないですよ、お金かかるけど、です。確かにactive-activeでセンターを運用するのは比較的容易です。でも、一つのシステムを2つのセンターで同じように動かして、いつでも使えるように、となると途端にハードルが上がります。つまり、経営者がバックアップサイトを有効に使えんのか!と言うことには応えられ、障害の時に切り替えをしなくてもいい、夢の運用にはまだ時間が必要です。

あ、cisco,EMC,vmwareに魂を売ればなんとかなりますよ。
スポンサーサイト

クラウド業者は鼠小僧?


今日は前々回に書いた「3)仮に見積もりで大きなリソースを必要としても、実態として使わないなら他で流用してしまう」の内容について書きます。

世の中の多くのシステムでは1.5倍理論のために使わない領域を抱えています。多分稼働率80パーセントのシステムなんて皆無です。50パーセント使えばかなり良いほうだと思います。そのため、論理的にはかなり無駄な投資をしていることになります。この投資をいかに効率的にするかが賢いITの付き合い方になるんだと思います。

しかし極力この無駄を省くことを追求すると、リスクが生まれます。それはまさかこないと思っていた1.5倍の需要が現実のものとなった時に起きます。エンジニアであればあるほどいい加減なことは言えず(良くも悪くも営業さんは勢いですが(笑))、この絶対にありえないまさかに対応できなければ安心できないのです。そのためのヒントが前回のリニアにリソース増強できるようにするに繋がります。

そもそも無駄だとは思っていてもリソースを用意してしまうのは、増強が追いつかないリスクに対しての結果であり、そこがクリアできれば安心して無駄な買い物を控えることができます。論理的には複数のシステムを集めることでこのリスク回避の領域を共有できます。

例えば、必要な領域10に対して50の余剰リソース(1.5倍を重ねた無駄)を構えるとシステムが10集まると、
(10+50)×10=600
となりますが、50の領域を10のシステムでシェアすれば
10×10+50=150
となり、かなり削減できます。そこそこの企業であればシステム数は10なんてことはないので、天文学的な余剰リソースがあることになります。

さて、やっとこさ本題に入りますが、これらのリソースをシェアするには仮想化技術が有効です。仮想化技術を使わずにリニアにリソース増強で頑張る方法もありますが、かなり苦労します。前回も書いたように大きく分けてリソースには
・CPU
・メモリ
・ディスク
があります。仮想化技術を使うとこれらをまとめて管理できます。また、注意したいのは仮想化技術をいくつものレイヤーで導入しないことです。所謂ハイパーパイザーを入れると不要になる仮想化技術はいくつもあります。実際には不要だと判断できなかったり、ハードウェアレイヤーからアプリケーションレイヤーまで一気通貫見れないために自分のレイヤーだけで効率化を考え、結果的に無駄が生まれます。

ちなみに、vmwareを例にすると、先ほどの3つのリソースのうち、CPUとメモリは設定でオーバーコミットができます。特に注意すべきはメモリのオーバーコミットですが、物理サーバーに普通に組んだ時と同じくスワップ状態になると急激にスローダウンします。ちなみにvmwareでは、ゲストOS起動時にはそれなりにメモリ容量を確保しますが、全く使わないと五分弱で使用していないメモリが解放されはじめます。もちろんゲストOSから見れば減ったようには見えませんし、物理的な限界を超えなければ再割り当てされます。

また、ディスクに関してはシンプロビジョニングという機能が使えます。これもディスクのオーバーコミットと言えますが、動きはメモリほど単純ではありません。というのはシンプロの場合、ファイルシステムの管理からは切り離されたものであるためファイルが不要になって削除してもディスクレイヤー(ストレージレイヤー)まで情報が伝わらないのです。そのため削除の多いシステムにおいては注意が必要です。ちなみにシンプロビジョニングはvmwareではなくストレージレイヤーでも利用できます。両方でやるのはあまり意味がないのでどこのレイヤーでやるかは考える必要があります。前回記載したプールの概念とうまく組み合わせて考える必要があります。

また、ディスクのオーバーコミット的な意味合いの技術として重複排除という機能もあります。オラクルのデータベースでは重複排除と圧縮を同時に行うことが可能です。オラクルの場合ディスクだけではなくメモリの削減もできるのでかなり魅力的です。ただ個人的にはバグが怖いので検証するとともに慎重に選択したいです。
その他、ファイルシステムやボリュームマネージャー、バックアップソフトなどでも重複排除できます。

なお、私なら普段使うデータはハイパーパイザーのシンプロビジョニングで合理化し、バックアップはストレージレイヤーでまとめて重複排除したほうがいいと思います。というのは、普段使うデータは同じデータパターンになることは可能性として低い(例えばお客さんごとにデータがあればそれぞれの名前などの情報は異なる)ため重複排除するよりもシンプロビジョニングで使わない領域を節約したほうが効率的だからです。逆にバックアップデータのように複数世代のデータを取る場合にはデータパターンが重複する可能性が高いからです。

多少バックアップについて触れると、個人的にはDataDomainのアーキテクチャは好きです。Netappからスピンアウトしたメンバーが設計しただけあって、基本設計はONTAPに似ていますが違った特徴もあります。DataDomainでは重複排除するためのセグメントが4~12KBの可変長に分割されます。重複部分を探すには全文検索の「分かち」と似たような感じなので可変長のほうがより重複しやすくなります。その他のストレージは固定長なのでセグメントの先頭で1バイトズレるとそれ以降全てが別のセグメントになってしまいます。

さて、タイトルの意味についてですが、どのクラウド業者もオーバーコミットを駆使しています。特に価格競争に勝つためには、仕入れを安くして、在庫を減らし、増強のリードタイムを減らします。特に在庫を減らすのは効果的なので使わないであろう領域はオーバーコミットします。中でも大口の客は大きく領域を確保しがちです。つまりその行為が義賊とされた鼠小僧に似ていると言えなくもないかと思います(大名屋敷から盗んで世間にばらまくという意味で)。とは言え、実際の鼠小僧が小判をばらまいたという事実はないようですが。。。

ということで、ITの無駄についてシリーズもの書いてきましたが、一旦ここまでにしようと思います。まだまだ気ままなブログは続きます。

過去の記事への補足

過去の記事
http://aufdai.blog69.fc2.com/blog-entry-91.html#comment129
についてコメントを頂き、書きっぱなしになっていたのを思い出しました。

実はvmware上でGUIが遅くなったと思っていたのですが、原因は違いました。結構調べるのに苦労しましたが、正解はカーネルパラメーターのhugepageを設定していたからです。これを設定したため、メモリがガッツリ確保され遅くなっていました。ちなみに、CLIで遅くならなかったのは単にメモリを使わないからなんでしょう。

また、vmwareから見るとOSが起動するとhugepageが設定してあるため、フルで物理メモリを使いにいきます。しかし、hugepageで確保した領域のアクセスが全くないため徐々ににメモリをvmwareが開放していきます。正確にはわかりませんが、動作を見ていると五分以内に開放する感じでした。

これらからわかることは、ESXにはメモリをはじめ、物理以上のリソースを割り当てる仕組みがいろいろあることです。もちろんそういった動作は様々なドキュメントに書かれていますが、実際にリソースが減っていくのを見ているのは面白かったです。

今回は結果的にいい実験になってしまいましたが、しばらく使われないリソースを開放していく時間やロジックについても抑えておいたほうがいいかもしれませんね。逆に必要になった時にどのくらいの速さで戻ってくるのかも注目ポイントかもしれません。

vForumに参加しました

vforum1

vForumに2日間参加しました。初日の基調講演ではvmworldでもあった寸劇が行われていました。仮想のの保険会社のやつです(笑)個人的にコメントしたい内容は以下です。

■vPostgresの内容について
vmwareがポスグレを出すというものです。調子に乗って同時通訳を使わずに聞いたのでわからなかった部分も少しありますがほとんど理解したつもりです。てかテクニカルな内容の同時通訳はイマイチです。気になったところはESXカーネルに多少手を加えているオリジナルなところです。個人的にはenterpriseDBと組んで既存のオラクルからの移行をしやすくして欲しかったです。まあ、それでも需要はあると思いますが。

■springなどのミドルウェアについて
最近vmwareは仮想化製品の会社からミドルウェアの会社に移行しつつあります。中でもオープンソース系の買収は激しいです。扱っている製品が幅広いのでコメントが難しいですが、一番面白かったのはライセンス形態です。今までは仮に仮想化ライセンスに対応していたとしても仮想CPU単位の購入でした。つまりシステムのピークに合わせてライセンスを購入する必要があります。ところが、今回vCenterとリソース情報を連携することで、利用した量のライセンス料になるようです。IBMのメインフレームみたいな感じですね。かなり合理的になるので、やっと登場したなあ、と思いますしこれから流行らないか期待したいです。

■テクノロジーセッションの可用性について
さすがにテクノロジーセッションというだけあって濃い内容でした。概念をわかりやすく説明していましたが、真意を理解できた人は少ないのでは?

まず、vSphere HAについてです。HAエージェントが刷新されています。FDMエージェントに変わったのですが、マスターは1つでそれ以外はスレーブという構成になります。そこで、ハートビートの仕組みが変わっています。今回からハートビートデータストア(要はvotingディスク)ができました。クラスタの仕組みを知っていれば何のためかはわかりますね。
また、動作についてネットワーク障害でクラスタグループが分断される(隔離ではなくネットワークパーティションの状態)についての細かい動作も紹介されていました。正直セミナーにしてはディープな内容で楽しかったです。特にマスターの無いほうのクラスタグループにマスターが選出されるロジックは確認する価値ありです。後日資料がダウンロードできるそうなので必ずチェックします。
あと、うれしい機能として地味ですが、アドミッションコントロールが複数台指定可能になった変更もありました。これもミドルウェアの製品対策には便利ですね。特に対オラクル対策(笑)

ネットワークの仮想化を考えてみる

私はITの中でもネットワークがわかりません。最も概念的なことはわかりますが、設計したことも、触ったこともありません。

そんなレベルですが、ネットワークにもクラウドの波が押し寄せているような気がします。特に、ロードバランサー、ファイアウォール、ルータの機能をどこに実装するかは今後の注目ポイントでしょう。全て仮想サーバー上に持っていくのか、はたまたスイッチ等のHWに集約してしまうのかは大きな分かれ道だと思います。

仮想サーバー上に配置すると、サーバー内通信がメモリ間の通信になるので高速化が期待できますが、そもそものロジック処理は遅くなるはずです。ネットワークの振り分けロジックは単純なものなので、HWに組み込んでしまったほうが明らかに高速です。専用チップに勝てる訳がありません。ただ、早ければいい訳ではないので、設計や実装の容易さも重要なポイントです。基本的に仮想サーバー上に配置したほうがいろいろな設定で融通が効きます。性能に問題がないのであれば扱いやすさを考慮すべきです。特に仮想化しておくとGUIでパーツを組み合わせる感覚でシステムが作れるようになります(最近そういうソリューションが多いです)。

結局、どっちに寄せるべきかの個人的な結論はないのですが、似たような話はストレージにもあります。RAIDなどの機能をボリュームマネージャーで実装してしまうのか、ストレージで行うのか、ということです。ストレージも中身はサーバーなんでネットワーク機器ほど単純ではありませんが。。。

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。