Time Voyager 序章

ステージングされたブループリントをコミットする(ネットワークに更新を展開する)場合、結果が期待していたものと異なる場合があります。誤ってブループリントに変更をコミットしてしまった場合、変更を取り消したい場合もあります。あるいは、ネットワークを数回の改訂前の状態に戻すことに決めたかもしれません。複雑さのレベルによっては、手動でステージングを行い、変更をコミットして実行した内容を元に戻すことが困難で、エラーが発生しやすい場合があります。このような場合は、Time Voyagerを使用して、ブループリントの以前のリビジョンをすばやく復元できます。

ブループリントは、保持されている任意のリビジョンにロールバックできます。デフォルトでは、最新の 5 つのブループリント コミットが保持されます。6回目にコミットすると、最初のリビジョンは破棄され、6番目のリビジョンが5番目のリビジョンになり、2番目のリビジョンが最初のリビジョンになり、追加のブループリント変更がコミットされます。自動保存されるリビジョン数は、最大100リビジョンに変更できます。[ コミット] ダイアログで、上限に達して別の変更をコミットした場合、新しいリビジョンが自動保存された最も古いリビジョンに置き換わることを示すメッセージが表示されます。コミットするときに制限に達し、リビジョンを削除したくない場合は、コミットせずにコミットダイアログを閉じてから、Time Voyagerで自動保存されるリビジョンの数を増やすことができます。

特定のリビジョンを 保持 するか、手動で保存することで、無期限に保持することができます。リビジョンを保持する場合、それは循環する5つのリビジョンには含まれません。最大 25 個のリビジョンを保持でき、デフォルトでは 30 個のブループリント リビジョンから選択できます。(自動保存するリビジョン数を最大100に変更すると、最大125個のリビジョンを保存できます。各リビジョンにはストレージ容量が必要であることに注意してください。リビジョンを保持しない場合は、削除するだけです。

ブループリントをコミットする際には、そのリビジョンで行われた変更を識別できるように、リビジョンの説明を追加することをお勧めします。これらの説明は、そのリビジョンが保持されている限り、ブループリントのリビジョン履歴セクションに表示されます。コミット時に説明を追加しない場合は、後でいつでも追加できます(ただし、変更内容を覚えておく必要があります)。リビジョンにジャンプする(ロールバック)場合、この説明は正しいリビジョンを選択するのに役立ちます。リビジョン間の具体的な違いは表示されないため、そのリビジョンで使用可能な変更情報は説明のみです。

リビジョンにジャンプすると、コミットされていない、以前にステージングされた変更はすべて破棄されます。これが問題の場合は、コミットされていない変更に対処するまでロールバックしないでください。

Time Voyagerは単なるUNDO機能ではありません。Time Voyagerを使用する場合は、前のコミットにロールバックします。つまり、最後のコミットで削除されたものはすべて、ロールバック時に再適用されます。リビジョンの間には、追加と削除の両方、多くの変更がある可能性があり、そのすべてがロールバックに含まれます。ロールバックをコミットする前に、保留中の変更を詳細に確認することが重要です。Time Voyagerは、UNDO機能よりも(ネットワーク全体に対して)リビジョン制御システムと比較して優れています。

サポートされていないTime Voyagerシナリオ

• Apstraサーバーをアップグレードした後は、アップグレード時にブループリントのリビジョン履歴が破棄されるため、古いバージョンのブループリントにジャンプすることはできません。Apstraをアップグレードする前に使用した以前のApstraバージョンに戻す必要がある場合は、「 データベースの復元」を参照してください。この方法を使用すると、デバイス構成の観点から問題が発生する可能性があります。
• プリスティン設定がリビジョン間で変更されている場合はサポートされません。
• NOSのバージョンがリビジョン間で異なる場合はサポートされません。デバイスマネージャーを使用してNOSバージョンを同じバージョンにダウングレードし、以前のリビジョンにロールバックすることができます。
• 以前のリビジョンで割り当てられたデバイスが使用できなくなった場合、ビルドエラーシステム IDが存在しません。(逆に、デバイス を追加 して、 そのデバイスなしで 前のリビジョンにジャンプすると成功します。追加されたデバイスは削除されます)。
• 以前のリビジョンで割り当てられたリソースが再割り当てされると、 すでに使用中のビルド エラー リソースが発生します。ビルド・エラーを解決するには、そのグループの各メンバーにリソースを手動で割り当てるか、リソース・グループのオーバーライドをリセットします。(以前に割り当てられたグローバルリソースプールが変更された後に以前のリビジョンにジャンプすると、成功 する可能性があります が、インテント違反が発生する可能性があります。
• 手動によるデバイス構成変更が受け入れられている場合は、サポートされません。
• 結果のデバイス構成状態が異なるそれ以外のケースではサポートされません。

注:

Apstraサーバーのバックアップ/リストアを使用して、以前のリビジョンにジャンプしてみませんか?Time Voyagerは、Apstraサーバーとデバイス間の同期された構成を(可能な限り)維持します。Apstraのバックアップ/リストアでは機能しません。事実上、Apstraのバックアップ/リストアは、デバイス構成の観点からは帯域外の変更です。バックアップが復元された場合は、データベースバックアップから復元した内容がデバイス設定に反映されていることを確認するために、完全な設定をプッシュする必要があります。これはおそらく混乱を招くでしょう。

ブループリントからTime Voyager をクリックして、保持されているブループリントリビジョンに移動します。リストの最初のリビジョンがアクティブなリビジョンです。連続するリビジョンは、最新のものから最も古いものへと日付順に並べられます。