kentoh - Fotolia


Hyper-converged platform integration challenges

Integrating a hyper-converged platform into your computing environment is an issue for many data centers. Explore possible roadblocks and tools to aid the process.

One thing we expect from a hyper-converged system is the removal of the storage silo. But if the hyper-converged platform can't be integrated into the existing infrastructure, a new silo can be created: the hyper-converged platform itself.

One of the first places to integrate a hyper-converged system is with the existing virtualization platform. The simplest integration method is to enable virtual machine (VM) migration to the new platform. Longer-term integration will be important if the hyper-converged platform is not a complete replacement for existing platforms. There are two fundamental design options:

  • Target only greenfield deployments and ignore migration completely.
  • Acknowledge that existing VMs, hardware and management should be integrated.

Hyper-converged platform hypervisor integration

A hyper-converged platform may use a hypervisor that hasn't been used in the existing environment. For example, Scale Computing's HC3 and Nutanix Acropolis platforms use the KVM hypervisor, while most enterprises use vSphere. If a new hypervisor is introduced, VMs can't be migrated seamlessly to the new platform and will need fundamental changes such as new configuration files, a new storage location and new hypervisor drivers in the guest OS. This is far more intrusive process than simply moving to new storage with the same hypervisor.

If existing storage is on a Fibre Channel network, it typically can't be made available to hyper-converged systems because they usually only speak IP storage: NFS, iSCSI or SMB3.

Nutanix has promised automated tools to ease this migration process to its new platform. Every VM will likely be shut down for a while when the hypervisor is changed. Migrating from one hypervisor to another can also require a lot of late nights and long weekends for the project team, so this additional cost will need to be accounted for when evaluating a hypervisor change. It may outweigh the license cost savings you will achieve.

If the hyper-converged system uses the same hypervisor, it becomes a story of storage access. Existing hypervisors will need access to the hyper-converged storage or hyper-converged servers will need access to the existing storage. If existing storage is on a Fibre Channel network, it typically can't be made available to hyper-converged systems because they usually only speak IP storage: NFS, iSCSI or SMB3. Usually, the hyper-converged storage can be presented to the legacy hosts.

At least one vendor allows external hypervisors as an ongoing part of its offering. These compute nodes access the hyper-converged storage in the same way they would use any other IP storage. Other vendors suggest external servers for migrating existing VMs to the hyper-converged platform and require VMs to be entirely on their hardware platform.

If legacy hosts will access hyper-converged storage, it's a good idea to use 10 Gigabit Ethernet -- 1 GbE is probably too slow for production workloads. You may choose to simply upgrade one legacy host and use that as a swing host. Every VM migrating from old to hyper-converged would pass through the swing host as part of the migration.

Management options in a new hyper-converged architecture

Managing existing and new platforms from the same hypervisor management tool will aid migration. But this is further complicated if you also change hypervisors, since there are very few cross-hypervisor management platforms. Ensure your chosen hyper-converged platform allows management to be integrated.

If management isn't integrated, your migration planning will be more complex. For example, VMware's EVO:RAIL hyper-converged platform must be managed by its own vCenter instance, rather than using an existing vCenter. This is a platform designed for greenfield deployment. There appears to be no simple way to migrate running VMs from another vSphere environment to an EVO:RAIL deployment. That's not to say it is impossible, just more complex than migrating existing VMs to another hyper-converged platform.

Once you have thought through the storage and management integration, VM compatibility is next on the list. Does the hyper-converged platform use a CPU that is compatible with the existing hosts? You may need to implement features like VMware's Enhanced vMotion Compatibility (EVC), which makes newer CPUs look like older CPUs to the VMs, allowing vMotion onto the newer hosts. Once all the VMs are migrated to the hyper-converged platform, the CPU features can be upgraded on the cluster.

Deploying a hyper-converged infrastructure is a big change in the data center. Depending on the level of change, you may get more or less integration with your existing platform. The more integration you have, the easier it is to transition from the old platform to a hyper-converged one. The trickiest part is if the hyper-converged platform becomes a new silo because the environment isn't fully hyper-converged.

Next Steps

Ensure quality performance when integrating a hyper-converged platform

Setting up your hyper-converged configuration: Universal steps

Hyper-converged storage: Some assembly may be required

Dig Deeper on Hyper-Converged Infrastructure Implementation