Monday, May 11, 2015

Hyper-V DR build out

So we are getting ready to ramp up our disaster recover build out. We have recently completed a SAN migration and have now begun the process of building out our DR capabilities. The question came up as to how we would facilitate a failover of the VMs. To give a little background. We have an EMC VNX 2 in our primary data center and we are in the process of moving our old VNX to our DR site.  We will be replicating between the sites using recover point. 

After kicking around some ideas of how we could use these existing tools and the capabilities of Hyper-V I think I have come to a solution.  Since all of the VHD files we be replicating to our DR site and we will have some hosts thee on standby I though couldn't I just script the import of the vms through PowerShell. This would allow me to take the vms as they stood in production and bring them online at DR in the event of a disaster.  So as long as the primary site is offline the servers could come up and run at the DR site.  To make this easier we can extend the network to the DR site so the ips would not need to change and this would make the transition quicker.  

So then I thought how do we fail back. So in theory the vms will be replicating back to the primary site when it becomes available.  All of the files will become current on production.  At this point if I shut down all of the vms running at DR,allow the replication to complete, and then turn them back on at the primary site they should pickup right where they left off at DR.  

In theory it should work. So we are putting together a test to prove everything out.  As we work through it I will be looking for places to automate parts of the failover. Probably using some orchestrator run books or trying some things with Azure. I will keep track of  our progress here and document this out as we go.  I am open to feed back if anyone has any ideas or has already been through this. I am sure there are other solutions using addition technology but this is what I have to work with, and make it work I will.

Thursday, May 7, 2015

PowerShell unplugged at Ignite

I am sitting in the Windows PowerShell unplugged with Jeffery Snover.

Lots of cool tips and tricks for PowerShell.  

Pester is an open source test platform for PowerShell.  It is currently being expanded by Microsoft currently to add some more features.  

PowerShell v5

Introduces package management and repositories.

Classes are introduced inv5.


Nano Server
This is an even more trimmed down type of core system. There is no gui and no console. It is only managed remotely.  The total install size is 410MB.  This is manages through PowerShell remote as well as through your remote management GUIs on your local machine.

This can be used for Hyper-v, IIS, Fileserver ...







Hyper-V

When we first started with virtualization in our environment it was pretty small scale.  Gradually we have expanded and grown our environment.  At this point it is rare that we are adding a physical server to serve any other purpose then to act as a host for more virtual machines.  Currently we have close to 175 virtual machines running across 5 hyper-v Cluster ranging from Windows 2008R2 to Windows 2012R2.  With the availability of Windows Server 2016 Technical preview 2, we are starting to kick it around.

Based on some of the things I have heard at Microsoft Ignite 2015, there are some compelling reasons to move to the new version when it becomes available sometime next year.  

One of the most notable things I have seen with Server 2016 is the enhancements with regards to.   storage and storage management.  Server 2016 introduces Storage Replica and Storage QoS.  In regards to Hyper-V Storage QoS will allow you to manage your storage performance between VMs that reside on a shared LUN.  This can give you more flexibility when you are planning out your storage requirements.

After I go through my notes I will post some additional items specifically from the Ignite conference.