VMware Workspace Portal (http://www.vmware.com/products/workspace-portal) is one of the key products VMware has in the EUC suite. It has gone through several iterations, and arrived at it’s current state. I have seen it since it was 1.0, and in September 2014, 2.1 was released with lots of improvements.
Prior to 2.1, workspace was a vApp made up of at least 5 virtual machines, all based on SUSE Linux. When 2.1 was released, the architecture was simplified, to just start with 1 VM. This made the deployment much simpler, and also eliminates the actual “vApp” configuration. In turn, this also makes backup & recovery, as well as SRM replication much easier to handle for workspace.
One other piece of news which was announced around the same time is that the VMware vFabric Postgres (sometimes also called vPostgres) is no longer available as of the 1st September 2014. Existing customers will continue to receive support, but no new licenses can be purchased. Details can be found at the two URLs below.
- http://www.vmware.com/products/vfabric-postgres
- https://www.vmware.com/support/policies/product-eoa
This is a concern because Workspace is only supported with two databases, vPostgres and Oracle. Most customers I meet are Microsoft SQL shops, and almost never have Postgres in the environment, and a few would use Oracle. With vPostgres going EOA, this means that production deployments are left with only Oracle as the database to use.
For those who knows something about Workspace, it comes with a built in Postgres database, and it used to be meant for quick deployments for use with POC, or test environments. With vPostgres going away, the guidance changed, and I am happy to have learnt that we can now use the internal database for production deployments.
There were two main reasons why external databases were strongly recommended for production deployments
- was that the databases could be setup with good database clustering and protection
- when we want to do N+1 deployment with workspace appliance, the other appliances would have to point to a common database
Just recently, the guidance has changed, we can now use the internal database for production deployments and we can setup database replication as well. A VMware KB article has been published with the steps to do this, and a VMware Blog post created to illustrate the process.
I’m sure the official documents will be updated in due time, but it now means the following database configurations would be supported for production deployemnt
- Postgres built into Workspace – as a standalone instance
- Postgres built into Workspace – as a replicated database instance for high availability
- External vPostgres – as before (if you have license and support)
- External Oracle – as before, no change here