JP5782397B2 - Failure notification device and notification method - Google Patents

Description

  The present invention relates to a failure notification device and a notification method for notifying a virtual server of a network failure in a virtual network using a virtual server and a tunnel technology.

  In order to construct a network independent of existing network technology, a technology for constructing an overlay network (slice) by combining server virtualization technology and network tunnel technology has become widespread. Slice aims to construct a network using any network technology without depending on physical configuration or technology. In the slice, the virtual server plays the role of a node such as a router or a switch. The physical network is concealed by the tunnel, and the virtual servers appear to be adjacent to each other (directly connected). For example, even when the physical network is an Ethernet (registered trademark) network, it is aimed to construct a storage area network or an ATM slice.

  Assume that a failure occurs in the physical network and the tunnel between virtual servers is disconnected. In a normal physical network, when a network disconnection occurs, a link down is detected immediately in a node such as a router or a switch. Similarly, in a slice, when a tunnel is disconnected, it is desired that a virtual network interface of a virtual server operating as a node detects a link down. However, in the case of a virtual server, the Ethernet interface and the SCSI interface are connected to a software device (such as a virtual switch) provided by the physical server. For this reason, even when a failure occurs in the physical network, link down does not occur, and the connection is always maintained.

  There is a method for confirming communication between virtual switches in order to detect a link failure.

  In general alarm transfer described in Patent Document 1, when a link down occurs in the opposite device, the own device also notifies the failure to the connected network device by causing the link down. .

  In Patent Literature 2, the physical environment and the virtual environment are associated with each other, and the influence range of the virtual environment with respect to a failure in the physical environment is specified.

Japanese Patent Laid-Open No. 2003-110585 JP 2010-086516 A

  However, when a slice configures a storage area network using a SCSI device of a virtual server, there is no method for confirming communication between virtual servers, and therefore a link failure cannot be detected by the virtual server. Furthermore, even when a failure can be detected by the virtual switch, a case where the link between the virtual server and the virtual switch cannot be controlled is not considered.

  In the general alarm transfer of Patent Document 1, failure information can be appropriately notified to the end terminal through the point-to-point line, but in the case of a network, the link-down of the affected end terminal is appropriately generated. I can't let you. Furthermore, the case where the link between the virtual server and the virtual switch cannot be controlled is not considered.

  In Patent Document 2, when a failure is detected on the management network, it is necessary to notify the failure to the virtual server or the virtual switch. However, the virtual server is not connected to the management network, and the virtual server itself is also sliced. Since the user builds it independently, it is not possible to set a method for linking with a system that detects a failure.

  Therefore, according to the present invention, when a failure occurs in a physical network in a slice constructed by original network technology without depending on the technology of the physical network, the virtual server constituting the slice can detect the network failure. It is an object of the present invention to provide a failure notification device and a notification method.

  In order to solve the above problems, a failure notification device according to the present invention is a failure notification device for notifying a virtual server of a network failure in a virtual network using a virtual server and a tunnel technology, and is a network on a route extending a tunnel. Fault detection means for detecting a fault in the network, tunnel management means for specifying a virtual server that uses the tunnel if a fault is detected, and a virtual that connects the tunnel in which the fault is detected and the virtual server. Virtual switch management means for specifying a switch; and link-down means for bringing down the link between the virtual switch and the virtual server.

  Moreover, it is also preferable that the link-down means lowers the link between the virtual switch and the virtual server by deleting the link of the virtual switch.

  The link down means preferably deletes the virtual switch to bring down the link between the virtual switch and the virtual server.

  Moreover, it is also preferable that the failure detection means detects a failure by connecting a probe server to the virtual switch to which the virtual server is connected and confirming communication between the probe servers.

  The failure detection means preferably detects a failure by using EthernetOAM or ping.

  In addition, the virtual switch is preferably a software device having a SCSI initiator and a SCSI target.

  In order to solve the above problems, a failure notification method according to the present invention is a failure notification method for notifying a virtual server of a network failure in a virtual network using a virtual server and a tunnel technology, and is a network on a path through which a tunnel is established. A fault detection step for detecting a fault in the network, a tunnel management step for identifying a virtual server that uses the tunnel if a fault is detected, and a virtual that connects the tunnel in which the fault is detected and the virtual server. A virtual switch management step of specifying a switch; and a link down step of bringing down the link between the virtual switch and the virtual server.

  According to the present invention, in a virtual server that constitutes a virtual network (slice) constructed using an arbitrary network technology, no matter what tunnel technology is used for connection between the virtual servers, a network failure can be prevented. The effect that it can detect as link down can be acquired.

1 shows a network configuration of the present invention. The system block diagram of the failure notification apparatus of this invention is shown. The network structure of the Example of this invention is shown. The operation | movement flowchart of the Example of this invention is shown. 3 shows a network configuration according to another embodiment of the present invention. 3 shows a network configuration of another embodiment of the present invention.

  The best mode for carrying out the present invention will be described in detail below with reference to the drawings. FIG. 1 shows a network configuration of the present invention.

  The network of this embodiment includes a physical server 1, a virtual server 11 built in the physical server 1, a virtual switch 12, a virtual switch 13, a physical server 2, a virtual server 21 built in the physical server 2, a virtual server The switch 22, the virtual switch 23, the physical server 3, the virtual server 31 built in the physical server 3, the virtual switch 32, the virtual switch 33, the tunnel 4 built on the network connecting the physical server 1 and the physical server 2 The tunnel 5 is constructed on the network connecting the physical server 2 and the physical server 3.

  The physical servers 1, 2, and 3 are servers having a virtualization function, and include a plurality of virtual servers and a virtual switch having a layer 2 function. Tunnels 4 and 5 are constructed on the physical network between the physical server 1 and the physical server 2 and between the physical server 2 and the physical server 3. The virtual switch 13 and the virtual switch 22 are connected to the tunnel 4, and the virtual switch 23 and the virtual switch 32 are connected to the tunnel 5. By using the tunnel, the physical network is concealed from each virtual server, the virtual server 11 in the physical server 1 is the virtual server 21 in the physical server 2, and the virtual server 21 in the physical server 2 is in the physical server 3. The virtual server 31 appears to be directly connected to each other. A virtual network (slice) composed of the virtual server 11, the virtual server 21, and the virtual server 31 is created by the virtual switch and the tunnel.

  FIG. 2 shows a system configuration diagram of the failure notification device of the present invention. The failure notification device 6 includes a failure detection function 61, a tunnel management function 62, a virtual switch management function 63, and a link down function 64. The failure notification device 6 is created as one process in the physical server. A failure notification device process is created for each physical server in which a virtual server exists.

  The failure detection function 61 detects a failure of the network on the route through which the tunnel is established. The failure detection function 61 performs failure detection using Ethernet OAM (operations, administration, maintenance), which is a maintenance / management function of the Ethernet network, or ping for confirming the reachability of packets in the IP network. Further, it is possible to detect a failure by separately connecting a probe server to a virtual switch to which the virtual server is connected, and confirming the connectivity of the probe server.

  The tunnel management function 62 manages the virtual server that uses the tunnel. When a tunnel failure is detected, a virtual server using the tunnel is specified.

  The virtual switch management function 63 manages virtual switches that use the tunnel. When a tunnel failure is detected, the virtual switch that connects the tunnel where the failure is detected and the virtual server is specified.

  The link down function 64 brings down the link of this virtual switch. For example, the link down function 64 can bring down the link by deleting the link of the virtual switch or deleting the virtual switch.

  When the physical network fails, the link down function 64 brings down the link of the virtual switch, so that the virtual server constituting the virtual network can detect the network failure as the link down.

  In the present embodiment, the failure notification device 6 is shown as one process in the physical server, but the failure notification device 6 can also be created as one virtual server in the physical server. In this case, a virtual server of the failure notification device is created for each virtual switch.

  Examples of the present invention are shown below. Here, since the virtual server communicates with the outside through the tunnel, a virtual switch to which the virtual server is connected is constructed on the logical interface. For example, an operation method of the failure notification apparatus in the physical server R1 when the physical servers R1 and R2 as shown in FIG. 3 are connected by a GRE tunnel will be described.

In the physical server R1, a GRE tunnel is created using the following command.
# ip tunnel add netR2 mode gre remote 192.168.20.3 local 192.168.0.3
# ip link set netR2 up
# ip addr add 10.10.10.1 dev netR2

Similarly, on the physical server R2 side, a GRE tunnel is created using the following command.
# ip tunnel add netR1 mode gre remote 192.168.0.3 local 192.168.20.3
# ip link set netR1 up
# ip addr add 10.10.10.2 dev netR1

  Thereby, a tunnel is created in each physical server. The tunnel management function 62 manages that the GRE tunnel netR2 created here is connected to the physical server R2.

  Next, connect the tunnel and the virtual switch. For example, when Xen is used as the virtual server creation software, the GRE tunnel netR2 can be specified as a device to be linked when creating the virtual switch xenbr1 as follows.

# / etc / xen / scripts / network-bridge start vifnum = 1 bridge = xenbr1 netdev = netR2
The virtual switch management function 63 manages the tunnel netR2 and the virtual switch xenbr1 linked here.

  Finally, the virtual server connected to the created virtual switch xenbr1 is specified in the configuration file as follows in the case of Xen.

kernel = '/boot/vmlinuz-2.6.24-19-xen'
ramdisk = '/boot/initrd.img-2.6.24-19-xen'
memory = '128'
root = '/ dev / xvda2 ro'
disk = [
'tap: aio: /vm/domains/vm001/swap.img,xvda1,w',
'tap: aio: /vm/domains/vm001/disk.img,xvda2,w',
]
name = 'vm001'
vif = ['ip = 192.168.10.111, mac = 00: 16: 3E: A8: A0: 88, bridge = xenbr1']
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
extra = '2 console = xvc0'
Thereby, a virtual server linked to the tunnel xenbr1 is constructed.

  The failure detection function 61 detects a failure in a route along the tunnel using ping. From the information of the tunnel management function 62, the physical server R1 in which the failure notification device 6 is operating acquires information that establishes a tunnel with the physical server R2. Since the physical server R2 is connected by a GRE tunnel, a failure is detected by pinging the IP address 192.168.20.3 of the physical server R2.

  When there is no ping response from the physical server R2, the failure detection function 61 notifies the tunnel management function 62 of failure detection. In the tunnel management 62, the virtual switch management function 63 acquires information on the virtual switch xenbr1 created on the failed GRE tunnel netR2.

Next, the link down function 64 deletes the virtual switch xenbr1 by the following command.
# ifdown xenbr1
# ifdown netR2
# brctl delif xenbr1 netR2
# brctl delbr xenbr1

The failure notification device 6 manages virtual switches according to the flowchart of FIG.
Step 1: The failure detection function 61 performs alive monitoring of the partner communication device or switch using Ping or EtherOAM.
Step 2: The failure detection function 61 confirms whether there is a response from the opposite device (the partner communication device or switch). If there is a response, return to step 1 and monitor again. If there is no response, go to step 3.
Step 3: The tunnel management function 62 identifies the virtual server associated with the tunnel that does not respond, and the virtual switch management function 63 identifies the tunnel that does not respond and the virtual switch that connects this virtual server, and links The down function 64 deletes this virtual switch.

  Another embodiment is shown in FIG. The physical servers 1, 2, and 3 are servers having a virtualization function, and are configured by a plurality of virtual servers and software devices having a SCSI initiator and a SCSI target. Tunnels 4 and 5 are constructed on the physical network between the physical server 1 and the physical server 2 and between the physical server 2 and the physical server 3. Software device 15 and software device 24 are connected to tunnel 4, and software device 25 and software device 34 are connected to tunnel 5. By using the tunnel, the physical network is concealed from each virtual server, the virtual server 11 in the physical server 1 is the virtual server 21 in the physical server 2, and the virtual server 21 in the physical server 2 is in the physical server 3. The virtual server 31 appears to be directly connected to each other. A virtual network (slice) composed of the virtual server 11, the virtual server 21, and the virtual server 31 is created by the software device and the tunnel.

  Examples of the present invention are shown below. Here, since the virtual server communicates with the outside through a tunnel, a software device to which the virtual server is connected is constructed on the logical interface. For example, an operation method of the failure notification device in the physical server R1 when the physical servers R1 and R2 as shown in FIG. 6 are connected by an iSCSI session will be described.

The physical server R2 uses a SCSI target subsystem for Linux (SCST) so that the SCSI device can be accessed from the outside by iSCSI. For example, in order to make / dev / sdb of the physical server R1 accessible from the outside, the setting file / etc / scst. Make the following settings in conf.
HANDLER vdisk_fileio {
DEVICE disk01 {
filename / dev / sdb
nv_cache 1
}
}
TARGET_DRIVER iscsi {
enabled 1
TARGET iqn.2006-10.net.vlnb: tgt {
LUN 0 disk01
enabled 1
}
}

Next, the device set by using the following command is made accessible as an iSCSI device from the outside.
# modprobe scst
# modprobe scst_vdisk
# modprobe iscsi-scst
# iscsi-scstd
# scstadmin -config /etc/scst.conf

On the physical server R1 side, an iSCSI session is created using the following command.
# iscsiadm -m discovery -t sendtargets -p 192.168.20.3
# iscsiadm -m node -T iqn.2006-10.net.vlnb: tgt -p 192.168.20.3:3260,1 --login

  As a result, an iSCSI session is created in each physical server. The tunnel management function 62 manages that the iSCSI session created here is connected to the physical server R2.

  Next, the virtual server and the software device are linked. For example, when Xen is used as the virtual server creation software and the software device that has established the iSCSI session is / dev / sdc, it can be specified as follows.

kernel = '/boot/vmlinuz-2.6.24-19-xen'
ramdisk = '/boot/initrd.img-2.6.24-19-xen'
memory = '128'
root = '/ dev / xvda2 ro'
disk = [
'tap: aio: /vm/domains/vm001/swap.img,xvda1,w',
'tap: aio: /vm/domains/vm001/disk.img,xvda2,w',
'phy: / dev / sdc, sda, w',
]
name = 'vm001'
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
extra = '2 console = xvc0'
As a result, a virtual server linked to the software device / dev / sdc is constructed.

  The failure detection function 61 detects a failure in a route along the tunnel using ping. From the information of the tunnel management function 62, the physical server R1 in which the failure notification device 6 is operating acquires information that establishes a tunnel with the physical server R2. Since it is connected to the physical server R2 through an iSCSI session, a failure is detected by pinging the IP address 192.168.20.3 of the physical server R2.

  When there is no ping response from the physical server R2, the failure detection function 61 notifies the tunnel management function 62 of failure detection. In the tunnel management 62, the virtual switch management function 63 acquires information on the software device / dev / sdc created on the iSCSI session in which a failure has occurred.

Next, the link down function 64 deletes the software device / dev / sdc by the following command.
# iscsiadm -m node -T iqn.2006-10.net.vlnb: tgt -p 192.168.20.3:3260,1 --logout

  Moreover, all the embodiments described above are illustrative of the present invention and are not intended to limit the present invention, and the present invention can be implemented in other various modifications and changes. Therefore, the scope of the present invention is defined only by the claims and their equivalents.

1, 2, 3 Physical server 4, 5 Tunnel 6 Failure notification device 11, 21, 31 Virtual server 12, 13, 22, 23, 32, 33 Virtual switch 14, 15, 24, 25, 34, 35 Software device 61 Failure Detection function 62 Tunnel management function 63 Virtual switch management function 64 Link down function

Claims (7)

In a virtual network using a virtual server and tunnel technology, a failure notification device for notifying a virtual server of a network failure,
A failure detection means for detecting a failure of the network on the route through the tunnel;
When a failure is detected, tunnel management means for specifying a virtual server using the tunnel; and
Virtual switch management means for identifying a virtual switch that connects the tunnel in which a failure is detected and the virtual server;
Link-down means for bringing down the link between the virtual switch and the virtual server;
A failure notification device comprising:   The failure notification device according to claim 1, wherein the link-down unit is configured to bring down the link between the virtual switch and the virtual server by deleting the link of the virtual switch.   The failure notification device according to claim 1, wherein the link-down unit is configured to delete a link between the virtual switch and the virtual server by deleting the virtual switch.   The failure detection means detects a failure by connecting a probe server to the virtual switch to which the virtual server is connected, and confirming communication between the probe servers. The failure notification device according to any one of the above.   The failure notification device according to claim 1, wherein the failure detection unit detects a failure by using Ethernet OAM or ping.   The failure notification device according to claim 1, wherein the virtual switch is a software device having a SCSI initiator and a SCSI target. A failure notification method for notifying a virtual server of a network failure in a virtual network using a virtual server and tunnel technology,
A fault detection step for detecting faults in the network on the route through which the tunnel is established;
A tunnel management step for identifying a virtual server using the tunnel when a failure is detected;
A virtual switch management step for identifying a virtual switch that connects the tunnel in which a failure is detected and the virtual server;
A link down step for bringing down the link between the virtual switch and the virtual server;
A failure notification method characterized by comprising:

Images