CloudCenter Integration Fundamentals - ACI Deployment: Existing EPG

[tuanngu4]

Summary

CloudCenter offers three fundamental deployment models pertaining to an ACI-enabled cloud: Existing EPG, New EPG and Bridge Domain Template. This series of articles will describe the different models and explain the resultant artifacts on the fabric.

CloudCenter and Cisco ACI are application-centric platforms which as a result take a top down approach when it comes to application delivery. Because CloudCenter is tightly and natively integrated with the APIC, not only are the requirements of the application satisfied during the design phase, the network and security requirements are similarly satisfied during the execution phase. When an application is deployed by CloudCenter into an ACI fabric, the conventional APIC objects and policies are dynamically created and applied to the respective virtual machines.

Items to note:

The environment used for this documentation is a dCloud reserved lab, so the APIC is a simulated version of the platform.

The CloudCenter version referenced for this document is v4.7.3, which includes many enhancements to the ACI integration. 

Primary Guiding Assumptions

• CloudCenter considers the Existing EPG(s) to be wholly sufficient, meaning that any policies required in order to deliver application to and from the EPG members are already in place.
• CloudCenter will not manipulate the Existing EPG(s) - no new contracts will be applied and no existing applied contract will be removed
• If the CloudCenter components (CCM, CCO, AMQP) are contained in a different and separate tenant than the existing EPG(s) into which the application nodes will be deployed, policies and corresponding contracts should exist and be applied so as to allow the nodes to reach the requisite CloudCenter services
• CloudCenter does not currently support uEPG(s)
• The typical ACI constructs for the tenant (Bridge Domain, DHCP Policy/Relay Label, VRF, External Routed Network - whether tenant specific or shared from the common tenant) are pre-configured and operationally healthy

ACI Configuration

• If you have participated in a dCLoud lab you will find some of these configurations familiar
• Tenant: CliQr
  • AP: Application-Services (added for the purposes of this article)
    • EPG:
      • App-Servers
      • DB-Servers
        • Contract: External_Outbound (Consumed from the common tenant L3_Out EPG)
        • Contract: CloudCenter-Mgmt (Consumed from the common tenant L3_Out EPG)
        • Contract: DB-Srv (Provided to the common tenant L3_Out EPG)
      • Web-Servers
        • Contract: External_Outbound (Consumed from the common tenant L3_Out EPG)
        • Contract: CloudCenter-Mgmt (Consumed from the common tenant L3_Out EPG)
        • Contract: Web-Srv (Provided to the common tenant L3_Out EPG)
  • BD: Production
  • VRF: dCloud-CliQr
    • EPG Collection: no associated policies

• Tenant: common
  • BD: BD_Common
  • VRF: VRF_common
  • External Route Network:
    • L3_Out
      • Provided Contract: CloudCenter-Mgmt
      • Provided Contract: External_Outbound
      • Consumed Contract: Web-Srv
      • Consumed Contract: DB-Srv

• NOTE: The ACI simulator does not offer a data path, so the objects displayed are for logical reference. The configuration herein simulates the characteristics of a real ACI fabric. Only the filters for the Web-Srv and DB-Srv contracts have been created and those contracts applied. This omission was deliberate as the App-Srv contract is not required for the OpenCart application and thereby for the purposes of this article.

CC Application Profile

• To enable an application for ACI compatibility, enable the micro-segmentation capability in the application  profile (AP) - the one being demonstrated is OpenCart, a two-tier AP
  • Application Profile: Basic Information tab
    • Enable micro-segmentation (check this box)
      

• This AP uses two of the out-of-box services from the content library, the Apache and MySQL services
• These services contain predefined firewall rules (Apache with TCP ports 80 & 443 and MySQL with TCP port 3306) allowing access to CIDR 0.0.0.0/0 by default
• In this sample AP Apache allows 0.0.0.0/0 to access TCP port 80 only, as the OpenCart application does not have an HTTPS interface

• The difference in the firewall ruleset between the two tiers is more clearly displayed in the Database tier (or the MySQL service)
  • Access is allowed to all members of the Apache tier (contextual association) because the dependency mapping has been drawn and the micro-segmentation has been enabled. In order for the contextual association to work, the MySQL service must have firewall rules configured prior to the dependency mapping being drawn.
  • In ACI terminology, the Apache tier provides the contract to members of 0.0.0.0/0 (typically for Ingress flow) and the Database tier provides the contract to members of the Apache tier

• NOTE: Since the focus of this article is the Existing EPG model, and since the aforementioned guiding assumptions apply, CloudCenter will neither create ACI artifacts nor apply any existing ones. Also, if the Enable micro-segmentation capability is not selected and the firewall rule for the MySQL service, when manually created, specifies the Apache tier as the source network, CloudCenter would apply the same treatment to the application deployment as when the capability is enabled.

CC Environment

• To activate the native APIC integration in CloudCenter, simply add the endpoint URL of the APIC as an Extension in the Admin area
  • In this environment the URL specifies an HTTP location; the option to direct to the HTTPS interface is within this article
• ACI Extension requirements:
  • APIC Controller URL
    • can be in IP_Address or FQDN form
  • User name
    • this specific user should exist on the APIC and the user's privilege managed by the RBAC capabilities provided by the APIC
  • Password
  • Managed Orchestrator
    • this CloudCenter Orchestrator would typically be co-resident with the same vCenter managing the Virtual Machine Manager (VMM) domain integration

CC Deployment Submission

• Much of the user's experience during the deployment submission can be predefined in the Default Settings of the Deployment Environment
• Deployment Requirements
  • Use ACI Extension in On position
  • APIC Extension
    • dCloud_APIC
      • Once the extension is selected, CC will auto-discover the objects relevant to the privileges of the user whose credentials were used to configure the ACI Extension
  • Virtual Machine Manager
    • My-vCenter
      • This is specified by the APIC
  • APIC Tenant
    • CliQr
      • This is specified by the APIC and configured according the the description in the above section
        
  • L3 Out
    • non selected
      • Though there are two routed networks in this environment, one at the tenant level and one in the common tenant, they will not be selected
  • Network Type
    • ACI
  • End Point Group
    • Existing EPG
  • Existing EPG
    • Web-Servers

• DB-Servers

ACI policies

• In this case, the tenant EPG(s) connect to the L3_Out EPG in the common tenant via the External_Outbound contract
• Expected outcomes from the deployment (Existing EPG model)
  • Since the EPG(s) has already been configured and since CC does not support uEPGs, the virtual machines provisioned by vCenter will be connected to the EPG (vDS port group) and can be observed in the Operational tab of the EPG

Exceptions

• Earlier I stated that CloudCenter will not create ACI artifacts while this deployment model is chosen. This is partially true and only applies if the L3 Out selection is unconfigured. If the L3 Out routed network is selected, the following behavior will be observed:
• If the common tenant L3_Out EPG is selected during the deployment submission
  • The L3_Out selection during the deployment submission determines the association of contract(s) for ingress flows, such that the policies configured in the Firewall Rules in the CC Application Profile dictate the filters/policies created for the respective EPG members in ACI - these are then applied to the selected L3 Out EPG
  • The filters and contracts are created based upon the application profile's specifications

• And applied to the L3_Out
  • These would be applied to the L3_Out EPG if it was selected during the deployment submission

• NOTE: You must apply these contracts to the existing Web-Servers and DB-Servers EPGs manually if the contracts contain filters that are not already configured and if you want to connect external clients to the deployed application nodes
• Objects created by CC in ACI to satisfy the requirements of the application would, in accordance with the lifecycle framework, be destroyed upon the application's termination in CC

• The behavior detailed above would significantly differ had the deployment model been New EPG. The subsequent articles will enumerate these differences.
  

[dfreedman]

This is the first of the articles you've written that I've read.  I intend to read "New EPG" and "BD Template" deployment model articles next.

The following are my comments/questions.  Of course, in some of my experiences I could personally be doing something wrong with or without knowing it, so bear that in mind as you read.

Primary Guiding Assumptions section is fully understood.

ACI Configuration section is fully understood.

CC Application Profile section:

• Is the “enable micro-segmentation” checkbox new as of v4.7.3 and required for successful application deployment with an ACI integration?  Reason for the question:  I was not aware of this checkbox, as such my recent app deployment tests ran with this checkbox disabled.  App deployments sometimes succeeded and sometimes failed.  What are the intended/true impacts of enabling this setting?
• What is the point of configuring the 0.0.0.0/0 TCP/80 firewall rule on the web-tier app node (or any other firewall rule on any other tier app node) if this article is about existing EPGs and per assumptions, existing EPGs are wholly sufficient and CC will not manipulate existing EPGs?
• I learned about “contextual association” of firewall rules between tiers which I didn’t know about previously (or had not previously noticed/attempted), so thank you for that.  However, it seems limiting that in order for this to work properly that the DB tier firewall rules must be configured BEFORE drawing the ‘drag and drop’ connection between tier elements in the workspace.  This comes down to an ‘order of configuration operations’ requirement within the software itself and from my perspective is an unlikely to occur.  I personally would lay out all of my app tiers in the workspace, draw their dependencies, and then set out to configure the requirements for each tier (top down:  look at the big picture before looking at the small picture within each of the finer app tier elements).  I would argue that this functionality should work regardless of the order of configuration operations within CC software.  From my perspective, to have a dependency on the order of configuration operations is to generate a lot of support calls for no good reason. If that’s not going to change I would argue against using contextual firewall rules between tiers and use firewall rules leveraging IP space to identify the desired tier since it’s likely each tier will be designed with its own IP space to begin with (not necessarily true when ACI is deployed in an application centric model, where all app tiers may be held within the same IP space because IP is just an identifier and has nothing to do with policy).  Also, back to Q2… per assumptions, I thought we said none of these contracts would apply to existing EPGs anyways?

CC Environment section is fully understood.

CC Deployment Submission section:

• If the L3OUT pre-exists as it must in the ACI fabric, for what reason would we not select this in the Deployment Environment Defaults?  My understanding is that Deployment Environment Defaults, while exposed to consumer-based users of CC, can still be modified by the user… in which case, does it really matter if any of these settings are selected or not, other than to try to guide the user when ultimately they are responsible for understanding how all of these settings could impact their application deployment efforts (which I feel is unrealistic for most shops)?  My understanding is that Simplified Networking is used in an attempt to limit what the consumer-based user can modify before deployment (in my mind this is a good thing), however in my testing I’ve found that despite Simplified Networking containing an opportunity to define all of the same settings, deployment using Deployment Environment Defaults functions properly and Simplified Networking does not.

Exceptions section. Maybe going to answer one of my own previous questions.  So if I’m reading this correctly, CloudCenter will create ACI artifacts when “Existing EPG” deployment model is chosen if the L3out selection is configured?  I personally would always choose the L3out so as to be deterministic about desired traffic flows… which now means that ACI would create and apply artifacts (contracts) to node Existing app-node EPGs to ensure communication between them and EPGs within the common tenant or with the outside work (External EPG)?

To summarize:  In my mind, “Existing EPGs” means what the assumptions stated at the beginning of the article.  In this mode I expect zero automation of any kind coming from CC with regards to ACI artifacts being created or terminated.  In fact, in this mode I do not want CC making any changes regardless of which settings may or may not have been selected (L3out, etc).

[tuanngu4]

Dan, nice to see that you've conquered yout longstanding bout with brevity. My responses corresponding to your comments:

CC Application Profile section:

• The checkbox is not new to v4.7.3, it was developed alongside the initial integration with ACI. It is no longer required for deployment into an ACI fabric but is required to deliver “micro-segmented” application tiers into public clouds (Azure, AWS, GCE).
• The point of that configuration is that there is a “universal” benefit to doing this, even though the “Existing EPG” deployment model does not honor these rules. Here, I am alluding to the ability for application architects to avoid having to reduce having to create application profiles based on common denominators. Had I created an application profile for “Existing EPG” and one for “New EPGs” then I would negate the inherent benefit of CloudCenter’s cloud agnostic posture.
• So from my perspective, every application service, whether out of box or custom, should include the anticipated security posture. This should be a design-time decision and not primarily a deployment-time decision. So when an application architect onboard the service the architect expects for that service to contain the expected firewall rules. Suppose the service did not contain these - the architect would have to repeat the process every time the service is onboarded in the topology modeler. This would be a heavy technical burden and in my mind a unnecessary one. Now. if you want to use an IP space and forego the contextual rules nothing prevents you from doing so but please understand that you will be imposing a specific desired state and taking away the ability of the platform to dynamically handle the mapping. Where the fabric is related, and not necessarily in this deployment model but in the “New EPG” and "Bridge Domain Template,” the subnets backing the Bridge Domains can be numerous and would require an automated treatment. You are correct that in this model, the firewall rules would be ignored because CloudCenter retains the integrity of the existing EPG. Again, on application profile for the three deployment models, and conceivably for more deployment models like public clouds with the requirement for “micro-segmentation."

CC Deployment Submission section:

• I strongly suggest that you involve support if you are seeing inconsistencies with the Simplified Networks feature. I agree with your statement regarding Simplified Networks. I think that the user experience for unprivileged users deploying into very specific predefined environments should be curated and simple. However, not every user carries that profile. For privileged users deploying into production or quasi-production (staging) environments, the user experience is not the same. For that reason, I left the options visible. My suggestion is to NOT select the L3 Out network for the “Existing EPG” model. I wrote the exceptions section to offer a truthful representation of what CloudCenter does under the hood. These articles are not intended to be a progressive march toward best practice conventions but more a veracious report of what to expect from the integration.