Splunk Enterprise 6.2.0 分散デプロイマニュアル 作成：2014 年 11 ⽉ 21 ⽇ 午後 4 時 10 分 Copyright (c) 2015 Splunk Inc. All Rights Reserved Table of Contents 概要 分散 Splunk Enterprise の概要 Splunk Enterprise 内でのデータの移動：データパイプライン デプロイ環境の拡張：Splunk Enterprise コンポーネント コンポーネントと役割 分散デプロイ環境の導⼊ 3 3 6 8 9 10 このマニュアルの残りの部分について データの転送 分散サーチ ハードウェアのキャパシティ・プランニング Splunk Enterprise インスタンスのアップグレード 12 12 12 12 12 共通のデプロイアーキテクチャ 共通のデプロイアーキテクチャの概要 デプロイのトポロジー デプロイ環境の拡張 12 12 12 17 デプロイ環境のアップグレード 分散環境のアップグレード Windows ユニバーサルフォワーダーのアップグレード *nix システムのユニバーサルフォワーダーのアップグレード 18 18 21 21 概要 分散 Splunk Enterprise の概要 このマニュアルは、複数のマシンへの各種 Splunk Enterprise 機能コンポーネントの分散⽅法について記述して います。Splunk Enterprise を分散することで、あらゆる規模の企業のデータニーズやその複雑性に対処すること が可能になります。 単⼀マシンのデプロイ環境では、1 つの Splunk Enterprise インスタンスがデータ⼊⼒からサーチ⽤インデック スの作成まで、すべての処理を担当します。単⼀マシンデプロイ環境は、テスト/評価⽬的での利⽤に役⽴ち、ま た部⾨規模の環境におけるニーズを満たすことができるでしょう。ただし、多数のマシンからデータが到着し、多 数のユーザーがデータをサーチする必要があるような⼤規模環境の場合は、複数の Splunk Enterprise インスタ ンスにまたがって機能を分散することもできます。このマニュアルは、そのような分散環境への Splunk Enterprise のデプロイおよび使⽤⽅法について説明しています。 Splunk Enterprise 環境の拡張 Splunk Enterprise では、データパイプライン 内をデータが通過していくにつれて、主に 3 つの処理が⾏われま す。まず、ファイルやネットワークなどからデータを取り込み ます。次にデータのインデックスを作成 しま す。(実際にはまず最初にデータを解析してから、次にインデックスを作成しますが、ここでは解析もインデック ス作成処理の⼀部とみなして説明していきます。)最後に、インデックスが作成されたデータ (インデックス データ) に対してサーチを実⾏ (対話型またはスケジュールによる) します。 この処理 (機能) を、複数の Splunk Enterprise インスタンスに分割して割り当てることができます。処理対象の データ量や環境の要因に応じて、数台から数千台もの規模で機能を分散させることが可能です。たとえば、データ の取り込みのみを⾏う数台のインスタンス、データのインデックスを作成する数台のインスタンス、そしてサーチ リクエストを処理する 1 台または複数台のインスタンスで構成されるデプロイ環境を構築することができます。 これらの専⾨のインスタンスは総合的にコンポーネント と呼ばれています。コンポーネントにはいくつかのタイ プがあります。 たとえば、⼀般的な中規模デプロイ環境では、データの起源となるマシン上にフォワーダー と呼ばれる軽量版の Splunk Enterprise を導⼊することができます。フォワーダーはさまざまなデータを取り込んで、ネットワーク経 由でそのデータをインデクサー と呼ばれる他の Splunk Enterprise コンポーネントに転送します。インデクサー は負荷のかかる仕事を担当しています。データのインデックスを作成し、サーチを実⾏します。インデクサーはマ シン上に単独で常駐する必要があります。⼀⽅、データ取り込み処理はマシンのパフォーマンスに与える影響が少 ないため、フォワーダーはデータを⽣成するマシン上に共存させることができます。以下の図は、複数のフォワー ダーが単⼀のインデクサーにデータを送信する環境を表しています。 環境の規模を拡張するために、さらにフォワーダーやインデクサーを追加していくことができます。⼤規模なデプ ロイ環境では、数百台ものフォワーダーを設置して、複数台のインデクサーにデータを送信するようなこともあり ます。フォワーダー上でロードバランシングを⾏い、データを⼀部またはすべてのインデクサーに分散させること 3 ができます。ロードバランシングは環境の規模を拡張するために役⽴つだけでなく、あるインデクサーが停⽌した 時のフェイルオーバーに利⽤することもできます。この場合フォワーダーは⾃動的にデータの送信先を、残りの稼 働中のインデクサーに切り替えます。以下の図では、各フォワーダーが 2 台のインデクサーに対してデータの ロードバランシングを⾏っています。 複数のインデクサーにまたがるサーチアクティビティを管理/統合するために、インデックス機能とサーチ機能を 分離することもできます。このようなデプロイ環境は「分散サーチ 」環境と呼ばれており、各インデクサーは データのインデックスを作成し、⾃⼰が保有するインデックスのサーチを実⾏します。サーチヘッド はサーチ管 理 を専⾨とする Splunk Enterprise インスタンスで、⼀連のインデクサーにまたがってサーチ処理を調整し、そ の結果を統合してユーザーに表⽰します。 4 ⼤規模環境の場合、設定、ジョブ・スケジュール、および過去のサーチ結果を共有する複数のサーチヘッドで構成 される、サーチヘッド・クラスタ をデプロイできます。3 台のサーチヘッドで構成される、⼩規模なサーチヘッ ド・クラスタの図を以下に⽰します。 これらの図は、基本的なデプロイトポロジーを表しています。実際にはデータ取り込み、インデックス作成、およ びサーチ機能を、さまざまな組み合わせで利⽤することができます。たとえば、指定した条件に基づいて、複数の インデクサーにデータを転送するようにフォワーダーを設定することができます。また、ローカルにデータを処理 してから、他のインデクサーにそれを転送して保管するようにフォワーダーを設定することもできます。さらに、 サーチヘッドとインデクサーの両⽅の役割を果たす単⼀のインスタンスを導⼊し、⾃⼰のインデックスだけではな く他のインデクサーのインデックスもサーチするように設定することも可能です。必要に応じていろいろな⽅法で Splunk Enterprise を組み合わせて使⽤することができます。さまざまな状況に応じて柔軟に活⽤することができ ます。 このマニュアルは、単⼀の部⾨のデータを管理する場合から全社規模でデータを管理するような場合まで、さまざ まなニーズに応じたデプロイ環境の構築⽅法について説明しています。 5 データ可⽤性を⽬的にしたインデクサー・クラスタの使⽤ インデクサー・クラスタは、相互のデータを複製するように設定された Splunk Enterprise インデクサーのグ ループです。このプロセスは、インデックスレプリケーション として知られています。クラスタは Splunk Enterprise データの複数の同⼀コピーを保持することにより、データ消失を防⽌しながら、サーチ⽤データの可 ⽤性を向上します。 Splunk Enterprise のクラスタ機能では、あるインデクサーから別のインデクサーに⾃動フェイルオーバーを⾏い ます。つまり、1 つまたは複数のインデクサーに障害が発⽣した場合でも、引き続き到着データのインデックスが 作成され、サーチが可能になります。 クラスタは単純にデータの可⽤性を向上するだけではありません。デプロイ環境を構築、拡張する際に検討する必 要がある、その他の主要機能も提供しています。たとえば、クラスタ内のすべてのインデクサーにまたがって、設 定を管理して、⼿軽に更新する機能が⽤意されています。また、分散サーチ機能も内蔵されています。インデク サー・クラスタの詳細は、『インデクサーとクラスタの管理』の「クラスタとインデックス・レプリケーションに ついて」を参照してください。 Splunk Enterprise デプロイの管理 Splunk Enterprise には、分散デプロイ環境の管理に役⽴ついくつかのツールが⽤意されています。 デプロイサーバー ：このコンポーネントは、デプロイ環境全体の設定を集中管理して、その内容を更新する ための⼿段を提供しています。詳細は、『Splunk Enterprise インスタンスの更新』マニュアルの「デプロ イ・サーバーについて」を参照してください。 分散管理コンソール ：この機能は、デプロイ環境の管理とトラブルシューティングに役⽴ちます。『管理 マニュアル』の「分散管理コンソールの設定」を参照してください。 次に説明する項⽬ この概要セクションの残りの部分では、以下の事項について説明しています。 Splunk Enterprise 内でのデータの移動：データパイプライン デプロイ環境の拡張：Splunk Enterprise コンポーネント コンポーネントと役割 まず、Splunk Enterprise にデータが取り込まれた時点から、ユーザーがサーチできる状態になるまでの流れとな る、データパイプラインの説明を⾏います。次に、Splunk Enterprise の各種機能をモジュール構成のコンポーネ ントに分離する⽅法について説明します。また、データパイプラインの処理を円滑に実施するための、利⽤可能な Splunk Enterprise コンポーネントとその役割の関係についても取り上げていきます。 このマニュアルの残りのセクションでは、Splunk Enterprise コンポーネントを使った分散 Splunk Enterprise デプロイ環境の構築⽅法などの、コンポーネントの詳細について説明していきます。 デプロイ環境の規模に基づいたキャパシティ・プランニングについては、『キャパシティ・プランニング』マニュ アルを参照してください。 Splunk Enterprise 内でのデータの移動：データパイプライン Splunk Enterprise 内のデータは、ログファイルやネットワークフィードなどのソースからデータパイプライン内 を通過して、貴重なナレッジを内包したサーチ可能イベントに変換されるまで、さまざまなフェーズを経て処理が ⾏われます。データパイプライン には、以下のセグメントが含まれています。 ⼊⼒ パーシング処理 インデックス作成 サーチ ここで説明するように、これらの各セグメントを異なる Splunk Enterprise インスタンスに割り当てることがで きます。 データパイプラインの概要を以下の図に⽰します。 6 「デプロイ環境の拡張」で説明するように、Splunk Enterprise インスタンスはデータパイプラインの 1 つまた は複数のセグメントに関与します。 注意： この図は、インデックス作成アーキテクチャの簡単なビューを表しています。これは、アーキテクチャを 機能的に表したもので、Splunk Enterprise の内部動作を完全に表している訳ではありません。特に、パーシング パイプラインは、実際にはパーシング 、マージング 、およびタイピング の 3 つのパイプラインで成り⽴ってお り、これらが連携してパーシング機能を担当しています。このような区別はトラブルシューティングの際に関係し てきますが、⼀般的な Splunk Enterprise の設定やデプロイには何も影響することはありません。 ⼊⼒ Splunk Enterprise は⼊⼒セグメントでデータを取り込みます。Splunk はソースから raw データを取得して、そ れを 64K のブロックに分割し、各ブロックにいくつかのメタデータキーを追加します。このキーは、⼊⼒ソース 全体に適⽤されます。これには、データのホスト 、ソース 、およびソースタイプ が含まれます。キーには、デー タストリームの⽂字エンコード、データの後処理を制御する値 (イベントを保管するインデックスなど) などの、 Splunk Enterprise が内部的に使⽤する値を含めることも可能です。 このフェーズで Splunk Enterprise はデータストリームの内容には注⽬しないため、キーは個別のイベントでは なくソース全体に適⽤されます。実際、この時点で Splunk Enterprise は個別のイベントに対して何の考察も ⾏っていません。特定のグローバルプロパティを持つデータストリームとして処理しているだけです。 パーシング処理 セグメントのパーシング中、Splunk Enterprise はデータの調査、分析、および変換を⾏います。これは、イベ ント処理 としても知られています。このフェーズ中にデータストリームが個別のイベントに分割されます。パー シングフェーズには、さまざまなサブフェーズが存在しています。 データストリームの個別の⾏への分割。 識別、パーシング、およびタイムスタンプの設定。 個別のイベントへの、ソースキーからコピーされたメタデータの追加。 Splunk Enterprise 正規表現変換ルールによる、イベントデータとメタデータの変換。 7 インデックス作成 インデックス作成時には、解析されたイベントが取得され、それがディスク上のインデックスに書き込まれます。 圧縮された raw データと対応するインデックスファイルの両⽅が書き込まれます。 単純化するために、パーシングとインデックス作成はまとめてインデックス作成プロセスと呼ばれます。⼀般的に はそれでも⼗分です。しかし、実際のデータ処理を詳しく⾒る場合は、これらの 2 つの⼿続きを個別に考慮する 必要があります。 インデックス作成パイプラインの詳細を表した図とインデックス作成の仕組みについては、Community Wiki の 「How Indexing Works」を参照してください。 サーチ Splunk Enterprise のサーチ機能は、対話型サーチとスケジュール済みサーチ、レポートとグラフ、ダッシュボー ド、アラートを含め、インデックス作成されたデータをユーザーが参照、使⽤するために必要なあらゆる側⾯を管 理しています。サーチ機能の⼀環として、Splunk Enterprise はユーザーが作成したナレッジオブジェクト を保 存します。 パイプライン内の各ステップの詳細は、『インデックスとクラスタの管理』マニュアルの「インデックス作成の仕 組み」を参照してください。 デプロイ環境の拡張：Splunk Enterprise コンポーネント デプロイトポロジーとパフォーマンス要件を満たすために、Splunk Enterprise インスタンスを区別し、データ⼊ ⼒やインデックス作成などのそれぞれが担当する役割を割り当てることができます。たとえば、データの取り込み のみを⾏うインスタンスを⽤意することができます。取り込んだデータは、インデックス作成を担当する他のイン スタンスに転送します。また、インデックス作成を複数のインスタンスに分散させて、各インスタンスにサーチリ クエストを処理させることもできます。このような役割分担を容易にするために、いろいろなコンポーネント タ イプを組み合わせて、各インスタンスに 1 つまたは複数の役割を割り当てることができます。これらのコンポー ネントの⼤半は、完全版インスタンスの特定の機能を有効化/無効化することで作成できます。 分散環境では、以下のコンポーネントタイプを利⽤できます。 インデクサー フォワーダー サーチヘッド デプロイサーバー これらのコンポーネントは完全版 Splunk Enterprise インスタンスのバリエーションで、特定の機能が有効また は無効になっています。ただし、ユニバーサルフォワーダー は例外で、独⾃の実⾏形式ファイルを使⽤していま す。 インデクサー インデクサーは、インデックスの作成と管理を⾏う Splunk Enterprise コンポーネントです。インデクサーの主 な機能を以下に⽰します。 到着データのインデックス作成。 インデックスデータのサーチ。 1 つの Splunk Enterprise インスタンスからのみ構成される単⼀マシン環境では、データの取り込み およびサー チ管理 機能もインデクサーが担当します。 ⼤規模環境でのニーズに合わせて、インデックス作成処理をデータの取り込み機能や、必要に応じてサーチ管理機 能からも切り離すことができます。このような⼤規模な分散環境では、インデクサーはしばしば独⾃のマシン上に 常駐し、そのインデックスデータのサーチとともにインデックス作成 (通常はパーシングも含む) 処理のみを担当 します。このような場合、インデックス作成/サーチ以外の処理は他の Splunk Enterprise コンポーネントが担当 します。フォワーダー がデータを取り込んで、インデクサーがデータのインデックス作成とサーチを⾏い、サー チヘッド がインデクサー全体のサーチを調整します。 インデクサーの詳細は、『インデクサーとクラスタの管理』マニュアルの「インデックスとインデクサーについ て」を参照してください。 フォワーダー 通常インデクサーとは別の役割が担当する作業として、データの取り込みが挙げられます。たとえば、データを⽣ 成する Windows および Linux マシンのグループが存在しており、それらのイベントを単⼀の Splunk Enterprise インデクサーに送って集中処理する場合を考えてみましょう。⼀般的にこれを実現するための最良の ⽅法は、フォワーダー として知られる軽量の Splunk Enterprise インスタンスを、データを⽣成する各マシン上 にインストールすることです。これらのフォワーダーはデータ⼊⼒を管理し、結果となるネットワーク上のデータ ストリームを専⽤のマシンに常駐する Splunk Enterprise インデクサーに送信します。2 種類のフォワーダーが 存在しています。 ユニバーサルフォワーダー： 処理負荷が⾮常に低く、パーシングされていないデータのみを転送します。 ヘビーフォワーダー： 処理負荷が多少⾼くなりますが、データを転送する前にパーシングやインデックス 作成処理を⾏うことも可能です。 フォワーダーの詳細は、『データの転送』マニュアルの「転送と受信について」を参照してください。 サーチヘッド 8 ⼤量のインデックスデータが存在しており、それに多数のユーザーが同時にサーチを実⾏するような環境では、イ ンデックス作成の負荷を複数のインデクサーに分散し、またサーチクエリー機能を別個のマシンに担当させること を検討してください。このような分散サーチ環境 では、1 つまたは複数のサーチヘッド と呼ばれている Splunk Enterprise コンポーネントが、サーチリクエストを複数のインデクサーに分配します。 サーチヘッドの詳細は、『分散サーチ』マニュアルの「分散サーチについて」を参照してください。 デプロイサーバー 分散デプロイ環境を更新するために、Splunk Enterprise のデプロイサーバー を使⽤することができます。デプ ロイサーバーを利⽤して、設定やそのコンテンツを⼀連の Splunk Enterprise インスタンス (デプロイクライア ント ) に配布することができます。デプロイクライアントは、OS、マシンタイプ、アプリケーション、場所など の、任意の基準でグループ化することができます。通常デプロイクライアントは、フォワーダーまたはインデク サーです。たとえば、ローカルの Linux フォワーダーで設定を変更し、正常に機能することを確認したら、デプ ロイ環境内の各 Linux フォワーダーに変更した設定を配布することができます。 デプロイ環境が⼩さい場合 (約 50 未満のデプロイクライアント)、デプロイサーバーは、他の Splunk Enterprise コンポーネントの役割を果たすインスタンス (サーチヘッドまたはインデクサー) と共存することができます。⼤ 規模なデプロイ環境では、独⾃の Splunk Enterprise インスタンス上で動作させる必要があります。詳細は、 『Splunk Enterprise インスタンスの更新』マニュアルの「デプロイサーバーのパフォーマンス⾒積もり」を参照 してください。 デプロイサーバーの詳細は、『Splunk Enterprise インスタンスの更新』マニュアルの「デプロイサーバーについ て」を参照してください。 次のトピック 分散環境の規模や性質に関係なく、インデックス作成とイベント処理 に関する問題の基本は同じですが、イン デックス作成戦略を策定する際には、デプロイ環境のニーズを検討することが重要です。この作業を効果的に⾏う ためには、コンポーネントと Splunk Enterprise の役割の対応についても理解しておく必要があります。 デプロイ環境のハードウェア要件については、『キャパシティ・プランニング』マニュアルを参照してください。 コンポーネントと役割 データパイプライン 内の各セグメントが、1 つまたは複数の Splunk Enterprise コンポーネント が担当する役 割に直接対応しています。たとえば、データの取り込みが Splunk Enterprise の役割になります。データの取り 込みは、インデクサーまたはフォワーダーが実施できます。データパイプラインの詳細は、ここを参照してくださ い。 データパイプラインでの各コンポーネントの動作 パイプライン内の各セグメントと、それに対応する役割を実⾏する Splunk Enterprise コンポーネントを以下の 表に⽰します。 データパイプラインのセグメント 役割 この役割を担当できるコンポーネント データの取り込み データの取り込み インデクサー ユニバーサルフォワーダー ヘビーフォワーダー パーシング処理 パーシング処理 インデクサー ヘビーフォワーダー インデックス作成 インデックス作成 インデクサー サーチ サーチ インデクサー サーチヘッド N/A 分散環境更新の管理 デプロイサーバー 表に記載のように、いくつかの役割は状況に応じて別のコンポーネントに担当させることができます。たとえば、 データの取り込みを単⼀マシンのデプロイ環境ではインデクサーに担当させ、より⼤規模な環境ではフォワーダー に担当させることが可能です。 コンポーネントの詳細は、ここを参照してください。 コンポーネントの動作 Splunk Enterprise 機能を分散、管理するために、いくつかの⼀般的な⽅法が存在しています。 インデクサーへのデータ転送 ここで取り上げるデプロイ環境では、データの取り込みをフォワーダー が担当し、収集したデータを Splunk Enterprise インデクサーに送信しています。フォワーダーは、2 種類に分類できます。 ユニバーサルフォワーダー： これらは、各⾃のホストマシンでリソースの消費量が少なくなっています。 到着したデータストリームに対して最低限の処理を⾏ってから、それをインデクサー (レシーバー ) に転送 します。 ヘビーフォワーダー： これらは、完全な Splunk Enterprise インスタンスの⼤部分の機能を保有していま す。インデクサーにデータを転送する前に、パーシングを⾏うことができます。(パーシングとインデックス 作成の違いについては、「Splunk Enterprise 内でのデータの移動」を参照してください。) 9 どちらの種類のフォワーダーでも、インデクサーにデータを転送する前に、ホスト、ソース、ソースタイプなどの メタデータでデータにタグを設定します。 フォワーダーにより、⼤量のデータまたは多彩な種類のデータを処理しながら、リソースを効率的に使⽤すること ができます。また、ロードバランシング 、データのフィルタリング 、およびルーティング などの機能により、 さまざまなデプロイトポロジを採⽤することができます。 設定や使⽤事例も含めたフォワーダーの詳細については、『データの転送』マニュアルの「転送と受信について」 を参照してください。 複数インデクサーに対するサーチ 分散サーチ では、Splunk Enterprise インスタンスはサーチリクエストを他の Splunk Enterprise インスタンス に送信し、結果を結合してユーザーに提供します。これは、⽔平スケーリング、アクセス制御、および地理的に分 散したデータの管理など、さまざまな⽬的に役⽴ちます。 サーチ結果を管理する Splunk Enterprise インスタンスは、サーチヘッドと呼ばれます。インデックスを管理 し、実際のサーチを実⾏するインスタンスはインデクサーで、その意味ではサーチピア とも呼ばれています。 設定や使⽤事例も含めた分散サーチの詳細については、『分散サーチ』マニュアルの「分散サーチについて」を参 照してください。 分散環境更新の管理 多数のフォワーダー、インデクサー、およびサーチヘッドで構成される分散デプロイ環境を管理する場合、 Splunk Enterprise のデプロイサーバーを利⽤すると Splunk Enterprise コンポーネント (主にフォワーダーとイ ンデクサー) の設定と更新作業が簡単になります。デプロイサーバーを使⽤することで、共通の特徴に基づいてコ ンポーネント (デプロイクライアント ) をサーバークラス にグループ化して、更新ファイルを配布することがで きます。 サーバークラスは、設定を共有している⼀連の Splunk Enterprise インスタンスです。⼀般的にサーバークラス は OS、マシンタイプ、アプリケーション、場所、またはその他の基準でグループ化されます。単⼀のデプロイク ライアントが複数のサーバークラスに所属することができます。たとえば、英国に設置されている Linux ユニ バーサルフォワーダーが、サーバークラス Linux とサーバークラス UK に所属して、それぞれのクラスから適切 な設定を受信することができます。 デプロイ環境管理の詳細は、『Splunk Enterprise インスタンスの更新』マニュアルの「デプロイサーバーについ て」を参照してください。 その他の参考情報 これらが Splunk Enterprise 分散環境の基盤となるコンポーネントおよび機能となります。 インデクサー： 『インデクサーとクラスタの管理』マニュアルの「インデックスとインデクサーについて」 を参照してください。 フォワーダー： 『データの転送』マニュアルの「転送と受信について」を参照してください。 サーチヘッド： 『分散サーチ』マニュアルの「分散サーチについて」を参照してください。 デプロイサーバー： 詳細は、『Splunk Enterprise インスタンスの更新』マニュアルの「デプロイサーバー について」を参照してください。 Splunk Enterprise の各種設定については、『管理マニュアル』の「パラメータとデータパイプラインの設定」を 参照してください。このトピックには、主要な設定とそれが影響するデータパイプラインのセグメントについての 説明が記載されています。Splunk Enterprise トポロジー内のどのコンポーネントが、データパイプライン内のど のセグメントを担当しているのか分かっている場合は、このトピックを参考にどこで設定を⾏うのかを判断するこ とができます。たとえば、サーチセグメントの担当にサーチヘッドを使⽤している場合、サーチ関連の設定はイン デクサーではなくサーチヘッド上で⾏う必要があります。 分散デプロイ環境の導⼊ ここでは、以下のような複層分散環境を導⼊するための、⾼レベルのフレームワークを説明しています。 10 このような分散環境を導⼊するには、3 種類のコンポーネントをインストール、設定する必要があります。 インデクサー フォワーダー (⼀般的にはユニバーサルフォワーダー) サーチヘッド インデクサーのインストールと設定 デフォルトで、Splunk Enterprise インスタンスはすべてインデクサーとしての役割を果たします。⽔平⽅向ス ケーリングでは、個別のマシンに複数のインデクサーをインストールすることができます。 Splunk Enterprise インスタンスのインストール⽅法については、『インストール・マニュアル』を参照してくだ さい。 インデクサーを設置したら、『インデクサーとクラスタの管理』マニュアルで、環境ニーズに応じた設定⽅法を学 習してください。 フォワーダーからデータを受信するためのインデクサーの設定については、『データの転送』マニュアルの「レ シーバーを有効にする」を参照してください。また、インデクサーが⼀部のデータをフォワーダーを介さずに取り 込んでいる場合は、『データの取り込み』マニュアルでデータの取り込みの設定⽅法を学習してください。このト ピックの図は、ファイアウォールからとデータルーターからの、2 つのデータを直接取り込んでいる例を表してい ます。 データの可⽤性、データの忠実度、およびデータの復元がデプロイ環境の主⽬的である場合は、⼀連のインデク サーではなくインデクサー・クラスタのデプロイを検討する必要があります。詳細は、『インデクサーとクラスタ の管理』の「インデクサー・クラスタとインデックスレプリケーションについて」を参照してください。 フォワーダーのインストールと設定 ⼀般的な分散デプロイ環境には、多数のフォワーダーが少数のインデクサーにデータを供給しています。たいてい の場合は、ユニバーサルフォワーダーを利⽤するのが最適です。ユニバーサルフォワーダーは、Splunk Enterprise とは別個にダウンロードすることができます。 フォワーダーのインストール、設定⽅法については、『データの転送』マニュアルを参照してください。 次に『データの取り込み』マニュアルで、各フォワーダーのデータ取り込みの設定⽅法を学習してください。 サーチヘッドのインストールと設定 分散サーチのニーズに合わせて、1 つまたは複数のサーチヘッドをインストールすることができます。サーチヘッ ドは複数のインデクサーのサーチを管理するように設定された Splunk Enterprise インスタンスです。ユーザー はサーチヘッドの Splunk Web に接続して、サーチを実⾏します。 サーチヘッドの詳細は、『分散サーチ』マニュアルを参照してください。 その他のデプロイ作業 11 ライセンスマスター を指定して、Splunk Enterprise ライセンスを設定する必要があります。詳細は、『管理マ ニュアル』の「Splunk Enterprise ライセンスの設定 」を参照してください。 Splunk Enterprise のデプロイサーバー を使って、デプロイコンポーネントの更新作業を簡素化することができ ます。デプロイ・サーバーの設定⽅法の詳細は、『Splunk Enterprise インスタンスの更新』マニュアルを参照し てください。 このマニュアルの残りの部分について データの転送 Splunk 6.0 では、以前はこのマニュアルに記載されていたデータの転送と受信に関するトピックが、独⾃のマ ニュアル『データの転送』に移動されました。 分散サーチ Splunk 6.0 では、以前はこのマニュアルに記載されていた分散サーチとサーチヘッドに関するトピックが、独⾃ のマニュアル『分散サーチ』に移動されました。 ハードウェアのキャパシティ・プランニング Splunk 6.2 から、以前はこのマニュアルに記載されていたハードウェアのキャパシティ・プランニングに関する トピックが、独⾃のマニュアル『キャパシティ・プランニング』に移動されました。 Splunk Enterprise インスタンスのアップグレード デプロイサーバーは、Splunk Enterprise インスタンスをアップグレードするための、Splunk Enterprise 内蔵の 機能です。 Splunk 6.0 以降では、以前はこのマニュアルに記載されていたデプロイサーバーに関するトピックが、独⾃のマ ニュアル『Splunk Enterprise インスタンスのアップグレード』に移動されました。 共通のデプロイアーキテクチャ 共通のデプロイアーキテクチャの概要 この章は、さまざまな規模のデプロイ環境に共通するアーキテクチャの種類について説明しています。ここの説明 は、初期要件および将来的な要件を正しく理解するために役⽴ちます。また、新たなデプロイ環境のニーズの判断 および既存の Splunk Enterprise デプロイ環境の拡張準備にも役⽴ちます。⼀般的な Splunk Enterprise デプロ イ環境の規模や利⽤⽅法における成⻑と進化についても記載されています。 Splunk Enterprise のデプロイ環境は、⽇あたり数ギガバイト程度のデータのインデックスを作成し、数⼈のユー ザーしかデータにアクセスしない部⾨規模の単⼀サーバー構成から、数テラバイトのデータのインデックスを作成 し、数百⼈ものユーザーがサーチを実⾏する、複数のデータセンターに分散された⼤規模な企業レベルの構成まで 多岐に渡ります。 この章では、いくつかの典型的なデプロイ環境 (規模別に分類) について、以下のような事項を説明していきま す。 コンポーネントのタイプと数 ユーザーのタイプと数 データサイズと取り込みタイプ 設計上の検討事項 可⽤性、回復可能性、アクセス性、および設定管理などの、基本的な管理上の問題 スタッフの要件 デプロイのトポロジー ここでは、プランニングに役⽴つ、規模に応じた代表的なトポロジーについて説明していきます。 部⾨規模 ⼩規模企業 中規模企業 ⼤規模企業 これらの分類は⼤まかに規模を定めたもので、単⼀サーバー構成から多数のユーザーが使⽤する全社規模の構成ま でさまざまな構成で構築することが可能です。 また、このトピックにはインデクサー・クラスタのトポロジに関する簡単な説明も記載されています。インデク サー・クラスタは、任意の企業レベルに導⼊することができます。 注意： 「⼩企業」、「中企業」、「⼤企業」などは、厳密に企業の規模を定義したものではありません。どちら かと⾔えば企業内でどれだけの数/種類の Splunk 機能を使⽤し、どれだけ複雑な利⽤⽅法を採⽤するかを⽬安に しているとお考えください。Splunk は企業の成⻑に従って、引き続き成功を収めるための価値を提供していくこ とができます。また⼀般的には成⻑に伴って、デプロイ環境の規模も⼤きくなっていきます。たとえば、ある Fortune 500 社が部⾨レベルで特定の使⽤事例に限定される単⼀サーバー Splunk 構成で利⽤を開始し、その後 12 ⼩企業から中企業、そして⼤企業へと成⻑するにつれて、⼤企業のデプロイ環境を採⽤し、全社規模の分散環境を 構築していくことができます。 部⾨規模 部⾨規模のデプロイ環境は、⽂字通り組織内の単⼀部⾨の⽐較的簡単なニーズを満たすための構成です。⼀般的に このようなデプロイ環境は、以下のようになっています。 単⼀の Splunk インスタンス、インデクサーとサーチヘッドの両⽅の役割を果たします。 インデックス作成量が 20GB/⽇以下。 データをインスタンスに送信する⽐較的少数 (⼀般的には 10 台未満で 100 台を超えることはほとんどない) のフォワーダー。 更新は⼿動で、またはインデクサーに常駐するデプロイサーバーにより⾏われます。 ユーザー数は⽐較的少なく、⼀般的には 10 ⼈以下です。 部⾨規模のデプロイ環境のコンポーネントを以下の図に⽰します。 ⼩規模企業 ⼩企業デプロイ環境は、Splunk デプロイ環境の成⻑における次の段階で、ある程度の⽔平スケーリングを提供し ています。⼀般的にこのようなデプロイ環境は、以下のようになっています。 複数のSplunk インスタンス、たとえば 2〜3 台のインデクサーとユーザーがすべてのインデクサーに対し てまとめてサーチを実⾏するための、単⼀のサーチヘッドで構成されています。 インデックス作成量が 20〜100GB/⽇。 最⾼で数百台のフォワーダーがインデクサーにデータを供給します。⼀般的にフォワーダーはロードバラン シングを利⽤して、複数のインデクサーにデータを分散します。 更新は⼿動で、またはサーチヘッドに常駐するデプロイサーバーにより⾏われます。 ユーザー数は多いですが、⼀般的には 100 ⼈未満です。 ⼩企業のデプロイ環境のコンポーネントを以下の図に⽰します。 13 中規模企業 中企業のデプロイ環境は、Splunk デプロイ環境の成⻑曲線の中間で、⽔平スケーリングの度合いが⾼くなってい ます。⼀般的にこのようなデプロイ環境は、以下のようになっています。 多数のSplunk インスタンス (例：5 台以上のインデクサーと 2 台のサーチヘッド)。 インデックス作成量が 100〜300GB/⽇。 最⾼で数千台のフォワーダーがロードバランシングでインデクサーにデータを供給。 更新ファイルは、設定管理ツール (スタンドアロンのデプロイサーバーまたは Puppet や Chef などのサー ドパーティ製ツール) で管理します。 多数のユーザー (数百⼈またはそれ以上)。 中企業のデプロイ環境のコンポーネントを以下の図に⽰します。 ⼤規模企業 14 ⼤企業デプロイ環境は、全社的にデータを処理して、複数のデータセンターにまたがる場合もあります。⼀般的に このようなデプロイ環境は、以下のようになっています。 多数の Splunk インスタンス (例：数⼗台のインデクサーと 10 台のサーチヘッド)。 インデックス作成量が 300GB〜数 TB/⽇ 数千台のフォワーダー。 更新ファイルは、設定管理ツール (スタンドアロンのデプロイサーバーまたは Puppet や Chef などのサー ドパーティ製ツール) で管理します。 多数のユーザー (数百⼈)。 ⼤企業のデプロイ環境のコンポーネントを以下の図に⽰します。 インデクサー・クラスタ 前述のトポロジーはインデックス・レプリケーションには対応していませんが、要件に応じて任意の企業レベルの トポロジーにインデクサー・クラスタを導⼊することができます。そのためには、後述する Splunk Enterprise インスタンス数よりもインスタンス数を増やす必要があります。⼩規模企業デプロイ環境のインデクサー・クラス タ・トポロジーの例を以下に⽰します。 15 ⼩規模なインデクサー・クラスタの例を以下に⽰します。このクラスタには 3 台のピアノード (インデクサー) が 存在し、複製データ保持数は 3 となっています。複製データ保持数 3 は、すべてのデータが 3 台すべてのピアに またがって複製されることを意味しているため、基本的にこのシナリオは 1 台または 2 台のインデクサーを保有 する、⾮常に⼩規模な企業の例に代わるものです。クラスタのデータ保管⽅法では、⾮クラスタ構成の場合と⽐べ てデータ量が厳密に 3 倍になる訳ではありません。 図で分かるように、クラスタ構成でも⾮クラスタ構成と同じように、必要に応じてピアやフォワーダーを追加して デプロイ環境を拡張していくことができます。また、サーチヘッドを追加することもできます。 詳細は、『インデクサーとクラスタの管理』の「インデクサー・クラスタとインデックス・レプリケーションにつ いて」を参照してください。 サーチヘッド・クラスタ サーチヘッド・クラスタで、複数のサーチヘッドをまとめることができます。そうすることにより、各サーチヘッ ドが設定、ジョブ・スケジュール、および過去のサーチ結果を共有することができます。インデクサー・クラスタ のように、サーチヘッド・クラスタも任意の企業レベルのトポロジーに導⼊することができます。⽐較的⼩規模な サーチヘッド・クラスタの例を以下に⽰します。 16 このクラスタはロードバランシングを⾏う 3 台のサーチヘッドで構成されており、ユーザーからのリクエストや インデックス・データを持つ複数台のサーチ・ピアを管理しています。『分散サーチ』マニュアルの「サーチヘッ ド・クラスタリングについて」を参照してください。 デプロイ環境の拡張 デプロイ環境の特徴は、その規模によって異なります。(ここで説明するデプロイ環境の規模とは、⽇次インデッ クス作成量に基づいています。)このトピックは、デプロイ環境の主な特徴と検討事項、およびデプロイ環境の拡 張に伴う変化について説明していきます。 注意： 規模は、デプロイ環境のニーズとアーキテクチャに影響する数多くの要素の 1 つにしか過ぎません。これ らの表に記載されている数字は、単なるプランニングのためのガイドラインです。また、ここで取り上げているシ ナリオは、規模に基づく連続的な成⻑についてのみを表しています。実際の値は、各デプロイ環境の特性によって ⼤幅に異なります。 ハードウェアのキャパシティ・プランニングとデプロイ環境の規模については、『キャパシティ・プランニング』 マニュアルを参照してください。 主な特徴 デプロイ環境の特徴は、その規模の成⻑に伴い変化していきます。この表はその予測と、デプロイ環境の変化に伴 いニーズを満たすために必要となる Splunk コンポーネントに関する情報を表しています。 部⾨規模 ⼩規模企業 中規模企業 ⼤規模企業 インデックス作成量 (⽇ 次) 0〜20GB 20〜100GB 100〜300GB 300GB〜1TB 超 フォワーダー数 中央値 10 台未 満、最⼤ 100 台 中央値は 10 台程 度、最⼤値は 100 台程度。 中央値は 10 台程 度、最⼤値は数千台 前半。 中央値は 10 台程 度、最⼤値は 1000 台程度。 ユーザー数 中央値 10 未満 中央値は 10 ⼈台 程度 中央値は 10 ⼈台程 度、最⼤値は 100 ⼈ 台前半。 中央値は 10 ⼈台 程度、最⼤値 500 ⼈台超。 App 数 (同梱および独⾃ 1〜10 開発の両⽅) 1〜10 1〜20 以上 10〜50 インデクサーコンポーネ ント 1 台のインデク サー 2〜3 台のインデ クサー 4〜9 台のインデク サー 10 台以上のインデ クサー サーチヘッドコンポーネ ント インデクサーと 兼務 1 台のスタンドア ロンサーチヘッド 2 台のサーチヘッド 3 台以上のサーチ ヘッド 設定管理機能 ⼿動設定または デプロイサー バー ⼿動設定またはデ プロイサーバー デプロイサーバーま たはサードパーティ 製ツール デプロイサーバー またはサードパー ティ製ツール 設計上の検討事項 この表は、デプロイ環境の設計時に考慮する必要があるいくつかの問題点をまとめています。 部⾨規模 ⼩規模企業 管理、モニタリング ロードバランシン グ、管理、モニタリ ング ロードバランシン グ、管理、モニタリ ング、中継フォワー ダー ロードバランシン グ、管理、モニタリ ング、中継フォワー ダー サーチの問題 ユーザー数、アラー ト、App サーチヘッド/イン デクサーナレッジ管 理/ユーザー数 サーチヘッド/インデ クサーナレッジ管 理、ユーザー数、 サーチヘッド・クラ スタ、ジョブ・サー バー サーチヘッド/イン デクサーナレッジ管 理、ユーザー数、 サーチヘッド・クラ スタ、ジョブ・サー バー スケジュール済み サーチの負荷 アラート、App/ ダッシュボード依 存、サマリーサーチ アラート、App/ ダッシュボード依 存、サマリーサーチ アラート、App/ダッ シュボード依存、サ マリーサーチ、ジョ ブサーバー アラート、App/ ダッシュボード依 存、サマリーサー チ、ジョブサー バー、API/SDK ⼊⼒タイプ ネットワーク、スク リプト ネットワーク、スク リプト、バッチ、統 合 ネットワーク、スク リプト、バッチ、統 合 ネットワーク、スク リプト、バッチ、統 合 データファブリック (フォワーダーロー ドバランシング、ス トレージ、インデッ ユーザー・インター フェイス (サーチヘッ ド・クラスタ、ロー ド・バランシング)、 データ・ファブリッ ク (フォワーダー・ ユーザー・インター フェイス (サーチ ヘッド・クラスタ、 ロード・バランシン グ)、データ・ファ ブリック (フォワー フォワーダーの問 題 可⽤性 プラットフォーム依 存 (RAID、電源) 17 中規模企業 ⼤規模企業 クスレプリケーショ ン) ロードバランシン グ、ストレージ、イ ンデックス・レプリ ケーション) ダー・ロードバラン シング、ストレー ジ、インデックス・ レプリケーション) 回復性 バックアップ、保持 バックアップ、イン デックスレプリケー ション、バケツ/イ ンデックス復元 バックアップ、イン デックスレプリケー ション、バケツ/イン デックス復元 バックアップ、イン デックスレプリケー ション、バケツ/イ ンデックス復元 アクセス可能性 ローカル vs. 企業認 証 認証⽅法 認証⽅法 認証⽅法 スタッフ 管理者/アーキテクト 1〜2 ⼈、ナレッジ管 管理者：0.5〜1 管理者：0.5〜1 理者：0.5〜2 ⼈、 ⼈、サーチ/ダッ ⼈、サーチ/ダッ シュボード、App 開 シュボード、App 開 サーチ/ダッシュボー ド、App 開発：1〜3 発/ナレッジ管理 発/ナレッジ管理 ⼈、プログラム/プロ 者：0.25〜1 ⼈ 者：0.5〜1.5 ⼈ ジェクト管理者：1 ⼈ 管理者：2〜4 ⼈ま たはそれ以上、アー キテクト：1 ⼈また はそれ以上、ナレッ ジ管理者：2〜5 ⼈ またはそれ以上、 サーチ/ダッシュ ボード、App 開発： 2〜6⼈またはそれ以 上、プログラム管理 者：1 ⼈、プロジェ クト管理者：0.5〜2 ⼈ トレーニング情報および提供されているプロフェッショナルサービスについては、Splunk 営業担当までお問い合 わせください。 デプロイ環境のアップグレード 分散環境のアップグレード このトピックは、分散 Splunk Enterprise デプロイ環境のコンポーネントのアップグレードプロセスについて説 明しています。 分散 Splunk Enterprise 環境のアップグレードは、単⼀インスタンス Splunk Enterprise 環境のアップグレード よりも困難な問題を抱えています。ダウンタイムを短縮し、データが失われることがないように、コンポーネント のアップグレードは特定の順番で実⾏することをお勧めします。順番については、後述しています。 注意： この説明は、分散環境で Splunk Enterprise をアップグレードするための、⾼レベルのガイダンスとなっ ています。分散環境の形態はさまざまです。そのため、このトピックでは詳細な⼿順を説明することはできませ ん。このトピックを読んでも分散 Splunk 環境のアップグレードに関するその他の質問がある場合は、Splunk サ ポートポータルで案件を登録してください。 分散コンポーネント間の複数バージョンの互換性 異なるバージョンのサーチヘッド とサーチピア 間の互換性については、『分散サーチ』マニュアルの「バージョ ンの互換性」を参照してください。 インデクサーとフォワーダー間の互換性については、『データの転送』マニュアルの「フォワーダーとインデク サーの互換性」を参照してください。 アップグレード前の App のテスト 分散環境をアップグレードする前に、ご利⽤のすべての Splunk App が、アップグレードするバージョンの Splunk Enterprise 上で動作することを確認します。 重要： サーチヘッドプール を利⽤する分散環境をアップグレードする場合、プールにあるサーチヘッドは App や設定⽤に共有ストレージスペースを使⽤するため、この⼿順が必要になります 。 App が⽬的のアップグレード版 Splunk Enterprise で正常に動作することを確認するには： 1. リファレンスマシン上で、現在実⾏している Splunk Enterprise の完全版をインストールします。 注意： 既存の Splunk Enterprise インスタンスを使⽤することもできます (関連データのインデックスを作成し ておらず、環境内の他のインスタンスと同じバージョンの場合)。 2. このインスタンス上に App をインストールします。 3. App が期待通りに動作することを確認します。 4. インスタンスを⽬的のバージョンにアップグレードします。 5. 新しいバージョンでも、App が正しく動作することを確認します。 App が正しく動作した場合、分散環境のアップグレード時に、それらを適切な場所に移動することができます。 プールを使わないサーチヘッドを使⽤している場合は、サーチヘッドのアップグレード時に App を各サー チヘッドの $SPLUNK_HOME/etc/apps に移動します。 18 プールを使⽤するサーチヘッドの場合は、そのサーチヘッドが App を探す共有ストレージに App を移動し ます。 警告： プールを使⽤するサーチヘッドをアップグレードする場合、それ⽤の共有ストレージに App をコピーする 必要があることを警告するメッセージが表⽰されます。警告はするものの、⾃動的にコピーされることはありませ ん。アップグレード時には、Splunk Enterprise に同梱されている App も含めて (サーチ App や App と して実装されている データのプレビュー機能など) 、更新したすべての App を⼿動で共有ストレージにコピー する必要があります。そうしないと、アップグレードの完了後にのユーザーインターフェイスに関する問題が発⽣ する可能性があります。 複数のインデクサーとプールを使⽤しないサーチヘッドを持つ分散環境のアップグレード 可⽤性を維持するために、複数のインデクサーとプールを使⽤しないサーチヘッドを持つ分散環境をアップグレー ドする場合は、まずサーチヘッドをアップグレードしてから、それをサポートするインデックス作成インフラを アップグレードすることをお勧めします。環境内にデプロイサーバーを配備している場合は、サーチヘッドのアッ プグレードを開始する前にそれを忘れずに無効にしてください。 複数のインデクサーとプールを使⽤しないサーチヘッドを持つ分散環境をアップグレードするには： アップグレード準備 1. プールを使わないサーチヘッドが使⽤するすべての App が、アップグレード版の Splunk でも動作することを 確認します (「アップグレード前の App のテスト」を参照)。 2. 環境内でデプロイサーバー を使⽤している場合は、⼀時的にそれを無効にします。こうすることによって、 サーバーが無効な設定を他のコンポーネントに配布することを防⽌できます。 3. デプロイサーバーをアップグレードしますが、再起動は⾏わないでください。 サーチヘッドのアップグレード 4. いずれかのサーチヘッドを無効にしてアップグレードします。再起動は許可しないでください。 5. サーチヘッドをアップグレードしたら、正常動作を確認した App をサーチヘッドの レクトリに配置します。 $SPLUNK_HOME/etc/apps ディ 6. このサーチヘッドを再起動して、正常に操作できるか、機能を正しく利⽤できるかを確認します。 7. サーチヘッドに何も問題がない場合は、残りのサーチヘッドも 1 台ずつ無効にしてアップグレードしていきま す。環境にあるすべてのサーチヘッドに対して、この⼿順を繰り返します。必要に応じて、作業完了後に各サーチ ヘッドの動作や機能をテストしてください。 8. 最後のサーチヘッドのアップグレードが完了したら、すべてのサーチヘッドの動作と機能をテストします。 インデクサーのアップグレード 9. インデクサーを 1 台ずつ無効にしてアップグレードします。アップグレード後は即座にインデクサーを再起動 することができます。 10. サーチヘッドが各インデクサーから⽬的のデータを探せることをテストします。 11. すべてのインデクサーをアップグレードしたら、デプロイサーバーを再起動します。 複数のインデクサーとプールを使⽤するサーチヘッドを持つ分散環境のアップグレード 分散環境に、プールを使⽤しているサーチヘッド がある場合、環境のアップグレード⼿順は⼤幅に複雑になりま す。ダウンタイムに関する制限がある場合は、メンテナンス期間内iこの種類のアップグレードを⾏うことが最適 です。 このような環境におけるアップグレードの主な概念を以下に⽰します。 プールを使⽤するサーチヘッドは、グループとして有効/無効にする必要があります。 プール内のすべてのサーチヘッドの Splunk Enterprise バージョンは同じでなければなりません。 サーチヘッドプールをアップグレードする前に、サーチヘッドが使⽤する App と設定をテストする必要が あります。 ここに記載されている事項以外に何か疑問や懸念がある場合は、Splunk サポートポータルをご利⽤ください。 複数のインデクサーとプールを使⽤するサーチヘッドを持つ分散環境をアップグレードするには： アップグレード準備 1. プールを使うサーチヘッドが使⽤するすべての App が、アップグレード版の Splunk Enterprise でも動作する ことを確認します (「アップグレード前の App のテスト」を参照)。 2. 環境内でデプロイサーバー を使⽤している場合は、⼀時的にそれを無効にします。こうすることによって、 サーバーが無効な設定を他のコンポーネントに配布することを防⽌できます。 3. デプロイサーバーをアップグレードしますが、再起動は⾏わないでください。 サーチヘッドプールのアップグレード 19 4. 機能および操作テストのためにアップグレードする、サーチヘッドプール内のサーチヘッド (サーチヘッド 1) を指定します。 注意： サーチヘッドをアップグレードする前に、それをサーチヘッドプールから⼀時的に削除する必要がありま す。複数の理由からこの作業を実施する必要があります。 サーチヘッドプールの共有ストレージで提供されている App やユーザーオブジェクトの変更を防⽌する。 アップグレード中の、不注意によるローカル App やシステム設定の共有ストレージへの移⾏を防⽌する。 アップグレード中に問題があった場合に、その備えとして使⽤する有効なローカル設定を確保する。 アップグレードの結果問題が発⽣した場合に、バックアップ⼿段としてサーチヘッドを⼀時的に⾮プール構成で使 ⽤することができます。 5. 環境内のすべてのサーチヘッドを停⽌します。 注意： この時点でサーチ機能は利⽤できなくなります。アップグレード後にすべてのサーチを再起動するまで、 サーチ機能は利⽤できません。 6. 確認が完了した App (ステップ 1 でテストした) を、サーチヘッドプールの共有ストレージに配置します。 7. サーチヘッド 1 をサーチヘッドから削除します。 注意： 各サーチヘッド上でサーチヘッドプールの使⽤を有効/無効にする⽅法については、『分散サーチ』マニュ アルの「サーチヘッドプールの設定」を参照してください。 8. サーチヘッド 1 をアップグレードします。 9. サーチヘッド 1 を再起動して、正常に動作、機能するかどうかを確認します。 注意 ：この場合、「動作」や「機能」とは、インスタンスが起動し、正常にログインできるかどうかを意味して います。共有ストレージで提供されている App やオブジェクトを使⽤できるかどうかではありません。また、分 散サーチが正常に実⾏されるかどうかでもありません。 10. アップグレードしたサーチヘッド 1 が⽬的通りに機能している場合： a. b. c. d. それを停⽌します。 サーチヘッドから共有ストレージに、App とユーザー基本設定をコピーします。 サーチヘッドプールに再び追加します。 サーチヘッドを再起動します。 11. 上記のステップ 7〜10 の⼿順に従って、プール内の残りのサーチヘッドを 1 台ずつアップグレードしていき ます。 警告： 各サーチヘッドをアップグレードする前にサーチヘッドプールからそれを削除してください。アップグ レード完了後に、プールに再び追加します。各サーチヘッドの動作と機能を確認する必要はありませんが、アップ グレード作業中は 1 回に 1 台のサーチヘッドのみを稼働することができます。すべてのサーチヘッドのアップグ レードを完了するまでの間は、他のサーチヘッドを起動しないでください。 12. プール内の最後のサーチヘッドのアップグレードが完了したら、すべてのサーチヘッドを再起動します。 13. すべてのサーチヘッドの機能と動作を、サーチヘッドプールが提供するすべての App とユーザーオブジェク トにまたがってテスト/確認します。 14. すべてのインデクサーにまたがって、分散サーチをテスト/確認します。 インデクサーのアップグレード 15. サーチヘッドが正常に動作することを確認したら、環境の稼働を維持するためのインデクサー (インデクサー 1) を 1 つ、そして最初にアップグレードするインデクサー (インデクサー 2) を選択します。 注意： ダウンタイムを考慮する必要がない場合は、この作業を実施する必要はありません。 16. インデクサー 1 を除くすべてのインデクサーを停⽌します。 注意： ダウンタイムを考慮する必要がない場合は、すべてのインデクサーを停⽌することができます。 17. インデクサー 2 をアップグレードします。 18. インデクサー 2 を起動して、正常に動作、機能するかどうかを確認します。 注意： サーチヘッドとインデクサー間のバージョン互換性については、『分散サーチ』マニュアルの「バージョ ンの互換性」を参照してください。 19. インデクサー 2 が正常に動作、機能することを確認したら、インデクサー 1 を停⽌します。 20. インデクサー 1、および残りすべてのインデクサーを⼀度に 1 台ずつアップグレードしていきます。アップグ レード後は即座にインデクサーを再起動することができます。 21. すべてのインデクサーにまたがって、機能と動作をテスト/確認します。 22. デプロイサーバーを再起動して、正常に動作、機能するかどうかを確認します。 フォワーダーのアップグレード 20 分散環境をアップグレードする場合、その環境内にあるユニバーサルフォワーダーもアップグレードすることがで きます。これは必須の作業ではありません。必要に応じて作業を⾏うかどうかを判断してください。フォワーダー は常に最新版のインデクサーと互換性があります。そのため、データの送信先インデクサーをアップグレードした からといって、フォワーダーをアップグレードする必要はありません。 ユニバーサルフォワーダーをアップグレードするには、このマニュアルの以下のトピックを参照してください。 Windows ユニバーサルフォワーダーのアップグレード *nix システムのユニバーサルフォワーダーのアップグレード Windows ユニバーサルフォワーダーのアップグレード 『データの転送』マニュアルに移動 Windows ユニバーサル・フォワーダーのアップグレード⽅法は、『データの転送』マニュアルに移動されまし た。 Windows でのユニバーサル・フォワーダーのアップグレード⽅法については、該当するトピックを参照してくだ さい。 *nix システムのユニバーサルフォワーダーのアップグレード 『データの転送』マニュアルに移動 UNIX ユニバーサル・フォワーダーのアップグレード⽅法は、『データの転送』マニュアルに移動されました。 *nix でのユニバーサル・フォワーダーのアップグレード⽅法については、該当するトピックを参照してください。 21
© Copyright 2024 Paperzz
