{"id":71,"date":"2009-02-13T15:48:11","date_gmt":"2009-02-13T04:48:11","guid":{"rendered":"http:\/\/nsrd.wordpress.com\/?p=71"},"modified":"2018-12-12T16:33:28","modified_gmt":"2018-12-12T06:33:28","slug":"things-not-to-virtualise-backup-servers-and-storage-nodes","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2009\/02\/13\/things-not-to-virtualise-backup-servers-and-storage-nodes\/","title":{"rendered":"Things not to virtualise: backup servers and storage nodes"},"content":{"rendered":"

Note: It’s 2015, and I now completely disagree with what I wrote below. Feel free to read what I had to say, but then check out Virtualised Servers and Storage Nodes<\/a>.<\/em><\/p>\n

Introduction<\/h3>\n

When it comes to servers, I love<\/em> virtualisation. No, not to the point where I’d want to marry virtualisation, but it is something I’m particularly keen about. I even use it at home \u2013 I’ve gone from 3 servers, one for databases, one as a fileserver, and one as an internet gateway down to one, thanks to VMware Server<\/a>.<\/p>\n

Done rightly, I think the average datacentre should be able to achieve somewhere in the order of 75% to 90% virtualisation. I’m not<\/em> talking high performance computing environments – just your standard server farms. Indeed, having recently seen a demo for VMware’s Site Recovery Manager (SRM)<\/a>, and having participated in many site failover tests, I’ve become a bigger fan of the time and efficiency savings available through virtualisation.<\/p>\n

That being said, I think backup servers fall into that special category of “servers that shouldn’t be virtualised”. In fact, I’d go so far as to say that even if every other machine in your server environment is virtual, your backup server still shouldn’t be a virtual machine.<\/p>\n

There are two key reasons why I think having a virtualised backup server is a Really Bad Idea, and I’ll outline them below:<\/p>\n

Dependency<\/h3>\n

In the event of a site disaster, your backup server should be at least equally the first server that is rebuilt. That is, you may start the process of getting equipment ready for restoration of data, but the backup server needs to be up and running in order to achieve data recovery.<\/p>\n

If the backup server is configured as a guest within a virtual machine server, it’s hardly going to be the first machine to be configured is it? The virtual machine server will need to be built and configured first, then the backup server after this.<\/p>\n

In this scenario, there is a dependency that results in the build of the backup server becoming a bottleneck to recovery.<\/p>\n

I realise that we try to avoid scenarios where the entire datacentre needs to be rebuilt, but this still has to remain a factor in mind – what do<\/em> you want to be spending time on when you need to recover everything?<\/p>\n

Performance<\/h3>\n

Most enterprise class virtualisation systems offer the ability to set performance criteria on a per machine basis \u2013 that is, in addition to the basics you’d expect such as “this machine gets 1 CPU and 2GB of RAM”, you can also configure options such as limiting the number of MHz\/GHz available to each presented CPU, or guaranteeing performance criteria.<\/p>\n

Regardless though, when you’re a guest in a virtual environment, you’re still sharing resources. That might be memory, CPU, backplane performance, SAN paths, etc., but it’s still sharing.<\/p>\n

That means at some point, you’re sharing performance. The backup server, which is trying to write data out to the backup medium (be that tape or disk), is potentially either competing with for, or at least sharing backplane throughput with the machines that is backing up.<\/p>\n

This may not always<\/em> make a tangible impact. However, debugging such an impact when it does occur becomes much more challenging. (For instance, in my book<\/a>, I cover off some of the performance implications of having a lot of machines access storage from a single SAN, and how the performance of any one machine during backup is no longer affected just by that machine. The same non-trivial performance implications come into play when the backup server is virtual.)<\/p>\n

In Summary<\/h3>\n

One way or the other, there’s a good reason why you shouldn’t virtualise your backup environment. It may be that for a small environment, the performance impact isn’t an issue and it seems logical to virtualise. However, if you are<\/em> in a small environment, it’s likely that your failover to another site is likely to be a very manual process, in which case you’ll be far more likely to hit the dependency issue when it comes time for the full site recovery.<\/p>\n

Equally, if you’re a large company that has a full failover site, then while the dependency issue may not be as much of a problem (due to say, replication, snapshots, etc.), there’s a very high chance that backup and recovery operations are very time critical, in which case the performance implications of having a backup server share resources with other machines will likely make a virtual backup server an unpalatable solution.<\/p>\n

A final request<\/h3>\n

As someone who has done a lot<\/em> of support, I’d make one special request if you do<\/em> decide to virtualise your backup server*.<\/p>\n

Please, please<\/em> make sure that any time you log a support call with your service provider you let them know you’re running a virtual backup server. Please<\/em>.<\/p>\n

—
\n* Much as I’d like everyone to do as I suggest, I (a) recognise this would be a tad boring and (b) am unlikely at any point soon or in the future to become a world dictactor, and thus wouldn’t be able to issue such an edict anyway, not to mention (c) can occasionally be fallible.<\/p>\n","protected":false},"excerpt":{"rendered":"

Note: It’s 2015, and I now completely disagree with what I wrote below. Feel free to read what I had…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[13,16,17],"tags":[1241,1250,1084],"class_list":["post-71","post","type-post","status-publish","format-standard","hentry","category-general-thoughts","category-networker","category-policies","tag-architecture","tag-policies","tag-virtualisation"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-19","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/71","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/comments?post=71"}],"version-history":[{"count":2,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/71\/revisions"}],"predecessor-version":[{"id":7691,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/71\/revisions\/7691"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=71"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=71"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=71"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}