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

30 

Loading....

Loading....

Loading....

Loading....

Loading....

Full text

(1)

GHG Protocol Product Life Cycle Accounting

and Reporting Standard

ICT Sector Guidance

Chapter 5:

5

Guide for assessing GHG emissions of

Cloud Computing and Data Center

Services

DRAFT

26 January 2013

(2)

page 2

Table of Contents

5 Guide for assessing GHG emissions of Cloud Computing and Data Center Services ... 1

5.1 Introduction ... 5

5.1.1 What is in this chapter ... 5

5.1.2 The audience for this chapter ... 5

5.1.3 Examples: When to use and when not to use this chapter ... 5

5.1.4 Rationale of this chapter ... 6

5.1.5 Business Goals for assessing Cloud and Data Center Services ... 6

5.2 Overview of Method ... 7

5.2.1 Data Centers and Cloud Services ... 7

5.2.2 Completeness principle ... 8

5.2.3 Fixed and Variable emissions... 9

5.2.4 Allocation Process ... 9

5.2.5 Calculation Process ... 10

5.3 Functional Unit ... 10

5.3.1 Functional Unit: Cloud Services ... 11

5.3.2 Functional Unit: Data Center Services ... 12

5.4 Boundary Setting ... 12

5.4.1 Defining Boundaries ... 12

5.4.2 Attributable Processes ... 12

5.4.3 Non-attributable Processes ... 13

5.4.4 Temporal Considerations - amortization of embodied emissions ... 13

5.5 Data Collection and Data Quality ... 13

5.6 Allocation ... 17

5.6.1 Allocation of Data Center emissions ... 17

5.6.2 Allocating Equipment to Cloud Services ... 21

5.6.3 Allocating Equipment to Data Center Services... 22

5.6.4 Allocation of Network emissions ... 22

5.6.5 Allocation of End-user device emissions ... 23

5.7 Calculating Inventory Results ... 23

5.7.1 Overview of Calculation Methodology for Cloud Services ... 23

5.7.2 Calculating Data Center Emissions ... 24

5.7.3 Calculating Network Emissions ... 25

5.7.4 Calculating End-user-Device Use ... 26

5.7.5 Calculating Embodied Emissions ... 26

5.7.6 Example Case Study of Cloud Service ... 26

(3)

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 2012.

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:

http://www.ghgprotocol.org/feature/ghg-protocol-product-life-cycle-accounting-and-reporting-standard-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.]

(4)

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).

(5)

page 5

5.1

Introduction

1

5.1.1 What is in this chapter

2

This chapter forms part of the ICT Sector Guidance to the Greenhouse Gas Protocol Product Life 3

Cycle Accounting and Reporting Standard („Product Standard‟) and covers Cloud and Data Center 4

Services 5

This chapter provides guidance and accounting methods for the calculation of GHG emissions 6

related to Cloud and Data Center Services 7

The chapter provides guidance on the following key items: 8

Establishing the scope of a product inventory. 9

Defining the functional unit. 10

Boundary setting. 11

Allocation. 12

Collecting data and assessing data quality. 13

Calculating inventory results and GHG emissions. 14

A case study for assessing cloud services. 15

Examples of calculating emissions of data center services. 16

5.1.2 The audience for this chapter

17

There are several potential users of this chapter: 18

Suppliers of Cloud and Data Center Services, who require standard terminology, guidance and 19

accounting methods to calculate the GHG emissions of the services that they provide. This may 20

often be required in response to queries from their customers and potential customers. It can also 21

be used to understand where the major sources of GHG emissions are from Cloud and Data Center 22

Services, and how the suppliers may reduce the emissions of the services that they provide. 23

Users of Cloud and Data Center Services, who are interested in understanding the GHG 24

emissions of the services that they are using, and understand where improvements and efficiencies 25

may be made. 26

Organizations, which are interested in understanding the GHG emissions of cloud and data center 27

services, and understanding these in relation to more traditional ways of delivering the same 28

services. 29

5.1.3 Examples: When to use and when not to use this chapter

30

This guidance is for accounting of GHG emissions from cloud and data center services. Examples of where it 31

may be used are: 32

For assessing the GHG emissions of a cloud service provided from one or more data centers 33

For assessing the GHG emissions associated with the use of all or part of a data center (e.g. where 34

all or part of a data center is leased from a data center provider). 35

For comparing the GHG emissions of a cloud service with those from an equivalent non-cloud 36

service. (For this type of use it is important to apply the same boundary conditions to both cases, 37

in addition it is recommended to carry out an uncertainty analysis to understand the comparison of 38

the results). 39

This guidance for cloud and data center services should not be used: 40

For comparison of similar cloud or data center services from different providers, without additional 41

rules to ensure a valid comparison. 42

43 44

(6)

page 6

5.1.4 Rationale of this chapter

1

A range of business and consumer applications are increasingly provided from cloud architecture, for 2

example: 3

E-mail, calendar, document and other business applications. 4

Consumer photo, video and music and other data storage applications. 5

Search, social networking and database applications. 6

Application hosting in the cloud. 7

8

This chapter provides guidance on how to quantify the energy and GHG emissions associated with the 9

delivery of these services. The guidance is written from the perspective of a “user” of cloud services and 10

aims to provide standard and repeatable methods in order to facilitate a better understanding of the energy 11

and GHG impacts of alternative ICT service delivery solutions. 12

5.1.5 Business Goals for assessing Cloud and Data Center Services

13

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared 14

pool of configurable computing resources (e.g. networks, servers, storage, applications, and services) that 15

can be rapidly provisioned and released with minimal management effort or service provider interaction1. As 16

such, it is a service that can yield significant efficiencies in the provision of ICT services and can lead to a 17

reduction in GHG emissions based on how the service is configured and deployed2. Co-location data center 18

services, which differ from cloud services in that the user has control of the specification and management 19

of the IT devices used to host ICT services, can also yield life cycle efficiencies compared to traditional in-20

house IT hosting. 21

This guidance allows cloud and data center service providers and customers to measure and report the GHG 22

emissions from their services in a consistent manner and make informed choices to reduce GHG emissions. 23

For the purposes of this guidance, cloud services are those services that are provided to computers and 24

other end-user devices as a utility over a network, using shared infrastructure that includes data centers, 25

