Server spec out for potential virtualisation project

[Guest Guest]

You don't seem to be understanding that I want a HA system with centralised storage (quite possibly I'll end up with 2 storage devices, with their built in mirroring set up). I don't want traditional 'storage' on a device, as it makes disaster recovery more difficult. I want centralised storage, per the industry standard model for virtualising servers. If I leave, I don't want to leave behind some custom built, complex to manage system. I want companies able to support their stuff, and I want it to be simple. I don't want to spend time fiddling.

 

Until you buy 2 SANs with 2 seperate paths for teh data ie 2 switches and the appropriate cabling you arnt going industry standard. dhicks model is actually better in terms of HA as it doesnt rely on any single peice of hardware, and aslong as your servers have enough spare capacity you can bring all of your (critical) systems back up on the single remaining box.

 

Saying that, if you arnt comfortable with DRBD then I wouldnt go that way, but I would be looking at some form of backup SAN. If/when the SAN goes down you will look like abit of a tit trying to explain to SMT why your brilliant new idea was crippled by a single faulty RAID card/RAM/etc. Of course this is all dependent on money, and as you are going to be saving money over the long run buying 2 SANs isnt such a bad move... Buiding a cheap backup SAN could be a suitable compromise.

 

On that QNAPs SAN you mentioned; no way, not a chance. Its a Atom with 1gb ram and no RAID card. iSCSI likes a nice big cache of RAM, and the software raid is going to hammer your CPU. The Overland looks a much better bet.

 

 

How are you planning on implimenting the file serving on this setup? IME Id be going physical, be that as a totally seperate physical server or directly from the SAN/NAS.

Edited February 20, 2011 by Guest

[dhicks]

I want a HA system with centralised storage

 

But couldn't your storage servers run as VMs on a larger bit of hardware? Your servers are heafty enough that you could give a storage VM a dedicated core, a dedicated network port, 4GB of RAM and, of course, assign it its own block device - no need to use a VM disk image that's part of a larger physical disk, the storage server can have a whole RAID 5 array to itself.

[dhicks]

if you arnt comfortable with DRBD then I wouldnt go that way

 

I'd use DRBD or rsync myself, but shurely Windows Server must have some kind of real-time disk replication option?

[localzuk]

Until you buy 2 SANs with 2 seperate paths for teh data ie 2 switches and the appropriate cabling you arnt going industry standard. dhicks model is actually better in terms of HA as it doesnt rely on any single peice of hardware, and aslong as your servers have enough spare capacity you can bring all of your (critical) systems back up on the single remaining box.

 

Saying that, if you arnt comfortable with DRBD then I wouldnt go that way, but I would be looking at some form of backup SAN. If/when the SAN goes down you will look like abit of a tit trying to explain to SMT why your brilliant new idea was crippled by a single faulty RAID card/RAM/etc.

 

On that QNAPs SAN you mentioned; no way, not a chance. Its a Atom with 1gb ram and no RAID card. iSCSI likes a nice big cache of RAM, and the software raid is going to hammer your CPU. The Overland looks a much better bet.

 

Indeed. I am considering 2 SANs and 2 switches to handle it all. If I'm going to go down this route, I want to do it properly.

 

The QNAP stuff would be ideal for a D2D backup solution though.

 

But couldn't your storage servers run as VMs on a larger bit of hardware? Your servers are heafty enough that you could give a storage VM a dedicated core, a dedicated network port, 4GB of RAM and, of course, assign it its own block device - no need to use a VM disk image that's part of a larger physical disk, the storage server can have a whole RAID 5 array to itself.

 

True, but as I said, I'm not comfortable doing this, it isn't a 'standard' way of doing it and would make someone coming in to take over, should I leave, scratch their head and ponder what I was doing. I don't want to do 'custom' stuff using DRBD. I want someone to be able to call, say, Overland and say 'my servers aren't replicating properly - fix it'. I live in an area where IT people are few and far between, and where the age of the population is increasing and averages something like 55 now. So, getting someone new would be difficult if they needed too many skills.

Edited February 20, 2011 by localzuk

[localzuk]

I'd use DRBD or rsync myself, but shurely Windows Server must have some kind of real-time disk replication option?

 

Best I know of is share level replication (ie DFS), and that wouldn't really suit.

[Guest Guest]

I'd use DRBD or rsync myself, but shurely Windows Server must have some kind of real-time disk replication option?

 

Best I know of is share level replication (ie DFS), and that wouldn't really suit.

 

I may be wrong but Ive been given the impression HyperV with clustering can do this. Personally though I wouldnt go down that route as simply put, after my experiances of DFS, I dont trust microsoft for that sort of thing, and also HyperV doesnt support the linux distros I use.

 

dhicks: dont get me wrong, I love your model and it would certainly be one of the option I would consider, but it isnt something you can plough into without being confortable with the concept and the workings of it. rsync is capible of duplicating block devices now isnt it? I assume this is what you are talking about? Or are you referring to file level with LVM taking a snapshot, rsync mirroring it off, and then deleting the snapshot?

Either way its not masively complicated but IME it is way above alot of peoples heads and is certainly not something our LEA would be happy with for the reasons localzuk has mentioned.

 

Localzuk: you are certainly heading down the right path as far as your requirements. You do need to consider my point on how your fileserver will work. Does the Overland handle this well? Also how does the Overland handle HA? It seems that good HA is one of the big things you pay for with the expensive SANs. Dont just assume that you can buy a Overland and then the QNAP for a backup SAN as depending on the protocols used this may not be possible.

[dhicks]

Best I know of is share level replication (ie DFS), and that wouldn't really suit.

 

Third-party software to replicate Windows harddrives? A very quick Google search turns up SteelEye DataKeeper Cluster Edition, although with no details on price - I'm sure there must be other options available, and it'd be worth looking at if it could save you having to buy two SAN devices. That should give you the support you need - all your hardware can still be bought from HP, and you could buy software along with a support agreement.

[dhicks]

rsync is capible of duplicating block devices now isnt it?

 

I think you still need to apply the "--copy-devices" patch separatly, I don't think the feature has made it in to the "proper" version of rsync yet.

 

It rather depends on what kind of backups you want - what kind of service level / level of rubustness you would like to provide. For mirroring of file servers I'd use DRBD to replicate block devices over the network in real time - everything that gets written to one server's storage gets written to another's. If one server falls over the mirror can be up instantly, or maybe within a minute or two, depending on what hardware you're running on (I think you need identical processors to be able to do near-instant failover of VMs - probably easier to just boot a new instance of the file server VM on the mirror server). This, obviously, implies having a second chunk of storage sitting around not doing very much most of the time (other than using up power), which a lot of schools would probably see as overkill.

 

For versioning of files, I'd use rsync to sync two servers, then have a deduplicating script run on the backup server to replace duplicate files with hard links to a common file. Both rsync and such a deduplicating script would work fine on Windows. The files would be shared the same as on the original server, with the same users able to read files, but no-one able to write - this share could then be mounted as a Windows drive, and any time people needed to restore a file they could just go and copy-and-paste it over to their normal workspace. This implies having a chunk of storage available that's larger than the original - the larger, the further back you'll be able to keep versioning. rsync would probably run once a night - you could stop file-sharing services first (or shutdown the file server, snapshot, and reboot) to ensure all files were in a consistant state while rsync ran.

 

For backups of VM images, and anything else you wanted placed on removeable media and taken offsite or into a firesafe, I'd shutdown the server, snapshot, reboot and rsync (with --copy-devices) to the removeable media.

 

Either way its not masively complicated but IME it is way above alot of peoples heads

 

Are there no front ends available to make setting up DRBD mirrored easier? If not, that's a potential gap in the storage market there - systems that can do fully replicated storage, with excellent local disk performance for your VM images, but at less cost than a SAN. It just needs a nice management front end that gets the concept across clearly - most people do seem to be rather stuck on the idea that they must have a SAN.

Edited February 20, 2011 by dhicks