Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2015年9月

月別アーカイブ: 2015年9月

vCloud Airを使った災害対策 〜構築編 ・後半〜

ソフトバンクC&Sの幸田です。VMware vCloud Air構築編の後半になります。

記事の流れ
1回:vCloud Air DR 2.0 概要編
第2回:vCloud Air DR 2.0 構築編
(前半) vSphere Replication のデプロイ
・(後半) vCloud Air を退避先として登録/・仮想マシンの保護設定 本記事 
第3回:vCloud Air DR 2.0 活用編

前回の構築編ではオンプレ環境にvSphere Replicationを構築しました。このvSphere Replicationが仮想マシンをDR先に飛ばすコンポーネントになります。今回はDR先の登録(もちろんDR先はvCloud Air)とDRしたい仮想マシン(保護したい仮想マシン)の登録方法をみていきます。

vCloud Air を退避先として登録

vSphere Replicationのデプロイ完了後、Web Clientのホーム画面に”vSphere Replication”のアイコンが出現しています。アイコンをクリックして、退避先のvCloud Air Disasterの指定を開始します。

2-2-1

「ホーム」タブを選択し、「管理」をクリックします。

2-2-2

下図のアイコン(マウスカーソルを合わせると「クラウドプロバイダを…」とメッセージが出現)をクリックします。

2-2-3

退避先となるvCloud Airの情報入力を行います。必要な情報はvCloud Airにログインして確認します。入力完了後、「次へ」をクリックします。

2-2-4

vCloud Airにログインし登録に必要な情報を取得します。
↓↓
2-2-5

(Web Clientに戻って)vCloud Airから取得した情報を入力します。

2-2-6

vCloud Air DR2.0の仮想データセンタを選択します。「選択されたオブジェクト」タブにも同様の仮想データセンタが表示されていることを確認し、「次へ」をクリックします。

2-2-7

2-2-8

入力したvCloud Air DR2.0の情報が表示されます。誤りが無いことを確認し、「終了」をクリックします。

2-2-9

しばらくするとvCloud Airへの接続が完了した旨のメッセージが「最近のタスク」に表示されます。ただしこの時点では、ステータスに「ネットワーク設定の欠落」との文言と赤色の警告マークが表示されています。ネットワーク設定を行うため、先ほど設定したクラウドをクリックし、表示された下図のアイコンをクリックします。

2-2-10

ここではDR2.0にバックアップされる仮想マシンが、クラウド上の仮想データセンタ内に用意されているネットワークのうち、どこへ接続されるようにするかを指定します。

2-2-11

別途vCloud Airへログインし、ネットワーク名を確認して接続を行います。ここでは”DR-NW”として設定します。選択後、「次へ」をクリックします。

2-2-12

誤りが無いことを確認して「終了」をクリックします。

2-2-13

しばらくしてステータスが「接続中」となります。

2-2-14

ここまででバックアップ先となるvCloud Air 仮想データセンタの指定は完了です。

仮想マシンの保護設定

最後に、オンプレミスにあるDR対象仮想マシンに対して設定を行います。オンプレミスの仮想マシンの状態は、定期的にvCloud Airへ自動同期されます。
このステップでは、同期を行う時間間隔や、保持する世代数を指定します。

オンプレミスにて、Web Clientの「ホストおよびクラスタ」のインベントリから、DRしたい仮想マシンを右クリックして、「すべてのvSphere Replicationアクション」のメニューを表示させ「レプリケーションの構成」を選択します。

2-2-15

表示された設定画面にて、「クラウド プロバイダに複製」を選択し「次へ」をクリックします。

2-2-16

これまでの手順で退避先として指定したvCloud Airの仮想データセンタを選択して「次へ」をクリックします。

2-2-17

仮想マシンのバックアップのデータ配置先を選択する画面が表示されます。ここではデフォルトのままとし、「次へ」をクリックします。

2-2-18

仮想マシンデータをコピーする際、OSの静止オプションと、レプリケーション時のネットワーク圧縮設定を指定します。ここではデフォルトのままとし、「次へ」をクリックします。

2-2-19

次に、バックアップする仮想マシンのRPO、およびインスタンス(仮想マシンのバックアップデータ)の保持期間と個数を設定します。ここでは、2時間毎のRPO、1日4個のインスタンスを6日間分保持する設定(合計24個保持)とします。「次へ」をクリックします。

2-2-20

設定の一覧が表示されます。誤りが無いことを確認し、「終了」をクリックします。

2-2-21

設定に問題がなければ仮想マシンの同期が開始され、Web Clientの「最近のタスク」内で進捗および完了が確認できます。また、vCloud Airのポータル画面に仮想マシンが追加されていることが確認できます。

2-2-22

以上、オンプレミスの仮想マシンをDR設定するまでの作業ステップをご紹介しました。

仮想マシンの保護設定は、対象仮想マシン分実施する必要がありますが、手順も簡素なものとなっておりますので、是非お試しください。次回の活用編では、フェイルオーバーテストの実施方法や、実際のフェイルオーバー・フェイルバックなどを実施する方法をご紹介します!

第1回:vCloud Air DR 2.0 概要編
第2回:vCloud Air DR 2.0 構築編
(前半) vSphere Replication のデプロイ
・(後半) vCloud Air を退避先として登録/・仮想マシンの保護設定 (本記事)
第3回:vCloud Air DR 2.0 活用編
(前半) フェイルオーバー試験テスト/フェイルオーバー
・(後半)フェイルバック

vCloud Airを使った災害対策 〜構築編 ・前半〜

引き続きソフトバンクC&Sの幸田さまより、機能強化された VMware vCloud Air のDisaster Recoveryサービスについて2回目の寄稿していただきます。それでは幸田さま、よろしくお願いします!!


みなさまこんにちは、ソフトバンクC&Sの幸田です。
一般的にDR環境は、オンプレと同等の環境を用意する必要があり、構築と運用の観点から敷居の高い代物となってしまいます。オンプレにある仮想マシンの退避先としてvCloud Airを使用していただくことによって、災害対策をより身近にご使用いただけることを目指しております。

今回は、そのvCloud Air DRサービスをご使用いただくための手順(前半)をご紹介します。

2-1

vCloud Air DR 2.0 の構築は3つのステップを踏みます。(オンプレミス側にはvSphere環境がある前提で話をすすめます。)

・vSphere Replication のデプロイ
・vCloud Air を退避先として登録
・仮想マシンの保護設定

本記事ではまずオンプレミス側での作業 vSphere Replicationの構築から実施していきます。できるだけ実作業に沿った画面付の手順のため、記事が長くなってしまいますが…最後までお付き合いください。

vSphere Replication のインストール

仮想マシンをvCloud Airへ退避させるためには、オンプレミス環境にvSphere Replicationをデプロイします。

vSphere ReplicationはVMwareよりOVFテンプレートが提供されている仮想アプライアンスです。デプロイ作業は短時間で完了します。まずはMy VMwareからvSphere Replicationをダウンロードします。

2-2

※バージョンの表記は当記事の作成時点のものです。最新版をダウンロードしてください。

ダウンロードしたデータの中にOVFファイルが含まれていることを確認しておきます。

2-3

vSphere 環境の管理画面から「OVFテンプレートのデプロイ」を選択し、vSphere Replicationのデプロイを開始します。

2-4

My VMwareからダウンロードしたOVFファイルを選択します。

2-5

2-6

詳細の確認画面では「次へ」を、利用規約の同意画面では「承諾」を選択したうえで「次へ」をクリックします。

2-7

2-8

vSphere Replicationの仮想マシン名とデプロイ先リソース(データセンタやフォルダ)を選択して「次へ」をクリックします。

2-9

割り当てる仮想CPU数(2または4)を指定して「次へ」をクリックします。

2-10

仮想ディスクを配置するデータストアおよび配置フォーマット(Thin Provisioning, Thick ProvisioningのLazy Zeroed またはEager Zeroed)を選択し、「次へ」をクリックします。

2-11

接続する仮想ネットワークを選択します。vCenter ServerおよびESXiの管理ポートが所属するネットワークとします。

2-12

IPアドレスの割り当てはDHCPまたは静的-手動から選択します。ここでは静的-手動を選択し、設定できる各IPアドレスを入力して「次へ」をクリックします。

2-13

任意の管理パスワードを入力します。また、デフォルトで組み込まれているデータベースを使用するか否かの選択(今回は使用することを選択)、およびvSphere Replicationが接続する管理ネットワークに持つIPアドレスの入力を行い、「次へ」をクリックします。

2-14

vCenter Server に対して、適切な連携が出来るか否かの診断が行われます。「バインドのステータス」に緑色のチェックが表示されていることを確認し、「次へ」をクリックします。

2-15

各設定の一覧が表示されるので、設定が正しいことを確認します。デプロイ後にパワーオンするか否かを選択して(今回はパワーオンを選択)、「終了」をクリックします。

2-16

以上でオンプレ環境における作業(vSphere Replicationの展開)は完了です。

次回はDR先である、vCloud Airの登録や、DRする仮想マシンの設定をみていきます!

第1回:vCloud Air DR 2.0 概要編
第2回:vCloud Air DR 2.0 構築編
・(前半) vSphere Replication のデプロイ 本記事
(後半) vCloud Air を退避先として登録/・仮想マシンの保護設定
第3回:vCloud Air DR 2.0 活用編
(前半) フェイルオーバー試験テスト/フェイルオーバー
・(後半)フェイルバック

VMware NSX 6.2 の新機能 〜 複数データセンターをまたいだネットワーク・セキュリティ機能の実現

VMworld 2015 にて、VMware NSX の最新バージョンである NSX 6.2 が発表されました。この新バージョンでは、vCenter Server もしくは物理的なロケーションを越えてネットワーク・セキュリティ機能を提供できるようになるなど、大きな機能強化が行われています。

NSX を発表してから 2 年間が経過し、ビジネスは順調に成長してきています。すでに、700 社以上の顧客が NSX を選択し、100 社以上の顧客が NSX を本番系で利用、65 社以上の顧客が 100 万ドルを超える大きな投資を NSX に行っています。以下、NSX 6.2 の新機能について、3 つの領域に分けて説明します。

vCenter Server もしくはデータセンターをまたいだネットワークとセキュリティ

NSX 6.2 の最も大事な新機能の 1 つは、複数の vCenter Server をまたいで、論理的なネットワークとセキュリティ機能を提供できることです。それぞれの vCenter が、地理的に離れたデータセンターにあっても大丈夫です(150ms の遅延まで)。

図を使って具体的に説明しましょう。ここでは、3 つの vCenter が地理的に離れたデータセンターに分散している状況を想定しています。NSX 6.2 では、これらの分散したシステムを、単一の「ユニバーサル」なコントローラ クラスタからまとめて制御できます。論理スイッチと分散論理ルータ、そして分散ファイアウォールのルールなどは、vCenter もしくはデータセンターをまたいだ「ユニバーサル」なかたちで作成できるようになります。

NSX Manager は vCenter ごとに 1:1 で存在しますが、プライマリの役割を持つ NSX Manager は 1 つのみであり、残りの NSX Manager はセカンダリとしてユニバーサル オブジェクトの情報をプライマリから複製します。

Slide1

ユニバーサル オブジェクトのわかりやすい利点は、仮想マシン(VM)を vCenter 間もしくはデータセンター間で移動したときに、ネットワークの設定変更が必要なく、一貫性のあるセキュリティポリシーを提供し続けられることです。これにより、災害復旧やデータセンター移行を従来よりずっとシンプルで高速に行うことができます。

vCenter もしくはデータセンターをまたいだリソースプールを作り、Cross vCenter vMotion と組み合わせて利用することもできます。ここでは全ての機能を紹介しきれませんが、ユニバーサル分散論理ルータにおいて、North-South のルーティングを物理的な場所に基づいてローカライズすることも可能です。

物理インフラとのより緊密な統合

NSX 6.2 の今後のバージョンにおいて、vSphere 環境における Open vSwitch Database(OVSDB)のサポートが追加される予定です(注意: 表記を一部修正)。これにより、ハードウェアのスイッチやロード バランサーなど、エコシステム パートナーのソリューションとの標準ベースでの統合が可能になります。

1 つの例としては、ハードウェア VTEP(VXLAN Tunnel End Point)を導入することで、仮想ネットワークと物理ワークロードを接続しやすくなるなど、NSX のシンプルで一貫性のあるオペレーションをより大きな範囲に拡張しやすくなります。

Slide2

運用管理とトラブルシューティングにおける新機能

この分野ではいくつもの新機能がありますが、ここでは 2 つピックアップして紹介します。

集中管理 CLI は、コントローラやホスト、NSX Manager などの分散したコンポーネントから情報を収集し、それを単一のインタフェースからアクセスすることを可能にします。情報を集めるためにデバイスからデバイスにホップし、手動でデータの相関を見てトラブルシューティングの糸口をつかまなければならなかった従来のやり方とは異なり、一貫性のある情報ソースが提供されます。

トレースフローは、仮想ネットワーク内のさまざまなコンポーネントをパケットがどのように通過するかを確認するためのツールです。トレースフローは、あたかもゲスト VM から来たかのようにパケットを生成してデータパスに埋め込み、そのハンドリングを全てトレースできます。

—-

機能の詳細を知りたい方は、NSX 6.2 の製品ドキュメントをぜひご覧ください。また、パートナーエコシステムにおいても多くの新しい連携ができるようになっております。ご興味ある方はこちらのエントリ(英語)をご覧ください。

関連エントリ:  VMware NSX 6.2: Enterprise Automation, Security and Application Continuity

vSphere 問題解決までのヒント!- 第3回 実践編

はじめまして、テクニカルサポートエンジニアのRyoです。
Marieにかわりまして第3回を担当させていただきます。

第1回、第2回のサポートブログではトラブル発生時に「まずどうすればよいの?」をスタートに、サポートリクエスト(SR)を作成するまでのTIPSをご紹介しました。
VMware製品の障害問い合わせに不慣れなお客様でも、これまでの投稿の内容でかなりイメージが掴めたのではないでしょうか。
まだ、お読みで無い方は以下からチェックしてみて下さい。

—————————————————————————–
第1回 トラブル発生時に役立つ 4 つのリソース
第2回 サポートリクエスト(SR)と情報採取
—————————————————————————–

これまでの投稿をお読み頂いた方々の中には
「いやいや、実際トラブル発生した時はそんな一筋縄にスムーズに事は運ばないよ」 と思いたくなるシーンや、
「事象を整理しようにも、なかなかまとめづらい内容なんですよね」 なんて言いたくなることもあるかと思います。
もちろん、トラブルと言っても多種多様なものがありますので、中には一筋縄ではいかない事象も存在します。

第3回では、もう少し実際の事例に即した形で、ハマりやすいポイントなどをお話し、
「ああ、そうか、そういう視点で対応すれば良んだ」 など、少しでも今後の対応の参考にして頂ければと思います。


トラブル発生からお問い合わせまで

早速ですが、トラブルが発生してから問い合わせまでの流れをおさらいしますと
一連の流れは以下のような感じになります。

001

この流れが滞りなく進めば、お客様側で内容の再確認などを行う手間も省けますし、
SRの担当サポートエンジニアが、お問い合わせ内容を把握し調査に取りかかるまでの時間がかなり短縮されます。
* 1,2の詳細については第1回、3,4,5の詳細については第2回にて紹介しています。

しかしながら、トラブルというのは多種多様で、上記の流れに沿って事象を整理しようと思っても
なかなか上手く事象を把握できず、対応に手間取ってしまうケースももちろん存在します。
では、どのようなケースの場合、事象の把握で時間を要してしまうのでしょうか。
いくつか例を挙げてご紹介します。

case1 トラブルの検知

▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮

002

まずはじめに、 “1.トラブル発生” の際に手間取ってしまうであろうケースをご紹介したいと思います。
実際のトラブル発生に気づくポイントとしては、大きく以下の3点があります。

———————————————————————
a. 作業中にエラーが発生した
b. 使用者が動作の異常に気づいた
c. 監視サーバからアラートメールが届いた
———————————————————————

上記aの作業中のエラーは、実際に人が目で見て確認することがほとんどなので、特に見落としすることはないかと思います。
エラーに気づいた際は、エラーメッセージ内容と発生時刻を正確に書き留め、スクリーンショットを取得し、
サポートエンジニアに連携する下準備をしておくとSR発行の際に、正確な情報を伝えることが出来ます。

次にbの動作異常についてもユーザもしくはシステム管理者が気づくケースがほとんどかと思います。
動作異常、特にパフォーマンス関連については捉えにくい部分もありますので、case2で少しお話できればと思います。

残るcのアラートメールに関しては、お客様ご使用の監視システムを介して発行していることが大半かと思います。
ほとんどの警告やエラーメッセージはその内容が記載されており、一体何が発生したのかが何となく察することが出来るかと思います。


アラートメールの中身が無い?

alert

しかし中にはアラートメールは届いているものの、内容が全く無く、何のエラーを示しているのかがわからないケースがあります。
これは、vCenterサーバからSNMPトラップを監視サーバ宛に発行したものの、監視サーバはその内容を解釈できず、内容の表示が無いというものです。
このようなケースはESXiなどのアップグレードを行った際に、監視サーバ側でSNMP MIBファイル(管理情報ベース)の更新をし忘れていた時に起こることがあります。

特にESXi4.xから5.xなど、大きなバージョンアップがある際には、MIBファイルを新しいものに更新することを忘れないようにしましょう。
そうすることで、アラートの内容が確認できないといった事態を事前に回避し、すぐに問題に気づくことができます。

最新のMIBファイルは以下からダウンロードすることが可能ですので、チェックしてみてください。

* VMware KB: SNMP MIB module file download (1013445)
http://kb.vmware.com/kb/1013445

SNMPトラップの設定をこれからやってみようという方は、以下の構成手順をチェックしてみてください。

* VMware KB: Configuring SNMP traps in vCenter Server 4.x / 5.x (1006438)
http://kb.vmware.com/kb/1006438


トラブルは発生していないのに、アラートを検知する?

ハードウェアの障害は発生していないはずなのに、ESXiホストのハードウェアステータスが警告と表示されている
というような困った状況がまれに発生することがあります。
このような事象は、実はサーバーチップセット上の過去のハードウェア障害の履歴をを消し忘れていた時に起こることがあります。

よくある事例として、KBでも紹介されていますのでチェックしてみてください。

* Warnings in the Hardware Status tab of the ESXi 5.x host fails to clear (2061093)
http://kb.vmware.com/kb/2061093

 

case2 パフォーマンスが悪い?

▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮

——————————————————————————————————————————————
特にエラーは発生していないが、アプリケーションの動作が遅い。
昨日深夜の日次運用バッチ処理に時間がかかりすぎて途中でキャンセルされてしまった。
——————————————————————————————————————————————

など、結果として影響は見えているのにも関わらず、エラーメッセージと思しきものが見当たらないケースがまれにあります。
この様なパフォーマンスの問題は、アプリケーション、DB、ストレージ、ネットワーク、ハードウェア障害など様々な要因が考えられ、すぐにその要因がわかるような単純なケースもあれば、複合的な要因で発生するケースもあります。

この様な場合、トラブル対応の一連の流れの中の、“4. 事象の整理” で時間を要してしまいがちです。

003

パフォーマンスの問題に対するアプローチは様々ですが、今回は仮想環境上でなにか異常を見つけた時に、何を確認し、どのような情報を取得し、VMwareサポートに連携すれば対応がスムーズに運ぶかというポイントでお話します。
まずは簡単にチェックできる箇所から確認していきましょう。


何と何を比較し、”悪い” という判断に至ったか

performance

事象の切り分けや、各種パフォーマンスデータを収集する前に、まずそもそものところで何を問題視しているかをまとめてみましょう。
例えば、「アプリケーション、仮想マシンの動作が遅くなっている」 という状況であれば、
その “遅くなっている” というのはどのような判断基準で判断したのかを、確認できる範囲でチェックしてみましょう。

—————————————————————————————————————————————————————————
・ xx日の処理とyy日の処理を比較するとyy日の処理が遅くなった
・ 同じ構成、同じアプリケーションを実行している仮想マシン01と仮想マシン02を比較すると仮想マシン01が遅い
・ ESXi1号機上で実行していた仮想マシンをESXi2号機にvMotionした後から、ESXi2号機上の仮想マシンが遅くなった
—————————————————————————————————————————————————————————

このようにざっくりとで構いませんので、”悪くなった(遅くなった)” という判断に至る比較ポイントをまとめみて下さい。
これらの情報は今後詳細に調査方針を定める上で非常に重要な情報となります。
エラーの無いパフォーマンスの問題のゴールを設定する上で、比較対象 “正常系”、”異常系” を定めることが主な目的となります。
そうすることで、切り分け、調査方針が定めやすくなります。


“正常系”、”異常系” それぞれで情報取得

比較対象を決めた後は、”正常系”、”異常系” それぞれの環境で情報取得を行いましょう。
取得する情報は第2回でご案内した vm-support に、パフォーマンススナップショットデータを加えていただくと、
パフォーマンス問題の対応時に役立つ場合があります。

* VMware KB: Collecting performance snapshots using vm-support in ESX and ESXi (1967)
http://kb.vmware.com/kb/1967

上記KBに記載があるように、ESXi5.xを例にすると、にSSHでログインし以下のコマンドを実行します。

# vm-support -p -d <取得期間(秒)> -i <取得間隔(秒)>

<取得期間(秒)> : 事象確認できる時間を設定してください。わからなければ100秒で指定してみてください。
<取得間隔(秒)> : 推奨時間である10秒を指定してください。

上記実行後は vm-support 取得手順に従い、ログバンドルを取得いただけますと
パフォーマンスデータは自動でログバンドルに取り込まれます。

以上のように、”正常系”、”異常系” を把握し、それぞれの情報取得実施頂くだけで調査の初動の部分で対応スピードが大きく変わってきます。

また、特にパフォーマンスの問題に関しては、現場のお客様が気づいた・確認した情報が非常に重要なポイントとなることが多いです。
「関係しないかも・・・」と思ったことが、意外と本質と捉えていたりすることもありますので、情報にフィルタをかけない状態で、実際に確認した生の情報を頂ければと思います。
お客様が確認した情報と取得いただいたログの情報を合わせて送付いただけましたら、あとはサポートエンジニアにお任せください。

参考までに、いくつかパフォーマンス関連のノウハウがKBにまとまっていますのでチェックしてみてください。

* VMware KB: Troubleshooting ESX/ESXi virtual machine performance issues (2001003)
http://kb.vmware.com/kb/2001003
=> 仮想マシンのパフォーマンス問題が発生した際の調査ポイントがまとめられています。

* VMware KB: Troubleshooting network performance issues in a vSphere environment (1004087)
http://kb.vmware.com/kb/1004087
=> ネットワーク遅延が発生した際の調査ポイントがまとめられています。

* VMware KB: Storage device performance deteriorated (2007236)
http://kb.vmware.com/kb/2007236
=> ストレージパフォーマンスが低下した際の調査ポイントがまとめられています。

case3 ログが確認できない?

▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮

最後に “5. ログの取得” に関するTIPSをご紹介したいと思います。

004

トラブルを解決するためには、トラブルに対する対処策が必要です。
その対処策を見つけ出すためには、事象発生時に “何が起こっていたか” を正確に把握する必要があります。
“何が起こっていたか” を把握するためにログの情報はなくてはならないものです。


ログがローテートされている?

———————————————————————————————————————————-
該当時間のログ出力を確認しましたが、ログがローテートされており確認できませんでした。
——————————————————————————————————————————–
第2回の投稿でも少し触れましたが、お客様に対しサポートエンジニアからこのような回答を提示するケースが時折見受けられます。
ログの内容を確認出来ない場合、具体的に何が起こっていたかを把握できず、明確な調査結果、対処策をお出しできない可能性があります。

もちろん、事象の内容によっては一時的にログの出力が膨大になり、ログのローテートを防ぐことができない場合もあります。
ですが中には、事象が発生してからログ収集までの時間が経過しすぎたが為に、ログが残っていないというケースもあります。
後者については早めのログ収集を意識することで対策が可能ですが、それでもトラブルの度にログの取りこぼしが起こるような場合、
以下のKBを参考にログの保存世代数やサイズを増やすことも検討してみてもよいかもしれません。

* VMware KB: Increasing VMware vCenter Server and VMware ESX/ESXi logging levels (1004795)
http://kb.vmware.com/kb/1004795

もちろんログ管理設計による部分かと思いますが、ストレージ観点で容量に余裕のある範囲内で対応いただくことで、
トラブル対応がスムーズに進むのではないかと思います。


ログを取得したけど、中身がない?

log

先ほどの話の通りに事象発生後すぐにログバンドルの取得をしたにもかかわらず、中身を見るとログが出力されていない、
というようなケースも実はごくまれに発生したりします。これは、そもそもログの出力(vmsyslogd)が停止している場合に起こるケースです。
では、一体どのような状況で起こり得るのでしょうか。

* VMware KB: ESXi 5.x host stops saving logs to storage (2001442)
http://kb.vmware.com/kb/2001442

上記KBでいくつか紹介していますが、以下のようなケースでログの出力が停止します。

——————————————————————————————————————————————
・ ローカルストレージの容量不足
・ 外部ストレージにログを保存している場合の、ネットワークやストレージ障害
・ ログファイルが破損している
・ ディスク障害が発生している
——————————————————————————————————————————————

ディスク障害やネットワーク障害など、ESXiとは直接関係の無いところで発生し得るケースが多いです。
このような場合は、まずハードウェアのトラブルの解消した上で、以下のコマンドでログの出力を再開させてみましょう。

# esxcli system syslog reload (ESXi5.xの場合)

このようなケースも存在するといことだけでも頭の片隅に入れておいてもらえると、
ログファイル自体は存在するもの、のある期間のログ出力が無い、といった場合の初動の部分でスムーズな判断ができるかもしれません。

以上のように、ログ取得の際に、目当ての時間帯でログ出力が無かったり、そもそもログが無かったり
といった状況に遭遇した時に 「こんなケースもあるのか」 ということを少し知っているだけで、
イレギュラーが発生した際に状況把握がしやすくなり、サポートエンジニアとのコミュニケーションがより円滑になるかと思います。


ログの確認以前に、どのログを取得すればよいかわからない

先ほどまでの話とは少し別なところで、そもそもどの製品のログバンドルを取得すればよいのか、
xxx製品のログの取得方法がわからない、といったケースもあるかと思います。
そのような場合は、その旨をSR発行時にサポートエンジニアに連携していただければ調査に必要な情報をご連絡いたします。

ログの確認をすぐにでもはじめて欲しいといった場合には、余分なログがあっても構いませんので、
関連しそうだと思う製品のログをすべて取得するというのも1つの手段かと思います。
たとえ無駄な情報が多くても、サポートエンジニアがその中から必要な情報をピックアップして確認を行いますのでご安心ください。
一方で、ログサイズが大きすぎてアップロードが難しい、運用環境の制限で取得が難しい、といった状況に遭遇することもあるかと思います。
そのような場合も、一度サポートエンジニアに状況をご相談いただければと思います。

参考までに、以下のKBに各種製品のログファイルの場所がまとめられておりますのでチェックしてみてください。
* VMware KB: Location of log files for VMware products (1021806)
http://kb.vmware.com/kb/1021806


いかがでしたでしょうか。第3回では第1回、2回でご紹介したサポートリクエスト発行までの流れのなかで、つまずきやすいポイントをいくつかピックアップしてご紹介しました。
もちろん、ここに挙げた例以外にも様々なケースが存在しますが、ご紹介した話が少しでもトラブル対応時の手助けになればと思います。
以上、第3回でした。ではまたSRでお会いしましょう!


IMG_0687
こんな感じで日々ご支援しております!

vSphere 問題解決までのヒント!
第1回 トラブル発生時に役立つ 4 つのリソース
第2回 サポートリクエスト(SR)と情報採取
第3回 実践編

vCloud Airを使った災害対策 〜概要編〜

ソフトバンクC&Sの幸田さまに7月に機能強化されたvCloud Air のDisaster Recoveryサービスについて3回に分けて寄稿していただきます。それでは幸田さま、よろしくお願いいたします!!


みなさまこんにちは、ソフトバンクC&Sの幸田です。
わたしから、機能強化されたVMware vCloud AirのDRサービス、通称「DR 2.0」をご紹介させていただきます。

第1回:vCloud Air DR 2.0 概要編(本編)
第2回:vCloud Air DR 2.0 構築編
(前半)vSphere Replication のデプロイ
・(後半)vCloud Air を退避先として登録/仮想マシンの保護設定
第3回:vCloud Air DR 2.0 活用編
(前半) フェイルオーバー試験テスト/フェイルオーバー
(後半)フェイルバック

2014年11月より日本データセンタでのサービス提供を開始したvCloud Airでは、新しいサービスや機能強化がワールドワイドで次々と実装されています。 災害対策専用のサービスメニューであるDisaster Recovery(以下、DR)は米国で数多くの導入実績があり、日本でも提供開始当初から注目度の大変高いサービスです。このDRについての大幅な機能強化が、2015年7月に実装されました。

1-1

今回は1回目の概要編として、強化された各機能の概要をご紹介します。DR 2.0では、次の3つの機能強化が行われました。

・複数のリカバリポイント
・ネイティブ フェイルバックへの対応
・セルフサービスによる自動化

