Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページで
 

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

このネットワーク構成例について

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

「」も参照

ユース ケースの概要

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

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

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

技術概要

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

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

  1. まず、すべてのトラフィックをプライマリ デバイスに移行します。

  2. バックアップデバイスがサーバートラフィックを処理しなくなったら、バーチャルシャーシを分離します。

  3. バックアップデバイスが完全に分離された状態で、バックアップデバイス上のソフトウェアをアップグレードして再起動します。バックアップ デバイスは元のネットワーク設定のコピーを保持します。

  4. アップグレードされたバックアップがオンラインになると、サーバートラフィックがプライマリデバイスからバックアップデバイスにシフトされます。バックアップがネットワーク負荷を処理したら、プライマリデバイスをアップグレードして再起動します。

  5. プライマリ デバイスがオンラインになると、トラフィックがプライマリ デバイスに戻ります。

  6. 最後に、2台のデバイス間のバーチャルシャーシリンクを再度有効にして、新しいソフトウェアバージョンを実行するバーチャルシャーシペアを再作成します。

設定例

この設定例では、Junos OSリリース14.1X53-D49.1からJunos OSリリース18.1R2.6に2メンバーのバーチャルシャーシをアップグレードする方法を示しています。この機能は NSSU 機能でサポートされていないので、次に説明する手動プロセスを使用します。

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

要件

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

開始する前に、以下を行います。

  • バーチャルシャーシが事前プロビジョニングされていない場合、1つのメンバーがプライマリルーティングエンジン、もう1つのメンバーがバックアップルーティングエンジンであることを設定します。

  • バーチャル シャーシが 2 つのメンバーで構成されていることを確認します。

  • バーチャル シャーシ モードでバーチャル シャーシを設定する(つまり、バーチャル シャーシ ファブリック モードではない)

  • バーチャル シャーシがレイヤー 2 機能のみを実行していることを確認します(つまり、IRB またはルーティング プロトコルなし)

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

  • Junos OS リリース 14.1X53-D49.1 を実行する 2 台のQFX5100-48S-6Q デバイス

  • Junos OS リリース 18.1R2.6

  • Ubuntu Linux 16.04 を実行しているテスト サーバー

概要

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

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

トポロジ

構成

手順

手順

デバイスをアップグレードするには、以下の手順にしたがっています。

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

  2. 新しいソフトウェアをバーチャル シャーシ メンバーにアップロードします。バーチャルシャーシプライマリおよびバックアップデバイス上の /var/tmp に新しいソフトウェアをコピーします。このステップでは、アップグレード手順のために、両方のスイッチでソフトウェアをステージします。コピー操作は、Junos OS イメージの転送中に完了するまでにしばらく時間がかかります。

  3. メンバーが 2 つだけのバーチャル シャーシを形成するたびに、分割検出を無効にすることをお勧めします。スプリット検出を無効にしない場合、この例の後半でバックアップルーティングエンジンを無効にした場合、プライマリデバイスがラインカードの役割を担い、コントロールプレーンとデータプレーンを停止することがあります。

    このNCEをフル構成のバーチャルシャーシで起動したので、このオプションは既に設定されている必要があります。何らかの理由がない場合は、今すぐ設定してください。

  4. バックアップ ルーティング エンジンのサーバー側ポートを無効にして、スイッチオーバー中の中断を最小限に抑えます。

  5. バックアップ ルーティング エンジンに向けて VCP ポートを無効にします。これでバーチャルシャーシが分かります

  6. バックアップのルーティング エンジンをアップグレードします。18.2以降のJunosリリースにアップグレードする場合は、オプションを force-host 含める必要があります。これは、ホスト OS と Junos バイナリの両方が更新され、一致したままになります。

  7. プライマリ デバイスのサーバー側ポートを無効にし、バックアップ上のサーバー側ポートを同時に再有効化することで、サーバー側ポートを交換します。バックアップデバイスとプライマリデバイスに同じ設定を実装し、2台のデバイスがバーチャルシャーシに含まれている場合に残された設定を変更します。

    バックアップ QFX では、まずプライマリ デバイスのサーバー側ポートを無効にします。設定をコミットしないでください。

    次に、以前の設定を削除して、バックアップ上のサーバー側ポートを再度有効にします。設定をコミットします。

    プライマリ QFX で設定を繰り返します。

  8. プライマリ ルーティング エンジンをアップグレードします。18.2以降のJunosリリースにアップグレードする場合は、オプションを force-host 含める必要があります。これは、ホスト OS と Junos バイナリの両方が更新され、一致したままになります。

  9. メモ：

    この手順に従うのは、事前プロビジョニングしていないバーチャル シャーシの場合のみです。バーチャル シャーシが事前にプロビジョニングされている場合、メンバーシップの選択は、プライマリ ルーティング エンジンが事前に設定されていない場合のシステム稼働時間に基づきます。

  10. サーバー側のポートをプライマリ デバイスにスワップします。プライマリ デバイスのサーバー側ポートを再度有効にして、バーチャル シャーシが復帰したときに LACP コンバージェンスを高速化します。バックアップデバイスとプライマリデバイスに同じ設定を実装し、2台のデバイスがバーチャルシャーシに含まれている場合に残された設定を変更します。

    バックアップQFXでは、以前の設定を削除して、プライマリデバイス上のサーバー側ポートを最初に再度有効にします。設定をコミットしないでください。

    その後、バックアップのサーバー側ポートを無効にして、設定をコミットします。

    プライマリ QFX で設定を繰り返します。

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

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

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

    プライマリ QFX 上:

    メモ：

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

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

結論

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