2 つの CF VM がアクティブ/スタンバイ（1:1）冗長ペアとして機能します。アクティブ CF は次の機能を果たします。

• コントローラのタスク

• ローカルコンテキスト VPNMGR

• ローカルコンテキスト（MGMT）と DI ネットワーク vNIC

• vHDD のシステム起動イメージと設定ストレージ

• vHDD のレコードストレージ

• CLI およびロギング用のアウトオブバンド（OOB） 管理（vSerial と vKVM）

SF VM は、サービスコンテキスト（ユーザ I/O ポート）を提供し、プロトコルシグナリングおよびセッション処理タスクに対応します。VPC-DI インスタンスは最小 4、最大 14 の SF VM を持つことができ、最大 12 の SF VM をアクティブにできます。

各 SF VM は、CF に指定されているとおりに 3 つのロールのいずれかを動的に実行します。

• Demux VM（フロー割り当て）

• セッション VM（トラフィック処理）

• スタンバイ VM（n+1 冗長性）

SF は次の機能を担当します。

VPC-DI インスタンスの最小設定では、4 つの SF の 2 つのアクティブ、1 つの demux 、および 1 つのスタンバイが必要です。

VPC-DI インスタンス内の VM が相互に通信するためには、各インスタンスに VM をインターコネクトするプライベート L2 ネットワークが必要です。このネットワークは、IaaS/仮想化インフラストラクチャ内の VLAN を使用し、最初の vNIC として各 VM にタグなしで公開されるようにする必要があります。

DI ネットワークは、単一の VPC-DI インスタンスを排他的に使用する必要があります。他のデバイスがこのネットワークに接続されていない可能性があります。アクセスを制限するセキュアなネットワークである必要があります。

（注）	1 つのデータセンター内で複数のインスタンスをインスタンス化する場合は、各インスタンスに独自の DI ネットワークが必要です。

インスタンス内のすべての VM は、物理的に同じサイトに配置する必要があり、理想的には最小限の相互接続デバイスとともに同じいくつかのラックに配置します。DI ネットワークの信頼性は、VPC-DI インスタンスの安定性を確保するために重要です。WAN または輻輳状態のリンク全体で L2 トンネリングプロトコルを使用することは推奨されません。

SF ポートを使用して、ベアラーとシグナリングパケットを送受信します。ネットワーク設定とアドレスの使用をシンプルにするため、すべての SF に接続する必要があるのは、高帯域幅（ベアラー）パケット用の VLAN のみです。低帯域幅インターフェイス（シグナリング）は 2 つの SF のみに接続できます。次の図では、ベアラー VLAN はすべての SF に接続され、シグナリングとその他の VLAN は最初の 2 つの SF のみに接続されています。

（注）	この非対称の配置は、必要なインターフェイスの数は少なくなりますが、2 つの VM の損失によりサービスが損失することになるため、障害については慎重に検討する必要があります。

ECMP はハッシュに基づく負荷分散を行い、任意の SF VM にトラフィックを送信できます。

入力では、SF はフロールックアップを実行し、特定の SF 上の特定の SESSMGR タスクにパケットを転送します。この入力トラフィックの一部は、ローカル SESSMGR タスクによって処理されます。それ以外の場合は、DI ネットワークを介して正しい SF にリレーされます。出力では、各 SF がローカルポートからパケットを送信します（ECMP を使用している場合）。ほとんどの場合、パケットが通過する VM の数は 2 未満です。ただし、ACL とトンネリングにより、EPC の設定に応じて、特定のフローのホップ数を増加させる可能性があります。

VPC-DI インスタンス内の各 VM は、1 つの CPU サブシステムを備えた仮想カードとして表されます。これにより、多くの CLI コマンド、ログ、および機能は、ASR 5500 プラットフォームで実行されている StarOS と同様に動作します。

コンテキスト、サービス、プール、インターフェイス、カード、およびポートの StarOS の概念は、ASR 5500 プラットフォームの場合と同様に各 VM に存在します。

