WO2023166626A1 - 通信システム、配置計算装置、設定投入装置、通信方法、及びプログラム - Google Patents
通信システム、配置計算装置、設定投入装置、通信方法、及びプログラム Download PDFInfo
- Publication number
- WO2023166626A1 WO2023166626A1 PCT/JP2022/008933 JP2022008933W WO2023166626A1 WO 2023166626 A1 WO2023166626 A1 WO 2023166626A1 JP 2022008933 W JP2022008933 W JP 2022008933W WO 2023166626 A1 WO2023166626 A1 WO 2023166626A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- host
- gateway
- mark
- packet
- instance
- Prior art date
Links
Images
Classifications
-
- 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/76—Routing in software-defined topologies, e.g. routing between virtual machines
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1083—In-session procedures
Definitions
- the present invention relates to a packet routing scheme in a communication system.
- a communication format that provides services by combining communication devices such as gateways (GW) and applications on a virtualization platform is widely used.
- Non-Patent Document 1 a method of introducing an IGP or an Agent instance (Non-Patent Document 1) and making the host learn the route necessary for GW identification.
- Non-Patent Document 2 a method is known in which an application that processes packets identifies the GW that is the source of the packet transfer by performing SNAT (Non-Patent Document 2) with the address of the GW.
- the above conventional technology has problems such as session disconnection when the terminal is reconnected to a different GW, and the need for the host to learn a large number of routes.
- the present invention has been made in view of the above points.
- the session is not disconnected even when the terminal is reconnected to the GW, and it is necessary to learn a large amount of routes.
- the purpose is to provide technology that makes it possible not to
- a gateway for performing network processing on a packet transmitted from a device, and a first mark indicating that the transfer source is the gateway is attached to the packet transferred from the gateway. , a first host forwarding said first marked packet; an application, receiving a packet transferred from the first host, adding a second mark to the packet indicating that the transfer source is the first host, and adding the second mark a second host that forwards packets to the application and forwards packets forwarded from the application to the first host based on the second mark; A communication system is provided wherein said first host forwards packets received from said second host to said gateway based on said first mark.
- FIG. 2 is a diagram for explaining the premise of services;
- FIG. 2 is a diagram for explaining a service-based network; It is a figure for demonstrating a prior art. It is a figure for demonstrating a prior art. It is a figure which shows the summary of a prior art. It is a figure for demonstrating the outline
- FIG. 4 is a diagram for explaining Proposal 1;
- FIG. 10 is a diagram for explaining Proposal 2;
- FIG. 10 is a diagram for explaining Proposal 2;
- FIG. 10 is a diagram for explaining Proposal 3;
- FIG. 10 is a diagram for explaining Proposal 3;
- FIG. 10 is a diagram for explaining Proposal 3;
- FIG. 10 is a diagram for explaining Proposal 3; FIG. 4 is a diagram for explaining the processing flow in the routing method of this embodiment; FIG. 10 is a diagram showing an example in the case of a VM/container nested structure; FIG. 10 is a diagram showing a processing flow of instance placement determination; FIG. 10 is a diagram showing a processing flow of setting automation; It is a figure showing the whole system composition example in an embodiment of the invention.
- 4 is a configuration diagram of a host management unit; FIG. It is an example of a host information DB. 4 is a configuration diagram of an instance management unit; FIG. It is an example of an instance information DB. 4 is a configuration diagram of an arrangement calculation unit; FIG. 4 is a configuration diagram of a setting input unit 400; FIG. It is a figure which shows the example of each table. This is the sequence of instance placement when the service starts.
- FIG. 4 is a diagram showing a packet flow; It is a figure which shows the hardware configuration example of an apparatus.
- this system has a gateway (GW), an application (APP), and a device (Dev) connected to the CPE.
- GW gateway
- APP application
- Dev device
- the GW performs network processing (eg tunneling, load balancing) necessary for the service.
- An App is an endpoint that implements service logic (eg machine learning, image processing, storage). Also, as for communication establishment, it is assumed that communication is established in the direction from Dev to GW/App that provides services.
- the GW and App will operate in the form of VMs or containers on the virtualization infrastructure.
- a plurality of instances exist as GWs, and by distributing and holding routes to WANs, network processing load is distributed.
- Multiple instances of App exist to distribute the processing load of App.
- GW and App may each be single.
- GW1, GW2, App1, App2, CPE1, CPE2, Dev1, and Dev2 are shown.
- GW1 holds a route addressed to Dev1 and NAT information
- GW2 holds a route addressed to Dev2 and NAT information.
- the base NW has different NW segments (implemented by Calico, Cillium, Openstack, etc.) between instances. Instances do not have individual paths, and communication between instances is relayed by hosts or network nodes.
- NW segments implemented by Calico, Cillium, Openstack, etc.
- hosts or network nodes The routing requirements for services assumed in this embodiment are as follows.
- a "host” in this embodiment may be a physical server or a virtual server.
- the GW holds network processing information such as transfer routes and NAT information, and it is necessary to transfer packets processed by the App to the GW that has appropriate network processing information. As shown in FIG. 2, App1, for example, needs to transfer packets addressed to Dev1 to GW1 and return packets addressed to Dev2 to GW2. dgw (default gateway) cannot perform such a forwarding process.
- Non-Patent Document 1 As a conventional technology for transferring packets processed by App to GW having appropriate network processing information, there is a technology that introduces IGP or Agent instance (Non-Patent Document 1) and makes the host learn the route necessary for GW identification. be.
- FIG. 3 shows that the Agent instance on Host 1 routes to App.
- this conventional technology requires route learning (equivalent to the number of CPEs) in a large number of hosts, and has the problem of affecting scalability/resources/trackability. Moreover, there is also the problem that the operation cost of newly establishing an IGP and an additional Agent instance is high.
- Non-Patent Document 2 There is also a conventional technology that uses SNAT.
- SNAT is performed on packets flowing into the GW using the address of the GW instance, so that the App that processes the packets identifies the source GW.
- Fig. 5 shows a summary of the conventional technology. As shown in FIG. 5, the conventional technology has the following two drawbacks, and a routing scheme capable of solving these problems is required.
- Connmark (a function to mark the traced flow) on the host and PBR based on the mark.
- instances may be placed so that processing is completed by a GW/App pair within a single host.
- the host 1 is provided with GW1 and GW2, and the host 2 is provided with App1 and App2.
- GW1 receives the packet at S1 and forwards the packet to App1 at S2.
- the host 2 assigns a mark to identify the host (host 1) from which the traffic flows, and performs PBR based on the mark.
- the host 1 assigns a mark to identify the inflow source GW (GW1) and performs PBR based thereon.
- the host 2 performs PBR to return the packet to the inflow source host 1
- the host 1 performs PBR to return the packet to the inflow source GW1.
- GW1 and App1 are placed on host 1, and GW2 and App2 are placed on host 2.
- FIG. 7 the GW in each host is made single.
- connection tracking and PBR settings ((i) in FIG. 6) for distinguishing GWs in the host as shown in (ii) in FIG. 6 can be reduced.
- connection tracking and PBR are used to identify the source flow. (i)) to reduce performance degradation.
- Proposal 1 Minimum configuration
- a policy is focused on services that establish communication in the direction from the device to the GW/App, ingress traffic is processed by an appropriate GW, and egress traffic is returned to the inflow source GW or its host server. Perform base routing (PBR).
- PBR base routing
- PBR based on connmark and mark will be set step by step. This eliminates the need to rewrite the packet header, so the session is not disconnected when the GW is changed. That is, it does not affect application processing.
- FIG. 8 shows an example of processing traffic from CPE1 in a system having hosts 1 and 2.
- GW1 holds a route addressed to CPE1.
- connmark+PBR is set so as to send the packet to the host 1 when returning the communication packet between the CPE1 and App1 to the CPE1.
- traffic destined for CPE1 is returned to the EID (endpoint identifier) of GW1.
- host 1 sets connmark+PBR so that packets for communication between CPE1 and APP1 are sent to GW1.
- the instance placement is optimized to further consolidate the processing and settings of Connmark/PBR.
- the connmark setting for GW identification is reduced.
- the number of apps for each host is arranged as evenly as possible so that GW/App processing can be completed within a single host, the number of flows subject to connmark/PBR for host identification and the transfer delay is intended to be reduced.
- FIG. 9 shows a case where the number of GWs in each host is one (eg at the beginning of service), and FIG. 10 shows a case where there are multiple GWs per host (eg during peak hours).
- ingress traffic to GW1 is basically preferentially processed by App1 within the same host1. This eliminates the need for PBR, allows traffic to be transferred from App1 to host 1, and can be transferred to GW1 using the default route of host 1, etc., thereby reducing settings.
- hosts 1 and 2 since hosts 1 and 2 only track connections across hosts and carry out PBR, the number of connections to be tracked and the number of flows to be PBRed can be reduced. For example, in host 2, only packets that flowed in from host 1 are tracked and marked. Also, only marked packets processed by App can be routed to host 1 by PBR and transferred to GW 1 by the default route of host 1 or the like.
- connmark/PBR is required to identify the GW within the host 1, as described above.
- Ingress traffic connmarks on the interface of GW1/3 and routes packets to GW1/3 with PBR based on the mark of incoming packets to Host1.
- host 2 only packets that flowed in from host 1 are tracked and marked, only marked packets processed by App are routed to host 1 by PBR, and transferred to GW1 by host 1's default route, etc.
- Proposal 3 Method setting automation system
- Proposal 3 by adopting a system that automatically sets the above-mentioned method based on the usage status of the host, settings are made according to increases and decreases in the number of instances, enabling stable communication. . Configuration examples, setting timings, and setting details for each host usage situation will be described with reference to FIGS. 11 to 13. FIG.
- Case 1 Case where multiple GWs operate on the host>
- a configuration example of Case 1 is shown in FIG.
- the setting timing in case 1 is at the time of GW activation/deletion, and the setting contents are (a) Connmark setting for the inflow flow (for the number of GWs), and (b) the GW corresponding to the return flow mark value. This is the PBR setting (for the number of GWs) for transfer.
- settings (a) and (b) are unnecessary when there is one GW instance.
- ⁇ Case 2 App runs on the host> A configuration example of Case 2 is shown in FIG.
- the setting timing in case 2 is when the App is started/deleted, and the setting contents are (c) Connmark setting for the inflow flow (for the number of hosts), and (d) GW corresponding to the return flow mark value. This is the PBR setting (for the number of hosts) for transfer.
- Case 3 Case where multiple GWs and apps are running on the host> A configuration example of case 3 is shown in FIG.
- the setting timing in case 3 is when App and Gw are activated/deleted, and the setting contents are (a) to (d) described in cases 1 and 2.
- FIG. In the following, the contents of the proposals 1 to 3 mentioned above will be described in more detail.
- Dev1 sends a packet to Application 1 on Host 2.
- CPE1 encaps the packet and transmits it to GW1.
- GW1 receives the packet and transmits the packet to application 1 after decapping.
- the host 1 connmarks the packet in the request direction.
- the host 2 running the application 1 connmarks each source mac in the request direction.
- connmark is performed on the host 2 on which the application 1 operates, with the source mac address as a trigger.
- a source mac address as a connmark trigger is an example. Any information may be used as long as it is information contained in the packet and can identify the source host. For example, the source IP address of the tunneling header may be used.
- the packet is transferred to the host 1 (on which GW1 operates) that is the inflow source. That is, in the Reply direction, the packet is transferred to the host 1 from which the packet is received according to the mark value.
- the host 1 forwards the reply packet to the inflow source GW1 based on the mark value in S3.
- the host 1 has multiple GWs, so this setting is necessary to identify them.
- the system of this embodiment can also be implemented in a VM/container nesting structure.
- the path of the instance (container) is not advertised in the physical server segment, so communication is performed using tunneling such as IPIP.
- FIG. 15 A configuration example that employs a VM/container nesting structure is shown in FIG. As shown in FIG. 15, communication is established by performing the procedures of S1 to S4 in VMs 1 and 2 that accommodate instances. No setting to the physical server is required. Specifically, it is as follows.
- VM1 marks the flow with the GW number by CONNMARK.
- VM2 marks the flow with the source host number with CONNMARK.
- VM2 sees the host number marked on the flow and forwards the flow to the corresponding host with IPIP.
- VM1 sees the GW number marked on the flow and forwards the flow to the corresponding GW.
- S101 to S106 one GW is deployed to one host. If all GWs still cannot be deployed, additional GWs are deployed to the host in S107-S110. Since all of S101 to S106 and S107 to S110 are repetitions for the host, each step will be described with "host A" as an example.
- the placement calculation unit 300 confirms the status of host A. To check the status means to acquire information necessary for placement determination. In S102, the placement calculation unit 300 confirms whether or not there are resources for the host A, and proceeds to S103 if there are resources for deploying the GW, and proceeds to S106 if there are none.
- the placement calculation unit 300 confirms the number of GWs of host A, and proceeds to S106 if there is a GW, and proceeds to S104 if there is no GW.
- S104 GW is deployed to host A.
- S105-S106 if there is no undeployed GW, the process is terminated, and if there is an undeployed GW and an unconfirmed host, the process returns to S101 to process the next host.
- the instance management unit 200 determines the number of hosts and the number of instances as resources. In S202, the instance management unit 200 (or the placement calculation unit 300) places instances.
- the GW in the host is made as single as possible, and the number of applications per host is made uniform.
- the setting input unit 400 determines the state of the host based on the information from the host management unit 100, and proceeds to S204 if the App is operating, and to S205 if the GW and APP are operating. , and if only the GW is operating, proceed to S206.
- the setting input unit 400 performs the setting input of FIG. 12, and in S205, performs the setting input of FIG.
- S206 if the number of GWs is one, proceed to S208. If the number of GWs is plural, then in S207, the setting input of FIG. 11 is performed. In S208, the instance management unit 200 monitors used resources.
- FIG. 18 shows an example of the overall configuration of the system according to this embodiment.
- this system includes a CPE 10, a GW resolution unit 20, a host 1 (host server) on which GW1 operates, a host 2 on which App1 operates, a host management unit 100, a DB 30, an instance management unit 200, an allocation calculation It has a section 300 and a setting entry section 400 .
- Each part shown in FIG. 18 may be a single device, or a plurality of parts may constitute one device.
- the GW resolution unit 20, the host management unit 100, the instance management unit 200, the placement calculation unit 300, and the setting input unit 400 are replaced with the GW resolution device 20, the host management device 100, the instance management device 200, the placement calculation device 300, and the setting input device 400, respectively. You can call it
- the outline of each part (each device) is as follows.
- the CPE 10 is a network device that accommodates client terminals (devices).
- the CPE 10 determines the GW of the connection destination by inquiring of the GW resolution unit 20 .
- GW1 which is an instance that operates as a NW function for services
- App1 that provides application logic operate on hosts 1 and 2, respectively.
- the host management unit 100 manages the host names, network information, and resource information of these hosts in the DB30.
- the placement calculation unit 300 determines the host to which the instance is to be placed, based on the number of hosts and the resource status.
- the instance management unit 200 arranges instances based on the decisions made by the arrangement calculation unit 300, and manages instance IDs, network information, and resource information.
- the setting input unit 400 performs network settings for each host based on the instance arrangement status.
- the host management unit 100 acquires host names, network information, and resource information from each host and manages them in a DB.
- FIG. 19 shows the configuration of the host management unit 100. As shown in FIG. As shown in FIG. 19, the host management unit 100 has a host information DB 110, a host information acquisition unit 120, and a distribution API function unit .
- the host information acquisition unit 120 accesses the host to acquire the above information, and stores the acquired information in the host information DB 110.
- the host information DB 110 manages network information such as host IDs, IP addresses/mac addresses, and host resources.
- the external layout calculation unit 300 and setting input unit 400 access the host information DB 110 via the distribution API function unit 130 and acquire information necessary for processing, such as network information and resource usage rate.
- FIG. 20 shows an example of information stored in the host information DB 110. As shown in FIG.
- the instance management unit 200 deploys instances.
- the instance name, instance type, and network information are acquired and managed in the DB.
- FIG. 21 shows a configuration example of the instance management unit 200. As shown in FIG.
- the instance management unit 200 has an instance information DB 210, an instance deploy function unit 220, an instance information acquisition unit 230, and a distribution API function unit 240.
- the instance deployment function unit 220 selects hosts based on instructions from the placement calculation unit 30 and deploys instances.
- the instance information acquisition unit 230 accesses the instance, acquires the above information, and stores it in the instance information DB 210.
- the instance information D210B manages network information such as instance IDs, IP addresses/mac addresses, and host resources.
- the external layout calculation unit 300 and setting input unit 400 access the instance information DB 210 via the distribution API function unit 240 and acquire necessary information such as application type, network information, and operating host information.
- FIG. 22 shows an example of information stored in the instance information DB 210. As shown in FIG.
- the placement calculator 300 determines the host on which to deploy the instance.
- FIG. 23 shows a configuration example of the placement calculation unit 300. As shown in FIG. As shown in FIG. 23 , the layout calculation unit 300 has an information acquisition unit 310 , a layout determination unit 320 and a layout instruction unit 330 .
- the information acquisition unit 310 accesses the instance management unit 200/host management unit 100 via the distribution API function unit and acquires the resource availability status for each host and the number of GW instances and APP instances already in operation.
- the placement determining unit 320 determines the GW instance placement destination host according to the flow of GW placement determination processing (FIG. 16). Also, with regard to APP instances, the hosts on which APP instances are arranged are determined so that the number of instances for each type of APP is as even as possible on a host-by-host basis, as long as the host resources permit.
- the placement instruction unit 330 instructs the instance management unit 200 on the placement method based on the calculation result of the placement determination unit 320 .
- the setting input unit 400 sets the connmark and PBR necessary for the technology according to the present embodiment to the host.
- FIG. 24 shows a configuration example of the setting input unit 400.
- the setting input unit 400 has a host parameter DB 410 , an instance parameter DB 420 , a table management DB 430 , an information acquisition unit 440 , a setting generation unit 450 and a setting input processing unit 460 .
- the information acquisition unit 440 accesses the instance management unit 200/host management unit 100 via the distribution API function unit, and obtains the resource availability status for each host, the number of GW instances in operation, the APP instance, and the network required for setting. Acquire information and store it in the corresponding DB.
- the instance parameter DB 420 manages the operational status of instances and interface names.
- the host parameter DB 410 manages operational information and address information of instances in the host.
- the table management DB 430 manages on which host the table for PBR is operating.
- the setting generation unit 450 determines the state of the number of instances for each host based on information from various DBs, and generates settings for connmark and PBR.
- settings include (1) connmark based on the GW interface name, (2) connmark based on the mac address of the host, (3) settings for policy-based routing based on various mark values, and the like. be done.
- the setting input processing unit 460 sets the corresponding host based on the calculation result of the setting generation unit 450.
- FIG. 25 shows an example of information stored in each of the table management DB 430, instance parameter DB 420, and host parameter DB 410.
- FIG. 26 shows an example of a sequence for arranging instances on hosts 1 and 2 as instance arrangement at service start.
- Each of the hosts 1 and 2 may be a physical machine or a virtual machine.
- the sequence shown in FIG. 26 shows the procedures for starting the host at the time of starting the service, calculating the allocation of the instances, starting the instances, and inputting the settings to the host.
- the host management unit 100 activates each host of the infrastructure that constitutes the service, and collects information about each activated host.
- the collected information is stored in the host information DB 110 as shown in FIG. 20, for example.
- the instance management unit 200 acquires host information from the host management unit 100.
- the placement calculation unit 300 acquires instance information from the host management unit 100 .
- the instance management unit 200 requests the placement calculation unit 300 to calculate the placement of instances.
- the placement calculation unit 300 determines the placement based on the information of the instance and the host, and in S9, instructs the instance management unit 200 for placement.
- the instance management unit 200 selects a host and starts an instance.
- instance information is sent to the instance management unit 200 and stored in the instance information DB (FIG. 22).
- the setting input unit 400 acquires host information from the host management unit 100 in S14, and acquires instance information from the instance management unit 200 in S15. In S16, the setting input unit 400 uses the acquired information to create necessary network settings such as connmark and PBR, and in S17 and S18, inputs the settings to each host.
- the packet transmitted by the device 50 arrives at the CPE 10 (S1), resolves the GW of the connection destination by an inquiry to the GW resolution unit 20 (S2, S3), and is transferred to the host 1 where the GW 1 operates (S4 ).
- the host 1 transfers the incoming packet to GW1 (S5). After GW1 performs necessary NW processing on this packet in S6, it is transferred to host 1 again for communication to App1 in S7.
- the host 1 connmarks with the interface name etc. corresponding to GW1. Host 1 sends packets marked for flow identification to Host 2 at S9 for communication to App1.
- the host 2 connmarks the packet using the source mac address (here, the address of the host 1) as a key.
- the source mac address here, the address of the host 1
- App processing of the packet is performed in App1.
- the host 2 associates the mark value added in S10 with the mac address, and performs PBR on the return packet after processing in App1 based on the mark. Thereby, the packet is transferred to the host 1 (S15). Similarly, in S16, the host 1 that has received the return packet performs PBR to return the packet to the inflow source GW1 according to the mark value associated with the interface name of the GW1. NW processing is performed in S17 to S19, and the packet is transferred from the host 1 to the device 50 in S20.
- GW resolution unit 20 (Hardware configuration example) GW resolution unit 20, host management unit 100, instance management unit 200, placement calculation unit 300, setting input unit 400, GW resolution device 20, host management device 100, instance management device 200, placement calculation device 300, setting input device 400, All of the host, GW, and App can be implemented, for example, by causing a computer to execute a program. This computer may be a physical computer or a virtual machine on the cloud.
- GW resolution unit 20, host management unit 100, instance management unit 200, placement calculation unit 300, setting input unit 400, GW resolution device 20, host management device 100, instance management device 200, placement calculation device 300, setting input device 400, host, GW, and App are collectively called a device.
- the device can be realized by executing a program corresponding to the processing performed by the device using hardware resources such as a CPU and memory built into the computer.
- the above program can be recorded in a computer-readable recording medium (portable memory, etc.), saved, or distributed. It is also possible to provide the above program through a network such as the Internet or e-mail.
- FIG. 28 is a diagram showing a hardware configuration example of the computer.
- the computer of FIG. 28 has a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, etc., which are interconnected by a bus BS.
- a program that implements the processing in the computer is provided by a recording medium 1001 such as a CD-ROM or memory card, for example.
- a recording medium 1001 such as a CD-ROM or memory card
- the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000 .
- the program does not necessarily need to be installed from the recording medium 1001, and may be downloaded from another computer via the network.
- the auxiliary storage device 1002 stores installed programs, as well as necessary files and data.
- the memory device 1003 reads and stores the program from the auxiliary storage device 1002 when a program activation instruction is received.
- the CPU 1004 implements functions related to the device according to programs stored in the memory device 1003 .
- the interface device 1005 is used as an interface for connecting to a network or the like.
- a display device 1006 displays a GUI (Graphical User Interface) or the like by a program.
- An input device 1007 is composed of a keyboard, a mouse, buttons, a touch panel, or the like, and is used to input various operational instructions.
- the output device 1008 outputs the calculation result.
- a gateway that performs network processing on a packet transmitted from a device, affixes a first mark to a packet forwarded from the gateway to indicate that the gateway is the forwarding source, and adds the first mark to the packet forwarded from the gateway.
- a first host that forwards packets tagged with an application, receiving a packet transferred from the first host, adding a second mark to the packet indicating that the transfer source is the first host, and adding the second mark a second host that forwards packets to the application and forwards packets forwarded from the application to the first host based on the second mark;
- the communication system wherein the first host forwards packets received from the second host to the gateway based on the first mark.
- (Appendix 2) 3. The communication system of clause 1, wherein the first host and the second host each use connmarks to mark packets and use policy-based routing for forwarding packets based on the marks.
- a placement computing device for determining on which host to deploy a gateway instance in a communication system comprising multiple hosts, comprising: memory; at least one processor connected to the memory; including The processor Get the resource information of each host and the number of deployed gateway instances, As long as the host has the resources to deploy a gateway instance, decide to deploy one gateway instance on each host, and for gateway instances that have not been decided to deploy, Deployed Computing Unit that decides to deploy.
- Appendix 4 4. The allocation computing device according to claim 3, wherein, with respect to application instances, the processor determines the allocation to each host so that the number of instances is as even as possible among the hosts.
- a setting input device for inputting settings for a host in a communication system including a plurality of hosts, memory; at least one processor connected to the memory; including The processor Get host information and instance information for each host where the instance is located, For a host where multiple gateway instances are arranged, create settings for mark processing for inflow flows for each gateway instance and settings for routing using marks for return flows for each gateway instance, generates settings for mark processing for inflow flows and settings for routing using marks for return flows, for the host where A setting input device that submits the generated settings to the relevant host.
- a communication method in a communication system including a first host with a gateway and a second host with an application comprising: The first host forwards a packet transmitted from a device to the gateway, adds a first mark to the packet forwarded from the gateway to indicate that a forwarding source is the gateway, and forwarding packets marked with to said second host; The second host receives a packet transferred from the first host, puts a second mark on the packet indicating that the transfer source is the first host, and applies the second mark. to the application, forwarding packets forwarded from the application to the first host based on the second mark; The communication method, wherein the first host forwards the packet received from the second host to the gateway based on the first mark.
- CPEs 10 CPEs 20 GW resolution unit 30 DB 50 Device 100 Host management unit 110 Host information DB 120 host information acquisition unit 130 distribution API function unit 200 instance management unit 210 instance information DB 220 Instance deployment function unit 230 Instance information acquisition unit 240 Distribution API function unit 300 Placement calculation unit 310 Information acquisition unit 320 Placement determination unit 330 Placement instruction unit 400 Setting input unit 410 Host parameter DB 420 Instance Parameter DB 430 table management DB 440 information acquisition unit 450 setting generation unit 460 setting input processing unit 1000 drive device 1001 recording medium 1002 auxiliary storage device 1003 memory device 1004 CPU 1005 interface device 1006 display device 1007 input device 1008 output device
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
通信システムにおいて、デバイスから送信されたパケットに対してネットワーク処理を行うゲートウェイを備え、前記ゲートウェイから転送されたパケットに、転送元が前記ゲートウェイであることを示す第1のマークを付し、前記第1のマークを付したパケットを転送する第1のホストと、アプリケーションを備え、前記第1のホストから転送されたパケットを受信し、当該パケットに、転送元が前記第1のホストであることを示す第2のマークを付け、前記第2のマークを付したパケットを前記アプリケーションに転送し、前記アプリケーションから転送されたパケットを、前記第2のマークに基づいて、前記第1のホストに転送する第2のホストと、を備え、前記第1のホストは、前記第2のホストから受信したパケットを、前記第1のマークに基づいて、前記ゲートウェイに転送する。
Description
本発明は、本発明は、通信システムにおけるパケットのルーティング方式に関連するものである。
仮想化基盤上でゲートウェイ(GW)などの通信装置やアプリケーションを組み合わせてサービスを提供する通信形態が広く普及している。
利用者のデバイス(端末)からGWを経由してアプリケーションを利用する際に、アプリケーションの処理結果等を元のデバイスに返すことが必要な場合がある。そのための従来技術としては、IGPやAgentインスタンス(非特許文献1)を導入してGW識別に必要な経路をホストに学習させる方法が知られている。
また、別の従来技術として、GWのアドレスでSNAT(非特許文献2)を行うことで、パケットを処理するアプリケーションが、パケット転送元のGWを識別する方法も知られている。
Calico Felix : https://projectcalico.docs.tigera.io/maintenance/monitor/monitor-component-metrics
BIG IP SNAT: https://www.f5.com/ja_jp/services/resources/glossary/secure-network-address-translation-snat
しかし、上記の従来技術では、端末が異なるGWに再接続した場合にセッションが切れる、ホストに大量の経路を学習させる必要がある等の課題があった。
本発明は上記の点に鑑みてなされたものであり、アプリケーションが処理したパケットを適切なGWまで転送する技術において、端末のGW再接続時にもセッションが切れず、大量の経路の学習も必要としないことを可能とする技術を提供することを目的とする。
開示の技術によれば、デバイスから送信されたパケットに対してネットワーク処理を行うゲートウェイを備え、前記ゲートウェイから転送されたパケットに、転送元が前記ゲートウェイであることを示す第1のマークを付し、前記第1のマークを付したパケットを転送する第1のホストと、
アプリケーションを備え、前記第1のホストから転送されたパケットを受信し、当該パケットに、転送元が前記第1のホストであることを示す第2のマークを付け、前記第2のマークを付したパケットを前記アプリケーションに転送し、前記アプリケーションから転送されたパケットを、前記第2のマークに基づいて、前記第1のホストに転送する第2のホストと、を備え、
前記第1のホストは、前記第2のホストから受信したパケットを、前記第1のマークに基づいて、前記ゲートウェイに転送する
通信システムが提供される。
アプリケーションを備え、前記第1のホストから転送されたパケットを受信し、当該パケットに、転送元が前記第1のホストであることを示す第2のマークを付け、前記第2のマークを付したパケットを前記アプリケーションに転送し、前記アプリケーションから転送されたパケットを、前記第2のマークに基づいて、前記第1のホストに転送する第2のホストと、を備え、
前記第1のホストは、前記第2のホストから受信したパケットを、前記第1のマークに基づいて、前記ゲートウェイに転送する
通信システムが提供される。
開示の技術によれば、アプリケーションが処理したパケットを適切なGWまで転送する技術において、端末のGW再接続時にもセッションが切れず、大量の経路の学習も必要としないことを可能とする技術が提供される。
以下、図面を参照して本発明の実施の形態(本実施の形態)を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。
(サービスの前提について)
まず、本実施の形態で想定するサービスを提供するシステムについて、図1を参照して説明する。
まず、本実施の形態で想定するサービスを提供するシステムについて、図1を参照して説明する。
図1に示すように、本システムは、ゲートウェア(GW)とアプリケ―ション(APP)、CPEに接続されるデバイス(Dev)を有する。
ここで、GWは、サービスに必要なネットワーク処理(例:トンネリング,負荷分散)を実施する。Appは、サービスロジックを実装したエンドポイント(例:機械学習,画像処理,ストレージ)である。また、通信確立については、Devからサービスを提供するGW/Appへの方向の通信確立を実施することを想定する。
本実施の形態では、GWやAppは,仮想化基盤上のVMあるいはコンテナの形式で動作することを想定している。GWとして複数のインスタンスが存在し、WAN宛の経路を分散して保持することで、ネットワーク処理を負荷分散する。Appとして複数のインスタンスが存在し、Appの処理負荷を分散する。なお、GWとAppはそれぞれ単一であってもよい。
図1の例では、GW1、GW2、App1、App2、CPE1、CPE2、Dev1、Dev2が示されている。図1に示すとおり、GW1は、Dev1宛の経路やNAT情報を保持し、GW2は、Dev2宛の経路やNAT情報を保持する。
次に、サービス基盤のネットワーク(基盤NW)の前提について説明する。基盤NWでは、インスタンス間で異なるNWセグメント(例えばCalico, Cillium, Openstack等で実現される)を持つ。インスタンスは個々の経路を持たず、インスタンス同士の通信はホストあるいはネットワークノードが中継する。本実施の形態で想定するサービスのルーティング要件は下記のとおりである。なお、本実施の形態における「ホスト」は物理サーバであってもよいし、仮想サーバであってもよい。
GWが転送経路やNAT情報等のネットワーク処理情報を保持しており、Appが処理したパケットを適切なネットワーク処理情報を持つGWまで転送する必要がある。図2に示すとおり、例えば、App1は、Dev1宛のパケットをGW1に転送し、Dev2宛のパケットをGW2に返す必要がある。dgw(デフォルトゲートウェイ)はこのような転送処理を行うことができない。
(従来技術)
Appが処理したパケットを適切なネットワーク処理情報を持つGWまで転送するための従来技術として、IGPやAgentインスタンス(非特許文献1)を導入し、GW識別に必要な経路をホストに学習させる技術がある。図3には、ホスト1上のAgentインスタンスがAppに対して経路設定を行うことが示されている。
Appが処理したパケットを適切なネットワーク処理情報を持つGWまで転送するための従来技術として、IGPやAgentインスタンス(非特許文献1)を導入し、GW識別に必要な経路をホストに学習させる技術がある。図3には、ホスト1上のAgentインスタンスがAppに対して経路設定を行うことが示されている。
しかし、この従来技術では、多数のホストで(CPE数相当の)経路学習が必要となり、スケーラビリティ/リソース/追跡性に影響があるという課題がある。また、IGPや追加のAgentインスタンスを新設するオペレーションコストがかかるという課題もある。
また、SNATを用いる従来技術もある。この従来技術では、図4に示すとおり、GWへの流入パケットに対し、GWインスタンスのアドレスでSNATを行うことで、パケットを処理するAppが送信元のGWを識別する(非特許文献2)。
しかし、CPEが移動する場合など、CPE発パケットが異なるGWに再接続する場合がある。このとき、App視点では送信元IPが変更されたように見えるため、セッションを維持できなくなる。図4の例において、例えば、CPE1発のパケットがGW2に接続する際には、セッションを維持できなくなる。
図5に従来技術のまとめを示す。図5に示すとおり、従来技術では以下の二つの欠点があり、これらを解決可能なルーティング方式が必要である。
・端末が異なるGWに接続した場合などでもアプリケーション処理に影響する
・ホストに大量の経路を学習させる必要がある
(提案方式の概要)
上記の課題を解決するための本実施の形態における提案方式の概要を説明する。本実施の形態では、デバイスからサービス(GW/App)への方向で通信確立するサービスに着目し、Egressトラヒックをパケット流入元のGWやそのホストサーバまで段階的に戻すように、ポリシーベースルーティング(PBR)を行う。
・ホストに大量の経路を学習させる必要がある
(提案方式の概要)
上記の課題を解決するための本実施の形態における提案方式の概要を説明する。本実施の形態では、デバイスからサービス(GW/App)への方向で通信確立するサービスに着目し、Egressトラヒックをパケット流入元のGWやそのホストサーバまで段階的に戻すように、ポリシーベースルーティング(PBR)を行う。
具体的には、上記をホストでのConnmark(追跡したフローにマークを付する機能)とマークに基づくPBRにより実現する。
また、配置最適化の工夫として、ConnmarkやPBRの対象になるフロー数を削減するため、単一ホスト内のGW/Appのペアで処理が完結するようにインスタンスを配置することとしてもよい。
図6を参照して基本構成の例(段階的にPBRを行うルーティング方式)を説明する。ホスト1にGW1とGW2が備えられ、ホスト2にApp1とApp2が備えられる。S1において、GW1はパケットを受信し、S2においてApp1へパケットを転送する。S3では、(i)において、ホスト2が、トラヒック流入元のホスト(ホスト1)を識別するマーク付与とそれに基づくPBRを行う。(ii)において、ホスト1が、流入元のGW(GW1)を識別するマーク付与とそれに基づくPBRを行う。
つまり、(i)では、ホスト2で、パケットを流入元のホスト1に戻すPBRを行い、(ii)では、ホスト1で、パケットを流入元のGW1に戻すPBRを行う。
図7を参照して配置上の工夫(インスタンス配置方式)を説明する。図7に示すとおり、ホスト1にGW1とApp1を配置し、ホスト2にGW2とApp2を配置する。つまり、各ホスト内のGWを単一にする。これにより、図6の(ii)で示したような、ホスト内でGWを区別するためのコネクション追跡やPBR(図6の(i))設定を削減できる。
図7のS1~S4のフローの通り、基本的にはホスト1で処理を完結することができる。S11~S14のフローのとおり、異なるGWに再接続したフローやリソースの問題により単一ホストで処理を完結できないフローのみを対象に、流入元のフローを識別するためのコネクション追跡やPBR(図6の(i))を行い、性能劣化を低減する。
以下では、本実施の形態に係る提案内容である提案1~提案3のそれぞれについて説明する。
(提案1:最小構成)
提案1として本実施の形態に係るシステムの最小構成について説明する。本実施の形態に係るシステムでは、デバイスからGW/Appへの方向で通信確立するサービスに着目し、Ingressトラヒックを適切なGWで処理し、Egressトラヒックを流入元のGWやそのホストサーバに戻すポリシーベースルーティング(PBR)を行う。
提案1として本実施の形態に係るシステムの最小構成について説明する。本実施の形態に係るシステムでは、デバイスからGW/Appへの方向で通信確立するサービスに着目し、Ingressトラヒックを適切なGWで処理し、Egressトラヒックを流入元のGWやそのホストサーバに戻すポリシーベースルーティング(PBR)を行う。
具体的には、connmarkとmarkに基づくPBRを段階的に設定する。これにより、パケットヘッダの書き換えが不要なため、GW変更時にセッションが切れない。すなわち、アプリケーション処理に影響を与えない。
また、本システムでは、Connmarkの処理はフローに対して動的に行われ、その設定数はホスト単位/GW単位となる。これにより、Dev単位での設定が必要となる従来方式と比較して少ない設定で済む。
図8に、ホスト1とホスト2を有するシステムにおいて、CPE1からのトラヒックを処理する場合の例を示す。図8に示すとおり、GW1は、CPE1宛の経路を保持する。1段階目の設定として、ホスト2において、CPE1とApp1との間の通信のパケットをCPE1へ戻す際に、ホスト1へ送るようにconnmark+PBRの設定がなされる。また、App1において、CPE1宛のトラヒックはGW1のEID(エンドポイント識別子)に戻す。
2段階目の設定として、ホスト1において、CPE1とAPP1との間の通信のパケットはGW1に送るようにconnmark+PBRの設定がなされる。
(提案2:配置最適化)
前述したように、本実施の形態では、インスタンス配置を最適化して、Connmark/PBRの処理や設定をさらに集約することとしている。
前述したように、本実施の形態では、インスタンス配置を最適化して、Connmark/PBRの処理や設定をさらに集約することとしている。
すなわち、ホスト内のGWを極力単一にすることで、GW識別用のconnmark設定を削減する。また、ホストごとのApp数を極力均等に配置して、単一ホスト内でGW/Appの処理が完結できるようにすることで、ホスト識別用のconnmark/PBRの対象となるフロー数と転送遅延を削減することとしている。
図9に、各ホスト内のGW数が一つの場合(例:サービス初期)を示し、図10に、ホストごとのGW数が複数の場合(例:ピーク時)を示す。
図9に示す場合では、GW1へのIngressトラヒックは基本的に同じホスト1内のApp1で優先的に処理する。これにより、PBRは不要となり、トラヒックをApp1からホスト1に転送し、ホスト1のdefault route等でGW1に転送することができ、設定削減が可能となる。
また、ホスト1、2では、ホストをまたぐコネクションのみ追跡してPBRを行うので、追跡するコネクション数やPBRするフロー数を削減できる。例えば、ホスト2では、ホスト1から流入したパケットのみ追跡してマーキングする。また、Appで処理したマーク付きのパケットのみをホスト1にPBRでルーティングし、ホスト1のdefault route等でGW1に転送することができる。
図10の例では、前述したように、ホスト1内でGWを識別するためのconnmark/PBRが必要になる。
図10に示すように、ホスト1において、IngressトラヒックはGW1/3のインターフェースでconnmarkを行って、ホスト1への流入パケットのマークに基づき、パケットをGW1/3へPBRでルーティングする。
ホスト2では、ホスト1から流入したパケットのみ追跡してマーキングし、Appで処理したマーク付きのパケットのみをホスト1にPBRでルーティングし、ホスト1のdefault route等でGW1に転送する。
(提案3:方式設定自動化システム)
提案3においては、ホストの使用状況に基づいて前述の方式設定を自動的に行うシステムを採用することで、インスタンスの増減に追従して設定を行い、安定的な通信を可能にすることとしている。ホストの使用状況毎の構成例、設定タイミング、設定内容を、図11~図13を用いて説明する。
提案3においては、ホストの使用状況に基づいて前述の方式設定を自動的に行うシステムを採用することで、インスタンスの増減に追従して設定を行い、安定的な通信を可能にすることとしている。ホストの使用状況毎の構成例、設定タイミング、設定内容を、図11~図13を用いて説明する。
<ケース1:ホストに複数のGWが動作するケース>
ケース1の構成例を図11に示す。ケース1での設定タイミングは、GW起動時/削除時であり、設定内容は、(a)流入フローに対するConnmark設定(GW個数分)、及び、(b)戻りフローのマーク値に対応するGWに転送するためのPBR設定(GW個数分)である。なお、ケース1において、設定(a),(b)は、GWインスタンスが一個の場合には不要である。
ケース1の構成例を図11に示す。ケース1での設定タイミングは、GW起動時/削除時であり、設定内容は、(a)流入フローに対するConnmark設定(GW個数分)、及び、(b)戻りフローのマーク値に対応するGWに転送するためのPBR設定(GW個数分)である。なお、ケース1において、設定(a),(b)は、GWインスタンスが一個の場合には不要である。
<ケース2:ホストにAppが動作するケース>
ケース2の構成例を図12に示す。ケース2での設定タイミングは、App起動時/削除時であり、設定内容は、(c)流入フローに対するConnmark設定(ホスト数分)、及び、(d)戻りフローのマーク値に対応するGWに転送するためのPBR設定(ホスト数分)である。
ケース2の構成例を図12に示す。ケース2での設定タイミングは、App起動時/削除時であり、設定内容は、(c)流入フローに対するConnmark設定(ホスト数分)、及び、(d)戻りフローのマーク値に対応するGWに転送するためのPBR設定(ホスト数分)である。
<ケース3:ホストに複数GWとAppが動作するケース>
ケース3の構成例を図13に示す。ケース3での設定タイミングは、AppとGwの起動時/削除時であり、設定内容は、ケース1、2で説明した(a)~(d)である。以下では、上述した提案1~3に関する内容をより詳細に説明する。
ケース3の構成例を図13に示す。ケース3での設定タイミングは、AppとGwの起動時/削除時であり、設定内容は、ケース1、2で説明した(a)~(d)である。以下では、上述した提案1~3に関する内容をより詳細に説明する。
(提案1のルーティング方式における処理フロー)
図14を参照して、提案1のルーティング方式における処理フローを説明する。この処理フローでは、流入元のGW宛にアプリケーションからのreplyを返す。具体的な処理を、図14を参照して説明する。
図14を参照して、提案1のルーティング方式における処理フローを説明する。この処理フローでは、流入元のGW宛にアプリケーションからのreplyを返す。具体的な処理を、図14を参照して説明する。
S0において、Dev1は、ホスト2上のアプリ1に向けてパケットを送信する。S1において、CPE1は、パケットをEncapしてGW1宛てに送信する。S2において、GW1は、パケットを受信し、Decap後にパケットをアプリ1に送信する。
S3において、ホスト1は、request方向のパケットに対してconnmarkを行う。S4において、アプリ1が動作するホスト2においてrequest方向でsource macごとにconnmarkする。つまり、アプリ1が動作するホスト2上でsource mac addressをトリガーにしたconnmarkを行う。なお、connmarkのトリガーとしてsource mac addressを使用することは一例である。パケットに含まれている情報であって、かつ流入元のホストが特定可能な情報であればどのような情報を用いてもよい。例えばトンネリングヘッダの送信元IPアドレスなどを用いてもよい。
S5において、流入元の(GW1が動作する)ホスト1にパケットを転送する。つまり、Reply方向については、mark値に応じて、パケット流入元のホスト1にパケットを転送する。
S6において、ホスト1は、S3のマーク値に基づいてreplyパケットを流入元のGW1に転送する。なお、本例ではホスト1に複数GWが存在するので、それらを識別するためにこの設定が必要となる。
(入れ子構造について)
本実施の形態のシステムはVM/コンテナ入れ子構造でも実施することが可能である。ただし、入れ子構造では、インスタンス(コンテナ)の経路が、物理サーバセグメントで広告されていないため、IPIP等のトンネリングを用いて通信を実施する。
本実施の形態のシステムはVM/コンテナ入れ子構造でも実施することが可能である。ただし、入れ子構造では、インスタンス(コンテナ)の経路が、物理サーバセグメントで広告されていないため、IPIP等のトンネリングを用いて通信を実施する。
VM/コンテナ入れ子構造を採用する構成例を図15に示す。図15に示すとおり、インスタンスを収容するVM1,2でS1~S4の手順を行うことで通信を確立させる。物理サーバへの設定は不要である。具体的には下記のとおりである。
S1において、VM1は、CONNMARKによりフローにGW番号でマークをつける。S2において、VM2は、CONNMARKによりフローに流入元のホスト番号でマークをつける。S3において、VM2は、フローにマークされたホスト番号を見て対応するホストにIPIPでフローを転送する。S4において、VM1は、フローにマークされたGW番号を見て対応するGWにフローを転送する。
(配置決定方式の処理フロー)
提案2の配置最適化(図9,図10)について、図16を参照して、システムに含まれる各ホストに対するGW(インスタンスの例)の配置決定を行うための処理フローの例を説明する。配置決定処理は、後述する配置計算部300が実行する。ただし、デプロイはインスタンス管理部200が行う。ここでは、ホスト数、デプロイすべきGW数が予め与えられているとする。
提案2の配置最適化(図9,図10)について、図16を参照して、システムに含まれる各ホストに対するGW(インスタンスの例)の配置決定を行うための処理フローの例を説明する。配置決定処理は、後述する配置計算部300が実行する。ただし、デプロイはインスタンス管理部200が行う。ここでは、ホスト数、デプロイすべきGW数が予め与えられているとする。
S101~S106において、GWを1つのホストに1つずつデプロイする。それでも全GWをデプロイできない場合に、S107~S110において、ホストに追加のGWをデプロイする。S101~S106とS107~S110はいずれもホストについての繰り返しなので、ここでは、例として、「ホストA」を対象として各ステップを説明する。
S101において、配置計算部300はホストAの状態を確認する。状態を確認するとは、配置決定に必要な情報を取得することである。S102において、配置計算部300は、ホストAのリソースの有無を確認し、GWのデプロイのためのリソースが有る場合はS103に進み、無い場合はS106に進む。
S103において、配置計算部300は、ホストAのGW数を確認し、GWが有る場合はS106に進み、無い場合はS104に進む。
S104において、ホストAに対してGWをデプロイする。S105~S106において、未デプロイGWが無ければ処理を終了し、未デプロイGWがあり、かつ、未確認ホストがあればS101に戻り、次のホストの処理を行う。
未デプロイGWがあり、かつ、未確認ホストが無ければ、S107において、ホストAの状態を確認し、S108においてホストAのリソース確認を行う。リソースがあればS109においてホストAにGWをデプロイする。リソースが無ければS110に進む。
S110において、未デプロイGW及び未確認ホストがあれば、別のホストについて、S108,S109の処理を行う。
(設定自動化システムの処理フロー)
提案3の設定自動化(図11~図13)の処理フローについて、図17を参照して説明する。ここでの処理は、後述するインスタンス管理部200、設定投入部400等により行われる。
提案3の設定自動化(図11~図13)の処理フローについて、図17を参照して説明する。ここでの処理は、後述するインスタンス管理部200、設定投入部400等により行われる。
S201において、インスタンス管理部200は、リソースとして、ホスト数、インスタンス数を決定する。S202において、インスタンス管理部200(あるいは配置計算部300)は、インスタンスを配置する。ここでは、ホスト内のGWは極力、単一とするとともに、ホストあたりのアプリ数を均等にする。
S203において、設定投入部400は、ホスト管理部100からの情報に基づいて、ホストの状態を判定し、Appが動作している場合はS204に進み、GWとAPPが動作している場合はS205に進み、GWのみが動作している場合はS206に進む。
S204において、設定投入部400は、図12の設定投入を行い、S205において、図13の設定投入を行う。
S206において、GWの数が1つであればS208に進む。GWの数が複数であればS207において、図11の設定投入を行う。S208において、インスタンス管理部200は、使用リソース監視を行う。
(システム全体構成)
図18に、本実施の形態におけるシステムの全体構成例を示す。図18に示すように、本システムは、CPE10、GW解決部20、GW1が動作するホスト1(ホストサーバ)、App1が動作するホスト2、ホスト管理部100、DB30、インスタンス管理部200、配置計算部300、設定投入部400を有する。
図18に、本実施の形態におけるシステムの全体構成例を示す。図18に示すように、本システムは、CPE10、GW解決部20、GW1が動作するホスト1(ホストサーバ)、App1が動作するホスト2、ホスト管理部100、DB30、インスタンス管理部200、配置計算部300、設定投入部400を有する。
図18に示す各部は、単独の装置であってもよいし、複数の部位が1つの装置を構成してもよい。GW解決部20、ホスト管理部100、インスタンス管理部200、配置計算部300、設定投入部400をそれぞれGW解決装置20、ホスト管理装置100、インスタンス管理装置200、配置計算装置300、設定投入装置400と呼んでもよい。各部(各装置)の概要は下記のとおりである。
CPE10はクライアント端末(デバイス)を収容するNW装置である。CPE10はGW解決部20に問い合わせることで接続先のGWを決定する。
クラウド上の仮想基盤ではサービス向けのNW機能として動作するインスタンスであるGW1と、アプリケーションロジックを提供するApp1が、それぞれホスト1、2上で動作する。
ホスト管理部100はこれらのホストのホスト名やネットワーク情報・リソース情報をDB30で管理する。配置計算部300は、ホストの台数やリソース状況に基づき、インスタンスの配置先となるホストを決定する。
インスタンス管理部200は、配置計算部300の決定に基づきインスタンスを配置し、インスタンスのIDやネットワーク情報・リソース情報を管理する。設定投入部400は、インスタンスの配置状況に基づき各ホストにネットワーク設定を行う。
以下では、各部の構成と動作をより詳細に説明する。なお、以下で説明する各部の構成と動作は一例である。これまでに説明した設定や動作を実現できるのであれば、装置(部位)の構成や動作はどのようなものであってもよい。
(ホスト管理部100)
ホスト管理部100は、ホスト名やネットワーク情報・リソース情報を各ホストから取得しDBで管理する。図19に、ホスト管理部100の構成を示す。図19に示すように、ホスト管理部100は、ホスト情報DB110、ホスト情報取得部120、配信API機能部130を有する。
ホスト管理部100は、ホスト名やネットワーク情報・リソース情報を各ホストから取得しDBで管理する。図19に、ホスト管理部100の構成を示す。図19に示すように、ホスト管理部100は、ホスト情報DB110、ホスト情報取得部120、配信API機能部130を有する。
ホスト情報取得部120は、ホストにアクセスして上述の情報を取得し、取得した情報をホスト情報DB110に格納する。ホスト情報DB110は、HostのIDやIPアドレス/macアドレス等のネットワーク情報、ホストリソースを管理する。
外部の配置計算部300、設定投入部400は、配信API機能部130経由でホスト情報DB110にアクセスし、ネットワーク情報やリソース利用率などの、処理に必要な情報を取得する。図20に、ホスト情報DB110に格納される情報の例を示す。
(インスタンス管理部200)
インスタンス管理部200はインスタンスをデプロイする。また、インスタンス名やインスタンス種別・ネットワーク情報を取得しDBで管理する。図21にインスタンス管理部200の構成例を示す。
インスタンス管理部200はインスタンスをデプロイする。また、インスタンス名やインスタンス種別・ネットワーク情報を取得しDBで管理する。図21にインスタンス管理部200の構成例を示す。
図21に示すように、インスタンス管理部200は、インスタンス情報DB210、インスタンスデプロイ機能部220、インスタンス情報取得部230、配信API機能部240を有する。
インスタンスデプロイ機能部220は、配置計算部30の指示に基づいてホストを選択してインスタンスをデプロイする。
インスタンス情報取得部230は、インスタンスにアクセスして上述の情報を取得してインスタンス情報DB210に格納する。インスタンス情報D210Bは、インスタンスのIDやIPアドレス/macアドレス等のネットワーク情報、ホストリソースを管理する。
外部の配置計算部300、設定投入部400は、配信API機能部240経由でインスタンス情報DB210にアクセスし、アプリ種別やネットワーク情報、動作しているホスト情報などの必要な情報を取得する。図22に、インスタンス情報DB210に格納される情報の例を示す。
(配置計算部300)
配置計算部300は、インスタンスをデプロイするホストを決定する。図23に、配置計算部300の構成例を示す。図23に示しように、配置計算部300は、情報取得部310、配置決定部320、配置指示部330を有する。
配置計算部300は、インスタンスをデプロイするホストを決定する。図23に、配置計算部300の構成例を示す。図23に示しように、配置計算部300は、情報取得部310、配置決定部320、配置指示部330を有する。
情報取得部310は、配信API機能部経由でインスタンス管理部200/ホスト管理部100にアクセスし、ホストごとのリソース空き状況と既に動作しているGWインスタンスやAPPインスタンスの数を取得する。
配置決定部320は、GW配置決定処理の流れ(図16)に沿ってGWインスタンスの配置先ホストを決定する。また、APPインスタンスについては、ホストリソースが許容する限り、ホスト単位でAPPの種類ごとのインスタンス数ができるだけ均等になるように、APPインスタンスの配置先ホストを決定する。
配置指示部330は、配置決定部320の計算結果に基づき、インスタンス管理部200へ配置方法を指示する。
(設定投入部400)
設定投入部400は本実施の形態に係る技術で必要となるconnmarkやPBRの設定をホストに対して行う。
設定投入部400は本実施の形態に係る技術で必要となるconnmarkやPBRの設定をホストに対して行う。
図24に、設定投入部400の構成例を示す。図24に示すように、設定投入部400は、ホストパラメータDB410、インスタンスパラメータDB420、テーブル管理DB430、情報取得部440、設定生成部450、設定投入処理部460を有する。
情報取得部440は、配信API機能部経由でインスタンス管理部200/ホスト管理部100にアクセスし、ホストごとのリソース空き状況と、動作しているGWインスタンスの数、APPインスタンス、設定に必要なネットワーク情報を取得し、対応するDBに格納する。
インスタンスパラメータDB420は、インスタンスの動作状況やインターフェース名を管理する。ホストパラメータDB410は、ホストの中のインスタンスの動作情報やアドレス情報を管理する。テーブル管理DB430は、PBRのためのテーブルがどのホストで動作しているかを管理する。
設定生成部450は、各種DBからの情報に基づいてホストごとのインスタンス数の状態判定を行い、connmark、PBRのための設定を生成する。
設定の一例としては、(1)GWのインターフェース名に基づいたconnmark、(2)ホストのmacアドレスに基づいたconnmark、(3)各種mark値に基づくポリシーベースルーティングを行うための設定、等が挙げられる。
設定投入処理部460は、設定生成部450の計算結果に基づき、該当のホストに設定を行う。
図25に、テーブル管理DB430、インスタンスパラメータDB420、ホストパラメータDB410それぞれについて、格納される情報の例を示す。
(シーケンス例1)
サービス開始時のインスタンスの配置として、ホスト1,2にインスタンスを配置する場合のシーケンス例を図26に示す。なお、ホスト1、2はそれぞれ、物理マシンでもよいし、仮想マシンでもよい。図26に示すシーケンスは、サービス開始時のホストの起動、インスタンスの配置計算、インスタンスの起動、ホストへの設定投入の手順を示している。
サービス開始時のインスタンスの配置として、ホスト1,2にインスタンスを配置する場合のシーケンス例を図26に示す。なお、ホスト1、2はそれぞれ、物理マシンでもよいし、仮想マシンでもよい。図26に示すシーケンスは、サービス開始時のホストの起動、インスタンスの配置計算、インスタンスの起動、ホストへの設定投入の手順を示している。
まず、S1~S4においてホスト管理部100がサービスを構成する基盤の各ホストを起動し、起動した各ホストの情報を収集する。収集した情報は、例えば、図20に示したようにホスト情報DB110に格納される。
S5において、インスタンス管理部200はホスト管理部100からホスト情報を取得する。S6において、配置計算部300は、ホスト管理部100からインスタンス情報を取得する。
S7において、インスタンス管理部200から配置計算部300に対し、インスタンスの配置を計算する要求を行う。S8において、配置計算部300は、インスタンス及びホストの情報をもとに配置を決定し、S9において、インスタンス管理部200に対して配置を指示する。
この指示に基づいて、S10~S13において、インスタンス管理部200は、ホストを選択してインスタンスを起動する。起動に伴って、インスタンス情報がインスタンス管理部200に送信され、インスタンス情報DB(図22)に格納される。
設定投入部400は、S14においてホスト管理部100からホスト情報を取得し、S15において、インスタンス管理部200からインスタンス情報を取得する。S16において、設定投入部400は、取得した情報を用いて、connmarkやPBRといった必要なネットワーク設定を作成し、S17~S18において、各ホストに設定を投入する。
(シーケンス例2)
次に、本実施の形態において想定するパケットの転送手順として、ホスト1にGW1が配置され、ホスト2にApp1が配置されている場合における転送手順を、図27を参照して説明する。
次に、本実施の形態において想定するパケットの転送手順として、ホスト1にGW1が配置され、ホスト2にApp1が配置されている場合における転送手順を、図27を参照して説明する。
デバイス50が送信したパケットはCPE10に到着し(S1)、GW解決部20への問い合わせにより接続先のGWを解決(S2,S3)した上で、GW1が動作するホスト1まで転送される(S4)。
ホスト1では、流入パケットをGW1に転送する(S5)。S6において、GW1がこのパケットに必要なNW処理を施した後、S7において、App1へ通信するために再びホスト1に転送する。
ホスト1は、S8において、GW1に対応するインターフェース名等でconnmarkを行う。ホスト1は、S9において、フロー識別のためのマークが付けられたパケットを、App1に通信するために、ホスト2に送信する。
S10において、ホスト2は、当該パケットに対し、source macアドレス(ここではホスト1のアドレス)をキーにしてconnmarkを行う。S11~S13において、App1でパケットのApp処理が行われる。
S14において、ホスト2は、S10で付加したマーク値とmac addressを対応させることで、App1で処理後の返りパケットをmarkに基づいてPBRする。これにより、パケットはホスト1に転送される(S15)。同様に、S16において、返りパケットを受信したホスト1では、GW1のインターフェース名に対応づけられたマーク値に従って、流入元のGW1にパケットを戻すPBRを行う。S17~S19において、NW処理がなされ、S20において、ホスト1からデバイス50にパケットが転送される。
(ハードウェア構成例)
GW解決部20、ホスト管理部100、インスタンス管理部200、配置計算部300、設定投入部400、GW解決装置20、ホスト管理装置100、インスタンス管理装置200、配置計算装置300、設定投入装置400、ホスト、GW、Appはいずれも、例えば、コンピュータにプログラムを実行させることにより実現できる。このコンピュータは、物理的なコンピュータであってもよいし、クラウド上の仮想マシンであってもよい。以下、GW解決部20、ホスト管理部100、インスタンス管理部200、配置計算部300、設定投入部400、GW解決装置20、ホスト管理装置100、インスタンス管理装置200、配置計算装置300、設定投入装置400、ホスト、GW、Appを総称して装置と呼ぶ。
GW解決部20、ホスト管理部100、インスタンス管理部200、配置計算部300、設定投入部400、GW解決装置20、ホスト管理装置100、インスタンス管理装置200、配置計算装置300、設定投入装置400、ホスト、GW、Appはいずれも、例えば、コンピュータにプログラムを実行させることにより実現できる。このコンピュータは、物理的なコンピュータであってもよいし、クラウド上の仮想マシンであってもよい。以下、GW解決部20、ホスト管理部100、インスタンス管理部200、配置計算部300、設定投入部400、GW解決装置20、ホスト管理装置100、インスタンス管理装置200、配置計算装置300、設定投入装置400、ホスト、GW、Appを総称して装置と呼ぶ。
すなわち、当該装置は、コンピュータに内蔵されるCPUやメモリ等のハードウェア資源を用いて、当該装置で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体(可搬メモリ等)に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。
図28は、上記コンピュータのハードウェア構成例を示す図である。図28のコンピュータは、それぞれバスBSで相互に接続されているドライブ装置1000、補助記憶装置1002、メモリ装置1003、CPU1004、インターフェース装置1005、表示装置1006、入力装置1007、出力装置1008等を有する。
当該コンピュータでの処理を実現するプログラムは、例えば、CD-ROM又はメモリカード等の記録媒体1001によって提供される。プログラムを記憶した記録媒体1001がドライブ装置1000にセットされると、プログラムが記録媒体1001からドライブ装置1000を介して補助記憶装置1002にインストールされる。但し、プログラムのインストールは必ずしも記録媒体1001より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置1002は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
メモリ装置1003は、プログラムの起動指示があった場合に、補助記憶装置1002からプログラムを読み出して格納する。CPU1004は、メモリ装置1003に格納されたプログラムに従って、当該装置に係る機能を実現する。インターフェース装置1005は、ネットワーク等に接続するためのインターフェースとして用いられる。表示装置1006はプログラムによるGUI(Graphical User Interface)等を表示する。入力装置1007はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。出力装置1008は演算結果を出力する。
(実施の形態のまとめ、効果)
以上説明したように、本実施の形態では、仮想化基盤環境で提供される、デバイスからサービスの方向で通信確立するサービスにおいて、conntrackに基づいたポリシーベースルーティングにより、返りパケットをゲートウェイインスタンスやその収容ホストへ段階的に戻すルーティング方式を提案した。
以上説明したように、本実施の形態では、仮想化基盤環境で提供される、デバイスからサービスの方向で通信確立するサービスにおいて、conntrackに基づいたポリシーベースルーティングにより、返りパケットをゲートウェイインスタンスやその収容ホストへ段階的に戻すルーティング方式を提案した。
より具体的には、GWの動作ホストにおいてGWに対応するインターフェースをキーにしたconnmarkを行い、Appの動作ホストにおいて送信元macアドレスをキーにしたconnmarkを行うことで、戻りの通信に対しmacアドレスに対応する流入元ホスト宛のPBRと、インターフェースに対応する流入元GW宛のPBRを行う。
また、上記方式の実現に必要な設定の集約を可能にするインスタンス配置方式を提案した。更に、ストでのインスタンス収容状況に基づき、上記方式の実現に必要な設定を動的に行う設定自動化システムを提案した。
本実施の形態により、アプリケーションが処理したパケットを適切なGWまで転送する技術において、端末のGW再接続時にもセッションが切れず、大量の経路の学習も必要としないこととすることができる。
また、本技術では、パケットヘッダの書き換えが不要なため,アプリケーション処理に影響を与えない。また、多数のAPPインスタンス(エンドポイント)に設定を投入することなく、オーバーヘッドの削減が見込まれる。
(付記)
以上の実施形態に関し、更に以下の付記項を開示する。
(付記項1)
デバイスから送信されたパケットに対してネットワーク処理を行うゲートウェイを備え、前記ゲートウェイから転送されたパケットに、転送元が前記ゲートウェイであることを示す第1のマークを付し、前記第1のマークを付したパケットを転送する第1のホストと、
アプリケーションを備え、前記第1のホストから転送されたパケットを受信し、当該パケットに、転送元が前記第1のホストであることを示す第2のマークを付け、前記第2のマークを付したパケットを前記アプリケーションに転送し、前記アプリケーションから転送されたパケットを、前記第2のマークに基づいて、前記第1のホストに転送する第2のホストと、を備え、
前記第1のホストは、前記第2のホストから受信したパケットを、前記第1のマークに基づいて、前記ゲートウェイに転送する
通信システム。
(付記項2)
前記第1のホストと前記第2のホストはそれぞれ、パケットへマークを付すためにconnmarkを使用し、マークの基づくパケットの転送のためにポリシーベースルーティングを使用する
付記項1に記載の通信システム。
(付記項3)
複数のホストを含む通信システムにおいてゲートウェイインスタンスをデプロイするホストを決定するための配置計算装置であって、
メモリと、
前記メモリに接続された少なくとも1つのプロセッサと、
を含み、
前記プロセッサは、
各ホストのリソース情報及びデプロイされているゲートウェイインスタンス数を取得し、
ホストにゲートウェイインスタンスをデプロイするためのリソースがある限り、各ホストに1つずつゲートウェイインスタンスをデプロイすることを決定し、デプロイすることが決定されていないゲートウェイインスタンスについて、ゲートウェイインスタンスがデプロイ済みのホストにデプロイすることを決定する
配置計算装置。
(付記項4)
アプリケーションインスタンスに関して、前記プロセッサは、インスタンス数ができるだけホスト間で均等になるように、各ホストへの配置を決定する
付記項3に記載の配置計算装置。
(付記項5)
複数のホストを含む通信システムにおいてホストに対する設定を投入する設定投入装置であって、
メモリと、
前記メモリに接続された少なくとも1つのプロセッサと、
を含み、
前記プロセッサは、
インスタンスが配置された各ホストにおけるホスト情報とインスタンス情報を取得し、
ゲートウェイインスタンスが複数個配置されたホストに対して、ゲートウェイインスタンス毎の流入フローに対するマーク処理のための設定と、ゲートウェイインスタンス毎の戻りフローに対するマークを用いたルーティングのための設定を生成し、アプリケーションインスタンスが配置されたホストに対して、流入フローに対するマーク処理のための設定と、戻りフローに対するマークを用いたルーティングのための設定を生成し、
生成した設定を該当のホストに投入する
設定投入装置。
(付記項6)
ゲートウェイを備える第1のホストと、アプリケーションを備える第2のホストを含む通信システムにおける通信方法であって、
前記第1のホストが、デバイスから送信されたパケットを前記ゲートウェイに転送し、前記ゲートウェイから転送されたパケットに、転送元が前記ゲートウェイであることを示す第1のマークを付し、前記第1のマークを付したパケットを前記第2のホストに転送し、
前記第2のホストが、前記第1のホストから転送されたパケットを受信し、当該パケットに、転送元が前記第1のホストであることを示す第2のマークを付け、前記第2のマークを付したパケットを前記アプリケーションに転送し、前記アプリケーションから転送されたパケットを、前記第2のマークに基づいて、前記第1のホストに転送し、
前記第1のホストは、前記第2のホストから受信したパケットを、前記第1のマークに基づいて、前記ゲートウェイに転送する
通信方法。
(付記項7)
コンピュータに、付記項3又は4に記載の配置計算装置における各処理を実行させるプログラムを記憶した非一時的記憶媒体。
(付記項8)
コンピュータに、付記項5に記載の設定投入装置における各処理を実行させるプログラムを記憶した非一時的記憶媒体。
以上の実施形態に関し、更に以下の付記項を開示する。
(付記項1)
デバイスから送信されたパケットに対してネットワーク処理を行うゲートウェイを備え、前記ゲートウェイから転送されたパケットに、転送元が前記ゲートウェイであることを示す第1のマークを付し、前記第1のマークを付したパケットを転送する第1のホストと、
アプリケーションを備え、前記第1のホストから転送されたパケットを受信し、当該パケットに、転送元が前記第1のホストであることを示す第2のマークを付け、前記第2のマークを付したパケットを前記アプリケーションに転送し、前記アプリケーションから転送されたパケットを、前記第2のマークに基づいて、前記第1のホストに転送する第2のホストと、を備え、
前記第1のホストは、前記第2のホストから受信したパケットを、前記第1のマークに基づいて、前記ゲートウェイに転送する
通信システム。
(付記項2)
前記第1のホストと前記第2のホストはそれぞれ、パケットへマークを付すためにconnmarkを使用し、マークの基づくパケットの転送のためにポリシーベースルーティングを使用する
付記項1に記載の通信システム。
(付記項3)
複数のホストを含む通信システムにおいてゲートウェイインスタンスをデプロイするホストを決定するための配置計算装置であって、
メモリと、
前記メモリに接続された少なくとも1つのプロセッサと、
を含み、
前記プロセッサは、
各ホストのリソース情報及びデプロイされているゲートウェイインスタンス数を取得し、
ホストにゲートウェイインスタンスをデプロイするためのリソースがある限り、各ホストに1つずつゲートウェイインスタンスをデプロイすることを決定し、デプロイすることが決定されていないゲートウェイインスタンスについて、ゲートウェイインスタンスがデプロイ済みのホストにデプロイすることを決定する
配置計算装置。
(付記項4)
アプリケーションインスタンスに関して、前記プロセッサは、インスタンス数ができるだけホスト間で均等になるように、各ホストへの配置を決定する
付記項3に記載の配置計算装置。
(付記項5)
複数のホストを含む通信システムにおいてホストに対する設定を投入する設定投入装置であって、
メモリと、
前記メモリに接続された少なくとも1つのプロセッサと、
を含み、
前記プロセッサは、
インスタンスが配置された各ホストにおけるホスト情報とインスタンス情報を取得し、
ゲートウェイインスタンスが複数個配置されたホストに対して、ゲートウェイインスタンス毎の流入フローに対するマーク処理のための設定と、ゲートウェイインスタンス毎の戻りフローに対するマークを用いたルーティングのための設定を生成し、アプリケーションインスタンスが配置されたホストに対して、流入フローに対するマーク処理のための設定と、戻りフローに対するマークを用いたルーティングのための設定を生成し、
生成した設定を該当のホストに投入する
設定投入装置。
(付記項6)
ゲートウェイを備える第1のホストと、アプリケーションを備える第2のホストを含む通信システムにおける通信方法であって、
前記第1のホストが、デバイスから送信されたパケットを前記ゲートウェイに転送し、前記ゲートウェイから転送されたパケットに、転送元が前記ゲートウェイであることを示す第1のマークを付し、前記第1のマークを付したパケットを前記第2のホストに転送し、
前記第2のホストが、前記第1のホストから転送されたパケットを受信し、当該パケットに、転送元が前記第1のホストであることを示す第2のマークを付け、前記第2のマークを付したパケットを前記アプリケーションに転送し、前記アプリケーションから転送されたパケットを、前記第2のマークに基づいて、前記第1のホストに転送し、
前記第1のホストは、前記第2のホストから受信したパケットを、前記第1のマークに基づいて、前記ゲートウェイに転送する
通信方法。
(付記項7)
コンピュータに、付記項3又は4に記載の配置計算装置における各処理を実行させるプログラムを記憶した非一時的記憶媒体。
(付記項8)
コンピュータに、付記項5に記載の設定投入装置における各処理を実行させるプログラムを記憶した非一時的記憶媒体。
以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
10 CPE
20 GW解決部
30 DB
50 デバイス
100 ホスト管理部
110 ホスト情報DB
120 ホスト情報取得部
130 配信API機能部
200 インスタンス管理部
210 インスタンス情報DB
220 インスタンスデプロイ機能部
230 インスタンス情報取得部
240 配信API機能部
300 配置計算部
310 情報取得部
320 配置決定部
330 配置指示部
400 設定投入部
410 ホストパラメータDB
420 インスタンスパラメータDB
430 テーブル管理DB
440 情報取得部
450 設定生成部
460 設定投入処理部
1000 ドライブ装置
1001 記録媒体
1002 補助記憶装置
1003 メモリ装置
1004 CPU
1005 インターフェース装置
1006 表示装置
1007 入力装置
1008 出力装置
20 GW解決部
30 DB
50 デバイス
100 ホスト管理部
110 ホスト情報DB
120 ホスト情報取得部
130 配信API機能部
200 インスタンス管理部
210 インスタンス情報DB
220 インスタンスデプロイ機能部
230 インスタンス情報取得部
240 配信API機能部
300 配置計算部
310 情報取得部
320 配置決定部
330 配置指示部
400 設定投入部
410 ホストパラメータDB
420 インスタンスパラメータDB
430 テーブル管理DB
440 情報取得部
450 設定生成部
460 設定投入処理部
1000 ドライブ装置
1001 記録媒体
1002 補助記憶装置
1003 メモリ装置
1004 CPU
1005 インターフェース装置
1006 表示装置
1007 入力装置
1008 出力装置
Claims (8)
- デバイスから送信されたパケットに対してネットワーク処理を行うゲートウェイを備え、前記ゲートウェイから転送されたパケットに、転送元が前記ゲートウェイであることを示す第1のマークを付し、前記第1のマークを付したパケットを転送する第1のホストと、
アプリケーションを備え、前記第1のホストから転送されたパケットを受信し、当該パケットに、転送元が前記第1のホストであることを示す第2のマークを付け、前記第2のマークを付したパケットを前記アプリケーションに転送し、前記アプリケーションから転送されたパケットを、前記第2のマークに基づいて、前記第1のホストに転送する第2のホストと、を備え、
前記第1のホストは、前記第2のホストから受信したパケットを、前記第1のマークに基づいて、前記ゲートウェイに転送する
通信システム。 - 前記第1のホストと前記第2のホストはそれぞれ、パケットへマークを付すためにconnmarkを使用し、マークの基づくパケットの転送のためにポリシーベースルーティングを使用する
請求項1に記載の通信システム。 - 複数のホストを含む通信システムにおいてゲートウェイインスタンスをデプロイするホストを決定するための配置計算装置であって、
各ホストのリソース情報及びデプロイされているゲートウェイインスタンス数を取得する情報取得部と、
ホストにゲートウェイインスタンスをデプロイするためのリソースがある限り、各ホストに1つずつゲートウェイインスタンスをデプロイすることを決定し、デプロイすることが決定されていないゲートウェイインスタンスについて、ゲートウェイインスタンスがデプロイ済みのホストにデプロイすることを決定する配置決定部と
を備える配置計算装置。 - アプリケーションインスタンスに関して、前記配置決定部は、インスタンス数ができるだけホスト間で均等になるように、各ホストへの配置を決定する
請求項3に記載の配置計算装置。 - 複数のホストを含む通信システムにおいてホストに対する設定を投入する設定投入装置であって、
インスタンスが配置された各ホストにおけるホスト情報とインスタンス情報を取得する情報取得部と、
ゲートウェイインスタンスが複数個配置されたホストに対して、ゲートウェイインスタンス毎の流入フローに対するマーク処理のための設定と、ゲートウェイインスタンス毎の戻りフローに対するマークを用いたルーティングのための設定を生成し、アプリケーションインスタンスが配置されたホストに対して、流入フローに対するマーク処理のための設定と、戻りフローに対するマークを用いたルーティングのための設定を生成する設定生成部と、
前記設定生成部により生成した設定を該当のホストに投入する設定投入部と
を備える設定投入装置。 - ゲートウェイを備える第1のホストと、アプリケーションを備える第2のホストを含む通信システムにおける通信方法であって、
前記第1のホストが、デバイスから送信されたパケットを前記ゲートウェイに転送し、前記ゲートウェイから転送されたパケットに、転送元が前記ゲートウェイであることを示す第1のマークを付し、前記第1のマークを付したパケットを前記第2のホストに転送し、
前記第2のホストが、前記第1のホストから転送されたパケットを受信し、当該パケットに、転送元が前記第1のホストであることを示す第2のマークを付け、前記第2のマークを付したパケットを前記アプリケーションに転送し、前記アプリケーションから転送されたパケットを、前記第2のマークに基づいて、前記第1のホストに転送し、
前記第1のホストは、前記第2のホストから受信したパケットを、前記第1のマークに基づいて、前記ゲートウェイに転送する
通信方法。 - コンピュータを、請求項3又は4に記載の配置計算装置における各部として機能させるためのプログラム。
- コンピュータを、請求項5に記載の設定投入装置における各部として機能させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2022/008933 WO2023166626A1 (ja) | 2022-03-02 | 2022-03-02 | 通信システム、配置計算装置、設定投入装置、通信方法、及びプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2022/008933 WO2023166626A1 (ja) | 2022-03-02 | 2022-03-02 | 通信システム、配置計算装置、設定投入装置、通信方法、及びプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023166626A1 true WO2023166626A1 (ja) | 2023-09-07 |
Family
ID=87883201
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2022/008933 WO2023166626A1 (ja) | 2022-03-02 | 2022-03-02 | 通信システム、配置計算装置、設定投入装置、通信方法、及びプログラム |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO2023166626A1 (ja) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2014511616A (ja) * | 2011-02-23 | 2014-05-15 | マカフィー, インコーポレイテッド | 論理装置、処理方法及び処理装置 |
JP2014160451A (ja) * | 2013-01-24 | 2014-09-04 | Ricoh Co Ltd | 情報処理システム及び情報処理方法 |
JP2015219873A (ja) * | 2014-05-21 | 2015-12-07 | コニカミノルタ株式会社 | サーバ装置、ゲートウェイ装置、画像処理システム、サーバ装置の制御方法、ゲートウェイ装置の制御方法、サーバ装置の制御プログラム、及びゲートウェイ装置の制御プログラム |
-
2022
- 2022-03-02 WO PCT/JP2022/008933 patent/WO2023166626A1/ja unknown
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2014511616A (ja) * | 2011-02-23 | 2014-05-15 | マカフィー, インコーポレイテッド | 論理装置、処理方法及び処理装置 |
JP2014160451A (ja) * | 2013-01-24 | 2014-09-04 | Ricoh Co Ltd | 情報処理システム及び情報処理方法 |
JP2015219873A (ja) * | 2014-05-21 | 2015-12-07 | コニカミノルタ株式会社 | サーバ装置、ゲートウェイ装置、画像処理システム、サーバ装置の制御方法、ゲートウェイ装置の制御方法、サーバ装置の制御プログラム、及びゲートウェイ装置の制御プログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112470436B (zh) | 用于提供多云连通性的***、方法、以及计算机可读介质 | |
US20220377045A1 (en) | Network virtualization of containers in computing systems | |
EP3466037B1 (en) | Subnet stretching via layer three communications | |
US11502920B1 (en) | Multi-carrier access to provider substrate extensions | |
US9935920B2 (en) | Virtualization gateway between virtualized and non-virtualized networks | |
US11848800B2 (en) | Connecting virtual computer networks with overlapping IP addresses using transit virtual computer network | |
CN108347493B (zh) | 混合云管理方法、装置和计算设备 | |
WO2017113231A1 (zh) | 一种报文传输的方法、装置和*** | |
US11159344B1 (en) | Connectivity of cloud edge locations to communications service provider networks | |
US11470047B1 (en) | Managed virtual networks for computing cloud edge locations | |
US20070064661A1 (en) | Method, apparatus and system for maintaining mobility resistant IP tunnels using a mobile router | |
JP6076275B2 (ja) | 通信ネットワークの経路制御連携システム及び方法 | |
US10917460B2 (en) | Distributed load-balancing for software defined networks | |
US20210303366A1 (en) | Cloud-native proxy gateway to cloud resources | |
WO2016169218A1 (zh) | 一种网关虚拟化方法、***及计算机存储介质 | |
US11070475B2 (en) | Transparent migration of virtual network functions | |
WO2020209099A1 (ja) | 通信システム及び通信方法 | |
Lin et al. | On exploiting SDN to facilitate IPv4/IPv6 coexistence and transition | |
WO2023166626A1 (ja) | 通信システム、配置計算装置、設定投入装置、通信方法、及びプログラム | |
US11595347B1 (en) | Dual-stack network addressing in cloud provider network edge locations | |
Johansson et al. | Supporting user mobility with peer-to-peer-based application mobility in heterogeneous networks | |
US12052171B2 (en) | Communication system and communication method | |
CN114268604B (zh) | 访问服务的提供方法和*** | |
US20230337055A1 (en) | Usage of wireless telecommunication service provider autonomous system number (asn) in a cloud-native wireless telecommunication network | |
CN117278395A (zh) | 一种容器云平台环境下的网络配置方法和服务器 |
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: 22929772 Country of ref document: EP Kind code of ref document: A1 |