GHG Protocol Product Life Cycle Accounting and Reporting Standard ICT Sector Guidance. Chapter 5:

Transcription

1 GHG Protocol Product Life Cycle Accounting and Reporting Standard ICT Sector Guidance Chapter : Guide for assessing GHG emissions of Cloud Computing and Data Center Services DRAFT January 0

2 Table of Contents Guide for assessing GHG emissions of Cloud Computing and Data Center Services.... Introduction..... What is in this chapter..... The audience for this chapter..... Examples: When to use and when not to use this chapter..... Rationale of this chapter..... Business Goals for assessing Cloud and Data Center Services.... Overview of Method..... Data Centers and Cloud Services..... Completeness principle..... Fixed and Variable emissions..... Allocation Process..... Calculation Process Functional Unit Functional Unit: Cloud Services..... Functional Unit: Data Center Services.... Boundary Setting..... Defining Boundaries..... Attributable Processes..... Non-attributable Processes..... Temporal Considerations - amortization of embodied emissions.... Data Collection and Data Quality.... Allocation..... Allocation of Data Center emissions..... Allocating Equipment to Cloud Services..... Allocating Equipment to Data Center Services..... Allocation of Network emissions..... Allocation of End-user device emissions.... Calculating Inventory Results..... Overview of Calculation Methodology for Cloud Services..... Calculating Data Center Emissions..... Calculating Network Emissions..... Calculating End-user-Device Use..... Calculating Embodied Emissions..... Example Case Study of Cloud Service..... Example Calculations for Data Center Services... page

3 [This is a chapter of the GHG Protocol Product Standard ICT Sector Guidance. It is being issued as a draft for public comment, through the GHG Protocol ICT Stakeholder Advisory Group. It has been revised following comments received on the previous draft that was issued in March 0. Following any further comments received on this draft, the document will be revised again and a final version published. The ICT Sector Guidance consists of the following chapters: Introduction; Telecommunications Network Services; Desktop Managed Services; Cloud and Data Center Services; Transport Avoidance; Hardware; Software. The Introduction Chapter includes general principles applicable to the GHG assessment of ICT products and a summary of common methods to be used, which all the chapters can refer to. Further details of the ICT Sector Guidance initiative are available at the GHG Protocol website: Sections (such as this) in italics and square brackets are for explanation of the draft and will be removed for the final version of the document.] page

4 Executive Summary: Cloud and Data Center Services Chapter Cloud and data center services are becoming increasingly commonplace, replacing IT services that would formerly have been provided and hosted by companies using their own in-house dedicated computing infrastructure. Cloud computing provides application hosting, often utilizing shared resources, with convenient, on-demand, ubiquitous remote access via the internet. Cloud services are typically provided remotely by a third party, and may also be provided as on-premise cloud services. Data center services allow companies to meet their computing requirements through a mix of leasing options, more efficiently and cost effectively than using their own dedicated facilities. This has driven a rapid growth in terms of cloud computing services, internet usage, and exponential growth in data centers. This has in turn raised particular concern over energy consumption of networks and data centers. This chapter therefore provides guidance for the calculation of the greenhouse gas (GHG) emissions related to cloud and data center services, allowing practitioners to assess and study the GHG impact of these services. Where detailed scientific measurement is not available, a key challenge in assessing cloud and data center services is how to allocate the GHG emissions of a data center to the services provided from it. This chapter gives guidance on this, and provides a number of different allocation methods (dependent on the type of data center, the type of service, and the type of metering and information available at the data center). The GHG emissions of cloud services relate to the three main areas that make up the delivery of the service: the data center emissions, the emissions of the network, and the emissions of the end-user devices (such as PCs, laptops, tablets, and phones). This chapter describes how to calculate the emissions of these separate elements. Other chapters in the guidance document provide further details: the Hardware chapter for emissions of ICT hardware; the Telecommunications Network Services chapter for emissions of networks; and the Software chapter for the emissions of software. This chapter concludes with a case study for assessing a cloud service and some examples for calculating emissions of data center services (illustrating the different allocation methodologies that may be used). page

5 Introduction.. What is in this chapter This chapter forms part of the ICT Sector Guidance to the Greenhouse Gas Protocol Product Life Cycle Accounting and Reporting Standard ( Product Standard ) and covers Cloud and Data Center Services This chapter provides guidance and accounting methods for the calculation of GHG emissions related to Cloud and Data Center Services The chapter provides guidance on the following key items: Establishing the scope of a product inventory. Defining the functional unit. Boundary setting. Allocation. Collecting data and assessing data quality. Calculating inventory results and GHG emissions. A case study for assessing cloud services. Examples of calculating emissions of data center services... The audience for this chapter There are several potential users of this chapter: Suppliers of Cloud and Data Center Services, who require standard terminology, guidance and accounting methods to calculate the GHG emissions of the services that they provide. This may often be required in response to queries from their customers and potential customers. It can also be used to understand where the major sources of GHG emissions are from Cloud and Data Center Services, and how the suppliers may reduce the emissions of the services that they provide. Users of Cloud and Data Center Services, who are interested in understanding the GHG emissions of the services that they are using, and understand where improvements and efficiencies may be made. Organizations, which are interested in understanding the GHG emissions of cloud and data center services, and understanding these in relation to more traditional ways of delivering the same services... Examples: When to use and when not to use this chapter This guidance is for accounting of GHG emissions from cloud and data center services. Examples of where it may be used are: For assessing the GHG emissions of a cloud service provided from one or more data centers For assessing the GHG emissions associated with the use of all or part of a data center (e.g. where all or part of a data center is leased from a data center provider). For comparing the GHG emissions of a cloud service with those from an equivalent non-cloud service. (For this type of use it is important to apply the same boundary conditions to both cases, in addition it is recommended to carry out an uncertainty analysis to understand the comparison of the results). This guidance for cloud and data center services should not be used: For comparison of similar cloud or data center services from different providers, without additional rules to ensure a valid comparison. page

6 Rationale of this chapter A range of business and consumer applications are increasingly provided from cloud architecture, for example: , calendar, document and other business applications. Consumer photo, video and music and other data storage applications. Search, social networking and database applications. Application hosting in the cloud. This chapter provides guidance on how to quantify the energy and GHG emissions associated with the delivery of these services. The guidance is written from the perspective of a user of cloud services and aims to provide standard and repeatable methods in order to facilitate a better understanding of the energy and GHG impacts of alternative ICT service delivery solutions... Business Goals for assessing Cloud and Data Center Services Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g. networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. As such, it is a service that can yield significant efficiencies in the provision of ICT services and can lead to a reduction in GHG emissions based on how the service is configured and deployed. Co-location data center services, which differ from cloud services in that the user has control of the specification and management of the IT devices used to host ICT services, can also yield life cycle efficiencies compared to traditional inhouse IT hosting. This guidance allows cloud and data center service providers and customers to measure and report the GHG emissions from their services in a consistent manner and make informed choices to reduce GHG emissions. For the purposes of this guidance, cloud services are those services that are provided to computers and other end-user devices as a utility over a network, using shared infrastructure that includes data centers, hardware, software and other infrastructure. This guidance adopts the standard definitions and taxonomy for cloud services developed by NIST, which delineate by the level of operational control the user has: Infrastructure as a Service (IaaS): The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls). Platform as a Service (PaaS): The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment. NIST Special Publication 00- The NIST Definition of Cloud Computing September 0 The Carbon Emissions of Server Computing for small-to medium-sized organizations: A performance study of On-Premise vs. The Cloud. NRDC & WSP. October 0. NIST Special Publication 00- The NIST Definition of Cloud Computing September 0 page

7 0 0 0 Software as a Service (SaaS): The capability provided to the consumer is to use the provider s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based ), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings. Data center Services are defined as Wholesale and Colocation services, in which the service provider leases space in a facility and provides mechanical, electrical and other operational services to users (i.e. lessees). The lessee has full control of specification and management of the IT devices hosting the services. Wholesale leases: lessee may lease the entire data center, pay utility bills and operate/maintain all data center physical infrastructure. Alternatively, the lessee may lease the entire site, and rely upon the owner for operation and maintenance of the critical environment infrastructure (electrical, mechanical and other critical infrastructure) and payment of utility bills. Colocation leases: the owner operates and maintains all critical data center infrastructure, however, in some cases the owner operates and maintains ICT infrastructure and leases servers as physical hosts. Or alternatively a cage with basic power/cooling/security is provided and the lessee operates all ICT equipment. The underlying energy-using infrastructure used by cloud and data center services includes: Hardware: servers, switches and routers that store and transmit information Software: which controls and commands the hardware to process information and thus how much power is consumed Data centers: which house servers and other hardware devices for storing and fulfilling services and provide the critical systems and other ancillary equipment Network: which includes wired or wireless infrastructure for transmitting information from cloud infrastructure to end users End user devices (or client ): including computers, smart phones and other devices used for accessing cloud services The chapter draws from the methods outlined in the Telecommunication Network Services and Hardware chapters of this guidance document, which prescribe the methods for calculating the GHG impacts of the various component parts of the infrastructure that support a cloud service. 0. Overview of Method This section provides an overview of the approach for calculating the GHG emissions from Cloud and Data Center services. This is then expanded on through the rest of this chapter... Data Centers and Cloud Services Relationship between Cloud Services and Data Centers Cloud services include use of: Data centers Networks End user devices Thus a fundamental part of calculating the emissions from cloud services involves calculating the emissions from the data center and allocating these to the specific service. Data center services provide computing services from all or part of a data center. So again this involves allocating the total data center emissions to the specific data center service. page

8 0 0 0 Data Center Definition The guidance in this chapter is applicable to a variety of different type of data centers, thus the definition adopted is deliberately broad. A data center is considered to be a physical location dedicated to hosting ICT infrastructure: A data center may be a location in a mixed-use facility or a dedicated location. Data centers may be of varying tiers or form factors; i.e. providing different levels of security, redundancy etc. Data centers may host ICT infrastructure for internal use or services for external customers, with a diverse set of business applications or usage at any physical location. Data centers may be used for testing or production use of applications, services, platforms or clouds. Data centers may vary in size in terms of total useable capacity for ICT equipment. Data Center Overhead It is well understood within the industry that a data center will use more input energy than it delivers to the IT equipment; this overhead is due to the data center mechanical and electrical (M&E) infrastructure and is commonly measured with the metric PUE which represents the ratio between the total facility power and the IT equipment power. This energy overhead (or non-it energy) includes the energy used by cooling systems, and also power delivery components such as UPS (uninterruptible power supply), switch gear, generators and batteries. Data Center Capacity It is common for data center capacity to be sold based either on provisioned circuit power (kw) or on physical floor space provided (square meters or square feet). Thus the data center lease will provide for a specified power or floor space, which may then be divided further to a rack, cage or server level. The data center will typically be designed to a specification of maximum power provision, with the infrastructure equipment and cooling capability being designed for this maximum power. It is therefore appropriate to use the data center capacity as a key method for allocating overheads. This data center capacity is therefore measured in terms of kw (although it can also be derived from floor space or from numbers of racks). Note, in this chapter the term provisioned capacity is therefore used to refer to the circuit power (or floor space) allocated to the data center, to an individual customer, service, or set of IT equipment... Completeness principle A key aspect of calculating emissions from data center services and cloud services is the allocation of the data center emissions to the individual services. The underlying principle of the allocation mechanisms is that of completeness: all of the emissions of the data center should be allocated to the services that the data center delivers. This principle can be summarized as: Allocate all of the emissions The Power Usage Effectiveness (PUE) ratio was developed as a key data center efficiency metric by The Green Grid consortium page

9 0 0 0 The first key rule is that the entire GHG emissions of the data center should be allocated to the services delivered from it. This includes both the utility energy supply and the embodied emissions in the devices. All IT devices must be allocated to a service This is the second part of the completeness principle. All IT devices in the data center should be allocated to a delivered service. Those which support more than one service such as shared network, shared storage or monitoring systems should be divided across the other devices using a consistent allocation per physical device, logical device or service unit... Fixed and Variable emissions A key consideration in the definition and implementation of an allocation mechanism is the separation between the fixed and variable emissions of the data center. Part of the data center emissions are fixed and do not vary with the IT service consumption or the IT electrical load in the data center. This includes the embodied emissions of the data center, the fixed part of the data center energy overhead and the fixed energy consumption of the IT devices. There is a substantial part of the energy overhead which does not vary with the IT electrical load within the data center. This mix of fixed and variable overheads is the cause of the commonly observed efficiency decrease (or PUE increases) with decreasing IT electrical load. This is also true at the level of the IT device, (for example, many servers use over 0% of their peak workload electrical power at zero or low load, although chip and server manufacturers are now working at reducing this system idle power). The difficulty of determining the precise mix of fixed and variable infrastructure overheads for a site has an important implication for measurement and reporting. The inherent error margin in scaling an IT load to the allocated utility energy tends to negate any increase in accuracy obtained through device level metering. Other estimation methods are likely to be of equivalent overall accuracy and operators are not expected to install IT device level power metering simply to report emissions. As far as reasonable, based on the available data the selected allocation method should seek to separate the fixed and variable emissions of the site. The intent is to allocate the fixed emissions based on the provisioned capacity and the variable based on the energy consumption of each platform, customer or device... Allocation Process A data center is like an onion with multiple layers. At each layer an allocation is potentially necessary. Figure : Data center layers page