hardware, software and other infrastructure. This guidance adopts the standard definitions and taxonomy 26

for cloud services developed by NIST3, which delineate by the level of operational control the user has: 27

Infrastructure as a Service (IaaS): The capability provided to the consumer is to provision 28

processing, storage, networks, and other fundamental computing resources where the consumer is 29

able to deploy and run arbitrary software, which can include operating systems and applications. 30

The consumer does not manage or control the underlying cloud infrastructure but has control over 31

operating systems, storage, and deployed applications; and possibly limited control of select 32

networking components (e.g., host firewalls). 33

Platform as a Service (PaaS): The capability provided to the consumer is to deploy onto the 34

cloud infrastructure consumer-created or acquired applications created using programming 35

languages, libraries, services, and tools supported by the provider. The consumer does not manage 36

or control the underlying cloud infrastructure including network, servers, operating systems, or 37

storage, but has control over the deployed applications and possibly configuration settings for the 38

application-hosting environment. 39

1 NIST Special Publication 800-145 The NIST Definition of Cloud Computing September 2011

2 The Carbon Emissions of Server Computing for small-to medium-sized organizations: A performance study of On-Premise vs. The Cloud. NRDC & WSP. October 2012.

(7)

page 7

Software as a Service (SaaS): The capability provided to the consumer is to use the provider‟s 1

applications running on a cloud infrastructure. The applications are accessible from various client 2

devices through either a thin client interface, such as a web browser (e.g., web-based email), or a 3

program interface. The consumer does not manage or control the underlying cloud infrastructure 4

including network, servers, operating systems, storage, or even individual application capabilities, 5

with the possible exception of limited user-specific application configuration settings. 6

Data center Services are defined as Wholesale and Colocation services, in which the service provider leases 7

space in a facility and provides mechanical, electrical and other operational services to users (i.e. lessees). 8

The lessee has full control of specification and management of the IT devices hosting the services. 9

Wholesale leases: lessee may lease the entire data center, pay utility bills and operate/maintain 10

all data center physical infrastructure. Alternatively, the lessee may lease the entire site, and rely 11

upon the owner for operation and maintenance of the critical environment infrastructure (electrical, 12

mechanical and other critical infrastructure) and payment of utility bills. 13

Colocation leases: the owner operates and maintains all critical data center infrastructure, 14

however, in some cases the owner operates and maintains ICT infrastructure and leases servers as 15

physical hosts. Or alternatively a cage with basic power/cooling/security is provided and the lessee 16

operates all ICT equipment. 17

The underlying energy-using infrastructure used by cloud and data center services includes: 18

Hardware: servers, switches and routers that store and transmit information 19

Software: which controls and commands the hardware to process information and thus how much 20

power is consumed 21

Data centers: which house servers and other hardware devices for storing and fulfilling services 22

and provide the critical systems and other ancillary equipment 23

Network: which includes wired or wireless infrastructure for transmitting information from cloud 24

infrastructure to end users 25

End user devices (or “client”): including computers, smart phones and other devices used for 26

accessing cloud services 27

The chapter draws from the methods outlined in the Telecommunication Network Services and Hardware 28

chapters of this guidance document, which prescribe the methods for calculating the GHG impacts of the 29

various component parts of the infrastructure that support a cloud service. 30

5.2

Overview of Method

31

This section provides an overview of the approach for calculating the GHG emissions from Cloud and Data 32

Center services. This is then expanded on through the rest of this chapter. 33

5.2.1 Data Centers and Cloud Services

34

Relationship between Cloud Services and Data Centers

35

Cloud services include use of: 36

Data centers 37

Networks 38

End user devices 39

Thus a fundamental part of calculating the emissions from cloud services involves calculating the emissions 40

from the data center and allocating these to the specific service. 41

Data center services provide computing services from all or part of a data center. So again this involves 42

allocating the total data center emissions to the specific data center service. 43

(8)

page 8

1

Data Center Definition

2

The guidance in this chapter is applicable to a variety of different type of data centers, thus the definition 3

adopted is deliberately broad. 4

A “data center” is considered to be a physical location dedicated to hosting ICT infrastructure: 5

A data center may be a location in a mixed-use facility or a dedicated location. 6

Data centers may be of varying tiers or form factors; i.e. providing different levels of security, 7

redundancy etc. 8

Data centers may host ICT infrastructure for internal use or services for external customers, with a 9

diverse set of business applications or usage at any physical location. 10

Data centers may be used for testing or production use of applications, services, platforms or 11

clouds. 12

Data centers may vary in size in terms of total useable capacity for ICT equipment. 13

Data Center Overhead

14

It is well understood within the industry that a data center will use more input energy than it delivers to the 15

IT equipment; this overhead is due to the data center mechanical and electrical (M&E) infrastructure and is 16

commonly measured with the metric PUE4 which represents the ratio between the total facility power and 17

the IT equipment power. 18

This energy “overhead” (or non-IT energy) includes the energy used by cooling systems, and also power 19

delivery components such as UPS (uninterruptible power supply), switch gear, generators and batteries. 20

Data Center “Capacity”

21

It is common for data center “capacity” to be sold based either on provisioned circuit power (kW) or on 22

physical floor space provided (square meters or square feet). Thus the data center lease will provide for a 23

specified power or floor space, which may then be divided further to a rack, cage or server level. The data 24

center will typically be designed to a specification of maximum power provision, with the infrastructure 25

equipment and cooling capability being designed for this maximum power. It is therefore appropriate to use 26

the data center capacity as a key method for allocating overheads. This data center “capacity” is therefore 27

measured in terms of kW (although it can also be derived from floor space or from numbers of racks). 28

Note, in this chapter the term “provisioned capacity” is therefore used to refer to the circuit power (or floor 29

space) allocated to the data center, to an individual customer, service, or set of IT equipment. 30

5.2.2 Completeness principle

31

A key aspect of calculating emissions from data center services and cloud services is the allocation of the 32

data center emissions to the individual services. The underlying principle of the allocation mechanisms is 33

that of completeness: all of the emissions of the data center should be allocated to the services that the 34

data center delivers. This principle can be summarized as: 35

Allocate all of the emissions 36

4 The Power Usage Effectiveness (PUE) ratio was developed as a key data center efficiency metric by The Green Grid consortium

http://www.thegreengrid.org/

(9)

page 9

