WO2024004029A1 - サーバのログ取得操作の自動化 - Google Patents

サーバのログ取得操作の自動化 Download PDF

Info

Publication number
WO2024004029A1
WO2024004029A1 PCT/JP2022/025743 JP2022025743W WO2024004029A1 WO 2024004029 A1 WO2024004029 A1 WO 2024004029A1 JP 2022025743 W JP2022025743 W JP 2022025743W WO 2024004029 A1 WO2024004029 A1 WO 2024004029A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
log
logs
information
physical
Prior art date
Application number
PCT/JP2022/025743
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/025743 priority Critical patent/WO2024004029A1/ja
Publication of WO2024004029A1 publication Critical patent/WO2024004029A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/20—Arrangements for monitoring or testing data switching networks the monitoring system or the monitored elements being virtualised, abstracted or software-defined entities, e.g. SDN or NFV

Definitions

  • the present disclosure relates to automation of server log acquisition operations.
  • Patent Document 1 discloses a system including a network device and a management server that manages the network device.
  • the management server realizes device management by collecting device information and device operation information from network devices via the Internet.
  • the network devices include image processing devices such as printers, copiers, network cameras, digital medical devices, and the like.
  • cloud computing which uses on-demand virtualized computing resources on physical resources such as servers
  • NFV Network Function Virtualization
  • NFV Network Function Virtualization
  • Telecom networks in recent years are large-scale networks built on virtualization platforms, and in order to construct, maintain, and operate the networks, log information is necessary for the large number of physical servers deployed at each data center (accommodation station). and monitor and manage the status of each server.
  • Virtualized networks using general-purpose servers include equipment from more vendors than traditional networks using specialized hardware.
  • operators such as administrators
  • log acquisition has been a very time-consuming task.
  • the present disclosure aims to efficiently acquire logs of physical servers that constitute a virtualized network.
  • a network management device includes one or more processors, and at least one of the one or more processors performs first acquisition processing, generation processing, and second acquisition processing.
  • the first acquisition process is a process of acquiring server information from which a physical server from which logs are to be acquired can be selected from among the physical servers configuring the network virtualization environment.
  • the generation process is a process of generating, based on the server information, a program corresponding to the physical server from which the log is to be acquired, and for acquiring the log of the physical server.
  • the second acquisition process is a process of executing the program and acquiring the log of the physical server from which the log is to be acquired.
  • a network management method acquires server information that allows selecting a physical server from which logs are to be acquired from among the physical servers that configure a network virtualization environment, and Based on the information, a program corresponding to the physical server from which the logs are to be acquired is generated, and which is for acquiring the logs of the physical server, and the program is executed to generate the logs of the physical server from which the logs are to be acquired. including obtaining.
  • a network management system includes one or more processors, and at least one of the one or more processors performs first acquisition processing, generation processing, and second acquisition processing.
  • the first acquisition process is a process of acquiring server information from which a physical server from which logs are to be acquired can be selected from among the physical servers configuring the network virtualization environment.
  • the generation process is a process of generating, based on the server information, a program corresponding to the physical server from which the log is to be acquired, and for acquiring the log of the physical server.
  • the second acquisition process is a process of executing the program and acquiring the log of the physical server from which the log is to be acquired.
  • logs of physical servers that configure a virtualized network can be efficiently acquired.
  • 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 log acquisition section.
  • FIG. 4 is a sequence diagram showing the log acquisition operation of the server.
  • FIG. 5 is a flowchart showing the script generation processing procedure.
  • FIG. 6 is a conceptual diagram of script generation processing.
  • FIG. 7 is an example of extracting an analysis log.
  • FIG. 8 is a block diagram showing an example of the hardware configuration of the network management device.
  • the network management device includes a log acquisition function that acquires logs of physical servers in a mobile network constructed using a virtualization infrastructure.
  • the network management device in this embodiment acquires server information that allows selection of a physical server from which logs are to be acquired from among the physical servers that constitute the network virtualization environment.
  • the network management device generates a program corresponding to the physical server of which logs are to be acquired, and for acquiring logs of the physical server, based on the acquired server information.
  • the network management device executes the generated program and acquires the log of the physical server from which the log is to be acquired.
  • the network management device in this embodiment may extract information necessary for hardware analysis from the acquired physical server log and output it as an analysis log.
  • 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 is a virtualized network constructed using a virtualization platform. 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 generic 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 log acquisition unit 150 implements a log acquisition function that acquires logs of a server that is part of NFVI.
  • This log acquisition unit 150 constitutes a network management device according to this embodiment.
  • logs of servers that constitute a network virtualization environment are acquired, and the status of the servers is monitored and managed.
  • the servers from which logs are to be obtained may include at least one of a failed server and a bare metal server whose normality needs to be confirmed.
  • the server from which logs are acquired is not limited to the above, and may be any server that constitutes the virtualized environment of the mobile network 100.
  • a worker for example, an administrator
  • a management tool to obtain server logs.
  • workers can manually enter the GUI (Graphical User Interface), RESTful API, IPMI (Intelligent Platform Management Interface), etc. via the management tool to create the logs required for server monitoring operations. I had obtained it.
  • GUI Graphic User Interface
  • RESTful API Real-Time Transport Agent
  • IPMI Intelligent Platform Management Interface
  • virtualized networks that use general-purpose servers include devices from more vendors than traditional networks that use dedicated hardware.
  • the above-mentioned management tools are defined for each vendor, and each has different operating methods and commands to be input.
  • the log acquisition unit 150 automatically generates a program for acquiring logs for each server from which logs are to be acquired, and executes the program to acquire the logs.
  • the operator can acquire server logs through a unified operation that does not depend on vendors or the like, or almost does not depend on vendors. As a result, the burden on the worker and the occurrence of errors can be reduced.
  • logs obtained by executing commands defined by each vendor comply with the standards of each vendor, and may include logs that are unnecessary for analysis. Therefore, if the operator performing the analysis is not proficient in the work, errors may occur in the analysis results. Errors in such analysis results can lead to inefficient or inappropriate operations, which can also affect services. Therefore, the log acquisition unit 150 may extract information necessary for hardware analysis from the log acquired from the server and output it as an analysis log. This makes it possible to obtain server analysis logs in a unified format that is independent or almost independent of vendors. As a result, errors in analysis results can be suppressed.
  • the log acquisition unit 150 is not limited to being an external function of the OSS/BSS 140 or MANO 130 as shown in FIG.
  • the log acquisition unit 150 may be provided inside the OSS/BSS 140 or may be provided inside the MANO 130. In this case, the log acquisition function of the log acquisition unit 150 becomes part of the functions of the OSS/BSS 140 and MANO 130.
  • FIG. 3 is a functional block diagram of the log acquisition unit 150.
  • the log acquisition section 150 includes a server information acquisition section 151, a script generation section 152, a script execution section 153, and an analysis log extraction section 154.
  • the server information acquisition unit 151 acquires server information that allows selection of a server from which logs are to be acquired.
  • the server information acquired by the server information acquisition unit 151 includes information that allows identification of individual servers, such as a server ID and an IP address (BMC_IP) of a BMC (Baseboard Management Controller).
  • the server information acquired by the server information acquisition unit 151 may include at least one of the vendor name, vendor ID, model number, and firmware version of the server.
  • the server information acquisition unit 151 can acquire the server information, for example, by acquiring an input file in which the server information is directly written.
  • the method for acquiring server information is not limited to the method using the above file format, but may also be a method using command input, for example.
  • the server information acquisition unit 151 may acquire the server information by accepting a command input by the operator in which the server information is described. Further, the server information acquisition unit 151 may access a predetermined location and acquire the server information.
  • the server information acquisition unit 151 may, for example, use the BMC_IP input by the operator to access the server from which logs are to be acquired, and acquire the firmware version of the server.
  • the script generation unit 152 generates a script for acquiring logs of a server from which logs are to be acquired, based on the server information acquired by the server information acquisition unit 151.
  • the script is a script corresponding to the server from which logs are to be obtained.
  • the script generation unit 152 can generate different scripts for each server vendor, server model number, and server firmware, for example. Note that in this embodiment, a case will be described in which a script for acquiring a log is generated, but the program is not limited to a script and may be any program that executes one or a series of commands for acquiring a log.
  • the script execution unit 153 executes the script generated by the script generation unit 152 and acquires the log of the server from which the log is to be acquired.
  • the analysis log extraction unit 154 extracts information necessary for analyzing the server hardware from the log obtained by executing the script by the script execution unit 153, and outputs the extracted information as an analysis log.
  • the configuration of the functional blocks of the log acquisition 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 log acquisition 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.
  • FIG. 4 is a sequence diagram showing the log acquisition operation of the server.
  • an alert is notified from the NFVI 110 or VNF 120 in relation to the failure.
  • the above-mentioned alert includes an error, a warning, and a notice.
  • a primary analysis is performed to analyze the alert and identify the server (suspected location) where the failure is likely to have occurred. This primary analysis may be performed using, for example, a predetermined analysis tool.
  • the user (worker) 300 sets the server identified by the primary analysis as a log acquisition target server, and inputs the server information of the server in step S1 of FIG.
  • the user 300 may input server information to the OSS 140, and the OSS 140 may transfer the server information received from the user 300 to the log acquisition unit 150.
  • the log acquisition unit 150 generates a script for acquiring logs of the server from which logs are to be acquired, based on the server information input in step S1.
  • FIG. 5 is a flowchart showing the script generation processing procedure executed by the log acquisition unit 150.
  • the script generation unit 152 of the log acquisition unit 150 acquires the vendor name of the server from which the log is to be acquired from the server information. Note that the script generation unit 152 may obtain the vendor ID of the server.
  • the script generation unit 152 acquires the model number (server type) of the server from which logs are to be acquired from the server information.
  • the script generation unit 152 acquires the firmware version of the server whose log is to be acquired from the server information.
  • step S14 the script generation unit 152 generates a script for acquiring logs of the server from which logs are to be acquired, based on the information acquired in steps S11 to S13.
  • FIG. 6 is a conceptual diagram of script generation processing.
  • the command to obtain server logs varies by vendor. Further, the command may differ depending on the model number and firmware version of the server even if the vendor is the same. Therefore, as shown in FIG. 6, the script generation unit 152 generates scripts for each vendor, each server type, and even for each firmware version. For example, if the vendor name of the server whose log is to be acquired is "Vender_1," the server type is "Server_1,” and the firmware version is "FW_1,” the script generation unit 152 generates the script "Script_1.”
  • step S3 the log acquisition unit 150 executes the script generated in step S2.
  • the command executed at this time is a command defined for each vendor of the server (physical server) 400 from which logs are to be obtained, and is a command generated according to the server type and firmware version. In this way, the log acquisition unit 150 automatically generates and executes commands depending on the vendor, server type, and firmware version.
  • step S4 the log acquisition unit 150 acquires a log from the server (physical server) 400 from which the log is acquired.
  • the logs acquired at this time are standard logs that comply with the standards of each vendor.
  • the log acquisition unit 150 acquires the standard log from the server 400, in step S5, it executes an analysis log extraction process to extract only the analysis log from the standard log.
  • the standard log obtained by executing the script includes information A necessary for hardware analysis, as well as information related to SNMP (Simple Network Management Protocol) and NTP (Network Time Protocol). Information B that is unnecessary for hardware analysis may also be included.
  • step S5 of FIG. 4 only information A necessary for hardware analysis is extracted from the standard log as an analysis log.
  • the analysis log includes CPU (Central Processing Unit), DIMM (Dual Inline Memory Module), PSU (Power Supply Unit), RAID (Redundant Arrays of Inexpensive Disks),
  • the information may include information regarding at least one of Disk, MB (motherboard), Fan, and NIC (Network Interface Card).
  • step S6 the log acquisition unit 150 transmits the analysis log extracted in step S5 to the user 400.
  • the analysis log can be output in a predetermined format (eg, text format).
  • the output destination of the analysis log is not limited to the user 400.
  • the analysis log may be output to a tool that performs secondary analysis of failures.
  • the log acquisition unit 150 which is the network management device in this embodiment, acquires server information that allows selection of a server from which logs are to be acquired from among the servers (physical servers) that constitute the network virtualization environment. do. Furthermore, the log acquisition unit 150 generates a script (program) corresponding to the server from which the log is to be acquired, and for acquiring the log of the server, based on the server information. Then, the log acquisition unit 150 executes the generated script and acquires the log of the server from which the log is to be acquired.
  • a script program
  • the log acquisition unit 150 in this embodiment can automatically generate and execute a script for log acquisition. Therefore, it is possible to reduce the workload of the operator and to suppress the occurrence of manual errors.
  • the log acquisition unit 150 can generate a script for log acquisition in correspondence with the server that is the target of log acquisition, so even if the command for log acquisition is different for each server, the Server logs can be properly obtained.
  • server logs are obtained by executing different commands defined for each vendor, for example. Commands and the like for acquiring this log may vary depending on the model number, firmware version, etc. of the server. Therefore, when log acquisition work is performed manually, the worker must learn management tools and commands that differ depending on the vendor, etc., which imposes a heavy burden on the worker. Furthermore, tasks that are difficult to master as described above tend to be tasks that are dependent on the individual. Furthermore, even if the worker is proficient in the work, human errors are likely to occur when the work is done manually. In this embodiment, as described above, the log acquisition work of the server can be automated, so that the work efficiency can be improved. Further, since erroneous operations by operators can be suppressed, adverse effects on the commercial environment can be avoided.
  • the log acquisition unit 150 can acquire at least one of the vendor name, vendor ID, model number, and firmware version of the server as server information. Therefore, even if the command for log acquisition differs depending on the vendor, or even depending on the server type or firmware version, the log acquisition unit 150 can appropriately generate a script for log acquisition, and the server logs can be properly obtained.
  • the log acquisition unit 150 may acquire the server information by acquiring an input file in which the server information of the server from which the log is to be acquired is described.
  • logs can be obtained using input that is independent (almost independent) of vendors and the like. Therefore, it is possible to avoid problems caused by input errors by the operator.
  • the server whose log is to be obtained may be, for example, a server in which a failure has occurred.
  • the operator can perform analysis work to identify the cause of the failure, and can proceed with the recovery work appropriately.
  • the server from which logs are to be obtained may be, for example, a bare metal server in which no OS or the like is installed. By acquiring the log of the bare metal server, the operator can confirm the normality of the server and can perform provisioning normally.
  • logs obtained from servers by executing commands defined by each vendor comply with standards defined by each vendor.
  • the information contained in the acquired logs differs depending on the vendor, etc., and the location where the information to be checked is written also differs. Therefore, for workers who are not proficient in the work, there is a risk that it will take time to analyze the logs or that the logs cannot be evaluated appropriately.
  • the log acquisition unit 150 can extract information necessary for hardware analysis from the acquired log and output it as an analysis log. In this way, it is possible to obtain output that is independent (almost independent) of vendors and the like. Therefore, the operator can quickly and appropriately analyze the log.
  • Telecom networks are required to have high reliability and high availability, so if a failure occurs in the network, speedy recovery is required.
  • speedy recovery is required.
  • server analysis logs can be output quickly and appropriately, so workers can appropriately analyze logs regardless of their level of proficiency and can perform maintenance work. . Therefore, it is possible to avoid performing inefficient recovery work due to errors in log analysis results, and to shorten the time required for recovery (network failure time). Furthermore, it is also possible to avoid the impact on services caused by erroneous operations.
  • logs of physical servers that constitute a virtualized network can be efficiently and appropriately acquired.
  • 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 log acquisition 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 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.
  • a method comprising one or more processors, in which at least one of the one or more processors acquires server information from which a physical server from which logs are to be acquired can be selected from among physical servers constituting a network virtualization environment. 1, a generation process that generates a program corresponding to the physical server from which logs are to be acquired, and that is for acquiring logs of the physical server, based on the server information, and executing the program. and a second acquisition process of acquiring logs of the physical server from which the logs are to be acquired.
  • At least one of the one or more processors further executes an output process of extracting information necessary for hardware analysis from the log and outputting it as an analysis log [1] Or the network management device according to [2].
  • the above analysis log includes CPU (Central Processing Unit), DIMM (Dual Inline Memory Module), PSU (Power Sup-ply Unit), RAID (Redundant Arrays of Inexpensive Disks), Disk (disk), MB (motherboard) ), Fan, and NIC (Network Interface Card).
  • CPU Central Processing Unit
  • DIMM Direct Memory Module
  • PSU Power Sup-ply Unit
  • RAID Redundant Arrays of Inexpensive Disks
  • Disk disk
  • MB motherboard
  • Fan Fan
  • NIC Network Interface Card
  • a network management method comprising: generating a program for acquiring logs of the physical server; executing the program; and acquiring logs of the physical server from which the logs are to be acquired.
  • a step comprising one or more processors, and acquiring server information that allows selection of a physical server from which logs are to be acquired from among physical servers constituting a network virtualization environment, using at least one of the one or more processors. 1, a generation process that generates a program corresponding to the physical server from which logs are to be acquired, and that is for acquiring logs of the physical server, based on the server information, and executing the program. and a second acquisition process of acquiring logs of the physical server from which the logs are to be 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...Log acquisition section, 151...Server information acquisition section, 152...Script generation section, 153...Script execution section, 154...Log extraction section for analysis

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer And Data Communications (AREA)
  • Debugging And Monitoring (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

ネットワーク管理装置は、第１の取得処理と、生成処理と、第２の取得処理と、を実行する。第１の取得処理は、ネットワークの仮想化環境を構成する物理サーバのうち、ログ取得対象の物理サーバを選定可能なサーバ情報を取得する処理である。生成処理は、サーバ情報に基づいて、ログ取得対象の物理サーバに対応したプログラムであって、当該物理サーバのログを取得するためのプログラムを生成する処理である。第２の取得処理は、上記プログラムを実行し、ログ取得対象の物理サーバのログを取得する処理である。

Description

サーバのログ取得操作の自動化
　本開示は、サーバのログ取得操作の自動化に関する。
　従来、遠隔地に設置された複数台のネットワーク機器からインターネット経由で情報を収集して、管理サーバにて監視し、ネットワーク機器の保守に役立てるシステムが知られている。
　特許文献１は、ネットワーク機器と、ネットワーク機器を管理する管理サーバとを含むシステムを開示する。管理サーバは、ネットワーク機器から、機器情報や機器の稼働情報をインターネット経由で収集することで、機器管理を実現する。上記ネットワーク機器は、例えばプリンターや複写機、ネットワークカメラ、デジタル医療機器などといった画像処理装置を含む。
特開２０１７－５４３９７号公報
　近年、汎用サーバの性能向上、ネットワーク基盤の充実を背景として、サーバなどの物理リソース上に仮想化されたコンピューティングリソースをオンデマンドで使うクラウドコンピューティング（以下、「クラウド」という。）が広く普及している。また、ネットワーク機能を仮想化し、クラウド上で提供するＮＦＶ（Network Function Virtualization）が知られている。ＮＦＶとは、仮想化技術およびクラウド技術を用いて、これまで専用ハードウェア上で動いていた様々なネットワークサービスのハードウェアとソフトウェアとを分離し、ソフトウェアを仮想化された基盤上で動かす技術である。これによって運用の高度化やコスト削減が期待される。
　近年のテレコムネットワークは仮想化基盤で構築された大規模ネットワークであり、ネットワークの構築、保守および運用のために、各データセンタ（収容局）に配備された多数の物理サーバについて、必要なログ情報を取得し、各サーバの状態を監視および管理している。
　汎用サーバを利用した仮想化ネットワークには、専用ハードウェアを使用した従来のネットワークに比べて、より多くのベンダーの機器が混在する。従来、作業者（管理者など）は、サーバごと（例えばベンダーごと）に定義された操作を行ってログ情報を取得しており、ログ取得作業は非常に手間のかかる作業であった。
　そこで、本開示は、仮想化ネットワークを構成する物理サーバのログを効率的に取得することを課題とする。
　上記課題を解決するために、本開示の一態様によるネットワーク管理装置は、１以上のプロセッサを備え、前記１以上のプロセッサの少なくとも一つによって、第１の取得処理と、生成処理と、第２の取得処理と、が実行される。前記第１の取得処理は、ネットワークの仮想化環境を構成する物理サーバのうち、ログ取得対象の物理サーバを選定可能なサーバ情報を取得する処理である。前記生成処理は、前記サーバ情報に基づいて、前記ログ取得対象の物理サーバに対応したプログラムであって、当該物理サーバのログを取得するためのプログラムを生成する処理である。前記第２の取得処理は、前記プログラムを実行し、前記ログ取得対象の物理サーバのログを取得する処理である。
　上記課題を解決するために、本開示の一態様によるネットワーク管理方法は、ネットワークの仮想化環境を構成する物理サーバのうち、ログ取得対象の物理サーバを選定可能なサーバ情報を取得し、前記サーバ情報に基づいて、前記ログ取得対象の物理サーバに対応したプログラムであって、当該物理サーバのログを取得するためのプログラムを生成し、前記プログラムを実行し、前記ログ取得対象の物理サーバのログを取得する、ことを含む。
　上記課題を解決するために、本開示の一態様によるネットワーク管理システムは、１以上のプロセッサを備え、前記１以上のプロセッサの少なくとも一つによって、第１の取得処理と、生成処理と、第２の取得処理と、が実行される。前記第１の取得処理は、ネットワークの仮想化環境を構成する物理サーバのうち、ログ取得対象の物理サーバを選定可能なサーバ情報を取得する処理である。前記生成処理は、前記サーバ情報に基づいて、前記ログ取得対象の物理サーバに対応したプログラムであって、当該物理サーバのログを取得するためのプログラムを生成する処理である。前記第２の取得処理は、前記プログラムを実行し、前記ログ取得対象の物理サーバのログを取得する処理である。
　本開示の一態様によれば、仮想化ネットワークを構成する物理サーバのログを効率的に取得することができる。
図１は、本実施形態のネットワーク管理装置を含むモバイルネットワークの構成例を示す図である。 図２は、ネットワーク管理システムの内部構成の一例を示す図である。 図３は、ログ取得部の機能ブロック図である。 図４は、サーバのログ取得動作を示すシーケンス図である。 図５は、スクリプト生成処理手順を示すフローチャートである。 図６は、スクリプト生成処理の概念図である。 図７は、解析用ログの抽出例である。 図８は、ネットワーク管理装置のハードウェア構成の一例を示すブロック図である。
　以下、添付図面を参照して、本開示の実施形態について詳細に説明する。以下に開示される構成要素のうち、同一機能を有するものには同一の符号を付し、その説明を省略する。なお、以下に開示される実施形態は、本開示の一形態であり、装置の構成や各種条件によって適宜修正または変更されるべきものであり、以下の実施形態に限定されるものではない。また、本実施形態で説明されている特徴の組み合わせの全てが上記課題の解決手段に必須のものとは限らない。
　以下、本実施形態に係るネットワーク管理装置が、仮想化基盤で構築されるモバイルネットワークにおける物理サーバのログを取得するログ取得機能を備える場合について説明する。
　具体的には、本実施形態におけるネットワーク管理装置は、ネットワークの仮想化環境を構成する物理サーバのうち、ログ取得対象の物理サーバを選定可能なサーバ情報を取得する。また、ネットワーク管理装置は、取得されたサーバ情報に基づいて、ログ取得対象の物理サーバに対応したプログラムであって、当該物理サーバのログを取得するためのプログラムを生成する。そして、ネットワーク管理装置は、生成されたプログラムを実行し、ログ取得対象の物理サーバのログを取得する。
　さらに、本実施形態におけるネットワーク管理装置は、取得された物理サーバのログからハードウェアの解析に必要な情報を抽出し、解析用ログとして出力してよい。
　図１は、本実施形態のネットワーク管理装置を含むモバイルネットワーク１００のネットワーク構成例を示す図である。
　図１に示すモバイルネットワーク１００においては、スマートフォンなどのモバイル通信可能な端末と無線アクセスネットワーク（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）１４０からの指示に応じた処理を行うことができる。
　ＶＮＦＭ１３２は、ＶＮＦ１２０のライフサイクル管理を行う。なお、ＶＮＦＭ１３２は、ＶＮＦ１２０毎に、それぞれ対応する専用ＶＮＦＭとしてＭＡＮＯ１３０に配置されていてもよい。または、１つのＶＮＦＭ１３２が、２以上のＶＮＦ１２０のライフサイクルを管理してもよい。この場合、ＶＮＦＭ１３２は、異なるベンダーから提供されるＶＮＦ１２０に対応する汎用ＶＮＦＭであってもよい。
　ＶＩＭ１３３は、ＶＮＦ１２０が使用するリソースの運用管理を行う。
　ＯＳＳ／ＢＳＳ１４０は、モバイルネットワーク１００の統合管理システムである。
　ここで、ＯＳＳは、サービスを構築し、運営していくために必要なシステム（機器やソフトウェア、仕組みなど）であり、ＢＳＳは、利用料などの課金、請求、顧客対応などのために用いる情報システム（機器やソフトウェア、仕組みなど）である。
　ログ取得部１５０は、ＮＦＶＩの一部であるサーバのログを取得するログ取得機能を実現する。このログ取得部１５０が本実施形態に係るネットワーク管理装置を構成している。
　モバイルネットワーク１００では、ネットワークの構築、保守および運用の各フェーズにおいて、ネットワークの仮想化環境を構成するサーバのログを取得し、当該サーバの状態を監視および管理している。
　例えば、サーバに障害が発生した場合には、障害の原因を解析するために、サーバのログを取得する必要がある。また、例えば、データセンタ（収容局）を新たに構築する場合には、当該データセンタにサーバを設置し、当該サーバのハードウェアの正常性を確認したうえでオペレーティングシステム（ＯＳ）等をインストールしていく。この場合にも、正常性の確認のためにサーバのログを取得する必要がある。
　本実施形態において、ログ取得対象のサーバは、障害が発生しているサーバおよび正常性の確認が必要なベアメタルサーバの少なくとも一方を含んでよい。
　なお、ログ取得対象のサーバは上記に限定されるものではなく、モバイルネットワーク１００の仮想化環境を構成する任意のサーバであってよい。
　従来、作業者（例えば管理者など）は、所定の管理ツールを操作してサーバのログを取得していた。具体的には、作業者は、管理ツールを介して、ＧＵＩ（Graphical User Interface）、ＲＥＳＴｆｕｌ　ＡＰＩ、ＩＰＭＩ（Intelligent Platform Management Interface）等を手入力することで、サーバの監視運用で必要となるログを取得していた。
　しかしながら、汎用サーバを利用した仮想化ネットワークは、専用ハードウェアを使用した従来のネットワークに比べて、より多くのベンダーの機器が混在する。上記管理ツールは、ベンダーごとに定義されており、それぞれ操作方法や入力するコマンド等が異なる。
　そのため、作業者は、ベンダーごとの各種手順書を参照して作業を習得しなければならないなど、サーバのログ取得作業に習熟するための負荷が大きかった。また、作業者の経験の差などにより習熟度に差があると、ログ取得作業の迅速性や正確性に差が出てしまう。さらに、ベンダーごとの操作の違いよって作業者が混乱し、ヒューマンエラーを発生させやすい。
　そこで、本実施形態では、ログ取得部１５０は、ログ取得対象のサーバごとにログを取得するためのプログラムを自動生成し、当該プログラムを実行してログを取得する。これにより、作業者は、ベンダー等に依存しない、あるいは、ほぼ依存しない統一的な作業でサーバのログを取得することができる。その結果、作業者の負荷とエラー発生とを軽減することができる。
　また、ベンダーごとに定義されたコマンドを実行して得られるログは、ベンダーごとの標準規格に準拠しており、解析に不要なログも含まれうる。そのため、解析にあたる作業者が作業に習熟していない場合、解析結果の誤謬が起こりうる。このような解析結果の誤謬は、非効率なオペレーションや不適切なオペレーションにもつながるため、サービスにも影響しうる。
　そこで、ログ取得部１５０は、サーバから取得したログからハードウェアの解析に必要な情報を抽出し、解析用ログとして出力してよい。これにより、ベンダー等に依存しない、あるいは、ほぼ依存しない統一的な形式でサーバの解析用ログを取得することができる。その結果、解析結果の誤謬を抑制することができる。
　なお、ログ取得部１５０は、図２に示すようにＯＳＳ／ＢＳＳ１４０やＭＡＮＯ１３０の外部機能である場合に限定されない。ログ取得部１５０は、ＯＳＳ／ＢＳＳ１４０の内部に設けられていてもよいし、ＭＡＮＯ１３０の内部に設けられていてもよい。この場合、ログ取得部１５０が有するログ取得機能は、ＯＳＳ／ＢＳＳ１４０やＭＡＮＯ１３０の機能の一部となる。
　図３は、ログ取得部１５０の機能ブロック図である。
　この図３に示すように、ログ取得部１５０は、サーバ情報取得部１５１と、スクリプト生成部１５２と、スクリプト実行部１５３と、解析用ログ抽出部１５４とを備える。
　サーバ情報取得部１５１は、ログ取得対象のサーバを選定可能なサーバ情報を取得する。ここで、サーバ情報取得部１５１が取得するサーバ情報は、サーバＩＤやＢＭＣ（Baseboard Management Controller）のＩＰアドレス（ＢＭＣ＿ＩＰ）など、個々のサーバを特定可能な情報を含む。また、サーバ情報取得部１５１が取得するサーバ情報は、サーバのベンダー名、ベンダーＩＤ、型番およびファームウェアバージョンの少なくとも１つを含んでよい。
　サーバ情報取得部１５１は、例えば、上記サーバ情報が直接記述された入力ファイルを取得することで、当該サーバ情報を取得することができる。
　なお、サーバ情報の取得方法は上記のファイル形式による方法に限定されるものではなく、例えば、コマンド入力による方法であってもよい。この場合、サーバ情報取得部１５１は、作業者が入力した、サーバ情報が記述されたコマンドを受け付けることで、サーバ情報を取得してよい。
　また、サーバ情報取得部１５１は、所定の場所にアクセスして上記サーバ情報を取得してもよい。サーバ情報取得部１５１は、例えば、作業者が入力したＢＭＣ＿ＩＰを用いてログ取得対象のサーバにアクセスし、当該サーバのファームウェアバージョンを取得してもよい。
　スクリプト生成部１５２は、サーバ情報取得部１５１により取得されたサーバ情報に基づいて、ログ取得対象のサーバのログを取得するためのスクリプトを生成する。ここで、当該スクリプトは、ログ取得対象のサーバに対応したスクリプトである。スクリプト生成部１５２は、例えば、サーバのベンダーごと、さらにはサーバの型番やサーバのファームウェアごとに、それぞれ異なるスクリプトを生成することができる。
　なお、本実施形態では、ログを取得するためのスクリプトを生成する場合について説明するが、ログを取得するための１つまたは一連のコマンドを実行させるプログラムであればよく、スクリプトに限定されない。
　スクリプト実行部１５３は、スクリプト生成部１５２により生成されたスクリプトを実行し、ログ取得対象のサーバのログを取得する。
　解析用ログ抽出部１５４は、スクリプト実行部１５３によるスクリプトの実行によって取得されたログから、サーバのハードウェアの解析に必要な情報を抽出し、解析用ログとして出力する。
　なお、図３に示したログ取得部１５０の機能ブロックの構成は一例であり、複数の機能ブロックが１つの機能ブロックを構成するようにしてもよいし、いずれかの機能ブロックが複数の機能を行うブロックに分かれてもよい。
　また、ログ取得部１５０の複数の機能は、それぞれ、図２に示すネットワーク管理システムのＯＳＳ／ＢＳＳ１４０やＭＡＮＯ１３０の外部機能、ＯＳＳ／ＢＳＳ１４０の内部機能、ＭＡＮＯ１３０内部機能に分かれていてもよい。
　図４は、サーバのログ取得動作を示すシーケンス図である。
　例えばサーバに障害が発生した場合、発生した障害に関連して、ＮＦＶＩ１１０やＶＮＦ１２０からアラートが通知される。ここで、上記アラートは、エラー（error）、警告（warning）、通知（notice）を含む。この場合、まずアラートを分析して障害が発生していると思われるサーバ（被疑箇所）を特定する一次解析が行われる。この一次解析は、例えば所定の解析ツールを用いて行われてよい。
　ユーザ（作業者）３００は、一次解析により特定されたサーバをログ取得対象のサーバとして、図４のステップＳ１において、当該サーバのサーバ情報を入力する。なお、ユーザ３００は、ＯＳＳ１４０に対してサーバ情報を入力し、ＯＳＳ１４０がユーザ３００から受け付けたサーバ情報をログ取得部１５０に転送する構成であってもよい。
　ステップＳ２では、ログ取得部１５０は、ステップＳ１において入力されたサーバ情報に基づいて、ログ取得対象のサーバのログを取得するためのスクリプトを生成する。
　図５は、ログ取得部１５０が実行するスクリプト生成処理手順を示すフローチャートである。
　まずステップＳ１１において、ログ取得部１５０のスクリプト生成部１５２は、サーバ情報からログ取得対象のサーバのベンダー名を取得する。なお、スクリプト生成部１５２は、サーバのベンダーＩＤを取得してもよい。
　ステップＳ１２では、スクリプト生成部１５２は、サーバ情報からログ取得対象のサーバの型番（サーバ型）を取得する。
　ステップＳ１３では、スクリプト生成部１５２は、サーバ情報からログ取得対象のサーバのファームウェアバージョンを取得する。
　そして、ステップＳ１４では、スクリプト生成部１５２は、ステップＳ１１～１３において取得された情報に基づいて、ログ取得対象のサーバのログを取得するためのスクリプトを生成する。
　図６は、スクリプト生成処理の概念図である。
　サーバのログを取得するためのコマンドは、ベンダーごとに異なる。また、当該コマンドは、ベンダーが同じであっても、サーバの型番やファームウェアバージョンによって異なりうる。そこで、図６に示すように、スクリプト生成部１５２は、ベンダーごと、サーバ型ごと、さらにはファームウェアバージョンごとにスクリプトを生成する。
　例えば、ログ取得対象のサーバのベンダー名が「Ｖｅｎｄｅｒ＿１」であり、サーバ型が「Ｓｅｒｖｅｒ＿１」であり、ファームウェアバージョンが「ＦＷ＿１」である場合、スクリプト生成部１５２は、スクリプト「Ｓｃｒｉｐｔ＿１」を生成する。
　図４に戻って、ステップＳ３では、ログ取得部１５０は、ステップＳ２において生成されたスクリプトを実行する。このとき実行されるコマンドは、ログ取得対象のサーバ（物理サーバ）４００のベンダーごとに定義されたコマンドであって、サーバ型やファームウェアバージョンに応じて生成されたコマンドである。このように、ログ取得部１５０は、ベンダーやサーバ型、ファームウェアバージョンに応じてコマンドを自動で生成し、実行する。
　そして、ステップＳ４において、ログ取得部１５０は、ログ取得対象のサーバ（物理サーバ）４００からログを取得する。このとき取得されるログは、各ベンダーの標準規格に準拠した標準ログである。
　ログ取得部１５０は、サーバ４００から標準ログを取得すると、ステップＳ５において、標準ログから解析用ログのみを抽出する解析用ログ抽出処理を実行する。
　例えば図７に示すように、スクリプトの実行によって取得される標準ログには、ハードウェア解析に必要な情報Ａの他に、ＳＮＭＰ（Simple Network Management Protocol）やＮＴＰ（Network Time Protocol）に関する情報など、ハードウェア解析に不要な情報Ｂも含まれうる。
　そこで、図４のステップＳ５では、標準ログからハードウェア解析に必要な情報Ａのみを解析用ログとして抽出する。
　上記解析用ログは、例えば図７の情報Ａに示すように、ＣＰＵ（Central Processing Unit）、ＤＩＭＭ（Dual Inline Memory Module）、ＰＳＵ（Power Sup-ply Unit）、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）、Ｄｉｓｋ（ディスク）、ＭＢ（motherboard）、Ｆａｎ（ファン）およびＮＩＣ（Network Interface Card）の少なくとも１つに関する情報を含んでよい。これらの情報を解析用ログとして出力することで、作業者は、サーバの状態を適切に評価することができる。
　そして、ステップＳ６において、ログ取得部１５０は、ステップＳ５において抽出された解析用ログをユーザ４００に対して送信する。解析用ログは、予め定められた形式（例えばテキスト形式）で出力することができる。
　なお、解析用ログの出力先はユーザ４００に限定されない。例えば、障害の二次解析を行うツール等に解析用ログを出力してもよい。
　以上説明したように、本実施形態におけるネットワーク管理装置であるログ取得部１５０は、ネットワークの仮想化環境を構成するサーバ（物理サーバ）のうち、ログ取得対象のサーバを選定可能なサーバ情報を取得する。また、ログ取得部１５０は、上記サーバ情報に基づいて、ログ取得対象のサーバに対応したスクリプト（プログラム）であって、当該サーバのログを取得するためのスクリプトを生成する。そして、ログ取得部１５０は、生成されたスクリプトを実行し、ログ取得対象のサーバのログを取得する。
　このように、本実施形態におけるログ取得部１５０は、ログ取得のためのスクリプトを自動的に生成して実行することができる。したがって、作業者の作業負荷を軽減することができるとともに、手作業によるエラー発生を抑制することができる。
　また、ログ取得部１５０は、ログ取得のためのスクリプトを、ログ取得対象のサーバに対応させて生成することができるので、サーバごとにログ取得のためのコマンドが異なる場合であっても、対象サーバのログを適切に取得することができる。
　マルチベンダーで構成される仮想化ネットワークにおいては、例えばベンダーごとに定義された異なるコマンドを実行してサーバのログを取得する。このログ取得のためのコマンド等は、サーバの型番やファームウェアバージョン等によっても異なりうる。そのため、ログ取得作業を手作業で行う場合、作業者は、ベンダー等により異なる管理ツールやコマンドを習得しなければならず、負荷が大きい。また、上記のように習熟が困難な作業は、属人的な作業になりやすい。さらに、仮に作業に習熟した作業者であっても、手作業の場合ヒューマンエラーが発生しやすい。
　本実施形態では、上述したように、サーバのログ取得作業を自動化することができるので、作業の効率化を図ることができる。また、作業者による誤操作を抑制することができるので、商用環境への悪影響を回避することができる。
　また、ログ取得部１５０は、サーバ情報として、サーバのベンダー名、ベンダーＩＤ、型番およびファームウェアバージョンの少なくとも１つを取得することができる。
　したがって、ログ取得のためのコマンドが、ベンダーによって、さらにはサーバ型やファームウェアバージョンによって異なる場合であっても、ログ取得部１５０は、ログ取得のためのスクリプトを適切に生成することができ、サーバのログを適切に取得することができる。
　さらに、ログ取得部１５０は、ログ取得対象のサーバのサーバ情報が記述された入力ファイルを取得することで、当該サーバ情報を取得してよい。
　この場合、ベンダー等に依存しない（ほぼ依存しない）入力でログを取得することができる。そのため、作業者による入力ミスに起因する不具合の発生を回避することができる。
　ここで、ログ取得対象のサーバは、例えば障害が発生しているサーバであってよい。障害が発生しているサーバのログを取得することで、作業者は、障害の発生原因を特定するための解析作業を行うことができ、適切に復旧作業を進めることが可能となる。
　また、ログ取得対象のサーバは、例えばＯＳ等がインストールされていないベアメタルサーバであってもよい。ベアメタルサーバのログを取得することで、作業者は、当該サーバの正常性の確認を行うことができ、正常にプロビジョニングを実行させることができる。
　また、マルチベンダーで構成される仮想化ネットワークにおいて、ベンダーごとに定義されたコマンドを実行してサーバから得られるログは、ベンダーごとに定義された標準規格に準拠している。つまり、ベンダー等の違いによって、取得されるログに含まれる情報は異なり、また、確認したい情報が記述されている場所なども異なる。そのため、作業に習熟していない作業者の場合、ログの解析に時間を要したり、ログを適切に評価できなかったりするおそれがある。
　これに対してログ取得部１５０は、取得されたログからハードウェアの解析に必要な情報を抽出し、解析用ログとして出力することができる。このように、ベンダー等に依存しない（ほぼ依存しない）出力を得ることができる。したがって、作業者は、ログの解析を迅速かつ適切に行うことができる。
　テレコムネットワークは、高信頼性、高可用性の要請が大きいため、ネットワークにおいて障害が発生した場合、復旧までの迅速性が求められる。例えば、遠隔地のサーバに障害が発生した場合、当該サーバのログを解析して、障害の原因追求と復旧への道筋を示す最適解の導出とを行うことが早急に求められる。
　本実施形態では、サーバの解析用ログを迅速かつ適切に出力することができるので、作業者は、習熟度の差によらずに適切にログを解析することができ、保守作業にあたることができる。したがって、ログ解析結果の誤謬に起因する非効率な復旧作業の実施を回避し、復旧までにかかる時間（ネットワーク障害時間）を短縮することができる。また、誤謬のオペレーション等に起因するサービスへの影響も回避することができる。
　以上のように、本実施形態においては、仮想化ネットワークを構成する物理サーバのログを効率的かつ適切に取得することができる。本実施形態においては、遠隔地にあるエージェントレス物理サーバについても、適切にサーバ状態を管理および監視することができる。
　本実施形態に係るネットワーク管理装置は、モバイルネットワーク１００のバックホールネットワークやコアネットワーク等を構成するいずれかの汎用サーバに実装されてよい。なお、ネットワーク管理装置は、専用サーバに実装されてもよい。また、ネットワーク管理装置は、単一または複数のコンピュータ上に実装されてもよい。
　ネットワーク管理装置が単一のコンピュータに実装される場合、図８に示すように、ネットワーク管理装置１は、ＣＰＵ２、ＲＯＭ３、ＲＡＭ４、ＨＤＤ５、入力部（キーボード、ポインティングデバイス等）６、表示部（モニター等）７、通信Ｉ／Ｆ８等を備えることができる。ネットワーク管理装置１はまた、外部メモリを備えてよい。
　ＣＰＵ２は、１つ以上のプロセッサにより構成され、ネットワーク管理装置１における動作を統括的に制御する。図３に示すログ取得部１５０の各要素の少なくとも一部の機能は、ＣＰＵ２がプログラムを実行することで実現することができる。なお、当該プログラムは、ＲＯＭ３やＨＤＤ５等の不揮発性メモリに記憶されていてもよいし、着脱可能な記憶媒体（不図示）等の外部メモリに記憶されていてもよい。
　ただし、図３に示すログ取得部１５０の各要素のうちの少なくとも一部が専用のハードウェアとして動作するようにしてもよい。この場合、専用のハードウェアは、上記ＣＰＵ２の制御に基づいて動作する。
　ハードウェアにより実現される機能については、例えば、所定のコンパイラを用いることで、各機能モジュールの機能を実現するためのプログラムからＦＰＧＡ上に自動的に専用回路を生成すればよい。また、ＦＰＧＡと同様にしてＧａｔｅ　Ａｒｒａｙ回路を形成し、ハードウェアとして実現するようにしてもよい。また、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）により実現するようにしてもよい。
　本開示の態様は、プログラムを記憶するコンピュータ可読記憶媒体を含むことができ、ここでは、当該プログラムが、ネットワーク管理装置１のＣＰＵ２（１つ以上のプロセッサの少なくとも一つ）によって実行されたときに、ネットワーク管理装置１に前述の方法のうちの少なくともいずれかを実行させる命令を含む。
　なお、上記において特定の実施形態が説明されているが、当該実施形態は単なる例示であり、本開示の範囲を限定する意図はない。本明細書に記載された装置及び方法は上記した以外の形態において具現化することができる。また、本開示の範囲から離れることなく、上記した実施形態に対して適宜、省略、置換及び変更をなすこともできる。かかる省略、置換及び変更をなした形態は、請求の範囲に記載されたもの及びこれらの均等物の範疇に含まれ、本開示の技術的範囲に属する。
　（本開示の実施形態）
　本開示は以下の実施形態を含む。
　［１］１以上のプロセッサを備え、前記１以上のプロセッサの少なくとも一つによって、ネットワークの仮想化環境を構成する物理サーバのうち、ログ取得対象の物理サーバを選定可能なサーバ情報を取得する第１の取得処理と、前記サーバ情報に基づいて、前記ログ取得対象の物理サーバに対応したプログラムであって、当該物理サーバのログを取得するためのプログラムを生成する生成処理と、前記プログラムを実行し、前記ログ取得対象の物理サーバのログを取得する第２の取得処理と、が実行される、ことを特徴とするネットワーク管理装置。
　［２］前記第１の取得処理は、前記サーバ情報として、前記物理サーバのベンダー名、ベンダーＩＤ、型番およびファームウェアバージョンの少なくとも１つを取得することを特徴とする［１］に記載のネットワーク管理装置。
　［３］前記１以上のプロセッサの少なくとも一つによって、前記ログからハードウェアの解析に必要な情報を抽出し、解析用ログとして出力する出力処理がさらに実行されることを特徴とする［１］または［２］に記載のネットワーク管理装置。
　［４］前記解析用ログは、ＣＰＵ（Central Processing Unit）、ＤＩＭＭ（Dual Inline Memory Module）、ＰＳＵ（Power Sup-ply Unit）、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）、Ｄｉｓｋ（ディスク）、ＭＢ（motherboard）、Ｆａｎ（ファン）およびＮＩＣ（Network Interface Card）の少なくとも１つに関する情報を含むことを特徴とする［３］に記載のネットワーク管理装置。
　［５］前記第１の取得処理は、前記ログ取得対象の物理サーバの前記サーバ情報が記述された入力ファイルを取得することで、前記サーバ情報を取得することを特徴とする［１］から［４］のいずれかに記載のネットワーク管理装置。
　［６］前記ログ取得対象の物理サーバは、障害が発生している物理サーバおよび正常性の確認が必要なベアメタルサーバの少なくとも一方を含むことを特徴とする［１］から［５］のいずれかに記載のネットワーク管理装置。
　［７］ネットワークの仮想化環境を構成する物理サーバのうち、ログ取得対象の物理サーバを選定可能なサーバ情報を取得し、前記サーバ情報に基づいて、前記ログ取得対象の物理サーバに対応したプログラムであって、当該物理サーバのログを取得するためのプログラムを生成し、前記プログラムを実行し、前記ログ取得対象の物理サーバのログを取得する、ことを含むことを特徴とするネットワーク管理方法。
　［８］１以上のプロセッサを備え、前記１以上のプロセッサの少なくとも一つによって、ネットワークの仮想化環境を構成する物理サーバのうち、ログ取得対象の物理サーバを選定可能なサーバ情報を取得する第１の取得処理と、前記サーバ情報に基づいて、前記ログ取得対象の物理サーバに対応したプログラムであって、当該物理サーバのログを取得するためのプログラムを生成する生成処理と、前記プログラムを実行し、前記ログ取得対象の物理サーバのログを取得する第２の取得処理と、が実行される、ことを特徴とするネットワーク管理システム。
　１１…基地局、１２…エッジデータセンタ、１３…地域データセンタ、１４…中央データセンタ、１００…モバイルネットワーク、１１０…ＮＦＶＩ、１２０…ＶＮＦ、１３０…ＭＡＮＯ、１３１…ＮＦＶＯ、１３２…ＶＮＦＭ、１３３…ＶＩＭ、１４０…ＯＳＳ／ＢＳＳ、１５０…ログ取得部、１５１…サーバ情報取得部、１５２…スクリプト生成部、１５３…スクリプト実行部、１５４…解析用ログ抽出部

 

Claims (8)

  1. 　１以上のプロセッサを備え、
    　前記１以上のプロセッサの少なくとも一つによって、
    　ネットワークの仮想化環境を構成する物理サーバのうち、ログ取得対象の物理サーバを選定可能なサーバ情報を取得する第１の取得処理と、
    　前記サーバ情報に基づいて、前記ログ取得対象の物理サーバに対応したプログラムであって、当該物理サーバのログを取得するためのプログラムを生成する生成処理と、
    　前記プログラムを実行し、前記ログ取得対象の物理サーバのログを取得する第２の取得処理と、
    　が実行される、
    　ことを特徴とするネットワーク管理装置。
  2. 　前記第１の取得処理は、前記サーバ情報として、前記物理サーバのベンダー名、ベンダーＩＤ、型番およびファームウェアバージョンの少なくとも１つを取得する
    　ことを特徴とする請求項１に記載のネットワーク管理装置。
  3. 　前記１以上のプロセッサの少なくとも一つによって、
    　前記ログからハードウェアの解析に必要な情報を抽出し、解析用ログとして出力する出力処理
    　がさらに実行されることを特徴とする請求項１に記載のネットワーク管理装置。
  4. 　前記解析用ログは、ＣＰＵ（Central Processing Unit）、ＤＩＭＭ（Dual Inline Memory Module）、ＰＳＵ（Power Sup-ply Unit）、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）、Ｄｉｓｋ（ディスク）、ＭＢ（motherboard）、Ｆａｎ（ファン）およびＮＩＣ（Network Interface Card）の少なくとも１つに関する情報を含む
    　ことを特徴とする請求項３に記載のネットワーク管理装置。
  5. 　前記第１の取得処理は、前記ログ取得対象の物理サーバの前記サーバ情報が記述された入力ファイル を取得することで、前記サーバ情報を取得する
    　ことを特徴とする請求項１に記載のネットワーク管理装置。
  6. 　前記ログ取得対象の物理サーバは、障害が発生している物理サーバおよび正常性の確認が必要なベアメタルサーバの少なくとも一方を含む
    　ことを特徴とする請求項１に記載のネットワーク管理装置。
  7. 　ネットワークの仮想化環境を構成する物理サーバのうち、ログ取得対象の物理サーバを選定可能なサーバ情報を取得し、
    　前記サーバ情報に基づいて、前記ログ取得対象の物理サーバに対応したプログラムであって、当該物理サーバのログを取得するためのプログラムを生成し、
    　前記プログラムを実行し、前記ログ取得対象の物理サーバのログを取得する、
    　ことを含むことを特徴とするネットワーク管理方法。
  8. 　１以上のプロセッサを備え、
    　前記１以上のプロセッサの少なくとも一つによって、
    　ネットワークの仮想化環境を構成する物理サーバのうち、ログ取得対象の物理サーバを選定可能なサーバ情報を取得する第１の取得処理と、
    　前記サーバ情報に基づいて、前記ログ取得対象の物理サーバに対応したプログラムであって、当該物理サーバのログを取得するためのプログラムを生成する生成処理と、
    　前記プログラムを実行し、前記ログ取得対象の物理サーバのログを取得する第２の取得処理と、
    　が実行される、
    　ことを特徴とするネットワーク管理システム。
PCT/JP2022/025743 2022-06-28 2022-06-28 サーバのログ取得操作の自動化 WO2024004029A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/025743 WO2024004029A1 (ja) 2022-06-28 2022-06-28 サーバのログ取得操作の自動化

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/025743 WO2024004029A1 (ja) 2022-06-28 2022-06-28 サーバのログ取得操作の自動化

Publications (1)

Publication Number Publication Date
WO2024004029A1 true WO2024004029A1 (ja) 2024-01-04

Family

ID=89382177

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/025743 WO2024004029A1 (ja) 2022-06-28 2022-06-28 サーバのログ取得操作の自動化

Country Status (1)

Country Link
WO (1) WO2024004029A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010072758A (ja) * 2008-09-16 2010-04-02 Ricoh Co Ltd 機器管理装置、機器管理システム、機器情報取得方法、機器情報取得プログラム、及びそのプログラムを記録した記録媒体
JP2019506662A (ja) * 2015-12-23 2019-03-07 コンプテル オーユー ネットワーク管理

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010072758A (ja) * 2008-09-16 2010-04-02 Ricoh Co Ltd 機器管理装置、機器管理システム、機器情報取得方法、機器情報取得プログラム、及びそのプログラムを記録した記録媒体
JP2019506662A (ja) * 2015-12-23 2019-03-07 コンプテル オーユー ネットワーク管理

Similar Documents

Publication Publication Date Title
US9705974B2 (en) Methods and apparatus to transfer physical hardware resources between virtual rack domains in a virtualized server rack
US8910172B2 (en) Application resource switchover systems and methods
US10326645B2 (en) System and methods for configuration management
US9021294B2 (en) Discovering boot order sequence of servers belonging to an application
EP3451587B1 (en) Creating searchable and global database of user visible process traces
US11483218B2 (en) Automating 5G slices using real-time analytics
US11636016B2 (en) Cloud simulation and validation system
US20200007408A1 (en) Methods and apparatus to proactively self-heal workload domains in hyperconverged infrastructures
CN113285822B (zh) 对网络交换结构的硬件设备进行故障排除的方法和系统
CN111813495B (zh) 节点测试方法和装置、存储介质和电子装置
US10929261B1 (en) Device diagnosis
US10997042B2 (en) Systems and methods for configuration management
WO2023276039A1 (ja) サーバ管理装置、サーバ管理方法およびプログラム
WO2024004029A1 (ja) サーバのログ取得操作の自動化
EP3852424B1 (en) Application resilience for applications deployed on a cloud platform
US11539612B2 (en) Testing virtualized network functions
WO2023276038A1 (ja) サーバ管理装置、サーバ管理方法およびプログラム
WO2024042599A1 (ja) 障害発生時におけるサーバ状態確認支援
JP6818654B2 (ja) 試験自動化装置、試験方法、及びプログラム
US20240193033A1 (en) Network management apparatus, network management method and network management system
WO2023032116A1 (ja) スクリプト判別装置、スクリプト判別方法およびスクリプト判別システム
WO2023228233A1 (ja) 障害発生時における自動復旧のためのネットワーク管理
WO2024142310A1 (ja) 仮想化基盤構築におけるプロファイル管理
US11743108B1 (en) Dynamic customization of network controller data path based on controller internal state awareness
WO2022269808A1 (ja) ネットワーク管理装置、ネットワーク管理方法およびプログラム

Legal Events

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

Ref document number: 22949306

Country of ref document: EP

Kind code of ref document: A1