Synergy composer v1 migrations

[DelMagna]

Hi all

I'm hoping to be migrating a pair of v1 composers to v2 soon and would like to ask the wider community to share their experiences and issues if possible. I can follow the HPE guide, but have heard that the guide may have errors in the procedures and so wanted to ask for any real-world experiences on the procedures.

This is a two frame environment so I have unused composer slots and would plan to install the v2 modules into these to re-image these with the same OV version as v1 composers ahead of doing the composer migration work

Has anyone had any major issues that have caused a service disruption??

thanks Del

[MV3]

Hello,

There are no errors in the procedure. We have thoroughly tested these configurations, documented them, and they are widely referenced by customers worldwide. You can proceed with implementing them.

Refer HPE Synergy Migration Guide for Migrating HPE Synergy Composers and HPE Synergy Frame Link Modules : https://www.hpe.com/psnow/doc/a00090518en_us.

Cheers...

[PatrickLong]

@DelMagna The documentation is pretty good and I've been through this 3 times, but watch out for this possible snafu - when you get to the point that you are creating the manual backup of the C1 environment to then re-apply to your C2 env of identical Oneview version (page 24 step 5), make SURE you know exactly what characters you are entering in the Password textbox - because there is no "confirm" textbox/string compare in that backup GUI.

[DelMagna]

@PatrickLong  - many thanks for the infomation. I will make sure I use something simple that isn't prone to typos.

From reading through the migration guide I can see there seems to be an option to restore the OneView backup before re-adding the composer network settings or alternatively to add the network settings before restoring the backup. I will be doing this local to the frames, so will have the option of either but wanted to ask if, in your experience, you favor one over the other?

Also - what is the value in removing the standby appliance before shutting down? Why not just shutdown the appliances so they remain a cluster pair?

I assume without OneView able to alert of any issues during the migration, the only way to ensure the environment is remaining in a healthy state is from other application - eg vCenter alerts etc.

Have you ever experienced any concerning issues or alerts during\after any migrations you have done previously?

thanks again

DM

[DanCernese]

"Also - what is the value in removing the standby appliance before shutting down? Why not just shutdown the appliances so they remain a cluster pair?"

because they will not come back up in a cluster.  the cluster technology is not designed that way.  having the standby removed also eliminates several corner-case scenarios where the standby might accidentally take over and try to be the active or at least they might both say "we don't know who is master".  removing it elminates complexity.

[DelMagna]

Hi @DanCernese 

Thanks for the reply and that makes sense now.

In your opinion is there a preference on whether to apply the composer IP settings before or after restoring the backup? 

And (outside of restoring the incorrect backup!) is there any other scenario's that could result in the active configuration being overwritten or impacted in any way that could result in the compute modules suffering a service outage? Perhaps firmware related?

thanks

[DanCernese · Accepted solution]

In your opinion is there a preference on whether to apply the composer IP settings before or after restoring the backup? 

There are two processes purely because working in a datacenter is physically stressful in many locations (noise, seating, temperature).  It really depends on where you want to work; the choice is do most of the work physically local or remote.

And (outside of restoring the incorrect backup!) is there any other scenario's that could result in the active configuration being overwritten or impacted in any way that could result in the compute modules suffering a service outage? Perhaps firmware related?

.Only if there was already a latent issue.  It is exactly the same process as if you restarted the Composers with respect to existing configurations.  Just to be more comfortable, you could restart them and let the whole startup & refresh process completely finish.  Things only "happen" if the Composers have a configuration that is different than it detects when it refreshes all the components.

[DelMagna]

Hi @DanCernese 

Thanks for the extra advice - it proved useful.

The migration completed pretty much without incident - an initial issue when the new composer2 didn't recognise the USB during the reimage process (luckily I had another USB that worked fine).

The only bit of unexpected behavior was the below appliance alert - showed up about 1Hr after the migration completed. It may not be related but I don't know what it means or it's impact and also can't fully understand what the resolution is telling me to do. The Alert is as follows:

The AMQP server certificate used in the communication between the appliance and external clients listening to SCMB notifications from the appliance is invalid.

Resolution If the appliance certificate is CA-signed, generate the appliance certificate using "Create appliance self-signed certificate" from the action menu in the Settings->Security page. Then, use the DELETE /rest/certificates/ca/default REST API. Download the newly generated AMQP certificates to the external clients listening to SCMB notification from the appliance, if any. Refer to the section describing state-change message bus notifications for external clients in the product user guide for detailed steps.

Is this alert to be expected when migrating composers? Or probably unrelated?

We does use selfsigned certs so I can follow the resolution to create a new one, but then not sure about the next bit using the REST API command. How and where do I do this?

As far as I know we're not using any external clients listening to status change message bus traffic - or could this be the iLO on the Compute Nodes?

Any ideas on how to clear this alert would be greatly thanked