Both of these features help cloud users implement cross-account bucket and object access, and define how long an object lives in a bucket. Keeping consistent with the earlier blog entries and continuing to promote…
Embracing open source technology is not something new to us and here at Eucalyptus we practice this everyday. In Eucalyptus 4.1.0, we chose this beautiful commodity storage technology Ceph for our Block Storage Service. yay! While the product is under heavy development, I am happy to give update about how Ceph can be used as a block storage backend for Eucalyptus Storage Controller (SC).
First thing first, so to use Ceph as a block storage manager, we need a basic Ceph cluster deployed. Apart from having several automation technologies to deploy Ceph, it also has a beautiful tool called ceph-deploy. We found it really pleasing while deploying Ceph clusters with ceph-deploy. But as our requirement is to be able to deploy Ceph clusters of different sizes on-demand for testing ceph+eucalyptus setup, so we needed some automation for this. After giving some thought about our use case, we decided to take the a newer path which would be easily maintainable for us. So, we decided to write a small chef cookbook to deploy a Ceph cluster with ceph-deploy, fun isn’t it? 😉
For those who want to take a quick taste of Eucalyptus and Ceph at it’s early phase here is how you do it:
To deploy using ceph-cookbook which uses ceph-deploy,
To add Ceph cluster as block storage backend for Eucalyptus, we will need a newer kernel with RBD module support and Ceph installed on the Eucalyptus Storage Controller (SC). For this demo we will use the LT kernel from ELRepo.
At this point your Eucalyptus Storage Controller should be ready to be used with Ceph as a storage backend!
Now test your Eucalyptus SC with Ceph RBD by creating volumes and snapshots.
To check the ongoing events on your Ceph cluster, run `ceph -w` on the Monitor node.
Happy Cephing with Eucalyptus!
Even though it’s under heavy development, we will love to hear your experience with Ceph+Eucalyptus.
Join us at #eucalyptus on Freenode.
Update: My colleague and good friend Swathi Gangisetty pointed out that for Eucalyptus Storage Controller to be operational no newer kernel is required. Currently, for librbd, SC interacts with Ceph via JNA bindings that are packaged as jar and comes with Eucalyptus.
This post demonstrates Hadoop deployment on Eucalyptus using Apache Ambari on Horton Data Platform stack. Bits and pieces:
Hortonworks Data Platform (HDP) stack
4 instance-store/EBS-backed instances
2 vcpus, 1024MB memory, 20GB disk space
CentOS 6.5 base image
For this is demo we tried to use very minimum resources. Our Eucalyptus deployment topology looks like below, 1x (Cloud Controller + Walrus + Storage Controller + Cluster Controller) 1x (Node Controller + Object Storage Gateway) To meet our instance requirement, we changed the instance-type according to our need.
Preparation Run an instance of m1.xlarge or any other instance type that meets the above requirement. When the instance is running copy the keypair that is used to run this instance at .ssh/id_rsa, we will be using this same keypair for all the instances.
Eucalyptus 4.0 is one of the biggest releases in Eucalyptus history with several major architectural changes. Lots of new re-engineered components and some behavioral changes have landed with this new release.
Major changes in Eucalyptus 4.0
This is the biggest one and probably the one many of us were waiting for a long time. From 4.0 CLC DB and user-facing services can be installed/registered in different hosts. With that said, now it is also possible to have multiple user-facing services (UFS).
SERVICE user-api API_110 API_110 ENABLED 45 http://10.111.1.110:8773/services/User-API arn:euca:bootstrap:API_110:user-api:API_110/
SERVICE user-api API_112 API_112 ENABLED 45 http://10.111.1.112:8773/services/User-API arn:euca:bootstrap:API_112:user-api:API_112/
SERVICE user-api API_119 API_119 ENABLED 45 http://10.111.1.119:8773/services/User-API arn:euca:bootstrap:API_119:user-api:API_119/
SERVICE user-api API_179 API_179 ENABLED 45 http://10.111.1.179:8773/services/User-API arn:euca:bootstrap:API_179:user-api:API_179/
Object Storage Gateway (OSG)
Another attractive feature in Eucalyptus 4.0. With this new service, it is possible to use different object storage backends. For now OSG has complete support for RiakCS and WalrusBackend as object storage backends. Other object storages like Ceph should be pluggable as well with OSG, but is not fully tested.
More about Object Storage Gateway and RiakCS were discussed in previousposts.
This is another great addition to Eucalyptus. Now image management was never been so fun than this. One important thing is, from 4.0 Eustore has been replaced with couple of other interesting commands in the toolset.
EDGE is a new networking mode which was introduced in 3.4 as a tech-preview feature. The main reason behind this networking mode is to remove the need of Cluster Controller to be in the data for all the running VMs. Also, this helps to eradicate the need of tagging VLAN packets to achieve Layer 2 isolation between the VMs. With this network mode, now there will be a new standalone component called eucanetd will be running on the Node Controller. In EDGE networking mode eucanetd running on the Node Controller maintains the networking and ensures any single point of failure.
Re-engineered Eucalyptus Console
This is one of the biggest changes that happened in 4.0. We said goodbye to the Eucalyptus Admin UI (https://<CLC_IP_address>:8443), Eucalyptus User Console and welcomed the newly designed EucaConsole with the administrative features.
Tech-Preview of CloudFormation
CloudFormation!!! Yes, CloudFormation feature has been implemented and released in Eucalyptus 4.0 as a tech-preview, though the implementation is pretty well.
In the currently implementation of CloudFormation, the service does not come with other user-facing services, it needs to be registered separately on the same host with CLC/DB (EUCA-9505).
Apart from those, another big improvement was with Administrative Roles. There are now pre-defined roles for Eucalyptus admin account, e.g Cloud Account Admin, Cloud Resource Admin, Infrastructure Admin. ELB supports session stickiness, modify attributes of instances is supported and so on. Also many AWS compatibility issues have been fixed in this Fantastic release.
Installing Eucalyptus is now easier than ever. You can start with a CentOS 6.5 minimal server and get your own Amazon compatible Eucalyptus cloud.
To get started run the following command and have your own private cloud up and running,
In the last post, we have installed Riak CS on a single node. For production, a deployment of five or more nodes is required for better performance, reliability. Riak has a default three times data replication mechanism and in smaller deployment the replication requirement may not be met properly and also it may compromise the fault-tolerance ability of the cluster. Fewer nodes will have higher workloads.
According to the documentation:
If you have 3 nodes, and require all 3 to replicate, 100% of your nodes will respond to a single request. If you have 5, only 60% need respond.
In this post, we will use 5 nodes to create a Riak cluster for our Eucalyptus setup. Since we will be using Riak CS, we will be installing Riak CS in each node. We will also need a Stanchion server.
Overall, our setup will look like below:
a) 5x Riak nodes
b) 5x Riak CS nodes (one in each Riak node)
c) 1x Stanchion node
d) 1x Riak Control
e) 1x Riak CS Control
f) 1x Nginx server for load balancing between the Riak CS nodes
First we will install Riak, Riak CS on all the nodes,