Comments
Description
Transcript
Mirantis_CiscoWebex-case
Cisco WebEx OpenStack 導入事例 ビジネス・ニーズ 設計目標 Web会議とサービス型ソフトウェア （SaaS） モデル両方のディスラ 長年、様々のオープンソースの取り組みに参加してきたCiscoは、 プティブなパイオニアであるCisco Webexは、IT業務インフラ構 標準化されたオープンソース・ソフトウェアでインフラ運用を統合 築面で絶えず刷新を行うことが必要となっている。 ミッションクリ する潜在的可能性を認識していた。 しかしこれは、 グリーンフィー ティカルなインフラは、 ボイスミーティングの活発な提供だけに限 ルド （未開発領域） へのデプロイメントではなかった。OpenStack らない。分析、 コンテンツ/記録保存、 システム管理、新製品研究開 OpenSource Cloudが、 その柔軟性と透明性ゆえに最適のテクノ 発のためのツーリングといった主要な支援アプリケーションも含 ロジーとして浮上した。OpenStackへの移行は、経常コストの引 まれる。 こうした補完的なアプリケーションはクラウド主導のアジ き下げや、 インフラとソフトウェア・レイヤーの間のロードマップ整 リティ （俊敏性） とコスト節減を共に必要とする。 合性の改善といった、商業面・運用面両方でメリットをもたらす可 能性を秘めていた。 Cisco WebEx業務設計者であるReinhardt Quelleは、 「WebEx はビジネスに不可欠なサービスであり、当社はそれを決して休止 世界規模のユーザー人口、高トラフィック、 および市場トップの地 させない。顧客は、土曜の午前3時にWebEx会議を始めることも 位を有するWebExサービスの高い注目度から言って、 その根底に ありうる。WebExに休止時間が予定されることは、決してない」 と あるインフラ・レイヤーは、可用性の高い、 きわめて堅牢なもので 語る。 なければならなかった。業務プロセスやその他のインフラ・サービ スにわたる複雑な依存は、 プロジェクトに一層の複雑さをもたら 2011年の末頃までにCisco WebExはこうした補完的アプリケー した。 ションの実行について、一群の相容れないクラウドおよび仮想化 ソリューションに直面していた。各アプリケーション自体は一緒に 移行の第1段階として、Ciscoは、 イメージのストレージ、 ログ処理 うまく機能したが、 その根底にあるプラットフォームの細分化は、 面、製品開発面等のミッションクリティカルな補完的サービスを、 アプリケーションのプロビジョニング、環境設定、 デプロイメント、 新しい標準化されたOpenStackクラウド・プラットフォームへと 運用に関して一貫した慣行を活用することを困難にした。 移行した。 プロジェクトが時間通り、予算内で成功裏に完了するこ とを保証するため、Ciscoは、 こうした要件を満たしうるOpen- Amazon (AWS) EC2やVMwareといったクラウドおよび／また Stack参照アーキテクチャー一式の開発と実装をミランティスに は仮想化のために使用されているプロプライエタリーな商用技術 頼った。世界最大のOpenStackクラウドシステム専門インテグレ は、種々のインフラ構成要素にわたって、 ライセンシング・コストと ーターであるミランティスは、 プロジェクトの計画と実行のため、 利用コストが入り混じったコストを積み重ねていた。しかも、 エンジニアとアーキテクトを大挙動員した。何十例ものOpen- WebExサービスは、音声、映像、画面共用、協働等の複雑な事柄 Stackデプロイメント実績を持つミランティスは、Ciscoの設計目 の実現のために、 きわめて特化したITサービスを利用する。 これは 標を業務インフラ自動化へと具体化させるのにうってつけだった。 パブリッククラウドには容易に適合しないサービスだ。 Quelleは、 「当社は、多重相互接続を有する世界中の20近いロケ ーションで業務を行っている。 それらがパブリッククラウドで機能 するのは無理な相談だ」 という。 ©2016 Cisco Webex, Inc. and Mirantis, Inc. 技術目標 細部が重要であるため、特定のオペレーティングシステム、 ホスト WebExとミランティスは、OpenStackへのプロダクション・クラウ ドの移行に関して下記の目標を定めた。 • CiscoのUCSサーバー・プラットフォームに基づく、何千もの CPUコアと何ペタバイトものストレージを有する大規模プライ ベートクラウド • コアWebEx会議サービスをサポートする、IDサービスSplunk によるデータ分析といった主要インフラ・アプリケーションとの 統合 構成、 ネットワーキング／ストレージ／ 監視／ロギング・ツールに またがる込み入った依存を明らかにするマニフェストが書かれて きた。 これらはすべて、デプロイメント・スキーマに統合され、世界 各地の複数のデータセンターにわたる数百のノードで大規模にテ ストされた。 HAアーキテクチャー EssexFinalリリースに沿って標準化された、WebEx OpenStack • 一般的なオープンソース・コンポーネントを用いて実装される、 すべてのOpenStackコンポーネントの高可用性 （HA） サポート クラウド・アーキテクチャーは、OpenStack Compute(Nova)と • OpenStackクラウドインフラの継続的管理のための Puppetマ ニフェストを用いた自動プロビジョニング・フレームワーク ポーネントを高可用性にする必要があった。 • マルチデータセンター・サポートを含む、Swiftを用いたオブジェ クトストレージ・サービス 具体的には、 デプロイメント・トポロジーは、HAプロキシ・ロードバ • 業務のアジリティを推進するとともに、新しいアプリケーション や機能の実装を効率化する、完全にプログラマブルで伸縮自在 なマルチテナンシー・インフラを立ち上げるための方法論 OpenStack ObjectStorage(Swift)サービスを含んでいる。 この アーキテクチャーでは、OpenStackクラウドのステートフル・コン ランサーが前段に置かれた、 アクティブ・アクティブ構成のコント ローラーノードHAペアを含んでいた。 コントローラーノードのす べてのインスタンスについて静的仮想エンドポイントを提供する ためKeepaliveDが使用された。 • 複数のグローバルなロケーション間でのサービスディストリビ ューションのサポート 実装面のハイライト デプロイメント自動化 プログラマブル・インフラの中核的能力は、 クラウドの構成モジュ ールの自動環境設定であり、 これにより、 ソフトウェア・モジュール とサービスを、 その根底にあるハードウェアと結合させるという、具 体的なサービス・レベル目標に対応できる。 こうしたモジュールは MySQLデータベース・インスタンスは、HAモードで設定された 本質的に、種々のアプリケーションやワークロード増大に対応する Mu l t i - M a s t e rレプリケーション・マネージャー（ M M M ）と ためのコンピュート、 およびストレージのプロビジョニングにおい RabbitMQを用いてレプリケーションされた。 て、あるいは、長期にわたりアプリケーション要件に繰り返し応え るなかで、絶えず変化する。 中核的なOpenStackサービスの持ち前の能力を、継続的統合と継 続的デプロイメントをサポートする十分な柔軟性を備えた環境へ とつなげるため、 ミランティスは、業務サイクル全体を通じオンデマ ンドでOpenStackコンピュートおよびストレージ・サービスをプロ ビジョニングするためのPuppetマニフェスト群一式を書いてデプ ロイした。 ©2016 Cisco Webex, Inc. and Mirantis, Inc. Novaボリュームのためのカスタム・スケジューラー マルチデータセンター・オブジェクトストレージ ミランティスによって設定されたもう一つの重要な能力は、Nova- Swiftストレージの中核的能力は、分散型環境での実行可能性に Computeのためのボリューム・サービスだった。OpenStackでの ある。局所性は、 パーティションへのデータの割り当てを決定する ボリューム・ストレージのデフォルトの実装はロケーション独立的 リングと呼ばれる分散ハッシュテーブルによって維持される。集中 であり、VM（仮想マシン） に、 そのラック外の、数ネットワーク・ホッ 型環境では、 自動リング再構築を管理することができるが、 ミラン プ離れたボリュームリソースを、 あるいは地球の裏側にあるボリュ ティスは 、クラスター 内 の すべ ての ストレ ー ジノード 上 で 、 ームリソースすらも割り当てる可能性を生み出すが、 それは、パフ ringrebuildコマンドを同時に呼び出す機能を作成し、データ・ア ォーマンスの低下を招き得る。 ミランティスは、永続的なボリュー ドレス可能性の維持を確保した。 ムがローカルVMに結び付けられるよう、 カスタムのボリューム／ ストレージ・アフィニティ・スケジューラーを作成した。 おかげで、 WebEx OpenStack クラウドは、全世界に分散した複数のデータ クラウドに基づいて事を進めるアプリケーション開発者は、 この潜 センターにわたって実行されるため、 ミランティスはデータストア 在的な問題に悩まされずにすむ。 ボリューム・デフォルトへのこの の特定の地理的ロケーションを特徴づけるため、Essexリリースに 変更は、OpenStackの将来のリリースに盛り込むことが提案され おけるSwiftのギャップに対処しなければならなかった。 これは、 ロ ている。 ケーション・コンテクストを変換するため世界中のデータセンター ラージオブジェクトのためのSwift ン値のテーブルである 「リングのリング」 （ ring of rings ） を構築す OpenStackのオブジェクトストレージ・サービスであるSwiftは ることによって達成された。 これにより、 キャッシュされたオブジェ オブジェクトの構造とは無関係にオブジェクトを保存する強力か クトがローカルだった場合、 リモートだった場合をそれぞれのノー つ融通性のあるアーキテクチャーを提供し全世界に分散したクラ ドにおけるコンピュートサービスが明確に特定し、適宜のアクショ ウドインフラにわたって、最小限の待ち時間でオブジェクトを容易 ンをとることが保証される （例えば、オブジェクトのロケーション にアクセス可能にする。 この能力は、WebExOpenStack クラウド 特性に基づいてパフォーマンスを改善するため、 レプリケーション や、種々のサイズやフットプリントにわたる、保存されたオブジェク をトリガーする等）。 にわたって横並びでレプリケーションされるストレージロケーショ ト・タイプの多様性にとりわけ理想的だった。 Swiftサービスのもう一つの重要な強化は、 レプリケーションの暗 ミランティスはOpen Swift Object Storageサービスを、Apache 号化を可能にすることだった。デフォルトでは、 レプリケーション Jcloud（Javaプラットフォームで動作するAPI/ライブラリ） を通し が単一のセキュリティーゾーン内で行われるという素朴な仮定の てアプリケーション開発者がアドレス可能なマルチパートアップロ 下、Swiftはノード間のオブジェクトをプレーンテキストでレプリケ ーダーによって強化しOpenStackクラウドで実行されるアプリケ ーションする。 しかし、分散型アプリケーションのグローバルな性 ーション用のストレージ・サービスの実装プロセスを簡易化した。 格、 ならびに、様々の保存されたオブジェクトの多種多様な用途ゆ えに、 より粒度の細かいセキュリティモデルが必要とされた。 ただ OpenStack Essex のリリースでは、Swiftでキャッシュされるイ しそれは、 グローバル・レプリケーションと両立しうるものでなけ メージの最大サイズは5GBであるが、 ミランティスは、Swiftサー ればならなかった。 ビスの利用者がより大きなファイルを必要サイズまで分割（チャン ク化） できるようにするクライアントコードを作成した。 したがって Swiftは様々のクライアント・アプリケーションに透明性がある （見 える）形で、 それらをキャッシュして、 オンデマンドで再構築しうる。 ©2016 Cisco Webex, Inc. and Mirantis, Inc. 継続的なテストと検証 OpenStackクラウド環境の主要なリスク目標は、故障に際しての 耐障害性である。いかなる環境も、 ワークロードの実行に直接影 響する未知の不具合による劣化を未然に防ぐための大規模かつ 継続的なテストや常時稼働する包括的プログラムがなければ、継 続的な耐障害性の実現は期待できない。OpenStackコミュニティ は、Essexリリースにおいて、完全にデプロイされたOpenStack環 境に対して実行することが意図された、包括的な機能をもつソフト ウェアパッケージかつシステムテストを行うTempestプロジェク トを立ち上げた。 ミランティスは、継続的な WebEX OpenStack クラウドの設定の検証を実行するテスト用ソフトウェアとして、 Tempestを実装した。Ciscoはこれを、 プロジェクト期間中、各ス コープ・マイルストーンでの大規模な継続的ブラックボックス検証 を実行するために使用し、規定された運用範囲内で環境が適切に 稼動し続けることを保証した。 さらに、WebEx設計目標に対し特 有のこのテストスイートのため、2つの重要な強化がなされた。 第一に、 ミランティスは、再起動時にサービスが適正な応答シグナ ルを提供することを検証するため、HAサービスのフェイルオーバ ーレスポンスを演習するブラックボックステストを追加した。第二 に、 ミランティスは、Puppetプロビジョニング自動化マニフェスト のホワイトボックステストを自動化する機能を、作成した。従来の ブラックボックステストは、 マニフェスト適用後の最終状態を検証 する。 しかしこれは、 マニフェスト適用の中間段階に生み出される 依存性がデプロイメントにおける異常を覆い隠すおそれを残す。 これに対処するため、 ミランティスは、中間の設定状態を確認する ことにより、最終状態だけではなく各ステップを検証するPython スクリプトを実行し、各々の自動化された設定ステップとデプロイ メント・プロセスの各ステップの適切さを確認するホワイトボック ス設定検証シーケンスを開発した。 ©2016 Cisco Webex, Inc. and Mirantis, Inc.