このページの内容

このネットワーク設定例について
ユースケースの概要
技術概要
設定例
まとめ

2メンバーQFXシリーズバーチャルシャーシのアップグレード

このネットワーク設定例について

このネットワーク構成例(NCE)は、ノンストップソフトウェアアップグレード(NSSU)プロセスが利用できない場合に、2メンバーのQFXシリーズバーチャルシャーシをアップグレードする方法を示しています。このプロセスにより、サービスの中断が最小限に抑えられ、データセンターのワークロードへの影響も最小限に抑えられます。QFXシリーズのNSSU機能は、JunosリリースノートのQFXシリーズセクションに記載されている特定のリリース間でサポートされています。

ユースケースの概要

バーチャルシャーシ機能は、QFXシリーズポートフォリオの重要な側面です。データセンターにおけるバーチャルシャーシの一般的なユースケースは、複数のトップオブラックスイッチを単一の論理エンティティに集約して、高可用性ペアの管理と運用を簡素化することです。このユースケースでは、サーバーのラックが2台のトップオブラックQFXシリーズスイッチにマルチホームされます。スイッチはバーチャルシャーシペアに設定されており、QFXシリーズデバイスのいずれかに障害が発生した場合にネットワークパスに耐障害性を提供します。

これらのデバイスでソフトウェアの更新が必要な場合は、通常、バーチャルシャーシのNSSU機能を使用してデバイスをアップグレードします。NSSUアップグレードは、接続されたサーバーへのサービスの中断を最小限に抑えるために、バーチャルシャーシメンバーデバイスをインテリジェントな順序で選択的にアップグレードします。

ただし、「開始」リリースと「終了」リリースが NSSU アップグレードプロセスをサポートしていないアップグレードシナリオによってはあります。これらのシナリオでアップグレードする場合、一連の手動操作を通じて同様の結果を得ることができます。このユースケースは、2つのリリース間のNSSU以外のアップグレードパスを対象としています。

技術概要

2 メンバーのバーチャルシャーシを手動でアップグレードするプロセスは、自動化された NSSU プロセスで実行される手順をよく似ています。このシーケンスでは、高可用性設計を活用して、アップグレードと再起動を実行するために 1 台のデバイスを体系的にサービスから削除します。サーバーノードが各デバイスにデュアルホームされている場合、ネットワークは、アップグレード期間中にバーチャルシャーシメンバーの 1 つが削除されても耐えることができます。プロセス中に全体的なネットワーク帯域幅が低下しますが、ネットワークは引き続き使用できます。

バーチャルシャーシ機能では、プライマリ/バックアップの概念を採用しており、バーチャルシャーシのメンバー間でデバイスの状態を同期した状態に保ちます。一方のデバイスがトラフィックを処理している間、もう一方のデバイスはオフラインにしてアップグレードします。両方のデバイスをアップグレードするには、次の手順に従います。

まず、すべてのトラフィックをプライマリデバイスにシフトします。
バックアップデバイスがサーバートラフィックを処理できなくなったら、バーチャルシャーシを分割します。
バックアップデバイスが完全に分離された状態で、バックアップデバイスのソフトウェアをアップグレードして再起動します。バックアップデバイスは、元のネットワーク設定のコピーを保持します。
アップグレードされたバックアップがオンラインになると、サーバーのトラフィックをプライマリデバイスからバックアップデバイスにシフトします。バックアップがネットワーク負荷を処理できるようになったら、プライマリデバイスをアップグレードして再起動します。
プライマリデバイスがオンラインになったら、トラフィックをプライマリデバイスに戻します。
最後に、2台のデバイス間のバーチャルシャーシリンクを再度有効にして、新しいソフトウェアバージョンを実行しているバーチャルシャーシペアを再作成します。

設定例

この構成例では、2メンバーのバーチャルシャーシをJunos OSリリース14.1X53-D49.1からJunos OSリリース18.1R2.6にアップグレードする方法を示しています。たまたま、これは NSSU 機能でサポートされる組み合わせではないため、以下に示す手動プロセスを使用します。

この例では基本的なバーチャルシャーシ構成を使用していますが、ここでのプロセスはさまざまなユースケースに適応できます。

要件
概要
設定

要件

この手順を使用して、QFX5100、QFX5110、QFX5220、またはQFX5200スイッチで構成される2メンバーのバーチャルシャーシの両方を同じJunos OSリリースバージョンにアップグレードします。この例のように、バーチャルシャーシの両方のメンバーを同じプラットフォームにすることを強くお勧めします。

始める前に:

バーチャルシャーシが2つのメンバーで構成されており、1つはプライマリメンバー、もう1つはバックアップメンバーとして構成されていることを確認します。
バーチャルシャーシモード(つまり、バーチャルシャーシファブリックモードではない)でバーチャルシャーシを設定します。
バーチャルシャーシがレイヤー2機能のみを実行している(つまり、IRBまたはルーティングプロトコルを実行していない)ことを確認します

この例では、以下のハードウェアおよびソフトウェアコンポーネントを使用しています。

