Schema Design Considerations
A schema is a collection of templates, which are used for defining policies, with each template assigned to a specific tenant. There are multiple approaches you can take when it comes to creating schema and template configurations specific to your deployment use case. The following sections describe a few simple design directions you can take when deciding how to define the schemas, templates, and policies in your Multi-Site environment.
Keep in mind that when designing schemas, you must consider the supported scalability limits for the number of schemas, templates, and objects per schema. Detailed information on verified scalability limits is available in the Cisco Multi-Site Verified Scalability Guides for your release.
単一スキーマの展開
スキーマ設計の最も簡単なアプローチは、単一のスキーマで単一のテンプレートを導入することです。単一のテンプレートを含む単一のスキーマを作成し、そのテンプレートにすべての VRF、ブリッジドメイン、EPG、コントラクト、およびその他の要素を追加して、1 つまたは複数のサイトに展開することができます。
Multi-Site スキーマを作成する最も簡単な方法は、同じスキーマとテンプレート内にすべてのオブジェクトを作成することです。ただし、サポートされているスキーマの数に制限があるため、このアプローチは大規模な展開に適していない場合があります。これは、これらの制限を超える可能性があります。
また、このアプローチでは、テンプレートで定義されたすべてのオブジェクトが「ストレッチ オブジェクト」になり、テンプレートに加えられたすべての変更が、そのようなテンプレートに関連付けられたすべてのサイトに常に同時に展開されることに注意してください。
ネットワーク分離での複数スキーマ
スキーマ設計のもう 1 つのアプローチは、ネットワーク オブジェクトをアプリケーション ポリシー設定から分離することです。ネットワーク オブジェクトには、VRF、ブリッジ ドメイン、サブネットなどがあり、アプリケーションポリシーオブジェクトには EPG 、コントラクト、フィルタ、外部 EPG、およびサービス グラフが含まれます。
最初に、ネットワーク要素を含むスキーマを定義します。すべてのネットワーク要素を含む単一のスキーマを作成するか、または、それらを参照するアプリケーション、またはネットワークが拡張するサイトに基づいて、複数のスキーマに分割します。
次の図は、VRF、BD、およびサブネットが設定され、2 つのサイトに展開されている単一のネットワーキング テンプレート設定を示しています。
その後、各アプリケーションのポリシー オブジェクトを含む、1 つ以上の個別のスキーマを定義します。この新しいスキーマは、前のスキーマで定義されたブリッジ ドメインなどのネットワーク要素を参照できます。次の図に、2 つのアプリケーション テンプレートを含むポリシー スキーマを示します。これらのテンプレートの両方が外部スキーマのネットワーキング要素を参照しています。アプリケーションの一方は 1 つのサイトにローカルであり、他方は 2 つのサイト間で拡張されます。
ポリシー スキーマとテンプレートを作成して展開すると、ネットワーク スキーマのネットワーキング オブジェクトに、ポリシー スキーマ要素による外部参照の数が表示されます。外部参照を含むオブジェクトは、上のネットワーク スキーマの図に示すように、リボンのアイコンでも示されます。
この方法で設計されたスキーマは、ネットワーキング オブジェクトをポリシー オブジェクトから論理的な分離します。ただし、これにより、各スキーマで外部参照されたオブジェクトの追跡はさらに複雑になります。
Multiple Schemas Based On Object Relationships
When configuring multiple schemas with shared object references, it is important to be careful when making changes to those objects. For instance, making changes to or deleting a shared networking object can impact applications in one or more sites. Because of that, you may choose to create a template around each individual site that contains only the objects used by that site and its applications, including the VRFs, BDs, EPGs, Contracts, and Filters. And create different templates containing the shared objects.
The site1 template in the above figure contains only the objects that are local to Site1 and the template is deployed to only the Miami site. Similarly, the site2 template contains only the object relevant to site2 and is deployed to the San Francisco site. Any change made to any object in either of these templates has no effect on the other one. The shared template contains objects that are shared between the sites.
You can extend this scenario for an additional site with the following template layout:
-
Site 1 template
-
Site 2 template
-
Site 3 template
-
Site 1 and 2 shared template
-
Site 1 and 3 shared template
-
Site 2 and 3 shared template
-
All shared template
Similarly, rather than separating objects based on which site they are deployed to, you can also choose to create schemas and templates based on individual applications instead. This would allow you to easily identify each application profile and map them to schemas and sites as well as easily configure each application as local or stretched across sites.
However, as this could quickly exceed the templates per schema limit (listed in the Verified Scalability Guide for your release), you would have to create additional schemas to accommodate the multiple combinations. While this creates additional complexity with multiple additional schemas and templates, it provides true separation of objects based on site or application.
フィードバック