Splunk Enterprise 6.2.0
分散サーチ
作成：2014 年 11 ⽉ 21 ⽇ 午後 4 時 11 分
Copyright (c) 2015 Splunk Inc. All Rights Reserved
Table of Contents
分散サーチの概要
分散サーチについて
サーチのシナリオ例
サーチヘッドがサーチピアに送信する内容
分散サーチのライセンス
バージョンの互換性
4
4
4
6
7
7
分散サーチの設定
設定の概要
サーチヘッドの指定
サーチピアの追加
サーチピアの削除
ナレッジバンドルサイズの制限
分散サーバー名の管理
ベストプラクティス：サーチヘッドデータのインデクサー層への転
送
分散サーチ・グループの作成
7
7
8
9
11
11
12
12
ナレッジバンドルのマウント
マウントバンドルについて
マウントバンドルの設定
サーチヘッドプーリングでのマウントバンドルの使⽤
14
14
15
17
サーチヘッド・クラスタリングの概要
サーチヘッド・クラスタリングについて
サーチヘッド・クラスタリングのアーキテクチャ
18
18
19
サーチヘッド・クラスタリングのデプロイ
サーチヘッド・クラスタのシステム要件とその他のデプロイに関す
る検討事項
サーチヘッド・クラスタのデプロイ
サーチヘッド・クラスタとインデクサー・クラスタの統合
クラスタ内のサーチヘッドのサーチ・ピアへの接続
ロード・バランサーとサーチヘッド・クラスタリングの使⽤
サーチヘッド・プールからサーチヘッド・クラスタへの移⾏
スタンドアロンのサーチヘッドからサーチヘッド・クラスタへの移
⾏
22
22
サーチヘッド・クラスタリングの設定
サーチヘッド・クラスタの設定
サーチヘッド・クラスタの複製データ保持数の選択
サーチヘッド・クラスタの秘密鍵の設定
31
31
32
33
サーチヘッド・クラスタのメンバーの更新
サーチヘッド・クラスタへの設定変更の配布⽅法
クラスタが複製する設定の更新
デプロイヤーを使った App と設定の更新の配布
33
33
34
36
サーチヘッド・クラスタリングの管理
クラスタ・メンバーの追加
クラスタ・メンバーの削除
アドホック・サーチのみを実⾏するようにクラスタ・メンバーを設
39
39
41
42
13
25
28
28
29
29
30
定
サーチヘッド・クラスタのステータスの表⽰
サーチヘッド・クラスタ・メンバー障害への対処
サーチヘッド・クラスタの再起動
43
44
45
サーチヘッド・クラスタリングのトラブルシューティング
デプロイの問題
実⾏時の検討事項
46
46
46
サーチヘッドプーリング
サーチヘッドプーリングの概要
サーチヘッドプールの作成
ロードバランサーでのサーチヘッドプールの使⽤
その他のプーリング操作
設定変更の管理
デプロイサーバーとサーチヘッドプーリング
設定更新タイミングの選択
サーチヘッドプールのアップグレード
46
46
48
50
50
51
51
51
51
分散サーチの動作
分散サーチでの認証の仕組み
ユーザーによる分散サーチの制御
51
52
53
分散サーチのトラブルシューティング
⼀般的な設定に関する問題
サーチヘッドプーリング設定に関する問題
分散サーチのエラーメッセージ
53
53
54
55
分散サーチの概要
分散サーチについて
重要： このマニュアルをお読みになる前に、『分散デプロイ』マニュアルを参照して、Splunk Enterprise 分散
デプロイ環境の基礎を学習してください。
分散サーチ では、サーチヘッド と呼ばれる Splunk Enterprise インスタンスが⼀連のインデクサーにサーチリク
エストを送信します。インデクサーは、各⾃のインデックスに対して実際のサーチを実⾏します。次にサーチヘッ
ドは返された結果をまとめて、ユーザーに表⽰します。⼀般的なシナリオでは、1 台のサーチヘッドが複数のイン
デクサーのサーチを管理します。
使⽤事例
分散サーチの主な使⽤事例を以下に⽰します。
パフォーマンス向上のための⽔平スケーリング。 分散サーチでは、複数の Splunk Enterprise インスタ
ンスにまたがってインデックス作成とサーチ処理の負荷を分散する⼿段を提供することで、⽔平⽅向のス
ケーリングを容易にし、⼤量のデータのインデックス作成とサーチを実現しています。
アクセス制御： 分散サーチを使ってインデックスデータへのアクセスを制御することができます。⼀般的な
環境では、たとえばセキュリティ担当者などの⼀部のユーザーが全社規模のデータにアクセスする必要があ
り、他のユーザーは各⾃が担当する業務のデータにのみアクセスします。
各地域に分散しているデータの管理： 分散サーチにより、ローカルのオフィスに各⾃のデータにアクセス
させながら、企業レベルでアクセスを集中管理することができます。シカゴとサンフランシスコのオフィス
は各⾃のローカルデータのみにアクセスできます。⼀⽅ニューヨーク本社は、⾃⼰のローカルデータ以外に
も、シカゴとサンフランシスコのデータにアクセスすることができます。
分散サーチのコンポーネント
サーチを担当する Splunk Enterprise インスタンスは、サーチヘッド と呼ばれています。分散サーチに関与する
インデクサーは、サーチピア またはインデクサーノード と呼ばれています。
デフォルトでサーチヘッドは、すべてのサーチピアに対してサーチを実⾏します。クエリに splunk_server フィー
ルドを指定することで、サーチを 1 台または複数台のサーチピアに制限することができます。『サーチマニュア
ル』の「1 つまたは複数のサーチピアにまたがるサーチ」を参照してください。
サーチヘッド・クラスタ
サーチヘッド・クラスタ は、スケーラビリティと⾼可⽤性を提供するために連係動作するサーチヘッドのグルー
プです。これは、⼀連のサーチ・ピアにまたがってサーチを実⾏するためのリソースとして中⼼的な役割を果たし
ています。
クラスタ内のサーチヘッドは、ほとんどの場合相互に交換可能です。クラスタの任意のメンバーから、同じサー
チ、ダッシュボード、ナレッジ・オブジェクトなどにアクセス、実⾏することができます。
代わりに⼀連のサーチピアに対して、複数の独⽴したサーチヘッドを実⾏させることができます。ただし、複数の
サーチヘッドのアクティビティを管理する場合は、それをサーチヘッド・クラスタ内にデプロイする必要がありま
す。
「サーチヘッド・クラスタリングについて」を参照してください。
インデクサー・クラスタとサーチヘッド
インデクサー・クラスタ もサーチヘッドを使⽤して、⼀連のインデクサーまたはピア・ノード に対するサーチを
実⾏します。サーチヘッドがインデクサー・クラスタの⼀部となる場合、サーチヘッドのデプロイおよび設定⽅法
はまったく違う物になります。インデクサー・クラスタ内のサーチヘッドの設定については、『インデクサーとイ
ンデクサー・クラスタの管理』マニュアルの「サーチヘッドの設定」を参照してください。
サーチのシナリオ例
⽔平スケーリング⽤の単純な分散サーチの例を以下の図に⽰します。この例では、1 台のサーチヘッドが 3 台の
サーチヘッドに対してサーチを⾏います。
4
この図は、アクセス制御のための分散サーチを表しています。セキュリティ部⾨のサーチヘッドは、すべてのサー
チピアにアクセスすることができます。各サーチピアは、⾃⼰のデータに対してサーチを実⾏することができま
す。また、部⾨ A のサーチピアは、⾃⼰のデータと部⾨ B のデータの両⽅にアクセスすることができます。
以下の図は、ロードバランシング構成のフォワーダーが、⼀連のインデクサーにデータを転送している例を表して
5
います。専⽤サーチヘッドの他に、各インデクサー上にサーチヘッドが存在ししています。すべてのサーチヘッド
が、⼀連のインデクサー全体に対してサーチを実⾏できます。
ロードバランシングの詳細については、『データの転送』マニュアルの「ロードバランシングの設定」を参照して
ください。
サーチヘッドがサーチピアに送信する内容
分散サーチを開始すると、サーチヘッドはその ナレッジオブジェクト をサーチピアに複製、分散します。ナレッ
ジオブジェクトには、保存済みサーチ、イベントタイプ、およびインデックスのサーチに⽤いられるその他のエン
ティティなどが含まれます。サーチヘッドは、サーチピアにサーチを適切に実⾏させるために、そのような情報を
サーチピアに配布する必要があります。サーチヘッドが配布する⼀連のデータは、ナレッジバンドル と呼ばれて
います。
ナレッジバンドルの内容
サーチピアはサーチヘッドのナレッジバンドルを使ってサーチを実⾏します。分散サーチの実⾏時、ピアはローカ
ルナレッジオブジェクトを知っていません。サーチヘッドのナレッジバンドル内のオブジェクトにのみアクセスす
ることができます。
⼀般的にバンドルには、$SPLUNK_HOME/etc/system、$SPLUNK_HOME/etc/apps、および
ファイル (設定ファイルや資産) のサブセットが含まれています。
$SPLUNK_HOME/etc/users
からの、
ナレッジバンドルの配布処理は、デフォルトではサーチヘッドの App の内容を受信することを意味しています。
App にピアとの共有が不要な、⼤きいバイナリが含まれている場合、distsearch.conf 内の [replicationWhitelist]
または [replicationBlacklist] スタンザを使って、バンドルのサイズを削減することができます。このマニュアル
の「ナレッジバンドルサイズの制限」を参照してください。
サーチヘッド上で、ナレッジバンドルは $SPLUNK_HOME/var/run ディレクトリに存在しています。完全版のバンドル
の場合拡張⼦は .bundle に、データバンドルの場合は .delta になります。これらは tar ファイルで、tar tvf を実
⾏してその内容を参照することができます。
サーチヘッドからのナレッジバンドルは、各サーチピアの $SPLUNK_HOME/var/run/searchpeers ディレクトリに配布さ
れます。ナレッジバンドルは、サーチピアとサーチヘッドでは異なる場所に保管されるため、サーチスクリプトで
リソースへのパスをハードコード化しないようにしてください。
ナレッジバンドルのマウントによる効率の向上
デフォルトでサーチヘッドは各サーチピアにナレッジバンドルを複製、配布します。効率を向上するために、バン
ドルの複製処理を省いてナレッジバンドルのディレクトリにサーチピアをマウントさせることができます。ナレッ
ジバンドルにマウントする場合、マウントバンドル と呼ばれています。バンドルのマウント⽅法の詳細は、「ナ
レッジバンドルのマウント」を参照してください。
ユーザー認証
6
分散サーチのすべての認証は、サーチヘッドから⾏われます。サーチピアへのサーチリクエストへの送信時、サー
チヘッドは認証情報も送信します。この場合、サーチを実⾏しているユーザー名、ユーザーのロール、および認証
情報を含んでいる分散 authorize.conf ファイルの場所をサーチピアに知らせます。
分散サーチのライセンス
分散デプロイ環境内の各サーチピアは、適切なライセンスプールにアクセスできなければなりません。
インデックス作成を⾏わない、またはサマリーインデックスのみを使⽤するサーチヘッドは、フォワーダーライセ
ンスを使⽤することができます。他の種類のインデックス作成処理を⾏うサーチヘッドは、ライセンスプールにア
クセスする必要があります。
ライセンスに関する問題の詳細は、『インストールマニュアル』の「サーチヘッドのライセンス」を参照してくだ
さい。
バージョンの互換性
最新のサーチ機能を有効活⽤するために、サーチヘッドとサーチ・ピアは同時にアップグレードすることをお勧め
します。できない場合は、このトピックに記載されているバージョン互換性のガイドラインに従ってください。
サーチヘッドとサーチピアの互換性
インデクサー・クラスタに参加しているサーチヘッドを除いて、6.x サーチヘッドは 6.x および 5.x のサーチ・ピ
アと互換性があります。サーチヘッドはサーチ・ピアと同じかそれ以降のバージョンでなければなりません。
6.x サーチヘッドは、5.x サーチピアと互換性があります。
5.x サーチヘッドは、6.x サーチピアと互換性はありません。
これらのガイドラインは、スタンドアロンのサーチヘッドと、サーチヘッド・クラスタに参加しているサーチヘッ
ドの両⽅に適⽤されます。
重要： インデクサー・クラスタには、別の互換性制限があります。『インデクサーとインデクサー・クラスタの
管理』の「Splunk Enterprise バージョンの互換性」を参照してください。
バージョン混在分散サーチの互換性
5.x サーチピアに対して 6.x サーチヘッドを利⽤することはできますが、理解しておく必要があるいくつかの問題
が存在しています。6.x の機能群を有効活⽤するために、サーチヘッドとサーチピアを同時にアップグレードする
ことをお勧めします。
このセクションは互換性の問題について説明しています。
バージョン混在デプロイ環境での 6.x の機能
6.x サーチヘッドを 5.x サーチピアに対して使⽤する場合は、以下の事項に注意してください。
サーチヘッド上では、レポート⾼速化を使⽤しない場合にのみデータモデルを使⽤できます。
サーチヘッド上でピボットを使⽤することができます。
サーチヘッド上で予測分析 (predict) コマンドを使⽤できます。
リモートタイムライン機能はパフォーマンス低下の可能性がある
デフォルトで 6.x サーチヘッドはサーチピアにリモートタイムラインを⽣成するように指⽰します。サーチピアが
6.x の場合は何の問題もありませんが、5.x のサーチピアはタイムラインの⽣成⽅法を知りません。そのためサー
チ速度が⼤幅に低下してしまいます。
この問題に対処するには、サーチヘッド上の
limits.conf
に、以下の属性を追加します。
[search]
remote_timeline_fetchall = false
この変更を⾏った後は、サーチヘッドを再起動する必要があります。
重要： すべてのサーチピアを 6.x にアップグレードしたら、この属性を削除する必要があります。
分散サーチの設定
設定の概要
重要： サーチヘッド・クラスタの設定の詳細は、「サーチヘッド・クラスタリングの概要」から始まるサーチ
ヘッド・クラスタに関する⼀連の章を参照してください。
分散サーチ を有効にするための基本的な設定は単純です。特定の Splunk Enterprise インスタンスをサーチヘッ
ド として指定して、⼀連のインデクサーへの分散サーチ接続を確⽴するだけです。
その他にもさまざまな種類の設定⽅法が存在しています。
7
サーチヘッドのタイプ
⼀般的な分散サーチデプロイ環境では、専⽤のサーチヘッド (サーチ実⾏担当) が使⽤されています。専⽤のサー
チヘッドは、外部データのインデックス作成を⾏いません。
ただし、1 台または複数台のサーチピア (インデクサー) をサーチヘッドとして動作させることもできます。専⽤
のサーチヘッドの代わりに、または専⽤のサーチヘッドに加えて、これらの両⽅の機能を兼務するサーチヘッドを
使⽤することもできます。さまざまな分散サーチトポロジーの例は、「サーチシナリオの例」を参照してくださ
い。
分散サーチの設定
分散サーチの設定は、基本的な 3 つのステップから成り⽴っています。
1. Splunk Enterprise インスタンスをサーチヘッドとして指定します。「サーチヘッドの指定」を参照してくださ
い。
2. サーチヘッドにサーチピアを追加します。「サーチピアの追加」を参照してください。
3. サーチピアにデータ⼊⼒を追加します。⼊⼒の追加はインデクサーの場合と同様に、サーチピア上で直接または
フォワーダー経由で設定できます。データ⼊⼒の詳細は、『データの取り込み』マニュアルを参照してください。
分散サーチ環境でのシステム・クロックの同期
分散サーチに参加する Splunk Enterprise インスタンスを実⾏するマシンは、仮想マシンまたは物理マシンを問
わず、すべてシステム・クロックを同期する必要があります。特にサーチヘッドとサーチ・ピアではこのことが重
要です。サーチヘッド・プーリングまたはマウントされたバンドルの場合は、共有ストレージ・ハードウェアもこ
れに含まれます。そうしないと、バンドルの複製失敗、サーチ失敗、または過去のサーチ結果の早期期限切れな
ど、さまざまな問題が発⽣する可能性があります。
使⽤する同期⽅法は、ご利⽤のマシンによって異なります。Splunk Enterprise を実⾏するマシンとオペレーティ
ング・システムのシステム・マニュアルを参照してください。⼤部分の環境では、ネットワーク・タイム・プロト
コル (NTP) が最適です。
その他のタイプの設定
その他のタイプの設定には、以下のようなものがあります。
サーチピアの削除。
ナレッジバンドルのサイズの制限。
分散サーバー名の管理。
ナレッジバンドルの管理。
認証の設定。
注意： Splunk インデクサー・クラスタ はサーチヘッドを使⽤して、⼀連のインデクサーまたはピア・ノード に
対するサーチを実⾏します。サーチヘッドがインデクサー・クラスタの⼀部となる場合、サーチヘッドのデプロイ
⽅法はまったく違う物になります。インデクサー・クラスタ内のサーチヘッドのデプロイについては、『インデク
サーとインデクサー・クラスタの管理』マニュアルの「サーチヘッドを有効にする」を参照してください。
サーチヘッドの指定
フォワーダーを除き、各 Splunk Enterprise インスタンス上ではデフォルトで分散サーチ が有効になっていま
す。このことは、各 Splunk Enterprise サーバーがサーチヘッド として、サーチピア と称される⼀連のインデク
サーグループのサーチを管理することができます。
⼀部の状況下では、単⼀のインスタンスにサーチヘッドとサーチピアの両⽅の機能を担当させることも可能です。
ただし、それ以外の場合は専⽤の サーチヘッドを⽤意します。専⽤のサーチヘッドはサーチのみを担当します。
外部データのインデックス作成は⾏いません。
専⽤のサーチヘッドのインストール
専⽤のサーチヘッドをインストールするには、以下の⼿順に従ってください。
1. 『キャパシティ・プランニング』マニュアルを参考にハードウェアのニーズを判断します。
2. 『インストール・マニュアル』の、ご利⽤のオペレーティング・システムに応じた記事を参照し、Splunk
Enterprise をインストールします。
3. Enterprise ライセンス・グループにサーチヘッドを追加します。外部データのインデックスを作成しない、専
任のサーチヘッドの場合でも、この作業を⾏う必要があります。詳細は、「Splunk Enterprise ライセンスのタイ
プ」を参照してください。
4. サーチヘッドから、サーチ対象となるすべてのインデクサー (サーチピア) への分散サーチを確⽴します。⽅法
については、「サーチピアの追加」を参照してください。
5. サーチヘッドにログインして、すべてのサーチピアにまたがるサーチを実⾏します (例：* のサーチなど)。結果
の splunk_server フィールドを調べます。このフィールドにすべてのサーチピアが記載されていることを確認して
ください。
6. 認証の設定については、『Splunk Enterprise のセキュリティ』マニュアルを参照してください。
8
重要： 専⽤のサーチヘッドを、外部データのインデックスを作成するようには設定しないでください。ライセン
ス違反になります。
⾮専⽤のサーチヘッドの設定
単⼀のインスタンスにサーチヘッドとサーチピア (インデクサー) の両⽅の機能を担当させる場合は、『インス
トールマニュアル』の「Splunk Enterprise ライセンスについて」を参考に、標準のライセンスを持つ Splunk
Enterprise インスタンスとしてサーチヘッドをインストールします。標準ライセンスを持つインスタンスは、外
部データのインデックスを作成することができます。既存のインデクサーをサーチヘッドとして設定することもで
きます。
インスタンスをサーチヘッドとサーチピアの両⽅の機能を担当するように設定したら、サーチピアを追加します。
「サーチピアの追加」を参照してください。
サーチピアの追加
任意の Splunk Enterprise インスタンスがサーチヘッド として、サーチピア と称される⼀連のインデクサーグ
ループのサーチを管理することができます。デフォルトで分散サーチ機能 は有効になっています。
分散サーチをアクティブにするには、サーチヘッドとして指定した Splunk Enterprise インスタンスにサーチピ
アを追加します。そのためには、サーチピアを⼿動で追加します。その他さまざまな設定オプションを利⽤できま
すが、⼀般的にはデフォルト値を変更する必要はありません。
インスタンスをサーチヘッドまたはサーチピアとして設定する場合、以下の違いを覚えておいてください。
サーチヘッド は、サーチピアのリストを維持管理する必要があります。そうしないと、何もサーチできませ
ん。専⽤のサーチヘッドは、外部データの取り込みを⾏いません。
サーチピア には、外部データの取り込みを設定する必要があります。そうしないとインデックスを作成でき
ません。
これらの役割の違いは特に意識する必要はありません。Splunk Enterprise インスタンスはサーチヘッドとサーチ
ピアの両⽅として機能することができます。
これらのクラスタのシナリオには、サーチ・ピアを設定するための特別な要件があります。
インデクサー・クラスタ はサーチヘッドを使⽤して、⼀連のインデクサーまたはピア・ノード に対する
サーチを実⾏します。サーチヘッドがインデクサー・クラスタの⼀部となる場合、サーチヘッドのデプロイ
および設定⽅法はまったく違う物になります。インデクサー・クラスタ内のサーチヘッドの設定について
は、『インデクサーとインデクサー・クラスタの管理』マニュアルの「サーチヘッドの設定」を参照してく
ださい。
サーチヘッド・クラスタには、サーチ・ピアをサーチヘッドに接続する際に検討する必要がある、特定の制
限事項があります。「クラスタ内のサーチヘッドのサーチ・ピアへの接続」を参照してください。
設定の概要
以下の⽅法でサーチヘッドの分散サーチを設定することができます。
Splunk Web
Splunk CLI
distsearch.conf
設定ファイル
たいていの場合、Splunk Web がお勧めの⽅法です。
設定はサーチヘッド上で⾏います。主なステップは、サーチヘッドのサーチピアを指定することです。分散サーチ
機能はデフォルトで有効になっています。
重要： インデクサーをサーチピアとして機能させる前に、デフォルトの「changeme」からパスワードを変更す
る必要があります。そうしないと、サーチヘッドがピアを認証することはできません。
⼀般的にパスワードの変更以外は、サーチピアの設定を変更する必要はありません。ピアへのアクセスは、公開鍵
認証を使って制御することができます。ただし、ピアにアクセスさせるためにナレッジバンドル をマウントする
場合は、サーチピアの設定作業が必要 になります。「ナレッジバンドルのマウント」を参照してください。
Splunk Web の使⽤
サーチピアの指定
サーチピアを指定するには；
1. サーチヘッドで Splunk Web にログインして、ページ上部にある [設定] クリックします。
2. [分散環境] の [分散サーチ] をクリックします。
3. [サーチピア] をクリックします。
4. [サーチピア] ページで、[新規] を選択します。
5. サーチピアを指定し、任意の認証の設定を⾏います。
6. [保存 ] をクリックします。
9
7. 各サーチピアに対して同じ作業を繰り返します。
その他の分散サーチ設定
その他の設定を⾏うには：
1. サーチヘッドで Splunk Web にログインして、ページ上部にある [設定] クリックします。
2. [分散環境] の [分散サーチ] をクリックします。
3. [分散サーチの設定] をクリックします。
5. 必要に応じて他の設定を⾏います。
6. [保存 ] をクリックします。
CLI の使⽤
サーチピアを指定するには；
1. サーチヘッド上の
$SPLUNK_HOME/bin/
ディレクトリに移動します。
2. 追加する各サーチピアに対して、splunk
add search-server
コマンドを発⾏します。
例：
splunk add search-server -host 10.10.10.10:8089 -auth admin:password -remoteUsername admin -remotePassword
passremote
以下の事項に注意してください。
サーチピアの IP アドレスと管理ポートを指定するには、-host フラグを指定します。
ローカルインスタンス (サーチヘッド) とリモートインスタンス (サーチピア) の両⽅の資格情報を指定しま
す。ローカル資格情報の場合は -auth フラグを、リモート資格情報の場合は -remoteUsername および remotePassword フラグを使⽤します (この例ではサーチピア 10.10.10.10)。リモート資格情報は、サーチピア
の管理者レベルのユーザーのものでなければなりません。
distsearch.conf の編集
たいていの場合は、Splunk Web にあるオプションで⼗分に分散サーチ環境を設定できます。ただし、⼀部の⾼
度な設定を⾏うには distsearch.conf を直接編集する必要があります。設定オプションの詳細は、distsearch.conf
ファイルを参照してください。
設定ファイルの⼀般情報については、「設定ファイルについて」を参照してください。
サーチ・ピアの追加
分散サーチを実⾏するには：
1. サーチヘッドで
distsearch.conf
2. ⼀連のサーチ・ピアを
ファイルを作成、または編集します。
[distributedSearch]
スタンザに追加します。例：
[distributedSearch]
servers = 192.168.1.1:8059,192.168.1.2:8059
3. サーチヘッドを再起動します。
キーファイルの配布
Splunk Web または CLI でサーチピアを追加する場合、認証は⾃動的に処理されます。ただし、distsearch.conf
を編集してピアを追加する場合、キーファイルを⼿動で配布する必要があります。上記の説明に従ってサーチ・ピ
アを追加してサーチヘッドを再起動したら：
1. サーチヘッドから
<searchhead_name>
ファイルを、各サーチピアの
にコピーします。
$SPLUNK_HOME/etc/auth/distServerKeys/trusted.pem
$SPLUNK_HOME/etc/auth/distServerKeys/<searchhead_name>/trusted.pem
はサーチヘッドの
serverName
です。「分散サーバー名の管理」を参照してください。
単⼀のピアからの複数のサーチヘッドの認証
複数のサーチヘッドが単⼀のピアをサーチすることができます。このピアは、各サーチヘッドの証明書のコピーを
保管している必要があります。
サーチ・ピアは、各サーチヘッドのキーを
保管します。
$SPLUNK_HOME/etc/auth/distServerKeys/<searchhead_name>
10
ディレクトリに
たとえば、2 台のサーチヘッド A と B があり、その両⽅が特定の 1 台のサーチピアをサーチする必要がある場合
は、以下の作業を⾏います。
1. サーチ・ピアで、$SPLUNK_HOME/etc/auth/distServerKeys/A/ および
トリを作成します。
2. A の
trusted.pem
ファイルを
$SPLUNK_HOME/etc/auth/distServerKeys/B/
$SPLUNK_HOME/etc/auth/distServerKeys/A/
$SPLUNK_HOME/etc/auth/distServerKeys/B/
に、B の
trusted.pem
ディレク
を
にコピーします。
3. サーチピアを再起動します。
サーチ・ピアのグループ化
サーチ・ピアを分散サーチ・グループにグループ化することができます。そうすることによって、サーチ・ピアの
⼀部を対象にサーチを実⾏することができます。「分散サーチ・グループの作成」を参照してください。
サーチピアの削除
Splunk Web または CLI を使って、サーチヘッドからサーチピアを削除することができます。お気づきかもしれ
ませんが、この作業を⾏うと、サーチヘッドのそのサーチピアに対する知識が単純に削除されます。ピア⾃体には
何の影響もありません。
Splunk Web を使ったサーチピアの削除
サーチヘッドの Splunk Web にある [分散サーチ] ページから、サーチピアを削除することができます。
注意： この作業では、単純にサーチヘッドからサーチピアのエントリが削除されます。サーチピアからサーチ
ヘッドのキーが削除されることはありません。たいていの場合、このことが問題になることはありませんし、何の
対処をする必要もありません。
CLI を使ったサーチピアの削除
サーチヘッド上で
splunk remove search-server
コマンドを実⾏し、サーチヘッドからサーチピアを削除します。
以下の事項に注意してください。
サーチヘッドの資格情報のみを指定するには、-auth フラグを使⽤します。
ピアの場所と splunkd 管理ポートを指定するには、-url フラグを使⽤します。デフォルトで管理ポートは
8089 ですが、ご利⽤のデプロイ環境によっては異なる場合もあります。
この例は、10.10.10.10:8089 サーチピアを削除します。
splunk remove search-server -auth admin:password -url 10.10.10.10:8089
ピアの削除後に、成功したことを知らせるメッセージが表⽰されます。
信頼関係の無効化
必要に応じて、サーチピアとサーチヘッド間の信頼関係を無効にすることができます。そのためには、サーチピア
上の $SPLUNK_HOME/etc/auth/distServerKeys/<searchhead_name> から、trusted.pem ファイルを削除します。
注意： <searchhead_name> は、サーチヘッドの
serverName
です。「分散サーバー名の管理」を参照してください。
通常このステップは不要です。
ナレッジバンドルサイズの制限
ナレッジバンドル は、サーチを可能にするためにサーチヘッドが複製してサーチピアに配布するデータです。こ
のバンドルの内容と⽬的については、「サーチヘッドがサーチピアに送信する内容」を参照してください。
デフォルトでナレッジバンドルには、すべてのサーチヘッドの App のほぼすべてのコンテンツが含まれるため、
ナレッジバンドルが⾮常に巨⼤になることもあります。バンドルのサイズを制限するために、レプリケーションの
ホワイトリストを作成することができます。そのためには、distsearch.conf を編集して [replicationWhitelist] ス
タンザを指定します。
[replicationWhitelist]
<name> = <whitelist_regex>
...
ホワイトリストの正規表現を満たしているすべてのファイルが、サーチヘッドがサーチピアに配布するバンドルに
含まれます。複数の正規表現を指定した場合、それらのファイルをまとめたものがバンドルに含まれます。
以下の例では、拡張⼦が「.conf」または「.spec」のすべてのファイルがナレッジバンドルに含まれます。
11
[replicationWhitelist]
allConf = *.conf
allSpec = *.spec
allConf や allSpec などの名前は、設定をレイヤー化 (優先順位設定) する⽬的でのみ使⽤されます。つま
り、distsearch.conf のグローバルコピーとローカルコピーの両⽅がある場合、1 つの正規表現のみローカルコピー
版を優先するように設定することができます。たとえば、前述の例がグローバルコピーと仮定して、ローカルコ
ピーにはホワイトリストに以下のように指定する場合を考えてみましょう。
[replicationWhitelist]
allConf = *.foo.conf
2 つの conf ファイルはレイヤー化され、ローカルコピーが優先されます。このようにして、サーチヘッドはこれ
らの 2 つの正規表現を満たすファイルのみを配布します。
allConf = *.foo.conf
allSpec = *.spec
設定ファイルの属性の優先度については、『管理マニュアル』の「属性ファイルの優先度」を参照してください。
また、[replicationBlacklist] スタンザを使ってレプリケーションのブラックリストを作成することもできます。ブ
ラックリストはホワイトリストよりも優先されます。詳細は『管理マニュアル』の「distsearch.conf」を参照し
てください。
ナレッジバンドルを複製、配布する代わりに、⼤規模環境でも⼩規模環境でも、すべてのサーチピアに対して、共
有ストレージにあるナレッジバンドルにマウントさせることができます。詳細は、「ナレッジバンドルのマウン
ト」を参照してください。
分散サーバー名の管理
各サーチヘッドおよびサーチピアの名前は、server.conf に指定されている
す。serverName 属性のデフォルトは、サーバーのマシン名です。
serverName
属性により決まりま
分散サーチ環境では、すべてのサーチヘッドとサーチピアが⼀意の名前を持つ必要があります。分散サーチ環境
で、serverName には 3 種類の特殊な使⽤事例があります。
サーチヘッドの認証: サーチピアがサーチヘッドの認証を⾏う場合、サーチヘッドの
/etc/auth/distServerKeys/<searchhead_name>/trusted.pem にあるキーファイルが参照されます。
サーチクエリ内のサーチピアの識別： serverNameは、splunk_server フィールドの値で、特定のノードにクエ
リを⾏う場合に指定します。詳細は、『サーチマニュアル』の「インデックスと分散サーチピアからのイベ
ントの取得」を参照してください。
サーチ結果内のサーチピアの識別： serverNameは、splunk_server フィールドに報告されます。
注意： serverNameは、サーチピアをサーチヘッドに追加する場合は使⽤されません。この場合は、ドメイン名また
は IP アドレスでサーチピアを指定します。
を変更する唯⼀の理由が、単⼀のマシン上に複数の Splunk Enterprise インスタンスが存在し、それら
が同じ分散サーチグループに参加している場合です。この場合、配布するために serverName を変更する必要があり
ます。
serverName
ベストプラクティス：サーチヘッドデータのインデクサー層への転送
サーチヘッドのすべての内部データを、ピア (インデクサー) 層に転送することが、ベストプラクティスと考えら
れています。こうすることには、さまざまな利点が存在しています。
すべてのデータを 1 つの場所に蓄積する。こうすることにより、データの管理が簡素化されます。インデッ
クスとデータの管理が必要なのは、1 つのレベル (インデクサーレベル) のみになります。
サーチヘッド停⽌時に、診断が可能になる。障害につながるデータは、インデクサー上に保管されており、
後ほど他のサーチヘッドからそれにアクセスすることができます。
サマリーインデックスサーチの結果をインデクサーレベルに転送することで、すべてのサーチヘッドがそれ
にアクセスすることができます。そうしない場合は、データを⽣成したサーチヘッドのみがそれを利⽤でき
ることになります。
サーチヘッド・データの転送
サーチヘッド上で個別にインデックスを作成せずに、データを直接インデクサーに転送することをお勧めします。
そのためには、サーチヘッドをフォワーダーとして設定します。主な⼿順を以下に⽰します。
1. インデクサー上に必要なインデックスが存在していることを確認します。 たとえば、S.o.S App はカスタ
ム・インデックスにデータを保管するスクリプト⼊⼒を使⽤しています。S.o.S をサーチヘッドにインストールし
ている場合、App が⽣成するデータに必要なインデックス設定をインデクサーに提供するために、S.o.S アドオン
をインデクサーにインストールする必要があります。⼀⽅、_audit と _internal はサーチヘッド上だけでなくイン
デクサー上にも存在しているため、対応するサーチヘッドのデータを保持するために、それらのインデックスの
バージョンを個別に作成する必要があります。
2. サーチヘッドをフォワーダーとして設定します。 ⼀連のサーチピア (インデクサー) にまたがって、ロードバ
ランシング⽤の転送を⾏うサーチヘッド上に、設定⽤の outputs.conf ファイルを作成します。また、サーチヘッド
12
がデータをローカルに保持しながら、それをサーチ・ピアにも転送することがないように、サーチヘッド上でのイ
ンデックス作成をオフにする必要があります。
outputs.conf
ファイルの例を以下に⽰します。
# Turn off indexing on the search head
[indexAndForward]
index = false
[tcpout]
defaultGroup = my_search_peers
forwardedindex.filter.disable = true
indexAndForward = false
[tcpout:my_search_peers]
server=10.10.10.1:9997,10.10.10.2:9997,10.10.10.3:9997
autoLB = true
この例では、各インデクサーの受信ポートが 9997 に設定されていることを前提にしています。
の設定の詳細は、『データの転送』マニュアルの「outputs.conf によるフォワーダーの設定」を参照
してください。
outputs.conf
サーチヘッド・クラスタ・メンバーからのデータの転送
サーチヘッド・クラスタ・メンバーから⼀連のサーチ・ピアにデータを転送する場合、同じ設定⼿順を実⾏しま
す。ただし、すべてのメンバーが同じ outputs.conf ファイルを使⽤していることを確認する必要があります。その
ために、個別のサーチヘッド上ではファイルを編集しないでください。代わりにデプロイヤーを使って、クラスタ
にファイルを配布してください。「デプロイヤーを使った App と設定の更新の配布」を参照してください。
分散サーチ・グループの作成
サーチ・ピアをグループ化して、サーチ・ピアのサブセットへのサーチを⼿軽に⾏うことができます。サーチ・ピ
アのグループは、「分散サーチ・グループ」と呼ばれています。分散サーチ・グループは、distsearch.conf ファイ
ルに指定します。
たとえば、ニューヨークとサンフランシスコにそれぞれ複数台のサーチ・ピアが存在しており、どちらかの場所に
ある⼀連のサーチ・ピアに対してのみサーチを実⾏したい場合を考えてみましょう。そのためには、ニューヨーク
とサンフランシスコを表す 2 つのサーチ・グループ NYC と SF を作成します。
distsearch.conf
で以下のスタンザを作成します。
[distributedSearch]
# This stanza lists the full set of search peers.
servers = 192.168.1.1:8089, 192.168.1.2:8089, 175.143.1.1:8089, 175.143.1.2:8089, 175.143.1.3:8089
[distributedSearch:NYC]
# This stanza lists the set of search peers in New York.
default = false
servers = 192.168.1.1:8089, 192.168.1.2:8089
[distributedSearch:SF]
# This stanza lists the set of search peers in San Francisco.
default = false
servers = 175.143.1.1:8089, 175.143.1.2:8089, 175.143.1.3:8089
この例では、サーチに指定できる 2 つのサーチ・グループ NYC と SF を作成します。
以下の事項に注意してください。
属性には、サーチ・ピアのグループ・リストが IP アドレスと管理ポートで記載されています。
各サーチ・グループのサーバー・リストは、全般の [distributedSearch] スタンザのサブセットでなければな
りません。
各グループ・リストの⼀部が重複していても構いません。たとえば、それぞれの場所からの数台のピアを含
む、「Primary_Indexers」という名前の 3 番⽬のグループを追加することができます。
グループの default 属性に真 (True) を設定すると、サーチにサーチ・グループが指定されていない場合、そ
のグループがサーチ対象となります。すべてのグループに対して偽 (False) を設定すると、サーチにサー
チ・グループが指定されていない場合、[distributedSearch] スタンザ内の全サーチ・ピアがサーチ対象にな
ります。
servers
サーチ内でサーチ・グループを使⽤するには、以下のようにサーチ・グループを指定します。
sourcetype=access_combined status=200 action=purchase splunk_server_group=NYC | stats count by product
13
このサーチは、NYC にあるピアのみを対象に実⾏されます。
注意： この機能は、インデクサー・クラスタリングでは無効です。インデクサー・クラスタリングの場合、⼀連
のサーチ・ピア (ピア・ノード) に対してデータが任意に複製されます。特定のセットのデータが、どの特定のピ
アに保管されるかを知ることはできません。
ナレッジバンドルのマウント
マウントバンドルについて
サーチヘッドがサーチピアに配布する⼀連のデータは、ナレッジバンドル と呼ばれています。バンドルの内容
は、サーチヘッドの $SPLUNK_HOME/etc/{apps,users,system} サブディレクトリに存在しています。このバンドルの内
容と⽬的については、「サーチヘッドがサーチピアに送信する内容」を参照してください。
デフォルトでサーチヘッドは各サーチピアにナレッジバンドルを複製、配布します。効率を向上するために、バン
ドルの複製処理を省いてナレッジバンドルのディレクトリにサーチピアをマウントさせることができます。共有ス
トレージ上のナレッジバンドルにマウントする場合、それはマウントバンドル と呼ばれます。
警告： ⼤部分の共有ストレージソリューションは、WAN 経由では正常に機能しません。マウントバンドルには
共有ストレージが必要なため、⼀般的には WAN 環境には導⼊しないでください。
マウントバンドルを使⽤する理由
⼤量のサーチ時データが存在している場合、複製プロセスに時間がかかる可能性があるため、マウントバンドルが
役⽴ちます。バンドルのレプリケーションが遅くなる⼀般的な原因としては、巨⼤なルックアップテーブルが挙げ
られます。
バンドルのレプリケーションに⻑時間かかる場合は、警告が
splunkd.log
に書き込まれます。例：
DistributedBundleReplicationManager - bundle replication to 2 peer(s) took
too long (12943ms), bundle file size=296150KB ...
マウントバンドルのアーキテクチャ
サーチヘッドの設定に応じて、マウントバンドルの設定⽅法はさまざまです。⼀般的な例を以下に⽰します。
単⼀サーチヘッドの場合： 共有ストレージにナレッジバンドルをマウントします。すべてのサーチピアは
バンドルにアクセスしてサーチリクエストを処理します。共有ストレージにマウントバンドルを保有する単
⼀サーチヘッドを以下の図に⽰します。
⾮クラスタ構成の複数のサーチヘッドが存在する場合： 各サーチヘッドのローカルストレー上でナレッ
ジバンドルを管理します。以下の図では、各サーチヘッドが独⾃のバンドルを管理しており、各サーチピア
が個別にマウントしてアクセスします。
14
どの場合でも、サーチピアは各サーチヘッドの
する必要があります。
$SPLUNK_HOME/etc/{apps,users,system}
サブディレクトリにアクセス
サーチ・ピアは、サーチヘッドのサーチ・リクエストを満たすためにのみ、マウントされたディレクトリを使⽤し
ます。インデックス作成または他の分散サーチに直接関係しない⽬的の場合、サーチピアは他のインデクサーと同
様に各⾃のローカル apps, users、および system ディレクトリを使⽤します。
マウントバンドルの設定
マウントバンドルを設定するには、サーチヘッドとサーチピアの両⽅を設定する必要があります。ここで説明して
いる⼿順は、バンドルが共有ストレージ上にあることを前提にしていますが、そうでなくても構いません。サーチ
ヘッドとサーチピアの両⽅がアクセスできる場所に存在していれば何の問題もありません。
注意： マウントバンドルをサーチヘッドのローカル
す。
$SPLUNK_HOME
パスには配置しないようにすることをお勧めしま
サーチヘッドの設定
サーチヘッドでの⼿順を以下に⽰します。
1. 共有ストレージ上のバンドルサブディレクトリ ($SPLUNK_HOME/etc/{apps,users,system}) をマウントします。その
ためのもっとも簡単な⽅法は、サーチヘッドの $SPLUNK_HOME/etc ディレクトリをマウントすることです。
*nix プラットフォームの場合： NFS マウントを設定します。
Windows： CIFS (SMB) 共有を設定します。
重要： サーチヘッドの Splunk ユーザーアカウントには、共有ストレージの場所に対する読み取り/書き込みアク
セスが必要です。サーチピアには、バンドルサブディレクトリに対する読み取りアクセスが必要です。
2. サーチヘッドの
distsearch.conf
ファイルに、以下の項⽬を設定します。
shareBundles=false
これにより、サーチヘッドによるサーチピアへのバンドルの複製が中⽌されます。
3. サーチヘッドを再起動します。
サーチピアの設定
マウントバンドルにアクセスできるようにするには、各サーチピアに対して以下の⼿順を実⾏します。
1. サーチピア上でバンドルディレクトリをマウントします。
15
2. サーチピア上の $SPLUNK_HOME/etc/system/local/ に、distsearch.conf ファイルを作成します。ピアが接続する各
サーチヘッドに対して、[searchhead:<searchhead-splunk-server-name>] スタンザを作成し、以下の属性を設定しま
す。
[searchhead:<searchhead-splunk-server-name>]
mounted_bundles=true
bundles_location=<path_to_bundles>
以下の事項に注意してください。
サーチピアの設定ファイルは、[searchhead:<searchhead-splunk-server-name>] スタンザのみを含む必要があり
ます。distsearch.conf 内の他のスタンザは、サーチヘッド専⽤です。
<searchhead-splunk-server-name>
を識別するには、サーチヘッドで以下のコマンドを実⾏します。
splunk show servername
には、サーチヘッドではなくサーチピアのマウントポイントを指定する必要があります。
たとえば、サーチヘッド上の $SPLUNK_HOME が /opt/splunk で、NFS 経由で /opt/splunk/etc をエクスポートす
る場合を考えてみましょう。次にサーチピア上の /mnt/splunk-head にその NFS 共有をマウントする必要があ
ります。<path_to_bundles> の値は /mnt/splunk-head でなければなりません。/opt/splunk ではありません。
<path_to_bundles>
重要： 複数のサーチヘッドがこのサーチピアにサーチを分散する場合、サーチピア上でそれぞれに対して個別の
スタンザを作成する必要があります。
3. サーチピアを再起動します。
注意： サーチピアがサーチヘッドの /etc ディレクトリ内の、必要なサブディレクトリにのみアクセスできるよう
に、必要に応じてバンドルサブディレクトリ (apps,users,system) へのシンボリックリンクを設定することができま
す。詳細は、以下の例を参照してください。
設定の例
共有ストレージへのマウントバンドルの設定⽅法の例を⽰します。
サーチヘッド
Splunk Enterprise サーバー名が「searcher01」のサーチヘッド上で、以下の作業を⾏います。
1. サーチヘッドの
ます。
$SPLUNK_HOME/etc
2. サーチヘッドの
distsearch.conf
ディレクトリを共有ストレージに、読み取り/書き込みアクセスでマウントし
ファイルに、以下の項⽬を設定します。
[distributedSearch]
...
shareBundles = false
3. サーチヘッドを再起動します。
サーチピア
各サーチピア上で以下の作業を⾏います。
1. サーチヘッドの
$SPLUNK_HOME/etc
ディレクトリを、サーチピアの以下の場所にマウントします。
/mnt/searcher01
2. (オプション)バンドル内のサブディレクトリへのシンボリックリンクから構成されるディレクトリを作成しま
す。
/opt/shared_bundles/searcher01
/opt/shared_bundles/searcher01/system -> /mnt/searcher01/system
/opt/shared_bundles/searcher01/users -> /mnt/searcher01/users
/opt/shared_bundles/searcher01/apps -> /mnt/searcher01/apps
注意： このオプションステップは、ピアに必要なディレクトリにのみアクセスさせる場合に役⽴ちます。
3. サーチピア上の
ます。
$SPLUNK_HOME/etc/system/local/
に、distsearch.conf ファイルを作成し、以下のスタンザを指定し
16
[searchhead:searcher01]
mounted_bundles = true
bundles_location = /opt/shared_bundles/searcher01
4. サーチピアを再起動します。
5. 各サーチピアに対して⼿順を繰り返します。
サーチヘッドプーリングでのマウントバンドルの使⽤
この機能は廃⽌予定です。
サーチヘッド・プーリングは、Splunk Enterprise バージョン 6.2 から⾮推奨 (廃⽌予定) となりました。この
ことは、この機能はまだ利⽤できますが、将来のバージョンでは削除される可能性があることを意味していま
す。
代わりに、サーチヘッド・クラスタリングをデプロイすることができます。「サーチヘッド・クラスタリングに
ついて」を参照してください。サーチヘッド・クラスタリングは、マウント・バンドルをサポートしていませ
ん。
⾮推奨で廃⽌予定の機能の⼀覧は、リリースノートの「⾮推奨 (廃⽌予定) の機能」を参照してください。
複数のサーチヘッドの管理にサーチヘッドプーリングを使⽤している場合、基本的にマウントバンドルの設定⼿順
に違いはありません。ただし、以下の事項を考慮する必要があります。
サーチヘッドプールとマウントバンドルの両⽅で、同じ共有ストレージ場所を使⽤してください。サーチ
ヘッドプーリングは、マウントバンドルに必要なディレクトリのサブセットを使⽤します。
サーチヘッドプーリング⾃体では、$SPLUNK_HOME/etc/{apps,users} ディレクトリのマウントのみが必要になり
ます。ただし、マウントバンドルを使⽤する場合、マウントされた $SPLUNK_HOME/etc/system ディレクトリも
指定する必要があります。この場合、サーチヘッド間で競合は発⽣しません。常に各⾃のバージョンの
system ディレクトリを使⽤し、マウントされているバージョンは無視されます。
サーチピアには、プール内の各サーチヘッドに対して個別の distsearch.conf を作成する必要があります。こ
れらのスタンザ内の bundles_location は同⼀である必要があります。
サーチヘッドプールの設定⽅法については、「サーチヘッドプーリングの設定」を参照してください。
設定の例：マウントバンドルを使⽤するサーチヘッドプーリング
この例では、単⼀のシステム内でサーチヘッドプーリングとマウントバンドルの両⽅を組み合わせる⽅法を⽰しま
す。この例には、2 種類の主なセクションが存在しています。
1. 2 台のサーチヘッドから構成されるサーチヘッドプールを設定します。ここでは、バンドルもマウントします。
2. サーチヘッドプールからのバンドルにアクセスできるように、サーチピアを設定します。
この例では、共有ストレージ場所に対して NFS マウントを使⽤していることを前提にしています。
パート 1：サーチヘッドプールの設定
プールを設定する前に、以下の予備的ステップを実⾏します。
1. 2 台の Splunk Enterprise インスタンスをサーチヘッドとして有効にします。この例は、それぞれのインスタ
ンス名が「searcher01」および「searcher02」と仮定しています。
2. 各サーチヘッドにアクセスできる、共有ストレージ場所を設定します。この例では、サーチヘッド上に NFS マ
ウントポイントを /mnt/search-head-pooling として指定したことを前提にしています。
これらの⼿順の詳細は、「サーチヘッドのプールの作成」を参照してください。
次にサーチヘッドプールを設定します。
1. サーチヘッド上で 、splunkd を停⽌します。
splunk stop splunkd
2. サーチヘッド上で 、サーチヘッドプーリングを有効にします。この例では、共有ストレージ場所として
/mnt/search-head-pooling の NFS マウントを使⽤します。
splunk pooling enable /mnt/search-head-pooling [--debug]
また、このステップでは /mnt/search-head-pooling 下に空の /etc/apps およびは
す。ステップ 3 ではこれらのディレクトリを使⽤します。
/etc/users
ディレクトリを使⽤しま
3. いずれかのサーチヘッド の $SPLUNK_HOME/etc/apps および $SPLUNK_HOME/etc/users ディレクトリの内容
を、/mnt/search-head-pooling 下の /etc/apps および /etc/users サブディレクトリにコピーします。
17
cp -r $SPLUNK_HOME/etc/apps/* /mnt/search-head-pooling/etc/apps
cp -r $SPLUNK_HOME/etc/users/* /mnt/search-head-pooling/etc/users
4. 1 つのサーチヘッドの
ます。
$SPLUNK_HOME/etc/system
ディレクトリを、/mnt/search-head-pooling/etc/system にコピーし
cp -r $SPLUNK_HOME/etc/system /mnt/search-head-pooling/etc/
5. /mnt/search-head-pooling/etc/system/local/server.conf ファイルに
す。存在している場合は、エントリを削除します。
6. サーチヘッド上で 、distsearch.conf ファイルを編集して
[pooling]
スタンザがあるかどうかを確認しま
shareBundles = false
を設定します。
[distributedSearch]
...
shareBundles = false
7. サーチヘッド上で 、splunkd を開始します。
splunk start splunkd
サーチヘッドプールが稼働するはずです。
パート 2：サーチピア上のマウントバンドル
次に、サーチピア上でバンドルをマウントします。
サーチピア上で、以下の⼿順を実⾏します。
1. 共有ストレージ場所 (以前にサーチヘッド上で /mnt/search-head-pooling と設定したのと同じ場所) が、ピア上で
/mnt/bundles として表⽰されるようにマウントします。
2. バンドル内のサブディレクトリへのシンボリックリンクから構成されるディレクトリを作成します。
/opt/shared_bundles/bundles/system -> /mnt/bundles/etc/system
/opt/shared_bundles/bundles/users -> /mnt/bundles/etc/users
/opt/shared_bundles/bundles/apps -> /mnt/bundles/etc/apps
3. サーチピア上の $SPLUNK_HOME/etc/system/local/ 内に
対応するスタンザを指定します。
distsearch.conf
ファイルを作成し、2 つの各サーチヘッドに
[searchhead:searcher01]
mounted_bundles = true
bundles_location = /opt/shared_bundles/bundles
[searchhead:searcher02]
mounted_bundles = true
bundles_location = /opt/shared_bundles/bundles
4. サーチピアを再起動します。
splunk restart splunkd
各サーチピアに対して⼿順を繰り返します。
サーチヘッド・クラスタリングの概要
サーチヘッド・クラスタリングについて
サーチヘッド・クラスタ は、サーチの集中リソースとしての役割を果たす、Splunk Enterprise サーチヘッド の
グループです。サーチヘッド・クラスタのメンバー は基本的に交換可能です。クラスタの任意のメンバーから、
同じサーチの実⾏、同じダッシュボードの参照、同じサーチ結果へのアクセスが可能です。
交換可能を実現するために、クラスタ内のサーチヘッドは設定と App、過去のサーチ結果 、およびジョブ・スケ
ジュールを共有する必要があります。サーチヘッド・クラスタはメンバー間で、これらの共有可能リソースの⼤部
分を⾃動的に伝搬します。
18
サーチヘッド・クラスタの利点
サーチヘッド・クラスタには、以下のような利点があります。
⽔平スケーリング： ユーザー数とサーチ負荷が増加するにつれて、クラスタに新たなサーチヘッドを追加
することができます。サーチヘッド・クラスタに、ユーザーとクラスタの間に配置したサードパーティ製の
ロード・バランサーを組み合わせることにより、このトポロジーはユーザーに対して透過的になります。
⾼可⽤性： あるサーチヘッドが停⽌しても、クラスタ内の他のサーチヘッドから、同じサーチを実⾏した
り、同じサーチ結果にアクセスしたりすることができます。
単⼀障害点がない： サーチヘッド・クラスタは動的なキャプテン を使ってクラスタを管理します。キャプ
テンが停⽌しても、他のメンバーから⾃動的にクラスタの管理作業を引き継ぎます。
クラスタのアーキテクチャ
サーチヘッド・クラスタは、ネットワーク化されたサーチヘッドのグループ (クラスタ・メンバー) で構成されて
います。クラスタ・メンバーの 1 台がキャプテンとなり、クラスタの活動を管理します。キャプテンの役割を果
たしているメンバーが停⽌した場合、他のメンバーがそれを引き継ぎます。
メンバーは以下の事項を共有します。
ジョブ・スケジュール： クラスタはジョブのスケジュールを集中管理しており、各スケジュール済みサー
チを最適なメンバー (⼀般的には負荷がもっとも少ないメンバー) に割り当てます。
過去のサーチ結果： クラスタは過去のサーチ結果を複製し、すべてのメンバーがそれを利⽤できるように
します。
設定： クラスタでは、すべてのメンバーが同じ設定セットを共有する必要があります。ダッシュボードやレ
ポートの更新などの、ナレッジ・オブジェクトの実⾏時更新の場合は、すべてのメンバーに設定が⾃動的に
複製されます。App やその他の設定の場合は、ユーザーがデプロイヤー を使ってクラスタ・メンバーに設
定を配布する必要があります。デプロイヤーは、クラスタ外に存在する、Splunk Enterprise インスタンス
です。
「サーチヘッド・クラスタリングのアーキテクチャ」を参照してください。
クラスタの設定⽅法
クラスタを設定するには、クラスタのサーチヘッドを設定、デプロイします。⼿順は任意の分散環境でのサーチ
ヘッドの設定⽅法と似ています。主な違いとしては、サーチヘッドをクラスタのメンバーとしても設定する必要が
あることが挙げられます。
「サーチヘッド・クラスタリングのデプロイ」を参照してください。
ユーザーのクラスタへのアクセス⽅法
ユーザーは、サーチヘッドにアクセスするのと同じ⽅法でクラスタにアクセスします。ブラウザで、クラスタのメ
ンバーである任意のサーチヘッドを指定します。クラスタ・メンバーはジョブ、過去のサーチ結果、および設定を
共有するため、ユーザーはどのサーチヘッドにアクセスしても構いません。いつでも同じセットのダッシュボード
やサーチなどにアクセスできます。
⾼い可⽤性とロード・バランシングを実現するために、クラスタの全⾯にロード・バランサーを配置することをお
勧めします。そうすると、ロード・バランサーはユーザーにクラスタ内の任意のサーチヘッドを割り当てることが
でき、各クラスタ・メンバー間でユーザーの負荷を分散させることができます。あるサーチヘッドが停⽌しても、
ロード・バランサーはユーザーを残りのいずれかのサーチヘッドに割り当てられます。
サーチヘッド・クラスタとインデクサー・クラスタ
サーチヘッド・クラスタはインデクサー・クラスタ とは異なります。インデクサー・クラスタの主⽬的は、イン
デクサーのグループを管理してデータの可⽤性を⾼めることにあります。インデクサー・クラスタには常に 1 つ
または複数の関連するサーチヘッドが含まれており、それを利⽤してインデクサー上のデータにアクセスします。
これらのサーチヘッドは、サーチヘッド・クラスタのメンバーである場合もありますが、必ずしもそうである必要
はありません。
インデクサー・クラスタ内のサーチヘッドについては、『インデクサーとインデクサー・クラスタの管理』マニュ
アルの「サーチヘッドの設定」を参照してください。
サーチヘッド・クラスタのインデクサー・クラスタへの追加については、このマニュアルの「サーチヘッド・クラ
スタとインデクサー・クラスタの統合」を参照してください。
サーチヘッド・クラスタリングのアーキテクチャ
サーチヘッド・クラスタは、サーチの集中リソースとしての役割を果たす、Splunk Enterprise サーチヘッドのグ
ループです。
サーチヘッド・クラスタの構成要素
サーチヘッド・クラスタ は、設定、ジョブ・スケジュール、および過去のサーチ結果 を共有する、サーチヘッ
ド のグループで構成されています。サーチヘッドは、クラスタ・メンバー とも呼ばれます。
1 台のクラスタ・メンバーがキャプテン の役割を果たします。キャプテンは、各メンバー間のジョブのスケ
ジュールとレプリケーション活動を管理します。また、他のメンバーと同様にサーチヘッドとしての役割も果た
し、サーチ・ジョブの実⾏や結果の提供などを⾏います。クラスタ・メンバー間で、キャプテンの役割が別のメン
バーに引き継がれることもあります。
19
実際にサーチヘッド・クラスタを構成する⼀連のサーチヘッド・メンバーの他に、クラスタが機能するためには他
のコンポーネントも必要となります。
デプロイヤー： App やその他の設定をクラスタ・メンバーに配布する Splunk Enterprise インスタンスで
す。これはクラスタ外に配置されます。また、クラスタ・メンバーと同じインスタンス上で動作することは
できません。ただし、デプロイ・サーバー やインデクサー・クラスタ のマスター・ノードなどの他の
Splunk Enterprise コンポーネントと同じインスタンス上で動作することは可能です。「デプロイヤーを
使った App と設定の更新の配布」を参照してください。
サーチ・ピア： クラスタのメンバーがサーチを実⾏する⼀連のインデクサーです。サーチ・ピアは独⽴した
インデクサー、またはインデクサー・クラスタ内のノードになります。「クラスタ内のサーチヘッドのサー
チ・ピアへの接続」を参照してください。
ロード・バランサー： サードパーティ製のソフトウェアまたはハードウェアで、必要に応じてユーザーと
クラスタ・メンバーの間に配置されます。ロード・バランサーを設置すると、ユーザーは単⼀のインター
フェイスから、特定のサーチヘッドを指定せずに、⼀連のサーチヘッドにアクセスすることができます。
「ロードバランサーとサーチヘッド・クラスタリングの使⽤」を参照してください。
3 台のメンバーで構成される、⼩規模なサーチヘッド・クラスタの図を以下に⽰します。
この図は、主なクラスタ関連コンポーネントとそのやり取りを表しています。
1 台のメンバーがキャプテンとしての役割を果たし、クラスタ内のさまざまな活動を指⽰します。
メンバーは各⾃通信を⾏って、ジョブのスケジュール、過去のサーチ結果の複製、設定の更新、およびクラ
スタ内のその他の活動の調整を⾏います。
メンバーは、サーチ・リクエストに対処するために、サーチ・ピアと通信します。
必要に応じてロード・バランサーを設置して、ユーザーはそれを介してサーチヘッドにアクセスできます。
デプロイヤーはクラスタ外に設置されており、クラスタのメンバーに更新を配布します。
サーチヘッド・クラスタのキャプテン
キャプテンはすべてのクラスタ・メンバーに共通のサーチ・アクティビティに加えて、他の作業もこなすクラス
タ・メンバーです。クラスタのアクティビティを管理、調整します。任意のメンバーがキャプテンの役割を果たせ
ますが、クラスタ内にキャプテンは 1 台のみ存在できます。キャプテンに障害が発⽣した場合は、他のメンバー
がそのロールを引き継ぎます。
キャプテンの役割
キャプテンはクラスタのメンバーで、他のクラスタ・メンバーと同じように、⾃⼰の能⼒に応じてサーチ・アク
ティビティ (アドホック・サーチとスケジュール済みサーチの両⽅) を実⾏しています。必要に応じてキャプテン
のサーチ・アクティビティを制限して、アドホック・サーチのみを実⾏して、スケジュール済みサーチは実⾏しな
いように設定することができます。「アドホック・サーチのみを実⾏するようにキャプテンを設定」を参照してく
ださい。
また、キャプテンはすべてのクラスタ・メンバー間でアクティビティを調整、管理しています。担当する業務を以
下に⽰します。
ジョブのスケジュール。現在の負荷に基づいて、⾃⼰も含めたメンバーにジョブを割り当てます。
クラスタ内のアラートおよびアラート抑制の管理。キャプテンは各アラートを追跡していますが、アラート
を⽣成するのはサーチを開始したメンバーです。
ナレッジ・バンドル のサーチ・ピアへの配布。
過去のサーチ結果の複製の管理。キャプテンは、複製データ保持数 を満たすために、必要に応じて過去の
サーチ結果を複製します。「サーチヘッド・クラスタの複製データ保持数の選択」を参照してください。
設定更新の複製。キャプテンは、あるクラスタ・メンバーで⾏われたナレッジ・オブジェクトの実⾏時の変
更を、他のすべてのメンバーに複製します。これには、たとえば保存済みサーチ、ルックアップ・テーブ
ル、およびダッシュボードの変更や追加などが含まれます。「クラスタが複製する設定の更新」を参照して
20
ください。
キャプテンの選出
サーチヘッド・クラスタは動的にキャプテンを利⽤しています。つまり、クラスタの使⽤時に、キャプテンの役割
を果たすメンバーを変更することができます。任意のメンバーがキャプテンとしての役割を果たせます。必要に応
じてクラスタはキャプテンの選出を⾏い、その結果新しいメンバーがキャプテンの役割を引き継ぐこともありま
す。
キャプテンの選出は次の場合に⾏われます。
現在のキャプテンが停⽌、または再起動された。
クラスタがローリング再起動を実⾏した (例：デプロイヤーがクラスタ・メンバーを更新した後)。ローリン
グ再起動中にはキャプテンも再起動されるため、選出が⾏われます。「サーチヘッド・クラスタの再起動」
を参照してください。
ネットワークがパーティション分割され、1 台または複数のメンバーが残りのサーチヘッド・クラスタから
分離された。ネットワークのパーティションが回復した場合、これらのメンバーがキャプテン選出の契機と
なる可能性があります。
⼀般的には、上記のようなイベントの発⽣後、新しいキャプテンの選出までには 1〜2 分ほどかかります。その間
機能しているキャプテンは存在せず、サーチヘッドは各⾃のローカル環境のみを把握しています。各メンバーが
キャプテンの役割を引き継ぐ前に最低限のタイムアウト期間待機する必要があるため、選出にこれだけの時間がか
かります。タイムアウトの値は設定可能です。
選出プロセスでは、すべてのメンバーに無作為にタイマーが設定されます。設定された時間を最初に経過したメン
バーがキャプテンに⽴候補して、他のメンバーに同意を求めます。⼀般的には他のメンバーはこれに同意して、そ
のメンバーが新たなキャプテンとなります。キャプテンになるメンバーは、すべてのメンバーの過半数の同意を得
る必要があります。たとえば、7 台のメンバーが存在するクラスタでは、キャプテンに選出されるには 4 台以上
の同意が必要です。同様に、6 台のメンバーが存在するクラスタでも、4 台以上の同意が必要になります。
以前にキャプテンだったメンバーが引き続き動作している場合は、それがクラスタのキャプテンとして選出される
こともあります。この⼿続きは公平に⾏われます。
メンバーがキャプテンとして選出されたら、それが以降のキャプテン業務を引き継ぎます。
キャプテン選出⼿続きとその意味
正常にキャプテンが選出されるために過半数の同意が必要であることには、デプロイ環境に関する次のような事項
が関係しています。
クラスタは 3 台以上のメンバーで構成する必要があります。2 台構成のクラスタでは、ノード障害に対処で
きません。どちらかのメンバーに障害が発⽣すると、クラスタはキャプテンを選出して機能を継続すること
ができません。キャプテンの選出にはすべてのメンバーの過半数 (51%) の同意が必要で、2 台構成のクラス
タでは両⽅のノードが稼働している必要があります。そのため、2 台構成のクラスタでは、サーチヘッド・
クラスタの⾼可⽤性の利点を断念する必要があります。
クラスタを 2 ヶ所のサイトにまたがって運⽤する場合、プライマリ・サイトにノードの過半数を設置する必
要があります。サイト間のネットワークが切断された場合、過半数を保有するサイトのみが新たなキャプテ
ンを選出できます。「サイト障害によりキャプテンが選出できない可能性」を参照してください。
クラスタによる過去のサーチ結果の取り扱い
クラスタは過去のサーチ結果の⼤部分を、複数のクラスタ・メンバーに複製します。メンバーが過去のサーチ結果
にアクセスする必要がある場合、ローカル・コピーがある場合はそれにアクセスします。そうでない場合は、プロ
キシを使ってサーチ結果にアクセスします。
過去のサーチ結果の複製
クラスタはスケジュール済みサーチから返された過去のサーチ結果の、複数のコピーを管理しています。複製デー
タ保持数により、クラスタが過去のサーチ結果を保持するコピー数が決まります。たとえば、複製データ保持数が
3 の場合、過去のサーチ結果を⽣成したメンバー上、そして他の 2 台のメンバー上に過去のサーチ結果のコピー
が保持されます (合計 3 つ)。
キャプテンが、クラスタ・メンバーへの過去のサーチ結果の複製を管理します。他のサーチヘッドと同様に、クラ
スタ構成かどうかに関係なく、サーチが完了するとそのサーチ結果は、サーチ実⾏元メンバーのディスパッチ・
ディレクトリに保管されます。次にキャプテンが過去のサーチ結果のレプリケーション・プロセスを開始し、⽣成
元のメンバーも含めて複製データ保持数に相当するメンバーがコピーを保持するようになるまで、メンバー間にコ
ピーを配布していきます。
コピーを受け取る⼀連のメンバーは、過去のサーチ結果ごとに異なることもあります。つまり、ある⽣成元メン
バーからの 2 つの異なる過去のサーチ結果のコピーが、異なるメンバーに複製されることがあります。
キャプテンは、過去のサーチ結果のレジストリを、各サーチ結果のコピーの場所に関する情報も含めて管理してい
ます。レジストリが変更されると、キャプテンはその差分を各メンバーに送信します。
あるメンバーが停⽌して、⼀部の過去のサーチ結果のコピーがクラスタから失われた場合、キャプテンはクラスタ
内の各サーチ結果のコピー数が、複製データ保持数を満たしている状態に戻すために、修復作業を開始します。
過去のサーチ結果は、$SPLUNK_HOME/var/run/splunk/dispatch 下にあるディスパッチ・ディレクトリに保管されます。
このディレクトリの各サブディレクトリに、それぞれ 1 つの過去のサーチ結果が保管されます。クラスタが複製
するのは、これらのサブディレクトリです。
過去のサーチ結果のプロキシ
21
過去のサーチ結果のプロキシ
クラスタは、保存されているスケジュール済みサーチから返された過去のサーチ結果のみを複製します。以下のよ
うな他のサーチ・タイプからの結果は複製されません。
スケジュール済みリアルタイム・サーチ
アドホック・サーチ (リアルタイムまたは履歴サーチ)
これらの結果が⽣成元ではないサーチヘッドからリクエストされた場合、クラスタは結果をプロキシ経由で提供し
ます。リクエストしたメンバーに対して、この結果は多少の遅延の後に表⽰されます。
また、保存されているスケジュール済みサーチのサーチ結果が必要だけれども、そのメンバーがそのサーチ結果の
ローカル・コピーを保持していない場合、クラスタがプロキシ (代理) としてコピーを持つメンバーから結果を取
得して提供します。同時にクラスタは、そのサーチ結果のコピーをリクエストしたメンバーに複製します。こうす
ることによって、それ以降のリクエストに対してはローカル・コピーを利⽤することができます。このような処理
が⾏われるため、⼀部の過去のサーチ結果については、複製データ保持数以上のコピーが存在することもありま
す。
設定変更の配布
いくつかの例外を除いて、すべてのクラスタ・メンバーが同じ設定を使⽤する必要があります。たとえば、あるメ
ンバーのダッシュボードを編集した場合、他のすべてのメンバーにその変更内容を反映させる必要があります。同
様に、App を配布する場合は、すべてのメンバーにそれを配布する必要があります。サーチヘッド・クラスタリ
ングには、クラスタ内で設定の同期を維持する⼿段が存在しています。
クラスタ・メンバーへの配布⽅法に基づくと、設定の変更は 2 種類に分類できます。
変更の複製： 実⾏時のナレッジ・オブジェクトの変更は、そのメンバーから他のすべてのメンバーに⾃動的
に複製されます。
変更のデプロイ： App や他の実⾏時ではない設定の変更を⼀連のメンバーに配布するには、外部インスタ
ンスであるデプロイヤーを使⽤します。変更の配布はデプロイヤーで実⾏する必要があります。
「サーチヘッド・クラスタへの設定変更の配布⽅法」を参照してください。
ジョブ・スケジュール
キャプテンは保存済みサーチ・ジョブのスケジュールを担当し、負荷に基づいて各クラスタ・メンバーにそれを割
り当てます。基本的には、その時点でサーチ負荷がもっとも低いメンバーにジョブが割り当てられます。
あるメンバーでジョブが失敗した場合、それが別のメンバーに割り当てられます。複数回失敗した場合は、ユー
ザーの介⼊なしには解決できない可能性が⾼いため、ジョブの再割り当ては 1 回のみ⾏われます。たとえば、
サーチ⽂字列が誤っているジョブは、何度実⾏しても失敗してしまいます。
メンバーをアドホック・サーチのみを実⾏するように指定することができます。この場合、キャプテンはそのメン
バーにジョブをスケジュールしません。キャプテンをアドホック・サーチのみを実⾏するように指定することもで
きます。この場合、キャプテンは⾃⼰に対してジョブをスケジュールしません。キャプテンの役割はメンバー間で
引き継ぐことができるため、この設定によりキャプテンの機能がスケジュール済みサーチと競合することはありま
せん。「アドホック・サーチのみを実⾏するようにクラスタ・メンバーを設定」を参照してください。
注意： キャプテンは、各メンバーのマシンの実際の CPU 負荷は考慮していません。クラスタ内のすべてのメン
バーが⼀様に設定されており、コアの種類やその数などがすべて同じであることを前提にしています。
サーチヘッド・クラスタリングと KV ストア
サーチヘッド・クラスタ上に KV ストアを配置することができます。ただし、サーチヘッド・クラスタは KV ス
トア・データのレプリケーションを管理することも、KV ストアの操作に関与することもありません。KV ストア
の詳細は、『管理マニュアル』の「KV ストアについて」を参照してください。
サーチヘッド・クラスタリングのデプロイ
サーチヘッド・クラスタのシステム要件とその他のデプロイに関する
検討事項
サーチヘッド・クラスタのメンバー のシステム要件の⼤半は、⾮クラスタ構成のサーチヘッドと同じです。ここ
では、サーチヘッド・クラスタ特有の要件について説明していきます。
主要要件のまとめ
クラスタ・メンバーのプロビジョニングに関する主な注意事項を以下に⽰します。
各メンバーは個別のマシンまたは仮想マシン上で動作し、また各マシンが同じオペレーティング・システム
で動作している必要があります。
すべてのメンバーで、同じバージョンの Splunk Enterprise を実⾏する必要があります。
すべてのメンバーを、⾼速ネットワーク経由で接続する必要があります。
メンバー数は複製データ保持数または 3 台のどちらか⼤きい⽅の値以上でなければなりません。
クラスタ・メンバーの他に、メンバーに更新を配布するデプロイヤーを設置する必要があります。デプロイヤー
は、メンバーではないインスタンス上で実⾏する必要があります。場合によっては、デプロイ・サーバー また
はインデクサー・クラスタ のマスター・ノードと同じインスタンスで実⾏することができます。
詳細および他の問題については、このトピックの残りの部分を参照してください。
22
ハードウェアとオペレーティング・システムの要件
クラスタ・メンバーのマシン要件
各メンバーは、個別のマシンまたは仮想マシン上で動作している必要があります。
基本的にマシンのハードウェア要件は、Splunk Enterprise サーチヘッドの要件と基本的に同じです。『キャパシ
ティ・プランニング・マニュアル』の「リファレンス・ハードウェア」を参照してください。主な違いは、ディス
パッチ・ディレクトリが⼤きくなることに対応するため、ストレージを増やす必要があることです。「ストレージ
の検討事項」を参照してください。
すべてのクラスタ・メンバーで、同じハードウェア仕様を持つ⼀様なマシンを使⽤することをお勧めします。その
理由は、クラスタ・キャプテン はスケジュール済みジョブを、現在のジョブ負荷に基づいて各メンバーに割り当
てるためです。この時、各メンバーのマシンの実際の処理能⼒は考慮されません。各マシンの性能が同じであるこ
とを前提にしています。
クラスタ・メンバーのオペレーティング・システム要件
すべてのマシンで同じ OS が動作していなければなりません。
サーチヘッド・クラスタリングは、以下のオペレーティング・システムで利⽤できます。
Linux
Solaris
現在 Windows システムでのサーチヘッド・クラスタリングはサポートされていません。
ストレージの検討事項
クラスタ構成サーチヘッドのストレージ要件を判断する場合、過去のサーチ結果 の複製コピーを取り扱うために
必要なスペースを考慮する必要があります。
ストレージ⾒積もりの⽬的で、⾮クラスタ構成環境のサーチヘッドがある場合は、クラスタに移⾏する前にディス
パッチ・ディレクトリのサイズの推移を観察することができます。すべての⾮クラスタ構成サーチヘッドのディス
パッチ・ディレクトリのサイズを合計し、それにクラスタ固有の要因を考慮して値を調整していきます。
検討する必要があるもっとも重要な要因が、複製データ保持数 です。たとえば複製データ保持数が 3 の場合、ク
ラスタ移⾏前のストレージ合計の約 3 倍の量が必要になり、これを各クラスタメンバーに均等に割り当てる必要
があります。
その他の要因によっては、さらにストレージが必要になることもあります。そのような要因の 1 つが、ノード障
害のプランニングです。メンバーが停⽌して、⼀連の過去のサーチ結果 (オリジナルおよび複製コピー) がクラス
タから失われた場合、複製データ保持数を満たす各サーチ結果のコピーを保持するように、修復作業が⾏われま
す。修復作業中、停⽌したメンバーが保持していたコピーは残りのメンバーに複製され、各メンバーのディスパッ
チ・ディレクトリのサイズが増加します。
その他の問題で、メンバーあたりのストレージ量が増加することもあります。たとえば、クラスタでは各メンバー
への複製コピーの配布が完全に均等に⾏われる訳ではありません。また、クラスタが⼀部の過去のサーチ結果のコ
ピーを、複製データ保持数以上に保持することもあります。「クラスタによる過去のサーチ結果の取り扱い」を参
照してください。
ベスト・プラクティスとして、各メンバーには予想される必要ストレージ量よりも⼤幅に⼤きなストレージを⽤意
してください。そうすることにより、将来の需要およびクラスタ・メンバーの停⽌による⼀時的な需要増加の両⽅
に対応することができます。いずれかのメンバーのディスク領域が⼀杯になったら、クラスタでのサーチ実⾏は停
⽌されます。
Splunk Enterprise インスタンスの要件
Splunk Enterprise バージョンの互換性
バージョン 6.2 以上の Splunk Enterprise インスタンスのグループに、サーチヘッド・クラスタリングを導⼊す
ることができます。すべてのメンバーで、同じバージョンの Splunk Enterprise を実⾏する必要があります。
サーチヘッド・クラスタは、5.x または 6.x サーチ・ピア に対してサーチを実⾏できます。サーチヘッドとサー
チ・ピア間のバージョンの互換性については、「バージョンの互換性」を参照してください。
ライセンス要件
ライセンスのニーズは、通常のサーチヘッドと同じです。『管理マニュアル』の「Splunk Enterprise ライセンス
の種類」を参照してください。
必要なインスタンス数
以下の両⽅の要件を満たすために、クラスタには最低限必要なメンバー数があります。
あるメンバーが停⽌してもクラスタが機能するために、最低 3 台のメンバー。「キャプテン選出⼿続きとそ
の意味」を参照してください。
インスタンスの複製データ保持数。「サーチヘッド・クラスタの複製データ保持数の選択」を参照してくだ
さい。
23
たとえば、複製データ保持数が 2 または 3 の場合は、最低 3 つのインスタンスが必要です。たとえば、複製デー
タ保持数が 5 の場合は、最低 5 つのインスタンスが必要です。
必要に応じてそれ以上のメンバーを追加して、サーチおよびユーザー処理能⼒を強化することもできます。
また、クラスタを 2 つのサイトにまたがって構築している場合、プライマリ・サイトに過半数のクラスタ・メン
バーを設置するようにしてください。「キャプテン選出⼿続きとその意味」を参照してください。
サーチ・ピアはクラスタ・メンバーにできない
他のサーチヘッドのサーチ・ピアをクラスタ・メンバーにすることはできません。クラスタ・メンバーのデータに
アクセスするお勧めの⽅法については、「ベスト・プラクティス：サーチ・ヘッド・データのインデクサー・レイ
ヤーへの転送」を参照してください。
ネットワーク要件
ネットワークのプロビジョニング
すべてのメンバーは、各メンバーが他のメンバーにアクセスできる⾼速ネットワーク上に配置する必要がありま
す。
メンバーは同じサブネット上または同じデータセンター内に存在していなくても構いません (データセンター間の
接続が⾼速な場合)。server.conf でサーチヘッド・クラスタリングの各種タイムアウト設定を調整することができ
ます。タイムアウト設定の詳細は、Splunk プロフェッショナル・サービスにお問い合わせください。
注意： ⼗分に⾼品質な接続がある場合は、複数のデータ・センターにまたがってサーチヘッド・クラスタをデプ
ロイすることができます。ただし、現在のバージョンの Splunk Enterprise では、サーチヘッド・クラスタはサ
イトを認識していません。たとえば、2 つのデータ・センターにまたがってメンバーが存在している場合に、ある
データ・センターのメンバー上に保存済みサーチの 1 つの複製コピーを、別のデータ・センターのメンバー上に
別のコピーを配置するように指定することはできません。クラスタ内で⼀連の過去のサーチ結果の複製⽅法をキャ
プテンが決定する際に、メンバーの場所は考慮されません。
クラスタ・メンバーが使⽤するポート
各メンバーがこれらのポートを使⽤できるようにする必要があります。
管理⽤ポート (デフォルトは 8089) は、他のすべてのメンバーが利⽤できるようにする必要があります。
http ポート (デフォルトは 8000) は、メンバーのデータにアクセスする任意のブラウザが利⽤できるように
する必要があります。
KV ストア・ポート (デフォルトは 8191) は、他のすべてのメンバーが利⽤できるようにする必要がありま
す。CLI コマンド splunk show kvstore-port を使ってポート番号を識別することができます。
複製⽤ポート は、他のすべてのメンバーが利⽤できるようにする必要があります。
これらのポートは、ファイアウォールの許可するポートに指定する必要があります。
警告： クラスタに参加している間は、メンバーの管理⽤ポートを変更しないでください。管理⽤ポートを変更す
る必要がある場合は、まずクラスタからメンバーを離脱させる必要があります。
分散サーチ環境でのシステム・クロックの同期
分散サーチに参加する Splunk Enterprise インスタンスを実⾏するマシンは、仮想マシンまたは物理マシンを問
わず、すべてシステム・クロックを同期する必要があります。特にクラスタ・メンバーとサーチ・ピアではこのこ
とが重要です。そうしないと、サーチ失敗、過去のサーチ結果の早期有効期限切れ、アラートに関する問題など、
さまざまな問題が発⽣する可能性があります。
使⽤する同期⽅法は、ご利⽤のマシンによって異なります。Splunk Enterprise を実⾏するマシンとオペレーティ
ング・システムのシステム・マニュアルを参照してください。⼤部分の環境では、ネットワーク・タイム・プロト
コル (NTP) が最適です。
デプロイヤーの要件
デプロイヤー として動作する Splunk Enterprise インスタンスが必要です。デプロイヤーはメンバーの設定を更
新します。「デプロイヤーを使った App と設定の更新の配布」を参照してください。
デプロイヤーの機能は、サーチヘッド・クラスタリング専⽤ですが、バージョン 6.2 以降が動作するすべての
Splunk Enterprise インスタンスに内蔵されています。デプロイヤーを動作させるインスタンスには、さまざまな
選択肢があります。
デプロイ・サーバーがある場合は、デプロイ・サーバーと同じインスタンスでデプロイヤーを実⾏します。
デプロイ・サーバーがないけれども、インデクサー・クラスタを使⽤している場合、インデクサー・クラス
タのマスター・ノードと同じインスタンスでデプロイヤーを動作させることも可能ですが、これはマスター
の負荷によって決まります。クラスタ・マスターの負荷限度については、『インデクサーとインデクサー・
クラスタの管理』の「マスター・ノードの追加の役割」を参照してください。
デプロイ・サーバーがなく、許容できる負荷程度のインデクサー・クラスタ・マスターもない場合は、専⽤
の Splunk Enterprise インスタンスでデプロイヤーを実⾏してください。
重要： サーチヘッド・クラスタのメンバー上にはデプロイヤーを配置しないでください。
その他の検討事項
デプロイ・サーバーとサーチヘッド・クラスタ
24
クラスタ・メンバーの更新にデプロイ・サーバーは使⽤しないでください。
設定や App のクラスタ・メンバーへの配布⼿段として、デプロイ・サーバーはサポートされていません。⼀連の
メンバーに設定を配布するには、サーチヘッド・クラスタ・デプロイヤーを使⽤する必要があります。「デプロイ
ヤーを使った App と設定の更新の配布」を参照してください。
サーチヘッド・クラスタリングとサーチヘッド・プーリング
サーチヘッド・プール の⼀部となっているインスタンスでサーチヘッド・クラスタリングを有効にすることはで
きません。移⾏の詳細は、「サーチヘッド・プールからサーチヘッド・クラスタへの移⾏」を参照してください。
サーチヘッド・クラスタのデプロイ
ここでは、サーチヘッド・クラスタの設定と開始に必要な主要⼿順を説明していきます。
サーチヘッド・クラスタの構成要素
サーチヘッド・クラスタは、設定、ジョブ・スケジュール、および過去のサーチ結果 を共有する、サーチヘッ
ド のグループで構成されています。サーチヘッドは、クラスタ・メンバー とも呼ばれます。
1 台のクラスタ・メンバーがキャプテン の役割を果たします。キャプテンは、各メンバー間のジョブとレプリ
ケーション活動を管理します。また、他のメンバーと同様にサーチヘッドとしての役割も果たし、サーチ・ジョブ
の実⾏や結果の提供などを⾏います。クラスタ・メンバー間で、キャプテンの役割が別のメンバーに引き継がれる
こともあります。
実際にサーチヘッド・クラスタを構成する⼀連のサーチヘッド・メンバーの他に、クラスタが機能するためには他
のコンポーネントも必要となります。
デプロイヤー： App やその他の設定をクラスタ・メンバーに配布する Splunk Enterprise インスタンスで
す。これはクラスタ外に配置されます。また、クラスタ・メンバーと同じインスタンス上で動作することは
できません。ただし、デプロイ・サーバーやインデクサー・クラスタのマスター・ノードなどの他の
Splunk Enterprise コンポーネントと同じインスタンス上で動作することは可能です。
サーチ・ピア ：クラスタのメンバーがサーチを実⾏する⼀連のインデクサーです。サーチ・ピアは独⽴した
インデクサー、またはインデクサー・クラスタ内のノードになります。
ロード・バランサー： サードパーティ製のソフトウェアまたはハードウェアで、必要に応じてユーザーと
クラスタ・メンバーの間に配置されます。ロード・バランサーを設置すると、ユーザーは単⼀のインター
フェイスから、特定のサーチヘッドを指定せずに、⼀連のサーチヘッドにアクセスすることができます。
3 メンバーの⼩規模なサーチヘッド・クラスタと各種コンポーネントの関係を表した図を以下に⽰します。
ここでは、クラスタ・メンバーとデプロイヤーの設定を中⼼に説明していきます。この章では、サーチピアの設
定、インデクサー・クラスタへの接続、ロード・バランサーの追加などについても説明しています。
クラスタのデプロイ
クラスタデプロイの主要ステップを以下に⽰します。
1. 要件を判断します。
2. デプロイヤーを設定します。
3. Splunk Enterprise インスタンスをインストールします。
25
4. クラスタ・メンバーを初期化します。
5. クラスタ・キャプテンを起動します。
6. デプロイ後の設定作業を実施します。
1.要件の判断
a. クラスタの規模、つまりクラスタに参加させるサーチヘッド数を決定します。⼀般的にはすべてのサーチヘッ
ドを単⼀のクラスタに参加させます。クラスタの規模に影響する要素には、予想されるサーチ負荷と同時ユーザー
数、および可⽤性とフェイルオーバーに関するニーズなどが挙げられます。「サーチヘッド・クラスタリングにつ
いて」を参照してください。
b. 複製データ保持数 を決定します。複製データ保持数は、クラスタが保持する過去のサーチ結果のコピー数で
す。最適な複製データ保持数は、ご利⽤の環境のさまざまな要因によって異なりますが、基本的には障害耐性とス
トレージ容量のトレードオフとなります。複製データ保持数に⾼い値を設定すると、より多くのクラスタ・メン
バー上により多くの過去のサーチ結果のコピーが保管されることになり、過去のサーチ結果へのアクセスにプロキ
シを使うことなく、メンバーの障害耐性を強化できます。ただし、追加のコピーを取り扱うためにより多くのスト
レージが必要になります。「サーチヘッド・クラスタの複製データ保持数の選択」を参照してください。
c. サーチヘッド・クラスタを⼀連のスタンドアロン・インデクサー向けに動作させるのか、またはインデク
サー・クラスタ向けに動作させるのかを決定します。インデクサー・クラスタの詳細は、『インデクサーとインデ
クサー・クラスタの管理』マニュアルの「クラスタとインデックス・レプリケーションについて」を参照してくだ
さい。
d. その他の問題については、「サーチヘッド・クラスタのシステム要件およびその他のデプロイに関する検討事
項」を参照してください。
2.デプロイヤーの設定
クラスタ設定の⼀環としてデプロイヤーを今選択することをお勧めします。デプロイヤーを設置しないと、クラス
タ・メンバーに App や更新された設定を配布できません。
a. デプロイヤーの役割を果たす Splunk Enterprise インスタンスを選択します。
このインスタンスをサーチヘッド・クラスタのメンバーにすることはできません。ただし状況によっては、他の⽬
的で使⽤される Splunk Enterprise インスタンスにすることが可能です。必要に応じて、デプロイヤーとして動
作させる新しい Splunk Enterprise インスタンスをインストールします。「デプロイヤーの要件」を参照してく
ださい。
デプロイヤーの機能は、すべての Splunk Enterprise インスタンス上で⾃動的に有効になります。次のステップ
で説明するように、必要な作業はデプロイヤーの秘密鍵を指定することだけです。この⼿順の後半で、クラスタ・
メンバーにアクセスさせるために、このデプロイヤー・インスタンスを指定します。
デプロイヤーを使ったクラスタ・メンバーに対する App の配布については、「デプロイヤーを使った App と更
新設定の配布」を参照してください。
b. デプロイヤーの秘密鍵を設定します。
「サーチヘッド・クラスタの秘密鍵の設定」を参照してください。
デプロイヤーは秘密鍵を使って、クラスタ・メンバーとの通信の認証を⾏います。クラスタ・メンバーもこれを
使って相互に認証を⾏います。この鍵の使⽤は省略できますが、使⽤する場合はすべてのクラスタ・メンバーおよ
びデプロイヤーが同じ値を使⽤する必要があります。クラスタ・メンバーへの鍵の設定は、その初期化時に⾏えま
す。
重要： 秘密鍵を設定することを強くお勧めします。
デプロイヤーに鍵を設定するには、デプロイヤーの
ザに、pass4SymmKey 属性を指定します。例：
server.conf
ファイルの
[general]
または
[shclustering]
スタン
[shclustering]
pass4SymmKey = yoursecretkey
鍵を有効にするには、デプロイヤーを再起動する必要があります。
3.Splunk Enterprise インスタンスのインストール
クラスタ・メンバーとして動作する Splunk インスタンスをインストールします。必要な最低メンバー数について
は、「必要なインスタンス数」を参照してください。
警告： 常に新たなインスタンスを使⽤してください。サーチヘッド・クラスタにインスタンスを追加する過程
で、そのインスタンス上に現在存在している設定や App はすべて上書きされます。
Splunk Enterprise のインストール⽅法については、『インストールマニュアル』を参照してください。
重要： 各インスタンスの管理者パスワードを変更する必要があります。クラスタの設定に使⽤する CLI コマンド
は、デフォルトのパスワードを持つインスタンス上では機能しません。
4.クラスタ・メンバーの初期化
26
クラスタに参加させる各インスタンスに対して、splunk
再起動します。
init shcluster-config
コマンドを実⾏してインスタンスを
splunk init shcluster-config -auth <username>:<password> -mgmt_uri <URI>:<management_port> -replication_port
<replication_port> -replication_factor <n> -conf_deploy_fetch_url <URL>:<management_port> -secret security_key
splunk restart
以下の事項に注意してください。
このコマンドは、動作中のインスタンスに対してのみ実⾏できます。
-auth パラメータには、このインスタンスの現在のログイン資格情報を指定します。このパラメータは必須で
す。
-mgmt_uri パラメータには、このインスタンスの URI と管理⽤ポートを指定します。完全修飾ドメイン名を
使⽤する必要があります。このパラメータは必須です。
-replication_port パラメータには、インスタンスが他のクラスタ・メンバーから送られてくる過去のサーチ
結果を待ち受けるために使⽤するポートを指定します。利⽤可能な任意の未使⽤ポートを複製ポートとして
指定することができます。インスタンスの管理⽤または受信⽤ポートを再利⽤しないでください。このパラ
メータは必須です。
-replication_factor パラメータは、クラスタが保持する過去のサーチ結果のコピー数です。すべてのクラス
タ・メンバーが同じ複製データ保持数を使⽤する必要があります。このパラメータは省略可能です。明⽰的
に設定しない場合、デフォルトの複製データ保持数 3 が使⽤されます。
conf_deploy_fetch_url パラメータには、デプロイヤー・インスタンスの URL と管理⽤ポートを指定します。
初期化中にこのパラメータの指定は省略できますが、デプロイヤーを使⽤する前に設定する必要がありま
す。「デプロイヤーを使った App と設定の更新の配布」を参照してください。
-secret パラメータには、クラスタ・メンバーが各メンバー間およびデプロイヤーとの通信の認証に使⽤する
秘密鍵を指定します。このパラメータは省略可能ですが、あるメンバーに設定したら、他のすべてのメン
バーにそれを設定する必要があります。鍵は、すべてのクラスタ・メンバーおよびデプロイヤーで同じでな
ければなりません。「サーチヘッド・クラスタの秘密鍵の設定」を参照してください。
重要： 秘密鍵を設定することを強くお勧めします。
例：
splunk init shcluster-config -auth admin:changed -mgmt_uri https://sh1.ajax.com:8089 -replication_port 34567 replication_factor 2 -conf_deploy_fetch_url https://10.160.31.200:8089 -secret mykey
splunk restart
警告： 最初のクラスタ・デプロイ後に他のメンバーを追加する場合は、「クラスタ・メンバーの追加」の⼿順に
従って作業を⾏ってください。
5.クラスタ・キャプテンの起動
a. 最初にクラスタのキャプテンとする、初期化済みのインスタンスを選択します。任意のインスタンスを選択で
きます。
b. 選択したインスタンス上で
splunk bootstrap shcluster-captain
コマンドを実⾏します。
splunk bootstrap shcluster-captain -servers_list "<URI>:<management_port>,<URI>:<management_port>,..." -auth
<username>:<password>
以下の事項に注意してください。
このコマンドは、指定したインスタンスを最初のクラスタ・キャプテンとして指名します。
このコマンドは、クラスタのライフサイクル全体にわたって、単⼀のインスタンスに対してのみ、そして 1
回のみ実⾏してください。
-servers_list パラメータには、このコマンドを実⾏するメンバーも含めた、クラスタ・メンバーのカンマ区
切りリストを指定します。メンバーは URI と管理⽤ポートで指定します。このパラメータは必須です。
重要： -servers_list に指定する URI は、各メンバーの初期化時に -mgmt_uri パラメータに指定したものと完
全に同じでなければなりません。たとえば、初期化時に https://foo.example.com:8089 を指定して、ここでは
https://foo.subdomain.example.com:8089 を指定することは、たとえ同じノードとして解釈される場合でもでき
ません。
bootstrap コマンドの例：
splunk bootstrap shcluster-captain -servers_list
"https://sh1.ajax.com:8089,https://sh2.ajax.com:8089,https://sh3.ajax.com:8089,https://sh4.ajax.com:8089" -auth
admin:changed
6.デプロイ後の設定作業の実施
セットアップを完了するには、以下の作業を実施します。
a. サーチヘッド・クラスタをインデクサー・クラスタと統合します。 このステップは省略することができま
27
す。「サーチヘッド・クラスタとインデクサー・クラスタの統合」を参照してください。
b. サーチヘッドをサーチ・ピアと接続します。 このステップは必須です。「クラスタ内のサーチヘッドのサー
チ・ピアへの接続」を参照してください。
サーチヘッド・クラスタのステータスの確認
サーチヘッド・クラスタの総合的なステータスを確認するには、いずれかのメンバーから以下のコマンドを実⾏し
ます。
splunk show shcluster-status -auth <username>:<password>
このコマンドは、キャプテンとクラスタ・メンバーに関する基本的な情報を返します。各メンバーのステータス
(稼働中または停⽌) が表⽰されます。
次のステップ
サーチヘッド・クラスタを設定したら、以下のような作業を⾏えます。
サーチヘッドの前⾯にロード・バランサーを設置する。「ロードバランサーとサーチヘッド・クラスタリン
グの使⽤」を参照してください。
デプロイヤーを使って、App や設定をサーチヘッドに配布する。「デプロイヤーを使った App と設定の更
新の配布」を参照してください。
サーチヘッド・クラスタとインデクサー・クラスタの統合
サーチヘッド・クラスタとインデクサー・クラスタ を統合するには、サーチヘッド・クラスタの各メンバーを、
インデクサー・クラスタのサーチヘッドとして設定する必要があります。それが完了したら、サーチヘッドはイン
デクサー・クラスタのマスター・ノードからサーチ・ピア のリストを取得します。
インデクサー・クラスタ⽤にサーチヘッド・クラスタ・メンバーを設定するには、splunk
ンドを使⽤します。例：
edit cluster-config
コマ
splunk edit cluster-config -mode searchhead -master_uri https://10.152.31.202:8089 -secret newsecret123
splunk restart
この例では、以下の事項を指定しています。
インスタンスは、インデクサー・クラスタ内のサーチヘッドである。
インデクサー・クラスタのマスター・ノードは、10.152.31.202:8089 にある。
秘密鍵は「newsecret123」。インデクサー・クラスタとサーチヘッド・クラスタの両⽅の、すべてのノー
ドが同じ秘密鍵を使⽤する必要があります。
この作業は、サーチヘッド・クラスタの各メンバーに対して⾏う必要があります。
基本的な設定で必要な事項は以上です。サーチヘッドは、インデクサー・クラスタ内のピア・ノードに対してサー
チを実⾏するようになります。
インデクサー・クラスタのサーチヘッドの設定の詳細は、『インデクサーとインデクサー・クラスタの管理』マ
ニュアルの「サーチヘッドの設定」を参照してください。この章には、サーチヘッドがインデクサー・クラスタと
⾮クラスタ構成のインデクサーの両⽅をサーチする、ハイブリッド・サーチなどの、より複雑なシナリオの設定に
ついても記載されています。
クラスタ内のサーチヘッドのサーチ・ピアへの接続
クラスタ内のサーチヘッドがサーチを実⾏するには、インデクサー (サーチ・ピア ) の ID を知る必要がありま
す。クラスタのすべてのメンバーが、同じ⼀連のサーチ・ピアにアクセスできる必要があります。
サーチヘッドがサーチ・ピアを探す⽅法は、サーチヘッド・クラスタがインデクサー・クラスタ の⼀部かどうか
によって異なります。検討する必要がある 2 種類のシナリオがあります。
サーチヘッド・クラスタはインデクサー・クラスタに対して実⾏される。
サーチヘッド・クラスタは個別の⾮クラスタ構成インデクサーに対して実⾏される。
重要： クラスタ・メンバーは、他のクラスタ・メンバーにサーチを分散することはできません。つまり、クラス
タ・メンバーが、そのクラスタのサーチ・ピアになることはできません。
サーチヘッド・クラスタとインデクサー・クラスタの使⽤
サーチヘッド・クラスタがインデクサー・クラスタに接続している場合、インデクサー・クラスタのマスター・
ノードはサーチ対象ピア・ノードのリストをサーチヘッドに提供します。
サーチヘッド・クラスタ・メンバーをインデクサー・クラスタに参加するように設定したら、サーチヘッドにサー
チ・ピアを知らせるためのさらなる設定は不要です。「サーチヘッド・クラスタとインデクサー・クラスタの統
合」を参照してください。
インデックス・レプリケーションが不要な場合でも、⼀連のサーチ・ピアを設定するこの簡単な⼿段は役⽴ちま
28
す。インデクサーをインデクサー・クラスタに複製データ保持数 1 で追加するだけです。このトポロジーには、
管理上の観点からもさまざまな利点があります。『インデクサーとインデクサー・クラスタの管理』マニュアルの
「インデクサー・クラスタを使ったインデックス作成環境の拡張」を参照してください。
⾮クラスタ構成インデクサーを持つサーチヘッド・クラスタ
インデクサー・クラスタがない場合、各サーチヘッドにサーチ・ピアを個別に追加する必要があります。そのため
のもっとも簡単な⽅法は、CLI を使⽤することです。各サーチヘッド上で以下の作業を⾏います。
1. サーチヘッド上の
$SPLUNK_HOME/bin/
ディレクトリに移動します。
2. 追加する各サーチピアに対して、splunk
add search-server
コマンドを発⾏します。
splunk add search-server -host <URI>:<management_port> -auth <user>:<password> -remoteUsername <user> remotePassword <password>
以下の事項に注意してください。
サーチ・ピアの URI と管理⽤ポートを指定するには、-host フラグを使⽤します。
ローカルインスタンス (サーチヘッド) とリモートインスタンス (サーチピア) の両⽅の資格情報を指定しま
す。ローカル資格情報の場合は -auth フラグを、リモート資格情報の場合は -remoteUsername および remotePassword フラグを使⽤します。リモート資格情報は、サーチピアの管理者レベルのユーザーのものでな
ければなりません。
この例でサーチ・ピアの IP アドレスは
passremote となっています。
10.10.10.10、管理⽤ポートは 8089
で、admin ユーザーのパスワードは
splunk add search-server -host 10.10.10.10:8089 -auth admin:mypassword -remoteUsername admin -remotePassword
passremote
3. すべてのサーチ・ピアを追加したら、サーチヘッドを再起動します。
この⼿順は各サーチヘッド上で繰り返す必要があります。すべてのサーチヘッドが⼀連の同じサーチ・ピアを使⽤
する必要があります
Splunk Web でサーチ・ピアを追加することもできます。そのためには、まず「[設定] メニュー」の説明に従って
隠し設定を表⽰する必要があります。次に「サーチ・ピアの追加」の説明に従って作業を⾏います。
サーチヘッド・データのサーチ・ピアへの転送
サーチヘッドのすべての内部データを、ピア (インデクサー) 層に転送することが、ベストプラクティスと考えら
れています。サーチヘッドをサーチ・ピアに接続したら、「ベスト・プラクティス：サーチヘッド・データのイン
デクサー層への転送」を参考に作業を⾏います。
ロード・バランサーとサーチヘッド・クラスタリングの使⽤
クラスタ構成サーチヘッドの前⾯にサードパーティ製ハードウェア/ソフトウェアのロード・バランサーを設置す
ることをお勧めします。このようにして、ユーザーは単⼀のインターフェイスから、特に特定のサーチヘッドを指
定せずに、⼀連のサーチヘッドにアクセスすることができます。
この⽬的で使⽤できるさまざまなサードパーティ製ロード・バランサーが存在しています。レイヤー 7 (アプリ
ケーション・レベル) の処理を採⽤したロード・バランサーを選択してください。
ユーザー・セッションが「継続的」または「固定」になるようにロードバランサーを設定します。そうすることに
よって、そのセッション中ユーザーは、単⼀のサーチヘッドにより対応されることになります。
サーチヘッド・プールからサーチヘッド・クラスタへの移⾏
サーチヘッド・プールからサーチヘッド・クラスタに設定を移⾏することができます。ただし、サーチヘッドのイ
ンスタンス⾃体を移⾏することはできません。サーチヘッド・クラスタ・メンバーを有効にするには、新しいイン
スタンスを使⽤する必要があります。
サーチヘッド・プールからサーチヘッド・クラスタに設定を移⾏するには、サーチヘッド・プールの共有ディレク
トリをデプロイヤーにコピーします。次にデプロイヤーを使って、それらのディレクトリをクラスタ・メンバーに
配布します。
新しいクラスタに移⾏するのか、またはすでに稼働中のクラスタに移⾏するのかによって、移⾏⼿順は多少異なり
ます。
警告： サーチヘッド・クラスタに App を移⾏する場合、デフォルトの App (サーチ App などの Splunk
Enterprise に同梱されている App) は移⾏しないでください。デフォルトの App をクラスタ・メンバーに配布す
ると、メンバーに存在しているバージョンの App が上書きされてしまいます。これは望ましいことではありませ
ん。ただし、デフォルトの App に関連したプライベートなオブジェクトは移⾏しても構いません。プライベート
なオブジェクトは /etc/users にあります。/etc/apps ではありません。
新しいサーチヘッド・クラスタへの移⾏
29
サーチヘッド・プールから新しいサーチヘッド・クラスタに設定を移⾏するには：
1. 新しいサーチヘッド・クラスタのデプロイ⼿順に従って作業を⾏います。クラスタ・メンバーの初期化時に、デ
プロイヤーの場所を指定します。「サーチヘッド・クラスタのデプロイ」を参照してください。
警告： 新しいインスタンスをデプロイする必要があります。既存のサーチヘッドを再利⽤することはできませ
ん。
2. サーチヘッド・プールの共有ストレージにある /etc/apps と /etc/users ディレクトリを、デプロイヤーの配布⽤
ディレクトリにコピーします。配布⽤ディレクトリは、$SPLUNK_HOME/etc/shcluster にあります。
配布⽤ディレクトリのファイル構造については、「設定バンドルの内容」を参照してください。
3. $SPLUNK_HOME/etc/shcluster/apps にデフォルトの App (サーチ App など) がある場合は、それを削除する必要が
あります。これらをクラスタ・メンバーには配布しないでください。そうしてしまうと、すでにメンバーに存在し
ている App が上書きされてしまいます。
4. 設定バンドルのクラスタ・メンバーへの配布には、デプロイヤーを使⽤します。「設定バンドルの配布」を参照
してください。
注意： クラスタ・メンバーに、以前にサーチヘッド・プールが使⽤していたのと同じ⼀連のサーチ・ピアを指定
しないと、クラスタはサーチ・ピアに存在しているレポート⾼速化サマリーやデータ・モデル・サマリーを再作成
する必要があります。この処理は⾃動的に⾏われます。ただし、古いサマリーは⾃動的には削除されません。
既存のサーチヘッド・クラスタへの移⾏
サーチヘッド・プールから既存のサーチヘッド・クラスタに設定を移⾏するには：
1. サーチヘッド・プールの共有ストレージにある
時ディレクトリにコピーします。
/etc/apps
と
/etc/users
ディレクトリを、それらを編集可能な⼀
2. ⼀時ディレクトリで、以下のサブディレクトリを削除します。
サーチ App などのデフォルト App。デフォルトの App をクラスタ・メンバーには配布しないでくださ
い。そうしてしまうと、すでにメンバーに存在している App が上書きされてしまいます。
デプロイヤーの配布⽤ディレクトリにすでに存在している App。そうしないと、サーチヘッド・プールから
のバージョンで、メンバー上にすでに存在しているバージョンが上書きされてしまいます。
3. 残りのサブディレクトリを⼀時ディレクトリから、$SPLUNK_HOME/etc/shcluster にあるデプロイヤーの配布⽤ディ
レクトリにコピーします。配布⽤ディレクトリにすでに存在しているサブディレクトリは、そのまま残します。
配布⽤ディレクトリのファイル構造については、「設定バンドルの内容」を参照してください。
4. デプロイヤーを使って、移⾏設定も含めた設定バンドルをクラスタ・メンバーに配布します。「設定バンドルの
配布」を参照してください。
スタンドアロンのサーチヘッドからサーチヘッド・クラスタへの移⾏
既存のスタンドアロン・サーチヘッドからサーチヘッド・クラスタ内のすべてのメンバーに設定を移⾏することが
できます。
重要： サーチヘッドのインスタンスは移⾏できません。設定のみ移⾏できます。サーチヘッド・クラスタには、
新しい Splunk Enterprise インスタンスのみを追加できます。
設定を移⾏するには：
1. スタンドアロンのサーチヘッドの
時ディレクトリにコピーします。
$SPLUNK_HOME/etc/apps
と
$SPLUNK_HOME/etc/users
ディレクトリを、編集可能な⼀
2. ⼀時ディレクトリで、以下のサブディレクトリを削除します。
サーチ App などのデフォルト App。デフォルトの App をクラスタ・メンバーには配布しないでくださ
い。そうしてしまうと、すでにメンバーに存在している App が上書きされてしまいます。
デプロイヤーの配布⽤ディレクトリにすでに存在している App。そうしないと、スタンドアロンのサーチ
ヘッドからのバージョンで、メンバー上にすでに存在しているバージョンが上書きされてしまいます。
3. 残りのサブディレクトリを⼀時ディレクトリから、デプロイヤーの配布⽤ディレクトリにコピーします。配布⽤
ディレクトリは、$SPLUNK_HOME/etc/shcluster にあります。配布⽤ディレクトリにすでに存在しているサブディレク
トリは、そのまま残します。
配布⽤ディレクトリのファイル構造については、「設定バンドルの内容」を参照してください。
4. 新しいクラスタ・メンバーを追加する必要がある場合は、新しいクリーンなインスタンスを使⽤する必要があり
ます。既存のサーチヘッドを再利⽤することはできません。クラスタ・メンバーの追加については、「クラスタ・
メンバーの追加」を参照してください。
5. デプロイヤーを使って、移⾏設定も含めた設定バンドルをクラスタ・メンバーに配布します。「設定バンドルの
配布」を参照してください。
注意： クラスタ・メンバーに、以前にスタンドアロンのサーチヘッドが使⽤していたのと同じ⼀連のサーチ・ピ
アを指定しないと、クラスタはサーチ・ピアに存在しているレポート⾼速化サマリーやデータ・モデル・サマリー
を再作成する必要があります。この処理は⾃動的に⾏われます。ただし、古いサマリーは⾃動的には削除されませ
ん。
30
ん。
サーチヘッド・クラスタリングの設定
サーチヘッド・クラスタの設定
ここでは、サーチヘッド・クラスタの動作の設定⽅法について説明していきます。クラスタ・メンバーがアクセス
する⼀連の保存済みサーチ、ダッシュボード、および App などの、クラスタ・メンバーのサーチ時環境の設定に
ついては説明していません。サーチ時環境の設定については、「サーチヘッド・クラスタ・メンバーの更新」を参
照してください。
メンバーはクラスタ設定を、$SPLUNK_HOME/etc/system/local/ にあるローカルの server.conf ファイルに保管します。
利⽤可能な設定属性については、server.conf ファイルを参照してください。
主要情報
このトピックを参照する際には、以下の事項に留意してください。
基本的な設定作業は、デプロイ中の各メンバーの初期化時に⾏います。
サーチヘッド・クラスタリングには、多数の設定項⽬が存在しています。いくつかの例外を除き、Splunk
サポートからの指⽰なしでこれらの設定の初期値/デフォルト値を変更しないでください。
特に記載のない限り、すべてのメンバーで同⼀の設定を使⽤する必要があります。
すべてのメンバーの設定を変更した場合、すべてのメンバーをほぼ同時に再起動する必要があります。
初期化時の設定
基本的な設定はすべて、デプロイ中の各メンバーの初期化時に⾏えます。初期化時に各クラスタ・メンバーに設定
できる、または設定する必要がある、主な設定属性を以下に⽰します。
メンバーの URI。「サーチヘッド・クラスタのデプロイ」を参照してください。
メンバーの複製⽤ポート。「サーチヘッド・クラスタのデプロイ」を参照してください。
クラスタの複製データ保持数。「サーチヘッド・クラスタの複製データ保持数の選択」を参照してくださ
い。
クラスタの秘密鍵。「サーチヘッド・クラスタの秘密鍵の設定」を参照してください。
デプロイヤーの場所。「クラスタ・メンバーへのデプロイヤーの指定」を参照してください。
警告： これらの属性は初期化時に設定し、その後は変更しないことを強くお勧めします。「サーチヘッド・クラ
スタのデプロイ」を参照してください。
初期化後の設定の変更
初期化後でも安全に⾏える設定の変更は、アドホック・サーチの設定です。特定のメンバーがアドホック・サーチ
のみを実⾏するかどうか、および現在キャプテンとして動作しているメンバーがアドホック・サーチのみを実⾏す
るかどうかを設定することができます。アドホック・サーチのみ実⾏するように指定されたデプロイメンバーに
は、スケジュール済みサーチは割り当てられません。「アドホック・サーチのみを実⾏するようにクラスタ・メン
バーを設定」を参照してください。
すべてのメンバー間で同じ設定を維持
サーチヘッド・クラスタリングの
下の例外があります。
server.conf
属性の値は、すべてのメンバーで同じにする必要がありますが、以
mgmt_uri
adhoc_searchhead
[replication_port://<port>]
上記以外の設定値がメンバー間で異なっている場合、現在キャプテンの役割を果たしているメンバーによってクラ
スタの動作が異なります。そのような事態にならないようにしてください。
設定⽅法
設定作業の⼤半は初期のクラスタ・デプロイ時に CLI コマンド
には、2 種類の⽅法があります。
CLI の
splunk edit shcluster-config
server.conf
の
[shclustering]
splunk init
を使って⾏います。後ほど設定を⾏う
コマンドを使⽤する。
スタンザを直接編集する。
⼀般的には、CLI を使⽤する⽅が簡単です。
警告： すべてのメンバーに対して同じように設定の変更を⾏ってから、それらをほぼ同時に再起動する必要があ
ります。すべてのメンバー間で同⼀の設定を維持することが重要なため、再起動に splunk rolling-restart コマン
ドは使⽤しないでください。ただし、「アドホック・サーチのみを実⾏するようにクラスタ・メンバーを設定」で
説明しているように、captain_is_adhoc_searchhead 属性を変更する場合は例外です。代わりに各メンバー上
で、splunk restart コマンドを実⾏します。
CLI を使ったサーチヘッド・クラスタリングの設定
31
CLI の splunk edit shcluster-config コマンドを使って、server.conf 内の
できます。各属性と設定値をキー/値のペアとして指定してください。
[shclustering]
スタンザを編集することが
たとえば、adhoc_searchhead 属性を編集するには：
splunk edit shcluster-config -adhoc_searchhead true -auth <username>:<password>
操作が成功して、splunkd の再起動を指⽰するメッセージが表⽰されます。
以下の事項に注意してください。
サーチヘッド・クラスタリングのオン/オフを切り替える disabled 属性を除き、このコマンドを使って
[shclustering] スタンザ内の任意の属性を編集できます。
このコマンドは、初期化されたメンバー上でのみ利⽤できます。初期設定には、splunk init shcluster-config
を使⽤します。
server.conf の編集によるサーチヘッド・クラスタリングの設定
を直接編集して属性を変更することもできます。サーチヘッド・クラスタリングの属性は
スタンザにありますが、1 つ例外があります。複製⽤ポートを変更するには、[replication_port] ス
タンザを使⽤します。
server.conf
[shclustering]
サーチヘッド・クラスタの複製データ保持数の選択
複製データ保持数は、クラスタが保持する過去のサーチ結果 (またはサーチ結果) のコピー数です。保存されたス
ケジュール済みサーチの過去のサーチ結果に対してのみ複製が⾏われます。クラスタはアドホック・サーチやリア
ルタイム・サーチの結果を複製しません。
複製データ保持数の効果
クラスタは、「複製データ保持数 - 1」台のメンバー障害に、過去のサーチ結果を失わずに対処することができま
す。たとえば、システムで 2 台までのメンバー障害発⽣に過去のサーチ結果を失わずに対処できるようにするた
めには、複製データ保持数に 3 を設定する必要があります。この場合、クラスタは 3 つの過去の各サーチ結果の
コピーを、個別のメンバーに保管します。2 台のメンバーが停⽌しても、3 台⽬のメンバーの過去のサーチ結果を
利⽤することができます。
複製データ保持数のデフォルト値は、3 です。たいていの場合は、この値で⼗分です。
たとえば 50 台のサーチヘッドがある⼤規模なクラスタでも、それに合わせて複製データ保持数に⼤きな値を設定
する必要はありません。複製データ保持数に相当するメンバーが停⽌しない限り、クラスタ内にはそれぞれの過去
のサーチ結果のコピーが最低 1 つ存在しており、すべてのクラスタ・メンバーがそれにアクセスできます。クラ
スタ内のサーチヘッドは、プロキシにより過去のサーチ結果のコピーを保管しているサーチヘッドにアクセスでき
ます。プロキシ操作は⾼速で、他のサーチヘッドのサーチ結果へのアクセスに遅延が発⽣することはほとんどあり
ません。
注意： 複製データ保持数は、クラスタが保持する過去のサーチ結果のコピー数のみを決定します。新しい保存済
みサーチなど、実⾏時の設定変更には影響を与えません。そのような変更は、別の⼿段によりすべてのクラスタ・
メンバーに複製されます。50 台のサーチヘッドがある場合、それらの 50 台すべてがそのような設定の変更を受
け取ります。「クラスタが複製する設定の更新」を参照してください。
複製データ保持数の設定
すべてのクラスタ・メンバーが同じ複製データ保持数を使⽤する必要があります。複製データ保持数を決める
server.conf の属性は、replication_factor です。
複製データ保持数はクラスタのデプロイ時に、メンバー初期化の⼀環として指定します。「クラスタ・メンバーの
初期化」を参照してください。
必要に応じてデプロイ後に複製データ保持数を変更できますが、そうする前に Splunk サポートに相談することを
お勧めします。あるメンバー上で複製データ保持数を変更したら、すべてのメンバーに対してそれを変更する必要
があります。設定値の変更については、「サーチヘッド・クラスタの設定」を参照してください。
その他の参考情報
クラスタによる過去のサーチ結果の複製⽅法については、「クラスタによる過去のサーチ結果の取り扱い」を参照
してください。そのトピックには、過去のサーチ結果の複製について、以下のような事項も含めてさまざまな
キー・ポイントが記載されています。
場合によっては、クラスタが過去のサーチ結果のコピーを、複製データ保持数以上に複製することもありま
す。
ある過去のサーチ結果を持たないメンバーがそれにアクセスする必要がある場合、プロキシを使ってそれに
アクセスします。また、追加の複製処理が⾏われます。
あるメンバーが停⽌すると、そのメンバーに保管されていた過去のサーチ結果のコピーが別のメンバーに配
置されます。
クラスタ内の各メンバーの⼀連の過去のサーチ結果の表⽰⽅法については、「過去のサーチ結果の⼀覧表⽰」を参
照してください。
32
サーチヘッド・クラスタの秘密鍵の設定
各クラスタ・メンバー間およびメンバーとデプロイヤー間の通信を認証するための、秘密鍵を設定することができ
ます。
サーチヘッド・クラスタリング設定の概要については、「サーチヘッド・クラスタの設定」を参照してください。
秘密鍵はすべてのノードで同⼀にする
あるクラスタ・メンバーに鍵を設定した場合、その他すべてのメンバーとにも同じ値で鍵を設定する必要がありま
す。
サーチヘッド・クラスタがインデクサー・クラスタの⼀部である場合、両⽅のクラスタで同じ鍵を使⽤する必要が
あります。
ベストプラクティス：デプロイ時に秘密鍵を設定する
鍵はデプロイ時に、CLI コマンド splunk init shcluster-config に -secret パラメータを指定して設定することを強
くお勧めします。「サーチヘッド・クラスタのデプロイ」を参照してください。
デプロイ後の秘密鍵の設定
デプロイ後に秘密鍵を変更するには、各クラスタ・メンバー上で server.conf の
この属性は [shclustering] または [general] スタンザ下に指定します。例：
pass4SymmKey
属性を編集します。
[shclustering]
pass4SymmKey = yoursecretkey
サーチヘッド・クラスタがインデクサー・クラスタの⼀部である場合、サーチヘッド・クラスタのメンバーとイン
デクサー・クラスタのノードの両⽅が同じ鍵を使⽤するように、鍵を [general] スタンザに設定します。
鍵を有効にするには、各インスタンスを再起動する必要があります。デプロイ後の設定については、「設定⽅法」
を参照してください。
秘密鍵のコピーの保持
鍵のコピーを安全な場所に保管する必要があります。インスタンスが動作を開始すると、秘密鍵は平⽂から暗号化
された形式に変更されるため、server.conf から復元することはできません。後ほど新たなメンバーを追加する場
合、鍵を設定するために平⽂の鍵が必要になります。
サーチヘッド・クラスタのメンバーの更新
サーチヘッド・クラスタへの設定変更の配布⽅法
最初にお読みください：
このトピックをお読みになる前に：
『管理マニュアル』の「設定ファイルを使ったSplunk Enterprise の管理」を参照してください。その章に
は、設定ファイルに関する重要なバックグラウンド情報が記載されています。
サーチヘッド・クラスタにおける設定ファイルの重要性
設定ファイルは、⼀連のナレッジ・オブジェクト も含めて、サーチヘッドの機能を制御します。たとえば、保存
済みサーチ 、イベント・タイプ 、およびワークフロー・アクション ⽤の設定ファイルが存在しています。その
他の設定ファイルには、データ⼊⼒やインデックス作成などの、サーチ以外の機能に関する設定項⽬が含まれてい
ます。『管理マニュアル』の「設定ファイルの⼀覧」を参照してください。
設定ファイル以外でも、サーチ時機能に重要なファイルが存在しています。たとえば、静的なルックアップ ・
テーブル、ダッシュボード 、およびデータ・モデル は、その定義の⼀環として各種ファイルを使⽤します。
サーチヘッド・クラスタが正常に動作するには、すべてのメンバーが同じサーチ関連の設定を使⽤する必要があり
ます。たとえば、クラスタ内のすべてのサーチヘッドは、同じセットの保存済みサーチにアクセスできなければな
りません。そのため、同じ savedsearches.conf 設定を使⽤する必要があります。
クラスタ内のすべてのサーチヘッドに対して、App も同⼀である必要があります。本質的に App は、⼀連の設定
情報です。
注意： 単⼀のサーチヘッドのみに、App をローカルにインストールできます。トラブルシューティングやテスト
⽬的などで、このような作業を⾏います。ただし、実際に利⽤されている環境では、App も含めたすべての設定
を、すべてのクラスタ・メンバー間で同じに維持することが重要です。
サーチヘッド・クラスタへの設定変更の配布⽅法
サーチヘッド・クラスタは、メンバー間で設定が同⼀であることを保証するために、⾃動レプリケーションとデプ
ロイヤーの 2 種類の⼿段を利⽤しています。
33
変更の複製
実⾏時のナレッジ・オブジェクトの変更は、そのクラスタ・メンバーから他のすべてのメンバーに⾃動的に複製さ
れます。これには、たとえば保存済みサーチ、ルックアップ・テーブル、およびダッシュボードの変更や追加など
が含まれます。たとえば、ユーザーが Splunk Web でフィールド抽出を定義した場合、クラスタ内のすべての
サーチヘッドにフィールド抽出が複製されます。
「クラスタが複製する設定の更新」を参照してください。
変更のデプロイ
クラスタではすべての設定変更が複製される訳ではありません。実⾏時に Splunk Web、CLI、または REST API
で⾏われた変更のみが複製されます。その他の設定の変更や追加が⾏われた場合、それを明⽰的にすべてのクラス
タ・メンバーに配布する必要があります。この作業には、デプロイヤーと呼ばれる特別な Splunk Enterprise イ
ンスタンスが⽤いられます。
デプロイヤーを使⽤する必要がある変更の例としては、設定ファイルに対する直接の変更が挙げられます。たとえ
ば、limits.conf で変更を⾏った場合、デプロイヤーを使ってその変更を配布する必要があります。同様
に、savedsearches.conf などのナレッジ・オブジェクト設定ファイルを直接編集した場合も、デプロイヤーを使っ
てクラスタ・メンバーにそれを配布する必要があります。また、新しい App やアップグレードした App のクラ
スタ・メンバーへの配布にも、デプロイヤーを使⽤します。
「デプロイヤーを使った App と設定の更新の配布」を参照してください。
[設定] メニュー
Splunk Web の[設定] メニューには、各種設定がさまざまなグループに分類されています。たとえば、[ナレッジ]
にはナレッジ・オブジェクト関連の設定が含まれています。サーチヘッド・クラスタリングはデフォルトで、各メ
ンバーの [設定] メニューのすべての⾮ナレッジ・グループを⾮表⽰にしています。たとえば、データ⼊⼒および
分散環境に関する設定が⾮表⽰になります。必要に応じて⾮表⽰になっているカテゴリを表⽰することができま
す。
⾮ナレッジ設定を⾮表⽰にする理由は、クラスタがナレッジ・カテゴリの設定項⽬への変更しか複製しないためで
す。あるメンバー上でナレッジ以外の設定項⽬を変更した場合、他のメンバーにその変更は⾃動的には複製されま
せん。
メンバー上でナレッジ以外の設定項⽬を利⽤する必要がある場合は、⾮表⽰の設定を表⽰することができます。
1. Splunk Web の右上にある [設定] をクリックします。[ナレッジ] グループのみに限定された設定項⽬が表⽰さ
れます。
2. リストの最後にある、[すべての設定を表⽰] ボタンをクリックします。⾮表⽰の設定項⽬に対する変更は複製
されないことを知らせるダイアログ・ボックスが表⽰されます。
3. 続⾏するには、ダイアログ・ボックスの [表⽰] をクリックします。ロールの権限に応じた、⼀連の設定が表⽰
されます。
admin ユーザーなど、これらの設定項⽬を表⽰する権限があるすべてのユーザーに対して、設定項⽬が表⽰され
るようになります。設定を再び⾮表⽰にする場合は、インスタンスを再起動する必要があります。
重要： ⾮ナレッジ設定を変更した場合、その設定変更はそれを⾏ったクラスタ・メンバー上にのみ存在します。
他のメンバーも変更したい場合は、デプロイヤーを使って該当する設定ファイルを配布する必要があります。
クラスタが複製する設定の更新
実⾏時のナレッジ・オブジェクト の変更は、そのクラスタ・メンバーから他のすべてのメンバーに⾃動的に複製
されます。これには、たとえば保存済みサーチ 、ルックアップ ・テーブル、およびダッシュボード の変更や追
加などが含まれます。たとえば、ユーザーが Splunk Web でフィールド抽出 を定義した場合、クラスタ内のすべ
てのサーチヘッドにフィールド抽出が複製されます。
注意： クラスタの複製データ保持数に関係なく、設定の変更はすべてのクラスタ・メンバーに複製されます。複
製データ保持数は、過去のサーチ結果の複製にのみ適⽤されます。
ホワイトリストは、複製される変更のタイプを決定します。このリストを利⽤して、特定のタイプを除外すること
ができます。
複製の仕組み
クラスタ・メンバーのサーチヘッドの設定を変更すると、メンバーは設定をファイル (または複数のファイル) に
ローカルに保存して、その変更をキャプテンに送信します。クラスタ内の各メンバーは約 5 秒ごとにキャプテン
と連絡を取り、前回の変更を受け取った後に何か変更があった場合はそれを取得します。次に各クラスタ・メン
バーは受け取った変更をローカルに適⽤します。
たとえば、ユーザーがあるクラスタ・メンバーで Splunk Web を使って新しいフィールド抽出を作成した場合を
考えてみましょう。Splunk Web は、そのメンバーのローカル・ファイルにフィールド抽出を保存します。メン
バーは、ファイルの変更をキャプテンに送信します。各クラスタ・メンバーが次にキャプテンと連絡を取った時
に、その変更も含めて最近に⾏われた変更を取得して、各⾃がローカルにそれを適⽤します。数秒ほどで、すべて
のクラスタ・メンバーが新しい抽出を持つことになります。
注意： この⽅法で複製、更新されたファイルは、⼀連のクラスタ・メンバー間で意味的/機能的に同等です。ただ
し、すべてのメンバー上でファイルが同⼀ではない場合もあります。たとえば環境によっては、変更がキャプテン
34
に届く順番などの要因により、props.conf 内の更新された設定が、メンバーによって異なる場所に記載されること
があります。
クラスタが複製する変更
クラスタはナレッジ・オブジェクトへの変更を複製します。
複製には以下の制限があります。
特定の設定⽅法で⾏われた変更のみが複製されます。
ホワイトリストは、複製される変更のタイプを決定します。
複製が⾏われる変更⽅法
クラスタでは、以下の⽅法で⾏われた変更のみが複製されます。
Splunk Web
CLI
REST API
設定ファイルを直接編集して⾏われた変更は複製されません。
たとえば、ユーザーがあるクラスタ・メンバーで Splunk Web を使って保存済みサーチを作成した場合、その保
存済みサーチはすべてのクラスタ・メンバーに複製されます。しかし、管理者があるクラスタ・メンバー上で
savedsearches.conf ファイルを直接編集して保存済みサーチを追加した場合、その保存済みサーチは他のクラス
タ・メンバーには複製されません。代わりにデプロイヤーを使って、その保存済みサーチをクラスタ・メンバーに
配布する必要があります。
複製のホワイトリスト
クラスタはホワイトリストを使って、複製する変更を判断します。ホワイトリスト
は、$SPLUNK_HOME/etc/system/default にあるデフォルト版の server.conf に、⼀連の conf_replication_include 属性を
使って設定します。
メンバーの $SPLUNK_HOME/etc/system/local 下にある server.conf を編集して、このリストに項⽬を追加/削除するこ
とができます。ホワイトリストを変更する場合は、すべてのクラスタ・メンバーに対して同じ変更を⾏う必要があ
ります。
ホワイトリスト内の項⽬の総合的なリストについては、デフォルト版の
トリスト項⽬の⼀般的な例を以下に⽰します。
server.conf
を参照してください。ホワイ
alert_actions
commands
datamodels
event_renderers
eventtypes
fields
history
html
literals
lookups
macros
manager
models
multikv
nav
panels
props
quickstart
savedsearches
searchbnf
searchscripts
segmenters
tags
times
transforms
transactiontypes
ui-prefs
user-prefs
views
viewstates
workflow_actions
クラスタは、ホワイトリスト項⽬に指⽰されているすべてのファイルへの変更を複製します。これには設定ファイ
ルだけではなく、ダッシュボードや nav XML、ルックアップ・テーブル・ファイル、データ・モデル JSON ファ
イルなども含まれます。また、*.meta ファイルに含まれている権限も複製されます。
35
各種ホワイトリスト項⽬に対して複製されるファイル・タイプの例を以下に⽰します。
# escape-hatch HTML views
conf_replication_include.html = true
# lookup table files
conf_replication_include.lookups = true
# manager XML
conf_replication_include.manager = true
# datamodel JSON files
conf_replication_include.models
= true
# nav XML
conf_replication_include.nav = true
# view XML
conf_replication_include.views = true
クラスタが無視する変更
クラスタは、ホワイトリストに記載されていない項⽬に対する設定の変更を無視します。たとえば、データ⼊⼒や
インデックスを定義するデータ⼊⼒などの、インデックス時設定が挙げられます。
また、Splunk Web、CLI、または REST API を使った変更のみが複製されます。設定ファイルを直接編集した場
合、それは複製されません。代わりにデプロイヤーを使って、ファイルをすべてのクラスタ・メンバーに配布する
必要があります。
また、新たにインストールまたはアップグレードされた App も、クラスタ・メンバーには複製されません。
このような設定の変更をデプロイヤーを使って配布する⽅法については、「デプロイヤーを使った App と更新設
定の配布」を参照してください。
複製の実施時期
複製の⽬的はサーチ関連の設定を、すべてのクラスタ・メンバー間で同期することにあります。そのために、メン
バーの状態に応じてさまざまな時点で複製が実施されます。
クラスタ内のアクティブな各メンバー は約 5 秒ごとにキャプテンと連絡を取り、前回の変更を受け取った
後に⾏われた変更を取得します。
注意： メンバーがキャプテンと連絡を取る間隔は、server.conf の
す。
conf_replication_period
属性で編集できま
新しいメンバーがクラスタに参加した場合 、それはキャプテンに連絡を取って現在複製されている⼀連の
設定を含む TAR 書庫をダウンロードします。それには、これまでにクラスタ内で⾏われたすべての変更が
含まれています。メンバーは TAR 書庫をローカルに適⽤します。
メンバーがクラスタに再参加した場合 。まず、「以前にクラスタから削除したメンバーの追加」の説明に
従って、インスタンスをクリーニングしてから、それをクラスタに再追加してください。メンバーはキャプ
テンに連絡を取り、新しいメンバーを追加した時と同様に、TAR 書庫をダウンロードします。
メンバーが予期せずに停⽌した場合については、「サーチヘッド・クラスタ・メンバーの障害への対処」を
参照してください。場合によっては、メンバーは⼀連の中間的な変更をダウンロードして、それを適⽤する
ことができます。また、TAR 書庫を適⽤するために、splunk resync コマンドの実⾏が必要なこともありま
す。
デプロイヤーを使った App と設定の更新の配布
デプロイヤーは、サーチヘッド・クラスタのメンバーに App や他の更新された設定を配布するために使⽤する
Splunk Enterprise インスタンスです。デプロイヤーが配布する⼀連の更新情報は、設定バンドル と呼ばれてい
ます。
デプロイヤーは、コマンドが実⾏されると設定バンドルの配布を⾏います。またデプロイヤーは、クラスタに参
加/再参加した任意のメンバーにもバンドルを⾃動的に配布します。
警告： クラスタ・メンバーへの App の配布には、デプロイ・サーバーではなくデプロイヤーを使⽤する必要があ
ります。デプロイヤーを使⽤することで、クラスタが⾃動的に複製するサーチ実⾏時の更新との競合の可能性を排
除できます。「クラスタが複製する設定の更新」を参照してください。
デプロイヤーが管理する更新
実⾏時以外の設定の変更を配布するには、デプロイヤーを使⽤します。クラスタは⼤部分の実⾏時サーチ関連設定
変更を、すべてのクラスタ・メンバーに複製します。たとえば、ユーザーがあるクラスタ・メンバーで保存済み
サーチを作成した場合、その保存済みサーチは他のすべてのクラスタ・メンバーに複製されます。「クラスタが複
製する設定の更新」を参照してください。他の更新情報を配布するには、デプロイヤーが必要です。
デプロイヤーを使⽤する必要がある更新の種類を以下に⽰します。
新しいまたはアップグレードされた App。
直接編集した設定ファイル。
サーチに関連していない更新。indexes.conf や
inputs.conf
36
などの更新は、たとえ CLI や Splunk Web で編
集された場合でも、⾃動的には複製されません。
注意： デプロイヤーは設定の更新の配布にのみ使⽤します。サーチヘッド・クラスタの初期設定やメンバーが動
作している Splunk Enterprise インスタンス・バージョンのアップグレードには利⽤できません。
デプロイヤーの設定
注意： ここで説明している作業は、「サーチヘッド・クラスタのデプロイ」で説明しているサーチヘッド・クラ
スタのデプロイ⼿順に統合されました。サーチヘッド・クラスタの初期デプロイ時にデプロイヤーを設定した場
合、このセクションをスキップしてください。
デプロイヤーにするインスタンスの選択
サーチヘッド・クラスタには 1 台のデプロイヤーが必要です。デプロイヤーは、サーチヘッド・クラスタ外で動
作する Splunk Enterprise インスタンスでなければなりません。
Splunk Enterprise 環境の特定のコンポーネントに応じて、デプロイ・サーバーやインデクサー・クラスタのマス
ター・ノードなどの、他の役割も果たしている既存の Splunk Enterprise インスタンスをデプロイヤーにするこ
ともできます。そうでない場合は、専⽤のインスタンスでそれを実⾏します。「デプロイヤーの要件」を参照して
ください。
デプロイヤーの秘密鍵の設定
サーチヘッド・クラスタのメンバーが秘密鍵を使⽤している場合、デプロイヤーにも同じ鍵を設定する必要があり
ます。デプロイヤーはこの鍵を使って、クラスタ・メンバーとの通信の認証を⾏います。鍵を設定するには、デプ
ロイヤーの server.conf ファイルの [general] または [shclustering] スタンザに、pass4SymmKey 属性を指定します。
例：
[shclustering]
pass4SymmKey = yoursecretkey
鍵は、すべてのクラスタ・メンバーおよびデプロイヤーに対して同じでなければなりません。クラスタ・メンバー
への鍵の設定は、初期化時に⾏えます。
鍵を有効にするには、インスタンスを再起動する必要があります。
注意： クラスタ・メンバーとデプロイヤーの pass4SymmKey の値が異なっている場合 (たとえば、メンバーにこの値
を設定したが、デプロイヤーには設定しなかった)、デプロイヤーが設定バンドルを配布しようとするとエラー・
メッセージが表⽰されます。以下のようなメッセージが表⽰されます。
Error while deploying apps to first member: ConfDeploymentException: Error while fetching apps baseline on
target=https://testitls1l:8089: Non-200/201 status_code=401; {"messages":[{"type":"WARN","text":"call not properly
authenticated"}]}
クラスタ・メンバーへのデプロイヤーの指定
各クラスタ・メンバーはデプロイヤーの場所を知る必要があります。メンバーの初期化時にデプロイヤーの場所を
指定することをお勧めします。「サーチヘッド・クラスタのデプロイ」を参照してください。
初期化時にデプロイヤーの場所を設定しなかった場合は、デプロイヤーを使⽤する前に各メンバーの
ファイルにその場所を追加する必要があります。
server.conf
[shclustering]
conf_deploy_fetch_url = <URL>:<management_port>
conf_deploy_fetch_url
属性には、デプロイヤー・インスタンスの URL と管理⽤ポートを指定します。
後ほどクラスタに新しいメンバーを追加する場合、それをクラスタに追加する前に conf_deploy_fetch_url を設定す
る必要があります。そうすることによって、そのメンバーは即座にデプロイヤーと通信して、最新の設定バンドル
を⼊⼿できます。
設定バンドルの内容
設定バンドルは、デプロイヤーがクラスタ・メンバーに配布する⼀連のファイルです。これには、App や他の設
定ファイル・グループを含めることができます。内容は⾃分が決定します。設定バンドルのファイルは、デプロイ
ヤーの専⽤の場所に配置します。
デプロイヤーは設定バンドルを各 App ごとに 1 つ、⼀連の TAR 書庫としてメンバーに配布します。
警告： ⾮常に⼤きな TAR 書庫 (>200 MB) を配布しようとすると、各種タイムアウトにより操作が失敗すること
があります。可能な場合は TAR 書庫の App の⼀部の内容を削除してから、再試⾏してください。
デプロイヤー上の場所
デプロイヤー上で、設定バンドルは $SPLUNK_HOME/etc/shcluster ディレクトリに保管します。このディレクトリ下の
⼀連のファイルが設定バンドルを構成しています。
37
ディレクトリの構造を以下に⽰します。
$SPLUNK_HOME/etc/shcluster/
apps/
<app-name>/
<app-name>/
...
users/
以下の事項に注意してください。
各 App は、/apps 下の独⾃のサブディレクトリに保管します。App は TAR を解凍しておく必要がありま
す。
ファイルをユーザーに配布するには、メンバー上に保管しようと考えている、/users のサブディレクトリ下
にファイルを保管します。
デプロイヤーは、コンテンツに最低 1 つの設定ファイルが含まれている限り、/shcluster/users 下にコンテ
ンツを配布します。たとえば、⼀部の user サブディレクトリ下にプライベートなルックアップ・テーブル
やビューを保管した場合、/shcluster/users 下に 1 つ以上の設定ファイルも存在している場合にのみデプロ
イヤーはそれらを配布します。
default および local サブディレクトリに保管されているすべてのファイルが、メンバーの default サブディ
レクトリにまとめられます。このことは、app および user サブディレクトリにもあてはまります。「クラ
スタ・メンバーの場所」を参照してください。
設定バンドルには、以前に配布したすべての App、および新しい App が含まれている必要があります。バ
ンドルから App を削除すると、次回にバンドルを配布する際に、クラスタ・メンバーからその App が削除
されます。
クラスタ・メンバー上の App を更新するには、設定バンドルに更新したバージョンの App を保管します。
以前に配布した App を削除するには、設定バンドルからそれを削除します。次にバンドルを配布した時
に、各メンバーのファイル・システムからそれが削除されます。
shcluster ディレクトリ下のサブディレクトリの内容のみが配布されます。shcluster ディレクトリ直下にある
単独のファイルは配布されません。たとえば、ファイル /shcluster/file1 が配布されることはありません。
単独のファイルをデプロイするには、/apps 下に新しい App ディレクトリを作成し、その local サブディレ
クトリにファイルを保管します。たとえば、$SPLUNK_HOME/etc/shcluster/newapp/local 下に file1 を保管しま
す。
デプロイヤーがバンドルを配布する際に、前回の配布から変更されたすべての App のすべてのコンテンツが配布
されます。App が変更されていない場合、デプロイヤーはそれの再配布を⾏いません。
警告： 設定バンドル内にクラスタ・メンバー上のデフォルト App と同名の App がある場合、メンバー上の App
はそれで上書きされてしまいます。たとえば、設定バンドル内に「search」App を作成した場合、Splunk
Enterprise に同梱されているデフォルトのサーチ App が上書きされます。このような事態を回避することをお勧
めします。
注意： shcluster の場所は、クラスタ・メンバーに配布したいファイルのみを対象にしています。デプロイヤーが
⾃⼰の設定⽤に、そのディレクトリ内のファイルを使⽤することはありません。
クラスタ・メンバーの場所
クラスタ・メンバー上で、デプロイされた App やファイルは
下に保管されます。
$SPLUNK_HOME/etc/apps
および
$SPLUNK_HOME/etc/users
重要： ファイルがメンバーのローカル App ディレクトリ $SPLUNK_HOME/etc/apps/<app_name>/local に配布されること
はありません。代わりに、設定バンドル内のローカルおよびデフォルト設定の両⽅が、メンバーのデフォルト
App ディレクトリ $SPLUNK_HOME/etc/apps/<app_name>/default に配布されます。こうすることによって、配布される
設定により、メンバー上のローカルまたは複製されたサーチ実⾏時の設定が上書きされることを回避できます。そ
うしないと、たとえば App のアップグレードによりサーチ実⾏時の変更が消去されてしまいます。
同様に、ユーザー・ファイルはメンバーのデフォルト・ユーザー・ディレクトリに配布されます。ローカル・ユー
ザー・ディレクトリではありません。たとえ
ば、$SPLUNK_HOME/etc/shcluster/users/admin/search/local/savedsearches.conf などのユーザー・ファイルをデプロイ
ヤーに保管して、それをメンバーに配布した場合、それは各メンバーの
$SPLUNK_HOME/etc/users/admin/search/default/savedsearches.conf に保管されます。
設定バンドルの配布前に⾏われるステージング・プロセスで、デプロイヤーは設定バンドルをステージング・エリ
アにコピーして、そこで /shcluster/apps/<appname>/local 内のファイルのすべての設定
を、/shcluster/apps/<appname>/default 内のファイルと結合します。local ディレクトリの設定が、対応する default
ディレクトリの設定に優先します。たとえば、/newapp/local/inputs.conf ファイルがある場合、デプロイヤーはそ
のファイルの設定を取って、それを /newapp/default/inputs.conf 内の設定に結合します。ある属性が両⽅で定義さ
れている場合、結合されたファイルには local ディレクトリの定義が保持されます。デプロイヤーは、結合された
デフォルト・ファイルのみを配布します。
設定バンドルの配布
設定バンドルをクラスタ・メンバーに配布するには：
1. App とその他の設定変更を、デプロイヤーの
shcluster/
2. App の TAR を解凍します。
38
下のサブディレクトリに保管します。
3. デプロイヤーで
splunk apply shcluster-bundle
コマンドを実⾏します。
splunk apply shcluster-bundle -target <URI>:<management_port> -auth <username>:<password>
以下の事項に注意してください。
パラメータには、クラスタのメンバーの URI と管理⽤ポートを指定します。たとえ
ば、https://10.0.1.14:8089 のように指定します。クラスタ・メンバーを 1 つのみ指定しますが、デプロイ
ヤーはすべてのメンバーに配布します。このパラメータは必須です。
-auth パラメータには、デプロイヤーの資格情報を指定します。
-target
splunk apply shcluster-bundle
に対して、デプロイヤーは以下のメッセージを表⽰します。
Warning: Depending on the configuration changes being pushed, this command
might initiate a rolling-restart of the cluster members. Please refer to the
documentation for the details.
Do you wish to continue? [y/n]:
これに対して「y」と回答すると、コマンドが実⾏されます。デプロイヤーは、設定バンドルをそのファイル・シ
ステム内の別の場所 ($SPLUNK_HOME/var/run/splunk/deploy) で前処理し、それを各クラスタ・メンバーに配布しま
す。⼀般的に設定バンドルは、各 App に 1 つずつ、複数の TAR 書庫で構成されています。
次に各クラスタ・メンバーは、バンドル内に含まれている変更をローカルに適⽤します。ローリング再起動が必要
と判断された場合、すべてのメンバーが再起動されるまで、⼀度に約 10% のメンバーが順次再起動されていきま
す。
ローリング再起動時には、キャプテンも含めたすべてのメンバーが再起動されます。キャプテンの再起動により選
出プロセスが開始され、新しいキャプテンが選出されます。最後のメンバーの再起動が完了した後、クラスタが安
定化するまで約 60 秒ほどかかります。それまでの間は、エラー・メッセージが表⽰されることもあります。それ
らのメッセージは無視しても構いません。60 秒経過したら表⽰されなくなるはずです。ローリング再起動プロセ
スの詳細は、「サーチヘッド・クラスタの再起動」を参照してください。
再起動の契機となる設定変更については、$SPLUNK_HOME/etc/system/default/app.conf を参照してください。これに
は、変更時に再起動されない設定ファイルの⼀覧が記載されています。その他の設定を変更した場合は、再起動が
⾏われます。
複数クラスタへの配布
デプロイヤーは同じ設定バンドルを、サービスを提供しているすべてのクラスタ・メンバーに配布します。そのた
め、複数のサーチヘッド・クラスタがある場合、それらのクラスタが完全に同じ設定、App などを利⽤している
場合にのみ、それらのクラスタに対して同じデプロイヤーを使⽤することができます。
クラスタで異なる設定が必要になる可能性がある場合は、クラスタごとに個別のデプロイヤーを設置してくださ
い。
サーチヘッド・クラスタリングの管理
クラスタ・メンバーの追加
クラスタに追加する可能性があるメンバーは、以下のようなカテゴリに分類できます。
新規メンバー： この場合、新しいメンバーを追加して、クラスタを拡張します。
以前にクラスタから削除したメンバー： この場合、splunk remove コマンドを使ってクラスタから離脱させ
たメンバーを、再度追加することになります。
クラスタから削除処理を⾏わずに離脱したメンバー： たとえば、インスタンスが予期せずにシャットダウ
ンされた場合などが、この状況に該当します。
ここでは、これらのカテゴリを個別に取り上げていきます。また、詳細な⼿順の参照先も記載しています。
新規メンバーの追加
これらの⼿順は、以前にクラスタに参加したことがない Splunk Enterprise インスタンスを対象にしています。
重要： 新しくインストールしたインスタンスを常に使⽤することをお勧めします。
新しくインストールしたインスタンスの追加
以前にサーチヘッドとして機能したことがない、新たにインストールした Splunk Enterprise インスタンスを追
加するには：
1. インスタンスを初期化します。「インスタンスの初期化」を参照してください。
2. クラスタにインスタンスを追加します。「インスタンスの追加」を参照してください。
既存のインスタンスの追加
既存の Splunk Enterprise インスタンスを追加するには：
39
1. インスタンスが以前に他のサーチヘッド・クラスタのメンバーであった場合、このクラスタにそれを追加する前
に、そのクラスタからメンバーを削除して無効にしてください。「クラスタ・メンバーの削除」を参照してくださ
い。
2. インスタンスをクリーニングして、クラスタでの動作に影響する可能性がある既存の設定を削除します。「イン
スタンスのクリーニング」を参照してください。
3. インスタンスを初期化します。「インスタンスの初期化」を参照してください。
4. クラスタにインスタンスを追加します。「インスタンスの追加」を参照してください。
以前にクラスタから削除したメンバーの追加
以前にこのクラスタのメンバーだったけれども、splunk remove shcluster-member コマンドを使ってクラスタから削
除された Splunk Enterprise インスタンス⽤の⼿順です。「クラスタ・メンバーの削除」を参照してください。
削除されたメンバーの追加
削除されたメンバーを追加するには：
1. インスタンスをクリーニングして、クラスタでの動作に影響する可能性がある既存の設定を削除します。「イン
スタンスのクリーニング」を参照してください。
2. クラスタにインスタンスを追加します。「インスタンスの追加」
以前にクラスタから削除されて無効にされたメンバーの追加
以前にクラスタから削除されて無効にされたメンバーを追加するには：
1. インスタンスをクリーニングして、クラスタでの動作に影響する可能性がある既存の設定を削除します。「イン
スタンスのクリーニング」を参照してください。
2. インスタンスを初期化します。「インスタンスの初期化」を参照してください。
3. クラスタにインスタンスを追加します。「インスタンスの追加」
クラスタから削除処理を⾏わずに離脱したメンバーの追加
クラスタから明⽰的に削除せずに離脱したメンバーの場合：
1. splunk
start
コマンドでインスタンスを開始します。
2. メンバーの停⽌期間によっては、現在の設定セットをダウンロードするために
必要なこともあります。
splunk resync
コマンドの実⾏が
コマンドの詳細、および障害が発⽣したメンバーへの対処に関する他の問題点については、「クラス
タ・メンバー障害への対処」を参照してください。
splunk resync
このカテゴリに該当するメンバーの⼀般的な理由は、クラスタ・メンバーの⼀時的な障害によるものです。
詳細な⼿順
ここでは、クラスタ・メンバーを追加するための詳細な⼿順を説明していきます。 お客様の環境によっては、こ
れらの⼿順の⼀部しか必要ないこともあります。このトピックの各⼿順を参考に、ご⾃分の環境に必要な作業を判
断してください。
インスタンスのクリーニング
注意： デフォルトの設定のみを使⽤する新しいインスタンスを追加する場合、この⼿順は必要ありません。
クラスタに既存のインスタンスを追加する場合は、まずそのインスタンスを停⽌して、splunk
を実⾏する必要があります。
clean all
コマンド
splunk stop
splunk clean all
splunk start
コマンドは、すべてのクラスタ・メンバー間で必要な同⼀の設定や App の維持を妨害する可能性
がある、設定の更新を削除します。server.conf 内の [shclustering] スタンザ下の既存の設定は削除されません。
splunk clean all
警告： このステップは、インスタンス上でもっとも以前に⾏われた設定を削除します。
すべてのメンバー間で共有する必要がある設定については、「サーチヘッド・クラスタへの設定変更の配布⽅法」
を参照してください。
splunk clean
コマンドの詳細は、CLI のヘルプを参照してください。
40
splunk help clean
インスタンスの初期化
クラスタに新規のメンバーを追加する場合、追加前にそれを初期化する必要があります。
splunk init shcluster-config -auth <username>:<password> -mgmt_uri <URI>:<management_port> -replication_port
<replication_port> -replication_factor <n> -conf_deploy_fetch_url <URL>:<management_port> -secret security_key
splunk restart
以下の事項に注意してください。
コマンドの詳細と各種パラメータの意味については、「サーチヘッド・クラス
タのデプロイ」を参照してください。
conf_deploy_fetch_url パラメータには、デプロイヤー・インスタンスの URL と管理⽤ポートを指定します。
既存のクラスタに新たなメンバーを追加する際に、そのメンバーがデプロイヤーに連絡して最新の設定バン
ドルを⼊⼿できるようにするために設定する必要があります。「デプロイヤーを使った App と設定の更新
の配布」を参照してください。
splunk init shcluster-config
このステップは、新しいメンバーの場合にのみ⾏います。クラスタに再参加するメンバーでは実⾏しないでくださ
い。
インスタンスの追加
最後にインスタンスをクラスタに追加します。新しいメンバーまたは現在のクラスタのメンバーから、splunk
shcluster-member コマンドを実⾏できます。どこから実⾏するかによって、必要なパラメータも異なります。
add
新しいメンバー上で splunk add コマンドを実⾏する場合は、以下のようにコマンドを使⽤します。
splunk add shcluster-member -current_member_uri <URI>:<management_port>
以下の事項に注意してください。
は、このノードを参加させるクラスタの任意のメンバーの管理⽤ URI です。このパラ
メータにより、新しいノードがクラスタと通信できるようになります。
current_member_uri
現在のクラスタ・メンバー上で splunk add コマンドを実⾏する場合は、以下のようにコマンドを使⽤し
ます。
splunk add shcluster-member -new_member_uri <URI>:<management_port>
以下の事項に注意してください。
は、クラスタに追加しようとしている新しいメンバーの管理⽤ URI です。このパラメータ
は、メンバーの初期化時に指定した -mgmt_uri の値と同⼀にする必要があります。
new_member_uri
追加後の作業
メンバーをクラスタに参加または再参加させたら、すべての複製/配布された設定の更新情報が適⽤されます。
追加されたメンバーはキャプテンと通信して、複製された設定の TAR 書庫をダウンロードします。
また、デプロイヤーと通信して設定バンドルを受け取ります。
「サーチヘッド・クラスタへの設定変更の配布⽅法」を参照してください。
クラスタ・メンバーの削除
クラスタからメンバーを削除するには、任意のクラスタ・メンバー上から
を実⾏します。
splunk remove shcluster-member
コマンド
重要： クラスタからメンバーを削除するには、ここに記載している⼿順を使⽤する必要があります。単純にメン
バーを停⽌しないでください。
後ほどメンバーをクラスタに再参加させるには、「以前にクラスタから削除したメンバーの追加」を参照してくだ
さい。実際の⼿順は、クラスタからメンバーを単に削除したのか、削除した後メンバーを無効にしたのかによって
異なります。
メンバーの削除
警告： メンバーをクラスタから削除するまで、メンバーを停⽌しないでください。
1. メンバーを削除します。
41
削除するメンバー上で splunk remove コマンドを実⾏する場合は、以下のように指定します。
splunk remove shcluster-member
削除するメンバー以外のメンバー上で splunk remove コマンドを実⾏する場合は、以下のように指定します。
splunk remove shcluster-member -mgmt_uri <URI>:<management_port>
以下の事項に注意してください。
mgmt_uri
は、クラスタから削除するメンバーの管理⽤ URI です。
2. メンバーを停⽌します。
メンバーを削除したら、クラスタ内の設定が更新されるまで 2 分ほど待った後、インスタンスを停⽌します。
splunk stop
インスタンスを停⽌することで、キャプテン上に削除したメンバーに関するエラー・メッセージが表⽰されなくな
ります。
メンバーの無効化
他の⽬的で使⽤するためにインスタンスを維持する場合は、次にメンバーを無効化する必要があります。
splunk disable shcluster-config
このコマンドは、サーチヘッド・クラスタリング機能を完全に無効化するものです。
重要： メンバーの無効化は、splunk
い。
remove shcluster-member
を使ってメンバーを削除した後にのみ⾏ってくださ
アドホック・サーチのみを実⾏するようにクラスタ・メンバーを設定
⼀般的にクラスタ内のサーチヘッドは、ユーザーからのアドホック・サーチヘッド・リクエストとキャプテンから
割り当てられたスケジュール済みサーチの両⽅を処理します。あるクラスタ・メンバーの処理をアドホック・サー
チ・リクエストのみに制限することができます。メンバーをアドホック・サーチ専⽤にすると、それにスケジュー
ル済みサーチは割り当てられません。
アドホック・サーチ専⽤に指定するには、2 種類の⽅法があります。
特定のメンバーを、常時アドホック・サーチのみを実⾏するように指定する。
あるメンバーがキャプテンになっている間は、アドホック・サーチのみを実⾏するように指定する。
注意： アドホック・サーチのみを実⾏するようにメンバーを設定できますが、スケジュール済みサーチのみを実
⾏するようには設定できません。任意のクラスタ・メンバーが常にアドホック・サーチを実⾏できます。また、さ
まざまな⼿段でユーザーによるサーチヘッドへのアクセスを防⽌することも可能です。
アドホック・サーチのみを実⾏するようにメンバーを設定
デプロイ環境特有の要件によっては、特定のサーチヘッドをアドホック・サーチ専⽤にしたいこともあるでしょ
う。アドホック専⽤のサーチヘッドが、スケジュール済みサーチを実⾏することはありません。アドホック専⽤の
サーチヘッドを指定するには、そのメンバーの server.conf ファイルに adhoc_searchhead 属性を設定します。
[shclustering]
adhoc_searchhead = true
変更内容を有効にするには、インスタンスを再起動する必要があります。
アドホック・サーチのみを実⾏するようにキャプテンを設定
キャプテン・メンバーをアドホック専⽤のサーチヘッドとして指定できます。そうすることによって、キャプテン
の役割を果たしている間、そのメンバーでスケジュール済みサーチは実⾏されません。またキャプテンは、クラス
タの活動を管理することに専念できます。キャプテンの役割が他のメンバーに引き継がれた場合、前のキャプテン
ではスケジュール済みサーチの実⾏が再開され、新しいキャプテンはアドホック・サーチのみを実⾏するようにな
ります。
重要： どのメンバーがキャプテンの役割を引き継いでも同じ動作が⾏われるように、この変更はすべてのクラス
タ・メンバーに対して⾏う必要があります。
キャプテンをアドホック専⽤のサーチヘッドにするには、各メンバーの
属性を設定します。
42
server.conf
に
captain_is_adhoc_searchhead
[shclustering]
captain_is_adhoc_searchhead = true
変更内容を有効にするには、各メンバーを再起動する必要があります。⼤部分のサーチヘッド・クラスタリング関
連の設定変更の場合と違い、メンバーの再起動には splunk rolling-restart コマンドを使⽤できます。「サーチ
ヘッド・クラスタの再起動」を参照してください。
サーチヘッド・クラスタリング設定の概要については、「サーチヘッド・クラスタの設定」を参照してください。
サーチヘッド・クラスタのステータスの表⽰
サーチヘッド・クラスタのステータス情報を提供するさまざまな CLI コマンドが存在しています。
クラスタ・ステータスの表⽰
サーチヘッド・クラスタの総合的なステータスを確認するには、いずれかのメンバーから以下のコマンドを実⾏し
ます。
splunk show shcluster-status -auth <username>:<password>
このコマンドは、キャプテンとクラスタ・メンバーに関する基本的な情報を返します。各メンバーのステータス
up (稼働中)、down (停⽌)、detention (遅延)、restarting (再起動中) が表⽰されます。
注意： クラスタ・メンバーがディスク・スペースを使い切ってしまった場合、遅延状態になります。遅延状態の
メンバーには、スケジュール済みサーチまたは過去のサーチ結果のコピーは割り当てられません。修復するには、
そのインスタンスで利⽤できるディスク・スペースを増やす必要があります。
メンバー設定の表⽰
クラスタ・メンバーの設定を確認するには、そのメンバー上で以下のコマンドを実⾏します。
splunk list shcluster-config -auth <username>:<password>
または、他のメンバーから以下のコマンドを発⾏することもできます。
splunk list shcluster-config -uri <URI>:<management_port> -auth <username>:<password>
以下の事項に注意してください。
-uri
パラメータには、設定を確認するメンバーの URI と管理⽤ポートを指定します。
クラスタ・メンバーの表⽰
すべてのクラスタ・メンバーのリストを取得するには、任意のメンバーから以下のコマンドを実⾏します。
splunk list shcluster-members -auth <username>:<password>
このコマンドは、クラスタのすべてのメンバーとその設定を返します。
メンバー情報の⼀覧表⽰
あるメンバーに関する情報を表⽰するには、そのメンバー上で以下のコマンドを実⾏します。
splunk list shcluster-member-info -auth <username>:<password>
または、他のメンバーから以下のコマンドを発⾏することもできます。
splunk list shcluster-member-info -uri <URI>:<management_port> -auth <username>:<password>
以下の事項に注意してください。
-uri
パラメータには、設定を表⽰するメンバーの URI と管理⽤ポートを指定します。
過去のサーチ結果の表⽰
クラスタに保管されている⼀連の過去のサーチ結果を表⽰するには、キャプテン上で以下のコマンドを実⾏しま
す。
splunk list shcluster-artifacts
特定のメンバーに保管されている⼀連の過去のサーチ結果を表⽰するには、そのメンバー上で以下のコマンドを実
43
⾏します。
splunk list shcluster-member-artifacts
スケジューラ・ジョブの表⽰
⼀連の過去のスケジューラ・ジョブを表⽰するには、キャプテン上で以下のコマンドを実⾏します。
splunk list shcluster-scheduler-jobs -auth <username>:<password>
サーチヘッド・クラスタ・メンバー障害への対処
⼀般的にはメンバーに障害が発⽣しても、クラスタがその問題に対処して、引き続き通常通りに機能します。
障害が発⽣したメンバーが回復して再起動し、クラスタに再度参加した場合、⼀般的にはその後の処理が⾃動的に
⾏われます。ただし、ユーザーの介⼊が必要な場合もあります。
メンバーの障害発⽣時
サーチヘッド・クラスタのメンバーに何らかの理由で障害が発⽣し、クラスタから離脱した場合、⼀般的にクラス
タは中断することなく機能し続けることができます。
クラスタの特徴である⾼可⽤性により、過半数 (51%) のメンバーが動作しており、メンバー数が複製データ
保持数以上である限り、クラスタは継続的に機能することができます。
たとえば、15 台構成のクラスタで複製データ保持数が 3 の場合、8 台以上のメンバーが残っていればクラ
スタは機能し続けることができます。15 台のメンバー構成で複製データ保持数が 10 のクラスタがある場
合、クラスタが機能を維持するには 10 台以上が正常に動作している必要があります。
過半数のメンバーに障害が発⽣、または停⽌した場合、クラスタでは新たなキャプテンを選出できなくなる
ためクラスタ全体が機能を停⽌します。「サーチヘッド・クラスタのキャプテン」を参照してください。
障害が発⽣したメンバーが保有していたすべての過去のサーチ結果は、他のサーチヘッドから利⽤すること
ができます (ただし、障害が発⽣したメンバー数が複製データ保持数未満の場合)。障害が発⽣したメンバー
数が複製データ保持数以上になった場合、⼀部の過去のサーチ結果が残りのメンバーでは利⽤できなくなり
ます。
障害が発⽣したメンバーがキャプテンだった場合、残りのメンバーから新たなキャプテンが選出されます。
メンバーは設定を共有しているため、新たなキャプテンは即座に完全に機能します。
クラスタの前⾯にロード・バランサーを設置している場合、ロード・バランサーが障害発⽣ノードのユー
ザーを他の利⽤可能なサーチヘッドに⾃動的に誘導します。
メンバーがクラスタに再参加した場合
障害が発⽣したメンバーは、そのインスタンスが正常に再起動できた場合⾃動的にクラスタに再参加します。この
ような場合、他のクラスタ・メンバーと⼀致するように即座に設定の更新が必要になります。このメンバーは、2
種類の設定を更新する必要があります。
キャプテンから取得する複製された変更。
デプロイヤーから配布される変更。
クラスタ・メンバー間での設定の共有の仕組みについては、「サーチヘッド・クラスタへの設定変更の配布⽅法」
を参照してください。
複製された変更の更新
メンバーがクラスタに再参加したら、キャプテンと通信してそれまでに複製された変更セットを要求します。その
次に⾏われる処理は、関連する変更履歴の⼀部が変更ジャーナルから消去されたかどうかによって異なります。
変更履歴が何もシステムから消去されていない場合 (それまでの変更が消去制限を超えていない)、メンバー
はキャプテンから変更情報をダウンロードして、それをオフラインになる前に使⽤していた設定に適⽤しま
す。
それまでの変更の⼀部が消去制限を超えてた場合、いくつかの変更履歴はすでに削除されているため、完全
な設定を含んだ TAR 書庫をダウンロードして、それで既存の設定を上書きする必要があります。
消去制限
設定変更履歴の消去制限は、さまざまな属性で決定されます。これらの属性は、server.conf 内の
タンザにあります。これらの属性の中で重要なものを以下に⽰します。
conf_replication_purge.eligibile_count。デフォルトは
conf_replication_purge.eligibile_age。デフォルトは
20,000 件の変更です。
1 ⽇です。
server.conf ファイルを参照してください。
更新処理の仕組み
44
[shclustering]
ス
クラスタへの参加時に、メンバーはそれまでに複製された⼀連の変更情報を適⽤しようと試みます。変更情報が消
去制限を超えて⼀部の変更履歴がすでにクラスタから削除されている場合、メンバーの UI に以下のようなバ
ナー・メッセージが表⽰されます。
Error pulling configurations from the search head cluster captain; consider performing a destructive configuration
resync on this search head cluster member.
このメッセージが表⽰された場合、メンバーは設定変更の差分情報で設定を更新できないため、設定情報全体の
TAR 書庫を適⽤しなければならないことを表しています。この処理は⾃動的には⾏われません。ユーザーが操作
する必要があります。
TAR 書庫をダウンロードして適⽤する処理を開始するには、メンバー上で以下の CLI コマンドを実⾏する必要が
あります。
splunk resync shcluster-replicated-config
警告： このコマンドにより、メンバー上のサーチ関連設定全体が上書きされますが、ローカルで⾏われた変更は
失われてしまいます。
配布された変更の更新
クラスタにメンバーが再参加した場合、⾃動的にデプロイヤーと通信して、最新の設定バンドルを⼊⼿します。次
にメンバーは、前回バンドルをダウンロードした後に⾏われた変更や追加などを適⽤します。
「デプロイヤーを使った App と設定の更新の配布」を参照してください。
サーチヘッド・クラスタの再起動
クラスタ全体を再起動するには、splunk rolling-restart コマンドを使⽤します。このコマンドは、再起動処理中も
クラスタが引き続き機能できるように、すべてのクラスタ・メンバーを段階的に再起動します。
デプロイヤーは、メンバーへの設定バンドルの配布後に、必要に応じてローリング (段階的) 再起動を実⾏しま
す。このプロセスの詳細は、「設定バンドルの配布」を参照してください。
警告： たいていの場合、server.conf の [shcluster] スタンザで設定を変更すると、すべてのメンバー間で同⼀の設
定を維持するためにすべてのメンバーをほぼ同時に再起動する必要があります。この理由から、そのような設定変
更を⾏った後のメンバーの再起動に splunk rolling-restart コマンドは使⽤しないでください
(captain_is_adhoc_searchhead 属性を設定する場合を除く)。「サーチヘッド・クラスタの設定」を参照してくださ
い。
ローリング再起動の開始
splunk rolling-restart
コマンドをキャプテンから実⾏します。
splunk rolling-restart shcluster-members
ローリング再起動の仕組み
ここでは、ローリング (段階的または順次) 再起動の仕組みを説明します。キャプテンは、⼀度にメンバーの約
10% (デフォルト) に対して、再起動メッセージを発⾏します。これらのメンバーが再起動され、キャプテンとの
通信が回復すると、別の 10 % のメンバーに再起動メッセージが発⾏されます。このような処理が、キャプテンも
含めてすべてのメンバーが再起動されるまで繰り返されます。
注意： クラスタ内のメンバー数が 10 未満の場合は、1 回に 1 台のメンバーが再起動されます。
キャプテンは、最後に再起動されます。キャプテンの再起動により選出プロセスが開始され、新しいキャプテンが
選出されます。
すべてのメンバーの再起動が完了した後、クラスタが安定化するまで約 60 秒ほどかかります。それまでの間は、
エラー・メッセージが表⽰されることもあります。それらのメッセージは無視しても構いません。60 秒ほどで表
⽰されなくなるはずです。
注意： 段階的な再起動中は、すべてのメンバーがすべてのナレッジ・オブジェクトを利⽤できることは保証され
ません。
同時に再起動するメンバー数の設定
デフォルトで、キャプテンは 1 回に 10% のメンバーに対して再起動コマンドを発⾏します。ただし、この割合は
server.conf の [shcluster] スタンザにある percent_peers_to_restart 属性で設定することができます。また、この属
性を CLI の splunk edit shcluster-config コマンドで設定することもできます。たとえば、1 回にピアの 20% を再
起動するように動作を変更するには、以下のコマンドを使⽤します。
splunk edit shcluster-config -percent_peers_to_restart 20
45
警告： 20% を超える値は設定しないでください。そうしないと、キャプテン選出プロセスで問題が発⽣する可能
性があります。
属性を変更しても、実際の再起動を開始するためには
⾏する必要があります。
percent_peers_to_restart
splunk rolling-restart
コマンドを実
再起動プロセスのモニター
ローリング再起動の進捗状況を確認するには、いずれかのメンバーから以下のコマンドを実⾏します。
splunk show shcluster-status -auth <username>:<password>
このコマンドは、ローリング再起動が処理中 (1) かまたはそうではない (0) かを⽰す
ます。
rolling_restart_flag
を返し
注意： このコマンドは再起動の最終プロセス中、つまりこの情報を追跡しているキャプテンが再起動中の場合は
機能しません。その間は、「In handler 'shclusterstatus': Node is not captain....」から始まるエラー・メッセー
ジが表⽰されます。再起動処理が完了するまで 60 秒ほど待ってから、コマンドを再実⾏してください。
サーチヘッド・クラスタリングのトラブルシューティ
ング
デプロイの問題
新しいメンバーの追加時にクラッシュ
クラスタにメンバーを追加した時にクラッシュする場合、そのインスタンスが以前に他のクラスタのメンバーだっ
たかどうかを確認します。そうだった場合、前のクラスタからそのインスタンスが正しく削除されていない可能性
があります。
クラスタにメンバーを追加する際には、常に新しいインスタンスを使⽤することをお勧めします。インスタンスを
再利⽤する場合は、「新しいメンバーの追加」の説明に従う必要があります。
実⾏時の検討事項
クラスタ・メンバーの管理による遅延
キャプテンと他のクラスタ・メンバー間の管理と調整により、最⾼ 1.5 分ほどの遅延が発⽣することがありま
す。たとえば、サーチ・ジョブの保存時に、Splunk Web が短期間ですがジョブの状態を更新しないことがあり
ます。同様に、キャプテンが削除を完了するまでに数分ほどかかることもあります。
また、新しいキャプテン選出の契機となるイベントが発⽣した場合、選出が完了するまでに 1〜2 分ほどかかりま
す。その間、サーチヘッドではアドホック・ジョブ・リクエストのみを処理できます。
アクティブなアラート数の制限
サーチヘッド・クラスタは、約 5000 件のアクティブで失効していないアラートを処理できます。この制限値を
維持するために、アラートの抑制機能を使⽤するか、またはアラートの保持期間を制限してください。『アラー
ト・マニュアル』を参照してください。
サイト障害によりキャプテンが選出できない可能性
クラスタが 2 つのサイトにまたがっており、過半数のメンバーを持つサイトが停⽌した、または何らかの理由で
アクセスできなくなった場合、クラスタは新しいキャプテンを選出できません。キャプテン選出には過半数のメン
バーの合意が必要ですが、過半数に満たない数のメンバーしか動作していないためです。その間、メンバーが提供
するサービスはアドホック・サーチのみになります。
対処するには、停⽌したサイトを復旧するか、または残りのクラスタ・メンバーを停⽌して、クラスタを再設定し
てください。
サーチヘッドプーリング
サーチヘッドプーリングの概要
この機能は廃⽌予定です。
この機能は、Splunk Enterprise バージョン 6.2 から⾮推奨 (廃⽌予定) となりました。このことは、この機能
はまだ利⽤できますが、将来のバージョンでは削除される可能性があることを意味しています。
代わりに、サーチヘッド・クラスタリングをデプロイすることができます。「サーチヘッド・クラスタリングに
ついて」を参照してください。
⾮推奨で廃⽌予定の機能の⼀覧は、リリースノートの「⾮推奨 (廃⽌予定) の機能」を参照してください。
46
重要： サーチヘッドプーリングは⾼度な機能です。実際に導⼊する前に、Splunk 営業チームにデプロイ⽅法
について問い合わせることをお勧めします。
複数のサーチヘッドが同じ設定とユーザーデータを共有するように指定することができます。このことは、サー
チヘッドプーリング として知られています。複数のサーチヘッドを使⽤する主な理由は、同じデータに対して多
数のユーザーがサーチを実⾏する場合の⽔平スケーリングを容易にすることにあります。サーチヘッドプーリング
では、あるサーチヘッドが利⽤できなくなった場合の影響を低減することもできます。サーチヘッドプーリングを
使った、⼀般的なデプロイ環境の概要を以下の図に⽰します。
設定とユーザーデータを共有するために、プールに⼊れる各サーチヘッド上でサーチヘッドプーリングを有効にし
ます。サーチヘッドプーリングが有効になると、これらのオブジェクトカテゴリがプール内のすべてのサーチヘッ
ド共通のリソースとして利⽤できるようになります。
設定データ -- 保存済みサーチ や他のナレッジオブジェクト の設定を含む設定ファイル 。
サーチ成果物 、特定のサーチ実⾏のレコード。
スケジューラ状態 、プール内の 1 つのサーチヘッドのみが、ある特定のスケジュール済みサーチ を実⾏す
るようにします。
たとえば、1 つのサーチヘッド上でサーチを作成、保存した場合、プール内の他のすべてのサーチヘッドが⾃動的
にそれにアクセスできるようになります。
サーチヘッドプーリングにより、$SPLUNK_HOME/etc/{apps,users} 内のすべてのファイルを共有のために利⽤できるよ
うになります。これには、*.conf ファイル、*.meta ファイル、ビューファイル、サーチスクリプト、ルックアップ
テーブル、およびその他のファイルが含まれます。
導⼊上の主な問題
以下の事項に注意してください。
⼤部分の共有ストレージソリューションは、WAN 経由では正常に機能しません。サーチヘッドプーリング
には待ち時間が短く、秒あたりの実⾏操作数が⾼い共有ストレージが必要なため、WAN を介したサーチ
ヘッドプーリングの導⼊はサポートされていません。
プール内のすべてのサーチヘッドが、同じバージョンの Splunk Enterprise を動作させている必要がありま
す。アップグレードはすべてを同時に⾏ってください。詳細は、『分散デプロイ』マニュアルの「分散デプ
ロイ環境のアップグレード」を参照してください。
サーチヘッドプーリングは、専⽤のサーチヘッドグループの管理を簡素化することを⽬的にしています。⼀
般的には、サーチヘッドの機能も兼務するインデクサーのグループにプールを適⽤しないでください。これ
はサポートされていない設定です。サーチヘッドプーリングは、インデックス作成のパフォーマンスに⼤き
な影響があります。
プール内のサーチヘッドを相互のサーチピアにすることはできません。
サーチヘッドプーリングとナレッジバンドル
47
サーチヘッドがサーチピアに配布する⼀連のデータは、ナレッジバンドル と呼ばれています。詳細は、「サーチ
ヘッドがサーチピアに送信する内容」を参照してください。
デフォルトで、サーチヘッドプール内の 1 つのサーチヘッドのみが、⼀連のサーチピアにナレッジバンドルを送
信します。また、プール内の各サーチヘッドが相互のサーチピアとなっている場合、各⾃がプール内のバンドルに
アクセスできるため、互いにバンドルを送信することはありません。これはバージョン 4.3.2 で導⼊された最適化
⼿法ですが、バージョン 5.0 ではデフォルトの設定になりました。distsearch.conf 内の useSHPBundleReplication
属性で設定を変更することができます。
さらなる最適化⼿段として、共有ストレージ上にナレッジバンドルをマウントすることができます。「マウントバ
ンドルについて」を参照してください。そうすることにより、バンドルをサーチピアに配布する⼿間を省けます。
サーチヘッドプーリングとマウントバンドルの組み合わせ⽅については、「サーチヘッドプーリングでのマウント
バンドルの使⽤」を参照してください。
その他の参考情報
サーチヘッドプーリングのその他の情報については、この章の他のトピックを参照してください。
サーチヘッドプールの作成
ロードバランサーでのサーチヘッドプールの使⽤
その他のプーリング操作
設定変更の管理
デプロイサーバーとサーチヘッドプーリング
設定更新タイミングの選択
Answers
何か質問がありますか？「Splunk Answers」では、Splunk コミュニティに寄せられた、サーチヘッドプーリン
グに関する質問と回答をご覧いただけます。
サーチヘッドプールの作成
サーチヘッドのプールを作成するには、以下の⼿順に従ってください。
1. 各サーチヘッドにアクセスできる、共有ストレージ場所を設定します。
2. 個別のサーチヘッドを設定します。
3. サーチヘッドを停⽌します。
4. 各サーチヘッド上でプーリングを有効にします。
5. ユーザーおよび App ディレクトリを共有ストレージにコピーします。
6. サーチヘッドを再起動します。
詳細なステップは後述しています。
1. 各サーチヘッドにアクセスできる、共有ストレージの場所の設定
プール内の各サーチヘッドが設定と成果物を共有できるように、共有ストレージ経由で共通のファイルセットにア
クセスする必要があります。
*nix プラットフォームの場合： NFS マウントを設定します。
Windows： CIFS (SMB) 共有を設定します。
重要： Splunk ユーザーアカウントには、共有ストレージの場所に対する読み取り/書き込みアクセスが必要で
す。Windows にサーチヘッドをインストールする場合は、共有ストレージへの読み取り/書き込みアクセスを持
つユーザーとしてインストールしてください。ローカルシステム (Local System) ユーザーは、このアクセス権を
保有していません。詳細は、『インストールマニュアル』の「Splunk を実⾏するユーザーアカウントの選択」を
参照してください。
2. 個別のサーチヘッドの設定
a. 各サーチヘッドを個別に設定して、通常の⽅法でサーチピアを指定します。「サーチピアの追加」を参照して
ください。
b. 各サーチヘッドに対して server.conf に⼀意の serverName 属性が設定されていることを確認します。要件の詳
細は、「分散サーバー名の管理」を参照してください。サーチヘッドに⼀意の serverName がない場合は、起動時に
警告が⽣成されます。詳細は、「⼀意の serverName 属性に関する警告」を参照してください。
c. 必要な認証情報を指定します。2 種類の⽅法があります。
各サーチヘッド個別にユーザー認証を指定する。あるサーチヘッド上の有効なユーザーが、プール内の他の
サーチヘッドのユーザーに⾃動的になることはありません。LDAP を使ってユーザー認証を集中管理するこ
とができます。「LDAP によるユーザー認証」を参照してください。
すべてのプールメンバーが使⽤する共有ストレージ上に、共通の認証設定を配置する。認証の変更を⾏った
後は、プールのメンバーを再起動する必要があります。
注意： 個別のプールメンバー上で⾏われた認証の変更は (例：Splunk Web を使⽤)、そのプールのメンバーに対
48
してのみ、共有ストレージ上の任意の設定に優先されます。そのため、共有ストレージ上に共通の設定がすでに存
在している場合、⼀般的には Splunk Web を使って認証の変更は⾏わないようにしてください。
3. サーチヘッドの停⽌
プーリングを有効にする前に、splunkd を停⽌する必要があります。プール内の各サーチヘッドに対して、この操
作を⾏ってください。
4. 各サーチヘッド上でのプーリングの有効化
サーチヘッド上のプーリングを有効にするには、CLI コマンドの splunk pooling enable を使⽤します。このコマン
ドは、server.conf に特定の値を設定します。また共有ストレージ内にサブディレクトリを作成し、Splunk
Enterprise がその内部でファイルを作成、移動できることを検証します。
コマンドの構⽂を以下に⽰します。
splunk pooling enable <path_to_shared_storage> [--debug]
注意：
NFS で、<path_to_shared_storage> は NFS の共有マウントポイントです。
Windows で、<path_to_shared_storage> は CIFS/SMB 共有の UNC パスでなければなりません。
--debug パラメータを指定すると、追加の情報 btool.log ログに記録します。
プール内の各サーチヘッドに対して、このコマンドを実⾏します。
このコマンドは、$SPLUNK_HOME/etc/system/local 内の
ます。
server.conf
の
[pooling]
server.conf
ファイルにある
[pooling]
スタンザ内に値を設定し
スタンザを直接編集することもできます。server.conf の詳細は、ここを参照してくださ
い。
重要： [pooling] スタンザは、$SPLUNK_HOME/etc/system/local/ 直下の server.conf ファイルに配置する必要がありま
す。このことは、ローカルディスクまたは共有ストレージ上の App を介して、[pooling] スタンザをデプロイでき
ないことを意味しています。詳細は、server.conf ファイルを参照してください。
5. ユーザーおよび App ディレクトリの共有ストレージへのコピー
既存のサーチヘッド上の $SPLUNK_HOME/etc/apps および $SPLUNK_HOME/etc/users ディレクトリの内容を、共有ストレー
ジの空の /etc/apps および /etc/users ディレクトリにコピーします。これらのディレクトリはステップ 4 で作成
し、その時に指定した <path_to_shared_storage> 下に存在しています。
たとえば、NFS マウントが
す。
/tmp/nfs
の場合は、以下のパターンに⼀致する App サブディレクトリをコピーしま
$SPLUNK_HOME/etc/apps/*
コピー先
/tmp/nfs/etc/apps
この結果、以下のような⼀連のサブディレクトリが作成されます。
/tmp/nfs/etc/apps/search
/tmp/nfs/etc/apps/launcher
/tmp/nfs/etc/apps/unix
[...]
同様に、ユーザーサブディレクトリをコピーします。
$SPLUNK_HOME/etc/users/*
コピー先
/tmp/nfs/etc/users
重要： App およびユーザーサブディレクトリのサブセットのみをコピーすることもできます。ただし、前述の説
明に従って正しい場所にコピーするようにしてください。
6. サーチヘッドの再起動
コマンドを実⾏したら、splunkd を再起動します。プール内の各サーチヘッドに対して、この
操作を⾏ってください。
splunk pooling enable
49
ロードバランサーでのサーチヘッドプールの使⽤
サーチヘッドの前⾯でロードバランサーを実⾏したい場合もあるでしょう。このようにして、ユーザーは単⼀のイ
ンターフェイスから、特に特定のサーチヘッドを指定せずに、サーチヘッドのプールにアクセスすることができま
す。
ロードバランシングを利⽤するもう 1 つの理由として、あるサーチヘッドが停⽌してもサーチの成果物や結果に
アクセスできるようにすることが挙げられます。通常、RSS およびメールアラートには、サーチの開始元となる
サーチヘッドへのリンクが記載されます。そのサーチヘッドが停⽌した (そしてロードバランシングが使われてな
い) 場合、そのサーチ成果物と結果にはアクセスできなくなります。ただし、ロードバランシングを利⽤していれ
ば、特定のサーチヘッドではなくロードバランサーを参照するようにアラートを設定することができます。
ロードバランサーの設定
ロードバランサーの選択、設定時には、いくつかの注意事項があります。
ロードバランサーは、レイヤー 7 (アプリケーションレベル) の処理を採⽤する必要があります。
ユーザーセッションが「継続的」または「固定」になるようにロードバランサーを設定します。そうするこ
とによって、そのセッション中ユーザーは、単⼀のサーチヘッドが対応することになります。
ロードバランサーへのアラートリンクの⽣成
ロードバランサーへのアラートリンクを⽣成するには、alert_actions.conf を編集する必要があります。
1. サーチヘッドから共有ストレージ内の適切な App ディレクトリに、alert_actions.conf をコピーします。たいて
いの場合、これは /<path_to_shared_storage>/etc/apps/search/local になります。
2. hostname 属性がロードバランサーを指すように編集します。
hostname = <proxy host>:<port>
詳細は『管理マニュアル』の「alert_actions.conf」を参照してください。
これでアラートリンクが個別のサーチヘッドではなく、ロードバランサーを指すようになっているはずです。
その他のプーリング操作
splunk pooling enable
CLI コマンドの他にも、サーチヘッドプーリングの管理に重要なさまざまなコマンドが存在
しています。
splunk pooling validate
splunk pooling disable
splunk pooling display
または splunk pooling disable を実⾏する前に、splunkd を停⽌する必要があります。ただ
し、splunkd の停⽌中または動作中に、splunk pooling validate や splunk pooling display を実⾏することは可能で
す。
splunk pooling enable
各サーチヘッドが共有リソースにアクセスできることの確認
コマンドは、最初にサーチヘッドプーリングを設定する際に、サーチヘッドのアクセスを検
証します。サーチヘッドの共有リソースへのアクセスを再検証する必要がある場合は (NFS 設定を変更した場合な
ど)、CLI コマンドの splunk pooling validate を実⾏することができます。
splunk pooling enable
splunk pooling validate [--debug]
サーチヘッドプーリングを無効にする
以下の CLI コマンドを使って、サーチヘッドプーリングを無効にすることができます。
splunk pooling disable [--debug]
無効にする各サーチヘッド上で、このコマンドを実⾏してください。
重要： splunk pooling disable コマンドを実⾏する前に、splunkd を停⽌する必要があります。このコマンドを実⾏
したら、splunkd を再起動する必要があります。
プーリングステータスの表⽰
CLI コマンドの splunk pooling
認することができます。
display
を使って、サーチヘッド上でプーリングが有効になっているかどうかを確
splunk pooling display
50
以下の例は、プーリングが有効になっているかどうかに応じた、システム応答の変化を表しています。
$ splunk pooling enable /foo/bar
$ splunk pooling display
Search head pooling is enabled with shared storage at: /foo/bar
$ splunk pooling disable
$ splunk pooling display
Search head pooling is disabled
設定変更の管理
重要： サーチヘッド上でプーリングを有効にした後、設定ファイルを直接編集した場合は常にサーチヘッドにそ
の旨を知らせる必要があります。
特に
す。
local
ディレクトリ内の設定ファイルにスタンザを追加した場合は、以下のコマンドを実⾏する必要がありま
splunk btool fix-dangling
注意： Splunk Web や CLI を使って変更した場合は、この作業を実⾏する必要はありません。
デプロイサーバーとサーチヘッドプーリング
サーチヘッドプーリングでは、すべてのサーチヘッドが単⼀の設定セットにアクセスします。そのため、デプロ
イサーバー や Puppet などのサードパーティ製デプロイ管理ツールを使って、複数のサーチヘッドに更新を配布
する必要はありません。ただし、すべての Splunk Enterprise インスタンス間で設定操作を統⼀するために、
サーチヘッドプーリングでデプロイツールを使⽤することもできます。
デプロイサーバーを使ってサーチヘッド設定を管理する場合は、以下の事項に注意してください。
1. いずれかのサーチヘッドをデプロイクライアントとして指名するために、$SPLUNK_HOME/etc/system/local 内に
deploymentclient.conf ファイルを作成して、そのデプロイサーバーを指定します。1 台のサーチヘッドをデプロイ
クライアントと指名するだけで⼗分です。
2. deploymentclient.conf で、repositoryLocation 属性にサーチヘッドの共有ストレージマウントポイントを設定しま
す。また、ローカルに設定した repositoryLocation がダウンロード場所として使⽤されるよう
に、serverRepositoryLocationPolicy=rejectAlways を設定する必要もあります。
3. デプロイサーバー上の
serverclass.conf
で、サーチヘッドクライアントのサーバークラスを定義します。
デプロイサーバーの詳細は、『Splunk Enterprise インスタンスの更新』マニュアルの「デプロイサーバーについ
て」を参照してください。
設定更新タイミングの選択
バージョン 5.0.2 以前では、ストレージからの同期のデフォルト値は、とても頻繁な間隔に設定されていました。
この場合、特に多数のユーザー (数百〜数千⼈) が存在するデプロイ環境では、プールからの設定変更の読み取り
に過度の時間が費やされる可能性があります。
5.0.3 以降では、この頻度のデフォルト設定が減少されました。server.conf では、以下の設定が設定の更新タイミ
ングに影響を与えます。
# 5.0.3 defaults
[pooling]
poll.interval.rebuild = 1m
poll.interval.check = 1m
これらの設定の以前のデフォルト値は、それぞれ 2s と 5s でした。
従来のデフォルト値では、あるサーチヘッド上で⾏われた変更は、7 秒以内に他のサーチヘッド上に反映されま
す。通常は、更新内容をこれだけ短時間に伝搬する必要はありません。この設定値を 1 分に変更することで、共
有ストレージシステムの負荷が⼤幅に減少します。ビジネスニーズに応じて、これらの値をより⻑い間隔に設定す
ることもできます。
サーチヘッドプールのアップグレード
プール内のすべてのサーチヘッドが、同じバージョンの Splunk Enterprise を動作させている必要があります。
アップグレード⼿順については、『分散デプロイマニュアル』の「分散デプロイ環境のアップグレード」を参照し
てください。サーチヘッドプールをアップグレードする前に、この⼿順を⼊念にお読みください。プールが正常に
機能するように、この⼿順に厳密に従う必要があります。
分散サーチの動作
51
分散サーチでの認証の仕組み
分散サーチの処理時にサーチピアが使⽤する認証設定は、管理やローカルサーチリクエストなどのローカルアク
ティビティで使⽤される設定とは異なります。
分散サーチの処理時にサーチピアは、サーチヘッドがサーチリクエストを送信する際にすべてのサーチピア
に配布する、ナレッジバンドル に含まれている設定を使⽤します。これらの設定は、サーチヘッド上で作
成、管理されます。
ローカルアクティビティの実⾏時に、サーチピアはそれ⾃体が作成してローカルに保管した認証設定を使⽤
します。
そのため分散サーチの管理時には、これらの 2 種類の認証を区別することが重要になります。特に、サーチヘッ
ドプーリング またはマウントバンドル を使⽤するシステムを管理する場合、ナレッジバンドルを介して認証設定
がどのように配布されるのかを理解しておく必要があります。
バックグラウンド情報については、以下のような主要概念の記事をご覧ください。
Splunk Enterprise 認証： 『Splunk Enterprise のセキュリティ』マニュアルの「ロールベースのユー
ザーアクセスについて」
マウントバンドル： このマニュアルの「ナレッジバンドルのマウント」
サーチヘッドプーリング： このマニュアルの「サーチヘッドプーリング」
分散サーチの権限の管理
すべての権限設定は、1 つまたは複数の authorize.conf ファイルに保管されます。これには、Splunk Web や CLI
を使った設定も含まれます。サーチヘッドからサーチピアに配布されるのは、これらの authorize.conf ファイルで
す。ナレッジバンドルで、通常これらのファイルは /etc/system/{local,default} または /etc/apps/<appname>/{local,default} に存在しています。
サーチピアはナレッジバンドル内の設定を⾃動的に使⽤するため、通常は正常に処理が⾏われます。ユーザーの
ロールはサーチヘッド上で設定します。サーチヘッドはそれらの設定を、サーチ⾃体の配布時に⾃動的にサーチピ
アに配布します。
ただしサーチヘッドプーリングを使⽤する場合、サーチヘッドとサーチピアすべてが同じ authorize.conf ファイル
セットを使⽤するように注意する必要があります。このために、以下の事項を確認してください。
プール内のすべてのサーチヘッドが同じ
サーチヘッドが使⽤している
ンドルに含まれている。
authorize.conf
authorize.conf
ファイルセットを使⽤している。
ファイルセットが、サーチピアに配布されるようにナレッジバ
このトピックは、サーチヘッドプーリングまたはマウントバンドルを使⽤しているかどうかに基づいて、主な 4
つのシナリオについて説明しています。単純なシナリオから複雑なシナリオへの順番で説明していきます。
4 つのシナリオ
分散サーチの authorize.conf ファイルに対して⾏う必要がある作業は、デプロイ環境がサーチヘッドプーリングを
採⽤しているのか、またはマウントバンドルをサーチしているのかによって異なります。これらの 4 つのシナリ
オを以下に⽰します。
サーチヘッドプーリングなし、マウントバンドルなし
サーチヘッドプーリングなし、マウントバンドルあり
サーチヘッドプーリングあり、マウントバンドルなし
サーチヘッドプーリングあり、マウントバンドルあり
最初の 2 つのシナリオは単純にそのままで機能しますが、後の 2 つのシナリオを採⽤する場合は、⼊念なプラン
ニングが必要になります。万全を期すために、このセクションでは 4 つのシナリオすべてについて説明していき
ます。
注意： これらのシナリオは、分散サーチの権限設定にのみ対処しています。ローカルの権限設定は、分散サーチ
デプロイ環境とは無関係に機能します。
サーチヘッドプーリングなし、マウントバンドルなし
サーチヘッドの権限設定はすべて、サーチピアが受信する分散サーチリクエストとともに、複製されたナレッジバ
ンドルの⼀部として配布されます。
サーチヘッドプーリングなし、マウントバンドルあり
サーチヘッド上の権限設定はすべて、⾃動的にマウントバンドルに保管され、分散サーチ時にサーチピアにより使
⽤されます。
サーチヘッドプーリングあり、マウントバンドルなし
プール内のサーチヘッドは、/apps および /users ディレクトリを共有しますが、/etc/system/local ディレクトリは
共有しません。/apps サブディレクトリ内の authorize.conf ファイルはすべてのサーチヘッドが⾃動的に共有し、
いずれかのサーチヘッドがサーチピアにサーチリクエストを配布する際にナレッジバンドルに含まれます。
52
権限の変更はサーチヘッドの /etc/system/local ディレクトリ内の authorize.conf ファイルにも保存されるため、問
題が発⽣することもあります (例：サーチヘッドの権限設定を Splunk Web で更新する場合)。このディレクトリ
は、プール内のサーチヘッド間では共有されませんが、ナレッジバンドルの⼀環としてサーチピアに配布されま
す。設定システムの動作の仕組みにより、/etc/system/local 内の authorize.conf ファイルのコピーは、/apps サブ
ディレクトリ内のファイルよりも優先されます。(詳細は『管理マニュアル』の「設定ファイルの優先度」を参照
してください。)
そのため、単⼀のサーチヘッドの /etc/system/local ディレクトリからサーチピアに配布される authorize.conf のコ
ピーは、サーチヘッドプールの共有ディレクトリから配布される任意のコピーよりも優先されます。この状況を考
慮しないと、サーチピアはサーチのためにサーチヘッドが配布した権限設定に応じて、各サーチで異なる権限設定
を使⽤することになります。⼤部分の状況下では、このような事態は望ましくありません。
この問題を回避するために、サーチヘッドの /etc/system/local/authorize.conf ファイルに対して⾏われた変更が、
プール内のすべてのサーチヘッドに伝搬されるようにする必要があります。これに対処するための⽅法の 1 つ
は、変更された /etc/system/local/authorize.conf ファイルを App サブディレクトリに移動することです。プール
内のすべてのサーチヘッドが、/apps ディレクトリを共有しているためです。
サーチヘッドプーリングあり、マウントバンドルあり
これは前のシナリオと似ています。プール内のサーチヘッドは、/apps および /users ディレクトリを共有します
が、/etc/system/local ディレクトリは共有しません。/apps サブディレクトリ内の authorize.conf ファイルは、すべ
てのサーチヘッドにより⾃動的に共有されます。また、サーチピアがいずれかのサーチヘッドからのサーチリクエ
ストを処理する場合に使⽤するマウントバンドルにも含まれます。
ただし、権限の変更がサーチヘッドの /etc/system/local ディレクトリ内の authorize.conf ファイルに影響すること
もあります (例：サーチヘッドの権限設定を Splunk Web で更新する場合)。このディレクトリは、プール内の
サーチヘッド間で⾃動的に共有されることはありません。また、サーチピアが使⽤するマウントバンドルに⾃動的
に配布されることもありません。そのため、当該バージョンの authorize.conf にすべてのサーチヘッドとすべての
サーチピアがアクセスできるための、何らかの⼿段を⽤意する必要があります。
もっとも簡単な⽅法は、変更された /etc/system/local/authorize.conf ファイルを App サブディレクトリに移動す
ることです。プール内のすべてのサーチヘッドとすべてのサーチピアが、/apps ディレクトリを共有しているため
です。
ユーザーによる分散サーチの制御
ユーザーの観点からは、分散サーチ の指定と実⾏は基本的に他のサーチの実⾏と同じです。背後では、サーチ
ヘッド がクエリをサーチピア に分散し、返された結果を統合してユーザーに表⽰します。
ユーザーは、サーチに参加するサーチピアを制限することができます。また、トラブルシューティングのために、
分散サーチの設定を理解しておく必要があります。
分散サーチの実⾏
⼀般的に、分散サーチはローカルサーチと同じコマンドセットを使⽤します。ただし、分散サーチを制御、制限す
るために、追加のコマンドやオプションが⽤意されています。
デフォルトでサーチヘッドは、すべてのサーチ・ピアに対してサーチを実⾏します。クエリに splunk_server
フィールドを指定することで、サーチを 1 台または複数台のサーチ・ピアに制限することができます。詳細は、
『サーチマニュアル』の「インデックスと分散サーチピアからのイベントの取得」を参照してください。
サーチコマンド localop も、分散サーチの定義に役⽴ちます。これを利⽤して、サーチヘッドでのそれ以降のコマ
ンドの実⾏を制限することができます。詳細と例については、『サーチリファレンス』の localop の説明を参照
してください。
また、lookup コマンドには、分散サーチで使⽤するための local 引数が⽤意されています。true を設定すると、
サーチヘッド上でのみルックアップが⾏われます。false の場合は、サーチピア上でもルックアップが⾏われま
す。これは、ルックアップテーブルを複製する、スクリプトを使⽤するルックアップで特に役⽴ちます。詳細と例
については、『サーチリファレンス』の lookup の説明を参照してください。
分散サーチのトラブルシューティング
⼀般的な設定に関する問題
サーチヘッドとサーチピアのクロックスキューがサーチ動作に与える影響
サーチヘッドとサーチピアのクロックを、NTP または他の⼿段を使って同期することが重要です。数秒以上ク
ロックの同期が取れないと、サーチが失敗したり、不完全なサーチ結果が⽣成されたりしてしまいます。
ナレッジ・バンドル内の設定がサーチ・ピアにまだ複製されていないとサーチが失敗する
可能性がある
設定の変更がサーチヘッドからサーチピアに反映されるまで、少し時間がかかることがあります。そのため、サー
チヘッド上で設定の変更が⾏われてから、それがサーチピアに複製されるまでの間 (⼀般的には数分以下)、分散
サーチが失敗するか、または前の設定に基づいた結果が返されることがあります。
53
サーチ失敗が発⽣する可能性がある設定の変更には、新しい App が関与する変更や、authentication.conf や
authorize.conf に対する変更が挙げられます。例：
ロールに対して許可するインデックスを変更してから、そのロールのユーザーとしてサーチを実⾏した
新しい App を作成して、そのApp 内からサーチを実⾏した
このような失敗が発⽣すると、サーチヘッド上にメッセージが記録されます。
前の設定に基づいた結果を返す変更には、フィールド抽出またはルックアップテーブルファイルの変更が含まれま
す。
対処するには、サーチを再実⾏してください。
サーチヘッドプーリング設定に関する問題
サーチヘッドプーリングを導⼊する場合、理解しておく必要があるいくつかの問題が存在しています。これらは主
に、各サーチヘッド間の調整に関する問題です。
Splunk Web で⾏った認証と権限の変更は単⼀のサーチヘッドにのみ適⽤される
サーチヘッドで Splunk Web を使って⾏った認証と権限の変更は、そのサーチヘッドにのみ適⽤され、プール内
の他のサーチヘッドには適⽤されません。プールの各メンバーは、⾃⼰のローカル設定を
$SPLUNK_HOME/etc/system/local に保管しています。プール全体で設定を共有するには、「サーチヘッドプーリングの
設定」の説明に従って、共有ストレージに設定を保管します。
サーチヘッドと共有ストレージのクロックスキューがサーチ動作に与える影響
サーチヘッドと共有ストレージサーバーのクロックを、NTP または他の⼿段を使って同期することが重要です。
数秒以上クロックの同期が取れないと、サーチが失敗したり、不完全なサーチ結果が⽣成されたりしてしまいま
す。
共有ストレージサーバー上の権限に関する問題でプーリング障害が発⽣する可能性
各サーチヘッド上で Splunk を実⾏するユーザーアカウントには、共有ストレージサーバー上のファイルへの読み
取り/書き込み権限が必要です。
パフォーマンス分析
サーチヘッドプーリングに関する問題の割合が⼤きくなると、パフォーマンスが悪化します。
サーチヘッドプーリングのデプロイまたは調査時には、以下の事項を考慮することが⼤切です。
ストレージ： プールが使⽤するストレージは、⾮常に⾼い IOPS に対応できなければなりません。IOPS が
1000 未満の場合は、おそらく正常に動作することはできません。
ネットワーク： ストレージとサーチヘッド間の通信パスは、⾼い帯域幅を持ち、待ち時間も⾮常に⼩さな値
でなければなりません。このことはほぼ、ストレージシステムをサーチヘッドと同じスイッチ上に配置する
必要があることを意味しています。WAN リンクでは、正常に機能しません。
サーバーの並列性： サーチでは多数のファイルを要求する⼤量のプロセスが実⾏されるため、システムの
並列性が⾼くなければなりません。そのため、多数のリクエストを並⾏処理できるように、NFS サーバーの
チューニングが必要なことがあります。
クライアントの並列性： クライアントのオペレーティングシステムは、⼤量のリクエストを同時に処理で
きなければなりません。
環境を確認するための⼀般的な⼿段を以下に⽰します。
ファイルストアが使⽤されていない間に、Bonnie++ などのストレージベンチマークツールを利⽤して、
IOPS が⼗分であることを検証します。
ネットワークテストを実施して、サーチヘッドとストレージシステム間の往復時間が、約 10ms 程度である
ことを確認します。
100 万個のファイルを作成してそれらを削除するなどの、単純な作業を実⾏します。
以上のようなテストを⾏って何の問題もなかった場合は、I/O 負荷⽣成タスクを実⾏または実際に Splunk
Enterprise を実⾏して負荷を⽣成しながら、NFS 統計データを収集し、NFS リクエストに問題がないかど
うかを確認します。
NFS クライアントの同時処理数の制限によりタイムアウトの発⽣やサーチが速度が遅くな
る可能性がある
サーチヘッドプールのサーチパフォーマンスは、共有ストレージのスループットとサーチ負荷によって決まりま
す。実⾏中の同時サーチユーザー数と同時スケジュール済みサーチ数の組み合わせにより、共有ボリュームに必要
な合計 IOP が決まります。IOP 要件は、実⾏されるサーチの種類によっても変化します。サーチヘッド間で共⽤
するデバイスを適切に準備するために、サーチを実⾏する同時ユーザー数および同時に実⾏されるジョブ数/App
数を把握する必要があります。
サーチがタイムアウトする、またはサーチ実⾏が遅い場合は、NFS クライアントが対処できる最⼤同時リクエス
ト数を超えている可能性があります。この問題を解決するには、クライアントの同時処理可能性を増やしてくださ
い。たとえば、Linux NFS クライアントで tcp_slot_table_entries の設定を調整します。
多数のユーザーによる NFS 待ち時間の増加は設定アクセス遅延やディスパッチリーピング
遅延につながる可能性がある
54
Splunk Enterprise はサーチヘッドプールのストレージ設定状態の変更を検出すると、インメモリーの状態と同期
します。基本的には設定が更新されると、その設定がメモリー内に読み込まれます。サーチプールのストレージが
過負荷状態または多数のユーザー、App、設定ファイルを処理する場合、この同期プロセスによりパフォーマンス
が低下する可能性があります。これを軽減するために、「設定更新タイミングの選択」で説明しているように、最
低読み取り頻度を増やすことができます。
⼀意の serverName 属性に関する警告
プール内の各サーチヘッドには、⼀意の serverName 属性が必要です。Splunk Enterprise は各サーチヘッドの開始
時に、この条件を検証します。問題が発⾒された場合は、エラーメッセージが⽣成されます。
serverName "<xxx>" has already been claimed by a member of this search head pool
in <full path to pooling.ini on shared storage>
There was an error validating your search head pooling configuration. For more
information, run 'splunk pooling validate'
このエラーの主な原因は、プール内の他のサーチヘッドがすでにこのサーチヘッドの serverName を使⽤しているこ
とにあります。問題に対処するためには、このサーチヘッドの次のところにある、serverName 属性を変更してくだ
さい：system/local/server.conf。
他にもこのエラー発⽣の原因となる状態があります。
現在のサーチヘッドの serverName が変更された。
現在のサーチヘッドの GUID が変更された。⼀般的にこれは、/etc/instance.cfg が削除されたことが原因で
す。
これらの問題を修正するには、以下のコマンドを実⾏します。
splunk pooling replace-member
これにより、pooling.ini ファイルが現在のサーチヘッドの
ピングに上書きされます。
serverName->GUID
マッピングで更新され、従来のマッ
アップグレード後に Splunk Web に不⾃然または不正確な項⽬が表⽰される
プールを使うサーチヘッドのアップグレード時には、アップグレード完了後に、Splunk Enterprise に同梱されて
いる App も含めて (サーチ App や App として実装されているデータプレビュー機能など)、すべての 更新され
た App を、サーチヘッドプールの共有ストレージにコピーする必要があります。そうしないと、Splunk Web に
不⾃然または不正確な項⽬が表⽰されることがあります。
この問題を修正するには、アップグレードしたサーチヘッドから、すべての更新された App をサーチヘッドプー
ルの共有ストレージにコピーします。このとき、各 App の local サブディレクトリは除外するように注意してく
ださい。
重要： コピー時に各 App の local サブディレクトリを除外することで、共有ストレージの設定ファイルがローカ
ル版の設定ファイルで上書きされることを防⽌できます。
App のコピーが完了したら、プール内のすべてのサーチヘッドで Splunk Enterprise を再起動してください。
分散サーチのエラーメッセージ
分散サーチに関連する⼀般的なサーチ時エラーメッセージの⼀部を、以下の表に⽰します。
エラーメッセージ
意味
status=down
指定されたリモートピアを利⽤できません。
status=not a splunk server
指定されたリモートピアが、Splunk Enterprise サーバーではありません。
duplicate license
指定されたリモートピアが重複するライセンスを使⽤しています。
certificate mismatch
指定されたリモートピアとの認証に失敗しました。
55

Splunkによる コンプライアンス

統合ログ監視システムの構築で 脅威をいち早く検出、解析して - Splunk

NEXT SPOT 設定マニュアル - NEXT-BB

ごい牌 ルール （四人専用）

VP-930R ランプ表示によるプリンタ状態

『激突! ブレイク学園』新機能レイドバトル「征伐戦」を開催

中間CA証明書 設定変更手順書（Apache）

ス​マ​ー​ト​グ​リ​ッ​ド

『ドラゴンギャル～双龍の闘い～』無料版アプリを先行

初中級・準中級・中級・中上級 - 早稲田大学アカデミックソリューション

Ficha - Comercial Aliagro

日本語 - 関西学院大学

Splunk Enterprise 6.2.0 インストールマニュアル