Cisco Crosswork Hierarchical Controller 7.0 インストレーション ガイド

はじめに

このドキュメントは、高可用性を備えた Cisco Crosswork Hierarchical Controller のインストールガイドです。Cisco Crosswork Hierarchical Controller では、ノード内復元力と、ノード間復元力、および地理的冗長性のための 3 ノードクラスタを導入します。

このドキュメントでは、次の項目を説明しています。

●        Crosswork Hierarchical Controller ノード内復元力

●        Crosswork Hierarchical Controller インストールの前提条件

●        Crosswork Hierarchical Controller のインストール

●        Crosswork Hierarchical Controller 3 ノードクラスタ

●        HA クラスタの設定

注記：HA クラスタの管理の詳細については、『Cisco Crosswork Hierarchical Controller Administration Guide』を参照してください。

Cisco Crosswork Hierarchical Controller ノード内復元力

Cisco Crosswork Hierarchical Controller ワークロードは、プラグインとコアコンテナで構成されています。

●        プラグインコンテナは、アプリケーションとアダプタです。

●        コアコンテナは、コアマネージャモジュール（Brain）、データベース、Web サーバーなどです。

プラグインとコアコンテナの両方が障害から保護されます。

●        プラグインコンテナの正常性ステータスが、Brain によってモニターおよびチェックされます。障害が発生した場合、Brain はコンテナを再起動します。プラグインコンテナはステートレスであり、新しいインスタンスは Brain に接続された後に起動され、呼び出しの受け入れを開始します。

●        コアコンテナは、docker-daemon および docker-compose によってモニターされます。障害が発生した場合、コアコンテナは docker によって自動的に再起動されます。これらのコンテナはステートフルであり、永続ボリュームを使用します。

docker が応答を停止すると、OS レベルの systemd ユーティリティが再起動します。

Cisco Crosswork Hierarchical Controller のアーキテクチャ

Cisco Crosswork Hierarchical Controller の前提条件

ハードウェア

サーバーノード

この仕様は、Crosswork Hierarchical Controller のアクティブインスタンスとスタンバイインスタンス、またはスタンドアロンインスタンスを対象としています。

ウィットネスノード

ウィットネス ノードは、Crosswork Hierarchical Controller の「3 ノードクラスタ」高可用性ソリューションの 3 番目のノードです。

オペレーティング システム

Crosswork Hierarchical Controller アプリケーションは、サポートされている次のオペレーティングシステムにインストールできます。

●        RedHat 7.6 EE または 5.9

●        Oracle Linux 8.4

●        CentOS 7.6

OS は、ベアメタルまたは VM（仮想マシン）サーバーにインストールできます。

クライアント（Client）

クライアントマシンの要件は次のとおりです。

●        PC または MAC

●        GPU

●        GPU ハードウェア アクセラレーションをサポートする Web ブラウザ

●        推奨

◦       画面の解像度 1920 X 1080

◦       Google Chrome Web ブラウザ

（注）    ネットワーク 3D マップのすべての利点を適正に活用するには、GPU が必須です。

ソリューションの規模

Crosswork Hierarchical Controller は、数十万のネットワーク要素と、シェルフ、ポート、リンク、トンネル、接続、サービスなどの数百万のサブ NE およびトポロジ要素を持つ非常に大規模なネットワークで、モデル化、分析、およびプロビジョニングといった操作を実行するように設計されています。このドキュメントでは、本ソリューションのスケールを分析します。

Crosswork Hierarchical Controller の機能と制限の詳細な分析に入る前に、このシステムは、約 12,000 の光学 NE と 1,500 のコアおよびエッジルータを備えたネットワーク上で数年間正常に展開され、現在では19,000 NEにまで拡大していることに注目できます。この展開では、機器への直接アクセスを使用します。これは、以下で説明するように、最も負荷のかかる使用例です。

Crosswork Hierarchical Controller のようなネットワークコントローラを設計する場合、次の潜在的な拡張性のボトルネックを考慮する必要があります。

●        NE との通信

●        データベースでのネットワークモデルの保存

●        UI でのデータのレンダリング

●        アプリケーションでのネットワークデータの処理

Crosswork Hierarchical Controller モデルのキャパシティは、現在次のように指定されています。

上記のモデルキャパシティは、シスコの展開実績に基づいていることに注意してください。もっと大きなネットワークキャパシティを処理するためにフットプリントを増やす（拡張する）ことが可能なため、実際の数はさらに大きくなります。必要に応じて追加のアセスメントも可能です。

