One of the biggest I’ve been looking forward to us releasing is Affinity, and that day has finally arrived.

We already have an advanced scheduler inside Extility, ensuring that virtual machines are optimally placed considering the load of the overall platform.  However, load is not the only consideration for machine placement. Our new affinity system provides a flexible key-based multifactor placement algorithm. This enables licensees to control the placement of VMs based on a number of different factors, controlled both by the customer and by the licensee. Here are some use cases:

Licensing

For our customers who license certain software per physical CPU or server, it can make sense to restrict placement of VMs running certain image types to a given group of machines, to be most cost effective. The Microsoft Windows SPLA, for example, encourages this.

Redundancy

Customers running multiple webservers may want to ensure they are running on seperate physical servers, or in seperate physical racks, or even in completely different datacentres. Such servers can be configured by the customer to “repel” each other – we call this negative affinity. This is an example of a customer provided affinity.

Performance

In some ways the opposite use case of redundancy, some customers may want to ensure certain machines are clustered as close together as possible for performance (DB servers in the example below).  We call this positive affinity.

Privacy

Cloud multi-tenancy is an amazing thing, but for customers taking slow steps into the cloud, being able to offer a ‘private cloud of resources’ within the public cloud eases a significant burden in the journey to all the cloud has to offer.  Being able to allocate specific physical machines upon which only certain virtual machines can be launched delivers that.  This can also allow for better budgeting if the resources are more regulated.

Advanced Rules

We also appreciate there is circumstances where more than one of these rules could apply at the same time.  That’s why we’ve built Affinity into what we think is an industry leading technology.

Licensees and customers (to the extent permitted by the Licensee) can set a series of arbitrary rules and weightings against customers, images and virtual machines, allowing a combination of weightings to be used, and at the same time still delivering a truly on-demand self service offering. Multiple sets of rules can be set up at the same time and the Affinity system will automatically deal with them and allocate accordingly.

In Summary

So if you want to build a windows platform in a pseudo private cloud with negative affinity for webservers to each other but positive affinity to their backend databases, all on an on-demand reactive basis, now you can. (Oh, and a million other possible combinations as well of course!)

A diagram below shows the possibilities described above, the blue lines show segregation of physical machines to run Windows Virtual Machines, the black lines show segregation to a particular customers ‘private’ machines.

For simplicities sake this diagram only shows one or two virtual machines per physical one, but of course this could be much larger numbers depending on the specification of the physical machines:

Excuse me while I look down the back of the sofa for some IP addresses … OK, I’m back now, no IP addresses, but I did find 27p and an old dog chew.

Anyway, on a serious point, the solution to this problem is IPv6, which has been around forever in internet terms – since December 1995 in fact when RFC1883 was published.

IPv6 means that every man, women, dog and insect can have their own ip address (or block of IP address), because it uses a different numbering system to IPv4, allowing for far more addresses. IPv4 uses a 32 bit addressing system (theoretically allowing a miniscule maximum of 4,294,967,296 addresses, though in practice many are wasted), whereas IPv6 uses a 128 bit system, theoretically allowing for 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses, or very roughly one trillion per grain of sand on the earth (grains of sand are big users of IP).

Despite IPv6 being around for about 16 years now, there hasn’t been much pressure for network or hosting providers to take it up, but with IPv4 running out, that’s all changing.

Extility 1.3 has full capabilities for IPv6 built in, including assigning individual subnets to customers and a complete firewall service. We are one of the first in the world to offer this capability.

If you would be interested in finding out more, please let us know at sales@flexiant.com.

Extility is Flexiant’s software that powers the FlexiScale cloud platform, which we also license directly to service providers and companies building their own public or private clouds. Extility is a little unusual, as we provide a complete end-to-end solution. You can start with a few of your own physical servers a switch and some storage, add our software on top, and you have a complete working end-to-end cloud platform, including server/storage/network management, customer management, billing/chargeback, customer self-service, reporting etc.  You name it, we’ve pretty much written support for it.

But that’s not all. We have designed Extility in a very modular fashion, which allows us to integrate easily with any of your existing CRM/Billing/Management systems.  The one thing we are not is a ‘black box’, quite the opposite in fact.

Anyway, that’s what we do, and below is a brief outline of the key components of the platform, which we will cover in more detail in future posts.

Hypervisor Support

Customer UI/API

Customer Management

Automatic Signup

Fraud Detection

Metering/Billing

Reporting

Resellers

Our whole UI can be white labelled, and we provide full reseller capability.

Networks

Storage

Extility Storage Gateway

Servers

APIs

High Availability

Today we are announcing that we have made it easier for customers to share images between FlexiScale, AWS and Eucalyptus, and thus have also made it easier to move servers between them. In addition to our native metadata service, we now provide an AWS compatible metadata service.

This experimental feature is currently in beta test, and we recognise that it isn’t yet fully functional. We don’t, for instance, currently support user-data. However, you can boot most unbundled AMIs, once you have put them into a disk image with a kernel and a partition table. See our fsmaker utility here for one way to do this, though there are many others.

To access AWS compatible metadata, you can either use existing tools  (e.g. the euca2ools suite), or parse it yourself by accessing the following URL from your VM (note that this link will not work from outside a VM):

http://169.254.169.254/latest/meta-data

If you access our metadata service using AWS compatibility mode, you will not get the full richness of data we offer. Our native meta-data service includes far more extensive configuration options. However, it should certainly help with making images compatible.

As an example, we have been booting the Ubuntu UEC Natty Narwhal images (download the tarball and untar to get the unbundled image). These correctly populate the openssh key stores and so forth.

Watch this space for more updates!

1. You don’t actually need all of your servers on 24/7, but whilst you try to remember shut them down at the end of the day, you keep forgetting;
2. You need to organise a reboot for 3am to complete an upgrade, and really don’t fancy staying up until then; or
3. You regularly need to run servers at specified times for specified periods and want to keep track of them.

Well, if so, you’re not alone. It turns out these do happen to lots of our customers. So, we have introduced a new feature in the API which you will find useful, called CreateScheduledServerJob (more details via the API page). This call allows you to schedule server stops and starts at any time in the future quickly and easily.

In a future release we will add support for this in the UI as well, so if you have any feedback on how you would like to see that done, please let us know.

We don’t officially support FreeBSD at the moment, but if there is a reasonable demand for it we’d be happy to look further at it, so please let us know.

We are discovering neat tips, tricks and technologies that our customers are building on top of our platform all the time. If you would like to be featured please drop us an e-mail via the support channel.

Every Image that exists on our platform is assigned a unique and secret key, which is only available to the image owner. Each server is also assigned a unique key, which is available to the owner of the server, and through the server’s metadata. We also compute a hash of these two (called the Image Server Hash), and present that to the image using the metadata. Assuming the image is appropriately locked using our Image Permissions feature, this can be passed to the image vendor together with the server’s own key and the image’s id number (in case the image vendor has multiple images). The image vendor can then ascertain whether it is the right image making the call out. Obtaining one Image Server Hash would only allow impersonation of a single server.

The steps involved are explained in more detail below.

Image Creation

On creation of an image, the image is assigned a random Image Key (a 256 bit number represented as a 64 character hexadecimal string). The Image Key is available to the Image Owner (only) to read through the API using the ListImageTemplates call, but never appears within the metadata presented to any VM. This ensures it is private to the image owner.

Sample Image Key:  542246391f5ef2de58c66c21165c39672b703a272c9493b122edc75e47ba9d7a

Server Creation

On creation of a server, the server is assigned a random Server Key (once again, a 256 bit number represented as a 64 character hexadecimal string). The Server Key forms part of the Server/System metadata and is available to read through the API by the server owner using the GetServer API call. This is private to the server owner except (as set out below), but as it forms part of the system metadata, it is also exposed to the server (and thus, potentially, the image provider).

Sample Server Key: 56dc5eb4661dac003f6019a07349d2b326c02ee2aca93e502fa0017f7cd0a6e0

On creation of the server, we also create an Image Server Hash. This is an SHA-256 hash of the ASCII concatenation of the hexadecimal Image Key and the hexadecimal Server Key. It too is presented as a 64 character hexadecimal string. Like the Server Key, this forms part of the Server/System meta-data. As such it is available to read through the API by the server owner using the GetServer API call. Again, as it forms part of the system metadata, it is also exposed to the server (and thus, potentially, the image provider). Due to the one way nature of hashing, knowledge of the Image Server Hash, even when combined with the knowledge of the Server Key, will not allow a deduction of the Image Key.

Sample Image Server Hash: 74d796f800f7dfa8b40be760d207eede752e029556a7cd2927a53b01713a9659

TIP: You can test these to show this works by rehashing the keys and comparing them here

Why is this useful?

