HPE SimpliVity
1748073 Members
5223 Online
108758 Solutions
New Discussion

Moving Simplivity Host to another Cluster

 
kmsj13
Occasional Advisor

Moving Simplivity Host to another Cluster

Hi Everyone, 

Our customer have two existing servers with different Cluster (One HPE-Simplivity for each Cluster), then they requests to make it in one cluster to make it High Available, they also provided new vCenter Server for the new setup. I followed this https://community.hpe.com/t5/HPE-SimpliVity/Can-we-manually-add-the-host-into-the-new-vCenter-if-the/td-p/7024327 . But after joining the two omnistacks on the same cluster, there was a prompt of "SimpliVity OmniCubes Not Together In Cluster" . What missing steps do i need to do?

 

Please see svt-federation-show below:

 

 

 

8 REPLIES 8
JohnHHaines
HPE Pro

Re: Moving Simplivity Host to another Cluster

I don't know what you did to"join" the two nodes, but I suspect it was not done the right way. My apologies if I am wrong, if so please provide some detail on how you did this.

You cannot "merge" or "split" a cluster. The underlying SimpliVity object store is a complex distributed file system, and there is no way to join two separate object stores (created when you deployed the first node in each cluster) together.

The only way to add a node to an existing cluster is to re-deploy it. Simply moving the server object in vCenter is not sufficient. That's because vCenter (and ESXi) don't know anything about the SimpliVity Object Store, and while they will appear to be in the same cluster, they do not share a common SVT Object Store.

Re-deploying a node will wipe it, and re-install both ESXi and SimpliVity.

I would open a Support call, because you are at risk of data loss, but I suspect the way to fix this is:

- move the DR node back to the DR cluster (however you moved it in the first place)

- use the SimpliVity Move feature to move any VMs on the DR node that you want to keep to the Production Node

- remove the DR Node form the SVT Federation

-re-image the DR node using the Deploy Image from the software bundle

- re-deploy using Deployment Manager

If there is no data on the node you want to keep, you could skip moving it back, but if you plan on using the same IPs you will have to delete the server from the Federation database and vCenter.

The only way to add a node into an existing cluster is to deploy it using Deployment Manager, and you can only do that with a node that has been imaged with the Deployment Image - you can't do it with an installed and configured node.


I work for HPEAccept or Kudo
MikeSeden
HPE Pro

Re: Moving Simplivity Host to another Cluster

As per engineering the proper way to move a node is a svt-federation-remove, then a full factory reset and redeploy. I would open a support ticket. But as to HA... (my opinion)

SimpliVity is by nature of its design, Fault tolerant in the VMware sense. so you have two fault tolerant nodes running the exact same to achieve High Availability. HA = 2 times resources for each HA VM. I would not put both hosts in HA but would allow Simplivity to do what it does naturally and put only the VM's that needed to be absolutly always up into HA. Remember VMware is not aware of what Simplivity does. Each VM has a primary and secondary copy (VM+2=3) and when the copies are running as basically 'HA' already you tend to eat up processor when doubling that effort.

 


While I am an HPE Employee, all of my comments (whether noted or not), are my own and are not any official representation of the company
Accept or Kudo
kmsj13
Occasional Advisor

Re: Moving Simplivity Host to another Cluster

Thank you for your answers and suggestions, those existing servers doesn't have any VMs right now. 

kmsj13
Occasional Advisor

Re: Moving Simplivity Host to another Cluster

 I would not put both hosts in HA but would allow Simplivity to do what it does naturally and put only the VM's that needed to be absolutly always up into HA. 

 

I would like to clarify on this matter, Is there a feature on Simplivity to automatically restart the Fault VMs from the other nodes of the cluster?  

 

JohnHHaines
HPE Pro

Re: Moving Simplivity Host to another Cluster

No, we use and support the underlying Hypervisor feature, in this case vSphere HA, to do that.

I don't see the point of building a cluster and NOT enabling HA, but maybe that's just me. I want the automatic restart of VMs in the event of a failure, and the 9-5 maintenance window, that HA gives me. However, SimpliVity certainly gives you that flexibility.


I work for HPEAccept or Kudo
MikeSeden
HPE Pro

Re: Moving Simplivity Host to another Cluster

