| This document is based on this functional spec document that Tom Mueller, Sahoo, Siva and myself participated in. Architectural ComponentsThe PaaS feature consists of the architectural components described in this section. These components are services that reside within an instance of GlassFish server, but depending on the configured topology, they may or may not be within the same server. The Platform As A Service (PaaS) feature is about considering the Java EE ecosystem as a set of services interoperating. These services can be of different types like a Java EE Service Type (Java EE Stack) or a Persistence Service (a Database). In GlassFish 3.2, we propose to add capabilities to understand Java EE application's explicit and implicit services requirements. Such requirements can then be implemented using basically three building blocks. At the lower level, the Infrastructure Management Service is responsible for managing hardware resources and allocate virtual machines. The IMS has no understanding of Java EE Services types. The Orchestrator resides above the IMS layer and is responsible for understanding the Services requirements of deployed applications, it delegates to the IMS the provision of virtual machines. Finally, the Elasticity manager is responsible for monitoring the runtime environment and dial up or down the services availability based on constraints set by the deployer or administrator. The diagram below show how these components fits together :
Unknown macro: {gliffy}
IaaS Management Service (IMS)The Infrastructure as a Service (IaaS) management service provides an abstraction of the IaaS cloud to the GlassFish software. This abstraction encapsulates various APIs that are available for managing cloulds. The IaaS management service is responsible for carrying out the decisions made by the elasticity manager and the orchestrator. If the IaaS provides VM-level monitoring services, then the IaaS management service communicates information about IaaS decisions (such as moving a VM) to the elasticity manager, which then includes that information into its elasticity algorithms. It is capable of allocating and de-allocating virtual machines across all groups defined in its configuration. Virtual machines are allocated across groups (virtualization management decision tbd) but the IaaS management service is responsible for deciding on which bare metal hardware such virtual machines should run. Server PoolsMachines are divided into server pools. Server Pools can be geographically determined, or can be based on network boundaries. Such pools are composed of physical machines and share the same virtualization technology (libvirt, jclouds..). It is unclear how well such groups will map to public clouds offerings (at worst I suppose you have a single group). The group will be managed by an IaaS management service which has the following APIs.
The IaaS management service will not duplicate the DAS responsibilities of maintaining a list of clusters or list of deployed applications. It's main responsibility is to provide bare metal and run VMs on it. I consider the IaaS management service stateless artifacts. The IaaS management service could be implemented as a standalone component on top of GlassFish nucleus distribution. TemplatesGlassFish 3.2 will be a template based virtualization solution. Templates are virtual machines disk that can be duplicated on demand to create a new virtual machine instance. Templates are usually provided by the IT department of corporations and very little assumption should be made about its content. Templates will need to provide a GlassFish installation or a way to automatically install GlassFish by providing a SSH access for instance. Templates will provide one to many services implementation (Java EE Service, Database Service, MQ Service, etc...) which must be identified when registering a template to the system. OrchestratorThe orchestrator is the top-level services that provides the ability to deploy an application to the cloud. It is responsible for:
The orchestrator uses a set of service plugins to allow applications to be deployed with various services such as a database, JMS, etc. Elasticity ManagerThe elasticity manager is responsible for providing elasticity to the deployed application. It is responsible for:
Domains ManagerAn optional deliverable of 3.2 is the Domains Manager. The Domains Manager is responsible for automating the process of creating a domain within the cloud. The domains manager may be a simple command line interface that is used by the PaaS admin to create a domain on behalf of a GlassFish user, or it could provide a GUI console that would provide a single landing point for users to create a domain (or domains), and it could even provide a simplified interface for application deployment. The domains manager is an optional part of the architecture, as the PaaS admin could manually allocate a VM from the cloud, create a GlassFish domain on it, and configure that domain to use the IMS. The domains manager could have the following functions: For GlassFish Users:
For the PaaS Administrator
The domains manager acts as an interface point for users of the PaaS. It has the ability to create a VM for a DAS. But it doesn't analyze applications, create VMs for clustered instances, create VMs for other services. It doesn't have a pluggable interface for service providers. The domains manager runs on a GlassFish DAS. The domains manager lifecycle begins with a manual installation of GlassFish with the PaaS feature. A separate GlassFish domain is needed to run the domains manager itself, i.e., separate from the domains that are being managed by users of the domains manager. If this GlassFish domain is to be run within the cloud itself, a VM for the domain would need to be manually created using tools from the cloud infrastructure. Domains Manager Data StoreThe domains manager stores the following information
DAS CreationHow the GlassFish cloud environment bootstraps itself depends on the deployment environment.
DeploymentThe most important difference with the PaaS Feature versus 3.1 is the deployment use case. In 3.1 the users were most of the time performing the following tasks when deploying an application to a multi-instance environments :
As you can see, the physical layout of the deployment is set before the deployment itself and the elasticity of the cluster can be achieved though manually adding instances to an existing cluster. With the PaaS feature, the dynamics will be reversed where the hardware is mapped to a deployment request and the elasticity is entirely managed by the PaaS architecture (of course manual modification could still be possible, tbd).The following steps is how the system could handle a cloud deployment request.
It is still unclear at this point where the virtual machines templates will reside. It is entirely possible that we choose to associate template management at the IaaS management service level as it is usually a primary function of the same IT department (the IaaS admin responsibilities). ElasticityElasticity will be mostly managed by the PaaS architecture within the DAS where instances can be provisioned or decommissioned following events, monitoring triggers. Let's have a look at the work the PaaS architecture will have to do to add a new GlassFish instance to a deployment environment.
|