Crosswork Hierarchical Controller GUI は、一般的なロールの分布状況で、次の数の同時使用ユーザーを管理できます。

ストレージ

Crosswork Hierarchical Controller の稼働に必要なストレージ容量は、パフォーマンスカウンタと毎日の DB バックアップに必要なストレージ容量によって異なります。

パフォーマンス モニタリング ストレージは、クライアントポートの数と、カウンタが保存される期間に基づいて計算されます。大まかに言って 1000 ポートごとに 700 MB です。

ストレージを計算するための詳細な式は次のとおりです。

<uncompressed data>=<number of ports>*<samples per day>*<number of days>*60

ストレージ = (<uncompressed data>*0.1)+<daily backup size>*<number of days>*<number of months>

次の想定を考慮に入れます。

●        サンプル：1 日あたりのサンプル

●        ポートあたりのサンプルサイズ：60 バイト

●        日数：PM データが保存される日数

●        圧縮率：データは DB で最大 10% の比率で圧縮

●        日次バックアップ：1 日あたり最大 60 MB

●        バックアップの日数：デフォルトは過去 7 日間

●        バックアップの月数：デフォルトは 3 か月

インストールに関する推奨事項

●        NTP を使用して、ネットワーク要素間ですべてのクロックを同期します。

●        必要なポートが使用可能であり、関連するポートがネットワーク、マネージャ、およびコントローラ（SNMP、CLI SSH、NETCONF など）と通信するために開いていることを確認します。「ポート」セクションを参照してください。

●        インストールファイル（プラットフォーム用のイメージ 1 つとアプリケーション用のイメージ 1 つ）を選択したディレクトリにダウンロードします。

●        Crosswork Hierarchical Controller プラットフォームとリモートホスト間のアクセスがファイアウォールによって妨げられないことを確認します。

●        ‘yum’ update を実行して、最新の OS パッチがインストールされていることを確認します（インターネットにアクセスできない場合は、https://access.redhat.com/solutions/29269 で推奨事項を参照）。

通信マトリックス

以下は、「説明」列に一覧表示されているアイテムが使用されている場合のデフォルトのポート要件です。これらのポートにはそれぞれ異なる設定が可能です。

Crosswork Hierarchical Controller のインストール

Crosswork Hierarchical Controller プラットフォームのインストール

このプラットフォーム インストールにより、Crosswork Hierarchical Controller プラットフォームと 3D Explorer アプリケーションがインストールされます。

Crosswork Hierarchical Controller をインストールするには、次の手順を実行します。

1.     .sh インストールファイルがダウンロードされたディレクトリに移動します。

2.     root としてインストールコマンドを実行します。

sudo su -

bash ./<file name>.sh

このインストール手順では、インストール中にユーザーが入力する必要はありません。インストール手順では HW リソースがチェックされ、リソースが不足しているときにはエラーが発生します。その場合、インストールを中止または再開できます。その他の障害が発生した場合は、最寄りの Sedona サポートチームにお問い合わせください。

インストールが完了したら、「sedo -h」と入力して、Crosswork Hierarchical Controller コマンドラインツールを開始します。コマンドバージョンを入力して、該当するバージョンが正しくインストールされていることを確認します。

3.     Crosswork Hierarchical Controller ユーザーインターフェイス（https://server-name) または IP）に、ユーザー「admin」およびパスワード「admin」でログインします。

4.     Crosswork Hierarchical Controller のアプリケーションバーで、[ユーザープロファイル（User Profile）] > [パスワードの変更（Change Password）] を選択します。デフォルトのパスワード「admin」を変更する必要があります。

Crosswork Hierarchical Controller アプリケーションのインストール

アプリケーションをインストールするには、次の手順を実行します。

1.     インストールまたはアップグレードが必要なアプリケーションを含む netfusion-apps.tar.gz ファイルを取得し、Crosswork Hierarchical Controller サーバーにコピーします。

2.     コマンドを実行します。

sedo import apps [netfusion-apps.tar.gz file]

インストールされている Crosswork Hierarchical Controller アプリケーションの表示

インストールされている Crosswork Hierarchical Controller アプリケーションを表示するには、次の手順を実行します。

1.     インストールが完了したら、Crosswork Hierarchical Controller がインストールされている OS に root アクセスできることを確認し、「sedo -h」と入力して Sedona の sedo ユーティリティを開きます。

2.     次のコマンドを実行して、インストールされているアプリケーションを確認します。

sedo apps list

出力には、インストールされているアプリケーションとその ID、名前、およびそれらが有効かどうかが表示されます。システムアプリケーション（デバイスマネージャなど）を除くすべてのアプリケーションは、デフォルトで無効になっています。

アプリケーションの有効化または無効化

インストールされているアプリケーションは、sedo コマンドを使用して有効または無効にすることができます。

アプリケーションを有効または無効にするには、次の手順を実行します。

1.     アプリケーションを有効にするには、次のコマンドを実行します。

sedo apps enable [application ID]

アプリケーションは、アプリケーションが有効になった後に Crosswork Hierarchical Controller Explorer のみに表示されます。Crosswork Hierarchical Controller Explorer がすでに開いている場合は、ページを更新します。左側のアプリケーションバーにアプリケーションアイコンが表示されます。

2.     アクティブなアプリケーションを無効にするには、次のコマンドを実行します。

sedo apps disable [application ID]

アプリケーションを無効にすると、アプリケーションバーにアイコンが表示されなくなります。

Crosswork Hierarchical Controller アプリケーションのアップグレード

Crosswork Hierarchical Controller プラットフォームを再インストールせずにアプリケーションをアップグレードすることができます。

アプリケーションをアップグレードするには、次の手順を実行します。

1.     インストールまたはアップグレードが必要なアプリケーションを含む netfusion-apps.tar.gz ファイルを取得し、NetFusion サーバーにコピーします。

2.     コマンドを実行します。

sedo import apps [netfusion-apps.tar.gz file]

（注）   Crosswork Hierarchical Controller プラットフォームをアップグレードする前に、アップグレード対象のアプリケーションが有効になっていた場合、既存のインスタンスは自動的にシャットダウンされ、新しいアップグレードされたインスタンスが開始されます。

ネットワークアダプタの追加とネットワークデバイスの検出

ネットワークアダプタを追加し、ネットワークデバイスを検出する方法については、『Cisco Crosswork Hierarchical Controller Administration Guide』を参照してください。

Cisco Crosswork Hierarchical Controller の 3 ノードクラスタ

Cisco Crosswork Hierarchical Controller では、3 ノードを使用したアクティブ/スタンバイ ウィットネス クラスタを使用して高可用性アーキテクチャを導入します。

3 ノードクラスタは、少なくとも 2 ノードのクォーラムによる継続的な運用を保証します。障害が発生した場合、制御権の取得についての決定は、クォーラムによって自動的に行われます。

クォーラムの利点は、2 つのアクティブノードが互いを認識しないというリスクを回避できることです。ネットワークに変更を加えるシステムの場合、前述のリスクは高くなります。

このアーキテクチャでは、2 つのノードがアクティブシステムとスタンバイシステムとして機能し、3 番目のノードがウィットネスとして機能し、他のいずれかのノードと共にクォーラムを形成します。

すべてのノードは IPsec トンネルのフルメッシュを介して接続されており、それらのノードには etcd ツールを使用した永続クラスタ構成用の分散データストアがあります。

ユーザー（および REST API）は、個別の仮想 IP（VIP）を使用してフロントエンドにアクセスします。IPsec トンネルは、HA レプリケーションに使用されます。

ソフトウェアのコンポーネント

このアーキテクチャでは、PostgresSQL の機能と、分散データストアおよび DB クラスタ用の 2 つのコンポーネントを利用します。

クラスタのノード数は 3 つである必要があります。

PostgresSQL

PostgresSQL は、Cisco Crosswork Hierarchical Controller DB です。ネットワークモデル、運用および構成テーブルがこれに保存されます。

2 インスタンスの DB がインストールされている場合、それらをプライマリおよびスタンバイとして設定し、DB の同期を維持するためのレプリケーションを行うことができます。

etcd

etcd は、分散システムまたはマシンのクラスタがアクセスする必要があるデータを保存するための確実な方法を提供する、強力な一貫性のある分散キー値ストアです。etcd はネットワークパーティション中にリーダーの選出を適切に処理し、リーダーノードにおいてもマシンの障害に耐えることができます。

Cisco Crosswork Hierarchical Controller は、etcd を使用してクォーラムとクラスタ構成を維持します。etcd はクラスタ内の各ノードにインストールされており、Patroni は etcd を使用してクォーラムへのアクセシビリティを把握します。

Patroni

Patroni は、クラウドネイティブの機能とフェイルオーバーおよびフェイルバックの詳細オプションを備えた PostgreSQL の HA ソリューションです。

PostgreSQL はそれ自体のプロセスを処理し、Patroni は PostgreSQL サービスとそのレプリケーションステータスを etcd、zookeeper、Consul などの分散システムでモニターします。PostgreSQL がダウンすると、ボットとして機能する Patroni が新しいマスターの選択を開始します。以前のマスターが回復すると、Patroni はそれをクラスタに再度追加します。

Patroni は、PostgreSQL と同じコンテナで実行されます。

ボットとして行動する Patroni

ノードの設定

3 つのノードすべてに Cisco Crosswork Hierarchical Controller がインストールされています。3 番目のノードであるウィットネスでは、アダプタとアプリケーションが実行されません。

ノードは、IKEv2 および IP50 ESP との IPsec トンネル経由で通信します。

すべてのノードは、IP 到達可能な同じネットワーク内にある必要があります。ノードは、同じデータセンターに展開できます。あるいは、リモートデータセンター間の通信が高品質の帯域幅（少なくとも 1 Gbps）かつ低遅延（100 ミリ秒以下）である場合にはリモートデータセンターに展開できます。

Cisco Crosswork Hierarchical Controller にはロードバランサが付属していません。統合システム（Cisco Crosswork Hierarchical Controller、コントローラ、ネットワーク、オーケストレータ）をロードバランサに接続して、障害が発生した場合にも継続的なサービスが確保されるようにすることをお勧めします。

同期

2 つのインスタンスは、PostgreSQL を使用してネットワークモデル、構成、およびネットワーク統計データに関して同期されます。新しいアプリケーションとアダプタ、および 3D マップと証明書は、Rsync ツールと同期されます。

Cisco Crosswork Hierarchical Controller の運用

正常状態

通常の状態では、すべてのノードが接続されており、ステータスをクラスタ構成データストア（etcd）に書き込むことに成功した最初のノードが制御権を取得し、アクティブノードになります。これは PostgreSQL の Patroni によって行われます。

検出（アダプタ）とアプリケーションは、アクティブノードのみで実行されます。

スタンバイシステムのアダプタとアプリケーションはモニタリングモードで実行され、コントローラへの接続をテストしたり、NBI をエクスポートするアプリケーションへの接続を OSS からテストしたりします。

この通常の状態では、すべてのノードがクォーラムにあり、両方のノードの Patroni がクラスタ構成を継続的に読み取ります。

2 番目のノードがスタンバイになり、3 番目のノードであるウィットネスが構成のモニタリングを継続します。

通常の動作

アクティブノード接続の失敗

アクティブノードが他のノードへの接続を失った場合、その etcd は、少数派になったことを識別すると、自身を読み取りにロックします。Patroni は、etcd のデータストアの読み取りに失敗すると、自動的に自身を降格します。Brain は、アクティブノードの接続が失敗したことを識別し、自身とすべてのコンテナをスタンバイモードに移行させます。

他の 2 つのノードがクォーラムに留まることになり、スタンバイノードをアクティブに切り替えることに投票します。

アクティブノードの障害

すべてのノードが接続を失った場合

すべてのノードが相互の接続を失うと、クォーラムがなくなり、アクティブノードとスタンバイノードは自身をロックダウンし、すべてのコンテナを降格します。

ウィットネス ノードが接続を失った場合

ウィットネス ノードが接続を失っても、2 つのノードはまだクォーラムを構成しており、マスターとスレーブに投票できます。他の変更が発生しない場合、アクティブノードはアクティブな状態を保ちます。

復帰

クラスタフェールオーバーは非復帰型であり、アクティブである任意のノードで継続的に動作できます。手動スイッチオーバーがサポートされています。

HA クラスタの設定

HA クラスタを設定するには、仮想 IP（VIP）が必要です。これは、フロントエンドが（リーダーノードまたはスタンバイノード上の）アプリケーションに接続するために使用されます。IT 管理者は、VIP とインターフェイスを決定します。

注記：VIP は通常、フロントエンドコンテナに接続するために使用されますが、VIP インターフェイスは OS レベルで設定され、任意のコンテナに到達するために使用できます。

注記：HA クラスタの管理の詳細については、『Cisco Crosswork Hierarchical Controller Administration Guide』を参照してください。

HA クラスタを設定するには、次の手順を実行します。

1.     アクティブノードで新しいクラスタを作成するには、次のコマンドを実行します。

sedo ha new-cluster – ipsec-address HOST [--subnet SUBNET] [--dns-server HOST] - vip-address VIP --vip-intf INTF

where

--ipsec-address は、このホストのパブリック名です（DNS ラベルまたは IPv4）。

--subnet は、内部 IPsec トンネルサブネットです（デフォルト：172.16.237.0/24）。

--dns-server は、ホスト名を解決する DNS サーバーです（オプション）。

- vip-address は、CIDR 形式のネットマスクを含む仮想 IPv4 アドレスです。

--vip-intf は、仮想 IP が追加されるインターフェイスです（例：eth0）。

2.     スタンバイノードをクラスタに追加します。このアクションにより、現在の（スタンバイ）ノードのデータが消去されます。

sedo ha add-cluster --remote-api-address REMOTE --remote-api-username USERNAME --ipsec-address HOST [--no-verify] --vip-intf INTF

where

--remote-api-address は、リモートクラスタのパブリック名です（DNS ラベルまたは IPv4）。

--remote-api-username は、クラスタ管理者のユーザー名です。

--ipsec-address は、このホストのパブリック名です（DNS ラベルまたは IPv4）。

--no-verify は、確認のためのプロンプトを表示しないことを意味します。

--vip-intf は、仮想 IP が追加されるインターフェイスです。

3.     続行を確認するには、次の文字を入力します。

対応

4.     ウィットネス ノードをクラスタに追加するには、次のコマンドを実行します。

sedo ha add-cluster --remote-api-address REMOTE --remote-api-username USERNAME ––ipsec-address HOST [--no-verify]--witness [-f]

where

--remote-api-address は、リモートクラスタのパブリック名です（DNS ラベルまたは IPv4）。

--remote-api-username は、クラスタ管理者のユーザー名です。

--ipsec-address は、このホストのパブリック名です（DNS ラベルまたは IPv4）。

--no-verify は、確認のためのプロンプトを表示しないことを意味します。

--witness は、このノードをウィットネスとして設定します。

-f は、確認のためのプロンプトを表示しないことを意味します。

5.     続行を確認するには、次の文字を入力します。

対応

6.     プロンプトが表示されたら、フロントエンドのログイン情報を入力してください。

データベースが複製されます（複製中にステータスを確認すると、[ロール（Role）] が [レプリカ（Replica）] になっています）。

7.     データベースが複製されると、その [ロール（Role）] は [同期スタンバイ（Sync Standby）] になります。「HA 状態の確認」を参照してください。

8.     状態を確認するには、次のコマンドを実行します。

sedo ha state

IPsec Tunnels

+---+-------------+------------------+------------------+---------------+---------------+

| | State | From | To | From Subnet | To Subnet |

+---+-------------+------------------+------------------+---------------+---------------+

| 1 | ESTABLISHED | YY.YY.118.68 (*) | YY.YY.118.75 | XXX.XX.0.0/24 | XXX.XX.1.0/24 |

| 2 | ESTABLISHED | YY.YY.118.61 | YY.YY.118.75 | XXX.XX.2.0/24 | XXX.XX.1.0/24 |

| 3 | ESTABLISHED | YY.YY.118.61 | YY.YY.118.68 (*) | XXX.XX.2.0/24 | XXX.XX.0.0/24 |

+---+-------------+------------------+------------------+---------------+---------------+

etcd ノード

+---+----------------+---------+--------+

| | Endpoint | Status | Errors |

+---+----------------+---------+--------+

| 1 | XXX.XX.0.1 (*) | started | |

| 2 | XXX.XX.2.1 | started | |

| 3 | XXX.XX.1.1 | started | |

+---+----------------+---------+--------+

データベース ノード

+---+------------+----------------+--------------+---------+----+-----------+

| | Member | Host | Role | State | TL | Lag in MB |

+---+------------+----------------+--------------+---------+----+-----------+

| 1 | XXX.XX.0.1 | XXX.XX.0.1 (*) | leader | running | 17 | |

| 2 | XXX.XX.1.1 | XXX.XX.1.1 | sync_standby | running | 17 | 0 |

+---+------------+----------------+--------------+---------+----+-----------+

NetFusion ノード

+---+------------------+-------------+---------+

| | Public Address | Internal IP | Role |

+---+------------------+-------------+---------+

| 1 | YY.YY.118.75 | XXX.XX.1.1 | Standby |

| 2 | YY.YY.118.61 | XXX.XX.2.1 | Witness |

| 3 | YY.YY.118.68 (*) | XXX.XX.0.1 | Active |

+---+------------------+-------------+---------+

IPsec トンネルが確立され、リーダー（アクティブ）ノードとウィットネス ノードで etcd デーモンが開始され、データベースがリーダーノードで実行されています。