10 The allocation steps are summarized in the following diagram (Figure : Allocation steps) Data Center IT Devices Virtual Machines Services Users Fixed Emissions Allocated kw Fixed Emissions Allocated Capacity Virtual Machine Service User Variable Emissions Drawn kwh Variable Emissions Utilised Capacity Other Virtual Machines Other Services Other Users Figure : Allocation steps ) Allocate the data center emissions a) Allocate fixed emissions to IT devices based upon the provisioned capacity for the IT device, or group of devices b) Allocate variable emissions to IT devices based upon the energy consumption of the IT device or group of devices ) If virtual machines are in use, allocate IT device emissions to virtual machines, for example: a) Allocate the IT device fixed emissions (based on idle power) to virtual machines based on the fraction of machine capacity allocated to the virtual machine or based on a simple fixed emissions to total virtual machines approach b) Allocate the IT device variable emissions (actual idle power) to virtual machines based on a suitable proxy for work such as CPU load ) Allocate IT device emissions (or virtual machine emissions) to services ) Where a service is used by more than one user then the service emissions should be allocated to the individual users The specific allocation methods chosen for each step will be partly dependent on the data available, and on the type of service being delivered. Section. provides more detailed guidance on the different allocation methods... Calculation Process The calculation process is described further in section.. The process involves calculating and summing the data center emissions, network emissions, and end-user device emissions, and then allocating these to a service.. Functional Unit The functional unit should define the following three parameters: The Quantity of the service: this will be the defining parameter for the service and typically will equate to how the service is sold. Some typical examples are: Number of users, mailboxes supported Size of storage capacity (GB) provided Quantity of computing capability provided (e.g. number of minutes, or number and type of servers) The Duration of the service: typically this will be expressed in terms of per year. Some examples are: page 0

11 0 Per year, month, day, hour or minute For the contract duration (one or multiple years) The Quality of the service: this should describe the relevant service levels, where they exist, as these may have a significant impact on the resources required to provide the service, in terms of recovery / availability... Functional Unit: Cloud Services Cloud services are procured in different ways, for example: on a per-user basis; or by storage capacity (e.g. GB of data stored), both measured over a period of time (e.g. per-day or per-year). These are useful starting points for defining the functional unit of cloud services. Where use profiles vary significantly for cloud services, transactions may better reflect the key indicator i.e. the number of application programming interfaces (API) and web requests processed by the platform over a period of time. These alternative functional units may be used when undertaking analysis of cloud services, and should be selected based on the characteristics of the cloud service as shown in Table : Table : Alternative Functional Units for Cloud Services Functional Unit Example Cloud Services Characteristics Per-user (or user group) , calendar, document and other business applications High data storage requirements and high user access Per-unit of storage capacity Consumer photo, video and music and other data storage applications High data storage requirements and low user access 0 0 Per-transaction Search; social networking and database applications Low data storage requirements; high user access When undertaking analysis on a per-user basis, to account for the fact that servers hosting cloud services do not follow a linear scale as user counts increase, aggregation into different sized user groups may be necessary to understand efficiencies of scale provided by cloud services. These user groups may be defined by the number of users or by the terms of a license, or service level agreement. Transaction-based analysis can enable more accurate comparison of alternative cloud platforms. A transaction can be defined as a WebAPI (i.e. a web request/response), for example. However, due to the diversity and complexity in types of transactions and lack of a standardized methodology to separate each type of transaction, an assumption would typically be made that all transactions for a given service require the same amount of energy load upon the IT hardware to process, based on typical packet size and type of transaction. The functional unit should be defined with a high degree of specificity, defining the level and quality of service, especially in cases where the basis for normalization is complex and could be potentially misleading. For instance, instead of simply defining the functional unit as an API, additional descriptive information can be provided to clarify what an API specifically means for a given type of service and what range in physical resource demands may exist for various types of APIs considered. As a further example, even for a service such as there is a range of parameters which will legitimately affect the energy consumption of the delivered user service;. The size of the mailstore (in both messages and total data volume). The number of messages sent and received in each unit time page

12 0 0. The extent of filtering, virus scanning etc. carried out on each routed message. Whether the messages are viewed in a web mail client or downloaded by a client application using a protocol such as POP or IMAP, or both. The level of resilience and availability of the infrastructure, e.g. redundant front end servers and duplicate storage of the mailstore(s) across multiple data centers. The additional functionality provided, e.g. calendaring. The physical location (geographic region and jurisdiction) in which the data is held and processed.. Functional Unit: Data Center Services For data center services, the functional unit should clearly describe the kind of lease (wholesale or colocation) and fully define the scope of the service in terms of quantity and time period, and any particular service level agreements (SLAs) that are part of the service.. Boundary Setting.. Defining Boundaries Cloud services create emissions in three main places: Data centers: switches, routers and servers / storage devices used for receiving, sending and storing data and the associated critical systems, facilities and utilities. Network: routers, switches, cables and other equipment associated with the transfer of data between the data center and end-user. End-user devices: PCs, laptops, tablets, phones or other devices used to access cloud services. The diagram shown in Figure provides generic boundaries for aspects of infrastructure that support cloud service delivery. Depending on the nature of specific cloud applications, certain aspects may not be necessary to include. Figure : Generic scope and boundary for equipment used by Cloud Services.. Attributable Processes Processes directly attributable to the GHG impact of cloud services are: page

13 0 0 Hosting and fulfillment of the cloud applications including servers, storage devices, other IT equipment, critical systems and associated data center facilities including HVAC systems required for server cooling. Internet transfer. User access. Energy, water, refrigerants, fire suppression gases and other consumable materials consumed by the above processes throughout their life cycle... Non-attributable Processes Processes that are not attributable to the GHG impact of cloud services are: Energy consumed during software development. Material and energy flows from production of capital equipment, transportation vehicles, buildings and their energy use not directly related to equipment for hosting and fulfillment of the cloud service and associated equipment. Maintenance of capital equipment... Temporal Considerations - amortization of embodied emissions The embodied emissions of the equipment should be amortized over the expected in-use lifetime of the equipment. The lifetime will vary significantly from equipment type to equipment type, and also based on the renewal policy of the data center. This may also vary based on the type of technology used. For example: Lifetime of IT equipment is likely to be between months and years. Examples of lifetimes for infrastructure equipment are: Years - Main MV transformers, some electrical switchgear 0 Years Chillers, Cooling towers, main chilled water pipework, backup generators, low voltage distribution cabling and switchgear, AHU units Years UPS, data hall electrical PDU, CRAC units <0 Years Elements closely coupled to IT such as in row cooling units, rack exit door coolers, smart power strips etc. 0 It is usual to align the amortization of the embodied emissions with the assumptions used for amortization of capital costs for financial accounting purposes. Whatever assumptions are used for amortizing equipment, they should be clearly stated in supporting documentation. 0. Data Collection and Data Quality Data should be collected for all processes included in the inventory boundary. Primary data should be collected for processes under the ownership or control of the cloud service provider. Depending on the service being assessed and the allocation method being used the following data may be required: Users: use profiles and number of users at any given period of time Licensing or service level agreements: the units of service defined, e.g. number of users for a specified period of time Transactions: for example, measured Iops or WebAPIs/requests processed by the platform, over a specified time period Data centers: number and location page

14 Server count: number of servers provisioned to host and fulfill the cloud application and data storage requirements. This includes redundancy for business continuity and disaster recovery Network Link equipment count: number of in-data center routers and switches required to fulfill WebAPI requests, and process web transactions. This includes redundancy for business continuity and disaster recovery Device utilization: computational load that a device is managing relative to the specified peak load Power consumption per type of IT hardware: calculated energy consumed by a server at a given rate of device utilization and estimated power for networking and storage equipment Data center Power Usage Effectiveness (PUE): defined as the ratio of overall power drawn by the data center facility, to the power delivered to the IT hardware. This is a data center-specific metric and accounts for energy consumption of active cooling, power conditioning, lighting, and other critical data center infrastructure. Emission Factors - equipment: factors for the embodied emissions of relevant IT equipment, ideally obtained from equipment manufacturers. See also the Hardware chapter for methods of calculating and estimating these. Emission Factors electricity: the emission factor for the electricity used should be appropriate for the region where the electricity is consumed. Electricity grid emission factors are published on a national basis, and in some cases on a regional basis. Electricity grid emission factors should be used that include the full life cycle of the energy source (i.e. include emissions due to extraction and transportation of the fuel, as well as generation and transmission). If primary data is not available, secondary data and/or assumptions may be developed for processes that are not under the ownership or control of the cloud service provider. These might include: Internet transfer: secondary data on access and core network usage (see the Telecommunications Network Services chapter for more details) Embodied emissions for hardware: estimates of embodied emissions on a per-server basis. The use of all primary and secondary data should be clearly documented and communicated with the results of the GHG inventory with commentary on: Technological representativeness: the degree to which the data reflects the actual equipment and infrastructure used to support the cloud service Geographical representativeness: the degree to which the data reflects actual geographic location of the equipment used to host and fulfill services (e.g., country or site) Temporal representativeness: the time period that the collected data relates to Completeness: the degree to which the data are statistically representative of the cloud services Reliability: the degree to which the sources, data collection methods, and verification procedures used to obtain the data are dependable. Data Center Energy data Energy (kwh) used by a data center is a key data item to be measured. The diagram shown in Figure identifies key measurement points within a data center. page

15 0 0 Figure : Flow chart of energy use throughout a site Measurement of kwh at both points M (Utility kwh) and M (IT Equipment kwh) allow for the calculation of the PUE data center metric. If possible, in order to improve accuracy of tracking on a per rack or device level basis, the data center operator may also track the remaining measurement points. It is noted, that this is a large undertaking, particularly in older sites with a variety of monitoring systems. Retrofitting an existing data center may require a large investment in instrumentation, as well as data acquisition and reporting software. Hardware and software-based equipment power monitoring techniques (M & M) are evolving rapidly and becoming more cost effective. Deployment of software monitoring systems, where the hardware systems have the APIs needed to provide the data to the software system, can offer an efficient way to track IT energy use by customer account. Data Center Capacity It is common for data center capacity to be sold based either on provisioned circuit power (kw) or on physical floor space provided (square meters or square feet). By way of comparison, in commercial buildings, the square foot (SF) or square meter (SM) is the basic unit of provision for capacity management, and demand for additional SF/SM drives takedown of additional capacity. Key metrics for commercial buildings are cost per SF/SM and SF/SM per person, as well as a variety of other metrics depending upon the particular business use of the building. In the data center industry, the common unit for measuring capacity is kilowatts. Secondary units, such as capacity in terms of racks or SF/SM are also in use throughout the industry, but are easily converted back to kilowatts from a per unit basis. The industry is currently gravitating towards a kilowatts unit basis for capacity management, and for ease of calculation, this guidance recommends conversion to a kilowatt unit for analysis of each site. The data center will typically be designed to a specification of maximum power provision, with the infrastructure equipment and cooling capability being designed for this maximum power. It is therefore page

16 appropriate to use the data center capacity as a key method for allocating fixed emissions such as overheads. In other words, a particular site may be designed to provide 0,000 kw of capacity for ICT equipment. Thus, the fixed emissions of the site can be allocated based upon the share of total kilowatts of capacity that are provided by the particular site. Data Center Capacity Example The diagram shown in Figure is intended to represent an example of a data center physical layout, in order to provide a better understanding of data center capacity and its allocation to specific IT devices. 0 Figure : Example data center physical layout Key for Figure : Colo : Colocation CRAC: Computer Room Air Conditioning PDU: RPP: Power Distribution Unit Remote Power Panel In a typical colocation data center, IT equipment is hosted in a physical room, or multiple rooms, with adequate power and cooling to support reliable site operations. The above floor plan is a data center showing one room (Colo) for IT equipment, served by electrical and mechanical equipment, with.mw of useable capacity, backed by a UPS with nominal capacity at output to the IT equipment room of.mw. page

17 It is recommended to track capacity within each IT equipment room (colo above) and determine the capacity of power provisioned for each rack in the room. A typical data center may have a variety of rack types with different numbers of circuits deployed to each, and thus each rack may be tracked individually. 0 Identifying IT Equipment Ownership - ITAM Inventory IT asset management (ITAM) systems are used by data center owners to track ownership of equipment hosted in their data centers. ITAM inventories are required for various business reasons, such as property tax reporting and accordingly are subject to quality controls and should include all IT equipment installed, and in particular, all assets plugged into power sources at the site, with ownership by specific business division or owning organization, purchase information and application/service usage. An exception to the use of ITAM inventories would be for a data center provider selling wholesale data center space (i.e. caged or rooms of raw data center space). In this case, the wholesale provider would track the total kw of useable capacity, whether metered or unmetered for each customer. In this circumstance, the lessee would maintain an inventory of its assets. To establish emissions, the asset inventory data should be correlated to installed racks/circuits and allocated to all respectively owned asset equipment Allocation This section describes the allocation of emissions of data centers, networks and end-user devices... Allocation of Data Center emissions Choice of allocation method Methods used to allocate data center emissions vary in difficulty of implementation or applicability to the business need, depending on the type and complexity of the data center, what data is easily available and the type of service being assessed. Each company should choose a method that meets their business needs, and the allocation methodologies in this section are presented as best practices that may or may not be applicable to the needs of a particular company. Each company will need to determine the method to be utilized based upon cost or expediency; it is recommended to establish a practice and adhere to this practice for the entire data center GHG inventory. If a combination of methods is used (for example, due to equipment age) then this should be justified and documented. Completeness principle The calculation of GHG emissions due to cloud and data center services involves allocating the emissions of the data center to the specific service being assessed. As described in section. Overview of Method the completeness principle should be adhered to i.e. all of the emissions of the data center should be allocated to the services that the data center delivers to its customers. Fixed and variable emissions The other concept introduced in section. is that of fixed and variable emissions for a data center, and that different allocation methods are appropriate for fixed and variable emissions. Therefore it is recommended that, to the extent to which it is practical, the emissions are separated out into fixed and variable. Given the difficulty inherent in separating the fixed energy overhead, most practical allocation regimes must understand their inherent error margin when determining the method and reporting precision so as not to create a false impression of accuracy. page

18 The fixed emissions include the embodied emissions of the data center and equipment, the fixed part of the data center overhead energy and the fixed energy consumption of the IT devices. It is recommended that the fixed emissions are allocated based on data center capacity (defined in section..), while the variable emissions are allocated based on the IT device electrical power consumed. Steps for allocating data center emissions The following diagram (Figure, repeated from section..) summarizes the preferred allocation steps for a data center. Data Center IT Devices Virtual Machines Services Users Fixed Emissions Allocated kw Fixed Emissions Allocated Capacity Virtual Machine Service User Variable Emissions Drawn kwh Variable Emissions Utilised Capacity Other Virtual Machines Other Services Other Users Figure : Allocation steps Step. Allocate the data center fixed emissions to IT devices Fixed emissions include: embodied emissions of the data center and equipment the part of the data center emissions that does not vary with IT electrical load Whilst a full determination of the fixed emissions of the data center can be complex operators may identify parts of or estimate their full fixed emissions via some simple methods, for example: Observing the fixed energy consumption with all major infrastructure equipment operating during a commissioning test at zero IT load, whilst this is temperature dependent it forms a reasonable basis for estimation Performing a regression analysis of the utility power against IT power across a suitable range of readings, again subject to temperature but can be a reasonable basis for estimation Utilizing sub-metering of infrastructure loads and identifying those which are not related to IT energy consumption and subtracting those loads from the overhead applied to the IT load, these fixed loads might include: i. generator and fuel tank heaters, ice melt systems ii. gas consumed by heating boilers iii. diesel or other fuels consumed in generator load testing iv. lighting loads v. Support areas, monitoring and BMS systems, security systems vi. office space outlets, lighting and air conditioning vii. make-up air handling units and associated humidity controls In terms of the familiar PUE equation this separation may be expressed as; page

19 Once a method has been chosen to estimate the fixed part of the in-use emissions of the data center the fixed and variable emissions for the allocation period may be separated by: The fixed emissions of the data center should be allocated based on the data center capacity that has been provisioned. The allocation factor thus is: Thus the fixed emissions allocated to an IT device, group of devices or electrical load is: 0 Where capacity provisioned n is the data center capacity provisioned to the identified device or group of devices. The total capacity provisioned total is the sum of all the capacity provisioned for the data center, not the design or rated capacity of the data center. This is to ensure that all the emissions of the data center are allocated to services delivered by the data center and none are absorbed by the data center operator. Capacity is commonly measured in kilowatts. However, if it is measured in other units, such as number of racks or floor area, then it should be converted to kw prior to allocation of emissions. Table gives an example of this conversion from floor area in square feet (SF) to kw. The total SF and kw capacity are known; from these a Watts per SF factor can be calculated. The Watts per SF factor is then multiplied by the SF provisioned to a specific organization to calculate the kw capacity provisioned to the organization. Table : Conversion SF to kw DC Total Useable SF UPS Output Capacity (kw) Watts per SF Org # provisioned SF Site, Site, Org # provisioned kw 0 Step. Allocate the data center variable emissions to IT devices Variable emissions include: the remainder of the data center overhead not already allocated in the fixed emissions step the variable energy consumption of the IT devices The variable emissions of the data center should be allocated based on the metered energy consumed by the relevant IT devices during the time period being assessed. The allocation factor thus is: page

20 Thus the allocated variable emissions to an IT device, group of devices or electrical load is: Where detailed energy metering is not available, then an alternative estimation approach may be based at the simplest level on the number of physical servers dedicated to the service. 0 Step. Allocate the IT device fixed emissions to virtual machines (where these are being used) Where the service is running on virtual machines (VMs), then the emissions need to be allocated based on a parameter of the virtual machines. It is likely that an operator may have a large homogeneous group of physical machines and these may be treated as a single large IT device. At the IT device level, part of the IT energy consumption may be considered to be fixed, this may be estimated based on the zero load power draw of the machines as a fraction of the average power draw of the machines over the allocation interval: 0 Where the operator is unable to estimate the fixed proportion of the IT device(s) energy consumption then the idle power should be considered to be zero and the fixed emissions are simply those calculated for the IT device(s). To allocate the fixed emissions to the individual virtual machines either a simple division by the number of virtual machines in each period on the physical machine(s) or a weighted division which takes into account physical resource allocation may be used. The intent is to capture an additional part of the IT allocated variable energy as fixed consumption by the IT device. Step. Other allocation methods for VMs are described in the Software chapter. Allocate the IT device variable emissions to virtual machines (where these are being used) The variable emissions part of the VM emissions is simply the IT allocated emissions minus those already allocated to the fixed VM emissions: 0 Again, where the operator is unable to estimate the fixed proportion of the IT device(s) energy consumption then the idle power should be considered to be zero and the variable emissions are simply those calculated for the IT device(s). Again, to allocate the total VM variable emissions individual virtual machines this may be done either by by simple division of the number of VMs or by a weighted division which takes into account some aspect of the load each VM presented to the physical host during the allocation period: page 0

21 Step. Allocate IT device emissions (or VM emissions) to services It is increasingly common for IT services to share physical IT devices and infrastructure. In this case the emissions allocated to each device need to be calculated and summed as follows: 0 0 Step. Where is the allocation factor of the services for the IT device, and is the emissions for the IT device or virtual machine. (The allocation factor in this case represents the usage of the device or virtual machine, using some appropriate physical metric such as cpu usage or memory usage). Allocate service emissions to the individual users In the case where a service is used by more than one user, such as , the service emissions should be allocated across the users based on a representative measure. A suitable method of allocating the service capacity and utilization across the users should be selected and described. This may well be based on the billing structure of the service for ease of use and transparency. Examples of the allocation might be: Bandwidth for streaming services Bytes available for storage and Bytes transferred for storage services Mailbox size for Where the data center has a highly homogeneous environment and the data center provides a set of similar services which may not have any dedicated IT equipment, then it may be appropriate to bypass the allocation of emissions to IT equipment and services and simply allocate the data center emissions based upon service utilization. 0.. Allocating Equipment to Cloud Services Private clouds have defined infrastructure operated solely for a given organization or service. In instances of private cloud, it may be possible to identify and measure specific storage and networking devices that support specific cloud services, in which case the allocation method outlined above can be followed. However, more often, public and private cloud services are run using virtual machines (VM) located in multiple data centers. In turn, the data centers may support other services and be at varying degrees of fitout / loading. It is therefore a challenge to allocate specific ICT equipment and emissions associated with electrical and mechanical services to cloud services. When it is not possible to identify specific hardware and equipment to a cloud service, then a more simplified approach may be appropriate using estimates of suitable parameters that reflect the underlying allocation. Simplified parameters that may be used for allocation of Data Center emissions: Estimated count of physical servers dedicated to the service (divided by the total number of servers in the data center) Estimated count of virtual machines dedicated to the service (divided by the total number of virtual machines on the fabric hosting them) Parameter that reflects the IT resource usage by the service, for example: Iops (input-output operations per second) over a specified period of time WebAPIs (i.e. number of web request/responses) over a specified period of time page

22 Processing time, processor type, number of instances or Storage requirements in Mbytes.. Allocating Equipment to Data Center Services Data center services can be Wholesale or Colocation services (see section..); depending on the type of lease different information may be available for the calculation of the GHG emissions. In instances where it is possible to identify and measure specific IT devices that support the specific data center services, then the allocation method outlined above can be followed. When it is not possible to identify specific hardware and equipment to a data center service, then a more simplified approach may be appropriate using estimates of suitable parameters that reflect the underlying allocation. Simplified methods that may be used for allocation of Data Center emissions: Count of servers Allocate the total data center emissions using the ratio of the number of servers used for the service divided by the total number of servers at the data center site Provisioned data center capacity Determine the provisioned kw capacity for each device and allocate the total data center emissions using the ratio of provisioned kw capacity used for the service divided by the total provisioned kw capacity. Sample power readings Measure the power consumption of all IT devices while under load, sampling at different times. Average the samples for each device, then allocate the total data center emissions using the ratio of the average sample power for the IT devices used by the service divided by the average sample power for all the IT devices in the data center Note that device power consumption may vary significantly, which reduces the value of this method Manufacturer s power rating This is similar to the previous method, except using manufacturer s power ratings for the IT devices, ideally adjusting by actual usage of the equipment. Metered energy readings This method requires metering of the energy used by each IT device. The total data center emissions are then allocated using the ratio of the energy used by the relevant IT devices over the time period being considered divided by the data center s total energy consumption for the same time period... Allocation of Network emissions Allocation of emissions due to network equipment within the data center should be automatically included within the method for allocating the data center emissions, described above in section.. (Allocation of Data Center emissions), provided that the network devices are allocated to the cloud or data center services that are being assessed. For the emissions of networks external to the data center (e.g. WAN, internet, LAN at end-user premises) then the emissions of the relevant network can be allocated to the service, based on one of the following parameters: Number of ports Data traffic page

23 Provisioned bandwidth For further details of calculating and allocating network emissions, see the Telecommunications Network Services chapter... Allocation of End-user device emissions End-user devices (e.g. laptops, desktops, mobile devices) may be dedicated to a particular service, but are more likely to be shared in use between different services. Allocation of the emissions of end-user devices can be done based on actual time used by the service, or on some appropriate resource usage relevant to the service (e.g. percentage cpu used), or metered energy usage by the service Calculating Inventory Results.. Overview of Calculation Methodology for Cloud Services The emissions of a cloud service are calculated by summing the total emissions of the service for the time period being considered, then dividing by the appropriate parameter for the functional unit being measured. The primary variables that drive emissions from cloud services are number and location of servers, the associated data center operations, the equipment that transfers data across the network, and the end-user equipment. The emissions of the service are derived by dividing the sum of the emissions associated with these processes by the relevant parameter for the functional unit being measured. See section. (Functional Unit) for discussion of different functional units. The following are examples of calculations for different functional units: Emissions per user = (Total Emissions of the service (Data center + Network + Equipment)) / (Number of Active Users) or Emissions per transaction = (Total Emissions of the service (Data center + Network + Equipment)) / ( transaction count) or Emissions per unit of storage (GB) = (Total Emissions of the service (Data center + Network + Equipment)) / (Storage Capacity (GB))) 0 0 The following data is required for the denominators in the examples above for the different functional units: Active Users A median number of active users should be determined over a specified time period; or alternatively calculations performed on the average maximum number of users the service is sized for over a specified time period. Transaction Count Transaction count is the sum of the number Iops or WebAPIs for a given service over a defined period of time. Storage Capacity Provisioned storage capacity should be used as the denominator, rather than actively used storage capacity. page

24 0 0 0 Due to temporal variations in the number of users, transactions performed or storage capacity provided, and the associated equipment utilization, a sufficiently long time period should be specified for data collection to allow a representative average emission intensity to be calculated. For example, the time period specified may be a month or a year... Calculating Data Center Emissions The primary variables that drive emissions from data center services are number of servers and the efficiency and location of the associated data center operations. Two alternative methods are available to calculate the emissions of the data center services. The advantages and disadvantages of each method are provided below in Table and assumptions should be detailed in support of any calculations performed, together with a list of potential sources of error. Method (bottom up): This method requires identification of specific equipment associated with the service, and measuring the energy use of this equipment. It can be used where it is not practical to get the total emissions of the data center. Data Center Emissions of service = (((No. Servers Energy Use of Servers) + (Network Link Equipment Energy Use of Network Link Equipment)) PUE Electricity Emission Factor) + embodied emissions of IT devices + allocation of embodied emissions of data center overhead Where the servers, network equipment and IT devices are those allocated to the service. Or Method (top down): This method allocates the total Data Center emissions using an appropriate allocation method (see section.. Allocation of Data Center emissions for discussion of allocation methods). Ideally this method would allocate separately the fixed and variable emissions of the data center. Data Center Emissions of service = Total Data Center Emissions x Allocation Factor For example, a simple allocation factor would be: (Number of servers allocated to service) / (Total number of servers) The total number of servers should also include actual or assumed backup servers including redundant storage and network drives, and networking link equipment. This backup equipment may be in different physical locations. Network link equipment is assumed to be the routers, switches and other associated equipment within the data center used to fulfill requests, and process web transactions. Network equipment associated with internet transfer is considered later. page

25 Table : Application of alternative methods for calculating data center emissions Method Application Advantages Disadvantages Bottom up Top down Where dedicated servers and network link equipment for hosting and fulfillment of cloud services can be identified. Where total data center emissions are not known. Where cloud applications are hosted across a virtualized shared pool of servers and network link equipment. Accurate use profiles can be ascertained and monitoring techniques can be applied to equipment to track electricity consumption (see section. for discussion on monitoring techniques). Allows a user to capture the relative benefits of software for server power management Simple top-down approach that provides an approximation of emissions. Captures all the energy use for a data center avoiding any leakage. Can also account for fixed and variable emissions. PUE assumption has to be applied to model share of non-it data center emissions. Requires a detailed accounting of devices and their nominal power consumption. Does not necessarily account for all the data center emissions. The specific use profile of the cloud application and equipment is not modeled. Shared use of data center network link equipment is assumed to be a similar ratio to servers. The specification of servers hosting the cloud applications are not considered. To account for temporal variations server and network link equipment should be tracked at a frequency for the data to be representative (e.g. weekly or monthly) for the duration of the time period defined for the study... Calculating Network Emissions Network emissions (external to the data center) should be calculated using the methods provided in the Telecommunications Network Services Chapter: Data required for the calculation includes: 0 Electricity consumed by access technologies Internet backbone electricity consumption Transfer rate Transmission Time The overall calculation method is as follows: kwh/gb kwh/gb GB/min; Mbit/s minutes or seconds 0 Internet Emissions per Unit of Data Transferred = ((Internet Backbone Electricity + Access Technologies Electricity) Data Transfer Rate Transmission Time) Emission Factor Electricity consumed by access and internet backbone equipment may be calculated based on either metered data for that equipment, or by applying an assumed utilization rate to the equipment s power rating. This can then be multiplied by the assumed number of intermediate devices (or internet hops) the data passes through to its destination. Transfer emissions per unit of data transferred can be aggregated to a per-user or per-license level by multiplying it by a typical profile for a user or licensee. page

26 Calculating End-user-Device Use Where the GHG assessment is comparing a cloud service with an equivalent non-cloud service, and where there is no significant difference between the profile of end-user devices used to access the services, then the end-user devices may be considered to be equivalent, and therefore could be excluded from the analysis. If, however, the cloud service results in a shift towards a different end-user-device profile, such as away from PC s towards more thin clients or mobile devices, or if the use profile of the service changes significantly, then end-user-devices should be included in the analysis. In this circumstance, a survey to determine the mix of end-user-devices should be undertaken and their energy consumption and emissions estimated. Guidance on calculating the emissions associated with the use of end-user devices is provided in the Hardware chapter of this Guidance Document... Calculating Embodied Emissions The method for calculating embodied emissions of the ICT equipment is provided in the Hardware chapter of this Guidance Document. In studies undertaken to date, the embodied emissions associated with non-use stage (i.e. material acquisition and pre-processing, production, equipment distribution and storage, and end-of-life) emissions are typically a small component of the overall emissions burden of cloud services. A number of studies have been undertaken by equipment manufacturers and academic institutions to provide credible approximations of embodied emissions, which may be used as secondary data for the purposes of expediting studies, if manufacturers of the equipment are unable to provide primary data... Example Case Study of Cloud Service Case Study: Microsoft Cloud Services Scope and business goals for footprinting these services As part of their move into the cloud computing market, Microsoft has studied the provision of a number of their business applications - Microsoft Exchange, Microsoft SharePoint and Microsoft Dynamics CRM via the cloud to understand whether the cloud is a greener computing alternative. Microsoft aimed to test potential efficiency benefits that cloud offers, including dynamic provisioning, improved server utilization, private versus multi-tenant architecture, and data center efficiency (i.e. PUE) through larger state-of the art facilities. Functional Unit Quantity: The use-profile varies somewhat between each Microsoft application studied; however, they are all generally characterized by high data storage requirements and high user access. As a result a per-user unit of analysis is determined to be the most representative way to characterize the functional unit and three different sizes of organization (small (00 users), medium (,000 users) and large (0,000 users)) are modeled. Cloud Computing and Sustainability: The Environmental Benefits of Moving to the Cloud. Accenture & WSP. November 00. see press release at and download whitepaper at page

27 Duration: To reflect changing use profiles over time data for a full year is modeled so that an average emission rate per-user can be determined. Quality: The standard Microsoft business applications were modeled. Defining Boundaries The study focuses on North American and European regions, and specific data centers are identified and network assumptions made for internet transmission between locations. Processes attributable to the analysis are identified as the operational energy consumption and embodied emissions of the ICT equipment directly used for hosting, fulfilling and internet transmission of the services, and indirect energy consumed by the data centers hosting the equipment. Non-attributable processes include: the embodied emissions of the non-ict equipment and data center facility; water used for cooling (although a Water Use Efficiency measure could be applied to incorporate the life cycle impacts of water consumed). Allocating equipment to the service Cloud services are hosted in multiple data center locations in a VM environment. An allocation of equipment to the services therefore has to be calculated based on the application demand. Sales records are used to ascertain how many seats (i.e. users) are in use over the course of a month period and averaged for the period. Provisioned seats were higher than active seats and used for calculations to ensure the full extent of ICT equipment was captured in calculations. To determine ICT equipment utilization, the number of users is correlated to the average storage and compute profile per user to determine the effective storage and compute capacity requirements. Ratios are applied to account for virtualization efficiencies and for redundant equipment that accommodates duplicate files/ back-up and recovery systems. Use profiles are also used to estimate the volume of data transmitted across the internet and to allocate network-link equipment (i.e. switches and routers) within the data center. An average server specification is developed per application to determine the energy draw per server based on observed server utilization and data center location. Wherever possible, application specific customers, users and active seats are paired to specific server allocations and data center locations so that the number of internet hops could be approximated for the user base. Data Collection and Data Quality Primary data is collected on users and server counts correlated to application demand in specific data center locations, including redundant recovery and back-up systems. Measured PUE ratios are also used for each data center. Secondary data from industry databases and leading research is used to estimate the emissions arising from internet transfer and non-use stages of the equipment life cycle. Calculating Emissions Total emissions arising are calculated by applying emission factors to energy consumed by the allocated equipment at each data center location and summing them with internet transfer emissions. The total emissions arising is then divided by the number of users to derive an emissions ratio of Total kg CO e per user... Example Calculations for Data Center Services The following provides three examples, illustrating different methods for calculating emissions of data center services, with different types of data center, services and metrics available. These examples are intended to demonstrate the different allocation methodologies that may be used. page

28 Example : Data Center Service/Hosting Provider Site Inventory The first example illustrates four sites, each with specific information regarding type of metering available, for a data center hosting provider (see Table ). In this example, the data center provider leases parts of the data center capacity to different customers, as in a typical colocation environment. The method for calculating the emissions for each customer (lessee) is shown below for each of the four sites, and is dependent on the type of metering available. Method - Site A with rack metering: Where all the data is measured annually, and the kwh consumed by all the IT equipment for the whole site. is the annual energy in 0 Method Site B, No rack metering, leased by breaker/circuit capacity: The data is again measured annually, and the is the circuit capacity in kw. If a customer leases capacity for only part of a full year, or the capacity leased varies during the year, then the capacity should be prorated (e.g. on a monthly basis). Method Site C, No rack metering, leased by SF: The data is again measured annually, and the is the provisioned capacity in SF (square feet). If a customer leases capacity for only part of a full year, or the capacity leased varies during the year, then the capacity should be prorated (e.g. on a monthly basis). Method Site D, No rack metering, leased by rack: In this method the data center emissions are allocated using the IT device power ratings. 0 The data is again measured annually, and the is the sum of the power ratings for all the customer (or site) IT devices. Again, as the number of IT devices will vary over the year, it is recommended to track this at a monthly level and pro rata for the full year. Table : Hosting Provider Site Inventory Site Name Construction emissions (tco e) amortized annually Annual emissions (tco e) during operations Total annual emissions (tco e) Lessee metering installed Allocation factor for emissions Site A,000,00,00 Per Rack (Rack metered energy for customer) / (rack metered energy for site) Site B Unknown 0,000 0,000 None leased by breaker capacity Site C Unknown,000,000 None leased by SF Site D Unknown,000,000 None leased by rack (Leased circuit capacity for customer) / (Leased circuit capacity for site) (Leased SF capacity for customer) / (Leased SF capacity for site) (sum of the power ratings for all the customer IT devices) / (sum of the power ratings for all the site IT devices) page

29 Example : Company Data Center Portfolio Site Inventory This next example, given in Table, shows three data center sites used by a company, within its portfolio of data center sites. Each site is different in terms of services or applications hosted at the site, what metering is installed, and the type of data center (i.e. owned or leased). Site DC hosts IT equipment for a cloud service application sold to customers of the company. The company wants to calculate the emissions by business division (or organization) within the company. The methods to do this for each site are as follows: Method - Site DC with rack metering, fully owned and operated by company: 0 The is the annual energy in kwh consumed by all the IT equipment allocated to the specific organization (or business division) and the is the annual energy in kwh consumed by all the IT equipment for the whole site. Method Site DC, No rack metering, leased by breaker/circuit capacity, PUE unknown 0 Where: is the circuit capacity in kw provided by organization. is the total hours in the year that the IT equipment is used by the organization. is the electricity Emission Factor (measured in kg CO e / kwh) Note: In this case, neither the total site emissions, nor the site PUE factor are known, thus this method has a high degree of uncertainty. Either an estimation for the PUE factor should be used (and stated what assumption is used), or it should be clearly stated that the PUE factor is being ignored (i.e. PUE assumed equal to ). Method Site DC, Rack metering, PUE reported by lessor: In this case, the organization emissions are those for hosting the cloud service app. Where: is the annual energy in kwh consumed by all the IT equipment allocated to hosting the cloud service app. is the Power Usage Effectiveness ratio as reported by the lessor. is the electricity Emission Factor (measured in kg CO e / kwh) Table : Company Site Inventory Site Name DC DC DC Type PUE Construction emissions (tco e) amortized annually Fully owned Leased colocation Leased colocation Annual emissions (tco e) during operations Total annual emissions (tco e) Metering installed Use.,000,00,00 Per Rack Internal use only, no services sold externally, IT equipment tracked by business division Unknown Unknown Unknown Unknown None leased by breaker capacity Internal, IT equipment tracked by business division. unknown Unknown Unknown Per Rack Cloud Service App Per Organization emissions calculation (Rack metered energy for org) / (rack metered energy for site) * total site emissions provisioned circuit capacity per org * annual hours * EF Rack metered energy of cloud service * PUE * EF page

30 0 Example : Customer / Service Application Inventory This example shows the inventory of IT devices, provisioned power and estimated energy correlated against specific data center services. This matching of IT devices to specific services allows the provisioned power for the IT devices to be allocated to the services. The provisioned power can then be used to allocate the total data center energy to specific services. Following are two examples of asset ownership inventory: the first example, given in Table, shows a single data center with multiple asset owners, and the second, given in Table, shows a single service application hosted across multiple data center sites. In the first example (shown in Table ) the provisioned power is used as the factor for allocating the energy and cooling kwh of the data center to the different services. In the second example (shown in Table ) the provisioned power is assumed to be the actual power used, with the equipment running hours per day, thus the daily energy used is calculated as x provisioned power. Table : Data center Asset Owner Inventory single site, allocation by provisioned capacity Location Colo Colo Colo Colo Colo Colo Service Owner Service App Servers Network Devices Drive Bays Other IT Devices Provisioned Power (kw) Estimated Energy & Cooling (kwh per day) Human Resources Benefits Messaging Service Messaging Service Cloud Service Cloud Service Data Center Services Messaging - Partner Service Messaging - Core Cloud Service - App # Cloud Service - App # EPMS System Operations Colo Networking Network Table : Service Application Equipment Inventory all IT equipment owned by a single service application across multiple sites Site Name Servers Drive Bays Network Devices Other IT Devices Provisioned Power (watts) DC DC DC TOTAL Estimated Total energy (kwh per day) page 0