Upgrading VMware Mirage to 4.3

I’ve been waiting for a while for version 4.3 to come out for some interesting features some of my customers would be able to leverage, but I never thought I would be so surprised once I got to understand how to do it.

Essentially, there is no upgrade procedure, you just uninstall and reinstall the components just as they were before by using installer files from the 4.3 version.

Yes, I know, I thought the same but I can say that in the end it just seems to work. Even if there is no orchestration of a version upgrade that checks things around before proceeding I have to admit that the ease of operations is pretty nice.

Preparations steps are simple, just make sure you have the following written down:

  • Database server name
  • Credentials for the database server
  • Horizon Mirage server cache directory location
  • Cache size

Then just stop all Mirage services, snapshot all volumes, backup your DB and you’re done. A more detailed procedure can be found here but there is really not much more than that.

Now to the upgrade (or should I say reinstall?), the only thing to remember is that the order of operations must be respected:

  1. Select Control Panel > Add or Remove Programs to uninstall the system components.
  2. Uninstall all Horizon Mirage servers.
  3. Uninstall the Horizon Mirage Management console.
  4. Uninstall the Horizon Mirage Management server.
  5. Uninstall Horizon Mirage WebAccess.
  6. Use the new mis files to install the latest version of Horizon Mirage.
  7. Install the Horizon Mirage Management server.
  8. Install the Horizon Mirage Management console.
  9. Install the Horizon Mirage servers.
  10. Install Horizon Mirage WebAccess.

You will need to reboot the server after step 9.

A neat thing is that you won’t need to do anything to update your Mirage clients because once they contact the server they will self-upgrade with no downtime for the user. I just wish it would be possible to suppress the balloon notification that informs users about the upgrade or the possibility to decide when user clients will be upgraded.

I used this procedures twice on simple single server implementations and I had no issues.

Even if I would prefer a real upgrade procedure, in the end of the day i just want upgrades to work and this seems to be the case with Horizon Mirage, so no complains.

Advertisements

Configuring redundancy for Horizon Workspace Virtual Machines aka How To Scale Horizon Workspace

Horizon Workspace can scale to many thousands of users, but obviously you are going to need more than just the mere default setup with 5 virtual machines if you want to get there.

As an example let’s take VMware own internal implementation for 13.000+ users so we can see how does Horizon Workspace scale:

  • 1x Configurator VA is used. 2vCPU, 2G Memory
  • 6x Connector VA is used. 2 vCPU, 4G Memory
  • 4x Gateway VA is used: 2 vCPU, 8G Memory
  • 2x Service VA is used: 2vCPU, 6G Memory (1 for HA)
  • 11x Data VA is used: 6 vCPU, 32G Memory
  • 2x Postgres Server is used: 4 vCPU, 4G Memory (1 for replication)
  • 3x MS Office Preview Server: 4vCPU, 4G Memory

VMware Architectural Diagram

As you can see most components can scale to many units, except the configurator-va. The configurator-va is a single point of administration when it comes to configuring your Horizon Workspace environment and it cannot be redundant.

Note: If you intend to increase the capacity of your Horizon Workspace virtual machines don’t forget to adjust the java heap size for improved performance.

In order to add a new virtual machine of any type, you must log in to the configurator-va virtual machine as root user and run the following command:

hznAdminTool addvm –type="VMType" --ip="new VM ip address"


This command can be executed only after the Horizon Workspace setup has been fully completed and you have tested that the solution is working.

The new virtual machines will have to follow the same requirements regarding IP addresses as the base virtual machines. For an overview of these requirements check “How to install Horizon Workspace using an external database”.

For Connector and Data virtual machines, this command creates the new virtual machine by cloning a base snapshot of the original virtual machine of the same type. The base snapshot is captured for all virtual machines during the initial deployment. The command fails if the base snapshot does not exist.

For service and gateway virtual machines, this command creates the new virtual machine by cloning the current virtual machine snapshot.

Let’s dig into details about having multiple instance of each type of virtual machine.

Note: The following commands, unless specified otherwise, must be executed on the configurator-va.

Multiple gateway-va
Companies can deploy multiple gateway-va in order to distribute load on more than one virtual machine thus providing both redundancy and scalability for this role. This is usually the first role that you want to make redundant since it’s the entry point for all users.

The specific command to add a gateway-va is as follows:

hznAdminTool addvm –type=GATEWAY --ip="new VM ip address"


Multiple service-va
You might want to add another service-va for the same reasons of the gateway-va.

Note: In order to add more service-va you must be using and external database.

The specific command to add a service-va is as follows:

hznAdminTool addvm –type=APPLICATION_MANAGER -- ip="new VM ip address"


Now connect to https://ConfiguratorHostname, open the System Information page and note how both the old and new service-va are listed and also how the new service-va is in maintenance mode. Before proceeding verify that the virtual machine was added correctly by checking the IP address.

We are going to need to open some firewall ports on all service-va, as referral for the coming configs use these:

iptables -A INPUT -i eth0 -s "OTHER_service_va_IP" -p tcp --dport
9300:9400 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -s "OTHER_service_va_IP" -p tcp --sport
9300:9400 -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -s "OTHER_service_va_IP" -p udp --dport
54328 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -s "OTHER_service_va_IP" -p udp --sport
54328 -m state --state ESTABLISHED -j ACCEPT

Now we need to do the following to open firewall ports:

  • Run hznAdminTool listvms command to list service-va virtual machines.
  • Write down only the service-va virtual machine IP addresses.
  • Log in to the service-va virtual machine for IP address1 as root and go to the console.
  • Run the iptables command and use IP address2 as the value for the “OTHER_service_va_IP” parameter.
  • Log in to the service-va virtual machine for IP address2 as root and go to the console.
  • Run the iptables command and use IP address1 as the value for the “OTHER_service_va_IP” parameter value.

Next we need to run the following commands on all service-va:

service elasticsearch stop
hznAdminTool configureElasticSearch -ES_MULTICAST_ENABLED true service elasticsearch start
service elasticsearch status


And run the following commands only on the new service-va:

service rabbitmq-server stop
service elasticsearch stop
rm /var/run/rabbitmq/pid
rm /var/run/rabbitmq/lock
rm /var/run/elasticsearch/elasticsearch.pid
rm /var/lock/subsys/elasticsearch
rm -R /db/rabbitmq/data/*
rm -R /db/elasticsearch/*
service rabbitmq-server start
service rabbitmq-server status
rabbitmqctl stop_app
rabbitmqctl force_reset
rabbitmqctl start_app
hznAdminTool configureElasticSearch -ES_MULTICAST_ENABLED true service elasticsearch start
service elasticsearch status

Finally go to https://ConfiguratorHostname/cfg and click “Exit Maintenance Mode” on the newly added service-va. The Configurator updates all the gateway-va virtual machines and starts sending requests to the new
service-va virtual machine as well.

Multiple connector-va
Creating multiple connector-va will allow you to reduce traffic and reduce downtime. Other than that, creating multiple connector-va will enable you to use multiple means of authentication such as Active Directory user and password, RSA SecurID passcode or Kerberos-based Windows authentication. To enable multiple forms of authentication, you must set up multiple connector-va virtual machines.

Image

Depending on the type of authentication, you deploy a new connector-va in a different way. This subject will require a new post by itself but you can find details now in the Horizon Workspace Documentation Center.

Multiple data-va
User accounts are provisioned to a specific data-va virtual machine that handles their file activity. It is recommended that each data-va virtual machine serve no more than 1000 users, so you need to scale if you have more than that. When you add a new data-va virtual machine, the new data-va virtual machine automatically becomes available from the default COS host pool. The host pool for other classes of service that are created displays the new data-va virtual machine, but it is not enabled in that COS. To use a new data-va virtual machine in the other classes of service, the administrator must modify the COS and enable the data-va virtual machine.

The first data-va virtual machine in the Horizon Workspace configuration is the master node. This node contains the metadata for the data-va virtual machine user accounts. If you create additional data-va virtual machines, these data-va virtual machines are file stores only. When the master node is down, users cannot log in to their data accounts.

You can configure the host pool in the COS to use specific data-va virtual machines. In this way, you can manage where accounts are provisioned. For example, you add a second data-va virtual machine because disk space on the first data-va virtual machine is low. You do not want the first data-va virtual machine to be provisioned with any more new accounts once you have added the second node. From the Horizon Workspace Administrator Web interface, edit each COS to select the new data-va virtual machine in the Host Pool and deselect the other data-va virtual machine.

The specific command to add a data-va is as follows:

hznAdminTool addvm –type=DATA --ip="new VM ip address"


Note: Don’t forget to configure preview on each data-va.

Now the new data-va is in maintenance mode, to complete adding a new data-va do the following:

  • Restart each existing data-va
  • Log in to each data-va virtual machine as the root user to generate ssh keys
  • Reboot each data-va

The on each data-va:

su - zimbra
/opt/zimbra/.ssh/authorized_keys/zmupdateauthkeys
/etc/rc.d/memcached restart

Now go to https://ConfiguratorHostname and click “Exit Maintenance Mode”.

The new data-va virtual machine is ready to use.

Update: In Horizon Workspace 1.5 the base snapshot of the data-va is not used anymore to create other data-va. In order to create more data-va you have to create a “New datava-template Virtual Machine”.

Disclaimer: In this article i pasted parts of the official documentation.

Understanding Horizon Workspace components and installation prerequisites

In the last post i described in details how to prepare a vPostgres DB to host Horizon Workspace external database.

During the installation process, as we will see, you can choose to use an internal database or an external one but keep in mind that the internal database is ment only for testing purpose so if you are installing Horizon Workspace in a production environment you must have a VM with vPostgres installed as this is the only supported configuration, so you can understand why the first post was needed.

So now we are ready to install Horizon Workspace… well, not quite yet. It is very important to understand that to install this product there are number of preparation steps that need to be taken before actually getting our hands dirty and start having fun. Some of those steps include filling up some technical prerequisites and some are just decisions that need to be taken keeping in mind that during the installation phase there are some settings that cannot be changed afterwards unless redeploying the entire solution. This is something you definitely don’t want to find out after you’ve performed all the installation and configuration tasks and then have to start over again.

In this post we are going through all the prerequisites so with that out of the way we will be able to easily proceed with the deployment phase, but first let’s talk about the Horizon Workspace virtual appliances and their respective functions. The following is taken from the official documentation.

  • VMware Horizon Workspace Configurator Virtual Appliance (configurator-va): You start configuring Horizon Workspace with this virtual appliance, using both the Configurator virtual appliance interface and the Configurator Web interface. The configurations you make with the Configurator are distributed to the other virtual appliances in the vApp. Note: The configurator-va is the only component that cannot scale to multiple instances.
  • VMware Horizon Workspace Manager Virtual Appliance (service-va): Horizon Workspace Manager handles ThinApp package synchronization and gives you access to the Administrator Web interface, from which you can manage users, groups, and resources.
  • VMware Horizon Workspace Connector Virtual Appliance (connector-va): Horizon Workspace Connector provides the following services: user authentication (identity provider), directory synchronization, ThinApp-catalog loading, and View pool synchronization.
  • VMware Horizon Workspace Data Virtual Appliance (data-va): Horizon Workspace Data Virtual Appliance controls the file storage and sharing service, stores users’ data (files), and synchronizes users’ data across multiple devices.
  • VMware Horizon Workspace Gateway Virtual Appliance (gateway-va): Horizon Workspace Gateway Virtual Appliance is the single endpoint for all end-user communication. User requests come to the gateway-va virtual machine, which then routes the request to the appropriate virtual appliance.

System and Network Configuration Requirements
The preparation part is the longest and most important when deploying a distributed service such as Horizon Workspace, for this reason VMware prepared a detailed checklist to fill up before starting the installation process. The following is a list of all the things you will have to decide and mark down:

  • Horizon Workspace Fully Qualified Domain Name (FQDN)
  • Network Information for Configurator (configurator-va)
  • Network Information for Manager (service-va)
  • Network Information for Connector (connector-va)
  • Network Information for Data (data-va)
  • Network Information for Gateway (gateway-va)
  • Network Information for IP Pools
  • Active Directory Domain Controller
  • SMTP Server
  • vCenter Credentials
  • SSL Certificate (Optional)
  • Horizon Workspace License Key
  • Microsoft Windows Preview
  • External Database

Before getting into details let’s take a high level look at the architecture of Horizon Workspace as it’s meant to be in a production environment:

Image

This picture (which is taken straight from the public documentation of the product) shows that every connection from users accessing the Horizon Workspace portal have to go through the Horizon gateway VM(s). The “(s)” easily shows how you can have one or multiple Horizon gateways, in which case you will also need some sort of load balancing mechanism in front of the gateways. The Horizon gateway virtual appliance runs nginx as web server that basically proxies every connection to the desired service so users actually need connectivity only to the gateways virtual appliances.

IMPORTANT: Placing the gateway VA in a separate network such as a DMZ network is not a supported configuration.

The following picture gives a better understanding of the network configuration requirements:

Image

As you can see all communication go into the gateway VA and out to the other virtual appliances which are actually providing the services. Users will connect exclusively in HTTPS and the same is true also for most of communication between virtual appliances, so we will need to work a bit on SSL certificates at some point but it’s not mandatory in the setup phase as you can see form the above list since it is marked as optional in the prereqs.

Horizon Workspace FQDN
Choosing the FQDN is a tricky one because once you input it during the setup you can’t go back and change it, so it definitely deserves some thinking or you might find yourself redeploying from scratch. Most companies choose to have the same FQDN for both internal and external connections which makes it perfectly transparent for users to reach Workspace no matter where they are located; obviously the FQDN will resolve with a public IP for external users and with a private IP for internal users, hence the need of two sets of load balancers as you can see in the first picture.

Network configuration for virtual appliances
Just write down TCP/IP configurations that you intend to assign to the five virtual appliances, including DNS configuration. I encourage you to use consecutive addresses for simplicity.

IP Pools
Honestly this is a little obscure to me. IP Pools are used as a set of IP addresses that you define and assign to a network in vCenter so that they can be used when you deploy a vApp. Funny is the fact that those addresses must not be the ones you will use for setting up the virtual appliances. Even funnier is the fact that if you deploy the vApp from the Web Client you don’t even have to create an IP Pool. I have no problems admitting my ignorance here on the usefulness and meaning of this step.

Active Directory Domain Controller
Self explaining. Since Horizon Workspace integrates with your Active Directory you will need to have IP address, basic parameters and credentials handy during the setup. Just keep in mind that your users in AD will need to have Name, Last Name and email address compiled before importing them in Horizon Workspace or the import will fail.

SMTP Server
This is used by users when sharing documents. Note that you must specify a working SMTP since a check is performed during the setup and you won’t be able to proceed otherwise.

vCenter credentials
If you are deploying Horizon Workspace I’m pretty sure you have these. 🙂

SSL Certificate (optional)
I like to deal with this after the initial deployment and this is another tricky one, so during the setup we will use default self-signed certificates for simplicity.

Horizon Workspace Product Key
Yes, you need one. 🙂
For a proof-of-concept you can request a trial key that will work for 100 users.

Microsoft Windows Preview
When using Microsoft documents in Horizon Workspace web portal you can get a preview without having Microsoft Office installed. The preview can be generated with a LibreOffice add-on that runs directly on the data-va or they can be generated on a Microsoft Server with Microsoft Office installed; the first is a free option and it’s usually good enough, the latest will grant you a higher level of compatibility but you will have to pay Microsoft licenses.

External Database
If you read my last post you should know about this already.

Now that you have all handy you are ready to install Horizon Workspace.

%d bloggers like this: