Find Communities by: Category | Product

1 2 Previous Next

日本語コミュニティ

17 Posts authored by: emc-hirahara

こんにちは、クラウドプラットフォームスペシャリストの平原です。

 

2017年11月28日、Dell EMCは国内での提供開始を含む、「Dell EMC Cloud for Microsoft Azure Stack」のプレスリリース(リンク)を発表しました。この発表に先だって、同日、日本マイクロソフト株式会社様によるMicrosoft Azure Stack 記者発表会も行われ、会場にいた私もその場の熱気とともに、Azure Stackへの高い関心と期待を感じ取りました。

そこで、今回はDell EMCが提供するAzure Stack製品について紹介します。

図8.png

 

Azure Stackとは?

Azure Stackは、パブリッククラウドサービスで既に知られているMicrosoft Azure(以下 Azure)の仕組みとサービスをハイパーコンバージドインフラ(HCI)上に実装し、社内データセンターでAzureサービスを利用可能にしたものです。

図1.png

これまで、異なるテクノロジーのクラウド同士を統合管理するってとても難しかったですよね?Azure Stackだと、Azureと同じクラウドモデルを社内データセンターに持ち込めるので、真のハイブリッドクラウドを容易に実現し、運用の違いや場所を意識することなく、Azureで開発された最先端のクラウドアプリケーションを自在に展開出来るようになります。

図2.png

 

Azure Stackを使うと何が嬉しいの?

例えば、何か新しいビジネスを始めるために、ウェブやモバイルを活用したアプリ開発を手っ取り早く始めたい場合どうしますか?AWS, Google Cloud Platform, Azureといった選択肢が出てくると思います。しかし、企業ポリシーの制約で顧客のプライバシーを持つ情報を社外に置くことが許されないとしたらどうでしょう?その途端に、これらパブリッククラウドサービスのほとんどは候補から外れてしまいます。

図3.png

でも、Azureであればその課題に対応出来ます。Azure StackならAzureのサービスが社内データセンターで使え、Azureで開発したアプリケーションコードも変更無しに実行出来るのです。Azure Stackなら「クラウドは活用したい!でも、場所や企業内の制約が…」みたいな理由で諦める必要はもう無くなりますね!

図4.png

 

Azure Stackって導入は難しいの?

色々とメリットがありそうなAzure Stackですが、クラウド基盤の導入なんて経験もないし、難しいのではという疑問も出てきそうですね。でも、そこは心配に及びません。Azure Stackはマイクロソフトが直接販売するのではなく、インテグレーテッドパートナーと呼ばれる、マイクロソフトとの協業で実績のあるハードウェアベンダー各社が、自社ハードウェア製品とAzure Stackソフトウェアをパッケージング、インテグレーテッドシステムとして販売します。従って、通常は、HCIノード用のサーバー、管理用サーバー、ToRスイッチおよび管理スイッチがラッキング、ケーブリング、そしてその状態で動作検証まで行われた状態で出荷されます。

図5.png

お客様側ではラックスペースおよび電源の確保、上位スイッチのルーティング仕様と設定確認まで行っていただければ、後はDell EMCがお客様とのヒアリング情報に基づいて、ハードウェア設置とAzure Stackの設定までを行ったうえでお客様にお引き渡しします。この時点でAzure Stackのポータルは利用可能になっています。

 

今回の発表の「Dell EMC Cloud for Microsoft Azure Stack」、何がスゴいの?

さて、各社のAzure Stack製品、所詮はx86サーバーにAzure Stackソフトウェアが載っているだけでどれも同じと思っていませんか?色々見ていくと、製品としてインテグレートする過程で、ベンダー各社の思想が反映されていて興味深いです。そして、Dell EMCにおけるその一つが「最新技術への徹底したこだわり」です。

 

10月19日にマイクロソフトは、Azure StackでIntel Xeonスケーラブルプロセッサがサポートされたことをブログ(リンク)でアナウンスしました。そして、その同日にDell EMCも同プロセッサを採用したAzure Stack製品のリリースをいち早くブログ(リンク)でアナウンスしました。

図6.png

 

今度の「Dell EMC Cloud for Microsoft Azure Stack」、とにかく圧倒的な性能キャパシティ向上を実現しています。このグラフを見てください。一世代前のPowerEdgeベースの製品と比較して、最大で約2.5倍のAzureインスタンスが収容出来ます。

図7.png

これは何を意味するのでしょうか?これまでの仮想化基盤と異なり、クラウドネイティブな基盤はひとたびサービスが当たればキャパシティの予測は非常に困難です。この時、同じフットプリントでより多くのサービスをこなせるかは、ビジネスの結果に直結する重要なポイントです。もちろん、真のハイブリッドクラウドが実現出来るAzure Stackなら、Azureのリソースと組み合わせた、より柔軟なキャパシティ管理が可能となります。

 

Azure Stackはマイクロソフトおよびパートナーとともに進化し続けます

Azure Stackは、単なるHyper-V仮想化基盤(インフラ)ではなく、提供される機能も使い方も、まさに「データセンターに延長されたAzureサービス」と考えたほうがすっきりするでしょう。従って、Azure Stackもまた、パブリックのAzureサービスと同様に定期的に機能が追加、強化されながら成長してゆきます。手間をかけることなく、最新のサービスがオンプレ基盤で使えるようになるというところも期待したいところですね。

 

さて、この度のプレスリリース(リンク)発表に際しては、計10社のお客様およびパートナー各社様から、エンドースメントへのご賛同をいただきました。ここにご紹介させていただくとともに、ご賛同に深く感謝を申し上げます。(敬称略、50音順)

 

  • 伊藤忠テクノソリューションズ株式会社
  • 株式会社インターネットイニシアティブ
  • 日商エレクトロニクス株式会社
  • 日本コムシス株式会社
  • 日本ビジネスシステムズ株式会社
  • 日本マイクロソフト株式会社
  • 株式会社野村総合研究所
  • 株式会社ブロードバンドタワー
  • 三井情報株式会社
  • リコージャパン株式会社

 

そして、ご賛同いただきました各社様とこの「Dell EMC Cloud for Microsoft Azure Stack」をしっかりと育てていきたいと考えています。どうぞご期待ください。

< 前回の投稿を読む

 

こんにちは、仮想化技術およびクラウドソリューション担当の平原です。クラウド導入に伴い、プロビジョニングの主体者が事業部門利用者に移ってくると、逐次利用者からの要求を把握するのは困難になってきます。カタログの設計にもよりますが、やはり品揃えを考えれば松竹梅スペックの仮想マシンは一通り揃えたい、しかし、簡単に作れるからといって松スペックの仮想マシンばかり要求されても困る...このような時にはリクエスト承認の機能を持たせることで一定の抑止効果を持たせられるのではないでしょうか?承認フローをどのレイヤーで持たせるかはお客様の議論によって変わってきますので、vRealize Automationより上位のITSMプロセスツールや他のオーケストレータに実装するというのも1つの答えです。どこにどのように実装するのかは正解はないのですが、ここでは簡易にvRealize Automationを使ったメールベースの承認機能を紹介いたします。

 

承認はカタログの実行や仮想マシンのアクションなどに個別に持たせることが可能です。これらはApproval Policy(承認ポリシー)によってふるまいが決定されます。それでは実際に承認ポリシーを作成しながら進めてみます。

 

今回はAmazon EC2のいくつかのカタログの中でCPU、メモリスペックが高い、c3.8xlarge(32CPU、64GBメモリ)インスタンスタイプの仮想マシンプロビジョングに承認を適用したいと思います。では、新しい承認ポリシーを作成します。

approval_policy1.png

パブリッククラウド上の仮想マシン作成のポリシーなので、"Service Catalog - Catalog Item Request - Cloud Machine"をチェックします。

approval_policy2.png

承認ポリシーのための条件設定を作成します。ここではCPUが8個以上を承認対象とします。また、承認要求のためのメールアドレスを入力します。

approval_policy3.png

同様にメモリが16GB以上を承認対象とする設定をもう1つ作成します。

approval_policy4.png

これで承認ポリシーの作成は完了です。

approval_policy5.png

 

approval_policy6.png

 

次にエンタイトルメントを編集します。ここでは開発部門DevOpsのエンタイトルメントを編集します。

cat_item1.png

c3.8xlargeインスタンスタイプのサービスカタログに承認ポリシーを紐付けるためにEntitled Catalog Itemを追加します。

cat_item2.png

ここで承認ポリシーを適用したいサービスカタログと承認ポリシーを指定します。

cat_item3.png

これで追加されました。承認ポリシーはサービスカタログ個別に設定も出来ますし、サービスに対して複数のカタログに一律に設定することも可能です。

cat_item4.png

では、DevOps開発部門利用者からサービスカタログを実行してみます。

run_cat1.png

スペックを確認し、リクエストをSubmitします。

run_cat2.png

自分のリクエストを確認するとステータスが"Pending Approval"になっているのが分かります。

run_cat3.png

この情報はメールでも通知されます。

run_cat4.png

同時に管理者側にも承認要求のメールが通知されます。管理者はメール下部のリンクからリクエスト内容を確認します。

run_cat5.png

管理者はリクエストの妥当性を判断のうえ、利用を追記し、"Approve"または"Reject"を選択します。ここではリクエストを却下します。

run_cat6.png

 

run_cat7.png

利用者側にはリクエストが却下された旨のメールが通知されます。また、ポータルのリクエストステータスも"Rejected"に変更されています。

run_cat9.png

 

run_cat8.png

 

このように承認機能をうまく利用すると、ITサービスの俊敏性を落とすことなく、オンプレミスの極端なリソース占有やパブリッククラウドサービスでの高価なスペックの仮想マシン作成に一定の抑止をかけることは出来そうです。

 

続きの投稿を読む >

< 前回の投稿を読む


こんにちは、仮想化技術およびクラウドソリューション担当の平原です。今回はvRealize Automationの活躍の幅を拡げてみましょう。みなさん、vRealize Automationって仮想マシンに関するオペレーションの自動化しか出来ないと思っていませんか?実は、vRealize AutomationにはAdvanced Service Designer(vRealize Automation 7からはXaaS Services。ちなみにXaaSはAnything as a Serviceと読みます...)と呼ばれる機能を使って、vRealize OrchestratorのワークフローをvRealize Automationのブループリントから直接呼び出す機能があります。これを使うと、例えばADユーザの作成、無効・有効化、削除などの作業を部門利用者に開放することが可能になります。

 

既に利用者で開発済のvRealize Orchestratorのワークフロー"Create a user with a password in an OU and set department"があるという前提で話を進めます。これはADの指定されたOUに新しいユーザを作成し、部門のコストセンターを登録するというものです。

vro_wf_tree.png

ちなみにこのワークフローはvRealize Orchestrator上から直接実行できます。

vro_wf_tree2.png

ウィザードの指示に従って、要求されるパラメータを入力(この画面ではOUの選択)すれば処理が実行します。vRealize Orchestratorからのワークフロー実行はクラウド管理者に限定されますが、例えば、部門内の人の異動でプロジェクト人員の変更などがあることを考えると、これがセルフサービスポータル経由で実行出来れば、IT担当者への依頼なしに速やかに処理が可能になりますね。

vro_wf_tree3.png


では、設定です。設定の流れとしてはカスタムリソースの作成、XAASブループリントの作成とパブリッシュ、以降はカタログアイテムとして編集し、エンタイトルメントを付与することで利用者に機能の開放が可能です。基本的には仮想マシン作成などのカタログ作成の流れと似ています。

 

カスタムリソースは、vRealize Automationで受け取った値をvRealize Orchestratorのワークフローに引き渡すための定義体と言えるものです。

custom_rsrc1.png

ここではADユーザの作成を行うという動作なので、Orchestrator TypeからAD:Userを選択します。

custom_rsrc2.png

"Is enabled"フィールドがあるのを確認します。

custom_rsrc3.png

 

次にXAASブループリントを作成します。

xaas_bp1.png

vRealize Orchestratorのワークフローツリーが表示されるので、"Create a user with a password in an OU and set department"ワークフローを選択します。

xaas_bp2.png

適当なブループリント名を入力します。

xaas_bp3.png

vRealize Orchestratorに引き渡すパラメータの入力フォームを指定します。OUはADから参照したOU一覧をツリー表示し、そこから選択するようにします。

xaas_bp4.png

部門のコストセンターはドロップダウンリストでの選択を指定します。ドロップダウンリストは外部(例えば人事システムなど)からのエクスポート出力を利用するイメージです。

xaas_bp5.png

ドロップダウンリストデータの参照先を指定します。

xaas_bp6.png

ドメイン名は1つしか選択がないので固定値の入力とします。

xaas_bp8.png

固定値とはいえ、利用者に誤って書き換えられては困るので"Read only"の拘束条件を付けます。このような形でvRealize Automation側でlook & feelを仕上げていきます。

xaas_bp9.png

ブループリントの作成が完了です。

xaas_bp10.png

あとは前回のカタログ作成と同じようにXAASブループリントをパブリッシュします。

xaas_bp11.png

パブリッシュされたXAASブループリント(カタログアイテム)を編集しましょう。

cat_item1.png

アイコンを編集し、サービスカタログのグルーピングであるサービス(ここでは"Services")を関連づけます。

cat_item2.png

後は開発部門へのエンタイトルメントを確認します。

entitle1.png

先ほどのカタログアイテムに紐付けたサービスが見えているのでこれでOKです。

entitle2.png

 

さあ、開発部門の利用者(devuser)でログインし直してみましょう。無事、Servicesに"Create AD User"カタログが見えているようです。では、実行してみましょう。

run_cat1.png

リクエスト名と申請理由を入力します。

run_cat2.png

ブループリントの設定のとおり入力画面が現れました。OU、部門コストセンターを選択して、Submitするとワークフローが実行します。

run_cat3.png

ワークフローの実行が完了したのでWindows側の管理ツール(Active Directory Users and Computers)で確認してみましょう。

run_cat4.png

無事、ADユーザは作成されたようです。

run_cat5.png

 

利用者が作成したADユーザは、仮想マシン同様に自らのアイテムとして管理が出来ます。

action1.png

ちなみにXaaS Servicesでは、XAASブループリントではなく、リソースアクションで定義をするとアイテムのアクションドロップダウンメニューからユーザの削除や無効化などの実行ができるようになります。サービスカタログから実行して、削除したいユーザを探すみたいなことするよりもスマートですね。

action2.png

 

action3.png

このようにAdvanced Service Designer(XaaS Services)を活用すると、より日頃の運用周りを効率化出来そうです。(この部分の実装は弊社のカスタムサービスの範囲となりますのでご注意ください)

 

続きの投稿を読む >

< 前回の投稿を読む

 

こんにちは、仮想化技術およびクラウドソリューション担当の平原です。クラウドの導入如何に関わらず、問題発生時の調査対象の構成確認や構成設定変更時の影響範囲の特定などを目的にITインフラの構成情報は何らかの方法で管理されていると思います。では、現状これらの情報はどのように管理されているでしょうか?ITサービスマネジメントのベストプラクティスと言われているITILでは、構成情報を集中管理するための要素としてCMDB(構成管理データベース)が定義されていますが、これもは何か実際のデータベースシステムを構築して運用すべきものではなく、Excelシートなどのいわゆる台帳管理であったとしても唯一の情報として正しく管理されていれば、それは立派なCMDBとして機能します。そして多くのお客様がこのExcelシートによる手作業での管理を採用されているのはないでしょうか?

manual_cfg_mgmt.png

クラウド導入においてのもう1つの悩みは、インフラそのものを置き換え、自動化するだけではその効果は限定的であり、従来の運用フローとどのように連携するのか?そして、そもそも従来の運用がクラウドとの連携にあたって一気通貫での自動化の阻害要因となるのであれば、運用そのものを見直すというところにまで考えを拡げる必要があります。この点でこの手作業での構成管理プロセスというのは多くのケースで変革を迫られる領域の1つと言えます。

 

一番簡単な方法としては、定期的なタイミングでvRealize AutomationやvCenter Serverからプロビジョニング済の仮想マシン情報を取り出し、それを構成管理のマスターにすることですが、いつプロビジョニングが実行されるか分からないクラウド環境においては、必ずしも取り出した情報と現況の一致を保証することは難しく、また、構成管理の適用範囲も極めて限定されるため、特に構成アイテムの関連性をもとに影響範囲の特定などでは支障をきたす可能性があります。

 

もう1つの方法は、新たなCMDBを構築し、API連携等によって仮想マシンのプロビジョニングやデコミッショニングのタイミングで自動で更新可能な仕組みを検討することです。この方法は、他のインフラ領域の構成情報と統合でき、相互関連性を持たせられること。担当者や保守契約情報など機器から自動収集される以外の情報を柔軟に付加、管理できることなどから、高いレベルの運用性を持たせることが可能ですが、

  • そもそもCMDBとしてどんなツールを採用するのか?
  • 構成管理の範囲をどこまで拡げ、スキーマをどのように定義するのか?
  • 既存の構成情報の取り込み(インポート)はどうするのか?
  • 他の運用管理ツール(インシデント管理、ヘルプデスク等)との連携はどうするのか?

など、クラウドのインフラ導入に匹敵するだけの工数を想定しておく必要があるかもしれません。

 

このため、このようなITサービスマネジメントやビジネスワークフローをSaaS(Software as a Service)として提供する会社も現れてきており、米国ではServiceNowというSaaSの利用シェアが高まっているようです。Enterprise Hybrid Cloudにおいても欧米市場における利用シェアを鑑みて、ITSM連携のリファレンスアーキテクチャにServiceNowを採用しています。

ServiceNowの概要はこちらです(ServiceNow社のホームページに飛びます)

 

連携イメージとしては、下記のイメージのとおりです。Enterprise Hybrid Cloud環境には、vRealize OrchestratorにDELL EMCが開発したServiceNow連携検証済のワークフローが導入され、vRealize Automationのブループリントからワークフロー実行がトリガされる仕組みです。Enterprise Hybrid Cloudのオンプレミス環境とServiceNowとの情報のやり取りは、ServiceNow社が提供するMID(Management, Instrumentation, and Discovery)サーバをデータセンター上に配置することにより、HTTPSの通信許可を与えるだけで可能となります。

ehc_snow_integration.png

では、vRealize側の画面を見てみましょう。まずはvRealize Orchestratorですが、ここにはDELL EMCによる開発済のワークフローが導入されます。標準ユースケースの導入であれば特にカスタマイズなく導入が行われます。ここでのワークフローに与えられているIDはvRealize Automation側での設定で必要となってきます。

workflow1.png

次にvRealize Automation側でサービスカタログ実行とServiceNow連携ワークフローの実行を紐付けます。これは毎回のように出てくるBuild ProfileBlueprint上で設定されます。Buildprofileでは、仮想マシンのライフサイクルステータス(作成、除却など)を示すWorkflow Stub(ワークフロースタブ)という情報に対して、先ほどのvRealize OrchestratorワークフローのIDを紐付けます。ここでは"ServiceNow Integration"という名前でBuildprofileを作成しました。

buildprofile2.png

次にBlueprintの作成または更新です。重要なのはPropertiesタブの部分です。ここに先ほど作成したBuild Profileである"ServiceNow Integration"が表示されているはずですのでこれにチェックを入れます。実際のところBlueprintへの仕込みはこれだけです。

blueprint1.png


blueprint2.png

一見分かりませんが、ServiceNowと連携するサービスカタログの完成です。

provision1.png

では、実際にプロビジョニングしてみましょう。Propertiesタブに先ほどのBuildprofileの設定内容が反映されています。

provision2.png

 

provision3.png

リクエストステータスがSuccessfulで新しい仮想マシンが作成されました。ここの仮想マシン名"BLRPOCLIN043"に着目しておいてください。

provision5.png

 

provision7.png

ServiceNowのポータルにアクセスしてみます。無事、仮想マシン"BLRPOCLIN043"が登録されていました。

snow1.png

 

snow2.png

 

snow3.png

次に仮想マシンの除却を行います。仮想マシンのアイテムを開いて、操作メニューから"Destroy"を選びます。

provision6.png

仮想マシンが問題なく削除されると、ServiceNow側の仮想マシンステータスは"Retired"に変更されました。過去の履歴管理を行う上では仮想マシンが削除されたからといって構成情報も消すわけにはいかないですから...

snow4.png

いかがだったでしょうか?以前のブログでREST APIによる情報取得例を紹介しましたが、実際には情報取得だけでなく、このようなツール間連携もお互いのツール内部にガチガチな造り込みをすることなしに、緩~い感じ(!?)で実現出来てしまいます。いわゆるソフトウェアディファインドやクラウドの特徴でもあるプログラマブルITの好例でしょう。この「プログラマブル」という概念は非常に重要です。これがあるからこそ、どんな複雑な要件に対しても柔軟に基盤を拡張できる、また自分に足らない、出来ないことも他の力を借りて実現できるわけです。AWSが成功をおさめたのも、まさにこの他の力を借りる「エコシステム」を創り上げたことによるものと言えます。

 

Enterprise Hybrid Cloudもまた、お客様のユースケースに役立つサードパーティーインテグレーションを継続的に進めていきます。

  • ServiceNow:ITSMソリューション連携
  • Infoblox:IPAM(IPアドレス管理)ソリューション連携
  • Palo Alto Networks:フォイアウォールソリューション連携
  • Puppet Enterprise:Infrastructure as Code(構成管理自動化)ソリューション連携
  • Chef(計画中):Infrastructure as Code(構成管理自動化)ソリューション連携

 

続きの投稿を読む >

< 前回の投稿を読む

 

こんにちは、仮想化技術およびクラウドソリューション担当の平原です。今回はIaaS、クラウドへの移行の際に切っても切り離せないお金(コスト)の話です。これまで、日本のお客様のほとんどはサービス(システム)ごとに縦割りのインフラを構築し、お金の出所も各プロジェクトのお財布からというのがほとんどでした。弊社が主力製品としている統合ストレージが普及してからも、実はこの考え方はあまり変わることなく、「筐体内のここからここまでのディスクは我がプロジェクトの予算で購入」みたいなことが通用していたこともあり、ファイナンス面から見たITリソース管理というのは従来のサイロ型の域を抜け出ることがありませんでした。結果として、自分がお金を出していない部分には一切タッチが出来ないものですから、ある部分のリソースが余っていたとしてもそれを有効活用することも出来ないという状況が発生したのです。では、クラウド時代におけるリソース管理の考え方というのはどういうものなのでしょう。言い尽くされてはいますが、改めてNIST(米国国立標準技術研究所)によるクラウドコンピューティングの定義を振り返ってみましょう。

nist_cloud_definition.png

※ NIST Special Publication 800-145 NISTによるクラウドコンピューティングの定義(翻訳:独立行政法人 情報処理推進機構)から引用

 

この定義の3番目がまさにリソース管理のあるべき姿を言い表しています。そして、リソースの集積とマルチテナントモデルによる共用が進むと、5番目の定義であるサービスの計測可能性がより重要な意味を持ってきます。共通のお財布から購入されたものを皆で使い合うわけですから、各々が実績に応じてどれだけ利用したかというのは利用の公平性という点で常に求められてくるわけです。従って、IT管理者の立場としては、利用実績の提示を行うにあたって「このサービスを今提供するためにそもそも一体幾らかかっている」のかということをきちんと透明性(もしくは納得感)をもって可視化しておかないといけないのです。Enterprise Hybrid CloudでもこのITコストの透明性は重要な要件と位置づけており、そのためのツールとしてvRealize Suiteに含まれるvRealize Business Standardを活用しています。

 

では、vRealize Business Standardがどのようなものかを説明しましょう。vRealize Business Standardは社内クラウドサービス提供に関わるコスト要素(コストドライバ)から、ITコスト全体の可視化を図るためのツールで、以下のような分析を支援します。

vrb1.png

 

① クラウドコスト分析

vCenterなどから収集されたサーバ型番やOSなどの情報をもとに、各種コスト情報が収録されているリファレンスデータベース(VMware社が定期的にメンテナンスおよび提供)の参照または手入力によって月額ランニングコストを試算します。

vrb2.png

クラウドコスト計算のためのコストドライバ

vrb_costing.png

② オペレーション分析

先の月額コストをベースに、CPUおよびメモリ使用率などから実際の仮想マシン稼働コストを算出することで費用対効果の分析を支援します。

vrb3.png

仮想マシンコストの計算

vm_costing.png

③ 消費分析

実際の仮想マシン稼働コストと、各利用部門予算(バジェット)および値付けに基づくチャージ金額との比較分析から、予算配分の最適化および価格設定適正化のための分析を支援します。

vrb4.png

 

vrb5.png

④ クラウドサービス間のコスト比較分析

仮想マシン作成にあたって、オンプレミスとパブリッククラウドサービス間で仮想マシン料金の試算を行うことで利用者に最良の選択肢を提供。

vrb6.png

