Mirantis-NetScaler White Paper

Transcription

1 ホワイトペーパー 可 性 ADC サービスによるスケーラブルな冗 OpenStack クラウドの構築 マルチゾーン / マルチリージョンクラウド統合の ベストプラクティス

2 ホワイトペーパー Mirantis OpenStack と Citrix NetScaler の活 2 目次 クラスタアーキテクチャーのベストプラクティス... 4 OpenStack コントロールプレーンの 可 性アーキテクチャー... 4 フォルトドメインと OpenStack 可 性ゾーンの対応付け... 5 ホストアグリゲートによる AZ 機能の抽象化... 6 HA 環境 のネットワーキングの検討... 6 負荷分散の検討... 6 ステートフルアプリケーション導入時の検討... 7 Neutron LBaaS による OpenStack 上での クラウドサービスとしての負荷分散... 7 Citrix NetScaler による OpenStack LBaaS... 7 性能および可 性についての一般的検討... 8 マルチデータセンターアーキテクチャーのベストプラクティス... 9 OpenStack の複数の可 性ゾーンへの NetScaler ADC サービスの導入 MOS における Mirantis とシトリックスの統合 まとめ 次のステップ 参考資料... 13

3 ホワイトペーパー Mirantis OpenStack と Citrix NetScaler の活 3 この文書では OpenStack と Citrix NetScaler ADC サービスを利 した大 規模 可 性コンピューティングクラウド構築のベストプラクティスの チェックリストを掲載します 取り上げる話題は以下のとおりです ダウンタイム最小化とデータ漏洩防止 クラウド対応 / ステートレスアプリケーションと状態依存アプリケーションの混在利 同一の共有インフラストラクチャー上での複数テナント (OpenStack プロジェクト ) のホスティング シームレスで 可 性のあるアプリケーションの 速化 / 負荷分散サービス 性能 SLA の順守 複数のロケーションへのクラウドサービスの分散 この文書では 主に次の 2 つの方法論を検討します リソース隔離 ( プール化 ): 可 性ゾーンやホストアグリゲートといった OpenStack の構成要素の適切な活 により フォルトドメインと HA ドメインへのインフラストラクチャーのグループ化を うことによる アプリケーションの導入 保守 問題対処 災害復旧の簡素化と最適化 アプリケーションデリバリー制御 (ADC):Citrix NetScaler テクノロジーを使 することにより 耐障害性のある分散型マルチテナントクラウドアーキテクチャー上で 可 性 / 性能アプリケーションデリバリー / 負荷分散サービスを実現するためのベストプラクティス Mirantis とシトリックスは それぞれが持つ深いエンジニアリング専門知識と大量の顧客実地体験を活かして この複雑な話題空間をカバーするために協業を いました OpenStack の大手専業企業の 1 つであり く評価されている Mirantis OpenStack ディストリビューションの開発元である Mirantis は 現在 OpenStack コア *1 への貢献度が三番目に く 企業 組織 サービス提供事業者向け大規模 OpenStack クラウドを 他のどのインテグレータよりも多数構築しています シトリックスは仮想化クラウドアーキテクチャーへの ADC 導入のパイオニアであり ソフトウェア定義型の大規模ネットワーキング環境について 他に類を ない専門知識を有しています この専門知識を体現したものが サービスの俊敏性と自動化 アプリケーション性能保証のニーズに応える NetScaler App Delivery Controller ソリューションです

4 ホワイトペーパー Mirantis OpenStack と Citrix NetScaler の活 4 クラスタアーキテクチャーのベストプラクティス 計画段階で次の 3 つのベストプラクティスルールを適 すると 対障害弾 性のあるスケーラブルな OpenStack データセンターをより簡単に構築できます 物理リソースを隔離してフォルトドメインを構築し それらを OpenStack 可用性ゾーンにする 原則として 制御 演算 ストレージ ネットワーク機能について 近隣のプールとの共通の障害ポイント ( 電源 基幹ネットワーク接続など ) のない独 したプールを構築し それらを AZ にします OpenStack コントローラーとデータベースコントローラーを 近隣の 3 つ以上のフォルトドメインに分散させて クラスタに対障害弾 性を持たせる 後述の OpenStack コントロールプレーンの 可 性アーキテクチャー を参照してください ネットワーク : 設計時にデータプレーンとコントロールプレーンの両方について スケールアウト性と 可用性の基準を検討する これらの推奨事項を取り入れると 3 つ以上のフォルトドメインから構成される自己完結型の OpenStack クラスタを構築できます これらのフォルトドメインは 管理者やユーザーからは可 性ゾーンとして えます この可視性によって 次に示すように対障害弾 性を備えたアプリケーションの導入がより簡単になります Web アプリケーションのような完全にステートレスなアプリケーションについては 複数の別々の AZ に冗 インスタンスを導入し 負荷分散を適 することで対障害弾 性を持たせることができます ( 負荷分散にも対障害弾 性を持たせることができます 下記参照 ) これにより 1 つのフォルトドメインで障害が発生したとしても アプリケーションがダウンしなくなります クォーラム方式の HA が必要なアプリケーションは OpenStack コントローラーやストレージ (Ceph) コントローラーと同様に 同期メカニズムを持つ 3 つの別々の AZ に導入します 各フォルトドメインの演算 ストレージ ネットワークキャパシティを OpenStack コントローラーのキャパシティまで増強し 該当するフォルトドメインにインフラストラクチャー集約を追加して そのそれぞれに OpenStack コントローラーとストレージコントローラーの新しいコンポーネントを追加すると スケールアウトを うことができます OpenStack コントロールプレーンの 可 性アーキテクチャー Mirantis OpenStack のリファレンスアーキテクチャーでは 次の手法によって OpenStack コントロールプレーンの HA が実現されます 専 コントローラーノードを 3 つ導入します 各コントローラーノード上の OpenStack のステートレスコンポーネント (Nova Cinder Glance) をロードバランサ (Citrix NetScaler など ) の背後に配置し それらをアクティブ / アクティブモードで稼働させます OpenStack のステートフルコンポーネント (L3 ゲートウェイエージェントと DHCP エージェント ) をアクティブ / スタンバイモードで稼働させ ノード障害が発生した場合はペースメーカーによるフェイルオーバーを います クラウド状態データを保持するデータベース (MySQL) を Galera を使 してクラスタとして運 します Galera では多数決クォーラムアルゴリズムに基づいて意思決定が われるため コントローラー障害に対する耐性を持たせるには ノード数を奇数にする必要があります ( ノード数が 3 の場合は 1 つの 5 の場合は 2 つのコントローラーの障害を許容 以下同様 )

5 ホワイトペーパー Mirantis OpenStack と Citrix NetScaler の活 5 OpenStack サービス同士の通信に使 されるメッセージキュー (RabbitMQ) を RabbitMQ のネイティブクラスタリング機能を使 してクラスタ方式で稼働させます VM 起動ディスク イメージ スナップショット ボリューム のストレージを 分散ストレージプラットフォーム (Ceph NetApp EMC VNX など ) を使 して実現します これにより VM のライブマイグレーションとライブエバキュエーションが可能になります (UI または API からの指示が必要 ) Cinder( ボリュームストレージ ) Glance( イメージストレージ ) Swift( オブジェクトストレージ API) として Ceph( 対障害弾 性のあるマルチモーダルデータストレージシステム ) を使 する場合は 単純な冗 性によって Ceph のオブジェクトストレージデーモンコンポーネントが保護され Ceph のモニタコンポーネントには Ceph 自身のクォーラム方式の HA が提供されます そのため 3 つの ( またはそれ以上の数の ) 全ノード間の時刻同期化が必要になります フォルトドメインと OpenStack 可 性ゾーンの対応付け OpenStack の導入を終えると 各ドメインのリソースを OpenStack 可 性ゾーン ( ホストアグリゲートに割り当てられたユーザーから視認できる名前 ) に割り当てることにより フォルトドメインの線引きを うことができます ホストアグリゲート / 可 性ゾーンの定義には Nova クライアント CLI またはそれに相当する REST コールを使 します 以下は (OpenStack Juno における ) コマンドの使 例です 要約すると まず次の CLI コマンドを使 して my_host_aggregate というホストアグリゲートを my_availability_zone という可 性ゾーンとして作成します $ nova aggregate-create my_host_aggregate my_availability_zone 次に ホストアグリゲートとその ID のリストを出 させます $ nova aggregate-list

6 ホワイトペーパー Mirantis OpenStack と Citrix NetScaler の活 6 最後に ホストアグリゲートの ID を使 して 作成した可 性ゾーンにホスト (my_hostname など ) を追加します $ nova aggregate-add-host <ID> my_hostname ホストアグリゲートによる AZ 機能の抽象化 管理者からだけ視認することができる名前のないホストアグリゲートを使 すると さまざまな基準 ( ハイパーバイザータイプなど ) に基づいて各可 性ゾーンをさらに分割することができます それには キーと値のペアをアグリゲートの定義に追加して 必要なレベルの粒度を指定します このキーと値のペアは 利 可能なキャパシティと必要なリソースに応じた ワークロードのさらに適正な割り振りのために ( および不適切なホストにワークロードが導入されようとしたときにエラーをスローするために ) nova-scheduler/filter で使 されます 慎重に扱えば 特定のワークロード群の冗 性の要件に合わせて それを満たす全可 性ゾーンを包含したホストアグリゲートを定義することもできます この手法を使 すると ステートレスアプリケーションを対障害弾 性のある方法で導入することができます そのためには 基本的にアプリケーションのインスタンスを複数の別々の可 性ゾーンに導入するだけですみます 後は ホストアグリゲートから駆動されるフィルタによって アプリケーションの要件に適合するハードウェアが自動的に検出されます HA 環境 のネットワーキングの検討 フォルトドメインからなる OpenStack クラウドのスケールアウト性と冗 性は ネットワークをどのように構成するかによってほぼ決まります 単に L2/L3 ネットワークだけでなく ADC やファイアウォールなどのネットワークサービスについても コントロールプレーンとデータプレーンの両方についての可 性 / スケールアウト性モデルの検討が必要です VLAN 方式のネットワークのような従来のセグメンテーションモデルを使 する場合は VLAN の範囲と それを複数の物理ドメインに延 できるかどうかを検討する必要があります クラウドアーキテクチャー実現のために 中央コントローラーに基づく新しいネットワーキングソリューションを採 する場合は データプレーンのスケーラビリティと性能の検討に加えて これらのコントロールプレーン技術に適したスケーラビリティ / 冗 性モデルを慎重に設計する必要があります 負荷分散の検討 OpenStack クラウドに 可 性を持たせるには 接続と分離に加えて ネットワークサービス ( ロードバランサ ファイアウォールなど ) の可 性 / 冗 性モデルを慎重に検討する必要があります 主に次の要因を考慮する必要があります スケールアウト クラウド設計では ワークロードの増大に合わせて キャパシティを必要に応じて増強できるようにすることが大切です ただし より 性能なデバイスへの交換によってスケールや性能の増強を う通常のエンタープライズ環境と異なり ノードをキャパシティの増強単位とし ノード数を段階的に増やしていくことを推奨します このスケールアウト方式であれば 負荷分散キャパシティとアプリケーション演算キャパシティの両方を同時に増強することができます クラウドアーキテクチャー設計時には 各ベンダーの技術を比較検討し コントロールプレーンとデータプレーンの両方について シームレスなスケールアウトモデルを実現できるかどうかを確認する必要があります 可用性モデル ( アクティブ / アクティブとアクティブ / パッシブ ) ネットワークサービスのほとんどのベンダーは この 2 種類の HA 方式のどちらか一方 または場合によっては両方をサポートしています 標準的なエンタープライズ環境ではアクティブ / パッシブ HA モデルが非常に

7 ホワイトペーパー Mirantis OpenStack と Citrix NetScaler の活 7 よく使われますが 典型的なクラウドアーキテクチャーにはアクティブ / アクティブモデルの方が適しています その理由は クラウド設計の基本になるのはスケールアウトアーキテクチャーであるため 各ノードが他のノードに N+1 冗 性を提供しながら 要求をアクティブに処理したほうがよいからです ステートフルアプリケーション導入時の検討 HA の計画時には アプリケーションの性質そのものについての検討も必要です クラウド に設計された新しいアプリケーションは一般にステートレスであり 障害発生ノードを修復する代わりに 新ノードへの交換を うという思想に基づいて 障害が発生してもよいように構築されています この疎結合アーキテクチャーはオンデマンドキャパシティのクラウドモデルに大変よく適合しますが 複数ノード間での状態共有を前提にした従来型のアプリケーションもあります ADC の観点から各ベンダーの技術を評価し その ADC ソリューションのスケールアウト機能が 複数ノード間でのアプリケーション状態の同期と共有をサポートしているかどうかを確認する必要があります Neutron LBaaS による OpenStack 上での クラウドサービスとしての負荷分散 Neutron は OpenStack の NaaS(Network-as-a-Service) 層であり Neutron には 度な LBaaS (Load-Balancing-as-a-Service) サービスがあります Neutron LBaaS を利 すると 負荷分散の as a service 消費モデルを実現し 消費 API セットを介して 特定のベンダーの技術に依存しない負荷分散ポリシーを導入することができます 負荷分散アプライアンスの管理に関係するインフラストラクチャーの複雑さからの抽象化も可能になります Neutron LBaaS では 商 およびオープンソースの負荷分散技術を利 して要求の負荷分散を うことができるため 使 するバックエンド技術に柔軟な選択肢が生まれます LBaaS は現在は Neutron の一部ですが ネットワーキング分野の独 した OpenStack プロジェクトにする計画が進 中です Citrix NetScaler による OpenStack LBaaS 多くの事例では 複数のデータセンターを別々の地域に分散させます このような事例で 複数のデータセンター全体にわたるリソースの利 を最適化するには 広域トラフィック分散 / 負荷分散メカニズムが必要です そのため すべての ADC ベンダーが何らかの形の広域サーバー負荷分散 (DNS に基づいてトラフィックを広域的に分配するメカニズム ) を提供しています ただし 各ベンダーの製品の比較検討を い ユーザープロキシミティ ジオロケーション 利 可能キャパシティ 重み付けといった主要な仕様の洗練性を確認する必要があります NetScaler の OpenStack LBaaS 統合機能は 基幹業務アプリケーションを大規模運 している組織のためのソリューションとして開発されています IaaS(Infrastructure-as-a-Service) 実 にまつわる運 上の問題を解決すると同時に 性能 可 性 スケールの制御と柔軟性を実現できます NetScaler の OpenStack LBaaS ソリューションは NCC(NetScaler Control Center) と呼ばれる専 のオーケストレーション製品をベースにしています この製品によって OpenStack への LBaaS 導入に伴う運 上の複雑さが軽減され 全 NetScaler 物理 / 仮想アプライアンスのシームレスな統合が可能になります

