Network management system cluster with joint query processing

Abstract

The embodiment of the invention relates to a network management system cluster with joint query processing. A process includes, in response to a migration of a network device deployment from a first network management system cluster to a second network management system cluster, reserving first data in the first network management system cluster for a reservation period. The data represents information about deployment of the network device. The process includes receiving, by a federated layer engine of the second cluster of network management systems, a given query directed to information associated with the deployment of the network device. The process includes determining, by the federated layer engine, whether a query time associated with the given query is within a retention period, and processing, by the federated layer engine, the given query in response to the determination of whether the query time is within the retention period.

Description

Technical Field

[0001] Embodiments of the present application relate to a network management system cluster with federated query processing. Background Art

[0002] Enterprises can use cloud-based network management systems to collect, log, visualize, and analyze network telemetry metrics. Analysis of network telemetry metrics can be beneficial for a variety of purposes, such as identifying network configuration issues, identifying network performance issues, detecting network device failures, identifying security vulnerabilities, and detecting security attacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Figure 1 is a block diagram of a computer network having a network management system (NMS) cluster having a federated query processing architecture according to an example implementation;

[0004] Figure 2 is a flow chart depicting a process for migrating a network device deployment from a first NMS cluster to a second NMS cluster according to an example implementation;

[0005] Figure 3 is a block diagram of a federated query processing architecture implemented according to an example;

[0006] Figure 4 is a timeline illustrating query routing using a federated query processing architecture according to an example implementation;

[0007] Figure 5 is a flow chart depicting processing of a query received in a target NMS cluster having a network device deployment migrated from a migrated NMS cluster according to an example implementation;

[0008] Figure 6 is a flow chart depicting a process for migrating a network device deployment from a first network management system cluster to a second network management system cluster according to an example implementation;

[0009] Figure 7 is an illustration of machine readable instructions according to an example implementation that, when executed by a machine associated with a target network management system cluster, causes the machine to process a query based on a query time and a data retention period; and

[0010] Figure 8 is a block diagram of a system associated with a first network management system cluster having a federation layer engine for selectively directing queries to a first query processing layer of the first network management system cluster or a second query processing layer of a second network management system cluster based on a determination whether a data retention period associated with a network device deployment migration is pending. DETAILED DESCRIPTION

[0011] A network management system (NMS) cluster may include a central NMS component (e.g., a cloud-based component) that manages network devices (also referred to herein as "managed network devices") of a particular network device deployment. In one example, a network device deployment may include a collection of network devices associated with a particular geographic location. For example, a particular NMS cluster may include a network device deployment that includes network devices located in one or more branch networks that are located in the same campus or the same country / region. The central NMS component may include a central server. Managed network devices may generate messages (referred to herein as "network telemetry messages") and send them to the central server. Typically, network telemetry messages may provide information about network telemetry metrics, from which information, an understanding of the state of a network, a network device, or a network device to which (multiple) client devices are connected may be determined directly or indirectly. In one example, a network device deployment may be associated with a particular customer identification (ID).

[0012] The NMS cluster can store information about network device deployments. In one example, the NMS cluster information can include network artifacts (e.g., network device certificates), acquired network telemetry metrics, network device profiles, and network device configuration settings. Clients of the NMS cluster can submit queries that are directed to retrieve specific NMS cluster information.

[0013] Because network devices are deployed in geographic locations that differ from the geographic location of the NMS central component, it may be beneficial to migrate the network devices to different NMS clusters. For example, a network device deployment may be located in Japan, and the corresponding central NMS component may be located in the United States. Migrating a network device deployment to an NMS cluster with a central NMS component located in the same or closer time zone may be beneficial for purposes such as better matching a customer's system startup time with a maintenance window. In another example, a customer may migrate a particular network deployment to an NMS cluster that contains the customer's other network devices, thereby enabling the central NMS component to present a single view of multiple customers' network devices to the customer.

[0014] One method for migrating a network device deployment from a first NMS cluster to a second NMS cluster is to move or migrate all NMS cluster information data from the first NMS cluster to the second NMS cluster. However, this method may be costly from both a time and cost perspective. In addition, this method may encounter challenges due to jurisdictional privacy regulations that restrict the movement of data related to identified or identifiable natural persons.

[0015] According to an example implementation, when a network device deployment is migrated from a first NMS cluster to a second NMS cluster, a minimal amount of data is migrated (e.g., limited to data migration of non-transient network artifact data (such as device certificates)), wherein a majority of the NMS cluster information data is retained in the first NMS cluster for a data retention period. In one example, the data retention period may begin with a migration date and end after a certain number of calendar days (e.g., 30 days, 60 days, or other number of days specified by a service level agreement (SLA)) from the migration date. Users (e.g., system administrators) affiliated with NMS cluster customers may submit queries to the second NMS cluster after the migration date to access and / or modify the NMS cluster information. According to an example implementation, the first NMS cluster and the second NMS cluster have a joint query processing architecture to intelligently direct such queries to the query processing layer of one or both NMS clusters.

[0016] The federated query processing architecture provides a query processing abstraction that makes the migration of network device deployment appear seamless from a customer's perspective. The federated query processing architecture handles the routing of queries based on whether the corresponding query time (e.g., the time when the query is generated, or the time when the query is received by the NMS cluster) is within a data retention period. According to an example implementation, if the query time is within the data retention period (i.e., the data retention period is "suspended"), the federated query processing architecture first directs the query to the query processing layer of the first NMS cluster (the migrated NMS cluster), and if the first NMS cluster does not provide some or all of the data to satisfy the query, the federated query processing architecture directs the query processing to the query processing layer of the second NMS cluster. In addition, according to an example implementation, if the query time is after the end of the data retention period, the federated query processing architecture directs the query solely to the query processing layer of the second NMS cluster.

[0017] refer to Figure 1 As a more specific example, according to some implementations, computer network 100 includes NMS clusters 112 - 1 and 112 - 2 . Figure 1 Certain components of NMS cluster 112-1 are depicted, with the understanding that NMS cluster 112-2 may have similar components. References herein to "NMS cluster 112" refer to either NMS cluster 112-1 or 112-2.

[0018] like Figure 1 As shown, according to some implementations, NMS cluster 112 can include central NMS resources or components 171, such as central server 170 and activation server 160. Additionally, NMS cluster 112 can include network device deployment 118. Network device deployment 118 includes network device 114.

[0019] In the context used herein, an "NMS cluster" refers to a collection of one or more network device deployments and one or more components that provide one or more services (also referred to as "management services" or "NMS services") to manage (multiple) network device deployments. In one example, an NMS cluster may include a single central server (management component) that provides (multiple) NMS services to manage one or more network device deployments. In another example, an NMS cluster may include a high availability (HA) group of central servers, and a specific active central server of the HA group may provide (multiple) NMS services for one or more network device deployments of the NMS cluster. In one example, an NMS cluster may include management components other than a central server, such as an activation server. In the context used herein, a "network device deployment" refers to a collection of one or more network devices that are attached to a specific customer of (multiple) NMS services.

[0020] One or more NMS clusters 112 may be associated with a particular customer. In one example, a network device deployment 118 may correspond to a local branch network (e.g., a local area network (LAN)), such as a network corresponding to a particular building, a group of buildings, a campus, an edge computer system, or a data center. In another example, a network device deployment 118 may include multiple local branch networks. A network device deployment 118 may be associated with a particular geographic location such as a campus site or a city, and according to some implementations, a network device deployment 118 may have a larger geographic span and be associated with a particular state, country, or geographic region including multiple countries. According to some implementations, the central NMS component 171 may be a cloud-based resource that may be located in one or more data centers.

[0021] According to an example implementation, the network devices 114 of the NMS cluster 112 and the central NMS component 171 may communicate via a network fabric 164. According to an example implementation, the network fabric 164 may be associated with one or more types of communication networks, such as, by way of example, a Fibre Channel network, a Compute Express Link (CXL) fabric, a dedicated management network, a local area network (LAN), a WAN, a global network (e.g., the Internet), a wireless network, or any combination thereof.

[0022] According to an example implementation, the central server 170 may provide one or more NMS services. The NMS services may include any of a plurality of different services for visualization, analysis, logging, collection, configuration query and / or monitoring of information associated with the network device deployment 118 (e.g., network telemetry metrics). Data corresponding to the information may be stored in one or more databases 184 of the NMS cluster 112. The central server 170 may provide data to a dashboard such as a graphical user interface (GUI) 167 that allows a user of an associated customer (e.g., a system administrator) to monitor network events. For example, the GUI 167 may display graphical data representing telemetry-affiliated events, trajectories, and conditions. In addition, through a GUI such as the GUI 167, a user may submit a query to the central server 176 for network device deployment information (e.g., network telemetry information, configuration information, and other information associated with the network device deployment 118). In one example, the GUI 167 may be provided by a specific client software executed on the management node 165, or as another example, may be provided by an Internet browser executed on the management node 165. In one example, the GUI 167 may allow a system administrator to manage various aspects of the NMS cluster 112. This management may include configuring the network devices 114, providing configuration data (e.g., configuration files) to be transmitted to the network devices 114, initiating firmware upgrades on the network devices 114, establishing basic subscriptions for network telemetry reports, and various other management-related actions.

[0023] According to an example implementation, when the network device 114 is first connected to a network corresponding to the network device deployment 118, a dynamic host protocol configuration (DHCP) server may provide the network device 114 with an Internet Protocol (IP) address of the activation server 160 (e.g., providing the IP address as a DHCP option). The activation server 160 and its other functions authenticate the network device 114, and the activation server 160 provides the network device 114 with network artifacts (e.g., an IP address and credentials) for being connected to the central server 170 after successful authentication.

[0024] A given network device deployment 118 may be migrated between NMS clusters 112. For the following examples, assume that a particular network device deployment 118 is migrated from NMS cluster 112-2 (which may also be referred to as the "old NMS cluster 112-2" or the "migrated NMS cluster 112-2") to NMS cluster 112-1 (which may also be referred to as the "new NMS cluster 112-1" or the "target NMS cluster 112-1"). After the migration, the old NMS cluster 112-2 retains data representing the previous (and now migrated) network device deployment 118. In one example, the data may represent network telemetry metric information about the network device deployment 118. In another example, the data may represent configuration data (e.g., network artifacts, certificates, configuration settings, and / or configuration files) for the network device deployment 118. According to an example implementation, rather than migrating all of the data from the old NMS cluster 112-2 to the new NMS cluster 112-1, a majority of the data is retained in the database(s) 184 of the old NMS cluster 112-2. For a given period of time, referred to herein as a "data retention period," queries received by the new NMS cluster 112-1 may be provided from data stored in one or both of the NMS clusters 112-1 and 112-2.

[0025] According to an example implementation, the NMS cluster 112 has a component of a federated query processing architecture referred to as a "federated layer engine 180". The federated engine layer 180 of the new NMS cluster 112-1 intelligently directs queries received by the new NMS cluster 112-1 to the new NMS cluster 112-1, the old NMS cluster 112-2, or both the NMS clusters 112-1 and 112-2. The routing of queries by the federated layer engine 180 can be based on factors such as the query time, the migration date, and whether the data retention period has ended. In this case, "query time" refers to a specific time corresponding to the query. In one example, the query time can be a timestamp representing the time when the query was generated. In another example, the query time can be the time when the query was received by the federated layer engine 180.

[0026] In the examples herein, queries requesting data are discussed. According to other implementations, a given query may be used for other purposes, such as storing data in the database 184 of the NMS cluster 112 or modifying data stored in the database 184 of the NMS cluster 112.

[0027] According to an example implementation, the NMS cluster 112 includes a query processing layer 183 that includes a query layer engine 182. According to an example implementation, when a query is directed to the query processing layer 183 of the NMS cluster 112, the query layer engine 182 determines whether data corresponding to the query resides in the database(s) 184 of the NMS cluster 112. If so, the query layer engine 182 provides for the query by providing a query result that includes the data.

[0028] Continuing with the migration example, a query may be submitted to the new NMS cluster 112-1 with a query time in one of three time periods: a first time period before the migration date, a second time period after the migration date when the data retention period is suspended, or a third time period after the data retention period expires. For queries with a query time within the data retention period, the query may potentially be served from either NMS cluster 112-1 or 112-2.

[0029] According to an example implementation, when the new NMS cluster 112-1 receives a query whose query time corresponds to the second period (i.e., when the data retention period is pending), the federation layer engine 180 of the new NMS cluster 112-1 determines whether the query targets data before the migration date. If so, the federation layer engine 180 routes the query to the query processing layer 183 of the old NMS cluster 112-2. The query processing layer 183 of the old NMS cluster 112-2 can determine whether the data corresponding to the data is stored in the old NMS cluster 112-2. If the data corresponding to the data is not stored in the old NMS cluster 112-2, the federation layer engine 180 redirects the query to the query processing layer 183 of the new NMS cluster 112-1.

[0030] According to an example implementation, when the new NMS cluster 112-1 receives a query with a query time corresponding to the second period (i.e., when the data retention period is pending) and targeting data after the migration date, the federation layer engine 180 of the new NMS cluster 112-1 routes the query to the query processing layer 183 of the new NMS cluster 112-1. For queries with corresponding query times after the data retention period ends, the federation engine layer 180 of the new NMS cluster 112-1 routes the query to the query processing layer 183 of the new NMS cluster 112-1.

[0031] According to an example implementation, as further described herein, the query layer engine 182 may provide one or more query processing optimizations. These optimizations may include a cache for storing frequently accessed query data and machine learning-based predictive features for pre-populating the cache based on observed query usage patterns. As an example, the predictive features may include predictive query execution and query enrichment.

[0032] In the context used herein, "network telemetry measurement" refers to information or content from which an understanding of the state of a network, a network device, or a network device to which (multiple) client devices are connected can be determined directly or indirectly. In one example, network telemetry data may include periodically measured statistics of network or network device measurements or measurements. In one example, statistics may be traffic flow for a specific sampling period (e.g., traffic flow for a specific VLAN). In other examples, statistical data may be periodically measured egress bandwidth, ingress bandwidth, latency, round-trip time, or resource usage or host activity. In other examples, network telemetry data may represent the value of a counter of a network device, a configuration setting of a network device, an event log of a network device, a state snapshot of a network device, a configuration snapshot of a network device, or other information about a network device. Network telemetry data may represent an event. In one example, a network device may send a network telemetry message that is triggered by certain change events (e.g., a network telemetry message triggered by a network device sending a disassociation message). In general, network telemetry data may represent information about the control, management, and / or data plane of a network.

[0033] In the context used in this article, "network device" refers to an actual or physical electronic component that can carry out data communication between other components. In one example, a network device can be a switch that operates at the second level (L2) of an open system interconnection (OSI) model to connect components of a computer network together. In another example, a network device can be a third level (L3) switch that connects two components of a computer network together and connects a computer network together. In other examples, a network device can be a component, a processor device, a network interface controller (NIC) or a structure switch including one or more devices in the above-mentioned devices of a gateway, a multicast router, a bridge, a Z generation or a computing high-speed link (CXL) network. A network device can be a wired or wireless device.

[0034] According to some implementations, a server (such as activation server 160 or central server 170) may correspond to machine-readable instructions (or "software") executed on one or more nodes 188 of central network management system 170. In the context used herein, a "node" refers to a processor-based entity with an associated set of hardware and software resources. Figure 1As shown, the node 188 may have one or more associated hardware processors 190 (e.g., one or more central processing unit (CPU) cores, and / or one or more graphics processing unit (GPU) cores) and associated memory 192. The memory 192 is a non-transitory storage medium that may be formed by a semiconductor memory device, a memristor-based memory device, a magnetic memory device, a phase-change memory device, a combination of devices of one or more of these memory technologies, and the like. The memory 192 may represent a collection of memories of both volatile memory devices and non-volatile memory devices. According to some implementations, the memory 192 may store machine-readable instructions that, when executed by the one or more hardware processors 190, cause the (multiple) hardware processors 190 to form instances of components of the activation server 160 and the central server 170. In one example, the memory 192 may store machine-readable instructions that, when executed by the one or more hardware processors 190, cause the (multiple) hardware processors 190 to form instances of the federation layer engine 180 and the query layer engine 182.

[0035] In one example, node 188 can be an actual or physical entity, such as a computer platform or a portion of a computer platform (e.g., a portion corresponding to a set of CPU cores or CPU cores). In this case, a "computer platform" is a processor-based electronic device that has an associated operating system. In an example, the computer platform can be a rack server or a blade server. In another example, node 188 can be a virtual entity that is an abstraction of physical hardware and software resources, such as a virtual machine. Depending on a specific implementation, multiple nodes 188 can be located on one or more virtual machines or physical machines. In addition, according to an example implementation, nodes 188 can be distributed across virtual machines or physical machines located in different geographical locations (e.g., located in different data centers).

[0036] As used herein, an "engine" may refer to one or more circuits. For example, a circuit may be a hardware processing circuit that may include any or some combination of the following: a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit (e.g., a programmable logic device (PLD), such as a complex PLD (CPLD)), a programmable gate array (e.g., a field programmable gate array (FPGA)), an application specific integrated circuit (ASIC), or another hardware processing circuit. An "engine" may refer to a combination of one or more hardware processing circuits and machine-readable instructions (software and / or firmware) executable on the one or more hardware processing circuits. According to some implementations, one or more engines of a central server 170 (such as a federation layer engine 180 or a query layer engine 182) may be formed by one or more processors 190 that execute machine-readable instructions.

[0037] According to some implementations, the central NMS component 171 may include multiple activation servers 160 and multiple central servers 170 for the same NMS cluster 112. In one example, for HA, a given service container of a particular NMS cluster 112 may contain an HA group of activation servers 160 and an HA group of central servers 170, such that if a given active server 160, 170 fails, another server 160, 170 may take over for the failed server 160, 170 of the HA group.

[0038] Figure 2 A process 200 is depicted for migrating a network device deployment from a first NMS cluster (the "old" or "migrated" NMS cluster) to a second NMS cluster (the "new" or "target" NMS cluster). Figure 2 , process 200 includes receiving (block 204) a customer request to migrate a particular network device deployment from a first NMS cluster to a second NMS cluster. In one example, the customer may submit the request to a central server of the first NMS cluster. In another example, the customer may submit the request to a central server of the second NMS cluster.

[0039] According to block 208, process 200 includes modifying provisioning rules on the activation server to onboard network devices to the network device deployment of the second NMS cluster. In one example, block 208 may include removing provisioning rules for the network device from the first NMS cluster and creating provisioning rules for the network device on the activation server of the second NMS cluster. In another example, a particular activation server may be shared by the first NMS cluster and the second NMS cluster, and block 204 involves replacing a first set of provisioning rules on the active server (which specifies how to provision network devices for the first NMS cluster) with a second set of provisioning rules (which specifies how to provision network devices for the second NMS cluster). According to an example implementation, block 204 may include creating new provisioning rules for the network device based on one or more Internet Protocol (IP) addresses and / or domain names associated with the network device deployment of the second NMS cluster.

[0040] According to an example implementation, process 200 includes migrating non-transient network artifact data from a first NMS cluster to a second NMS cluster while retaining remaining data associated with the network device deployment in the first NMS cluster. According to an example implementation, block 212 is a first step in changing the NMS mode from the network device being deployed in the first NMS cluster to the second NMS cluster. In one example, the non-transient data may include data representing tags, ranges, configurations, floor plans, user input data, or other non-transient data.

[0041] According to an example implementation, the next part of the NMS mode change includes providing (block 216) the network device inventory of the network device deployment to the central server of the second NMS cluster. In one example, according to some implementations, the transmission of the network device inventory does not involve inventory reconciliation because the network device inventory remains unchanged.

[0042] According to an example implementation, the next part of the NMS mode change includes providing the new digital certificate to the network devices deployed by the network devices according to block 220. In one example, the network devices may receive the new digital certificate from a certificate certification service (CCS), and the second NMS cluster trusts the digital certificate provided by the root certificate authority (and issued by the activation server).

[0043] According to an example implementation, a fourth part of the NMS mode change includes: according to box 224, storing metadata representing the migration date and data retention period in the second NMS cluster. In one example, box 224 may include updating the activation server of the second NMS cluster with provisioning rules pointing to the second NMS cluster for all network devices being migrated. According to an example implementation, near the end or at the end of the migration of non-transient network artifact data (box 212), the central server of the first NMS cluster may disconnect the network devices and reject new attempted connections by these devices. In one example, a particular network device may be configured to contact the activation server after a predetermined number (e.g., three) of connection failures. The activation server then provides the network device with new provisioning rules for being connected to the second NMS cluster.

[0044] According to an example implementation, the migration data defines a data retention policy for one or more network device deployments. The metadata controls the federation layer engine of a particular NMS cluster (e.g., Figure 1 How the federation layer engine 180 in the NMS cluster routes queries directed to the NMS cluster. In one example, a particular NMS cluster may store the following metadata:

[0045]

[0046] For this example, the metadata stores retention data for two network device deployments that are migrated to the NMS cluster. For a particular customer (corresponding to the second row above), the metadata specifies a migration date of June 1, 2022, a retention period of 90 days, and a uniform resource identifier (URI (e.g., uniform resource locator (URL))) of the old NMS cluster. In addition, for this example, the migration data specifies migration information for a second customer (corresponding to the third row above) for a migration date of June 2, 2022, a retention period of 60 days, and the URI of the old NMS cluster.

[0047] Figure 3A federated query processing architecture 300 is depicted according to an example implementation. For this example, a network device deployment has been migrated from a migrated or old NMS cluster 112-2 to a target or new NMS cluster 112-1. Additionally, for this example, the new NMS cluster 112-1 receives a query 304. Based on a query time associated with the query 304, the federation layer engine 180 of the new NMS cluster 112-1 routes or directs the query 304 (as shown by path 302) to the query processing layer 183 of the old NMS cluster 112-2 or (as shown by path 303) to the query processing layer 183 of the new NMS cluster 112-1. According to an example implementation, the federation layer engine 180 performs routing of the query 304 based on the query time associated with the query 304 and the query processing policy defined by the migration metadata 308.

[0048] Also combined Figure 3 For reference Figure 4 According to an example implementation, the migration metadata 308 defines a migration date 408 and a data retention period end date 412. In one example, the migration date 408 may be a calendar date corresponding to the date on which the migration occurs. In one example, the data retention period end date 412 may correspond to the calendar date on which the retention period specified by the migration metadata 308 ends. As shown at 404, the federation layer engine 180 directs queries with corresponding query times before the migration date 408 to the old NMS cluster 112-2. For queries with corresponding query times corresponding to a pending retention period (e.g., after the migration date 408 and at or before the data retention period end date 412), as shown at 420, the federation layer engine 180 selectively directs the corresponding queries to the old 112-2 and new NMS 112-1 clusters. As further described herein, the federation layer engine 180 may enable selective direction or routing of queries based on whether data is a query (e.g., whether data before or after the migration date 208 is a query). As shown at 424 , the federation layer engine 180 directs queries having corresponding query times after the data retention period end date 412 to the query processing layer 183 of the new NMS cluster 112 - 2 .

[0049] According to an example implementation, the query layer engine 182 has features for optimizing query processing. According to an example implementation, the query layer engine 182 can create time indexes for tables stored in the database 184 before migration, which tables do not already have time indexes. If the query time corresponds to a specific time index of a table, the table is selected to provide the query. According to an example implementation, the query layer engine 182 can create secondary indexes for tables stored in the database 184. Secondary indexes help improve selectivity and speed up query processing time. For example, using a secondary index of a customer ID can improve query processing time because most queries can be based on time and customer ID.

[0050] According to an example implementation, the query layer engine 182 may have a probability filter 324. According to an example implementation, the query layer engine 182 may test the probability filter 324 for a key corresponding to the query 304 to determine whether data corresponding to the key exists in the (multiple) databases 184. According to an example implementation, the query layer engine 182 may also update the probability filter 324 when data is stored and / or retrieved in the (multiple) databases, so that the probability filter 324.

[0051] In one example, the probability filter 324 can be a Bloom filter. The Bloom filter includes a bit array that can be evaluated for the purpose of evaluating or testing whether an element is a member of a set. When used as a probability filter 324, the Bloom filter can be used to evaluate whether the data requested by the query 304 exists in the (multiple) databases 184 of the NMS cluster. More specifically, the Bloom filter can be associated with a set of hash functions that produce corresponding hashes of input values. Each hash then identifies a specific position of the bit array. Testing of the Bloom filter reveals that if the bits stored in the bit array positions identified by the hash are all Boolean TRUE values ​​(e.g., "1" bits), then the input value is stored in (multiple) databases 184. There is a high probability. If any bit stored in the bit array position identified by the hash is a Boolean FALSE value (e.g., "0" bit), the test of the Bloom filter can be used to deterministically exclude the input value from being stored in (multiple) databases 184. When the database(s) are queried for a particular input value, the Bloom filter may be updated by hashing the key with a set of hash functions to identify a bit array position of the bit array and setting the bit at the bit array position to an appropriate Boolean value based on whether the data store contains the input value.

[0052] In one example, the input value for testing and updating the Bloom filter can be associated with one or more database index keys. In one example, the input value can correspond to the customer ID index key. In another example, the input value can correspond to the network device serial number index key. In another example, the input value can correspond to the media access control (MAC) address key. In another example, the input value can correspond to the application ID index key. In one example, a given query 304 can specify a value corresponding to one or more database index keys (e.g., one or more of the customer ID index key, the network device serial number index key, the MAC address index key, and the application ID index key), and the query processing engine 182 can test the Bloom filter with these values ​​to determine whether (multiple) databases 184 store these values.

[0053] Additionally, the query processing engine 182 may update the Bloom filter. In one example, the Bloom filter may indicate a false positive result for a particular index value, as revealed by further processing of the query 304 by the query processing engine 182, and the query processing engine 182 may update the Bloom filter to reflect that the index value is not stored in the database(s) 184. In another example, the query processing engine 182 may update the Bloom filter when the particular index value is stored in the database(s) 184.

[0054] According to some implementations, the NMS cluster may have multiple probability filters 324, for example, a probability filter 342 for each database 184. In other examples, the NMS cluster may have multiple probability filters 342 for different database index keys or different combinations of index keys.

[0055] Among the specific features of the Bloom filter, the bit array may have a bit size (e.g., a size on the order of kilobytes) that is optimized to minimize false positive results. The query processing engine 182 may update the Bloom filter based on query results within a specific sliding time window to assign a specific time granularity (e.g., a granularity of several hours) to the Bloom filter based on the specific use case of the query to the (multiple) databases 184. In one example, three hash functions may be used to provide hashing to evaluate the bit array.

[0056] In the context used herein, a "hash" (also referred to as a "hash", "hash value", "hash digest", "cryptographic hash" or "cryptographic hash value") is generated by applying a cryptographic hash function to a value. A cryptographic hash function can receive an input, and the cryptographic hash function can then generate a hexadecimal string to match the input. For example, the input can include a data string (e.g., a data structure in a memory represented by a starting memory address and an ending memory address). In such an example, based on the data string, the cryptographic hash function outputs a hexadecimal string. In addition, any minor changes to the input can change the output hexadecimal string. In another example, the cryptographic hash function can be a secure hash function (SHA), any hash function approved by the Federal Information Processing Standard (FIPS), any hash function approved by the National Institute of Standards and Technology (NIST), or any other cryptographic hash function. In some examples, the string can use another format instead of the hexadecimal format.

[0057] According to other examples, the probability filter 324 may be a filter other than a Bloom filter, such as a cuckoo filter or other probabilistic data structure.

[0058] like Figure 3As shown, according to some implementations, the query layer engine 182 may include a cache 320 to improve query processing performance. In this way, data corresponding to the query 304 and stored in the cache 320 may be retrieved faster than retrieving the data from the database 304. Any of a number of different strategies may be used to manage the storage of data in the cache 320 and the eviction of data from the cache 320. In one example, the query layer engine 320 may learn query usage patterns over a period of time and pre-populate data into the cache 320 to serve future queries based on the learned query usage patterns. In one example, queries targeting application visibility (e.g., queries targeting insights about applications, such as queries targeting the health, performance, or security of applications) or queries targeting client visibility (e.g., queries targeting insights about client devices, such as queries targeting the health, performance, or security of client devices) may be performance intensive and at the same time follow predictable usage patterns.

[0059] In one example, the query layer engine 182 may observe one or more query usage patterns for a particular customer ID over a predetermined time period (e.g., the last two weeks). In one example, the query layer engine 182 may observe query patterns for a particular customer ID that targets a particular application ID, a particular network device, and a particular network telemetry metric. Continuing with this example, the query layer engine 182 may pre-run (e.g., generate and process) queries that: 1) target the application ID, the network device, and the network telemetry metric and 2) are consistent with the observed patterns. These queries populate the cache 320 with data that is expected to be requested by the query 304 in the near future.

[0060] According to some implementations, the query layer engine 182 can train and use a machine learning model 327 to learn query usage patterns and predict one or more future queries based on the learned query usage patterns. According to some implementations, the model 327 is a deep learning, recursive neural network (RNN) model that learns dependencies from observed sequences, such as a long short-term memory (LSTM) model to predict the time difference in the next query. The LSTM model constructs a time series of queries, where the prediction is based on the past sequence and time difference of the query period. In one example, the LSTM model can be constructed by transforming the query period through a hot encoding based on the following query period categories: monitoring (e.g., three hours, one day, one week, one month, and three months of query periods), unified critical communications (UCC) (e.g., three hours, one day, one week, and one month of query periods), and client monitoring (e.g., three hours, one day, one week, one month, and three months of query periods). Any of multiple features related to past queries can be used to extend the LSTM model, such as customer queries, customer profile clusters, deployment use cases, locations, NMS characteristics, intent of deployment, speculative client counts, business patterns, query patterns, network device types, number of network nodes, custom parameters, security hardening parameters, network classifications, network tags, and other and / or different features.

[0061] Some queries 304 may be for a predetermined period of time, such as a day, a week, etc., and queries 304 from new users may overlap in time with queries that have been previously processed and have corresponding data stored in the cache 320. Thus, for a given query 304 targeting a predetermined period of time, the cache 320 may store a portion of the data requested by the given query 304. According to an example implementation, in response to such a query, the query layer engine 182 relies in part on the cached data, and the query layer engine 182 generates and processes one or more incremental queries to retrieve data corresponding to the data for the predetermined period of time from the database(s) 184 that is not stored in the cache 320.

[0062] According to an example implementation, the query layer engine 182 may modify or enrich the query 304 based on whether some of the data that satisfies the query 304 is stored in the cache 320. In one example, if the query layer engine 182 determines that a subset of the data targeted by the given query 304 is stored in the cache 320, the query layer engine 182 enriches the given query 304 to target all or a portion of the target data that is not stored in the cache 320.

[0063] According to an example implementation, the query layer engine 192 can enrich a particular query 304 based on future query predictions (e.g., predictions of one or more future queries by the model 327). Thus, instead of, for example, pre-running queries to pre-populate the cache 320, the query layer engine 192 can, for example, enrich received queries 304 to cover expected future queries and pre-populate the cache 320 with data targeted by the expected future queries.

[0064] According to an example implementation, the query layer engine 182 includes a transformation engine 328. According to an example implementation, the transformation engine 328 performs aggregation functions to meet specific use cases. In one example, the transformation engine 328 can perform aggregations such as sum, average, maximum, or minimum in response to the query 304. According to some implementations, the transformation engine 328 can perform approximate "top N" aggregations across multiple NMS clusters. According to an example implementation, the transformation engine 328 can return unique counts across NMS clusters, and the federation layer engine can combine the unique counts across multiple clusters to provide a unique count for each entity (e.g., a MAC address or application ID). According to some implementations, in order to enable accurate status information to be displayed across clusters, the query layer engine 182 passes the status information back to the federation layer engine 182 along with a timestamp as information, thereby enabling the federation layer engine 182 to identify and consider the latest status information.

[0065] Figure 5 An example process 500 for processing queries received in a target NMS cluster according to an example implementation is depicted. For this example, a network device deployment has been migrated from a previous or old (or "migrated") NMS cluster to a target NMS cluster.

[0066] refer to Figure 5 , process 500 first includes a decision that can be made by the federation layer engine of the target NMS cluster. The decision includes determining (decision box 504) whether the migration is supported by the service level agreement (SLA). In this manner, in this case, whether the SLA supports the migration refers to the SLA specifying details about the migration, such as the number of calendar days for the data retention period. If the SLA does not support the migration, then according to box 508, process 500 includes the federation layer engine directing the query to be processed by the query processing layer of the target NMS cluster.

[0067] If the SLA supports the migration according to decision box 504, the federation layer engine further determines whether the query targets data before the migration date according to decision box 512. In other words, in decision box 512, process 500 includes determining whether the query time is within the data retention period (i.e., whether the data retention period is still pending). If the query targets data before the migration date, then according to box 508, the federation layer engine directs the query to the query processing layer of the target NMS cluster. However, if according to decision box 512, the federation layer engine determines that the query time is before the migration date, then the federation layer engine first directs the query to the query layer engine of the migrated NMS cluster, as shown in box 514.

[0068] Process 500 next depicts actions that may be taken by the query processing layer of the migrated NMS cluster. According to an example implementation, the query processing layer of the migrated NMS cluster may determine whether data corresponding to the query is stored in the migrated NMS cluster by testing a probability filter, according to decision block 516. If the testing of the probability filter reveals that the query data is not present in the migrated NMS cluster, then according to block 508, the query is redirected back to the query processing layer of the target NMS cluster. According to an example implementation, redirecting the query back to the target NMS cluster may, for example, involve the query processing layer of the migrated NMS cluster indicating to the federation layer engine of the target NMS cluster that the query processing layer of the migrated NMS cluster cannot serve the query, and in response to the indication, the federation layer engine redirecting the query to the query processing layer of the target NMS cluster.

[0069] According to an example implementation, if, according to decision block 516, the test of the probability filter reveals that data corresponding to the query is present in the migrated NMS cluster, then the query processing layer of the migrated NMS cluster continues to process the query. More specifically, according to an example implementation, the query processing layer of the migrated NMS cluster may then determine (decision block 520) whether the data corresponding to the query is present in the cache of the query processing layer. If so, then according to block 522, the data is retrieved from the cache layer. However, if, as determined in decision block 520, the query data is not present in the cache, then according to an example implementation, the query processing layer may apply one or more optimizations. For example, Figure 5As shown, these optimizations may include applying (block 524) machine learning to predict one or more future queries based on one or more observed query patterns. Based on the predicted future query(s), then, according to block 528, the current query may be enriched based on the data in the cache layer and the predicted future query(s) to execute the predicted query, as shown in block 532. Then, according to block 536, the query processing layer of the migrated NMS cluster may store the results of the predicted query(s) execution in the cache. If all data corresponding to the query is present in the cache, as determined at decision block 520, then according to the example implementation, the query processing layer of the migrated NMS cluster retrieves the data from the cache according to block 522.

[0070] Whether the data is retrieved from the cache (block 522) or retrieved by the enriched query(s), process 500 includes determining whether the query result data is to be transformed in decision block 544. If so, the query result data is transformed according to block 548. Process 500 also includes sending (block 552) the query response to the target caller.

[0071] refer to Figure 6 According to an example implementation, process 600 includes: according to box 604, in response to the migration of the network device deployment from the first network management system cluster to the second network management system cluster, retaining first data in the first network management system cluster for a retention period. The data represents information about the network device deployment. In one example, the network device deployment can be migrated to a geographic area that is the same as the geographic area of ​​the central component of the second network management system. In one example, non-transient network artifact data of network devices of the network device deployment can be migrated to the second network management system cluster. In one example, data representing network telemetry metric information of the network device deployment can be retained in one or more databases of the first network management system cluster and not transmitted to the second network management system cluster. In one example, the second network management cluster may include a cloud-based central component, such as a central server and an activation server.

[0072] Process 600 also includes: according to box 608, receiving a given query directed to information associated with the network device deployment by the federation layer engine of the second network management system cluster. According to box 612, process 600 includes determining, by the federation layer engine, whether a query time associated with the given query is within a retention period. In one example, the query time is the time when the given query was generated. In one example, the federation layer engine can correspond to machine-readable instructions executed by one or more hardware processors. In one example, the federation layer engine can determine whether the query time is within the retention period based on metadata. In one example, the metadata can represent a customer ID associated with the network device deployment, a calendar date corresponding to a migration date, and a number of days corresponding to the retention period.

[0073] Process 600 includes processing, by the federation layer engine, the given query in response to a determination of whether the query time is within the retention period, according to block 616. In one example, in response to the federation layer engine determining that the query time is within the retention period and the given query targets data prior to a migration date, the federation layer engine may direct the query to a query layer engine of a first network management cluster. In one example, in response to the federation layer engine determining that the given query targets data after a migration date, the federation layer engine may direct the query to a query layer engine of a second network management cluster.

[0074] In one example, the query layer engine can determine based on a predictive filter whether data targeted by a given cluster is stored in a network management system cluster based on a probabilistic filter. In one example, the probabilistic filter can be a Bloom filter. In one example, the query layer engine can retrieve data targeted by a given query from a cache. In one example, the query layer engine can use a machine learning model to learn query usage patterns and predict future queries based on query usage patterns. In one example, the query layer engine can pre-run predicted future queries to pre-fill the cache. In one example, the query layer engine can enrich received queries based on predicted queries to pre-fill the cache. In one example, the query layer engine can serve queries with data from the cache in response to queries spanning a specific time period, and retrieve the remaining data by generating and processing one or more incremental queries. In one example, the query layer engine can correspond to machine-readable instructions executed by one or more hardware processors.

[0075] refer to Figure 7According to an example implementation, a non-transitory storage medium 700 stores machine-readable instructions 704. The instructions 704, when executed by a machine associated with a target network management system cluster, cause the machine to receive a query directed to information associated with a network device deployment. The network device deployment is migrated from the migrated network management system cluster to the target network management system cluster. In one example, the network device deployment can be migrated to a geographic area that is the same as the geographic area of ​​the central component of the second network management system. In one example, non-transitory network artifact data of network devices of the network device deployment can be migrated to the target network management system cluster. In one example, data representing network telemetry metric information of the network device deployment can be retained in one or more databases of the migrated network management system cluster and not transmitted to the target network management system cluster. In one example, the migrated and target network management system clusters can each include a cloud-based central component, such as a central server and an activation server.

[0076] Instructions 704, when executed by the machine, cause the machine to determine whether the query time is within a data retention period associated with the migration. In one example, the query time is the time when a given query is generated. In one example, the instructions, when executed by the machine, may cause the machine to determine whether the query time is within the retention period based on metadata stored in the target network management system cluster. In one example, the metadata may represent a customer ID associated with the network device deployment, a calendar date corresponding to the migration date, and a number of days corresponding to the retention period.

[0077] Instructions 704, when executed by the machine, cause the machine to direct the query to the query processing layer of the migrated network system management cluster based on a determination that the query time is within the data retention period. In one example, instructions 704, when executed by the machine, cause the machine to route the query to the query processing layer of the target network management system cluster in response to a determination by the migrated network management system cluster that the migrated network management system cluster does not contain data corresponding to the query.

[0078] refer to Figure 8 According to an example implementation, a system associated with a first network management system cluster 800 includes a first query processing layer 804 and a federation layer engine 808. The federation layer engine 808 includes a hardware processor 812. The hardware processor 812 determines whether a data retention period associated with a migration of a network device deployment from a second network management system cluster to a first network management system cluster is pending based on metadata in response to receiving a given query directed to information associated with a network device deployment of the first network management cluster. In one example, the first query processing layer 804 may correspond to machine-readable instructions executed by one or more hardware processors.

[0079] In one example, the network device deployment may be migrated to the same geographic region as the geographic region of the central component of the first network management system cluster. In one example, non-transient network artifact data of the network devices of the network device deployment may be migrated to the first network management system cluster. In one example, data representing network telemetry metric information of the network device deployment may be retained in one or more databases of the second network management system cluster and not transmitted to the first network management system cluster. In one example, the first network management cluster may include a cloud-based central component, such as a central server and an activation server.

[0080] In one example, the metadata may represent a customer ID associated with the network device deployment. In one example, the metadata may represent a calendar date corresponding to a migration date when the second network management system cluster was migrated to the first network management system cluster. In one example, the metadata may represent a number of days corresponding to a data retention period.

[0081] The hardware processor 812 selectively directs the query to the first query processing layer 804 or the second query processing layer of the second network management system cluster in response to receiving a given query, based on a determination of whether the data retention period is pending. In one example, the first query processing layer 804 can retrieve data corresponding to the given query from the cache. In one example, the first query processing layer 804 can use a machine learning model to learn query usage patterns and predict future queries based on the query usage patterns. In one example, the first query processing layer 804 can pre-run predicted future queries to pre-populate the cache. In one example, the first query processing layer 804 can enrich received queries based on the predicted queries to pre-populate the cache. In one example, the first query processing layer 804 can serve the given query with data from the cache and data provided by processing one or more incremental queries in response to the given query spanning a specific time period.

[0082] According to an example implementation, the processing includes: in response to determining that the query time is within the retention period, determining whether the query targets data associated with a time before the migration; and in response to determining that the given query targets data associated with a time before the migration, determining whether the data stored in the first network management system cluster satisfies the given query. The process also includes: in response to determining that the query time is within the retention period and based on the result of the determination of whether the data stored in the first network management system cluster satisfies the query, directing the given query to the query processing layer of the second network management system cluster. A particular advantage is that the time and cost associated with migrating a network device deployment to another network management system cluster is reduced.

[0083] According to an example implementation, determining whether data stored in the first network management system cluster satisfies a given query includes determining that data is stored in the first network management system cluster based on a probabilistic filter.A particular advantage is that time and cost associated with migrating a network device deployment to another network management system cluster is reduced.

[0084] According to an example implementation, determining that the data is stored in the first network management system cluster includes determining a plurality of hashes based on at least one of: a customer identification, a network device serial number, a media access control (MAC) address, and an application identification. Determining that the data is stored in the first network management system cluster also includes providing the plurality of hashes to a probabilistic filter to test the filter against the data. A particular advantage is that time and cost associated with migrating a network device deployment to another network management system cluster is reduced.

[0085] According to an example implementation, it is determined whether a cache of the first network management system cluster stores data corresponding to the query.One particular advantage is that time and cost associated with migrating a network device deployment to another network management system cluster is reduced.

[0086] According to an example implementation, machine learning is applied to learn query usage patterns; and based on the query usage patterns, queries are executed according to the query usage patterns to pre-populate the cache with data corresponding to the query results. A particular advantage is that the time and cost associated with migrating a network device deployment to another network management system cluster is reduced.

[0087] According to an example implementation, in response to a given query, predicting a second query; and processing the second query includes adding result data for the second query to a cache. One particular advantage is that time and cost associated with migrating a network device deployment to another network management system cluster is reduced.

[0088] According to an example implementation, in response to a given query, a second query is predicted, the given query is enriched based on the prediction to provide a third query, and the third query is processed. This includes adding result data for the third query to a cache. A particular advantage is that the time and cost associated with migrating a network device deployment to another network management system cluster is reduced.

[0089] According to an example implementation, the process includes: in response to determining that the query time is within the retention period, determining whether the given query targets data associated with the time after the migration. In response to determining that the given query targets data associated with the time after the migration, directing the given query to a query processing layer of the second network management system cluster. A particular advantage is that the time and cost associated with migrating a network device deployment to another network management system cluster is reduced.

[0090] According to an example implementation, in response to determining that the query time is outside the reserved period, the given query is directed to the query processing layer of the second network management system cluster.One particular advantage is that time and cost associated with migrating a network device deployment to another network management system cluster is reduced.

[0091] According to an example implementation, data corresponding to a given query is retrieved, and in response to the given query, an aggregate function is applied to the retrieved data to derive a query result.One particular advantage is that time and cost associated with migrating a network device deployment to another network management system cluster is reduced.

[0092] The detailed description described herein refers to the accompanying drawings. Where possible, the same reference numerals are used in the drawings and the foregoing description to refer to the same or similar parts. However, it should be clearly understood that the drawings are only for illustration and description. Although several examples are described in this document, modifications, adaptations and other implementations are also possible. Therefore, the detailed description does not limit the disclosed examples. On the contrary, the proper scope of the disclosed examples can be defined by the appended claims.

[0093] The terms used in this article are only used to describe specific examples, and are not restrictive. As used in this article, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" should also include plural forms. The term "multiple" used in this article is defined as two or more. The term "another" used in this article is defined as at least the second or more. Unless otherwise specified, the term "connected" used in this article is defined as connected, whether directly without any intervening element, or indirectly with at least one intervening element. Two elements can be mechanically, electrically or communicatively linked through a communication channel, path, network or system. The term "and / or" used in this article refers to and covers any and all possible combinations of related listed items. It should also be understood that although the terms first, second, third, etc. can be used to describe various elements in this article, these elements should not be limited by these terms, because unless otherwise specified or the context indicates otherwise, these terms are only used to distinguish one element from another element. As used in this article, the term "includes" means including but not limited to, and the term "including" means including but not limited to. The term "based on" means at least partially based on.

[0094] While the present disclosure has been described with respect to a limited number of implementations, those skilled in the art having the benefit of this disclosure will appreciate numerous modifications and variations thereof. The appended claims are intended to cover all such modifications and variations.

Claims

1. A method comprising: In response to migration of a network device deployment from a first network management system cluster to a second network management system cluster, retaining first data in the first network management system cluster for a retention period, wherein the data represents information about the network device deployment; receiving, by a federation layer engine of the second network management system cluster, a given query directed to information associated with the network device deployment; determining, by the federation layer engine, whether a query time associated with the given query is within the retention period; as well as The given query is processed by the federation layer engine responsive to the determination of whether the query time is within the retention period.

2. The method of claim 1 , wherein the processing comprises, in response to determining that the query time is within the retention period: determining whether the given query targets data associated with a time prior to the migration; In response to determining that the given query targets data associated with a time prior to the migration, determining whether data stored in the first network management system cluster satisfies the given query; as well as Based on the result of the determination of whether the query is satisfied by data stored in the first network management system cluster, the given query is directed to a query processing layer of the second network management system cluster. 3 . The method of claim 2 , wherein determining whether data stored in the first network management system cluster satisfies the given query comprises determining that the data is stored in the first network management system cluster based on a probabilistic filter.

4. The method of claim 3, wherein determining that the data is stored in the first network management system cluster comprises: determining a plurality of hashes based on at least one of: a customer identification, a network device serial number, a media access control MAC address, and an application identification; as well as The plurality of hashes are provided to the probabilistic filter to test the probabilistic filter against the data.

5. The method according to claim 2, further comprising: A determination is made as to whether a cache of the first network management system cluster stores the data corresponding to the query.

6. The method according to claim 5, further comprising: Apply machine learning to learn query usage patterns; Based on the query usage pattern, queries are executed according to the query usage pattern to pre-populate the cache with data corresponding to query results.

7. The method of claim 5, further comprising, in response to the given query: predicting a second query; and Processing the second query includes adding result data for the second query to the cache.

8. The method of claim 5, further comprising, in response to the given query: predicting the second query; enriching the given query based on the prediction to provide a third query; Processing the third query includes adding result data for the third query to the cache.

9. The method of claim 1 , wherein the processing comprises, in response to determining that the query time is within the retention period: determining whether the given query targets data associated with a time after the migration; and In response to determining that the given query targets data associated with a time after the migration, the given query is directed to a query processing layer of the second network management system cluster.

10. The method according to claim 1, further comprising: In response to determining that the query time is outside the retention period, the given query is directed to a query processing layer of the second network management system cluster.

11. The method according to claim 1, further comprising: Retrieving data corresponding to the given query; as well as In response to the given query, an aggregate function is applied to the retrieved data to obtain a query result.

12. A non-transitory storage medium storing machine-readable instructions that, when executed by a machine associated with a target network management system cluster, cause the machine to: receiving a query directed to information associated with a network device deployment, wherein the network device deployment is migrated from a migrated network management system cluster to the target network management system cluster; determining whether the query time is within a data retention period associated with the migration; as well as Based on the determination that the query time is within the data retention period, the query is directed to a query processing layer of the migrated network system management cluster.

13. The storage medium of claim 12, wherein the instructions, when executed by the machine, further cause the machine to direct the query to a query processing layer of the target network management system cluster in response to redirection of the query by the migrated network system management cluster.

14. The storage medium of claim 13, wherein the instructions, when executed by the machine, further cause the machine to test a probability filter to determine whether the target network management system cluster stores data corresponding to the query in response to the query being directed to the query processing layer of the target network management system cluster.

15. The storage medium of claim 13, wherein the instructions, when executed by the machine, further cause the machine to determine whether data corresponding to the query is stored in a cache of the query processing layer of the target network management system cluster in response to the query being directed to the query processing layer of the target network management system cluster.

16. The method of claim 15, wherein the instructions, when executed by the machine, further cause the machine to direct the query to the query processing layer of the target network management system cluster in response to: Apply machine learning to learn query usage patterns; Based on the query usage pattern, queries are executed according to the query usage pattern to pre-populate the cache with data corresponding to query results.

17. A system associated with a first network management system cluster, wherein the system comprises: First query processing layer; as well as A federation layer engine comprising a hardware processor, the hardware processor being responsive to receiving a given query directed to information associated with a deployment of network devices of the first network management cluster: determining, based on the metadata, whether a data retention period associated with migration of the network device deployment from a second network management system cluster to the first network management system cluster is pending; as well as Based on the determination of whether the data retention period is pending, the query is selectively directed to the first query processing tier or a second query processing tier of the second network management system cluster.

18. The system of claim 12, wherein the hardware processor is further configured to: determining that the data retention period is pending; In response to determining that the data retention period is pending, directing the query to the second network management system; and In response to the second network management system cluster determining that the second network management system cluster does not store data corresponding to the query, the query is processed.

19. The system of claim 18, wherein the query comprises a first query, and the hardware processor is further configured to: Retrieving first data corresponding to the first query and stored in the first network management system cluster; applying machine learning to predict a second query based on observed query usage patterns; processing the second query to provide second data; The first data and the second data are combined to provide a query response to the first query.

20. The system of claim 18, wherein the query comprises a first query, and the hardware processor is further configured to: applying machine learning to predict a second query based on observed query usage patterns; enriching the first query based on the second query to provide an enriched first query; as well as The enriched first query is processed to provide a query response to the first query and to provide data not corresponding to the first query to pre-populate a cache of the first network management system cluster.

Images