1 クラウド管理 - 概要

この章では、クラウド管理およびOracle Cloudプラットフォームが提供する各種のサービスやコンポーネントの概要を説明します。

また、クラウド要件を計画する際に便利な統合プランナ、およびリソース管理、メータリング、チャージバック・サポートなどのOracle Enterprise Managerの様々なライフ・サイクル管理機能についても説明します。

この章の構成は、次のとおりです。

• クラウド管理の概要

• Enterprise Managerによるクラウド管理ライフサイクルの管理

• Oracle Cloudサービス・モデルの概要

• Oracle Cloud機能へのアクセス

クラウド管理の概要

企業およびクラウド・サービス・プロバイダは、Oracle Enterprise Managerを使用してクラウド・サービスを構築し、運用できます。Enterprise Managerによって提供される機能はクラウドのライフ・サイクル全体に渡り、どのようなタイプのクラウド・サービスでも、その設定および管理が可能です。

企業は、増大するビジネス上の需要を満たすために、数百あるいは数千にものぼるアプリケーションをサポートする必要があります。この増大により、サーバーおよびストレージの取得と管理のコストは跳ね上がりました。クラウドにより、お客様は、サーバー、ストレージおよびデータベースのワークロードを共有ハードウェアおよびソフトウェアのインフラストラクチャに統合できます。

セルフ・サービス、伸縮自在の拡張性および従量制によるサーバーやストレージへのオンデマンド・アクセスの提供により、Enterprise Managerでは次の利点を提供します。

• サービスのクオリティの向上: IT組織は、コストを削減しようとするだけではなく、それと同時にサービスのクオリティの向上、パフォーマンス、機能およびセキュリティという観点からソリューションを考えています。クラウドのコンシューマは、クラウドに内在する高可用性という特性そのものから利益を得ます。

  組織は、標準化されたプロビジョニングの一環として、統合された個人情報およびセキュリティのインフラストラクチャを実現できます。これらのポリシーおよびコンプライアンス規定は、後から追加されたようなセキュリティ・ポリシーではなく、プロビジョニング・プロセスの一環です。

• より迅速なデプロイメントが可能: 標準的なビルディング・ブロック・コンポーネント(たとえば、サーバー、CPU、ストレージ、ネットワーク)、標準的な構成およびツールを使用したクラウド・インフラストラクチャの構築により、合理化され、自動化された簡素なデプロイメント・プロセスが可能になります。

• リソースの伸縮性の提供: 記憶域サイズおよび計算能力という2つの面で、データベースの許容量を拡大および縮小する機能により、アプリケーションは本質的に絶えず変化するビジネスのワークロードに合せる柔軟性を持つことができます。

• 迅速なプロビジョニング: クラウド内のデータベースは迅速にプロビジョニングでき(多くの場合はセルフ・サービス・インフラストラクチャを介して)、機敏なアプリケーションのデプロイメントが可能になります。これにより、本番アプリケーションのデプロイメント、プラットフォームのデプロイメントまたはテスト・ベッド構成の作成にかかる全体の時間を削減できます。

Enterprise Managerによるクラウド管理ライフサイクルの管理

Enterprise Managerには次のような機能があり、クラウドのライフサイクルの全体を管理できます。

• 計画
• クラウドの設定
• クラウドの構築
• サービスのテストおよびデプロイ
• クラウドの監視および管理
• メータリングとチャージ、最適化

計画

Enterprise Managerを使用すれば、既存のデータ・センターをクラウド環境に変換できます。クラウドを設定する前に、物理および仮想ネットワーク、ストレージ・アレイ、アプリケーションなどのインフラストラクチャの要件の計画を立てる必要があります。

Enterprise Managerの統合プランナは、管理者がクラウドのアーキテクチャを計画するのに役立つ強力なツールです。これにより、ソースと宛先のターゲットを識別し、アプリケーションをどこに配置するかなど、適用可能な技術、および機能的な制約を判断できます。物理から仮想(P2V)、物理から物理(P2P)、物理からExadataといった移行計画を含む統合アドバイザを生成できます。統合プランナはまた、Database-as-a-Service(DBaaS)を設定するときに役立つ、データベースの統合プランの確認にも使用できます。

クラウドの設定

Enterprise Managerは、Infrastructure-as-a-Service (IaaS)、およびDatabase-as-a-Service (DBaaS)クラウドのモデル化に使用できます。ユーザーや組織の必要に合った適切なクラウド・サービス・モデル(「Oracle Cloudサービス・モデルの概要」を参照)を選択することが重要です。クラウドの設定を容易にするために、Enterprise Managerでは、物理および仮想の両方のインフラストラクチャ用の機能を提供しています。

物理インフラストラクチャの場合、Enterprise Managerでは、基本的なデプロイメント・プロシージャ、ジョブ・システムおよびエンタープライズ・ソフトウェア・ライブラリの自動化フレームワークを活用します。データベースとミドルウェアの両方に事前に必要なソフトウェアをプロビジョニングするために、即時利用可能なデプロイメント・プロシージャが用意されています。同じ自動化フレームワークは、データ・クローニングとストレージ管理の目的で、サード・パーティのストレージ・システムとの対話にも使用されます。仮想インフラストラクチャの場合は、ハイパーバイザーのベアメタル・プロビジョニングと、サーバーおよびストレージのプール設定を提供します。完了すると、これらすべてを機能やQoS特性に基づくゾーンに分類できます。Enterprise Managerでは仮想化ストレージ接続テクノロジを活用し、クラウド設定プロセスをNetapp、日立、富士通などのストレージ・テクノロジと統合します。管理者は、データベースおよびミドルウェア・プラットフォーム用に標準化されたサービス・テンプレートを定義して、これらをサービスとして公開できます。これらのサービスは、単一階層のテンプレートまたは複合的な多階層のエンタープライズ・プラットフォームとして表現されます。

Enterprise Managerは、ロール型のアクセス制御をサポートします。リソース制限、すなわち割当て制限が、サービスへのアクセスを制御するためにロールに割り当てられます。これはサービスの不正な使用を防ぎ、その一方で少数のユーザーがクラウドのリソースの大部分を使用することを防ぎます。LDAPとの統合により、Enterprise Managerでエンタープライズ・ロールの継承が可能です。

クラウドの構築

Enterprise Managerでは、アプリケーションまたはコンポーネントの全体をパッケージ化し、サービスとしてクラウドに公開できます。これは、組織内におけるアプリケーションの開発およびプロビジョニングのプロセスを促進します。

開発者は、ユーティリティ・コンポーネントおよびアプリケーションを、グループ内で再利用可能なアセンブリおよびサービス・テンプレートという形態で公開できます。同様に、アプリケーションをアセンブリとして使用可能とすることで、テスト・チーム、ビジネス解析または製品チームは、数クリックの操作で事前作成アプリケーションをデプロイできます。

サービスのテストおよびデプロイ

アプリケーションを構築したら、テストが必要です。Enterprise Managerでは、アプリケーションの変更とデータベースの変更の両方をテストできる、テスト用のポートフォリオが提供されます。

このテスト・ソリューションにより、テスト環境で製品のロードおよびリプレイを取得でき、結果が予測可能となります。また、テクノロジ・レイヤーに組み込まれた診断機能を利用して、修正のための処方箋を提供します。

Enterprise Managerは、エンド・ユーザーがサービスをデプロイできるようにするセルフ・サービス・アプリケーションを提供します。このセルフ・サービス・アプリケーションはカスタマイズ可能です。エンド・ユーザーは、データベースおよびプラットフォームとともに、プロビジョニングするアプリケーション・アセンブリをオンデマンドで選択できます。リクエストごとに、それぞれのコンポーネントが必要とするCPU、メモリーなどの基礎となるリソースの量を指定できます。Enterprise Managerでは、リクエストされたサービスおよび適切なリソースが自動的にプロビジョニングされます。セルフ・サービス・アプリケーションでもまた、ユーザーは、スケジュールまたはパフォーマンス・メトリックに基づいて、リソースのスケール・アウトまたはスケール・バックのポリシーを定義できます。

