従来のデータ・センターと同じように、クラウドの場合でも Cognos をデプロイするには複数のマシンが必要になることがあります。そうなると、クラウド・ソリューションにも複数のイメージが必要になってきます。この場合、パフォーマンス、スケーラビリティー、そして高可用性などの基準から、最終的に複数イメージのトポロジーとなるのが通常です。この記事では、このような複数のイメージからなるトポロジーに適用されるベスト・プラクティスについて説明します。

この記事は、クラウドでの Cognos に関するベスト・プラクティスと、インストールおよび構成のポイントを説明する連載の第 1 回です。この連載では Cognos 8 を使用します。

複数のソフトウェア・イメージを使用する際のベスト・プラクティス、そしてパフォーマス、スケーラビリティー、高可用性に関する問題について取り上げる前に、まずはクラウドとワークロード、そして Cognos 8 ではクラウドの威力をどのように利用できるかについて説明します。

Cognos 8 BI: シートベルトをお締めください

まず、IBM Cognos 8 BI に馴染みのない読者のために、この製品について簡単に説明しておきます。

IBM® Cognos® 8 BI (Business Intelligence) は、IBM Information Management 製品ファミリーのメンバーです。あらゆる種類のソフトウェア (Cognos BI の他に、DB2®、Cloudscape、InfoSphere™、Optim™、FileNet®、Informix®、OmniFind® などがあります) を取り揃えた IBM Information Management は、分析、データ/データベース管理、エンタープライズ・コンテンツ/コンプライアンス管理、メッセージングとコラボレーション、そしてポータルとマッシュアップなど、あらゆる種類のタスクに対応します。IBM のビジネス・アナリティクスの分野は、Cognos ソフトウェアと SPSS の統計分析ソフトウェアでなりたっています。

IBM Cognos 8 BI を構成する主要なタスク指向のコンポーネントには、以下の 4 つがあります。

1. IBM Cognos 8 BI レポーティング: レポーティングのライフサイクルに関連するすべてのコンポーネントを 1 つの Web ベースのソリューションに統合し、一連のレポート作成機能を提供します。例えば、以下の機能があります。
   • セルフサービスのレポーティング機能により、IT 部門を煩わせることなく、ユーザーがそれぞれに必要な情報を取得することができます。
   • 一度作成すれば、どこからでもアクセスできるレポーティング機能により、IT 部門はユーザーがさまざまな機器からアクセス可能な 1 つのレポートを作成するだけで済みます。サポートされる言語は 25 を超え、さまざまな出力形式にも対応します。この機能には、他のアプリケーションやプロセスからアクセスすることも可能です。
2. IBM Cognos 8 BI 分析: データが保管されている場所に関わらず、対話形式で情報を調べることができます (オンライン分析処理およびディメンション構造を持つリレーショナル・ソースが対象となります)。複雑な問題の分析を素早く簡単に実行できることから、処理の概要レベルとトランザクション・レベルの詳細との間をスムーズに移動しながら、重要なデータを見つけることができます。 また、カスタマイズ可能な組み込み時系列分析機能を用いて、企業内でのビジネス・イベントの変遷を写真のように詳細かつ高度に示すチャートを作成することもできます。
3. IBM Cognos 8 BI ダッシュボード: データが伝えようとしている内容が一目でわかるように表示することによって、パフォーマンスのモニター、測定、管理を支援します。これらの表示は、小さな異常が大きなビジネス問題に発展する前にその異常を見つけ出すための重要なツールとなります。ダッシュボードは、表示の詳細レベルを調節したり、出力形式をさまざまに変更したりして、自分にとって使用しやすいようにカスタマイズすることができます。
4. IBM Cognos 8 BI スコアカード: ダッシュボードから取得したレポートを分析して評価指標に変換し、その結果を基に、将来を見通した戦略を立てられるようにします。さらに、それぞれのアクションの結果を測定できるようにするための評価指標を作成するスコアカードは、戦略を他の人々に伝達する上でも役立ちます。このコンポーネントはいわば操作の中央司令部として、以下の機能を備えています。
   • スコアカードの各評価指標には所有者を割り当てることができます。
   • スコアカードには、戦略マップ全体のなかでのそれぞれの優先順位に応じてランクを付けることができます。
   • 各スコアカードに BI 機能を組み込み、変化のスピードが速い状況のなかで現状に即した分析に対応することができます。
   • 戦略マップという大局のなかでスコアカードを検討し、全体的な計画の進化に各スコアカードが適合しているかどうかを容易に判断することができます。

上記の他、Cognos 8 BI を拡張するために使用できる各種のコンポーネントがあります。

上に戻る

Cognos 8 BI: 雲 (クラウド) のなかへ

ビジネス・アナリティクス・ソフトウェアの威力とクラウド・コンピューティングのスコープは明らかに絶好の組み合わせであると誰もが思うはずです。この 2 つが共に目指すのは、いずれも従来のシステムによって課せられてきた過去の制約を打ち破ることにあります。

• クラウド・コンピューティングは、データ・リソースの共有を可能にして同じ 1 つのマシンですべてのデータ・リソースをホストする必要をなくすことによって、仮想リソースと物理リソース両方のストレージに関する制約を克服することを目指しています。CPU のピーク使用量の問題を解決するために採っている手段は、クラウド内 (場合によってはクラウド外) のさまざまなシステムでワークロードを分散することです。アクセス・コストの問題を解決するためには、事前定義されたアプリケーション・テスト・システムと生産性アプリケーションを必要に応じて使用可能にするという手段を採っています。
• ビジネス・アナリティクスは、傾向および異常を突き止めるという労力のかかる作業を人間の手から解放し、自動化します。ビジネス・アナリティクスでは、データを情報へと変換し、人々が容易に傾向を捉え、発見された事実を共有できるように、データの「可視表現」を作成します。また、情報を知識に変えることで、考えられる解釈/ソリューションの組み合わせを提供し、人々が最も重要なタスクに専念できるようにします。そのタスクとはつまり、「この先、どの方向に進むべきか」という質問に対する答えを出すことです。

この連載の内容

この連載では私たち自身の経験に基づいたベスト・プラクティスを説明します。具体的には、以下に関するベスト・プラクティスです。

• パフォーマンス、スケーラビリティー、高可用性などの基準に基づく、複数のイメージを使用した Cognos クラウド・トポロジーの管理。既存の hosts ファイルを使用した複数のイメージの管理、異なるクラスター・サイズへのスケール・アウト、専用イメージを使用したスナップショットの作成、そして必要とされるファイルを保管するのに適した場所について説明します。
• パフォーマンスとスケーラビリティーに応じたアーキテクチャーのサイズ変更。ユーザー・コミュニティーと地理的分散によるパフォーマンスへの影響、そしてアプリケーションの複雑さがパフォーマンスへ及ぼす可能性のある影響について説明します。さらに、デプロイ後のスケーラビリティーに関する一般規則についても説明します。
• 高可用性をもたらすための設定の選択。高可用性をもたらし、障害から回復しやすくするために推奨されるクラウドでの Cognos のセットアップ方法と保守方法を説明します。これには、Cognos ゲートウェイと Cognos アプリケーション・サーバー、現用モードと予備モード両方での Cognos Content Manager、および IBM DB2 HADR (High Availability and Disaster Recovery) の使用方法も含まれます。
• 一般的なトポロジー、セキュリティー、およびデータに関する考慮事項。各種のワークロードおよび要件に応じたデータ、クエリー・データベース、および認証ソースの保管場所について説明します。

Cognos 8 BI/IBM Cloud (IBM Smart Business Development and Test on the IBM Cloud) に特有のセキュリティーに関するベスト・プラクティスおよびインストールのオプションについては、読者の皆さんの要望に応じて、今後の記事で取り上げます。

この連載の手始めとして、トポロジーを設計およびテストする際に考慮しなければならない項目を以下に要約します (すべてを網羅したリストではありません)。

クラウドに取り掛かる際の 4 つのポイント

トポロジーを設計および改良する際には、以下のことを心掛けてください。

1. 最初は単純なトポロジーから始めます。要件を満たすだけにして、必要以上に複雑なトポロジーにはしないでください。
2. トポロジー内のクラウド・インスタンスの数は常に最小限に抑えるようにします。インスタンスを追加するのは簡単なので、最初は必要となるインスタンスの数を低く見積もってください。
3. 上記 2 番目の助言は、固有のクラウド・イメージの数についても当てはまります。例えば、起動時に自己カスタマイズする単一の DB2 データベース・イメージを管理するほうが、5 種類のクエリー・データベース・イメージを作成するより簡単です。
4. トポロジーを設計してテストするプロセスは、以下のように繰り返しのプロセスでなければなりません。
   1. トポロジーを設計/改良する。
   2. 必要なインスタンスを作成/カスタマイズする。
   3. インスタンスをインストール/構成する。
   4. イメージのスナップショットを保存する。
   5. 機能とパフォーマンスをテストする。
   6. 最初のステップから繰り返す。

ここからは記事の本題として、複数イメージのクラウド・トポロジーを管理するためのベスト・プラクティスに話題を移します。

上に戻る

ベスト・プラクティス: hosts ファイルを使用して複数のイメージを管理する

複数のクラウド・イメージを使用する場合には、これらのイメージに関連付けられた複数のさまざまな IP アドレスを扱わなければなりません。

ホスト名は、論理名と IP アドレスを 1 つの対にします。ホスト名は多くの場合、DNS サーバーによって保管され、プログラムによってホスト名を IP アドレスに、またはその逆にマッピングできるようにします。例えば、予備の Content Manager バージョン 10.3.0.1 の IP アドレスは、ホスト名 cm_standby にマッピングされるようにすることができます。

複雑なソリューションでは、これらのホスト名を管理する内部 DNS サーバーを用意するという方法が適切な場合もあります。けれどもマシンには、オペレーティング・システムがホスト名を IP アドレスにマッピングするために使用する、hosts ファイルとして知られるファイルもあります。大抵は、この hosts ファイルを使用してインスタンスのクラスターを管理するほうが簡単です。

• UNIX® で hosts ファイルが置かれている場所は /etc/hosts です。
• Windows® で hosts ファイルが置かれている場所は \Windows\System32\Drivers\etc\hostsです。

この記事では、すべてのインスタンスは同じクラウドの領域にあり、したがってそれらの IP アドレスは同じクラスのプライベート IP アドレスの範囲であるという前提にします。複数のクラウド・インスタンスが異なる地理的領域にある場合には、IP アドレスの複数のクラスを扱う際の問題も考慮事項に追加されることになるかもしれません。

上に戻る

例: 単一のイメージを使用したエラスティック Cognos 8 クラスター

使用するイメージの数を最小限に抑えると、クラウド・ソリューションの管理は必ず容易になるということを忘れないでください。例えば、Cognos 8 クラウドのデプロイメントには異なる役割 (ゲートウェイ、ディスパッチャー、コンテンツ・マネージャーなど) を持つ複数のインスタンスが必要になることがあります。この場合、単一の汎用イメージを作成し、それをカスタマイズするという方法を採ったほうが、大抵はデプロイメントを管理しやすくなります。

Cognos 8 クラスターには以下の 3 つの論理コンポーネントを組み込むことができます。

• ゲートウェイ
• ディスパッチャー兼コンテンツ・マネージャー
• データベース

このクラスターを構築する 1 つの手法は、以下の 3 つのクラウド・イメージを個別に使用することです。

• ゲートウェイ・イメージ (Cognos および Apache を使用)
• ディスパッチャー・クラウド・イメージ
• DB2 データベース・イメージ

けれども忘れてはならない鉄則は、できるだけイメージの数を少なくすることです。このシナリオでは、すべてのコンポーネントが単一のクラウド・イメージにロードされる場合には生じない難問が、ソリューションを動的にスケーリングする場合に生じることになります。

すべてのソフトウェア・コンポーネント (Cognos 8、Apache、および DB2) を組み込んだ単一のクラス・イメージを出発点にする方法もあります。この単一のイメージから動的にインスタンスを起動するメカニズムを定義して、イメージが動的に拡大するように構成します。

そのための手順には、主に以下の 3 つのステップがあります。

1. 必要なすべてのソフトウェアを単一のクラウド・イメージにインストールする。
2. ホスト名のエイリアスを使用してソリューション・クラスターを構成する。
3. hosts ファイルを使用して、これらのホスト名のエイリアスを実際のインスタンスおよび対応する IP アドレスにマッピングする。

ホスト名のエイリアス

以下のエントリーを含めた hosts ファイルを作成します。

• myCognos: 現在のインスタンスのエイリアスです (localhost と同様)。
• vm-db2: DB2 インスタンスのエイリアスです。
• vm-gateway: Cognos ゲートウェイ・インスタンスのエイリアスです。
• vm-cognos1: 最初の Cognos ディスパッチャーのエイリアスです。
• vm-cognos2 ... vm-cognos10: 使用する可能性のある残り 9 つの Cognos ディスパッチャーのエイリアスです。

デフォルトでは、hosts ファイル内のすべてのエイリアスは localhost (現在のマシン・インスタンスのエイリアス) にマッピングされます。

Cognos 8 構成ツールの「Environment (環境)」タブに、表 1 に記載する設定を入力してください。

表 1 の URI に含まれるポート 9080 (Websphere® Application Server にインストールした場合にディスパッチャーが使用するデフォルト・ポート) は、お使いの環境での適切なポート番号に置き換えてください。例えば、WebSphere Application Server ではなく Tomcat を使用している場合には、ポート番号を 9300 に変更します。

上記の構成設定を使用すれば、インスタンスを起動して hosts ファイルに変更を加えるだけで、インスタンスが 1 つだけのクラスターから、12 ものインスタンスを持つクラスターにまで、クラウド・トポロジーをスケール・アウトできるようになります。

次は、クラスターの構成をサイズごとに見ていきます。

サイズ 1 のクラスター

任意のインスタンスが、単一のサイズ 1 のスタンドアロン・クラスターとして機能することができます。インストールされたすべてのソフトウェア (Cognos 8、Apache、および DB2) は、この単一のインスタンス上で動作します。

サイズ 2 のクラスター

サイズ 2 のクラスターでは、2 つのインスタンスがそれぞれ以下の役割を果たします。

• インスタンス 1 は DB2 の役割を果たします。
• インスタンス 2 は、ゲートウェイ、ディスパッチャー、およびコンテンツ・マネージャーの役割を果たします。

インスタンス 1 に DB2 の役割を割り当てるには、インスタンス 1 の hosts ファイルを以下のように変更します。

インスタンス 2 にゲートウェイ、ディスパッチャー、およびコンテンツ・マネージャーの役割を割り当てるには、インスタンス 2 の hosts ファイルを以下のように変更します。

hosts ファイルで行った変更はすぐに適用されることに注意してください。つまり、ほとんどのオペレーティング・システム (Windows および Linux を含む) では、hosts ファイルにエントリーを追加または更新しても、サービスを再起動する必要はないということです。さらに、これらの変更を適用するために、すでに実行中の Cognos 8 インスタンスを再起動する必要もありません。

サイズ 3 のクラスター

3 番目のインスタンスを起動し、hosts ファイルを変更して以下の役割を割り当てます。

• インスタンス 1 には DB2 の役割
• インスタンス 2 にはゲートウェイの役割
• インスタンス 3 にはディスパッチャー/コンテンツ・マネージャーの役割

インスタンス 3 の hosts ファイルは、例えば以下のように変更します。

サイズ 4 から 12 までのクラスターへのスケール・アウト

サイズ 3 よりも多くのインスタンスを追加してクラスターをスケール・アウトするには、上記で概説した手順を繰り返します。新規インスタンスを追加し、まだ使用していない vm-cognos ホスト名を新規インスタンスの IP に割り当てることによって、インスタンスを追加ディスパッチャーとしてトポロジーにアタッチします。例えば 4 つ目のインスタンスを追加する場合、インスタンス 4 の hosts ファイルを以下のように変更します。

基本的に、クラウド・インスタンスをディスパッチャー・リストに追加することによって、ソリューションを動的にスケール・アウトしていることになります。ディスパッチャー・リストはロード・バランサーとして機能するため、Cognos 8 は Cognos 構成に記載されている順にディスパッチャーに連絡します。

このトポロジーの合計 12 のインスタンスで、ディスパッチャーの数が 10 に制限されているのは、この例ではこのように設定しているにすぎません。ディスパッチャーの数は、それぞれの要件に応じて減らすことも、増やすこともできます。

上に戻る

プライベート・イメージを使用したスナップショットの作成

ソリューションの開発は、必ず IBM Cloud にプライベート・イメージを作成して作業のスナップショットを取りながら行ってください。プライベート・イメージはバックアップとなるだけでなく、イメージのソフトウェア・インストールおよび構成のすべてを記録することから、時間の節約にもなります。

例えば、リポジトリーの変更やセキュリティー/ファイアウォールの設定、そして共通ツールのすべてが含まれるオペレーティング・システムのプライベート・イメージを作成すれば、他のイメージを作成するときにそのプライベート・イメージを出発点として使用できるため、イメージを毎回始めから作成する必要がなくなります。このような基本イメージのスナップショットを用意することをベスト・プラクティスしてお勧めします。

プライベート・イメージに変更を加えると、新しいプライベート・イメージが作成されることになりますが、新しいイメージに保管されるのは、最初のイメージと 2 番目のイメージとの違いだけです。例えば Cognos 8 を基本イメージにインストールした後に新しいプライベート・イメージを作成すると、そのイメージのサイズは遥かに小さくなります。新しく作成されるイメージに永続化しなければならないのは、新しく追加された Cognos 8 ソフトウェアだけだからです。

前述のとおり、プライベート・イメージはスペースを節約するためにイメージ間での変更 (差分変更) しか保管しないため、中間のプライベート・イメージを削除することはできません。例えば、イメージ C はイメージ B をベースとし、イメージ B はイメージ A をベースとしている場合、イメージ C はイメージ B に依存しているため、イメージ B を削除することはできません。従って、IBM Cloud はイメージ B での変更をイメージ A に適用することによって、イメージ C を生成します。

上に戻る

クラウド内でのファイル

IBM Cloud 内のファイルは、2 つの場所に保管することができます。1 つはクラウド・インスタンスに関連付けられたファイルシステム、もう 1 つはマウントされたディレクトリーです。

ファイルを保管できるクラウド・インスタンスに関連付けられたローカル・ファイルシステムは、PC のハード・ディスクのようなものです。各インスタンスのファイルシステムは一時的なものなので、ここに保管されたファイルは一時ファイルと見なされます。インスタンスがシャットダウンされると (あるいはある種の障害が発生すると)、ファイルシステム上に存在している情報は失われることになります。さらに、クラウド・インスタンス内に保管されたファイルには、他のインスタンスからアクセスすることはできません。

IBM Cloud のストレージ・インスタンスのファイルシステムをベースにマウントされたディレクトリーにも、ファイルを保管することができます。このクラウド・ファイルシステムは、複数の PC に接続された NAS (Network Addressable Storage) ユニットに似ていて、ここに保管されたファイルは永続ファイルと見なすことができます。これは、IBM Cloud のストレージがバックアップと冗長性を保証してくれるおかげです。

IBM Cloud のストレージ・インスタンスのファイルシステムにマウントされたディレクトリーに保管されているファイルには、すべてのインスタンスがアクセスして共有することが可能です。ストレージの追加バックアップおよびリカバリー・サービスは、IBM Cloud から別途購入することができます。

クラウド・イメージの外部で保管しなければならないファイル、あるいはクラウド・インスタンスの間で共有する必要のあるファイルについては、IBM のストレージ・クラウドによってマウントされたディレクトリーに保管してください。Cognos 8 の複数イメージのデプロイメントでは、以下のものについてはローカル・インスタンスではなく、マウントされたディレクトリーに保管することを検討する必要があります。

• ファイル・ベースのデータ・ソース
• 共通ソフトウェア
• 共通デプロイメント・スクリプト (複数のプライベート・イメージを変更することなくスクリプトの更新/調整を可能にするため)
• 事前に作成された hosts ファイルおよびその他の構成ファイル (クラウド・インスタンスにコピーするため)
• 重要な監査ファイルまたはログ・ファイルのコピー (元のインスタンスがシャットダウンされてもファイルが残されるようにするため)
• データベースのバックアップ・ファイル

上に戻る

まとめ

この記事で説明したベスト・プラクティスによって、皆さんが複数イメージのクラウド・トポロジーを一層有効に管理して、IBM Cloud で効率的に Cognos を実行できるようになることを願っています。クラウド・コンピューティングの威力にスマートなビジネス・アナリティクス機能を組み合わせることで、競争力のあるアプリケーションにすることができます。

Cognos をクラウドで実行する方法については、Cognos サイトおよび developerWorks で詳細を調べてください (「参考文献」を参照)。

参考文献

学ぶために

• Cognos Business Analytics についての詳細を調べてください。
  
  
• その他の IBM ビジネス・アナリティクス・ソフトウェアを調べてください。
  
  
• Cognos Proven Practices チームでは、顧客の実体験に基づいたベスト・プラクティスに関する資料を提供しています。
  
  
• Redbooks のドラフト版「IBM Smart Analytics Cloud」では、Smart Analytics Cloud の実験的実装について詳しく説明しています。
  
  
• developerWorks のクラウド開発者向けリソースで、クラウド開発プロジェクトを作成しているアプリケーションおよびサービス開発者たちの知識と経験を調べて共有してください。
  
  

製品や技術を入手するために

• Cognos 8 Business Intelligence ソフトウェアのオンライン・デモを見て、この製品を試してみてください。
  
  

議論するために

• My developerWorks でクラウド・コンピューティング・グループの一員になってください。
  
  
• My developerWorks でクラウドに関する優れたブログのすべてを読んでください。
  
  
• 専門家のネットワークであるとともに、互いにつながりを持ち、共有、協力するためのコミュニティー・ツールが集められている My developerWorks コミュニティーに加わってください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• Cognos 8 BI: シートベルトをお締めください
• Cognos 8 BI: 雲 (クラウド) のなかへ
• ベスト・プラクティス: hosts ファイルを使用して複数のイメージを管理する
• 例: 単一のイメージを使用したエラスティック Cognos 8 クラスター
• プライベート・イメージを使用したスナップショットの作成
• クラウド内でのファイル
• まとめ
• 参考文献
• 著者について
• コメント