VM が起動すると、VM プロファイル内に設定された vNIC が検出され、「仮想イーサネット」タイプのポートに相当する数が StarOS CLI に表示されます。

vNIC の順序を手動で指定するには、起動パラメータファイルの作成を参照してください。

デフォルトでは、システムはハイパーバイザが提示する順序で vNIC インターフェイスを割り当てます。

• CF VM（スロット 1 および 2）

  • 最初に提示されるインターフェイス（1/0 または 2/0）は DI ネットワーク用です。

  • 2 番目に提示されるインターフェイス（1/1 または 2/1）は 管理ネットワーク用です。

• SF VM（スロット 3 ～ 16）

  • 最初に提示されるインターフェイス（slot /0）は DI ネットワーク用です。

  • トラフィックインターフェイス slot /10 ～ slot/21 は、IaaS VLAN 制御トラフィックとデータトラフィック用です。

    （注）	StarOS は最大 12 個のサービスポートをサポートしますが、実際のポート数はハイパーバイザによって制限される場合があります。

サポートされているハイパーバイザにリストされているインターフェイスと、KVM ブリッジグループまたは VMware vSwitch が VM インターフェイスと一致させる順序で一致していることを確認する必要があります。

（注）	ハイパーバイザの CLI や GUI にリストされている vNIC の順序が、ハイパーバイザが VM に提供する方法と同じであることは保証できません。初期設定では、show hardware CLI コマンドを使用して、ハイパーバイザ vNIC 設定に表示されている MAC アドレスを調べ、VM によって学習された MAC アドレスと一致させる必要があります。これにより、VM インターフェイスが目的のブリッジグループまたは VMware vSwitch に接続されていることが確認されます。

VPC-DI インスタンス内の VM は、ソフトウェアベースの暗号化とパケットのトンネリングを実行します（高いスループットのハードウェアベースのサービスとは異なります）。ベアラーパケットの暗号化を多用するコールモデル、または重要な PKI（公開キーインフラストラクチャ）のキー生成レートを持つコールモデルでは、重要なコンピューティング リソースが必要になる場合があります。

COTS サーバハードウェアが Intel 89xx チップに基づいて Coleto Creek のチップセットを使用している場合、システムはパケットの暗号化と復号化にこのハードウェアチップを自動的に利用します。ただし、システムが暗号化と復号化にハードウェアチップセットを使用するためには、すべてのサービス機能 Vm でこのチップセットを使用する必要があります。

外部トラフィックのセキュリティは、トンネリング、暗号化、Access Control List（ACL; アクセスコントロールリスト）、コンテキストの分離、およびユーザ認証機能など、既存の StarOS プラットフォームと同様の機能を備えています。CF および SF 上のユーザポートおよびインターフェイスは、StarOS の CLI 設定によって保護されます。

仮想システムでは、データセンター機器の DI ネットワークを介してネットワーク通信が行われるため、お客様側にさらにセキュリティ上の懸念が生じます。

DI ネットワークは、システムネットワークの VLAN のメンバーシップをその特定の VPC-DI インスタンス内の VM に制限することによって、データセンター内の他のホストから分離する必要があります。ネットワークに誤って追加された他のホストによる DI ネットワークへの不正アクセス、またはルータ、スイッチ、またはハイパーバイザの侵害によって、StarOS のセキュリティ対策が中断または回避される可能性があります。このような中断により、障害、サービスの損失や、制御とベアラーパケットの検出が発生する可能性があります。DI ネットワークへのアクセスを適切に保護することは、StarOS の制御の範囲を超えています。

DI ネットワークコンポーネント（CF および SF など）の VM 間の通信は、外部から提供された SSH キーによる認証によってのみ可能になりました。さらに、システムは、DI ネットワーク内のログインに公開/秘密キーベースの SSH 認証を適用します。パスワード、キー、または LI 情報は保存されず、クリアテキストで送信されます。

オペレータが、管理およびベアラーの LI （合法的傍受）などネットワークを物理的に分離する必要がある場合は、センシティブデータを伝送するため、DI ネットワークの物理的な分離も実行する必要があります。仮想環境では、ネットワークの物理的な分離は不可能な場合、または実用的でない場合があります。これらの要件を持つオペレータは、必要に応じて十分な保護を提供することを確認するために、ハイパーバイザとインフラストラクチャを調査する必要があります。

仮想システムは、リソースの冗長性と可用性全体の基盤となるハードウェアとハイパーバイザに依存しています。StarOS は、その上部でシステムの冗長性を処理します。

ハードウェアとハイパーバイザには、次が備わっている必要があります。

• 実際の冗長ハードウェアコンポーネント（電源、ディスクなど）

• 冗長ネットワークパス（デュアルファブリック/NIC、自動フェールオーバー搭載）

• 冗長ネットワークアップリンク（スイッチ、ルータなど）

基盤となるインフラストラクチャ（ホスト、ハイパーバイザ、およびネットワーク）に期待値を超える可用性と信頼性が備わっている場合にのみ、高可用性を実現できます。システムは、実行されている環境と同じ信頼性のみを備えています。

シャーシ間セッションリカバリ（ICSR）は、冗長ではないハードウェア（CPU、メモリ、マザーボード、ハイパーバイザソフトウェアなど）に障害が発生した場合に、可用性を高め、リカバリ時間を短縮するためにも推奨されます。ICSR は、ゲートウェイのセッションレベルでのみ冗長性を提供します。

2 つの CF VM は、VPC-DI インスタンスおよびローカルコンテキストポートやローカル管理ポートを制御するために 1:1 冗長化されています。

両方の CF の管理ポート vNIC は相互に 1:1 冗長であり、インフラストラクチャ内の同じ VLAN に配置する必要があります。一度に 1 つの管理ポートのみがアクティブになります。

（注）	ホストまたはハイパーバイザに障害が発生した場合に冗長性を確保するために、2 つの CF VM を同じ物理ホスト（サーバまたはブレード）上で実行することはできません。

SF VM ごとに、サービスポートのネットワーク接続が提供されます。各 SF には 1 つ以上のポートと関連付けられたインターフェイスがありますが、SF はペアリングされていないため 1:1 の冗長性を提供しません。

SF ポートの冗長性は、ECMP またはサポートされている別の L3 プロトコルを使用して確立する必要があります。

インスタンスに必要な合計スループットは、セッションリカバリが有効になっている N-2 SF を超えないようにする必要があります。これにより、1 つの SF が失敗しても、他の SF が負荷を引き継ぐことができます。サービス IP アドレスにループバックインターフェイスを使用することを強くお勧めします。

SF とピアルータ間のパス障害を検出するために BFD を使用することをお勧めします。これにより、障害が発生した場合に ECMP パスが除外されます。

セッションリカバリが有効になっている場合、1 つの VM が VPN/Demux になり、残りの VM はセッション処理 VM になります。スタンバイ SF は、他の SF に応じて冗長性を提供できます。

（注）	各 SF VM は、ホストまたはハイパーバイザに障害が発生した場合に冗長性を確保するために、別の物理ホスト上で実行する必要があります。

VPC-DI は、StarOS ソフトウェアリリースで ICSR をサポートするサービスの 2 つのインスタンス間で ICSR をサポートします。複数のサービスタイプが使用されている場合は、ICSR をサポートするサービスのみが ICSR を使用できます。

（注）	2 つの VPC-DI インスタンスは、異なる DI ネットワーク上にある必要があります。

ICSR は、サイト/行/ラック/ホストの停止や主要なソフトウェア障害の冗長性をサポートしています。これを行うには、重複しないホストとネットワークインターコネクト上で 2 つのインスタンスを実行する必要があります。ICSR は、同様に設定されたインスタンス間でのみサポートされます。VPC-DI インスタンスと別のタイプのプラットフォーム間の ICSR はサポートされていません。

L3 ICSR がサポートされています。

詳細については、このガイドの「シャーシ間セッションリカバリ」の章を参照してください。

システムでは、各 CF VM が次のように設定されている必要があります。

• 8 vCPU

• 16 GB RAM

• 最初の vNIC は DI ネットワークです。

• 2 番目の vNIC は管理ポートです。

• 最初の vHDD は、起動イメージと設定ストレージです（/flash、非 RAID、4 GB を推奨）。

• 2 番目の vHDD はレコードストレージ用です（オプション）（hd-local1、RAID、最小 16 GB を推奨）

（注）	両方の CF VM が同一に設定されている必要があります。

システムでは、各 SF VM が次のように設定されている必要があります。

• 12 個以上の vCPU（vCPU と vRAM のオプション を参照）。

  （注）	SF VM は起動せず、vCPU のこの最小要件が満たされていない場合は、次のエラーが報告されます。 Found hardware disparate in minimum number of cores, found n cores, minimum expected cores are 12.

• 32 GB 以上の vRAM（vCPU と vRAM のオプション を参照）。

• 最初の vNIC は DI ネットワークです。

• 2 番目とそれ以降の vNIC はサービスポートです。システムは最大 12 個の vNIC をサポートしますが、この数はハイパーバイザによって制限される場合があります。

• vHDD は起動イメージ用で、2 GB が推奨されています。

（注）	すべての SF VM が同様に設定されている必要があります。VM ハードウェア設定のモニタリングの詳細については、VM ハードウェアの検証を参照してください。

CPU は、システム全体とアプリケーションを単独で完全に実行でき、複数の物理 CPU コアの搭載が可能な 1 つの物理コンピュータチップです。仮想コアテクノロジーは、物理コアごとに複数の論理プロセッサ（vCPU）をサポートします。特定のプラットフォーム上でサポートされている vCPU の合計数は、使用可能な物理コアの数と、各コアに実装されている仮想コアテクノロジーのタイプによって異なります。

VM が NUMA ノードにまたがらないようにすることを推奨します。vCPU は基盤となる CPU に合わせます。パフォーマンスを最適化するために、VM が NUMA ノードにまたがらないようにします。

CF と SF は、多数の vCPU が割り当てられ、それぞれが 1 つのスレッド（命令のシーケンス）VM 内で実行します。プラットフォーム CPU でサポートされている使用可能な vCPU の数がハイパーバイザを介して VM に割り当てることができる vCPU の最大数を超える場合があります。

（注）	VM あたりの vCPU の数は、プラットフォーム CPU でサポートされている vCPU の最大数を超えてはなりません。

パフォーマンスを最大化するには、基盤となるハードウェアに合わせて、vCPU または vRAM の数を調整することが望ましい場合があります。SF は vCPU と vRAM のさまざまな組み合わせをサポートしますが、すべての SF がインスタンス内で同じ組み合わせを共有する必要があります。

ソフトウェアは、vCPU の数とその SF の vRAM の量に基づいて、SF の起動時に SF ごとに最適な SESSMGR タスクの数を決定します。

このリリースでは、次のような vNIC オプションがサポートされています。

• VMXNET3：VMware 用の準仮想 NIC

• VIRTIO：KMV 用の準仮想 NIC

• ixgbe：Intel 10 ギガビット NIC 仮想機能

• enic：Cisco UCS NIC

• SR-IOV：シングルルート I/O の仮想化 ixgbe インターフェイスと enic インターフェイス

システムは、vhost-net と vhost-user ベースの両方のバックエンドメカニズムと対話できる DPDK ベースのユーザアプリケーションに基づいて Virtio フロントエンドを実装します。vhost-user と vhost-net は、共有メモリベースの、イベント、および割り込み記述子を使用する vhost パラダイムの実装を提供します。DPDK ベースのフロントエンドドライバを vhost-net と vhost-user と組み合わせて使用すると、Linux ブリッジベースのデータパスと比較して、パフォーマンスの高いデータパスを実現できます。

