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 0 March 0
Table of Contents Guide for assessing GHG emissions of Cloud Computing and Data Center Services.... Introduction..... Goal of this Chapter of the Guidance..... Business Purpose / Reasons for footprinting this Service.... Unit of Analysis, Functional Unit and Reference Flow..... Cloud Services..... Data Center Services.... Boundary Setting..... Defining Boundaries..... Attributable Processes..... Non-attributable Processes..... Temporal Considerations.... Allocation..... Allocating Equipment and Infrastructure to Cloud Services..... Allocating Equipment and Infrastructure to Data Center Services... 0.. Identifying IT Equipment Ownership - ITAM Inventory.... Data Collection and Data Quality.... Calculating Inventory Results..... Overview of Calculation Methodology for Cloud Services..... Estimating Data Center Emissions..... Estimating Network Emissions..... Estimating End-Use-Device Use..... Estimating Life Cycle Emissions..... Calculating Cloud Service Efficiency..... Overview of Calculation Methodology for Data Center Services... page
[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. This is a DRAFT chapter and is still subject to further review and changes. All chapters have been drafted separately by Technical Working Group members, and then reviewed by the TWG and the Steering Committee; however they have not yet been fully reviewed and edited by the convening secretariat. In particular, consolidation and rationalisation with other chapters of the ICT Sector Guidance is still to be reviewed and completed. Use of terminology and methodology also still needs to be reviewed for conformance with the Product Standard. The ICT Sector Guidance consists of the following chapters: Introduction; Telecommunications Network Services; Desktop Managed Services; Transport Substitution; Cloud and Data Center Services. Plus technical support chapters covering: Hardware; Software; Data Centers. 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: http://www.ghgprotocol.org/feature/ghg-protocol-product-life-cycle-accounting-and-reportingstandard-ict-sector-guidance 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
0 0 0. Introduction.. Goal of this Chapter of the Guidance A range of business and consumer applications are increasingly provided from cloud architecture: E-mail, calendar, document and other business applications. Consumer photo, video and music and other data storage applications. Search, social networking and database applications. 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 Purpose / Reasons for footprinting this Service 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. 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. This guidance allows cloud and data center service providers and customers to benchmark 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-use 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. Cloud services can be broadly categorised by the level of operational control the user has: Infrastructure as a Service (IaaS): Access to a virtual server and a storage pool with full access to the server s operating system and to the applications that are running on it. Platform as a Service (PaaS): Platforms for running web-based applications. PaaS clouds do not provide access to the underlying operating system. Software as a Service (SaaS): Enables commercial SaaS applications in a hosted environment. 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. NIST Special Publication 00- The NIST Definition of Cloud Computing September 0 NIST Special Publication 00- The NIST Definition of Cloud Computing September 0 page
0 0 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 use devices (or client ); including computers, smart phones and other devices used for accessing cloud services The chapter draws from the standard methods outlined in the Data Center; Telecommunication Network Services and; ICT Equipment and Hardware sections of this guidance document, which prescribe the methods for calculating the life cycle impacts of the various component parts of the infrastructure that support a cloud service.. Unit of Analysis, Functional Unit and Reference Flow.. Cloud Services Cloud services are procured in different ways, for example on a per-user basis over a period of time (e.g. per-day or per-year); or by storage capacity (e.g. GB of data stored). 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 of efficiency 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) E-mail, 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 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 licence, or service level agreement. page
0 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 of analysis should be defined with a high degree of specificity 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... Data Center Services Energy Consumption Unit of Analysis Kilowatt hours (kwh) is the unit of analysis utilized for tracking of energy use throughout a data center site. Functionally, for an accurate accounting of energy use throughout the site, the flow chart shown in Figure can be used as a reference: 0 Figure : Flow chart of energy use throughout a site Tracking of kwh is required at both measurement points M (Utility kwh) and M (IT Equipment kwh) at a minimum. These points form the basis for tracking PUE data center efficiency. If possible, in order to improve accuracy of tracking on a per rack or device level basis, the data center operator should invest in tracking the remaining measurement points; however 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. Capacity Allocation Unit of Analysis Kilowatts (kw) are the unit of analysis utilized for tracking functional capacity of a data center site. In commercial buildings, the square foot (SF) or square meter (SM) is the basic unit of allocation for capacity management, and demand for additional SF/SM drives takedown of additional capacity. Key metrics tracked page
0 in this model 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 database industry, the common denominator of all capacity units is kilowatts. Secondary units, such as capacity in terms racks or SF/SM are also in use throughout the industry, but are easily converted back to total 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. Kilowatts can be utilized to determine emissions attributable to all phases of the data center lifecycle, as the focus of providing data center capacity in kilowatts is the foundation of all uses of a data center. In other words, a particular site may be designed to provide 0,000 kw of capacity for ICT equipment. Thus, the embedded emissions during design and build of the site, and during use of the site, as well as demolition of the site, can all be allocated based upon the total kilowatts of capacity that are provided by the particular site. Data center Capacity Units - Reference Diagram The diagram shown in Figure is intended to represent a typical data center physical layout, in order to provide a better understanding of capacity allocation and accounting for use of capacity. 0 Figure : Typical data center physical layout 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 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. The data center operator will typically downgrade the UPS capacity when considering the amount of capacity to be allocated to IT equipment, in order to account for distribution losses, and in this example a 0% reduction from UPS output capacity is determined (Useable Capacity = UPS Nominal Capacity*0.). page
0 0 It is required to also track capacity within each IT equipment room (colo above) and determine the kw of power provided to 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 each rack will need to be tracked individually. As discussed in section. Unit of Analysis, Functional Unit and Reference Flow, for an extremely accurate inventory, kwh can be tracked at the rack level through implementation of branch circuit monitoring, or at the device level by tracking direct use at each individual power cord. However, this may be cost-prohibitive or instrumentation may not be installed at each site in a data center portfolio. Therefore, at a minimum, tracking the capacity in kw for each colocation, and at each rack, is required in order to properly allocate emissions to the many uses of IT equipment at the site. Today, there are many types of data centers, including container or containment data centers, and it is required to determine the amount of useable kw capacity for IT equipment, and document the assumptions behind that capacity in order to provide a valid accounting of emissions.. Boundary Setting.. Defining Boundaries Cloud services generate a demand for energy in three primary places: Data centers: switches, routers and servers 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-use 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 page
0 0 0 0.. Attributable Processes Processes directly attributable to calculating the impact of cloud services are: Hosting and fulfilment of the cloud applications including servers, other IT equipment, critical systems and associated data center facilities including HVAC systems required for server cooling. Internet transfer. User access. Energy, water and refrigerants consumed by the above processes throughout their life cycle... Non-attributable Processes Processes that are not attributable to calculating the impact of cloud services are: Critical systems, other equipment and maintenance activities associated with telecommunication service-provider facilities. 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 fulfilment of the cloud service and associated equipment. Maintenance of capital equipment. End-use devices, unless migration to cloud services results in a significant shift in user access devices... Temporal Considerations The functional units associated with cloud services are either bound by a time period, or defined by an instance of a transaction. As a result, amortization of non-use phase impacts should be considered during the attribution of embodied emissions to a cloud service. Typically embodied energy in end-use devices, network and data center IT equipment should be amortized over a year period; critical data center systems over year period and data center non-critical systems and buildings over a year period. Whatever assumptions are used for amortizing equipment, they should be clearly stated in supporting documentation.. Allocation.. Allocating Equipment and Infrastructure 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. 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 fit-out / loading. It is therefore a challenge to allocate specific ICT equipment and emissions associated electrical and mechanical services to cloud services. When it is not possible to identify specific hardware and equipment to a cloud service; the following steps are required to define and allocate equipment cloud services: Establish the application demand in relation to physical resource requirements, such as Iops (inputoutput operations per second) or WebAPIs (i.e. number of web request/responses) over a specified period of time Match application demand with IT hardware requirements for core hosting and fulfilment processes Estimate data center, network infrastructure and end use device energy consumption Considerations for each of these steps are outlined in Figure below. page
0 Figure : Steps for establishing an inventory of equipment associated with cloud services Once an inventory of equipment and its location has been developed, primary and secondary data associated with its use-phase and life cycle impacts should be gathered... Allocating Equipment and Infrastructure to Data Center Services In a co-location data center, or data center in a mixed-use facility, methods used to allocate emissions vary in difficulty of implementation or applicability to the business need. Each company should choose a method that meets their business needs, and the calculation methodologies listed herein are presented as best practices that may or may not be applicable to the needs of a particular company. Conversion Methodology SF/SM to kw Prior to calculating emissions for each site, it is recommended to normalize against kw. Each site in a company portfolio can easily be converted to kw units for capacity using this method. This method simply calculates the total available watts per SF/SM which can then be used to calculate kw allocated to each organization utilizing the capacity at the site, as shown in Table below: Table : Conversion SF/SM to KW DC Total Useable SF UPS Output Capacity (kw) Watts per SF Org # Allocated SF Site,00 00 00 000 00 Site,000 00 00 000 00 Org # Allocated kw Allocation Method KW Allocation Method In this practice, once emissions are collected for each Data center, the useable KW (available for hosting ICT infrastructure) allocated to the organization is tracked as a percentage of the total useable KW for page 0
0 determination of emissions allocation. This practice requires the company to track the device power requirements for all installed ICT infrastructure and allocate circuits based upon these requirements. There are several methods for determining the device power requirements for ICT infrastructure, and these vary in complexity as well. For example, one simple method which could be utilized is simply to take a count of the physical servers installed at a particular site, divide into the peak kw used in a given month, and determine a watts per server metric to be used as the basis for device power allocation. A more complex method would be to test the utilization of a particular device type, such as a specific server model, with a clamp-on meter applied to the power cord, and then track a device rating of typical power use for each type of device. A third method would be to track the manufacturer equipment rating, and adjust by actual usage of the equipment. Each company will need to determine the method to be utilized based upon cost or expediency; however the requirement is to establish a practice and adhere to this practice across the entire data center footprint in the GHG inventory. If a combination of methods is used due to equipment age, this is required to be documented. Need a reference to Table below: Table : Useable KW Allocation by Organization Site Name Total Useable kw Org # Allocated kw Org # Allocated kw Available kw DC,000,000,000,000 DC,000 0,000,00 DC,000,000 0 0 0 0 Allocation Method kwh Metering Method In this practice, power metering and data collection for all devices hosted for each organization is required. As illustrated in section A.., metering in any particular data center could be installed at various points throughout the site, and in practice there is great variance in the existing installed base of data center sites. In order to establish a valid inventory, it is required to document metering and kwh data collection points at each site and determine whether a combination of kwh data and estimated data based upon allocated kw will be utilized for each site... Identifying IT Equipment Ownership - ITAM Inventory All organizations tracking data center emissions are required to have in place a quality IT asset management system, tracking asset ownership of all physical assets hosted at each site. In addition, a data quality program to ensure asset accuracy must be in place. This asset inventory must 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. Asset management inventories are required for many other business reasons, such as property tax reporting. Accordingly, these inventories are likely to already be installed at the majority of companies. The only exception would be the case of a data center provider selling wholesale data center space (caged or rooms of raw data center space). In this exception, the wholesale provider must track the total kw of useable capacity, and whether metered or unmetered for each customer. The customer leasing the physical capacity for the installation of its IT equipment, should maintain an accurate inventory of its assets. To establish emissions for each owning organization, asset inventory data must be correlated to installed racks/circuits allocated to all respectively owned asset equipment.. 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. These typically include: page
0 0 0 0 Users: use profiles and number of users at any given period of time Licencing 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 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 Llonk 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. 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: the number of internet hops and equipment required for data transfer to end users. Embodied energy for hardware: LCA estimates of embodied energy on a per-server basis. The use of all primary and secondary data should be clearly documented and communicated with the results of the life cycle analysis with commentary on: Technological representativeness: the degree to which the data reflect 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 fulfil services (e.g., country or site) Temporal representativeness: the time period over which the performance of the service is calculated 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.. Calculating Inventory Results.. Overview of Calculation Methodology for Cloud Services The primary variables that drive emissions from cloud services are number and location of servers, the associated data center operations and equipment that transfers data across the network. The efficiency of service is derived by dividing the sum of the emissions associated with these processes by the functional units outlined in Section. Unit of Analysis, Functional Unit and Reference Flow. (Emissions per transaction or per user = (Total System Emissions (Data center+network+equipment life cycle))/(active users or transaction count)) page
0 0 Due to temporal variations in the number of users and transactions performed, and therefore 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... Estimating Data Center Emissions The primary variables that drive emissions from cloud services are number of servers and the efficiency and location of the associated data center operations. Two alternative methods are available to calculate these; the application, and pro s and con s of each method is provided below in Table. Method : (Data Center Emissions = ((No. Servers Energy Use of Servers) + (Network Link Equipment Energy Use of Network Link Equipment) PUE) Emission Factor) Or Method : (Data Center Emissions= ((Total Data Center Energy Use) / (Total No.Servers) No. servers allocated to cloud service) Emission Factor 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 used to fulfil requests, and process web transactions. Network equipment associated with internet transfer is considered later. Table : Application of alternative methods for calculating data center emissions Method Application Pro s Con s Where dedicated servers and network link equipment for hosting and fulfilment of cloud services can be identified. Accurate use profiles can be ascertained and metering can be applied to server arrays to track electricity consumption Allows a user to capture the relative benefits of software for server power management 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. Where cloud applications are hosted across a virtualized shared pool of servers and network link equipment. Top-down approach that provides a simple approximation of emissions. Captures all the energy use for a data center ensuring that everything has been captured. The specific use profile of the cloud application and equipment is not modelled 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. page
0 0 0 0 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... Estimating Network Emissions Network emissions should be calculated using the methods provided in the Telecommunications Network Services Chapter: Data required for the calculation includes: Electricity consumed by access technologies kwh/gb Internet backbone electricity consumption kwh/gb Transfer rate GB/min Transfer electricity watt-hrs/transaction For internet backbone electricity consumption, assumptions for the average number of internet hops between data center and end user have to be made. Secondary data may also be used from credible previous studies. The overall calculation method is as follows: Internet Transfer Emissions per Transaction = ((Internet Backbone Electricity + Access Technologies Electricity) data transfer rate response time) Emission Factor Transfer emissions per transaction can be aggregated to a per-user or per-licence level by multiplying the per-transaction figure by a typical profile for a user or licensee... Estimating End-Use-Device Use Unless there is a significant difference between the profile of devices used to access cloud services versus the same non-cloud services. End-use devices can be considered a non-attributable process... Estimating Life Cycle Emissions The method for calculating life cycle emissions is provided in the Section X of this Guidance Document (or by the Product Standard?). In studies undertaken to date, the embodied emissions associated with non-use phase (i.e. material acquisition and pre-processing, production, equipment distribution and storage, and end-of-life) emissions are 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 life cycle 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. To estimate emissions from equipment at end-of-life, data on the end-of-life treatment of equipment can often be obtained from the company offering the cloud service. Alternatively, country-specific recovery and recycling rates in which the data center is located may be used as a reasonable assumption... Calculating Cloud Service Efficiency To derive the efficiency of a cloud services, the total emissions arising from the system can be denominated on a per-user, per-transaction, or per-unit of storage capacity. The following data is required to perform these efficiency calculations: page
0 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. Case Study: Microsoft Cloud Services Scope and reasons 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 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. 0 0 0 Unit of Analysis, Functional Unit and Functional Unit 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 peruser unit of analysis is determined to be the most representative way to characterize efficiency gains and three different sizes of organization (small (00 users), medium (,000 users) and large (0,000 users)) are modeled. 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. 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 life cycle impacts 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 life cycle impacts 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 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 page
0 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 phases of the equipment life cycle. Calculating Efficiency 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 efficiency ratio of Total kg CO eq per user. 0 0 0.. Overview of Calculation Methodology for Data Center Services Careful accounting of the methodology used for tracking emissions at each site will include: all identified emissions during each lifecycle phase, the units and method of determining allocation by organization utilizing the space, and any boundaries specific to the site. The below example illustrates three sites with specific information regarding type of metering and allocation methodology per site, for a data center hosting provider. Data Center Service/Hosting Provider Site Inventory In Table below, the data center provider tracks the method of determining emissions per customer for each of three sites. There are four distinct methods illustrated: Method - Site with rack metering: Per customer % emissions = Total rack metered annual kwh * PUE * CEF / total site annual emissions Method - No rack metering, leased by breaker/circuit capacity: Per customer % emissions = Total leased circuit capacity * monthly hours * PUE * CEF (summed annually) / total site annual emissions Method No rack metering, leased by SF: Per customer % emissions = Total SF leased per month * watts per SF * PUE * CEF (summed annually) / total site annual emissions Method Estimated by device ratings for all IT equipment: page
Per customer % emissions = sum of device ratings for all customer IT equipment, tracked monthly * monthly hours * PUE * CEF (summed annually) / total site annual emissions Table : Hosting Provider Site Inventory Site Name Construction tco e/ amortized annually Annual tco e during operations Total annual emissions Lessee metering installed Lessee emissions calculation Site A,000,00,00 Per Rack Total rack metered annual kwh * PUE * CEF 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 Estimated (# of total circuits * monthly hours * PUE) Estimated by total % of SF allocated Estimated by total device ratings * monthly hours * PUE * CEF 0 0 Calculation Company Data Center Portfolio Site Inventory This next example, given in Table, shows sites in use within a company portfolio, along with specific information on how company use is tracked by service or application hosted at the site. In this table, Site C hosts IT equipment for a cloud service application sold to customers of the company. The methods used to track the percentage of emissions per organization hosted at the data center site are as follows: Method - Site with rack metering, fully owned and operated by company: Site Annual Emissions = amortized embedded emissions + annual tcoe during operations (all scope emissions identified annually) Per organization % emissions = Total rack metered annual kwh * PUE * CEF / total site annual emissions Method - No rack metering, leased by breaker/circuit capacity, PUE unknown Per org % emissions = Total allocated circuit capacity * monthly hours * CEF (summed annually) / total annual emissions for all leased circuits Method Rack metering, PUE reported by lessor: Per org % emissions = Total annual kwh * PUE * CEF / total annual emissions all racks Table : Company Site Inventory Site Name Type PUE Construction tco e/ amortized annually Annual tco e during operations Total annual emissions Metering installed Use Per Org emissions calculation page
DC Fully owned.,000,00,00 Per Rack Internal use only, no services sold externally, IT equipment tracked by business division % of emissions = Total rack metered annual kwh * PUE * CEF / Total annual emissions DC Leased colocation Unknown Unknown Unknown Estimated: # of total circuits * annual hours * CEF None leased by breaker capacity Internal, IT equipment tracked by business division % of circuits per org * annual hours * CEF DC Leased colocation. unknown Unknown Total rack kwh * PUE (reported by lessor) * CEF Per Rack Cloud Service App 00% of emissions by single Org (Cloud Service App) 0 Calculation - Customer/Service Application Inventory For each data center in the portfolio, a data center provider or company with data center sites hosing IT equipment assets, will need to track and correlate usage of the data center by customer and service application. This is the point of correlation between power (either kw or kwh) and IT equipment asset inventories. Once this data is collected per organizational entity owning IT equipment assets at the site, the data collected will then need to correlated with the specific data center site profile as shown in section.. Overview of Calculation Methodology for Cloud Services. Following are a couple 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. Table : Data center Asset Owner Inventory single site using KW method Location Colo Service Owner Service App Servers Net Devices Drive Bays Others Allocated Power (kw) Power & Cooling (kwh) Estimated - Daily Human Resources Benefits 0 0.. Colo Colo Colo Colo Colo Messaging Service Messaging Service Cloud Service Cloud Service Data Center Services Messaging - Partner Service 0 0.. Messaging - Core 0 0.. Cloud Service - App # 0. 0.0 Cloud Service - App # 0 0.. EPMS System Operations 0 0 0 0 0 Colo Networking Network 0. page
Table : Service Application Equipment Inventory all IT equipment owned by a single service application across multiple sites Site Name Servers Drive Bays Net Devices Other Devices Allocated Power (watts) DC 0 0. Total kwh Daily Estimate DC 0 0 0. DC 00 0. 0 0 0. page