Workload Optimization Manager 3.4.4 設置ガイド

このマニュアルに記載されている仕様および製品に関する情報は、予告なしに変更されることがあります。このマニュアルに記載されている表現、情報、および推奨事項は、すべて正確であると考えていますが、明示的であれ黙示的であれ、一切の保証の責任を負わないものとします。このマニュアルに記載されている製品の使用は、すべてユーザー側の責任になります。

対象製品のソフトウェア ライセンスと限定保証は、製品に添付された『Information Packet』に記載されています。ソフトウェアライセンスまたは限定保証書が見つからない場合は、CISCO の代理店に連絡してコピーを入手してください。

Cisco が採用している TCP ヘッダー圧縮機能は、UNIX オペレーティング システムのカリフォルニア大学バークレイ校（UCB）によるパブリック ドメイン バージョンの一部として、UCB が開発したプログラムを採用したものです。All rights reserved. Copyright © 1981, Regents of the University of California.

ここに記載されている他のいかなる保証にもよらず、各社のすべてのマニュアルおよびソフトウェアは、障害も含めて「現状のまま」として提供されます。シスコおよび上記代理店は、商品適格性、特定目的適合、および非侵害の保証、もしくは取り引き、使用、または商慣行から発生する保証を含み、これらに限定することなく、明示または暗黙のすべての保証を放棄します。

いかなる場合においても、シスコおよびその供給者は、このマニュアルの使用または使用できないことによって発生する利益の損失やデータの損傷をはじめとする、間接的、派生的、偶発的、あるいは特殊な損害について、あらゆる可能性がシスコまたはその供給者に知らされていても、それらに対する責任を一切負わないものとします。

このマニュアルで使用している IP アドレスおよび電話番号は、実際のアドレスおよび電話番号を示すものではありません。マニュアルの中の例、コマンド出力、ネットワーク トポロジ図、およびその他の図は、説明のみを目的として使用されています。説明の中に実際のアドレスおよび電話番号が使用されていたとしても、それは意図的なものではなく、偶然の一致によるものです。

この文書の印刷されたハード コピーおよび複製されたソフト コピーは、すべて管理対象外と見なされます。最新版については、現在のオンライン バージョンを参照してください。

シスコは世界各国 200 箇所にオフィスを開設しています。各オフィスの住所、電話番号、FAX 番号は当社の Web サイト（www.cisco.com/go/offices）をご覧ください。

Cisco および Cisco のロゴは、米国およびその他の国における Cisco およびその関係会社の登録商標を示します。シスコの商標の一覧については、https://www.cisco.com/c/en/us/about/legal/trademarks.html をご覧ください。記載されているサードパーティの商標は、それぞれの所有者に帰属します。「パートナー」という用語の使用は Cisco と他社との間のパートナーシップ関係を意味するものではありません。（1721R）

© 2018-2022 Cisco Systems, Inc. All rights reserved.

はじめに

Workload Optimization Manager、クラウドおよびリモート対応環境用アプリケーションリソース管理（ARM）向けプレミアソリューションをお選びいただきありがとうございます。このガイドは、仮想化環境に Workload Optimization Manager をインストールし、ライセンスをインストールし、リソースの管理を開始するのに必要な情報を提供します。

ご不明な点がございましたら、シスコ サポートまでお問い合わせください。

よろしくお願いいたします。

Workload Optimization Manager チーム

最小要件

ライセンス要件

使用環境で Workload Optimization Manager を実行するには、適切なライセンスをインストールする必要があります。ライセンスにより、Workload Optimization Manager の異なる機能のセットが有効になり、使用環境内で指定された数のワークロードがサポートされます。

ユーザーインターフェイスの要件

Workload Optimization Manager のユーザーインターフェイスを表示するには、HTML5 のページを表示できるブラウザでプラットフォームにログインする必要があります。現在、Workload Optimization Manager は次のブラウザをサポートしています。

■      Apple Safari

■      Google Chrome

■      Microsoft Edge

■      Mozilla Firefox

ネットワークアドレッシングの要件

Workload Optimization Manager には、静的 IP アドレッシングが必要です。静的 IP のセットアップは、Workload Optimization Manager VM イメージのインストール手順で説明されています。

コンピューティングとストレージの要件

Workload Optimization Manager インスタンスを実行するための要件は、管理している環境のサイズによって異なります。Workload Optimization Manager では、環境のリアルタイム表現がメモリに保持されます。管理するエンティティの数が多く、エンティティ間の関係が広ければ広いほど、Workload Optimization Manager を実行する VM に必要なリソースも多くなります。また、VM の要件が増えると、VM をホストする物理マシンの要件も増えます。

ここにリストされている要件は、Workload Optimization Manager の展開を計画する際に留意する必要がある推奨事項です。展開後、VM のメモリ容量、CPU 容量、または両方を変更する必要がある場合は、VM をシャットダウンして変更を加えた後、再度電源を投入することで新しい容量を使用できます。

注：

Workload Optimization Manager プラットフォームをホストするマシンは、SSE4.2 命令セットをサポートしている必要があります。この命令セットのサポートの導入時期は、チップ メーカーごとに異なっています。

■      Intel：2008 年 11 月

■      AMD：2011 年 10 月

Workload Optimization Manager をホストするために使用するマシンは、これらの日付以降に製造されている必要があります。Linux システムでは、次のコマンドを実行してこの命令セットのサポートを確認できます。

cat /proc/cpuinfo | grep sse4

詳細については、http://www.cpu-world.com/Glossary/S/SSE4.html にある用語集エントリを参照してください。

ほとんどの場合、次の最小要件を満たすホストで Workload Optimization Manager を実行できます。

シスコでは、事前設定された VM イメージ（OVA または VHD ファイル）を 2 つのハードドライブで提供しています。適切な容量のストレージをドライブに確保するには、最低 1.25 TB が必要です。

仮想マシンイメージへのインストール

Workload Optimization Manager プラットフォームは、次のイメージとしてダウンロードできます。

■      VMware OVA 1.0 イメージ

■      Microsoft Hyper-V イメージ

注：

最小要件として、Workload Optimization Manager をホストする VM には 128 GB のメモリをお勧めします。ただし、小規模な環境（10,000 VM 以下）を管理する予定の場合は、64 GB のメモリを備えた VM にインストールできます（「最小要件」（6 ページ）を参照）。

64 GB のメモリを備えた VM をインストールする場合は、VM メモリのデフォルトを変更する必要があります（「Workload Optimization Manager VM の展開」（9 ページ）を参照）。

プラットフォームは、次の 2 つの主な手順でインストールします。

1.       Workload Optimization Manager VM イメージをネットワークにインストールします。

Workload Optimization Manager プラットフォームのインスタンスをホストする VM がインストールされて起動します。

2.       Workload Optimization Manager コンポーネントを VM に展開します。

Workload Optimization Manager VM イメージについて

Workload Optimization Manager は、CentOS Linux OS を実行する VM としてインストールされます。新しいバージョンごとに、製品を実行するためにインストールする VM イメージ（OVA または VHD）が提供されます。通常は、VM イメージを 1 回インストールします。後続の Workload Optimization Manager の更新では、インストールされた VM で製品の更新を実行します。これは次の 2 つのことを意味します。

■      製品の更新では、Workload Optimization Manager アプリケーション スタックの新しいコンポーネントのパッチが、最初に VM イメージをインストールしたときに取得したのと同じ CentOS プラットフォームに適用されます。製品の更新は、基盤となる OS に影響を及ぼしません。

■      時間の経過とともに、CentOS ディストリビューションの重要なセキュリティパッチが提供されることがあります。OS を最新の状態に保つのはユーザーの責任です。それらのパッチは、必要なときにいつでも Workload Optimization Manager VM にインストールできます。

注：

シスコは、現在、CentOS Linux OS で VM イメージをリリースしています。CentOS Linux OS は、全体的なセキュリティ要件を満たしていることを確認しています。CentOS Linux OS のプラットフォームが実行可能で安全である限り、CentOS を使用し続ける予定です。

OVA：vCenter イメージのインストール

Workload Optimization Manager をインストールする場合、最初にプラットフォームをホストする VM を展開します。

vCenter Server 環境の場合、各四半期リリースで OVA イメージが提供されます。vCenter Server で Workload Optimization Manager を実行する場合は、四半期リリースをインストールしてから、必要に応じて新しいポイント リリースに更新できます。

注：

最小要件として、Workload Optimization Manager をホストする VM には 128 GB のメモリをお勧めします。ただし、小規模な環境（10,000 VM 以下）を管理する予定の場合は、64 GB のメモリを備えた VM にインストールできます（「最小要件」（6 ページ）を参照）。

64 GB のメモリを備えた VM をインストールする場合は、VM メモリのデフォルトを変更する必要があります（「Workload Optimization Manager VM の展開」（9 ページ）を参照）。

Workload Optimization Manager OVA をインストールするには、次の手順を実行します。

1.       Workload OptimizationManager インストール パッケージをダウンロードします。

Workload Optimization Manager Software Download ページ（https://software.cisco.com/download/home/286328879/type/
286317011/release）に移動して、最新の OVA イメージへのリンクを確認します。

インストール パッケージには、cisco_cwom-<version>-<XXXXXXXXXXXXXX>.ova ファイル

ここで、<version> が Workload Optimization Manager のバージョン番号であり、<XXXXXXXXXXXXXX> がタイムスタンプです。

例：cisco_cwom-3.0.0-20190916164429000.ova

OVA ファイルは、インストールの準備ができている Workload Optimization Manager コンポーネントを備えた VM として展開されます。

2.       OVA ファイルをデータセンターにインポートします。

vCenter Server クライアントを使用して、OVA を使用環境にインポートします。

3.       Workload Optimization Manager VM を展開します。

OVA ファイルから展開された VM を設定します。

最小要件として、Workload Optimization Manager をホストする VM には 128 GB のメモリをお勧めします。ただし、小規模な環境（10,000 VM 以下）を管理する予定の場合は、64 GB のメモリを備えた VM にインストールできます（「最小要件」（6 ページ）を
参照）。

64 GB のメモリを備えた VM を展開する場合は、メモリのデフォルト値を手動で変更します。

a.      VM を右クリックして、[Edit Settings] を選択します。

b.       [メモリ（Memory）] に 64 と入力します。

c.       [OK] をクリックして、設定を保存します。

d.       VM の電源を投入します。

4.       リモートコンソールを開きます。

展開直後の Workload Optimization Manager VM の場合：

a.      [サマリ（Summary）] タブを選択します。

b.       [リモート コンソールの起動（Launch Remote Console）] をクリックします。

5.       Workload Optimization Manager システム管理者アカウントをセットアップします。

a.      リモートコンソールで、次のデフォルトログイン情報でログインします。

■      ユーザー名： turbo

アカウント名 root は使用しないでください。

■      パスワード： vmturbo

次に、新しいパスワードの入力を求められます。

b.       新しいパスワードを入力します。

新しいパスワードは、強力なパスワード ポリシー（大文字と小文字、数字、記号の組み合わせ）に準拠している必要があります。新しいパスワードは誰にも教えないでください。

注：

変更したアカウントのログイン情報は安全な場所に保存してください。セキュリティ上の理由から、このアカウントが、Workload Optimization Manager VM にアクセスして構成できる唯一のアカウントです。

c.       新しいパスワードを再度入力して確認します。

6.       ルートパスワードを更新します。

プラットフォームでは、/var/log/messages にあるログ メッセージのロールアップなど、特定のプロセスに root アカウントが使用されます。アカウントのログイン情報が最新であることを確認するには、パスワードを変更する必要があります。

a.      スーパーユーザーセッションを開きます。

■      リモートコンソールで、su - と入力します。

■      パスワードプロンプトで、デフォルトのパスワード（vmturbo）を入力します。

b.       新しいパスワードをリセットします。

デフォルトのパスワードを使用して root としてログインすると、新しいパスワードの入力を求めるプロンプトが表示されます。この新しいパスワードは、強力なパスワード ポリシー（大文字と小文字、数字、記号の組み合わせ）に準拠している必要があります。

新しいパスワードは誰にも教えないでください。

注：

root アカウントのログイン情報は安全な場所に保存してください。

c.       スーパーユーザーセッションを終了します。

exit と入力します。

