Summary
With the recent launch of the VMware Cloud on AWS Software Defined Data Center (SDDC) from VMware, many Business Critical Application (BCA) workloads that were previously difficult to deploy in the cloud no longer require significant platform modifications.
This post describes a Better Together demonstration VMware and AWS presented at VMworld 2017 using an Oracle RAC Database for high-availability zero-downtime client connection failover, supporting a Django-Python application running in a Native AWS Elastic Beanstalk environment.
Oracle RAC presents two requirements that are difficult to meet on AWS infrastructure:
- Shared Storage
- Multicast Layer 2 Networking.
VMware vSAN and NSX deployed into the VMware SDDC cluster meet those requirements succinctly.
The Django-Python application layer’s end-to-end provisioning is fully automated with AWS Elastic Beanstalk, which creates one or more environments containing the necessary Elastic Load Balancer, Auto-Scaling Group, Security Group, and EC2 Instances each complete with all of the python prerequisites needed to dynamically scale based on demand. From a zip file containing your application code, a running environment can be launched with a single command.
By leveraging the AWS Elastic Beanstalk Service for the application tier, and VMware Cloud on AWS for the database tier, this end-to-end architecture delivers a high-performance, consistently repeatable, and straightforward deployment. Better Together!
Architecture
In the layout above, on the right, VMware Cloud on AWS is provided by VMware directly. For each Software Defined Data Center (SDDC) cluster, the ESXi hypervisor is installed on Bare Metal hardware provided by AWS EC2, deployed into a Virtual Private Cloud (VPC) within an AWS account owned by VMware.
Each EC2 physical host contributes 8 internal NVMe high performance flash drives, which are pooled together using VMware vSAN to provide shared storage. This service requires a minimum number of 4 cluster nodes, which can be scaled online (via portal or REST API) to 16 nodes at initial availability, with 32 and 64-node support to follow shortly thereafter.
VMware NSX provides one or more extensible overlay logical networks for Customer virtual machine workloads, while the underlying AWS VPC CIDR block provides a control plane for maintenance and internal management of the service.
All of the supporting infrastructure deployed into the AWS account on the right side of the diagram is incorporated into a consolidated hourly or annual rate to the Customer from VMware.
In the layout above, on the left, a second AWS account directly owned by the Customer is connected to the VMware owned SDDC account for optionally consuming Native AWS services alongside deployed vSphere resources (right).
When initially deploying the VMware Cloud on AWS SDDC cluster, we need to provide temporary credentials to login to a newly created or existing Customer managed AWS account. The automation workflow then creates an Identity and Access Management (IAM) role in the Customer AWS account (left), and grants account permissions for the SDDC to assume the role in the Customer AWS account.
This role provides a minimal set of permissions necessary to create Elastic Network Interfaces (ENIs) and route table entries within the Customer AWS account to facilitate East-West routing between the Customer AWS Account’s VPC CIDR block (left), and any NSX overlay logical networks the Customer chooses to create in the SDDC account for VM workloads (right).
The East-West traffic within the same Availability Zone provides extremely low latency free of charge, enabling the Customer to integrate technology from both vSphere and AWS within the same application, choosing the best of both worlds.
Oracle RAC Configuration
Database workloads are typically IO latency sensitive. Per VMware KB article 2121181, there are a few recommendations to consider for significantly improving disk IO performance.
Below is the disk setup for Oracle RAC Cluster using VMware multi-writer setting which allows disks to be shared between the Oracle RAC nodes.
The Oracle Databases on VMware Best Practices Guide provides best practice guidelines for deploying Oracle Single Instance and Oracle RAC cluster on VMware SDDC.
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/vmware-oracle-databases-on-vmware-best-practices-guide.pdf
For the VMworld demo, the OCI compliant Oracle Instant Client was wrapped with the cx_Oracle python library, and Oracle’s Database Resident Connection Pooling (DRCP). Database connections are initially evenly balanced between the ORCL1 and ORCL2 instances serving a custom Database Service named VMWORLD.
By failing the database service on a given node, we demonstrate that only 50% of client connections are affected, all of which can immediately reconnect to the surviving instance.
An often overlooked challenge with Oracle RAC is that client connections do not automatically fail back after repairing the failure. Those client connections must be recycled at the resource pool level, which might require an application outage if only one pool was included in the design. Multiplexing requests over two connection pools in your application code allows each pool to be iteratively taken out of service without taking the application down.
Given such application design changes often are not tenable post-deployment, AWS Elastic Beanstalk makes quick work of that limitation by simply deploying a GREEN copy of your application environment, validating it passes health-checks, and then transitioning your Customer workload from BLUE to GREEN stacks. When the GREEN stack boots, its database connections will be properly balanced between instances as desired, after which the BLUE stack can then be safely terminated. Similarly, application code changes can be deployed using the same BLUE/GREEN methodology, affording rapid rollback to the original stack if problems are encountered. As many additional stacks can be deployed with a single command, “eb create GREEN”, or automated via REST-API.
At VMworld, we ran a live demo continuously failing each database service iteratively followed by an Elastic Beanstalk environment URL swap between BLUE and GREEN every 60 seconds, while monitoring Oracle’s GV$CPOOL_CC_STATS data dictionary view. The ClassName consists of the database service name VMWORLD, followed by the Beanstalk environment name, and the application server’s EC2 instance identifier. The second and subsequent columns of the below table indicate the RAC node servicing queries between refresh cycles.
Conclusion
VMware Cloud on AWS affords many Better Together opportunities to not only streamline operational processes by leveraging Native AWS services, but also enable a cloud-first IT transformation without needing to disruptively re-platform your Enterprise Business Critical Applications.
The cloud based SDDC cluster deployment is simply another datacenter and cluster managed in the same way you manage your on-premises VMware environments today, without needing to retool or retrain staff.
Creating and expanding SDDC clusters can be accomplished in minutes, allowing you to drive utilization to a much higher efficiency without concern for 18-24 month capacity planning cycles that must be budgeted for peak usage. Release burst capacity immediately after it is no longer needed without any CAPEX overhead, as well as the OPEX overhead of running your own datacenters.
Demo for the “Oracle RAC on VMware Cloud on Amazon AWS” can be found in the url below
https://www.youtube.com/watch?v=vpU0MW8tkhc
All Oracle on VMware SDDC collaterals can be found in the url below
Oracle on VMware Collateral – One Stop Shop
https://blogs.vmware.com/apps/2017/01/oracle-vmware-collateral-one-stop-shop.html
More information on VMware Cloud on AWS can be found at the url below
https://blog.cloud.vmware.com/s/services-and-products-vmware-cloud-on-aws
