Compellent Live Volume

I just thought I would put a post up about Compellent Live Volume.
We now utilise Live Volume for our SQL and we are soon to implement it as part of our Hyper V 3 setup.
I remember when I was researching Live volume and it wasn’t clear exactly what it did and how it worked.
Even when I did the Compellent Admin course it still wasn’t completely clear.
Now I have actually implemented it I can shed some light on the subject.

What does Live Volume do?
It allows a Volume to be hosted on multiple SANs at the same time.
It allows an administrator to designate which SAN the volume is active on – e.g. we need to do maintenance on SAN A so lets make it active on SAN B instead.
It can automatically change which SAN the volume is active on based on the amount on I/O, so the volume is optimally placed.

What does Live Volume not do?
Automated disaster recovery – if you have a SAN failure there is no guarantee the data will be 100% up to date on the replica SAN and the migration to secondary SAN can only be done with the help of Co-Pilot. This is a dodgy game to play as when the failed SAN comes back online it will be out of date but consider itself primary and any changes since Co-Pilot made the other SAN primary could get lost. That is why they don’t let you do this yourself!!!

so what does this look like:

So in this example we have a single server mapped to multiple SANs. In this case this behaves very similarly to a standard replicated volume but with one very helpful difference.
Lets start with the volume being “Live” on SAN A. The volume is mapped and the writes are all sent to SAN A. any changes are replicated across a suitably large replication connection (FC, FCoE or iSCSI). If we need to perform maintenance on SAN A we can make the volume active on SAN B, during this operation the Compellent may actually send some of the operations over the replication link until the path becomes active from Server A to SAN B.
This is really cool as we can now perform all sorts of maintenance on the SAN without scheduling outages for the services provided on Server A.

This may be all some of us want to do but I would wonder who would architect this kind of solution? Normally the servers are cheaper and more likely to fail or need schedule maintenance (patches, firmware etc) and SANs are expensive, more resilient and can be updated online.
I would suspect anyone who can afford two SANs and Live Volume licenses will probably be doing something a little more complicated.

lets look at our old SQL Geo-Cluster:

We have two server and two SANs in a geographically dispersed cluster.
We use EMC Mirrorview to replicate the data.
as part of the cluster we had to add in some software called Mirrorview/CE (Cluster Edition).
this forms a cluster resource and controls on which SAN the volume is active.
this means if we want to fail over from one SAN to another we have to take the cluster resource and associated services offline. The advantage to this in (in theory) if we did have a SAN failure then the cluster would failover and CE would make the other SAN live, I had no way of testing this without pulling the power from the SAN and I guessed I would never find out if it worked.
Unfortunately I was wrong. We had a bit of an incident with a contractor servicing our fire suppression system and we temporarily lost a datacentre. I can say from experience that I had to wait for the SAN to come back up and Mirrorview to get back in sync before the failover would work. I am sure I could have called EMC support and asked them to promote the volume, but there goes my single advantage to the EMC approach. I learned from this episode that Live Volume and CE are similar in the downsides but Live Volume is better in day to day use.

So what does this look like now we utilise Live Volume;
remarkably similar, just replace the words EMC CLARiiON with Compellent.

Whats the difference I hear you ask,
based on a standard MS cluster, not a lot. The SQL instance is active on either Server A or B. We now find the strange situation where we control where the data is processed using Microsoft Clustering and where the data is being accessed using Compellent Enterprise Manager. Although confusing this does allow us to migrate from one SAN to another without doing a cluster failover. Also we can set Live Volume to automatically change the SAN active SAN for each volume based on I/O usage. it’s all good.

Everything so far is based on traditional clustering with a single server accessing a single volume.
that’s not really the case any more as Linux, VMFS or Microsoft CSV allow multiple servers to access the same volume.
so what does this mean to live volume. quite simply it means that theoretically Live Volume is the future for multi site volumes.
We can now have multiple servers in different datacentres accessing the same volume, then based on which servers are using the most I/O the volume will be moved to the optimal SAN.
The I/O is redirected from the passive to the active SAN through the replication link and this is what allows the live volume role swap.
let me build our 8 node multi site Hyper V 3 using Live Volume environment and I will update as to how well it works.

Change the on screen keyboard to extended mode

the registry entry for this is
HKCU\Software\Microsoft\TabletTip\1.7\ShowAuxPad
and the type of value is a REG_DWORD
setting this to 1 (decimal) will change to extended mode.
I needed to do this for a specific application that needed page up and page down functionality.
I used a group policy preference and it worked perfectly.

Migrate vSphere 5 to Hyper V 2012 Part 2

Now you all know what I am up to lets look at the first technical design challenge: Networking.

I am very familiar with network configuration from the ESX/ESXi world but after some research it seems that I may need to reconsider all of this when changing hypervisor.

My first decision is the number of network cards to procure for the servers. Our existing vSphere networking follows the older convention of 2 NICS for vCenter/Management 2 NICS for vMotion and 2 NICS for Production traffic, as they are hosted in a blade centre we dont have dedicated DRAC/BMC as this is handled directly from the bladecentre chassis.

Now not only do I have to consider a change in hypervisor I also must consider the use of Converged Newtworking for our FCoE implementation.

We are moving away from the bladecentre architecture for a couple of key reasons;
1. We were never really large enough to justify more than 1 bladecentre per datacentre
2. Adding hosts later was more complex as we filled the bladecentre from day 1 so we deliberately upgraded the hosts that what we had rather than buy standalone or another very low population blade centre.
3. I dont like risk, having all the servers in a bladecentre – no matter how reliable, it seems risky to me.

We are a Dell house so that leaves us with some options. Our optimum configuration due to existing Windows Server Datacentre licensing is 4x 2 socket servers with 256/512GB RAM – whatever we can afford!
I suspect we will end up with R720 as we have a number of R710 and R720 and they have all served us well.
We always purchase a DRAC Enterprise card for support reasons and that will be 1GB connected to a dedicated DRAC switch.

Now the fun begins.

Migrate vSphere 5 to Hyper V 2012 Part 1

I am undertaking a project to migrate our existing vSphere 5 environment to Hyper V 2012.

We have decided that the licensing and associated support costs for VMware are so high in comparison to Hyper V that we would rather spend the money on better hardware rather than licenses for more memory!

The current environment is made of 16 Dell Blades; 8 in one room and 8 in another as DR using SRM. The storage is FC using 4 Brocade 300 switches (2 in each room with ISL trunks to merge the fabric) and one EMC CX4-240 SAN in each datacentre. The current environment hosts about 120 VMs but we are beginning to hit memory contention issues.

Over the last few years we have been researching and implementing other technologies to prepare us for this move. We are lucky enough to be using Cisco Nexus 5010 switches in both Datacentres and we recently purchased FCoE licenses and 2232 Fabric extenders. Along with VSS Core and VPC configuration of the Nexus switches we are now able to run 10GB Networking and FCoE in a merged fabric across the two datacentres.

The procurement of a Dell Compellent SAN was the last piece of the jigsaw and we are planning to use Compellent Live Volume to change our existing live and DR environments over to a completely active-active arrangement with spare capacity for the most critical services.

Now the fun begins researching, testing, evaluating, purchasing and implementing the solution.

Win 7 Tablet – Show the on screen keyboard

I have had to do some SCCM Task sequence and Group policy work to make a Panasonic tablet play nicely with Windows 7. One setting that I found essential but that was poorly documented was how to show the on screen keyboard at login. Eventually with some digging and testing I found the setting:

HKLM|SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\ShowTabletKeyboard
I created a new OU  and an associated Group Policy for the Tablets and set the value of this to 1 using group policy preferences and happy days the on screen keyboard is ready to use at login.

Server Naming Convention

I have worked at a lot of different organisations and working at an IT outsourcer and one thing that seems to always suprise me is the poor naming of servers.

I always think that the key purpose of a server name is to make it easily identifiable and unique. When I first started my current job I had inherited a naming convention based on the genious idea of servername-rack start location-rack end location-operating system-operating system version.

As I am sure you can imagine the server name were not exactly intuitive!

The real problem came when we decomissioned a Server room and moved all of the servers, suddenly a naming convention based on location when the location had changed became unmanageable. Then we started virtualizing!

We started by thinking about what is important to us for easy identification and had a rule of thumb not to use more than 3 letters for any part of the name.

We decided to put a 2 letter company name abbreviation at the start as this would be very useful in seperating new servers from old and would be invaluable in the case of any mergers or co-hosting.

Department name is important to us so again we worked out a number of 2 and 3 letter abbreviations for these.

Then we came to the use, for this we used sensible names as follows:

EX – Exchange

AS – Application

DC – Domain Controller

WEB – Web Server

VM – Hypervisor

DB – Database

We then append a number to then end to make it unique.

If we cluster we then add a letter starting from A onwards depending on the number of nodes.

So we end up with a maximum of 11 letters and numbers, we can virtualize, move location and co-host without affecting the convention.

How to Disable Java Auto Update

One problem I come across a lot if software that tries to auto update itself. As I work on corporate computers this is normally not possible due to a lockdown policy disabling the users from installing software, a proxy that disables the download of this software and policies from suppliers mandating a specific version of the software.
I have found the best way to disable Java from updating itself is to use a group policy preference to control the following registry entry:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy\EnableJavaUpdate
this is a DWORD and should be set to a value of O (Decimal).
This will disable the option to autoupdate in the control panel applet (if the user can even see it) and disable all updating. you can check the change has applied because the control panel applet now looks like this without the update tab:

Welcome to the Blog.