7.       その他の必要な設定手順を実行してから、Workload Optimization Manager コンポーネントをインストールします。

Workload Optimization Manager インスタンスに必要な重要な構成手順を実行するには、「全般 構成タスク」（16 ページ）を参照してください。

Workload Optimization Manager コンポーネントをインストールするには、「Workload Optimization Manager コンポーネントの展開」

（73 ページ）を参照してください。

VHD：Microsoft Hyper-V イメージのインストール

Workload Optimization Manager をインストールする場合、最初にプラットフォームをホストする VM を展開します。

Hyper-V 環境の場合、各四半期リリースで Hyper-V イメージが提供されます。Hyper-V VM で Workload Optimization Manager を実行する場合は、四半期リリースをインストールしてから、必要に応じて新しいポイント リリースに更新できます。

注：

最小要件として、Workload Optimization Manager をホストする VM には 128 GB のメモリをお勧めします。ただし、小規模な環境（10,000 VM 以下）を管理する予定の場合は、64 GB のメモリを備えた VM にインストールできます（「最小要件」（6 ページ）を参照）。

64 GB のメモリを備えた VM をインストールする場合は、VM メモリのデフォルトを変更する必要があります（「Workload Optimization Manager VM の展開」（9 ページ）を参照）。

Workload Optimization Manager をインストールするには?

1.       Workload OptimizationManager インストール パッケージをダウンロードします。

Workload Optimization Manager Software Download ページ（https://software.cisco.com/download/ home/286328879/type/
286317011/release）に移動して、最新の Hyper-V イメージへのリンクを確認します。

2.       .Zip ファイルを展開し内容をコピーして、Hyper-V サーバーに（またクラスタ共有ボリュームかローカル ハード ドライブのどちらかに）仮想マシン イメージを含みます。

3.       Hyper-V マネージャの仮想マシン インポート ウィザードを使用して、環境内に仮想マシンをインポートします。

4.       仮想ネットワーク アダプタが正しい仮想ネットワークに接続されていることを確認します。

5.       Workload Optimization Manager インスタンスに十分なメモリが必要です。

シスコでは、Workload Optimization Manager インスタンスに静的メモリを使用することを推奨します。ただし、インスタンスに静的または動的なメモリを指定することができます。デフォルトのインストールでは、静的メモリは 128 GB に設定されます。

6.       Workload Optimization Manager アプライアンスを開始し、その IP アドレスを記録します。

7.       Workload Optimization Manager システム管理者アカウントをセットアップします。

a.      次のデフォルトのログイン情報で VM の Hyper-V コンソールにログインします。

■      ユーザー名：turbo

アカウント名 root は使用しないでください。

■      パスワード：vmturbo

次に、新しいパスワードの入力を求められます。

b.       新しいパスワードを入力します。

新しいパスワードは、強力なパスワード ポリシー（大文字と小文字、数字、記号の組み合わせ）に準拠している必要があります。新しいパスワードは誰にも教えないでください。

注：

変更したアカウントのログイン情報は安全な場所に保存してください。セキュリティ上の理由から、このアカウントが、Workload Optimization Manager VM にアクセスして構成できる唯一のアカウントです。

c.       新しいパスワードを再度入力して確認します。

8.       ルートパスワードを更新します。

プラットフォームでは、/var/log/messages にあるログ メッセージのロールアップなど、特定のプロセスに root アカウントが使用されます。アカウントのログイン情報が最新であることを確認するには、パスワードを変更する必要があります。

a.      スーパーユーザーセッションを開きます。

■      リモートコンソールで、su - と入力します。

■      パスワードプロンプトで、デフォルトのパスワード（vmturbo）を入力します。

b.       新しいパスワードをリセットします。

デフォルトのパスワードを使用して root としてログインすると、新しいパスワードの入力を求めるプロンプトが表示されます。この新しいパスワードは、強力なパスワード ポリシー（大文字と小文字、数字、記号の組み合わせ）に準拠している必要があります。

新しいパスワードは誰にも教えないでください。

注：

root アカウントのログイン情報は安全な場所に保存してください。

c.       スーパーユーザーセッションを終了します。

exit と入力します。

9.       インストールされた VM の NIC を有効にします。

Workload Optimization Manager インスタンスの構成には、1 つの NICが含まれますが、これは有効化されていないか、ネットワークに接続されていません。Hyper-V マネージャで NIC を表示し、有効にします。

10.       その他の必要な設定手順を実行してから、Workload Optimization Manager コンポーネントをインストールします。

Workload Optimization Manager インスタンスに必要な重要な構成手順を実行するには、「全般 構成タスク」（16 ページ）を参照してください。

Workload Optimization Manager コンポーネントをインストールするには、「Workload Optimization Manager コンポーネントの展開」

（73 ページ）を参照してください。

Workload Optimization Manager コンポーネントの展開

注：

このセクションでは、デフォルトのインストールプロセスについて説明します。インストールをカスタマイズする場合は、「付録：段階的なプラットフォーム展開」（73 ページ）の手順を実行することを検討してください。

たとえば、展開対象の Kubernetes ホスト名を変更するには、段階的なインストールを実行する必要があります。

プラットフォームをホストする Workload Optimization Manager VM をインストールしたら、次の手順でプラットフォーム コンポーネントをインストールできます。

まず、インストールの実行に必要な情報を収集します。

■      時刻同期用のネットワークタイムソース（任意）

この手順は、インストール中に、または後で実行できます。VM のクロックを今すぐ同期する場合は、ネットワークタイムソースの入力を求められます。VM のクロックの同期の詳細については、「時刻の同期」（16 ページ）を参照してください。

■      更新されたルートパスワード

インストール スクリプトを実行するには、VM のルート パスワードを更新しておく必要があります。「OVA：vCenter イメージのインストール」（8 ページ） または「VHD：vCenter イメージのインストール」（10 ページ）の手順に従った場合、この手順はすでに実行しているはずです。

必要な情報を準備できたら、インストールスクリプトを実行できます。

1.       インストールスクリプトを起動します。

■      turbo ユーザーとして Workload Optimization Manager VM でセキュアセッション（SSH）を開始します。

■      スクリプト ディレクトリに変更します。

cd /opt/local/bin/

■      インストール スクリプトを実行します。

sudo t8cInstall.sh

2.       Workload Optimization Manager VM に静的 IP アドレスを設定していることを確認します。

コンポーネントが起動したら、この静的 IP アドレスを Web ブラウザに入力して、Workload Optimization Manager ユーザー インターフェイスのログイン ページにアクセスします。

スクリプトの最初の手順で、次のプロンプトが表示されます。

ipsetup スクリプトを実行してネットワークをセットアップしましたか？[y/n] n

プラットフォーム VM の静的 IP を設定していない場合は、n を入力してインストール スクリプトを終了し、静的 IP を構成します。

プラットフォーム VM の静的 IP をすでに構成している場合は、y を入力してインストールを続行します。スクリプトの出力には、VM に対して認識される IP アドレスが表示されます。次に例を示します。

古い IP アドレス: 10.0.2.15

新しい IP アドレス: 10.10.123.123

注：

プラットフォーム コンポーネントと VM アドレス間の依存関係により、コンポーネントのインストール後は IP アドレスを簡単に変更できません。Workload Optimization Manager の実稼働インストールの場合、VM は静的 IP で実行する必要があります。テストまたは評価インストールの場合、DHCP を使用できますが、後に実稼働環境で使用する予定がある場合は、必ず静的 IP を構成する必要があります。

「OVA：vCenter イメージのインストール」（8 ページ） または「VHD：vCenter イメージのインストール」（10ページ ）、これを行うには、すでに ipsetup.sh スクリプトを実行している必要があります。

3.       スクリプトによりインストールが実行されている間は待機します。

インストールプロセスの進行中、スクリプトにより以下の作業が実行されます。

■      必要な証明書を使用したプラットフォーム環境を設定する

■      VM で Kubernetes クラスタを設定する

この設定は、成功するまで数回試行されることがあります。試行が失敗するたびに、次のようなメッセージが表示されます。

クラスタの問題をさらにデバッグおよび診断するには、「kubectl cluster-info dump」を使用します。

接続に成功すると、スクリプトは次の手順に進みます。

■      プラットフォームのローカルストレージを確立する

■      プラットフォームの kubernetes 名前空間を turbonomic として作成する

■      必要な Kubernetes シークレットにアクセスするための承認を設定する

■      MariaDB データベース サーバーを初期化して、プラットフォームの履歴データを管理します。

スクリプトは、MariaDB に完全な権限を持つ 2 つのアカウントを作成します。

–     root@localhost

このアカウントにはパスワードは不要です。このアカウントを介して接続するには、ユーザーは system root である必要があります。

–     mysql@localhost

このアカウントにはパスワードは不要です。このアカウントを介して接続するには、ユーザーは system mysql である必要があります。

注：

セキュリティ上の理由から、これらのアカウントにはパスワードを構成することをお勧めします。これらのアカウントには、sudo 経由で接続できます。例：sudo mysql。接続後、これらのアカウントにパスワードを設定できます。詳細については、https://mariadb.com/kb にある MariaDB ナレッジベースを参照してください。

■      組み込みレポート用のタイムスケールデータベースとデータエクスポータをインストールする

■      プラットフォーム コンポーネントを展開して起動する

展開が開始されると、次の内容が出力されます。

###########################

展開をロールアウトし、開始します

############################

コンポーネントが展開されたら、コンポーネントが起動するのを待ちます。

インストール プロセスが完了し、すべてのコンポーネントが起動するのを待ちます。

** スクリプトは 30 分間待機します。**

すべてのコンポーネントが 30 分以内に起動した場合、インストールは完了し、成功しています。

すべてのコンポーネントが 30 分以内に起動しない場合、次の内容が表示され、スクリプトが終了します。

===========================================================================

1 つ以上の展開がまだ起動していません。

** 環境が安定するまで、さらに 30 分お待ちください。**

コンポーネントのステータスを確認するには、次のコマンドを実行します。

kubectl get pods

一部のコンポーネントがまだ準備ができていない場合は、サポート担当者に連絡してください。

展開が準備できていません。

スクリプトは次に、kubectl get pods コマンドのフォーマットされた結果を表示します。Workload Optimization Manager プラットフォームのポッドの現在のステータスがわかります。

注：

コンポーネントがすべて起動する前にスクリプトが終了した場合は、さらに 30 分待つことをお勧めします。コンポーネントのステータスを定期的に確認するには、kubectl get pods を実行します。さらに 30 分待ってもすべてのコンポーネントが起動しない場合は、サポート担当者に連絡してください。

インストールが成功し、コンポーネントがすべて起動している場合、次のようなメッセージが表示され、VM の静的 IP アドレスが示されます。

########################################

展開が完了しました。UI からログインしてください

https://10.10.123.123

#########################################

これで、次の手順に進めます。

4.       プラットフォームのマスターキーシークレットのコピーを保存します。

インストール手順により、Kubernetes クラスタにマスターキーシークレットが作成されます。Workload Optimization Manager は、このシークレットを使用して、プラットフォーム コンポーネントへのアクセスを提供します。キーデータは安全な場所に保存する必要があります。何らかの理由でキーデータが破損したり、使用できなくなったりすると、Workload Optimization Manager は動作しなくなります。動作しなくなった場合は、サポート担当者に連絡し、保存したキーデータを使用してプラットフォームを回復できます。

データを保存するには、次の手順を実行します。

a.      プラットフォーム シークレットを一覧表示します。

次のコマンドを実行します。

kubectl get secrets

結果には、次のようなマスターキーシークレットが含まれます。

...

master-key-secret              Opaque                        1                               57d

...

b.       マスターキーデータを表示します。

マスターキーの名前が見つかったら、キーデータを表示できます。

kubectl get secret master-key-secret -o yaml

コマンドの結果は次のようになります。

apiVersion: v1

data:

primary_key_256.out: AfnJWutxNHAduaIOdAii3DRA2fMa6lzX4rWetZxxZvc=

kind: Secret

metadata:

creationTimestamp: "2021-06-30T02:59:19Z"

managedFields:

- apiVersion: v1

fieldsType: FieldsV1

fieldsV1:

f:data:

.: {}

f:primary_key_256.out: {}

f:type: {}

manager: kubectl-create

operation: Update

time: "2021-06-30T02:59:19Z"

name: master-key-secret

namespace: turbonomic

resourceVersion: "1072"

uid: a314b2ba-2061-4b41-b844-56caf2c3728d

type: Opaque

保存する重要なキーデータは、primary_key... データです。前述の例では、次の行を保存する必要があります。

primary_key_256.out: AfnJWutxNHAduaIOdAii3DRA2fMa6lzX4rWetZxxZvc=

c.       データを安全な場所に保存します。

このデータをファイルに書き込み、安全なバックアップ場所に保存します。マスターキーを回復する必要がある場合は、サポート担当者がこのデータを使用して回復を実行します。

5.       Workload Optimization Manager のユーザーインターフェイスにログインし、管理者ユーザーアカウントのパスワードを設定します。

Workload Optimization Manager には、ADMINISTRATOR ロールを持つ administrator という名前のデフォルトのユーザー アカウントが含まれています。初めてログインするときは、そのアカウントに独自のパスワードを設定する必要があります。ADMINISTRATOR ロールを持つ他のアカウントの作成や削除は可能ですが、Workload Optimization Manager のインストールには、ADMINISTRATOR ロールを持つアカウントが常に少なくとも 1 つ必要です。

ログインページで、必要に応じて情報を入力し、メモしておきます。

■      USERNAME：administrator のデフォルトのログイン情報を使用します。

■      PASSWORD のパスワードを入力します。

新しいパスワードは、強力なパスワード ポリシー（大文字と小文字、数字、記号の組み合わせ）に準拠している必要があります。新しいパスワードは誰にも教えないでください。

■      パスワードをもう一度入力して、[パスワードの再入力（REPEAT PASSWORD）] を確認します。

■      [アカウントの作成（Create Account）] をクリックします。

これは、Workload Optimization Manager のユーザーインターフェイスに管理者権限でアクセスするために使用するアカウントです。ユーザーインターフェイス管理者アカウントのログイン情報は安全な場所に保存してください。

注：

最初のログインは、常に管理者アカウントで行います。これは管理ユーザー アカウントであり、Workload Optimization Manager システム管理者アカウントではありません。

6.       管理者としてログインしたら、他のユーザーアカウントを作成し、さまざまなロールを付与できます。ユーザーアカウントとロールの詳細については、Workload Optimization Manager ユーザーガイド を参照してください。

注：

セキュリティ上の理由から、Workload Optimization Manager インストールのメイン管理者として機能する別の管理者ユーザーアカウントを作成してから、デフォルトの管理者アカウントを削除することができます。ただし、管理者権限を持つ少なくとも 1 つのユーザーアカウントが常に必要であることを忘れないでください 。

全般設定タスク

Workload Optimization Manager インスタンスをインストールした後、次の構成タスクを実行する必要があります。

■      （必須）システムクロックを同期し、タイムサーバーを設定します。

■      （重要）MariaDB バージョンを確認してください。

■      （オプション）使用可能なディスク領域を増やします。

■      （任意）LDAP を介してセキュアなアクセスを適用します。

■      （任意）信頼できる証明書を介してセキュアなアクセスを適用します。

■      （任意）プローブのセキュアなアクセスを有効にします。

■      （任意）Cluster Manager の証明書を変更します。

■      （任意）組み込みレポートを有効にします。

■      （任意）データエクスポータを有効にします。

■      （任意）プラットフォームノードの IP アドレスを変更します。

■      （任意）プローブコンポーネントを有効または無効にします。

（必須）時刻の同期

同じネットワークにある他のデバイスと、Workload Optimization Manager インスタンスのクロックを同期させることが重要です。デフォルトでは、Workload Optimization Manager サーバーは、次のいずれかのタイムサーバーと同期するように設定されています。

■      0.centos.pool.ntp.org

■      1.centos.pool.ntp.org

■      2.centos.pool.ntp.org

■      3.centos.pool.ntp.org

これらのサーバーと同期させるには、インストールした Workload Optimization Manager がインターネットにアクセスできる必要があります。インターネット アクセスが制限されている環境の場合は、ネットワーク上のタイム サーバーとの同期を構成する必要があります。

いずれの場合も、Workload Optimization Manager のクロックが正しく同期されていることを確認する必要があります。システム クロックを確認するには、次の手順を実行します。

1.       Workload Optimization Manager インスタンスへの SSH ターミナルセッションを開きます。

Workload Optimization Manager をインストールしたときに設定したシステム管理者でログインします。

■      ユーザー名：turbo

■      ユーザ名： [your_private_password]

2.       時刻設定を確認します。

 date コマンドを実行します。次のような結果が表示されます。

2019 年 2 月 2 日(木) 14:25:45 UTC

時刻を確認するには、timedatectl コマンドを実行します。出力は次のようになります。

Local time: Fri 2019-12-06 21:09:26 UTC

Universal time: Fri 2019-12-06 21:09:26 UTC

RTC time: Fri 2019-12-06 21:09:27

Time zone: UTC (UTC, +0000)

NTP enabled: yes

NTP synchronized: yes

RTC in local TZ: no

DST active: n/a

出力から、NTP が有効になっているかどうか、現在同期されているかどうか、およびその他の時刻同期情報を確認できます。

出力が正しく、使用環境がインターネットにアクセスできる場合、システムクロックが同期されていると見なすことができます。

出力が正しくない場合、またはネットワーク上のタイム サーバーとの同期を構成する必要がある場合、サーバー インスタンスで chrony を構成する必要があります。

Workload Optimization Manager インスタンスで chrony を設定するには、次の手順を実行する必要があります。

1.       Workload Optimization Manager インスタンスへの SSH ターミナルセッションを開きます。

2.       chrony 構成ファイルを開きます。

たとえば、次のコマンドを実行します。sudo vi /etc/chrony.conf

3.       使用環境で使用するタイムサーバーを指定します。

chrony ファイルには、タイム サーバーを構成するための次のステートメントが含まれています。

server 0.centos.pool.ntp.org iburst

server 1.centos.pool.ntp.org iburst

server 2.centos.pool.ntp.org iburst

server 3.centos.pool.ntp.org iburst

使用するサーバーのステートメントを入力します。次に、使用しないステートメントを削除するか、コメントアウトします。次のコマンドシンタックスを使用してタイム サーバーを指定します。

server My_Time_Server_Name iburst

4.       ファイルを保存します。

5.       chrony サービスを再起動します。

コマンドを実行します。sudo systemctl restart chronyd

6.       時間が正しいことを確認してください。

date コマンドを実行します。次のような結果が表示されます。

2019 年 12 月 6 日金曜日 21:09:26 UTC

時刻が同期されていることを確認するには、timedatectl コマンドを実行します。出力は次のようになります。

Local time: Fri 2019-12-06 21:09:26 UTC

Universal time: Fri 2019-12-06 21:09:26 UTC

RTC time: Fri 2019-12-06 21:09:27

Time zone: UTC (UTC, +0000)

NTP enabled: yes

NTP synchronized: yes

RTC in local TZ: no

DST active: n/a

時刻を確認するには、date の出力を既知の UTC タイムサーバーからの出力と比較します。

出力が正しい場合、システム クロックが同期されていると見なすことができます。

出力が正しくない場合は、サポート担当者に連絡してください。

（重要）MariaDB バージョンの確認

デフォルトの履歴データベースで、Workload Optimization Manager は現在、MariaDB バージョン 10.5.16 をサポートしています。このサポートには、Workload Optimization Manager による履歴データベースの使用に関する包括的なテストと品質管理が含まれます。

VM イメージ（OVA または VHD）としてインストールされた Workload Optimization Manager を実行しており、そのイメージのインストールに含まれているデータベースを使用している場合は、バージョン 10.5.16 を使用する必要があります。Workload Optimization Manager のバージョンを（初めてインストールするのではなく）更新する場合は、インストールで正しいバージョンの MariaDB を使用していることを確認する必要があります。

このセクションでは、Workload Optimization Manager の VM イメージのインストールで MariaDB のバージョンを確認する方法について説明します。また、更新スクリプトを使用して Workload Optimization Manager をバージョン 3.1.5 以降に更新した場合は、このセクションの手順を使用して MariaDB を更新できます。

重要事項：

MariaDB バージョン 10.5.16 以降を実行する必要があります。Workload Optimization Manager は、他のバージョンの MariaDB でも動作できます。MariaDB バージョン 10.5.16 での動作が完全にテストされています。

既知の問題のため、MariaDB バージョン 10.5.14、10.5.15、10.6.7、10.7.3、または 10.8.2 は使用しないでください。

Workload Optimization Manager は、カスタムインストールとして展開された MySQL 5.7.x もサポートしています。

Workload Optimization Manager を初めてインストールした場合、そのインストールには特定のバージョンを実行する MariaDB が含まれており、Workload Optimization Manager のバージョンを更新しても、MariaDB のバージョンは同じままです。MariaDB 10.5.16 を含む Workload Optimization Manager の最初のリリースは 3.3.6 です。最初に旧バージョンをインストールしている場合、MariaDB を明示的に 10.5.16 に更新していない場合は、ここで更新する必要があります。

VM イメージのインストールの場合、リモートデータベース（VM の外部）を使用するようにインストールを設定できます。そのような展開では、データベースのバージョニングを自分で管理する必要があります。リモートの MariaDB インスタンスを使用している場合は、バージョン 10.5.16 を使用することをお勧めします。リモート MySQL の場合、バージョン 5.7.x を使用する必要があります。

（Workload Optimization Manager VM イメージとして展開されていない）Kubernetes クラスタにインストールし、MariaDB を使用している場合は、バージョン 10.5.16 を使用することをお勧めします。ダウンロード パッケージへは以下からアクセスすることができます。https:// archive.mariadb.org/mariadb-10.5.16/yum/centos7-amd64. MySQL の場合、バージョン 5.7.x を使用する必要があります。そのような

展開では、データベースのバージョニングを自分で管理する必要があります。

MariaDB バージョンの確認

Workload Optimization Manager OVA で実行されている MariaDB のバージョンを確認するには、次の手順を実行します。

1.       Workload Optimization Manager インスタンスへの SSH ターミナルセッションを開きます。

Workload Optimization Manager をインストールしたときに設定したシステム管理者でログインします。

■      ユーザー名：turbo

■      ユーザ名：[your_private_password]

2.       MariaDB のバージョンを確認します。

mysql -u root --password=my_pwd -e "SHOW VARIABLES LIKE 'version';"

出力は次のようになります。

+---------------+------------------+

| Variable_name | Value                      |

+---------------+------------------+

| version       | 10.5.16-MariaDB |

+---------------+------------------+

バージョンが 10.5.16-MariaDB よりも古い場合は、データベースを更新する必要があります。

バージョンが 10.5.16-MariaDB 以降の場合は、以下の更新手順を実行しないでください。

MariaDB の更新

VM イメージとしてインストールされた Workload Optimization Manager を使用していて、そのイメージとともにインストールされたデフォルトの MariaDB を使用している場合は、MariaDB バージョン 10.5.16 を実行する必要があります。

Workload Optimization Manager VM の MariaDB を更新するには、次の手順を実行します。

1.       Workload Optimization Manager インスタンスへの SSH ターミナルセッションを開きます。

Workload Optimization Manager をインストールしたときに設定したシステム管理者でログインします。

■      ユーザー名：turbo

■      パスワード：[your_private_password]

2.       VM が Workload Optimization Manager 更新 ISO イメージにマウントされていることを確認します。

注：

Workload Optimization Manager の更新が完了すると、ISO イメージが自動的にアンマウントされます。MariaDB の更新を実行するには、バージョン 3.1.5 以降に更新するために使用したのと同じ ISO イメージに Workload Optimization Manager インスタンスをマウントする必要があります。

オフライン更新と ISO イメージのマウントについては、「オフライン更新」（66 ページ）を参照してください。

3.       MariaDB 更新スクリプトを実行します。

スクリプトを実行する前に、MariaDB パスワードを確認しておく必要があります。デフォルトでは、このパスワードは vmturbo です。

a.      スクリプトディレクトリに移動します。

cd /opt/local/bin

b.       スクリプトを実行可能にします。

chmod +x mariadbUpgrade.sh

c.       データベース更新スクリプトを実行します。

sudo ./mariadbUpgrade.sh

このスクリプトを実行すると、MariaDB のバージョンが更新され、許可されたパケットのサイズ制限、および innodb のバッファとログのサイズが増えます。スクリプトの出力には、次の内容が含まれている必要があります（ Total Memory と buffer pool size は、VM 構成によって異なります）。

================================

mariadb 構成を更新します。

================================

合計メモリ：128773 MB

Innodb バッファー プール サイズの変更：9216 MB

許可される最大パケットの変更：1G

innodb ログ ファイル サイズの変更：10G

================================

4.       更新された MariaDB バージョンを確認します。

スクリプトが完了すると、バージョン 10.5.16 が実行されている必要があります。バージョンを確認するには、次のコマンドを実行します。

mysql -u root --password=my_pwd -e "SHOW VARIABLES LIKE 'version';"

出力は次のようになります。

+---------------+-----------------+

| Variable_name | Value                     |

+---------------+-----------------+

| version             | 10.5.16-MariaDB |

+---------------+-----------------+

5.       Workload Optimization Manager プラットフォームのポッドをスケールアップします。

データベースを更新するために、スクリプトによってプラットフォームポッドがスケールダウンされます。完了すると、次のプロンプトが表示されます。

##########################################################################

mariadb がアップグレードされ、適切に機能していることを確認したら、次を実行します。

kubectl scale deployment --replicas=1 t8c-operator -n turbonomic ##########################################################################

正しいバージョンの MariaDB が実行されていることを確認したら、プラットフォームをスケールアップします。

kubectl scale deployment --replicas=1 t8c-operator -n turbonomic

使用可能なディスク容量の増加

VM イメージへの Workload Optimization Manager の標準インストールには、履歴データ用の MariaDB データベースサーバーが含まれています。組み込みレポートを有効にすると、プラットフォームでは TimescaleDB Postgres データベースも使用してレポートデータが管理されます。さまざまな理由から、データベース サービス用のデフォルトのストレージ容量が十分でない場合があります。十分でない場合は、利用可能なストレージ容量を増やす必要があります。

ストレージ容量を増やす一般的な理由は、組み込みレポートの推定ニーズに対応するためです。組み込みレポートのストレージ要件は、使用環境の変化に応じて、または Workload Optimization Manager インストールを設定するターゲット数の増加に応じて、時間の経過とともに変化する可能性があります。組み込みレポートの要件の見積もりについては、「組み込みレポートのストレージ要件の見積もり」（40 ページ）を参照してください。

実行する手順の概要は次のとおりです。

■      VM に新しいディスクを追加する

■      SCSI デバイスを再スキャンする

■      新しい LVM パーティションを作成する

■      物理ボリューム（pv）を作成する

■      pv を既存のボリュームグループ（vg）に追加する

■      論理ボリューム（lv）を拡張する

■      新しい lv を使用するようにファイルシステムを拡張する

■      埋め込みレポートのストレージを増やすには、XFS クォータを増やします

MariaDB のスペースを増やすために、この手順を実行する必要はありません。

Workload Optimization Manager ストレージの論理ボリューム管理

プラットフォームでは、論理ボリューム管理（LVM）を使用して VM ディスクが管理されます。データベース ストレージを増やすには、新しいディスクを VM に追加し、そのディスクを使用して LVM 論理ボリューム（/dev/turbo/var_lib_mysql）を拡張する必要があります。この論理ボリュームは、履歴データベースと組み込みレポート データベースの両方を提供します。

ストレージの増加：手順

データベースで使用可能なストレージ容量を増やすには、次の手順を実行します。

1.       VM に新しいディスクを追加します。

VM データセンターの手順を使用して、新しいディスクを VM に追加します。Workload Optimization Manager は、VMware または Hyper-V VM としてインストールされます。新しいディスクを追加する手順については、ハイパーバイザのドキュメントを参照してください。

2.       Workload Optimization Manager インスタンスへの SSH ターミナルセッションを開きます。

Workload Optimization Manager をインストールしたときに設定したシステム管理者でログインします。

■      ユーザー名：turbo

■      パスワード：[your_private_password]

3.       SCSI デバイスを再スキャンします。

新しいディスクが使用可能なことを確認するには、SCSI デバイスを再スキャンしてから、ブロックデバイスを一覧表示します。デバイスをスキャンするには、次を実行します。

echo "- - -" > /sys/class/scsi_disk//0\:0\:0\:0/device/rescan

新しいディスクを確認するには、次を実行します。

lsblk

新しいディスクは、/dev/sdc のような名前で表示されます。新しいディスクが表示されない場合は、次の代替手順を試して強制的に再スキャンします。

■      VM 上にある SCSI ホストデバイスの数を確認する

ls /sys/class/scsi_host

host0、host1、host2... hostn などのデバイスのリストが表示されます。

■      各デバイスをスキャンする

デバイスごとにコマンドを実行します（ <hostn> は、host0 または host1 などの番号付きのホスト デバイスです）。

echo "- - -" > /sys/class/scsi_host/host0/scan

■      ブロックデバイスを一覧表示する

lsblk を再度実行して、ブロック デバイスを一覧表示します。

4.       新しい LVM パーティションを作成します。

新しいディスクの名前が /dev/sdc1 である場合、次のコマンドを実行します。

cfdisk /dev/sdc1

以下の操作を実行します。

■       new

■       プライマリ

■       サイズを確認

■       タイプを 8E に変更

■       write

■       quit

5.       物理ボリューム（pv）を作成します。

新しいディスクの名前が /dev/sdc1 である場合、次のコマンドを実行します。

pvcreate /dev/sdc1

6.       新しい pv を既存のボリュームグループに追加します。

新しいディスクの名前が /dev/sdc1 である場合、次のコマンドを実行します。

vgextend /dev/turbo /dev/sdc1

7.       論理ボリューム（lv）を拡張して、新しい pv の空き領域を使用します。

まず、使用可能な物理エクステント（PE）をリストします。コマンドを実行します:

vgdisplay

次のような結果が表示されます。

フリー PE / サイズ      128000 / 500.00 GiB

この例では、128000 が lv を拡張する量です。たとえば、次のコマンドを実行します。

lvextend -l +128000 /dev/turbo/var_lib_mysql

8.       XFS ファイルシステムを拡張して、現在の lv 領域をすべて使用します。

XFS を拡張する前に、空きディスク容量を表示し、その容量を記録します。使用可能な領域が増えたことを確認するには、XFS 拡張後の空き領域とこの値を比較します。コマンドを実行します:

df -h

次に、XFS 容量を拡張します。

xfs_growfs /dev/turbo/var_lib_mysql

次に、更新された空きディスク容量を一覧表示して、元の容量と比較します。

df -h

9.       組み込みレポートの容量を増やす場合は、TimescaleDB の XFS クォータを拡張します。

MariaDB のスペースを増やすために、この手順を実行する必要はありません。

Timescale DB の容量を増やすには、そのプロセスのクォータを必要な量だけ増やす必要があります。クォータ名は Postgresql です。

たとえば、400 GB のボリュームを追加し、現在の Postgresql クォータが 400 GB である場合を仮定します。このケースの場合、クォータを 800 GB に増やすことができます。この例では、次のコマンドを実行します。

xfs_quota -x -c 'limit -p bhard=800g Postgresql' /var/lib/dbs

/var/lib/dbs に設定されている現在のクォータを表示するには、次のコマンドを実行します。

xfs_quota -xc 'report -pbih' /var/lib/dbs

（任意）LDAP を介したセキュアなアクセスの適用

会社のポリシーでセキュアなアクセスが必要な場合は、LDAP サービスで証明書を使用して、ユーザーのセキュアなアクセスを設定できます。たとえば、Active Directory（AD）アカウントを設定して、ユーザーまたはユーザーグループの外部認証を管理できます。AD を有効にするためのユーザーインターフェイスには、証明書ベースのセキュリティを適用する [Secure] オプションが含まれています。詳細については、『Workload Optimization Manager ユーザーガイド』の「ユーザーアカウントの管理」を参照してください。

LDAP サービスが認証局（CA）を使用している場合、その CA によって署名された証明書で、この機能がそのままサポートされる必要がありますが、AD 接続を設定するときに、[Secure] オプションをオンにするだけです。

LDAP サービスが自己署名証明書を使用している場合は、その証明書を Workload Optimization Manager 認証ポッドにインストールする必要があります。実行する手順は次のとおりです。

■      LDAP サーバーから証明書を取得する

■      証明書をプラットフォームのトラストストアにインポートする

■      Workload Optimization Manager プラットフォームの認証ポッドに証明書を追加する

■      Workload Optimization Manager プラットフォームの Operator チャートでトラストストアを有効にする

自己署名証明書のインストール

セキュアなアクセスを設定するには、次の手順を実行します。

1.       Workload Optimization Manager インスタンスへの SSH ターミナルセッションを開きます。

Workload Optimization Manager をインストールしたときに設定したシステム管理者でログインします。

■      ユーザー名： turbo

■      パスワード： [your_private_password]

2.       LDAP サーバー証明書を Workload Optimization Manager インスタンスにダウンロードします。

LDAP 管理者から証明書を取得し、Workload Optimization Manager プラットフォームにダウンロードします。たとえば、/tmp/ldapserver.crt ファイルにダウンロードできます。

3.       .crt ファイルを Workload Optimization Manager トラストストアにインポートします。

これで、Workload Optimization Manager プラットフォームの cacerts ファイルが変更されます。

注：

証明書を Workload Optimization Manager トラストストアにインポートするには、keytool ユーティリティを使用する必要があります。このユーティリティをインストールするには、次のコマンドを実行します。

sudo yum install java-1.8.0-openjdk

/usr/bin/keytool にユーティリティがインストールされます。

LDAP 証明書のエイリアスがすでに存在する場合は、その証明書を削除します。たとえば、エイリアスが ldapcert1 である場合、次のコマンドを実行します。

keytool -delete -alias ldapcert1 -keystore cacerts -storepass changeit

次のコマンドを使用して、新しい証明書をトラストストアにインポートします。

keytool -import -alias ldapcert1 -file /tmp/ldapserver.crt -keystore cacerts \

-deststoretype jks -storepass changeit -noprompt

4.       cacerts ファイルから auth シークレットを作成します。

base64 cacerts > auth-secrets.yaml

5.       編集のためにシークレットファイルを開きます。

vi auth-secrets.yaml

6.       ファイルを編集して、有効な yaml ファイルにします。

a.      証明書のすべての行を 4 つのスペースでインデントします。

ファイルの作成時に、証明書の内容を連結します。最初の手順では、証明書を 4 つのスペースでインデントします。たとえば、vi エディタで次のコマンドを実行します。

:%s/^/    /g

b.       シークレットファイルにデータフィールドを追加します。

ファイルの先頭に次のテキストを追加します。

apiVersion: v1

kind: Secret

metadata:

name: auth-secret

data:

cacerts: |

c.       変更を保存します。

完成したファイルは次のようになります。

apiVersion: v1

kind: Secret

metadata:

name: auth-secret

data:

cacerts: |

/u3+7QAAAAIAAAABAAAAAgAFY2VydDEAAAF5H2lEigAFWC41MDkAAAYQMIIGDDCCBPSgAwIBAgIT HAAAARHIFJdLbG90sAAAAAABETANBgkqhkiG9w0BAQUFADBcMRMwEQYKCZImiZPyLGQBGRYDY29t

MRcwFQYKCZImiZPyLGQBGRYHdm10dXJibzEUMBIGCgmSJomT8ixkARkWBGNvcnAxFjAUBgNVBAMT DWNvcnAtREVMTDEtQ0EwHhcNMjEwNDA4MDM0OTEyWhcNMjIwNDA4MDM0OTEyWjAhMR8wHQYDVQQD

ExZkZWxsMS5jb3JwLnZtdHVyYm8uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA sCXuh2MTrFERyU/aKgdbgyjLezNuwF6nmZveZUhDaJDpfLHJlzhwfyYRTGfSSusVo4polJS4WqPZ T3Zk8f2IaX04RpfpQErq5N3uY/BxFkATWLMDiquSd0Di798k2diYXAxXvzMmfmIkBBYJta9oztum uXyh/42dXOGznQ5fFuxosgAksZ6CnXGDKrTBlb0bHpST1z1Pdg+fJ+f9Tq7IffOYdVbuedFTwsik Z0JgDCIRrmmsOJphiHdBqJ6ZLdbSeEzBIbboiQs81pAELw7V0ZZUfKV6y8+zMTACGwpVPJSFv7LX RlW1TWcqhXVAOmroe2WcU8KJE6XZTBxp7z7dzwIDAQABo4IDADCCAvwwLwYJKwYBBAGCNxQCBCIe IABEAG8AbQBhAGkAbgBDAG8AbgB0AHIAbwBsAGwAZQByMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr

BgEFBQcDATAOBgNVHQ8BAf8EBAMCBaAweAYJKoZIhvcNAQkPBGswaTAOBggqhkiG9w0DAgICAIAw DgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAS0wCwYJYIZIAWUDBAECMAsG CWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzBCBgNVHREEOzA5oB8GCSsGAQQBgjcZAaAS

BBDswjlHut/nQZ0uK2aUglGbghZkZWxsMS5jb3JwLnZtdHVyYm8uY29tMB0GA1UdDgQWBBR6M7Hb BiirpjIXQ3PXXScB8LkmRDAfBgNVHSMEGDAWgBRjs9l3el7SuKUDMlrHHRhBkENgaDCB0QYDVR0f BIHJMIHGMIHDoIHAoIG9hoG6bGRhcDovLy9DTj1jb3JwLURFTEwxLUNBLENOPWRlbGwxLENOPUNE

UCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u LERDPWNvcnAsREM9dm10dXJibyxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNl P29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIHHBggrBgEFBQcBAQSBujCBtzCBtAYI KwYBBQUHMAKGgadsZGFwOi8vL0NOPWNvcnAtREVMTDEtQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtl

eSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Y29ycCxEQz12bXR1 cmJvLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1 dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAQEADP6OYLONkZ2j6gaBdfdoIJtvn1g1qXTsRrtFuUcF C9mUxL0G5Tudr0VlyEnLH2wtj10CGsIi54+aPGYiElXijThEe1WTHaO2hklRLdNrM8KxUp3tUNb/ cP4d+EYt297wVWgxpl9MStiND8+7M2+65daoEu5IOLtq4lC7YlCSXay19N5HdiGBHV5L07PTZ261

qDzShSb0ZWtG7++5VkqveVEIfs3hUYdaItz0Zu6sym90aUcvn5wohV1GPPqGDvVCg5Kf50hsZfmy ltNlaqiiqLMnYVMa93CkpFFjoP9gmGFJky0yTfh6G8HuqbI7guddDsUqMQTT3uv3EBwSYeImOya7 Zye5C4NnsAfnx8kOwXdsVERC

7.       このシークレットファイルをプラットフォーム環境に適用します。

kubectl apply -f auth-secrets.yaml

8.       プラットフォームの Operator チャートを更新して、シークレット ファイルで作成した cacerts 証明書を使用します。

a.      編集のためにチャートファイルを開きます。

ファイルを開きます。/opt/turbonomic/kubernetes/operator/deploy/crds/
charts_v1alpha1_xl_cr.yaml

b.       コンポーネントオプションの認証仕様として認証シークレットを追加します。

チャート ファイルで、spec:セクションを見つけます。そのセクション内で、auth:サブセクションを見つけます。

これは、spec: の global:の後にある 2 番目のサブセクションである必要があります。auth: サブセクションがない場合は、

spec: に追加できます。

c.       証明書シークレットをファイルに追加します。

auth: サブセクション内の javaComponentOptions: ステートメントにシークレットのパスを追加します。パスを -D オプションとして追加します。auth: サブセクションは次のようになります。auth は 2 つのスペースでインデントされ、javaComponentOptions は 4 つのスペースでインデントされます。

# JAVA_OPTS を認証 POD に渡して、

# LDAPS（セキュア LDAP）の AD 証明書のトラストストアなどの追加オプションを設定します

auth:

javaComponentOptions: "-Djavax.net.ssl.trustStore=/home/turbonomic/data/helper_dir/cacerts"

d.       Operator チャートの変更を Workload Optimization Manager プラットフォームに適用します。

次のコマンドを実行します。

kubectl apply -f \

/opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml

承認コンポーネントが再起動され、新しい設定を使用できるようになります。

 （オプション）Turbonomic UI を保護するための証明書の追加

会社のポリシーにより、信頼できる証明書を介した SSL 接続が必要な場合、Workload Optimization Manager により既知の認証局からの信頼できる証明書をインストールできます。

証明書の要求

最初の手順では、証明書を取得します。次の手順では、証明書要求を生成する方法について説明します。

1.       シェルターミナルセッションを開きます。

Workload Optimization Manager インスタンスの SSH ターミナルセッションを開きます。turbo としてログインし、前述のインストール手順で管理アカウント用に作成したパスワードを使用します。詳細については、インストール手順、「Workload Optimization Manager システム管理者アカウントの アップ」（9 ページ）を参照してください。

2.       秘密キーファイルを保存するディレクトリに変更します。

シェル セッションが Workload Optimization Manager インスタンス上にある場合は次のディレクトリを使用する必要があります。/opt/turbonomic directory:

cd /opt/turbonomic

3.       秘密キーファイルを作成して保存します。

秘密キーファイルを作成するコマンドを実行します。

この例では、秘密キーファイルの名前は myPrivate.key

openssl genrsa -out myPrivate.key 2048 です。

このファイルは後で必要になります。Workload Optimization Manager インスタンスでセッションを行っている場合は、ファイルをローカル マシンにコピーできます。

4.       証明書署名要求（CSR）を生成する情報を含むファイルを作成します。

vi certsignreq.cfg

5.       要求データを certsignreq.cfg ファイルに追加します。

このファイルに、次のコードを挿入します。山カッコでマークされたフィールド（<city> など ）は、示された値を入力します。たとえば、国、都市、会社など。

[req]

ts = 2048

prompt = no

default_md = sha256

req_extensions = req_ext

distinguished_name = dn

[dn]

C=<country, 2 letter code>

L=<city>

O=<company>

OU=<organizational unit name>

CN=<FQDN>

emailAddress=<email address>

[req_ext]

subjectAltName = @alt_names

[alt_names]

DNS.1 = <FQDN>

DNS.2 = <server’s short name>

DNS.3 = <server’s IP address>

注:

[CN] フィールドに、Workload Optimization Manager インスタンスの完全修飾ドメイン名を指定します。

代理ユーザー名は、Workload Optimization Manager インスタンスにアクセスする別の方法です。[alt_names] セクションでは、[DNS.1] フィールドの値は必須です。[DNS.1] に、Workload Optimization Manager インスタンスの完全修飾ドメイン名を指定します。[DNS.2] および [DNS.3] の値は任意です。必要に応じて、複数の DNS.<n> フィールドを追加できます。

6.       書き込みし、ファイルを終了します。

Esc を押して : wq! と入力し、Enter を押します。

7.       証明書要求ファイルを生成します。

この例では、ファイルに myRequest.csr

という名前を付けます。次のコマンドを実行します。

openssl req -new -sha256 -nodes -out myRequest.csr -key \
myPrivate.key -config certsignreq.cfg

8.       生成された要求ファイルを認証局に送信します。

Workload Optimization Manager インスタンスでファイルを生成した場合は、そのファイルをローカルマシンに転送する必要があります。リモートマシンの証明書要求ファイルへのパスは、/opt/turbonomic/myRequest.csr です。

証明機関は証明書を作成するためにこのファイルを使用します。

認証局から DER と Base64 の間のエンコーディングを選択できる場合は、Base64 を選択してください。

9.       証明書を受信したら、ディスクに保存します。

Base 64 でエンコードされた証明書でない場合は、DER から Base 64 に変換する必要があります。証明書の名前が MyCertificate.crt である場合、次のコマンドを実行します。

openssl x509 -inform der -in MyCertificate.der -out MyCertificate.crt

Workload Optimization Manager への署名証明書のインストール

署名証明書を取得したら、Workload Optimization Manager インスタンスにインストールできます。署名証明書を要求するときに取得した秘密キーと証明書ファイルを使用します。

■      myPrivate.key

■      MyCertificate.crt

署名証明書をインストールするには、次の手順を実行します。

1.       Workload Optimization Manager インスタンスの SSH ターミナルセッションを開きます。

2.       キーと証明書データを Workload Optimization Manager の chart.yaml ファイルに追加します。

ファイルを開きます。/opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml

global パラメータのセクションを見つけます。global パラメータの下で、ingress:secrets セクションを作成し、certificate、key、および name のエントリを作成します。

global パラメータは次のようになります。

global:
ingress:

secrets:

- certificate: |

-----BEGIN CERTIFICATE-----

SAMPLE PUBLIC KEY

-----END CERTIFICATE-----

key: |

-----BEGIN RSA PRIVATE KEY-----

SAMPLE PRIVATE KEY

-----END RSA PRIVATE KEY-----

name: nginx-ingressgateway-certs

追加したフィールドの場合：

■      [certificate:] このフィールドには、MyCertificate.crt ファイルの内容が保持されます。ファイルを開いて内容をコピーし、ここに貼り付けます。

■      [key:] このフィールドには、myPrivate.key ファイルの内容が保持されます。ファイルを開いて内容をコピーし、ここに貼り付け
ます。

■      [name:] このフィールドは必須で、名前は nginx-ingressgateway-certs である必要があります。

3.       CR ファイルに加えた変更を適用します。

次のコマンドを実行します。

kubectl apply -f \
kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml

4.       nginx ポッドを再起動します。

HTTPS アクセスに証明書を要求するには、nginx ポッドを再起動する必要があります。

a.      ポッドのフルネームを取得します。

kubectl get pods -n turbonomic コマンドを実行します。出力で、nginx のエントリを探します。次のようなエントリが見つかります。

nginx-5b775f498-sm2mm                        1/1     Running   0

b.       ポッドを再起動します。

次のコマンドを実行します。<UID> は、ポッド インスタンスに対して生成された ID です。

kubectl delete pod nginx-<UID>

nginx ポッドが再起動します。再起動後、Workload Optimization Manager は HTTPS アクセス用の証明書を要求します。

 （オプション）プローブ用の追加の CA 証明書の追加

ターゲットが信頼できる証明書を介した SSL 接続を必要とする場合、Workload Optimization Manager を使用すると、関連するプローブ コンポーネントに信頼できる証明書をインストールできます。

Workload Optimization Manager プラットフォームには、ターゲットに接続してターゲットのデータを検出するために使用する多くのプローブコンポーネントが含まれています。この手順では、1 つのコンポーネントである Dynatrace プローブのセットアップを想定しています。他のプローブにも同じ手順を使用し、各プローブに異なる Kubernetes シークレット名を指定できます。

注：

複数のプローブの SSL 通信を設定するには、プローブごとに固有の証明書を取得する必要があります。

プローブコンポーネントに証明書をインストールするには、特定のプローブの Kubernetes シークレット名を知っている必要があります。次の表に、構成できるプローブとプローブのシークレット名を示します。ここに記載されていないプローブに対してセキュア アクセスを構成する必要がある場合は、サポート担当者に連絡してください。

プローブコンポーネントへの署名証明書のインストール

この手順は、有効な .crt ファイルがすでにあることを前提としています。証明書ファイルがない場合は、ネットワーキング チームに作成してもらってください。

署名証明書を取得したら、プローブインスタンスにインストールできます。署名証明書を要求するときに取得した証明書ファイルを使用します。

MyCertificate.crt

プローブで署名証明書をインストールするには、次の手順を実行します。

1.       証明書をローカルマシンから Workload Optimization Manager インスタンスにコピーします。

SCP を使用して、MyCertificate.crt をローカル マシンからインスタンスの /tmp ディレクトリにコピーします。

2.        turbo ユーザーアカウントを使用して、Workload Optimization Manager インスタンスの SSH 端末セッションを開きます。

3.       プローブ コンポーネントから信頼ストアを取得します。

最初に、プローブを実行するポッドの ID を取得します。ID を取得するには、次のコマンドを実行します。

kubectl get pods

Workload Optimization Manager プラットフォームで実行されているポッドとポッドの ID が一覧表示されます。構成するポッドの ID を記録します。

CA 信頼ストアを取得するには、次のコマンドを実行します。<Probe-Pod-Id> は記録した ID です。

kubectl cp <Probe-Pod-Id>:etc/pki/ca-trust/extracted/java/cacerts cacerts

4.       証明書をポッドのキーストアにインポートします。

この手順の一環として、証明書が Base64 形式であることを確認します。プローブ コンポーネントの bash セッションにいる間に、次のコマンドを実行します。

■      chmod 775 cacerts

■       keytool -import -alias probe_certificate -file \

MyCertificate.crt -keystore cacerts -deststoretype jks \

-storepass changeit -no-prompt

MyCertificate.crt は、取得した証明書の名前です。

■      base64 cacerts > base64.txt

5.       証明書データを含む yaml ファイルを作成します。

プローブの K8s シークレット名を使用して、次の命名規則で yaml ファイルを作成します。

<Secret_Name>-secrets.yaml

たとえば、Dynatrace プローブの SSL を有効にする場合、シークレット名が dynatrace である次のような yaml ファイルを作成します。

dynatrace-secrets.yaml

a.      Workload Optimization Manager サーバーの bash セッションにいる間に、vi エディタ セッションで yaml ファイルを開きます。

vi <Secret_Name>-secrets.yaml

b.       base64 データを yaml 形式に揃えます。

: と入力して、コマンド モードを開始します。コマンドの場合、次のように入力します。空白トークンは 4 つの余白文字です。

:%s/^/    /g

 RETURN を押してコマンドを実行します。次に、vi エディタを保存して終了します。

c.       次の内容をファイルに追加します。

apiVersion: v1

kind: Secret

metadata:

name: <Secret_Name>

data:

cacerts: |

xxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxx

cacerts セクションで、生成した base64.txt データで xxx 文字を置き換えます。

6.       yaml ファイルを Workload Optimization Manager プラットフォームに適用します。

次のコマンドを実行します。<Probe-Pod-Id> は記録した ID です。

■       kubectl apply -f <Secret_Name>-secrets.yaml

7.       SSL 証明書を使用して設定するプローブごとに、chart_v1alpha1_cl_cr.yaml ファイルにエントリを追加します。

a.      Workload Optimization Manager プラットフォームで実行されているシェルセッションにおいて、テキストエディタで次のファイルを開きます。

vi /opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml

b.       設定しているプローブのエントリをファイルで検索します。前述の表にリストされているプローブ名を使用します。たとえば、Dynatrace プローブを設定している場合は、mediation-dynatrace のエントリを見つけます。エントリがファイルに存在しない場合は、global: と同じレベルの spec: セクションに追加できます。プローブ エントリは 2 つのスペースでインデントされ、javaComponentOptions は 4 つのスペースでインデントされます。

c.       プローブ エントリの下に、javaComponentOptions: の次のエントリを追加します。javaComponentOptions: -

Djavax.net.ssl.trustStore=/home/turbonomic/data/helper_dir/cacerts

たとえば、Dynatrace プローブを構成している場合、エントリは次のようになります。

mediation-dynatrace:

javaComponentOptions: -Djavax.net.ssl.trustStore=/home/turbonomic/data/helper_dir/cacerts resources:

limits:

memory: 2Gi

d.       chart_v1alpha1_cl_cr.yaml ファイルを保存して終了します。

e.       変更したファイルを Workload Optimization Manager プラットフォームに適用します。コマンドを実行します:

kubectl apply -f /opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml

（オプション）Cluster Manager の証明書の変更

ファイアウォールの内側にインストールする場合、clustermgr コンポーネントから診断をアップロードするには、その証明書を変更する必要があります。

clustermgr の証明書を変更する手順の前提として、Cluster Manager に追加する証明書がすでに生成されている必要があります。

1.       Workload Optimization Manager インスタンスの SSH ターミナルセッションを開きます。

Workload Optimization Manager のインストール時に設定したシステム管理者でログインします。

■      ユーザー名：

turbo

■      Password:

[your_private_password]

2.       clustermgr ポッドのフルネームを取得します。

コマンドを実行します:

kubectl get pods -n turbonomic | grep clustermgr

次のような結果が表示されます。

clustermgr-5f487f58f-tf84b   0/1     Running   52         2d4h

この例では、clustermgr-5f487f58f-tf84b がポッドのフルネームであり、5f487f58f-tf84b が POD_ID です。

3.       ポッドの現在の ca-bundle.crt ファイルのコピーを /tmp に保存します。

次のコマンドを実行します。<POD_ID> は、ポッドのフルネームから取得した ID です。

kubectl cp \

clustermgr-<POD_ID>:etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem \

/tmp/ca-bundle.crt

4.       バンドルに証明書を追加します。

証明書ごとにこのコマンドを繰り返します。<MY_CERT> はユーザーの証明書ファイルです。

cat <MY_CERT> >> /tmp/ca-bundle.crt

5.       変更された証明書の Kubernetes シークレットを作成します。

kubectl create secret generic clustermgr-secret --from-file=/tmp/ca-bundle.crt

6.       編集のために cr.yaml ファイルを開きます。

次に例を示します。

vi /opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml

7.       このシークレットを使用するように cr.yaml ファイルを変更します。

ファイルに以下の内容を追加します。

clustermgr:
env:

-  name: component_type
value: clustermgr

-  name: instance_id

valueFrom:
fieldRef:

fieldPath: metadata.name

-  name: instance_ip

valueFrom:

fieldRef:

fieldPath: status.podIP

-  name: serverHttpPort
value: "8080"

-  name: kafkaServers
value: kafka:9092

-  name: kafkaNamespace
valueFrom:

fieldRef:
apiVersion: v1

fieldPath: metadata.namespace

-  name: CURL_CA_BUNDLE

value: /home/turbonomic/data/ca-bundle.crt

8.       変更を保存し、cr.yaml ファイルを適用します。

kubectl apply -f \

/opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml

grep ^clustermgr でログを確認すると、診断を送信するたびに適切な curl コマンドが実行されていることがわかります。

次のコマンドを使用して、Cluster Manager ポッドの .crt ファイルを確認することもできます。<POD_ID> は、ポッドのフルネームから取得した ID です。

kubectl exec -it clustermgr-<POD_ID> bash vi /home/turbonomic/data/ca-bundle.crt

（任意）組み込みレポートの有効化

組み込みレポートは、Workload Optimization Manager プラットフォームの一部として独自のコンポーネントで実行されます。このアーキテクチャにより、パフォーマンスが向上し、ストレージ要件が軽減されます。組み込みレポートを有効にすると、複数の環境の詳細をチャート化する一連の構築済みダッシュボードに移動できます。ダッシュボードとチャートは、Grafana の可観測性プラットフォームによって強化されています。Grafana を使用すると、既存のダッシュボードを簡単にナビゲートし、コーディングせずに独自のチャートやダッシュボードを作成できます。

組み込みレポートを有効にするために使用する方法は、次のように、Workload Optimization Manager インスタンスのバージョンステータスによって異なります。

■      「スクリプトインターフェイス」（34 ページ）

Workload Optimization Manager バージョン 3.0.0 以降が新しい VM イメージ（OVA または VHD）としてインストールされている場合（「仮想マシン イメージへのインストール」（8 ページ）を参照）。enable_reporting.py スクリプトを実行して組み込みレポートを設定できます。

■      「Workload Optimization Manager の cr.yaml ファイルの編集」（35 ページ）

Workload Optimization Manager のインストールに VM イメージを使用せずに、Workload Optimization Manager を Kubernetes クラスタとしてインストールした場合、

Workload Optimization Manager のインストール用に charts_v1alpha1_xl_cr.yaml ファイルを手動で編集します。

スクリプトインターフェイス

Workload Optimization Manager をバージョン 3.0.0 以降の VM イメージとしてインストールした場合、組み込みレポートを有効にするスクリプトは、次の場所にインストール済みです。

/opt/local/bin/enable_reporting.py

このスクリプトを実行するには、次の手順を実行します。

1.       Workload Optimization Manager インスタンスへの SSH ターミナルセッションを開きます。

Workload Optimization Manager をインストールしたときに設定したシステム管理者でログインします。

■      ユーザー名： turbo

■      ユーザ名： [your_private_password]

2.       スクリプトディレクトリに移動します。

cd /opt/local/bin

3.       次のスクリプトを実行します。

./enable_reporting.py

次の 2 つのパスワードの入力を求められます。

■      Grafana 管理者パスワード。

このパスワードにより、外部 URL から、およびデータを Grafana にフィードするエクストラクタ コンポーネントから Grafana にアクセスできます。

特殊文字は使用しないでください。

重要事項：

Grafana 管理者パスワードを変更する必要があるのは、このときだけです。

この手順が完了した後で Grafana 管理者パスワードを変更すると、組み込みレポート コンポーネントはプラットフォーム内の他のコンポーネントと正しく通信できなくなります。このパスワードを後で変更した場合は、サポート担当者に連絡してください。

■      Grafana データベースパスワード。

このパスワードにより、Grafana とレポートデータを格納する Postgres データベース間の通信が可能になります。

パスワードを指定すると、スクリプトによって次のような確認メッセージが表示されます。

次の場所に新しい変更を正常に適用しました。/opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alp ha1_xl_cr.yaml.

次の場所にバックアップが書き込まれています。/opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml.bak

これは、Workload Optimization Manager の設定が正常に更新されたことを示しています。次に、変更された設定が適用されて、組み込みレポート機能が有効になります。次のようなメッセージが表示されます。

CR ファイル /opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml を適用しています。

警告：kubectl の適用は、次のいずれかによって作成されたリソースで使用する必要があります。

kubectl create --save-config または

kubectl apply xl.charts.helm.k8s.io/

xl-release configured

変更が有効になるのを待っています...

構成の変更を適用するために api ポッドを再起動します。

ポッド「api-65cf47986f-jxszd」を削除変更が正常に適用されました。埋め込みレポートが有効になりました。

4.       インストールを確認します。

次のコマンドを実行します。

./enable_reporting.py --validate

組み込みレポートが正常に有効になっている場合、スクリプトの出力は次のようになります。

明らかな埋め込みレポートのインストール エラーは検出されませんでした。

Workload Optimization Manager の cr.yaml ファイルの編集

ここでは、VM イメージのインストール用の charts_v1alpha1_xl_cr.yaml を見つけて編集する方法について説明します。Kubernetes ノードクラスタにインストールした場合、このファイルは別の場所にある可能性があります。

組み込みレポートを有効にするには、次の手順を実行します。

■      組み込みレポートを実装するプロセスを有効にします。

■      API ポッドを更新して、新しい検索機能とデータインジェスト機能を有効にします。

■      インストールを再確認します。

■      PDF レポートと電子メールサブスクリプションを有効にします（任意）。

Grafana Exporter、TimescaleDB、およびデータ抽出プロセスを有効にする必要があります。これを行うには、次のファイルを編集します。

charts_v1alpha1_xl_cr.yaml ファイル

1.       Workload Optimization Manager インスタンスへの SSH ターミナルセッションを開きます。

Workload Optimization Manager をインストールしたときに設定したシステム管理者でログインします。

■      ユーザー名： turbo

■      ユーザ名： [your_private_password]

2.       次のファイルをテキストエディタで開きます。

/opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml

3.       TimescaleDB データベースへの外部アクセス用に、Workload Optimization Manager インスタンスの IP アドレスを指定します。ファイルの global: セクションで、次の行を追加します。<Platform_IP> はインスタンスの IP アドレスです。

global:

externalTimescaleDBIP: <Platform_IP>

4.       Grafana プロセスを有効にします。

crds/charts_v1alpha1_xl_cr.yam で grafana: セクションを見つけます。yaml ファイルを開き、enabled: true の行のコメントを外します。

5.       データベースタイプとして Postgres を有効にします。

Postgres を有効にすると、組み込みレポートの履歴データの永続ストレージが設定されます。grafana: セクションで、grafana.ini: database: のサブセクションを見つけ、type: postgres の行のコメントを外します。

これまでに行った変更は、次のようになります。

global:

externalTimescaleDBIP: <Platform_IP>

...

grafana:

enabled: true

adminPassword: admin

grafana.ini:

database:

type: postgres

...

6.       管理者パスワードとデータベースパスワードを変更します。

パスワードはデフォルト値のままではなく、変更することをお勧めします。

重要事項：

パスワードには英数字のみ使用できます。

パスワードにより、さまざまな組み込みレポートコンポーネント間の通信が可能になります。一部のコンポーネントは英数字のみを受け入れます。特殊文字を使用すると、コンポーネントは通信できません。さらに、パスワードを修正する手順を実行するには、サポートエンジニアの支援が必要です。

パスワードを設定するには、次の手順を実行します。

■      Grafana 管理者パスワードを設定します。

このパスワードにより、外部 URL から、およびデータを Grafana にフィードするエクストラクタ コンポーネントから Grafana にアクセスできます。grafana: セクションで、adminPassword の値を変更します。

特殊文字は使用しないでください。

パスワードが MyNewGrafanaPassword である場合、次のように設定します。adminPassword:

MyNewGrafanaPassword を設定します。

重要事項：

Grafana 管理者パスワードを変更する必要があるのは、このときだけです。

この手順が完了した後で Grafana 管理者パスワードを変更すると、組み込みレポート コンポーネントはプラットフォーム内の他のコンポーネントと正しく通信できなくなります。このパスワードを後で変更した場合は、サポート担当者に連絡してください。

■      Grafana データベースパスワードを設定します。

このパスワードにより、Grafana とレポートデータを格納する Postgres データベース間の通信が可能になります。grafana: セクションで、grafana.ini: database: password: のサブセクションを見つけ、パスワード値を変更します。

7.       3 つの組み込みレポートプロセスを有効にします。

追加した properties: セクションのすぐ後で、同じレベルで次のエントリを追加して reporting processes: を有効にします。

reporting:
enabled: true

timescaledb:
enabled: true

extractor:
enabled: true

これらのエントリを grafana: セクションおよび properties: セクションのインデントに合わせることが重要です。行った変更は次のようになります。

global:

externalTimescaleDBIP: <Platform_IP>

...

grafana:

enabled：true

adminPassword: MyNewGrafanaPassword

grafana.ini: database:

type: postgres

password: MyNewDatabasePassword

properties:

extractor:

grafanaAdminPassword: MyNewGrafanaPassword

reporting:

enabled: true
timescaledb:

enabled: true
extractor:

enabled：true

8.       chart_v1alpha1_xl_cr.yaml ファイルの編集が完了したら、変更を保存して適用します。

■      変更を保存して、テキストエディタを終了します。

■      変更を適用します。コマンドを実行します:

kubectl apply -f \

/opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml

■      API およびエクストラクタポッドを削除します。

エクストラクタポッドを削除すると、再起動がトリガーされ、行った変更が読み込まれます。

完全なポッド名を取得するには、kubectl get pods -n turbonomic コマンドを実行します。次に、api と extractor で始まるポッドの 2 つのエントリを見つけます。たとえば、次のエントリがあるとします。

–  kubectl delete pod -n turbonomic api-7887c66f4b-shndq

–  kubectl delete pod -n turbonomic extractor-5b86976bc8-vxwz4

9.       インストールを確認します。

インストールを再確認するには、次の手順を実行します。

■      組み込みレポートポッドが実行されていることを確認します。

ポッドが実行されていることを確認するには、kubectl get pods -n turbonomic を実行します。出力には、次のようなエントリが含まれている必要があります。

■      Postgres が実行されていることを確認します。

Postgres データベースは、Workload Optimization Manager サーバーマシン上でデーモンとして実行されている必要があります。ステータスを確認するには、次のコマンドを実行します。

sudo systemctl status postgresql-12.service.

以下のような出力が表示されます。

postgresql-12.service - PostgreSQL 12 database server

