PureApplication 1 IBM PureApplication サマー・スクール 第２部 プランニング編：PureApplication Systemによるクラウド基盤の設計と構築
by user
Comments
Transcript
PureApplication 1 IBM PureApplication サマー・スクール 第２部 プランニング編：PureApplication Systemによるクラウド基盤の設計と構築
IBM PureApplication サマー・スクール 第２部 プランニング編：PureApplication Systemによるクラウド基盤の設計と構築 PureApplicationによるクラウド基盤の設計 © 2013 IBM Corporation 1 Disclaimer この資料は日本アイ・ビー・エム株式会社ならびに日本アイ・ビー・エム システムズ・エ ンジニアリング株式会社の正式なレビューを受けておりません。 当資料は、資料内で説明されている製品の仕様を保証するものではありません。 資料の内容には正確を期するよう注意しておりますが、この資料の内容は2013年07 月現在の情報であり、製品の新しいリリース、修正などによって動作／仕様が変わる 可能性があるのでご注意下さい。 PureApplication Summer School 2 © 2013 IBM Corporation 2 当セッションの目的 3 当セッションでは、IBM PureApplication Systemによるクラウド基盤（パ ターンがデプロイされて動作するための環境）を構築するにあたって、一般 に設計・検討すべき事項を示します クラウド・グループやIPグループといったPureApplication特有の機能・概念 を、どのように利用・適用するかについて、例を挙げて説明します パターン自体の設計は含みません © 2013 IBM Corporation 先にお話したPureApplicationのデプロイメントでの概念を基本に、 PureApplicationでクラウド基盤を構築する上で、どのような検討が必要かを説明し ます。 3 当セッションの内容 はじめに はじめに リソースの共有と分割～クラウド・グループの設計～ リソースの共有と分割～クラウド・グループの設計～ 連携と分離 連携と分離 ~IPグループ設計~ ~IPグループ設計~ リソースの割当と制御 リソースの割当と制御 ～環境プロファイル設計～ ～環境プロファイル設計～ ロールに基づく権限とアクセス制御 ロールに基づく権限とアクセス制御 ～ユーザー/グループ設計～ ～ユーザー/グループ設計～ まとめ まとめ 4 © 2013 IBM Corporation 大きく、4つの設定項目、クラウド・グループ、IPグループ、環境プロファイル、そして、 ユーザー及びグループについて、お話します。 4 はじめに 5 © 2013 IBM Corporation このセクションでは、まず、PureApplicationの製品として概要をお話します。 5 企業クラウド基盤の要件 クラウド基盤では、従来の基盤とは異なる要件がある クラウド基盤では、従来の基盤とは異なる要件がある 効率的リソース共有 効率的リソース共有 アジリティ アジリティ エラスティシティ エラスティシティ マルチテナンシー マルチテナンシー サービス継続性 サービス継続性 マルチ・ テナンシー 企業システム の一般的要件 •セキュリティ •可用性 •パフォーマンス ・・・ ＋ サービス 継続性 アジリティ （即時性） エラスティ シティ 効率的 リソース 共有 6 © 2013 IBM Corporation 企業クラウド基盤の要件には、大きく２つの側面があります。 1つは、通常の企業システムに一般的に要求される、従来と同様の要件です。ただし、優先度や、そ の具体的内容は変わる可能性があります。 もう1つは、クラウド特有の要件ですが、主に5つ挙げます。 １つ目は、リソースを共有し、かつ、効率的に行う必要があります。 そのためには、ハードウェア・リソースは仮想化し共有する必要があります。 また、仮想化されたリソースは、プールし、必要な量を割り当て、不要になれば、回収する、 仮想化リソースのライフ・サイクル管理も必要です。 2つ目はアジリティです。 リソースのリクエストに対して、直ちに必要なリソースを割当る必要があります。時間を要して いては、クラウドと言えません。 そのためには、リクエストから稼働環境のセットアップまでの処理・手順を自動化する、いわ ゆるプロビジョニング機能が必要になります。 3つ目のエラスティシティは、言い換えれば、動的なスケールアウトと、スケールインです。 トランザクション量やリソース使用量をモニタリングし、必要な時にはリソースを自動的に追 加し、不要になれば回収し、パフォーマンスを確保しながら、リソース利用を最適化しなけ ればなりません。 4つ目、サービス継続性は、いわゆる障害時の可用性に加えて、保守や運用のために部分的な停 止があっても、サービスを止めないということです。 障害発生時の耐障害性はもちろん、H/Wの増強や、部品やファームウェアの保守、Fixの 適用等々、保守作業時もサービスを継続できる仕組みが必要です。 最後に、マルチテナンシー。 リソースは、広く共有するほど、効率が向上します。しかし、アプリケーション、部門、或いは、 グループ会社を跨ったリソース共有のためには、一方では、互いの分離も必要になります。 マルチテナンシーは、そういった、利用者間、利用システム間での干渉を防ぐことです。 6 PureApplicationクラウド基盤の主要設計対象 企業システム の一般的要件 マルチ・テナ ンシー ＋ アジリティ （即時性） サービス 継続性 エラスティ シティ 制約 ＋ 効率的 リソース 共有 セキュリティ設計 クラウド・グループ IPグループ 環境プロファイル ユーザー／グループ 監視 運用 ネットワーク設計 パフォーマンス設計 ＜PureApplication クラウド基盤設計＞ データ/ストレージ設計 * 監視・運用については、明日の午後のセッションでご説明します。 7 © 2013 IBM Corporation 要件に加えて、企業の指針や法規制等々の制約を意識して、設計を行うことになり ます。 データセンター全体の設計として、セキュリティ、パフォーマンス、ネットワーク、 データやストレージ設計などがあります。 これらをベースにPureApplication内の、主要な設計項目として、クラウド・グループ、 環境プロファイル、IPグループ、ユーザー/グループ、監視、運用があります。 監視・運用については、明日のセッションを参照ください。このセッションでは、それ 以外の点線で囲んだ項目について取り上げます。 7 【復習】クラウド・グループ／IPグループ／環境プロファイル 稼動のための各リソースは、デプロイ時にサーバーインスタンスに割当 稼動のための各リソースは、デプロイ時にサーバーインスタンスに割当 クラウド・グループ単位でリソースをプール クラウド・グループ単位でリソースをプール 環境プロファイルにより、リソースの割当元のクラウド・グループ等を指定 環境プロファイルにより、リソースの割当元のクラウド・グループ等を指定 必要リソースの指定 （CPU、メモリー等） WAS WAS IHS デプロイ パターン 環境 プロファイル インスタンス 計算ノー ド ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ IPグループ CPU クラウド・グループ xx 8 ストレージ DB2 WAS 計算ノード メモリー メモリー WAS IHS ・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ メモリー CPU IPグループ ストレージ クラウド・グループ zz © 2013 IBM Corporation パターン＆デプロイメントのセッションで既にお話しましたが、復習します。 作成したパターンをデプロイする際に、そのデプロイに割当てるリソースの制御など を規定しているのが、環境プロファイルになります。 リソースは、クラウド・グループというリソース・プールにグルーピングされています。 8 リソースの共有と分割 ~クラウド・グループの設計~ 9 © 2013 IBM Corporation このセッションでは、クラウド・グループの設計についてお話します。 9 【復習】クラウド・グループ 計算ノードやIPグループ等のリソース・プールの定義 計算ノードやIPグループ等のリソース・プールの定義 このクラウド・グループにデプロイする仮想マシンのテンプレート情報を保持 このクラウド・グループにデプロイする仮想マシンのテンプレート情報を保持 共有サービスはクラウド・グループごとにデプロイ 共有サービスはクラウド・グループごとにデプロイ 設定項目 設定項目 計算ノード 計算ノード タイプ： タイプ： 仮想CPU割当方法を指定（平均 仮想CPU割当方法を指定（平均 or or 専有） 専有） IPグループ（次章参照） IPグループ（次章参照） 管理VLAN 管理VLAN ID ID ストレージ・ボリューム構成／仮想マシン構成のデフォルト値 ストレージ・ボリューム構成／仮想マシン構成のデフォルト値 クラウド・グループ クラウド・グループ IPグループ IPグループ IPアドレス 使用中 nnn.nnn.nnn.nnn ◆ 計算ノード 共有サービス 共有サービス 共有サービス nnn.nnn.nnn.nnn ・ ・ 10 © 2013 IBM Corporation まず、クラウド・グループとは、なんだったか？復習です。 クラウド・グループ、いわゆるリソース・プールで、計算ノードは、それぞれクラウドグ ループに所属します。 デプロイすると、そのインスタンスは、デプロイ先のクラウド・グループに所属する計 算ノード上で稼動します。 また、クラウド・グループには、デプロイ時に使用するIPアドレスのプールである、IP グループを幾つか所属させることができます。 共有サービスも、クラウド・グループ単位にデプロイされて動作します。 10 【参考】共有サービス クラウド・グループ内で共有される機能コンポーネント クラウド・グループ内で共有される機能コンポーネント 共有サービスも仮想アプリケーション・パターンで提供され、簡単にデプロイ＆稼動 共有サービスも仮想アプリケーション・パターンで提供され、簡単にデプロイ＆稼動 仮想アプリケーション・パターンのポリシー実装、及び監視で使用 仮想アプリケーション・パターンのポリシー実装、及び監視で使用 クラウド・グループ Elastic Load Balancing プロキシー ルーティング ＆ オート・スケーリング 監視関連の共有サービス システム・モニター OS 監視 11 パターン・インスタンス アプり パターン・インスタンス サーバー アプりパターン・インスタンス DB サーバー アプり サーバーアプり DB サーバー アプりサーバー DB LDAPサーバー アプり サーバー サーバー サーバー アプり LDAP サーバー アプりサーバー サーバー LDAP サーバー サーバー アプり サーバー キャッシュ HTTP セッション 永続化 WAS システム・モニター HTTP サーバー システム・モニター DBパフォーマンス ・モニター WAS 監視 IHS 監視 DBパフォーマンス 監視 © 2013 IBM Corporation 共有サービスの説明は割愛しますが、ルーティングの機能を提供するELB、セッ ション永続化機能を提供するキャッシュ機能、それから、監視関連の各種サービス などがあります。 11 クラウド・グループ設計のポイント １． １．クラウド・グループの分け方 クラウド・グループの分け方 分離要件・ポリシーに依存（SLA、運用時間） 分離要件・ポリシーに依存（SLA、運用時間） 少ないほど、リソース共有の効率は向上（共有サービス 少ないほど、リソース共有の効率は向上（共有サービス も考慮） も考慮） ２．キャパシティ ２．キャパシティ 計算ノード数（CPU&メモリー） 計算ノード数（CPU&メモリー） CPUは専有 CPUは専有 or or 平均？ 平均？ エラスティシティ（自動スケール・アウト）を考慮 エラスティシティ（自動スケール・アウト）を考慮 可用性も考慮して決める（後述） 可用性も考慮して決める（後述） ３．可用性 ３．可用性 可用性リソースの予約設定（ 可用性リソースの予約設定（ 1/ 1/ (ノード数） (ノード数） のリソースを予約） のリソースを予約） リソース 有効利用 分離 ポリシー 可用性 12 © 2013 IBM Corporation クラウド・グループの設計には、主に3つのポイントがあります。 1つは、どういった粒度、基準で分離するか？です。 これは、一般的には、干渉を避けたい分離の要件や、様々なポリシー、SLAや運用方針、との整合 性が求められます。 ただし、一般的には、細かく分けるほどリソース共有の効率は悪くなり、大きいグルーピングほど、効 率は向上します。 リソースそれ自体もそうですが、クラウド・グループ毎に共有サービスも必要になるので、その分の オーバーヘッドも考慮する必要があります。 2つ目は、各クラウド・グループにどれだけのリソースを割当てるか？です。 これは、一般的にはパフォーマンスやキャパシティの要件で決まるものですが、クラウド、或いは、 PureApplicationならではの考慮点もあります。 割当るのは、計算ノードですが、CPUとメモリーの両方を考えます。 CPUは、通常は、「平均」で割当てます。 エラスティシティ、つまり、動的なスケール・アウト機能を使用することで、リソース使用を効率化するこ とができます。一方で、実際にスケールアウトした場合のリソース量には注意が必要です。 また、サービス継続性については、3つ目の項目とも関連しますが、必要な計算ノード数＋１すること で、計算ノード障害時でも、サービスの停止を避けることができます。 3つ目、可用性リソースの予約設定を行うことで、計算ノード障害時でも、全てのVMを他の計算ノー ドで稼動させることができるように、1計算ノード分のリソースを予約します。 計算ノード障害や、運用停止の際のリソースをどう考えるかで、具体的には、停止時のサービス継続 性を考慮して、計算ノード1台分のリソースを予約する機能を利用するか、どうかの選択になります。 それだけ、キャパシティも増やすことにも繋がります。 12 クラウド・グループの分け方 運用時間が同じアプリケーションを集める 共有サービスの運用との連動 同じクラウド・グループで稼動するアプリケーションが利用 ELBやキャッシュを停止すれば、依存する全アプリケーションへ影響 監視用共有サービスの保守停止時には、監視ができない 計算ノードの保守 開発・テスト環境と本番環境の分離 開発・テスト環境でのリソース利用が、本番環境に影響しない 開発環境では、監視用共有サービスを稼動しない選択枝 本番環境のみ、「可用性リソースの予約」を設定 運用時間が同じアプリケーションであれば、計算ノードの停止・保守も容易 キャパシティに余裕があれば、別の計算ノードに無停止で移動することも可能 「可用性リソースの予約」オプションを設定すれば、1台の停止でも全VMの稼動が可能 計算ノード・レベルでの分離 利用部門やプロジェクトによる分離 計算ノード数に基づくシンプルな課金が可能 13 © 2013 IBM Corporation クラウド・グループの分け方について、具体的もう少し詳細に見てみます。 ここでは、3つの可能性を議論してみましょう。 まず、運用時間を考慮した分離です。 同じクラウド・グループで稼動するアプリケーションは、同じ共有サービスを使用します。 そのため、共有サービスを保守で停止する場合には、同じクラウド・グループで稼動する全てのシス テムに影響します。 とりわけ、ELBやキャッシュを使用するシステムは、停止せざるを得ません。 共有サービスの停止は、それほどの頻度で行われるわけではありませんが、ひとつの考慮点ではあ ります。 共有サービス程ではありませんが、計算ノードの保守という可能性もあります。ただし、こちらの場合 は、別計算ノードに移動してサービス継続することもできます。 次に、開発・テスト環境と本番環境といった、用途、或いは、サービス・レベルによる分離です。 クラウド・グループを分離することで、開発・テスト環境が、本番環境に影響しません。 また、開発・テスト環境では、可用性リソースの予約が不要であったり、共有サービスの一部も不要 で停止することで、リソースの節約ができる可能性もあります。 最後に利用部門やプロジェクト単位での分離です。 これまで、述べたのと同じような議論が可能です。加えて、課金がシンプルになる可能性があります。 つまり、クラウド・グループに所属する計算ノード数での課金という考え方が成立します。 vCPU数による課金は、共有している以上、厳密ではありません。もちろん、CPU使用率を監視して 課金する手段もあります。 13 可用性の考え方 可用性を考慮した計算ノードのグルーピング 可用性を考慮した計算ノードのグルーピング PureApplicationはパターン内の同一パーツ（例：APサーバー）を複数デプロイする際に、 PureApplicationはパターン内の同一パーツ（例：APサーバー）を複数デプロイする際に、 計算ノードをまたがって仮想マシンを配置する 計算ノードをまたがって仮想マシンを配置する クラウド・グループに計算ノードを2つ以上登録することで、１つの計算ノード障害時でも クラウド・グループに計算ノードを2つ以上登録することで、１つの計算ノード障害時でも サービスの継続は可能 サービスの継続は可能 クラウド・グループ内にシャーシをまたがって計算ノードを登録することでシャーシ障害時で クラウド・グループ内にシャーシをまたがって計算ノードを登録することでシャーシ障害時で も縮退運用でサービスを継続できる も縮退運用でサービスを継続できる 障害時以外の要件もあわせて検討する 障害時以外の要件もあわせて検討する PureApplicationの保守をサービス無停止で行いたい場合など PureApplicationの保守をサービス無停止で行いたい場合など 計算ノード上の仮想マシンを移動する必要 計算ノード上の仮想マシンを移動する必要 パターン Web サーバー Web サーバー ノード Web サーバー アプり サーバー アプり サーバー DB サーバー Web サーバー アプり サーバー アプり サーバー アプり サーバー アプり サーバー DB サーバー DB サーバー デプロイ ノード DB サーバー 14 © 2013 IBM Corporation クラウド・グループのデザインでは計算ノードの配置も重要です。 PureApplication Systemのプロビジョニング機能はパターン内の同一パーツ（例： APサーバー）を複数デプロイする際に、計算ノードをまたがって仮想マシンを配置 します。 クラウド・グループに2台以上の計算ノードが登録されていれば、1台の計算ノード に障害が発生しても縮退構成でサービスの継続は可能です。 さらに96コア以上のモデルであればシャーシをまたがって計算ノードを選択し、クラ ウド・グループに登録することでシャーシ障害時でもサービスの継続が可能です。 また、この設計は障害時以外に保守をサービス無停止で行いたい要件がある場合 にも重要になりますので、保守の要件も十分に考慮してください。 14 可用性の考え方（つづき） 可用性をどのレベルで確保するかを十分検討する 可用性をどのレベルで確保するかを十分検討する 計算ノード・レベルで担保すると仮想マシンの集約度がさがる 計算ノード・レベルで担保すると仮想マシンの集約度がさがる 障害発生時に一時的な縮退運用が可能かどうかを検討する 障害発生時に一時的な縮退運用が可能かどうかを検討する ワークロードによっては上のレイヤーで可用性の確保を検討する ワークロードによっては上のレイヤーで可用性の確保を検討する クラウド・グループの「可用性リソースの予約」設定 クラウド・グループの「可用性リソースの予約」設定 計算ノード障害時に全仮 計算ノード障害時に全仮 想マシンの救済が 想マシンの救済が 必要？ 必要？ シンプルな設定で可用性を向上できる シンプルな設定で可用性を向上できる 高可用性構成にすることで、利用できる計算リソース量（CPU＆メモリー）は制限される 高可用性構成にすることで、利用できる計算リソース量（CPU＆メモリー）は制限される MW層の可用性パターンでの対応が可能かも検討する MW層の可用性パターンでの対応が可能かも検討する 優先度をつけることで本当に重要なものだけ救うこともできる 優先度をつけることで本当に重要なものだけ救うこともできる クラウド・グループのプロパティ （後述） （後述） HAのため 予約済 （デプロイ不可） 使用可能 リソース HAのため 予約済 （デプロイ不可） 使用可能 リソース • 1/N (ノード数） のリソースが事前予約される • １計算ノードの障害発生時は、全VMを救済することが可能 15 計算ノード 16 物理コア 256GBメモリ 搭載 クラウド・グループ 16 物理コア 256GBメモリ available 2計算ノードからなるクラウド・グループの例 © 2013 IBM Corporation エンタープライズ・システムでは可用性は常に重要な要件の1つです。 クラウド環境の場合はさまざまなワークロードがPureApplication System上で稼動 しますので、可用性をどのレベルで確保するかを確認することが重要です。 計算ノード・レベルで担保する以外に、MWのレベルでHAの機能を実装することも 可能ですし、クラスター構成をとっているシステムであれば障害発生時でも一時的 に縮退運用で対応できる可能性もあります。 ワークロード・レベルでの可用性を意識したデザインは「パターンを利用したシステ ム・デザイン」のセッション資料を参照してください。 一方、計算ノード障害時に全仮想マシンを退避させることを可能にするクラウド・グ ループの「可用性リソース予約」の設定のメリットは、クラウド・グループ内で稼動し ている個々のワークロードを意識せずにシンプルな設定で可用性を確保できること です。その反面、クラウド・グループ内に常に1台分の計算ノードのリソースが予約さ れるため、全体として利用できるリソースが限定されます。 そのため、前ページのように、MWレベルで可用性を担保したり、環境プロファイル を使ったワークロードに優先度をつける方法もあわせて十分検討してください。 15 シナリオ1： アプリケーション・ライフサイクルを通じて利用するデプロイメント基盤 クラウド・グループ設計方針 用途に応じて分離 その他の考慮点 リソースの再利用性を意識する 運用の責任者、範囲を意識する クラウド・グループの範囲 稼動システムの重要度と運用要件を重視 ノード2 本番クラウド・グループ 本番 ノード1 ノード3 テスト ノード4 ノード5 開発 ノード6 業務継続性が求められる重要度の高い本番環境へ専用の計算 ノードリソース 運用要件が他と異なるため他環境と分離 管理ネットワーク分離のために独立したクラウド・グループとする テスト／開発クラウド・グループ リソースの再利用性を意識し、短いライフサイクルでリサイクル 複数ユーザー環境なので、運用責任者とその責任範囲を限定 開発 とテストで、運用指針や運用管理者が異なる場合は、クラ ウド・グループを分離 16 © 2013 IBM Corporation ここでは、具体的に3つのシナリオを考えて、クラウド・グループの設計指針を考えてみます。 シナリオ1はアプリケーション・ライフサイクルを通してのデプロイメント基盤としてPureApplication Systemを利用する例です。 本番、テスト、開発、それぞれが同じPureApplicationで稼動する前提です。 開発は、統合テスト環境、テストはシステム・テスト環境と読み替えても良いです。 このシナリオでは、稼動システムの重要度と運用要件を重視し、用途と運用方針ごとにクラウド・グ ループを分離する方針です。 まず本番環境は専用のクラウド・グループを作成することとします。これは、業務継続性が求められる 重要度の高い本番環境用なため、他環境との独立性を重視し、専用のリソースと独立した管理用 ネットワークを割当てるためです。 運用時間や運用方針の違いなどを考慮して、運用要件が等しい範囲でクラウド・グループを定義す ることも考えられます。 テスト環境と開発環境はその要件からリソースを共有することが可能です。特にリソースの再利用を 効率よく行うにはクラウド・グループを1つにして、リソースを共有する範囲を広くしたほうが効果が高 いと考えられます。ただし、開発とテスト環境では運用方針や運用者が異なる場合で運用を重視す る場合には、運用の責任者、範囲を考慮してクラウド・グループをさらに分割することも選択肢として 考えられます。 16 シナリオ2： 多様なユーザーにサービスを提供するWebアプリケーション統合基盤 クラウド・グループ設計方針 クラウド・グループの範囲 利用者別 ネットワーク構成の特性で分ける ノード2 ノード4 ノード5 ノード6 稼動システムの重要度と運用要件を 重視 可用性の担保をどのレベルで考慮す るかを検討 ネットワーク構成など要件が異なる 稼動時間/運用時間が異なるため社内と社外で分ける 社内アプリケーション用クラウド・グループ その他の考慮点 社内と社外向けにクラウド・グループを分割 社外向け ノード3 社内向け ノード1 17 アプリケーション特性ごとに分離 季節変動型のアプリケーションがあるため、重要度の中と低 のアプリケーション間でリソースを共有し有効活用する 顧客向け社外アプリケーション用クラウド・グループ 計算ノード障害に耐えられる設計にする 必要なノード数＋１を確保する © 2013 IBM Corporation シナリオ2は多様なユーザーにWebアプリケーションを提供するアプリケーション統 合基盤としてPureApplication Systemを利用する例です。 このシナリオでは、アプリケーションの特性を考慮した上でネットワーク要件ごとにク ラウド・グループを分離する方針とし、社内向けアプリケーションと社外向けアプリ ケーションでクラウド・グループを分割しています。ネットワーク要件のほかに、稼動 時間/運用時間が異なることもクラウド・グループを分割する要素になります。 社内アプリケーションはその特性から2つのカテゴリーに分類されていましたが、ク ラウド・グループは1つに集約することで、季節変動型アプリケーションなどリソース のニーズが異なるアプリケーション間でリソースを共有し有効活用することを可能に します。 また、社外アプリケーションはビジネス上重要度が非常に高いため、1台の計算 ノード障害時にすべての仮想マシンを自動復旧させるために可用性リソースの予 約設定をクラウド・グループに対して行うこととします。その場合、想定計算ノード数 ＋1台の計算ノードが必要となります。 17 シナリオ3： 規模・ライフサイクルが異なる多数のアプリケーション向けクラウド基盤 クラウド・グループ設計指針 その他の考慮点 アプリケーション特性別 アプリケーションのパフォーマンス要件別 さまざまなライフサイクルを持つア プリケーションの基盤となる環境 クラウド・グループの範囲 リソースの割当て方式別 利用者やシステム環境、構成の特性で分ける ノード2 大規模向け ノード1 ノード5 ノード6 小規模向け ノード4 リソースの割り当て方法でクラウド・グループを分割 随時負荷の高い大規模Webアプリの仮想CPUには専用でCPU リソースを割当 ライフサイクルや負荷が多様な小規模Webアプリ類は集約度と リソースの有効活用を重視して平均で割当 ノード3 18 アプリ分類 要件 リソースの割り当て 小規模Webアプリ類 重要度：高 平均 小規模Webアプリ類 重要度：低 季節変動型 平均 大規模Webアプリ類 重要度：高 常に負荷高い 専用 クラウド・ グループ１ クラウド・ グループ2 © 2013 IBM Corporation シナリオ3は多様なライフサイクルを持つアプリケーション向けのプライベート・クラウ ド基盤としてPureApplication Systemを利用する例です。 このシナリオでは、アプリケーションの特性とパフォーマンス要件を元にクラウド・グ ループを分割します。 コンスタントにアクセスのある大規模Webアプリケーションの仮想マシン群に対して は、安定したスループットを実現できるように仮想CPUに対して専用でCPUリソース を割当てます。この設定はクラウド・グループ単位での設定となるため、大規模Web アプリケーション群は他のアプリケーション群とは別にクラウド・グループを割当てま す。 小規模Webアプリケーション群はアプリケーションによってライフサイクルや負荷も 多様なため、リソースを共有する範囲を広くすることでリソースの有効活用を図りま す。また、アプリケーション間でCPUリソースを共有し動的に割当を変更できるよう にすることで、それぞれの負荷に応じてリソースを調整できるようにリソースの割当 ては「平均」方式を採用することとします。 18 【参考】クラウド・グループ： 仮想CPU割当てのタイプ タイプ 仮想CPU（vCPU)と 物理CPU（pCPU ) １計算ノードの 最大仮想CPU数 専用 １vCPU = 1pCPU 16* 平均 8 vCPU = 1pCPU 128* 特徴・補足 CPU及びメモリーへのアクセス効率が高い １計算ノード上で稼動できるVM数が少ない 他のVMの使用状況によっては、より多くのCPU能力 が使用可能 より多くの仮想マシンを１計算ノードで稼動できる *ただし、CPUコアの10%は、ハイパーバイザー用に予約 【平均】 【専用】 指定された仮想CPU数（＝物理CPU）を、個々のVMが専有 ・・・・・・・ ・・・・・・・ CPU ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ CPU ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ CPU ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ 1つの物理CPUを最大8つのVMで共用 VM ・・・・・・・ ・・・・・・・ CPU ・・・・・・・ ・・・・・・・ ・・・・・・・ ・・・・・・・ VM VM VM VM VM VM vCPU=1 19 vCPU=2 VM VM VM © 2013 IBM Corporation クラウド・グループには、インスタンスのCPUの使用の仕方を指定する必要がありま す。 指定は、「専用」又は、「平均」のいずれかで、通常は、「平均」を設定します。 「平均」とすれば、1計算ノード当り16個のCPUコアを128個の仮想CPUとみなして、 各VMで共有して使用することができます。 一方「専有」とした場合、各VMへは、実際のCPUコアが割当てられます。したがっ て、各計算ノードでは、最大16個までしか仮想マシンを稼動させることができません。 19 連携と分離 ～IPグループの設計~ 20 © 2013 IBM Corporation 次に、IPグループの設計についてお話します。 20 【復習】IPグループ IPアドレス範囲、及び、VLANレベルでのネットワークの分離が可能 IPアドレス範囲、及び、VLANレベルでのネットワークの分離が可能 IPグループの内容物： IPグループの内容物： VMに適用する各種ネットワーク設定とIPアドレスのプール VMに適用する各種ネットワーク設定とIPアドレスのプール 環境プロファイル設定が「IPグループ」の場合、 環境プロファイル設定が「IPグループ」の場合、 プールから未使用のアドレスを割当 プールから未使用のアドレスを割当 IPアドレスのプールには、範囲等を指定してIPアドレスを追加可能 IPアドレスのプールには、範囲等を指定してIPアドレスを追加可能 ネットマスク ネットマスク ＆ ＆ デフォルト・ゲートウェイ設定を含む デフォルト・ゲートウェイ設定を含む DNSサーバーのIPアドレス DNSサーバーのIPアドレス （プライマリ （プライマリ ＆ ＆ セカンダリ） セカンダリ） 所属するVLANのID 所属するVLANのID 固定IP使用の場合（プロファイル設定が「パターン・デプロイヤー」）も、アドレス以外の設定（ネット 固定IP使用の場合（プロファイル設定が「パターン・デプロイヤー」）も、アドレス以外の設定（ネット マスク＆デフォルトゲートウェイ／DNSサーバー等）はVMに適用される マスク＆デフォルトゲートウェイ／DNSサーバー等）はVMに適用される IPグループ DNS設定 （プライマリー＆セカンダリー） VLAN ID ネットマスク ＆ デフォルト・ゲートウェイ 21 IPアドレスのプール IPアドレス IPアドレス nnn.nnn.nnn.nnn nnn.nnn.nnn.nnn nnn.nnn.nnn.nnn nnn.nnn.nnn.nnn ・ ・・ ・・ ・ 使用中 使用中 ◆ ◆ © 2013 IBM Corporation IPグループについての復習です。 IPグループは、IPアドレスのプールですが、それ以外に、デフォルトのネットマスク やゲートウェイ、DNSサーバーのIPアドレス等も指定します。 21 IPグループ設計のポイント 全体のネットワーク設定との整合性に注意 全体のネットワーク設定との整合性に注意 １．VLAN １．VLAN ブロードキャストの影響範囲を分離 ブロードキャストの影響範囲を分離 異なるIPグループで同じVLAN 異なるIPグループで同じVLAN IDを指定することも可能 IDを指定することも可能 ２．IPアドレス ２．IPアドレス ゾーンニングによる分離 ゾーンニングによる分離 エラスティシティによるノード増加も考慮して十分な個数が必要 エラスティシティによるノード増加も考慮して十分な個数が必要 外部との連携のための方法 外部との連携のための方法 連携用のIPアドレス・グループの作成（負荷分散装置と連携するELB 連携用のIPアドレス・グループの作成（負荷分散装置と連携するELB 等） 等） 手動による固定IPの割振り 手動による固定IPの割振り ３．DNS ３．DNS PSMに設定するDNSには、全てのIPアドレスが登録されている必要がある PSMに設定するDNSには、全てのIPアドレスが登録されている必要がある IPアドレス・グループ毎に異なるDNSサーバーの指定も可能 IPアドレス・グループ毎に異なるDNSサーバーの指定も可能 22 © 2013 IBM Corporation IPグループ設計のポイントとして、3つ挙げます。 いずれも、データセンター全体のネットワーク設計と密接に関連します。 1点目は、VLANをどう分離するか？です。 ご存知の通り、VLANを分けることで、ブロードキャストの影響を避け、また、フィルタリングやファイア ウォールによるアクセス制御といった分離も可能になります。 2点目は、IPアドレスの振り方です。 まず、当然ですがゾーニングによって、IPアドレスを分離するということがあります。 次に、エラスティシティ、つまり、動的スケーリングを使用する場合は、IPアドレスの個数を十分準備 する必要があります。 ELBや共有キャッシュサービスもスケール・アウトするので、注意が必要です。 1つの課題は、外部と連携するノードのIPアドレスをどうするかです。 例えば、限定的な個数の、外部連携専用のIPアドレス・グループを作成するということが考えられま す。 手動による固定IPアドレスの割振りも可能ですが、その場合、エラスティシティ、すなわち、自動ス ケーリングの機能は利用できません。 3点目は、DNS設定についてです。 まず、PSMに設定するDNSサーバーについては、全てのIPアドレスが登録されている必要がありま す。 通常は、それぞれのIPアドレス・グループでも同じDNSサーバーを指定すればよいです。 要件によっては、別のDNSサーバーを指定して、名前解決の観点からもゾーンニングをサポートす ることも可能です。 22 データセンター基盤コンポーネントとPureApplication PureApplicationの設置に伴ってセンター側に必要とされるデータセンター側のコンポーネント PureApplicationの設置に伴ってセンター側に必要とされるデータセンター側のコンポーネント 運用基盤 ネットワーク基盤 ネットワーク基盤 DNSサーバー＆NTPサーバー（必須） ToRに対向するネットワーク・スイッチ ToRに対向するネットワーク・スイッチ ファイル連携用SCP/HTTPサーバー（必須） ルーター ルーター バックアップ用のTSMサーバー 負荷分散装置（オプション） 負荷分散装置（オプション） SNMPトラップ連携用の監視サーバー PureApplication System ネットワーク基盤 ネットワーク・スイッチ ルーター DNSには使用する IPアドレスとそのホ スト名の登録が必要 PureApplication System 内のルーティングも必要 SCP／HTTP サーバー 負荷分散装置 PureApplication System （オプション） の保守・運用に必須 23 DNS サーバー NTP サーバー 監視サーバー （SNMP） TSM サーバー データセンター運用基盤 © 2013 IBM Corporation ここで、PureApplicationの外側に必要、或いは、連携が推奨される、いくつかの機 能コンポーネントについて、復習します。 まず、PureApplicationに搭載されている、N/Wスイッチは、ルーティング機能はあ りません。 したがって、ルーティング機能、ルーターは、外部に用意する必要があります。 また、外部に負荷分散装置があれば、有Active-Activeのプロキシー構成をサポー トできます。 名前解決のためのDNSサーバーと時刻同期のためのNTPサーバーは、 PureApplicationの導入時から必要になります。 また、先に述べたように、仮想マシン・インスタンスで使用するIPアドレスは、DNS サーバーに名前登録されていることが前提です。 PureApplicationは、監視機能を提供しますが、外部の監視サーバーにSNMPト ラップで連携することができます。 PureApplicationは、TSMクライアント機能を提供しますが、バックアップを行うには、 そのバックアップ先としてのTSMサーバーが必要になります。 また、PureApplicationへのFix適用やログ取得には、外部にSCPサーバー、及び、 HTTPサーバー等が必要になります。 23 ELB専用のIPグループの作成 ELB用IPグループ 割り振り先 192.168.0.1 192.168.0.2 192.168.0.3 IPアドレス 使用中 192.168.0.1 ◆ ◆ 192.168.0.2 IPアドレス 使用中 192.168.123.1 ◆ ◆ 192.168.123.2 ・・・ ・・・ 192.168.0.3 仮想アプリケーション用 IPグループ ・・・ ELB ＃1 192.168.0.1 負荷分散装置 ELB ＃2 192.168.0.2 ELB ＃3 192.168.0.3 ELBインスタンス 24 APサーバー 192.168.123.1 APサーバー 192.168.123.2 APサーバー 192.168.123.3 Web Application Pattern インスタンス © 2013 IBM Corporation 外部連携用のIPグループを作成する例として、ELB専用のIPグループを作成する 場合です。 ELBで使用するIPアドレス・グループ内のIPアドレスは、予め負荷分散装置に登録 しておきます。 これによって、負荷分散装置に一々、ELBのIPアドレスを割振る必要がなくなります。 24 リソースの割当と制御 ～環境プロファイル～ 25 © 2013 IBM Corporation このセッションでは、環境プロファイルの設定についてお話します。 25 【参考】環境プロファイルとは 使用するリソースの割当方法及び、リソースの制限などを記述 使用するリソースの割当方法及び、リソースの制限などを記述 マルチテナント環境でユーザーやユーザー・グループの使用リソースの分離・制限が可能 マルチテナント環境でユーザーやユーザー・グループの使用リソースの分離・制限が可能 環境プロファイル タイプ 実働 実働前 パフォーマンス テスト 開発 リサーチ すべて 選択 品質保証 デプロイ先クラウド・グループ 使用するIPグループ IPアドレスの指定方法 IPグループから の自動割当 デプロイヤー の手動設定 or IPグループ デプロイ時の優先度 プラチナ 金 銀 銅 IPグループ 計算ノード 環境の制限 ストレージ 使用量 ・・・・・・・ ・・・・・・・ 仮想 ・・・・・・・ CPU数 ・・・・・・・ ・・・・・・・ ・・・・・・・ 仮想 メモリー量 使用 使用可能 ライセンス数 ライセンス数 26 © 2013 IBM Corporation 先にお話したとおり、デプロイ時には環境プロファイルを選択する必要があります。 環境プロファイルには、ここにあるような設定項目があります。 もっとも重要なのは、デプロイ先のクラウド・グループです。 これによって、どこのリソースを使用するのかが決まります。 26 環境プロファイル設計のポイント 各デプロイヤーが利用できる環境プロファイルを制限 各デプロイヤーが利用できる環境プロファイルを制限 １．クラウド・グループ １．クラウド・グループ デプロイヤーによって使用できるリソースを分離 デプロイヤーによって使用できるリソースを分離 各クラウド・グループ毎にユーザー・グループを作成 各クラウド・グループ毎にユーザー・グループを作成 ２．IPアドレス ２．IPアドレス デプロイヤーの利用するネットワークを制限 デプロイヤーの利用するネットワークを制限 用途によってIPアドレスを使い分け 用途によってIPアドレスを使い分け 外部連携が必要なコンポーネント 外部連携が必要なコンポーネント → → 手動設定 手動設定 エラスティシティが必要なコンポーネント エラスティシティが必要なコンポーネント → → 大きなIPアドレス・グループ 大きなIPアドレス・グループ ３．環境の制限 ３．環境の制限 同じ環境プロファイルを使用するインスタンスへのリソース割当量の制限 同じ環境プロファイルを使用するインスタンスへのリソース割当量の制限 仮想CPU/メモリー/ストレージ/ライセンス 仮想CPU/メモリー/ストレージ/ライセンス 制限超過時には、デプロイに失敗 制限超過時には、デプロイに失敗 ４． ４．重要度の設定 重要度の設定 計算ノード停止時の稼動VMの優先度に影響（次ページ以降を参照） 計算ノード停止時の稼動VMの優先度に影響（次ページ以降を参照） 27 © 2013 IBM Corporation 環境プロファイルの設計のポイントを4つ挙げます。 デプロイヤーは、デプロイを実施するユーザーです。 1点目は、クラウド・グループの指定ですが、分離するためには、そのデプロイヤー に使用を許可するクラウド・グループを登録します。 グループ単位でアクセス制御を行うことが考えられます。 2点目は、IPアドレスですが、まず、デプロイヤーの利用できるIPを分離・制限する か？です。 3点目は、各種の制限をどうするか？です。 環境プロファイルを通じて、CPU、メモリー、ストレージ、ライセンス数などの制限を 設定することができます。 4点目は、重要度の設定です。これは、計算ノードが障害や運用で停止する場合に、 どのVMを退避し、どのVMを停止するかの選択基準になります。 27 優先度設定とウェイト値 環境プロファイルの優先度とデプロイ時に設定する優先度の組み合わせで仮 想マシンの重要度を示すウェイト値が決まる 環境 プロファイル x デプロイ時 AP Web AP パターン Web AP Web AP Web AP AP DB 各VMの Weight=16 DB DB DB 環境 プロファイル x デプロイ時 AP Web AP Web 28 AP DB DB 各VMの Weight=12 © 2013 IBM Corporation 環境プロファイルで設定される優先度（Platinum、Golden、Silver,Bronze）とデプ ロイ時の優先度（High Med,Low）との組み合わせで各仮想マシンのウェイト値が決 定されます。このウェイト値が高い仮想マシンほど優先度が高くなります。 障害などで、計算ノードのキャパシティ不足になった場合、この優先度に従って仮 想マシンが退避・稼動されます。 図の例では同じパターンからデプロイされた仮想システム・インスタンスでも利用す る環境プロファイルの設定値と、デプロイ時の設定値によって優先度が変わることを 示しています。 28 【参考】環境プロファイルにおける優先度設定 29 環境プロファイルの設定項目 © 2013 IBM Corporation この画面は環境プロファイルの設定画面のキャプチャーです。環境プロファイルの プロパティの1つに「優先度」を設定する項目があります。これは環境プロファイルご とに設定可能なパラメータで、この環境プロファイルを使ってデプロイする仮想マシ ンの重要度を決定する際に使用されます。 29 【参考】 デプロイ時の優先度設定 仮想マシンの優先度 環境プロファイルに設定される優先度とデプロイ時に設定される優先度の組 み合わせで決定 デプロイ時の優先度設定 計算ノード障害時に全仮想マシンの退避 が難しい場合には、仮想マシンの優先度 にしたがって退避可否が判断される クラウド・グループを共有するシステム間で もっとも重要なシステムのインスタンスの ウェイトが高くなるように調整 30 © 2013 IBM Corporation 仮想マシンの優先度は、前頁の環境プロファイルで設定された優先度と、デプロイ 時に個々のインスタンス単位で設定できる優先度の組み合わせで決定されます。 計算ノード障害時に全仮想マシンの退避が難しいばあには、仮想マシンの優先度 にしたがって、退避可否が判断され、優先度の高いものが優先されます。 クラウド・グループ設計でご紹介した可用性のための予約設定を行わない場合は、 クラウド・グループを共有システム間でもっとも重要なシステムのインスタンスのウェ イトが高くなるように調整して、優先度の高いものを優先して復旧させることも可能 です。 30 環境プロファイルのデザイン －優先度の活用 背景/理由 優先度をつけることで本当に重要なものだけ救う クラウド・グループ・レベルでの可用性設定よりリソースを有効活用できる SLAの異なるアプリを1つのクラウド・グループに集約 ノード・グループ・レベルでの可用性確保より集約度をあげることができる ノード1 ノード2 ノード3 環境プロファイルにより優先度を設定し、優先度に応じた対 応が可能 デプロイ時の優先度を設定することでよりインスタンス単位 で優先順位をつけることができる アプリ分類 要件 環境プロファイルの優先度 ノード4 小規模Webアプリ類 重要度：高 金 ノード5 小規模Webアプリ類 重要度：低 季節変動型 銅 大規模Webアプリ類 重要度：高 常に負荷高い プラチナ ノード6 31 環境プロファイルの優先度を設定 © 2013 IBM Corporation ここで、クラウド・グループのデザインでご紹介したシナリオ2を例に優先度の活用を 考えてみましょう。 先にご紹介した計算ノード・レベルで可用性を設定することも可能ですが、より細か い粒度のインスタンスごとに優先度をつけることでリソースを有効活用しつつ、本当 に重要なものだけを障害時に救うという運用が可能となります。 ここではSLAの異なるアプリケーションを１つのクラウド・グループに集約しますが、 アプリケーションのカテゴリ別に環境プロファイルを分けてそれぞれ優先度を設定 することと、デプロイ時の優先度設定でインスタンスごとに優先度を管理します。こ の設定によりリソースを最大限に有効活用しつつ、本当に重要な仮想マシンは優 先度を高くして可用性を高めることが可能となります。 31 ロールに基づく権限付与とアクセス制御 ~ユーザー/グループ設計~ 32 © 2013 IBM Corporation このセクションでは、ユーザーとユーザーグループの設計についてお話します。 32 ユーザー／グループ設計のポイント １．ロール別にユーザー／グループを作成し権限を付与 １．ロール別にユーザー／グループを作成し権限を付与 コンテンツ開発者や管理者 コンテンツ開発者や管理者 パターン作成者 パターン作成者 カタログ・コンテンツ管理者 カタログ・コンテンツ管理者 クラウド・インフラ管理者 クラウド・インフラ管理者 システム管理者 システム管理者 環境プロファイル管理者 環境プロファイル管理者 ワークロード管理者 ワークロード管理者 パターン利用者 パターン利用者 パターン・デプロイヤー パターン・デプロイヤー ２．組織や管理上の役割に応じて、対象への権限を付与 ２．組織や管理上の役割に応じて、対象への権限を付与 組織別/チーム別で対象リソースを限定 組織別/チーム別で対象リソースを限定 インスタンス インスタンス パターン/カタログ・コンテンツ パターン/カタログ・コンテンツ 環境プロファイル/クラウド・グループ/IPグループ 環境プロファイル/クラウド・グループ/IPグループ 権限の限定を通じてマルチテナンシーの実現 権限の限定を通じてマルチテナンシーの実現 33 © 2013 IBM Corporation ユーザー及びユーザー・グループ設計のポイントは、大きく2つです。 1つは、ユーザー/ユーザー・グループの権限では、ロールを意識した権限付与が必要です。 コンテンツでいえば、パターンや、パターンで使用するイメージ、スクリプト・パッケージ等の作成・管 理があります。 クラウド・インフラでいえば、システム（端的に言えばHW）、環境プロファイル、などになります。 ここで、「ワークロード」と呼でいるのは、HW以外の、パターン作成やデプロイに関する全てのリソー スを指しています。 それらを管理する管理者というロールもあります。 パターン利用者は、パターンをデプロイする「デプロイヤー」ロールとが基本になります。 2番目は、適切なアクセス権限の付与です。 PureApplicationの各種リソースは、作成者に全権限があり、作成者が各ユーザー/グループに権限 を付与します。 基本的に「読み取り」か「書き込み」になります。 これら権限の付与を、カタログ・コンテンツであるイメージやスクリプト・パッケージ、或いは、パターン をデプロイして作成したインスタンスについて行います。 環境プロファイルや、クラウド・グループ、或いは、IPグループのアクセス制御は、マルチテナンシー の基礎になります。 33 パターンの作成・デプロイ・運用における必要権限 パターンのライフサイクルにおける各アクティビティには、適切なユーザー権限と使用リソースへの パターンのライフサイクルにおける各アクティビティには、適切なユーザー権限と使用リソースへの 適切なアクセス権限が必要 適切なアクセス権限が必要 仮想システム・パターンの場合 パターン・デプロイヤー （デフォルト） パターン作成者 運用者 監視者 新規作成 カタログ 仮想システム パターン 読み取り 読み取り デプロイ 監視：読み取り 開始・停止：書込み 読み取り パターン・インスタンス HV HV HV 仮想 イメージ インスタンス 管理 アプり サーバー スクリプト・ パッケージ アドオン 環境プロファイル DB サーバー アプり サーバー カタログ・コンテンツ 管理者 仮想イメージ/ スクリプト・パッケージ 等 の登録 34 環境プロファイル 管理者 環境プロファイル 作成 © 2013 IBM Corporation 仮想パターンの作成、デプロイ、運用における、必要なユーザーのアクセス権限について述べます。 まず、仮想パターンの元になる、仮想イメージやスクリプト・パッケージをカタログに登録する必要が あります。 カタログに、新規のコンテンツを登録するには、「カタログ・コンテンツ管理者」の権限が必要になり ます。 次に、新規のパターンを作成するには、「パターン作成者」の権限が必要になります。 加えて、仮想パターンの作成に使用する仮想イメージやスクリプト・パッケージに対する読み取り権 限をカタログ・コンテンツ管理者等に設定してもらう必要があります。 PureApplicationのユーザーは、パターン・デプロイヤーの権限をデフォルトで与えられています。 したがって、デプロイしたいパターンへの読み取り権限と、それをデプロイするための環境プロファ イルへの読み取り権限があれば、パターンをデプロイできます。 一方、環境プロファイルの作成には、環境プロファイル作成者の権限が必要になります。 作成者は、作成した環境プロファイルへの読み取り権限を、誰に与えるかによって、各ユーザー毎 に、どのクラウド・グループへのデプロイを許すのか、リソース利用量をどう制限するのか等々のコ ントロールを行うことができます。 デプロイしたパターンのインスタンスを運用していくに当たって、監視には、読み取り権限が、開始 や停止といった操作には、書込み権限が必要になります。 34 【参考】ユーザー＆ユーザー・グループのワークロード管理権限 通常ユーザー（及びユーザーグループ）に関するワークロード管理権限は以下の５つ 通常ユーザー（及びユーザーグループ）に関するワークロード管理権限は以下の５つ デプロイの権限（デフォルト） デプロイの権限（デフォルト） 新規パターンの作成 新規パターンの作成 新規環境プロファイルの作成 新規環境プロファイルの作成 新規カタログ・コンテンツの作成 新規カタログ・コンテンツの作成 ILMT ILMT ワークロード管理権限 実行可能アクション ロール パターンをクラウドにデプロイ （画面表示なし） 全ユーザーに対するデフォルト・パーミッション パターン・ デプロイヤー 新規パターンの作成 新規パターンを作成することができる 許可されたパターンをクラウドにデプロイすることができる パターン作成者 作成したパターンに関するパーミッション（（読み取り専用ま たは編集) を他ユーザーへ付与することができる 新規環境プロファイルの作成 新規に環境プロファイルを作成することができる 作成した環境プロファイルに関するパーミッション（読み取り 環境プロファイル 管理者 専用または編集)を他ユーザーへ付与することができる 新規カタログ・コンテンツの作 成 カタログ(仮想イメージ, 構成スクリプト, 再利用可能コン ポーネント、アドオン 等）に新規コンテンツを作成/追加するこ とができる カタログ・コンテン ツ管理者 IBM License Metric Tool （ILMT） ILMTを構成することができる ライセンス管理者 35 © 2013 IBM Corporation PureApplicationのワークロード管理権限の設定とロールのマップです。また、それ ぞれ、実行可能なアクションをまとめておきます。 35 パターンの作成・デプロイ・運用における必要権限（続き） パターンのライフサイクルにおける各アクティビティには、適切なユーザー権限と使用リソースへの パターンのライフサイクルにおける各アクティビティには、適切なユーザー権限と使用リソースへの 適切なアクセス権限が必要 適切なアクセス権限が必要 仮想アプリケーション・パターンの場合 パターン・デプロイヤー （デフォルト） パターン作成者 運用者 監視者 新規作成 仮想 アプリケーション パターン 読み取り 読み取り デプロイ インスタンス 管理 監視：読み取り 開始・停止：書込み 読み取り パターン・インスタンス アプり サーバー OS 基本OS イメージ パターン プラグイン テンプレート 環境プロファイル DB サーバー アプり サーバー 管理者 （ワークロード・リソース権限） プラグイン/ パターン・テンプレート等 の登録 36 環境プロファイル 管理者 環境プロファイル 作成 © 2013 IBM Corporation 同様に、アプリケーション・パターンの作成、デプロイ、運用における、必要なユー ザーのアクセス権限について述べます。 まず、仮想アプリケーション・パターンの元になる、基本OSイメージ、プラグイン、 パターン・テンプレートの管理権限は、管理者としてワークロード・リソース権限が 必要です。 仮想アプリケーション・パターン作成者は、ワークロード・リソース権限を持つ管理 者に、これらのコンテンツに関する読み取り権限をもらう必要があります。 デプロイ以降は、仮想システム・パターンと同様です。 36 管理者の権限 管理者権限の対象 それぞれの対象について、次のいずれかの権限 管理 (全アクセス権) 表示 (読み取り専用) 委任の許可 37 ワークロード・リソース（Workload Resource） クラウド・グループ（Cloud Group) ハードウェア(Hardware) 監査(Auditing) セキュリティー(Security) “委任の許可”ユーザーは、自身の持つパーミッションレベルを他のユーザーに与 えたり、削除する事が可能 “委任の許可”ユーザーは最低１つの “管理” パーミッション・レベルをもつ必要が ある © 2013 IBM Corporation 参考までに、PureApplicationの管理者権限で。基本OSイメージや、システム・プラ グインの管理にはワークロード・リソース権限が必要です。 37 （参考）管理者の権限 設定 対象リソース ワークロード・リソース ワークロード管理対象すべて – デプロイ、パターン作成、プロファイル作 成、カタログのコンテンツ作成、IBM License Metric Toolの構成 クラウド・リソース クラウド・グループ, IPグループ, ストレージ・ボリューム, 仮想アプライ アンス, 仮想マシン・グループ, 仮想マシン 共有サービス 全てのデプロイの管理モニタリング (デプロイに対するモニター・アドミ ニストレーター) ハードウェア・リソース 以下の管理または構成: 全てのH/Wリソース - (計算ノード, 管理ノード, ストレージ・デバイス), ネットワーク・デバイス, 外部アクセス・ネットワーク, システム設定 システム・メンテナンスの適用 全てのH/Wモニタリング マシン・レポートの表示 サービス・パネルへのIBM特権ログイン 監査管理 外部システムに監査ファイル・パッケージを提示することができる 監査ファイル・パッケージの読み込みとダウンロードができる 38 © 2013 IBM Corporation 参考までに、各権限の詳細です。 38 （参考）管理者の権限（セキュリティ管理権限） セキュリティー管理権限の設定 ユーザー/グループの表示 (読み取 り専用) 実行可能なアクション ユーザーとグループを表示できる。ただしそれらの 設定の変更はできない。 すべてのセキュリティー・リソースの 全てのセキュリティー・リソースを表示できる。ただし 表示 (読み取り専用) それらの設定の変更はできない。 セキュリティー管理 (全アクセス権) 全てのセキュリティー・リソースの設定と変更ができ る。ユーザー・アカウントおよびユーザー・グループ の追加、変更、削除ができる(LDAPグループ・メン バーシップは、LDAPセキュリティー・アドミニストレー ターが制御する) 39 © 2013 IBM Corporation 参考までに、管理者権限のうち、セキュリティ管理権限の内容です。 39 まとめ 40 © 2013 IBM Corporation まとめです。 40 まとめ 41 企業システムに求められる一般的要件のほかに、クラウド固有の要件が存在 企業システムに求められる一般的要件のほかに、クラウド固有の要件が存在 マルチテナンシー マルチテナンシー エラスティシティー エラスティシティー アジリティ アジリティ 効率的リソース共有 効率的リソース共有 サービス継続性 サービス継続性 要件と制約に基づきPureApplicationを設計 要件と制約に基づきPureApplicationを設計 クラウド・グループ クラウド・グループ IPグループ IPグループ 環境プロファイル 環境プロファイル ユーザー/グループ ユーザー/グループ © 2013 IBM Corporation 企業クラウド基盤には、クラウドならではの要件があり、それが、PureApplicationで、 どう実現できるか？ をお話しました。 41 参考資料 IBM PureApplication System W1500 / W700 Information Center http://pic.dhe.ibm.com/infocenter/psappsys/v1r1m0/index.jsp IBM PureApplication System デザイン・ワークショップ http://www.ibm.com/developerworks/jp/websphere/library/pureapp/ipas_design_ ws/ developerWorks：「IBM PureApplication System のセキュリティーと信頼」 http://www.ibm.com/developerworks/jp/websphere/techjournal/1212_chao/1212 _chao.html developerWorks：「Managing administrative access in IBM PureApplication System」 http://www.ibm.com/developerworks/websphere/library/techarticles/1211_woolf/1211_wo olf.html 42 © 2013 IBM Corporation 42 ITを、もっと手早くカンタンに。 43 © 2013 IBM Corporation 43