Virtual Failback

  • Comments posted to this topic are about the item Virtual Failback

  • The one way direction is one of the concerns that I had in experimenting in my own time. So much so that I either bare metal or cloud host but nothing in between.

    I am sure that for some people that their roles demand a more intimate knowledge and finer grained solutions but until I come across a need I cannot fight the flow towards cloud so am stuck in bare metal or a one way journey to cloud hosted and nothing in between.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • One of my instances is on a VMWare host with between 40-70 guests. I get sub-second response from a 3TB database. But that's certainly due more to tuning than to the environment, and I'm at the mercy of whatever gets V-motioned to the host.

    One guest on a host? Why wouldn't you just dedicate the HW to the instance?

  • For V2P I would use ShadowProtect headstart restore. Restore backups on to the bare metal server all the way to the latest incremental while the VM is still in production. Schedule the migration outage at which point you power down the VM, apply any subsequent up-to-date incrementals to the bare metal, apply Hardware Independent Recovery (driver replacement), finalise partitions and then boot.

    The key to migrations are having the right tools and testing.

    There are plenty of reasons to use a hypervisor when there is only a single virtual machine. Besides the obvious management and hardware abstraction benefits, a major case for this today is to support legacy operating systems of which 2003 resides. There aren't too many current generation server vendors which supply system drivers let alone technical support. I recently had a client who still uses SQL 2000 on top of Server 2003 R2 and installing ESXi was the only choice.

    I manage a few bare metals vSphere clusters (bare metal servers) at SoftLayer for a video conferencing service for our clients with a VPN back to our data centre (hybrid environment, more lingo). We did that primarily due to the benefits a Tier 1 data centre brings. We didn't have the bandwidth to supply such a service. A fibre Ethernet service where we are located in Australia would cost more than the hardware alone making it uneconomical. Definitely capital expenditure is a thing of the past. A business can always form a lease agreement with a financier and pay for data centre equipment as an annuity. Having a mix of on-premise and cloud infrastructure (Iaas/PaaS/SaaS) in a hybrid environment. makes sense to get a nice balance between cost and control.

  • VMWare works great as far as I am concerned.

    To your point about running a single guest on one host - while you certainly can do this, if you are having performance issues, there is no guarantee this will make a difference.

    Why? Well in our environment, our hosts have something like 192GB of ram, and I believe at least 32 cores. That is enough to run a LOT of guests. Yet we still see issues at times. We have found that it is not usually an issue with the number of guests, in fact we rarely would have more than 2-3 high demand guests on a host like that.

    So where is the issue? Well everywhere of course! Network, storage, VMWare cabinet configuration, the list goes on.

    Why are we seeing issues? Because keeping a VMWare certified engineer requires paying them. Today if you can spell VMWare, someone will hire you. You are certified, great, you are even more in demand. We have gone through at least six VMWare certified engineers in the past 5 years or less. Not a single one was in the position for 12 months. While all of them were very good, you don't become an expert in weeks or months, it takes time to develop experience.

    Now it may make sense to put a single guest on a host, but if you do so, use it as a troubleshooting step. Do things drastically improve? Maybe your hosts are overstressed. If things don't improve markedly, start looking at other things inside VMWare and your infrastructure.

    I expect things are similar with other brands.

    Dave

  • One of the main reasons to virtualize is high availability, which means the possibility of vMotioning your VM to a different host. If you have a single VM that's a DB with lots of RAM and CPU on one host, then you have to keep another similar host idling to receive that huge VM. I'm guessing that would not fly in most environments - certainly not where I work.

    I'm not a vmWare engineer, but I believe there are ways to provision CPU, disk and memory to insure that your DB has what it needs. Having said that, it is important to balance the other VM's on that host and not over-provision.

  • To answer the original question, build a new VM Machine and spec it accordingly. Setup Log shipping, Mirroring or AlwaysOn. Fail it over and monitor performance. If not happy with performance fail it back, reassess and try again.

    This is the best way to mitigate risk around migrating to virtual if you are unsure about the performance of a particular database. I wouldn't do this for all databases, only the ones which you had a concern with.

    You can also enable hot pluggable cores and memory on the VM, only had to use this once during a migration from Physical to Virtual in the above manner. This was more of a result of the application/database upgrade we did in conjunction with the migration to Virtual.

    We have a pretty good VMware setup and we find that we can usually reduce CPU core count to half that of the physical server. Currently running about 600 instances of SQL on Virtual with only about 4 instances still physical, all ranging is size from MB's to Multi TB's. We run up to 40 SQL Servers on a single physical VMware host, depending on environment (dev, test, prod) and performance requirements.

    From a SQL availability perspective we have more problems with the remaining physical servers due to hardware faults than we do with all the virtual servers.

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply