VMware Workspace ONE Community
Alethay
Enthusiast
Enthusiast
Jump to solution

Workspace Portal 2.1 redundancy

Hi everybody,

some question about redundancy of the new workspace portal.I'm pretty new on this product, i've installed the 2.0 version in a lab environment in semptember and the latest version a couple of weeks ago. Everything works fine with one VA, but when i cloned it for redundancy have got some problems. Suppose the VA is under a load balancer, the cloned vm must be a "full installation" clone or a "connector only" clone? If i use the first method (full clone) the "join domain" and "view pool" is disabled on the cloned VA, i must re-enable that? The cloned VA must be added as an IdP or is sufficient to set up the correct load balanced FQDN on both the VA? Last but not the least, the correct procedure to install the public certificate is:

1 - Install the certificate on both the VA and load balancer,

2 - Install the certificate only on the VA and copy the .pem file from VA to the load balancer?

I hope that all it's clear!

Thanks in advance

Ale

1 Solution

Accepted Solutions
admin
Immortal
Immortal
Jump to solution

Hi,

Most of the deployment cases can be fulfilled with "Complete/Full" installation of Workspace 2.1. "Connector-only" installation is required in case you have multiple AD's.

Here are the steps to setup redundancy with Workspace 2.1 -

1. Do a "Complete/Full" installation of Workspace 2.1 with an external database. Let's name this vm as ws1.company.com (a.k.a. ws1)

2. Set up your load balancer.

a. Update LB configuration to have a valid certificate. Keep the root-ca of the LB certificate handy, you will need this later.

b. Configure the LB to forward requests to ws1 host.

c. Install the workspace root-ca on the LB provided by this url: https://ws1.company.com/horizon_workspace_rootca.pem

3. Go again to https://ws1.company.com:8443/cfg/ssl, click on "Terminate SSL on Load Balancer" tab. In the text-box below, enter the root-ca of LB and save the configuration.

4. Go to https://ws1.company.com:8443/cfg/workspaceUrl tab. Enter the LB url, e.g. https://lb.company.com:443. Save the configuration. After this step, you should be able to login to workspace using the https://lb.company.com as the url.

5. Now in order to add redundancy. Clone the VM ws1 (do not power on the vm after clone).

6. Edit this new vm's properties to set new IP address. Now, power on the VM. The VM should come up fine with new hostname, say ws2.company.com. If you go to https://ws2.company.com:8443, it should serve you a certificate with CN=ws2.company.com.

Note:

    • If ws1 was configured to join a domain, and/or do view sync, xenapp sync, directory sync, etc, all of these will be disabled.
    • No need to add this new VM as IdP.
    • Sync's should be enabled on only one VM.
    • If Kerberos was enabled on ws1, it will be disabled on ws2. You will have to manually go and configure Kerberos on ws2 node. Only this time you will need the new vm to join domain. Otherwise, you won't require the new vm to join domain.

7. Update the LB to also include this new VM, i.e. ws2 in it's forward lookup. Now if you remove the first VM, i.e. ws1 from LB lookup, you should be able to login to workspace using the https://lb.company.com url.

Let me know if you have any more questions.


Thanks

~ Devang

View solution in original post

8 Replies
admin
Immortal
Immortal
Jump to solution

Hi,

Most of the deployment cases can be fulfilled with "Complete/Full" installation of Workspace 2.1. "Connector-only" installation is required in case you have multiple AD's.

Here are the steps to setup redundancy with Workspace 2.1 -

1. Do a "Complete/Full" installation of Workspace 2.1 with an external database. Let's name this vm as ws1.company.com (a.k.a. ws1)

2. Set up your load balancer.

a. Update LB configuration to have a valid certificate. Keep the root-ca of the LB certificate handy, you will need this later.

b. Configure the LB to forward requests to ws1 host.

c. Install the workspace root-ca on the LB provided by this url: https://ws1.company.com/horizon_workspace_rootca.pem

3. Go again to https://ws1.company.com:8443/cfg/ssl, click on "Terminate SSL on Load Balancer" tab. In the text-box below, enter the root-ca of LB and save the configuration.

4. Go to https://ws1.company.com:8443/cfg/workspaceUrl tab. Enter the LB url, e.g. https://lb.company.com:443. Save the configuration. After this step, you should be able to login to workspace using the https://lb.company.com as the url.

5. Now in order to add redundancy. Clone the VM ws1 (do not power on the vm after clone).

6. Edit this new vm's properties to set new IP address. Now, power on the VM. The VM should come up fine with new hostname, say ws2.company.com. If you go to https://ws2.company.com:8443, it should serve you a certificate with CN=ws2.company.com.

Note:

    • If ws1 was configured to join a domain, and/or do view sync, xenapp sync, directory sync, etc, all of these will be disabled.
    • No need to add this new VM as IdP.
    • Sync's should be enabled on only one VM.
    • If Kerberos was enabled on ws1, it will be disabled on ws2. You will have to manually go and configure Kerberos on ws2 node. Only this time you will need the new vm to join domain. Otherwise, you won't require the new vm to join domain.

7. Update the LB to also include this new VM, i.e. ws2 in it's forward lookup. Now if you remove the first VM, i.e. ws1 from LB lookup, you should be able to login to workspace using the https://lb.company.com url.

Let me know if you have any more questions.


Thanks

~ Devang

pbjork
VMware Employee
VMware Employee
Jump to solution

Please note we have a Hands-On Lab covering many common tasks in Workspace Portal 2.1.. Taking the HOL is absolutely free of charge and well worth for you to check-out.. Announcing the availability of the new and improved Workspace Portal Hands-On Lab. | Horizon Tech Bl...

Alethay
Enthusiast
Enthusiast
Jump to solution

Thank you everybody, i'll test that configuration soon and post the result.

Meanwhile this is another helpfull article for me about the availability of workspace database due to the EOA of vFabricPostgres

http://kb.vmware.com/selfservice/microsites/microsite.do?cmd=displayKC&docType=kc&externalId=2094258...

0 Kudos
Alethay
Enthusiast
Enthusiast
Jump to solution

Some feedback about my recent test. At customer site everything works fine also with embedded database, configured following your wonderfull blog.

Instead in my lab environment i receive an error during FQDN changing  "Error validating workspace url"

DNS lookup works fine, no firewall between client and workspace virtual appliance vm, certificate verification  through curl command is OK.

Here an extract of configurator.log

2014-12-22 15:32:33,981 WARN  (tomcat-http--41) [;;] com.vmware.horizon.admin.auth.WorkspaceAuthenticationProvider - password authentication failed: Exception while verifying pw info for user admin@admin : mac check in EAX failed

2014-12-22 15:32:50,840 ERROR (tomcat-http--19) [;;] com.vmware.horizon.svadmin.service.ApplicationSetupService - Error validating workspace url.

Any suggestion are appreciated

Thanks a lot

Ale

0 Kudos
admin
Immortal
Immortal
Jump to solution

Hi,

I would need some more information to troubleshoot.

What type of LB are you using? What certificate is installed on the LB, is it self-signed or third-party? When you hit the LB url from browser, does it forward the request to the Workspace vm?

What is the output of following two curl commands -

1. Run this from Workspace vm: curl -v https://lb-hostname/SAAS/API/1.0/REST/system/health

2. Run the same curl from a machine other than Workspace vm and LB.

Could you please gather all logs from /opt/vmware/horizon/workspace/logs directory. You can email them to me @ shahd@vmware.com.

Thanks

0 Kudos
Alethay
Enthusiast
Enthusiast
Jump to solution

Hi Shahd,

the load balancer is Citrix Netscaler VPX, with a self-signed certificate installed on it. When i hit the load balancer URL i receive the right certificate but the request wasn't forwarded to workspace VA and i think is it normal until the FQDN isn't changed, does it correct?

In attachment the results of curl command and the requested log file.

0 Kudos
admin
Immortal
Immortal
Jump to solution

Hi Alethay,

The LB should be configured to forward requests fo the Workspace before changing FQDN. That's what point 2-a says. This is required because during FQDN change, the Connector will reach Service to update IdP configuration.

Thanks

Devang

Alethay
Enthusiast
Enthusiast
Jump to solution

Sorry Devang, my load balancer configuration is not correct! Now it works!

Thanks a lot

Ale

0 Kudos