Meraki ファームウェアを管理するためのベストプラクティス

Last updated
Save as PDF

こちらの記事は Best Practices for Meraki Firmware を翻訳したものです。

内容に矛盾や不一致がある場合は英語版の内容が優先されます。

概要

従来、ファームウェア管理は面倒で時間がかかる上リスクを伴う手順であり、アップグレードを行うネットワーク管理者にとって恐怖と嫌悪感を抱くようなものでした。また、その管理の複雑さは長い間、例えば USB ドライブが壊れてアップグレードが失敗したり、データセンターで夜遅くまで新しいコードのプロビジョニングを手作業で行ったというようなホラーストーリーを生み出し、業界全体のファームウェア管理プラクティスを悩ませてきました。Meraki ではこれらの負担を軽減することができます。Cisco Merakiは、パワフルなネットワークとITソリューションをシンプルで簡単な管理方法で提供することをモットーにしており、これは Meraki デバイスのファームウェア管理にも当てはまります。

クラウドがもたらす変化

Merakiでは、提供しているクラウドベースのダッシュボードを利用して複雑なファームウェアの問題に取り組んでいます。ダッシュボードの力を利用することで、ファームウェアの容易な展開とスケジューリングを可能にしています。また、ダッシュボードは、新しいファームウェアで利用可能になる新機能について、独自の情報を提供しています。

セキュリティの観点から見ると、クラウドのメリットは他に類を見ません。今日、新たなセキュリティ脆弱性が絶えず報告されており、ネットワークインフラが悪用されないとは言えません。このような規模の脅威を抑制するには、柔軟で迅速なソフトウェアの修復が最も重要です。Merakiには、発見された脆弱性に即座に対応し、パッチを当て、そのファームウェアをお客様がすぐに利用できるようにする力があります。

シンプルなファームウェアアップデート

Merakiが開業した初期の頃は、ファームウェアの設定は、週末の深夜など、お客様のネットワークに都合の良いメンテナンスの時間帯を指定するだけでした。Merakiがお客様とともに成長していく中で、クラウドベースのシンプルな方法を維持しつつ、ファームウェアの管理を希望するお客様のために、より厳密な管理方法を取り入れました。お客様は、ネットワーク毎にファームウェアを選択することで組織内の各ネットワークのファームウェアを管理できるようになりました。

Merakiは、Merakiのクラウドプラットフォームを使用したファームウェアの配信により、非常に迅速で信頼性の高い方法でファームウェアのアップグレードを提供することで差別化を図っています。その結果は、ユーザーの素晴らしいファームウェア採用率に表れています。より詳細な管理オプションがあったとしても、大多数のユーザーは、安定版リリース候補が利用可能になった直後に、最新のファームウェアビルドを採用し、稼働させています。当社の広範なテストとベータ採用プロセスにより、信頼性の高いファームウェアを定期的に提供し、最新のセキュリティと安定性を実現しています。

Meraki ファームウェアの命名規則

Meraki ファームウェアの命名法は製品間で共通であり、名前の一部としてメジャー、マイナー、メンテナンス、ホットフィックス番号で構成されています。

Meraki のバージョン番号は、ユーザがファームウェアのアップデートのレベルを理解できるようつけています。メジャーバージョンは一般的にマイナーバージョンよりも重要であり、アップグレードする前に慎重に検討する必要があります。マイナーバージョンとメンテナンスバージョンは一般的に重要度が低く、より簡単にアップグレードすることができます。

ファームウェアのバージョンは、以下のフォーマットで命名されます：

<製品名> <メジャー>.<マイナー>.<メンテナンス>.<ホットフィックス>

バージョン	説明
メジャー	メジャーバージョンは新しいモデルや製品、技術、機能が導入された際にリリースされます
マイナー	メジャーバージョンで報告された事象への修正や、新機能が追加される場合にマイナーバージョンがリリースされます。
メンテナンス	マイナーバージョンのリリース後に報告された事象への修正アップデートが含まれます。
ホットフィックス	ホットフィックスバージョンはマイナーバージョンへの緊急の修正がを含まれています。次のメンテナンスバージョンより迅速にリリースする必要がある場合にリリースされます。

MXアプライアンスのファームウェアについては、先行して下記の新しい命名規則が採用されています。また、今後のアップデートにより下記命名規則はダッシュボードUIとAPIを通じてサポートされます。

メジャーバージョン（主要な変更点、機能リリースのファミリーを表す）
マイナーバージョン（メジャーバージョン内の機能リリースを表し、新機能を含む）
ポイントリリース（上記表内のマイナーバージョンの定義と同じ）

UI上は現在、マイナーリリースとポイントリリースの番号を一緒に表しています。例えば、MX 18.1.05はMX 18.105と表現されます。したがって、MX 18.201は、MX 18.1XXリリースとは異なるマイナーバージョンと機能セットを表すことになります。

Meraki ファームウェアのリリースサイクルは、ファームウェアの展開プロセスにおいて、ベータ版、安定版リリース候補版（RC）、安定版ファームウェアの 3 つの段階で構成されています。このサイクルの詳細については Meraki におけるファームウェア開発サイクルに記載されています。

ファームウェアの自動アップグレード

Meraki は "ネットワークをシンプルに" を目標に掲げおり、"ファームウェアアップグレードの自動化" はその目標を達成するための手段の 1 つです。ファームウェアアップグレードプロセスをサポートし、お客様へ安定したサービスを提供するため、特定のファームウェアアップグレード基準を満たしたネットワークに対し、Meraki は管理者に代わり新しいファームウェアへのアップグレードを計画・実行します。デフォルトではすべてのネットワークは自動的にファームウェアアップグレードが実行されるようになっています。このアップグレード作業は管理者側の操作は不要ですが、お客様によってはそれがファームウェアの管理プロセスとしては適切でない場合があります。

新しいファームウェアがリリースされると即座にダッシュボード上に表示され管理者側でアップグレードできるようになります。管理者側で実行しない場合でも自動アップグレードプロセスにより最終的には対象のネットワークに対し自動的にアップグレードが実行されます。しかしながら、自動アップグレードプロセスは必ずしもリリース直後に実行されるわけではないことに注意してください。自動アップグレードプロセスは時間をかけて段階的に行われますが、様々な要因により数週間以上にわたる場合があります。

要因として例えば既存のファームウェアと新しいファームウェア間に潜在するコンフリクトやアップグレード対象のデバイス数あるいはアップグレードに注意を要する重要なデバイスやネットワークの特別な設定などがあります。ファームウェアアップグレードを展開する際にはセキュリティや稼働時間、互換性を最大限維持することを最も重要視しています。セキュリティや稼働時間、互換性の維持に影響がでる恐れがある場合にはその影響が解消されるまでファームウェアアップグレードの展開を保留する場合があります。

自動アップグレードプロセスでアップグレード先に選ばれるファームウェアは 3 つのリリースタイプに分かれます。（安定版、安定版リリース候補、ベータ版) 自動アップグレードプロセスが実行されると、”対象のネットワークで設定されたリリースタイプに合った最新バージョンへアップグレードするようにスケジュールが組まれます"。例えば安定版リリース候補で稼働しているネットワークでは、新しい安定版リリース候補のファームウェアが適用されます。

自動アップグレードプロセスは段階的にすべてのネットワークに展開されますが、前述の理由により遅延する可能性があるため、一部のオーガナイゼーションでは手動によるアップグレードプロセスが必要となる場合があります。より都合の良い時期にアップグレードを実施したい場合には、オーガナイゼーション > ファームウェアがアップグレードから手動でアップグレードする日時を指定することを強く推奨しています。

自動ファームウェアアップグレードがスケジュールされると管理者およびネットワークアラートの受信者に通知され、ダッシュボード上部にもバナーでお知らせが表示されます。通常ファームウェアアップグレードは通知が送信されてから最低でも 7 日以上空けて実施されます。

例えばアップグレードウィンドウが水曜日深夜12時に設定されている状態で、木曜日に自動ファームウェアアップグレードがスケジュールされたとします。このときスケジュールされる日時は次の水曜日では 7 日を下回るため、翌々週の水曜日になります。

このファームウェアアップグレードプロセスは中止できませんが、別の日時に変更することは可能です。

自動ファームウェアアップグレードはネットワーク単位で実施されます。そのため、オーガナイゼーション内で同じデバイスタイプでもアップグレード対象にならないネットワークが存在する可能性があります。

また、自動アップグレードは一定のスケジュールで行われるものではないため、例えば古いベータ版ファームウェアで稼働しているネットワークで、新しいベータ版がリリースされても即座にアップグレード対象になるとは限りません。

ネットワークによっては、様々な理由でファームウェア・アップグレードがスケジュールされない場合があります。ネットワーク管理者は、定期的にすべてのネットワークのファームウェア・アップグレードをチェックし、そのような場合には手動で最新のファームウェア・バージョンにアップグレードすることを推奨します。

一般的なファームウェアアップグレードのベストプラクティス

Meraki はデバイスの管理を直感的に行うという約束の下に作られましたが、これはファームウェア管理にも当てはまります。Meraki ダッシュボードにより、Meraki は高品質なファームウェアを構築・リリースすることができ、ユーザーは最新の機能や高品質、高セキュアなソフトウェアにアクセスできます。基本的には初期状態のシンプルで自動かつシームレスなアップグレードを推奨しています。デフォルトでは新しいファームウェアがリリースされるとアップグレードの予定が自動的に組まれるようになっています。なお、ファームウェアは事前に充分な検証、テストを経てリリースされています。

ファームウェアアップグレードに関するデフォルトの設定は以下のとおりです。

ベータ版ファームウェア : 自動アップグレードの対象外
アップグレードされる日時 : 水曜日午前 12 時

Meraki では平均して四半期に一度新しいファームウェアを各製品群に展開しています。このサイクルによりユーザーは新たに実装された機能に即座にアクセスでき、またファームウェアバージョン間の大幅な変化を最小限に抑え、高品質なソフトウェアの提供が確保されています。

自動アップデートの予定が組まれると予定された日にちの 2 週間前に管理者へその旨が通知されます。この 2 週間内に管理者は予定日時を変更することができます。各組織に最も適した曜日・時刻を設定することを推奨しており、その設定をネットワーク全体 > 一般でデフォルトの日時として指定留することもできます。

先進的で新しい機能を利用したい場合には”ベータファームウェアを試す”の設定を有効にすることを推奨します。この設定を有効にするとファームウェア開発サイクルにおける自動および手動内部テストプロセスが完了したファームウェアを早期に利用することができます。ベータ版ファームウェアをインストールした場合、新機能をいち早く利用できるだけでなく新機能が広く利用可能となる前に弊社へフィードバックを送ることができます。新しいベータ版ファームウェアで何らかの問題が発生した場合にはいつでも以前の安定版へロールバックできます。あるいは 14 日以内であれば直近でインストールしていたファームウェアバージョンへロールバックできます。14 日以降でロールバックをご希望の場合には Meraki サポートへお問い合わせください。

テンプレート

設定テンプレートを使用すると複数の拠点に同じ設定を同時に展開することができます。ネットワークがテンプレートに紐付いている場合ファームウェアもテンプレートで管理されるため、テンプレートで設定されたものとは異なるファームウェアバージョンをインストールすることはできません。Meraki サポートでは特定のデバイスのファームウェアを個別にアップグレードする機能を有しています。しかしながら、これが適用されたデバイスは今後の通常のファームウェアアップグレードができなくなるため注意が必要です。

複数拠点展開時のベストプラクティス

Meraki のファームウェアの仕組みを理解できたところで、これを活用して自信をもってネットワーク内のファームウェアを管理する方法について説明します。

上図のとおり大規模ネットワークを管理している場合にはファームウェアは段階的に展開することを推奨します。この手法を採用することで新しい機能を全体に展開する前に新機能やその安定性を検証することができます。

検証用ネットワーク ( Beta - ベータ)

ベータ版がリリースされた際には専用の検証用ネットワークを 1 つあるいは複数用意することを推奨します。検証用ネットワークとは通例ラボネットワークあるいは小規模ですが新機能を試すのに充分なデバイスを備えた本番環境です。組織内において様々な規模の本番環境がある場合にはそれぞれの規模と同等の検証用ネットワークを用意すると最善です。

ベータ版ファームウェアを検証すべき理由

ベータ版ファームウェアは前述のベータ版リリースプロセスのとおり厳格な検証を経ていますが、ベータ版ファームウェアを検証用ネットワークで試すことを推奨します。お客様固有の環境で検証を行うことで実際の環境で問題なく動作することが保証されます。

ベータ版ファームウェアに対するフィードバック

ベータ版ファームウェアを展開中に何らかの問題・不具合が確認された場合、Meraki サポートへお問い合わせください。お問い合わせいただくことで社内プロセスに則り報告された事象が社内で確実に記録されます。ケースを起票することで調査に必要な情報を収集し、それらを解決のためにエンジニアリングチームに提示できるようになります。解決策の一環として、解決策の有効性を確認するためのホットフィックス(一般的にはパッチとも呼ばれます)が提供されることがあります。ホットフィックスによって問題が解決したことが確認されると、ファームウェアリリースプロセスを経て新しいベータ版に適用され、検証を継続することができるようになります。

安定版候補用ネットワーク ( Validate - 検証)

ベータ版ファームウェアの検証が完了した後は、メジャーバージョンが安定版候補(RC)に移行するまで待つこともできますが、検証済みベータ版に特に問題がなかった場合には残りのネットワークに適用することもできます。本番環境では安定版ファームウェアのみを使用するというポリシーがある場合には次のステップとして安定版候補ファームウェアを検証用のネットワークに展開します。ファームウェア展開プロセスで記載があったとおり、RC ファームウェアは安定版に非常に近いため、本番環境のより多くのネットワークに展開することができます。この段階ではすべての新機能は検証済みであり、ネットワークを通じて広く展開することを重点が置かれているため、広範な検証計画を練る必要はありません。安定版ファームウェアで何らかの問題が発生した場合には安定版候補で解決している可能性があるので安定版候補へアップグレードすることを推奨します。

安定版ネットワーク ( Full Deployment - 全拠点展開)

ファームウェアが "安定版" へ移行したら残りのネットワークへファームウェアを展開する準備が完了したことになり、アップグレードツールを使うか、自動アップグレードプロセスが開始されるまで待つことができます。ベストプラクティスに従って安定版を試験、検証することで自信を持って固有環境でもファームウェアを展開できます。

新しいベータ版あるいは安定候補が期待するとおり機能していて全体で利用したい場合はそのまま全体へ適用して構いません。Meraki は開発プロセスのすべての段階で高品質のファームウェアを提供するよう努めています。しかしながら展開後に何らかの事象が発生した場合にはいつでも簡単に以前の安定版へロールバックできます。.

MR ファームウェアを展開する際のベストプラクティス

Meraki アクセスポイントの拡大に並行して今日の展開に求められる高性能で高可用性のネットワークを提供することに注力し続けています。この目標を達成するために Meraki ではアップグレード中のダウンタイムを最小限に抑えながら計画の柔軟性を維持し、なおかつアップグレードメンテナンス枠の正確性を保つことに重点を置いています。殆どの Meraki アクセスポイントはアップグレード後 1 分以内に再起動するためたとえ勤務時間帯にアップグレードを実施する必要があった場合でもエンドユーザーの業務中断を最小限に抑えることができます。

Meraki ではファームウェアアップグレード体験の向上やさらなるネットワークのダウンタイム最小化のために日々取り組んでいます。詳しくは Access Point Firmware Upgrade Strategy(英語表記) をご参照ください。

また、Meraki 無線ネットワークを稼働させている場合、Wi-Fi ファームウェア展開を各自に遂行するためにいくつか留意すべきことがあります。1 つ目はネットワーク内のすべての AP で必ず同じファームウェアに揃えることです。多くの Wi-Fi 機能が各 AP 間ですべて同じ動作をすることを前提に作られているためです。例えば、殊に L3 ローミング機能においては各ファームウェアバージョン間で互換性がない場合があります。

2 つ目は無線ネットワークをアップグレードした際に古いネットワークドライバーを使用しているクライアント機器では新機能利用時に問題を抱える可能性があることです。MR ファームウェアをリリースする前に Meraki では様々なノート PC、スマートフォン、固有の無線チップセットを搭載した旧世代の無線機器を含む 100 台の異なるデバイスで試験を行っていますが、試験用に 1 台アクセスポイントを用意し環境固有の可能性があるクライアントを試験しておくといいでしょう。環境固有の可能性があるクライアントとは例えば業務遂行に必要な専用の POS システムやバーコードスキャナーが含まれるかもしれません。繰り返しますが最新のベータ版 MR ファームウェアを環境固有の可能性があるクライアントで試験しておくことはベストプラクティスの 1 つです。これは開発サイクルの早い段階で相互運用性に影響を及ぼす可能性がある問題に Meraki 側でいち早く気付けるようになるためです。

これらの基本的なベストプラクティスに加え、Meraki のアクセスポイントでは大規模なファームウェアアップデートを改善する製品ライン独自の機能があります。

大規模無線ネットワークにおけるベストプラクティス

従来は大規模なキャンパス内無線ネットワークを運用している場合、無線機器のファームウェアをアップグレードすることはリスクが高いと考えられてきました。Meraki エンジニアで採用されている迅速でクラウドベースのファームウェア開発プロセスにより、リスクの高いファームウェア展開を低リスクに抑える対策を取ることができるようになりました。Meraki のベストプラクティスはファームウェアを試験、検証するために他のネットワークと孤立したエリアを設けることです。これは大規模なネットワークであってもです。 Meraki MR 試験用エリアがあれば物理環境における Meraki の無線ファームウェアを検証できます。これによりソフトウェア開発の早い段階で Meraki のエンジニアと直接関わることができ、新機能へのフィードバックやネットワークの展開に影響を及ぼす恐れのある問題を特定する手助けとなります。

上の例ではカフェテリアと大会議室を Meraki 試験エリアとして設定しています。このエリア内にあるアクセスポイントはメインのネットワークとは別のネットワークに移動させ、（ベータ版) ファームウェアをインストールできるようにしています。こうすることで試験用のアクセスポイントは必要であればメインのネットワークに戻すことで手早く安定版へロールバック可能になります。

この運用が理想的である理由は以下のとおりです。

このエリアには 6 台のアクセスポイントがあり、試験を実施するには充分な数であること
このエリアには様々なスマートフォンやノートPC が持ち込まれるため多様なクライアントデバイスが存在すること
ほぼすべての従業員が１日のうちに度々このエリアに出入りしていること
このエリアは業務上重要なエリアではないため潜在的な無線の問題への影響はユーザーに取って御しやすいものであること

試験環境で現在のファームウェアが問題ないことを確認できれば、安心して残りのネットワークにアップグレードを展開できます。この例では試験用エリア内外を行き来した場合にローミングの問題が発生する可能性があることに注意してください。これはエリア内外でファームウェアバージョンが違うことでローミングがシームレスに行われない可能性があるためです。

MS ファームウェアを展開する際のベストプラクティス

ネットワーク構築がスイッチングの段階まで進んだときにさらに考慮しておくべきことがあります。1 つはスイッチのトポロジーです。アクセス層を離れ、コア層に近づくにつれてファームウェアアップグレード中のリスクが高まるためです。 Meraki のスイッチファームウェアを管理する上で独自の機能として以下の 2 つが実装されています。

段階的アップグレード : アップグレードを論理的に分けられたグループ毎に展開できます。例えばリスクが低いアクセス層から始めてコア層へ展開するするなど
スタックスイッチの自動アップグレード

円滑な移行を確保するために Meraki スイッチをアップグレードする際には各グループ、段階毎に充分なアップグレード時間枠を設定してください。各アップグレードサイクルにおいて、新しいバージョンのダウンロード、アップグレードの実行、STP や OSPF などのプロトコルによるネットワークの再収束が行われるため充分な時間を設ける必要があります。また、アップグレード後に新たな問題が見つかった場合にはロールバックする時間も必要になります。

スイッチのアップグレードプロセスは以下のとおりです。

ファームウェアのダウンロードを開始 (要する時間は接続環境に依る)
配下に存在するファームウェアがダウンロードを完了させるまでの猶予として 20 分待機
新しいファームウェアのインストール、および再起動(約 1 分間)
ネットワークプロトコルの再収束 (設定に依る)

Meraki のスイッチでは "Safe Configuration" というメカニズムが導入されており、設定変更によりスイッチがオフラインあるいは再起動するようなことがあった場合に直前の設定 (Safe) に戻ることができるようになっています。通常の運用でスイッチが一定期間問題なく機能している場合（殆どの場合 30 分、ファームウェアアップグレード後の場合は 2 時間) その際の設定は "Safe" とみなされます。

スイッチが初めてオンラインになった時あるいはファクトリーリセットが行われた直後は "Safe" 設定ファイルが生成されます（既存の Safe ファイルが存在しないため) 初回起動時に連続して再起動されるとこの設定ファイルが失われオンラインにならないことがあります。そのような場合には復旧するためにファクトリーリセットが必要になります。

そのため、初めて起動する場合やファクトリーリセットを実施した場合はスイッチをオンラインの状態を 2 時間維持することを推奨します。

段階的アップグレード

複雑なスイッチネットワークの管理をよりシンプルにするために、Meraki では自動化された段階的なファームウェアアップグレードをサポートしています。これにより管理者は簡単にスイッチをグループ分けし、アップグレードするスイッチを分割できます。アップグレードの予定を組むと下図の例のようにアップグレードを複数の段階(Stage) に分けることができます。この例の場合、アクセス層のスイッチを "Stage 1" とし、段階的にコア層の Stage 3 へとアップグレードを進めていきます。段階的アップグレードが始まると Stage 1 のすべてのスイッチは Stage 2 のアップグレードが開始する前にアップグレードを完了します。このサイクルは全 Stage のアップグレードが完了するまで続きます。

スタックスイッチのアップグレード

段階的アップグレードのサポートに加え、Meraki ではスタックスイッチの管理もシンプルです。アップグレード機能の一部としてスタックスイッチ全体のアップグレードを自動的に制御するようになっています。具体的には各スイッチのファームウェアアップグレードの管理とスタック構成内での再起動するタイミングの調整を行っています。段階的アップグレードでスタックスイッチをアップグレードする場合、自動的にスタック全体をアップグレードするようになっています。スタックのアップグレードプロセスも前述のプロセスに準じています。つまり各スタックメンバーはほぼ同時に再起動し、メンバーがオンラインになると自動的にスタックを組むようになっています。

MX ファームウェアを展開する際のベストプラクティス

Meraki で提供している他の製品とは異なり、MX アプライアンスや Z シリーズデバイスは 1 つのダッシュボードネットワークに原則 1 台のみです。そのため展開時にはより細かい制御が可能です。

ファームウェアアップグレードが行われると MX は必ず再起動します。殆どの場合、これによりローカルネットワーク全体が一時的にダウンするため適切なメンテナンス時間を設定してください。MX デバイスはネットワークの中心、アップストリームであるため、メンテナンスが正常に完了するようにアップグレード完了後にモニタリングやテストを行う充分な時間を確保することも推奨します。

多くの MX のアップグレードを展開する際は以下のベストプラクティスに従うとファームウェアの移行や管理をよりシンプルにできます。

HA 構成のアプライアンスネットワークにおけるアップグレード

MX アプライアンスをウォームスペア (High Availability = HA) 構成として運用している場合(ルーターモード、VPNコンセントレーターモードを問わず) 、ファームウェアアップグレード時のダウンタイムが 0 になるような手順が自動的に行われるようになっています。これは以下のプロセスによって行われます。

プライマリ MX がファームウェアをダウンロードする
プライマリ MX が VRRP の送信を止める
セカンダリ MX がマスターとなる
プライマリ MX が再起動する
プライマリ MX が再びオンラインとなる
プライマリ MX が VRRP の送信を再開する
プライマリ MX が再びマスターとなる
セカンダリ MX がファームウェアをダウンロードする (元々予定されていたアップグレード時刻のおよそ 15 分後 )
セカンダリ MX が VRRP の送信を止める
セカンダリ MX が再起動し、再びオンラインとなる

AutoVPN 環境におけるファームウェアアップグレード展開

VPN コンセントレーターをアップグレードする際は余裕を持ったメンテナンス時間を計画しアップグレードが完了し、VPN トンネルがすべて確立されネットワークシステムが正常に戻ったことを確実に確認できるようにしてください。

アップグレードを実行するネットワークの規模や複雑さにあわせたメンテナンス時間を設けることを推奨しています。例えば 10 拠点をスポークに持つ VPN コンセントレーターと、1000 拠点をスポークに持ち、データーセンターとダイナミックルーティングを行っているような VPN コンセントレーターをアップグレードするのでは後者のほうがメンテナンス時間は長めに確保したほうがいいでしょう。

ベータ版ファームウェアを VPN コンセントレーター上でテストしている場合はアップグレードが完了するまでの時間と完了後に動作検証を行うための時間をメンテナンス時間の中で計画するのがベストです。また手に負えない問題が発生した際に以前のバージョンへロールバックするための時間も確保しておくことを推奨します。

VPN コンセントレーターが HA 構成の場合には前述のプロセスに従います。プライマリがアップグレード中はスペアへ VPN トンネルが確立され始めますが、アップグレードは通常迅速に完了するためスペアのコンセントレーターとのやり取りは最小限で済みます。

一般的に HA 構成であっても各スポーク拠点に一定程度の影響やダウンタイムがあることを常に想定しておくといいでしょう。殆どの場合スポーク拠点とコンセントレーター間で障害があってもはわずか数秒のことですが、データーセンターとスポーク拠点間の WAN (広域ネットワーク)接続で問題が発生した場合、その影響は顕著に現れます。

Meraki におけるファームウェア開発サイクル

Meraki がクラウド上で管理された機器を提供する企業であることの重要な利点の 1 つは完全な自動の内部テストを活用できることであり、同時にクラウドを活用してユーザー全体ベースでデバイスの主要なパフォーマンス指標をモニタリングできることです。堅牢で信頼性の高いファームウェア開発を保証するため Meraki では一貫したソフトウェアリリースプロセスに従い、一貫した信頼性の高いファームウェアを検証、展開しています。Meraki のファームウェア開発プロセスは”アルファ”、”ベータ”、”安定版リリース候補、"安定版" の” 4 段階に分かれます。各ファームウェアバージョンは最終的に安定版となることを目標に作成、リリースされています。開発プロセスの各段階で特定のビルドが主要な評価基準を満たさなかった場合新しいビルドが作成され、プロセスが新たに始まります。以降のセクションでは各段階について詳しく説明しています。

アルファプレリリース

メジャー、マイナー両方のリリースを含むすべての新しいファームウェアではすべてのビルドは社内の完全なアルファテストプロセスを経ています。ユーザーの手元へ届ける前に Meraki ではすべてのビルドで拡大し続けるテスト群を実行することで検証を行い、修正済み不具合の再発等がないか、新しい機能が想定通りに機能しているかをチェックしています。各製品ラインには各々に特化した自動および手動のテストがあり、それらは Meraki がソフトウェアや新機能の開発・拡大を続けている中で修正済み不具合の再発可能性を最小限に抑えられるように設計されています。

Meraki の基本理念の一環として、新しいビルドがテストを無事通過すると新しいファームウェアとしてリリースし、社内の個人およびエンジニアリングネットワークに展開します。Meraki はお客様がファームウェアを展開する前に我々自身がまずファームウェアを展開、実行することが重要だと考えています。このプロセスでは作成したビルドを新しいベータ版ファームウェアとしてリリースすることを検討する前に、実際の環境で新しいファームウェアを 1 週間あるいはそれ以上の期間実行します。

そのビルドが社内のすべてのリリース基準を満たした場合にはユーザーへの提供を開始します。解決する必要がある問題が発見された場合はプロセスをやりなおし、その問題を対応してからリリースを進めます。更に稀なケースではありますが、修正の難しさやタイミングにより既知リグレッションがあるビルドのリリースを進めることがあります。その場合、該当するリグレッションをリリースノートに記載します。

ベータリリース

新しいファームウェアは最初に "ベータ版”という形で利用できるようになります。ベータ版はユーザーが新機能を試したり不具合の修正を確認するために実環境で稼働させていることが多いです。ベータ版ファームウェアは既に内部でリグレッション、安定性、およびパフォーマンステストを済ませてあり、実際のネットワークへ適用する際のリスクを抑えています。"ベータファームウェアを試す" を選択しているオーガナイゼーションではベータ版がリリースされた際に自動的に通知され、アップグレードの予定が組まれます。ベータ版への自動アップグレードはファームウェアアップグレードツールでキャンセルあるいは日時の変更が可能で、ロールバックを行うこともできます。前述の設定をしていなくてもファームウェアアップグレードツールでいつでもベータ版ファームウェアへ手動でアップグレードすることも可能です。ベータ版ファームウェアは同業界の別製品で見られる "Early Deployment" と同様のものであると考えられます。

最新のベータ版はサポート窓口およびエンジニアリングチームでのサポートの対象です。古いベータ版ファームウェアについてはベストエフォートでの対応となるため、完全なサポートをご希望の場合には最新のベータ版へのアップグレードが必要です。

安定版リリース候補

新しいファームウェアバージョンがベータ版から成熟すると、安定版リリース候補へ移行します。移行に際し、ベータ版ファームウェアのパフォーマンスについて、弊社のソフトウェアおよびプロダクトチームにより正式なレビューが行われます。ファームウェアの品質は定量化のために重要業績評価指標（KPI）によって分析されます。これには、未解決のサポートケースやエンジニアリング上の問題、当該ファームウェアの採用状況、安定性に関する指標などが含まれます。正式がレビューを経て、ベータ版は”安定版リリース候補”へ移行します。この時点で、ファームウェアのバージョンは、ファームウェアアップグレードツールでも安定版リリース候補に表示されます。新しい安定版リリース候補が利用可能になった時点で、エンジニアリングチームは、一部のお客様の安定版および安定版候補で稼働しているネットワークにアップグレードのスケジュールを段階的に開始します。これらのアップグレードは、ファームウェアアップグレードツールを使用してキャンセル、変更、または元に戻すことができます。

最新の安定版リリース候補はサポートおよびエンジニアリングチームにて完全にサポートされますが、以前の安定版リリース候補についてはベストエフォートでのサポートとなります。最新のベータ版、安定版リリース候補、または安定版へのアップグレードにより、完全なサポートが保証されます。

安定版リリース

安定版リリース候補は、世界中のデバイスに徐々にロールアウトされながら、時間をかけて安定版へと成熟していきます。Merakiのインストールベースがメジャーバージョンの規定のしきい値に達すると（ノードの約20％）、そのファームウェアリビジョンは最終的な公式レビューを経て安定版に昇格します。マイナーリリースについては、ケースバイケースで決定されます。

この場合も、安定版リリース候補のレビューと同じKPIが分析されます。これらのプロセスが完了すると、ファームウェアは "安定版 "に昇格します。昇格後の安定版は、ダッシュボードのファームウェアアップグレードツールを使って、どのお客様でも適用することができます。最新の安定版は、特定のデバイスのために新たに作成されたすべてのダッシュボード・ネットワークに使用されるバージョンでもあります。

ファームウェアアップグレードツール

Meraki ファームウェアアップグレードツールを使用して上記のベストプラクティスをすべてシンプルに管理することができます。このツールは、製品ポートフォリオ全体のすべてのMerakiファームウェアを1つのダッシュボードで簡単に管理できるように設計されています。弊社の他のクラウド機能と同様に、使いやすさを向上させ、ファームウェア管理を新プリにするために、ファームウェアアップグレードツールにさらなる機能を構築し続けています。

"概要" タブでは、ダッシュボード内の最近のアップグレード一覧や自動または手動でスケジュールされた保留中のアップグレード、これらのアップグレードをキャンセルまたは再スケジュールする機能、特定のMeraki製品のベータ版、安定版リリース候補、安定版で利用可能なファームウェアバージョンのリストなど、さまざまな情報が表示されます。

ダッシュボードで利用可能なベータ版、安定版のリリース候補、安定版のファームウェアには、変更履歴ノートのリストが含まれています。これらのノートにより、既存のファームウェアとアップグレードを予定しているバージョンとの間に発見された新機能、バグ修正、および既存の既知の問題について、管理者は完全に把握することができます。また、設定テンプレートをご利用のお客様は、ファームウェア・アップグレード・ツールのメリットを享受することができます。

特定のファームウェアバージョンをリクエストする

互換性の理由で特定のバージョンのファームウェアが必要な場合は、Meraki サポートにリクエストすることができます。最新の安定版またはリリース候補版ではないファームウェアを実行中に発生した問題はサポートされませんので、トラブルシューティングを継続するために、Merakiサポートは最新版のファームウェアへのアップグレードを推奨する必要があることにご注意ください。

ファームウェアバージョンの固定

一般的には、ネットワーク全体をアップグレードするのではなく、特定のデバイスのファームウェアをアップグレードすることは推奨されません。しかし、トラブルシューティングの過程で、Meraki Support が特定のデバイスで特定のバージョンのファームウェアを試す必要があると判断することがあります。Merakiサポートによってファームウェアが手動で設定されているデバイスには、メッセージが表示されます。

Firmware version locked, please contact Support.

ロックされたファームウェアの追加や削除はスケジュールできないので、Meraki サポートに連絡して完了させてください。デバイスはネットワークのファームウェアに合わせて自動的にダウングレード/アップグレードされます。

その他ファームウェアに関するドキュメント

このベスト・プラクティス・ドキュメントに加えて、Meraki製品の導入に役立つその他のドキュメントもご参照ください。

概要