• vhost-user は、ユーザ空間でパケットを完全に処理し、パフォーマンスを引き上げます。システムは DPDK ベースのユーザ空間アプリケーションにフロントエンドを実装しますが、ホストユーザ空間アプリケーションは vhost-user インターフェイスに基づいてバックエンドを実装します。

• vhost-net は、Virtio ネットワーキングのカーネルレベルのバックエンドを提供します。これにより、Virtio パケット処理タスクをユーザ空間 (QEMU プロセス) から移動し、カーネル (vhost-net ドライバ) に移動することで、仮想化のオーバーヘッドを軽減します。これにより、デバイス エミュレーション コードは、ユーザ空間からシステムコールを実行する代わりに、カーネルサブシステムに直接コールすることができます。

  システムは、vhost-user で 1 つのキューをサポートします。

必須/フラッシュ（非 RAID）ドライブに追加した場合、システムは仮想マシン（VM）の下で RAID1 をサポートします。VM ごとに、この表に示す SCSI ID と一致する仮想 SCSI ディスクを CF のみで作成できます。最小ディスクサイズは 16 GB を超えている必要があります。

記録ストレージ（CDR および UDR）の場合、CF VM には、予想される記録要件を満たすサイズの 2 番目の vHDD をプロビジョニングする必要があります（最小 16 GB）。レコードは、2 番目の vHDD 上の /records に書き込まれます。

StarOS は、事前にインストールされたディスクテンプレートを QCOW2 形式で使用して、各 VM にインストールされます。スロット番号は、ESC および OpenStack によって管理されます。スロット番号は、VM 設定の一部として割り当てられます。スロット番号は、インストール時に自動検出されます。ハイパーバイザからスロット番号を検出できるように、インストーライメージのインストールは完全に自動化されています。詳細については、ソフトウェアインストールおよびネットワーク展開を参照してください。

VM の vNIC の設定を制御する方法については、起動パラメータファイルの作成 を参照してください 。

各 VM は再起動し、VPC-DI インスタンスへの参加を試みます。ブートローダーは、自動起動（スクリプト）、ネットワーク起動、または手動起動によってインスタンスを起動します。

仮想 BIOS が完了すると、VM はローカル vHDD から起動し、CFE（共通ファームウェア環境）を実行します。CFE は、インストール中に作成されたパラメータファイルがあるかどうか、vHDD を検索します。このファイルが検出されて正しく解析された場合、CFE は VM のタイプとスロット番号に応じて異なるパスを取得します。いずれの場合も、最初の vNIC がネットワークのインターフェイスになります。

オペレータ展開ごとに、VPC-DI インスタンスをホストする L2 スイッチ上での帯域幅要件のモデリングが必要です。

主要なベアラートラフィックの他に、DI ネットワークは VM 間でセッションシグナリングと内部制御データも渡します。

内部制御トラフィックは冗長動作中は多くなりますが、通常動作時は大幅に低下します。次の場合に制御トラフィックの使用率が高くなります。

• アクティブ SF VM からスタンバイ SF へのタスクの移行

• スタンバイ SF の起動または再起動

• SF の起動または再起動

• SF またはスタンバイ CF の起動または再起動

• 大量のシグナリングトラフィック（1 秒あたりのコールイベント（CEP）レートが高い）

• CLI またはバルク統計情報の使用率が非常に多い

CEPS レート、設定、および管理操作に応じて、ベアラースループットに関係なく、各 VM は DI ネットワークインターフェイスに負荷をかけます。この負荷はばらつきが大きい可能性がありますが、平均して VM あたり 1 Gbps 未満です（他の VM よりも使用率が高い VM もあります）。