Enrique Castro-Leon is an enterprise architect and technology strategist with Intel Corporation working on technology integration for highly efficient virtualized cloud data centers to emerging usage models for cloud computing.
He is the lead author of two books, The Business Value of Virtual Service Grids: Strategic Insights for Enterprise Decision Makers and Creating the Infrastructure for Cloud Computing: An Essential Handbook for IT Professionals.
He holds a BSEE degree from the University of Costa Rica, and M.S. degrees in Electrical Engineering and Computer Science, and a Ph.D. in Electrical Engineering from Purdue University.
John Kennedy is a senior researcher in the Cloud and Services Lab of Intel Labs Europe. He is focusing on open standards and open source enablers to facilitate more dependable cloud computing. John is particularly active in Intel's European research initiatives, engaging in collaborative research at local, national, and international levels. He has a B. Eng (hons) in Electronic Engineering and M. Sc. in Computing. John joined Intel in 1997 and has held roles of systems analyst, developer, solution architect, and applied researcher in Intel's Manufacturing, IT, and Intel Labs organizations.
On the Concept of Metadata Exchange in Cloud Services - Part II Published: May 20, 2013 • Service Technology Magazine Issue LXXII PDF
In the second article of this two part series we explored the concept of cloud service metadata and metadata exchange. Service metadata is information about a service itself, allowing service introspection. Metadata is essential for service consumer building a composite application to evaluate whether a given service offering from a provider matches the application's requirements. In this article we'll see how metadata features for artifacts inside a service can be exposed across service boundaries. Read the first part of this article here.
Intel Corporation and Telefónica Digital initiated a joint project to build a proof point of the concepts described in the previous article. The goal for this project was to demonstrate the feasibility of cloud bursting across two companies.
The PoC implements a service setup scenario where an application running on servers in Folsom, California requests external resources, namely servers hosted by Telefónica running in Madrid. A carefully choreographed pas de deux ensues, facilitated by a cloud fabric implemented under Citrix Netscaler* VPX. When the dance completes, the remote Telefónica servers ("nodes") end up in the same subnet as the initiating servers in Folsom, California.
In the remainder of this section we provide a detailed description of the cloud bursting setup orchestration. In the initial state, as shown in Figure 1, we see two resources (servers) functioning independently. The Intel data center hosts an application capable of cloud bursting (that is, Intel is the service consumer or initiator), whereas the Telefónica data center offers hardware for rent as a traditional cloud IaaS service.
Figure 1 - Initial state before cloud bursting (Source: Intel 2012)
Now assume that customer A1, currently running two virtual machines in the Intel host, requests that a third virtual machine be instantiated, as shown in Figure 2. Furthermore assume that under current policies there is no more room for virtual machines at the Intel host.
Figure 2 - The application receives a request to add a third virtual machine (Source: Intel 2012)
The infrastructure manager orchestrating resources for the Intel application, which can be a service in its own right, makes a decision to outsource the hosting of the new virtual machine to an external IaaS provider and queries a resource broker, essentially a directory service. The broker returns a URL for the extended resource, a handle for the Telefónica data center provisioning API. The requester uses the handle to initiate a process to qualify and bind the Telefónica service to the application.
At a higher level this orchestration can be accomplished through the OpenStack or the OCCI frameworks. Figure 3 shows some of the OpenStack Compute API (Nova API) calls. At a lower level these calls get mapped into Citrix Netscaler operations.
Assume that as a matter of policy the application is compelled to compute the carbon footprint for all resources it touches, and through the Nova API it retrieves the Telefónica host metadata dictionary. After some parsing it extracts the power management object, listing the server's power management features. In our proof-of-concept this confirms the presence of Intel® Node Manager Technology and the access methods (API) to elicit these features. At this point the API can be bound to the power management policies already in effect, allowing operations such as calculating the energy expended by the operations performed on the Telefónica node.
Figure 3 - Current policy prevents new VM from being created at the Intel host. The Infrastructure Manager queries a broker for an external resource for a cloud bursting target. (Source: Intel 2012)
The final configuration after the automated setup is shown in Figure 4.
Figure 4 - Physical host and virtual machine bound to originating service (Source: Intel 2012)
When a number of services are connected in this manner to build a composite application, the result is a multi-cloud, and hence the moniker multi-cloud management.
Figure 5 - A Multi-Cloud Composite Application. (Source: Intel 2012)
The multi-cloud handshaking process happens in this manner: An enterprise application monitoring the application's performance senses in-house resources running short of an anticipated peak demand and goes through a third-party broker to identify a cloud provider to land the extra demand. The broker recommends the Telefónica service and goes through the provider/consumer setup described earlier. The choreography of this setup is fairly complex, facilitated by Citrix NetScaler VPX.
In order to manage risk, Telefónica also balances in-house and subsidiary cloud providers. Some of these providers may be pure play providers, relying on IaaS providers for their infrastructure needs as shown in Figure 5.
For each of the recursive provider/consumer relationships represented by the blue arrows in Figure 5, there is metadata flowing in the opposite direction, represented by the red arrows.
Figure 6 depicts a management console running at an Intel lab in Folsom, California, represented by the Intel Data Center Manager (DCM) console, displaying a service metadata attribute, namely power management for a service running. The simulated service runs in a server installed at a lab in Madrid. After a cloud bursting handshake the remote server has been placed in the service consumer's local subnet, and all the low level capabilities of that server are now available to the service consumer, including the IPMI-based API that DCM uses to access the firmware implemented Intel Node Manager capabilities for server power monitoring and for imposing power consumption limits.
Figure 6 - Folsom Management Console Displaying a Power Management Resource in Madrid.
During the service negotiation the original enterprise cloud bursting requester has the option of requesting exclusive access to the hardware and can manage this hardware as if it were a local resource if the application demands it. Beyond that, the metadata exchange mechanism can in principle perform introspection on the service to identify all the intervening services to verify their reputation. Conversely, any service provider can advertise their presence and leverage their brand name.
The "in principle" is an important qualifier. How much metadata is exposed is very much a business decision among the parties involved. Some providers will make their particular combination of services their secret sauce and choose not to disclose it, where others may decide that disclosing a complete portfolio is in their interest. Conversely, some service providers who want to make themselves known may require providers upstream to provide their identity as a condition for doing business.
The OpenStack effort has resulted in potential enhancements to OpenStack being identified, and in several research areas being identified for future collaboration. Further investigation is ongoing to identify a suitably scalable approach for secure metadata exchange that might be of interest to the
Economics is driving the adoption of the cloud, and within this context, the authors believe that economics will also drive the need for metadata. It is very likely that the metadata revolution that took place in consumer space social networks will take place in enterprise space in the next few years.
With the status quo and a one-size-fits-all strategy, a service product would be overprovisioned or too complex for customers with the lowest SLA requirements, resulting in higher OpEx, and there would be opportunity costs: customers not signing up because a service offering does not meet their requirements profile, being either under- or over-specified. The service metrics enabled by the availability of service metadata reduces uncertainty and adds predictability to service transactions, increasing the perceived value from the perspective of the service consumer, and enabling the service provider to offer more targeted, differentiated products.
The geolocation example described in this article is only one example of new cloud service capabilities enabled by service metadata exchange. We will be reporting the outcomes of actual experiments in
Another area that requires additional exploration is the security aspects of metadata exchange. Since the ability to advertise certain capabilities may determine whether or not a specific service gets hired, these decisions will have a revenue impact on service operators. Therefore the temptation exists for unscrupulous operators to alter metadata records.
Hence it is necessary to implement methods to deter this potential tampering. An example could be service spoofing: a service operator may claim to be using a storage service from a highly regarded provider, when in reality the operator vectors storage functionality to a lower cost and presumably less reliable provider. Service metadata brings a needed degree of transparency in cloud transactions, a first step toward bringing predictable QoS that in turn will enable enforceable SLAs. This degree of unpredictability has been one of the main barriers toward cloud adoption in the industry.
Metadata exchange depends on mutually agreed protocols between the contracting parties in order to work. To this end we are actively working with open source projects and open standards organizations to introduce and showcase such support into appropriate points in the cloud computing stack.
The work reported here represents only the beginning of what we believe is a rich area for research, very relevant to cloud computing because of the revenue and cost implications to service providers and consumers alike. Platform power management features are being used in this project as a proof of feasibility for the metadata exchange.
Support for metadata exchange is an optional component in a service offering. Service providers will support the capability if it's in their interest, for instance if it helps in building a reputation with positive revenue impact. In any case, when a service provider chooses to expose certain metadata, the service consumer needs to have a reasonable assurance that the information is truthful.
There are also technical motivations for metadata adoption: this framework can be extended into a general framework for a two-way auto-negotiation where a service consumer queries or imposes certain requirements on the service provider, for instance the type of hypervisor to be used in a service request.
Areas to be further explored in the future are the concept of a metadata management infrastructure, whether brokered by third parties or as two-party exchanges such as the recursive aspects of metadata exchange and metadata filtering. We will report on these discoveries as data becomes available.
[REF-1] Ganesan Shankaranarayanan, Adir Even, "The Metadata Enigma," Comm. ACM, Vol. 49-2, February 2006.
[REF-2] J. Wang, P. Varman, C. Xie, "Middleware Enabled Data Sharing on Cloud Storage Services," Proc. ACM MW4SOC'10, Bangalore, November 29, 2010.
[REF-3] Wikipedia, Metadata, Retrieved February 5, 2012 from http://en.wikipedia.org/wiki/Metadata.
[REF-4] Dournaee, B., "Taking Control of the Cloud for your Enterprise," Intel Corporation white paper, 2010. Retrieved from http://info.intel.com/rs/ intel/images/Taking_Control_of_the_Cloud.pdf.
[REF-5] Harmon, R. R., Auseklis, N., "Sustainable IT Services: Assessing the Impact of Green Computing Practices," PICMET 2009 Proceedings, IEEE, pp. 1707-1717, 2009.
[REF-6] Kearney, K.T.; Torelli, F.; Kotsokalis, C.; "SLA: An abstract syntax for Service Level Agreements, Grid Computing (GRID)," 2010 11th IEEE/ ACM International Conference, pp. 217–224, 2010, http://www.sla4d- grid.de/sites/default/files/SLAWS_Grid-2010_SLAatSOI_Model.pdf
[REF-7] Kennedy, J; Edmonds, A., Bayon, V., Cheevers, P. Lu, K., Stopar, M., Murn, D., "SLA-Enabled Infrastructure Management," Chapter 7 in Service Level Agreements for Cloud Computing, Springer, 2011.
[REF-8] E. Castro-Leon, E., He, J., Chang, M., Peiravi, P., The Business Value of Virtual Service Oriented Grids, Chapter 2, Intel Press, 2008.
[REF-9] Open Cloud Computing Interface, Retrieved February 20, 2012 from http://occi-wg.org/.
[REF-10] Linthicum, D.S., Cloud Computing and SOA Convergence in Your Enterprise, A Step-by-Step Guide, Addison-Wesley, 2010.
[REF-11] Schmidt, R., "Perspectives for Moving Business Processes into the Cloud," I. Bider et al. (Eds.), BPMDS 2010 and EMMSAD 2010, pp. 49–61, Springer-Verlag Berlin Heidelberg 2010.
[REF-12] Schmidt, R., "A Service-System Based Identification of Meta-services for the Service-Oriented Enterprise Architecture," Proc. 15th IEEE Int. Enterprise Distributed Object Computing Conference, pp. 293–300, 2011.
[REF-13] The W3C Incubator Activity. Retrieved February 20, 2012 from http://www.w3.org/2005/Incubator/usdl/.
[REF-14] Wolf, C., "Security and Compliance in the Cloud," 2009. Retrieved February 5, 2012
[REF-15] Wolf, C., "The Cloud Mystery Machine: Metadata Standards," 2010. Retrieved February 12, 2012
[REF-16] "The Future Internet Core Platform." Retrieved February 20, 2012 from http://www.fi-ware.eu/.
[REF-17] Verma, A., Venkataraman, S., Caesar, Campbell, R., "Efficient Metadata Management for Cloud Computing Applications," Technical Report, University of Illinois, 2010. Retrieved from https://www.ideals.illinois. edu/handle/2142/14820
[REF-18] SLA@SOI Project Web Site in the European Union. Retrieved February 20, 2012 from http://www.sla-at-soi.eu.
[REF-19] Foundations for SLA Management – Evaluated Framework, SCLA@ SOI Deliverable D.A5a, Retrieved February 20, 2012 from http://sla-at-soi.eu/wp-content/uploads/2011/08/D.A5a-M38-SLA-Foundations-and-Management.pdf.
[REF-20] A Collection of Resources Relating to the SLA Model, SLA@SOI SourceForge Project Wiki. Retrieved February 20, 2012 from http://sourceforge.net/apps/trac/sla-at-soi/wiki/SlaModel.
[REF-21] Coase, R. H., "The Nature of the Firm," Economica, Vol. 4 No. 16. (Nov. 1937), pp. 386-405.
[REF-22] Open Data Center Alliance Usage: Service Catalog, Open Data Center Alliance (2011)