CN106462444A - Architecture and method for cloud provider selection and projection - Google Patents

Abstract

The invention relates to an architecture and method for cloud provider selection and projection. According to the invention, an architecture and method are provided for selecting and projecting a data center. For example, one embodiment of an apparatus comprises: a broker component to manage data center information, the broker component to receive updates containing the data center information and to respond to queries to provide the data center information; a selection engine to perform data center selections and/or recommendations for a cloud user based on data center information read from the broker component, wherein the data center selections and/or recommendations are made based on data center requirements and/or preferences specified by the end user; and a projection component to interface with a selected data center and transmit data to configure the data center on behalf of the user upon selection of the data center from the selections and/or recommendations made by the selection engine.

Description

Architecture and methodology for cloud provider selection and projection

Background technique

Cross References to Related Applications

This application claims the benefit of the following patent applications: U.S. Patent Application No. 14/588,613, filed January 2, 2015; U.S. Provisional Patent Application No. 61/924,122, filed January 6, 2014; U.S. Patent Application No. 14/588,620 filed on January 6, 2014; U.S. Provisional Patent Application No. 61/924,125 filed on January 6, 2014; U.S. Patent Application No. 14/588,626 filed on January 2, 2015; U.S. Provisional Patent Application No. 61/924,128 filed on January 6; U.S. Provisional Patent Application No. 14/588,631 filed on January 2, 2015; U.S. Provisional Patent Application No. 61/924,133 filed on January 6, 2014; U.S. Patent Application No. 14/588,658, filed January 2, 2015; U.S. Provisional Patent Application No. 61/924,137, filed January 6, 2014; U.S. Patent Application No. 14/ 588,607; and U.S. Provisional Patent Application No. 61/924,143, filed January 6, 2014, which are hereby incorporated by reference in their entirety.

technical field

The present invention relates generally to the field of data processing systems. More specifically, the present invention relates to systems and methods for cloud provider selection and projection.

Description of related fields

Cloud computing can be provided using infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), and software-as-a-service (SaaS) models. Either of these models can be implemented within a cloud-based "data center" composed of various computing resources (eg, servers, routers, load balancers, switches, etc.).

IaaS is the most basic model. IaaS providers provide physical computers or virtual computers (i.e., using virtual machines) and other resources such as virtual machine disk image libraries, storage resources (including file-based storage), firewalls, load balancers, IP addresses, virtual local area networks (VLANs) and software packages. IaaS providers can dynamically provision these resources from larger pools installed in data centers. To deploy their applications, cloud users install operating system images and application software on cloud resources. In this model, cloud subscribers maintain the operating system and application software. Typically, cloud providers bill users based on the amount of resources allocated and consumed.

In the PaaS model, a cloud provider delivers a complete computing platform, which typically includes an operating system, web server, programming language execution environment, and database. Application developers develop and run software solutions on this cloud platform without the cost and complexity associated with purchasing and managing the underlying hardware and software layers. In some PaaS implementations, underlying resources (eg, compute, storage, etc.) are automatically scaled to match application requirements, eliminating the need for cloud users to manually allocate resources.

In the SaaS model, the cloud provider installs and maintains application software in the cloud, and the cloud subscriber accesses the software from cloud clients (sometimes called the "software on demand" model). This simplifies maintenance and support by eliminating the need to install and run applications on cloud subscribers' own computers. Compared to locally executed applications, cloud applications offer virtually unlimited scalability by cloning tasks onto multiple virtual machines during runtime to meet changing work demands. The load balancer distributes the work across groups of virtual machines transparently to the user (the user only sees a single access point).

Description of drawings

The present invention can be better understood from the following detailed description in conjunction with the following drawings, wherein:

Figure 1A illustrates one embodiment of a cloud analysis and projection service;

Figure 1B illustrates details related to the cloud provider market;

Figure 2A shows a system architecture according to one embodiment of the present invention;

2B to 2C illustrate a method according to an embodiment of the present invention;

Figure 3 shows an illustration of data center arbitration (arbitrage) employed in one embodiment of the present invention;

Figure 4 shows an embodiment of a selection engine architecture;

Figures 5A-5D show additional details related to one embodiment of a virtualization and projection component including a graphical user interface;

Figure 6 illustrates multiple logical layers employed in one embodiment for projecting a virtual data center onto a physical data center;

Figure 7 shows additional details related to one embodiment of a global mediation;

Figure 8 shows an embodiment of a virtual data center overlay;

Figures 9 to 10 illustrate an embodiment of a distributed file system engine for migrating data centers;

11A-11B illustrate an embodiment of a shadow storage system for migrating data centers;

Figures 12A to 12C illustrate gateways and network infrastructure for migrating data centers in one embodiment of the present invention;

Figures 13A-13B illustrate an agent and data collection process according to one embodiment of the present invention;

Figure 14 shows additional details of one embodiment of the global broker and communication with the selection engine.

detailed description

Embodiments of apparatuses, methods, and machine-readable media for cloud service selection and projection are described below. Throughout the description, for purposes of explanation, numerous specific details are set forth herein in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are not shown or are shown in block diagram form in order to avoid obscuring the underlying principles of the invention.

Embodiments of the invention described herein take advantage of a growing number of cloud service providers for those migrating to the cloud. In particular, these embodiments include mechanisms for managing and moving data centers independently of the cloud service provider that actually provides the cloud footprint. In one embodiment, the cloud footprint is an IaaS footprint; however, the underlying principles of the present invention can also be implemented throughout a data center offering PaaS services or SaaS services.

FIG. 1A shows a high-level architecture of a Cloud Analysis and Projection Service (CAPS) 100 according to one embodiment of the present invention. As described in detail below, CAPS 100 is capable of implementing several powerful models, including the ability to arbitrate a wide variety of data centers offered by cloud providers 121-124 in order to create optimal prices, performance, availability and/or geographic scope. In particular, one embodiment of CAPS 100 evaluates cost data, resource data, performance data, geographic extent data, reliability data, and/or any other relevant cloud provider variables according to requirements specified by cloud subscribers 111-115. for analysis. Once the relevant data has been evaluated, the CAPS 100 automatically selects one or more cloud providers for the cloud subscriber. Alternatively or in addition, CAPS 100 may exploit measurable differences between cloud providers by performing cloud arbitration (e.g., once an imbalance occurs between cloud providers, including in cloud provider pricing, performance , service level agreement, or other measurable metric that differs (i.e. capitalized) from matching transactions) to recommend a set of "candidate" cloud providers. The end user can then choose among the recommended cloud provider candidates.

As discussed in detail below, one embodiment of the CAPS 100 includes virtualization and projection logic to virtualize data center resources and enable data center migration ( See, for example, the virtualization and projection component 231 shown in Figure 2A). Specifically, one embodiment of CAPS 100 generates a virtualized or logical representation of all data center resources including, but not limited to, routers, switches, load balancers, WAN accelerators, firewalls, VPN concentrators, DNS/DHCP servers, workloads/virtual machines, file systems, network attached storage systems, object storage, and backup storage, to name a few. This "virtual data center" representation reflects the atomic components comprising the data center and manages the basic debug state of each logical device. The CAPS 100 then implements the virtualized data center by converting the virtualized representation into the format required to implement the physical data center, or by executing the virtual data center directly on the cloud provider (e.g., using a fully virtualized implementation, as described below in conjunction with FIG. 9 ) to project the virtual data center onto the new physical data center.

There are thousands of small cloud service providers who are just as capable of delivering IaaS to their customers as the large providers, but these small providers are considered fragmented or regional. Consider the diagram shown in Figure 1B, which shows the current major North American cloud service providers. Note the log reduction in market share. Through the long tail of the solicitation curve, CAPS100 becomes a "market maker" for aggregated data center services. In one embodiment, CAPS 100 employs an intermediary model for buying and selling these data center services, ie, arranging a transaction between a buyer and a seller, and receiving a commission when the transaction is executed. This is beneficial to both cloud subscribers 111-115 and cloud providers 121-124 as it enables movement through fragmented markets and creates aggregated markets without mere acquisitions.

Cloud sellers 121-124 may base their data on cost and other variables such as duration (specific cost for a limited time period), service level agreement, geographic location, network resources (for some distributed applications) and/or dedicated to certain applications The hardware resources of the program are quoted to the CAPS platform 100 . This data can be further augmented with historical records from past customer transactions (eg, using customer feedback or other rating systems). The concept of "arbitration" is thus expanded to match cloud buyer requirements with a larger list of cloud seller characteristics. A simple example is price and duration. A seller may only have capacity at a certain discounted rate for a certain duration (eg, because another customer booked that capacity at a given time in the future). This may work for some buyers with more mobile data center architectures, or only short-term needs for their data centers. Overall, however, with the law of large numbers in effect, there may be an increasing likelihood that the CAPS 100 will find a buyer for each seller, making both profitable.

As shown in FIG. 2A, one embodiment of the CAPS 100 includes a number of components including a global broker 210, a set of user choice engines 220-222 (e.g., one user choice engine per cloud user), and a virtualization and projection assembly 231. The global broker 210 manages the database 211 of all available cloud providers 121 to 124, and the properties of the data centers provided by the cloud providers. By way of example, database 211 may include cost data, resource data, performance data, geographic extent data, reliability data, and/or any other relevant information related to the data centers operated by cloud providers 121-124. Database 211 may be dynamically updated by cloud providers 121 - 124 themselves or statically by members of CAPS 100 . For example, if a particular cloud provider has changed its cost structure for data center resources for a particular duration, that cloud provider may update the cost/duration in database 211 with the change. Similarly, if the cloud provider has upgraded its hardware/software, or opened a new data center in a new location, the cloud provider can update the database 211 to reflect these changes.

In one embodiment, global broker 210 exposes an application programming interface (API) to enable updates to database 211 . The cloud providers 121-124 can then utilize the API to dynamically update the database 211. This can be achieved, for example, via CAPS software installed at each of the cloud providers 121-124, and/or via a web server accessible by a browser client at the cloud provider. Static provider updates are also possible via the API.

In one embodiment, user selection engines 220-222 are implemented to make data center selection/recommendations for each cloud user. In the example shown in FIG. 2A, selection engine 220 is executed to implement user A's data center selection/recommendation; selection engine 221 is executed to implement user B's data center selection/recommendation; Center selection/recommendation. In operation, each selection engine 220-222 is provided with the data center requirements (e.g., cost, performance, reliability, geographic location, etc.) of a corresponding cloud user and then identifies candidate cloud offerings matching those requirements from the intermediary database. business.

As discussed in more detail below, each selection engine 220-222 may generate a prioritized list of cloud providers 121-124 that match the user's requirements (e.g., cloud providers at the top of the list are more preferred than cloud providers at the bottom of the list). more closely match these requirements). This list is available as a set of cloud provider "recommendations" and is presented to end users along with a comparative analysis explaining the reasons for those recommendations. Alternatively, in one embodiment, the selection engine may automatically select one of the cloud providers for the user (and, as discussed below, migrate between data centers).

In one embodiment, the selection engines 220-222 periodically and/or automatically receive updates from the global brokerage database 211 to give new data center selections and/or recommendations. For example, if a particular cloud provider 121-124 has significantly reduced its cost of service, this may cause the selection engine to select that cloud provider and/or place that cloud provider at the top of the priority list (thus enabling migration to This new cloud provider makes sense). The frequency with which the selection engine receives updates and generates the data center priority list may vary depending on the implementation of CAPS 100 and/or the preferences of each cloud subscriber.

FIG. 4 shows additional details related to selection engine 220, which includes data center prioritization logic 420 for sending a query to intermediary 210 indicating data center requirements (e.g., determined by user request/preference 425). For example, data center prioritization logic 420 may send a query based on user input 425 specifying that it is only interested in data centers located within a particular geographic area and having certain capabilities (eg, load balancing, automatic failover capabilities). Therefore, the candidate data centers provided by the broker 210 will be limited to those with the required parameters.

As noted in FIG. 4 , data center prioritization logic 420 can then prioritize candidate data centers based on various weighting components, including arbitration component 401 , performance component 402 , and reliability component 403 . Although only three components are shown in FIG. 3 , various other/additional components may be included in the data center prioritization logic 420 while still adhering to the underlying principles of the invention (e.g., such as geographic location, end-user data center rating, etc.).

In one embodiment, weights are assigned to each component 401 - 403 based on user-specified requirements/preferences 425 . For example, if a particular cloud subscriber is primarily interested in low-cost data center services, then the arbitration component 401 may be weighted more heavily than the performance component 402 and the availability component 403 . Another cloud subscriber may also be interested in low cost, but may specify minimum requirements for performance component 402 and/or reliability component 403 . In this case, the data center prioritization logic 420 will filter out those data centers that do not meet the minimum requirements, and then prioritize the remaining candidate data centers based on cost. Yet another cloud user may be primarily concerned with the data center reliability component 403 , and thus the reliability component 403 may be weighted more heavily than the arbitration component 401 or the performance component 402 . Various/additional algorithms may be implemented by data center prioritization logic 420 to generate preferences or recommendations 410 based on relative component weights.

Returning to Figure 2A, once a new cloud provider is selected, the virtualization and projection component 231 manages the migration of the data center to the new cloud provider. As noted above, one embodiment of the virtualization and projection component 231 maintains a "virtual data center" representation of the data center resources required by each cloud subscriber, such as routers, switches, load balancers, WAN accelerators, firewalls, VPN centralized servers, DNS/DHCP servers, workloads/virtual machines, file systems, network-attached storage systems, object storage, and backup storage, to name a few. This "virtual data center" representation reflects the atomic components comprising the data center and manages the basic commissioning state of each logical device (eg, each device's user-specific configuration). In one embodiment, the virtualization and projection component 231 maintains its own database 232 for all data needed to manage/migrate each virtual data center. Alternatively, virtualization and projection component 231 may rely on global mediation database 211 to store this data.

Once a new data center is selected, the virtualization and projection component 231 projects the virtual data center onto the new data center. As mentioned above, projection to a new data center may involve (e.g. based on specific hardware/software resources of the cloud provider) or by directly executing a virtual data center on the cloud provider (e.g. using a fully virtualized implementation, As discussed below in conjunction with FIG. 9 ), the virtualized representation is transformed into the format required to implement the physical data center. Once the projection is complete, the old data center can be shut down.

Figure 2B shows an embodiment of a method for selecting a new data center based on user-specified data center specifications and requirements; Figure 2C shows a method for migrating from one data center to another An example of the method.

Turning first to Figure 2B, at 250, the user enters the specifications of the data center. As used herein, "Specifications" include specific components and architectures of data centers including, for example, routers, switches, load balancers, WAN accelerators, firewalls, VPN concentrators, DNS/DHCP servers, workloads/virtual machines, file systems, The arrangement of network-attached storage systems, object storage, and backup storage. In one embodiment, the virtualization and projection component 231 may provide a user with a graphical user interface (GUI) for graphically selecting data center components and interconnections between them (see, e.g., FIG. 8 and related text). The GUI can be web-based (eg, provided through a web page accessible via a browser), or can be implemented as a stand-alone application. In one embodiment, the virtualization and projection component 231 determines data center specifications by asking the cloud subscriber a series of questions related to the data center architecture. Alternatively or in addition, the virtualization and projection component 231 can provide the user with a set of pre-built data center templates from which to select based on the user's data center requirements. Each template can be associated with a certain set of required resources and/or have specific parameters associated therewith.

Regardless of how the user enters data center specifications, at 251 the virtualization and projection component uses these specifications to build a virtual data center representation. As noted above, in one embodiment, the virtual representation includes an abstract representation of all desired data center resources and structural layout (eg, interconnections between resources). The virtual representation reflects the atomic components comprising the data center and manages the basic debug state of each logical device.

At 252, the user indicates various factors to be considered for prioritizing candidate data centers. As noted above, this may involve associating weights with variables, such as data center costs, performance data, and/or reliability data, based on the user's preferences/requirements. At 253, a set of candidate data centers is identified based on the specifications and requirements. For example, as previously discussed, if a particular cloud user is primarily interested in low-cost data center services, then the cost variable may be weighted more heavily than the performance and availability variables. Various different prioritization algorithms can be implemented to generate preferences or recommendations based on relative component weights.

At 254, a data center is selected from the identified candidate data centers. In one embodiment, the selection is made by the cloud user (eg, after viewing a prioritized list of candidates). In another embodiment, this selection is performed automatically for the cloud subscriber.

Regardless of the data center selection, at 255 the virtual data center is projected onto the selected physical data center. As mentioned above, projection to a new data center may involve (e.g. based on specific hardware/software resources of the cloud provider) or by directly executing a virtual data center on the cloud provider (e.g. using a fully virtualized implementation, As discussed below in conjunction with FIG. 9 ), the virtualized representation is transformed into the format required to implement the physical data center. Once the projection is complete, the data center can be brought online.

Figure 2C illustrates one embodiment of a method of migrating an existing data center to a new data center. At 260, a data center update is received and evaluated, and at 261, a decision is made whether migration to a new data center is justified (eg, based on price, performance, and/or reliability considerations). As mentioned, global broker 210 may receive continuous dynamic updates from cloud providers 121-124, and/or may be statically updated (ie, by members of CAPS 100). As these updates are stored in the global broker 210, each selection engine 220-222 can execute its selection policy to determine whether migration to a new data center would be beneficial to the end user. For example, a decision to migrate may be based on changes in the current data center and/or other candidate data centers (e.g., changes in cost, SLA, data center tier other than cost, time of day, performance for restricted time periods, availability, etc.) made.

FIG. 3 illustrates one embodiment of a decision process for selecting a new data center in a graphical depiction. As shown, a migration event 370 may be generated upon detection that the costs associated with the current data center have fallen outside of tolerance (eg, as indicated by cost arbitration block 371 ). The event can be a scheduled event (e.g., the cloud provider can provide advance notice of cost changes), in which case the selection engine can employ a scheduler to trigger migration events to occur at specific points in time (e.g., costs are expected to exceed point in time for the target range) to move the data center. As shown in block 372, the global broker may be continuously updated via projection feeds with data pertaining to all monitored data centers. All monitored data center groups are filtered by a selection engine based on filter criteria such as cost, performance, location and/or availability to arrive at a set of candidate data center projections. A particular data center is then selected from the set of candidates based on "events" such as the failure of the current projection to fall within tolerance, a rise in the difference between the candidate projection and the current projection above a threshold, and/or filtering Standards change. The end result is that events are triggered (either automatically or manually by the cloud user) to migrate the data center.

Returning to FIG. 2C, at 262, a new data center is selected from the set of candidates, and at 263, a virtual data center is projected onto the newly selected data center (e.g., using various projection techniques described herein) .

As shown in Figures 5A-5D, one embodiment includes a graphical user interface and a command line interface for creating and managing virtual data centers. In one embodiment, the virtual controllers employed in the virtual data center are each represented by a unique graphic. Figure 5A shows a specific set of graphs used to represent virtual controllers, including: Virtual Data Center graph 501, Gateway graph 502, Network Router graph 503, Network Switch graph 504, Firewall graph 505, Load Balancer graph 506, WAN Acceleration Graph 507, Workload/Virtual Machine Graph 508, DNS Server Graph 509, File System Graph 510, DHCP Server Graph 511, Backup Storage Graph 512, Network Attached Storage Graph 513, VPN Concentrator Graph 514, and Object Storage Graph 515 .

A brief description of each of the virtual controllers represented by these graphical images is given below. In one embodiment, access to the underlying resources is provided via a management interface exposed through the virtualization and projection component 221 .

Virtual Data Center 501 is a program that captures projected high-level attributes such as geographic location, SLA, tier, and the like. This is a non-operational object used to group geographically distinct datacenters at the top level. Attributes of a virtual data center may include location, service level agreement, data center tier, pricing classification.

Gateway router 502 is responsible for public routing on the Internet. Attributes include WAN configuration, routing entries, routing protocols, interface monitoring, DNS properties, topology information/routing information, and affinity rules.

The network router 503 is responsible for routing between all sub-networks within the virtual data center. Multiple network routers can be instantiated with different interfaces connected to different subnets, much like a real router. Attributes can include network configuration, routing entries, routing protocols, interface monitoring, and affinity rules.

The network switch 504 embodies the concept of a subnet. Interfaces that connect different devices to each other within a sub-network are modeled by this entity. With telemetry collected for each connected device, a network switch can be a managed entity that identifies data center usage and its cost and performance. Properties can include network configuration, monitoring, and affinity rules.

Firewall 505 is a feature typically provided by cloud providers, but can also be an additional feature provided by CAPS 100 (either directly or through the App Store concept). A firewall can provide a range of potential contributions including, but not limited to, Network Address Translation (NAT), Distributed Denial of Service (DDOS) protection, and traffic monitoring. Attributes can include network configuration, firewall policies, monitoring policies, and affinity rules.

Load balancer 506 is a device for mapping multiple identical workloads together for scale-out purposes. Attributes can include network configuration, addressable end stations, balancing policies, monitoring, and affinity rules.

WAN Accelerator 507 is a service that can be used to interconnect data centers over a WAN. The building blocks may include appliances such as Riverbed that provide deduplication compression algorithms. These services can be provided by cloud providers to cloud subscribers in the form of virtual workloads. Between two or more virtual data centers, instances of WAN accelerators (one per site) can be used to compress data traveling across the WAN. Attributes can include network configuration, endpoint configuration, SLAs, basic user privileges, monitoring, and affinity rules.

Workloads/virtual machines 508 maintain a common configuration of OS images. For various VM formats such as VMDK, ISO, its main responsibility is to deliver these images. By maintaining these images at all times, the migration process is greatly simplified. Attributes may include CPU class and quantity, memory, local storage, operating system image, network configuration, and affinity rules.

The DNS server 509 provides a method for the virtual data center to name both the inside and outside of the IaaS data center. This DNS server should be connected to the managed IaaS service provider's naming service and the Siaras global directory/broker. Attributes can include domain names, addressing, migration characteristics, monitoring, and affinity rules.

File system 510 may be associated with network attached storage (NAS). This file system can be a shared resource, but can have some associated privileges, either through addressability, or potentially user-based privileges. A core feature of the migration component of the file system includes data migration. In one embodiment, the virtual controller supports the ability to transfer data from one file system instance to another file system instance. Migration can be coordinated at a higher layer than the virtual file system controller, but the controller should at least provide "Sink" and "Source" mechanisms for migration. As discussed in more detail below, in one embodiment, a distributed file system (eg, Hadoop) that does not require manual transfer of data is used. Each instance of the file system automatically binds to an existing node and downloads the necessary local data. Attributes of a file system can include size, network configuration, SLAs, basic user privileges, backup policies, and affinity rules.

The DHCP server 511 allows the data center provider to define addressing schemes and ACLs, and other controls over devices within the logical data center. Properties can include subnetwork configuration, monitoring, and affinity rules.

Backup storage 512 is a core attribute of any high availability application, and may be an attributed feature of the local IaaS service provider, or may be a value-added feature of CAPS. In the latter case, the issue is the amount of data transferred out of the physical data center, and the costs associated with it.

Network attached storage 513 can be a high performance storage method that can be used in a tier 1 IaaS cloud data center or in a dedicated data center. These controllers are used to manage these resources. Attributes can include LUNs and sizes, RAID policies, network configuration, SLAs, basic user privileges, backup policies, and affinity rules.

VPN concentrator 514 is the end station that remote clients will use to connect to the data center. VDI applications and other essential secure connections will utilize a VPN concentrator or be used as a simple secure VPN endpoint. Attributes can include network configuration, firewall policies, monitoring policies, and affinity rules.

IaaS cloud providers may offer object storage capabilities represented by object storage graph 515 . Optimally, the object storage virtual controller will provide a transformation function to map one object storage facility to another object storage facility. The responsibility of the end application may be to leverage a cloud PaaS abstraction solution such as Chef or Cloud Foundry to handle API changes. In one embodiment, the role of CAPS is to ensure that the move is efficiently made and the data is available for continued processing by the new project. Attributes can include size, network configuration, SLAs, basic user privileges, backup policies, and affinity rules.

FIG. 5B shows an exemplary series of commands 510 that may be executed by virtualization and projection component 221 (eg, via a command line accessible to an exposed management interface) to build a virtual data center. While a command line interface is shown for purposes of explanation, the same set of commands may be executed in response to a user manipulating elements within a graphical user interface (eg, as shown in FIGS. 5C-5D ). In this example, the "Create Data Center 'Bob'" command creates a virtual controller for a data center named 'Bob' (represented by graph 501). The command "create subnet 'main' 192.168.1.0/24 on 'Bob'" creates network switch virtual controller 504 under virtual data center 'Bob', and another set of "create" commands creates gateway under network switch 504 A virtual controller 502 , a file system virtual controller 510 and two virtual machine controllers 508 . The resulting virtual data center is then projected to data center 520 via the "project" command. As described in this article, a variety of different techniques can be employed to project a virtual data center onto a physical data center. After the virtual data center has been successfully projected, a "move" command may be executed to migrate the virtual data center to a new physical data center 521 .

Figure 5C illustrates an exemplary graphical user interface (GUI) "dashboard" for creating and managing virtual data centers. A network topology of two data centers (data center A 553 and data center B 554 ) coupled together via a WAN accelerator is shown within the GUI window 551 . In one embodiment, a user can create, edit, and delete virtual controllers within the displayed network topology by selecting and dragging primitives representing virtual controllers. For example, virtual controller elements displayed within area 550 of the GUI can be selected and configuration data associated with each of these elements can be edited. Alternatively, the user may directly select a virtual controller from the GUI window 551 to edit variables associated with the controller.

A site status window 552 is also shown to provide data related to arbitration (eg, data center costs), performance, and reliability. Under the graphical arbitration element, users can access a variety of cost information, including maximum specified costs, target costs, and current costs associated with the usage of each data center. Additionally, under the graphical arbitration element, the user can specify triggers and actions (referred to as "events" in Figure 2D) in response to changes in cost values. For example, a user may specify that migration should occur if the cost value rises above a certain threshold.

Under the graphical performance element, users can view current performance measurements, including network performance, CPU performance, and storage performance. A user may also specify triggers and actions in response to changes in performance values. For example, a user may specify that if the performance of any particular variable drops below a specified threshold, the data center should be relocated.

Below the graphical fault management element, the user can access various fault/reliability data, including different types of system alarms (eg, major, major, minor, etc.). Again, the user can specify triggers and actions in response to changes in reliability. For example, a user may specify that if the number of critical or major alarms rises above a specified threshold, the data center should be relocated.

In one embodiment, the management GUI shown in Figure 5C provides the following functions/features:

Distributed data centers should be visible within their respective geographic locations;

The active item shows which IaaS service provider is providing the service;

Ability to define policies that should project virtual data centers, including policies based on location, cost, time, performance, SLA, tier, replication;

Alternative data centers (monitored sites) should be visible to end users;

The ability to clearly see where there is a problem, including performance issues, cost issues, and availability issues (for example, an IaaS provider, which is offering a limited amount of time on its assets, may have a countdown timer);

Plan moves in advance and possibly monitor the ability of resources to remain available at the destination location;

Ability to clearly see costs within different data center instances and how costs are within a given data center (e.g. hourly reporting mechanisms can be maintained for facility financial forensics at the end of the month, quarter or year); and/ or

The ability to configure policies for data center mobility. This may include alert notifications requiring manual intervention, and the ability to schedule migrations based on pre-determined maintenance windows (eg, move at 2am the next morning if an arbitration event occurs). A special case might be to move immediately if an existing projection dies due to a failure within the data center.

Figure 5D shows the hierarchical virtual controller arrangement shown within window 551 in more detail. As mentioned, a user can design a virtual data center simply by selecting and dragging the graphical elements representing each of the virtual controllers 560-599. In the specific topology shown in FIG. 5D , gateway 560 is associated with data center A, and gateway 561 is associated with data center B. Network router 563, firewall 562 and WAN accelerator 564 are logically located directly under gateway 560, while another network router 582, firewall 583 and WAN accelerator 581 are located directly under gateway 561 in a hierarchical arrangement. As shown, a dedicated WAN interconnect communicatively coupling the two WAN accelerators 564 and 581 may be used to ensure redundancy and/or failover between the two data centers. In one embodiment, as discussed below, the WAN interconnect can be used to simplify the migration process (ie, when migrating a virtual data center to a new physical data center).

The first set of network switches 565-567 are logically located under the network router 563 in data center A, and the second set of network switches 584-586 are logically located under the network router 582 in data center B. A switch 565 couples a set of Apache servers to a local network consisting of a load balancer 568 , a set of workload/VM units 569 to 571 (for performing processing tasks) and a file system 572 . Switch 566 couples a second set of workload/VM units 573-576 to implement a cache memory subsystem (“Memcache”), while switch 567 couples another set of workload/VM units 577-579 to object memory 580. Connect to implement the database.

In the example shown in FIG. 5D , a mirrored set of components is configured in data center B. In the example shown in FIG. For example, a switch 584 couples a set of Apache servers to a local network consisting of a load balancer 587 , a set of workload/VM units 588 to 590 (for performing processing tasks), and a file system 591 . Switch 585 couples a second set of workload/VM units 592-595 to implement a cache memory subsystem ("Memcache"), and switch 586 couples another set of workload/VM units 596-598 and object memory 599 to implement the database.

In one embodiment, additional data center elements, such as processing resources, network resources, and storage resources, can be added simply by clicking and dragging virtual controllers within the illustrated hierarchical architecture. For example, additional workload/VM controllers can be added under each respective switch to increase processing power. Similarly, additional switches can be added under the routers 563, 582 to add new subsystems to the data center topology.

In some of the embodiments described below, file systems 572 and 591 are distributed file systems with a built-in ability to maintain synchronization between two data centers across a WAN interconnect (eg, as Hadoop).

As a specific example using the architecture shown in FIG. 5D , web services may be provided by groups of Apache servers that are load balanced by load balancing means 568 , 587 . These can be within a single subnetwork. Memcache servers may form a second sub-network to maintain active caches of their respective databases. Groups of database servers 577-579, 596-598 each operate from a common data store 580,599.

In operation, when a URL request enters the data center through the gateway 560, 561, the URL request is screened by the firewall 562, 583 and then forwarded to the load balancer 568, 587, which redirects the request to Apache one of the servers. In this case, the number of servers can be increased automatically under heavy load conditions. For example, servers can be scoped, and triggers can be used to expand and contract those server pools. What is unique here is that the architecture shown is an actual logical data center that is orthogonal to any given cloud provider service, making it lightweight in nature.

Going back to the previous example, once the URL is processed, the active Apache server forwards the request to the Memcache server. If there is a page rewrite flag in Memcache (eg, data expires), then in one embodiment, Memcache will respond immediately (eg, within 200ms) to expired data instead of waiting for several seconds to refresh. When an event occurs, Memcache will trigger a database query from the next set of servers. When doing this, end users typically get the latest data when they hit refresh on their browser. In other words, leaving it up to the end user to re-request the data will give Memcache the necessary time to update "behind the scenes".

FIG. 6 illustrates the various layers used in one embodiment of the virtualization and projection logic 221 to project a virtual data center to a cloud provider. Specifically, the abstract virtual data center representation 601 may be constructed using the GUIs shown in FIGS. 5A-5D and/or via a third-party user interface 602 (eg, using a GUI designed by a third party). In one embodiment, each object from abstract GUI layer 601 (eg, graphical objects 560 through 599 shown in FIG. 5D ) maps to a specific controller within virtual device controller layer 603 . Each virtual device controller includes a virtual data structure that includes the data needed to implement hardware infrastructure (eg, routers, switches, gateways, etc.), and interfaces that enable access to the data. For example, the interface may be implemented using Representational State Transfer (REST) or any other interface model.

The resulting set of virtual device controllers 603 can be mapped to corresponding physical devices within the projected data center 605 via a cloud mediation layer 604, which can use cloud APIs (e.g., JClouds) to accomplish. In one embodiment, a separate "plug-in" module is provided to map and/or translate the virtual appliance controller representation into a format that can be implemented on resources provided by the cloud provider. Thus, in FIG. 6 , plugin A is used to map and/or translate the virtual data center representation to cloud provider A, and plugin B can be used to translate and project the virtual data center representation to cloud provider B. Therefore, when a new data center registers its services with the broker 210, the underlying virtual data center representation does not need to be modified. Instead, new plug-ins are only required to map and/or convert existing virtual data centers to new physical data centers. These plug-ins can be implemented within the cloud provider premises (eg, on the cloud provider LAN) and/or on servers at the CAPS 100 .

FIG. 7 shows additional details related to one embodiment of the global broker 210 . As noted above, the global broker 210 includes a data center database 211 that contains data related to each provider, including but not limited to resource data (e.g., specifying the types of processing platforms, network platforms, storage platforms available) ), performance data (e.g., measured based on latency associated with processing tasks or network communication tasks), cost (e.g., expressed in dollars per day or other unit of use), geographic data (e.g., indicating geographic location), and reliability data (eg, based on the average number of critical alarms over a certain time period).