The first key rule is that the entire GHG emissions of the data center should be allocated to the 1

services delivered from it. This includes both the utility energy supply and the embodied emissions 2

in the devices. 3

All IT devices must be allocated to a service 4

This is the second part of the completeness principle. All IT devices in the data center should be 5

allocated to a delivered service. Those which support more than one service such as shared 6

network, shared storage or monitoring systems should be divided across the other devices using a 7

consistent allocation per physical device, logical device or service unit. 8

5.2.3 Fixed and Variable emissions

9

A key consideration in the definition and implementation of an allocation mechanism is the separation 10

between the fixed and variable emissions of the data center. 11

Part of the data center emissions are fixed and do not vary with the IT service consumption or the IT 12

electrical load in the data center. This includes the embodied emissions of the data center, the fixed part of 13

the data center energy overhead and the fixed energy consumption of the IT devices. 14

There is a substantial part of the energy overhead which does not vary with the IT electrical load within the 15

data center. This mix of fixed and variable overheads is the cause of the commonly observed efficiency 16

decrease (or PUE increases) with decreasing IT electrical load. This is also true at the level of the IT device, 17

(for example, many servers use over 50% of their peak workload electrical power at zero or low load, 18

although chip and server manufacturers are now working at reducing this system idle power). 19

The difficulty of determining the precise mix of fixed and variable infrastructure overheads for a site has an 20

important implication for measurement and reporting. The inherent error margin in scaling an IT load to the 21

allocated utility energy tends to negate any increase in accuracy obtained through device level metering. 22

Other estimation methods are likely to be of equivalent overall accuracy and operators are not expected to 23

install IT device level power metering simply to report emissions. 24

As far as reasonable, based on the available data the selected allocation method should seek to separate the 25

fixed and variable emissions of the site. The intent is to allocate the fixed emissions based on the 26

provisioned capacity and the variable based on the energy consumption of each platform, customer or 27

device. 28

5.2.4 Allocation Process

29

A data center is like an onion with multiple layers. At each layer an allocation is potentially necessary. 30

31

32

Figure 1: Data center layers 33

(10)

page 10

The allocation steps are summarized in the following diagram (Figure 2: Allocation steps)

1 2 Fixed Emissions Allocated kW Variable Emissions Drawn kWh Fixed Emissions Allocated Capacity Variable Emissions Utilised Capacity Virtual Machine Other Virtual Machines Service Other Services User Other Users

Data Center IT Devices Virtual Machines Services Users

3

Figure 2: Allocation steps 4

5

1) Allocate the data center emissions 6

a) Allocate fixed emissions to IT devices based upon the provisioned capacity for the IT device, or 7

group of devices 8

b) Allocate variable emissions to IT devices based upon the energy consumption of the IT device or 9

group of devices 10

2) If virtual machines are in use, allocate IT device emissions to virtual machines, for example: 11

a) Allocate the IT device fixed emissions (based on idle power) to virtual machines based on the 12

fraction of machine capacity allocated to the virtual machine or based on a simple fixed emissions 13

to total virtual machines approach 14

b) Allocate the IT device variable emissions (actual – idle power) to virtual machines based on a 15

suitable proxy for work such as CPU load 16

3) Allocate IT device emissions (or virtual machine emissions) to services 17

4) Where a service is used by more than one user then the service emissions should be allocated to the 18

individual users 19

20

The specific allocation methods chosen for each step will be partly dependent on the data available, and on 21

the type of service being delivered. Section 5.6 provides more detailed guidance on the different allocation 22

methods. 23

5.2.5 Calculation Process

24

The calculation process is described further in section 5.7. The process involves calculating and summing 25

the data center emissions, network emissions, and end-user device emissions, and then allocating these to a 26

service. 27

5.3

Functional Unit

28

The functional unit should define the following three parameters: 29

The Quantity of the service: this will be the defining parameter for the service and typically will equate to 30

how the service is sold. Some typical examples are: 31

Number of users, mailboxes supported 32

Size of storage capacity (GB) provided 33

Quantity of computing capability provided (e.g. number of minutes, or number and type of servers) 34

The Duration of the service: typically this will be expressed in terms of per year. Some examples are: 35

(11)

page 11

Per year, month, day, hour or minute

1

For the contract duration (one or multiple years) 2

The Quality of the service: this should describe the relevant service levels, where they exist, as these 3

may have a significant impact on the resources required to provide the service, in terms of recovery / 4

availability. 5

5.3.1 Functional Unit: Cloud Services

6

Cloud services are procured in different ways, for example: on a “per-user” basis; or by “storage” capacity 7

(e.g. GB of data stored), both measured over a period of time (e.g. per-day or per-year). These are useful 8

starting points for defining the functional unit of cloud services. Where use profiles vary significantly for 9

cloud services, “transactions” may better reflect the key indicator – i.e. the number of application 10

programming interfaces (API) and web requests processed by the platform over a period of time. 11

These alternative functional units may be used when undertaking analysis of cloud services, and should be 12

selected based on the characteristics of the cloud service as shown in Table 1: 13

Table 1: Alternative Functional Units for Cloud Services

14

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

Per-transaction Search; social networking and

database applications

Low data storage requirements; high user access

15

When undertaking analysis on a per-user basis, to account for the fact that servers hosting cloud services do 16

not follow a linear scale as user counts increase, aggregation into different sized user groups may be 17

necessary to understand efficiencies of scale provided by cloud services. These user groups may be defined 18

by the number of users or by the terms of a license, or service level agreement. 19

Transaction-based analysis can enable more accurate comparison of alternative cloud platforms. A 20

transaction can be defined as a WebAPI (i.e. a web request/response), for example. However, due to the 21

diversity and complexity in types of transactions and lack of a standardized methodology to separate each 22

type of transaction, an assumption would typically be made that all transactions for a given service require 23

the same amount of energy load upon the IT hardware to process, based on typical packet size and type of 24

transaction. 25

The functional unit should be defined with a high degree of specificity, defining the level and quality of 26

service, especially in cases where the basis for normalization is complex and could be potentially misleading. 27

For instance, instead of simply defining the functional unit as an API, additional descriptive information can 28

be provided to clarify what an API specifically means for a given type of service and what range in physical 29

resource demands may exist for various types of APIs considered. 30

As a further example, even for a service such as email there is a range of parameters which will legitimately 31