Loaded: loaded (/usr/lib/systemd/system/postgresql-12.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2020-07-29 06:39:43 UTC; 14h ago

Docs: https://www.postgresql.org/docs/12/static/

Process: 1536 ExecStartPre=/usr/pgsql-12/bin/postgresql-12-check-db-dir ${PGDATA} (code=exited, s tatus=0/SUCCESS)

Main PID: 1562 (postmaster)

Tasks: 15

Memory: 145.5M

CGroup: /system.slice/postgresql-12.service

## 419 postgres: TimescaleDB Background Worker Scheduler

## 1562 /usr/pgsql-12/bin/postmaster -D /var/lib/pgsql/12/data/

## 1928 postgres: logger

## 1986 postgres: checkpointer

## 1988 postgres: background writer

## 1989 postgres: walwriter

## 1990 postgres: autovacuum launcher

## 1991 postgres: stats collector

## 1992 postgres: TimescaleDB Background Worker Launcher

## 1994 postgres: logical replication launcher

## 4054 postgres: grafana_backend grafana 10.233.90.172(33038) idle

## 4884 postgres: grafana_backend grafana 10.233.90.172(35814) idle

## 4912 postgres: grafana_reader extractor 10.233.90.172(33898) idle

##11365 postgres: grafana_reader extractor 10.233.90.172(40728) idle

##32367 postgres: TimescaleDB Background Worker Scheduler

（任意）レポートの編集、PDF、および電子メールサブスクリプション

組み込みレポートを有効にする手順を完了したら、Workload Optimization Manager のナビゲーションバーで [レポート（Reports）] をクリックして、新しいブラウザ タブで Grafana ダッシュボードを開くことができます。Grafana ダッシュボードから、既存のダッシュボードのリストを確認できます。

このビューからレポートを作成および編集し、それらのレポートをサブスクライバに送信するには、次の手順を実行する必要があります。

■      単一のレポートエディタのユーザーアカウントを設定します。

このユーザーには、レポートの作成と編集、PDF の作成、および電子メールサブスクリプションの設定権限があります。

■      Workload Optimization Manager に Grafana ライセンスをインストールします。

このライセンスは無料です。

■      Workload Optimization Manager の電子メール プロキシを構成して、Workload Optimization Manager から送信される電子メール メッセージを有効にします。

有効にすると、Workload Optimization Manager からレポートを電子メールで送信できます。

注：

Workload Optimization Manager の組み込みレポートは、Grafana ダッシュボードを使用してレポートを表示します。レポートから PDF を生成し、Grafana からサブスクライバに PDF を電子メールで送信する手順については、Grafana レポートのドキュメントを参照してください。

https://grafana.com/docs/grafana/latest/enterprise/reporting/

レポートエディタ権限を持つユーザーアカウントの設定

レポートを編集するには、ライセンスユーザーが必要です。ここで構成するユーザーアカウントは、レポートを編集してサブスクリプションを設定するユーザー権限が付与されるライセンスにアクセスできます。

ユーザーアカウントを作成するには、次の手順を実行します。

1.       Workload Optimization Manager で、[User Management] ページを表示します。

[設定（Settings）] > [ユーザー管理（User Management）] に移動します。

2.       レポートエディタとして設定するユーザーアカウントを選択します。

既存のアカウントを編集するか、新しいアカウントを作成できます。

3.       ユーザーのロールを選択します。

ユーザーは、共有ロールまたはスコープロール以外の任意のロールを持つことができます。

4.       レポートエディタの権限を設定します。

[Options] で、[DESIGNATE AS REPORT EDITOR] を選択します。

5.       必要なユーザーアカウントにその他のプロパティを設定し、ユーザーアカウントを保存します。

ユーザーアカウントの作成方法の詳細については、『Workload Optimization Manager ユーザーガイド』の「ユーザーアカウントの管理」を参照してください。

Grafana ライセンスのインストール

レポートエディタのユーザーアカウントでライセンス権限を使用するには、Grafana ライセンスをインストールする必要があります。Grafana ライセンスをインストールするには、次の手順を実行します。

1.       無料ライセンスを要求します。

サポート担当者に連絡して、ライセンスファイルを要求します。このリクエストには、レポートページへの Workload Optimization Manager の URL が含まれている必要があります。たとえば、ドメイン MyCompany.com から Workload Optimization Manager のユーザーインターフェイスにログインする場合、次の URL を指定します。

https://MyCompany.com/reports/

この URL は、指定するドメインにライセンスが適用されることを保証するために、ライセンスファイルに組み込まれています。

2.       ファイルをローカル マシンに保存します。

このファイルには、.jwt ファイル名の拡張子が付いている必要があります。

3.       .jwt ファイルを Workload Optimization Manager のライセンスとしてインストールします。

Workload Optimization Manager にライセンスをインストール場合と同じように、ライセンスファイルをインストールします。

a.      [License] ページに移動します。

[設定（Settings）] > [ライセンス（License）] に移動します。

b.       Workload Optimization Manager インスタンスにライセンスを適用します。

[Import License] をクリックします。ライセンスファイルを [Enter License] スライドアウトにドラッグします。または、ローカル マシンでライセンス ファイルを参照して開くこともできます。

ライセンスをインストールしたら、[Reports] ビューに移動します（Workload Optimization Manager のナビゲーションバーで [Reports] をクリックします）。ダッシュボードに移動して [ダッシュボードの共有（Share Dashboard）] をクリックすると、PDF の作成を選択できるようになりました。ダッシュボードの PDF を電子メールで送信するには、Workload Optimization Manager で SMTP リレーを構成する必要があります。

SMTP リレーの設定

SMTP リレーにより、Workload Optimization Manager はレポートサブスクライバに電子メールを送信できます。Workload Optimization Manager で SMTP リレーを構成するには、次の手順を実行します。

1.       [Email Settings] ページに移動します。

[設定（Settings）] > [電子メールおよびトラップ通知（Email and Trap Notifications）] に移動します。

2.       SMTP 設定を設定します。

[SMTP 設定（SMTP Settings）] フィールドでは、Workload Optimization Manager からの電子メール通信を有効にするためにネットワークで使用するメールリレー サーバーを指定します。ここで設定したリレーによって、レポートをサブスクライバに送信する電子メールが有効になります。

サーバーに認証が必要な場合は、ユーザー名とパスワードをここで入力します。次の通知の暗号化オプションも選択できます。

■      なし

■      Ssl

■      Tls

3.       Workload Optimization Manager によって送信される電子メールの返信先アドレスを設定します。[全般電子メール設定（General Email Settings）] セクションで FROM アドレスを指定します。

レポート エディタ ユーザーを作成し、Grafana ライセンスをインストールし、SMTP リレーを構成したら、ダッシュボードの PDF を作成して、サブスクライバに送信できます。

組み込みレポートのストレージ要件の見積もり

組み込みレポート機能では、TimescaleDB サーバーを使用してチャートデータが管理されます。これは、TimescaleDB 拡張機能を使用して実行される PostgreSQL サーバーです。Workload Optimization Manager インスタンスのデータストアを構成して、TimescaleDB 要件をサポートするのに十分なスペースを確保する必要があります。

最初に組み込みレポートを有効にするときは、必要なストレージ容量を見積もり、その容量に応じてプラットフォーム ストレージを構成する必要があります。組み込みレポートをすでに有効にしている場合は、現在のストレージ構成を確認し、現在および将来のニーズを満たしているか判断する必要があります。

TimescaleDB に必要なストレージは、以下の内容に依存します。

■      データ保持期間

TimescaleDB データを保存する期間。

■      使用環境のサイズ

Workload Optimization Manager が管理する使用環境内のエンティティの数。この数は時間の経過とともに変化するため、所定のデータ保持期間における使用環境内のエンティティの平均数と考える必要があります。

また、エンティティ数が増えると、他のアクティビティと同様にデータ要件も増えることに注意してください。ストレージ要件は、次のような理由で時間の経過とともに増加する可能性があります。

■      ワークロード、アプリケーション コンポーネント、ストレージ、またはホストなどのエンティティを使用環境に追加する。

■      新しいターゲットを設定する。

ストレージ見積もりルックアップテーブル

シスコでは、さまざまなトポロジと保持期間の TimescaleDB ストレージ要件を調査しています。次の表に、計算した見積もりを示します。使用環境によって要件が異なる場合があることに注意してください。

デフォルトのインストールでは、TimescaleDB に 200GB のディスククォータが付与されます。デフォルトのインストールでは、データベースが次のエンティティ数をサポートできると見積もっています。

データ保持期間の設定

デフォルトでは、Workload Optimization Manager の組み込みレポートの保持期間は 365 日に設定されます。現在設定されている保持期間を確認し、Workload Optimization Manager のユーザーインターフェイスで変更できます。

これらのアクションを実行するには、[Maintenance Options] ページに移動し、次の手順を実行します。

1.      

クリックして [Settings] ページに移動します。

2.       [Maintenance Options] を選択します。

3.       組み込みレポートのデータ保持期間を設定します。

コントロールの [Data Retention] グループで、[Saved Reporting Data] のフィールドを見つけます。組み込みレポートの現在のデータ保持期間が日単位で表示されます。デフォルトは 365 日です。

保持期間を変更するには、別の日数を入力し、[設定の適用（Apply Settings）] をクリックします。

TimescaleDB のストレージ容量の増加

Workload Optimization Manager のインストール後に組み込みレポートのストレージ要件を見積もると、TimescaleDB で使用できるストレージ容量を増やす必要があることがわかる場合があります。

プラットフォームでは、論理ボリューム管理（LVM）を使用して VM ディスクが管理されます。データベース ストレージを増やすには、新しいディスクを VM に追加し、そのディスクを使用して LVM 論理ボリューム（/dev/turbo/var_lib_mysql）を拡張する必要があります。この論理ボリュームは、履歴データベースと組み込みレポート データベースの両方を提供します。完了したら、TimescaleDB のクォータを増やします。

詳細については、「使用可能なディスク容量の増加」（21 ページ）を参照してください。

エンティティ数の見積もり

使用環境内のエンティティ数を把握するには、各検出サイクルのエンティティ数をリストする INFO メッセージを Workload Optimization Manager のログファイルで検索します。文字列 INFO [Stages$BroadcastStage] を検索できます。INFO 文字列は次のようになります。

topology-processor-6f6486df64-zf 2021-09-27 20:51:33,724 INFO [Stages$BroadcastStage] :
Successfully sent 1505 entities within topology...

この例は、トポロジに 1505 のエンティティがあることを示しています。時間の経過とともにインベントリがどのように変化するかを考慮する必要があります。たとえば、エンティティ数を時間の経過とともにチェックして、定期的に増加するかどうかを確認できます。

（任意）データエクスポータの有効化

データ エクスポートをサポートするために、Workload Optimization Manager には、データを標準形式にストリーミングできるエクストラクタ コンポーネントがあります。ストリーミングされたデータは、Elasticsearch などの検索および分析サービスにロードできます。

データエクスポータを有効にするには、次の手順を実行する必要があります。

■      エクストラクタ コンポーネントを有効にします。

エクストラクタは、Workload Optimization Manager のインストールの一部として実行されるコンポーネントです。エクストラクタはデフォルトでは有効になっていません。

■      エクストラクタのストリームをデータサービスに配信するコネクタを展開します。

エクストラクタは、Workload Optimization Manager データを Kafka トピックとして公開します。コネクタにより、データサービスがデータ トピックを使用できるようになります。このドキュメントには、サンプルの Elasticsearch コネクタの展開ファイルが含まれています。

エクストラクタ コンポーネントの有効化

データエクスポータを有効にする最初の手順では、エクストラクタ コンポーネントを有効にします。エクストラクタを有効にするには、次の手順を実行します。

1.       Workload Optimization Manager インスタンスへの SSH ターミナルセッションを開きます。

Workload Optimization Manager をインストールしたときに設定したシステム管理者でログインします。

■      ユーザー名： turbo

■      ユーザ名： [your_private_password]

2.       cr.yaml ファイルを編集して、エクストラクタ コンポーネントを有効にします。

同じ SSH セッションで、編集のために cr.yaml ファイルを開きます。次に例を示します。

vi /opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml

3.       エクストラクタ コンポーネントのエントリを編集します。

注：

組み込みレポートを有効にしている場合、エクストラクタ コンポーネントはすでに有効になっています（true に設定されています）。

データ エクスポータを有効にしなくても組み込みレポートを有効にできるのと同様に、組み込みレポートを有効にしなくてもデータ エクスポータを有効にできることを理解する必要があります。

cr.yaml ファイルでエクストラクタエントリを検索します。次のように表示されます。

extractor:

enabled: false

エントリを true に変更します。

4.       エクストラクタプロパティのエントリを編集します。

cr.yaml ファイルでエクストラクタエントリを検索します。次のように表示されます。

properties:

extractor:
enableDataExtraction: false

エントリを true に変更します。

5.       変更を保存してプラットフォームに適用します。

変更を保存したら、次の kubectl コマンドを使用して変更を適用します。

kubectl apply -f \

/opt/turbonomic/kubernetes/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml

6.       エクストラクタ コンポーネントが実行されていることを確認します。

プラットフォームでコンポーネントが再起動されるのを待ちます。次のコマンドを実行します。

kubectl get pods -n turbonomic

以下のような出力が表示されます。

エクストラクタ コンポーネントのエントリを探します。エントリが存在する場合、エクストラクタ コンポーネントはインストールされて、実行されています。

コネクタの導入

エクストラクタは、Workload Optimization Manager データを Kafka トピックとして公開します。このデータを検索および分析サービスにロードするには、該当サービスにコネクタを展開する必要があります。たとえば、データを Elasticsearch にロードする場合は、Easticsearch コネクタを展開する必要があります。

Workload Optimization Manager プラットフォームを実行するのと同じ Kubernetes ノードにコネクタを展開します。展開するには、コネクタに必要なポッドを宣言する Kubernetes Deployment を作成します。以下に、Elasticsearch へのコネクタのサンプル展開を示します。

コネクタを展開するには、エクストラクタ コンポーネントを実行しているのと同じホストに展開 yaml ファイルを作成し、次のコマンドを実行します。

kubectl create -f <MyConnectorDeployment.yaml>

<MyConnectorDeployment.yaml> は展開ファイルの名前です。

展開されたポッドの名前が es-kafka-connect である場合、コネクタが実行されていることを確認するには、kubectl get pods -n turbonomic を実行します。以下のような出力が表示されます。

コネクタを展開したら、Workload Optimization Manager の分析サイクル（約 10 分）が終了するのを待ちます。その後、データサービスに JSON としてロードされた、Workload Optimization Manager 環境からのエンティティとアクションを確認できます。

コネクタの展開例

サービスがエクスポートされたデータを処理できるように、コネクタを Elasticsearch に展開する場合、たとえば、Elasticsearch で Kibana を使用して、データダッシュボードを表示できます。次の手順を実行しているとします。

■      Workload Optimization Manager を実行しているネットワーク上の VM に Elasticsearch を展開している。Elasticsearch ホストは、Workload Optimization Manager Kubernetes ノードから確認できます。コネクタの展開でこのホストアドレスを指定します。

■      Workload Optimization Manager データをロードする Elasticsearch インデックスを設定している。コネクタの展開でこのインデックスを指定します。

次のリストは、Logstash イメージを使用してエクストラクタ データを収集し、Elasticsearch ホストにパイプする展開です。展開では、ストレージボリュームもセットアップし、エクストラクタからの入力を設定し、Elasticsearch インスタンスへの出力を設定します。

リストを確認するときは、次の点に注意してください。

■      Elasticsearch ホストの場所とログイン情報：

...

...

env:

-  name: ES_HOSTS

value: "<UrlToMyElasticsearchHost>"

-  name: ES_USER

value: "<MyElasticsearchUser>"

-  name: ES_PASSWORD

valueFrom: secretKeyRef:

name: <MyES_KeyName>

key: <MyES_Key>

Logstash は次の環境変数を使用します。

–      ES_HOSTS：エクスポートされたデータをパイプする場所を識別します。

–      ES_USER：Elasticsearch のユーザーアカウントを識別します。

–      ES_PASSWORD：アカウントのログイン用。このコネクタの例は、Elasticsearch パスワードを Kubernetes シークレットとして保存していることを前提としています。

Logstash は、ES_HOSTS 環境変数を使用して、エクスポートされたデータをパイプする場所を識別します。

■      Kafka トピックの名前：

...

logstash.conf: |
input {

kafka {

topics => ["turbonomic.exporter"]

...

Logstash の入力構成では、turbonomic.exporter という名前の単一のトピックが必要です。

■      Logstash の出力構成は、ES_HOSTS 環境変数によって識別される Elasticsearch サーバーに対するものです。<MyElasticsearchIndex> の代わりに独自の Elasticsearch インデックスを指定します。

...

output {
elasticsearch {

index => "<MyElasticsearchIndex>"
hosts => [ "${ES_HOSTS}" ]

}

}

...

サンプルリスト：Elasticsearch コネクタ

このリストは、データエクスポータの Elasticsearch コネクタを作成するために使用できる展開ファイルのサンプルです。ユーザー名やパスワードなど、一部の設定を変更する必要があることに注意してください。また、コネクタを特定の環境に準拠させるために、ポートやその他の設定を指定する必要がある場合もあります。

apiVersion: apps/v1
kind: Deployment
metadata:

name: elasticsearch-kafka-connect
labels:

app.kubernetes.io/name: elasticsearch-kafka-connect
spec:

replicas: 1
selector:

matchLabels:

app.kubernetes.io/name: elasticsearch-kafka-connect
template:

metadata:
labels:

app.kubernetes.io/name: elasticsearch-kafka-connect
spec:

containers:

-  name: logstash

image: docker.elastic.co/logstash/logstash:7.10.1
ports:

-  containerPort: 25826
env:

-  name: ES_HOSTS

value: "<UrlToMyElasticsearchHost>"

-  name: ES_USER

value: "<MyElasticsearchUser>"

-  name: ES_PASSWORD

valueFrom:

---

secretKeyRef:

name: <MyES_KeyName>

key: <MyES_Key>

resources:
limits:

memory: 4Gi
volumeMounts:

-  name: config-volume

mountPath: /usr/share/logstash/config

-  name: logstash-pipeline-volume
mountPath: /usr/share/logstash/pipeline

volumes:

-  name: config-volume
configMap:

name: logstash-configmap
items:

-  key: logstash.yml
path: logstash.yml

-  name: logstash-pipeline-volume
configMap:

name: logstash-configmap
items:

-  key: logstash.conf
path: logstash.conf

apiVersion: v1
kind: ConfigMap
metadata:

name: logstash-configmap
data:

logstash.yml: |
http.host: "0.0.0.0"

path.config: /usr/share/logstash/pipeline
logstash.conf: |

input {
kafka {

topics => ["turbonomic.exporter"]
bootstrap_servers => "kafka:9092"
client_id => "logstash"

group_id => "logstash"
codec => "json"

type => "json"

session_timeout_ms => "60000"   # Rebalancing if consumer is found dead
request_timeout_ms => "70000"   # Resend request after 70 seconds

}

}

filter {

}

output {
elasticsearch {

index => "<MyElasticsearchIndex>"
hosts => [ "${ES_HOSTS}" ]

user => "${ES_USER}"
password => "${ES_PASSWORD}"

}

}

---

apiVersion: v1
kind: Service
metadata:

labels:

app: elasticsearch-kafka-connect
name: elasticsearch-kafka-connect

spec:

ポート

- name: "25826"

port: 25826

targetPort: 25826
selector:

app: elasticsearch-kafka-connect

（オプション）プラットフォーム ノードの IP アドレスの変更

Workload Optimization Manager の標準インストール（VM イメージとしてインストール）の場合、プラットフォームの IP アドレスの変更が必要になる場合があります。たとえば、VM を移動する場合、別のアドレスを割り当てる必要がある場合があります。プラットフォームの IP アドレスを変更する必要がある場合、提供されているスクリプトを使用できます。

注：

Workload Optimization Manager インストールの IP アドレスは、できるだけ変更しないでください。これは、予期しない依存関係に影響を与える可能性のあるセンシティブなアクションです。

Workload Optimization Manager バージョン 3.0.0 以降の IP アドレスのみ、以下の手順を使用して変更する必要があります。IP アドレスを変更する必要があり、バージョン 3.0.0 以降に更新できない場合は、サポート担当者に連絡してください。

Workload Optimization Manager VM の IP アドレスを変更するには、次の手順を実行します。

1.       必要な情報を用意します。

プラットフォームの現在の IP アドレスと、使用する新しい IP アドレスの両方を特定します。

VM でシェル セッションを開いてコマンドを実行するためのログイン情報も知っている必要があります。