Operations for Logs Disaster Recovery

You can use the following information specific to disaster recovery for Operations for Logs by using Site Recovery Manager.

Guidelines for Protecting Operations for Logs

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.

• Operations for Logs 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 Operations for Logs cluster.
  • Using static IP addresses eliminates the need to update the IP addresses of Operations for Logs cluster nodes each time the IP address of a Operations for Logs node changes. 
  • Operations for Logs 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 Operations for Logs to feed their logs, use a fully qualified domain name (FQDN) or IP address as the syslog target. For example, vSphere ESXi, vSphere, and VMware Aria 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 Operations for Logs cluster. 

  • For the primary node, when you use a load balancer, a fully resolvable FQDN is required. Otherwise, the ESXi hosts fail to feed the syslog messages to Operations for Logs 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, Operations for Logs 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 (primary node FQDN or internal load balancer FQDN) on all the external devices feeding logs to the Operations for Logs cluster.
• Join requests from a Operations for Logs worker node should use the FQDN of the Operations for Logs primary node.
• 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 Operations for Logs to revert to the FQDN when an IP address is not reachable for any reason.