Difference between revisions of "VT-CloudCaps:Capacities"

From EGIWiki
Jump to: navigation, search
Line 1: Line 1:
This page will gather various capacities that we identified as being useful for use cases. The EGI virtualized infrastructure will not be able to provide all of the capacities initially. However, given sufficient demand, they may eventually be implemented.<br>
+
This page will gather various capacities that we identified as being useful for use cases. The EGI virtualized infrastructure will not be able to provide all of the capacities initially. However, given sufficient demand, they may eventually be implemented.<br>  
  
 
{| cellspacing="1" cellpadding="1" border="1" style="width: 1011px; height: 970px;"
 
{| cellspacing="1" cellpadding="1" border="1" style="width: 1011px; height: 970px;"
Line 6: Line 6:
 
! scope="col" | Capacity  
 
! scope="col" | Capacity  
 
! scope="col" | Description  
 
! scope="col" | Description  
! scope="col" | Accounting
+
! scope="col" | Accounting  
 
! scope="col" | Technical solution(s)
 
! scope="col" | Technical solution(s)
 
|-
 
|-
Line 16: Line 16:
 
The benefit of block storage over object storage is that the application within the virtual instance does not need to be aware of it. With block storage appearing to the VM as just another block device, from which an ordinary file system can be mounted, applications will be able to deal with this kind of storage transparently.<br>  
 
The benefit of block storage over object storage is that the application within the virtual instance does not need to be aware of it. With block storage appearing to the VM as just another block device, from which an ordinary file system can be mounted, applications will be able to deal with this kind of storage transparently.<br>  
  
| OpenStack provides Disk GB&nbsp;hours. Storage Accounting Record (StAR) potentially usable here.
+
| OpenStack provides Disk GB&nbsp;hours. Storage Accounting Record (StAR) potentially usable here.  
 
|  
 
|  
Offered by the following Cloud stacks within EGI&nbsp;FCTF:
+
Offered by the following Cloud stacks within EGI&nbsp;FCTF:  
  
*OpenStack
+
*OpenStack  
*OpenNebula
+
*OpenNebula  
*StratusLab
+
*StratusLab  
 
*WNoDeS supports this with restrictions: only administrators can add extra block storage. It is a planned feature to allow users to do that.
 
*WNoDeS supports this with restrictions: only administrators can add extra block storage. It is a planned feature to allow users to do that.
  
Line 33: Line 33:
 
Applications within virtual instances need to make explicit use of object storage in order to make use of it. This is a key difference in comparison to block storage. A potential solution to overcome this limitation is to try and mount object storage as a file system, e.g. via a FUSE&nbsp;driver. There are hints that such solutions exist.<br>  
 
Applications within virtual instances need to make explicit use of object storage in order to make use of it. This is a key difference in comparison to block storage. A potential solution to overcome this limitation is to try and mount object storage as a file system, e.g. via a FUSE&nbsp;driver. There are hints that such solutions exist.<br>  
  
| Yes (StAR?), actual metrics need to be defined.
+
| Yes (StAR?), actual metrics need to be defined.  
 
|  
 
|  
*OpenStack Swift
+
*OpenStack Swift  
 
*CDMI proxies
 
*CDMI proxies
  
Line 49: Line 49:
 
Examples of this kind of system are:&nbsp;Amazon SQS <ref>http://aws.amazon.com/sqs/</ref>  
 
Examples of this kind of system are:&nbsp;Amazon SQS <ref>http://aws.amazon.com/sqs/</ref>  
  
| Yes, number of messages, maybe their size. SQS accounts number of sends and receives separately. Bulk send/receive cheaper.
+
| Yes, number of messages, maybe their size. SQS accounts number of sends and receives separately. Bulk send/receive cheaper.  
 
|  
 
|  
AMQP
+
AMQP  
  
*ActiveMQ
+
*ActiveMQ  
 
*RabbitMQ
 
*RabbitMQ
  
Need to be careful with AMQP&nbsp;protocol versions, 0.9.1 seems entirely different from 1.0. ActiveMQ support 1.0, RabbitMQ 0.9.1 (and will stick to it).
+
Need to be careful with AMQP&nbsp;protocol versions, 0.9.1 seems entirely different from 1.0. ActiveMQ support 1.0, RabbitMQ 0.9.1 (and will stick to it).  
  
 
|-
 
|-
Line 65: Line 65:
  
 
|  
 
|  
|  
+
| There's currently (Apr 2013) a new development in OpenStack<ref>https://wiki.openstack.org/wiki/Heat</ref> that is supposed to implement CloudFormation.
 
|-
 
|-
 
! scope="row" | 5  
 
! scope="row" | 5  
Line 82: Line 82:
 
Databases as a service, be it SQL&nbsp;or no-SQL.<br>  
 
Databases as a service, be it SQL&nbsp;or no-SQL.<br>  
  
| Based on number of requests and size of DB.
+
| Based on number of requests and size of DB.  
 
|  
 
|  
 
|-
 
|-

Revision as of 16:38, 15 April 2013

This page will gather various capacities that we identified as being useful for use cases. The EGI virtualized infrastructure will not be able to provide all of the capacities initially. However, given sufficient demand, they may eventually be implemented.

Id Capacity Description Accounting Technical solution(s)
1 Block Storage

Block storage can be attached to virtual instances at run time. Some cloud stacks even require the use of explicitly attached block storage to make any use of the instances at all.

The benefit of block storage over object storage is that the application within the virtual instance does not need to be aware of it. With block storage appearing to the VM as just another block device, from which an ordinary file system can be mounted, applications will be able to deal with this kind of storage transparently.

OpenStack provides Disk GB hours. Storage Accounting Record (StAR) potentially usable here.

Offered by the following Cloud stacks within EGI FCTF:

  • OpenStack
  • OpenNebula
  • StratusLab
  • WNoDeS supports this with restrictions: only administrators can add extra block storage. It is a planned feature to allow users to do that.
2 Object Storage

Object storage is scalable storage in which data objects can be stored. The FCTF have agreed on CDMI to be the access mechanism of choice.

Applications within virtual instances need to make explicit use of object storage in order to make use of it. This is a key difference in comparison to block storage. A potential solution to overcome this limitation is to try and mount object storage as a file system, e.g. via a FUSE driver. There are hints that such solutions exist.

Yes (StAR?), actual metrics need to be defined.
  • OpenStack Swift
  • CDMI proxies
3 Messaging

A messaging system can be used to decouple communication among distributed components of cloud "applications". At the same time, this capacity can be used at the infrastructure level. Messaging is a higher level service, which can be offered/used in several modes of operation:

  1. Directly within a VM, either a specific one deployed by the user or as part of a larger VM containing multiple components and services
  2. As a platform service offered by the cloud. Users could simply rely on its availability and make use of it.

Examples of this kind of system are: Amazon SQS [1]

Yes, number of messages, maybe their size. SQS accounts number of sends and receives separately. Bulk send/receive cheaper.

AMQP

  • ActiveMQ
  • RabbitMQ

Need to be careful with AMQP protocol versions, 0.9.1 seems entirely different from 1.0. ActiveMQ support 1.0, RabbitMQ 0.9.1 (and will stick to it).

4 CloudFormation

CloudFormation is the capacity to deploy collections of related resources.

There's currently (Apr 2013) a new development in OpenStack[2] that is supposed to implement CloudFormation.
5 AutoScaling

Many applications can benefit from automatic scaling either horizontally or vertically. We refert to vertical scaling as the resizing of existing cloud instances, whereas horizontal scaling means adding or removing instances on demand.

AutoScaling can be supported by additional service such as rule engines and messaging services to provide the data and decisions for scaling.

6 Database

Databases as a service, be it SQL or no-SQL.

Based on number of requests and size of DB.
7
8
9
10