WO2023228233A1 - 障害発生時における自動復旧のためのネットワーク管理 - Google Patents

障害発生時における自動復旧のためのネットワーク管理 Download PDF

Info

Publication number
WO2023228233A1
WO2023228233A1 PCT/JP2022/021061 JP2022021061W WO2023228233A1 WO 2023228233 A1 WO2023228233 A1 WO 2023228233A1 JP 2022021061 W JP2022021061 W JP 2022021061W WO 2023228233 A1 WO2023228233 A1 WO 2023228233A1
Authority
WO
WIPO (PCT)
Prior art keywords
failure
network management
healing
virtual machine
healing process
Prior art date
Application number
PCT/JP2022/021061
Other languages
English (en)
French (fr)
Inventor
正昭 小杉
淳 岡田
合 浦澤
Original Assignee
楽天モバイル株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 楽天モバイル株式会社 filed Critical 楽天モバイル株式会社
Priority to PCT/JP2022/021061 priority Critical patent/WO2023228233A1/ja
Publication of WO2023228233A1 publication Critical patent/WO2023228233A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance

Definitions

  • the present disclosure relates to network management for automatic recovery when a failure occurs.
  • NFV Network Function Virtualization
  • NFV Network Function Virtualization
  • ETSI European Telecommunications Standards Institute
  • NFV defines an NFV architecture (for example, see Patent Document 1).
  • an OSS and MANO work together to perform a healing process to recreate a virtual machine on normal hardware.
  • This healing process is automatically performed using a failure occurrence notification from a failed server or a management node that monitors and manages the server as a trigger.
  • the server and virtual machine may be automatically restored without performing healing processing.
  • healing processing is also performed on servers and virtual machines that can be automatically recovered as described above. In that case, post-processing requires unnecessary human labor such as problem analysis for the failed server or virtual machine, replacement of the failed server, and migration work to return the virtual machine to a normal server after replacement. will occur.
  • the present disclosure aims to reduce operational costs when a failure occurs in a virtualized environment.
  • a network management device includes one or more processors, and at least one of the one or more processors performs acquisition processing, determination processing, and implementation processing. executed.
  • the acquisition process is a process of acquiring broadcast information that is broadcast when a failure occurs in a physical server or a virtual machine built on the physical server in a network virtualization environment.
  • the determination process is a process of determining whether or not it is necessary to perform a healing process to recreate the virtual machine in which the failure has occurred, based on information regarding the failure, when the notification information is acquired.
  • the implementation process is a process for automatically implementing the healing process when it is determined that the healing process needs to be performed.
  • a network management method provides broadcast information that is broadcast when a failure occurs in a physical server or a virtual machine built on the physical server in a network virtualization environment. is obtained, and when the notification information is obtained, it is determined whether or not it is necessary to perform a healing process to recreate the virtual machine in which the failure has occurred, based on the information regarding the failure, and whether the healing process is performed. This includes automatically performing the healing process when it is determined that it is necessary.
  • a network management system includes one or more processors, and at least one of the one or more processors performs acquisition processing, determination processing, and implementation processing. executed.
  • the acquisition process is a process of acquiring broadcast information that is broadcast when a failure occurs in a physical server or a virtual machine built on the physical server in a network virtualization environment.
  • the determination process is a process of determining whether it is necessary to perform a healing process to recreate the virtual machine in which the failure has occurred, based on information regarding the failure, when the notification information is acquired.
  • the implementation process is a process for automatically implementing the healing process when it is determined that the healing process needs to be performed.
  • FIG. 1 is a diagram showing an example of the configuration of a mobile network including a network management device according to this embodiment.
  • FIG. 2 is a diagram showing an example of the internal configuration of the network management system.
  • FIG. 3 is a functional block diagram of the network management section.
  • FIG. 4 is a sequence diagram showing the auto-healing implementation operation.
  • FIG. 5 is an example of an auto-healing execution condition list.
  • FIG. 6 is a flowchart showing the operation of the network management section.
  • FIG. 7 is a block diagram showing an example of the hardware configuration of the network management device.
  • the network management device includes a network management function for automatic recovery when a failure occurs in a mobile network constructed using a virtualization platform. Specifically, when a failure occurs in a physical server or a virtual machine built on the physical server in a network virtualization environment, the network management device performs a healing process to recreate the failed virtual machine. (hereinafter referred to as "auto-healing"). Then, the network management device performs auto-healing when it is determined that it is necessary to perform auto-healing.
  • the network management device in this embodiment acquires notification information (hereinafter referred to as "alert") that is notified when the above-mentioned failure occurs, and performs auto-healing based on the information regarding the failure when the alert is acquired. Determine whether or not implementation is necessary.
  • the information regarding the failure may be an acquired alert, or may be information different from the acquired alert.
  • the information regarding the failure may be, for example, status information indicating the status of the physical server in which the virtual machine in which the failure has occurred is constructed.
  • the physical server state information may be, for example, a system event log (SEL).
  • FIG. 1 is a diagram showing an example of a network configuration of a mobile network 100 including a network management device according to this embodiment.
  • a terminal capable of mobile communication such as a smartphone and a radio access network (RAN) communicate wirelessly, and the information is relayed through a backhaul network (mobile backhaul: MBH).
  • MBH mobile backhaul network
  • the mobile network 100 includes a base station 11 and a plurality of accommodation stations 12 to 14.
  • the accommodation station 12 is an edge data center
  • the accommodation station 13 is a regional data center (RDC)
  • the accommodation station 14 is a central data center (CDC).
  • a backhaul network is configured between the edge data center 12 and the central data center 14.
  • the mobile network 100 in this embodiment may be a virtualized network constructed using a virtualization infrastructure. In this mobile network 100, everything from a backbone network switch to a base station wireless access function is implemented using software on a general-purpose server.
  • the base station 11 includes an antenna, a power distribution board, a battery, and the like.
  • the edge data center 12 is installed near the base station 11, and is connected to each of the plurality of base stations 11 using an optical fiber cable or the like.
  • the edge data center 12 implements RAN-related wireless access functions.
  • the regional data center 13 is connected to a plurality of edge data centers 12 located in the target region. This regional data center 13 implements a firewall/NAT (Network Address Translation), CDN (Content Distribution Network), and various applications for edge computing using software.
  • the central data center 14 is connected to a plurality of regional data centers 13. This central data center 14 implements core functions such as EPC (Evolved Packet Core) and IMS (IP Multimedia Subsystem).
  • each data center such as the edge data center 12, regional data center 13, and central data center 14 is not limited to the number shown in FIG.
  • the number of each data center (accommodating station) such as the edge data center 12, regional data center 13, and central data center 14 is not limited to the number shown in FIG.
  • FIG. 1 only one regional data center 13 and one central data center 14 are shown, but a plurality of regional data centers 13 and a plurality of central data centers 14 may be installed.
  • FIG. 2 is a diagram illustrating an example of the internal configuration of a network management system that constitutes the mobile network 100.
  • NFVI (NFV Infrastructure) 110 is a network function virtualization platform, and is configured to include physical resources, a virtualization layer, and virtualization resources.
  • Physical resources include hardware resources such as computing resources, storage resources, and transmission resources.
  • the virtualization layer is a virtualization layer such as a hypervisor that virtualizes physical resources and provides them to a VNF (Network Function Virtualization) 120.
  • Virtualized resources are virtualized infrastructure resources provided to the VNF 120.
  • the NFVI 110 is a virtualized computing system that virtualizes the hardware resources of a physical server (hereinafter simply referred to as a "server") such as computing, storage, and network functions using a virtualization layer such as a hypervisor. It is a platform that can be used flexibly as virtualized hardware resources such as storage and virtualized networks.
  • a plurality of servers making up the NFVI 110 are arranged in data centers (accommodating stations) 12 to 14.
  • the number, location, wiring, etc. of servers placed in each data center 12 to 14 are determined in advance depending on the data center type (accommodating station type).
  • the installed servers are connected by an internal network so that they can send and receive information to and from each other.
  • the data centers are connected via a network, and servers provided in different data centers can send and receive information to and from each other via the network.
  • the VNF 120 corresponds to an application running on a virtual machine (VM) on a server, and implements network functions in a software manner. Note that although not particularly illustrated, a management function called EM (Element Manager) may be provided for each VNF 120.
  • EM Element Manager
  • the NFVI 110 and VNF 120 in FIG. 2 constitute a virtualization environment. In other words, the virtualization environment is comprised of three layers: hardware, virtualization layer, and virtual machine in order from the bottom layer.
  • the MANO 130 has a virtualization environment management function and an orchestration function.
  • the MANO 130 includes an NFVO (NFV-Orchestrator) 131, a VNFM (VNF-Manager) 132, and a VIM (Virtualized Infrastructure Manager) 133.
  • the NFVO 131 performs orchestration of NFVI resources, life cycle management of network services, and comprehensive operational management of the entire system.
  • This NFVO 131 can perform processing according to instructions from an OSS/BSS (Operation Support System/Business Support System) 140, which will be described later.
  • OSS/BSS Operaation Support System/Business Support System
  • the VNFM 132 performs life cycle management of the VNF 120.
  • the VNFM 132 may be arranged in the MANO 130 as a dedicated VNFM corresponding to each VNF 120.
  • one VNFM 132 may manage the life cycle of two or more VNFs 120.
  • VNFM 132 may be a general-purpose VNFM that corresponds to VNF 120 provided by a different vendor.
  • the VIM 133 performs operational management of resources used by the VNF 120.
  • OSS/BSS 140 is an integrated management system for mobile network 100.
  • OSS is the system (equipment, software, mechanism, etc.) necessary to build and operate the service
  • BSS is the information used for billing, billing, customer support, etc. It is a system (equipment, software, mechanism, etc.).
  • the network management unit 150 determines whether or not to perform auto-healing, and determines whether it is necessary to perform auto-healing. Realizes a network management function that automatically performs auto-healing in certain cases.
  • This network management section 150 constitutes a network management device according to this embodiment.
  • the network management unit 150 can include a management database 150a that manages conditions for performing autohealing.
  • the network management unit 150 uses information included in the alert and information managed in the management database 150a to perform an implementation process to determine whether auto-healing is necessary. Necessity determination processing can be executed. If the network management unit 150 determines that it is necessary to perform auto-healing, it instructs the OSS/BSS 140 and MANO 150 to perform auto-healing.
  • the management database 150a manages data describing conditions for performing auto-healing in a list format.
  • the implementation condition list managed by the management database 150a can be data in which possible failures, confirmation information, and values are associated with each other.
  • the above-mentioned confirmation information is information regarding a failure, and is information that should be additionally checked in addition to the alert in order to determine whether or not to perform auto-healing when the failure occurs.
  • the confirmation information may include, for example, the state information of the physical server described above.
  • the above-mentioned value is a value that can be included in the confirmation information, and is a value related to the conditions for performing auto-healing.
  • the value may be a specific keyword that may be included in the verification information. For example, if the confirmation information includes a specific keyword, the network management unit 150 can determine that it is unnecessary to perform auto-healing. Details of the implementation condition list will be described later.
  • the management database 150a may be a volatile memory, a nonvolatile memory, or the like that acquires the above implementation condition list from an external device and temporarily stores it.
  • the timing of acquiring the implementation condition list is not particularly limited.
  • the network management unit 150 is not limited to being an external function of the OSS/BSS 140 or the MANO 130 as shown in FIG.
  • the network management unit 150 may be provided inside the OSS/BSS 140 or may be provided inside the MANO 130. In this case, the network management function of the network management unit 150 becomes part of the functions of the OSS/BSS 140 and MANO 130.
  • the network management unit 150 executes auto-healing when it is determined that auto-healing is necessary through the execution necessity determination process. You may perform auto-healing instead of instructing.
  • FIG. 3 is a functional block diagram of the network management section 150.
  • the network management section 150 includes an alert acquisition section 151, a confirmation information acquisition section 152, an implementation necessity determination section 153, and an auto-healing implementation instruction section 154.
  • the alert acquisition unit 151 acquires an alert that is notified when a failure occurs in a physical server or virtual machine. When a failure occurs in a physical server or virtual machine, an alert is notified from the NFVI 110 or VNF 120.
  • the alert acquisition unit 151 can acquire alerts notified from the NFVI 110 and VNF 120 via the OSS/BSS 140 and MANO 150.
  • the confirmation information acquisition unit 152 refers to the management database 150a based on the alert acquired by the alert acquisition unit 151, and determines confirmation information to be referred to. Then, the confirmation information acquisition unit 152 acquires the determined confirmation information.
  • the implementation necessity determining unit 153 determines whether or not auto-healing is required based on at least one of the alert acquired by the alert acquisition unit 151 and the confirmation information acquired by the confirmation information acquisition unit 152.
  • FIG. 4 is an example of an auto-healing implementation condition list 400 managed by the management database 150a.
  • the implementation condition list 400 stores list IDs, failure information, confirmation information, and values in association with each other.
  • the list ID is identification information on the list, and may have any value.
  • the fault information is information that can be included in an alert and can be information that indicates the details of the fault.
  • the failure information may include "No response", "FPGA fatal bus error", and the like.
  • OS operating system
  • the alert will include "No response” as the failure information.
  • FPGA Field Programmable Gate Array
  • the alert includes "FPGA fatal bus error" as failure information.
  • the confirmation information is information that should be confirmed in order to determine whether or not to perform auto-healing when a failure occurs, and may be a system event log (SEL) or the like as shown in FIG. 4.
  • SEL is a log in which system events are written, and is state information that is generated for each server and indicates the state of the server. For example, when the server is restarted, "Reboot event" is written in the SEL. Note that an event ID may be written in SEL. In this case, the management database 150a may manage the event ID corresponding to "Reboot event".
  • the implementation necessity determining unit 153 determines that auto-healing is to be performed when the confirmation information does not include a value managed by the implementation condition list 400. In other words, if the confirmation information includes the value managed in the implementation condition list 400, the implementation necessity determining unit 153 determines that there is no need to perform auto-healing.
  • the server and virtual machine may be automatically recovered by simply restarting the server without performing a healing process. For example, if a kernel panic occurs, recovery can be achieved by restarting the server. Furthermore, even if an error such as data writing occurs depending on the communication timing during data transfer, there is a high possibility of recovery by restarting.
  • the server is often set to be automatically rebooted. Therefore, if it is confirmed that the failed server has been restarted after a failure has occurred, the implementation necessity determining unit 153 determines that there is no need to perform auto-healing.
  • the confirmation information acquisition unit 152 refers to the implementation condition list 400 shown in FIG. 4 and determines that the confirmation information to be referred to is SEL. Determine and obtain the SEL of the server where the failure has occurred. Further, the implementation necessity determining unit 153 determines whether the SEL acquired by the confirmation information acquiring unit 152 includes “Reboot event”. Then, the implementation necessity determining unit 153 determines that if the SEL includes "Reboot event", the server has been restarted, and there is a possibility that automatic recovery will occur after the restart is completed, so auto-healing is not performed. Decide that it is unnecessary. On the other hand, if the SEL does not include "Reboot event,” the implementation necessity determining unit 153 determines that auto-healing is necessary because the server has not restarted and will not be automatically restored even if it continues to wait. I judge that.
  • the auto-healing implementation instruction unit 154 instructs the OSS/BSS 140 and MANO 150 to perform auto-healing when the implementation necessity determining unit 153 determines that auto-healing is necessary.
  • the OSS/BSS 140 and MANO 150 that have received the instruction to perform auto-healing recover the VNF by moving or recreating the VNF on a normal server.
  • the configuration of the functional blocks of the network management unit 150 shown in FIG. 3 is an example, and multiple functional blocks may configure one functional block, or any functional block may perform multiple functions. It may be divided into blocks. Further, the plurality of functions of the network management unit 150 may be divided into external functions of the OSS/BSS 140 and MANO 130 of the network management system shown in FIG. 2, internal functions of the OSS/BSS 140, and internal functions of the MANO 130, respectively. Furthermore, although the implementation condition list 400 shown in FIG. 4 shows only the case where the confirmation information is SEL and the value is "Reboot event," the confirmation information and values are not limited to the above.
  • FIG. 5 is a sequence diagram showing the auto-healing implementation operation by the network management unit 150.
  • an alert is notified from the NFVI 110 or VNF 120 where the failure has occurred.
  • the OSS 140 and the MANO 150 detect a failure by receiving an alert notified from the NFVI 110 and the VNF 120 in step S1.
  • the OSS 140 and the MANO 150 transfer the notified alert to the network management unit (NW management unit) 150.
  • the network management unit 150 obtains the alert, refers to the management database 150a, and determines confirmation information associated with the fault that has occurred. Then, in step S3, the network management unit 150 requests the OSS 140 and the MANO 150 to send confirmation information. Then, the OSS 140 and the MANO 150 request the NFVI 110 and/or the VNF 120 to transmit confirmation information in step S4, and obtain the confirmation information in step S5 as a response to the request. For example, if the confirmation information is SEL, the NFVI 110 receives the confirmation information transmission request, acquires the SEL from the target physical server, and transmits the acquired SEL to the OSS 140 and MANO 150. In step S6, the OSS 140 and the MANO 150 transfer the acquired confirmation information to the network management unit 150.
  • step S7 the network management unit 150 performs a process of determining whether auto-healing is necessary based on the acquired confirmation information. If the network management unit 150 determines that auto-healing is necessary through the execution necessity determination process, it instructs the OSS 140 and MANO 150 to execute auto-healing in step S8. In step S9, the OSS 140 and the MANO 150 perform auto-healing. When auto-healing is completed, a completion notification is sent from NFVI 110 and VNF 120 in step S10. The OSS 140 and the MANO 150 receive the completion notification and transfer the completion notification to the network management unit 150 in step S11. Thereby, the network management unit 150 can confirm that auto-healing has been completed.
  • the network management unit 150 is not limited to acquiring confirmation information from the NFVI 110 and VNF 120 via the MANO 130 and OSS 140, as shown in FIG.
  • the network management unit 150 may directly obtain the confirmation information from the NFVI 110 or VNF 120.
  • the network management unit 150 determines that auto-healing is not necessary through the execution necessity determination process, it monitors the operating status of the failed virtual machine (VNF) and determines whether it is operating normally. You may also check to see if it has been restored. In this case, if the virtual machine does not operate normally even after a predetermined period of time has passed since the failure occurred, the network management unit 150 determines that automatic recovery has not been performed and that it is necessary to perform healing processing. It may be re-judged that there is, and the OSS 140 and MANO 150 may be instructed to perform auto-healing.
  • VNF virtual machine
  • FIG. 6 is a flowchart showing the operation of the network management section 150.
  • the network management unit 150 determines whether a failure has been detected. Specifically, the network management unit 150 determines whether an alert has been acquired from the OSS 140 and the MANO 150. If the network management unit 150 has not acquired an alert, it determines that no failure has been detected and remains on standby; if it has acquired an alert, it determines that a failure has been detected and steps S22 to move to.
  • step S22 the network management unit 150 acquires confirmation information corresponding to the failure, and proceeds to step S23.
  • step S23 the network management unit 150 executes a process for determining whether auto-healing is necessary based on the confirmation information acquired in step S22.
  • step S24 if it is determined in the execution necessity determination process in step S23 that auto-healing is not necessary, the network management unit 150 moves to step S25 and determines that auto-healing is necessary. If so, the process moves to step S27.
  • step S25 the network management unit 150 checks the operating state of the failed virtual machine and determines whether the virtual machine is operating normally, that is, whether the virtual machine has automatically recovered. Then, if the network management unit 150 determines that the virtual machine has automatically recovered, it ends the process of FIG. 6, and if it determines that the virtual machine has not automatically recovered, it moves to step S26.
  • step S26 the network management unit 150 determines whether a predetermined time has elapsed since the failure occurred.
  • the predetermined time is set to be longer than the time required for automatic recovery of the virtual machine after a failure occurs.
  • the predetermined time can be set to be longer than the time required to restart the physical server and virtual machine. If the network management unit 150 determines in step S26 that the predetermined time has not elapsed since the failure occurred, the process returns to step S25, and the network management unit 150 determines that the predetermined time has elapsed since the failure occurred. If so, the process moves to step S27. In step S27, the network management unit 150 instructs the OSS 140 and MANO 150 to perform auto-healing.
  • the network management unit 150 allows the virtual machine to automatically recover even if it is determined that it is not necessary to perform auto-healing as a result of the process of determining whether or not to perform auto-healing based on the alert and confirmation information. If not, it is possible to re-judge that auto-healing is necessary and instruct to perform auto-healing. Therefore, it is possible to appropriately prevent the virtual machine from remaining unrecovered.
  • the network management unit 150 which is the network management device in this embodiment, receives a notification when a failure occurs in a physical server or a virtual machine in a network virtualization environment. Based on this information, it is determined whether the healing process is necessary or not. Then, if it is determined that it is necessary to perform the healing process, the network management unit 150 instructs the OSS 140 and the MANO 150 to perform the healing process. In this way, the network management unit 150 causes auto-healing to be performed.
  • the network management unit 150 in this embodiment determines whether or not to perform auto-healing based on the information regarding the failure, and when it is determined that it is necessary to perform auto-healing. Auto-healing can only be performed in Therefore, in an event where auto-recovery occurs without performing auto-healing, it is possible to prevent auto-healing from being performed unnecessarily.
  • the network management unit 150 can determine that it is unnecessary to perform auto-healing. Whether or not a reboot has occurred can be confirmed based on the status information of the physical server.
  • the status information may be, for example, a system event log.
  • the network management unit 150 can quickly understand that a reboot has occurred, and can quickly determine whether auto-healing is necessary.
  • the determination of whether or not to perform auto-healing is not limited to the above. For example, if the failure that has occurred is a physical failure, the network management unit 150 may determine that it is necessary to perform auto-healing. Further, the network management unit 150 may determine that it is unnecessary to perform auto-healing if the failure that has occurred is a logical failure that can be resolved by rebooting. Furthermore, the network management unit 150 may determine that it is unnecessary to perform auto-healing if the failure that has occurred is a failure that has occurred depending on communication timing. Furthermore, if the failure that has occurred is a kernel panic, the network management unit 150 may determine that it is unnecessary to perform auto-healing. Further, the network management unit 150 may determine that auto-healing is not necessary when the failure that has occurred is a bus error between the FPGA and the host.
  • the network management unit 150 may determine whether or not the above implementation is necessary based on the details of the failure. In this case as well, it is possible to appropriately determine whether or not auto-healing is necessary, and it is possible to prevent auto-healing from being performed unnecessarily. Further, in this case, the network management unit 150 may determine the details of the failure based on an alert that is notified when a failure occurs, and determine whether the above-mentioned implementation is necessary. However, if the content of the failure cannot be determined based on the alert alone, the network management unit 150 acquires information that can determine whether or not the above implementation is necessary, separately from the alert, as additional confirmation information, and based on the confirmation information, the network management unit 150 You may decide whether or not to implement it.
  • the confirmation information in this case may be SEL, which is one of the state information of the physical server, or may be information regarding other failures.
  • the network management device may be installed in any general-purpose server that constitutes the backhaul network, core network, etc. of the mobile network 100.
  • the network management device may be implemented in a dedicated server.
  • the network management device may be implemented on a single or multiple computers. When the network management device is implemented in a single computer, as shown in FIG. etc.) 7, communication I/F 8, etc.
  • the network management device 1 may also include external memory.
  • the CPU 2 is composed of one or more processors, and centrally controls operations in the network management device 1. At least some of the functions of each element of the network management unit 150 shown in FIG. 3 can be realized by the CPU 2 executing a program. Note that the program may be stored in a nonvolatile memory such as the ROM 3 or the HDD 5, or may be stored in an external memory such as a removable storage medium (not shown).
  • the elements of the network management unit 150 shown in FIG. 3 may operate as dedicated hardware.
  • the dedicated hardware operates under the control of the CPU 2.
  • a predetermined compiler may be used to automatically generate a dedicated circuit on the FPGA from a program for realizing the functions of each functional module.
  • a Gate Array circuit may be formed in the same manner as an FPGA and realized as hardware. Alternatively, it may be realized by an ASIC (Application Specific Integrated Circuit).
  • aspects of the present disclosure may include a computer-readable storage medium that stores a program, where the program, when executed by the CPU 2 (at least one of the one or more processors) of the network management device 1; , including instructions for causing the network management device 1 to execute at least one of the methods described above.
  • the present disclosure includes the following embodiments.
  • Comprising one or more processors at least one of the one or more processors notifies when a failure occurs in a physical server or a virtual machine built on the physical server in a network virtualization environment. an acquisition process that acquires notification information; and a judgment process that determines whether or not it is necessary to perform a healing process to recreate the virtual machine in which the failure has occurred, based on information regarding the failure when the notification information is acquired. and an implementation process for automatically implementing the healing process when it is determined that the healing process needs to be performed.
  • the judgment process acquires state information of the physical server on which the virtual machine in which the fault has occurred is constructed as information regarding the fault, and determines whether or not the healing process is necessary based on the state information.
  • the network management device according to [1], wherein the network management device determines the following.
  • the determination process may include determining that implementation of the healing process is unnecessary if it is determined based on the status information that the physical server has been restarted after the failure has occurred.
  • the network management device according to [2] or [3].
  • the determination process determines that it is necessary to perform the healing process when the failure is a physical failure, and determines that the healing process is necessary when the failure is a logical failure that can be resolved by rebooting.
  • the network management device according to any one of [1] to [4], wherein the network management device determines that it is unnecessary to perform a healing process.
  • the determination process is characterized in that if the failure is a bus error between an FPGA (Field Programmable Gate Array) and a host, it is determined that the healing process is not necessary. 7].
  • the network management device according to any one of [7].
  • Comprising one or more processors at least one of the one or more processors notifies when a failure occurs in a physical server or a virtual machine built on the physical server in a network virtualization environment.
  • an acquisition process that acquires notification information; and a judgment process that determines whether or not it is necessary to perform a healing process to recreate the virtual machine in which the failure has occurred, based on information regarding the failure when the notification information is acquired.
  • SYMBOLS 11 Base station, 12... Edge data center, 13... Regional data center, 14... Central data center, 100... Mobile network, 110... NFVI, 120... VNF, 130... MANO, 131... NFVO, 132... VNFM, 133... VIM, 140... OSS/BSS, 150... Network management section, 150a... Management database, 151... Alert acquisition section, 152... Confirmation information acquisition section, 153... Implementation necessity judgment section, 154... Auto healing implementation instruction section

Abstract

ネットワーク管理装置は、取得処理と、判断処理と、実施処理と、を実行する。取得処理は、ネットワークの仮想化環境において物理サーバまたは当該物理サーバ上に構築された仮想マシンに障害が発生した際に報知される報知情報を取得する処理である。判断処理は、報知情報が取得された場合に、障害に関する情報に基づいて、障害が発生した仮想マシンを再作成するヒーリング処理の実施の要否を判断する処理である。実施処理は、ヒーリング処理の実施が必要であると判断された場合に、ヒーリング処理を自動的に実施する処理である。

Description

障害発生時における自動復旧のためのネットワーク管理
　本開示は、障害発生時における自動復旧のためのネットワーク管理に関する。
　汎用サーバの性能向上、ネットワーク基盤の充実を背景として、サーバなどの物理リソース上に仮想化されたコンピューティングリソースをオンデマンドで使うクラウドコンピューティング（以下、「クラウド」という。）が広く普及している。また、ネットワーク機能を仮想化し、クラウド上で提供するＮＦＶ（Network Function Virtualization）が知られている。ＮＦＶとは、仮想化技術およびクラウド技術を用いて、これまで専用ハードウェア上で動いていた様々なネットワークサービスのハードウェアとソフトウェアとを分離し、ソフトウェアを仮想化された基盤上で動かす技術である。これによって運用の高度化やコスト削減が期待される。
　そして、近年、モバイルネットワークにおいても仮想化が進められている。
　ＥＴＳＩ（European Telecommunications Standards Institute）　ＮＦＶでは、ＮＦＶのアーキテクチャが定義されている（例えば、特許文献１参照）。
国際公開第２０１６／１２１８０２号
　従来、仮想化環境において、ハードウェア障害や仮想マシン障害が発生した場合、ＯＳＳおよびＭＡＮＯが連携して、正常なハードウェア上に仮想マシンを再作成するヒーリング処理を実施する。このヒーリング処理は、障害が発生したサーバまたは当該サーバを監視・管理する管理ノードからの障害発生通知をトリガとして自動的に実施される。
　しかしながら、障害の内容等によっては、ヒーリング処理を実施せずとも、サーバおよび仮想マシンが自動で復旧する場合がある。
　障害発生通知をトリガとして自動的にヒーリング処理を実施する構成の場合、上記のように自動復旧し得るサーバおよび仮想マシンに対してもヒーリング処理が実施されてしまう。その場合、後処理として、障害が発生したサーバや仮想マシンに対する問題解析作業、障害が発生したサーバの交換作業、交換後の正常なサーバ上へ仮想マシンを戻す移行作業等の余計な人的稼働が生じてしまう。
　そこで、本開示は、仮想化環境における障害発生時の運用コストを削減することを課題とする。
　上記課題を解決するために、本開示の一態様によるネットワーク管理装置は、１以上のプロセッサを備え、前記１以上のプロセッサの少なくとも一つによって、取得処理と、判断処理と、実施処理と、が実行される。前記取得処理は、ネットワークの仮想化環境において物理サーバまたは当該物理サーバ上に構築された仮想マシンに障害が発生した際に報知される報知情報を取得する処理である。前記判断処理は、前記報知情報が取得された場合に、前記障害に関する情報に基づいて、前記障害が発生した仮想マシンを再作成するヒーリング処理の実施の要否を判断する処理である。前記実施処理は、前記ヒーリング処理の実施が必要であると判断された場合に、前記ヒーリング処理を自動的に実施する処理である。
　上記課題を解決するために、本開示の一態様によるネットワーク管理方法は、ネットワークの仮想化環境において物理サーバまたは当該物理サーバ上に構築された仮想マシンに障害が発生した際に報知される報知情報を取得し、前記報知情報が取得された場合に、前記障害に関する情報に基づいて、前記障害が発生した仮想マシンを再作成するヒーリング処理の実施の要否を判断し、前記ヒーリング処理の実施が必要であると判断された場合に、前記ヒーリング処理を自動的に実施する、ことを含む。
　上記課題を解決するために、本開示の一態様によるネットワーク管理システムは、１以上のプロセッサを備え、前記１以上のプロセッサの少なくとも一つによって、取得処理と、判断処理と、実施処理と、が実行される。前記取得処理は、ネットワークの仮想化環境において物理サーバまたは当該物理サーバ上に構築された仮想マシンに障害が発生した際に報知される報知情報を取得する処理である。前記判断処理は、前記報知情報が取得された場合に、前記障害に関する情報に基づいて、前記障害が発生した仮想マシンを再作成するヒーリング処理の実施の要否を判断する処理である。前記実施処理は、前記ヒーリング処理の実施が必要であると判断された場合に、前記ヒーリング処理を自動的に実施する処理である。
　本開示の一態様によれば、仮想化環境における障害発生時の運用コストを削減することができる。
図１は、本実施形態のネットワーク管理装置を含むモバイルネットワークの構成例を示す図である。 図２は、ネットワーク管理システムの内部構成の一例を示す図である。 図３は、ネットワーク管理部の機能ブロック図である。 図４は、オートヒーリング実施動作を示すシーケンス図である。 図５は、オートヒーリングの実施条件リストの一例である。 図６は、ネットワーク管理部の動作を示すフローチャートである。 図７は、ネットワーク管理装置のハードウェア構成の一例を示すブロック図である。
　以下、添付図面を参照して、本開示の実施形態について詳細に説明する。以下に開示される構成要素のうち、同一機能を有するものには同一の符号を付し、その説明を省略する。なお、以下に開示される実施形態は、本開示の一形態であり、装置の構成や各種条件によって適宜修正または変更されるべきものであり、以下の実施形態に限定されるものではない。また、本実施形態で説明されている特徴の組み合わせの全てが上記課題の解決手段に必須のものとは限らない。
　以下、本実施形態に係るネットワーク管理装置が、仮想化基盤で構築されるモバイルネットワークにおける障害発生時の自動復旧のためのネットワーク管理機能を備える場合について説明する。
　具体的には、ネットワーク管理装置は、ネットワークの仮想化環境において物理サーバまたは当該物理サーバ上に構築された仮想マシンに障害が発生した場合に、当該障害が発生した仮想マシンを再作成するヒーリング処理（以下、「オートヒーリング」という。）の実施の要否を判断する。そして、ネットワーク管理装置は、オートヒーリングの実施が必要であると判断された場合、オートヒーリングを実施する。
　本実施形態におけるネットワーク管理装置は、上記障害が発生した際に報知される報知情報（以下、「アラート」という。）を取得し、アラートが取得された場合に、障害に関する情報に基づいてオートヒーリングの実施の要否を判断する。ここで、障害に関する情報は、取得されたアラートであってもよいし、取得されたアラートとは別の情報であってもよい。障害に関する情報は、例えば、障害が発生した仮想マシンが構築されている物理サーバの状態を示す状態情報であってよい。物理サーバの状態情報は、例えばシステムイベントログ（ＳＥＬ）であってよい。
　図１は、本実施形態のネットワーク管理装置を含むモバイルネットワーク１００のネットワーク構成例を示す図である。
　図１に示すモバイルネットワーク１００においては、スマートフォンなどのモバイル通信可能な端末と無線アクセスネットワーク（Radio Access Network：ＲＡＮ）とが無線通信し、その情報をバックホールネットワーク（モバイルバックホール：ＭＢＨ）を中継してコアネットワークに送って処理することで、インターネット２００に接続したり、他社のネットワークと接続して音声通話をしたりすることができる。
　具体的には、モバイルネットワーク１００は、基地局１１と、複数の収容局１２～１４と、を備えて構成される。ここで、収容局１２はエッジデータセンタ、収容局１３は地域データセンタ（Regional Data Center：ＲＤＣ）、収容局１４は中央データセンタ（Central Data Center：ＣＤＣ）である。エッジデータセンタ１２から中央データセンタ１４までの間でバックホールネットワークが構成される。
　本実施形態におけるモバイルネットワーク１００は、仮想化基盤で構築された仮想化ネットワークであってよい。このモバイルネットワーク１００では、汎用的なサーバ上に、基幹網の交換機から基地局の無線アクセス機能までをソフトウェアで実現している。
　基地局１１は、アンテナや配電盤、バッテリー等を備える。
　エッジデータセンタ１２は、基地局１１の近くに設置され、複数の基地局１１とそれぞれ光ファイバーケーブル等で接続されている。エッジデータセンタ１２では、ＲＡＮ関連の無線アクセス機能を実現する。
　地域データセンタ１３は、対象地域に配置される複数のエッジデータセンタ１２と接続されている。この地域データセンタ１３では、ファイアウォール／ＮＡＴ（Network Address Translation）、ＣＤＮ（Content Distribution Network）や、エッジコンピューティングのためのさまざまなアプリケーションをソフトウェアにより実現する。
　中央データセンタ１４は、複数の地域データセンタ１３と接続されている。この中央データセンタ１４では、ＥＰＣ（Evolved Packet Core）やＩＭＳ（IP Multimedia Subsystem）などのコア機能を実現する。
　なお、エッジデータセンタ１２、地域データセンタ１３、中央データセンタ１４といった各データセンタ（収容局）の数は、図１に示す数に限定されない。例えば図１では、地域データセンタ１３および中央データセンタ１４を１つずつしか図示していないが、地域データセンタ１３および中央データセンタ１４はそれぞれ複数設置されていてもよい。
　図２は、モバイルネットワーク１００を構成するネットワーク管理システムの内部構成の一例を示す図である。
　この図２に示す構成要素は、それぞれ参照点を有している。図２に示す構成要素間を結ぶ線は、互いに情報の送受信が可能であることを示している。
　ＮＦＶＩ（NFV Infrastructure）１１０は、ネットワーク機能仮想化基盤であり、物理資源、仮想化層、仮想化資源を含んで構成される。物理資源には、計算資源、記憶資源、伝送資源といったハードウェアリソースが含まれる。仮想化層は、物理資源を仮想化してＶＮＦ（Network Function Virtualization）１２０に提供するためのハイパーバイザー等の仮想化レイヤである。仮想化資源は、ＶＮＦ１２０に提供される仮想化されたインフラ資源である。
　即ち、ＮＦＶＩ１１０は、コンピューティング、ストレージ、ネットワーク機能といった物理サーバ（以下、単に「サーバ」ともいう。）のハードウェアリソースを、ハイパーバイザー等の仮想化レイヤで仮想化した仮想化コンピューティング、仮想化ストレージ、仮想化ネットワークといった仮想化ハードウェアリソースとして柔軟に扱えるようにした基盤である。
　ＮＦＶＩ１１０を構成するサーバは、複数まとめてデータセンタ（収容局）１２～１４に配置される。各データセンタ１２～１４に配置されるサーバの台数や配置位置、配線等は、データセンタのタイプ（収容局タイプ）によって予め定められている。各データセンタ１２～１４では、配置されたサーバが内部のネットワークによって接続されており、互いに情報の送受信を行うことができるようになっている。また、データセンタ間はネットワークで接続されており、異なるデータセンタに設けられたサーバは、当該ネットワークを介して互いに情報の送受信を行うことができるようになっている。
　ＶＮＦ１２０は、サーバ上の仮想マシン（Virtual Machine：ＶＭ）で動作するアプリケーションに対応し、ネットワーク機能をソフトウェア的に実現する。なお、特に図示しないが、ＶＮＦ１２０ごとにＥＭ（Element Manager）という管理機能が設けられていてもよい。
　図２におけるＮＦＶＩ１１０とＶＮＦ１２０とで仮想化環境を構成している。つまり、仮想化環境は、下層から順に、ハードウェア、仮想化レイヤ、仮想マシンの３レイヤで構成される。
　ＭＡＮＯ（Management and Orchestration）１３０は、仮想化環境の管理機能とオーケストレーション機能とを有する。ＭＡＮＯ１３０は、ＮＦＶＯ（NFV-Orchestrator）１３１、ＶＮＦＭ（VNF-Manager）１３２、ＶＩＭ（Virtualized Infrastructure Manager）１３３を備える。
　ＮＦＶＯ１３１は、ＮＦＶＩリソースのオーケストレーションや、ネットワークサービスのライフサイクル管理を行い、システム全体の統合的な運用管理を行う。このＮＦＶＯ１３１は、後述するＯＳＳ／ＢＳＳ（Operation Support System/Business Support System）１４０からの指示に応じた処理を行うことができる。
　ＶＮＦＭ１３２は、ＶＮＦ１２０のライフサイクル管理を行う。なお、ＶＮＦＭ１３２は、ＶＮＦ１２０毎に、それぞれ対応する専用ＶＮＦＭとしてＭＡＮＯ１３０に配置されていてもよい。または、１つのＶＮＦＭ１３２が、２以上のＶＮＦ１２０のライフサイクルを管理してもよい。この場合、ＶＮＦＭ１３２は、異なるベンダから提供されるＶＮＦ１２０に対応する汎用ＶＮＦＭであってもよい。
　ＶＩＭ１３３は、ＶＮＦ１２０が使用するリソースの運用管理を行う。
　ＯＳＳ／ＢＳＳ１４０は、モバイルネットワーク１００の統合管理システムである。
　ここで、ＯＳＳは、サービスを構築し、運営していくために必要なシステム（機器やソフトウェア、仕組みなど）であり、ＢＳＳは、利用料などの課金、請求、顧客対応などのために用いる情報システム（機器やソフトウェア、仕組みなど）である。
　ネットワーク管理部１５０は、ＮＦＶＩの一部である物理サーバまたは仮想マシン（ＶＮＦ）に障害が発生した場合、オートヒーリングの実施の要否を判断し、オートヒーリングの実施が必要であると判断された場合にオートヒーリングを自動的に実施するネットワーク管理機能を実現する。このネットワーク管理部１５０が本実施形態に係るネットワーク管理装置を構成している。
　ネットワーク管理部１５０は、オートヒーリングの実施条件を管理する管理データベース１５０ａを備えることができる。ネットワーク管理部１５０は、障害発生時に通知されるアラートを取得すると、当該アラートに含まれる情報と、管理データベース１５０ａにおいて管理される情報とを用いて、オートヒーリングの実施要否を判断するための実施要否判断処理を実行することができる。そして、ネットワーク管理部１５０は、オートヒーリングの実施が必要であると判断した場合、ＯＳＳ／ＢＳＳ１４０およびＭＡＮＯ１５０に対してオートヒーリングの実施を指示する。
　管理データベース１５０ａは、オートヒーリングの実施条件を記述したデータをリスト形式で管理する。管理データベース１５０ａが管理する実施条件リストは、発生し得る障害と、確認情報と、値と、を対応付けたデータとすることができる。
　ここで、上記の確認情報は、障害に関する情報であって、当該障害が発生した場合に、オートヒーリングの実施要否を判断するためにアラートとは別に追加で確認すべき情報である。確認情報は、例えば、上述した物理サーバの状態情報を含んでよい。
　また、上記の値は、確認情報に含まれ得る値であって、オートヒーリングの実施条件に関する値である。当該値は、確認情報に含まれ得る特定のキーワードであってよい。例えばネットワーク管理部１５０は、確認情報に特定のキーワードが含まれる場合、オートヒーリングの実施が不要であると判断することができる。実施条件リストの詳細については後述する。
　なお、管理データベース１５０ａは、上記の実施条件リストを外部装置から取得し、一時的に記憶する揮発性メモリまたは不揮発性メモリ等であってもよい。この場合、実施条件リストを取得するタイミングは特に限定されない。
　さらに、ネットワーク管理部１５０は、図２に示すようにＯＳＳ／ＢＳＳ１４０やＭＡＮＯ１３０の外部機能である場合に限定されない。ネットワーク管理部１５０は、ＯＳＳ／ＢＳＳ１４０の内部に設けられていてもよいし、ＭＡＮＯ１３０の内部に設けられていてもよい。この場合、ネットワーク管理部１５０が有するネットワーク管理機能は、ＯＳＳ／ＢＳＳ１４０やＭＡＮＯ１３０の機能の一部となる。
　ネットワーク管理部１５０がＯＳＳ／ＢＳＳ１４０やＭＡＮＯ１３０の内部に設けられている場合には、ネットワーク管理部１５０は、実施要否判断処理によりオートヒーリングの実施が必要であると判断した場合、オートヒーリングの実施を指示するのではなく、オートヒーリングを実施してよい。
　図３は、ネットワーク管理部１５０の機能ブロック図である。
　この図３に示すように、ネットワーク管理部１５０は、アラート取得部１５１と、確認情報取得部１５２と、実施要否判断部１５３と、オートヒーリング実施指示部１５４と、を備える。
　アラート取得部１５１は、物理サーバまたは仮想マシンに障害が発生した際に報知されるアラートを取得する。物理サーバや仮想マシンに障害が発生した場合、ＮＦＶＩ１１０やＶＮＦ１２０からアラートが通知される。アラート取得部１５１は、ＮＦＶＩ１１０やＶＮＦ１２０から通知されるアラートを、ＯＳＳ／ＢＳＳ１４０やＭＡＮＯ１５０を介して取得することができる。
　確認情報取得部１５２は、アラート取得部１５１により取得されたアラートをもとに管理データベース１５０ａを参照し、参照すべき確認情報を決定する。そして、確認情報取得部１５２は、決定された確認情報を取得する。
　実施要否判断部１５３は、アラート取得部１５１により取得されたアラートおよび確認情報取得部１５２により取得された確認情報の少なくとも一方に基づいて、オートヒーリングの実施要否を判断する。
　図４は、管理データベース１５０ａが管理するオートヒーリングの実施条件リスト４００の一例である。
　実施条件リスト４００は、リストＩＤ、障害情報、確認情報および値を対応付けて格納する。
　リストＩＤは、リスト上の識別情報であり、任意の値であってよい。
　障害情報は、アラートに含まれ得る情報であって、障害の内容を示す情報とすることができる。障害情報は、図４に示すように、「Ｎｏ　ｒｅｓｐｏｎｓｓｅ」や「ＦＰＧＡ　ｆａｔａｌ　ｂｕｓ　ｅｒｒｏｒ」などを含んでよい。
　例えば、カーネルパニックなどのＯＳ（オペレーティングシステム）のエラーやネットワーク障害などが発生し、要求に対して応答がないままタイムアウトする事象が発生した場合、アラートには障害情報として「Ｎｏ　ｒｅｓｐｏｎｓｓｅ」が含まれる。
　また、例えば、ＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）およびホスト間でのデータ転送時においてエラーが発生した場合、アラートには障害情報として「ＦＰＧＡ　ｆａｔａｌ　ｂｕｓ　ｅｒｒｏｒ」が含まれる。
　確認情報は、障害が発生した場合に、オートヒーリングの実施要否を判断するために確認すべき情報であり、図４に示すように、システムイベントログ（ＳＥＬ）などであってよい。ＳＥＬは、システムイベントが記述されるログであり、サーバごとに生成される、サーバの状態を示す状態情報である。例えばサーバが再起動した場合、ＳＥＬには「Ｒｅｂｏｏｔ　ｅｖｅｎｔ」が記述される。なお、ＳＥＬには、イベントＩＤが記述される場合もある。この場合、管理データベース１５０ａは、「Ｒｅｂｏｏｔ　ｅｖｅｎｔ」に対応するイベントＩＤを管理してもよい。
　本実施形態では、実施要否判断部１５３は、確認情報に、実施条件リスト４００で管理される値が含まれない場合、オートヒーリングを実施すると判断する。換言すると、実施要否判断部１５３は、確認情報に、実施条件リスト４００で管理されている値が含まれている場合には、オートヒーリングを実施する必要がないと判断する。
　障害の内容等によっては、ヒーリング処理を実施せずとも、再起動するだけでサーバおよび仮想マシンが自動復旧する場合がある。例えばカーネルパニックが発生した場合は、サーバを再起動することで復旧し得る。また、データ転送時に、通信タイミングに依存してデータ書き込み等のエラーが発生した場合にも、再起動により復旧する可能性が高い。そして、仮想化環境においては、上記のように再起動により自動復旧し得る障害が発生した場合には、サーバを自動的に再起動させる設定にしていることが多い。
　そこで、実施要否判断部１５３は、障害が発生した後に、障害が発生したサーバの再起動が発生したことが確認できた場合には、オートヒーリングを実施する必要がないと判断する。
　例えば、アラート取得部１５１により取得されたアラートに「Ｎｏ　ｒｅｓｐｏｎｓｓｅ」が含まれる場合、確認情報取得部１５２は、図４に示す実施条件リスト４００を参照し、参照すべき確認情報はＳＥＬであると判断し、障害が発生しているサーバのＳＥＬを取得する。また、実施要否判断部１５３は、確認情報取得部１５２により取得されたＳＥＬに「Ｒｅｂｏｏｔ　ｅｖｅｎｔ」が含まれるか否かを判定する。
　そして、実施要否判断部１５３は、ＳＥＬに「Ｒｅｂｏｏｔ　ｅｖｅｎｔ」が含まれる場合には、サーバの再起動が発生しており、再起動の完了後に自動復旧する可能性があるため、オートヒーリングは不要であると判断する。一方、実施要否判断部１５３は、ＳＥＬに「Ｒｅｂｏｏｔ　ｅｖｅｎｔ」が含まれない場合、サーバの再起動は発生しておらず、このまま待機していても自動復旧されないため、オートヒーリングが必要であると判断する。
　オートヒーリング実施指示部１５４は、実施要否判断部１５３によりオートヒーリングの実施が必要であると判断された場合、ＯＳＳ／ＢＳＳ１４０およびＭＡＮＯ１５０にオートヒーリングの実施を指示する。
　オートヒーリングの実施指示を受けたＯＳＳ／ＢＳＳ１４０およびＭＡＮＯ１５０は、正常なサーバ上にＶＮＦを移動または再作成することで、ＶＮＦを復旧させる。
　なお、図３に示したネットワーク管理部１５０の機能ブロックの構成は一例であり、複数の機能ブロックが１つの機能ブロックを構成するようにしてもよいし、いずれかの機能ブロックが複数の機能を行うブロックに分かれてもよい。
　また、ネットワーク管理部１５０の複数の機能は、それぞれ、図２に示すネットワーク管理システムのＯＳＳ／ＢＳＳ１４０やＭＡＮＯ１３０の外部機能、ＯＳＳ／ＢＳＳ１４０の内部機能、ＭＡＮＯ１３０内部機能に分かれていてもよい。
　さらに、図４に示す実施条件リスト４００では、確認情報がＳＥＬであり、値が「Ｒｅｂｏｏｔ　ｅｖｅｎｔ」である場合のみを示しているが、確認情報および値は上記に限定されない。
　図５は、ネットワーク管理部１５０によるオートヒーリング実施動作を示すシーケンス図である。
　物理サーバまたは仮想マシンに何らかの障害が発生すると、障害が発生したＮＦＶＩ１１０やＶＮＦ１２０からアラートが通知される。ＯＳＳ１４０およびＭＡＮＯ１５０は、ステップＳ１において、ＮＦＶＩ１１０やＶＮＦ１２０から通知されるアラートを受信することで障害を検知する。ステップＳ２では、ＯＳＳ１４０およびＭＡＮＯ１５０は、通知されたアラートをネットワーク管理部（ＮＷ管理部）１５０に転送する。
　ネットワーク管理部１５０は、アラートを取得し、管理データベース１５０ａを参照して、発生した障害に対応付けられた確認情報を決定する。そして、ネットワーク管理部１５０は、ステップＳ３において、ＯＳＳ１４０およびＭＡＮＯ１５０に対して、確認情報の送信を要求する。
　すると、ＯＳＳ１４０およびＭＡＮＯ１５０は、ステップＳ４において、ＮＦＶＩ１１０および／またはＶＮＦ１２０に対して確認情報の送信を要求し、当該要求の応答として、ステップＳ５において確認情報を取得する。例えば確認情報がＳＥＬである場合、ＮＦＶＩ１１０は、確認情報の送信要求を受けて対象の物理サーバからＳＥＬを取得し、取得したＳＥＬをＯＳＳ１４０およびＭＡＮＯ１５０に送信する。ステップＳ６では、ＯＳＳ１４０およびＭＡＮＯ１５０は、取得した確認情報をネットワーク管理部１５０に転送する。
　ステップＳ７では、ネットワーク管理部１５０は、取得された確認情報をもとに、オートヒーリングの実施要否判断処理を行う。
　そして、ネットワーク管理部１５０は、実施要否判断処理によりオートヒーリングの実施が必要であると判断すると、ステップＳ８において、ＯＳＳ１４０およびＭＡＮＯ１５０に対してオートヒーリングの実施を指示する。ステップＳ９では、ＯＳＳ１４０およびＭＡＮＯ１５０は、オートヒーリングを実施する。
　オートヒーリングが完了すると、ステップＳ１０において、ＮＦＶＩ１１０およびＶＮＦ１２０から完了通知が送信される。ＯＳＳ１４０およびＭＡＮＯ１５０は、当該完了通知を受信し、ステップＳ１１において、完了通知をネットワーク管理部１５０に転送する。これにより、ネットワーク管理部１５０は、オートヒーリングが完了したことを確認することができる。
　なお、ネットワーク管理部１５０は、図５に示すように、ＭＡＮＯ１３０やＯＳＳ１４０を介してＮＦＶＩ１１０やＶＮＦ１２０から確認情報を取得する場合に限定されない。ネットワーク管理部１５０は、ＮＦＶＩ１１０やＶＮＦ１２０から直接、確認情報を取得してもよい。
　また、ネットワーク管理部１５０は、実施要否判断処理によりオートヒーリング実施は不要であると判断した場合、障害が発生した仮想マシン（ＶＮＦ）の稼働状態を監視し、正常に稼働したか、つまり自動復旧したかを確認するようにしてもよい。この場合、ネットワーク管理部１５０は、障害が発生してから所定時間が経過しても仮想マシンが正常に稼働しない場合には、自動復旧されていないと判断して、ヒーリング処理の実施が必要であると判断し直し、ＯＳＳ１４０およびＭＡＮＯ１５０に対してオートヒーリングの実施を指示してもよい。
　図６は、ネットワーク管理部１５０の動作を示すフローチャートである。
　まずステップＳ２１において、ネットワーク管理部１５０は、障害を検知したか否かを判定する。具体的には、ネットワーク管理部１５０は、ＯＳＳ１４０およびＭＡＮＯ１５０からアラートを取得したか否かを判定する。そして、ネットワーク管理部１５０は、アラートを取得していない場合には、障害を検知していないと判定してそのまま待機し、アラートを取得した場合には、障害を検知したと判定してステップＳ２２に移行する。
　ステップＳ２２では、ネットワーク管理部１５０は、障害に対応する確認情報を取得し、ステップＳ２３に移行する。
　ステップＳ２３では、ネットワーク管理部１５０は、ステップＳ２２において取得された確認情報に基づいて、オートヒーリングの実施要否判断処理を実行する。
　ステップＳ２４では、ネットワーク管理部１５０は、ステップＳ２３における実施要否判断処理においてオートヒーリングの実施が不要であると判定された場合は、ステップＳ２５に移行し、オートヒーリングの実施が必要であると判定された場合はステップＳ２７に移行する。
　ステップＳ２５では、ネットワーク管理部１５０は、障害が発生した仮想マシンの稼働状態を確認し、仮想マシンが正常に稼働しているか、すなわち、仮想マシンが自動復旧したかを判定する。そして、ネットワーク管理部１５０は、仮想マシンが自動復旧したと判定した場合には図６の処理を終了し、仮想マシンが自動復旧していないと判定した場合にはステップＳ２６に移行する。
　ステップＳ２６では、ネットワーク管理部１５０は、障害が発生してから所定時間が経過しているか否かを判定する。ここで、上記所定時間は、障害が発生してから仮想マシンが自動復旧するまでに要する時間以上に設定する。例えば、上記所定時間は、物理サーバおよび仮想マシンの再起動に要する時間以上に設定することができる。
　そして、ネットワーク管理部１５０は、ステップＳ２６において、障害が発生してから所定時間が経過していないと判定した場合にはステップＳ２５に戻り、障害が発生してから所定時間が経過したと判定した場合には、ステップＳ２７に移行する。
　ステップＳ２７では、ネットワーク管理部１５０は、ＯＳＳ１４０およびＭＡＮＯ１５０に対してオートヒーリングの実施を指示する。
　このように、ネットワーク管理部１５０は、アラートおよび確認情報に基づくオートヒーリングの実施要否判断処理の結果、オートヒーリングの実施は不要であると判断された場合であっても、仮想マシンが自動復旧されない場合には、オートヒーリングの実施が必要であると判断し直してオートヒーリングの実施を指示することができる。したがって、仮想マシンが復旧されないままの状態となることを適切に防止することができる。
　以上説明したように、本実施形態におけるネットワーク管理装置であるネットワーク管理部１５０は、ネットワークの仮想化環境において物理サーバまたは仮想マシンに障害が発生した際に報知されるが取得された場合、当該障害に関する情報に基づいて、ヒーリング処理の実施の要否を判断する。そして、ネットワーク管理部１５０は、ヒーリング処理の実施が必要であると判断された場合に、ＯＳＳ１４０およびＭＡＮＯ１５０にヒーリング処理の実施を指示する。このようにして、ネットワーク管理部１５０は、オートヒーリングを実施させる。
　このように、本実施形態におけるネットワーク管理部１５０は、障害が発生した場合、障害に関する情報に基づいてオートヒーリングの実施の要否を判断し、オートヒーリングの実施が必要であると判断された場合にのみ、オートヒーリングを実施することができる。したがって、オートヒーリングを実施せずとも自動復旧する事象において、不必要にオートヒーリングを実施してしまうことを防止することができる。
　オートヒーリングを実施した場合、後処理として、障害が発生したサーバや仮想マシンに対する問題解析作業、障害が発生したサーバの交換作業、交換後の正常なサーバ上へ仮想マシンを戻す移行作業等の人的稼働が生じる。そのため、本来必要のないオートヒーリングを実施してしまった場合、余計な人的稼働が生じ、その分の運用コスト（人的コスト、時間的コスト等）がかかる。
　本実施形態では、上述したように、不必要にオートヒーリングを実施してしまうことを防止することができるので、上記の運用コストを抑えることができる。
　上述したように、障害の内容によっては、再起動することで物理サーバおよび仮想マシンが自動的に復旧する場合がある。そのため、ネットワーク管理部１５０は、障害が発生した後に物理サーバの再起動が発生したと判断された場合、オートヒーリングの実施は不要であると判断することができる。
　再起動が発生したか否かは、物理サーバの状態情報をもとに確認することができる。ここで、上記状態情報は、例えばシステムイベントログであってよい。ネットワーク管理部１５０は、システムイベントログを参照することにより、再起動が発生したことを速やかに把握することができ、オートヒーリングの実施要否を迅速に判断することができる。
　なお、オートヒーリングの実施要否判断は、上記に限定されるものではない。
　例えば、ネットワーク管理部１５０は、発生した障害が物理的な障害である場合、オートヒーリングの実施が必要であると判断してもよい。また、ネットワーク管理部１５０は、発生した障害が、再起動によって解消される論理的な障害である場合、オートヒーリングの実施は不要であると判断してもよい。
　さらに、ネットワーク管理部１５０は、発生した障害が、通信タイミングに依存して発生した障害である場合、オートヒーリングの実施は不要であると判断してもよい。また、ネットワーク管理部１５０は、発生した障害がカーネルパニックである場合、オートヒーリングの実施は不要であると判断してもよい。また、ネットワーク管理部１５０は、発生した障害が、ＦＰＧＡおよびホスト間のバスエラーである場合に、オートヒーリングの実施は不要であると判断してもよい。
　このように、ネットワーク管理部１５０は、障害の内容に基づいて上記の実施要否を判断してもよい。この場合にも、オートヒーリングの実施の要否を適切に判断することができ、不必要にオートヒーリングを実施してしまうことを防止することができる。
　また、この場合、ネットワーク管理部１５０は、障害が発生した際に報知されるアラートに基づいて障害の内容を判断し、上記の実施要否を判断してもよい。ただし、アラートだけでは障害の内容を判断できない場合には、ネットワーク管理部１５０は、アラートとは別に上記の実施要否を判断可能な情報を追加の確認情報として取得し、確認情報に基づいて上記の実施要否を判断してよい。この場合の確認情報は、物理サーバの状態情報の１つであるＳＥＬであってもよいし、それ以外の障害に関する情報であってもよい。
　以上のように、本実施形態では、物理サーバまたは仮想マシンに障害が発生した場合にオートヒーリングの実施要否を判断し、オートヒーリングの実施が必要であると判断された場合にのみオートヒーリングを実施するので、仮想化環境における障害発生時の運用コストを削減することができる。
　本実施形態に係るネットワーク管理装置は、モバイルネットワーク１００のバックホールネットワークやコアネットワーク等を構成するいずれかの汎用サーバに実装されてよい。なお、ネットワーク管理装置は、専用サーバに実装されてもよい。また、ネットワーク管理装置は、単一または複数のコンピュータ上に実装されてもよい。
　ネットワーク管理装置が単一のコンピュータに実装される場合、図７に示すように、ネットワーク管理装置１は、ＣＰＵ２、ＲＯＭ３、ＲＡＭ４、ＨＤＤ５、入力部（キーボード、ポインティングデバイス等）６、表示部（モニター等）７、通信Ｉ／Ｆ８等を備えることができる。ネットワーク管理装置１はまた、外部メモリを備えてよい。
　ＣＰＵ２は、１つ以上のプロセッサにより構成され、ネットワーク管理装置１における動作を統括的に制御する。図３に示すネットワーク管理部１５０の各要素の少なくとも一部の機能は、ＣＰＵ２がプログラムを実行することで実現することができる。なお、当該プログラムは、ＲＯＭ３やＨＤＤ５等の不揮発性メモリに記憶されていてもよいし、着脱可能な記憶媒体（不図示）等の外部メモリに記憶されていてもよい。
　ただし、図３に示すネットワーク管理部１５０の各要素のうちの少なくとも一部が専用のハードウェアとして動作するようにしてもよい。この場合、専用のハードウェアは、上記ＣＰＵ２の制御に基づいて動作する。
　ハードウェアにより実現される機能については、例えば、所定のコンパイラを用いることで、各機能モジュールの機能を実現するためのプログラムからＦＰＧＡ上に自動的に専用回路を生成すればよい。また、ＦＰＧＡと同様にしてＧａｔｅ　Ａｒｒａｙ回路を形成し、ハードウェアとして実現するようにしてもよい。また、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）により実現するようにしてもよい。
　本開示の態様は、プログラムを記憶するコンピュータ可読記憶媒体を含むことができ、ここでは、当該プログラムが、ネットワーク管理装置１のＣＰＵ２（１つ以上のプロセッサの少なくとも一つ）によって実行されたときに、ネットワーク管理装置１に前述の方法のうちの少なくともいずれかを実行させる命令を含む。
　なお、上記において特定の実施形態が説明されているが、当該実施形態は単なる例示であり、本開示の範囲を限定する意図はない。本明細書に記載された装置及び方法は上記した以外の形態において具現化することができる。また、本開示の範囲から離れることなく、上記した実施形態に対して適宜、省略、置換及び変更をなすこともできる。かかる省略、置換及び変更をなした形態は、請求の範囲に記載されたもの及びこれらの均等物の範疇に含まれ、本開示の技術的範囲に属する。
　（本開示の実施形態）
　本開示は以下の実施形態を含む。
　［１］１以上のプロセッサを備え、前記１以上のプロセッサの少なくとも一つによって、ネットワークの仮想化環境において物理サーバまたは当該物理サーバ上に構築された仮想マシンに障害が発生した際に報知される報知情報を取得する取得処理と、前記報知情報が取得された場合に、前記障害に関する情報に基づいて、前記障害が発生した仮想マシンを再作成するヒーリング処理の実施の要否を判断する判断処理と、前記ヒーリング処理の実施が必要であると判断された場合に、前記ヒーリング処理を自動的に実施する実施処理と、が実行される、ことを特徴とするネットワーク管理装置。
　［２］前記判断処理は、前記障害が発生した仮想マシンが構築されている前記物理サーバの状態情報を前記障害に関する情報として取得し、当該状態情報に基づいて、前記ヒーリング処理の実施の要否を判断することを特徴とする［１］に記載のネットワーク管理装置。
　［３］前記状態情報は、システムイベントログ情報であることを特徴とする［２］に記載のネットワーク管理装置。
　［４］前記判断処理は、前記状態情報に基づいて、前記障害が発生した後に前記物理サーバの再起動が発生したと判断された場合、前記ヒーリング処理の実施は不要であると判断することを特徴とする［２］または［３］に記載のネットワーク管理装置。
　［５］前記判断処理は、前記障害が物理的な障害である場合、前記ヒーリング処理の実施が必要であると判断し、前記障害が再起動によって解消され得る論理的な障害である場合、前記ヒーリング処理の実施は不要であると判断することを特徴とする［１］から［４］のいずれかに記載のネットワーク管理装置。
　［６］前記判断処理は、前記障害が通信タイミングに依存して発生した障害である場合、前記ヒーリング処理の実施は不要であると判断することを特徴とする［１］から［５］のいずれかに記載のネットワーク管理装置。
　［７］前記判断処理は、前記障害がカーネルパニックである場合、前記ヒーリング処理の実施は不要であると判断することを特徴とする［１］から［６］のいずれかに記載のネットワーク管理装置。
　［８］前記判断処理は、前記障害がＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）およびホスト間のバスエラーである場合、前記ヒーリング処理の実施は不要であると判断することを特徴とする［１］から［７］のいずれかに記載のネットワーク管理装置。
　［９］前記判断処理は、前記ヒーリング処理の実施が不要であると判断した場合、前記障害が発生した仮想マシンの稼働状態を監視し、前記障害が発生してから所定時間が経過しても前記仮想マシンが正常に稼働しない場合、前記ヒーリング処理の実施が必要であると判断し直すことを特徴とする［１］から［８］のいずれかに記載のネットワーク管理装置。
　［１０］ネットワークの仮想化環境において物理サーバまたは当該物理サーバ上に構築された仮想マシンに障害が発生した際に報知される報知情報を取得し、前記報知情報が取得された場合に、前記障害に関する情報に基づいて、前記障害が発生した仮想マシンを再作成するヒーリング処理の実施の要否を判断し、前記ヒーリング処理の実施が必要であると判断された場合に、前記ヒーリング処理を自動的に実施する、ことを含むことを特徴とするネットワーク管理方法。
［１１］１以上のプロセッサを備え、前記１以上のプロセッサの少なくとも一つによって、ネットワークの仮想化環境において物理サーバまたは当該物理サーバ上に構築された仮想マシンに障害が発生した際に報知される報知情報を取得する取得処理と、前記報知情報が取得された場合に、前記障害に関する情報に基づいて、前記障害が発生した仮想マシンを再作成するヒーリング処理の実施の要否を判断する判断処理と、前記ヒーリング処理の実施が必要であると判断された場合に、前記ヒーリング処理を自動的に実施する実施処理と、が実行される、ことを特徴とするネットワーク管理システム。
　１１…基地局、１２…エッジデータセンタ、１３…地域データセンタ、１４…中央データセンタ、１００…モバイルネットワーク、１１０…ＮＦＶＩ、１２０…ＶＮＦ、１３０…ＭＡＮＯ、１３１…ＮＦＶＯ、１３２…ＶＮＦＭ、１３３…ＶＩＭ、１４０…ＯＳＳ／ＢＳＳ、１５０…ネットワーク管理部、１５０ａ…管理データベース、１５１…アラート取得部、１５２…確認情報取得部、１５３…実施要否判断部、１５４…オートヒーリング実施指示部

 

Claims (11)

  1. 　１以上のプロセッサを備え、
    　前記１以上のプロセッサの少なくとも一つによって、
    　ネットワークの仮想化環境において物理サーバまたは当該物理サーバ上に構築された仮想マシンに障害が発生した際に報知される報知情報を取得する取得処理と、
    　前記報知情報が取得された場合に、前記障害に関する情報に基づいて、前記障害が発生した仮想マシンを再作成するヒーリング処理の実施の要否を判断する判断処理と、
    　前記ヒーリング処理の実施が必要であると判断された場合に、前記ヒーリング処理を自動的に実施する実施処理と、
    　が実行される、
    　ことを特徴とするネットワーク管理装置。
  2. 　前記判断処理は、前記障害が発生した仮想マシンが構築されている前記物理サーバの状態情報を前記障害に関する情報として取得し、当該状態情報に基づいて、前記ヒーリング処理の実施の要否を判断する
    　ことを特徴とする請求項１に記載のネットワーク管理装置。
  3. 　前記状態情報は、システムイベントログ情報であることを特徴とする請求項２に記載のネットワーク管理装置。
  4. 　前記判断処理は、前記状態情報に基づいて、前記障害が発生した後に前記物理サーバの再起動が発生したと判断された場合、前記ヒーリング処理の実施は不要であると判断する
    　ことを特徴とする請求項２に記載のネットワーク管理装置。
  5. 　前記判断処理は、
    　前記障害が物理的な障害である場合、前記ヒーリング処理の実施が必要であると判断し、
    　前記障害が再起動によって解消され得る論理的な障害である場合、前記ヒーリング処理の実施は不要であると判断する
    　ことを特徴とする請求項１に記載のネットワーク管理装置。
  6. 　前記判断処理は、前記障害が通信タイミングに依存して発生した障害である場合、前記ヒーリング処理の実施は不要であると判断する
    　ことを特徴とする請求項１に記載のネットワーク管理装置。
  7. 　前記判断処理は、前記障害がカーネルパニックである場合、前記ヒーリング処理の実施は不要であると判断する
    　ことを特徴とする請求項１に記載のネットワーク管理装置。
  8. 　前記判断処理は、前記障害がＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）およびホスト間のバスエラーである場合、前記ヒーリング処理の実施は不要であると判断する
    　ことを特徴とする請求項１に記載のネットワーク管理装置。
  9. 　前記判断処理は、
    　前記ヒーリング処理の実施が不要であると判断した場合、前記障害が発生した仮想マシンの稼働状態を監視し、
    　前記障害が発生してから所定時間が経過しても前記仮想マシンが正常に稼働しない場合、前記ヒーリング処理の実施が必要であると判断し直す
    　ことを特徴とする請求項１に記載のネットワーク管理装置。
  10. 　ネットワークの仮想化環境において物理サーバまたは当該物理サーバ上に構築された仮想マシンに障害が発生した際に報知される報知情報を取得し、
    　前記報知情報が取得された場合に、前記障害に関する情報に基づいて、前記障害が発生した仮想マシンを再作成するヒーリング処理の実施の要否を判断し、
    　前記ヒーリング処理の実施が必要であると判断された場合に、前記ヒーリング処理を自動的に実施する、
    　ことを含むことを特徴とするネットワーク管理方法。
  11. 　１以上のプロセッサを備え、
    　前記１以上のプロセッサの少なくとも一つによって、
    　ネットワークの仮想化環境において物理サーバまたは当該物理サーバ上に構築された仮想マシンに障害が発生した際に報知される報知情報を取得する取得処理と、
    　前記報知情報が取得された場合に、前記障害に関する情報に基づいて、前記障害が発生した仮想マシンを再作成するヒーリング処理の実施の要否を判断する判断処理と、
    　前記ヒーリング処理の実施が必要であると判断された場合に、前記ヒーリング処理を自動的に実施する実施処理と、
    　が実行される、
    　ことを特徴とするネットワーク管理システム。

     
     
     
PCT/JP2022/021061 2022-05-23 2022-05-23 障害発生時における自動復旧のためのネットワーク管理 WO2023228233A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/021061 WO2023228233A1 (ja) 2022-05-23 2022-05-23 障害発生時における自動復旧のためのネットワーク管理

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/021061 WO2023228233A1 (ja) 2022-05-23 2022-05-23 障害発生時における自動復旧のためのネットワーク管理

Publications (1)

Publication Number Publication Date
WO2023228233A1 true WO2023228233A1 (ja) 2023-11-30

Family

ID=88918807

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/021061 WO2023228233A1 (ja) 2022-05-23 2022-05-23 障害発生時における自動復旧のためのネットワーク管理

Country Status (1)

Country Link
WO (1) WO2023228233A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016533655A (ja) * 2013-09-30 2016-10-27 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 障害管理方法、エンティティ、及びシステム
JP2018026709A (ja) * 2016-08-10 2018-02-15 日本電信電話株式会社 障害復旧システム及び方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016533655A (ja) * 2013-09-30 2016-10-27 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 障害管理方法、エンティティ、及びシステム
JP2018026709A (ja) * 2016-08-10 2018-02-15 日本電信電話株式会社 障害復旧システム及び方法

Similar Documents

Publication Publication Date Title
CN102708018B (zh) 一种异常处理方法及系统、代理设备与控制装置
US10038742B2 (en) Methods and apparatus to retire hosts in virtual server rack deployments for virtual computing environments
EP2972870B1 (en) Coordinating fault recovery in a distributed system
US8910172B2 (en) Application resource switchover systems and methods
EP3210367B1 (en) System and method for disaster recovery of cloud applications
US20170293538A1 (en) Using Diversity to Provide Redundancy of Virtual Machines
JP4448878B2 (ja) 障害回復環境の設定方法
US11507479B2 (en) High availability for a relational database management system as a service in a cloud platform
CN108347339B (zh) 一种业务恢复方法及装置
WO2014076838A1 (ja) 仮想マシン同期システム
WO2017049997A1 (zh) 一种基于云计算服务的虚拟机监控方法、装置及系统
US10120779B1 (en) Debugging of hosted computer programs
CN104503861A (zh) 一种异常处理方法及系统、代理设备与控制装置
CN108319492B (zh) 复位物理机的方法、装置与系统
US20210235290A1 (en) Endpoint computing device multi-network slice remediation/productivity system
CN112732412B (zh) 一种服务配置文件处理方法、装置、存储介质及电子设备
JP2012014674A (ja) 仮想環境における故障復旧方法及びサーバ及びプログラム
WO2023228233A1 (ja) 障害発生時における自動復旧のためのネットワーク管理
US20180152352A1 (en) Virtual machine mobility
CN116360865A (zh) 集群管理方法、设备及计算系统
US11954509B2 (en) Service continuation system and service continuation method between active and standby virtual servers
CN113542322A (zh) 用于活动目录程序的安装方法、装置、计算设备及介质
CN107783855B (zh) 虚拟网元的故障自愈控制装置及方法
WO2024004029A1 (ja) サーバのログ取得操作の自動化
WO2023021642A1 (ja) ネットワーク管理装置、ネットワーク管理方法およびネットワーク管理システム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 17910458

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22943642

Country of ref document: EP

Kind code of ref document: A1