Splunk 5.0.2
インデクサーとクラスタの管理
作成：2013 年 3 月 13 日 午前 8 時 5 分
Copyright (c) 2013 Splunk Inc. All Rights Reserved
Table of Contents
インデックスの 概 要
9
インデックス、インデクサ ー 、およびクラスタ
インデックス
インデクサ ー
クラスタ
9
9
9
10
インデックス作成の仕組み
イベント 処 理
インデックスには何がある？
インデックスのデフォルトセット
回答
10
10
11
12
12
インデックス時とサ ー チ時
インデックス時
サ ー チ時
12
12
13
分散環境でのインデクサ ー
インデクサ ー へのデ ー タ 転 送
Search across multiple indexers
13
13
14
インデックスの管理
14
インデックスの管理について
インデックス作成 処 理の詳細
14
15
複 数 のインデックスの設定
複 数 のインデックスを利用する理由
インデックスの作成と編集
特定のインデックスへのイベントの送信
特定のインデックスのサ ー チ
15
15
15
17
18
Splunk からのインデックスとデ ー タの削除
今後のサ ー チからイベントを削除する
1 つまたは複 数 のインデックスからのデ ー タの削除
インデックス全 体 の削除
インデックスを削除せずに無 効 化する
リタイアポリシ ー に基づいて古いデ ー タを削除
19
19
20
20
21
21
インデックスの最適化
21
インデックスストレ ー ジの管理
21
Splunk によるインデックスの保管方法
注意事項
Splunk のデ ー タ 過時間の仕組み
21
22
22
インデックスディレクトリの 内 容
バケツと Splunk の管理
バケツのトラブルシュ ー ティング
その他の 参 考情報
23
24
24
26
インデックスストレ ー ジの設定
26
インデックスデ ー タベ ー スの移動
*nix ユ ー ザ ー の場合
Windows ユ ー ザ ー の場合
Splunk 管理を使ったインデックスへのパスの 更
28
28
29
29
インデックスデ ー タ用の複 数 パ ー ティションの使用
複 数 のパ ー ティションの設定
クラスタと coldPath
30
30
31
インデックスサイズの設定
各インデックスのインデックスサイズの設定
バケツタイプによるインデックスサイズの設定
ボリュ ー ムによるインデックスサイズの設定
すべてをまとめる
31
31
31
31
32
ディスク使用量の制限の設定
最低空きディスクスペ ー スの設定
インデックスストレ ー ジの制御
33
33
34
ブル ー ムフィルタの設定
なぜブル ー ムフィルタを使用するのか？
ブル ー ムフィルタの設定
34
34
35
インデックスのバックアップとア ー カイブ
35
インデックス作成されたデ ー タのバックアップ
デ ー タの時間 過
インデックスデ ー タベ ー スディレクトリの場所
バックアップ方針の選
ホットバケツのウォ ー ムへの手動移行
復元の推 事項
インデックスのバックアップ方法
クラスタ化されたデ ー タのバックアップ
35
36
36
37
37
38
38
38
リタイアおよびア ー カイブポリシ ー の設定
コ ー ルドからフロ ー ズンへの移行動作の 属 性の設定
デ ー タのア ー カイブ
その他のバケツ移行 条 件
ア ー カイブポリシ ー のトラブルシュ ー ティング
38
39
39
39
40
インデックス作成されたデ ー タのア ー カイブ
Splunk によるデ ー タのア ー カイブ方法
ア ー カイブへの署名
クラスタ化デ ー タのア ー カイブ
40
40
42
42
ア ー カイブされたインデックスデ ー タの復元
42
ア ー カイブを別の Splunk インスタンスに復元する場合の制限事 42
項
ア ー カイブバケツに 4.2 以降のデ ー タが含まれているかどうか 43
の判 断
4.2 以降のア ー カイブの解凍
43
4.2 より前のア ー カイブの解凍
44
クラスタ化デ ー タの復元
45
クラスタとインデックスレプリケ ー ションの 概 要
45
クラスタとインデックスレプリケ ー ションについて
クラスタの 内 容
クラスタの設定方法
クラスタのサ ー チ方法
先に進む前に
非クラスタ Splunk デプロイ環境から移行しますか？
45
45
46
47
47
47
基本的なクラスタのア ー キテクチャ
クラスタのコンポ ー ネント
重要な 概 念
インデックス作成の仕組み
サ ー チの仕組み
クラスタでのノ ー ド障害の取り扱い
47
47
49
50
51
51
クラスタのデプロイ
52
デプロイの 概 要
非クラスタ Splunk デプロイ環境から移行しますか？
クラスタのデプロイ
その他のデプロイシナリオ
52
52
52
54
最初にお 読 みください：クラスタ構成と非クラスタ構成の Splunk デ 54
プロイの主な相違点
クラスタピアでデプロイサ ー バ ー やサ ー ドパ ー ティ製のデプロ 54
イツ ー ルを使用しないでください
システム要件の相違
54
その他の 討事項と非クラスタデプロイとの相違点
55
非クラスタ構成インデクサ ー の移行
55
システム要件とその他のデプロイに 関 する 討事項
ハ ー ドウェア要件
Splunk バ ー ジョンの互換性
必要な Splunk インスタンス
ネットワ ー ク要件
ストレ ー ジの 討事項
ライセンス情報
サ ー バ ー とクラスタのデプロイ
55
55
55
55
55
56
57
57
マスタ ー ノ ー ドを有 効 にする
58
マスタ ー を有 効 にする
マスタ ー ダッシュボ ー ドの表示
追加設定
58
58
59
ピアノ ー ドを有 効 にする
ピアを有 効 にする
ピアダッシュボ ー ドの表示
ピアの設定
59
59
59
59
サ ー チヘッドを有 効 にする
サ ー チヘッドを有 効 にする
サ ー チヘッドダッシュボ ー ドの表示
複 数 クラスタサ ー チを有 効 にする
複 数 のサ ー チヘッドの設定
追加設定
60
60
60
60
60
61
ピアのインデックスレプリケ ー ションの準備
61
フォワ ー ダ ー を使ったデ ー タの取り 込 み
フォワ ー ダ ー からピアノ ー ドへの接 続 の設定
フォワ ー ダ ー のデ ー タ入力の設定
インデクサ ー 答確認の仕組み
ロ ー ドバランシングの仕組み
ピア上で直接入力を設定する
61
61
63
63
63
64
クラスタを使ったインデックスの 強
クラスタピア管理とデプロイサ ー バ ー の比較
処 理能力 強 デプロイのためのクラスタの設定
64
64
65
非クラスタインデクサ ー のクラスタ化環境への移行
従来 のデ ー タの管理
クラスタへの App の移行
65
65
65
クラスタのアップグレ ー ド
アップグレ ー ド順序
5.0.1 以前からのアップグレ ー ド
66
67
68
クラスタの設定
68
マスタ ー の設定
デプロイ後の設定の 実 施
スタンバイマスタ ー の設定
68
68
68
ピアノ ー ドの設定
すべてのピアの共通設定の管理
ピア 単位での設定の管理
69
69
70
ピアインデックスの設定
71
すべてのピアが同じ indexes.conf ファイルセットを使用する必 71
要があります
ピアのインデックスセットの設定
indexes.conf の編集
新しい indexes.conf ファイルのピアへの配布
72
72
73
サ ー チヘッドの設定
複 数 クラスタサ ー チの設定
クラスタ化サ ー チヘッドと非クラスタ化サ ー チヘッドの違い
分散サ ー チの [管理 ] ペ ー ジ
マウントされたバンドルおよびサ ー チピアの設定
73
73
74
74
74
詳細設定
74
server.conf によるクラスタの設定
クラスタノ ー ドを有 効 にする
秘密鍵の設定
クラスタノ ー ドの再起動
警告：マスタ ー 上で複製デ ー タ保持 数 またはサ ー チ可能デ ー タ
保持 数 を やさないでください
74
75
76
76
76
CLI を使ったクラスタの設定
CLI コマンドのヘルプ
クラスタノ ー ドを有 効 にする
クラスタ設定の編集
クラスタ情報の表示
クラスタの管理
76
76
77
77
77
77
クラスタの管理
78
マスタ ー ダッシュボ ー ドの表示
ダッシュボ ー ドへのアクセス
ダッシュボ ー ドの表示
ピアノ ー ドダッシュボ ー ドのマスタ ー ビュ ー へのアクセス
78
78
78
80
ピアダッシュボ ー ドの表示
ピアダッシュボ ー ドへのアクセス
ダッシュボ ー ドの表示
81
81
81
サ ー チヘッドダッシュボ ー ドの表示
ダッシュボ ー ドへのアクセス
ダッシュボ ー ドの表示
サ ー チピア上の情報の表示
82
82
82
82
ピアをオフラインにする
83
一時的にピアをオフラインにする場合
83
永久的にピアをオフラインにする場合
83
offline コマンド
83
ピアの一時停止：高速な offline コマンド
84
ピアの永久停止： enforce-counts を指定した offline コマンド 84
共通のピア設定と App の更新
設定バンドルの構造
85
85
クラスタ App の制限事項
設定バンドルの配布
ピア起動時のバンドルの配布
86
87
88
クラスタ全 体 または 1 台のクラスタノ ー ドの再起動
クラスタ全 体 の再起動
単一ピアの再起動
88
88
88
クラスタの仕組み
89
高度なユ ー ザ ー 向けの基本 概 念
89
複製デ ー タ保持 数
89
サ ー チ可能デ ー タ保持 数
90
バケツとクラスタ
デ ー タファイル
バケツの移行
バケツのサ ー チの可否と優先度 状 態
世代
90
91
92
92
93
クラスタの 状 態
94
クラスタでのインデックス作成の仕組み
ピアノ ー ド起動時
ピアノ ー ドのホットバケツの移行時期
ピアノ ー ドとフォワ ー ダ ー のやり取り
95
95
95
96
クラスタ化サ ー チの仕組み
クラスタにまたがるサ ー チ
単一ピアのサ ー チ
96
96
97
クラスタノ ー ドの起動方法
マスタ ー ノ ー ドの開始時
ピアが新しいクラスタに 参 加した場合
ピアが 既 存のクラスタに 参 加した場合
97
97
97
97
ピアノ ー ド停止時の 処 理
ピアノ ー ドを意 図的にオフラインにした場合
予期せずにピアノ ー ドが停止した場合
バケツ修復のシナリオ
97
98
99
99
ピアノ ー ドが復 した場合の 処 理
マスタ ー のバケツのカウント方法
バケツの修復とピア上のコピ ー
102
102
102
マスタ ー ノ ー ド停止時の 処 理
マスタ ー が停止した場合
マスタ ー が復 した場合
103
103
103
インデックスの 概 要
インデックス、インデクサ ー 、およびクラスタ
このマニュアルでは、Splunk のデータリポジトリとそれを作成、管理するための Splunk コンポーネントについて
明していきます。
インデックスは、Splunk データのリポジトリです。Splunk は到着したデータをイベントに 換します。イベントは
インデックスに保管されます。
インデクサーは、データのインデックスを作成する Splunk インスタンスです。インデクサーは、データの入力や
サーチの管理など、他の Splunk 機能も頻繁に実行しています。ただし、分散環境の場合、一般的にデータ入力と
サーチ管理は他の Splunk コンポーネントが担当します。これらは、フォワーダーおよびサーチヘッドと呼ばれて
います。このマニュアルでは、インデックス作成機能についてのみ 明していきます。
クラスタは、相互のデータを複製するように設定されたインデックスのグループです。このプロセスは、インデッ
クスレプリケーションとして知られています。クラスタは Splunk データの複数の同一コピーを保持することによ
り、データ消失を防止しながら、サーチ用データの可用性を向上します。
インデックス
Splunk がデータのインデックスを作成するにつれて、一連のファイルが作成されます。これらのファイルは、2
つのカテゴリに分類できます。
縮形式の raw データ (rawdata)
raw データを指すインデックスといくつかのメタデータファイル (インデックスファイル)
Splunk のインデックスは、これらのファイルにより構成されています。一連のディレクトリに保管されている
ファイルは、その 過時間で管理されています。これらのディレクトリは、バケツと呼ばれています。詳細は、こ
のマニュアルの「Splunk によるインデックスの保管方法」を参照してください。
Splunk は、柔軟なサーチと高速なデータ取得を目的にインデックスを管理しています。インデックスは、ユー
ザーが設定可能なスケジュールにより順次アーカイブされます。Splunk はすべてをフラットファイルで管理して
います。バックグラウンドでサードパーティ製のソフトウェアを実行する必要はありません。
インデックス作成処理中に、Splunk は高速なサーチ/分析を可能にするために、到着したデータを処理して、その
結果をインデックス内にイベントとして保管します。インデックス作成時に、Splunk はデータをさまざまな方法
で 張します。以下に例を示します。
データストリームを個別のサーチ可イベントに分割する。
タイムスタンプを作成、判別する。
ホスト、ソース、ソースタイプなどのフィールドを抽出する。
到着したデータに して、カスタムフィールドの識別、重要なデータのマスキング、新規または 更されたキー
の書き込み、複数行イベントの分割ルールの適用、不要なイベントのフィルタリング、イベントの特定イン
デックスまたはサーバーへのルーティングなどの、ユーザー定義のアクションを実行する。
このインデックス作成プロセスは、イベント処理としても知られています。
インデックス作成を開始するには、単に目的のデータ入力を指定します。その他の入力をいつでも追加することが
できます。追加したデータ入力に してもインデックスが作成されます。データ入力の追加方法については、
『Getting Data In Manual』の「What Splunk can index」を参照してください。『Getting Data In Manual』には、
データのニーズを たすための、インデックス時イベント処理の設定方法についても 明されています。「Overview
of event processing」を参照してください。
デフォルトで Splunk はすべてのユーザーデータを、単一の事前設定されたインデックスに保管します。また、内
部処理目的で他の複数のインデックスも作成します。新しいインデックスを追加したり、既存のインデックスを
データ要件に合わせて管理したりすることができます。詳細は、このマニュアルの「インデックスの管理」を参照
してください。
インデクサ ー
インデクサーは、インデックスの作成と管理を行う Splunk コンポーネントです。インデクサーの主な機能を以下
に示します。
9
到着データのインデックス作成。
インデックスデータのサーチ。
1 つの Splunk インスタンスからのみ構成される単一マシン環境では、データの取り込みおよびサーチ管理機能も
インデクサーが担当します。
大規模環境でのニーズに合わせて、インデックス作成処理をデータの取り込み機能や、必要に じてサーチ管理機
能からも切り離すことができます。このような大規模な分散環境では、Splunk インデクサーはしばしば独自のマ
シン上に常駐し、そのインデックスデータのサーチとともにインデックス作成処理のみを担当します。このような
場合、インデックス作成以外の処理は他の Splunk コンポーネントが担当します。フォワーダーがデータを取り込
んで、インデクサーがデータのインデックス作成とサーチを行い、サーチヘッドがインデクサー全体のサーチを調
整します。大規模環境へのデプロイ例を以下に示します。
インデクサーを使った分散デプロイの詳細は、このマニュアルの「分散デプロイ環境のインデクサー」を参照して
ください。
Splunk インデクサーのインストール方法については、『Installation Manual』を参照してください。
クラスタ
クラスタは、連携して冗長インデックス作成およびサーチ機能を提供する、Splunk ノードのグループです。クラ
スタ内には 3 種類のノードが存在しています。
クラスタを管理する単一のマスターノード。マスターノードは、特別なタイプのインデクサーです。
クラスタのインデックス作成機能を担当し、複数のインデックスデータのコピーを保持し、データをサーチ
する複数のピアノード。
すべてのピアノードにまたがってサーチを調整、管理する 1 つまたは複数のサーチヘッド。
Splunk のクラスタ機能では、あるノードから別のノードに自動フェイルオーバーを行います。つまり、1 つまた
は複数のピアに障害が発生した場合でも、引き続き到着データのインデックスが作成され、サーチが可能になりま
す。
このマニュアルの前半に記載されているインデックス作成に関する情報は、クラスタに参加しているかどうかにか
かわらず、すべてのインデクサーに関連しています。ただし、クラスタに参加しているインデクサーは、スタンド
アロンインデクサーと比べて追加の設定を行う必要があります。クラスタの詳細は、このマニュアルの後半の「ク
ラスタとインデックスレプリケーションについて」以降の 明を参照してください。
インデックス作成の仕組み
Splunk は任意の種類の時系列データ (タイムスタンプを持つデータ) のインデックスを作成できます。データのイ
ンデックスを作成する際には、タイムスタンプに基づいてデータがイベントに分割されます。
イベント 処 理
イベント処理は、パーシングとインデックス作成の 2 つのステージに分かれて行われます。Splunk に取り込まれ
るデータはすべて、大きなチャンク (10,000 バイト) としてパーシングパイプラインを通過します。パーシング中
に、これらのチャンクはイベントに分割されます。分割されたイベントは、インデックス作成パイプラインに渡さ
れて、最終処理が行われます。
パーシング中、Splunk はさまざまなアクションを実行します。以下に例を示します。
各イベントに して、host、source、および sourcetype などの、一連のデフォルトフィールドを抽出する。
文字コードを設定する。
改行ルールを使って行の終端を識別する。大半のイベントは短く、1 2行程度ですが、中には長いイベントも
10
存在しています。
タイムスタンプを識別する、また存在しない場合は作成する。タイムスタンプ処理と同時に、イベント境界
の識別が行われます。
このステージで、重要なイベントデータ (クレジットカード情報や社会保障番号など) をマスクするように
Splunk を設定することができます。また、受信したイベントにカスタムメタデータを適用するように設定す
ることもできます。
インデックス作成パイプラインでは、以下のような追加処理が行われます。
すべてのイベントを、サーチ可能なセグメントに分割する。セグメント分割レベルを指定することができま
す。この設定は、インデックス作成/サーチ速度、サーチ能力、およびディスクの 縮効率に影響します。
インデックスデータ構造を作成する。
raw データとインデックスファイルをディスクに書き込む。ディスクでは、インデックス作成後の 縮処理が
行われます。
パーシングパイプラインとインデックス作成パイプラインへの分割は、主にフォワーダーの展開に関連していま
す。ヘビーフォワーダーは、データのパーシングを行い、最終的なインデックス作成処理を行うためにそのデータ
をインデクサーに転送します。
イベントの詳細およびインデックス作成処理時に何が行われるかについては、『Getting Data In Manual』の
「Configure event processing」を参照してください。
注意：インデックスの作成処理は I/O リソースを消費します。
インデックス作成の主要プロセスを以下の図に示します。
注意：この図は、インデックス作成アーキテクチャの簡単なビューを表しています。これは、アーキテクチャの機
能的なビューで、完全な Splunk の内部動作を表している訳ではありません。特に、パーシングパイプラインは、
実際にはパーシング、マージング、およびタイピングの 3 つのパイプラインが成り立っており、これらが連携して
パーシング機能を担当しています。このような区別はトラブルシューティングの際に関係してきますが、一般的な
Splunk の設定やデプロイには何も影響することはありません。
インデックスには何がある？
11
Splunk は、処理するデータすべてをインデックスに格納しています。インデックスはデータベースの集合体
で、$SPLUNK_HOME/var/lib/splunk のサブディレクトリに存在しています。インデックスは raw データファイ
ルとインデックスファイルの、2 種類のファイルタイプから成り立っています。詳細は、このマニュアルの
「Splunk によるインデックスの保管方法」を参照してください。
インデックスのデフォルトセット
Splunk には、さまざまな事前設定されたインデックスが用意されています。以下に例を示します。
main：これは、デフォルトの Splunk インデックスです。特に指定のない限り、処理されたデータはすべて
ここに保管されます。
_internal：Splunk 内部ログおよび処理指標を保管します。
_audit：ファイルシステム 更監視、追跡、およびすべてのユーザーサーチ履歴に関連するイベントが含まれ
ます。
Splunk 管理者は、新規インデックスの作成、インデックスプロパティの編集、不要なインデックスの削除、およ
び既存のインデックスの移動などの作業を行えます。Splunk 管理者は、Splunk 管理、CLI、および indexes.conf
などの設定ファイルを使ってインデックスの管理を行います。詳細は、このマニュアルの「インデックスの管理」
を参照してください。
回答
何か質問がありますか？「Splunk Answers」から、Splunk コミュニティに寄せられた、インデックス作成に関す
る質問と回答をご覧ください。
インデックス時とサ ー チ時
Splunk ドキュメントでは、頻繁に「インデックス時」および「サーチ時」と言う用語について言及されていま
す。これらの用語は、インデックス作成時に発生した処理のタイプとサーチ実行時に発生した処理のタイプを区別
するために用いられます。
Splunk を管理する際には、これらの違いを理解しておくことが重要です。たとえば、データのインデックス作成
をまだ開始していない時点で、処理するカスタムソースタイプやホストが大量に存在していると考えられる場合、
あらかじめそれらを定義しておくことができます。そのためには、インデックス処理中にカスタムソースタイプと
ホストが適切に処理されるように、それらを事前に定義します (ルールベースのソースタイプ割り当て、ソースタ
イプの優先設定、入力ベースのホスト割り当て、およびホストの優先設定などを使用)。
一方、すでにデータのインデックス作成を開始している場合は、サーチ時にこのような問題を処理することができ
ます。そうしない場合は、カスタムソースタイプ/ホストを既存のデータや新規データに適用するために、イン
デックスを再作成する必要があります。インデックスの作成後は、ホスト/ソースタイプ割り当てを 更することは
できません。ただし、それらに代替値でタグを設定し、それを利用して問題を管理することができます。
一般的に、フィールド抽出などのナレッジ作成アクティビティは、サーチ時に実行することをお勧めします。カス
タムフィールドの抽出などの作業をインデックス時に実行すると、インデックス時とサーチ時の両方でパフォーマ
ンスが低下してしまいます。インデックス作成中に抽出フィールドを追加すると、インデックス作成処理速度が低
下してしまいます。また、他のフィールドの追加によりインデックスが巨大化し、当然大きなインデックスのサー
チには時間がかかるため、その後のインデックスに するサーチ速度も低下してしまいます。サーチ時にフィール
ドの抽出を実行することで、このようなパフォーマンス上の問題を回避することができます。サーチ時のフィール
ド抽出の詳細は、『Knowledge Manager manual』の「About fields」および「Create search-time field
extractions」を参照してください。
インデックス時
インデックス時の処理は、イベントデータのインデックスを実際に作成する直前に行われます。
インデックス時 (またはその前) には、以下の処理が行われます。
デフォルトのフィールド抽出 (host、source、sourcetype、および timestamp など)
特定の入力に する静的または動的なホスト割り当て
デフォルトのホスト割り当てへの優先設定
ソースタイプのカスタマイズ
インデックス-時間フィールド抽出
イベントのタイムスタンプ
イベントの改行処理
イベントのセグメント化 (サーチ時にも行われる)
12
サ ー チ時
サーチ時の処理は、サーチ実行時にサーチによるイベントの収集に伴い行われます。サーチ時には以下の処理が行
われます。
イベントのセグメント化 (インデックス時にも行われる)
イベントタイプのマッチング
サーチ時のフィールド抽出 (自動およびカスタムフィールド抽出、複数値フィールドのパーシングを含む)
フィールドのエイリアス設定
外部データソースからのフィールドルックアップ
ソースタイプ名の 更
タグの設定
分散環境でのインデクサ ー
インデクサーは、インデックスの作成と管理を行う Splunk コンポーネントです。インデクサーの主な機能を以下
に示します。
到着データのインデックス作成。
インデックスデータのサーチ。
1 つの Splunk インスタンスからのみ構成される単一マシン環境では、データの取り込みおよびサーチ管理機能も
インデクサーが担当します。
大規模環境でのニーズに合わせて、インデックス作成処理をデータの取り込み機能や、必要に じてサーチ管理機
能からも切り離すことができます。このような大規模な分散環境では、Splunk インデクサーはしばしば独自のマ
シン上に常駐し、そのインデックスデータのサーチとともにインデックス作成処理のみを担当します。このような
場合、インデックス作成以外の処理は他の Splunk コンポーネントが担当します。
たとえば、イベントを生成する一連の Windows および Linuxマシンが存在しており、それらのイベントを単一の
Splunk インデクサーに送って集中処理する場合を考えてみましょう。一般的にこれを実現するための最良の方法
は、フォワーダーとして知られる 量の Splunk インスタンスを、イベントを生成する各マシン上にインストールす
ることです。これらのフォワーダーはデータ入力を担当し、ネットワーク上のデータを専用のマシンに常駐する
Splunk インデクサーに送信します。
同 に、インデックス作成された大量のデータが存在しており、それに して多数のユーザーが同時にサーチを実行
するような場合は、サーチ管理機能とインデックス作成機能を切り離す方が合理的です。このような分散サーチ環
境では、1 つまたは複数のサーチヘッドが、サーチリクエストを複数のインデクサーにまたがって分配します。イ
ンデクサーは引き続き各自のインデックスに する実際のサーチを処理しますが、サーチヘッドがすべてのインデ
クサーにまたがって総合的なサーチプロセスを管理し、ユーザーに統合されたサーチ結果を提供します。
大規模環境へのデプロイ例を以下に示します。
分散環境でもインデックス作成とイベント処理に関する問題の基本は わりありませんが、インデックス作成 略を
策定する際には、デプロイのニーズを 討することが重要です。
注意：大規模な分散デプロイ環境では、クラスタがその中核を為すことが多いですが、クラスタコンポーネント自
体はすべて単一の高速ネットワーク上に配置する必要があります。クラスタの詳細は、「クラスタとインデックス
レプリケーションについて」を参照してください。
インデクサ ー へのデ ー タ 転 送
リモートデータをインデクサーに転送するには、フォワーダーを使用します。フォワーダーは、データ入力を受け
取り、それをまとめたデータを Splunk インデクサーに送信します。フォワーダーは、2 種類に分類できます。
13
ユニバーサルフォワーダー：これらは、各自のホストマシンでリソースの消費量が少なくなっています。到
着したデータストリームに して最低限の処理を行ってから、それをインデクサー (レシーバー) に転送しま
す。
ヘビーフォワーダー：これらは、完全な Splunk インスタンスの大部分の機能を保有しています。インデク
サーにデータを転送する前に、パーシングを行うことができます。(パーシングとインデックス作成の違いに
ついては、「インデックス作成の仕組み」を参照してください。)これらは、インデックス作成したデータを
ローカルに保管したり、パーシングしたデータをレシーバーに転送し、そのマシン上で最終的なインデック
ス処理を行ったりできます。
どちらの種類のフォワーダーでも、インデクサーにデータを転送する前に、ホスト、ソース、ソースタイプなどの
メタデータでデータにタグを設定します。
フォワーダーにより、リモートソースから到着する大量のデータまたは多彩な種類のデータを処理する場合に、リ
ソースを効率的に使用することができます。また、ロードバランシング、データのフィルタリング、およびルー
ティングなどの機能により、さまざまなデプロイトポロジを採用することができます。
設定や使用事例も含めたフォワーダーの詳細については、『Distributed Deployment manual』の「About
forwarding and receiving」を参照してください。
Search across multiple indexers
分散サーチでは、Splunk サーチヘッドはサーチリクエストを Splunk インデクサーに送信し、結果を結合してユー
ザーに返します。これは、水平スケーリング、アクセス制御、および地理的に分散したデータの管理など、さまざ
まな目的に役立ちます。
設定や使用事例も含めた分散サーチの詳細については、『Distributed Deployment manual』の「About distributed
search」を参照してください。
インデクサーのクラスタは、サーチヘッドを使ってクラスタのピアノード間のサーチを管理/調整しています。
「クラスタとインデックスレプリケーションについて」を参照してください。
インデックスの管理
インデックスの管理について
Splunk にデータを追加すると、Splunk はそれを処理してインデックスに格納します。デフォルトでは、Splunk
に取り込んだデータはメイン (main) インデックスに保管されます。ただし、他のインデックスを作成して、異な
るデータ入力で使用するようにそれを設定することができます。
インデックスは、ディレクトリとファイルの集合体です。これらは、$SPLUNK_HOME/var/lib/splunk 下にありま
す。インデックスディレクトリは「バケツ」とも呼ばれており、その 過時間で編成管理されています。インデッ
クスストレージの詳細は、「Splunk によるインデックス保管の仕組み」を参照してください。
main インデックスの他に、Splunk には事前設定されたさまざまな内部インデックスが用意されています。内部イ
ンデックスは、アンダースコア (_) から始まる名前が付けられています。Splunk Web では、インデックスの全リ
ストを参照できます。Splunk Web の右上にある [管理] リンクをクリックして、次に [インデックス] をクリックし
てください。これには、以下の事項が含まれています。
main：デフォルトの Splunk インデックスです。特に指定のない限り、処理された外部データはすべてここ
に保管されます。
_internal：このインデックスには、Splunk プロセッサからの内部ログや指標が含まれています。
_audit：ファイルシステム 更監視、追跡、およびすべてのユーザーサーチ履歴に関連するイベントが含まれ
ます。
このマニュアルのさまざまなトピックで、さまざまなインデックスの管理方法が 明されています。特にインデッ
クス管理においては、以下のトピックが役に立ちます。
複数のインデックスの設定
Splunk からのインデックスとデータの削除
インデックスストレージの設定
インデックスデータベースの移動
インデックスデータ用の複数パーティションの使用
インデックスサイズの設定
ディスク使用量の制限の設定
インデックス作成されたデータのバックアップ
リタイアおよびアーカイブポリシーの設定
14
インデックス作成 処 理の詳細
インデックスの詳細については、以下の項目を参照してください。
このマニュアルの「インデックス作成の仕組み」。
このマニュアルの「Splunk によるインデックス方法」。
このマニュアルの「クラスタとインデックスレプリケーションについて」。
『Getting Data In Manual』の「Configure event processing」。
とても巨大なデータセットに関する作業については、『Knowledge Manager Manual』の「Set up and use
summary indexes」。
複 数 のインデックスの設定
Splunk には、main と言う名前のインデックスが用意されています。デフォルトでは、このインデックスにすべて
のイベントが格納されます。Splunk は他にも、内部システムが使用するその他の各種インデックス、およびサマ
リーインデックスやイベント追跡などの他のSplunk 機能も作成します。
Enterprise ライセンスの Splunk では、追加のインデックスを無制限に追加することができます。main インデック
スは、インデックスが指定されていない任意の入力またはサーチコマンドのデフォルトインデックスとしての役割
を果たします。このデフォルトは 更することができます。インデックスは、Splunk Web、Splunk CLI、または
indexes.conf を使って追加することができます。
ここでは、以下の事項を取り上げていきます。
複数のインデックスを利用する理由。
新しいインデックスの作成方法。
特定のインデックスへのイベントの送信方法。
特定のインデックスのサーチ方法。
複 数 のインデックスを利用する理由
複数のインデックスを利用するさまざまな理由が存在しています。
ユーザーのアクセスを制御する。
さまざまな保持ポリシーを採用する。
特定の状況下でサーチを高速化する。
複数のインデックスを設定する主な理由は、ユーザーのデータに するアクセスを制御することにあります。ユー
ザーをロールに割り当てる場合、ユーザーのサーチを各自のロールに基づいて特定のインデックスに制限すること
ができます。
また、異なるデータセットに して異なる保持ポリシーを適用する場合、データを異なるインデックスに送信し
て、各インデックスに して異なるアーカイブ/保持ポリシーを設定することができます。
また、Splunk のサーチ方法に じて複数のインデックスの設定が必要な場合もあります。大量の高ノイズデータ
ソースと、少量のデータソースを同じインデックスに取り込み、たいていの場合は少量のデータ ソースに して
サーチを行う場合、Splunk は大量のボリュームソースからのデータもサーチする必要があるため、サーチ速度は
通常よりも低下します。この問題を緩和するために、各データソース専用のインデックスを作成し、各ソースから
専用のインデックスにデータを送信することができます。これで、サーチするインデックスを指定することができ
ます。これにより、サーチ速度を改善することができます。
インデックスの作成と編集
Splunk Web、Splunk CLI を使用するか、または indexes.conf を直接 更して、インデックスを作成、編集するこ
とができます。
注意：クラスタに新しいインデックスを追加するには、indexes.conf を直接編集する必要があります。Splunk
Web または CLI を使ってインデックスを追加することはできません。クラスタ向けの indexes.conf の設定方法に
ついては、「ピアインデックスの設定」を参照してください。このトピックには、新しいクラスタインデックスの
作成例が記載されています。
Splunk Web の 使 用
1. Splunk Webで、[管理] > [インデックス] に移動して、[新規] をクリックします。
2. 新しいインデックスを作成するには、以下の項目を入力します。
15
インデックスの名前。インデックス名には、ASCII 文字のみを使用する必要があります。数字、英字、アン
ダースコア、およびハイフンのみを使用できます。新しいインデックスの先頭に、アンダースコアまたはハ
イフンを使用することはできません。
インデックスデータストレージのパス：
ホームパス：空にするとデフォルトの $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 を編集して、Splunk を再起動してください。
注意：一部のインデックスプロパティは、indexes.conf ファイルを編集することによってのみ設定できます。プ
ロパティの全一覧については、indexes.conf のトピックを参照してください。
CLI の 使 用
$SPLUNK_HOME/bin/
ディレクトリに移動して、add index コマンドを実行します。最初に Splunk を停止する必要
はありません。
新しいインデックス「fflanda」を追加するには、以下のコマンドを入力します。
splunk add index fflanda
注意：新しいインデックス名には、数字、英字、アンダースコア、およびハイフンのみを使用できます。先頭にア
ンダースコアまたはハイフンを使用することはできません。
新しいインデックスに してデフォルトパスを使用したくない場合は、パラメータを使って別の場所を指定しま
す。
./splunk add index foo -homePath /your/path/foo/db -coldPath /your/pat/foo/colddb
-thawedPath /your/path/foo/thawedDb
CLI からインデックスのプロパティを編集することもできます。たとえば、インデックス「fflanda」を編集するに
は、CLI で以下のように入力します。
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
を編集したら、Splunk を再起動する必要があります。
重要：クラスタノードのインデックス設定の追加、編集については、「ピアインデックスの設定」を参照してくだ
さい。
16
特定のインデックスへのイベントの送信
デフォルトでは、Splunk はすべてのイベントを main インデックスに送ります。しかし、一部のイベントを別の
インデックスに送りたい場合もあるでしょう。たとえば、特定のデータ入力からのデータを独自のインデックスに
送ることができます。また、データをセグメント化したり、ノイズの多いソースからのイベントデータを専用のイ
ンデックスに送ったりできます。
重要：イベントを特定のインデックスに送るには、インデクサー上にそのインデックスがすでに存在していなけれ
ばなりません。存在しないインデックスにイベントを送った場合、インデクサーはそれらのイベントを破棄しま
す。
データ入力から特定のインデックスへのすべてのイベントの送信
特定のデータ入力からのすべてのイベントを特定のインデックスに送るには、システムにデータを取り込んでいる
Splunk コンポーネント (インデクサーまたはインデクサーにデータを送信するフォワーダー) 上の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.conf で作成する正規表現を含むスタンザに する transforms_name を指定します。
3. transforms.conf に、ステップ 2 で指定した transforms_name と言う名前のスタンザを作成します。このスタン
ザは：
ステップ 1 で指定した属性に一致する正規表現を指定します。
属性に一致するイベントを送る代替インデックスを指定します。
以下のセクションは、ステップ 2 と 3 の詳細を記載しています。
props.conf の編集
$SPLUNK_HOME/etc/system/local/props.conf
に以下のスタンザを追加します。
[<spec>]
TRANSFORMS-<class_name> = <transforms_name>
以下の事項に注意してください。
<spec>
は、以下のいずれかになります。
<sourcetype>、イベントのソースタイプ
host::<host>、<host>
はイベントのホスト
はイベントのソース
source::<source>、<source>
<class_name>
は、任意の一意の識別子です。
<transforms_name>
は、transforms.conf 内で 換に割り当てる任意で一意の識別子です。
transforms.conf の編集
$SPLUNK_HOME/etc/system/local/transforms.conf
に以下のスタンザを追加します。
17
[<transforms_name>]
REGEX = <your_custom_regex>
DEST_KEY = _MetaData:Index
FORMAT = <alternate_index_name>
以下の事項に注意してください。
<transforms_name>
は、props.conf に指定されている <transforms_name> 識別子と一致する必要がありま
す。
<your_custom_regex>
DEST_KEY
には、ステップ 1 で指定した属性の一致条件を指定します。
にはインデックス属性 _MetaData:Index を指定する必要があります。
<alternate_index_name>
には、イベントをルーティングする代替インデックスを指定します。
例
この例では、windows_snare_log ソースタイプのイベントを、そのログタイプに基づいて適切なインデックスに送
ります。アプリケーション (Application) ログは代替インデックスに送られます。セキュリティ (Security) などのそ
の他のログタイプは、デフォルトのインデックスに送られます。
このように仕分けるにためには、props.conf を使用します。windows_snare_log ソースタイプのイベントに し
て、transforms.conf の AppRedirect スタンザ (「Application」ログタイプを探す正規表現を指定) を介して送り先
を指示します。適切な場所で「Application」に一致したイベントは、代替インデックス「applogindex」に送られ
ます。その他のイベントはすべてデフォルトのインデックスに送られます。
1. 属性の識別
この例のイベントは以下のようになります。
web1.example.com
MSWinEventLog
1
Application
4156
MSDTC
Unknown User
N/A
Information
message: Session idle timeout over, tearing down the session.
721
WEB1
Wed Sep 06 17:05:31 2006
Printers
179
web1.example.com
MSWinEventLog
1
Security
722
Wed Sep 06 17:59:08 2006
576
Security
SYSTEM
User
Success Audit
WEB1
Privilege Use
Special privileges assigned to new logon:
User Name:
Domain:
Logon
ID: (0x0,0x4F3C5880)
Assigned: SeBackupPrivilege
SeRestorePrivilege
SeDebugPrivilege
SeChangeNotifyPrivilege
SeAssignPrimaryTokenPrivilege 525
一部のイベントには値「Application」が、他のイベントには同じ場所に値「Security」が存在しています。
2. props.conf の編集
$SPLUNK_HOME/etc/system/local/props.conf
に以下のスタンザを追加します。
[windows_snare_syslog]
TRANSFORMS-index = AppRedirect
これは、windows_snare_syslog ソースタイプのイベントに、transforms.conf 内の AppRedirect スタンザを指示し
ています。
3. transforms.conf の編集
$SPLUNK_HOME/etc/system/local/transforms.conf
に以下のスタンザを追加します。
[AppRedirect]
REGEX = MSWinEventLog\s+\d+\s+Application
DEST_KEY = _MetaData:Index
FORMAT = applogindex
このスタンザは、props.conf によりここに誘導されたイベントを処理します。正規表現に一致したイベント (文字
列「Application」を含む) は、代替インデックス「applogindex」に送られます。その他のイベントはすべて、通常
通りにデフォルトのインデックスに送られます。
特定のインデックスのサ ー チ
特定のインデックスを明示的に指定しない限り、Splunk はデフォルトのインデックス (デフォルトでは main) を
象にサーチを実施します。たとえば、以下のサーチコマンドは、hatch インデックスをサーチします。
18
String
index=hatch userid=henry.gale
また、特定のロールの作成/編集時に別のデフォルトインデックスを設定して、それに してサーチを実行すること
も可能です。
Splunk からのインデックスとデ ー タの削除
インデックス作成したデータまたはインデックス全体を Splunk から削除できます。主なオプションを以下に示し
ます。
今後のサーチからイベントを削除する。
1 つまたは複数のインデックスからすべてのデータを削除する。
インデックス全体を削除または無効にする。
リタイアポリシーに基づいて古いデータを削除する。
警告：削除したデータを元に すことはできません。ここで 明している方法で削除したデータを元に したい場合
は、適切なデータソースからデータのインデックスを再作成する必要があります。
今後のサ ー チからイベントを削除する
Splunk には、今後のサーチからイベントデータを削除するための特別な演算子 delete が用意されていま
す。delete を使用する前に、このセクションを注意深くお読みください。
注意：リアルタイムサーチ時には delete 演算子を実行できず、到着するイベントを削除することはできません。
リアルタイムサーチ時に delete の使用を試みると、エラーメッセージが表示されます。
削除できるユーザーは？
演算子は、「delete_by_keyword」 限を持つユーザーのみが実行できます。Splunk にはデフォルトで、特
殊ロール「can_delete」が用意されており、このロールがこの 限を保有しています (他は保有していない)。デフォ
ルトで、管理者ロールにはこの 限が与えられていません。インデックスデータを削除する際にログインする、特
別なユーザーを作成しておくことをお勧めします。
delete
詳細は、『Security Manual』の「Add and edit roles」を参照してください。
削除方法
まず、削除 象イベントを返すサーチを実行します。このサーチは削除 象イベントのみを返し、その他のイベント
は返さないことを入念に確認してください。確認できたら、パイプを使ってサーチ結果を delete 演算子に渡しま
す。
たとえば、ソース /fflanda/incoming/cheese.log からインデックス作成したイベントを削除して、今後のサーチ
に表れないようにする場合は、以下の作業を行います。
1. 今後インデックスが作成されないように、 象のソースを無効化または削除します。
2. インデックスから、当該ソースのイベントをサーチします。
source="/fflanda/incoming/cheese.log"
3. 削除 象データが正しく返されているかどうか、結果を確認します。
4. これらのデータが目的の削除データだと確認できたら、パイプ文字を使ってサーチを delete に渡します。
source="/fflanda/incoming/cheese.log" | delete
その他の例については、『Search Reference Manual』の delete 演算子に関する項目を参照してください。
サーチを delete 演算子に渡すことにより、そのサーチから返されるすべてのイベントがマークされます。マーク
されたイベントは、今後のサーチでは返されません。Splunk でサーチを実行して、このデータを参照できるユー
ザーは存在しません (管理 限を持つユーザーを含む)。
注意：パイプ文字を使って delete に結果を渡してもディスクスペースが えることはありません。
また、delete 演算子はイベントのメタデータを更新することもありません。そのため、任意のメタデータサーチ
には引き続きそれらのイベントが含まれますが、それらはサーチ不可となっています。メインのすべてのインデッ
クスデータダッシュボードには、削除されたソース、ホスト、またはソースタイプのイベント数が引き続き表示さ
れます。
19
1 つまたは複 数 のインデックスからのデ ー タの削除
ディスクからインデックスデータを永久に削除するには、CLI の clean コマンドを使用します。このコマンドは
<index_name> 引数の指定内容に じて、1 つまたはすべてのインデックスからデータを完全に削除します。一般的
に clean は、すべてのデータのインデックスを再作成する前に実行します。
注意：CLI の clean コマンドは、Windows 版も含めてすべてのバージョンの Splunk で使用できます。Windows
版の Splunk で CLI コマンドを発行する際には、以下に記載されている例のスラッシュ (/) の代わりに、円記号 (\)
を使用してください。
clean コ マ ン ド の 使 用 方 法
ここでは、clean コマンドの主な使用方法について 明していきます。
clean
のヘルプを表示するには、以下のコマンドを入力します。
splunk help clean
すべてのインデックスからイベントデータを削除するには、以下のコマンドを入力します。
splunk clean eventdata
1 つのインデックスからイベントデータを削除するには、以下のコマンドを入力します。
splunk clean eventdata -index <index_name>
ここで、<index_name> は 象となるインデックス名を表しています。
clean
で確認のメッセージを表示しない場合は、-f パラメータを追加します。
重要：clean コマンドを実行する前には、Splunk を停止する必要があります。
注意：5.0 より前のバージョンの Splunk では、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
インデックス全 体 の削除
インデックス全体を削除するには (それに含まれているデータのみではなくすべてを削除)、CLI コマンドの remove
index を使用します。
splunk remove index <index_name>
このコマンドは、インデックスのデータディレクトリを削除し、また indexes.conf からインデックスのスタンザ
を削除します。
このコマンドを実行する前に、すべての inputs.conf ファイルを参照して (インデクサーおよびインデクサーに
データを転送するフォワーダー上のファイル)、削除 象インデックスにデータを送るように指示しているスタンザ
がないことを確認してください。たとえば、インデックス「nogood」まを削除する場合、データ入力スタンザ内
に属性/値のペア index=nogood が指定されていないことを確認します。. インデックスが削除されたら、以降その
インデックスに送信されるデータは破棄されます。
remove index
を実行する場合、インデクサー上の任意のデータ取り込み設定が、そのインデックスにデータを送
20
るように設定されていると、警告のメッセージが表示されます (フォワーダー上の設定は確認されません)。以下の
ようなメッセージが表示されます。
03-28-2012
03-28-2012
03-28-2012
03-28-2012
23:59:22.973
23:59:22.973
23:59:22.973
23:59:22.973
-0700
-0700
-0700
-0700
WARN
WARN
WARN
WARN
IndexAdminHandler
IndexAdminHandler
IndexAdminHandler
IndexAdminHandler
-
Events from the following 3 inputs will now be discarded, since they
type: monitor, id: /home/v/syslog-avg-1000-lines
type: monitor, id: /mnt/kickstart/internal/fermi
type: monitor, id: /mnt/kickstart/internal/flights
の動作中に remove index を実行することができます。コマンド実行完了後、splunkd を再起動する必要は
ありません。
splunkd
インデックス削除処理は比較的高速ですが、処理完了までにかかる時間はさまざまな要因によって異なります。
削除 象データの量。
同じディスク上の他のインデックスに大量の書き込みを行っているかどうか。
削除 象インデックスに小さな .tsidx ファイルが大量に存在しているかどうか。
インデックスを削除せずに無 効 化する
インデックスを削除しないで無効化する場合は、disable index CLI コマンドを使用します。
splunk disable index <index_name>
コマンドと違い、disable index コマンドはインデックスデータを削除しません。無効化したデータ
は再び有効にすることができます (enable index コマンドを使用)。ただし、インデックスを無効化する
と、splunkd はそのインデックスを 象にしたデータを受け付けません。
remove index
Splunk Web でインデックスを無効化することもできます。この場合は、[管理] > [インデックス] に移動した後、
目的のインデックスの右側にある [無効] をクリックします。
リタイアポリシ ー に基づいて古いデ ー タを削除
インデックス内のデータが指定期間を 過した場合、またはインデックスのサイズが指定値に達した場合、それは
「フローズン」状態に移行します。この時点で、そのデータはインデックスから削除されます。リタイアポリシー
の設定内容によっては、データを削除する前に、それをアーカイブに移動することもできます。
詳細は、このマニュアルの「リタイアおよびアーカイブポリシーの設定」を参照してください。
インデックスの最適化
Splunk によるデータインデックスの作成中に、splunk-optimize プロセスの 1 つまたは複数のインスタンスが断
続的に実行され、データサーチ時のパフォーマンスを最適化するためにインデックスファイルが結合されま
す。splunk-optimize プロセスはほんの短時間ですが、CPU を大幅に使用することがあります。splunk-optimize
の同時インスタンス数は、indexes.conf の maxConcurrentOptimizes 値を 更して減らすことができますが、一般的
にはこの作業は必要ありません。
splunk-optimize
が十分な頻度で実行されない場合は、サーチ効率が低下してしまいます。
は、ホットバケツ上でのみ実行されます。大量のインデックス (.tsidx) ファイルがある場合 (一
般的には 25 以上) は、ウォームバケツで手動実行することも可能です。splunk-optimize を実行するに
は、$SPLUNKHOME/bin に移動して以下のコマンドを入力します。
splunk-optimize
splunk-optimize -d|--directory <bucket_directory>
には、さまざまなオプションパラメータを指定できます。利用できるパラメータを表示するに
は、以下のコマンドを入力します。
splunk-optimize
splunk-optimize
バケツの詳細は、「Splunk によるインデックスの保管方法」を参照してください。
インデックスストレ ー ジの管理
Splunk によるインデックスの保管方法
21
Splunk がデータのインデックスを作成するにつれて、一連のファイルが作成されます。これらのファイルには、2
種類のデータが含まれています。
縮形式の raw データ (rawdata)
raw データを指すインデックスといくつかのメタデータファイル (インデックスファイル)
Splunk のインデックスは、これらのファイルにより構成されています。一連のディレクトリに保管されている
ファイルは、その 過時間で管理されています。一部のディレクトリには、新たに作成されたインデックスデータ
が含まれています。他のディレクトリには、以前に作成されたインデックスデータが含まれています。このような
ディレクトリ数は、インデックスを作成するデータ量に じて、とても大きくなる場合があります。
注意事項
実際にはさほど気にする必要はありません。Splunk はデフォルトで、インデックスデータをさまざまな段階を て
管理、処理します。一般的に数年後など、長期間の 過後には、Splunk は古いデータをシステムから削除します。
デフォルトのスキーマでも十分に役立ちます。
ただし、大量のデータのインデックスを作成する、特別なデータ保持要件がある、またはその他 過時間に関する
ポリシーを入念に 討する必要があるような場合は、このトピックを参考にしてください。また、データをバック
アップするような場合にも、どこにデータがあるのかを理解するためにこの記事が役立ちます。どうぞご一読くだ
さい。
Splunk のデ ー タ 過時間の仕組み
各インデックスディレクトリは、バケツと呼ばれています。現在まで学習したことをまとめると：
Splunk のインデックスには、 縮された raw データと関連するインデックスファイルが含まれている。
Splunk インデックスは、多数の 過時間が指定されたインデックスディレクトリにまたがって存在してい
る。
インデックスディレクトリはバケツである。
バケツはその 過時間の 過に伴い、さまざまなステージに移行します。
ホット
ウォーム
コールド
フローズン
バケツは、その 過時間が 過するにつれて、あるステージから別のステージへと移行していきます。嵐にインデッ
クスが作成されたデータはホットバケツに保管されます。ホットバケツは、サーチ可で積極的に書き込まれます。
ホットバケツが一定のサイズに達すると、それはウォームバケツになり (ウォームに移行)、新たなホットバケツが
作成されます。ウォームバケツはサーチ可ですが、積極的には書き込まれません。ウォームバケツは多数存在して
います。
Splunk が作成したウォームバケツが最大数に達すると、その 過時間に基づいてウォームバケツからコールドバケ
ツへの移行が開始されます。常に一番古いバケツがコールドバケツに移行されます。バケツはこのようにして、時
間の 過に伴い順次コールドバケツに移行していきます。設定されている期間が 過すると、コールドバケツはフ
ローズンバケツに移行します。この時点でバケツはアーカイブまたは削除されます。indexes.conf 内の属性を編集
することで、バケツの 過時間ポリシーを指定することができます。このポリシーは、バケツのあるステージから
次のステージへの移行時期を示します。
バケツが移行する各ステージを以下に示します。
バケツの
ステージ
明
サーチ可？
ホット
新たにインデックスが作成されたデータを保管し
ています。書き込み可能。各インデックスに し
はい
て 1 つまたは複数のホットバケツ。
ウォーム
ホットから移行されたデータ。ウォームバケツは
はい
多数存在しています。
コールド
ウォームから移行されたデータ。コールドバケツ
はい
は多数存在しています。
フローズ
ン
コールドから移行されたデータ。デフォルトで
は、フローズンデータは削除されますが、アーカ
いいえ
イブすることも可能です。アーカイブされたデー
タは、後ほど解凍することができます。
22
特定のステージのバケツの集合体は、データベースまたは DB と呼ばれることもあります。たとえば、ホット
DB、ウォーム DB、コールド DB などのように呼ばれます。
注意：ホットバケツは、splunkd の再起動時に常に移行されます。
インデックスディレクトリの 内 容
各バケツには、サブディレクトリが存在しています。Splunk は、ホット/ウォーム/コールドバケツを区別するため
に、ディレクトリを編成管理しています。また、バケツディレクトリ名は、データの 過時間に基づいています。
デフォルトインデックス (defaultdb) のディレクトリ構造を以下に示します。
バケツ
タイプ
デフォルトの場所
メモ
ホット $SPLUNK_HOME/var/lib/splunk/defaultdb/db/*
複数のホットサブディレクトリが存在する場合
があります。各ホットバケツは独自のサブディ
レクトリを保有しています。サブディレクトリ
の命名規則を以下に示します。
hot_v1_<localid>
ウォー
$SPLUNK_HOME/var/lib/splunk/defaultdb/db/*
ム
各ウォームバケツ個別のサブディレクトリが存
在しています。これらの名前は、「ウォーム/
コールドバケツの命名規則」の 明に従って付け
られます。
複数のコールドサブディレクトリが存在してい
ます。ウォームバケツがコールドに移行される
と、データはこのディレクトリに移動されます
が名前は 更されません。
コール
$SPLUNK_HOME/var/lib/splunk/defaultdb/colddb/*
ド
注意：クラスタ内で、バケツの複製されたコ
ピーはすべて colddb ディレクトリに保管されま
す。ホット、ウォーム、またはコールドかどう
かは関係ありません。ただし、元のクラスタバ
ケツのコピーは、この表に記載されている標準
の場所に保管されます。たとえば clusterpeer1
が新しいホットバケツを作成し、それを
clusterpeer2 に複製した場合、clusterpeer1 上の
元のホットバケツのコピーは db ディレクトリに
保管されます。clusterpeer2 上の複製された
ホットバケツのコピーは、colddb ディレクトリ
に保管されます。クラスタとバケツの詳細は、
このマニュアルの「バケツとクラスタ」を参照
してください。
フロー N/A：フローズンデータは、削除されるかまたは指定
ズン
ディレクトリにアーカイブされます。
デフォルトでは削除されます。代わりにデータ
をアーカイブする方法については、「インデッ
クスデータのアーカイブ」を参照してくださ
い。
解凍
アーカイブされて、後ほど解凍されたデータの
場所。アーカイブされたデータの解凍状態への
復元については、「アーカイブされたデータの
復元」を参照してください。
$SPLUNK_HOME/var/lib/splunk/defaultdb/thaweddb/*
ホット/ウォーム、およびコールドディレクトリへのパスは 更することができます。たとえば、コールドバケツを
ホット/ウォームバケツとは個別の場所に保管することができます。「インデックスストレージの設定」および
「インデックスデータへの複数パーティションの使用」を参照してください。
重要：すべてのインデックス保管場所は書き込み可能でなければなりません。
ウ ォ ー ム /コ ー ル ド バ ケ ツ の 命 名 規 則
バケツ名は、それに含まれているデータの時間範 を表しています。バケツの命名規則は、インでクサーがクラス
タピアとして機能している間にウォームに移行されたかどうかによって、わずかに異なっています。
23
非クラスタバケツの場合： db_<newest_time>_<oldest_time>_<localid>
クラスタ化された元のバケツコピーの場合： db_<newest_time>_<oldest_time>_<localid>_<guid>
クラスタ化された複製バケツコピーの場合： rb_<newest_time>_<oldest_time>_<localid>_<guid>
ここで：
および <oldest_time> は、保管されているデータの 過時間を表すタイムスタンプです。タイ
ムスタンプは、UTC エポック時 (秒) で表されています。例：db_1223658000_1223654401_2835 は、2008 年
10 月 10 日からの期間が午前 9 時 午前 10 時のデータを含む、非クラスタウォームバケツです。
<localid> は、元のバケツが存在しているインデクサーが生成したバケツの ID です。
<guid> は、元のバケツが存在しているピアノード (インデクサー) の guid です。guid はピアの
$SPLUNK_HOME/etc/instance.cfg ファイルにあります。
<newest_time>
クラスタ内で、元のバケツと複製されたコピーは同じ名前を持ちますが、プリフィックスが異なっています (元の
バケツは db、複製されたコピーは rb)。
注意：クラスタ内で、データが元のピアからターゲットピアに転送される場合、データはまずターゲットピアの一
時ディレクトリに保管されます。このディレクトリは、元のピアの <localid> および <guid> で示されます
(例：<localid>_<guid>)。. これは、データの転送元バケツの種類に関係なく当てはまります。複製が完了した
ら、このディレクトリがウォームバケツに移行され、前述のようにプリフィックス rb_ が付けられます。クラスタ
のアーキテクチャと複製されたデータの転送の概要は、「基本的なクラスタアーキテクチャ」を参照してくださ
い。
重要：バケツの命名規則は 更される可能性があります。
バケツと Splunk の管理
Splunk を管理する際には、Splunk がバケツにどのようにインデックスを保管するのかを理解しておくと役立ちま
す。特に、さまざまな管理作業を行うためには、バケツを正しく理解しておく必要があります。
リタイアおよびアーカイブポリシーの設定方法については、「リタイアおよびアーカイブポリシーの設定」を参照
してください。リタイアポリシーは、データのサイズまたは 過時間に基づいて設定することができます。
インデックスデータのアーカイブ方法の詳細は、「インデックスデータのアーカイブ」を参照してください。署名
のアーカイブについては、『Security Manual』の「Configure archive signing」を参照してください。アーカイブ
からのデータの復元方法については、「アーカイブされたデータの復元」を参照してください。
データのバックアップ方法については、「インデックスデータのバックアップ」を参照してください。このトピッ
クでは、手動によるホットバケツからウォームバケツへの移行 (バックアップできるようにするため) 方法につい
ても 明されています。また、Community Wiki の「Best practices for backing up」も参照してください。
ディスク使用量の制限値の設定については、「ディスク使用量の制限の設定」を参照してください。
バケツの設定項目の一覧については、「インデックスストレージの設定」を参照してください。
バケツのトラブルシュ ー ティング
ここでは、バケツに関するさまざまな問題の 処方法について 明していきます。
クラッシュ後の回復
通常 Splunk は、ユーザーの介入なしでクラッシュ後の回復を行えます。予期しない問題でインデクサーが停止し
た場合、最後の方で受信したデータをサーチできないことがあります。Splunk を再起動すると、バックグラウン
ドで fsck が自動実行されます。このコマンドは、バケツのヘルス状態を診断して、必要に じてサーチデータを再
構築します。
の手動実行が必要になるようなことはほとんどありません。このコマンドを手動実行する場合は、Splunk を
停止する必要があります。また、インデックスが大きい場合は、コマンドの完了までに数時間かかることもありま
す。それまでの間は、データにアクセスできません。ただし、Splunk サポートからこのコマンドの実行が指示さ
れた場合に備えて、このセクションの残りの部分では実行方法を 明しています。(また、4.2.x インデクサーを回復
する場合も、fsck を手動実行する必要があります。このコマンドは、Splunk インデクサー 4.3 以上でのみ自動的
に実行されます。)
fsck
を手動実行するには、まず Splunk を停止する必要があります。次に、 象のバケツに して fsck を実行しま
す。すべてのインデックスのバケツに して fsck を実行するには、以下のコマンドを使用します。
fsck
splunk fsck --repair --all
この場合、すべてのインデックスのすべてのタイプのバケツ (ホット/ウォーム/コールド/解凍) が再構築されます。
24
注意：fsck コマンドは、Splunk 4.2 以上で作成されたバケツのみを再構築します。
fsck
コマンドの詳細、および利用できるオプションの一覧を表示するには、以下のコマンドを実行してくださ
い。
splunk fsck
警告：インデックスのサイズによっては、fsck --repair コマンドの完了までに数時間かかることもあります。こ
のことが、可能な場合は Splunk にバックグラウンドでこのコマンドを実行させる理由です。また、一部のバケツ
のみを再構築する必要がある場合は、次の「バケツの再構築」の 明に従って、それらのバケツに してのみ
rebuild コマンドを実行することができます。
単にインデックスの状態を診断したいだけの場合は (復旧措置を行わない)、--repair フラグを指定しないで fsck
を実行します。
splunk fsck --all
バケツの再構築
バケツ内のインデックスおよびメタデータファイル (バージョン 4.2 以上) が何らかの理由で壊れた場合、raw デー
タファイルからバケツを再構築することができます。以下のコマンドを使用してください。
splunk rebuild <bucket directory>
古いインデックスおよびメタデータファイルが自動的に削除、再構築されます。自分でファイルを削除する必要は
ありません。
重要：rebuild コマンドを実行する前に、Splunk を停止する必要があります。
注意事項：
バケツの再構築は、ライセンスのカウント 象ではありません。
バケツの再構築を完了するまでに、長時間かかることがあります。ハードウェアの仕 などシステム上のさま
ざまな要因により、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. 成功したら、バケツを通常の名前に 更します。
インデックスレベルのバケツマニフェストの再構築
インデックスレベルのマニフェストを再構築する必要はほとんどありませんが、必要な場合に備えてそのためのコ
マンドがいくつか用意されています。
警告：これらのコマンドは、Splunk サポートから指示された場合にのみ使用してください。独自にマニフェスト
を再構築しないようにしてください。
インデックスレベルのマニフェストファイルには、.bucketManifest と .metaManifest の 2 種類のファイルがあり
ます。.bucketManifest ファイルには、インデックス内のすべてのバケツのリストが含まれています。たとえば、
バケツをインデックスに手動コピーしたような場合に、これの再構築が必要になります。.metaManifest ファイル
には、インデックスレベルのメタデータファイルに寄与するバケツのリストが含まれています。
25
以下のコマンドは、.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
その他の 参 考情報
インデックスストレージとバケツの詳細については、以下の各トピックを参照してください。
インデックスストレージの設定
インデックスデータ用の複数パーティションの使用
インデックスストレージの設定
バケツとクラスタ
また、『管理マニュアル』の「indexes.conf」および Community Wiki の「Understanding buckets」も参照してく
ださい。
インデックスストレ ー ジの設定
インデックスは、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
この場所は書き込み可能でな
ければなりません。
$SPLUNK_HOME/var/lib/splunk/
(デフォルトのイ
ンデックスのみ)
defaultdb/db/
詳細は、以下
の項目を参照...
インデックス
データ用の複
数パーティ
ションの使用
コールドバケツを保管するパ
ス (必須)。
coldPath
クラスタでは、これはすべて
の複製されたバケツのコピー
の場所にもなります。この場
所は書き込み可能でなければ
なりません。
26
$SPLUNK_HOME/var/lib/splunk/
(デフォルト
のインデックスのみ)
defaultdb/colddb/
インデックス
データ用の複
数パーティ
ションの使用
解凍されたバケツを保管する
パス (必須)。
thawedPath
この場所は書き込み可能でな
ければなりません。
$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 が
使用され、この属性は無視さ
れます。
(ホット/ウォームバケ
ツストレージ) または coldPath
homePath
27
Splunk のデー
タ 過時間の仕
組み
インデックス
データ用の複
数パーティ
ションの使用
リタイアおよ
びアーカイブ
ポリシーの設
定
この属性または
のどちらも
設定しない場合、バケツがフ
ローズンに移行されると、バケ
ツのディレクトリ名のみがログ
に記 され、バケツは削除されま
す。
coldToFrozenScript
インデックス
作成された
データのアー
カイブ
この属性または
のどちらも設
定しない場合、バケツがフロー
ズンに移行されると、バケツの
ディレクトリ名のみがログに記
され、バケツは削除されます。
coldToFrozenDir
インデックス
作成された
データのアー
カイブ
homePath.maxDataSizeMB (コールドバケツストレージ) の
最大サイズ。どちらかの属性
なし
coldPath.maxDataSizeMB が存在しない、または 0 が設
定されている場合、そのパス
はサイズによる制約を受けま
せん。
maxVolumeDataSizeMB
ボリュームの最大サイズ。属
性が指定されていない場合、
個別のボリュームのサイズに
制約はありません。
なし
バケツタイプ
によるイン
デックスサイ
ズの設定
ボリュームに
よるインデッ
クスサイズの
設定
注意： 非クラスタインデックスの場合のみ、Splunk 管理を使ってインデックスへのパスを設定することができま
す。[Splunk 管理] > [システム設定] > [全般設定] に移動してください。[インデックス設定] で、[インデックスへの
パス] フィールドを設定します。この作業を行った後は、CLI から Splunk を再起動する必要があります ([管理] か
らではない)。
インデックスデ ー タベ ー スの移動
インデックスデータベース全体を、ある場所から別の場所に移動できます。ここでは、そのための手順について
明していきます。この手順では、インデックスデータベースがインストール時に作成されるデフォルトの場所に存
在していることを前提にしています。
個別のインデックスまたはインデックスの一部を別の場所に移動することも可能です。いったん移動すると、その
後の移動操作はここで 明している手順とは異なります。Splunk インデックスの構造の詳細は、「Splunk によるイ
ンデックスの保管方法」を参照してください。単一のインデックスの場所の 更方法については、「インデックス
ストレージの設定」を参照してください。
*nix ユ ー ザ ー の場合
1. ターゲットファイルシステムに十分なスペースがあることを確認してください。最低でもインデックス作成の
象となる raw データの合計サイズの 1.2 倍以上のスペースが必要です。
2. ターゲットディレクトリを作成し、それに して Splunk が実行するユーザーに する書き込み 限があることを確
認してください。たとえば、Splunk がユーザー「splunk」として実行される場合、そのユーザーにディレクトリ
の所有 を与えてください。
mkdir /foo/bar
chown splunk /foo/bar/
Splunk を実行するユーザーの設定については、このトピックを参照してください。
3. 新しいインデックスホームの準備が完了したら、Splunk を停止します。$SPLUNK_HOME/bin/ ディレクトリに移
動して、以下のコマンドを実行します。
splunk stop
4. 既存のインデックスファイルシステムを新しいホームにコピーします。
cp -rp $SPLUNK_DB/* /foo/bar/
5. SPLUNK_DB 環境 数の設定を解除します。
unset SPLUNK_DB
6. 新しいインデックスディレクトリを反映するように、./etc/splunk-launch.conf を編集します。このファイル
の SPLUNK_DB 属性を、新たなインデックスディレクトリを指すように 更します。
SPLUNK_DB=/foo/bar
7. Splunk を開始します。$SPLUNK_HOME/bin/ に移動して、以下のコマンドを実行します。
splunk start
Splunk サーバーは新しいインデックスのコピーの読み込み、書き込みを行う場所を認識します。
28
8. Splunk が新しい場所から読み取り/書き込みできることを確認したら、古いインデックスデータベースを削除す
ることができます。
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 runs as>:F
Splunk を実行するユーザーについては、Windows への Splunk のインストールに関するトピックを参照してくだ
さい。
注意： Windows Vista、7、Server 2003、および Server 2008 ユーザーは、icacls を使ってディレクトリ 限が正
しいかどうかを確認できます。Microsoft TechNet の記事に、特定のコマンドライン引数に関する情報が記載され
ています。
3. Splunk を停止します。%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 を開始します。%SPLUNK_HOME%\bin ディレクトリに移動して、以下のコマンドを実行します。
splunk start
Splunk サーバーは新しいインデックスのコピーの読み込み、書き込みを行う場所を認識します。
8. Splunk が新しい場所から読み取り/書き込みできることを確認したら、古いインデックスデータベースを削除す
ることができます。
Splunk 管理を使ったインデックスへのパスの 更
Splunk 管理を使って、インデックスへのパスを 更することができます。インデックスを実際に移動する前に 明し
た手続きとは異なり、Splunk 管理でパスを 更した場合、その 更は新たにインデックスに到着したデータにのみ適
用されます。そのため、このような目的で Splunk 管理を使用することは、データの取り込みを開始する前の新し
いインデクサーにのみ限定することをお勧めします。
パスを 更するには：
1. [管理] > [システム設定] > [全般設定] に移動します。
2. このページの [インデックス設定] にある [インデックスへのパス] フィールドに移動します。
29
3. このフィールドに新しいパスを入力します。ここに、新たなインデックスデータが保管されます。
4. ご利用の環境で SPLUNK_DB 環境 数が設定されている場合は、その設定を解除します。
*nix の場合、コマンドラインから以下のコマンドを入力します。
unset SPLUNK_DB
Windows の場合、コマンドラインから以下のコマンドを入力します。
set SPLUNK_DB=
5. CLI を使って Splunk を再起動します。$SPLUNK_HOME/bin/ (*nix) または %SPLUNK_HOME%\bin (Windows) に移動し
て、以下のコマンドを実行します。
splunk restart
重要：Splunk 管理内で再起動機能を使用しないでください。これには、目的としているインデックスディレクト
リを 更する効果はありません。CLI から再起動する必要があります。
インデックスデ ー タ用の複 数 パ ー ティションの使
用
Splunk は、インデックスデータ用に複数のディスクおよびパーティションを利用できます。複数のインデックス
やバケツタイプに基づいて、多数のディスク/パーティション/ファイルシステムを使用するように設定することが
できます。ただし、それらを正しくマウントして、indexes.conf からそれらを正しく指すように設定する必要が
あります。しかし、最良の結果を得るためには、単一の高性能ファイルシステムを使って Splunk インデックス
データを保持/管理することをお勧めします。
複数のパーティションを使用する場合、Splunk のインデックスデータを配置するもっとも一般的な方法は、ロー
カルマシン上にホット/ウォームバケツを保持し、コールドバケツを別個のディスクアレイに格納することです (長
期保存用)。高速な読み取り/書き込みパーティションを持つマシン上にホット/ウォームバケツを配置することをお
勧めします。大半のサーチはここで行われます。コールドバケツは、信頼性の高いディスクアレイに配置してくだ
さい。
重要：クラスタを使用している場合、コールドストレージの要件はまったく異なっています。後述する「クラスタ
と coldPath」を参照してください。
複 数 のパ ー ティションの設定
複数のパーティションを設定するには：
1. 普段 OS で設定しているように、パーティションを設定します。
2. ディスク/パーティションをマウントします。
3. パーティションの正しいパスを指すように、indexes.conf を編集します。パスはインデックス単位で設定しま
す。そのため、インデックスごとに個別のパーティションを設定することができます。各インデックスには、独自
の [<index>] スタンザが存在し、<index> がインデックス名となっています。これらは、設定可能なパス属性で
す。
homePath = <path on server>
これは、インデックスのホットおよびウォームデータベースを含むパスです。
警告：パスは書き込み可能でなければなりません。
coldPath = <path on server>
これは、インデックスのコールドデータベースを含むパスです。
警告：パスは書き込み可能でなければなりません。
重要：クラスタの場合、このパスはすべての複製されたバケツのコピーの保管場所としての役割も果
たします。(クラスタバケツの元のコピーは、バケツの種類に じて標準のディレクトリに保管されてい
ます。)そこで、coldPath ディレクトリに して使用するストレージの種類には、クラスタとはまったく
異なる要件が存在しています。「クラスタと coldPath」を参照してください。
thawedPath = <path on server>
これは、インデックスの解凍されたデータベースを含むパスです。
30
クラスタと coldPath
クラスタ内で、coldPath ディレクトリに して使用するストレージには、homePath のストレージと同じ特性がなけ
ればなりません。バケツの複製されたコピーはすべて、coldPath ディレクトリに保管されるためです。ホット、
ウォーム、またはコールドかどうかは関係ありません。coldPath に して いストレージを使用した場合、クラスタ
の総合的なパフォーマンスが低下してしまいます。
通常 coldPath にさほど頻繁にはアクセスされないデータが含まれているため、低速なディスクアレイに配置でき
る、非クラスタ構成のインデクサーとは違い、クラスタの場合はそのニーズを たすために、coldPath に してパ
フォーマンスの高いストレージを使用する必要があります。たとえば、クラスタピアの coldPath に存在するバケ
ツの一部が、引き続き書き込まれている複製されたホットバケツである場合があります。他のバケツはウォームコ
ピーに複製され、サーチヘッドはそれらに頻繁にアクセスします。また、クラスタの設定および今後何が行われる
か (ピアがオフラインになるなど) に じて、ピアのバケツコピーをサーチ不可からサーチ可に 換しなければなら
ず、coldPath データの処理にかなりの時間がかかることもあります。
クラスタ動作の詳細は、「クラスタおよびインデックスレプリケーションについて」およびそれ以降のトピックを
参照してください。特に、「システム要件」にはクラスタストレージのハードウェアに関する詳細な情報が記載さ
れています。
インデックスサイズの設定
インデックスストレージサイズは、さまざまな方法で設定できます。
インデックス単位
ホット/ウォームバケツ用とコールドバケツ用を個別に
ボリュームを使ってインデックス間にまたがって
インデックスストレージサイズを設定するには、indexes.conf に属性を設定します。このトピックで取り上げてい
る属性の詳細は、「インデックスストレージの設定」を参照してください。
警告：インデックスの処理中には、短時間ですが設定されている最大値を超える場合があります。制限を設定する
際には、いくらかのバッファ領域を確保するようにしてください。また、大部分の UNIX システムなど特定のシス
テムでは、そのパーティション上に設定可能な予約スペースが維持されていることに注意してください。インデッ
クスサイズを決定する際には、そのような予約スペースも考慮する必要があります。
各インデックスのインデックスサイズの設定
インデックス単位に最大インデックスサイズを設定するには、maxTotalDataSizeMB 属性を使用します。この限度
に達すると、バケツのフローズンへの移行が開始されます。
バケツタイプによるインデックスサイズの設定
(ホット/ウォームバケツストレージ) または coldPath (コールドバケツストレージ) の最大サイズを設定す
るには、maxDataSizeMB 属性を使用します。
homePath
# set hot/warm storage to 10,000MB
homePath.maxDataSizeMB = 10000
# set cold storage to 5,000MB
coldPath.maxDataSizeMB = 5000
属性はグローバルに、または各インデックスに して設定できます。インデックスレベルの設定は、
グローバル設定に優先します。インデックスのグループにまたがってバケツストレージを設定するには、後述の
maxVolumeDataSizeMB 属性を使用します。
maxDataSizeMB
ボリュ ー ムによるインデックスサイズの設定
ボリュームを作成して、最大データサイズを設定することにより、複数のインデックスにまたがってディスク使用
量を管理できます。ボリュームは、インデックス作成したデータを保管するファイルシステム内のディレクトリを
表します。
ボリュームには、複数のインデックスからのデータを保管できます。一般的には、ホット/ウォームバケツ用と
コールドバケツ用に個別のボリュームを使用します。たとえば、あるボリュームにすべてのインデックス用のホッ
ト/ウォームバケツを格納し、別のボリュームにはコールドバケツを格納するように設定できます。
ボリュームを使って homePath および coldPath を定義することができます。これを使って thawedPath を定義する
ことはできません。
31
また、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
[volume:frio]
path = /mnt/big_disk
32
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 はさまざまな方法でディスクスペースを制御しています。インデックスは、ディスクスペースの大半を消
費します。ディスクスペースが不足すると、インデックスの作成が停止されます。最低空きスペースの制限値を設
定して、インデックスの作成を停止するまでの空きディスクスペース量を制御することができます。空きスペース
量が制限値以上に回復すると、インデックスの作成が再開されます。
注意：インデックスに必要なスペース量を判断するには、『Installation Manual』の「Estimate your storage
requirements」を参照してください。
最低空きディスクスペ ー スの設定
インデックスデータを保管するディスクの最低空きディスクスペース量を設定できます。制限値に達すると、
Splunk は動作を停止します。これはインデックスとサーチの両方に影響します。
Splunk は定期的に、インデックスを保管しているすべとのパーティションの空きスペースをチェックしま
す。いずれかのパーティションで空きディスクスペース制限値に達すると、その値より多くのスペースが利
用できるようになるまでの間、データのインデックス作成が中止されます。ディスクスペースを確保する必
要があることを知らせる、UI バナーおよび splunkd 警告が表示されます。
サーチを実行する前に、ディスパッチディレクトリが保管されている
$SPLUNK_HOME/var/run/splunk/dispatch のファイルシステム上で、指定された量の空きディスクを確保する
必要があります。
デフォルトの最低空きディスクスペース量は 2,000 MB です。
注意：
この方法では、Splunk がデータの消去によりディスクスペースを確保することはありません。単により多く
の空きスペースが確保されるまで、処理を停止します。
インデックスの作成が停止中に到着したデータは失われる可能性があります。
最低空きディスクスペース量は、Splunk Web、CLI、または server.conf 設定ファイルを使って設定することがで
きます。
Splunk Web
Splunk Web で最低空きディスクスペースを指定するには：
1. Splunk Web の右上にある [管理] をクリックします。
2. [システム設定] をクリックします。
3. [全般設定] をクリックします。
4. [インデックス設定] セクションで、[空きディスクスペースがこの値 (MB) を下回ったらインデックスの作成を一
時停止] フィールドを設定します。
33
5. 最低空きディスクスペース量をメガバイトで入力します。
6. [保存] をクリックします。
7. 更内容を有効にするために、Splunk を再起動します。
コ マ ン ド ラ イ ン イ ン タ ー フ ェ イ ス (CLI) の 使 用
Splunk の CLI を使って最低空きディスクスペース量を設定することができます。この例では、最低空きディスク
スペースとして 20,000 MB (20 GB) を設定します。
splunk set minfreemb 20000
splunk restart
CLI の使用方法の詳細は、『管理マニュアル』の「CLI について」を参照してください。
server.conf
server.conf ファイルに最低空きディスクスペースを設定することもできます。関連するスタンザ/属性を以下に示
します。
[diskUsage]
minFreeSpace = <num>
<num>
はメガバイトです。デフォルトは 2000 です。
インデックスストレ ー ジの制御
indexes.conf ファイルには、インデックス設定が含まれています。最大インデックスサイズやデータの最大 過時
間などを指定して、ディスクストレージの使用を調整することができます。これらのいずれかの制限値に達する
と、もっとも古いインデックスデータが削除 (デフォルト) またはアーカイブされます。事前定義されているアー
カイブスクリプトを使用または独自のスクリプトを作成して、データをアーカイブすることができます。
を使った最大インデックスサイズまたは 過時間の設定方法については、「リタイアおよびアーカイ
ブポリシーの設定」を参照してください。
indexes.conf
インデックスストレージの詳細は、「Splunk によるインデックス保管の仕組み」を参照してください。
ブル ー ムフィルタの設定
ここでは、ブルームフィルタの概要およびそれを使ったパフォーマンス改善 (特に希な単語をサーチする場合) に
ついて 明していきます。
このトピックを読む前に、Splunk によるデータの保管方法およびデータの 過時間について理解しておく必要があ
ります。基本的に、インデックス作成されたデータはバケツと呼ばれるサブディレクトリから構成されるデータ
ベースディレクトリに保管されます。各インデックスには、独自のデータベースセットが存在しています。データ
はその 過時間の 過とともに、さまざまな種類のバケツに移行されます (ホット、ウォーム、コールド、フローズ
ン)。詳細は、「Splunk によるデータの保管」および「データの時間 過」を参照してください。
なぜブル ー ムフィルタを使用するのか？
ブルームフィルタは、エレメントがセットのメンバーかどうかをテストするために用いられるデータ構造です。ブ
34
ルームフィルタは、ディスク上の各バケツ内にファイルとして保管されます。サーチを実行する場合、特に希に登
場する単語をサーチする場合に、ブルームフィルタを使用するとインデックスからイベントを取得するまでの時間
を大幅に短縮することができます。
Splunk が時系列データのインデックスを作成するにつれて、raw データをタイムスタンプにより分類した raw
データを含む 縮ファイルと一連の時系列インデックス (tsidx) ファイルが作成されます。tsidx ファイルは、データ
内のすべてのキーワード (エラーコード、 答時間など) の辞書としての役割を果たす用語目 ファイルで、raw デー
タ内のイベントの場所への参照が含まれています。サーチを実行すると、tsidx ファイル内のキーワードが 索さ
れ、参照先の raw データファイルからイベントが取得されます。
ブルームフィルタはバケツレベルで機能し、個別のファイル bloomfilter を使用します。基本的にこれは、キー
ワードがバケツ内に存在しないことを知らせるハッシュテーブルです。そのため、サーチを実行する際には、ブ
ルームフィルタにより除外されていないバケツの tsidx ファイルのみをサーチするだけで みます。ディスクからイ
ベントを取得する実行コストは、tsidx ファイルのサイズと数に伴って 加します。ブルームフィルタにより Splunk
がサーチする必要がある tsidx ファイル数が減るため、各バケツのサーチにかかる時間も減少します。
ブルームフィルタは、バケツの tsidx ファイルに見つかった一意のキーワードをすべて保管する代わりに、各キー
ワードのハッシュを計算します。複数のキーワードが同じハッシュになる場合もあります。そのため、誤判定の可
能性はありますが、 出漏れは回避できます。ブルームフィルタはこのようにして、特定のバケツに存在しない単
語を素早く除外するため、Splunk は次のバケツのサーチに即座に取りかかることができます。ブルームフィルタ
が除外できなかったバケツ (バケツにキーワードが実際に存在するかどうかが分からない) に しては、通常のよう
にサーチが行われます。
ブル ー ムフィルタの設定
ブルームフィルタは、バケツがホットからウォームに移行する際に作成されます。デフォルトでは、バケツがフ
ローズンに以降するとフィルタが削除されます (別の保持設定を指定していない場合)。ここでは、ブルームフィル
タファイルの設定と管理に使用できる設定パラメータについて 明していきます。
ブルームフィルタを使用するかどうかを指定するには、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 index server>
* An absolute path that contains the bloomfilter files for the index.
* If not specified, it defaults to homePath.
* May contain a volume reference (see volume section below).
* MUST be defined in terms of a volume definition (see volume section below).
* CAUTION: Path must be writable.
* Must restart splunkd after changing this parameter; index reload will not suffice.
createBloomfilter = true|false
* Control whether to create bloomfilter files for the index.
* TRUE: bloomfilter files will be created. FALSE: not created.
* Defaults to TRUE.
また、bloomHomePath を明示的に定義する場合は、ボリュームを使用する必要があります。ボリュームは、イン
デックス作成したデータを保管するファイルシステム内のディレクトリを表します。詳細は、『インデクサーとク
ラスタの管理マニュアル』の「インデックスサイズの設定」を参照してください。
注意：バケツをホットからウォームに移行する時に、マーカーファイル corrupt.bloomOnly.maker が一時的に現れ
ます。このファイル名は紛らわしいですが、ブルームフィルタを破壊する訳ではありません。何も 処する必要は
ありません。単に無視してください。
インデックスのバックアップとア ー カイブ
インデックス作成されたデ ー タのバックアップ
インデックスデータのバックアップ方法を決めるためには、まず Splunk によるデータの保管方法、および時間の
過によるデータの取り扱いの仕組みを理解しておくことが大切です。その後、バックアップ方法を決定します。
このトピックを参照する前に、「Splunk によるインデックスの保管方法」を参照してインデックス構造とその設
35
定オプションを理解するようにしてください。その時間がない方のために、次のセクションにはそのトピックの要
点が記載されています。
デ ー タの時間 過
インデックス作成されたデータはバケツと呼ばれるサブディレクトリから構成されるデータベースディレクトリに
保管されます。各インデックスには、独自のデータベースセットが存在しています。
データは、時間が 過するにつれて、さまざまな種類のバケツに移行します。時間の 過に伴うデータの取り扱いに
ついては、indexes.conf の属性で設定します。indexes.conf の設定の詳細は、「インデックスストレージの設
定」を参照してください。
ここでは、Splunk インデックスでの、時間の 過に伴うデータの取り扱いについて簡単に 明しています。
1. 最初にデータのインデックスが作成されると、それはホットバケツに格納されます。設定によっては、複数のバ
ケツが同時に存在することもあります。ホットバケツは積極的に書き込まれるため、バックアップすることはでき
ません。ただし、スナップショットを取得することは可能です。
2. ホットバケツ内のデータは、ポリシーに設定されている条件を たすと「ウォーム」データに再分類されます。
これは、データのウォームバケツへの「移行」と呼ばれています。これは、ホットバケツが指定サイズまたは 過
時間に達した場合、または splunkd が再起動された時に行われます。ホットバケツの移行が実施されると、ディレ
クトリ名が 更されウォームバケツとなります。(手動でバケツをホットからウォームに移行することもできます。
詳細は以下を参照してください。)ウォームバケツのバックアップを行うこともできます。
3. インデックスが設定されている何らかの制限値に達した場合 (通常はウォームバケツ数)、もっとも古いバケツが
「コールド」バケツになります。バケツは colddb ディレクトリに移動されます。デフォルトのウォームバケツ数
は 300 です。
4. 最後に、定義されているポリシー要件に基づいて、バケツがコールドから「フローズン」に移行されます。
Splunk は、フローズンになったバケツを削除します。ただし、データを保持する必要がある場合は、バケツを削
除する前にデータをアーカイブすることができます。詳細は、「インデックスデータのアーカイブ」を参照してく
ださい。
インデックスやバケツのサイズまたはデータの 過時間などの各種パラメータを利用して、リタイアおよびアーカ
イブポリシーを設定することができます。
要約：
ホットバケツ - 現在書き込まれているバケツ、バックアップしないでください。
ウォームバケツ - ホットから移行されます、安全にバックアップできます。
コールドバケツ - ウォームから移行されます。バケツは別の場所に移動されます。
フローズンバケツ - これらのバケツは削除されますが、その前にアーカイブすることができます。
インデックスデータベースの場所は、indexes.conf に設定します。(デフォルトインデックスのデータベースの場
所の詳細については、後述しています。)また、ここにはホットバケツの最大サイズや 過時間など、さまざまな属
性を指定することができます。
インデックスデ ー タベ ー スディレクトリの場所
デフォルトインデックス (defaultdb) のディレクトリ構造を以下に示します。
バケツ
タイプ
デフォルトの場所
メモ
ホット $SPLUNK_HOME/var/lib/splunk/defaultdb/db/*
複数のホットサブディレクトリが存在する場合
があります。各ホットバケツは独自のサブディ
レクトリを保有しています。サブディレクトリ
の命名規則を以下に示します。
hot_v1_<ID>
ウォー
$SPLUNK_HOME/var/lib/splunk/defaultdb/db/*
ム
各ウォームバケツ個別のサブディレクトリが存
在しています。これらの名前は、「ウォーム/
コールドバケツの命名規則」の 明に従って付け
られます。
複数のコールドサブディレクトリが存在してい
ます。ウォームバケツがコールドに移行される
と、データはこのディレクトリに移動されます
36
が名前は 更されません。
コール
$SPLUNK_HOME/var/lib/splunk/defaultdb/colddb/*
ド
注意：クラスタ内で、バケツの複製されたコ
ピーはすべて colddb ディレクトリに保管されま
す。ホット、ウォーム、またはコールドかどう
かは関係ありません。ただし、元のクラスタバ
ケツのコピーは、この表に記載されているディ
レクトリ内の標準の場所に保管されます。
フロー N/A：フローズンデータは、削除されるかまたは指定
ズン
ディレクトリにアーカイブされます。
デフォルトでは削除されます。代わりにデータ
をアーカイブする方法については、「インデッ
クスデータのアーカイブ」を参照してくださ
い。
解凍
アーカイブされて、後ほど解凍されたデータの
場所。アーカイブされたデータの解凍状態への
復元については、「アーカイブされたデータの
復元」を参照してください。
$SPLUNK_HOME/var/lib/splunk/defaultdb/thaweddb/*
ホット/ウォーム、およびコールドディレクトリへのパスは 更することができます。たとえば、コールドバケツを
ホット/ウォームバケツとは個別の場所に保管することができます。「インデックスストレージの設定」および
「インデックスデータへの複数パーティションの使用」を参照してください。
重要：すべてのインデックス保管場所は書き込み可能でなければなりません。
バックアップ方針の選
基本的には 討する必要がある 2 種類のバックアップシナリオが存在しています。
続的な、ウォームデータの 分バックアップ。
すべてのデータのバックアップ (たとえば、Splunk のアップグレード前)
実際のバックアップ実行方法は、ご自分の組織で利用しているツールや手順によって異なりますが、ここでは必要
な作業に関するガイドラインを提供しています。
分バックアップ
一般的には、適切な 分バックアップユーティリリティを使って、新しいウォームバケツを定期的にバックアップ
するようにスケジュールすることをお勧めします。バケツが頻繁に移行されるような環境では、バックアップされ
る前にコールドバケツに移行されたデータを見逃さないように、コールドデータベースのディレクトリもバック
アップ 象にする必要があります。ウォームからコールドに移行する際に、バケツディレクトリ名は 更されないた
め、単に名前でフィルタリングすることができます。
ホットバケツもバックアップする場合は、VSS (Windows/NTFS) や ZFS (ZFS) などのツール、またはその他のス
トレージサブシステムが提供するスナップショット機能を使って、ファイルのスナップショットを取得する必要が
あります。利用できるスナップショットツールがない場合は、手動でホットバケツをウォームバケツに移行して、
それをバックアップすることができます (後述)。ただし、一般的にこのような行為は、後述する理由によりお勧め
できません。
すべてのデータのバックアップ
Splunk をアップグレードする前には、すべてのデータをバックアップすることをお勧めします。これには、ホッ
ト、ウォーム、およびコールドバケツが含まれます。
この作業を行うためには、データのサイズやどのくらいの時間システムを停止できるかなどの条件に じて、さま
ざまな方法を利用できます。基本的なガイドラインを以下に示します。
データが少量の場合は、Splunk をシャットダウンして、データベースディレクトリのコピーを作成してか
ら、アップグレードを実施してください。
大量のデータがある場合は、アップグレード前にホットバケツのスナップショットを取得する方が良いかも
しれません。
どのような場合でも、ホットから移行されたウォームバケツの 分バックアップを行っている場合は、この時点で
のみホットバケツをバックアップする必要があります。
ホットバケツのウォ ー ムへの手動移行
インデックスのバケツを手動でホットからウォームに移行するには、以下の CLI コマンドを使用しま
37
す。<index_name> には、移行するインデックス名を指定してください。
splunk _internal call /data/indexes/<index_name>/roll-hot-buckets a€“auth <admin_username>:<admin_password>
重要：強制的な移行はデータのサーチパフォーマンスを永久的に低下させるため、通常ホットバケツの手動移行は
お勧めできません。一般的には、バケツが大きいほどサーチを効率的に行えます。早期にバケツを移行すると、小
さくて非効率的なバケツを作成することになります。ホットデータをバックアップする必要がある場合は、スナッ
プショットの取得が推 するバックアップ手法になります。
復元の推 事項
致命的ではないディスク障害が発生した場合 (たとえば、一部のデータは残っているけれども Splunk を実行でき
ない場合) は、一部が壊れたデータストアの最上位から復元する代わりに、インデックスディレクトリを別の場所
に移動してバックアップから復元することをお勧めします。Splunk は起動時に必要に じてホットバケツを自動的
に作成し、インデックスの作成作業を再開します。監視 象ファイルとディレクトリは、バックアップ時の場所で
取得されます。
インデックスのバックアップ方法
インデックス内のすべてのデータを 日確実にバックアップするための手段については、Splunk ブログの「Index
backup strategy」を参照してください。
クラスタ化されたデ ー タのバックアップ
クラスタにはすでにデータの冗長コピーが含まれていますが、クラスタのデータを他の場所にバックアップしたい
場合もあります (たとえば、障害 策の一環としてサイト外にコピーを保持する場合)。
このためのもっとも簡単な方法は、このトピックの前半で 明したように、非クラスタ化インデクサーのデータを
バックアップするのと同じ手段で、クラスタ内の個別の各ピアノードのデータをバックアップすることです。ただ
し、この方法ではバックアップデータが重複してしまいます。たとえば、複製データ保持数が 3 のクラスタがある
場合、そのクラスタは一連のピアノードのすべてのデータに して、3 つのコピーを保持します。このような環境で
個別の各ノードに保管されているデータをバックアップした場合、結果的に 3 つのデータコピーを含むバックアッ
プができてしまいます。1 台のノードのデータをバックアップするだけではこの問題を解決することはできませ
ん。そのノードにクラスタ内のすべてのデータが保管されている保証がないからです。
この問題を解決するには、クラスタ上の各バケツのコピーをそれぞれ 1 つ識別して、それらのコピーのみをバック
アップすることが考えられます。ただし、このような作業は複 でとても手間がかかります。1 つの手段として、各
ピアのインデックスストレージを調べ、バケツ名に含まれているバケツ ID 値を使って、各バケツのコピーを 1 つ
のみ識別するスクリプトを作成することが げられます。バケツ ID は、すべてのバケツのコピーで同じになりま
す。バケツ ID の詳細は、「ウォーム/コールドバケツの命名規則」を参照してください。クラスタバックアップス
クリプトの設計時には、バケツの raw データのみをバックアップするのか、または raw データとインデックス
ファイルの両方をバックアップするのかも 討する必要があります。後者の場合は、各バケツのサーチ可コピーも
識別するようにスクリプトを設計する必要があります。
クラスタバックアップは複 なため、Splunk プロフェッショナルサービスに、クラスタ化データの単一のコピーを
バックアップするためのガイダンスを依頼することをお勧めします。サービスチームは、お客 の環境のニーズに
合わせたソリューションの設計をお手伝いいたします。
リタイアおよびア ー カイブポリシ ー の設定
データリタイアおよびアーカイブポリシーの設定は、インデックスのサイズまたはインデックス内のデータの 過
期間で定義します。
Splunk は、インデックスデータをバケツと呼ばれるディレクトリに保管しています。バケツはリタイアするまで
に 4 種類の段階を ます。インデックスデータが最終段階のフローズンになると、それがインデックスから削除さ
れます。フローズン状態のデータを削除する代わりに、アーカイブすることを設定できます。詳細は、「インデッ
クスデータのアーカイブ」を参照してください。
バケツの
ステージ
明
サーチ可？
ホット
新たにインデックスが作成されたデータを保管しています。書き込み可能。各イン
デックスに して 1 つまたは複数のホットバケツ。
はい
ウォーム
ホットから移行されたデータ。ウォームバケツは多数存在しています。
はい
38
コールド
ウォームから移行されたデータ。コールドバケツは多数存在しています。
はい
フローズ
ン
コールドから移行されたデータ。デフォルトでは、フローズンデータは削除されま
すが、アーカイブすることも可能です。アーカイブされたデータは、後ほど解凍す
ることができます。
いいえ
インデックスおよびバケツのサイズ、場所、および 過時間は indexes.conf で設定、編集します。「インデックス
ストレージの設定」を参照してください。
警告：データのリタイアおよびアーカイブポリシーの設定を 更した場合、Splunk は警告することなしに古いデー
タを削除できてしまいます。
コ ー ルドからフロ ー ズンへの移行動作の 属 性の設定
内の maxTotalDataSizeMB および frozenTimePeriodInSecs 属性は、バケツがコールドからフローズ
ンに移行する時期を決定します。これらの属性の詳細は、以降の 明を参照してください。
indexes.conf
イ ン デ ッ ク ス が 大 き く な り す ぎ た 場 合 に デ ー タ を フ ロ ー ズ ン に 移 行 ： Set
maxTotalDataSizeMB
データをフローズンに移行してインデックスから削除する時期を、インデックスサイズで設定できます。インデッ
クスが指定サイズを超えた場合に、もっとも古いデータがフローズン状態に移行されます。
デフォルトのインデックス最大サイズは、500,000 MB です。最大サイズを 更するには、indexes.conf 内の
maxTotalDataSizeMB 属性を編集します。たとえば、最大サイズとして 250,000 MB を指定します。
[main]
maxTotalDataSizeMB = 250000
重要：サイズはメガバイトで指定してください。
新しい設定を有効にするには、Splunk を再起動してください。処理 象データの量によっては、Splunk が新しいポ
リシーに従ってインデックスのバケツの移行を開始するまでに少し時間がかかることがあります。その間、CPU
の使用率が高くなる可能性があります。
デ ー タ が 古 く な っ た 場 合 に フ ロ ー ズ ン に 移 行 す る ： Set frozenTimePeriodInSecs
バケツのフローズンへの移行時期を、データの 過時間で設定することができます。特定のバケツ内の最新のデー
タの 過時間が設定された値に達すると、バケツ全体が移行されます。
データをフローズンに移行するまでの 過時間を指定するには、indexes.conf 内の frozenTimePeriodInSecs 属性を
編集します。この属性は、データをフローズン状態に移行するまでの 過秒数を指定します。デフォルトは
188697600 秒 (約 6 年) です。180 日 (15552000 秒) 以上 過した古いイベントをインデックスから削除する設定例
を以下に示します。
[main]
frozenTimePeriodInSecs = 15552000
重要：時間は秒数で指定します。
新しい設定を有効にするには、Splunk を再起動してください。処理 象データの量によっては、Splunk が新しいポ
リシーに従ってインデックスのバケツの移行を開始するまでに少し時間がかかることがあります。その間、CPU
の使用率が高くなる可能性があります。
デ ー タのア ー カイブ
フローズンデータを削除する代わりにアーカイブする場合は、「インデックスデータのアーカイブ」の 明に従っ
て Splunk にその旨を指示する必要があります。独自のアーカイブスクリプトを作成することも、Splunk にアーカ
イブ処理を行わせることも可能です。アーカイブしたデータは後ほど復元 (解凍) することができます。「アーカ
イブされたデータの復元」を参照してください。
その他のバケツ移行 条 件
あるステージから別のステージへのバケツの移行の契機となる条件は、他にもさまざま存在しています。一部の条
件は、データの削除やアーカイブにつながります。これらの条件はすべて設定可能です。「インデックスストレー
ジの設定」を参照してください。リタイアポリシーに影響するすべてのオプションを完全に理解するために、この
トピックおよび indexes.conf ファイルを参照してください。
39
たとえば、Splunk はバケツが最大サイズに達した場合にそのバケツを移行します。indexes.conf 内の
maxDataSize に小さな値を設定すると、バケツのサイズが小さくなるため、より頻繁に移行が行われるようになり
ます。ただし、少数の大きなバケツを使用する代わりに多数の小さなバケツを使用すると、サーチに時間がかかる
ことに注意してください。目的の結果を得るためには、色々と試して最適なバケツサイズを決定する必要がありま
す。
ア ー カイブポリシ ー のトラブルシュ ー ティング
ディスクスペースが足りなくなったからアーカイブポリシーを 更したけれどもうまく
機能しない
ディスクスペースが足りなくなったため、より 格なアーカイブポリシーに 更した場合でも、新しいポリシーに
従ってイベントのアーカイブが開始されないことがあります。このような場合、処理を実行するための空きスペー
スが足りない可能性があります。まず最初に、処理を実行できるようにいくらかのスペースを確保してください。
Splunk を停止して、最高 5 GB ほどの空きディスクスペースを確保してから、もう一度 Splunk を起動してくださ
い。しばらくすると (実際にかかる時間は処理 象データの量によって異なります)、バケツのアーカイブが開始さ
れたことを示す、splunkd.log 内の BucketMover に関する情報エントリが表示されるはずです。
インデックス作成されたデ ー タのア ー カイブ
時間の 過に伴って (データがフローズン状態に移行する時点で)、データを自動的にアーカイブするように Splunk
を設定することができます。このためには、indexes.conf を設定します。
警告：デフォルトでは、フローズン状態に移行したデータはすべて削除されます。データは、フローズン状態に移
行した時点でインデックスから削除されます。データを保持しておきたい場合は、削除前にデータをアーカイブす
るように設定する必要があります。このためには、indexes.conf 内に coldToFrozenDir 属性を設定するか、また
は有効な coldToFrozenScript を指定します。
データストレージの詳細は、「Splunk によるインデックスの保管方法」を参照してください。indexes.conf の編
集方法については、「インデックスストレージの設定」を参照してください。
Splunk によるデ ー タのア ー カイブ方法
Splunk は、データリタイアポリシーに基づいて、インデックスから古いデータを取り除きます (「リタイアおよび
アーカイブポリシーの設定」を参照)。データは各種ステージを移動していきます。これらのステージは、ファイ
ルディレクトリの場所に しています。まずデータはホットデータベースに保管されます。このデータベース
は、$SPLUNK_HOME/var/lib/splunk/defaultdb/db/ 下のサブディレクトリ (バケツ) として存在しています。次
に、$SPLUNK_HOME/var/lib/splunk/defaultdb/db のサブディレクトリとして存在する、ウォームデータベースに
移行します。その後順次、データはコールドデータベース $SPLUNK_HOME/var/lib/splunk/defaultdb/colddb に移
行されます。
最後にデータは、フローズン状態になります。この処理はさまざまな条件に じて発生します (「リタイアおよび
アーカイブポリシーの設定」を参照)。この時点で、Splunk はデータをインデックスから消去します。フローズン
データをインデックスから消去する前にアーカイブする場合は、その旨を設定する必要があります。アーカイブ処
理には、2 種類の方法を選 できます。
Splunk にアーカイブを自動実行させる。
実行するアーカイブスクリプトを指定する。
アーカイブ動作は、これらの indexes.conf 属性の設定内容によって異なります。
coldToFrozenDir：この属性は、Splunk
がフローズンデータを自動的にアーカイブする場所を示します。
coldToFrozenScript：この属性は、データをフローズンにする際に実行するユーザースクリプトを示しま
す。これは一般的に、フローズンデータをアーカイブするスクリプトになります。スクリプトは、他の目的
に利用することも可能です。Splunk には、サンプルのアーカイブスクリプトが 1 つ同梱されており
($SPLUNK_HOME/bin/coldToFrozenExample.py)、これを利用、編集することができます。また、その他任意の
スクリプトを指定することも可能です。
注意：これらの属性の中の 1 つのみを指定できます。両方の属性を設定した場合、coldToFrozenDir 属性の設定が
coldToFrozenScript の設定に優先されます。
どちらの属性も指定しない場合は、消去するバケツ名を単にログファイル
$SPLUNK_HOME/var/log/splunk/splunkd_stdout.log に書き込むデフォルトスクリプトが実行されます。その後バ
ケツが消去されます。
Splunk に デ ー タ を ア ー カ イ ブ さ せ る
40
に coldToFrozenDir 属性を設定した場合、Splunk はインデックスからデータを消去する前に、自動
的にフローズンバケツを指定場所にコピーします。
indexes.conf
$SPLUNK_HOME/etc/system/local/indexes.conf
に以下のスタンザを追加します。
[<index>]
coldToFrozenDir = "<path to frozen archive>"
以下の事項に注意してください。
<index>
は、アーカイブするデータが存在するインデックスを示します。
は、Splunk がアーカイブしたバケツを保管するディレクトリを示します。
<path to frozen archive>
注意：Splunk Web を使って新しいインデックスを作成する際に、そのインデックスのフローズンアーカイブのパ
スを指定することもできます。詳細は、「複数インデックスの設定」を参照してください。
Splunk によるフローズンデータのアーカイブ方法は、当初 4.2 より前の Splunk でデータのインデックスが作成さ
れたのかどうかによって異なります。
バージョン 4.2 以降で作成されたバケツの場合、raw データファイルを除くすべてのファイルが削除されま
す。
4.2 より前のバージョンで作成されたバケツの場合、単にバケツ内のすべての .tsidx および .data ファイル
が gzip されます。
この差異は、raw データの形式の 更によるものです。4.2 以降では Splunk がインデックスバケツを再構築するた
めに必要なすべての情報が raw データファイルに含まれています。
バケツの解凍 (復元) 方法の詳細は、「アーカイブされたインデックスデータの復元」を参照してください。
アーカイブスクリプトの指定
に coldToFrozenScript 属性を設定した場合、インデックスからフローズンデータを消去する前に、
指定したスクリプトが実行されます。
indexes.conf
実際のスクリプトを指定する必要があります。一般的にはデータをアーカイブするスクリプトを指定しますが、任
意のアクションを実行するスクリプトを指定できます。
$SPLUNK_HOME/etc/system/local/indexes.conf
に以下のスタンザを追加します。
[<index>]
coldToFrozenScript = ["<path to program that runs script>"] "<path to script>"
以下の事項に注意してください。
は、アーカイブするデータが存在するインデックスを示します。
には、アーカイブスクリプトへのパスを指定します。スクリプトは、$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"
Splunk には、アーカイブスクリプトの例 $SPLUNK_HOME/bin/coldToFrozenExample.py が用意されています。これ
を編集することも可能です。
注意：サンプルスクリプトを使用する場合、ご自分の環境に合わせてアーカイブの場所を 更してください。ま
た、Splunk のアップグレード時に 更したファイルが上書きされないように、編集したスクリプトの名前を 更する
か、または別の場所に移動してください。これはあくまでもサンプルのスクリプトなので、ご利用の環境に合わせ
て編集した後、正常に動作することを確認しない限り、実際の生産環境には適用しないでください。
このサンプルスクリプトは、当初のデータのインデックスが 4.2 より前のバージョンの Splunk で作成されたかど
うかによって、異なる動作を行います。
バージョン 4.2 以降で作成されたバケツの場合、raw データファイルを除くすべてのファイルが削除されま
す。
4.2 より前のバージョンで作成されたバケツの場合は、単にすべての .tsidx および .data ファイルが gzip さ
れます。
41
この差異は、raw データの形式の 更によるものです。4.2 以降では Splunk がインデックスバケツを再構築するた
めに必要なすべての情報が raw データファイルに含まれています。
バケツの解凍 (復元) 方法の詳細は、「アーカイブされたインデックスデータの復元」を参照してください。
ベストプラクティスとして、Splunk が完了待ち状態で待機することがないように、スクリプトはできる限り早く
処理を完了するようにしてください。たとえば、低速なボリュームへアーカイブするような場合は、まずインデッ
クスと同じ (高速な) ボリューム内の一時ディレクトリにバケツをコピーするようにスクリプトを設定します。そ
の後 Splunk 外で別個のスクリプトを使って、そのバケツを一時ディレクトリから低速なボリューム上の目的の
ディレクトリに移動します。
ア ー カイブへの署名
Splunk では、アーカイブに署名することができます。この機能を利用することで、アーカイブの復元時に整合性
を 証することができます。
注意：アーカイブの署名を使用する場合、独自のアーカイブスクリプトを指定する必要があります。Splunk に自
動的にアーカイブ処理を行わせる場合は、アーカイブの署名を実行することはできません。
クラスタ化デ ー タのア ー カイブ
クラスタには、インデックスデータの冗長コピーが保管されています。前述の方法を使ってこのようなデータを
アーカイブする場合、複数のデータコピーをアーカイブすることになります。
たとえば、複製データ保持数が 3 のクラスタがある場合、そのクラスタは一連のピアノードのすべてのデータに
して、3 つのコピーを保持します。各ピアノードに してフローズン移行時に自己のデータをアーカイブするように
設定した場合、3 つのアーカイブされたデータのコピーができてしまいます。1 台のノードのデータをアーカイブ
するだけではこの問題を解決することはできません。そのノードにクラスタ内のすべてのデータが保管されている
保証がないからです。
クラスタ上の各バケツのコピーを 1 つのみアーカイブして、残りを破棄すればこの問題は解決します。ただし、こ
のような作業は複 でとても手間がかかります。クラスタ化データの単一コピーをアーカイブするためのガイダン
スが必要な場合は、Splunk プロフェッショナルサービスまでお問い合わせください。サービスチームは、お客 の
環境のニーズに合わせたソリューションの設計をお手伝いいたします。
アーカイブ先の指定
クラスタ化データの複数コピーをアーカイブすることを選 した場合は、名前の競合が発生しないように注意する
必要があります。すべてのピアノードからのデータを単一のアーカイブディレクトリに送ることはできません。ク
ラスタ内には同じ名前を持つバケツのコピーが複数存在しており、ディレクトリの内容には一意の名前を付ける必
要があります。代わりに、各ピアノードからのバケツを個別のアーカイブディレクトリに送る必要がありま
す。indexes.conf 内の coldToFrozenDir 属性を使って共有ストレージ内の宛先ディレクトリを指定した場合、こ
のような処理は困難です。「ピアインデックスの設定」で 明しているように、indexes.conf ファイルはすべての
ピアノード上で同一でなければなりません。その代わりに、各ピアのアーカイブバケツを共有ストレージ上の個別
の場所に保管するスクリプトを作成し、coldToFrozenScript 属性を使ってそのスクリプトを指定することができ
ます。
ア ー カイブされたインデックスデ ー タの復元
アーカイブされたデータを復元するには、アーカイブされているバケツを解凍用ディレクトリ
(例：$SPLUNK_HOME/var/lib/splunk/defaultdb/thaweddb) に移動して、次にこのトピックの後半で 明する手順に
従って処理を行います。thaweddb 内のデータには、サーバーのインデックス 過時間スキーマ (ホット > ウォーム>
コールド > フローズン) は適用されません。アーカイブデータは、解凍用ディレクトリに必要なだけ保管しておく
ことができます。データが不要になったら、それを削除するかまたは別のディレクトリに移動してください。
重要：アーカイブデータの復元は、そのインデックスが Splunk 4.2 以降で作成されたかどうかによって作業内容
が異なります。これは、4.2 まで raw データの形式が 更されたためです。
データのアーカイブ方法については、「インデックスデータのアーカイブ」を参照してください。また、解凍した
データを再びアーカイブする場合についても、そのトピックを参照してください。
ア ー カイブを別の Splunk インスタンスに復元する場合の制限事項
たいていの場合、アーカイブは当初インデックスを作成した Splunk インスタンスだけではなく、任意の Splunk
インスタンスに復元することができます。ただし、これにはいくつかの要素が影響してきます。
42
Splunk バージョン：Splunk 4.2 以降で作成されたバケツを、4.2 より前の Splunk インスタンスに復元する
ことはできません。4.1 と 4.2 ではバケツのデータ形式が 更されています。4.2 より前の Splunk インスタン
スは、新しい形式を理解することはできません。つまり、以下のようになります。
4.2 以降のバケツ：4.2 以降のバケツは、任意の 4.2 以降のインスタンスに復元できます。
4.2 より前のバケツ：4.2 より前のバケツは、任意の Splunk インスタンス (4.2 以前および 4.2 以降) に
復元できます。ただし、後述するように、いくつかの OS に関連する問題があります。
OS のバージョン：通常は、異なる OS 上で動作する Splunk インスタンスにバケツを復元することができま
す。概要を以下に示します。
4.2 以降のバケツ：4.2 以降のバケツは、任意の OS 上で動作する Splunk インスタンスに復元できま
す。
4.2 より前のバケツ：4.2 より前のバケツは、任意の OS 上で動作する Splunk インスタンスに復元でき
ますが、異なるエンディアンを持つシステムに 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_0
$SPLUNK_HOME/var/lib/splunk/defaultdb/thaweddb/temp_db_1181756465_1162600547_0
2. 一時ディレクトリで rebuild コマンドを実行し、Splunk インデックスと関連ファイルを再構築します。
# splunk rebuild $SPLUNK_HOME/var/lib/splunk/defaultdb/thaweddb/temp_db_1181756465_1162600547_0
3. この一時バケツを Splunk が認識できる名前に 更します。
# cd $SPLUNK_HOME/var/lib/splunk/defaultdb/thaweddb/
# mv temp_db_1181756465_1162600547_0 db_1181756465_1162600547_1001
注意：インデックス内の他のバケツと競合しないバケツ ID を指定する必要があります。この例では、インデック
ス内でバケツ ID 1001 が一意であることを前提にしています。そうでない場合は、他の競合していないバケツ ID
を選 してください。
4. Splunk を再起動します。
# splunk restart
Windows ユ ー ザ ー
43
4.2 以降のアーカイブバケツを解凍用ディレクトリに復元する例を以下に示します。
1. アーカイブバケツを復元用ディレクトリにコピーします。
> xcopy D:\MyArchive\db_1181756465_1162600547_0 %SPLUNK_HOME%\var\lib\splunk\defaultdb\thaweddb\temp_db_1181756465_1162600547
2. 一時ディレクトリで rebuild コマンドを実行し、Splunk インデックスと関連ファイルを再構築します。
> splunk rebuild %SPLUNK_HOME%\var\lib\splunk\defaultdb\thaweddb\temp_db_1181756465_1162600547_0
3. この一時バケツを Splunk が認識できる名前に 更します。
> cd %SPLUNK_HOME%\var\lib\splunk\defaultdb\thaweddb
> move temp_db_1181756465_1162600547_0 db_1181756465_1162600547_1001
注意：インデックス内の他のバケツと競合しないバケツ ID を指定する必要があります。この例では、インデック
ス内でバケツ ID 1001 が一意であることを前提にしています。そうでない場合は、他の競合していないバケツ ID
を選 してください。
4. Splunk を再起動します。%SPLUNK_HOME%\bin に移動して、以下のコマンドを実行します。
> 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. この一時バケツを Splunk が認識できる名前に 更します。
# 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
2. バケツのアーカイブ時に 縮されている場合は、それを解凍します。
3. この一時バケツを Splunk が認識できる名前に 更します。
> cd %SPLUNK_HOME%\var\lib\splunk\defaultdb\thaweddb
> move temp_db_1181756465_1162600547_0 db_1181756465_1162600547_1001
44
注意：インデックス内の他のバケツと競合しないバケツ ID を指定する必要があります。この例では、インデック
ス内でバケツ ID 1001 が一意であることを前提にしています。そうでない場合は、他の競合していないバケツ ID
を選 してください。
4. マニフェストを更新します。
> cd %SPLUNK_HOME%\bin
> splunk login
> splunk _internal call /data/indexes/main/rebuild-metadata-and-manifests
しばらくすると、復元したバケツが再びサーチ可になります。
クラスタ化デ ー タの復元
アーカイブされたクラスタ化データの個別のピアノードへの復元は、個別のインデクサーへのデータの復元と同じ
方法で行えます。ただし、「インデックスデータのアーカイブ」で 明しているように、クラスタ化データの単一
のコピーをアーカイブすることは困難です。代わりにクラスタ内のすべてのピアノードのデータをアーカイブした
場合は、後ほどそのデータを復元し、それを元のピアノードの復元用ディレクトリに保管することができます。ク
ラスタ上の復元したデータには、複製データ保持数のコピーが含まれます。
注意：復元用ディレクトリのデータは複製されません。何らかの方法でデータの単一のコピーをアーカイブして、
それを後ほど復元した場合、クラスタ内にはピアノードの復元用ディレクトリに保管した単一のデータコピーのみ
が存在することになります。
クラスタとインデックスレプリケ ー ションの 概 要
クラスタとインデックスレプリケ ー ションについ
て
クラスタは、相互のデータを複製するように設定された Splunk インデクサーのグループです。このプロセス
は、インデックスレプリケーションとして知られています。クラスタは Splunk データの複数の同一コピーを保持
することにより、データ消失を防止しながら、サーチ用データの可用性を向上します。
Splunk のクラスタ機能では、あるインデクサーから別のインデクサーに自動フェイルオーバーを行います。つま
り、1 つまたは複数のインデクサーに障害が発生した場合でも、引き続き到着データのインデックスが作成され、
サーチが可能になります。
インデックスレプリケーションの主な利点を以下に示します。
データ可用性：インデクサーは常に到着データを処理でき、インデックスが作成されたはサーチ可となりま
す。
データ忠実度：データが失われることはありません。Splunk に送信されたデータは、Splunk に保管された
データと完全に同一で、サーチに利用することができます。
データ復元：インデクサーがダウンしても、データが失われることなく、引き続きデータを利用できます。
改善されたサーチパフォーマンス：データを複数のインデクサーに配布することにより、サーチ時に複数の
インデクサーで並列的にバケツを読み取ることができ、各インデクサーの I/O 負荷を減らすことができま
す。
インデックスレプリケーションの主なトレードオフとしては、データ可用性/復元とストレージコスト (およびわず
かな処理負荷の 加) の兼ね合いが げられます。クラスタのデータ復元可能性は、クラスタ内で保持するデータコ
ピー数に比例します。ただし、データコピーの保持数が多いと、ストレージ要件も高くなります。このトレードオ
フを管理して企業ニーズを たすために、クラスタに保持するデータコピー数を設定することができます。これ
は、「複製データ保持数」と呼ばれています。
また、インデックスレプリケーションが必要ではない状況でも、クラスタを使ってインデックス容量/能力を 強す
ることができます。「クラスタを使ったインデックスの 強」を参照してください。
クラスタの 内 容
クラスタは、連携して冗長インデックス作成およびサーチ機能を提供する、Splunk ノードのグループです。クラ
スタ内には 3 種類のノードが存在しています。
クラスタを管理する単一のマスターノード。
複数のデータコピーのインデックス作成と保持、およびデータのサーチを処理する複数のピアノード。
一連のピアノードにまたがってサーチを調整、管理する 1 つまたは複数のサーチヘッド。
45
マスターノードはクラスタを管理しています。ピアノードの複製アクティビティを調整し、サーチヘッドにデータ
の 索場所を指示します。また、ピアノードの設定を管理し、またピアノード停止時の復旧処置を担当します。
ピアノードは、単独のインデクサーと同 に、データを受け取って、インデックスを作成します。ただし、スタン
ドアロンのインデクサーとは異なり、ピアノードはクラスタ内の他のノードからのデータも複製します。ピアノー
ドは到着データのインデックスを作成しながら、同時に他のノードからの複製データを保管します。最低でも、複
製データ保持数と同じ数のピアノードが必要です。複製データ保持数が 3 の場合、最低 3 台のピアノードが必要
になります。
サーチヘッドは、一連のピアノードにまたがってサーチを行います。ピアノードにまたがるサーチを管理するため
に、サーチヘッドを使用する必要があります。サーチヘッドは、残りのクラスタ構成部と同時に有効にする必要が
あります。
一般的には、クラスタにデータを取り込むためにフォワーダーを使用することをお勧めします。
基本的なクラスタの概要を以下に示します。このクラスタには 3 台のピアノードが存在し、複製データ保持数は 3
となっています。
これは単純なデプロイ例で、小規模な非クラスタデプロイと似ています。一部のフォワードーがロードバランシン
グデータをインデクサー (ピアノード) グループに送信し、インデクサーがサーチヘッドにサーチ結果を送信しま
す。ただし、クラスタ環境は非クラスタデプロイ環境とは 2 つの点で異なっています。
インデクサーはデータのコピーを他のインデクサーに転送します。
マスターノードはデータ転送を行いませんが、サーチピアおよびサーチヘッドが関与しているさまざまなア
クティビティを管理、調整します。
クラスタの設定方法
クラスタの設定は簡単です。作業内容は、スタンドアロンのインデクサーグループを設定する場合と似ています。
基本的には、インデクサーをインストールして、いくつかの設定を行います。
主な違いとしては、クラスタノードを指定して、有効化する必要があることが げられます。1 つのインデクサーを
マスターノードとして、その他のインデクサーをピアノードとして指定します。ピアノード数は、最低でも複製
データ保持数と同じ台数が必要になります。水平スケーリングのためにインデックス能力を 強する場合は、単に
ピアノードを追加していきます。
ピア間にまたがるサーチを管理して、それをまとめた結果をユーザーに返すために、サーチヘッドも設定する必要
があります。
ノードとサーチヘッドを有効にするには、Splunk 内で任意の設定を行う場合と同 に、Splunk 管理、CLI、または
設定ファイルを編集することで行います。
46
詳細は、このマニュアルの「クラスタのデプロイ」を参照してください。
クラスタのサ ー チ方法
クラスタのサーチは、クラスタ化されていない一連のインデクサーグループをサーチするのと同じ方法で行いま
す。サーチはサーチヘッド 由で実行します。
ただし、その裏側で行われる処理は少し異なっています。サーチを実行すると、サーチヘッドはマスターノードに
問い合わせて、処理 象のデータを保有するピアノードを判断します。次に、サーチヘッドはサーチタスクをそれ
らのノードに配布します。各ノードは各自の担当タスクを処理して、結果をサーチヘッドに返します。サーチヘッ
ドは、結果を統合して Splunk 管理に返します。ユーザーの 点からは、スタンドアロンのインデクサーまたはクラ
スタ化されていないインデクサーグループに してサーチを実行する場合と、何ら わりはありません。
先に進む前に
クラスタの設定と使用は簡単ですが、まず Splunk のインデックス作成とデプロイの基本を正しく理解しておく必
要があります。続行する前に、以下の事項を正しく理解するようにしてください。
インデクサーの設定方法：「Splunk によるインデックスの格納方法」およびこのマニュアルに記載されてい
るその他のインデックス管理に関するトピックを参照してください。
サーチヘッドの処理：分散サーチの詳細は、『Distributed Deployment manual』の「About distributed
search」を参照してください。
インデクサーにデータを取り込むためのフォワーダーの使用方法：『Getting Data In Manual』の「Use
forwarders」を参照してください。
非クラスタ Splunk デプロイ環境から移行しますか？
クラスタ構成のインデクサーは、クラスタ構成ではない Splunk インデクサーとは要件が異なっています。インデ
クサーを移行する前に、それらの事項を理解しておく必要があります。詳細は、「クラスタ構成と非クラスタ構成
の Splunk デプロイの主な相違点」を参照してください。それを参照した後は、「非クラスタインデクサーのクラ
スタ化環境への移行」に進んで実際の移行プロセスの詳細を確認してください。
基本的なクラスタのア ー キテクチャ
ここでは、クラスタのアーキテクチャについて紹介していきます。クラスタの各コンポーネント、およびそれらが
連携する方法について 明します。また、基本的な概念やクラスタにおけるインデックス作成/サーチの処理につい
ても 明していきます。
クラスタのアーキテクチャの詳細については、「クラスタの仕組み」を参照してください。
クラスタのコンポ ー ネント
クラスタには、3 種類の Splunk コンポーネントが含まれています。
クラスタを管理する単一のマスターノード。
データのインデックス作成、複製、およびサーチを実行する複数のピアノード。
すべてのピアノードにまたがってサーチを調整、管理する 1 つまたは複数のサーチヘッド。
また、一般的にクラスタデプロイ環境では、フォワーダーを使ってデータを取り込み、それをピアに転送します。
マスターノード、ピアノード、およびサーチヘッドはすべて、Splunk インデクサーの特殊なタイプです。
単純なクラスタの例を以下に示します。このクラスタには数台のピアと、それにデータを送信するフォワーダーが
存在しています。
47
この図で示されている処理のいくつかは、まだ 明されていません。どうぞ読み進めてください。
マスターノード
マスターノードはクラスタを管理しています。ピアノードの複製アクティビティを調整し、サーチヘッドにデータ
の 索場所を指示します。また、ピアノードの設定を管理し、またピアノードがオフライン時の復旧処置を担当し
ます。
ピアノードとは違い、マスターノードは外部データのインデックスを作成しません。クラスタには、マスターノー
ドが 1 つのみ存在しています。
重要：マスターノードは、ピアノードやサーチヘッドのように複数の作業を同時に兼務することはできません。ま
た、ピアノードやサーチヘッドと同じマシン上に存在することはできません。
ピアノード
ピアノードは、クラスタのインデックス作成機能を担当します。これらのノードはデータを受信し、インデックス
を作成します。また、クラスタ内の他のピアノードと複製データを相互に送受信します。ピアノードは、自己の
データのインデックスを作成しながら、同時に複製されたデータを送受信できます。すべてのインデクサーと同
に、ピアもサーチヘッドからのサーチ要求に して、各自のインデックスデータに するサーチを実行します。
デプロイするピアノード数は、クラスタの複製データ保持数とインデックス作成負荷の 2 つの要素によって決まり
ます。たとえば、複製データ保持数が 3 の場合 (データのコピーを 3 つ保持する)、最低 3 台のピアが必要です。3
台のインデクサーで 処しきれないインデックス作成負荷がある場合は、処理能力を向上するためにピアを追加す
る必要があります。
サーチヘッド
サーチヘッドは、一連のピアノードにまたがってサーチを管理します。これは、サーチクエリーをピアに配布し、
また返された結果を統合します。すべてのサーチはサーチヘッドから行います。クラスタには最低 1 台のサーチ
ヘッドが必要です。
フォワーダー
フォワーダーは、どのような Splunk デプロイ環境でも同じように機能します。フォワーダーは外部ソースから
データを取り込んで、それをインデクサー (クラスタの場合はピアノード) に転送します。クラスタへのデータの
取り込みにフォワーダーを使用する必要はありませんが、たいていの場合は利用した方が便利です。インデクサー
答確認機能はフォワーダーでのみ有効にでき、これによって取り込んだデータのインデックスが確実かつ高信頼
に作成されます。また、ピアノード障害に 処する 点からも、ロードバランシングフォワーダーを使用することを
お勧めします。そうすることで、あるピアが停止しても、フォワーダーはロードバランシンググループ内の他のピ
48
アに転送先を切り替えることができます。クラスタ環境におけるフォワーダーの詳細は、このマニュアルの「フォ
ワーダーを使ったデータの取り込み」を参照してください。
重要な 概 念
クラスタの機能を理解するためには、いくつかの概念に慣れ親しんでおく必要があります。
複製データ保持数：クラスタが保持するデータコピー数で、クラスタの障害耐性のレベルを表しています。
サーチ可能データ保持数：クラスタが保持するデータのサーチ可コピー数で、クラスタであるノードが停止
した時にどれだけ素早くサーチ能力を回復できるかを表しています。
バケツ：バケツはインデックスストレージの基本単位です。クラスタは、複製データ保持数に相当する各バ
ケツのコピーを保持しています。
ここでは、これらの概念を簡単に紹介していきます。
複製データ保持数
マスター設定の一環として、クラスタに保持するデータのコピー数を指定します。このコピー数は、クラスタの複
製データ保持数と呼ばれています。複製データ保持数は、インデックスレプリケーションの主要概念です。この値
により、クラスタの障害耐性が決まります。クラスタは、「複製データ保持数 - 1」台のピアノード障害に 処する
ことができます。たとえば、システムで 2 台までのピア障害発生に 処できるようにするためには、複製データ保
持数に 3 を設定する必要があります。この場合、クラスタは 3 つの同一のデータコピーを、別個のノードに保管
します。この場合、2 台のピアが停止しても、3 台目のピアのデータを利用することができます。
3 台のピアで複製データ保持数が 3 のクラスタの例を以下に示します。
この図では、1 台のピアがフォワーダーからデータを受信、処理して、それを他の 2 台のピアに転送しています。
クラスタには、ピアのデータの完全なコピーが 3 つ存在しています。この図では、すべてのデータが単一のピアを
通じてシステムに到着するように、複製を大幅に簡素化して表しています。たいていの 3 台ピアのクラスタでは、
3 台のピアすべてがフォワーダーから外部データを受信し、また他のピアからの複製データも受信します。
複製データ保持数および値の調整に関係するトレードオフについては、「複製データ保持数」を参照してくださ
い。
サーチ可能データ保持数
マスターを設定する際には、サーチ可能データ保持数も指定します。サーチ可能データ保持数は、クラスタが保持
するデータのサーチ可コピー数を表しています。
データのサーチ可コピーは、サーチ不可コピーよりも大きなストレージスペースを必要とします。そのため、ニー
ズに じた適切なサーチ可能データ保持数を設定する必要があります。たいていの場合は、サーチ可能データ保持
数はデフォルト値の 2 のままで使用してください。この場合、クラスタ内で 1 台のピアノードが停止しても、わ
ずかな中断でサーチを 続することができます。
サーチ可コピーとサーチ不可コピーには、一部のデータに違いがあります。サーチ可コピーには、データ自身と
Splunk がデータのサーチに使用するインデックスファイルが含まれています。サーチ不可コピーには、データの
みが含まれています。サーチ不可コピーに含まれているデータにも初期処理が行われており、必要に じてイン
デックスファイルを作成できる形式で保管されています。
サーチ可能データ保持数および値の調整に関係するトレードオフについては、「サーチ可能データ保持数」を参照
してください。
バケツ
Splunk はインデックスデータをバケツに保管します。バケツは、データファイルを保管するディレクトリです。
一般的にインデックスは多数のバケツから構成されています。
完全クラスタは、複製データ保持数の値だけ各バケツのコピーを保持しており、各コピーは別個のノードに保管さ
49
完全クラスタは、複製データ保持数の値だけ各バケツのコピーを保持しており、各コピーは別個のノードに保管さ
れています。バケツのコピーは、サーチ可またはサーチ不可になります。完全クラスタには、サーチ可能データ保
持数の値だけの各バケツのサーチ可コピーも存在しています。
バケツには 2 種類のファイルが保管されています。raw データファイルには、データといくつかのメタデータが含
まれています。バケツのサーチ可コピーの場合は、データのインデックスファイルが含まれています。
クラスタは、バケツ単位で複製されます。元のバケツと他のピアノード上のバケツのコピーには、同一の raw
データセットが含まれています。ただし、インデックスファイルはサーチ可バケツにのみ存在しています。
ピアは新しいバケツを作成すると、マスターと通信してそのバケツのデータを転送するピアのリストを取得しま
す。クラスタのピアノード数が複製データ保持数より大きい場合、ピアは新たなバケツの開始時に 回異なるセッ
トのピアにデータを転送することがあります。複製データ保持数が 3 の場合でも、ピアのオリジナルバケツのコ
ピーは漸次その他のピアに がっていきます。
クラスタの構造を理解するためには、バケツを正しく理解する必要があります。バケツの概要については、
「Splunk によるインデックスの保管方法」を参照してください。次に、「バケツとクラスタ」を参照してくださ
い。ここには、クラスタデプロイ環境において重要なバケツの概念が、詳細に 明されています。
インデックス作成の仕組み
クラスタのインデックス作成機能は、非クラスタのインデックス作成と似ていますが、クラスタが複数のデータコ
ピーを保管すると言う違いがあります。各ピアノードは、非クラスタインデクサーと同 に、外部データを取り込
んで処理し、インデックスを作成します。主な違いとしては、ピアノードは処理したデータのコピーもクラスタ内
の他のピアに転送することが げられます。それらのコピーは、それら独自のバケツに格納されます。処理 みデー
タを受信する一部のピアは、受信データに してインデックスを作成する場合もあります。複製データ保持数は、
処理されたデータのコピーを受け取るピア数を決定します。サーチ可能データ保持数は、データのインデックスを
作成するピア数を決定します。
ピアノードは、外部データのインデックスを作成しながら、同時に他のピアから送信された複製データを保管し、
必要に じてインデックスを作成することができます。たとえば、複製データ保持数が 3 で、3 台のピアノードを
持つクラスタが存在している場合、各ピアは外部データを取り込み、インデックスを作成しながら、他のピアから
転送されたデータのコピーを保管することができます。クラスタのサーチ可能データ保持数が 2 の場合、転送され
たデータのコピーを受け取るもう一方のピアが、それのインデックスも作成します。(データを最初に取り込んだ
ピアは、常に自分が保持するデータのインデックスを作成します。)フォワーダーおよび他のピアからのデータの
移動を以下の図に示します。
注意：すべてのピアノードが外部データを取り込むようにクラスタを設定することができます。これがもっとも一
般的な設定です。これを行うには、単に各ピアノードの入力を設定します。ただし、ピアノードのサブセットのみ
がデータを取り込むようにクラスタを設定することもできます (現時点では、そうする理由はほとんどありません
が)。入力をどのようにクラスタにまたがって分散している場合でも、すべてのピアが複製データを保管できま
50
す。マスターは、複製データを受け取るピアノードを決定します。現在の所、これを設定することはできません。
ピアは外部データのインデックスを複製するだけでなく、各自の _audit や _internal などの内部インデックスも
複製します。
マスターは、ピア間のやり取りを管理します。特に、どのピアがそのデータを転送したかを各ピアに知らせます。
マスターがこれを知らせると、当該ピアノードが停止しない限り、ピアはマスターの関与なしに相互にデータを交
換します。マスターは、どのピアにサーチ可データが存在しているかも追跡しており、常にサーチ可能データ保持
数の値だけのサーチ可データのコピーが利用できることを保証しています。ピアが停止した場合は、マスターが復
旧作業を担当します。
詳細は、「クラスタ化されたインデックスの仕組み」を参照してください。
サ ー チの仕組み
クラスタ内で、サーチヘッドはすべてのサーチを担当します。このプロセスは、非クラスタ環境で、分散サーチが
機能する仕組みと似ています。主な違いは、サーチヘッドは、マスターを利用してサーチピアを示すことにありま
す。また、各バケツの 1 つのコピーに してのみサーチが行われるようにするために、さまざまなプロセスが採用
されています。
各バケツのコピーを 1 つのみサーチに利用するために、クラスタ内の各バケツの 1 つのサーチ可コピーが「プラ
イマリ」として設定されます。サーチは、一連のプライマリコピーに してのみ行われます。一連のプライマリコ
ピーは、時間の 過とともに 更される可能性があります (例：ピアノードのダウンに伴って)。停止したノード上の
一部のバケツのコピーがプライマリだった場合、それらのバケツの他のサーチ可コピーを代わりにプライマリにす
る必要があります。他のサーチ可コピーが存在しない場合 (クラスタのサーチ可能データ保持数が 1 のため) は、
まずサーチ不可コピーをサーチ可コピーに 換しないと、プライマリコピーとして指定することはできません。
マスターはすべてのピアノード上のすべてのバケツのコピーを追跡しており、ピアノード自体も各自のバケツコ
ピーの状態を把握しています。このようにして、サーチリクエストに えて、ピアはどのバケツコピーをサーチす
れば良いのかを把握しています。
サーチヘッドは定期的にマスターから、アクティブなサーチピアのリストを取得します次にサーチヘッドはサーチ
を処理するために、分散サーチの場合と同じようにそれらのピアと直接通信し、サーチリクエストと複製バンドル
ピアに送信して、ピアから返されたサーチ結果をまとめます。
たとえば、3 つのピアが存在するクラスタで、サーチヘッドからの特定のサーチリクエストを たすために必要な
20 個のバケツを管理している場合を考えてみましょう。それら 20 個のバケツのプライマリコピーを、最初のピア
に 10 個、2 番目のピアに 6 個、3 番目のピアに 4 個配置することができます。各ピアがサーチリクエストを受け
取り、そのバケツのコピーがプライマリでサーチ処理を行うかどうかを判断します。
詳細は、「クラスタ化されたサーチの仕組み」を参照してください。
クラスタでのノ ー ド障害の取り扱い
ピアノードが停止した場合、マスターはそのピアのバケツを他のピア上に復元しようと試みます。たとえば、停止
したノードに 20 個のバケツコピーが保管されており、その中の 10 個がサーチ可の場合 (3 つのプライマリバケツ
のコピーを含む)、マスターはそれらの 20 個のバケツのコピーを他のノードに保管しようと試みます。また、10
個のサーチ可コピーを他のノード上の同じバケツのサーチ可コピーで置換します。
複製データ保持数に指定された値よりも残りノード数が少なくなった場合、クラスタは失われた 20 個のコピーを
置換できなくなります。サーチ可能データ保持数に指定された値よりも残りノード数が少なくなった場合、クラス
タは失われた 10 個のサーチ可コピーを置換できなくなります。
どのような場合でも、クラスタは失われたバケツのコピーに して、それらのバケツの他のピア上のコピーを「プ
ライマリ」として指定し、サーチヘッドが完全にアクセスできる状態を維持する必要があります。クラスタが完全
なプライマリコピーのセットを保持できなくなるのは、複製可能データ保持数以上のノードが停止した場合のみで
す。たとえば、5 台のピアノードを持つクラスタで複製データ保持数が 3 に設定されている場合、1 台または 2 台
のピアが停止しても完全なプライマリコピーセットを保持できますが、3 台目が停止するとその状態を維持できな
くなってしまいます。
前述のように、バケツのコピーをサーチ可に 換するためには少し時間がかかります。サーチ可能データ保持数が 1
の場合、クラスタはサーチ可バケツセットを 1 つのみ保持します。一部のプライマリコピーを保持しているピアが
停止した場合は、まずいくつかのサーチ不可コピーをサーチ可コピーに 換しないと、それらを失われたコピーの
代わりとなる (置き換わる) プライマリとして指定することはできません。この処理が行われている間は、クラス
タには不完全なプライマリバケツのセットが存在することになります。その間もサーチを続行することはできます
が、利用可能なサーチ可バケツに してのみサーチが行われます。徐々にすべてのサーチ可コピーが置換され、そ
れらが「プライマリ」として指定されます。そうなると、完全なバケツセットに してサーチを実行できるように
なります。
51
一方、サーチ可能データ保持数に 2 以上の値を設定すると、クラスタは即座に残りのノード上に存在するサーチ可
コピーを「プライマリ」として指定できます。停止したノードのサーチ可コピーの置換処理は行われますが、その
間もクラスタのすべてのデータに してサーチを 続できます。
詳細は、「ピアノード停止時の処理」を参照してください。
マスターノードが停止した場合、ある程度の期間は、ピアノードは引き続きインデックスを作成し、データを複製
することができます。また、サーチヘッドもデータ全体をサーチできます。ただし、徐々に問題が発生するように
なります (特に、いずれかのピアが停止した場合など)。マスターが存在しないと、ピア停止による問題から回復す
ることはできません。サーチヘッドは不完全なセットに してサーチを行うことになります。一般的には、マス
ターが存在しない場合でもクラスタはできる限り最善の動作を行いますが、システムは不整合状態となり、結果を
保証できなくなってしまいます。
詳細は、「マスターノード停止時の処理」を参照してください。
クラスタのデプロイ
デプロイの 概 要
ここでは、クラスタをデプロイするための主なステップについて 明していきます。以降のトピックでは、これら
のステップの詳細を見ていきます。
クラスタのデプロイを開始する前に、Splunk 管理に関するさまざまな知識を理解しておく必要があります。
インデクサーの設定方法：「Splunk によるインデックスの格納方法」およびこのマニュアルに記載されてい
るその他のインデックス管理に関するトピックを参照してください。
サーチヘッドの処理：分散サーチの詳細は、『Distributed Deployment manual』の「About distributed
search」を参照してください。ただし、クラスタのサーチヘッドは、このトピックの 明とは、少し異なる設
定が行われています。これらの違いについては、このマニュアルの後半にある「サーチヘッドの設定」で 明
しています。
インデクサーにデータを取り込むためのフォワーダーの使用方法：『Getting Data In Manual』の「Use
forwarders」を参照してください。
非クラスタ Splunk デプロイ環境から移行しますか？
クラスタ構成のインデクサーは、クラスタ構成ではない Splunk インデクサーとは要件が異なっています。インデ
クサーを移行する前に、それらの事項を理解しておく必要があります。詳細は、「クラスタ構成と非クラスタ構成
の Splunk デプロイの主な相違点」を参照してください。それを参照した後は、「非クラスタインデクサーのクラ
スタ化環境への移行」に進んで実際の移行プロセスの詳細を確認してください。
クラスタのデプロイ
クラスタをデプロイする場合、インデックスの作成を実行するクラスタのマスターとピアノードを有効にして、設
定します。また、クラスタ内のデータをサーチするサーチヘッドも有効にします。さらに、一般的にはクラスタ内
のノードにデータを送信するように、フォワーダーを設定します。デプロイする各種コンポーネントを含んだ小さ
なクラスタの例を以下の図に示します。
52
クラスタデプロイの主要ステップを以下に示します。
1. 要件を判断します。
a. データ可用性およびフェイルオーバーのニーズを把握します。「クラスタについて」を参照してください。
b.複製データ保持数を決定します。複製データ保持数は、クラスタが保持する raw データのコピー数です。最適な
複製データ保持数は、ご利用の環境のさまざまな要因によって異なりますが、基本的には障害耐性とストレージ容
量のトレードオフとなります。複製データ保持数に高い値を設定すると、多数のピアノード上により多くのデータ
コピーが保管されることになり、データの可用性を失わずにノードの障害耐性を強化できます。ただし、追加デー
タを取り扱うためにより多くのノードとストレージが必要になります。詳細は、「複製データ保持数」を参照して
ください。
警告：最初から、ニーズに合わせた適切な複製データ保持数を設定するようにしてください。クラスタが大量の
データを保有するようになってから、複製データ保持数の値を やすことはお勧めできません。この場合、値が や
された複製データ保持数に じてクラスタは大量のバケツをコピーしなければなりません。コピー中は、クラスタ
の総合的なパフォーマンスも大幅に低下してしまいます。
c.サーチ可能データ保持数を決定します。サーチ可能データ保持数は、クラスタにインデックスデータのサーチ可
コピー保持数を指示します。この値は、クラスタがノード停止から回復するまでの速度に影響します。サーチ可能
データ保持数の値を大きくすると、クラスタがより迅速に回復できます。ただし、より多くのストレージスペース
および処理能力を消費します。たいていの環境では、デフォルトのサーチ可能データ保持数 2 が適性で、ノードの
停止時にもわずかな中断でサーチを続行することができます。詳細は、「サーチ可能データ保持数」を参照してく
ださい。
警告：最初から、ニーズに合わせた適切なサーチ可能データ保持数を設定するようにしてください。クラスタが大
量のデータを保有するようになってから、サーチ可能データ保持数の値を やすことはお勧めできません。この場
合、 やされたサーチ可能データ保持数に じてクラスタは大量のデータ処理 (サーチ不可バケツのコピーのサーチ可
コピーへの 換) を行わなければならず、処理中はクラスタの総合的なパフォーマンスに極端な 影響を与えてしまい
ます。
d.クラスタの規模を決定するその他の養親を判別します。たとえば、インデックスを作成するデータの量などを判
別します。一般的に、単一のクラスタにすべてのインデクサーを配置し、さらに水平方向のスケーリングを確保し
たい場合は、複製データ保持数よりも多くのピアノードを追加する必要があります。同 に、予想されるサーチ負
荷に じて、複数のサーチヘッドを設定しなければならないこともあります。
e.その他の問題については、「システム要件およびその他のデプロイに関する 討事項」を参照してください。
2. ネットワークに Splunk クラスタインスタンスをインストールします。最低でも、「複製データ保持数 + 2」個
の Splunk インスタンスが必要になります。
最低でも「複製データ保持数」台のピアノードが必要ですが、ステップ 1d で 明したように、インデックス
作成能力を強化するために他のピアを追加することも可能です。
53
また、マスターノード用とサーチヘッド用に、その他 2 つの Splunk インスタンスも必要になります。
Splunk のインストール方法については、『Installation Manual』を参照してください。
3. Splunk インスタンスのクラスタリングを有効にします。
a. マスターノードを有効にします。「マスターノードを有効にする」を参照してください。
重要：マスターを初めて起動した場合、複製データ保持数と同じ数のピアを有効にして再起動するまでは、ピアに
おけるインデックス作成がマスターによりブロックされます。
b. ピアノードを有効にします。「ピアノードを有効にする」を参照してください。
c. クラスタのサーチヘッドを有効にします。クラスタのサーチヘッドの設定は、非クラスタグループのインデク
サー設定よりも簡単です。「サーチヘッドを有効にする」を参照してください。
4. ピアノード設定を完了します。
a. ピアのインデックス設定を行います。このステップは、デフォルトのインデックスや App のセットを やす必要
がある場合にのみ実施する必要があります。一般的には、すべてのピアが同じインデックスセットを使用する必要
があります。あるピアにインデックス (またはインデックスを定義する App) を追加した場合は、特別なクラスタ
固有の配布方法を使ってすべてのピアにそれを追加してください。一連のピアに適用する必要がある、その他の設
定が存在している場合もあります。方法の詳細は、「ピアのインデックスレプリケーションの準備」を参照してく
ださい。
b. ピアのデータ入力を設定します。たいていの場合は、フォワーダーを使ってピアにデータを送信するのが最適
です。詳細は、「フォワーダーを使ったデータの取り込み」を参照してください。このトピックに記述されている
ように、通常はインデクサー 答確認を有効にした、ロードバランシングフォワーダーを使用します。
ノードを有効にしてピアノデータ入力を設定すると、クラスタはインデックスの作成とデータの複製を自動的に開
始します。
その他のデプロイシナリオ
この章は、その他のクラスタ展開シナリオに関するガイドラインも 明しています。
既存のデータを保有するインデクサーをクラスタに追加する。「非クラスタインデクサーのクラスタ化環境
への移行」を参照してください。
インデックスレプリケーションが要件ではなく、単にインデックスのスケーラビリティの 点からクラスタを
導入する。「クラスタを使ったインデックスの 強」を参照してください。
最初にお 読 みください：クラスタ構成と非クラス
タ構成の Splunk デプロイの主な相違点
ここでは、クラスタ構成のインデクサーと非クラスタ構成のインデクサーの主な違いについて 明していきます。
特に、システム要件とデプロイの 点からの問題を取り上げています。
現在のインデクサーセットをクラスタに移行することを計画している場合は、このトピックを注意深くお読みくだ
さい。
クラスタピアでデプロイサ ー バ ー やサ ー ドパ ー ティ製のデプロイ
ツ ー ルを使用しないでください
クラスタピアに設定や App を配布するための手段としてサポートされている、デプロイサーバーやサードパー
ティ製のデプロイツール (Puppet や CFEngine など) はありません。一連のクラスタピアに設定を配布するには、
「共通のピア設定の更新」で 明されている設定バンドルを使用してください。
デプロイサーバーから設定バンドルを使った App 配布への移行方法の詳細は、「クラスタへの App の移行」を参
照してください。
システム要件の相違
ピアノードのシステム要件は、非クラスタインデクサーとは一部違いがあります。インデクサーを移行する前に、
「システム要件とその他のデプロイに関する 討事項」を参照してください。特に、以下の相違点に注意してくだ
さい。
54
インデクサーをクラスタピアに 換する際には、ディスク使用量が大幅に 加します。日常的なインデックス作
成量、サーチ可能データ保持数、および複製データ保持数に できる十分なディスクスペース量があることを
確認してください。ピアのディスク使用量の詳細は、「ストレージの 討事項」を参照してください。
colddb ストレージに して、別のハードウェアを使用しなければならないこともあります。ハードウェアのス
トレージニーズの詳細は、「ストレージハードウェア」を参照してください。
ピアノードは他のクラスタコンポーネントとともに、高速ネットワーク上に配置する必要があります。
「ネットワーク要件」を参照してください。
クラスタコンポーネントは、Splunk インスタンスを共有できません。マスターノード、ピアノード、および
サーチヘッドは、それぞれ独自のインスタンス上で動作する必要があります。
その他の 討事項と非クラスタデプロイとの相違点
また、以下の事項に注意してください。
大半のクラスタデプロイ環境では、データをピアに送信するフォワーダー上でインデクサー 答確認を有効に
する必要があります。これは、インデックスのパフォーマンスにある程度影響します。「インデクサー 答確
認の仕組み」を参照してください。
インデクサー 答確認、インデックスや他のピアノードから送られてくる複製データの保管の必要性など、い
くつかの要因により、総合的なパフォーマンスが低下します。
クラスタピアを再起動する場合は、Splunk 管理を使用するか、または splunk offline や splunk rollingrestart などのクラスタ CLI コマンドを使用する必要があります。splunk restart は使用しないでくださ
い。詳細は、「クラスタ全体または 1 台のクラスタノードの再起動」を参照してください。
非クラスタ構成インデクサ ー の移行
既存の Splunk インデクサーのクラスタへの移行およびその結果や 影響については、「非クラスタインデクサーの
クラスタ化環境への移行」を参照してください。
システム要件とその他のデプロイに 関 する 討事項
クラスタは Splunk インデクサーのグループなので、その大部分は Splunk インデクサーのシステム要件に準 して
います。Splunk インデクサーの詳細なソフトウェア/ハードウェア要件については、『Installation Manual』の
「System requirements」を参照してください。このトピックには、クラスタに関する他の要件を記載していま
す。
ハ ー ドウェア要件
クラスタの各コンポーネント (マスターノード、ピアノード、およびサーチヘッド) は、別個のマシンまたは VM
上で動作する必要があります。それ以外は、『Installation Manual』の「Reference hardware」に記載されている
ように、ハードウェア要件はどの Splunk インスタンスでも基本的には同じです。
注意：マスターノードのハードウェアストレージに関するニーズは、「Reference hardware」に記載されている要
件よりも低くなっています (マスターは外部データのインデックスを作成しないため)。
Splunk バ ー ジョンの互換性
バージョン 5.0 以上の Splunk インデクサーグループにクラスタリングを導入することができます。サーチヘッド
を含めすべてのクラスタコンポーネントで、同じバージョンの Splunk が動作していなければなりません。
必要な Splunk インスタンス
各クラスタノードは、独自の Splunk インスタンス上に常駐する必要があります。そのため、クラスタには最低で
も「複製データ保持数 + 2」個の Splunk インスタンスが必要です。内訳は、「複製データ保持数」台のピアノー
ド、および 1 台のマスターノード、および 1 台または複数台のサーチヘッドになります。たとえば、複製データ
保持数が 3 のクラスタをデプロイする場合は、最低でも 5 つの Splunk インスタンスが必要になります。3 つはピ
ア用に、1 つはマスター用に、1 つはサーチヘッド用になります。複製データ保持数の詳細は、「複製データ保持
数」を参照してください。
クラスタのサイズは、複製データ保持数だけでなく、インデックスを作成するデータ量などの他の要因によっても
異なります。詳細は、このマニュアルの「デプロイの概要」を参照してください。
ネットワ ー ク要件
クラスタ内のすべてのノードを、各ノードが他のノードにアクセスできる高速ネットワーク上に配置する必要があ
55
ります。これには、マスターノード、ピアノード、およびサーチヘッドが含まれます。
ノードは同じサブネット上または同じデータセンター内に存在していなくても構いません (データセンター間の接
続が非常に高速な場合)。server.conf でクラスタの各種タイムアウト設定を調節することができます。タイムアウ
トの設定について支援が必要な場合は、Splunk プロフェッショナルサービスまでお問い合わせください。
注意：十分な高品質の接続がある場合は、複数のデータセンターにまたがってクラスタをデプロイすることができ
ます。ただし、現在のバージョンの Splunk では、クラスタはサイトを認識していません。たとえば、2 つのデー
タセンターにまたがってピアノードが存在している場合に、あるデータセンターのノード上にクラスタデータの 1
つの複製コピーを、別のデータセンターのノード上に別のコピーを配置するように指定することはできません。ク
ラスタ内で一連のデータセットの複製方法をマスターが決定する際に、ピアの場所は考慮されません。
ストレ ー ジの 討事項
クラスタ化インデックスのストレージ要件を考慮する場合、非クラスタインデックスと比べて 2 つの点で異なって
います。
一連のピアノードで、複数のデータコピーを取り扱うために容量が える。
使用するストレージハードウェアの種類。
クラスタは、「インデックスストレージの設定」に記載されているように、インデックスストレージを管理するた
めに通常の設定を使用します。
ストレージ要件の決定
ピアノードが処理するデータの量を保管するために、十分な量のディスクスペースを確保することが重要になりま
す。Splunk のデータ量およびストレージニーズの概算方法に関する一般情報ついては、『Installation Manual』の
「Estimating your storage requirements」を参照してください。そこには、非クラスタ構成のインデクサーにスト
レージの見積もり方法が記載されています。そのガイドラインを参考に、クラスタに必要となる余分なデータコ
ピーの量を概算してください。
クラスタを利用する場合は、転送されてくるデータ量を 討するだけではなく、複製データ保持数とサーチ可能
データ保持数も考慮して、一連のピアノードの合計ストレージ要件を判断する必要があります。複製データ保持数
が 3 の場合、データのコピーを 3 つ保管することになります。これらのコピーを保管するために余分なストレー
ジスペースが必要になりますが、3 倍のストレージが必要になる訳ではありません。データのサーチ不可コピーは
サーチ可コピーよりもサイズが小さくなります (データのみで するインデックスファイルは含まれていないた
め)。そのため、たとえば複製データ保持数が 3 でサーチ可能データ保持数が 2 の場合、非クラスタ構成のインデ
クサーに同じデータを保管する場合と比べて、2 倍以上 3 倍未 のストレージスペースが必要となります。
サーチ不可コピーにより減らせるストレージ量を知るには、他にもいくつかの事項を調査する必要があります。
サーチ不可コピーで不要になるインデックスファイルのサイズは、「Estimating your storage requirements」に記
述されている要因によって大幅に 動します。
重要：マスターは個別のピアノードのストレージ量を把握していません。そのため、特定の複製データセットを受
け取るピアノードの決定時には、ノードのストレージ量は考慮されません。また、どのピアが複製データをサーチ
可にするかも任意に決定されます (サーチ可能データ保持数が 2 以上の場合)。そのため、各ピアノードには、その
ピアが保有するデータだけではなく、他のピアから転送されてくる可能性がある複製コピー用のストレージも十分
に確保する必要があります。(「インデックスボリュームを使ったストレージ管理の簡素化」で 明しているよう
に、インデックスボリュームを使ってストレージを管理することをお勧めします。)クラスタにおけるストレージ
の使用量は、そのライフサイクルを通して常時監視しておく必要があります。
ストレージ要件の例
概算で、受信した syslog データが Splunk で 縮、インデックス作成されると、元のサイズの約 50% になります。
raw データに 15%。
関連するインデックスファイルに 35%。
実際には、この概算値は『Installation Manual』の「Estimating your storage requirements」に記述されている各種
要因によって大幅に 動します。
Splunk に取り込まれる syslog データが 100GB であると仮定します。非クラスタ構成のインデクサーの場合、そ
のデータは Splunk のストレージのうち 50GB (100GB の 50%) を占有します。ただし、クラスタの場合、スト
レージの計算には複製データ保持数とサーチ可能データ保持数を考慮して、すべてのクラスタピアの合計ストレー
ジ要件を判断する必要があります。(前述のように、特定のピアで必要になるストレージ量を正確に予測すること
は困難です。)
ここでは、クラスタのストレージ要件を見積もる 2 つの例を取り上げていきます。どちらの例でも、受信する
syslog データは 100GB で、その結果 15GB の raw データと 35GB のインデックスが作成されることを前提にして
56
います。
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。
ストレージハードウェア
ホット/ウォームおよびコールドバケツの場所は、それぞれ indexes.conf 内の homePath および coldPath で指定し
ます。詳細は、「インデックスストレージの設定」を参照してください。非クラスタ構成のインデクサーと比べ
て、クラスタではこれらの保管場所に使用するストレージタイプに関する要件がとても異なっています。
非クラスタ構成のインデクサーでは、ホット/ウォームバケツとコールドバケツに して個別のパーティションを指
定することにより、それぞれに して異なる種類のストレージを指定することができます。一般的にコールドバケ
ツはホット/ウォームバケツと比べてアクセス頻度が比較的少ないため、この方法を利用してコールドバケツを低
速なディスクアレイに保管することができます。また、通常はコールドバケツに してインデックス作成処理を実
施する必要はありません。詳細は、「インデックスデータ用の複数のパーティションの使用」を参照してくださ
い。
ただしクラスタの場合、この方法はお勧めできません。coldPath の保管場所に使用するストレージに
は、homePath に使用するストレージと同じパフォーマンス特性が必要です。これは、バケツの複製されたコピー
がすべて、ピアの coldPath ディレクトリに保管されるためです。ホット、ウォーム、またはコールドかどうかは
関係ありません。coldPath に して いストレージを使用した場合、クラスタの総合的なパフォーマンスが低下して
しまいます。
クラスタ運用のニーズに するためにも、coldPath には高性能のストレージが必要です。たとえば、coldPath に存
在するバケツが、引き続き書き込まれているホットバケツである場合があります。他のバケツはウォームコピーに
複製され、サーチヘッドはそれらに頻繁にアクセスします。また、クラスタの設定および今後何が行われるか (ピ
アがオフラインになるなど) に じて、ピアのバケツコピーをサーチ不可からサーチ可に 換しなければなら
ず、coldPath データの処理にかなりの時間がかかることもあります。
また、通常コールドバケツのストレージニーズに加えて、ホット/ウォームバケツのすべての複製コピーを取り扱
うために、各ピアには十分な容量の coldPath ストレージを確保しておく必要があります。
注意：coldPath に保管されるのは、複製されたホット/ウォームバケツのみです。ホット/ウォームバケツの元のコ
ピーは、通常と わらずにピアの homePath に保管されます。また、すべてのコールドバケツのコピーは coldPath
に保管されます。
ライセンス情報
他の Splunk デプロイ環境と同 に、ライセンス要件はインデクサーが処理するデータ量により決まります。追加量
のライセンスを購入するには、Splunk 営業担当にお問い合わせください。Splunk ライセンスの詳細は、『管理マ
ニュアル』の「ライセンスの仕組み」を参照してください。
インデックス複製におけるライセンス上の問題はさほど多くはありません。
マスター、ピア、サーチヘッドを含めクラスタメンバーはすべて、Enterprise ライセンスプールに割り当て
る必要があります (インデックス作成処理を行わない場合でも)。
クラスタメンバーは、同じライセンス設定を共有する必要があります。
ライセンスに しては受信データのみがカウントされます。複製されたデータは 象外です。
無料版ライセンスでは、インデックス複製は利用できません。
サ ー バ ー とクラスタのデプロイ
クラスタピアにはデプロイサーバーを使用しないでください。
クラスタピアへの設定や App の配布手段として、デプロイサーバーはサポートされていません。一連のクラスタ
ピアに設定を配布するには、「共通のピア設定の更新」で 明されている設定バンドルを使用してください。
デプロイサーバーから設定バンドルを使った App 配布への移行方法の詳細は、「クラスタへの App の移行」を参
照してください。
57
マスタ ー ノ ー ドを有 効 にする
このトピックを読む前に、「デプロイの概要」をご覧ください。
クラスタには、マスターノードが 1 台のみ存在しています。マスターノードは、ピアノードのアクティビティを調
整します。それ自体がデータを保管または複製することはありません (自己の内部データを除く)。
重要：マスターノードはピアノードのように、2 つの作業を兼務することはできません。マスターノードとして有
効にした Splunk インスタンスは、1 つの役割のみを担当する必要があります。また、マスターノードはピアとマ
シンを共有することはできません。
クラスタのデプロイ時には、ピアノードを設定する前に、最初のステップでマスターノードを有効にする必要があ
ります。
注意：このトピックに記載されている手順は、Splunk 管理を使ってマスターノードを有効にする方法について 明
しています。その他にも、2 種類の方法でマスターノードを有効にすることができます。
マスターの server.conf ファイルを直接編集する。詳細は、「server.conf によるクラスタの設定」を参照し
てください。一部の高度な設定は、このファイルを編集することによってのみ設定できます。
CLI の edit cluster-config コマンドを使用する。詳細は、「CLI によるクラスタの設定」を参照してくだ
さい。
マスタ ー を有 効 にする
インデクサーをマスターノードとして有効にするには：
1. Splunk Web で [管理] をクリックします。
2. [分散環境] セクションで、[クラスタリング] をクリックします。
3. [クラスタリングを有効にする] を選 します。
4. [このインスタンスをクラスタマスターにします。] を選 します。
5. 他にもいくつかのフィールドを記入する必要があります。
作成する各バケツのコピー数は？これは、クラスタの複製データ保持数です。デフォルトは 3 です。複製
データ保持数の詳細は、「複製データ保持数」を参照してください。適切な複製データ保持数を今すぐ選 し
てください。後ほどクラスタが大量のデータを保有するようになってから、複製データ保持数の値を やすこ
とはお勧めできません。
インデクサーのハートビートタイムアウトは？デフォルト値は 60 秒です。Splunk サポートに確認せずに、
この値を 更しないでください。ハートビートタイムアウト期間内にマスターがピアからの 答を受信しない場
合、ピアが停止したものと判断し、復旧措置を開始します。通常ピアは、マスターに 秒ごとにハートビート
を送信します。
作成する各バケツのサーチ可コピー数は？これは、クラスタのサーチ可能データ保持数です。デフォルトは
2 です。複製データ保持数の詳細は、「複製データ保持数」を参照してください。適切なサーチ可能データ
保持数を今すぐ選 してください。後ほどクラスタが大量のデータを保有するようになってから、サーチ可能
データ保持数の値を やすことはまったくお勧めできません。
秘密鍵：マスター、ピア、サーチヘッド間の通信を認証するための鍵です。鍵は、すべてのクラスタインス
タンス間で同じでなければなりません。ここでフィールドを空にする場合は、他のピアやサーチヘッドに し
ても同じように空にしてください。
6. [保存] をクリックします。
7. ページの上部にある情報バーから、「 更内容を有効にするには、Splunk を再起動する必要があります。ここを
クリックして Splunk 管理から再起動してください。」と言うメッセージを探してください。リンクをクリックす
ると [管理] ページに移動します。そこから再起動を行えます。
重要：マスターを初めて起動した場合、すべてのピア (複製データ保持数と同じ数のピア) を有効にして再起動す
るまでは、ピアにおけるインデックス作成がマスターによりブロックされます。
マスターノードの詳細設定については、「マスターの設定」を参照してください。
マスタ ー ダッシュボ ー ドの表示
再起動後、マスターノードに再度ログインして、[管理] の [クラスタリング] ページに ります。今回は、マスターク
ラスタリングダッシュボードが表示されます。ダッシュボードの詳細は、「マスターダッシュボードの表示」を参
照してください。
58
追加設定
デプロイ後のマスターノードの設定については、このマニュアルの「マスターの設定」を参照してください。
ピアノ ー ドを有 効 にする
このトピックを読む前に、「デプロイの概要」をご覧ください。
通常は、クラスタをデプロイするために複数のピアノードを有効にする必要があります。最低でも、複製データ保
持数と等しい数のピアを有効にする必要があります。水平スケーリングに するために、より多くのピアが必要な
場合もあります。
一連のピアを有効にする前に、「マスターノードを有効にする」の 明に従ってマスターノードを有効にして再起
動する必要があります。マスターを初めて起動した場合、複製データ保持数と同じ数のピアを有効にして再起動す
るまでは、ピアにおけるインデックス作成がマスターによりブロックされます。
注意：このトピックに記載されている手順は、Splunk 管理を使ってピアノードを有効にする方法について 明して
います。その他にも、2 種類の方法でビアノードを有効にすることができます。
ピアの server.conf ファイルを直接編集する。詳細は、「server.conf によるクラスタの設定」を参照してく
ださい。
CLI の edit cluster-config コマンドを使用する。詳細は、「CLI によるクラスタの設定」を参照してくだ
さい。
ピアを有 効 にする
インデクサーをピアノードとして有効にするには：
1. Splunk Web で [管理] をクリックします。
2. [分散環境] セクションで、[クラスタリング] をクリックします。
3. [クラスタリングを有効にする] を選 します。
4. [このインスタンスをクラスタピアにします。] を選 します。
5. 他にもいくつかのフィールドを記入する必要があります。
クラスタマスターの場所は？マスターの IP アドレスまたはドメイン名、およびその管理ポートを入力しま
す。この情報は、マスターのクラスタリングダッシュボードに表示されます。例：
https://10.152.31.202:8089
秘密鍵：マスター、ピア、サーチヘッド間の通信を認証するための鍵です。鍵は、すべてのクラスタインス
タンス間で同じでなければなりません。マスターに秘密鍵がある場合は、ここに入力する必要があります。
複製ポート：これは、ピアが他のピアから転送された複製データを受信するポートです。この目的で、利用
可能な任意のポートを指定することができます。
6. [保存] をクリックします。
7. ページの上部にある情報バーから、「 更内容を有効にするには、Splunk を再起動する必要があります。ここを
クリックして Splunk 管理から再起動してください。」と言うメッセージを探してください。リンクをクリックす
ると [管理] ページに移動します。そこから再起動を行えます。
8. クラスタのすべてのピアノードに して、この作業を繰り返します。
複製データ保持数と同じ数のピアを有効にしたら、クラスタでインデックスの作成とデータの複製を開始できます
(「マスターノードを有効にする」を参照)。
ピアダッシュボ ー ドの表示
再起動後、ピアノードに再度ログインして、[管理] の [クラスタリング] ページに ります。今回は、ピアのクラスタ
リングダッシュボードが表示されます。ダッシュボードの詳細は、「ピアダッシュボードの表示」を参照してくだ
さい。
ピアの設定
ピアを有効にした後は、データのインデックス作成を開始する前に、各種設定を行う必要があります。詳細は、以
59
下のトピックを参照してください。
ピアインデックスの設定
フォワーダーを使ったデータの取り込み
また、いくつかの詳細オプションを設定することもできます。「ピアノードの設定」を参照してください。
サ ー チヘッドを有 効 にする
このトピックを読む前に、「デプロイの概要」をご覧ください。
クラスタをサーチするには、最低 1 台のクラスタサーチヘッドを有効にする必要があります。
一連のピアを有効にする前に、「マスターノードを有効にする」の 明に従ってマスターノードを有効にして再起
動する必要があります。
注意：このトピックに記載されている手順は、Splunk 管理を使ってサーチヘッドを有効にする方法について 明し
ています。その他にも、2 種類の方法でサーチヘッドを有効にすることができます。
サーチヘッドの server.conf ファイルを直接編集する。詳細は、「server.conf によるクラスタの設定」を参
照してください。複数クラスタサーチなど一部の高度な設定は、このファイルを編集することによってのみ
設定できます。
CLI の edit cluster-config コマンドを使用する。詳細は、「CLI によるクラスタの設定」を参照してくだ
さい。
サ ー チヘッドを有 効 にする
Splunk インスタンスをクラスタのサーチヘッドとして有効にするには：
1. Splunk Web で [管理] をクリックします。
2. [分散環境] セクションで、[クラスタリング] をクリックします。
3. [クラスタリングを有効にする] を選 します。
4. [このインスタンスをサーチヘッドにします。] を選 します。
5. 他にも 2 つのフィールドを記入する必要があります。
クラスタマスターの場所は？マスターの IP アドレスまたはドメイン名、およびその管理ポートを入力しま
す。この情報は、マスターのクラスタリングダッシュボードに表示されます。例：
https://10.152.31.202:8089
秘密鍵：マスター、ピア、サーチヘッド間の通信を認証するための鍵です。鍵は、すべてのクラスタインス
タンス間で同じでなければなりません。マスターに秘密鍵がある場合は、ここに入力する必要があります。
6. [保存] をクリックします。
7. ページの上部にある情報バーから、「 更内容を有効にするには、Splunk を再起動する必要があります。ここを
クリックして Splunk 管理から再起動してください。」と言うメッセージを探してください。リンクをクリックす
ると [管理] ページに移動します。そこから再起動を行えます。
サ ー チヘッドダッシュボ ー ドの表示
再起動後、サーチヘッドに再度ログインして、[管理] の [クラスタリング] ページに ります。今回は、サーチヘッド
のクラスタリングダッシュボードが表示されます。詳細は、「サーチヘッドダッシュボードの表示」を参照してく
ださい。
複 数 クラスタサ ー チを有 効 にする
サーチヘッドは、複数のクラスタにまたがったサーチを実行することができます。この機能を有効にするには、
「複数クラスタサーチの設定」の 明に従って server.conf を直接編集する必要があります。
複 数 のサ ー チヘッドの設定
多数の同時サーチを可能にするために、複数のサーチヘッドを設定することができます。サーチヘッドのニーズの
決定方法については、『Distributed Deployment Manual』の「Hardware capacity planning for a distributed Splunk
deployment」を参照してください。
60
複数のサーチヘッドを設定する場合は、単に追加のインスタンスに して有効化のための手順を繰り返します。複
数のサーチヘッドで設定とユーザーデータを共有するためにプールを使用する場合については、『Distributed
Deployment Manual』の「Configure search head pooling」を参照してください。
追加設定
クラスタ化したサーチヘッドの設定については、このマニュアルの「サーチヘッドの設定」を参照してください。
ピアのインデックスレプリケ ー ションの準備
ピアを有効にしたら、インデックスレプリケーションの準備のために、さらなる設定作業を行わなければならない
こともあります。特に、ピアがインデックスの共通セットを使用していることを確認する必要があります。また、
その他の設定や App をすべてのピアに配布しなければならないこともあります。
デフォルトのインデックスセットのみを使用する場合は、即座にレプリケーションを開始することができます。た
だし、データを他のインデックス (App が定義するインデックスも含む) にも送信する必要がある場合は、まず追
加の設定作業を実施する必要があります。
クラスタピアにまたがったインデックスの設定方法については、「ピアインデックスの設定」を参照してくださ
い。
ピアにまたがった App の設定方法および他のピア設定上の問題については、「ピアの設定」を参照してくださ
い。
フォワ ー ダ ー を使ったデ ー タの取り 込 み
クラスタピアノードは、非クラスタ構成のインデックスと同 に任意のソースから、データを直接取り込むことが
できます。ただし、データの忠実度が重要な場合は、ノードに直接データを取り込む代わりに、まずロードバラン
シングフォワーダーを使ってデータを取り込んでから、それをピアノードに転送します。フォワーダーからデータ
を受け取るノードは、レシーバーまたは受信ノードと呼ばれています。
フォワーダー、特にロードバランシングフォワーダーを使用してクラスタにデータを転送する理由としては、主に
以下の 2 点が げられます。
すべての受信データのインデックスを確実に作成する。フォワーダーのインデクサー 答確認機能を有効にす
れば、すべての受信データのインデックスが作成され、クラスタに保管されたことを確認できます。この仕
組みは次のようになります。ピアがフォワーダーからデータブロックを受信すると、そのデータのインデッ
クスを作成後、フォワーダーに 答確認を送信します。フォワーダーがピアから 答確認を受信しない場合は、
データを再送信します。フォワーダーは 答確認を受信するまで、データの再送を繰り返します。インデク
サー 答確認は、終端間データの忠実度を確保するための唯一の手段です。このトピック後半の「インデク
サー 答確認の仕組み」を参照してください。
潜在的なノード障害に 処する：フォワーダーのロードバランシングにより、ロードバランシングが行われて
いるグループ内のある受信ノードが停止した場合、フォワーダーはそのグループ内の残りのピアに引き続き
データを送信します。ロードバランシングがない場合、受信ノードが停止すると、フォワーダーはデータの
送信を続行する手段がありません。このトピック後半の「ロードバランシングの仕組み」を参照してくださ
い。
重要：続行する前に、フォワーダーの詳細およびそれを使った Splunk へのデータの取り込み方法を理解しておく
必要があります。フォワーダーの基本については、『Distributed Deployment Manual』の「About forwarding and
receiving」を参照してください。そのマニュアルのそれ以降のトピックには、フォワーダーのデプロイおよび設定
方法が詳細に記述されています。
フォワーダーを使ってクラスタにデータを取り込むには、2 種類の設定作業を行う必要があります。
1. フォワーダーからピアノードへの接続を設定します。
2. フォワーダーのデータの取り込み方法を設定します。
注意：このトピックは、ユニバーサルフォワーダーを使用していることを前提にしています。ただし、基本的な手
順はライトフォワーダーでもヘビーフォワーダーでも同じです。
フォワ ー ダ ー からピアノ ー ドへの接 続 の設定
フォワーダーとピアノード間の接続を設定するために、3 つのステップで作業を行います。
1. フォワーダーからデータを受信するようにピアノードを設定します。
61
2. ピアノードにデータを送信するようにフォワーダーを設定します。
3. 各フォワーダー上でインデクサー 答確認を有効にします。このステップは、終端間データの忠実度を確保する
ために必要です。デプロイの要件で忠実度が不要な場合は、このステップをスキップしても構いません。ただし、
インデクサー 答確認を使用していないことを警告するメッセージが表示されます。
接続の設定が完了したら、フォワーダーへのデータストリーム (これがクラスタに転送される) を制御するデータ
入力を設定します。この方法については、「フォワーダーのデータ取り込みの設定」を参照してください。
1. フ ォ ワ ー ダ ー か ら デ ー タ を 受 信 す る よ う に ピ ア ノ ー ド を 設 定 す る
ピアがフォワーダーからデータを受信するためには、ピアの受信ポートを設定する必要があります。受信ポートの
設定方法については、『Distributed Deployment Manual』の「Enable a receiver」を参照してください。
重要：ピアの $SPLUNK_HOME/etc/system/local/ にある inputs.conf ファイルを編集して受信ポートを指定すること
ができます。多くのクラスタでは、同一の inputs.conf ファイルをすべてのピアに配布することにより、ピア入力
設定の手間を減らすことができます。この場合、各ピア個別に指定した受信ポートよりも、共通版の inputs.conf
に指定されている受信ポートが優先されます。すべてのピアにまたがった共通の inputs.conf の作成およびデプロ
イの詳細については、「共通のピア設定の更新」を参照してください。
2. ピ ア ノ ー ド に デ ー タ を 送 信 す る よ う に フ ォ ワ ー ダ ー を 設 定 す る
フォワーダーを設定する場合、受信ピアの IP アドレスと受信ポート番号を指定します。例：10.10.10.1:9997この
作業は、フォワーダーの outputs.conf ファイルで行います。詳細は、『Distributed Deployment Manual』の
「Configure forwarders with 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
ロードバランシングの詳細については、『Distributed Deployment Manual』の「Set up load balancing」を参照し
てください。
注意：フォワーダーの受信ピアを指定するには、他にもさまざまな方法が存在しています。例：
フォワーダーのデプロイ時に、受信ピアを指定することができます (Windows フォワーダーのみ)。
『Deployment Manual』の「Deploy a Windows forwarder manually」を参照してください。
『Distributed Deployment Manual』の「Deploy a *nix forwarder manually」の 明に従って、CLI コマンド add
forward-server を持つレシーバーを指定することができます。
これらの手法はどちらも、outputs.conf ファイルを 更することにより可能です。どの方法で受信ピアを指定した
場合でも、outputs.conf ファイルを直接編集して、次の手順で 明しているようにインデクサー 答確認をオンにす
る必要があります。
3. 各 フ ォ ワ ー ダ ー 上 で イ ン デ ク サ ー 答 確 認 を 有 効 に す る
クラスタがすべての到着データを受信してインデックス作成するために、各フォワーダー上でインデクサー 答確
認をオンにする必要があります。このためには、outputs.conf の useACK 属性に true を設定します。
useACK=true
また、ピアノードからの 答を待機中にフォワーダーがブロックされないように、フォワーダーの maxQueueSize に
7MB を設定する必要があります。
[tcpout]
maxQueueSize = 7MB
インデクサー 答確認の設定方法および maxQueueSize 設定の詳細は、『Distributed Deployment Manual』の
「Protect against loss of in-flight data」を参照してください。
注意：このステップは、終端間データの忠実度を確保するために必要です。デプロイの要件で忠実度が不要な場合
62
は、このステップをスキップしても構いません。ただし、インデクサー 答確認を使用していないことを警告する
メッセージが表示されます。
例：インデクサー 答確認を使用するロードバランシングフォワーダー
ロードバランシングを使ってクラスタ内の 3 つのピアに順番にデータを送信するフォワーダー用の outputs.conf
設定例を以下に示します。この例では、各ピアが受信ポートとして 9997 を使用すると仮定しています。
[tcpout]
defaultGroup=my_LB_peers
maxQueueSize = 7MB
[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
秒後、別のピアに切り替えて、その後も同 に作業を行います。任意の時点でその時の受信ノードから 答確認がな
い場合、次に利用可能なノードにデータを再送信します。
フォワ ー ダ ー のデ ー タ入力の設定
フォワーダーと受信ピア間の接続を指定したら、クラスタにデータを送信するための、フォワーダーへのデータ入
力を指定する必要があります。一般的には、フォワーダーの inputs.conf ファイルを編集します。データ入力の設
定の詳細は、『Getting Data In Manual』の「What Splunk can index」を参照してください。また、そのマニュア
ルの「Use forwarders」には、フォワーダーのデータ入力の指定方法の概要が記載されています。
インデクサ ー 答確認の仕組み
簡単に言えば、インデクサー 答確認は次のように動作します。フォワーダーは受信ピアに 続的にデータを送信し
ます (約 64 KB のブロックで)。フォワーダーは、ピアから 答確認を受信するまでの間、各ブロックのコピーを保
持します。待機中でも、その他のブロックは引き続き送信されます。
すべてが順調な場合、受信ピアは：
1. データブロックを受信し、それを解析してインデックスを作成し、データ (raw データとインデックスデータ) を
ファイルシステムに書き込みます。
2. raw データのコピーをターゲットピアに複製します。
3. フォワーダーに 答確認を送信します。
答確認により、データが正常にクラスタに書き込まれたことを確認できます。 答確認を受信すると、フォワー
ダーは当該ブロックをメモリーから解放します。
注意：受信ピアは、データのターゲットピアへの複製を試みた後に、 答確認をフォワーダーに送信します。デー
タの複製が正常に行われたかどうかに関係なく、 答確認は送信されます。受信ピアがデータの複製を試みたかど
うかで判断されます。複製を試みた後は、受信ピアまたはターゲットピアのいずれかにノード障害が発生しても、
クラスタはデータを回復することができます。
この一連の処理中に何らかの障害が発生した場合、フォワーダーは 答確認を受信しません。この場合、自動的に
データブロックが再送信されます。フォワーダーにロードバランシングが設定されている場合は、そのロードバラ
ンシンググループ内の他の受信ノードにブロックが送信されます。フォワーダーにロードバランシングが設定され
ていない場合は、前述のように同じノードにデータが再送信されます。
重要：終端間のデータの忠実度を保証するためには、クラスタにデータを送信する各フォワーダーに して明示的
にインデクサー 答確認を有効にする必要があります。このためには、フォワーダーの outputs.conf ファイルで
useACK 属性に true を設定します。デプロイの要件で終端間データの忠実度が不要な場合は、このステップをス
キップしても構いません。ただし、インデクサー 答確認を使用していないことを警告するメッセージが表示され
ます。
インデクサー 答確認の仕組みについては、『Distributed Deployment Manual』の「Protect against loss of in-flight
data」を参照してください。
ロ ー ドバランシングの仕組み
ロードバランシングでは、フォワーダーは到着データを複数の受信ピアノードに分散します。各ノードはデータ全
体の一部を受け取り、各受信ノードのデータをまとめたものが全データになります。
63
Splunk フォワーダーは自動ロードバランシングを実行します。フォワーダーは、指定された時間間隔に基づいて
異なるノードにデータをルーティングします。たとえば、3 台のピアノードから成り立っているロードバランシン
ググループを考えてみましょう。それぞれのノードを A、B、および C とします。フォワーダーは指定された 30
秒などの一定の間隔で、データストリームを、グループ内の他のノードに切り替えます。ノードは無作為に選 さ
れます。たとえばフォワーダーは、ノード B からノード A に切り替え、次にノード C に切り替えます。あるノー
ドが停止すると、即座に別のノードに切り替えられます。
注意：フォワーダーがモニターするように設定されている、各入力に するデータストリームがあります。フォ
ワーダーはデータストリームを他のノードに切り替えても安全かどうかを判断します。次に、指定されている間隔
で、新たに選 したノードにデータストリームを切り替えます。新しいノードにデータストリームを安全に切り替
えることができなかった場合は、安全に送信できるようになるまでの間、前のノードとの接続を維持してデータス
トリームの送信を 続します。
ロードバランシングは、クラスタ展開において重要な役割を果たします。ノード障害時にも、データが失われるこ
とはありません。フォワーダーがデータを送信したノードからインデクサー 答確認を受信しない場合、そのデー
タはロードバランシング内の次に利用できるノードに送信されます。
フォワーダーのロードバランシングの詳細については、『Distributed Deployment Manual』の「Set up load
balancing」を参照してください。インデクサー 答確認とロードバランシングの仕組みについては、『Distributed
Deployment Manual』の「Protect against loss of in-flight data」を参照してください。
ピア上で直接入力を設定する
データ入力にフォワーダーを使用しない場合、通常のように各ピア上で入力を設定することができます。たとえ
ば、inputs.conf を編集します。入力の設定方法の詳細は、『Getting Data In Manual』の「Configure your
inputs」を参照してください。
クラスタを使ったインデックスの 強
クラスタの主な目的は、インデックスレプリケーションを有効にすることにあります。また、クラスタはデプロイ
トポロジを 張する場合にも役立ちます。インデックスレプリケーションが不要な場合でも、複数のインデクサー
を管理するための手段として利用できます。
たとえば、単一のインデクサーでは 処しきれないほど大量のデータのインデックスを作成、保管するために、3 台
のインデクサーと 1 台のサーチヘッドのデプロイ環境を作成する場合を考えてみましょう。Splunk 5.0 より前でこ
のような環境を実現する唯一の方法は、各インデクサーを個別に設定し、サーチヘッドに追加した後、デプロイ
サーバーのようなツールを使ってインデクサー設定を調整することでした。
クラスタリングを利用すれば、デプロイ用にクラスタを設定して 3 台のインデクサーの代わりに 3 台のピアノー
ドを指定できます。インデックスレプリケーションおよびその他の主な利点であるデータ可用性や耐障害性が不要
な場合でも、クラスタを使って複数のインデクサーインスタンスを調整することにはさまざまな利点があります。
管理とインデクサー設定の調整が簡単 (デプロイサーバーを使ったり手動で更新するのではない)。詳細は、
「共通のピア設定の更新」を参照してください。
分散サーチの設定と制御が簡単。「サーチヘッドを有効にする」を参照してください。
クラスタリングダッシュボードを使ってインデクサーの状態を把握。「マスターダッシュボードを有効にす
る」を参照してください。
開発された新たなクラスタ管理機能を活用できる。
インデックス作成能力を 強するためにクラスタを採用することの主な欠点を以下に示します。
クラスタのマスターノードとして機能する Splunk インスタンスを追加でインストールする必要がある。
すべてのクラスタコンポーネントが同じ高速ネットワーク上になければなりません。
クラスタは異種インデクサーをサポートしていない。クラスタ内のすべてのピアノードが同じ indexes.conf
設定を使用する必要があります。詳細は、次のセクションの「クラスタピア管理とデプロイサーバーの比
較」を参照してください。
デプロイサーバーを使って、クラスタピアに設定や App を配布することはできません。詳細は、次のセク
ションの「クラスタピア管理とデプロイサーバーの比較」を参照してください。
クラスタピア管理とデプロイサ ー バ ー の比較
クラスタの役に立つ機能の 1 つとして、マスターノードからすべてのインデクサー (ピアノード) の設定を管理、
更新できることが げられます。その点では、デプロイサーバーと機能が似ています。ただし、デプロイサーバー
とは異なり、ピア管理にはサーバークラスの概念がありません。このこと、およびクラスタのアクティビティの調
整方法により、異なるグループのインデクサーに、異なる App または indexes.conf を指定することはできませ
ん。(「ピアノードの設定」で 明しているように、クラスタ内のすべてのピアノードが、同じ indexes.conf 設定お
よび他の設定を使用する必要があります。)異種セットのインデクサーが必要な場合は、機能 強のためにクラスタ
64
を使用することはできません。
また、複数のピアノードにまたがって設定や App を配布する手段として、デプロイサーバーやサードパーティ製
の分散設定管理ソフトウェア (例：Puppet や Chef など) はサポートされていません。
一方、ピアノードへのアップデートのダウンロードに用いられる設定バンドルには、デプロイサーバーと比べて利
点があります。アップデートを配布するだけでなく、ピア上でそれを 証してから、ピアを順番に再起動していき
ます。詳細は、「共通のピア設定の更新」を参照してください。
処 理能力 強 デプロイのためのクラスタの設定
処理能力を 強するためのデプロイでクラスタを設定するには (インデックスレプリケーションなし)、複製データ
保持数とサーチ可能データ保持数に単に 1 を設定します。こうすることにより、クラスタはデータ複製を行わず、
単純に一連の Splunk インスタンスの調整を行います。データの複製コピーは保持されないため、必要なストレー
ジサイズを減らすことができ、処理上のオーバーヘッドも最低限に抑えられます。
非クラスタインデクサ ー のクラスタ化環境への移
行
現在のインデクサーセットをクラスタに移行することを計画している場合は、「クラスタ構成と非クラスタ構成の
Splunk デプロイの主な相違点」を注意深くお読みください。このトピックには、移行作業を開始する前に理解し
ておく必要がある問題点が記述されています。
任意の時点で、非クラスタインデクサーをクラスタに (ピアノードとして) 追加することができます。そのために
は、「ピアノードを有効にする」で 明しているように、インデクサーをピアとして有効にします。
インデクサーをピアにすると、それは他のピアと同 にクラスタに参加します。ピアに到着する新規データは、ク
ラスタの複製データ保持数に じて複製されます。また、ピアは他のピアからの複製データを受信する候補でもあ
ります。インデクサー上にすでに存在しているデータが自動的に複製されることはありませんが、後述するように
サーチには関与しています。
従来 のデ ー タの管理
「従来のデータ」とは、クラスタピアへの 換前にインデクサー上に保管されていたデータを表しています。
クラスタによる従来のインデックスデータの処理
クラスタに既存のインデクサーを追加した場合、すでにインデクサー上に存在しているバケツは複製されません。
クラスタに追加する前からインデクサー上に存在していたバケツは、「スタンドアロン」のバケツと呼ばれていま
す。そのようなバケツに してもサーチは行われ、クラスタ内の他の複製されたバケツからのサーチ結果と統合さ
れます。
従来のデータを移行する方法はありませんか？
スタンドアロンのバケツを複製 象バケツに 換するコストが高いため (クラスタの複製データ保持数とサーチ可能
データ保持数を たすために、複数のサーチ可およびサーチ不可コピーを作成する必要があるため)、一般的には 換
することはお勧めできません (特に大量のスタンドアロンバケツを持つインデクサーの場合)。この 換について
は、保証している 換手順はありません。どうしても 換する必要があるような場合は、Splunk プロフェッショナル
サービスにそのような作業のトレードオフや要件をお問い合わせください。
クラスタへの App の移行
現在の非クラスタ環境で、一連のインデクサーへの App の配布に、デプロイサーバーを使用している方もいるで
しょう。インデクサーをクラスタのピアノードに 換したら、この方法は利用できなくなります。詳細は、「クラ
スタ構成と非クラスタ構成の Splunk デプロイの主な相違点」を参照してください。
ピアノードに App を配布するには、「共通のピア設定と App の更新」の 明に従って設定バンドルを使用する必要
があります。App をマスターノード上の特別な場所に保管すると、最初にインデクサーをピアとして有効にした場
合に、マスターから各インデクサーにその App が配布されます。後ほど App を追加、 更する必要がある場合は、
マスター上で適切な追加、 更作業を行った後、マスターに更新された設定バンドルをピアセット全体に配布する
ように指示します。
設定バンドルを使う方法とデプロイサーバーを使う方法の比較については、「クラスタピア管理とデプロイサー
バーの比較」を参照してください。
65
重要：ピアノードに App を配布する場合は、設定バンドルを使用する必要があります。このような目的にデプロ
イサーバーを使用することはできません。
ク ラ ス タ App の 制 限 事 項
設定バンドルの一部として App をピアに配布する場合、非クラスタ App と比べて一定の制限事項があります。特
に、このようなクラスタ App は、サーチ時設定や Splunk Web コンポーネントをサポートしていません。詳細
は、「クラスタ App の制限事項」を参照してください。
App の 移 行 方 法
App はクラスタを有効にする際に移行することをお勧めします。そのための手順については、後述の 明を参照し
てください。
重要：この手順を実施する前に、この章の前半に記載されている各トピックの内容を正しく理解しておく必要があ
ります。「デプロイの概要」からこのトピックまでの 明を、あらかじめお読みになってください。
この手順は、デプロイサーバーのデプロイクライアントとして設定された一連のインデクサーセットが存在する、
分散サーチ環境を前提にしています。デプロイサーバーは、App とインデックス-時間設定をインデクサーにプッ
シュするために用いられています。これらのインデクサーを、クラスタのピアノードに 換します。ピアノードに
換したら、それ以降デプロイサーバーを使ってそれらのピアに App をプッシュすることはできません。代わりに
設定バンドルを使用する必要があります。
クラスタを有効にする際に App を移行するには、以下の手順に従ってください。
1. 「マスターノードを有効にする」の 明に従って、マスターを有効にします。
2. デプロイサーバー上で、マスターが移行予定のインデクサーに配布する一連の App を探します。これらの App
は、デプロイサーバーの $SPLUNK_HOME/etc/deployment-apps ディレクトリにあります。これらの App には、移行
する必要があるインデックス時設定が含まれていることを確認してください。無関係な設定からは、インデックス
時設定を削除することをお勧めします (一般的にはサーチ時設定)。
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 の更新
クラスタのアップグレ ー ド
66
重要：すべてのクラスタコンポーネント (マスター、ピア、およびサーチヘッド) で、同じバージョンの Splunk が
動作していなければなりません。あるノードをアップグレードする場合は、残りもすべてアップグレードしてくだ
さい。
クラスタコンポーネントをアップグレードするには、標準の Splunk アップグレード手順に従ってください。ただ
し、以下で 明するようにいくつかの例外があります。Splunk のアップグレードに関する一般的な情報について
は、「Splunk のアップグレード方法」を参照してください。
アップグレ ー ド順序
アップグレードは、以下の順序で順番に行ってください。
1. マスターノード。
2. すべてのピアノード。
3. サーチヘッド。
警告：すべてのクラスタコンポーネントのアップグレード準備が完了するまでは、アップグレード作業を開始しな
いでください。マスターをアップグレードしたけれどもピアをアップグレードしないと、クラスタにさまざまなエ
ラーや警告が発生します。
マスターノードのアップグレード
5.0.2 マスターのアップグレードの最後に、マスターはピアに新しいバージョンの設定バンドルを配布して、ピア
を再起動します。ピアが再起動されたら、即座にピアを 5.0.2 にアップグレードする必要があります。アップグ
レードするまでの間、ピアにはさまざまな警告やバンドル 証エラーが発生する可能性があります。
マスターのアップグレード時には、以下のような要件を知らせるメッセージが表示されます。
CLUSTER MASTER UPGRADE DETECTED!
This instance is a cluster master. You must upgrade its set of cluster peers
(indexers) to match the new version immediately following the master upgrade.
IMPORTANT: Continuing with this migration causes the master to immediately
restart its set of peers to apply a new configuration bundle.
Would you like to continue? (y/n)
続行しない妥当な理由がない限りは、表示されるメッセージに して「y」を入力してください。「n」を入力する
と、マスターはアップグレードの最後に停止して、ピアの再起動は行いません。ピアのアップグレード準備が完了
するまでマスターの再起動を停止することはできますが、その場合クラスタはマスターなしで動作します。短期間
ならそのような状況も可能ですが、時間が 過するにつれてエラーが発生する可能性が高くなっていきます。
どのような場合でも、ピアのアップグレードを らせることはお勧めできません。マスターのアップグレードを
ロールバックする手段はありません。そのため、ピアをアップグレードしない限り、ピアとマスターは同期されま
せん。それまでの間は、さまざまなエラーや警告が表示される可能性があります。
Windows ユーザーの場合：Windows でのマスターアップグレード時には、プロンプトは表示されません。アップ
グレードを開始すると、作業が完了するまで処理が行われ、最後にピアノードが再起動されます。
マスター停止時および再起動後の処理については、「マスターノード停止時の処理」を参照してください。
ピアノードのアップグレード
ピアノードのアップグレード時には、以下の事項に注意してください。
ピアのアップグレードにより、実行中のサーチが中断される可能性があります。
ダウンタイムやインデックス作成/サーチの中断をを最小限に抑えるために、ピアノードは一度に 1 つずつ
アップグレードしてください。
アップグレード前にピアを停止するには、offline コマンドを使用します。「ピアをオフラインにする」を
参照してください。十分なアップグレード期間を確保するために、restart_timeout 属性を編集して、再起
動時間を長くしなければならないこともあります。詳細は、適切なトピックを参照してください。
マスターのアップグレード時から、ピアのアップグレードの完了時までの間、クラスタにはさまざまな警告
やエラーが発生する可能性があります。　67
サーチヘッドのアップグレード
サーチヘッドアップグレード時のクラスタへの影響は、その作業中にサーチ中断の可能性があることのみです。
5.0.1 以前からのアップグレ ー ド
5.0.2 のアップグレード時に、$SPLUNK_HOME/etc/master-apps (マスター上) および $SPLUNK_HOME/etc/slave-apps
(ピア上) にある /cluster ディレクトリは、名前が /_cluster に 更されます。この処理は自動的に行われます。こ
のディレクトリの詳細は、「共通のピア設定の更新」を参照してください。
5.0.2 へのアップグレード後にマスターを再起動すると、一連のピアノードの順次再起動が実施されます。これに
より、最新バージョンの設定バンドルがピアに配布されます (名前が 更された /_cluster ディレクトリ)。
クラスタの設定
マスタ ー の設定
マスターを有効にした時点でマスターの設定を行うことができます。「マスターノードを有効にする」を参照して
ください。一般的に、マスターで必要な設定はこれだけです。
デプロイ後の設定の 実 施
さらに詳細な設定を行う場合は、以下の方法を利用できます。
Splunk 管理の [クラスタリングを有効にする] ページで 更を行う。マスターノードダッシュボードからのこ
のページの表示方法については、「マスターノードダッシュボードの表示」を参照してください。
マスターの server.conf ファイルで、[clustering] スタンザを直接編集する。詳細は、「server.conf による
クラスタコンポーネントの設定」を参照してください。一部の高度な設定は、このファイルを編集すること
によってのみ設定できます。
CLI の edit cluster-config コマンドを使用することができます。詳細は、「CLI によるクラスタの設定」
を参照してください。
警告：複製データ保持数とサーチ可能データ保持数を 更することは可能ですが、クラスタに大量のデータが保管
された後に、これらの設定を やすことはお勧めできません。そうすると、数多くのバケツアクティビティが開始
され、バケツのコピー作成中/サーチ可コピーに 換中の間、クラスタのパフォーマンスに 影響を与えてしまいま
す。
Splunk サポートからの指示がない限り、heartbeat_timeout はデフォルト値の 60 (秒) から 更しないでください。
特に、この値を減らしてはいけません。ピアが過負荷状態になる危険性があります。
マスター設定の 更後は、 更内容を反映するためにマスターを再起動する必要があります。
重要：マスターには、他のクラスタコンポーネントを管理する機能のみがあります。これを外部データのインデッ
クス作成やクラスタのサーチに利用することはできません。
スタンバイマスタ ー の設定
現在マスターのフェイルオーバー機能はありませんが、プライマリマスターが何らかの理由で停止した場合に即座
に立ち上げることができる、スタンバイマスターを設定してマスター障害に備えることができます。
スタンバイマスターを準備する際には、マスターの静的状態しかバックアップする必要はありません。すべてのク
ラスタコピーの状態などのクラスタに関する動的情報は、すべてクラスタピアのグループが保持します。ピアはこ
の情報を必要に じてマスターノードとやり取りします (例：マスターがクラスタに復 した場合、または停止したマ
スターをスタンバイマスターが引き いだ場合)。マスターはその情報を使って、クラスタの状態マップを再構築し
ます。
2 種類の個別の静的設定をバックアップする必要があります。
マスタークラスタの設定が保管されている、マスターの server.conf ファイル。マスターのクラスタ設定を
更した時は常にこのファイルをスタンバイマスターにコピーする必要があります。
「共通のピア設定の更新」で 明しているように、共通のピア設定が保管されている、マスターの
$SPLUNK_HOME/etc/master-apps ディレクトリ。ピアノードに配布するコンテンツを更新した時には常に、こ
のディレクトリをスタンバイマスターにコピーする必要があります。
68
ピアノードとサーチヘッドがスタンバイインスタンスを探してそれをマスターとして認識するために、スタンバイ
マスターはプライマリマスターと同じ IP アドレスと管理ポートを使用する必要があります。管理ポートはインス
トール時に設定されますが、後ほど web.conf を編集して 更することができます。スタンバイマスターが同じ IP
アドレスを使用するように、DNS ベースのフェイルオーバー、ロード バランサー、またはその他のテクニックを
採用する必要があります。
2 種類の静的設定をバックアップし、IP アドレスと管理ポートを正しく設定しておけば、停止したプライマリマス
ターからスタンバイマスターへの置換作業は簡単です。CLI の splunk start コマンドを使ってスタンバイマス
ターを起動するだけです。
ピアノ ー ドの設定
重要：このトピックをご覧になる前に、Splunk で設定ファイルがどのように機能するのかを理解しておく必要が
あります。『管理マニュアル』の「設定ファイルについて」およびそれに続くトピックを参照してください。
ピア設定作業の大半は、クラスタの初期デプロイ時に行われます。
1. ピアを有効にする際に、マスターおよび複製されたデータを受信するポートを指定します。「ピアノードを有効
にする」を参照してください。
2. 一連のピアセットを有効にしたら、必要に じてインデックスを設定します。「ピアインデックスの設定」を参
照してください。
3. 最後に、入力を設定します。通常は、フォワーダーを使用します。「フォワーダーを使ったデータの取り込み」
を参照してください。
これがピア設定の主要ステップです。ただし、後ほどピアの初期設定を 更しなければならないこともあります。
たとえば、イベント処理を設定するために、props.conf および transforms.conf を編集する必要があります。App
をピアに配布しなければならないこともあります。ここでは、展開後のピア設定の更新方法について 明していき
ます。
ベストプラクティスとして、ピアは交換可能なものとして取り扱う必要があります。そのためには、大部分の設定
ファイルを同じバージョンで、すべてのピアに して適用する必要があります。クラスタが正常にデータを複製し
て、ノードのフェイルオーバーを実施できるように、ピアは同じインデックス機能を共有する必要があります。ピ
ア間で一部の主要ファイルが異なっている場合、正常に処理を行うことができません。特に、一部の極めて限定さ
れた例外を除いて、indexes.conf 内の一連のインデックス関連スタンザは、すべてのピア間で同一でなければな
りません。また、インデックス-時間処理もすべてのピア間で同一でなければなりません。
ここでは、一連のピアでの同一の設定の維持管理方法について 明していきます。また、必要に じて行うピア単位
の設定方法についても 明しています。
すべてのピアの共通設定の管理
できる限り、クラスタ内のすべてのピアで共通の設定ファイルセットを使用するようにしてください。特に
indexes.conf はすべてのピアノードで同じでなければなりません。ピアは、同じクラスタ化インデックスセット
を共有する必要があります。すべてのピアにまたがって、同じ props.conf および transforms.conf ファイルを使
用することもお勧めします。これらの 3 つの主要ファイルだけでなく、その他の設定ファイルも同じバージョンを
すべてのピアで使用することにより、クラスタの管理を大幅に簡素化することができます。
App には同じバージョンの設定ファイルが含まれていることが多いため、たいていの場合は単一のピアに別個に
App をインストールするのではなく、クラスタ内のすべてのピアに App も配布する必要があります。詳細は、こ
のトピックの後半にある「すべてのピアへの App の配布方法」を参照してください。
重要：スタンドアロンのインデクサーの設定管理と比べて、共通のピア設定ファイルを管理する際にはいくつかの
重要な違いがあることを理解しておく必要があります。
クラスタ単位で管理する必要がある設定の 更を、個別のピアで行わないでください。たとえば、Splunk 管
理や CLI を使ってインデックス設定を行わないでください。
ピア上で、indexes.conf などのクラスタ全体の設定ファイルを直接編集しないでください。代わりにマス
ター上のファイルを編集し、それをこのトピックの後半に記載している設定バンドルを使用して配布してく
ださい。詳細は、「共通のピア設定の更新」を参照してください。こうすることによってのみ、すべてのピ
アが同じバージョンのファイルを使用することが保証されます。
すべてのピアノードに共通の設定ファイルを管理する際に、デプロイサーバーは使用しないでください。代
わりに、設定バンドルを使用します。
す べ て の ピ ア に す る indexes.conf の 設 定
69
データを複製するには、indexes.conf ファイルに定義されている一連のクラスタ化インデックスの設定を、クラ
スタ内のすべてのピアで同一にする必要があります。このファイルの設定方法については、「ピアインデックスの
設定」を参照してください。
注意：はは限定された環境下 (たとえば、ローカルテストまたは監視を実行) では、インデックスを 1 台のピアに
のみ追加し、他のピアには追加したくないような場合があります。インデックスの設定を注意深く行い、その結果
や 影響について十分に理解している場合にのみ、ピア固有の indexes.conf を作成し、それを適用するようにして
ください。そのようなインデックス内のデータは複製されません。ピア固有の indexes.conf が補足的に使用され
ますが、すべてのピアが使用する共通バージョンの設定に代わることはありません。必要に じて同 の方法で、ピ
ア固有の App を管理することができます。詳細は、後述の「単一ピアへのインデックスの追加」を参照してくだ
さい。
更新した設定のすべてのピアへの配布方法
新しいまたは編集した設定ファイルをすべてのピアに配布するには、まずマスター上の特別な場所にファイルを保
管します。次に、マスターにその場所にあるファイルをピアノードに配布するように指示します。すべてのピアに
共通の一連の設定ファイルセットは、設定バンドルと呼ばれています。設定バンドルはマスター上で管理され、単
一の操作でピアに配布できます。
この配布方法は、indexes.conf、props.conf、および transforms.conf に限定されるものではありません。同じ方
法を利用して、任意の同一の設定ファイルをすべてのピアに配布することができます。たとえば、すべてのピアが
単一のデータ入力セットを共有できる場合、この方法を使って共通の inputs.conf ファイルをすべてのピアに配布
することができます。
すべてのピアに設定を配布する方法の詳細は、「共通のピア設定の更新」を参照してください。
注意：別の配布方法を使って更新を配布することも可能ですが、お勧めすることはできません。設定バンドルを利
用して更新を配布する場合、マスターが配布を担当して、すべてのピアが同じクラスタ化インデックスセットも含
む一連の設定を使用するように設定します。他の配布方法を使用する場合は、新しいインデックスにデータの送信
を開始する前に、新たにクラスタ化されたインデックスの設定がすべてのピアに正常に配布されたこと、およびす
べてのピアが再起動されたことを確認する必要があります。
す べ て の ピ ア へ の App の 配 布 方 法
すべてのピアに App を配布するには、各設定ファイルを配布する場合と同じように、まずマスター上の特別な場
所に App を保管します。App は設定バンドルの一部となります。準備が完了したら、設定バンドル全体をピア
ノードに配布するように、マスターノードに指示します。
重要：App を配布する前に、その indexes.conf ファイルを調査してください。App 固有の indexes.conf ファイ
ルに定義されている各インデックスに して、インデックスが各クラスタピアに複製されるよう
に、repFactor=auto を明示的に設定する必要があります。詳細は、「indexes.conf の repFactor 属性」を参照して
ください。
App の準備とすべてのピアへの配布方法については、「共通のピア設定の更新」を参照してください。
重要：クラスタ App は、非クラスタ App と比べて一定の制限事項があります。詳細は、「クラスタ App の制限事
項」を参照してください。
ピア 単 位での設定の管理
一部の設定をピア単位で管理しなければならないこともあります。それでも、たいていの場合は、ピアを相互交換
できるようにすべてのピアで同じ設定を使用することをお勧めします。
デ ー タ の 取 り 込 み (デ ー タ 入 力 ) の 設 定
ピアにデータを取り込むには、フォワーダーを使用することをお勧めします。詳細は、「フォワーダーを使った
データの取り込み」を参照してください。
フォワーダーを利用せずにデータをピアに直接取り込みたい場合は、インデクサーに して設定する場合と同じ方
法でピアにデータの取り込み方法を設定します。詳細は、『Getting Data In Manual』の「Configure your inputs」
を参照してください。
重要：データ取り込みの設定はピア単位に行えますが、すべてのピアで同じデータ取り込み設定を使用できるかど
うかを 討するようにしてください。すべてのデータがフォワーダーにより中 されており、すべてのピアの受信
ポートが同じ場合は、そうすることが可能になります。そのような場合は、マスターノードで共通の inputs.conf
ファイルを管理できます。「共通のピア設定の更新」を参照してください。
単一ピアへのインデックスの追加
70
インデックスを単一のピアに追加する必要がある場合は、ピア上に個別の indexes.conf ファイルを作成します。
ただし、その新たなインデックスのデータはそのピアにのみ保管され、他のピアに複製されることはありません。
この方法は主にローカルでのテストやモニター目的で使用されます (当該ピアにのみダウンロードした特定の App
を利用したテストなど)。ピア固有の indexes.conf が補足的に使用されますが、すべてのピアが使用する共通バー
ジョンの設定に代わることはありません。
1 台のピアに して indexes.conf のバージョンを作成する場合、それをインデクサー内で許可されている任意の場
所に配置できます。『管理マニュアル』の「設定ファイルについて」を参照してください。このファイルを保管し
てはいけない場所の 1 つとして、$SPLUNK_HOME/etc/slave-apps が げられます。ここには、ピアの設定バンドルが
保管されています。ここにファイルを保管した場合、次回の設定バンドルのダウンロード時にそのファイルが上書
きされてしまいます。
重要：ローカルインデックスを追加した場合、その repFactor 属性はデフォルト値の 0 のまま使用してくださ
い。auto を設定しないでください。auto を設定すると、ピアはクラスタ内の他のピアへのインデックスデータの
複製を試みます。他のピアには新たなインデックスに関する設定が行われていないため、それらのピア上に複製
データの保管場所は存在せず、さまざまな問題、時には深刻な問題が発生してしまいます。また、次にマスターが
ピアへの設定バンドルの配布を試みる際に、不適切な設定のインデックスを持つピアがマスターにバンドル 証エ
ラーを返し、ピアに正しくバンドルを適用できなくなってしまいます。
その他の設定の 更
個別のピアで他の設定をピア固有の値に 更する必要がある場合、クラスタ構成かどうかにかかわらず、他の
Splunk インスタンスと同じ方法でピアを設定することができます。Splunk 管理や CLI を使ったり、直接設定ファ
イルを編集したりすることができます。
ピアの再起動
他のインデクサーと同 に、通常は設定を 更したらピアを再起動する必要があります。ただし、非クラスタ構成の
インデクサーとは異なり、ピアの再起動に CLI の splunk restart コマンドを使用することはできません。代わり
に Splunk 管理の再起動機能を使用してください。クラスタピアの再起動方法の詳細は、「クラスタピアの再起
動」を参照してください。
ピアインデックスの設定
インデックスの設定は、indexes.conf ファイルを編集することで行います。このファイルは、インデクサーの一連
のインデックス、およびバケツのサイズと属性を決定します。クラスタ内のすべてのピアが同じインデックスセッ
トを使用する必要があるため (後述する特定の目的がある場合を除く)、通常すべてのピアで indexes.conf ファイ
ルを同じにする必要があります。
注意：たいていの Splunk 設定ファイルのように、indexes.conf ファイルの複数のバージョンを用意して、それぞ
れのファイルを Splunk インスタンスの個別のディレクトリに配置することができます。設定ファイルおよび複数
バージョンの処理方法の詳細は、「設定ファイルについて」を参照してください。
クラスタピアは、基本的なクラスタのニーズを取り扱うデフォルトの indexes.conf ファイルでデプロイされま
す。インデックスを追加、またはバケツの動作を 更する場合は、マスター上の特別な場所に存在している
indexes.conf ファイルを編集して、そのファイルをすべてのピアに同時に配布します。
重要：Splunk 管理または CLI を使ってピアノードのインデックス設定を 更することはできません。indexes.conf
を直接 更する必要があります。
すべてのピアが同じ indexes.conf ファイルセットを使用する必要が
あります
通常 indexes.conf ファイルセットは、クラスタ内のすべてのピアで同一でなければなりません。特に、すべての
ピアが同じクラスタ化されたインデックスセットを使用する必要があります。これは、インデックスレプリケー
ションが正常に機能するための必須事項です。(一方、マスターノードは自己の内部データのみのインデックスを
作成するため、独自の indexes.conf ファイルを使用します。)この制限事項には、後述するように限定的な例外事
項があります。
クラスタを最初に作成する場合、マスターは各ピアにデフォルトの indexes.conf ファイルを配布します。この
バージョンの indexes.conf は、クラスタのピア向けに特別に設計されています。デフォルトの indexes.conf
は、main (デフォルト) インデックス、および_audit や _internal などの内部インデックスのレプリケーションを
オンにします。
システムによっては、追加のインデックスやバケツ属性の 更を適用するために、 更された indexes.conf のイン
デックス/バケツ属性をさらに編集して、ピアに配布しなければならないこともあります。すべてのピアが同じ
indexes.conf を使用するように、マスターノードを使ってすべてのピアに一度にファイルを配布する必要があり
71
ます。この設定バンドルを使用する方法については、「共通のピア設定の更新」を参照してください。
他の配布方法を使ってすべてのピアに indexes.conf ファイルを配布することも可能ですが、推 できるのは設定バ
ンドルを利用する方法のみで、またこの方法しかサポートされていません。この方法を利用する場合、すべてのピ
アがおなじクラスタ化インデックスセットを持つように、マスターが配布を担当します。他の配布方法を使用する
場合、新しいインデックスにデータの送信を開始する前に、新たにクラスタ化されたインデックスの設定がすべて
のピアに正常に配布されたこと、およびすべてのピアが再起動されたことを確認する必要があります。
設定バンドルを使って、すべてのピアに App を配布することもできます。これらの App には独自の indexes.conf
ファイルが含まれている場合もあります。このファイルは、App 外の他のバージョンのファイルと共存して処理が
行われていることもあり、そのような場合は他のピアにも配布する必要があります。App 配布の詳細は、「すべて
のピアへの App の配布方法」を参照してください。
注意：限定された環境下では (たとえば、ローカルテストや監視を行うために)、ピアに固有のインデックスを設定
する、ピア固有の indexes.conf を作成することもできます。ただし、そのようなインデックスは複製されませ
ん。ピア固有の indexes.conf が補足的に使用されますが、すべてのピアが使用する共通バージョンの設定に代わ
ることはありません。詳細は、「単一ピアへのインデックスの追加」を参照してください。
ピアのインデックスセットの設定
一連のピアにまたがるインデックスを設定する作業は、2 つのステップから成り立っています。
1. マスターノードの indexes.conf を編集します。「indexes.conf の編集」を参照してください。
2. マスターを使って、一連のピアにファイルを配布します。「新しい indexes.conf ファイルのピアへの配布」を
参照してください。
これらの 2 つのステップの詳細を以下に示します。
indexes.conf の編集
の設定方法の詳細は、このマニュアルの「インデックスの管理」および「インデックスストレージ
の管理」を参照してください。indexes.conf の属性の一覧については、『管理マニュアル』の indexes.conf に関
する 明を参照してください。
indexes.conf
大部分は、他の Splunk インデクサーと同 に、クラスタピアの 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>
...
ス ラ ッ シ ュ デ ィ レ ク ト リ 区 切 り 文 字 に よ る homePath と coldPath の 指 定
異種混在環境では、マスターノードの OS でディレクトリパスの指定に、ピアノードの OS とは異なる表記規則を
使用している場合があります。indexes.conf ファイルはマスターノード上で編集し、次にそれをピアに配布する
ため、このことが問題になる可能性があります。
たとえば、マスターノードで Windows、ピアで Linux を使用している場合に、通常 Windows マスターで
homePath を指定する際には、ディレクトリ区切り文字として円記号を使用します。しかし、Linux ピアに配布する
ファイルには、ディレクトリ区切り文字としてスラッシュを使用する必要があります。
この問題に 処するために、マスターやピアが使用しているオペレーティングシステムの種類に関係な
く、homePath および coldPath でディレクトリパスを指定する時には、常にスラッシュを使用することをお勧めし
ます。例：
homePath = $SPLUNK_HOME/var/lib/splunk/defaultdb/db/
Splunk は常に、スラッシュをディレクトリ区切り文字として認識します。
インデックスボリュームを使ったストレージ管理の簡素化
72
重要：このサブトピックを理解するためには、「ストレージの 討事項」に記述されている、クラスタストレージ
要件の詳細を学んでおく必要があります。
インデックスボリュームは、複数のインデックスにまたがってストレージサイズを指定するための手 な手段を提
供しています。ボリュームは他のインデックス設定と同 に、indexes.conf に指定します。インデックスボリュー
ムの詳細と指定方法については、「ボリュームによるインデックスサイズの設定」を参照してください。
このセクションに記載されている使用事例の他に、ボリュームを使ってインデックスセット全体のホット/ウォー
ムおよびコールドデータの合計サイズを指定することもできます。この方法は特にクラスタで役立ちます。クラス
タでは複製されたデータがコールドデータベースに保管され、あるピアノードに存在する元のデータと複製データ
の合計を予測することが困難です。ホット/ウォームおよびコールドデータベース全体に して単一のボリュームを
指定することにより、インデックスが各ピア上で占有する総合的なストレージ量を制御することができます。ただ
し、特定の種類のバケツの使用量は制御できません。
2 つのインデックスに して、すべてのバケツ (オリジナルと複製) の合計ストレージサイズの指定にボリュームを
使用した例を以下に示します。
[volume:cluster1]
path = /mnt/big_disk
maxVolumeDataSizeMB = 300000
[idx1]
repFactor=auto
homePath = volume:cluster1/idx1/db
coldPath = volume:cluster1/idx1/colddb
thawedPath=<path for thawed buckets>
[idx2]
repFactor=auto
homePath = volume:cluster1/idx2/db
coldPath = volume:cluster1/idx2/colddb
thawedPath=<path for thawed buckets>
この設定は indexes.conf の一部で、クラスタ内のすべてのピアで同一でなければならないため、ボリュームの
path はすべてのピアで正常に機能する手段で指定する必要があります。(すべてのピアが同じ物理ストレージを使
用する必要があるのではなく、指定するパス参照が各ピア上で適切に解釈される必要があります。)また、ボ
リュームを使って解凍パスを指定することはできません。
注意：クラスタ内のホット/ウォーム/コールドデータベースは同じパフォーマンス特性を持つ必要があるため、ク
ラスタ化ストレージでこのアプローチは適切に機能しますが、非クラスタ構成インデクサーの場合、コールドデー
タベースには低速なストレージが使われる可能性があるため、この方法の使用はお勧めできません。詳細は、「ボ
リュームによるインデックスサイズの設定」を参照してください。
新しい indexes.conf ファイルのピアへの配布
を編集したら、それをクラスタの一連のピアノードに配布する必要があります。indexes.conf を含
めた設定ファイルのすべてのピアへの配布方法については、「共通のピア設定の更新」を参照してください。
indexes.conf
App の配布も含めたその他の種類のピア設定については、「ピアノードの設定」を参照してください。
サ ー チヘッドの設定
他のクラスタコンポーネントを有効にするのと同時に、サーチヘッドも設定して、有効にする必要があります。
「サーチヘッドを有効にする」を参照してください。クラスタの一連のピアノードは、自動的にサーチヘッド
のサーチピアとして指定されます。
基本的には、有効化プロセスでデフォルトの設定を使用することができます。ただし、サーチヘッドに複数のクラ
スタにまたがったサーチを実行させたい場合は、後述するように直接 server.conf を編集する必要があります。
また、サーチヘッドプーリングやマウントされたバンドルなどの、分散サーチの高度な機能を使用したい場合は、
サーチヘッド上で distsearch.conf を編集する必要があります。詳細設定も含めたサーチヘッドの詳細は、
『Distributed Deployment Manual』の「Search across multiple indexers」を参照してください。その章は、主に
非クラスタ環境について 明していますが、クラスタ環境におけるサーチヘッドの高度な機能の設定に関する情報
も記載されています。
複 数 クラスタサ ー チの設定
複数のクラスタが存在する場合、すべてのクラスタにまたがってサーチを実行するようにサーチヘッドを設定する
ことができます。この設定を行うには、サーチヘッドの server.conf ファイルを編集して、master_uri 属性にマ
73
スターノード参照のカンマ区切りリストを指定し、その後に各マスターのスタンザを個別に指定します。例：
[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 ファイルの仕 を参照してください。server.conf を使った
クラスタの設定方法の詳細は、「server.conf によるクラスタの設定」を参照してください。
注意：この設定は、直接 server.conf に行う必要があります。Splunk 管理や CLI を使って複数クラスタサーチを
設定することはできません。
クラスタ化サ ー チヘッドと非クラスタ化サ ー チヘッドの違い
クラスタ化サーチヘッドと非クラスタ化サーチヘッドでは、大部分の設定や機能は同じです。高度な機能を利用す
るために詳細設定を行うには、distsearch.conf を編集します。
主な違いは、クラスタの場合、クラスタ有効化プロセスの一環として、サーチヘッドとサーチピアが自動的に相互
接続されることです。自動 出を有効にするために、distsearch.conf の設定を行う必要はありません。
クラスタ構成のサーチヘッドでは、他にもいくつかの属性が無効になります。特に、クラスタ構成のサーチヘッド
は、distsearch.conf 内の以下の属性を無視します。
servers
disabled_servers
heartbeatMcastAddr
heartbeatPort
heartbeatFrequency
ttl
checkTimedOutServersFrequency
removedTimedOutServers
autoAddServers
注意：非クラスタ環境のように、サーチピアへのサーチヘッドのアクセスは、公開鍵認証により管理されます。た
だし、鍵を手動で配布する必要はありません。サーチヘッドは自動的に公開鍵をサーチピアにプッシュします。
分散サ ー チの [管理 ] ペ ー ジ
Splunk 管理の分散サーチページを使ってクラスタ構成のサーチヘッドを設定することはできません。ただし、
サーチヘッド上で当該ページに移動して、すべてのサーチピアのリストを表示することができます。
マウントされたバンドルおよびサ ー チピアの設定
設定の大半は、サーチヘッドでのみ有効になります。ただし、マウントされたバンドルを導入す
るには、サーチピアにも distsearch.conf ファイルを配布する必要があります。クラスタの場合、マスターノード
を使ってピアにこのファイルを配布する必要があります。マスターノードを使ったピア設定の管理方法について
は、このマニュアルの「ピアノードの設定」を参照してください。マウントされたバンドルの設定方法について
は、『Distributed Deployment Manual』の「Mount the knowledge bundle」を参照してください。
distsearch.conf
詳細設定
server.conf によるクラスタの設定
たいていの場合は、「クラスタのデプロイ」で 明しているように、Splunk 管理からクラスタノードを有効にする
のが一番手 な方法です。Splunk 管理でノードを有効にする場合、設定はノードの
$SPLUNK_HOME/etc/system/local/ にある server.conf ファイルに保存されます。また、server.conf ファイルを直
74
接編集して、ノードを有効にしたり、クラスタ設定を 更することも可能です。
クラスタを制御する server.conf のメインスタンザは、[clustering] です。有効化を制御する基本属性や Splunk
管理で利用できる設定の他に、server.conf を利用してさまざまな高度なクラスタ設定を行うことができます。こ
れらの属性を 更するには、server.conf を直接編集する必要があります。
スタンザの他にも、クラスタは [replication_port] スタンザを使用して、ピアが複製データを待機
するポートを指定します。
[clustering]
このトピックでは、基本的なクラスタノード有効化に関する属性と、Splunk 管理における設定について取り上げ
ていきます。詳細設定も含めたすべてのクラスタ属性の詳細は、server.conf の仕 を参照してください。
クラスタノ ー ドを有 効 にする
各ノードタイプの単純なクラスタ有効化を行う、クラスタリングスタンザのサンプルを以下に示します。これらの
例に記載されている設定属性は、Splunk 管理の [クラスタリングを有効にする] ページのフィールドに していま
す。
注意：Splunk 管理でクラスタノードを設定する場合、結果となる server.conf スタンザには非デフォルト値の属
性のみが含まれます。たとえば、Splunk 管理でマスターノードを有効にする場合、複製データ保持数のデフォル
ト値 3 を使用して、新しい値を指定しない場合、スタンザに replication_factor 属性は含まれません。
マスターノード
マスターノードの基本設定例を以下に示します。
[clustering]
mode = master
replication_factor = 4
search_factor = 3
pass4SymmKey = whatever
この例では、以下の事項を指定しています。
Splunk インスタンスはクラスタマスターノード。
クラスタの複製データ保持数は 4。
クラスタのサーチ可能データ保持数は 3。
秘密鍵は「whatever」。
ピアノード
ピアノードの設定例を以下に示します。
[replication_port://9887]
[clustering]
master_uri = https://10.152.31.202:8089
mode = slave
pass4SymmKey = whatever
この例では、以下の事項を指定しています。
ピアはポート 9887 で他のピアから転送される複製データを待機。
ピアのクラスタマスターの場所は 10.152.31.202:8089。
Splunk インスタンスはクラスタピアノード。
秘密鍵は「whatever」。
サーチヘッド
サーチヘッドの設定例を以下に示します。
[clustering]
master_uri = https://10.152.31.202:8089
mode = searchhead
pass4SymmKey = whatever
この例では、以下の事項を指定しています。
ピアのサーチヘッドの場所は 10.152.31.202:8089。
Splunk インスタンスはクラスタサーチヘッド。
75
秘密鍵は「whatever」。
注意：複数クラスタサーチは、server.conf を編集して有効にすることもできます。詳細は、「複数クラスタサー
チの設定」を参照してください。
秘密鍵の設定
必要に じて pass4SymmKey を指定して、マスター、ピア、およびサーチヘッド間の認証を行うための秘密鍵を設定
することができます。あるクラスタノードにこれを設定した場合は、他のすべてのクラスタノードにも同じ値を指
定する必要があります。
鍵の使用をクラスタ機能のみに限定する場合は、[clustering] スタンザ内に鍵を指定します。[general] スタンザ
内に pass4SymmKey を指定した場合、優先設定として [clustering] にも鍵を指定しない限り、この鍵はクラスタ機
能とライセンス機能の両方で有効になります。設定スタンザ内で属性を複数回指定した場合、より固有な設定が全
般的な設定に優先されます。そこで、[general] スタンザと [clustering] スタンザに鍵を指定した場合、クラス
タ機能は [clustering] の設定を使用して、ライセンス機能は [general] の設定を使用します。
クラスタノ ー ドの再起動
Splunk インスタンスをクラスタノードとして設定したら、 更内容を有効にするためにそれらすべて (マスター、
ピア、およびサーチヘッド) を再起動する必要があります。このためには、各ノードで CLI の restart コマンドを
実行します。
$SPLUNK_HOME/bin/splunk restart
マスターを初めて起動した場合、複製データ保持数と同じ数のピアを有効にして再起動するまでは、ピアにおける
インデックス作成がマスターによりブロックされます。
'重要： 最初に Splunk インスタンスをクラスタピアノードとして有効にするためには、CLI の restart コマンドを
使用することができますが、それ以降の再起動には、このコマンドを使用しないでください。いったんインデック
スレプリケーションが開始されると、restart コマンドはレプリケーションとの互換性がありません。安全な再起
動方法など、その他の情報については、「クラスタピアの再起動」を参照してください。
警告：マスタ ー 上で複製デ ー タ保持 数 またはサ ー チ可能デ ー タ保持
数 を やさないでください
で複製データ保持数とサーチ可能データ保持数を 更することは可能ですが、クラスタに大量のデータ
が保管された後に、これらの設定を やすことはお勧めできません。そうすると、数多くのバケツアクティビティ
が開始され、バケツのコピー作成中/サーチ可コピーに 換中の間、クラスタのパフォーマンスに 影響を与えてしま
います。
server.conf
CLI を使ったクラスタの設定
Splunk CLI を使って、さまざまなクラスタアクティビティを実施することができます。以下に例を示します。
クラスタノードを有効にする
クラスタ設定の編集
クラスタ情報の表示
クラスタの管理
一部のクラスタリングコマンドは、マスターノードでのみ利用できます。それ以外のコマンドは、ピアノードでの
み利用できます。
CLI コマンドのヘルプ
CLI には、クラスタリングコマンド用にオンラインヘルプが用意されています。クラスタリングコマンドの全般的
なヘルプについては、$SPLUNKHOME/bin で以下のコマンドを入力してください。
splunk help cluster
特定のコマンドのヘルプについては、コマンド名を指定します。例：
76
splunk list cluster-config
CLI の全般情報については、『管理マニュアル』の「Splunk のコマンドラインインターフェイス (CLI)」を参照す
るか、または以下のコマンドを入力します。
splunk help
クラスタノ ー ドを有 効 にする
Splunk インスタンスをクラスタノードとして有効にするには、edit cluster-config コマンドを使用します。イ
ンスタンスを有効にしたら、それを再起動する必要があります。
マスターノードを有効にする
Splunk インスタンスをマスターノードとして有効にするには、mode に「master」を設定して、必要に じて他のク
ラスタオプションも指定します。
splunk edit cluster-config -mode master -replication_factor 4 -search_factor 3
splunk restart
重要：マスターを初めて起動した場合、すべてのピア (複製データ保持数と同じ数のピア) を有効にして再起動す
るまでは、ピアにおけるインデックス作成がマスターによりブロックされます。
ピアノードを有効にする
Splunk インスタンスをピアノードとして有効にするには、mode に「slave」を設定します。また、master_uri お
よび replication_port も指定する必要があります。
splunk edit cluster-config -mode slave -master_uri https://10.160.31.200:8089 -replication_port 9887
splunk restart
サーチヘッドを有効にする
Splunk インスタンスをサーチヘッドとして有効にするには、mode に「searchhead」を設定します。ま
た、master_uri も指定する必要があります。
splunk edit cluster-config -mode searchhead -master_uri https://10.160.31.200:8089
splunk restart
クラスタ設定の編集
ノードを有効にした後は、edit cluster-config コマンドを使って、クラスタノードの設定を 更することができま
す。設定可能な項目については、CLI のヘルプおよび server.conf 仕 ファイルを参照してください。
クラスタ情報の表示
各種クラスタ情報を返すさまざまな list コマンドが用意されています。たとえば、クラスタ内の各ピアの詳細情
報を取得するには、マスター上で以下のコマンドを実行します。
splunk list cluster-peers
クラスタ設定に関する情報を取得するには、任意のノードから以下のコマンドを実行します。
splunk list cluster-config
list
コマンドの全一覧については、CLI のクラスタリングに関するヘルプを参照してください。
クラスタの管理
CLI を使って、クラスタ上でさまざまなアクションを実行することができます。これらのアクションについては、
それぞれのトピックで 明されています。
77
ピアをオフラインにするには、offline コマンドを使用します。
共通のピア設定を更新するには、apply cluster-bundle コマンドを使用します。
すべてのクラスタピアを再起動するには、rolling-restart コマンドを使用します。
クラスタの管理
マスタ ー ダッシュボ ー ドの表示
このダッシュボードには、クラスタ全体のステータスに関する詳細情報が表示されます。ここから、マスターの各
ピアノードの情報を参照することもできます。
他のクラスタリングダッシュボードの詳細は、以下の項目を参照してください。
ピアダッシュボードの表示
サーチヘッドダッシュボードの表示
ダッシュボ ー ドへのアクセス
マスターノードのダッシュボードを表示するには：
1. マスターノード上で、Splunk Web の [管理] をクリックします。
2. [分散環境] セクションで、[クラスタリング] をクリックします。
このダッシュボードは、すでにマスターとして有効にされた Splunk インスタンス上でのみ表示できます。
ダッシュボ ー ドの表示
マスターダッシュボードには、以下のセクションが存在しています。
マスターノード詳細
クラスタの概要
ピア詳細
インデックス詳細
また、ダッシュボードの上部には [設定] ボタンがあります。このボタンをクリックして、マスターの設定を 更す
ることができます。ただし、以下の警告に注意してください。
警告：複製データ保持数とサーチ可能データ保持数を 更することは可能ですが、クラスタに大量のデータが保管
された後に、これらの設定を やすことはお勧めできません。そうすると、数多くのバケツアクティビティが開始
され、バケツのコピー作成中/サーチ可コピーに 換中の間、クラスタのパフォーマンスに 影響を与えてしまいま
す。
78
マスターノード詳細
このダッシュボードは以下の情報を提供しています。
マスター名：ピアの $SPLUNK_HOME/etc/system/local/server.conf ファイルに指定されている、マスターの
serverName。
複製データ保持数：クラスタの複製データ保持数。
サーチ可能データ保持数：クラスタのサーチ可能データ保持数。
クラスタの概要
[クラスタの概要] には、クラスタのヘルス情報が簡単にまとめられています。以下のような情報が表示されます。
クラスタがサーチ可かどうか。
サーチ可ピア数。
サーチ可インデックス数。
クラスタのヘルス状態に じて、以下のような警告メッセージが表示されることもあります。
ピアが設定されていません。
ピアが停止しています。
複製データ保持数を たしていません。
サーチ可能データ保持数を たしていません。
[クラスタの概要] に表示されている情報の詳細については、ダッシュボードの [ピア詳細] および [インデックス詳
細] セクションを参照してください。
ピア詳細
マスターダッシュボードには、各ピアに する以下の情報が表示されます。
ピア名：ピアの $SPLUNK_HOME/etc/system/local/server.conf ファイルに指定されている、ピアの
serverName。
サーチ可：ピアが現在サーチ可かどうかを表しています。
79
ステータス：ピアのステータス。ここで 明しているプロセスの詳細は、「ピアをオフラインにする」を参照
してください。可能な値：
Up
3 回のハートビートを受信しなかった場合に発生します。こ
れは一時的な状態で、ピアが長時間この状態になることはほとんどありません。
Detention：ピアのリソースに制約がある場合 (例：ディスクスペースを使い切った)、制限状態に移行
します。この状態の間、ピアは入力を受け付けません。ただし、サーチには参加します。
Restarting：enforce-counts フラグを指定せずに offline コマンドを実行すると、ピアは
ReassigningPrimaries 状態から一時的にこの状態に移行します。restart_timeout に指定されている
期間、この状態が持続します (デフォルトは 10 分)。この時間内にピアを再起動しない場合、ピアは
Down 状態に移行します。ローリング再起動中または Splunk 管理から再起動した場合にも、ピアはこの
状態に移行します。
ShuttingDown：マスターが、ピアがシャットダウン中であることを 出しました。
ReassigningPrimaries：enforce-counts フラグを指定せずに offline コマンドを実行した場合、ピア
は一時的にこの状態に移行します。
Decommissioning：offline コマンドに enforce-counts フラグを指定して実行すると、ピアはこの状態
に移行します。この状態は、すべてのバケツ修復が完了し、ピアがシャットダウンできるようになる
までの間維持されます。
GracefulShutdown：offline コマンドに enforce-counts フラグを指定して実行した場合、正常に離脱
が完了してシャットダウンした場合にこの状態に移行します。オフラインになっている間はこの状態
が 続します。
Down：ピアは離脱以外の理由でオフラインになった場合、この状態に移行します。enforce-counts フ
ラグを指定せずに offline コマンドを実行し、ピアのシャットダウンが restart_timeout に指定され
た期間 (デフォルトは 10 分) 内に行われなかった場合、またはピアがその他の理由 (例：ピアがクラッ
シュした) でオフラインになった場合にそうなります。
バケツ：ピアがコピーを保有しているバケツ数です。
Pending：マスターがピアから、連続して
任意のピアに関する詳細情報を取得するには、ピア名をクリックします。この操作により、以下に 明するピアの
ダッシュボードのマスター版が表示されます。
インデックス詳細
このセクションには、クラスタのインデックスが表示されます。各インデックスに して、以下のフィールドが表
示されます。
索引：インデックス名。内部インデックス名の先頭には、アンダースコア (_) が付けられています。
サーチ可：インデックスがサーチ可かどうか。つまり、各バケツの最低 1 つのサーチ可コピーを保有してい
るかどうかを表しています。インデックス内のバケツのサーチ可コピーが 1 つもない場合は、インデックス
はサーチ不可であると報告されます。
複製コピー数：クラスタが保有するインデックスのコピー数。各コピーは完全で、失われているバケツがな
い状態でなければなりません。クラスタの複製データ保持数よりもコピー数が少ない場合は、警告のアイコ
ンが表示されます。
サーチ可コピー数：クラスタが保有するインデックスの完全なサーチ可コピー数。クラスタのサーチ可能
データ保持数よりもコピー数が少ない場合は、警告のアイコンが表示されます。たとえば、サーチ可能デー
タ保持数が 2 の時に、2つあるはずのサーチ可コピーの 1 つが失われている場合、警告アイコンが表示され
ます。
バケツ：インデックス内のバケツ数。
サイズ：ホットバケツを除くインデックスサイズ。
インデックスのリストには、内部インデックスの _audit と _internal が含まれます。これらの内部インデックスに
は、クラスタ内のすべてのピアが生成したデータがまとめられています。ある 1 台のピアが生成したデータをサー
チする必要がある場合、ピアのホスト名でサーチすることができます。
ピアノ ー ドダッシュボ ー ドのマスタ ー ビュ ー へのアクセス
このダッシュボードには、ピアノードのステータスに関する詳細情報が表示されます。このバージョンのダッシュ
ボードには 2 ヶ所からアクセスできます。
マスターノード上：前のセクションで 明したように、マスターダッシュボードでピア名をクリックします。
当該ピアノード上：「ピアダッシュボードの表示」を参照してください。
マスターバージョンのピアダッシュボードの例を以下に示します。
80
ダッシュボードには、ピアのステータスに関する情報が表示されます。
場所：ピアの IP アドレスとポート番号。
前回ハートビート：マスターが前回にピアからハートビートを受信した時刻。
複製ポート：ピアが他のピアから複製されたデータを受信するポートです。
ステータス：ピアのステータス。ここで 明しているプロセスの詳細は、「ピアをオフラインにする」を参照
してください。可能な値：
Up
3 回のハートビートを受信しなかった場合に発生します。こ
れは一時的な状態で、ピアが長時間この状態になることはほとんどありません。
Detention：ピアのリソースに制約がある場合 (例：ディスクスペースを使い切った)、制限状態に移行
します。この状態の間、ピアは入力を受け付けません。ただし、サーチには参加します。
Restarting：enforce-counts フラグを指定せずに offline コマンドを実行すると、ピアは
ReassigningPrimaries 状態から一時的にこの状態に移行します。restart_timeout に指定されている
期間、この状態が持続します (デフォルトは 10 分)。この時間内にピアを再起動しない場合、ピアは
Down 状態に移行します。ローリング再起動中または Splunk 管理から再起動した場合にも、ピアはこの
状態に移行します。
ShuttingDown：マスターが、ピアがシャットダウン中であることを 出しました。
ReassigningPrimaries：enforce-counts フラグを指定せずに offline コマンドを実行した場合、ピア
は一時的にこの状態に移行します。
Decommissioning：offline コマンドに enforce-counts フラグを指定して実行すると、ピアはこの状態
に移行します。この状態は、すべてのバケツ修復が完了し、ピアがシャットダウンできるようになる
までの間維持されます。
GracefulShutdown：offline コマンドに enforce-counts フラグを指定して実行した場合、正常に離脱
が完了してシャットダウンした場合にこの状態に移行します。オフラインになっている間はこの状態
が 続します。
Down：ピアは離脱以外の理由でオフラインになった場合、この状態に移行します。enforce-counts フ
ラグを指定せずに offline コマンドを実行し、ピアのシャットダウンが restart_timeout に指定され
た期間 (デフォルトは 10 分) 内に行われなかった場合、またはピアがその他の理由 (例：ピアがクラッ
シュした) でオフラインになった場合にそうなります。
Pending：マスターがピアから、連続して
ピアダッシュボ ー ドの表示
このダッシュボードには、ピアノードのステータスに関する詳細情報が表示されます。このバージョンのダッシュ
ボードには 2 ヶ所からアクセスできます。
マスターノード上：詳細は、「ピアノードダッシュボードのマスタービューへのアクセス」を参照してくだ
さい。
ピアノード自体 (このトピックで 明されています)。
ピアダッシュボ ー ドへのアクセス
ピアノードのダッシュボードを表示するには：
1. ピアノード上で、Splunk Web の [管理] をクリックします。
2. [分散環境] セクションで、[クラスタリング] をクリックします。
このダッシュボードは、すでにピアとして有効にされた Splunk インスタンス上でのみ表示できます。
ダッシュボ ー ドの表示
81
ピアバージョンのダッシュボードの例を以下に示します。
ダッシュボードには、ピアのステータスに関する情報が表示されます。
マスターの場所：マスターノードの IP アドレスとポート番号。
登 み：ピアがマスターに登 されているかどうか。
複製ポート：ピアが他のピアから複製されたデータを受信するポートです。
また、ダッシュボードの上部には [設定] ボタンがあります。このボタンをクリックして、ピアの設定を 更するこ
とができます。
サ ー チヘッドダッシュボ ー ドの表示
このダッシュボードには、サーチヘッドのステータスに関する詳細情報が表示されます。
ダッシュボ ー ドへのアクセス
ダッシュボードにアクセスするには：
1. サーチヘッド上で、Splunk Web の [管理] をクリックします。
2. [分散環境] セクションで、[クラスタリング] をクリックします。
このダッシュボードは、クラスタのサーチヘッドとして有効にされた Splunk インスタンス上でのみ表示できま
す。
ダッシュボ ー ドの表示
サーチヘッドダッシュボードの例を以下に示します。
ダッシュボードには、サーチヘッドのステータスに関する情報が表示されます。
マスターの場所：マスターノードの IP アドレスとポート番号。
世代 ID：現在の世代 ID。サーチヘッドおよびピアノードはこの情報を使って、サーチするバケツのコピーを
判断します。世代の詳細は、「世代」を参照してください。
世代ピア：現在の世代のサーチピアセットです。ここでピアは、GUID で識別されます。GUID は各ピアの
$SPLUNK_HOME/etc/instance.cfg ファイルに指定されています。
サーチヘッドを再設定するには、ダッシュボードの上部にある [設定] ボタンをクリックします。
サ ー チピア上の情報の表示
サーチヘッドの Splunk 管理の [分散サーチ] ページから、サーチピア (クラスタリングでは、一連のピアノードと
82
同じ) の情報を表示することもできます。
1. サーチヘッド上で、Splunk Web の [管理] をクリックします。
2. [デプロイ] セクションで、[分散サーチ] をクリックします。
3. [サーチピア] をクリックすると、一連のサーチピアが表示されます。
警告： サーチヘッド設定の 更やピアの追加に、Splunk 管理の [分散サーチ] ページを使用しないでください。ク
ラスタ化されたサーチヘッドを正しく設定する方法については、「サーチヘッドの設定」を参照してください。
ピアをオフラインにする
ピアをオフラインにするには、offline コマンドを使用します。
ニーズに じてピアを永久にオフラインにすることも、一時的にオフラインにすることも可能です。どちらの場合
でも、クラスタは有効または完了状態に復 するためのアクションを行います。
有効なクラスタは、そのバケツのすべてのサーチ可コピーを保有しており、データセット全体に してサーチ
リクエストを処理できます。
完全クラスタには、そのすべてのバケツのコピーが複製データ保持数の値だけ存在しており、またサーチ可
能データ保持数の値だけのサーチ可コピーを保有しています。そのため、障害 策の点で指定された要件を た
しています。
一時的にピアをオフラインにする場合
ピアを一時的にオフラインにする場合、一般的にはアップグレードやその他のメンテナンス作業のために短時間だ
けオフラインにします。データの処理とサーチの実行を中断することなくなく処理したいですが、ピアが短時間だ
けオフラインになる場合は、クラスタが複製データ保持数とサーチ可能データ保持数を たさない状態となっても
我慢することができます。
ピアが一時的にオフラインになると、マスターはそれを有効な状態に すためのプロセスを開始しますが、ピアが
オンラインになるとクラスタはその完全な状態に復 するため、完全な状態への復元は試みられません。
永久的にピアをオフラインにする場合
ピアを永久にオフラインにする場合、それで中断することなくクラスタが引き続きデータを処理してサーチを実行
するようにしたいと思うでしょう。また、ピアのオフラインにより失われるバケツのコピーを、他のピアに引き
がせたいと考えることもあります。たとえば、オフラインにするピアが 10 個のバケツのコピーを保持している場
合 (3 つのサーチ可および 7 つのサーチ不可)、クラスタは複製データ保持数とサーチ可能データ保持数を たすため
に、それらのコピーをクラスタ内の他のピア上に再作成する必要があります。
ピアを永久にオフラインにする場合、マスターはクラスタを有効で完全な状態に すために、さまざまなバケツ修
復プロセスを開始します。
offline コマンド
CLI の offline コマンドは、一時および永久の両方の種類のピアシャットダウンに しています。これは処理中の
サーチを完了しながら、素早く有効な状態に せるように、ピアを段階的に停止していきます。このようにして、
既存のサーチや今後のサーチが中断されることを防止します。offline コマンドは、クラスタを完全な状態に すた
めのバケツ修復作業も開始します。コマンドの実行方法に じて、プロセスは即座に開始されるか、またはピアが
オンラインに復 した場合にバケツの修復が不要になるように、一定期間の 過後に開始されます。
重要： offline コマンドが意図通りに動作するためには、サーチ可能データ保持数は最低 2 以上でなければなりま
せん。理由を以下に示します。サーチ可能データ保持数が 2 の場合、常にデータのサーチ可コピーの予備が存在し
ています。サーチ可データを持つピアがオフラインになった場合、そのデータの予備のコピーに即座に切り替えら
れて新たなサーチが行われます。これにより、クラスタ上でサーチが不可能な時間を最小限に抑えられます。一
方、サーチ可能データ保持数が 1 の場合、サーチ可コピーが利用できなくなると、まずサーチ不可コピーをサーチ
可にしないと、完全なデータセットに してサーチを行うことはできません。「ピア離脱時のクラスタ復旧時間の
見積もり」で 明しているように、この処理には時間がかかってしまいます。
offline
コマンドには 2 種類のバージョンがあります。
splunk offline：高速版の offline
コマンドで、ピアを一時的にオフラインにする目的で使用されます。ピ
アはサーチ実行中の場合でも、最大で 5 10 分後に停止します。このバージョンのコマンドを利用すれば、バ
ケツ修復活動を開始せずに手 にピアを停止させられます。また、ピアを素早く永久的に停止させて、停止後
にバケツ修復活動を行う場合にも、このバージョンのコマンドを使用します。
83
splunk offline --enforce-counts：enforce-counts
バージョンのコマンドで、クラスタが完全状態に った
後にのみピアを永久的にオフラインにする場合に使用します。enforce-counts フラグを使用すると、すべて
のサーチおよび修復アクティビティが完了するまでの間、ピアはシャットダウンされません。
重要：ピアを停止する場合、stop コマンドではなく offline コマンドを使用します。offline コマンドは、サーチ
の中断を最小限に抑えるような方法でピアを停止します。
ピアの一時停止：高速な offline コマンド
高速版の offline コマンドの構文を以下に示します。
splunk offline
このコマンドは直接ピア上から実行します。
このコマンドを実行すると、クラスタを有効な状態に すために必要な処理をマスターが手配した後にピアが
シャットダウンされます。最大で 5 10 分ほどかかります。シャットダウンされるまでの間、ピアは 続中のサーチ
を処理します。
ピアのシャットダウン後、ピアのメンテナンス作業を行ってピアをオンラインに すまでに 10 分間 (デフォルト) の
余裕があります。この時間内にピアがクラスタに復 しなかった場合、マスターはクラスタを完全状態に すための
バケツ修復作業を開始します。もっと多くの時間が必要な場合は、restart_timeout 属性を編集して、マスターが
ピアを待機する時間を延長することができます。「再起動時間の延長」を参照してください。
ピアのオフライン時に行われるプロセスの詳細は、「ピアノード停止時の処理」を参照してください。
再起動期間の延長
ピア上のメンテナンス作業を行う必要があるけれども、マスターの restart_timeout に設定されている期間 (デ
フォルトは 600 秒 (10 分)) では足りないような場合、この設定値を 更することができます。マスター上で以下の
CLI コマンドを実行してください。
splunk edit cluster-config -restart_timeout <seconds>
たとえば、以下のコマンドはタイムアウト期間を 900 秒 (15 分) に設定します。
splunk edit cluster-config -restart_timeout 900
このコマンドはその場で実行できます。実行後にマスターを再起動する必要はありません。
また、マスター上の server.conf でこの値を 更することもできます。
ピアの永久停止： enforce-counts を指定した offline コマンド
enforce-counts 版の offline コマンドの構文を以下に示します。
splunk offline --enforce-counts
このコマンドは直接ピア上から実行します。
このバージョンのコマンドは、離脱プロセスを開始します。このプロセス中、マスターはさまざまな復旧処理を指
示します。これらの処理が完了し、クラスタが完全状態に るまでの間、ピアはシャットダウンされません。当該
ピアが大量のバケツコピーを保有している場合、この処理にはかなりの時間がかかることがあります。
完全状態に復 するまでにかかる時間は、ピアが保持するデータの量と種類によって異なります。詳細は、「ピア
離脱時のクラスタ復旧時間の見積もり」を参照してください。
注意：クラスタが完全状態に復 できない場合、ピアはシャットダウンされません。一般的には、クラスタ内のピ
アの台数が、複製データ保持数を下回った場合にそのような状況が発生します。たとえば、クラスタの複製データ
保持数が 3 で、ピアノードが 3 台の場合、いずれかのノードをオフラインにしようとすると、クラスタが完全状
態に復 することはできません。このような状況下でピアをオフラインにする必要がある場合は、高速版の offline
コマンドを使用してください。
離脱処理中、ピアは 続中のサーチを引き続き処理します。
後ほどピアを再起動すると、それがクラスタに追加されます。
ピアの離脱時に行われるプロセスの詳細は、「ピアノード停止時の処理」を参照してください。
84
ピア離脱時のクラスタ復旧時間の見積もり
ピアの離脱時、マスターは残りのピアに して、バケツを修復してクラスタを完全状態に すための作業を指示しま
す。たとえば、離脱ピアが 10 個のバケツのコピーを保管しており、その中の 5 つがサーチ可だった場合、マス
ターはピアに以下の作業を指示します。
これらの 10 個のバケツを他のピアにコピーし、クラスタ内でバケツのコピー数が完全に維持されるように
します (複製データ保持数と一致)。
5 つのサーチ不可バケツのコピーをサーチ可にして、サーチ可バケツのコピー数が完全に維持されるように
します (サーチ可能データ保持数と一致)。
このアクティビティが完了するまでには、ある程度の時間がかかります。どのくらいの時間がかかるかは、以下の
ようなさまざまな要素によって異なります。
CPU、ストレージタイプ、接続タイプなどのシステム要因。
サーチ可バケツの作成作業を割り当てられたピアが現在実行している、その他のインデックス作成作業量。
離脱ピアが保持していたバケツのサイズと数。
離脱ピアに保管されていた、サーチ可コピー上のインデックスファイルサイズ。(これらのインデックスファ
イルは、セグメント化の量などの要因によって、raw データと比べてサイズが大幅に異なります。)
これらのさまざまな要因が影響しますが、処理にかかる概算時間を見積もることは可能です。Splunk が基準とし
ているハードウェアを使用していることを前提に、2 つの主要処理にかかる概算時間の算出方法について 明してい
きます。
10 GB のサーチ不可バケツコピーを LAN 由で他のピアにに転送するには、およそ 5 10 分ほどかかります。
10 GB のバケツをサーチ不可からサーチ可に 換するには、作成されるインデックスファイルのサイズによっ
て、30分 数時間ほどかかります。
共通のピア設定と App の更新
このトピックに記述されているピア更新プロセスにより、すべてのピアノードが共通の主要設定ファイルを共有す
ることが保証されます。ピアノードに App も含めた共通のファイルを配布、更新するには、この方法を使用する
必要があります。
注意：ピアノード設定の問題については、「ピアノードの設定」を参照してください。このトピックには、すべて
のピアで同一でなければならないファイルの詳細が記載されています。大部分の状況下で同一でなければならない
主要設定ファイルには、indexes.conf、props.conf、および transforms.conf があります。ご利用のシステムの
ニーズによっては、他の設定ファイルも同じでなければならない場合もあります。通常 App にはそのような主要
ファイルの別バージョンが含まれているため、一般的にはすべてのピアに して共通の App セットを維持管理する
必要があります。
新しいまたは編集した設定ファイルや App をすべてのピアに配布するには、まずマスター上の特別な場所にファ
イルを保管します。次に、マスターにその場所にあるファイルをピアに配布するように指示します。すべてのピア
に共通の一連の設定ファイル/App は、設定バンドルと呼ばれています。設定バンドルはマスター上で管理され、
単一の操作でピアに配布できます。
設定バンドルの構造
新しいまたは 更した設定バンドルファイルは、マスターノード上の特別な場所に保管します。次に、設定バンド
ルを各ピアノードの特定の橋予に配布するように、マスターに指示を行います。
マスター上
マスター上で、設定バンドルは $SPLUNK_HOME/etc/master-apps ディレクトリに存在しています。このディレクト
リ下の一連のファイルが設定バンドルを構成しています。これらは常にグループとしてすべてのピアに配布されま
す。ディレクトリの構造を以下に示します。
$SPLUNK_HOME/etc/master-apps
/_cluster
/default
/local
/<app-name>
/<app-name>
...
以下の事項に注意してください。
/_cluster
ディレクトリは特別なディレクトリで、すべてのピアに配布する必要がある設定ファイル用の
85
ディレクトリです。
サブディレクトリには、indexes.conf のデフォルトバージョンが保管されていま
す。このディレクトリには何もファイルを追加しないでください。また、このディレクトリ内のファ
イルは編集しないでください。
/_cluster/local サブディレクトリには、ピアに配布する新しいまたは編集した設定ファイルを配置で
きます。
注意：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/default
最新の設定バンドルをピアに配布する場合は、マスターにその旨を明示的に指示します。また、ピアがマスターに
登 されると (たとえば、初期スタートアップ時に)、マスターはそのピアに最新の設定バンドルを配布します。
重要：マスターがピアにバンドルを配布する場合、バンドル全体が配布されるため、以前にピアに配布された設定
バンドルの内容はすべて上書きされます。
注意：場所 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 の制限事項
設定バンドルの一部としてピアに配布する App には、/etc/apps ディレクトリに配布する App と比べて一定の制
限事項があります。
クラスタ App は、データパイプラインの以下のフェーズの設定をサポートしています。
データ入力
パーシング
インデックス作成
クラスタ App は、以下の設定とコンポーネントをサポートしていません。
サーチフェーズの設定
86
Splunk Web コンポーネント (たとえば、Splunk Web 由でこれらの App にアクセスできません)
注意：マスターは、サーチ設定や Splunk Web コンポーネントを含む、app ディレクトリ内のすべてのコンテンツ
を配布します。ピアノードは、これらの設定とコンポーネントに単にアクセスできないだけです。
データパイプラインの各フェーズおよび各フェーズに関連する設定ファイルと属性の詳細は、「設定パラメータと
データパイプライン」を参照してください。
設定バンドルの配布
新たなまたは 更した設定ファイルと App をすべてのピアに配布するには、以下の手順に従ってください。
1. ファイルや App を用意して、それらをテストします。
2. マスターノードの設定バンドルに、ファイルと App を移動します。
3. マスターに、設定バンドルをピアに適用するように指示します。
マスターノードはバンドル全体をピアに配布します。このとき、ピアの現在のバンドルの内容が上書きされます。
1. 設 定 バ ン ド ル の フ ァ イ ル と App の 準 備
ピアに配布するファイルに、必要な 更を行います。一連のピアに配布する前にスタンドアロンの Splunk インスタ
ンス上でファイルのテストを行って、正しく機能することを確認することをお勧めします。ピアノードのダウンタ
イムを最低限に抑えるために、次のステップに進む前に必要なすべてのファイルが正常に機能することを確認して
ください。
ファイルの正しい設定方法については、「ピアノードの設定」および「ピアインデックスの設定」を参照してくだ
さい。
重要：設定バンドルのサブディレクトリに新しいインデックスを定義する 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. バ ン ド ル の ピ ア へ の 適 用
ピアに設定バンドルを適用するには、マスター上で以下の CLI コマンドを実行します。
splunk apply cluster-bundle
以下の警告メッセージが表示されます。
Warning: This command will automatically restart all peers. Do you wish to continue? [y/n]:
続行するには、y を入力します。コマンドに --answer-yes フラグを指定して、このメッセージの表示を省略する
ことができます。
splunk apply cluster-bundle --answer-yes
コマンドを使用すると、マスターが新しい設定バンドルをピアに配布します。ピアはバン
ドルを個別に 証します。「バンドルの 証」とは、ピアがバンドル内のすべての indexes.conf ファイルの設定を
証することです。すべてのピアが正常にバンドルの 証を完了したら、マスターはバンドルを反映するために、ピ
アノードの順次再起動 (ローリング再起動) を指示します。
apply cluster-bundle
一般的にこのダウンロードと 証プロセスは、数秒ほどで完了します。バンドルの 証に失敗したピアがある場合、
そのピアはマスターにメッセージを送信します。マスターの Splunk 管理の [クラスタリング] ページにはエラーが
表示されます。すべてのピアのバンドルの 証が正常に完了しない限り、次のフェーズであるピアの再起動は行わ
れません。
証が完了したら、マスターはすべてのピアの順次再起動を開始します。マスターは、一度に約 10 % のピアノード
87
に再起動メッセージを発行します (クラスタ内に 10 台未 のピアが存在している場合は、一度に 1 台のピア)。これ
らのピアが再起動され、マスターとの通信が回復すると、別の 10 % のピアに再起動メッセージが発行されます。
このような処理が、すべてのピアが再起動されるまで繰り返されます。この方法により、ロードバランシングフォ
ワーダーが送信するデータを受信するピアが常に存在することになります。
ピアが再起動されると、新しい設定バンドルが使用されます。このバンドルは、ローカルの
$SPLUNK_HOME/etc/slave-apps に保管されています。
重要：ファイルは $SPLUNK_HOME/etc/slave-apps から移動しないでください。
バンドル更新プロセスのステータスの表示
クラスタバンドル更新の進捗状況を表示するには、マスターから以下のコマンドを実行します。
splunk show cluster-bundle-status
このコマンドは、バンドルの 証が正常に完了したか、または失敗したかを表示します。また、各ピアの再起動ス
テータスも表示します。
ピア起動時のバンドルの配布
最初に Splunk インスタンスをピアノードとして設定した後は、ピアをクラスタに参加させるために手動で再起動
する必要があります。「ピアノードを有効にする」を参照してください。再起動時にピアはマスターと接続し、現
在の設定バンドルをダウンロードして、ローカルでバンドルを 証した後、もう一度再起動を行います。バンドル
の 証が正常に完了した場合にのみ、ピアはクラスタに参加します。このプロセスは、オフラインのピアがオンラ
インになった場合にも行われます。
証が失敗した場合は、エラーを修正した後に、マスターから splunk apply cluster-bundle を実行する必要があ
ります。
クラスタ全 体 または 1 台のクラスタノ ー ドの再起
動
通常は、クラスタ全体を再起動する必要はありません。マスターの設定を 更した場合は、単にマスターを再起動
します。「マスターの設定」を参照してください。一連の共通ピア設定を更新した場合は、一連のピアを再起動し
ます。「共通のピア設定の更新」を参照してください。
クラスタ全 体 の再起動
何らかの理由で、マスターとピアノードの両方を再起動しなければならない場合は、以下の手順に従ってくださ
い。
1. 通常の Splunk インスタンスの再起動と同 に、マスターノードを再起動します。たとえば、マスター上で以下の
CLI コマンドを実行します。
splunk restart
2. マスターの再起動が完了したら、すべてのピアがマスターに再登 するまで待機します。マスターダッシュボー
ドには、すべてのピアとインデックスがサーチ可であることを知らせるメッセージが表示されます。「マスター
ダッシュボードを有効にする」を参照してください。
3. ピアをグループとして再起動します。マスター上で以下の CLI コマンドを実行してください。
splunk rolling-restart cluster-peers
サーチヘッドを再起動する必要がある場合は、残りのクラスタが動作している限り、任意の時点で再起動すること
ができます。
単 一ピアの再起動
単一のピアでのみ設定ファイルを 更した場合など、1 台のピアのみを再起動しなければならないこともあります。
重要：ピアの再起動に CLI の splunk restart コマンドは使用しないでください。restart コマンドを使用する
と、マスターはそのピアが再起動中であることを認識できません。代わりに、ピアのハートビート送信を待つデ
88
フォルトの 60 秒 過後に、マスターは通常のピア停止時と同じように復旧作業を開始してしまいます (バケツコ
ピーの他のピアへの追加など)。(マスターの実際の待機時間は、マスターの heartbeat_timeout 属性の設定により
異なります。専門家からの指示がない限り、デフォルト値の 60 秒を 更することはお勧めできません。)
単一ピアを安全に再起動するために、2 種類の方法が用意されています。
Splunk 管理を使用する ([管理] > [サーバーコントロール])。
CLI コマンド splunk offline に splunk start を指定する。
Splunk 管理または offline/start コマンドを使ってピアを再起動する場合、マスターはピアが永久に停止したと
判断する前に 10 分間 (デフォルト) 待機します。これはピアがオンラインに復 するために十分な時間で、クラスタ
による不要な復旧処理の実行を防止することができます。この 10 分間の待機は、Splunk 管理からまたは
offline/start コマンドを使ってピアを再起動した場合にのみ行われます。
注意：マスターが実際に待機する時間は、server.conf 内の restart_timeout 属性の値によって決まります。この
属性のデフォルト値は 600 秒 (10 分) です。マスターにより長い時間待機させたい場合は、「再起動期間の延長」
の 明に従って restart_timeout の値を 更してください。
offline/start
を使った再起動には、Splunk 管理を使った再起動と比べて、処理中のサーチが完了するまで待って
からピアを停止すると言う利点があります。また、これは 2 段階に分けて行われる処理のため、何らかのメンテナ
ンス作業を行う目的でピアを短時間停止させたいような場合にも利用できます。この方法の短所は、Splunk 管理
がピア上の任意のバケツのコピーから優先度を他のピアのサーチ可コピーに割り当て直してしまうことです。これ
により、サーチ負荷が不均等になり、ピアが大量のプライマリバケツコピーを保持していると問題が発生する可能
性があります。
offline
コマンドの詳細は、「ピアをオフラインにする」を参照してください。
クラスタの仕組み
高度なユ ー ザ ー 向けの基本 概 念
クラスタの機能を理解するためには、いくつかの概念に慣れ親しんでおく必要があります。
複製データ保持数：クラスタが保持するデータのコピー数を示します。これはクラスタの回復力 (複数の
ノード障害に 処できる能力) を示しています。
サーチ可能データ保持数：クラスタが保持するサーチ可のデータコピー数を示します。クラスタのノード停
止からの復旧速度に影響します。
バケツ：インデックス用の基本ストレージコンテナです。インデクサーのデータベース内のサブディレクト
リに しています。
クラスタの状態：これらの状態は、クラスタの健全性 (ヘルス) に関する情報を表しています。
これらの概念の概要は、クラスタのアーキテクチャを紹介している「基本的なクラスタアーキテクチャ」を参照し
てください。今ご覧の章にある各トピックに、詳細が記載されています。
複製デ ー タ保持 数
クラスタ設定の一環として、クラスタに保持するデータのコピー数を指定します。データはバケツに分割されてお
り、クラスタは各バケツの複数のコピーを管理しています。バケツの各コピーは、個別のピアノードに保管されま
す。データ/バケツのコピー数は、クラスタの複製データ保持数と呼ばれています。
クラスタは、「複製データ保持数 - 1」台のピアノード障害に 処することができます。たとえば、システムで 2 台
のピアの障害発生に 処できるようにするためには、複製データ保持数に 3 を設定する必要があります。この場
合、クラスタは 3 つの同一の各バケツのコピーを、別個のノードに保管します。複製データ保持数に 3 を設定し
た場合、クラスタの障害発生ピアノード数が 2 台までならば、すべてのデータを引き続き利用することができま
す。2 台のノードが停止しても、引き続き残りのピアにある 1 つの完全なデータコピーを利用できます。
複製データ保持数を やすことで、より多くの台数のピアノード障害に 処することができます。複製データ保持数
が 2 の場合、1 台のノード障害に する耐性しかありません。3 の場合は、2 台のピアノードの同時障害に 処できま
す (以降同 )。
このトレードオフは、値を やすとそれだけ多くのデータコピーを保管、処理しなければならないことです。複製
活動自体はさほど処理能力を消費しませんが、複製データ保持数が 加するに連れて、より多くのインデクサーを
稼働させる必要があり、またインデックスデータに するストレージもより多く確保する必要があります。一方、
データ複製自体にはさほど処理能力を必要としないため、クラスタ内に複数のインデクサーを配置する利点を活用
して、より多くのデータを取り込んでインデックスを作成することができます。クラスタ内の各インデクサーは、
オリジナルデータを持つインデクサー (ソースピア) および複製ターゲット (ターゲットピア) の両方として機能で
89
きます。これは、到着したデータのインデックスを作成でき、またクラスタ内の他のインデクサーからのデータコ
ピーを保管することも可能です。
以下の図では、1 台のピアがフォワーダーからデータを受信して処理し、それを他の 2 台のピアに転送していま
す。クラスタには、そのピアのデータの 3 つの完全なコピーが、各ピアに 1 つずつ保管されます。
注意：この図では、すべてのデータが単一のピアを通じてシステムに取り込まれるように、ピア複製を大幅に簡素
化して表しています。実際には複 性が すいくつかの問題が存在しています。
大部分のクラスタでは、各ピアノードがソースピアとターゲットピアの両方として動作し、どちらもフォ
ワーダーから外部データを、そして他のピアから複製されたデータを受信しています。
水平方向のスケーリングを確保するために、複製データ保持数が 3 のクラスタを 4 台以上のピアで構成する
ことができます。各ソースピアは任意の時点でそのデータのコピーを 2 台のターゲットピアに転送します
が、新しいホットバケツの開始時には 回、そのターゲットピアが 化する可能性があります。
この章の後半のトピックでは、クラスタによるデータの処理方法が詳細に 明されています。
サ ー チ可能デ ー タ保持 数
マスターノードを設定する際には、サーチ可能データ保持数を指定します。サーチ可能データ保持数は、クラスタ
が保持するデータのサーチ可コピー数を表しています。サーチ可能データ保持数のデフォルト値は 2 で、この場合
クラスタはすべてのデータのサーチ可コピーを 2 つ保持します。サーチ可能データ保持数は、複製データ保持数以
下でなければなりません。
サーチ可コピーとサーチ不可コピーでは、データに違いがあります。サーチ可コピーには、データ自身と Splunk
がデータのサーチに使用する広大なインデックスファイルが含まれています。サーチ不可コピーには、データのみ
が含まれています。サーチ不可コピーに含まれているデータにも初期処理が行われており、必要に じてインデッ
クスファイルを再作成できる形式で保管されています。Splunk インデックスを構成するファイルの詳細は、
「データファイル」を参照してください。
サーチ可能データ保持数が 2 以上の場合、あるピアノードが停止してもわずかな中断でサーチを 続することがで
きます。たとえば、複製データ保持数に 3 を、サーチ可能データ保持数に 2 を設定した場合を考えてみましょ
う。クラスタはバケツのコピー 3 つをクラスタ内の個別のピアに保管し、各バケツのコピーの中の 2 つはサーチ
可になります。サーチに関与しているバケツのコピーを持つピアが停止した場合、他のピアのバケツのサーチ可コ
ピーが即座にサーチに参加します。
一方、クラスタのサーチ可能データ保持数が 1 の場合にピアが停止すると、すべてのクラスタデータを 象にサー
チを再開できるまでに大幅に時間がかかってしまいます。バケツのサーチ不可コピーをサーチ可にすることはでき
ますが、raw データからインデックスファイルを作成しなければならないため、この 換処理には時間がかかりま
す。停止したピアに大量のサーチ可データが保管されていた場合、処理時間が大幅に長くなることがあります。
サーチ不可コピーをサーチ可に 換するためにかかる時間の見積もりについては、ここを参照してください。
クラスタでサーチ可コピー数を制限する理由は、サーチ可データはサーチ不可データよりも大量のストレージを消
費するためです。そのため、ピアノード障害発生時にもすべてのデータに素早くアクセスできることとストレージ
要件の 加がトレードオフとなります。サーチ可およびサーチ不可データの相 ストレージサイズの見積もりについ
ては、「ストレージの 討事項」を参照してください。
バケツとクラスタ
Splunk はインデックスデータをバケツに保管します。バケツは、データ自身およびデータのインデックスファイ
ルを保管するディレクトリです。一般的にインデックスは多数のバケツから成り立っており、データの 過時間別
に編成されています。
クラスタは、バケツ単位で複製されます。元のバケツと他のピアノード上の複製されたコピーには、同一のデータ
セットが含まれています。ただし、インデックスファイルはサーチ可バケツにのみ存在しています。
90
クラスタ内で、単一のソースピアからのバケツのコピーを複数のターゲットピアに分散させることができます。た
とえば、5 台のピアが存在するクラスタの複製データ保持数が 3 の場合 (水平方向スケーリングの一般的なシナリ
オ)、クラスタは各バケツセットの複製コピーを 3 つ保持します (ソースピア上の元のコピーと 2 台のターゲットピ
ア上の複製されたコピー)。ソースピアが新しいホットバケツを開始すると、マスターはそのピアに して、データ
の複製先となる新しい一連のターゲットピアを指示します。つまり、元のコピーはソースピア上に保管され、それ
らのバケツの複製されたコピーはその他のピア上に無作為に分散保管されます。現在の所、この動作を設定するこ
とはできません。同じピア上に同じバケツのコピーが 2 つ保管されることはありません。
今 明したシナリオを以下の図に示します。5 台のピア、複製データ保持数 3、および 7 つのオリジナルのバケツが
存在し、そのコピーはすべてのピアにまたがって展開されています。簡略化するために、この図ではある 1 台のピ
アからのデータバケツのみを表示しています。実際の環境では、すべてではないですが、その他のピアもデータの
送信元となり、それをクラスタ内の他のピアに複製します。
この図で、1A がソースバケツになります。1B は 1C そのバケツのコピーです。この図では、同じ方法で
2A/B/C、3A/B/C、などのように表記しています。
クラスタの構造を理解するためには、バケツを正しく理解する必要があります。このセクションの残りの部分で
は、クラスタのデプロイにとって重要なバケツの概念について取り上げていきます。バケツの概要については、
「Splunk によるインデックス保管方法」を参照してください。
デ ー タファイル
バケツ内には 2 種類のファイルが存在しています。
処理された 縮形式の外部データ (raw データ)
raw データを指すインデックス (インデックスファイル)
raw データは実際には「未加工の」データではありません。このデータは、イベントとして処理された外部データ
から成り立っています。処理されたデータは 縮された raw データジャーナルファイルに保管されます。raw デー
タファイルはジャーナルファイルとして、イベントデータだけでなく、関連するインデックスファイルを生成する
ために必要なすべての情報を保管しています。
raw データは、サーチ可およびサーチ不可の両方のバケツコピーに含まれています。サーチ可コピーにはインデッ
クスファイルも含まれます。
ピアノードは、一連のデータをフォワーダーから受け取ると、データを処理してそれをローカルのホットバケツの
raw データファイルに追加します。また、インデックス処理も行い、 するインデックスファイルを作成します。
さらに、処理した raw データのコピーのみをターゲットピアに転送します。ターゲットピアは、その raw データ
ファイルを独自のバケツのコピーに追加します。オリジナルおよび複製されたバケツコピーの raw データは同一
です。
クラスタのサーチ可能データ保持数が 1 の場合、ターゲットピアのバケツのコピーには、raw データのみが保管さ
れます。データのインデックスファイルは作成されません。ターゲットピア上にインデックスファイルを保管しな
いことで、ストレージ要件を緩和することができます。raw データはジャーナルファイルとして保存されるため、
オリジナルの完全にインデックス処理されているデータを管理しているピアが停止した場合、いずれかのターゲッ
トファイルがその raw データのコピーからインデックスを生成することができます。
クラスタのサーチ可能データ保持数が 2 以上の場合、一部または全部のターゲットピアもデータのインデックス
ファイルを作成します。たとえば、複製データ保持数が 3 で、サーチ可能データ保持数が 2 の場合を考えてみま
しょう。この場合、ソースピアは自己の raw データのコピーを、2 台のターゲットピアに転送します。これらのピ
91
アのいずれかは raw データを使ってインデックスファイルを作成します。このインデックスファイルは、バケツ
のコピーに保管されます。このようにして、データのサーチ可コピーが 2 つ存在することになります (元のコピー
とインデックスファイルを持つ複製されたコピー)。「サーチ可能データ保持数」で 明されているように、これに
よってピアノード障害発生時にも、クラスタをより素早く復旧することができます。サーチ可バケツコピーの詳細
は、このトピックの後半にある「バケツのサーチ可否」を参照してください。
バケツの移行
バケツは時間の 過とともに、さまざまな段階 (ステージ) に移行します。
ホット
ウォーム
コールド
フローズン
これらのステージの詳細は、「Splunk によるインデックス保管方法」を参照してください。
クラスタのアーキテクチャを 明する前に、これらのバケツの各ステージの基本的な概念を理解しておく必要があ
ります。ホットバケツは、現在も 続して書き込まれているバケツです。インデクサーがホットバケツへの書き込
みを終了すると (たとえば、バケツが最大サイズに達したため)、そのバケツはウォームに移行され、新しいホット
バケツへの書き込みが開始されます。ウォームバケツは読み取り可能ですが (例：サーチ用)、それに新しいデータ
が書き込まれることはありません。その後バケツは「コールド」に移行し、最後には「フローズン」になります。
フローズン状態のバケツはアーカイブされるか、または削除されます。
これ以外にもいくつかの事項を えておく必要があります。
ホット/ウォームおよびコールドバケツは、ソースピアノード上の個別に設定可能なディレクトリに保管され
ます。
すべての複製されたバケツのコピーは、それがホット、ウォーム、またはコールドの場合でも、すべてター
ゲットノードのコールド保管用ディレクトリに保管されます。
ウォームまたはコールドバケツのファイル名には、バケツ内のデータの時間範 が含まれています。バケツの
命名規則の詳細は、「インデックスディレクトリの内容」を参照してください。
サーチは、ホット、ウォーム、およびコールドバケツにまたがって行われます。
バケツの移行条件は、「Splunk によるインデックスの保管方法」で 明するように、設定を 更することが可
能です。
ストレージ要件の見積もり方法などの、ストレージのハードウェア情報については、「ストレージの 討事
項」を参照してください。
バケツのサ ー チの可否と優先度 状 態
クラスタは複数バケツのコピーを管理しているため、どのバケツのコピーをサーチするのかを判断する方法が必要
になります。任意の時点で、バケツのコピーはサーチ可またはサーチ不可になります。また、バケツのサーチ可コ
ピーはプライマリまたは非プライマリにすることができます。
バケツのコピーに、raw データファイルに加えてインデックスファイルも含まれている場合、それはサーチ可とな
ります。外部データを受信するピアは、raw データのインデックスを作成し、raw データのコピーをそのターゲッ
トピアに送信します。サーチ可能データ保持数が 1 より大きい場合は、それに じてピアの一部または全部が複製
したバケツのインデックスファイルを生成します。たとえば、複製データ保持数が 3、サーチ可能データ保持数が
2、そしてクラスタが完全な場合、クラスタには各バケツのコピーが 3 つ存在することになります。3 つのコピー
すべてが raw データファイルを保持し、その中の 2 つ (ソースピア上のコピーといずれかのターゲットピア上のコ
ピー) にはインデックスファイルが含まれており、サーチ可となります。3 番目のコピーはサーチ不可になります
が、必要に じてサーチ可に 換することができます。サーチ不可コピーをサーチ可に 換する処理は、主にバケツの
サーチ可コピーを保持するピアが停止した場合などに行われます。
バケツのプライマリコピーは、サーチに参加するサーチ可コピーです。有効なクラスタには、各バケツに 1 つのプ
ライマリコピーが存在しています。このようにして、各バケツの 1 つのコピーのみがサーチされます。プライマリ
コピーを保有しているノードが停止した場合、プライマリではない他のノード上のサーチ可バケツが即座にプライ
マリとして指名され、サーチが続行されます。新たにインデックスファイルが生成されるまで待機する必要はあり
ません。
最初は、オリジナルのデータを保有するピアのバケツのコピーがプライマリコピーになりますが、これは時間の
過に伴い 更される可能性があります。たとえば、そのピアが停止した場合は、いずれかのターゲットピアのサー
チ可コピーに優先度が与えられます。
重要：ピアが停止した場合にのみ、優先度の再割り当てが行われます。この場合、マスターは停止したピアのプラ
イマリコピーの代わりに、残りのピアのいずれかのサーチ可コピーをプライマリにします。このプロセスの詳細
は、「ピアノード停止時の処理」を参照してください。
すべてのピアにまたがったバケツの例を以下の図に示します。クラスタの複製データ保持数は 3、サーチ可能デー
92
タ保持数は 2 です。この場合、クラスタは 2 つのサーチ可コピーを保持します。ここで、ソースピア上のバケツ
のコピーはすべてプライマリ (そしてサーチ可) になります。2 番目のサーチ可コピーは、クラスタ内の残りのピア
にまたがって存在しています。
プライマリバケツコピーのセットは、次のセクションで 明するようにクラスタの世代を定義しています。
世代
世代は、クラスタのバケツのどのコピーがプライマリでサーチに関与するのかを識別します。世代は時間が 過
し、ピアがクラスタから離脱/参加していくに伴って 化していきます。ピアが停止すると、そのプライマリバケツ
コピーは他のピアに割り当て直されます。
注意：実際にサーチ 象となるバケツのセットは、サーチの時間範 などの要因によっても異なります。このこと
は、インデクサーがクラスタ化されているかどうかに関係なく当てはまります。
世代は他の方法でも定義することができます。世代は、クラスタの有効な状態のスナップショットです。ここで、
「有効」とは、クラスタ内の各バケツが 1 つのプライマリコピーを保持していることを表しています。
任意の時点で、現在マスターに登 されているすべてのピアが、現在の世代に参加します。ピアがクラスタに参加
またはクラスタから離脱すると、マスターは新しい世代を作成します。
クラスタコンポーネントによる世代の使用方法
ここでは、各種クラスタコンポーネントが世代情報をどのように使用するのかについて 明していきます。
マスターはそれぞれの新しい世代を作成し、それに世代 ID を割り当てます。必要に じて、ピアやサーチ
ヘッドと現在の世代 ID をやり取りします。また、各世代のプライマリバケツのコピーおよびそれがどのピア
に存在しているのかも追跡しています。
ピアは、どのバケツのコピーが各世代のプライマリなのかを追跡しています。ピアは複数世代にまたがって
優先度情報を保持しています。
各サーチでサーチヘッドはマスターから取得した世代 ID を使って、サーチ 象ピアを判断します。
世代の 更時期
世代は以下の状況下で 更されます。
マスターがオンラインになった。
ピアがクラスタに追加された。
ピアが意図的 (CLI の offline コマンド) または偶発的 (障害発生) に停止した。
ピアが停止した場合、マスターは停止したノードのバケツのプライマリコピーの代わりに、残りのノード上にある
同じバケツのサーチ可コピーをプライマリに割り当て直し、新しい世代を作成します。
マスターは、バケツがホットからウォームに移行する場合には新たな世代を作成しません。そのため、新しいホッ
トバケツが作成されます (バケツが前述の理由により移行された場合を除く)。そのような状況では、一連のピアは
更されません。サーチヘッドは、どのピアがその世代に属しているのかを知る必要しかありません。特定のピア
上のどのバケツのコピーがプライマリであるかを知る必要はありません。この情報はピア自体が管理しています。
93
上のどのバケツのコピーがプライマリであるかを知る必要はありません。この情報はピア自体が管理しています。
サーチにおける世代の使用方法
サーチヘッドは定期的に、マスターに最新の世代情報を問い合わせます。世代が 更されると、マスターはサーチ
ヘッドに新しい世代 ID とその世代に属するピアのリストを通知します。サーチヘッドは、サーチ実行時にピアに
その ID を渡します。ピアはその ID を使って、サーチのプライマリバケツを判別します。
一般的に、サーチは最新世代のプライマリバケツコピーを使って行われます。長時間実行されるサーチの場合、以
前の世代にまたがってサーチを実行できる場合もあります (一般的には、サーチの途中でピアが停止したため)。こ
れにより、一部のデータが失われている場合でも (停止ノードによる)、長時間に渡るサーチを完了することができ
ます。必要に じて手動で再び代替サーチを実行することもできます。
ピアの停止により世代が 更される理由
ピアの停止により、マスターが新たな世代を作成する理由は、ピアの停止時にマスターは停止したピアのプライマ
リコピーの代わりとなる、他のピアのコピーをプライマリとして割り当て直すためです。以前の世代でプライマリ
でなかったコピーが、新しい世代のプライマリになります。サーチに関連する世代 ID を知ることで、ピアはその
サーチのプライマリであるバケツを判断することができます。
たとえば以下の図は、すべてのプライマリコピーを保持するソースノードが停止して、マスターが残りのピアにバ
ケツの修復を指示した後の、以前と同じ簡素化版のクラスタを表しています。まず、マスターノードは優先度を、
各バケツの残りのサーチ可コピーに割り当て直します。次に、マスターノードは失われたサーチ可コピーを補うた
めに、サーチ不可コピーをサーチ可コピーに 換するようにピアに指示します。最後にマスターは、新たなサーチ
不可コピーセット (1D、2D など) を複製し、残りのピアに分散させることを指示します。
ソースノードが停止しても、合計バケツコピー数の複製データ保持数 (3) と合計サーチ可バケツコピー数のサーチ
可能データ保持数、および各バケツの 1 つのプライマリコピーにより、クラスタは完全状態と有効状態の両方を復
元することができます。この図では、プライマリコピーが別のピアに移動されているため、前の図とは世代が異
なっていることが分かります。
注意：この図には、ある 1 台のピアからのバケツのみが表示されています。この図を詳細に記述すると、複数のピ
アから転送されたさまざまなバケツが表示されることになります。
クラスタの 状 態
正常に動作、機能しているクラスタは、有効で完全な状態です。
有効なクラスタには、各バケツに 1 つのプライマリコピーが存在しています。
完全クラスタには、各バケツの複製データ保持数だけのコピーが存在しており、また各バケツに してサーチ
可能データ保持数だけのサーチ可コピーを保有しています。
有効なクラスタは、データセット全体に してサーチリクエストを処理することができます。
完全クラスタは、障害 策の点で指定された要件を たしています。
また、確実なデータ可用性を実現するために、クラスタは完全状態であるだけでなく、サーチ可能データ保持数に
最低 2 以上を設定する必要があります。こうすることによって、サーチヘッドはあるピアが停止しても、クラスタ
94
全体にまたがるサーチを続行することができます。
ピアノードが停止した場合、マスターはクラスタの有効な状態と完全な状態を復元するための作業を指示します。
クラスタを有効な状態に すことはできても、完全な状態に すことはできない場合があります。(たとえば、3 台の
ピアを持つクラスタで複製データ保持数が 3 の場合を考えてみましょう。1 台のピアが停止すると、ピアが再稼働
しない限りクラスタを完全状態に回復することはできません。ただし、有効状態に復 することは可能です。)ノー
ド停止時のクラスタの復旧処理については、「ピアノード停止時の処理」を参照してください。
クラスタでのインデックス作成の仕組み
クラスタ内でのインデックス作成について 明する前に、2 種類のピアノードの違いを理解しておきましょう。
ソースノード：ソースノードは、フォワーダーまたは他のソースからデータを取り込みます。
ターゲットノード：ターゲットノードは、複製されたデータのストリームをソースノードから受信します。
実際には、1 台のピアがソースノードとターゲットノードの両方として機能します。ただし、クラスタコンポーネ
ント間のデータおよびメッセージの流れを理解するために、これらの 2 種類の区別を理解しておくことが役立ちま
す。
重要：一般的なクラスタデプロイ環境では、すべてのピアノードがソースノードとなります (各ノードが独自の外
部入力を保有している)。これは必要条件ではありませんが、一般的には最善の方法です。一部のピアをターゲッ
トノード専用として保有することに、何も意義はありません。複製データ保管の処理コストはとても小さく、また
現在の所複製データを受信するノードを指定することはできません。受信ノードはマスターがバケツ単位に決定
し、その動作を設定することはできません。すべてのピアノードがターゲットとしての役割も果たすことに留意し
てください。
注意：外部データの複製に加えて、各ピアはその内部インデックスも他のピアに同 の方法で複製します。ただ
し、ここでは 明を簡素化するために、外部データがどのように処理されるかについてのみ注目していきます。
ピアノ ー ド起動時
これらのイベントは、ピアノードの起動時に発生します。
1. ピアノードはマスターに登 して、マスターから最新の設定バンドルを受け取ります。
2. マスターは新しい世代を開始します。
3. ピアは他のインデクサーと同 に、外部データの取り込みを開始します。ピアはデータを処理してイベントに
し、それを raw データファイルに追加します。また、関連するインデックスファイルも作成します。これらの
ファイル (raw データとインデックスファイルの両方) はローカルのホットバケツに保管されます。これがバケツ
のプライマリコピーになります。
4. マスターは、ピアにその複製データのターゲットピアのリストを渡します。たとえば、複製データ保持数が 3
の場合、マスターは 2 台のターゲットピアのリストを渡します。
5. サーチ可能データ保持数が 2 以上の場合、マスターはピアに、データのコピーをサーチ可にするターゲットピ
アも指示します。たとえば、サーチ可能データ保持数が 2 の場合、マスターはコピーをサーチ可にする 1 台の
ターゲットピアを選出し、その情報をソースピアに伝えます。
6. ピアは、マスターが指示したターゲットピアへの、処理 み raw データの転送を開始します。ピアは、raw デー
タファイル全体の処理が完了するまで転送を開始しないのではなく、処理 みのデータをブロック単位で転送して
いきます。また、ステップ 5 でマスターが通信したターゲットピアが、そのコピーをサーチ可にする必要がある場
合は、その旨も伝えます。
7. ソースピアから raw データを受信したターゲットピアは、それをローカルのバケツコピーに保管します。
8. サーチ可コピーの作成を指示されたターゲットは、必要なインデックスファイルの生成を開始します。
9. ピアはそのホットバケツを移行するまでの間、ターゲットへのデータ転送を 続します。
注意：ソースおよびターゲットピアは相互に管理ポートを通じて通信する訳ではありません。複製ポートを介し
て、相互にデータを送受信するだけです。総合的なプロセスはマスターノードが管理します。
これは、単に 1 台のピアにおけるデータの流れです。クラスタ内では、複数のピアが常時相互にデータを送受信し
ます。
ピアノ ー ドのホットバケツの移行時期
95
ソースピアがホットバケツをウォームバケツに移行する場合 (たとえば、バケツが最大サイズに達したため)、以下
の一連のイベントが発生します。
1. ソースピアはマスターおよびターゲットピアに、バケツを移行することを伝えます。
2. ターゲットピアは各自のバケツのコピーを移行します。
3. ソースピアはこの間にも、外部データの取り込みを 続しています。新しいホットバケツ内にローカルにデータ
のインデックスを作成し、raw データを、マスターから取得した新たなターゲットピアセットに転送します。
4. ソースピアから新しいホットバケツの raw データを受信したターゲットピアは、それをローカルのバケツコ
ピーに保管します。サーチ可コピーの作成を指示されたターゲットは、必要なインデックスファイルの作成も開始
します。
5. ソースピアは次のホットバケツを移行するまでの間、ターゲットへのデータ転送を 続します。以降も同 の処理
が行われます。
ピアノ ー ドとフォワ ー ダ ー のやり取り
ピアノードがフォワーダーからデータを取得すると、フォワーダーからのデータを受け取る他のインデクサーと同
に処理が行われます。ただし、大部分のクラスタリング環境では、ピアにデータを送信する各フォワーダー上
でインデクサー 答確認を有効にする必要があります。こうすることによって、フォワーダーとピア間でデータが
失われることを防止できます。また、これが終端間のデータ忠実度を確保する唯一の方法です。フォワーダーがピ
アに送信したデータブロックに する確認 答を受信しなかった場合、そのブロックが再送信されます。
インデクサー 答確認の有効化も含めた、フォワーダーのピアへのデータ送信の設定方法の詳細は、「フォワー
ダーを使ったデータの取り込み」を参照してください。ピアとフォワーダーがインデクサー 答確認をどのように
処理しているかについては、「インデクサー 答確認の仕組み」を参照してください。
クラスタ化サ ー チの仕組み
クラスタでは、サーチヘッドを使って一連のピアにまたがるサーチを行います。後述するように希な状況下では、
1 台のピア上でサーチを実行することもできます。
クラスタにまたがるサ ー チ
クラスタ化サーチは、非クラスタ環境で分散サーチが動作する仕組みと非常に似ています。主な違いは、サーチ
ヘッドがマスターノードからサーチピアのリストを取得することにあります。また、世代 ID もマスターから取得
します。その後は、ピアと直接通信を行います。
注意：クラスタ化サーチで、サーチピアとは現在マスターに登 されている一連のクラスタピアのことです (稼働し
ていてクラスタに参加しているピア)。
サーチヘッドがサーチを開始すると：
1. サーチヘッドはマスターノードと通信します。
2. マスターノードはサーチヘッドに現在の世代 ID およびその世代のピア (現在マスターに登 されているピア) のリ
ストを伝えます。
3. サーチヘッドは、非クラスタ環境の分散サーチと同じようにサーチピアと通信し、ピアに同じ情報 (サーチリク
エストと複製バンドル) を渡します。ただし、クラスタの場合は世代 ID もサーチピアに渡します。
4. サーチピアは世代 ID を使って、各自が保有するその世代のプライマリバケツコピーを判別し (ある場合)、そし
てサーチに参加する必要があるかどうかを判断します。他のサーチと同 に、ピアはサーチの時間範 も使って特定
のバケツをサーチするかどうかを判断します。
5. サーチピアは、各自のバケツのプライマリコピーをサーチして、結果をサーチヘッドに渡します。サーチヘッド
はそれらの結果を統合します。
非クラスタ環境の分散サーチと同 に、複数のサーチヘッドを用意してそれらを単一のユニットのように動作させ
ることができます。これは、サーチヘッドプールと呼ばれています。また、非クラスタ分散サーチのように、マウ
ントされたバンドルを使ってサーチヘッドからピアに渡されるデータ量を減らすことができます。
これらの機能および他の分散サーチで利用できる機能については、『Distributed Deployment manual』の
「Search across multiple indexers」を参照してください。また、クラスタ構成のサーチヘッドと非クラスタサー
チヘッドの設定の違いについては、このマニュアルの「サーチヘッドの設定」を参照してください。
96
単 一ピアのサ ー チ
デバッグ目的で、1 台のピアノードに してのみサーチを行わなければならないこともあります。この場合は、その
ピア上で直接サーチを行います。このサーチは、ピア上にある任意のサーチ可データにアクセスします。ピア上の
サーチ不可データ、または他のピア上のサーチ可データのコピーにアクセスすることはありません。
注意：各ピア上でどのデータをサーチ可にするかを設定する方法は存在しないことに注意してください。ただし最
低でも、ピアからクラスタに取り込まれたデータはすべて、そのピア上でサーチ可になります。
クラスタノ ー ドの起動方法
このトピックは、以下の場合にどのような処理が行われるのかを 明しています。
マスターノードの開始時
ピアが新しいクラスタに参加した場合
ピアが既存のクラスタに参加した場合
マスタ ー ノ ー ドの開始時
マスターノードがオンラインになると (初回またはそれ以降)、クラスタピアの待機を開始します。オンラインに
なっているピアはマスターに登 します。マスターは、それらのピアをクラスタに追加します。マスターは複製
データ保持数に等しい台数のピアが登 されるまで待ち、その後クラスタの実行を開始します。
初めてクラスタをデプロイする場合、まずマスターを有効にしてから、次にピアノードを有効にする必要がありま
す。「デプロイの概要」を参照してください。マスターは、複製データ保持数と同じ台数のピアが有効になり再起
動されるまで、ピアのインデックス作成をブロックします。
その後マスターを再起動すると、60 秒の間ピアの登 のために待機します。この期間が過ぎて、複製データ保持数
以上のピアが登 された場合、マスターはクラスタとして動作するために、取り込んだデータのコピーの転送先の
指示などの、ピアの調整を開始します。そのため、マスターを再起動する場合は、複製データ保持数以上のピアが
稼働していることを確認してください。
最初の 60 秒間が 過すると、マスターダッシュボードでクラスタのステータスを確認することができます。
マスターの停止および再起動時にどのような処理が行われるかについては、「マスターノード停止時の処理」を参
照してください。
ピアが新しいクラスタに 参 加した場合
初めてクラスタをデプロイする場合は、まずマスターを有効にしてから、次にピアノードを有効にする必要があり
ます。「デプロイの概要」を参照してください。マスターは、複製データ保持数と同じ台数のピアが有効になり再
起動されるまで、ピアのインデックス作成をブロックします。
各ピアはオンラインになるとマスターに登 します。マスターは、そのピアに最新の設定バンドルを自動的に配布
します。次にピアはローカルに設定ファイルを 証します。バンドルの 証が正常に完了した場合にのみ、ピアはク
ラスタに参加します。
クラスタに複製データ保持数以上のピアが参加したら、ピアはデータのインデックス作成を開始します。
ピアが 既 存のクラスタに 参 加した場合
ピアは後ほど、すでにマスターと複製データ保持数の台数のピアが稼働し、クラスタが機能するようになってか
ら、オンラインにすることもできます。ピアをオンラインにすると、そのピアはマスターに登 します。マスター
は、そのピアに最新の設定バンドルを自動的に配布します。次にピアはローカルに設定ファイルを 証します。バ
ンドルの 証が正常に完了した場合にのみ、ピアはクラスタに参加します。
注意：既存のクラスタに新しいピアを追加しても、即座にバケツの再配置が行われる訳ではありません。新しいピ
アは今後のバケツ複製に参加しますが、マスターが既存のピアから新しいピアにバケツのコピーの移動やプライマ
リの再割り当てを指示することはありません。
ピアノ ー ド停止時の 処 理
ピアノードは意図的に (「ピアをオフラインにする」に記述されているように CLI の offline コマンドを使用) 停
止、または意図せずに (サーバークラッシュなど) 停止することがあります。offline コマンドを使用してピアを停
止すれば、サーチの中断を最低限に抑えられます。
97
ピアがどのように停止した場合でも、マスターが復旧措置を指示して代わりのバケツコピーを配置します。このプ
ロセスは、バケツの修復と呼ばれています。マスターは 続的に、各ノード上に保管されているバケツのコピーお
よびその状態 (優先度、サーチの可否) を追跡しています。あるピアが停止すると、マスターはクラスタを以下の
状態に回復する目的で、残りのピアにバケツセットの修復を指示できます。
各バケツのプライマリコピーが 1 つずつのみ存在している。(有効な状態)
各バケツのサーチ可コピーのフルセットが、サーチ可能データ保持数と一致している。
各バケツのコピーのフルセット (サーチ可およびサーチ不可の両方) が、複製データ保持数と一致している。
(完全な状態)
通常は複数ノードに致命的な障害が発生しなければ、マスターは有効なクラスタを再作成することができます。ク
ラスタのサーチ可能データ保持数が 2 以上の場合は、ほぼ即座にその作業を完了できます。マスターが完全クラス
タを再構築できるかどうかは、複製データ保持数以上のピアが引き続き稼働しているかどうかによって決まりま
す。最低でも複製データ保持数と同じ数のノードが動作していないと、クラスタを完全状態に復 させることはで
きません。
クラスタが完全状態に るまでには非常に時間がかかることがあります (最初にあるピアから他のピアにバケツを転
送し、バケツのサーチ不可コピーをサーチ可にする必要があるため)。詳細は、「ピア離脱時のクラスタ復旧時間
の見積もり」を参照してください。
ノードの停止時には、バケツ修復の復旧措置のほかにも、いくつかの主要イベントが発生します。
マスターは新たな世代に移行して、新しい世代 ID を作成します。世代 ID は必要に じてピアやサーチヘッド
に通知します。
停止したノードのホットバケツのコピーを保有するピアは、それらのコピーをウォームに移行します。
ピアノ ー ドを意 図 的にオフラインにした場合
コマンドは、クラスタからピアを削除します。また、このコマンドはピアを停止します。この場合、処理
中のサーチを完了し、クラスタを完全なサーチ可状態に素早く せるように、順次処理を行いながらピアを正常に
停止します。
offline
offline
コマンドには 2 種類のバージョンがあります。
splunk offline：高速版の offline
コマンドです。ピアはサーチ実行中または復旧処理中の場合でも、最大
で 5 10 分後に停止します。
splunk offline --enforce-counts：enforce-counts
版のコマンドで、クラスタが完全状態に復 したことを
証することを目的にしています。enforce-counts フラグを使用すると、すべてのサーチおよび復旧処理が完
了するまでの間、ピアはシャットダウンされません。
ピアをオフラインにする基本的な方法については、「ピアをオフラインにする」を参照してください。
高 速 な offline コ マ ン ド
高速版の offline コマンドの構文を以下に示します。
splunk offline
このバージョンのコマンドは、以下の一連の処理を実行します。
1. 部分シャットダウン。ピアは即座に部分シャットダウンを行います。ピアは外部入力および複製データの受け付
けを停止します。ただし、サーチ処理は 続します。
2. 優先度割り当て。マスターは、ピア上の任意のプライマリバケツコピーの優先度を、他のピア上のそれらのバケ
ツのサーチ可コピーに割り当て直します。このステップの最後には、クラスタが有効状態に復 します。サーチ可
能データ保持数が 2 以上の場合、この処理はあっという間に完了します。このステップの間、ピアのステータスは
ReassigningPrimaries になります。
3. 世代 ID の 更。マスターはクラスタの世代 ID を 更します。このステップの最後には、ピアは新しいサーチに参
加しなくなりますが、引き続き処理中のサーチには関与します。
4. 完全シャットダウン。ピアは最大で 5 10 分後または処理中のサーチおよび優先度の再割り当て処理が完了した
場合に (どちらかが先に発生した時点で)、完全にシャットダウンされます。また、マスターへのハートビートの送
信を中止します。
5. 再起動カウント。ピアのシャットダウン後、マスターは server.conf に設定されている restart_timeout の期間
(デフォルトは 10 分) 待機します。その期間内にピアがオンラインに復 した場合、それ以上の復旧措置は行われま
せん。このステップの間、ピアのステータスは Restarting になります。ピアがタイムアウト期間内に復 しなかっ
た場合は、そのステータスが Down に 化します。
98
6. 復旧処理。ピアが restart_timeout に指定されている期間内に再起動されなかった場合、マスターはクラスタバ
ケツの修復処理を開始します。残りのピアに して、停止するピア上にあったバケツのコピーを複製するように指
示します。また、停止するピアのバケツのサーチ可コピーの代わりとなるように、それらのバケツの他のピア上の
サーチ不可コピーをサーチ可コピーに 換することも指示します。このステップの最後には、クラスタが完全状態
に ります。ピアの停止により複製データ保持数未 のピアしか稼働していない場合は、このステップを完了して完
全クラスタに ることができません。このプロセスは、ピアがすでにオフライン状態でも実施されます。
enforce-counts を 指 定 し た offline コ マ ン ド
enforce-counts 版の offline コマンドの構文を以下に示します。
splunk offline --enforce-counts
このバージョンのコマンドは、離脱と呼ばれるプロセスを開始します。離脱プロセス時には、以下の一連の処理が
行われます。
1. 部分シャットダウン。ピアは即座に部分シャットダウンを行います。ピアは外部入力および複製データの受け付
けを停止します。ただし、サーチ処理は 続します。
2. 優先度割り当て。マスターは、ピア上の任意のプライマリバケツコピーの優先度を、他のピア上のそれらのバケ
ツのサーチ可コピーに割り当て直します。このステップの最後には、クラスタが有効状態に復 します。サーチ可
能データ保持数が 2 以上の場合、この処理はあっという間に完了します。このステップの間、ピアのステータスは
ReassigningPrimaries になります。
3. 世代 ID の 更。マスターはクラスタの世代 ID を 更します。このステップの最後には、ピアは新しいサーチに参
加しなくなりますが、引き続き処理中のサーチには関与します。
4. 復旧処理。マスターはクラスタのバケツの修復処理を開始します。残りのピアに して、停止するピア上にあっ
たバケツのコピーを複製するように指示します。また、停止するピアのバケツのサーチ可コピーの代わりとなるよ
うに、それらのバケツの他のピア上のサーチ不可コピーをサーチ可コピーに 換することも指示します。このス
テップの最後には、クラスタが完全状態に ります。ピアの停止により複製データ保持数未 のピアしか稼働してい
ない場合は、このステップを完了して完全クラスタに ることができません。このステップの間、ピアのステータ
スは Decommissioning になります。
5. 完全シャットダウン。ピアは、1) 処理中のサーチが完了した、および 2) クラスタが完全状態に復 した場合に
シャットダウンされます。シャットダウンされたピアは、マスターへのハートビートの送信を中止します。この時
点で、ピアのステータスは GracefulShutdown に 化します。
注意：クラスタが完全状態に復 できない場合、バケツの修復処理は完了できず、ピアはシャットダウンされませ
ん。一般的には、残りピアの台数が、複製データ保持数を下回った場合にそのような状況が発生します。
予期せずにピアノ ー ドが停止した場合
コマンド実行以外の何らかの理由でピアノードが停止した場合、マスターへの定期的なハートビート送信
が中断します。マスターはこれによりノード停止を 出し、復旧措置を開始します。基本的にマスターは、ピアを
意図的に停止する場合と同じ処理を指示しますが、以下の例外があります。
offline
停止したピアは、処理中のサーチには参加しません。
マスターはハートビートタイムアウトの時間 (デフォルトは 60 秒) だけ待機して、その後優先度の再割り当
てとバケツの修復処理を開始します。
ノードが停止してもクラスタにまたがってサーチは 続されますが、クラスタが有効な状態に回復するまでの間
は、部分的な結果しか表示されません。
バケツ修復のシナリオ
バケツ修復には 3 種類の作業が関与しています。
バケツの他のサーチ可コピーにプライマリステータスを割り当て直す。
バケツのサーチ不可コピーをサーチ可コピーにする。
複製したバケツのコピーを、バケツのコピーを保有していないピアに転送する。
バケツのサーチ可コピーの、非プライマリからプライマリへの 換は即座に行われます。サーチ可バケツのコピー
にはすでにインデックスファイルが存在しているため、実質的にはほとんど何の処理も行われません。(サーチ可
コピーの予備が存在していることを前提にしています。そのためには、サーチ可能データ保持数が 2 以上でなけれ
ばなりません。そうでない場合は、まずサーチ不可コピーをサーチ可コピーに 換してから、それをプライマリと
して指定します。)しかし、バケツのサーチ不可コピーをサーチ可コピーに 換する作業は、バケツのインデックス
ファイルを作成する必要があるため、多少時間がかかります。サーチ不可コピーをサーチ可に 換するためにかか
99
る時間の見積もり方法については、「ピア離脱時のクラスタ復旧時間の見積もり」を参照してください。
ここでは 2 つの例を参考に、マスターによる 1) 有効で完全なクラスタの再作成、および 2) 有効だけれども不完全
なクラスタの作成 (残りノード数が不十分な場合) について 明していきます。このプロセスは、ピアを意図的に停
止した場合でも、ピアが意図せずに停止した場合でも同じです。
以下の事項を忘れないようにしてください。
クラスタは、各バケツのサーチ可コピーが 1 つ存在している場合に「有効」となります。有効なクラスタに
するサーチでは、完全なサーチ結果が返されます。
クラスタに、複製データ保持数と同数のバケツのコピー、およびサーチ可能データ保持数と同数のサーチ可
コピーが存在している場合、そのクラスタは「完全」です。
すべてのバケツのサーチ可コピーが存在しているけれども、複製データ保持数よりも少ない数のバケツコ
ピーしか存在していない場合、クラスタは有効だけれども不完全になります。そのため、複製データ保持数
が 3 で 3 台のピアノードしか存在していないクラスタで、いずれかのピアが停止した場合、クラスタを有効
な状態にすることは可能ですが、2 台のノードしか稼働していないため完全な状態にすることはできません
(複製データ保持数に指定されている 3 つのバケツコピーを維持できないため)。
例：バケツの修復による有効で完全なクラスタの作成
前提：
停止したピアは、以下のようなクラスタのメンバーだった。
停止したピアを含めて 5 台のピアが存在
複製データ保持数 = 3
サーチ可能データ保持数 = 2
停止したピアは以下バケツコピーを保有していた。
バケツのプライマリコピー数は 3
サーチ可コピー数は 10 (プライマリコピーを含む)
合計バケツコピー数は 20 (サーチ可およびサーチ不可を含む)
ピアが停止すると、マスターは以下のように、残りのピアに してさまざまなメッセージを送信します。
1. 停止ノードの 3 個のプライマリコピーのそれぞれに して、マスターは当該バケツのサーチ可コピーを保有する
他のノードを探し、そのノードに して保有するコピーをプライマリにするように指示します。
このステップが完了すると、クラスタは有効状態に復 し、それ以降のサーチに しては完全な結果セットを返せる
ようになります。
2. 停止ノードの 10 個のサーチ可コピーのそれぞれに して、マスターは当該バケツのサーチ不可コピーを保有する
他のノードを探し、そのノードに して保有するコピーをサーチ可にするように指示します。そのノードは、その
コピーのインデックスファイルの作成を開始します。
3. 停止ノードの合計 20 個のバケツのコピーそれぞれに して、マスターは 1) そのバケツのコピーを保有するノー
ドおよび 2) そのバケツのコピーを保有していないノードを探します。次に、コピーを持つノードに して、バケツ
のデータを他のノード (データを持たないノード) にコピーするように指示します。
この最後のステップが完了すると、クラスタは完全状態に復 します。
例：バケツの修復による有効だが不完全なクラスタの作成
前提：
停止したピアは、以下のようなクラスタのメンバーだった。
停止したピアを含めて 3 台のピアが存在
複製データ保持数 = 3
サーチ可能データ保持数 = 1
停止したピアは以下バケツコピーを保有していた。
バケツのプライマリコピー数は 3
サーチ可コピー数は 10 (プライマリコピーを含む)
合計バケツコピー数は 20 (サーチ可およびサーチ不可を含む)
クラスタには 3 台しかノードがなく、複製データ保持数が 3 のため、あるノードが停止すると複製データ保持数
の要件を たすことができません。そのため、クラスタを完全状態に復 することはできません。
ピアが停止すると、マスターは以下のように、残りのピアに してさまざまなメッセージを送信します。
1. 停止ノードの 10 個のサーチ可コピーのそれぞれに して、マスターは当該バケツのサーチ不可コピーを保有する
他のノードを探し、そのノードに して保有するコピーをサーチ可にするように指示します。そのノードは、その
100
コピーのインデックスファイルの作成を開始します。
2. 停止ノードの 3 個のプライマリコピーのそれぞれに して、マスターは当該バケツのサーチ可コピーを保有する
ノードを探し、そのノードに して保有するコピーをプライマリにするように指示します。前の例とは違い、クラ
スタのサーチ可能データ保持数が 1 であるため、サーチ不可コピーをサーチ可コピーに 換しないと、他のバケツ
のコピーをプライマリとして指定することはできません。
ステップ 2 が完了すると、クラスタは有効状態に復 し、それ以降のサーチに しては完全な結果セットを返せるよ
うになります。
3. 停止したノード上の合計 20 個のバケツコピーについては、コピーを保持するために十分な数のノードが残って
いないため、マスターが代替コピーを作成するための処理を開始することはできません。
クラスタは複製データ保持数に相当する完全なバケツコピーのセットを作成できないため、クラスタは不完全な状
態となります。
画像
以下の図は、5 台のピアが存在する、複製データ保持数が 3 でサーチ可能データ保持数が 2 のクラスタを表してい
ます。バケツのプライマリコピーは、フォワーダーからデータを受信したソースピア上に存在しており、そのデー
タのサーチ可およびサーチ不可コピーが他のピアに保管されています。
注意：この図はとても単純化されています。分かりやすいように、この図ではある 1 台のピアが保有するデータの
バケツのみを表しています。実際の環境では、すべてではないですが、その他のピアもデータの送信元となり、そ
れをクラスタ内の他のピアに複製します。
以下の図は、すべてのプライマリコピーを保持するソースノードが停止して、マスターが残りのピアにバケツの修
復を指示した後の、前と同じように単純化されたクラスタを表しています。
101
マスターは、停止したピアのバケツを回復するために、クラスタにさまざまな作業を指示します。
1. マスターは停止ピア上のバケツのコピーの優先度を、残りのピア上にあるサーチ可コピーに割り当て直します。
このステップが完了すると、世代 ID が 更されます。
2. マスターはピアに して、サーチ不可コピーセットをサーチ可に 換して、失われたサーチ可コピーを補完するよ
うに指示します。
3. マスターは、新たなサーチ不可コピーセット (1D、2D など) を複製し、残りのピアに分散させることを指示しま
す。
ソースノードが停止しても、合計バケツ数の複製データ保持数と合計サーチ可バケツ数のサーチ可能データ保持
数、および各バケツに するそれぞれ 1 つのプライマリコピーにより、クラスタは完全状態と有効状態の両方を復
元することができます。この図では、プライマリコピーが別のピアに移動されているため、前の図とは世代が異
なっていることが分かります。
ピアノ ー ドが復 した場合の 処 理
ピアノードは意図的 (CLI の offline コマンド) に、または偶発的 (サーバークラッシュなど) に停止することがあり
ます。ピアが停止すると、「ピアノード停止時の処理」で 明しているように、バケツの修復と呼ばれるクラスタ
の復旧処理が行われます。現在ご覧のトピックでは、ピアがその後クラスタに復 した場合にどのような処理が行
われるのかについて 明していきます。
ピアが復 すると、マスターへのハートビート送信を開始します。マスターはそれを認識すると、ピアをクラスタ
に追加します。前にクラスタに参加していた場合と同じ完全なバケツのコピーをピアが保有している場合、マス
ターはそれらのコピーを管理 象バケツ数に追加します。
注意：ピアはマスターに接続すると、最新版の設定バンドルを保有しているかどうかを確認します。ピアの停止中
にバンドルが更新された場合は、最新版の設定バンドルをダウンロードして、それをローカルに 証し、再起動し
ます。バンドルの 証が正常に完了した場合にのみ、ピアはクラスタに再参加します。
マスタ ー のバケツのカウント方法
ピアがクラスタに復 した場合に何が起きるのかを理解するために、まずマスターがバケツのコピーをどのように
追跡しているのかを理解する必要があります。
マスターは、クラスタ内の各バケツの数を管理しています。マスターは、各バケツに する、以下の情報を保有し
ています。
クラスタ内に存在しているバケツのコピー数。
クラスタ内に存在しているバケツのサーチ可コピー数。
またマスターは、特定のバケツのプライマリコピーが常に 1 つだけ存在するように制御しています。
マスターは、これらのカウントにより、クラスタが有効で完全であるかを判断します。完全クラスタの条件を以下
に示します。
各バケツのプライマリコピーが 1 つずつのみ存在している。
各バケツのサーチ可コピーのフルセットが、サーチ可能データ保持数と一致している。
各バケツのコピーのフルセット (サーチ可およびサーチ不可) が、複製データ保持数と一致している。
バケツの修復とピア上のコピ ー
ピアが停止すると、マスターは残りのピアにバケツの修復処理を指示します。最終的にバケツの修復が成功した場
合、クラスタは完全状態に復 します。
その後ピアがクラスタに復 した場合、マスターはそのバケツコピーをカウント数に追加します (ピア停止の原因と
なった問題により、それらのコピーが壊れていない場合)。その結果がどうなるかは、ピアの復 時までにバケツの
修復処理が完了しているかどうかによって異なります。
バケツの修復が完了している場合
バケツの修復がすでに完了し、クラスタが完全状態になっている場合、復 したピアのコピーは単に余分なコピー
となります。たとえば、複製データ保持数が 3 の場合に、クラスタですべてのバケツの修復処理が完了すると、ク
ラスタには再び各バケツの 3 つのコピーが存在することになります (停止したピアが停止前に管理していたバケツ
を含む)。停止したピアが完全な状態のコピーを持った状態でクラスタに復 すると、マスターは単純にそれらのコ
ピーをカウント 象としてコピー数に追加します。そのため、一部のバケツに しては、3 つではなく 4 つのコピー
102
が存在することになります。同 に、復 したピアが一部のバケツのサーチ可コピーを保持していた場合は、余分な
サーチ可バケツが存在することになります。これらの余分なコピーは、後ほどそれらのバケツの一部のコピーを保
持している、その他のピアが停止した場合などに役立ちます。
バケツがまだ修復中の場合
クラスタが、ピア停止時に失われたコピーを引き続き再作成している場合、ピアの復 によりバケツの修復処理作
業を減らせます。マスターが復 したピア上のコピーをカウント 象に追加すると、クラスタは不完全だが有効な状
態であることが分かります。そこで、その他のピアにそれらのバケツのコピー作成を指示する必要がなくなりま
す。ただし、バケツのコピーやコピーのサーチ可への 換などの、バケツ修復処理中のピアは、それらのコピーに
する作業を完了するまで行います。バケツの修復処理には時間がかかるため、停止したピアをオンライン状態に復
させることには、そうするだけの価値があります (特にピアが大量のバケツコピーを保有している場合)。
マスタ ー ノ ー ド停止時の 処 理
マスターは、クラスタが正常に動作するために必要不可欠で、大部分のクラスタ活動を指示、調整する役割を果た
しています。マスターが停止した場合、ピアとサーチヘッドは既定の行動を取り、しばらくの間は通常に近い動作
を行えます。それでも、マスターの停止は深刻な障害として 処する必要があります。
マスタ ー が停止した場合
マスターが停止しても、他の障害が発生しない限りクラスタは通常のように機能することができます。ピアは引き
続きデータの取り込み、他のピアへのコピーの転送、バケツの複製、およびサーチヘッドからのサーチリクエスト
への 答を行えます。
ピアはホットバケツを移行する時に、通常はマスターに問い合わせて次のホットバケツの転送先ターゲットピアリ
ストを取得します。しかし、マスター停止中にピアがホットバケツを移行した場合、次のホットバケツは前のホッ
トバケツと同じ一連のターゲットピアに転送されます。
問題は徐々に現れてきます。たとえば、マスター停止中にピアが停止した場合、バケツの修復処理を実行すること
はできません。また、何らかの理由であるピアがターゲットピアと接続できない場合、他のターゲットに 更する
ことはできません。
サーチもマスターなしで 続することができますが、徐々にサーチがアクセスできるデータセットが不完全なもの
になっていきます。サーチヘッドは、マスターが停止する前に最後に取得した世代 ID を使用します。この世代の
ピアが停止した場合は、警告メッセージが表示されます。
マスターの停止の可能性に 処するために、必要に じて処理をヒキ尽くスタンバイマスターを設定することができ
ます。詳細は、「スタンバイマスターの設定」を参照してください。
マスタ ー が復 した場合
ピアは引き続きハートビートを送信しているため、マスターが復 すると、それを 出して再接続することができま
す。
マスターが復 すると、ピアが登 できるように 60 秒間待機します。この期間が 過すると、マスターはピアノード
やバケツの状態を含めた、クラスタの全状態を把握します。最低でも複製データ保持数だけのピアが登 されてい
る場合、クラスタを有効で完全な状態にするために、マスターはバケツの修復に必要な作業を開始します。さら
に、必要に じて世代 ID も更新します。
このアクティビティが完了するまでには、ある程度の時間がかかります。特に、バケツのサーチ不可コピーをサー
チ可に 換する処理には時間がかかります (特にピアノードが大量のデータを処理しなければならない場合)。サー
チ不可コピーをサーチ可に 換するためにかかる時間の見積もりについては、ここを参照してください。
最初の 60 秒間が 過すると、マスターダッシュボードでクラスタのステータスを確認することができます。
注意：マスターを再起動する場合は、複製データ保持数以上のピアが稼働していることを確認する必要がありま
す。
103

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

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

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

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

Splunk Enterprise

日本ジャンボー、日本 HP との協業第二弾

HCI International 2003 参加報告

ピボットマニュアル - Splunk Docs