互換性マトリクス、リリースノートとファームウェアの変更

「サポート対象」とは、三つ組についての言明です——このモジュールが、このプラットフォームで、このソフトウェアリリースにおいて、という三つ組です。ベンダーはこの三つ組を互換性マトリクスとリリースノートで公開し、それを変更します——新しい光モジュールが加わり、古いものが外れ、検証がより厳格になります。購入前にマトリクスを読み、アップグレード前に読み直すことが、最も安上がりな互換性対策です。このページでは、情報がどこにあるか、どう読むか、そしてソフトウェアアップグレードが光モジュールの障害に変わらないようフリートを運用する方法を示します。

ベンダーがサポート情報を公開する場所

実行している NOS バージョンのリリースノートも確認してください。光モジュール関連の変更は「解決済みの問題」「動作の変更」「新しいハードウェアサポート」の項目の中に隠れています。

マトリクスの項目を読む

ソフトウェアで変わるもの

想定外を避けるフリート運用

1. 棚卸し — （スイッチ上またはベンチ上で）すべてのモジュールのベンダー、PN、シリアル、リビジョン、ファームウェアをポートごとに CMDB へ記録する。
2. リリースを固定する — NOS バージョンを互換性の三つ組の一部として扱う。アクセス層とコア層を同じ日にアップグレードしない。
3. アップグレードのたびに、光モジュール関連の項目についてリリースノートを読む。
4. 使用しているすべての種類の光モジュールを1つずつ用いて、ラボまたはカナリアスイッチで試験する——サードパーティ製とコーディング済みのモジュールを最初に。
5. 旧イメージを保持し、ロールバック計画を用意する。どのポートが errdisable になりやすいかを把握しておく。
6. 前後でDDM のベースラインを取得し、監視上の挙動変化を可視化する（監視）。
7. 光モジュール PN とその後継のEOL を追跡し、交換品がマトリクスと一致するようにする。

この構図におけるサードパーティ製・コーディング済み光モジュール

OEM の PN にコーディングされたモジュールは、オリジナルと同じマトリクスの項目で判断されます——コーディングが完全であれば、プラットフォームは違いを見分けられません——が、ベンダーのサポート言明はそのモジュールには及ばず、新しいリリースでの検証強化によって露呈することがあります。コーディング済みモジュールは棚卸し表で識別可能にしておき（実際のベンダーとシリアル）、アップグレード時には最初に試験し、リリースがその扉を閉じる場合に備えて計画を立ててください（サードパーティの光モジュール、 ベンダーロック）。

NIC とサーバー側

サーバーアダプターには独自のマトリクス（アダプター ↔ モジュール ↔ ドライバー／ファームウェア）と独自のポリシーがあります——一部の Intel ファミリーは、ドライバーパラメーターで許可しない限りリスト外の SFP を拒否します。Mellanox/Nvidia のアダプターは InfiniBand 用にケーブルを検証します。NOS のアップグレードと同様に、ドライバーとファームウェアの更新もこれらの規則を変えます（ポート設定のレシピ）。

CodingBox では

フリート運用のベンチ側の作業です。受入検査の際にすべてのモジュールの識別情報とファームウェアバージョンをCode databaseに読み込み、疑わしいモジュールのバイトをCheck transceiver でマトリクスの項目と照合し、コーディング済みかオリジナルかの区別をデータベースの備考に残しておくことで、アップグレード当日の拒否を数秒でモジュールまで追跡できるようにします。

ベンダーとオペレーティングシステムごとの NIC ドライバーとファームウェアのポリシーの詳細：NIC でのトランシーバー互換性。

コミッショニングチェックリストとしてのフリート運用——設定前のアップグレード、カナリア試験、DDM ベースライン、受入試験：選定とコミッショニング。