新規または既存のSplunk Cloud (またはSplunk Enterprise)環境にデプロイメントサーバーを追加してフォワーダーを管理する

クラウド導入チームの一員として働いていると、Splunk Cloud (またはSplunk Enterprise)を利用するお客様と毎日のように接する中で、管理を最適化して管理負荷を効果的に軽減する方法をよく尋ねられます。これは特に、Splunkを初めて利用するお客様や、当初は少数で導入したフォワーダーを数百または数千規模に増やしたいお客様にとって重要な課題です。このようなときは常に、私はデプロイメントサーバーの導入をお勧めします。

トレーニングを受けた経験豊富なSplunk管理者がいるかSplunkのプロフェッショナルサービスを契約している比較的大規模な組織では、多くの場合、デプロイメントサーバーは導入済みでしょう。

しかし、Splunk CloudやSplunk Enterpriseを初めて導入する場合、こうしたスペシャリストを置くほどの予算はないかもしれません。

この記事は、そのようなお客様を念頭に置いています。

詳しい手順や仕組みについては取り上げませんが、必要な設定、私の現場経験に基づくその拡張方法、ベストプラクティスの概要をご紹介します。ここで説明する設定は、Splunkのプロフェッショナルサービス基本設定ツールセットを参考にしました。

始める前に

この記事では、ローカルネットワークでAppをデプロイするためのデプロイメントサーバーの設定方法について簡単に説明します。アーキテクチャに関しては、データをSplunk Cloudインスタンスに送信するための設定はCloud Forwarder Appに含まれます。これは、オンプレミスのインデクサーに転送するAppやHF/UFの集約層でも代替可能ですが、ここでは説明は省略します。

まずは、この記事で使用するいくつかの用語について説明します。

デプロイメントサーバー(DS) – 中央の設定マネージャーとしての役割を果たすSplunk Enterpriseインスタンスです。他のインスタンスに設定のアップデートをデプロイします。デプロイメントサーバー、クライアント、Appで構成される設定アップデート機構全体を指すこともあります。

デプロイメントクライアント – リモート設定の対象となるSplunk Enterpriseインスタンスです。デプロイメントサーバーからアップデートを受け取ります。通常は、Splunkユニバーサルフォワーダーまたはヘビーフォワーダーがクライアントになります。

サーバークラス – デプロイメントクライアントのグループ内で共有されるデプロイメント設定のカテゴリです。1つのデプロイメントクライアントは複数のサーバークラスに属すことができます。

デプロイメントApp – 1つ以上のサーバークラスのメンバーにデプロイされるひとまとまりのコンテンツです。

では始めましょう。

最初に、DSとして使用するSplunkヘビーフォワーダー(HF/HWF)インスタンスが必要です。このインスタンスは設定済みで、すでにSplunk Cloudインスタンスにデータを送信している必要があります。この記事では、このインスタンスが/opt/splunkにインストールされていると仮定します。

仕様の面では、仮想マシンであれば問題はなく、それが推奨されます。要件は、4コアで、8 GB以上のRAMと、デプロイメントAppを扱うのに十分なディスク容量(通常は50 GB以上)があることです。また、必須ではありませんが、最大限のパフォーマンスを得るには64ビットLinuxホストが理想的です。

このサーバーは、すべてのホストと通信できるようにネットワーク上に配置する必要もあります。具体的には、ファイアウォールで、DSホストが使用するSplunk管理ポート(デフォルトはTCP:8089、DSが複数ある場合は各ポート)を開く必要があります。

さらに、いくつかのAppが必要です。

この記事では、Splunk_TA_nix、Splunk Cloudスタックに含まれる100_demostack_splunkcloud、org_deployment_client (詳細は後述)をデプロイします。

これらのAppはすべて、/opt/splunk/etc/deployment-apps/ディレクトリに置く必要があります。ここに置くと、Splunk Webインターフェイスの[フォワーダー管理]ページに表示されます。

このページからサーバークラスを作成できます。そのためにはまず、デプロイメントトポロジーを考える必要があります。簡単に言うと、DSでは、ホスト名、IPアドレス、またはマシンタイプに基づいてクライアントをフィルタリングできます。そのため、すべてのクライアントにデプロイする場合もいくつかのオプションがあります。

それではサーバークラスを作成していきましょう。

最初にすべてのクライアントを対象とするサーバークラスを作成します。ここでは名前を「All_Hosts」とします。

作成したら、このサーバークラスにAppとクライアントを追加しましょう。

まずは先ほどのorg_deployment_client Appと100_demostack_splunkcloud AppをAll_Hostsサーバークラスに追加します。

次にクライアントを追加します。現時点でこのDSに接続しているクライアントはありません。しかし、このクラスはすべてのクライアントが対象なので、[Include] (含める)ホワイトリストに「*」を追加します。

続いて、同じ手順でサーバークラスをもう1つ作成しますが、今回はSplunk_TA_nix Appを追加します。また、今回はフィルタリングを行いますが、マシンタイプでフィルタリングするにはクライアントが接続している必要があります。つまり、該当するマシンタイプのクライアントが接続していない場合は、マシン名かIPアドレスでフィルタリングする必要があります。この例では、ホスト名「nix-*, ubuntu*」のフィルタを作成しています。

作成したらDSの準備は完了です。ではクライアントを接続しましょう。

クライアントの接続

前の手順でorg_deployment_client Appを追加しましたが、このAppについて少し説明しましょう。

通常、DSに接続するようにクライアントを設定するには、CLIから追加するか(splunk set deploy-poll servername.mydomain.com:8089)、/opt/splunk/etc/system/localにあるdeploymentclient.confファイルを編集して再起動します。

これで完了です。ただし問題があります。この作業がローカルである点です。そのため、クライアントを追加するたびに、手動で設定を行う必要があります。自動化することもできますが、もっと良い方法があります。

それは、DSに接続するためのAppを作成することです。こうしてできたのがorg_deployment_clientです。

Splunk PS基本設定から抜粋したテンプレートは次のようになります。

[deployment-client]
# Set the phoneHome at the end of the PS engagement
# 10 minutes
# phoneHomeIntervalInSecs = 600

[target-broker:deploymentServer]
# Change the targetUri
targetUri = deploymentserver.splunk.mycompany.com:8089

コメントにもあるとおり、targetUriにDSのアドレスと管理ポートを指定します。ここではIPアドレスではなくDNS名を使用することを強くお勧めします。6.3以降では、ロードバランサーを指定することもできます(便利になりました)。

ここからが佳境です。org_deployment_client AppをすべてのUFにデプロイします(UFのインストール時または導入後)。これにより、今後、targetUriとphoneHomeInternvalInSecsを変更するときに、フォワーダーを1つ1つ設定する必要がなくなります。デプロイ方法はたくさんあります。git/mercurial/cvs/スクリプトを使用することも、デプロイを自動化するカスタムインストールパッケージを作成することも、インストール後に手動でデプロイすることもできます。どの方法でもかまわないので、とにかくデプロイしましょう。

完了したら、クライアント(org_deployment_clientデプロイ済み)を追加します。今回デプロイしたAppはいずれも、DSからのダウンロード後にSplunkを再起動するように設定されていないため、手動で再起動する必要があります。再起動後、[フォワーダー管理]画面で、ホストとAppが追加されていることを確認します。

これで、ホストはマシンデータをSplunk Cloudに送信するようになります。これには、有効なTAとモジュール入力も含まれます。

注意事項と推奨事項

覚えておいていただきたい注意事項と推奨事項がいくつかあります。

1) サーチヘッドクラスターメンバー(SHC) – これらはDSの対象にはできません。デプロイヤーノードがこの機能を担います。

2) インデックスクラスターメンバー – これらはDSの対象にはできません。クラスターマスターノードが設定のデプロイを担います。

3) 自動化の使用(Puppet/Chef/Ansibleなど) – DSと併用するときは注意してください。設定が消えたり無効になったりする可能性があります。

4) serverclasses.confを変更するときはまず開発環境でテストします。

5) サーバークラスやAppの命名規則を標準化します。ここではorg_deployment_clientを使用しましたが、mycompany_deploymentclient_securelanやmycompany_deploymentclient_dmz1でもかまいません。

デプロイサーバーには、ここで説明した以外にも便利な機能がたくさんあります。教育チームが提供するトレーニングやSplunk PSを利用して、DSのさまざまな機能や拡張方法を学ぶことができます。興味がありましたら、お問い合わせください。

参考：
Capacity Planning Manual for Splunk Enterprise
Updating Splunk Enterprise Instances – Deployment server architecture
Updating Splunk Enterprise Instances – Plan a deployment
Updating Splunk Enterprise Instances – Configure deployment clients

Splunkをどうぞご活用ください。
Eric Six、Dennis Bourg

このブログはこちらの英語ブログの翻訳です。