Patent Application
20100077063
Various systems, methods, techniques or other means for saving resources, e.g., electric power, are known in the computing industry. For example, reduction of energy consumed by a computing device may be achieved by causing the computing device to enter a sleep, power save, stand-by or hibernation mode. Other methods or techniques may involve reducing the frequency or rate of a clock governing the operation of a central processing unit or other components. Yet other methods may shut down components such as a display screen or hard drive when suitable conditions are detected. Such methods and/or techniques typically involve detecting a time when a computing device is idle by monitoring or sensing absence of interaction with a human user, e.g., via an input/output device such as a keyboard and/or a mouse, for a predefined period of time.
However, such methods known in the art fail to provide a solution for many scenarios, systems and/or environments. For example, a server, e.g., a server remotely located in a datacenter, may not be equipped with human interface devices, such as mouse and/or keyboard. Accordingly, detecting idle time as described above may be impossible.
There is therefore a need for a system, method and apparatus for allowing a computing device, particularly a server or other device having primarily network activity, to enter and exit a sleep mode.
Embodiments of the invention may enable one or more computing devices to be emulated by another computing device such that at least a network behavior of the emulated computing device is maintained by the emulating device. In some embodiments, operational parameters of a server may be obtained and provided to an emulating computing device. An emulating device may emulate a server including maintaining a network presence of the server. While being emulated, a server may operate in a power save mode or any other functionality or operational state or mode. Conditions requiring a termination of an emulation of a server may be detected by the server or by the emulating device. Upon detecting conditions requiring a termination of an emulation of a server, operational or other parameters may be provided to the server by the emulating device and the server may assume or enter full, or other, operational mode in a manner transparent to networks and/or or devices interacting with the previously emulated server.
Embodiments of the invention may detect an emulation condition. An emulation condition may be a condition indicating a suitability of a first computing device to perform a set of emulated network operations of a second computing device normally performed by said second computing device when operating in a normal operational mode. At least a first network functionality parameter may be provided to the emulating computing device. The emulating computing device may be caused to perform at least some of the emulated network operations of said second computing device according to the network functionality parameter provided. The emulated computing device may be caused to assume or enter a reduced operational mode, wherein such reduced operational mode may be associated with reduced network operation with respect to a normal operational mode.
An awake condition may be detected and may indicate a need for a network operation of the emulated computing device. A network functionality parameter may be provided to the emulated computing device by the emulating computing device. The emulated computing device may be caused to assume or enter a normal operational mode and perform the network operation based on the provided network functionality parameter. The emulating computing device may be caused to cease emulating the emulated device.
Embodiments of the invention are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like reference numerals indicate corresponding, analogous or similar elements, and in which:
It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity.
In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those of ordinary skill in the art that the invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, modules, units and/or circuits have not been described in detail so as not to obscure the invention.
Although embodiments of the invention are not limited in this regard, discussions utilizing terms such as, for example, “processing,” “computing,” “calculating,” “determining,” “establishing”, “analyzing”, “checking”, or the like, may refer to operation(s) and/or process(es) of a computer, a computing platform, a computing system, or other electronic computing device, that manipulate and/or transform data represented as physical (e.g., electronic) quantities within the computer's registers and/or memories into other data similarly represented as physical quantities within the computer's registers and/or memories or other information storage medium that may store instructions to perform operations and/or processes.
Although embodiments of the invention are not limited in this regard, the terms “plurality” and “a plurality” as used herein may include, for example, “multiple” or “two or more”. The terms “plurality” or “a plurality” may be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like.
Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed at the same point in time.
Although embodiments of the invention are not limited in this regard, the terms “emulate” or “emulating” as used in this patent application specification should be expansively and broadly construed to include performing any functionality of an emulated device by an emulating device. In particular, emulating may include performing network related functionality and/or emulating a network behavior, presence. Any applicable operational or other aspects of an emulated device may be performed, carried out, executed, implemented, handled or assumed by the emulating device, e.g., handling and communicating over network connections. According to embodiments of the invention, Emulating network related behavior, functionality or other aspects of a device may include emulating or performing functionalities related to some or all the seven layers of a network architecture as defined by the open system interconnection (OSI) model. For example, emulation of a device may include performing operations related to the physical, data, network, transmission and/or application layers.
As described above, there is a need to allow a server to enter and exit sleep mode, particularly in the absence of human interaction. Further aggravating the problem is the fact that a server may be required to be continuously available for various network communications. Methods currently in use for entering/exiting sleep mode are not suitable, as these may cause the loss of network presence of the server, e.g., render network connections unusable, effectively disabling applications, users and/or other computing devices from further interacting with the server.
Reference is made to
Client computing devices 135 and 145 may be any computing device using, utilizing or otherwise associated with a service provided by a server, e.g., by servers 115 and/or 125. For example, client computing devices 135 and 145 may be or may include, for example, a personal computer, a desktop computer, a mobile computer, a laptop computer, a notebook computer, a terminal, a workstation, a server computer, a Personal Digital Assistant (PDA) device, a tablet computer, a network device, a mobile phone, a household appliance or any other suitable computing device. It will be recognized that embodiments of the invention are not limited by the nature, type, number or other aspects of servers 115 and/or 125 nor are embodiments of the invention limited by nature, type, number or other aspects of client computing devices 135 and/or 145. Although two client computing devices are shown, any applicable number, e.g., a thousands of client computing devices may be used or may be part of embodiments of the invention.
Networks 150 and 160 may be, may comprise, or may be part of a private IP network, the internet, an integrated services digital network (ISDN), frame relay connections, a modem connected to a phone line, a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a wireline or wireless network, a local, regional, or global communication network, a network internal to a computing device, e.g., a bus as known in the art, an enterprise intranet, any combination of the preceding and/or any other suitable communication means. Networks 150 and 160 may be physically located in the same geographical location, e.g., they may be two segments of an intranet in an organization's facility or they may be geographically apart, e.g., in two different, remote sites or locations. Networks 150 and 160 may not be of the same or similar architecture, for example, network 150 may be a private IP network while network 160 may be a combination of the internet and a private frame relay network connected to the internet. It will be recognized that embodiments of the invention are not limited by the nature or type of networks 150 and 160 or other aspects related to network 150 and/or 160.
Network device 170 may be any suitable or applicable network device. For example, network device may be or may comprise a firewall, a load balancer, a virtual private network (VPN) device or access point, or a network switch, router or gateway. Network device 170 may perform any applicable tasks or functions required in order to enable computing devices to communicate, e.g., over networks 150 and 160. For example, network device 170 may be or may comprise a network switch enabling client computing device 135 to communicate with server 125. Network device 170 may additionally or alternatively be or comprise a gateway enabling computing devices connected to network 150 (e.g., emulating computing device 110) to communicate with computing devices connected to network 160 (e.g., client computing device 145).
Emulating computing devices 110, 120 and 130 may be any suitable computing devices. For example, computing devices similar to servers 115 or client computing device 135 as described herein. Alternatively or additionally, emulating computing devices 110, 120 and 130 may be or may comprise a chip, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a computer blade, e.g., installed in a chassis, a core in a multi-core CPU or any other suitable computing device. Typically but not necessarily, emulating computing devices 110, 120 and 130 may be devices that require limited resources in order to operate or function, for example, a power consumption of these devices may be very low. Although emulating computing devices 120 and 130 are shown as related to server 125 and network device 170 respectively, embodiments of the invention are not limited in this regard. An emulating computing device may be related to or incorporated in client computing device or any suitable device, system, platform or component.
Various configurations of embodiments of the invention are possible. Other than a server in an organization or a server in a datacenter being emulated during applicable periods of time other implementations or configurations are possible. For example, a personal or home computer connected to the family's entertainment set top box may not be accessible, e.g., for playing a movie, if it is in sleep mode or similar state. Such home computer may be emulated during times it is not used by an emulating, low resource device, for example, network behavior, presence or other aspects may be emulated. Such configuration may enable putting a home PC to sleep while maintaining its availability or network presence. Another example may be a home computing device being accessed from a remote location, e.g., accessing a home PC from a work office, accessing an office PC from a mobile device such as a laptop or a smart phone. Again, if the home PC is allowed to assume sleep mode or other low operational state, it may not be remotely accessible. Embodiments of the invention may enable such home PC to enter sleep mode while its network related or other aspects are being emulated by an emulating device thus maintain its availability for remote access.
In a typical mode of operation, servers, e.g., servers 115 and/or 125, may perform tasks or functions for remote users, applications or client computing devices, e.g., device 135 or 145 or users operating such devices. Such functions may comprise, for example, executing various applications on behalf of remote users, storing and providing data or otherwise performing or providing various services. Since it may be impossible to determine or predict a time when services provided by a server may be required or generally when communication with a server may be required, servers may be required to continuously maintain a network presence. A network presence of a server may generally refer to an availability and/or accessibility of/to the server over a network. However, there may be periods of time when servers, e.g., servers 115 and 125, are idle, or when services provided by such servers are not required and/or requested by any computing device, application, user or any other entity.
As known in the art, a computing device connected to a network may perform various network related, background functions even when it does not perform or execute a specific function or provide a service. For example, implementations of network protocol stacks may perform maintenance or background tasks. Embodiments of the invention are not limited by the network architecture involved or the parts or components of such architectures. For example, embodiments of the invention may be applicable to network architectures or layers such as asynchronous transfer mode (ATM), frame relay, integrated services digital network (ISDN), transmission control protocol (TCP), internet protocol (IP), fiber optics, ethernet or any combination thereof. For the sake of simplicity and clarity, TCP/IP over ethernet is mainly used in the discussion herein as an example. In the case of TCP, maintenance or background tasks may be, for example, handling keep-alive messages over established connections, listening to well known or other ports, responding to status messages or queries related to selected applications, e.g., directory change command according to common internet file system (CIFS) protocol etc.
According to embodiments of the invention, an emulating device may perform such maintenance or background tasks for, or on behalf of, an emulated device or server thus enabling the emulated server to operate in a reduced functionality mode, e.g., sleep, power save, hibernation or other mode. An emulating device may further require minimal resources, e.g., electric power, in order to operate. According to embodiments of the invention, having an emulating device emulate, substitute or replace a server while the server operates in a reduced functionality mode may enable substantial resource saving, e.g., electric or other energy resources. For example, a server typically consuming 250 Watts (joules of energy per second) may be emulated by a chip or ASIC only consuming ten (10) or even less Watts. In other embodiments, hundreds of servers may be emulated by a single computing device thus resulting a substantial reduction of consumption of energy and/or other resources as well as reduced heat dissipation.
According to embodiments of the invention, an emulating device, e.g., emulating computing devices 110, 120, 130 or 210 may fully or partially emulate, imitate, substitute, fill in for, or otherwise replace one or more functions, functionalities and/or operational or other aspects of a server or other computing device being emulated. In some embodiments, an emulating device may perform or assume some or all network related activities, functionalities or other aspects of the device being emulated while the emulated device may maintain, perform or continue performing other functionalities. For example, applications originally executing on an emulated server may continue executing on the server while the server's network related functionality is being emulated by an emulating device. As further described herein, if or when an application executing on the emulated server requires network communication, emulation of the server may be terminated.
According to embodiments of the invention, a server being emulated by an emulating device may, for example, enter or assume an alternative operational mode or state. For example, an emulated computing device may assume a sleep, power save, stand-by or hibernation mode or otherwise assume a reduced functionality state while being emulated. Alternatively or additionally, while being emulated, specific resources associated with a server may selectively be shutdown, halted, or otherwise made to reduce their operational capacity. For example, a hard disk may be put to sleep, its read/write head may be parked, a display may be turned off, a frequency of a clock governing an operation of a CPU, controller and/or chip set may be lowered or wait states may be added between operational states of a component. Some or all applicable components of a server or other computing device being emulated may be caused to operate according to a predefined, typically reduced capacity. Typically, while being emulated, a server and/or its components may, possibly as a result of an assumed alternative operational state or mode, consume substantially less power than otherwise. Embodiments of the invention are not limited by the state, mode, or other operational aspects related to a computing device being emulated as described herein. Any methods, systems, means or techniques known in the art may be employed in order to alter an operational state of an emulated computing device without departing from the scope of the present invention.
In some embodiments, an emulating computing device may maintain a network presence of a computing device being emulated. For example, an emulating device may control, maintain, or be otherwise associated with network connections originally or otherwise associated with an emulated server as described herein. Accordingly, an emulating device may communicate with network devices on behalf of an emulated device. For example, send and/or receive data over network connections that were originally established by the emulated devices.
Reference is made to
In some embodiments, a module, e.g., a software module executed on server 215, may be configured to detect such conditions. Conditions that enable or permit a server to be emulated (and their respective detection) may vary from one server to another or they may vary according to circumstances, e.g., time of day, applications running on the server or any other applicable or available parameters, information, aspects or context. For example, a list of applications that may be executed on server 215 may be provided to a software module that may determine that none of the listed applications is currently executing and accordingly, the server may be emulated. It will be recognized that embodiments of the invention are not limited by the way, method or means to determine that a server may be emulated. Alternatively or additionally, conditions enabling or permitting emulation of a computing device may be detected by a device other than the device to be emulated. For example, emulating device 455 may detect conditions enabling or permitting emulation of server 405 or conditions that otherwise indicate that emulation of server 405 is desirable.
As shown by block 240, operational parameters may be communicated from server 215 to emulating device 210. Operational parameters as referred to herein, may be or may include any relevant or applicable parameters. For example, operational parameters may be network operational parameters, setting parameters, context parameters, state parameters, mode parameters or configuration parameters, data or information. For example, routing tables, ARP tables, a list of established TCP connections possibly accompanied by their associated transmission control blocks (TCB), a list of ports being listened to (as defined by TCP) etc. Operational parameters may be or may include any application related information, data or parameters. For example, a state of a specific application, whether predefined messages are expected by the application and so on. Operational parameters may be or may include any setting parameters, configuration parameters and/or state, mode or context parameters, data or information that may be relevant to or used or required by a computing device emulating another computing device. For example, network operational and/or context parameters may be TCP connections information, e.g., any information, data or parameters typically stored in a transmission control block (TCB) used by a TCP implementation as known in the art. A TCB may exist for each TCP connection, a TCB may include parameters such as receive and transmit sequence numbers, receive and transmit window sizes, source and destination IP addresses and port numbers, connection state etc. Accordingly, transferring a TCB from server 215 to emulating device 210 may enable emulating device 210 to emulate server 215 insofar as the relevant TCP connection is concerned. In the exemplary case of TCP/IP, network context information or operational parameters may further include objects such as an address resolution protocol (ARP) table, a routing table and the like. Accordingly, such information or objects may be transferred as shown by block 240.
As shown by block 245, a transition from one operational mode to another of server 215 and emulating device 210 may be coordinated. Such coordination may be required in order to maintain coherency, for example as viewed by client device 220. For example, it may be undesirable for both server 215 and emulating device 210 to attempt to communicate over the session (that may be a TCP connection) established as shown by block 230. Accordingly, in the exemplary case of TCP/IP, coordination or synchronization may be required to ensure that the operational modes of server 215 and device 210 are such that only one of them is actively associated with a TCP connection. Any suitable synchronization or coordination mechanism may be employed. For example, upon completion of communicating network context information or operational parameters as described herein, emulating device 210 may cause server 215 to operate according to a predefined operational mode. For example, emulating device 210 may instruct server 215 to enter or assume a reduced functionality operational mode and upon receiving an acknowledge (ACK) from server 215, may commence emulating server 215 as shown by block 255. Server 215 may enter a reduced functionality operational mode as shown by block 250 immediately after communicating the acknowledge as discussed. Emulating device 210 may perform any other necessary operations. For example, emulating device 210 may cause, e.g., configure, a network device to route communication of data destined to server 215 to emulating device 210.
According to embodiments of the invention, an emulating device may handle, maintain, control or be otherwise associated with any network related aspects that may be associated with an emulated device. For example, while emulating server 215, emulating device may communicate with client computing device 220 over a TCP connection as shown by block 260, for example, over a TCP connection previously established between server 215 and device 220 as shown by block 230. Emulating device may be able to communicate over such TCP connection based on network context, configuration, parameters or other information or operational parameters received from server 215 as described herein. Network context information or operational parameters obtained by emulating device 210 may enable it to communicate over a previously established TCP connection while adhering to any TCP/IP rules, constraints limitations or other aspects, e.g., sequence numbers, connection state, window sizes, maximal transmission unit (MTU) option etc. Accordingly, the fact that rather than server 215 communicating over such TCP connections with client device 220 emulating device is now communicating with device 220 may be transparent to client device 220 and possibly, transparent to other devices on the relevant network.
As shown by block 265, emulating device 210 may detect conditions disabling emulation of server 215. Such condition may generally be referred to as an awake condition requiring an emulated device to wake, e.g., assume or enter a normal operational mode. For example, a request to establish a new TCP connection (reception of a synchronization packet known as SYN packet) may cause emulating device 210 to determine that emulating server 215 may no longer be desirable or that transparent emulation of server 215 may no longer be performed. Various other considerations, limitations, aspects or configuration parameters may control or effect a decision to terminate or continue an emulation of a server. For example, emulating device 210 may be configured to process layer 7 (e.g., application level or layer) information. Accordingly, emulating device 210 may be able to emulate server 215 with regards to a specific application, e.g., respond to a specific application's query etc. Accordingly, upon receiving data or information requiring an involvement of server 215, e.g., information destined to an application associated with, or executing on server 215, emulating device may notify server 215 as shown by block 270. Although not shown in
Possibly upon receiving a notification as shown by block 270, server 215 may exit a reduced functionality mode or any operational mode assumed while being emulated, and enter or assume a normal or other operational mode as shown by block 275. In such mode server 215 may receive network context information or operational parameters communicated by emulating device 210 as shown by block 280. Operational parameters transferred as shown by block 280 may be similar to those transferred as shown by block 240. Though similar, compared with parameters transferred as shown by block 240, parameters transferred as shown by block 280 may reflect network or other activity that took place while server 215 was being emulated, for example, activities involving emulating device 210 and client computing device 220. For example, a state or other aspects of a TCP connection transferred from server 215 to device 210 may have changed, due to sending and/or receiving data over the connection etc. Accordingly, server 210 may update relevant structures, e.g., TCB blocks associated with TCP connections such that communication over existing TCP connections may seamlessly proceed. For example, referring to the flow depicted in
As shown by block 285, emulating of a computing device may be terminated. Such termination may include, as shown by block 280, exiting an emulation mode by the emulating device. For example, emulating device 210 may cease emulating server 215, e.g., handling network connections associated with server 215 etc. As shown by block 290, terminating an emulation may include handling of network connections by the device previously being emulated. For example, TCP connections that may have been handled by emulating device 210 during a time server 215 was emulated may be handled by server 215 upon termination of an emulation. A transfer of control, handling usage or association of network connections from an emulating device back or to another device, e.g., to server 215 may be transparent to other devices, for example, client device that may be unaware of such transfer. Such transparency may be enabled by communicating relevant information from an emulating device to an emulated device.
Reference is made to
According to embodiments of the invention, a special module installed on a server to be emulated may perform obtaining of operational parameters described herein. For example, a filter driver configured to interact with a kernel or other entities of an operating system may be executed on server 215 in
Operational parameters obtained or collected and/or communicated, e.g., between an emulated and an emulating device as described herein may relate to any one of the open systems interconnection (OSI) seven layers of a network architecture as known in the art. Accordingly, operational parameters may include lower layers related information or parameters, e.g., media access control (MAC) addresses, network layer information, e.g., IP addresses or routing information, transport layer parameters, e.g. TCP parameters and application layer or level information.
Application layer information or parameters obtained according to embodiments of the invention may be specific to each relevant application. For example, knowledge of a specific protocol used by a specific application may enable embodiments of the invention to collect or otherwise obtain parameters relevant to such application, in particular, parameters related to communication or network aspects related to such application, and may further enable an emulating device to emulate some of the functions or aspects of such specific application.
As shown by block 310, the flow may include detecting conditions enabling server emulation. Such detection may comprise identifying, observing or detecting an emulation condition, e.g., a condition enabling a first computing device to be emulated by a second computing device. An emulation condition may indicate a suitability of a first computing device to perform a set of emulated network operations of a second computing device. For example, an emulation condition may indicate a condition where by emulating device 110 is suitable for emulating one of servers 115 in
According to embodiments of the invention, conditions enabling server emulation may be related to any operational aspect of the server, e.g., mode or state of an operating system operating the server, a network or other protocol stack and the state or condition of applications executing on the server. For example, it may be determined that a server may be emulated if applications executing on it are idle or otherwise require no interaction with entities external to the server or if relevant information indicates that no interaction with other computing devices is to be expected for a known or unknown period of time. Conditions enabling emulating a server or other computing device may be preconfigured. For example, a configuration parameter may be such that emulation of a server is disabled during a specific time of day, day of week etc. Alternatively, specific conditions, states, modes or other aspects of specific applications may dictate enabling/disabling of emulation. For example, if a specific application executing on a server is known to be currently involved in an ongoing interaction with a user then emulating of the server may be disabled, prohibited or avoided.
As shown by block 315, the flow may include providing an emulating device with server operational communication, network or other parameters. Parameters collected as described herein and/or any other information, data or parameters relevant to an emulation of a server may be provided to a device configured to emulate the server. For example, a module installed on a server and configured to collect operational parameters as described herein may communicate, e.g., over a network, any or all of the parameters obtained as described. Providing operational or other parameters to an emulating device may be performed in any applicable way. For example, an emulating device may be directly connected to an emulated server, e.g., over a peripheral component interconnect (PCI) or other bus. Alternatively, as described herein, an emulating device may reside inside an emulated server or computing device, accordingly, providing operational parameters to the emulating device may comprise storing them in a predefined location in a memory accessible to the module collecting the operational parameters and the emulating device.
While techniques known in the art, e.g., virtualization, may move or relocate an application or a virtual server from one physical machine or device to another, embodiments of the invention may differ at least insofar as they may selectively identify, collect or obtain and communicate network parameters, information and/or context from an emulated device to an emulating device. For example, rather than or in addition to communicating a memory snapshot or other structures or objects, embodiments of the invention may obtain and communicate a collection of parameters specifically related to a network functionality and/or context related to a device to be emulated to an emulating device. Such communicated parameters may enable an emulating device to perform some or all network related functionalities or aspects of the relevant emulated device.
As shown by block 320, the flow may include altering the operational mode of a server and emulating the server's communications, network or other aspects by an emulating device. For example, the emulated server may be put to sleep or assume a power save mode as known in the art or otherwise assume an operational state or mode that comprises reduced functionality and possibly, reduced power consumption or limited consumption of other resources. Emulation of a first computing device by a second computing device may be performed such that any related network devices, applications, users or other entities are unaware of such emulation being performed, otherwise phrased, emulation of a first device by a second device may be transparent to other devices. For example, a remote computer communicating with a server during a first period of time may be unaware it is communicate with an emulating device during a second period of time, where the server is being emulated by the emulating device during such second period of time. For example, an application on client computing device 135 may interact with server 125 during a first period of time when server 125 is not being emulated. Such application may interact with emulating device 120 during a second period of time when server 125 is being emulated by device 120 and again with server 125 during a third period of time when server 125 is no longer being emulated. Accordingly, emulation of a server may be transparent to other devices associated with an emulation server.
Emulating a server may comprise performing configuration or other tasks related to any device operationally or otherwise associated with the emulated server. For example, referring to
While emulating a server, e.g., emulating a server's network or communication behavior or other aspects, an emulating device may perform any task, e.g., network related task, that would typically or otherwise be performed by the emulated server. For example, maintaining TCP connections by sending and/or responding to keep-alive messages or receiving and sending application specific messages. For example, a protocol adhered to by an application may define a message enabling users or applications to probe or query the application in order to determine if a state, context or other aspects relevant to the application have changed. According to embodiments of the invention, an emulating device may reply to such message without involving the application thus enabling the server to remain in sleep mode or any other mode or state assumed while being emulated.
As discussed herein, routing information may be part of the information obtained and provided to an emulating device. Provided with routing information, an emulating device may cause data packets sent on behalf of an emulated server to traverse the same network path that would have been traversed had such packets originated at the emulated server. For example, source routing may be used by an emulating device to route outgoing traffic according to a routing table or routing information related to an emulated server. As described herein, a single emulating device may emulate a number of servers or computing devices. Accordingly, for each egress packet, an emulating device may examine the relevant routing structure, e.g., the one associated with the server associated with the packet, and set the source routing information in the packet according to the routing information of the specific server associated with the packet. Such mechanism may cause traffic over a network to be unaffected by the emulation of servers attached to the network.
Any other operational or other aspects of one or more emulated servers may be performed or emulated by an emulating device. For example, based on operational parameters provided to an emulated device TCP connection may be fully emulated, e.g., proper time stamps may be added to communications over selected connections, parameters or options such as maximum transmission unit (MTU), maximum window size etc. may be implemented according to their implementation, state or other relevant aspects on the emulated server. Accordingly, a device communicating with an emulating device may be unaware of, or indifferent to the emulation being performed. As described herein, an emulating device may emulate any number of devices, for example, a single emulating device in a datacenter may emulate hundreds or thousands of servers, thus dramatically reducing power consumption and costs. An emulating device may emulate any number of devices, e.g., servers by specifically emulating each of the emulated devices' behavior. For example, a possibly different MTU, receive and transmit window sizes or other TCP parameters of each emulated server may be adhered to when emulating, or communicating with remote devices on behalf of the specific emulated server. According to embodiments of the invention, a structure, entry in a table or object representing the network context, parameters or aspects of each emulated server may be maintained and used by the emulating device in order to adequately emulate the network behavior, presence or other aspects of each server or device being emulated.
As shown by block 325, the flow may include detecting conditions requiring altering an operational mode of a server. Such condition may generally be referred to as an awake condition requiring an emulated device to wake, e.g., assume or enter a normal operational mode. According to embodiments of the invention, when an awake or other conditions described herein are met or detected, an emulation of a server may be terminated. Such conditions may be, for example, detecting a request for a service that may be provided by an emulated server, detecting an attempt to open a new network connection to the server, e.g., a reception of a TCP SYN packet. Other conditions may be a reception of a packet containing information that needs handling by an application executing on the emulated server. As discussed herein, specific messages or packets, even ones destined to a specific applications executing on an emulated server, may be handled by the emulating device. However, in case a packet received by the emulating device contains information that the emulating device is unable, unauthorized or otherwise incapable of handling, the emulating device may determine that emulation of the relevant server is to be terminated. As described herein, conditions for terminating an emulation may be related to detected events or received information, e.g., packets received from a network, or they may be related to various other events or aspects. For example, a user may cause an emulation of a server to be terminated by interacting with an emulating device and further instructing it to terminate an emulation of a specific server or a predefined group of servers. Alternatively, configuration parameters may dictate or define conditions for a termination of an emulation of a server. For example, an emulating device may be configured to terminate or avoid an emulation of a server during preconfigured hours, days etc. Other parameters, criteria, rules or thresholds may be used, for example, an emulating device may be configured to terminate an emulation of a server after a predefined period of time during which the server was emulated has elapsed, if a predefined number of predefined messages has been received, a predefined number of connections has been in an established state for a predefined time period etc. Other conditions or criteria for terminating an emulation of a device may be a reset of the emulated device, an interrupt received from an I/O device connected to the emulated device, a hardware or software timer expiration or interrupt etc. It will be noted that an emulating device may be in operational connection and/or communication with the relevant emulated device. For example, a module executing on the emulated device may update the emulating device regarding any conditions, events or relevant states related to the emulated device thus enable the emulating device to determine, possibly based on events related to the emulated device that emulation is to be terminated.
According to embodiments of the invention, an emulated server may cause or trigger a termination of an emulation. For example, by detecting a request of an application executing on the server to communicate over a network. For example, upon detecting that an application executing on the server needs to interact with a user or other application, the server may terminate the emulation. Any conditions requiring the server to regain control of network connections controlled by an emulating device may cause the server to terminate the emulation. Any applicable conditions, configured rules, criteria or events may be cause a server being emulated to trigger a termination of its emulation. For example, detecting user interaction with the server, e.g., a local keyboard's key being pressed or a connected point and click device being used may be cause the server to terminate its emulation. Any other applicable events, e.g., a hardware or software timer expiration may generate, trigger, initiate or otherwise cause a termination of an emulation of a server or other computing device. Another exemplary event that may cause a termination of an emulation of a server may be a reset, shutdown or power up or down of a server. In such case the server may cause a termination of its emulation as part of a shutdown procedure or as part of its boot or power up procedure.
As shown by block 330, the flow may include providing an emulated server with operational parameters, e.g., network or communication related parameters. For example, operational parameters may be communicated from an emulating device to an emulated server, e.g., as shown by block 280 of
As shown by block 335, a server may alter its operational mode, e.g., switch from sleep or power save mode to full operational mode. As further shown, an emulating device may cease from emulating a server at such point. Any configurations required in order to enable a server to function in non-emulated state mode or fashion may be affected by the server, by the emulating device or by both. For example, gratuitous ARP messages may be broadcasted in order to cause devices connected to a network to correctly update their respective ARP tables. Routers, gateways or other network devices may be configured in order to reflect that a server is no longer being emulated.
Reference is made to
Module 412 may interact with OS 420 and obtain or receive any relevant information from OS 420. Such information may be a list, state or status of applications executing on server 405. Information related to applications executing or scheduled to execute on server 405 may enable embodiments of the invention to determine whether and/or how server 405 may be emulated by an emulating device. For example, if a specific application, e.g., a mail application, known to require network activity is currently executing then it may be determined that emulation of server 405 is currently undesirable or impossible. It will be noted that an operational state of applications executing on server 405 may be a parameter upon which a decision to emulate server 405 may be based. For example, although a specific application may be executing, it may be determined that its current state is such that emulation of the relevant server may still be performed as the application may require no network activity or that activity related to the application may be performed by an emulating device. For example, if the network related activity of an application executing on server 405 is receiving, acknowledging or generating a periodic “keep alive” message then server 405 may be emulated by emulating device 455. Accordingly, emulating device may handle such “keep alive” messages on behalf or instead of server 405 and/or applications executing on server 405.
A module such as server module 412 may interact with kernel 425 to obtain various parameters or information that may be used in order to determine whether and/or how server 405 may be emulated as described herein. For example, internal parameters related to OS 420 may be obtained. Such internal parameters or information may not be related to a specific application or user but to aspects such as a state of the operating system, services currently running etc. Other related aspects may be kernel mode operations, processes and the like that may be running, scheduled to run etc. For example, if a kernel level operation that requires network communication is currently running or is scheduled to execute then it may be determined that emulating server 405 may be undesirable and may, for example, be delayed till conditions are such that emulation is possible, desirable or permitted.
Other entities, modules, and the like that may be interacted with by server module 412 may be a protocol stack, e.g., a TCP protocol stack implementation, a registry, e.g., a registry of a Windows® operating system as known in the art. Interacting with a TCP protocol stack may enable server module to determine the state, level, scope or other parameters related to network activity related to server 405. For example, it may be determined if and/or which applications or connections are currently involved in network activity and/or the type or nature of such activity. Such determination may be based on monitoring network connections that are active, being listened to etc. Module 412 may interact with any other relevant module or entity on server 405 in order to obtain any relevant information, in particular, information relevant to network activity or other aspects.
Module 412 may be installed on server 405 any time after server 405 has been operative or module 412 may come pre-installed, e.g., as part of an installation of an operating system. For example, server module 412 and/or filter driver 415 may be part of an operating system operating server 405. Filter driver 415 may, as known in the art, interact with various components of server 405. For example, as shown, filter driver 415 may interact with operating system (OS) 420, kernel 425 and/or protocol stack 430. Filter driver 415 may extract, receive or otherwise obtain any information from OS 420, kernel 425, protocol stack 430 or any other module, application or program on server 405. As known in the art, filter driver 415 may intercept any transaction from and/or between the entities listed above or any other entity and may further provide information, data or parameters thus obtained to, for example, server module 412. In some embodiments, filter driver 415 may be part of server module 412. It will be recognized that the configuration depicted in
OS 420 may be any commercial or other OS as known in the art. Kernel 425 may be the kernel of OS 420 as known in the art. Protocol stack 430 may be any applicable protocol stack as known in the art, e.g., a TCP/IP protocol stack, possibly adapted to run, for example, over ethernet physical and data layers.
Emulating device 455 may be an emulating computing device as described herein. For example, emulating device 455 may be similar to any one of emulating devices 110, 120 and/or 130 shown in
According to embodiments of the invention, various configurations are possible. For example, in a first configuration, emulating device 455 may be a separate device or otherwise independent on a specific device in order to operate. For example, emulating device 455 may be similar to emulating device 110 in
According to embodiments of the invention, a single emulating device may simultaneously emulate any applicable number of servers or computing devices. Any operations, procedures, communicated messages etc. described herein with relation to an emulation of a server by an emulating device may be performed for each emulated server, possibly independently from other procedures, operations or messages exchanged regarding other simulated servers. for example, emulating device 110 may emulate all or some of servers 115.
According to embodiments of the invention, a high availability (HA), load sharing or other configurations are possible. In a HA configuration, two or more emulating devices may share data, information, parameters, rules, thresholds, criteria, settings, configurations, context or any other aspects pertaining to an emulation of one or more computing devices. In such configuration, a first emulating device may be designated as the active emulating device while other emulating devices may be designated as a backup or redundant emulating devices. In case an active emulating device fails, a backup emulating device may step-in or otherwise replace the failing device. While typically replacement of a failing emulating device may be automatic as described herein, such replacement may be manual, e.g., an administrator or other user may interact, possibly with modules 460, via communication modules 465 of the relevant emulating devices and instruct them to perform tasks needed in order to facilitate a transfer of emulation from a first to a second emulating device. Alternatively, such transfer may be automatic. Various protocols may be implemented by a number of emulating devices in order to enable backup, high availability or redundancy. For example, a customized router redundancy protocol (RRP) known in the art may be adhered to, supported or otherwise implemented by a number of emulating devices. Such configuration may enable a number of emulating devices to provide high availability or redundancy as known in the art. For example, a failing emulating device may be automatically and seamlessly replaced by a backup emulating device.
While an emulating module may be installed inside a server or computing device that is to be emulated, an emulating device or module may be external to the server or computing device that is to be emulated. For example, an emulating device may be connected to a network and may, accordingly, emulate any computing device operatively connected to such network. An administrator may configure, e.g., associate a server and/or an emulating device with other devices thus determine which emulating device is to emulate which server. For example, emulating device 110 and a specific one of servers 115 may be configured such that emulating device 110 will emulate the specific one of servers 115, alternatively or additionally, emulating device 120, that is internal to server 125 may, by default, emulate server 125 but may, in addition, emulate one of servers 115. Any applicable configuration may enable any emulating device or module to emulate one or more servers or computing devices.
Various messages may be communicated between and/or by server 405 and emulating device 455. For example, a protocol adhered to by server 405 and device 455 may define a message format comprising the following fields: a message type or op-code, an identification of the emulated device (server) and message parameters. For example, an op-code or message type may be one of: a reset of server, wake (e.g., exit sleep mode), start emulation mode etc. An identifier of an emulated device may serve or enable an emulating device emulating a number of servers to identify the server associated with the message. An exemplary identifier may be a unique identifier associated with a NIC, e.g., the MAC address. Parameters included in a message may be any relevant parameters, for example, operational parameters described herein and communicated between an emulating and emulated device.
The following exemplary functions, tasks or operations may be performed by server module 412. Server module 412 may monitor any relevant activities, events, flows or other aspects pertaining to the operation and configuration of server 405. Aspects monitored by module 412 may relate to software, logic, hardware or any applicable aspects. For example, a change in hardware configuration, e.g., replacement or addition of a NIC to server 405 may be detected by module 412. Connections states, modes and or other aspects may be monitored, recorded and/or logged by module 412. Module 412 may further analyze any obtained information and may determine, according to analyzed information, a time when server 405 may be emulated and a method, level, degree, extent or way of emulation. As shown, server module may interact with an OS, an OS kernel, a protocol stack and/or applications on server 405. Although only some components of server 405 interacted with by module 412 are shown, any applicable component of server 405 may be interacted with by module 412 in order to obtain information or parameters required in order to determine server 405 may be emulated.
Server module 412 may collect any information parameters or other data that may be required by emulating device 455 and, as part of emulating server 405, may communicate any such information to emulating device 455. Upon termination of an emulation of server 405 and as described herein, emulating device 455 may communicate to server 405 any data, information, parameters, rules, thresholds, criteria, settings, configurations or context required in order to enable server 405 to operate according to the operational state assumed after being emulated. For example, information in TCB's of TCP connections, e.g., sequence numbers, expected ACK, connection state, timers etc. may be sent from emulating device 455 to server 405 in order to enable server 405 to resume control of, maintain and/or use such TCP connection. Accordingly, module 412 may receive such parameters and may further provide various components of server 405 with needed information. For example, module 412 may update protocol stack 430 with information pertaining to connections as described above. Module 412 may similarly update or configure OS 420 or application 410 according to received information, for example, regarding states, modes, events and the like.
In some embodiments of the invention, after server 405 has been emulated, module 412 may function as an adaptation layer. For example, a TCP connection that has been transferred to emulating device 455 and then returned to server 405 may have had some bytes or packets sent over it while being emulated by device 455. Accordingly, a difference may exist between the sequence numbers of the last byte sent and/or received by protocol stack 430 and the correct numbers that must be used in order to adhere with the TCP rules. In such case, module 412 may adjust protocol header fields of incoming and/or outgoing (ingress and/or egress) packets, e.g., an offset may be added to or subtracted from sequence number fields protocol packets or segments. Any other adaptation or other tasks may be performed by module 412 in order to enable transparency of emulation to various components of server 405 and/or computing devices interacting with server 405. Other exemplary operations may be updating a protocol stack regarding new connections, e.g., connections opened by an emulating device during an emulation period etc.
While server 405 is being emulated, module 412 may monitor any applicable activity, state or aspect of server 405 and may further act when required. For example, module 412, possibly aided by filter driver 415, may block egress or ingress network communication from/to server 405. For example, module 412 may prevent server 405 from sending or receiving ACK packets over TCP network connections. Module 412 may do so in order to prevent duplicate messages, e.g., messages sent by both an emulated server and the respective emulating device.
In order to interact with a protocol stack, module 412 and module 460 may implement a command, procedure or application program interface (API) that may enable manipulations of network connections. For example, the following commands relaying on the well known in the art socket interface may be implemented. For example, SocketListenAdd (IP address) (Port Number) enabling commanding a listen to be performed on a socket identified by the provided IP address and port number, SocketListenDel enabling stopping of a listen on an identified socket, SocketListenShow enabling a listing of relevant sockets, SocketActiveAdd (IP address) (Port Number) enabling adding an active socket to a protocol stack and SocketStop (socket id) enabling stopping an interaction with a socket (and associated connection). Such exemplary commands may be used in order to interact with a protocol stack in order to manage handling of connections by such protocol stack. Such commands may enable module 412 to cause protocol stack 430 to stop handling connections while server 405 is being emulated and may also enable module 412 to cause protocol stack 430 to regain control of connections when server 405 is no longer being emulated. similarly, such commands may be used by module 460 on emulating device 455 when interacting with the local protocol stack (not shown). For example, ports listened to by server 405 may be listened to by emulating device 455 by having module 460 using SocketListenAdd.
Module 412 may update emulating device, e.g., emulation module 460 regarding any meaningful events. for example, in case server 405 is shutdown or being reset module 412 may update module 460 either during a shutdown procedure or when server 405 is operational, e.g., after a restart. When server 405 is rebooted or otherwise becomes operational, module 412 may obtain, from local storage, from emulating device 455 or from another source relevant information or parameters determining aspects of emulation. For example, a time during which server 405 is to be idle before emulation of it will be triggered. Such configuration parameters may be stored on any applicable device or media. For example, emulating device 455 may store such configuration parameters and may, based on an identification parameter in a message received locate the relevant parameters and send them to server 405.
Emulation module may receive a “sleep” message from server 405 notifying it that server 405 is ready to be emulated. Such message may include all information required by emulating device 455 in order to emulate server 405. Accordingly, module 460 may use such information as described herein, e.g., update a local protocol stack regarding network connections being transferred from server 405 to device 455. Module 460 may perform monitoring and recording of various information, parameters or aspects of network and/or other activity related to server 405 in a way similar to that described herein with respect to module 412. Upon receiving a “wake” message indicating that server 405 needs to assume full or other functional mode, e.g., a “wake” message, module 460 may send all relevant information to server 405, possibly to be received by module 412 on the server. Such relevant information may include any data or parameters as described herein, pertaining to any aspect of operation of the server. For example, updated information pertaining to network connections may be communicated. Such information may include any data or parameters required in order to enable a seamless transition of control of network connections and/or other operational aspects from an emulating device, e.g., device 455 to an emulated server, e.g., server 405.
While emulating device 455 emulates server 405, module 460 may analyze any received information in order to determine if it can handle it by itself or if server 405 needs to be awakened in order to handle received information or detected event. For example, a request for opening a new TCP connection may cause module 460 to determine that server 405 needs to be brought back to full or other operational mode. Other events that may cause a termination of an emulation of server 405 may be application specific events or messages as described herein. Module 460 may be configured to handle various events, messages or received information without involving server 405. For example, module 460 may be configured to handle a specific set of messages pertaining to a specific applications, e.g., reply to a status inquiry. Accordingly, when a message or event is detected by module 460 and such message or event can not be properly handled by module 460, module 460 may send a “wake” message to server 405 thus initiating a termination of emulation of server 405 and further causing server 405 to handle the event.
Reference is made to
According to embodiments of the invention, storage device 540 may be any suitable storage device, e.g., a hard disk or a universal serial bus (USB) storage device, input devices 520 may include a mouse, a keyboard or any suitable input devices and output devices 545 may include one or more displays, speakers and/or any other suitable output devices. According to embodiments of the invention, various programs, applications, scripts or any executable code may be loaded into memory 530 and may further be executed by controller 505. For example, a software module implementing any one or more of server module 412, filter driver 415, emulation module 460 and/or communication module 465 may be loaded into memory 530 and may be executed by controller 505 under operating system 515.
While certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents may occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the invention.
This application claims benefit of U.S. Provisional Patent Application No. 61/098,242, filed Sep. 19, 2008, which is incorporated in its entirety herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61098242 | Sep 2008 | US |
