Which providers offer LEBs with combo of SSD and non-SSD "local" storage?

craigb

I'm aware of 64u http://www.64u.co.uk/ offering SSD and SAN storage. Who else?

If you're a provider, what stops you from offering a combo? (investment outlay? waiting on the price of SSDs to drop further? branding thing ("we're SSD powered"), added complexity, little demand etc). Personally, as much I'm drawn to SSD, I prefer a combo as I can both do more with it and decide which "hot files" benefit from SSD.

*local = storage provisioned directly to the guest (e.g. local HDD, SAN storage but not FTP backup space)

Maounique

There is the cachecade and the ssd cache module some ppl are using, especially the latter.
In this way, the hot files stay on SSD and you still have a hefty storage space.
I hear now solus accepts 2 HDDs and it is only a matter of time I suppose before KVMs will benefit from that.
I was thinking too of some combination, even OVZ can mount some NFS or even CIFS share, how to automate that at provisioning is another matter, tho.
M

rds100

I guess it's because it's not common so most people are not looking for such a setup since they don't even know that it is possible and don't know how to use it.
I am sure when someone offers it on LEB/LET there would be a lot of signups from curious users who would order it to test it and then would not renew it for the second month because they lost interest and didn't know what to use this for.

SimpleNode

To be honest, I have no idea how to have mulitple 'drives' mount in OVZ.

I have a small SSD sitting in one of our nodes after Incero offered it for $1, but no idea how to use it in OVZ

rds100

@SimpleNode said: To be honest, I have no idea how to have mulitple 'drives' mount in OVZ.

I have a small SSD sitting in one of our nodes after Incero offered it for $1, but no idea how to use it in OVZ

>

It is certainly possible, i use it on an internal node:

Filesystem            Size  Used Avail Use% Mounted on

/dev/simfs            1.0G  639M  386M  63% /

/dev/mapper/vg1-mi1   886G  367G  475G  44% /var/www

tmpfs                 128M     0  128M   0% /lib/init/rw

tmpfs                 128M     0  128M   0% /dev/shm

You put something like this in /etc/vz/conf/XXX.mount

!/bin/sh

/bin/mount -n --bind /mounts/mirror1/CentOS /vz/root/105/var/www/

Nick_A

Speaking for us personally, we use SSD-caching like Maounique mentioned. I haven't really weighed the pros/cons between our solution and a distinct SSD/HDD combo, so really nothing is stopping us other than a lack of research.

Maounique

TBH I think that the ssd cache thing is better than having distinct partitions on each.
1. The hot files are picked by the module as on demand basis, if a user does it, will probably not be as efficient;
2. The SSD will be filled with used space by the ppl which dont use the VPS or files which do not need fast access, therefore more IOPS will go to the HDDs resulting in higher iowait states.

The system can be tweaked a lot and is impartial, making, more or less, objective decisions, having separate partitions means leaving the decision for the users mostly and that is not a good thing.
At the very least, a SSD partition and a raid with ssd cache (another drive) might solve both problems.
M

DomainBop

Colorhost.de -SSD swap on Xen

Clustered.net in the UK also has SSD swap but 40-170GBP per month is a little above lowbox territory