Optimization of computing resources through monitoring and manipulating availabilty

In a method of managing a computing network, an expected behavior of a host is determined. The host is associated with a network resource, and is configured to be switched between active and inactive states. When the host is in the inactive state, a message is transmitted via the network on behalf of the host based on the expected behavior thereof such that the host appears to be in the active state. Related computer systems and computer program products are also discussed.

BACKGROUND

Various embodiments described herein relate to computer systems, methods and program products and, more particularly, to management of computer systems, methods and computer program products.

The costs of having host/server computers in a data center switched on and running may be significant, both in terms of resources (e.g., CPU, RAM, disk as well as power/cooling etc.) and money. For example, the costs of server power consumption and cooling systems to dissipate the generated heat may be major expenses in modern data centers.

To maintain effective operation and sustain profitability, power management systems may be used to reduce power usage while simultaneously satisfying customer requirements. For example, a typical server may consume a relatively high amount of power even when idle, due for instance to chip leakage current and/or power consumption of other supporting components, such as disk drives and network routers.

Turning a system off and directing traffic to a subset of available servers during non-peak hours may be one approach to saving power during periods of low traffic. Some such technologies for server shutdown may mainly be based on manual actions by system administrators. However, having to manually power on hosts when required may be tedious and/or difficult to manage, for example, due to the amount of manual effort required and/or due to over-provisioning that may be used to ensure that performance goals are met. Likewise, while some server shutdown/startup technologies may be automated, they are typically driven by simple policies. For example, some automated resource management solutions may simply base the conditions to detect host shutdown/startup on the time of day and/or date.

SUMMARY

According to some embodiments of the present disclosure, in a method of managing a computing network, an expected active-state behavior of a host is determined. The host is associated with a network resource, and is configured to be switched between active and inactive states. When the host is in the inactive state, a message is transmitted via the network on behalf of the host based on the expected behavior thereof such that the host appears to be in the active state. The determining and the transmitting are performed by at least one processor, which may be distinct from hardware associated with the host.

According to further embodiments of the present disclosure, a computer system for managing a computing network includes at least one processor and a memory coupled to the processor. The memory includes computer readable program code embodied therein that, when executed by the processor, causes the processor to determine an expected active-state behavior of a host. The host is associated with a network resource, and is configured to be switched between active and inactive states. When executed by the processor, the computer readable program code further causes the processor to transmit, when the host is in the inactive state, a message via the network on behalf of the host based on the expected behavior thereof such that the host appears to be in the active state.

According to still further embodiments of the present disclosure, a computer program product for managing a computing network includes a computer readable storage medium having computer readable program code embodied in the medium. The computer readable program code includes computer readable program code to determine an expected behavior of the host. The host is configured to be switched between active and inactive states, and is associated with a network resource. The computer readable program code further includes computer readable program code to transmit, when the host is in the inactive state, a message via the network on behalf of the host based on the expected behavior thereof such that the host appears to be in the active state.

It is noted that aspects described herein with respect to one embodiment may be incorporated in different embodiments although not specifically described relative thereto. That is, all embodiments and/or features of any embodiments can be combined in any way and/or combination. Moreover, other systems, methods, and/or computer program products according to embodiments will be or become apparent to one with skill in the art upon review of the following drawings and detailed description. It is intended that all such additional systems, methods, and/or computer program products be included within this description, be within the scope of the present disclosure, and be protected by the accompanying claims.

DETAILED DESCRIPTION

As described herein, a computing system or environment may include one or more hosts, operating systems, peripherals, and/or applications. Machines in a same computing system or environment may have shared memory or resources, may be associated with the same or different hardware platforms, and/or may be located in the same (e.g., local) or different (e.g., remote) physical locations. Computing environments described herein may refer to a virtualized environment (such as a cloud environment) and/or a physical environment. Machines or servers described herein may refer to physical machines or virtual machines (VMs), which may be managed by one or more virtual hypervisors in some embodiments.