In reply to your question "Is there a feature on Simplivity to automatically restart the Fault VMs from the other nodes of the cluster?" The short answer is yes. VM ware has 2 classifications Fault Tolerant and High Availability.  Fault Tolerant is when a VM goes down on a node, another copy of that VM will very quickly come up on that node or on another node depending on how the policy is configured for VM ware. High availability means there are Identical VMs running, 1 active, 1 inactive, always exchanging data so that if the active VM goes down, the inactive takes over instantly (or close to it). They can be on the same node or different nodes like Fault tolerant, depending on the policy set up in VMware. Most people use different nodes for both for redundancy. I am attaching 2 documents that shows how simplivity stores and manages data. Basically it is the same as VMwares Fault tolerant, but other virtualization solutions call it High Availability.

https://damianerangey.com/2018/07/20/how-virtual-machine-data-is-stored-and-managed-within-a-hpe-simplivity-cluster/

https://damianerangey.com/2018/08/29/how-virtual-machine-data-is-stored-and-managed-within-a-hpe-simplivity-cluster-part-2/

Simplivity creates 2 copies of the VM the primary on the same node as the VM and the secondary on the other node. The information written to the VM is deduped to the Primary and secondary copies so they all know the same thing. The copies are just that, copies. If the VM goes down, the primary copy will spin up in a minute or so, all data written to VM stored in Simplivity cache so when VM copy comes up there is no data lost. If the Node goes down and the secondary doesn't hear from the other node, It will come up, become the primary copy and the VM will come up from it,once again no data lost and very quickly. It is basically the same as Fault Tolerent in VMwares terms, but in routing and switching and most other places its called High availability. 

Back to my original point in VMware when you run HA you have 2 VMs running with I/O using CPU and power, one active one not. This is the reason I said high availability is 2 times the compute. When the Simplivity solution is installed on VMware it has to talk to the VCSA to work. The Omnistack Virtual Controller is in charge of the VMs on the host. VMware has no idea what Simplivity is doing so while it does VMware fault tolerant automatically, people tend to create policies in VMware that do what simplivity is already doing. Simplivity balances is load and storage out automatically with in the cluster. When you set VMware up to move machines around as space is needed it tends to counrteract simplivity's efforts and problems arise.

VMware is a virtualization platform.  Simplivity will run on Hyper V as well. It is a hyperconverged solution, basically a data center in a box. Use the virtualization platform in the solution, dont use the solution in a virtualization platform.

Hope this helps-


While I am an HPE Employee, all of my comments (whether noted or not), are my own and are not any official representation of the company
Accept or Kudo
scott_svt
Frequent Advisor

Re: Moving Simplivity Host to another Cluster

There is some unclear information here, so I'll just clarify a few terms:

1. Storage HA - This is the SimpliVity functionality that ensures that there are two copies of the data within a cluster, i.e. two replicas on two nodes within the cluster. NOTE: The arrangement of primary/secondary copies of the data is on a per-VM not per-node basis., i.e. one node is not a mirror of another. This functionality does not replace any VMware functionality as this functionality has nothing to do with compute.

2. vSphere HA - This is the standard VMware functionality that ensures that a VM is restarted on another node in the case of a failure. In our case, if a node fails, all VMs that are running on that node will be powered up on the other node in the cluster that has a copy of the data. As per @JohnHHaines, there is no good reason to not enable this functionality.

3. Fault Tolerance - This is the standard VMware functionality that allows you to have two 'live' copies of the VM in a active/standby pair. The standby VM will take over should the active VM fail, as the two copies are in lockstep.

@kmsj13: Regarding your actual issue, as has been said before, it is not actually possible to merge or split clusters even within the same federation. What you currently have is two nodes in the same compute cluster, but different storage failure domains and this in not a valid state. You need to pick one node to be the seed for your Federation and redeploy the other node. You should also then enable vSphere HA, but I assume you were planning on doing that anyway. As above, Storage HA and vSphere HA complement each other. One does not replace the other.


Accept or Kudo
MikeSeden
HPE Pro

Re: Moving Simplivity Host to another Cluster

Thanks Scott! I was thinking backwards again.


While I am an HPE Employee, all of my comments (whether noted or not), are my own and are not any official representation of the company
Accept or Kudo