WO2019235304A1 - サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラム - Google Patents

サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラム Download PDF

Info

Publication number
WO2019235304A1
WO2019235304A1 PCT/JP2019/021127 JP2019021127W WO2019235304A1 WO 2019235304 A1 WO2019235304 A1 WO 2019235304A1 JP 2019021127 W JP2019021127 W JP 2019021127W WO 2019235304 A1 WO2019235304 A1 WO 2019235304A1
Authority
WO
WIPO (PCT)
Prior art keywords
vnf
service chain
redundancy
determination unit
redundant
Prior art date
Application number
PCT/JP2019/021127
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 US15/734,292 priority Critical patent/US11258551B2/en
Publication of WO2019235304A1 publication Critical patent/WO2019235304A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/22—Arrangements for detecting or preventing errors in the information received using redundant apparatus to increase reliability
    • 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • 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/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • 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/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • 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/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5045—Making service definitions prior to deployment
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • 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/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
    • 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/0803—Configuration setting
    • H04L41/0823—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
    • H04L41/0826—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability for reduction of network costs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/128—Shortest path evaluation for finding disjoint paths
    • 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/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering

Definitions

  • the present invention relates to a service chain design apparatus, a service chain design method, and a service chain design program.
  • a method of preparing a spare computer in advance before a failure occurs in the system and switching the processing to the spare computer when a failure occurs is called redundancy.
  • This redundancy can provide a highly reliable system with excellent fault tolerance.
  • a redundant configuration such as duplication of service components (routes, various devices, applications, etc.) is adopted.
  • Patent Document 1 when designing a redundant communication path in a sub-network in which the entire network is divided into a plurality of hardware candidates such as fiber duplication, node duplication, and pipe duplication among a plurality of redundant route candidates.
  • a communication path output means is described that uses as few route candidates as possible to share hardware resources.
  • NFV Network Function Virtualization
  • VNF Virtualized Network Function
  • VNFs are, for example, vCPE (Virtualized Customer Premises Equipment), vRouter, vMitigator, vFW (Virtualized Firewall), vLB (Virtualized Load Balancer), and vDPI (Virtualized Deep Packet Inspection).
  • vCPE Virtualized Customer Premises Equipment
  • vRouter vMitigator
  • vFW Virtualized Firewall
  • vLB Virtualized Load Balancer
  • vDPI Virtualized Deep Packet Inspection
  • a technique that allows VNFs to be flexibly selected and used for each user is called service chaining.
  • a series of services provided by service chaining is called a service chain.
  • the network function provided by the dedicated appliance can be realized by software (virtual machine) group on the virtualization platform.
  • software virtual machine
  • a network function group realized on a virtualization platform composed of general-purpose servers is connected as a single service through service chaining.
  • FIG. 7 is an explanatory diagram of a service chain.
  • a physical network system is constructed in which each physical node [N1,..., N11] is connected by each physical link [L1,.
  • the physical node N4 and the physical node N8 are connected by a physical link L8.
  • virtual nodes [VM1,..., VM6] are formed on this physical node, and VNFs [F1,.
  • F1 of VNF is operating on the virtual node VM1.
  • one or more VNFs are bundled respectively by service chains [A, B, C].
  • the VNF used by each service chain varies between a VNF with a heavy access and a high load, and a VNF with a low access and a low load. Details of the VNF used by each service chain will be described below with reference to FIG.
  • FIG. 8 is a detailed explanatory diagram of a service chain constructed on the physical network system of FIG.
  • Reference numeral 109 denotes a path in which each service chain [A, B, C] in FIG. 7 traces the physical resource and the virtual resource that pass from the start point to the end point.
  • the service chain A uses the VNF “F2” on the VM3 and the VNF “F3” on the destination VM5 from the physical node N1 at the start point.
  • the service chain B uses the VNF “F3” on the VM5 and the VNF “F1” on the destination VM1 from the physical node N1 at the start point.
  • the service chain C uses the VNF “F4” on the VM6, the VNF “F3” on the VM5, and the VNF “F2” on the destination VM3 from the physical node N3 at the start point. That is, VNF “F3” is used for three service chains A to C, VNF “F2” is used for two service chains A and C, VNF “F1” is used only for service chain B, and VNF “F4” is used. "Is used only for service chain C.
  • the table 209a indicates the number of accommodated users for each service chain, and the service chain A accommodates the maximum 100 users.
  • the table 209b shows the status of the service chain focused on each VNF indicated by VNFID.
  • the influence at the time of failure is larger than that of other VNFs (highlighted by hatching in the figure).
  • the redundant physical resource prepared as a spare becomes an idle resource as it is in a normal state, so that the resource is wasted. Therefore, from the viewpoint of cost, it is preferable that the physical resources for redundancy are as few as possible.
  • VNF “F3 that affects many users at the time of failure (that is, interrupts the service and imposes inconvenience on waiting time for many users). It is desirable to prioritize "" over other VNFs and increase redundancy.
  • the main object of the present invention is to design a redundant configuration of virtual network functions that is cost-effective while improving the reliability of the entire service chain.
  • the service chain designing apparatus of the present invention has the following features.
  • at least one of the number of service chains using VNFs and the number of users accommodated in the service chains using VNFs is made important for each VNF, and VNFs having a high importance are made redundant.
  • a first determination unit that determines the target VNF;
  • a second determination unit that determines, when the importance level of the redundancy target VNF determined by the first determination unit exceeds a predetermined threshold, the redundant target VNF that has exceeded the redundancy execution VNF;
  • the new redundancy execution that becomes the load distribution destination of the service chain that uses the redundancy execution VNF so that the importance of the redundancy execution VNF determined by the second determination unit falls below a predetermined threshold.
  • a redundancy calculation unit that calculates the number of VNFs generated.
  • the redundancy target VNF is selected with the importance of parameters directly affecting services and users, such as the number of service chains using the VNF and the number of users accommodated by the VNF, so that the reliability is high. Service chain design becomes possible. Furthermore, by narrowing down important VNFs as VNFs to be redundant, it is possible to design a redundant configuration of a virtual network function with good cost efficiency.
  • the first determination unit weights the higher importance as the position of the VNF in the service chain is behind the route, In addition, it is characterized in that at least one of the weights having a higher importance for a VNF that consumes more resources in the previous stage in the service chain is an importance for each VNF.
  • the first determination unit determines the weight of service contents provided by the VNF and the weight of users accommodated by the service chain. The importance is calculated for each VNF based on at least one of the weights.
  • the VNF having the important service or the important user is preferentially made redundant, so that the satisfaction of the user can be increased.
  • the present invention is characterized in that the second determination unit determines whether or not the importance of the redundancy target VNF exceeds a predetermined threshold based on the measurement data of the performance value of VNF.
  • VNF having a high load of the fluctuating VNF is preferentially made redundant, a more practical reliability design is possible.
  • the service chain design apparatus further includes an arrangement determining unit and a redundant route determining unit
  • the placement determination unit sets the placement destinations of the new redundancy execution VNFs for the number of generations calculated by the redundancy calculation unit so that the placement destinations of the plurality of redundancy execution VNFs are different from each other.
  • Decide The redundant route determining unit determines each redundant route that passes through each placement destination determined by the placement determining unit so that redundant routes between redundant routes in each service chain are reduced.
  • the service chain design apparatus further includes an arrangement determining unit and a redundant route determining unit,
  • the placement determination unit sets the placement destinations of the new redundancy execution VNFs for the number of generations calculated by the redundancy calculation unit so that the placement destinations of the plurality of redundancy execution VNFs are different from each other.
  • Decide The redundant route determination unit arranges a load balancer at a position immediately before the redundant route of the redundant execution VNF determined by the arrangement determination unit, and a plurality of the redundant execution VNFs via the load balancer It is characterized in that a redundant route passing through each is determined.
  • FIG. 8 is a detailed explanatory diagram of a service chain constructed on the physical network system of FIG. 7.
  • FIG. 1 is a configuration diagram of a service chain design apparatus 1.
  • the service chain design apparatus 1 is configured as a computer having a CPU (Central Processing Unit), a memory, storage means (storage unit) such as a hard disk, and a network interface.
  • the CPU executes a program (also referred to as an application or its abbreviated application) read on the memory, thereby operating a control unit (control means) configured by each processing unit.
  • a program also referred to as an application or its abbreviated application
  • the VNF included in the service chain handled by the service chain designing apparatus 1 is defined as follows. First, the service chain design apparatus 1 designates, as a “redundancy target VNF”, an important VNF that affects many users at the time of a failure among all VNFs operating on the physical network system. For example, VNF “F3” in FIG. 8 is an example of the redundancy target VNF. Next, when the service chain design apparatus 1 satisfies a predetermined standard for the “redundancy target VNF”, the service chain design apparatus 1 actually sets the redundancy target VNF as a VNF (hereinafter “redundancy execution VNF”). decide.
  • redundancy execution VNF a VNF
  • the VNF to be actually made redundant is determined through the steps of “all VNFs ⁇ redundancy target VNF ⁇ redundancy execution VNF”. In other words, it is still uncertain whether or not the VNF to be actually made redundant is just selected as the redundancy target VNF.
  • the service chain design apparatus 1 includes a policy / threshold management DB 21, a service chain configuration information DB 22, an accommodation information management DB 23, a performance value collection DB 24, and a redundancy target VNF management DB 25 as databases for storing various data. .
  • the service chain design apparatus 1 has a service chain generation request reception unit 11, a service chain generation request decomposition unit 12, and a redundancy target VNF determination unit (first determination) as processing units for selecting “redundancy target VNF”. Part) 13 and a redundancy target VNF determining part 14.
  • the service chain designing apparatus 1 includes a redundancy determination unit (second determination unit) 31 and a redundancy determination unit 32 as processing units for determining the selected “redundancy target VNF” as “redundancy execution VNF”.
  • the redundant route determination unit 37 is connected to a service chain controller request reception unit 38 outside the service chain design apparatus 1 in order to actually make the determined “redundancy execution VNF” redundant.
  • FIG. 2 is a configuration diagram of data related to the service chain handled by the service chain design apparatus 1.
  • Reference numeral 101 is a service chain D newly added to the service chain A to C of reference numeral 109 in FIG. These service chains A to D use five VNFs VNFs “F1” to “F5”.
  • the table T00 shows the number of accommodated users T02 of each service chain IDT01 of reference numeral 101 as in the table 209a of FIG. Looking at the service chain alone, it can be said that the service chain D that accommodates the largest number of users is the most influential service chain.
  • Tables T10, T20, and T30 indicate the status of the service chain focused on each VNF indicated by VNFIDT11, similarly to the table 209b of FIG. Similarly to the table 209b of FIG. 8, the accommodation service chain IDT12 and the accommodation number T20 (service number T21, user number T22) are associated with each VNFIDT11. Further, in FIG. 2, the performance value T30 (CPU usage rate with value 1 being 100%) for each VNFIDT 11 is also associated. Each of such tables T00, T10, T20, and T30 is obtained by the service chain generation request decomposition unit 12 disassembling each service chain received by the service chain generation request reception unit 11.
  • the redundancy target VNF determining unit 13 determines the VNF having the maximum service number T21 from the contents of the tables T00, T10, T20, and T30.
  • the highlighted VNF “F3” is the redundancy target VNF determining unit 14 Is determined as “redundancy target VNF”.
  • FIG. 3 is a configuration diagram of data after the VNF “F3” on the service chain B of FIG. 2 is made redundant.
  • Reference numeral 102 denotes a service chain B constructed on the physical network system of FIG. 7, similarly to the reference numeral 101 of FIG. 2. Comparing the code 101 and the code 102, the service chain B of the code 102 is located on the detour “N3 ⁇ N7 ⁇ N11 ⁇ VM6 ⁇ N11 ⁇ N7 ⁇ N3 ⁇ N1 ⁇ N2 ⁇ N4 ⁇ N8” from the start node N1.
  • the second VNF “F3” is made redundant.
  • Tables T11 and T40 are threshold values used for determining whether or not the redundancy determining unit 31 sets “redundancy target VNF” as “redundant execution VNF”.
  • the redundancy determination unit 31 determines that the redundancy target VNF “F3” is still the redundancy execution VNF. Judge not to do. On the other hand, when the number of service chains using the VNF “F3” further increases by 2 and satisfies “ ⁇ 5” of the service number T41 of the VNF “F3”, the redundancy determining unit 32 determines the redundancy target VNF. It is determined that “F3” is the redundancy execution VNF.
  • Tables T11 and T50 (the number of services T51, the number of users T52, and the performance value T53) are referred to in order to specifically calculate how the redundancy calculation unit 33 makes the redundancy execution VNF “F3” redundant.
  • redundancy 3 is determined. That is, in order to satisfy “2 ⁇ (2 or less)” of the number of services T51, five service chains are set so that the number of accommodation services of each VNF “F3” is “1, 2, 2”, respectively. What is necessary is just to disperse. In other words, by setting the threshold value T50 immediately after redundancy to a lower value than the redundancy determination threshold value T40, a margin is provided so that the second redundancy determination decision is not made immediately after the redundancy is made once. .
  • the VNF arrangement determining unit 35 determines the arrangement of two newly generated VNFs “F3”. Here, it is desirable to arrange a total of three VNFs “F3” including new and old on different physical servers.
  • a route (path) of a service chain that passes through the redundant route calculation unit 36 and two newly generated VNFs “F3” is also generated. For example, as indicated by reference numeral 102, the service chain B branches from the starting node N3 existing before the VNF “F3”, passes through the VM6 on the node N11 where the VNF “F3” exists, and passes through the service chain.
  • a route that merges with the node N8 on the end point side of B is newly calculated by the redundant route calculation unit.
  • the redundant route calculation unit 36 does not overlap each new route as much as possible so that only the start point side (N1) and the end point side (N8) overlap before and after branching. It is desirable to do.
  • the redundant route determination unit 37 receives the calculation result of the redundant route calculation unit 36 and instructs the service chain controller request reception unit 38 to set a new route.
  • the policy / threshold management DB 21 stores a redundancy determination threshold T40 for each VNFIDT 11 and a threshold T50 immediately after redundancy for each VNFIDT 11.
  • the “policy” is not directly stored in the DB, but “uses the number of services T41 for the determination of the redundancy determination unit 31” or “a combination of the number of users T42 and the performance value T43 to determine the redundancy determination unit. It is pre-set information such as “used for determination 31”.
  • the service chain configuration information DB 22 stores the components of each service chain for each service chain IDT01 as indicated by reference numeral 101 in FIG.
  • the accommodation information management DB 23 stores the accommodation user number T02, the VNFIDT11 accommodated in the service chain, and the accommodation number T20 as the accommodation information for each service chain IDT01.
  • the performance value collection DB 24 is measured for each VNFIDT 11, and as the collected performance value T30, the CPU usage rate illustrated in FIG. 2, the delay time not illustrated, the used bandwidth, the used memory, the number of used processes, the traffic transmission / reception amount, The processing speed or the like is stored as one or a plurality of combination values.
  • the redundancy target VNF management DB 25 stores the VNFIDT 11 (F3 in FIG. 2) that is the redundancy target and the accommodation service chain IDT 12.
  • the service chain generation request reception unit 11 receives a generation order for a new service chain.
  • the service chain generation request decomposition unit 12 performs an order content decomposition process received by the service chain generation request reception unit 11 and writes the result in the service chain configuration information DB 22 and the accommodation information management DB 23.
  • the redundancy target VNF determination unit 13 refers to each database and acquires data necessary to select the redundancy target VNF from all the VNFs.
  • the VNF information that configures the service chain is acquired from the service chain configuration information DB 22.
  • the policy information for determining the redundancy target VNF is acquired from the policy / threshold management DB 21.
  • the number of users / number of services accommodated in each service chain is acquired from the accommodation information management DB 23. -From the performance value collection DB 24, obtain the performance value information of the VNFs accommodated in each service chain.
  • the redundancy target VNF determination unit 13 selects a redundancy target VNF candidate by any of the methods listed below. Which method is used is specified by the acquired policy information.
  • Method 13 A VNF that provides a particularly important function as a service (eg, VNF that provides an emergency response service) is permitted to be a redundancy target VNF.
  • a VNF accommodating an important user is permitted to be a redundancy target VNF.
  • Method 15 In a service chain, a VNF existing in an important position is permitted to be a redundancy target VNF (details will be described later in FIG. 4).
  • Method 16 A VNF that consumes many resources in the previous stage is permitted to be a redundancy target VNF (details will be described later in FIG. 5).
  • the redundancy target VNF determination unit 14 determines the redundancy target VNF by using one or more results calculated by (Method 11) to (Method 16) of the redundancy target VNF determination unit 13 (details are shown in FIG. 6). (Postscript). Parameters such as the number of accommodated service chains and the number of accommodated users are parameters of importance for determining the redundancy target VNF.
  • the redundancy determination unit 31 determines whether or not the redundancy target VNF determined by the redundancy target VNF determination unit 14 is set as the redundancy execution VNF.
  • This determination process refers to the policy / threshold value management DB 21, the accommodation information management DB 23, and the performance value collection DB 24, and compares whether the current value (actual value) exceeds the threshold value for each threshold value of the determination criterion. It is processing to do.
  • the criteria are listed below.
  • the redundancy determining unit 32 determines whether or not the redundancy target VNF is to be a redundancy execution VNF based on the result of the redundancy determining unit 31 (whether or not one or more threshold values are exceeded). For example, the redundancy determination unit 32 determines redundancy if both threshold values of (reference 21) and (reference 22) are exceeded.
  • the redundancy calculation unit 33 divides the redundancy determination parameters (the number of serviced service chains, the number of accommodated users, and the performance value) to be equal to or less than an arbitrary threshold value, and newly generates VNFs for the divided values. Therefore, the redundancy calculation unit 33 refers to the policy / threshold management DB 21, the accommodation information management DB 23, and the performance value collection DB 24.
  • the redundancy determining unit 34 determines the number of new generations of the target VNF using the result (one or more redundancy) of the redundancy calculating unit 33. For example, consider a case where the number of newly generated target VNFs is 2 when focusing on the number of accommodation service chains, and the number of new generations is 3 when focusing on performance values.
  • the redundancy determination unit 34 employs the maximum number of 2 and 3, and finally determines the number of newly generated VNFs as 3.
  • the VNF arrangement determining unit 35 refers to the service chain configuration information DB 22 and the performance value collection DB 24 and arranges the newly generated VNF so that the redundant execution VNFs are arranged on different physical servers as much as possible. decide. As a result, even when one physical server fails, if any other physical server is alive, one of the redundancy execution VNFs continues to function, thereby improving the reliability.
  • the redundant route calculation unit 36 refers to the service chain configuration information DB 22 and the performance value collection DB 24 and calculates a redundant route based on the arrangement of each newly generated VNF determined by the VNF arrangement determination unit 35.
  • the redundant route calculation methods are listed below.
  • the redundant route calculation unit 36 calculates a redundant route using at least one of (Method 31) to (Method 33).
  • Methodhod 31 For each service chain, a new route between a server (or a start / end node) immediately before / immediately after the VNF to be made redundant and a server where the new VNF exists and a Dijkstra Calculate by law.
  • Methodhod 32 Already assigned paths are excluded from calculation in a plurality of redundant VNFs of the same type.
  • a route that is less shared is selected. In this way, by not causing the route overlap, it is possible to prevent the occurrence of service interruption due to the failure of both the working route and the standby route.
  • a load balancer such as vLB (virtual load balancer) is arranged immediately before the VNF to be made redundant.
  • a redundant route that passes through each of the plurality of redundant execution VNFs (existing VNF and new VNF) via the load balancer may be generated. However, in this case, even if the virtual paths are separated from each other, the physical paths are not necessarily separated.
  • the redundant route determination unit 37 determines the redundant route of the newly generated VNF using the result (one or more redundant routes) of the redundant route calculation unit 36.
  • the determined redundant route is added to the service chain configuration information DB 22.
  • the service chain controller request reception unit 38 receives the following setting information from the redundant route determination unit 37 and reflects the setting information on the physical network.
  • ⁇ VNFID of redundant execution VNF -Number of redundant execution VNFs-Redundant execution VNF placement destination physical server ID Information on New Redundant Route that Passes Redundant Execution VNF The details of each component of the service chain design apparatus 1 have been described above with reference to FIGS. 1 to 3.
  • FIGS. 4 to 6 a part of the processing of the redundancy target VNF determination unit 13 and the redundancy target VNF determination unit 14 will be supplementarily described.
  • FIG. 4 is an explanatory diagram illustrating a processing example of (Method 15) of the redundancy target VNF determination unit 13.
  • the redundancy target VNF determination unit 13 determines that the VNF existing at an important position in the service chain is the redundancy target VNF.
  • VNF existing in an important position is the following two types.
  • A The VNF located at the end of the service chain is a VNF existing in an important position.
  • F3 of the service chain A and “F2” of the service chain C are respectively positioned last.
  • (B) Weighting is performed according to the position of the VNF in the service chain (the weight as the importance is increased as the position is behind the chain), and the VNF having the largest weight is the VNF existing in the important position.
  • “F3” of service chain A is located behind “F2” of the same service chain A, so that the weight is 1.0 larger than 0.5 of “F2” of the front. Is set to Then, as shown in the table 203, a total value of weights in the entire service chain is obtained for each VNF, and “F3” having the maximum value of 1.66 is set as a VNF existing in an important position.
  • the reason for setting the weights as in (A) and (B) is as follows.
  • the service chain is processed by VNF in order (sequentially) from the start point of the route. For example, if the last VNF in the chain fails, it is necessary to start over from the very beginning. In other words, the processing performed in the previous stage of the route is wasted and is all redone. Therefore, the more the VNF is behind the chain, the more important (the redundancy target).
  • FIG. 5 is an explanatory diagram illustrating a processing example of (Method 16) of the redundancy target VNF determination unit 13.
  • the redundancy target VNF determination unit 13 determines, as (Method 16), the VNF that consumes many resources in the previous stage as the redundancy target VNF.
  • the VNF that consumes a lot of resources in the previous stage can be obtained as a VNF having the largest weight, for example, by weighting each VNF according to the ratio of the resources used in the previous stage processing.
  • “resource usage rate” for each VNF is seen as a material for determining whether or not the processing is heavy. This is because heavier processing is executed as the resource usage rate increases.
  • the redundancy target VNF determination unit 13 uses the weight of the entire service chain as described in (Method 15) of FIG. 4 for the weight of each resource usage rate obtained in (Method 16) of FIG.
  • the VNF having the maximum total value may be set as the redundancy target VNF.
  • FIG. 6 is an explanatory diagram illustrating a processing example of the redundancy target VNF determination unit 14.
  • the redundancy target VNF determining unit 14 may determine the redundancy target VNF by combining two or more results calculated by (Method 11) to (Method 16) of the redundancy target VNF determining unit 13. Specific examples will be described below.
  • the table 205 has a large number of users for determining the VNF (method 12) having the maximum number of accommodated users for each VNF (that is, the number of users T22 in the accommodated number T20 shown in FIG. 2).
  • the resource usage rate for determining the VNF (method 16) that is consuming this resource is extracted. First, as described in FIG.
  • the service chain design apparatus 1 individually multiplexes particularly important VNFs that affect a large number of users as redundancy target VNFs, thereby improving the reliability of the entire service chain. Can be further enhanced. Furthermore, higher reliability can be secured by using the redundancy in the service chain as in the comparative example and the redundancy in the important VNF unit of the present embodiment in combination.
  • the redundancy target VNF determination unit 13, the redundancy target VNF determination unit 14, the redundancy determination unit 31, and the redundancy determination unit 32 are prepared as individual functional units, respectively.
  • a configuration is shown in which a VNF to be made redundant is first determined, then various threshold values of the target VNF are observed, and redundancy is made.
  • the redundancy target VNF determination unit 13, the redundancy target VNF determination unit 14, the redundancy determination unit 31, and the redundancy determination unit 32 are mounted in the service chain design apparatus 1 as one functional unit. May be.
  • the service chain design apparatus 1 operates so as to determine the redundancy target VNF while observing various threshold values of all operating VNFs and simultaneously perform redundancy.
  • the service chain design apparatus 1 handles four types of service chains A to D as shown in FIG. 2, but is not limited to these numbers and configurations.
  • hardware resources of a general computer can be realized by a program that operates as each unit of the service chain design apparatus 1.
  • the program can be distributed via a communication line, or can be recorded on a recording medium such as a CD-ROM for distribution.
  • Service chain design apparatus 11 Service chain generation request reception part 12 Service chain generation request decomposition part 13 Redundancy object VNF determination part (1st determination part) 14 Redundancy Target VNF Determination Unit 21 Policy / Threshold Management DB 22 Service chain configuration information DB 23 Accommodation information management DB 24 Performance value collection DB 25 VNF management DB for redundancy 31 Redundancy determination unit (second determination unit) 32 Redundancy determination unit 33 Redundancy calculation unit 34 Redundancy determination unit 35 VNF placement determination unit (placement determination unit) 36 Redundant route calculation unit 37 Redundant route determination unit 38 Service chain controller request reception unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Hardware Redundancy (AREA)

Abstract

【課題】サービスチェイン全体の信頼性を高めつつ、コストの効率もよい仮想ネットワーク機能の冗長化構成を設計すること。 【解決手段】サービスチェイン設計装置１は、ＶＮＦを利用するサービスチェインの数、および、ＶＮＦを利用するサービスチェインが収容するユーザの数のうちの少なくとも１つをＶＮＦごとの重要度とし、その重要度が大きいＶＮＦを冗長化対象ＶＮＦと判定する冗長化対象ＶＮＦ判定部１３と、冗長化対象ＶＮＦ判定部１３が判定した冗長化対象ＶＮＦの重要度が所定閾値を超過したときに、その超過した冗長化対象ＶＮＦを冗長化実行ＶＮＦと判定する冗長化判定部３１とを有する。

Description

サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラム
　本発明は、サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラムに関する。
　システムに障害が発生するまえに予備の計算機をあらかじめ用意しておき、障害発生時には予備の計算機に処理を切り替える手法は、冗長化と呼ばれる。この冗長化により耐障害性に優れた信頼性の高いシステムを提供できる。サービスの信頼性を高める方法として、サービスの構成要素（経路、各種装置、アプリケーション等）を２重化するなどの冗長構成が採用される。
　特許文献１には、ネットワーク全体を複数に分割したサブネットワーク内の冗長通信経路の設計をする際に、冗長化された複数の経路候補のうち、ファイバ重複、ノード重複、管路重複などのハードウェア資源を共用するような経路候補をなるべく用いない通信経路出力手段が記載されている。
特開２０１４－１５０４４１号公報
　既存のネットワークサービスにおいて、各種ネットワーク機能は物理装置（アプライアンス）で提供されていた。そのため、ネットワーク機能の提供元となる物理装置が固定されてしまい、柔軟性に欠けていた。そこで、物理装置を用いて仮想装置（ＶＭ：Virtual Machine）を構築する仮想化技術を、ネットワーク資源にも適用する試みが普及しつつある。
　ＮＦＶ（Network Function Virtualization）は、各種ネットワーク機能を仮想装置（ソフトウェア）で提供する仮想化技術である。仮想装置によりネットワーク機能の配置に柔軟性が生まれることで、ユーザごとの個別の要望に柔軟に対応することができる。
　ＮＦＶ技術により仮想化されたネットワーク機能は、ＶＮＦ（Virtualized Network Function）と呼ばれる。ＶＮＦは、例えば、vCPE（Virtualized Customer Premises Equipment）、vRouter、vMitigator、vFW（Virtualized Firewall）、vLB（Virtualized Load Balancer）、vDPI（Virtualized deep packet inspection）である。
　ＶＮＦをユーザごとに柔軟に選択・利用可能とする技術を、サービスチェイニングという。サービスチェイニングによって提供される一連のサービスをサービスチェインという。
　サービスチェインによって、専用アプライアンスで提供されていたネットワーク機能を仮想化基盤上のソフトウェア（仮想マシン）群で実現することができる。つまり、NFV技術によって、ネットワーク機器をソフトウェアとハードウェアとに分離し、汎用サーバで構成された仮想化基盤上で実現したネットワーク機能群を、サービスチェイニングによって数珠つなぎにすることで1つのサービスとして提供する。
　図７は、サービスチェインの説明図である。
　まず、物理資源のアプライアンスとして、各物理ノード［N1,…,N11］が、各物理リンク［L1,…,L14］で接続される物理的なネットワークシステムが構築されている。例えば、物理ノードN4と物理ノードN8とは、物理リンクL8で接続される。
　この物理ノード上に仮想ノード［VM1,…,VM6］が形成され、その仮想ノード上でVNF［F1,…,F4］が動作しているとする。例えば、仮想ノードVM1上にはVNFのF1が動作している。
　さらに、１つ以上のVNFは、サービスチェイン[A,B,C]によってそれぞれ束ねられている。ここで、各サービスチェインが利用するVNFには、アクセスが混んでいて負荷の高いVNFと、アクセスが空いていて負荷の低いVNFとでばらつきが発生する。以下、各サービスチェインが利用するVNFの詳細について、図８を参照して説明する。
　図８は、図７の物理的なネットワークシステム上に構築されたサービスチェインの詳細な説明図である。
　符号１０９は、図７の各サービスチェイン[A,B,C]が始点から終点までに通過する物理資源、仮想資源を順に辿った経路を示す。
　サービスチェインＡは、始点の物理ノードN1から、VM3上のVNF「F2」と、終点のVM5上のVNF「F3」とを利用する。
　サービスチェインＢは、始点の物理ノードN1から、VM5上のVNF「F3」と、終点のVM1上のVNF「F1」とを利用する。
　サービスチェインＣは、始点の物理ノードN3から、VM6上のVNF「F4」と、VM5上のVNF「F3」と、終点のVM3上のVNF「F2」とを利用する。
　つまり、VNF「F3」は３つのサービスチェインＡ～Ｃに使用され、VNF「F2」は２つのサービスチェインＡ，Ｃに使用され、VNF「F1」はサービスチェインＢだけに使用され、VNF「F4」はサービスチェインＣだけに使用される。
　また、テーブル２０９ａは、サービスチェインごとの収容ユーザ数を示すものであり、サービスチェインＡが最大の100人のユーザを収容している。そして、テーブル２０９ｂは、VNFIDで示されるVNFごとに着目したサービスチェインの状況を示す。符号１０９の説明で前記したように、VNF「F3」は３つのサービスチェインＡ～Ｃに使用され（つまり、サービス数＝３）、これらのサービスチェインのユーザ数の総和（＝１８０）が最大なので、故障時の影響度が他のVNFよりも大きいものとなっている（図示ではハッチングで強調）。
　ここで、ネットワークの冗長設計の話題に戻る。特許文献１などで示唆されているように、信頼性の観点では、ネットワークを複数の経路で冗長化するときには、なるべく多くの物理資源を用意することで、共通に用いる物理資源を少なくすることが好ましい。なぜなら、共通に用いる物理資源が障害によりダウンしてしまうと、その物理資源を用いる冗長経路の全てが同時に利用不可能となってしまい、障害発生後の切替対象から外れてしまうからである。
　一方で、ネットワーク運営者の観点からは、ネットワークの冗長設計において、予備として用意する冗長化用の物理資源は、そのまま平常時には遊休資源となってしまうため、リソースの無駄使いになってしまう。よって、コストの観点では、なるべく冗長化用の物理資源が少ない方が好ましい。
　以上、信頼性の観点と、コストの観点とを統合的に考えると、ネットワークの冗長設計においては、故障時の影響度が高い重要な箇所は手厚く冗長化を行うことで信頼性を確保しつつ、故障時の影響度が少ない箇所は冗長化の度合いを下げることでコストを節約するような、メリハリの取れたバランスのよい設計が求められる。
　例えば、図７，図８のようなサービスチェインの構成では、故障時に多くのユーザに影響を与える（つまり、サービスを中断させてしまい、多くのユーザに待ち時間の不便を強いてしまう）VNF「F3」を他のVNFよりも優先して冗長化を手厚くすることが望ましい。
　そこで、本発明は、サービスチェイン全体の信頼性を高めつつ、コストの効率もよい仮想ネットワーク機能の冗長化構成を設計することを、主な課題とする。
　前記課題を解決するために、本発明のサービスチェイン設計装置は、以下の特徴を有する。
　本発明は、ＶＮＦを利用するサービスチェインの数、および、ＶＮＦを利用するサービスチェインが収容するユーザの数のうちの少なくとも１つをＶＮＦごとの重要度とし、その重要度が大きいＶＮＦを冗長化対象ＶＮＦと判定する第１判定部と、
　前記第１判定部が判定した前記冗長化対象ＶＮＦの重要度が所定閾値を超過したときに、その超過した前記冗長化対象ＶＮＦを冗長化実行ＶＮＦと判定する第２判定部と、
　前記第２判定部が判定した前記冗長化実行ＶＮＦに対して、その重要度が所定閾値を下回るように、前記冗長化実行ＶＮＦを利用するサービスチェインの負荷分散先となる新たな前記冗長化実行ＶＮＦの生成数を計算する冗長度計算部とを有することを特徴とする。
　これにより、ＶＮＦを利用するサービスチェインの数や、ＶＮＦが収容するユーザの数という、直接的にサービスやユーザに影響するパラメータを重要度として冗長化対象ＶＮＦを選択することで、信頼性の高いサービスチェインの設計が可能となる。さらに、重要なＶＮＦを冗長化対象ＶＮＦとして絞り込むことで、コストの効率もよい仮想ネットワーク機能の冗長化構成を設計することができる。
　本発明は、前記第１判定部が、前記サービスチェインの数、および、前記収容するユーザの数に加えて、サービスチェイン内におけるＶＮＦの位置がルートの後方であるほど高い重要度とする重み、および、サービスチェイン内における前段で多くのリソースを消費しているＶＮＦほど高い重要度とする重みの少なくとも１つをＶＮＦごとの重要度とすることを特徴とする。
　これにより、ルートの後方であるほど高い重要度とする重みが選択された場合には、サービスチェインのルート後方になるほど冗長化されやすくなるので、ＶＮＦの障害発生によるサービスチェイン始点からの処理のやり直しの影響を低減できる。
　また、前段で多くのリソースを消費しているＶＮＦほど高い重要度とする重みが選択された場合でも、ＶＮＦの障害発生によるサービスチェイン始点からの処理のやり直しの影響を低減できる。
　本発明は、前記第１判定部が、前記サービスチェインの数、および、前記収容するユーザの数に加えて、前記ＶＮＦが提供するサービス内容の重み、および、サービスチェインが収容するユーザの重みのうちの少なくとも１つの重みをもとに、ＶＮＦごとの重要度を計算することを特徴とする。
　これにより、サービス内容の重みやユーザの重みが選択された場合には、重要なサービスや重要なユーザをかかえるＶＮＦが優先的に冗長化されるので、ユーザの満足度を高めることができる。
　本発明は、前記第２判定部が、ＶＮＦの性能値の測定データをもとに、前記冗長化対象ＶＮＦの重要度が所定閾値を超過したか否かを判定することを特徴とする。
　これにより、変動するＶＮＦの負荷が高くなったＶＮＦが優先的に冗長化されるので、より実用的な信頼性設計が可能となる。
　本発明は、前記サービスチェイン設計装置が、さらに、配置決定部と、冗長ルート決定部とを有しており、
　前記配置決定部が、複数の前記冗長化実行ＶＮＦの配置先がそれぞれ異なる物理サーバ上になるように、前記冗長度計算部が計算した生成数分の新たな前記冗長化実行ＶＮＦの配置先を決定し、
　前記冗長ルート決定部が、各サービスチェインの冗長ルート同士で重複する経路が少なくなるように、前記配置決定部が決定した各配置先を通過する各冗長ルートを決定することを特徴とする。
　これにより、複数のＶＮＦ間や、複数の冗長ルート間で重複するハードウェア資源を減らすことにより、１つのハードウェア資源が故障しても、生存するＶＮＦや生存する冗長ルートを多く確保し、信頼性の高い設計が可能となる。
　本発明は、前記サービスチェイン設計装置が、さらに、配置決定部と、冗長ルート決定部とを有しており、
　前記配置決定部が、複数の前記冗長化実行ＶＮＦの配置先がそれぞれ異なる物理サーバ上になるように、前記冗長度計算部が計算した生成数分の新たな前記冗長化実行ＶＮＦの配置先を決定し、
　前記冗長ルート決定部が、前記配置決定部が決定した前記冗長化実行ＶＮＦの配置先の冗長ルートにおける直前の位置にロードバランサを配置し、そのロードバランサを経由して複数の前記冗長化実行ＶＮＦそれぞれを通過する冗長ルートを決定することを特徴とする。
　これにより、設定変更の対象となる装置が少なくなるため、業務が容易となり、当該設定変更による他サービスへの影響リスクも低減することができる。
　本発明によれば、サービスチェイン全体の信頼性を高めつつ、コストの効率もよい仮想ネットワーク機能の冗長化構成を設計することができる。
本実施形態に係わるサービスチェイン設計装置の構成図である。 本実施形態に係わるサービスチェイン設計装置が扱うサービスチェインに関するデータの構成図である。 本実施形態に係わる図２のサービスチェインＢ上のＶＮＦが冗長化された後のデータの構成図である。 本実施形態に係わる冗長化対象ＶＮＦ判定部の処理例を示す説明図である。 本実施形態に係わる冗長化対象ＶＮＦ判定部の処理例を示す説明図である。 本実施形態に係わる冗長化対象ＶＮＦ決定部の処理例を示す説明図である。 サービスチェインの説明図である。 図７の物理的なネットワークシステム上に構築されたサービスチェインの詳細な説明図である。
　以下、本発明の一実施形態について、図面を参照して詳細に説明する。
　図１は、サービスチェイン設計装置１の構成図である。
　サービスチェイン設計装置１は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
　このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。
　サービスチェイン設計装置１が扱うサービスチェインに含まれるＶＮＦについて、以下のように定義する。
　まず、サービスチェイン設計装置１は、物理的なネットワークシステム上で動作する全ＶＮＦのうち、故障時に多くのユーザに影響を与える重要なＶＮＦを「冗長化対象ＶＮＦ」として指定する。例えば、図８のVNF「F3」は、冗長化対象ＶＮＦの一例である。
　次に、サービスチェイン設計装置１は、「冗長化対象ＶＮＦ」に対して所定の基準を満たしたときに、その冗長化対象ＶＮＦを実際に冗長化するＶＮＦ（以下「冗長化実行ＶＮＦ」）として決定する。つまり、「全ＶＮＦ→冗長化対象ＶＮＦ→冗長化実行ＶＮＦ」という段階を経て実際に冗長化するＶＮＦが決定される。換言すると、冗長化対象ＶＮＦに選出されただけでは、まだ実際に冗長化するＶＮＦか否かは未確定の状態である。
　サービスチェイン設計装置１は、各種データを格納するデータベースとして、ポリシー／閾値管理ＤＢ２１と、サービスチェイン構成情報ＤＢ２２と、収容情報管理ＤＢ２３と、性能値収集ＤＢ２４と、冗長化対象ＶＮＦ管理ＤＢ２５とを有する。
　サービスチェイン設計装置１は、「冗長化対象ＶＮＦ」を選出するための処理部として、サービスチェイン生成要求受付部１１と、サービスチェイン生成要求分解部１２と、冗長化対象ＶＮＦ判定部（第１判定部）１３と、冗長化対象ＶＮＦ決定部１４とを有する。
　サービスチェイン設計装置１は、選出された「冗長化対象ＶＮＦ」を「冗長化実行ＶＮＦ」として決定するための処理部として、冗長化判定部（第２判定部）３１と、冗長化決定部３２と、冗長度計算部３３と、冗長度決定部３４と、ＶＮＦ配置決定部３５と、冗長ルート計算部３６と、冗長ルート決定部３７とを有する。
　さらに、冗長ルート決定部３７は、決定された「冗長化実行ＶＮＦ」を実際に冗長化するために、サービスチェイン設計装置１外部のサービスチェインコントローラ要求受付部３８と接続される。
　以下、図２，図３の具体例を元に、これらのサービスチェイン設計装置１の各構成要素を明らかにする。
　図２は、サービスチェイン設計装置１が扱うサービスチェインに関するデータの構成図である。
　符号１０１は、図８の符号１０９のサービスチェインＡ～Ｃに対して、新たにサービスチェインＤを追加したものである。これらのサービスチェインＡ～Ｄは、VNF「F1」～「F5」という５つのＶＮＦを利用する。
　テーブルＴ００は、図８のテーブル２０９ａと同様に、符号１０１の各サービスチェインＩＤＴ０１の収容ユーザ数Ｔ０２を示す。サービスチェイン単体でみると、最大のユーザ数200人を収容するサービスチェインＤが最も影響力の高いサービスチェインであるといえる。
　テーブルＴ１０，Ｔ２０，Ｔ３０は、図８のテーブル２０９ｂと同様に、ＶＮＦＩＤＴ１１で示されるＶＮＦごとに着目したサービスチェインの状況を示す。図８のテーブル２０９ｂと同様に、収容サービスチェインＩＤＴ１２と、収容数Ｔ２０（サービス数Ｔ２１、ユーザ数Ｔ２２）とが、ＶＮＦＩＤＴ１１ごとに対応づけられている。さらに、図２では、ＶＮＦＩＤＴ１１ごとの性能値Ｔ３０（値１を100%とするＣＰＵ使用率）も、対応づけられている。
　このような各テーブルＴ００，Ｔ１０，Ｔ２０，Ｔ３０は、サービスチェイン生成要求受付部１１が受け付けた各サービスチェインを、サービスチェイン生成要求分解部１２が分解して求めたものである。
　そして、各テーブルＴ００，Ｔ１０，Ｔ２０，Ｔ３０の内容を冗長化対象ＶＮＦ判定部１３がサービス数Ｔ２１が最大であるＶＮＦを判定した結果、強調図示したVNF「F3」が冗長化対象ＶＮＦ決定部１４により「冗長化対象ＶＮＦ」として決定される。
　図３は、図２のサービスチェインＢ上のVNF「F3」が冗長化された後のデータの構成図である。
　符号１０２は、図２の符号１０１と同様に、図７の物理的なネットワークシステム上に構築されたサービスチェインＢを示す。
　符号１０１と符号１０２とを比較すると、符号１０２のサービスチェインＢは、始点ノードN1からの迂回路「N3→N7→N11→VM6→N11→N7→N3→N1→N2→N4→N8」上に、２つめのVNF「F3」が冗長化されている。
　テーブルＴ１１，Ｔ４０（サービス数Ｔ４１、ユーザ数Ｔ４２、性能値Ｔ４３）は、冗長化判定部３１が「冗長化対象ＶＮＦ」を「冗長化実行ＶＮＦ」とするか否かを判定に使用される閾値をＶＮＦＩＤＴ１１ごとに対応づけたものである。例えば、サービス数Ｔ４１の「≧５（５以上）」とは、図２のサービス数Ｔ２１が５以上になったときに、「冗長化対象ＶＮＦ」を「冗長化実行ＶＮＦ」とする旨を示している。
　つまり、図２の段階ではサービス数Ｔ２１＝３なので、サービス数Ｔ４１の「≧５」を満たさないので、冗長化判定部３１は、冗長化対象ＶＮＦ「F3」は、まだ冗長化実行ＶＮＦとはしない旨を判定する。一方、VNF「F3」を利用するサービスチェイン数がさらに２つ増加し、VNF「F3」のサービス数Ｔ４１の「≧５」を満たすようになったら、冗長化決定部３２は、冗長化対象ＶＮＦ「F3」を冗長化実行ＶＮＦとする旨を決定する。
　テーブルＴ１１，Ｔ５０（サービス数Ｔ５１、ユーザ数Ｔ５２、性能値Ｔ５３）は、冗長度計算部３３が冗長化実行ＶＮＦ「F3」をどのように冗長化するかを具体的に計算するために参照される。例えば、強調図示したサービス数Ｔ５１の「２≦（２以下）」とは、冗長化実行ＶＮＦ「F3」を冗長化することにより、１つの箇所のVNF「F3」あたり、そのF3を利用するサービスチェイン数が２以下の状態になるようにする旨を示す。
　よって、冗長度決定部３４は、冗長化前はサービスチェイン数「５」を収容していた１箇所のVNF「F3」を、新規に２つ生成して合計３箇所のVNF「F3」が存在するように、つまり、合計３箇所なので冗長度＝３を決定する。つまり、サービス数Ｔ５１の「２≦（２以下）」を満たすため、それぞれのVNF「F3」の収容サービス数がそれぞれ「１つ、２つ、２つ」になるように、５つのサービスチェインを分散させればよい。
　つまり、冗長化決定閾値Ｔ４０よりも冗長化直後の閾値Ｔ５０を低い値とすることで、１回冗長化した後、すぐに２度目の冗長化決定の判定がおりないように余裕をもたせている。
　ＶＮＦ配置決定部３５は、新規に２つ生成するVNF「F3」の配置を決定する。ここで、新旧含め、合計３つのVNF「F3」は、全て異なる物理サーバ上に配置することが望ましい。
　冗長ルート計算部３６と、新規に２つ生成するVNF「F3」を通過するサービスチェインのルート（経路）も新規に生成する。例えば、符号１０２で示したように、サービスチェインＢにおいては、VNF「F3」の前に存在する始点ノードN3から分岐し、VNF「F3」が存在するノードN11上のVM6を通過し、サービスチェインＢの終点側のノードN8に合流するルートが、冗長ルート計算部３６によって新規に計算される。
　ここで、冗長ルート計算部３６は、符号１０２の例では、始点側（N1）と終点側（N8）だけが分岐前後で重複しているように、各新規経路は可能な限り重複させないようにすることが望ましい。
　冗長ルート決定部３７は、冗長ルート計算部３６の計算結果を受け、サービスチェインコントローラ要求受付部３８に対して新規経路を設定するように指示する。
　以上、図２，図３を参照して、サービスチェイン設計装置１の各処理部の具体例を用いた説明を行った。
　以下では、サービスチェイン設計装置１の各処理部および各データベースの内容について、一般化した説明を行う。まず、符号２１～２５で示す各データベースが、格納するデータ内容について、図２，図３で説明したテーブルＴ００～Ｔ５０を参照しつつ説明する。
　ポリシー／閾値管理ＤＢ２１は、ＶＮＦＩＤＴ１１ごとの冗長化決定閾値Ｔ４０と、ＶＮＦＩＤＴ１１ごとの冗長化直後の閾値Ｔ５０とを格納する。ここで「ポリシー」とは、ＤＢには直接格納されていないが、「サービス数Ｔ４１を冗長化判定部３１の判定に用いる」もしくは、「ユーザ数Ｔ４２および性能値Ｔ４３を組み合わせて冗長化判定部３１の判定に用いる」などの事前設定情報である。
　サービスチェイン構成情報ＤＢ２２は、図２の符号１０１で示したような、サービスチェインＩＤＴ０１ごとの各サービスチェインの構成要素を格納する。例えば、サービスチェインＡの構成要素「N1→L1→N2→L4→N5→L10→N9→VL3→VM3→F2(T11)→VL3→N9→L11→N6→L12→N10→VL5→VM5→F3(T11)」が、サービスチェイン構成情報ＤＢ２２に格納される。
　収容情報管理ＤＢ２３は、サービスチェインＩＤＴ０１ごとの収容情報として、収容ユーザ数Ｔ０２、当該サービスチェインに収容されるＶＮＦＩＤＴ１１、および、収容数Ｔ２０を格納する。
　性能値収集ＤＢ２４は、ＶＮＦＩＤＴ１１ごとに測定され、収集された性能値Ｔ３０として、図２に例示したＣＰＵ使用率や、図示省略した遅延時間、使用帯域、使用メモリ、使用プロセス数、トラヒック送受信量、処理速度などを１つまたは複数の組み合わせ値として格納する。
　冗長化対象ＶＮＦ管理ＤＢ２５は、冗長化対象となったＶＮＦＩＤＴ１１（図２では、Ｆ３）と、その収容サービスチェインＩＤＴ１２とを格納する。
　次に、符号２１～２５で示す各データベースを用いて、各処理部の動作を説明する。
　サービスチェイン生成要求受付部１１は、新規サービスチェインの生成オーダを受け付ける。
　サービスチェイン生成要求分解部１２は、サービスチェイン生成要求受付部１１が受け付けたオーダ内容の分解処理を行い、その結果をサービスチェイン構成情報ＤＢ２２、および、収容情報管理ＤＢ２３に書き出す。
　冗長化対象ＶＮＦ判定部１３は、以下に示すように、各データベースを参照して、全ＶＮＦから冗長化対象ＶＮＦを選択するために必要なデータを取得する。
　・サービスチェイン構成情報ＤＢ２２から、サービスチェインを構成するＶＮＦ情報を取得する。
　・ポリシー／閾値管理ＤＢ２１から、冗長化対象ＶＮＦを決定するポリシー情報を取得する。
　・収容情報管理ＤＢ２３から、各サービスチェインに収容されているユーザ数／サービス数などを取得する。
　・性能値収集ＤＢ２４から、各サービスチェインに収容されているＶＮＦの性能値情報を取得する。
　そして、冗長化対象ＶＮＦ判定部１３は、以下に列挙する手法のいずれかにより、冗長化対象ＶＮＦの候補を選択する。どの手法を用いるかは、取得したポリシー情報で指定される。
　（手法１１）収容サービスチェイン数（＝重要度）が最大であるＶＮＦを、冗長化対象ＶＮＦとすることを許可する。
　（手法１２）収容ユーザ数（＝重要度）が最大であるＶＮＦを、冗長化対象ＶＮＦとすることを許可する。
　（手法１３）特に重要な機能をサービスとして提供しているＶＮＦ（例：緊急対応用サービスを提供するＶＮＦなど）を、冗長化対象ＶＮＦとすることを許可する。
　（手法１４）重要ユーザを収容しているＶＮＦを、冗長化対象ＶＮＦとすることを許可する。
　（手法１５）サービスチェインにおいて、重要なポジションに存在するＶＮＦを、冗長化対象ＶＮＦとすることを許可する（詳細は図４で後記）。
　（手法１６）前段で多くのリソースを消費しているＶＮＦを、冗長化対象ＶＮＦとすることを許可する（詳細は図５で後記）。
　冗長化対象ＶＮＦ決定部１４は、冗長化対象ＶＮＦ判定部１３の（手法１１）～（手法１６）で算出した結果を１つ以上用いて、冗長化対象ＶＮＦを決定する（詳細は図６で後記）。
　なお、収容サービスチェイン数、収容ユーザ数などのパラメータは、冗長化対象ＶＮＦを決定するための重要度のパラメータである。
　冗長化判定部３１は、冗長化対象ＶＮＦ決定部１４により決定された冗長化対象ＶＮＦを、冗長化実行ＶＮＦとするか否かを判定する。この判定処理は、ポリシー／閾値管理ＤＢ２１、収容情報管理ＤＢ２３、および、性能値収集ＤＢ２４を参照して、現在値（実測値）が閾値を超過しているかどうかを、判定基準の閾値ごとに比較する処理である。以下に、判定基準を列挙する。
　（基準２１）収容サービスチェイン数（＝重要度）が任意の閾値を超えた場合に、冗長化実行ＶＮＦとすることを許可する。
　（基準２２）収容ユーザ数（＝重要度）が任意の閾値を超えた場合に、冗長化実行ＶＮＦとすることを許可する。
　（基準２３）性能値（＝重要度）が任意の閾値を超えた場合に、冗長化実行ＶＮＦとすることを許可する。
　冗長化決定部３２は、冗長化判定部３１の結果（１つ以上の閾値超過の可否）をもって、最終的に冗長化対象ＶＮＦを冗長化実行ＶＮＦとするか否かを決定する。冗長化決定部３２は、例えば、（基準２１）および（基準２２）それぞれの閾値が共に超過していたら冗長化を決定する。
　冗長度計算部３３は、冗長化判断のパラメータ（収容サービスチェイン数、収容ユーザ数、性能値）が、任意の閾値以下になるように分割し、分割した分のＶＮＦを新規に生成する。そのため、冗長度計算部３３は、ポリシー／閾値管理ＤＢ２１、収容情報管理ＤＢ２３、および、性能値収集ＤＢ２４を参照する。
　冗長度決定部３４は、冗長度計算部３３の結果（１つ以上の冗長度）を用いて、対象ＶＮＦの新規生成数を決定する。例えば、収容サービスチェイン数に着目した場合は対象ＶＮＦの新規生成数は２となり、性能値に着目した場合は新規生成数が３となるような場合を考える。冗長度決定部３４は、２と３との最大数を採用し、最終的にはＶＮＦの新規生成数を３と決定する。
　ＶＮＦ配置決定部３５は、サービスチェイン構成情報ＤＢ２２および性能値収集ＤＢ２４を参照して、冗長化実行ＶＮＦがそれぞれ可能な限り別々の物理サーバ上に配置されるように、新規生成したＶＮＦの配置を決定する。これにより、１つの物理サーバが故障した場合でも、他の物理サーバが生存していれば、いずれかの冗長化実行ＶＮＦが機能し続けることで、信頼性を高めることができる。
　冗長ルート計算部３６は、サービスチェイン構成情報ＤＢ２２および性能値収集ＤＢ２４を参照して、ＶＮＦ配置決定部３５が決定した各新規生成ＶＮＦの配置をもとに、冗長ルートを計算する。以下に、冗長ルートの計算手法を列挙する。冗長ルート計算部３６は、（手法３１）～（手法３３）のうちの少なくとも１つを用いて、冗長ルートを計算する。
　（手法３１）サービスチェインごとに、冗長化対象となるＶＮＦの直前／直後のＶＮＦが存在するサーバ（もしくは、始点／終点ノード）と、新規ＶＮＦが存在するサーバとの間の新規経路を、ダイクストラ法などで算出する。
　（手法３２）冗長化された複数の同種ＶＮＦにおいて、既に割り当てられている経路は計算の対象外とする。もしくは、より共有されていない経路を選択する。このように、経路重複を発生させないことで、現用系および予備系の経路双方が故障することによるサービス断の発生を予防することができる。
　（手法３３）冗長化対象となるＶＮＦの直前にｖＬＢ（virtual Load Balancer）などのロードバランサを配置する。そのロードバランサを経由して複数の冗長化実行ＶＮＦ（既存ＶＮＦおよび新規ＶＮＦ）それぞれを通過する冗長ルートを生成してもよい。ただし、この場合、仮想経路は互いに分離されていても、物理経路が分離されているとは限らない。
　冗長ルート決定部３７は、冗長ルート計算部３６の結果（１つ以上の冗長ルート）を用いて、新規生成したＶＮＦの冗長ルートを決定する。決定された冗長ルートは、サービスチェイン構成情報ＤＢ２２に追加される。
　サービスチェインコントローラ要求受付部３８は、冗長ルート決定部３７から以下の設定情報を受け取り、その設定情報を物理ネットワークに反映させる。
　・冗長化実行ＶＮＦのＶＮＦＩＤ
　・冗長化実行ＶＮＦの生成数
　・冗長化実行ＶＮＦの配置先の物理サーバＩＤ
　・冗長化実行ＶＮＦを通過する新規の冗長ルートの情報
　以上、図１～図３を参照して、サービスチェイン設計装置１の各構成要素の詳細を説明した。以下、図４～図６を参照して、冗長化対象ＶＮＦ判定部１３および冗長化対象ＶＮＦ決定部１４の一部の処理を補足説明する。
　図４は、冗長化対象ＶＮＦ判定部１３の（手法１５）の処理例を示す説明図である。
　冗長化対象ＶＮＦ判定部１３は、（手法１５）として、サービスチェインにおいて、重要なポジションに存在するＶＮＦを、冗長化対象ＶＮＦとすることとした。ここで、「重要なポジションに存在するＶＮＦ」とは、以下の２通りである。
　（Ａ）サービスチェインの最後に位置するＶＮＦが、重要なポジションに存在するＶＮＦである。符号１０３の例では、サービスチェインＡの「Ｆ３」と、サービスチェインＣの「Ｆ２」とが、それぞれ一番最後に位置する。
　（Ｂ）サービスチェインにおけるＶＮＦの位置によって重み付けし（チェインの後方に位置するほど、重要度としての重みを大きくし）、一番重みの大きいＶＮＦが、重要なポジションに存在するＶＮＦである。符号１０３の例では、サービスチェインＡの「Ｆ３」は、同じサービスチェインＡの「Ｆ２」よりも後方に位置しているので、重みが前方の「Ｆ２」の０．５よりも大きい１．０に設定されている。そして、テーブル２０３に示すように、サービスチェイン全体での重みの合計値をＶＮＦごとに求め、その最大値１．６６となる「Ｆ３」を、重要なポジションに存在するＶＮＦとする。
　なお、（Ａ）や（Ｂ）のように重みを設定した理由は、次の通りである。サービスチェインは、ルートの始点から順番に（シーケンシャルに）、ＶＮＦで処理される。例えば、チェインの最後のＶＮＦが故障した場合、一番最初から処理をやり直す必要がある。つまり、ルートの前段で実施した処理は無駄となり、全てやり直しとなってしまう。従って、チェインの後方のＶＮＦになればなるほど、重要（冗長化対象）となるようにした。
　図５は、冗長化対象ＶＮＦ判定部１３の（手法１６）の処理例を示す説明図である。
　冗長化対象ＶＮＦ判定部１３は、（手法１６）として、前段で多くのリソースを消費しているＶＮＦを、冗長化対象ＶＮＦとすることとした。前段で多くのリソースを消費しているＶＮＦは、例えば、ＶＮＦごとに、前段処理で使用しているリソースの割合によって重み付けし、一番重みの大きいＶＮＦとして求めることができる。
　図５の例では、テーブル２０４に示すように、重い処理か否かを判断する材料として、ＶＮＦごとの「リソース使用率」をみる。リソース使用率が大きい程、より重い処理を実行しているためである。
　そして、符号１０４の例では、サービスチェインＡの「Ｆ２」は、テーブル２０４を参照するとリソース使用率＝０．７である。そして、（自身のＶＮＦの重み）＝（サービスチェインにおける前段のリソース使用率）＋（自身のリソース使用率）という累積和の計算により、冗長化対象ＶＮＦ判定部１３は、各ＶＮＦの重みを求める。つまり、図４の（手法１５）と同様に、チェインの後方のＶＮＦになればなるほど、重要度としての重みを増加させた。
　サービスチェインＡの「Ｆ２」の重み＝（自身のリソース使用率＝０．７）となり、
　サービスチェインＡの「Ｆ３」の重み＝（前段のリソース使用率＝０．７）＋（自身のリソース使用率＝０．８）＝１．５となる。
　同様に、冗長化対象ＶＮＦ判定部１３は、サービスチェインＢのＦ３，Ｆ１の重みも求める。
　そして、冗長化対象ＶＮＦ判定部１３は、重みの最大値＝１．６となるＦ１を、冗長化対象ＶＮＦとする。
　さらに、冗長化対象ＶＮＦ判定部１３は、図５の（手法１６）で求めた各リソース使用率の重みに対して、図４の（手法１５）で説明したように、サービスチェイン全体での重みの合計値が最大値となるＶＮＦを、冗長化対象ＶＮＦとしてもよい。例えば、図５の３つのＶＮＦについては、以下のように、重みの合計値が求まる。
　・「Ｆ１」の重みの合計値＝１．６
　・「Ｆ２」の重みの合計値＝０．７
　・「Ｆ３」の重みの合計値＝２．３（＝１．５＋０．８）
　よって、重みの合計値が最大の「Ｆ３」が、冗長化対象ＶＮＦとなる。
　図６は、冗長化対象ＶＮＦ決定部１４の処理例を示す説明図である。
　冗長化対象ＶＮＦ決定部１４は、冗長化対象ＶＮＦ判定部１３の（手法１１）～（手法１６）で算出した結果を２つ以上組み合わせて、冗長化対象ＶＮＦを決定してもよい。以下、その具体例を説明する。
　テーブル２０５は、ＶＮＦごとに、収容ユーザ数が最大であるＶＮＦ（手法１２）を決定するためのユーザ数（つまり、図２で示した収容数Ｔ２０のうちのユーザ数Ｔ２２）と、前段で多くのリソースを消費しているＶＮＦ（手法１６）を決定するためのリソース使用率とを抜粋したものである。
　まず、図５で説明したように、（手法１６）に従って、各ＶＮＦの重みを計算する。例えば、サービスチェインＡのＦ３の重み＝０．７＋０．８＝１．５である。
　次に、ＶＮＦごとに、（手法１６）の重み×（手法１２）のユーザ数の積を求める。例えば、サービスチェインＡのＦ３の積＝（重み１．５）×（ユーザ数１８０）＝２７０となる。この積が他のどのＶＮＦの積よりも大きいので（つまり、重要度が最大値となるので）、冗長化対象ＶＮＦ決定部１４は、Ｆ３を冗長化対象ＶＮＦとして決定する。
　以上説明した本実施形態では、サービスチェイン設計装置１が、サービスチェインに使用されるＶＮＦを冗長化することで、サービスチェインを動的かつ信頼性を高めた設計を行う方法を示した。
　なお、比較例として、同じＶＮＦの集合を提供可能なサービスチェインを複数用意し、いずれか１つのサービスチェインに問題が発生した場合に、他のサービスチェインに切り替えるという運用方法が想定される。ただし、この比較例では、複数のサービスチェインに共有されるＶＮＦが故障した場合、故障したＶＮＦから他のＶＮＦに切り替える過程で多くのサービスまたはユーザに影響が及んでしまう。
　例えば、あるＶＮＦが１００個のサービスチェインに共有されている場合、本ＶＮＦが故障すると、一度に１００個のチェインが予備系に切り替わる。結果、１００種のサービス影響と、本サービスチェインに収容されている多数のユーザに影響を及ぼしてしまう。
　一方、本実施形態では、サービスチェイン設計装置１が、多数のユーザに影響を及ぼしてしまうような、特に重要なＶＮＦを冗長化対象ＶＮＦとして個別に多重化することで、サービスチェイン全体の信頼性をより高めることができる。さらに、比較例のようなサービスチェイン単位での冗長化と、本実施形態の重要なＶＮＦ単位での冗長化とを併用することで、より高い信頼性を確保できる。
　また、本実施形態では、冗長化対象ＶＮＦ判定部１３と、冗長化対象ＶＮＦ決定部１４と、冗長化判定部３１と、冗長化決定部３２とをそれぞれ個別の機能部として用意することで、最初に冗長化対象とするＶＮＦを決定し、次に対象ＶＮＦの各種閾値を観測し、冗長化を行う構成を示した。その代わりに、冗長化対象ＶＮＦ判定部１３と、冗長化対象ＶＮＦ決定部１４と、冗長化判定部３１と、冗長化決定部３２とを１つの機能部としてサービスチェイン設計装置１内に実装してもよい。その場合、運用中の全ＶＮＦの各種閾値を観測しながら、冗長化対象ＶＮＦを決定し、同時に冗長化を行うようにサービスチェイン設計装置１が動作する。
　なお、本実施形態においては、本発明に係るサービスチェイン設計装置１は、図２に示すように、４種類のサービスチェインＡ～Ｄを扱うこととしたが、これらの個数や構成に限定されない。また、本発明では、一般的なコンピュータのハードウェア資源を、サービスチェイン設計装置１の各手段として動作させるプログラムによって実現することができる。そして、このプログラムは、通信回線を介して配布したり、ＣＤ－ＲＯＭ等の記録媒体に記録して配布したりすることも可能である。
　１　　　サービスチェイン設計装置
　１１　　サービスチェイン生成要求受付部
　１２　　サービスチェイン生成要求分解部
　１３　　冗長化対象ＶＮＦ判定部（第１判定部）
　１４　　冗長化対象ＶＮＦ決定部
　２１　　ポリシー／閾値管理ＤＢ
　２２　　サービスチェイン構成情報ＤＢ
　２３　　収容情報管理ＤＢ
　２４　　性能値収集ＤＢ
　２５　　冗長化対象ＶＮＦ管理ＤＢ
　３１　　冗長化判定部（第２判定部）
　３２　　冗長化決定部
　３３　　冗長度計算部
　３４　　冗長度決定部
　３５　　ＶＮＦ配置決定部（配置決定部）
　３６　　冗長ルート計算部
　３７　　冗長ルート決定部
　３８　　サービスチェインコントローラ要求受付部

Claims (8)

  1. 　ＶＮＦ（Virtualized Network Function）を利用するサービスチェインの数、および、ＶＮＦを利用するサービスチェインが収容するユーザの数のうちの少なくとも１つをＶＮＦごとの重要度とし、その重要度が大きいＶＮＦを冗長化対象ＶＮＦと判定する第１判定部と、
    　前記第１判定部が判定した前記冗長化対象ＶＮＦの重要度が所定閾値を超過したときに、その超過した前記冗長化対象ＶＮＦを冗長化実行ＶＮＦと判定する第２判定部と、
    　前記第２判定部が判定した前記冗長化実行ＶＮＦに対して、その重要度が所定閾値を下回るように、前記冗長化実行ＶＮＦを利用するサービスチェインの負荷分散先となる新たな前記冗長化実行ＶＮＦの生成数を計算する冗長度計算部とを有することを特徴とする
    　サービスチェイン設計装置。
  2. 　前記第１判定部は、前記サービスチェインの数、および、前記収容するユーザの数に加えて、サービスチェイン内におけるＶＮＦの位置がルートの後方であるほど高い重要度とする重み、および、サービスチェイン内における前段で多くのリソースを消費しているＶＮＦほど高い重要度とする重みの少なくとも１つをＶＮＦごとの重要度とすることを特徴とする
    　請求項１に記載のサービスチェイン設計装置。
  3. 　前記第１判定部は、前記サービスチェインの数、および、前記収容するユーザの数に加えて、前記ＶＮＦが提供するサービス内容の重み、および、サービスチェインが収容するユーザの重みのうちの少なくとも１つの重みをもとに、ＶＮＦごとの重要度を計算することを特徴とする
    　請求項２に記載のサービスチェイン設計装置。
  4. 　前記第２判定部は、ＶＮＦの性能値の測定データをもとに、前記冗長化対象ＶＮＦの重要度が所定閾値を超過したか否かを判定することを特徴とする
    　請求項１ないし請求項３のいずれか１項に記載のサービスチェイン設計装置。
  5. 　前記サービスチェイン設計装置は、さらに、配置決定部と、冗長ルート決定部とを有しており、
    　前記配置決定部は、複数の前記冗長化実行ＶＮＦの配置先がそれぞれ異なる物理サーバ上になるように、前記冗長度計算部が計算した生成数分の新たな前記冗長化実行ＶＮＦの配置先を決定し、
    　前記冗長ルート決定部は、各サービスチェインの冗長ルート同士で重複する経路が少なくなるように、前記配置決定部が決定した各配置先を通過する各冗長ルートを決定することを特徴とする
    　請求項１ないし請求項４のいずれか１項に記載のサービスチェイン設計装置。
  6. 　前記サービスチェイン設計装置は、さらに、配置決定部と、冗長ルート決定部とを有しており、
    　前記配置決定部は、複数の前記冗長化実行ＶＮＦの配置先がそれぞれ異なる物理サーバ上になるように、前記冗長度計算部が計算した生成数分の新たな前記冗長化実行ＶＮＦの配置先を決定し、
    　前記冗長ルート決定部は、前記配置決定部が決定した前記冗長化実行ＶＮＦの配置先の冗長ルートにおける直前の位置にロードバランサを配置し、そのロードバランサを経由して複数の前記冗長化実行ＶＮＦそれぞれを通過する冗長ルートを決定することを特徴とする
    　請求項１ないし請求項４のいずれか１項に記載のサービスチェイン設計装置。
  7. 　サービスチェイン設計装置は、第１判定部と、第２判定部と、冗長度計算部とを有しており、
    　前記第１判定部は、ＶＮＦ（Virtualized Network Function）を利用するサービスチェインの数、および、ＶＮＦを利用するサービスチェインが収容するユーザの数のうちの少なくとも１つをＶＮＦごとの重要度とし、その重要度が大きいＶＮＦを冗長化対象ＶＮＦと判定し、
    　前記第２判定部は、前記第１判定部が判定した前記冗長化対象ＶＮＦの重要度が所定閾値を超過したときに、その超過した前記冗長化対象ＶＮＦを冗長化実行ＶＮＦと判定し、
    　前記冗長度計算部は、前記第２判定部が判定した前記冗長化実行ＶＮＦに対して、その重要度が所定閾値を下回るように、前記冗長化実行ＶＮＦを利用するサービスチェインの負荷分散先となる新たな前記冗長化実行ＶＮＦの生成数を計算することを特徴とする
    　サービスチェイン設計方法。
  8. 　請求項７に記載のサービスチェイン設計方法を、コンピュータである前記サービスチェイン設計装置に実行させるためのサービスチェイン設計プログラム。
PCT/JP2019/021127 2018-06-04 2019-05-28 サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラム WO2019235304A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/734,292 US11258551B2 (en) 2018-06-04 2019-05-28 Service chain designing device, service chain designing method, and service chain designing program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018-107042 2018-06-04
JP2018107042A JP6973300B2 (ja) 2018-06-04 2018-06-04 サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラム

Publications (1)

Publication Number Publication Date
WO2019235304A1 true WO2019235304A1 (ja) 2019-12-12

Family

ID=68769861

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/021127 WO2019235304A1 (ja) 2018-06-04 2019-05-28 サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラム

Country Status (3)

Country Link
US (1) US11258551B2 (ja)
JP (1) JP6973300B2 (ja)
WO (1) WO2019235304A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112217874B (zh) * 2020-09-21 2021-08-17 北京邮电大学 一种服务功能链生成方法及装置
TWI827974B (zh) * 2021-09-08 2024-01-01 財團法人工業技術研究院 虛擬功能效能分析系統及其分析方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016152480A (ja) * 2015-02-17 2016-08-22 日本電信電話株式会社 通信ネットワークの冗長経路検出システムおよびその検出方法

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8010942B1 (en) * 2007-03-05 2011-08-30 Sprint Communications Company L.P. Resilient application design and displaying design profile via graphical user interface
US20110105084A1 (en) * 2009-10-30 2011-05-05 Openwave Systems, Inc. Back-channeled packeted data
JP5748363B2 (ja) 2013-02-01 2015-07-15 日本電信電話株式会社 通信経路設計装置、通信経路設計方法及び通信経路設計プログラム
US9882828B1 (en) * 2014-11-11 2018-01-30 Amdocs Software Systems Limited System, method, and computer program for planning distribution of network resources in a network function virtualization (NFV) based communication network
US9503391B2 (en) * 2014-04-11 2016-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for network function placement
ES2760875T3 (es) * 2014-04-30 2020-05-18 Affirmed Networks Inc Optimización de extensión de capacidad en una red móvil
US9806975B2 (en) * 2014-06-12 2017-10-31 Futurewei Technologies, Inc. Methods and systems for managing capacity in a virtualized network
CN105429776B (zh) * 2014-09-22 2020-06-09 中兴通讯股份有限公司 一种虚拟化网络功能管理的方法和系统
ES2876311T3 (es) * 2014-09-29 2021-11-12 Koninklijke Kpn Nv Replicación de estado de instancias de función de red virtual
US9462084B2 (en) * 2014-12-23 2016-10-04 Intel Corporation Parallel processing of service functions in service function chains
CN107534570B (zh) * 2015-06-16 2021-08-24 慧与发展有限责任合伙企业 用于虚拟化网络功能监控的计算机系统、方法和介质
JP6636142B2 (ja) * 2015-09-30 2020-01-29 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． スケールアウト関連付けの方法および装置、ならびにシステム
US10477449B2 (en) * 2016-08-26 2019-11-12 Veniam, Inc. Systems and methods for route selection in a network of moving things, for example including autonomous vehicles
US11558246B2 (en) * 2016-12-09 2023-01-17 British Telecommunications Public Limited Company Implementing service function chains
CN108632063B (zh) * 2017-03-20 2021-01-05 华为技术有限公司 管理网络切片实例的方法、装置和系统
US20200138693A1 (en) * 2017-05-31 2020-05-07 L'oreal Composition for conditioning hair
US11070432B2 (en) * 2017-07-20 2021-07-20 Cisco Technology, Inc. Dynamic and customizable virtual network functions
US11467881B2 (en) * 2017-09-13 2022-10-11 At&T Intellectual Property I, L.P. Framework, method and apparatus for network function as a service for hosted network functions in a cloud environment
CN109560955B (zh) * 2017-09-27 2021-10-01 华为技术有限公司 网络的部署信息确定方法及设备
US10467040B2 (en) * 2017-09-29 2019-11-05 Nec Corporation Intelligent self-configuring decision method for the cloud resources management and orchestration
US10491483B2 (en) * 2017-10-19 2019-11-26 Nicira, Inc. Using application programming interface calls for communication between network functions
US10999155B2 (en) * 2017-10-26 2021-05-04 Cisco Technology, Inc. System and method for hybrid and elastic services
US10826797B2 (en) * 2017-12-15 2020-11-03 Foundation Of Soongsil University Industry Cooperation System and method for processing network packets based on NFV for ensuring high availability
GB2573283B (en) * 2018-04-26 2020-04-29 Metaswitch Networks Ltd Improvements relating to network functions virtualization

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016152480A (ja) * 2015-02-17 2016-08-22 日本電信電話株式会社 通信ネットワークの冗長経路検出システムおよびその検出方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NAKATSUKASA, SATOSHI ET AL: "A consideration of a redundant service router system for high availability and advanced operation", IEIICE TECHNICAL REPORT, vol. 111, no. 344, 8 December 2011 (2011-12-08), pages 103 - 108 *

Also Published As

Publication number Publication date
US20210226743A1 (en) 2021-07-22
JP6973300B2 (ja) 2021-11-24
US11258551B2 (en) 2022-02-22
JP2019213028A (ja) 2019-12-12

Similar Documents

Publication Publication Date Title
US8862744B2 (en) Optimizing traffic load in a communications network
EP3563236B1 (en) Systems and methods for adding microservices into existing system environments
US10075329B2 (en) Customizable high availability switchover control of application delivery controllers
US7610425B2 (en) Approach for managing interrupt load distribution
US20080263401A1 (en) Computer application performance optimization system
US11411808B2 (en) Managing failover region availability for implementing a failover service
US20060050630A1 (en) Storage network management server, storage network managing method, storage network managing program, and storage network management system
US11397652B2 (en) Managing primary region availability for implementing a failover from another primary region
CN102187315A (zh) 在虚拟环境中获取用于服务器负载均衡的反馈信息的方法和装置
EP4127936B1 (en) Managing failover region availability for implementing a failover service
US11397651B2 (en) Managing failover region availability for implementing a failover service
EP4068725B1 (en) Topology-based load balancing for task allocation
US20080148270A1 (en) Method and implementation for storage provisioning planning
WO2019235304A1 (ja) サービスチェイン設計装置、サービスチェイン設計方法、および、サービスチェイン設計プログラム
KR20200080458A (ko) 클라우드 멀티-클러스터 장치
Kang et al. Resilient resource allocation model in service function chains with diversity and redundancy
CN114237910A (zh) 客户端负载均衡实现方法及装置
CN109451090B (zh) 一种域名解析方法及装置
CN107491270B (zh) 一种多控存储系统的资源访问方法及装置
Birke et al. Power of redundancy: Designing partial replication for multi-tier applications
KR102201651B1 (ko) 태스크 지역성과 다운스트림 상태를 고려한 확률 기반의 데이터 스트림 파티셔닝 방법 및 이를 기록한 기록매체
CN112783673A (zh) 一种调用链的确定方法、装置、计算机设备及存储介质
Sagkriotis et al. Scalable data plane caching for kubernetes
JP2019169135A (ja) コンピュータクラスタのノード間の通信経路を確立する方法、当該方法に対応するコンピュータプログラム、及びコンピュータクラスタ
US11671486B1 (en) Managing availability zone utilizing redundancy validation

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: 19815742

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: 19815742

Country of ref document: EP

Kind code of ref document: A1