Splunk Enterprise 6.3.0
インデクサーおよびインデクサーのク
ラスタの管理
作成⽇時：2015/09/04 3:44 pm
Copyright (c) 2016 Splunk Inc. All Rights Reserved
Table of Contents
インデックスの概要
インデックス、インデクサー、およびインデクサークラスタ
インデックス作成の仕組み
インデックス時とサーチ時
インデクサーのインストール
分散環境でのインデクサー
5
5
6
8
9
9
インデックスの管理
インデックスの管理について
複数のインデックスの設定
インデックスとインデックスデータの削除
インデックス並列化⽤パイプラインセットの管理
インデックスの最適化
DMC を使⽤してインデックス作成のパフォーマンスを確認する
11
11
11
15
17
19
19
インデックスストレージの管理
インデクサーによるインデックスの保管⽅法
インデックスストレージの設定
インデックスデータベースの移動
インデックスデータ⽤の複数パーティションの使⽤
インデックスサイズの設定
ディスク使⽤量の制限の設定
ブルームフィルタの設定
再起動が必要な indexes.conf の変更
DMC を使⽤してインデックスとボリュームステータスを確認する
19
19
22
24
25
26
28
29
30
30
インデックスのバックアップとアーカイブ
インデックス作成されたデータのバックアップ
リタイアおよびアーカイブポリシーの設定
インデックス作成されたデータのアーカイブ
アーカイブされたインデックスデータの復元
31
31
33
34
36
インデクサークラスタとインデックスレプリケーションの概要
インデクサークラスタとインデックスレプリケーションについて
マルチサイト・インデクサー・クラスタ
インデクサー・クラスタ・アーキテクチャの基礎
マルチサイト・インデクサー・クラスタのアーキテクチャ
39
39
41
42
47
インデクサークラスタのデプロイ
インデクサークラスタのデプロイの概要
クラスタ構成と⾮クラスタ構成のインデクサーデプロイの主な相違
点
インデクサークラスタのシステム要件とその他のデプロイに関する
検討事項
インデクサークラスタのマスターノードを有効にする
ピアノードを有効にする
サーチヘッドを有効にする
ベストプラクティス：マスターノードのデータのインデクサーレイ
ヤーへの転送
ピアのインデックスレプリケーションの準備
インデクサークラスタを使ったインデックスの増強
⾮クラスタインデクサーのクラスタ化環境への移⾏
インデクサークラスタのアップグレード
50
51
53
53
57
58
58
60
60
60
61
62
インデクサークラスタへのデータの取り込み
インデクサークラスタへのデータの取り込み⽅法
フォワーダーを使ったインデクサークラスタへのデータの取り込み
インデクサー検出によりフォワーダーをピアノードに接続
フォワーダーをピアノードに直接接続
69
69
69
71
75
インデクサークラスタの設定
インデクサークラスタの設定の概要
ダッシュボードを使ったインデクサークラスタの設定
server.conf を使ったインデクサークラスタの設定
CLI を使ったインデクサークラスタの設定と管理
76
76
77
77
78
マスターの設定
マスター設定の概要
ダッシュボードを使ったマスターの設定
server.conf を使ったマスターの設定
CLI を使ったマスターの設定
インデクサークラスタのマスターノードの交換
79
79
80
80
81
81
ピアの設定
ピアノード設定の概要
ダッシュボードを使ったピアノードの設定
server.conf を使ったピアノードの設定
CLI を使ったピアノードの設定
すべてのピアの共通設定の管理
すべてのピアの App デプロイの管理
インデクサークラスタ内のピアインデックスの設定
共通のピア設定と App の更新
ピア単位での設定の管理
82
82
83
84
84
85
86
86
88
92
サーチヘッドの設定
サーチヘッド設定の概要
ダッシュボードを使ったサーチヘッドの設定
server.conf を使ったサーチヘッドの設定
CLI を使ったサーチヘッドの設定
複数のインデクサークラスタにまたがったサーチ
ハイブリッドサーチの設定
93
93
94
95
95
96
98
マルチサイト・インデクサー・クラスタのデプロイと設定
98
マルチサイト・インデクサー・クラスタのデプロイの概要
98
マルチサイト・インデクサー・クラスタへのサーチアフィニティの 99
導⼊
server.conf を使ったマルチサイト・インデクサー・クラスタの設 101
定
CLI を使ったマルチサイト・インデクサー・クラスタの設定
104
サイトの複製データ保持数の設定
106
サイトのサーチ可能データ保持数の設定
108
単⼀サイトからマルチサイトへのインデクサークラスタの移⾏
110
インデクサークラスタのステータスの表⽰
[マスター] ダッシュボードの表⽰
[ピア] ダッシュボードの表⽰
[サーチヘッド] ダッシュボードの表⽰
DMC を使⽤してインデクサークラスタステータスを確認する
112
112
114
115
116
インデクサークラスタの管理
ピアをオフラインにする
116
116
メンテナンスモードの使⽤
インデクサークラスタ全体または 1 台のピアノードの再起動
ローリング再起動 コマンドの使⽤
インデクサークラスタのプライマリバケツの再調整
インデクサークラスタからの超過バケツコピーの削除
マスターのリストからのピアの削除
117
118
119
121
121
123
マルチサイト・インデクサー・クラスタの管理
マスターサイト障害の取り扱い
マスター再起動またはサイト障害後のインデックス作成の再開
マルチサイト・インデクサー・クラスタの単⼀サイトクラスタへ
の変換
ピアの新しいサイトへの移動
123
123
123
124
インデクサークラスタの仕組み
⾼度なユーザー向けのインデクサークラスタの基本概念
複製データ保持数
サーチ可能データ保持数
バケツとインデクサークラスタ
インデクサークラスタの状態
クラスタでのインデックス作成の仕組み
インデクサークラスタでのサーチの仕組み
インデクサー・クラスタ・ノードの起動⽅法
ピアノード停⽌時の処理
ピアノードが復帰した場合の処理
マスターノード停⽌時の処理
124
124
125
126
126
131
131
132
134
134
139
140
インデクサーおよびインデクサーのクラスタのトラブルシューティ
ング
⾮クラスタバケツの問題
バケツのレプリケーションの問題
設定バンドルの問題
140
124
140
142
143
インデックスの概要
インデックス、インデクサー、およびインデクサークラスタ
このマニュアルでは、Splunk Enterprise のデータリポジトリとそれを作成、管理するための Splunk Enterprise
コンポーネントについて説明していきます。
インデックス は、Splunk Enterprise データのリポジトリです。Splunk Enterprise は到着したデータをイベン
ト に変換します。イベントはインデックスに保管されます。
インデクサー は、データのインデックスを作成する Splunk Enterprise インスタンスです。⼩規模なデプロイ環
境では、単⼀のインスタンスが他の Splunk Enterprise 機能 (データの取り込みやサーチ管理など) も担当する場
合があります。ただし、⼤規模な分散 環境の場合、データの取り込みとサーチ管理は他の Splunk Enterprise コ
ンポーネントが担当します。このマニュアルでは、単⼀インスタンスまたは分散デプロイ環境における、インデッ
クス作成機能を集中的に取り上げていきます。
インデクサークラスタ は、相互のデータを複製するように設定されたインデクサーのグループです。このプロセ
スは、インデックスレプリケーション またはインデクサークラスタリングとして知られています。クラスタは
データの複数の同⼀コピーを保持することにより、データ消失を防⽌しながら、サーチ⽤データの可⽤性を向上し
ます。
インデックス
Splunk Enterprise がデータのインデックスを作成する際、多数のファイルが作成されます。これらのファイル
は、主に 2 つのカテゴリに分類できます。
圧縮形式の raw データ (rawdata )
raw データを指すインデックス (インデックスファイル 、tsidx ファイル とも呼ばれます) およびいくつ
かのメタデータファイル
Splunk Enterprise のインデックスは、これらのファイルにより構成されています。⼀連のディレクトリに保管さ
れているファイルは、その経過時間で管理されています。これらのディレクトリは、バケツ と呼ばれています。
詳細は、このマニュアルの「Splunk Enterprise によるインデックスの保管⽅法」を参照してください。
Splunk Enterprise は、柔軟なサーチと⾼速なデータ取得を⽬的にインデックスを管理しています。インデックス
は、ユーザーが設定可能なスケジュールにより順次アーカイブされます。Splunk Enterprise はすべてをフラット
ファイルで管理しています。バックグラウンドでサードパーティ製のソフトウェアを実⾏する必要はありません。
インデックス作成処理中に、Splunk Enterprise は⾼速なサーチ/分析を可能にするために、到着したデータを処
理して、その結果をインデックス内にイベントとして保管します。インデックス作成時に、Splunk Enterprise は
データをさまざまな⽅法で拡張します。以下に例を⽰します。
データストリームを個別のサーチ可能イベントに分割する。
タイムスタンプを作成、判別する。
ホスト、ソース、ソースタイプなどのフィールドを抽出する。
到着したデータに対して、カスタムフィールドの識別、重要なデータのマスキング、新規または変更された
キーの書き込み、複数⾏イベントの分割ルールの適⽤、不要なイベントのフィルタリング、イベントの特定
インデックスまたはサーバーへのルーティングなどの、ユーザー定義のアクションを実⾏する。
このインデックス作成プロセスは、イベント処理 としても知られています。
インデックス作成を開始するには、単に⽬的のデータ⼊⼒を指定します。その他の⼊⼒をいつでも追加することが
できます。追加したデータ⼊⼒に対してもインデックスが作成されます。データ⼊⼒の追加⽅法については、
『データの取り込み』マニュアルの「Splunk がインデックス処理できる項⽬」を参照してください。『データの
取り込み』マニュアルには、データのニーズを満たすための、インデックス時イベント処理の設定⽅法についても
説明されています。「イベント処理の概要」を参照してください。
デフォルトで Splunk Enterprise はすべてのユーザーデータを、単⼀の事前設定されたインデックスに保管しま
す。また、内部処理⽬的で他の複数のインデックスも作成します。新しいインデックスを追加したり、既存のイン
デックスをデータ要件に合わせて管理したりすることができます。詳細は、このマニュアルの「インデックスの管
理」を参照してください。
インデクサー
インデクサーは、インデックスの作成と管理を⾏う Splunk Enterprise コンポーネントです。インデクサーの主
な機能を以下に⽰します。
到着データのインデックス作成。
インデックスデータのサーチ。
1 つの Splunk Enterprise インスタンスからのみ構成される単⼀マシン環境では、データの取り込み およびサー
チ管理 機能もインデクサーが担当します。このタイプの⼩規模なデプロイは、組織内の単⼀部⾨のニーズを満た
す⽬的などで⽤いられます。
⼤規模環境でのニーズに合わせて、インデックス作成処理をデータの取り込み機能や、必要に応じてサーチ管理機
能からも切り離すことができます。このような⼤規模な分散環境では、Splunk インデクサーはしばしば独⾃のマ
シン上に常駐し、そのインデックスデータのサーチとともにインデックス作成処理のみを担当します。このような
場合、インデックス作成以外の処理は他の Splunk Enterprise コンポーネントが担当します。フォワーダー が
データを取り込んで、インデクサーがデータのインデックス作成とサーチを⾏い、サーチヘッド がインデクサー
全体のサーチを調整します。⼤規模環境へのデプロイ例を以下に⽰します。
5
インデクサーを使った分散デプロイの詳細は、このマニュアルの「分散デプロイ環境のインデクサー」を参照して
ください。
Splunk インデクサーは、単なる Splunk Enterprise インスタンスです。Splunk Enterprise インスタンスのイン
ストール⽅法については、『インストール』マニュアルを参照してください。
インデクサークラスタ
インデクサークラスタは、連携して冗⻑インデックス作成およびサーチ機能を提供する、Splunk Enterprise ノー
ドのグループです。クラスタ内には 3 種類のノードが存在しています。
クラスタを管理する単⼀のマスターノード 。マスターノードは、特別なタイプのインデクサーです。
クラスタのインデックス作成機能を担当し、複数のインデックスデータのコピーを保持し、データをサーチ
する複数のピアノード 。
すべてのピアノードにまたがってサーチを調整、管理する 1 つまたは複数のサーチヘッド。
インデクサークラスタ機能では、あるノードから別のノードに⾃動フェイルオーバーを⾏います。つまり、1 つま
たは複数のピアに障害が発⽣した場合でも、引き続き到着データのインデックスが作成され、サーチが可能になり
ます。
このマニュアルの前半では、すべてのインデクサーに関連する設定や管理情報について、それがクラスタの⼀部で
あるかに関係なく説明します。「インデクサークラスタとインデックスレプリケーションについて」のトピックか
らはじまる後半は、クラスタについてのみ重要な説明です。
インデックス作成の仕組み
Splunk Enterprise は任意の種類の時系列データ (タイムスタンプ を持つデータ) のインデックス を作成できま
す。データのインデックスを作成する際には、タイムスタンプに基づいてデータがイベント に分割されます。
イベント処理とデータパイプライン
データはインデクサーに⼊り、イベント処理 が発⽣するパイプラインを通じて処理を⾏います。最後に、処理さ
れたデータは、ディスクに書き込まれます。このパイプラインは、繋ぎ合わさった複数の短いパイプラインで構成
されています。このエンドトゥエンドのデータパイプラインの単⼀インスタンスは、パイプラインセット と呼ば
れています。
イベント処理は、パーシングとインデックス作成の 2 つのメインステージに別れて⾏われます。Splunk
Enterprise に取り込まれるデータはすべて、⼤きなチャンク (10,000 バイト) としてパーシングパイプライン を
通過します。パーシング中に、これらのチャンクはイベントに分割されます。分割されたイベントは、インデッ
クス作成 パイプラインに渡されて、最終処理が⾏われます。
パーシング中、Splunk Enterprise はさまざまなアクションを実⾏します。以下に例を⽰します。
各イベントに対して、host、source、および sourcetype などの、⼀連のデフォルトフィールドを抽出する。
⽂字セットのエンコードを設定する。
⾏分割ルールを使って⾏の終端を識別する。⼤半のイベントは短く、1〜2 ⾏程度ですが、中には⻑いイベ
6
ントも存在しています。
タイムスタンプを識別する、また存在しない場合は作成する。タイムスタンプ処理と同時に、イベント境界
の識別が⾏われます。
このステージで、重要なイベントデータ (クレジットカード情報や社会保障番号など) をマスクするように
Splunk を設定することができます。また、受信したイベントにカスタム・メタデータを適⽤するように設
定することもできます。
インデックス作成パイプラインでは、以下のような追加処理が⾏われます。
すべてのイベントを、サーチ可能なセグメントに分割する。セグメント分割レベルを指定することができま
す。この設定は、インデックス作成/サーチ速度、サーチ能⼒、およびディスクの圧縮効率に影響します。
インデックスデータ構造を作成する。
raw データとインデックスファイルをディスクに書き込む。ディスクでは、インデックス作成後の圧縮処理
が⾏われます。
パーシングパイプラインとインデックス作成パイプラインの分割は、主にフォワーダー のデプロイの際に重要で
す。ヘビーフォワーダー は、パーシング⽤パイプラインを介して⽣データを実⾏でき、最終的なインデックス作
成処理を⾏うためにそのデータをインデクサーに転送できます。ユニバーサルフォワーダー はこの⽅法でデータ
のパーシングを⾏いません。代わりに、ユニバーサルフォワーダーは⽣データをインデクサーに転送し、両⽅のパ
イプラインを通じて処理を⾏います。ただし、これら 2 種類のフォワーダーは特定の構造化データにパーシング
を⾏う点に留意してください。『データの取り込み』マニュアルの「ヘッダーのあるファイルからのデータ抽出」
を参照してください。
イベントおよびインデクサーがデータをイベントに転送する⽅法の詳細は、『データの取り込み』マニュアルの
「イベント処理の設定」を参照してください。
注意： インデックスの作成処理は I/O リソースを消費します。
インデックス作成の主要プロセスを以下の図に⽰します。
注意： この図は、インデックス作成アーキテクチャを簡単に説明したものです。これは、アーキテクチャを機能
的に表したもので、Splunk Enterprise の内部動作を完全に表している訳ではありません。特に、パーシング・パ
イプラインは、実際にはパーシング 、マージング 、およびタイピング の 3 つのパイプラインで成り⽴ってお
り、これらが連携してパーシング機能を担当しています。このような区別はトラブルシューティングの際に関係し
てきますが、⼀般的な Splunk Enterprise の設定やデプロイには何も影響することはありません。
7
データパイプラインおよびデータパイプラインがデプロイの決定に与える影響についての詳細は、『分散デプロ
イ』マニュアルの「Splunk Enterprise 内でのデータの移動：データパイプライン」を参照してください。
インデックスには何がある？
Splunk Enterprise は、処理するデータすべてをインデックスに格納しています。インデックスはデータベースの
集合体で、$SPLUNK_HOME/var/lib/splunk のサブディレクトリに存在しています。インデックスは raw データファイ
ル とインデックスファイル の、2 種類のファイルタイプから成り⽴っています。詳細は、このマニュアルの
「Splunk Enterprise によるインデックスの保管⽅法」を参照してください。
インデックスのデフォルトセット
Splunk Enterprise には、さまざまな事前設定されたインデックスが⽤意されています。以下に例を⽰します。
main ：これは、デフォルトの Splunk Enterprise インデックスです。特に指定のない限り、処理された
データはすべてここに保管されます。
_internal ：Splunk Enterprise 内部ログおよび処理指標を保管します。
_audit ：ファイルシステム変更監視、追跡、およびすべてのユーザーサーチ履歴に関連するイベントが含ま
れます。
Splunk Enterprise 管理者は、新規インデックスの作成、インデックスプロパティの編集、不要なインデックスの
削除、および既存のインデックスの移動などの作業を⾏うことができます。Splunk Enterprise 管理者は、
Splunk Web 、CLI、および indexes.conf などの設定ファイルを使ってインデックスの管理を⾏います。詳細は、
このマニュアルの「インデックスの管理」を参照してください。
Answers
何か質問がありますか？「Splunk Answers」から、Splunk コミュニティに寄せられた、インデックス作成に関
する質問と回答をご覧ください。
インデックス時とサーチ時
Splunk Enterprise ドキュメントでは、頻繁に「インデックス時 」および「サーチ時 」という⽤語について⾔及
しています。これらの⽤語は、インデックス作成時に発⽣した処理のタイプとサーチ実⾏時に発⽣した処理のタイ
プを区別するために⽤いられます。
Splunk Enterprise を管理する際には、これらの違いを理解しておくことが重要です。たとえば、データのイン
デックス作成をまだ開始していない時点で、処理するカスタムソースタイプ やホスト が⼤量に存在していると考
えられる場合、あらかじめそれらを定義しておくことができます。そのためには、インデックス処理中にカスタム
ソースタイプとホストが適切に処理されるように、それらを事前に定義します (ルールベースのソースタイプ割り
当て、ソースタイプの優先設定、⼊⼒ベースのホスト割り当て、およびホストの優先設定などを使⽤)。
⼀⽅、すでにデータのインデックス作成を開始している場合は、サーチ時にこのような問題を処理することができ
ます。そうしない場合は、カスタムソースタイプ/ホストを既存のデータや新規データに適⽤するために、イン
デックスを再作成する必要があります。インデックスの作成後は、ホスト/ソースタイプ割り当てを変更すること
はできません。ただし、それらに代替値でタグを設定し、それを利⽤して問題を管理することができます。
⼀般的に、フィールド抽出などのナレッジ作成アクティビティは、サーチ時に実⾏することをお勧めします。カス
タムフィールドの抽出などの作業をインデックス時に実⾏すると、インデックス時とサーチ時の両⽅でパフォーマ
ンスが低下してしまいます。インデックス作成中に抽出フィールドを追加すると、インデックス作成処理速度が低
下してしまいます。また、他のフィールドの追加によりインデックスが巨⼤化し、当然⼤きなインデックスのサー
チには時間がかかるため、その後のインデックスに対するサーチ速度も低下してしまいます。サーチ時にフィール
ドの抽出を実⾏することで、このようなパフォーマンス上の問題を回避することができます。サーチ時のフィール
ド抽出の詳細は、『ナレッジ管理』マニュアルの「フィールドについて」および「Splunk Enterprise がフィール
ドを抽出する時期」を参照してください。
インデックス時
インデックス時 の処理は、イベントデータのインデックスを実際に作成する直前に⾏われます。
インデックス時 (またはその前) には、以下の処理が⾏われます。
デフォルトフィールドの抽出 (host、source、sourcetype、およびtimestamp など)
特定の⼊⼒に対する静的または動的なホスト割り当て
デフォルトのホスト割り当てへの優先設定
ソースタイプのカスタマイズ
カスタムインデックス時フィールドの抽出
構造化データフィールドの抽出
イベントのタイムスタンプ
イベントの改⾏処理
イベントのセグメント化 (サーチ時にも⾏われる)
サーチ時
サーチ時 の処理は、サーチ実⾏時にサーチによるイベントの収集に伴い⾏われます。サーチ時には以下の処理が
⾏われます。
イベントのセグメント化 (インデックス時にも⾏われる)
イベントタイプのマッチング
サーチ時フィールド抽出 (複数値フィールドおよび計算済みフィールドを含む、⾃動およびカスタムフィー
ルド抽出)
8
フィールドのエイリアス設定
ルックアップからのフィールド追加
ソースタイプ名の変更
タグの設定
インデクサーのインストール
デフォルトで、Splunk Enterprise インスタンスはすべてインデクサーとしての役割を果たします。Splunk
Enterprise インスタンスのインストール⽅法については、『インストール』マニュアルを参照してください。そ
の後このマニュアルに戻って、インデクサーの設定⽅法を学習してください。
分散環境にインデクサーをデプロイする場合は、「分散環境でのインデクサー」を参照してください。
分散環境でのインデクサー
重要： このトピックをより良く理解するためには、『分散デプロイ』マニュアルに記載されている Splunk
Enterprise 分散環境を理解しておく必要があります。
インデクサーは、インデックスの作成と管理を⾏う Splunk Enterprise コンポーネントです。インデクサーの主
な機能を以下に⽰します。
到着データのインデックス作成。
インデックスデータのサーチ。
1 つの Splunk Enterprise インスタンスからのみ構成される単⼀マシン環境では、データの取り込み およびサー
チ管理 機能もインデクサーが担当します。
⼤規模環境でのニーズに合わせて、インデックス作成処理をデータの取り込み機能や、必要に応じてサーチ管理機
能からも切り離すことができます。このような⼤規模な分散環境では、インデクサーはしばしば独⾃のマシン上に
常駐し、そのインデックスデータのサーチとともにインデックス作成処理のみを担当します。このような場合、イ
ンデックス作成以外の処理は他の Splunk Enterprise コンポーネントが担当します。
たとえば、イベントを⽣成する⼀連の Windows および Linux マシンが存在しており、それらのイベントを単⼀
のインデクサーに送って集中処理する場合を考えてみましょう。⼀般的にこれを実現するための最良の⽅法
は、フォワーダー として知られる軽量の Splunk Enterprise インスタンスを、イベントを⽣成する各マシン上に
インストールすることです。これらのフォワーダーはデータ⼊⼒を担当し、ネットワーク上のデータを専⽤のマシ
ンに常駐するインデクサーに送信します。
同様に、インデックス作成された⼤量のデータが存在しており、それに対して多数のユーザーが同時にサーチを実
⾏するような場合は、サーチ管理機能とインデックス作成機能を切り離す⽅が合理的です。このような分散サー
チ環境 では、1 つまたは複数のサーチヘッド が、サーチリクエストを複数のインデクサーにまたがって分配しま
す。インデクサーは引き続き各⾃のインデックスに対する実際のサーチを処理しますが、サーチヘッドがすべての
インデクサーにまたがって総合的なサーチプロセスを管理し、ユーザーに統合されたサーチ結果を提供します。
⼤規模環境へのデプロイ例を以下に⽰します。
9
分散環境でもインデックス作成とイベント処理に関する問題の基本は変わりありませんが、インデックス作成戦略
を策定する際には、デプロイのニーズを検討することが重要です。
インデクサーへのデータ転送
リモートデータをインデクサーに転送するには、フォワーダーを使⽤します。フォワーダーは、データ⼊⼒を受け
取り、それをまとめたデータを Splunk Enterprise インデクサーに送信します。フォワーダーは、2 種類に分類
できます。
ユニバーサルフォワーダー ：これらは、各⾃のホストマシンでリソースの消費量が少なくなっています。
到着したデータストリームに対して最低限の処理を⾏ってから、それをインデクサー (レシーバー ) に転送
します。
ヘビーフォワーダー ：これらは、完全な Splunk Enterprise インスタンスの⼤部分の機能を保有していま
す。インデクサーにデータを転送する前に、パーシングを⾏うことができます(パーシングとインデックス作
成の違いについては、「インデックス作成の仕組み」を参照してください)。これらは、インデックス作成し
たデータをローカルに保管したり、パーシングしたデータをレシーバーに転送し、そのマシン上で最終的な
インデックス処理を⾏ったりできます。
どちらの種類のフォワーダーでも、インデクサーにデータを転送する前に、ホスト、ソース、ソースタイプなどの
メタデータでデータにタグを設定します。
フォワーダーにより、リモートソースから到着する⼤量のデータまたは多彩な種類のデータを処理する場合に、リ
ソースを効率的に使⽤することができます。また、ロードバランシング 、データのフィルタリング 、およ
びルーティング などの機能により、さまざまなデプロイトポロジーを採⽤することができます。
フォワーダーの設定や詳細な使⽤事例も含めた説明については、『データの転送』マニュアルを参照してくださ
い。
複数インデクサーに対するサーチ
分散サーチで、サーチヘッドはサーチリクエストをインデクサーに送信し、結果を結合してユーザーに返します。
これは、⽔平スケーリング、アクセス制御、および地理的に分散したデータの管理など、さまざまな⽬的に役⽴ち
ます。
設定や使⽤事例も含めた分散サーチとサーチヘッドの詳細については、『分散サーチ』マニュアルの「分散サーチ
について」を参照してください。
インデクサーのクラスタ は、サーチヘッドを使ってクラスタのピアノード間のサーチを管理/調整しています。
「インデクサークラスタとインデックスレプリケーションについて」を参照してください。
分散環境へのインデクサーのデプロイ
このトピックで前に説明した図のような分散環境を導⼊するには、3 種類のコンポーネントをインストール、設定
する必要があります。
インデクサー
フォワーダー (⼀般的にはユニバーサルフォワーダー)
サーチヘッド
インデクサーのインストールと設定
デフォルトで、Splunk Enterprise インスタンスはすべてインデクサーとしての役割を果たします。⽔平⽅向ス
ケーリングでは、個別のマシンに複数のインデクサーをインストールすることができます。
Splunk Enterprise インスタンスのインストール⽅法については、『インストール』マニュアルを参照してくださ
い。
次にこのマニュアルに戻って、ご⾃分のデプロイ環境のニーズに合わせた各インデクサーの設定⽅法を参照してく
ださい。
フォワーダーのインストールと設定
⼀般的な分散デプロイ環境には、多数のフォワーダーが少数のインデクサーにデータを供給しています。たいてい
の場合は、ユニバーサルフォワーダーを利⽤するのが最適です。ユニバーサルフォワーダーは、Splunk
Enterprise とは別個にダウンロードすることができます。
フォワーダーのインストール、設定⽅法については、『データの転送』マニュアルを参照してください。
サーチヘッドのインストールと設定
分散サーチのニーズに合わせて、1 つまたは複数のサーチヘッドをインストールすることができます。サーチヘッ
ドは、特別な設定が⾏われた Splunk Enterprise インスタンスです。
サーチヘッドの詳細は、『分散サーチ』マニュアルを参照してください。
その他のデプロイ作業
ライセンスマスター を指定して、Splunk Enterprise ライセンスを設定する必要があります。詳細は、『管理』
マニュアルの「Splunk Enterprise ライセンスの設定 」を参照してください。
Splunk Enterprise のデプロイサーバー を使って、デプロイコンポーネントの更新作業を簡素化することができ
10
ます。デプロイサーバーの設定⽅法の詳細は、『Splunk Enterprise インスタンスの更新 』マニュアルを参照
してください。
インデクサーのクラスタのインストール
データの可⽤性、データの忠実度、およびデータの復元がデプロイ環境の主⽬的である場合は、⼀連のインデク
サーではなくインデクサークラスタのデプロイを検討する必要があります。詳細は、このマニュアルの「インデク
サークラスタとインデックスレプリケーションについて」を参照してください。
インデックスの管理
インデックスの管理について
データを追加すると、それが処理されてインデックス に格納されます。デフォルトでは、インデクサーに取り込
んだデータはメイン (main) インデックスに保管されます。ただし、他のインデックスを作成して、別のデータ⼊
⼒で使⽤するように設定することができます。
インデックスは、ディレクトリとファイルの集合体です。これらは、$SPLUNK_HOME/var/lib/splunk 下にあります。
インデックスディレクトリは「バケツ 」とも呼ばれており、その経過時間で編成管理されています。インデック
スストレージの詳細は、「Splunk Enterprise によるインデックス保管の仕組み」を参照してください。
main インデックスの他に、Splunk Enterprise には事前設定されたさまざまな内部インデックスが⽤意されてい
ます。内部インデックスは、アンダースコア (_) から始まる名前が付けられています。Splunk Web のインデック
スの⼀覧を表⽰するには、Splunk Web の上部にある [設定] リンクをクリックして、次に [インデックス] を選
択します。リストには、以下の項⽬が含まれます。
main ：これは、デフォルトの Splunk Enterprise インデックスです。特に指定のない限り、処理された外
部データはすべてここに保管されます。
_internal ：このインデックスには、Splunk Enterprise 内部ログと測定基準が含まれています。
_audit ：ファイルシステム変更監視、追跡、およびすべてのユーザーサーチ履歴に関連するイベントが含ま
れます。
このマニュアルのさまざまなトピックで、さまざまなインデックスの管理⽅法が説明されています。特にインデッ
クス管理においては、以下のトピックが役に⽴ちます。
複数のインデックスの設定
Splunk からのインデックスとデータの削除
インデックスストレージの設定
インデックスデータベースの移動
インデックスデータ⽤の複数パーティションの使⽤
インデックスサイズの設定
ディスク使⽤量の制限の設定
インデックス作成されたデータのバックアップ
リタイアおよびアーカイブポリシーの設定
インデックス作成処理の詳細
インデックスの詳細については、以下の項⽬を参照してください。
このマニュアルの「インデックス作成の仕組み」。
このマニュアルの「Splunk によるインデックスの保管⽅法」。
このマニュアルの「クラスタとインデックスレプリケーションについて」。
『データの取り込み』マニュアルの「イベント処理の設定」。
とても巨⼤なデータセットに関する作業については、『ナレッジ管理』マニュアルの「サマリーインデック
スの設定と使⽤」。
複数のインデックスの設定
デフォルトでは、main インデックスにすべてのイベントが保管されます。インデクサーは他にも、内部システムが
使⽤する各種インデックス、およびサマリーインデックスやイベント監査などの他の機能⽤のインデックスも保有
しています。
Splunk Enterprise ライセンスでは、追加のインデックスを無制限に追加することができます。main インデックス
は、インデックスが指定されていない任意の⼊⼒またはサーチコマンドのデフォルトインデックスとしての役割を
果たします。このデフォルトは変更することができます。インデックスは、Splunk Web、CLI、または
indexes.conf を使って追加することができます。
ここでは、以下の事項を取り上げていきます。
複数のインデックスを利⽤する理由。
新しいインデックスの作成⽅法。
特定のインデックスへのイベントの送信⽅法。
特定のインデックスのサーチ⽅法。
複数のインデックスを利⽤する理由
複数のインデックスを利⽤するさまざまな理由が存在しています。
ユーザーのアクセスを制御する。
11
さまざまな保持ポリシーを採⽤する。
特定の状況下でサーチを⾼速化する。
複数のインデックスを設定する主な理由は、ユーザーのデータに対するアクセスを制御することにあります。ユー
ザーをロール に割り当てる場合、ユーザーのサーチを各⾃のロールに基づいて特定のインデックスに制限するこ
とができます。
また、異なるデータセットに対して異なる保持ポリシーを適⽤する場合、データを異なるインデックスに送信し
て、各インデックスに対して異なるアーカイブ/保持ポリシーを設定することができます。
また、サーチ⽅法に応じて複数のインデックスの設定が必要な場合もあります。⼤量の⾼ノイズデータソースと、
少量のデータソースを同じインデックスに取り込み、たいていの場合は少量のデータソースに対してサーチを⾏う
場合、インデクサーは⼤量のボリュームソースからのデータもサーチする必要があるため、サーチ速度は通常より
も低下します。この問題を緩和するために、各データソース専⽤のインデックスを作成し、各ソースから専⽤のイ
ンデックスにデータを送信することができます。これで、サーチするインデックスを指定することができます。こ
れにより、サーチ速度を改善することができます。
インデックスの作成と編集
Splunk Web、CLI を使⽤するか、または
きます。
indexes.conf
を直接変更して、インデックスを作成、編集することがで
注意： インデクサークラスタに新しいインデックスを追加するには、indexes.conf を直接編集する必要がありま
す。Splunk Web または CLI を使ってインデックスを追加することはできません。クラスタ向けの indexes.conf
の設定⽅法については、「インデクサークラスタ内のピアインデックスの設定」を参照してください。このトピッ
クには、新しいクラスタインデックスの作成例が記載されています。
Splunk Web の使⽤
1. Splunk Webで、[設定] > [インデックス] に移動して、[新規] をクリックします。
2. 新しいインデックスを作成するには、以下の項⽬を⼊⼒します。
インデックスの名前。ユーザー定義のインデックス名には、数字、英⼩⽂字、アンダースコア、およびハイ
フンのみを使⽤できます。
インデックスデータストレージのパス：
ホームパス：空にするとデフォルトを使⽤： $SPLUNK_DB/<index_name>/db
コールド DB パス：空にするとデフォルトを使⽤： $SPLUNK_DB/<index_name>/colddb
復元済み/再⽣済み DB パス：空にするとデフォルトを使⽤： $SPLUNK_DB/<index_name>/thaweddb
インデックス全体の最⼤サイズ。デフォルトは 500000 MB です。
このインデックスのホット (現在書き込まれている) 部分の最⼤サイズ。最⼤サイズを設定する場合、量が多
いインデックス (main インデックスなど) には auto_high_volume を、それ以外の場合は auto を使⽤してくだ
さい。
フローズン (変更不可) バケツアーカイブパス。フローズンバケツをアーカイブする場合にこのフィールドを
設定します。バケツのアーカイブの詳細は、「インデックス作成されたデータのアーカイブ」を参照してく
ださい。
注意： これらの設定の詳細は、「インデックスストレージの設定」を参照してください。
3. [保存 ] をクリックします。
Splunk Web の [設定] の [インデックス] セクションで、インデックス名をクリックしてインデックスを編集す
ることができます。[設定] で変更できないプロパティは灰⾊表⽰されます。それらのプロパティを変更するに
は、indexes.conf を編集してから、インデクサーを再起動してください。
注意： ⼀部のインデックスプロパティは、indexes.conf ファイルを編集することによってのみ設定できます。プロ
パティの全⼀覧については、indexes.conf のトピックを参照してください。
CLI の使⽤
$SPLUNK_HOME/bin/
ディレクトリに移動して、add
index
コマンドを実⾏します。最初にインデクサーを停⽌する必要
はありません。
新しいインデックス「fflanda」を追加するには、以下のコマンドを⼊⼒します。
splunk add index fflanda
注意： ユーザー定義のインデックス名には、数字、英⼩⽂字、アンダースコア、およびハイフンのみを使⽤でき
ます。先頭にアンダースコアまたはハイフンを使⽤することはできません。
新しいインデックスに対してデフォルトパスを使⽤したくない場合は、パラメータを使って別の場所を指定しま
す。
splunk add index foo -homePath /your/path/foo/db -coldPath /your/path/foo/colddb
-thawedPath /your/path/foo/thawedDb
CLI からインデックスのプロパティを編集することもできます。たとえば、インデックス「fflanda」を編集する
には、CLI で以下のように⼊⼒します。
12
splunk edit index fflanda -<parameter> <value>
インデックス設定の詳細は、「インデックスストレージの設定」を参照してください。
indexes.conf の編集
新しいインデックスを追加するには、$SPLUNK_HOME/etc/system/local にある
でスタンザを追加します。例：
indexes.conf
に、新しいインデックス名
[newindex]
homePath=<path for hot and warm buckets>
coldPath=<path for cold buckets>
thawedPath=<path for thawed buckets>
...
インデックス設定の詳細は、「インデックスストレージの設定」および indexes.conf ファイルの説明を参照して
ください。
注意： スタンザ内に指定するインデックス名には、数字、英⼩⽂字、アンダースコア、およびハイフンのみを使
⽤できます。ユーザー定義インデックスの開始⽂字として、アンダースコアまたはハイフンを使⽤することはでき
ません。
indexes.conf
を編集したら、インデクサーを再起動する必要があります。
重要： クラスタノードのインデックス設定の追加、編集については、「インデクサークラスタ内のピアインデッ
クスの設定」を参照してください。
特定のインデックスへのイベントの送信
デフォルトでは、すべての外部イベントが main インデックスに送られます。しかし、⼀部のイベントを別のイ
ンデックスに送りたい場合もあるでしょう。たとえば、特定のデータ⼊⼒からのデータを独⾃のインデックスに送
ることができます。また、データをセグメント化したり、ノイズの多いソースからのイベントデータを専⽤のイン
デックスに送ったりできます。
重要： イベントを特定のインデックスに送るには、インデクサー上にそのインデックスがすでに存在していなけ
ればなりません。存在しないインデックスにイベントを送った場合、インデクサーはそれらのイベントを破棄しま
す。
データ⼊⼒から特定のインデックスへのすべてのイベントの送信
特定のデータ⼊⼒からのすべてのイベントを特定のインデックスに送るには、システムにデータを取り込んでいる
Splunk Enterprise コンポーネント (インデクサーまたはインデクサーにデータを送信するフォワーダー) 上の
inputs.conf のデータ⼊⼒⽤スタンザに以下の⾏を追加します。
index = <index_name>
以下の
inputs.conf
スタンザの例では、/var/log からのすべてのデータをインデックス
fflanda
に送ります。
[monitor:///var/log]
disabled = false
index = fflanda
特定のイベントを別のインデックスに送る
イベントを特定のキューに送るように、特定のイベントを特定のインデックスに送ることができます。これは、イ
ンデクサー⾃体に設定します。インデクサーにデータを送信するフォワーダーではありません。
特定のイベントを特定のインデックスに送るには、インデクサー上で props.conf と transforms.conf を編集しま
す。
1. ⽬的のイベントを識別するための、共通の属性を判断します。
2. props.conf で、ソース、ソースタイプ、またはホストのスタンザを作成します。このスタンザ
は、transforms_name で作成する正規表現を含むスタンザに対応する transforms.conf を指定します。
3. transforms.conf に、ステップ 2 で指定した
は：
transforms_name
という名前のスタンザを作成します。このスタンザ
ステップ 1 で指定した属性に⼀致する正規表現を指定します。
属性に⼀致するイベントを送る代替インデックスを指定します。
以下のセクションは、ステップ 2 と 3 の詳細を記載しています。
p rop s.c onf の編集
$SPLUNK_HOME/etc/system/local/props.conf
に以下のスタンザを追加します。
13
[<spec>]
TRANSFORMS-<class_name> = <transforms_name>
以下の事項に注意してください。
は、以下のいずれかになります。
<spec>
<sourcetype>、イベントのソースタイプ
host::<host>、<host>
はイベントのホストを表します。
はイベントのソースを表します。
source::<source>、<source>
<class_name>
は、任意の⼀意の識別⼦です。
<transforms_name>
は、transforms.conf 内で変換に割り当てる任意で⼀意の識別⼦です。
tra nsform s.c onf の編集
$SPLUNK_HOME/etc/system/local/transforms.conf
に以下のスタンザを追加します。
[<transforms_name>]
REGEX = <your_custom_regex>
DEST_KEY = _MetaData:Index
FORMAT = <alternate_index_name>
以下の事項に注意してください。
<transforms_name>
は、<transforms_name> に指定されている
<your_custom_regex>
DEST_KEY
props.conf
識別⼦と⼀致する必要があります。
には、ステップ 1 で指定した属性の⼀致条件を指定します。
にはインデックス属性
<alternate_index_name>
_MetaData:Index
を指定する必要があります。
には、イベントをルーティングする代替インデックスを指定します。
例
この例では、windows_snare_log ソースタイプのイベントを、そのログタイプに基づいて適切なインデックスに送り
ます。アプリケーション (Application) ログは代替インデックスに送られます。セキュリティ (Security) などの
その他のログタイプは、デフォルトのインデックスに送られます。
このように仕分けるにためには、props.conf を使⽤します。windows_snare_log ソースタイプのイベントに対し
て、transforms.conf の AppRedirect スタンザ (「Application」ログタイプを探す正規表現を指定) を介して送り
先を指⽰します。適切な場所で「Application」に⼀致したイベントは、代替インデックス「applogindex」に送
られます。その他のイベントはすべてデフォルトのインデックスに送られます。
1 .属性の識別
この例のイベントは以下のようになります。
web1.example.com
4156
MSDTC
User
N/A
MSWinEventLog
1
Application
Information
WEB1
Printers
message: Session idle timeout over, tearing down the session.
web1.example.com
576
MSWinEventLog
Security
SYSTEM
1
User
Special privileges assigned to new logon:
ID: (0x0,0x4F3C5880)
SeDebugPrivilege
721
Wed Sep 06 17:05:31 2006
Unknown
Security
722
Success Audit
User Name:
Assigned: SeBackupPrivilege
SeChangeNotifyPrivilege
String
179
Wed Sep 06 17:59:08 2006
WEB1
Domain:
Privilege Use
Logon
SeRestorePrivilege
SeAssignPrimaryTokenPrivilege 525
⼀部のイベントには値「Application」が、他のイベントには同じ場所に値「Security」が存在しています。
2 .p rop s.c onf の編集
$SPLUNK_HOME/etc/system/local/props.conf
に以下のスタンザを追加します。
[windows_snare_syslog]
TRANSFORMS-index = AppRedirect
これは、windows_snare_syslog ソースタイプのイベントに、transforms.conf 内の
ます。
14
AppRedirect
スタンザを指⽰してい
3 .tra nsform s.c onf の編集
$SPLUNK_HOME/etc/system/local/transforms.conf
に以下のスタンザを追加します。
[AppRedirect]
REGEX = MSWinEventLog\s+\d+\s+Application
DEST_KEY = _MetaData:Index
FORMAT = applogindex
このスタンザは、props.conf によりここに誘導されたイベントを処理します。正規表現に⼀致したイベント (⽂字
列「Application」を含む) は、代替インデックス「applogindex」に送られます。その他のイベントはすべて、
通常通りにデフォルトのインデックスに送られます。
特定のインデックスのサーチ
特定のインデックスを明⽰的に指定しない限り、インデクサーはデフォルトのインデックス (デフォルトでは
main ) を対象にサーチを実施します。たとえば、以下のサーチコマンドは、hatch インデックスをサーチします。
index=hatch userid=henry.gale
また、特定のロールの作成/編集時に別のデフォルトインデックスを設定して、それに対してサーチを実⾏するこ
とも可能です。
インデックスとインデックスデータの削除
インデックス作成したデータまたはインデックス全体をインデクサーから削除できます。主なオプションを以下に
⽰します。
今後のサーチからイベントを削除する。
1 つまたは複数のインデックスからすべてのデータを削除する。
インデックス全体を削除または無効にする。
リタイアポリシーに基づいて古いデータを削除する。
注意： 削除したデータを元に戻すことはできません。ここで説明している⽅法で削除したデータを元に戻したい
場合は、適切なデータソースからデータのインデックスを再作成する必要があります。
今後のサーチからのイベントの削除
Splunk のサーチ⾔語には、将来のサーチからイベントデータを削除するための特別な演算⼦
います。delete を使⽤する前に、このセクションを注意深くお読みください。
delete
が⽤意されて
注意： リアルタイムサーチ時には delete 演算⼦を実⾏できず、到着するイベントを削除することはできません。
リアルタイムサーチ時に delete を使⽤すると、エラーメッセージが表⽰されます。
削除できるユーザーは？
演算⼦は、「delete_by_keyword」権限 を持つユーザーのみが実⾏できます。Splunk Enterprise にはデ
フォルトで、特殊ロール 「can_delete」が⽤意されており、このロールがこの権限を保有しています (他は保有し
ていません)。デフォルトで、管理者ロールにはこの権限が与えられていません。インデックスデータを削除する
際にログインする、特別なユーザーを作成しておくことをお勧めします。
delete
詳細は、『セキュリティ』マニュアルの「ロールの追加と編集」を参照してください。
削除⽅法
まず、削除対象イベントを返すサーチを実⾏します。このサーチは削除対象イベントのみを返し、その他のイベン
トは返さないことを⼊念に確認してください。確認できたら、パイプを使ってサーチ結果を delete 演算⼦に渡し
ます。
たとえば、ソース /fflanda/incoming/cheese.log からインデックス作成したイベントを削除して、今後のサーチに表
れないようにする場合は、以下の作業を⾏います。
1. 今後インデックスが作成されないように、対象のソースを無効化または削除します。
2. インデックスから、当該ソースのイベントをサーチします。
source="/fflanda/incoming/cheese.log"
3. 削除対象データが正しく返されているかどうか、結果を確認します。
4. これらのデータが⽬的の削除データだと確認できたら、パイプ⽂字を使ってサーチを
delete
に渡します。
source="/fflanda/incoming/cheese.log" | delete
その他の例については、『サーチリファレンス』マニュアルの delete 演算⼦に関する項⽬を参照してください。
注意： Windows で Splunk を実⾏する場合、例の中のスラッシュをバックスラッシュまたは円記号 (\) に置き換
15
えてください。
サーチを delete 演算⼦に渡すことにより、そのサーチから返されるすべてのイベントがマークされます。マーク
されたイベントは、今後のサーチでは返されません。サーチを実⾏して、このデータを参照できるユーザーは存在
しません (管理権限を持つユーザーを含む)。
注意： パイプ⽂字を使って delete に結果を渡してもディスクスペースが増えることはありません。データがイン
デックスから実際に削除される訳ではありません。サーチから⾒えなくなるだけです。
演算⼦はイベントのメタデータを更新することもありません。そのため、任意のメタデータサーチには引き
続きそれらのイベントが含まれますが、それらはサーチ不可能となっています。メインのすべてのインデックス
データ ダッシュボードには、削除されたソース、ホスト、またはソースタイプのイベント数が引き続き表⽰され
ます。
delete
削除操作とインデクサークラスタ
通常のインデックスレプリケーション処理では、delete 演算⼦の効果はクラスタ内のすべてのバケツコピーに素早
く伝搬されます。⼀般的には数秒から数分ほどで完了しますが、クラスタの負荷とデータ量、および delete 演算
⼦の影響を受けるバケツ数によって異なります。この伝搬されるまでの間に、すでに削除された結果をサーチが返
す可能性があります。
また、delete 操作実⾏時に、すべての結果が伝搬される前にプライマリバケツのコピーを保持するピアが停⽌する
と、⼀部の削除データが失われてしまいます。この場合、停⽌したピアのプライマリコピーが割り当て直された後
に操作を再実⾏する必要があります。
1 つまたは複数のインデックスからのデータの削除
ディスクからインデックスデータを永久に削除するには、CLI の clean コマンドを使⽤します。このコマンドは
<index_name> 引数の指定内容に応じて、1 つまたはすべてのインデックスからデータを完全に削除します。⼀般的
に clean は、すべてのデータのインデックスを再作成する前に実⾏します。
注意： クラスタインデックス上で、clean コマンドは使⽤できません。
clean コマンドの使⽤⽅法
ここでは、clean コマンドの主な使⽤⽅法について説明していきます。
clean
のヘルプを表⽰するには、以下のコマンドを⼊⼒します。
splunk help clean
すべてのインデックス からイベントデータを削除するには、以下のコマンドを⼊⼒します。
splunk clean eventdata
1 つのインデックス からイベントデータを削除するには、以下のコマンドを⼊⼒します。
splunk clean eventdata -index <index_name>
ここで、<index_name> は対象となるインデックス名を表しています。
clean
で確認のメッセージを表⽰しない場合は、-f パラメータを追加します。
重要： clean コマンドを実⾏する前には、インデクサーを停⽌する必要があります。
注意： 5.0 より前のバージョンのインデクサーでは、clean コマンドを実⾏するとインデックスの次のバケツ ID
値が 0 にリセットされました。バージョン 5.0 以降では、そのような問題がなくなりました。そこで、最新のバ
ケツ ID が 3 だった場合、clean の実⾏後、次のバケツ ID は 0 ではなく 4 になります。バケツの命名規則とバケ
ツ ID の詳細は、このマニュアルの「インデックスディレクトリの内容」を参照してください。
例
この例では、すべてのインデックスからイベントデータを削除します。
splunk stop
splunk clean eventdata
この例では、_internal インデックスからイベントデータを削除します。また、削除を確認するメッセージは表⽰
しません。
splunk stop
splunk clean eventdata -index _internal -f
16
インデックス全体の削除
インデックス全体を削除するには (それに含まれているデータのみではなくすべてを削除)、CLI コマンドの
index を使⽤します。
remove
splunk remove index <index_name>
このコマンドは、インデックスのデータディレクトリを削除し、また
削除します。
indexes.conf
からインデックスのスタンザを
このコマンドを実⾏する前に、すべての inputs.conf ファイルを参照して (インデクサーおよびインデクサーに
データを転送するフォワーダー上のファイル)、削除対象インデックスにデータを送るように指⽰しているスタン
ザがないことを確認してください。たとえば、インデックス「nogood」を削除する場合、データ⼊⼒スタンザ内
に次に属性/値のペアが指定されていないことを確認します：index=nogood。インデックスが削除されたら、以降そ
のインデックスに送信されるデータは破棄されます。
を実⾏する場合、インデクサー上の任意のデータ取り込み設定が、そのインデックスにデータを送る
ように設定されていると、警告のメッセージが表⽰されます (フォワーダー上の設定は確認されません)。以下のよ
うなメッセージが表⽰されます。
remove index
03-28-2012 23:59:22.973 -0700 WARN
IndexAdminHandler - Events from the following 3 inputs will now be discarded,
since they had targeted index=zzz:
03-28-2012 23:59:22.973 -0700 WARN
IndexAdminHandler - type: monitor, id: /home/v/syslog-avg-1000-lines
03-28-2012 23:59:22.973 -0700 WARN
IndexAdminHandler - type: monitor, id: /mnt/kickstart/internal/fermi
03-28-2012 23:59:22.973 -0700 WARN
IndexAdminHandler - type: monitor, id: /mnt/kickstart/internal/flights
の動作中に
りません。
splunkd
remove index
を実⾏することができます。コマンド実⾏完了後、splunkd を再起動する必要はあ
インデックス削除処理は⽐較的⾼速ですが、処理完了までにかかる時間はさまざまな要因によって異なります。
削除対象データの量。
同じディスク上の他のインデックスに⼤量の書き込みを⾏っているかどうか。
削除対象インデックスに⼩さな .tsidx ファイルが⼤量に存在しているかどうか。
インデックスを削除せずに無効化する
インデックスを削除しないで無効化する場合は、disable
index
CLI コマンドを使⽤します。
splunk disable index <index_name>
コマンドと違い、disable index コマンドはインデックスデータを削除しません。無効化したデータは
再び有効にすることができます (enable index コマンドを使⽤)。ただし、インデックスを無効化すると、splunkd は
そのインデックスを対象にしたデータを受け付けません。
remove index
Splunk Web でインデックスを無効化することもできます。この場合は、[設定] > [インデックス] に移動した
後、⽬的のインデックスの右側にある [無効] をクリックします。
リタイアポリシーに基づいて古いデータを削除
インデックス内のデータが指定期間を経過した場合、またはインデックスのサイズが指定値に達した場合、それは
「フローズン」状態に移⾏します。この時点で、そのデータはインデックスから削除されます。リタイアポリシー
の設定内容によっては、データを削除する前に、それをアーカイブに移動することもできます。
詳細は、このマニュアルの「リタイアおよびアーカイブポリシーの設定」を参照してください。
インデックス並列化⽤パイプラインセットの管理
インデックスの並列化はインデクサーが複数のパイプラインセットを維持することを可能とする機能です。パイプ
ラインのセットは、⽣データの取り込みから、イベント処理、イベントのディスクへの書き込みまで、⼀連のデー
タの処理を取扱います。パイプラインのセットは、「インデックス作成の仕組み」で説明する処理パイプラインの
インスタンスです。
デフォルトでは、インデクサーは単⼀のパイプラインセットを実⾏します。しかし、利⽤可能なコアおよび I/O
の両⽅に関してマシンに余裕があれば、 2つのパイプラインセットを実⾏するようにインデクサーを設定できま
す。2 つのパイプラインセットを動作させると、インデクサーのスループットが 2 倍になります。
注意： インデクサーの実際のスループット向上は、⼊⼒データの特性とその他の要因によって異なります。
加えて、⼤量データの集中的なピークが問題となる場合、インデックス並列化はピークへの対応を容易にします。
しかし、再度強調しますが、これはマシンに⼗分な容量と能⼒がある場合に限ります。
つまり、利⽤可能なマシンのリソースによって、インデックス並列化が適する典型的な使⽤事例がいくつかありま
す。
インデクサーのスループット拡張
17
データのピークの取扱
使⽤事例の理解と、ご使⽤のデプロイが複数のパイプラインセット使⽤に適しているか判断するには、『キャパシ
ティプランニング』マニュアルを参照してください。
パイプラインセット数の設定
注意： パイプラインセットの数をデフォルト設定から増やす前に、インデクサーが複数のパイプラインセットを
サポートしているか確認してください。まず、『キャパシティプランニング』マニュアルを読みます。加えて、パ
イプラインセットの数が2 つを超える場合は特に、専⾨サービス担当者にご相談ください。
パイプラインセットの数を 2 つに設定するには、server.conf の
parallelIngestionPipelines
属性を 変更します。
parallelIngestionPipelines = 2
変更内容を有効にするには、インデクサーを再起動する必要があります。
専⾨サービス担当者が勧めない限り、パイプラインセットの数は最⼤ 2 つまでにしてください。
インデクサーによる複数パイプラインセット取扱のしくみ
パイプラインセットを 2 つ実⾏すると、データの取り込み時点からイベントをディスクに書き込む時点まで、2
つの完全な処理パイプラインを得られます。パイプラインセットは、お互いに独⽴して動作し、相⼿のアクティビ
ティを把握することはありません。各パイプラインセットが個別のインデクサー 2 台により実⾏されているのと
同じような効果が得られます。
各データ⼊⼒は単⼀パイプラインに取込まれます。例えば、Â ファイルを直接取り込む場合、ファイル全体が単⼀
のパイプラインに処理されます。パイプラインはファイルのデータを共有しません。
⼊⼒データはインデクサーのどちらのパイプラインセットにも⼊⼒可能です。新しい⼊⼒の複数の（複数のパイプ
ラインセットへの）割り振りには、ラウンドロビン⽅式負荷分散が使われます。
各パイプラインはそれぞれの⼀連のホットバケツに書き込みを⾏います。
複数のパイプラインセットのインデックス設定への影響
インデックス設定はパイプラインセットを検査します。これらには、パイプライン、プロセッサ、キューに関連す
るあらゆる設定が含まれます。これらの例として、limits.conf の max_fd と maxKBps、indexes.conf の maxHotBuckets
が含まれます。
複数のパイプラインセットがある場合、これらの制限はインデクサー全体ではなく、各パイプラインセットに適⽤
されます。例えば、各パイプラインセットはそれぞれ maxHotBuckets 制限の制約を受けます。maxHotBuckets を 4 に
設定すると、各パイプラインセットは⼀度に最⼤ 4 つまでホットバケツが設定可能となります。パイプライン
セットが 2 つある場合は、インデクサーに最⼤ 8 つ設定可能です。
フォワーダーと複数のパイプラインセット
また、フォワーダーを設定して複数のパイプラインセットを実⾏できます。複数のパイプラインセットは、フォ
ワーダーのスループットを増やし、フォワーダーは複数の⼊⼒を同時に処理できます。
パイプラインを⻑時間占有する⼤きなファイルを処理する必要がある場合などで特に有⽤です。単⼀のパイプライ
ンでは、フォワーダーがその⼤きなファイルの処理を終えるまで次のファイルの処理に進めません。パイプライン
が 2 つあれば、1 つ⽬のパイプラインが⼤きなファイルの処理を⾏っている間も、2 つ⽬のパイプラインが迅速
に⼩さな⽅のファイルを取り込み、転送できます。
フォワーダーがリソースを⼗分持っているとすると、取り込むデータの特性によっては、パイプラインを 2 つ持
つフォワーダーはパイプラインが 1 つしかないフォワーダーの 2 倍の容量を転送可能です。
フォワーダーでパイプラインセットを複数使⽤する⽅法
フォワーダーに複数のパイプラインセット使⽤を有効にすると、各パイプラインがデータ⼊⼒/出⼒の両⽅を⾏い
ます。ヘビーフォワーダーの場合、各パイプラインはさらにパーシングも⾏います。
フォワーダーはラウンドロビン⽅式負荷分散を使⽤して、新しい⼊⼒をパイプラインセット全体に割り振ります。
フォワーダーは出⼒ストリームを個別に転送します。フォワーダーがロードバランシング⽤に設定されている場
合、出⼒ストリームの負荷分散は別々に⾏われます。受信インデクサーはフォワーダーから⼊ってくる各ストリー
ムを個別に、別々のフォワーダーから⼊ってきているかのように処理します。
注意： フォワーダーとインデクサーのパイプラインセットはお互いに独⽴したものです。例えば、複数のパイプ
ラインを使⽤するフォワーダーは、転送先のインデクサーのパイプラインセットが 1 つでも 2 つでも関係なく、
あらゆるインデクサーへ転送できます。フォワーダーはインデクサーのパイプライン設定はわかりませんし、それ
を判別する必要もありません。同様に、複数のパイプラインセットを持つインデクサーは、データを送ってくる
フォワーダーのパイプラインセットの数に関係なく、フォワーダーからデータを受信できます。
フォワーダーにパイプラインセットを設定
フォワーダーへのパイプラインセットの数を設定する⽅法はインデクサーに対しての設定と同様です。server.conf
の parallelIngestionPipelines 属性を使⽤します。
18
ヘビーフォワーダーには、インデクサーの場合と同様の注意が必要で、マシンは相当に余裕のあるものとします。
通常、パイプラインセットの数は 2 つまでに制限し、専⾨のサービス担当者に相談をする必要があります。
『キャパシティプランニング』マニュアルを参照してください。
ユニバーサルフォワーダーでは、単⼀のパイプラインセットでの平均コア使⽤率は 0.5 となっていますが、状況
により最⼤ 1.5 まで増加します。そのため、パイプラインセットが 2 つある場合、コア使⽤率は 1.5 から 3.0 の
間になります。ユニバーサルフォワーダーに ２つを超える、3 つ以上のパイプラインセットを設定したい場合
は、専⾨のサービス担当にまず相談してください。
インデックスの最適化
インデクサーによるデータインデックスの作成中に、splunk-optimize プロセスの 1 つまたは複数のインスタンス
が断続的に実⾏され、データサーチ時のパフォーマンスを最適化するためにインデックスファイルが結合されま
す。splunk-optimize プロセスはほんの短時間ですが、CPU を⼤幅に使⽤することがあります。splunk-optimize の
同時インスタンス数は、indexes.conf の maxConcurrentOptimizes 値を変更して減らすことができますが、⼀般的には
この作業は必要ありません。
splunk-optimize
が⼗分な頻度で実⾏されない場合は、サーチ効率が低下してしまいます。
は、ホットバケツ 上でのみ実⾏されます。⼤量のインデックス (.tsidx) がある場合は、ウォームバ
ケツで⼿動実⾏することも可能です (⼀般的には 25 以上)。splunk-optimize を実⾏するには、$SPLUNKHOME/bin に移
動して次のように⼊⼒します：a
splunk-optimize
splunk-optimize -d|--directory <bucket_directory>
には、さまざまなオプションパラメータを指定できます。利⽤できるパラメータを表⽰するには、
以下のコマンドを⼊⼒します。
splunk-optimize
splunk-optimize
バケツの詳細は、「Splunk によるインデックスの保管⽅法」を参照してください。
DMC を使⽤してインデックス作成のパフォーマンスを確認する
分散管理コンソール (DMC) を使⽤して、デプロイのほぼすべてをモニタリングできます。このトピックでは、イ
ンデックス作成のパフォーマンスを確認するコンソールダッシュボードについて説明します。
分散管理コンソールに関する最も重要な説明は、『分散管理コンソール』マニュアルにあります。
インデックス作成 のメニューには、2 種類のパフォーマンスダッシュボードが存在します。
インデックス作成のパフォーマンス：インスタンス
インデックス作成のパフォーマンス：デプロイ
名称の通り、類似の情報を提供しますが、範囲は単⼀のインスタンスまたはデプロイ全体と異なります。
パフォーマンスダッシュボードは、インデックス作成処理に関する次のような幅広い情報を提供します。
インデックス作成レート
キューのフィルレシオ
データパイプラインの様々な部分の CPU 情報
詳細はダッシュボードを確認してください。また、『分散管理コンソール』マニュアルの「インデックス作成のパ
フォーマンス：インスタンス」と「インデックス作成のパフォーマンス：デプロイ」を参照してください。
インデックスストレージの管理
インデクサーによるインデックスの保管⽅法
インデクサーがデータのインデックスを作成する際には、多数のファイルが作成されます。これらのファイルに
は、2 種類のデータが含まれています。
圧縮形式の raw データ (rawdata )
raw データを指すインデックスといくつかのメタデータファイル (インデックスファイル )
Splunk Enterprise のインデックス は、これらのファイルにより構成されています。⼀連のディレクトリに保管
されているファイルは、その経過時間で管理されています。⼀部のディレクトリには、新たに作成されたインデッ
クスデータが含まれています。他のディレクトリには、以前に作成されたインデックスデータが含まれています。
このようなディレクトリ数は、インデックスを作成するデータ量に応じて、とても⼤きくなる場合があります。
注意事項
実際にはさほど気にする必要はありません。インデクサーはデフォルトで、インデックスデータをさまざまな段階
を経て管理、処理します。⼀般的に数年後など、⻑期間の経過後には、インデクサーは古いデータをシステムから
削除します。デフォルトのスキーマでも⼗分に役⽴ちます。
19
ただし、⼤量のデータのインデックスを作成する、特別なデータ保持要件がある、またはその他経過時間に関する
ポリシーを⼊念に検討する必要があるような場合は、このトピックを参考にしてください。また、データをバック
アップするような場合にも、どこにデータがあるのかを理解するためにこの記事が役⽴ちます。どうぞご⼀読くだ
さい。
データの時間経過
各インデックスディレクトリは、バケツ と呼ばれています。現在まで学習したことをまとめると：
インデックスには、圧縮された raw データと関連するインデックスファイルが含まれている。
インデックスは、多数の経過時間が指定されたインデックスディレクトリにまたがって存在している。
インデックスディレクトリはバケツと呼ばれます。
バケツはその経過時間の経過に伴い、さまざまなステージに移⾏します。
ホット
ウォーム
コールド
フローズン
解凍
バケツは、その経過時間が経過するにつれて、あるステージから別のステージへと移⾏していきます。データのイ
ンデックスが作成されると、ホットバケツに格納されます。ホットバケツはサーチ可能で、積極的に書き込みが⾏
われます。インデックスは⼀度にホットバケツを複数開くことができます。
特定の条件においては (例えば、ホットバケツが特定のサイズに達するか splunkd が再起動した時)、ホットバケツ
はウォームバケツ (「ウォームに移⾏」) になり、新しいホットバケツが代わりに作成されます。ウォームバケツ
はサーチ可能ですが、積極的には書き込まれません。ウォームバケツは多数存在しています。
さらに条件が重なると (例えば、ウォームバケツの最⼤数に達する場合）、バケツの経過時間に基づいてウォーム
バケツからコールドバケツへの移⾏が開始されます。常に⼀番古いウォームバケツが選択され、コールドバケツに
移⾏されます。バケツはこのようにして、時間の経過に伴い順次コールドバケツに移⾏していきます。設定されて
いる期間が経過すると、コールドバケツはフローズンバケツに移⾏します。この時点でバケツはアーカイブまたは
削除されます。indexes.conf 内の属性を編集することで、バケツの経過時間ポリシーを指定することができま
す。このポリシーは、バケツのあるステージから次のステージへの移⾏時期を⽰します。
フローズンデータがアーカイブされても、後ほど解凍できます。解凍されたデータはサーチに利⽤可能です。
バケツが移⾏する各ステージを以下に⽰します。
バケツの
ステージ
ホット
説明
サーチ可能？
新たにインデックスが作成されたデータを保管し
ています。書き込み可能。各インデックスに対し はい
て 1 つまたは複数のホットバケツ。
ホットから移⾏されたデータ。ウォームバケツは
ウォーム 多数存在しています。ウォームバケツにはデータ はい
の積極的な書き込みはありません。
コールド ウォームから移⾏されたデータ。コールドバケツ はい
は多数存在しています。
コールドから移⾏されたデータ。デフォルトで
フローズ は、フローズンデータは削除されますが、代わり
いいえ
ン
にアーカイブすることも選択可能です。アーカイ
ブされたデータは、後ほど解凍できます。
解凍
データはアーカイブから戻されます。フローズン
データをアーカイブした場合、解凍によりフロー
はい
ズンデータをインデックスに戻すことができま
す。
特定のステージ内のバケツの集合体は、データベースまたは「db」として表されることがあります。たとえば、
「ホット db」、「ウォーム db」、「コールド db」などのように表されます。
インデックスディレクトリの内容
各インデックスは、$SPLUNK_HOME/var/lib/splunk 下の独⾃のディレクトリに保管されます。ディレクトリ名は、イ
ンデックス名と同じです。インデックスディレクトリ下には、バケツをステージ別 (ホット/ウォーム、コール
ド、解凍) に分類する⼀連のサブディレクトリがあります。
バケツ⾃体が、それらのディレクトリのサブディレクトリになります。バケツのディレクトリ名は、データの経過
時間に基づいています。
デフォルト・インデックス (defaultdb) のディレクトリ構造を以下に⽰します。
バケツ
のス
テージ
ホット
デフォルトの場所
$SPLUNK_HOME/var/lib/splunk/defaultdb/db/*
メモ
ホットバケツにそれぞれ 1 つずつ、複数のホットサブ
ディレクトリを設定することができます。「バケツの
20
命名規則」を参照してください。
ウォー
ム
$SPLUNK_HOME/var/lib/splunk/defaultdb/db/*
各ウォームバケツ個別のサブディレクトリが存在して
います。「バケツの命名規則」を参照してください。
コール
ド
$SPLUNK_HOME/var/lib/splunk/defaultdb/colddb/*
複数のコールドサブディレクトリが存在しています。
ウォームバケツがコールドに移⾏されると、データは
このディレクトリに移動されますが名前は変更されま
せん。
デフォルトでは削除されます。代わりにデータをアー
フロー N/A：フローズンデータは、削除されるか、
または指定のディレクトリにアーカイブされま カイブする⽅法については、「インデックスデータの
ズン
す。
アーカイブ」を参照してください。
解凍
$SPLUNK_HOME/var/lib/splunk/defaultdb/thaweddb/*
アーカイブされて、後ほど解凍されたデータの場所。
アーカイブされたデータの解凍状態への復元について
は、「アーカイブされたデータの復元」を参照してく
ださい。
ホット/ウォーム、コールド、および復元⽤ディレクトリへのパスは変更することができます。たとえば、コール
ドバケツをホット/ウォーム・バケツとは個別の場所に保管することができます。「インデックスストレージの設
定」および「インデックスデータへの複数パーティションの使⽤」を参照してください。
重要： すべてのインデックス保管場所は書き込み可能でなければなりません。
注意： 6.0 より前のバージョンの Splunk Enterprise では、複製されたクラスタバケツのコピーは、それがホッ
トバケツでもウォームバケツでも常に colddb ディレクトリに保管されます。6.0 以降では、ホットバケツとウォー
ムバケツのコピーは、⾮複製コピーと同じ db ディレクトリに保管されます。
バケツの命名規則
バケツの命名は次に従います。
バケツのステージ：ホット、ウォーム、コールド、解凍
バケツディレクトリの種類：⾮クラスタ、元クラスタまたは複製クラスタ
重要： バケツの命名規則は変更される可能性があります。
⾮クラスタバケツ
スタンドアロン型インデクサーは⾮クラスタバケツを⽣成します。これらは、命名規則の種類の 1 つです。
クラスタバケツ
インデクサークラスタ の⼀部であるインデクサーはクラスタバケツを⽣成します。クラスタバケツは複数のコ
ピーがあります。クラスタバケツの命名規則はコピー、元、複製の種類を区別します。
簡潔に、インデクサークラスタのバケツは複製データ保持数 に従い複数のコピーを所有します。データがクラス
タに⼊り込むと、受信インデクサーはデータをホットバケツに書き込みます。この受信インデクサーをソースクラ
スタピア と呼び、また、データが書き込まれるバケツはバケツの元コピーと呼ばれます。
データがホットコピーに書き込まれると、ソースピアがホットデータのコピーをまとめてクラスタの別のインデク
サーに流します。これらのインデクサーはバケツのターゲットピアとして参照します。ターゲットピア上のスト
リームデータのコピーをバケツの複製コピーと呼びます。
ソースピアが⽣成したホットバケツをウォームに移⾏すると、ターゲットピアはそのバケツの複製コピーを移⾏し
ます。ウォームコピーは各々の複製コピーです。
インデクサークラスタのアーキテクチャと複製されたデータの転送の概要は、「インデクサー・クラスタ・アーキ
テクチャの基礎」を参照してください。
バケツ名
バケツには命名規則があります。
バケツタイプ
ホットバケツ
ウォーム/コールド/解凍バケツ
⾮クラスタ
hot_v1_<localid>
db_<newest_time>_<oldest_time>_<localid>
クラスタオリジナル
hot_v1_<localid>
db_<newest_time>_<oldest_time>_<localid>_<guid>
クラスタ複製
<localid>_<guid>
rb_<newest_time>_<oldest_time>_<localid>_<guid>
注意：
および <oldest_time> は、バケツに保管されているデータの経過時間を表すタイムスタンプで
す。タイムスタンプは、UTC エポック時 (秒) で表されています。例： db_1223658000_1223654401_2835 は、
2008 年 10 ⽉ 10 ⽇からの期間が午前 9 時〜午前 10 時のデータを含む、⾮クラスタウォームバケツで
す。
<localid> は、バケツの ID です。クラスタバケツは、バケツの元および複製コピーに、同じ <localid> があ
ります。
<guid> は、ソースピアノードの guid です。guid はピアの $SPLUNK_HOME/etc/instance.cfg ファイルにありま
<newest_time>
21
す。
インデクサークラスタ内で、元のウォームバケツと複製されたコピーは同じ名前を持ちますが、プリフィックスが
異なっています (元のバケツは db、複製されたコピーは rb)。
注意： インデクサークラスタ内で、データがソースピアからターゲットピアに転送される場合、データはまず
ターゲットピアの⼀時ディレクトリに保管されます。このディレクトリは、<localid>_<guid> ホットバケツ規則で
⽰されます。これは、ストリームバケツがホットバケツかに関係なく、あらゆる複製バケツのコピーに適⽤されま
す。例えば、バケツの調整アクティビティ時に、ピアはウォームバケツを他のピアに転送する場合があります。複
製が完了したら、<localid>_<guid> ディレクトリがウォームバケツディレクトリに移⾏され、プリフィックス rb_
が付けられます。
バケツと Splunk Enterprise の管理
Splunk Enterprise を管理する際には、インデクサーがバケツにどのようにインデックスを保管するのかを理解し
ておくと役⽴ちます。特に、さまざまな管理作業を⾏うためには、バケツを正しく理解しておく必要があります。
リタイアおよびアーカイブポリシーの設定⽅法については、「リタイアおよびアーカイブポリシーの設定」
を参照してください。リタイアポリシーは、データのサイズまたは経過時間に基づいて設定できます。
インデックスデータのアーカイブ⽅法の詳細は、「インデックスデータのアーカイブ」を参照してくださ
い。アーカイブからのデータの復元⽅法については、「アーカイブされたインデックスデータの復元」を参
照してください。
データのバックアップ⽅法については、「インデックス作成されたデータのバックアップ」を参照してくだ
さい。このトピックでは、バックアップできるようにするため、⼿動によるホットバケツからウォームバケ
ツへの移⾏⽅法についても説明されています。また、Community Wiki の「Best practices for backing
up」も参照してください。
ディスク使⽤量の制限値の設定については、「ディスク使⽤量の制限の設定」を参照してください。
バケツの設定項⽬の⼀覧については、「インデックスストレージの設定」を参照してください。
インデックスサイズの設定については、「インデックスサイズの設定」を参照してください。
インデックスデータの分割については、「インデックスデータ⽤の複数パーティションの使⽤」を参照して
ください。
インデックスクラスタのバケツ機能については、「バケツとインデクサークラスタ」を参照してください。
また、『管理』マニュアルの「indexes.conf」およびコミュニティ Wiki の「バケツについて」も参照してくださ
い。
インデックスストレージの設定
インデックスは、indexes.conf で設定します。indexes.conf の編集⽅法は、インデックスレプリケーション (イン
デクサークラスタリング) を使⽤しているかどうかによって異なります。
クラスタ化されていないインデックスの場合 、$SPLUNK_HOME/etc/system/local/ 内または
$SPLUNK_HOME/etc/apps/ 内のカスタム App ディレクトリ内の indexes.conf のコピーを編集しま
す。$SPLUNK_HOME/etc/system/default 内のコピーは編集しないでください。設定ファイルとディレクトリの場
所については、「設定ファイルについて」を参照してください。
クラスタ化インデックスの場合 、クラスタのマスターノード上の indexes.conf のコピーを編集し、次にそ
れをすべてのピアノードに配布します (「インデクサークラスタ内のピアインデックスの設定」を参照)。
この表には、バケツ に影響する主な indexes.conf 属性とその設定が記載されています。また、これらの属性の使⽤
⽅法を表しているトピックへのリンクも記載されています。他も含めて、これらの属性の詳細情報の⼤半は、常に
indexes.conf ファイルを参照します。
属性
設定内容
デフォルト
ホットおよびウォームバケツ
を保管しているパス。(必
須。 )
homePath
この場所は書き込み可能でな
ければなりません。
コールドバケツを保管するパ
ス。(必須。 )
coldPath
この場所は書き込み可能でな
ければなりません。
解凍されたバケツを保管する
パス。(必須。 )
thawedPath
この場所は書き込み可能でな
22
詳細は、以下
の項⽬を参
照...
インデックス
データ⽤の複
(デフォルトのイ 数パーティ
ンデックスのみ)
ションの使⽤
$SPLUNK_HOME/var/lib/splunk/
defaultdb/db/
$SPLUNK_HOME/var/lib/splunk/
(デフォルト
のインデックスのみ)
defaultdb/colddb/
$SPLUNK_HOME/var/lib/splunk/
defaultdb/thaweddb/
(デフォル
インデックス
データ⽤の複
数パーティ
ションの使⽤
インデックス
データ⽤の複
数パーティ
この場所は書き込み可能でな
ければなりません。
トのインデックスのみ)
数パーティ
ションの使⽤
repFactor
インデックスを他のクラスタ
ピアに複製するかどうかを指
定します。(クラスタピア
ノード上のインデックスに
対して必須。 )
0 (インデックスは他のピアに
複製されない、⾮クラスタイ
ンデックスの場合の正しい動
作)。クラスタ化インデックス
の場合は、インデックスを複
製するために repFactor に
auto を設定する必要がありま
す。
インデクサー
クラスタ内の
ピアインデッ
クスの設定
maxHotBuckets
ホットバケツの最⼤数。アー
カイブデータを処理するため
に、この値には 2 以上を設定
する必要があります。たとえ
ば、デフォルトの main イン
デックスの場合、これに 10
が設定されています。
新しいカスタムインデックス
の場合は、3 になります。
データの時間
経過
maxDataSize
ホットからウォームへの移
⾏動作を決定します。 ホッ
トバケツの最⼤サイズ。ホッ
トバケツがこのサイズに達す
ると、ウォームに移⾏しま
す。この属性は、すべてのバ
ケツの概算サイズも決定しま
す。
状況により異なります。
indexes.conf を参照。
maxWarmDBCount
ウォームからコールドへの
移⾏動作を決定しま
す。 ウォームバケツの最⼤
数。ウォームバケツが最⼤数
に達すると、コールドへの移
⾏が開始されます。
300
インデックス
データ⽤の複
数パーティ
ションの使⽤
maxTotalDataSizeMB
コールドからフローズンへ
の移⾏動作を決定しま
す。 インデックスの最⼤サイ
ズ。この限度に達すると、
コールドバケツのフローズン
への移⾏が開始されます。
500000 (MB)
リタイアおよ
びアーカイブ
ポリシーの設
定
frozenTimePeriodInSecs
コールドからフローズンへ
の移⾏動作を決定しま
す。 フローズンに移⾏してか
らの、バケツの最⼤経過時
間。
188697600 (秒、約 6 年)
リタイアおよ
びアーカイブ
ポリシーの設
定
この属性または
coldToFrozenDir
アーカイブしたデータの保管
場所。バケツがコールドから
フローズンに移⾏した時の動
作を決定します。設定した場
合、フローズンバケツをイン
デックスから削除する直前
に、そのバケツをこのディレ
クトリにアーカイブします。
のどちらも
設定しない場合、バケツがフ
ローズンに移⾏されると、バ
ケツのディレクトリ名のみが
ログに記録され、バケツは削
除されます。
インデックス
作成された
データのアー
カイブ
coldToFrozenScript
コールドバケツをフローズン
バケツに移⾏する直前に実⾏
するスクリプト。この属性と
coldToFrozenDir の両⽅を設定
した場合、coldToFrozenDir が
使⽤され、この属性は無視さ
れます。
この属性または
coldToFrozenDir のどちらも設
定しない場合、バケツがフ
ローズンに移⾏されると、バ
ケツのディレクトリ名のみが
ログに記録され、バケツは削
除されます。
インデックス
作成された
データのアー
カイブ
(ホット/ウォームバ
ケツストレージ) または
homePath.maxDataSizeMB coldPath (コールドバケツスト
レージ) の最⼤サイズ。どち
coldPath.maxDataSizeMB らかの属性が存在しない、ま
たは 0 が設定されている場
合、そのパスはサイズによる
制約を受けません。
なし
バケツタイプ
によるイン
デックスサイ
ズの設定
ボリュームの最⼤サイズ。属
性が指定されていない場合、
個別のボリュームのサイズに
制約はありません。
なし
ボリュームに
よるインデッ
クスサイズの
設定
インデックス
データ⽤の複
数パーティ
ションの使⽤
coldToFrozenScript
リタイアおよ
びアーカイブ
ポリシーの設
定
homePath
maxVolumeDataSizeMB
注意： ⾮クラスタインデックスの場合のみ、Splunk Web を使ってインデックスへのパスを設定することができ
ます。[設定] > [システム設定] > [全般設定] に移動してください。[インデックス設定] で、[インデックスへ
のパス] フィールドを設定します。この作業を⾏った後は、CLI からインデクサーを再起動する必要があります
(Splunk Web からではない)。
23
インデックスデータベースの移動
インデックスデータベース全体を、ある場所から別の場所に移動できます。ここでは、そのための⼿順について説
明していきます。この⼿順では、インデックスデータベースがインストール時に作成されるデフォルトの場所に存
在していることを前提にしています。
個別のインデックスまたはインデックスの⼀部を別の場所に移動することも可能です。いったん移動すると、その
後の移動操作はここで説明している⼿順とは異なります。Splunk Enterprise インデックスの構造の詳細は、「イ
ンデクサーによるインデックスの保管⽅法」を参照してください。単⼀のインデックスの場所の変更⽅法について
は、「インデックスストレージの設定」を参照してください。
*nix ユーザーの場合
1. ターゲットファイルシステムに⼗分なスペースがあることを確認してください。最低でもインデックス作成の対
象となる raw データの合計サイズの 1.2 倍以上のスペースが必要です。
2. ターゲットディレクトリを作成し、それに対して Splunk Enterprise が実⾏するユーザーに対する書き込み権
限があることを確認してください。たとえば、Splunk Enterprise がユーザー「splunk」として実⾏される場
合、そのユーザーにディレクトリの所有権を与えてください。
mkdir /foo/bar
chown splunk /foo/bar/
Splunk Enterprise を実⾏するユーザーの設定については、このトピックを参照してください。
3. 新しいインデックスホームの準備が完了したら、インデクサーを停⽌します。$SPLUNK_HOME/bin/ ディレクトリに
移動して、以下のコマンドを実⾏します。
splunk stop
4. 既存のインデックスファイルシステムを新しいホームにコピーします。
cp -rp $SPLUNK_DB/* /foo/bar/
5. SPLUNK_DB 環境変数の設定を解除します。
unset SPLUNK_DB
6. 新しいインデックスディレクトリを反映するように、$SPLUNK_HOME/etc/splunk-launch.conf を編集します。この
ファイルの SPLUNK_DB 属性を、新たなインデックスディレクトリを指すように変更します。
SPLUNK_DB=/foo/bar
7. インデクサーを開始します。$SPLUNK_HOME/bin/ に移動して、以下のコマンドを実⾏します。
splunk start
インデクサーは新しいインデックスのコピーの読み込み、書き込みを⾏う場所を認識します。
8. インデクサーが新しい場所から読み取り/書き込みできることを確認したら、古いインデックスデータベースを
削除することができます。
Windows ユーザーの場合
1. ターゲットドライブまたはディレクトリに⼗分な利⽤可能スペースがあることを確認します。
注意： インデックスの保管場所としてマップされているネットワーク・ドライブを使⽤することは絶対にお勧め
できませんし、サポートもされていません。
2. コマンドプロンプトから、ターゲットドライブに移動して、ターゲットドライブ内のファイルに
スが書き込めるように、正しく権限が設定されていることを確認します。
splunkd
プロセ
C:\Program Files\Splunk> D:
D:\> mkdir \new\path\for\index
D:\> cacls D:\new\path\for\index /T /E /G <the user Splunk Enterprise runs as>:F
Splunk Enterprise を実⾏するユーザーについては、Windows への Splunk のインストールに関するトピックを
参照してください。
注意： Windows Vista、7、Server 2003、および Server 2008 ユーザーは、icacls を使ってディレクトリ権限
が正しいか確認できます。Microsoft TechNet の記事に、特定のコマンドライン引数に関する情報が記載されて
24
います。
3. インデクサーを停⽌します。%SPLUNK_HOME%\bin ディレクトリに移動して、以下のコマンドを実⾏します。
splunk stop
注意： コントロールパネルの [サービス] を使⽤して、splunkd および
す。
splunkweb
サービスを停⽌することもできま
4. 既存のインデックスファイルシステムを新しいホームにコピーします。
xcopy "C:\Program Files\Splunk\var\lib\splunk\*.*" D:\new\path\for\index /s /e /v /o /k
5. SPLUNK_DB 環境変数の設定を解除します。
set SPLUNK_DB=
6. 新しいインデックスディレクトリを反映するように、%SPLUNK_HOME%\etc\splunk-launch.conf を編集します。この
ファイルの SPLUNK_DB 属性を、新たなインデックスディレクトリを指すように変更します。
SPLUNK_DB=D:\new\path\for\index
注意： 設定ファイル内の SPLUNK_DB 属性を含む⾏の先頭にシャープ記号 (#) がある場合、その⾏は注釈⾏として取
り扱われているため、# を削除する必要があります。
7. インデクサーを開始します。%SPLUNK_HOME%\bin ディレクトリに移動して、以下のコマンドを実⾏します。
splunk start
インデクサーは新しいインデックスのコピーの読み込み、書き込みを⾏う場所を認識します。
8. インデクサーが新しい場所から読み取り/書き込みできることを確認したら、古いインデックスデータベースを
削除することができます。
Splunk Web を使ったインデックスへのパスの変更
Splunk Web を使って、インデックスへのパスを変更することができます。インデックスを実際に移動する前に
説明した⼿続きとは異なり、Splunk Web でパスを変更した場合、その変更は新たにインデックスに到着した
データにのみ適⽤されます。そのため、このような⽬的で Splunk Web を使⽤することは、データの取り込みを
開始する前の新しいインデクサーにのみ限定することをお勧めします。
パスを変更するには：
1. [設定 ] > [サーバー設定 ] > [全般設定 ] と選択して移動します。
2. このページの [インデックス設定] にある [インデックスへのパス] フィールドに移動します。
3. このフィールドに新しいパスを⼊⼒します。ここに、新たなインデックスデータが保管されます。
4. ご利⽤の環境で
SPLUNK_DB
環境変数が設定されている場合は、その設定を解除します。
*nix の場合、コマンドラインから以下のコマンドを⼊⼒します。
unset SPLUNK_DB
Windows の場合、コマンドラインから以下のコマンドを⼊⼒します。
set SPLUNK_DB=
5. CLI を使ってインデクサーを再起動します。$SPLUNK_HOME/bin/ (*nix) または
して、以下のコマンドを実⾏します。
%SPLUNK_HOME%\bin
(Windows) に移動
splunk restart
重要： Splunk Web 内で再起動機能を使⽤しないでください。これには、⽬的としているインデックスディレク
トリを変更する効果はありません。CLI から再起動する必要があります。
インデックスデータ⽤の複数パーティションの使⽤
インデクサーは、インデックスデータ⽤に複数のディスクおよびパーティションを利⽤できます。複数のインデッ
クスやバケツ タイプに基づいて、多数のディスク/パーティション/ファイルシステムを使⽤するように設定する
25
ことができます。ただし、それらを正しくマウントして、indexes.conf からそれらを正しく指すように設定する必
要があります。しかし、最良の結果を得るためには、単⼀の⾼性能ファイルシステムを使ってインデックスデータ
を保持/管理することをお勧めします。
複数のパーティションを使⽤する場合、インデックスデータを配置するもっとも⼀般的な⽅法は、ローカルマシン
上にホット/ウォームバケツを保持し、コールドバケツを別個のディスクアレイに格納することです (⻑期保存
⽤)。⾼速な読み取り/書き込みパーティションを持つマシン上にホット/ウォームバケツを配置することをお勧め
します。⼤半のサーチはここで⾏われます。コールドバケツは、信頼性の⾼いディスクアレイに配置してくださ
い。
複数のパーティションの設定
複数のパーティションを設定するには：
1. 普段 OS で設定しているように、パーティションを設定します。
2. ディスク/パーティションをマウントします。
3. パーティションの正しいパスを指すように、indexes.conf を編集します。パスはインデックス単位で設定しま
す。そのため、インデックスごとに個別のパーティションを設定することができます。各インデックスには、独⾃
の [<index>] スタンザが存在し、<index> がインデックス名となっています。これらは、設定可能なパス属性です。
homePath = <path on server>
これは、インデックスのホットおよびウォームデータベースを含むパスです。
注意： パスは書き込み可能でなければなりません。
coldPath = <path on server>
これは、インデックスのコールドデータベースを含むパスです。
注意： パスは書き込み可能でなければなりません。
thawedPath = <path on server>
これは、インデックスの解凍されたデータベースを含むパスです。
インデックスサイズの設定
インデックスストレージサイズは、さまざまな⽅法で設定できます。
インデックス単位
ホット/ウォームバケツ ⽤とコールドバケツ⽤を個別に
ボリュームを使ってインデックス間にまたがって
インデックスストレージサイズを設定するには、indexes.conf に属性を設定します。このトピックで取り上げた
属性の詳細は、「インデックスストレージの設定」を参照してください。
注意： インデックスの処理中には、短時間ですが設定されている最⼤値を超える場合があります。制限を設定す
る際には、いくらかのバッファ領域を確保するようにしてください。また、⼤部分の UNIX システムなど特定の
システムでは、そのパーティション上に設定可能な予約スペースが維持されていることに注意してください。イン
デックスサイズを決定する際には、そのような予約スペースも考慮する必要があります。
各インデックスのインデックスサイズの設定
インデックス単位に最⼤インデックスサイズを設定するには、maxTotalDataSizeMB 属性を使⽤します。この限度に
達すると、バケツのフローズンへの移⾏が開始されます。
バケツタイプによるインデックスサイズの設定
(ホット/ウォームバケツストレージ) または
るには、maxDataSizeMB 属性を使⽤します。
homePath
coldPath
(コールドバケツストレージ) の最⼤サイズを設定す
# set hot/warm storage to 10,000MB
homePath.maxDataSizeMB = 10000
# set cold storage to 5,000MB
coldPath.maxDataSizeMB = 5000
属性はグローバルに、または各インデックスに対して設定できます。インデックスレベルの設定は、
グローバル設定に優先します。インデックスのグループにまたがってバケツストレージを設定するには、後述の
maxVolumeDataSizeMB 属性を使⽤します。
maxDataSizeMB
ボリュームによるインデックスサイズの設定
ボリュームを作成して、最⼤データサイズを設定することにより、複数のインデックスにまたがってディスク使⽤
量を管理できます。ボリュームは、インデックス作成したデータを保管するファイルシステム内のディレクトリを
表します。
ボリュームには、複数のインデックスからのデータを保管できます。⼀般的には、ホット/ウォームバケツ⽤と
コールドバケツ⽤に個別のボリュームを使⽤します。たとえば、あるボリュームにすべてのインデックス⽤のホッ
ト/ウォームバケツを格納し、別のボリュームにはコールドバケツを格納するように設定できます。
26
ボリュームを使って
とはできません。
homePath
および
coldPath
を定義することができます。これを使って
thawedPath
を定義するこ
また、bloomHomePath を明⽰的に定義する場合は、ボリュームを使⽤する必要があります。bloomHomePath の詳細は、
このマニュアルの「ブルームフィルタの設定」を参照してください。
ボリュームの設定
ボリュームを設定するには、以下の構⽂を使⽤します。
[volume:<volume_name>]
path = <pathname_for_volume>
必要に応じて、ボリュームの最⼤サイズを指定する
maxVolumeDataSizeMB
属性を⼊れることもできます。
例：
[volume:hot1]
path = /mnt/fast_disk
maxVolumeDataSizeMB = 100000
この例では、/mnt/fast_disk にあるボリューム「hot1」に最⼤サイズ 100,000 MB を割り当てています。
同様に、以下のスタンザは最⼤ 150,000 MB を使⽤するボリューム「cold1」を定義しています。
[volume:cold1]
path = /mnt/big_disk
maxVolumeDataSizeMB = 150000
ボリュームの使⽤
これで、インデックスの homePath および coldPath をボリュームで定義できるようになりました。たとえば、上記
で定義したボリュームを使って、以下の 2 つのインデックスを定義できます。
[idx1]
homePath = volume:hot1/idx1
coldPath = volume:cold1/idx1
[idx2]
homePath = volume:hot1/idx2
coldPath = volume:cold1/idx2
ボリュームを使って、⾃分のニーズに合わせてインデックスストレージスペースを管理できます。ただし、⼀般的
にボリュームは、ホット/ウォームおよびコールドバケツと相関しています。処理するバケツタイプによって、ス
トレージ要件も異なります。そのため、通常は⼀部のボリュームを homePath (ホット/ウォームバケツ) 専⽤として
指定し、coldPath (コールドバケツ) ⽤も別途指定します。
ウォームバケツを保管するボリュームが maxVolumeDataSizeMB に達すると、コールドへの移⾏が開始されます。コー
ルドバケツを保管するボリュームが maxVolumeDataSizeMB に達すると、フローズンへの移⾏が開始されます。ボ
リュームにウォームバケツとコールドバケツの両⽅が存在している場合は (インデックスの homePath と coldPath の
両⽅に同じボリュームが設定された場合)、もっとも古いバケツがフローズンに移⾏されます。
すべてをまとめる
この例では、インデックス単位の homePath.maxDataSizeMB および coldPath.maxDataSizeMB 属性とボリュームを使⽤し
た、インデックスストレージのきめ細かい管理⽅法について説明していきます。特に、あるインデックスへのデー
タの集中により、他のインデックスからの頻繁なバケツ移動の発⽣を防⽌することを重視しています。インデック
ス単位の設定は、負荷を減らすためにどのインデックスも指定サイズを超えてスペースを専有しないようにするこ
とを⽬的にしています。
# global settings
# Inheritable by all indexes: no hot/warm bucket can exceed 1 TB.
# Individual indexes can override this setting.
homePath.maxDataSizeMB = 1000000
# volumes
[volume:caliente]
path = /mnt/fast_disk
maxVolumeDataSizeMB = 100000
27
[volume:frio]
path = /mnt/big_disk
maxVolumeDataSizeMB = 1000000
# indexes
[i1]
homePath = volume:caliente/i1
# homePath.maxDataSizeMB is inherited from the global setting
coldPath = volume:frio/i1
# coldPath.maxDataSizeMB not specified anywhere:
# This results in no size limit - old-style behavior
[i2]
homePath = volume:caliente/i2
homePath.maxDataSizeMB = 1000
# overrides the global default
coldPath = volume:frio/i2
coldPath.maxDataSizeMB = 10000
# limits the size of cold buckets
[i3]
homePath = /old/style/path
homePath.maxDataSizeMB = 1000
coldPath = volume:frio/i3
coldPath.maxDataSizeMB = 10000
ディスク使⽤量の制限の設定
Splunk Enterprise はさまざまな⽅法でディスクスペースを制御しています。インデックスは、ディスクスペース
の⼤半を消費します。ディスクスペースが不⾜すると、インデックスの作成が停⽌されます。最低空きスペースの
制限値を設定して、インデックスの作成を停⽌するまでの空きディスクスペース量を制御することができます。空
きスペース量が制限値以上に回復すると、インデックスの作成が再開されます。
注意： インデックスに必要なスペース量を判断するには、『キャパシティプランニング』マニュアルの「スト
レージ要件の⾒積もり」を参照してください。
最低空きディスクスペースの設定
インデックスデータを保管するディスクの最低空きディスクスペース量を設定できます。制限値に達すると、イン
デクサーは動作を停⽌します。これはインデックスとサーチの両⽅に影響します。
インデクサーは定期的に、インデックスを保管しているすべてのパーティションの空きスペースをチェック
します。いずれかのパーティションで空きディスクスペース制限値に達すると、その値より多くのスペース
が利⽤できるようになるまでの間、データのインデックス作成が中⽌されます。ディスクスペースを確保す
る必要があることを知らせる、UI バナーおよび splunkd 警告が表⽰されます。
サーチを実⾏する前に、ディスパッチディレクトリが保管されている次のファイルシステム上で、指定され
た量の空きディスクを確保する必要があります： $SPLUNK_HOME/var/run/splunk/dispatch
デフォルトの最低空きディスクスペース量は 5,000MB です。
注意：
この⽅法では、インデクサーがデータの消去によりディスクスペースを確保することはありません。単によ
り多くの空きスペースが確保されるまで、処理を停⽌します。
インデックスの作成が停⽌中に到着したデータは失われる可能性があります。
最低空きディスクスペース量は、Splunk Web、CLI、または
きます。
server.conf
設定ファイルを使って設定することがで
Splunk Web
Splunk Web で最低空きディスクスペースを指定するには：
1. Splunk Web の右上にある [設定] をクリックします。
2. [サーバー設定 ] をクリックします。
3. [全般設定] をクリックします。
4. [インデックス設定] セクションで、[空きディスクスペースがこの値 (MB) を下回ったらインデックスの作
成を⼀時停⽌] フィールドを設定します。
28
5. 最低空きディスクスペース量をメガバイトで⼊⼒します。
6. [保存 ] をクリックします。
7. 変更内容を有効にするために、インデクサーを再起動します。
コマンドラインインターフェイス (CLI) の使⽤
CLI を使って最低空きディスクスペース量を設定することができます。この例では、最低空きディスクスペースと
して 20,000 MB (20 GB) を設定します。
splunk set minfreemb 20000
splunk restart
CLI の使⽤⽅法の詳細は、『管理』マニュアルの「CLI について」を参照してください。
server.conf
server.conf ファイルに最低空きディスクスペースを設定することもできます。関連するスタンザ/属性を以下に⽰
します。
[diskUsage]
minFreeSpace = <num>
<num>
はメガバイトです。デフォルトは 5000 です。
インデックスストレージの制御
indexes.conf ファイルには、インデックス設定が含まれています。最⼤インデックスサイズやデータの最⼤経過
時間などを指定して、ディスクストレージの使⽤を調整することができます。これらのいずれかの制限値に達する
と、もっとも古いインデックスデータが削除 (デフォルト) またはアーカイブされます。事前定義されているアー
カイブスクリプトを使⽤または独⾃のスクリプトを作成して、データをアーカイブすることができます。
を使った最⼤インデックスサイズまたは経過時間の設定⽅法については、「リタイアおよびアーカイ
ブポリシーの設定」を参照してください。
indexes.conf
インデックスストレージの詳細は、「インデクサーによるインデックス保管⽅法」を参照してください。
ブルームフィルタの設定
ここでは、ブルームフィルタの概要およびそれを使ったパフォーマンス改善 (特にまれな単語をサーチする場合)
について説明していきます。
このトピックを読む前に、インデックス作成後のデータの保管⽅法およびデータの経過時間について理解しておく
必要があります。基本的に、インデックス作成されたデータはバケツ と呼ばれるサブディレクトリから構成され
るデータベースディレクトリに保管されます。各インデックスには、独⾃のデータベースセットが存在していま
す。データはその経過時間の経過とともに、さまざまな種類のバケツに移⾏されます (ホット、ウォーム、コール
ド、フローズン)。詳細は、「インデクサーによるデータの保管」および「データの時間経過」を参照してくださ
い。
なぜブルームフィルタを使⽤するのか？
ブルームフィルタは、エレメントがセットのメンバーかどうかをテストするために⽤いられるデータ構造です。ブ
ルームフィルタは、ディスク上の各バケツ内にファイルとして保管されます。サーチを実⾏する場合、特にまれに
登場する単語をサーチする場合に、ブルームフィルタを使⽤するとインデックスからイベントを取得するまでの時
間を⼤幅に短縮することができます。
インデクサーが時系列データのインデックスを作成するにつれて、raw データをタイムスタンプにより分類した
raw データを含む圧縮ファイルと⼀連の時系列インデックス (tsidx) ファイル が作成されます。tsidx ファイル
は、データ内のすべてのキーワード (エラーコード、応答時間など) の辞書としての役割を果たす⽤語⽬録ファイ
ルで、raw データ内のイベントの場所への参照が含まれています。サーチを実⾏すると、tsidx ファイル内のキー
29
ワードが検索され、参照先の raw データファイルからイベントが取得されます。
ブルームフィルタはバケツレベルで機能し、個別のファイル bloomfilter を使⽤します。基本的にこれは、キー
ワードがバケツ内に存在しないことを知らせるハッシュテーブルです。そのため、サーチを実⾏する際には、ブ
ルームフィルタにより除外されていないバケツの tsidx ファイルのみをサーチするだけで済みます。ディスクから
イベントを取得する実⾏コストは、tsidx ファイルのサイズと数に伴って増加します。ブルームフィルタにより
Splunk がサーチする必要がある tsidx ファイル数が減るため、各バケツのサーチにかかる時間も減少します。
ブルームフィルタは、バケツの tsidx ファイルに⾒つかった⼀意のキーワードをすべて保管する代わりに、各キー
ワードのハッシュを計算します。複数のキーワードが同じハッシュになる場合もあります。そのため、誤判定の可
能性はありますが、検出漏れは回避できます。ブルームフィルタはこのようにして、特定のバケツに存在しない単
語を素早く除外するため、インデクサーは次のバケツのサーチに即座に取りかかることができます。ブルームフィ
ルタが除外できなかったバケツ (バケツにキーワードが実際に存在するかどうかが分からない) に対しては、通常
のようにサーチが⾏われます。
ブルームフィルタの設定
ブルームフィルタは、バケツがホットからウォームに移⾏する際に作成されます。デフォルトでは、バケツがフ
ローズンに移⾏するとフィルタが削除されます (別の保持設定を指定していない場合)。ここでは、ブルームフィル
タファイルの設定と管理に使⽤できる設定パラメータについて説明していきます。
ブルームフィルタを使⽤するかどうかを指定するには、limits.conf の
さい。
use_bloomfilter
パラメータを使⽤してくだ
[search]
use_bloomfilter = true|false
* Control whether to use bloom filters to rule out buckets.
* Defaults to True.
特定のインデックスのブルームフィルタを作成するには、indexes.conf の Per Index オプションを編集します。
bloomHomePath = <path on indexer>
* The location where the bloom filter files for the index are stored.
* If specified, it must be defined in terms of a volume definition.
* If not specified, bloom filter files for the index will be stored inside the bucket directories.
* The path must be writable.
* You must restart splunkd after changing this parameter.
createBloomfilter = true|false
* Determines whether to create bloom filter files for the index.
* Defaults to "true".
また、bloomHomePath を明⽰的に定義する場合は、ボリュームを使⽤する必要があります。ボリュームは、インデッ
クス作成したデータを保管するファイルシステム内のディレクトリを表します。詳細は、「インデックスサイズの
設定」を参照してください。
注意： バケツをホットからウォームに移⾏する時に、マーカーファイル corrupt.bloomOnly.maker が⼀時的に現れま
す。このファイル名は紛らわしいですが、ブルームフィルタが破損した訳ではありません。何も対処する必要はあ
りません。単に無視してください。
再起動が必要な indexes.conf の変更
indexes.conf
への変更内容を反映するために、再起動が必要なこともあります。
以下のいずれかの属性の変更：
homePath, coldPath, thawedPath, bloomHomePath, summaryHomePath,
tstatsHomePath, repFactor, rawChunkSizeBytes, minRawFileSyncSecs, syncMeta, maxConcurrentOptimizes,
coldToFrozenDir
ボリュームの追加または削除
データのあるインデックスの有効化/無効化
インデックスの削除
以下の変更を⾏った場合は、インデクサーを再起動する必要はありません。
新しいインデックススタンザの追加
再起動が必要な項⽬に記載されていない属性の変更
データのないインデックスの有効化/無効化
DMC を使⽤してインデックスとボリュームステータスを確認する
分散管理コンソール (DMC) を使⽤して、デプロイのほぼすべてをモニタリングできます。このトピックでは、イ
ンデックス作成のパフォーマンスを確認するコンソールダッシュボードについて説明します。
分散管理コンソールのプライマリの⽂書は、『分散管理コンソール』マニュアルに設定されています。
インデックスとボリュームのステータスをモニターするダッシュボードが複数あります。ダッシュボードは単⼀の
インスタンスまたはデプロイ全体に対象範囲が分かれます。これらは、[インデックス作成 ] のメニューにありま
30
す。
インデックスとボリューム：インスタンス
インデックスとボリューム：デプロイ
インデックス詳細：インスタンス
インデックス詳細：デプロイ
ボリューム詳細：インスタンス
ボリューム詳細：デプロイ
これらのダッシュボードは次のようにインデックスやボリュームに関する豊富な情報を提供します。
インデックスごとのディスク使⽤状況
ボリューム使⽤状況
時間経過によるインデックスとボリュームサイズの推移
データ使⽤状況
バケツタイプ統計
バケツ設定
詳細はダッシュボードを確認してください。また、『分散管理コンソール』マニュアルの「インデックス作成：イ
ンデックスとボリューム」を参照してください。
インデックスのバックアップとアーカイブ
インデックス作成されたデータのバックアップ
インデックスデータのバックアップ⽅法を決めるためには、まずインデクサーによるデータの保管⽅法、およびイ
ンデックス作成後の時間の経過によるデータの取り扱いの仕組みを理解しておくことが⼤切です。その後、バック
アップ⽅法を決定します。
このトピックを参照する前に、「インデクサーによるインデックスの保管⽅法」を参照してインデックス構造とそ
の設定オプションを理解するようにしてください。その時間がない⽅のために、次のセクションにはそのトピック
の要点が記載されています。
データの時間経過
インデックス作成されたデータはバケツ と呼ばれるサブディレクトリから構成されるデータベースディレクトリ
に保管されます。各インデックスには、独⾃のデータベースセットが存在しています。
データは、時間が経過するにつれて、さまざまな種類のバケツに移⾏します。データ状態の推移を定義するには、
indexes.conf に属性を設定します。データ状態の推移を制御するための indexes.conf への設定⽅法については、
「インデックスストレージの設定」を参照してください。
ここでは、インデックスの時間の経過に伴うデータの取り扱いについて簡単に説明しています。
1. 最初にデータのインデックスが作成されると、それはホットバケツに格納されます。設定によっては、複数のバ
ケツが同時に存在することもあります。ホットバケツは積極的に書き込まれるため、バックアップすることはでき
ません。ただし、スナップショットを取得することは可能です。
2. ホットバケツ内のデータは、ポリシーに設定されている条件を満たすと「ウォーム」データに再分類されます。
これは、データのウォームバケツへの「移⾏」と呼ばれています。これは、ホットバケツが指定サイズまたは経過
時間に達した場合、または splunkd が再起動された時に⾏われます。ホットバケツの移⾏が実施されると、ディレ
クトリ名が変更されウォームバケツとなります。(⼿動でバケツをホットからウォームに移⾏することもできま
す。詳細は以下を参照してください。)ウォームバケツのバックアップを⾏うこともできます。
3. インデックスが設定されている何らかの制限値に達した場合 (通常はウォームバケツ数)、もっとも古いバケツが
「コールド」バケツになります。バケツは colddb ディレクトリに移動されます。デフォルトのウォームバケツ数
は 300 です。
4. 最後に、定義されているポリシー要件に基づいて、バケツがコールドから「フローズン」に移⾏されます。イン
デクサーはフローズンバケツを削除します。ただし、データを保持する必要がある場合は、バケツを削除する前に
データをアーカイブすることができます。詳細は、「インデックスデータのアーカイブ」を参照してください。
インデックスやバケツのサイズまたはデータの経過時間などの各種パラメータを利⽤して、リタイアおよびアーカ
イブポリシーを設定することができます。
要約：
ホットバケツ - 現在書き込まれているバケツ。バックアップしないでください。
ウォームバケツ - ホットから移⾏されます。安全にバックアップできます。
コールドバケツ - ウォームから移⾏されます。バケツは別の場所に移動されます。
フローズンバケツ - これらのバケツは削除されますが、その前にアーカイブすることができます。
インデックスデータベースの場所は、indexes.conf に設定します(デフォルトインデックスのデータベースの場所の
詳細については、後述しています)。また、ここにはホットバケツの最⼤サイズや経過時間など、さまざまな属性
を指定することができます。
インデックスデータベースディレクトリの場所
デフォルトインデックス (defaultdb) のディレクトリ構造を以下に⽰します。
バケツ
31
バケツ
タイプ
ホット
デフォルトの場所
メモ
複数のホットサブディレクトリが存在する場合があり
ます。各ホットバケツは独⾃のサブディレクトリを保
有しています。サブディレクトリの命名規則を以下に
⽰します。
$SPLUNK_HOME/var/lib/splunk/defaultdb/db/*
hot_v1_<ID>
ウォー
ム
$SPLUNK_HOME/var/lib/splunk/defaultdb/db/*
各ウォームバケツ個別のサブディレクトリが存在して
います。これらの名前は、「ウォーム/コールドバケツ
の命名規則」の説明に従って付けられます。
コール
ド
$SPLUNK_HOME/var/lib/splunk/defaultdb/colddb/*
複数のコールドサブディレクトリが存在しています。
ウォームバケツがコールドに移⾏されると、データは
このディレクトリに移動されますが名前は変更されま
せん。
デフォルトでは削除されます。代わりにデータをアー
フロー N/A：フローズンデータは、削除されるかま
カイブする⽅法については、「インデックス作成され
ズン
たは指定ディレクトリにアーカイブされます。
たデータのアーカイブ」を参照してください。
解凍
$SPLUNK_HOME/var/lib/splunk/defaultdb/thaweddb/*
アーカイブされて、後ほど解凍されたデータの場所。
アーカイブされたデータの解凍状態への復元について
は、「アーカイブされたインデックスデータの復元」
を参照してください。
ホット/ウォーム、およびコールドディレクトリへのパスは変更することができます。たとえば、コールドバケツ
をホット/ウォームバケツとは別の場所に保管することができます。「インデックスストレージの設定」および
「インデックスデータ⽤の複数パーティションの使⽤」を参照してください。
重要： すべてのインデックス保管場所は書き込み可能でなければなりません。
バックアップ⽅針の選択
基本的には検討する必要がある 2 種類のバックアップシナリオが存在しています。
継続的な、ウォームデータの増分バックアップ。
すべてのデータのバックアップ (たとえば、インデクサーのアップグレード前)
実際のバックアップ実⾏⽅法は、ご⾃分の組織で利⽤しているツールや⼿順によって異なりますが、ここでは必要
な作業に関するガイドラインを提供しています。
増分バックアップ
⼀般的には、適切な増分バックアップユーティリティを使って、新しいウォームバケツを定期的にバックアップす
るようにスケジュールすることをお勧めします。バケツが頻繁に移⾏されるような環境では、バックアップされる
前にコールドバケツに移⾏されたデータを⾒逃さないように、コールドデータベースのディレクトリもバックアッ
プ対象にする必要があります。ウォームからコールドに移⾏する際に、バケツディレクトリ名は変更されないた
め、単に名前でフィルタリングすることができます。
ホットバケツもバックアップする場合は、VSS (Windows/NTFS) や ZFS (ZFS) などのツール、またはその他の
ストレージサブシステムが提供するスナップショット機能を使って、ファイルのスナップショットを取得する必要
があります。利⽤できるスナップショットツールがない場合は、⼿動でホットバケツをウォームバケツに移⾏し
て、それをバックアップすることができます (後述)。ただし、⼀般的にこのような⾏為は、後述する理由によりお
勧めできません。
すべてのデータのバックアップ
インデクサーをアップグレードする前には、すべてのデータをバックアップすることをお勧めします。これには、
ホット、ウォーム、およびコールドバケツが含まれます。
この作業を⾏うためには、データのサイズやどのくらいの時間システムを停⽌できるかなどの条件に応じて、さま
ざまな⽅法を利⽤できます。基本的なガイドラインを以下に⽰します。
データが少量の場合は、インデクサーをシャットダウンして、データベースディレクトリのコピーを作成し
てから、アップグレードを実施してください。
⼤量のデータがある場合は、アップグレード前にホットバケツのスナップショットを取得する⽅がよいかも
しれません。
どのような場合でも、ホットから移⾏されたウォームバケツの増分バックアップを⾏っている場合は、この時点で
のみホットバケツをバックアップする必要があります。
ホットバケツのウォームへの⼿動移⾏
インデックスのバケツを⼿動でホットからウォームに移⾏するには、以下の CLI コマンドを使⽤しま
す。<index_name> には、移⾏するインデックス名を指定してください。
splunk _internal call /data/indexes/<index_name>/roll-hot-buckets -auth <admin_username>:<admin_password>
重要： 強制的な移⾏はデータのサーチパフォーマンスを永久に低下させるため、通常ホットバケツの⼿動移⾏は
32
お勧めできません。⼀般的には、バケツが⼤きいほどサーチを効率的に⾏うことができます。早期にバケツを移⾏
すると、⼩さくて⾮効率的なバケツを作成することになります。ホットデータをバックアップする必要がある場合
は、スナップショットの取得が推奨するバックアップ⼿法になります。
注意： ⾼速化データモデルサマリーとインデックスレプリケーションを利⽤する環境では、ホットバケツを⼿動
で移⾏することはお勧めできません。他のインデックス管理ジョブが進⾏中の際にホットバケツが移⾏される場
合、データの整合性が低下する可能性があります。
復元の推奨事項
致命的ではないディスク障害が発⽣した場合 (たとえば、⼀部のデータは残っているけれどもインデクサーを実⾏
できない場合) は、⼀部が壊れたデータストアの最上位から復元する代わりに、インデックスディレクトリを別の
場所に移動してバックアップから復元することをお勧めします。インデクサーは起動時に必要に応じてホットバケ
ツを⾃動的に作成し、インデックスの作成作業を再開します。監視対象ファイルとディレクトリは、バックアップ
時の場所で取得されます。
クラスタ化されたデータのバックアップ
インデクサークラスタ にはすでにデータの冗⻑コピーが含まれていますが、クラスタのデータを他の場所にバッ
クアップしたい場合もあります (たとえば、障害対策の⼀環としてサイト外にコピーを保持する場合)。
このためのもっとも簡単な⽅法は、このトピックの前半で説明したように、⾮クラスタ化インデクサーのデータを
バックアップするのと同じ⼿段で、クラスタ内の個別の各ピアノードのデータをバックアップすることです。ただ
し、この⽅法ではバックアップデータが重複してしまいます。たとえば、複製データ保持数 が 3 のクラスタがあ
る場合、そのクラスタは⼀連のピアノードのすべてのデータに対して、3 つのコピーを保持します。このような環
境で個別の各ノードに保管されているデータをバックアップした場合、結果的に 3 つのデータコピーを含むバッ
クアップができてしまいます。1 台のノードのデータをバックアップするだけではこの問題を解決することはでき
ません。そのノードにクラスタ内のすべてのデータが保管されている保証がないからです。
この問題を解決するには、クラスタ上の各バケツのコピーをそれぞれ 1 つ識別して、それらのコピーのみをバッ
クアップすることが考えられます。ただし、このような作業は複雑でとても⼿間がかかります。1 つの⼿段とし
て、各ピアのインデックスストレージを調べ、バケツ名に含まれているバケツ ID 値を使って、各バケツのコピー
を 1 つのみ識別するスクリプトを作成することが挙げられます。バケツ ID は、すべてのバケツのコピーで同じに
なります。バケツ ID の詳細は、「ウォーム/コールドバケツの命名規則」を参照してください。クラスタバック
アップスクリプトの設計時には、バケツの raw データのみをバックアップするのか、または raw データとイン
デックスファイルの両⽅をバックアップするのかも検討する必要があります。後者の場合は、各バケツのサーチ可
能コピーも識別するようにスクリプトを設計する必要があります。
クラスタバックアップは複雑なため、Splunk プロフェッショナルサービスに、クラスタ化データの単⼀のコピー
をバックアップするためのガイダンスを依頼することをお勧めします。サービスチームは、お客様の環境のニーズ
に合わせたソリューションの設計をお⼿伝いいたします。
リタイアおよびアーカイブポリシーの設定
データリタイアおよびアーカイブ ポリシーの設定は、インデックスのサイズまたはインデックス内のデータの経
過期間で定義します。
インデクサーは、インデックスデータをバケツ と呼ばれるディレクトリに保管しています。バケツはリタイアす
るまでに 4 種類の段階を経ます。インデックスデータが最終段階のフローズンになると、それがインデックスか
ら削除されます。フローズン状態のデータを削除する代わりに、アーカイブするようにインデクサーを設定できま
す。詳細は、「インデックス作成されたデータのアーカイブ」を参照してください。
バケツの
ステージ
ホット
説明
新たにインデックスが作成されたデータを保管しています。書き込み可能。各イン
デックスに対して 1 つまたは複数のホットバケツ。
サーチ可能？
はい
ウォーム ホットから移⾏されたデータ。ウォームバケツは多数存在しています。
はい
コールド ウォームから移⾏されたデータ。コールドバケツは多数存在しています。
はい
コールドから移⾏されたデータ。デフォルトでは、フローズンデータは削除されま
フローズ すが、アーカイブすることも可能です。アーカイブされたデータは、後ほど解凍す
ン
ることができます。
いいえ
インデックスおよびバケツのサイズ、場所、および経過時間は indexes.conf で設定、編集します。「インデック
スストレージの設定」を参照してください。
注意： データのリタイアおよびアーカイブポリシーの設定を変更した場合、インデクサーは警告なしに古いデー
タを削除できます。
コールドからフローズンへの移⾏動作の属性の設定
内の maxTotalDataSizeMB および frozenTimePeriodInSecs 属性は、バケツがコールドからフローズンに移
⾏する時期を決定します。これらの属性の詳細は、以降の説明を参照してください。
indexes.conf
インデックスが⼤きくなりすぎた場合にデータをフローズンに移⾏：maxTotalDataSizeMB の設定
データをフローズンに移⾏してインデックスから削除する時期を、インデックスサイズで設定できます。インデッ
クスが指定サイズを超えた場合に、もっとも古いデータがフローズン状態に移⾏されます。
33
デフォルトのインデックス最⼤サイズは、500,000 MB です。最⼤サイズを変更するには、indexes.conf 内の
maxTotalDataSizeMB 属性を編集します。たとえば、最⼤サイズとして 250,000 MB を指定します。
[main]
maxTotalDataSizeMB = 250000
重要： サイズはメガバイトで指定してください。
新しい設定を有効にするには、インデクサーを再起動してください。処理対象データの量によっては、インデク
サーが新しいポリシーに従ってインデックスのバケツの移⾏を開始するまでに少し時間がかかることがあります。
その間、CPU の使⽤率が⾼くなる可能性があります。
データが古くなった場合にフローズンに移⾏する： frozenTimePeriodInSecs の設定
バケツのフローズンへの移⾏時期を、データの経過時間で設定することができます。特定のバケツ内の最新のデー
タの経過時間が設定された値に達すると、バケツ全体が移⾏されます。
データをフローズンに移⾏するまでの経過時間を指定するには、indexes.conf 内の frozenTimePeriodInSecs 属性を編
集します。この属性は、データをフローズン状態に移⾏するまでの経過秒数を指定します。デフォルトは
188697600 秒 (約 6 年) です。180 ⽇ (15552000 秒) 以上経過した古いイベントをインデックスから削除する
設定例を以下に⽰します。
[main]
frozenTimePeriodInSecs = 15552000
重要： 時間は秒数で指定します。
新しい設定を有効にするには、インデクサーを再起動してください。処理対象データの量によっては、インデク
サーが新しいポリシーに従ってインデックスのバケツの移⾏を開始するまでに少し時間がかかることがあります。
その間、CPU の使⽤率が⾼くなる可能性があります。
データのアーカイブ
フローズンデータを削除する代わりにアーカイブする場合は、「インデックス作成されたデータのアーカイブ」の
説明に従ってインデクサーにその旨を指⽰する必要があります。独⾃のアーカイブスクリプトを作成することも、
インデクサーにアーカイブ処理を⾏わせることも可能です。アーカイブしたデータは後ほど復元 (解凍) すること
ができます。「アーカイブされたインデックスデータの復元」を参照してください。
その他のバケツ移⾏条件
あるステージから別のステージへのバケツの移⾏の契機となる条件は、他にもさまざま存在しています。⼀部の条
件は、データの削除やアーカイブにつながります。これらの条件はすべて設定可能です。「インデックスストレー
ジの設定」を参照してください。リタイアポリシーに影響するすべてのオプションを完全に理解するために、この
トピックおよび indexes.conf ファイルを参照してください。
たとえば、インデクサーはバケツが最⼤サイズに達した場合にそのバケツを移⾏します。indexes.conf 内の
maxDataSize に⼩さな値を設定すると、バケツのサイズが⼩さくなるため、より頻繁に移⾏が⾏われるようになり
ます。ただし、少数の⼤きなバケツを使⽤する代わりに多数の⼩さなバケツを使⽤すると、サーチに時間がかかる
ことに注意してください。⽬的の結果を得るためには、⾊々と試して最適なバケツサイズを決定する必要がありま
す。
アーカイブポリシーのトラブルシューティング
ディスクスペースが⾜りなくなったからアーカイブポリシーを変更したけれどもうまく機能しない
ディスクスペースが⾜りなくなったため、より厳格なアーカイブポリシーに変更した場合でも、新しいポリシーに
従ってイベントのアーカイブが開始されないことがあります。このような場合、処理を実⾏するための空きスペー
スが⾜りない可能性があります。まず最初に、処理を実⾏できるようにいくらかのスペースを確保してください。
インデクサーを停⽌して、最⾼ 5 GB ほどの空きディスクスペースを確保してから、もう⼀度インデクサーを起動
してください。しばらくすると (実際にかかる時間は処理対象データの量によって異なります)、バケツのアーカイ
ブが開始されたことを⽰す、splunkd.log 内の BucketMover に関する情報エントリが表⽰されるはずです。
インデックス作成されたデータのアーカイブ
時間の経過に伴って (データがフローズン状態に移⾏する時点で)、データを⾃動的にアーカイブするようにインデ
クサーを設定することができます。このためには、indexes.conf を設定します。
注意： デフォルトでは、フローズン状態に移⾏したデータはすべて削除されます。データは、フローズン状態に
移⾏した時点でインデックスから削除されます。データを保持しておきたい場合は、削除前にデータをアーカイブ
するように設定する必要があります 。このためには、indexes.conf 内に coldToFrozenDir 属性を設定するか、また
は有効な coldToFrozenScript を指定します。
データストレージの詳細は、「インデクサーによるインデックスの保管⽅法」を参照してください。indexes.conf
の編集⽅法については、「インデックスストレージの設定」を参照してください。
インデクサーによるデータのアーカイブ⽅法
34
インデクサーは、データリタイアポリシーに基づいて、インデックスから古いデータを取り除きます (「リタイア
およびアーカイブポリシーの設定」を参照)。データは各種ステージを移動していきます。これらのステージは、
ファイルディレクトリの場所に対応しています。まずデータはホット データベースに保管されます。このデータ
ベースは、$SPLUNK_HOME/var/lib/splunk/defaultdb/db/ 下のサブディレクトリ (バケツ ) として存在しています。次
に、$SPLUNK_HOME/var/lib/splunk/defaultdb/db のサブディレクトリとして存在する、ウォーム データベースに移⾏し
ます。その後順次、データはコールド データベース $SPLUNK_HOME/var/lib/splunk/defaultdb/colddb に移⾏されま
す。
最後にデータは、フローズン 状態になります。この処理はさまざまな条件に応じて発⽣します (「リタイアおよび
アーカイブポリシーの設定」を参照)。この時点で、インデクサーはデータをインデックスから消去します。フ
ローズンデータをインデックスから消去する前にアーカイブする場合は、その旨を設定する必要があります。アー
カイブ処理には、2 種類の⽅法を選択できます。
インデクサーにアーカイブを⾃動実⾏させる。
実⾏するアーカイブスクリプトを指定する。
アーカイブ動作は、これらの
indexes.conf
属性の設定内容によって異なります。
coldToFrozenDir。この属性は、インデクサーがフローズンデータを⾃動的にアーカイブする場所を⽰しま
す。
coldToFrozenScript。この属性は、データをフローズンにする際に実⾏するユーザースクリプトを⽰します。
これは⼀般的に、フローズンデータをアーカイブするスクリプトになります。スクリプトは、他の⽬的に利
⽤することも可能です。インデクサーには、サンプルのアーカイブスクリプトが 1 つ同梱されており
($SPLUNK_HOME/bin/coldToFrozenExample.py)、これを編集して利⽤することができます。また、その他任意のス
クリプトを指定することも可能です。
注意： これらの属性の中の 1 つのみを指定できます。両⽅の属性を設定した場合、coldToFrozenDir 属性の設定が
coldToFrozenScript の設定に優先されます。
どちらの属性も指定しない場合は、消去するバケツ名を単にログファイル
$SPLUNK_HOME/var/log/splunk/splunkd_stdout.log に書き込むデフォルトスクリプトが実⾏されます。その後バケツが
消去されます。
インデクサーにデータをアーカイブさせる
に coldToFrozenDir 属性を設定した場合、インデクサーはインデックスからデータを消去する前に、⾃
動的にフローズンバケツを指定場所にコピーします。
indexes.conf
$SPLUNK_HOME/etc/system/local/indexes.conf
に以下のスタンザを追加します。
[<index>]
coldToFrozenDir = "<path to frozen archive>"
以下の事項に注意してください。
<index>
は、アーカイブするデータが存在するインデックスを⽰します。
は、インデクサーがアーカイブしたバケツを保管するディレクトリを⽰します。
<path to frozen archive>
注意： Splunk Web を使って新しいインデックスを作成する際に、そのインデックスのフローズンアーカイブの
パスを指定することもできます。詳細は、「複数インデックスの設定」を参照してください。
インデクサーによるフローズンデータのアーカイブ⽅法は、当初 4.2 より前のリリースでデータのインデックス
が作成されたのかどうかによって異なります。
バージョン 4.2 以降で作成されたバケツの場合、raw データファイル を除くすべてのファイルが削除され
ます。
4.2 より前のバージョンで作成されたバケツの場合、単にバケツ内のすべての
が gzip されます。
.tsidx
および
.data
ファイル
この差異は、raw データの形式の変更によるものです。4.2 以降ではインデクサーがインデックスバケツを再構築
するために必要なすべての情報が raw データファイルに含まれています。
バケツの解凍 (復元) ⽅法の詳細は、「アーカイブされたインデックスデータの復元」を参照してください。
アーカイブスクリプトの指定
に coldToFrozenScript 属性を設定した場合、インデックスからフローズンデータを消去する前に、指定
したスクリプトが実⾏されます。
indexes.conf
実際のスクリプトを指定する必要があります。⼀般的にはデータをアーカイブするスクリプトを指定しますが、任
意のアクションを実⾏するスクリプトを指定できます。
$SPLUNK_HOME/etc/system/local/indexes.conf
に以下のスタンザを追加します。
[<index>]
coldToFrozenScript = ["<path to program that runs script>"] "<path to script>"
35
以下の事項に注意してください。
は、アーカイブするデータが存在するインデックスを⽰します。
には、アーカイブスクリプトへのパスを指定します。スクリプトは、$SPLUNK_HOME/bin また
はそのサブディレクトリに保管する必要があります。
<path to program that runs script> は省略することができます。スクリプトの実⾏に Python などのプログラ
ムが必要な場合に、これを設定します。
スクリプトを $SPLUNK_HOME/bin に保管しており、名前が myColdToFrozen.py の場合は、以下のように属性を設
定します。
<index>
<path to script>
coldToFrozenScript = "$SPLUNK_HOME/bin/python" "$SPLUNK_HOME/bin/myColdToFrozen.py"
アーカイブスクリプトの詳細は、indexes.conf ファイルを参照してください。
インデクサーには、アーカイブスクリプトの例
を編集することも可能です。
$SPLUNK_HOME/bin/coldToFrozenExample.py
が⽤意されています。これ
注意： サンプルスクリプトを使⽤する場合、ご⾃分の環境に合わせてアーカイブの場所を変更してください。ま
た、インデクサーのアップグレード時に変更したファイルが上書きされないように、編集したスクリプトの名前を
変更するか、または別の場所に移動してください。これはあくまでもサンプルのスクリプト なので、ご利⽤の
環境に合わせて編集した後、正常に動作することを確認しない限り、実際の⽣産環境には適⽤しないでください。
このサンプルスクリプトは、当初のデータのインデックスが 4.2 より前のバージョンのリリースで作成されたか
どうかによって、フローズンデータを異なる⽅法でアーカイブします。
バージョン 4.2 以降で作成されたバケツの場合、raw データファイルを除くすべてのファイルが削除されま
す。
4.2 より前のバージョンで作成されたバケツの場合は、単にすべての
れます。
.tsidx
および
.data
ファイルが gzip さ
この差異は、raw データの形式の変更によるものです。4.2 以降ではインデクサーがインデックスバケツを再構築
するために必要なすべての情報が raw データファイルに含まれています。
バケツの解凍 (復元) ⽅法の詳細は、「アーカイブされたインデックスデータの復元」を参照してください。
ベストプラクティスとして、インデクサーが完了待ち状態で待機することがないように、スクリプトはできる限り
早く処理を完了するようにしてください。たとえば、低速なボリュームへアーカイブするような場合は、まずイン
デックスと同じ (⾼速な) ボリューム内の⼀時ディレクトリにバケツをコピーするようにスクリプトを設定しま
す。その後インデクサー外で別のスクリプトを使って、そのバケツを⼀時ディレクトリから低速なボリューム上の
⽬的のディレクトリに移動します。
クラスタ化データのアーカイブ
インデクサークラスタ には、インデックスデータの冗⻑コピーが保管されています。前述の⽅法を使ってこのよ
うなデータをアーカイブする場合、複数のデータコピーをアーカイブすることになります。
たとえば、複製データ保持数 が 3 のクラスタがある場合、そのクラスタは⼀連のピアノードのすべてのデータに
対して、3 つのコピーを保持します。各ピアノードに対してフローズン移⾏時に⾃⼰のデータをアーカイブするよ
うに設定した場合、3 つのアーカイブされたデータのコピーができてしまいます。1 台のノードのデータをアーカ
イブするだけではこの問題を解決することはできません。そのノードにクラスタ内のすべてのデータが保管されて
いる保証がないからです。
クラスタ上の各バケツのコピーを 1 つのみアーカイブして、残りを破棄すればこの問題は解決します。ただし、
このような作業は複雑でとても⼿間がかかります。クラスタ化データの単⼀コピーをアーカイブするためのガイダ
ンスが必要な場合は、Splunk プロフェッショナルサービスまでお問い合わせください。サービスチームは、お客
様の環境のニーズに合わせたソリューションの設計をお⼿伝いいたします。
アーカイブ先の指定
クラスタ化データの複数コピーをアーカイブすることを選択した場合は、名前の競合が発⽣しないように注意する
必要があります。すべてのピアノードからのデータを単⼀のアーカイブディレクトリに送ることはできません。ク
ラスタ内には同じ名前を持つバケツのコピーが複数存在しており (複製データ保持数が > 2 のデプロイ環境)、
ディレクトリの内容には⼀意の名前を付ける必要があります。代わりに、各ピアノードからのバケツを個別のアー
カイブディレクトリに送る必要があります。indexes.conf 内の coldToFrozenDir 属性を使って共有ストレージ内の宛
先ディレクトリを指定した場合、このような処理は困難です。「インデクサークラスタ内のピアインデックスの設
定」で説明しているように、indexes.conf ファイルはすべてのピアノード上で同⼀でなければなりません。その代
わりに、各ピアのアーカイブバケツを共有ストレージ上の個別の場所に保管するスクリプトを作成
し、coldToFrozenScript 属性を使ってそのスクリプトを指定することができます。
アーカイブされたインデックスデータの復元
アーカイブされたデータを復元するには、アーカイブされているバケツ を解凍⽤ディレクトリ
(例：$SPLUNK_HOME/var/lib/splunk/defaultdb/thaweddb) に移動して、次にこのトピックの後半で説明する⼿順に従っ
て処理を⾏います。thaweddb 内のデータには、サーバーのインデックスの時間経過による状態遷移 (ホット >
ウォーム > コールド > フローズン) は適⽤されません。アーカイブデータは、解凍⽤ディレクトリに必要なだけ
保管しておくことができます。データが不要になったら、それを削除するかまたは別のディレクトリに移動してく
ださい。
重要： アーカイブデータの復元は、そのインデックスが Splunk Enterprise 4.2 以降で作成されたかどうかに
36
よって作業内容が異なります。これは、4.2 で Splunk Enterprise の raw データの形式が変更されたためです。
データのアーカイブ⽅法については、「インデックス作成されたデータのアーカイブ」を参照してください。ま
た、解凍したデータを再びアーカイブする場合についても、そのトピックを参照してください。
アーカイブを別のインデクサーのインスタンスに復元する場合の制限事項
たいていの場合、アーカイブは当初インデックスを作成したインデクサーインスタンスだけではなく、任意のイン
デクサーインスタンスに復元することができます。ただし、これにはいくつかの要素が影響してきます。
Splunk Enterprise バージョン： Splunk Enterprise 4.2 以降で作成されたバケツを、4.2 より前のイン
デクサーインスタンスに復元することはできません。4.1 と 4.2 ではバケツのデータ形式が変更されていま
す。4.2 より前のインデクサーは、新しい形式を理解することはできません。つまり、以下のようになりま
す。
4.2 以降のバケツ： 4.2 以降のバケツは、任意の 4.2 以降のインスタンスに復元できます。
4.2 より前のバケツ ：4.2 より前のバケツは、任意のインデクサー (4.2 以前および 4.2 以降) に復元
できます。ただし、後述するように、いくつかの OS に関連する問題があります。
OS のバージョン： 通常は、異なる OS 上で動作するインデクサーにバケツを復元することができます。概
要を以下に⽰します。
4.2 以降のバケツ： 4.2 以降のバケツは、任意の OS 上で動作するインデクサーに復元できます。
4.2 より前のバケツ： 4.2 より前のバケツは、任意の OS 上で動作するインデクサーに復元できます
が、異なるエンディアンを持つシステムに 4.2 より前のデータを復元することはできません。たとえ
ば、64 ビットシステム上で⽣成されたデータは 32 ビットシステムでは正常に機能せず、PowerPC
または SPARC システムから x86 または x86-64 システム、またはその逆⽅向にデータを移動するこ
とはできません。
また、アーカイブされているバケツを復元する際には、インデックスと競合するバケツ ID を導⼊しないようにし
てください。この問題については後述します。
アーカイブバケツに 4.2 以降のデータが含まれているかどうかの判断
アーカイブバケツを解凍する前に、アーカイブバケツが 4.2 より前かまたは 4.2 以降かを識別する必要がありま
す。ここでは、coldToFrozenDir または⽤意されているサンプルスクリプトを使ってアーカイブされたバケツを前提
に、これらの違いについて説明していきます。
4.2 以降のバケツ： バケツディレクトリには、raw データディレクトリ journal.gz のみが含まれています。
4.2 より前のバケツ： バケツディレクトリには、.tsidx および .data ファイルの gzip、および <int>.gz と
いう名前の付けられたファイルを含む raw データディレクトリが含まれています。
重要： 独⾃のスクリプトを使ってデータをアーカイブした場合、結果となるバケツには任意のファイルが含まれ
ます。
または⽤意されているサンプルスクリプトを使ってバケツをアーカイブした場合は、以下の⼿順に
従ってそれを解凍することができます。
coldToFrozenDir
4.2 以降のアーカイブの解凍
*nix ユーザー
4.2 以降のアーカイブバケツを解凍⽤ディレクトリに復元する例を以下に⽰します。
1. アーカイブバケツを復元⽤ディレクトリにコピーします。
cp -r db_1181756465_1162600547_1001 $SPLUNK_HOME/var/lib/splunk/defaultdb/thaweddb
注意： バケツ ID は、インデックス内の他のインデックスと重複することはできません。この例では、インデック
ス内でバケツ ID 1001 が⼀意であることを前提にしています。そうでない場合は、他の競合していないバケツ
ID を選択してください。
2. アーカイブディレクトリで
splunk rebuild
コマンドを実⾏し、インデックスと関連ファイルを再構築します。
splunk rebuild $SPLUNK_HOME/var/lib/splunk/defaultdb/thaweddb/db_1181756465_1162600547_1001
3. インデクサーを再起動します。
splunk restart
Windows ユーザー
4.2 以降のアーカイブバケツを解凍⽤ディレクトリに復元する例を以下に⽰します。
1. アーカイブバケツを復元⽤ディレクトリにコピーします。
xcopy
D:\MyArchive\db_1181756465_1162600547_1001 %SPLUNK_HOME%\var\lib\splunk\defaultdb\thaweddb\db_1181756465_1162600547_1001
37
/s /e /v
注意： バケツ ID は、インデックス内の他のインデックスと重複することはできません。この例では、インデック
ス内でバケツ ID 1001 が⼀意であることを前提にしています。そうでない場合は、他の競合していないバケツ
ID を選択してください。
2. アーカイブディレクトリで
splunk rebuild
コマンドを実⾏し、インデックスと関連ファイルを再構築します。
splunk rebuild %SPLUNK_HOME%\var\lib\splunk\defaultdb\thaweddb\db_1181756465_1162600547_1001
3. インデクサーを再起動します。
splunk restart
4.2 より前のアーカイブの解凍
*nix ユーザー
4.2 より前のアーカイブバケツを復元⽤ディレクトリに復元する例を以下に⽰します。
1. アーカイブバケツを解凍⽤ディレクトリの⼀時ディレクトリにコピーします。
# cp -r db_1181756465_1162600547_0
$SPLUNK_HOME/var/lib/splunk/defaultdb/thaweddb/temp_db_1181756465_1162600547_0
2. バケツのアーカイブ時に圧縮されている場合は、それを解凍します。
3. この⼀時バケツをインデクサーが認識できる名前に変更します。
# cd $SPLUNK_HOME/var/lib/splunk/defaultdb/thaweddb/
# mv temp_db_1181756465_1162600547_0 db_1181756465_1162600547_1001
注意： インデックス内の他のバケツと競合しないバケツ ID を指定する必要があります。この例では、インデック
ス内でバケツ ID 1001 が⼀意であることを前提にしています。そうでない場合は、他の競合していないバケツ
ID を選択してください。
4. マニフェストを更新します。
# cd $SPLUNK_HOME/bin
# ./splunk login
# ./splunk _internal call /data/indexes/main/rebuild-metadata-and-manifests
しばらくすると、復元したバケツが再びサーチ可能になります。
Windows ユーザー
4.2 より前のアーカイブバケツを復元⽤ディレクトリに復元する例を以下に⽰します。
1. アーカイブバケツを復元⽤ディレクトリにコピーします。
> xcopy
D:\MyArchive\db_1181756465_1162600547_0 %SPLUNK_HOME%\var\lib\splunk\defaultdb\thaweddb\temp_db_1181756465_1162600547_0
/s /e /v
2. バケツのアーカイブ時に圧縮されている場合は、それを解凍します。
3. この⼀時バケツをインデクサーが認識できる名前に変更します。
> cd %SPLUNK_HOME%\var\lib\splunk\defaultdb\thaweddb
> move temp_db_1181756465_1162600547_0 db_1181756465_1162600547_1001
注意： インデックス内の他のバケツと競合しないバケツ ID を指定する必要があります。この例では、インデック
ス内でバケツ ID 1001 が⼀意であることを前提にしています。そうでない場合は、他の競合していないバケツ
ID を選択してください。
4. マニフェストを更新します。
> cd %SPLUNK_HOME%\bin
> splunk login
> splunk _internal call /data/indexes/main/rebuild-metadata-and-manifests
しばらくすると、復元したバケツが再びサーチ可能になります。
38
クラスタ化データの復元
アーカイブされたクラスタ化データの個別のピアノードへの復元は、個別のインデクサーへのデータの復元と同じ
⽅法で⾏うことができます。ただし、「インデックス作成されたデータのアーカイブ」で説明しているように、ク
ラスタ化データの単⼀のコピーをアーカイブすることは困難です。代わりにクラスタ内のすべてのピアノードの
データをアーカイブした場合は、後ほどそのデータを復元し、それを元のピアノードの復元⽤ディレクトリに保管
することができます。コピーも含めたすべてのオリジナルデータを復元するため、複製データ保持数だけの復元
データのコピーがクラスタに配置されます。
注意： 復元⽤ディレクトリのデータは複製されません。すべてのバケツのコピーではなく、あるバケツの単⼀の
コピーのみを復元した場合、クラスタ内にはそれを配置したピアノード上の復元⽤ディレクトリに、その単⼀のコ
ピーのみが保管されます。
インデクサークラスタとインデックスレプリケーショ
ンの概要
インデクサークラスタとインデックスレプリケーションについて
インデクサークラスタは、相互のデータを複製するように設定された Splunk Enterprise インデクサーのグルー
プです。このプロセスは、インデックスレプリケーション として知られています。クラスタは Splunk
Enterprise データの複数の同⼀コピーを保持することにより、データ消失を防⽌しながら、サーチ⽤データの可
⽤性を向上します。
インデクサークラスタ機能では、あるインデクサーから別のインデクサーに⾃動フェイルオーバーが⾏われます。
つまり、1 つまたは複数のインデクサーに障害が発⽣した場合でも、引き続き到着データのインデックスが作成さ
れ、サーチが可能になります。
インデックスレプリケーションの主な利点を以下に⽰します。
データ可⽤性： インデクサーは常に到着データを処理でき、インデックスが作成されたデータはサーチ可能
となります。
データ忠実度： データが失われることはありません。クラスタに送信されたデータは、クラスタ内に保管さ
れたデータと完全に同⼀で、サーチに利⽤することができます。
データ復元： インデクサーがダウンしても、データが失われることなく、引き続きデータを利⽤できます。
障害対策： マルチサイトクラスタリングにより、あるデータセンターに全体的な障害が発⽣しても対処でき
るシステムを構築することができます。
サーチアフィニティ： マルチサイトクラスタリングにより、サーチヘッドはローカルサイト経由でデータ
セット全体にアクセスできるため、⻑距離ネットワークトラフィックを⼤幅に削減することができます。
インデックスレプリケーションの主なトレードオフとしては、データ可⽤性/復元とストレージコスト (およびわ
ずかな処理負荷の増加) の兼ね合いが挙げられます。クラスタのデータ復元可能性は、クラスタ内で保持するデー
タコピー数に⽐例します。ただし、データコピーの保持数が多いと、ストレージ要件も⾼くなります。このトレー
ドオフを管理して企業ニーズを満たすために、クラスタに保持するデータコピー数を設定することができます。こ
れは、「複製データ保持数 」と呼ばれています。
また、インデックスレプリケーションが必要ではない状況でも、クラスタを使ってインデックス容量/能⼒を増強
することができます。「インデクサークラスタを使ったインデックスの増強」を参照してください。
注意： サーチヘッドクラスタ は、⾼い可⽤性とスケーラビリティを持つ、サーチヘッドのグループを提供してい
ます。これはインデクサークラスタとは別個の機能ですが、インデクサークラスタと組み合わせて Splunk
Enterprise デプロイ環境に⾼い可⽤性と拡張性を持つソリューションを構築することができます。『分散サー
チ』マニュアルの「サーチヘッドクラスタリングについて」を参照してください。
インデクサークラスタのパーツ
インデクサークラスタは、連携して冗⻑インデックス作成およびサーチ機能を提供する、Splunk Enterprise イン
スタンス、またはノード のグループです。各クラスタには 3 種類のノードが存在しています。
クラスタを管理する単⼀のマスターノード 。
複数のデータコピーのインデックス作成と保持、およびデータのサーチを処理する複数台〜多数のピアノー
ド。
⼀連のピアノードにまたがってサーチを調整、管理する 1 つまたは複数のサーチヘッド 。
マスターノード はクラスタを管理しています。ピアノードの複製アクティビティを調整し、サーチヘッドにデー
タの検索場所を指⽰します。また、ピアノードの設定を管理し、またピアノード停⽌時の復旧処置を担当します。
ピアノード は、単独のインデクサーと同様に、データを受け取って、インデックスを作成します。ただし、スタ
ンドアロンのインデクサーとは異なり、ピアノードはクラスタ内の他のノードからのデータも複製します。ピア
ノードは到着データのインデックスを作成しながら、同時に他のノードからの複製データを保管します。最低で
も、複製データ保持数と同じ数のピアノードが必要です。複製データ保持数が 3 の場合、最低 3 台のピアノード
が必要になります。
サーチヘッド は、⼀連のピアノードにまたがってサーチを⾏います。インデクサークラスタにまたがるサーチを
管理するために、サーチヘッドを使⽤する必要があります。
⼀般的には、クラスタにデータを取り込むためにフォワーダー を使⽤することをお勧めします。
基本的な単⼀サイトのインデクサークラスタの概要を以下に⽰します。このクラスタには 3 台のピアノードが存
在し、複製データ保持数は 3 となっています。
39
この図は単純なデプロイ例で、⼩規模な⾮クラスタデプロイと似ています。⼀部のフォワーダーがロードバランシ
ングデータをインデクサー (ピアノード) グループに送信し、インデクサーがサーチヘッドにサーチ結果を送信し
ます。ただし、クラスタ環境は⾮クラスタデプロイ環境とは 2 つの点で異なっています。
インデクサーはデータのコピーを他のインデクサーに転送します。
マスターノードはデータ転送を⾏いませんが、サーチピアおよびサーチヘッドが関与しているさまざまなア
クティビティを管理、調整します。
マルチサイト・インデクサー・クラスタ
マルチサイト・インデクサー・クラスタ により、複数の場所にあるインデックスデータのコピーを完全に保持
することができます。これは、障害対策の強化とサーチアフィニティの向上という利点をもたらします。各サイト
のデータコピー数を指定することができます。マルチサイトクラスタは、多くの観点で基本的な単⼀サイトクラス
タと同じですが、設定とその動作にいくつかの違いがあります。「マルチサイト・インデクサー・クラスタ」を参
照してください。
クラスタの設定⽅法
クラスタの設定は簡単です。作業内容は、スタンドアロンのインデクサーグループを設定する場合と似ています。
基本的には、インデクサーをインストールして、いくつかの設定を⾏います。
主な違いとしては、クラスタノードを指定して、有効化する必要があることが挙げられます。1 つの Splunk
Enterprise インスタンスをマスターノードとして、その他のインスタンスをピアノードとして指定します。ピア
ノード数は、最低でも複製データ保持数と同じ台数が必要になります。⽔平スケーリングのためにインデックス能
⼒を増強する場合は、単にピアノードを追加していきます。
ピア間にまたがるサーチを管理して、それをまとめた結果をユーザーに返すために、1 つまたは複数のサーチヘッ
ドも設定する必要があります。
クラスタノードを有効にするには、Splunk Enterprise 内で任意の設定を⾏う場合と同様に、Splunk Web、
CLI、または設定ファイルを編集することで⾏います。
「インデクサークラスタのデプロイの概要」を参照してください。
クラスタのサーチ⽅法
クラスタのサーチは、クラスタ化されていない⼀連のインデクサーグループをサーチするのと同じ⽅法で⾏いま
す。サーチはサーチヘッド経由で実⾏します。
ただし、その裏側で⾏われる処理は少し異なっています。サーチを実⾏すると、サーチヘッドはマスターノードに
問い合わせて、現在の⼀連のピアノードを特定します。次に、サーチヘッドはサーチタスクをそれらのピアに配布
します。各ノードは各⾃の担当タスクを処理して、結果をサーチヘッドに返します。サーチヘッドは、結果を統合
して Splunk Web に返します。ユーザーの観点からは、スタンドアロンのインデクサーまたはクラスタ化されて
いないインデクサーグループに対してサーチを実⾏する場合と、何ら変わりはありません。「インデクサークラス
タでのサーチの仕組み」を参照してください。
マルチサイトクラスタを利⽤すれば、サーチアフィニティも導⼊することができます。サーチアフィニティでは、
40
サーチヘッドは可能な限りそのサイトにあるインデクサーのみから、サーチ結果を取得します。また、サーチは完
全なデータのセットにアクセスできます。「マルチサイト・インデクサー・クラスタへのサーチアフィニティの導
⼊」を参照してください。
先に進む前に
クラスタの設定と使⽤は簡単ですが、まず Splunk Enterprise のインデックス作成とデプロイの基本を正しく理
解しておく必要があります。続⾏する前に、以下の事項を正しく理解するようにしてください。
インデクサーの設定⽅法： 「インデクサーによるインデックスの保管⽅法」およびこのマニュアルに記載
されているその他のインデックス管理に関するトピックを参照してください。
サーチヘッドの処理： 分散サーチとサーチヘッドの詳細は、『分散サーチ』マニュアルの「分散サーチに
ついて」を参照してください。
インデクサーにデータを取り込むためのフォワーダーの使⽤⽅法： 『データの取り込み』マニュアルの
「フォワーダーの使⽤」を参照してください。
⾮クラスタ Splunk Enterprise デプロイ環境からの移⾏
クラスタ構成のインデクサーは、クラスタ構成ではないインデクサーとは要件が異なっています。インデクサーを
移⾏する前に、それらの事項を理解しておく必要があります。詳細は、「クラスタ構成と⾮クラスタ構成の
Splunk Enterprise インデクサーデプロイの主な相違点」を参照してください。それを参照した後は、「⾮クラス
タインデクサーのクラスタ化環境への移⾏」に進んで実際の移⾏プロセスの詳細を確認してください。
マルチサイト・インデクサー・クラスタ
Splunk Enterprise 6.1 で、インデクサークラスタにはサイト認識機能が組み込まれています。これにより、各サ
イト単位でマルチサイト・インデクサー・クラスタ を明⽰的に設定することができます。これによりクラスタ
の導⼊とデータセンターなどの複数の物理サイトへの拡張、展開が簡単になります。
使⽤事例
マルチサイトクラスタは単⼀サイトクラスタと⽐べて、主に 2 つの利点があります。
障害対策の強化： データのコピーを複数の場所に保管することで、ある場所で障害や災害が発⽣しても、
データへのアクセスを維持することができます。マルチサイトクラスタは、サイトのフェイルオーバー機能
を提供しています。あるサイトがダウンしても、残りのサイト上でインデックスの作成とサーチを継続する
ことができます。処理の中断もデータの損失もありません。
サーチアフィニティ： 各サイトがサーチヘッドと完全なサーチ可能データのセットの両⽅を持つような構
成にすると、各サイトのサーチヘッドによるサーチはローカルのピアノードにのみ限定されます。そうする
ことにより、通常の状況下でサーチヘッドは他のサイト上のデータにアクセスする必要がなくなるため、サ
イト間のネットワークトラフィックを⼤幅に減らすことができます。
マルチサイト設定
マルチサイトクラスタの設定は、基本の単⼀サイトクラスタとは多少異なります。マルチサイトクラスタの場合の
主な違いを以下に⽰します。
各ノードにサイトを割り当てます。
複製データ保持数とサーチ可能データ保持数はサイトごとに指定できます。つまり各サイトで保持するコ
ピー数とサーチ可能コピー数、およびクラスタ全体で保持するそれらの数を指定することができます。
このほかにもいくつかの設定上の違いが存在しています。「マルチサイト・インデクサー・クラスタのデプロイの
概要」を参照してください。
マルチサイトのアーキテクチャ
単⼀サイトクラスタとマルチサイトクラスタのアーキテクチャは似ています。マルチサイトクラスタの場合の主な
違いを以下に⽰します。
各ノードは、割り当てられたサイトに所属します。
バケツコピーのレプリケーションは、サイト認識により⾏われます。
サーチヘッドは、可能な限りサーチをローカルピアにのみ分散します。
マルチサイトクラスタのアーキテクチャの詳細は、「マルチサイト・インデクサー・クラスタのアーキテクチャ」
を参照してください。
その他の参考情報
以下の章やトピックには、マルチサイトクラスタの詳細が記載されています。
「マルチサイト・インデクサー・クラスタのデプロイと設定」この章には、サーチアフィニティの設定、マ
ルチサイトの複製データ保持数とサーチ可能データ保持数などを含めた、マルチサイト設定の詳細が含まれ
ています。
「マルチサイト・インデクサー・クラスタの管理」この章は、マスターサイト障害発⽣時の対処、およびマ
ルチサイトクラスタの単⼀サイトクラスタへの変換などの問題を取り上げています。
「単⼀サイトからマルチサイトへのインデクサークラスタの移⾏」このトピックは、単⼀サイトクラスタの
マルチサイトクラスタへの変換⽅法について説明しています。
このマニュアル内のその他のトピックでは、必要に応じてマルチサイトクラスタと単⼀サイトクラスタの違いにつ
いて説明しています。
41
インデクサー・クラスタ・アーキテクチャの基礎
ここでは、インデクサークラスタ のアーキテクチャについて紹介していきます。単⼀サイトクラスタの各ノー
ド、およびそれらが連携する⽅法について説明します。また、基本的な概念やクラスタにおけるインデックス作
成/サーチの処理についても説明していきます。
マルチサイトクラスタのアーキテクチャは、単⼀サイトクラスタのアーキテクチャと似ています。ただし、いくつ
かの点では⼤幅に違っています。マルチサイトクラスタのアーキテクチャおよび単⼀サイトクラスタとの違いにつ
いては、「マルチサイト・インデクサー・クラスタのアーキテクチャ」を参照してください。
クラスタのアーキテクチャの詳細については、「インデクサークラスタの仕組み」を参照してください。
クラスタノード
クラスタには、3 種類のノードが含まれています。
クラスタを管理する単⼀のマスターノード 。
データのインデックス作成、複製、およびサーチを実⾏する複数のピアノード 。
すべてのピアノードにまたがってサーチを調整、管理する 1 つまたは複数のサーチヘッド 。
また、⼀般的にクラスタデプロイ環境では、フォワーダー を使ってデータを取り込み、それをピアに転送しま
す。
マスターノード、ピアノード、およびサーチヘッドはすべて、特殊な Splunk Enterprise インスタンスです。す
べてのノードが、個別のマシン上の個別のインスタンスに存在している必要があります。たとえば、マスターノー
ドがピアノードやサーチヘッドと同じインスタンス上に存在することはできません。
単純な単⼀サイトクラスタの例を以下に⽰します。このクラスタには数台のピアと、それにデータを送信するフォ
ワーダーが存在しています。
この図で⽰されている処理のいくつかは、まだ説明されていません。どうぞ読み進めてください。
マスターノード
マスターノード はクラスタを管理しています。ピアノードの複製アクティビティを調整し、サーチヘッドにデー
タの検索場所を指⽰します。また、ピアノードの設定を管理し、またピアノードがオフライン時の復旧処置を担当
します。
ピアノードとは違い、マスターノードは外部データ のインデックスを作成しません。クラスタには、マスター
ノードが 1 つのみ存在しています。
ピアノード
ピアノード は、クラスタのインデックス作成機能を担当します。これらのノードはデータを受信し、インデック
スを作成します。また、クラスタ内の他のピアノードと複製データを相互に送受信します。ピアノードは、⾃⼰の
42
データのインデックスを作成しながら、同時に複製されたデータを送受信できます。すべてのインデクサーと同様
に、ピアもサーチヘッドからのサーチ要求に対して、各⾃のインデックスデータに対するサーチを実⾏します。
デプロイするピアノード数は、クラスタの複製データ保持数 とインデックス作成負荷の 2 つの要素によって決ま
ります。たとえば、複製データ保持数が 3 の場合 (データのコピーを 3 つ保持する)、最低 3 台のピアが必要で
す。3 台のインデクサーで対処しきれないインデックス作成負荷がある場合は、処理能⼒を向上するためにピアを
追加する必要があります。
サーチヘッド
サーチヘッド は、⼀連のピアノードにまたがってサーチを管理します。これは、サーチクエリーをピアに配布
し、また返された結果を統合します。すべてのサーチはサーチヘッドから⾏います。クラスタには最低 1 台の
サーチヘッドが必要です。
フォワーダー
フォワーダー は、どのような Splunk Enterprise デプロイ環境でも同じように機能します。フォワーダーは外部
ソースからデータを取り込んで、それをインデクサー (クラスタの場合はピアノード) に転送します。クラスタへ
のデータの取り込みにフォワーダーを使⽤する必要はありませんが、たいていの場合は利⽤した⽅が便利です。イ
ンデクサー応答確認 機能はフォワーダーでのみ有効にでき、これによって取り込んだデータのインデックスが確
実かつ⾼信頼に作成されます。また、ピアノード障害に対処する観点からも、ロードバランシング フォワーダー
を使⽤することをお勧めします。そうすることで、あるピアが停⽌しても、フォワーダーはロードバランシンググ
ループ内の他のピアに転送先を切り替えることができます。クラスタ環境におけるフォワーダーの詳細は、このマ
ニュアルの「フォワーダーを使ったインデクサークラスタへのデータの取り込み」を参照してください。
重要な概念
クラスタの機能を理解するためには、いくつかの概念に慣れ親しんでおく必要があります。
複製データ保持数 ：クラスタが保持するデータコピー数で、クラスタの障害耐性のレベルを表しています。
サーチ可能データ保持数 ：クラスタが保持するデータのサーチ可能コピー数で、クラスタであるノードが
停⽌した時にどれだけ素早くサーチ能⼒を回復できるかを表しています。
バケツ ：バケツはインデックスストレージの基本単位です。クラスタは、複製データ保持数に相当する各バ
ケツのコピーを保持しています。
ここでは、これらの概念を簡単に紹介していきます。
複製データ保持数
マスター設定の⼀環として、クラスタに保持するデータのコピー数を指定します。このコピー数は、クラスタの複
製データ保持数 と呼ばれています。複製データ保持数は、インデックスレプリケーションの主要概念です。この
値により、クラスタがどの程度の障害まで対応できるかが決まります。クラスタは、「複製データ保持数 - 1」台
までのピアノードに障害が発⽣しても、それに対処することができます。たとえば、システムで 2 台までのピア
障害発⽣に対処できるようにするためには、複製データ保持数に 3 を設定する必要があります。この場合、クラ
スタは 3 つの同⼀のデータコピーを、別個のノードに保管します。この場合、2 台のピアが停⽌しても、3 台⽬
のピアのデータを利⽤することができます。複製データ保持数のデフォルト値は、3 です。
3 台のピアで複製データ保持数が 3 のクラスタの例を以下に⽰します。
43
この図では、1 台のピアがフォワーダーからデータを受信、処理して、それを他の 2 台のピアに転送していま
す。クラスタには、ピアのデータの完全なコピーが 3 つ存在しています。この図では、すべてのデータが単⼀の
ピアを通じてシステムに到着するように、複製を⼤幅に簡素化して表しています。たいていの 3 台ピアのクラス
タでは、3 台のピアすべてがフォワーダーから外部データを受信し、また他のピアからの複製データも受信しま
す。
複製データ保持数および値の調整に関係するトレードオフについては、「複製データ保持数」を参照してくださ
い。
重要： マルチサイトクラスタでは、⼤幅に異なる複製データ保持数を使⽤します。「マルチサイトの複製データ
保持数とサーチ可能データ保持数」を参照してください。
サーチ可能データ保持数
マスターを設定する際には、サーチ可能データ保持数 も指定します。サーチ可能データ保持数は、クラスタが保
持するデータのサーチ可能 コピー数を表しています。
データのサーチ可能コピーは、サーチ不可能 コピーよりも⼤きなストレージスペースを必要とします。そのた
め、ニーズに応じた適切なサーチ可能データ保持数を設定する必要があります。たいていの場合は、デフォルト値
の 2 を使⽤してください。これにより、あるピアノードが停⽌しても、ほんのわずかな中断でサーチを継続する
ことができます。
データのサーチ可能なコピーとサーチ不可のコピーの違い：サーチ可能なコピーにはデータとクラスタがデータの
サーチに使⽤する拡張インデックスファイルが含まれています。サーチ不可能コピーには、データのみが含まれて
います。サーチ不可能コピーに含まれているデータにも初期処理が⾏われており、必要に応じてインデックスファ
イルを作成できる形式で保管されています。
サーチ可能データ保持数および値の調整に関係するトレードオフについては、「サーチ可能データ保持数」を参照
してください。
重要： マルチサイトクラスタでは、⼤幅に異なるサーチ可能データ保持数を使⽤します。「マルチサイトの複製
データ保持数とサーチ可能データ保持数」を参照してください。
バケツ
Splunk Enterprise はインデックスデータをバケツ に保管します。バケツは、データファイルを保管するディレ
クトリです。⼀般的にインデックスは多数のバケツから構成されています。
完全 クラスタは、複製データ保持数の値だけ各バケツのコピーを保持しており、各コピーは別個のノードに保管
されています。バケツのコピーは、サーチ可能またはサーチ不可能になります。完全クラスタには、サーチ可能
データ保持数の値だけの各バケツのサーチ可能コピーも存在しています。
バケツには 2 種類のファイルが含まれています。raw データファイル には、データといくつかのメタデータが含
まれています。バケツのサーチ可能コピーの場合は、データのインデックスファイル が含まれています。
クラスタは、バケツ単位で複製されます。オリジナルのバケツと他のピアノード上にあるそのコピーは、同じ raw
データセットを持っています。サーチ可能コピーにはインデックスファイルも含まれます。
44
ピアは新しいバケツを作成すると、マスターと通信してそのバケツのデータを転送するピアのリストを取得しま
す。クラスタのピアノード数が複製データ保持数より⼤きい場合、ピアは新たなバケツの開始時に毎回異なるセッ
トのピアにデータを転送することがあります。複製データ保持数が 3 の場合でも、ピアのオリジナルバケツのコ
ピーは漸次その他のピアに拡がっていきます。
クラスタの構造を理解するためには、バケツを正しく理解する必要があります。バケツの概要については、「イン
デクサーによるインデックスの保管⽅法」を参照してください。次に、「バケツとインデクサークラスタ」を参照
してください。ここには、クラスタデプロイ環境において重要なバケツの概念が、詳細に説明されています。
インデックス作成の仕組み
クラスタのインデックス作成機能は、⾮クラスタのインデックス作成と似ていますが、クラスタが複数のデータコ
ピーを保管するという違いがあります。各ピアノードは、⾮クラスタインデクサーと同様に、外部データを取り込
んで処理し、インデックスを作成します。主な違いとしては、ピアノードは処理したデータのコピーもクラスタ内
の他のピアに転送、または複製することが挙げられます。それらのコピーは、それら独⾃のバケツに格納されま
す。処理済みデータを受信する⼀部のピアは、受信データに対してインデックスを作成する場合もあります。複製
データ保持数は、データのコピーを受け取るピア数を決定します。サーチ可能データ保持数は、データのインデッ
クスを作成するピア数を決定します。
ピアノードは、外部データのインデックスを作成しながら、同時に他のピアから送信された複製データを保管し、
必要に応じてインデックスを作成することができます。たとえば、複製データ保持数が 3 で、3 台のピアを持つ
クラスタが存在している場合、各ピアは外部データを取り込み、インデックスを作成しながら、他のピアから転送
されたデータのコピーを保管することができます。クラスタのサーチ可能データ保持数が 2 の場合、転送された
データのコピーを受け取るもう⼀⽅のピアが、そのインデックスも作成します(データを最初に取り込んだピア
は、常に⾃分が保持するデータのインデックスを作成します)。フォワーダーおよび他のピアからのデータの移動
を以下の図に⽰します。
すべてのピアノードが外部データを取り込むようにクラスタを設定することができます。これがもっとも⼀般的な
設定です。これを⾏うには、単に各ピアノードの⼊⼒を設定します。ただし、ピアノードのサブセットのみがデー
タを取り込むようにクラスタを設定することもできます。⼊⼒をどのようにクラスタにまたがって分散している場
合でも、すべてのピアが複製データを保管できます。マスターはバケツ単位で、複製データを受け取るピアノード
を決定します。マルチサイトクラスタリングの場合を除いて、これを設定することはできません。マルチサイトク
ラスタリングでは、各サイトの⼀連のピアが受け取るデータのコピー数を指定することができます。
ピアは外部データのインデックスを複製するだけでなく、各⾃の
製します。
_audit
や
_internal
などの内部インデックスも複
マスターは、ピア間のやり取りを管理します。特に、どのピアがそのデータを転送したかを各ピアに知らせます。
マスターがこれを知らせると、当該ピアノードが停⽌しない限り、ピアはマスターの関与なしに相互にデータを交
換します。マスターは、どのピアにサーチ可能データが存在しているかも追跡しており、常にサーチ可能データ保
持数の値だけのサーチ可能データのコピーが利⽤できることを保証しています。ピアが停⽌した場合は、マスター
が復旧作業を担当します。
詳細は、「クラスタでのインデックス作成の仕組み」を参照してください。
マルチサイトクラスタ環境でのインデックス作成の仕組みについては、「マルチサイトのインデックス作成」を参
照してください。
45
サーチの仕組み
インデクサークラスタ内で、サーチヘッドはすべてのサーチを担当します。このプロセスは、⾮クラスタ環境
で、分散サーチ が機能する仕組みと似ています。主な違いは、サーチヘッドは、マスターを利⽤してサーチピア
を⽰すことにあります。また、各バケツの 1 つのコピーに対してのみサーチが⾏われるようにするために、さま
ざまなプロセスが採⽤されています。
各バケツのコピーを 1 つのみサーチに利⽤するために、クラスタ内の各バケツの 1 つのサーチ可能コピーが「プ
ライマリ 」として設定されます。サーチは、⼀連のプライマリコピーに対してのみ⾏われます。
⼀連のプライマリコピーは、時間の経過とともに変更される可能性があります (例：ピアノードのダウンに伴っ
て)。停⽌したノード上の⼀部のバケツのコピーがプライマリだった場合、それらのバケツの他のサーチ可能コ
ピーを代わりにプライマリにする必要があります。他のサーチ可能コピーが存在しない場合 (クラスタのサーチ可
能データ保持数が 1 のため) は、まずサーチ不可能コピーをサーチ可能コピーに変換しないと、プライマリコピー
として指定することはできません。
マスターはピアがクラスタに参加/再参加した時に、サーチ負荷の分散を改善するために、⼀連のピアにプライマ
リを再配分します。「インデクサークラスタのプライマリバケツの再調整」を参照してください。
マスターはすべてのピアノード上のすべてのバケツコピーを追跡しており、ピアノード⾃体も各⾃のバケツコピー
の状態を把握しています。このようにして、サーチリクエストに応えて、ピアはどのバケツコピーをサーチすれば
よいのかを把握しています。
サーチヘッドは定期的にマスターから、アクティブなサーチピアのリストを取得します。次にサーチヘッドはサー
チを処理するために、分散サーチの場合と同じようにそれらのピアと直接通信し、サーチリクエストと複製バンド
ルピアに送信して、ピアから返されたサーチ結果をまとめます。
たとえば、3 つのピアが存在するクラスタで、サーチヘッドからの特定のサーチリクエストを満たすために必要な
20 個のバケツを管理している場合を考えてみましょう。それら 20 個のバケツのプライマリコピーを、最初のピ
アに 10 個、2 番⽬のピアに 6 個、3 番⽬のピアに 4 個配置することができます。各ピアがサーチリクエストを
受け取り、そのバケツのコピーがプライマリでサーチ処理を⾏うかどうかを判断します。
詳細は、「インデクサークラスタでのサーチの仕組み」を参照してください。
重要： マルチサイトクラスタでのサーチの動作には、いくつかの重要な違いがあります。たとえば、⼀般的にク
ラスタ内の各サイトは完全なプライマリバケツのセットを保持しています。そのため、サーチヘッドはそのサイト
にローカルなデータに対して、すべてのサーチを実⾏できます。詳細は、「マルチサイトのサーチ」を参照してく
ださい。
クラスタでのピアノード障害の取り扱い
ピアノードが停⽌した場合、マスターはそのピアのバケツを他のピア上に復元しようと試みます。たとえば、停⽌
したノードに 20 個のバケツコピーが保管されており、その中の 10 個がサーチ可能の場合 (3 つのプライマリバ
ケツのコピーを含む)、マスターはそれらの 20 個のバケツのコピーを他のノードに作成しようと試みます。同様
に、10 個のサーチ可能コピーを他のノード上の同じバケツのサーチ可能コピーでの置換しようと試みます。ま
た、対応する他のピア上のサーチ可能コピーのステータスを⾮プライマリからプライマリに変更することで、プラ
イマリコピーを置換します。
複製データ保持数とノード障害
複製データ保持数に指定された値よりも残りピアノード数が少なくなった場合、クラスタは失われた 20 個のコ
ピーを置換できなくなります。たとえば、3 台ノード構成のクラスタで複製データ保持数が 3 の場合、あるノー
ドが停⽌すると代わりのコピーを保管するノードが存在しないため、失われたコピーを置換することはできませ
ん。
極端な状況を除いて、クラスタは他のピア上のそれらのバケツのコピーを「プライマリ」として指定することで、
失われたプライマリバケツのコピーを補い、サーチヘッドですべてのデータに完全にアクセスできる状態を維持す
る必要があります。
クラスタが完全なプライマリコピーのセットを保持できなくなるのは、複製可能データ保持数以上のノードが停⽌
した場合のみです。たとえば、5 台のピアノードを持つクラスタで複製データ保持数が 3 に設定されている場
合、1 台または 2 台のピアが停⽌しても完全なプライマリコピーセットを保持できますが、3 台⽬が停⽌すると
その状態を維持できなくなってしまいます。
サーチ可能データ保持数とノード障害
サーチ可能データ保持数は、あるノードの停⽌後に完全なサーチ機能を素早く再開できるかどうかに影響します。
あるノードが停⽌した場合に迅速に復旧するために、サーチ可能データ保持数には 2 以上の値を設定する必要が
あります。そうすることにより、マスターは停⽌したノードのプライマリの代わりに、他のノードの既存のサーチ
可能コピーを利⽤することができます。
代わりにサーチ可能データ保持数に 1 を設定すると、クラスタはサーチ可能バケツのコピーを 1 つのみ保持しま
す。⼀部のプライマリコピーを保持しているピアが停⽌した場合は、まず残りのピア上の対応する⼀連のサーチ不
可能コピーをサーチ可能コピーに変換しないと、それらを失われたコピーの代わりとなる (置き換わる) プライマ
リとして指定することはできません。この時間がかかる処理が⾏われている間は、クラスタには不完全なプライマ
リバケツのセットが存在することになります。サーチは実⾏できますが、利⽤可能なプライマリバケツのみが対象
になります。クラスタは順次失われたすべてのバケツに代わるコピーを作成していきます。そうなると、完全な
データのセットに対してサーチを実⾏できるようになります。
⼀⽅、サーチ可能データ保持数に 2 以上の値を設定すると、クラスタは即座に残りのノード上に存在するサーチ
可コピーにプライマリステータスを割り当てることができます。停⽌したノードからのサーチ可能コピーの置換処
理は⾏われますが、その間もクラスタのすべてのデータに対してサーチを継続できます。
46
ピア障害時の詳細は、「ピアノード停⽌時の処理」を参照してください。
マルチサイトクラスタでのピアノード障害への対処については、「マルチサイトクラスタ環境でのピアノード障害
の取り扱い」を参照してください。
クラスタでのマスターノード障害の取り扱い
マスターノードが停⽌した場合、ある程度の期間は、ピアノードは引き続きインデックスを作成し、データを複製
することができます。また、サーチヘッドもデータ全体をサーチできます。ただし、徐々に問題が発⽣するように
なります (特に、いずれかのピアが停⽌した場合など)。マスターが存在しないと、ピア停⽌による問題から回復す
ることはできません。サーチヘッドは不完全なセットに対してサーチを⾏うことになります。⼀般的には、マス
ターが存在しない場合でもクラスタはできる限り最善の動作を⾏いますが、システムは不整合状態となり、結果を
保証できなくなってしまいます。
マスター障害時の詳細は、「マスターノード停⽌時の処理」を参照してください。
マルチサイト・インデクサー・クラスタのアーキテクチャ
このトピックは、マルチサイト・インデクサー・クラスタ のアーキテクチャについて説明しています。主にマ
ルチサイトクラスタと単⼀サイトクラスタの違いについて取り上げています。単⼀サイトクラスタに関するクラス
タアーキテクチャの概要については、「インデクサー・クラスタ・アーキテクチャの基礎」を参照してください。
マルチサイトクラスタと単⼀サイトクラスタのアーキテクチャの違い
マルチサイトクラスタは、単⼀サイトクラスタと⽐べて主に以下の点が異なっています。
各ノード (マスター/ピア/サーチヘッド) にサイトが割り当てられています。
バケツコピーのレプリケーションはサイト認識により⾏われます。
サーチヘッドは、可能な限りサーチをローカルピアにのみ分散します。
バケツ修復作業は、サイト境界を考慮して⾏われます。
マルチサイトクラスタのノード
マルチサイトクラスタと単⼀サイトクラスタのノードは、以下の特徴を共有しています。
クラスタには、マスター、ピア、サーチヘッドの 3 種類のノードがあります。
各クラスタには、マスターノードが 1 つのみ存在しています。
クラスタは、任意の数のピアノードとサーチノードを保有することができます。
マルチサイトノードは以下の点が異なっています。
各ノードが、特定のサイトに所属します。⼀般的には物理的な場所により、サイトが決められます。たとえ
ば、クラスタにボストンとフィラデルフィアのサーバーを含める場合、ボストン内のすべてのノードをサイ
ト 1 に、フィラデルフィア内のすべてのノードをサイト 2 に割り当てます。
⼀般的なマルチサイトクラスタでは、各サイトにサーチヘッドを配置します。これは、サーチアフィニ
ティ を実現するために必要です。サーチアフィニティにより、サーチヘッドはすべてのデータにローカルで
アクセスでき、サーチ効率が向上します。
2 つのサイトで構成されるクラスタの例を以下に⽰します。
47
以下の事項に注意してください。
マスターノードはクラスタ全体を管理しています。マスターは物理的にはあるサイトに存在していますが、
実際にはいずれのサイトのメンバーでもありません。ただし、各マスターにはサーチヘッドが内蔵されてお
り、そのサーチヘッドには (結果的にマスターとまとめて) サイトを指定する必要があります。マスターの
サーチヘッドはテスト⽬的でのみ⽤意されていることに注意してください。実際の運⽤環境では使⽤しない
でください。
各サイトには独⾃のサーチヘッドがあり、そのサイトの⼀連のピアノードに対してサーチを実⾏します。こ
れは、サーチアフィニティを実現するように設定されたクラスタの例です。
ピアはサイト境界にまたがってデータを複製します。この動作は、障害対策とサーチアフィニティの両⽅の
基盤となります。
マルチサイトの複製データ保持数とサーチ可能データ保持数
単⼀サイトの場合と同様に、マルチサイトクラスタでも複製データ保持数とサーチ可能データ保持数により、クラ
スタ内のバケツコピー数とサーチ可能バケツコピー数が決まります。ただし、マルチサイトの複製データ保持数と
サーチ可能データ保持数は、各サイトのコピー数も決定するという違いがあります。3 サイト構成のマルチクラス
タ環境の複製データ保持数の例を次に⽰します。
site_replication_factor = origin:2, site1:1, site2:1, site3:1, total:4
この複製データ保持数は、サイトがデータの元サイトである場合を除き、各サイトが各バケツのコピーを 1 つ保
持することを⽰しています (元サイトの場合は 2 つのコピーを保持)。また、クラスタの合計コピー数が 4 になる
ことも表しています。
この例で、複製データ保持数は明⽰的にすべてのサイトを指定していますが、これは必須という訳ではありませ
ん。明⽰サイト は、複製データ保持数で明⽰的に指定しているサイトです。⾮明⽰サイト は、複製データ保持数
で明⽰的に指定していないサイトです。
3 サイト構成のクラスタのマルチサイト複製データ保持数の別な例を以下に⽰します。この複製データ保持数で
は、2 つのサイトのみを明⽰的に指定しています。
site_replication_factor = origin:2, site1:1, site2:2, total:5
この例で、⾮明⽰サイト site3 が保持するコピー数は状況によって異なります。site1 が元のオリジナルサイトの
場合、site1 は 2 つのコピーを、site2 は 2 つのコピーを、そして site3 が残り 1 つのコピーを保持します。
site2 が元のオリジナルサイトの場合、site1 は 1 つのコピーを、site2 は 2 つのコピーを、site3 は 2 つのコ
ピーを保持します。site3 が元のオリジナルサイトの場合、site1 は 1 つのコピーを、site2 は 2 つのコピーを、
site3 は 2 つのコピーを保持します。
注意： 以下の例で total の値を 4 にすることはできません。最低でも 5 でなければなりません。これは、複製
データ保持数に⾮明⽰サイトがある場合、合計は最低でもすべての明⽰サイトと元のサイトの合計値にする必要が
あります。
複製データ保持数の構⽂と動作の詳細は、「サイトの複製データ保持数の設定」を参照してください。
48
サイトのサーチ可能データ保持数も仕組みは同じです。詳細は、「サイトのサーチ可能データ保持数の設定」を参
照してください。
マルチサイトのインデックス作成
マルチサイトのインデックス作成は、「インデクサー・クラスタ・アーキテクチャの基礎」で説明している単⼀サ
イトのインデックス作成と似ています。単⼀のマスターが、すべてのサイトのすべてのピアにまたがって、レプリ
ケーションを管理、調整します。
このセクションでは、マルチサイトクラスタにおける主な違いを簡単に説明していきます。ここでは、例として 3
サイト構成で、複製データ保持数が次のように設定されたクラスタを使⽤します：
site_replication_factor = origin:2, site1:1, site2:1, site3:1, total:4
マルチサイトの場合の主な注意事項を以下に⽰します。
データのレプリケーションは、複製データ保持数に基づいて、サイト境界にまたがって⾏われます。この例
で、site1 内のピアがデータを取り込んだ場合、それは site1 内の他のピアにそのデータのコピーを配信し
(origin の設定 2 を満たすため)、また 1 つのコピーを site2 内のピアに、1 つのコピーを site3 内のピアに
配信します。
マルチサイトのレプリケーションでは、オリジンサイトの概念があり、これによって最初にデータを取り込
んだサイトでデータを異なる⽅法で処理することが可能になります。以下に例を⽰します。データの起源が
site1 の場合、このサイトは 2 つのコピーを保持します。データの起源が他のサイトの場合、site1 は 1 つ
のコピーのみを保持します。
単⼀サイトレプリケーションのように、複製されたデータを受け取るピアを明⽰的に指定することはできま
せん。ただし、データを受け取るサイトは指定できます。そのサイト内のピアがデータを受け取ります。
クラスタによる移⾏された単⼀サイトバケツの処理については、「単⼀サイトからマルチサイトへのインデクサー
クラスタの移⾏」を参照してください。
マルチサイトのサーチ：サーチアフィニティ
マルチサイトのサーチは、多くの点で「インデクサー・クラスタ・アーキテクチャの基礎」で説明している単⼀サ
イトのサーチと似ています。各サーチは、⼀連のプライマリバケツのコピーにまたがって⾏われます。ただし、主
な違いが 1 つあります。
マルチサイトクラスタは、サーチアフィニティを提供します。これにより、サイトのローカルデータに対してのみ
サーチを実⾏させることが可能です。サーチアフィニティを利⽤するには、クラスタの設定が必要です。特に、
ローカルでサーチ可能データとサーチヘッドの両⽅が利⽤できるようにする必要があります。
サーチアフィニティを実現するためには、各サイトが最低 1 つのサーチ可能データの完全なセットを持つよう
に、サーチ可能データ保持数を設定します。そうすることでマスターは、各サイトが適切に動作している間、各サ
イトが完全なプライマリバケツコピーのセットを保持するように調整します。これは、有効 な状態と呼ばれてい
ます。
サーチアフィニティを満たす状態で、サーチヘッドはサーチリクエストをクラスタ内のすべてのピアに配布します
が、サーチヘッドと同じサイト内のピアのみがリクエストに応答し、そのプライマリバケツのコピーをサーチして
結果をサーチヘッドに返します。
サイトのピアの⼀部が失われると、そのサイトにプライマリの完全なセットはもはや存在しないこと (つまり、有
効な状態ではなくなる) になります。また、サイトを有効状態に戻すために、バケツの修復処理が試みられます。
修復処理中は、サーチヘッドが完全な結果セットを⼊⼿できるように、必要に応じてリモートサイトのピアがサー
チに参加します。サイトが有効状態に戻ったら、サーチヘッドは再びローカルピアのみを使ってサーチを⾏いま
す。
注意：サーチアフィニティは希望によって無効にできます。特定のサーチヘッドを無効にすると、サーチヘッドは
あらゆるサイトのピアからデータを取り込むことができます。
サーチアフィニティの詳細およびそのためのサーチ可能データ保持数の設定⽅法については、「マルチサイト・イ
ンデクサー・クラスタへのサーチアフィニティの導⼊」を参照してください。サーチアフィニティも含めたサーチ
の内部処理については、「インデクサークラスタでのサーチの仕組み」を参照してください。
マルチサイトクラスタとノード障害
マルチサイトクラスタでのノード障害への対処⽅法は、ある意味単⼀サイトクラスタとは⼤きく異なっています。
重要： このセクションをお読みになる前に、「予備の」バケツコピーの概念を理解する必要があります。予備の
コピーは、ピアへの割り当て待ちのコピーです。マルチサイト・ピア・ノード障害の結果として、⼀部のバケツコ
ピーがすぐにはピアに割り当てられないことがあります。たとえば、合計の複製データ保持数が 5 のクラスタで
は、マスターがオリジナルのピアに他の 3 台のピアにのみバケツを配布するように指⽰する場合があります。こ
の場合、4つのコピーが利⽤されており (オリジナルの他に配布された 3 つのコピー)、特定の条件を満たした場合
のピアへの割り当て待ちの 5 番⽬のコピーが存在することになります。5 番⽬の未割り当てのコピーは、予備の
コピーとなります。このセクションでは、ピアノードの障害発⽣時に、クラスタが予備のコピーを保持する必要が
ある場合について説明していきます。
マルチクラスタ環境でのピアノード障害の取り扱い
ピアが停⽌すると、可能な場合はそのサイト内でバケツの修復処理が⾏われます。クラスタは、当該サイト内の残
りのピアにコピーを追加することで、失われたバケツコピーの補填を試みます。(どの場合でも、各ピアはある特
49
定のバケツのコピーを最⾼で 1 つ保持することができます。)サイト内のピアにコピーを追加することですべての
バケツを修復できない場合は、複製データ保持数とサーチ可能データ保持数に応じて、クラスタは他のサイトのピ
アにコピーを作成する場合があります。
これらの状況下での修復処理は、障害が発⽣したピアが明⽰サイトにあるか、または⾮明⽰サイトにあるかによっ
てある程度異なります。
明⽰サイトでサイト固有の複製データ保持数を独⾃に満たすことができないほどのピアが停⽌した場合、クラスタ
は他のサイトのピアにコピーを作成してそれを補填する試みを⾏いません。そうではなく、必要な数のピアがまも
なくサイトに復帰することを前提にしています。新しいバケツの場合でも、サイトに復帰するピア⽤のコピーを保
持します。つまり、それらのコピーを他のサイトのピアには割り当てずに、最初のサイトのピアが利⽤できるよう
になるまで待機して、それらのピアにコピーを割り当てます。
たとえば、3 サイト構成のクラスタ (site1、site2、site3) で次の複製データ保持数を設定した場合を考えてみま
しょう：
site_replication_factor = origin:2, site1:1, site2:2, total:5
通常クラスタは、site2 で 2 つのコピーを保持します。ただし、site2 でかなりの数のピアが停⽌して、残りが 1
台となり、サイトが複製データ保持数 2 を満たせなくなった場合、その残りのピアがクラスタ内のすべてのバケ
ツのコピーを 1 つ保持し、このサイト⽤の他のコピーセットをクラスタが保持します。site2 で 2 台⽬のピアが
復帰した場合、そのピアにクラスタが保持していたコピーが配布されます。
⾮明⽰サイトでかなりの数のピアが停⽌し、それが保有していた数のバケツコピーを維持できなくなった場合、ク
ラスタは他のサイトにコピーを追加することでそれを補います。たとえば、前述の例で⾮明⽰サイト site3 がバケ
ツのコピーを 2 つ保有しており、そこで 1 台を残して他のすべてのピアが停⽌して、各バケツのコピーを 1 つし
か保持できない場合を考えてみましょう。クラスタはそれを補うために、そのバケツのコピーを他のサイト上のピ
アに配布します (当該バケツのコピーを持たないピアが最低 1 台あることが前提)。
サイトのすべてのピアが停⽌した場合のクラスタの処理については、「サイト障害時のクラスタの処理」を参照し
てください。
サイト障害時のクラスタの処理
サイト障害は、単純にピアノード障害の特殊な事例です。クラスタの修復は、前述のピアノード障害で説明した
ルールに従って⾏われます。クラスタはサイトの復旧に備えて、予備のコピーを保持する場合があることに注意す
る必要があります。
予備として保持されている既存の任意のバケツのコピーに対して、クラスタはその修復処理中に他のサイトにコ
ピーを追加することはありません。同様に、サイトの停⽌後に追加された新しいバケツに対して、クラスタにサイ
トが復帰するまでの間、クラスタはある程度のコピーを保持します。
クラスタが保持するコピーを決定する⽅法を以下に⽰します。
明⽰サイトの場合、クラスタはサイトのサーチ可能コピー保持数と複製データ保持数に指定されている数の
コピーおよびサーチ可能コピーを予備として保持します。
⾮明⽰サイトの場合、サイトのサーチ可能データ保持数と複製データ保持数の total コンポーネントが⼗分
に⼤きな場合、明⽰サイトを処理した後に、1 つのサーチ可能コピーを予備として保持します。(サーチ可能
データ保持数が⼗分に⼤きくないけれども、複製データ保持数は⼗分に⼤きい場合、クラスタは 1 つのサー
チ不可能コピーを予備として保持します。)
たとえば、2つの明⽰サイト (site1 および site2) と 1 つの⾮明⽰サイト (site3) からなる 3 サイト構成のクラス
タを考えてみましょう。このクラスタの設定は次のようになっています：
site_replication_factor = origin:2, site1:1, site2:2, total:5
site_search_factor = origin:1, site1:1, site2:1, total:2
サイトの停⽌に備えて、クラスタは次のようにバケツのコピーを保持します。
site1 が停⽌した場合、クラスタはサーチ可能コピーを 1 つ予備として保持します。
site2 が停⽌した場合、クラスタはサーチ可能なコピーを 1 つ含めた 2 つのコピーを保持します。
site3 が停⽌した場合、クラスタはサーチ不可能コピーを 1 つ保持します。
保持されているコピーが必要となったら、クラスタは残りのコピーを他の利⽤可能なサイトに複製します (既存の
バケツの修復時と新しいバケツの追加時の両⽅)。
サイトがクラスタに復帰すると、新しいバケツとサイト停⽌時にサイトに保持されていたバケツの両⽅に関して、
最低でも予備として保持されていたバケツコピーが割り当てられる程度まで、そのサイトのバケツ修復処理が⾏わ
れます。
マスターが存在しているサイトが停⽌した場合は、残りのいずれかのサイトでスタンバイマスターを⽴ち上げるこ
とができます。「マスターサイト障害の取り扱い」を参照してください。
マルチクラスタ環境でのマスターノード障害の取り扱い
マルチサイトクラスタは、単⼀サイトクラスタと同じ⽅法でマスターノード障害に対処します。クラスタは引き続
きその環境下で、最善の動作を⾏うように機能します。「マスターノード停⽌時の処理」を参照してください。
インデクサークラスタのデプロイ
50
インデクサークラスタのデプロイの概要
ここでは、インデクサークラスタ をデプロイするための主なステップについて説明していきます。以降のトピッ
クでは、これらのステップの詳細を⾒ていきます。
クラスタのデプロイを開始する前に、Splunk Enterprise 管理に関するさまざまな知識を理解しておく必要があり
ます。
インデクサーの設定⽅法： 「インデクサーによるインデックスの保管⽅法」およびこのマニュアルに記載
されているその他のインデックス管理に関するトピックを参照してください。
サーチヘッドの処理： 分散サーチの詳細は、『分散サーチ』マニュアルの「分散サーチについて」を参照
してください。インデクサークラスタ環境のサーチヘッドの設定は、他のサーチヘッドの設定とは異なるこ
とに注意してください。違いの詳細は、このマニュアルの「サーチヘッド設定の概要」を参照してくださ
い。
インデクサーにデータを取り込むためのフォワーダーの使⽤⽅法： 『データの取り込み』マニュアルの
「フォワーダーの使⽤」を参照してください。
重要： このチャプターでは、インデックスクラスタの個別サーチヘッドをデプロイしていると仮定します。サー
チヘッドクラスタ のメンバーであるサーチヘッドの統合⽅法については、『分散サーチ』マニュアルの「サーチ
ヘッドクラスタとインデクサークラスタの統合」を参照してください。
⾮クラスタ Splunk Enterprise デプロイ環境からの移⾏
クラスタ構成のインデクサー (ピア) は、クラスタ構成ではないインデクサーとは要件が異なっています。インデ
クサーを移⾏する前に、それらの事項を理解しておく必要があります。「クラスタ構成と⾮クラスタ構成のインデ
クサーデプロイの主な相違点」を参照してください。それを参照した後は、「⾮クラスタインデクサーのクラスタ
化環境への移⾏」に進んで実際の移⾏プロセスを確認してください。
重要： ⾮クラスタ構成からクラスタ構成にインデクサーを移⾏する前に、それが本当に必要か確認してくださ
い。この作業は⼀⽅向のプロセスです。クラスタ構成から⾮クラスタ構成にインデクサーを変換するための、サ
ポートされている⼿順はありません。
マルチサイトクラスタをデプロイするか？
マルチサイト・インデクサー・クラスタ は単⼀サイトクラスタよりもかなり複雑です。デプロイするには、い
くつかの問題点を検討して、また完全に異なる設定作業を⾏う必要があります。マルチサイトクラスタをデプロイ
する場合は、まずこのトピックを読んでから、「マルチサイト・インデクサー・クラスタのデプロイの概要」を参
照してください。
クラスタのデプロイ
クラスタをデプロイする場合、インデックスの作成を実⾏するクラスタのマスターとピアノードを有効にして、設
定します。また、クラスタ内のデータをサーチするサーチヘッドも有効にします。さらに、⼀般的にはクラスタに
データを送信するように、フォワーダーを設定します。デプロイする各種ノードを含んだ⼩さなクラスタの例を以
下の図に⽰します。
51
クラスタデプロイの主要ステップを以下に⽰します。
1. 要件を判断します。
a. データ可⽤性およびフェイルオーバーのニーズを把握します。「インデクサークラスタとインデックスレプリ
ケーションについて」を参照してください。
b. 基本的な単⼀サイトクラスタをデプロイするのか、またはマルチサイトクラスタをデプロイするのかを決定し
ます。マルチサイトクラスタは、複数の場所にデータのコピーを分散できるため、強⼒な障害対策機能を備えてい
ます。また、サーチアフィニティも有効にできます。サーチアフィニティにより、サーチをローカルデータに限定
し、ネットワークトラフィックを削減することができます。詳細は、「マルチサイト・インデクサー・クラスタ」
を参照してください。
c. 複製データ保持数 を決定します。複製データ保持数は、クラスタが保持する raw データのコピー数です。最適
な複製データ保持数は、ご利⽤の環境のさまざまな要因によって異なりますが、基本的には障害耐性とストレージ
容量のトレードオフとなります。複製データ保持数に⾼い値を設定すると、多数のピアノード上により多くのデー
タコピーが保管されることになり、データの可⽤性を失わずにノードの障害耐性を強化できます。ただし、追加
データを取り扱うためにより多くのノードとストレージが必要になります。マルチサイトクラスタの場合、各サイ
トに配置するコピー数も決定する必要があります。詳細は、「複製データ保持数」を参照してください。
警告： 最初から、ニーズに合わせた適切な複製データ保持数を設定するようにしてください。クラスタが⼤量の
データを保有するようになった後に、複製データ保持数の値を増やすことはお勧めできません。この場合、値が増
やされた複製データ保持数に応じてクラスタは⼤量のバケツをコピーしなければなりません。コピー中は、クラス
タの総合的なパフォーマンスも⼤幅に低下してしまいます。
d. サーチ可能データ保持数 を決定します。サーチ可能データ保持数は、クラスタにインデックスデータのサーチ
可能コピー保持数を指⽰します。この値は、クラスタがノード停⽌から回復するまでの速度に影響します。サーチ
可能データ保持数の値を⼤きくすると、クラスタがより迅速に回復できます。ただし、より多くのストレージス
ペースおよび処理能⼒を消費します。たいていの単⼀サイトデプロイ環境では、デフォルトのサーチ可能データ保
持数 2 が適性で、ノードの停⽌時にもわずかな中断でサーチを続⾏することができます。マルチサイトクラスタ
の場合、各サイトに配置するサーチ可能コピー数も決定する必要があります。詳細は、「サーチ可能データ保持
数」を参照してください。
警告： 最初から、ニーズに合わせた適切なサーチ可能データ保持数を設定するようにしてください。クラスタが
⼤量のデータを保有するようになった後に、サーチ可能データ保持数の値を増やすことはお勧めできません。この
場合、増やされたサーチ可能データ保持数に応じてクラスタは⼤量のデータ処理 (サーチ不可能バケツのコピーの
サーチ可能コピーへの変換) を⾏わなければならず、処理中はクラスタの総合的なパフォーマンスに悪影響を与え
てしまいます。
e. クラスタの規模を決定するその他の要因を判別します。たとえば、インデックスを作成するデータの量などを
判別します。⼀般的に、単⼀のクラスタにすべてのインデクサーを配置し、さらに⽔平⽅向のスケーリングを確保
したい場合は、複製データ保持数よりも多くのピアノードを追加する必要があります。同様に、予想されるサーチ
負荷に応じて、複数のサーチヘッドを追加しなければならないこともあります。
f. その他の問題については、「インデクサークラスタのシステム要件とその他のデプロイに関する検討事項」を参
照してください。
2. ネットワークに Splunk Enterprise クラスタインスタンスをインストールします。 最低でも、「複製
データ保持数 + 2」個のインスタンスが必要になります。
最低でも「複製データ保持数」台のピアノード が必要ですが、ステップ 1e で説明したように、インデック
ス作成能⼒を強化するために他のピアを追加することも可能です。
また、マスターノード ⽤とサーチヘッド ⽤に、その他 2 つのインスタンスも必要になります。
マルチサイトクラスタの場合は、ご⾃分のサーチアフィニティと障害対策のニーズに応じて決まる、各サイトの
サーチヘッドとピアノードの要件も考慮する必要があります。「マルチサイト・インデクサー・クラスタのデプロ
イの概要」を参照してください。
Splunk Enterprise のインストール⽅法については、『インストール』マニュアルを参照してください。
3. インスタンスのクラスタリングを有効にします。
a. マスターノードを有効にします。「マスターノードを有効にする」を参照してください。
b. ピアノードを有効にします。「ピアノードを有効にする」を参照してください。
c. サーチヘッドを有効にします。「サーチヘッドを有効にする」を参照してください。
重要： マルチサイトクラスタの場合、クラスタノードを有効にする⼿順は異なります。「マルチサイト・インデ
クサー・クラスタのデプロイの概要」を参照してください。
4. ピアノード設定を完了します。
a. ピアのインデックス設定を⾏います。このステップは、デフォルトのインデックスと App のセットを増やす必
要がある場合にのみ実施する必要があります。⼀般的には、すべてのピアが同じインデックスセットを使⽤する必
要があります。あるピアにインデックス (またはインデックスを定義する App) を追加した場合は、クラスタ固有
の配布⽅法を使ってすべてのピアにそれを追加してください。⼀連のピアに適⽤する必要がある、その他の設定が
存在している場合もあります。⽅法の詳細は、「ピアのインデックスレプリケーションの準備」を参照してくださ
い。
b. ピアのデータ⼊⼒を設定します。たいていの場合は、フォワーダーを使ってピアにデータを送信するのが最適
です。詳細は、「インデクサークラスタへのデータの取り込み⽅法」を参照してください。このトピックに記述さ
れているように、通常はインデクサー応答確認を有効にした、ロードバランシングフォワーダーをデプロイしま
す。
52
ノードを有効にしてピアのデータ⼊⼒を設定すると、クラスタはインデックスの作成とデータの複製を⾃動的に開
始します。
5. ピアノードにデータを転送するようにマスターノードを設定します。 このベスト・プラクティスには、さま
ざまな利点があります。「ベストプラクティス：マスターノードのデータのインデクサーレイヤーへの転送」を参
照してください。
その他のデプロイシナリオ
この章は、その他のクラスタ展開シナリオに関するガイドラインも説明しています。
既存のデータを保有するインデクサーをクラスタに追加する。「⾮クラスタインデクサーのクラスタ化環境
への移⾏」を参照してください。
単⼀サイトクラスタをマルチサイトに移⾏する。「単⼀サイトからマルチサイトへのインデクサークラスタ
の移⾏」を参照してください。
インデックスレプリケーションが要件ではなく、単にインデックスのスケーラビリティの観点からクラスタ
を導⼊する。「インデクサークラスタを使ったインデックスの増強」を参照してください。
クラスタ構成と⾮クラスタ構成のインデクサーデプロイの主な相違点
ここでは、クラスタ構成のインデクサーと⾮クラスタ構成のインデクサーの主な違いについて説明していきます。
特に、システム要件とデプロイの観点からの問題を取り上げています。
現在のインデクサーセットをクラスタに移⾏することを計画している場合は、このトピックを注意深くお読
みください。
クラスタピアでデプロイサーバーやサードパーティ製のデプロイツールを使⽤しないでく
ださい
クラスタピア (インデクサー) に設定や App を配布するための⼿段としてサポートされている、デプロイサーバー
やサードパーティ製のデプロイツール (Puppet や CFEngine など) はありません。
⼀連のクラスタピアに設定を配布するには、代わりに「共通のピア設定と App の更新」で説明されている設定バ
ンドル を使⽤してください。このトピックで説明されているように、設定バンドルを使⽤する⽅法では、まずマ
スターノードにピア App を保管した後、その App を各ピアノードに配布します。
デプロイサーバーから設定バンドルを使った App 配布への移⾏⽅法の詳細は、「クラスタへの App の移⾏」を
参照してください。
注意： スタンドアロン型サーチヘッドであれば、デプロイサーバーを使⽤して更新をインデクサークラスタの
サーチヘッドに配布可能です。デプロイサーバーを使って、サーチヘッドクラスタ のメンバーに更新を配布可能
です。
システム要件の相違
ピアノードのシステム要件は、⾮クラスタインデクサーとは⼀部違いがあります。インデクサーを移⾏する前に、
「インデクサークラスタのシステム要件とその他のデプロイに関する検討事項」を参照してください。特に、以下
の相違点に注意してください。
インデクサーをクラスタピアに変換する際には、ディスク使⽤量が⼤幅に増加します。⽇常的なインデック
ス作成量、サーチ可能データ保持数、および複製データ保持数に対応できる⼗分なディスクスペース量があ
ることを確認してください。ピアのディスク使⽤量の詳細は、「ストレージの検討事項」を参照してくださ
い。
クラスタノードは、Splunk Enterprise インスタンスを共有できません。マスターノード、ピアノード、お
よびサーチヘッドは、それぞれ独⾃のインスタンス上で動作する必要があります。
その他の検討事項と⾮クラスタデプロイとの相違点
また、以下の事項に注意してください。
⼤半のクラスタデプロイ環境では、データをピアに送信するフォワーダーで、インデクサー応答確認 を有
効にする必要があります。「インデクサー応答確認の仕組み」を参照してください。
インデクサーの検出機能を使⽤して、フォワーダーをピアノードに接続するプロセスの簡略化が可能です。
「インデクサー検出⽅法の利点」を参照してください。
いくつかの要因により、総合的なパフォーマンスが低下します。主因の 1 つがインデクサー応答確認です。
また、他のピアノードから受け取った複製データも、それを保管し、必要に応じてインデックスを作成する
必要があるため、ある程度パフォーマンスに影響します。
クラスタピアを再起動する場合は、Splunk Web を使⽤するか、または splunk offline や splunk rollingrestart などのクラスタ対応 CLI コマンドを使⽤する必要があります。splunk restart は使⽤しないでくださ
い。詳細は、「インデクサークラスタ全体または 1 台のクラスタノードの再起動」を参照してください。
⾮クラスタ構成インデクサーの移⾏
既存のインデクサーのクラスタへの移⾏およびその結果や悪影響については、「⾮クラスタインデクサーのクラス
タ環境への移⾏」を参照してください。
インデクサークラスタのシステム要件とその他のデプロイに関する検
討事項
53
インデクサークラスタは Splunk Enterprise インデクサーのグループなので、その⼤部分はインデクサーのシス
テム要件に準拠しています。インデクサーの詳細なソフトウェア/ハードウェア要件については、『インストー
ル』マニュアルの「システム要件」を参照してください。このトピックには、クラスタに関する他の要件を記載し
ています。
主要要件のまとめ
注意する必要がある主な要件を以下に⽰します。
各クラスタノード (マスター、ピア、またはサーチヘッド) は、個別の Splunk Enterprise インスタンス上
に配置する必要があります。
各ノードは個別のマシンまたは仮想マシン上で動作し、また各マシンが同じ OS で動作している必要があり
ます。
すべてのノードを、ネットワーク経由で接続する必要があります。
たとえば、1 台のマスターと 1 台のサーチヘッド、そして3 台のピア構成のクラスタをデプロイするには、ネッ
トワークで接続された 5 つのマシン上で、5 つの Splunk Enterprise インスタンスを動作させる必要がありま
す。また、すべてのマシンで同じ OS が動作していなければなりません。
その他の注意事項を以下に⽰します。
⾮クラスタ構成のデプロイと⽐べ、クラスタ構成のデプロイ環境では複数のデータコピーを保持するため
に、より多くのストレージが必要になります。
インデックスレプリケーション⾃体では、必要ライセンス数が増加することはありません。
ピアへのアップデート配布にデプロイサーバーを使⽤することはできません。
詳細は、このトピックの後半を参照してください。
必要な Splunk Enterprise インスタンス
各クラスタノードは、独⾃の Splunk Enterprise インスタンスに存在する必要があります。そのため、クラスタ
は最低でも「複製データ保持数 + 2」台のインスタンスで構成する必要があります (「複製データ保持数 」台の
ピアノード + 1 台のマスターノード + 1 つまたは複数のサーチヘッド)。たとえば、複製データ保持数が 3 のク
ラスタをデプロイする場合は、最低でも 5 つの Splunk インスタンスが必要になります (3 台のピア、1 台のマス
ター、および 1 台のサーチヘッド)。複製データ保持数の詳細は、このマニュアルの「複製データ保持数」を参照
してください。
クラスタのサイズは、複製データ保持数だけでなく、インデックスを作成するデータ量などの他の要因によっても
異なります。「インデクサークラスタのデプロイの概要」を参照してください。
重要： マスターはサーチ機能を保有していますが、この機能はデバッグ⽬的でのみ使⽤する必要があります。マ
スターのリソースは、主⽬的であるクラスタ動作の調整のためにのみ専念させる必要があります。マスターを実働
環境のサーチヘッドにすることは絶対にしないようにしてください。「マスターノードのその他のロール」を参照
してください。
Splunk Enterprise バージョンの互換性
バージョン 5.0 以上のインデクサーグループにクラスタリングを導⼊することができます。
Splunk Enterprise 6.1 以前 でのマスターノード実⾏
ピアノードとサーチヘッドは、マスターノードと同じバージョンを使⽤する必要があります。
Splunk Enterprise 6.2 以上 でのマスターノード実⾏
ピアノードとサーチヘッドはマスターと異なるバージョンを実⾏できますが、以下の制約があります。
ピアノードとサーチヘッドは、バージョン 6.1 以降を利⽤する必要があります。
ピアノードとサーチヘッドは、マスターノードと同じバージョンまたはそれ以下のバージョンを利⽤する必
要があります。
同⼀サイト内のピアノードとサーチヘッドは、すべて同じバージョンを利⽤する必要があります。
たとえば、ピアとマスターの互換性については、以下のようになります。
6.1
6.2
6.2
6.0
ピアノードは、6.2
ピアノードは、6.2
ピアノードは、6.1
ピアノードは、6.2
マスターと互換性があります。
マスターと互換性があります。
マスターとは互換性がありません。
マスターとは互換性がありません。
この例は、「ピアノード」を「サーチヘッド」に置き換えた場合にも当てはまります。
また、複数のクラスタのピアとサーチヘッド間の互換性については以下のようになります。
6.1 ピアノードは、同じサイトの 6.2 サーチヘッドまたはピアノードと互換性がありません。
6.1 サーチヘッドは、同じサイトの 6.2 ピアノードまたはサーチヘッドと互換性がありません。
すべてが 6.1 ピア/サーチヘッドのサイトと、すべてが 6.2 ピア/サーチヘッドのサイトから構成される混在
環境は、6.2 マスターと互換性があります。
6.1 のピアノードに対し、6.2 以降のマスターを実⾏
6.1 ピアノードに対して 6.2 以降のマスターを利⽤するには、マスターの
use_batch_mask_changes に false を設定する必要があります。
54
server.conf
ファイル内の
マスターの再起動を回避するには、CLI で以下の属性を設定します。
splunk edit cluster-config -use_batch_mask_changes false
マスター・インスタンスを初めて設定する場合、この属性も設定することができます。
splunk edit cluster-config -mode master -use_batch_mask_changes false
注意： ピアノードをすべて 6.2 にアップグレードしたら、use_batch_mask_changes を
true
に戻す必要があります。
マシンの要件
クラスタの各ノード (マスターノード、ピアノード、およびサーチヘッド) は、別個のマシンまたは仮想マシン上
で動作する必要があります。それ以外は、ストレージを除くハードウェア要件は、基本的に任意の Splunk
Enterprise インスタンスと同じです。『キャパシティプランニング』マニュアルの「リファレンスハードウェ
ア」を参照してください。
主な違いは、後述するピアノードのストレージ要件です。
注意： マスターノードのストレージに関する要件は、「リファレンスハードウェア」に記載されている要件より
も相当に低くなっています (マスターは外部データのインデックスを作成しないため)。
すべてのクラスタインスタンスは、同じ OS 上で動作していなければなりません。
クラスタのシステムクロックの同期
クラスタに参加する Splunk Enterprise インスタンスを実⾏するマシンは、仮想マシンまたは物理マシンを問わ
ず、すべてシステムクロックを同期する必要があります。これには、マスターノード、ピアノード、およびサーチ
ヘッドが含まれます。そうしないと、マスターとピアノード間のタイミングの問題、サーチ失敗、または過去の
サーチ結果の早期期限切れなどの、さまざまな問題が発⽣する可能性があります。
使⽤する同期⽅法は、ご利⽤のマシンによって異なります。Splunk Enterprise を実⾏するマシンとオペレーティ
ングシステムのシステムマニュアルを参照してください。⼤部分の環境では、ネットワーク・タイム・プロトコル
(NTP) が最適です。
ストレージの検討事項
クラスタ構成インデックスのストレージ要件を判断する際には、⼀連のピアノードが複数のデータコピーを取り扱
うための、容量の増加を考慮する必要があります。
クラスタは、「インデックスストレージの設定」に記載されているように、インデックスストレージを管理するた
めに通常の設定を使⽤します。
ストレージ要件の決定
ピアノードが処理するデータの量を保管するために、⼗分な量のディスクスペースを確保することが重要になりま
す。Splunk Enterprise のデータ量およびストレージニーズの概算⽅法に関する⼀般情報については、『インス
トール』マニュアルの「ストレージ要件の⾒積もり」を参照してください。そこには、⾮クラスタ構成のインデク
サーにストレージの⾒積もり⽅法が記載されています。そのガイドラインを参考に、クラスタに必要となる余分な
データコピーの量を概算してください。
クラスタを利⽤する場合は、転送されてくるデータ量を検討するだけではなく、複製データ保持数とサーチ可能
データ保持数 も考慮して、⼀連のピアノードの合計ストレージ要件を判断する必要があります。複製データ保持
数が 3 の場合、データのコピーを 3 つ保管することになります。これらのコピーを保管するために余分なスト
レージスペースが必要になりますが、3 倍のストレージが必要になる訳ではありません。データのサーチ不可能コ
ピーはサーチ可能コピーよりもサイズが⼩さくなります (データのみで対応するインデックスファイルは含まれて
いないため)。そのため、たとえば複製データ保持数が 3 でサーチ可能データ保持数が 2 の場合、⾮クラスタ構成
のインデクサーに同じデータを保管する場合と⽐べて、2 倍以上 3 倍未満のストレージスペースが必要となりま
す。
サーチ不可能コピーにより減らせるストレージ量を知るには、他にもいくつかの事項を調査する必要があります。
サーチ不可能コピーで不要になるインデックスファイルのサイズは、『インストール』マニュアルの「ストレージ
要件の⾒積もり」に記述されている要因によって⼤幅に変動します。
重要： マスターは個別のピアノードのストレージ量を把握していません。そのため、特定の複製データセットを
受け取るピアノードの決定時には、ノードのストレージ量は考慮されません。また、どのピアが複製データをサー
チ可能にするかも任意に決定されます (サーチ可能データ保持数が 2 以上の場合)。そのため、各ピアノードに
は、そのピアが保有するデータだけではなく、他のピアから転送されてくる可能性がある複製コピー⽤のストレー
ジも⼗分に確保する必要があります。クラスタにおけるストレージの使⽤量は、そのライフサイクルを通して常時
監視しておく必要があります。
ストレージ要件の例
概算で、受信した syslog データが圧縮、インデックス作成されると、元のサイズの約 50% になります。
raw データに 15%。
関連するインデックスファイルに 35%。
実際には、この概算値は『インストール』マニュアルの「ストレージ要件の⾒積もり」に記述されている各種要因
55
によって⼤幅に変動します。
Splunk Enterprise に取り込まれる syslog データが 100GB であると仮定します。⾮クラスタ構成のインデク
サーの場合、そのデータはインデクサーのストレージのうち 50GB (100GB の 50%) を占有します。ただし、ク
ラスタの場合、ストレージの計算には複製データ保持数とサーチ可能データ保持数を考慮して、すべてのクラスタ
ピアの合計ストレージ要件を判断する必要があります。(前述のように、特定のピアで必要になるストレージ量を
正確に予測することは困難です。)
ここでは、クラスタのストレージ要件を⾒積もる 2 つの例を取り上げていきます。どちらの例でも、受信する
syslog データは 100GB で、その結果 15GB の raw データと 35GB のインデックスが作成されることを前提に
しています。
3 ピアノード、複製データ保持数有 = 3; サーチ可能データ保持数 = 2: これにより、ピアノードすべて
の全体で総計 115GB 必要となります (平均 38GB/ピア)。計算⽅式は次の通りです。
合計 raw データ = (15GB * 3) = 45GB。
合計インデックスファイル = (35GB * 2) = 70 GB。
5 ピアノード、複製データ保持数有 = 5; サーチ可能データ保持数 = 3: これにより、ピアノードすべて
の全体で総計 180GB 必要となります (平均 36GB/ピア)。計算⽅式は次の通りです。
合計 raw データ = (15GB * 5) = 75GB。
合計インデックスファイル = (35GB * 3) = 105 GB。
ストレージハードウェア
6.0 より前のバージョンの Splunk Enterprise では、複製されたクラスタバケツのコピーは、それがホットバケツ
でもウォームバケツでも常に colddb ディレクトリに保管されます。6.0 以降では、ホットバケツとウォームバケツ
のコピーは、⾮複製コピーと同じ db ディレクトリに保管されます。 これにより、⾮クラスタ構成のインデックス
と⽐べて、クラスタ構成のインデックスでは colddb ⽤に⾼速なストレージを検討する必要がなくなります。
ライセンス情報
他の Splunk Enterprise デプロイ環境と同様に、ライセンス要件はインデクサーが処理するデータ量により決ま
ります。追加量のライセンスを購⼊するには、Splunk 営業担当にお問い合わせください。Splunk Enterprise ラ
イセンスの詳細は、『管理』マニュアルの「Splunk Enterprise ライセンスの仕組み」を参照してください。
インデックス複製におけるライセンス上の問題はさほど多くはありません。
マスター、ピア、サーチヘッドを含めクラスタメンバーはすべて、Enterprise ライセンス・プール に割り
当てる必要があります (インデックス作成処理を⾏わない場合でも)。
クラスタメンバーは、同じライセンス設定を共有する必要があります。
ライセンスに対しては受信データのみがカウントされます。複製されたデータは対象外です。
無料版ライセンスでは、インデックス複製は利⽤できません。
クラスタノードが使⽤するポート
クラスタノードがこれらのポートを使⽤できるようにする必要があります。
マスター上：
管理⽤ポート (デフォルトは 8089) は、他のすべてのクラスタノードが利⽤できるようにする必要が
あります。
各ピア上：
管理⽤ポートは、他のすべてのクラスタノードが利⽤できるようにする必要があります。
複製ポートは、他のすべてのピアノードが利⽤できるようにする必要があります。
受信ポートは、そのピアにデータを送信するすべてのフォワーダーが利⽤できるようにする必要があ
ります。
サーチヘッド上：
管理⽤ポートは、他のすべてのノードが利⽤できるようにする必要があります。
http ポート (デフォルトは 8000) は、サーチヘッドからデータにアクセスする任意のブラウザが利⽤
できるようにする必要があります。
サーバーとクラスタのデプロイ
クラスタピアにはデプロイサーバーを使⽤しないでください。
クラスタピアへの設定や App の配布⼿段として、デプロイサーバーはサポートされていません。⼀連のクラスタ
ピアに設定を配布するには、代わりに「共通のピア設定と App の更新」で説明されている設定バンドル を使⽤し
てください。
デプロイサーバーから設定バンドルを使った App 配布への移⾏⽅法の詳細は、「クラスタへの App の移⾏」を
参照してください。
マスターノードのその他のロール
⼀般的に、マスターノードの役割を果たす Splunk Enterprise インスタンスは、それ専⽤にする必要がありま
す。ただし、条件によっては、マスターインスタンスに他の処理負荷が軽い作業を⾏わせることも可能です。
デバッグ⽬的で、マスター内蔵のサーチヘッドを使⽤できます。
マスターの負荷によっては、マスター上でサーチヘッド・クラスタ・デプロイヤーを稼働できる場合があり
ます。
マスターの負荷によっては、マスター上で分散管理コンソールを稼働できる場合があります。
マスター上でデプロイヤーまたは分散管理コンソールを実⾏するには、マスターのクラスタが常に次の制限値を下
回っていなければなりません。
56
インデクサー 30 台
バケツ 100,000 個
インデックス 10 個
サーチヘッド 10 台
インデクサークラスタのマスターノードを有効にする
このトピックを読む前に、「 インデクサークラスタのデプロイの概要 」をご覧ください。
クラスタには、マスターノード が 1 台のみ存在しています。マスターノードは、ピアノードのアクティビティを
調整します。それ⾃体がデータを保管または複製することはありません (⾃⼰の内部データを除く)。
重要： マスターノードはピアノードまたはサーチノードのように、2 つの作業を兼務することはできません。マ
スターノードとして有効にする Splunk Enterprise インスタンスは、1 つのインデクサークラスタのみを担当す
る必要があります。また、マスターノードはピアとマシンを共有することはできません。ただし、条件によって
は、マスターインスタンスに他の処理負荷が少ない作業を⾏わせることも可能です。「マスターノードのその他の
ロール」を参照してください。
クラスタのデプロイ時には、ピアノードを設定する前に、最初のステップでマスターノードを有効にする必要があ
ります。
このトピックに記載されている⼿順は、Splunk Web を使ってマスターノードを有効にする⽅法について説明し
ています。その他にも、2 種類の⽅法でマスターノードを有効にすることができます。
マスターの server.conf ファイルを直接編集する。詳細は、「server.conf を使ったマスターの設定」を参照
してください。⼀部の⾼度な設定は、このファイルを編集することによってのみ設定できます。
CLI の edit cluster-config コマンドを使⽤する。詳細は、「CLI を使ったマスターの設定」を参照してくだ
さい。
重要： このトピックは、単⼀サイトクラスタでマスターを有効にする⽅法についてのみ説明しています。マルチ
サイトクラスタのデプロイを⾏う場合は、「server.conf を使ったマルチサイト・インデクサー・クラスタの設
定」を参照してください。
マスターを有効にする
インデクサーをマスターノードとして有効にするには：
1. Splunk Web の右上にある [設定] をクリックします。
2. [分散環境] セクションで、[インデクサークラスタリング] をクリックします。
3. [インデクサークラスタリングを有効にする] を選択します。
4. [マスターノード] を選択して、[次へ] をクリックします。
5. 他にもいくつかのフィールドを記⼊する必要があります。
複製データ保持数 ：複製データ保持数 は、クラスタが管理するデータコピー数を⽰します。デフォルトは
3 です。複製データ保持数の詳細は、「複製データ保持数」を参照してください。この時点で正しい複製
データ保持数を選択するようにしてください。後ほどクラスタが⼤量のデータを保有するようになった後
に、複製データ保持数の値を増やすことはお勧めできません。
サーチ可能データ保持数： サーチ可能データ保持数 は、クラスタが保持するデータのサーチ可能コピー数
を表しています。デフォルトは 2 です。サーチ可能データ保持数の詳細は、「サーチ可能データ保持数」を
参照してください。この時点で正しいサーチ可能データ保持数を選択するようにしてください。後ほどクラ
スタが⼤量のデータを保有するようになってから、サーチ可能データ保持数の値を増やすことはお勧めでき
ません。
セキュリティキー ：マスター、ピア、サーチヘッド間の通信を認証するための鍵です。鍵は、すべてのクラ
スタインスタンス間で同じでなければなりません。ここでフィールドを空にする場合は、他のピアやサーチ
ヘッドに対しても同じように空にしてください。
クラスタラベル ：ここでクラスタにラベルを付加できます。ラベルは分散管理コンソール内のクラスタ特定
に役⽴ちます。『分散管理コンソール』マニュアルの「クラスタラベルの設定」を参照してください。
6. [マスターノードを有効にする] をクリックします。
「マスターノードをアクティブにするには、Splunk を再起動する必要があります。」というメッセージが表⽰さ
れます。Splunk はサーバーコントロールから再起動できます。
7. [サーバーコントロールに移動] をクリックします。[設定] ページが表⽰されます。ここから再起動を⾏うことが
できます。
重要： マスターを初めて起動した場合、すべてのピア (複製データ保持数と同じ数のピア) を有効にして再起動す
るまで、ピアにおけるインデックス作成はマスターによりブロックされます。マスターがクラスタへのピア参加待
ちの場合は、マスターを再起動しないでください。再起動すると、ピアをもう⼀度再起動する必要があります。
[マスター] ダッシュボードの表⽰
再起動後、マスターノードに再度ログインして、Splunk Web の [クラスタリング] ページに戻ります。今回は、
マスタークラスタリングダッシュボードが表⽰されます。ダッシュボードの詳細は、「[マスター] ダッシュボード
の表⽰」を参照してください。
追加設定
57
デプロイ後のマスターノードの設定については、「マスター設定の概要」を参照してください。
ピアノードを有効にする
このトピックを読む前に、「 インデクサークラスタのデプロイの概要 」をご覧ください。
通常は、クラスタをデプロイするために複数のピアノード を有効にする必要があります。最低でも、複製データ
保持数 と等しい数のピアを有効にする必要があります。⽔平スケーリングに対応するために、より多くのピアが
必要な場合もあります。
⼀連のピアを有効にする前に、「インデクサークラスタのマスターノードを有効にする」の説明に従ってマス
ターノード を有効にして再起動する必要があります。マスターを初めて起動した場合、複製データ保持数と同じ
数のピアを有効にして再起動するまでは、ピアにおけるインデックス作成がマスターによりブロックされます。
このトピックに記載されている⼿順は、Splunk Web を使ってピアノードを有効にする⽅法について説明してい
ます。その他にも、2 種類の⽅法でビアノードを有効にすることができます。
ピアの server.conf ファイルを直接編集する。詳細は、「server.conf を使ったピアノードの設定」を参照し
てください。
CLI の edit cluster-config コマンドを使⽤する。詳細は、「CLI を使ったピアノードの設定」を参照してく
ださい。
重要： このトピックは、単⼀サイトクラスタでピアを有効にする⽅法についてのみ説明しています。マルチサイ
トクラスタのデプロイを⾏う場合は、「server.conf を使ったマルチサイト・インデクサー・クラスタの設定」を
参照してください。
ピアを有効にする
インデクサーをピアノードとして有効にするには：
1. Splunk Web の右上にある [設定] をクリックします。
2. [分散環境] セクションで、[クラスタリング] をクリックします。
3. [インデクサークラスタリングを有効にする] を選択します。
4. [ピアノード] を選択して、[次へ] をクリックします。
5. 他にもいくつかのフィールドを記⼊する必要があります。
マスター URI管理ポートを含むマスターのURI を⼊⼒します。例：https://10.152.31.202:8089。
ピア複製⽤ポート ：これは、ピアが他のピアから転送された複製データを受信するポートです。この⽬的
で、利⽤可能な任意の未使⽤ポートを指定することができます。このポートは、管理⽤ポートや受信⽤ポー
トと異なっている必要があります。
セキュリティキー ：マスター、ピア、サーチヘッド間の通信を認証するための鍵です。鍵は、すべてのクラ
スタインスタンス間で同じでなければなりません。マスターにセキュリティ鍵がある場合は、ここに⼊⼒す
る必要があります。
6. [ピアノードを有効にする] をクリックします。
「ピアノードをアクティブにするには、Splunk を再起動する必要があります。」というメッセージが表⽰されま
す。
7. [サーバーコントロールに移動] をクリックします。[設定] ページが表⽰されます。ここから再起動を⾏うことが
できます。
8. クラスタのすべてのピアノードに対して、この作業を繰り返します。
複製データ保持数と同じ数のピアを有効にしたら、クラスタでインデックスの作成とデータの複製を開始できます
(「インデクサークラスタのマスターノードを有効にする」を参照)。
[ピア] ダッシュボードの表⽰
再起動後、ピアノードに再度ログインして、Splunk Web の [クラスタリング] ページに戻ります。今回は、ピア
のクラスタリングダッシュボードが表⽰されます。ダッシュボードの詳細は、「[ピア] ダッシュボードの表⽰」を
参照してください。
ピアの設定
ピアを有効にした後は、データのインデックス作成を開始する前に、各種設定を⾏う必要があります。詳細は、以
下のトピックを参照してください。
インデクサークラスタ内のピアインデックスの設定
インデクサークラスタへのデータの取り込み⽅法
また、ピア上でその他の設定が必要な場合もあります。「ピアノード設定の概要」を参照してください。
サーチヘッドを有効にする
このトピックを読む前に、「 インデクサークラスタのデプロイの概要 」をご覧ください。
58
クラスタをサーチするには、インデクサークラスタ内で最低 1 台のサーチヘッド を有効にする必要があります。
⼀連のピアを有効にする前に、「インデクサークラスタのマスターノードを有効にする」の説明に従ってマスター
ノードを有効にして再起動する必要があります。
このトピックに記載されている⼿順は、Splunk Web を使ってサーチヘッドを有効にする⽅法について説明して
います。その他にも、2 種類の⽅法でサーチヘッドを有効にすることができます。
サーチヘッドの server.conf ファイルを直接編集する。詳細は、「server.conf を使ったサーチヘッドの設
定」を参照してください。複数クラスタサーチなど⼀部の⾼度な設定は、このファイルを編集することに
よってのみ設定できます。
CLI の edit cluster-config コマンドを使⽤する。詳細は、「CLI を使ったサーチヘッドの設定」を参照して
ください。
重要： このトピックは、単⼀サイトクラスタで個別サーチヘッドを有効にする⽅法についてのみ説明していま
す。
マルチサイトクラスタのデプロイを⾏う場合は、「server.conf を使ったマルチサイト・インデクサー・ク
ラスタの設定」を参照してください。
サーチヘッドクラスタ のメンバーであるサーチヘッドの統合をする場合、『分散サーチ』マニュアルの
「サーチヘッドクラスタとインデクサークラスタの統合」を参照してください。
サーチヘッドを有効にする
インデクサークラスタで Splunk インスタンスをサーチヘッドとして有効にするには：
1. Splunk Web の右上にある [設定] をクリックします。
2. [分散環境] セクションで、[インデクサークラスタリング] をクリックします。
3. [クラスタリングを有効にする] を選択します。
4. [サーチヘッドノード] を選択して、[次へ] をクリックします。
5. 他にもいくつかのフィールドを記⼊する必要があります。
マスター URI ：管理ポートを含むマスターのURI を⼊⼒します。例：https://10.152.31.202:8089。
セキュリティキー ：マスター、ピア、サーチヘッド間の通信を認証するための鍵です。鍵は、すべてのクラ
スタインスタンス間で同じでなければなりません。マスターにセキュリティ鍵がある場合は、ここに⼊⼒す
る必要があります。
6. [サーチヘッドノードを有効にする] をクリックします。
「サーチヘッドノードをアクティブにするには、Splunk を再起動する必要があります。」というメッセージが表
⽰されます。Splunk はサーバーコントロールから再起動できます。
7. [サーバーコントロールに移動] をクリックします。[設定] ページが表⽰されます。ここから再起動を⾏うことが
できます。
次のステップ
サーチヘッドを有効にしたら、以下の作業を⾏うことができます。
[サーチヘッド] ダッシュボードの表⽰
サーチヘッドに他のクラスタのサーチを許可
クラスタへのサーチヘッドの追加
サーチヘッド上でその他の設定を⾏います。
[サーチヘッド] ダッシュボードの表⽰
再起動後、サーチヘッドに再度ログインして、Splunk Web の [クラスタリング] ページに戻ります。今回は、
サーチヘッドのクラスタリングダッシュボードが表⽰されます。詳細は、「[サーチヘッド] ダッシュボードの表
⽰」を参照してください。
サーチヘッドに複数クラスタのサーチを許可
ダッシュボードから、サーチヘッドがサーチ対象にする他のクラスタを追加することができます。詳細は、「複数
のインデクサークラスタにまたがったサーチ」を参照してください。
インデクサークラスタへのサーチヘッドの追加
多数の同時サーチを可能にするために、複数のサーチヘッドを設定することができます。サーチヘッドのニーズの
決定⽅法については、『キャパシティプランニング』マニュアルの「ハードウェアのキャパシティプランニング」
を参照してください。
インデクサークラスタに複数のサーチヘッドを設定する場合は、単に追加のインスタンスに対して有効化のための
⼿順を繰り返します。サーチヘッドが設定とジョブを共有するようにサーチヘッドクラスタをデプロイしたい場合
は、『分散サーチ』マニュアルの「インデクサークラスタとサーチヘッドクラスタの統合」を参照してください。
追加設定
59
インデクサークラスタ内のサーチヘッドの設定については、「サーチヘッド設定の概要」を参照してください。
ベストプラクティス：マスターノードのデータのインデクサーレイ
ヤーへの転送
マスターノードのすべての内部データを、インデクサー (ピアノード) レイヤーに転送することが、ベストプラク
ティスと考えられます。こうすることには、さまざまな利点が存在しています。
すべてのデータを 1 つの場所に蓄積する。データ管理のプロセスを簡略化：インデックスとデータの管理が
必要なのは、1 つのレベル (インデクサーレベル) のみになります。
マスターノード停⽌時に、診断が可能になる。障害につながるデータは、インデクサー上に保管されてお
り、後ほどサーチヘッドからそれにアクセスすることができます。
マスター上で個別にインデックスを作成せずに、データを直接インデクサーに転送することをお勧めします。その
ためには、マスターをフォワーダーとして設定します。主な⼿順を以下に⽰します。
1. インデクサー上に必要なインデックスがすべて存在していることを確認します。 これが⼀般的な事例です
(マスターノード上にカスタムインデックスを作成しない限り)。_audit と _internal はマスター上だけでなくイン
デクサー上にも存在しているため、対応するマスターのデータを保持するために、それらのインデックスのバー
ジョンを個別に作成する必要があります。
2. マスターをフォワーダーとして設定します。 ⼀連のピアノードにまたがって、ロードバランシング⽤の転送
を設定するマスターノード上に、outputs.conf ファイルを作成します。また、マスターがデータをローカルに保持
しながら、それをピアに転送することがないように、マスター上でのインデックス作成をオフにする必要がありま
す。
outputs.conf
ファイルの例を以下に⽰します。
# Turn off indexing on the master
[indexAndForward]
index = false
[tcpout]
defaultGroup = my_peers_nodes
forwardedindex.filter.disable = true
indexAndForward = false
[tcpout:my_peers_nodes]
server=10.10.10.1:9997,10.10.10.2:9997,10.10.10.3:9997
autoLB = true
この例では、各ピアノードの受信ポートが 9997 に設定されていることを前提にしています。
の設定の詳細は、『データの転送』マニュアルの「outputs.conf によるフォワーダーの設定」を参照
してください。
outputs.conf
ピアのインデックスレプリケーションの準備
ピアを有効にしたら、インデックスレプリケーションの準備のために、さらなる設定作業を⾏わなければならない
こともあります。
デフォルトのインデックスセットとデフォルト設定のみを使⽤する場合は、即座にデータのレプリケーションを開
始することができます。ただし、ピア上に App をインストールしたり、設定を変更したりする場合は、すべての
ピアに対して⼀連の変更を適⽤する必要があります。特に、インデックス (App が定義したインデックスを含む)
を追加する必要がある場合は、ピアが共通のインデックスセットを使⽤するような⽅法でそれを実施する必要があ
ります。
クラスタピアにまたがったインデックスの設定⽅法については、「インデクサークラスタ内のピアインデックスの
設定」を参照してください。
ピアにまたがった App の設定⽅法および他のピア設定上の問題については、「ピアノード設定の概要」を参照し
てください。
インデクサークラスタを使ったインデックスの増強
インデクサークラスタの主な⽬的は、インデックスレプリケーション を有効にすることにあります。また、クラ
スタはデプロイトポロジを拡張する場合にも役⽴ちます。インデックスレプリケーションが不要な場合でも、複数
のインデクサーを管理するための⼿段として利⽤できます。
たとえば、単⼀のインデクサーでは対処しきれないほど⼤量のデータのインデックスを作成、保管するために、3
台のインデクサーと 1 台のサーチヘッドのデプロイ環境を作成する場合を考えてみましょう。Splunk Enterprise
5.0 より前でこのような環境を実現する唯⼀の⽅法は、各インデクサーを個別に設定し、サーチヘッドに追加した
後、デプロイサーバー のようなツールを使ってインデクサー設定を調整することでした。
クラスタリングを利⽤すれば、デプロイ⽤にクラスタを設定して 3 台のインデクサーの代わりに 3 台のピアノー
ドを指定できます。インデックスレプリケーションおよびその他の主な利点であるデータ可⽤性や耐障害性が不要
な場合でも、クラスタを使って複数のインデクサーインスタンスを調整することにはさまざまな利点があります。
60
管理とインデクサー設定の調整が簡単 (デプロイサーバーを使ったり⼿動で更新するのではない)。詳細は、
「共通のピア設定と App の更新」を参照してください。
分散サーチの設定と制御が簡単。「サーチヘッドを有効にする」を参照してください。
クラスタリングダッシュボードを使ってインデクサーの状態を把握。「[マスター] ダッシュボードの表⽰」
を参照してください。
開発された新たなクラスタ管理機能を活⽤できる。
インデックス作成能⼒を増強するためにクラスタを採⽤することの主な⽋点を以下に⽰します。
クラスタのマスターノードとして機能する Splunk Enterprise インスタンスを追加でインストールする必要
がある。
クラスタは異種インデクサーをサポートしていない。すべてのクラスタノードが同じバージョンレベルでな
ければなりません。また、クラスタ内のすべてのピアノードが同じ indexes.conf 設定を使⽤する必要があり
ます。詳細は、次のセクションの「クラスタピア管理とデプロイサーバーの⽐較」を参照してください。
デプロイサーバーを使って、クラスタピアに設定や App を配布することはできません。詳細は、次のセク
ションの「クラスタピア管理とデプロイサーバーの⽐較」を参照してください。
クラスタピア管理とデプロイサーバーの⽐較
クラスタの役に⽴つ機能の 1 つとして、マスターノードからすべてのインデクサー (ピアノード) の設定を管理、
更新できることが挙げられます。その点では、デプロイサーバー と機能が似ています。ただし、デプロイサー
バーとは異なり、クラスタピアの管理にはサーバークラスの概念がありません。このこと、およびクラスタのアク
ティビティの調整⽅法により、異なるグループのインデクサーに、異なる App または indexes.conf を指定するこ
とはできません。(「ピアノード設定の概要」で説明しているように、クラスタ内のすべてのピアノードが、同じ
indexes.conf 設定および他の設定を使⽤する必要があります。)異種セットのインデクサーが必要な場合は、機能増
強のためにクラスタを使⽤することはできません。
⼀⽅、ピアノードへのアップデートのダウンロードに⽤いられる設定バンドルには、デプロイサーバーと⽐べて利
点があります。アップデートを配布するだけでなく、ピア上でそれを検証してから、(必要な場合は) ピアを順番に
再起動していきます。詳細は、「共通のピア設定と App の更新」を参照してください。
重要： ピアノードに直接アップデートをデプロイするために、デプロイサーバーやサードパーティ製の設定管理
ソフトウェア (Puppet や Chef など) を使⽤しないでください。このようなツールは、マスターへのアップデート
のデプロイに利⽤することができます。次に、マスターの配布機能を使って、アップデートをピアにデプロイして
ください。「デプロイサーバーを使ったマスターへの App の配布」を参照してください。
処理能⼒増強デプロイのためのクラスタの設定
処理能⼒増強デプロイのためにインデックス・レプリケーションなしでクラスタを設定するには、複製データ保
持数 とサーチ可能データ保持数 に 1 を設定します。こうすることで、クラスタはデータレプリケーションなし
の、単純な Splunk Enterprise インスタンスの管理セットとして動作します。データの複製コピーは保持されな
いため、必要なストレージサイズを減らすことができ、処理上のオーバーヘッドも最低限に抑えられます。
⾮クラスタインデクサーのクラスタ化環境への移⾏
現在利⽤している⼀連のインデクサーをインデクサークラスタに移⾏したい場合は、「クラスタ構成と⾮クラスタ
構成のインデクサーデプロイの主な相違点」を注意深くお読みください。このトピックには、移⾏作業を開始する
前に理解しておく必要がある問題点が記述されています。
任意の時点で、⾮クラスタインデクサーをクラスタに (ピアノードとして) 追加することができます。そのために
は、「ピアノードを有効にする」で説明しているように、インデクサーをピアとして有効にします。
インデクサーをピアにすると、それは他のピアと同様にクラスタに参加します。ピアに到着する新規データは、ク
ラスタの複製データ保持数に応じて複製されます。また、ピアは他のピアからの複製データを受信する候補でもあ
ります。インデクサー上にすでに存在しているデータが⾃動的に複製されることはありませんが、後述するように
サーチには関与しています。
重要： ⾮クラスタ構成からクラスタ構成にインデクサーを移⾏する前に、それが本当に必要か確認してくださ
い。この作業は⼀⽅向のプロセスです。クラスタ構成から⾮クラスタ構成にインデクサーを変換するための、サ
ポートされている⼿順はありません。
従来のデータの管理
「従来のデータ」とは、クラスタピアへの変換前にインデクサー上に保管されていたデータを表しています。
クラスタによる従来のインデックスデータの処理
クラスタに既存のインデクサーを追加した場合、すでにインデクサー上に存在しているバケツは複製されません。
クラスタに追加する前からインデクサー上に存在していたバケツは、「スタンドアロン」のバケツと呼ばれていま
す。そのようなバケツに対してもサーチは⾏われ、クラスタ内の他の複製されたバケツからのサーチ結果と統合さ
れます。
従来のデータを移⾏する⽅法はありませんか？
スタンドアロンのバケツを複製対象バケツに変換するコストが⾼いため (クラスタの複製データ保持数とサーチ可
能データ保持数を満たすために、複数のサーチ可能およびサーチ不可能コピーを作成する必要があるため)、⼀般
的には変換することはお勧めできません (特に⼤量のスタンドアロンバケツを持つインデクサーの場合)。この変換
については、保証している変換⼿順はありません。どうしても変換する必要があるような場合は、Splunk プロ
フェッショナルサービスにそのような作業のトレードオフや要件をお問い合わせください。
61
クラスタへの App の移⾏
現在の⾮クラスタ環境で、⼀連のインデクサーへの App の配布に、デプロイサーバー を使⽤している⽅もいる
でしょう。インデクサーをクラスタのピアノードに変換したら、この⽅法は利⽤できなくなります。詳細は、「ク
ラスタ構成と⾮クラスタ構成のインデクサーデプロイの主な相違点」を参照してください。
ピアノードに App を配布するには、「共通のピア設定と App の更新」の説明に従って設定バンドル を使⽤する
必要があります。App をマスターノード上の特別な場所に保管すると、最初にインデクサーをピアとして有効に
した場合に、マスターから各インデクサーにその App が配布されます。後ほど App を追加、変更する必要があ
る場合は、マスター上で適切な追加、変更作業を⾏った後、マスターに更新された設定バンドルをピアセット全体
に配布するように指⽰します。
設定バンドルを使う⽅法とデプロイサーバーを使う⽅法の⽐較については、「クラスタピア管理とデプロイサー
バーの⽐較」を参照してください。
重要： ピアノードに App を配布する場合は、設定バンドルを使⽤する必要があります。このような⽬的にデプロ
イサーバーを使⽤することはできません。
App の移⾏⽅法
App はクラスタを有効にする際に移⾏することをお勧めします。そのための⼿順については、後述の説明を参照
してください。
重要： この⼿順を実施する前に、この章の前半に記載されている各トピックの内容を正しく理解しておく必要が
あります。「インデクサークラスタのデプロイの概要」からこのトピックまでの説明を、あらかじめご覧くださ
い。
この⼿順は、デプロイサーバーのデプロイクライアントとして設定された⼀連のインデクサーセットが存在する、
分散サーチ環境を前提にしています。デプロイサーバーは、App をインデクサーに配信するために⽤いられま
す。これらのインデクサーを、クラスタのピアノードに変換します。ピアノードに変換したら、それ以降デプロイ
サーバーを使ってそれらのピアに App をプッシュすることはできません。代わりに設定バンドルを使⽤する必要
があります。
クラスタを有効にする際に App を移⾏するには、以下の⼿順に従ってください。
1. 「インデクサークラスタのマスターノードを有効にする」の説明に従って、マスターを有効にします。
2. デプロイサーバー上で、マスターが移⾏予定のインデクサーに配布する⼀連の App を探します。これらの App
は、デプロイサーバーの $SPLUNK_HOME/etc/deployment-apps ディレクトリにあります。
3. デプロイサーバーからこれらの App をクラスタマスターの $SPLUNK_HOME/etc/master-apps ディレクトリにコピー
します。master-apps ディレクトリの詳細は、「設定パンドルの構造」を参照してください。
4. 任意の indexes.conf に対して、master-apps 内の各 App を調査します。これらのファイル内で、新たなインデッ
クスを定義しているスタンザを探してください。それらのスタンザに対して、以下の属性/値のペアを追加しま
す。
repFactor=auto
これにより、インデックスのレプリケーションが有効になります。詳細は、「indexes.conf の repFactor 属性」
を参照してください。
注意： App の作成者/保守管理者である場合は、この変更を $SPLUNK_HOME/etc/masterapps/<appname>/default/indexes.conf 内で⾏うこともできます。
5. 各インデクサーをクラスタピアに、⼀度に 1 つずつ変換していきます。
a. インデクサーがデプロイクライアントではなくなるように再設定します。
b. インデクサーの
$SPLUNK_HOME/etc/apps
ディレクトリにある App を削除します。
c. 「ピアノードを有効にする」の説明に従って、インデクサーをクラスタピアとして有効にします。
d. ピアを再起動して、有効化プロセスを完了します。
e. マスターが予定の App セットをピアの
ます。
$SPLUNK_HOME/etc/slave-apps
ディレクトリに配布したことを確認し
6. すべてのピアを有効にしたら、[マスター] ダッシュボードに移動して、⽬的のインデックスセットが複製されて
いることを確認します。このダッシュボードの説明は、「[マスター] ダッシュボードの表⽰」にあります。
クラスタピアの設定の詳細は、以下のトピックを参照してください。
インデクサークラスタ内のピアインデックスの設定
ピアノード設定の概要
共通のピア設定と App の更新
インデクサークラスタのアップグレード
重要： このトピックの説明は、すべてのノードを新バージョンに同時にアップグレードすることを前提にしてい
62
ます。このような状況が当てはまらないこともあります。バージョン混在クラスタについては、「Splunk
Enterprise バージョンの互換性」を参照してください。
アップグレードの内容に応じて、アップグレード⼿順は⼤幅に異なります。このトピックは以下のシナリオをカ
バーしています。
6.x からのアップグレード
5.x からのアップグレード
新たなメンテナンスリリースへのアップグレード (例 ：6.1.1 から 6.1.2)
5.0.1 以前からのアップグレード
単⼀サイトからマルチサイトに移⾏？
単⼀サイトインデクサークラスタをマルチサイトクラスタに変換する場合、まず 6.2 へのアップグレードを⾏っ
てから「単⼀サイトからマルチサイトへのインデクサークラスタの移⾏」を参照してください。
6.x からのアップグレード
たとえば 6.2 インデクサークラスタを 6.3 クラスタにアップグレードする場合など、 6.x からのアップグレード
では、すべてのクラスタノードをオフラインにする必要があります。オンラインまたは稼働状態のままアップグ
レードすることはできません。
以下の⼿順に従ってください。
1. マスターを停⽌します。
2. すべてのピアとサーチヘッドを停⽌します。
ピアを停⽌する場合は、splunk
offline
コマンドではなく
splunk stop
コマンドを使⽤してください。
3. 『インストール』マニュアルの「Splunk Enterprise のアップグレード⽅法」に記述されている、標準の
Splunk Enterprise アップグレード⼿順に従って、マスターノードをアップグレードします。まだピアはアップ
グレードしないでください。
4. まだ起動していない場合はマスターを開始し、すべてのプロンプトをそのまま受け⼊れます。
5. マスター上で splunk enable maintenance-mode を実⾏します。マスターがメンテナンスモードに移⾏したことを確
認するには、splunk show maintenance-mode を実⾏します。このステップにより、不要なバケツ修復処理を防⽌でき
ます。「メンテナンスモードの使⽤」を参照してください。
6. 『インストール』マニュアルの「Splunk Enterprise のアップグレード⽅法」に記述されている、標準の
Splunk Enterprise アップグレード⼿順に従って、ピアノードとサーチヘッドをアップグレードします。
7. まだ起動していない場合は、ピアノードとサーチヘッドを開始します。
8. マスター上で splunk disable maintenance-mode を実⾏します。マスターがメンテナンスモードから復帰したこと
を確認するには、splunk show maintenance-mode を実⾏します。
[マスター] ダッシュボードを参照して、すべてのクラスタノードが正常に再稼働していることを確認することがで
きます。
5.x から 6.x へのアップグレード
5.x インデクサークラスタを 6.x クラスタにアップグレードする場合、すべてのクラスタノードをオフラインにす
る必要があります。オンラインまたは稼働状態のままアップグレードすることはできません。
以下の⼿順に従ってください。
1. マスターノード上で、safe_restart_cluster_master スクリプトを、--get_list オプションを指定して実⾏します。
splunk cmd python safe_restart_cluster_master.py <master_uri> --auth <username>:<password> --get_list
注意： master_uri パラメータの場合、マスターノードの URI とポート番号を使⽤してください。例：
https://10.152.31.202:8089
このコマンドを実⾏すると、すべてのクラスタバケツのコピーとその状態のリスト
が、$SPLUNK_HOME/var/run/splunk/cluster/buckets.xml ファイルに保管されます。このリストは、マスターのアップグ
レード後にマスターに復元されます。
重要： このスクリプトのコピーを⼊⼿するには、「safe_restart_cluster_master スクリプト」からコピーして、
それを貼り付けてください。
この⼿順が必要な理由については、「safe_restart_cluster_master スクリプトが必要な理由」を参照してくださ
い。
2. マスターを停⽌します。
3. すべてのピアとサーチヘッドを停⽌します。
ピアを停⽌する場合は、splunk
offline
コマンドではなく
splunk stop
63
コマンドを使⽤してください。
4. 『インストール』マニュアルの「Splunk Enterprise のアップグレード⽅法」に記述されている、標準の
Splunk Enterprise アップグレード⼿順に従って、マスターノードをアップグレードします。まだピアはアップ
グレードしないでください。
5. まだ起動していない場合はマスターを開始し、すべてのプロンプトをそのまま受け⼊れます。
6. 「共通のピア設定と App の更新」に記述されている構⽂を使って、splunk apply cluster-bundle コマンドを実⾏
します。(6.0 で設定バンドルのチェックサムの算出⽅法が変更されたため、ピアを何度も再起動することを防⽌
するために、この⼿順が必要になります。)
7. マスター上で splunk enable maintenance-mode を実⾏します。マスターがメンテナンスモードに移⾏したことを確
認するには、splunk show maintenance-mode を実⾏します。このステップにより、不要なバケツ修復処理を防⽌でき
ます。「メンテナンスモードの使⽤」を参照してください。
8. 『インストール』マニュアルの「Splunk Enterprise のアップグレード⽅法」に記述されている、標準の
Splunk Enterprise アップグレード⼿順に従って、ピアノードとサーチヘッドをアップグレードします。
9. まだ起動していない場合は、ピアノードとサーチヘッドを開始します。
10. マスター上でもう⼀度 safe_restart_cluster_master スクリプトを実⾏しますが、今回は
を使⽤して、ステップ 1 で作成したバケツリストの場所を指定します。
freeze_from
オプション
splunk cmd python safe_restart_cluster_master.py <master_uri> --auth <username>:<password> --freeze_from
<path_to_buckets_xml>
例：
splunk cmd python safe_restart_cluster_master.py <master_uri> --auth admin:changeme --freeze_from
$SPLUNK_HOME/var/run/splunk/cluster/buckets.xml
これにより、ステップ 1 で⽣成されたフローズンバケツのリストをマスターが取得します。
11. マスター上で splunk
を確認するには、splunk
を実⾏します。マスターがメンテナンスモードから復帰したこと
を実⾏します。
disable maintenance-mode
show maintenance-mode
[マスター] ダッシュボードを参照して、すべてのクラスタノードが正常に再稼働していることを確認することがで
きます。
safe_restart_cluster_master スクリプトが必要な理由
スクリプトは、5.x マスターノードによるフローズンバケツのコピーの処理⽅法に関す
る問題に対処するためのスクリプトです。この問題はリリース 6.0 以降では修正されていますが、5.x からマス
ターをアップグレードする際には引き続き問題となっています。このセクションでは、この問題の詳細について説
明しています。
safe_restart_cluster_master
ピアがバケツのコピーをフローズンに移⾏すると、マスターはそのバケツの修復を中⽌します。この場合マスター
は、他のピアも順次そのバケツのコピーをフローズンに移⾏することを前提に動作しています。
マスターが継続的に動作している場合は、それでも正常に機能します。ただし、5.x ではあるピアがバケツをフ
ローズンにした時点以降にマスターを再起動すると、フローズンバケツのナレッジはマスターまたはピアには保持
されません。マスターはフローズンコピー (他のピア上にそのバケツのまだフローズン状態に移⾏されていないコ
ピーがある場合) を失われたコピーとして取り扱い、クラスタを完全状態に戻すために普段通りの修復作業を実⾏
します。クラスタに⼀部のみがフローズン状態のバケツが多数ある場合、この処理が完了するまでに⻑い時間がか
かってしまいます。処理が完了するまでの間、マスターは次の世代を処理することはできません。
6.0 へのアップグレード後のマスター再起動時にこのような問題が発⽣することを防⽌するために、マスター上で
safe_restart_cluster_master スクリプトを実⾏する必要があります。アップグレード⼿順で説明しているように、
最初に 5.x マスター上でこのスクリプトに --get_list オプションを指定して実⾏すると、すべてのクラスタバケツ
のコピーとその状態 (フローズンかどうかなど) のリストが⽣成されます。次にマスターを 6.x にアップグレード
した後に、freeze_from オプションを使ってスクリプトを再実⾏すると、アップグレードしたマスターにそのリス
トの内容が反映されるため、無駄なフローズンバケツの修復処理を防⽌することができます。
safe_restart_cluster_master スクリプト
アップグレード⼿順のステップ 1〜9 を実施するには、safe_restart_cluster_master スクリプトを実⾏する必要があ
ります。現在このスクリプトは、製品には付属していません。 スクリプトを⼊⼿するには、以下のスクリプト
を直接コピーして、それを $SPLUNK_HOME/bin/safe_restart_cluster_master.py に保存してください。
重要： 次のセクション「parse_xml_v3 スクリプト」の説明に従って、parse_xml_v3 スクリプトもコピーして保存
する必要があります。
スクリプトの内容を以下に⽰します。
import httplib2
from urllib import urlencode
import splunk, splunk.rest, splunk.rest.format
from parse_xml_v3 import *
64
import json
import re
import time
import os
import subprocess
#before restarting the master, store the buckets list in /var/run/splunk/cluster
BUCKET_LIST_PATH = os.path.join(os.environ['SPLUNK_HOME'] , 'var' , 'run' , 'splunk' , 'cluster' , 'buckets.xml')
def get_buckets_list(master_uri, auth):
f = open(BUCKET_LIST_PATH,'w')
atom_buckets = get_xml_feed(master_uri +'/services/cluster/master/buckets?count=-1',auth,'GET')
f.write(atom_buckets)
f.close()
def change_quiet_period(master_uri, auth):
args={'quite_period':'600'}
return get_response_feed(master_uri+'/services/cluster/config/system?quiet_period=600',auth, 'POST')
def num_peers_up(master_uri, auth):
count = 0
f= open('peers.xml','w')
atom_peers = get_xml_feed(master_uri+'/services/cluster/master/peers?count=-1',auth,'GET')
f.write(atom_peers)
regex= re.compile('"status">Up')
f.close()
file = open('peers.xml','r')
for line in file:
match = regex.findall(line)
for line in match:
count = count + 1
file.close()
os.remove('peers.xml')
return count
def wait_for_peers(master_uri,auth,original_number):
while(num_peers_up(master_uri,auth) != original_number):
num_peers_not_up = original_number - num_peers_up(master_uri,auth)
print "Still waiting for " +str(num_peers_not_up) +" peers to join ..."
time.sleep(5)
print "All peers have joined"
def get_response_feed(url, auth, method='GET', body=None):
(user, password) = auth.split(':')
h = httplib2.Http(disable_ssl_certificate_validation=True)
h.add_credentials(user, password)
if body is None:
body = {}
response, content = h.request(url, method, urlencode(body))
if response.status == 401:
raise Exception("Authorization Failed", url, response)
elif response.status != 200:
raise Exception(url, response)
return splunk.rest.format.parseFeedDocument(content)
def get_xml_feed(url, auth, method='GET', body=None):
(user, password) = auth.split(':')
h = httplib2.Http(disable_ssl_certificate_validation=True)
h.add_credentials(user, password)
if body is None:
body = {}
response, content = h.request(url, method, urlencode(body))
if response.status == 401:
raise Exception("Authorization Failed", url, response)
elif response.status != 200:
raise Exception(url, response)
return content
def validate_rest(master_uri, auth):
return get_response_feed(master_uri + '/services/cluster/master/info', auth)
65
def freeze_bucket(master_uri, auth, bid):
return get_response_feed(master_uri + '/services/cluster/master/buckets/' + bid + '/freeze', auth, 'POST')
def freeze_from_file(master_uri,auth,path=BUCKET_LIST_PATH):
file = open(path) #read the buckets.xml from either path supplied or BUCKET_LIST_PATH
handler = BucketHandler()
parse(file, handler)
buckets = handler.getBuckets()
fcount = 0
fdone = 0
for bid, bucket in buckets.iteritems():
if bucket.frozen:
fcount += 1
try:
freeze_bucket(master_uri,auth, bid)
fdone += 1
except Exception as e:
print e
print "Total bucket count:: ", len(buckets), "; number frozen: ", fcount, "; number re-frozen: ", fdone
def restart_master(master_uri,auth):
change_quiet_period(master_uri,auth)
original_num_peers = num_peers_up(master_uri,auth)
print "\n" + "Issuing restart at the master" +"\n"
subprocess.call([os.path.join(os.environ["SPLUNK_HOME"],"bin","splunk"), "restart"])
print "\n"+ "Master was restarted" + "\n"
print "\n" + "Waiting for all " +str(original_num_peers) + " peers to come back up" +"\n"
wait_for_peers(master_uri,auth,original_num_peers)
print "\n" + "Making sure we have the correct number of frozen buckets" + "\n"
if __name__ ==
'__main__':
usage = "usage: %prog [options] <master_uri> --auth admin:changeme"
parser = OptionParser(usage)
parser.add_option("-a","--auth", dest="auth", metavar="user:password", default=':',
help="Splunk authentication parameters for the master instance");
parser.add_option("-g","--get_list", action="store_true",help="get a list of frozen buckets and strore them in
buckets.xml");
parser.add_option("-f", "--freeze_from",dest="freeze_from",
help="path to the file that contains the list of buckets to be frozen. ie path to the
buckets.xml generated by the get_list option above");
(options, args) = parser.parse_args()
if len(args) ==
0:
parser.error("master_uri is required")
elif len(args) > 1:
parser.error("incorrect number of arguments")
master_uri = args[0]
try:
validate_rest(master_uri, options.auth)
except Exception as e:
print "Failed to access the master info endpoint make sure you've supplied the authentication credentials"
raise
# Let's get a list of frozen buckets, stored in
if(options.get_list):
print "Only getting the list of buckets and storing it at " + BUCKET_LIST_PATH
get_buckets_list(master_uri,options.auth)
elif(options.freeze_from):
print "Reading the list of buckets from" + options.freeze_from + "and refreezing them"
freeze_from_file(master_uri,options.auth,options.freeze_from)
else:
print "Restarting the master safely to preserve knowledge of frozen buckets"
66
get_buckets_list(master_uri,options.auth)
restart_master(master_uri,options.auth)
freeze_from_file(master_uri,options.auth,BUCKET_LIST_PATH)
parse_xml_v3 スクリプト
スクリプトには、safe_restart_cluster_master が必要とするいくつかのヘルパー機能が含まれていま
す。現在このスクリプトは、製品には付属していません。 スクリプトを⼊⼿するには、以下のスクリプトを直
接コピーして、それを $SPLUNK_HOME/bin/parse_xml_v3.py に保存してください。
parse_xml_v3
スクリプトの内容を以下に⽰します。
import sys
from xml.sax import ContentHandler, parse
from optparse import OptionParser
class PeerBucketFlags:
def __init__(self):
self.primary = False
self.searchable = False
class Bucket:
def __init__(self):
self.peer_flags = {}
# key is peer guid
self.frozen = False
class BucketHandler(ContentHandler):
def __init__(self):
ContentHandler.__init__(self)
self.buckets = {}
self.in_entry = False
self.in_peers = False
self.save_title = False
self.save_frozen = False
self.peer_nesting = 0
self.current_peer_flags = {}
self.current_guid = None
self.current_frozen_flag = ''
self.current_peer_field = None
self.current_peer_field_value = ''
self.current_bucket = ''
def getBuckets(self):
return self.buckets
def startDocument(self):
pass
def endDocument(self):
pass
def startElement(self, name, attrs):
if name == 'entry':
self.in_entry = True
elif self.in_entry and name == 'title':
self.save_title = True
elif self.in_entry and name == 's:key' and attrs.get('name') == 'frozen':
self.save_frozen = True
elif name == 's:key' and attrs.get('name') == 'peers':
self.in_peers = True
elif self.in_peers and name == 's:key':
self.peer_nesting += 1
if self.peer_nesting == 1:
self.current_peer_flags = PeerBucketFlags()
self.current_guid = attrs.get('name').encode('ascii')
elif self.peer_nesting == 2:
self.current_peer_field = attrs.get('name').encode('ascii')
self.current_peer_field_value = ''
def endElement(self,name):
if name == 'entry':
self.in_entry = False
67
self.in_entry = False
self.current_bucket=''
elif self.save_title:
try:
(idx, local_id, origin_guid) = self.current_bucket.split('~')
except ValueError as e:
print "Invalid? ", self._locator.getLineNumber()
print self.current_bucket
print e
raise
self.buckets[self.current_bucket] = Bucket()
self.save_title = False
elif self.save_frozen:
if self.current_frozen_flag in [1, '1', 'True', 'true']:
self.buckets[self.current_bucket].frozen = True
self.current_frozen_flag = ''
self.save_frozen = False
elif self.peer_nesting == 2 and name == 's:key':
if self.current_peer_field == 'bucket_flags':
self.current_peer_flags.primary = (self.current_peer_field_value == '0xffffffffffffffff')
elif self.current_peer_field == 'search_state':
self.current_peer_flags.searchable = self.current_peer_field_value == 'Searchable'
# Nesting level goes down in either case.
self.peer_nesting -= 1
elif self.peer_nesting == 1 and name == 's:key':
self.buckets[self.current_bucket].peer_flags[self.current_guid] = self.current_peer_flags
self.peer_nesting -= 1
elif self.in_peers and self.peer_nesting == 0 and name == 's:key':
self.in_peers = False
def characters(self, content):
if self.save_title:
self.current_bucket += content.encode('ascii').strip()
elif self.save_frozen:
self.current_frozen_flag += content.encode('ascii').strip()
if self.peer_nesting > 0:
s = content.encode('ascii').strip()
if s:
self.current_peer_field_value += s
新しいメンテナンスリリースへのアップグレード
クラスタを新しいメンテナンスリリースにアップグレードする場合は (例：6.1 から 6.1.1 へ)、クラスタ全体を同
時に停⽌する必要はありません。⼀度に 1 台ずつ、順番にノードをオンラインアップグレードすることができま
す。
重要： ローリングアップグレードを⾏う場合でも、すべてのノードを迅速にアップグレードする必要がありま
す。「インデクサークラスタのシステム要件とその他のデプロイに関する検討事項」で説明しているように、クラ
スタが適切に機能するためには、すべてのノードで同じバージョンの Splunk Enterprise を動作させる必要があ
ります。そのため、すべてのクラスタノードのアップグレード準備が完了するまでは、アップグレード作業を開始
しないでください。マスターをアップグレードしたけれどもピアをアップグレードしないと、クラスタにさまざま
なエラーや警告が発⽣します。短期間なら⼀般的にこれでも問題ありません。ただし、できる限り早くすべての
ノードのアップグレードを完了する必要があります。
クラスタノードをアップグレードするには、標準の Splunk Enterprise アップグレード⼿順に従ってください。
ただし、以下で説明するようにいくつかの例外があります。Splunk Enterprise のアップグレードに関する⼀般的
な情報については、「Splunk Enterprise のアップグレード⽅法」を参照してください。
以下の⼿順に従ってください。
1.マスターノードのアップグレード
まず マスターノードをアップグレードします。
マスター停⽌時および再起動後の処理については、「マスターノード停⽌時の処理」を参照してください。
2.マスターのメンテナンスモードへの移⾏
マスター上で splunk enable maintenance-mode を実⾏します。マスターがメンテナンスモードに移⾏したことを確認
するには、splunk show maintenance-mode を実⾏します。このステップにより、不要なバケツ修復処理を防⽌できま
す。「メンテナンスモードの使⽤」を参照してください。
3.ピアノードのアップグレード
ピアノードのアップグレード時には、以下の事項に注意してください。
68
ピアのアップグレードにより、実⾏中のサーチが中断される可能性があります。
ダウンタイムやインデックス作成/サーチの中断を最⼩限に抑えるために、ピアノードは⼀度に 1 つずつ
アップグレードしてください。
アップグレード前にピアを停⽌するには、offline コマンドを使⽤します。「ピアをオフラインにする」を参
照してください。⼗分なアップグレード期間を確保するために、restart_timeout 属性を編集して、再起動時
間を⻑くしなければならないこともあります。詳細は、適切なトピックを参照してください。
マスターのアップグレード時から、ピアのアップグレード完了までの間、クラスタにはさまざまな警告やエ
ラーが発⽣する可能性があります。
マルチサイトクラスタの場合、ピアをアップグレードするサイトの順番は関係ありません。メンテナンス
ノードには、サイトの概念がありません。
4.サーチヘッドのアップグレード
サーチヘッドアップグレード時のクラスタへの影響は、その作業中にサーチ中断の可能性があることのみです。
5.マスターのメンテナンスモードからの復帰
マスター上で splunk disable maintenance-mode を実⾏します。マスターがメンテナンスモードから復帰したことを
確認するには、splunk show maintenance-mode を実⾏します。
5.0.1 以前からのアップグレード
5.0.1 以前からのアップグレード時に、$SPLUNK_HOME/etc/master-apps (マスター上) および $SPLUNK_HOME/etc/slaveapps (ピア上) にある /cluster ディレクトリは、名前が /_cluster に変更されます。この処理は⾃動的に⾏われま
す。このディレクトリの詳細は、「共通のピア設定と App の更新」を参照してください。
5.0.1 以前からのアップグレード後にマスターを再起動すると、⼀連のピアノードの順次再起動が実施されます。
これにより、最新バージョンの設定バンドルがピアに配布されます (名前が変更された /_cluster ディレクトリ)。
インデクサークラスタへのデータの取り込み
インデクサークラスタへのデータの取り込み⽅法
クラスタピアノードは、⾮クラスタ構成のインデックスと同様に任意のソースから、データを直接取り込むことが
できます。ただし、データの忠実度が重要な場合は、ノードに直接データを取り込む代わりに、まずフォワー
ダー を使ってデータを取り込んでから、それをピアノードに転送します。
データ⼊⼒⽤フォワーダーの利点
クラスタへのデータの送信にフォワーダーを使⽤する主な理由はいくつかあります。
すべての受信データのインデックスを確実に作成する。 フォワーダーのインデクサー応答確認 機能を有
効にすれば、すべての受信データのインデックスが作成され、クラスタに保管されたことを確認できます。
ピアがフォワーダーからデータブロックを受信すると、そのデータのインデックスを作成後、フォワーダー
に応答確認を送信します。フォワーダーがピアから応答確認を受信しない場合は、データを再送信します。
フォワーダーは応答確認を受信するまで、データの再送を繰り返します。インデクサー応答確認は、終端間
データの忠実度を確保するための唯⼀の⼿段です。「インデクサー応答確認の仕組み」を参照してくださ
い。
潜在的なノード障害に対処する。 フォワーダーのロードバランシング により、グループ内のあるピアが停
⽌した場合、フォワーダーはそのグループ内の残りのピアに引き続きデータを送信します。⼀⽅で、ピアに
直接⼊⼒を⾏う場合では、受信ピアが停⽌するとデータソースはデータを送ることができません。「ロード
バランシングの仕組み」を参照してください。
データソースとピアノードの接続プロセスを簡略化するには フォワーダーのインデクサー検出を有効に
することで、フォワーダーは⾃動的にロードバランスを利⽤可能なすべてのピアノードに⾏います。これに
は、クラスタに後で追加されるピアノードも含まれます。「インデクサー検出⽅法の利点」を参照してくだ
さい。
ピア上で直接⼊⼒を設定する
データ⼊⼒にフォワーダーを使⽤しない場合、通常のように各ピア上で⼊⼒を設定することができます。たとえ
ば、ピアの inputs.conf を編集します。⼊⼒の設定⽅法の詳細は、『データの取り込み』マニュアルの「データ取
り込みの設定」を参照してください。
フォワーダーを使ったインデクサークラスタへのデータの取り込み
インデクサークラスタとフォワーダーを使⽤する主な理由は、
すべての受信データのインデックスを確実に作成するためです。 フォワーダーのインデクサー応答確
認 機能を有効にすれば、すべての受信データのインデックスが作成され、クラスタに保管されたことを確認
できます。「インデクサー応答確認の仕組み」を参照してください。
69
潜在的なノード障害に対処する。 フォワーダーのロードバランシング により、グループ内のあるピアが停
⽌した場合、フォワーダーはそのグループ内の残りのピアに引き続きデータを送信します。「ロードバラン
シングの仕組み」を参照してください。
データソースとピアノードの接続プロセスを簡略化するには フォワーダーのインデクサー検出を有効に
することで、フォワーダーは⾃動的にロードバランスを利⽤可能なすべてのピアノードに⾏います。これに
は、クラスタに後で追加されるピアノードも含まれます。「インデクサー検出⽅法の利点」を参照してくだ
さい。
フォワーダーを使ってクラスタにデータを取り込むには、2 種類の設定作業を⾏う必要があります。
フォワーダーをピアノードに接続
フォワーダーのデータ⼊⼒を設定
続⾏する前に、フォワーダーの詳細およびそれを使った Splunk Enterprise へのデータの取り込み⽅法を理解し
ておく必要があります。フォワーダーの基本については、『データの転送』マニュアルの「転送と受信について」
を参照してください。そのマニュアルのそれ以降のトピックには、フォワーダーのデプロイおよび設定⽅法が詳細
に記述されています。
フォワーダーをピアノードに接続
フォワーダーをピアノードに接続する⽅法は 2 つあります。
インデクサー検出機能の使⽤： インデクサー検出により、各フォワーダーはマスターノードにクラスタ内
のすべてのピアノードの⼀覧を問い合わせます。そして、ロードバランシングを使い、データを⼀連のピア
ノードに転送します。マルチサイトクラスタの場合、フォワーダーは単⼀サイトのピアすべての⼀覧をマス
ターに問い合わせできます (任意)。「インデクサー検出によりフォワーダーをピアノードに接続」を参照し
てください。
フォワーダーをピアノードに直接接続： これは、フォワーダー/インデクサーの接続を設定する従来の⽅
法です。フォワーダーにレシーバー として直接ピアノードを指定します。「フォワーダーをピアノードに直
接接続」を参照してください。
インデクサー検出⽅法の利点
インデクサー検出は従来の⽅法より利点があります。
新しいピアノードがクラスタに加わる際に、新しいピアへの接続のためにフォワーダーを再設定や再起動す
る必要がありません。フォワーダーは⾃動的にマスターからピアのリストを更新します。また、ロードバラ
ンシングを使⽤して、リストのピアすべてに転送を⾏います。
クラスタピアの現在の設定を判断せずに新しいフォワーダーを追加できます。新しいフォワーダーにインデ
クサー検出を設定するだけです。
⼀連のピア全体へデータを転送する際は、重み付きロードバランシングを使⽤します。インデクサー検出に
より、マスターは各ピアのディスクスペース総容量を追跡し、この情報をフォワーダーに連絡できます。
ディスク容量に基づき、フォワーダーは各ピアに送信するデータの量を調整します。
各フォワーダーへのデータ⼊⼒設定
フォワーダーと受信ピア間の接続を指定したら、クラスタにデータを送信するための、各フォワーダーへのデータ
⼊⼒を指定する必要があります。⼀般的には、フォワーダーの inputs.conf ファイルを編集します。
データ⼊⼒の設定の詳細は、『データの取り込み』マニュアルの「Splunk がインデックス処理できる項⽬」を参
照してください。また、そのマニュアルの「フォワーダーの使⽤」には、フォワーダーのデータ⼊⼒の指定⽅法の
概要が記載されています。
インデクサー応答確認の仕組み
⼀貫したデータの忠実度を保証するためには、クラスタにデータを送信する各フォワーダーに対して明⽰的にイン
デクサー応答確認を有効にする必要があります。
インデクサー応答確認の仕組み：各フォワーダーは受信ピアに約 64 KB のブロックで継続的にデータを送信しま
す。フォワーダーは、ピアから応答確認を受信するまでの間、各ブロックのコピーを保持します。待機中でも、そ
の他のブロックは引き続き送信されます。
すべてが順調な場合、受信ピアは：
1. データブロックを受信し、それを解析してインデックスを作成し、データ (raw データとインデックスデータ)
をファイルシステムに書き込みます。
2. raw データのコピーを各ターゲットピアに配信します。
3. フォワーダーに応答確認を送信します。
応答確認により、データが正常にクラスタに書き込まれたことを確認できます。応答確認を受信すると、フォワー
ダーは当該ブロックをメモリーから解放します。
フォワーダーが応答確認を受信しない場合、それはデータ伝送路に障害が発⽣していることを意味しています。受
信ピアが停⽌しているか、またはピアが⼀連のターゲットピアと通信できていない可能性があります。フォワー
ダーは次に、⾃動的にデータブロックを再送信します。フォワーダーがロードバランシングを使⽤している場合
は、そのロードバランシンググループ内の他の受信ノードにブロックが送信されます。フォワーダーにロードバラ
ンシングが設定されていない場合は、前述のように同じノードにデータが再送信されます。
70
インデクサー応答確認の仕組みについては、『データの転送』マニュアルの「転送中データの消失の防⽌」を参照
してください。
ロードバランシングの仕組み
ロードバランシングでは、フォワーダーは到着データを複数の受信ピアノードに分散します。各ノードはデータ全
体の⼀部を受け取り、各受信ノードのデータをまとめたものが全データになります。
Splunk フォワーダーは⾃動ロードバランシングを実⾏します。フォワーダーは、指定された時間間隔に基づいて
異なるノードにデータをルーティングします。例えば、3 つのピアノード A、B、および C で構成されるロードバ
ランシンググループがあるとします。フォワーダーは、outputs.conf の autoLBFrequency 属性で指定された⼀定の間
隔で (デフォルトは 30 秒)、データストリームの転送先をグループ内の他のノードに切り替えます。ノードは無作
為に選択されます。例えばフォワーダーは、30 秒間隔で、ノード B からノード A に切り替え、次にノード C に
切り替えます。あるノードが停⽌すると、即座に別のノードに切り替えられます。
注意： もう少し詳しく説明すると、各フォワーダーの⼊⼒は、それぞれ独⾃のデータストリームを保有していま
す。フォワーダーは指定した間隔で、切り替えが安全な場合は、データストリームを新しく選択したノードに切り
替えます。新しいノードにデータストリームを安全に切り替えることができなかった場合は、そのノードに安全に
送信できるようになるまでの間、前のノードとの接続を維持してデータストリームの送信を継続します。
ロードバランシングとインデクサー応答確認は、クラスタ展開において重要な役割を果たします。ノード障害時に
も、データが失われることはありません。フォワーダーがデータを送信したノードからインデクサー応答確認を受
信しない場合、そのデータはロードバランシング内の次に利⽤できるノードに送信されます。
インデクサー検出機能を使⽤するフォワーダーは常にロードバランシングを使⽤して⼀連のピアノードにデータを
送信します。重み付きロードバランシングを有効にすると、フォワーダーは各ピアのディスク容量に基づいてデー
タを配布します。例えば、 400 GB のディスク容量があるピアは、200 GB ディスクのピアの 2 倍のデータを受
信します。「重み付きロードバランシングの使⽤」を参照してください。
詳細情報として、
インデックス検出を活⽤したロードバランシングについては、「インデクサー検出によりフォワーダーをピ
アノードに接続」を参照してください。
インデクサー検出なしのロードバランシングについては、『データの転送』マニュアルの「ロードバランシ
ングの設定」を参照してください。
インデクサー応答確認とロードバランシングの仕組みについては、『データの転送』マニュアルの「転送中
データの消失の防⽌」を参照してください。
インデクサー検出によりフォワーダーをピアノードに接続
インデクサー検出は、フォワーダーをインデクサークラスタのピアノードに接続するプロセスの能率を⾼めます。
インデクサークラスタの設定とメンテナンスを簡略化します。「インデクサー検出⽅法の利点」を参照してくださ
い。インデクサー検出は、インデクサークラスタへの転送にのみ使⽤できます。
各フォワーダーはマスターノードにクラスタ内のすべてのピアノードの⼀覧を問い合わせます。そして、ロードバ
ランシングを使い、データを⼀連のピアノードに転送します。マルチサイトクラスタの場合、フォワーダーはマス
ターに単⼀サイトのピアすべての⼀覧を問い合わせできます。
インデクサー検出の仕組み
プロセスの仕組みは、簡単には以下の通りです。
1. ピアノードがマスターに受信ポートの情報を提供する。
2. ⼀定の間隔でフォワーダーがマスターに利⽤可能なピアノードの⼀覧を問い合わせる。間隔は調整できます。
「ポーリング頻度の調整」を参照してください。
3. マスターがピアノードの URI と受信ポートをフォワーダーに送信する。
4. フォワーダーは、マスターが提供した⼀連のノードにデータを送信する。
この⽅法では、フォワーダーはクラスタに加⼊または退去するピアを検知し、受信中のピア群を適切に識別してク
ラスタの現在の状態を把握しています。
マルチサイトクラスタの場合、各フォワーダーがサイトのメンバーとして識別可能です。この場合、マスターはピ
アノードすべての⼀覧をこのサイトに対してのみ送信し、フォワーダーはロードバランシングをサイト経由のみに
限定します。「マルチサイトクラスタでのインデクサー検出の使⽤」を参照してください。
さらに、ピアノードは重み付きロードバランシングを使⽤して、各ピア間のディスク容量の⽐率に基づいて送信す
るデータ量を調節できます。「重み付きロードバランシングの使⽤」を参照してください。
注意： マスターが停⽌すると、フォワーダーは利⽤可能なピアノードの最新の⼀覧を参照します。⼀⽅で、⼀覧
はフォワーダーの再起動で失われます。そのため、フォワーダーがマスター停⽌中に再起動する場合、ピアノード
の⼀覧はなく、データが転送できなくなるため、データ損失の可能性があります。同様に、フォワーダーが初めて
起動する場合は、マスターがピアの⼀覧を渡すまで待機することになります。
インデックス検出の設定
インデクサー検出を使⽤して、フォワーダーとピアノード間の接続を設定するための主な⼿順は以下の通りです。
1. フォワーダーからデータを受信するようにピアノードを設定します。
71
2. マスターノードを設定して、インデクサー検出を有効にします。
3. フォワーダーを設定します。
接続を設定したら、フォワーダーのデータ⼊⼒を設定してください。「各フォワーダーへのデータ⼊⼒設定」を参
照してください。
1.フォワーダーからデータを受信するようにピアノードを設定します。
ピアがフォワーダーからデータを受信するためには、ピアの受信ポート を設定する必要があります。ピアの
inputs.conf ファイルを編集して受信ポートを指定することができます。例えば、inputs.conf のこの設定は受信
ポートを 9997 に設定します。
[splunktcp://9997]
disabled = 0
『データの転送』マニュアルの「レシーバーを有効にする」を参照してください。
注意： インデクサー検出を使⽤する場合、各ピアノードは単⼀の設定受信ポートしかありません。ポートは
splunktcp または splunktcp-ssl に設定できますが、両⽅同時にはできません。クラスタ内のピアノードにはすべて
同じ⽅法 splunktcp か splunktcp-ssl を使⽤してください。
同⼀の inputs.conf ファイルをすべてのピアに配布することにより、ピア⼊⼒設定の⼿間を減らすことができま
す。各ピア個別に指定した受信ポートよりも、共通版の inputs.conf に指定されている受信ポートが優先されま
す。すべてのピアにまたがった共通の inputs.conf の作成およびデプロイの詳細については、「共通のピア設定と
App の更新」を参照してください。
マルチサイトクラスタに転送する場合、特定の際とのピアにのみデータを送信するようフォワーダーを設定しま
す。「マルチサイトクラスタでのインデクサー検出の使⽤」を参照してください。
2.マスターノードを設定して、インデクサー検出を有効にする
マスターの
server.conf
に、このスタンザを追加します。
[indexer_discovery]
pass4SymmKey = <string>
polling_rate = <integer>
indexerWeightByDiskCapacity = <bool>
以下の事項に注意してください。
このスタンザの属性はすべて任意です。
pass4SymmKey 属性は、マスターとフォワーダー間のやりとりで使⽤されるセキュリティキーを指定します。
設定すると、フォワーダーすべてとマスターノードが同じ値である必要があります。マスターとクラスタ
ノード間のやりとりで使⽤される pass4SymmKey 属性とは異なる値があり、「セキュリティキーの設定」で説
明される通り、[clustering] スタンザに設定されます。
polling_rate 属性は、フォワーダーがマスターにピアノードの最新の⼀覧を問い合わせる頻度を調整する⽅
法を提供します。値は 1 から 10 までの整数です。デフォルトは 10 です。「ポーリング頻度の調整」を参
照してください。
indexerWeightByDiskCapacity 属性は、インデックス検出が重み付きロードバランシングを使⽤するかを判断し
ます。デフォルトは偽 (False) です。「重み付きロードバランシングの使⽤」を参照してください。
3.フォワーダーの設定
a . インデクサー検出を使⽤するためのフォワーダーの設定
各フォワーダーで、outputs.conf ファイルに設定を追加します。
[indexer_discovery:<name>]
pass4SymmKey = <string>
master_uri = <uri>
[tcpout:<target_group>]
indexerDiscovery = <name>
以下の事項に注意してください。
スタンザでは、<name> が [tcpout:<target_group>] スタンザの indexerDiscovery 属性
セットを参照します。
pass4SymmKey 属性は、マスターとフォワーダー間のやりとりで使⽤されるセキュリティキーを指定します。
フォワーダーすべてとマスターノードが同じ値である必要があります。
<master_uri> は、マスターノード⽤ URI と管理ポートです。例：https://10.152.31.202:8089
[tcpout:<target_group>] スタンザでは、indexerDiscovery 属性を、インデクサー検出を有効化しない場合に受
信ピアノードを指定するのに使う server 属性の代わりに設定します。インデクサー検出により、フォワー
[indexer_discovery:<name>]
の
<name>
72
ダーは server 属性からではなく、マスターから受信ピアノードの⼀覧を⼊⼿します。両⽅の属性が設定され
る場合、indexerDiscovery が優先されます。
b. 各フォワーダー上でインデクサー応答確認を有効にする
注意： このステップは、終端間データの忠実度を確保するために必要です。デプロイの要件で忠実度が不要な場
合は、このステップをスキップしても構いません。
クラスタがすべての到着データを受信してインデックス作成するために、各フォワーダー上でインデクサー応答確
認をオンにする必要があります。
インデクサー応答確認の設定には、indexerDiscovery 属性を設定する同じスタンザにおいて、各フォワーダーの
outputs.conf で、useACK 属性を設定します。
[tcpout:<target_group>]
indexerDiscovery = <name>
useACK=true
インデクサー応答確認の設定⽅法の詳細は、『データの転送』マニュアルの「転送中データの消失の防⽌」を参照
してください。
例
この例では：
マスターノードがインデクサー検出を有効にします。
マスターとフォワーダーはセキュリティキーを共有します。
フォワーダーはデータをピアノードのディスク総容量で加重されたピアノードに送信します。
フォワーダーはインデクサー応答確認を使⽤してデータのエンツーエンドの忠実度を確保します。
マスターノード上：server.conf：
[indexer_discovery]
pass4SymmKey = my_secret
indexerWeightByDiskCapacity = true
各フォワーダーの
output.conf：
[indexer_discovery:master1]
pass4SymmKey = my_secret
master_uri = https://10.152.31.202:8089
[tcpout:group1]
autoLBFrequency = 30
forceTimebasedAutoLB = true
indexerDiscovery = master1
useACK=true
[tcpout]
defaultGroup = group1
マルチサイトクラスタでのインデクサー検出の使⽤
マルチサイトクラスタでは、クラスタはクラスタノードの位置に基づき、サイトに分割されます。「マルチサイ
ト・インデクサー・クラスタ」を参照してください。
マルチサイトクラスタでインデクサー検出を使⽤すると、フォワーダーを設定してサイト認識が可能です。サイト
を認識したフォワーダーは、データをそのサイトのピアノードにのみ転送します。
マルチサイトクラスタの設定には、サイトに各ピアノードを割り当てます。マルチサイトクラスタでインデクサー
検出を使⽤すると、サイトに各フォワーダーを割り当てられます。マスターはフォワーダーに割り当てられたサイ
トのピアの⼀覧を提供し、それらのピアにのみデータ転送を⾏います。
重要： マルチサイトクラスタとインデクサー検出を使⽤すると、すべてのフォワーダーに site-id を割り当てる必
要があります。フォワーダーにサイト認識をさせたくない場合、特殊 site-id 「site0」を割り当てます。フォワー
ダーが「site0」を割り当てられると、クラスタ内のサイトすべてのピアに転送を⾏います。
サイトにフォワーダーを割り当てるには、フォワーダーの
[general]
site = <site-id>
以下の事項に注意してください。
73
server.conf
ファイルにスタンザを追加します。
はフォワーダーが属するサイトです。例：「site1」フォワーダーがデータを送信するマルチサイ
トクラスタのサイトで、有効でなければなりません。<site-id> の詳細は、「site の値」を参照してくださ
い。
フォワーダーに、サイト全体のピアにデータを送信させたい場合、site に「site0」の値を割り当てます。マ
スターがフォワーダーにクラスタのピアすべての⼀覧を送ります。
フォワーダーにサイトが割り当てられていない場合、マスターは空の⼀覧を送り、フォワーダーはいずれの
ピアノードにもデータを送信できません。
<site-id>
重み付きロードバランシングの使⽤
インデクサーリカバリを有効にすると、フォワーダーは常にロードバランシングを使⽤してノード間のデータスト
リームを切り替え、⼀連のピアノード全体へ受信データを送ります。フォワーダーがインデクサー検出なしでロー
ドバランシングを使⽤する⽅法に類似していますが、重要な違いがあります。特に、重み付きロードバランシング
を使⽤できる点が異なります。
重み付きロードバランシングでは、各ピアのディスク容量を反映した負荷分散が⾏われます。例えば、 400 GB
のディスク容量があるピアは、200 GB ディスクのピアのほぼ 2 倍のデータを受信します。
重要： ディスク容量は、空き容量ではなく、ピアのローカルディスクスペースの総容量を指しています。
重み付きロードバランシングの仕組み
重み付きロードバランシングは通常のフォワーダーロードバランシングと似た動作をします。フォワーダーの
output.conf ファイル内にある autoLBFrequency 属性には、データストリームが異なるインデクサーを切り替える頻
度がすでに設定されています。しかしながら、切り替え先の選択は相対的なディスク容量に基づき⾏われます。選
択はランダムですが、⼤きなディスク容量があるインデクサーが重み付けにより優先されます。
⾔い換えれば、フォワーダーは加重的な選択を⾏います。そのため、フォワーダーで autoLBFrequency が 60 に設定
されている場合、データストリームの送出を60 秒ごとに新しいインデクサーに切り替えます。ロードバランシン
グが、500 GB ディスクと 100 GB ディスクの 2 つのインデクサー間で⾏われる場合、⼤きい容量のあるディス
クを備えたインデクサーは切替時に 5 倍の確率で選択されます。
各インデクサーに送られる全体のトラフィックはこの⽐率に基づきます。
indexer_disk_capacity/total_disk_capacity_of_indexers_combined
インデクサークラスタのロードバランシングに関する説明は、「ロードバランシングの仕組み」を参照してくださ
い。
重み付きロードバランシングの有効化
マスターノードの
制御します。
server.conf
ファイル内にある
indexerWeightByDiskCapacity
属性が重み付きロードバランシングを
[indexer_discovery]
indexerWeightByDiskCapacity = <bool>
以下の事項に注意してください。
属性には、デフォルトでは「false」が設定されています。重み付きロードバラン
シングを有効にするには、値を「true」に設定します。
indexerWeightByDiskCapacity
インデクサー⽤表⽰ディスク容量の変更
実際より低いディスク容量しかなくても、重み付きロードバランシングにインデクサーの処理をさせたい場合があ
ります。その場合、advertised_disk_capacity 属性を使⽤して対応します。例えば、500 GB ディスクのインデク
サーに 50 (50%) と属性値を設定すると、重み付きロードバランシングが実際のディスク容量が 250 GB だった
かのように処理を⾏います。
インデクサーの
server.conf
ファイル内の
advertised_disk_capacity
属性を設定します。
[clustering]
advertised_disk_capacity = <integer>
以下の事項に注意してください。
属性は、容量をマスターに送る前に、インデクサーの実際のディスク容量に適⽤さ
れるパーセンテージを⽰します。例えば、500 GB ディスクのインデクサーに 50 を設定すると、インデク
サーはマスターにディスク容量が 250 GB であると伝えます。
値は 10 から 100 の間で異なります。
デフォルトは 100 です。
advertised_disk_capacity
ポーリング頻度の調整
フォワーダーは定期間隔でマスターにポーリングし、ピアの最新の⼀覧を受け取ります。この⽅法で、フォワー
ダーは利⽤可能なピアの設定変更を認識し、転送の修正を⾏います。ポーリングの頻度は調整可能です。
74
ポーリングの頻度は、フォワーダーの数とマスターの server.conf ファイルで設定される
基づきます。各フォワーダーのポーリング間隔はこの式に従います：
polling_rate
属性の値に
(number_of_forwarders/polling_rate + 30 seconds) * 1000 = polling interval, in milliseconds
以下にいくつかの例を⽰します。
# 100 forwarders, with the default polling_rate of 10
(100/10 + 30) * 1000 = 40,000 ms., or 40 seconds
# 10,000 forwarders, with the default polling_rate of 10
(10000/10 + 30) * 1000 = 1,030,000 ms., or 1030 seconds, or about 17 minutes
# 10,000 forwarders, with the minimum polling_rate of 1
(10000/1 + 30) * 1000 = 10,030,000 ms., or 10,030 seconds, or a bit under three hours
polling_rate
の設定には、マスターの
server.conf
にある
[indexer_discovery]
スタンザに属性を追加します。
[indexer_discovery]
polling_rate = <integer>
以下の事項に注意してください。
属性は 1 から 10 までの整数です。
デフォルトは 10 です。
polling_rate
フォワーダーをピアノードに直接接続
フォワーダーとピアノード間の接続設定の主な⼿順があり、各フォワーダーを各ピアノードに直接接続する従来の
⽅法を使⽤します。
1. フォワーダーからデータを受信するようにピアノードを設定します。
2. ピアノードにデータを送信するようにフォワーダーを設定します。
3. 各フォワーダー上でインデクサー応答確認を有効にします。このステップは、終端間データの忠実度を確保する
ために必要です。デプロイの要件で忠実度が不要な場合は、このステップをスキップしても構いません。
接続を設定したら、フォワーダーのデータ⼊⼒を設定してください。「フォワーダーのデータ⼊⼒の設定」を参照
してください。
1.フォワーダーからデータを受信するようにピアノードを設定します。
ピアがフォワーダーからデータを受信するためには、ピアの受信ポート を設定する必要があります。受信ポート
の設定⽅法については、『データの転送』マニュアルの「レシーバーを有効にする」を参照してください。
ピアの inputs.conf ファイルを編集して受信ポートを指定することができます。同⼀の inputs.conf ファイルをす
べてのピアに配布することにより、ピア⼊⼒設定の⼿間を減らすことができます。各ピア個別に指定した受信ポー
トよりも、共通版の inputs.conf に指定されている受信ポートが優先されます。すべてのピアにまたがった共通の
inputs.conf の作成およびデプロイの詳細については、「共通のピア設定と App の更新」を参照してください。
2.ピアノードにデータを送信するようにフォワーダーを設定します。
フォワーダーを設定する場合、受信ピアの IP アドレスと受信ポート番号を指定します。例：10.10.10.1:9997。こ
の作業は、フォワーダーの outputs.conf ファイルで⾏います。詳細は、『データの転送』マニュアルの
「outputs.conf によるフォワーダーの設定」を参照してください。受信ピアを指定するには、以下のように
server 属性を設定します。
server=10.10.10.1:9997
ここに指定する受信ポートは、ステップ 1 でピアに設定したポートです。
フォワーダーで、データを複数のピアノードに順番に提供するように、ロードバランシングを設定する場合、受信
ピアのロードバランシンググループを設定します。たとえば、outputs.conf 内の以下の属性/値のペアは、3 つのピ
アのロードバランシンググループを⽰します。
server=10.10.10.1:9997,10.10.10.2:9997,10.10.10.3:9997
ロードバランシングの詳細については、『データの転送』マニュアルの「ロードバランシングの設定」を参照して
ください。
注意： フォワーダーの受信ピアを指定するには、他にもさまざまな⽅法が存在します。例：
75
フォワーダーのデプロイ時に、受信ピアを指定することができます (Windows フォワーダーのみ)。『デー
タの転送』マニュアルの「Windows フォワーダーの⼿動デプロイ」を参照してください。
『データの転送』マニュアルのの「*nix フォワーダーの⼿動デプロイ」の説明に従って、CLI コマンド add
forward-server を使ってレシーバーを指定することができます。
これらの⼿法を利⽤するには、outputs.conf ファイルを変更します。どの⽅法で受信ピアを指定した場合でも、イ
ンデクサー応答確認をオンにしたい場合は、次の⼿順で説明しているように、outputs.conf ファイルを直接編集す
る必要があります。
3.各フォワーダー上でインデクサー応答確認を有効にします。
注意： このステップは、終端間データの忠実度を確保するために必要です。デプロイの要件で忠実度が不要な
場合は、このステップをスキップしても構いません。
クラスタがすべての到着データを受信してインデックス作成するために、各フォワーダー上でインデクサー応答確
認をオンにする必要があります。
インデクサー応答確認を設定するには、各フォワーダーの
outputs.conf
に
useACK
属性を設定します。
[tcpout:<peer_target_group>]
useACK=true
インデクサー応答確認の設定⽅法の詳細は、『データの転送』マニュアルの「転送中データの消失の防⽌」を参照
してください。
重要： インデクサー応答確認が正常に機能するように、フォワーダーの待機キューを適切なサイズに設定する必
要があります。5.0.4 以降のフォワーダーの場合は、システムがこれを⾃動的に調整します。それより前のバー
ジョンのフォワーダーの場合、そのバージョンのフォワーダーの「転送中データの消失の防⽌」の説明を参照して
ください。特に、そのサブトピックの maxQueueSize 設定に関する記事を⼊念にお読みください。
例：インデクサー応答確認を使⽤するロードバランシングフォワーダー
ロードバランシングを使ってクラスタ内の 3 つのピアに順番にデータを送信するフォワーダー⽤の outputs.conf
設定例を以下に⽰します。この例では、各ピアが受信ポートとして 9997 を使⽤すると仮定しています。
[tcpout]
defaultGroup=my_LB_peers
[tcpout:my_LB_peers]
autoLBFrequency=40
server=10.10.10.1:9997,10.10.10.2:9997,10.10.10.3:9997
useACK=true
フォワーダーは、まず server 属性に記載されているピアの中の 1 つにデータを送信することから開始します。40
秒後、別のピアに切り替えて、その後も同様に作業を⾏います。任意の時点でその時の受信ノードから応答確認が
ない場合、次に利⽤可能なノードにデータを再送信します。
インデクサークラスタの設定
インデクサークラスタの設定の概要
インデクサークラスタを設定するには、個別のノードを設定します。2 種類の設定を実施します。
クラスタ⾃体の動作の設定。
クラスタのインデックス作成とサーチ動作の設定。
この章は、特にクラスタ動作の設定⽅法の概要を説明しています。
各ノードタイプの設定
各ノードタイプの設定項⽬は、クラスタの異なる側⾯の動作に対応しています。
マスターノード： 総合的なクラスタ動作の設定。
ピアノード： 個別のピアノードとクラスタのインデックス作成動作の設定。
サーチヘッド： インデクサークラスタ内の個別のサーチヘッドおよびサーチ動作の設定。
各ノードタイプの設定の詳細は、該当するノードタイプの章を参照してください。たとえば、「ピアノードの設
定」には、ピアクラスタノードの設定に関するトピックや、ピアが使⽤するインデックス作成の設定⽅法を説明す
るトピックなどが含まれています。
クラスタ動作の設定⽅法
各ノードの初期設定はデプロイ時に⾏われます。クラスタノードのデプロイ後に設定を変更する必要がある場合
は、以下の⽅法があります。
76
Splunk Web でノードのダッシュボードから、設定を編集することができます。「ダッシュボードを使った
インデクサークラスタの設定」を参照してください。
ノードの server.conf ファイルで、[clustering] スタンザを直接編集する。詳細は、「server.conf を使った
インデクサークラスタの設定」を参照してください。⼀部の⾼度な設定を⾏うには、このファイルを編集す
る必要があります。
CLI を使⽤する。詳細は、「CLI によるインデクサークラスタの設定と管理」を参照してください。
ダッシュボードを使ったインデクサークラスタの設定
ダッシュボードを使ってインデクサー・クラスタ・ノードを設定するには：
1. ノード上で、Splunk Web の右側にある [設定] をクリックします。
2. [分散環境] セクションで、[インデクサークラスタリング] をクリックします。
3. ダッシュボードの右上にある [編集] ボタンを選択します。
各ノードタイプの設定の詳細は、以下の項⽬を参照してください。
「ダッシュボードを使ったマスターの設定」
「ダッシュボードを使ったピアノードの設定」
「ダッシュボードを使ったサーチヘッドの設定」
server.conf を使ったインデクサークラスタの設定
このトピックを参照する前に、『管理』マニュアルの「設定ファイルについて」およびそれ以降のトピックをご覧
ください。これらのトピックは、Splunk Enterprise が設定ファイルを使⽤⽅法について説明しています。
インデクサークラスタの設定は $SPLUNK_HOME/etc/system/local/ にある server.conf ファイルに存在しています。
Splunk Web または CLI を使ってクラスタノードをデプロイする場合、ノードは設定内容をこのファイルに保存
します。初期のデプロイ時またはその後の設定変更時に、server.conf ファイルを直接編集することも可能です。
インデクサークラスタを制御する server.conf のメインスタンザは、[clustering] です。Splunk Web の設定に対
応する基本属性の他に、server.conf はクラスタノード間の通信を制御する各種の⾼度な設定を提供しています。
Splunk サポートからの指⽰がない限り、これらの設定は変更しないでください。
このトピックは、すべてのノードタイプに共通ないくつかの問題について説明しています。
様々なノードタイプの設定
各ノードタイプに関する詳細は、以下の項⽬を参照してください。
「server.conf を使ったマスターの設定」
「server.conf を使ったピアノードの設定」
「server.conf を使ったサーチヘッドの設定」
詳細設定も含めたすべてのクラスタ属性の詳細は、server.conf の仕様を参照してください。
マルチサイトクラスタの設定については、「server.conf を使ったマルチサイト・インデクサー・クラスタの設
定」も参照してください。
セキュリティキーの設定
必要に応じて pass4SymmKey を指定して、マスター、ピア、およびサーチヘッド間の認証を⾏うためのセキュリティ
キーを設定することができます。あるクラスタノードにこれを設定した場合は、他のすべてのクラスタノードにも
同じ値を指定する必要があります。
インデクサークラスタ⽤の [clustering] スタンザにあるキーを設定します。ライセンス⽤に
ある pass4SymmKey も設定可能です。
[general]
スタンザに
重要： 鍵のコピーを安全な場所に保管する必要があります。インスタンスが動作を開始すると、セキュリティ
キーは平⽂から暗号化された形式に変更されるため、server.conf から復元することはできません。後ほど新たな
ノードを追加する場合、鍵を設定するために平⽂の鍵が必要になります。
server.conf 変更後の再起動
インスタンスを初めてクラスタノードとして設定する場合、変更内容を反映するためにそれを再起動する必要があ
ります。
後ほど設定を変更する場合、変更内容によってはインスタンスの再起動が必要ないことがあります。可能な場合
は、ピアの再起動を避けるようにしてください。⼀連のピアを再起動すると、バケツの修復処理に時間がかかる可
能性があります。
初期設定
インスタンスをクラスタノードとして初期設定したら、変更内容を有効にするためにそれらすべて (マスター、ピ
ア、およびサーチヘッド) を再起動する必要があります。このためには、各ノードで CLI の restart コマンドを実
77
⾏します。
$SPLUNK_HOME/bin/splunk restart
マスターを初めて起動した場合、複製データ保持数と同じ数のピアを有効にして再起動するまでは、ピアにおける
インデックス作成がマスターによりブロックされます。マスターがクラスタへのピア参加待ちの場合は、マスター
を再起動しないでください。再起動すると、ピアをもう⼀度再起動する必要があります。
重要： 最初にインスタンスをクラスタピアノードとして有効にするためには、CLI の restart コマンドを使⽤する
ことができますが、それ以降の再起動には、このコマンドを使⽤しないでください。いったんインデックスレプリ
ケーションが開始されると、restart コマンドはレプリケーションとの互換性がありません。安全な再起動⽅法な
ど、その他の情報については、「単⼀ピアの再起動」を参照してください。
以降の設定の変更
server.conf
ファイル内で以下のいずれかの属性を変更した場合、ノードを再起動する必要はありません。
ピアノードまたはサーチヘッド上：
master_uri
pass4SymmKey
マスターノード上：
quiet_period
heartbeat_timeout
restart_timeout
max_peer_build_load
max_peer_rep_load
pass4SymmKey
cluster_label
その他のクラスタ関連の設定を変更した場合は、再起動が必要です。
CLI を使ったインデクサークラスタの設定と管理
CLI を使って、さまざまなインデクサー・クラスタ・アクティビティを実施することができます。以下に例を⽰し
ます。
クラスタノードの設定
クラスタ情報の表⽰
クラスタの管理
⼀部のクラスタリングコマンドは、マスターノードなどの特定のノードタイプに対してのみ利⽤できます。
このトピックは、すべてのノードタイプに共通の問題について説明しています。
クラスタノードの設定
CLI を使⽤して、あらゆるタイプのクラスタノードの有効化または設定変更を⾏うことができます。
マスターノードの有効化または編集は、「CLI を使ったマスターの設定」を参照してください。
ピアノードの有効化または編集は、「CLI を使ったピアノードの設定」を参照してください。
サーチヘッドの有効化または編集は、「CLI を使ったサーチヘッドの設定」を参照してください。
特定のコマンドラインオプションの詳細は、「server.conf を使ったインデクサークラスタの設定」を参照してく
ださい。
マルチサイトクラスタの設定については、「CLI によるマルチサイト・インデクサー・クラスタの設定」も参照し
てください。
セキュリティキーの指定
各クラスタノードを有効化する際に、-secret フラグを追加することで、必要に応じてクラスタのセキュリティ
キーを指定することができます。例えば、ピアノード設定時に指定可能です：
splunk edit cluster-config -mode slave -master_uri https://10.160.31.200:8089 -replication_port 9887 -secret
your_key
セキュリティキーは、マスターとピアおよびサーチヘッド間の通信を認証します。鍵を指定する場合、すべてのク
ラスタインスタンス間で同じでなければなりません。たとえばマスターに対して指定した場合、それをすべてのピ
アとサーチヘッドに対しても指定する必要があります。
クラスタ情報の表⽰
78
各種クラスタ情報を返すさまざまな splunk list コマンドが⽤意されています。たとえば、クラスタ内の各ピアの
詳細情報を取得するには、マスター上で以下のコマンドを実⾏します。
splunk list cluster-peers
クラスタ設定に関する情報を取得するには、任意のノードから以下のコマンドを実⾏します。
splunk list cluster-config
splunk list
コマンドの全⼀覧については、CLI のクラスタリングに関するヘルプを参照してください。
クラスタの管理
CLI を使って、クラスタ上でさまざまなアクションを実⾏することができます。これらのアクションについては、
それぞれのトピックで説明されています。
ピアをオフラインにするには、splunk offline コマンドを使⽤します。
共通のピア設定を更新するには、splunk apply cluster-bundle コマンドを使⽤します。
すべてのクラスタピアを再起動するには、splunk rolling-restart cluster-peers コマンドを使⽤します。
メンテナンスモードを有効にするには、splunk enable maintenance-mode コマンドを使⽤します。
余分なバケツのコピーを削除するには、splunk remove excess-buckets コマンドを使⽤します。
複数クラスタサーチを設定します。
CLI コマンドのヘルプ
CLI には、各コマンドのオンラインヘルプが⽤意されています。クラスタリングコマンドの全般的なヘルプについ
ては、$SPLUNKHOME/bin で以下のコマンドを⼊⼒してください。
splunk help cluster
特定のコマンドのヘルプについては、コマンド名を指定します。例：
splunk help list cluster-config
CLI の全般情報については、『管理』マニュアルの「コマンドラインインターフェイス (CLI) による Splunk
Enterprise の管理」を参照するか、または以下のコマンドを⼊⼒します。
splunk help
マスターの設定
マスター設定の概要
マスターを有効にする際に、マスターの初期設定を⾏います。「インデクサークラスタのマスターノードを有効に
する」を参照してください。⼀般的に、マスターで必要な設定はこれだけです。
設定の変更
設定を編集する必要がある場合は、以下の⽅法を利⽤できます。
Splunk Web のマスターノードダッシュボードから設定を編集する。「ダッシュボードを使ったマスターの
設定」を参照してください。
マスターの server.conf ファイルで、[clustering] スタンザを直接編集する。⼀部の⾼度な設定を⾏うには、
このファイルを編集する必要があります。「server.conf を使ったマスターの設定」を参照してください。
CLI を使⽤する。「CLI を使ったマスターの設定」を参照してください。
マスター設定の変更後は、変更内容を反映するためにマスターを再起動する必要があります。
重要： マスターの唯⼀の機能は、他のクラスタノードを管理することです。これを外部データのインデックス作
成やクラスタのサーチに利⽤しないでください。
注意が必要な変更
これらの設定を変更する際には注意が必要です。
複製データ保持数とサーチ可能データ保持数。 後ほどインデクサークラスタが⼤量のデータを保有するよ
うになった後に、これらの設定値を増やすことはお勧めできません。そうすると⼤量のバケツアクティビ
ティが開始され、バケツのコピー作成中やバケツをサーチ可能な状態に変換中は、クラスタのパフォーマン
スに悪影響を与えてしまいます。
79
ハートビートタイムアウト。 Splunk サポートからの指⽰がない限り、heartbeat_timeout 属性はデフォルト
値の 60 (秒) から変更しないでください。特に、値を減らさないようにしてください。そうするとピアが過
負荷状態になる可能性があります。
スタンバイマスターの設定
マスターノード障害に対処するためには、現在のマスター停⽌時に処理を引き継ぐスタンバイマスターを設定しま
す。「インデクサークラスタのマスターノードの交換」を参照してください。
マルチサイトマスターの設定
マルチサイトマスターは、基本の単⼀サイトクラスタと⽐べてさまざまな点で設定上の違いがあり、また追加の設
定項⽬も存在しています。「server.conf を使ったマルチサイト・インデクサー・クラスタの設定」を参照してく
ださい。
ダッシュボードを使ったマスターの設定
ダッシュボードを使ってマスター設定を編集することができます。
1. Splunk Web の右上にある [設定] をクリックします。
2. [分散環境] セクションで、[インデクサークラスタリング] をクリックします。
3. ダッシュボードの右上にある [編集] ボタンを選択します。
注意： マルチサイトクラスタの場合、[編集 ] ボタンは無効になっています。
[編集] ボタンには、さまざまなオプションがあります。
ノードタイプ ：インスタンスのノードタイプを変更します。注意： アクティブなクラスタ内のノードの、
ノードタイプを変更することはほとんどありません。変更する場合は、その結果どうなるのかを慎重に検討
してください。
マスターノード設定 ：これらのマスターノード設定を変更します。
複製データ保持数 ：クラスタの複製データ保持数を変更します。警告： クラスタが⼤量のデータを保
有するようになってから、複製データ保持数の値を増やすことはお勧めできません。そうすると、数
多くのバケツアクティビティが開始され、バケツのコピー作成中は、クラスタのパフォーマンスに悪
影響を与えてしまいます。
サーチ可能データ保持数 ：クラスタのサーチ可能データ保持数を変更します。警告： クラスタが⼤量
のデータを保有するようになってから、複製データ保持数の値を増やすことはお勧めできません。そ
うすると、数多くのバケツアクティビティが開始され、バケツのコピーをサーチ可能に変換中は、ク
ラスタのパフォーマンスに悪影響を与えてしまいます。
セキュリティキー ：セキュリティキーを変更します。クラスタ内の他のすべてのノードでセキュリ
ティキーを変更する場合は、秘密鍵のみを変更してください。鍵は、クラスタ内のすべてのインスタ
ンス間で同じでなければなりません。
クラスタラベル： クラスタにラベルを加えます。ラベルは分散管理コンソール内のクラスタ特定に役
⽴ちます。『分散管理コンソール』マニュアルの「クラスタラベルの設定」を参照してください。
設定バンドルの配布： 更新した設定と App を⼀連のピアノードに配布します。このプロセスの詳細は、
「共通のピア設定と App の更新」を参照してください。
インデクサークラスタリングを無効にする ：クラスタからこのノードを削除します。警告： クラスタから
マスターノードを削除すると、その後順次クラスタ全体が機能しなくなっていきます。
このダッシュボードを使ったクラスタステータスの表⽰については、「[マスター] ダッシュボードの表⽰」を参照
してください。
server.conf を使ったマスターの設定
最初にお読みください：
このトピックをお読みになる前に、以下の項⽬を参照してください。
「server.conf を使ったインデクサークラスタの設定」。このトピックは、クラスタ設定の基本を説明して
います。すべてのノードタイプに共通ないくつかの問題について説明しています。
マスターノードを有効にする
以下の例では、マスターノードを有効にする際に設定する必要がある、基本的な項⽬を表しています。特段の注記
がない限り、設定は必須です。記載されている設定属性は、Splunk Web の [クラスタリングを有効にする]
ページのフィールドに対応しています。
[clustering]
mode = master
replication_factor = 4
search_factor = 3
pass4SymmKey = whatever
cluster_label = cluster1
この例では、以下の事項を指定しています。
インスタンスはクラスタマスターノード。
80
クラスタの複製データ保持数は 4。
クラスタのサーチ可能データ保持数は 3。
セキュリティキーは「whatever」。セキュリティキーは任意ですが、設定を推奨します。「セキュリティ
キーの設定」を参照してください。
クラスタラベルは、「cluster1」です。任意のクラスタラベルは分散管理コンソール内のクラスタ特定に役
⽴ちます。『分散管理コンソール』マニュアルの「クラスタラベルの設定」を参照してください。この属性
は、マスターノードにのみ設定します。
重要： マスターを初めて起動した場合、すべてのピア (複製データ保持数と同じ数のピア) を有効にして再起動す
るまで、ピアにおけるインデックス作成はマスターによりブロックされます。マスターがクラスタへのピア参加待
ちの場合は、マスターを再起動しないでください。再起動すると、ピアをもう⼀度再起動する必要があります。
注意： Splunk Web でマスターノードを有効にする場合、結果となる server.conf スタンザには⾮デフォルト値の
属性のみが含まれます。たとえば、S複製データ保持数のデフォルト値 3 を使⽤して、新しい値を指定しない場
合、スタンザに replication_factor 属性は含まれません。
マスター設定の編集
必要に応じてこれらの設定を変更できます。たとえば、クラスタのセキュリティキーを変更するには、各ノードの
pass4SymmKey の値を編集します。
ほとんど編集の必要がない⾼度な属性も含めた、すべてのクラスタ属性の詳細は、server.conf ファイルを参照し
てください。
CLI を使ったマスターの設定
最初にお読みください：
このトピックをお読みになる前に、以下の項⽬を参照してください。
「CLI を使ったインデクサークラスタの設定と管理」を参照してください。このトピックは、CLI を使った
インデクサークラスタ設定の基本を説明しています。すべてのノードタイプに共通ないくつかの問題につい
て説明しています。
マスターノードを有効にする
以下の例では、マスターノードを有効にする際に通常設定する必要がある、基本的な項⽬を表しています。記載さ
れている設定属性は、Splunk Web の [クラスタリングを有効にする] ページのフィールドに対応しています。
splunk edit cluster-config -mode master -replication_factor 4 -search_factor 3 -secret your_key -cluster_label
cluster1
splunk restart
重要： マスターを初めて起動した場合、すべてのピア (複製データ保持数と同じ数のピア) を有効にして再起動す
るまで、ピアにおけるインデックス作成はマスターによりブロックされます。マスターがクラスタへのピア参加待
ちの場合は、マスターを再起動しないでください。再起動すると、ピアをもう⼀度再起動する必要があります。
マスター設定の編集
CLI を使って後ほど設定を編集することもできます。最初にマスターを有効にする際に使ったのと同じコマンド
の、splunk edit cluster-config コマンドを使⽤してください。
設定可能な項⽬については、CLI のヘルプおよび server.conf 仕様ファイルを参照してください。
警告：マスター上で複製データ保持数またはサーチ可能データ保持数を増やさないでくだ
さい
複製データ保持数とサーチ可能データ保持数を変更することは可能ですが、クラスタに⼤量のデータが保管された
後に、これらの設定を増やすことはお勧めできません。そうすると、数多くのバケツアクティビティが開始され、
バケツのコピー作成中またはサーチ可能コピーに変換中の間、クラスタのパフォーマンスに悪影響を与えてしまい
ます。
インデクサークラスタのマスターノードの交換
以下のような理由で、マスターノードを交換しなければならないことがあります。
ノードに障害が発⽣した。
マスターを別のマシンまたはサイトに移動する必要がある。
現在マスターのフェイルオーバー機能はありませんが、プライマリマスターが停⽌した場合に即座に⽴ち上げるこ
とができる、インデクサークラスタにスタンバイマスターを設定してマスター障害に備えることができます。同じ
⽅法を使って意図的にマスターを交換することもできます。
このトピックでは、マスター交換の主要な⼿順を説明しています。
1. スタンバイ/交換⽤マスターに必要なファイルをバックアップします。
81
重要： これは事前準備の作業です。この作業はマスターに障害が発⽣する前に⾏う必要があります (そうしないと
システムから削除されてしまいます)。
2. ピアとサーチヘッドが、新しいマスターに接続するように準備します。
3. 古いマスターを、新しいマスターと交換します。
重要： マルチサイトクラスタの場合、マスターがあるサイトの障害に備えて、そこに予備のマスターを準備する
必要があります。「マスターサイト障害の取り扱い」を参照してください。
交換⽤マスターが必要とするファイルのバックアップ
交換⽤マスターを準備する際に、コピーする必要があるのはマスターの静的な状態のみです。
注意： クラスタの動的な状態をコピーする必要はありません。すべてのクラスタコピーの状態などのクラスタに
関する動的情報は、すべてクラスタピアのグループが保持します。ピアはこの情報を必要に応じてマスターノード
とやり取りします (例：マスターがクラスタに復帰した場合、または停⽌したマスターをスタンバイマスターが引
き継いだ場合)。マスターはその情報を使って、クラスタの動的状態マップを再構築します。
マスター上には、バックアップする必要がある 2 つの静的設定があります。バックアップ後は、それを交換⽤マ
スターにコピーします。
マスタークラスタの設定が保管されている、マスターの server.conf ファイル。マスターのクラスタ設定を変
更した時は常にこのファイルをバックアップする必要があります。
「共通のピア設定と App の更新」で説明しているように、共通のピア設定が保管されている、マスターの
$SPLUNK_HOME/etc/master-apps ディレクトリ。ピアノードに配布するコンテンツセットを更新した時は常に、
このディレクトリをバックアップする必要があります。
ピアとサーチヘッドノードが新しいマスターを⾒つけられるようにする
ピアノードとサーチヘッドが交換⽤インスタンスを探して、それをマスターとして正しく認識できるようにするた
めには、2 種類の⽅法があります。
交換⽤マスターがプライマリ・マスターと同じ IP アドレスと管理ポートを使⽤する場合。 交換⽤マス
ターが同じ IP アドレスを使⽤するように、DNS ベースのフェイルオーバー、ロード・バランサー、または
その他のテクニックを採⽤する必要があります。管理ポートはインストール時に設定されますが、後ほど
web.conf を編集して変更することができます。
交換⽤マスターがプライマリ・マスターと同じ IP アドレスまたは管理ポートを使⽤しない場合。 この
場合は、新しいマスターを⽴ち上げた後に、ピアとサーチヘッドの master_uri 設定を編集して、新しいマス
ターの IP アドレスと管理ポートを指⽰する必要があります。
重要： どちらの⽅法でも、ピアノードまたはサーチヘッドを再起動する必要があります。
マスターの交換
2 セットの静的設定ファイルをバックアップしている場合を考えてみましょう。マスターを交換する⼿順は簡単で
す。
1. 予定されていた交換作業の場合、古いマスターを停⽌します。マスター障害による交換の場合、このステップは
すでに完了しています。
2. 新しい Splunk Enterprise をインストール、開始、および停⽌します。これが交換⽤マスターになります。
3. 交換⽤マスターの
4. 古いマスターの
コピーします。
5. コピーした
ます。
server.conf
server.conf
server.conf
内の
ファイルから⼀時ディレクトリに
および
$SPLUNK_HOME/etc/master-apps
sslKeysfilePassword
sslKeysfilePassword
設定をコピーします。
ファイルのバックアップを、交換⽤マスターに
設定を削除して、それをステップ 3 で保存した設定に置き換え
6. 交換⽤マスターを開始します。
7. 前述の「ピアとサーチヘッドノードが新しいマスターを⾒つけられるようにする」に記載されているいずれかの
⽅法を使って、ピアおよびサーチヘッドノードが新しいマスターを指していることを確認します。
注意： ステップ 3 とステップ 5 を省略したい場合は、server.conf ファイル全体をコピーする代わりに、交換⽤マ
スター上の [general] と [clustering] スタンザを置換します。
マスター障害時にどうなるかについては、「マスターノード停⽌時の処理」を参照してください。
ピアの設定
ピアノード設定の概要
ピアノードの設定は、2 つのカテゴリに分類できます。
82
マスター URI や複製ポートなどの、インデクサークラスタの基本設定。
データ取り込み、インデックス作成、および他の関連する設定。これには、App のピアノードへのデプロイ
が含まれます。
初期設定
ピアクラスタ設定の⼤部分は初期デプロイ中に⾏われます。
1. ピアを有効にする際に、マスターノードおよび複製されたデータを受信するポートなどのクラスタに関する設定
を⾏います。「ピアノードを有効にする」を参照してください。
2. ⼀連のピアセットを有効にしたら、必要に応じてインデックスを設定します。「インデクサークラスタ内のピア
インデックスの設定」を参照してください。
3. 最後に、⼊⼒を設定します。通常は、フォワーダーを使⽤します。「フォワーダーを使ったインデクサークラス
タへのデータの取り込み」を参照してください。
これがピア設定の主要ステップです。後ほどピアの設定を変更しなければならないこともあります。
クラスタ設定の変更
クラスタノード設定を変更するには、主に 2 つの理由があります。
ピアを他のマスターにリダイレクトする。 マスターに障害が発⽣したけれども、処理を引き継ぐスタンバ
イマスターが⽤意されている場合などに役⽴ちます。スタンバイ・マスターの詳細は、「インデクサークラ
スタのマスターノードの交換」を参照してください。
クラスタのピアのセキュリティキーを変更する。 クラスタ内の他のすべてのノードでセキュリティキー変
更する場合にのみ、秘密鍵を変更してください。鍵は、クラスタ内のすべてのインスタンス間で同じでなけ
ればなりません。
クラスタ設定を編集するには、以下のいずれかの⽅法を使って各ピアノードを個別に変更します。
Splunk Web のピアノードダッシュボードから設定を編集する。「ダッシュボードを使ったピアノードの設
定」を参照してください。
ピアの server.conf ファイルを編集する。詳細は、「server.conf を使ったピアノードの設定」を参照してく
ださい。
CLI を使⽤する。詳細は、「CLI によるピアノードの設定」を参照してください。
マルチサイト・ピア・ノードを設定する場合の違いや追加作業については、「server.conf を使ったマルチサイ
ト・インデクサー・クラスタの設定」を参照してください。
インデックス作成および関連する動作の設定
「ピア単位での設定の管理」で説明している⾮常に限られた例外的状況を除いて、indexes.conf 内の⼀連のイン
デックススタンザはすべてのピア上で同⼀でなければなりません。また、インデックス時処理もすべてのピア間で
同⼀でなければなりません。クラスタが正常にデータを複製して、ノードのフェイルオーバーを実施できるよう
に、ピアは同じインデックス機能を共有する必要があります。ピア間で⼀部の主要ファイルが異なっている場合、
正常に処理を⾏うことができません。
ベストプラクティスとして、ピアは交換可能なものとして取り扱う必要があります。そのためには、同じバージョ
ンの設定ファイルと App を、すべてのピアに対して適⽤する必要があります。最低でも、次のファイルが同じで
なければなりません：
indexes.conf
props.conf
transforms.conf
ピアが共通の設定ファイルと App のセットを共有するように、マスター上にファイルと App を配置した後、設
定バンドルを使⽤すれば、単⼀の操作で⼀連のピアにそれを配布することができます。
以下のトピックでは、⼀連のピアでの同⼀の設定の維持管理⽅法について説明していきます。
すべてのピアの共通設定の管理
すべてのピアの App デプロイの管理
インデクサークラスタ内のピアインデックスの設定
共通のピア設定と App の更新
単⼀ピア設定の管理
テストや他の⽬的で、⼀部の設定をピア単位で処理しなければならないこともあります。それでも⼀般的には、ピ
アを相互交換できるようにすべてのピアで同じ設定を使⽤することをお勧めします。
単⼀ピア設定の詳細は、「ピア単位での設定の管理」を参照してください。
ダッシュボードを使ったピアノードの設定
ダッシュボードを使ってピアクラスタ設定を編集することができます。ダッシュボードにアクセスするには：
83
1. Splunk Web の右上にある [設定] をクリックします。
2. [分散環境] セクションで、[インデクサークラスタリング] をクリックします。
3. ダッシュボードの右上にある [編集] ボタンを選択します。
[編集] ボタンは、設定に影響する各種オプションを提供しています。
注意： マルチサイトクラスタの場合、[編集 ] ボタンは無効になっています。
このダッシュボードを使ったクラスタステータスの表⽰については、「[ピア] ダッシュボードの表⽰」を参照して
ください。
クラスタ設定の変更
このピアノードの設定を変更するには、[設定] オプションを選択します。
マスターを変更するには、[マスター URI] フィールドを編集します。
複製⽤ポートを変更するには、[ピア複製⽤ポート] フィールドを編集します。
セキュリティキーを変更するには、[セキュリティキー] フィールドを編集します。
クラスタからのサーチヘッドの削除
クラスタからピアを削除するには、[インデクサークラスタリングを無効にする] オプションを選択します。
その他の編集
[編集] ボタンには、もう 1 つのオプション「ノードタイプ 」があります。
注意： アクティブなクラスタ内のノードの、ノードタイプを変更することはほとんどあり得ません。変更する場
合は、その結果どうなるのかを慎重に検討してください。
server.conf を使ったピアノードの設定
最初にお読みください：
このトピックをお読みになる前に、以下の項⽬を参照してください。
「server.conf を使ったインデクサークラスタの設定」。このトピックは、クラスタ設定の基本を説明して
います。インデクサークラスタのすべてのノードタイプに共通ないくつかの問題について説明しています。
ピアノードを有効にする
以下の例では、ピアノードを有効にする際に設定する必要がある、基本的な項⽬を表しています。これらの例に記
載されている設定属性は、Splunk Web の [クラスタリングを有効にする] ページのフィールドに対応していま
す。
[replication_port://9887]
[clustering]
master_uri = https://10.152.31.202:8089
mode = slave
pass4SymmKey = whatever
この例では、以下の事項を指定しています。
ピアはポート 9887 で他のピアから転送される複製データを待機。利⽤可能な任意の未使⽤ポートを複製
ポートとして指定することができます。管理⽤または受信⽤ポートを再利⽤しないでください。
ピアのクラスタマスターの場所は 10.152.31.202:8089 です。
インスタンスはクラスタピア (スレーブ) ノード。
セキュリティキーは「whatever」。
ピア設定の編集
必要に応じてこれらの設定を変更できます。たとえば、クラスタのセキュアサーバーを変更するには、各ノードの
pass4SymmKey の値を変更します。
CLI を使ったピアノードの設定
最初にお読みください：
このトピックをお読みになる前に、以下の項⽬を参照してください。
「CLI を使ったインデクサークラスタの設定と管理」を参照してください。このトピックは、CLI を使った
クラスタ設定の基本を説明しています。インデクサークラスタのすべてのノードタイプに共通ないくつかの
問題について説明しています。
84
ピアノードを有効にする
以下の例では、ピアノードを有効にする際に設定する必要がある、基本的な項⽬を表しています。記載されている
設定属性は、Splunk Web の [クラスタリングを有効にする] ページのフィールドに対応しています。
インスタンスをピアノードとして有効にするには、mode に「slave」を設定します。master_uri および
replication_port も設定する必要があります。任意で、セキュリティキー (secret) の指定が可能です。
splunk edit cluster-config -mode slave -master_uri https://10.160.31.200:8089 -replication_port 9887 -secret
your_key
splunk restart
ピア設定の編集
CLI を使って後ほど設定を編集することもできます。最初にピアを有効にする際に使ったのと同じコマンド
の、splunk edit cluster-config コマンドを使⽤してください。
設定可能な項⽬については、CLI のヘルプおよび server.conf 仕様ファイルを参照してください。
すべてのピアの共通設定の管理
App を含む⼀連の設定ファイルは、インデクサークラスタのすべてのピアの間で共通したものとすべきです。こ
れにより、ピアを事実上交換可能にすることで、可⽤性をさらに⾼めます。各ピアで同様のインデックスが作成さ
れるよう、同⼀にする必要のある設定もいくつか存在します。
マスターノードは設定バンドル ⽅法により、⼀度にすべてのピアにファイルや App を配布します。この⽅法を使
⽤して、共通設定を管理してください。「共通のピア設定と App の更新」を参照してください。
すべてのピア間で同じであるファイル
以下のファイルは、すべてのピア間で同⼀のバージョンを配布することをお勧めします。
indexes.conf。すべてのピアが⼀連のクラスタインデックスの共有をすることが重要です。
および transforms.conf。すべてのピアがデータのインデックス作成を⾏う際、共通のルールを使
⽤する必要があります。
props.conf
これらの 3 つの主要ファイルだけでなく、その他の設定ファイルも同じバージョンをすべてのピアで使⽤するこ
とにより、クラスタの管理を⼤幅に簡素化することができます。たとえば、すべてのピアが単⼀のデータ⼊⼒セッ
トを共有できる場合、この⽅法を使って単⼀の inputs.conf ファイルをすべてのピア間で保持することができま
す。
App にはそれらの設定ファイルのバージョンが含まれていることが多いため、単⼀のピアに別個に App をインス
トールするのではなく、すべてのピアに同じ⼀連の App を配布する必要があります。「すべてのピアの App デ
プロイの管理」を参照してください。
注意： 限定された環境下 (たとえば、ローカルテストやモニタリング) では、インデックスを 1 台のピアにのみ追
加し、他のピアには追加しないこともあります。インデックスの設定を注意深く⾏い、その結果や悪影響について
⼗分に理解している場合にのみ、単⼀のピアの indexes.conf を作成し、それを適⽤するようにしてください。その
ようなインデックス内のデータは複製されません。単⼀ピアの indexes.conf が補⾜的に使⽤されますが、すべての
ピアが使⽤する共通バージョンの設定に代わることはありません。必要に応じて同様の⽅法で、単⼀ピアの App
を管理することができます。「単⼀ピアへのインデックスの追加」を参照してください。
すべてのピアに設定ファイルの配布
ピアノードに設定ファイルの配布をするには次の⼿順に従います。
1. indexes.conf ファイルを配布する場合、設定を⾏うことでインデックスレプリケーションのサポートが可能で
す。「インデクサークラスタ内のピアインデックスの設定」を参照してください。
2. ファイルをマスターの $SPLUNK_HOME/etc/master-apps ディレクトリに配置します。この場所の⼀連のサブディレク
トリが設定バンドルを構成しています。
3. Splunk Web または CLI を使⽤してピアノードに設定バンドルを配布します。
この⼿順の詳細は、「共通のピア設定と App の更新」を参照してください。
スタンドアロンのインデクサーと⽐べたピア設定の管理
設定バンドルを使⽤する⽅法は、⼀連のピアにまたがって共通の設定と App のデプロイを管理する唯⼀のサポー
トされている⼿段です。これにより、すべてのピアで同じバージョンの設定ファイルを使⽤することができます。
スタンドアロンのインデクサーの設定管理と⽐べて、ピア設定ファイルを管理する際にはいくつかの重要な違いが
あることに注意してください。
クラスタ単位で管理する必要がある設定の変更を、個別のピアで⾏わないでください。たとえば、Splunk
Web や CLI を使ってインデックス設定を⾏わないでください。
85
ピア上で、indexes.conf などのクラスタ全体の設定ファイルを直接編集しないでください。代わりに、マス
ター上のファイルを編集して、設定バンドルを利⽤してそれを配布してください。
ピアノードにまたがって共通の設定ファイルを管理するために、デプロイサーバーやサードパーティ製のデ
プロイツール (Puppet や CFEngine など) は使⽤しないでください。代わりに、設定バンドルを使⽤しま
す。
設定バンドルを利⽤して更新を配布する場合、マスターが配布を担当して、すべてのピアが同じクラスタ化イン
デックスセットも含む⼀連の設定を使⽤するように設定します。
推奨事項によらず、設定バンドル以外の他の配布⽅法を使⽤する場合は、新しいインデックスにデータの送信を開
始する前に、最低でも新たにクラスタ化されたインデックスの設定がすべてのピアに正常に配布されたこと、およ
びすべてのピアが再ロードされたことを確認する必要があります。
注意： デプロイサーバーを使ってピアに直接 App を配布することはできませんが、デプロイサーバーを使ってマ
スターノードの設定バンドル保管場所に App を配布することは可能です。この場所に App を保管したら、次に
設定バンドルを使⽤して、ピアノードに App を配布します。「デプロイサーバーを使ったマスターノードへの
App の配布」を参照してください。
すべてのピアの App デプロイの管理
このトピックをお読みになる前に、「すべてのピアの共通設定の管理」を参照してください。App のデプロイ
は、このトピックに記載されている設定ファイルのデプロイの、単なる特殊な事例です。
重要：マスターノードを使⽤して、ピアノードに App をデプロイします。デプロイサーバーやサードパーティ製
のデプロイツール (Puppet や CFEngine など) は使⽤しないでください。
ピアノードに App の配布をするには次の⼿順にしたがいます。
1. indexes.conf ファイル向けに App を検査します。App 固有の indexes.conf ファイルに定義されている各イン
デックスに対して、インデックスがすべてのピアに複製されるように、repFactor=auto を明⽰的に設定します。
「indexes.conf の repFactor 属性」を参照してください。
2. App をマスターの $SPLUNK_HOME/etc/master-apps ディレクトリに配置します。この場所の⼀連のサブディレクト
リが設定バンドル を構成しています。
3. Splunk Web または CLI を使⽤してピアノードに設定バンドルを配布します。
これら⼿順の各詳細は、「共通のピア設定と App の更新」を参照してください。
⼀連のピアに App が配布されたら、各ピア上で Splunk Web を使って、普段通りに App を起動することができ
ます。『管理』マニュアルの「Splunk App について」を参照してください。
App にアクセスする場合、個別のピアではなくサーチヘッドからアクセスします。そのため、サーチヘッド上に
も App をインストールする必要があります。サーチヘッド上では、App ⽤の標準ディレクトリ
$SPLUNK_HOME/etc/apps に App を配置します。
インデクサークラスタ内のピアインデックスの設定
インデックスの設定は、indexes.conf ファイルを編集することで⾏います。このファイルは、インデクサーの⼀
連のインデックス、およびバケツ のサイズと属性を決定します。クラスタ内のすべてのピアが同じインデックス
セットを使⽤する必要があるため (後述する特定の⽬的がある場合を除く)、通常すべてのピアで indexes.conf ファ
イルを同じにする必要があります。
クラスタピアは、基本的なクラスタのニーズに対応するピア固有のデフォルト indexes.conf ファイルでデプロイさ
れます。インデックスを追加、またはバケツの動作を変更する場合は、マスター上の特別な場所に存在している
indexes.conf ファイルを編集して、そのファイルをすべてのピアに同時に配布します。
重要： Splunk Web または CLI を使ってピアノードのインデックス設定を変更することはできませ
ん。indexes.conf を直接変更する必要があります。
すべてのピアが同じ indexes.conf ファイルセットを使⽤する必要があります
通常 indexes.conf ファイルセットは、クラスタ内のすべてのピアで同⼀でなければなりません。特に、すべてのピ
アが同じクラスタ化されたインデックスセットを使⽤する必要があります。これは、インデックスレプリケーショ
ンが正常に機能するための必須事項です。(⼀⽅、マスターノードは⾃⼰の内部データのみのインデックスを作成
するため、独⾃の indexes.conf ファイルを持ちます。)この制限事項には、後述するように限定的な例外事項があ
ります。
クラスタを最初に作成する場合、マスターは各ピアに特別なデフォルトの indexes.conf ファイルを配布します。こ
のバージョンは、すべての Splunk インデクサーが取得するデフォルト標準の indexes.conf を補⾜するものです。
ピア固有のデフォルトの indexes.conf は、main インデックス、および_audit や _internal などの内部インデックス
のレプリケーションをオンにします。
システムによっては、追加のインデックスやバケツ属性の変更を適⽤するために、変更された indexes.conf のイン
デックス/バケツ属性をさらに編集して、ピアに配布しなければならないこともあります。すべてのピアが同じ
indexes.conf を使⽤するように、マスターノードを使ってすべてのピアに⼀度にファイルを配布する必要がありま
す。この設定バンドル を使⽤する⽅法については、「共通のピア設定と App の更新」を参照してください。
86
設定バンドルを使って、すべてのピアに App を配布する必要があります。これらの App には独⾃の indexes.conf
ファイルが含まれている場合もあります。このファイルは、App 外の他のバージョンのファイルと共存して処理
が⾏われていることもあり、そのような場合は他のピアにも配布する必要があります。App 配布の詳細は、「す
べてのピアの App デプロイの管理」を参照してください。
注意： 限定された環境下では (たとえば、ローカルテストや監視を⾏うために)、単⼀のピア専⽤の indexes.conf
を作成することもできます。ただし、そのようなインデックスは複製されません。単⼀ピアの indexes.conf が補⾜
的に使⽤されますが、すべてのピアが使⽤する共通バージョンの設定に代わることはありません。詳細は、「単⼀
ピアへのインデックスの追加」を参照してください。
ピアのインデックスセットの設定
⼀連のピアにまたがるインデックスを設定する作業は、2 つのステップから成り⽴っています。
1. マスター上で共通の
indexes.conf
ファイルを編集します。
2. マスターを使って、⼀連のピアにファイルを配布します。
これらの 2 つのステップの詳細を以下に⽰します。
1.indexes.conf の編集
の設定⽅法の詳細は、このマニュアルの「インデックスの管理」および「インデックスストレージの
管理」を参照してください。indexes.conf の属性の⼀覧については、『管理』マニュアルの indexes.conf に関す
る説明を参照してください。
indexes.conf
⼤部分は、他の任意のインデクサーと同様に、クラスタピアの
いに注意する必要があります。
indexes.conf
を編集します。ただし、いくつかの違
indexes.conf の repFactor 属性
新しいインデックススタンザを追加する場合、repFactor 属性に「auto」を設定する必要があります。これによ
り、インデックスのデータがクラスタ内の他のノードに複製されます。例：
[<newindex>]
repFactor=auto
homePath=<path for hot and warm buckets>
coldPath=<path for cold buckets>
thawedPath=<path for thawed buckets>
...
注意： デフォルトで repFactor には 0 が設定されています。この場合、インデックスは複製されません。クラスタ
構成のインデックスの場合は、「auto」を設定する必要があります。
を「auto」から「0」にリセットすることで、更なる複製を⽌めますが、⾃動的に既に複製されたバケツ
のコピーを取り除きません。加えて、複数のコピーを有するバケツ全体のサーチは複製イベントを返します。空き
ディスク容量を増やし、複製イベントの可能性を除去するには、余分のコピーを⼿動で削除する必要があります。
repFactor
スラッシュディレクトリ区切り⽂字による homePath と coldPath の指定
異種混在環境では、マスターノードの OS でディレクトリパスの指定に、ピアノードの OS とは異なる表記規則
を使⽤している場合があります。indexes.confファイルはマスターノード上で編集し、次にそれをピアに配布する
ため、このことが問題になる可能性があります。
たとえば、マスターノードで Windows、ピアで Linux を使⽤している場合に、通常 Windows マスターで
homePath を指定する際には、ディレクトリ区切り⽂字として円記号を使⽤します。しかし、Linux ピアに配布する
ファイルには、ディレクトリ区切り⽂字としてスラッシュを使⽤する必要があります。
この問題に対処するために、マスターやピアが使⽤しているオペレーティングシステムの種類に関係な
く、homePath および coldPath でディレクトリパスを指定する時には、常にスラッシュを使⽤することをお勧めしま
す。例：
homePath = $SPLUNK_HOME/var/lib/splunk/defaultdb/db/
Splunk Enterprise は常に、スラッシュをディレクトリ区切り⽂字として認識します。
2.新しい indexes.conf ファイルのピアへの配布
indexes.confを編集したら、それをクラスタの⼀連のピアノードに配布する必要があります。indexes.conf
を含めた
設定ファイルのすべてのピアへの配布⽅法については、「共通のピア設定と App の更新」を参照してください。
App の配布も含めたその他の種類のピア設定については、「ピアノード設定の概要」を参照してください。
インデックスの確認
ピアノードで⼀連のインデックスを確認するには、マスターダッシュボードの [インデックス] をクリックしま
87
す。「[マスター] ダッシュボードを有効にする」を参照してください。
注意： 新しいインデックスは、データが含まれて初めてタブの下に現れます。⾔い換えると、ピアノードに新し
いインデックスを設定すると、そのインデックスの⾏はインデックスにデータを送信して初めて表⽰されます。
共通のピア設定と App の更新
このトピックに記述されているピア更新プロセスにより、すべてのピアノードが共通の主要設定ファイルを共有す
ることが保証されます。ピアノードに App も含めた共通のファイルを配布、更新するには、この⽅法を⼿動で呼
び出す必要があります。このプロセスは、ピアがクラスタに加わる際にも⾃動で動作します。
ピアの設定ファイルに関する詳細は、「すべてのピアの共通設定の管理」を参照してください。このトピックに
は、すべてのピアで同⼀でなければならないファイルの詳細が記載されています。⼤部分の状況下で同⼀でなけれ
ばならない設定ファイルには、indexes.conf、props.conf、および transforms.conf があります。ご利⽤のシステムの
ニーズによっては、他の設定ファイルも同じでなければならない場合もあります。通常 App にはそのような主要
ファイルの別バージョンが含まれているため、すべてのピアに対して共通の App セットを維持管理する必要があ
ります。
すべてのピアに共通の⼀連の設定ファイル/App は、設定バンドル と呼ばれています。設定バンドルはマスター
上で管理され、単⼀の操作でピアに配布できます。設定バンドルの配布に使⽤されるプロセスは、設定バンドル⽅
法として知られています。
すべてのピア間で新しいまたは編集済み設定ファイルや App の配布を⾏うには、マスターの設定バンドルにファ
イルを追加し、マスターにピアにファイルを配布するよう指⽰します。
設定バンドルの構造
設定バンドルは、すべてのピアノードに共通な⼀連のファイルと App から成り⽴っています。
マスター上
マスター上で、設定バンドルは $SPLUNK_HOME/etc/master-apps ディレクトリに存在しています。このディレクトリ下
の⼀連のファイルが設定バンドルを構成しています。これらは常にグループとしてすべてのピアに配布されます。
ディレクトリの構造を以下に⽰します。
$SPLUNK_HOME/etc/master-apps/
_cluster/
default/
local/
<app-name>/
<app-name>/
...
以下の事項に注意してください。
ディレクトリは特別なディレクトリで、すべてのピアに配布する必要がある設定ファイル⽤のディ
レクトリです。
/_cluster/default サブディレクトリには、indexes.conf のデフォルトバージョンが保管されています。
このディレクトリには何もファイルを追加しないでください。また、このディレクトリ内のファイル
は編集しないでください。このピア固有のデフォルトの indexes.conf
は、$SPLUNK_HOME/etc/system/default 下にあるデフォルトの indexes.conf よりも優先度が⾼くなっていま
す。
/_cluster/local サブディレクトリには、ピアに配布する新しいまたは編集した設定ファイルを配置でき
ます。
5.0/5.0.1 のアップグレード： Splunk バージョン 5.0/5.0.1 では、/_cluster ディレクトリの名前が
/cluster (アンダースコアなし) になっていました。バージョン 5.0/5.0.1 のマスターノードを 5.0.2 以
降にアップグレードすると、/cluster ディレクトリの名前は⾃動的に /_cluster に変更されます。アッ
プグレードの完了後にマスターを再起動すると、マスターノードはピアノードの順次再起動を実⾏
し、名前が変更された /_cluster ディレクトリで、新しいバンドルを各ピアに配布します。すべてのピ
アノード (5.0/5.0.1 ピアも含む) の slave-apps ディレクトリに、名前の変更されたディレクトリが保
管されます。
/<app-name> サブディレクトリはオプションです。このディレクトリは、任意の App をピアノードに配布す
る⼿段を提供しています。必要に応じて作成、指定してください。たとえば、ピアノードに
「appBestEver」を配布するには、その App のコピーを独⾃のサブディレクトリ $SPLUNK_HOME/etc/masterapps/appBestEver に保管します。
master-apps ディレクトリ下のサブディレクトリの内容のみが配布されます。master-apps ディレクトリ直下に
ある単独のファイルは配布されません。たとえば、単独のファイル /master-apps/file1 が配布されることはあ
りません。そのため、単独の任意の設定ファイルは /_cluster/local サブディレクトリに保管するようにして
ください。
/_cluster
最新の設定バンドルをピアに配布する場合は、マスターにその旨を明⽰的に指⽰します。また、ピアがマスターに
登録されると (たとえば、ピアがクラスタに加わる時に)、マスターはそのピアに現在の設定バンドルを配布しま
す。
注意： マスターがピアにバンドルを配布する場合、バンドル全体が配布されるため、以前にピアに配布された設
定バンドルの内容はすべて上書きされます。
88
の場所は、ピアノードファイルのみです。マスターが⾃⼰の設定⽤にそのディレクトリ内のファイル
を使⽤することはありません。
master-apps
ピア上
ピア上で、設定バンドルは $SPLUNK_HOME/etc/slave-apps 下に保管されます。このディレクトリは、ピアを有効にし
た後、マスターから最新版のバンドルを取得した時に作成されます。最上位レベルのディレクトリ名が異なること
を除き、設定バンドルの構造と内容はマスターと同じになります。
$SPLUNK_HOME/etc/slave-apps/
_cluster/
default/
local/
<app-name>/
<app-name>/
...
重要： ダウンロードされたファイルはここにそのまま残してください。また、絶対に編集しないでください。後
ほどピアに設定ファイルや App の更新バージョンを再配布した場合、それは $SPLUNK_HOME/etc/slave-apps 内の古い
バージョンに上書きされます。これは、クラスタ内のすべてのピアが当該ディレクトリ中の同じファイルを使⽤す
る必要があるためです。
同じ理由から、ファイルやサブディレクトリを直接 $SPLUNK_HOME/etc/slave-apps に追加しないようにしてくださ
い。マスターが設定バンドルを再配布すると、ディレクトリは上書きされてしまいます。
Splunk が設定ファイルを評価する際に、$SPLUNK_HOME/etc/slave-apps/[_cluster|<app-name>]/local サブディレクトリ
内のファイルが最優先されます。設定ファイルの優先順位の詳細は、『管理』マニュアルの「設定ファイルの優先
度」を参照してください。
設定バンドルの配布
新たなまたは変更した設定ファイルと App をすべてのピアに配布するには、以下の⼿順に従ってください。
1. ファイルや App を⽤意して、それらをテストします。
2. マスターノードの設定バンドルに、ファイルと App を移動します。
3. マスターに、設定バンドルをピアに適⽤するように指⽰します。
マスターノードはバンドル全体をピアに配布します。このとき、ピアの現在のバンドルの内容が上書きされます。
1.設定バンドルのファイルと App の準備
ピアに配布するファイルに、必要な変更を⾏います。⼀連のピアに配布する前にスタンドアロンのテスト⽤インデ
クサー上でファイルのテストを⾏って、正しく機能することを確認することをお勧めします。ピアノードの負荷を
減らすために、できる限りすべてのアップデートを単⼀のバンドルにまとめるようにしてください。
ファイルの設定⽅法については、「すべてのピアの共通設定の管理」および「インデクサークラスタ内のピアイン
デックスの設定」を参照してください。
重要： 設定バンドルのサブディレクトリに新しいインデックスを定義する indexes.conf ファイルが存在する場合、
各インデックスの repFactor 属性に auto を明⽰的に設定する必要があります。この作業は、app サブディレクトリ
に存在する indexes.conf ファイル、および _cluster サブディレクトリ内のすべの indexes.conf ファイルに対して必
要です。詳細は、「indexes.conf の repFactor 属性」を参照してください。
2.マスターノードへのファイルの移動
ファイルと App の配布準備が完了したら、それらをマスター上の
$SPLUNK_HOME/etc/master-apps/
にコピーします。
App はこのディレクトリに直接保管します。例：$SPLUNK_HOME/etc/master-apps/<app-name>。
スタンドアロンファイルを $SPLUNK_HOME/etc/master-apps/_cluster/local サブディレクトリに保管します。
3.バンドルのピアへの適⽤
ピアに設定バンドルを適⽤するために、Splunk Web または CLI を使⽤することができます。
S p lu nk Web を使ったバンドルの適⽤
ピアに設定バンドルを適⽤するには、マスターノードダッシュボードに移動します。
1. Splunk Web の右上にある [設定] をクリックします。
2. [分散環境] セクションで、[インデクサークラスタリング] をクリックします。
3. ダッシュボードの右上にある [編集] ボタンをクリックして、次に [設定バンドルの配布] オプションを選択し
ます。
89
ダッシュボードに、前回成功した配布の情報が表⽰されます。また、これには [設定バンドルの配布] ボタンも表
⽰されます。
4. [設定バンドルの配布] ボタンをクリックします。
特定の状況下では、配布時にすべてのピアノードの再起動が⾏われることを警告するポップアップウィンドウが表
⽰されます。ピアの再起動が発⽣する設定の変更については、「設定バンドル変更後の再起動または再ロード」を
参照してください。
5. [変更内容を配信] をクリックして、作業を続⾏します。
画⾯に、配布の進捗状況を知らせる情報が表⽰されます。配布が完了または異常終了したら、画⾯にその結果が表
⽰されます。配布が異常終了した場合は、配布を受信できなかったピアが表⽰されます。各ピアが配布内容を正常
に受信し、適⽤できなければなりません。失敗したピアがあった場合は、そのバンドルはすべてのピアに対して適
⽤されません。
処理が正常に完了すると、新しい設定が使⽤されます。この⼀連の設定は、ローカルの
apps に保管されます。
重要： ファイルは
$SPLUNK_HOME/etc/slave-apps
$SPLUNK_HOME/etc/slave-
から移動しないでください。
配布プロセスの内部処理の詳細は、CLI を使ったバンドルの適⽤について説明している、次のセクションを参照し
てください。
CL I を使ったバンドルの適⽤
1. ピアに設定バンドルを適⽤するには、マスター上で以下の CLI コマンドを実⾏します。
splunk apply cluster-bundle
以下の警告メッセージが表⽰されます。
Warning: Under some circumstances, this command will initiate a rolling restart
of all peers. This depends on the contents of the configuration bundle. For
details, refer to the documentation. Do you wish to continue? [y/n]:
ローリング再起動が発⽣する設定の変更については、「設定バンドル変更後の再起動または再ロード」を参照して
ください。
2. 続⾏するには、メッセージに対して
ジの表⽰を省略することができます。
y
を⼊⼒します。コマンドに
--answer-yes
フラグを指定して、このメッセー
splunk apply cluster-bundle --answer-yes
コマンドを使⽤すると、マスターが新しい設定バンドルをピアに配布します。ピアは
バンドルを個別に検証します。このプロセス中、ピアがバンドル内のすべての indexes.conf ファイルの設定を検証
することです。すべてのピアがバンドルを正常に検証したら、必要に応じてマスターはすべてのピアを順番に再起
動 (ローリング再起動) するように調整します。
splunk apply cluster-bundle
⼀般的にこのダウンロードと検証プロセスは、数秒ほどで完了します。バンドルの検証に失敗したピアがある場
合、そのピアはマスターにメッセージを送信します。マスターの Splunk Web のダッシュボードにはエラーが表
⽰されます。すべてのピアのバンドルの検証が正常に完了しない限り、次のフェーズであるピアの再ロードまたは
再起動は⾏われません。
検証が成功しなかった場合、マスターが通知した問題を修正して、splunk
があります。
apply cluster-bundle
を再実⾏する必要
検証が完了すると、マスターは各ピアに再ロード、または必要に応じてすべてのピアを順次再起動 (ローリング再
起動) するように指⽰します。ローリング再起動の仕組みについては、「rolling-restart コマンドの使⽤」を参照
してください。
処理が正常に完了すると、新しい設定が使⽤されます。この⼀連の設定は、ローカルの
apps に保管されます。
重要： ファイルは
$SPLUNK_HOME/etc/slave-apps
$SPLUNK_HOME/etc/slave-
から移動しないでください。
⼀連のピアに App が配布されたら、各ピア上で Splunk Web を使って、普段通りに App を起動、管理すること
ができます。『管理』マニュアルの「App とアドオンの設定とプロパティの管理」を参照してください。
注意： apply
コマンドは、検証プロセスに問題があった場合に利⽤される、オプションフラグ -が⽤意されています。このフラグは、バンドルが有効であることを確認した上で、Splunk サポー
トの指⽰に従ってのみ使⽤する必要があります。⾃分が何をやっているのかを正しく理解していない限り、このフ
ラグを使って検証プロセスを回避しないでください。
cluster-bundle
skip-validation
CL I を使ったバンドル更新プロセスのステータスの表⽰
クラスタバンドル更新の進捗状況を表⽰するには、マスターから以下のコマンドを実⾏します。
90
splunk show cluster-bundle-status
このコマンドは、バンドルの検証が正常に完了したか、または失敗したかを表⽰します。また、各ピアの再起動ス
テータスも表⽰します。
設定バンドルを使って配布してはいけない設定
ピアの $SPLUNK_HOME/etc/slave-apps ディレクトリは読み取り専⽤になっています。新しいバンドルの配布時には毎
回ディレクトリ全体が上書きされるため、こうする必要があります。そうしないと、そのディレクトリ内の設定に
対して⾏われた変更が失われてしまいます。また、クラスタはすべてのピアの同⼀性を保つために、このディレク
トリ内の設定を利⽤しています。
そのため、ピアが⾃動的に更新する必要がある設定を、設定バンドルを使って配布した場合、ピアはそのために
$SPLUNK_HOME/etc/apps 下に新しいバージョンの App を作成します。同名の 2 つの App を保有することはできない
ため、splunkd.log には「unexpected duplicate app」エラーが記録されます。
これの⼀般的な原因は、設定バンドルを介した SSL パスワードの配布です。Splunk Enterprise は、再起動時に
パスワードを暗号形式で上書きします。しかし、設定バンドルを使って設定を配布すると、ピアは
$SPLUNK_HOME/etc/slave-apps 下にある版ジルの場所に、⾮暗号化パスワードを上書きできません。そのため、バン
ドル配布後の再起動時に、暗号化バージョンは $SPLUNK_HOME/etc/apps に、$SPLUNK_HOME/etc/slave-apps 下のバージョ
ンと同じ名前で書き込まれます。
たとえば、inputs.conf にある以下の設定は配布しないでください。
[SSL]
password = <your_password>
設定バンドル内の App ディレクトリ「newapp」に設定がある場合、ピアの再起動時に $SPLUNK_HOME/etc/apps 下
に「newapp」ディレクトリが作成され、そこに設定が保管されます。そのため、「newapp」App が重複してし
まいます。
ピア起動時のバンドルの配布
最初に Splunk インスタンスをピアノードとして設定した後は、ピアをクラスタに参加させるために⼿動で再起動
する必要があります。「ピアノードを有効にする」を参照してください。再起動時にピアはマスターと接続し、現
在の設定バンドルをダウンロードして、ローカルでバンドルを検証した後、もう⼀度再起動を⾏います。バンドル
の検証が正常に完了した場合にのみ、ピアはクラスタに参加します。このプロセスは、オフラインのピアがオンラ
インになった場合にも⾏われます。
検証が失敗した場合は、エラーを修正した後に、マスターから
ます。
splunk apply cluster-bundle
を実⾏する必要があり
設定バンドル変更後の再起動または再ロード
設定バンドル内のファイルを変更した場合、ピアの再起動が必要なことがあります。ピアを単に再ロードして、イ
ンデックス作成/サーチ処理を中断しなくて済む場合もあります。ピア上のバンドルの再読み込みフェーズでは、
再起動が必要かどうかが決定され、必要な場合にのみマスターにピアのローリング再起動が指⽰されます。
再読み込みは、以下の場合に⾏われます。
に新たなソースタイプを追加した。
内で TRANSFORMS-<class> スタンザを追加または更新した。
transforms.conf に新たなスタンザを追加した。
以下の変更は、indexes.conf 内で⾏います。
新しいインデックススタンザの追加
データのないインデックスの有効化/無効化
再起動が必要な項⽬に記載されていない属性の変更
props.conf
props.conf
再起動は、以下の場合に⾏われます。
設定バンドルに、indexes.conf、props.conf、または transforms.conf を除く設定ファイルへの変更が含まれて
いる。
前述の再読み込みリストに記載されている以外の変更を、props.conf または transforms.conf に対して⾏っ
た。
indexes.conf に対して以下のいずれかの変更を⾏った。
ボリュームの追加または削除
データのあるインデックスの有効化/無効化
インデックスの削除
以下のいずれかの属性の変更： homePath, coldPath, thawedPath, bloomHomePath, summaryHomePath,
tstatsHomePath, repFactor, rawChunkSizeBytes, minRawFileSyncSecs, syncMeta, maxConcurrentOptimizes,
coldToFrozenDir
デプロイサーバーを使ったマスターへの App の配布
デプロイサーバーを使ってピアに直接 App を配布することはできませんが、デプロイサーバーを使ってマスター
ノードの設定バンドル保管場所に App を配布することは可能です。この場所に App を保管したら、次にこのト
ピックで説明した設定バンドルを使⽤して、ピアノードに App を配布します。
91
デプロイサーバーの他に、サードパーティ製の設定配布管理ソフトウェア (Puppet や Chef など) を使⽤して、
App をマスターに配布することもできます。
デプロイサーバーを使ってマスターの設定バンドルにファイルを配布するには：
1. 『Splunk Enterprise インスタンスのアップデート』の「デプロイクライアントの設定」の説明に従って、マス
ターをデプロイサーバーのクライアントとして設定します。
2. マスターノードで、deploymentclient.conf を編集して、repositoryLocation 属性に
ます。
master-apps
の場所を設定し
[deployment-client]
serverRepositoryLocationPolicy = rejectAlways
repositoryLocation = $SPLUNK_HOME/etc/master-apps
3. デプロイサーバー上で、マスターの設定バンドルにダウンロードするデプロイ App を 1 つまたは複数作成しま
す。App が、前述の設定バンドルの構造要件を満たしていることを確認してください。デプロイ⽤ App の作成⽅
法については、『Splunk Enterprise インスタンスの更新』の「デプロイ⽤ App の作成」を参照してください。
4. マスターをデプロイ App にマップするサーバークラスを 1 つまたは複数作成します。
5. 各サーバークラスは
stateOnClient = noop
設定を含みます。
[serverClass:<serverClassName>]
stateOnClient = noop
注意： App スタンザレベルで、この設定を上書きしないでください。
6. マスターノードに App をダウンロードします。
マスターが新しいまたは更新されたデプロイ App を受信して設定バンドルに保管したら、このトピックで説明さ
れている⽅法を使ってピアにバンドルを配布することができます。
重要： デプロイ App の受信後にマスターが⾃動的に再起動しないように、適切な作業を⾏ってください。特にデ
プロイ App の動作を定義する際には、serverclass.conf の restartSplunkd 設定の値を、デフォルトの false から変
更しないでください。サーバークラスの定義にフォワーダー管理を使⽤する場合は、[App の編集] 画⾯の
[splunkd を再起動] フィールドの選択が解除されていることを確認してください。
デプロイサーバーの詳細と、必要な各種操作の実⾏⽅法については、『Splunk Enterprise インスタンスの更新』
マニュアルを参照してください。
ピア単位での設定の管理
⼤部分の設定は、すべてのピア間で同じでなければなりません。「すべてのピアの共通設定の管理」を参照してく
ださい。テスト⽤などの限定された⽬的で、ピア単位で⼀部の設定を変更することができます。
データの取り込み (データ⼊⼒) の設定
ピアへのデータの取り込みには、フォワーダーを使⽤することをお勧めします。設定プロセスの詳細は、「フォ
ワーダーを使ったインデクサークラスタへのデータの取り込み」を参照してください。
フォワーダーを利⽤せずにデータをピアに直接取り込みたい場合は、インデクサーに対して設定する場合と同じ⽅
法でピアにデータの取り込み⽅法を設定します。詳細は、『データの取り込み』マニュアルの「⼊⼒の設定」を参
照してください。
重要： データ取り込みの設定はピア単位で⾏うことができますが、すべてのピアで同じデータ取り込み設定を使
⽤できるかを検討するようにしてください。すべてのデータがフォワーダーにより中継されており、すべてのピア
の受信ポートが同じ場合は、そうすることが可能になります。そのような場合は、マスターノードで共通の
inputs.conf ファイルを管理できます。「共通のピア設定と App の更新」を参照してください。
単⼀ピアへのインデックスの追加
インデックスを単⼀のピアに追加する必要がある場合は、ピア上に個別の indexes.conf ファイルを作成します。た
だし、その新たなインデックスのデータはそのピアにのみ保管され、他のピアに複製されることはありません。こ
の⽅法は主にローカルでのテストやモニター⽬的で使⽤されます (当該ピアにのみダウンロードした特定の App
を利⽤したテストなど)。ピア固有の indexes.conf が補⾜的に使⽤されますが、すべてのピアが使⽤する共通バー
ジョンの設定に代わることはありません。
1 台のピアに対して indexes.conf のバージョンを作成する場合、それをインデクサー内で許可されている任意の場
所に配置できます。『管理』マニュアルの「設定ファイルについて」と「設定ファイルディレクトリ」を参照して
ください。このファイルを保管してはいけない場所の 1 つとして、$SPLUNK_HOME/etc/slave-apps が挙げられます。
ここには、ピアの設定バンドルが保管されています。ここにファイルを保管した場合、次回の設定バンドルのダウ
ンロード時にそのファイルが上書きされてしまいます。
重要： ローカルインデックスを追加した場合、その repFactor 属性はデフォルト値の 0 のまま使⽤してくださ
い。auto は設定しないでください。auto を設定すると、ピアはクラスタ内の他のピアへのインデックスデータの
複製を試みます。他のピアには新たなインデックスに関する設定が⾏われていないため、それらのピア上に複製
92
データの保管場所は存在せず、さまざまな問題、時には深刻な問題が発⽣してしまいます。また、次にマスターが
ピアへの設定バンドルの配布を試みる際に、不適切な設定のインデックスを持つピアがマスターにバンドル検証エ
ラーを返し、⼀連のピアに正しくバンドルを適⽤できなくなってしまいます。
その他の設定の変更
個別のピアで他の設定をピア固有の値に変更する必要がある場合、クラスタ構成かどうかにかかわらず、他の
Splunk Enterprise インスタンスと同じ⽅法でピアを設定することができます。Splunk Web や CLI を使った
り、直接設定ファイルを編集したりすることができます。
ピアの再起動
他のインデクサーと同様に、設定を変更したらピアを再起動しなければならないことがあります。ただし、⾮クラ
スタ構成のインデクサーとは異なり、ピアの再起動に CLI の splunk restart コマンドを使⽤することはできませ
ん。代わりに Splunk Web の再起動機能を使⽤してください。クラスタピアの再起動⽅法の詳細は、「単⼀ピア
の再起動」を参照してください。
再起動が必要な変更については、「server.conf 変更後の再起動」および「設定バンドル変更後の再起動または再
ロード」を参照してください。
サーチヘッドの設定
サーチヘッド設定の概要
インデクサークラスタ内のサーチヘッドの設定は、以下のカテゴリに分類できます。
クラスタノード設定。サーチヘッドノードの基本設定は、インデクサークラスタの初期デプロイ時に⾏われ
ます。後ほど設定を編集することができます。
⾼度な機能とトポロジー。マウントバンドルなどのこれらの機能は、インデクサークラスタに参加している
かどうかにかかわらず、すべてのサーチヘッドで利⽤できます。
複合サーチ。複数のクラスタにまたがって、またはクラスタ構成および⾮クラスタ構成のサーチピアにまた
がって、サーチを組み合わせて使⽤することができます。
重要： この章は、インデクサークラスタ内でノードとして動作する独⽴したサーチヘッドについて説明していき
ます。サーチヘッドクラスタ とインデクサークラスタの統合⽅法については、『分散サーチ』マニュアルの
「サーチヘッドクラスタとインデクサークラスタの統合」を参照してください。さらに、『分散サーチ』マニュア
ルの「サーチヘッドクラスタリングの設定」を参照してください。
クラスタノード設定
インデクサークラスタのサーチヘッドとしての、Splunk Enterprise インスタンスの基本設定は、インデクサーク
ラスタの初期デプロイ時に⾏われます。後ほど設定を編集することができます。
初期設定の実⾏
他のクラスタノードを有効にするのと同時に、サーチヘッドも設定して、有効にする必要があります。「サーチ
ヘッドを有効にする」を参照してください。クラスタの⼀連のピアノードは、サーチヘッドのサーチピア になり
ます。基本的な機能を利⽤する場合、他の設定を⾏う必要はありません。
設定の編集
特定のクラスタのサーチヘッド基本設定を編集する主な理由は 2 つあります。
サーチヘッドを同じクラスタの他のマスターにリダイレクトする。 マスターに障害が発⽣したけれど
も、そのクラスタにスタンバイマスターが⽤意されており、それにサーチヘッドをリダイレクトする場合な
どに役⽴ちます。スタンバイマスターの詳細は、「インデクサークラスタのマスターノードの交換」を参照
してください。
クラスタに対してサーチヘッドのセキュリティキーを変更する。 クラスタ内の他のすべてのノードで秘
密鍵を変更する場合にのみ、秘密鍵を変更してください。鍵は、クラスタ内のすべてのインスタンス間で同
じでなければなりません。
サーチヘッドのクラスタノード設定を編集するには、以下のいずれかの⽅法を利⽤します。
Splunk Web のサーチヘッドノードダッシュボードから設定を編集する。「ダッシュボードを使ったサーチ
ヘッドの設定」を参照してください。
サーチヘッドの
ください。
server.conf
ファイルを編集する。「server.conf を使ったサーチヘッドの設定」を参照して
CLI を使⽤する。「CLI を使ったサーチヘッドの設定」を参照してください。
マルチサイトサーチヘッドの設定
マルチサイトサーチヘッドを設定する場合の違いや追加作業については、「マルチサイト・インデクサー・クラス
タへのサーチアフィニティの導⼊」および「server.conf を使ったマルチサイト・インデクサー・クラスタの設
定」を参照してください。
93
⾼度な機能とトポロジー
マウントバンドルなどの、分散サーチの⾼度な機能を導⼊したい場合は、サーチヘッド上で
集する必要があります。
distsearch.conf
を編
⾼度な設定の実⾏⽅法については、『分散サーチ』マニュアルを参照してください。このドキュメントは、⾮クラ
スタ構成のインデクサー環境を中⼼にしていますが、ここに説明していることを除いては、インデクサークラスタ
での作業時にも、⼤部分の⾼度なサーチヘッド機能を同様に設定することができます。
インデクサークラスタ上で動作するサーチヘッドと⾮クラスタ構成のインデクサーに対して動作している
サーチヘッドの⽐較
⼤半の設定と機能は、インデクサークラスタ上で動作しているサーチヘッドと、⾮クラスタ構成のインデクサーに
対して動作するサーチヘッドでは同じです。
主な違いは、インデクサークラスタの場合、クラスタ有効化プロセスの⼀環として、サーチヘッドとサーチピアが
⾃動的に相互接続されることです。⾃動検出を有効にするために、distsearch.conf の設定を⾏う必要はありませ
ん。
内のいくつかの属性は、インデクサークラスタ内のサーチヘッドに対しては無効になります。イン
デクサークラスタ内のサーチヘッドでは、以下の属性が無視されます。
distsearch.conf
servers
disabled_servers
heartbeatMcastAddr
heartbeatPort
heartbeatFrequency
ttl
checkTimedOutServersFrequency
autoAddServers
⾮クラスタ構成のインデクサーに対して動作する場合のように、サーチヘッドのサーチピアへのアクセスは、公開
鍵認証により管理されます。ただし、鍵を⼿動で配布する必要はありません。インデクサークラスタ内のサーチ
ヘッドは、公開鍵を⾃動的にサーチピアに配布します。
マウントされたバンドルおよびサーチピアの設定
設定の⼤半は、サーチヘッドでのみ有効になります。ただし、マウントされたバンドルを導⼊する
には、サーチピアに distsearch.conf ファイルを配布する必要があります。インデクサークラスタの場合、マス
ターノードを使ってピアにこのファイルを配布する必要があります。マスターノードを使ったピア設定の管理⽅法
については、このマニュアルの「共通のピア設定と App の更新」を参照してください。マウントされたバンドル
の設定⽅法については、『分散サーチ』マニュアルの「ナレッジバンドルのマウント」を参照してください。
distsearch.conf
インデクサークラスタ環境での [分散サーチ] ページの機能
インデクサーのサーチヘッドの設定やピアのクラスタへの追加に、Splunk Web の [分散サーチ] ページを使⽤し
ないでください。ただし、このページからサーチピアの⼀覧を参照することは可能です。
複合サーチ
複数のインデクサークラスタにまたがってサーチを⾏う⽅法については、「複数のインデクサークラスタにまた
がったサーチ」を参照してください。
クラスタ構成および⾮クラスタ構成の両⽅のサーチピアをサーチするには、「ハイブリッドサーチの設定」を参照
してください。
ダッシュボードを使ったサーチヘッドの設定
ダッシュボードを使って、サーチヘッドノード設定を編集することができます。ダッシュボードにアクセスするに
は：
1. Splunk Web の右上にある [設定] をクリックします。
2. [分散環境] セクションで、[インデクサークラスタリング] をクリックします。
ダッシュボードには、設定に影響するさまざまなメニュー項⽬やアクションが⽤意されています。
このダッシュボードを使ったインデクサークラスタのステータスの表⽰については、「サーチヘッドダッシュボー
ドの表⽰」を参照してください。
特定のクラスタの設定の変更
特定のインデクサークラスタに対するサーチヘッドの設定を変更するには、そのクラスタの⾏にある [設定の編
集] アクションを選択します。
マスターを変更するには、[マスター URI] フィールドを編集します。
セキュリティキーを変更するには、[セキュリティキー] フィールドを編集します。
94
他のインデクサークラスタへの参加
サーチヘッドを他のクラスタに接続するには、「複数のインデクサークラスタにまたがったサーチ」を参照してく
ださい。
クラスタからのサーチヘッドの削除
インデクサークラスタからサーチヘッドを削除するには、⽬的のクラスタの⾏にある [クラスタの削除] アクショ
ンを選択します。この操作により、サーチヘッドとそのクラスタとの関係が解除されますが、他のクラスタとの接
続はそのまま維持されます (ある場合)。
すべてのクラスタからサーチヘッドを削除する場合は、ダッシュボードの右上にある [編集] メニューから [クラ
スタリングを無効にする] を選択します。
その他の編集
このインスタンスを他のノードタイプ (ピアノードなど) に変更する必要がある場合は、ダッシュボードの右上に
ある [編集] ボタンを使って変更することができます。
注意： アクティブなクラスタ内のノードの、ノードタイプを変更することはほとんどあり得ません。変更する場
合は、その結果どうなるのかを慎重に検討してください。
注意： マルチサイトクラスタの場合、[編集 ] ボタンは無効になっています。
server.conf を使ったサーチヘッドの設定
最初にお読みください：
このトピックをお読みになる前に、以下の項⽬を参照してください。
「server.conf を使ったインデクサークラスタの設定」。このトピックは、インデクサークラスタ設定の基
本を説明しています。すべてのノードタイプに共通ないくつかの問題について説明しています。
サーチヘッドを有効にする
以下の例では、サーチヘッドノードを有効にする際に設定する必要がある、基本的な項⽬を表しています。ここに
記載されている設定属性は、Splunk Web の [クラスタリングを有効にする] ページのフィールドに対応してい
ます。
[clustering]
master_uri = https://10.152.31.202:8089
mode = searchhead
pass4SymmKey = whatever
この例では、以下の事項を指定しています。
サーチヘッドのクラスタマスターの場所は
インスタンスはクラスタサーチヘッド。
セキュリティキーは「whatever」。
10.152.31.202:8089
です。
サーチヘッド設定の編集
必要に応じてこれらの設定を変更できます。たとえば、クラスタのセキュアサーバーを変更するには、各ノードの
pass4SymmKey の値を変更します。
複数のインデクサークラスタにまたがって、またはクラスタ構成および⾮クラスタ構成のサーチピアにまたがって
サーチを実⾏するように、サーチヘッドを設定することができます。以下の事項を参照してください。
複数のインデクサークラスタにまたがったサーチ
ハイブリッドサーチの設定
CLI を使ったサーチヘッドの設定
最初にお読みください：
このトピックをお読みになる前に、以下の項⽬を参照してください。
「CLI を使ったインデクサークラスタの設定と管理」を参照してください。このトピックは、CLI を使った
インデクサークラスタ設定の基本を説明しています。すべてのノードタイプに共通な、いくつかの問題につ
いて説明しています。
サーチヘッドを有効にする
以下の例では、サーチヘッドを有効にする際に通常設定する必要がある、基本的な項⽬を表しています。記載され
ている設定属性は、Splunk Web の [クラスタリングを有効にする] ページのフィールドに対応しています。
95
インスタンスをサーチヘッドとして有効にするには、mode に「searchhead」を設定します。また、master_uri も
指定する必要があります。任意で、セキュリティキー (secret) の指定が可能です。
splunk edit cluster-config -mode searchhead -master_uri https://10.160.31.200:8089 -secret your_key
splunk restart
サーチヘッド設定の編集
CLI を使って後ほど設定を編集することもできます。
重要： サーチヘッドを初めて有効にする場合、splunk edit cluster-config コマンドを使⽤します。サーチヘッド設
定を変更する場合は、splunk edit cluster-master コマンドを使⽤する必要があります。
たとえば、セキュリティキーを変更するには、以下のコマンドを使⽤します。
splunk edit cluster-master https://10.160.31.200:8089
-secret newsecret123
重要： splunk edit cluster-master コマンドは常に初期パラメータとして、現在のマスターの URI:ポート値を取り
ます。たとえば、以下のコマンドは-master_uri パラメータに新しい値を設定することで、サーチヘッドを別のマ
スターに接続します。ただし、初期パラメータとしては、古いマスターの値を提供します。
splunk edit cluster-master https://10.160.31.200:8089
-master_uri https://10.160.31.555:8089
設定可能な項⽬については、CLI のヘルプおよび server.conf 仕様ファイルを参照してください。
複数のインデクサークラスタにまたがったサーチ
サーチヘッドが、複数のインデクサークラスタに対してサーチを実⾏するように設定することができます。使⽤す
る⽅法は、単⼀サイトクラスタか、またはマルチサイトクラスタかによって異なります。
単⼀サイト・インデクサー・クラスタに対するマルチサイト・クラスタ・サーチの設定
マルチクラスタサーチを設定するには：
1. クラスタのいずれかのサーチヘッドを、「サーチヘッドを有効にする」の説明に従って設定します。
2. サーチヘッドに新しいクラスタのマスターを指⽰します。この作業は、Splunk Web、CLI、またはサーチヘッ
ドの server.conf ファイルを編集して⾏うことができます。
Splunk Web
Splunk Web では、[サーチヘッド] ダッシュボードから、複数クラスタサーチを設定することができます。
1. ダッシュボードの右上にある [サーチ対象クラスタを追加] ボタンを選択します。
2. ポップアップウィンドウ内のフィールドを記⼊します。
マスター URI ：管理ポートを含むマスターのURI を⼊⼒します。例：https://10.152.31.202:8089。
セキュリティキー ：マスター、ピア、サーチヘッド間の通信を認証するための鍵です。鍵は、クラスタ内の
すべてのインスタンス間で同じでなければなりません。マスターにセキュリティ鍵がある場合は、ここに⼊
⼒する必要があります。サーチヘッドは、各クラスタごとに個別の鍵を使⽤することができます。
クラスタからサーチヘッドを削除するには、「クラスタからのサーチヘッドの削除」を参照してください。
CLI を使⽤
CLI では、以下のコマンドを使って複数クラスタサーチを設定することができます。
splunk add cluster-master <master_uri:port>
splunk edit cluster-master <master_uri:port>
splunk remove cluster-master <master_uri:port>
splunk list cluster-master
これらのコマンドの実⾏後に、サーチヘッドを再起動する必要はありません。
たとえば、マスターが https://10.160.31.200:8089 に存在するクラスタにサーチヘッドを追加するには、以下
のコマンドを実⾏します。
splunk add cluster-master https://10.160.31.200:8089
これらのコマンドの詳細は、CLI のヘルプを参照してください。
96
server.conf を編集
複数クラスタサーチを設定するには、サーチヘッドの server.conf ファイルを編集して、master_uri 属性にマス
ターノード参照のカンマ区切りリストを指定し、その後に各マスターのスタンザを個別に指定します。例：
[clustering]
mode = searchhead
master_uri = clustermaster:east, clustermaster:west
[clustermaster:east]
master_uri=https://SplunkMaster01.example.com:8089
pass4SymmKey=someSecret
[clustermaster:west]
master_uri=https://SplunkMaster02.example.com:8089
この例でサーチヘッドは、SplunkMaster01 との通信時に pass4SymmKey 「someSecret」を使⽤しますが、
SplunkMaster02 との通信時には pass4SymmKey を使⽤しません。
server.conf
を編集したら、変更内容を反映するためにサーチヘッドを再起動する必要があります。
複数クラスタサーチの設定⽅法の詳細は、server.conf ファイルの仕様を参照してください。
マルチサイト・インデクサー・クラスタに対するマルチサイト・クラスタ・サーチの設定
サーチヘッドは、複数のマルチサイトクラスタにまたがって、または単⼀サイトクラスタとマルチサイトクラスタ
の組み合わせに対してサーチを実⾏することができます。この設定を⾏うには、マルチサイト・クラスタへの接続
時に、サーチヘッドの site 属性を指定する必要があります。
CLI を使⽤
CLI では、splunk add cluster-master コマンドを使って複数クラスタサーチを設定することができます。マルチサ
イトクラスタの追加時に、サーチヘッドの site 値を含めます。
splunk add cluster-master <master_uri:port> -site site<n>
このコマンドの実⾏後に、サーチヘッドを再起動する必要はありません。
server.conf を編集
マルチサイトクラスタのマルチサイトクラスタサーチを設定するには、マルチサイト固有の 2 つの属性 site およ
び multisite を設定する必要があります。これらの属性の場所は、いくつかの要因によって異なります。
サーチヘッドがマルチサイトクラスタのみをサーチして、サーチヘッドが各クラスタと同じサイトに存在す
る場合 、[general] スタンザの site 属性および各 [clustermaster] スタンザの multisite 属性を配置します：
[general]
site=site1
[clustering]
mode = searchhead
master_uri = clustermaster:multieast, clustermaster:multiwest
[clustermaster:multieast]
multisite=true
master_uri=https://SplunkMaster01.example.com:8089
[clustermaster:multiwest]
multisite=true
master_uri=https://SplunkMaster02.example.com:8089
サーチヘッドがマルチサイトクラスタのみをサーチして、サーチヘッドが各クラスタとは異なるサイトに存
在する場合、 [clustermaster] スタンザ下に site および multisite 属性を配置します。
[clustering]
mode = searchhead
master_uri = clustermaster:multieast, clustermaster:multiwest
[clustermaster:multieast]
multisite=true
97
master_uri=https://SplunkMaster01.example.com:8089
site=site1
[clustermaster:multiwest]
multisite=true
master_uri=https://SplunkMaster02.example.com:8089
site=site2
サーチヘッドが単⼀サイトクラスタとマルチサイトクラスタにまたがってサーチする場合 、任意のマルチサ
イトクラスタの [clustermaster] スタンザに site と multisite 属性を配置します。この例で、サーチヘッドは 2 つ
のクラスタにまたがってサーチを実⾏しますが、その中の 1 つのみがマルチサイトクラスタです。
[clustering]
mode = searchhead
master_uri = clustermaster:multi, clustermaster:single
[clustermaster:multi]
multisite=true
master_uri=https://SplunkMaster01.example.com:8089
site=site1
[clustermaster:single]
master_uri=https://SplunkMaster02.example.com:8089
server.conf
を編集したら、変更内容を反映するためにサーチヘッドを再起動する必要があります。
マルチサイトクラスタ設定の詳細は、「server.conf を使ったマルチサイト・インデクサー・クラスタの設定」を
参照してください。
ハイブリッドサーチの設定
クラスタ構成サーチピアと⾮クラスタ構成サーチピアにまたがってサーチを実⾏することができます。ハイブリッ
ドサーチを設定するには：
1. 「サーチヘッドを有効にする」の説明に従って、インデクサークラスタのサーチヘッドを設定します。
2. Splunk Web または CLI を使って、1 つまたは複数の⾮クラスタ構成サーチピアを追加します。⽅法について
は、『分散サーチ』の「サーチヘッドへのサーチピアの追加」を参照してください。
以下の事項に注意してください。
⾮クラスタ構成のサーチピアは、Splunk Web または CLI を使って指定する必要があります。認証上の問題
のため、distsearch.conf を直接編集してサーチピアを指定することはできません。Splunk Web または CLI
を使ってサーチピアを追加した場合、公開鍵資格情報の⼊⼒を要求するメッセージが表⽰されま
す。distsearch.conf を直接編集してサーチピアを指定すると、これらの資格情報を指定する⼿段がありませ
ん。公開鍵と分散サーチの詳細は、『分散サーチ』の「サーチヘッドへのサーチピアの追加」を参照してく
ださい。
ハイブリッドサーチは、サーチヘッドプーリングと互換性がありません。
インデクサーはクラスタピアまたは⾮クラスタ構成サーチピアになることができます。クラスタピアの場
合、⾃動的にそのクラスタのサーチヘッドのサーチピアになります。⾮クラスタ構成サーチピアの場合、
サーチヘッドの distsearch.conf ファイルにそのエントリが指定されます。両⽅を兼務することはできませ
ん。誤ってインデクサーをクラスタピアと⾮クラスタ構成サーチピアの両⽅として設定した場合、サーチ
ヘッドの Splunk Web の [分散サーチ] ページには、そのピアに対する 2 つのエントリが表⽰され、⽚⽅の
ステータスは「Peer member of cluster and distsearch.conf」と表⽰されます。修正するに
は、distsearch.conf でそのピアのエントリを無効にするか、または削除してください。
マルチサイト・インデクサー・クラスタのデプロイと
設定
マルチサイト・インデクサー・クラスタのデプロイの概要
このトピックをお読みになる前に、以下の項⽬を参照してください。
「インデクサークラスタのデプロイの概要」を参照してください。このトピックは、単⼀サイトクラスタ
とマルチサイト ・インデクサー・クラスタのデプロイの⼀般的な概要を説明しています。現在お読みのト
ピックは、マルチサイトの違いについてのみ説明しています。
重要： このチャプターでは、マルチサイト・インデクサー・クラスタの個別サーチヘッドをデプロイしていると
仮定します。サーチヘッドクラスタ のメンバーであるサーチヘッドの統合⽅法については、『分散サーチ』マ
ニュアルの「サーチヘッドクラスタとインデクサークラスタの統合」を参照してください。
単⼀サイトクラスタからの移⾏
98
単⼀サイトクラスタからマルチサイト・インデクサー・クラスタに移⾏する⽅法については、「単⼀サイトからマ
ルチサイトへのインデクサークラスタの移⾏」を参照してください。
マルチサイト・インデクサー・クラスタのデプロイ
マルチサイトクラスタをデプロイするには、各サイトの⼀連のノードを設定します。
単⼀のマスターがいずれかのサイトに存在し、マルチサイトクラスタ全体を管理します。
⼀連のピアノードは各サイトに配置します。
クラスタのデータをサーチするサーチヘッドは、各サイトに存在します。すべてのサーチをローカルで実⾏
する場合は、各サイトにサーチヘッドを設置する必要があります。このことは、サーチアフィニティ とし
て知られています。
たとえば、それぞれが 3 台のピアと 1 台のサーチヘッドを持つ 2 サイト構成のクラスタを設定するには、以下の
インスタンスをインストール、設定します。
サイト
サイト
サイト
サイト
サイト
1
1
2
1
2
またはサイト 2 のいずれかのサイトに 1 台のマスターノード
に 3 台のピアノード
に 3 台のピアノード
に 1 台のサーチヘッド
に 1 台のサーチヘッド
注意： マスター⾃⾝は、その物理的な場所を除いて、実際にはどのサイトのメンバーでもありません。ただし、
各マスターにはサーチヘッドが内蔵されており、そのサーチヘッドに対してマスターの設定内でサイトの属性を設
定する必要があります。マスター内蔵のサーチヘッドを使⽤しない場合でも、マスターにサイトを指定する必要が
あります。マスターのサーチヘッドはテスト⽬的でのみ⽤意されていることに注意してください。実際の運⽤環境
では使⽤しないでください。
マルチサイトノードの設定
マルチサイトクラスタノードをデプロイ、設定するには、server.conf を直接編集するか、または CLI を使⽤する
必要があります。Splunk Web を使⽤することはできません。
マルチサイト固有の設定
マルチサイトクラスタをデプロイする場合、単⼀サイトと同じ設定を⾏うほかに、⼀連のサイトと複製されたコ
ピーおよびサーチ機能コピーの場所を⽰す追加設定を⾏います。
マスター上 ：
マルチサイトのクラスタを有効にします。
クラスタの⼀連のサイトを列挙します。
マルチサイトの複製データ保持数を設定します。
マルチサイトのサーチ可能データ保持数を設定します。
各クラスタノード上 ：
ノードが存在しているサイトを指定します。
server.conf を使った設定
を使ってマルチサイトマスターノードを設定するには、「server.conf を使ったマルチサイト・インデ
クサー・クラスタの設定」を参照してください。
server.conf
CLI を使った設定
CLI を使ってマルチサイトマスターノードを設定するには、「CLI を使ったマルチサイト・インデクサー・クラ
スタの設定」を参照してください。
マルチサイトクラスタでのインデクサー検出の使⽤
インデクサー検出を使⽤してフォワーダーにピアノードと接続させる場合、各フォワーダーにサイトを割り当てる
必要があります。「マルチサイトクラスタでのインデクサー検出の使⽤」を参照してください。
マルチサイト・インデクサー・クラスタへのサーチアフィニティの導
⼊
マルチサイト・インデクサー・クラスタの利点の 1 つが、サーチヘッドがローカルサイトに保管されているデー
タからのみサーチ結果を取得するように、クラスタを設定できることです。これにより、ネットワークトラフィッ
クを削減しながら、完全なデータのセットにアクセスすることができます (各サイトがすべてのデータのコピーを
保持しているため)。この利点は、「サーチアフィニティ 」として知られています。
たとえば、カリフォルニアに 2 つのデータセンターがある場合を考えてみましょう。1 つはサンフランシスコ
に、もう 1 つはロサンゼルスにあります。各サイトがそれぞれのデータセンターに対応した、2 サイト構成のク
ラスタを設定します。サーチアフィニティにより、⻑距離のネットワークトラフィックを削減することができま
す。サンフランシスコにあるデータセンターのサーチヘッドは、サンフランシスコにあるピアからのみサーチ結果
を取得し、ロサンゼルスのサーチヘッドはそちら側のローカルピアからのみサーチ結果を取得します。
サーチアフィニティの仕組み
99
サーチアフィニティを導⼊するサイトに対して、サイトがサーチ可能データの全セットとローカルサーチヘッドを
保有するようにマルチサイトクラスタを設定します。これにより各サイトのサーチヘッドは、サイトが有効 な状
態である限り、サイトのローカルにあるデータのみを取得します。
⼀部のサーチ可能データを持つローカルピアが停⽌して、サイトが⼀時的に有効な状態ではなくなった場合、ロー
カルサイトのバケツ修復処理中にサーチヘッドは必要に応じてリモートサイトのピアにあるデータにアクセスしま
す。この間も、サーチヘッドは可能な限りローカルサイトからデータを取得しようと試みます。
サイトが有効な状態に回復したら、その後のサーチは再びローカルサイトに対してのみ⾏われます。
クラスタによるサーチアフィニティの処理⽅法の詳細は、「マルチサイト・インデクサー・クラスタのアーキテク
チャ」を参照してください。
サーチアフィニティの導⼊
マルチサイトクラスタにより、デフォルトでサーチアフィニティは有効になっています。ただし、それを有効活⽤
するには、いくつかの作業を実施する必要があります。特に、ローカルでサーチ可能データとサーチヘッドの両⽅
が利⽤できるようにする必要があります。
サーチアフィニティを導⼊するには：
1. サーチアフィニティが必要な各サイトが、最低 1 つのサーチ可能コピーを保持するように、サイトのサーチ可
能データ保持数を設定します。
そのための⽅法の 1 つとして、サーチアフィニティが必要な各サイトに対して、明⽰的にサーチ可能データ保持
数を指定することが挙げられます。たとえば、site_search_factor = origin:1, site1:1, site2:1, total:3 の 4 サイト
構成のクラスタでは、site1 と site2 が各バケツのサーチ可能コピーを保有します。3 番⽬のサーチ可能コピー
セットは、2 つの⾮明⽰サイトに分散されます。どちらかのサイトが、完全なサーチ可能コピーのセットを保有す
る保証ありません。そのため、サーチアフィニティは site1 と site2 でのみ有効になります。site1 と site2 はそ
れぞれすべてのバケツのプライマリコピーをもっています。
⼀部または全部を明⽰的に指定せずに、すべてのサイトがサーチ可能コピーを保持するように、サイトのサーチ可
能データ保持数を設定する⽅法もあります。たとえば、site_search_factor = origin:1, total:3 の 3 サイト構成の
クラスタの場合、サイトあたり 1 つのサーチ可能コピーが保証され、各サイトでサーチアフィニティが有効にな
ります。各サイトにはすべてバケツのプライマリコピーがあります。
複製データ保持数とサーチ可能データ保持数によるサイトへのコピーの配布については、「サイトの複製データ保
持数の設定」および「サイトのサーチ可能データ保持数の設定」を参照してください。
2. サーチアフィニティが必要な各サイトにサーチヘッドをデプロイします。
サーチアフィニティの無効化
サーチアフィニティはサーチヘッドで無効にできます。サーチアフィニティが無効になっていると、サーチヘッド
は結果の⼊⼿を単⼀のサイトに限らずに試みます。そして、複数のサイトから結果を得られます。例えば、待ち時
間の少ない近場にデータセンターが 2 箇所あり、インデクサーの処理を両⽅のサイトに分散して全体のパフォー
マンスを改善したいときに役⽴ちます。
サーチアフィニティが無効になっていると何が起きるか
サーチヘッドのサーチアフィニティが無効になっていると、あらゆるサイトのインデクサーからサーチ結果が届き
ます。サイトのサーチ可能データ保持数がマルチサイトでのサーチ可能なバケツコピーの数量を決める場合、サー
チヘッドは定義されていない条件を使⽤してどのサーチ可能なコピーをサーチするか選択します。あるサイトから
バケツのコピーを、そして他のサイトの他のバケツコピーを選択する場合、結果はマルチサイトから届きます。
サーチヘッドは常にプライマリバケツコピーから選択します。例えば、サーチ可能データ保持数と 2 つのサイト
クラスタがあるとしましょう。
site_search_factor = origin:2, total:3
元のサイトは 2 つのサーチ可能なコピーを保管し、2 つ⽬のサイトは各バケツのサーチ可能なコピーを保管しま
す。そのため、いくつかのバケツ (site1 で⽣成されたバケツ) については、site1 が 2 つのサーチ可能なコピーを
有し、他のバケツ (site2 で⽣成されたバケツ) については、site2 が2 つのサーチ可能なコピーを有します。しか
し、各サイトでは、単⼀のプライマリコピーしか持てません。
サーチアフィニティのあるサーチヘッドは、可能な場合、サーチヘッドのあるサイトでプライマリコピーにサーチ
の制限をかけます。
対照的に、サーチアフィニティのあるサーチヘッドは両サイトでのプライマリコピーでサーチの配布を無効にしま
す。これらのバケツについては、site1 のプライマリと site2 のプライマリどちらを選択するかわかりません。前
回のサーチと同じプライマリを使⽤する傾向があります。
サーチアフィニティの無効化⽅法
サーチアフィニティを無効にするには、server.conf でサーチヘッドのサイト値を「site0」に設定します。
[general]
site = site0
100
[clustering]
multisite = true
...
site=site0
の設定により、サイトの特定はせず、サーチが単⼀のサイトクラスタにあるかのように動作させられま
す。
マルチサイトサーチヘッドの設定詳細については、「サーチヘッドの設定」を参照してください。
server.conf を使ったマルチサイト・インデクサー・クラスタの設定
最初にお読みください：
このトピックをお読みになる前に、以下の項⽬を参照してください。
「マルチサイト・インデクサー・クラスタのデプロイの概要」。このトピックには、マルチサイトクラスタ
の設定に関する重要な背景情報が記載されています。
「server.conf を使ったインデクサークラスタの設定」。このトピックは、クラスタ設定の基本を説明して
います。単⼀サイトクラスタに重点を置いていますが、⼤部分の情報はマルチサイトクラスタにも関連して
います。
マルチサイト設定と単⼀サイト設定の違い
マルチサイト・インデクサー・クラスタは単⼀サイトクラスタと同じように設定しますが、いくつかの新たな属性
も設定しなければならない点が異なっています。
すべてのマルチサイトクラスタノード (マスター/ピア/サーチヘッド) 上：
site
属性は、ノードが存在しているサイトを⽰します。
マスターノードとサーチヘッド上：
multisite
属性は、マスターまたはサーチヘッドがマルチサイトクラスタに参加していることを⽰します。
マスターノードのみ：
available_sites
属性は、マスターが管理しているサイトを⽰します。
site_replication_factor は、単⼀サイトクラスタで使われている標準の replication_factor
に代わるもので
す。詳細は、「サイトの複製データ保持数の設定」を参照してください。
site_search_factor は、単⼀サイトクラスタで使われている標準の search_factor に代わるものです。詳細
は、「サイトのサーチ可能データ保持数の設定」を参照してください。
重要： 単⼀サイトクラスタからマルチサイトクラスタにクラスタを移⾏する場合、既存の単⼀サイトバケツの
replication_factor および search_factor 属性を保持しながら、新たなマルチサイトバケツ⽤にマルチサイトの
site_replication_factor および site_search_factor 属性を追加する必要があります。「単⼀サイトからマルチサイト
へのインデクサークラスタの移⾏」を参照してください。
マルチサイトクラスタノードの設定
マルチサイトクラスタを設定するには、各ノードの server.conf ファイルを編集して、各サイトのノードを設定し
ます。クラスタ属性の詳細は、server.conf の仕様を参照してください。
site の値
site の値は、ノードが存在するサイトを⽰します。マルチサイトクラスタ内の各ノードに、site の値を割り当てま
す。そのためには、[general] スタンザの site 属性を設定します。
site 値の構⽂を以下に⽰します。
site<n>
ここで <n> は 1〜63 の範囲の整数です。site1、site2、site3... のようになります。
例：
site=site1
注意： サーチヘッドの場合、サイト値を「site0」に設定できます。この設定で、サーチヘッドのサーチアフィニ
ティ は無効化されます。
マスターノードの設定
マスターノード上で、クラスタ全体の主要属性を設定します。マスターノードのマルチサイト設定例を以下に⽰し
ます。
101
[general]
site = site1
[clustering]
mode = master
multisite = true
available_sites = site1,site2
site_replication_factor = origin:2,total:3
site_search_factor = origin:1,total:2
pass4SymmKey = whatever
cluster_label = cluster1
この例では、以下の事項を指定しています。
インスタンスは site1 に存在している。
インスタンスはクラスタマスターノード。
クラスタはマルチサイト。
クラスタは site1 と site2 の 2 サイト構成。
クラスタの複製データ保持数はデフォルトの「origin:2,total:3」。
クラスタのサーチ可能データ保持数はデフォルトの「origin:1,total:2」。
クラスタのセキュリティキーは「whatever」。
クラスタラベルは、「cluster1」です。
以下の事項に注意してください。
属性は [general] スタンザに指定します。その他のマルチサイト属性はすべて、[clustering] スタンザに
指定します。
マスターはクラスタ内の任意のサイトに配置できますが、各クラスタは 1 つのマスターのみを保有できま
す。
multisite=true を設定する必要があります。
available_sites 属性に、すべてのクラスタサイトを記載する必要があります。
site_replication_factor と site_search_factor を設定する必要があります。詳細は、「サイトの複製データ保
持数の設定」および「サイトのサーチ可能データ保持数の設定」を参照してください。
セキュリティキーを設定する pass4SymmKey の指定は省略することもできます。詳細は、「server.conf を使っ
たインデクサークラスタの設定」を参照してください。
クラスタラベルは任意です。ラベルは分散管理コンソール内のクラスタ特定に役⽴ちます。『分散管理コン
ソール』マニュアルの「クラスタラベルの設定」を参照してください。
site
重要： マスターを初めて起動した場合、複製データ保持数と同じ数のピアを完全に有効にして再起動するまで
は、ピアにおけるインデックス作成がマスターによりブロックされます。たとえば、「site_replication_factor =
origin:2, site1:1, site2:2, site3:3, total:8」の 3 サイト構成のクラスタを考えてみましょう。この場合、すべての
サイトにまたがって合計 8 台以上のピアが存在するようになるまで (内訳として site1 に 1 台以上、site2 に 2 台
以上、site3 に 3 台以上)、マスターはインデックスの作成をブロックします。
マスターがクラスタへのピア参加待ちの場合は、マスターを再起動しないでください。再起動すると、ピアをもう
⼀度再起動する必要があります。
ピアノードの設定
マルチサイトクラスタでピアを設定するには、[general] スタンザに
は、単⼀サイトクラスタのピアと同じです。
site
属性を設定します。他のすべての設定
マルチサイトピアノードの設定例を以下に⽰します。
[general]
site = site1
[replication_port://9887]
[clustering]
master_uri = https://10.152.31.202:8089
mode = slave
pass4SymmKey = whatever
この例では、以下の事項を指定しています。
インスタンスは site1 に存在している。ピアは 1 つのサイトにのみ所属できます。
ピアはポート 9887 で他のピアから転送される複製データを待機。利⽤可能な任意の未使⽤ポートを複製
ポートとして指定することができます。管理⽤または受信⽤ポートを再利⽤しないでください。
ピアのクラスタマスターの場所は 10.152.31.202:8089。
インスタンスはクラスタピア (スレーブ) ノード。
セキュリティキーは「whatever」。
サーチヘッドの設定
マルチサイトのサーチヘッドは、サーチアフィニティを提供します。詳細は、「マルチサイト・インデクサー・ク
ラスタへのサーチアフィニティの導⼊」を参照してください。
102
マルチサイトクラスタでサーチヘッドを設定するには、[general] スタンザに site 属性を、[clustering] スタンザ
に multisite 属性を設定します。他のすべての設定は、単⼀サイトクラスタのサーチヘッドと同じです。マルチサ
イトサーチヘッドノードの設定例を以下に⽰します。
[general]
site = site1
[clustering]
multisite = true
master_uri = https://10.152.31.202:8089
mode = searchhead
pass4SymmKey = whatever
この例では、以下の事項を指定しています。
インスタンスは site1 に存在している。サーチヘッドはマスターあたり 1 つのサイトにのみ所属できます。
サーチヘッドはマルチサイトクラスタのメンバー。
サーチヘッドのクラスタマスターの場所は 10.152.31.202:8089。
インスタンスはクラスタサーチヘッド。
セキュリティキーは「whatever」。
サーチヘッドのサーチアフィニティを無効化するには、site 属性を「site0」に設定し、クラスタのサイトすべて
からデータをランダムに⼊⼿します。
注意： server.conf を使ってマルチサイトクラスタサーチを有効にすることもできます。この場合、サーチヘッド
は複数のクラスタ (マルチサイトまたは単⼀サイト) にまたがってサーチを⾏います。複数のマルチサイトクラス
タにまたがってサーチを⾏う場合、サーチヘッドを各クラスタの異なるサイトのメンバーとして設定することがで
きます。詳細は、「マルチサイトクラスタのマルチサイトクラスタサーチの設定」を参照してください。
稼働しているサーチヘッドを再設定する場合は、server.conf を直接編集するのではなく、「CLI を使ったマルチ
サイト・インデクサー・クラスタの設定」で説明しているように、CLI コマンドを使⽤することをお勧めします。
CLI を使⽤すれば、サーチヘッドを再起動する必要はありません。
クラスタノードの再起動
初期設定後
インスタンスをマルチサイトクラスタノードとして設定したら、変更内容を有効にするためにそれらすべて (マス
ター、ピア、およびサーチヘッド) を再起動する必要があります。このためには、各ノードで CLI の restart コマ
ンドを実⾏します。
$SPLUNK_HOME/bin/splunk restart
重要： マスターを初めて起動した場合、複製データ保持数と同じ数のピアを完全に有効にして再起動するまで
は、ピアにおけるインデックス作成がマスターによりブロックされます。たとえば、「site_replication_factor =
origin:2, site1:1, site2:2, site3:3, total:8」の 3 サイト構成のクラスタを考えてみましょう。この場合、すべての
サイトにまたがって合計 8 台以上のピアが存在するようになるまで (内訳として site1 に 1 台以上、site2 に 2 台
以上、site3 に 3 台以上)、マスターはインデックスの作成をブロックします。
マスターがクラスタへのピア参加待ちの場合は、マスターを再起動しないでください。再起動すると、ピアをもう
⼀度再起動する必要があります。
設定の変更後
マスター上
以下の属性を変更したら、マスターを再起動する必要があります。
multisite
available_sites
site_replication_factor
site_search_factor
マスターを再起動したら、クラスタピアも順番に再起動 (ローリング再起動) する必要があります。そうしない
と、クラスタは不確定状態になってしまいます。splunk rolling-restart コマンドの詳細は、「rolling-restart コマ
ンドの使⽤」を参照してください。
マスター上で
site
を変更した場合、再起動する必要はありません。
ピア上
ピア上で
site
の値を変更したら、変更内容を反映するためにピアを再起動する必要があります。
重要： 最初にインスタンスをクラスタピアノードとして有効にするためには、CLI の restart コマンドを使⽤する
ことができますが、それ以降の再起動には、このコマンドを使⽤しないでください。いったんインデックスレプリ
103
ケーションが開始されると、restart コマンドはレプリケーションとの互換性がありません。安全な再起動⽅法な
ど、その他の情報については、「単⼀ピアの再起動」を参照してください。
サーチヘッド上
サーチヘッド上で
site
を変更した場合、再起動する必要はありません。
CLI を使ったマルチサイト・インデクサー・クラスタの設定
最初にお読みください：
このトピックをお読みになる前に、以下の項⽬を参照してください。
「マルチサイト・インデクサー・クラスタのデプロイの概要」。このトピックには、マルチサイトクラスタ
の設定に関する重要な背景情報が記載されています。
「CLI を使ったインデクサークラスタの設定と管理」。このトピックは、クラスタを設定するための基本的
な CLI の使⽤⽅法を説明しています。単⼀サイトクラスタに重点を置いていますが、⼤部分の情報はマルチ
サイトクラスタにも関連しています。
「server.conf を使ったマルチサイト・インデクサー・クラスタの設定」。このトピックには、現在のト
ピックで取り上げられているコマンドラインオプションに対応する属性の詳細などを含め、マルチサイトク
ラスタの設定に役⽴つ情報が記載されています。
マルチサイトクラスタノードの設定
コマンドを使って、インスタンスをマルチサイトクラスタノードとして設定します。イ
ンスタンスを有効にしたら、再起動する必要があります。
splunk edit cluster-config
site の値
site の値は、ノードが存在するサイトを⽰します。マルチサイトクラスタ内の各ノードに、site の値を割り当てま
す。
site 値の構⽂を以下に⽰します。
site<n>
ここで <n> は 1〜63 の範囲の整数です。site1、site2、site3... のようになります。
注意： サーチヘッドの場合、サイト値を「site0」に設定できます。この設定で、サーチヘッドのサーチアフィニ
ティ は無効化されます。
マスターノードの設定
マスターノードのマルチサイト設定例を以下に⽰します。
splunk edit cluster-config -mode master -multisite true -available_sites site1,site2 -site site1 site_replication_factor origin:2,total:3 -site_search_factor origin:1,total:2
splunk restart
この例では、以下の事項を指定しています。
インスタンスはクラスタ・マスター・ノード。
クラスタはマルチサイト。
クラスタは site1 と site2 の 2 サイト構成。
マスターは site1 に存在している。
クラスタの複製データ保持数はデフォルトの「origin:2,total:3」。
クラスタのサーチ可能データ保持数はデフォルトの「origin:1,total:2」。
以下の事項に注意してください。
各クラスタには、マスターが 1 つのみ存在しています。
マルチサイトクラスタマスターに対して、multisite に true を設定する必要があります。
available_sites 属性で、すべてのクラスタサイトを記載する必要があります。
site_replication_factor と site_search_factor を設定する必要があります。詳細は、「サイトの複製データ保
持数の設定」および「サイトのサーチ可能データ保持数の設定」を参照してください。
重要： マスターを初めて起動した場合、複製データ保持数と同じ数のピアを完全に有効にして再起動するまで
は、ピアにおけるインデックス作成がマスターによりブロックされます。たとえば、「site_replication_factor =
origin:2, site1:1, site2:2, site3:3, total:8」の 3 サイト構成のクラスタを考えてみましょう。この場合、すべての
サイトにまたがって合計 8 台以上のピアが存在するようになるまで (内訳として site1 に 1 台以上、site2 に 2 台
以上、site3 に 3 台以上)、マスターはインデックスの作成をブロックします。
マスターがクラスタへのピア参加待ちの場合は、マスターを再起動しないでください。再起動すると、ピアをもう
⼀度再起動する必要があります。
104
注意： 後ほど
の値を変更した場合、マスターを再起動する必要はありません。
site
ピアノードの設定
マルチサイトクラスタでピアノードを設定するには、site 属性を設定します。他のすべての設定は、単⼀サイトク
ラスタのピアと同じです。
マルチサイトピアノードの設定例を以下に⽰します。
splunk edit cluster-config -mode slave -site site1 -master_uri https://10.160.31.200:8089 -replication_port 9887
splunk restart
この例では、以下の事項を指定しています。
インスタンスはクラスタピア (スレーブ) ノード。
インスタンスは site1 に存在している。ピアは 1 つのサイトにのみ所属できます。
ピアのクラスタマスターの場所は 10.160.31.200:8089。
ピアはポート 9887 で他のピアから転送される複製データを待機。利⽤可能な任意の未使⽤ポートを複製
ポートとして指定することができます。管理⽤または受信⽤ポートを再利⽤しないでください。
注意： 後ほど
site
の値を変更した場合、ピアを再起動する必要はありません。
サーチヘッドの設定
マルチサイトクラスタでサーチヘッドを設定するには、site パラメータを設定します。他のすべての設定は、単⼀
サイトクラスタのサーチヘッドと同じです。
サーチヘッドを最初に設定するのと、後ほどその設定を変更するのとでは、違うコマンドを使⽤します。
サーチヘッドを初期設定するには：
splunk edit cluster-config
コマンドを使⽤します。マルチサイトサーチヘッドの設定例を以下に⽰します。
splunk edit cluster-config -mode searchhead -site site1 -master_uri https://10.160.31.200:8089
splunk restart
この例では、以下の事項を指定しています。
インスタンスはクラスタサーチヘッド。
サーチヘッドは site1 に存在している。サーチヘッドは、各クラスタ内の 1 つのサイトにのみ所属します。
サーチヘッドのクラスタマスターの場所は 10.160.31.200:8089。
サーチヘッドのサーチアフィニティを無効化するには、site 属性を「site0」に設定し、クラスタのサイトすべて
からデータをランダムに⼊⼿します。
注意： site パラメータを指定する場合、サーチヘッドの server.conf ファイルに
れます。明⽰的に multisite パラメータを渡す必要はありません。
multisite=true
が⾃動的に設定さ
後ほどサーチヘッドの設定を編集するには：
splunk edit cluster-config
たとえば、最初に
みましょう。
コマンドではなく、splunk
splunk edit cluster-config
edit cluster-master
コマンドを使⽤します。
コマンドを使って単⼀サイトのサーチヘッドを設定した場合を考えて
splunk edit cluster-config -mode searchhead -master_uri https://10.160.31.200:8089
splunk restart
このサーチヘッドをマルチサイトクラスタ⽤に再設定するには、splunk
す。
splunk edit cluster-master https://10.160.31.200:8089
edit cluster-master
コマンドを使⽤しま
-site site1
重要： splunk edit cluster-master コマンドは常に初期パラメータとして、現在のマスターの URI:ポート値を取り
ます。その他の例については、「CLI を使ったインデクサークラスタのサーチヘッドの設定」を参照してくださ
い。
マルチサイトクラスタサーチ⽤のマルチサイトサーチヘッドの設定については、「マルチサイトクラスタのマルチ
クラスタサーチの設定」を参照してください。
注意： 後ほど
site
の値を変更した場合は、サーチヘッドを再起動する必要はありません。
105
サイトの複製データ保持数の設定
最初にお読みください：
サイトの複製データ保持数を設定する前に、以下の事項を理解しておく必要があります。
基本的な単⼀サイトの複製データ保持数。「インデクサー・クラスタ・アーキテクチャの基礎」および「複
製データ保持数」を参照してください。
マルチサイトクラスタの設定。「server.conf を使ったマルチサイト・インデクサー・クラスタの設定」を
参照してください。
サイトの複製データ保持数とは
マルチサイト・インデクサー・クラスタを導⼊するためには、サイトの複製データ保持数を設定する必要がありま
す。これは単⼀サイトデプロイ環境に固有の、標準の複製データ保持数に代わるものです。サイトの複製データ保
持数は、クラスタの基本設定の⼀環としてマスターノードに指定します。
サイトの複製データ保持数は、クラスタ全体のバケツコピー数合計を制御するだけでなく、サイトレベルでのバケ
ツコピーの場所を制御することができます。たとえば、2 サイト構成のクラスタで、⽚⽅のサイトで 2 つのコ
ピーを保持し、もう⼀⽅のサイトで 1 つのコピーを保持して、すべてのバケツのコピーを合計で 3 つ保持するよ
うに設定することができます。
また、バケツの起源となるオリジナルのサイトに基づいて、複製ポリシーを指定することもできます。この場合、
外部データを取り込んだサイトで、⾃⼰のサイトで取り込んだのではないデータのバケツコピー数よりも、⾃⼰が
取り込んだデータのバケツコピー数を多く保持するように、複製データ保持数を設定することができます。たとえ
ば、各サイトで⾃⼰が取り込んだすべてのデータのコピーを 2 つ保持するけれども、他のサイトが取り込んだ
データのコピーは 1 つのみ保持するように設定することができます。
構⽂
サイトの複製データ保持数は、マスターの server.conf ファイルの site_replication_factor 属性で設定します。こ
の属性は、単⼀サイトの replication_factor 属性の代わりに、[clustering] スタンザに存在しています。例：
[clustering]
mode = master
multisite=true
available_sites=site1,site2
site_replication_factor = origin:2,total:3
site_search_factor = origin:1,total:2
CLI を使ってサイトの複製データ保持数を設定することもできます。「CLI を使ったマルチサイト・インデク
サー・クラスタの設定」を参照してください。
警告： site_replication_factor 属性は正確に指定する必要があります。そうしないと、マスターは開始されませ
ん。
正式な構⽂を以下に⽰します。
site_replication_factor = origin:<n>, [site1:<n>,] [site2:<n>,] ..., total:<n>
ここで：
は、バケツのコピー数を⽰す正の整数です。
は、データを取り込んだサイト (データが最初にクラスタに⼊ってきたサイト) がそのバケツのコ
ピーを保持する最低数を⽰します。データを取り込んだサイトは、「オリジン」サイトと呼ばれています。
site1:<n>, site2:<n>, ..., は、指定された各サイトが保持する最低コピー数を⽰します。識別⼦「site1」、
「site2」などは、ピアノードに指定する site 属性値と同じです。
total:<n> は、クラスタ内のすべてのサイトにまたがる、各バケツの合計コピー数を⽰します。
<n>
origin:<n>
以下の事項に注意してください。
この属性は、サイトあたりの複製ポリシーを⽰しています。これはグローバルな設定で、すべてのインデッ
クス内のすべてのバケツに適⽤されます。
この属性は mode=master および multisite=true の場合にのみ有効です。これらの条件を満たしている場合、ど
の replication_factor 属性にも優先されます。
origin
および
total
の値が必要です。
サイト値 (site1:<n>, site2:<n>, ...) は省略可能です。ここに指定されたサイトは「明⽰」サイトと呼ばれま
す。ここに指定されないサイトは「⾮明⽰」サイトと呼ばれます。
クラスタが、サイトが取得する最低コピー数を判断する⽅法を以下に⽰します。
サイトがオリジンの場合、そのサイトが取得する最低コピー数は、site 値 (ある場合) または
りも多くなります。
106
origin
よ
サイトがオリジンでない場合、site 値 (ある場合) がそのサイトが取得する最低コピー数を決定しま
す。
⾮明⽰サイトはそれがオリジンである場合を除いて、コピー数が保証されることはありません。
たとえば、「site_replication_factor = origin:2, site1:1, site2:2, site3:3, total:8」の 4 サイトクラスタの
場合、site1 は⾃⼰が取り込んだデータのコピーを 2 つ、他のサイトが取り込んだデータのコピーを 1 つ保
持します。site2 は、⾃⼰が取り込んだデータかどうかに関係なく、2 つのデータコピーを保持します。
site3 は、⾃⼰が取り込んだデータかどうかに関係なく、3 つのデータコピーを保持します。⾮明⽰サイト
の site4 は、⾃⼰が取り込んだデータのコピーを 2 つ、site2 または site3 が取り込んだデータのコピーを
2 つ、site1 が取り込んだデータのコピーを 1 つ保持します。(site4 は、各バケツのコピー数が total の値
8 を満たすために必要な数のコピーを取得します。)データのオリジンに応じた、site4 のコピー数の計算⽅
法を以下に⽰します。
originate at site1 -> 2 copies in site1, 2 copies in site2, 3 copies in site3, 1 copy in site4 => total=8
originate at site2 -> 1 copy in site1, 2 copies in site2, 3 copies in site3, 2 copies in site4 => total=8
originate at site3 -> 1 copy in site1, 2 copies in site2, 3 copies in site3, 2 copies in site4 => total=8
originate at site4 -> 1 copy in site1, 2 copies in site2, 3 copies in site3, 2 copies in site4 => total=8
site_replication_factor
を指定する場合、これが site と
origin
に基づく
total
に最低限必要な値の決定⽅法
です。
⾮明⽰サイトがある場合、total の値は最低でも すべての明⽰サイトと
なりません。
origin
の値の合計でなければ
たとえば、「site_replication_factor = origin:2, site1:1, site2:2」の 3 サイト・クラスタの場
合、total は最低でも 5 にする必要があります (2+1+2=5)。「site_replication_factor = origin:2,
site1:1, site3:3」の 3 サイト・クラスタの場合、total は最低でも 6 にする必要があります
(2+1+3=6)。
すべてのサイトが明⽰サイトの場合、total は site と
する必要があります。
origin
の値を満たすために必要な最低値以上に
たとえば、「site_replication_factor = origin:1, site1:1, site2:1, site3:1」の 3 サイトクラスタの場
合、total は最低 3 になります (この設定では、3 つより多くのコピーは不要なため)。
「site_replication_factor = origin:2, site1:1, site2:1, site3:1」の 3 サイトクラスタの場合、いずれ
かのサイトが常にオリジンとなり、他の各サイトは 1 つのみコピー必要だけれども、オリジンは 2 つ
のコピーが必要になるため、total は最低でも 4 になります。「site_replication_factor = origin:3,
site1:1, site2:2", site3:3」の 3 サイトクラスタの場合、total は最低 8 になります (site1 がオリジン
になる場合を想定して)。
この値を決定するためのもっとも簡単な⽅法は、最⼩の site 値の代わりに origin の値を使⽤して、
site の値を合計する (代⽤する origin の値も含めて) ことです。最後の例の場合
("site_replication_factor = origin:3, site1:1, site2:2", site3:3")、site1 がもっとも⼩さな値 (1) を
持っています。この場合、その 1 の代わりに origin の値 3 を使⽤して、それに site2 と site3 の値を
加算します (3+2+3=8)。
の値が、明⽰値の合計より⼤きくなる可能性があるため、クラスタには「残りの」バケツコピーを取り
扱うための⽅針が必要となります。以下に⽅針を⽰します。
total
すべての site および origin の値を満たした後に、割り当てるコピーが残っている場合、それらの残り
のコピーをすべてのサイトにまたがって分散します。このとき、コピー数が少ないまたはコピーがな
いサイトを優先し、できる限り均等に分散します。利⽤可能な残りコピー数が⼗分にある場合、各サ
イトは最低 1 つのコピーを持ちます。
たとえば、「site_replication_factor = origin:1, site1:1, site4:2, total:4」の 4 サイトクラスタで、
site1 がオリジンの場合、残り 1 つのコピーが存在します。このコピーは、site2 または site3 に、無
作為に分散 (配布) されます。しかし、site2 がオリジンの場合、それが 1 つのコピーを保持し、site3
に分散する残りコピーはありません。
他の例として、「site_replication_factor = origin:2, site1:2, site4:2, total:7」の 4 サイトクラスタ
で、site1 がオリジンの場合、分散する残り 3 つのコピーが存在します。site2 と site3 に明⽰的に割
り当てられているコピーはないため、3 つのコピーはこれらに分散され、各サイトが最低 1 つのコ
ピーを保有することになります。ただし、site2 がオリジンの場合、それが 2 つのコピーを取得し、
site3 が残り 1 つのコピーを保持することになります。
このプロセスの全体は、各サイトで⼗分な数のピアが利⽤できるかどうかによって異なります。サイ
トに余分なコピーを受け取るのに⼗分な数のピアがない場合、それらのコピーはピアに余⼒があるサ
イトに移動されます。どのような場合でも、各サイトに対して最低 1 つのコピーが配布/保持されます
(⼗分な数のコピーが利⽤可能なことが前提)。
他にもいくつかの例を以下に⽰します。
「origin:1, total:3」の 3 つのサイトクラスタ：配布はサイトごとにコピー 1 つのみ保証しま
す。
「origin:1, total:4」の 3 つのサイトクラスタ：分散により、サイトあたり 1 つのコピーが保証
されます。もう 1 つのコピーは、最低 2 台のピアを持つサイトに配布されます。
「origin:1, total:9」の 3 つのサイトクラスタ：site1 はピアを 1 つのみ、site2 と site3 はそれ
ぞれピアを 10 有している場合、配布はサイトごとにコピー 1 つのみ保証し、残り 6 の残コピー
107
は site2 と site3 の間で均等に配布します。
ある⾮明⽰サイトですべてのピアが停⽌して、他の⾮明⽰サイトにコピーを渡した後も残りのコピー
がある場合、クラスタはそのサイト⽤に残りのコピーのいずれかを保持し、そのピアの復旧を待ちま
す。その間 site_replication_factor を満たすことはできません。停⽌したピアを持つサイト⽤に保持さ
れているコピーのために、分散されるコピー数は指定されている total の値よりも 1 つ少なくなって
います。
たとえば、「site_replication_factor = origin:1, site1:1, site4:2, total:5」の 4 サイトクラスタで、
site1 がオリジンの場合、site2 と site3 に残りの 2 つのコピーが分散されます。site2 のすべてのピ
アが停⽌した場合、残りのコピーの 1 つは site3 に配布され、その他のコピーは site2 のピアがクラ
スタに復帰するまでの間、予備として保持されます。その間、site_replication_factor は満たされませ
ん。ただし、「site_replication_factor = origin:1, site1:1, site4:2, total:4」の 4 サイトクラスタの場
合 (前の例との唯⼀の違いは、total の値が 5 ではなく 4 になっている)、site1 がオリジンならば残り
のコピーは 1 つになり、site2 または site3 に配布されます。site2 のすべてのピアが停⽌した場合、
そのコピーは site3 に移動して、site2 ⽤の予備的コピーは保持されません。この例では site2 ⽤の予
備コピーは保持されないため、 site_replication_factor を満たしています。
各サイトには、origin の値またはその site の値よりも多い数の、⼀連のピアをデプロイする必要がありま
す。
たとえば、「site_replication_factor = origin:2, site1:1, site2:2, site3:3, total:8」の 3 サイトクラスタの
場合、サイトには最低でも次の数のピアが必要です。site1：2 peers; site2: 2 peers; site3: 3 peers。
すべてのサイトにまたがってデプロイするピア数の合計は、total の値以上でなければなりません。
値は、デフォルト値として 3 が設定されている replication_factor 属性より⼤きい数値でなければいけ
ません。そのため、total 値が 2 の場合、replication_factor を 2 に設定する必要があります。
total
単⼀サイトクラスタから移⾏する場合、total の値は最低でも単⼀サイトクラスタの replication_factor の値
と同じ⼤きさでなければなりません。「単⼀サイトからマルチサイトへのインデクサークラスタの移⾏」を
参照してください。
属性のデフォルトは「origin:2, total:3」です。
例
デフォルト値「site_replication_factor = origin:2, total:3」のサイト 2 箇所 (site1, site2) のク
ラスタ： バケツについては、データを⽣成するサイトはコピーを 2 つ保存します。残りのサイトは 1 つの
コピーを保管します。
デフォルト値「site_replication_factor = origin:2, total:3」のサイト 3 箇所 (site1, site2,
site3) のクラスタ： バケツについては、データを⽣成するサイトはコピーを 2 つ保存します。2 つの⾮オ
リジンサイトから無作為に選択されるいずれかのサイトが、1 つのコピーを保管し、もう⼀⽅のサイトはコ
ピーを保管しません。
「site_replication_factor = origin:1, site1:1, site2:1, site3:2, total:5」のサイト 3 箇所
(site1, site2, site3) のクラスタ： バケツはすべて、site1 と site2 がそれぞれ最低 1 つ、site3 が 2 つ
コピーを保存します。5 番⽬のコピーは site1 または site2 に配布されます (これらのサイトに割り当てられ
ているコピーが site3 よりも少ないため)。
「site_replication_factor = origin:2, site1:1, site2:1, total:4 」の サイト 3 箇所 (site1, site2,
site3) のクラスタ： site1 がデータを⽣成するバケツを 2 つ、そしてそれ以外の他のバケツは 1 つコピー
を保存します。site2 も同じパターンに従います。site の値が明⽰的に定義されていない site3 の場合も、
同じパターンに従います。
「site_replication_factor = origin:2, site1:1, site2:2, total:5」のサイト 3 箇所 (site1, site2,
site3) のクラスタ： site1 がデータを⽣成するバケツを 2 つ、site2 が⽣成するバケツのコピーを 1 つま
たは 2 つ、site3 が⽣成するバケツのコピーを 1 つ保存します。site2 は、⾃⼰が取り込んだデータかどう
かに関係なく、任意のバケツのコピーを 2 つ保管します。site の値が明⽰的に定義されていない site3 は、
⾃⼰が取り込んだデータのバケツコピーを 2 つ保管し、site2 が取り込んだデータのバケツのコピーを 1 つ
または 2 つ保管します。(site2 が取り込んだデータのバケツの場合、初期割り当ての後 1 つのコピーが残り
ます。マスターはこれを無作為に site1 または site3 に割り当てます。)
「site_replication_factor = origin:1, total:4」のサイト 3 箇所のクラスタ： すべてのサイトにまた
がって、各バケツの 4 つのコピーが無作為に分散されます。各サイトには、最低 1 つのコピーが配布されま
す。
サイトのサーチ可能データ保持数の設定
最初にお読みください：
サイトのサーチ可能データ保持数を設定する前に、以下の事項を理解しておく必要があります。
基本的な単⼀サイトのサーチ可能データ保持数。「クラスタアーキテクチャの基礎」および「サーチ可能
データ保持数」を参照してください。
サイトの複製データ保持数。「サイトの複製データ保持数の設定」を参照してください。
マルチサイトクラスタの設定。「server.conf を使ったマルチサイト・インデクサー・クラスタの設定」を
参照してください。
サイトのサーチ可能データ保持数とは
108
マルチサイト・インデクサー・クラスタを導⼊するためには、サイトのサーチ可能データ保持数を設定する必要が
あります。これは単⼀サイトデプロイ環境に固有の、標準のサーチ可能データ保持数に代わるものです。サイトの
サーチ可能データ保持数は、クラスタの基本設定の⼀環としてマスターノードに指定します。
サイトのサーチ可能データ保持数は、クラスタ全体のサーチ可能バケツコピー数合計を制御するだけでなく、サイ
トレベルでのサーチ可能バケツコピーの場所を制御することができます。たとえば、2 サイト構成のクラスタで、
⽚⽅のサイトで 2 つのコピーを保持し、もう⼀⽅のサイトで 1 つのコピーを保持して、すべてのバケツのサーチ
可能コピーを合計で 3 つ保持するように設定することができます。
また、バケツのオリジンサイトに基づいて、サーチポリシーを指定することもできます。この場合、外部データを
取り込むサイトで、⾃⼰のサイトで取り込んだのではないデータのバケツコピー数よりも、⾃⼰が取り込んだデー
タのサーチ可能バケツコピー数を多く保持するように、サーチ可能データ保持数を設定することができます。たと
えば、各サイトで⾃⼰が取り込んだすべてのデータのサーチ可能コピーを 2 つ保持するけれども、他のサイトが
取り込んだデータのコピーは 1 つのみ保持するように設定することができます。
サイトの サーチ可能データ保持数は、クラスタがサーチアフィニティを達成しているかどうかを判断するために
役⽴ちます。「マルチサイト・インデクサー・クラスタへのサーチアフィニティの導⼊」を参照してください。
構⽂
と site_replication_factor の構⽂は同じですが、 site_search_factor 内の追加要件と明⽰サイト
の値が site_replication_factor 内のサブセットであるという違いがあります。このセクションは、構⽂の詳細を説
明しています。
site_search_factor
サイトのサーチ可能データ保持数は、マスターの server.conf ファイルの site_search_factor 属性で設定します。
この属性は、単⼀サイトの search_factor 属性の代わりに、[clustering] スタンザに存在しています。例：
[clustering]
mode = master
multisite=true
available_sites=site1,site2
site_replication_factor = origin:2,total:3
site_search_factor = origin:1,total:2
CLI を使ってサイトのサーチ可能データ保持数を設定することもできます。「CLI を使ったマルチサイト・イン
デクサー・クラスタの設定」を参照してください。
警告： site_search_factor 属性は正確に指定する必要があります。そうしないと、マスターは開始されません。
正式な構⽂を以下に⽰します。
site_search_factor = origin:<n>, [site1:<n>,] [site2:<n>,] ..., total:<n>
ここで：
は、バケツのサーチ可能データコピー数を⽰す正の整数です。
は、データを取り込んだサイト (データが最初にクラスタに⼊ってきたサイト) がそのバケツの
サーチ可能コピーを保持する最低数を⽰します。データを取り込んだサイトは、「オリジン」サイトと呼ば
れています。
site1:<n>, site2:<n>, ..., は、指定された各サイトが保持するサーチ可能な最低コピー数を⽰します。識別
⼦「site1」、「site2」などは、ピアノードに指定する site 属性値と同じです。
total:<n> は、クラスタ内のすべてのサイトにまたがる、各バケツの合計サーチ可能コピー数を⽰します。
<n>
origin:<n>
以下の事項に注意してください。
この属性は、サイトあたりのサーチ可能コピーポリシーを⽰しています。これはグローバルな設定で、すべ
てのインデックス内のすべてのバケツに適⽤されます。
この属性は mode=master および multisite=true の場合にのみ有効です。これらの条件を満たしている場合、ど
の search_factor 属性にも優先されます。
origin
および
total
の値が必要です。
サイト値 (site1:<n>, site2:<n>, ...) は省略可能です。ここに指定されたサイトは「明⽰」サイトと呼ばれま
す。ここに指定されないサイトは「⾮明⽰」サイトと呼ばれます。
サイトが取得するサーチ可能コピーの最低数を決定するには、site_replication_factor でサイトが取得する複
製された最低コピー数を決定する場合と同じ規則を使⽤します。「サイトの複製データ保持数の設定」を参
照してください。
に必要な最⼩値を決定するには、site_replication_factor の最⼩ total 値を決定するのと同じ規則を使
⽤します。「サイトの複製データ保持数の設定」を参照してください。
total
の値が、明⽰値の合計より⼤きくなる可能性があるため、クラスタには「残りの」サーチ可能バケツコ
ピーを取り扱うための⽅針が必要となります。⽅針は、「サイトの複製データ保持数の設定」で説明してい
る残りの複製されたコピーに関する⽅針に従います。
total
すべての値は、site_replication_factor の対応する値以下でなければなりません。
109
たとえば、「site_replication_factor = origin:2, site1:1, site2:2, total:5」の 3 サイトクラスタの場
合、site_search_factor で origin の値が 2 を超えることはできません。また、site1 の値が 1 を、site2 の値
が 2 を、total の値が 5 を超えることはできません。
で site の値が明⽰的に指定されている場合、site_replication_factor でも明⽰的に指定す
る必要があります。ただし、site_replication_factor の明⽰サイトの値は、site_search_factor には明⽰的に
指定する必要はありません。
site_search_factor
たとえば、「site_replication_factor = origin:2, site1:1, site2:2, total:5」(⾮明⽰サイト site3 がある)の 3
サイトクラスタ構成の場合、「site_search_factor = origin:1, site2:2, total:4」 (明⽰サイト site1 を除外
している) と指定できますが、「site_search_factor = origin:1, site1:1, site2:2, site3:1, total:4」 (⾮明⽰
サイト site3 を明⽰指定) とは指定できません。
サーチアフィニティの場合、それが必要な各サイトが最低 1 つのサーチ可能コピーを保持するよう
に、site_search_factor を設定する必要があります。明⽰サイトのみがサーチアフィニティの対象になりま
す。
単⼀サイトクラスタから移⾏する場合、total の値は最低でも単⼀サイトクラスタの search_factor の値と同
じ⼤きさでなければなりません。「単⼀サイトからマルチサイトへのインデクサークラスタの移⾏」を参照
してください。
属性のデフォルトは「origin:1, total:2」です。
例
サイトのサーチ可能データ保持数の構⽂例については、「サイトの複製データ保持数の設定」を参照してくださ
い。site_search_factor の origin/site/total の値を指定するための構⽂は、site_replication_factor と同じです。
単⼀サイトからマルチサイトへのインデクサークラスタの移⾏
単⼀サイトクラスタからマルチサイト・インデクサー・クラスタに移⾏することができます。移⾏後、クラスタは
単⼀サイトのバケツとマルチサイトのバケツの両⽅を保有します。それらは、以下の規則に従って個別に管理され
ます。
単⼀サイトのバケツ (移⾏時に存在していたバケツ) は、その単⼀サイト⽤の複製データ保持数とサーチ可能
データ保持数を使⽤します。これをマルチサイトに変換することはできません。
マルチサイトバケツ (移⾏後に作成されたバケツ) は、マルチサイトの複製データ保持数とサーチ可能データ
保持数に従います。
マルチサイト移⾏の実施
重要： 移⾏プロセスで、Splunk Enterprise のバージョンが変更されることはありません。マルチサイトクラス
タに移⾏するには、バージョン 6.1 以降のインスタンスが動作していなければなりません。そのため、マルチサ
イトに移⾏する前に、単⼀サイト・クラスタのアップグレード作業が必要なことがあります。「インデクサークラ
スタのアップグレード」の適切な⼿順に従って作業を⾏ってください。
単⼀サイトクラスタをマルチサイトに移⾏するには、各ノードをマルチサイト対応にするように設定を⾏います。
1. マスターノードをマルチサイト対応に設定してから、それを再起動します。⼿順は、「CLI を使ったマルチサイ
ト・インデクサー・クラスタの設定」を参照してください。例：
splunk edit cluster-config -mode master -multisite true -available_sites site1,site2 -site site1 site_replication_factor origin:2,total:3 -site_search_factor origin:1,total:2
splunk restart
以下の事項に注意してください。
複製データ保持数とサーチ可能データ保持数⽤の既存の単⼀サイト属性 replication_factor および
search_factor は削除しないでください。これらは、移⾏したバケツを処理するために必要です。
と site_search_factor の total の値は、それぞれが最低でも
と同じ⼤きさでなければなりません。
site_replication_factor
search_factor
replication_factor
および
いずれかのサイトのピア数が単⼀サイトの replication_factor または search_factor 未満の場合、それらの属
性の値を、もっとも少ないサイトのピア数に合わせる必要があります。たとえば、replication_factor が 3 で
search_factor が 2、そしていずれかのサイトのピアが 2 台しかない場合は、replication_factor を 2 に変更
する必要があります。そうしないと、クラスタによる移⾏されたバケツの複製⽅法により、移⾏されたバケ
ツが複製データ保持数やサーチ可能データ保持数を満たさないことになります。「マルチサイトクラスタが
複製データ保持数やサーチ可能データ保持数を満たさない」を参照してください。
2. マスター上でメンテナンスモードを設定します。
splunk enable maintenance-mode
このステップにより、不要なバケツ修復処理を防⽌できます。「メンテナンスモードの使⽤」を参照してくださ
110
い。
マスターがメンテナンスモードに移⾏したことを確認するには、splunk
show maintenance-mode
を実⾏します。
3. 既存のピアノードをマルチサイト対応に設定します。各ピアに対して、そのマスターノードとサイトを指定しま
す。例：
splunk edit cluster-config -site site1
ピアの再起動を要求するメッセージが表⽰されます。
各ピアに対してこの作業を⾏い、そのピアのサイトを指定します。
4. クラスタに新しいピアを追加したい場合は、「CLI を使ったマルチサイト・インデクサー・クラスタの設定」の
説明に従って作業を⾏います。例：
splunk edit cluster-config -mode slave -site site1 -master_uri https://10.160.31.200:8089 -replication_port 9887
splunk restart
この作業を、クラスタに追加する新たな各ピアに対して⾏います。
5. サーチヘッドをマルチサイト対応に設定します。各サーチヘッドに対して、そのマスターノードとサイトを指定
します。例：
splunk edit cluster-master https://10.160.31.200:8089 -site site1
各サーチヘッドに対してこの作業を⾏い、そのサーチヘッドのサイトを指定します。
6. クラスタに新しいサーチヘッドを追加したい場合は、「CLI を使ったマルチサイト・インデクサー・クラスタの
設定」の説明に従って作業を⾏います。例：
splunk edit cluster-config -mode searchhead -site site1 -master_uri https://10.160.31.200:8089
splunk restart
この作業を、クラスタに追加する新たな各サーチヘッドに対して⾏います。
7. マスター上でメンテナンスモードを無効にします。
splunk disable maintenance-mode
マスターがメンテナンスモードから復帰したことを確認するには、splunk
show maintenance-mode
を実⾏します。
[マスター] ダッシュボードを参照して、すべてのクラスタノードが正常に再稼働していることを確認することがで
きます。
移⾏時に、クラスタは各単⼀サイトバケツにサイト値でタグを設定します。
注意： server.conf を直接編集して、マルチサイトクラスタを設定することもできます。「server.conf を使ったマ
ルチサイト・インデクサー・クラスタの設定」を参照してください。
8. インデクサー検出を使⽤してフォワーダーにピアノードと接続させる場合、各フォワーダーにサイトを割り当て
る必要があります。「マルチサイトクラスタでのインデクサー検出の使⽤」を参照してください。
クラスタが単⼀サイトバケツを移⾏して管理する仕組み
マルチサイトクラスタのバケツには、オリジンサイトを識別するプロパティが含まれています。単⼀サイトクラス
タのバケツには、そのようなプロパティがありません。そのため、クラスタを単⼀サイトからマルチサイトに移⾏
する際には、各単⼀サイトバケツにオリジンサイト値でタグを設定する必要があります。バケツ名には、そのオリ
ジンとなるピアの GUID が含まれているため、クラスタは常にオリジンのピアを知っています。この情報を使っ
て、バケツのオリジンサイトが判断されます。
クラスタにオリジンピアが引き続き存在している場合、オリジンピアが割り当てられているサイトがバケツ
のオリジンサイトと判断されます。そこで、そのサイトがバケツのオリジンとして設定されます。
クラスタにオリジンピアが存在していない場合、そのバケツのコピー数がもっとも多いサイトがオリジンサ
イトと判断されます。そこで、そのサイトがバケツのオリジンとして設定されます。
クラスタが推定したオリジンサイトを使って単⼀サイトバケツを管理し、単⼀サイトの複製データ保持数とサーチ
可能データ保持数を満たすために必要な、バケツの修復処理を⾏う仕組みを以下に⽰します。
複製データ保持数を満たすために追加のバケツコピーを複製する必要がある場合、推定されたバケツのオリ
ジンサイト内でのみ複製が⾏われます。
サーチ可能データ保持数を満たすために、バケツのサーチ不可能コピーをサーチ可能にする必要がある場
合、バケツのサーチ不可能コピーがすでに他のサイトに存在している場合は、オリジンサイト以外でその処
理が⾏われることもあります。
111
オリジンサイト以外でバケツの新たなコピーが作成されることはありません。
インデクサークラスタのステータスの表⽰
[マスター] ダッシュボードの表⽰
このダッシュボードには、インデクサークラスタ全体のステータスに関する詳細情報が表⽰されます。ここから、
マスターの各ピアノードの情報を参照することもできます。
他のクラスタリングダッシュボードの詳細は、以下の項⽬を参照してください。
[ピア] ダッシュボードの表⽰
[サーチヘッド] ダッシュボードの表⽰
マスターダッシュボードへのアクセス
マスターノードのダッシュボードを表⽰するには：
1. Splunk Web の右上にある [設定] をクリックします。
2. [分散環境] セクションで、[インデクサークラスタリング] をクリックします。
このダッシュボードは、マスターとして有効にされたインスタンス上でのみ表⽰できます。
[マスター] ダッシュボードの表⽰
[マスター] ダッシュボードには、以下のセクションが存在しています。
クラスタの概要
[ピア] タブ
[インデックス] タブ
[サーチヘッド] タブ
[ピア] タブが開かれている、ダッシュボードの初期表⽰を以下に⽰します。
クラスタの概要
[クラスタの概要] には、クラスタのヘルス情報が簡単にまとめられています。以下のような情報が表⽰されます。
クラスタのデータが完全にサーチ可能かどうか、つまりクラスタ内のすべてのバケツにプライマリ コピーが
あるかどうか。
サーチ可能データ保持数と複製データ保持数が⼀致しているかどうか。
サーチ可能ピア数。
サーチ可能インデックス数。
クラスタのヘルス状態に応じて、以下のような警告メッセージが表⽰されることもあります。
⼀部のデータがサーチ不可能。
複製データ保持数が合いません。
サーチ可能データ保持数が合いません。
[クラスタの概要] に表⽰される情報の詳細は、下部にある各タブを参照してください。
ダッシュボードの右上には、3 つのボタンがあります。
編集： このボタンの詳細は、「ダッシュボードを使ったマスターの設定」を参照してください。マルチサイ
トクラスタの場合、このボタンは無効になっています。
112
詳細： マスターノード設定の詳細を表⽰します。
名前 ：マスターの $SPLUNK_HOME/etc/system/local/server.conf ファイルに指定されている、マスターの
serverName。
複製データ保持数： クラスタの複製データ保持数 。
サーチ可能データ保持数： クラスタのサーチ可能データ保持数 。
世代 ID： クラスタの現在のサーチ ID 。
ドキュメント：
[ピア] タブ
[マスター] ダッシュボードには、各ピアに対する以下の情報が表⽰されます。
ピア名： ピアの $SPLUNK_HOME/etc/system/local/server.conf ファイルに指定されている、ピアの serverName。
完全にサーチ可能： この列は、現在ピアがプライマリの完全セットを保有していて完全にサーチ可能かど
うかを⽰しています。
サイト： (マルチサイトのみ)各ピアのサイト値が表⽰されます。
ステータス： ピアのステータス：ここで説明しているプロセスの詳細は、「ピアをオフラインにする」を参
照してください。可能な値：
Up
Pending。マスターがピアから、連続して
3 回のハートビートを受信しなかった場合に発⽣します。こ
れは⼀時的な状態で、ピアが⻑時間この状態になることはほとんどありません。
Detention。ピアのリソースに制約がある場合 (例：ディスクスペースを使い切った)、制限状態に移⾏
します。この状態の間、ピアは⼊⼒を受け付けません。ただし、サーチには参加します。
Restarting。offline コマンドを実⾏すると、ピアは ReassigningPrimaries 状態から⼀時的にこの状態に
移⾏します。restart_timeout に指定されている期間、この状態が持続します (デフォルトは 60 秒)。こ
の時間内にピアを再起動しない場合、ピアは Down 状態に移⾏します。ローリング再起動中または
Splunk Web から再起動した場合にも、ピアはこの状態に移⾏します。
ShuttingDown。マスターが、ピアがシャットダウン中であることを検出しました。
ReassigningPrimaries。offline コマンドを実⾏した場合、ピアは⼀時的にこの状態に移⾏します。
Down。ピアがオフラインになった場合、ピアはこの状態に移⾏します。offline コマンドを実⾏して、
ピアがrestart_timeout の期間 (デフォルトは 60 秒) を超えてシャットダウンした、またはその他の理
由でピアがオフラインになった (たとえばクラッシュしたため) などの理由が考えられます。
バケツ： ピアがコピーを保有しているバケツ数です。
ピアの詳細情報を⼊⼿するには、ピア名の左にある⽮印をクリックします。以下のフィールドが表⽰されます。
場所： ピアの IP アドレスとポート番号。
前回のハートビート： マスターが前回にピアからハートビートを受信した時刻。
複製⽤ポート： ピアが他のピアから複製されたデータを受信するポートです。
ベース世代 ID： ピアのベース世代 ID で、ピアが前回クラスタに参加した時点の、クラスタの世代 ID と
等しくなります。この ID は、クラスタの現在の世代 ID 以下になります。ピアが世代 1 の時点でクラスタ
に参加し、それ以降クラスタに参加し続けている場合は、現在のクラスタの世代 ID が 5 になっていても、
そのピアのベース世代 ID は 1 になります。
GUID： ピアの GUID。
注意： ピアの停⽌後、そのステータスは「Down」または「GracefulShutdown」に変化しますが、リストには引
き続き表⽰されます。マスターのリストからピアを削除する⽅法については、「マスターのリストからのピアの削
除」を参照してください。
[インデックス] タブ
[マスター] ダッシュボードには、各インデックスに対する以下の情報が表⽰されます。
インデックス名： インデックス名。内部インデックス名の先頭には、アンダースコア (_) が付けられていま
す。
完全にサーチ可能： インデックスが完全にサーチ可能かどうか。つまり、各バケツの最低 1 つのサーチ可
能コピーを保有しているかどうかを表しています。インデックス内のバケツのサーチ可能コピーが 1 つもな
い場合は、インデックスはサーチ不可能であると報告されます。
サーチ可能データコピー： クラスタが保有するインデックスの完全なサーチ可能コピー数。
複製されたデータコピー： クラスタが保有するインデックスのコピー数。各コピーは完全で、失われてい
るバケツがない状態でなければなりません。
バケツ： インデックス内のバケツ数。
raw データの累積サイズ： ホットバケツを除くインデックスサイズ。
インデックスのリストには、内部インデックスの _audit と _internal が含まれます。これらの内部インデック
スには、クラスタ内のすべてのピアが⽣成したデータがまとめられています。ある 1 台のピアが⽣成したデータ
をサーチする必要がある場合、ピアのホスト名でサーチすることができます。
このタブには、[バケツのステータス] ボタンも表⽰されます。これをクリックすると、[バケツのステータス]
ダッシュボードに移動します。「[バケツのステータス] ダッシュボード」を参照してください。
注意： 新しいインデックスは、データが含まれて初めてここに現れます。⾔い換えると、ピアノードに新しいイ
ンデックスを設定すると、そのインデックスの⾏はインデックスにデータを送信して初めて表⽰されます。
[サーチヘッド] タブ
[マスター] ダッシュボードには、このクラスタにアクセスする各サーチヘッドに対する以下の情報が表⽰されま
す。
サーチヘッド名： サーチヘッドの
る、serverName。
$SPLUNK_HOME/etc/system/local/server.conf
113
ファイルに指定されてい
サイト： (マルチサイトのみ)各サーチヘッドのサイト値が表⽰されます。
ステータス： サーチヘッドが稼働しているかどうか。
注意： このリストには、サーチヘッドの 1 つとしてマスターノードが含まれています。マスターはサーチヘッド
機能を保有していますが、この機能はデバッグ⽬的でのみ使⽤する必要があります。マスターのリソースは、主⽬
的であるクラスタ動作の調整のためにのみ専念させる必要があります。マスターを実働環境のサーチヘッドにする
ことは絶対にしないようにしてください。また、専⽤のサーチヘッドとは違い、マスターのサーチヘッドにはマル
チクラスタサーチの設定を⾏えません。⾃⼰のクラスタのみサーチすることができます。
ピアの詳細情報を⼊⼿するには、サーチヘッド名の左にある⽮印をクリックします。以下のフィールドが表⽰され
ます。
場所： サーチヘッドのサーバー名とポート番号。
GUID： サーチヘッドの GUID。
[バケツのステータス] ダッシュボードの表⽰
[バケツのステータス] ダッシュボードには、クラスタ内のバケツのステータスが表⽰されます。これには 3 種類
のタブがあります。
修復タスク - 処理中
修復タスク - 保留中
超過バケツを持つインデックス
修復タスク - 処理中
このタブには、現在修復中のバケツのリストが表⽰されます。たとえば、バケツのコピー数が少なすぎる場合、ク
ラスタを「有効 」かつ「完全 」な状態に戻すために、修復処理を⾏う必要があります。その作業中は、このリス
トにバケツが表⽰されます。
修復タスク - 保留中
このタブには、現在修復待ちのバケツのリストが表⽰されます。修復タスクは、サーチ可能データ保持数、複製
データ保持数、および世代でフィルタリングすることができます。
バケツ修復作業の詳細は、「ピアノード停⽌時の処理」を参照してください。
超過バケツを持つインデックス
このタブには、超過バケツコピーを持つインデックスのリストが表⽰されます。超過コピーを持つバケツと、超過
サーチ可能コピーを持つバケツの両⽅が表⽰されます。また、各カテゴリの超過コピー数合計も表⽰されます。た
とえば、インデックス「new」に 3 つの超過コピー (1 つがサーチ可能) を持つバケツが 1 つ、そしてサーチ不可
能な 1 つの超過コピーを持つ 2 番⽬のバケツがある場合、「new」の⾏には以下のように表⽰されます。
2
1
4
1
超過コピーがあるバケツ
サーチ可能超過コピーがあるバケツ
合計超過コピー数
合計サーチ可能超過コピー数
単⼀のインデックスの超過コピーを削除する場合は、そのインデックスの⾏の右側にある [削除] ボタンをクリッ
クします。
すべてのインデックスの超過コピーを削除する場合は、[すべての超過バケツを削除] ボタンをクリックします。
超過バケツコピーの詳細は、「インデクサークラスタからの超過バケツコピーの削除」を参照してください。
分散管理コンソールを使⽤してステータスを確認
分散管理コンソール (DMC) を使⽤して、インデクサークラスタのステータスを含むデプロイのほぼすべてをモニ
タリングできます。コンソールを開始して⼊⼿できる情報は、マスターダッシュボードで⼊⼿可能な情報のほとん
どと重複します。
詳細は、「DMC を使⽤してインデクサークラスタステータスを確認」を参照してください。
[ピア] ダッシュボードの表⽰
インデクサークラスタの [ピア] ダッシュボードには、単⼀のピアノードのステータスに関する詳細情報が表⽰さ
れます。
クラスタ内のすべてのピアの情報を単⼀のビューで表⽰する場合は、代わりにマスターノードダッシュボードを使
⽤します。「[マスター] ダッシュボードの表⽰」を参照してください。
[ピア] ダッシュボードへのアクセス
[ピア] ダッシュボードを表⽰するには：
1. Splunk Web の右上にある [設定] をクリックします。
2. [分散環境] セクションで、[インデクサークラスタリング] をクリックします。
このダッシュボードは、ピアとして有効にされたインスタンス上でのみ表⽰できます。
114
ダッシュボードの表⽰
ダッシュボードの外観を以下に⽰します。
ダッシュボードには、ピアのステータスに関する情報が表⽰されます。
名前 ：ピアの $SPLUNK_HOME/etc/system/local/server.conf ファイルに指定されている、serverName。
複製⽤ポート： ピアが他のピアから複製されたデータを受信するポートです。
マスターの場所： マスターノードの IP アドレスとポート番号。
ベース世代 ID： ピアのベース世代 ID で、ピアが前回クラスタに参加した時点の、クラスタの世代 ID と
等しくなります。この ID は、クラスタの現在の世代 ID 以下になります。ピアが世代 1 の時点でクラスタ
に参加し、それ以降クラスタに参加し続けている場合は、現在のクラスタの世代 ID が 5 になっていても、
そのピアのベース世代 ID は 1 になります。
ピアの設定
[ピア] ダッシュボードの右上にある [編集] ボタンには、ピアの設定を変更するためのさまざまなオプションが⽤
意されています。「ダッシュボードを使ったピアノードの設定」を参照してください。
注意： マルチサイトクラスタの場合、[編集] ボタンは無効になっています。
[サーチヘッド] ダッシュボードの表⽰
このダッシュボードには、インデクサークラスタ内のサーチヘッドのステータスに関する詳細情報が表⽰されま
す。
ダッシュボードへのアクセス
ダッシュボードにアクセスするには：
1. Splunk Web の右上にある [設定] をクリックします。
2. [分散環境] セクションで、[インデクサークラスタリング] をクリックします。
このダッシュボードは、クラスタのサーチヘッドとして有効にされたインスタンス上でのみ表⽰できます。
ダッシュボードの表⽰
[サーチヘッド] ダッシュボードの例を以下に⽰します。
このダッシュボードには、サーチヘッドが所属しているすべてのクラスタのマスターノードが表⽰されます。ま
た、各クラスタのステータスに関する情報も表⽰されます。
マスターノードとクラスタの詳細を確認するには、各⾏の左側にある⽮印をクリックします。
サーチヘッドの情報を表⽰するには、ダッシュボードの右上にある [詳細] ボタンを選択します。
名前 ：サーチヘッドの
$SPLUNK_HOME/etc/system/local/server.conf
ファイルに指定されている、serverName。
サーチヘッドの設定
ダッシュボードには、サーチヘッドとして動作するための各種オプションが⽤意されており、またこれを使ってさ
まざまな設定を変更することができます。「ダッシュボードを使ったサーチヘッドの設定」を参照してください。
サーチピア上の情報の表⽰
サーチヘッドの Splunk Web の [分散サーチ] ページから、サーチヘッドのサーチピア (クラスタリングでは、ク
115
ラスタの⼀連のピアノードと同じ) の情報を表⽰することもできます。
1. サーチヘッド上で、Splunk Web の右上にある [設定] をクリックします。
2. [分散環境] セクションで、[分散サーチ] をクリックします。
3. [サーチピア] をクリックすると、⼀連のサーチピアが表⽰されます。
注意： サーチヘッド設定の変更やピアの追加に、Splunk Web の [分散サーチ] ページを使⽤しないでください。
インデクサークラスタのサーチヘッドを正しく設定する⽅法については、「サーチヘッド設定の概要」を参照して
ください。
DMC を使⽤してインデクサークラスタステータスを確認する
分散管理コンソール (DMC) を使⽤して、デプロイのほぼすべてをモニタリングできます。このトピックでは、イ
ンデックス作成のパフォーマンスを確認するコンソールダッシュボードについて説明します。
分散管理コンソールのプライマリの⽂書は、『分散管理コンソール』マニュアルに設定されています。
インデックス作成 のメニューには、2 種類のインデクサークラスタリングダッシュボードが存在します。
インデクサークラスタリング：ステータス
インデクサークラスタリング：サービスアクティビティ
インデクサークラスタリング：ステータスダッシュボードはクラスタの状態に関する情報を提供します。⼤きな規
模で、「[マスター]ダッシュボードの確認」に記載される通り、マスターダッシュボードの情報を重複表⽰しま
す。
インデクサークラスタリング：サービスアクティビティダッシュボードは、バケツ修理アクティビティや警告・エ
ラーなどの問題に関する情報を提供します。
詳細はダッシュボードを確認してください。また、『分散管理コンソール』マニュアルの「インデクサークラスタ
リング：ステータス」と「インデクサークラスタリング：サービスアクティビティ」を参照してください。
インデクサークラスタの管理
ピアをオフラインにする
ピアをオフラインにするには、splunk
断を最低限に抑えられます。
offline
コマンドを使⽤します。offline コマンドを使⽤すれば、サーチの中
ピアがオフラインになる途中または後、クラスタは有効 または完了 状態に復帰するためのアクションを⾏いま
す。
有効 なクラスタは、そのバケツのすべてのプライマリコピーを保有しており、データセット全体に対して
サーチリクエストを処理できます。マルチサイトクラスタの場合、有効なクラスタは各サイトのプライマリ
コピーを保有しており、サーチアフィニティも導⼊されています。
完全 クラスタには、そのすべてのバケツのコピーが複製データ保持数 の値だけ存在しており、またサーチ
可能データ保持数 の値だけのサーチ可能コピーを保有しています。そのため、障害対策の点で指定された要
件を満たしています。完全クラスタは有効なクラスタでもあります。
offline コマンド
CLI offline コマンドはピアのシャットダウンを指⽰します。これは処理中のサーチを完了しながら、素早く有効
な状態に戻せるように、ピアを段階的に停⽌していきます。このようにして、既存のサーチや今後のサーチが中断
されることを防⽌します。offline コマンドは、クラスタを完全な状態に戻すためのバケツ修復作業も開始しま
す。
注意： ピアはサーチ実⾏中の場合でも、最⼤で 5〜10 分後に停⽌します。
offline コマンドが意図通りに動作するためには、サーチ可能データ保持数は最低 2 以上でなければなりません。
そのため、サーチ可能データ保持数が 2 の場合、常にデータのサーチ可コピーの予備が存在しています。サーチ
可能データを持つピアがオフラインになった場合、そのデータの予備のサーチ可能コピーに即座に切り替えられて
新たなサーチが⾏われます。これにより、クラスタ上でサーチが不可能な時間を最⼩限に抑えられます。⼀⽅、
サーチ可能データ保持数が 1 の場合、サーチ可能コピーが利⽤できなくなると、まずサーチ不可能コピーをサー
チ可能にしないと、完全なデータセットに対してサーチを⾏うことはできません。「ピアオフライン時のクラスタ
復旧時間の⾒積もり」で説明しているように、この処理には時間がかかる可能性があります。
重要： ピアを停⽌する場合、stop コマンドではなく offline コマンドを使⽤します。offline コマンドは、サーチ
の中断を最⼩限に抑えるような⽅法でピアを停⽌します。
オフラインコマンドによるピアの停⽌
offline
コマンドの構⽂を以下に⽰します。
splunk offline
このコマンドは直接ピア上から実⾏します。
116
このコマンドを実⾏すると、クラスタを有効な状態に戻すために必要な処理をマスターが⼿配した後にピアが
シャットダウンされます (必要に応じて、プライマリを再度割り当て)。最⼤で 5〜10 分ほどかかります。シャッ
トダウンされるまでの間、ピアは継続中のサーチを処理します。
ピアのシャットダウン後、ピアのメンテナンス作業を⾏ってピアをオンラインに戻すまでに 60 秒間 (デフォルト)
の余裕があります。この時間内にピアがクラスタに復帰しなかった場合、マスターはクラスタを完全状態に戻すた
めのバケツ修復作業を開始します。60 秒以上必要な場合は、restart_timeout 属性を編集して、マスターがピアを
待機する時間を延⻑することができます。「再起動時間の延⻑」を参照してください。
多数のピアを⼀時的にオフラインにする操作を⾏っている場合、その操作中はメンテナンスモードに移⾏すること
を検討してください。「メンテナンスモードの使⽤」を参照してください。
ピアのオフライン時に⾏われるプロセスの詳細は、「ピアノード停⽌時の処理」を参照してください。
ピアの停⽌後、そのステータスは「Down」に変化しますが、[マスター] ダッシュボードのリストには引き続き表
⽰されます。マスターのリストからピアを削除する⽅法については、「マスターのリストからのピアの削除」を参
照してください。
再起動期間の延⻑
ピア上のメンテナンス作業を⾏う必要があるけれども、マスターの restart_timeout に設定されている期間 (デフォ
ルトは 60 秒) では⾜りないような場合、この設定値を変更することができます。マスター上で以下の CLI コマン
ドを実⾏してください。
splunk edit cluster-config -restart_timeout <seconds>
たとえば、以下のコマンドはタイムアウト期間を 900 秒 (15 分) に設定します。
splunk edit cluster-config -restart_timeout 900
このコマンドはその場で実⾏できます。実⾏後に、マスターを再起動する必要はありません。
また、マスター上の
server.conf
でこの値を変更することもできます。
ピアオフライン時のクラスタ復旧時間の⾒積もり
を超える時間、ピアがオフラインの時、マスターは残りのピアに対して、バケツを修復してクラス
タを完全状態に戻すための作業を指⽰します。たとえば、離脱ピアが 10 個のバケツのコピーを保管しており、そ
の中の 5 つがサーチ可能だった場合、マスターはピアに以下の作業を指⽰します。
restart_timeout
これらの 10 個のバケツを他のピアにコピーし、クラスタ内でバケツのコピー数が完全に維持されるように
します (複製データ保持数と⼀致)。
5 つのサーチ不可能バケツのコピーをサーチ可能にして、サーチ可能バケツのコピー数が完全に維持される
ようにします (サーチ可能データ保持数と⼀致)。
このアクティビティが完了するまでには、ある程度の時間がかかります。どのくらいの時間がかかるかは、以下の
ようなさまざまな要素によって異なります。
CPU、ストレージタイプ、接続タイプなどのシステム要因 。
サーチ可能バケツの作成作業を割り当てられたピアが現在実⾏している、その他のインデックス作成処理
作業量 。
オフラインのピアが保持していたバケツのサイズと数 。
オフラインのピアに保管されていた、サーチ可能コピー上のインデックスファイルサイズ 。(これらのイン
デックスファイルは、セグメント化の量などの要因によって、raw データと⽐べてサイズが⼤幅に異なりま
す。)raw データとインデックスファイルの相対サイズについては、「ストレージの検討事項」を参照してく
ださい。
サーチ可能データ保持数： クラスタが、サーチ不可能コピーをサーチ可能に変換するまでにかかる時間を
決定します。サーチ可能データ保持数が 2 以上の場合、クラスタは残りのサーチ可能コピーからサーチ不可
能コピーにインデックスファイルをコピーすることにより、サーチ不可能コピーをサーチ可能コピーに変換
することができます。サーチ可能データ保持数が 1 の場合、クラスタはインデックスファイルを再構築して
サーチ不可能コピーを変換する必要があるため、処理に時間がかかってしまいます。(バケツ内のファイルの
タイプについては、「データファイル」を参照してください。)
これらのさまざまな要因が影響しますが、処理にかかる概算時間を⾒積もることは可能です。Splunk Enterprise
が基準としているハードウェアを使⽤していることを前提に、2 つの主要処理にかかる概算時間の算出⽅法につい
て説明していきます。
10 GB (raw データやインデックスファイル) を LAN 経由であるピアから他のピアに転送する場合、およそ
5〜10 分ほどかかります。
4GB の raw データを含むサーチ不可バケツコピーのインデックスファイルを再構築するためにかかる時間
は、⽣成されるインデックスファイルのサイズなどのさまざまな要因によって異なりますが、おおまかには
30 分ほどかかると考えてください。サーチ可能データ保持数が 1 の場合、転送できるインデックスファイ
ルのコピーが存在しないため、インデックスファイルの再構築が必須になります。4 GBの raw データを含
むサーチ不可バケツのコピーにインデックスファイルが追加されると、サイズが約 10 GB に増加すること
もあります。前述のように、実際のサイズはさまざまな要素によって異なります。
メンテナンスモードの使⽤
ホットバケツのレプリケーション時にエラーが発⽣し、ソースピアでバケツの移⾏が⾏われるような状況がありま
117
す。インデクサークラスタを正常な状態に保つためにこの動作は有益ですが、エラーが頻繁に発⽣するとクラスタ
内に多数の⼩さなバケツができる可能性があります。このような状況が発⽣する原因としては、ネットワーク上の
問題が継続的に発⽣した、またはピアが頻繁にオフラインになった場合などが挙げられます。
この動作を停⽌するために、クラスタを⼀時的にメンテナンスモードにすることができます。メンテナンスモード
は、ネットワークの再設定などの、ネットワークエラーが頻発するシステムメンテナンス作業に役⽴ちます。同様
に、ピアをアップグレードする、または複数のピアを⼀時的にオフラインにするような場合も、メンテナンスモー
ドモードを利⽤して、作業時間中のバケツの移⾏処理を停⽌することができます。
メンテナンスモードは、単⼀サイトクラスタの場合もマルチサイトクラスタの場合も同じように機能します。これ
に、サイトの概念はありません。
警告： クラスタがメンテナンスモードの間は、マスターは複製データ保持数やサーチ可能データ保持数の規則を
適⽤しません。メンテナンスモード中に⾏われる唯⼀のバケツ修復処理は、マスターが利⽤できるサーチ可能バケ
ツコピーにプライマリを再割り当てする場合です。そのため、クラスタは有効だけれども不完全な状態で動作する
ことができます。詳細は、「インデクサークラスタの状態 」を参照してください。
注意： CLI コマンドの apply cluster-bundle と rolling-restart はデフォルトでその動作にメンテナンスモードを組
み込んでいます。そのため、これらのコマンドの実⾏時に明⽰的にメンテナンスモードを有効にする必要はありま
せん。これらのコマンドを実⾏した場合、メンテナンスモードがオンになったことを知らせるメッセージが [マス
ター] ダッシュボードに表⽰されます。
メンテナンスモードを有効にする
メンテナンス作業を開始する前に、クラスタをメンテナンスモードにしてください。メンテナンス作業が完了した
ら、メンテナンスモードを無効にする必要があります。
メンテナンスモードを有効にするには、マスターノード上で以下の CLI コマンドを実⾏します。
splunk enable maintenance-mode
コマンドを実⾏すると、メンテナンスモードの影響を警告するメッセージが表⽰されます。続⾏するには、
このメッセージに応答する必要があります。
enable
重要：6.3 より、メンテナンスモードがマスターの再起動時に継続します。
メンテナンスモードを無効にする
標準のバケツ移⾏ (ローリング) 動作に戻すには、以下のコマンドを実⾏します。
splunk disable maintenance-mode
メンテナンスモードのステータスの判断
メンテナンスモードがオンになっているかどうかを判断するには、以下のコマンドを実⾏します。
splunk show maintenance-mode
返された値が 1 の場合、メンテナンスモードがオンになっていることを表しています。0は、メンテナンスモード
がオフになっていることを表します。
インデクサークラスタ全体または 1 台のピアノードの再起動
ここでは、インデクサークラスタ全体または単⼀のピアノードの再起動⽅法について説明します。
マスターまたはピアノードを再起動すると、「インデクサークラスタのプライマリバケツの再調整」で説明してい
るように、マスターは⼀連のピアにプライマリバケツのコピーを再配分します。
再起動が必要な変更については、「server.conf 変更後の再起動」および「設定バンドル変更後の再起動または再
ロード」を参照してください。
クラスタ全体の再起動
通常は、クラスタ全体を再起動する必要はありません。マスターの設定を変更した場合は、マスターのみを再起動
します。⼀連の共通ピア設定を更新した場合、「共通のピア設定と App の更新」で説明しているように、マス
ターは必要な場合にのみ⼀連のピアを再起動します。
何らかの理由で、マスターとピアノードの両⽅を再起動しなければならない場合は、以下の⼿順に従ってくださ
い。
1. 通常のインスタンスの再起動と同様に、マスターノードを再起動します。たとえば、マスター上で以下の CLI
コマンドを実⾏します。
splunk restart
2. マスターの再起動が完了したら、すべてのピアがマスターに再登録するまで待機します。[マスター] ダッシュ
118
ボードには、すべてのピアとインデックスがサーチ可能であることを知らせるメッセージが表⽰されます。「[マ
スター] ダッシュボードを有効にする」を参照してください。
3. ピアをグループとして再起動します。マスター上で以下の CLI コマンドを実⾏してください。
splunk rolling-restart cluster-peers
「ローリング再起動 コマンドの使⽤」を参照してください。
サーチヘッドを再起動する必要がある場合は、残りのクラスタが動作している限り、任意の時点で再起動すること
ができます。
単⼀ピアの再起動
単⼀のピアでのみ特定の設定を変更した場合など、1 台のピアのみを再起動しなければならないこともあります。
単⼀ピアを安全に再起動するために、2 種類の⽅法が⽤意されています。
Splunk Web を使⽤する ([設定] > [サーバーコントロール] )。
CLI コマンド offline に start を指定する。
Splunk Web または offline/start コマンドを使ってピアを再起動する場合、マスターはピアが永久に停⽌したと
判断する前に 60 秒間 (デフォルト) 待機します。これはピアがオンラインに復帰するために⼗分な時間で、クラ
スタによる不要な復旧処理の実⾏を防⽌することができます。
注意： マスターが実際に待機する時間は、server.conf 内の restart_timeout 属性の値によって決まります。この属
性のデフォルト値は 60 秒です。マスターにより⻑い時間待機させたい場合は、「再起動期間の延⻑」の説明に
従って restart_timeout の値を変更してください。
offline/start
を使った再起動には、Splunk Web を使った再起動と⽐べて、処理中のサーチが完了するまで待っ
てからピアを停⽌するという利点があります。また、これは 2 段階に分けて⾏われる処理のため、何らかのメン
テナンス作業を⾏う⽬的でピアを短時間停⽌させたいような場合にも利⽤できます。
offline
コマンドの詳細は、「ピアをオフラインにする」を参照してください。
警告： ピアの再起動に CLI の restart コマンドは使⽤しないでください。restart コマンドを使⽤すると、マス
ターはそのピアが再起動中であることを認識できません。代わりに、ピアのハートビート送信を待つデフォルトの
60 秒経過後に、マスターは通常のピア停⽌時と同じように復旧作業を開始してしまいます (バケツコピーの他の
ピアへの追加など)。マスターの実際の待機時間は、マスターの heartbeat_timeout 属性の設定により異なります。
専⾨家からの指⽰がない限り、デフォルト値の 60 秒を変更することはお勧めできません。
ローリング再起動 コマンドの使⽤
コマンドは、再起動処理中もクラスタが引き続き機能できるように、すべてのピアノードを
段階的に再起動します。
splunk rolling-restart
ローリング再起動は以下の状況で発⽣します。
コマンドを呼び出すことで、ローリング再起動が実⾏されます。
マスターがローリング再起動を実⾏します。マスターは、ピアノードへの設定バンドルの配布後に、必要に
応じて⾃動的にローリング再起動を実⾏することもあります。このプロセスの詳細は、「設定バンドルの配
布」を参照してください。
splunk rolling-restart
注意： 絶対に必要な場合を除いて、splunk rolling-restart コマンドは使⽤しないでください。⼀連のピアを再起
動すると、バケツの修復処理に時間がかかる可能性があります。
ローリング再起動の仕組み
マスターは、⼀度にビアノードの約 10% (デフォルト) に対して、再起動のメッセージを発⾏します。クラスタ内
のピア数が 10 未満の場合は、1 回に 1 台のピアを再起動します。
これらのピアが再起動され、マスターとの通信が回復すると、別の 10 % のピアに再起動メッセージが発⾏されま
す。このような処理が、すべてのピアが再起動されるまで繰り返されます。この⽅法により、ロードバランシング
フォワーダーが送信するデータを受信するピアが常に存在することになります。
ローリング再起動の最後に、マスターはクラスタのプライマリバケツの再調整を⾏います。「インデクサークラス
タのプライマリバケツの再調整」を参照してください。
ローリング再起動の動作に関する諸注意：
マスターはピアを、無作為な順番で再起動します。
段階的な再起動中は、クラスタが完全にサーチ可能であることは保証されません。
ローリング再起動の指定
splunk rolling-restart
コマンドはマスターから実⾏します。
splunk rolling-restart cluster-peers
119
⼀度に再起動するピアのパーセンテージを指定
デフォルトで、マスターは 1 回に 10% のピアに対して再起動コマンドを発⾏します。ただし、この割合は
server.conf の [clustering] スタンザにある percent_peers_to_restart 属性で設定することができます。また、この
属性を CLI の splunk edit cluster-config コマンドで設定することもできます。たとえば、1 回にピアの 20% を再
起動するように動作を変更するには、以下のコマンドを実⾏します。
splunk edit cluster-config -percent_peers_to_restart 20
すべてのピアを⼀度に再起動させる場合は、値として
100
を指定してコマンドを実⾏します。
splunk edit cluster-config -percent_peers_to_restart 100
この⽅法は、サーチを実⾏しているユーザーが存在せず、フォワーダーがクラスタにデータを送信していないよう
な場合に役⽴ちます。再起動の完了までにかかる時間を短縮することができます。
属性を変更しても、実際の再起動を開始するためには
⾏する必要があります。
percent_peers_to_restart
splunk rolling-restart
コマンドを実
マルチサイトクラスタでのローリング再起動
マルチサイトクラスタでは、サイトを考慮したローリング再起動ができます。つまり、1 つのサイトのすべてのピ
アを再起動してから、次のサイトに移ります。これにより、各サイトに完全なプライマリのセットがあると仮定し
て、確実にクラスタを常時サーチ可能とします。
デフォルトでは、ローリング再起動はサイトと関係なく動作します。マスターはピアの場所を考慮せずに再起動し
ます。
マルチサイトクラスタでのローリング再起動の指⽰
マルチサイトクラスタで
splunk rolling-restart
コマンドを呼び出すと、次の動作を指定できます。
サイトを考慮して再起動するか、-site-by-site パラメータで指定します。
サイトの順を-site-order パラメータで指定します。
マルチサイト版の コマンドです。
splunk rolling-restart cluster-peers [-site-by-site true|false] [-site-order site<n>,site<n>, ...]
以下の事項に注意してください。
パラメータ
このパラメータにサイト認識によって再起動するかを指定します。
デフォルトでは「false」になっており、マスターはクラスタ全体から毎回ランダムでピアを選択する
状態になっています。またサイトのある場所は考慮されません。
-site-order パラメータ
このパラメータはサイトの再起動の順番を指定します。
このオプションを使⽤する際は、利⽤可能なサイトをすべて⼀覧表⽰にする必要があります。
このパラメータは -site-by-site パラメータが「true」に設定されている場合に意味を持ちます。
デフォルトでは、このパラメータは指定されておらず、ランダムで設定されます。
-site-by-site
以下のような 3 つのサイトクラスタを例に考えてみましょう。
splunk rolling-restart cluster-peers -site-by-site true -site-order site1,site3,site2
に値「true」があると、マスターは次のサイトに進む前にそのサイトでピア全部を再起動します。パラメータはマスターが再起動をかける順を site1、site3、site2 としています。そのため、マスター
はまず site1 の再起動を⾏い、完了するまで待機します。それから site3 を再起動し、同じく完了するまで待機し
て、最後に site2 の再起動を⾏います。
-site-by-site
site-order
各ラウンドで再起動するマルチサイトピアノ数をマスターが判断する⽅法
単⼀サイトクラスタと同様に、server.conf 内の percent_peers_to_restart 属性を編集して、同時に再起動するピア
のパーセンテージを指定できます。サイト別に再起動するかを問わず、このパーセンテージは常にグローバルに計
算されます。このパーセンテージが デフォルトの 10% だとして、2 箇所のサイトクラスタは site1 にピアが
10、site2 にピアが 20、合計 30 のピアがあり、マスターは⼀度にピアを 3 つまで再起動を⾏うとしましょう。
サイトを考慮しない再起動の場合、マスターは全サイトからランダムにピアを 3 つ選択します。あるサイトから
はピアを 2 つ、他からはピアを 1 つ、もしくはどれか⼀つのサイトからピアを 3 つ選択するケースも考えられま
す。
サイトを考慮する再起動の場合、その処理は以上とは異なります。
1. マスターが先に再起動するサイトを選択します。たとえば、site2 を選択します(サイトの順番は設定できま
120
す)。
2. マスターは site2 からピア 3 つを再起動します。
3. マスターは site2 からピアをさらに 3 つ再起動ます。以降、site2 の 20 のピア全部を再起動するまでこれを繰
り返します。site2 の再起動の最終回では、ピアは 2 つのみ再起動します。マスターは⼀回分の再起動をサイト間
で分割しません。
4. マスターは site1 からピアを 3 つを再起動します。
5. マスターは site1 からピアをさらに 3 つ再起動し、以降、繰り返しで site1 の 10 のピア全部を再起動します。
site1 の再起動の最終回では、ピアは 1 つのみ再起動します。これは、ピアが最後に 1 つ余るからです。
インデクサークラスタのプライマリバケツの再調整
マスターまたはピアノードを起動または再起動すると、マスターは⼀連のプライマリ バケツのコピーを各ピア
に、できる限り均等に配分されるように再調整を⾏います。たとえば、4 台のピアに 300 個のバケツがある場
合、各ピアが 75 個のバケツコピーを保持するのが理想です。再調整は、⼀連のピアのサーチ負荷を均等にするこ
とを⽬的にしています。
再調整の仕組み
マスターは再調整のために、必要に応じて既存のバケツコピーのプライマリ状態を、他のピア上の同じバケツ
のサーチ可能 コピーに再割り当てします。この再調整はできる限り最善の状態にするために⾏われますが、完全
な均等配分は保証されません。
再調整は、ピアまたはマスターノードがクラスタに参加または再参加した時に、⾃動的に⾏われます。ローリング
再起動時には、処理の最後に 1 回のみ調整が⾏われます。
注意： クラスタに新しいピアが参加した場合、再調整が⾏われますが、そのピアは再調整には参加しません (バケ
ツコピーをまだ保有していないため)。再調整は、サーチ可能バケツのコピーを保有している既存のピア間で⾏わ
れます。
バケツの再調整時、マスターは単純にあるサーチ可能コピーのプライマリ状態を、同じバケツの他のサーチ可能コ
ピーに再割り当てします (他のコピーが存在しており、そうすることで各ピア間のプライマリより均等になる場
合)。ピアでバケツのコピーが配信されることはありません。また、サーチ不可コピーが作成されることもありま
せん。既存のピアにサーチ可能コピーがない場合は、再調整時にそのピアにプライマリが渡されることもありませ
ん。
再調整の⼿動開始
この処理を⼿動で実⾏する場合は、ピアを再起動するか、またはマスター上の REST エンドポイント
/services/cluster/master/control/control/rebalance_primaries を使⽤します。たとえば、マスターノード上で以下の
コマンドを実⾏します。
curl -k -u admin:pass --request POST \
https://localhost:8089/services/cluster/master/control/control/rebalance_primaries
詳細は、cluster/master/control の REST API ドキュメントを参照してください。
マルチサイトクラスタの再調整
マルチサイトクラスタでの再調整の動作には、いくつかの違いがあります。マルチサイトクラスタの場合、⼀般的
に複数のサイトがプライマリコピーの完全セットを保有しています。クラスタの再調整を⾏う場合、再調整は各サ
イトで独⽴的に⾏われます。たとえば、2 サイトクラスタで、プライマリの再調整は site1 と site2 で独⽴して⾏
われます。2 つのサイト間でプライマリが移動することはありません。
いずれかのサイトでピアの起動または再起動が⾏われると、すべてのサイトで再調整が⾏われます。たとえば、2
サイトクラスタの site1 でピアを再起動すると、site1 と site2 の両⽅で再調整が⾏われます。
サマリー
クラスタの再調整は、クラスタ内の既存のサーチ可能コピーの、プライマリ割り当てを再調整することです。
これは以下の場合に⾏われます。
ピアがクラスタに参加または再参加した。
ローリング再起動の終了時。
マスターがクラスタに再参加した。
マスター上で REST エンドポイント rebalance_primaries を使⽤した。
インデクサークラスタからの超過バケツコピーの削除
ピアが停⽌した後再びインデクサークラスタに復帰した場合、停⽌中にそのピアに保持されていたバケツを再度利
⽤できるようになります。この場合、「ピアノードが復帰した場合の処理」で説明しているように、クラスタ内で
余分なバケツのコピーが保持される可能性があります。
つまり、復帰したピアにより、クラスタ内に複製データ保持数やサーチ可能データ保持数を満たすために必要なバ
ケツより多くのコピーが保管される可能性があります。余分なコピーを保持することには利点もありますが、余分
121
なコピーを削除してディスクスペースを節約することもできます。
超過バケツコピーは、[マスター] ダッシュボードまたは CLI で表⽰、削除することができます。
[マスター] ダッシュボードを使⽤
超過バケツコピーを表⽰または削除するには：
1. マスターノード上で、Splunk Web の右上にある [設定] をクリックします。
2. [分散環境] セクションで、[インデクサークラスタリング] をクリックします。
[マスター] ダッシュボードが表⽰されます。
3. [インデックス] タブを選択します。
4. [バケツのステータス] ボタンをクリックします。
[バケツのステータス] ダッシュボードが表⽰されます。
5. [超過バケツを持つインデックス] タブを選択します。
このタブには、超過バケツコピーを持つインデックスのリストが表⽰されます。超過コピーを持つバケツと、超過
サーチ可能コピーを持つバケツの両⽅が表⽰されます。また、各カテゴリの超過コピー数合計も表⽰されます。た
とえば、インデックス「new」に 3 つの超過コピー (1 つがサーチ可能) を持つバケツが 1 つ、そしてサーチ不可
能な 1 つの超過コピーを持つ 2 番⽬のバケツがある場合、「new」の⾏には以下のように表⽰されます。
2
1
4
1
超過コピーがあるバケツ
サーチ可能超過コピーがあるバケツ
合計超過コピー数
合計サーチ可能超過コピー数
単⼀のインデックスの超過コピーを削除する場合は、そのインデックスの⾏の右側にある [削除] ボタンをクリッ
クします。
すべてのインデックスの超過コピーを削除する場合は、[すべての超過バケツを削除] ボタンをクリックします。
CLI の使⽤
Splunk CLI には、余分なバケツを管理、削除するために役⽴つ 2 つのコマンドが⽤意されています。これらのコ
マンドを実⾏して、⼀連のインデックスセットを削除することも、単⼀のインデックスを削除することも可能で
す。
クラスタに余分なコピーがあるかどうかの判断
サーチ可能コピーも含め、バケツに余分なコピーがあるかどうかを判断するには、マスターから以下のコマンドを
実⾏します。
splunk list excess-buckets [index-name]
splunk list excess-buckets
からの出⼒は以下のようになります。
index=_audit
Total number of buckets=4
Number of buckets with excess replication copies=0
Number of buckets with excess searchable copies=0
Total number of excess replication copies across all buckets=0
Total number of excess searchable copies across all buckets=0
index=_internal
Total number of buckets=4
Number of buckets with excess replication copies=0
Number of buckets with excess searchable copies=0
Total number of excess replication copies across all buckets=0
Total number of excess searchable copies across all buckets=0
index=main
Total number of buckets=5
Number of buckets with excess replication copies=5
Number of buckets with excess searchable copies=5
Total number of excess replication copies across all buckets=10
Total number of excess searchable copies across all buckets=5
余分なバケツコピーの削除
余分なバケツコピーをクラスタ (または、クラスタ上の 1 つのインデックス) から削除するには、マスターから以
下のコマンドを実⾏します。
122
splunk remove excess-buckets [index-name]
マスターが、余分なコピーを削除するピアを決定します。この動作は設定不可能で、もっとも最近にクラスタに復
帰したピアから余分なコピーを削除する必要はありません。
マスターのリストからのピアの削除
ピアの停⽌後も、マスターのピアノードのリストにはそれが表⽰されています。たとえば、停⽌した状況 (⽅法)
によっては、ステータスが「Down」または「GracefulShutdown」になっても、[マスター] ダッシュボードに引
き続き表⽰されます。その後マスターを再起動すると、そのピアはマスターのリストから削除されます。マスター
を再起動せずに、CLI の splunk remove cluster-peers コマンドを使ってピアを削除することもできます。
./splunk remove cluster-peers -peers <guid>,<guid>,<guid>,...
以下の事項に注意してください。
このコマンドは、マスターのピアリストから、1 つまたは複数の ピアを削除します。
削除するピアはすべて、ステータスが「Down」または「GracefulShutdown」でなければなりません。
ピアは、その GUID をカンマ区切りリストで指定します。
GUID のハイフンは、指定することも省略することも可能です。例：4EB4D230-CB8B-4DEB-AD68CF9209A6868A および 4EB4D230CB8B4DEBAD68CF9209A6868A はどちらも有効な指定です。
リストに無効な GUID が指定されている場合、その GUID を停⽌したピアと関連付けられないため、処理
全体が異常終了します。
[マスター] ダッシュボードのピアリスト詳細は、「[マスター] ダッシュボードの表⽰」を参照してください。
マルチサイト・インデクサー・クラスタの管理
マスターサイト障害の取り扱い
マスターノードが存在しているサイトで障害が発⽣した場合は、残りのいずれかのサイトで新たなマスターを⽴ち
上げることができます。その間も、クラスタはできる限り最善の動作を⾏うように努⼒します。ピアは引き続きマ
スター停⽌時に使⽤していたターゲットピアのリストに基づいて、他のピアにデータをストリーム配信します。そ
れらのターゲットピアの⼀部が停⽌した場合 (サイト障害発⽣など)、それらはストリーム配信するターゲットのリ
ストから削除され、リストに残っているピアにデータのストリーム配信が続⾏されます。
マスターサイト障害に備えて、他の最低 1 つのサイトにスタンバイマスターを設定する必要があります。
以下の作業を⾏います。
1. 現在のマスターがあるサイト以外の最低 1 つのサイトに、スタンバイマスターを設定します。⽅法について
は、「インデクサークラスタのマスターノードの交換」を参照してください。これは事前準備の作業です。必要
な事態が発⽣する前に、この作業を⾏う必要があります。
2. マスターサイトが停⽌したら、残りのいずれかのサイトでスタンバイマスターを⽴ち上げます。「インデクサー
クラスタのマスターノードの交換」を参照してください。
3. クラスタのインデックス作成を再開します。「マスターノード再起動またはサイト障害後のインデックス作成の
再開」を参照してください。
新しいマスターが、古いマスターの代わりに機能します。
注意： サイトが後ほど復旧したら、そのサイトのピアに新しいマスターを指⽰する必要があります。「ピアと
サーチヘッドノードが新しいマスターを⾒つけられるようにする」を参照してください。
マスター再起動またはサイト障害後のインデックス作成の再開
マスターが復帰すると、複製データ保持数を満たすために⼗分なピア数がインデクサークラスタに存在するように
なるまでの間、インデックス作成はブロックされます。基本的に単⼀サイトクラスタの場合、これは望ましい動作
です。ただし、マルチサイトクラスタの場合は、サイトの複製データ保持数を満たすために⼗分な数のピアが利⽤
できない場合でも、インデックス作成を再開したい場合があります (たとえば、サイト障害が発⽣した場合)。
⼀般的にこのようなニーズが発⽣する事例は 2 つあります。
サイトが停⽌した後に、何らかの理由でマスターを再起動する必要がある。
マスターがあるサイトが停⽌したため、他のサイトでスタンバイマスターを起動した。
サイトが停⽌したけれどもマスターが他のサイトで動作している場合は、マスターは起動時にのみチェックを⾏う
ため、インデックス作成は普段通りに続⾏されます。
インデックス作成のブロックを解除するために、複製データ保持数だけのピアが利⽤できない場合は、マスター上
で splunk set indexing-ready コマンドを実⾏します。
splunk set indexing-ready -auth admin:changeme
たとえば、「site_replication_factor = origin:1, site1:2, site2:2, site3:2, total:7」設定の 3 サイトクラスタを考
えてみましょう。ここでマスターは site1 に存在しています。site2 が停⽌して、その後にマスターを再起動した
123
場合、マスターは再起動後のインデックス作成をブロックします (site2 の最低 2 台のピアの⽣存を確認待ちのた
め ("site2:2"))。この状況で、残りのサイトでインデックス作成を再開するためにコマンドを使⽤することができ
ます。
同様に、マスターがある site1 が停⽌して、site2 のスタンバイマスターを起動した場合、当初新しいマスターは
site1 が利⽤できないために、インデックス作成をブロックします。この場合にコマンドを使って新しいマスター
にインデックス作成の再開を指⽰することができます。
重要： 記載されている状況下でマスターを再起動する場合は、毎回 splunk set indexing-ready を実⾏する必要があ
ります。このコマンドは、現在の再起動のインデックス作成のみをブロック解除します。
注意： このコマンドはサイト障害を前提に設計されていますが、単⼀サイトクラスタで複製データ保持数だけの
ピアが利⽤できるようになる前にインデックス作成を再開する場合にも使⽤できます。ただし、そのような場合で
も、⼀般的には複製データ保持数だけのピアがクラスタに再参加するまで待つことをお勧めします。
マルチサイト・インデクサー・クラスタの単⼀サイトクラスタへの変
換
マルチサイト・インデクサー・クラスタを基本的な単⼀サイトクラスタに変換することができます。そうすると、
すべてのピアとサーチヘッドが、暗黙的な単⼀サイトクラスタの⼀部となります。
1. すべてのクラスタノード (マスター/ピア/サーチヘッド) を停⽌します。
2. マスターノードで、server.conf を編集します。
a.
multisite
に
false
を設定します。
b. 単⼀サイトクラスタの
す。
c.
site
replication_factor
と
search_factor
属性を、⽬的の複製動作を⾏うように設定しま
属性を削除します。
3. 各ピアおよびサーチヘッド上で、server.conf を編集します。
a.
site
属性を削除します。
4. マスターノードを開始します。
5. ピアノードとサーチヘッドを開始します。
以下の事項に注意してください。
マスターは
す。
server.conf
に残っている任意のマルチサイト⽤属性 (site_replication_factor など) を無視しま
再起動時に、マスターは各バケツのプライマリコピーを取得します。
変換後、単⼀サイトクラスタの複製データ保持数を超えるバケツコピーは、そのまま残されます。これらの
余分なコピーの削除⽅法については、「インデクサークラスタからの超過バケツコピーの削除」を参照して
ください。
以降のバケツの複製とバケツの修復は、単⼀サイトクラスタの複製データ保持数およびサーチ可能データ保
持数に設定された値に従って⾏われます。
単⼀サイトクラスタからマルチサイトクラスタへの変換⽅法については、「単⼀サイトからマルチサイトへのイン
デクサークラスタの移⾏」を参照してください。
ピアの新しいサイトへの移動
ピアを別のサイトに移動する場合、この⼿順を使⽤します。この⼿順は、ピアを誤ったサイトに配送し、間違いに
気が付く前にピアをデプロイした場合に役⽴ちます。
1. offline コマンドでピアをオフラインにします。「ピアをオフラインにする」を参照してください。マスターは
このピアが処理していたバケツのコピーを、同じサイト内の他のピアに割り当てます。
2. ピアのサーバーを新しいサイトに移動します。
3. サーバーから、すべてのバケツを持つインデックスデータベースも含めて、インストールされている Splunk
Enterprise 全体を削除します。
4. サーバーに Splunk Enterprise を再インストールしてクラスタリングを有効にし、ピアのサイト値に新しいサ
イトを設定します。
ピアがクラスタに新しいピアとして再参加します。
インデクサークラスタの仕組み
⾼度なユーザー向けのインデクサークラスタの基本概念
124
クラスタの機能を理解するためには、いくつかの概念に慣れ親しんでおく必要があります。
複製データ保持数： クラスタが保持するデータのコピー数を⽰します。これはクラスタの回復⼒ (複数の
ノード障害に対処できる能⼒) を⽰しています。
サーチ可能データ保持数： クラスタが保持するサーチ可能 なデータコピー数を⽰します。クラスタのノー
ド停⽌からの復旧速度に影響します。
バケツ： インデックス⽤の基本ストレージコンテナです。インデクサーのデータベース内のサブディレクト
リに対応しています。
クラスタの状態： これらの状態は、クラスタの健全性 (ヘルス) に関する情報を表しています。
これらの概念の概要は、クラスタのアーキテクチャを紹介している「インデクサー・クラスタ・アーキテクチャの
基礎」を参照してください。今ご覧の章にある各トピックに、詳細が記載されています。
複製データ保持数
インデクサークラスタ設定の⼀環として、クラスタに保持するデータのコピー数を指定します。ピアノードは到着
したデータをバケツ に格納し、クラスタは各バケツの複数のコピーを管理しています。クラスタは各バケツのコ
ピーを、個別のピアノードに保管します。クラスタが管理/保持する各バケツのコピー数が、複製データ保持数 で
す。
複製データ保持数とクラスタの弾性
クラスタは、「複製データ保持数 - 1」台のピアノード障害に対処することができます。たとえば、システムで 2
台のピアの障害発⽣に対処できるようにするためには、複製データ保持数に 3 を設定する必要があります。この
場合、クラスタは 3 つの同⼀の各バケツのコピーを、別個のノードに保管します。複製データ保持数に 3 を設定
した場合、クラスタの障害発⽣ピアノード数が 2 台までならば、すべてのデータを引き続き利⽤することができ
ます。2 台のノードが停⽌しても、引き続き残りのピアにある 1 つの完全なデータコピーを利⽤できます。
複製データ保持数を増やすことで、より多くの台数のピアノード障害に対処することができます。複製データ保持
数が 2 の場合、1 台のノード障害に対する耐性しかありません。3 の場合は、2 台のピアノードの同時障害に対処
できます (以降同様)。
このトレードオフは、値を増やすとそれだけ多くのデータコピーを保管、処理しなければならないことです。複製
活動⾃体はさほど処理能⼒を消費しませんが、複製データ保持数が増加するにつれて、より多くのインデクサーを
稼働させる必要があり、またインデックスデータに対するストレージもより多く確保する必要があります。⼀⽅、
データ複製⾃体にはさほど処理能⼒を必要としないため、クラスタ内に複数のインデクサーを配置する利点を活⽤
して、より多くのデータを取り込んでインデックスを作成することができます。クラスタ内の各インデクサーは、
オリジナルデータを持つインデクサー (ソースピア) および複製ターゲット (ターゲットピア) の両⽅として機能で
きます。これは、到着したデータのインデックスを作成でき、またクラスタ内の他のインデクサーからのデータコ
ピーを保管することも可能です。
例：複製データ保持数
以下の図では、1 台のピアがフォワーダーからデータを受信して処理し、それを他の 2 台のピアに転送していま
す。クラスタには、そのピアのデータの 3 つの完全なコピーが、各ピアに 1 つずつ保管されます。
125
注意： この図では、すべてのデータが単⼀のピアを通じてシステムに取り込まれるように、ピア複製を⼤幅に簡
素化して表しています。実際には複雑性が増すいくつかの問題が存在しています。
⼤部分のクラスタでは、各ピアノードがソースピアとターゲットピアの両⽅として動作し、どちらもフォ
ワーダーから外部データを、そして他のピアから複製されたデータを受信しています。
⽔平⽅向のスケーリングを確保するために、複製データ保持数が 3 のクラスタを 4 台以上のピアで構成する
ことができます。各ソースピアは任意の時点でそのデータのコピーを 2 台のターゲットピアに転送します
が、新しいホットバケツの開始時には毎回、そのターゲットピアが変化する可能性があります。
この章の後半のトピックでは、クラスタによるデータの処理⽅法が詳細に説明されています。
マルチサイトクラスタの複製データ保持数
マルチサイトクラスタは特別なバージョンの複製データ保持数、サイトの複製データ保持数を使⽤します。これは
クラスタ全体が管理するコピー数だけでなく、各サイトが管理するコピー数も決定します。サイトの複製データ保
持数の詳細は、「サイトの複製データ保持数の設定」を参照してください。
サーチ可能データ保持数
マスターノードを設定する際には、サーチ可能データ保持数 を指定します。サーチ可能データ保持数は、インデ
クサークラスタが保持するデータのサーチ可能 コピー数を表しています。つまり、サーチ可能データ保持数は
各バケツ のサーチ可能コピー数を決定します。サーチ可能データ保持数のデフォルト値は 2 で、この場合クラス
タはすべてのデータのサーチ可能コピーを 2 つ保持します。サーチ可能データ保持数は、複製データ保持数 以下
でなければなりません。
サーチ可能およびサーチ不可能バケツコピー
バケツのサーチ可能なコピーとサーチ不可 のコピーの違い：サーチ可能なコピーにはデータとピアノードがデー
タのサーチに使⽤する拡張インデックスファイルが含まれています。サーチ不可能コピーには、データのみが含ま
れています。サーチ不可能コピーに含まれているデータにも初期処理が⾏われており、必要に応じてインデックス
ファイルを再作成できる形式で保管されています。Splunk Enterprise インデックスを構成するファイルの詳細
は、「データファイル」を参照してください。
ピアノード障害からのサーチの回復
サーチ可能データ保持数が 2 以上の場合、あるピアノードが停⽌してもわずかな中断でサーチを継続することが
できます。たとえば、複製データ保持数に 3、サーチ可能データ保持数に 2 を指定した場合を考えてみましょ
う。クラスタはクラスタ内の個別のピアに、すべてのバケツの 3 つのコピーを保管、管理します。各バケツの 2
つのコピーがサーチ可能になります。サーチに関与しているバケツのコピーを持つピアが停⽌した場合、他のピア
のバケツのサーチ可能コピーが即座にサーチに参加します。
⼀⽅、クラスタのサーチ可能データ保持数が 1 の場合にピアが停⽌すると、クラスタデータの完全なセットを対
象にサーチを再開できるまでに⼤幅に時間がかかってしまいます。バケツのサーチ不可コピーをサーチ可にするこ
とはできますが、raw データからインデックスファイルを構築しなければならないため、この変換処理には時間が
かかります。停⽌したピアに⼤量のサーチ可能データが保管されていた場合、処理時間が⼤幅に⻑くなることがあ
ります。サーチ不可能コピーをサーチ可能に変換するためにかかる時間の⾒積もりについては、ここを参照してく
ださい。
クラスタでサーチ可能コピー数を制限する理由は、サーチ可能データはサーチ不可能データよりも⼤量のストレー
ジを消費するためです。そのため、ピアノード障害発⽣時にもすべてのデータに素早くアクセスできることとスト
レージ要件の増加がトレードオフとなります。サーチ可能およびサーチ不可能データの相対ストレージサイズの⾒
積もりについては、「ストレージの検討事項」を参照してください。たいていのニーズの場合は、デフォルトの
サーチ可能データ保持数である 2 がバランスの取れた選択となります。
マルチサイトクラスタのサーチ可能データ保持数
マルチサイトクラスタは特別なバージョンのサーチ可能データ保持数、サイトのサーチ可能データ保持数を使⽤し
ます。これはクラスタ全体が管理するサーチ可能コピー数だけでなく、各サイトが管理するサーチ可能コピー数も
決定します。サイトのサーチ可能データ保持数の詳細は、「サイトのサーチ可能データ保持数の設定」を参照して
ください。
バケツとインデクサークラスタ
Splunk Enterprise はインデックスデータをバケツ に保管します。バケツは、データ⾃⾝およびデータのイン
デックスファイルの両⽅を保管するディレクトリです。⼀般的にインデックスは多数のバケツから成り⽴ってお
り、データの経過時間別に編成されています。
インデクサークラスタは、バケツ単位で複製されます。元のバケツと他のピアノード上の複製されたコピーには、
同⼀のデータセットが含まれています。ただし、インデックスファイルはサーチ可能 コピーにのみ存在していま
す。
クラスタ内で、単⼀のソースピアからのバケツのコピーを複数のターゲットピアに分散させることができます。た
とえば、5 台のピアが存在するクラスタの複製データ保持数が 3 の場合 (⽔平⽅向スケーリングの⼀般的なシナリ
オ)、クラスタは各バケツセットの複製コピーを 3 つ保持します (ソースピア上の元のコピーと 2 台のターゲット
ピア上の複製されたコピー)。ソースピアが新しいホットバケツを開始すると、マスターはそのピアに対して、
データの複製先となる新しい⼀連のターゲットピアを指⽰します。そのため、オリジナルのコピーはすべてソース
ピアに存在し、それらのバケツの複製されたコピーが他のピアに無作為に分散されます。この動作を設定すること
はできません。同じピア上に同じバケツのコピーが 2 つ存在することはありません。マルチサイトクラスタの場
合、複製されたコピーのサイトの場所を設定することもできますが、実際のピアを指定することはできません。
今説明したシナリオを以下の図に⽰します。5 台のピア、複製データ保持数 3、および 7 つのオリジナルのソー
126
スバケツが存在し、そのコピーはすべてのピアにまたがって展開されています。簡略化するために、この図ではあ
る 1 台のピアからのデータバケツのみを表⽰しています。実際の環境では、すべてではないですが、その他のピ
アもデータの送信元となり、それをクラスタ内の他のピアに複製します。
この図で、1A がソースバケツになります。1B は 1C そのバケツのコピーです。この図では、同じ⽅法で
2A/B/C、3A/B/C、などのように表記しています。
クラスタの構造を理解するためには、バケツを正しく理解する必要があります。このセクションの残りの部分で
は、クラスタのデプロイにとって重要なバケツの概念について取り上げていきます。バケツの詳細については、
「インデクサーによるインデックスの保管⽅法」を参照してください。
データファイル
バケツ内には主に 2 種類のファイルが存在しています。
処理された圧縮形式の外部データ (raw データ )
raw データを指すインデックス (インデックスファイル )
バケツにはその他の種類のファイルもいくつか存在していますが、これらが理解しておく必要がある重要なファイ
ルです。
raw データは実際には「未加⼯の」データではありません。このデータは、イベントとして処理された外部データ
から成り⽴っています。処理されたデータは圧縮された raw データジャーナルファイルに保管されます。raw
データファイルはジャーナルファイルとして、イベントデータ だけでなく、関連するインデックスファイルを⽣
成するために必要なすべての情報を保管しています。
raw データは、サーチ可能 およびサーチ不可能 の両⽅のバケツコピーに含まれています。サーチ可能コピーには
インデックスファイルも含まれます。
ピアノードは、⼀連のデータをフォワーダーから受け取ると、データを処理してそれをローカルのホットバケツの
raw データファイルに追加します。また、インデックス処理も⾏い、対応するインデックスファイルを作成しま
す。さらに、処理した raw データのコピーのみをターゲットピアに転送します。ターゲットピアは、その raw
データファイルを独⾃のバケツのコピーに追加します。オリジナルおよび複製されたバケツコピーの raw データ
は同⼀です。
クラスタのサーチ可能データ保持数が 1 の場合、ターゲットピアのバケツのコピーには、raw データのみが保管
されます。データのインデックスファイルは作成されません。ターゲットピア上にインデックスファイルを保管し
ないことで、ストレージ要件を緩和することができます。raw データはジャーナルファイルとして保存されるた
め、オリジナルの完全にインデックス処理されているデータを管理しているピアが停⽌した場合、いずれかのター
ゲットファイルがその raw データのコピーからインデックスを⽣成することができます。
クラスタのサーチ可能データ保持数が 2 以上の場合、⼀部または全部のターゲットピアもデータのインデックス
ファイルを作成します。たとえば、複製データ保持数に 3、サーチ可能データ保持数に 2 を指定した場合を考え
てみましょう。この場合、ソースピアが raw データを 2 つのターゲットピアに配信します。これらのピアのいず
れかは raw データを使ってインデックスファイルを作成します。このインデックスファイルは、バケツのコピー
に保管されます。このようにして、データのサーチ可能コピーが 2 つ存在することになります (元のコピーとイン
デックスファイルを持つ複製されたコピー)。「サーチ可能データ保持数」で説明されているように、これによっ
127
てピアノード障害発⽣時にも、クラスタをより素早く復旧することができます。サーチ可能バケツコピーの詳細
は、このトピックの後半にある「バケツのサーチの可否」を参照してください。
バケツファイルの詳細は、これらのトピックを参照してください。
ピア停⽌時のバケツファイルの再⽣成⽅法については、「ピアノード停⽌時の処理」を参照してください。
raw データとインデックスファイルの相対サイズについては、「ストレージの検討事項」を参照してくださ
い。
バケツの移⾏
バケツは時間の経過とともに、さまざまな段階 (ステージ) に移⾏します。
ホット
ウォーム
コールド
フローズン
これらのステージの詳細は、「インデクサーによるインデックス保管⽅法」を参照してください。
クラスタのアーキテクチャを説明する前に、これらのバケツの各ステージの基本的な概念を理解しておく必要があ
ります。ホットバケツは、現在も継続して書き込まれているバケツです。インデクサーがホットバケツへの書き込
みを終了すると (たとえば、バケツが最⼤サイズに達したため)、そのバケツはウォームに移⾏され、新しいホット
バケツへの書き込みが開始されます。ウォームバケツは読み取り可能ですが (例：サーチ⽤)、それに新しいデータ
が書き込まれることはありません。その後バケツはコールドに移⾏し、最後にはフローズンになります。フローズ
ン状態のバケツはアーカイブされるか、または削除されます。
これ以外にもいくつかの事項を覚えておく必要があります。
ホット/ウォームバケツとコールドバケツは、それぞれ別の場所に保管されます。これらの場所は設定するこ
とができます。
ウォームまたはコールドバケツのファイル名には、バケツ内のデータの時間範囲が含まれています。バケツ
の命名規則の詳細は、「インデックスディレクトリの内容」を参照してください。
サーチは、ホット、ウォーム、およびコールドバケツにまたがって⾏われます。
バケツの移⾏条件は、「インデックスストレージの設定」で説明するように、設定を変更することが可能で
す。
ストレージ要件の⾒積もり⽅法などの、ストレージのハードウェア情報については、「ストレージの検討事
項」を参照してください。
バケツのサーチの可否と優先度状態
バケツのコピーはサーチ可能 またはサーチ不可能 になります。クラスタは複数バケツのサーチ可能コピーを管理
できるため、どのコピーがサーチに関与しているのかを判断する⽅法が必要になります。このためにクラスタ
は、優先度 の概念を使⽤しています。サーチ可能バケツのコピーは、優先 または⾮優先になります。
バケツのコピーに、raw データファイルに加えてインデックスファイルも含まれている場合、それはサーチ可能と
なります。外部データを受信するピアは、raw データのインデックスを作成し、raw データのコピーをそのター
ゲットピアに送信します。サーチ可能データ保持数が 1 より⼤きい場合は、それに応じてピアの⼀部または全部
が複製したバケツのインデックスファイルを⽣成します。たとえば、複製データ保持数が 3、サーチ可能データ保
持数が 2、そしてクラスタが完全 な場合、クラスタには各バケツのコピーが 3 つ存在することになります。3 つ
のコピーすべてに raw データファイルが含まれており、その中の 2 つのコピー (ソースピアのコピーといずれか
のターゲットピア上のコピー) にはインデックスファイルも含まれているためサーチ可能になります。3 番⽬のコ
ピーはサーチ不可能になりますが、必要に応じてサーチ可能に変換することができます。サーチ不可能コピーを
サーチ可能に変換する処理は、主にバケツのサーチ可能コピーを保持するピアが停⽌した場合などに⾏われます。
バケツのプライマリコピーは、サーチに参加するサーチ可能コピーです。有効 な単⼀サイトクラスタには、各バ
ケツに 1 つのプライマリコピーが存在しています。このようにして、各バケツの 1 つのコピーのみがサーチされ
ます。プライマリコピーを保有しているノードが停⽌した場合、プライマリではない他のノード上のサーチ可能バ
ケツが即座にプライマリとして指名され、サーチが続⾏されます。新たにインデックスファイルが⽣成されるまで
待機する必要はありません。
注意： マルチサイトクラスタの場合、有効なクラスタとは各サイトの⼀連のプライマリコピーを保有しており、
サーチアフィニティも満たしているクラスタです。サーチアフィニティを満たしている場合、サーチヘッドはロー
カルサイトのピアに対してサーチを実⾏します。このためには、各サイトが独⾃のプライマリバケツのセットを保
有している必要があります。
最初は、オリジナルのデータを保有するピアのバケツのコピーがプライマリコピーになりますが、これは時間の経
過に伴い変更される可能性があります。たとえば、ピアが停⽌した場合、マスターは停⽌したピア上のプライマリ
コピーからの優先度を、残りのピアの対応するサーチ可能コピーに再割り当てします。このプロセスの詳細は、
「ピアノード停⽌時の処理」を参照してください。
優先度の再割り当ては、マスターによるクラスタの再調整時にも、ピア間のプライマリコピーを均等に配分するた
めに⾏われます。再調整は以下の場合に⾏われます。
ピアがクラスタに参加または再参加した。
マスターがクラスタに再参加した。
マスター上で REST エンドポイント rebalance_primaries を使⽤した。
詳細は、「インデクサークラスタのプライマリバケツの再調整」を参照してください。
すべてのピアにまたがったバケツの例を以下の図に⽰します。クラスタの複製データ保持数は 3、サーチ可能デー
タ保持数は 2 です。この場合、クラスタは 2 つのサーチ可能コピーを保持します。ここで、ソースピア上のバケ
ツのコピーはすべてプライマリ (そしてサーチ可能) になります。2 番⽬のサーチ可能コピーは、クラスタ内の残
りのピアにまたがって存在しています。
128
プライマリバケツコピーのセットは、次のセクションで説明するようにクラスタの世代を定義しています。
世代
世代 は、クラスタのバケツのどのコピーがプライマリでサーチに関与するのかを識別します。
注意： 実際にサーチ対象となるバケツのセットは、サーチの時間範囲などその他の要因によっても異なります。
このことは、インデクサーがクラスタ化されているかどうかに関係なく当てはまります。
世代は時間が経過し、ピアがクラスタから離脱/参加していくに伴って変化していきます。ピアが停⽌すると、そ
のプライマリバケツコピーは他のピアに割り当て直されます。マスターは他の特定の状況下でも、プライマリの再
割り当てを⾏います。その処理は、「クラスタの再調整」として知られています。
世代を定義する別の⽅法：世代は、クラスタの有効な 状態のスナップショットです。ここで、「有効」とは、ク
ラスタ内の各バケツが 1 つのプライマリコピーを保持していることを表しています。
現在マスターに登録されているすべてのピアが、現在の世代に参加します。ピアがクラスタに参加またはクラスタ
から離脱すると、マスターは新しい世代を作成します。
注意： 新しいバケツに優先度を再割り当てする処理は即座に完了するものではないため、ピアの停⽌などのイベ
ントにより、優先度の再割り当て処理中にクラスタの世代数が変化する可能性があります (特に、停⽌したピアに
多数のプライマリが保持されていた場合)。
世代はクラスタ全体の属性です。マルチサイトクラスタ内のすべてのサイトでその値は同じになります。
クラスタノードによる世代の使⽤⽅法
ここでは、各種クラスタノードが世代情報をどのように使⽤するのかについて説明していきます。
マスターはそれぞれの新しい世代を作成し、それに世代 ID を割り当てます。必要に応じて、ピアやサーチ
ヘッドと現在の世代 ID をやり取りします。また、各世代のプライマリバケツのコピーおよびそれがどのピ
アに存在しているのかも追跡しています。
ピアは、どのバケツのコピーが各世代のプライマリなのかを追跡しています。ピアは複数世代にまたがって
優先度情報を保持しています。
各サーチでサーチヘッドはマスターから取得した世代 ID を使って、サーチ対象ピアを判断します。
世代の変更時期
世代は以下の状況下で変更されます。
マスターがオンラインになった。
ピアがクラスタに参加した。
ピアが意図的 (CLI の offline コマンド) または偶発的 (障害発⽣) に停⽌した。ピアが停⽌した場合、マス
ターは停⽌したノードのバケツのプライマリコピーの代わりに、残りのノード上にある同じバケツのサーチ
129
可能コピーをプライマリに割り当て直し、新しい世代を作成します。
マスター上で⼿動で REST エンドポイント rebalance_primaries を使⽤したなど、プライマリコピーの再調整
が⾏われた場合。再調整の詳細は、「インデクサークラスタのプライマリバケツの再調整」を参照してくだ
さい。
マスターは、バケツがホットからウォームに移⾏する場合には新たな世代を作成しません。そのため、新しいホッ
トバケツが作成されます (バケツが前述の理由により移⾏された場合を除く)。そのような状況では、⼀連のピアは
変更されません。サーチヘッドは、どのピアがその世代に属しているのか (どのピアが現在クラスタに参加してい
るのか) だけを知る必要があります。特定のピア上のどのバケツのコピーがプライマリであるかを知る必要はあり
ません。この情報はピア⾃体が管理しています。
サーチにおける世代の使⽤⽅法
サーチヘッドは定期的に、マスターに最新の世代情報を問い合わせます。世代が変更されると、マスターはサーチ
ヘッドに新しい世代 ID とその世代に属するピアのリストを通知します。各サーチヘッドは、サーチ実⾏時にピア
にその ID を渡します。ピアはその ID を使って、サーチのプライマリバケツを判別します。
⼀般的に、サーチは最新世代のプライマリバケツコピーを使って⾏われます。ただし、⻑時間にわたって実⾏され
るサーチの場合、前の世代にまたがってサーチが⾏われることもあります。⼀般的にこのような状況は、サーチ途
中にピアが停⽌したことが原因で発⽣します。これにより、⼀部のデータが失われている場合でも (停⽌ピアノー
ドによる)、⻑時間にわたるサーチを完了することができます。必要に応じて⼿動で再び代替サーチを実⾏するこ
ともできます。
ピアの停⽌により世代が変更される理由
ピアの停⽌により、マスターが新たな世代を作成する理由は、ピアの停⽌時にマスターは停⽌したピアのプライマ
リコピーの代わりとなる、他のピアのコピーをプライマリとして割り当て直すためです。以前の世代でプライマリ
でなかったコピーが、新しい世代のプライマリになります。サーチに関連する世代 ID を知ることで、ピアはその
サーチのプライマリであるバケツを判断することができます。
たとえば以下の図は、すべてのプライマリコピーを保持するソースノードが停⽌して、マスターが残りのピアにバ
ケツの修復を指⽰した後の、以前と同じ簡素化版のクラスタを表しています。まず、マスターノードは優先度を、
各バケツの残りのサーチ可能コピーに割り当て直します。次に、マスターノードは失われたサーチ可能コピーを補
うために、サーチ不可能コピーをサーチ可能コピーに変換するようにピアに指⽰します。最後にマスターは、新た
なサーチ不可能コピーセット (1D、2D など) を複製し、残りのピアに分散させることを指⽰します。
ソースノードが停⽌しても、合計バケツコピー数の複製データ保持数 (3) と合計サーチ可能バケツコピー数のサー
チ可能データ保持数、および各バケツの 1 つのプライマリコピーにより、クラスタは完全 状態と有効 状態の両⽅
を復元することができます。この図では、プライマリコピーが別のピアに移動されているため、前の図とは世代が
異なっていることが分かります。
注意： この図には、ある 1 台のピアからのバケツのみが表⽰されています。この図を詳細に記述すると、複数の
ピアから転送されたさまざまなバケツが表⽰されることになります。
クラスタによるフローズンバケツの取り扱い
130
スタンドアロン型インデクサーの場合、バケツがフローズンに移⾏すると、インデクサーは colddb ディレクトリ
からバケツを削除します。リタイアポリシーによっては、インデクサーは削除前にそのコピーをアーカイブディレ
クトリに写します。「インデックス作成されたデータのアーカイブ」を参照してください。
インデクサークラスタの場合、バケツのあるピアのコピーのうちフローズンバケツの削除が必要になります。アー
カイブは任意です。ピアはリタイアポリシーに異なりがあるため、バケツはコピー間でフリーズしていない場合も
あります。コピーがフリーズされる不必要なバケツの処理を防ぐため、各ピアはバケツのフリーズの時期をマス
ターに知らせます。
マスターが特定のバケツの初のフリーズ指⽰を受け取ったら、バケツがフリーズするという表⽰の為にフラグをた
てて、それから他のピアにはバケツがフリーズする旨をアラートします。各ピアは、必要に応じてアーカイブさ
れ、バケツのコピーはリタイアポリシーにしたがって削除されます。コピーがすべてクラスタから削除されたら、
マスターは⼀覧からバケツを削除します。
インデクサークラスタの状態
正常に動作、機能しているインデクサークラスタは、「有効 」で「完全 」な状態です。
「有効 」なクラスタには、各バケツに 1 つのプライマリ コピーが存在しています。マルチサイトクラスタ
の場合、有効なクラスタはサーチアフィニティを満たしている各サイトのプライマリコピーの完全なセット
を保有しています。
「完全 」なクラスタには、各バケツの複製データ保持数 だけのコピーが存在しており、また各バケツに対
してサーチ可能データ保持数 だけのサーチ可能 コピーを保有しています。マルチサイトクラスタの場合、
バケツコピー数はサイト固有の複製データ保持数とサーチ可能データ保持数の要件も満たす必要がありま
す。
以下の事項に注意してください。
有効なクラスタは、データセット全体に対してサーチリクエストを処理することができます。有効なマルチ
サイトクラスタは、サーチアフィニティ特有の条件も満たしています。
完全クラスタは、障害対策の点で指定された要件を満たしています。
完全クラスタは、有効なクラスタでもありますが、有効なクラスタは完全クラスタではないこともありま
す。
また、堅牢なデータ可⽤性を実現するために、クラスタは完全状態なだけでなく、サーチ可能データ保持数も 2
以上に設定する必要があります。そうすることにより、ピアが停⽌した場合でも中断することなく、クラスタにま
たがってサーチを継続することができます。
ピアノードが停⽌した場合、マスターはクラスタの有効な状態と完全な状態を復元するための作業を指⽰します。
クラスタを有効な状態に戻すことはできても、完全な状態に戻すことはできない場合があります。(たとえば、3
台のピアを持つクラスタで複製データ保持数が 3 の場合を考えてみましょう。1 台のピアが停⽌すると、ピアが
再稼働しない限りクラスタを完全状態に回復することはできません。ただし、有効状態に復帰することは可能で
す。)ノード停⽌時のクラスタの復旧処理については、「ピアノード停⽌時の処理」を参照してください。
クラスタでのインデックス作成の仕組み
インデックス作成時のノード間のデータとメッセージの流れを理解する場合、ピアノードが果たしている 2 つの
役割を明確に区別することが役⽴ちます。
ソースノード： ソースノードは、フォワーダーまたは他のソースからデータを取り込みます。
ターゲットノード： ターゲットノードは、複製されたデータのストリームをソースノードから受信しま
す。
実際には、1 台のピアがソースノードとターゲットノードの両⽅として (しばしば同時に) 機能します。
重要： ⼀般的なインデクサークラスタのデプロイ環境では、すべてのピアノードがソースノードとなります (各
ノードが独⾃の外部⼊⼒を保有している)。これは必要条件ではありませんが、⼀般的には最善の⽅法です。⼀部
のピアをターゲットノード専⽤として保有することに、何も意義はありません。複製データ保管の処理コストはと
ても⼩さく、また現在のところ複製データを受信するノードを指定することはできません。受信ノードはマスター
がバケツ単位に決定し、その動作を設定することはできません。すべてのピアノードがターゲットとしての役割も
果たすことに留意してください。
注意： 外部データの複製に加えて、各ピアはその内部インデックスも他のピアに同様の⽅法で複製します。簡単
にするため、ここでは外部データのみを取り上げていきます。
ターゲットピアの選択⽅法
ソースピアがホットバケツを開始すれば、マスターノードは複製データを流すターゲットピアを⼀覧にします。⼀
覧はバケツごとにまとめられています。ソースピアが複数のホットバケツに書き込みをしている場合、各バケツの
コンテンツを別のターゲットピアに流している可能性があります。
マスターは、ターゲットピアの⼀覧をランダムで選択します。マルチサイトクラスタリングの場合、複製データ保
持数によってサイト境界を踏まえますが、これらの制約のなかで、ランダムでターゲットピアを選択します。
ピアノード起動時
これらのイベントは、ピアノードの起動時に発⽣します。
1. ピアノードはマスターに登録して、マスターから最新の設定バンドル を受け取ります。
131
2. マスターは、クラスタのプライマリ バケツを再調整し、新しい世代を開始します。
3. ピアは他のインデクサーと同様に、外部データの取り込みを開始します。ピアはデータを処理してイベントに
し、それを raw データファイルに追加します。また、関連するインデックスファイルも作成します。これらの
ファイル (raw データとインデックスファイルの両⽅) はローカルのホットバケツに保管されます。これがバケツ
のプライマリコピーになります。
4. マスターは、ピアにその複製データのターゲットピアのリストを渡します。たとえば、複製データ保持数が 3
の場合、マスターは 2 台のターゲットピアのリストを渡します。
5. サーチ可能データ保持数が 2 以上の場合、マスターはピアに、データのコピーをサーチ可能 にするターゲット
ピアも指⽰します。たとえば、サーチ可能データ保持数が 2 の場合、マスターはコピーをサーチ可能にする 1 台
のターゲットピアを選出し、その情報をソースピアに伝えます。
6. ピアは、マスターが指⽰したターゲットピアへの、処理済み raw データの転送を開始します。ピアは、raw
データファイル全体の処理が完了するまで転送を開始しないのではなく、処理済みのデータをブロック単位で転送
していきます。また、ステップ 5 でマスターが通信したターゲットピアが、そのコピーをサーチ可能にする必要
がある場合は、その旨も伝えます。
7. ソースピアから raw データを受信したターゲットピアは、それをローカルのバケツコピーに保管します。
8. サーチ可能コピーの作成を指⽰されたターゲットは、必要なインデックスファイルの⽣成を開始します。
9. ピアはそのホットバケツを移⾏するまでの間、ターゲットへのデータ転送を継続します。
注意： ソースピアとターゲットピアが、管理⽤ポート経由で相互に通信することはほとんどありません。通常は
複製ポート経由で単純にデータを送受信します。マスターノードはそのプロセス全体を管理しています。
これは、単に 1 台のピアにおけるデータの流れです。クラスタ内では、複数のピアが常時相互にデータを送受信
します。
ピアノードのホットバケツの移⾏時期
ソースピアがホットバケツをウォームバケツに移⾏する場合 (たとえば、バケツが最⼤サイズに達したため)、以下
の⼀連のイベントが発⽣します。
1. ソースピアはマスターおよびターゲットピアに、バケツを移⾏することを伝えます。
2. ターゲットピアは各⾃のバケツのコピーを移⾏します。
3. ソースピアはこの間にも、外部データの取り込みを継続しています。新しいホットバケツ内にローカルにデータ
のインデックスを作成し、raw データを、マスターから取得した新たなターゲットピアセットに転送します。
4. ソースピアから新しいホットバケツの raw データを受信したターゲットピアは、それをローカルのバケツコ
ピーに保管します。サーチ可能コピーの作成を指⽰されたターゲットは、必要なインデックスファイルの作成も開
始します。
5. ソースピアは次のホットバケツを移⾏するまでの間、ターゲットへのデータ転送を継続します。以降も同様の処
理が⾏われます。
ピアノードとフォワーダーのやり取り
ピアノードがフォワーダーからデータを取得すると、フォワーダーからのデータを受け取る他のインデクサーと同
様に処理が⾏われます。ただし、⼀般的にクラスタリング環境では、ピアにデータを送信する各フォワーダー上
でインデクサー応答確認 を有効にする必要があります。こうすることによって、フォワーダーとピア間でデータ
が失われることを防⽌できます。また、これが終端間のデータ忠実度を確保する唯⼀の⽅法です。フォワーダーが
ピアに送信したデータブロックに対する確認応答を受信しなかった場合、そのブロックが再送信されます。
フォワーダーのピアへのデータ送信の設定⽅法の詳細は、「フォワーダーを使ったインデクサークラスタへのデー
タの取り込み」を参照してください。ピアとフォワーダーがインデクサー応答確認をどのように処理しているかに
ついては、「インデクサー応答確認の仕組み」を参照してください。
インデクサークラスタでのサーチの仕組み
単⼀サイト・インデクサー・クラスタの場合、サーチヘッドは⼀連のピア全体に対してサーチを実⾏します。
マルチサイト・インデクサー・クラスタの場合は、サーチアフィニティ を導⼊することができます。サーチア
フィニティを導⼊すると、サーチはサーチヘッドが存在しているサイトのピアに対して実⾏されます。そうするこ
とによって、クラスタデータの完全なセットへのアクセスを失うことなく、ネットワーク効率を向上することがで
きます。
後述するようにまれな状況下では、1 台のピア上でサーチを実⾏することができます。
単⼀サイトクラスタのサーチ
インデクサークラスタに対するサーチの仕組みは、⾮クラスタ構成のインデクサーの分散サーチ とある意味似て
います。主な違いは、サーチヘッド がマスターノードからサーチピア のリストを取得することにあります。ま
た、世代 ID もマスターから取得します。その後は、ピアと直接通信を⾏います。
注意： インデクサークラスタのサーチで、サーチピアとは現在マスターに登録されている⼀連のクラスタピアの
ことです (稼働していてクラスタに参加しているピア)。
132
サーチヘッドがサーチを開始すると：
1. サーチヘッドはマスターノードと通信します。
2. マスターノードはサーチヘッドに現在の世代 ID およびその世代のピア (現在マスターに登録されているピア)
のリストを伝えます。
3. サーチヘッドは、インデクサークラスタが関与しない分散サーチと同じように、サーチピアと通信を⾏います。
ピアには完全に同じ情報 (サーチリクエストと複製バンドル) を提供しますが、それ以外に世代 ID もサーチピア
に提供します。
4. サーチピアは世代 ID を使って、各⾃が保有するその世代のプライマリ バケツコピーを判別し (ある場合)、そ
してサーチに参加する必要があるかどうかを判断します。他のサーチと同様に、ピアはサーチの時間範囲も使って
特定のバケツをサーチするかどうかを判断します。
5. サーチピアは、各⾃のバケツのプライマリコピーをサーチして、結果をサーチヘッドに渡します。サーチヘッド
はそれらの結果を統合します。
インデクサークラスタとサーチヘッドクラスタを統合して、サーチヘッドの拡張性と可⽤性を向上することができ
ます。『分散サーチ』マニュアルの、「サーチヘッドクラスタとインデクサークラスタの統合」を参照してくださ
い。
これらの機能、および分散サーチで利⽤できる他の機能については、『分散サーチ』マニュアルの「分散サーチに
ついて」を参照してください。また、インデクサークラスタ内でサーチヘッドを利⽤する場合の設定の違いについ
ては、このマニュアルの「サーチヘッドの設定」を参照してください。
マルチサイトクラスタでのローカルサーチ
マルチサイトクラスタでは、⼀般的に各サイトにサーチヘッドを配置します。そうすることによって、サーチア
フィニティの恩恵を受けられます。サーチアフィニティを導⼊すると、⼀般的にサーチは要求元のサーチヘッドが
存在しているサイトのピアに対してのみ実⾏されます。
マルチサイトクラスタでは、サーチアフィニティは常に有効になっています。ただし、それを有効活⽤するには、
いくつかの作業を実施する必要があります。特に、ローカルでサーチ可能データとサーチヘッドの両⽅が利⽤でき
るようにする必要があります。サーチアフィニティの設定⽅法については、「マルチサイト・インデクサー・クラ
スタへのサーチアフィニティの導⼊」を参照してください。
サイトのサーチアフィニティの設定が完了すると、実際のサーチ処理は単⼀サイトクラスタと同じように⾏われま
す。サーチヘッドは、クラスタ全体にまたがってすべてのピアに、現在の世代 ID、およびサーチおよび複製バン
ドルを配布します。ただし、応答はローカルピアのみが⾏います。ピアは各⾃のプライマリバケツをサーチして、
結果をサーチヘッドに返します。バケツコピーがプライマリかどうかの判断には、世代 ID が⽤いられます。
注意： 「クラスタでのインデックス作成の仕組み」で説明しているように、ホットバケツのデータはブロック単
位で複製されます。オリジナルのコピーが別のサイトにある、複製されたホットバケツのコピーがローカルサーチ
に関与している場合、ローカルピアがオリジナルを持つピアから最新のホットデータのブロックを取得するまで、
時間の遅延が発⽣することがあります。その間、サーチで最新のデータは返されません。
ローカルサイトで⼀部のピアが停⽌しており、サイトに完全なプライマリセットが存在しない場合は、リモートピ
アがサーチに参加して、そのサイトで失われているプライマリからの結果を提供します。この場合、データの完全
なセットへのアクセスを維持するために、サーチはサーチアフィニティを満たしていません。サイトが有効 な状
態に復旧すると、それ以降のサーチはサーチアフィニティを満たして⾏われます。
単⼀ピアのサーチ
デバッグ⽬的で、1 台のピアノードに対してのみサーチを⾏わなければならないこともあります。この場合は、そ
のピア上で直接サーチを⾏います。このサーチは、ピア上にある任意のサーチ可能 データにアクセスします。ピ
ア上のサーチ不可能データ、または他のピア上のサーチ可能データのコピーにアクセスすることはありません。
注意： 各ピア上でどのデータをサーチ可能にするかを設定する⽅法は存在しないことに注意してください。ただ
し最低でも、ピアからクラスタに取り込まれたデータはすべて、そのピア上でサーチ可能になります。
クラスタのレポートおよびデータモデル⾼速化サマリーの取扱⽅法
インデクサークラスタはレポート⾼速化 とデータモデル⾼速化 サマリーを複製しません。
これらのサマリーはピアに残り、各インデックスレベルディレクトリ下のディレクトリに保管されます。例えば、
「index1」インデックスは、$SPLUNK_HOME/var/lib/splunk/index1 に保管されます。レポート⾼速化サマリーディレ
クトリは summary と名前がつけられ、データモデル⾼速化サマリーディレクトリは datamodel_summary とつけられて
います。
サマリーの期間によっては、サマリーは 1 つ以上のバケツと相関性があります。サマリーが⽣成されると、その
期間バケツのプライマリコピーを持つピアに残ります。サマリーが複数のバケツに及び、これらのバケツのプライ
マリコピーが複数のピアに残る場合、各ピアはサマリーの対応する部分を保持します。
プライマリがバケツのコピーから別のコピーに再度割り当てられる場合 (例：ピアがプライマリコピーの保持に失
敗するため)、サマリーは新しいプライマリコピーのあるピアには移りません。そのため、利⽤ができません。次
回に Splunk Enterprise がサマリー更新レポートを実⾏し、サマリーが失われていることに気が付いて、サマ
リーを再⽣成するまでの間、サマリーは利⽤できなくなります。
マルチサイトクラスタでは、単⼀のサイトクラスタと同様に、サマリーがプライマリバケツコピーと残ります。マ
ルチサイトクラスタは複数のプライマリがあり、各サイトはサーチアフィニティをサポートしているため、サマ
リーはサーチ実⾏時に利⽤可能なサーチヘッドを⽣成する特定のプライマリと残ります。サイトアフィニティのた
めに、サマリーは⽣成されるサーチヘッドと同じサイトのプライマリに残ります。
133
インデクサー・クラスタ・ノードの起動⽅法
このトピックは、以下の場合にどのような処理が⾏われるのかを説明しています。
マスターノードの開始時
ピアが新しいクラスタに参加した場合
ピアが既存のクラスタに参加した場合
マスターノードの開始時
マスターノードがオンラインになると (初回またはそれ以降)、クラスタピアの待機を開始します。オンラインに
なっているピアはマスターに登録します。マスターは、それらのピアをクラスタに追加します。マスターは複製
データ保持数に等しい台数のピアが登録されるまで待ち、その後クラスタの実⾏を開始します。
初めてクラスタをデプロイする場合 、まずマスターを有効にしてから、次にピアノードを有効にする必要があり
ます。「インデクサークラスタのデプロイの概要」を参照してください。マスターは、複製データ保持数と同じ台
数のピアが有効になり再起動されるまで、ピアのインデックス作成をブロックします。
その後マスターを再起動すると 、60 秒の間ピアの登録のために待機します。この期間が過ぎて、複製データ保
持数以上のピアが登録された場合、マスターはクラスタとして動作するために、プライマリ バケツコピーの再調
整および取り込んだデータのコピーの転送先の指⽰などの、ピアの調整を開始します。そのため、マスターを再起
動する場合は、複製データ保持数以上のピアが稼働していることを確認してください。
最初の 60 秒間が経過すると、[マスター] ダッシュボードでクラスタのステータスを確認することができます。
マスターの停⽌および再起動時にどのような処理が⾏われるかについては、「マスターノード停⽌時の処理」を参
照してください。
ピアが新しいクラスタに参加した場合
初めてクラスタをデプロイする場合は、まずマスターを有効にしてから、次にピアノードを有効にする必要があり
ます。「インデクサークラスタのデプロイの概要」を参照してください。マスターは、複製データ保持数と同じ台
数のピアが有効になり再起動されるまで、ピアのインデックス作成をブロックします。
各ピアはオンラインになるとマスターに登録します。マスターは、そのピアに最新の設定バンドル を⾃動的に配
布します。次にピアはローカルに設定ファイルを検証します。バンドルの検証が正常に完了した場合にのみ、ピア
はクラスタに参加します。
クラスタに複製データ保持数以上のピアが参加したら、ピアはデータのインデックス作成を開始します。
ピアが既存のクラスタに参加した場合
ピアは後ほど、すでにマスターと複製データ保持数の台数のピアが稼働し、クラスタが機能するようになってか
ら、オンラインにすることもできます。ピアをオンラインにすると、そのピアはマスターに登録します。マスター
は、そのピアに最新の設定バンドルを配布します。ピアはローカルに設定ファイルを検証します。バンドルの検証
が正常に完了した場合にのみ、ピアはクラスタに参加します。
注意： 既存のクラスタに新しいピアを追加すると、「インデクサークラスタのプライマリバケツの再調整」で説
明しているように、既存のピアノードのプライマリバケツコピーの再調整が⾏われます。ただし、新しいピアがそ
れらのプライマリコピーを受け取ることはありません。再調整は⼀連のサーチ可能コピーに対してのみ⾏われます
が、新しいピアの起動時にそのピアはサーチ可能コピーを持っていないためです。新しいピアは今後のバケツ複製
に参加しますが、マスターが既存のピアから新しいピアにバケツのコピーの移動やプライマリの再割り当てを指⽰
することはありません。
ピアノード停⽌時の処理
ピアノードは意図的に (「ピアをオフラインにする」に記述されているように CLI の
⽌、または意図せずに (サーバークラッシュなど) 停⽌することがあります。
offline
コマンドを使⽤) 停
ピアがどのように停⽌した場合でも、マスターが復旧措置を指⽰して代わりのバケツコピーを配置します。このプ
ロセスは、バケツの修復 と呼ばれています。マスターは、各ノード上に保管されているバケツのコピーおよびそ
の状態 (優先度 、サーチの可否 ) を追跡しています。あるピアが停⽌すると、マスターはクラスタを以下の状態に
回復する⽬的で、残りのピアにバケツセットの修復を指⽰できます。
各バケツのプライマリ コピーが正確に 1 つ存在している (有効 な状態)。マルチサイトクラスタの場合、有
効な状態とは、site_search_factor に基づいてサーチアフィニティを満たしている各サイトにプライマリコ
ピーが存在していることです。
各バケツのサーチ可能 コピーのフルセットが、サーチ可能データ保持数と⼀致している。マルチサイトクラ
スタの場合、サーチ可能バケツコピー数はサイト固有のサーチ可能データ保持数の要件も満たす必要があり
ます。
各バケツのコピーのフルセット (サーチ可能およびサーチ不可能の両⽅) が、複製データ保持数と⼀致してい
る (完全 状態)。マルチサイトクラスタの場合、バケツコピー数はサイト固有の複製データ保持数の要件も満
たす必要があります。
通常は複数ノードに致命的な障害が発⽣しなければ、マスターは有効なクラスタを再作成することができます。ク
ラスタ (またはマルチサイトクラスタ内のサイト) のサーチ可能データ保持数が 2 以上の場合は、ほぼ即座にその
作業を完了できます。マスターが完全クラスタを再構築できるかどうかは、複製データ保持数以上のピアが引き続
き稼働しているかどうかによって決まります。最低でも複製データ保持数と同じ数のピアが動作していないと、ク
ラスタを完全状態に復帰させることはできません。マルチサイトクラスタの場合、各サイトには最低でもサイトの
複製データ保持数に指定されている台数のピアが利⽤できる状態でなければなりません。
134
クラスタが完全状態に戻るまでには⾮常に時間がかかることがあります (最初にあるピアから他のピアにバケツを
転送し、バケツのサーチ不可能コピーをサーチ可能にする必要があるため)。詳細は、「ピアオフライン時のクラ
スタ復旧時間の⾒積もり」を参照してください。
ノードの停⽌時には、バケツ修復の復旧措置のほかにも、いくつかの主要イベントが発⽣します。
マスターは新たな世代 に移⾏して、新しい世代 ID を作成します。世代 ID は必要に応じてピアやサーチ
ヘッドに通知します。
停⽌したノードのホットバケツのコピーを保有するピアは、それらのコピーをウォームに移⾏します。
ピアノードを意図的にオフラインにした場合
コマンドは、クラスタからピアを削除して、次にピアを停⽌します。この場合、処理中のサーチを完了
し、クラスタを完全なサーチ可能状態に素早く戻せるように、順次処理を⾏いながらピアを正常に停⽌します。
offline
注意： ピアはサーチ実⾏中または復旧処理中の場合でも、最⼤で 5〜10 分後に停⽌します。
ピアをオフラインにする基本的な⽅法については、「ピアをオフラインにする」を参照してください。
offline コマンド
offline
コマンドは次の構⽂があります：
splunk offline
このコマンドは、以下の⼀連の処理を実⾏します。
1. 部分シャットダウン。 ピアは即座に部分シャットダウンを⾏います。ピアは外部⼊⼒および複製データの受け
付けを停⽌します。ただし、サーチ処理は継続します。
2. 優先度再割り当て。 マスターは、ピア上の任意のプライマリバケツコピーの優先度を、他のピア (マルチサイ
トクラスタの場合、同じサイト内のピア) 上のそれらのバケツのサーチ可能コピーに割り当て直します。このス
テップの最後には、クラスタ (またはクラスタのサイト) が有効状態に復帰します。サーチ可能データ保持数が 2
以上の場合、この処理はあっという間に完了します。このステップの間、ピアのステータスは ReassigningPrimaries
になります。
3. 世代 ID の変更。 マスターはクラスタの世代 ID を変更します。このステップの最後には、ピアは新しいサー
チに参加しなくなりますが、引き続き処理中のサーチには関与します。
4. 完全シャットダウン。 ピアは最⼤で 5〜10 分後または処理中のサーチおよび優先度の再割り当て処理が完了
した場合に (どちらかが先に発⽣した時点で)、完全にシャットダウンされます。また、マスターへのハートビート
の送信を中⽌します。
5. 再起動カウント。 ピアのシャットダウン後、マスターは server.conf に設定されている restart_timeout の期間
(デフォルトは 60 秒) 待機します。この期間内にピアがオンラインに復帰したら、マスターは⼀連のプライマリバ
ケツのコピーを再調整しますが、その他の修復処理は⾏いません。このステップの間、ピアのステータスは
Restarting になります。ピアがタイムアウト期間内に復帰しなかった場合は、そのステータスが Down に変化しま
す。
6. 復旧処理。 ピアが restart_timeout に指定されている期間内に再起動されなかった場合、マスターはクラスタバ
ケツの修復処理を開始します。残りのピアに対して、停⽌するピア上にあったバケツのコピーを複製するように指
⽰します。また、停⽌するピアのバケツのサーチ可能コピーの代わりとなるように、それらのバケツの他のピア上
のサーチ不可能コピーをサーチ可能コピーに変換することも指⽰します。このステップの最後には、クラスタが完
全状態に戻ります。ピアの停⽌により複製データ保持数未満のピアしか稼働していない場合は、このステップを完
了して完全クラスタに戻ることができません。バケツ修復処理の詳細は、「バケツ修復のシナリオ」を参照してく
ださい。
マルチサイトクラスタの場合、復旧処理はオフラインピアと同じサイト内で⾏われます (可能な場合)。詳細は、
「マルチサイトクラスタでのバケツ修復」を参照してください。
予期せずにピアノードが停⽌した場合
コマンド実⾏以外の何らかの理由でピアノードが停⽌した場合、マスターへの定期的なハートビート送信
が中断します。マスターはこれによりノード停⽌を検出し、復旧措置を開始します。基本的にマスターは、ピアを
意図的に停⽌する場合と同じ処理を指⽰しますが、以下の例外があります。
offline
停⽌したピアは、処理中のサーチには参加しません。
マスターはハートビートタイムアウトの時間 (デフォルトは 60 秒) だけ待機して、その後優先度の再割り当
てとバケツの修復処理を開始します。
ノードが停⽌してもクラスタにまたがってサーチは継続されますが、クラスタが有効な状態に回復するまでの間
は、部分的な結果しか表⽰されません。
マルチサイトクラスタの場合、あるサイトでピアが停⽌すると、有効な状態に復帰するまでの間そのサイトのサー
チアフィニティは失われます (あった場合)。それまでの間は、リモートピアがサーチに参加して、完全な結果を返
し続けます。
バケツ修復のシナリオ
停⽌したピアのバケツコピーを置換するために、マスターはピア間のバケツ修復処理を調整します。すべてのバケ
135
ツコピーを置換するだけでなく、クラスタはすべてのプライマリコピーとサーチ可能コピーを補っている必要があ
ります。
バケツ修復には 3 種類の作業が関与しています。
停⽌したピアのバケツに対応する、他のピア上のサーチ可能コピーにプライマリステータスを割り当て
て、停⽌したピアのすべてのプライマリコピーを回復する (置換する) 。
他のピアのサーチ不可コピーをサーチ可能に変換して、サーチ可能コピーを回復する 。
各バケツのコピーをまだそのバケツを保有していないピアに配布して、すべてのバケツコピー (サーチ可
能およびサーチ不可) を置換する 。
たとえば、停⽌したピアが 10 個のバケツコピーを保有しており、その 5 個がサーチ可能で、サーチ可能コピー
の中の 2 個がプライスマリだった場合を考えてみましょう。クラスタは以下の処理を実施する必要があります。
2 個のサーチ可能コピーのプライマリステータスを、他のピアのサーチ可能コピーに再割り当てする。
他のピア上の 5 個のサーチ不可バケツコピーを、サーチ可能に変換する。
10 個のバケツコピーを、ある稼働中のピアから別の稼働中のピアに配布する。
最初の処理となる、バケツのサーチ可コピーの、⾮プライマリからプライマリへの変換は即座に⾏われます。サー
チ可バケツのコピーにはすでにインデックスファイルが存在しているため、実質的にはほとんど何の処理も⾏われ
ません。(予備のサーチ可能コピーがあることを前提にしています。そのためには、サーチ可能データ保持数が 2
以上でなければなりません。そうでない場合、クラスタはまずサーチ不可能コピーをサーチ可能コピーに変換し
て、そのコピーにプライマリのステータスを割り当てます。)
2 番⽬の処理となる、バケツのサーチ不可コピーのサーチ可能コピーへの変換には少し時間がかかります。サーチ
不可コピーを持つピアは、他のピアのサーチ可能コピーからバケツのインデックスファイルをコピーする必要があ
るためです (そのバケツのサーチ可能コピーがない場合は、raw データファイルからバケツのインデックスファイ
ルを再構築する必要があります)。サーチ不可能コピーをサーチ可能に変換するためにかかる時間の⾒積もり⽅法
については、「ピアオフライン時のクラスタ復旧時間の⾒積もり」を参照してください。
3 番⽬の処理となる、あるピアから他のピアへのコピーの配布も、かなり時間がかかる可能性があります (配布す
るデータ量による)。詳細は、「ピアオフライン時のクラスタ復旧時間の⾒積もり」を参照してください。
以下の 2 つの例は、マスターによる 1) 有効で完全なクラスタの再作成、および 2) 有効だけれども不完全なクラ
スタの作成 (残りノード数が不⼗分な場合) を表しています。このプロセスは、ピアを意図的に停⽌した場合で
も、ピアが意図せずに停⽌した場合でも同じです。
以下の事項を忘れないようにしてください。
クラスタは、各バケツのサーチ可能コピーが 1 つ存在している場合に「有効」となります。有効なクラスタ
に対するサーチでは、完全なサーチ結果が返されます。
クラスタに、複製データ保持数と同数のバケツのコピー、およびサーチ可能データ保持数と同数のサーチ可
能コピーが存在している場合、そのクラスタは「完全」です。
すべてのバケツのサーチ可能コピーが存在しているけれども、複製データ保持数よりも少ない数のバケツコ
ピーしか存在していない場合、クラスタは有効だけれども不完全になります。そのため、複製データ保持数
が 3 で 3 台のピアノードしか存在していないクラスタで、いずれかのピアが停⽌した場合、クラスタを有効
な状態にすることは可能ですが、2 台のノードしか稼働していないため完全な状態にすることはできません
(複製データ保持数に指定されている 3 つのバケツコピーを維持できないため)。
例：バケツの修復による有効で完全なクラスタの作成
前提：
ピアが突然に停⽌した (offline コマンドを実⾏した結果ではない)。
停⽌したピアは、以下のようなクラスタのメンバーだった。
停⽌したピアを含めて 5 台のピアが存在
複製データ保持数 = 3
サーチ可能データ保持数 = 2
停⽌したピアは以下のようなバケツコピーを保有していた。
バケツのプライマリコピー数は 3
サーチ可能コピー数は 10 (プライマリコピーを含む)
合計バケツコピー数は 20 (サーチ可能およびサーチ不可能を含む)
ピアが停⽌すると、マスターは以下のように、残りのピアに対してさまざまなメッセージを送信します。
1. 停⽌ピアの 3 個のプライマリコピーのそれぞれに対して、マスターは当該バケツのサーチ可能コピーを保有す
る他のピアを探し、そのピアに対して保有するコピーをプライマリにするように指⽰します。
このステップが完了すると、クラスタは有効状態に復帰し、それ以降のサーチに対しては完全な結果セットを返せ
るようになります。
2. 停⽌ピアの 10 個のサーチ可能バケツコピーのそれぞれに対して、マスターは 1) 当該バケツのサーチ可能コ
ピーを保有するピアを探します、および 2) 同じバケツのサーチ不可能コピーを持つピアを探します。次に、サー
チ可能コピーを持つピアに対して、バケツのインデックスファイルを 2 番⽬のピアに配信するように指⽰しま
す。インデックスファイルのコピーが完了すると、サーチ不可能コピーがサーチ可能コピーになります。
3. 3. 停⽌ノードの合計 20 個のバケツのコピーそれぞれに対して、マスターは 1) そのバケツのコピーを保有する
ピアおよび 2) そのバケツのコピーを保有していないピアを探します。次に、コピーを持つピアに、バケツの raw
データを 2 番⽬のピアに配信するように指⽰します。その結果、そのバケツの新しいサーチ不可コピーが作成さ
れます。
この最後のステップが完了すると、クラスタは完全状態に復帰します。
136
例：バケツの修復による有効だが不完全なクラスタの作成
前提：
ピアが突然に停⽌した (offline コマンドを実⾏した結果ではない)。
停⽌したピアは、以下のようなクラスタのメンバーであった。
停⽌したピアを含めて 3 台のピアが存在
複製データ保持数 = 3
サーチ可能データ保持数 = 1
停⽌したピアは以下のようなバケツコピーを保有していた。
バケツのプライマリコピー数は 5
5 個のサーチ可能コピー (プライマリコピー数と同じ、サーチ可能データ保持数 = 1 のため、すべての
サーチ可能コピーがプライマリにもなる必要がある)
合計バケツコピー数は 20 (サーチ可能およびサーチ不可能を含む)
クラスタには 3 台しかピアがなく、複製データ保持数が 3 のため、あるピアが停⽌すると複製データ保持数の要
件を満たすことができません。そのため、クラスタを完全状態に復帰することはできません。
ピアが停⽌すると、マスターは以下のように、残りのピアに対してさまざまなメッセージを送信します。
1. 停⽌ノードの 10 個のサーチ可コピーのそれぞれに対して、マスターはまず当該バケツのサーチ不可コピーを保
有する他のピアを探し、そのピアに対して保有するコピーをサーチ可にするように指⽰します。そのピアは、その
コピーのインデックスファイルの作成を開始します。(サーチ可能データ保持数が 1 なので、残りのノード上にこ
れらのバケツのその他のサーチ可能コピーはありません。そのため、残りのピアが他のサーチ可能コピーからイン
デックスファイルを取得して、サーチ不可のバケツコピーをサーチ可能にすることはできません。代わりに、サー
チ不可能コピーの raw データからインデックスファイルを作成する、時間がかかる作業を⾏う必要があります。)
2. 次にマスターはステップ 1 のピアに、5 個の新しいサーチ可能コピーをプライマリにするように指⽰します。
前の例とは違い、サーチ不可コピーをサーチ可コピーに変換しないと、他のバケツのコピーをプライマリとして指
定することはできません。クラスタのサーチ可能データ保持数が 1 のため、スタンバイしているサーチ可能コ
ピーがないためです。
ステップ 2 が完了すると、クラスタは有効な状態に戻ります。これ以降のサーチでは、完全な結果セットが返さ
れます。
3. 停⽌したノード上の 20 個のバケツコピーについては、コピーを保持するために⼗分な数のノードが残っていな
いため、マスターが代替コピーを作成するための処理を開始する (複製データ保持数に指定されているように、ク
ラスタに各バケツの 3 個のコピーを保有する) ことはできません。
クラスタは複製データ保持数に相当する完全なバケツコピーのセットを作成できないため、クラスタは不完全な状
態となります。
画像
5 台のピアを持つクラスタで、複製データ保持数が 3、サーチ可能データ保持数が 2 の例を以下の図に⽰しま
す。プライマリバケツのコピーはフォワーダーからデータを受信するソースピアに存在しており、そのデータの
サーチ可能コピーとサーチ不可能コピーが、他のピアに分散しています。
137
注意： この図は⼤幅に単純化されています。分かりやすいように、この図ではある 1 台のピアが保有するデータ
のバケツのみを表しています。実際の環境では、すべてではないですが、その他のピアもデータの送信元となり、
それをクラスタ内の他のピアに複製します。
以下の図は、すべてのプライマリコピーを保持するソースノードが停⽌して、マスターが残りのピアにバケツの修
復を指⽰した後の、前と同じように単純化されたクラスタを表しています。
マスターは、停⽌したピアのバケツを回復するために、クラスタにさまざまな作業を指⽰します。
1. マスターは停⽌ピア上のバケツのコピーの優先度を、残りのピア上にあるサーチ可能コピーに割り当て直しま
す。このステップが完了すると、世代 ID が変更されます。
138
2. マスターはピアに対して、サーチ不可能コピーセットをサーチ可能に変換して、失われたサーチ可能コピーを補
完するように指⽰します。
3. マスターは、新たなサーチ不可能コピーセット (1D、2D など) を複製し、残りのピアに分散させることを指⽰
します。
ソースノードが停⽌しても、合計バケツ数の複製データ保持数と合計サーチ可能バケツ数のサーチ可能データ保持
数、および各バケツに対するそれぞれ 1 つのプライマリコピーにより、クラスタは完全状態と有効状態の両⽅を
復元することができます。この図では、プライマリコピーが別のピアに移動されているため、前の図とは世代が異
なっていることが分かります。
マルチサイトクラスタのバケツ修復
マルチサイトクラスタでのノード障害への対処⽅法は⼀部単⼀サイトクラスタの場合とは⼤きく異なっています。
「マルチサイトクラスタとノード障害」を参照してください。
バケツ修復ステータスの表⽰
[マスター] ダッシュボードから、バケツ修復のステータスを表⽰することができます。「[マスター] ダッシュボー
ドを有効にする」を参照してください。
ピアノードが復帰した場合の処理
ピアノードは意図的 (CLI の offline コマンド) に、または偶発的 (サーバークラッシュなど) に停⽌することがあ
ります。ピアが停⽌すると、「ピアノード停⽌時の処理」で説明しているように、バケツの修復 と呼ばれるクラ
スタの復旧処理が⾏われます。現在ご覧のトピックでは、ピアがその後クラスタに復帰した場合にどのような処理
が⾏われるのかについて説明していきます。
ピアが復帰すると、マスターへのハートビート送信を開始します。マスターはそれを認識すると、ピアをクラスタ
に追加します。前にクラスタに参加していた場合と同じ完全なバケツのコピーをピアが保有している場合、マス
ターはそれらのコピーを管理対象バケツ数に追加します。マスターはクラスタの再調整も⾏います。その結果、ピ
ア上のサーチ可能バケツコピーがある場合、それにプライマリ ステータスが割り当てられることがあります。再
調整の詳細は、「インデクサークラスタのプライマリバケツの再調整」を参照してください。
注意： ピアはマスターに接続すると、最新版の設定バンドル を保有しているかどうかを確認します。ピアの停⽌
中にバンドルが更新された場合は、最新版の設定バンドルをダウンロードして、それをローカルに検証し、再起動
します。バンドルの検証が正常に完了した場合にのみ、ピアはクラスタに再参加します。
マスターのバケツのカウント⽅法
ピアがクラスタに復帰した場合に何が起きるのかを理解するために、まずマスターがバケツのコピーをどのように
追跡しているのかを理解する必要があります。
マスターは、クラスタ内の各バケツの数を管理しています。マスターは、各バケツに対する、以下の情報を保有し
ています。
クラスタ内に存在しているバケツのコピー数。
クラスタ内に存在しているバケツのサーチ可能 コピー数。
またマスターは、特定のバケツのプライマリ コピーが常に 1 つだけ存在するように制御しています。
マルチサイトクラスタでは、マスターは各サイトのコピーとサーチ可能コピー、およびクラスタ全体を追跡管理す
ることができます。また、明⽰的にサーチ可能データ保持数が指定されている各サイトは、各バケツのプライマリ
コピーを正確に 1 つ保有することが保証されます。
マスターは、これらのカウントにより、クラスタが有効 で完全 であるかを判断します。単⼀サイトクラスタの場
合、これはクラスタが以下の条件を満たしていることを意味しています。
各バケツのプライマリコピーが 1 つずつのみ存在している。
各バケツのサーチ可能コピーのフルセットが、サーチ可能データ保持数と⼀致している。
各バケツのコピーのフルセット (サーチ可能およびサーチ不可能) が、複製データ保持数と⼀致している。
マルチサイトクラスタの場合、有効で完全なクラスタは以下の条件を満たしています。
明⽰的にサーチ可能データ保持数が指定されている各サイトが、各バケツのプライマリコピーを正確に 1 つ
保持している。
各サイトのサーチ可能データ保持数とクラスタ全体の合計を満たす、各バケツのサーチ可能コピーの完全な
セットを保有している。
各サイトの複製データ保持数とクラスタ全体の合計を満たす、各バケツのコピーの完全なセット (サーチ可
能およびサーチ不可能) を保有している。
バケツの修復とピア上のコピー
ピアが停⽌すると、マスターは残りのピアにバケツの修復処理を指⽰します。最終的にバケツの修復が成功した場
合、クラスタは完全状態に復帰します。
その後ピアがクラスタに復帰した場合、マスターはそのバケツコピーをカウント数に追加します (ピア停⽌の原因
となった問題により、それらのコピーが壊れていない場合)。その結果がどうなるかは、ピアの復帰時までにバケ
ツの修復処理が完了しているかどうかによって異なります。
バケツの修復が完了している場合
139
バケツの修復がすでに完了し、クラスタが完全状態になっている場合、復帰したピアのコピーは単に余分なコピー
となります。たとえば、複製データ保持数が 3 の場合に、クラスタですべてのバケツの修復処理が完了すると、
クラスタには再び各バケツの 3 つのコピーが存在することになります (停⽌したピアが停⽌前に管理していたバケ
ツを含む)。停⽌したピアが完全な状態のコピーを持った状態でクラスタに復帰すると、マスターは単純にそれら
のコピーをカウント対象としてコピー数に追加します。そのため、⼀部のバケツに対しては、3 つではなく 4 つ
のコピーが存在することになります。同様に、復帰したピアが⼀部のバケツのサーチ可能コピーを保持していた場
合は、余分なサーチ可能バケツコピーが存在することになります。これらの余分なコピーは、後ほどそれらのバケ
ツの⼀部のコピーを保持している、その他のピアが停⽌した場合などに役⽴ちます。
バケツがまだ修復中の場合
クラスタが、ピア停⽌時に失われたコピーを引き続き再作成している場合、ピアの復帰によりバケツの修復処理作
業を減らすことができます。マスターが復帰したピア上のコピーをカウント対象に追加すると、クラスタは不完全
ですが有効な状態であることが分かります。そこで、その他のピアにそれらのバケツのコピー作成を指⽰する必要
がなくなります。ただし、バケツのコピーやコピーのサーチ可能への変換などの、バケツ修復処理中のピアは、そ
れらのコピーに対する作業を完了するまで⾏います。バケツの修復処理には時間がかかるため、停⽌したピアをオ
ンライン状態に復帰させるのは効果的です (特にピアが⼤量のバケツコピーを保有している場合)。
余分なバケツコピーの削除
ピアの復帰により⼀部のバケツの余分なコピーが存在している場合、余分なコピーを削除してディスクスペースを
節約することができます。詳細は、「インデクサークラスタからの超過バケツコピーの削除」を参照してくださ
い。
マスターノード停⽌時の処理
マスターは、インデクサークラスタが正常に動作するために必要不可⽋で、⼤部分のクラスタ活動を指⽰、調整す
る役割を果たしています。マスターが停⽌した場合、ピアとサーチヘッドは既定の⾏動を取り、しばらくの間は通
常に近い動作を⾏うことができます。それでも、マスターの停⽌は深刻な障害として対処する必要があります。
マスターの停⽌の可能性に対処するために、必要に応じて処理を引き継ぐスタンバイマスターを設定することがで
きます。詳細は、「インデクサークラスタのマスターノードの交換」を参照してください。
マスターが停⽌した場合
マスターが停⽌しても、他の障害が発⽣しない限りクラスタは通常のように機能することができます。ピアは引き
続きデータの取り込み、他のピアへのコピーの転送、バケツの複製、およびサーチヘッドからのサーチリクエスト
への応答を⾏うことができます。
ピアはホットバケツを移⾏する時に、通常はマスターに問い合わせて次のホットバケツの転送先ターゲットピアリ
ストを取得します。しかし、マスター停⽌中にピアがホットバケツを移⾏した場合、次のホットバケツは前のホッ
トバケツと同じ⼀連のターゲットピアに転送されます。
問題は徐々に現れてきます。たとえば、マスター停⽌中にピアが停⽌した場合、必要なバケツの修復 処理を実⾏
することはできません。また、何らかの理由であるピアがターゲットピアと接続できない場合、他のターゲットに
変更することはできません。
サーチヘッドもマスターなしで機能することはできますが、徐々にサーチでアクセスできるデータセットが不完全
なものになっていきます。(たとえば、プライマリバケツコピーを持つピアが停⽌した場合、他のピアのコピーを
プライマリにする⽅法がないため、それらのバケツはサーチ対象ではなくなります。)サーチヘッドは、マスター
が停⽌する前に最後に取得した世代 ID を使⽤します。この世代のピアが停⽌した場合は、警告メッセージが表⽰
されます。
マスターが復帰した場合
ピアは引き続きハートビートを送信しているため、マスターが復帰すると、それを検出して再接続することができ
ます。
マスターが復帰すると、ピアが登録できるように 60 秒間待機します。この期間が経過すると、マスターはピア
ノードやバケツの状態を含めた、クラスタの全状態を把握します。最低でも複製データ保持数だけのピアが登録さ
れている場合、クラスタを有効 で完全 な状態にするために、マスターはバケツの修復に必要な作業を開始しま
す。また、必要に応じてクラスタの再調整を⾏い、世代 ID を更新します。
バケツをコピーしてサーチ不可コピーをサーチ可能コピーにする作業が含まれるため、バケツの修復作業が完了す
るまでにはある程度の時間がかかります。バケツ修復作業を完了するためにかかる時間の⾒積もりについては、こ
こを参照してください。
最初の 60 秒間が経過すると、[マスター] ダッシュボードでクラスタのステータスを確認することができます。
注意： マスターを再起動する場合は、複製データ保持数以上のピアが稼働していることを確認してください。
インデクサーおよびインデクサーのクラスタのトラブ
ルシューティング
⾮クラスタバケツの問題
ここでは、クラスタリングとは独⽴して発⽣する、バケツに関するさまざまな問題の対処⽅法について説明してい
きます。
140
バケツの再構築
通常インデクサーは、ユーザーの介⼊なしでクラッシュ後の回復を⾏うことができます。予期しない問題でインデ
クサーが停⽌した場合、最後の⽅で受信したデータをサーチできないことがあります。インデクサーを再起動する
と、バックグラウンドで fsck が⾃動実⾏されます。このコマンドは、バケツのヘルス状態を診断して、必要に応
じてサーチデータを再構築します。
注意： fsck の⼿動実⾏が必要になるようなことはほとんどありません。このコマンドを⼿動実⾏する場合は、イ
ンデクサーを停⽌する必要があります。また、インデックスが⼤きい場合は、コマンドの完了までに数時間かかる
こともあります。それまでの間は、データにアクセスできません。ただし、Splunk サポートからこのコマンドの
実⾏が指⽰された場合に備えて、このセクションの残りの部分では実⾏⽅法を説明しています。
を⼿動実⾏するには、まずインデクサーを停⽌する必要があります。次に、対象のバケツに対して fsck を実
⾏します。すべてのインデックスのバケツに対して fsck を実⾏するには、以下のコマンドを使⽤します。
fsck
splunk fsck repair --all-buckets-all-indexes
この場合、すべてのインデックスのすべてのタイプのバケツ (ホット/ウォーム/コールド) が再構築されます。
注意： fsck コマンドは、Splunk Enterprise 4.2 以上で作成されたバケツのみを再構築します。
fsck
コマンドの詳細、および利⽤できるオプションの⼀覧を表⽰するには、以下のコマンドを実⾏してください。
splunk fsck --help
コマンドは、インデックスのサイズによっては実⾏に数時間かかります。再構築対象のバケツが少し
だけだと判断する場合は、rebuild コマンドをそれらのバケツだけに実⾏することが可能です。次のセクション 単
⼀バケツの再構築 を参照してください。
fsck repair
単にインデックスの状態を診断したいだけの場合は (復旧措置を⾏わない)、次を実⾏します：
splunk fsck scan --all-buckets-all-indexes
注意： splunk fsck を使って単⼀のバケツを修復することはできません。代わりに
てください。
splunk rebuild
コマンドを使⽤し
単⼀バケツの再構築
バケツ内のインデックスおよびメタデータファイル (バージョン 4.2 以上) が何らかの理由で壊れた場合、raw
データファイルからバケツを再構築することができます。以下のコマンドを使⽤してください。
splunk rebuild <bucket directory>
古いインデックスおよびメタデータファイルが⾃動的に削除、再構築されます。⾃分でファイルを削除する必要は
ありません。
rebuild
コマンドを実⾏する前に、インデクサーを停⽌する必要があります。
注意：
バケツの再構築は、ライセンスのカウント対象ではありません。
バケツの再構築を完了するまでに、⻑時間かかることがあります。ハードウェアの仕様などシステム上のさ
まざまな要因により、10 GB のバケツの再構築に約 30 分〜数時間かかる場合もあります。
4.2 より前の無効なホットバケツの回復
メタデータファイル (Sources.data, Hosts.data, SourceTypes.data) が壊れているまたは不正だと判断されると、ホッ
トバケツは無効なホット (invalid_hot_<ID>) バケツになります。通常不正なデータは不正な時間範囲を指していま
す。このことは、イベント数も不正確であることを表しています。
無効なホットバケツは無視されます。このようなバケツにデータは追加されず、サーチすることもできません。無
効なバケツは、maxTotalDataSizeMB などのバケツの制限値を決定する際にも考慮されません。無効なバケツがシス
テム内のデータフローに悪影響を与えることはありませんが、これによりディスクストレージが、設定されている
最⼤値を超えてしまう可能性もあります。
無効なホットバケツを回復するには、recover-metadata コマンドを使⽤します。
1. メタデータファイル
Sources.data, Hosts.data, SourceTypes.data
のバックアップコピーを作成します。
2. raw データ情報からメタデータを再構築します。
splunk cmd recover-metadata path_to_your_hot_buckets/invalid_hot_<ID>
3. 成功したら、バケツを通常の名前に変更します。
141
インデックスレベルのバケツマニフェストの再構築
インデックスレベルのマニフェストを再構築する必要はほとんどありませんが、必要な場合に備えてそのためのコ
マンドがいくつか⽤意されています。
警告： これらのコマンドは、Splunk サポートから指⽰された場合にのみ使⽤してください。独⾃にマニフェスト
を再構築しないようにしてください。
インデックスレベルのマニフェストファイルには、.bucketManifest と .metaManifest の 2 種類のファイルがありま
す。.bucketManifest ファイルには、インデックス内のすべてのバケツのリストが含まれています。たとえば、バケ
ツをインデックスに⼿動コピーしたような場合に、この再構築が必要になります。.metaManifest ファイルには、イ
ンデックスレベルのメタデータファイルに寄与するバケツのリストが含まれています。
以下のコマンドは、.bucketManifest および .metaManifest ファイル、そして main インデックスの homePath 内の
すべての *.data ファイルのみ を再構築します。個別のバケツのメタデータを再構築することはありません 。
splunk _internal call /data/indexes/main/rebuild-metadata-and-manifests
.metaManifest
および
homePath/*.data
ファイルのみを再構築する場合は、代わりに以下のコマンドを使⽤します。
splunk _internal call /data/indexes/main/rebuild-metadata
.bucketManifest
ファイルのみを再構築する場合は、以下のコマンドを使⽤します。
splunk _internal call /data/indexes/main/rebuild-bucket-manifest
すべてのインデックスのマニフェストを再構築する場合、ワイルドカードのアスタリスク (*) を使⽤できます。
例：
splunk _internal call /data/indexes/*/rebuild-metadata-and-manifests
バケツのレプリケーションの問題
バケツのレプリケーションを妨害するネットワーク上の問題
ソースピアがターゲットピアにホットバケツを複製できないなどの、ピアノード間の接続に関する問題がある場
合、ソースピアはホットバケツを移⾏して新しいホットバケツの使⽤を開始します。引き続きターゲットピアへの
接続に問題がある場合は、同様に新しいホットバケツが使⽤されます。
障害が⻑引いて⼤量の⼩さなホットバケツが⽣成されることを防⽌するために、ソースピアは特定のターゲットピ
アに対するレプリケーションエラーが設定された値に達すると、ターゲットピアとの接続に関する問題に対処する
ために、ホットバケツの移⾏を中⽌します。デフォルトは、3 回のレプリケーションエラーです。その後マスター
ノードのダッシュボードには、ソースピアのエラー発⽣回数に応じて、以下のバナーメッセージが 1 回または複
数回表⽰されます。
Search peer <search peer> has the following message: Too many streaming errors to target=<target
peer>. Not rolling hot buckets on further errors to this target. (This condition might exist with
other targets too. Please check the logs.)
ネットワークに関する問題が発⽣している間は、最新のホットバケツの利⽤可能なコピー数が複製データ保持数を
満たさない可能性があります。
レプリケーションエラーの発⽣可能回数の設定
許可するレプリケーションエラーの発⽣回数を調整するために、ソースピアの server.conf にある
max_replication_errors 属性を設定することができます。ただし、単⼀のネットワーク上の問題に起因するレプリ
ケーションエラーはまとめて 1 つのエラーとしてのみカウントされるため、この属性のデフォルト値である 3 を
変更する必要はほとんどありません。「Too many streaming errors」バナーメッセージは引き続き表⽰されます
が、無視しても構いません。
注意： 複数のレプリケーションエラーをまとめて 1 つのエラーとみなす処理は、リリース 6.0 で⾏われた変更で
す。この変更により、異常な条件下でない限り、エラー数がデフォルト値の 3 を超えることはほとんどありませ
ん。
ソースピア上のレプリケーション障害の証拠
レプリケーション障害の証拠は、ソースピアの splunkd.log に、障害が発⽣したターゲットピアへの参照と⼀緒に
記録されます。ログ内の関連する⾏を探すには、「CMStreamingErrorJob」で検索します。たとえば、以下の
grep コマンドでは、GUID が「B3D35EF4-4BC8-4D69-89F9-3FACEDC3F46E」のピアに、15 件のストリー
ム配信エラーが発⽣していることが分かります。
142
grep CMStreamingErrorJob ../var/log/splunk/splunkd.log* | cut -d' ' -f10 | sort |uniq -c | sort -nr
15 failingGuid=B3D35EF4-4BC8-4D69-89F9-3FACEDC3F46E
ピアを無効にしてから再度有効にできない
インデクサーをピアとして無効にした場合、無効にされた時点でピアに存在していたホットバケツは、ウォームに
移⾏され、スタンドアロンバケツの命名規則に従って名前が付けられます。後ほどピアを再度有効にした場合、マ
スターはそれらのバケツをクラスタのバケツとして認識し、クラスタバケツの命名規則により命名されていると考
えます。しかし、実際にはスタンドアロンバケツの命名規則に従って命名されているため、問題が発⽣してしまい
ます。この命名規則の違いにより、ピアはクラスタに再参加できません。
この問題に対処するには、バケツを消去するか、または再度有効にする前に、ピア上のスタンドアロンバケツを削
除する必要があります。
マルチサイトクラスタが複製データ保持数やサーチ可能データ保持数を満たさない
この場合、マルチサイトクラスタが複製データ保持数またはサーチ可能データ保持数を満たしていない旨を知らせ
るメッセージが表⽰されます。たとえば、メッセージは [マスター] ダッシュボードに表⽰されます。このような
状態は、マルチサイトクラスタの⽴ち上げ直後、即座に発⽣します。
単⼀サイトの replication_factor および search_factor の値を、各サイトにあるピアの台数と⽐較してください。
(単⼀サイトの複製データ保持数とサーチ可能データ保持数を明⽰的に設定していない場合は、それぞれがデフォ
ルトの 3 と 2 になります。)いずれかのサイトのピア数が 2 つの属性の⼀番⼩さな値未満の場合は、両⽅の属性
の値を、もっとも少ないサイトのピア数以上に設定する必要があります。
設定バンドルの問題
ここでは、マスターからピアノードに設定バンドルを配布する際に発⽣する可能性がある問題を説明していきま
す。
⾮常に⼤きなバンドルの配布時にバンドル検証が失敗する
⾮常に⼤きなバンドル (>200MB) を配布しようとすると、各種タイムアウトによりバンドルの検証に失敗するこ
とがあります。対処⽅法：
1. マスターの
server.conf
を編集して、以下の設定を含めます。
[sslConfig]
allowSslCompression = false
[clustering]
heartbeat_timeout = 600
2. マスターを再起動します。
3. server.conf 設定の更新を含むバンドルをピアに配布します。
a. 前回に正常終了した配布の後に追加された App を、⼀時ディレクトリに移動します。
b. マスターに、以下の設定で
$SPLUNK_HOME/etc/master-apps/_cluster/local/server.conf
を作成します。
[general]
useHTTPClientCompression = true
[clustering]
heartbeat_period = 30
cxn_timeout = 300
send_timeout = 300
rcv_timeout = 300
c. バンドルをピアに配布します。
splunk apply cluster-bundle
これにより、すべてのピアのローリング再起動が開始されます。
4. ステップ 3a でバンドルから削除した App を、バンドルに再追加します。また、新しい
残します。
5. このバンドルをピアに配布します。
143
server.conf
ファイルも

はいしゃうんちく其の四 "タバコいつやめるの？？"

IT運用とビッグデータの 意外な関係とは

マシンデータに眠っているのはビジネスチャンス

本田技研工業 - マクニカネットワークス

Splunk Enterprise

納入書取扱いのお願い - 余市町ホームページ

けいれん既往者への予防接種について，教えてください。

HP Workstationクイック リファレンス カード