Patent Application
20220283833
The present invention relates to an SPP server, a virtual machine connection control system, an SPP server connection control method and a program.
Supported by progress of virtualization technology by NFV (Network Functions Virtualization) and the like, a system has been constructed and operated for each service. In addition, from the form of constructing a system for each service, a form called SFC (Service Function Chaining) of performing utilization as needed like components and improving operability by dividing service functions into reusable module units and operating them on an independent virtual machine (VM: Virtual Machine or container or the like) environment is becoming mainstream (see Non-Patent Literature 1).
A method of connecting and linking a plurality of virtual machines (appropriately abbreviated as VMs hereinafter) is called Inter-VM Communication, and a virtual switch has been standardly utilized for inter-VM connection in a large-scale environment of a data center or the like. However, since it is a method with great communication delay, faster methods have been newly proposed. For example, a method of using special hardware called SR-IOV (Single Root I/O Virtualization) and a method by software using Intel DPDK (Intel Data Plane Development Kit) (referred to as DPDK hereinafter) which is a high speed packet processing library or the like have been proposed (see Non-Patent Literature 2). The DPDK makes it possible to substantially improve performance and throughput of packet processing and secure a lot of time for data plane applications.
The DPDK exclusively uses computer resources of a CPU (Central Processing Unit) and an NIC (Network Interface Card) or the like. Therefore, it is not easily applied to a purpose of flexible switching in module units like the SFC. As an application for mitigating it is an SPP (Soft Patch Panel) (see Non-Patent Literature 3). The SPP omits packet copying in a virtualization layer by preparing a shared memory among the VMs and enabling the individual VMs to directly refer to the same memory space. In addition, for packet exchange between a physical NIC and the shared memory, the DPDK is used and acceleration is achieved. The SPP can change an input destination and an output destination of packets in terms of software by controlling a reference destination of memory change of the individual VMs. In such a manner, the SPP achieves dynamic connection switch between the VMSs and between the VM and the physical NIC.
The SPP controller 20a is operated by a command line 31 from a control terminal device (Control Terminal) 30. The SPP controller 20a performs resource allocation and routing for connecting the VMs on a basis of connection control by the command line 31.
In the resource management in the SPP illustrated by the sign 1100 in
However, for the DPDK and the SPP, performance tuning is difficult, and parameters are set in consideration of hardware configuration of a CPU, a memory and various kinds of components or the like as illustrated by the sign 1000 in
For example, in the DPDK application of the SPP or the like, a core and a memory or the like to be used need to be specified by parameters (on the premise that an application user knows an optimum value beforehand). Actually, tuning needs to be performed while recognizing a layout of the core and the memory (hyperthread utilization propriety, CPU architecture and layout, whether or not to extend over a bus, the number of channels and the number of clocks or the like for the memory) and adjusting the parameters. In this case, since examinations have to be performed one by one by a command or the like, there is the problem that it is extremely time-consuming.
The present invention is implemented in consideration of such a background, and an object of the present invention is to reduce labor and time of a performance verification in an SPP and improve reproducibility of verification testing.
In order to solve the problem described above, the present invention is an SPP server including: an SPP (Soft Patch Panel) configured to control a reference destination in a memory space of a plurality of virtual machines; a scenario management unit configured to acquire a scenario definition defining typical performance verification procedures as scenarios by a series of scripts; a scenario execution unit configured to execute a command using the scenario definition managed by the scenario management unit; an information collection unit configured to receive an instruction from the scenario execution unit and issue a command for collecting hardware information of a setting target set by the SPP; and a measurement data acquisition unit configured to acquire measurement data of a measurement item when verifying performance using the scenario definition managed by the scenario management unit.
According to the present invention, labor and time of a performance verification in an SPP can be reduced, and reproducibility of verification testing can be improved.
Hereinafter, a virtual machine connection control system or the like in an embodiment (referred to as “present embodiment” hereinafter) of the present invention will be explained with reference to the drawings.
As illustrated in
<SPP Server>
The SPP server 100 includes a scenario management unit 110, a scenario execution unit 120, a server information collection unit 130 (information collection unit), a profile unit 140 (measurement data acquisition unit), a capture unit 150, and an SPP 160. The scenario management unit 110 acquires a scenario definition defining typical performance verification procedures as scenarios by a series of scripts.
Then, the scenario management unit 110 manages a scenario definition 50 (see
The scenario execution unit 120 executes a command using the scenario definition 50 managed by the scenario management unit 110.
When an item is executed from the operation menu, the scenario execution unit 120 automatically executes processing based on the scenario according to an XML definition for which the scenario definition 50 is managed as the XML. The scenario execution unit 120 analyzes the XML and executes each command.
The server information collection unit 130 receives an instruction from the scenario execution unit 120, and issues a command for collecting hardware information of a setting target set by the SPP 160. For example, for information collection, a command for performing sampling is issued.
As described above, in a DPDK application of the SPP or the like, tuning needs to be performed while recognizing a layout of a core and a memory to be used (hyperthread utilization propriety, CPU architecture and layout, whether or not to extend over a bus, the number of channels and the number of clocks or the like for the memory) and adjusting parameters. The server information collection unit 130 can reduce each examination by the command as the entire system by combining the command issuance with the scenario definition 50.
The profile unit 140 acquires measurement data of a measurement item when verifying performance using the scenario definition 50 managed by the scenario management unit 110. The profile unit 140 acquires data to be measured (time-sequential data of throughput and delay response data corresponding to the time-sequential data) other than a log or the like.
The capture unit 150 captures the command issued by the user terminal, the log and an operation screen by moving images, on the basis of a capture procedure described by the scenario definition 50.
The capture unit 150 acquires and stores the command manually issued by a user and the log via an API (Application Program Interface) (see a sign=in
Note that detailed data such as the measurement data is acquired by the profile unit 140, and a situation that the user is roughly viewing and the log (event log) which is not the data are captured by the capture unit 150.
The SPP 160 controls the reference destination in the memory space of the plurality of virtual machines. Then, the SPP 160 manages resources (NIC, ring) of the SPP including the virtual machines, a port object and a VM object.
<GUI Terminal>
The GUI terminal 200 cooperates with the SPP server 100 and performs resource allocation and routing for connecting the virtual machines by a GUI operation. The GUI terminal 200 includes a GUI controller 210, an HTTP (Hyper Text Transfer Protocol) server function unit 220, and a browser 230. The GUI controller 210 presents information on a screen by a graphic element, and controls the GUI operation of instructing a position and a movement on the screen by a pointing device.
The HTTP server function unit 220 provides the information stored in the GUI terminal 200 in response to an HTTP request transmitted from a client through the Internet or the like.
The browser 230 displays the information of a webpage on the Internet on the screen
<Load Tester>
The load tester 300 executes a performance verification by the SPP server. The load tester 300 uses pktgen (R) as a traffic generator 310. The pktgen is a packet generator which utilizes the DPDK, and can transmit packets in a plurality of patterns.
Hereinafter, an operation of the SPP server 100 of the virtual machine connection control system 1 configured as described above will be explained.
<Scenario Definition Preparation>
The scenario is defined by the user with the typical verification procedures as a series of scripts (the scenario defined by the user is referred to as the scenario definition 50). The scenario definition 50 defines automation items for executing a typical verification (performance measurement, testing). By using the scenario definition 50, loads of work which is complicated and needs two or more times of testing such as performance tuning are reduced (to be described later).
As illustrated in
The test A and the test B are test scenarios indicating the verification procedures of the work which is complicated and needs two or more times of testing such as performance tuning. The verification procedures are made time-sequential so as to advance to the test B after the test A.
In step S11, the user is made to set the test A of registering the test scenario according to guidance by the user terminal 40 (see
In step S12, the user terminal 40 (see
In hardware information acquisition in step S12 described above, the user terminal 40 further describes the scenario for acquiring CPU information in step S15 and the scenario for acquiring memory information in step S16.
As illustrated in
In order to set a network route of the scenarios in
Returning to
In step S18, the user terminal 40 describes measurement for the test A. In the measurement in step S18, the scenario for acquiring server information in step S19, the scenario for setting the parameters in step S20 and the scenario for preserving a measurement value in step S21 are described further. That ends description of the test scenarios for the test A, and then the description of the test scenarios for the test B is started.
While step numbers are attached to the scenario definition 50 illustrated in
The scenario management unit 110 (see
A part indicated by a sign (a) in
A part indicated by a sign b in
A part indicated by a sign c in
As illustrated in
The scenario management unit 110 manages the test scenario prepared by the user terminal 40 as the XML. The scenario execution unit 120 preserves the test scenario described by the XML (step S102).
The user terminal 40 transmits test start to the scenario execution unit 120 by executing the item from the operation menu (step S103).
The scenario execution unit 120 automatically executes processing based on the scenario according to the XML definition, on a basis of the preserved scenario. That is, the scenario execution unit 120 executes calling to individual units corresponding to the instruction of the scenario. Here, the scenario execution unit 120 starts a test and instructs capture start to the capture unit 150 (step S104).
The capture unit 150 starts capture of capturing the command manually issued by the user, the log and the operation screen by moving images (step S105). The capture unit 150 acquires and stores the command manually issued by the user and the log via the API (see the sign=in
Note that the capture is continued until the series of tests ends (step S124).
The user terminal 40 transmits test (the test A (see
The scenario execution unit 120 starts the processing of the test A based on the scenario according to the XML definition on the basis of the preserved scenario definition 50, and transmits processing start of the test A to the server information collection unit 130 (step S107).
The server information collection unit 130 receives the instruction from the scenario execution unit 120, issues the command for collecting the hardware information in the test A, and acquires the hardware information (server information) of the test A (step S108). Note that the hardware information (server information) acquisition is continued until the series of tests ends (step S116).
Here, the server information collection unit 130 combines the command issuance in the test A with the scenario definition 50 provided from the scenario execution unit 120 and thus each examination by the command is substantially reduced.
The scenario execution unit 120 starts the measurement in the test A, and notifies the profile unit 140 (step S109).
The profile unit 140 acquires the data to be measured (for example, the time-sequential data of the throughput and the delay response data corresponding to the time-sequential data, regarding the test A) as a profile of the test A (step S110).
When the measurement of the test A ends, the scenario execution unit 120 notifies the profile unit 140 of measurement end of the test A (step S111), and transmits the end of the test A to the user terminal 40 (step S112).
The profile unit 140 stops the acquisition of the data to be measured (profile) (step S113).
The user terminal 40 is notified of the end of the test A, and transmits next test (the test B (see
The scenario execution unit 120 starts the processing of the test B based on the scenario according to the XML definition on the basis of the preserved scenario, and transmits the processing start of the test B to the server information collection unit 130 (step S115).
The server information collection unit 130 receives the instruction from the scenario execution unit 120, issues the command for collecting the hardware information in the test B, and acquires the hardware information (server information) of the test B (step S116). Here, the server information collection unit 130 combines the command issuance in the test B with the scenario definition 50 provided from the scenario execution unit 120 and thus each examination by the command is substantially reduced.
The scenario execution unit 120 starts the measurement in the test B, and notifies the profile unit 140 (step S117).
The profile unit 140 acquires the data to be measured (for example, the time-sequential data of the throughput and the delay response data corresponding to the time-sequential data, regarding the test B) as the profile of the test B (step S118).
When the measurement of the test B ends, the scenario execution unit 120 notifies the profile unit 140 of the measurement end of the test B (step S119), and transmits the end of the test B to the user terminal 40 (step S120).
The profile unit 140 stops the acquisition of the data to be measured (profile) (step S121).
The user terminal 40 is notified of the end of a series of the test B, and transmits the next test end to the scenario execution unit 120 by executing the item from the operation menu (step S122).
The scenario execution unit 120 executes test end processing, and notifies the capture unit 150 (step S123). The capture unit 150 ends the capture (step S124).
As illustrated in
The SPP server 100 performs dynamic network setting of the SPP, tests and the reproduction through the operation screen.
The configuration view 113 illustrated in
As illustrated in
For example, the route indicated by a sign d in
In such a manner, hardware information acquisition, parameter setting and routing or the like can be automated. Automatable procedures are systemized, and reproducibility is improved by logging and capture for parts to be manually performed.
[Hardware Configuration]
The SPP server 100 relating to the present embodiment is implemented by a computer 900 configured as illustrated in
The computer 900 includes a CPU 910, a RAM 920, a ROM 930, an HDD 940, a communication interface (I/F) 950, an input/output interface (I/F) 960, and a medium interface (I/F) 970.
The CPU 910 is operated on the basis of a program stored in the ROM 930 or the HDD 940, and controls the individual units. The ROM 930 stores a boot program executed by the CPU 910 at activation of the computer 900 and a program which depends on hardware of the computer 900 or the like.
The HDD 940 stores the program executed by the CPU 910 and data used by the program or the like. The HDD 940 may be a DB used by the server information collection unit 130 (see
The CPU 910 controls an output device such as a display and a printer and an input device such as a keyboard and a mouse through the input/output interface 960. The CPU 910 acquires data from the input device through the input/output interface 960. In addition, the CPU 910 outputs the generated data to the output device through the input/output interface 960.
The medium interface 970 reads the program or the data stored in a recording medium 980, and provides the CPU 910 with the program or the data through the RAM 920. The CPU 910 loads the program from the recording medium 980 onto the RAM 920 through the medium interface 970, and executes the loaded program. The recording medium 980 is, for example, an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phasechangerewritable Disk), a magneto-optical recording medium such as an MO (Magneto Optical disk), a tape medium, a magnetic recording medium or a semiconductor memory.
For example, in a case where the computer 900 functions as the SPP server 100 relating to the present embodiment, the CPU 910 of the computer 900 implements the functions of the individual units of the SPP server 100 by executing the program loaded onto the RAM 920. In addition, in the HDD 940, the data inside the individual units of the SPP server 100 is stored. The CPU 910 of the computer 900 reads and executes the programs from the recording medium 980, but may acquire the programs from another device through the communication network 80 as another example.
[Effect]
As described above, the SPP server 100 (see
In such a manner, labor and time of the performance verification in the SPP can be reduced, and the reproducibility of verification testing can be improved.
(1) For example, while there are many tuning items such as the parameter setting regarding hardware and the resource allocation to processes in the verification of the SPP, by preparing the scenario definition 50 as an automation task, the labor can be greatly reduced.
(2) In addition, regarding verification work manually performed by the user, by preparing the scenario definition 50, automation is made possible, the time of the verification can be reduced, and the reproducibility regarding the verification testing can be improved.
That is, in order to perform performance tuning in consideration of the hardware, appropriate parameter needs to be set corresponding to difference of a hardware architecture, however, since the confirmation method and setting method are detailed, a lot of know-how is required to obtain an optimum setting parameter, and work time is needed.
The SPP server 100 unitarily manages the hardware information, a test procedure and a test result regarding the SPP. The SPP server 100 automatically performs setting and the test, and graphically presents the result to the user. Thus, the SPP server 100 can improve test reproducibility and reduce a work cost needed for the performance tuning.
(3) Further, the scenario definition 50 can be applied even when the hardware is changed, and the labor in the case of performing the similar verification in the plurality of machines can be reduced.
(4) The information collection unit (server information collection unit 130) can automatically acquire the required hardware information in cooperation with the scenario. The server information collection unit 130 can reduce each examination by the command as the entire system by combining the command issuance with the scenario definition 50.
(5) The measurement data acquisition unit (profile unit 140) can automatically acquire the data to be measured (the time-sequential data of the throughput and the delay response data corresponding to the time-sequential data) in cooperation with the scenario.
In the SPP server 100, the scenario definition 50 describes a setting procedure of acquiring the hardware information, parameter information and route information, the capture procedure of acquiring the command issued by the user terminal and the log thereof, and a measurement procedure of acquiring the measurement data of the measurement item when verifying the performance, for each test for which the performance verification procedures are made time-sequential.
In such a manner, the SPP server 100 can unitarily manage the hardware information, the test procedure and the test result using the scenario definition 50, and automatically perform the test.
The SPP server 100 includes the capture unit 150 which captures the command manually issued by the user, the log and the operation screen by moving images, on the basis of the capture procedure described by the scenario definition 50.
In such a manner, the capture unit 150 can recognize the situation that the user is viewing by capturing the command manually issued by the user, the log and the operation screen by the moving images. In addition, the measurement item and log collection defined in the scenario can be automatically executed and a verification result can be displayed.
In the SPP server 100, the capture unit 150 acquires and stores the command manually issued by the user and the log via the API provided in the SPP controller.
In such a manner, the capture unit 150 can acquire the command manually issued by the user and the log via the API provided in the SPP controller.
Of the individual processing explained in the embodiment described above, all or part of the processing explained as the one to be automatically performed may be manually performed, or all or part of the processing explained as the one to be manually performed may be automatically performed by a known method. In addition, information including processing procedures, control procedures, specific names, various kinds of data and parameters illustrated in the above-described document and in the drawings can be arbitrarily changed unless otherwise specified.
In addition, individual components of the individual devices illustrated are functionally conceptual, and do not always need to be physically configured as illustrated. That is, specific form of distribution/integration of the individual devices is not limited to the illustration, and the all or part may be functionally or physically distributed/integrated in an arbitrary unit and configured according to various kinds of loads and using situations or the like.
Further, part or all of the individual configurations, functions, processing units and processing means or the like described above may be implemented by the hardware by design in an integrated circuit for example. In addition, the individual configurations and functions or the like described above may be implemented by software for a processor to interpret and execute the programs which implement the respective functions. The information of the programs, tables and files or the like which implements the individual functions can be held in a recording device such as a memory, a hard disk or an SSD (Solid State Drive), or a recording medium such as an IC (Integrated Circuit) card, an SD (Secure Digital) card or an optical disk.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/JP2019/027130 | 7/9/2019 | WO |
