Method and system for managing fault tolerance associated with an auditor service unit

Abstract

The present disclosure relates to a method and a system for managing fault tolerance associated with an Auditor Service (AU) The method comprises receiving by a Load Balancer (LB) a request message from one or more service instances. The method comprises identifying by the LB, one or more available auditor service instances from a set of auditor service instances. The method comprises identifying by the LB, a positive health status associated with the one or more available auditor service instances. The method comprises transmitting, by the LB to an available auditor service instance from the one or more available auditor service instances, the request message based on the positive health status. The method further comprises managing the fault tolerance associated with the AU by transmitting the request message.

Description

METHOD AND SYSTEM FOR MANAGING FAULT TOLERANCE ASSOCIATED WITH AN AUDITOR SERVICE UNITFIELD OF THE DISCLOSURE

[0001] Embodiments of the present disclosure generally relate to network performance management systems. More particularly, embodiments of the present disclosure relate to managing fault tolerance associated with an Auditor Service (AU) unit.BACKGROUND

[0002] The following description of the related art is to provide background information pertaining to the field of disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section is used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of the prior art.

[0003] The 5G core networks are based on service-based architecture (SB A) that is centred around network function (NF) services. In the said Service-Based Architecture (SBA), a set of interconnected Network Functions (NFs) deliver the control plane functionality and common data repositories of the 5G network, where each NF is authorized to access services of other NFs. Particularly, each NF can register itself and its supported services to a Network Repository Function (NRF), which is used by other NFs for the discovery of NF instances and their services. Further, the network functions may include, but not limited to, a cloud-native network function (CNF) and a virtual network function (VNF).

[0004] The CNFs are a set of small, independent, and loosely coupled services such as microservices. These microservices work independently, which may increase speed and flexibility while reducing deployment risk. In 5G communication, cloud-native 5G network offers the fully digitized architecture necessary for deploying new cloud services and taking full advantage of cloud-native 5G features such as edge computing, as well as network slicing and other services. Whereas the VNFs may run in virtual machines (VMs) on common virtualization infrastructure. The VNFs may be created on top of network function virtualization infrastructure (NF VI) which may allocate resources like compute, storage, and networking efficiently among the VNFs. MANO which stands for Management and Orchestration is a key NFV architectural framework thatincludes all the essential management modules. It coordinates network resources in NFV framework. Further, due to such vast usage and implementation of the CNFs and the VNFs, there is a need of maintaining such microservices and applications data in a secure way, which may not be lost and may be retained safely from any unwanted incidents such as network service crash, outage, cyber-attacks and any other undesirable incidents.

[0005] A network function virtualization (NFV) and software defined network (SDN) design function module platform provides the facility to act as a single platform to manage all the Virtual Network Functions (VNFs) and Cloud-Native Network Functions (CNFs) being deployed in a telecom network. As the platform is completely based on micro service architecture, it is highly scalable and will be able to handle hundreds of NFVs. The platform is completely event driven and is based on standard REST Application Program Interfaces (APIs). An Auditor Service (AU) audits the resources in terms of physical memory, RAM and CPU at Inventory Manager (IM). IM maintains the virtual inventory and limited physical inventory. It maintains relation between physical and virtual resources (w.r.t overlay). Also, it describes physical and virtual resources w.r.t different attributes using updates from external micro- service. Thus, its data accuracy depends on the micro- services which create, update, delete these resources and at the same time update these events with IM. Other services can query IM relations, attributes etc. using Query APIs provided by IM. The AU brings inventory in synchronize with real time available / used resources and minimizes the mismatch between Inventory Manager (IM) and real time hardware. The data accuracy depends primarily on Swarm Adaptor (SA) and Inventory Manager (IM). The AU detects whether the hosts contain lesser / more containers than the amount present in inventory managed by the IM. It accordingly sends API request to IM to update its inventory. AU interacts with these microservices (MS) to fetch the real time data using various APIs. Due to high traffic on a particular instance of the dependent MS or unhealthy instance, requests might get failed which results into failure of system, so to avoid this type of scenario and to ensure that no server is overworked, there is a need for a new type of interface to resolve the incoming / outgoing requests distribution among all auditor instances.

[0006] Thus, there exists an imperative need in the art to manage fault tolerance for any event failure via an interface by efficiently maintaining incoming and outgoing requests distribution among all AU instances, which the present disclosure aims to address.SUMMARY

[0007] This section is provided to introduce certain aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.

[0008] An aspect of the present disclosure may relate to a method for managing a fault tolerance associated with an Auditor Service (AU) unit. The method comprises receiving, by a Load Balancer (LB) unit, a request message from one or more service instances. The method further comprises identifying, by the LB unit, one or more available auditor service instances from a set of auditor service instances. Further, the method comprises identifying, by the LB unit, a positive health status associated with the one or more available auditor service instances from the set of available auditor service instances. The method further comprises transmitting, by the LB unit via the AU LB interface to an available auditor service instance from the one or more available auditor service instances, the request message based on the positive health status. The method further comprises receiving, by the LB unit

[0304] , a request message response from the available auditor service instance based on the request message. The method further comprises transmitting, by the LB unit

[0304] , the request message response to the one or more service instances. The method further comprises managing, by the LB unit via the AU LB interface, the fault tolerance associated with the AU unit by transmitting the request message based on the positive health status.

[0009] In an exemplary aspect of the present disclosure, the set of auditor service instances comprises at least one of the one or more available auditor service instances and one or more unavailable auditor service instances associated with the AU unit.

[0010] In an exemplary aspect of the present disclosure, the set of auditor service instances is identified by an 0AM unit via the AU LB interface based on a predefined auditor status determination rule.

[0011] In an exemplary aspect of the present disclosure, the managing AU unit by the LB unit via the AU LB interface, the fault tolerance associated with the AU unit further comprises transmitting the request message to another available auditor service instance from the one or more available auditor service instances, in an event the available auditor service instance from the one or more available auditor service instances becomes unavailable during processing of the request message.

[0012] In an exemplary aspect of the present disclosure, the set of auditor service instances is received at the LB unit from the 0AM unit.

[0013] In an exemplary aspect of the present disclosure, the positive health status associated with the one or more available auditor service instances from the set of available auditor service instances is received by the LB unit from an 0AM unit based on a predefined health determination rule.

[0014] In an exemplary aspect of the present disclosure, the at least the positive health status associated with the one or more available auditor service instances from the set of available auditor service instances is received by the LB unit

[0304] from the 0AM unit in real time.

[0015] Another aspect of the present disclosure may relate to a system for managing a fault tolerance associated with an Auditor Service (AU) unit. The system comprises at least a Load Balancer (LB) unit. The LB unit is configured to receive, a request message from one or more service instances. The LB unit is further configured to identify, via the AU LB interface, one or more available auditor service instances from the set of auditor service instances. Furthermore, the LB unit is configured to identify, a positive health status associated with the one or more available auditor service instances from the set of auditor service instances. The LB unit is configured to transmit, via the AU LB interface to an available auditor service instance from the one or more available auditor service instances, the request message based on the positive health status. The LB unit is configured to receive a request message response from the available auditor service instances based on the request message. The LB unit is configured to transmit the request message response to the one or more service instances. The LB unit is configured to manage, via the AU LB interface, the fault tolerance associated with the AU unit by transmitting the request message based on the positive health status.

[0016] Yet another aspect of the present disclosure may relate to a non-transitory computer readable storage medium storing instruction for managing fault tolerance associated with an Auditor Service (AU) unit, the instructions include executable code which, when executed by one or more units of a system cause a load balancer (LB) unit to receive, a request message from one or more service instances. The instructions when executed by the system further cause the LB unit to identify, via the AU LB interface, one or more available auditor service instances from the set of auditor service instances. The instructions when executed by the system further cause the LB unit to identify, a positive health status associated with the one or more available auditor serviceinstances from the set of auditor service instances. The instructions when executed by the system further cause the LB unit to transmit, via the AU LB interface to an available auditor service instance from the one or more available auditor service instances, the request message based on the positive health status. The instructions when executed by the system further cause the LB unit to receive a request message response from the available auditor service instances based on the request message. The instructions when executed by the system further cause the LB unit to transmit the request message response to the one or more service instances. The instructions when executed by the system further cause the LB unit to manage, via the AU LB interface, the fault tolerance associated with the AU unit by transmitting the request message based on the positive health status.OBJECTS OF THE DISCLOSURE

[0017] Some of the objects of the present disclosure, which at least one embodiment disclosed herein satisfies are listed herein below.

[0018] It is an object of the present disclosure to provide a system and a method for managing fault tolerance for any event failure via an interface by efficiently maintaining incoming and outgoing requests distribution among all AU instances.

[0019] It is another object of the present disclosure to provide a solution that effectively routes client requests across all servers in a manner that maximizes speed and capacity utilization.

[0020] It is another object of the invention to provide an async event-based implementation to utilize the interface efficiently.

[0021] It is yet another object of the present disclosure to provide the ability to support HTTP / HTTPS in parallel (Configurable).DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating theprinciples of the present disclosure. Also, the embodiments shown in the figures are not to be construed as limiting the disclosure, but the possible variants of the method and system according to the disclosure are illustrated herein to highlight the advantages of the disclosure. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components or circuitry commonly used to implement such components.

[0023] FIG. 1 illustrates an exemplary system architecture, in accordance with exemplary implementations of the present disclosure.

[0024] FIG. 2 illustrates an exemplary block diagram of a computing device upon which the features of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure.

[0025] FIG. 3 illustrates an exemplary block diagram of a system for managing a fault tolerance associated with an Auditor Service (AU) unit, in accordance with exemplary implementations of the present disclosure.

[0026] FIG. 4 illustrates a method flow diagram for managing a fault tolerance associated with an Auditor Service (AU) unit, in accordance with exemplary implementations of the present disclosure.

[0027] FIG. 5 illustrates an implementation of the method for managing a fault tolerance associated with an Auditor Service (AU) unit, in accordance with exemplary implementations of the present disclosure.

[0028] The foregoing shall be more apparent from the following more detailed description of the disclosure.DETAILED DESCRIPTION

[0029] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter may each be used independently of oneanother or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above.

[0030] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.

[0031] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail.

[0032] Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations may be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure.

[0033] The word “exemplary” and / or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and / or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising” as an open transition word without precluding any additional or other elements.

[0034] As used herein, a “processing unit” or “processor” or “operating processor” includes one or more processors, wherein processor refers to any logic circuitry for processing instructions. Aprocessor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a (Digital Signal Processing) DSP core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input / output processing, and / or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor or processing unit is a hardware processor.

[0035] As used herein, “a user equipment”, “a user device”, “a smart-user-device”, “a smartdevice”, “an electronic device”, “a mobile device”, “a handheld device”, “a wireless communication device”, “a mobile communication device”, “a communication device” may be any electrical, electronic and / or computing device or equipment, capable of implementing the features of the present disclosure. The user equipment / device may include, but is not limited to, a mobile phone, smart phone, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, wearable device or any other computing device which is capable of implementing the features of the present disclosure. Also, the user device may contain at least one input means configured to receive an input from at least one of a transceiver unit, a processing unit, a storage unit, a detection unit and any other such unit(s) which are required to implement the features of the present disclosure.

[0036] As used herein, “storage unit” or “memory unit” refers to a machine or computer-readable medium including any mechanism for storing information in a form readable by a computer or similar machine. For example, a computer-readable medium includes read-only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices or other types of machine-accessible storage media. The storage unit stores at least the data that may be required by one or more units of the system to perform their respective functions.

[0037] As used herein “interface” or “user interface” refers to a shared boundary across which two or more separate components of a system exchange information or data. The interface may also be referred to a set of rules or protocols that define communication or interaction of one or more modules or one or more units with each other, which also includes the methods, functions, or procedures that may be called.

[0038] All modules, units, components used herein, unless explicitly excluded herein, may be software modules or hardware processors, the processors being a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASIC), Field Programmable Gate Array circuits (FPGA), any other type of integrated circuits, etc.

[0039] As used herein the transceiver unit include at least one receiver and at least one transmitter configured respectively for receiving and transmitting data, signals, information or a combination thereof between units / components within the system and / or connected with the system.

[0040] As discussed in the background section, a network function virtualization (NFV) and software defined network (SDN) design function module platform provides the facility to act as a single platform to manage all the Virtual Network Functions (VNFs) and Cloud-Native Network Functions (CNFs) being deployed in a telecom network. As the platform is completely based on micro service architecture, it is highly scalable and will be able to handle hundreds of NFVs. The platform is completely event driven and is based on standard REST Application Program Interfaces (APIs). Auditor service (AU) audits the resources in terms of physical memory, RAM and CPU at Inventory Manager (IM). The AU brings inventory in close sync with real time available / used resources and minimizes the mismatch between Inventory Manager (IM) and real time hardware. The data accuracy depends primarily on Swarm Adaptor (SA) and Inventory Manager (IM). The AU receives information from the SA which constantly monitors the resources. Further, the AU reconciles any differences between the real time available and used resource information obtained from AU and the information present in the IM. AU detects whether the hosts contain lesser / more containers than the amount present in inventory managed by IM, by querying the SA via API requests It accordingly sends API requests to IM to update its inventory. AU interacts with these microservices to fetch the real time data using various APIs. Due to high traffic on a particular instance of the dependent MS or unhealthy instance, requests might get failed which results into failure of system, so to avoid this type of scenario and to ensure that no server is overworked, there is a need for a new type of interface to resolve the incoming / outgoing requests distribution among all auditor instances. Furthermore, the current known solutions have several shortcomings.

