Before signing a rather large cheque for a new server ( see my other thread a page back) I've decided to have one last consideration of virtual servers.

My current thinking has always been bigger brighter faster. I love virtualisation as a concept and for testing / developing things. However beyond a powerful desktop I've never had to estimate or scope out a build.

So before I launch off and buy a server that is total overkill for all bar our peak traffic in a notional 18 months, I want to look hard at virtual options.

Given the virtual layer is on 15k sas isan and can be scaled memory wise easily, vm's are 1 month contract versus 12 or 6 + hardware outlay...I'm struggling to write any more on the cheque.

I know in some cases greedy neighbours is a major turn off.

one vm would not equal one dedicated, but a tier like:

LoadB

Web1 --- Web2

Db

Would work, indeed it does quite happily using dedicated boxes I have elsewhere. there are of course massive variations on that theme, passing static resources out to ngnix, memcache server etc...

So, anybody want to step up as a guru, and failing that, anyone want to burn an afternoon / day/ weekend making one work? So linux, mysql, ngnix, lighty, litespeed, php skillz would help...although arguably I get by on little

Call or txt on 07900 826 101

Info from 50,000 ft : virtual dedicated servers | virtual dedicated hosting | virtual dedicated servers

What aspect are you asking?

You want to rent shared virtual servers on the hosting companies machines and then you can buy more capacity within the VM when there is a peak and let it go again when you're done?

VMWare is pretty easy to get going for servers too and unless you're trying to something a bit more complex like PCIe multi-root virtualisation I can't see you having any serious issues.

How much is the VM option compared to the hardware option approximately over say 18 months?

Happy to lend a hand and you have me on msn etc.

Just txt'd you Col.

A basic sata based vm is 35quid a month + vat.

I'm happy setting up vm's, heck even zen to host vm's. What I'm not totally happy with is doing it for production setups, estimating the real requirements.

It makes sense on one hand to rent the vm's over buy a big box as the vm's can be upgraded and scaled.

eg. one front end loadb

two web servers or one maybe

one bigger 15k sas based mysql one.

The current box is a single cpu dual core 1.8 with 8gb of ram and sata based disks. It's not going to be hard for a fibre san with 15k sas disks to be quicker and thus as mysql is sooo dependant on disk and config (more so) not too hard to guess a boost.

I am of course not suggesting it will be as quick as a raid10 dedicated sas server with dual q3gh quad core procs...but it might a bit cheaper and more robust.

Coosts, well co-lo is going to be circa 120 a month, + hardware costs / deprec.

Renting vm's will be dependent on build and number required, say 35 cheapest low spec and 120 a month for a dual core 2Gig of Ram, basically what we have now.... which is why I've hit this omg I've missed a trick mental wall.

So to surmise, not setting up a server to do virtualised hosting, more using a service (no hardware purchase/ support headache) but then enjoy the complication of making the build work, so shared nfs over ssh etc.

I've done a fair amount of this, but you need to know the ins and outs of how they are visualising the systems.

eg is 1 CPU 10 low power CPUs or 1CPU with a 10th the clock speed (makes a difference)

How are they virtualising the storage. Guessing it's just a RAIDed SAN.

Are they time slicing the other I/O to the cards?

Database, you could improve performance by hiring a couple of VM's for it and runing mysql cluster on them if you have a good responce time and your DB is spread over many discs on the SAN.

Otherwise how about collocating a big DB server and then having a couple of low end VM's (one UK one US perhaps depending on traffic location) to do the web server side, so allowing the DB server to scale. The current server with a few tweaks should do fine as it's then missing the disk load from the web server.

My SQL is heavy on disks but also RAM so how much RAM etc can you spec with the VM.

Also which SATA drives are you currently running as some perform massively better than others. Might be a cheap way to get a huge performance gain for minimal expenditure. That plus how is the RAID volume and file system tuned for the data.

Drop me a call or PM and I can discuss further or I can give you a quick call around 4:30-6ish this evening.

Fir the guy who actually signs the cheque an English translation would be welcome, even a diagram with some diemensions and indication of where to apply 14lb hammer to make it work!

Please and thankyou

For the guy who actually signs the cheque an English translation would be welcome, even a diagram with some diemensions and indication of where to apply 14lb hammer to make it work!

Please and thankyou

I assume that's aimed at Colin?

Well i am glad some body knows what they are talking about! :eek:

For the guy who actually signs the cheque an English translation would be welcome, even a diagram with some diemensions and indication of where to apply 14lb hammer to make it work!

Please and thankyou

Too right. I've got a headache from looking at those posts.

It's all Geek to me:confused:

All makes perfect sense

Funnily enough, I followed a MySQL virtualisation scaling webinar today which approached just this topic. An interesting point discussed was whether virtualisation provided any performance benefit if you were "clustering" multiple "virtual" nodes. The general feeling was "maybe, if and only if your nodes were on separate hardware". I think the concern is that any VM can only run as fast as bare metal, and even with the latest CPUs and "bare metal emulation", the chances are some overheads may still impact on performance.

Another thought Colin, John, and please excuse me for my ignorance on the topic, but how much is Briskoda more than "just a database" ?

Would another possibility be putting it as an instance on an already existing database which has a billian nodes and a trillian GB of RAM? It may be faster / more reliable and cheaper than getting either a dedicated hardware box or virtualising our own install of MySQL or whatever it is that runs brisky....

I think the concern is that any VM can only run as fast as bare metal, and even with the latest CPUs and "bare metal emulation", the chances are some overheads may still impact on performance.

There just *has* to be overheads, because something is running on the bare hardware, and the OS is then running on that. Also, as you're invariably running on a SAN rather than dedicated spindles of drives, there will be a hit there compared to building on today's hardware with direct-attached, individual spindles properly configured.

Having said that: It might not be a problem, and virtualisation gives a lot of benefits (like fast, live snapshots in case you bugger things up )

We're moving to virtualised servers at work- Windows though, on HP blades with ESX server. The performance is very good, but we're running very high-spec blades and moving from servers that are 3 or more years old. I haven't tried virtualising any of the big ones yet.

We are just embarking (eg im down in slough next week doing the pre-build) on a mammoth VMWare project.. with the end result being at least 80% of our datacentre virtualised onto 5 quad-quad opteron DL585's with 128gb of ram and a 144 FC-spindle Netapp 3140. this includes our main line of business SQL databases, web serving, file serving and exchange.. there will also be replication, snapshots etc over to our DR site.. the VMWare servers there will handle all the development enviroments so we are not wasting our tin.

For us inparticular we will see big benifits and ROI, as our hosting team have a habit of massively over-speccing servers for stuff they can buy (think dual quad core and 16gb ram for a print server) and re-using decomissioned servers when they cant.. currently the average age of the hardware in our Datacentre is 6 years old... mind you i think ive knocked at least a year off that when i virtualised a Pentium-pro 200mhz last weekend

I think the comment about overheads is only true for raw CPU performance which will be tiny, and even so the big developments in hardware and multi-core CPUs is fast outpacing the mid-tier OS and application's ability to fully utilise it.

Also there are big gains you can make by over-commiting memory per VM vs total hard memory and the general idea of with a decent sized investment in ESX you will more than likely use a SAN for storage which is going to run rings around any DAS arrangement.

We are just embarking (eg im down in slough next week doing the pre-build) on a mammoth VMWare project.. with the end result being at least 80% of our datacentre virtualised onto 5 quad-quad opteron DL585's with 128gb of ram and a 144 FC-spindle Netapp 3140. this includes our main line of business SQL databases, web serving, file serving and exchange.. there will also be replication, snapshots etc over to our DR site.. the VMWare servers there will handle all the development enviroments so we are not wasting our tin.

For us inparticular we will see big benifits and ROI, as our hosting team have a habit of massively over-speccing servers for stuff they can buy (think dual quad core and 16gb ram for a print server) and re-using decomissioned servers when they cant.. currently the average age of the hardware in our Datacentre is 6 years old... mind you i think ive knocked at least a year off that when i virtualised a Pentium-pro 200mhz last weekend

I think the comment about overheads is only true for raw CPU performance which will be tiny, and even so the big developments in hardware and multi-core CPUs is fast outpacing the mid-tier OS and application's ability to fully utilise it.

Also there are big gains you can make by over-commiting memory per VM vs total hard memory and the general idea of with a decent sized investment in ESX you will more than likely use a SAN for storage which is going to run rings around any DAS arrangement.

Nope, I understand that even less :confused::confused:

Col D can we have a Geek - English translator just for the tech shed please????

Another thing to consider Colin.. opening that big box labelled sun and having a shiny new toy that looks and smells fantastic! I love the smell of new kit :P

I think the comment about overheads is only true for raw CPU performance which will be tiny, and even so the big developments in hardware and multi-core CPUs is fast outpacing the mid-tier OS and application's ability to fully utilise it.

You are probably right.

The overheads are there, but whether they are significant is another matter.

There just *has* to be overheads, because something is running on the bare hardware, and the OS is then running on that. Also, as you're invariably running on a SAN rather than dedicated spindles of drives, there will be a hit there compared to building on today's hardware with direct-attached, individual spindles properly configured.

Having said that: It might not be a problem, and virtualisation gives a lot of benefits (like fast, live snapshots in case you bugger things up )

We're moving to virtualised servers at work- Windows though, on HP blades with ESX server. The performance is very good, but we're running very high-spec blades and moving from servers that are 3 or more years old. I haven't tried virtualising any of the big ones yet.

To be fair a SAN with 10 boxes with 48 disks and a properly tuned set up will perform a lot better than local discs no matter how well they are tuned.

A SAN also copes a lot better with server hardware failures than a plain server with locally attached disks. If the disks are in a JBOD configuration you can get some reasonable performance, but if you start doing RAID then the sort of equipment you get in a SAN will eat your local disc RAID system for breakfast without thinking about it unless you're going to spend mega money.

Sure in maybe a small percentage of circumstances the local discs might be quicker than a SAN (say a tiny file on a sequential hit) but as soon as you push upwards the SAN wins.

Another thing that is very important to find out about the storage SAN is how are the discs you have access to configured? High IOP or High throughput or a balance of the two.

Ideally for your database you want huge IOP to get as many queries through as possible, although obviously it isn't quite that simple.

FWIW are you using INNODB tables in mysql?

As I see it you have a few things to look at:

- How much load does the web serving side place on the current server.

While this might not be that high, the context switches will be killing the CPU's

- How much of the database is accessed regularly and can you split this off into an archived section for the older threads.

- What the performance of the various parts of your current server is.

I'd say something like this could give maximum benefit.

- Web server visualised over a few (2+) virtual PC's that are good enough.

- SAN storage space on some cheap bulk storage server (7200rpm SATA discs)

- Fastest (highest IOP) discs you can put in the current server and use it to do database work for the recent posts. You could use fast discs on the SAN too, but you'd have to see the IOP perfomance.

- Keep your OS on separate physical discs to your database.

Also from the software point of view, it's worth checking if you can that the system uses prepared statements rather than creating each query as it's needed.

Did try and call you earlier then I had to shoot out.

Quite happy to lend a hand or information to you as required.

For Roo/JohnD

Basically Colin is working out if it's best to splash a load of cash on a bigger faster server and carry on pretty much as is or if it's cheaper or better to rent a share of somebody else's much much bigger system cluster (a load of systems acting as one) and run the servers off their rented kit.

Yep, it will work out about the same cost wise, but renting is more flexible.

The logical next step is to commission at least some web nodes, it's only an ip change, see how they cope.

There is a great scope to improve things, a number of attack angles are possible, shard the web / db, shard the db, add mysql slaves and a few more. The problem is at the moment it's on one machine, it's hard to replicate 54k page views and user activity... that is to say 1000 users viewing the home page is a lot less than 100 hitting new posts button. So a bit of this as it's an evenings project is to trial something, experince some pain and modify to suit.

It might be that at the end of this process we go for a few cheaper webservers than one big chunky one

Apologies for not getting back to you I was on my way out to Wales. How are you fixed this week, have skype etc?

I just remember the old days where we used to share a server, and the end result was not nice. I recall that if someone else on the same server did something that ate up the CPU cycles then our site would grind to a halt.

I just remember the old days where we used to share a server, and the end result was not nice. I recall that if someone else on the same server did something that ate up the CPU cycles then our site would grind to a halt.

True.. although things are much more flexible with VMware handling CPU time assignment and limiting resources to V-CPU's

True.. although things are much more flexible with VMware handling CPU time assignment and limiting resources to V-CPU's

Indeed, as I stated above it depends how the CPU's are carved up, but if you hire enough nodes you will be ok.

Bear in mind all a node is is a time slice or portion of resources on one or more PC's.

The dedicated hardware might have a slight edge on pure speed for the same total spend, but then you have data centre costs on top of it.

So if you roll those two together it becomes a similar cost to get the same or more power with a greater reliability.

If either of the Colins want any help on the front, you're both more than welcome to fire questions my way. I've already wasted too much time doing similar for various projects.

Just trying to get my head around this, is a node what mosso call a cycle?

From their FAQ

What are compute cycles?

Compute cycles measure how much processing time your applications require on the Mosso cloud. Using 10,000 compute cycles in a month is roughly equivalent to running a server with a 2.8 GHz modern processor for the same period of time.

IIRC the briskoda ad server was hosted on mosso and according to colin it chomped through far too many!

Not quite sure what Mosso would call a cycle as the definition they've given from your post is a bit wooly. Got to love marketing departments hey.

Their cycles, sounds like they were just giving you a chunk of CPU time and that was based on system priorities rather than actual hard control of the system resource. That alone will have taken a fair chunk of CPU to manage so slowing things down.

Typically these days you don't buy cycles, you buy a virtual machine, which represents a defined chunk of a real PC.

So say you have an 8 core system with 8GB of RAM, each node might be a single core and 1GB RAM plus a chunk of the disk space and the system could support a total of 8 "nodes" or virtual machines.

Then have farms and farms of these machines where you can have various levels of `node`

You have the standard one as above plus others that are lower, some that have more CPU/RAM etc and if desired a node can even have the full resource of the PC.