デバイス構成のライフサイクル
Apstraデバイスの設定ライフサイクルを十分に理解することが不可欠です。Apstra環境でデバイスを操作する前に、オンボーディングの瞬間から廃止された瞬間までのデバイスの設定方法を十分に理解することを強くお勧めします。
用語
設定ライフサイクルの段階は次のとおりです。
| 設定段階 | 説明 |
|---|---|
| Pristine Config | デバイスエージェントをインストールすると、デバイス上の既存の設定に設定が追加されます。通常、元の設定はデバイスのライフサイクルを通じて変更されません。 |
| ディスカバリー1の構成 | デバイス を確認する と、ApstraはすべてのインターフェイスでLLDPの有効化などの基本設定を追加します。 |
| Ready Config(以前の Discovery 2 Config) | デバイスを展開せずにブループリントに割り当てると(展開モード:準備完了)、Apstraはデバイスホスト名、インターフェイスの説明、ポート速度/ブレイクアウト設定などの基本設定を追加します。 |
| サービス設定 | デバイスを展開する際(展開モード:展開)、ApstraはApstra環境に必要な設定を追加します。 サービス設定 は、ディスカバリ1のコンフィグ、準備完了(ディスカバリ2)のコンフィグ、およびこの追加コンフィグで構成されています。 |
| レンダリングされた設定 | Apstraリファレンスデザインに従って、デバイス用に完全なApstraレンダリング設定を行う。 |
| インクリメンタル設定 | 行った変更をコミットするときに適用される設定 |
| ゴールデン設定 | 設定変更をコミットすると、Apstraは ゴールデン設定と呼ばれる新しい実行中設定を収集します。ゴールデン設定がインテントとして機能:Apstraは、実行中の設定とゴールデン設定を継続的に比較します。導入に失敗すると、Apstraはゴールデン設定の設定を解除します。 |
構成ステージ:概要
次の表は、さまざまな設定イベントとそれによって生じるデバイス設定、Apstraで管理されるデバイスの状態、およびブループリントの導入モードについて説明します。
| イベント | 結果として得られるデバイス構成 | 結果として得られるApstra管理対象デバイスの状態 | Apstraブループリント導入モード |
|---|---|---|---|
| 新しいデバイス | 工場出荷時のデフォルト設定 | 該当なし | 該当なし |
| デバイスにPre-Apstra [mgmt]設定を追加 | ファクトリー + Pre-Apstra | 該当なし | 該当なし |
| Apstraデバイスシステムエージェントをインストールする | Pristine Config: 工場出荷時 + Pre-Apstra + エージェントインストール設定 | OOS-隔離済み | 割り当てられていません |
| 確認デバイス | 発見1: 手付かずのインターフェイスと有効なインターフェイス | OOS 対応 | 割り当てられていません |
| ブループリントへのデバイスの割り当て(展開なし) | 準備完了(ディスカバリー2): ディスカバリー1、およびさまざまな基本設定 | IS対応 | 準備完了 |
| デバイスの展開 | サービス設定: 準備完了(Discovery 2)設定と完全なApstraレンダリング設定 | IS-アクティブ | 展開 |
| 増分設定の追加/コミット | ブループリントの変更による設定変更の差分 | IS-アクティブ | 展開 |
| ドレン装置 | 「ドレイン」設定が追加されました | IS対応 | ドレイン |
| デバイスのアンデプロイ | Apstraレンダリングされた設定を削除 | IS対応 | アンデプロイ |
| デバイスの割り当てを解除 | ディスカバリー1の設定が再適用されます | OOS 対応 | 割り当てられていません |
デバイスにエージェントをインストールすると、すでに存在していた設定はすべて Pristine Config の一部となり、デバイスの設定ライフサイクル全体に含まれます。修正を加えると、サービスに影響します。
構成ステージ:詳細
- 新しいデバイス(工場出荷時のデフォルト)
- Pre-Apstra設定を追加(ユーザー必須)
- エージェントのインストール(Pristine)
- デバイスの確認(Discovery 1 / 準備完了)
- デバイスの割り当て(準備完了/準備完了)
- デバイスの展開(レンダリング/アクティブ)
- デバイス更新のステージング(インクリメンタル/アクティブ)
- デバイスの再コミット(レンダリング更新/アクティブ)
新しいデバイス(工場出荷時のデフォルト)
デバイスのライフサイクルは、 工場出荷時のデフォルト 設定段階から始まります。
Pre-Apstra設定を追加(ユーザー必須)
設定ライフサイクル全体にわたって、特定の最小ベース設定が必要です。これには、エージェントのインストールとデバイス接続の構成が含まれます。デバイスとApstraサーバーのOOB(アウトオブバンド)間の管理IP接続を設定する必要があります。インバンド設定はサポートされていないため、設計図に変更を加えると接続の問題が発生する可能性があります。
この ユーザーに必要な 設定を Apstra ZTPPでブートストラップするか、スクリプト(または他の方法)で追加できます。
接続やデバイスエージェントのインストールに必要な設定、 またはデバイスのライフサイクル全体を通じて 必要であることがわかっている設定(バナーやNTP/SNMP/syslogサーバーのIPアドレスなど)のみを追加します。Apstraでレンダリングされない必須の設定を コンフィグレットで追加できます。
エージェントのインストール(Pristine)
デバイスにオンボックスエージェント(またはサーバー上のオフボックスエージェント)をインストールすると、デバイスは 隔離された 状態でApstraに接続して登録されます。Apstraは、部分的な設定をApstra以前の設定に適用します。この設定は 、プリスティン設定と呼ばれます。手付かずの設定は、後続のすべてのデバイス設定の基礎となります。
デバイスの確認(Discovery 1 / 準備完了)
デバイスを確認すると、そのデバイスは 準備完了 状態になります。この確認は、Apstraにデバイスを管理させる意思を示しています。Apstraは、元の設定に加えて、Apstraエージェントの運用に不可欠な最小限の基本設定を追加します。この設定は ディスカバリ 1 コンフィグと呼ばれます。ディスカバリ1では、 完全な 設定(フル設定プッシュ)を適用し、既存の設定をすべて上書きして設定の整合性を確保します。
- すべてのインターフェイスが、割り当てられたデバイスプロファイルのインターフェイス速度でレンダリングされます。
- すべてのインターフェイスが
no shutdownされており、LLDPネイバー情報を表示できます。 - デバイスがファブリックに参加できなくなるため、すべてのインターフェイスがL3モード(デフォルト)に移行します。
確認済みのデバイスは、単純に削除することはできません。デバイスにはアクティブなエージェントがインストールされたままなので、デバイスは数秒以内に再び表示されます。Apstra管理からデバイスを削除するには、完全なワークフローについては、 管理対象デバイスからデバイスを削除(廃止)するを参照してください 。
デバイスの割り当て(準備完了/準備完了)
デバイスをブループリントに割り当て、その展開モードを 準備完了に設定すると、そのデバイスは 準備完了(ディスカバリ2) 状態になります。デバイスはステージングされていますが、アクティブなブループリントにまだコミット(導入)されていません。Ready configは、 完全な 設定(Full config push)を適用して、設定の整合性を確保します。準備完了設定は、ネットワークインターフェイスを表示し、インターフェイスの説明を設定し、LLDPなどのテレメトリを検証して、正しく配線され、構成されていることを確認します。この設定は、ファブリック内の他のサービスに支障をきたすことはありません。リンクはアップしていますが、STP/L2操作を防ぐためL3モードで設定されています。
- ホスト名は、ブループリントインテントごとに設定されます。
- すべてのインターフェイスの説明は、ブループリントインテントごとに変更されます。
- インターフェイスは、ブループリントのインターフェイス速度でレンダリングされます。
- ルーティングまたは BGP は設定されていません。
- インターフェイスにL3情報は設定されていません。
- ファブリック MTU は、スパイン デバイス用に変更され、9050 バイトに変更されます。
デバイスの展開(レンダリング/アクティブ)
初めてデバイスを割り当てて展開するとき(展開モードを「展開してブループリントをコミットする」に設定)、デバイス上でフル設定のプッシュがトリガーされます。このアクションにより、実行中の完全な設定が元の設定で上書きされ、完全にレンダリングされたApstra設定が追加されます。Apstraは、Apstraでレンダリングされた設定に含まれない設定をすべて破棄します。
デバイスをコミットすると、デバイスは アクティブになり、Apstraによってサービス設定が展開され、デバイスは レンダリングされた 設定段階に移動します。レンダリングされた設定コンテンツは、元の設定、選択したリファレンスデザイン/トポロジー、NOS、デバイスモデルから取得されます。最初にレンダリングされた設定では、 完全な 設定を適用し(JinjaごとにApstraサーバーから既存の設定をすべて削除)、設定の整合性を確保します。これがApstraの完全な最終状態です。完全な設定がプッシュされ、すべてのインターフェイスが実行され、IPファブリック内のルーティングが設定されています。ここでは、完全な構成レンダリング、インテントベースのテレメトリ、標準的なサービス運用を行います。
- ホスト名は、ブループリントインテントごとに設定されます。
- すべてのインターフェイスの説明は、ブループリントインテントごとに変更されます。
- インターフェイスは、ブループリントのインターフェイス速度でレンダリングされます。
- インターフェイスVLAN、LAGS、MLAG、VXLANなどが管理対象です。
- すべてのL3情報がレンダリングされます。
- すべてのBGPピアリング情報に対してBGP設定が完全にレンダリングされます。
- DHCP設定は、必要なDHCPリレーエージェントに対して設定されます。
- デバイスがグラフデータベースに追加されます。
完全な設定がデバイスに正常に展開されると、Apstraはデバイス設定のスナップショットを取得し(例:show running-confg)、 ゴールデン設定として保存します。
この時点で設定を追加すると、設定の逸脱異常が発生します。偏差は、現在の設定と保存されているゴールデン設定との差です。導入タスクを続行する前に、異常を修正する必要があります。
ブループリントをコミットした後にレンダリングされたコンフィグファイルを表示するには、 アクティブ ブループリントでデバイスを選択し、 コンフィグ( 右側)をクリックします。
実行中の構成は、複数の方法で変更できます。リファレンスデザインに含まれていない設定を変更するには、 コンフィグレットを使用します。
デバイス更新のステージング(インクリメンタル/アクティブ)
実行中のブループリントに変更をステージングする場合、 増分 設定を作成します。
デバイスの再コミット(レンダリング更新/アクティブ)
デバイスの設定に影響するブループリントへの変更をコミットすると、部分的な設定によってレンダリングされた設定が更新されます。
ブループリントからデバイス構成を表示
ブループリントから、[ Staged > Physical ]に移動し、物理ブループリントの [Topology ]ビューに移動します。
トポロジー内のノードをクリックし、右側のパネルの デバイス タブから、 構成 セクションのレンダリング、インクリメンタル、プリスティン、またはデバイスコンテキストのリンクをクリックします。 
デバイスモデルは、データセンターのブループリントにコンフィグレットを作成するときや、フリーフォームブループリントにコンフィグテンプレートを作成するときに活用できる変数のネストされたディクショナリです。デバイスコンテキストには、データセンターの設計図でコンフィグレットを作成する際に役立つ情報が含まれています。インターフェイスセクションには、インターフェイスタグの tags とリンクタグの intf_tags があります。メインセクションには system_tagsがあります。

クエリタブには、キーまたは値をすばやく検索し、関心のある変数を特定するための動的検索機能が用意されています。構文は大文字と小文字を区別します。例えば、キーワード bgp を検索すると、スイッチのBGP設定とBGPセッション(プロトコルセッション)に関する情報が得られ、キーワード BGP で検索すると、「BGP-AOS-Policy」などのBGPルートマップのリストが表示されます。コンフィグレット内でこれらの変数を組み込みのプロパティセットとして使用する場合、デバイスモデルの大文字と小文字を区別する属性も尊重する必要があります。
デバイスモデルは、Apstra環境で使用される内部データモデルです。スキーマ変更の通知や文書化なしに変更される場合があります。
構成の逸脱
設定の展開が 成功する たびに、実行中の設定が収集され、 ゴールデン 設定として内部に保存されます。インテントはApstra製品の基盤です。実際に実行中の構成とこのゴールデン構成との間に違いがあると、ブループリントのダッシュボードに構成の逸脱異常が発生します。ゴールデン設定は、設定がデバイスに正常に適用されるたびに更新されます。
知っておくべき重要な点は次のとおりです。
- 設定の導入 が成功する たびに、ゴールデン設定が更新されます。
- 構成の導入に失敗した場合、ゴールデン構成は設定されません。これは、構成の逸脱と導入失敗の異常の両方が発生することを意味します。
- 実行中の設定テレメトリは継続的に収集され、ゴールデン設定と照合されます。違いがあれば、偏差異常が生じます。
- 構成の異常は、「変更を承認する機能」を使用して「抑制」できます。これは、変更がゴールデン設定またはインテントに追加されることを意味する ものではありません 。
詳細については、 異常(サービス) を参照してください。
フル構成を手動で適用
検出1およびデバイスの展開設定段階で、完全な設定プッシュを開始します。まれに、完全な設定プッシュを手動で適用する必要がある場合があります。例えば、TCAMカービングを必要とするNX-OSデバイスを含む設計図に必要な設定が設定されていない場合、デバイス設定は失敗します。TCAM設定エラーを修正してから、完全な設定を手動でプッシュする必要があります。
フルコンフィギュレーションのプッシュは、ボックス上で実行されているすべてのサービスに影響を与える可能性が非常に高いため、細心の注意を払って実行してください。正確な影響は、プッシュされる変更によって異なります。また、「帯域外」の変更 はすべて フルプッシュ時に上書きされることに注意してください。
展開モード
ブループリント内の管理対象デバイスは、以下のいずれかの モードにすることができます。
未設定
デバイスの初期状態デバイスがファブリックでアクティブではありません。ブループリント内のデバイスからシステムIDの割り当てを解除すると、展開モードは自動的に[未設定]に変わります(Apstraバージョン5.0.0以降)。
展開
デバイスはファブリックでアクティブです。
準備完了
デバイスをブループリントに割り当てると、展開モードが 準備完了に変更されます。Apstraは、準備完了(Discovery 2)設定(ホスト名、インターフェイスの説明、ポート速度/ブレイクアウト設定)をレンダリングします。デバイスがファブリックでアクティブではありません。 展開 から 準備完了 に変更すると、Apstraレンダリング設定が削除されます。
ドレイン
物理的なメンテナンスのためにデバイスをドレインすることで、既存のTCPフローに影響を与えることなく、サービスを停止することができます。ドレインするデバイスに応じて、Apstraは次の2つの方法のいずれかを使用します。
L2サーバーの場合
- どのNOSのMLAGピアリンク、ポートチャネル、およびボンディングインターフェイスも変更されていません。
- Arista EOSとCisco NX-OS、Apstra 4.2.1以降のJunos OSでは、設計図内のL2サーバーへのすべてのインターフェイスが
shutdownされます。
ネットワークL3スイッチの場合
デバイスは、インバウンド/アウトバウンドルートマップの「deny」ステートメントを使用して、0.0.0.0/0 le 32へのアドバタイズメントをブロックします。これにより、既存のL3 TCPフローを中断することなく継続できます。1、2秒後、src/dstデバイスによってTCPセッションが再確立されるか、新しいTCPポートをネゴシエートする必要があります。新しいTCPポートは、使用可能なリンクのリストから新しいECMPパスにデバイスを強制的にハッシュします。ルートマップが存在する場合、宛先へのECMPルートは利用できないため、 トラフィックはドレイン モードのデバイスを通過しません。デバイスからトラフィックが効果的に排出され、ファブリックから取り外すことができます(展開モードをアン デプロイに変更することで)。
TCPセッションがドレインする間(特にEVPNブループリントでは時間がかかる可能性があります)、BGPの異常は予想されます。設定の導入が完了すると、一時的な異常は解消されます。
デバイスの展開モードを [ドレイン ] に変更すると、ドレインするデバイスだけでなく、隣接するデバイスの設定も影響を受ける可能性があります。たとえば、スパインデバイスをドレインすると、接続されているすべてのリーフデバイスの設定が変更されます。隣接するリーフデバイスは、インバウンド/アウトバウンドルートフィルター(ルートマップ)の「reject(deny)」ステートメントを使用して、EVPN(オーバーレイ)とFABRIC(アンダーレイ)の両方について、0.0.0.0/0 le 32へのアドバタイズメントをブロックします。

同様に、リーフデバイスをドレインすると、接続されたスパインデバイスの設定が変化します。隣接するスパインデバイスは、インバウンド/アウトバウンドルートフィルター(ルートマップ)の「reject(deny)」ステートメントを使用して、EVPN(オーバーレイ)とFABRIC(アンダーレイ)の両方について、0.0.0.0/0 le 32へのアドバタイズをブロックします。

MLAGベースのトポロジーの場合、接続されたスパインデバイスの設定が変更されるだけでなく、ペアリングされたリーフデバイスの設定も変更されます。

アンデプロイ
デバイスをアンデプロイすると、完全なサービス設定が削除されます。デバイスがトラフィックを伝送している場合は、デバイスをアンデプロイする前に、まずそのデバイスを ドレイン モードにして(そして変更をコミットする)のが最善です。