複数のリカバリポイントを利用可能

従来のDRでは、仮想マシンのリカバリポイントは1世代のみでした。仮想マシンは「最後にレプリケーションを行ったときの状態」にのみ戻すことができました。オンプレミス環境にトラブルが起きて、クラウド環境へ本番運用を切り替えようとするとき、最後にレプリケーションされた時点の仮想マシンはすでにトラブルの影響を受けており、正常な状態ではなくなっていた、という場合が考えられます。

このような場合、クラウド側へ1世代のみのバックアップしか保持できない従来のDRでは、クラウド側に本番運用を切り替えたとしても、トラブルの影響を受けた状態の仮想マシンを立ち上げることしかできません。それ以前の状態に戻したくても、すでに正常な時点 の仮想マシンの状態はクラウド上には保持されていないためです。

DR 2.0では、複数世代のリカバリポイントを保持することができるようになりました。そのため上述のような場合も、トラブルの影響を受けていなかった時点の仮想マシンを保持していますので、正常な状態の仮想マシンをクラウド側で起動することが可能です。

1-2

ネイティブフェイルバックへの対応

クラウド側に本番運用を切り替えた後に、オンプレミス環境が復旧した場合、クラウド側で運用していた仮想マシンをオンプレミス環境へ戻す作業、すなわちフェイルバックが必要となります。
従来のDRでは、オンプレミス側にvCloud Connectorという仮想アプライアンスを構成してフェイルバックを行う必要がありました。VMware純正の無償ツールであり、仮想マシンをオンプレミスとクラウドの間で自由に移行させることのできる大変有用なツールです。しかしながら、例えばオンプレミスが一時的な不調に陥ったためにフェイルオーバーを行った後などは、フェイルバックのためだけにこのツールのインストール・セットアップを行うことは少々骨の折れる作業に感じられることも事実でした。

DR 2.0では、オンプレミスからクラウド側へのレプリケーションを行う仮想アプライアンスであるvSphere Replicationによって、クラウド側からオンプレミスへのレプリケーション、すなわちフェイルバックをも行うことができるようになりました。このため、フェイルバックに際してvCloud Connectorのインストール・セットアップは不要となりました。

1-3

プラグイン連携

オンプレミスが災害など万が一の状況に見舞われた場合、クラウド側へ本番運用を切り替えるには手動での作業がある程度必要となります。DRの利用に際しては、従来から標準搭載されているフェイルオーバーのテスト機能を用いて、いわば「避難訓練」を行い、切り替えに伴う作業手順を明確にしておく等の備えを行うことが肝要です。しかしながら、より確実にフェイルオーバーを行うには、作業をできる限り自動化しておくことが理想的です。まさにこの切り替え作業の自動化を実現するのが、3つめとしてご紹介するDRのプラグイン連携機能です。

1-4

VMwareが以前から提供している自動化ツールであるvRealize Orchestrator のプラグインを用いて、DR 2.0に新たに備えられたAPIを実行し、切り替えに伴う作業を自動化することができるようになりました。

以上、DR 2.0における機能強化の概要をご紹介しました。
2回目となる次回の構築編では、DR2.0によってオンプレミスの仮想マシンを保護する方法をご紹介します!

第1回:vCloud Air DR 2.0 概要編
第2回:vCloud Air DR 2.0 構築編
(前半)vSphere Replication のデプロイ
・(後半)vCloud Air を退避先として登録/仮想マシンの保護設定
第3回:vCloud Air DR 2.0 活用編
(前半) フェイルオーバー試験テスト/フェイルオーバー
(後半)フェイルバック

「早い!簡単!コンパクト!」だけじゃない! EVO:RAIL の隠れた魅力をご紹介

「みなさんこんにちは。

VMware EVO:RAIL は、EVO:RAIL 認定パートナーを通じ、ハードウェア、ソフトウェア、およびサポートが提供されます。今回は EVO:RAIL 認定パートナーであるネットワンシステムズの川満 雄樹様より、EVO:RAIL の具体的な利点や国内事例をご紹介いただきます。それでは川満様、よろしくお願いいたします。」

 

こんにちは。ネットワンシステムズの川満です。

EVO:RAIL というキーワードを聞いたとき、おそらく多くの方は「 15 分で簡単にvSphere をセットアップ」、「初心者でも簡単な仮想マシンの運用」、「外部ストレージ不要のコンパクトなアプライアンス」などの「早い!簡単!コンパクト!」な特徴を思い浮かべると思います。

前回の「電源投入から 15分で仮想マシンを立ち上げ! EVO:RAIL 最新情報」で紹介されているように、発表から10 ヶ月が経過し、EVO:RAIL もバージョン 1.2 がリリースされ、アプライアンス拡張数も 8 アプライアンス( 32 ノード)へとサポートされる上限数が広がりました。

ネットワンシステムズは昨年より、いち早く VMware EVO:RAIL の日本国内での取り扱いを開始し、EVO:RAIL システムの評価検証と、多くのソリューションとの連携検証を実施してきました。

今回は評価検証で実証した EVO:RAIL の利点のうち、今まであまり紹介されていなかった運用に直接関わってくる「EVO:RAIL のバージョンアップ方法」「 EVO:RAIL の拡張方法」と、 EVO:RAIL を活用頂いているお客様の導入事例をご紹介します。

・EVO:RAIL のバージョンアップ

通常の vSphere のバージョンアップは、 vCenter Server と連携した Update Manager を利用するか、各 ESXi 、 vCenter のソフトウェアを個別で入手し、それぞれのコンポーネント毎に CLI 、 GUI を駆使してバージョンアップ作業を実施する必要があり、非常に技術力と運用負荷が要求される作業でした。

EVO:RAIL の大きな特徴として、 EVO:RAIL rapid Deployment, Configuration & Management (以下、 EVO:RAIL DCM )と呼ばれるソフトウェア( EVO:RAIL Engine )が15分での簡単セットアップと、仮想化初心者でも操作しやすい簡単インターフェースを提供しています。

EVO:RAIL DCM は、「よりシンプルに仮想化基盤を利用する」という全く新しいコンセプトの管理ツールとして EVO:RAIL に組み込まれていますが、ソフトウェアバージョンアップもこの EVO:RAIL DCM を利用して簡単に適用する事が出来ます。

・EVO:RAIL 更新ソフトウェアの入手方法は?
01_MyVmware

既にお気付きの方もいらっしゃるかと思いますが、最近 My VMware のソフトウェアダウンロードページに「 EVO:RAIL 」カテゴリが追加されました。

EVO:RAIL の更新ソフトウェアは他の VMware 製品と同じく、 My VMware から入手できますが、一つ異なるポイントがあります。

EVO:RAILの場合、中心となるEVO:RAIL Engineのソフトウェアバージョンに合わせて ESXi、vCenter Server Appliance (vCSA) 、 Log Insight も動作互換確認済みのバージョンが掲載され、入手可能な事です。

  • EVO:RAIL <X.Y.Z> Offline Bundle : ESXi にインストールする EVO:RAIL Engine のエージェントです。 ZIP形式で提供され、解凍すると「 vmware-marvin-X.Y.Z-<Build No>.vib 」という名称の ESXi 用ソフトウェアが含まれています。
  • EVO:RAIL <X.Y.Z> Appliance RPM : vCSA にインストールする EVO:RAIL Engine のコアソフトウェアです。 RPM 形式で提供されます。
  • ESXi <Version> Offline Bundle : EVO:RAIL のバージョン毎に動作互換確認済みの ESXi 用アップデートファイルが提供されています。  ZIP 形式で提供されます。
  • VMware vCenter Server <Version> Appliance : EVO:RAIL のバージョン毎に動作互換確認済みの vCSA 用アップデートファイルが提供されています。  ZIP 形式で提供されます。
  • vRealize Log Insight Upgrade Bundle : EVO:RAIL のバージョン毎に動作互換確認済みの Log Insight 用アップデートファイルが提供されています。  PAK 形式で提供されます。

・バージョンアップの実施

バージョンアップは EVO:RAIL DCM で行います。

ダウンロードしたアップデート用のパッチファイルを EVO:RAIL システムにアップロードすると次の様なチェックボックス形式の更新画面が表示されます。

02_VerUp

ITインフラ管理者の操作は「ファイルのアップロード」→「チェックボックスのOn」→「更新ボタンのクリック」の 3 ステップのみで EVO:RAIL のバージョンアップは完了します。

03_VerUp

バージョンアップの間、各 ESXi ホストの再起動が必要な場合には、自動的に稼働する仮想マシンを別ホストへオンライン移行( vMotion )しながらホストのバージョンアップが実施されます。

そのため、仮想マシンを利用するユーザーのシステムに影響を与える事なく、サービスをオンラインのままEVO:RAIL アプライアンスのメンテナンスは自動で行われます。

弊社にて実際にバージョンアップの所要時間を検証したところ、全 ESXi サーバを順にバージョンアップ・再起動、及び vCSA のバージョンアップが行われ、 1 アプライアンス全体の更新は約1時間で完了しました。

一連の作業は、最初の更新ボタンをクリックしてからは自動バージョンアップとなるため非常に簡単で、仮想化環境のバージョン管理という IT インフラ管理者にとって非常に負担の大きい運用も、 EVO:RAIL を利用する事で大幅な負荷低減が可能なると考えられます。

・EVO:RAIL のアプライアンス追加・拡張

EVO:RAIL にはこのようなバージョンアップだけでなく、アプライアンスの追加作業、故障した ESXi ホスト・パーツの交換作業も EVO:RAIL DCM が簡単なインターフェースを提供しています。

EVO:RAIL を導入する事で初回の 15 分セットアップだけでなく、導入後の運用においても 10 分弱でのアプライアンス追加、そして故障したホスト・パーツの交換作業が可能になります。

実際に EVO:RAIL を拡張する場合はどのような作業をするか、簡単にご紹介します。

まず、既存の EVO:RAIL システムが接続された 10G ネットワークスイッチに追加の EVO:RAIL アプライアンスを接続し、電源を投入します。

すると、 EVO:RAIL Engine が追加のアプライアンスからの信号を検知し、 EVO:RAIL DCM の画面上に追加アプライアンスの検出と「 EVO:RAIL アプライアンスの追加」ボタンを表示します。

04_追加アプライアンス検出_1

ITインフラ管理者が行うアプライアンスの拡張操作は、「 EVO:RAIL アプライアンスの追加」ボタンを押し、次の画面で各 ESXi ホストに割り当てる管理ネットワークの IP アドレスを指定し、パスワードを入力するだけです。

※ IP アドレスは既存ホストの各管理ネットワークと同一 L2 ネットワークで指定します。

05_追加アプライアンス拡張

簡単すぎるかと思いますが、アプライアンスの追加作業で IT インフラ管理者の操作は以上です。

「アプライアンスの追加」ボタンを押してから所要時間約 5 分で、 vCenter Server Appliance に追加のESXi ホストが登録され、 VSAN データストアを含めてオンラインで拡張されます。

06_追加アプライアンス拡張後

もちろん、アプライアンスの拡張後は上の画面の様に、 EVO:RAIL DCM にアイコンが追加され、統合された管理が提供されます。

・EVO:RAIL の国内事例のご紹介

日本国内でいち早く EVO:RAIL を利用したシステムを導入したお客様の事例をご紹介します。

 

・福岡ひびき信用金庫様

福岡ひびき信用金庫様が取り組む仮想基盤上で稼働する業務系システムの災害対策サイトの構築。それを実現したのがコンパクトな 2U サイズの垂直統合製品「 EVO:RAIL 」でした。

福岡ひびき信用金庫様が抱えていたITインフラの課題、

  • 災害対策サイトを構築するうえでコストと手間
  • 外部ストレージ不要の遠隔地の DR システム自体の管理負荷の削減
  • 既存の vSphere 製品との親和性

これらを解決するために EVO:RAIL を災害対策サイトのシステム基盤に導入しました。

Hibiki_case_1

その効果は、

  • 運用管理コストを 10 分の 1 に削減
  • IT 初心者からベテランまでが使いこなせるシンプルなアプライアンスで少人数のチームで DR サイトが構築可能に
  • 災害発生時のいざという時は 2U のアプライアンスなので物理的な移動も可能に

等々、 3 番目は今までにないユニークな運用想定ですが、従来型のシステム基盤では実現が難しかった「可搬性」というものも EVO:RAIL では可能になるのかもしれません。

Hibiki_case_2

より詳細な事例情報、 PDF 資料のダウンロードは以下のURLを参照ください。

http://www.netone.co.jp/report/case/case_20150402.html

 

・朝日インタラクティブ様

ZDnet Japan や CNET Japan などの多くのオンラインメディア系 Web サイトを展開・運営する朝日インタラクティブ様は、高さわずか 2U (約 8.9cm )の「 EVO:RAIL 」 1 台の仮想環境上に既存のシステム、運営 Web メディアの約50台の物理サーバや社内業務システムを集約しました。

朝日インタラクティブ様が抱えていた IT システムの課題は以下のような点でした。

  •  毎年発生する既存サーバの保守、更新コストと、少人数体制の運用負荷削減
  • データセンターのハウジングコスト削減
  •  運営 Web メディアの可用性の向上

朝日インタラクティブ様においても、多くの企業のITインフラ管理者の課題でもある運用負荷と TCO を削減し、効率の良いシステム導入で高い ROI を得る事が命題でした。

asahi_1

今回、朝日インタラクティブ様では EVO:RAIL の導入により以下の効果を上げる事が出来ました。

  • ハウジングコストやサーバ保守コストからなる運用コストを 50% 削減
  • EVO:RAIL DCM の簡易な操作性で運用担当者の負荷を大きく軽減
  • 非常に高い稼働率が求められる運営 Web メディアの可用性を向上
  • 新規サービスの試験環境を迅速・簡単に準備可能

より詳細な事例情報、 PDF 資料のダウンロードは以下の URL を参照ください。

http://www.netone.co.jp/report/case/case_20150430.html

・おわりに

仮想化の基本でもあるサーバ仮想化統合は物理サーバから仮想サーバへの移行だけではなく、数年前に導入したシステム基盤上で稼働する仮想サーバのリプレイスでも需要が増えています。

数年前と比較して数倍に高性能化し、かつハイパーコンバージドと呼ばれる新しい形態の仮想化基盤を活用する事で、より効率的な統合が可能になりました。

従来システム基盤からのリプレイスをご検討の方は、ぜひ EVO:RAIL の活用を検討して頂ければと思います。

ネットワンシステムズでは、仮想デスクトップをはじめ、様々なソリューションを EVO:RAIL と組みあわせた評価検証を行い、お客様に最適なシステムをご提案しております。

詳しくは以下のサイトで最新の EVO:RAIL 情報をご覧いただき、ご不明点は弊社までお問い合わせください。

http://evo.netone.co.jp/

Virtual SAN 6.1 の新機能 〜 ストレッチ クラスタ、2 ノード構成などに新たに対応

今週 VMworld 2015 にて、VMware Virtual SAN(VSAN)の新バージョン 6.1 が発表されました。今回のバージョンでは、ストレッチクラスタや 2 ノード構成など、可用性に関して特に大きな進展があります。前のバージョン(6.0)が出てから半年で、大きなアップデートをご紹介できることを嬉しく思います。

VSAN 6.1 はこれが 3 世代目の正式リリースとなり、ビジネスは順調なペースで成長を続けています。最初の正式リリース(2014 年 3 月)から 15 ヶ月間が経過しましたが、VSAN を利用している顧客数は既に 2000 を超えています。

以下、VSAN 6.1 の新機能について、可用性、性能面、管理面の 3 つに分けて説明しましょう。

可用性における新機能

VSAN 6.1 には、ビジネス クリティカル アプリケーションを稼働させるようなエンタープライズ クラスのストレージとして、多くの可用性向上の新機能が搭載されています。以下、その中でも主な 5 つの新機能を紹介しましょう。

Virtual SAN ストレッチ クラスタ

VSAN 6.1 では、地理的に離れたサイト間でストレッチ クラスタを作成することをサポートします。データはサイト間で同期レプリケーションされます。サイト間の RTT (Round-Trip Time) は 5ms までサポートされます。

内部では、VSAN 6.0 で導入されたフォールト ドメイン機能を使っており、2 つのサイト以外にもう 1 つ、Witness サイトを設ける必要があります。Witness サイトとデータサイトの間は 100ms RTT 以下であることが必要です。ネットワークの帯域やトポロジなどの詳細は、近々出る予定の VSAN ストレッチ クラスタ ガイドをぜひご覧ください。

ストレッチ クラスタ機能により、マルチ データセンターなどの可用性を高める構成を組むことができるようになります。

SC-VSAN

Virtual SAN for Remote Office / Branch Office(ROBO)

VSAN 6.1 では、分散したリモートオフィス/支社への配備シナリオを新たにサポートします。顧客は、2 ノードの VSAN クラスタを各リモート オフィスに配備し、コアのデータセンターにある vCenter Server を通してそれらを集中管理できます。

内部の動作は VSAN ストレッチ クラスタと似ており、各リモート オフィスでは VSAN が 2 ノードで動作していますが、Witness VM を別の vSphere ホスト上で(通常はコアのデータセンターにて)動作させて、そこから 2 ノードの VSAN を監視できるようにする必要があります。

robo

Virtual SAN Replication(RPO 5 分間まで)

vSphere Replication では 15 分間(〜 24 時間)のRPOをサポートしていますが、VSAN 6.1 ではこの機能を強化し、RPO を 5 分間まで小さくすることをサポートします。

下図は、VMware Site Recovery Manager(SRM)との連携例です。ストレッチ クラスタを組んだ後に、レプリケーションを使うことで、広範囲の災害や、データセンター移行に対応することができます。

vsan-vr-srm

vSphere FT のサポート

vSphere FT(フォールト トレランス)を新たにサポートします。これにより、ゼロ ダウンタイムを必要とするミッション クリティカル アプリを VSAN 上で稼働させることが可能になります。複数の仮想 CPU からなる FT(SMP-FT)もサポートされます。

smp-ft-vsan

Windows Server Failover Clustering(WSFC)および Oracle Real Application Cluster(RAC)のサポート

VSAN 6.1 は Oracle および Microsoft のクラスタリング技術を新たにサポートします。Oracle RAC のユーザは、VSAN データストアにアクセスする複数の Oracle RDBMS インスタンスを立ち上げ、性能/スケーラビリティ/耐障害性を向上できます。同様に、Windows Server Failover Clustering を用いてアプリケーション レベルの可用性を向上することもできます。

wsfc-vsan

性能面における新機能

VMware は VSAN の性能改善を継続しています。今回、ハードウェア デバイスとインタフェースの新しいタイプをサポートすることで、スループットの向上とレイテンシの削減を実現します。

  • Non-Volatile Memory Express (NVMe)
  • ULLtra DIMM™

管理面における新機能

Virtual SAN Health Check(バージョン 2)

5 月にリリースされたヘルスチェック機能が改善されて VSAN 6.1 に取り込まれます。vSphere Web Client から、VSAN の構成やハードウェア/データの健全性に関して確認できるようになります。

health-ui

Virtual SAN Management Pack for vRealize Operations

VSAN 6.1 では vRealize Operations との統合が強化され、VSAN の健全性やリソース状況など、ステータスを可視化するための包括的な機能セットが提供されます。

VROPS

 

関連エントリ: WHATS NEW – VMWARE VIRTUAL SAN 6.1

【VMware発表】企業のコンテナ利用を加速する vSphere Integrated Containers

VMworld 2015 において、企業のコンテナ利用を加速する 2 つの新しいテクノロジープレビュー「VMware vSphere Integrated Containers」と「VMware Photon Platform」が発表されました。

本エントリでは、vSphere 顧客にとってより関連性の高い、VMware vSphere Integrated Containers の内容を紹介します。

コンテナに関する「開発者」と「IT 部門」の異なるニーズ

VMware Integrated Containers が想定するユースケースは、コンテナ化された新しいタイプのワークロードと、仮想マシンに基づく既存のワークロードが共存する環境です。企業が既存のアプリケーションをクラウド ネイティブなアプローチに変えていく際に、このような共存環境が出てくると VMware は考えています。

Dev-IT2

このケースにおいて私たちが想定する課題は、コンテナを使いたい「開発者」と、既存システムに則った運用を行いたい「IT 部門」が、全く異なるニーズを持っているということです。

開発者がコンテナ ベースの環境に「ポータビリティ、スピード、軽さ」を求めるのに対し、IT 部門は「セキュリティ、信頼性、一貫性のある管理」を求めます。この一見相反する要求をどのように同時に満たすかが、これからのコンテナ導入における 1 つの課題となっていくでしょう。

「仮想マシンごとに 1 つのコンテナ」というアプローチ

上記の課題を解決するために、VMware Integrated Containers では、「仮想マシン(VM)ごとに 1 つのコンテナ」というアプローチを取っています。この狙いは、コンテナを利用する際にも、VM ベースでの「セキュリティ、信頼性、管理」を適用可能にすることにあります。

VM ベースの利点を具体的に挙げていくと、まず、隔離レベル(OS)が低いというコンテナのセキュリティの課題を、VM によるハードウェアレベルの隔離で改善することができます。

vSphere DRS のような機能を利用して、信頼性を高めることもできます。ストレージやネットワークについては、vSphere プラットフォームの同等の要素にマップすることができます(VSAN や NSX など)。vSphere Web Client などの既存の管理インタフェースから、VM に加えてコンテナの状態も確認できます。

Dev-IT-Sol1

このようにして、IT 部門が求める「セキュリティ、信頼性、一貫性のある管理」を満たそうというわけです。

Photon OS と Instant Clone で「仮想マシンごとに 1 つのコンテナ」のための軽さを実現

ただ、単純に「VM ごとに 1 つのコンテナ」というやり方を取ると、コンテナの長所である「スピード、軽さ」が失われてしまいます。

この問題を解決するために、VMware Integrated Containers では、コンテナの OS に VMware が開発した、コンテナに最適化された軽量 Linux OS である「Photon OS」(旧称 Project Photon)を利用しています。

そしてより大事なポイントとして、vSphere 6.0 の新機能である Instant Clone を活用します。Instant Clone によって作られた VM は、親 VM のイメージとの差分のメモリだけを消費します。そのため、OS が共通であるコンテナ環境の場合、VM 作成の時点では物理的なメモリをほとんど消費せず、瞬時に起動することができます。

Instant Clone

Photon OS と Instant Clone を使えば、「仮想マシンごとに 1 つのコンテナ」においてもコンテナのスピードと軽さを実現でき、それでいてセキュリティや管理性といった VM の特性は保てるというわけです。

利用者からは「仮想コンテナホスト」として見える

VMware Integrated Containers では、vSphere は、Docker API などのコンテナの API を受け付ける「仮想コンテナホスト」として利用者に見えます。

VMware Integrated Containers では、Open Container Initiative によって定められた基本的な構成要素を使っており、それらを vSphere 環境にマップすることで、標準的な Docker クライアントツールと互換性がある仮想コンテナホストを作り出しています。
Bonneville

このようにして、VMware Integrated Containers は、コンテナを使いたい「開発者」と、既存システムに則った運用を行いたい「IT 部門」の異なるニーズを同時に満たすことで、企業におけるコンテナの利用を加速しようとしています。

Dev-IT-Sol2関連エントリ:  VMware のクラウド ネイティブ アプリ関連の 4 つのテクノロジー

 

【VMware発表】Hybrid Cloud Manager とクラウド間ライブマイグレーション

VMworld 2015 のジェネラル セッションにて、ハイブリッドクラウド環境における管理機能を提供する「vCloud Air Hybrid Cloud Manager」、およびその拡張機能として、クラウド間のライブマイグレーションである Cross-Cloud vMotion などを実現するテクニカル プレビュー「Project SkyScraper」が発表されました。

本エントリでは、これらがどのような機能を提供するのか、その概要を説明します。ハイブリッド クラウドにこだわってきた VMware が提供する最新技術をぜひ知っていただければと思います。

vCloud Air Hybrid Cloud Manager の位置づけ

先日のエントリでも解説しましたが、VMware は、ハイブリッド クラウド環境のネットワークとセキュリティにおいて、大きく 3 つの領域で製品/サービスを提供することで、包括的なソリューションを提供しようとしています。オンプレミス側では VMware NSX、パブリック クラウド側では(VMware NSX による)Advanced Networking Services です。

Hybrid Networking 2

今回発表されたのは、図の中央に位置する、ハイブリッドクラウドの管理機能を提供する「vCloud Air Hybrid Cloud Manager」です。オンプレミスとパブリック クラウドを繋ぎ込む、ハイブリッドクラウド環境におけるネットワークとセキュリティの大事な機能を担います。

vCloud Air Hybrid Cloud Managerの機能

Hybrid Cloud Manager がどんな機能を持っているのか、簡単に説明しましょう。Hybrid Cloud Manager の重要な機能は、大きく 3 つあります。

HCM

ハイブリッドクラウド上のワークロードを一元管理

  • Hybrid Cloud Manager は vSphere Web Client のプラグインとして提供されます。導入すると、vSphere Web Client から vCloud Air 上のワークロードの管理を行うことができるようになります。
  • これにより、vSphere Web Client を通して、オンプレミスの vSphere 環境と、パブリック クラウドの vCloud Air 環境のワークロードを一元管理することができます。

強化されたワークロードの移行

  • オンプレミスと vCloud Air 間の双方向のワークロードの移行機能を提供します。ワークロードの移行は、今までは vCloud Connector が提供していた機能ですが、その機能が強化された形で Hybrid Cloud Manager に搭載されます。
  • 強化されたポイントは、vSphere のレプリケーションベースの移行が行えるようになったことです。暗号化されたインターネット接続もしくは Direct Connect を経由してレプリケーションすることで、仮想マシンのダウンタイムを数分のレベルにまで短縮できます。
  • さらに、ダウンタイムはソフトウェアベースの WAN アクセラレーション機能によってさらに削減されます。移行のタイミングはオフピーク時間にスケジューリングできます。

ネットワーク延伸の管理

  • Hybrid Cloud Manager を使えば、オンプレミスの何百ものネットワークセグメントを L2 VPN トンネルを使ってクラウドに延伸できるようになります。その際、エッジ ゲートウェイは 1 つでも問題ありません。暗号化されたインターネット接続、もしくは Direct Connect のどちらでも利用することができます。この機能により、オンプレミスのデータセンターからクラウドへとシステムをシームレスに拡張し、双方のリソースを統合して利用することが可能になります。
  • ワークロードの移動前後で IP や MAC アドレスをキープすることも可能になります。ユーザはオンプレミスおよびクラウドの特長を活かしつつ、新しいタイプのハイブリッドクラウドアプリケーションを作ることができるようになります。

Hybrid Cloud Manager は、vSphere ユーザは無償でダウンロードして利用でき、マイグレーションの強化とネットワーク延伸機能は有償オプションで利用可能になります。Hybrid Cloud Manager の利用に際し、オンプレミス側には VMware NSX は必要ありません。

Hybrid Cloud Managerは、まずDedicated Cloud(専有型クラウド)向けに 9 月に提供が開始され、今年の後半に Virtual Private Cloud(共有型クラウド)をサポートする予定です。

クラウド間ライブマイグレーションを実現する Project SkyScraper

それでは、今年の VMworld のジェネラル セッションの 1 つの目玉であったクラウド間ライブマイグレーション Cross-Cloud vMotion を実現する Project SkyScraper について説明していきましょう。テクノロジー プレビューである Project SkyScraper は、Hybrid Cloud Manager の拡張機能として提供され、大きく 2 つの機能を有します。

Cross-Cloud vMotion

Cross-Cloud vMotion

1 つ目の機能が、vSphere vMotion の新しいテクノロジーである Cross-Cloud vMotion です。VMworld のジェネラル セッションのデモでは、オンプレミスと vCloud Air の間で、稼働中の仮想マシンを Cross-Cloud vMotion を使って移行していました。Cross-Cloud vMotion は vSphere Web Client から利用することができるため、利用に際し特別なインタフェースは必要ありません。VMworld のデモでも、vSphere Web Client から右クリックで Cross-Cloud vMotion を呼び出して実行しています。

Cross-Cloud vMotion は、Hybrid Cloud Manager のワークロードの移行機能を強力に補完するものです。顧客はクラウドへの移行に際し、マシンのアップタイムで妥協する必要は無く、全ての vMotion の特長が維持されます。このテクノロジーは、顧客に更なる柔軟性を提供します。

Content Sync

Project SkyScraper のもう 1 つの機能が、Content Sync 機能です。この機能を利用することで、顧客にオンプレミスのコンテンツ ライブラリを vCloud Air のコンテンツ カタログと同期できます。具体的には、VMのテンプレート、vApp、ISOイメージ、そしてスクリプトなどが含まれます。オンプレミスとクラウドの間でのコンテンツの一貫性あるものにし、間違いの多い手動での同期プロセスを無くすことができます。

仮想インフラでの運用をガラリと変えた vSphere vMotion が、いよいよクラウドの壁を越えて実行できるようになってきました。ライブマイグレーションを用いてクラウドへの移行が行えるようになれば、既存のワークロードを容易にクラウドへ移行できるようになるなど、クラウドの使い方や運用方法を大きく変えることは間違いありません。

VMware のハイブリッドクラウド技術の更なる進化にぜひご期待いただければと思います。