Can I migrate from a failover cluster... to itself? (SAN -> S2D)

[sonofsanta]

So after looking into replacing our existing virtual stack with new kit this summer, once the 5 year warranty is up, and finding out that pricing is not pretty right now with all the semiconductor shortages going on, a new and slightly insane possibility has presented itself: I get @ICTDirect_Dave to sell me a bunch of upgraded components for the current stuff and he'll rewarranty the lot, saving about 80% versus new and getting near the same (if not better) performance.

 

So, background: current kit is two HP DL360 G9s in a failover cluster connected to an HP MSA1040 SAN for the cluster shared volume. All running tickety-boo--even cluster aware updating works without a hiccup.

 

The plan would be that Dave sells me new CPUs, a bunch of RAM and some new storage, such that the only original components left are the mobo and PSUs (and, y'know, the case, but that's not likely to fail is it). He'll then warranty the lot for a fresh five years for me. The new storage would make an S2D pool and the SAN would go into retirement (impossible to change enough components in it that Dave will warranty it for me).

 

Now I know I can migrate from one failover cluster to another through SCVMM; I've done that before and it's dead easy. But with what I'd need to do here, I've got three specific questions:

• Will the failover cluster exist, temporarily, on mismatched hardware? I'd have to stick one node into maintenance mode, pull it out and swap the CPUs + upgrade the RAM + add the new disks, before I could bring it back online and migrate the VMs to do the other server. My understanding was always that nodes needed to be identical, but then I've only ever done it from scratch, so why wouldn't I buy identical nodes from the off.
  
• If and once the above is done, can I then do an in-place upgrade from Server 2012R2 -> Server 2019?
  
• Once I'm on 2019, can I then add the new local disks as an S2D pool and migrate my VMs from the SAN to the S2D pool? There is a "Migrate Storage" option in Hyper-V Manager but I don't know if it'll manage a move between technologies, or if it's just meant to move between volumes/pools.
  

 

It's definitely making work for myself doing it this way, but (a) it's interesting work, I'm always up for that (b) it could save about eighteen thousand pounds, and that is a lot of money. And if I come into work humming Hey Big Spender and plump for the 16C/32T Xeon Gold E5-2698-V3 CPUs at a bank-breaking £100 more each (oh no), it would actually work out more powerful than anything new I'm being offered for £20k+.

 

So I'm very tempted, but this might be a case of Matt Trying Too Hard to be Clever, which is never ideal. Is Dave a genius, or am I daft for even thinking this?

Edited May 24, 2021 by sonofsanta

[round2it]

Umm 2012 to 19 i think you might need to goto 16 first

[sonofsanta]

Umm 2012 to 19 i think you might need to goto 16 first

 

 

Probably, and I don't mind that too much, it's just whether I can do in-place OS upgrades on a cluster at all I'm unsure of!

[Primus]

You will need to go to 2016 as you can't add a 2019 server into a 2012 cluster.

 

To upgrade the node you'll have to evict it I believe.

[sonofsanta]

You will need to go to 2016 as you can't add a 2019 server into a 2012 cluster.

 

To upgrade the node you'll have to evict it I believe.

 

 

Answering my own question--there's this thing called Google, have you lot heard of it? I reckon it could be big--it looks like 2012R2 -> 2016 is the first path that allows for Cluster Operating System Rolling Upgrade. Pain to do it twice to get to 2019, but again, a pain that would save £18,000...

 

Answering my second question, too, I'm pretty sure it will exist temporarily on mismatched hardware, because I've done that before with mid-cycle RAM upgrades. Never done it with a CPU upgrade but if it didn't spit its dummy out at the first sign of heterogeneity, that's promising...

[Primus]

Again you should be fine with mismatched CPUs. You might need to check the box on the VM settings for processor compatibility if you want to live migrate.