みなさん、こんにちは。技術系の記事を担当しています、瀬口です。
今回は、EasyBlocksシリーズの再起動にかかる時間についてご紹介します。
EasyBlocksシリーズを運用するうえで、
アップデートで再起動するとき、サービスはどのくらいの時間止まるの…？
ネットワークやシステム設定を反映するときの作業時間を把握しておきたい…
といったお悩みをいただくことがあります。
EasyBlocksシリーズは、ファームウェアのアップデートや変更した本体設定を反映させるために、本体の再起動が必要です。再起動中はSyslogの受信やIPアドレスの払い出しといったサーバー機能が停止するため、サービスの停止時間がどのくらいになるのかを事前に把握しておくことが大切です。
本記事では、各種モデルでOS・各サービス・Web UIが起動するまでの時間を計測し、その結果をまとめました。
はじめに
EasyBlocksシリーズは、モデルごとにSyslog・DHCP・DNS・監視といった、ネットワークの基盤となるサービスを提供するアプライアンスです。そのため、機器が再起動している間は、以下のような影響が出ます。
- Syslogシリーズ：ネットワーク機器から送られてくるログを受信できない。
- DHCP・DDNシリーズ：新しく接続した端末にIPアドレスを払い出せない。
名前解決ができない。 - 監視シリーズ：監視対象機器の異常を検知・通知できない。
一方で、「再起動にどのくらいの時間がかかるのか」は、実際に測ってみないとわかりにくい部分です。
EasyBlocksシリーズのWeb UIでは、「再起動が完了するまで、およそ 180 秒程度の時間が必要です。」と表示されます(一部モデルは「200 秒程度」)。ただし、これはあくまで目安であり、実際の再起動時間とは異なる場合もあります。
そこで今回は、各モデルを実際に再起動し、OSの起動・各サービスの起動・Web UIの起動にそれぞれどのくらいの時間がかかるのかを計測しました。
検証するモデル
今回は、以下のモデルで再起動時間を計測しました。なお、EasyBlocksシリーズは、モデルによって使用している筐体（ハードウェア）が異なります。
| 製品名 | 型番 | 筐体 | 主なサービス |
|---|---|---|---|
| EasyBlocks Syslog 120G | EBIX/SYSLOG120G | EBIX型（手のひらサイズ） | Syslog |
| EasyBlocks Syslog Reporter 120G | EBX9/NR120G | EBX9型（1Uハーフサイズ） | Syslog・レポート |
| EasyBlocks DHCP AS 2500 | EBHX1/DHCPA2500 | EBHX1型（1Uハーフサイズ） | DHCP（冗長化対応） |
| EasyBlocks DDN1 | EBA16/DDN1 | EBA16型（手のひらサイズ） | DHCP・DNS・NTP |
| EasyBlocks DDN1 Enterprise | EBHX1/DDN1ENT | EBHX1型（1Uハーフサイズ） | DHCP・DNS・NTP（冗長化対応） |
| EasyBlocks 監視 | EBA16/KANSHI | EBA16型（手のひらサイズ） | 死活監視 |
| EasyBlocks リソース監視 | EBA16/RSK | EBA16型（手のひらサイズ） | 死活監視・リソース監視・トラフィック監視 |
| EasyBlocks リモート監視管理 | EBFX/RKANSHI | EBFX型（手のひらサイズ） | 死活監視・リモート管理 |
検証方法
検証は、以下の流れで実施しました。
- Web UIの「メンテナンス」から「再起動」の「実行」ボタンを押し、その時刻を再起動実施時刻とします。
- 再起動後、コマンドラインからOS・各サービス・Web UIが起動した時刻を確認します。
- 再起動実施時刻から各起動時刻までの経過時間を算出します。
また、DHCPシリーズ・DDNシリーズ・監視シリーズについては、Web UIのダッシュボード上の動作ログからもサービスを開始した時刻を確認できます。今回はコマンドラインで確認した時刻と、動作ログの時刻を照合しています。
Syslogシリーズでは、検証用の端末から毎秒ログを送信し、ログの受信が再開した時刻から、サービスが使える状態になったかどうかも確認しました。
※注意
今回の検証は、ファームウェアのアップデートや設定変更を伴わない再起動です。
反映するアップデート内容や設定内容、製品の状態などによっては、今回の結果より時間がかかる場合があります。
検証結果
計測したすべてのモデルで、Web UIに表示される目安の時間よりも短く、約40秒～1分20秒ですべてのサービスが起動しました。モデルごとの結果は以下のとおりです。
EasyBlocks Syslog 120G
筐体：EBIX型
Web UI上の目安：200秒程度
| 項目 | 再起動実施からの経過時間 |
|---|---|
| OS起動 | 34秒 |
| Syslogサービス起動 | 54秒 |
| Syslog受信再開 | 55秒 |
| Web UI起動 | 1分17秒 |
再起動の実施から約1分程度でSyslogの受信が再開しました。Web UIの起動は再起動の実施から約1分20秒後ですが、ログの受信はWeb UIよりも約20秒早く再開しています。そのため、Web UIにアクセスできない間も、ログの受信自体は再開している点がポイントです。
EasyBlocks Syslog Reporter 120G
筐体：EBX9型
Web UI上の目安：200秒程度
| 項目 | 再起動実施からの経過時間 |
|---|---|
| OS起動 | 41秒 |
| Syslogサービス起動 | 55秒 |
| Syslog受信再開 | 56秒 |
| Web UI起動 | 1分19秒 |
EasyBlocks Syslog 120Gと同様に、再起動の実施から約1分程度でSyslogの受信が再開し、その約20秒後にWeb UIが起動しました。OSの起動はSyslog 120Gより7秒ほど遅いものの、ログの受信再開までの時間はほぼ同じです。
EasyBlocks DHCP AS 2500
筐体：EBHX1型
Web UI上の目安：180秒程度
| 項目 | 再起動実施からの経過時間 |
|---|---|
| OS起動 | 48秒 |
| DHCPサービス起動 | 1分02秒 |
| Web UI起動 | 1分02秒 |
再起動の実施から約1分程度で、DHCPサービスとWeb UIが起動しました。
EasyBlocks DDN1
筐体：EBA16型
Web UI上の目安：180秒程度
| 項目 | 再起動実施からの経過時間 |
|---|---|
| OS起動 | 20秒 |
| DHCPサービス起動 | 40秒 |
| DNSサービス起動 | 41秒 |
| NTPサービス起動 | 41秒 |
| Web UI起動 | 41秒 |
再起動の実施から約40秒程度で、DHCP・DNS・NTPのすべてのサービスとWeb UIが起動しました。
EasyBlocks DDN1 Enterprise
筐体：EBHX1型
Web UI上の目安：180秒程度
| 項目 | 再起動実施からの経過時間 |
|---|---|
| OS起動 | 51秒 |
| DHCPサービス起動 | 1分09秒 |
| DNSサービス起動 | 1分09秒 |
| NTPサービス起動 | 1分09秒 |
| Web UI起動 | 1分09秒 |
再起動の実施から約1分10秒程度で、すべてのサービスとWeb UIが同時に起動しました。内訳としては、OSの起動からサービス起動までが約20秒と、EasyBlocks DDN1と同程度です。
一方、OSの起動自体は約50秒と、EasyBlocks DDN1よりも時間がかかっていますが、同じ筐体を使用しているEasyBlocks DHCP AS 2500のOS起動も約50秒のため、使用している筐体によるものと考えられます。
EasyBlocks 監視
筐体：EBA16型
Web UI上の目安：180秒程度
| 項目 | 再起動実施からの経過時間 |
|---|---|
| OS起動 | 16秒 |
| 監視サービス起動 | 37秒 |
| Web UI起動 | 37秒 |
再起動の実施から約40秒程度で、監視サービスとWeb UIが同時に起動しました。今回計測したモデルの中で、最も短い時間で起動しています。
EasyBlocks リソース監視
筐体：EBA16型
Web UI上の目安：180秒程度
| 項目 | 再起動実施からの経過時間 |
|---|---|
| OS起動 | 18秒 |
| 監視サービス起動 | 45秒 |
| Web UI起動 | 46秒 |
再起動の実施から約45秒程度で監視サービスとWeb UIが起動しました。EasyBlocks 監視よりも監視の起動に時間がかかっていますが、これは監視機能の種類が多いためではないかと考えられます。
EasyBlocks リモート監視管理
筐体：EBFX型
Web UI上の目安：180秒程度
| 項目 | 再起動実施からの経過時間 |
|---|---|
| OS起動 | 45秒 |
| 監視サービス起動 | 1分09秒 |
| Web UI起動 | 1分09秒 |
再起動の実施から約1分10秒程度で、監視サービスとWeb UIが同時に起動しました。内訳としては、OSの起動からサービス起動までが約25秒と、EasyBlocks 監視と同程度です。
一方、OSの起動自体には他のEasyBlocks 監視シリーズよりも時間がかかっていますが、これは使用している筐体の違いによるものと考えられます。
検証結果一覧
各モデルの結果を表でまとめると以下の通りです。
| 製品名 | OS起動 | サービス起動 | Web UI起動 | Web UI上の目安 |
|---|---|---|---|---|
| EasyBlocks Syslog 120G | 34秒 | 54秒 | 1分17秒 | 200秒程度 |
| EasyBlocks Syslog Reporter 120G | 41秒 | 55秒 | 1分19秒 | 200秒程度 |
| EasyBlocks DHCP AS 2500 | 48秒 | 1分02秒 | 1分02秒 | 180秒程度 |
| EasyBlocks DDN1 | 20秒 | 40～41秒 | 41秒 | 180秒程度 |
| EasyBlocks DDN1 Enterprise | 51秒 | 1分09秒 | 1分09秒 | 180秒程度 |
| EasyBlocks 監視 | 16秒 | 37秒 | 37秒 | 180秒程度 |
| EasyBlocks リソース監視 | 18秒 | 45秒 | 46秒 | 180秒程度 |
| EasyBlocks リモート監視管理 | 45秒 | 1分09秒 | 1分09秒 | 180秒程度 |
※いずれもファームウェアのアップデートや設定変更を伴わない再起動での結果です。
再起動時間を活かしたリスク管理
再起動にかかる時間がわかると、メンテナンス時のリスク管理に役立ちます。
例えば、以下のような点を事前に把握できます。
- ログが取れない時間
EasyBlocks Syslogでは、再起動から約1分間はSyslogを受信できません。一般的にログは送信側からは再送されないため、この間に送られたログは記録されない可能性があります。重要なログを扱う環境では、ログの発生が少ない時間帯（夜間・休日など）に再起動するのがおすすめです。 - IPアドレスが払い出されない時間
DHCP AS 2500では約1分、EasyBlocks DDN1では約40秒、DDN1 Enterpriseでは約1分10秒、新しいIPアドレスの払い出しと名前解決が止まります。
なお、すでにIPアドレスを取得している端末は、リース期間内であればそのまま通信を続けられます。影響を受けるのは、主に再起動中に新しく接続した端末です。 - 監視が止まる時間
監視シリーズでは、約40秒～1分10秒の間、監視が停止します。この間に発生した障害は、監視が再開するまで検知・通知されません。 - メンテナンス時間の見積もり
アップデートや設定内容によっては今回より時間がかかるため、今回の結果は最低限の目安として使えます。実際の作業では、Web UIに表示される目安（180～200秒程度）に余裕を持たせて計画すると安心です。
サービスを止められない環境では、EasyBlocks DHCP AS、DDN1 EnterpriseのActive/Standby方式の冗長化機能を利用する方法もあります。稼働機を再起動している間も待機機がサービスを引き継ぐため、サービスの停止時間を抑えられます。
Active/Standby方式のような冗長化機能を備えていないEasyBlocks Syslog、DDN1、監視シリーズの場合、2台構成で順番に再起動することで、ログの収集漏れや監視漏れを防ぐことも可能です。
まとめ
今回は、EasyBlocksシリーズの再起動にかかる時間を、モデルごとに計測してご紹介しました。
要点をまとめると、以下のとおりです。
- 今回計測したモデルは、再起動から約40秒～1分20秒程度でOS・各サービス・Web UIが起動した。
- いずれもWeb UI上の目安（180～200秒程度）より短い時間で起動した。
- EasyBlocks Syslog、Syslog Reporterは、Web UIよりも先にログの受信が再開する。
- アップデートや設定変更を伴う再起動では、今回の結果より時間がかかる場合がある。
- 再起動時間を把握しておくことで、ログの欠損やIPアドレスの払い出し停止などのリスクを事前に見積もれる。
EasyBlocksシリーズの運用やメンテナンスについてご不明な点がございましたら、お気軽にお問い合わせください。
▼ 今回ご紹介した製品はコチラ ▼
