本記事では、SSBのリプレースなどで、新しいSSBを初期セットアップする時に、既存のSSBからログデータとコンフィグレーションを転送して、セットアップする手順について説明します。
はじめに
SSBをリプレースするなどの場合、これまでは、ログデータの移行は既存のSSBからログデータを外部のNASなどにバックアップ(必要な応じてアーカイブ)して、新しいSSBにリストアする方法がありました。ただし、この方法では、データをバックアップしてからリストアするまでのログは新しいSSBで受信されずロストしていました。これは、バックアップおよびリストアされるログ量に応じて長い時間を要していました。
ここでは、新しいSSBを初期セットアップする時に、既存のSSBでログを受信しながらログデータおよびコンフィグレーションを新しいSSBに転送する機能を使用してセットアップする手順について説明します。
これにより、ログデータをバックアップ、アーカイブ、およびリストアする手間を省くことができ、ログデータのロスト時間を最小限に抑えられます。
以下では、既存のSSBを転送元SSBと記述しています。また、転送元のSSBのIPアドレスは`10.0.2.200`、新しいSSBの一時的なIPアドレスを`10.0.2.201`としています。必要に応じて読み換えてください。
前提条件&制限
- 新しいSSBは、転送元SSBと同一ネットワーク上にする必要があります。また、相互に通信可能の状態である必要があります。
- 新しいSSBは、転送元SSBとSSHで接続できる必要があります。
- 新しいSSBには、少なくとも転送元SSB内の全ログスペースのサイズ＋転送先SSBのシステムサイズのディスク容量が必要です。
- 転送は IPv4 でのみ機能し、IPv6 はサポートされていません。
- 転送元SSB は、少なくともSSBバージョン 6 LTS である必要があります。
- レポートおよびカスタムクラウドデータディスクに保存されたログスペースは転送されません。
- 可能ならば、バックアップ/アーカイブプロセスを停止してから実行することをお勧めします。
手順
それでは、新しいSSBの初期設定時に、転送元SSBから新しいSSBへログスペースとコンフィグレーションを転送する手順を以下に示します。
転送元SSBのSSH設定
新しいSSBから転送元SSBにSSH接続できるように、転送元SSBのSSH設定を行います。
※既に、SSH接続が有効の場合は、この手順をスキップしてください。
- 転送元SSBにアクセスします。
- [Basic Settings]>[Management]>[SSH settings]に移動します。
- SSH接続を有効にします。
Enable remote SSH access:✅
Enable password authentication:✅- [Commit]をクリックして設定を保存します。
新しいSSBのネットワーク設定
新しいSSBから転送元SSBに接続できるように、IPアドレスなどを設定します。ここでは、新しいSSBは初期インストール済みで、コンソールアクセスしてCLIで設定します。
- コンソールに`root/default`でログインします。
- [1 Shells]>[2 Core shell]を選択して、コアシェルに移動します。
- 以下コマンドを実行して、IPアドレスおよびデフォルトゲートウェイを設定します。
# ip addr add 10.0.2.201/24 dev eth0
# ip route add default via 10.0.2.2- pingで転送元SSBへ疎通確認します。
# ping 10.0.2.200 -c 4- `exit` > [6 Logout]でログアウトします。
転送元SSBからのログデータおよびコンフィグレーション転送
- 新しいSSBにブラウザでアクセスします。
- ウェルカムウィザードの[Configuration]画面で、[Standalone or primary node configuration]を選択します。
- [Transfer from another node]を選択します。
- [Transfer from another node]設定フィールドが展開されます。
[Transfer from another node]設定
- [Source address]に転送元SSBのIPアドレスを入力します(ここでは、10.0.2.200)。
- [Source host key]フィールドの
をクリックします。[Source host key]ダイアログが表示されるので、[Query]をクリックします。
- 転送元SSBのホスト鍵がアップロードされます。
転送元SSBへのRSA鍵設定
[Transfer from another node]設定時に生成された、新しいSSBのRSA鍵を転送元SSBのSSH設定でアップロードします。
- [RSA public key]に生成されたRSA鍵をクリップボードにコピーします。
※このRSA鍵は、転送プロセスを開始する前に、ウェルカムウィザードのページをリロードするたびに新しく生成されることに注意してください。この場合、以下の手順(転送元SSB-[Authorized keys]設定)で更新しなおす必要があります。
- 転送元SSBの[Basic Settings]>[Management]>[SSH settings]に移動し、[Authorized keys]リストに追加します。
をクリックして、をクリックします。
- [Changing key]ダイアログが表示されるので、[Copy-paste key]フィールドにRSA鍵をペーストして、[Set]をクリックします。
- RSA鍵がアップロードされるので、[Commit]をクリックして、設定を保存します。
- 新しいSSBに戻り、[Next]をクリックします。
コンフィグレーション確認
転送元SSBのコンフィグレーションが表示されるので、確認して、[Finish]をクリックします。
転送の開始
※データ容量やネットワーク速度に応じて、転送プロセスに時間がかかる場合があります。理想的なケースでは、1ギガビットネットワークを介して、1秒あたり約120MiBを転送できます。これは、1TiBのデータの転送に少なくとも2.5時間かかることを意味します。なお、弊社検証環境では51MiB/sとなり、1TiBでは5.7時間かかりました。
※転送中に転送元SSBのコンフィグレーションを変更しないでください。コンフィグレーションの一貫性が失われ、データが失われる可能性があります。
※転送プロセス中は、画面を閉じないことをお勧めします。
[Finish]をクリックすると、データ転送プロセスが開始されます。データ転送は、以下の 8 ステップで行われます。
- 1. [Transferring configuration and user preferences]、転送元のSSB でコンフィグレーションバンドルが自動的に作成され、新しいSSBに転送されます。
- 2. [Synchronizing most of the logs]、転送元SSBのすべての既存のログスペースが新しいSSBに転送されます。
※データ容量とネットワーク速度に応じて、このステップが完了するまでに時間がかかる場合があります。
- 3. [Synchronizing logs received during the previous step]、転送元SSB がデータ転送中にログを受信している場合、つまり、前のステップ中に受信したログがこのステップで転送されます。
※転送元SSBのログ受信状況に応じて、このステップが完了するまでに時間がかかる場合があります。
- 4. [Waiting for confirmation]、このステップで[Confirm]をクリックすると、データ転送の残りの自動プロセスが実行されます。[Confirm]をクリックします。
※[Confirm]をクリックすると、データ転送プロセスは中断できなくなり、自動的に完了します。
- 5. [Stopping syslog-ng on source]、転送元 SSBのsyslog-ngは停止され、ログはこのステップから転送元SSBによって受信または転送されません。
※このステップ後、転送元SSBでログ受信が停止され、新しいSSBがログ受信を再開するまでログがロストします。弊社環境では、約3分のログロスト時間が発生しました。この時間は、システム環境またはログ受信状況などに応じて異なります。
- 6. [Synchronizing the remaining logs from the source SSB]、転送元SSBのsyslog-ngがシャットダウンされる前に、[Confirm]ステップ中に転送元 SSBによって受信されたログを転送します。
※転送元SSBのログ受信状況に応じて、このステップが完了するまでに時間がかかる場合があります。
- 7. [Shutting down source cluster]、転送元SSBは、このステップでシャットダウンされます。転送元SSBがHA構成の場合、最初にセカンダリーノード、次にプライマリーノードがシャットダウンされます。
- 8. [Applying configuration]、以前に転送されたコンフィグレーションが新しいSSBに適用され、転送元SSBと同じIPアドレスを持つ、新しいSSBのログイン画面にリダイレクトします。
※転送元SSBの電源を入れる場合は、ネットワークから切り離してください。新しいSSBとIPアドレスがコンフリクトし、ログが正しく受信できなくなる場合があります。この時点では、転送元SSBと新しいSSBのコンフィグレーションは同一であることに注意してください。
以下に、手順の実行動画をアップしています。テキストの手順と合わせて参考にしてください。
エラーなど
操作中、発生する可能性があるエラーやアラートについて、説明します。
- エラー1：下記エラーは、転送元SSBのSSH接続が有効でない可能性があります。転送元SSH接続の有効を確認してください。あるいは、転送元SSBにSSH接続できていない可能性があります。SSB間の接続ができているか確認してください。
- エラー2：下記エラーは、新しいSSBのRSA鍵が転送元SSBのSSH設定で正しくアップロードされていない可能性があります。適宜、新しいSSBのRSA鍵を転送元SSBのSSH設定でアップロードしてください。このRSA鍵は操作ページをリロードするたびに新しく生成されることに注意してください。
- 転送処理中、新しいSSBへのリダイレクト時に、転送元SSBの任意のページを開いている場合、以下のアラートが発生する場合があります。これは、新しいSSBの任意のページに再アクセスする為、認証が必要である旨のアラートで、これは、無視できます。
DISMAN-EVENT-MIB::sysUpTimeInstance 74765
SNMPv2-MIB::snmpTrapOID.0 XCB-SNMP-MIB::xcbError
XCB-SNMP-MIB::description Authentication error - This module (Status) requires authentication, please log in.
XCB-SNMP-MIB::peerInetAddress 10.0.2.101
XCB-SNMP-MIB::peerInetAddressType ipv4おまけ
転送操作中の、パケットをキャプチャしてみました。
以下は、[Source host key]で[Query]を実行した時のキャプチャです。ssh-keyscanでホスト鍵を取得していることがわかります。
以下は、[Finish]を実行後のキャプチャです。SSHで転送データが暗号化され安全に通信できていることがわかります。
おわりに
いかがでしたでしょうか？
この機能を使用することで、既存のSSBから新しいSSBへ１ステップでログデータおよびコンフィグレーションを移行できることがわかりました。
SSBの機能
本記事で使用したSSBの機能は以下の通りです。
- 既存の SSB からのログスペースとコンフィグレーションの転送
参考資料
サーチページの使い方の詳細については、syslog-ng Store Box 7 LTS管理者ガイドの「3.2.1.3 既存の SSB からのログスペースとコンフィグレーションの転送」を参照してください。
過去連載記事
「SIEMのコスト削減とパフォーマンス向上(誤検知防止)の技」連載記事リスト
- (技1)「フィルター(Add filter)を使用したログ容量削減！」
- (技2)「カスタムフィルター(Custom filter)を使用したログ容量削減！」
- (技3)「Message throttleを使用した転送レート制限！」
- (技4)「Rewritesを使用した正規化！」
「リモートアクセスログを調査」連載記事リスト
- (その1)「フィルターログスペースを使用して必要なログのみ検索・抽出してみる！」
- (その2)「マルチログスペースを使用してログを集約してみる！」
- (その3)「リモートログスペースを使用して他のSSBに保存したログを検索・抽出してみる！」
- (その4)「サービス残業させていない？リライトを使用して日時を指定して検索してみる！」
- (その5)「サービス残業させていない？業務時間外勤務の実態をグラフで見やすく！」
- (その6)「サービス残業させていない？レポートを日ごと、週ごと、月ごとに定期的に送信！」
- (その7)「不正アクセスされていない？アクセス元IPアドレスから国・都市・ASNの調査！」
- (その8)「不正アクセスされていない？認証エラーの確認はしなくて大丈夫？」
- (その9)「不正アクセスされていない？認証エラーのログを見逃さない！(コンテンツベースアラート)」
- (その10)「不正アクセスされていない？認証エラーのログを見逃さない！(パターンデータベースアラート)」
- (その11)「不正アクセスされていない？認証エラーのログを見逃さない！(メッセージレートアラート)」
- (その12)「不正アクセスされていない？認証エラーログを可視化(平常時の確認)」
「syslog-ng Store Box大活用連載企画」連載記事リスト
- 第1回「syslog-ng Store Boxを知る」
- 第2回「syslog-ng Store Boxを仮想環境にインストールする」
- 第3回「syslog-ng Store Boxで出来ることまとめ」
- 第4回「Wiresharkでsyslogプロトコルパケットを覗く」
- 第5回「Ciscoスイッチ、FortigateファイアウォールログをSSBで受信！よりログを検索しやすく」
- 第6回「RPC APIを使ってみる、自社システムに統合！ログ検索の自動化！」
- 第7回「Active Directoryと連携して、Active Directoryユーザー認証！」
- 第8回「SSBをHA(High Availability)構成で構築してみる！」
- 第9回「ログをバイナリおよびテキスト形式で保存、違いを比較してみる」
- 第10回「ログファイルを共有して、外部ホストからアクセスしてみる！」
- 第11回「フィルターを使用して、必要なログのみ保存してみる！」
- 第12回「SSBの監視とアラート！SNMPマネージャーで監視およびSNMPトラップを受信してみる」
- 第13回「コンテンツベースアラート。重要なログを見逃さない！」
- 第14回「設定変更履歴。コンプライアンスにも対応！」
- 第15回「トラブルシューティングに役立つ機能。問題を迅速に解決！」
- 第16回「ユーザーアクセス制御。アクセス権限とタイプを設定してみる！」
- 第17回「リライト機能。ログの整形や正規化！」
- 第18回「バックアップリストア。システムデータおよびログデータをバックアップ、リストアしてみる！」
- 第19回「アーカイブ/クリーンアップ。ログデータをアーカイブ、クリーンアップしてみる！」
- 第20(最終)回「SSBの有効活用および安定稼働のためのポイントを紹介！」
SSBは、高信頼ログ管理アプライアンスです。様々なデバイスおよびアプリケーションからログメッセージを収集、分類、フィルタリング、正規化して安全に保存可能です。ログデータの信頼性を担保し、膨大なログが発生する高負荷環境、あるいはログロストが許されない企業・組織のログ管理に最適です。
syslog-ng Store Boxについての詳細は、製品紹介ページ・製品ガイドをご参照ください。
