この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
サードパーティのアプリケーションは、Bash シェルで dnf コマンドを使用するか、NX-OS CLI を介してネイティブ ホストにインストールされます。
dnf install rpm コマンドを入力すると、Cisco DNF プラグインが実行されます。このプラグインは、RPM を表示されない場所にコピーします。スイッチのリロード時に、システムは RPM を再インストールします。
構成が /etc に置かれている場合、Linux プロセス、incrond は、ディレクトリで作成されたアーティファクトをモニターし、それらを表示されない場所にコピーし、この場所から /etc にコピーし直します。
サードパーティ製アプリケーションの RPM には、次の注意事項と制約事項があります。
NX-OS 10.1(1) リリースには、NX-Linux（シスコ独自の Linux ディストリビューション）に基づく新しいオペレーティング システムと rootfs があるため、WRL5/WRL8 を使用して構築されたサードパーティ製 RPM は NX-Linux と互換性がない場合がありますそのため、サードパーティ製ソフトウェアが機能しない可能性があります。この場合、以前のリリースで使用されていたアプリケーションの古いバージョンを削除し、NX-Linux と互換性のある新しいソフトウェアに置き換えます。 にあります。
署名付き RPM のインストールに関するガイドラインと手順については、『Cisco Nexus 9000 Series NX-OS Software Upgrade and Downgrade Guide, Release 9.2(x)』を参照してください。リポジトリの数などです。
サードパーティ製アプリケーションは、スイッチの起動時に開始されます。サードパーティ製アプリケーションは、その通信インターフェイスが起動する前、またはスイッチと通信ピアまたはサーバー間のルーティングが確立される前に起動される可能性があります。したがって、すべてのサードパーティ製アプリケーションは、通信障害が発生した場合に堅牢になるように作成し、アプリケーションは接続の確立を再試行する必要があります。通信障害が発生してもアプリケーションに復元力がない場合は、「ラッパー」アプリケーションを使用して、目的のアプリケーションを起動する前に通信ピアが到達可能であることを確認するか、必要に応じて目的のアプリケーションを再起動する必要があります。
Cisco NX-OS リリース 10.2(3)F 以降、Python2 および依存 RPM は NX-OS から削除されます。ただし、Python2 および依存する RPM は、devhub サイトからパッケージグループ packagegroup-nxos-64-python-2-deprecated-rpms としてインストールできます。
次に、パッケージのインストールの完全なワークフローを示します。
switch# cat /etc/dnf/repos.d/open-nxos.repo
[open-nxos]
name=open-nxos
baseurl=https://devhub.cisco.com/artifactory/open-nxos/10.2.3/
enabled=1
gpgcheck=0
sslverify=0
dnf info packagegroup-nxos-64-python-2-deprecated-rpms
dnf install packagegroup-nxos-64-python-2-deprecated-rpms
The output of these cmds will be available post KR3F CCO.パッケージのインストールの完全なワークフローは次のとおりです。
|
エージェントが保存されているシスコのリポジトリを指すように、スイッチのリポジトリを設定します。 CLI を使用してデジタル署名をインポートする手順については、『Cisco Nexus 9000 Series NX-OS Software Upgrade and Downgrade Guide, Release 9.2(x)』の「Using Install CLIs for Digital Signature Support」を参照してください。 フルインストールログを使用した yum dnf を使用した RPM のインストールの例。 例:パッケージが正常にインストールされたかどうかをスイッチに照会し、そのプロセスまたはサービスが稼働していることを確認する例。 例: |
次に、永続的なサードパーティ RPM の背後にあるロジックを示します。
ローカルリポジトリは、永続的なサードパーティ RPM 専用です。dnf /etc/yum/repos.d/ thirdparty.repo は /bootflash/.rpmstore/ thirdparty を指します。
コマンドを入力するたびに、RPM のコピーが //bootflash/.rpmstore/ thirdparty に保存されます。dnf install third-party.rpm
リブート中に、サードパーティ製リポジトリ内のすべての RPM がスイッチに再インストールされます。
/etc 構成ファイルの変更は、/bootflash/.rpmstore/config/etc の下に保持され、/etc での起動時に再生されます。
/etc ディレクトリに作成されたスクリプトは、リロード後も保持されます。たとえば、/etc/init.d/ の下に作成されたサードパーティのサービススクリプトは、リロード中にアプリケーションを起動します。
 （注） |
iptables のルールは、bash シェルで変更された場合、再起動後は保持されません。 変更した iptables を永続化するには、「」を参照してください。リロード間で Iptable を永続化する |
NX-OS 機能 RPM は、VSH CLI を使用してインストールすることもできます。
| コマンドまたはアクション | 目的 | |
|---|---|---|
|
ステップ 1 |
show install package |
すでに存在するパッケージとバージョンを表示します。 |
|
ステップ 2 |
install add ? |
サポートされている URI を決定します。 |
|
ステップ 3 |
install add rpm-packagename |
The install add コマンドは、ローカル ストレージ デバイスまたは、ネットワーク サーバーへパッケージ ファイルをコピーします。 |
次に、Chef RPM をアクティブにする例を示します：
switch# show install package
switch# install add ?
WORD Package name
bootflash: Enter package uri
ftp: Enter package uri
http: Enter package uri
modflash: Enter package uri
scp: Enter package uri
sftp: Enter package uri
tftp: Enter package uri
usb1: Enter package uri
usb2: Enter package uri
volatile: Enter package uri
switch# install add bootflash:chef-12.0.0alpha.2+20150319234423.git.1608.b6eb10f-1.el5.x86_64.rpm
[####################] 100%
Install operation 314 completed successfully at Thu Aug 6 12:58:22 2015
パッケージをアクティブ化する準備ができたら、パッケージのアクティブ化 に移動します。
（注） |
RPM パッケージの追加とアクティブ化は、次の 1 つのコマンドで実行できます。 |
RPM は事前に追加しておく必要があります。
| コマンドまたはアクション | 目的 | |
|---|---|---|
|
ステップ 1 |
show install inactive |
追加されていても、アクティブ化されていないパッケージのリストを表示します。 |
|
ステップ 2 |
install activate rpm-packagename |
パッケージをアクティブ化します。 |
次に、パッケージをアクティブ化する例を示します：
switch# show install inactive
Boot image:
NXOS Image: bootflash:///yumcli6.bin
Inactive Packages:
sysinfo-1.0.0-7.0.3.x86_64
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
: protect-packages
Available Packages
chef.x86_64 12.0.0alpha.2+20150319234423.git.1608.b6eb10f-1.el5 thirdparty
eigrp.lib32_n9000 1.0.0-r0 groups-rep
o
sysinfo.x86_64 1.0.0-7.0.3 patching
switch# install activate chef-12.0-1.el5.x86_64.rpm
[####################] 100%
Install operation completed successfully at Thu Aug 6 12:46:53 2015
| コマンドまたはアクション | 目的 |
|---|---|
|
install deactivate package-name |
RPM パッケージを非アクティブ化します。 |
次に、Chef RPM パッケージを非アクティブ化する例を示します。
switch# install deactivate chefパッケージを削除する前に非アクティブ化します。非アクティブ化された RPM パッケージのみ削除できます。
| コマンドまたはアクション | 目的 |
|---|---|
|
install remove package-name |
RPM パッケージを削除します。 |
次に、Chef RPM パッケージを削除する例を示します。
switch# install remove chef-12.0-1.el5.x86_64.rpm| コマンドまたはアクション | 目的 |
|---|---|
|
show install packages |
インストールされているパッケージのリストを表示します。 |
次に、インストールされているパッケージのリストを表示する例を示します。
switch# show install packages| コマンドまたはアクション | 目的 |
|---|---|
|
show tech-support install |
詳細ログを表示します。 |
次の例は、詳細ログを表示する方法を示しています。
switch# show tech-support install| コマンドまたはアクション | 目的 |
|---|---|
|
インストール 追加 package-name アクティベート アップグレード |
パッケージをアップグレードします。 |
次に、パッケージをアップグレードする例を示します：
switch# install add bootflash:bgp-1.0.1-r0.lib32_n9000.rpm activate ?
downgrade Downgrade package
forced Non-interactive
upgrade Upgrade package
switch# install add bootflash:bgp-1.0.1-r0.lib32_n9000.rpm activate upgrade
[####################] 100%
Install operation completed successfully at Thu Aug 6 12:46:53 2015
| コマンドまたはアクション | 目的 |
|---|---|
|
インストール 追加 package-name アクティベート ダウングレード |
パッケージをダウングレードします。 |
次の例は、パッケージをダウングレードする方法を示しています。
switch# install add bootflash:bgp-1.0.1-r0.lib32_n9000.rpm activate ?
downgrade Downgrade package
forced Non-interactive
upgrade Upgrade package
switch# install add bootflash:bgp-1.0.1-r0.lib32_n9000.rpm activate downgrade
[####################] 100%
Install operation completed successfully at Thu Aug 6 12:46:53 2015
NX-API REST API オブジェクト モデルの仕様の詳細については、https://developer.cisco.com/docs/nx-api-dme-model-9-3-1-reference/ を参照してください。
DevOps 構成管理ツールについては、次のリンクを参照してください。
Ansible 2.0 リリース（Nexus サポート）、Ansible リリース インデックス
Ansible NX-OS サンプル モジュール、Ansible NX-OS サンプル モジュール
Puppet、Puppet Forge Cisco Puppet
Cisco Puppet モジュール（Git）Cisco Network Puppet モジュール
Cisco Chef クックブック（Git）Cisco Network Chef クックブック
ESX5.1/5.5、VirtualBox、Fusion、および KVM の場合、仮想 Nexus 9000 スイッチをダウンロードするには、https://software.cisco.com/portal/pub/download/portal/select.html?&mdfid=286312239&flowid=81422&softwareid=282088129に移動します。
Open NX-OS アーキテクチャと自動化に関する無料の書籍については、次を参照してください。 http://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/nexus9000/sw/open_nxos/programmability/guide/Programmability_Open_NX-OS.pdf
collectd は、システム パフォーマンスの統計情報を定期的に収集し、RRD ファイルなどの値を保存する複数の手段を提供するデーモンです。これらの統計情報を使用して、現在のパフォーマンスのボトルネック（パフォーマンス分析など）を見つけたり、将来のシステム負荷を予測したりできます（つまり、キャパシティ プランニング）。
詳細については、https://collectd.org を参照してください。
Ganglia は、クラスタやグリッドなどのハイパフォーマンス コンピューティング システム向けのスケーラブルな分散モニタリング システムです。これは、クラスタのフェデレーションを対象とした階層設計に基づいています。データ表現のための XML、コンパクトでポータブルなデータ転送のための XDR、データストレージと可視化のための RRDtool など、広く使用されているテクノロジーを活用します。設計されたデータ構造とアルゴリズムを使用して、ノードあたりのオーバーヘッドを低く抑え、同時実行性を高めます。この実装は堅牢であり、広範なオペレーティングシステムとプロセッサアーキテクチャに移植されており、現在、世界中の何千ものクラスタで使用されています。世界中の大学キャンパス間でクラスタをリンクするために使用されており、2000 ノードのクラスタを処理するように拡張できます。
詳細については、http://ganglia.info を参照してください。
Iperf は、TCP および UDP の最大帯域幅パフォーマンスを測定するために NLANR/DAST によって開発されました。Iperf を使用すると、さまざまなパラメータと UDP 特性を調整できます。Iperf は、帯域幅、遅延ジッターとデータグラム損失を報告します。
詳細については、http://sourceforge.net/projects/iperf/またはhttp://iperf.sourceforge.netを参照してください。
リンク層検出プロトコル（LLDP）は、EDP や CDP などの独自のリンク層プロトコルに代わるように設計された業界標準プロトコルです。LLDP の目的は、隣接するネットワークデバイスにリンク層通知を配信するための、ベンダー間互換性のあるメカニズムを提供することです。
詳細については、「https://vincentbernat.github.io/lldpd/index.html」を参照してください。
ICMP、SNMP、SSH、FTP、HTTP などによるネットワーク サービス
CPU 負荷、ディスク使用率、システム ログなどのホスト リソース
サーバー、スイッチ、アプリケーションのアラート サービス
[サービス（Services）]
詳細については、「https://www.nagios.org/」を参照してください。
OpenSSH は、盗聴、接続ハイジャック、およびその他の攻撃を排除するために、すべてのトラフィック（パスワードを含む）を暗号化する SSH 接続ツールのオープンソース バージョンです。OpenSSH は、セキュアなトンネリング機能と複数の認証方式を提供し、すべての SSH プロトコル バージョンをサポートします。
詳細については、「http://www.openssh.com」を参照してください。
Quagga は、さまざまなルーティング プロトコルを実装するネットワーク ルーティング ソフトウェア スイートです。Quagga デーモンは、ネットワーク アクセス可能 CLI（「vty」という）を使用して構成できます。
（注） |
Quagga BGP のみが検証されています。 |
詳細については、「http://www.nongnu.org/quagga/」を参照してください。
Splunk は、Web ベースのデータ収集、分析、およびモニタリング ツールであり、ユースケースに合わせて検索、可視化、および事前にパッケージ化されたコンテンツを備えています。raw データは、Splunk Universal Forwarder を使用して Splunk サーバーに送信されます。ユニバーサル フォワーダは、リモートソースからの信頼性の高いセキュアなデータ収集を可能にし、そのデータをインデックス作成と統合のために Splunk Enterprise に転送します。数万のリモート システムに拡張でき、パフォーマンスへの影響を最小限に抑えながらテラバイト単位のデータを収集できます。
詳細については、http://www.splunk.com/en_us/download/universal-forwarder.html を参照してください。
tcollector は、ローカル コレクタからデータを収集し、そのデータをオープン時系列データベース（OpenTSDB）にプッシュするクライアント側プロセスです。
tcollector には次の機能があります。
データ コレクタを実行し、データを照合します。
時系列データベース（TSD）への接続を管理します。
コレクタに TSD コードを埋め込む必要がなくなります。
繰り返される値の重複を排除します。
ワイヤ プロトコル作業を処理します。
詳細については、http://opentsdb.net/docs/build/html/user_guide/utilities/tcollector.html を参照してください。
tcpdump は、ネットワーク インターフェイス上の Boolean 式に一致するパケットの内容に関する説明を出力する CLI アプリケーションです。説明の前にタイムスタンプが表示されます。デフォルトでは、午前 0 時からの時間、分、秒、および小数点以下の秒として出力されます。
-w：後で分析するためにパケット データをファイルに保存します。
-r：ネットワーク インターフェイスからパケットを読み取るのではなく、保存されたパケット ファイルから読み取ります。
-V：保存されたパケット ファイルのリストを読み取ります。
詳細については、「http://www.tcpdump.org/manpages/tcpdump.1.html」を参照してください。
TShark は、CLI のネットワーク プロトコル アナライザです。Tshark を使用すると、ライブネットワークからパケットデータをキャプチャしたり、以前に保存したキャプチャファイルからパケットを読み取ったりできます。これらのパケットのデコードされた形式を標準出力に出力するか、パケットをファイルに書き込むことができます。TShark のネイティブ キャプチャ ファイル フォーマットは、pcap です。このフォーマットは、 tcpdump と他のツールに使用されています。TShark は、cap_net_admin ファイル機能を削除した後、ゲストシェル内で使用できます。
setcap
cap_net_raw=ep /sbin/dumpcap（注） |
このコマンドは、ゲストシェル内で実行する必要があります。 |
詳細については、「https://www.wireshark.org/docs/man-pages/tshark.html」を参照してください。
Cisco NX-OSリリース 10.6(2) 以降、 Cisco Nexus 9000 スイッチは、スイッチ上のLinuxコンテナでのサードパーティ アプリケーション（TPA）の直接的なホストをサポートしています。この機能により、管理者および自動化システムは、外部サーバーを必要とせずに、スイッチ上でコンテナ化されたアプリケーションをネイティブに展開、管理、およびモニタできます。
この機能は、複数の利点を提供します：
カスタムおよびベンダーアプリケーションの柔軟なデプロイメント：Linux ベースのアプリケーション（DHCP/TFTP サーバー、syslog コレクタ、モニタリング ツールなど）をスイッチ上で直接コンテナ内で実行でき、ネットワーク エッジで幅広い使用例をサポートします。
統合管理と自動化：TPA コンテナを構成、監視、管理するための NX- OS CLI コマンドとプログラム可能な API（gNMI や gNOI など）を提供し、自動化されたワークフローやバックエンド システムとの統合を可能にします。
運用の可視性とトラブルシューティング：リアルタイムのステータス、リソース使用率、および実行中のコンテナのログ取得を提供し、トラブルシューティングとパフォーマンス分析を簡素化します。
永続的で信頼性の高いアプリケーション運用：重要なアプリケーションをデバイスのアップグレードやリブート後に自動的に再起動するように設定でき、継続的で自動化されたサービス提供をサポートします。
セキュアでコンプライアンスに準拠した展開のサポート：VRF 対応のデプロイメント、セキュアな通信、設定とログイン情報の永続ストレージなど、シスコのセキュリティと規則遵守のベストプラクティスに準拠しています。
エッジとクラウドの統合向けに設計：オンボックス アプリケーション ホスティングとクラウドネイティブ管理が必要な Google Distributed Cloud Edge（GDCE）展開などのユースケースに対応します。
Cisco NX-OS リリース 10.6(2) 以降、 Cisco Nexus 9000 スイッチは、統合された Docker エンジンを使用して、サードパーティ アプリケーション（TPA）をスイッチ上で Linux コンテナとして直接ホストできます。
この機能は、NX- OS オペレーティング システム、Docker エンジン、および AppManager 間の統合を活用して、TPA ホスティングのスイッチ上でのコンテナ ライフサイクル管理を提供します。
次のコンポーネントは、コンテナベースの TPA ホスティングで重要な役割を果たします。
NX- OS：コンテナ化されたアプリケーションの機能の有効化、構成、および監視を管理します。
Docker エンジン：コンテナ ランタイム環境を提供し、 Linux アプリケーション コンテナのライフサイクルを管理します。
AppManager：コンテナ制御、ライフサイクル アクション、およびステータス レポートのために NX- OSと Docker 間を調整します。
このプロセスにより、Linux コンテナベースのサードパーティ アプリケーションのセキュアで永続的な自動ホスティングがスイッチ上で直接実行できるようになります。
コンテナベースのサードパーティ製アプリケーション（TPA）をホストおよび管理するプロセスには、次の段階が含まれます。
NX- OSと Docker コンテナ間のトランスポート インターフェイスとして使用できるのは、ループバック インターフェイスのみです。このインターフェイスは、TPA 通信用に明示的に設定する必要があります。
最適なパフォーマンスと信頼性を確保するために、アプリケーション コンテナを実行する場合は、少なくとも 6 つの CPU コアと 64 GB のメモリを備えたスイッチ プラットフォームを使用することをお勧めします。
設定ファイル、ログイン情報、および永続的なアプリケーション データを、専用ボリュームまたはホストマウント ディレクトリに保存して、デバイスの再起動やアップグレード後もデータが保持されるようにします。
重要なアプリケーション コンテナは、システムのアップグレードまたはリブート後に自動的に再起動するように構成し、重要なサービスの継続的な運用を確保する必要があります。
コンテナの高度なモニタリングとパフォーマンスの最適化は、現在の実装には含まれていません。ユーザーは、基本的なリソースおよびパフォーマンスの追跡にネイティブの Docker コマンドを使用できます。
サポートされている Docker のバージョンは 20.10.25-ce で、containerd v1.6.19 です。
Cisco Nexus 9000 スイッチでコンテナベースのサードパーティ アプリケーション（TPA）ホスティングを有効にし、設定するには、次の手順に従います。
Docker サービスの通信に使用するループバック インターフェイスを特定します。
|
ステップ 1 |
TPA 機能を有効化します。 例:このコマンドは、スイッチで Docker ベースのサードパーティ アプリケーション ホスティングを有効にします。 |
|
ステップ 2 |
TPA コンフィギュレーション モードに入ります。 例:このコマンドにより、スイッチが TPA（Docker Box）構成モードになります。 |
|
ステップ 3 |
Docker サービス通信のトランスポート インターフェイスを構成します。 例:Docker サービス通信では、ループバック インターフェイスのみがサポートされます。 |
コンテナベースの TPA ホスティングが有効になり、設定されました。スイッチでアプリケーション コンテナを展開および管理できるようになりました。
show dockerbox status および関連するコマンドで、設定を確認します。コマンド例と予想される出力については、検証のセクションを参照してください。
Cisco Nexus 9000 スイッチでのサードパーティ アプリケーション（TPA）コンテナ ホスティングのステータスと動作を確認するには、次の手順に従います。
これらの検証手順により、NX OS CLIコマンドを使用して、TPA ホスティングとそのコンテナの正常性と動作をチェックできます。
TPA ホスティングがスイッチで構成され、有効になっていることを確認します。
|
ステップ 1 |
TPA ホスティングのステータスを表示します。 例:このコマンドは、TPA（Docker）サービスの現在のステータスを表示します。 |
|
ステップ 2 |
内部状態およびデバッグ情報を表示します。 例:このコマンドは、TPA ホスティングの詳細な内部状態情報を提供します。 |
|
ステップ 3 |
イベント履歴を表示します。 例:TPA ホスティングに関連するエラーログ、デバッグメッセージ、またはメッセージ履歴を表示するには、このコマンドを使用します。 |
|
ステップ 4 |
コンテナ情報を表示します。 例:このコマンドは、概要、リソース統計、ログを含む、実行中のコンテナに関する情報を表示します。 |
|
ステップ 5 |
TPA ホスティング ログを表示します。 例:このコマンドは、TPA ホスティングの Docker サービス ログを表示します。 |
フィードバック