Meta chunks

Data protection with meta chunks increases capacity use efficiency without verification and data copying. In one aspect, a meta chunk is a data protection unit, which combines two or more source chunks that are determined to have a reduced sets of data fragments. The meta chunk can be encoded to generate a set of coding fragments, which can be stored and utilized to recover data fragments of any of the two or more source chunks. Further, the source chunks can be linked to the meta chunk. Furthermore, the sets of coding fragments, that were previously generated by individually encoding each source chunk, can be deleted.

TECHNICAL FIELD

The subject disclosure relates generally to storage systems. More specifically, this disclosure relates to a system and method for efficient data protection with meta chunks.

BACKGROUND

The large increase in amount of data generated by digital systems has created a new set of challenges for data storage environments. Traditional storage area network (SAN) and/or network-attached storage (NAS) architectures have not been designed to support data storage and/or protection at large multi-petabyte capacity levels. Object storage technology can be utilized to meet these requirements. By utilizing object storage technology, organizations can not only keep up with rising capacity levels, but can also store these new capacity levels at a manageable cost point.

Typically, a scale-out, cluster-based, shared-nothing object storage that employs a microservices architecture pattern, for example, an Elastic Cloud Storage (ECS™) can be utilized as a storage environment for a new generation of workloads. ECS™ utilizes the latest trends in software architecture and development to achieve increased availability, capacity use efficiency, and performance. ECS™ uses a specific method for disk capacity management, wherein disk space is partitioned into a set of blocks of fixed size called chunks. User data is stored in these chunks and the chunks are shared. One chunk can comprise fragments of several user objects. Chunk content is modified in an append mode. When chunks become full, they are sealed and the content of sealed chunks is immutable. Oftentimes, chunks can comprise a reduced set of data fragments. This increases capacity overheads on data protection and there are some cases when the overheads may be unreasonably high.

SUMMARY

Example systems and methods, and other embodiments, disclosed herein relate to facilitating capacity management in distributed storage systems. In one example embodiment, a system is disclosed that comprises a processor and a memory that stores executable instructions that, when executed by the processor, facilitate performance of operations. Moreover, the operations comprise determining source chunks stored within an object storage system; wherein the source chunks are determined to have fewer than a defined number of data fragments. Further, operations comprise based on combining the source chunks, generating a meta chunk; and encoding the meta chunk to generate coding fragments that are employable to recover at least a portion of the source chunks.

Another example embodiment of the specification relates to a method that comprises selecting, by a system comprising a processor, source chunks from chunks of an object storage system; wherein the source chunks are determined to have fewer data fragments than remaining of the chunks other than the source chunks and combining the source chunks to generate a meta chunk. Further, the method comprises based on erasure coding the meta chunk, determining coding fragments for the source chunks at a meta chunk level, wherein the coding fragments are to be employed to recover at least a portion of the source chunks during a failure condition.

Another example embodiment of the specification relates to a computer-readable storage medium comprising instructions that, in response to execution, cause a computing node device comprising a processor to perform operations, comprising combining source chunks stored within an object storage system to generate a meta chunk; wherein the source chunks are determined to have fewer than a defined number of data fragments; and based on erasure coding the meta chunk, determining coding fragments for the source chunks at a meta chunk level, wherein the coding fragments are to be employed to recover at least a portion of the source chunks during a failure condition.

DETAILED DESCRIPTION

One or more embodiments are now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the various embodiments. It may be evident, however, that the various embodiments can be practiced without these specific details, e.g., without applying to any particular networked environment or standard. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the embodiments in additional detail.

The term “cloud” as used herein can refer to a cluster of nodes (e.g., set of network servers), for example, within a distributed object storage system, that are communicatively and/or operatively coupled to each other, and that host a set of applications utilized for servicing user requests. In general, the cloud computing resources can communicate with user devices via most any wired and/or wireless communication network to provide access to services that are based in the cloud and not stored locally (e.g., on the user device). A typical cloud-computing environment can include multiple layers, aggregated together, that interact with each other to provide resources for end-users.