Some embodiments of the present disclosure may arise from realization that some current automated resource management solutions may be driven by relatively simple policies (for example, basing conditions for host shutdown/startup on time of day and/or date), which may not be a good fit in all cases. For instance, a user/client working over a weekend may not be able to access the necessary servers/hosts to perform their duties when resource management is based on such simple polices. Additional problems may also arise in that certain network tools and protocols may rely on a ‘heart beat’ like response to continue operating, which may limit the use of such simplistic resource management. Also, some protocols (such as Simple Services Discover Protocol (SSDP) and/or Common Internet File System (CIFS)) may require servers to respond appropriately in order to maintain a list of shares and/or services (e.g., printers); thus, having the servers offline may also mean that the managed services/shares are also offline.

Accordingly, embodiments of the present disclosure may detect incoming requests and/or other attempts to access network resources hosted on a server or other system, and may power and/or de-power the associated servers accordingly, in an on-demand fashion. Furthermore, even when the server itself is in a powered-off state, responses to incoming requests can be handled on behalf of the server to maintain the appearance of availability. Embodiments of the present disclosure thereby allow machines, physical and/or virtual, to be automatically put into a low/no power state when not required, as well as to be restarted when required, thus coordinating the availability of a network resource or other service based on demand.

As such, embodiments of the present disclosure may differ from other operations for automatic shutdown/startup of a computer system in that the conditions for shutdown/startup may be, but are not necessarily, based on the system time. Rather, conditions for shutdown/startup can be determined using an ‘on-demand’ method, i.e., when the access to the resource is requested, the corresponding host can be started. Furthermore, methods of determining requests for access may involve both learning and acting on information obtained through monitoring network traffic to the host in question, in order to determine whether the host can be maintained in an inactive state. As used herein, an “inactive state” may refer to shutdown/suspend/sleep/hibernate states, or more generally, to low- or no-power states.

Thus, embodiments of the present disclosure are not only directed to signaling a host as to when to transition to/from an inactive state, but also to prolonging the duration for which the host can remain in the inactive state, by providing an appearance of availability even when the host is inactive, and signaling the host to awake from the inactive state when needed or otherwise on-demand. Embodiments of the disclosure may be implemented as a running program with network access to the hosts it is managing.

FIG. 1is a block diagram illustrating a computing system or environment for managing computing resources by monitoring and manipulating availability in accordance with some embodiments of the present disclosure. Referring now toFIG. 1, the environment100includes at least one client or other requesting entity101, one or more servers/hosts105A-105N, and a resource manager130communicatively coupled via a network120. The servers/hosts105A-105N are configured to manage one or more network resources (collectively and/or individually) to provide hardware and/or software services, for example, responsive to requests from the client/requesting entity101.

The resource manager130is configured to signal the servers/hosts105A-105N to switch between inactive and active states in an on-demand manner, allowing for improved resource conservation. In the embodiment ofFIG. 1, the resource manager130includes a network monitor135, a behavior analyzer150, a message generator160, and a network traffic library140. The network traffic library140stores a set of messages (including requests and associated responses) and/or other data sampled from prior communications with (i.e., to and/or from) the servers/hosts105A-105N. The resource manager130operates by observing communications between one or more clients/requesting entities101and the servers/hosts105A-105N via the network monitor135, imitating or mimicking the behavior of the servers/hosts105A-105N by determining the expected server/host behavior via the behavior analyzer150, and transmitting a corresponding message on behalf of the server/host via the message generator160, as discussed in detail herein. In some embodiments, the resource manager130may be implemented by hardware that is distinct from the hardware associated with the servers/hosts105A-105N.

The network monitor135may include or implement a network monitoring tool for monitoring communications with the servers/hosts105A-105N. The clients/requesting entities101and the servers/hosts105A-105N may communicate via the network120using any number of communications modes or protocols. The network monitor135records network traffic and/or other data communicated via the network120, particularly messages (including requests and responses thereto) communicated with (i.e., to and/or from) the servers/hosts105A-105N, for example, using a network sniffer tool. The network monitor135stores these messages in the network traffic library140. For example, the network monitor135may store the messages received by and transmitted from the servers/hosts105A-105N in the network traffic library140, as request/response pairs. Any number of message interactions with the servers/hosts105A-105N can be recorded, for example, as may be needed for message generation as discussed below. The network traffic library140thus provides historical data for the servers/hosts105A-105N, which is used as a source for expected behavior analysis and response generation as described below.

The behavior analyzer150is configured to determine an expected behavior of one or more of the hosts105A-105N based on the network traffic communicated therewith, as stored in the network traffic library140. In some embodiments, the behavior analyzer150may determine the expected behavior for a host105A-105N by comparing an incoming request or other current network conditions with the network traffic previously communicated with that host, and identifying a particular message among the messages stored in the network traffic library140that most closely corresponds to the incoming request or other current network conditions.

When one or more of the servers/hosts105A-105N are in an inactive state, the message generator160is configured to synthesize or otherwise generate a message based on the expected behavior of the servers/hosts105A-105N as determined by the behavior analyzer150. The message may be, for example, a recurring message (such as an availability indicator) transmitted by a server/host105A-105N at a predetermined time and/or frequency. Additionally or alternatively, the message may be a response to a request for a resource managed by the server/host105A-105N. In some embodiments, the message may be a response corresponding to a particular one of the request/response pairs stored in the network traffic library, as identified by the behavior analyzer150based on an incoming request or other network conditions. The message generator160thereby generates and transmits a message via the network102on behalf of the associated server/host105A-105N, when that server/host105A-105N is in an inactive state. Thus, a response or other message that would have been provided by an active server/host105A-105N is automatically generated using the request/response pairs stored in the network traffic library140and transmitted via the network120even when the server/host105A-105N is inactive, providing an appearance of availability while allowing the inactive state to be prolonged.

It will be appreciated that in accordance with various embodiments of the present disclosure, the resource manager130and the servers105A-105N may be implemented as a single server, separate servers, or a network of servers (physical and/or virtual), which may be co-located in a server farm or located in different geographic regions. In particular, as shown in the example ofFIG. 1, the resource manager130is coupled to the servers105A-105N via network120. The network120may be a global network, such as the Internet or other publicly accessible network. Various elements of the network120may be interconnected by a wide area network (WAN), a local area network (LAN), an Intranet, and/or other private network, which may not be accessible by the general public. Thus, the communication network120may represent a combination of public and private networks or a virtual private network (VPN). The network120may be a wireless network, a wireline network, or may be a combination of both wireless and wireline networks. Although illustrated as a common network, it will be understood that the network120may represent one or more separate networks in some embodiments. As such, one or more of the resource manager130and the servers105A-105N may be co-located or remotely located, and communicatively coupled by one or more of the networks. More generally, althoughFIG. 1illustrates an example of a computing environment100, it will be understood that embodiments of the present disclosure are not limited to such a configuration, but are intended to encompass any configuration capable of carrying out the operations described herein.

FIG. 2illustrates an example computing device200in accordance with some embodiments of the present disclosure. The device200may be used, for example, to implement the resource manager130in the system100ofFIG. 1using hardware, software implemented with hardware, firmware, tangible computer-readable storage media having instructions stored thereon, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. The computing device200may also be a virtualized instance of a computer. As such, the devices and methods described herein may be embodied in any combination of hardware and software.

As shown inFIG. 2, the computing device200may include input device(s)205, such as a keyboard or keypad, a display210, and a memory215that communicate with one or more processors220(generally referred to herein as “a processor”). The computing device200may further include a storage system225, a speaker245, and I/O data port(s)235that also communicate with the processor220. The memory212may include a resource management module230installed thereon. The resource management module230may be configured to control startup/shutdown (or more generally, active/inactive states) of one or more servers or hosts that manage resources on a network, as well as to mimic the behavior of the host(s) in response to requests for the network resources and/or other network conditions, as described herein.

The storage system225may include removable and/or fixed non-volatile memory devices (such as but not limited to a hard disk drive, flash memory, and/or like devices that may store computer program instructions and data on computer-readable media), volatile memory devices (such as but not limited to random access memory), as well as virtual storage (such as but not limited to a RAM disk). The storage system225may include a network traffic library240storing network traffic (including but not limited to requests and associated responses) and other data communicated with a host, which may be accessed by the resource management module230to determine an expected behavior of an inactive host and transmit a response on its behalf, as described herein. Although illustrated in separate blocks, the memory212and the storage system225may be implemented by a same storage medium in some embodiments.

The input/output (I/O) data port(s)235may include a communication interface and may be used to transfer information in the form of signals between the computing device200and another computer system or a network (e.g., the Internet). The communication interface may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, or the like. These components may be conventional components, such as those used in many conventional computing devices, and their functionality, with respect to conventional operations, is generally known to those skilled in the art. Communication infrastructure between the components ofFIG. 2may include one or more device interconnection buses such as Ethernet, Peripheral Component Interconnect (PCI), and the like.

FIG. 3illustrates a software/hardware architecture300for management of network resources in accordance with further embodiments of the present disclosure. In particular,FIG. 3illustrates a processor320and memory312that may be used in computing devices or other data processing systems, such as the computing device200ofFIG. 2and/or the environment100ofFIG. 1. The processor320communicates with the memory312via an address/data bus310. The processor320may be, for example, a commercially available or custom microprocessor, including, but not limited to, digital signal processor (DSP), field programmable gate array (FPGA), application specific integrated circuit (ASIC), and multi-core processors. The memory312may be a local storage medium representative of the one or more memory devices containing software and data in accordance with some embodiments of the present invention. The memory312may include, but is not limited to, the following types of devices: cache, ROM, PROM, EPROM, EEPROM, flash, SRAM, and DRAM.

As shown inFIG. 3, the memory312may contain multiple categories of software and/or data installed therein, including (but not limited to) an operating system block302and a resource management block330. The operating system302generally controls the operation of the computing device or data processing system. In particular, the operating system302may manage software and/or hardware resources and may coordinate execution of programs by the processor320, for example, in providing the environment100ofFIG. 1.

The resource management block330is configured to carry out some or all of the functionality of the network monitor135, the behavior analyzer150, and/or the message generator160ofFIG. 1. As such, the resource management block330includes a monitoring function or module335, an expected behavior/analysis function or module350, and a message generation function or module360.

The monitoring module335is configured to monitor network conditions, including network traffic communicated with a host (such as one or more of the servers/hosts105A-105N ofFIG. 1) when the host is in the active state. The network traffic may include messages, such as requests communicated to the host, and associated responses to the requests communicated from the host. The monitoring module335can automatically create a database (e.g., the network traffic library140ofFIG. 1) storing the messages communicated with the host during the active state (for example, as request/response pairs) responsive to monitoring the network traffic communicated with the host. The monitoring module335may also be configured to identify and enumerate the network resource(s) managed by the host responsive to monitoring the network traffic communicated therewith. The monitoring module335can further detect an activity level of the host relative to one or more predetermined thresholds, and the resource management block330may signal the host to transition from the active state to the inactive state based on the detected activity level relative to the threshold(s). The threshold(s) may be time-based, date-based, and/or traffic-based in some embodiments.

The expected behavior/analysis module350is configured to determine an expected active-state behavior of the host. The expected behavior may be determined based on the current network conditions monitored by the monitoring module335and/or based on network traffic previously communicated with the host (e.g., as stored in the network traffic library/database). For example, based on the previously communicated traffic, the expected behavior/analysis module350may determine that the host is expected to transmit a recurring message associated with its network resource(s) under certain network conditions, e.g., that the host is expected to transmit an availability indicator at a particular time and/or frequency. Additionally or alternatively, the expected behavior/analysis module350may determine that the host is expected to transmit a particular message by identifying such a message among the messages stored in the database. In particular, the expected behavior/analysis module350may compare an incoming request for a network resource associated with the host with the request/response pairs stored in the network traffic library, and may identify one of the stored responses as corresponding to the expected response, based on a similarity of the request paired therewith to the incoming request. Also, the expected behavior/analysis module350may identify the incoming request as a request for static information (e.g., a static request), and may determine the expected response based on the data stored in the network traffic library or other pre-existing information that is accessible thereto.

As such, when the host is in the inactive state, the message generation module360is configured to generate and transmit a message via the network on behalf of the host based on the expected behavior determined by the expected behavior/analysis module350. For example, the message generation module360may generate and transmit an expected recurring message (such as an availability indicator) on behalf of the host responsive to determination thereof by expected behavior/analysis module350. Additionally or alternatively, based on the identification of one of the stored responses as corresponding to the expected response by the expected behavior/analysis module350, the message generation module360may generate the expected response and transmit the expected response via the network on behalf of the host. The message generation module360may generate the expected response from or by adapting the identified response, for instance, using symmetric field substitution. As such, when the host is in the inactive state, the message generation module360is configured to generate and transmit messages on its behalf, providing the appearance that the host is still in the active state, and allowing the host to be maintained in the inactive state for an extended duration.

In addition, based on the current and/or previous network traffic and/or other network conditions (as indicated by the monitoring module335), the expected behavior/analysis module350is configured to determine whether the active state of the host is necessary. For example, the expected behavior/analysis module350may identify an incoming request as a request for information not indicated by the monitored network traffic (e.g., a non-static or dynamic request), or may otherwise determine that the expected host behavior is beyond the imitation capabilities of the resource management module330. As such, the resource management block330may signal the host to transition from the inactive state to the active state, for example, via the message generator360. The resource management block330may also relay or forward the received request to the host responsive to signaling the host to switch to the active state, so that the host may respond appropriately.

AlthoughFIG. 3illustrates example hardware/software architectures that may be used in a device, such as the computing device200ofFIG. 2, to manage computing resources by monitoring and manipulating availability in accordance with some embodiments described herein, it will be understood that the present invention is not limited to such a configuration but is intended to encompass any configuration capable of carrying out operations described herein. Moreover, the functionality of the computing device200ofFIG. 2and the hardware/software architecture ofFIG. 3may be implemented as a single processor system, a multi-processor system, a processing system with one or more cores, a distributed processing system, or even a network of stand-alone computer systems, in accordance with various embodiments.

FIGS. 4A-4Cillustrate operations for managing computing resources by monitoring and manipulating availability in accordance with some embodiments of the present disclosure. As shown inFIG. 4A, a computing system400includes a file share server405, a print server410, and a resource manager430communicatively coupled via a network420. InFIG. 4A, the file share server405and a print server410are in an online or active mode. As such, in response to a request for a file share list, the file share server405generates and transmits a list response via the network420. Likewise, in response to a request for available printers, the printer server410generates and transmits a list of available printers via the network420. The resource manager430is configured to monitor traffic on the network420, including the aforementioned requests and responses, and record these messages in a database, such as the network traffic library140ofFIG. 1. As such, the resource manager430may collect and store historical data indicative of the behavior of the servers/hosts405,410, as well as identify and/or enumerate the network resources (as provided by the servers405,410) that are available on the network420.

InFIG. 4B, the resource manager430signals the servers405,410to shut down, suspend operations, sleep, or otherwise transition to an inactive state (illustrated by an “X”). The resource manager430may signal the servers405,410to enter the inactive state based on a variety of factors or triggers, including but not limited to time-based, date-based, and/or (where multiple servers are present) traffic-based triggers. When the file share server405and a print server410are inactive, the resource manager430is configured to mimic the behavior of the servers405,410, based on the requests and responses recorded inFIG. 4A. As such, in response to identifying a request for a file share list on the network420, the resource manager430determines that the requested information can be spoofed, and thus generates and transmits a response to the requesting entity based on the network traffic data previously recorded inFIG. 4A. Similarly, in response to identifying a request for available printers, the resource manager430generates and transmits the list of the available printers via the network420based on a previously recorded network traffic. The resource manager430may thereby determine the expected responses from the file share server405and/or the print server410and generate the expected responses on their behalf, thereby spoofing or mimicking the behavior of the servers405and/or410. As such, the inactive states of the servers405and410may be prolonged (thereby saving energy and network resources), while the servers405and410still appear to be active or otherwise available to the requesting entities.

FIG. 4Cillustrates operations of the resource manager430in response to a resource request that cannot be spoofed or imitated, such as a dynamic request. In particular, in response to identifying a print request on the network420, the resource manager430determines that the requested information is beyond its capabilities, and that the expected response cannot be mimicked and requires actual interaction with the print server410. As such, the resource manager430stores the print job request and signals the print server410to transition to an active state by transmitting an out of band (00B) call to power up the print server410. When the print server410is active, the resource manager430forwards the print job request to the print server410, and the print server410processes the print job request. The resource manager430also recognizes that the received print job request does not require interaction with file share server405, and thus, maintains the file share server405in the inactive state. As such, the resource manager430is configured to coordinate the availability of the services provided by the servers405and/or410on-demand.

Computer program code for carrying out the operations discussed above with respect toFIGS. 1-4may be written in a high-level programming language, such as COBOL, Python, Java, C, and/or C++, for development convenience. In addition, computer program code for carrying out operations of the present disclosure may also be written in other programming languages, such as, but not limited to, interpreted languages. Some modules or routines may be written in assembly language or even micro-code to enhance performance and/or memory usage. It will be further appreciated that the functionality of any or all of the program modules may also be implemented using discrete hardware components, one or more application specific integrated circuits (ASICs), or a programmed digital signal processor or microcontroller.

Operations for managing network resources in accordance with some embodiments of the present disclosure will now be described with reference to the flowcharts ofFIGS. 5 to 7. The operations described with reference toFIGS. 5 to 7may be performed by the hardware/software architecture ofFIG. 3, the computing device200ofFIG. 2, the resource manager130or430ofFIGS. 1 and 4, and/or elements thereof.

Referring now toFIG. 5, operations begin at block515where an expected behavior of a host in an active state is determined. The host may manage or otherwise be associated with one or more network resources. For example, the expected behavior of the host may be determined based on messages (including requests and responses) previously communicated with (i.e., to and/or from) the host, which may be stored in a database or library as historical data. As such, when the host is in an inactive state (for example, when the host is shutdown or in “sleep” mode), a message may be transmitted via the network on its behalf based on the expected behavior at block525. For example, the message may be a recurring message associated with the network resource that is typically transmitted by the host at a predetermined time and/or frequency, or may be a response to a detected request for the network resource. As such, even though the host may be powered-off or otherwise inactive, an appearance of availability of the host may be provided to a requesting device (such as the client101ofFIG. 1).

FIG. 6illustrates operations for managing computing resources by monitoring and manipulating availability in accordance with embodiments of the present disclosure in greater detail. Referring now toFIG. 6, operations began at block605where an active host is signaled to switch to an inactive state. For example, the host may be switched to the inactive state based on a threshold, which may be time based, date based, and/or traffic based, or may otherwise be determined based on activity level of the host. In some embodiments, the host may be switched to the inactive states by signaling a hypervisor to suspend a guest operating system (OS), or by signaling the operating system to transition to a suspension or hibernation mode.

While the host is in the inactive state, network conditions are monitored at block610. For example, the network may be monitored to detect or identify incoming requests for one or more resources managed by the host, and/or to determine other conditions that may require host action. At block615, an expected behavior of the host is determined based on the network conditions. The expected behavior may be determined based on historical data, such as network traffic previously communicated with the host, which may be monitored and automatically stored in a network traffic library, such as the library140ofFIG. 1. Additionally or alternatively, a database including information indicative of the expected behavior of the host under a variety of network conditions may be manually created by a programmer or other user.

Still referring toFIG. 6, at block620, it is determined whether the active state of the host is required. For example, it may be determined that actual host interaction is required based on the expected host behavior in response to an incoming request. In particular, it may be determined that the response to a request for static information does not require host interaction (as the requested information may be included in the stored network traffic library); conversely, it may be determined that the response to a request for dynamic information requires the host to be in the active state (as the requested information may not be indicated by the stored network traffic and/or may otherwise be incapable of being mimicked). If it is determined at block620that actual host interaction is required, the host is signaled to switch to the active state at block630, and the request is relayed to the host so that the host itself may transmit a response.

However, if it is determined at block620that actual host interaction is not required, a message is transmitted on behalf of the host at block625. For example, based on the network conditions, it may be determined that the expected host behavior involves transmission of a recurring message at predetermined times and/or frequencies, and such a message may thereby be generated and transmitted via the network on behalf of the host at block625. Additionally or alternatively, it may be determined that a response to an incoming request may be generated by referencing a similar previously stored request and its associated response stored in the network traffic library, and such a response may be generated and transmitted on behalf of the host at block625in response to the request. As such, the active behavior of the host may be mimicked while maintaining the host in the inactive state, thereby providing an appearance availability to a requesting entity while increasing the duration of inactivity of the host, saving both money and resources.

FIG. 7further illustrates operations for managing computing resources by monitoring and manipulating availability in accordance with embodiments of the present disclosure. Referring now toFIG. 7, operations begin at block700, where the network is monitored (or “snooped” in a promiscuous mode) for traffic communicated to and/or from an active host. Network resource(s) managed by the host may be identified and/or enumerated responsive to the monitoring. For example, it may be determined that one of the hosts being managed has a shared printer, and that this fact is ‘announced’ at regular periods by the host OS. As another example, it may be determined that a regular ICMP (ping) packet or ARP packet is transmitted on a recurring basis to indicate the availability of a host.

At block705, the activity level of the host is detected. In some embodiments, a threshold (for example, based on time, date, and/or network traffic) may be used to detect the host activity level. When it is determined that a particular host is not in use, the host is signaled to transition to a low/no power state (or other inactive state) at block710. For example, the host may be transitioned to the inactive state by signaling its hypervisor to suspend the guest OS, or by signaling the OS to suspend and/or hibernate.

While the host is in the inactive state, the behavior of the host may be imitated or mimicked so as to provide an appearance of host availability. For example, recurring messages that are typically transmitted by the host may be repeatedly and/or periodically be broadcast on behalf of the host while the host is inactive. In a particular example, while the host is in the inactive state, a request to access a resource managed by the host is identified at block715, and it is determined at block720whether a response to the request requires the host to be in the active state. For instance, as noted above, responses to requests for dynamic information may require actual host interaction, while responses to requests for static information may not (as such information may be available from and/or indicated by a database, such as the network traffic library described herein). If it is determined at block720that the active state of the host is not required, a response is generated and transmitted on behalf of the host at block725. For example, in the case of an ICMP request, the appropriate ICMP response may be generated and transmitted, such that the host appears to be up and available on the network.

On the other hand, if a request is identified at block715and it is determined at block720that a response requires actual server interaction (for example, a request for print job), the host is signaled to resume/wakeup or otherwise transition to the active state at block730. When the host wakes or is otherwise active, a copy of the request identified at block715is relayed to the host at block735. The host may thereby respond appropriately. Accordingly, embodiments of the present disclosure allow for automatic management of host shutdown and start up, while retaining the appearance of availability.