[0041] Thus, there exists an imperative need in the art to manage fault tolerance for any event failure via an interface by efficiently maintaining incoming and outgoing requests distributionamong all AU instances, which the present disclosure aims to address. The present disclosure aims to overcome the above-mentioned and other existing problems in this field of technology by providing a method and system of managing a fault tolerance associated with an Auditor Service (AU) unit.

[0042] Referring to FIG. 1, an exemplary system architecture

[0100] comprises a user interface (UI)

[0102] or a user experience (UX), an Elastic Load Balancer (ELB) 1

[0104] , an ELB 2

[0106] , an Identity and Access Management (IAM)

[0108] , an Event Routing Manager (ERM) unit

[0110] , an ELB 3

[0112] , an ELB 4

[0114] , Auditor service instances (AU)

[0116] , an Elastic Search Database

[0118] , an Orchestration Manager (0AM) unit

[0120] , and a Central Log Management Service (CLMS)

[0122] , wherein all the components are assumed to be connected to each other in a manner as obvious to the person skilled in the art for implementing features of the present disclosure. The Auditor service instances

[0116] may comprise multiple instances as shown in the FIG. 1, such as AU 1 [116-1], AU 2 [116-2], AU 3 [116-3] ... AU N [116-N],

[0043] The UI / UX

[0102] refers to an interface to interact with the system architecture

[0100] by a user. The system architecture

[0100] provides a graphically rich and alluring UI / UX interface

[0102] which helps the user to on-board VNFs, CNFs, design Network Service Chain, define CNF auto scaling and healing policies, instantiate Network Service and CNFs. It also allows users to create storage volume pools, availability zones and define host aggregates. The UI / UX

[0102] also provides a one stop solution to users who want to investigate mismatch of resources at server level and at inventory’s database. The user may be a system operator, a network consumer, and the like. The UI / UX

[0102] may be one of a graphical user interface (GUI), a command line interface, and the like. The GUI refers to an interface to interact with the system

[0100] by the user by visual or graphical representation of icons, menu, etc. The GUI is an interface that may be used within a smartphone, laptop, computer, etc. The CLI refers to a text-based interface to interact with the system

[0100] as by the user. The user may input text lines called as command lines in the CLI to access the data in the system.

[0044] The Elastic Load Balancer (ELB) such as ELB 1

[0104] , ELB 2

[0106] , ELB 3

[0112] , and ELB 4

[0114] are exemplary ELBs. The system may include ‘N’ number of ELBs. The ELBs are configured to distribute the load on the auditor service instances [AU 1 [116-2], AU 2 [116-2]... AU N [116-N], The ELBs are further configured to distribute traffic of incoming requests (JSON) based on availability of the auditor service instances. The distribution of traffic enhances faulttolerance. The fault tolerance refers to a capability of the auditor service system

[0116] to handle failures even when one of the auditor service instance fails.

[0045] The IAM

[0108] refers Identity and Access Management that verifies identity of the user who is trying to access the system. The verification may include entering a password, a biometric, and the like. Based on the authentication, the IAM unit

[0108] may authorise access for the user. The verification and the authorisation ensures that the user who is making the access request gets access to the system, and the user has the right level of access to the system. This way, the IAM also acts as a gateway to access other micro services. The IAM provides tokens for API access to other microservices. Further, the IAM

[0108] is configured to define roles and access privileges of the user.

[0046] The Event Routing Manager unit

[0110] is a central routing manager to which an MS publishes an event, then whichever other MS has subscribed to the same event, ERM will send the JSON to all those MS. Here, the ERM unit

[0110] routes the incoming events to appropriate auditor service instances

[0116] in an asynchronous manner. The auditor service instances

[0116] which includes one or more auditor service instances, where each instance audits resources in terms of physical memory, RAM and CPU at an Inventory Manager and Swarm Adaptor. Each of the auditor service instance may be served by at least two ELB units. For instance, the AU 1 [116-1] may be served by the ELB 3

[0112] and the ELB 4

[0114] , The one or more auditor service instances may have an active status or an inactive status.

[0047] The Elastic Search Database (DB)

[0118] refers to a database that organizes data into documents. The documents are grouped into different headers based on characteristics of the data. The Elastic Search Database

[0118] stores, performs searches and analyses the data quickly and in real-time to give a response in milliseconds. The Elastic Search Database

[0118] produces a fast search response based on performing the search in the header instead of the whole data. All micro services not only maintain the state information in their local cache but also persist it in Elastic Search DB

[0118] ,

[0048] The 0AM unit

[0120] is a framework that stores data of the auditor service instances. The data includes but may not be limited to an internet protocol (IP) address, a port, a server disk location. The 0AM unit

[0120] is further configured to maintain a ping-pong communication with all the instances of the auditor service

[0116] , The 0AM unit

[0120] maintains the ping-pong communication to check whether an instance is running or is down. All instances not only maintainthe state information in their local cache but also persist it in Elastic Search DB

[0118] , In case if one of the instances goes down, OAM unit

[0120] detects it and broadcasts the status to other running instances and also the ELB serving the instance which has gone down.

[0049] FIG. 2 illustrates an exemplary block diagram of a computing device

[0200] upon which the features of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure. In an implementation, the computing device

[0200] may also implement a method for managing a fault tolerance associated with an Auditor Service (AU) unit, utilising the system. In another implementation, the computing device

[0200] itself implements the method for managing a fault tolerance associated with an Auditor Service (AU) unit, using one or more units configured within the computing device

[0200] , wherein said one or more units are capable of implementing the features as disclosed in the present disclosure.

[0050] The computing device

[0200] may include a bus

[0202] or other communication mechanism for communicating information, and a hardware processor

[0204] coupled with bus

[0202] for processing information. The hardware processor

[0204] may be, for example, a general-purpose microprocessor. The computing device

[0200] may also include a main memory

[0206] , such as a random-access memory (RAM), or other dynamic storage device, coupled to the bus

[0202] for storing information and instructions to be executed by the processor

[0204] , The main memory

[0206] also may be used for storing temporary variables or other intermediate information during execution of the instructions to be executed by the processor

[0204] , Such instructions, when stored in non-transitory storage media accessible to the processor

[0204] , render the computing device

[0200] into a special-purpose machine that is customized to perform the operations specified in the instructions. The computing device

[0200] further includes a read only memory (ROM)

[0208] or other static storage device coupled to the bus

[0202] for storing static information and instructions for the processor

[0204] ,

[0051] A storage device

[0210] , such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to the bus

[0202] for storing information and instructions. The computing device

[0200] may be coupled via the bus

[0202] to a display

[0212] , such as a cathode ray tube (CRT), Liquid crystal Display (LCD), Light Emitting Diode (LED) display, Organic LED (OLED) display, etc. for displaying information to a computer user. An input device

[0214] , including alphanumeric and other keys, touch screen input means, etc. may be coupled to the bus

[0202] for communicating information and command selections to the processor

[0204] , Another type of user input device may be a cursor controller

[0216] , such as a mouse, a trackball, or cursor directionkeys, for communicating direction information and command selections to the processor

[0204] , and for controlling cursor movement on the display

[0212] , This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allow the device to specify positions in a plane.

[0052] The computing device

[0200] may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and / or program logic which in combination with the computing device

[0200] causes or programs the computing device

[0200] to be a special-purpose machine. According to one implementation, the techniques herein are performed by the computing device

[0200] in response to the processor

[0204] executing one or more sequences of one or more instructions contained in the main memory

[0206] , Such instructions may be read into the main memory

[0206] from another storage medium, such as the storage device

[0210] , Execution of the sequences of instructions contained in the main memory

[0206] causes the processor

[0204] to perform the process steps described herein. In alternative implementations of the present disclosure, hard-wired circuitry may be used in place of or in combination with software instructions.

[0053] The computing device

[0200] also may include a communication interface

[0218] coupled to the bus

[0202] , The communication interface

[0218] provides a two-way data communication coupling to a network link

[0220] that is connected to a local network

[0222] , For example, the communication interface

[0218] may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, the communication interface

[0218] may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, the communication interface

[0218] sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0054] The computing device

[0200] can send messages and receive data, including program code, through the network(s), the network link

[0220] and the communication interface

[0218] , In the Internet example, a server

[0230] might transmit a requested code for an application program through the Internet

[0228] , the ISP

[0226] , the local network

[0222] , the host

[0224] and the communication interface

[0218] , The received code may be executed by the processor

[0204] as it is received, and / or stored in the storage device

[0210] , or other non-volatile storage for later execution.

[0055] The present disclosure is implemented by a system

[0300] (as shown in FIG. 3). In an implementation, the system

[0300] may include the computing device

[0200] (as shown in FIG. 2). It is further noted that the computing device

[0200] is able to perform the steps of a method

[0400] (as shown in FIG. 4).

[0056] Referring to FIG. 3, an exemplary block diagram of a system

[0300] for managing a fault tolerance associated with an Auditor Service (AU) unit

[0302] is shown, in accordance with the exemplary implementations of the present disclosure. The system

[0300] comprises at least one auditor instance unit

[0302] , at least one load balancer (LB) unit

[0304] and at least one AU LB interface

[0306] , Also, all of the components / units of the system

[0300] are assumed to be connected to each other unless otherwise indicated below. As shown in the FIG. 3 all units shown within the system should also be assumed to be connected to each other. Also, in FIG. 3 only a few units are shown, however, the system

[0300] may comprise multiple such units or the system

[0300] may comprise any such numbers of said units, as required to implement the features of the present disclosure. In an implementation, the system

[0300] may reside in a server or a network entity. In yet another implementation, the system

[0300] may reside partly in the server / network entity.

[0057] The system

[0300] is configured for managing fault tolerance associated with an Auditor Service (AU) unit, with the help of the interconnection between the components / units of the system

[0300] , The system

[0300] is based on a microservice based architecture. The fault tolerance refers to a capability of a microservice based system to handle failures even when one of the microservice instances fail. The fault tolerance avoids complete failure of the microservice based system. These microservices (MSs) have specific task and functionality which they all need to perform. The MSs work collectively to achieve the overall functionality of the system

[0300] , Each MS exposes certain APIs which are called by other micro services. A microservice refers to an independent service in a system that performs a specific function. Each microservice may include one or more microservice instances. The one or more microservice instances are responsible for handling requests related to a specific functionality. The AU unit audits the resources in terms of physical memory, RAM and CPU at Inventory Manager. It brings inventory in close sync with real time available / used resources and minimizes the mismatch between Inventory Manager (IM) and real time hardware, by querying via a Swarm Adaptor via API requests. The Swarm Adaptor constantly monitors the real-time resources available and used and the AU reconciles any differences between the real time available and used resources and the information present in the IM.

[0058] The Load Balancer (LB) unit

[0304] is configured to receive a request message from one or more service instances. The service can be a producer service or a consumer service. The consumer service builds a request and sends a POST request to the producer service. The producer service then builds a response and returns it to the consumer service. In an exemplary implementation, the service may comprise one or more microservices. A microservice is a small, loosely coupled distributed service. Each microservice is designed to perform a specific business function and can be developed, deployed, and scaled independently. For example, a microservice may be defined to handle capacity management tasks, another can be defined to handle routing tasks in a network architecture. In the present disclosure, for example, the auditor service is a microservice which is implemented as part of the larger architecture. Further the request message includes parameters required for an application programming interface (API) related to a process / event for which message request is sent. For example, the request message includes parameters like event name, identifier of the LB unit

[0304] , a message type, and the like. In an implementation, the event name is the name of the API. For example:X-Event-Name=GET_DETAILS_FROM_TARGET_MS

[0059] An exemplary implementation for the event name may be GET CNFC INVENTORY AUDIT. This event is for fetching the audit report of actual and allocated resources used by a CNF ranging over various nodes in a region.

[0060] In one example, the request message may be to identify the RAM and CPU usage of another service instance (MS). The request message will be processed via the one or more instances of the AU unit

[0302] , The one or more instances of the AU unit

[0302] refers to multiple segments within the AU unit

[0302] to handle multiple incoming requests at a given time.

[0061] When an auditor service instance starts, it registers itself with the 0AM unit

[0120] , Further, the 0AM unit

[0120] stores data about the initiated set of auditor service instances. The data may include an internet protocol (IP) address, a port, a server disk location, and the like. The port is an endpoint in a connection that allows a system to differentiate between multiple services or applications running on the same IP address. The server disk location refers to a specific path on a server’s storage where files, applications, or data are stored. The 0AM unit

[0120] maintains a ping-pong communication with the set of auditor service instances. The ping-pong communication may check whether an instance from the set of auditor service instances is running or down. So, on request 0AM Unit

[0120] broadcasts a message to all the instances registered to it. This message may be in JSON format and contains information whether an auditor service instance is runningor down. Thus, with this process OAM unit

[0120] gets the availability status and is referred to as predefined auditor status determination rule. In this way, the one or more available auditor service instances from the set of auditor service instances are identified based on the predefined auditor status determination rule.

[0062] In an exemplary aspect of the present disclosure, a set of auditor service instances is received at the LB unit

[0304] from the Orchestration Manager (OAM) unit

[0120] , Further, the set of auditor service instances comprises at least one of the one or more available auditor service instances and one or more unavailable auditor service instances associated with the AU unit

[0302] , The list of the auditor service instances includes at least one of one or more available auditor service instances, and one or more unavailable auditor service instances associated with the AU unit

[0302] , The one or more available auditor service instances refers to the one or more instances of the AU unit

[0302] that may be available to process the request message. The one or more unavailable auditor service instances refers to the one or more instances of the AU unit

[0302] that are not available to process the request message. The one or more auditor service instances may be unavailable due to another request being processed by them. To automatically distribute incoming traffic across multiple instances of the AU unit

[0302] , the AU LB interface

[0306] may monitor the one or more instances of the AU unit

[0302] ,

[0063] In an exemplary aspect of the present disclosure, the LB unit

[0304] identifies one or more available auditor service instances from the set of auditor service instances. As described earlier, the LB unit

[0304] , receives the set of auditor service instances from the OAM unit

[0120] , The set of auditor service instances comprises the one of one or more available auditor service instances and the one or more unavailable auditor service instances. The LB unit

[0304] on receiving the request message identifies the one or more available auditor service instances. The one or more available auditor service instances refers to the instances of the AU unit

[0302] that may be available to process the message request.

[0064] Further, a positive health status is received by the LB unit

[0304] from the Orchestration Manager (OAM) unit

[0120] based on a predefined health determination rule. The predefined health determination rule includes the OAM unit

[0120] to do the ping-pong communication with the one or more available auditor service instances. The OAM unit

[0120] sends the message request to an OAM client that is located in the one or more available auditor service instances. If the one or more auditor service instances is running, the corresponding OAM client sends a response back to OAM unit

[0120] , If the response is received, it means the one or more available auditor serviceinstances are running. Based on the response received, the one or more available auditor service instances may be identified with the positive health status. Further, the positive health status associated with the one or more available auditor service instances is received in real-time.

[0065] In an exemplary aspect of the present disclosure, the LB unit

[0304] is configured to identify a health status of one or more available auditor service instances from the set of auditor service instances of the AU unit

[0302] , As described earlier, the LB unit

[0304] receives the positive heath status associated with the one or more available auditor service instances from the 0AM unit

[0120] , The LB unit

[0304] then identifies the positive health status from the already identified one or more available auditor service instances. The health status may be one of a positive health status or a negative health status. The positive health status is associated with the one or more available service instances of the AU unit

[0302] that are running. The negative health status is associated with the one or more available service instances of the AU unit

[0302] that are not running.

[0066] Herein after, based on the positive health status of an available auditor service instance, the LB unit

[0304] is configured to transmit the request message to an available auditor service instance from the one or more available auditor service instances, based on the positive health status. The request message may be transmitted via the AU LB interface

[0306] , The AU LB interface

[0306] is configured to distribute all incoming requests and outgoing requests. The distribution of the incoming requests balances the load equally on the AU unit

[0302] , Once the LB unit

[0304] has determined the health status of the one or more available auditor service instances, the LB unit

[0304] transmits the received request message to an available auditor service instance which has a positive health status.

[0067] In an exemplary aspect of the present disclosure, the LB unit

[0304] , receives a request message response from the available auditor service instance based on the request message. The request message response is sent by the available auditor service instance which processed the request message sent by the one or more service instances. The request message response comprises response values to the parameters as included in the request message. In an implementation, the request message may comprise an event name which is the name of the API. For example:X-Event-Name=GET_DETAILS_FROM_TARGET_MS

[0068] An exemplary implementation for the event name may be GET CNFC INVENTORY AUDIT. This event is for fetching the audit report of actual andallocated resources used by a CNF ranging over various nodes in a region. Based on this request message, the available auditor service instance will provide the request message response which will include the audit report of actual and allocated resources to the CNF.

[0069] In an exemplary aspect of the present disclosure, the LB unit

[0304] transmits the request message response to the one or more service instances.

[0070] Further, each of the auditor service instance may be served by at least two LB units. The LB unit

[0304] is configured to distribute incoming message requests on each of the auditor service instance by a round robin scheduling. The round robin scheduling refers to an algorithm to distribute tasks in a uniform manner where the incoming requests may be placed in a queue. The LB unit

[0304] may select the first request message in the queue and a time duration for execution is allocated to each of the request messages. After expiry of the time duration, the LB unit

[0304] may select the next request in the queue. Furthermore, the LB unit

[0304] may ensure that an acknowledgement of receiving the message request is sent back to the service instance which may have sent the message request.

[0071] Based on the above, it is seen that the LB unit

[0304] is configured to manage the fault tolerance associated with the AU unit

[0302] by transmitting the request message via the AU LB interface

[0306] , The message request is transmitted by the AU LB interface

[0306] based on the positive health status of an available auditor service instance of the AU unit

[0302] , Further, to manage fault tolerance associated with the AU unit

[0302] , the LB unit

[0304] is configured to transmit the request message to another available auditor service instance from the one or more available auditor service instances, in an event the available auditor service instance from the one or more available auditor service instances becomes unavailable during processing of the request message, ensuring that the AU unit

[0302] does not shutdown in case of a fault occurrence. To transmit the request message to another available auditor service instance, the LB unit

[0304] fetches a state information of the incomplete request message being served from the instance that may have become unavailable. The state information of the event included in the request message tells at what step has the event reached in the overall flow. The state information may be one of an event received, data fetched, processing done, data insertion in database completed, response sent to the requested microservice. The state information may be stored in a database after completion of every step.

[0072] In an implementation, all auditor service instances, maintain the state information in their local cache and also persist it in Elastic Search (ES) Database (DB). In case one of the instances goes down, 0AM unit

[0120] detects it and broadcast the status to other running auditor instances and also the LB unit

[0304] serving the instance. The LB unit

[0304] as such distributes the ingress traffic on the remaining available instances. One of the available auditor service instances takes the ownership of the instance which has gone down. It fetches the state information of the incomplete transaction being served by the instance which has gone down from ES and re-executes them. In case any transaction has not persisted in the ES, there will be a timeout, and the publisher service instance of that request message will re-transmit the same for execution to the LB unit

[0304] , and the LB unit

[0304] transmits to a healthy and available auditor service instance. A time out will also occur because request message acknowledgement was not sent by the auditor service instance in time, indicating failure at the instance.

[0073] Referring to FIG. 4, an exemplary method flow diagram

[0400] for managing fault tolerance associated with an Auditor Service (AU) unit

[0302] , in accordance with exemplary implementations of the present disclosure is shown. In an implementation the method

[0400] is performed by the system

[0300] , Further, in an implementation, the system

[0300] may be present in a server device to implement the features of the present disclosure. Also, as shown in FIG. 4, the method

[0400] starts at step

[0402] ,

[0074] At step

[0404] , the method comprises receiving, by a Load Balancer (LB) unit

[0304] , a request message from one or more service instances. In an implementation, each of the service instance may comprise one or more microservices (MSs). A microservice (MS) is a small, loosely coupled distributed service. These microservices (MSs) have specific task and functionality which they all need to perform. For example, a microservice may be defined to handle capacity management tasks, another can be defined to handle routing tasks in a network. The MSs work collectively to achieve the overall functionality of the system

[0300] , Each MS exposes certain APIs which are called by other micro services. Further the request message includes parameters required for an application programming interface (API) related to a process / event for which message request is sent. For example, the request message includes parameters like event name, identifier of the LB unit

[0304] , a message type, and the like. In an implementation, the event name is the name of the API. For example:X-Event-Name=GET_DETAILS_FROM_TARGET_MS

[0075] An exemplary implementation for the event name may be GET CNFC INVENTORY AUDIT. This event is for fetching the audit report of actual and allocated resources used by a CNF ranging over various nodes in a region.

[0076] When an auditor service instance starts, it registers itself with an Orchestration Manager (0AM) unit

[0120] , Further, the 0AM unit

[0120] stores data about the initiated set of auditor service instances. The data may include an internet protocol (IP) address, a port, a server disk location, and the like. The port is an endpoint in a connection that allows a system to differentiate between multiple services or applications running on the same IP address. The server disk location refers to a specific path on a server’s storage where files, applications, or data are stored. The 0AM unit

[0120] maintains a ping-pong communication with the set of auditor service instances. The ping- pong communication may check whether an instance from the set of auditor service instances is running or down. So, on request 0AM unit

[0120] broadcasts a JSON to all the instances registered to it. This JSON contains information whether an auditor service instance is running or down. Thus, this process gets the availability status and is referred to as predefined auditor status determination rule. In this way, the one or more available auditor service instances from the set of auditor service instances are identified based on the predefined auditor status determination rule.

[0077] In an exemplary aspect of the present disclosure, a set of auditor service instances is received at the LB unit

[0304] from the Orchestration Manager (0AM) unit

[0120] , Further, the set of auditor service instances comprises at least one of the one or more available auditor service instances and one or more unavailable auditor service instances associated with the AU unit

[0302] , The list of the auditor service instances includes at least one of one or more available auditor service instances, and one or more unavailable auditor service instances associated with the AU unit

[0302] , The one or more available auditor service instances refers to the one or more instances of the AU unit

[0302] that may be available to process the request message. The one or more unavailable auditor service instances refers to the one or more instances of the AU unit

[0302] that are not available to process the request message. The one or more auditor service instances may be unavailable due to another request being processed by them. To automatically distribute incoming traffic across multiple instances of the AU unit

[0302] , the AU LB interface

[0306] may monitor the one or more instances of the AU unit

[0302] ,

[0078] At step

[0406] , the method comprises identifying, by the LB unit

[0304] one or more available auditor service instances from a set of auditor service instances. As described earlier, the LB unit

[0304] , receives the set of auditor service instances from the 0AM unit

[0120] , The set of auditorservice instances comprises the one of one or more available auditor service instances and the one or more unavailable auditor service instances. The LB unit

[0304] on receiving the request message identifies the one or more available auditor service instances. The one or more available auditor service instances refers to the instances of the AU unit

[0302] that may be available to process the message request.

[0079] Further, a positive health status is received by the LB unit

[0304] from the Orchestration Manager (0AM) unit

[0120] based on a predefined health determination rule. The predefined health determination rule includes the 0AM unit

[0120] to do the ping-pong communication with the one or more available auditor service instances. The 0AM unit

[0120] sends the message request to an 0AM client that is located in the one or more available auditor service instances. If the one or more auditor service instances is running, the corresponding 0AM client sends a response back to 0AM unit

[0120] , If the response is received, it means the one or more available auditor service instances are running. Based on the response received, the one or more available auditor service instances may be identified with the positive health status. Further, the positive health status associated with the one or more available auditor service instances is received in real-time.

[0080] Next, at Step

[0408] , the method comprises identifying, by the LB unit

[0304] , a health status of one or more available auditor service instances from the set of auditor service instances of the AU unit

[0302] , As described earlier, the LB unit

[0304] receives the positive heath status associated with the one or more available auditor service instances from the 0AM unit

[0120] , The LB unit

[0304] then identifies the positive health status from the already identified one or more available auditor service instances. The health status may be one of a positive health status or a negative health status. The positive health status is associated with the one or more available service instances of the AU unit

[0302] that are running. The negative health status is associated with the one or more available service instances of the AU unit

[0302] that are not running.

[0081] Next, at Step

[0410] , the method comprises transmitting, by the LB unit

[0304] , the request message to an available auditor service instance from the one or more available auditor service instances, based on the positive health status. The request message may be transmitted via the AU LB interface

[0306] , The AU LB interface

[0306] is configured to distribute all incoming requests and outgoing requests. The distribution of the incoming requests balances the load equally on the AU unit

[0302] , Once the LB unit

[0304] has determined the health status of the one or more available auditor service instances, the LB unit

[0304] transmits the received request message to an available auditor service instance which has a positive health status.

[0082] Next, at Step

[0412] , the method comprises receiving, by the LB unit

[0304] , a request message response from the available auditor service instance based on the request message. The request message response is sent by the available auditor service instance which processed the request message sent by the one or more service instances. The request message response comprises response values to the parameters as included in the request message. In an implementation, the request message may comprise an event name which is the name of the API. For example:X-Event-Name=GET_DETAILS_FROM_TARGET_MS

[0083] An exemplary implementation for the event name may be GET CNFC INVENTORY AUDIT. This event is for fetching the audit report of actual and allocated resources used by a CNF ranging over various nodes in a region. Based on this request message, the available auditor service instance will provide the request message response which will include the audit report of actual and allocated resources to the CNF.

[0084] Next, at Step

[0414] , the LB unit

[0304] transmits the request message response to the one or more service instances.

[0085] Each of the auditor service instances may be served by at least two Load Balancer units. The LB unit

[0304] is configured to distribute incoming message requests on each of the microservice instance by a round robin scheduling. The round robin scheduling refers to an algorithm to distribute tasks in a uniform manner where the incoming requests may be placed in a queue. The LB unit

[0304] may select the first request message in the queue and a time duration for execution is allocated to each of the request messages. After expiry of the time duration, the LB unit

[0304] may select a next request in the queue. Furthermore, the LB unit

[0304] may ensure that an acknowledgement of receiving the message request is sent back to the microservice instance which may have sent the message request.

[0086] Next at step

[0416] , the method comprises managing, by the LB unit

[0304] via the AU LB interface

[0306] , the fault tolerance associated with the AU unit

[0302] by transmitting the request message based on the positive health status. The message request is transmitted by the AU LB interface

[0306] based on the positive health status of an available auditor service instance of the AU unit

[0302] , Further, to manage the fault tolerance associated with the AU unit

[0302] , the LB unit

[0304] is configured to transmit the request message to another available auditor serviceinstance from the one or more available auditor service instances, in an event the available auditor service instance from the one or more available auditor service instances becomes unavailable during processing of the request message, ensuring that the AU unit

[0302] does not shutdown in case of a fault occurrence. To transmit the request message to another available auditor service instance, the LB unit

[0304] fetches the status information of the incomplete request message being served from the instance that may have become unavailable. The state information of the event included in the request message tells at what step has the event reached in the overall flow. The state information may be one of an event received, data fetched, processing done, data insertion in database completed, response sent to the requested microservice. The state information may be stored in a database after completion of every step.

[0087] In an implementation, all auditor service instances maintain the state information in their local cache and persist it in Elastic Search (ES) Database (DB). In case one of the instances goes down, 0AM unit

[0120] detects it and broadcasts the status to other running auditor instances and also the LB unit

[0304] serving the instance. The LB unit

[0304] as such distributes the ingress traffic on the remaining available instances. One of the available auditor service instances takes the ownership of the instance which has gone down. It fetches the state information of the incomplete transaction being served by the instance which has gone down from ES and re-executes them. In case any transaction has not persisted in the ES, there will be a timeout, and the publisher service instance of that request message will re-transmit the same for execution to the LB unit

[0304] , and the LB unit

[0304] transmits to a healthy and available auditor service instance. A time out will also occur because request message acknowledgement was not sent by the auditor service instance in time, indicating failure at the instance.

[0088] The method thereafter terminates at step

[0418] ,

[0089] Referring to FIG.5, an exemplary implementation

[0500] of the method for managing a fault tolerance associated with an Auditor Service (AU) unit, is shown in accordance with exemplary implementations of the present disclosure. Further, FIG. 5 is intended to be read in conjunction with FIG. 1 and FIG. 3.

[0090] At Step

[0502] , the Orchestration Manager (0AM)

[0120] sends a set of auditor service instances to the Load Balancer

[0304] , Further, the set of auditor service instances comprises at least one of the one or more available auditor service instances and one or more unavailable auditor service instances associated with the AU unit

[0302] , The list of the auditor service instancesincludes at least one of one or more available auditor service instances, and one or more unavailable auditor service instances associated with the AU unit

[0302] , The one or more available auditor service instances refers to the one or more instances of the AU unit

[0302] that may be available to process a request message from a service instance or a microservice instance. Further, a positive health status is received by the LB unit

[0304] from the Orchestration Manager (0AM) unit

[0120] based on a predefined health determination rule. The predefined health determination rule includes the 0AM unit

[0120] to do the ping-pong communication with the one or more available auditor service instances. The 0AM unit

[0120] sends the message request to an 0AM client that is located in the one or more available auditor service instances. If the one or more auditor service instances is running, the corresponding 0AM client sends a response back to 0AM unit

[0120] , If the response is received, it means the one or more available auditor service instances are running. Based on the response received, the one or more available auditor service instances may be identified with the positive health status. Further, the positive health status associated with the one or more available auditor service instances is received in real-time.

[0091] At Step

[0504] , the one or more microservices

[0501] may send a request message to the Load Balancer

[0304] , Further the request message is related to a process / event which includes parameters required for an application programming interface (API) for which message request is sent. Here, each of the one or more microservices

[0501] is a publisher of the event. An example of the publisher microservices may be an Inventory Manager (IM) and a Swarm Adaptor (SA). For example, the request message includes parameters like event name, identifier of the LB unit

[0304] , resource information, a message type, and the like. The message request is then received by the load balancer (LB)

[0304] from one or more microservice instances

[0501] , Further, based on the request message, the LB unit

[0304] identifies an available auditor service instance from the set of auditor service instances received from the 0AM

[0120] , Further, the LB unit

[0304] also identifies the health status associated with the identified available auditor service instance.

[0092] Next, at step

[0506] , the LB unit

[0304] transmits the request message to an available auditor service instance from the one or more available auditor service instances, based on the positive health status. The request message is transmitted via the AU LB interface

[0306] , The AU LB interface

[0306] is configured to distribute all incoming requests and outgoing requests. The distribution of the incoming requests balances the load equally on the AU unit

[0302] ,

[0093] At Step

[0508] , the LB unit

[0304] , receives a request message response from the available auditor service instance based on the request message. The request message response is sent bythe available auditor service instance which processed the request message sent by the one or more service instances. The request message response comprises response values to the parameters as included in the request message. In an implementation, the request message may comprise an event name which is the name of the API. For example:X-Event-Name=GET_DETAILS_FROM_TARGET_MS

[0094] An exemplary implementation for the event name may be GET CNFC INVENTORY AUDIT. This event is for fetching the audit report of actual and allocated resources used by a CNF ranging over various nodes in a region. Based on this request message, the available auditor service instance will provide the request message response which will include the audit report of actual and allocated resources to the CNF.

[0095] Finally, at Step

[0510] , the LB unit

[0304] transmits the request message response to the one or more service instances who have sent the query request.

[0096] In an implementation, all auditor service instances maintain the state information in their local cache and also persist it in Elastic Search (ES) Database (DB). In case one of the instances goes down, 0AM unit

[0120] detects it and broadcasts the status to other running auditor instances and also the LB unit

[0304] serving the instance. The LB unit

[0304] as such distributes the ingress traffic on the remaining available instances. One of the available auditor service instances takes the ownership of the instance which has gone down. It fetches the state information of the incomplete transaction being served by the instance which has gone down from ES and re-executes them. In case any transaction has not been persisted in the ES, there will be a timeout, and the publisher service instance of that request message will re-transmit the same for execution to the LB unit

[0304] , and the LB unit

[0304] transmits to a healthy and available auditor service instance. A time out will also occur because request message acknowledgement was not sent by the auditor service instance in time, indicating failure at the instance.

[0097] The present disclosure further discloses a non-transitory computer readable storage medium storing instruction for managing a fault tolerance associated with an Auditor Service (AU) unit, the instructions include executable code which, when executed by one or more units of a system, cause a load balancer (LB) unit

[0304] to receive, a request message from one or more service instances. The instructions when executed by the system further cause the LB unit to identify, via the AU LB interface, one or more available auditor service instances from the set of auditor service instances. The instructions when executed by the system further cause the LB unitto identify, a positive health status associated with the one or more available auditor service instances from the set of auditor service instances. The instructions when executed by the system further cause the LB unit to transmit, via the AU LB interface to an available auditor service instance from the one or more available auditor service instances, the request message based on the positive health status. The instructions when executed by the system further cause the LB unit to receive a request message response from the available auditor service instances based on the request message. The instructions when executed by the system further cause the LB unit to transmit the request message response to the one or more service instances. The instructions when executed by the system further cause the LB unit to manage, via the AU LB interface, the fault tolerance associated with the AU unit by transmitting the request message based on the positive health status.

[0098] As is evident from the above, the present disclosure provides a technically advanced solution for managing fault tolerance associated with an Auditor Service (AU) unit. The present disclosure provides a system and a method for managing fault tolerance for any event failure via an AU LB interface by efficiently maintaining incoming and outgoing requests distribution among all AU instances. The present disclosure further provides a solution that effectively routes client requests across all servers in a manner that maximizes speed and capacity utilization. Further, the present disclosure provides the ability to support HTTP / HTTPS in parallel. Additionally, due to high traffic on a particular instance of a dependent MS or unhealthy auditor service instance requests might get failed, which results into failure of system, so to avoid this type of scenario and to ensure that no server is overworked AU LB interface enables a means by which incoming / outgoing requests can be easily distributed among all auditor service instances.

[0099] While considerable emphasis has been placed herein on the disclosed implementations, it will be appreciated that many implementations can be made and that many changes can be made to the implementations without departing from the principles of the present disclosure. These and other changes in the implementations of the present disclosure will be apparent to those skilled in the art, whereby it is to be understood that the foregoing descriptive matter to be implemented is illustrative and non-limiting.

[0100] Further, in accordance with the present disclosure, it is to be acknowledged that the functionality described for the various components / units can be implemented interchangeably. While specific embodiments may disclose a particular functionality of these units for clarity, it is recognized that various configurations and combinations thereof are within the scope of thedisclosure. The functionality of specific units as disclosed in the disclosure should not be construed as limiting the scope of the present disclosure. Consequently, alternative arrangements and substitutions of units, provided they achieve the intended functionality described herein, are considered to be encompassed within the scope of the present disclosure

Claims

We Claim:

1. A method [400] for managing fault tolerance associated with an Auditor Service (AU) unit [302], the method comprising: receiving, by a Load Balancer (LB) unit [304], a request message from one or more service instances; identifying, by the LB unit [304], one or more available auditor service instances from a set of auditor service instances; identifying, by the LB unit [304], a positive health status associated with the one or more available auditor service instances from the set of available auditor service instances;- transmitting, by the LB unit [304] via the AU LB interface [306], the request message to an available auditor service instance from the one or more available auditor service instances based on the positive health status; receiving, by the LB unit [304], a request message response from the available auditor service instance based on the request message;- transmitting, by the LB unit [304], the request message response to the one or more service instances; and managing, by the LB unit [304] via the AU LB interface [306], the fault tolerance associated with the AU unit [302] by transmitting the request message based on the positive health status.

2. The method [400] as claimed in claim 1, wherein the set of auditor service instances comprises at least one of the one or more available auditor service instances and one or more unavailable auditor service instances associated with the AU unit [302],3. The method [400] as claimed in claim 2, wherein the set of auditor service instances is identified by an Orchestration Manager (0AM) unit [120] via the AU LB interface [306] based on a predefined auditor status determination rule.

4. The method as claimed in claim 3, wherein the set of auditor service instances is received at the LB unit [304] from the 0AM unit [120],5. The method [400] as claimed in claim 1, wherein, the managing by the LB unit [304] via the AU LB interface [306], the fault tolerance associated with the AU unit [302] further comprises:transmitting the request message to another available auditor service instance from the one or more available auditor service instances, in an event the available auditor service instance from the one or more available auditor service instances becomes unavailable during processing of the request message.

6. The method [400] as claimed in claim 3, wherein the positive health status associated with the one or more available auditor service instances from the set of available auditor service instances is received by the LB unit [304] from the 0AM unit [120] based on a predefined health determination rule.

7. The method [400] as claimed in claim 6, wherein at least the positive health status associated with the one or more available auditor service instances from the set of available auditor service instances is received by the LB unit [304] from the 0AM unit [120] in real time.

8. A system [300] for optimising fault tolerance associated with an Auditor Service (AU) unit, the system comprises: at least a Load Balancer (LB) unit [304], wherein the load balancer unit is configured to:• receive, a request message from one or more service instances;• identify, one or more available auditor service instances from a set of auditor service instances;• identify, a positive health status associated with the one or more available auditor service instances from the set of auditor service instances;• transmit, via the AU LB interface [306] to an available auditor service instance from the one or more available auditor service instances, the request message based on the positive health status;• receive, a request message response from the available auditor service instance based on the request message;• transmit, the request message response to the one or more service instances; and• manage, via the AU LB interface [306], the fault tolerance associated with the AU unit [302] by transmitting the request message based on the positive health status.

9. The system [300] as claimed in claim 8, wherein the set of auditor service instances comprises at least one of the one or more available auditor service instances and one or more unavailable auditor service instances associated with the AU unit [302],10. The system [300] as claimed in claim 8, wherein the one or more available auditor service instances from the set of auditor service instances are identified by the Orchestration Manager (0AM) unit [120] via the AU LB interface [306] based on a predefined auditor status determination rule.

11. The system as claimed in claim 10, wherein the set of auditor service instances is received at the LB unit [304] from the 0AM unit [120],12. The system [300] as claimed in claim 8, wherein, to manage the fault tolerance associated with the AU unit [302], the LB unit [304] via the AU LB interface [306], is further configured to: transmit the request message to another available auditor service instance from the one or more available auditor service instances, in an event the available auditor service instance from the one or more available auditor service instances becomes unavailable during processing of the request message.

13. The system [300] as claimed in claim 10, wherein the positive health status associated with the one or more available auditor service instances from the set of available auditor service instances is received by the LB unit [304] from the 0AM unit [120] based on a predefined health determination rule.

14. The system [300] as claimed in claim 13, wherein at least the positive health status associated with the one or more available auditor service instances from the set of available auditor service instances is received by the LB unit [304] from the 0AM unit [120] in real time.

15. A non-transitory computer-readable storage medium storing instructions for managing fault tolerance associated with an Auditor Service (AU) unit [302], the storage medium comprising executable code which, when executed by one or more units of a system [300], causes: at least a Load Balancer (LB) unit [304] to:• receive, a request message from one or more service instances;• identify, one or more available auditor service instances from the set of auditor service instances;• identify, a positive health status associated with the one or more available auditor service instances from the set of auditor service instances;• transmit, via the AU LB interface [306] to an available auditor service instance from the one or more available auditor service instances, the request message based on the positive health status;• receive, a request message response from the available auditor service instance based on the request message;• transmit, the request message response to the one or more service instances; and• manage, via the AU LB interface [306], the fault tolerance associated with the AU unit [302] by transmitting the request message based on the positive health status.

Images