Minio as Eucalyptus ObjectStorage backend

Minio, the new cloud storage written in Go that let’s you store any data as objects also has another great feature, it’s AWS S3 compatible and that makes Minio really useful with Eucalyptus.

Eucalyptus supports multiple ObjectStorage backends, Riak CS (Cloud Storage), Ceph RGW and Eucalyptus already comes with S3 compatible Walrus. Eucalyptus ObjectStorage service acts as a gateway for the backends. Eucalyptus still handles all the AWS compatible Identity and Access Management stuffs. As Minio is compatible with AWS S3, we can actually use it with Eucalyptus as well. However, even though it is possible to use any object storage backend that is compatible with AWS S3, they are not supported unless specified otherwise on the Eucalyptus website/documentation.

The first step would be to start a Minio server.

Deploying a basic Minio server is super simple. For this demo I have used an Eucalyptus instance (virtual machine) running Ubuntu 16.04.1 LTS (Xenial Xerus).

$ wget https://dl.minio.io/server/minio/release/linux-amd64/minio
$ chmod +x minio
$ ./minio server ~/MinioBackend

We should see a super helpful output like below,

Endpoint:  http://172.31.21.31:9000  http://127.0.0.1:9000
AccessKey: GFQX5XMP1DSTIQ8JKRXN
SecretKey: aFLQegoeIgzF/hK+Xymba7JwSANfn98ANNcKXz+S
Region:    us-east-1
SqsARNs:

Browser Access:
   http://172.31.21.31:9000  http://127.0.0.1:9000

Command-line Access: https://docs.minio.io/docs/minio-client-quickstart-guide
   $ mc config host add myminio http://172.31.21.31:9000 GFQX5XMP1DSTIQ8JKRXN aFLQegoeIgzF/hK+Xymba7JwSANfn98ANNcKXz+S

Object API (Amazon S3 compatible):
   Go:         https://docs.minio.io/docs/golang-client-quickstart-guide
   Java:       https://docs.minio.io/docs/java-client-quickstart-guide
   Python:     https://docs.minio.io/docs/python-client-quickstart-guide
   JavaScript: https://docs.minio.io/docs/javascript-client-quickstart-guide

Minio also comes with a helpful web UI which can be accessible once we have Minio running.

Next step would be to see how we can add a new provider client in Eucalyptus. It is definitely easier that it sounds 🙂

If we try to reset the value for ObjectStorage it should show us the available supported objectstorage S3 provider clients or these values are also available in the cloud-output.log where user-facing services are running,

# euctl -r objectstorage.providerclient
euctl: error (ModifyPropertyValueType): Cannot modify \
objectstorage.providerclient.providerclient new value \
is not a valid value.  Legal values are: walrus,ceph-rgw,riakcs

So, now we have to add another provider client for Minio. Technically, we can probably use riakcs, if you have deployed Eucalyptus with packages, but I am not gonna do that in this case, since I already have source build cloud.

This post assumes that you know how to build Eucalyptus from source and doesn’t go into much detail. The purpose of this post is to show how to add a third-party object storage like Minio with Eucalyptus. But again, feel free to use package installation and use riakcs as provider client, use the Minio’s endpoint and user credentials as described below.

To add minio as a provider client, first we need to create a file called MinioProviderClient.java,

Build and install all of eucalyptus source or just build the jars.

Stop eucalyptus-cloud service and copy eucalyptus-object-storage-4.4.0.jar to /usr/share/eucalyptus directory where user-facing services are running. Restart eucalyptus-cloud service.

If everything goes well, when the services are enabled, we can now check if the supported object storage providers again.

# euctl -r objectstorage.providerclient
euctl: error (ModifyPropertyValueType): Cannot modify \
objectstorage.providerclient.providerclient new value \
is not a valid value.  Legal values are: walrus,ceph-rgw,minio,riakcs

Looks like minio is now one of the supported provider client for Eucalyptus object storage. That was easy! 🙂

At this point we should be able to set minio as a provider client for Eucalyptus object storage.

# euctl objectstorage.providerclient=minio
objectstorage.providerclient = minio

Now configure Eucalyptus ObjectStorage service to use our Minio deployment endpoint (public IP address/hostname) and credentials,

# euctl objectstorage.s3provider.s3endpoint=10.116.159.114:9000
# euctl objectstorage.s3provider.s3accesskey=GFQX5XMP1DSTIQ8JKRXN
# euctl objectstorage.s3provider.s3secretkey=aFLQegoeIgzF/hK+Xymba7JwSANfn98ANNcKXz+S

Eucalyptus ObjectStorage gateway does a connectivity check with the provided S3 endpoint to enable the objectstorage service of Eucalyptus. Basically it expects a HTTP response code for HEAD operation on S3 endpoint, which can be configured based on the backend, as different backend can send different response code. Apparently Minio returns 404 on it’s endpoint. So, to make it work, we need to set the value to 404 (feels weird though).

# euctl objectstorage.s3provider.s3endpointheadresponse=404

Within a few seconds we should see the object storage is enabled. We can run the following to check the service status of object storage,

# euserv-describe-services --filter service-type=objectstorage

Now we can use Minio as an object storage backend. However, while working, I found an issue where any PUT object request that was made through Eucalyptus ends up with a failure. After debugging with Swathi Gangisetty it looks like the AWS Java SDK Eucalyptus using doesn’t like the fact that Minio is returning Etag instead of ETag as it is mentioned in the AWS Documentation. To test, we removed Eucalyptus out of the picture and tried to upload an object directly with AWS Java SDK 1.7.1, which also failed in the same way. However, the same upload request works with AWS Java SDK 1.10.x.
So, to use Minio successfully as an Eucalyptus ObjectStorage backend, we either need a fix in Minio where it returns the correct ETag or when Eucalyptus starts using a newer AWS Java SDK in a future release.