Junos OSリリース14.1X53-D49.1を実行する2台のQFX5100-48S-6Qデバイス
Junos OSリリース18.1R2.6
Ubuntu Linux 16.04を実行するテストサーバー

概要

リリース間のアップグレードでは、移行中のダウンタイムを最小限に抑えるために、ネットワーク要素間で調整された特定の一連の手順が必要です。図に示すように、一般的な手順では、移行中にバーチャルシャーシへの冗長接続を備えた最新のサーバーの高可用性特性を活用します。

アップグレードの開始にあたっては、機能する2メンバーのバーチャルシャーシから始めます。私たちの目標は、トラフィックの中断を最小限に抑えて、新しいJunos OSリリースにアップグレードすることです。これを実現するために、バーチャルシャーシを分割し、メンバーデバイスをスタンドアロンユニットとしてアップグレードします。デバイスのアップグレード後、デバイスを再接続し、バーチャルシャーシを再確立します。

トポロジー

設定

手順

ステップバイステップの手順

デバイスをアップグレードするには:

バーチャルシャーシの状態を確認します。バーチャルシャーシのパラメーターを確認し、動作している2メンバーのバーチャルシャーシで作業していることを確認します。

新しいソフトウェアをバーチャルシャーシメンバーにアップロードします。新しいソフトウェアをバーチャルシャーシのプライマリデバイスとバックアップデバイス上の /var/tmp にコピーします。このステップでは、アップグレード手順のために両方のスイッチ上のソフトウェアをステージングします。Junos OSイメージの転送中は、コピー操作が完了するまでに時間がかかります。
メンバーが2人のみのバーチャルシャーシを形成する場合は常に、分割検出を無効にすることをお勧めします。分割検出を無効にしない場合、この例の後半でバックアップルーティングエンジンを無効にすると、プライマリデバイスがラインカードの役割を引き継ぎ、コントロールプレーンとデータプレーンを停止する可能性があります。

この NCE は完全に構成されたバーチャルシャーシで開始したため、このオプションは既に設定されているはずです。何らかの理由がない場合は、今すぐ設定してください。
バックアップルーティングエンジンのサーバー向けポートを無効にして、スイッチオーバー時の中断を最小限に抑えます。
バックアップルーティングエンジンに向けてVCPポートを無効にします。これにより、バーチャルシャーシが分割されます。
バックアップのルーティングエンジンをアップグレードします。18.2以降のJunosリリースにアップグレードする場合は、 force-host オプションを含める必要があります。これにより、ホストOSとJunosバイナリの両方が更新され、一致した状態が維持されます。
プライマリデバイスのサーバー向けポートを無効にし、同時にバックアップ上のサーバー向けポートを再度有効にして、サーバー向けポートを交換します。バックアップデバイスとプライマリデバイスに同じ設定を実装して、2台のデバイスがバーチャルシャーシの一部であったときに残った設定を変更します。

バックアップQFXで、まずプライマリデバイスのサーバー向けポートを無効にします。設定をコミットしない:
次に、以前の設定を削除して、バックアップでサーバーに接続するポートを再度有効にします。設定をコミットします。
プライマリQFXで設定を繰り返します。
プライマリルーティングエンジンをアップグレードします。18.2以降のJunosリリースにアップグレードする場合は、 force-host オプションを含める必要があります。これにより、ホストOSとJunosバイナリの両方が更新され、一致した状態が維持されます。
サーバーに面したポートをスワップして、プライマリデバイスに戻します。プライマリデバイスのサーバー向けポートを再度有効にして、バーチャルシャーシが復旧したときにLACPコンバージェンスを高速化します。バックアップデバイスとプライマリデバイスに同じ設定を実装して、2台のデバイスがバーチャルシャーシの一部であったときに残った設定を変更します。

バックアップQFXで、まず以前の設定を削除して、プライマリデバイスのサーバー向けポートを再度有効にします。設定をコミットしない:
次に、バックアップのサーバー向けポートを無効にして、設定をコミットします。
プライマリQFXで設定を繰り返します。

両方のボックスのVCPポートを再度有効にして、バーチャルシャーシを再確立します。

バーチャルシャーシを再確立したことを確認します。

両方のメンバーでアクセスポートを有効にします。バーチャルシャーシが再確立されたので、プライマリルーティングエンジンのem0アドレスを使用して、新しくアップグレードされたバーチャルシャーシと通信できるように、アクセスポートを再確立する必要があります。

プライマリQFXの場合:
注:
2メンバーのバーチャルシャーシにデバイスを追加する場合は、分割検出を再度有効にします。

2 メンバーのバーチャルシャーシをアップグレードしました。

まとめ

バーチャルシャーシは、データセンターの高可用性を実現するための重要なアーキテクチャ設計です。これで、データセンターのワークロードへの影響を最小限に抑えながら、2メンバーのQFXシリーズバーチャルシャーシを手動でアップグレードする方法がわかりました。NSSU が利用できない場合、または望ましくない場合、このドキュメントで説明されている手順を使用して、同様のトポロジーを持つバーチャルシャーシをアップグレードします。