ScaleDL Overview
2nd draft (7.10.2014)
Jure Polutnik, XLAB
Scalability management for Cloud Computing
/ Seventh Framework Programme:
Call FP7-ICT-2011-8
Priority 1.2 Cloud Computing
Collaboration Project (STREP)
Table of Contents
1.Introduction
1.1Overview
1.2Quick Example
2.Concepts
1.3ScaleDL Overview views
1.4Architecture view
1.4.1Layers
1.4.2Services
1.4.3Usage Proxy
1.4.4Connections
1.5Application definition view
1.5.1Example
1.6Specification view
1.6.1Service specification
1.6.2Cloud environment specification
1.6.3Deployable service specification
1.7Deployment view
1.7.1Clustered and Scalable deployment
1.8Examples
1.8.1Example: ScaleDL Overview model of sample web-shop application (TPC-W)
System architecture modelling steps:
1.8.2Example: ScaleDL Overview modelling in CloudScale Environment
1Introduction
The ScaleDL Overviewis a meta-model that provides a design-oriented modelling language for cloud-based system architectures and deployments. It has been designed with the purposeof modelling cloud based systems from the perspectives of service deployments, dependencies, performance, costs and usage. It provides the possibility of modelling private, public and hybrid cloud solutions, as well as systems running on non-elastic infrastructures.
The ScaleDL Overview consists of Architecture, Application, Specification and Deploymentviews. The ArchitectureView provides a descriptive abstraction of the system’s architecture, defined using cloud layers (i.e. infrastructure, platform and software layer), consisting of services as a basic building blocks. Service solution stack (i.e. vertically dependent services) is defined through deployment dependencies; referencing the service needed on the lower layer (i.e. infrastructure layer) for successfully deploying services on an upper layer (i.e. platform layer). The dependencies between service solution stacks are further defined through use of connection elements, representing network connectivity between service stacks. The connectivity with external environment is defined through UsageProxy for exposing services and ExternalSoftwareServices for referencing Software-As-A-Service (SaaS) services.
The Application Viewprovides a high-level definition of the system’s application, through services exposing operation interfaces (software and support platform services), the dependencies between them (provided and required interfaces). The operation interfaces exposed to external environment are defined through usage proxies, while using operation interfaces provided by external services (i.e. SaaS) through external proxies.
Service information, performance (SLOs) and costs are further described using Specification View. Additionally ScaleDL Overview meta-model contains Cloud Definition, defining services available in specific cloud environment and Platform Service Definition, defining deployable platform services (e.g. databases, application servers, etc.) that are deployable in the environments providing Infrastructure-As-A-Service (IaaS). Both definitions can be defined in advanceand used when constructing ScaleDL Overview models.
Deployment View provides information of how the services are deployed, theirs runtime configuration and also monitoring results. For the infrastructure and provided platform services it defines runtime and generic (i.e. black-box) deployments. First describes the elastic properties of the service deployment while for the later the expected performance and SLOs of external services.
The model has been developed under the CloudScale project, with the aim of providing a well-defined descriptive model to be used by the CloudScale Environment, itself a solution that allows defining and analysing scalability and performance features of cloud based systems. The core functionality of the system is provided through the CloudScale tool-chain; Analyser, Extractor and Spotter, and the goal of the CloudScale Environment is to seamlessly integrate all these tools by providing user-friendly interfaces to operate with them. The basis to achieve such integration is the ScaleDL Overview, which will provide a high-level view of the cloud system: the information needed for automatize usage ofthe Extractor and Spotter (Dynamic and Static), and a transformation into the Extended PCM model on which the Analysercan perform system analysis.
1.1Overview
The root entity of the system architecture is the CloudEnvironment, which defines an abstract cloud environment, split into three layers: SoftwareLayer, PlatformLayer and InfrastructureLayer. The basic element in each layer is the Service, which is further divided into three layered service classes: SoftwareService, PlatformService and InfrastructureService. Services in the architecture model represent high-level abstraction of cloud-based resources (e.g. application, database service, elastic computing infrastructure, etc.) and are further specified through ServiceDescriptorsand configured through ServiceDelpoyment, representing Specification and Deployment View.
The infrastructure services represent computing, networking, and storage services. In the current ScaleDL Overview version, networking services are not yet defined, and the connection between them is indirectly defined through dependencies between platform services. However the bandwidth available at the deployed services is specified through network interface properties, defined in virtual machine descriptors and the cloud environment specification.
The platform services offer a complete set of features (e.g. database, application server, etc.) composing the system development stack for a particular application. Platform services can be used as an execution environment for application services or as a support services offering complete solution made available for use by the application services, therefore the ScaleDL Overview splits these services into two groups: RuntimePlatformServices and SupportServices. The first contains a RuntimeContainer, available for deploying software services and the second represents the complete solution with its defined interfaces, through which software services make use of their capabilities.
The software services represent services offering functionality to the external environment or to another software services through exposed interfaces.
Services on the platform and software layersusually depend on services available in lower layers, however the exact information is not always known, and is it not required from the system point of view. Therefore the ScaleDL Overview divides those services into externally deployed services (i.e. ProvidedServices), which represents services that either are provided by the cloud provider or are available as a software-as-a-service, and system services, which are part of the system and were manually configured, deployed or developed by a system engineer. The externally deployed services (software or platform services) act as black boxes for which the deployment information is unknown to the system, and the performance of the system can be only predicted through measurements and/or service level objectives (SLO). The deployment information of the system services is known, therefore the performance can be analysed based on the performance of the lower layer services. Layers bellow infrastructure layer (e.g. virtualization and hardware layer) are not described in ScaleDL Overview, therefor infrastructure services are configured through RuntimeDeployment, which describescomputing environment (e.g. virtual machines) and various deployable configurations available in the cloud: clustered and scalable computing environment, load balancing and scalability management.
Figure 1: Cloud layers, services, deployment and usage overview
Although there are several possible connections between services (e.g. between services on the same layer, connections between software and support services), the ScaleDL Overview only defines connection between operation interface containers; software and support platform services. The ScaleDL Overview distinguishes between 2 types of connections; Internal andExternal. The Internal type is used for connecting platform services inside the same cloud environment, where the specifics (throughput, latency) are defined by the CloudEnvironment specification. The External type on the other hand, is used to connect components from different CloudEnvironment, representing the tunnel between two different cloud environments andconnections running from or into the system with use of proxy entities (i.e. calls to external services, or to represent entrant connections). Connection between services is prerequisite for defining which operation interfaces are required by services; only operation interfaces provided by connected services can be used by a specific service. The ScaleDL Overview definition currently does not infer connections between infrastructure layers that are indirectly defined through platform service connections if they are deployed on different infrastructure services.
For the purpose of connectivity with external environments, UsageProxyis introduced into the model, which function as an operation provider (UsageProxy) by defining the incoming external connections (and will contain anUsageModel in future ScaleDL Overview versions).
For connectivity with external software services while ServiceProxy represents the connections to the external software and platform services that are not part of the system or cloud environment, and function under a completely black-box paradigm. The distinction with the cloud provided services (e.g. Database As A Service) is that those services will be usually pre specified with their own performances, capabilities and SLOs; through the Specification view, while the specification of external services will be normally left to the users.
1.2Quick Example
For quick overview of the ScaleDL Overview following example will briefly introduce main model elements, how are connected between each other and how to use them on a real-life system. The model represents CloudStore ( a hypothetical cloud-based shopping service, deployed on the Amazon Web Services cloud. System is composed of 4 main components; web server, database server, storage server and external payment service. Web server is deployed on EC2 in auto scalability group, database and storage are provided by Dynamo and S3 support platform services, respectively. For external payment gateway we use PayPal application service.
- Architecture
- Application definition
- Specification
- Deployment
2Concepts
In the following section the main concepts of ScaleDL Overview will be described. In addition to modelling cloud based systems ScaleDL Overview also provides the ability to enhance elements’ specifications through cloud and service specifications; defined in separate model, which can be used in describing the modelled system.
At the time of writing this document, the ScaleDL Overview is still in development, therefore some features are not yet available, yet they are defined in this document. Currently the main missing part is the definition of external services’ behaviour and performance (i.e. SLO model), and the specifications for related costs (i.e. Price model), which will be defined in the last year of the CloudScale project.
2
2.1ScaleDL Overview views
Steps needed to completely define a system in the ScaleDL Overview are: creating system architecture, defining application view, specifying system services and defining services deployment. Therefore the system model is defined through 4 views: Architectural, Application, Specification and Deployment. Architectural view is a base view on which all other three depends on. It defines services, dependencies between them and cloud environments, while other three acts on a specific service, providing neccessery information to fully describe them and system as a whole.
Figure 2 : ScaleDL Overview views
Figure 2 shows the ScaleDL Overview model with consisting views and dependencies between each other. Each view will be described in the detail in following sections.
2.2Architectureview
The main part of the ScaleDL Overview is Architecture View, used to model cloud based systems with abstract elements without providing them with actual specification or deployment. It is responsible to describe basic system elements, their dependencies and roles.
The base component in the Architecture View is a CloudEnvironment, an abstract representation of cloud environment, in which the modelled system or part of it is deployed. The architecture can consists of more than one cloud environments and thus enabling possibility of modelling hybrid cloud solutions. With use of specification view, the cloud environment can be specified to provide infrastructure as a service (IaaS) or platform as a service (PaaS). For the first specifications hold the description of infrastructure resources while for the latter, it contains list of available services; however the specification can also describe a combination of those two (e.g. Amazon Web Services provides EC2 infrastructure and several platform services).
Figure 3: Usage of Platform and Infrastructure services
Figure 3 shows three different cloud configurations; first a typical IaaS provider with a PlatformService deployed on the available ComputingInfrastructureService; secondly a PaaS provider with aProvidedPlatformService component; and finally an IaaS provider with additional provided services. The ScaleDL Overview enables modelling of all of them.
In the following sections basic architecture elements are described in detail: Layers, Services, Connections and Proxies.
2.2.1Layers
The approach taken to model cloud based systems follows the categorization of cloud computing layers: Infrastructure layer, Platform layer and Software layer. Each layer consists of specific services, which are generalized in the ScaleDL Overview to enable modelling system architecture in an abstract way.
Figure 4: Architecture model layers
Figure 4 shows the architecture of a sample application deployed in the cloud environment from the perspective of the cloud layers, and their deployment and usage dependencies.
The CloudEnvironment consists of cloud layers, each providing services used by the modelled system:
●InfrastructureLayer: The infrastructure layer consists of infrastructure services (InfrastructureService) offering compute and storage capacity within the cloud environment. The layer itself is based on the virtualization and hardware layers, which are transparent to the cloud based systems, and therefore they are not included into the ScaleDL Overview.
●PlatformLayer: The platform layer consists of platform services (PlatformService) that represent the technology stack used by the developed software. It consists of services responsible for running software services and services that supports them with specific functionalities (e.g. databases).
●SoftwareLayer: The software layer consists of application services (SoftwareService), both internally produced and deployed or externally available, on which system application depends.
2.2.2Services
Services represent abstract building blocks of modelled system, defined in each layer: infrastructure, platform and software. Dependencies between them define the system architecture. In ScaleDL Overview we distinguish two dependencies; vertical and horizontal dependency. Vertical or deployment dependency defines, which service (if any) on lower layer is responsible to run specific service. For services provided by 3rd parties (e.g. cloud environment, SaaS), for which the deployment information is not known or is not in interest of system architect, ScaleDL Overview defines them as provided with special deployment elements (see Error! Reference source not found.). These provide SLOs and computing environments (in case of computing infrastructure services and runtime platform services; see below).These services are: InfrastructureServices (see 1.4.2.1),ProvidedPlatformRuntimeService, ProvidedPlatformSupportService (see 1.4.2.2), ProvidedSoftwareService and ExternalSoftwareService (see 1.4.2.3). Horizontal dependency is defined through use of Connections (see 1.4.4) between two operation interface containers; software and support platform services. ScaleDL Overview does not provide special elements for defining horizontal dependencies between infrastructure services. Nevertheless those are indirectly defined by the Connections in upper layer (i.e. platform layer); through connections between platform services that are not deployed on the same infrastructure service.
2.2.2.1Infrastructure services
The infrastructure services (InfrastructureService) represent compute, storage and network resources available in a specific IaaS cloud environment. In the current ScaleDL Overview version only computing services are supported:
●ComputingInfrastructureService: The computing infrastructure service represents services provided by specific IaaS. Through deployment configuration, one can configure which computing resource (i.e. instances) to used (normally more are available), how the service will scale (scaling policies), how the load are distributed between the resources (scheduling policies) and initial, minimum and maximum size of the cluster; minimum and maximum are defined in scalable deployments.
Infrastructure services are always provided (provided by 3rd party), therefor it requires ServiceDeployment (see ..), with defined SLA and SLO. Additionally ComputingInfrastructureService requires ComputingEnvironmentDeployment, with which it is possible to configure (considering specification) clustered and scalable computing environments (see1.7).
2.2.2.2Platformservices
The platform services are grouped into two main groups: deployable and provided platform services. First represents services for which we need to define on which infrastructure service it is deployed, while for the provided services this information is unknown to the modelled system and thus cannot be defined. The behaviour of those services is normally measured experimentally and/or defined through SLAs. The deployable platform services can be used only in IaaS clouds, since they provide infrastructure on which those components can be deployed. The provided platform services on the other hand are available in PaaS environments. Some cloud environmentsalso provides some kind of wizards for deploying platform services on the infrastructure (e.g. Amazon RDS and BeanStalk), which ScaleDL Overview defines as provided platform services specified with infrastructure descriptor on which runtime deployment must be defined (see 1.6).
Beside deployment information, platform services are also grouped by their ability to provide execution environment for software services (e.g. application servers) and the ability to support software services with specific features (e.g. databases). The support services thus provide interfaces used by softwareservices, while the runtime services provide runtime container into which we can deploy softwareservices.
Figure 5: PlatformService class hierarchy
Figure 5 shows the class hierarchy derived from platform services. Below is detailed description of all leaf classes: