Book Image

Learning VMware vRealize Automation

By : SRIRAM RAJENDRAN, Sriram Rajendran
Book Image

Learning VMware vRealize Automation

By: SRIRAM RAJENDRAN, Sriram Rajendran

Overview of this book

With the growing interest in Software Defined Data Centers (SDDC), vRealize Automation offers data center users an organized service catalog and governance for administrators. This way, end users gain autonomy while the IT department stays in control, making sure security and compliance requirements are met. Learning what each component does and how they dovetail with each other will bolster your understanding of vRealize Automation. The book starts off with an introduction to the distributed architecture that has been tested and installed in large scale deployments. Implementing and configuring distributed architecture with custom certificates is unarguably a demanding task, and it will be covered next. After this, we will progress with the installation. A vRealize Automation blueprint can be prepared in multiple ways; we will focus solely on vSphere endpoint blueprint. After this, we will discuss the high availability configuration via NSX loadbalancer for vRealize Orchestrator. Finally, we end with Advanced Service Designer, which provides service architects with the ability to create advanced services and publish them as catalog items.
Table of Contents (15 chapters)
Learning VMware vRealize Automation
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Index

vRealize Orchestrator high availability mechanism


VMware vRealize Orchestrator nodes update their heartbeat in the database every 5 seconds. The default number of missed heartbeats that indicates a problem on a node is 3 heartbeats.

If a vRealize Orchestrator node has a problem and stops the heartbeat, vRealize Orchestrator is aware that its heartbeat has stopped. When the heartbeat entry in the database is not updated, other vRealize Orchestrator nodes in the cluster will know that the heartbeat of the node with a problem has stopped.

When the timeout is reached, the following happens:

  • The vRealize Orchestrator node with the problem disappears from the Started Cluster Nodes section under the Server Availability option in the Orchestrator configuration page

  • The other vRealize Orchestrator nodes in the cluster determine that it is nonresponsive and take over the workflows

  • Once the server is ready to be brought online after fixing the issue, it's recommended to restart the impacted Orchestrator...