Thread: RapidSwitch launches VPS for £1!

Originally Posted by administrator

what apart from the fact parallel will always be faster than serial if people want it to be :P

But only if they can keep the trace lengths the same as you encounter signal timing issues as you move to faster frequencies - So in theory yes, in reality due to costs, no

oh shit lol sorry
( i accidently clicked edit instead of quote on your post freethough )
* administrator *

But logically however you look at it sata/sas/usb/iscsi are all potentially slower than a 32/64 bit wide databus... I never really understood why the backwards step was made. OK, there are headline speeds today that put ultra320 scsi to shame, but that is because of the change of direction in development, not the limit of the medium...

Perhaps one day we will all have serial motorways with excessive timing signals... or a huge chain and cog like a rollercoaster and a fixed spacing... Still it would stop the stop start morons!

Not opted for the iSCSI SAN approach then?

I suppose for the prices you're charging, it wouldn't be worth the hardware investment.

Its worth paying extra for Virtuozzo IMO. OpenVZ is of course the free version.

Originally Posted by PeteK

But logically however you look at it sata/sas/usb/iscsi are all potentially slower than a 32/64 bit wide databus... I never really understood why the backwards step was made. OK, there are headline speeds today that put ultra320 scsi to shame, but that is because of the change of direction in development, not the limit of the medium...

Actually it is the limit of the medium as already stated - The faster you push each line on a parallel bus, the more cross talk you have to deal with and you also have to deal with signal skew - where signals on each line don't arrive at the same time, or within the window - the window gets smaller as the frequency increases.

The wider you make it, the more chance of skew and the more cross-talk, also the more expensive it becomes to design boards that meet the requirements, because you have to add more and more layers, to keep trace lengths the same and reduce the skew. So it is a limit of the medium.

You can't compare it with motorways, because the cars in each lane don't have to arrive at their destination at the exact same time as each other, and there's minimal cross-talk, and if there is what would be classed as cross-talk rarely effects the car reaching the destination and it certainly doesn't corrupt the car (except in extreme cases), causing the car to have to be sent from the source to the destination again.

We are however veering majorly OT.

Originally Posted by James[UH]

Its worth paying extra for Virtuozzo IMO..

We'll agree to disagree that it's worth it. Having used it, I'd not give you 50p for it, but there we go.

Good luck with this.

Originally Posted by edb49

Quite a few seem to! We'll be launching control panels quite shortly, we've got a very clever way of doing it which modularises the installation of any control panel across all our offerings.

Want to elaborate a little on that?

Originally Posted by Cranky

Good luck with this.



Want to elaborate a little on that?

Sure. We found that there were a few problems with standard virtual offerings which we've set out to correct on ours. Firstly, we built our entire framework in the same way the rest of our systems are built. So we support OpenVZ, HyperV, Virtuozzo, Xen and VMware within the same framework. We've done it so that the virtualisation technology can be transparent to the client, or alternatively we can provide a differentiated offering based on the technology used. From our staff point of view, they click "New VPS" then they select "HyperV" (or whatever else) and then the operating system. We then have modules that go out to each of the virtualisation technologies to collect bandwidth, CPU usage, etc, etc, and plug this data into our main core control panel which does all the billing for bandwidth, 95th percentile calculation, and monitors CPU/RAM usage on the virtual servers to fire off an automated email to clients if it looks like they need to upgrade. The important thing with this framework is that we can allocate VPS to nodes seamlessly and allocate them based on actual/allocated RAM/CPU/disk/etc free. Many hosts at the moment have a static "we put 30 VPS on each node of X specification" which we don't think is an effective or intelligent way to do it.

The next stage of this is we rationalised running a large number of VPS nodes in our system needed to be managed in automated fashion. Change control becomes very important when you're running (as we intend to) 10s of thousands of VPS. For example, OpenVZ is built around OS templates. We realised that these need to be kept up to date so a client is always delivered a fully-patched operating system. What we have developer is a modularised system that plugs into different virtualisation technology to keep the images/templates updated. At the moment we automatically rebuild these every night and then push the revised images/templates down to the VPS hosts. As all provisioning is automated, we can perform test installs to check the functionality of these before pushing them down.

The next stage of our architecture is how to deal with additional software like control panels. The first stage of this is pretty easy, which is to plug the Parallels/cPanel/DirectAdmin APIs into our management system so we can automate license requests, and integrate them into our order system and billing system so they're fully automated. We then decided to abstract the installation process - you hit major scalability issues if you try to maintain *secure* templates/images for all your operating system and control panel combinations, on dedicated servers, VPS, etc. So what we are now well on the way to completing is a system that abstracts the control panel installation from the underlying VPS/cloud/dedicated server platform, essentially it acts like a human operator installing a control panel, and is extensible to plug in any "modules" for a new item of software - the idea being that clients can order a server with applications x, y and z preinstalled. From our point of view it will simply be a case of the client ticking a few boxes on the installation page, and everything gets automated from there on in.

This scratches the surface of what we've done and our current development. Sorry for the long-winded reply, but it's quite difficult to explain how the architecture works without being verbose!

Sounds very nice Ed.

One small point on the static figures of VPS/VDS per node - That of course does to some extent depend on the technology and is more of a problem if you're over-selling your CPU and RAM, rather than providing fixed limits. It does seem rather common for people to offer 256MB guaranteed and then offer 1GB burstable for example, same sort of deal with CPU - Which is bound to cause issues if you go for a fixed figure per box, as some clients are probably relying on having that burst RAM & CPU. We've gone the other way (as we always have done) with fixed limits - Obviously we do still keep an eye on things because of disk I/O, but when your disk is 2 x RAID-10 mirrored providing the storage, I/O is rarely an issue

Originally Posted by edb49

The important thing with this framework is that we can allocate VPS to nodes seamlessly and allocate them based on actual/allocated RAM/CPU/disk/etc free. Many hosts at the moment have a static "we put 30 VPS on each node of X specification" which we don't think is an effective or intelligent way to do it.

Pretty much the same as how we do it, with a no overselling, all resources guaranteed setup, VPS are allocated to nodes based on what the client orders, with a fixed number of cores, disk, ram etc - the "clever" bit is in provisioning the "lower end" vps efficiently, as there's obvious "wastage" if you stick 16 vm's with 512mb of ram each on a single node, when each has 16 or 32Gb of ram.

We tried to keep "ready to go" images of the o/s + cp + addon templates, but found the maintenance task higher than staging a direct cp install onto a basic o/s installation as required, so it becomes point-click install o/s, click run script to install o/s, click run scripts to install addons, click run scripts to install our common extras, play macros to do initial configuration, manual eyeball and check, let client at it to break it.

One of the largest issues was where the control panels seem to embed details of the IP - directadmin licences being a pain for that, which negated the ability to have a vps+da pre-loaded saved as a deployable image.

So (couldnt quite tell from the description) you planning to "force push" out to the *existing* live VM's new o/s security patches and CP updates after testing automatically, so that they're all in line ?

Originally Posted by othellotech

So (couldnt quite tell from the description) you planning to "force push" out to the *existing* live VM's new o/s security patches and CP updates after testing automatically, so that they're all in line ?

We've provided for this and have the capability but have no commercial plans for it currently.

Originally Posted by edb49

So we support OpenVZ, HyperV, Virtuozzo, Xen and VMware within the same framework.

Can we send you an OVF/ESX image to load into VMWare?
When it comes to upgrading between packages, is it a simple case of you updating the limits at your end?

Essentially the answer to this is "no". We're trying to automate everything as much as possible, and don't support clients uploading their own images currently. (No plans to change this either.)

We can update the limits our end to upgrade packages, yes.