vForum2018で登壇致しました!- 後編

カテゴリー: VMware, VWシリーズ, イベント   パーマリンク
このエントリーをはてなブックマークに追加

2018年11月13〜14日、ザ・プリンス パークタワー東京にて「vFORUM 2018 TOKYO」が開催されました。これはITに関わるすべての人に、デジタルトランスフォーメーションに必要不可欠な情報を届けることを目的としてVMwareが開催しているイベント。2日目のセッションで「VMware HCXを活用したマルチクラウドの世界とクラウド移行のユースケース」と題しまして、弊社の山本が、VMware, Inc. Product Line ManagerのAjay Anthony氏と講演致しました。その内容をご紹介します。

前編から続く

SLA(Service Level Agreement)を維持していくことの重要性

山本:ここからはHCXの具体的なお話に入っていきたいと思います。

VMware USでHCXのプロダクトラインマネージャーのAjay Anthonyさんにご登壇いただこうと思います。

Please come to stage, Ajay.

Ajay Anthony氏(以下、Anthony):みなさんこんにちは。ご紹介いただきありがとうございます。

ビジネスクリティカルなアプリケーションというのは、ただ1つだけ独立して存在しているということはあり得ません。そのほかのアプリケーションとつながっており、さらに(そこに)新規ユーザーの使用開始が伴うものです。

これらに対し、セキュリティやフォルトドメインを付与することが、ビジネスクリティカルなアプリケーションをレジリエントにする条件となります。また、一見無関係でも、インフラ的な観点においてアプリケーションに影響が出る場合があります。

アプリケーションを動かすプラットフォームがエンドオブライフ(サービス終了)となったり、販売終了になったりすることもあります。プラットフォームを乗り換え済みなら、インフラストラクチャーをトレンドの仕様に変えたり、M&Aに伴ってデータセンターの統合・集約が起きたりと、こういったことがたいていの場合は発生します。

これらの背後で起こることをすべて盛り込んだうえで、SLA(Service Level Agreement)を維持していくのが重要になってきます。

ビジネスの停滞につながる数々の要因

Anthony:私どもは、ここまでで述べたような困難にお客さまが直面していると認識しております。例えば、互換性のないスタックのvSphere(のバージョンを)5.5から6.5(に変える必要がある)こともあるでしょう。

さまざまなファイアウォールルールがあるために、移行するのも難しくなっています。

新旧双方の環境で、IPアドレスを維持したいというチャレンジもあるでしょう。アプリケーション双方の依存性というのも維持されなければなりません。 これらすべてがビジネスの停滞につながる要因となります。

こうして人とプロセスの分野に対応しているのが現状ですが、私たちはHCXで対応していくことができるのではないかと考えております。

シンプルなたとえ話をさせてください。(みなさんが)今、vSphere5.0を現在ご利用中だとしましょう。そしてIIJ GIOには最新のSDDC環境が用意されています。これらのWANにはインフラストラクチャーレベルのなにかしらのコネクティビティが、まず実現されます。

ここでHCXがまず行うのは、インフラストラクチャーレベルでのハイブリッド化の実現です。このハイブリッド化というのは、vSphereがvCenterで行っていることをネットワークレベルで行う、という解釈で構いません。

この考え方によって、マイグレーションワークロードが簡単に実現されます。これまでのレガシーを変更する必要もありません。例えば、設計の変更もレトロフィットな何かを導入する必要もありません。自動化の機能によって非常に簡単に実装できます。

ゼロダウンタイム・ゼロフリクションでのマイグレーションを実現したい

Anthony:これらは現在のHCXで実現可能なことです。

アプリケーションをノーリスクで移行できるとか、無停止で移行できるとか、IPアドレスの変更なしに移行できるといったことです。あとは、複数のネットワークパスで冗長性をもたせるとか、何回かクリックするだけでネットワークを延伸することもできます。

ほかにもWANの最適化がソリューションに含まれているので、(サイト間のネットワークの)レイテンシーの影響を軽減できます。vMotionは遅延に左右されやすいですからね。このように簡単にすることによって、マイグレーションを楽に行なっていくことが可能となっています。

私たちのビジョンとしては、vSphereに留まらず、どのクラウドに対してもハイブリッド性を持ち、ゼロダウンタイム・ゼロフリクションでのマイグレーションを実現したいと思っております。

山本:ありがとうございました。このように、HCXを活用することでオンプレミスからクラウドへの道筋を作れる、という仕組みについてお話しいただきました。

そうやって私たちは、オンプレミスからクラウドへの道筋というものを推進している会社です。

移行の課題とVMware HCXによる解決方法

山本:ここからは、実際の移行の案件事例についてお話しさせていただきます。実際の移行の案件事例から、どういう課題があるのかが明確になります。それにあわせて、VMware HCXでどうやって解決できるかについてお話しさせていただきます。

まずは移行の案件事例についてお話しさせていただきたいのですが、その移行先であるクラウドサービスは「IIJ GIOコンポーネントサービス 仮想化プラットフォーム VWシリーズ」というサービスです。こちらはなにかというと、先ほどの繰り返しになりますが、オンプレミスをそのままクラウドへ移行できるメリットというものをもったクラウドサービスです。

「そのままクラウドへ」といってもいろいろあると思うんですが、オンプレミスと同じOSやソフトウェアが利用可能であったり、vCenterを管理者権限で使えたりします。

クラウドサービスのコントロールパネルで運用するわけではなく、vCenterのコントロールパネルで運用したり、仮想マシンをそのまま移行、つまり「V2Vでそのまま使えますよ」「必要に応じてIPアドレスも変更しなくてもいいですよ」といったかたちで利用できるサービスになっています。

一方、クラウドサービスでもありますので、ハードウェアやファシリティを持たないプライベートクラウドとしてつかえるサービスになっています。

システム停止による影響は最小限に抑えたい

山本:実際の移行の案件事例ですが、すみません、かなり簡略化して書いてしまったのですが、こちらはオンプレミスのデータセンターに200台強のVMがあるという環境です。

こちらのハードウェアは、古いESXが4.1だったり、vCenterも4.1を使っているような環境で、こちらのデータセンターを閉めて、全部こちらに持っていきたいと。ただ、上に乗っかっているアプリケーションはそのまま移行したい。

そういったとき、システムとしては、Webのいろいろなポータルが集まっているサイトなので、移行するときにシステムの停止は最小限に抑えたいと。

ポータルのビジネスをしているお客さまですので、そのポータルを停めるというのは、お客さまのビジネスを停めてしまうという話になります。それは極力少なくしたい、そういった要件でした。

ここからここに(図が)ビビビってなってるのですけど、ぱっと見たところ「サクッとV2Vすればいいんですよね」というかたちで考えていたのですが、このプロジェクトを始めるにあたって、いろいろな課題が出てきました。それを1つずつ挙げていきます。

もちろんこれはインフラ面の課題だけです。さっきのポータルサイトって、ロードバランサーで上から来てる通信をどうやってデータセンターで切り替えるのかといった、いろんな課題があります。

そういうところについては、今日は時間の都合もありまして割愛させていただいて、インフラ面、とくにvSphereにフォーカスしたところだけでお話しさせていただきます。

IPアドレスを変更せずにインフラを移行させるには?

さきほどもお話ししたとおり、これは停められないシステムです。200台で構成されていて、ポータルサイトが複数あり、システム間の連携もたくさんあります。

例えば200台のVMを1台移したら、この連携を変えるために「IPアドレスは変わってるから連携のオペレーションも変えましょう」とするのは、現実的に無理な環境でした。なので、IPアドレスを変更せずにインフラを移行させる、という要件は必須でした。

かつ、システムの停止は極力抑えたいというお話ですので、例えばOVAでコンバートして、それをコピーして……としていると、いつ終わるかわからないので許容できません。

なので、vSphere Replicationを導入してレプリケーションするとなると、「RPOというかRTOを最小限にしていきます」ということで、vSphere Replicationを入れることに決めました。

ただ、vSphere Replicationを導入するとなると、とくにコンパチビリティにお詳しいかたはご存じだと思うんですけど、例えばクラウド環境下をvSphere6.0にすると、vSphere4.1と6.0で、vSphere Replicationと同期させることはできません。

なので、vSphere Replicationを使いたいがためにオンプレミス側のvCenter4.1をバージョンアップしました。当然、クローズするデータセンター、クローズする古いハードウェアに乗ってるvCenterって、もうそんなに触りたくないですよね。私も触りたくないんですけど。

それをわざわざバージョンアップしないと、vSphere Replicationは導入できません。ということでけっこう時間がかかりました。移行作業も半年くらいかかるんですが、このプロジェクト自体も1年ほどかかりました。まあ、「200台を移行しましょう」というだけでも、こういったことをやってるとたくさん時間がとられてしまいます。

24時間365日動き続けるシステム改修の苦労

山本:なので、こうやってネットワークをつくり、vSphere Replicationを入れます。vCenterのバージョンを上げて、vSphere Replicationでペアリングして、レプリケーションして、IPアドレスを変えずにV2Vしますという話なので、けっこう大変ですね。

そして、L2延伸のネットワークをつくります。L2延伸のネットワークも、HCXでオペレーションできるわけではなくて。私たちはネットワーク会社なので、ネットワークのインテグレーションができます。弊社のルータである「SEIL」(ザイル)を使ったのですが、それでL2延伸のネットワークを、L2TPでトンネリングする、といったネットワークを作りました。

vSphere Replicationを導入するために、vCenterのバージョンアップするということで、非常に苦労したというところがあります。

この図はけっこう簡単そうに見えるかもしれません。実際にこういう運用をされた方はおわかりだと思いますが、例えば、このL2延伸のネットワークを1つ作るだけでもけっこう大変です。なぜかというと、こちらのオンプレミスの環境で、こちらはポータルサイトという話なので、24時間365日動き続けています。

プロダクションの環境に手を入れて、新たなコンポーネントを入れますというのは、すごく大変な作業です。当然、作業のためには設計もしないといけないですし、手順書を作らないといけないですし、手順書のレビューもしないといけない。それをいつ入れられるかというと、そもそもいつでも停められるようなシステムでもないし、なにかあったら困るよねという話になる。このあたりの作業の調整に非常に時間がとられます。それで苦労した案件になります。

このような移行案件事例をみて、ここで申し上げたいことは、単純に「V2Vで移行しますよ」って言っても、その環境構築は複雑で、さまざまな考慮事項があります。なので、移行方式を簡略化できるという話になれば、非常に大きなメリットがあると考えています。ここでHCXを活用できればと考えています。

オンライン移行できることの価値

山本:HCXのメリットとはなにか。これ(移行方式の簡略化)以外にもあるんですけど、大きなメリットとして3つ挙げさせていただきます。

1つめは、HCXがNSXと連携してL2延伸を実施します。先ほど私が話した案件だと、私たちがネットワークのインテグレーションをして、私たちのルーターをつかって、L2延伸をして移行しましたといった話なんですが、HCXを使えばその機能でL2延伸ができるというのが大きなメリットです。

先ほど、オンプレミスの環境に手を入れるのってすごく嫌だし大変だよねって話をしました。クラウド側の移行先にNSXは必要なんですが、オンプレミスにNSXは不要です。

なので、オンプレミスの構成変更を最小限にできるというメリットがあるので、ここでHCXは使えるだろうと考えていただくのはポイントかなと思います。

2つめは、無停止の移行。サイト間のオンライン移行が可能です。HCXの機能でL2延伸ができますので、IPアドレスも変更せずにvMotionでデータセンター間の移行ができます。

ここで3つめ、あと1つ言いたいのは、オンラインの移行ができるというのは、非常に価値があるということです。またちょっと運用というか、細かいオペレーションの話になってしまって申し訳ないのですが。例えばvSphere Replicationでもいいんですけど、レプリケーションベースで実際にV2Vとかをやられたことあるかたはご存じだと思うのですが、V2Vで移行すると仮想マシンって停止しますよね。

停止すると、電源を入れていないといけないじゃないですか。先ほど手順書の話をしたのですが、電源オフして上げるというのは、手順書にも電源オフして上げるという手順を入れて、レビューを通して、いろんなことをしないといけない。これって、けっこう大変なことなんです。

移行方式一本化のメリット

山本:先ほど「IIJはシンプルに」という話をしましたが、シンプルに移行ができるのは価値のあることだと思います。いろいろシンプルにしていくと、移行の環境構築とか作業が簡略化されます。移行方式も一本化することによって、手順書作成とか、もろもろの業務調整も含めた作業工数の削減ができます。

ここで、HCXに対する期待と、今後の私たちのビジョンをお話しさせていただければと思います。

私たちでPoCをやったのですが、その実際の構成はこんな感じです。オンプレミスに環境をつくって、クラウドに動かす。

(投影のみのスライドが表示)

ここで1つ言いたいことは、クラウドにはNSXが必須となるという話です。NSXが必須ってなると、NSXを使いたくない人、SDDCに行きたくない人って、もしかしたらいるかもしれません。NSXを入れるのは大変だよね、いまは入れるタイミングじゃないよねみたいなこともあって、そういうときにHCXって困ってしまうなということも見えてきました。

あとは、当然vMotionのロジックで移行するので、大量のホットマイグレーション、例えばその運用ってマイグレーションがオンラインでできなかったりします。

なので、そういったVMはうまく停めて移行しないといけないといった、事前の環境の調整は必要です。単純な仮想マシンの移行ではなくて、VMware SDDCの世界、NSXとかも含めた世界へ移行することを意識していただいて、HCXを使っていただくといいんじゃないかなと思っております。

HCXの先にある、パブリッククラウドサービスの開発

山本:やっぱり、クラウドの移行って大変です。基盤変更するといろいろ考慮しないといけないとか、じゃあ手段はどうするのとか、あとは誰が作業するのとか、いろいろ課題があります。

私たちのアプローチとしては、先ほど申し上げたように、基盤変更に対してはそのままクラウド化できます。手段に対してはHCXも提供しますし、先ほどのようにSDDCにいきたくない、いけないという方には、別の手法でも提供できるツールも提供しています。今日はvFORUMなのでこのあたりの話はあまりしないのですが、そういったツールも提供しています。

あとは、移行作業もしっかりできるようにしたいと考えています。なにをしたらいいかというと、「移行作業ができません」「移行するのが大変です」となった場合、弊社はSIerの側面も備えていますので、ツール提供にとどまらず、作業を定型化してアウトソースできるようにもしています。

これだと完全にSIになりますが、そうではなくて、「こういうことをします」ということを決めることで、費用を圧縮したり、作業のナレッジ化をうまくできるようにしていきます。

HCXの先には、当然、パブリッククラウドがあります。うまく連携できるネットワークも含めたサービスを、IIJとしては今後つくっていきたいと思っています。

見方を変えると、ネットワークだけじゃなくてIoTの電子デバイスだったり、モバイルだったりということも含めまして、ネットワークも含めたひとつのクラウドサービスみたいなかたちでみせていきたいですし、IIJとしてはそういったサービスを提供していきたいと思っているので、よろしくお願いします。

これで、私のプレゼンテーションは終了させていただきます。どうもありがとうございました。

サービスのご紹介

IIJ GIOコンポーネントサービス 仮想化プラットフォーム VWシリーズ
VMware HCX on IIJ GIO

IIJのクラウドサービスに関するお問い合わせ

コメントは受け付けていません。