In one embodiment, multiple application programming interfaces (APIs) are exposed to provide access to the data center database 211, including a cloud provider interface 701, a cloud user interface 702, a configuration interface 703, and a management interface 704 . In one embodiment, each interface includes a set of commands for performing operations on the database (eg, create records, delete records, modify records, etc.). The cloud provider can access the data center database 211 via the cloud provider interface 701 , the cloud subscriber can access the data center database via the cloud user interface 702 , database configuration is done via the configuration interface 703 , and management operations are provided via the management interface 704 . In addition, a message bus 705 is provided that allows all cloud users to maintain an up-to-date view of available resources (eg, by providing data center results to a queue (discussed below) that cloud users listen to).

In one embodiment, the management interface 704 is used by the CAPS 100 to perform any and all grooming functions required for the continued performance of the system. Functionality that may be supported by the management interface includes the ability to:

View and modify data related to active buyers and sellers;

Provide access control lists (ACLs) that restrict access for buyers and sellers;

monitoring the throughput of the message bus 705;

Enable or disable other computing elements and storage elements to handle different loads;

Manage SaaS-based Data Center Manager clients;

Access to low-level command-line debugging and diagnostic tools;

Shut down the system and prepare to move to a new data center;

View all running instances of the system, including those running in multiple data centers;

manage failover solutions; and/or

Clients are statically managed for debugging purposes.

In one embodiment, configuration interface 703 allows CAPS 100 to provide updates to data center database 211 (e.g., adding new entries for vetted data centers and/or partner data centers, and removing data center as needed). In the non-partner category (eg, an IaaS provider that is not actively aware that CAPS 100 is utilizing its resources), it is up to CAPS 100 to provide updates to data center database 211 when changes occur.

In one embodiment, provisioning techniques such as data center "zones" (as used by Amazon) are made opaque to cloud users. For example, regions can simply be identified as different data centers. Thus, one virtual data center may be used in one region of one cloud provider (eg, Amazon) and one virtual data center may be used in a different cloud provider (eg, Rackspace). A corollary of this is that cloud subscribers can specify that they want a single provider and different sites/regions (eg, using affinity rules indicating the affinity of certain sites).

In one embodiment, the functionality included in configuration interface 703 includes the ability to:

Add/delete/view IaaS data center (seller) records;

Update static/dynamic seller records;

Force push records to buyers;

Create a new buyer and optionally create the associated SaaS infrastructure (using the Siaras template); and/or

View statistical reports related to registered buyers and sellers.

In one embodiment, the cloud provider interface 701 is open to cloud providers who want to publish details of available services. APIs can be connected to SaaS portals for manual entry and opening, from M2M integration with automation systems. Functionality of this interface may include the ability to add/delete/view/update cloud provider records.

In one embodiment, cloud subscriber management interface 704 is exposed to cloud subscribers running managed virtual data centers. These systems can run in the cloud itself (as SaaS) or as enterprise applications. The purpose of this interface is to provide methods for managed virtual data centers to report on the current execution history of the virtual data center. The interface can be implemented as a closed system that can only be activated through management software provided by CAPS 100 to the cloud subscriber (ie, the interface cannot be directly accessed by customers). In one embodiment, the functionality included in the cloud user interface includes the ability to:

Report updates on observed virtual data center performance;

Report any disruptions observed by a particular service provider;

report any failures to configure within the virtual data center (for example, incompatibility between intermediary systems or lack of reported functionality or available resources); and/or

Provide customer satisfaction reporting methods and fault reporting mechanisms.

In one embodiment, a global intermediary is responsible for DNS entry redirection for cloud users. This way, data center migrations can be updated immediately. Additionally, one embodiment of the global broker 210 is designed to support extensions. Specifically, any interface that requires multiple clients supports a scale-out architecture.

As described above, the virtualization and projection component 221 can be implemented by converting the virtualized representation into the format required to implement the physical data center (ie, a plug-in that converts the abstract data into a format usable by the physical resources of the data center), or by directly Implement a virtual data center on the cloud provider to project the virtual data center onto the physical data center.

Figure 8 illustrates the latter case, utilizing a fully virtualized implementation comprising a virtual data center overlay 800 over a number of virtual machines 821-826 provided by a common cloud provider 830 run. Thus, this embodiment includes a fully re-virtualized cloud layer where each component 801-806 of the virtual data center 800 can be projected onto any cloud provider (from the most general to the most complex) . In the particular example shown in FIG. 8 , each component runs on a different VM exposed by a generic cloud provider 830 . Specifically, virtual gateway 801 runs on VM821. Three different kernel VMs 802, 804, 805 (including virtual kernels) run on VMs 822, 824, 825 respectively. As shown, operating system or other software images 811, 812, and 813 may execute on top of kernel VMs 802, 804, 805, respectively. Virtual switch 803 runs on VM 823 and virtual file system 806 runs on VM 826 .

As shown in FIG. 8, each of the virtual components 801-806 forming the virtual data center 800 may use Layer 2 Tunneling Protocol (L2TP) tunneling, Secure Sockets Layer (SSL) tunneling, or another secure inter-process protocol to communicate, creating a secure tunnel between components. Additionally, as shown, virtual gateway 801 communicatively couples other components 802-806 to a public network via a public IP interface provided by VM 821.

There are several benefits to using a virtual data center overlay. First, since no translation is required, virtual data center overlays can be seamlessly deployed on any physical data center that can provide consistent VMs. A more even distribution of SLAs and security can be imposed across all tiers of data center services. Additionally, greater control and visibility of the actual data center may be provided, and thus in a more uniform manner over time. For example, each entity (eg, vGateway, KVM, vSwitch, vFileSystem, etc.) may include an agent to continuously measure performance and cost.

As noted above, the file systems 510, 572, 591 implemented in one embodiment of the present invention are distributed file systems with built-in features for maintaining synchronization between two (or more) data centers interconnected by a WAN. ability. Figure 9 shows one such embodiment comprising a first virtual data center 910 utilizing a file system 920 on a cloud provider 900 and a second virtual data center utilizing an associated file system 930 on a cloud provider 901 Center 911. Each of the file systems 920 and 930 includes a distributed file system engine 923 and 933, respectively, for synchronizing the local portion 921 of the file system 920 with the remote portion 932 of the file system 930, and Used to synchronize the local part 931 of the file system 930 with the remote part 922 of the file system 920 . After synchronization is achieved, any changes made to the local portion 921 of the file system 920 are automatically reflected in the remote portion 932 of the file system 930, and any changes made to the local portion 931 of the file system 930 are automatically reflected in the remote portion 922 of the file system 920. automatically reflected. In one embodiment, "local" components 921 , 931 of a file system are those components that are created, edited, and/or otherwise accessed locally by the corresponding virtual datacenter 910 , 911 . In contrast, "remote" components are those components that are created, edited, and/or otherwise accessed by a different virtual datacenter 910, 911.

In one embodiment, the distributed file system engine 923, 933 is a Hadoop distributed file system (HDFS) engine, and the local part and the remote part are implemented as Hadoop nodes. HDFS is a distributed scalable portable file system that stores large files on multiple machines and achieves reliability by replicating data across multiple hosts. Therefore, Hadoop instances do not require RSID storage on the host. Data nodes can talk to each other to rebalance data, move replicas, and maintain highly replicated data. In the embodiment shown in FIG. 9, the Hadoop protocol may be used to synchronize the local portions 921 and 931 of the file systems 920, 930 with the remote portions 932 and 922, respectively. It should be noted, however, that the underlying principles of the invention are not limited to any particular distributed file system protocol.

In one embodiment of the invention, a distributed file system (such as that described above) is used to simplify the data center migration process. For example, as shown in Figure 10, if a user chooses to migrate from cloud provider 900 to a new cloud provider 902, then once the new projection is complete (e.g., using the virtual data center techniques described herein), the distributed file system 943 to populate the underlying file system 940 of the virtual data center 912. For example, in FIG. 10 , local portion 941 of file system 940 may be populated from remote portion 932 of existing file system 930 of cloud provider 901 . Similarly, remote portion 942 of file system 940 may be populated from local portion 931 of existing file system 930 of cloud provider 901 . In one embodiment, the entire contents of the local portion 941 and the remote portion 942 of the file system 940 need not be fully populated prior to bringing the cloud provider 902 online. Instead, local distributed file system nodes 941 and remote distributed file system nodes 942 may be created and populated during runtime (after virtual data center 912 is brought online). When a request for data (not locally available) is received at local node 941 or remote node 942, the data can be retrieved from remote node 932 or 931 respectively, thereby populating local node 941 and remote node 942 during runtime. Thus, virtual data center 912 can be enabled to start up more efficiently on cloud provider 902 than in previous implementations (where all data of file system 940 was required ahead of time).

FIG. 11A shows another embodiment that includes a cloud provider 1100 running a virtual data center 1110 coupled to a file system 1120 managed by a distributed file system engine 1130 (as in the previous embodiment). as in). In this embodiment, the shadow storage system 1101 is used to store the shadow copy 1121 of the virtual data center file system 1120 . The distributed file system engine 1131 communicatively coupled to the distributed file system engine 1130 of the virtual data center is configured to maintain a synchronized shadow copy 1121 of the file system 1120 . In one embodiment, when changes are made to the local file system 1120, the distributed file system engines 1130-1131 coordinate to reflect those changes in the shadow file system 1121. The difference in this embodiment is that the shadow storage 1101 itself is not a data center accessible by end users. Instead, this shadow memory is only used for shadow storage.

In one embodiment, shadow storage system 1101 is used to simplify the data center migration process. For example, as shown in Figure 11B, if a user chooses to migrate from cloud provider 1100 to a new cloud provider 1102, then once the new projection is complete (e.g., using the virtual data center techniques described herein), the distributed file The protocol of the system engine 1132 to populate the underlying file system 1122 of the virtual data center 1111. For example, in FIG. 11B , file system 1122 may be populated from a shadow copy of file system 1121 stored on shadow storage system 1101 .

As in the above-described embodiments, the file system 1122 does not need to be completely populated with the entire content of the file system 1121 before the cloud provider 1102 is brought online. Instead, distributed file system nodes 1122 may be created and populated during runtime (after virtual data center 1111 is brought online). When a request for data (not locally available) is received at file system 1122, the data may be retrieved from shadow file system 1121, thereby populating file system 1122 during runtime. Thus, virtual data center 1111 can be enabled to be launched more efficiently on cloud provider 1102 than in previous implementations.

As shown in FIG. 12A , in one embodiment, the cloud analysis and projection service 1000 can be implemented at different data centers 1200 and 1210 using their own gateway devices 1250 and 1251 , respectively. Gateway 1250 can then be used to establish a secure connection, such as a virtual private network (VPN) connection, between data centers when performing intra-data center migrations. In one embodiment, the VPN connection includes a purchased WAN accelerator link, such as those that provide deduplication compression algorithms (eg, Riverbed).

Two tenants are shown in data center 1200 : tenant 1201 with virtual data center 1230 and file system 1220 , and tenant 1202 with virtual data center 1231 and file system 1221 . Another tenant 1203 with virtual data center 1232 and file system 1222 is located in data center 1210 . As used herein, a "tenant" is a cloud user who has signed up for the virtual data center services described herein. In the example shown, a dedicated VPN connection is used to migrate virtual data center 1230 of tenant 1201 from data center 1200 to data center 1210 . In this case, since the VPN connection (purchased by CAPS 100) is a dedicated link between data centers, there will be no additional cost to tenant 1201 regarding data center migration.

As shown in Figure 12B, in one embodiment, in addition to providing local gateway devices 1300-1302 at each of the cloud providers A-C, the cloud analysis and projection service 1000 may build/purchase network structures (e.g., dedicated network infrastructure/backbone, etc.), the network structure includes additional gateway/router devices 1310-1313 for supporting high-speed secure interconnection between the various providers.

In one embodiment, the cloud analysis and projection service 1000 maintains a provider connection table 1290 such as that shown in FIG. 12C to determine whether a dedicated high-speed connection exists between any two cloud providers' data centers. In the specific example shown in FIG. 12C , providers 1-3 are all interconnected via a dedicated network infrastructure (eg, maintained/purchased by CAPS 100 ), while cloud providers 4 and 5 do not have any such connections. In one embodiment, cloud analysis and projection service 1000 and/or selection engines 220-222 may consult table 1290 when making a data center recommendation or selection. For example, if data centers 3 and 5 have similar cost, performance, and reliability characteristics, but data center 3 is coupled to the current data center via a dedicated high-speed connection, the selection engine may recommend migration to data center 3 over data center 5 .

As noted above, the global broker 210 can be dynamically updated with feedback from the cloud provider, which can include cost, performance, and/or reliability updates. Figure 13A illustrates an embodiment where performance and/or reliability updates are dynamically provided by agents 1320-1321 executing within a tenant-specific virtual datacenter 1301. In this particular embodiment, an agent 1320-1321 is inserted into each of the workloads 1310-1311 being executed on the resources of the virtual data center 1301, respectively. Agents 1320-1321 monitor the execution of corresponding workloads 1310-1311 and collect performance data. For example, agents 1320-1321 may measure the time it takes for workloads 1310-1311 to complete executing program code, and/or may examine other components within the virtual data center (e.g., file system 1325) and measure the time it takes to receive a response from each component. time. This information can then be reported back to the global intermediary 210 via the gateway 1330 and used to calculate a normalized performance measure for the cloud provider 1300 .

Figure 13B illustrates another embodiment in which a single data collection workload 1360 executes in parallel with other workloads 1350-1352 within the virtual data center 1301 to collect performance data and/or reliability data. Data collection workload 1360 may check other workloads 1350-1352 and other data center components (such as file system 1353) and measure the amount of time it takes to receive a response (a longer time indicates relatively lower performance). Data collection workload 1360 may also calculate the amount of time required to execute its own program code (eg, insert tags in the program code or perform other program tracing techniques). Since the data collection workload executes as another workload on the resources of the cloud provider 1300, the performance relative to its own execution is indicative of the performance of the other workloads 1350-1352. The data collection workload then feeds performance results back to the global broker 210 via the gateway 1330 .

In another embodiment, gateway 1330 may itself collect performance data from workloads 1350 - 1352 (eg, inspect workloads as described above), and feed the resulting data back to global broker 210 .

In both embodiments shown in Figures 13A-13B, the agents 1320-1321 or the data collection workload 1360 can also monitor the reliability of the virtual data center. For example, if no response to the inspection is received after a specified time, it may be determined that the component being measured is not available. This reliability information may then be transmitted to the global broker 210 via the gateway 1330 .

As noted above, in one embodiment, the CAPS 100 architecture can be used as an online marketplace for buying and selling data center services that can be built using the CAPS 100 architecture. Also, the market is not limited to buying by cloud users and selling by actual cloud providers. Rather, in one embodiment, any user or entity can buy and sell data center services in the open marketplace. Accordingly, a particular cloud provider may purchase data center services from another cloud provider (including virtual providers as discussed below) to meet demand. Conversely, a cloud subscriber can sell data center services to another cloud subscriber or to another cloud provider. For example, a particular cloud provider may sell data center services months in advance of expected usage of the data centers (eg, June sells data centers that will be used in December/January). Using the open market provided by CAPS 100, another user or cloud provider can buy these services and then resell them (e.g., for a profit or loss, depending on the market price of the service in December/January ). In this way, CAPS 100 establishes a futures market for data center services.

Figure 14 shows how the global broker 210 and data center database 211 can be configured to enable such an online marketplace. As previously stated, the data center database 211 contains the latest records of each of the cloud providers registered with the CAPS 100, including resource data, performance data, cost data, geographic location data, reliability data, and possibly cloud user-related any other data. Record 1401 is related to and includes all current information for Amazon Web Services (AWS). In contrast, record 1402 represents a user (or another cloud provider) (identified as a virtual AWS (vAWS) database record) that has purchased AWS data center services at a specific price for a specified time period. Going back to the above example, this user may have purchased December/January data center services from AWS several months in advance, but did not intend to use them (or perhaps purchased with the intention of only using some of them , or realize after a period of purchase that he/she will not need all of the services purchased). In one embodiment, users who have purchased future (or current) entitlements to data center services may register the availability of these services within the data center database 211 of the global broker 210 . The global broker 210 may then include these services in response to database queries generated from the various selection engines 220-222. If the cost of these services is lower than the current market price (all other factors being equal), then the selection engine 220-222 will recommend/select these services over those offered at the current market price (assuming the seller buys at the lower price) , then this can benefit the seller).

FIG. 14 shows further details related to the communication between the selection engine and the global broker 210 . In particular, query parameters 1405 may be sent from each of the selection engines 220-222 to the database query engine 1400, which then queries the data center database 211 using these parameters. For example, selection engine 220 may be interested in data centers located in New York and Japan; selection engine 221 may be interested in data centers located in California; and selection engine 222 may be interested in data centers located in Europe. In response, the database query engine may execute a query (or series of queries) and retrieve from the database 211 all data centers that meet the specified criteria. In one embodiment, the result is a "candidate" data center as described above (ie, a data center that meets some minimum initial criteria; in this case, a data center based on geographic location).

In one embodiment, the results of the database query engines 1400 are provided as entries of the queue 1410 and the entries of the queue 1410 are read/filtered by each of the selection engines. In one embodiment, a producer/consumer architecture is implemented in which the database query engine 1400 acts as a producer (writing new entries to a queue) and the selection engines 220-222 act as consumers of the queue (also sometimes referred to as a queue "listeners"). Going back to the above example, the selection engine 220 will only retrieve those entries from the queue 1410 associated with the data centers in New York and Japan; the selection engine 221 will only retrieve those entries from the queue 1410 associated with the data center in California; The engine 222 will only retrieve those entries from the queue 1410 associated with data centers in Europe. The respective selection engines 220-222 may then perform filtering/weighting operations as described above to further filter candidate data centers for recommendations or selections beneficial to cloud users (eg, based on cost, performance, reliability, etc.). Although not explicitly shown in FIG. 14, each selection engine may generate queries on the queue to retrieve only those entries relevant to its search (eg, for selection engine 220, New York and Japan).

Embodiments of the invention may include the various steps set forth above. These steps may be embodied as machine-executable instructions that cause a general-purpose processor or a special-purpose processor to perform certain steps. Alternatively, the steps may be performed by specific hardware components containing hard-wired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.

Elements of the present invention may also be provided as a machine-readable medium for storing machine-executable program code. Machine-readable media may include, but are not limited to, floppy disks, optical disks, CD-ROM and magneto-optical disks, ROM, RAM, EPROM, EEPROM, magnetic or optical cards, or other types of media/machine-readable media suitable for storing electronic program code .

Throughout the foregoing description, for purposes of explanation, numerous specific details were set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. For example, it is obvious to those skilled in the art that the functional modules and methods described herein can be implemented as software, hardware or any combination thereof. Furthermore, although some embodiments of the invention are described herein in the context of a mobile computing environment, the underlying principles of the invention are not limited to mobile computing implementations. Indeed, in some embodiments any type of client or peer data processing device may be used, including, for example, desktop or workstation computers. Accordingly, the scope and spirit of the invention should be judged from the following appended claims.

Claims (6)

1. A device comprising: a mediation component for managing data center information, the mediation component receiving updates containing the data center information and responding to queries to provide the data center information; a selection engine that performs data center selection and/or recommendation for a cloud user based on data center information read from the mediation component, wherein the data center selection and/or recommendation is based on a data center specified by an end user requests and/or preferences; and A projection component, upon selecting a data center from the selections and/or recommendations made by the selection engine, the projection component interacts with the selected data center and transmits data to configure the data center on behalf of the user. 2. A method for selecting a data center comprising: generating a query for information related to the data center, the query pointing to a data store containing the data center information; performing a lookup in the data store using the query to generate a set of candidate data centers; One or more of the candidate data centers are prioritized for the cloud subscriber based on requirements specified by the cloud subscriber, including cost requirements indicating cost thresholds for data center usage, including performance thresholds performance requirements and/or reliability requirements including reliability thresholds; and One of the data centers is selected for the cloud subscriber based on the prioritization. 3. A virtual data center device, comprising: a virtual data center layer comprising a plurality of virtual appliance controllers and data defining relationships between the virtual appliance controllers; Each of the virtual device controllers represents physical data center resources and related configurations, and multiple virtual device controllers combined form a virtual data center; a cloud interposer that maps the plurality of virtual appliance controllers to relevant data center resources on the physical data center in response to a command to project the virtual data layer to the physical data center. 4. A device comprising: a graphical user interface (GUI) comprising a plurality of objects selectable and editable by an end user; A virtual device controller layer, the virtual device controller layer includes a plurality of virtual device controllers, each virtual device controller represents a physical data center resource and its related configuration, and the combined virtual device controllers form a virtual data center; wherein each of a plurality of said objects of said GUI represents and maps to a particular virtual device controller within a virtual device controller layer; and Wherein a user may edit data center resources and associated configurations of said data center resources by selecting said objects associated with said virtual appliance controllers of those resources. 5. A device for migrating data centers, comprising: a data center projection component that initiates and manages migration between data centers; A first instance of a distributed file system engine configured at a first data center and a second instance of a distributed file system engine configured at a second data center, the first instance of the distributed file system engine and said second instance maintains synchronization between files stored at said first data center and said second data center on behalf of a user; The data center projection component causes migration from the second data center to a third data center by opening a third instance of the distributed file system engine on a third data center, all of the distributed file system The third example populates files from the first data center and/or the second data center to the third data center, and the distributed file system allows the data center projection component to be stored in the first data center All files of the data center and the second data center are copied to the third data center before the second data center is taken offline. 6. An apparatus for enabling a market for data center services, comprising: a mediation component that manages data center information, the mediation component receiving updates containing the data center information and responding to queries to provide the data center information; a database accessible by the mediation component, the database storing the data center information, wherein each record in the database includes data for a physical data center provider or a virtual data center provider, each record of a physical data center provider, each record of the physical data center provider including a first identification code identifying the physical data center provider, specifying the resources provided by the physical data center provider resource data and cost data specifying the costs associated with using said resource; and each record of a virtual data center provider that includes a second identification code identifying a user who has purchased the right to use the physical data center provider's resources at a specified cost for a specified duration , the record further identifying the physical data center provider and the resources provided by the physical data center provider; and a selection engine that performs data center selection and/or Recommendation, wherein the data center selection and/or recommendation is based on data center requirements and/or preferences specified by the end user.