You can use the following information specific to disaster recovery for vRealize Log Insight 3.3.0 by using Site Recovery Manager.

Guidelines for Protecting vRealize Log Insight

To guard against expensive data center downtime, use the following guidelines for disaster recovery operations.

  • Allocate enough resources at the protected and recovery sites. Verify that enough CPU resources and storage are allocated to protected and recovery sites, because some of the operations of disaster recovery setup are resource intensive.
  • vRealize Log Insight does not support quiesced snapshots. If you are using a disaster recovery tool that supports quiesced snapshots, make sure to disable quiescing.
  • The choice of replication type is critical when you are configuring any virtual machine for disaster recovery. Consider Recovery Point Objective (RPO), Recovery Time Objective (RTO), Cost and Scalability when you are planning the replication type to use.
  • Use static IP addresses for all nodes in a vRealize Log Insight cluster.
    • Using static IP addresses eliminates the need to update the IP addresses of vRealize Log Insight cluster nodes each time the IP address of a vRealize Log Insight node changes. 
    • vRealize Log Insight includes all node IP addresses in each cluster node configuration file at /storage/core/loginsight/config/loginsight-config.xml#<n> where <n> is the largest number.
    • Some products that integrate with vRealize Log Insight to feed their logs, use a fully qualified domain name (FQDN) or IP address as the syslog target. For example, vSphere ESXi, vSphere, and vRealize Operations Manager use the nodes of the cluster master's or the load balancer's (if configured) FQDN or IP address as the syslog target.
  • Use an FQDN for all nodes in the vRealize Log Insight cluster. 

    • For the master node, when you use a load balancer, a fully resolvable FQDN is required. Otherwise, the ESXi hosts fail to feed the syslog messages to vRealize Log Insight or to any remote target. 

    • Using an FQDN saves time on post-restore and recovery configuration changes, assuming that the same FQDN can be resolved on the recovery site. 
    • For system alerts, vRealize Log Insight uses FQDN host names if available instead of IP addresses.  
    • Assuming that only underlying IP addresses change post-backup and recovery or disaster recovery operations, using FQDN eliminates the need to change the syslog target address (master node FQDN or internal load balancer FQDN) on all the external devices feeding logs to the vRealize Log Insight cluster.
    • With vRealize Log Insight 2.5, you must update the configuration file, located at /storage/core/loginsight/config/loginsight-config.xml#<n> where <n> is the largest number. This configuration file replaces the worker node IP address with the new IP address used for the restored nodes because the FQDN is not used for worker node addresses in the configuration file. You need to make this change only on the master node to synchronize the changes with all the worker nodes.
  • Join requests from a vRealize Log Insight worker node should use the FQDN of the vRealize Log Insight master node.
    • Beginning in vRealize Log Insight 2.5, the master node host value in the configuration file on each of the nodes, located at /storage/core/loginsight/config/loginsight-config.xml#<n>, is based on the value used by the first worker node sending a join request. Using the FQDN of the master node for the join request prevents making any manual changes to the master node host value post-disaster recovery. Otherwise, the worker nodes cannot rejoin the master node until the master node host name is updated in the configuration files on all restored cluster nodes.
  • Provide static IP addresses as well as optional virtual IP addresses for the load balancer. 
    • When configuring an integrated load balancer, provide the optional FQDN for the virtual IP address. This optional FQDN enables vRealize Log Insight to revert to the FQDN when an IP address is not reachable for any reason.