The Image may need to authenticate to the image provider’s system. By this we mean make some call out to the image provider’s own systems (e.g. to obtain a license key) perhaps using http. The image would provide the image_id from the metadata (and that will allow the image provider, who knows all the Image Keys she has generated, to deduce the Image Key), the Server Key and the Image Server Hash. The image provider can then compare the Image Server Hash it generates with the one presented to authenticate the user. As only the server concerned can read the Image Server Hash, presentation of the (Server Key, Image Server Hash) tuple verifiably indicates that the Image Server Hash has been obtained from a server created with that image.

For instance, the image provider might use a concatenation of the Image ID and the Server Key (possibly plus a prefix indicating “flexiscale”) as a username, and the Image Server Hash as a password, and use simple https authentication, verifying the image provider’s SSL certificate to ensure that the VM is actually talking to the image provider.

As the Server Keys are unique, if this authentication is done periodically (rather than just on first boot) an Image Provider can get a good idea how many of her images are running simultaneously.

But what stops a user just copying the Image Server Hash?

Firstly, the machine should be appropriately locked to ensure this does not happen. Our Image Permissions functions help here. The Image Server Hash should be sent over an encrypted session to ensure it isn’t snooped.

However, even if a customer (or a third party) obtains a copy of the Image Server Hash, it’s not a disaster. Whilst the (Server Key, Image Server Hash) tuple may be ported by a user with access to that virtual machine to another machine, the fact that multiple IP addresses are now requesting simultaneous authentication with the same server ID is both detectable and traceable, and can result in a refusal to authenticate; abusers can be quickly locked out by black-listing their Server Key.  Compare this to the situation without this protection, where a shared secret of some sort is stored in the image. Revealing that effectively gives away a ‘master license key’.

Possible uses

This feature has a wide variety of applications. Any situation where an image provider needs to know that it’s their own image that’s talking to them, and not someone synthesizing a fake authentication call can use this as part of their cryptographic armory. Of course, the image itself needs to be appropriately locked down or the authentication call could simply be removed. That’s what our new image permissions feature is for.

We’ve added some rather clever new functionality that along with the Image Verification system allows you a fine degree of control on what can be done with your images. If you are an image provider, that translates into what the users of your images can do once your images are made public.

Capabilities

You can now customize exactly what someone using your image can and can’t do with it.

FlexiScale by default allows customers to do all sorts of things that they wouldn’t normally be able to do as an end user e.g. detach disks, resize them, add additional capacity, take snapshots, create new images and so on.

Whilst that’s normally a good thing, it isn’t necessarily a good thing for image providers, who might have proprietary software on the disks for which they charge using licence keys, or might simply want to protect their configuration to ensure support can be given consistently.

Well our Capabilities system is the answer to this. You can now limit customers’ ability to perform a wide variety of options against a server created from your image. The operations you can control are as follows:

• Can Clone: They are able to create clone disks from the existing one;
• Can Snapshot: They are able to take snapshots of a disk;
• Can Image: They are able to create a new image from their server;
• Can Have Additional Disks: Allows them to add additional disks to a server;
• Can be Secondary Disk: Allows another disk to become the boot disk on a server;
• Can Console: Allows them to start a console to the server;
• Can Start: Allows them to start the server;
• Can Create Server: Allows them to create a server from the image; and
• Can be detached from Server: Allows them to detach the disk from the original server.

Obviously some of these capabilities are dependent on one another, and some can be used to circumvent other ones, so you need  to pick your capabilities carefully.

These capabilities do not apply to the image owner, so the image owner can still do any of the above tasks irrespective of the capabilities set. Capabilities only affect other users of a public image. Note that allowing someone to make a new image from your existing image will wipe any and all permission restrictions from their new image, as they will be the owners of that new image.

To illustrate this, we have set out a few use cases below:

Case 1: ISV with a Licensed Virtual Appliance

We are currently working with a number of ISVs who wish to use FlexiScale (or Extility) as a route to market for their software.  They provide a virtual appliance with full support, and without customer access, except perhaps via a web-based configuration page. They thus want to ensure:

• That customers don’t tamper with and change things they shouldn’t;
• That customers can’t breach any protection that might be in place for their IPR;
• That the machine can’t be cloned/manipulated to avoid paying multiple license fees; and
• That the customer customer can still add additional diskspace and take snapshot backups if required.

In this case the ISV would set the following capabilities:

• Can Snapshot: End customers are able to take snapshots of a disk;
• Can Have Additional Disks: Allows them to add additional disks to a server;
• Can Start: Allows them to start the server;
• Can Create Server: Allows them to create a server from the image.

They would then leaving the remaining capabilities disabled.

Case 2: ISV With MAC Address Licensing System

If (as a number of ISVs do) they use individual server MAC (Network Card) addresses as validation for a license key, they would be less concerned about a VM being cloned into more servers, but still retain concerns about the image being manipulated.  They also gives customers access to a non-privileged SSH account for adding the key and charge based on the disk capacity supplied in the server.

In that instance they would allow the following capabilities:

• Can Clone: End users are able to create clone disks from the existing one;
• Can Snapshot: They are able to take snapshots of a disk;
• Can Console: Allows them to start a console to the server;
• Can Start: Allows them to start the server; and
• Can Create Server: Allows them to create a server from the image.

Case 3: GPL Based Image

If an image provider was to provide a GPL based image that they were happy for other people to redistribute, they would leave all capabilities enabled. The image provider might then earn a revenue stream from support.

Image Verification

Image permissions and capabilities go hand in hand with another feature we’ve rolled out: Image Verification.  See an upcoming blog post for that.

The future

We’ve got a lot more work in this area under way. Check back in a month or two and you will be pleasantly surprised.

Summary

Capabilities play an important part in the tools we are launching for image providers and ISVs. Combined with the meta-data service, image verification and other features to be launched soon, it really is the perfect platform to use!

So how does it all work? Well it’s quite simple really.  Your SSH keys are assigned to your customer account, so you can easily add multiple keys for different users.

You add them via the API or UI, then our own Linux images will retrieve them on first boot up and populate the relevant ssh directories. You can then ssh to the box without using a password, safe in the knowledge that this operation requires your ssh private key.

The keys are transported using our meta-data service, so you can also use our first boot scripts in  your own images to achieve similar functionality.

Adding SSH Keys

To add an SSH key into your account via the UI you need to follow these steps:

• Login to your account (it helps to do this!)
• Click settings in the top bar.
• Click List SSH Keys in the box near the bottom (screenshot below)

This will then bring up a page that looks like this:

From here you can add your first SSH Key by clicking Add SSH Key.

It will bring up a further window, that looks like this:

You then have three fields to fill in:

• Username (Linux/Unix username that this key is attached to)
• SSH Key (the encryption identifier, the key itself, and the label, i.e. a single line such as you would find in your authorized_hosts file)
• Description (A unique description for your own use)

If you leave the user name blank, it will add the key to the default user for the image (so ‘ubuntu’ on Ubuntu, ‘root’ on the others). Note that we don’t create users, so any user that isn’t present on first boot will not have ssh keys populated.

Once you’ve added this, any server you start using our images will be automatically populated with those keys. Your own images can retrieve these via a special section of the metadata service.

It’s as simple as that!  As usual we continue to develop features that are there to make your life easier.  We receive feature requests all the time, and keep track of each and every one of them, so please do let us know if there is a feature you are desperate for!

SSH public key support

You can now add SSH public keys to your customer account using either the UI or the API. These keys are then installed on any server you create, allowing you securely to log into any such server without having to type a password.

This is something that we’ve been keen to do for a while, and we know how useful it is, as copying and pasting a cryptic password is not very convenient. There is no need to generate new keys, you are able to use your existing keys and just add them into FlexiScale. We’ve used our meta-data service to transit the ssh public keys, so you can use this method to populate the keys on your own images too.

Image Permissions and Image Verification

Speaking of the meta-data service, we’ve added another couple of new features.

Firstly, the ability to set granular permissions on images.  An image can be locked prior to being made public, which can prevent a user of that image doing certain types of action with it, for instance cloning the disks or even opening a console. This allows, for instance, image vendors to provide appliance images securely to customers. We believe this is a first (yet again) for any Cloud software provider.

Secondly, we’ve have rolled out a feature called Image Verification. This allows image providers to make a call out from their image, and securely verify that the call comes from an instance of that image. There’s some funky cryptography behind this that we’ll explain in another blog post.

These two features form part of a range of image management improvements we are making, the remainder coming with a major upgrade we’ll be releasing in the new year.

UI Improvements

Alongside this release we’ve made a number of improvements to the UI:

• Integration of the meta-data service into the UI;
• Ability to manage configuration of servers while they are running;
• Improved image management functionality;
• Improved Network management; and
• Improved responsiveness of the server start/stop screen (less waiting around to tell whether your server has started).

And as always

We’ve also implemented over eighty minor feature enhancements and bug fixes, ranging from performance enhancements, through business logic improvements, to new API calls. As usual, our API documentation has been updated and can be found in the reference section of our web site.

That’s all for now – more updates coming soon.