8 ホワイトペーパー Mirantis OpenStack と Citrix NetScaler の活 8 図 2. OpenStack の LBaaS プラグイン ドライバによる Citrix NetScaler と OpenStack の統合 Horizon webui または OpenStack Neutron クライアントおよび REST API から アプリケーションレベルの負荷分散をシームレスに制御することができます NCC(NetScaler Control Center) には NetScaler の付加価値 ADC 機能 クラウド消費モデルの実現を可能にする次の機能があります そのため NetScaler のあらゆる ADC 機能やセキュリティ機能をクラウドサービスとして容易に提供できます NetScaler インフラストラクチャー全体にわたるキャパシティのプール化 全 NetScaler アプライアンスの総合的自動化 サービスに応じたリソース割り当てによる SLA 保証 OpenStack KeyStone との統合によるシングルサインオン認証 ADC ポリシーの柔軟な配置アルゴリズム 運 情報の中央からの可視化とレポーティング 性能および可 性についての一般的検討 物理 / 仮想アプライアンスの選択 NetScaler には 物理アプライアンスから 仮想アプライアンス そして特定 途向けマルチテナントアプライアンスまで Neutron LBaaS の能 を める多彩なプラットフォームの選択肢があります テナントに対する LBaas 機能はそのままに 純粋に性能 スケーラビリティ コストのみに基づいて 使 するプラットフォームを自由に選択できます 専 ハードウェアの い対障害弾 性と信頼性が必要であれば物理アプライアンスを選択することができ ソフトウェア定義型のデータセンターモデルの方が望ましいのであれば仮想フォームファクタを採 することができます マルチテナント分離のベストプラクティス 共有インフラストラクチャーを使 すると クラウドの規模の経済性の礎を築くことができますが 分離性とセキュリティを犠牲にすることなく 同じ共有インフラストラクチャー上で複数のテナントをホスティングするにはどうすればよいかという問題に対する適切な対処が必要になります NetScaler の Neutron LBaaS ソリューションには 次のようなマルチテナント分離方式の多彩な選択肢があります 完全専用インスタンスによる最 の分離性と独 性 基幹業務ワークロード に設計されたこの分離モデルでは CPU メモリ スループット SSL 処理能 などの重要リソースについての テナントごとのきめ細かなハードウォール化を うことができ 最

9 ホワイトペーパー Mirantis OpenStack と Citrix NetScaler の活 9 レベルの分離度を実現できます 共有インスタンス 共有インスタンスはテスト / 開発ワークロードに最適です 1 つのインスタンスで複数のテナントの ADC ワークロードのホスティングを うことにより コスト効率の いベストエフォート型のマルチテナントソリューションを実現できます 区画に基づく 密度マルチテナント性 専 インスタンスの分離度と共有インスタンスのキャパシティ効率の好いとこ取りを狙うには NetScaler の管理区画に基づくマルチテナント性を使 します 密度を実現しつつ スループット 接続 メモリのような特定の重要パラメータのハードウォール化を うことができます スケーラビリティ / キャパシティのオンデマンド性 NetScaler の先進の TriScale テクノロジーを利 すると 次のようなさまざまなスケーラビリティ方式によって キャパシティを必要に応じて増強することができます スケールアップ NetScaler では 全アプライアンスで pay-grow ライセンスモデルがサポートされます 該当するライセンスを適 するだけで どのデバイスでもキャパシティ制限を解除することができます スケールアウト NetScaler の TriScale クラスタリングテクノロジーでは 最大 32 の別々のノードを単一の論理 NetScaler 装置としてクラスタ化し 運 / 構成データのシームレスな同期化を うことができます マルチデータセンターアーキテクチャーのベストプラクティス 前述のように Mirantis では OpenStack のネイティブ隔離メカニズムを使 して 次に示す複数の独 した OpenStack システムからなるマルチサイトクラウドの構築を います リージョン 地理的に分散した複数のデータセンターの UI と認証の共有に使 します 可用性ゾーン 1 つのデータセンター ( 単一のラック 電源 サーバールーム ) の中のフォルトドメインの分離に使 します ホストアグリゲート ユーザーが定めた任意の特性 ( 直接接続 SSD ストレージを使 できるかどうか サーバーのモデルなど ) に基づいて演算ノードをグループ化するために使 します リージョン 1 リージョン N API エンドポイント Horizon (Web UI) API エンドポイント Keystone コントローラー 1 コントローラー 2 コントローラー 3 コントローラー 1 コントローラー 2 コントローラー 3 可用性ゾーン 1 可用性ゾーン N 可用性ゾーン 1 可用性ゾーン N 演算 1 演算 3 演算 1 演算 3 演算 2 演算 N 演算 2 演算 N 分散ストレージ (Ceph Swift NetApp EMC) 非同期レプリケーショ 分散ストレージ (Ceph Swift NetApp EMC) 図 3. ADC を使 しない従来型構成のマルチリージョンクラウド 各リージョンの中にあるコントローラーは

10 ホワイトペーパー Mirantis OpenStack と Citrix NetScaler の活 10 HA 構成です 演算ノードは複数のフォルトドメインを包含した AZ の中で隔離されます ストレージには 可 性があります OpenStack の複数の可 性ゾーンへの NetScaler ADC サービスの導入 一般的ベストプラクティス NetScaler には OpenStack の複数の可 性ゾーンに ADC サービスを導入するためのソリューションが複数あります これらのソリューションを評価する際には 次のベストプラクティスを念頭に置く必要があります アプリケーションの可 性モデルに合わせて アプリケーションとともに ADC サービスの弾 的なスケーリングを う必要があります したがって 可 性ゾーンごとに NetScaler インスタンス ( またはインスタンスペア ) を 1 つずつ導入し 負荷分散を うと 演算リソースだけでなく アプリケーション の ADC サービスについても 障害分離性と障害からの保護を実現できます それぞれのフォルトドメインは 障害が発生しても他に影響を与えない自己完結型のユニットであるため ADC サービスにもそういった性質を持たせる必要があります すなわち 一般的なベストプラクティスでは それぞれの NetScaler に その NetScaler と同じ AZ 上のローカル演算ファームへのトラフィック負荷分散を わせます このようにすると あるフォルトドメインの NetScaler インスタンスで障害が発生したとしても 他のフォルトドメインに影響が及ぶことはなく AZ 間のトラフィック転送のオーパーヘッドも防ぐことができます 複数の AZ 上の NetScaler インスタンスは なるべく疎結合にします そうすれば AZ 間の相互作 と状態情報交換を最小限に抑えることができ クラウドアーキテクチャーにとって理想的です AZ 間の状態の同期が必要な ステートフル性が極めて いアプリケーションに対しては 例外を設けることができます

11 ホワイトペーパー Mirantis OpenStack と Citrix NetScaler の活 11 凡例 : 制御データ 図 4. 各リージョンに NetScaler ADC を導入した 可 性構成のマルチリージョン OpenStack クラウド 複数の AZ やデータセンターの NetScaler 間で負荷分散を うための導入の検討 前述のように 一般的なベストプラクティスでは AZ ごとにそれぞれ 1 つの NetScaler インスタンス ( または 1 つの NetScaler HA ペア ) を導入し それと同じ AZ 上のローカルコンピュータリソースへのトラフィック負荷分散を わせます それでは AZ 間でコントロールプレーンとデータプレーンの負荷分散を うには どうすればよいのでしょう AZ 間での NetScaler データプレーンの分散 : データプレーンのトラフィック分散には トラフィック分散を担当する外部機器 ( 上流のルータやスイッチなど ) が必要です ECMP と RHI の併用 : ECMP(Equal Cost Multi Path) は どのルータでもサポートされているレイヤ 3 レベルの一般的なトラフィック分散メカニズムです 通常は 上流のルーティング層 ( データセンターコアルータなど ) に ECMP を使 させて 複数の可 性ゾーンの NetScaler へのトラフィック分散を わせます ECMP はフロー安全性のあるステートレスなハッシュメカニズムに基づいているため 同じフローのトラフィックは常に同じ NetScaler に扱わせることができます RHI(Route Health Injection) は OSPF のような動的ルーティングプロトコルによって NetScaler からインスタンス上のサービスの可 性をアドバタイズするために使 されるメカニズムです RHI では NetScaler から OSPF に対して インスタンス上で稼働し

12 ホワイトペーパー Mirantis OpenStack と Citrix NetScaler の活 12 ている健康な全サービスのルート注入を います サービスが 不健康 になったり ダウンしたりすると そのルートがアドバタイズの対象から自動的に取り除かれ 上流のルータはその NetScaler インスタンスの該当するサービスにトラフィックを渡さなくなります ECMP と RHI の併 は 複数の可 性ゾーンへの NetScaler のスケールアウトアーキテクチャーの選択肢として 非常によく使われます GSLB によるマルチ DC: 複数のデータセンター ( およびおそらくは複数の地域 ) にまたがる環境で データセンター間のトラフィック分散を うには NetScaler の GSLB( 広域負荷分散 ) ソリューションが最適です ただし データセンターの中に複数の可 性ゾーンが存在する場合があるため この場合も ECMP と RHI の併 が 可 性ゾーン間の負荷分散のための効果的なソリューションとなります TriScale クラスタリングによるステートフルアプリケーションのスケールアウト : アプリケーションの中には 持続性を持たせなければならず 別々の可 性ゾーン上のノード間でのユーザーセッション状態の共有と保持が必要なものもあります これらのアプリケーションについては TriScale クラスタリングを使 すると AZ 間での均等な負荷分散が可能な 完全にステートフルで運 効率の いスケールアウトソリューションを実現できます AZ 間での NetScaler コントロールプレーンの分散 : OpenStack 環境では NCC(NetScaler Control Center) が NetScaler アプライアンスの中央コントロールプレーンの役割を担います OpenStack クラウドアーキテクチャーの設計時には NCC のスケーラビリティ / 可 性モデルについての慎重な検討が必要です 一般的なベストプラクティスとしては NCC インスタンスと OpenStack コントローラーノードを 1 対 1 に対応させます 単一リージョンにおける HA 構成の NCC の導入 : 複数の NCC を導入し それらを 可 性構成にすることにより リージョン 1 つにつき 1 つの論理的コントロールプレーンを構築できます HA クラスタ構成の OpenStack コントローラーによる複数の AZ 上のリソース管理と同様に この HA 構成のコントロールプレーンから 同一リージョンの複数の AZ 上で稼働している全 NetScaler インスタンスにアクセスすることができます マルチリージョンの検討 : 一般にマルチリージョンアーキテクチャーでは リージョンごと または地理的に分散したデータセンターごとに 完全に別々の OpenStack 環境を構築します NetScaler ADC サービスにとっては このことはそれぞれ別々の NCC が それと同じリージョン上の NetScaler アプライアンスの管理と制御を うことに相当します MOS における Mirantis とシトリックスの統合 Mirantis OpenStack には Fuel と呼ばれるウィザード方式のインストーラがあり 可 性 OpenStack クラスタ ( および必要に応じて Ceph 機能 ) を簡単に導入できます ウィザードに従って設定を うだけで HA 性を備え Ceph 機能を持つ OpenStack を自動的に導入することができます PoC やテスト としては Fuel を使 することによって HA コンポーネントと Ceph コンポーネントを単一のコントローラーノードに導入し ( ただし その場合は HA は完全には機能しません ) クラスタにそれとは別のコントローラーを追加できます ( コントローラー 3 つ以上で HA が有効になります ) Mirantis OpenStack と Fuel の詳細については Mirantis OpenStack のプランニングガイドおよびユーザーガイドを参照してください

13 ホワイトペーパー Mirantis OpenStack と Citrix NetScaler の活 13 NetScaler ADC( 物理 / 仮想の全プラットフォーム ) には Mirantis OpenStack との相互運 性があり この相互運 性は Mirantis による認定を受けています Mirantis のエンジニアたちによって検証 / 作成された MOS への NetScaler の統合についてのランブック ( 手順書 ) があります NetScaler を利 する Mirantis OpenStack ユーザーに対する L1/L2 レベルのサポートは Mirantis から提供されます また L3 レベルの問題はシトリックスのエンジニアに渡され サポートが われます まとめ Citrix NetScaler ADC は OpenStack クラウドの運 管理 性能 対障害弾 性に多大なメリットをもたらします 特に クラウドが大規模になったり 複数のリージョンへの展開が われたり 各データセンターのマルチテナント需要の多様性が増すほど このメリットは大きくなります この文書で述べたように NetScaler の全体アーキテクチャーと HA 方式は 対障害弾 性を備えたスケールアウトクラウドを構築するための OpenStack の実績のあるベストプラクティスにぴったりと調和します 次のステップ Citrix NetScaler ADC ソリューションと Mirantis OpenStack について さらに詳しいことをお知りになりたい方は まず 上のシトリックスとのパートナーシップについてのホームページをご覧ください 最新の Mirantis OpenStack ディストリビューションは から無償でダウンロードすることができます 30 間の無料サポート権が付属しているため 評価実装や PoC 実装にうってつけです Mirantis は Citrix NetScaler ADC を利 した OpenStack クラウドの評価 / 実装プランの検討サービスを っています サポートのためにさまざまな専門サービスが提供されており たとえば ADA ( アーキテクチャー設計評価 ) サービスでは Mirantis のクラウドアーキテクトの知識とノウハウを自在に吸収し 助言や指示を受けることができます ADA サービスの利 登録は から うことができます 参考資料 Mirantis OpenStack のマニュアル (6.0) Mirantis のリファレンスアーキテクチャー (HA Neutron ネットワーク Ceph) Mirantis の BoM カルキュレータ OpenStack コミュニティの文書 OpenStack アーキテクチャー設計ガイド OpenStack のスケーリング

14 ホワイトペーパー Maximizing Multi-tenancy with Citrix NetScaler 14 Citrix について Citrix(NASDAQ:CTXS) は 企業と人々の新しい働き方を実現するソフトウェア定義型のワークプレース 仮想化統合 モビリティ管理 ネットワーキング SaaS ソリューションのリーディングカンパニーです シトリックスのソリューションは あらゆるデバイス あらゆるネットワーク あらゆるクラウドからのアプリケーション デスクトップ データ コミュニケーションの迅速な利 を可能にする安全なモバイルワークプレースを実現し ビジネスにモビリティをもたらします シトリックスの 2014 年度の年間売上 は 31.4 億ドルで そのソリューションは世界中の 33 万以上の企業や組織において 1 億人以上の人々に利 されています シトリックスの詳細については をご覧ください 2015 Citrix Systems, Inc. All rights reserved. Citrix NetScaler NetScaler App Delivery Controller および TriScale は Citrix Systems, Inc. またはその子会社の登録商標であり 米国の特許商標局およびその他の国に登録されています その他の商標や登録商標はそれぞれの各社が所有権を有するものです Mirantis について ミランティスは OpenStack の大手専業会社であり く評価されている Mirantis OpenStack ディストリビューションの開発元です 現在 OpenStack コアプロジェクトへの貢献度が三番目に く 企業およびサービス提供事業者向け大規模 OpenStack クラウドを 他のどのベンダーよりも多数構築しています Mirantis OpenStack には 機能な事前構成 導入ツール (Fuel) が搭載されているため HA( 可 性 ) 構成の堅牢な OpenStack クラウドをほぼ自動的に構築できます ミランティスは OpenStack ファウンデーションの創設メンバーの一つでもあります 2015 ミランティスおよびミランティスのロゴマークは米国およびその他諸国におけるミランティスの登録商標です その他の商標はそれぞれの各社が所有権を有するものです E0515/PDF J0615/PDF