ITコスト管理に関してはお客様それぞれの考えもあるため、独自の計算ロジックが実装されているvRealize Businessをそのまま適用することが必ずしも最良の方法とは言えませんが、入力パラメータのチューニングを施すことで、分析結果にある程度の妥当性を持たせることは可能かなと考えています。とはいえ、ここは正直言うと、Enterprise Hybrid Cloudでも推奨パラメータというのは持ち得ない部分なので実運用に持って行くまでには試行錯誤が必要そうです。個人的な感想としては、クセのあるなかなか手強いツールではあります。

 

あと、ITコスト管理で必ず話題になるのはチャージバック(利用者へのコスト配賦)です。ここもチャージバックに求めるものがお客様ごとに異なるので、どういったことを実現したいのかは千差万別です。ただ、共通項としては以下のような要件が挙げられます。

  • 企業部門コード単位での課金
  • 四半期程度の価格改定への対応
  • 締日に基づく月額請求
  • 月途中からの利用の日割計算への対応
  • 月途中からの割り当てリソース変更への対応

このような要件に対応するための配賦額の計算やレポーティングに関しては、かかるコストの提示を目的としたショーバックツールのvRealize Businessには不得手であり、多くのお客様の要件に合わせるのは難しいのが実情です。残念ながらVMware社から販売されていたvCenter Chargeback Managerも販売終息となってしまった現在では、vCenterから取得した仮想マシンの基礎情報と独自の価格テーブルから、vRealize Orchestratorなどのワークフローで計算させる方法(要開発)が主流となっています。このあたりはチャージバック開発に実績のあるSIer様との協業でお客様の要件にお応えする体制を整えております。

 

続きの投稿を読む >

< 前回の投稿を読む

 

こんにちは、仮想化技術およびクラウドソリューション担当の平原です。では、ここからはいよいよAmazon EC2の仮想マシンプロビジョニングのためのサービスカタログを準備していきます。設定の相関図では青と周辺の緑の部分の設定になります。

vra_settings4.png

まず、サービスカタログを収めるService(サービス)を定義します。これはサービスカタログのグルーピングと同時に、後で設定する利用者ごとのアクセス権に絡んできます。"Public Cloud Services"という名前で作成してみます。

add_service.png

次にこのサービスにEntitlement(エンタイトルメント)を付与します。これは作成したサービスに誰がアクセス可能かなどを定義するものです。事前に作成しているDevOpsチームのエンタイトルメントに"Public Cloud Services"サービスを紐付けます。

add_entitle1.png


add_entitle2.png

次にいよいよ本丸のBlueprint(ブループリント)を作成します。

blueprint1.png

このブループリントに紐付く組織(Business Group)や仮想マシンの命名ルール(Machine Prefix)などを指定します。

blueprint2.png

このブループリントで使用するAmazon仮想マシンイメージ(AMI)とインスタンスタイプを指定します。AMIの参照はAWSコンソールでインスタンス作成時に表示されるAMI IDをもとに検索可能です。

blueprint3.png

blueprint4.png

カタログとして公開するためにブループリントをパブリッシュします。

blueprint5.png

パブリッシュされたカタログを編集し、先ほど作成した"Public Cloud Services"サービスに紐付けます。

catalog.png

これでサービスカタログが無事公開されました。(ブループリントを複製して、いくつかのインスタンスタイプでカタログを作っています)

service_portal.png

ここから仮想マシンをプロビジョニングしてみましょう。この例ではインスタンスタイプは固定なのでスペックは自動的に決定されます。ネットワークをVPC(Virtual Private Cloud)上に作成することを選択します。

provision1.png

VPC上のサブネットとセキュリティグループを選択し、リクエストを実行(サブミット)します。

provision2.png

リクエストの状態は必要なときにポータルから確認できます。

provision3.png

AWSコンソールからの確認でも、Machine Prefixに基づいた名前でインスタンスが作成されていることが確認できます。

aws_console.png

作成が完了したら、出来上がった仮想マシンをクリックします。

provision4.png

電源操作、シャットダウンはvRealize Automationのポータルから操作可能です。また、SSHでアクセスするための証明書ファイル(pemファイル)もこちらからダウンロード可能です。

provision5.png

このようにvRealize Automationのマルチクラウド管理機能を活用することで、単一のポータルから複数のハイパーバイザ、クラウドサービスの選択が可能となり、よりコスト性に優れたITサービスを実現出来るようになります。ここまで随分と長い手順説明でしたが、Enterprise Hybrid Cloudなら今回のようなAWS連携も既にパッケージ化されているので、要件に応じて必要な導入サービスをアドオンしていただければ、お客様側でこのような余計な手を煩わせることはありません。


あと余談ですが、仮想マシンを作成する際にvRealize Suiteに含まれるvRealize Businessというツールを使用すると、価格的に社内と社外どちらのサービスを使うのがいいかを試算したうえでサービスリクエストすることも可能です。この例では、低スペックの仮想マシンはパブリッククラウドサービスを使うのがリーズナブルですが、実は高スペックの仮想マシンならオンプレミスの社内リソースを使う方がお得であるという結果が出ました。これまで時間を要していた見積もり比較に相当する部分を大幅に短縮しながらも、ビジネスチャンスを逸することなくより最良の決定を下せるようにもなるのも明朗会計なクラウド導入のメリットと言えるでしょう。

vrb_cloud_compare1.png

vrb_cloud_compare2.png

このvRealize Businessについては、次回にもう少し説明をしてみたいと思います。

 

続きの投稿を読む >

< 前回の投稿を読む

 

こんにちは、仮想化技術およびクラウドソリューション担当の平原です。私は毎月のお小遣いに昨今の景気の厳しさを実感していますが、それは企業とて同じ。これまでのような潤沢な予算も確保出来ないなか、事業部門利用者が社内ITに注ぐ視線は実にシビアです。これまでなら言い値(?)ベースで疑問も持たずに使っていたけど、外にはどうも良さそうなサービスがあり、しかも低価格で明朗会計!となれば、より安いほうへと思うのも致し方ありません。かといって、そのまま好き勝手に使わせるにもいかず...ならば、VMware社の言葉を借りれば、Freedom(自由)とControl(統制)をどのように両立させるかというところで、社内ITの要求に叶うパブリッククラウドサービスをvRealize Automationからまとめて提供するようにしてみてはいかがでしょうか?vRealize AutomationはvSphere環境のためだけの製品ではなく、パブリッククラウドも含めたマルチクラウド環境に対応したポータルの構築が可能です。現在、Enterprise Hybrid CloudでサポートしているvRealize Automation 6.xでは、Amazon EC2, OpenStack, vCloud Air Networkパートナー(vCloud Director)に対応しており、近い将来にはvRealize Automation 7.2ベースでのMicrosoft Azureへの対応も計画しています。

hybridmodel.png

 

今回はvRealize AutomationでどのようにAmazon EC2のリソースにアクセスするための設定を行うかを説明します。以前に利用した設定の相関図ですが、今回は青い部分のEndpoint(エンドポイント)と呼ばれる部分の設定から始めます。Endpointはハイパーバイザ環境やクラウドサービスの管理ポイントを登録するもので、vSphereであればvCenter、Amazon EC2であればAWSコンソールがエンドポイントに相当します。ここの設定ではエンドポイントにアクセスするための認証情報が必要になるため、緑色の部分のCredentialに各エンドポイント用の認証情報を登録しておきます。

vra_settings3.png

まずは認証情報の登録です。Amazon EC2の場合、AWSコンソール上で生成したアクセスIDとシークレットキーからなるキーペアを事前に生成し、これを登録します。

 

まずはAWSのアカウントが無い方はアカウントを作成してください。作成方法はこちらを。

AWS アカウント作成の流れ(アマゾン ウェブ サービス社のページに飛びます)

また、これを試したことによる課金にはご注意ください。(初めての作成であれば12か月の無料利用枠が活用できます)

 

AWSマネジメントコンソールからセキュリティ認証情報画面に進み、"アクセスキー"から"新しいアクセスキーの作成"を実行します。

keypair1.png

 

keypair2.png

キーファイル(rootkey.csv)をダウンロードして開くと、中にAWSAccessKeyId, AWSSecretKeyの2つのエントリが確認出来るはずです。これは以降のvRealize Automationの設定に使用します。

keypair3.png

 

keypair4.png

 

次にEndpointの登録に必要となる認証情報(Credential)を設定します。User NameはAWSAccessKeyId、PasswordはAWSSecretKeyの情報を使います。

credential.png

認証情報の設定が終わったらEndpointの登録を行います。"New Endpoint"-"Cloud"-"Amazon EC2"を選びます。

endpoint1.png

エンドポイント名とAWSコンソールにアクセスする認証情報を選択します。

endpoint2.png

右クリックメニューで"Data Collection"を選んで情報の取得を指示します。

endpoint3.png

エンドポイントの登録が完了したら、次にFabric Group(ファブリックグループ)を作成します。Fabric Groupはエンドポイント配下にあるITリソースを論理的に分割したり、または複数のエンドポイントのITリソースを統合したりすることが出来ます。Amazon EC2の場合は仮想マシンを作成するリージョンの選択になります。ここではシンガポールリージョンを選択しています。

fabricgroup.png

最後にFabric Group内のリソースからReservation(リザベーション)を作成します。Reservationはどの組織に対してリソースを割り当て、どこまでのリソース使用を許すか(仮想マシン台数やメモリ総量の上限など)、ITリソースの利用に一定のルール(枠)をはめるものと言えます。

res1.png

Resourcesタブでは仮想マシンにアクセスするための鍵認証のキーペア生成ルールやAmazon EC2ではVPC(Virtual Private Cloud)サービス設定のマッピングなどを指定します。

res2.png

VPCで設定されているサブネットおよびセキュリティグループ(ファイアウォール設定)を指定します。このReservationから払い出された仮想マシンに対しては指定したサブネットでIPアドレスが付与されます。

res3.png

 

res4.png

Amazon EC2のReservation設定では仮想マシンの台数でリソース上限をかけることが可能です。このリソース上限に近づいた時のメールでのアラート設定も可能です。

res5.png

 

ここまでで、vRealize Automationに対してAWSを利用するためのリソース設定が完了しました。次回はAmazon EC2の仮想マシンプロビジョニングのためのサービスカタログの作成と実行までを説明いたします。

 

続きの投稿を読む >

< 前回の投稿を読む

 

こんにちは、仮想化技術およびクラウドソリューション担当の平原です。今回は(私もそうですが)REST APIはちょっとなぁ...でも、コマンドがあればスクリプトなんかバリバリ作っちゃうぜ!というお方にオススメのCLIでの操作方法を説明いたします。実はVMware社はvRealize CloudClientというCLIライクなツールも用意しています。CLIライクというのはダウンロードしてみると分かるのですが、このCloudClientはWindowsバッチファイルおよびLinuxシェルスクリプトとJavaプログラムからなるツールで、スクリプト自身は裏でJavaを介してREST APIを叩いている、いわゆるラッパーソフトウェアとして動作するものです。とはいえ、使い勝手は全くのCLIそのものですし、ユーザスクリプトへの組み込みも問題なく行えます。ということで、このCloudClientを入手して実際にコマンドを実行させてみましょう。

現時点での最新版はバージョン4.3または3.5になります。どちらのバージョンを使うのかはvRealize Automationのバージョンに依存しますが、vRealize Automation 7.xであれば4.x、vRealize Automation 6.xであれば3.xを使用してください。


vRealize CloudClient 4.3のダウンロード

cloudclient.png

VMware Product Interoperability Matrixes

support_matrix.png

まず、ダウンロードしてきたCloudClientのzipファイルを任意のディレクトリ上に解凍してください。解凍後に出来たディレクトリの中にbinというパスがあるので、その中のバッチファイルまたはシェルスクリプトを実行します。そうするとCloudClient>というプロンプトが表示されるのでそこからコマンド操作が可能です(初回のみ使用許諾を求められます)。

cloudclient.png

操作方法はHTML形式のヘルプファイル(別途ダウンロード必要)を参照するか、helpコマンドで必要な情報を得られます。また、コマンドの途中でタブキーを押すと、以降に続く候補が得られます。

help.png

最初に必要なのはvRealize Automationへのログイン操作です。

vra_login.png

ログインが完了したら、以降は必要とする操作のためのコマンドを打ってみましょう。ここではNetwork Profileのリスト一覧を取ってみます。

vre_nwprofile_list.png

なお、このままの出力だとツール間連携には使いにくいので、出力形式をCSVまたはJSON形式で指定することも可能です。

CSV形式

vre_nwprofile_list_csv.png

こちらはJSON形式

vre_nwprofile_list_json.png

前回のREST API同様にNetwork Profileの詳細が取れるかを試してみました。残念ながら期待した情報は取れませんでした。機能的には必ずしもREST APIと同じというわけではないので注意が必要です。

vre_nwprofile_details.png

さて、ここまでのサンプルを見ていて、CloudClientの中で対話的にコマンドを叩いているけど、これではユーザスクリプトに組み込めないのでは?という疑問もあるでしょう。こういうときはautologinファイルを作成することで、ワンラインでコマンド実行までさせることが可能です。autologinファイルと暗号化されたパスワードを格納するkeyfileを作成してみます。

vra_autologin.png

autologinファイルは、解凍したディレクトリの直下に"CloudClient.properties"の名前で出来ているので、こちらを環境に合わせて編集します。

autologinfile.png

CloudClient.propertiesファイルの中身

autologinfile2.png

ここまでの準備が完了するとワンラインでのコマンド実行が可能なので、これでユーザスクリプトに組み込むことが可能になります。

oneliner_cmd.png

ちなみにCloudClientは情報参照だけでなく、サービスカタログからの仮想マシン作成やvRealize Automationの設定変更などにも使えます。下記はVMware社が提供しているサンプルスクリプトで、カタログIDとビジネスグループを引数に仮想マシンの作成を行うものです。

create_server.png

このようにvRealize Automationが提供しているAPIやコマンドをうまく活用することで、皆さんの運用環境に合わせた、より高度な自動化の実現が可能です。

 

続きの投稿を読む >

< 前回の投稿を読む

 

こんにちは、仮想化技術およびクラウドソリューション担当の平原です。前回までは、仮想マシンプロビジョニング時のIPアドレス払い出しをNetwork Profileという設定を使用して自動化してみました。ここでお客様から「IPアドレス管理の自動化が可能なことは分かったけど、構成管理の一貫として、IPアドレスの払い出し状況はvRealize Automationの画面を見ることなく管理出来るようにしたい。Network Profileの情報をまとめて取り出す方法はないだろうか」という質問を受けました。このようにvRealize Automationから情報を取り出したり、他のツールからvRealize Automationを制御するためにvRealize AutomationはREST APIが便利です。

 

REST APIとは、それ自体で何か機能が定義されているAPIではなく、分散システムにおいて複数のソフトウェアを連携させるのに適したお作法に基づいたAPIといったものでしょうか。一般的にはパラメータを指定して、特定のURLにHTTPでアクセスすると、XMLまたはJSONで記述されたメッセージが返ってくるようなシステムおよび呼び出しインターフェースのことを指します。これによって、あるリソースを参照(GET)したり、またはリソースの新規作成(POST)、修正(PUT)が可能になります。具体的には、情報を参照、更新したり、何か新しい動作を指示するといった感じですね。

 

ということで、最近の言語にあまり馴染みのない(?)古くさい私は、今回はcurlコマンドを使用して、シンプルにREST APIを叩いてみますが、もちろんJavaやPythonなどで作成したアプリケーションからもREST APIを介して、クラウドそのものをスクリプトベースで運用することも可能となります。


vRealize Automationの場合、まずは認証操作が必要となります。vRealize Automationサーバに対して、API操作を行うHTTP Bearer Token(HTTPベアラトークン)なるものを要求します。返り値の黄色の長たらしい文字列がそのトークンです。このトークンを使うことで、デフォルトで24時間はトークンを要求した利用者でアクセスしているよということを証明することができるのです。関所手形みたいなものですね。

restapi1.png

次にこのトークンを使って、Network Profileの情報を参照します。そうすると、これまたダラダラとシリアルな文字列が返ってくるので、これを適当なコマンドやツールでパーズ(構文解析)してあげれば、自由自在な形で情報を整形して取り出すことが可能になります。今回はjqコマンドで単純整形した出力でお見せします。黄色の部分の"192.168.22.7"に着目しておいてください。

 

restapi2.png

restapi3.png

(省略)

restapi4.png

(省略)

restapi5.png

さて、これを確認の意味でvRealize AutomationのNetwork Profile設定画面から見てみましょう。着目していたIPアドレス"192.168.22.7"が"Allocated"で一致しているのがお分かりいただけるでしょう。REST APIで参照した情報は構造化されたシンプルなテキストなので、ここから必要な情報を抜き出せば、構成管理台帳の元ネタに使用できますし、いわゆるITILで言うところのCMDB(構成管理データベース)があれば、ツール間連携でデータベースにデータを直接インポートすることも容易に可能です。

 

