WO2012004872A1 - 管理装置、管理プログラムおよび管理方法 - Google Patents

管理装置、管理プログラムおよび管理方法 Download PDF

Info

Publication number
WO2012004872A1
WO2012004872A1 PCT/JP2010/061565 JP2010061565W WO2012004872A1 WO 2012004872 A1 WO2012004872 A1 WO 2012004872A1 JP 2010061565 W JP2010061565 W JP 2010061565W WO 2012004872 A1 WO2012004872 A1 WO 2012004872A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
management
key
moved
computer
Prior art date
Application number
PCT/JP2010/061565
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 EP10854426.3A priority Critical patent/EP2592556A1/en
Priority to JP2012523473A priority patent/JPWO2012004872A1/ja
Priority to PCT/JP2010/061565 priority patent/WO2012004872A1/ja
Publication of WO2012004872A1 publication Critical patent/WO2012004872A1/ja
Priority to US13/735,276 priority patent/US20130124913A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • G06F11/1484—Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3058—Monitoring arrangements for monitoring environmental properties or parameters of the computing system or of the computing system component, e.g. monitoring of power, currents, temperature, humidity, position, vibrations
    • 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/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements

Definitions

  • the present invention relates to a network management device, a management program, and a management method.
  • the VM host is a program that virtually realizes the operating environment of another computer system.
  • the VM guest operates as a virtual machine in the environment provided by the VM host, and is responsible for processing provided to the user. Even if the VM guest moves to a different VM host, the process can continue.
  • the disclosed technology has been made in view of the above, and aims to return the migrated VM guest to the VM host that was originally operating.
  • the moved VM guest can be returned to the originally operating VM host.
  • FIG. 1 is an explanatory diagram of a network according to the present embodiment.
  • FIG. 2 is a configuration diagram of the management apparatus according to the present embodiment.
  • FIG. 3 is an explanatory diagram of implementation by the management program.
  • FIG. 4 is an explanatory diagram of the relationship between the server hardware and the management program.
  • FIG. 5 is an explanatory diagram of an overlay network.
  • FIG. 6 is an explanatory diagram of a specific example of the definition of the hash table.
  • FIG. 7 is a diagram showing a specific example of the self-node table t2 shown in FIG.
  • FIG. 8 is a diagram showing a specific example of the domain table t3 shown in FIG.
  • FIG. 9 is a diagram showing a specific example of the node management table t4 shown in FIG.
  • FIG. 10 is a diagram showing a specific example of the routing table t5 shown in FIG.
  • FIG. 11 is a flowchart for explaining migration of a VM guest.
  • FIG. 12 is
  • FIG. 1 is an explanatory diagram of a network according to the present embodiment
  • FIG. 2 is a configuration diagram of a management apparatus according to the present embodiment.
  • the management target devices n1 to n4 are connected via a network. This network is the network to be monitored.
  • the monitoring device m1 is connected to the management target device n1, the monitoring device m2 is connected to the management target device n2, and the monitoring device m3 is connected to the management target device n3.
  • the monitoring devices m1 to m4 use the network interface of the monitoring target devices n1 to n4 to construct an overlay network for the network to which the monitoring target devices n1 to n4 belong.
  • the monitoring devices m1 to m4 function as nodes of this overlay network and can communicate with each other.
  • the management device m1 includes a sign monitoring unit m14, a guest moving unit m15, and a guest call back unit m16.
  • the sign monitoring unit m14 monitors a sign of failure of the management target device n1.
  • the guest moving unit m15 moves a process operating on the management target apparatus n1 to another management target apparatus when a sign of a failure of the management target apparatus n1 is detected.
  • the guest recall unit m16 performs a process of recalling the process moved from the management target apparatus n1 to another management target apparatus as necessary.
  • the management apparatus m1 includes an overlay network construction unit m11, a management target search unit m12, and a management information creation unit m13 in addition to the predictive monitoring unit m14, the guest moving unit m15, and the guest recalling unit m16.
  • the management device m1 is connected to a SAN (Storage Area Network) and causes the SAN to hold various types of information described later.
  • SAN Storage Area Network
  • the overlay network construction unit m11 is a processing unit that constructs an overlay network for a management target network, and includes a communication processing unit m21, a hash processing unit m22, an information acquisition unit m23, and a notification unit m24.
  • the communication processing unit m21 performs processing to communicate with other nodes on the network in which the management target device n1 participates as a node.
  • the hash processing unit m22 obtains a hash value from information acquired by the communication processing unit m21 from another node or information on the management target device, and uses the obtained hash value as a key of the overlay network.
  • the information acquisition unit m22 is a processing unit that acquires information from other nodes of the overlay network via the communication processing unit m21.
  • the notification unit m24 is a processing unit that notifies information to other nodes in the overlay network via the communication processing unit m21.
  • the management object search unit m12 sets, from the overlay network constructed by the overlay network construction unit m11, a management target apparatus m1 to which the management apparatus m1 is directly connected as a self node, and nodes belonging to the same management range (domain) as the self node. Perform search processing.
  • the management information creation unit m13 creates management information with the node obtained by the search by the management target search unit m12 as the management target node.
  • the sign monitoring unit m14 monitors the operating state of hardware, such as a fan, a memory, a CPU (Central Processing Unit), and a power source of the management target device n1, and detects a sign of failure.
  • hardware such as a fan, a memory, a CPU (Central Processing Unit), and a power source of the management target device n1, and detects a sign of failure.
  • CPU Central Processing Unit
  • the guest moving unit m15 moves the process executed by the management target device n1 to another node on the overlay network when the sign monitoring unit m14 detects a sign of failure.
  • the guest recall unit m16 determines whether there is a process moved from the management target apparatus n1 to another node when the management target apparatus n1 is started. If there is a process moved to another node, the guest recall unit m16 moves from the destination node. Call back the process.
  • the management apparatus m1 is preferably implemented as a management program that operates on a computer that is the management target apparatus n1.
  • domain A and domain B each include three servers, and communication between domain A and domain B is possible.
  • a VM (Virtual Machines) host program that virtually realizes the operating environment of another computer system is operating.
  • Four VM guest programs are running on the VM host program.
  • an operation management program further operates on the VM host program.
  • the operation management program operating on the VM host program causes the server to function as a management device.
  • the management target devices of this operation management program are the server itself, a VM host program that operates on the server, and a VM guest program.
  • an OS Operating System
  • an operation management program is operating on the OS.
  • a switch and a router are connected to this server.
  • the operation management program operating on the OS of the server causes the server to function as a management device.
  • the devices to be managed by this operation management program are the server itself and switches and routers connected to the server.
  • an OS Operating System
  • an operation management program is operating on the OS.
  • a storage is connected to this server.
  • the operation management program operating on the OS of the server causes the server to function as a management device.
  • the management target device of this operation management program is the server itself and a storage connected to the server.
  • the operation management program operates on the VM host program on the server and the OS, and each server functions as a management device. Therefore, each server, various programs operating on each server, and hardware connected to each server are managed by an operation management program operating on the corresponding server.
  • the operation management program on each server communicates with each other to construct an overlay network.
  • the operation management program can collect information about other nodes in the domain to which the operation management program belongs and create management information.
  • the operation management program can be acquired from a terminal accessible from both the domain A and the domain B.
  • FIG. 4 is an explanatory diagram of the relationship between the server hardware and the management program.
  • the management program Pg10 is stored in an HDD (Hard disk drive) P13 inside the server.
  • the management program Pg10 is described with an overlay network construction process Pg11 in which an operation as an overlay network construction unit is described, a management target search process Pg12 in which an operation as a management target search unit is described, and an operation as a management information creation unit.
  • the management program Pg10 is read from the HDD p13 and expanded in the memory p12. Then, the CPU (Central Processing Unit) p11 sequentially executes the programs expanded in the memory, thereby causing the server to function as a management device. At this time, the communication interface p14 of the server is used as the overlay network interface in the management apparatus.
  • the CPU Central Processing Unit
  • FIG. 5 is an explanatory diagram of the overlay network.
  • the management device or the management program When the management device or the management program is activated, it forms an overlay network.
  • the overlay network construction unit m11 uses, for example, Chord of the DHT (distributed hash table) algorithm, a circular overlay network as shown in FIG. 5 is formed.
  • Chord of the DHT distributed hash table
  • DHT Dynamic HyperText Transfer Protocol
  • a pair of key and value is held in a distributed manner at each node participating in the overlay network.
  • the value hashed with SHA (Secure Hash Algorithm) -1 is used as the key.
  • SHA Secure Hash Algorithm
  • the key of vmhost2 is 1, the key of domain1 is 5, the key of server1 is 15, the key of server2 is 20, the key of group1 is 32, the key of user1 is 40, and the key of vmgust11 is 55.
  • the key of server3 is 66, the key of vmquest12 is 70, the key of vmhost3 is 75, the key of vmquest13 is 85, and the key of vmquest14 is 90.
  • the key of vmhost1 is 100, the key of switch1 is 110, the key of storage1 is 115, and the key of vmgust21 is 120.
  • vmhost1 to 3 and server1 to 3 belong to domain1 and are the nodes on which the management program is executed, and are indicated by black circular symbols in FIG. Further, vmmuet, storage, switch, and the like belonging to domain1 are indicated by double circular symbols in FIG. In addition, in FIG. 5, nodes belonging to domain 2 (nodes with keys 4, 33, and 36) are indicated by shaded circular symbols.
  • each node consists of the immediately preceding node, the immediately following node, and (own node key + 2 ⁇ (x-1)) mod (2 ⁇ k) (x is a natural number from 1 to k, k is key Node information) as routing information. Specifically, it has information on discrete nodes such as 1,2,4,8,16,32,64,128.
  • each node can hold the value for Key in the node with the first Key greater than Key, and further obtain the value corresponding to Key from the node with the first Key greater than Key. It becomes possible.
  • FIG. 6 is an explanatory diagram of a specific example of the definition of DHT (distributed hash table). This DHT corresponds to the hash table t1 in the SAN of FIG.
  • a node name is used as a hashing key, and a value corresponding to the key is shown.
  • server hash the server name with SHA-1 and use it as Key. And it functions as a tag “server” indicating a server, a server name, a key obtained from the server name, a list of IP addresses of the server (IP list), a list of WWNs of the server (WWN list), and a management node Manager-flag indicating whether or not the server belongs, and the domain to which the server belongs and a list of domain keys are included as Value.
  • server indicating a server, a server name, a key obtained from the server name, a list of IP addresses of the server (IP list), a list of WWNs of the server (WWN list), and a management node Manager-flag indicating whether or not the server belongs, and the domain to which the server belongs and a list of domain keys are included as Value.
  • VM hosts For VM hosts, hash the VM host name with SHA-1 and use it as Key. Then, a tag “vmhost” indicating the VM host, a VM host name, a key obtained from the VM host name, an IP list of the VM host, a domain to which the VM host belongs and a list of domain keys, operate on the VM host It has a list of VM guests as Value.
  • VM guests For VM guests, hash the VM guest name with SHA-1 and use it as Key. And it has a tag “vmguest” indicating that it is a VM host, a VM guest name, a key obtained from the VM guest name, an IP list of the VM guest, the name and key of the VM host on which the VM guest is operating, as Value .
  • Switch For switches, hash the switch name with SHA-1 and use it as Key.
  • a tag “switch” indicating a switch, a switch name, a key obtained from the switch name, a switch IP list, a domain to which the switch belongs and a list of domain keys are included as Value.
  • a tag “storage” indicating storage, a storage name, a key obtained from the storage name, a storage IP list, a storage WWN list, a domain to which the storage belongs and a list of domain keys are included as Value.
  • a tag “user” indicating a user, a user name, a key obtained from the user name, a group name to which the user belongs and a list of group keys are included as Value.
  • For groups hash the group name with SHA-1 and use it as the key. Then, a tag “group” indicating a group, a group name, a key obtained from the group name, a list of user names and keys belonging to the group are provided as Value.
  • domain For the domain, hash the domain name with SHA-1 and use it as Key.
  • a tag “domain” indicating a domain, a domain name, a key obtained from the domain name, and a list of keys of domain management devices are included as Value.
  • FIG. 7 is a specific example of the self-node table t2 shown in FIG.
  • the self node table is a table in which information on nodes on the server on which the management program operates, that is, information on the server itself, a VM host operating on the server, a VM guest, and the like is registered.
  • FIG. 7 shows a self-node table created by a management program operating on vmhost1 together with vmgusts 11-14.
  • the self-node table has items of type, node name, key, IP, and WWN.
  • the entry is of type vmhost, node name is vmhost1.domain1.company.com, key is 100, IP is 10.20.30.40, and WWN is 10: 00: 00: 60: 69: 00: 23: 74 Is registered.
  • an entry is registered in which the type is vmguest, the node name is vmguest11.domain1.company.com, the key is 55, the IP is 10.20.30.41, and the WWN is null.
  • FIG. 8 is a specific example of the domain table t3 shown in FIG.
  • Each management device or management program obtains a key by hashing the domain name of the domain to which the own node belongs with SHA-1, and registers it in the domain table t3. Further, in the domain table t3, in addition to the domain name and the domain key, a manager key for managing the domain is registered. As long as the management program runs on the node, an arbitrary node can manage the node as a manager, and a plurality of managers may exist in the domain.
  • FIG. 9 is a specific example of the node management table t4 shown in FIG.
  • the node management table t4 is management information created by a management apparatus or a management program that operates as a manager that manages the nodes in the domain, and is information on all nodes belonging to the same domain as the own node.
  • the node management table t4 in FIG. 9 is a table created and held by a manager that manages domain1 in the overlay network shown in FIG.
  • the node management table t4 shown in FIG. 9 includes items of type, node name, key, domain key, manager flag, and managed flag.
  • Manager Flag takes a value of true if the node is a manager and false if it is not a manager.
  • Managed Flag takes a value of true if the node is managed and false if it is not managed.
  • the type is vmhost
  • the node name is vmhost2.domain1.company.com
  • Key is 1
  • Domain Key is 5
  • Manager Flag is false
  • Managed Flag is true. Has an entry.
  • the node management table t4 has an entry with a type of server, a node name of server1.domain1.company.com, a Key of 15, a Domain Key of 5, a Manager Flag of true, and a Managed Flag of true.
  • the node management table t4 has an entry with a type of server, a node name of server2.domain1.company.com, a Key of 20, a Domain Key of 5, a Manager Flag of false, and a Managed Flag of true.
  • the node management table t4 has entries of type vmguest, node name vmguest11.domain1.company.com, Key 55, Domain Key 5, Manager Flag false, Managed Flag true.
  • the node management table t4 has entries of type server, node name server3.domain1.company.com, key 66, domain key 5, manager flag false, and managed flag true.
  • node management table t4 has entries of type vmguest, node name vmguest12.domain1.company.com, Key 70, Domain Key 5, Manager Flag false, Managed Flag true.
  • the node management table t4 has an entry with a type of vmhost, a node name of vmhost3.domain1.company.com, a key of 75, a domain key of 5, a manager flag of false, and a managed flag of true.
  • the node management table t4 has an entry with a type of vmguest, a node name of vmguest13.domain1.company.com, a key of 85, a domain key of 5, a manager flag of false, and a managed flag of true.
  • node management table t4 has entries of type vmguest, node name vmguest14.domain1.company.com, Key 90, Domain Key 5, Manager Flag false, Managed Flag true.
  • node management table t4 has entries of type vmhost, node name vmhost1.domain1.company.com, Key 100, Domain Key 5, Manager Flag is true, and Managed Flag is true.
  • the node management table t4 has an entry with a type of switch, a node name of switch1.domain1.company.com, a key of 110, a domain key of 5, a manager flag of false, and a managed flag of true.
  • the node management table t4 has an entry with a type of storage, a node name of storage1.domain1.company.com, a key of 115, a domain key of 5, a manager flag of false, and a managed flag of true.
  • the node management table t4 has entries of type vmguest, node name vmguest21.domain1.company.com, Key 120, Domain Key 5, Manager Flag false, Managed Flag true.
  • the node management table t4 is a table for managing nodes belonging to the domain 1, the nodes belonging to the domain 2 are not registered.
  • FIG. 10 is a specific example of the routing table t5 shown in FIG.
  • the routing table t5 is a table used by each management device and management program for routing in the overlay network.
  • the routing table t ⁇ b> 5 includes a distance indicating a destination key as a final destination, a destination node name, and a destination key indicating a routing destination when communicating with the destination.
  • Key and Destination IP items that are IP addresses of routing destinations.
  • FIG. 10 shows a specific example of the routing table used by the key 100 node.
  • the distance is 1
  • the node name is vmhost1.domain1.company.com
  • the Destination Key is 1
  • the Destination IP is a1.b1.c1.d1
  • the distance is 2
  • the node name is vmhost2.domain1. company.com
  • Destination Key is 1
  • Destination IP is a1.b1.c1.d1.
  • the routing table t5 has a distance of 3, a node name of vmhost2.domain1.company.com, a destination key of 1, and a destination IP of a1.b1.c1.d1. Have items.
  • the routing table t5 has a distance of 5, a node name of vmhost2.domain1.company.com, a Destination Key of 1, and a Destination IP of a1.b1.c1.d1. Have items.
  • the routing table t5 has a distance of 9, a node name of vmhost2.domain1.company.com, a Destination Key of 1, and a Destination IP of a1.b1.c1.d1. Have items.
  • the routing table t5 has a distance of 17, a node name of vmhost2.domain1.company.com, a Destination Key of 1, and a Destination IP of a1.b1.c1.d1. Have items.
  • routing table t5 has items of distance 33, node name node1.domain2.company.com, Destination Key 4 and Destination IP a4.b4.c4.d4.
  • the routing table t5 has items of distance 65, node name node3.domain2.company.com, Destination Key 36, Destination IP a36.b36.c36.d36.
  • the routing table t5 is stored in Key1 (IP: a1.b1.c1.d1) when the node (key: 1, 2, 3, 5, 9, 17) belonging to the domain 1 is the destination. It stipulates routing.
  • the routing table t5 routes to the key 4 (IP: a4.b4.c4.d4) when the node key: 33 belonging to the domain 1 is the destination, and the node key: 65 belonging to the domain 2 is the destination. Is specified, routing to Key36 (IP: a36.b36.c36.d36) is specified.
  • FIG. 11 is a flowchart for explaining migration of a VM guest.
  • the management program operating on the VM host monitors the hardware state by the predictive monitoring process pg14 (S101).
  • the guest migration process pg15 detects other VMs from the hash table t1.
  • the host is searched (S103).
  • the VM host to be searched is preferably a VM host belonging to the same domain, that is, the same management range.
  • the guest migration process pg15 communicates with the VM host and confirms whether or not the VM host has a capacity capable of migrating its own VM guest (S105). ). If no other VM host is found (S104, No), or if another VM guest host is found but does not have sufficient capacity (S105, No), the process is terminated.
  • FIG. 12 is a flowchart for explaining the processing operation when starting up the VM host in server startup.
  • the VM host started up after removing the cause of the warning starts the management program (S201).
  • the guest recall process pg16 of the management program refers to the SAN self-node table t2 and reads the VM guest information created in this VM host (S202). Information other than the self-node table is collected at startup and a new table is generated.
  • the guest recall process pg16 ends the process as it is.
  • the guest recall process pg16 retrieves information on the VM guest from the hash table t1 (S204), and which VM host is currently operating. Specify (S205).
  • a node having a hash table is calculated from the key of the VM guest in the self node table t2, and the VM host is specified from the value of the hash table of the VM guest.
  • the guest recall process pg16 communicates with the operation management program on the migration destination VM host on which the VM guest is currently operating, and inquires whether the VM guest can be migrated (S206).
  • the guest recall process pg16 moves the VM guest to the original VM host (S208), changes the hash table, and ends the process.
  • the guest recall process pg16 returns to step S206 and periodically inquires the recall destination VM host. In addition, when the call back destination VM host is in a call ready state, the call back source VM host may be notified.
  • the hash table t1 is rewritten, so that it is possible to know which VM host the VM guest is operating on.
  • the self node table t2 is not rewritten by the migration of the VM guest, and indicates the original VM guest that was operating on the VM host.
  • the self node table t2 is held in the SAN, information is not lost due to a failure that has occurred in the VM host, a restart of the VM host, or the like.
  • the VM guest can be called back promptly without following the movement path of the VM guest. It can be done reliably.
  • the management apparatus, the management program, and the management method monitor the operation state of the management target apparatus that is a node of the management target network, and detect a failure sign when the management target apparatus is detected.
  • the process being executed by is moved to another node. Then, it is determined whether there is a process that has been moved to another node when the managed device is activated, and the moved process is recalled. For this reason, the moved process can be reliably recalled.
  • m1 management device m11 overlay network construction unit m12 management target search unit m13 management information creation unit m14 predictive monitoring unit m15 guest transfer unit m16 guest recall unit m21 communication processing unit m22 hash processing unit m23 information acquisition unit m24 notification unit t1 hash table t2 self Node table t3 Domain table t4 Node management table t5 Routing table p11 CPU p12 memory p13 HDD p14 communication interface pg10 management program pg11 overlay network construction process pg12 management target search process pg13 management information creation process pg14 predictive monitoring process pg15 guest move process pg16 guest recall process

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Hardware Redundancy (AREA)
  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)

Abstract

　管理装置（ｍ１）のオーバーレイネットワーク構築部（ｍ１１）は、管理対象のネットワークに対してオーバーレイネットワークを構築する。予兆監視部（ｍ１４）は、管理対象装置のハードウェア、例えばファン、メモリ、ＣＰＵ、電源などの動作状態を監視し、故障の予兆を検知する。ゲスト移動部（ｍ１５）は、予兆監視部（ｍ１４）が障害の予兆を検知した場合に、管理対象装置が実行している処理をオーバーレイネットワーク上の他のノードに移動させる。ゲスト呼び戻し部（ｍ１６）は、管理対象装置から他のノードに移動した処理があるかを管理対象装置の起動時に判定し、他のノードに移動した処理がある場合には移動先のノードから移動した処理を呼び戻す。

Description

管理装置、管理プログラムおよび管理方法
　本発明は、ネットワークの管理装置、管理プログラムおよび管理方法に関する。
　従来、大規模データセンタ等の分散コンピュータシステムのような大規模システムでは、処理を担当するハーウェアを交代させる、すなわち処理を異なるハードウェアに移動させることで、システムの可用性を高めていた。一例として、ハードウェア上でＶＭ（Virtual　Machines）ホストを動作させ、このＶＭホスト上でＶＭゲストを動作させる技術が知られている。
　ＶＭホストは、他のコンピュータシステムの動作環境を仮想的に実現するプログラムである。ＶＭゲストは、ＶＭホストによって提供された環境で仮想マシンとして動作し、ユーザに提供される処理を担う。ＶＭゲストは異なるＶＭホストに移動しても処理を継続することができる。
　そこで、従来、ＶＭホストが動作するコンピュータの障害の発生やその予兆を検知する技術、また仮想マシンのゲストを異なるホストに移動させる技術が知られている。
特開２００８－２０１４３３号公報 特開２００７－２３３６８７号公報 特表２００７－５３６６５７号公報
　しかしながら、従来の技術では、ＶＭホストが動作するコンピュータに障害が発生し、ＶＭゲストが他のＶＭホストに移動することを繰り返すと、ＶＭゲストが本来動作していたＶＭホストがどれであったか認識をするのが困難であった。そして、ＶＭゲストが本来動作していたＶＭホストが認識できなくなると、元のＶＭホストに呼び戻すことができないという問題点があった。
　移動したVMゲストを本来のホストに戻すことができないと、ＶＭホストとＶＭゲストとの関係はシステムの稼働に伴って無作為に変化することとなり、ハードウェアを意図したとおりに使用することができない。
　開示の技術は、上記に鑑みてなされたものであって、移動したＶＭゲストを本来動作していたＶＭホストに戻すことを目的とする。
　本願の開示する管理装置、管理プログラムおよび管理方法は、管理対象のネットワークのノードである管理対象装置の動作状態を監視し、障害の予兆を検知した場合に、管理対象装置が実行している処理をネットワーク上の他のノードに移動させる。また、開示の装置、方法、プログラムは、管理対象装置から他のノードに移動した処理があるかを管理対象装置の起動時に判定し、他のノードに移動した処理がある場合には移動先のノードから前記移動した処理を呼び戻す。
　本願の開示する管理装置、管理プログラムおよび管理方法によれば、移動したVMゲストを本来動作していたVMホストに戻すことができる。
図１は、本実施例に係るネットワークの説明図である。 図２は、本実施例にかかる管理装置の構成図である。 図３は、管理プログラムによる実施についての説明図である。 図４は、サーバのハードウェアと管理プログラムの関係についての説明図である。 図５は、オーバーレイネットワークの説明図である。 図６は、ハッシュテーブルの定義の具体例についての説明図である。 図７は、図1に示したセルフノードテーブルｔ２の具体例を示す図である。 図８は、図1に示したドメインテーブルｔ3の具体例を示す図である 図９は、図１に示したノード管理テーブルｔ４の具体例を示す図である。 図１０は、図１に示したルーティングテーブルｔ５の具体例を示す図である。 図１１は、ＶＭゲストの移動について説明するフローチャートである。 図１２は、ＶＭホスト立ち上げ時の処理動作を説明するフローチャートである。
　以下に、本発明にかかるネットワークの管理装置、管理プログラムおよび管理方法の実施例を図面に基づいて詳細に説明する。なお、本実施例は開示の技術を限定するものではない。
　図１は、本実施例に係るネットワークの説明図であり、図２は、本実施例にかかる管理装置の構成図である。図１に示したように、管理対象装置ｎ１～４は、ネットワークを介して接続されている。このネットワークが監視対象のネットワークとなる。
　管理対象装置ｎ１には、監視装置ｍ１が接続され、管理対象装置ｎ２には、監視装置ｍ２が接続され、管理対象装置ｎ３には、監視装置ｍ３が接続されている。監視装置ｍ１～４は、監視対象装置ｎ１～４のネットワークインタフェースを利用して、監視対象装置ｎ１～４が属するネットワークに対してオーバーレイネットワークを構築する。監視装置ｍ１～４は、このオーバーレイネットワークのノードとして機能し、互いに通信可能である。
　管理装置ｍ１～４は、同一の構成を有するので、以降の説明では管理装置ｍ１を例に説明を行なう。管理装置ｍ１は、予兆監視部ｍ１４、ゲスト移動部ｍ１５、ゲスト呼び戻し部ｍ１６を有する。予兆監視部ｍ１４は、管理対象装置ｎ１の故障の予兆を監視する。ゲスト移動部ｍ１５は、管理対象装置ｎ１の故障の予兆が検知された場合に、管理対象装置ｎ１で動作している処理を他の管理対象装置に移動させる。ゲスト呼び戻し部ｍ１６は、管理対象装置ｎ１から他の管理対象装置に移動した処理を必要に応じて呼び戻す処理を行なう。
　図２に示したように、管理装置ｍ１は、予兆監視部ｍ１４、ゲスト移動部ｍ１５、ゲスト呼び戻し部ｍ１６に加え、オーバーレイネットワーク構築部ｍ１１、管理対象検索部ｍ１２、管理情報作成部ｍ１３を有する。また、管理装置ｍ１は、ＳＡＮ（Storage　Area　Network）と接続し、ＳＡＮに後述する各種情報を保持させる。
　オーバーレイネットワーク構築部ｍ１１は、管理対象のネットワークに対してオーバーレイネットワークを構築する処理部であり、通信処理部ｍ２１、ハッシュ処理部ｍ２２、情報取得部ｍ２３、通知部ｍ２４を有する。
　通信処理部ｍ２１は、管理対象装置ｎ１がノードとして参加するネットワーク上の他のノードと通信する処理を行なう。ハッシュ処理部ｍ２２は、通信処理部ｍ２１が他のノードから取得した情報や管理対象装置の情報からハッシュ値を求め、得られたハッシュ値をオーバーレイネットワークのキーとする。情報取得部ｍ２２は、通信処理部ｍ２１を介してオーバーレイネットワークの他のノードから情報を取得する処理部である。通知部ｍ２４は、通信処理部ｍ２１を介してオーバーレイネットワークの他のノードに対して情報を通知する処理部である。
　管理対象検索部ｍ１２は、オーバーレイネットワーク構築部ｍ１１が構築したオーバーレイネットワークから、管理装置ｍ１が直接接続された管理対象装置ｍ１を自ノードとし、自ノードと同一の管理範囲（ドメイン）に属するノードを検索する処理を行なう。
　管理情報作成部ｍ１３は、管理対象検索部ｍ１２による検索によって得られたノードを管理対象ノードとする管理情報を作成する。
　予兆監視部ｍ１４は、管理対象装置ｎ１のハードウェア、例えばファン、メモリ、ＣＰＵ（Central　Processing　Unit）、電源などの動作状態を監視し、故障の予兆を検知する。
　ゲスト移動部ｍ１５は、予兆監視部ｍ１４が障害の予兆を検知した場合に、管理対象装置ｎ１が実行している処理をオーバーレイネットワーク上の他のノードに移動させる。
　ゲスト呼び戻し部ｍ１６は、管理対象装置ｎ１から他のノードに移動した処理があるかを管理対象装置ｎ１の起動時に判定し、他のノードに移動した処理がある場合には移動先のノードから移動した処理を呼び戻す。
　管理装置ｍ１は、管理対象装置ｎ１であるコンピュータ上で動作する管理プログラムとして実施することが好適である。図３に示した例では、ドメインＡとドメインＢにそれぞれ３つのサーバが含まれており、ドメインＡとドメインＢとの間は通信可能である。
　ドメインＡのサーバのうち１つでは、他のコンピュータシステムの動作環境を仮想的に実現するＶＭ（Virtual　Machines）ホストプログラムが動作している。そして、ＶＭホストプログラム上に４つのＶＭゲストプログラムが動作している。このサーバでは、ＶＭホストプログラム上で運用管理プログラムがさらに動作している。ＶＭホストプログラム上で動作する運用管理プログラムは、サーバを管理装置として機能させる。この運用管理プログラムの管理対象装置は、サーバ自体とサーバ上で動作するＶＭホストプログラム、ＶＭゲストプログラムである。
　また、ドメインＡのサーバのうち１つでは、ＯＳ（Operating　System）が動作し、ＯＳ上で運用管理プログラムが動作している。そして、このサーバにはスイッチとルータが接続されている。このサーバのＯＳ上で動作する運用管理プログラムは、サーバを管理装置として機能させる。この運用管理プログラムの管理対象装置は、サーバ自体とサーバに接続されたスイッチおよびルータである。
　また、ドメインＡのサーバのうち１つでは、ＯＳ（Operating　System）が動作し、ＯＳ上で運用管理プログラムが動作している。そして、このサーバにはストレージが接続されている。このサーバのＯＳ上で動作する運用管理プログラムは、サーバを管理装置として機能させる。この運用管理プログラムの管理対象装置は、サーバ自体とサーバに接続されたストレージである。
　ドメインＡと同様にドメインＢに含まれる３つのサーバについても、サーバ上のＶＭホストプログラムやＯＳ上でそれぞれ運用管理プログラムが動作し、各サーバを管理装置として機能させる。このため、各サーバ、各サーバ上で動作する各種プログラム、各サーバに接続されたハードウェアは、対応するサーバ上で動作する運用管理プログラムによって管理される。
　各サーバ上の運用管理プログラムは、互いに通信し、オーバーレイネットワークを構築する。加えて、運用管理プログラムは、自らが属するドメイン内の他のノードについて情報を収集し、管理情報を作成することができる。なお、運用管理プログラムは、ドメインＡとドメインＢの双方からアクセス可能な端末から取得することができる。
　図４は、サーバのハードウェアと管理プログラムの関係についての説明図である。管理プログラムＰｇ１０は、サーバ内部のＨＤＤ（Hard　disk　drive）Ｐ１３に格納される。管理プログラムＰｇ１０は、オーバーレイネットワーク構築部としての動作を記述されたオーバーレイネットワーク構築プロセスＰｇ１１、管理対象検索部としての動作を記述された管理対象検索プロセスＰｇ１２、管理情報作成部としての動作を記述された管理情報作成プロセスＰｇ１３、予兆監視部としての動作を記述された予兆監視プロセスＰｇ１４、ゲスト移動部としての動作を記述されたゲスト移動プロセスＰｇ１５、ゲスト呼び戻し部としての動作を記述されたゲスト呼び戻しプロセスＰｇ１６を含む。
　サーバが起動すると、管理プログラムＰｇ１０はＨＤＤｐ１３から読み出され、メモリｐ１２に展開される。そして、ＣＰＵ（Central　Processing　Unit）ｐ１１がメモリに展開されたプログラムを順次実行することで、サーバを管理装置として機能させる。この時、管理装置におけるオーバーレイネットワークのインタフェースとしては、サーバの通信インタフェースｐ１４を使用する。
　図５は、オーバーレイネットワークの説明図である。管理装置もしくは管理プログラムは、起動するとオーバーレイネットワークを形成する。オーバーレイネットワーク構築部ｍ１１が、例えば、DHT（分散ハッシュテーブル）アルゴリズムのChordを用いた場合、図５に示したような環状のオーバーレイネットワークが形成される。
　DHTでは、キー（Key）とバリュー（Value）のペアが、オーバーレイネットワークに参加する各ノードで分散して保持される。Chordの場合は、SHA（Secure　Hash　Algorithm）-1でハッシュした値をキーに用いる。各キーは自分のキーより大きい値のキーを持ち、管理プログラムが動作している最初のノードに格納される。
　図５の例では、ｖｍｈｏｓｔ２のキーが１、ｄｏｍａｉｎ１のキーが５、ｓｅｒｖｅｒ１のキーが１５、ｓｅｒｖｅｒ２のキーが２０、ｇｒｏｕｐ１のキーが３２、ｕｓｅｒ１のキーが４０、ｖｍｇｕｅｓｔ１１のキーが５５である。同様に、ｓｅｒｖｅｒ３のキーが６６、ｖｍｇｕｅｓｔ１２のキーが７０、ｖｍｈｏｓｔ３のキーが７５、ｖｍｇｕｅｓｔ１３のキーが８５、ｖｍｇｕｅｓｔ１４のキーが９０である。そして、ｖｍｈｏｓｔ１のキーが１００、ｓｗｉｔｃｈ１のキーが１１０、ｓｔｏｒａｇｅ１のキーが１１５、ｖｍｇｕｅｓｔ２１のキーが１２０である。
　ここで、ｖｍｈｏｓｔ１～３、ｓｅｒｖｅｒ１～３は、ｄｏｍａｉｎ１に属し、管理プログラムが実行されたノードであり、図５において黒い円形記号で示している。また、ｄｏｍａｉｎ１に属するｖｍｇｕｅｔ、ｓｔｏｒａｇｅ、ｓｗｉｃｈなどについては、図５において二重円形記号で示している。加えて、図５では、ｄｏｍａｉｎ２に属するノード（キーが４，３３，３６のノード）については、網掛けの円形記号で示している。
　既に述べたように、キーとValueのペアは自分のキーより大きい値のキーを持ち、管理プログラムが動作している最初のノードに格納されるので、Key　40,　55　は、Key　=　66　のノードに格納される。
　また、Chordの場合、各ノードは、直前のノードと、直後のノード及び(自ノードkey+2^(x-1))　mod　(2^k)　(xは1からkの自然数、kはkeyのビット数)　のノードの情報をルーティング情報として保持している。具体的には、1,2,4,8,16,32,64,128…というように離散したノードの情報を持つ。
　これによって、Chord　DHTでは、各ノードがKeyに対するValueを、Keyより大きい最初のKeyを持つノードに保持させ、更にKeyに対応するValueを、Keyより大きい最初のKeyを持つノードから取得することが可能になる。
　図６は、DHT（分散ハッシュテーブル）の定義の具体例についての説明図である。このDHTは、図１のSANにおけるハッシュテーブルｔ１に相当する。
　図６ではハッシュするキーとしてノード名を用い、キーに対応するValueを示している。
　サーバについては、サーバ名をSHA-1でハッシュしてKeyとする。そして、サーバであることを示すタグ「server」、サーバ名、サーバ名から求めたkey、サーバが有するＩＰアドレスの一覧（ＩＰリスト）、サーバが有するWWNの一覧（ＷＷＮリスト）、管理ノードとして機能しているかを示すmanager-flag、サーバの属するドメインとドメインのキーのリスト、をValue　として有する。
　ＶＭホストについては、VMホスト名をSHA-1でハッシュしてKeyとする。そして、ＶＭホストであることを示すタグ「vmhost」、VMホスト名、ＶＭホスト名から求めたkey、ＶＭホストのＩＰリスト、ＶＭホストの属するドメインとドメインのキーのリスト、ＶＭホスト上で動作するVMゲストのリスト、をValue　として有する。
　ＶＭゲストについては、VMゲスト名をSHA-1でハッシュしてKeyとする。そして、ＶＭホストであることを示すタグ「vmguest」、ＶＭゲスト名、ＶＭゲスト名から求めたkey、ＶＭゲストのＩＰリスト、ＶＭゲストが動作しているＶＭホストの名前とｋｅｙ、をValue　として有する。
　スイッチについては、スイッチ名をSHA-1でハッシュしてKeyとする。そして、スイッチであることを示すタグ「switch」、スイッチ名、スイッチ名から求めたkey、スイッチのＩＰリスト、スイッチの属するドメインとドメインのキーのリスト、をValue　として有する。
　ストレージについては、ストレージ名をSHA-1でハッシュしてKeyとする。そして、ストレージであることを示すタグ「storage」、ストレージ名、ストレージ名から求めたkey、ストレージのＩＰリスト、ストレージのWWNリスト、ストレージの属するドメインとドメインのキーのリスト、をValue　として有する。
　ユーザについては、ユーザ名をSHA-1でハッシュしてKeyとする。そして、ユーザであることを示すタグ「user」、ユーザ名、ユーザ名から求めたkey、ユーザの属するグループ名とグループのkeyのリスト、をValue　として有する。
　グループについては、グループ名をSHA-1でハッシュしてKeyとする。そして、グループであることを示すタグ「group」、グループ名、グループ名から求めたkey、グループに属するユーザ名とkeyのリスト、をValue　として有する。
　ドメインについては、ドメイン名をSHA-1でハッシュしてKeyとする。そして、ドメインであることを示すタグ「domain」、ドメイン名、ドメイン名から求めたkey、ドメインの管理装置のキーのリスト、をValue　として有する。
　図７は、図1に示したセルフノードテーブルｔ２の具体例である。セルフノードテーブルは、管理プログラムが動作するサーバ上のノード、すなわちサーバ自体、サーバ上で動作するＶＭホスト、ＶＭゲストなどの情報を登録したテーブルである。図７は、ｖｍｇｕｅｓｔ１１～１４とともに、ｖｍｈｏｓｔ１上で動作する管理プログラムが作成したセルフノードテーブルを示している。セルフノードテーブルには、種別、ノード名、key、IP、WWNの項目を有する。
　図７の例では、種別がvmhost、ノード名がvmhost1.domain1.company.com、keyが100、IPが10.20.30.40、WWNが10:00:00:60:69:00:23:74のエントリが登録されている。また、種別がvmguest、ノード名がvmguest11.domain1.company.com、keyが55、IPが10.20.30.41、WWNがnullのエントリが登録されている。
　同様に、種別がvmguest、ノード名がvmguest12.domain1.company.com、keyが70、IPが10.20.30.42、WWNがnullのエントリが登録されている。そして、種別がvmguest、ノード名がvmguest13.domain1.company.com、keyが85、IPが10.20.30.43、WWNがnullのエントリと、種別がvmguest、ノード名がvmguest14.domain1.company.com、keyが90、IPが10.20.30.44、WWNがnullのエントリが登録されている。
　図8は、図1に示したドメインテーブルｔ3の具体例である。各管理装置や管理プログラムは、自ノードが属するドメインのドメイン名をＳＨＡ－１でハッシュしてkeyを求め、ドメインテーブルｔ３に登録する。また、ドメインテーブルｔ3には、ドメイン名とドメインのkeyの他、ドメインの管理を行なうマネージャのkeyを登録する。管理プログラムが動作するノードであれば、任意ノードがマネージャとしてノードの管理を行なうことができ、ドメイン内に複数のマネージャが存在してもよい。
　図９は、図１に示したノード管理テーブルｔ４の具体例である。ノード管理テーブルｔ４は、ドメイン内のノードを管理するマネージャとして動作する管理装置や管理プログラムが作成する管理情報であり、自ノードと同一ドメインに属する全てのノードの情報である。
　図９のノード管理テーブルｔ４は、図５に示したオーバーレイネットワークのうちｄｏｍａｉｎ１を管理するマネージャが作成し、保持するテーブルを示している。
　図９に示したノード管理テーブルｔ４は、種別、ノード名、key、Domain　key、Manager　Flag、Managed　Flagの項目を有する。Manager　Flagは、そのノードがマネージャである場合にtrue、マネージャではない場合にfalseの値をとる。Managed　Flagは、そのノードが管理されている場合にtrue、管理されていない場合にfalseの値をとる。
　具体的には、図９に示したノード管理テーブルｔ４は、種別がvmhost、ノード名がvmhost2.domain1.company.com、Keyが1、Domain　Keyが5、Manager　Flagがfalse、Managed　Flagがtrueのエントリを有する。
　また、ノード管理テーブルｔ４は、種別がserver、ノード名がserver1.domain1.company.com、Keyが15、Domain　Keyが5、Manager　Flagがtrue、Managed　Flagがtrueのエントリを有する。
　また、ノード管理テーブルｔ４は、種別がserver、ノード名がserver2.domain1.company.com、Keyが20、Domain　Keyが5、Manager　Flagがfalse、Managed　Flagがtrueのエントリを有する。
　また、ノード管理テーブルｔ４は、種別がvmguest、ノード名がvmguest11.domain1.company.com、Keyが55、Domain　Keyが5、Manager　Flagがfalse、Managed　Flagがtrue、のエントリを有する。
　また、ノード管理テーブルｔ４は、種別がserver、ノード名がserver3.domain1.company.com、Keyが66、Domain　Keyが5、Manager　Flagがfalse、Managed　Flagがtrue、のエントリを有する。
　また、ノード管理テーブルｔ４は、種別がvmguest、ノード名がvmguest12.domain1.company.com、Keyが70、Domain　Keyが5、Manager　Flagがfalse、Managed　Flagがtrue、のエントリを有する。
　また、ノード管理テーブルｔ４は、種別がvmhost、ノード名がvmhost3.domain1.company.com、Keyが75、Domain　Keyが5、Manager　Flagがfalse、Managed　Flagがtrue、のエントリを有する。
　また、ノード管理テーブルｔ４は、種別がvmguest、ノード名がvmguest13.domain1.company.com、Keyが85、Domain　Keyが5、Manager　Flagがfalse、Managed　Flagがtrue、のエントリを有する。
　また、ノード管理テーブルｔ４は、種別がvmguest、ノード名がvmguest14.domain1.company.com、Keyが90、Domain　Keyが5、Manager　Flagがfalse、Managed　Flagがtrue、のエントリを有する。
　また、ノード管理テーブルｔ４は、種別がvmhost、ノード名がvmhost1.domain1.company.com、Keyが100、Domain　Keyが5、Manager　Flagがtrue、Managed　Flagがtrue、のエントリを有する。
　また、ノード管理テーブルｔ４は、種別がswitch、ノード名がswitch1.domain1.company.com、Keyが110、Domain　Keyが5、Manager　Flagがfalse、Managed　Flagがtrue、のエントリを有する。
　また、ノード管理テーブルｔ４は、種別がstorage、ノード名がstorage1.domain1.company.com、Keyが115、Domain　Keyが5、Manager　Flagがfalse、Managed　Flagがtrue、のエントリを有する。
　また、ノード管理テーブルｔ４は、種別がvmguest、ノード名がvmguest21.domain1.company.com、Keyが120、Domain　Keyが5、Manager　Flagがfalse、Managed　Flagがtrue、のエントリを有する。
　このように、ノード管理テーブルｔ４は、ドメイン１に属するノードを管理するテーブルであるので、ドメイン２に属するノードについては登録されていない。
　図１０は、図１に示したルーティングテーブルｔ５の具体例である。ルーティングテーブルｔ５は、各管理装置や管理プログラムがオーバーレイネットワークにおけるルーティングに用いるテーブルである。
　図１０に示した例では、ルーティングテーブルｔ５は、最終的な宛先である目的地のキーを示すdistance、目的地のノード名、目的地と通信する場合のルーティング先を示す宛先のキーであるDestination　Key、ルーティング先のＩＰアドレスであるDestination　IPの項目を有する。
　図１０は、キー１００のノードが用いるルーティングテーブルの具体例である。図１０のルーティングテーブルｔ５は、distanceが1、ノード名がvmhost1.domain1.company.com、Destination　Keyが1、Destination　IPがa1.b1.c1.d1、distanceが2、ノード名がvmhost2.domain1.company.com、Destination　Keyが1、Destination　IPがa1.b1.c1.d1の項目を有する。
　また、ルーティングテーブルｔ５は、distanceが3、ノード名がvmhost2.domain1.company.com、Destination　Keyが1、Destination　IPがa1.b1.c1.d1
の項目を有する。
　また、ルーティングテーブルｔ５は、distanceが5、ノード名がvmhost2.domain1.company.com、Destination　Keyが1、Destination　IPがa1.b1.c1.d1
の項目を有する。
　また、ルーティングテーブルｔ５は、distanceが9、ノード名がvmhost2.domain1.company.com、Destination　Keyが1、Destination　IPがa1.b1.c1.d1
の項目を有する。
　また、ルーティングテーブルｔ５は、distanceが17、ノード名がvmhost2.domain1.company.com、Destination　Keyが1、Destination　IPがa1.b1.c1.d1
の項目を有する。
　また、ルーティングテーブルｔ５は、distanceが33、ノード名がnode1.domain2.company.com、Destination　Keyが4、Destination　IPがa4.b4.c4.d4の項目を有する。
　また、ルーティングテーブルｔ５は、distanceが65、ノード名がnode3.domain2.company.com、Destination　Keyが36、Destination　IPがa36.b36.c36.d36の項目を有する。
　このように、ルーティングテーブルｔ５は、ドメイン１に属するノード(key:1,2,3,5,9,17)が目的地である場合にはKey1（IP:a1.b1.c1.d1）にルーティングすることを規定している。また、ルーティングテーブルｔ５は、ドメイン１に属するノードkey:33が目的地である場合にはKey4（IP:a4.b4.c4.d4）にルーティングし、ドメイン２に属するノードkey:65が目的地である場合にはKey36（IP:a36.b36.c36.d36）にルーティングすることを規定している。
　図１１は、ＶＭゲストの移動について説明するフローチャートである。ＶＭホストの動作中、ＶＭホスト上で動作する管理プログラムは、予兆監視プロセスpg１４によってハードウェアの状態を監視する（Ｓ１０１）。
　予兆監視プロセスpg１４がファン、メモリ、ＣＰＵ、電源などのハードウェアの動作状態について故障の前兆である警告情報を検知した場合（Ｓ１０２，Ｙｅｓ）、ゲスト移動プロセスpg１５は、ハッシュテーブルｔ１から他のＶＭホストを検索する（Ｓ１０３）。このとき、検索するＶＭホストは、同一ドメイン、すなわち同一の管理範囲に属するＶＭホストであることが望ましい。
　他のＶＭホストが見つかった場合（Ｓ１０４，Ｙｅｓ）、ゲスト移動プロセスpg１５は、そのＶＭホストと通信し、自ホストのＶＭゲストを移動させることができるキャパシティを持つＶＭホストかどうか確認する（Ｓ１０５）。他のＶＭホストが見つからない場合（Ｓ１０４，Ｎｏ）、また他のＶＭゲストホストが見つかっても十分なキャパシティを持たない場合（Ｓ１０５，Ｎｏ）には、そのまま処理を終了する。
　図１２は、サーバ起動におけるＶＭホスト立ち上げ時の処理動作を説明するフローチャートである。警告の原因を取り除いて立ち上げられたＶＭホストは、管理プログラムを起動する（Ｓ２０１）。管理プログラムのゲスト呼び戻しプロセスpg１６は、ＳＡＮのセルフノードテーブルｔ２を参照し、このＶＭホストで作成されたＶＭゲスト情報を読む（Ｓ２０２）。セルフノードテーブル以外については、立ち上げ時に情報を収集し、新しくテーブルを生成する。
　セルフノードテーブルｔ２にＶＭゲスト情報がない場合（Ｓ２０３，Ｎｏ）、ゲスト呼び戻しプロセスpg１６は、そのまま処理を終了する。一方、セルフノードテーブルｔ２にＶＭゲスト情報がある場合（Ｓ２０３，Ｙｅｓ）、ゲスト呼び戻しプロセスpg１６は、ハッシュテーブルｔ１からそのＶＭゲストの情報を検索し（Ｓ２０４）、現在どのＶＭホストで動作しているか特定する（Ｓ２０５）。この特定は、セルフノードテーブルｔ２のVMゲストのKeyからハッシュテーブルを持つノードを算出し、ＶＭゲストのハッシュテーブルのvalueからVMホストを特定すればよい。
　ゲスト呼び戻しプロセスpg１６は、現在ＶＭゲストが動作している移動先のＶＭホスト上の運用管理プログラムと通信し、ＶＭゲストを移動可能か問い合わせる（Ｓ２０６）。
　問い合わせの結果、移動可能であれば（Ｓ２０７，Ｙｅｓ）、ゲスト呼び戻しプロセスpg１６はＶＭゲストを元のＶＭホストへ移動させ、（Ｓ２０８）、ハッシュテーブルを変更して処理を終了する。
　また、問い合わせの結果、移動ができなければ（Ｓ２０７，Ｎｏ）、ゲスト呼び戻しプロセスpg１６はステップＳ２０６に戻り、呼び戻し先ＶＭホストに定期的に問い合わせる。なお、呼び戻し先ＶＭホストが呼び戻し可能な状態になった場合に、呼び戻し元ＶＭホストへ通知するようにしてもよい。
　このように、ＶＭゲストの移動が発生した場合には、ハッシュテーブルｔ１が書き換えられるため、ＶＭゲストがどのＶＭホストで動作しているかを知ることができる。一方でセルフノードテーブルｔ２は、ＶＭゲストの移動によっては書き換えられず、そのＶＭホストで動作していた本来のＶＭゲストを示す。加えて、セルフノードテーブルｔ２は、ＳＡＮに保持されることから、ＶＭホストに発生した障害やＶＭホストの再起動などによって情報が失われることがない。
　したがって、ＶＭゲストの移動先のＶＭホストでさらに異常が発生し、ＶＭゲストの移動が繰り返された場合であっても、ＶＭゲストの移動の軌跡を追うことなく、ＶＭゲストの呼び戻しを速やかに且つ確実に行なうことができる。
　上述したように、本実施例にかかる管理装置、管理プログラムおよび管理方法は、管理対象のネットワークのノードである管理対象装置の動作状態を監視し、障害の予兆を検知した場合に、管理対象装置が実行している処理を他のノードに移動させる。そして、管理対象装置の起動時に他のノードに移動した処理があるかを判定し、移動した処理を呼び戻す。このため、移動した処理を確実に呼び戻すことができる。
　　ｍ１　管理装置
　　ｍ１１　オーバーレイネットワーク構築部
　　ｍ１２　管理対象検索部
　　ｍ１３　管理情報作成部
　　ｍ１４　予兆監視部
　　ｍ１５　ゲスト移動部
　　ｍ１６　ゲスト呼び戻し部
　　ｍ２１　通信処理部
　　ｍ２２　ハッシュ処理部
　　ｍ２３　情報取得部
　　ｍ２４　通知部
　　ｔ１　ハッシュテーブル
　　ｔ２　セルフノードテーブル
　　ｔ３　ドメインテーブル
　　ｔ４　ノード管理テーブル
　　ｔ５　ルーティングテーブル
　　ｐ１１　ＣＰＵ
　　ｐ１２　メモリ
　　ｐ１３　ＨＤＤ
　　ｐ１４　通信インタフェース
　　ｐｇ１０　管理プログラム
　　ｐｇ１１　オーバーレイネットワーク構築プロセス
　　ｐｇ１２　管理対象検索プロセス
　　ｐｇ１３　管理情報作成プロセス
　　ｐｇ１４　予兆監視プロセス
　　ｐｇ１５　ゲスト移動プロセス
　　ｐｇ１６　ゲスト呼び戻しプロセス

Claims (7)

  1. 　管理対象のネットワークのノードである管理対象装置の動作状態を監視する監視部と、
    　前記監視部による監視の結果、障害の予兆を検知した場合に、前記管理対象装置が実行している処理をネットワーク上の他のノードに移動させる移動部と、
    　前記管理対象装置から他のノードに移動した処理があるかを前記管理対象装置の起動時に判定し、他のノードに移動した処理がある場合には移動先のノードから前記移動した処理を移動する呼び戻し部と、
    　を備えたことを特徴とする管理装置。
  2. 　前記管理対象装置が実行している処理の情報を前記管理対象装置とは異なる記録装置に記録する管理情報作成部を更に有し、前記呼び戻し部は、前記記録装置を参照して前記管理対象装置から他のノードに移動した処理があるかを判定することを特徴とする請求項１に記載の管理装置。
  3. 　前記移動部は、前記管理対象装置と同一の管理範囲に属するノードを移動先として選択することを特徴とする請求項１または２に記載の管理装置。
  4. 　管理対象のネットワークのノードであるコンピュータ上で動作する管理プログラムであって、
    　前記コンピュータから他のノードに移動した処理があるかを起動時に判定し、他のノードに移動した処理がある場合には移動先のノードから前記移動した処理を呼び戻す呼び戻し手順と、
    　前記コンピュータの動作状態を監視する監視手順と、
    　前記監視の結果、障害の予兆を検知した場合に、前記コンピュータが実行している処理をネットワーク上の他のノードに移動させる移動手順と、
    　をコンピュータに実行させることを特徴とする管理プログラム。
  5. 　前記呼び戻し手順は、自プログラムが動作するコンピュータ上で動作する他のノードを前記移動および呼び戻しの対象とすることを特徴とする請求項４に記載の管理プログラム。
  6. 　管理対象のネットワークのノードであるコンピュータの動作状態を監視して障害の予兆を検知する予兆監視手順と、
    　前記コンピュータ上で動作する処理毎にキーを算出し、前記コンピュータ上で動作する処理についてセルフノードテーブルを生成する手順と、
    　前記キーに応じて所定のルールにて定められた前記ネットワーク上のノードにキーと対応する処理の情報の組み合わせを有するハッシュテーブルを生成する手順と、
    　前記予兆監視手順による監視の結果、前記コンピュータの故障の予兆を検知した場合に、前記コンピュータ上で動作する処理を前記ネットワーク上の他のノードに移動させて前記ハッシュテーブルを更新する予兆検知時移動手順と、
    　前記コンピュータの起動時に、前記セルフノードテーブルのキーから該キーのハッシュテーブルを持つノードを特定し、該ハッシュテーブルから移動先ノードを抽出する手順と、
    　前記移動先ノードに移動した処理を前記コンピュータに移動させる呼び戻し手順と、
    をコンピュータに実行させることを特徴とする管理プログラム。
  7. 　管理対象のネットワークを管理する管理方法であって、
    　前記ネットワークのノードから他のノードに移動した処理があるかを前記ノードの起動時に判定し、他のノードに移動した処理がある場合には移動先のノードから前記移動した処理を呼び戻す呼び戻しステップと、
    　前記ノードの動作状態を監視する監視ステップと、
    　前記監視の結果、障害の予兆を検知した場合に、前記ノードが実行している処理を前記ネットワーク上の他のノードに移動させる移動ステップと、
    　を含んだことを特徴とする管理方法。
PCT/JP2010/061565 2010-07-07 2010-07-07 管理装置、管理プログラムおよび管理方法 WO2012004872A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP10854426.3A EP2592556A1 (en) 2010-07-07 2010-07-07 Management device, management program and management method
JP2012523473A JPWO2012004872A1 (ja) 2010-07-07 2010-07-07 管理装置、管理プログラムおよび管理方法
PCT/JP2010/061565 WO2012004872A1 (ja) 2010-07-07 2010-07-07 管理装置、管理プログラムおよび管理方法
US13/735,276 US20130124913A1 (en) 2010-07-07 2013-01-07 Management device and management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/061565 WO2012004872A1 (ja) 2010-07-07 2010-07-07 管理装置、管理プログラムおよび管理方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/735,276 Continuation US20130124913A1 (en) 2010-07-07 2013-01-07 Management device and management method

Publications (1)

Publication Number Publication Date
WO2012004872A1 true WO2012004872A1 (ja) 2012-01-12

Family

ID=45440873

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/061565 WO2012004872A1 (ja) 2010-07-07 2010-07-07 管理装置、管理プログラムおよび管理方法

Country Status (4)

Country Link
US (1) US20130124913A1 (ja)
EP (1) EP2592556A1 (ja)
JP (1) JPWO2012004872A1 (ja)
WO (1) WO2012004872A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017220148A (ja) * 2016-06-10 2017-12-14 富士通株式会社 情報管理プログラム、情報管理方法、及び情報管理装置

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2977050A1 (fr) * 2011-06-24 2012-12-28 France Telecom Procede de detection d'attaques et de protection
US11057285B2 (en) * 2014-11-24 2021-07-06 ZPE Systems, Inc. Non-intrusive IT device monitoring and performing action based on IT device state
US10418762B2 (en) 2015-03-09 2019-09-17 ZPE Systems, Inc. High serial port count infrastructure management device
US11337323B2 (en) 2015-03-09 2022-05-17 ZPE Systems, Inc. Modular infrastructure management device

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07282022A (ja) * 1994-04-04 1995-10-27 Hitachi Ltd マルチプロセッサシステム
JP2001306351A (ja) * 2000-04-19 2001-11-02 Nec Corp コンピュータシステムにおける障害対処方式
JP2007233687A (ja) 2006-03-01 2007-09-13 Nec Corp 仮想計算機システム、仮想計算機の制御方法、および仮想計算機プログラム
JP2007536657A (ja) 2004-05-08 2007-12-13 インターナショナル・ビジネス・マシーンズ・コーポレーション 仮想マシン・コンピュータ・プログラムの動的マイグレーション
JP2008210412A (ja) * 2003-02-12 2008-09-11 Internatl Business Mach Corp <Ibm> マルチノード分散データ処理システムにおいてリモート・アクセス可能なリソースを管理する方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005018510A (ja) * 2003-06-27 2005-01-20 Hitachi Ltd データセンタシステム及びその制御方法
JP2005258983A (ja) * 2004-03-15 2005-09-22 Hitachi Ltd 複数のクラスタシステムを有するコンピュータシステム、および、コンピュータシステムの制御方法
JP2006011581A (ja) * 2004-06-23 2006-01-12 Hitachi Ltd ストレージシステム及びストレージシステムの制御方法
US8572237B2 (en) * 2008-12-16 2013-10-29 Sap Ag Failover mechanism for distributed process execution

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07282022A (ja) * 1994-04-04 1995-10-27 Hitachi Ltd マルチプロセッサシステム
JP2001306351A (ja) * 2000-04-19 2001-11-02 Nec Corp コンピュータシステムにおける障害対処方式
JP2008210412A (ja) * 2003-02-12 2008-09-11 Internatl Business Mach Corp <Ibm> マルチノード分散データ処理システムにおいてリモート・アクセス可能なリソースを管理する方法
JP2007536657A (ja) 2004-05-08 2007-12-13 インターナショナル・ビジネス・マシーンズ・コーポレーション 仮想マシン・コンピュータ・プログラムの動的マイグレーション
JP2007233687A (ja) 2006-03-01 2007-09-13 Nec Corp 仮想計算機システム、仮想計算機の制御方法、および仮想計算機プログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017220148A (ja) * 2016-06-10 2017-12-14 富士通株式会社 情報管理プログラム、情報管理方法、及び情報管理装置

Also Published As

Publication number Publication date
US20130124913A1 (en) 2013-05-16
EP2592556A1 (en) 2013-05-15
JPWO2012004872A1 (ja) 2013-09-02

Similar Documents

Publication Publication Date Title
US20220131746A1 (en) Data center resource tracking
RU2375746C2 (ru) Способ и устройство для обнаружения сетевых устройств
WO2012004872A1 (ja) 管理装置、管理プログラムおよび管理方法
US10078655B2 (en) Reconciling sensor data in a database
JP5617304B2 (ja) スイッチング装置、情報処理装置および障害通知制御プログラム
US20190354448A1 (en) High availability and disaster recovery system architecture
JP5664662B2 (ja) 管理システム、管理装置、管理方法および管理プログラム
US9319271B2 (en) Management device and management method
CN108228272B (zh) Web容器生成处理方法、设备以及服务器
JP5741595B2 (ja) 管理装置、管理方法および管理プログラム
JP6269199B2 (ja) 管理サーバおよび障害復旧方法、並びにコンピュータ・プログラム
JP5483784B1 (ja) 制御装置、計算資源管理方法及び計算資源管理プログラム
JP6155861B2 (ja) データ管理方法、データ管理プログラム、データ管理システム及びデータ管理装置
JP5653322B2 (ja) 障害検出装置、ネットワーク構成推定装置および障害検出方法
US20150142960A1 (en) Information processing apparatus, information processing method and information processing system
CN116938753B (zh) 数据处理方法、装置及电子设备
JP2013009046A (ja) ネットワークシステム、管理装置、管理方法及び管理プログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10854426

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012523473

Country of ref document: JP

Ref document number: 2010854426

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE