Platform as a Service (PaaS) Competency Center Blueprint
Architectural Impacts of PaaS Concept:While PaaS does not impose a specific architecture for implementation, it is important to consider the types of applications that will be used in the platform. Restrict your Tenants to a small set of available architecture choices that reflect a set of common scenarios.
Enablers: Flexible Infrastructure Pre-requisites:None Last Modified:10/5/09
Private cloud instances should follow one or more pre-determined architectural templates to reduce the amount of initial administration required to set up an instance. A best practice is to consider a small number of architectural configurations to meet the needs of various cloud customer types. One approach is to segment based upon expected cloud usage patterns:
a) Single instance development cloud
b) Small population test/production cloud
c) Large population production cloud
One way to develop a unit of scalability for the cloud instances is to think about how the cloud instance handles requests via nodes . A single node represents at least an application server instance which is accessing a shared pool of database instances via RAC. Multiple nodes represent some coordinated set of application server instances that may be utilizing the RAC facilities directly or leveraging a data grid environment for greater scalability.
It is also possible to break cloud instance architectures down by their High Availability requirements.
a) No High Availability required
b) Highly Available with moderate failover time (e.g. hours)
c) Highly Available with strict failover time (e.g. minutes, seconds)
It is important to define what is meant by High Availability . Any multiple-node cloud should be able to withstand the failure of a node (JVM) process with degraded service levels. In other words, the cloud instance provides continuous uptime guarantees. This percentage of uptime is a variable factor in the development of cloud infrastructure, and for this discussion it can be assumed that general purpose dedicated servers supply adequate uptime for a cloud instance.
What is then configured per cloud instance is the failover time in the event of a catastrophic failure of the underlying hardware (either to the same or different data center). As such, for strict failover times it will be important to spread the cloud instance across multiple physical servers and possibly take data center replication into account.
Looking at the combinations of these two dimensions (scalability and fault tolerance), one can produce a set of cloud instance templates which will drive the configurations:
An important feature of a private cloud is that Tenants should not be concerned with the actual physical architecture running their application. While they may specify some initial parameters describing the intended usage of their cloud instance (e.g. Memory Intensive or CPU Intensive ), the details should not be important. Based upon the Service Level Agreement (SLA) established with the Tenant, a specific Quality of Service (QoS) describing latency or failover times will drive the actual physical implementation of the cloud instance. It is possible to use the table above as a starting point for describing the available cloud instance types to a Tenant in a self service application and keep the actual number of nodes in the domain as an implementation detail behind the scenes.
The types of business applications can be defined as follows:
short lifetime (weeks or months), a handful of occasional users whose inability to use the application has little to no impact on the business.
undetermined lifetime, a few dozen occasional users whose inability to use the application has moderate impact on the business.
long lifetime, several hundred periodic users whose inability to use the application has measurable impact on the business.
long lifetime, several thousand latency-sensitive users whose inability to use the application has serious and measurable impacts to the business.
Single Node Architecture
This cloud instance is the simplest to deploy and manage. It is effectively just a domain with a single Administration Server node that is hosting the Tenant's applications.
This architecture sets the foundation for all other cloud instance types. The single node is pre-configured to the JDBC Data Source representing the Tenant s allocated RAC storage. In addition it is pre-configured to authenticate against both the embedded LDAP inside the WebLogic domain as well as the cloud Administrator directory.
A hypothetical physical architecture is shown below:
The WebLogic portion of the cloud instance is comprised of a single JVM running WebLogic Server listening on port 7134. The database is a basic RAC instance running on another server with its database files handled by a shared storage appliance.
Note that all of the WebLogic install and domain files are stored on a shared NAS appliance and the actual server simply has a set of mount points defined for those paths. This means that the physical server where the domain runs has no dependency on the underlying file system holding the domain and as such can be replaced with a larger or smaller scale server without any need to change the domain configuration.
Note also that the single node architecture is effectively the same whether or not it is running in an OVM image.
These cloud instances follow the traditional WebLogic architectural practices for multi-node clusters. A best practice is to have a single cluster per domain to reduce complexity of management.
The introduction of additional nodes into the domain also raises the question of load balancing. In keeping with the design goals of a private cloud, load balancing should be incorporated into the cloud instance configuration itself and kept isolated from the Tenant. By having the cloud instance own its own load balancing mechanism it will be simpler for the provisioning process to notify the load balancer when the node count changes in the cluster. Depending upon the type of client traffic into the cloud applications the load balancing strategy will need to be addressed.
There are several options for HTTP load balancing in the multi-node architecture:
1. Dedicated WebLogic server node with load balancer servlet deployed. This option requires no additional software deployed for the cloud infrastructure besides WebLogic server. A downside to this approach is performance and the need for additional WebLogic licenses simply for the purpose of load balancing.
2. HTTP server deployed in front of cluster with WebLogic plug-in deployed. This option provides flexibility (e.g. Apache, IIS) however these products are deployed, provisioned and managed differently than WLS.
3. Shared hardware load balancer deployed inside cloud infrastructure. This option provides the greatest performance however is costly on a per-cloud instance basis.
Load balancing non HTTP traffic into the cloud is more complex as it requires additional configuration information to be made available to the generated EJB or JMS clients.
Multiple node architectures will be impacted by the decision to run in an OVM image- namely the choice of how to partition the nodes across server instances (physical or virtual).
The choice of Moderate or Strict failover times will dictate how the cloud infrastructure is deployed to physical or virtual servers. A simple Moderate cloud instance (shown below) may be able to meet the failover SLA by simply having the ability to re-create itself on another server instance and be prepared to handle client traffic within a few hours. This process may involve the location and preparation of new server hardware from a dedicated resource pool as well as the full provisioning exercise of WebLogic domain and application deployment.
Strict failover times involve a higher degree of engineering to provide shorter failover times. A traditional approach for establishing minimal failover times is to have the WebLogic domain spread its nodes across multiple physical servers. In this configuration there is a level of redundancy within the cloud instance such that a physical server failure only degrades service levels and does not take down the entire cloud instance. The individual WLS nodes, through normal RAC Service failover protection will be guaranteed data availability.
Additional levels of protection can be established by provisioning the cloud instance in two different data centers and handling the replication of application data between the environments. This replication can be handled either at the database or application tier depending upon the type of application being deployed into the cloud. This configuration is suitable for production clouds running mission critical applications.
Utilizing a Data Grid
The data access patterns of the applications inside the cloud infrastructure can also influence whether a data grid approach is required. A data grid (such as Coherence) provides an intermediate memory-based facility for handling the data necessary for an application. The data grid capacity is bounded only by the available server resources and therefore makes an excellent technology to support a cloud instance s data management needs.
The addition of a data grid significantly extends the abilities of a cloud infrastructure to handle additional scale without modifying the number of nodes in the domain. It also helps with maintaining uptime for user requests even in the event of a database connection failure.
The scale-out for a data grid enabled cloud instance can be achieved quite simply by adding new Coherence cache servers to the grid. These cache servers might be deployed on the same physical servers as other cache servers or additional server machines as needed. Coherence automatically balances the work of the data grid across the available cache servers dynamically as they enter and leave the grid.