Deployment Guide

Welcome to Deployment Architecture overview for Motadata ObserveOps (formerly known as AIOps). This document serves as a comprehensive guide to understanding the deployment architecture of Motadata ObserveOps, a powerful ObserveOps (Artificial Intelligence for IT Operations) solution.

In today's complex IT environments, deploying Motadata ObserveOps efficiently and effectively is crucial for organizations seeking to enhance their operational intelligence.

This document explores the architecture of Motadata ObserveOps in five distinct deployment modes, each tailored to specific business needs and IT requirements:

1. Single-Box
2. Distributed
3. Multi-Site Deployment
4. High Availability
5. Disaster Recovery
6. High Availability Over WAN

Through detailed explanations and accompanying diagrams, we will dive into the unique characteristics of each providing you with valuable insights to make informed decisions about your ObserveOps implementation strategy.

Now, we will look into all the types of deployment one by one. Let us start by looking into the single-box Deployment.

Single-Box

Single-Box Deployment

In a Single-Box Deployment of Motadata ObserveOps, Motadata application and MotaStore reside on the same entity.

Architecture

In a single-box Deployment of Motadata ObserveOps, Motadata application and MotaStore reside on the same entity, which can be a virtual machine (VM) or bare-metal server. This streamlined architecture simplifies the deployment process and offers versatility in monitoring various aspects of your IT infrastructure.

Configuration

1. Configure Motadata ObserveOps Application and Motadata DB on a single server as per the Single-Box Standalone Deployment scenario from the Installation Guide.

Distributed

Distributed Deployment

This deployment separates the MotaStore and the Motadata application onto different physical or virtual machines.

Architecture

In a Distributed Deployment of Motadata ObserveOps, the architecture is divided into two distinct entities to address specific security concerns. This deployment separates the MotaStore and the Motadata application onto different physical or virtual machines.

Suppose an organizations has stringent security requirements, especially those handling sensitive or confidential data or there are situations where separation of database and application components is mandated by compliance standards or internal security policies then the organization might opt for this deployment.

Configuration

1. Configure a server as per the Primary App scenario from the Installation Guide.

2. Configure a server as per the Primary DB scenario from the Installation Guide.

Multi-Site

Multi-Site Deployment

In a Multi-Site Deployment of Motadata ObserveOps, the architecture is tailored for multi-site scenarios, accommodating organizations with multiple branches, remote offices, or distributed locations. This deployment model optimizes data collection and visualization across a network of sites.

Architecture

• Multi-Site Scalability: Motadata ObserveOps accommodates organizations with head offices and remote branch locations by deploying the Motadata application (Motadata App) and Motadata database (Motadata DB) on separate virtual or physical machines at the central data center (head office) while extending monitoring capabilities to remote sites.

• Motadata Collectors: Remote sites are equipped with Motadata Collectors, which efficiently poll and gather data from local resources such as servers, network devices, and applications. The collected data is then securely transmitted to the central server (head office).

• Centralized Visualization: Data collected from various remote sites is centralized and visualized on the master server at the central data center, providing a unified view of the entire infrastructure.

Configuration

• Configure the Main Site as per the Distributed Deployment Scenario from the Installation Guide

• Configure the Collectors at the Remote Site(s) as per the Collector Deployment Scenario from the Installation Guide

Multi-Site Log Deployment

Let us consider how the Multi-Site deployment for an organization opting for only log monitoring capability of Motadata ObserveOps would look like:

Multi-Site Flow Deployment

Let us consider how the Multi-Site deployment for an organization opting for only log monitoring capability of Motadata ObserveOps would look like:

High Availability

High Availability

In this section, we will explore two distinct High Availability scenarios: single-box Deployment with High Availability and Distributed Deployment with High Availability. Each scenario presents unique configurations, prerequisites, and architecture designed to ensure a robust and fault-tolerant architecture.

Whether you opt for a consolidated single-box Deployment or a distributed setup, Motadata ObserveOps' High Availability deployment empowers your organization to navigate potential disruptions with confidence. Dive into the detailed explanations and accompanying diagrams to gain valuable insights into implementing High Availability, safeguarding your IT infrastructure, and fortifying your operational capabilities.

Single-Box Deployment with High Availability

Architecture

In a single-box Deployment with High Availability, Motadata ObserveOps employs a primary-secondary server configuration to ensure continuous availability. A virtual IP is configured to ensure uninterrupted service of Motadata ObserveOps to the user. This server setup forms the foundation for the High Availability architecture, allowing for a failover mechanism to take over in case of any failure.

In HA setups employing a single-box configuration, the Observer is intricately connected to both the primary and secondary components. This connection enables real-time synchronization of critical data.

• Continuous Heartbeat Exchange: The Primary and Secondary servers maintain constant communication by sending heartbeats to each other. This continuous heartbeat exchange ensures real-time monitoring of server availability status.

• Virtual IP Configuration: A Virtual IP is configured to ensure uninterrupted connectivity to Motadata ObserveOps for the end user.

• Agent and Collector Registration: Ensure the registration of all collectors and agents is done through the Virtual IP address. This will ensure the requests are being sent to the active application server in the event of a failover.

• Failover Trigger: The failover mechanism is designed to activate when the Primary server fails to send a heartbeat to the Secondary server within a pre-defined interval. This failover process ensures activation of the Secondary server as the Primary server, mitigating potential downtime.

• Activation of Slave Server: Upon detection of a failure, the Secondary server automatically takes over as the Primary server. This swift transition due to the configured virtual IP ensures continuous service availability.

• Role of Observer: The Observer retrieves data every 10 seconds from the Primary component, including configuration database and cache. This data is then stored within the Observer itself and synchronized with the Secondary component. This synchronization mechanism ensures that the configuration database and cache remain consistently updated across all components within the HA setup.

• Database Synchronization: Report DB of both Primary and Secondary components remains in sync through registration of slave component with the master component, ensuring data consistency and accessibility across the architecture.

• Restoration Process: Once the original Primary server is restored and operational, it resumes its role as the Primary server. The restoration is initiated after the Primary server sends a heartbeat to the Secondary server, confirming its availability.

This orchestrated process ensures a resilient High Availability single-box Deployment for Motadata ObserveOps, where servers communicate with each other, failover occurs promptly, and service continuity is prioritized.

Configuration

1. Configure three Physical IPs (one for Primary server, one for Secondary server, and one for observer) and a Virtual IP (for seamless user access and failover scenario) as per the single-box deployment scenario.

2. Configure the Observer server as per Single-Box High Availability scenario from the Installation Guide

3. Configure Primary Server as per the Single-Box High Availability scenario from the Installation Guide

4. Configure Secondary Server as per the Single-Box High Availability scenario from the Installation Guide

Distributed Deployment with High Availability

Architecture

In a Distributed Deployment with High Availability, the Primary server is connected to two separate sets of MotaStores, Primary DB and Secondary DB at the main site, ensuring redundancy and real-time data updates in case of failure. A virtual IP is configured to ensure uninterrupted access to the end user.

In distributed HA deployments, the Observer maintains connections with the Primary and Secondary application servers. This ensures comprehensive real-time synchronization of critical data.

• Continuous Heartbeat Exchange: The Primary and Secondary application servers engage in continuous communication through heartbeat exchanges. This ongoing communication allows real-time monitoring of server availability status.

• Virtual IP Configuration: A Virtual IP is configured to ensure uninterrupted connectivity to Motadata ObserveOps for the end user.

• Agent and Collector Registration: Ensure the registration of all collectors and agents is done through the Virtual IP address. This will ensure the requests are being sent to the active application server in the event of a failover.

• Config DB Synchronisation: The Observer retrieves data every 10 seconds from the primary Application Server, including configuration database and cache. This data is then stored within the Observer itself and synchronized with the Seccondary application server. This synchronization mechanism ensures that the configuration database and cache remain consistently updated across all components within the HA setup.

• Report DB Configuration: Deploy two sets of MotaStores to support redundancy and fault tolerance. The Primary application server maintains connections to both sets of MotaStores. Report DB of both Primary and Secondary Motastores remains in sync through registration with the Primary application server, ensuring data consistency and accessibility across distributed environments.

• Failover Mechanism: The failover mechanism triggers when the Primary application server fails to send a heartbeat to the Secondary application server within a predefined interval. This failover process ensures activation of the Secondary application server as the Primary server, mitigating potential downtime. In case, the Primary DB goes down, the Secondary DB seamlessly connects to the Primary Application server again mitigating potential downtime in this case.

• Activation of Slave Server: Upon detection of a failure in the Primary Application server, the Secondary Application server automatically takes over as the Primary server. This transition minimizes service disruption and maintains continuous availability due to the configuration of the virtual IP.

• Restoration Process: Once the original Primary Application server is restored, it resumes its role as the Primary Application server after sending a heartbeat to the Secondary Application server. The restoration process completes the cycle, ensuring a seamless transition back to the original configuration.

This orchestrated architecture ensures a resilient Distributed Deployment with High Availability for Motadata ObserveOps. The continuous communication, redundancy, and failover mechanisms collectively contribute to maintaining operational excellence.

Configuration

1. Configure five Physical IPs (one for Primary Application and Primary Database server each, one for Secondary Application and Secondary Database server each, and one for observer) and a Virtual IP (for seamless user access and failover scenario) as per the single-box deployment scenario.

2. Configure the Observer server as per the Distributed High Availability scenario from the Installation Guide

3. Configure Primary App Server as per the Distributed High Availability scenario from the Installation Guide

4. Configure Primary DB Server as per the Distributed High Availability scenario from the Installation Guide

5. Configure Secondary App Server as per the Distributed High Availability scenario from the Installation Guide

6. Configure Secondary DB Server as per the Distributed High Availability scenario from the Installation Guide

Disaster Recovery

Disaster Recovery

This comprehensive document takes a deep dive into the details of Motadata ObserveOps Disaster Recovery deployment, a vital component for organizations prioritizing robust business continuity strategies. Disaster Recovery ensures that organizations can easily navigate through disruptions, maintain data consistency, and adhere to strict recovery objectives.

Throughout the subsequent sections, we will dive into Distributed Deployment with Disaster Recovery. This includes specific configurations, prerequisites, and operational procedures designed to establish a resilient and recoverable architecture.

Single-Box Deployment with Disaster Recovery

Architecture

In a Single-Box Deployment with Disaster Recovery, Motadata ObserveOps establishes a comprehensive architecture that combines high availability with disaster recovery capabilities. This deployment model ensures not only redundancy and real-time updates but also prepares the infrastructure for swift recovery in case of catastrophic events.

Within this setup, the Observer maintains connections with the Primary and Secondary server components at the DC site, and replica server component at the DR site. This comprehensive connectivity guarantees uninterrupted monitoring and synchronization during DR scenarios.

• Continuous Heartbeat Exchange: Continuous communication occurs between the Primary and Secondary servers at main site through heartbeat exchanges. This real-time communication ensures constant monitoring of server availability status, critical for high availability.

• Servers Configuration: The architecture incorporates two single-box servers at the Main Site and another single-box server at the disaster recovery (DR) site. This server setup forms the core of the single-box with disaster recovery deployment, ensuring system resilience and facilitating disaster recovery.

• Virtual IP Configuration: A Virtual IP is configured at the main site to ensure High Availability and uninterrupted connectivity to Motadata ObserveOps for the end user.

• Agent and Collector Registration: Ensure the registration of all collectors and agents is done through the Virtual IP address. This will ensure the requests are being sent to the active application server in the event of a failover.

• Config DB Synchronisation: Every 10 seconds, the Observer retrieves data from the Primary server component, including configuration database and cache. This data is then stored within the Observer itself and synchronized with the Secondary and Replica components. This synchronization mechanism ensures that the configuration database and cache remain consistently updated across all components within the DR setup.

• Failover Mechanism for Disaster Recovery: When the Data Center goes down, a switch to DR site is made through a manual process. The Replica server at the DR site is manually started as the new Primary server. When the disaster occurs at the main site, the DB will already be updated at the MotadataDB on the DR site.

This architecture ensures a resilient Single-Box Deployment with Disaster Recovery for Motadata ObserveOps. The combination of continuous communication, redundancy, failover mechanisms collectively makes the infrastructure more robust against potential disasters.

Configuration

1. Configure three Physical IPs (one for primary, one for secondary, one for observer) at the Main Site, a Virtual IP (for High Availability scenario) at the main site and one Physical IP(for replica server) at the DR site.

2. Establish a reliable network link (i.e., VPN connectivity) between the main site and the DR site. This link is essential for real-time replication of the report database (reportdb), ensuring that data remains synchronized across both sites.

3. Configure the Observer server as per Single-Box Disaster Recovery scenario from the Installation Guide

4. Configure Primary Server as per the Single-Box Disaster Recovery scenario from the Installation Guide

5. Configure Secondary Server as per the Single-Box Disaster Recovery scenario from the Installation Guide

6. Configure Replica Server on the DR site as per the Single-Box Disaster Recovery scenario from the Installation Guide

Distributed Deployment with Disaster Recovery

Architecture

In a Distributed Deployment with Disaster Recovery, Motadata ObserveOps establishes a comprehensive architecture that combines high availability with disaster recovery capabilities. This deployment model ensures not only redundancy and real-time updates but also prepares the infrastructure for swift recovery in case of catastrophic events.

Within this setup, the Observer extends its connectivity to the Primary application server at the data center (DC) site, Secondary application server at the DC site, and the replica app at the DR site. This extensive network ensures continuous synchronization even in the event of a disaster.

• Continuous Heartbeat Exchange: Continuous communication occurs between the Primary and Secondary servers at main site through heartbeat exchanges. This real-time communication ensures constant monitoring of server availability status, critical for high availability.

• Application Servers Configuration: The architecture incorporates two application servers at the Main Site and another one at the disaster recovery (DR) site. This server setup forms the core of the distributed deployment with disaster recovery architecture, ensuring system resilience and facilitating disaster recovery.

• MotaStores Configuration: This architecture incorporates multiple MotaStores, two at the main site and another one at the Disaster Recovery site to support redundancy and fault tolerance. The Master server maintains connections to all the MotaStores, enabling simultaneous data storage and updates of the ReportDB for enhanced reliability.

• Virtual IP Configuration: A Virtual IP is configured at the main site to ensure High Availability and uninterrupted connectivity to Motadata ObserveOps for the end user.

• Agent and Collector Registration: Ensure the registration of all collectors and agents is done through the Virtual IP address. This will ensure the requests are being sent to the active application server in the event of a failover.

• Config DB Synchronisation: Every 10 seconds, the Observer retrieves data from the primary application server, including configuration database and cache. This data is then stored within the Observer itself and synchronized with the secondary and replica application servers. This synchronization mechanism ensures that the configuration database and cache remain consistently updated across all components within the DR setup.

• Report DB Configuration: For DR deployments utilizing distributed deployment models, the report database (report DB) is available in the MotaStore of both primary and secondary components at the main site, as well as the replica component at the DR site. These databases remain in sync through registration with the primary application, ensuring data consistency and accessibility across distributed environments. c

• Failover Mechanism for Disaster Recovery: When the Data Center goes down, a switch to DR site is made through a manual process. The Replica Application server at the DR site is manually started as the new Primary Application server and the replica database at the DB is registered with the replica application server(now the primary application server). When the disaster occurs at the main site, the DB will already be updated at the MotadataDB on the DR site.

This architecture ensures a resilient Distributed Deployment with Disaster Recovery for Motadata ObserveOps. The combination of continuous communication, redundancy, failover mechanisms collectively makes the infrastructure more robust against potential disasters.

Configuration

1. Configure five Physical IPs (one for primary application and primary database server each, one for secondary application and secondary database server each, one for observer) at the Main Site, a Virtual IP (for High Availability scenario) at the main site and configure two Physical IPs(one for replica application and one for replica database server each) at the DR site.

2. Establish a reliable network link (i.e., VPN connectivity) between the main site and the DR site. This link is essential for real-time replication of the report database (reportdb), ensuring that data remains synchronized across both sites.

3. Configure the Observer server on the DC site as per Distributed Disaster Recovery scenario from the Installation Guide

4. Configure Primary App Server on the DC site as per the Distributed Disaster Recovery scenario from the Installation Guide

5. Configure Primary DB Server on the DC site as per the Distributed Disaster Recovery scenario from the Installation Guide

6. Configure Secondary App Server on the DC site as per the Distributed Disaster Recovery scenario from the Installation Guide

7. Configure Secondary DB Server on the DC site as per the Distributed Disaster Recovery scenario from the Installation Guide

8. Configure Replica App Server on the DR site as per the Distributed Disaster Recovery from the Installation Guide

9. Configure Replica DB Server on the DR site as per the Distributed Disaster Recovery from the Installation Guide

Standard Operating Procedure in case of Failover

SOP for Disaster Recovery with Distributed Deployment

In the event of a failover in a Distributed Deployment with Disaster Recovery scenario for Motadata ObserveOps, ensuring a smooth transition and maintaining operational continuity is of primary importance. This Standard Operating Procedure outlines the steps to be taken during failover, focusing on preserving data integrity and minimizing disruption to users accessing the system.

Failover Procedure

1. Activate Disaster Recovery Site:

When the Data Center (DC) goes down, initiate the switch to the Disaster Recovery (DR) site. Manually start the Replica Motadata application as the new master at the DR site. Register the Replica database with the replica application, which now assumes the role of the master.

2. DNS Update:

Manually change the Domain Name System (DNS) to direct traffic to the DR site. Ensure that any agent and collector configurations are updated to point to the new master at the DR site.

3. Notify Users:

Notify users of the failover and provide clear instructions for accessing the Motadata ObserveOps application on the DR site.

Fail-back Procedure:

1. Data Transfer from DR to DC:

Once the DC components are back up and running, initiate the process of transferring cached data from the replica application at the DR site to the primary and slave applications at the DC site. Start the primary application, slave application, and both databases at the DC site.

By following these steps, the organization ensures a structured and organized approach to managing failover in a Distributed Deployment with Disaster Recovery scenario. This proactive approach maintains data integrity, operational continuity, and minimizes the impact on users and critical system functions during failover events.

SOP for Disaster Recovery with HA Deployment

In the event of a failover in a Distributed Deployment with HA scenario for Motadata ObserveOps, ensuring a smooth transition and maintaining operational continuity is of primary importance. This Standard Operating Procedure outlines the steps to be taken during failover, focusing on preserving data integrity and minimizing disruption to users accessing the system.

Failover Procedure

1. Activate Disaster Recovery Site:

When the Data Center (DC) goes down, initiate the switch to the Disaster Recovery (DR) site. Manually start the Replica Motadata Replica component as the new Primary Component at the DR site.

2. DNS Update:

Manually change the Domain Name System (DNS) to direct traffic to the DR site. Ensure that any agent and collector configurations are updated to point to the new master at the DR site.

3. Notify Users:

Notify users of the failover and provide clear instructions for accessing the Motadata ObserveOps application on the DR site.

Fail-back Procedure:

1. Data Transfer from DR to DC:

Once the DC components are back up and running, initiate the process of transferring cached data from the replica component at the DR site to the primary and secondary components at the DC site. Start the primary and master components at the DC site.

By following these steps, the organization ensures a structured and organized approach to managing failover in a Distributed Deployment with Disaster Recovery scenario. This proactive approach maintains data integrity, operational continuity, and minimizes the impact on users and critical system functions during failover events.

High Availability Over WAN

High Availability Over WAN

High Availability (HA) over WAN offers two well defined deployment types, Single-Box HA over WAN and Distributed HA Over WAN. Each deployment type has its own unique configurations and prerequisites. Throughout all the subsequent sections, we will deep dive and understand the operational procedures and specific configurations required for a successful deployment for High Availability Over WAN for Single and Distributed architecture.

High Availability over WAN not only ensures uninterrupted availability but also ensures highly resilient, robust, and recoverable architecture.

Single-Box Deployment with High Availability Over WAN

Architecture

In a Single-Box Deployment with High Availability over WAN, Motadata ObserveOps is deployed on Primary and Secondary site at two different geo-locations. Ensure a connection with appropriate bandwidth to allow seamless communication between both, Primary and Secondary servers.

In this deployment type, a FQDN entry is listed in the DNS server pointing to the Primary server. In case of a failover, the FQDN should be manually updated pointing to the Secondary server.

It is recommended that Observer shall be deployed at the Secondary site. The Observer will keep the config and cache files in sync.

• Continous Heartbeat Exchange: The Primary and Secondary servers maintain constant communication by sending heartbeats to each other. This continuous heartbeat exchange ensures real-time monitoring of server availability status.

• FQDN Configuration: A FQDN entry in the DNS server points the user requests to Motadata ObserveOps Primary server. Once the request is received it is translated from hostname to the IP address of Primary server. In the event of failover, FQDN entry in the DNS server shall be changed manually to point the requests to the Secondary server.

• Servers Configuration: The architecture comprises of one single-box server at Primary site and one at the Secondary site.

• Role of Observer: The Observer retrieves data every 10 seconds from the Primary server, including configuration database and cache. This data is then stored within the Observer itself and synchronized with the Secondary server. This synchronization mechanism ensures that the configuration database and cache remain consistently updated across all servers.

• Database Synchronization: Report DB of both Primary and Secondary server stay in sync with the help of Primary server.

• Agent and Collector Registration: Ensure the registration of all collectors and agents is done through the FQDN. This will ensure the requests are being sent to the active application server in the event of a failover.

• Failover Trigger: The Primary and Secondary servers stay in constant communication using Heartbeat. The failover triggers when the Primary application server fails consecutive Heartbeat exchanges. A failed Heartbeat exchange is called a Flap. The duration of each Heartbeat and number of Flaps after which the system will assume the Failover are configurable. Once the system reaches the failed flap counts threshold, as defined by the user. The system will assume the Primary server is down. For instance, if the Heartbeat duration is 30 seconds and failed Flap counts is set to 3. Motadata ObserveOps will await 90 seconds in total (30 seconds for each consecutive Flap count) after which it will deem the Primary server in the down state.

• Failover Mechanism: When the Primary application server goes down, Motadata ObserveOps will automatically execute the Failover Trigger. However, to provide seamless access to user, FQDN entries in the DNS server(s) will need to be manually updated to point the requests to the Secondary application server. The historical data will already be updated on the database on the secondary site.

Configuration

1. Configure three Physical IPs (one for Primary server, one for Secondary server, and one for observer) and a FQDN (for seamless user access and failover scenario) as per the single-box deployment scenario.

2. Configure the Observer server as per Single-Box High Availability Over WAN scenario from the Installation Guide

3. Configure Primary Server as per the Single-Box High Availability Over WAN scenario from the Installation Guide

4. Configure Secondary Server as per the Single-Box High Availability Over WAN scenario from the Installation Guide

Distributed Deploymment with High Availability Over WAN

Architecture

In Distributed Depolyment with High Availability over WAN, the MotaStore and Motadata app is deployed on different virtual or physical machines.

In this deployment type the Primary application server is connected to two separate MotaStores, one at the Primary site and one at the Secondary site. Since the Primary and Secondary sites are on different networks, they require Internet or VPN to estabilish connection with each other.

A FQDN is configured to direct the incoming traffic to Primary server and serve all the requests. If there's a failover scenario, FQDN will have to be manually configured to redirect the incoming traffic to the Secondary application server.

Here, Observer typically resides at the Secondary site and maintains connection with the Primary and Secondary application servers. This ensures comprehensive real-time synchronization of critical data.

• Continous Heartbeat Exchange: The Primary and Secondary servers maintain constant communication by sending heartbeats to each other. This continuous heartbeat exchange ensures real-time monitoring of server availability status.

• FQDN Configuration: A FQDN entry in the DNS server points the user requests to Motadata ObserveOps Primary application server. Once the request is received it is translated from hostname to the IP address of Primary application server.In the event of failover, FQDN entry in the DNS server shall be changed manually to point the requests to the Secondary application server.

• Servers Configuration: The architecture comprises of two distributed server setups. One at Primary site and one at the Secondary site. The Observer typically resides at the Secondary site.

• Role of Observer: The Observer retrieves data every 10 seconds from the Primary database server, including configuration database and cache. This data is then stored within the Observer itself and synchronized with the Secondary database server. This synchronization mechanism ensures that the configuration database and cache remain consistently updated across all servers within the HA setup.

• Database Synchronization: Report DB of both Primary and Secondary servers remains in sync through registration of Secondary database server with the Primary application server, ensuring data consistency and accessiility across the architecture.

• Agent and Collector Registration: Ensure the registration of all collectors and agents is done through the FQDN. This will ensure the requests are being sent to the active application server in the event of a failover.

• Failover Trigger: The Primary and Secondary application server stay in constant communication using Heartbeat. The failover triggers when the Primary application server fails consecutive Heartbeat exchanges. A failed Heartbeat exchange is called a Flap. The duration of each Heartbeat and number of Flaps after which the system will assume the Failover are configurable. Once the system reaches the failed flap counts threshold as defined by the user; The system will assume the Primary application server is down. For instance, if the Heartbeat duration is 30 seconds and failed Flap counts is set to 3. Motadata ObserveOps will await 90 seconds in total (30 seconds for each consecutive Flap count) after which it will deem the Primary application server in the down state.

• Failover Mechanism: When the Primary application server goes down, Motadata ObserveOps will automatically execute the Failover Trigger. However, to provide seamless access to user, FQDN entries in the DNS server(s) will need to be manually updated to point the requests to the Secondary application server. The historical data will already be updated on the database on the secondary site.

Configuration

1. Configure five Physical IPs (one for Primary Application and Primary Database server each, one for Secondary Application and Secondary Database server each, and one for observer) and a FQDN (for seamless user access and failover scenario) as per the Distributed Single-box deployment scenario.

2. Configure the Observer server as per the Distributed High Availability Over WAN scenario from the Installation Guide

3. Configure Primary App Server as per the Distributed High Availability Over WAN scenario from the Installation Guide

4. Configure Primary DB Server as per the Distributed High Availability Over WAN scenario from the Installation Guide

5. Configure Secondary App Server as per the Distributed High Availability Over WAN scenario from the Installation Guide

6. Configure Secondary DB Server as per the Distributed High Availability Over WAN scenario from the Installation Guide

Standard Operating Procedure in case of Failover

The SOPs mentioned in this section are valid for both Single and Distributed deployment with High Availability over WAN. In the event of failover, ensuring a smooth transition and maintaining opeartional continuity is of primary importance. This Standard Operating Procedure outlines the steps to be taken during failover, focusing on preseerving data integrity and minimizing disruption to users accessing the system.

Failover Procedure

1. FQDN Update:

Manually change the FQDN entry in the DNS server to direct traffic to Secondary Application server.

Fail-back Procedure:

1. FQDN Update:

Manually change the FQDN entry in the DNS server to direct traffic to the Primary Application server.