affect the energy consumption of the delivered user service; 32

1. The size of the mailstore (in both messages and total data volume) 33

2. The number of messages sent and received in each unit time 34

(12)

page 12

3. The extent of filtering, virus scanning etc. carried out on each routed message

1

4. Whether the messages are viewed in a web mail client or downloaded by a client application using 2

a protocol such as POP or IMAP, or both 3

5. The level of resilience and availability of the email infrastructure, e.g. redundant front end servers 4

and duplicate storage of the mailstore(s) across multiple data centers 5

6. The additional functionality provided, e.g. calendaring 6

7. The physical location (geographic region and jurisdiction) in which the data is held and processed 7

5.3.2 Functional Unit: Data Center Services

8

For data center services, the functional unit should clearly describe the kind of lease (wholesale or 9

colocation) and fully define the scope of the service in terms of quantity and time period, and any particular 10

service level agreements (SLAs) that are part of the service. 11

5.4

Boundary Setting

12

5.4.1 Defining Boundaries

13

Cloud services create emissions in three main places: 14

Data centers: switches, routers and servers / storage devices used for receiving, sending and 15

storing data and the associated critical systems, facilities and utilities. 16

Network: routers, switches, cables and other equipment associated with the transfer of data 17

between the data center and end-user. 18

End-user devices: PCs, laptops, tablets, phones or other devices used to access cloud services. 19

20

The diagram shown in Figure 3 provides generic boundaries for aspects of infrastructure that support cloud 21

service delivery. Depending on the nature of specific cloud applications, certain aspects may not be 22

necessary to include. 23

24

25

Figure 3: Generic scope and boundary for equipment used by Cloud Services 26

5.4.2 Attributable Processes

27

Processes directly attributable to the GHG impact of cloud services are: 28

(13)

page 13

Hosting and fulfillment of the cloud applications – including servers, storage devices, other IT 1

equipment, critical systems and associated data center facilities including HVAC systems required 2

for server cooling. 3

Internet transfer. 4

User access. 5

Energy, water, refrigerants, fire suppression gases and other consumable materials consumed by 6

the above processes throughout their life cycle. 7

5.4.3 Non-attributable Processes

8

Processes that are not attributable to the GHG impact of cloud services are: 9

Energy consumed during software development. 10

Material and energy flows from production of capital equipment, transportation vehicles, buildings 11

and their energy use not directly related to equipment for hosting and fulfillment of the cloud 12

service and associated equipment. 13

Maintenance of capital equipment. 14

5.4.4 Temporal Considerations - amortization of embodied emissions

15

The embodied emissions of the equipment should be amortized over the expected in-use lifetime of the 16

equipment. The lifetime will vary significantly from equipment type to equipment type, and also based on 17

the renewal policy of the data center. This may also vary based on the type of technology used. 18

For example: 19

Lifetime of IT equipment is likely to be between 18 months and 5 years. 20

Examples of lifetimes for infrastructure equipment are: 21

25 Years - Main MV transformers, some electrical switchgear 22

20 Years – Chillers, Cooling towers, main chilled water pipework, backup generators, low voltage 23

distribution cabling and switchgear, AHU units 24

15 Years – UPS, data hall electrical PDU, CRAC units 25

<10 Years – Elements closely coupled to IT such as in row cooling units, rack exit door coolers, 26

“smart power strips” etc. 27

28

It is usual to align the amortization of the embodied emissions with the assumptions used for amortization 29

of capital costs for financial accounting purposes. Whatever assumptions are used for amortizing equipment, 30

they should be clearly stated in supporting documentation. 31

5.5

Data Collection and Data Quality

32

Data should be collected for all processes included in the inventory boundary. Primary data should be 33

collected for processes under the ownership or control of the cloud service provider. 34

Depending on the service being assessed and the allocation method being used the following data may be 35

required: 36

Users: use profiles and number of users at any given period of time 37

Licensing or service level agreements: the units of service defined, e.g. number of users for a 38

specified period of time 39

Transactions: for example, measured Iops or WebAPIs/requests processed by the platform, over 40

a specified time period 41

Data centers: number and location 42

(14)

page 14

Server count: number of servers provisioned to host and fulfill the cloud application and data 1

storage requirements. This includes redundancy for business continuity and disaster recovery 2

Network Link equipment count: number of in-data center routers and switches required to 3

fulfill WebAPI requests, and process web transactions. This includes redundancy for business 4

continuity and disaster recovery 5

Device utilization: computational load that a device is managing relative to the specified peak 6

load 7

Power consumption per type of IT hardware: calculated energy consumed by a server at a 8

given rate of device utilization and estimated power for networking and storage equipment 9

Data center Power Usage Effectiveness (PUE): defined as the ratio of overall power drawn by 10

the data center facility, to the power delivered to the IT hardware. This is a data center-specific 11

metric and accounts for energy consumption of active cooling, power conditioning, lighting, and 12

other critical data center infrastructure. 13

Emission Factors - equipment: factors for the embodied emissions of relevant IT equipment, 14

ideally obtained from equipment manufacturers. See also the Hardware chapter for methods of 15

calculating and estimating these. 16

Emission Factors – electricity: the emission factor for the electricity used should be appropriate 17

for the region where the electricity is consumed. Electricity grid emission factors are published on a 18

national basis, and in some cases on a regional basis. Electricity grid emission factors should be 19

used that include the full life cycle of the energy source (i.e. include emissions due to extraction 20

and transportation of the fuel, as well as generation and transmission). 21

If primary data is not available, secondary data and/or assumptions may be developed for processes that 22

are not under the ownership or control of the cloud service provider. These might include: 23

Internet transfer: secondary data on access and core network usage (see the 24

Telecommunications Network Services chapter for more details) 25

Embodied emissions for hardware: estimates of embodied emissions on a per-server basis. 26

27

The use of all primary and secondary data should be clearly documented and communicated with the results 28

of the GHG inventory with commentary on: 29

Technological representativeness: the degree to which the data reflects the actual equipment 30

and infrastructure used to support the cloud service 31

Geographical representativeness: the degree to which the data reflects actual geographic 32

location of the equipment used to host and fulfill services (e.g., country or site) 33

Temporal representativeness: the time period that the collected data relates to 34

Completeness: the degree to which the data are statistically representative of the cloud services 35

Reliability: the degree to which the sources, data collection methods, and verification procedures 36

used to obtain the data are dependable. 37

Data Center Energy data

38

Energy (kWh) used by a data center is a key data item to be measured. The diagram shown in Figure 4 39

identifies key measurement points within a data center. 40

41 42

(15)

page 15

1

Figure 4: Flow chart of energy use throughout a site 2

Measurement of kWh at both points M1 (Utility kWh) and M4 (IT Equipment kWh) allow for the calculation 3

of the PUE data center metric. If possible, in order to improve accuracy of tracking on a per rack or device 4

level basis, the data center operator may also track the remaining measurement points. It is noted, that 5

this is a large undertaking, particularly in older sites with a variety of monitoring systems. Retrofitting an 6

existing data center may require a large investment in instrumentation, as well as data acquisition and 7

reporting software. 8

Hardware and software-based equipment power monitoring techniques (M7 & M8) are evolving rapidly and 9

becoming more cost effective. Deployment of software monitoring systems, where the hardware systems 10

have the APIs needed to provide the data to the software system, can offer an efficient way to track IT 11

energy use by customer account. 12

Data Center Capacity

13

It is common for data center “capacity” to be sold based either on provisioned circuit power (kW) or on 14

physical floor space provided (square meters or square feet). 15

By way of comparison, in commercial buildings, the square foot (SF) or square meter (SM) is the basic unit 16

of provision for capacity management, and demand for additional SF/SM drives takedown of additional 17

capacity. Key metrics for commercial buildings are cost per SF/SM and SF/SM per person, as well as a 18

variety of other metrics depending upon the particular business use of the building. 19

In the data center industry, the common unit for measuring capacity is kilowatts. Secondary units, such as 20

capacity in terms of racks or SF/SM are also in use throughout the industry, but are easily converted back to 21

kilowatts from a per unit basis. The industry is currently gravitating towards a kilowatts unit basis for 22

capacity management, and for ease of calculation, this guidance recommends conversion to a kilowatt unit 23

for analysis of each site. 24

The data center will typically be designed to a specification of maximum power provision, with the 25

infrastructure equipment and cooling capability being designed for this maximum power. It is therefore 26

(16)

page 16

appropriate to use the data center capacity as a key method for allocating fixed emissions such as

1

overheads. 2

In other words, a particular site may be designed to provide 10,000 kW of capacity for ICT equipment. 3

Thus, the fixed emissions of the site can be allocated based upon the share of total kilowatts of capacity 4

that are provided by the particular site. 5

Data Center Capacity Example

6

The diagram shown in Figure 5 is intended to represent an example of a data center physical layout, in 7

order to provide a better understanding of data center capacity and its allocation to specific IT devices. 8

9

Figure 5: Example data center physical layout 10

11

In a typical colocation data center, IT equipment is hosted in a physical room, or multiple rooms, with 12

adequate power and cooling to support reliable site operations. The above floor plan is a data center 13

showing one room (Colo1) for IT equipment, served by electrical and mechanical equipment, with 1.98MW 14

of useable capacity, backed by a UPS with nominal capacity at output to the IT equipment room of 2.2MW. 15

Key for Figure 5: Colo : Colocation

CRAC: Computer Room Air Conditioning PDU: Power Distribution Unit

(17)

page 17

It is recommended to track capacity within each IT equipment room (colo1 above) and determine the 1

capacity of power provisioned for each rack in the room. A typical data center may have a variety of rack 2

types with different numbers of circuits deployed to each, and thus each rack may be tracked individually. 3

4

Identifying IT Equipment Ownership - ITAM Inventory

5

IT asset management (ITAM) systems are used by data center owners to track ownership of equipment 6

hosted in their data centers. ITAM inventories are required for various business reasons, such as property 7

tax reporting and accordingly are subject to quality controls and should include all IT equipment installed, 8

and in particular, all assets plugged into power sources at the site, with ownership by specific business 9

division or owning organization, purchase information and application/service usage. 10

An exception to the use of ITAM inventories would be for a data center provider selling wholesale data 11

center space (i.e. caged or rooms of raw data center space). In this case, the wholesale provider would 12

track the total kW of useable capacity, whether metered or unmetered for each customer. In this 13

circumstance, the lessee would maintain an inventory of its assets. 14

To establish emissions, the asset inventory data should be correlated to installed racks/circuits and allocated 15

to all respectively owned asset equipment. 16

5.6

Allocation

17

This section describes the allocation of emissions of data centers, networks and end-user devices. 18

5.6.1 Allocation of Data Center emissions

19

Choice of allocation method

20

Methods used to allocate data center emissions vary in difficulty of implementation or applicability to the 21

business need, depending on the type and complexity of the data center, what data is easily available and 22

the type of service being assessed. Each company should choose a method that meets their business 23

needs, and the allocation methodologies in this section are presented as best practices that may or may not 24

be applicable to the needs of a particular company. 25

Each company will need to determine the method to be utilized based upon cost or expediency; it is 26

recommended to establish a practice and adhere to this practice for the entire data center GHG inventory. 27

If a combination of methods is used (for example, due to equipment age) then this should be justified and 28

documented. 29

Completeness principle

30

The calculation of GHG emissions due to cloud and data center services involves allocating the emissions of 31

the data center to the specific service being assessed. 32

As described in section 5.2 „Overview of Method‟ the completeness principle should be adhered to – i.e. all 33

of the emissions of the data center should be allocated to the services that the data center delivers to its 34

customers. 35

Fixed and variable emissions

36

The other concept introduced in section 5.2 is that of fixed and variable emissions for a data center, and 37

that different allocation methods are appropriate for fixed and variable emissions. Therefore it is 38

recommended that, to the extent to which it is practical, the emissions are separated out into fixed and 39

variable. Given the difficulty inherent in separating the fixed energy overhead, most practical allocation 40

regimes must understand their inherent error margin when determining the method and reporting precision 41

so as not to create a false impression of accuracy. 42

(18)

page 18

The fixed emissions include the embodied emissions of the data center and equipment, the fixed part of the 1

data center overhead energy and the fixed energy consumption of the IT devices. 2

It is recommended that the fixed emissions are allocated based on data center “capacity” (defined in section 3

5.2.1), while the variable emissions are allocated based on the IT device electrical power consumed. 4

Steps for allocating data center emissions

5

The following diagram (Figure 6, repeated from section 5.2.4) summarizes the preferred allocation steps for 6 a data center. 7 Fixed Emissions Allocated kW Variable Emissions Drawn kWh Fixed Emissions Allocated Capacity Variable Emissions Utilised Capacity Virtual Machine Other Virtual Machines Service Other Services User Other Users

Data Center IT Devices Virtual Machines Services Users

8

Figure 6: Allocation steps 9

10

Step 1. Allocate the data center fixed emissions to IT devices

11

Fixed emissions include: 12

embodied emissions of the data center and equipment 13

the part of the data center emissions that does not vary with IT electrical load 14

Whilst a full determination of the fixed emissions of the data center can be complex operators 15

may identify parts of or estimate their full fixed emissions via some simple methods, for 16

example: 17

Observing the fixed energy consumption with all major infrastructure equipment operating 18

during a commissioning test at zero IT load, whilst this is temperature dependent it forms a 19

reasonable basis for estimation 20

Performing a regression analysis of the utility power against IT power across a suitable range 21

of readings, again subject to temperature but can be a reasonable basis for estimation 22

Utilizing sub-metering of infrastructure loads and identifying those which are not related to IT 23

energy consumption and subtracting those loads from the overhead applied to the IT load, 24

these fixed loads might include: 25

i. generator and fuel tank heaters, ice melt systems 26

ii. gas consumed by heating boilers 27

iii. diesel or other fuels consumed in generator load testing 28

iv. lighting loads 29

v. Support areas, monitoring and BMS systems, security systems 30

vi. office space outlets, lighting and air conditioning 31

vii. make-up air handling units and associated humidity controls 32

In terms of the familiar PUE equation this separation may be expressed as; 33

(19)

page 19

Once a method has been chosen to estimate the fixed part of the in-use emissions of the data 1

center the fixed and variable emissions for the allocation period may be separated by: 2

3

The fixed emissions of the data center should be allocated based on the data center “capacity” 4

that has been provisioned. The allocation factor thus is: 5

Thus the fixed emissions allocated to an IT device, group of devices or electrical load is: 6

Where capacity provisionedn is the data center capacity provisioned to the identified device or 7

group of devices. The total capacity provisionedtotal is the sum of all the capacity provisioned for 8

the data center, not the design or rated capacity of the data center. This is to ensure that all 9

the emissions of the data center are allocated to services delivered by the data center and none 10

are absorbed by the data center operator. 11

Capacity is commonly measured in kilowatts. However, if it is measured in other units, such as 12

number of racks or floor area, then it should be converted to kW prior to allocation of emissions. 13

Table 2 gives an example of this conversion from floor area in square feet (SF) to kW. The total 14

SF and kW capacity are known; from these a „Watts per SF‟ factor can be calculated. The 15

„Watts per SF‟ factor is then multiplied by the SF provisioned to a specific organization to 16

calculate the kW capacity provisioned to the organization. 17

Table 2: Conversion SF to kW

18

DC

Total

Useable SF

UPS Output

Capacity

(kW)

Watts per

SF

Org #1

provisioned

SF

Org #1

provisioned

kW

Site 1 13,500 2700 200 2000 400 Site 2 27,000 2700 100 2000 200 19

Step 2. Allocate the data center variable emissions to IT devices

20

Variable emissions include: 21

the remainder of the data center overhead not already allocated in the fixed emissions step 22

the variable energy consumption of the IT devices 23

24

The variable emissions of the data center should be allocated based on the metered energy 25

consumed by the relevant IT devices during the time period being assessed. The allocation 26

factor thus is: 27

(20)

page 20

Thus the allocated variable emissions to an IT device, group of devices or electrical load is: 1

Where detailed energy metering is not available, then an alternative estimation approach may 2

be based at the simplest level on the number of physical servers dedicated to the service. 3

4 5

Step 3. Allocate the IT device fixed emissions to virtual machines (where these are being

6

used) 7

Where the service is running on virtual machines (VMs), then the emissions need to be allocated 8

based on a parameter of the virtual machines. It is likely that an operator may have a large 9

homogeneous group of physical machines and these may be treated as a single large IT device. 10

At the IT device level, part of the IT energy consumption may be considered to be fixed, this 11

may be estimated based on the zero load power draw of the machines as a fraction of the 12

average power draw of the machines over the allocation interval: 13

Where the operator is unable to estimate the fixed proportion of the IT device(s) energy 14

consumption then the idle power should be considered to be zero and the fixed emissions are 15

simply those calculated for the IT device(s). 16

To allocate the fixed emissions to the individual virtual machines either a simple division by the 17

number of virtual machines in each period on the physical machine(s) or a weighted division 18

which takes into account physical resource allocation may be used. The intent is to capture an 19

additional part of the IT allocated variable energy as fixed consumption by the IT device. 20

Other allocation methods for VMs are described in the Software chapter. 21

Step 4. Allocate the IT device variable emissions to virtual machines (where these are being

22

used) 23

The variable emissions part of the VM emissions is simply the IT allocated emissions minus 24

those already allocated to the fixed VM emissions: 25

Again, where the operator is unable to estimate the fixed proportion of the IT device(s) energy 26

consumption then the idle power should be considered to be zero and the variable emissions are 27

simply those calculated for the IT device(s). 28

29

Again, to allocate the total VM variable emissions individual virtual machines this may be done 30

either by by simple division of the number of VMs or by a weighted division which takes into 31

account some aspect of the load each VM presented to the physical host during the allocation 32

period: 33

(21)

page 21

Step 5. Allocate IT device emissions (or VM emissions) to services

1

It is increasingly common for IT services to share physical IT devices and infrastructure. In this 2

case the emissions allocated to each device need to be calculated and summed as follows: 3

Where is the allocation factor of the services for the IT device, and is 4

the emissions for the IT device or virtual machine. (The allocation factor in this case represents 5

the usage of the device or virtual machine, using some appropriate physical metric such as cpu 6

usage or memory usage). 7

Step 6. Allocate service emissions to the individual users

8

In the case where a service is used by more than one user, such as email, the service emissions 9

should be allocated across the users based on a representative measure. A suitable method of 10

allocating the service capacity and utilization across the users should be selected and described. 11

This may well be based on the billing structure of the service for ease of use and transparency. 12

Examples of the allocation might be: 13

Bandwidth for streaming services 14

Bytes available for storage and Bytes transferred for storage services 15

Mailbox size for email 16

Where the data center has a highly homogeneous environment and the data center provides a 17

set of similar services which may not have any dedicated IT equipment, then it may be 18

appropriate to bypass the allocation of emissions to IT equipment and services and simply 19

allocate the data center emissions based upon service utilization. 20

5.6.2 Allocating Equipment to Cloud Services

21

“Private” clouds have defined infrastructure operated solely for a given organization or service. In instances 22

of private cloud, it may be possible to identify and measure specific storage and networking devices that 23

support specific cloud services, in which case the allocation method outlined above can be followed. 24

However, more often, public and private cloud services are run using virtual machines (VM) located in 25

multiple data centers. In turn, the data centers may support other services and be at varying degrees of fit-26

out / loading. It is therefore a challenge to allocate specific ICT equipment and emissions associated with 27

electrical and mechanical services to cloud services. 28

When it is not possible to identify specific hardware and equipment to a cloud service, then a more 29

simplified approach may be appropriate using estimates of suitable parameters that reflect the underlying 30

allocation. 31

Simplified parameters that may be used for allocation of Data Center emissions: 32

Estimated count of physical servers dedicated to the service (divided by the total number of servers 33

in the data center) 34

Estimated count of virtual machines dedicated to the service (divided by the total number of virtual 35

machines on the fabric hosting them) 36

Parameter that reflects the IT resource usage by the service, for example: 37

Iops (input-output operations per second) over a specified period of time 38

WebAPIs (i.e. number of web request/responses) over a specified period of time 39

(22)

page 22

Processing time, processor type, number of instances

1

or Storage requirements in Mbytes 2

5.6.3 Allocating Equipment to Data Center Services

3

Data center services can be Wholesale or Colocation services (see section 5.1.5); depending on the type of 4

lease different information may be available for the calculation of the GHG emissions. 5

In instances where it is possible to identify and measure specific IT devices that support the specific data 6

center services, then the allocation method outlined above can be followed. 7

When it is not possible to identify specific hardware and equipment to a data center service, then a more 8

simplified approach may be appropriate using estimates of suitable parameters that reflect the underlying 9

allocation. 10

Simplified methods that may be used for allocation of Data Center emissions: 11

Count of servers 12

Allocate the total data center emissions using the ratio of the number of servers used for the 13

service divided by the total number of servers at the data center site 14

Provisioned „data center capacity‟ 15

Determine the provisioned kW capacity for each device and allocate the total data center 16

emissions using the ratio of provisioned kW capacity used for the service divided by the total 17

provisioned kW capacity. 18

Sample power readings 19

Measure the power consumption of all IT devices while under load, sampling at different 20

times. Average the samples for each device, then allocate the total data center emissions 21

using the ratio of the average sample power for the IT devices used by the service divided by 22

the average sample power for all the IT devices in the data center 23

Note that device power consumption may vary significantly, which reduces the value of this 24

method 25

Manufacturer‟s power rating 26

This is similar to the previous method, except using manufacturer‟s power ratings for the IT 27

devices, ideally adjusting by actual usage of the equipment. 28

Metered energy readings 29

This method requires metering of the energy used by each IT device. The total data center 30

emissions are then allocated using the ratio of the energy used by the relevant IT devices 31

over the time period being considered divided by the data center‟s total energy consumption 32

for the same time period. 33

34

5.6.4 Allocation of Network emissions

35

Allocation of emissions due to network equipment within the data center should be automatically included 36

within the method for allocating the data center emissions, described above in section 5.6.1 (Allocation of 37

Data Center emissions), provided that the network devices are allocated to the cloud or data center services 38

that are being assessed. 39

For the emissions of networks external to the data center (e.g. WAN, internet, LAN at end-user premises) 40

then the emissions of the relevant network can be allocated to the service, based on one of the following 41 parameters: 42 Number of ports 43 Data traffic 44

(23)

page 23

Provisioned bandwidth

1

For further details of calculating and allocating network emissions, see the Telecommunications Network 2

Services chapter. 3

4

5.6.5 Allocation of End-user device emissions

5

End-user devices (e.g. laptops, desktops, mobile devices) may be dedicated to a particular service, but are 6

more likely to be shared in use between different services. Allocation of the emissions of end-user devices 7

can be done based on actual time used by the service, or on some appropriate resource usage relevant to 8

the service (e.g. percentage cpu used), or metered energy usage by the service. 9

10 11

5.7

Calculating Inventory Results

12

5.7.1 Overview of Calculation Methodology for Cloud Services

13

The emissions of a cloud service are calculated by summing the total emissions of the service for the time 14

period being considered, then dividing by the appropriate parameter for the functional unit being measured. 15

The primary variables that drive emissions from cloud services are number and location of servers, the 16

associated data center operations, the equipment that transfers data across the network, and the end-user 17

equipment. The emissions of the service are derived by dividing the sum of the emissions associated with 18

these processes by the relevant parameter for the functional unit being measured. See section 5.3 19

(Functional Unit) for discussion of different functional units. The following are examples of calculations for 20

different functional units: 21

Emissions per user = (Total Emissions of the service (Data center + Network + Equipment)) / 22

(Number of Active Users) 23

or 24

Emissions per transaction = (Total Emissions of the service (Data center + Network + Equipment)) 25

/ ( transaction count) 26

or 27

Emissions per unit of storage (GB) = (Total Emissions of the service (Data center + Network + 28

Equipment)) / (Storage Capacity (GB))) 29

30

The following data is required for the denominators in the examples above for the different functional units: 31

Active Users

32

A median number of active users should be determined over a specified time period; or alternatively 33

calculations performed on the average maximum number of users the service is sized for over a 34

specified time period. 35

Transaction Count

36

Transaction count is the sum of the number Iops or WebAPIs for a given service over a defined 37

period of time. 38

Storage Capacity

39

Provisioned storage capacity should be used as the denominator, rather than actively used storage 40

capacity. 41

(24)

page 24

1

Due to temporal variations in the number of users, transactions performed or storage capacity provided, and 2

the associated equipment utilization, a sufficiently long time period should be specified for data collection to 3

allow a representative average emission intensity to be calculated. For example, the time period specified 4

may be a month or a year. 5

5.7.2 Calculating Data Center Emissions

6

The primary variables that drive emissions from data center services are number of servers and the 7

efficiency and location of the associated data center operations. Two alternative methods are available to 8

calculate the emissions of the data center services. The advantages and disadvantages of each method 9

are provided below in Table 3 and assumptions should be detailed in support of any calculations performed, 10

together with a list of potential sources of error. 11

Method 1 (bottom up):

12

This method requires identification of specific equipment associated with the service, and 13

measuring the energy use of this equipment. It can be used where it is not practical to get the 14

total emissions of the data center. 15

Data Center Emissions of service = (((No. Servers × Energy Use of Servers) + (Network Link 16

Equipment × Energy Use of Network Link Equipment)) × PUE × Electricity Emission Factor) + 17

embodied emissions of IT devices + allocation of embodied emissions of data center overhead 18

Where the servers, network equipment and IT devices are those allocated to the service. 19

Or 20

Method 2 (top down):

21

This method allocates the total Data Center emissions using an appropriate allocation method (see 22

section 5.6.1 „Allocation of Data Center emissions‟ for discussion of allocation methods). Ideally this 23

method would allocate separately the fixed and variable emissions of the data center. 24

Data Center Emissions of service = Total Data Center Emissions x Allocation Factor 25

For example, a simple allocation factor would be: (Number of servers allocated to service) / (Total 26

number of servers) 27

The total number of servers should also include actual or assumed backup servers including redundant 28

storage and network drives, and networking link equipment. This backup equipment may be in different 29

physical locations. 30

Network link equipment is assumed to be the routers, switches and other associated equipment within the 31

data center used to fulfill requests, and process web transactions. Network equipment associated with 32

internet transfer is considered later. 33 34 35 36 37 38 39

(25)

page 25

Table 3: Application of alternative methods for calculating data center emissions

1

Method

Application

Advantages

Disadvantages

1

Bottom up

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.

Accurate use profiles can be ascertained and monitoring techniques can be applied to equipment to track electricity consumption (see section 5.5 for discussion on monitoring techniques).

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.

Does not necessarily account for all the data center emissions.

2

Top down

Where cloud applications are hosted across a virtualized shared pool of servers and network link equipment.

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.

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.

2

To account for temporal variations server and network link equipment should be tracked at a frequency for 3

the data to be representative (e.g. weekly or monthly) for the duration of the time period defined for the 4

study. 5

5.7.3 Calculating Network Emissions

6

Network emissions (external to the data center) should be calculated using the methods provided in the 7

Telecommunications Network Services Chapter: 8

Data required for the calculation includes: 9

Electricity consumed by access technologies kWh/GB 10

Internet backbone electricity consumption kWh/GB 11

Transfer rate GB/min; Mbit/s

12

Transmission Time minutes or seconds

13 14

The overall calculation method is as follows: 15

Internet Emissions per Unit of Data Transferred = ((Internet Backbone Electricity + Access 16

Technologies Electricity) × Data Transfer Rate × Transmission Time) × Emission Factor 17

Electricity consumed by access and internet backbone equipment may be calculated based on either 18

metered data for that equipment, or by applying an assumed utilization rate to the equipment‟s power 19

rating. This can then be multiplied by the assumed number of intermediate devices (or internet hops) the 20

data passes through to its destination. 21

Transfer emissions per unit of data transferred can be aggregated to a per-user or per-license level by 22

multiplying it by a typical profile for a user or licensee. 23

(26)

page 26

5.7.4 Calculating End-user-Device Use

1

Where the GHG assessment is comparing a cloud service with an equivalent non-cloud service, and where 2

there is no significant difference between the profile of end-user devices used to access the services, then 3

the end-user devices may be considered to be equivalent, and therefore could be excluded from the 4

analysis. 5

If, however, the cloud service results in a shift towards a different end-user-device profile, such as away 6

from PC‟s towards more thin clients or mobile devices, or if the use profile of the service changes 7

significantly, then end-user-devices should be included in the analysis. In this circumstance, a survey to 8

determine the mix of end-user-devices should be undertaken and their energy consumption and emissions 9

estimated. 10

Guidance on calculating the emissions associated with the use of end-user devices is provided in the 11

Hardware chapter of this Guidance Document. 12

5.7.5 Calculating Embodied Emissions

13

The method for calculating embodied emissions of the ICT equipment is provided in the Hardware chapter 14

of this Guidance Document. 15

In studies undertaken to date, the embodied emissions associated with non-use stage (i.e. material 16

acquisition and pre-processing, production, equipment distribution and storage, and end-of-life) emissions 17

are typically a small component of the overall emissions burden of cloud services5. 18

A number of studies have been undertaken by equipment manufacturers and academic institutions to 19

provide credible approximations of embodied emissions, which may be used as secondary data for the 20

purposes of expediting studies, if manufacturers of the equipment are unable to provide primary data. 21

5.7.6 Example Case Study of Cloud Service

22

Case Study: Microsoft Cloud Services6

23

Scope and business goals for footprinting these services 24

As part of their move into the cloud computing market, Microsoft has studied the provision of a

25

number of their business applications - Microsoft Exchange®, Microsoft SharePoint® and Microsoft

26

Dynamics® CRM – via the cloud to understand whether the cloud is a “greener” computing

27

alternative. Microsoft aimed to test potential efficiency benefits that cloud offers, including dynamic

28

provisioning, improved server utilization, private versus multi-tenant architecture, and data center

29

efficiency (i.e. PUE) through larger “state-of the art” facilities.

30

Functional Unit 31

Quantity: The use-profile varies somewhat between each Microsoft application studied; however,

32

they are all generally characterized by high data storage requirements and high user access. As a

33

result a “per-user” unit of analysis is determined to be the most representative way to characterize

34

the functional unit and three different sizes of organization (small (100 users), medium (1,000 users)

35

and large (10,000 users)) are modeled.

36

5

Cloud Computing and Sustainability: The Environmental Benefits of Moving to the Cloud. Accenture & WSP. November 2010.

6 see press release at http://www.microsoft.com/en-us/news/press/2010/nov10/11-04CloudBenefitsPR.aspx

and download whitepaper at http://www.microsoft.com/Environment/products-and-solutions/cloud-computing.aspx

Figure

Updating...

Related subjects :