In the previous article we deployed our appliances. Before to go live, we are going to update some settings and update the self-signed certificates with CA-signed certificates. With that done, we will connect both appliances together, which will allow replications to be configured between the appliances.
Remark: the certificate update only makes sense if you already configured CA-signed certificates for your other vSphere components (have a look here if you want to update the certificates of the vCenter Server Appliance). If you didn’t, and don’t plan to do it, just skip this step!
In the first part of our article series, we had an overview of the vSphere Replication inner workings and studied several typical implementation designs. In this second part we will deploy the vSphere Replication Appliance on two sites: the production site and the disaster recovery site.
You can certainly remember that each appliance comes with a management part and the vSphere Replication engine itself. In our scenario, only the disaster recovery site requires the two components, and the production site would be happy with the management server only. However, both components are bundled together in the appliance, therefore there will be no difference in the deployment procedure for each site. Let’s proceed!
In this first vSphere Replication article we will have an overview of the product: how does it work? What are the components? After this overview, we will show several possible vSphere Replication designs.
In part 3, we finished the setup of our appliance. But if we really want a polished installation we still have a “little” thing to do: replace the self-signed certificates by certificates signed by our internal Certificate Authority.
Let’s be honest: replacing certificates for the vSphere platform has always been a mess (to say the least) ! But thanks to the great work of Michael Webster and Derek Seaman, things got better! First, they produced clear procedures to replace the certificates. Then Derek went a step further and wrote a powershell script that automates the first part of the process (certificate generation).
In parallel, VMware greatly improved its own documentation (… maybe with the support of the two guys above 🙂 ), and even has a tool which can update certificates on some VMware products… But not the vCSA!
Let’s sum it up: we are still waiting for the perfect tool, but in the meantime, there are clear (but lenghty 🙂 ) procedures to update the certificates. And so… Let’s do it!
In Part 2, we left our vCSA in a running state, technically ready for managing ESXi servers in production. In a small environment or a test lab, we could stop there. But for an appliance that is going to manage a production virtual infrastructure, we could improve our setup a little bit.
In this article, we are going to configure an SMTP server and implement monitoring for the appliance’s database disk.