network_profile.png

 

このようにREST APIを活用すると、単なるGUI操作しか出来ないと思われたクラウドサービスも、皆さんが日頃活用している業務フローにうまく組み入れることが出来そうな印象を持っていただけたのではないでしょうか?次回は、VMware社が提供しているvRealize CloudClientというCLIツールを使用して、従来のコマンドライクな形でvRealize Automationからの情報参照などを行ってみたいと思います。

 

続きの投稿を読む >

< 前回の投稿を読む


こんにちは、仮想化技術およびクラウドソリューション担当の平原です。さて、前回の続きです。Reservationに複数のNetwork Profileが紐付く場合の管理はどうなるでしょうか?この図では、リソースプールであるReservation上の3つのVM Networkにそれぞれ異なるNetwork Profileが対応しています。ただ、このままでは、このReservationから仮想マシンをプロビジョニングする時にどのNetwork Profileを参照すべきか判断が付きかねます。適用すべきNetwork ProfileとBlueprintをどのように紐付ければ良いのでしょうか?


reseravation2.png


再度、vRealize Automationの設定相関図をご覧ください。実は前回と微妙に違っています。青い四角のBlueprintに着目すると、Build Profileという項目が増えていないでしょうか?このBuild ProfileとReservationのNetwork Pathを紐付けることで、どのNetwork Profileを適用すれば良いのかが明示的に指定できます。


vra_settings2.png


こちらの図はBuild ProfileがどのようにReservationのNetwork Profileに紐付いているかを表したものです。


build_profile.png


Build Profile "Network-AppSvcs_ITaaS-Applications"の設定を開いてみると、Propertiesの欄に"VirtualMachine.Network0.Name"と"VM Network 2"の対応が記述されています。これは、仮想マシンの最初のネットワークデバイスにネットワーク名”VM Network 2"を指定するという意味になります。これで、Reservationからリソースを払い出すと同時にNetwork Profile "ITaaS-Applications"が適用されるようになります。


では、このBuild ProfileをBlueprintのどこに設定すればいいのでしょうか?Blueprint設定画面のPropertiesタブを参照すると、Build Profilesという欄に先ほど作成したBuild Profileが見えているはずです。このBuild Profileにチェックを入れればOKです。このBlueprintをマスター扱いにして、Blueprint複製~Build Profile設定編集を繰り返せば、利用者が望むネットワークに割り当て可能なサービスカタログを簡単に作成出来るという訳です。


blueprint2.png


ただ、このお客様はVLANの数が1,000を超え、ネットワークセグメントがかなり細分化されているらしいので、そもそもネットワーク体系をどう整理するのかなどの議論も必要でしょうし、このままではこのネットワークプロファイルでの手法を適用するのも運用管理上は大変かもしれません。ということで、VMware NSXの導入と合わせての検討も進められることになりそうです。(このあたりはEnterprise Hybrid Cloudでのマイクロセグメンテーションのユースケースなどで後日説明出来ればと思います)


次回はさらにこの議論から発展して、vRealize Automationが自動的に払い出したIPアドレス管理情報をお客様側でどのように管理するのかを説明いたします。


次の投稿を読む >

< 前回の投稿を読む

 

こんにちは、仮想化技術およびクラウドソリューション担当の平原です。今回はお客様との会話から出てきた、仮想マシンプロビジョニング時のIPアドレス管理について説明いたします。この設定自体は、Enterprise Hybrid CloudのIaaS導入における基本作業に含まれるので、実際にはお客様ご自身でゼロから設定するというシチュエーションはないかと思いますが、そもそもどのような設定を使うのか、運用段階での設定変更などでは知っておいてもムダではないかと思います。

 

このお客様はかなりの数のVLANを構成しており、事業部門ごとに異なるIPアドレスを割り当てる必要があるとのことでした。これをvRealize Automationのカタログとどのように連携させるのかということでご質問をいただいたという訳です。

 

その前にvRealize Automationが持つ設定の相関図をご覧いただきましょう(自分の理解のために作成したものなので一部省略があります)。この図では、黄色の四角がサービスカタログに相当するものですが、このテンプレート的なものとして青い四角のBlueprint(ブループリント)なるものが存在します。

 

vra_settings.png

Blueprintにはさらに複数の設定が紐付いており、仮想マシンスペックの上限設定に加え、仮想マシンをどのリソースプール(Reservation)から払い出すのか、どんなルールで仮想マシンの名前を付与(Machine Prefix)するのか、払い出した仮想マシンがどの組織(Business Group)に紐付くのか、仮想NICにどんなルールでIPアドレスを割り当てる(Network Profile)のかなどによって、利用者が必要とする仮想マシンが形成されます。

 

blueprint.png

 

そして、今回着目すべきはNetwork Profileになります。Network ProfileはExternal, NAT, Private, Routedの4種類のプロファイル選択が可能で、この図ではExternalの設定例を示しています。サブネットマスク、デフォルトゲートウエイ、DNSなどお馴染みの設定がなされていると思います。そして、次のタブには割り当て可能なIPアドレスレンジが指定されています。ここにプールされているIPアドレスのUnallocated(未割り当て)状態のものが、新規仮想マシン作成時に払い出され、固定IPアドレスとして割り当てられます。割り当てられたIPアドレスはAllocated状態に変わり、vRealize Automationの中で自動的に管理されることになります。これまで、Excelシートを使用して手作業でIPアドレス管理をしていた部分が自動化されるイメージです。

 

network_profile.png

 

そして、このNetwork ProfileはリソースプールであるReservationの仮想ネットワークに紐付いています。実行されたサービスカタログは、BlueprintからReservationをたどり、そこに紐付くNetwork ProfileにIPアドレスが割り当てられることになります。

 

reseravation.png

この例では、ReservationとNetwork Profileが1:1で対応している場合ですが、VLANの数が多く、VLANごとにReservationを作成することが現実的でないケースもあると思います。その場合はReservationとNetwork Profileを1:Nで対応させることも可能ですが、では、この場合、ReservationはどのNetwork Profileを使用すればいいのでしょうか?その方法については次回に続けて説明いたします。

 

続きの投稿を読む >

< 前回の投稿を読む


こんにちは、仮想化技術およびクラウドソリューション担当の平原です。前回はEnterprise Hybrid Cloudの導入が2か月で完了するという話でブログを締めくくりましたが、今回はその秘密を説明しましょう。

 

まず、この図をご覧ください。何の図か分かりますか?これはEnterprise Hybrid Cloudが利用するハードウェア、ソフトウェア製品がどのように関係しているかを表した図です。いわゆるインテグレーション作業を検討する上でのポンチ絵です。これだけでも複雑そうなソリューションだというのが何となく分かっていただけるかと思います。

diagram.png

 

では、全てのハードウェアの設置、ソフトウェアのインストールも完了して、とりあえず製品間でやり取りが可能というレベルまで設定を終えたとしましょう。その時点で、サービスポータルとなるvRealize Automationにアクセスするとどうでしょうか?ご覧のとおり画面は真っ白な状態です。

vra_initial.png

 

少々意外だったでしょうか?これはDELL EMCおよびVMware製品に限らず、他社製品にも共通なのですが、この時点ではあくまでも自動化のための基盤を導入しただけなので、実際のクラウドとして機能させるには、各々のお客様ごとに利用者が求めるサービスカタログの設計・作成やサービスカタログ実行のためのワークフロー(自動化の一連の手順を記述したもの)など「仕組み」の開発が必要なのです。これはvRealize Orchestratorのワークフローの一例ですが、このような(しかも膨大な数の)ワークフローを一から作るとなるととても気が遠い話ですね。でも、実際のクラウド実現の道程では、インフラの構築以上にこの仕組み造りの部分が一番大変なのです。

vro_workflow.png

 

そこでDELL EMCは、過去のカスタムプライベートクラウド構築の経験から、一般の利用者にとって最も良く使われるパターンを研究し、事前に共通利用可能なサービスカタログ テンプレートやワークフローを開発、モジュール化するという方法を取ったのです。これによって、お客様の要件に基づいて必要なモジュールを選択し、組み合わせることで個々のお客様に合ったプライベートクラウド環境を必要最小限の工数で提供することが可能になったのです。このモジュールは基本的な仮想マシン作成に加え、データバックアップ、災害対策、継続可用性、暗号化、Oracle導入自動化といったものが用意され、また他社製品との組み合わせではPuppetと連携した構成管理自動化モジュールの提供も可能となっています。

ehc_modules.png

 

もちろん、お客様先で短期間で確実に動くソリューション実現には、モジュールの蓄積だけでなく、

 

  1. ハードウェアを含め、考え得るモジュールの組み合わせパターンに対する動作検証
  2. お客様環境における導入手順標準化(スクリプト活用も含む)とドキュメント化
  3. 不具合修正に伴うパッチ動作の検証
  4. ハードウェアを含む、ファームウェア、ソフトウェアバージョンアップの組み合わせ動作検証
  5. お客様からのフィードバックに基づくユースケースの追加(モジュールの拡張)

 

の継続的な実施に、膨大なエンジニアリングリソースへの投入と投資を行っています。この手法に基づいて提供するソリューションを、我々は「エンジニアード ソリューション」と呼び、DELL EMCのコンバージドインフラストラクチャ製品における考え方をITサービスソリューションを含むレベルにまで適用することで、導入時だけでなくバージョンアップなどのライフサイクルを通して、複雑なソリューションも「一つのもの」として安心して使い続けられるようになっているのです。

 

そして、もう一つの安心はサポート体制です。Enterprise Hybrid CloudはDELL EMCが全ての問題に対する単一の窓口となるので、ハードウェア製品のみならず、他社製品も含めた切り分け、その後のベンダー間のやり取りも含め、責任をもって対応を行います。

single_support.png

 

いかがでしょうか?弊社のエンジニアード ソリューションというものが、いわゆるシステムインテグレーションとも異なる合理的な考えに基づいていることがご理解いただけたでしょうか?私はEnterprise Hybrid Cloudの説明時に良く「(SAPのような)業務パッケージのIaaS版」という言い方をします。日本のお客様は、とかく新しいことの導入に際して、自分たちのこれまでのやり方に合わせようとします。これは一般的な業務パッケージでも、Enterprise Hybrid Cloudでも、フルカスタム対応は可能ではあるのですが、結局のところ高くつくソリューションとなってしまいますし、それでも100%合わせることは至難の業です。そこで我々は、我々自身が培ってきたベストプラクティスに合わせてみることの検討もお話させていただいています。過去のしがらみにとらわれず、新しいやり方を検討することでこれまでの非効率性への気づきがあるかもしれません。Enterprise Hybrid Cloudは単なるテクノロジーの刷新ではなく、IT実務に携わる皆さんやビジネス部門利用者にITの使い方の変革をもたらすDELL EMCのノウハウの集積なのです。

 

次回以降は、Enterprise Hybrid Cloudの中核となるvRealize Automationを中心に、これまでいただいた技術的な質問などに答えていきたいと思います。


続きの投稿を読む >

< 前回の投稿を読む


こんにちは、仮想化技術およびクラウドソリューション担当の平原です。前回はパブリッククラウドに負けない社内ITを!というお題目でEnterprise Hybrid Cloudソリューションの触りを紹介しました。今回はそのEnterprise Hybrid Cloudソリューションの全体像を説明します。まずはEnterprise Hybrid Cloudの全体図です。大きく分けて4つの構成要素からなります。

図1.png


① インフラストラクチャ(ハードウェア)レイヤー

ソリューション展開で最も費やすべきはインフラストラクチャの構築ではありません。従って、インフラストラクチャレイヤーには、事前に工場出荷時点において構成済かつ検証済でお客様先での設置・導入が短期間で完了する、DELL EMCコンバージド・ハイパーコンバージドインフラストラクチャを採用しています。既存の基幹業務向けに最適でCisco UCSサーバ、DELL EMCストレージ製品、vSphereハイパーバイザからなるスケールアップ型のVxBLOCKと、コモディティサーバ(x86ベースの汎用サーバ)上のソフトウェアによってコンピュート、ストレージ機能を提供し、スモールスタートから不定期かつ柔軟でスケールアウトな拡張が可能なVxRACKの選択があります。

ci.png


② ソフトウェアディファインドレイヤー

効率性が重視される仮想化インフラストラクチャは、従来の物理インフラストラクチャと異なり、より粒度の細かいリソースの消費モデルが求められます。このため、共通インフラ配下のハードウェアリソースを抽象化、プール化し、物理ハードウェア単位よりもきめの細かいリソース提供を可能にするソフトウェアディファインド製品、VMware社のvSphereハイパーバイザ、DELL EMCのViPR Controllerソフトウェアディファインド ストレージを採用しています。また、仮想マシンや組織単位にきめの細かいネットワークセキュリティを実現するVMware NSXの組み合わせも可能です。


③ クラウドマネジメントレイヤー

異種混在ハイブリッドクラウド管理のためのクラウド管理プラットフォームである、VMware社のvRealize Suiteを採用しています。vRealize Suiteは以下の製品から構成され、Enterprise Hybrid Cloudにおいても、自動化、運用、ITコストマネジメントといった広範囲な要求実現のために各製品を駆使しています。

  • vRealize Automation:各利用者ごとにカスタマイズされたサービスポータルを提供し、vRealize Orchestratorとの連携によって、仮想マシン作成、アプリケーション展開のみならず、カスタムワークフロー実行のためのセルフサービスでの自動化環境を実現します。

vra.png

 

  • vRealize Operations & vRealize Log Insight:仮想マシン~ストレージまでエンドツーエンドのvSphere環境全体の可視化による異常の検知、キャパシティ管理(レポーティング)や、関連する機器からのログファイルを集約、属性情報に基づく高速検索と複数ログファイル間の相関分析から迅速な障害切り分けを支援します。Enterprise Hybrid Cloudインフラ基盤の日常的な運用業務における重要な運用管理ツールです。

vrops.png

loginsight.png

 

  • vRealize Business Cloud:クラウドサービスの提供にあたって、どれだけのランニングコストがかかっているのか、利用者の消費傾向から仮想マシン単位でのコストを割り出し、サービス価格に反映するための参考情報を計算するなど、ITコストおよびプライシングの透明化を支援します。

vrb.png

 

④ DELL EMCプロフェッショナルサービス

Enterprise Hybrid Cloudの早期立ち上げを支援する、導入支援(コンサルテーション)、導入、運用引き継ぎ(スキル移転)からなるサービスポートフォリオを準備しています。


Enterprise Hybrid Cloudは、DELL EMCのエンジニアリングチームがプライベートクラウドのあるべき姿を模索し、多くのお客様にとって有用なユースケースを提供するためにたどり着いた、最良の製品とテクノロジーの組み合わせからなるソリューションです。そして、驚くべきはこのソリューションの導入完了までの期間です。皆さんのデータセンターにこのEnterprise Hybrid Cloudを導入しようと決めてから、基本的な仮想マシンプロビジョニングが実施出来るまでにどれくらいの期間が必要だと思いますか?1年?1年半?いえいえ、最短約2か月で基本的なクラウドサービスを提供することが出来るようになるのです。普通に考えれば、にわかに信じがたいことですね?多くの皆さんの過去の経験を振り返っても、単純にインフラ構築だけでも、製品選定、設置そして単体・結合試験と、考えただけでも半年で済むものではなかったでしょう。そのうえ、そこにクラウドを構築するとなれば尚更です。


では、次回はなぜEnterprise Hybrid Cloudがこのような短期間で実装を完了出来るのかという秘密に迫ってみましょう。


続きの投稿を読む >

こんにちは、仮想化技術およびクラウドソリューション担当の平原です。今回は、皆さんのデータセンターでプライベートクラウドを容易に実現するDell EMC Enterprise Hybrid Cloudソリューションを紹介いたします。

ところで、皆さんの仮想化インフラ環境では、利用者(事業部門)からの仮想マシンの作成リクエストにどれくらいの日数で対応できているでしょうか?あるお客様の例では、事務処理~仮想マシンのプロビジョニング実作業~事後作業までを考えると、1台の仮想マシンを作成するのに最短でもおよそ15営業日かかっているとのことでした。

図1.png

 

さて、この15営業日、日頃ITの実務に携わる皆さんにとっての感覚はいかがでしょう?「随分とかかってるなぁ...」「いやいや、結構頑張ってる数字じゃない?」など様々でしょうか。ただ、昨今のビジネスは時間との勝負です。他社に先んじてどれだけ魅力的なサービスが展開できるかが生き残りの条件ともいえるこの時代にたった1台の仮想マシンに15営業日...利用者は本当に満足しているでしょうか?実はこのような意識のギャップが、一部のビジネス部門でシャドウITの活用に走らせているケースもあるようです。いわゆるパブリッククラウドサービスの利用です。部門決済(しかもクレジットカード)で簡単にアカウントが作成でき、数十分で必要な仮想マシンが自分で作れるとなれば、利用しない手はないでしょう。しかし、企業ガバナンスという観点で見た場合その選択は正しいのでしょうか?業務データが企業の外に置かれ、そのデータもクラウド事業者がどのようなセキュリティポリシーで保管しているのかも分からないとなれば、一度問題が起きた時、その企業が受けるイメージダウンとビジネス損失は計り知れないでしょう。


では、このような利用者を呼び戻すために社内ITがパブリッククラウドに負けない魅力的な存在になるにはどうしたら良いのでしょうか?その必須要件として以下の3つをあげておきたいと思います。

図2.png

 

そのためにはこれまでインフラ基盤の在り方、事務・作業プロセス、ITスタッフの役割、それぞれに変革が必要となります。そして、これら変革の実現をテクノロジーから支援するのがDell EMC Enterprise Hybrid Cloudなのです。ここに出ている画面。これは新しいITサービスの「顔」とも言えるEnterprise Hybrid Cloudのセルフサービスポータル画面です。

図3.png


利用者はこの画面を通して、利用者が必要とする仮想マシンをいつでも自由に作成することが可能です。(すいません、ここでは検証環境のリソースの関係でチープな仮想マシンです...)

図4.png


もちろん需要に合わせて仮想マシンのCPUやメモリの増減、ディスク容量の追加、サービスが終了して必要がなくなれば仮想マシンをリタイアさせることも自在にできるようになります。

図5.png


まさにパブリッククラウドの利用体験を社内インフラに持ち込み、社内ITサービスをより魅力的なものにすることが可能なのです。


先ほどの15営業日かかると言われていたお客様ですが、Enterprise Hybrid Cloudの導入効果を評価していただいたところ、サービスメニューの複雑さにもよりますが、提供までの時間を10~30分までに劇的に短縮できるとの感触を持っていただきました。今後、ビジネス機会創出とともに仮想マシン作成の回数が増えれば増えるほど、外注業者に支払っていたコストの節約効果は確実に出てくるでしょう。また、ITリソースを共通化し、縦割りシステムに発生していたムダを排除することで、全体量としてはこれまでの6~7割程度にハードウェア購入コストの最適化も期待出来ます。逆に言えば、限られたIT予算の中で新たな投資を実現するには、単に安いものに置き換えるだけではなく、既存ITインフラの運用も含めて極限まで効率化しないといけないのです。


では、次回はそのEnterprise Hybrid Cloudの全体像と特徴を説明したいと思います。


続きの投稿を読む >

 こんにちは、VMwareおよびクラウドソリューション担当の平原です。EMCがVMware製品と連携する様々なソリューションを提供しているのはご存じでしょうか?今回は、その中でも弊社のバックアップ製品との連携を実現するAvamar Plug-in for vCloud Directorをご紹介します。

 

プライベートクラウドに求められるのはマシンプロビジョニングだけ?

 サーバ仮想化技術を活用して、より効率的でスピーディーなインフラを検討するなかで、利用者が求めているのは何でしょうか?迅速な仮想マシンの展開はもちろんですが、データ保護もその一つではないでしょうか?実際、IaaSを提供する基盤を作るまでは何とか出来ても、次のステップとしてどのようにバックアップサービス(BaaS)を実現すれば良いのかは多くのお客様にとって課題のようです。そもそもBaaSを提供するにしても、どのような内容が必要なのでしょう?あるインフラ担当者はストレージハードウェアが持つレプリケーション機能で物理障害に対応する仕組で良いのではと考えていましたが、業務・サービス運用担当者の視点からは上がってきたのは、インフラレベルに加えて、アプリケーションレベルでのデータ保護でした。そうなると、インフラ担当者ではアプリケーションの運用に合わせた臨機応変なバックアップの実施は困難なため、業務・サービス運用担当者にバックアップ機能をサービスとして外出しで提供することが必要となってくるわけです。しかし、この仕組みの構築が難しいというのです。仮想マシン、ストレージを提供する基盤にバックアップの仕組みがきちんと連携していないため、利用者に一貫したサービスレベルでのバックアップメニューが提供できない。もしくはそれをするために、非常に多くのカスタマイズ、開発が必要となるからです。

 そこで、EMCはVMwareの各種管理ツールにプラグインする形で、容易なバックアップ連携を実現する仕組みを提供しています。その一つが今回紹介するAvamar Plug-in for vCloud Directorです。


avamar_plugin_overview_1.png

 

Avamar Plug-in for vCloud Directorとは?

 Avamar Plug-in for vCloud Director(以下、Avamar Plug-in)は、VMware社のクラウドサービス提供基盤であるvCloud Directorと弊社のバックアップ製品であるAvamarとの間で、バックアップ制御の仲介を担うプラグインソフトウェアです。このソフトウェア自体は無償なので、vCloud Directorを利用している既存のAvamarのお客様は、追加コストなしで導入可能です。Avamar Plug-inは、vCloud Directorの組織情報と組織に属するvApp(コンテナ化された仮想マシンのセット)情報を参照します。そして、Avamar Plug-inに設定されている各組織の標準バックアップポリシーをvAppに自動適用します。バックアップポリシー適用後は、ポリシーのスケジュールに応じて定期バックアップが実行されます。この他にも、利用者の要望に応じて、各種サービス重要度に合わせたバックアップポリシーへの変更やインフラ担当者を介することなく、いつでも必要なときに自身の業務のバックアップおよびリストアも可能となります。

 

avamar_plugin_overview_2.png

 

バックアップ、リストアはとても簡単!

 バックアップ、リストア操作はAvamar Plug-inの画面指示に従うだけです。vCloud Directorの管理状態の整合性とも連携が取れているため、複数のツールを使い分ける必要もありません。

 

 バックアップ管理者はAvamar Plug-inの管理画面から、vCloud Directorの組織に対してバックアップポリシーを作成しておきます。ここでは、Goldに日次、Silverに週次、Bronzeに月次のバックアップスケジュールを割り当てています。

avamar_for_vdc1.png


 vCloud Directorの利用者からプロビジョニングされたvApp(この例ではApp-Test)には標準のバックアップポリシーが自動的に設定されます。バックアップ管理者は必要に応じて、バックアップポリシーを変更したり、オンデマンドでバックアップを実行することができます。

avamar_for_vdc2.png


 リストア作業は、バックアップ管理者がリストアしたいvAppのリストアポイントを選択し、元のvAppに上書きでリストアするか、新規にデプロイしたvAppにリストアするかを決定できます。新規vAppのデプロイはAvamar Plug-inとvCloud Director間で完全に連動するので、バックアップ管理者はリストア操作に専念するだけです。また、リストアの単位はvApp全体またはvAppのある特定の仮想マシンのみを選択することも可能です。

avamar_for_vdc3.png

 

 これらの操作はREST APIを使って一般利用者向けの操作画面を開発、公開することもできるため、各vApp(=業務)担当者レベルでのセルフバックアップの仕組みの実現も可能です。


 また、一連の操作の流れはデモ動画にもまとめていますので、実際の操作性をこちらでもご確認ください。


 

この他にもある!EMCバックアップ製品とVMwareの連携ソリューション

 今回紹介したAvamar Plug-in for vCloud Directorの他、EMCはVMware社のvSphere Web ClientやvRealize Automationとの連携ソリューションも提供しており、お客様の導入環境に最適なクラウドレディなバックアップ環境の実現をお手伝いいたします。

 

EMC Avamar Plug-in for vCloud Director (vCD)

  • vCDテナント管理者にバックアップ管理タスクを委譲可能
  • vAppおよび仮想マシンのバックアップ&リストア、ファイル単位のリストアが容易に実行可能

EMC Avamar Plug-in for vSphere Web Client

  • vCenter Server管理者にバックアップ管理タスクを委譲可能
  • 仮想マシンのバックアップ&リストアが容易に実行可能

EMC Avamar Plug-in for vRealize Automation (vRA)

  • vRAテナント管理者および一般利用者にバックアップメニューを公開可能
  • 仮想マシンのバックアップ&リストアが容易に実行可能

Filter Blog

By date:
By tag: