Nothing Special   »   [go: up one dir, main page]

WO2021111516A1 - 通信管理装置及び通信管理方法 - Google Patents

通信管理装置及び通信管理方法 Download PDF

Info

Publication number
WO2021111516A1
WO2021111516A1 PCT/JP2019/047185 JP2019047185W WO2021111516A1 WO 2021111516 A1 WO2021111516 A1 WO 2021111516A1 JP 2019047185 W JP2019047185 W JP 2019047185W WO 2021111516 A1 WO2021111516 A1 WO 2021111516A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication
computer
unit
server
cluster
Prior art date
Application number
PCT/JP2019/047185
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 JP2021562226A priority Critical patent/JP7359222B2/ja
Priority to PCT/JP2019/047185 priority patent/WO2021111516A1/ja
Priority to US17/780,865 priority patent/US11695644B2/en
Publication of WO2021111516A1 publication Critical patent/WO2021111516A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/147—Network analysis or design for predicting network behaviour
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5006—Creating or negotiating SLA contracts, guarantees or penalties
    • 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/06—Generation of reports
    • H04L43/062—Generation of reports related to network traffic
    • 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/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2483—Traffic characterised by specific attributes, e.g. priority or QoS involving identification of individual flows
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5019—Workload prediction
    • 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/16—Threshold monitoring

Definitions

  • the present invention relates to a communication management device and a communication management method.
  • Non-Patent Document 1 a plurality of priority classes are pods, which are the smallest units for managing containers in kubernetes. It is disclosed that communication is possible without causing a queuing delay by allocating bandwidth in order from the pod of the high priority class.
  • Non-Patent Document 1 In a service that requires low latency in End-to-End communication, communication with end-user terminals outside the cluster and communication between microservices that are indispensable for application processing should also have low latency, but the technology of Non-Patent Document 1 Then, there is a problem that a delay occurs when multiplex or burst of high priority communication occurs.
  • the present invention has been made in view of the above points, and an object of the present invention is to suppress the occurrence of communication abnormalities in a cluster.
  • the communication management device obtains the communication amount of the communication performed by the communication units operating one or more in each of the plurality of computers constituting the cluster, and the communication amount in the future for the communication.
  • a predictive unit for predicting a specific unit that calculates the total of the future communication volume of the communication unit operating on the computer for each computer, and identifies a first computer whose total exceeds a threshold value, and the first.
  • the communication unit operating in one computer has a movement control unit that controls movement to a second computer.
  • FIG. 1 is a diagram for explaining an outline of an embodiment of the present invention.
  • FIG. 1 shows a state in which one or more pods are operating on each of the servers that are the four physical hosts (physical computers) that make up the cluster.
  • the solid double-headed arrow indicates communication with the outside of the cluster (outside the cluster), and the broken double-headed arrow indicates inter-microservice communication (communication between pods in the cluster).
  • a pod is a minimum unit that manages a set of containers (processes).
  • the communication management device 10 which is a computer that manages the cluster executes the procedures (1), (2), and (3). The meanings of these are as follows.
  • the communication management device 10 dynamically sets the QoS of the pod communication according to the communication quality request on the service side.
  • FIG. 2 is a diagram showing a hardware configuration example of the communication management device 10 according to the embodiment of the present invention.
  • the communication management device 10 of FIG. 2 has a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, a network interface 105, and the like, which are connected to each other by a bus B, respectively.
  • the program that realizes the processing in the communication management device 10 is provided by a recording medium 101 such as a CD-ROM.
  • a recording medium 101 such as a CD-ROM.
  • the program is installed in the auxiliary storage device 102 from the recording medium 101 via the drive device 100.
  • the program does not necessarily have to be installed from the recording medium 101, and may be downloaded from another computer via the network.
  • the auxiliary storage device 102 stores the installed program and also stores necessary files, data, and the like.
  • the memory device 103 reads and stores the program from the auxiliary storage device 102 when the program is instructed to start.
  • the CPU 104 executes the function related to the communication management device 10 according to the program stored in the memory device 103.
  • the network interface 105 is used as an interface for connecting to a network.
  • FIG. 3 is a flowchart for explaining an example of the processing procedure executed by the communication management device 10.
  • one or more programs installed in the communication management device 10 cause the communication management device 10 to execute each step.
  • step S10 the communication management device 10 acquires the communication volume for each destination of each pod running on each server in the cluster.
  • “by destination” refers to whether it is outside the cluster or inside the cluster, and for communication within the cluster, the amount of communication is distinguished for each communication partner. On the other hand, regarding the communication volume of communication outside the cluster, the communication partner is not distinguished. Therefore, the amount of communication outside the cluster is at most one for each pod.
  • the communication management device 10 predicts the future communication volume (for example, after N minutes) of each pod (calculates the predicted value of the communication volume) (S20).
  • the communication management device 10 calculates the predicted value of the communication amount of each server based on the predicted value of the communication amount of each pod, and the bandwidth may be exceeded based on the predicted value of the communication amount of each server. Identify a server ⁇ with a relatively high value (S30).
  • the communication management device 10 determines the pod to be moved from the pods operating on the server ⁇ , determines the destination server of the pod to be moved, and moves the pod to the server (S40). ).
  • the pod to be moved and the destination are determined so that the communication volume between the servers is distributed as evenly as possible in anticipation of future changes in the communication volume. As a result, the amount of communication can be distributed among the servers.
  • the communication management device 10 dynamically sets the QoS control for the newly scheduled (moved) pod (S50). That is, after the pod schedule (after moving), QoS control is performed particularly for the pod of the priority service whose communication quality is desired to be guaranteed.
  • FIG. 4 is a flowchart for explaining an example of the processing procedure of the acquisition processing of the communication volume for each destination of each pod. Further, FIG. 5 is a diagram for explaining the acquisition process of the communication amount for each destination of each pod.
  • the communication management device 10 acquires a list of pods for which the communication amount is to be acquired (hereinafter, referred to as "pod list").
  • the pod list is, for example, list information of some pods (that is, some pods having a relatively high priority regarding communication) for which communication volume is to be managed, and is created in advance, for example. However, if you want to manage the traffic of all pods, the pod list may be list information of all pods.
  • the identification information of each pod is, for example, an IP address, a service name, or the like.
  • each pod included in the pod list is referred to as a "target pod”.
  • the communication management device 10 receives a communication amount V4 (hereinafter referred to as "communication c4") for each communication between all pods (hereinafter referred to as "communication c4") from the telemetry information of the function of relaying the communication between pods (example: environment proxy). 5) is acquired (S12).
  • all pods mean all pods including pods other than the target pod.
  • a pod that is an end point of the communication c4 is specified for each communication c4.
  • the target pod is the end point, and the communication is not the communication in the same server (that is, the communication between the target pod and the pod on another server (hereinafter, "communication c2"). ”)), And for each target pod, the communication volume V2 (see FIG. 5) of each communication c2 related to the target pod (the target pod is the end point) is acquired (S13).
  • the communication management device 10 acquires the communication volume V3 (see FIG. 5) of the transmission / reception communication (hereinafter referred to as “communication c3”) of all pods from the management information of the container integration function (for example, docker) (S14). ..
  • the communication management device 10 subtracts the communication amount V4 from the communication amount V3 of the target pod for each target pod, so that the communication amount V1 of the communication between the target pod and the outside of the cluster (hereinafter referred to as “communication c1”). (S15).
  • one communication amount V1 and one or more communication amount V2 for each communication c2 are acquired for each target pod.
  • FIG. 6 is a diagram showing an example of communication of each pod.
  • FIG. 6 shows an example of communication c1 and c2 acquired in step S10.
  • the communication management device 10 makes a prediction in step S20 by different methods for the communication c1 and the communication c2.
  • FIG. 7 is a diagram for explaining the future communication volume prediction processing of each pod.
  • target pod p for each of the communication c1 and each communication c2 relating to a certain target pod (hereinafter referred to as “target pod p”), the current communication volume is shown on the left side, and the future (N minutes later) on the right side. ) Is shown. That is, the process described below is executed for each target pod.
  • the communication management device 10 analyzes the communication c1 of the target pod p in a time series ("Kawahara, AI utilization for network operations, 2018, https://www.jstage.jst.go.jp/article/bplus/”. 12/1 / 12_29 / _article / -char / ja / ”) and RNN (“Ida, Advanced Learning Technology for Deep Learning, 2018, https://www.ntt.co.jp/journal/1806/ Files / JN20180630.pdf ”) and other known technologies are used to predict future traffic (S21).
  • the communication management device 10 learns a prediction model for each communication c2 of the target pod p in consideration of the correlation with the prediction result of the communication amount V1, the policy information of the communication between pods, the characteristics of the communication protocol, and the prediction. Predict future traffic based on the model.
  • the communication management device 10 learns the correlation between the communication amount of the communication c1 and the sum of the components of the vector v2 of the communication amount of each communication c2 based on the past data (past communication history) (S22).
  • each component of the vector v2 is the communication amount of each communication c2 for each communication partner.
  • the communication c2 is a communication that transfers the processing of the communication c1 received by the target pod p to another pod according to the value of the request header and the load balancing weight, and since grpc is used as the protocol, the communication amount of each flow. Is fixed. Therefore, it is considered that there is a correlation between the communication volume of communication c1 and the total communication volume of communication c2.
  • the communication management device 10 also learns the correlation of each component of the vector v2 for the target pod p based on the past data (S23).
  • the communication management device 10 applies the predicted value of the communication c1 to the correlation between the learned communication amount of the communication c1 and the sum of the components of the vector v2 of the communication amount of each communication c2 for the target pod p. Then, the predicted value of the sum is calculated (S24).
  • the communication management device 10 applies the predicted value of the sum to the correlation between the sum and each component of the learned vector v2 for the pod of interest, and predicts the future traffic of the communication c2. Is calculated (S25).
  • the value of each component of the vector v2 is linearly proportional to the communication amount of the communication c2.
  • FIG. 8 is a flowchart for explaining an example of the processing procedure of the specific processing of the server ⁇ , which is likely to exceed the bandwidth.
  • step S31 the communication management device 10 calculates the maximum bandwidth of each server based on the link bandwidth connected to each server, the buffer value, and the like. Subsequently, the communication management device 10 determines (calculates) a threshold value for each server based on the maximum bandwidth and the allowable usage rate (S32).
  • the allowable usage rate is a preset value.
  • FIG. 9 is a diagram showing a calculation example of the threshold value.
  • FIG. 9 shows an example of a server having a link bandwidth of 10 Gbps, a buffer of 0.5 Gbps, and an allowable usage rate of 95%.
  • the threshold of the server is determined as 10 Gbps, as shown in FIG.
  • the threshold value may be fixedly set in each server.
  • the communication management device 10 compares the sum of the predicted values of the communications c1 and c2 of each pod belonging to the server with the threshold value of the server for each server, and the server ⁇ in which the total becomes larger than the threshold value. Is specified (S31). At this time, a plurality of servers can be specified as the server ⁇ .
  • the permissible usage rate may be set in consideration of such circumstances. That is, the allowable usage rate may be set to the ratio of the allowable communication amount to the communication of the target pod to the total communication amount of the server.
  • FIG. 10 is a diagram showing a specific example of the server ⁇ .
  • the server in the middle is specified as the server ⁇ .
  • FIG. 11 is a flowchart for explaining an example of the processing procedure of the determination process of the pod to be moved and the moving destination.
  • step S41 the communication management device 10 calculates the average T'of the predicted communication volume of each server.
  • the communication management device 10 selects the pod i to be moved so that the predicted communication volume of the server ⁇ is closest to T'by solving the following optimization problem (S42).
  • T alpha, traffic server alpha, t i is the amount of communication pod i.
  • the communication management device 10 searches for the destination server ⁇ so that the predicted communication volume of the destination server ⁇ is closest to T'by solving the following optimization problem (S43).
  • s ij is the sum of the communication volumes of the pod i and the (all) pods on the server j.
  • the pod i to be moved and the server ⁇ to be moved are determined so that the amount of communication between the servers is distributed as evenly as possible.
  • the communication management device 10 controls the movement of the pod i to the server ⁇ (S46). That is, the communication management device 10 controls to delete the pod i from the server ⁇ and newly generate the pod i on the server ⁇ . As a result, the pod i moves to the server ⁇ .
  • the communication management device 10 scales out the pod i into a plurality of pods (divides the pod i into a plurality of pods) (S45), and steps S42 and subsequent steps are performed. repeat.
  • FIG. 12 is a diagram showing an example of determining a pod to be moved and a destination to be moved.
  • FIG. 12 (1) shows an example in which the server on the left side has a high possibility of exceeding the bandwidth (exceeding the threshold value).
  • the pod is moved as shown in (2), it is possible to minimize the difference in the predicted communication volume of each server while eliminating the band excess. Therefore, in this case, the left pod of the left server is selected as the move target, and the right server is selected as the move destination.
  • the pod i to be moved and the server ⁇ to be moved are determined based on the predicted communication volume.
  • the pod i to be moved and the server ⁇ to be moved are determined based on the distribution of the predicted communication volume. It may be decided.
  • the predicted communication volume described above may be replaced by the variance of the predicted communication volume.
  • FIG. 13 is a flowchart for explaining an example of the processing procedure of QoS control to the pod after the movement.
  • FIG. 14 is a diagram for explaining QoS control to the pod after movement.
  • a reference numeral corresponding to the step number of FIG. 13 is assigned to the corresponding portion.
  • step S51 the communication management device 10 refers to the list in which the QoS control information of each pod is recorded, and acquires the QoS setting information for the moved pod i.
  • the communication management device 10 uses the technology of Non-Patent Document 1 and the tk command to input a setting for preferentially allocating a band to the moved pod i (S52). For example, as shown in FIG. 14, the communication management device 10 deletes the setting related to the pod i from the server ⁇ , sets the tk command for the server ⁇ , and the like.
  • FIG. 15 is a diagram showing an example of a specific system configuration to which the embodiment of the present invention is applied.
  • a plurality of servers which are examples of physical hosts, communicate via an IP network (for example, DC fabric, LAN, etc.).
  • IP network for example, DC fabric, LAN, etc.
  • a cluster NW30 which is a virtual network on which workloads for each container (eg, Kubertes pods and containers) run, is constructed for each service provider.
  • a plurality of clusters NW30 may exist on a single server.
  • the cluster NW management system 20 acquires network information such as communication volume from the workload on the cluster NW30 and the servers belonging to the cluster NW30, and sets the workload position control (scheduling) and QoS control based on the acquired information.
  • One or more computers to do That is, the cluster NW management system 20 corresponds to the communication management device 10 described above. Also, the workload corresponds to the above pods.
  • the cluster NW management system 20 may be located inside a server belonging to the cluster NW30. Further, when a plurality of cluster NW30s exist on a single server, the plurality of clusters NW management systems 20 may cooperate with each other and exchange information necessary for control.
  • FIG. 16 is a diagram showing a configuration example of the cluster NW management system 20.
  • the cluster NW management system 20 includes a traffic amount prediction device 21, a schedule device 22, a QoS control device 23, an interface device 24, a management DB 25, and the like.
  • Each device may be software or hardware (computer). If each device is software, each device may be implemented using a common computer. In any case, the function of each device is realized by the process of causing the computer to execute one or more programs installed in the computer that realizes each device.
  • the interface device 24 inputs the information of the command input from the user to the management DB 25, directly communicates with the server, the workload, and other internal functions which are the components of the cluster NW30, and exchanges telemetry, control information, and the like. ..
  • the management DB 25 holds the configuration (number of workloads, etc.) to be taken by the cluster based on the command input by the user.
  • the communication volume prediction device 21 acquires the traffic volume of the workload and the server from the interface device 24 and predicts the future communication volume.
  • the communication amount prediction device 21 further calculates the communication amount for each server and identifies the server ⁇ having a high possibility of exceeding the bandwidth.
  • the schedule device 22 determines the workload to be moved and the destination server from the server ⁇ .
  • the QoS control device 23 dynamically sets the QoS for the moved workload.
  • each server includes a workload management unit 41.
  • the workload management unit 41 receives control communication from the interface device 24, starts up and erases the workload, and guarantees that the workload operates normally in the server.
  • FIG. 17 is a diagram showing a configuration example of the communication volume prediction device 21.
  • the communication amount prediction device 21 includes a communication amount prediction unit 211, a band excess determination unit 212, a learning data DB 213, a prediction parameter management table 214, a threshold information table 215, and the like.
  • the learning data DB 213 stores the past communication volume of the workload and the server as learning data.
  • the prediction parameter management table 214 holds a list of workloads (target pods mentioned above) for which communication traffic is to be acquired.
  • the prediction parameter management table 214 also holds an algorithm used for learning the prediction model, setting information as prior information, and parameters after learning.
  • the communication amount prediction unit 211 acquires the communication amount of the workload and the server via the interface device 24, and predicts the future communication amount from the learning data accumulated in the learning data DB 213.
  • the traffic amount prediction unit 211 also updates the parameters of the prediction model and stores the update result in the prediction parameter management table 214.
  • the traffic prediction unit 211 further acquires the workload position information (which workload is located on which server) from the interface device 24, and calculates the traffic of each server.
  • the threshold information table 215 stores information used for determining the threshold value of the server bandwidth.
  • the bandwidth excess determination unit 212 determines the threshold value from the bandwidth and parameters of each server. The bandwidth excess determination unit 212 also compares the threshold value with the communication volume of each server to identify the server ⁇ having a high possibility of bandwidth excess.
  • FIG. 18 is a diagram showing a configuration example of the prediction parameter management table 214.
  • the prediction parameter management table 214 contains a list of workloads for which traffic is desired to be acquired, an algorithm used for predicting communication with the outside of the cluster, and information on the algorithm used for predicting communication with the workload inside the cluster. And its learning parameters are accumulated. In order to predict the traffic volume for each workload, individual learning parameters are held for each workload. The learning parameters are learned according to the newly flowing traffic data, and the values in the table are also updated.
  • the prediction parameter management table 214 also retains this information. The information is used to train the model.
  • FIG. 19 is a diagram showing a configuration example of the threshold information table 215.
  • the threshold information table 215 holds information for calculating the threshold value used by the band excess determination unit 212 when selecting the server ⁇ having a high possibility of band excess. For example, server bandwidth and socket buffer values are held for each server.
  • the threshold information table 215 also holds the permissible usage rate, which is information on the usage rate of the available band, with respect to the maximum band.
  • FIG. 20 is a diagram showing a configuration example of the schedule device 22.
  • the schedule device 22 includes a schedule calculation unit 221 and a cluster management table 222 and the like.
  • the schedule calculation unit 221 acquires the information of the bandwidth excess server and the communication amount information of the workload operating inside the server from the communication amount prediction device 21.
  • the schedule calculation unit 221 also refers to the cluster management table 222 and determines the workload to be moved from the out-of-band bandwidth server.
  • the schedule calculation unit 221 also refers to the cluster management table 222, and determines the destination server in consideration of the workload information running on each server and the metric information of the server.
  • the schedule calculation unit 221 further controls the movement of the workload. Specifically, the schedule calculation unit 221 sends an update request to the interface device 24 and at the same time sends a notification of the arrangement change to the QoS control device 23 in order to change the information of the workload to be moved and the server of the move destination.
  • the cluster management table 222 acquires and holds the ID of the workload running on each server and the metric (CPU, memory, storage amount, communication amount) of each server in real time via the interface device 24.
  • FIG. 21 is a diagram showing a configuration example of the cluster management table 222.
  • the cluster management table 222 holds the ID of the workload running on each server and the metric information indicating the current performance of each server.
  • the information in the table is updated based on the update request from the interface device 24 at the timing when the change occurs in the cluster NW30.
  • the schedule device 22 particularly refers to the metric information and determines the optimum destination server in terms of not only the communication volume but also the CPU, memory, and storage.
  • FIG. 22 is a diagram showing a configuration example of the QoS control device 23.
  • the QoS control device 23 includes a command generation unit 231, a past command DB 232, a QoS setting information table 233, and the like.
  • the command generation unit 231 When the command generation unit 231 receives the notification of the workload arrangement change from the schedule device 22, it inquires of the past command DB232, acquires the QoS settings set in the past for the workload to be moved, and via the interface device 24. Request to update the QoS settings. The command generation unit 231 also acquires priority information of the workload to be moved from the QoS setting information table 233, generates a new QoS command based on the acquired information, and updates the QoS settings via the interface device 24. Make a request.
  • FIG. 23 is a diagram showing a configuration example of the QoS setting information table 233.
  • the QoS setting information table 233 holds the QoS setting information (Guaranteed, Best Effort) according to the priority of each workload. This information is determined by the system administrator when the service starts. Since identifiers such as workload IDs, names, and IP addresses are updated at any time, service names and QoS setting information are linked in the QoS setting information table 233.
  • FIG. 24 is a sequence diagram for explaining an example of a processing procedure related to acquisition and prediction of communication volume information.
  • FIG. 24 shows a processing procedure executed in the cluster NW management system 20 corresponding to steps S10 to S30 of FIG.
  • Each workload transmits communication amount information (information indicating the current communication amount) to the communication amount prediction device 21 via the interface device 24 at predetermined time intervals (S101, S102).
  • each server transmits workload management information (information on the server on which the workload operates, etc.) to the traffic forecasting device 21 via the interface device 24 at predetermined time intervals (S103, S104).
  • the communication amount prediction unit 211 of the communication amount prediction device 21 records the information received via the interface device 24 in the learning data DB 213.
  • the traffic prediction unit 211 learns the past traffic data recorded in the training data DB 213 (S105), and based on the trained model, the future (for example, after N minutes) of each workload. Predict the amount of communication (S106). Subsequently, the communication volume prediction unit 211 calculates the predicted communication volume of each server by totaling the predicted communication volume of the workload for each server (S107). Subsequently, the band excess determination unit 212 of the traffic amount prediction device 21 identifies the server ⁇ having a high possibility of band excess based on the calculation result of each server (S108). Subsequently, the bandwidth excess determination unit 212 transmits the information of the specified server ⁇ and the predicted communication amount of each workload to the schedule device 22 (S109).
  • FIG. 25 is a sequence diagram for explaining an example of the processing procedure related to the execution of scheduling.
  • FIG. 25 shows a processing procedure executed in the cluster NW management system 20 corresponding to steps S40 and S50 of FIG.
  • the schedule calculation unit 221 of the schedule device 22 selects the workload to be moved from the workloads running inside the server ⁇ notified from the traffic forecasting device 21, and determines the server to which the workload is moved. (S201). Subsequently, the schedule calculation unit 221 transmits the selected or determined information to the workload management units 41 of the migration destination server and the migration source server, and the QoS control device 23 via the interface device 24 (S202, S210). , S220).
  • the workload management unit 41 which is an agent of each server, deletes and creates a new workload (move the workload) according to the instruction of the schedule device 22 (based on the information transmitted from the schedule calculation unit 221) (S211). ).
  • the command generation unit 231 of the QoS control device 23 generates a QoS control command to be applied to the moved workload (S221), and instructs the destination server to perform QoS control based on the command (S221). ).
  • the communication of the server can be set to a predetermined band. It is possible to prevent excess and reduce packet loss and delay. As a result, the occurrence of communication abnormalities in the cluster can be suppressed.
  • the pod or workload is an example of the communication unit.
  • a server is an example of a plurality of computers forming a cluster.
  • the communication volume prediction unit 211 is an example of an acquisition unit and a prediction unit.
  • the band excess determination unit 212 is an example of a specific unit.
  • the schedule calculation unit 221 is an example of a movement control unit.
  • the command generation unit 231 is an example of a QoS setting unit.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

通信管理装置は、クラスタを構成する複数のコンピュータのそれぞれにおいて１以上稼働する通信部が行う通信の通信量を取得する取得部と、前記通信について将来の通信量を予測する予測部と、前記コンピュータごとに当該コンピュータで稼働する前記通信部の前記将来の通信量の合計を算出し、前記合計が閾値を超過する第１のコンピュータを特定する特定部と、前記第１のコンピュータにおいて稼働する前記通信部について、第２のコンピュータへの移動を制御する移動制御部と、を有することで、クラスタにおける通信異常の発生を抑制する。

Description

通信管理装置及び通信管理方法
　本発明は、通信管理装置及び通信管理方法に関する。
　ＡＲ（Augmented Reality）、ＶＲ（Virtual Reality）、遠隔保守などのサービスでは、パケットロスや遅延を最小化した、高い通信品質がＥｎｄ－ｔｏ－Ｅｎｄで必要となる。このようなサービスが、クラスタにおいて構築されたクラウドネイティブな基盤（ｋｕｂｅｒｎｅｔｅｓ等）上で動作する状況において、例えば、非特許文献１では、ｋｕｂｅｒｎｅｔｅｓでコンテナを管理する最小単位であるポッドを複数の優先クラスに分けて、高優先クラスのポッドから順に帯域を割り当てることで、キューイング遅延を発生させずに通信を可能とすることが開示されている。
NBWGuard:Realizing Network QoS for Kubernetes ,2018.
　Ｅｎｄ－ｔｏ－Ｅｎｄ通信で低遅延が必要なサービスでは、クラスタ外エンドユーザ端末との通信や、アプリの処理に不可欠なマイクロサービス間の通信も低遅延であるべきところ、非特許文献１の技術では、高優先通信の多重やバーストが発生すると遅延が発生してしまうという問題が有る。
　本発明は、上記の点に鑑みてなされたものであって、クラスタにおける通信異常の発生を抑制することを目的とする。
　そこで上記課題を解決するため、通信管理装置は、クラスタを構成する複数のコンピュータのそれぞれにおいて１以上稼働する通信部が行う通信の通信量を取得する取得部と、前記通信について将来の通信量を予測する予測部と、前記コンピュータごとに当該コンピュータで稼働する前記通信部の前記将来の通信量の合計を算出し、前記合計が閾値を超過する第１のコンピュータを特定する特定部と、前記第１のコンピュータにおいて稼働する前記通信部について、第２のコンピュータへの移動を制御する移動制御部と、を有する。
　クラスタにおける通信異常の発生を抑制することができる。
本発明の実施の形態の概要を説明するための図である。 本発明の実施の形態における通信管理装置１０のハードウェア構成例を示す図である。 通信管理装置１０が実行する処理手順の一例を説明するためのフローチャートである。 各ポッドの宛先別通信量の取得処理の処理手順の一例を説明するためのフローチャートである。 各ポッドの宛先別通信量の取得処理を説明するための図である。 各ポッドの通信の一例を示す図である。 各ポッドの将来の通信量の予測処理を説明するための図である。 帯域超過となる可能性が高いサーバαの特定処理の処理手順の一例を説明するためのフローチャートである。 閾値の計算例を示す図である。 サーバαの特定例を示す図である。 移動対象のポッド及び移動先の決定処理の処理手順の一例を説明するためのフローチャートである。 移動対象のポッド及び移動先の決定例を示す図である。 移動後のポッドへのＱｏＳ制御の処理手順の一例を説明するためのフローチャートである。 移動後のポッドへのＱｏＳ制御を説明するための図である。 本発明の実施の形態を適用した具体的なシステム構成の一例を示す図である。 クラスタＮＷ管理システム２０の構成例を示す図である。 通信量予測装置２１の構成例を示す図である。 予測パラメータ管理テーブル２１４の構成例を示す図である。 閾値情報テーブル２１５の構成例を示す図である。 スケジュール装置２２の構成例を示す図である。 クラスタ管理テーブル２２２の構成例を示す図である。 ＱｏＳ制御装置２３の構成例を示す図である。 ＱｏＳ設定情報テーブル２３３の構成例を示す図である。 通信量情報の取得と予測に関する処理手順の一例を説明するためのシーケンス図である。 スケジューリングの実施に関する処理手順の一例を説明するためのシーケンス図である。
　以下、図面に基づいて本発明の実施の形態を説明する。以下では、クラスタにおいて構築されたｋｕｂｅｒｎｅｔｅｓ等のクラウドネイティブな基盤上でサービスを実現するプロセス（コンテナ）が実行される環境を想定して説明する。
　図１は、本発明の実施の形態の概要を説明するための図である。図１には、クラスタを構成する４つの物理ホスト（物理的なコンピュータ）であるサーバのそれぞれにおいて、１以上ポッド（Ｐｏｄ）が稼働している状態が示されている。また、実線の両矢印は、クラスタの外部（クラスタ外）との通信を示し、破線の両矢印は、マイクロサービス間通信（クラスタ内のポッド間の通信）を示す（斯かる表記は、以下の他の図面において同様である。）。なお、ポッドとは、コンテナ（プロセス）の集合を管理する最小単位をいう。図１では、当該クラスタを管理するコンピュータである通信管理装置１０が、（１）、（２）、（３）の手順を実行することが示されている。これらの意味は以下の通りである。
（１）各ポッドの通信量を予測することで、帯域超過の可能性が相対的に高いサーバを特定
（２）サーバ間で通信量が分散するように、移動させるポッドと移動先のサーバを選択
（３）（２）において、移動先としての条件を満たすサーバが無い場合、ポッドを複数個にスケールアウトし（ポッドを分割し）、ポッド間の通信量を分散した後で（２）以降を再実行
　なお、ポッドの移動後、通信管理装置１０は、サービス側の通信品質要求に応じたポッドの通信のＱｏＳ設定を動的に行う。
　図２は、本発明の実施の形態における通信管理装置１０のハードウェア構成例を示す図である。図２の通信管理装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びネットワークインタフェース１０５等を有する。
　通信管理装置１０での処理を実現するプログラムは、ＣＤ－ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
　メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って通信管理装置１０に係る機能を実行する。ネットワークインタフェース１０５は、ネットワークに接続するためのインタフェースとして用いられる。
　図３は、通信管理装置１０が実行する処理手順の一例を説明するためのフローチャートである。なお、図３の各ステップは、通信管理装置１０にインストールされた１以上のプログラムが通信管理装置１０に実行させる。
　ステップＳ１０において、通信管理装置１０は、クラスタ内の各サーバで稼働する各ポッドの宛先別通信量を取得する。ここで、「宛先別」とは、クラスタ外であるかクラスタ内であるかの別をいい、クラスタ内の通信については、通信相手別に通信量が区別される。一方、クラスタ外の通信の通信量については、通信相手は区別されない。したがって、クラスタ外の通信の通信量は、ポッドごとに高々１つである。
　続いて、通信管理装置１０は、各ポッドの将来（例えば、Ｎ分後）の通信量を予測（通信量の予測値を計算）する（Ｓ２０）。
　続いて、通信管理装置１０は、各ポッド通信量の予測値に基づいて、各サーバの通信量の予測値を算出し、各サーバの通信量の予測値に基づいて、帯域超過となる可能性が相対的に高いサーバαを特定する（Ｓ３０）。
　続いて、通信管理装置１０は、サーバαにおいて稼働するポッドの中から移動対象のポッドを決定すると共に、移動対象のポッドの移動先のサーバを決定し、当該ポッドを当該サーバへ移動する（Ｓ４０）。今後の通信量の変化を想定しサーバ間の通信量ができるだけ均等に分散されるように、移動対象のポッドと移動先が決定される。その結果、各サーバ間で通信量を分散できるようになる。
　続いて、通信管理装置１０は、新たにスケジューリングした（移動した）ポッドに対するＱｏＳ制御を動的に設定する（Ｓ５０）。すなわち、ポッドのスケジュール後（移動後）に、特に通信品質を担保したい優先サービスのポッドに対してＱｏＳ制御が行われる。
　続いて、ステップＳ１０の詳細について説明する。図４は、各ポッドの宛先別通信量の取得処理の処理手順の一例を説明するためのフローチャートである。また、図５は、各ポッドの宛先別通信量の取得処理を説明するための図である。
　ステップＳ１１において、通信管理装置１０は、通信量の取得対象とするポッドのリスト（以下、「ポッドリスト」という。）を取得する。ポッドリストは、例えば、通信量について管理したい一部のポッド（すなわち、通信に関する優先度が相対的に高い一部のポッド）の一覧情報であり、例えば、予め作成される。但し、全てのポッドの通信量について管理したい場合、ポッドリストは、全てのポッドの一覧情報でもよい。なお、ポッドリストにおいて、各ポッドの識別情報は、例えば、ＩＰアドレスやサービス名等である。以下、ポッドリストに含まれる各ポッドを「対象ポッド」という。
　続いて、通信管理装置１０は、ポッド間通信を中継する機能（例：ｅｎｖｏｙプロキシ）のテレメトリ情報から全ポッド間の通信（以下「通信ｃ４」という。）のそれぞれごとに、通信量Ｖ４（図５参照）を取得する（Ｓ１２）。ここで、全ポッドとは、対象ポッド以外のポッドも含む全てのポッドをいう。なお、ステップＳ１２では、通信ｃ４ごとに、通信量Ｖ４に加え、当該通信ｃ４の端点となるポッドが特定される。
　続いて、通信管理装置１０は、通信ｃ４のうち、対象ポッドが端点であり、かつ、同一サーバ内の通信ではない通信（すなわち、対象ポッド⇔別サーバ上のポッドの通信（以下、「通信ｃ２」という。））を特定し、対象ポッドごとに、当該対象ポッドに係る（当該対象ポッドが端点である）各通信ｃ２の通信量Ｖ２（図５参照）を取得する（Ｓ１３）。
　続いて、通信管理装置１０は、コンテナ統合機能（例えば、ｄｏｃｋｅｒ）の管理情報から全ポッドの送受信通信（以下「通信ｃ３」という。）の通信量Ｖ３（図５参照）を取得する（Ｓ１４）。
　続いて、通信管理装置１０は、対象ポッドごとに、当該対象ポッドの通信量Ｖ３から通信量Ｖ４を差し引くことで、対象ポッド⇔クラスタ外の通信（以下「通信ｃ１」という。）の通信量Ｖ１を取得する（Ｓ１５）。
　上記により、対象ポッドごとに、１つの通信量Ｖ１と、１以上の通信ｃ２別（通信相手のポッド別）の通信量Ｖ２とが取得される。
　続いて、図３のステップＳ２０の詳細について説明する。図６は、各ポッドの通信の一例を示す図である。図６には、ステップＳ１０において取得された、通信ｃ１及びｃ２の一例が示されている。本実施の形態では、予測精度を向上するため、通信管理装置１０は、ステップＳ２０において、通信ｃ１と通信ｃ２とで異なる方法で予測を行う。
　図７は、各ポッドの将来の通信量の予測処理を説明するための図である。図７には、或る１つの対象ポッド（以下、「対象ポッドｐ」という。）に関する通信ｃ１及び各通信ｃ２のそれぞれについて、左側に現在の通信量が示され、右側に将来（Ｎ分後）の通信量の予測値が示されている。すなわち、以下において説明する処理は、対象ポッドごとに実行される。
　まず、通信管理装置１０は、対象ポッドｐの通信ｃ１について、時系列分析（「川原、ネットワークオペレーションへのＡＩ活用、２０１８、https://www.jstage.jst.go.jp/article/bplus/12/1/12_29/_article/-char/ja/」）やＲＮＮ（「井田、深層学習のための先進的な学習技術、２０１８、https://www.ntt.co.jp/journal/1806/files/JN20180630.pdf」）等の公知技術を利用して将来の通信量を予測する（Ｓ２１）。
　一方、通信管理装置１０は、対象ポッドｐの各通信ｃ２について、通信量Ｖ１の予測結果との相関、ポッド間通信のポリシ情報、通信プロトコルの特性などを考慮した予測モデルを学習し、当該予測モデルに基づいて将来の通信量を予測する。
　例えば、通信管理装置１０は、過去データ（過去の通信履歴）に基づいて、通信ｃ１の通信量と各通信ｃ２の通信量のベクトルｖ２の成分の総和との相関関係を学習する（Ｓ２２）。ここで、ベクトルｖ２の各成分は、通信相手別の各通信ｃ２の通信量である。なお、通信ｃ２は、対象ポッドｐが受信した通信ｃ１の処理をリクエストヘッダの値及び負荷分散ｗｅｉｇｈｔにしたがって他のｐｏｄに転送する通信であり、プロトコルにｇｒｐｃを用いられため、各フローの通信量は固定的である。したがって、通信ｃ１の通信量と通信ｃ２の通信量の総和との間には相関関係が有ると考えられる。
　通信管理装置１０は、また、過去データに基づいて、対象ポッドｐについて、当該ベクトルｖ２の各成分の相関関係を学習する（Ｓ２３）。
　続いて、通信管理装置１０は、対象ポッドｐについて、学習済みの通信ｃ１の通信量と各通信ｃ２の通信量のベクトルｖ２の成分の総和の相関関係に対して通信ｃ１の予測値を適用して、当該総和の予測値を算出する（Ｓ２４）。
　続いて、通信管理装置１０は、注目ポッドについて、当該総和と学習済みのベクトルｖ２の各成分の相関関係に対して当該総和の予測値を適用して、通信ｃ２の将来の通信量の予測値を計算する（Ｓ２５）。
　なお、図７には、通信ｃ１の通信量＝ベクトルｖ２の成分の総和であり、ベクトルｖ２の各成分の相関が固定であるといった単純化した例が示されている。この場合、ベクトルｖ２の各成分の値は通信ｃ２の通信量に線形に比例する。
　続いて、図３のステップＳ３０の詳細について説明する。図８は、帯域超過となる可能性が高いサーバαの特定処理の処理手順の一例を説明するためのフローチャートである。
　ステップＳ３１において、通信管理装置１０は、各サーバに接続するリンク帯域及びバッファ値等に基づいて、各サーバの最大帯域を算出する。続いて、通信管理装置１０は、各サーバについて、最大帯域と許容使用率に基づいて閾値を決定（計算）する（Ｓ３２）。なお、許容使用率は、予め設定される値である。
　図９は、閾値の計算例を示す図である。図９には、リンク帯域が１０Ｇｂｐｓ、バッファが０．５Ｇｂｐｓ、許容使用率が９５％であるサーバの例が示されている。この場合、当該サーバの閾値は、図９に示されるように、１０Ｇｂｐｓとして決定される。但し、閾値は各サーバで固定的に設定されてもよい。
　続いて、通信管理装置１０は、サーバごとに、当該サーバに属する各ポッドの通信ｃ１及びｃ２の予測値の合計と、当該サーバの閾値とを比較し、当該合計が当該閾値より大きくなるサーバαを特定する（Ｓ３１）。この際、複数のサーバがサーバαとして特定されうる。
　なお、対象ポッドが全ポッドの一部である場合、当該予測値の合計は、必ずしもサーバによる全通信量であるとは限らない。そこで、このような事情を考慮して許容使用率が設定されてもよい。すなわち、許容使用率には、サーバの全通信量のうち対象ポッドの通信に対して許容される通信量の割合が設定されてもよい。
　図１０は、サーバαの特定例を示す図である。図１０の例では、真ん中のサーバがサーバαとして特定される。
　続いて、図３のステップＳ４０の詳細について説明する。図１１は、移動対象のポッド及び移動先の決定処理の処理手順の一例を説明するためのフローチャートである。
　ステップＳ４１において、通信管理装置１０は、各サーバの予測通信量の平均Ｔ'を計算する。
　続いて、通信管理装置１０は、以下の最適化問題を解くことで、サーバαの予測通信量がＴ'に最も近くなるように、移動対象のポッドｉを選択する（Ｓ４２）。
Figure JPOXMLDOC01-appb-M000001
 但し、Ｔαは、サーバαの通信量、ｔｉは、ポッドｉの通信量である。
　続いて、通信管理装置１０は、以下の最適化問題を解くことで、移動先のサーバβの予測通信量がＴ'に最も近くなるように、移動先のサーバβを探索する（Ｓ４３）。
Figure JPOXMLDOC01-appb-M000002
 但し、ｓｉｊは、ポッドｉとサーバｊ上の（全ての）ポッドの通信量の総和である。
　すなわち、サーバ間の通信量ができるだけ均等に分散されるように、移動対象のポッドｉと移動先のサーバβとが決定される。
　サーバβの探索に成功した場合（Ｓ４４でＹｅｓ）、通信管理装置１０は、ポッドｉについてサーバβへの移動を制御する（Ｓ４６）。すなわち、通信管理装置１０は、ポッドｉをサーバαから削除し、ポッドｉをサーバβに新規に生成するための制御を行う。その結果、ポッドｉがサーバβへ移動する。一方、サーバβの探索に失敗した場合（Ｓ４４でＮｏ）、通信管理装置１０は、ポッドｉを複数個にスケールアウトし（ポッドｉを複数のポッドに分割し）（Ｓ４５）、ステップＳ４２以降を繰り返す。
　図１２は、移動対象のポッド及び移動先の決定例を示す図である。図１２の（１）では、左側のサーバにおいて帯域超過（閾値の超過）の可能性が高い例が示されている。この場合、（２）に示されるようにポッドを移動すれば、当該帯域超過を解消しつつ、各サーバの予測通信量の差を最小化することができる。したがって、この場合、左側のサーバの左側のポッドが移動対象として選択され、右側のサーバが移動先として選択される。
　なお、上記では予測通信量に基づいて移動させるポッドｉ及び移動先のサーバβを決定する例を示したが、例えば、予測通信量の分散に基づいて移動させるポッドｉ及び移動先のサーバβが決定されるようにしてもよい。この場合、上記における予測通信量が予測通信量の分散に置換されればよい。
　続いて、図３のステップＳ５０の詳細について説明する。図１３は、移動後のポッドへのＱｏＳ制御の処理手順の一例を説明するためのフローチャートである。また、図１４は、移動後のポッドへのＱｏＳ制御を説明するための図である。図１４には、図１３のステップ番号に対応する符号が対応箇所に付与されている。
　ステップＳ５１において、通信管理装置１０は、各ポッドのＱｏＳ制御情報が記録されたリストを参照し、移動したポッドｉに対するＱｏＳ設定情報を取得する。
　続いて、通信管理装置１０は、非特許文献１の技術やｔｃコマンドを利用し、移動後のポッドｉに対して優先的に帯域を割り当てる設定を投入する（Ｓ５２）。例えば、通信管理装置１０は、図１４に示されるように、サーバαからポッドｉに関する設定を削除し、サーバβに対してｔｃコマンドの設定等を行う。
　続いて、上記した内容を適用した具体的なシステム例について説明する。図１５は、本発明の実施の形態を適用した具体的なシステム構成の一例を示す図である。
　図１５において、物理ホストの一例である複数のサーバがＩＰネットワーク（例えば、ＤＣファブリックやＬＡＮな等）を介して通信している。サーバ上には、コンテナごとのワークロード（例：Ｋｕｂｅｒｎｔｅｓのポッドやコンテナ）が稼働する仮想ネットワークであるクラスタＮＷ３０がサービス事業者ごとに構築されている。このとき、単一サーバ上に複数のクラスタＮＷ３０が存在してもよい。
　クラスタＮＷ管理システム２０は、クラスタＮＷ３０上のワークロードやクラスタＮＷ３０に属するサーバから通信量等のネットワーク情報を取得し、取得した情報に基づくワークロードの位置制御（スケジューリング）やＱｏＳ制御の設定等を行う１以上のコンピュータである。すなわち、クラスタＮＷ管理システム２０は、上記の通信管理装置１０に相当する。また、ワークロードは、上記のポッドに対応する。なお、クラスタＮＷ管理システム２０は、クラスタＮＷ３０に属するサーバ内部に位置してもよい。また、単一のサーバ上に複数のクラスタＮＷ３０が存在する場合、複数のクラスタＮＷ管理システム２０間で連携し、制御に必要な情報をやりとりしてもよい。
　図１６は、クラスタＮＷ管理システム２０の構成例を示す図である。図１６において、クラスタＮＷ管理システム２０は、通信量予測装置２１、スケジュール装置２２、ＱｏＳ制御装置２３、インタフェース装置２４及び管理ＤＢ２５等を含む。各装置は、ソフトウェアであってもよいしハードウェア（コンピュータ）であってもよい。各装置がソフトウェアである場合、各装置は、共通のコンピュータを用いて実現されてもよい。いずれの場合であっても、各装置の機能は、各装置を実現するコンピュータにインストールされた１以上のプログラムが当該コンピュータに実行させる処理により実現される。
　インタフェース装置２４は、ユーザから投入されたコマンドの情報を管理ＤＢ２５に投入したり、クラスタＮＷ３０の構成要素であるサーバやワークロード、その他の内部機能と直接通信し、テレメトリや制御情報等をやり取りする。
　管理ＤＢ２５は、ユーザが投入したコマンドに基づき、クラスタの取るべき構成（ワークロード数など）を保持する。
　通信量予測装置２１は、インタフェース装置２４からワークロードやサーバの通信量を取得して将来の通信量を予測する。通信量予測装置２１は、更に、サーバごとの通信量を計算し、帯域超過の可能性が高いサーバαを特定する。
　スケジュール装置２２は、サーバαの中から移動させるワークロードと移動先のサーバを決定する。
　ＱｏＳ制御装置２３は、移動したワークロードに対し動的にＱｏＳを設定する。
　また、各サーバは、ワークロード管理部４１を含む。ワークロード管理部４１は、インタフェース装置２４からの制御通信を受け付け、ワークロードの立ち上げや消去を行うなど、ワークロードがサーバ内で正常に稼働することを保証する。
　以下、通信量予測装置２１、スケジュール装置２２、ＱｏＳ制御装置２３の詳細について説明する。
　図１７は、通信量予測装置２１の構成例を示す図である。図１７において、通信量予測装置２１は、通信量予測部２１１、帯域超過判定部２１２、学習データＤＢ２１３、予測パラメータ管理テーブル２１４及び閾値情報テーブル２１５等を含む。
　学習データＤＢ２１３は、ワークロードやサーバの過去の通信量を学習データとして蓄積する。
　予測パラメータ管理テーブル２１４は、通信量を取得したいワークロード（上記の対象ポッド）のリストを保持する。予測パラメータ管理テーブル２１４は、また、予測モデルの学習に用いるアルゴリズムや事前情報となる設定情報、学習後のパラメータを保持する。
　通信量予測部２１１は、インタフェース装置２４を介してワークロードやサーバの通信量を取得し、学習データＤＢ２１３に蓄積された学習データから将来の通信量を予測する。通信量予測部２１１は、また、予測モデルのパラメータを更新し、更新結果を予測パラメータ管理テーブル２１４に格納する。通信量予測部２１１は、更に、インタフェース装置２４からワークロードの位置情報（どのワークロードがどのサーバに位置するか）を取得し、各サーバの通信量を計算する。
　閾値情報テーブル２１５は、サーバの帯域の閾値の決定に用いる情報を蓄積する。
　帯域超過判定部２１２は、サーバごとの帯域やパラメータから閾値を決定する。帯域超過判定部２１２は、また、閾値と各サーバの通信量とを比較し帯域超過の可能性が高いサーバαを特定する。
　図１８は、予測パラメータ管理テーブル２１４の構成例を示す図である。図１８に示されるように、予測パラメータ管理テーブル２１４は、通信量を取得したいワークロードのリスト、クラスタ外との通信予測に用いるアルゴリズム、クラスタ内のワークロードとの通信予測に用いるアルゴリズムの情報、及びその学習パラメータを蓄積する。ワークロードごとの通信量を予測するため、ワークロードごとに個別の学習パラメータが保持される。学習パラメータは新たに流入する通信量データに伴って学習され、テーブル内の値も更新される。
　また、各ワークロードがクラスタ内でどのように通信するかがポリシで定められている場合、予測パラメータ管理テーブル２１４は、これらの情報も保持する。当該情報は、モデルの学習に使用される。
　図１９は、閾値情報テーブル２１５の構成例を示す図である。図１９に示されるように、閾値情報テーブル２１５は、帯域超過判定部２１２が帯域超過の可能性が高いサーバαを選択する際に用いる閾値を計算するための情報を保持する。例えば、サーバの帯域、ソケットのバッファ値がサーバごとに保持される。閾値情報テーブル２１５は、また、最大帯域に対して、使用可能な帯域の使用率の情報である許容使用率を保持する。
　図２０は、スケジュール装置２２の構成例を示す図である。図２０において、スケジュール装置２２は、スケジュール演算部２２１及びクラスタ管理テーブル２２２等を含む。
　スケジュール演算部２２１は、帯域超過サーバの情報、及び当該サーバの内部で稼働するワークロードの通信量情報を通信量予測装置２１から取得する。スケジュール演算部２２１は、また、クラスタ管理テーブル２２２を参照し、帯域超過サーバから移動させるワークロードを決定する。スケジュール演算部２２１は、また、クラスタ管理テーブル２２２を参照し、各サーバで稼働しているワークロードの情報やサーバのメトリック情報を考慮したうえで、移動先のサーバを決定する。スケジュール演算部２２１は、更に、ワークロードの移動の制御を行う。具体的には、スケジュール演算部２２１は、移動対象ワークロードと移動先のサーバの情報を変更するため、インタフェース装置２４に更新依頼を行うと同時にＱｏＳ制御装置２３に配置変更の通知を送信する。
　クラスタ管理テーブル２２２は、インタフェース装置２４を介して、各サーバで稼働しているワークロードのＩＤや、各サーバのメトリック（ＣＰＵやメモリ、ストレージ量、通信量）をリアルタイムに取得し保持する。
　図２１は、クラスタ管理テーブル２２２の構成例を示す図である。図２１に示されるように、クラスタ管理テーブル２２２は、各サーバで動作するワークロードのＩＤ、及び各サーバの現在のパフォーマンスを示すメトリック情報を保持する。テーブル内の情報は、クラスタＮＷ３０の中で変更が発生するタイミングで、インタフェース装置２４からの更新依頼に基づき更新される。スケジュール装置２２は、特に、メトリック情報を参照し、通信量だけでなく、ＣＰＵ、メモリ、ストレージの観点で最適な移動先のサーバを決定する。
　図２２は、ＱｏＳ制御装置２３の構成例を示す図である。図２２において、ＱｏＳ制御装置２３は、コマンド生成部２３１、過去コマンドＤＢ２３２及びＱｏＳ設定情報テーブル２３３等を含む。
　コマンド生成部２３１は、スケジュール装置２２からワークロードの配置変更の通知を受け付けると、過去コマンドＤＢ２３２に問い合わせ、移動対象のワークロードに対して過去に設定したＱｏＳ設定を取得し、インタフェース装置２４を介してＱｏＳ設定の更新依頼を行う。コマンド生成部２３１は、また、ＱｏＳ設定情報テーブル２３３から移動対象のワークロードの優先度情報を取得し、取得情報に基づいて新たなＱｏＳコマンドを生成し、インタフェース装置２４を介してＱｏＳ設定の更新依頼を行う。
　図２３は、ＱｏＳ設定情報テーブル２３３の構成例を示す図である。図２３に示されるように、ＱｏＳ設定情報テーブル２３３は、各ワークロードの優先度に合わせて、ＱｏＳ設定情報（Guaranteed、Best Effort）を保持する。これらの情報は、サービス開始の時点でシステム管理者によって定められる。ワークロードのＩＤや名称・ＩＰアドレス等の識別子は随時更新されるため、ＱｏＳ設定情報テーブル２３３ではサービス名とＱｏＳ設定情報が紐づくようにする。
　以下、クラスタＮＷ管理システム２０において実行される処理手順について説明する。図２４は、通信量情報の取得と予測に関する処理手順の一例を説明するためのシーケンス図である。図２４は、図３のステップＳ１０～Ｓ３０に対応する、クラスタＮＷ管理システム２０において実行される処理手順を示す。
　各ワークロードは、所定の時間間隔で、インタフェース装置２４を介して通信量予測装置２１宛に通信量情報（現在の通信量を示す情報）を送信する（Ｓ１０１、Ｓ１０２）。一方、各サーバは、所定の時間間隔で、インタフェース装置２４を介して通信量予測装置２１宛にワークロードの管理情報（ワークロードが稼働するサーバの情報等）を送信する（Ｓ１０３、Ｓ１０４）。通信量予測装置２１の通信量予測部２１１は、インタフェース装置２４を介して受信した情報を学習データＤＢ２１３に記録する。
　その後、通信量予測部２１１は、学習データＤＢ２１３に記録された過去の通信量データを学習して（Ｓ１０５）、学習済みモデルに基づいて各ワークロードの将来的な（例えば、Ｎ分後の）通信量を予測する（Ｓ１０６）。続いて、通信量予測部２１１は、ワークロードの予測通信量をサーバごとに合計することで各サーバの予測通信量を算出する（Ｓ１０７）。続いて、通信量予測装置２１の帯域超過判定部２１２は、各サーバの算出結果に基づいて、帯域超過の可能性が高いサーバαを特定する（Ｓ１０８）。続いて、帯域超過判定部２１２は、特定したサーバαの情報と各ワークロードの予測通信量をスケジュール装置２２に送信する（Ｓ１０９）。
　図２５は、スケジューリングの実施に関する処理手順の一例を説明するためのシーケンス図である。図２５は、図３のステップＳ４０及びＳ５０に対応する、クラスタＮＷ管理システム２０において実行される処理手順を示す。
　スケジュール装置２２のスケジュール演算部２２１は、通信量予測装置２１から通知されたサーバαの内部で稼働するワークロードの中から移動させるワークロードを選択すると共に、当該ワークロードの移動先のサーバを決定する（Ｓ２０１）。続いて、スケジュール演算部２２１は、選択又は決定した情報をインタフェース装置２４を介して移動先のサーバ及び移動元サーバのそれぞれのワークロード管理部４１、並びにＱｏＳ制御装置２３へ送信する（Ｓ２０２、Ｓ２１０、Ｓ２２０）。
　各サーバのエージェントであるワークロード管理部４１は、スケジュール装置２２の指示に従い（スケジュール演算部２２１から送信された情報に基づき）、ワークロードの削除及び新規作成（ワークロードの移動）を行う（Ｓ２１１）。
　一方、ＱｏＳ制御装置２３のコマンド生成部２３１は、移動したワークロードに適用するＱｏＳ制御コマンドを生成し（Ｓ２２１）、当該コマンドに基づいて、移動先のサーバに対してＱｏＳ制御を指示する（Ｓ２２２）。
　上述したように、本実施の形態によれば、クラスタを構成するサーバの通信量を考慮して、動的にポッド（ワークロード）の位置を変更することで、サーバの通信が所定の帯域を超過することを防ぎ、パケットロスや遅延を削減することができる。その結果、クラスタにおける通信異常の発生を抑制することができる。
　なお、本実施の形態において、ポッド又はワークロードは、通信部の一例である。サーバは、クラスタを構成する複数のコンピュータの一例である。通信量予測部２１１は、取得部及び予測部の一例である。帯域超過判定部２１２は、特定部の一例である。スケジュール演算部２２１は、移動制御部の一例である。コマンド生成部２３１は、ＱｏＳ設定部の一例である。
　以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
１０　　　　　通信管理装置
２０　　　　　クラスタＮＷ管理システム
２１　　　　　通信量予測装置
２２　　　　　スケジュール装置
２３　　　　　ＱｏＳ制御装置
２４　　　　　インタフェース装置
２５　　　　　管理ＤＢ
３０　　　　　クラスタＮＷ
４１　　　　　ワークロード管理部
１００　　　　ドライブ装置
１０１　　　　記録媒体
１０２　　　　補助記憶装置
１０３　　　　メモリ装置
１０４　　　　ＣＰＵ
１０５　　　　ネットワークインタフェース
２１１　　　　通信量予測部
２１２　　　　帯域超過判定部
２１３　　　　学習データＤＢ
２１４　　　　予測パラメータ管理テーブル
２１５　　　　閾値情報テーブル
２２１　　　　スケジュール演算部
２２２　　　　クラスタ管理テーブル
２３１　　　　コマンド生成部
２３２　　　　過去コマンドＤＢ
２３３　　　　ＱｏＳ設定情報テーブル
Ｂ　　　　　　バス

Claims (6)

  1. 　クラスタを構成する複数のコンピュータのそれぞれにおいて１以上稼働する通信部が行う通信の通信量を取得する取得部と、
    　前記通信について将来の通信量を予測する予測部と、
    　前記コンピュータごとに当該コンピュータで稼働する前記通信部の前記将来の通信量の合計を算出し、前記合計が閾値を超過する第１のコンピュータを特定する特定部と、
    　前記第１のコンピュータにおいて稼働する前記通信部について、第２のコンピュータへの移動を制御する移動制御部と、
    を有することを特徴とする通信管理装置。
  2. 　前記移動の後において、前記移動の対象とされた前記通信部に対して優先的に帯域を割り当てるＱｏＳ設定を行うＱｏＳ設定部、
    を有することを特徴とする請求項１記載の通信管理装置。
  3. 　前記通信部は、前記クラスタ内の第１の通信及び前記クラスタの外部との第２の通信の双方又は一方を行い、
    　前記予測部は、過去における前記第１の通信と前記第２の通信との相関に基づいて、前記第２の通信の通信量を予測する、
    ことを特徴とする請求項１又は２記載の通信管理装置。
  4. 　前記移動制御部は、前記コンピュータごとに将来の通信量を予測し、前記第１のコンピュータにおいて稼働する前記通信部のうち、当該通信部を前記第１のコンピュータから移動した場合に、前記第１のコンピュータの将来の通信量が前記コンピュータごとの将来の通信量の平均に最も近くなる前記通信部を前記第２のコンピュータへの移動対象として選択する、
    ことを特徴とする請求項１乃至３いずれか一項記載の通信管理装置。
  5. 　前記移動制御部は、前記コンピュータごとに将来の通信量を予測し、前記移動の対象の前記通信部が当該コンピュータに移動した場合に、当該コンピュータの将来の通信量が前記コンピュータごとの将来の通信量の平均に最も近くなるコンピュータを前記第２のコンピュータとして選択する、
    ことを特徴とする請求項１乃至４いずれか一項記載の通信管理装置。
  6. 　クラスタを構成する複数のコンピュータのそれぞれにおいて１以上稼働する通信部が行う通信の通信量を取得する取得手順と、
    　前記通信について将来の通信量を予測する予測手順と、
    　前記コンピュータごとに当該コンピュータで稼働する前記通信部の前記将来の通信量の合計を算出し、前記合計が閾値を超過する第１のコンピュータを特定する特定手順と、
    　前記第１のコンピュータにおいて稼働する前記通信部について、第２のコンピュータへの移動を制御する移動制御手順と、
    をコンピュータが実行することを特徴とする通信管理方法。
PCT/JP2019/047185 2019-12-03 2019-12-03 通信管理装置及び通信管理方法 WO2021111516A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2021562226A JP7359222B2 (ja) 2019-12-03 2019-12-03 通信管理装置及び通信管理方法
PCT/JP2019/047185 WO2021111516A1 (ja) 2019-12-03 2019-12-03 通信管理装置及び通信管理方法
US17/780,865 US11695644B2 (en) 2019-12-03 2019-12-03 Communication management apparatus and communication management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2019/047185 WO2021111516A1 (ja) 2019-12-03 2019-12-03 通信管理装置及び通信管理方法

Publications (1)

Publication Number Publication Date
WO2021111516A1 true WO2021111516A1 (ja) 2021-06-10

Family

ID=76222501

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/047185 WO2021111516A1 (ja) 2019-12-03 2019-12-03 通信管理装置及び通信管理方法

Country Status (3)

Country Link
US (1) US11695644B2 (ja)
JP (1) JP7359222B2 (ja)
WO (1) WO2021111516A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024125201A1 (zh) * 2022-12-13 2024-06-20 华为云计算技术有限公司 一种服务网格限流方法及相关装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180314550A1 (en) * 2017-05-01 2018-11-01 Red Hat, Inc. Cluster topology aware container scheduling for efficient data transfer
US20190034237A1 (en) * 2017-02-25 2019-01-31 Vmware, Inc. Methods and apparatus to manage compute resources in a hyperconverged infrastructure computing environment
US20190102717A1 (en) * 2017-09-29 2019-04-04 At&T Intellectual Property I, L.P. Microservice auto-scaling for achieving service level agreements
US20190253490A1 (en) * 2016-10-31 2019-08-15 Huawei Technologies Co., Ltd. Resource load balancing control method and cluster scheduler

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10205675B2 (en) * 2016-10-19 2019-02-12 Red Hat, Inc. Dynamically adjusting resources to meet service level objectives
US11805073B2 (en) * 2021-05-03 2023-10-31 Avesha, Inc. Controlling placement of workloads of an application within an application environment

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190253490A1 (en) * 2016-10-31 2019-08-15 Huawei Technologies Co., Ltd. Resource load balancing control method and cluster scheduler
US20190034237A1 (en) * 2017-02-25 2019-01-31 Vmware, Inc. Methods and apparatus to manage compute resources in a hyperconverged infrastructure computing environment
US20180314550A1 (en) * 2017-05-01 2018-11-01 Red Hat, Inc. Cluster topology aware container scheduling for efficient data transfer
US20190102717A1 (en) * 2017-09-29 2019-04-04 At&T Intellectual Property I, L.P. Microservice auto-scaling for achieving service level agreements

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
CONG XU ET AL.: "NBWGuard: Realizing Network QoS for Kubernetes", IN THE PROCEEDINGS OF THE 19TH INTERNATIONAL MIDDLEWARE CONFERENCE INDUSTRY (MIDDLEWARE'18, 10 December 2018 (2018-12-10), pages 32 - 38, XP055834411 *
JING TAI PIAO ET AL.: "A Network-aware Virtual Machine Placement and Migration Approach in Cloud Computing", IN THE PROCEEDINGS OF 2010 NINTH INTERNATIONAL CONFERENCE ON GRID AND CLOUD COMPUTING, 1 November 2010 (2010-11-01), pages 87 - 92, XP031831023 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024125201A1 (zh) * 2022-12-13 2024-06-20 华为云计算技术有限公司 一种服务网格限流方法及相关装置

Also Published As

Publication number Publication date
US20230006893A1 (en) 2023-01-05
JPWO2021111516A1 (ja) 2021-06-10
US11695644B2 (en) 2023-07-04
JP7359222B2 (ja) 2023-10-11

Similar Documents

Publication Publication Date Title
JP4920080B2 (ja) コンテンツ配信ネットワークのための集中化したスケジューラ
JP6380110B2 (ja) リソース制御システム、制御パターン生成装置、制御装置、リソース制御方法及びプログラム
JP4984169B2 (ja) 負荷分散プログラム、負荷分散方法、負荷分散装置およびそれを含むシステム
US11792275B2 (en) Dynamic connection capacity management
CN112822050A (zh) 用于部署网络切片的方法和装置
KR20220000592A (ko) 사물인터넷 엣지 컴퓨팅 환경을 위한 컨테이너 기반 동적 자원 분배 방법 및 장치
US8854977B2 (en) Relay node
US10216593B2 (en) Distributed processing system for use in application migration
WO2022016969A1 (zh) 一种数据处理方法及装置
KR101448413B1 (ko) Atca-기반 장비에서 통신 트래픽을 스케줄링하기 위한 방법 및 장치
CN109815204A (zh) 一种基于拥塞感知的元数据请求分发方法及设备
US9654333B2 (en) Application allocation in datacenters
WO2021111516A1 (ja) 通信管理装置及び通信管理方法
US11397605B2 (en) Management system, management apparatus, management method, and program
CN112737806B (zh) 网络流量的迁移方法及装置
KR20160025926A (ko) 가상 응용서버들로 부하를 분산하는 장치 및 방법
US20180278495A1 (en) Provisioning of telecommunications resources
US11968124B2 (en) System and method for managing network traffic using fair-share principles
CN115190121B (zh) 基于跨地域的微服务过量负载调度系统、方法及设备
US20080114635A1 (en) Method and apparatus for calculating importance degrees for resources
KR101813165B1 (ko) 소프트웨어 정의 네트워크를 위한 적응적 제어 평면 관리 방법 및 장치
US11720387B2 (en) Managing communication rates between applications in a tiered application computing environment
JP7259738B2 (ja) 制御装置、制御システム、制御装置の制御方法及びプログラム
Sasaki et al. Resource Allocation Methods among Server Clusters in a Resource Permeating Distributed Computing Platform for 5G Networks
JP2011170649A (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: 19955079

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021562226

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19955079

Country of ref document: EP

Kind code of ref document: A1