Saturday, February 29, 2020

VMUG Leader Summit 2020 - An Eastern European Point of View

I had the opportunity to be invited to VMUG Leader Summit 2020. It takes place at VMware headquarters in Palo Alto and it brings together people from all around the world that share common passions: technology and community.

VMware User Group (VMUG) leaders are defined by their willingness to put an extra effort into bringing together local communities to learn new things and to discuss technology with good and bad. The local meetings are places of new and open ideas, networking and even socializing. I have been volunteering for enabling these meetings for the past seven years, but until I started to meet leaders from other countries I haven't understood the full potential. First I met fellow leaders at VMworld. But the time allocated at that event was limited. However even a few minutes with someone can prove inspiring. But when the summit was organized and the chance to spend 2 days next to my peers, then a new world opened to my eyes.

I come from an Eastern European country having somewhere deep down the, let's say, small town complex as I've always been looking up to Western Europe/US modern cultures. IT came as an escape for me and I have been working in multi cultural/multi national environments for the past 12 years. I've been in contact with people from Eastern and Western Europe, Middle East, Asia, Australia and even US in both business and social circumstances. However I have never seen all of these cultures coming together in the same time at a single table. Seeing all those people from literally all around the globe talking, debating, having fun in the same place is what never ceases to amaze me and what the summit brings as a huge value.

This was my second summit. Last year I was thinking that I was so lucky to get a glimpse at the organizational culture of another company and to see so many inspirational people coming and talking to us. For this year I had no expectations since I've already seen the best. And it was the opposite. I was again surprised and got more inspired and awed by the people that make up an organization.

As you can easily understand the summit wins on two categories. It brings together people from corners of the world to meet each other face to face and exchange ideas, inspire and trust one another. I believe that no matter how easy is to have virtual meetings, a handshake or a look in the eye can make a difference. The second win from the summit: it brings people closer to values and culture of VMware by giving us, the community of users, direct access to its C-level executives and awesome technical staff. Now that is a hard thing to do and such a cool one, too.

Personally, as a VMUG leader and as a human being, I fell like I've grown a bit since this journey started and so much more in the past 2 years. I leave here a dear photo and challenge you to guess the number of countries and continents represented in the picture:

Thursday, February 6, 2020

Migrate vRealize Orchestrator 7.3 Cluster with External Database to 7.6

In every environment's life comes a time when you need to upgrade. So it did happen for our vRO setup. The source environment is running vRO 7.3.1 in a 2-node cluster and with and external MSSQL database. The target environment is a 2-node cluster running vRO 7.6 and internal PostgreSQL (since no external is supported).

Because source vRO is connected to external MSSQL server, in place upgrade is out of the question. So a migration is actually the only way to do it. A constraint for the migration is not to change hostnames or IP addresses. Well, the requirement is actually to get everything back to 7.6 with a minimum of reconfiguration and here we talk about plugins, workflows, actions, configuration elements, certificates and all that jazz.

Having laid down the task ahead we started working on the plan. And what we came up with was pretty interesting. 

vRO 7.6 appliance offers a migration tool that is accessible through VAMI. The tool needs access to source vRO and database. Since we have a 2-node cluster, we'll take advantage of that and do a rolling migration. Source vRO 7.3 cluster is made of nodes: node1 and node2. Target vRO 7.6 cluster will be running the same vRO nodes.

So how does this rolling migration look like:

In initial state there is a vRO 7.3.1 cluster with external MSSQL database. We start by redirecting traffic in load balancer to node1 and disabling monitoring on the pool. Then we break the cluster by removing node2 and powering it off. Next we deploy a new node2 running 7.6 and using the same hostname and IP address. If you want to reuse the same VM name, you just need to rename the old node in vCenter Server.

This takes us to intermediary state where we have one node1 in 7.3.1 and node2 in 7.6 with and embedded PostgreSQL DB. Once node2 in 7.6 is up an running, we connect to VAMI and fire up the migration tool. Migration tool will transfer all data from node1 and the external DB to node2. After vRO is migrated to 7.6, we proceed to power off node1 running 7.3.1 and deploy node1 in 7.6. Don't forget to switch over traffic to node2 in load balancer.

Now we are in final state where both nodes are running 7.6. Once node1 is up, we add it to the cluster that node2 is already member. The cluster is back and this time running vRO 7.6 with embedded PostgreSQL database. Simple, right?

Well, there are a few of gothcas:
- when running the migration tool, a pre-check is run that can fail if the vRO DB contains duplicates; it can be fixed by either removing duplicates from DB or connecting with vRO client to source vRO and renaming them
- SSL certificates are not migrated - you need to connect to source vRO keystore and export the certificates, then re-add them in control center
- there is a cumulative update that needs to be applied to the freshly deployed vRO 7.6
- dynamic types plugin configuration is not migrated - there is an updated plugin that needs to be installed
- in some cases you may need to update the appliance hardware including file system

Lastly enable traffic in load balancers to both nodes and re-enable health monitors. Do that after importing SSL certificate.

Happy migrations!