Here are the requests for the fix in Minio: https://github.com/minio/minio/issues/3284
and for the AWS Java SDK update in Eucalyptus: https://eucalyptus.atlassian.net/browse/EUCA-12955

Update:
Looks like this was a bug in AWS Java SDK 1.7.1 and fixed in a later release,
https://github.com/aws/aws-sdk-java/pull/590

Advertisements

Using AWS CodeDeploy with Eucalyptus Cloudformation for On-Premise Application Deployments

More Mind Spew-age from Harold Spencer Jr.

Background

Recently, Amazon Web Services (AWS) announced that their CodeDeploy service supports on-premise instances.  This is extremely valuable – especially for developers and administrators to allow utilization of existing on-premise resources.

For teams who are using HP Helion Eucalyptus 4.1 (or who want to use Eucalyptus), this is even better news.  This feature – along with HP Helion Eucalyptus 4.1 Cloudformation – developers can deploy applications within a private cloud environment of HP Helion Eucalyptus.  This makes it even easier for developers and administrators to separate out and maintain production (AWS) versus development (HP Helion Eucalyptus) environments (or vice versa).  In addition, since HP Helion Eucalyptus strives for AWS compatibility, the Cloudformation templates used on Eucalyptus, can be used with AWS – with just a couple of modifications.

The Setup

To leverage on-premise instances with AWS CodeDeploy, please reference the AWS documentation entitled “Configure Existing On-Premises Instances…

View original post 798 more words

Eucalyptus 4.0 OSG Bucket ACLs and Object Lifecycle Management using Python Boto and s3cmd

More Mind Spew-age from Harold Spencer Jr.

Introduction

My last few blogs have discussed how Eucalyptus 4.0 supports similar Amazon Web Services, such as Elastic Compute Cloud (EC2), Simple Storage Services (S3), Elastic Load Balancing (ELB) and Security Token Services (STS) features. Using third party tools, such as python boto and s3cmd, features such as listing buckets and objects, listing running instances and assuming IAM roles were covered.  This blog entry is yet another example as to how Eucalyptus provides AWS compatible features in a private, on-premise cloud environment.

A couple of little known AWS-like features provided by the Eucalyptus 4.0.x Object Storage Gateway (OSG) that are barely discussed are the following:

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…

View original post 1,671 more words

James Iry’s history of programming languages (illustrated with pictures and large fonts)

The Quick Word

jacquardAda LovelaceAlan Turing04-church05-bartik06-backus07-mccarthy08-hopper09-kemeney-kutz10-steele11-wirth12-ritchie-thompson13-colmerauer14-milner15-kay16-ichbah17-stroustrup18-cox19-wall20-haskell21-rossum22-lerdorf23-hansson24-eich25-gosling26-hejlsberg26-odersky

–This post is a tribute to James Iry’s fantastic One Div Zero blog.

View original post

Choose Your Own Adventure: Which Eucalyptus UI is Right for You?

UX Doctor

Open source projects can often lead to an embarrassment of riches that can really be confusing. This is especially true when it comes to tools you can use to interact with your Eucalyptus cloud.

Options include CLIs, SDKs, and different graphical user interfaces. Each has advantages and disadvantages, strengths and weaknesses, and is targeted to a specific kind of person.

Depending on what you want to do, your level of cloud knowledge, and the kind of user experience you desire, there is a Eucalyptus UI that will fit you perfectly. Let’s take a quick look at each and then you can Choose Your Own Adventure to help you find your ideal fit.

EUCALYPTUS USER CONSOLE

Eucalyptus User Console Dashboard

The Eucalyptus User Console is an open source project with development primarily done internally by Eucalyptus employees. We wanted to give our customers a graphical user interface for self-service deployment of virtual machines on Eucalyptus…

View original post 747 more words

Eucalyptus and Nagios

nurmiblog

Production deployments of Eucalyptus, like production deployments of any infrastructure software running in a data center, require some amount of health and status monitoring be happening in order to both allow the Eucalyptus/data-center administrator the ability to stay on top of evolving resource situations and to provide invaluable diagnostic information when something is going sideways within the resource pool.  Fortunately for all of us, there exists a wide variety of health/status monitoring system out there, and several of them are of extremely high quality, tried and tested, and are available as part of major Linux distributions as pre-packaged open-source solutions.  One such system that I’m a personal fan of is called Nagios.

To quote from their website:

“Nagios is a powerful monitoring system that enables organizations to identify and resolve IT infrastructure problems before they affect critical business processes.”

Indeed it is!  I first used Nagios is 2000/2001…

View original post 1,182 more words

Finally Eucalyptus 3.1 is on Github.

Greg DeKoenigsberg Speaks

It’s taken a while, but the move is complete.  The source code for Eucalyptus 3.1 Beta is open and publicly available in Github.  It’s actually been there for a while now, but we’ve done enough housekeeping and we’re ready to open the doors.

Build instructions can be found in the INSTALL file, but they are still in flux; comments and patches are welcome.  Don’t hesitate to join us on #eucalyptus on freenode or on our community mailing list if you have questions.

Packages for the beta will be available for various distros in the coming days.  Special props go to Debian Partner company Credativ for their impressive work on the Google Web Toolkit libraries.

We’re also working on our new bug tracker; we’re in private beta to work through various auth and workflow kinks.  If you’re interested, ask for access on IRC or the mailing list, and we will…

View original post 51 more words