Abiquo 2.2 – New Abiquo KVM node with Centos6

As you would know, Abiquo is distributed in a CentOS 5.7 ISO image with all the components included. And when the users are installing the product, they can select the profile to install (Monolithic install, Distributed install, KVM Cloud node, etc.).

In order to continue the evolution of our ISO, we are preparing the migration to the newest CentOS 6 distribution.

In order to perform this migration gradually, and because KVM is one of the most important hypervisors used in Abiquo in our customers’ production environments, we have decided to start with the migration of the KVM Cloud node profile so as to provide the benefits of using the new KVM version included in CentOS 6.

For example, in CentOS 6, the new KVM version is now fully integrated into the kernel. Other improvements include the ability to assign CPU affinity for guests, and Kernel Same Page (KSM) technology, which allows the kernel to reuse identical memory pages across virtual machines. That’s certainly very useful for a cloud environment 🙂

Abiquo will continue to provide our ISO based on CentOS 5.7 but we have also prepared a special package that can be installed after a basic CentOS 6.2 install, for customers that wish to use KVM. It includes all the packages required for running KVM and all the components necessary to work with Abiquo (libvirt, abiquo-aim, etc.).

Step back to the cloud

I’m Steve Rushen, Sr. Director, Services and Support at Abiquo. Over the next few weeks I want to use this blog to share some of the experience that I’ve gained during the last two years at Abiquo, helping our customers to create award winning cloud services.

As an introduction I want to define what companies need from a cloud service.  It may sound obvious, but some companies rarely think about what they want their ‘cloud’ to do and tend to jump straight into a service without thinking of the business’ needs and requirements. I’ve seen many organisations run trials with one product after another, while they explore the cloud market. They are simply treading water and delaying the launch of any service while they try to understand what it is they want. This can build an ever-increasing list of requirements that makes projects delayed, or even doomed to failure, before they have even started.

Before companies run at full speed towards the cloud they should take a step back and think about what is required from the service. Organisations need to think about the essential characteristics of the cloud they want to build. NIST lists these as; on-demand self- service, broad network access, resource pooling, rapid elasticity and a measured service. For some businesses this isn’t going to be a complete list but it’s a great starting point for most.

Once the broad list of characteristics is complete, and with the knowledge of the business environment (i.e. the hardware, storage, networking and hypervisors that will define the service), companies will be ready to start building a list of requirements. That list of requirements is what should shape any discussion that is had with hardware and software vendors that are ready to talk cloud; without it the vendor be working to their own agenda without the customer in mind. If businesses are serious about creating cloud services then a little bit of upfront work will help define success. When choosing a cloud service many customers forget or are unaware about checking their cloud’s compatibility. Organisations need to identify cloud vendors that won’t be constrained by the hardware or the hypervisors that they are either using today or in the future.

If you’re a business that already has that list of requirements and wants to see what Abiquo can do, then get in touch. I’m always happy to have that conversation.

Abiquo 2.2 – Database accounting improvements

As you would know, Abiquo has the capacity to account any resource allocated and used by users in order to allow cloud providers to generate bills using their billing systems or using an Abiquo billing connector.

Accounting data is obviously one of the key parts of the product because it’s valuable data that tells Abiquo customers exactly how their users are consuming cloud resources in the platform.

As in other parts of the product, the engineering team are using information received from customers and labs in order to improve scalability. And accounting is a critical part of the platform because as the platform grows, the data generated keeps growing every hour/day/week, so the processes that consolidate the data need to have a very good response time.

In Abiquo EE 2.2 we have reviewed this processes and we have improved a lot the performance numbers measured in previous releases.

The following points sumarize the enhancements of this improvement:

• Improved security: separate ‘kinton_accounting’ schema to hold the new accounting tables and views so accounting queries do not access the main Abiquo schema
• Improved storage efficiency: saves 50-75% of space used by the pre-upgrade accounting table
• Improved VIEW performance: greatly improved query performance on large accounting tables
• Improved recovery handling: you can now recover missed accounting periods

This diagram is an overview of the Abiquo 2.0 accounting system. The accounting tables are part of the kinton schema.

After the upgrade to Abiquo 2.2, the accounting tables are now part of the kinton_accounting schema, as shown with the darker orange and green boxes in the following diagram.

After the upgrade, by default the system will retain accounting data for 90 days. You can manually recover missed accounting periods.

You should now access accounting data using the template queries in the new accounting schema.

Finally… I think that seeing a comparison is better than more words in this post.

Enjoy your bills! 😉

Abiquo 2.2 Nexenta Plugin

We are pleased to announce that our new Abiquo 2.2 release includes a new integration with Nexenta Storage. With this integration, the engineering team has resolved a long-term technical debt.

Abiquo’s external storage capabilities can be enabled in two different ways:

• The most common and recommended approach is to have a storage plugin for the Abiquo Storage System Manager that uses the target storage device’s management API to manage iSCSI volumes (block devices).
• The alternative is to use an Abiquo storage agent installed on the target storage device. This approach is used for devices that do not expose a management API, such as LVM. The Abiquo Storage Manager performs all operations against the storage agent.

When Abiquo began work on a storage plugin for Nexenta integration, we decided to adapt our OpenSolaris/ZFS agent to run on Nexenta. Meanwhile, the Nexenta team was preparing an API to fully manage their storage technology. So we then decided to do things better and refactor the existing storage integration to use the new REST API and thus avoid an extra component in the architecture between the Storage System Manager and the storage device.

This integration is now available in Abiquo 2.2, and it comes with a completely refactored and open source Storage Management interface (more about this in upcoming posts!).

Abiquo now supports Nexenta from version 3.0.3, but Nexenta Community versions prior to 3.1.3 may not work, because they do not ship with the iSCSI plugin, which is a basic requirement for the Abiquo external storage features.

Nexenta is based on ZFS technology and we feel it is a very good option for our customers because of its high performance capabilities in relation to its cost, so we will continue to support this product. And we hope you will be satisfied with the result!