Managed objects on NDO for Mulri-Site deployment

[Mario Rosi]

hi guys!

I’m working on a multi-site infrastructure and talking about "single site EPG/BD" vs "stretched EPG/BD" our first idea (as per best practices) was to create 1 Schema and 3 Templates as per the following:

- Site A Template (site association --> A
- Site B Template (site association --> B
- Streched Template (site association --> A & B

Let's assume that we have some objects in the Site A template and the customer wants to stretch this objects in both sites.

How do you manage this use case?

Our two hypothesis:

1) Destroy objects in Site A Template and recreate them in the Stretched Template --> distruptive and we don't like it

2) Do not segment the template as described above but put the objects into the Streched Template without enabling the "L2 Strech" flag. Enable it when necessary (based on customer's request) --> should be ok BUT all the objects will be always created in both fabrics even if they are not stretched

Other idea and/or suggestions?

thanks!

[HaiCa]

It will be good if I know your NDO version but since I do not, here a new feature on NDO version that "Migrating Objects Between Templates":

https://www.cisco.com/c/en/us/td/docs/dcn/ndo/4x/articles-441/nexus-dashboard-orchestrator-aci-templates-overview-and-operations-441.html

Is it non-disruptive? The answer is generally "It depends on the configuration," but in your specific case, it is not. Still, I recommend performing it during a short maintenance window.

Be aware that from NDO version 4.0(1), the best practices to define application templates have change. In fact, NDO added requirements and some environment can not deploy as only 3 template because of circular dependencies. Here the white paper for your convenience:

https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-739609.html#DeployingNDOschemasandtemplates

[Mario Rosi]

As written also in the document you provided :

”The objects will be migrated from the source template to the destination template that you selected. When you deploy your configuration, the objects will be removed from any fabric where the source Template is deployed and added to the fabric where the destination template is deployed.”

…so disruptive!

no way, the solution 2) looks to me the most affordable and safe at this point!

in terms of resources?

if I don’t stretch the BDs and EPGs, I would have shadow objects that APICs must manage so the scalability would be a problem in any case.

[HaiCa]

I don't think so, when you deploy the template, only the differently config be push, even un-managed or only local APIC config will not be deleted if not specify in the template itself. So in your case, no object be delete, no moving, it just be modified on the site A and add to APIC config of Site B.  

[MD Irshad Ansari · Accepted solution]

In practice, you usually don’t want to delete and recreate objects once they’re live, that’s too disruptive. The safer way is to place objects in the stretched template from the start and leave L2 stretch off until it’s really needed. That way they stay local until the customer asks, and you can just enable stretch without downtime.

If you want to keep a strict separation, another option is to use one schema for local-only objects and another for stretched ones, gives you cleaner control. But between your two options, #2 is definitely the more practical path.