WO2023031993A1 - サーバ管理装置、サーバ管理方法およびプログラム - Google Patents

サーバ管理装置、サーバ管理方法およびプログラム Download PDF

Info

Publication number
WO2023031993A1
WO2023031993A1 PCT/JP2021/031703 JP2021031703W WO2023031993A1 WO 2023031993 A1 WO2023031993 A1 WO 2023031993A1 JP 2021031703 W JP2021031703 W JP 2021031703W WO 2023031993 A1 WO2023031993 A1 WO 2023031993A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
script
servers
information
network
Prior art date
Application number
PCT/JP2021/031703
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 US17/800,884 priority Critical patent/US12124857B2/en
Priority to PCT/JP2021/031703 priority patent/WO2023031993A1/ja
Publication of WO2023031993A1 publication Critical patent/WO2023031993A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4416—Network booting; Remote initial program loading [RIPL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files

Definitions

  • the present invention relates to a server management device, a server management method and a program, and more particularly to technology for managing servers deployed in a large number of accommodation stations in a mobile network.
  • Patent Literature 1 discloses a network boot using the above method and speeding up the startup.
  • the above conventional PXE boot requires a DHCP server and a TFTP server. Since a DHCP server cannot be constructed as a common network with another network beyond a network segment (router), it is necessary to provide a DHCP server for each segment. Alternatively, you need to set up a DHCP relay to allow communication with a DHCP server on another network.
  • a DHCP server is provided for each data center or each rack where physical servers are installed. I had to do some network design and set up a DHCP relay. Also, each node had to make a request to the DHCP server and the TFTP server respectively. Thus, server deployment in large-scale networks has been cumbersome and inefficient.
  • an object of the present invention is to provide a server management device, a server management method, and a program that enable rapid and efficient deployment of servers in a large-scale network.
  • one aspect of a server management apparatus is a server information acquisition unit that acquires configuration information and identifier information of a plurality of servers that configure a network; a script for booting each server, the script including the configuration information and the identifier information of each server, for each of the plurality of servers, based on the configuration information and the identifier information of the plurality of servers; a script generation unit that generates a script; a remote disk setting unit that sets the remote disk by writing the script generated by the script generation unit to a remote disk to be mounted on each of the plurality of servers; a command input unit for inputting, to each of the plurality of servers via the network, a command for mounting the remote disk set by the remote disk setting unit on the corresponding server.
  • the identifier information acquired by the server information acquisition unit may include at least the IP (Internet Protocol) address of each server.
  • the server management device may further include a second command input unit that inputs a second command for powering on the server to each of the plurality of servers via the network.
  • the server management device responds to a request from each of the plurality of servers to distribute an OS (operating system) to be installed using the identifier information set in each server, to the source server,
  • a distribution unit that distributes the OS and the installation procedure may be further provided.
  • the boot may be a PXE boot
  • the script may be an iPXE script.
  • one aspect of the server management method is a server management method executed by a server management device, comprising a step of acquiring configuration information and identifier information of a plurality of servers constituting a network; generating, for each of the plurality of servers, a script for booting each server, the script including the configuration information and the identifier information of each server, based on the configuration information and the identifier information of the plurality of servers; setting the remote disk by writing the generated script to the remote disk to be mounted on each of the plurality of servers; and mounting the set remote disk to the corresponding server. and submitting a command to each of the plurality of servers via the network.
  • one aspect of the server management program is a server management program for causing a computer to execute server management processing, the program providing the computer with configuration information of a plurality of servers constituting a network and a server information acquisition process for acquiring identifier information; and booting each of the plurality of servers based on the configuration information and the identifier information of the plurality of servers acquired by the server information acquisition process. and a script generation process for generating a script including the configuration information and the identifier information of each server; By writing a script, a remote disk setting process for setting the remote disk and a command for mounting the remote disk set by the remote disk setting process on a corresponding server are sent to the plurality of remote disks via the network. and a command input process to be input to each server.
  • servers can be rapidly and efficiently deployed in a large-scale network.
  • FIG. 1 is a conceptual diagram showing an example of a network configuration of a mobile network system according to this embodiment.
  • FIG. 2 is a block diagram showing an example of the relationship between the virtualization infrastructure of the mobile network system and the server management device.
  • FIG. 3 is an example showing the overall configuration of server provisioning in this embodiment.
  • FIG. 4 is an example showing the overall configuration of conventional server provisioning.
  • FIG. 5 is a block diagram illustrating an example of a functional configuration of a provisioning server;
  • FIG. 6 is a flowchart illustrating an operation example of a provisioning server.
  • FIG. 7 is a block diagram illustrating an example of the functional configuration of a node;
  • FIG. 8 is a flowchart illustrating an example of node operation.
  • FIG. 9 is a diagram explaining the flow of server provisioning in the mobile network system.
  • FIG. 10 is a conceptual diagram of orchestration in the mobile network system.
  • the server management device is implemented in a central data center that constitutes the core network of a mobile network built on a virtualization platform, and is accommodated in a large number of accommodation stations (data centers) arranged in the mobile network.
  • each node server device
  • the node is a general-purpose server device capable of configuring a network virtualization infrastructure
  • the provisioning target server device includes a bare metal server, which is a server before an OS (Operating System) is installed.
  • the server management device is installed in any data center other than the central data center, such as a backhaul network (mobile backhaul: MBH) that relays the radio access network (RAN) to the core network. good.
  • MBH mobile backhaul network
  • RAN radio access network
  • FIG. 1 is a conceptual diagram showing an example of a network configuration of a mobile network system 100 according to an embodiment.
  • a terminal capable of mobile communication such as a smartphone communicates wirelessly with a radio access network, and the information is transmitted to the core network via a mobile backhaul (MBH) for processing.
  • MCH mobile backhaul
  • the mobile network 100 comprises a base station 11 and a plurality of accommodating stations 12-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 from the edge data center 12 to the central data center 14 .
  • the edge data center is also referred to as a GC (Group unit Center) to distinguish it from other data centers.
  • the mobile network 100 in this embodiment may be a virtualized network built on a virtualization infrastructure.
  • software is implemented on a general-purpose server from the switchboard of the backbone network to the wireless access function of the base station.
  • the base station 11 includes an antenna, a switchboard, a battery, and the like.
  • the edge data center 12 is installed near the base stations 11 and is connected to the plurality of base stations 11 by optical fiber cables or the like.
  • the edge data center 12 implements RAN-related radio access functions.
  • the regional data center 13 is connected to a plurality of edge data centers 12 arranged in the target region. In this regional data center 13, firewall/NAT (Network Address Translation), CDN (Content Distribution Network), and various applications for edge computing are implemented by software.
  • the central data center 14 is connected to multiple regional data centers 13 .
  • the 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, the regional data center 13, and the 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, the regional data center 13, and the central data center 14 is not limited to the number shown in FIG.
  • a plurality of regional data centers 13 and central data centers 14 may be installed.
  • FIG. 2 is a block diagram showing an example of the relationship between the virtualization infrastructure and the server management device that constitute the mobile network 100. As shown in FIG. Each component shown in FIG. 2 has a reference point. Lines connecting components shown in FIG. 2 indicate that information can be sent and received from each other.
  • NFVI (NFV Infrastructure) 110 is a network function virtualization infrastructure, and includes 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 for virtualizing physical resources and providing them to VNF (Network Function Virtualization) 120 .
  • a virtualized resource is a virtualized infrastructure resource provided to the VNF 120 .
  • the NFVI 110 flexibly virtualizes hardware resources such as computing, storage, and network functions as virtualized hardware resources such as virtualized computing, virtualized storage, and virtualized networks in a virtualization layer such as a hypervisor. It is a base that can be handled.
  • a plurality of general-purpose servers constituting the NFVI 110 of FIG. 2 may be arranged in each of the data centers (accommodating stations) 12-14.
  • the number of general-purpose servers to be placed in each of the data centers 12 to 14, their placement positions, wiring, etc. are determined in advance according to the data center type (accommodating station type).
  • the general-purpose servers installed are connected by an internal network so that information can be exchanged with each other.
  • Data centers are connected by a network, and general-purpose servers provided in different data centers can transmit 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 general-purpose server and implements network functions in software. Although not shown, each VNF 120 may be provided with a management function called EM (Element Manager).
  • EM Element Manager
  • the NFVI 110 and VNF 120 in FIG. 2 constitute a virtual environment. That is, the virtualization environment is composed of three layers, hardware, virtualization layer, and virtual machine, in order from the bottom.
  • a MANO (Management and Orchestration) 130 has a virtual 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 integrated operation management of the entire system.
  • the 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
  • VNFM 132 performs life cycle management of VNF 120 .
  • VNFM 132 may be arranged in MANO 130 as a dedicated VNFM corresponding to each VNF 120 .
  • one VNFM 132 may manage the lifecycles of two or more VNFs 120 .
  • VNFM 132 may be a generic VNFM that corresponds to VNF 120 from a different vendor.
  • the VIM 133 manages and operates resources used by the VNF 120 .
  • OSS/BSS 140 is an integrated management system for mobile network 100 .
  • OSS is a system (equipment, software, mechanism, etc.) necessary for building and operating a service
  • BSS is information used for billing such as usage fees, billing, customer service, etc. It is a system (equipment, software, mechanism, etc.).
  • the server management device 150 is communicably connected to the NFVI 110, the OSS/BSS 140 and the MANO 130, and executes server management processing for managing the servers (nodes) arranged in each data center.
  • FIG. 2 shows an example in which the server management device 150 is an external function of the OSS/BSS 140 and the MANO 130, this embodiment is not limited to this.
  • the server management device 150 may be provided inside the OSS/BSS 140 or inside the MANO 130 .
  • the server management functions of the server management device 150 are part of the functions of the OSS/BSS 140 and the MANO 130 .
  • FIG. 3 is an example showing the overall configuration of server provisioning in this embodiment.
  • the provisioning server 20 includes a northbound interface (Northbound I/F) 21 , a workflow engine 22 , an information management database 23 and an HTTP (Hypertext Transfer Protocol) server 24 .
  • This provisioning server 20 constitutes a server management device in this embodiment.
  • a plurality of nodes 30 are each connected to the provisioning server 20 via a network.
  • Each node 30 has a motherboard (M/B) 31 .
  • the motherboard 31 includes a BMC (Baseboard Management Controller) chipset 32 , a remote disk 33 mounted on a remote KVM, and a UEFI (Unified Extensible Firmware Interface) 34 .
  • KVM is an abbreviation for Keyboard, Video, Mouse.
  • the motherboard 31 may include connectors for connecting various chipsets, expansion slots, power supplies, and various disk drives, although not shown.
  • the provisioning server 20 activates the workflow engine 22 according to triggers input via the northbound interface 21 .
  • the workflow engine 22 acquires the node information of the plurality of nodes 30 to be provisioned from the information management database 23 that manages the node information (server information) of the plurality of nodes (servers) 30 that constitute the mobile network 100, Necessary files are generated for each of the plurality of nodes 30 based on the obtained node information.
  • the workflow engine 22 generates a disk image of the remote disk 33 to be mounted on each of the plurality of nodes 30 based on the node information, and mounts the remote disk 33 on the corresponding node 30. Submit the mount command via the network.
  • the remote disk 33 can be mounted using the remote disk function (virtual media function) of the remote KVM functions of the motherboard 31 .
  • the workflow engine 22 can input a power command (boot command) for turning on the power of the node 30 to the node 30 via the network.
  • This boot instruction may be an IPMI command using the IPMI (Intelligent Platform Management Interface) protocol.
  • the node 30 is powered on by receiving a boot command from the provisioning server 20 using IPMI/BMC.
  • the UEFI 34 When the power is turned on, the UEFI 34 is activated, the UEFI 34 reads information written in the remote disk 33, and performs initial settings such as network settings.
  • the node 30 is equipped with a NIC (Network Interface Card) compatible with PXE (Preboot eXecution Environment).
  • the node 30 activates the boot loader (eg, syslinux) 36 with the NIC firmware (PXE) 35 and sends a distribution request for the OS to be installed to the provisioning server 20 .
  • the node 30 acquires an OS package including an OS image, an OS setting file, etc. from the HTTP server 24 in response to the distribution request, and installs the OS 37 .
  • the workflow engine 22 can also install the middleware (M/W) 38 and the like in the node 30 after the OS 37 is installed in the node 30 .
  • M/W middleware
  • FIG. 4 is an example showing the overall configuration of conventional server provisioning.
  • the example shown in FIG. 4 is an example of adopting PXE boot for network booting from firmware written in the NIC.
  • Conventional PXE booting requires obtaining a boot image over the network. Therefore, a TFTP server for distributing the boot image and a DHCP server for issuing an address for communication with the TFTP server are essential. That is, as shown in FIG. 4, the provisioning server 20A includes a DHCP server 21A, a TFTP server 22A, and an HTTP server 23A.
  • Each node 30A makes a DHCP request to the DHCP server 21A with NIC firmware (PXE) 31A according to the boot command from the provisioning server 20A.
  • This DHCP request includes an IP address request, a TFTP server address request, and the like.
  • each node 30A receives a response from the DHCP server 21A, it makes a TFTP request to the TFTP server 22A based on the received information, acquires a boot script (such as a boot image) from the TFTP server 22A, and executes it. do.
  • each node 30A activates the boot loader 32A by the executed boot script, and transmits an OS distribution request to the HTTP server 23A.
  • each node 30A acquires the OS package from the HTTP server 23A as a response to the distribution request and installs the OS 33A.
  • a DHCP server and a TFTP server are unnecessary.
  • the UEFI 34 first reads the information written in the pre-mounted remote disk 33, thereby realizing the functions of the conventional DHCP server and TFTP server such as IP address setting. be able to.
  • IP assignment by the local network can be omitted. Therefore, the OS can be installed simply by obtaining the OS package from the HTTP server. Therefore, complicated settings in the conventional L2 network can be made unnecessary.
  • FIG. 5 is a block diagram showing an example of the functional configuration of the provisioning server 20.
  • the provisioning server 20 includes a server information acquisition unit 20a, a script generation unit 20b, a remote disk setting unit 20c, a mount command input unit (command input unit) 20d, a power command input unit (second command input unit) 20e and a distribution unit 20f.
  • the server information acquisition unit 20a acquires node information (server information) from the information management database 23 according to instructions from the administrator.
  • the information management database 23 is a database that manages node information of the plurality of nodes 30 that make up the mobile network 100 .
  • the node information managed by the information management database 23 is inventory information (Inventory information) required for provisioning of the node 30, and includes node configuration information and node identifier information.
  • the node information includes identification information of the node (ID, code, serial number, MAC address, IP address, etc.), identification information of the data center to which the node belongs (ID, type, code, etc.), location information of the node (data rack name in the center, rack number, etc.).
  • the node information may be managed in the information management database 23, for example, in units of clusters (units of data center (unit of GC, etc.), units of rack, units of POD, etc.).
  • the server information acquisition unit 20a receives information (for example, GC type, etc.) regarding provisioning target nodes specified by the administrator, and acquires corresponding node information from the information management database 23 based on the received information.
  • the node information acquired at this time may be node information in units of clusters (for example, in units of GCs).
  • the script generation unit 20b generates an iPXE script corresponding to each of the plurality of nodes 30 belonging to the cluster based on the node information for each cluster.
  • the iPXE script is a script for booting each node 30 and includes identifier information such as configuration information of each node 30 and IP address of each node 30 .
  • the script generation unit 20b embeds necessary information in a predefined iPXE script template based on the node information acquired by the server information acquisition unit 20a, thereby generating an iPXE script for each node. can be generated.
  • iPXE script templates may be stored in the information management database 23 for each type such as node type or GC type.
  • the script generation unit 20b generates an installation procedure corresponding to each of the plurality of nodes 30 belonging to the cluster based on the node information for each cluster, and stores the generated installation procedure in the HTTP server 24.
  • the installation procedure is a kickstart file in which an OS installation scenario for each node 30 is set.
  • the script generation unit 20b embeds necessary information in a predefined kickstart file template based on the node information acquired by the server information acquisition unit 20a, thereby performing kickstart for each node.
  • a file can be generated.
  • kickstart file templates may be stored in the information management database 23 for each type such as node type or GC type.
  • the remote disk setting unit 20 c generates disk images in which the iPXE scripts generated by the script generating unit 20 b are written, and sets these as remote disks to be mounted on each node 30 .
  • the mount command input unit 20d inputs to the corresponding node 30 via the network a disk mount command for mounting the remote disk set by the remote disk setting unit 20c on the corresponding node 30.
  • FIG. As a result, the remote disk 33 is mounted on the mother board 31 of the node 30 to which the command is input.
  • the power command input unit 20e inputs a power command (boot instruction) for powering on the node 30 to the node 30 via the network.
  • the distribution unit 20f Upon receiving an OS distribution request from the node 30, the distribution unit 20f sends the OS package stored in the HTTP server 24 and the Distribute the kickstart file.
  • an HTTP server is used as the file server, but the file server may be an HTTPS (Hypertext Transfer Protocol Secure) server, an NFS (Network File System) server, or the like.
  • FIG. 6 is a flowchart showing an operation example of the provisioning server 20.
  • the processing shown in FIG. 6 is started when the workflow engine 22 is activated.
  • the server information acquisition unit 20a acquires node information of a plurality of target nodes, and proceeds to step S2.
  • the script generation unit 20b generates an iPXE script for each node based on the node information acquired in step S1, and proceeds to step S3.
  • the remote disk setting unit 20c sets a remote disk to be mounted on each node 30 by generating a disk image for each node in which the iPXE script for each node generated in step S2 is written. , the process proceeds to step S4.
  • step S4 the script generation unit 20b generates a kickstart file for each node based on the node information acquired in step S1, and proceeds to step S5.
  • step S5 the script generator 20b places the kickstart file generated in step S4 in the HTTP server 24, and proceeds to step S6.
  • step S6 the mount command input unit 20d inputs to each node 30 via the network a disk mount command for mounting the remote disk set in step S3 on the corresponding node 30, and the process proceeds to step S7.
  • step S7 the power command input unit 20e inputs a power command (boot instruction) for powering on each node 30 to each node 30 via the network.
  • step S8 the distribution unit 20f determines whether or not an OS distribution request has been received from the node 30. If the distribution unit 20f has not received an OS distribution request from the node 30, the distribution unit 20f waits until an OS distribution request is received. Then, the OS package stored in the HTTP server 24 and the kickstart file corresponding to the node 30, which is the source of the OS distribution request, are distributed to the node 30, which is the source of the OS distribution request.
  • FIG. 7 is a block diagram showing an example of the functional configuration of the node 30.
  • the node 30 includes a disk mount section 30a, a boot execution section 30b, an information setting section 30c, a distribution request section 30d, and an install execution section 30e.
  • the disk mount unit 30a receives a disk mount command for mounting the remote disk 33 from the provisioning server 20, and mounts the remote disk 33 on the motherboard 31 according to the received command. An iPXE script is written on this remote disk 33 .
  • the boot executing unit 30b is triggered by a power command input from the provisioning server 20, reads the iPXE script written in the remote disk 33, and executes booting.
  • the information setting unit 30c sets node configuration information, an IP address, and the like included in the iPXE script read from the remote disk 33 to its own device.
  • the distribution request unit 30d transmits a distribution request for the OS to be installed to the provisioning server 20 using the IP address set in the own device. Also, the distribution requesting unit 30d receives the OS package and the kickstart file distributed from the provisioning server 20 in response to the transmitted distribution request.
  • the installation executing unit 30e installs the OS according to the procedure of the kickstart file.
  • FIG. 8 is a flow chart showing an operation example of the node 30.
  • the processing shown in FIG. 8 is started when a disk mount command is received from the provisioning server 20 while the power of the node 30 is off.
  • the disk mount unit 30a mounts the remote disk 33 according to the disk mount command from the provisioning server 20, and proceeds to step S12.
  • the boot execution unit 30b receives a boot command from the provisioning server 20, powers on the node 30, and proceeds to step S13.
  • step S13 the boot execution unit 30b activates the UEFI 34, reads the iPXE script from the remote disk 33, and proceeds to step S14.
  • step S14 the information setting unit 30c performs network settings such as IP address settings based on the iPXE script read in step S13, and proceeds to step S15.
  • step S15 the distribution request unit 30d uses the IP address set in step S14 to transmit an OS distribution request to the HTTP server 24, acquires the OS package and the kickstart file from the HTTP server 24, The process proceeds to step S16.
  • step S16 the installation executing unit 30e installs the OS using the OS package obtained in step S15 along with the kickstart file obtained in step S15.
  • the OSS 140 which is the highest layer of the virtualized network, manages inventory information such as configuration information and identifier information of each node 30 that constitutes the mobile network 100. and a BMaaS (Bare Metal as a Service) 142 that generates and deploys scripts for executing booting and OS installation for each node using the inventory information.
  • the workflow engine 143 included in the BMaaS 142 corresponds to the workflow engine 22 shown in FIG. 3
  • the script 144 corresponds to the iPXE script generated by the workflow engine 22 shown in FIG.
  • the OSS 140 can have the functionality of the provisioning server 20 shown in FIG.
  • the network can be established simply by constructing one set of the inventory management function 141, the BMaaS 142 and the HTTP server 145 in the central data center (CDC) 14. It enables server deployment to multiple edge data centers (GC) 12 and multiple regional data centers (RDC) 13 connected via.
  • the HTTP server 145 corresponds to the HTTP server 23 shown in FIG. In this way, central control by a central data center (CDC) is possible.
  • the provisioning server 20 in this embodiment generates an iPXE script corresponding to each of the plurality of nodes 30 based on the node information of the plurality of nodes 30 forming the mobile network 100 . Then, the disk image in which the generated iPXE script is written is mounted on the remote disk 33 of each corresponding node 30 .
  • the iPXE script is a script for booting each node 30 and includes configuration information and identifier information (IP address, etc.) of each node.
  • the provisioning server 20 can input a power command for turning on the power of each node 30 to each node 30 via the network.
  • the iPXE script is read from the remote disk 33 and executed by using the power command input from the provisioning server 20 as a trigger. It is possible to set its own IP address and the like and boot without obtaining a boot script from the server.
  • the provisioning server 20 manages unique configuration information such as the IP addresses of the plurality of nodes 30 that make up the mobile network 100, and uses the remote disk function to provide the configuration information to each node 30. Deploy scripts for booting including. Therefore, each node 30 can set an IP address and acquire a boot script by referring to the remote disk 33 mounted on itself. Therefore, the DHCP server and TFTP server required for conventional PXE booting are no longer required, and for example, complicated L2 network settings can be eliminated. Also, in each node 30, it is possible to eliminate the need for requests to the DHCP server and the TFTP server respectively.
  • the provisioning server 20 when the provisioning server 20 receives an OS distribution request using the IP address set in each node 30 from each node 30, the provisioning server 20 responds to the request to the transmission source node 30 and to the HTTP server 24. Distribute the stored OS packages and kickstart files.
  • each node 30 executes the iPXE script and transmits an OS distribution request to the provisioning server 20 using the IP address set to itself, thereby obtaining the OS package and the kickstart file from the HTTP server 24. can be downloaded. Then, each node 30 can install the OS by activating the acquired kickstart file.
  • the remote disk 33 mounted on each node 30 has only the function of performing initial network settings and booting the node 30, and the files necessary for OS installation (OS package, kickstart file) are Arranged in the HTTP server 24 .
  • OS package, kickstart file the files necessary for OS installation
  • each node 30 acquires necessary files from the HTTP server 24 and installs the OS.
  • the remote disk 33 can be made very light by mounting only the minimum information required for provisioning on the remote disk 33 instead of mounting all the information necessary for provisioning.
  • the provisioning server 20 generates a kickstart file corresponding to each of the plurality of nodes 30 based on the node information of the plurality of nodes 30 constituting the mobile network 100, and the OS package stores the generated kickstart file. It can be stored in the HTTP server 24, which is an encrypted file server. Therefore, each node 30 can install the OS in an appropriate scenario according to each environment according to the kickstart file.
  • a boot provisioning server using the remote disk function can be realized, and a large-scale server can be rapidly and efficiently deployed in a large-scale network.
  • the server management device 150 may be implemented in any general-purpose server that constitutes the backhaul network, core network, or the like of the mobile network 100 .
  • the server management device 150 may be implemented in a dedicated server.
  • the server management device 150 may be implemented on a single computer or multiple computers.
  • the server management device 150 includes a CPU, ROM, RAM, HDD, input unit (keyboard, pointing device, etc.), display unit (monitor, etc.), communication I/ F etc. can be provided.
  • the server management device 150 shown in FIG. 3 can be implemented by the CPU executing the program.
  • at least some of the elements of the server management device 150 shown in FIG. 3 may operate as dedicated hardware. In this case, the dedicated hardware operates under the control of the CPU.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

大規模ネットワークにおいて、迅速かつ効率的にサーバを展開する。　サーバ管理装置は、ネットワークを構成する複数のサーバの構成情報および識別子情報を取得するサーバ情報取得部と、サーバ情報取得部により取得された複数のサーバの構成情報および識別子情報に基づいて、複数のサーバのそれぞれについて、各サーバをブートするためのスクリプトであって各サーバの構成情報および識別子情報を含むスクリプトを生成するスクリプト生成部と、複数のサーバのそれぞれにマウントされるべきリモートディスクに、スクリプト生成部により生成されたスクリプトを書き込むことで、リモートディスクを設定するリモートディスク設定部と、リモートディスク設定部により設定されたリモートディスクを、対応するサーバにマウントさせるコマンドを、ネットワークを介して、複数のサーバのそれぞれに投入するコマンド投入部と、を備える。

Description

サーバ管理装置、サーバ管理方法およびプログラム
　本発明は、サーバ管理装置、サーバ管理方法およびプログラムに関し、特に、モバイルネットワークにおいて、多数の収容局に展開されるサーバを管理するための技術に関する。
　従来のネットワークブート方式として、ＰＸＥ（Ｐｒｅｂｏｏｔ ｅＸｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ）に対応したネットワークカードとＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバおよびＴＦＴＰ（Ｔｒｉｖｉａｌ Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）サーバとを利用したＰＸＥブートがある。
　特許文献１は、上記の方式を利用したネットワークブートとその起動の高速化について開示する。
特開２００５－１４９３３４号公報
　上記従来のＰＸＥブートでは、ＤＨＣＰサーバおよびＴＦＴＰサーバを必要とする。ＤＨＣＰサーバは、ネットワークセグメント（ルータ）を越えて別のネットワークと共通のものとして構築することができないため、セグメント毎にそれぞれＤＨＣＰサーバを設ける必要がある。もしくは、ＤＨＣＰリレーを設定して、別のネットワーク上にあるＤＨＣＰサーバとの通信を可能とする必要がある。
　近年のモバイルネットワーク等の大規模ネットワークにおいては、ネットワークの構築、保守、運用に効率化および自動化が求められている。例えばデータセンタ（収容局）を新たに構築する場合には、当該データセンタに物理サーバを設置し、設置した物理サーバにＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）等をインストールしていくが、こうしたデータセンタは多数存在し、地理的にも分散配置されているため、遠隔でＯＳ等のインストールが行われる。
　しかしながら、このような大規模ネットワークにおいて、上記従来のＰＸＥブートを利用したＯＳインストールを行う場合、例えばデータセンタ単位や物理サーバが設置されたラック単位でそれぞれＤＨＣＰサーバを設け、それぞれの環境に応じたネットワーク設計を行ったり、ＤＨＣＰリレーを設定したりする必要があった。また、各ノードにおいては、ＤＨＣＰサーバおよびＴＦＴＰサーバそれぞれに対して要求を行う必要があった。このように、大規模ネットワークにおけるサーバ展開は煩雑かつ非効率的であった。
　そこで、本発明は、大規模ネットワークにおいて、迅速かつ効率的にサーバを展開していくことが可能なサーバ管理装置、サーバ管理方法およびプログラムを提供することを課題とする。
　上記課題を解決するために、本発明に係るサーバ管理装置の一態様は、ネットワークを構成する複数のサーバの構成情報および識別子情報を取得するサーバ情報取得部と、前記サーバ情報取得部により取得された前記複数のサーバの前記構成情報および前記識別子情報に基づいて、前記複数のサーバのそれぞれについて、各サーバをブートするためのスクリプトであって各サーバの前記構成情報および前記識別子情報を含むスクリプトを生成するスクリプト生成部と、前記複数のサーバのそれぞれにマウントされるべきリモートディスクに、前記スクリプト生成部により生成された前記スクリプトを書き込むことで、前記リモートディスクを設定するリモートディスク設定部と、前記リモートディスク設定部により設定された前記リモートディスクを、対応するサーバにマウントさせるコマンドを、前記ネットワークを介して、前記複数のサーバのそれぞれに投入するコマンド投入部と、を備える。
　前記サーバ情報取得部により取得される前記識別子情報は、少なくとも各サーバのＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）アドレスを含んでよい。
　前記サーバ管理装置は、前記サーバの電源をオンさせる第２のコマンドを、前記ネットワークを介して、前記複数のサーバのそれぞれに投入する第２のコマンド投入部をさらに備えてよい。
　前記サーバ管理装置は、前記複数のサーバのそれぞれから、各サーバに設定された前記識別子情報を用いた、インストールすべきＯＳ（オペレーティングシステム）の配信の要求に応答して、送信元のサーバに、前記ＯＳおよびインストールプロシージャを配信する配信部をさらに備えてよい。
　前記ブートはＰＸＥブートであり、前記スクリプトはｉＰＸＥスクリプトであってよい。
　また、本発明に係るサーバ管理方法の一態様は、サーバ管理装置が実行するサーバ管理方法であって、ネットワークを構成する複数のサーバの構成情報および識別子情報を取得するステップと、取得された前記複数のサーバの前記構成情報および前記識別子情報に基づいて、前記複数のサーバのそれぞれについて、各サーバをブートするためのスクリプトであって各サーバの前記構成情報および前記識別子情報を含むスクリプトを生成するステップと、前記複数のサーバのそれぞれにマウントされるべきリモートディスクに、生成された前記スクリプトを書き込むことで、前記リモートディスクを設定するステップと、設定された前記リモートディスクを、対応するサーバにマウントさせるコマンドを、前記ネットワークを介して、前記複数のサーバのそれぞれに投入するステップと、を含む。
　さらに、本発明に係るサーバ管理プログラムの一態様は、サーバ管理処理をコンピュータに実行させるためのサーバ管理プログラムであって、該プログラムは、前記コンピュータに、ネットワークを構成する複数のサーバの構成情報および識別子情報を取得するサーバ情報取得処理と、前記サーバ情報取得処理により取得された前記複数のサーバの前記構成情報および前記識別子情報に基づいて、前記複数のサーバのそれぞれについて、各サーバをブートするためのスクリプトであって各サーバの前記構成情報および前記識別子情報を含むスクリプトを生成するスクリプト生成処理と、前記複数のサーバのそれぞれにマウントされるべきリモートディスクに、前記スクリプト生成処理により生成された前記スクリプトを書き込むことで、前記リモートディスクを設定するリモートディスク設定処理と、前記リモートディスク設定処理により設定された前記リモートディスクを、対応するサーバにマウントさせるコマンドを、前記ネットワークを介して、前記複数のサーバのそれぞれに投入するコマンド投入処理と、を含む処理を実行させるためのものである。
　本発明の一つの態様によれば、大規模ネットワークにおいて、迅速かつ効率的にサーバを展開していくことができる。
　上記した本発明の目的、態様及び効果並びに上記されなかった本発明の目的、態様及び効果は、当業者であれば添付図面及び請求の範囲の記載を参照することにより下記の発明を実施するための形態から理解できるであろう。
図１は、本実施形態におけるモバイルネットワークシステムのネットワーク構成の一例を示す概念図である。 図２は、モバイルネットワークシステムの仮想化基盤とサーバ管理装置との関係の一例を示すブロック図である。 図３は、本実施形態におけるサーバプロビジョニングの全体構成を示す一例である。 図４は、従来のサーバプロビジョニングの全体構成を示す一例である。 図５は、プロビジョニングサーバの機能構成の一例を示すブロック図である。 図６は、プロビジョニングサーバの動作例を示すフローチャートである。 図７は、ノードの機能構成の一例を示すブロック図である。 図８は、ノードの動作例を示すフローチャートである。 図９は、モバイルネットワークシステムにおけるサーバプロビジョニングの流れを説明する図である。 図１０は、モバイルネットワークシステムにおけるオーケストレーションの概念図である。
　以下、添付図面を参照して、本発明を実施するための実施形態について詳細に説明する。以下に開示される構成要素のうち、同一機能を有するものには同一の符号を付し、その説明を省略する。なお、以下に開示される実施形態は、本発明の実現手段としての一例であり、本発明が適用される装置の構成や各種条件によって適宜修正または変更されるべきものであり、本発明は以下の実施形態に限定されるものではない。また、本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。
　以下、本実施形態に係るサーバ管理装置が、仮想化基盤で構築されたモバイルネットワークのコアネットワークを構成する中央データセンタにおいて実装され、モバイルネットワークに配置される多数の収容局（データセンタ）に収容される各ノード（サーバ装置）に接続されて、各ノードのプロビジョニングを行う例について説明する。ここで、上記ノードは、ネットワーク仮想化基盤を構成可能な汎用サーバ装置であって、プロビジョニング対象のサーバ装置は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）がインストールされる前のサーバであるベアメタルサーバを含む。
　しかしながら、本実施形態はこれに限定されない。サーバ管理装置は、中央データセンタ以外、例えば無線アクセスネットワーク（Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ：ＲＡＮ）をコアネットワークに中継するバックホールネットワーク（モバイルバックホール：ＭＢＨ）等を構成するいずれかのデータセンタに実装されてよい。
　図１は、実施形態におけるモバイルネットワークシステム１００のネットワーク構成の一例を示す概念図である。
　図１に示すモバイルネットワーク１００においては、スマートフォンなどのモバイル通信可能な端末と無線アクセスネットワークとが無線通信し、その情報を、モバイルバックホール（ＭＢＨ）を中継してコアネットワークに送って処理することで、インターネット２００に接続したり、他社のネットワークと接続して音声通話をしたりすることができる。
　具体的には、モバイルネットワーク１００は、基地局１１と、複数の収容局１２～１４と、を備えて構成される。ここで、収容局１２はエッジデータセンタ、収容局１３は地域データセンタ（Regional Data Center：ＲＤＣ）、収容局１４は中央データセンタ（Central Data Center：ＣＤＣ）である。エッジデータセンタ１２から中央データセンタ１４までの間でバックホールネットワークが構成される。なお、以下の説明では、エッジデータセンタを他のデータセンタと区別するためにＧＣ（Group unit 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）１４０からの指示に応じた処理を行うことができる。
　ＶＮＦＭ１３２は、ＶＮＦ１２０のライフサイクル管理を行う。なお、ＶＮＦＭ１３２は、ＶＮＦ１２０毎に、それぞれ対応する専用ＶＮＦＭとしてＭＡＮＯ１３０に配置されていてもよい。または、１つのＶＮＦＭ１３２が、２以上のＶＮＦ１２０のライフサイクルを管理してもよい。この場合、ＶＮＦＭ１３２は、異なるベンダから提供されるＶＮＦ１２０に対応する汎用ＶＮＦＭであってもよい。
　ＶＩＭ１３３は、ＶＮＦ１２０が使用するリソースの運用管理を行う。
　ＯＳＳ／ＢＳＳ１４０は、モバイルネットワーク１００の統合管理システムである。
　ここで、ＯＳＳは、サービスを構築し、運営していくために必要なシステム（機器やソフトウェア、仕組みなど）であり、ＢＳＳは、利用料などの課金、請求、顧客対応などのために用いる情報システム（機器やソフトウェア、仕組みなど）である。
　サーバ管理装置１５０は、ＮＦＶＩ１１０、ＯＳＳ／ＢＳＳ１４０およびＭＡＮＯ１３０と通信可能に接続され、各データセンタに配置されたサーバ（ノード）を管理するサーバ管理処理を実行する。
　なお、図２は、サーバ管理装置１５０が、ＯＳＳ／ＢＳＳ１４０やＭＡＮＯ１３０の外部機能である例を示すが、本実施形態はこれに限定されない。例えば、サーバ管理装置１５０は、ＯＳＳ／ＢＳＳ１４０の内部に設けられていてもよいし、ＭＡＮＯ１３０の内部に設けられていてもよい。この場合、サーバ管理装置１５０が有するサーバ管理機能は、ＯＳＳ／ＢＳＳ１４０やＭＡＮＯ１３０の機能の一部となる。
　図３は、本実施形態におけるサーバプロビジョニングの全体構成を示す一例である。
　プロビジョニングサーバ２０は、ノースバウンドインタフェース（Northbound I/F）２１と、ワークフローエンジン２２と、情報管理データベース２３と、ＨＴＴＰ（Hypertext Transfer Protocol）サーバ２４と、を備える。このプロビジョニングサーバ２０が、本実施形態におけるサーバ管理装置を構成している。
　複数のノード３０は、ネットワークを介してプロビジョニングサーバ２０とそれぞれ接続されている。各ノード３０は、マザーボード（Ｍ／Ｂ）３１を備える。マザーボード３１は、ＢＭＣ（Baseboard Management Controller）チップセット３２と、リモートＫＶＭにマウントされたリモートディスク３３と、ＵＥＦＩ（Unified Extensible Firmware Interface）３４と、を備える。ここで、ＫＶＭは、Ｋｅｙｂｏａｒｄ，Ｖｉｄｅｏ，Ｍｏｕｓｅの略である。なお、特に図示しないが、マザーボード３１は、上記の他に各種チップセット、拡張スロット、電源や各種ディスクドライブを接続するコネクタを備えてよい。
　プロビジョニングサーバ２０は、ノースバウンドインタフェース２１を介して入力されるトリガに従ってワークフローエンジン２２を起動する。
　ワークフローエンジン２２は、モバイルネットワーク１００を構成する複数のノード（サーバ）３０のノード情報（サーバ情報）を管理する情報管理データベース２３から、プロビジョニングの対象となる複数のノード３０のノード情報を取得し、取得されたノード情報に基づいて、複数のノード３０のそれぞれについて必要なファイルを生成する。
　具体的には、ワークフローエンジン２２は、ノード情報に基づいて、複数のノード３０のそれぞれにマウントされるべきリモートディスク３３のディスクイメージを生成し、対応するノード３０に、リモートディスク３３をマウントさせるディスクマウントコマンドを、ネットワークを介して投入する。リモートディスク３３は、マザーボード３１のリモートＫＶＭ機能のうち、リモートディスク機能（仮想メディア機能）を用いてマウントすることができる。
　また、ワークフローエンジン２２は、ノード３０の電源をオンさせる電源コマンド（ブート命令）を、ネットワークを介してノード３０に投入することができる。このブート命令は、ＩＰＭＩ（Intelligent Platform Management Interface）プロトコルを用いたＩＰＭＩコマンドであってよい。
　ノード３０は、プロビジョニングサーバ２０からＩＰＭＩ／ＢＭＣを用いてブート命令を受信することで、電源がオンされる。電源がオンすると、ＵＥＦＩ３４が起動され、ＵＥＦＩ３４がリモートディスク３３に書き込まれた情報を読み出し、ネットワーク設定等の初期設定を行う。
　また、ノード３０には、ＰＸＥ（Preboot eXecution Environment）に対応したＮＩＣ（Network Interface Card）が搭載されている。ノード３０は、リモートディスク３３に書き込まれた情報を用いてＮＩＣファームウェア（ＰＸＥ）３５でブートローダ（例えばｓｙｓｌｉｎｕｘ）３６を起動し、プロビジョニングサーバ２０に対してインストールすべきＯＳの配信要求を送信する。そして、ノード３０は、当該配信要求の応答としてＨＴＴＰサーバ２４からＯＳイメージやＯＳ設定ファイル等を含むＯＳパッケージを取得して、ＯＳ３７をインストールする。
　なお、ワークフローエンジン２２は、ノード３０においてＯＳ３７がインストールされた後、ノード３０にミドルウェア（Ｍ／Ｗ）３８等をインストールすることもできる。
　図４は、従来のサーバプロビジョニングの全体構成を示す一例である。
　この図４に示す例は、ＮＩＣに書き込まれたファームウェアからネットワークブートするＰＸＥブートを採用した例である。
　従来のＰＸＥブートでは、ネットワーク経由でブートイメージを取得する必要がある。そのため、ブートイメージを配布するためのＴＦＴＰサーバと、ＴＦＴＰサーバと通信するためのアドレスを払い出すＤＨＣＰサーバとが必須となる。
　つまり、図４に示すように、プロビジョニングサーバ２０Ａは、ＤＨＣＰサーバ２１Ａと、ＴＦＴＰサーバ２２Ａと、ＨＴＴＰサーバ２３Ａと、を備える。
　各ノード３０Ａは、プロビジョニングサーバ２０Ａからのブート命令に従って、ＮＩＣファームウェア（ＰＸＥ）３１ＡでＤＨＣＰサーバ２１Ａに対してＤＨＣＰ要求を行う。このＤＨＣＰ要求には、ＩＰアドレス要求やＴＦＴＰサーバアドレス要求等が含まれる。
　また、各ノード３０Ａは、ＤＨＣＰサーバ２１Ａから応答を受け取ると、受け取った情報をもとにＴＦＴＰサーバ２２Ａに対してＴＦＴＰ要求を行い、ＴＦＴＰサーバ２２Ａからブートスクリプト（ブートイメージ等）を取得し、実行する。
　そして、各ノード３０Ａは、実行されたブートスクリプトによってブートローダ３２Ａが起動し、ＨＴＴＰサーバ２３Ａに対してＯＳの配信要求を送信する。そして、各ノード３０Ａは、当該配信要求の応答としてＨＴＴＰサーバ２３ＡからＯＳパッケージを取得して、ＯＳ３３Ａをインストールする。
　このように、従来のＰＸＥブートでは、ＤＨＣＰサーバおよびＴＦＴＰサーバを必要とする。しかしながら、ＤＨＣＰサーバはＬ２ネットワーク毎に設ける必要があるため、モバイルネットワーク１００のような大規模ネットワークにおいては、例えばデータセンタ単位やラック単位でＤＨＣＰサーバを設ける必要があった。つまり、データセンタ単位やラック単位でプロビジョニングサーバ２０Ａを構築する必要があった。
　これに対して、本実施形態では、ＤＨＣＰサーバおよびＴＦＴＰサーバは不要である。各ノード３０においては、電源オンで、まず、ＵＥＦＩ３４が、予めマウントされたリモートディスク３３に書き込まれた情報を読み込むことで、ＩＰアドレスの設定等、従来のＤＨＣＰサーバやＴＦＴＰサーバの機能を実現することができる。つまり、各ノード３０の固有の設定情報はそれぞれ各ノード３０のリモートディスク３３によって管理することで、ローカルネットワークによるＩＰ付与を省略することができる。そのため、ＨＴＴＰサーバからＯＳパッケージを取得するだけでＯＳのインストールが可能である。したがって、従来のＬ２ネットワークにおける煩雑な設定を不要とすることができる。
　以下、プロビジョニングサーバ２０の具体的構成について説明する。
　図５は、プロビジョニングサーバ２０の機能構成の一例を示すブロック図である。
　この図５に示すように、プロビジョニングサーバ２０は、サーバ情報取得部２０ａ、スクリプト生成部２０ｂ、リモートディスク設定部２０ｃ、マウントコマンド投入部（コマンド投入部）２０ｄ、電源コマンド投入部（第２のコマンド投入部）２０ｅおよび配信部２０ｆを備える。
　サーバ情報取得部２０ａは、管理者による指示に従って情報管理データベース２３からノード情報（サーバ情報）を取得する。
　情報管理データベース２３は、モバイルネットワーク１００を構成する複数のノード３０のノード情報を管理するデータベースである。この情報管理データベース２３が管理するノード情報は、ノード３０のプロビジョニングに必要なインベントリ情報（Inventory情報）であり、ノードの構成情報とノードの識別子情報とを含む。例えば、ノード情報は、ノードの識別情報（ＩＤ、コード、シリアルナンバー、ＭＡＣアドレス、ＩＰアドレス等）、当該ノードが属するデータセンタの識別情報（ＩＤ、タイプ、コード等）、ノードの位置情報（データセンタ内のラック名、ラック番号等）などを含んでよい。また、ノード情報は、情報管理データベース２３において、例えばクラスタ単位（データセンタ単位（ＧＣ単位等）、ラック単位、ＰＯＤ単位等）で管理されてよい。
　サーバ情報取得部２０ａは、管理者によって指定されたプロビジョニングの対象ノードに関する情報（例えばＧＣタイプ等）を受信し、受信した情報をもとに情報管理データベース２３から対応するノード情報を取得する。このとき取得されるノード情報は、クラスタ単位（例えばＧＣ単位）のノード情報であってよい。
　スクリプト生成部２０ｂは、クラスタ単位のノード情報に基づいて、当該クラスタに属する複数のノード３０にそれぞれ対応するｉＰＸＥスクリプトを生成する。ここで、ｉＰＸＥスクリプトは、各ノード３０をブートするためのスクリプトであって、各ノード３０の構成情報および各ノード３０のＩＰアドレス等の識別子情報を含む。
　具体的には、スクリプト生成部２０ｂは、予め定義されたｉＰＸＥスクリプトのテンプレートに、サーバ情報取得部２０ａにより取得されたノード情報をもとに必要な情報を埋め込むことで、ノード毎のｉＰＸＥスクリプトを生成することができる。例えば、ｉＰＸＥスクリプトのテンプレートは、ノードのタイプやＧＣのタイプ等の種類毎に情報管理データベース２３に格納されてよい。
　さらに、スクリプト生成部２０ｂは、クラスタ単位のノード情報に基づいて、当該クラスタに属する複数のノード３０にそれぞれ対応するインストールプロシージャを生成し、生成したインストールプロシージャをＨＴＴＰサーバ２４に格納する。ここで、上記インストールプロシージャは、ノード３０毎のＯＳインストールのシナリオを設定したキックスタートファイルである。
　具体的には、スクリプト生成部２０ｂは、予め定義されたキックスタートファイルのテンプレートに、サーバ情報取得部２０ａにより取得されたノード情報をもとに必要な情報を埋め込むことで、ノード毎のキックスタートファイルを生成することができる。例えば、キックスタートファイルのテンプレートは、ノードのタイプやＧＣのタイプ等の種類毎に情報管理データベース２３に格納されてよい。
　リモートディスク設定部２０ｃは、スクリプト生成部２０ｂにより生成されたｉＰＸＥスクリプトをそれぞれ書き込んだディスクイメージを生成し、これを各ノード３０にマウントされるべきリモートディスクして設定する。
　マウントコマンド投入部２０ｄは、リモートディスク設定部２０ｃにより設定されたリモートディスクを対応するノード３０にマウントさせるディスクマウントコマンドを、ネットワークを介して対応するノード３０に対して投入する。これにより、コマンドが投入されたノード３０が有するマザーボード３１にリモートディスク３３がマウントされる。
　電源コマンド投入部２０ｅは、ノード３０の電源をオンさせる電源コマンド（ブート命令）を、ネットワークを介してノード３０に対して投入する。
　配信部２０ｆは、ノード３０からのＯＳの配信要求を受信した場合に、当該配信要求に応答して、当該配信要求の送信元のノード３０に対して、ＨＴＴＰサーバ２４に格納されたＯＳパッケージおよびキックスタートファイルを配信する。
　なお、本実施形態ではファイルサーバとしてＨＴＴＰサーバを用いる場合について説明するが、ファイルサーバは、ＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ）サーバやＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ）サーバ等であってもよい。
　図６は、プロビジョニングサーバ２０の動作例を示すフローチャートである。
　この図６に示す処理は、ワークフローエンジン２２が起動されたタイミングで開始される。
　まずステップＳ１において、サーバ情報取得部２０ａは、複数の対象ノードのノード情報を取得し、ステップＳ２に移行する。
　ステップＳ２では、スクリプト生成部２０ｂは、ステップＳ１において取得されたノード情報に基づいて、ノード毎のｉＰＸＥスクリプトを生成し、ステップＳ３に移行する。
　ステップＳ３では、リモートディスク設定部２０ｃは、ステップＳ２において生成されたノード毎のｉＰＸＥスクリプトをそれぞれ書き込んだノード毎のディスクイメージを生成することで、各ノード３０にマウントされるべきリモートディスクを設定し、ステップＳ４に移行する。
　ステップＳ４では、スクリプト生成部２０ｂは、ステップＳ１において取得されたノード情報に基づいて、ノード毎のキックスタートファイルをそれぞれ生成し、ステップＳ５に移行する。
　ステップＳ５では、スクリプト生成部２０ｂは、ステップＳ４において生成されたキックスタートファイルをＨＴＴＰサーバ２４に配置し、ステップＳ６に移行する。
　ステップＳ６では、マウントコマンド投入部２０ｄは、ステップＳ３において設定されたリモートディスクを対応するノード３０にマウントさせるためのディスクマウントコマンドを、ネットワークを介して各ノード３０に投入し、ステップＳ７に移行する。
　ステップＳ７では、電源コマンド投入部２０ｅは、各ノード３０の電源をオンさせるための電源コマンド（ブート命令）を、ネットワークを介して各ノード３０に投入する。
　ステップＳ８では、配信部２０ｆは、ノード３０からＯＳの配信要求を受信したか否かを判定する。そして、配信部２０ｆは、ノード３０からのＯＳ配信要求を受信していない場合には、ＯＳ配信要求を受信するまで待機し、ノード３０からＯＳの配信要求を受信した場合には、ステップＳ９に移行して、ＯＳ配信要求の送信元のノード３０に対して、ＨＴＴＰサーバ２４に格納されたＯＳパッケージと、ＯＳ配信要求の送信元のノード３０に対応したキックスタートファイルとを配信する。
　図７は、ノード３０の機能構成の一例を示すブロック図である。
　この図７に示すように、ノード３０は、ディスクマウント部３０ａと、ブート実行部３０ｂと、情報設定部３０ｃと、配布要求部３０ｄと、インストール実行部３０ｅと、を備える。
　ディスクマウント部３０ａは、プロビジョニングサーバ２０からリモートディスク３３をマウントするためのディスクマウントコマンドを受信し、受信されたコマンドに従って、リモートディスク３３をマザーボード３１にマウントする。このリモートディスク３３には、ｉＰＸＥスクリプトが書き込まれている。
　ブート実行部３０ｂは、プロビジョニングサーバ２０から投入される電源コマンドをトリガにして、リモートディスク３３に書き込まれたｉＰＸＥスクリプトを読み出してブートを実行する。
　情報設定部３０ｃは、リモートディスク３３から読み出したｉＰＸＥスクリプトに含まれるノードの構成情報やＩＰアドレス等を自装置に設定する。
　配布要求部３０ｄは、自装置に設定されたＩＰアドレスを用いて、インストールすべきＯＳの配信要求を、プロビジョニングサーバ２０に送信する。また、配布要求部３０ｄは、送信した配信要求に応答してプロビジョニングサーバ２０から配信されるＯＳパッケージおよびキックスタートファイルを受信する。
　インストール実行部３０ｅは、キックスタートファイルのプロシージャに沿ってＯＳをインストールする。
　図８は、ノード３０の動作例を示すフローチャートである。
　この図８に示す処理は、ノード３０の電源が入っていない状態で、プロビジョニングサーバ２０からのディスクマウントコマンドを受信したタイミングで開始される。
　まずステップＳ１１において、ディスクマウント部３０ａは、プロビジョニングサーバ２０からのディスクマウントコマンドに従ってリモートディスク３３をマウントし、ステップＳ１２に移行する。
　次にステップＳ１２では、ブート実行部３０ｂは、プロビジョニングサーバ２０からのブート命令を受信してノード３０の電源をオンし、ステップＳ１３に移行する
　ステップＳ１３では、ブート実行部３０ｂは、ＵＥＦＩ３４を起動し、リモートディスク３３からｉＰＸＥスクリプトを読み込み、ステップＳ１４に移行する。
　ステップＳ１４では、情報設定部３０ｃは、ステップＳ１３において読み込まれたｉＰＸＥスクリプトをもとにＩＰアドレスの設定等のネットワーク設定を行い、ステップＳ１５に移行する。
　ステップＳ１５では、配布要求部３０ｄは、ステップＳ１４において設定されたＩＰアドレスを用いて、ＨＴＴＰサーバ２４に対してＯＳの配信要求を送信し、ＨＴＴＰサーバ２４からＯＳパッケージおよびキックスタートファイルを取得し、ステップＳ１６に移行する。
　ステップＳ１６では、インストール実行部３０ｅは、ステップＳ１５において取得されたキックスタートファイルに沿って、ステップＳ１５において取得されたＯＳパッケージを用いてＯＳのインストールを実行する。
　本実施形態のモバイルネットワーク１００においては、例えば図９に示すように、仮想化ネットワークの最上位層であるＯＳＳ１４０が、モバイルネットワーク１００を構成する各ノード３０の構成情報や識別子情報といったインベントリ情報を管理するインベントリ管理機能１４１と、上記インベントリ情報を用いて、ノード毎のブートやＯＳインストールを実行するためのスクリプトを生成して展開するＢＭａａＳ（Ｂａｒｅ Ｍｅｔａｌ ａｓ　ａ　Ｓｅｒｖｉｃｅ）１４２と、を有することができる。ここで、ＢＭａａＳ１４２が備えるワークフローエンジン１４３は、図３に示すワークフローエンジン２２に対応し、スクリプト１４４は、図３に示すワークフローエンジン２２によって生成されるｉＰＸＥスクリプトに対応する。
　このように、ＯＳＳ１４０が、図３に示すプロビジョニングサーバ２０の機能を有することができる。
　この場合、本実施形態のモバイルネットワーク１００においては、例えば図１０に示すように、中央データセンタ（ＣＤＣ）１４に、インベントリ管理機能１４１、ＢＭａａＳ１４２およびＨＴＴＰサーバ１４５を１セット構築するだけで、ネットワークを介して接続された多数のエッジデータセンタ（ＧＣ）１２および多数の地域データセンタ（ＲＤＣ）１３へのサーバ展開が可能となる。ここで、ＨＴＴＰサーバ１４５は、図３に示すＨＴＴＰサーバ２３に対応する。
　このように、中央データセンタ（ＣＤＣ）による中央制御が可能となる。
　以上説明したように、本実施形態におけるプロビジョニングサーバ２０は、モバイルネットワーク１００を構成する複数のノード３０のノード情報に基づいて、複数のノード３０のそれぞれに対応したｉＰＸＥスクリプトを生成する。そして、生成されたｉＰＸＥスクリプトを書き込んだディスクイメージを、それぞれ対応するノード３０のリモートディスク３３にマウントする。ここで、ｉＰＸＥスクリプトは、各ノード３０をブートするためのスクリプトであって、各ノードの構成情報および識別子情報（ＩＰアドレス等）を含むスクリプトである。
　また、プロビジョニングサーバ２０は、各ノード３０の電源をオンさせる電源コマンドを、ネットワークを介して各ノード３０にそれぞれ投入することができる。
　したがって、各ノード３０においては、プロビジョニングサーバ２０から投入される電源コマンドをトリガにして、リモートディスク３３からｉＰＸＥスクリプトを読み込んで実行することで、ＤＨＣＰサーバからＩＰアドレスを取得することなく、また、ＴＦＴＰサーバからブートスクリプトを取得することなく、自身のＩＰアドレス等を設定し、ブートすることができる。
　このように、プロビジョニングサーバ２０が、モバイルネットワーク１００を構成する複数のノード３０のＩＰアドレス等の固有な構成情報を管理し、リモートディスク機能を用いて、各ノード３０に対してそれぞれ上記構成情報を含むブート用のスクリプトを展開する。そのため、各ノード３０においては、自身にマウントされたリモートディスク３３を参照することで、ＩＰアドレス等の設定やブートスクリプトの取得が可能となる。
　したがって、従来のＰＸＥブートで必要であったＤＨＣＰサーバおよびＴＦＴＰサーバは不要となり、例えばＬ２ネットワークの煩雑な設定等を不要とすることができる。また、各ノード３０においては、ＤＨＣＰサーバ、ＴＦＴＰサーバそれぞれに対する要求を不要とすることができる。
　さらに、プロビジョニングサーバ２０は、各ノード３０から、各ノード３０に設定されたＩＰアドレスを用いたＯＳの配信要求を受信すると、その要求に応答して、送信元のノード３０に、ＨＴＴＰサーバ２４に格納されたＯＳパッケージおよびキックスタートファイルを配信する。
　つまり、各ノード３０においては、ｉＰＸＥスクリプトを実行して、自身に設定されたＩＰアドレスを用いてＯＳの配信要求をプロビジョニングサーバ２０に送信することで、ＨＴＴＰサーバ２４からＯＳパッケージおよびキックスタートファイルをダウンロードすることができる。そして、各ノード３０は、取得したキックスタートファイルを起動することにより、ＯＳをインストールすることができる。
　このように、各ノード３０にマウントされるリモートディスク３３は、初期設定であるネットワーク設定を行ってノード３０をブートできる機能のみを備え、ＯＳインストールに必要なファイル（ＯＳパッケージ、キックスタートファイル）はＨＴＴＰサーバ２４に配置する。そして、各ノード３０は、ＯＳインストールを行う際に、ＨＴＴＰサーバ２４から必要なファイルを取得し、ＯＳをインストールする。つまり、リモートディスク３３にプロビジョニングに必要なすべての情報をマウントするのではなく、必要最低限の情報のみをマウントすることで、リモートディスク３３を非常に軽くすることができる。
　また、プロビジョニングサーバ２０は、モバイルネットワーク１００を構成する複数のノード３０のノード情報に基づいて、複数のノード３０のそれぞれに対応したキックスタートファイルを生成し、生成したキックスタートファイルをＯＳパッケージが格納されたファイルサーバであるＨＴＴＰサーバ２４に格納することができる。
　したがって、各ノード３０は、キックスタートファイルに沿って、それぞれの環境に応じた適切なシナリオでＯＳをインストールすることができる。
　以上のように、本実施形態では、リモートディスク機能を用いたブート・プロビジョニングサーバを実現することができ、大規模ネットワークにおいて、迅速かつ効率的にサーバを大規模展開することができる。
　本実施形態に係るサーバ管理装置１５０は、モバイルネットワーク１００のバックホールネットワークやコアネットワーク等を構成するいずれかの汎用サーバに実装されてよい。なお、サーバ管理装置１５０は、専用サーバに実装されてもよい。また、サーバ管理装置１５０は、単一または複数のコンピュータ上に実装されてもよい。
　サーバ管理装置１５０が単一のコンピュータに実装される場合、当該サーバ管理装置１５０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＨＤＤ、入力部（キーボード、ポインティングデバイス等）、表示部（モニター等）、通信Ｉ／Ｆ等を備えることができる。この場合、図３に示すサーバ管理装置１５０の各要素の少なくとも一部の機能は、上記ＣＰＵがプログラムを実行することで実現することができる。ただし、図３に示すサーバ管理装置１５０の各要素のうちの少なくとも一部が専用のハードウェアとして動作するようにしてもよい。この場合、専用のハードウェアは、上記ＣＰＵの制御に基づいて動作する。
　なお、上記において特定の実施形態が説明されているが、当該実施形態は単なる例示であり、本発明の範囲を限定する意図はない。本明細書に記載された装置及び方法は上記した以外の形態において具現化することができる。また、本発明の範囲から離れることなく、上記した実施形態に対して適宜、省略、置換及び変更をなすこともできる。かかる省略、置換及び変更をなした形態は、請求の範囲に記載されたもの及びこれらの均等物の範疇に含まれ、本発明の技術的範囲に属する。
　１１…基地局、１２…エッジデータセンタ、１３…地域データセンタ、１４…中央データセンタ、２０…プロビジョニングサーバ、２２…ワークフローエンジン、２３…情報管理データベース、２４…ＨＴＴＰサーバ、３０…ノード、３１…マザーボード、３３…リモートディスク、３４…ＵＥＦＩ、３５…ＮＩＣファームウェア（ＰＸＥ）、１００…モバイルネットワーク、１５０…サーバ管理装置
 

 

Claims (7)

  1. 　ネットワークを構成する複数のサーバの構成情報および識別子情報を取得するサーバ情報取得部と、
    　前記サーバ情報取得部により取得された前記複数のサーバの前記構成情報および前記識別子情報に基づいて、前記複数のサーバのそれぞれについて、各サーバをブートするためのスクリプトであって各サーバの前記構成情報および前記識別子情報を含むスクリプトを生成するスクリプト生成部と、
    　前記複数のサーバのそれぞれにマウントされるべきリモートディスクに、前記スクリプト生成部により生成された前記スクリプトを書き込むことで、前記リモートディスクを設定するリモートディスク設定部と、
    　前記リモートディスク設定部により設定された前記リモートディスクを、対応するサーバにマウントさせるコマンドを、前記ネットワークを介して、前記複数のサーバのそれぞれに投入するコマンド投入部と、
    　を備えることを特徴とするサーバ管理装置。
  2. 　前記サーバ情報取得部により取得される前記識別子情報は、少なくとも各サーバのＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）アドレスを含む
    　ことを特徴とする請求項１に記載のサーバ管理装置。
  3. 　前記サーバの電源をオンさせる第２のコマンドを、前記ネットワークを介して、前記複数のサーバのそれぞれに投入する第２のコマンド投入部をさらに備える
    　ことを特徴とする請求項１または２に記載のサーバ管理装置。
  4. 　前記複数のサーバのそれぞれから、各サーバに設定された前記識別子情報を用いた、インストールすべきＯＳ（オペレーティングシステム）の配信の要求に応答して、送信元のサーバに、前記ＯＳおよびインストールプロシージャを配信する配信部をさらに備える
    　ことを特徴とする請求項１から３のいずれか１項に記載のサーバ管理装置。
  5. 　前記ブートはＰＸＥブートであり、前記スクリプトはｉＰＸＥスクリプトであることを特徴とする請求項１から４のいずれか１項に記載のサーバ管理装置。
  6. 　サーバ管理装置が実行するサーバ管理方法であって、
    　ネットワークを構成する複数のサーバの構成情報および識別子情報を取得するステップと、
    　取得された前記複数のサーバの前記構成情報および前記識別子情報に基づいて、前記複数のサーバのそれぞれについて、各サーバをブートするためのスクリプトであって各サーバの前記構成情報および前記識別子情報を含むスクリプトを生成するステップと、
    　前記複数のサーバのそれぞれにマウントされるべきリモートディスクに、生成された前記スクリプトを書き込むことで、前記リモートディスクを設定するステップと、
    　設定された前記リモートディスクを、対応するサーバにマウントさせるコマンドを、前記ネットワークを介して、前記複数のサーバのそれぞれに投入するステップと、
    　を含むことを特徴とするサーバ管理方法。
  7. 　サーバ管理処理をコンピュータに実行させるためのサーバ管理プログラムであって、該プログラムは、前記コンピュータに、
    　ネットワークを構成する複数のサーバの構成情報および識別子情報を取得するサーバ情報取得処理と、
    　前記サーバ情報取得処理により取得された前記複数のサーバの前記構成情報および前記識別子情報に基づいて、前記複数のサーバのそれぞれについて、各サーバをブートするためのスクリプトであって各サーバの前記構成情報および前記識別子情報を含むスクリプトを生成するスクリプト生成処理と、
    　前記複数のサーバのそれぞれにマウントされるべきリモートディスクに、前記スクリプト生成処理により生成された前記スクリプトを書き込むことで、前記リモートディスクを設定するリモートディスク設定処理と、
    　前記リモートディスク設定処理により設定された前記リモートディスクを、対応するサーバにマウントさせるコマンドを、前記ネットワークを介して、前記複数のサーバのそれぞれに投入するコマンド投入処理と、
    　を含む処理を実行させるためのものであることを特徴とするサーバ管理プログラム。

     
PCT/JP2021/031703 2021-08-30 2021-08-30 サーバ管理装置、サーバ管理方法およびプログラム WO2023031993A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US17/800,884 US12124857B2 (en) 2021-08-30 Server management apparatus and server management method
PCT/JP2021/031703 WO2023031993A1 (ja) 2021-08-30 2021-08-30 サーバ管理装置、サーバ管理方法およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/031703 WO2023031993A1 (ja) 2021-08-30 2021-08-30 サーバ管理装置、サーバ管理方法およびプログラム

Publications (1)

Publication Number Publication Date
WO2023031993A1 true WO2023031993A1 (ja) 2023-03-09

Family

ID=85412287

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/031703 WO2023031993A1 (ja) 2021-08-30 2021-08-30 サーバ管理装置、サーバ管理方法およびプログラム

Country Status (1)

Country Link
WO (1) WO2023031993A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009176213A (ja) * 2008-01-28 2009-08-06 Hitachi Software Eng Co Ltd ネットワークブート方式
US20150149758A1 (en) * 2013-11-22 2015-05-28 Bull Sas Method, computer readable medium and device for the configuration or maintenance of a computer system in a cluster

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009176213A (ja) * 2008-01-28 2009-08-06 Hitachi Software Eng Co Ltd ネットワークブート方式
US20150149758A1 (en) * 2013-11-22 2015-05-28 Bull Sas Method, computer readable medium and device for the configuration or maintenance of a computer system in a cluster

Also Published As

Publication number Publication date
US20240192964A1 (en) 2024-06-13

Similar Documents

Publication Publication Date Title
US11405274B2 (en) Managing virtual network functions
US11444765B2 (en) Methods and apparatus to manage credentials in hyper-converged infrastructures
JP7391862B2 (ja) 自動的に配備される情報技術（ｉｔ）システム及び方法
US10044795B2 (en) Methods and apparatus for rack deployments for virtual computing environments
EP3317762B1 (en) Methods and apparatus for software lifecycle management of a virtual computing environment
US7600005B2 (en) Method and apparatus for provisioning heterogeneous operating systems onto heterogeneous hardware systems
KR102524126B1 (ko) 5g 인프라 구축을 위한 분산 클라우드 시스템의 설계 및 설치를 제공하는 장치 및 방법
CN108089913B (zh) 一种超融合系统的虚拟机部署方法
CN105306225B (zh) 一种基于Openstack的物理机远程关机方法
WO2014169870A1 (zh) 虚拟网元自动装载及虚拟机ip地址获取的方法与系统、存储介质
CN103984575A (zh) 一种云计算环境下集群Linux操作系统快速部署方法
CN111198696B (zh) 一种基于裸机服务器的OpenStack大规模部署方法和系统
CN109600439B (zh) 基于微服务的PaaS平台的部署方法及PaaS平台
KR20150108230A (ko) 클러스터 시스템 구축 방법 및 장치
CN107810475B (zh) 用于虚拟计算环境的软件生命周期管理的方法和装置
US10592221B2 (en) Parallel distribution of application services to virtual nodes
US20170034120A1 (en) Network device setting method and information processing device
WO2023031993A1 (ja) サーバ管理装置、サーバ管理方法およびプログラム
WO2023031994A1 (ja) サーバ装置、情報処理方法およびプログラム
KR100439175B1 (ko) 리눅스 기반의 클러스터 시스템의 운영체제 원격 자동설치 방법
US12124857B2 (en) Server management apparatus and server management method
US12056097B1 (en) Deployment of infrastructure management services
US11947987B2 (en) Live node imaging
US20240126903A1 (en) Simulation of edge computing nodes for hci performance testing
US20240256169A1 (en) Dynamic node cluster with storage array

Legal Events

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

Ref document number: 17800884

Country of ref document: US

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

Ref document number: 21955890

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21955890

Country of ref document: EP

Kind code of ref document: A1