Summary This article provides how we make use of CloudCenter’s brownfield import and action library feature with CloudEndure Disaster Recovery to create a Disaster Recovery replica at AWS Cloud for a VM running in On-premises vCenter Product Versions Validated Product Version Cisco CloudCenter 4.8.2 CloudEndure Live Migration SaaS Details The business continuity of applications is becoming important along with data protection and operation in case of service outage or a failure. Applications disaster recovery (DR) plan should ensure the continuation of business critical applications in the event of a disaster. Public clouds are increasingly becoming easy and quick DR site alternatives to traditional on-premises DR site setups. Failing over to DR site in case of hardware or software failure at primary site provides continuity to business applications. Whenever a failure occurs workloads are failed over to DR site and then failed back to primary site when the crisis is over. Using cloud orchestration and automation tools like CloudCenter, you can automate the cloud disaster recovery process end-to-end. Using automated mechanism for DR, IT can meet DR SLAs than using manual ways of administration and management. With latest release of Cisco’s CloudCenter you can implement DR for workloads in on-premises by discover existing virtual machines using Brownfield import feature. Imported VMs comes under the management domain of CloudCenter. Once imported the virtual machines can be governed, metered likewise. Action library feature in CloudCenter enhances the brownfield import feature by enabling day N operations like DR operations on Brownfield and Greenfield deployments. CloudEndure provides Live Migration and Disaster Recovery (DR) for any application, allowing companies to mobilize entire applications with their data to and across clouds with near zero downtime and no data loss. CloudEndure enables truly consistent, block-level, real-time replication using continuous data protection (CDP). Here, we will explore how we can make use of CloudCenter’s brownfield import and action library with CloudEndure Disaster Recovery to configure DR at AWS for Virtual Machines in vCenter Figure 1 – CloudCenter Disaster Recovery Flow for Brownfield VMs Flow of operations for Disaster Recovery of virtual machine using CloudCenter and CloudEndure: Day 0: Define the vCenter Cloud in CloudCenter Define the Disaster Recovery target cloud as AWS in CloudEndure SaaS Create Disaster Recovery actions in Action Library at CloudCenter to call CloudEndure DR tasks script. It then shows up as available Actions for a Virtual Machine in the cloud Enable DR – To start the replication to cloud (Action needs to be configured to execute On the Virtual Machine OS) DR Status – To check the status of DR replication to cloud (Action needs to be configured to execute Externally) DR Cutover – To cutover to DR site for a given virtual machine (Action needs to be configured to execute Externally) Figure 2 – VM Page of CloudCenter with DR actions Day 1: CloudCenter discovers existing Virtual Machines running vCenter Existing VMs show up as “Unmanaged” as list of running VMs in the cloud Import the VM(s) of interest(needed for DR) and Install CloudCenter agent. Import to CloudCenter feature brings the VM(s) under CloudCenter management thereby enabling administrator to use consistent governance, metering policies, and performing day N operations Execute the Enable DR Action to start the replication to cloud (Figure 3) DR replication status can be checked any time by performing DR Status action at the VM page When ready, perform DR Cutover to replicated version at the DR Site, in this case AWS After the cutover, the replicated VM shows up as “Unmanaged” in the destination AWS cloud Import to CloudCenter to make the VM appear as Managed VM in the CloudCenter Test the VM and its contents Perform the application cutover – Shutdown (or terminate) the source VM in VCenter, make the VM in AWS cloud live for the users by performing DNS changes Figure 3 – Enable DR for a VM Disaster Recovery Action(s) and CloudEndure DR Script Figure 4 – Details of Enable DR Action defined in Action Library of CloudCenter The script that gets called as part of Enable DR action in CloudCenter contacts the CloudEndure SaaS and performs the following steps: Installs CloudEndure Agent on the Source VM Triggers the replication to destination cloud Figure 5 – Virtual Machine DR Dashboard view in CloudEndure SaaS Figure 6 – VM Details Display in CloudEndure SaaS Scripts used in the validation exercise are available at the following github location: https://github.com/datacenter/c3-community/tree/master/Integrations/DisasterRecovery/CloudEndure Wrapper Scripts for various operations – init-xxx.sh CloudEndure Scripts for Disaster Recovery – CE_Cisco_Integration_XX.py Additional Information CloudCenter – http://www.cisco.com/go/cloudcenter CloudCenter Documentation – http://docs.cloudcenter.cisco.com/ CloudEndure – http://www.cloudendure.com/ CloudEndure Documentation – http://docs.cloudendure.com/ ... View more

Use below link for more information: Migrating Brownfield Applications from Private Cloud to Public Cloud   ... View more

Summary: This article focuses on how we can make use of CloudCenter to migrate existing applications to Cloud by navigating through different stages of migration like Application Discovery, Performance Baselining and Migration Service. CloudCenter interacts with different functions at different stages to migrate the application. Product Versions Validated: Product Version Cisco CloudCenter 4.8.0 AppDynamics APM SaaS iQuate SaaS CloudEndure SaaS Details: Moving applications to cloud can be overwhelming, customers want to move to cloud with near zero downtime. Users wants to move applications instead of individual VMs. Typical moves to cloud focuses on moving individual VMs. Usually the applications are group of VMs (1 or more).  Moving one VM in the application may break the application or create an orphaned state for an application. It is critical that whole application moves (which may be 1 or more VMs). It has been a challenge to find application components that interact with each other for existing applications (aka brownfield). With the help of Application Discovery tools, application dependency can be derived and grouping of VMs can be done in an environment. Once the application discovery is done then the application move can be planned. Following diagram depicts different stages for application migration using CloudCenter. Figure 1 - Application Migration Flow Application Discovery is the first step in identifying the application and its components. Making sure application performance is same or better in the public cloud requires that you have performance baselines established while the application is running in private cloud. Application is then migrated using lift and shift type migration tools. Performance baseline is again done with the application running in public cloud and comparing performance of application in pre-migration and post-migration phase gives you visibility into technical metrics and business metrics. CloudCenter lets you navigate through different stages by interacting with various tools at various stages of the application migration cycle. There are different tools available for each of the stages and with CloudCenter’s extensible architecture you can plug-in various tools based on your environment, management and application needs. Following is one way this can be achieved: Using iQuate’s iQCloud, application discovery can be performed in an existing environment. CloudCenter enables AppD agents on application VMs for performance monitoring. AppDynamics captures the performance of the application in the private cloud before migration. CloudCenter using CloudEndure moves application virtual machines to different clouds like AWS, Azure, Google. AppDynamics helps you compare performance of application in public cloud to its performance in private cloud. Action library feature in CloudCenter enhances the brownfield import feature by enabling day N operations on Brownfield and Greenfield deployments. Using Action library, CloudCenter can trigger AppDynamics Agent installs and application moves using application discovery data from iQuate. CloudCenter can call CloudEndure SaaS to do the migration. CloudEndure starts replicating the data to cloud and subsequently cutover can be planned. Figure 2 -  Example of Application Migration Flow General flow for moving applications from VMWare vCenter to AWS Enable iQuate application discovery for existing vCenter environment Export application discovery data from iQuate Setup AppD access and dashboard metrics Import applications and enable them for AppD monitoring at CloudCenter Build Pre-Migration performance baseline at AppD Controller Migrate application VMs to AWS from CloudCenter using CloudEndure Import VMs to CloudCenter after they get migrated to AWS Build Post-Migration performance baseline at AppD Controller Compare Pre and Post migration performance Enable iQuate application discovery for existing vCenter environment Setup account with cloud.iquate.com Install iQuate appliance in vCenter environment Configure iQuate appliance with credentials of virtual machines that needs to be monitored to perform application discovery Figure 3 – View of discovered application in iQuate Export application discovery data from iQuate Login to iQuate portal Export the developed application discovery data for applications in the vCenter environment Setup AppD access and dashboard metrics Setup AppD SaaS account or On-Premise Controller Define dashboard and metrics to monitor for the application like application transactions response time Import application VMs and enable them for AppD monitoring at CloudCenter Login to CloudCenter and browse to Virtual Machines > “Unmanaged” tab Import Application VMs based on discovery data from iQuate Install CloudCenter agent on the VMs Define “Install AppD Agent” action in Action library and install appropriate AppD Agent on the VMs Figure 4 – Import VM view in CloudCenter Build Pre-Migration performance baseline at AppD Controller Make sure traffic is hitting the application Login to AppD controller and browse to application flowmap. Define business transactions of interest Define/observe metrics in the application dashboard Migrate Application VMs to AWS from CloudCenter using CloudEndure Setup Account in CloudEndure portal at www.cloudendure.com Define destination cloud like AWS and VPC/Subnet parameters to be used If required, setup VPN connectivity between AWS VPC and vCenter environment if VMs are not reachable over public IP Define “Migrate to AWS” action in the Action library at CloudCenter to call a script which internally calls CloudEndure Script to perform the migration and make sure to configure the object mapping to apply action for imported VMs Execute Migrate action against set of Application VMs Figure 5 – Migrate Action view in CloudCenter Import VMs to CloudCenter after they get migrated to AWS Login to CloudCenter UI > Virtual Machines Once Migration is completed, the application VMs will show up as “Unmanaged” in the AWS cloud at CloudCenter Import VMs to CloudCenter management Test and perform the cutover by performing DNS/Network changes Build Post-Migration performance baseline at AppD Controller Make sure traffic is hitting the application after its cutover to AWS Login to AppD Controller Observe dashboard metrics and build performance baseline comparison Figure 6 – Performance Comparison dashboard of Pre and Post Migration stages The script that gets called as part of Migrate action in CloudCenter contacts the CloudEndure SaaS and performs the following steps: Installs CloudEndure Agent on the Source VM Triggers the replication destination cloud Creates a blueprint for replica configuration Instantiates the VM in the destination cloud Figure 7 – View of Migration in CloudEndure SaaS Script used in the validation is available at the following github location: https://github.com/datacenter/c3-community/tree/master/Integrations/Migration/CloudEndure Move Wrapper Script for Action – init.sh Script for migration – CE_Cisco_integration.py Demo of the migration of application is available at the following location: Video Link : 16765 Additional Information CloudCenter – http://www.cisco.com/go/cloudcenter CloudCenter Documentation – http://docs.cloudcenter.cisco.com/ Quate – http://www.iquate.com/ AppDynamics – http://www.appdynamics.com/ CloudEndure – http://www.cloudendure.com/ ... View more

Summary This article provides how we make use of CloudCenter’s brownfield import and action library feature with CloudEndure Live Migration to move Virtual Machines to AWS from vCenter Product Versions Validated Product Version Cisco CloudCenter 4.8.0 CloudEndure Live Migration SaaS Details Migrating applications to cloud can be overwhelming. Customers want to migrate to cloud with near zero downtime. With latest release of Cisco’s CloudCenter you can discover existing virtual machines using Brownfield import feature. Imported VMs comes under the management domain of CloudCenter. Once imported the virtual machines can be governed, metered likewise. Action library feature in CloudCenter enhances the brownfield import feature by enabling day N operations on Brownfield and Greenfield deployments. CloudEndure provides Live Migration and Disaster Recovery for any application, allowing companies to mobilize entire applications with their data to and across clouds with near zero downtime and no data loss. CloudEndure enables truly consistent, block-level, real-time replication using continuous data protection (CDP). Here, we will explore how we can make use of CloudCenter’s brownfield import and action library with CloudEndure migration to migrate Virtual Machines to AWS from vCenter Figure 1 – CloudCenter Brownfield Migration (existing workloads) Flow Flow of events for migration of virtual machine in CloudCenter and CloudEndure migration: Day 0:     1. Define the vCenter Cloud in CloudCenter     2. Define the target cloud in CloudEndure SaaS Day 1:     1. CloudCenter discovers existing Virtual Machines running vCenter     2. Existing VMs show up as “Unmanaged” as list of running VMs in the cloud     3. Import to CloudCenter feature brings the VM(s) under CloudCenter management thereby enabling administrator to use consistent governance, metering policies     4. Define a Migration action in Action Library to call CloudEndure Migration Script. It then shows up as one of the Actions for a Virtual Machine in the cloud Figure 2 – VM Page of CloudCenter highlighting Migration action button      5. Execute the Migration Action to start the migration to cloud Figure 3 – Migration Action for a VM      6. Once completed, the migrated VM shows up as “Unmanaged” in the destination AWS cloud      7. Perform #3 to make the VM appear as Managed VM in the cloud      8. Test the VM and its contents      9. Perform the cutover – Shutdown (or terminate) the source VM in VCenter, make the VM in AWS cloud live for the users Migration Action and CloudEndure Migration Script Figure 4 – Details of Migration Action defined in Action Library of CloudCenter The script that gets called as part of Migration action in CloudCenter contacts the CloudEndure SaaS and performs the following steps:      1. Installs CloudEndure Agent on the Source VM      2. Triggers the replication to destination cloud      3. Cr eates a blueprint for replica configuration      4. Instantiates a VM in the target cloud Figure 5 – VM Migration Dashboard view in CloudEndure SaaS       Figure 6 – VM Migration Log display in CloudEndure SaaS Script used in the validation exercise is available at the following github location: https://github.com/datacenter/c3-community/tree/master/Integrations/Migration/CloudEndure Move Wrapper Script for Action – init.sh Migration Script for Migration – CE_Cisco_Integration.py Additional Information CloudCenter – http://www.cisco.com/go/cloudcenter CloudCenter Documentation – http://docs.cloudcenter.cisco.com/ CloudEndure – http://www.cloudendure.com/ CloudEndure Documentation – http://docs.cloudendure.com/ ... View more

Summary Deploy, Monitor, Optimize Applications using Cisco CloudCenter and AppDynamics Product Versions Validated Product Version Cisco CloudCenter 4.8.0 AppDynamics APM 4.3.0.4 Details This article focusses on how you can attain benefits from CloudCenter and AppD working together. CloudCenter excels at deploying, managing the applications while AppD excels at monitoring, diagnosing the applications. Applications can deploy and operate themselves by making CloudCenter and AppD work together. We will explore how automating different parts of application deployment and application monitoring can resolve the scaling challenges of applications. Monitoring data at AppD controller can be used to scale up or down the different tiers of CloudCenter deployed application. Deploying Self Operating Applications with CloudCenter and AppD Figure 1: CloudCenter and AppDynamics Architecture When building application profiles in CloudCenter, you can point to AppD agent installation during the nodes bring up CloudCenter deploys the application to cloud of your choice and installs the AppD agent on the nodes Once the AppD agent is up and running, it starts sending metrics to AppD Controller AppD Controller keeps the stats and analyzes the data as per the policies configured You can configure different policies in AppD to take different actions, say scale the tier when the number of transactions go above a threshold CloudCenter receives the trigger from AppD to scale up or down the tier thereby making the application to self-adjust based on the load it experiences Let’s take example of a Composite Multi-tier Application with multiple SubApps and understand how we can scale a specific tier using AppD and CloudCenter. Composite Application (Multi-tier architecture) Figure 2: Composite Application View In this example, we have a Composite Application example where Web Front End is interacting with two Sub Applications via load balancers. Both Sub Applications use a shared MySQL Database instance. Each of the Sub App’s Apache php tier can be scaled up or down based on the traffic it receives from its users. Composite Application with AppD and CloudCenter (CloudCenter deploying the application and AppD APM monitoring it) Figure 3: CloudCenter and AppDynamics Integration with Composite Application 1. You can build a Composite application profile in CloudCenter with AppD agent configured to install on Apache php nodes. Figure 4: Composite App Profile in CloudCenter 2. Once the Application is deployed, the Apache php nodes from Web FrontEnd, SubApp1, and SubApp2 register themselves with AppD Controller and starts sending application metrics to the controller 3. AppD Controller starts tracking the application and its usage. AppD’s transaction level monitoring gives better view of application’s normal or deviating states Figure 5: Composite Application Flowmap View in AppD Controller 4. In this setup, policy is configured in AppD controller to trigger a scale-up action at CloudCenter on a Health rule violation. This can be configured differently on case to case basis and is very flexible. For this example, its steady state is 10-15 calls per minute and policy is configured to scale-up when calls per minute go above 30 Figure 6: Business Policy for Application in AppD Controller 5. Once AppD Controller detects a Health rule violation over its configured breach period, it sends a REST API call to CloudCenter to scale the number of nodes of the Apache php tier. In this example, we are focusing on monitoring application at the Apache php tier for Sup App2 Figure 7: Health Rule Violation detected in AppD Controller 6. CloudCenter then fires up another node in the Apache php tier thereby reducing the load on existing nodes of the tier Figure 8: Scaled Nodes of SubApp2 view at CloudCenter Deployment 7. The SupApp2 in the Composite application now comes to steady state operation with the Apache php tier scaled Figure 9: Scaled Nodes of SubApp2 view at App Flowmap in AppD Controller Similar to scaling up the number of nodes, user can define a policy to scale down the nodes based on scaling-down criteria. This flow of self-adjusting the application based on its needs makes the application operate on its own in the times of heavy load. Application admin does not need to perform different actions manually like monitoring and scaling separately. This reduces operational overhead by taking benefits of automation features of CloudCenter and AppDynamics. AppDynamics Agent Installation Script Examples Based on Application monitoring needs, appropriate AppD agent can be installed. Each of the agents have their specific installation requirements. AppDynamics documentation site is recommended for detailed information. Here is a pointer to a sample scripts for PHP Application Agent Install: PHP Application Agent Install: Sample script to install AppD PHP Application agent is available at this location ( https://github.com/datacenter/c3-community/blob/master/Integrations/AppDynamics/Deployment/c3-appd-php-agent-sample.sh) Machine Agent Install: Sample script to install AppD machine agent for Linux is available at this location (https://github.com/datacenter/c3-community/blob/master/Integrations/AppDynamics/Deployment/c3-appd-machine-agent-sample.sh ) Custom Action: Custom actions can be defined in AppD controller. Sample custom.xml file along with action script is available at this location. ( https://github.com/datacenter/c3-community/blob/master/Integrations/AppDynamics/Deployment/sample-custom.xml) Sample Script to scale a job at the CloudCenter is available at this location. ( https://github.com/datacenter/c3-community/blob/master/Integrations/AppDynamics/Deployment/update-job-up.py) Additional Information Cisco CloudCenter - http://www.cisco.com/go/cloudcenter Cisco CloudCenter Product Documentation - http://docs.cloudcenter.cisco.com AppDynamics – http://www.appdynamics.com/ AppDynamics Documentation – http://docs.appdynamics.com ... View more

Summary Enabling AppDynamics Monitoring for Brownfield Virtual Machines using Cisco Cloud Center Product Versions Validated Product Version Cisco CloudCenter 4.8.0 AppDynamics APM 4.3.0.4 Details This article focuses on how you can attain benefits from CloudCenter and AppD working together. CloudCenter discovers existing virtual machines in different clouds like vCenter, AWS. Let’s explore how monitoring can be enabled for existing (brownfield environments) virtual machines which were not deployed using CloudCenter Brownfield Virtual Machines Monitoring With CloudCenter’s support for brownfield environments you can now import and manage previously deployed workloads along with new CloudCenter deployed workloads, in both data center and cloud. With Action Library feature you can define and execute self-service post deployment management actions. By using CloudCenter’s Brownfield Import and Action Library features with AppDynamics, you can enable monitoring of Virtual Machines at the AppD Controller. Figure 1: CloudCenter Brownfield Support – AppD Agent Install with Custom Action defined in Action Library 1. CloudCenter discovers the existing VMs from your cloud and the discovered VMs show up as Unmanaged in CloudCenter Figure 2 – Unmanaged Virtual Machines in CloudCenter 2. Import VM brings the Virtual Machine into CloudCenter management Figure 3 – Import Operation for Unmanaged Virtual Machines 3. Install CloudCenter Agent (aka agentlite) to manage the VMs efficiently. Installing CloudCenter Agent on the VM enables exhaustive Cloud Center features like performing custom actions, governance, show back etc. Figure 4 – Install CloudCenter Agent Operation 4. Using Action Library, define the action to install AppD agent into the imported VMs. AppDynamics support different types of agents for applications like Java, PHP, .Net, etc including the machine agents for Linux or Windows operating systems. Following steps can be used to define Install AppD Agent action: Write a wrapper for agent install, say a shell script for installing a machine agent – see example for machine agent install in the next section Upload the script to one of the repositories or HTTP location Define an action:  Actions Library > NEW ACTION Provide inputs for Action Name – Install AppD Agent, select “On Virtual Machine OS” for Execute Action, Object Mapping (Imported VMs, choose default for other options), path to script (step b) in Executable Command like http://<IP>/appd/appd-install-agent-init.sh Figure 5 – Create Action Operation in Action Library 5. Once defined, the Action becomes visible as one of the options against Imported VMs in Virtual Machines section 6. Use Install AppD Agent action to install the AppD agent into the VM thereby enabling the VM to start getting monitored by AppD Controller Figure 6 – Install AppD Agent using the action defined in action library AppDynamics Agent Installation Script Examples Based on Virtual Machine or Application monitoring needs, appropriate AppD agent can be installed. Each of the agents have their specific installation requirements. AppDynamics documentation site is recommended for detailed information. Here is a pointer to a sample scripts for Machine Agent Install and PHP Application Agent Install: Machine Agent Install: Sample script to install AppD machine agent for Linux is available at this location (https://github.com/datacenter/c3-community/blob/master/Integrations/AppDynamics/Brownfield/appd-machine-agent-sample.sh). PHP Application Agent Install: Sample script to install AppD PHP Application agent is available at thi s location (https://github.com/datacenter/c3-community/blob/master/Integrations/AppDynamics/Brownfield/appd-php-agent-sample.sh). Additional Information Cisco CloudCenter - http://www.cisco.com/go/cloudcenter Cisco CloudCenter Product Documentation - http://docs.cloudcenter.cisco.com AppDynamics – http://www.appdynamics.com/ AppDynamics Documentation – http://docs.appdynamics.com ... View more

Summary This article provides how we can make use of CloudCenter’s brownfield import and action library with Rivermeadow migration to move Virtual Machines to AWS from vCenter Product Versions Validated Product Version Cisco CloudCenter 4.8.0 Rivermeadow Migration Service SaaS Details Moving applications to cloud can be overwhelming, customers want to move to cloud with near zero downtime. Business continuity is critical. With latest release of Cisco’s CloudCenter you can discover existing virtual machines using Brownfield import feature. Imported VMs comes under the management domain of CloudCenter. Once imported the virtual machines can be governed, metered likewise. Action library feature in CloudCenter enhances the brownfield import feature by enabling day N operations on Brownfield and Greenfield deployments. Rivermeadow moves Virtual Machines to different cloud like AWS, vCenter. Integrating Rivermeadow migration with CloudCenter gives users the ability to move the VMs. Figure 1 – CloudCenter Brownfield Move (existing workloads) Flow Flow of events for move of virtual machine in CloudCenter and Rivermeadow migration: Day 0: Define the vCenter Cloud in CloudCenter Define the target cloud in Rivermeadow SaaS Day 1: CloudCenter discovers existing Virtual Machines running vCenter Existing VMs show up as “Unmanaged” as list of running VMs in the cloud Import to CloudCenter feature brings the VM(s) under CloudCenter management thereby enabling administrator to use consistent governance, metering policies Define a Move action in Action Library to call Rivermeadow Script. It then shows up as one of the Actions for a Virtual Machine in the cloud Figure 2 – VM Page of CloudCenter highlighting Move action button Execute the Move Action to start the move to cloud Figure 3 – Move Action for a VM Once completed, the moved VM shows up as “Unmanaged” in the destination AWS cloud Perform #3 to make the VM appear as Managed VM in the cloud Test the VM and its contents Perform the cutover - Shutdown the source VM in VCenter, make the VM in AWS cloud live for the users Move Action and Rivermeadow Migration Script Figure 4 – Details of Move Action defined in Action Library of CloudCenter The script that gets called as part of Move action in CloudCenter contacts the Rivermeadow SaaS and performs the following steps: Registers the VM as one of the Source Verifies the prerequisites are in place in Source VM and destination AWS cloud Starts the replication of the data Once done, instantiates the VM in the destination cloud Detailed steps of the move can be viewed in the Rivermeadow SaaS console. Following figure shows different steps involved in the Migration. Figure 5 – View of Migration Steps in Rivermeadow SaaS Script used in the validation is available at the following github location: https://github.com/datacenter/c3-community/tree/master/Integrations/Migration/Rivermeadow/scripts Move Wrapper Script for Action – init-xxx.sh Migration Script for one-click migration – oneclickmigration2-xxx.py Additional Information CloudCenter – http://www.cisco.com/go/cloudcenter CloudCenter Documentation – http://docs.cloudcenter.cisco.com/ Rivermeadow – http://www.rivermeadow.com/ Rivermeadow Documentation – http://docs.rivermeadow.com/ ... View more

Summary This article provides a sample application profile that can be imported for use in Cisco CloudCenter which installs and configures a scalable OpenCart application, using a nginx loadbalancer and MySQL database. Product Versions Validated Product Version Cisco CloudCenter 4.8.0 OpenCart 1.5.6.4 nginix 1.10.2 MySQL 5.6.27 Details OpenCart is an Apache PHP based application with MySQL database. For this sample deployment of OpenCart we will front end Apache PHP with load balancer based on nginx. The Apache PHP tier will be modeled to be scalable with an initial node count of 2 (and the maximum number of nodes that the user or APIs are permitable to scale up to is configurable as well). The concepts demonstrated by this sample application profile can be used to model any other desired application. OpenCart is free open source ecommerce platform for online merchants. OpenCart provides a professional and reliable foundation from which to build a successful online store. In the above diagram, following requirements are being considered: Apache php tier is multi-node with initial deployment with two nodes MySQL database is modeled as single node nginx load balancer is front ending the Apache php tier      Figure - CloudCenter Topology Modeler view of the modeled OpenCart application Considerations for installing Apache php package: Installation scripts in OpenCart package create DB tables and other entries using Opencart.sql file during the install. With single node based Apache php tier it is not an issue. With multi-node tier, the first node works fine but the subsequent nodes hit issue while executing the sql file. Following changes have been made to account for that: Modified CREATE TABLE lines to CREATE TABLE IF NOT EXISTS so that it checks for TABLE presence before trying to create a table in DB Modified INSERT INTO lines to INSERT IGNORE INTO so that it checks for entries in tables before inserting them Added db_prefix ‘oc_’ in the cli_install.php file in install folder Install script for OpenCart package refers to Apache php tier IP as a http_server variable when issuing install command. This works fine when you have single node as the variable has single IP in it. With multi-node, the value has comma separated IPs of nodes of the apache php tier. The node IP needs to be derived from tier IPs and node names Applicable Profile along with OpenCart package contents are available at following github location: https://github.com/datacenter/c3-community/tree/master/ApplicationProfiles/Opencart/Multi-node Application Profile - opencart-multinode-app-profile.zip OpenCart Package - opencart.zip Openart Install Script - install_opencart_cli.sh DB Setup Script - createdb.sql Additional Information CloudCenter - http://www.cisco.com/go/cloudcenter CloudCenter Product Documentation - http://docs.cloudcenter.cisco.com OpenCart - https://www.opencart.com/ nginx - https://nginx.org/en/ MySQL - https://www.mysql.com/ Update History Date Comment ... View more