Example systems and methods disclosed herein, in one or more embodiments, relate to an elastic cloud storage (ECS™) platform that can combine the cost advantages of commodity infrastructure with the reliability, availability and serviceability of traditional arrays. In one aspect, the ECS™ platform can comprise a cluster of nodes (also referred to as “cluster” herein) that delivers scalable and simple public cloud services with the reliability and/or control of a private-cloud infrastructure. Moreover, the ECS™ platform comprises a scale-out, cluster-based, shared-nothing object storage, which employs a microservices architecture pattern. The ECS™ platform can support storage, manipulation, and/or analysis of unstructured data on a massive scale on commodity hardware. As an example, ECS™ can support mobile, cloud, big data, content-sharing, and/or social networking applications. ECS™ can be deployed as a turnkey storage appliance or as a software product that can be installed on a set of qualified commodity servers and/or disks. The ECS™ scale-out and geo-distributed architecture is a cloud platform that can provide at least the following features: (i) lower cost than public clouds; (ii) unmatched combination of storage efficiency and data access; (iii) anywhere read/write access with strong consistency that simplifies application development; (iv) no single point of failure to increase availability and performance; (v) universal accessibility that eliminates storage silos and inefficient extract, transform, load (ETL)/data movement processes; etc.

In an aspect, ECS™ does not rely on a file system for disk capacity management. Instead, ECS™ partitions disk space into a set of blocks of fixed size called chunks (e.g., having a chunk size of 128 MB). All user data is stored in these chunks and the chunks are shared. Typically, a chunk can comprise fragments of several different user objects. The chunk content can be modified in an append-only mode. When a chunk becomes full, it can be sealed and the content of a sealed chunk is immutable. Further, ECS™ does not employ traditional data protection schemes like mirroring or parity protection. Instead, ECS™ utilizes erasure coding for data protection. Although the systems and methods disclosed herein have been described with respect to object storage systems (e.g., ECS™), it is noted that the subject specification is not limited to object storage systems and can be utilized for most any storage systems that utilize erasure coding for data protection and chunks for disk capacity management. Thus, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the technology may be used in various ways that provide benefits and advantages in computing and data storage in general.

FIG. 1shows part of a cloud data storage system such as ECS™ comprising a zone (e.g., cluster)102of storage nodes104(1)-104(M), in which each node is typically a server configured primarily to serve objects in response to client requests (e.g., received from clients108). The nodes104(1)-104(M) can be coupled to each other via a suitable data communications link comprising interfaces and protocols such as, but not limited to, Ethernet block106.

Clients108can send data system-related requests to the cluster102, which in general is configured as one large object namespace; there may be on the order of billions of objects maintained in a cluster, for example. To this end, a node such as the node104(2) generally comprises ports112by which clients connect to the cloud storage system. Example ports are provided for requests via various protocols, including but not limited to SMB (server message block), FTP (file transfer protocol), HTTP/HTTPS (hypertext transfer protocol), and NFS (Network File System); further, SSH (secure shell) allows administration-related requests, for example.

Each node, such as the node104(2), includes an instance of an object storage system114and data services. For a cluster that comprises a “GEO” zone of a geographically distributed storage system, at least one node, such as the node104(2), includes or coupled to reference tracking asynchronous replication logic116that synchronizes the cluster/zone102with each other remote GEO zone118. Note that ECS™ implements asynchronous low-level replication, that is, not object level replication. Typically, organizations protect against outages or information loss by backing-up (e.g., replicating) their data periodically. During backup, one or more duplicate or deduplicated copies of the primary data are created and written to a new disk or to a tape, for example within a different zone. The term “zone” as used herein can refer to one or more clusters that is/are independently operated and/or managed. Different zones can be deployed within the same location (e.g., within the same data center) or at different geographical locations (e.g., within different data centers).

In general, and in one or more implementations, e.g., ECS™, disk space is partitioned into a set of large blocks of fixed size called chunks; user data is stored in chunks. Chunks are shared, that is, one chunk may contain segments of multiple user objects; e.g., one chunk may contain mixed segments of some number of (e.g., three) user objects. In one embodiment, a chunk manager120can be utilized to manage the chunks and their protection (e.g., via erasure coding (EC)). In an aspect, the chunk manager120can generate meta chunks, wherein a meta chunk is a data protection unit, which unites two or more normal (e.g., source) chunks that have a reduced sets of data fragments. A CPU122and RAM124are shown for completeness; note that the RAM124can comprise at least some non-volatile RAM. The node includes storage devices such as disks126, comprising hard disk drives and/or solid-state drives. It is noted that the storage devices can comprise volatile memory(s) or nonvolatile memory(s), or both volatile and nonvolatile memory(s). Examples of suitable types of volatile and non-volatile memory are described below with reference toFIG. 10. The memory (e.g., data stores, databases, tables, etc.) of the subject systems and methods is intended to comprise, without being limited to, these and any other suitable types of memory.

FIG. 2illustrates an example layout200of a chunk within an object storage system in accordance with an aspect of the specification. In an aspect, disk space of the object storage system can be partitioned into a set of blocks of fixed size called chunks. As an example, the chunk size can be 128 MB. Typically, user data is stored in these chunks and the chunks are shared. As shown inFIG. 2, a chunk202can comprise segments of several user objects (e.g., object1segments204, object2segments206, and object3segments208). It is noted that the chunk layout depicted inFIG. 2. is one example and the chunks can have most any other layout with segments from one or more user objects. Chunk content is modified in an append-only mode. When the chunk becomes full enough, it is sealed. After the chunk is sealed, its content is immutable.

In an aspect, the chunk can be protected by employing erasure coding. During erasure coding, a chunk can be divided into k data fragments of equal size. To encode the chunk, redundant m coding fragments are created so that the system can tolerate the loss of any m fragments. The process of generating the coding fragments is called encoding. The process of data fragments recovery using available data and coding fragments is called decoding. As an example, the encoding operation can be represented with the equation below:

Ci=∑j=1k⁢Ci,j(1)
wherein,
Ci,j=Xi,j*Dj(2)
and wherein, Xi,jis a defined coefficient from a coding matrix (e.g., wherein i, j, and/or k can be most any integer). Further, Djare independent data fragments and Ciare coding fragments.

According to an aspect, the systems and methods disclosed herein can support geographically distributed setups (GEO) comprising two or more zones. GEO can be used to provide an additional protection of user data by means of replication. Replication works at the chunk level, wherein a backup copy of a chunk stored in a primary zone can be replicated to one or more secondary zones. Each zone protects the chunks it stores. If a copy of a chunk becomes unavailable, it can be recovered using its other copy. This process is called GEO recovery.

Referring now toFIG. 3, there illustrated is an example system300for generating meta chunks, according to an aspect of the subject disclosure. In one aspect, the chunk manager120can efficiently protect chunks, for example, by employing erasure coding. As an example, the chunk manager120can include functionality as more fully described herein, for example, as described above with regard to system100.

In one aspect, a source chunk detection component302can be utilized to determine two or more source chunks. As an example, a source chunk is a chunk that comprises fewer data fragments than a maximum number (k) of data fragments that can be stored within a chunk. There are several cases when a chunk has fewer than k data fragments. In one example, a chunk can be sealed before it gets filled. In this example scenario, a storage system stores only one or more (l) first data fragments, the data fragments with user data and the remaining k-l data fragments contain no user data so they are not stored. This scenario is normally a result of a failure or a node restart. As an example, when a storage system survives a period of instability, the system may produce thousands of poorly filled chunks with just one or two data fragments. In another example, a quasi-compacting garbage collection process detects unused blocks within chunks, reclaims their capacity, and re-uses the freed capacity to create new composite chunks. With the quasi-compacting garbage collection on, chunks degrade gradually. That is, a particular chunk can “lose” its data fragments at its beginning, its end, or in the middle. The number of lost fragments grows with the lapse of time.

Typically, a chunk table304can store information about chunks, for example, the number of data fragments stored in each chunk. The source chunk detection component302can utilize this information to identify two of more source chunks that can be combined to generate a meta chunk. As an example, source chunk detection component302can determine source chunks that when combined have k (or fewer than k) data fragments. The source chunk detection component302can optimize the source chunks selected such that the combined number of data fragments of the chunks has the closest value to k. It is noted that a source chunk can be a normal chunk or an existing meta chunk.

According to an aspect, a meta chunk generation component306can create a new meta chunk based on the source chunks selected by the source chunk detection component302. It is noted that physical capacity is not allocated for the meta chunk. However, the meta chunk generation component306can create a layout within the new meta chunk. This layout maps the data fragments of the source chunks to the data fragments of the new meta chunk. This mapping can be stored within the chunk table304. The creation of meta chunks does not impact data access because data location is still specified using source chunks, which remain the same. This assures advantage of meta chunks over conventional copying garbage collection. Use of meta chunks does not require resource-demanding verification procedure. Further, utilization of meta chunks does not require user data location updates. In one example, meta chunks can be utilized to protect user data at the zone/cluster level and information about meta chunks is typically not replicated to remote zones.

FIG. 4illustrates an example system400that facilitates efficient data protection by employing meta chunks. In one aspect, the chunk manager120and the meta chunk generation component306can include functionality as more fully described herein, for example, as described above with regard to systems100and300. Typically, erasure coding is utilized for data protection. Moreover, when data is protected with erasure coding, the overheads on data protection are be calculated as m/k. In the situation when a chunk has fewer data fragments (l) the overheads are m/l. Thus, the fewer l, the greater capacity overheads on data protection and there are cases when the overheads may be unreasonably high. Conventional copying garbage collection mechanisms are too slow to make a difference. In contrast, system400can protect chunks that have reduced sets of data fragments (e.g., by employing meta chunks) while efficiently reducing the overheads on data protection.

As described in detail supra, the meta chunk generation component306can generate a new meta chunk. A layout can be created within the new meta chunk that maps the data fragments of the source chunks to the data fragments of the new meta chunk. Further, an encoding component402can utilize erasure coding to encode the new meta chunk. The combined data fragments of the source chunks involved (k or fewer) are used for encoding. The encoding component402can generate and store m coding fragments for the new meta chunk. In an aspect, metadata of the source chunks (e.g., stored in chunk table304) can be updated to reference their meta chunk.

Furthermore, a cleanup component404can be utilized to delete coding fragments associated with the source chunks (e.g., that were previously generated to protect each source chunk). As an example, for N source chunks, the cleanup component404can delete N sets of m coding fragments, one set per source chunk from the initial set. Source meta chunks (if any) can also be deleted by the cleanup component404. Performing data protection at the meta chunk level (instead of source chunk level) allows to reduce the capacity overheads by N times, where N is a number of source chunks united in one meta chunk. Moreover, N*m previously generated coding fragments for the source chunks are replaced with just m coding fragments of the standard size for a meta chunk.

FIG. 5illustrates an example system500that facilitates efficient data recovery by employing meta chunks. In one aspect, a recovery component502can be utilized to recover one or more source chunks that have been protected at a meta chunk level. It is noted that the chunk table304can include functionality as more fully described herein, for example, as described above with regards to system300.

In one aspect, a failure detection component502can determine that a failure condition has occurred. For example, a failure condition can comprise a loss and/or unavailability of data (e.g., one or more data and/or coding fragments) due to data corruption, hardware failures, data center disasters, natural disasters, malicious attacks, etc. Moreover, the failure detection component502can detect the unavailability and/or loss at the source chunk level. A decoding component506can perform recovery of the data fragment at the meta chunk level. For example, the decoding component506can employ a decoding matrix that corresponds to the coding matrix utilized during erasure coding. Further, the decoding component506can utilize mapping information (e.g., that maps source chunks to a meta chunk) that is, for example, stored within the chunk table304, to determine the meta chunk that is too be recovered. The decoding results in a recovery of the data fragments, which can then be stored as a part of its parent source chunk (e.g., by employing the data storage component508).

FIGS. 6A-6Ddepict example embodiments that illustrate reduction of capacity overheads on data protection via meta chunks.FIG. 6Aillustrates three example chunks, chunk A602, chunk B604, and chunk C606, that have a reduced set of data fragments608. Moreover, in this example scenario, a 12+4 (k=12, m=4) erasure coding protection scheme/protocol is applied for data protection and coding fragments610are generated for each chunk A-C. Although only three chunks are depicted, it is noted that the subject disclosure is not limited to three chunks with a 12+4 protection scheme, and most any number (greater than 1) of chunks with most any erasure coding protection scheme can be utilized.

In this example, Chunk A602comprises nine data fragments, D1A, D3A, D4A, D5A, D6A, D7A, D10A, D11A, and D12A(e.g., data fragments D2A, D8A, and D9A, can be deleted by a quasi-compacting garbage collector); Chunk B604comprises one data fragment D1B(e.g., the chunk was sealed prematurely); Chunk C606comprises two data fragment D1C, D2C(e.g., the chunk was sealed prematurely). Altogether the chunks above comprise 12 (k) data fragments and 12 (3*m) coding fragments. The overheads on data protection is 1 (12/12) instead of target ⅓ ( 4/12). In one aspect, the chunks A-C can be identified as source chunks that can be combined into a meta chunk (e.g., via the source chunk detection component302).

FIG. 6Billustrates an example meta chunk M625that is generated (e.g., via the meta chunk generation component306) by combining the data fragments608of chunk A602, chunk B604, and chunk C606. As an example, the data fragments608of each source chunk (e.g., chunk A602, chunk B604, and chunk C606) can occupy a continuous range of the meta chunk M625. Encoding (e.g., erasure coding) of the meta chunk M625results in an example protected meta chunk M650illustrated inFIG. 6C. Moreover, the encoding of the meta chunk M625generates four (m) coding fragments654for the twelve data fragments652that belong to the three source chunks (chunk A602, chunk B604, and chunk C606). The source chunks (chunk A602, chunk B604, and chunk C606) can be linked with the protected meta chunk650(e.g., via the encoding component402) and the individual coding fragments610created for the normal chunks can be deleted (e.g., via the cleanup component404).

FIG. 6Dillustrates an example final layout of data and coding fragments. Since encoding is performed at meta chunk level, there are twelve data fragments (k)652and four (m) coding fragments654and the target level of overheads on data protection ⅓ ( 4/12) can be achieved. Data protection with meta chunks is a lightweight alternative to the copying garbage collector in ECS™. It increases of capacity use efficiency without verification and/or data copying. AlthoughFIGS. 6A-6Ddepict the generation and encoding of a meta chunk subsequent to encoding of individual source chunks, it is noted that the subject disclosure is not so limited and that the source chunks can be identified and employed to generate a meta chunk, before they have been individually encoded.

Referring now toFIG. 7, there illustrated is an example method700for data protection at a meta chunk level. In an aspect, method700can be performed within an object storage system, for example, ECS™. Typically, the object storage system employs a method for disk capacity management, wherein the disk space is partitioned into a set of blocks of fixed/defined size (e.g., 128 MB) called chunks. All user data can be stored in the chunks and the chunks can be shared between different users. For example, a chunk can comprise fragments of several dozens of user objects. However, one chunk can also comprise fragments of thousands of user objects (e.g., in case of email archives). Chunk content can be modified in an append-only mode. When a chunk becomes full enough, it can be sealed and once sealed, the content of the chunk is immutable. Oftentimes, chunks can be sealed before they are full and can have fewer than the maximum/defined number of data fragments (e.g., defined k data fragments for a k+l erasure coding protection protocol). Accordingly, at702, source chunks that have a reduced set of data fragments can be determined. For example, information from a chunk table (or other system data store) can be utilized to determine the source chunks.

At704, a meta chunk can be generated based on the source chunks. Physical capacity is not allocated for the meta chunk, but a layout can be created within the new meta chunk. This layout can link the data fragments of the source chunks involved to the data fragments of the meta chunk. At706, the meta chunk can be encoded to generate a set of coding fragments. As an example, the combined data fragments (k or fewer) of the source chunks are erasure coded by utilizing a k+m protection scheme and m coding fragments for the meta chunk are produced and stored. This set of coding fragments can be utilized to recover data fragments of one or more of the source chunks. At708, the source chunks can be linked to the meta chunk. As an example, the metadata of the source chunks can be updated to include a reference to the meta chunk. Further, at710, the individual sets of coding fragments, that were previously generated by individually encoding each source chunk, can be deleted. In one aspect, if the source chunks comprise one or more previously generated meta chunks, the previously generated meta chunks can also be deleted. Further, in this example scenario, the source chunks of the one or more previously generated meta chunks can be linked to the new meta chunk.

FIG. 8illustrates is an example method800for data recovery at a meta chunk level in accordance with an aspect of this disclosure. At802it can be determined that a failure condition has occurred within an object storage system (e.g., ECS™), wherein one or more fragments have become corrupted, unavailable, and/or lost. At804, it can be identified that the unavailable data fragment(s) belongs to a source chunk that is associated with a meta chunk. For example, metadata associated with the source chunk can provide a reference and/or link to a meta chunk that is to be recovered. At806, the data fragment(s) can be recovered at a meta chunk level. For example, a decoding operation can be performed by employing the coding fragments of the meta chunk. Further, at808, the recovered data fragment(s) is stored as a part of the source chunk.

The systems and methods (e.g.,100-800) disclosed herein provide at least the following non-limiting advantages: (i) reduced capacity overheads during data protection; and (ii) creation of meta chunks does not impact data access because data location is still specified using normal chunks, which remain the same. Use of meta chunks does not require neither resource-demanding verification procedure nor user data location updates.

FIG. 9illustrates an example high-level architecture900of an ECS™ cluster, according to an aspect of the subject disclosure. ECS™ can comprise a software-defined, cloud-scale, object storage platform that combines the cost advantages of commodity infrastructure with the reliability, availability and serviceability of traditional arrays. With ECS™, an organization can deliver scalable and simple public cloud services with the reliability and control of a private-cloud infrastructure. ECS™ provides comprehensive protocol support for unstructured (object and/or file) workloads on a single, cloud-scale storage platform. In an aspect, the ECS™ cluster902can comprise multiple nodes9041-904M, wherein M is most any integer. It is noted that the zones102, and/or zone(s)118, can comprise at least a portion of ECS™ cluster902. The nodes9041-904Mcan comprise storage devices (e.g. hard drives)9061-906Mand can run a set of services9081-908M. For example, single node that runs ECS™ version3.0can manage20independent services. Further, ECS™ data/management clients910can be coupled to the nodes9041-904M.

The ECS™ cluster902does not protect user data with traditional schemes like mirroring or parity protection. Instead, the ECS™ cluster902utilizes a k+m erasure coding protection scheme, wherein a data block (e.g., data chunk) is divided into k data fragments and m coding fragments are created (e.g., by encoding the k data fragments). Encoding is performed in a manner such that the ECS™ cluster902can tolerate the loss of any m fragments. As an example, the default scheme for ECS™ is 12+4, i.e. k equals to 12 and m equals to 4; however, the subject disclosure is not limited to this erasure coding protection scheme. When some fragments are lost, the missing fragments are restored via a decoding operation.

In one aspect, the storage services9081-908Mcan handle data availability and protection against data corruption, hardware failures, and/or data center disasters. As an example, the storage services9081-908Mcan comprise an unstructured storage engine (USE) (not shown), which is a distributed shared service that runs on each node9041-904M, and manages transactions and persists data to nodes. The USE enables global namespace management across geographically dispersed data centers through geo-replication. In an aspect, the USE can write all object-related data (such as, user data, metadata, object location data) to logical containers of contiguous disk space known as chunks. Chunks are open and accepting writes, or closed and not accepting writes. After chunks are closed, the USE can erasure-code them. The USE can write to chunks in an append-only pattern so that existing data is never overwritten or modified. This strategy improves performance because locking and cache validation is not required for I/O operations. All nodes9041-904Mcan process write requests for the same object simultaneously while writing to different chunks.

ECS™ continuously monitors the health of the nodes9041-904M, their disks, and objects stored in the cluster. ECS™ disperses data protection responsibilities across the cluster, it can automatically re-protect at-risk objects when nodes or disks fail. When there is a failure of a node or drive in the site, the USE can identify the chunks and/or erasure coded fragments affected by the failure and can write copies of the affected chunks and/or erasure coded fragments to good nodes and disks that do not currently have copies.

Private and hybrid clouds greatly interest customers, who are facing ever-increasing amounts of data and storage costs, particularly in the public cloud space. ECS™ provides a scale-out and geo-distributed architecture that delivers an on-premise cloud platform that scales to exabytes of data with a TCO (Total Cost of Ownership) that's significantly less than public cloud storage. Further, ECS™ provides versatility, hyper-scalability, powerful features, and use of low-cost industry standard hardware.

Referring now toFIG. 10, there is illustrated a block diagram of an example computer operable to execute data deletion with distributed erasure coding. In order to provide additional context for various aspects of the disclosed subject matter,FIG. 10and the following discussion are intended to provide a brief, general description of a suitable computing environment1000in which the various aspects of the specification can be implemented. While the specification has been described above in the general context of computer-executable instructions that can run on one or more computers, those skilled in the art will recognize that the specification also can be implemented in combination with other program modules and/or as a combination of hardware and software.

Generally, program modules include routines, programs, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the inventive methods can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, minicomputers, mainframe computers, as well as personal computers, hand-held computing devices, microprocessor-based or programmable consumer electronics, and the like, each of which can be operatively coupled to one or more associated devices. The illustrated aspects of the specification can also be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

With reference toFIG. 10, a block diagram of a computing system1000operable to execute the disclosed systems and methods is illustrated, in accordance with an embodiment. Computer1012comprises a processing unit1014, a system memory1016, and a system bus1018. As an example, the component(s), server(s), client(s), node(s), cluster(s), system(s), zone(s), module(s), agent(s), engine(s), and/or device(s) disclosed herein with respect to systems100-600and900can each include at least a portion of the computing system1000. System bus1018couples system components comprising, but not limited to, system memory1016to processing unit1014. Processing unit1014can be any of various available processors. Dual microprocessors and other multiprocessor architectures also can be employed as processing unit1014.

System bus1018can be any of several types of bus structure(s) comprising a memory bus or a memory controller, a peripheral bus or an external bus, and/or a local bus using any variety of available bus architectures comprising, but not limited to, industrial standard architecture (ISA), micro-channel architecture (MSA), extended ISA (EISA), intelligent drive electronics (IDE), VESA local bus (VLB), peripheral component interconnect (PCI), card bus, universal serial bus (USB), advanced graphics port (AGP), personal computer memory card international association bus (PCMCIA), Firewire (IEEE 1394), small computer systems interface (SCSI), and/or controller area network (CAN) bus used in vehicles.

System memory1016comprises volatile memory1020and nonvolatile memory1022. A basic input/output system (BIOS), comprising routines to transfer information between elements within computer1012, such as during start-up, can be stored in nonvolatile memory1022. By way of illustration, and not limitation, nonvolatile memory1022can comprise ROM, PROM, EPROM, EEPROM, or flash memory. Volatile memory1020comprises RAM, which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as SRAM, dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct Rambus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM).

Computer1012also comprises removable/non-removable, volatile/non-volatile computer storage media.FIG. 10illustrates, for example, disk storage1024. Disk storage1024comprises, but is not limited to, devices like a magnetic disk drive, floppy disk drive, tape drive, Jaz drive, Zip drive, LS-100 drive, flash memory card, or memory stick. In addition, disk storage1024can comprise storage media separately or in combination with other storage media comprising, but not limited to, an optical disk drive such as a compact disk ROM device (CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RW Drive) or a digital versatile disk ROM drive (DVD-ROM). To facilitate connection of the disk storage devices1024to system bus1018, a removable or non-removable interface is typically used, such as interface1026.

A user can enter commands or information into computer1012through input device(s)1036. Input devices1036comprise, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, cellular phone, user equipment, smartphone, and the like. These and other input devices connect to processing unit1014through system bus1018via interface port(s)1038. Interface port(s)1038comprise, for example, a serial port, a parallel port, a game port, a universal serial bus (USB), a wireless based port, e.g., Wi-Fi, Bluetooth®, etc. Output device(s)1040use some of the same type of ports as input device(s)1036.

Thus, for example, a USB port can be used to provide input to computer1012and to output information from computer1012to an output device1040. Output adapter1042is provided to illustrate that there are some output devices1040, like display devices, light projection devices, monitors, speakers, and printers, among other output devices1040, which use special adapters. Output adapters1042comprise, by way of illustration and not limitation, video and sound devices, cards, etc. that provide means of connection between output device1040and system bus1018. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s)1044.

Computer1012can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s)1044. Remote computer(s)1044can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device, or other common network node and the like, and typically comprises many or all of the elements described relative to computer1012.

For purposes of brevity, only a memory storage device1046is illustrated with remote computer(s)1044. Remote computer(s)1044is logically connected to computer1012through a network interface1048and then physically and/or wirelessly connected via communication connection1050. Network interface1048encompasses wire and/or wireless communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies comprise fiber distributed data interface (FDDI), copper distributed data interface (CDDI), Ethernet, token ring and the like. WAN technologies comprise, but are not limited to, point-to-point links, circuit switching networks like integrated services digital networks (ISDN) and variations thereon, packet switching networks, and digital subscriber lines (DSL).

Communication connection(s)1050refer(s) to hardware/software employed to connect network interface1048to bus1018. While communication connection1050is shown for illustrative clarity inside computer1012, it can also be external to computer1012. The hardware/software for connection to network interface1048can comprise, for example, internal and external technologies such as modems, comprising regular telephone grade modems, cable modems and DSL modems, wireless modems, ISDN adapters, and Ethernet cards.

The computer1012can operate in a networked environment using logical connections via wired and/or wireless communications to one or more remote computers, cellular based devices, user equipment, smartphones, or other computing devices, such as workstations, server computers, routers, personal computers, portable computers, microprocessor-based entertainment appliances, peer devices or other common network nodes, etc. The computer1012can connect to other devices/networks by way of antenna, port, network interface adaptor, wireless access point, modem, and/or the like.

The computer1012is operable to communicate with any wireless devices or entities operatively disposed in wireless communication, e.g., a printer, scanner, desktop and/or portable computer, portable data assistant, communications satellite, user equipment, cellular base device, smartphone, any piece of equipment or location associated with a wirelessly detectable tag (e.g., scanner, a kiosk, news stand, restroom), and telephone. This comprises at least Wi-Fi and Bluetooth® wireless technologies. Thus, the communication can be a predefined structure as with a conventional network or simply an ad hoc communication between at least two devices.

The computing system1000is operable to communicate with any wireless devices or entities operatively disposed in wireless communication, e.g., desktop and/or portable computer, server, communications satellite, etc. This includes at least WiFi and Bluetooth® wireless technologies. Thus, the communication can be a predefined structure as with a conventional network or simply an ad hoc communication between at least two devices.

WiFi, or Wireless Fidelity, allows connection to the Internet from a couch at home, a bed in a hotel room, or a conference room at work, without wires. WiFi is a wireless technology similar to that used in a cell phone that enables such devices, e.g., computers, to send and receive data indoors and out; anywhere within the range of a base station. WiFi networks use radio technologies called IEEE 802.11 (a, b, g, n, etc.) to provide secure, reliable, fast wireless connectivity. A WiFi network can be used to connect computers to each other, to the Internet, and to wired networks (which use IEEE 802.3 or Ethernet). WiFi networks operate in the unlicensed 5 GHz radio band at a 54 Mbps (802.11a) data rate, and/or a 2.4 GHz radio band at an 11 Mbps (802.11b), a 54 Mbps (802.11g) data rate, or up to a 600 Mbps (802.11n) data rate for example, or with products that contain both bands (dual band), so the networks can provide real-world performance similar to the basic 10BaseT wired Ethernet networks used in many offices.

Furthermore, the terms “user,” “consumer,” “client,” and the like are employed interchangeably throughout the subject specification, unless context warrants particular distinction(s) among the terms. It is noted that such terms can refer to human entities or automated components/devices supported through artificial intelligence (e.g., a capacity to make inference based on complex mathematical formalisms), which can provide simulated vision, sound recognition and so forth.

Artificial intelligence based systems, e.g., utilizing explicitly and/or implicitly trained classifiers, can be employed in connection with performing inference and/or probabilistic determinations and/or statistical-based determinations as in accordance with one or more aspects of the disclosed subject matter as described herein. For example, an artificial intelligence system can be used to dynamically perform operations as described herein.

In accordance with various aspects of the subject specification, artificial intelligence based systems, components, etc. can employ classifiers that are explicitly trained, e.g., via a generic training data, etc. as well as implicitly trained, e.g., via observing characteristics of communication equipment, e.g., a server, etc., receiving reports from such communication equipment, receiving operator preferences, receiving historical information, receiving extrinsic information, etc. For example, support vector machines can be configured via a learning or training phase within a classifier constructor and feature selection module. Thus, the classifier(s) can be used by an artificial intelligence system to automatically learn and perform a number of functions.