Questions about virtual servers

[Rockingstone]

Hello,

We're currently looking into how virtual clouds could help us deal with hosting a website (with backend databases) which can suffer from high peaks at times. In order to avoid having to invest largely in hardware which is most likely idle most of the times we're currently investigating clouds. We're already looking into Amazon EC2 but that comes with some limitations.

I went over your product details and the several messages of this forum but still not everything is clear to me. If I understand correctly you can offer virtual servers which can either run Windows or Linux. Most common Linux distributions are supported, but I already read that Debian wasn't supported just yet. Am I right to conclude that its not possible for customers to create their own OS image but that when you refer to image cloning you basically mean that you set one up, the customer can then customize it and then the new image can be created/cloned/etc ?

Also; when it comes to Linux what distributions are supported? I already came across CentOS, are there more? Also not unimportant: if the choice of the OS is limited how are you dealing with OS upgrades? Is that the responsibility of the customer or do you provide such updates?

Also not unimportant to know is if there are any limitations? On Amazon's EC2 the whole thing is Xen based; one kernel basically runs the show. This means that when setting up an environment of your own you will always have to make sure to provide the system with the right kernel modules. Sometimes (very seldom) this can be a limitation if you wish to fully rely on package management without wasting space on unused kernel images. Are there any details like this with your services which we should keep in mind?

I also read that some Linux servers were unmanaged. What does that mean exacty? One of the key features which I picked up (hopefully correctly) was that adding/removing instances could be automated on your end. In other words; the moment the system detects a lack of capacity it can automatically trigger expansion with new instances. Is this assumption right or did you basically mean that upon detection we can initiate expansion through the use of the API ?

And when talking about the API; how is control access setup? Is it possible to utilize the API both in and outside of the cloud? When setting up a cluster in the cloud itself it might be beneficial to have a "monitoring instance" which has a fail-over outside the cloud.

Finally pricing; you have seperate charges for up/down loads. Do you also charge data streams between instances?

Thanks in advance for any insights you can give us.

With kind regards,

Peter Looyenga - Systems Engineer Rockingstone IT (http://www.rockingstone.com)

[phuber]

Hello,

We're currently looking into how virtual clouds could help us deal with hosting a website (with backend databases) which can suffer from high peaks at times. In order to avoid having to invest largely in hardware which is most likely idle most of the times we're currently investigating clouds. We're already looking into Amazon EC2 but that comes with some limitations.

I went over your product details and the several messages of this forum but still not everything is clear to me. If I understand correctly you can offer virtual servers which can either run Windows or Linux. Most common Linux distributions are supported, but I already read that Debian wasn't supported just yet. Am I right to conclude that its not possible for customers to create their own OS image but that when you refer to image cloning you basically mean that you set one up, the customer can then customize it and then the new image can be created/cloned/etc ?

Also; when it comes to Linux what distributions are supported? I already came across CentOS, are there more? Also not unimportant: if the choice of the OS is limited how are you dealing with OS upgrades? Is that the responsibility of the customer or do you provide such updates?

Also not unimportant to know is if there are any limitations? On Amazon's EC2 the whole thing is Xen based; one kernel basically runs the show. This means that when setting up an environment of your own you will always have to make sure to provide the system with the right kernel modules. Sometimes (very seldom) this can be a limitation if you wish to fully rely on package management without wasting space on unused kernel images. Are there any details like this with your services which we should keep in mind?

I also read that some Linux servers were unmanaged. What does that mean exacty? One of the key features which I picked up (hopefully correctly) was that adding/removing instances could be automated on your end. In other words; the moment the system detects a lack of capacity it can automatically trigger expansion with new instances. Is this assumption right or did you basically mean that upon detection we can initiate expansion through the use of the API ?

And when talking about the API; how is control access setup? Is it possible to utilize the API both in and outside of the cloud? When setting up a cluster in the cloud itself it might be beneficial to have a "monitoring instance" which has a fail-over outside the cloud.

Finally pricing; you have seperate charges for up/down loads. Do you also charge data streams between instances?

Thanks in advance for any insights you can give us.

With kind regards,

Peter Looyenga - Systems Engineer Rockingstone IT (http://www.rockingstone.com)
Peter,

We currently provide the following golden OS images:
• CentOS 4 (32-bit)
• CentOS 5 (32-bit and 64-bit)
• Ubuntu 6.06 LTS
• Windows Standard Server 2003 (32-bit and 64-bit)

We are currently working on a few more:
• Windows SBS Server 2003 (32-bit only) (coming very soon)
• A current Debian version (coming very soon)
• We will be preparing Ubuntu 8.04 LTS as soon as it is stable (~ end of May)


Fundamentally, it is possible for customers to create their own OS images (standard ISO boot image). We have already done that for suppliers of highly specialised Linux based Appliances that are based on a very ‘lean’ or ‘closed-down’ Linux stack. However, there are a few things we need to sort out before we can release that as a supported feature for general use. Why this?
• We need to allow customers to get access to a VNC console that lets them see the progress of a kernel compile and potential error messages (the access is fundamentally there, but we need to sort out some access security issues).
• We need to fully document how VSTools can be installed by customers themselves. VSTools are OpenSource accelerated network drivers that improve network speed dramatically and are pretty much required to get acceptable VM network performance.
• We are in the process of documenting how customers can upgrade to another Linux release or Kernel version and how that should be done taking VSTools into consideration.

Re supported golden images, please see above. FlexiScale currently provides an unmanaged Virtual Dedicated Server (VDS) and it is therefore the customer’s responsibility to manage updates. The documentation described above will explain how these upgrades can be done.

FlexiScale runs on a Xen-based hardware supported virtualisation platform (Intel VT or AMD-V). Each VM can run fully independent of the host OS and we are so far not aware of any limitations in running the golden OS images we provide. Once we can fully support customer build images, there should be full flexibility.
The only current limitation could come from VSTools that might be hard to get compiled into your highly modified Linux stack / kernel.

Currently, customers have to monitor their environment themselves and then add new instances via the API. However, we are planning to release a closed Beta of Phase I of our ‘auto-scaling’ functionality at the end of April.

You can access the API from both inside and outside the cloud.

We don’t charge for traffic that stays inside the FlexiScale cloud. So for example, if you build a multi-tier application with FlexiScale, the application servers traffic talking to the Db server will be ‘free’.

Phil Huber - COO/CTO

[Dean]

Peter,

Currently, customers have to monitor their environment themselves and then add new instances via the API. However, we are planning to release a closed Beta of Phase I of our ‘auto-scaling’ functionality at the end of April.

You can access the API from both inside and outside the cloud.

We don’t charge for traffic that stays inside the FlexiScale cloud. So for example, if you build a multi-tier application with FlexiScale, the application servers traffic talking to the Db server will be ‘free’.

Phil Huber - COO/CTO

Phil

Couple of questions.

[1] Are you still on track for the end of April re: Auto Scaling functionality
[2] What functionality are you actually delivering with this? ie. can we control the constraints re: scaling
[3] Do you have diagrams of your network configuration. ie. what firewalling capabilities are there
[4] When are you implementing the ability to load balance across multiple VMs

Will have more im sure :-)

thanks

dean

[Dean]

does support read these forums? or should I try email?

[jeisenbe]

Hi Dean,

Your post seems to have been missed. I will get someone to answer you as soon as :)

Jonathan.

[jeisenbe]

Dean, I apologise about the delay - your questions have been answered inline, below:

[1] Are you still on track for the end of April re: Auto Scaling functionality?

We have hit some technical challenges, but we are making good progress and plan to release a close Alpha test with a few customers around mid-May.


[2] What functionality are you actually delivering with this? ie. can we control the constraints re: scaling

Initially, the constraints will be very basic and mostly around number of connections per server and latency of your service (measured via a test URL). However, we have plans for Phase II where we will provide a whole set of business rules that customers can define. Below are a few examples. We are keen in discussing these rules with customers to find out if they would add value to them:
Definition how many VM's are required as base service (i.e. at least 1 VM)
Upper threshold that triggers a new VM start (i.e. num of connections or latency)
Lower freehold that will trigger a VM removal (peak is over)
How far does customer want to scale up (i.e. max. 5 servers)
Delay in s after Decision Engine detects a violation of threshold (i.e. 0-600s)
Alarming (let customer define for each stage between email/txt notification)
When an additional VM is switched on (immediately)
When the max. number of VM is switched on (immediately)
After max. number of minutes above base service (i.e. alert if DoS attack)
After racking up $$ in xx minutes/hours (protect customer from pay-as-you-go trap if something goes wrong or DoS)
Automated escalation (in case of malicious attacks - scale down/stop)
After max. number of minutes above base service (i.e. just stop the resources above base service since there is no value in keeping them up)
After racking up $$ in xx minutes/hours
[3] Do you have diagrams of your network configuration. ie. what Firewalling capabilities are there

We will release some more formal diagrams about our configuration later. As regards to Firewalling capabilities, our current implementation is a simple port-blocking service and does not provide deep packet inspection. However, we are already in discussion with IDS/Firewall appliance providers that would like to offer their product as software appliances within the FlexiScale environment.


[4] When are you implementing the ability to load balance across multiple VMs

We can currently offer a manually configured service where the customer is required to talk to our support/service staff to get it configured. However, we are at the final stages of engineering of a fully integrated LB service (Layer 4 Linux based) and hope to release it at the end of May/early June.