As part of a recent vSphere 5.5 deployment, I installed a small vSphere Replication 5.8 proof-of-concept for the customer to trial site-to-site replication and get their minds around how they can do some simple DR activities. The appliance is fairly simple to deploy, so I thought I’d just provide a few links to articles that I found useful. Firstly, esxi-guy has a very useful soup-to-nuts post on the steps required to deploy a replication environment, and the steps to recover a VM. You can check it out here. Secondly, here’s a link to the official vSphere Replication documentation in PDF and eBook formats – just the sort of thing you’ll want to read while on the treadmill or sitting on the bus on the way home from the salt mines. Finally, if you’re working in an environment that has a number of firewalls in play, this list of ports you need to open is pretty handy.
One problem we did have was that we’d forgotten what the password was on the appliance we’d deployed at each site. I’m not the greatest cracker in any case, and so we agreed that re-deploying the appliance would be the simplest course of action. So I deleted the VM at each site and went through the “Deploy from OVF” thing again. The only thing of note that happened was that it warned me I had previously deployed a vSphere Replication instance with that name and IP address previously, and that I should get rid of the stale version. I did that at each site and then joined them together again and was good to go. I’m now trying to convince the customer that SRM might be of some use to them too. But baby steps, right?
Note also that, if you want to deploy additional vSphere Replication VMs to assist with load-balancing in your environment, you need to use the vSphere_Replication_AddOn_OVF10.ovf file for the additional appliances.
A colleague of mine has been doing some data centre failover testing for a customer recently and ran into an issue with VMware’s Site Recovery Manager (SRM) 5.8 running on vSphere 5.5 U2. When attempting to perform a recovery, and you’re running Linked Mode, and the protected site is off-line, the recovery may fail. The upshot of this is “The user is unable to perform a recovery at the recovery site, in the event of a DR scenario”. Here’s what it looks like.
I don’t know what to say about this. I’d like to put the boot into whomever at VMware is responsible for this SNAFU, but I’m guessing that they’ve already had a hard time of it. At least, I guess, there’s a workaround, if not a fix. But you’d be a bit upset if this happened for the first time during a real failover. But that’s why we test before we handover. And what is it with everything going pear-shaped when Linked Mode is in use?
*Update – 29/10/2015*
Marcel van den Berg recently pointed out that updating to SRM 5.8.1 resolves this issue. Further detail can be found here.
EMC today announced their VSPEX BLUE offering and I thought I’d share some pictures and words from the briefing I received recently. PowerPoint presentations always look worse when I distil them down to a long series of dot points, so I’ll try and add some colour commentary along the way. Please note that I’m only going off EMC’s presentation, and haven’t had an opportunity to try the solution for myself. Nor do I know what the pricing is like. Get in touch with your local EMC representative or partner if you want to know more about that kind of thing.
EMC describe VSPEX BLUE as “an all-inclusive, Hyper-Converged Infrastructure Appliance, powered by VMware EVO:RAIL software”. Which seems like a nice thing to have in the DC. With VSPEX BLUE, the key EMC message is simplicity:
Simple to order – purchase with a single SKU
Simple to configure – through an automated, wizard driven interface
Simple to manage – with the new VSPEX BLUE Manager
Simple to scale – with automatic scale-out, where new appliances are automatically discovered and easily added to a cluster with a few mouse clicks
Simple to support – with EMC 24 x 7 Global support offering a single point of accountability for all hardware and software, including all VMware software
It also “eliminates the need for advanced infrastructure planning” by letting you “start with one 2U/4-node appliance and scale up to four”.
Awwww, this guy seems sad. Maybe he doesn’t believe that the hyperconverged unicorn warriors of the data centre are here to save us all from ourselves.
I imagine the marketing line would be something like “IT is hard, but you don’t need to be blue with VSPEX BLUE”.
VSPEX BLUE Software
VSPEX BLUE Manager extends hardware monitoring, and integrates with EMC Connect Home and online support facilities.
VSPEX BLUE Market offers value-add EMC software products included with VSPEX BLUE.
Automates cluster deployment and configuration, as well as scale-out and non-disruptive updates
Simple design with a clean interface, pre-sized VM templates and single-click policies
Resilient Cluster Architecture
VSAN distributed datastore provides consistent and resilient fault tolerance
VMotion provides system availability during maintenance and DRS load balances workloads
Software-defined data center (SDDC) building block
Combines compute, storage, network and management resources into a single virtualized software stack with vSphere and VSAN
While we live in a software-defined world, the hardware is still somewhat important. EMC is offering 2 basic configurations to keep ordering and buying simple. You getting it yet? It’s all very simple.
VSPEX BLUE Standard which comes with 128GB of memory per node; or
VSPEX BLUE Performance comes with 192GB of memory per node.
Each configuration has a choice of a 1GbE copper or 10GbE fibre network interface. Here’re some pretty pictures of what the chassis looks like, sans EMC bezel. Note the similarities with EMC’s ECS offering.
Processors (per node)
Intel Ivy Bridge (up to 130W)
Memory/processors (per node)
Four channels of Native DDR3 (1333)
Up to eight DDR3 ECC R-DIMMS per server node
Inputs/outputs (I/Os) (per node)
Dual GbE ports
Optional IB QDR/FDR or 10GbE integrated
1 x 8 PCIe Gen3 I/O Mezz Option (Quad GbE or Dual 10GbE)
1 x 16 PCIe Gen3HBA slots
Integrated BMC with RMM4 support
2U chassis supporting four hot swap nodes with half-width MBs
2 x 1200W (80+ & CS Platoinum) redundant hot-swap PS
Dedicated cooling/node (no SPoF) – 3 x 40mm dual rotor fans
Front panel with separate power control per node
17.24” x 30.35” x 3.46”
Integrated 4-Port SATA/SAS controller (SW RAID)
Up to 16 (four per node) 2.5” HDD
The VSPEX BLUE Standard configuration consists of four independent nodes consisting of the following:
The Performance configuration only differs from the standard in the amount of memory it contains, going from 128GB in the standard configuration to 192GB in the performance model, ideal for applications such as VDI.
VSPEX BLUE Manager
EMC had a number of design goals for the VSPEX BLUE Manager product, including:
Simplified the support experience
Seamless integration with EVO:RAIL and its facilities
The implementation of a management framework that allows driving EMC value-add software as services
Extended management orchestration for other use cases
Enablement of the VSPEX partner ecosystem
Software Inventory Management
Displays installed software versions
Discovers and downloads software updates
Automated, non-disruptive software upgrades
In my mind, this is the key bit of value-add that EMC offer with VSPEX BLUE – seeing what else is going on outside of EVO:RAIL.
Provides information not available in EVO:RAIL
Maps alerts to graphical representation of hardware configuration
Displays detailed configuration of hardware parts for field services
Aggregates health monitoring from vCenter and hardware BMC IPMI
Integrates with ESRS Connect Home for proactive notification and problem resolution
Integrates with eServices online support resources
Automatically collects diagnostic logs and ingrates with vRealize Log Insight
RecoverPoint for VMs
I’m a bit of a fan of RecoverPoint for VMs. The VSPEX BLUE appliance includes an EMC Recoverpoint for VMs license entitling 15 VMs with support for free. The version shipping with this solution also no longer requires storage external to VMware VSAN to store replica and journal volumes.
Protect VMs at VM-level granularity
Asynchronous and synchronous replication
Consistency group for application-consistent recovery
vCenter plug-in integration
Discovery, provisioning, and orchestration of DR workflow management
WAN compression and deduplication to optimize bandwidth utilization
One final thing to note – VMware ELAs not supported. VSPEX BLUE is an all-inclusive SKU, so you can’t modify support options, licensing, etc. But the EVO:RAIL thing was never really a good option for people who want that kind of ability to tinker with configurations.
Based on the briefing I received, the on-paper specs, and the general thought that seems to have gone into the overall delivery of this product, it all looks pretty solid. I’ll be interested to see if any of my customers will be deploying this in the wild. If you’re hyperconverged-curious and want to look into this kind of thing then the EMC VSPEX BLUE may well be just the thing for you.
We haven’t been doing this in our production configurations, but if you want to change the behaviour of SRM with regards to the “snap-xxx” prefix on replica datastores, you need to modify an advanced setting in SRM. So, go to the vSphere client – SRM, and right-click on Site Recovery and select Advanced Settings. Under SanProvider, there’s an option called “SanProvider.fixRecoveredDatastoreNames” with a little checkbox that needs to be ticked to prevent the recovered datastores being renamed with the unsightly prefix.
You can also do this when manually mounting snapshots or mirrors with the help of the esxcfg-volume command – but that’s a story for another time.