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
- End Point Group
- Existing EPG
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.