クラウドのモニタリングおよび管理

Enterprise Mangerには、多数の固有のモニタリングおよび管理機能があり、これが集合的にクラウド全体の管理システムを構成しています。

たとえば、Enterprise Managerには、ターゲットをグループに照合し、管理を容易にする機能があります。この管理グループ機能により、管理者は、テンプレートを介してモニタリング設定、コンプライアンス標準およびクラウド・ポリシーを定義でき、また、それぞれのターゲットをライン・オブ・ビジネス、ライフサイクルのステータスといった複数の階層に組織化できます。これにより、モニタリング・フレームワークは、クラウド内の何千ものサーバー、データベースおよびミドルウェア・ターゲットを対象にできます。

Enterprise Managerに組み込まれたインシデント管理システムにより、クラウドでパフォーマンスに影響を与える可能性のある複雑な操作上の問題をモニターできます。必要に応じて、発生するイベントの確認、抑止、エスカレート、処置ができ、インシデントのエスカレーションを既存のサポート・チケット発行システムにも統合できます。詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。契約上のサービス・レベル合意(SLA)は、アプリケーションの所有者とクラウドのプロバイダ間の契約を管理するように定義できます。管理者は、ユーザーと同様、サービスのリソースがSLAに合致することを保証するように自動的に調整されるような管理ポリシーを定義できます。

Enterprise Managerの構成管理機能は、クラウド環境用に最適化されています。たとえば、Enterprise Managerでは、膨大な数の構成を継続的にモニターすることで、変更を発見し、変化を測定し、構成エラーの箇所を特定して、システムのトポロジについて見通すことが、すべて1つのコンソールでできます。Enterprise Managerのクラウド管理機能は、My Oracle Supportとも統合されています。この統合により、クラウド全体の場所や文脈に即応したパッチ・アドバイザ、サービス・リクエスト管理、ナレッジ管理などの機能が提供されます。

Enterprise Manager Cloud Controlユーザー・インタフェースで提供されるIaaSおよびDBaaSのホームページで、クラウド管理者は、リクエストのサマリー・ビューおよびゾーン、プール、サーバー、サービス・インスタンス、データベースなどのサービスの一般的な状態を取得できます。

メータリングとチャージ、最適化

Enterprise Managerのメータリングおよびチャージバック機能により、企業は実際の使用状況と代表的な使用状況との対比を明らかにできます。管理者はまた、固定コスト、構成、管理費、人件費、エネルギ消費、またはこれらの組合せの明細を明らかにするように価格モデルを拡張できます。クラウド管理では、サービス・レベルが永続的であることを保証するために、リソースおよびプロセスの持続的な最適化も必要です。Enterprise Managerでは、管理者およびアプリケーション・ユーザーに対し、資産の再発見、パフォーマンスの再評価、クラウドのリバランス、プロビジョニング・プロセスのチューニングに役立つ機能が提供されます。チャージバックでは、CPU、メモリー、ストレージの使用状況などの基本メトリックをサポートしています。また、アプリケーションの使用状況、データベースの使用状況およびミドルウェアレベルのメトリックに基づく価格モデルも提供します。

Oracle Cloudサービス・モデルの概要

この項では、使用可能なOracle Cloudサービス・モデルについて説明します。

• Oracle Cloudサービス・モデル

• Oracle Cloudの構造

• IaaSコンポーネント

• DBaaSコンポーネント

Oracle Cloudサービス・モデル

OracleのCloudサービス・モデルは、ユーザーがアプリケーションの実行に必要な物理インフラストラクチャをリクエストできるようにするInfrastructure as a Serviceと、アプリケーションに必要なデータベースのコンポーネントを提供するPlatform as a Serviceという2つの主なカテゴリに分類できます。

• Infrastructure as a Service (IaaS)サービス・モデル: IaaSモデルでは、ユーザーは、ゲスト仮想マシン(ゲストVM)として作成されるサーバーをリクエストします。

  IaaSモデルでユーザーは、Enterprise Managerのセルフ・サービス・ポータルを使用してゲストVMをリクエストできます。またユーザーは、リクエストしたゲストVMにデプロイするアセンブリまたはテンプレートを指定できます。オペレーティング・システム、データベース・ソフトウェアおよびミドルウェア・ソフトウェアで構成される事前パッケージ済のアセンブリがあり、プラットフォームはこのサービスを使用してデプロイされます。

  ユーザーは、セルフ・サービス・ポータルを使用し、提供されるサービスをモニターでき、許可されている管理操作を実行できます。また、チャージバック・レポートを実行して、リソースの使用状況と、消費リソースに対して計算されたチャージバックの額を確認できます。

  IaaSクラウド・インフラストラクチャは、Oracle VM、Oracle Solaris、Oracle Enterprise LinuxなどのOracleのハードウェアおよびソフトウェア・コンポーネントで構築でき、サード・パーティのコンポーネントを使用することもできます。

• Platform as a Service (PaaS)サービス・モデル: PaaSモデルでは、コンシューマが独自のアプリケーションをデプロイできるプラットフォームを作成できます。プラットフォーム・リソースは通常、ホスト、オペレーティング・システム、Oracle WebLogic Applicationサーバーで構成され、これらはすべて仮想化できます。OracleデータベースまたはRACクラスタを含めることもできます。

  PaaSで使用可能なモデルには、次のものがあります。

  • Database as a Service (DBaaS)サービス・モデル: このモデルでユーザーは、セルフ・サービス・ポータルを介して、データベース・サービス(1のインスタンスまたはRAC)をリクエストできます。DBaaSは次のようなオプションで実装されます。

    • 仮想マシン・ベース: データベースは仮想アセンブリまたはテンプレートの一部としてデプロイされ、それぞれの仮想マシンは同じ物理サーバーを共有します。これにより、最大レベルの独立性(オペレーティング・システム・レベル)が提供されます。

    • 共有クラスタ: データベースは既存のクラスタウェアにデプロイされます。通常、グリッド・インフラストラクチャ(Oracle Clusterware、ASM)およびデータベース・ソフトウェアは、あらかじめインストールされます。クラウド・サービスは、基本的にそのインフラストラクチャの上にデプロイされるデータベースで構成されます。

    • 共有インストール: データベースは、既存のデータベース・インストール上にシングル・インスタンスのデータベースとしてデプロイされます。

    • Pluggable Database as a Service: プラガブル・データベースがデプロイされます。このモデルでは、高度な統合が提供され、管理とメンテナンスのオーバーヘッドは最小化されます。

    • スナップ・クローン: データベースのコピー・オン・ライト・テクノロジを使用して、シン・クローンを作成できます。このモデルでは、最小限の領域で即座にクローニングが実行されるため、機能テストに最適です。

    • フル・クローン: データベースの全体コピーを作成できます。このモデルは、重要なデータ更新のあるロード・テストに最適です。

    • 共有データベース(Schema as a Service): データベース・サービスは、既存のデータベース上のスキーマ・デプロイメントです。データベースのそれぞれのコンシューマは、データベースにアクセスしてそれぞれが異なるサービスを使用するものと想定し、そのメータリングおよびチャージバックを目的とします。このサービス・モデルは、Schema as a Serviceとも呼ばれます。

    IaaSと同様に、ユーザーは、データベースの起動/停止、バックアップおよびリカバリなどの一部の管理タスクを実行できます。セルフ・サービス・ユーザーは、チャージバック・レポートも使用可能です。

Oracle Cloudの構造

Oracleの実装では、クラウドは論理ゾーンで構成されます。ゾーンは論理プールから構成され、プールはホスト上のターゲットから構成されます。

IaaSゾーン内の論理プールは、1つ以上のOracle VM Serverとそれらの関連ストレージ・リソースの集合です。DBaaSゾーン内のプールは、同じプラットフォームとバージョン(Oracle Linux 6 x86-64上のOracle Database 12.2.0.1 RACなど)の1つ以上のOracle Databaseホーム(データベース・リクエストに使用)またはデータベース(スキーマ・リクエストに使用)、または同じプラットフォームとバージョン(Linux x86-64上のOracle Database 12.2.0.1など)のOracle Middlewareホームの集合です。

IaaSまたはPaaSのいずれでも、セルフ・サービスのユーザーは、カタログ・テンプレートからゾーン・レベルでリソースをリクエストします。次に、Enterprise Managerでは、リクエストを満たすために、選択されたゾーンのどのプールが使用できるかを決定します。必要とされるEnterprise Managerのジョブは、選択されたプール内の1つ以上のホストで開始され、リクエストを満たすために必要なエンティティを作成します。

IaaSクラウドでは、セルフ・サービスのユーザーがサーバーの作成をリクエストします。これらは実際にはゲスト仮想マシン(ゲストVM)です。1つのIaaSリクエストの結果、データベース、ミドルウェア・ソフトウェアおよびデプロイ済のアプリケーションを備えた1つ以上の仮想マシンが作成されます。

DBaaSビューでは、新規データベースまたは既存データベースのスキーマの作成をリクエストできます。PDBaaSビューでは、新規プラガブル・データベースをリクエストできます。

データベースは、ユーザーがアクセスするゾーンやカタログ・テンプレートに応じて、1つのインスタンスまたはRACになります。

図1-1に、クラウドの構造を示します。

図1-1 クラウドの構造

IaaSコンポーネント

IaaSクラウド・モデルは、次のコンポーネントで構成されています。

• クラウド: クラウドは、クラウド・コントローラによるプログラム的な制御およびクラウド管理者による管理の下にある、ストレージ・プール、サーバー・プール、ゾーンのセットです。クラウド管理者はコスト・センター管理者と協力して働き、コスト・センター管理者は、クラウドのリソース割当てを決定し、必要なチャージバック・ポリシーを決定することがその仕事です。

• ゾーン: クラウドは、1つ以上のゾーンで構成されます。ゾーンは、セルフ・サービスのプロビジョニングおよび管理を容易にするサーバー、ストレージ・エンティティなど、リソースの論理的なグループです。通常のゾーンは、数百から数千のサーバーで構成されます。

  空のゾーンまたはサーバー・プールのセットからなるゾーンを構成できます。2つ目のケースは設定が単純で共有のストレージを必要としませんが、そのようなゾーンではHAおよびライブ・マイグレーションが許可されません。

  ゾーンは重なり合うことはなく、あるリソースは1つのゾーンにのみ所属します。しかし、ゾーン内のリソースには、別のゾーンからアクセスすることも可能です。たとえば、ゾーン1の仮想マシンは、別のゾーンの仮想マシンと対話できます。

• サーバー・プール: サーバー・プールは、密結合のサーバー・グループ(通常は最大32サーバー)であり、ゲストVMのセットをホストします。複数のサーバーは、機能性および接続性において、大きな均一なものとみなされます。高可用性およびライブ・マイグレーションは、サーバー・プールを境界として許可されます。各サーバー・プールは、ライブ・マイグレーションを容易にするため、共有ストレージ・サブシステム(単なるNFSのマウント・ポイントでかまいません)へのアクセスを必要とします。さらに、HAのハートビート・ファイルを保持するため、クラスタ化されたファイル・システムへのアクセスが必要となることもあります。

• ストレージ・エンティティ: ストレージ・エンティティは、個別のファイル・システムまたはブロック・ストアです。各ストレージ・エンティティは、ストレージ・プールによって供給されます。自立型のエンティティは、それが削除されるまで存在します。1つ以上のゲストVMに関連付けられているその他のストレージ・エンティティは、VMがリタイアするときに削除されます。

• ストレージ・プール: ストレージ・プールは、ストレージ・エンティティのセットをホストする抽象的なストレージ・システムです。ストレージ・プールは、通常、ディスク、SSD、ストレージ・サーバーなどのストレージ・デバイスのセットを使用して実装されます。

DBaaSコンポーネント

DBaaSクラウド構造は次の要素で構成されます。

• PaaSインフラストラクチャ・ゾーン: PaaSインフラストラクチャ・ゾーンは、ホストのグループです。ゾーン内の各リソースは、サービス・インスタンスをデプロイする場所を表します。

  DBaaSを有効化または設定する前に、PaaSインフラストラクチャ・ゾーンを作成し、このゾーンを使用可能な特定のターゲット・セットおよびユーザーの配置ポリシー制約を定義する必要があります。

• ソフトウェア・プール: ソフトウェア・プールは、同種のリソースのセットです。DBaaSのソフトウェア・プールを作成できます。DBaaSで作成されるデータベース・プールは、選択したクラウド・サービス・モデルのタイプに応じたデータベース・ホーム、データベースまたはコンテナ・データベースのコレクションです。

  ソフトウェア・プールには、次の制約があります。

  • ターゲットは1つのソフトウェア・プールにのみ属することができます。
  • ソフトウェア・プールの作成後は名前とバージョンを変更できません。
  • ソフトウェア・プール内のすべてのターゲットは同種である必要があります。
  • 1つのサービス・テンプレートで複数のゾーンを使用できますが、各ゾーン内では1つのソフトウェア・プールしか使用できません。
• データベース・プロビジョニング・プロファイル: データベース・プロビジョニング・プロファイルは、プロビジョニングのソース・データベース情報を取得するエンティティです。プロファイルは、完全なデータベースまたはアプリケーションを形成する一連の関連するスキーマを表すことができます。
• サービス・テンプレート: サービス・テンプレートは、データベース、スキーマまたはミドルウェア・サービスを作成するためにセルフ・サービス・ユーザーに提供される標準化されたサービス定義です。

Oracle Cloud機能へのアクセス

Oracle Cloud機能には、標準のEnterprise Managerコンソールか、やはりEnterprise Managerの一部であるセルフ・サービス・ポータルのいずれかからアクセスします。

Enterprise Managerのその他の機能へのアクセスは制限されています。これにより企業は、インフラストラクチャ全体をエンド・ユーザーに公開することなく、安全にクラウドを実装できます。

Enterprise Manager Cloud Controlのコンソール

管理者は、Enterprise ManagerのCloud Controlコンソールを使用してクラウド・サービスの設定、モニター、管理を行います。各サービスは、それぞれのサービス専用のページを使用して管理されます。たとえば、IaaSおよびDBaaSには、クラウドの概要ページまたはEnterprise Managerのメニューから直接アクセスできる独自のページがあります。

Enterprise Managerのクラウドの概要ページには、すべてのクラウド・サービスの概要を表示する単一のペインがあります。Enterprise Managerでは、抽象化レイヤーを使用でき、その下にあるアプリケーションの複雑さをエンド・ユーザーに隠すことができます。この抽象化は、グラフィカル・ユーザー・インタフェース(GUI)およびアプリケーション・プログラミング・インタフェース(API)の2つのセルフ・サービス・インタフェース経由で提供されます。

セルフ・サービス・ポータル

クラウド・インフラストラクチャを直接管理できるように、Enterprise Managerでは即時利用可能なセルフ・サービス・ポータルが提供されており、セルフ・サービス・ユーザーは、ITスタッフの手を借りずにクラウド・サービス(プロビジョニング・アプリケーション)にアクセスできます。オンデマンド・プロビジョニング用に事前パッケージ済の仮想アセンブリおよびテンプレートが提供され、サービスおよびリソースの使用状況を追跡でき、チャージバック・レポートおよびキャパシティ・プランニングに使用できるデータが提供されます。

セルフ・サービス・ポータルは、セルフ・サービス・ユーザー向けのホーム・ページです。必要な権限を持つユーザーは、適切なラジオ・ボタンをクリックすることで、サービス・ページ間を移動できます。ポータルをどのように使用するかは、管理しているサービスのタイプによって異なります。