Full Report
updated on 24 Feb 2024
Methodology
Environmental impact
Software
Share Publication
Introduction
In this paper, we want to show an end-to-end model for accounting the environmental impact of a software application (’application’) we will use the example of an AI model & service to illustrate this. The main idea of this work is that an application maintains an environmental impact account, similar to a bank account, where the environmental impacts are accumulated over the life cycle of the application.
To improve the readability of the document, we use a specific language and words that hide some of the complexity. Here is an overview of the concepts behind the words:
Digital Resources: Capacity to compute, store and transfer data as produced by a server entity from energy.
Digital Resource Type: When we talk about types for digital resources in this document, we refer to compute, storage and network resources as ‘types of digital resources’.
Entity: We refer to the different entities in the value-chain of infrastructure required to run a software application. These entities are: Data Center Facility (Building), Rack (housing servers and network equipment), Server (IT equipment producing computing, storage or networking capacity), Client Device (e.g. Laptop or Phone). For now we exclude networking equipment.
Account: Akin to a bank account, it’s a multi-value ‘bucket’ where the environmental impacts are accumulated for an entity (see below).
The environmental impact indicators are always the same for each entity, and are a listed at the end of the document.
For sake of simplicity we refer to them as Operational, Embodied and Indirect Impacts, see the definitions below.
Each entity has two sub-accounts: Productive Impacts and Non-Productive Impacts. The goal of each entity should be to minimize the non-productive impacts and overall ensure the account balance doesn’t rise (or to slow down the accumulation of impacts)
All the accounts in this paper are cumulative, annual accounts. This means that the Embodied Impacts are allocated to each entity according to the Useful Life of that entity at the beginning of the year as a starting balance. The Operational Impacts over the year are then added cumulatively to the account. At the end of a year (or other period), the total account balance can be retrieved. Technically, the time-resolution can be anything from an hour to ten years, but for the sake of this paper, we stick to the annual resolution as it makes the examples more clear.
Productive Impact: Productive impacts are caused by the entity providing useful work, e.g. a server might use energy to perform computation for an application.
Non-Productive Impacts: Arise from an entity being operational/running but not performing useful work, e.g. a server might be idling but still consuming energy or a data center might be half-empty, which will lead to half it’s embodied impact to be attributed as non-productive.
Useful Work: We consider useful work performed on the last step of the value-creation chain. A server entity provisions digital resources. These are by default Non-Productive. The server, when running and provisioning resources, consumes energy. This changes when an application uses those provisioned resources, in which case they become productive. The goal of the server provisioning, virtualization or orchestration systems is to maximize the amount of productive resource usage.
Operational Impacts: These are environmental impacts which are created by the operation of the entity - in the case of the data center facility, this might be energy and associated GHG emissions for operating the cooling systems; for a server, it may be the energy consumed for running.
Embodied Impacts: These are static impacts which are caused by the creation (manufacturing) of the respective entity. The embodied impacts represent the starting balance.
Indirect Impacts: We use this account to describe the indirect impacts caused by a given entity, e.g. if a rack is to be running, this requires a data center facility. If that facility can house 100 racks, than each rack has an indirect impact of a 100th of the direct impacts of the facility. We do this, so that each entity can be assessed on it’s own, while making the indirect impacts visible on each entity as well.
Useful Life: Each entity has a useful life, for which we assign reasonable defaults. The useful life is expressed in years.
Now the complexity lies in the following chain of calculations:
Calculating the starting balance of Embodied Impacts for each entity
Accurately recording the Operational Impacts for each entity
Proportionally allocating the Impacts to the Account of the application, depending on the actual usage of all entities by the application.
For the allocation, taking into account both virtualization as well as spanning applications across multiple data centers and servers (e.g. with many virtual machines or Kubernetes clusters/pods)
So let’s start with loading the impact accounts of the different entities. Please note that this calculation model is meant to allow a each entity to stand on it’s own, measuring as direct impacts the ones the entity is responsible for. All the account balances are eventually added up when allocating them to application as direct and indirect impacts. It is possible to use this model on a data center facility, a rack or a server individually. This is important as many actors in the digital infrastructure are ‘broken up’ across the value-chain, e.g. a co-location operator only owns & runs the facility, an IT infrastructure provider might rent a rack to install their own servers, a customer might
The model does outline the interdependencies between the entity, e.g. to calculate the GHG emissions for the energy use of a rack, the data center facility must provide the emission factor of the grid or on-site power generation.
Introduction
In this paper, we want to show an end-to-end model for accounting the environmental impact of a software application (’application’) we will use the example of an AI model & service to illustrate this. The main idea of this work is that an application maintains an environmental impact account, similar to a bank account, where the environmental impacts are accumulated over the life cycle of the application.
To improve the readability of the document, we use a specific language and words that hide some of the complexity. Here is an overview of the concepts behind the words:
Digital Resources: Capacity to compute, store and transfer data as produced by a server entity from energy.
Digital Resource Type: When we talk about types for digital resources in this document, we refer to compute, storage and network resources as ‘types of digital resources’.
Entity: We refer to the different entities in the value-chain of infrastructure required to run a software application. These entities are: Data Center Facility (Building), Rack (housing servers and network equipment), Server (IT equipment producing computing, storage or networking capacity), Client Device (e.g. Laptop or Phone). For now we exclude networking equipment.
Account: Akin to a bank account, it’s a multi-value ‘bucket’ where the environmental impacts are accumulated for an entity (see below).
The environmental impact indicators are always the same for each entity, and are a listed at the end of the document.
For sake of simplicity we refer to them as Operational, Embodied and Indirect Impacts, see the definitions below.
Each entity has two sub-accounts: Productive Impacts and Non-Productive Impacts. The goal of each entity should be to minimize the non-productive impacts and overall ensure the account balance doesn’t rise (or to slow down the accumulation of impacts)
All the accounts in this paper are cumulative, annual accounts. This means that the Embodied Impacts are allocated to each entity according to the Useful Life of that entity at the beginning of the year as a starting balance. The Operational Impacts over the year are then added cumulatively to the account. At the end of a year (or other period), the total account balance can be retrieved. Technically, the time-resolution can be anything from an hour to ten years, but for the sake of this paper, we stick to the annual resolution as it makes the examples more clear.
Productive Impact: Productive impacts are caused by the entity providing useful work, e.g. a server might use energy to perform computation for an application.
Non-Productive Impacts: Arise from an entity being operational/running but not performing useful work, e.g. a server might be idling but still consuming energy or a data center might be half-empty, which will lead to half it’s embodied impact to be attributed as non-productive.
Useful Work: We consider useful work performed on the last step of the value-creation chain. A server entity provisions digital resources. These are by default Non-Productive. The server, when running and provisioning resources, consumes energy. This changes when an application uses those provisioned resources, in which case they become productive. The goal of the server provisioning, virtualization or orchestration systems is to maximize the amount of productive resource usage.
Operational Impacts: These are environmental impacts which are created by the operation of the entity - in the case of the data center facility, this might be energy and associated GHG emissions for operating the cooling systems; for a server, it may be the energy consumed for running.
Embodied Impacts: These are static impacts which are caused by the creation (manufacturing) of the respective entity. The embodied impacts represent the starting balance.
Indirect Impacts: We use this account to describe the indirect impacts caused by a given entity, e.g. if a rack is to be running, this requires a data center facility. If that facility can house 100 racks, than each rack has an indirect impact of a 100th of the direct impacts of the facility. We do this, so that each entity can be assessed on it’s own, while making the indirect impacts visible on each entity as well.
Useful Life: Each entity has a useful life, for which we assign reasonable defaults. The useful life is expressed in years.
Now the complexity lies in the following chain of calculations:
Calculating the starting balance of Embodied Impacts for each entity
Accurately recording the Operational Impacts for each entity
Proportionally allocating the Impacts to the Account of the application, depending on the actual usage of all entities by the application.
For the allocation, taking into account both virtualization as well as spanning applications across multiple data centers and servers (e.g. with many virtual machines or Kubernetes clusters/pods)
So let’s start with loading the impact accounts of the different entities. Please note that this calculation model is meant to allow a each entity to stand on it’s own, measuring as direct impacts the ones the entity is responsible for. All the account balances are eventually added up when allocating them to application as direct and indirect impacts. It is possible to use this model on a data center facility, a rack or a server individually. This is important as many actors in the digital infrastructure are ‘broken up’ across the value-chain, e.g. a co-location operator only owns & runs the facility, an IT infrastructure provider might rent a rack to install their own servers, a customer might
The model does outline the interdependencies between the entity, e.g. to calculate the GHG emissions for the energy use of a rack, the data center facility must provide the emission factor of the grid or on-site power generation.
Introduction
In this paper, we want to show an end-to-end model for accounting the environmental impact of a software application (’application’) we will use the example of an AI model & service to illustrate this. The main idea of this work is that an application maintains an environmental impact account, similar to a bank account, where the environmental impacts are accumulated over the life cycle of the application.
To improve the readability of the document, we use a specific language and words that hide some of the complexity. Here is an overview of the concepts behind the words:
Digital Resources: Capacity to compute, store and transfer data as produced by a server entity from energy.
Digital Resource Type: When we talk about types for digital resources in this document, we refer to compute, storage and network resources as ‘types of digital resources’.
Entity: We refer to the different entities in the value-chain of infrastructure required to run a software application. These entities are: Data Center Facility (Building), Rack (housing servers and network equipment), Server (IT equipment producing computing, storage or networking capacity), Client Device (e.g. Laptop or Phone). For now we exclude networking equipment.
Account: Akin to a bank account, it’s a multi-value ‘bucket’ where the environmental impacts are accumulated for an entity (see below).
The environmental impact indicators are always the same for each entity, and are a listed at the end of the document.
For sake of simplicity we refer to them as Operational, Embodied and Indirect Impacts, see the definitions below.
Each entity has two sub-accounts: Productive Impacts and Non-Productive Impacts. The goal of each entity should be to minimize the non-productive impacts and overall ensure the account balance doesn’t rise (or to slow down the accumulation of impacts)
All the accounts in this paper are cumulative, annual accounts. This means that the Embodied Impacts are allocated to each entity according to the Useful Life of that entity at the beginning of the year as a starting balance. The Operational Impacts over the year are then added cumulatively to the account. At the end of a year (or other period), the total account balance can be retrieved. Technically, the time-resolution can be anything from an hour to ten years, but for the sake of this paper, we stick to the annual resolution as it makes the examples more clear.
Productive Impact: Productive impacts are caused by the entity providing useful work, e.g. a server might use energy to perform computation for an application.
Non-Productive Impacts: Arise from an entity being operational/running but not performing useful work, e.g. a server might be idling but still consuming energy or a data center might be half-empty, which will lead to half it’s embodied impact to be attributed as non-productive.
Useful Work: We consider useful work performed on the last step of the value-creation chain. A server entity provisions digital resources. These are by default Non-Productive. The server, when running and provisioning resources, consumes energy. This changes when an application uses those provisioned resources, in which case they become productive. The goal of the server provisioning, virtualization or orchestration systems is to maximize the amount of productive resource usage.
Operational Impacts: These are environmental impacts which are created by the operation of the entity - in the case of the data center facility, this might be energy and associated GHG emissions for operating the cooling systems; for a server, it may be the energy consumed for running.
Embodied Impacts: These are static impacts which are caused by the creation (manufacturing) of the respective entity. The embodied impacts represent the starting balance.
Indirect Impacts: We use this account to describe the indirect impacts caused by a given entity, e.g. if a rack is to be running, this requires a data center facility. If that facility can house 100 racks, than each rack has an indirect impact of a 100th of the direct impacts of the facility. We do this, so that each entity can be assessed on it’s own, while making the indirect impacts visible on each entity as well.
Useful Life: Each entity has a useful life, for which we assign reasonable defaults. The useful life is expressed in years.
Now the complexity lies in the following chain of calculations:
Calculating the starting balance of Embodied Impacts for each entity
Accurately recording the Operational Impacts for each entity
Proportionally allocating the Impacts to the Account of the application, depending on the actual usage of all entities by the application.
For the allocation, taking into account both virtualization as well as spanning applications across multiple data centers and servers (e.g. with many virtual machines or Kubernetes clusters/pods)
So let’s start with loading the impact accounts of the different entities. Please note that this calculation model is meant to allow a each entity to stand on it’s own, measuring as direct impacts the ones the entity is responsible for. All the account balances are eventually added up when allocating them to application as direct and indirect impacts. It is possible to use this model on a data center facility, a rack or a server individually. This is important as many actors in the digital infrastructure are ‘broken up’ across the value-chain, e.g. a co-location operator only owns & runs the facility, an IT infrastructure provider might rent a rack to install their own servers, a customer might
The model does outline the interdependencies between the entity, e.g. to calculate the GHG emissions for the energy use of a rack, the data center facility must provide the emission factor of the grid or on-site power generation.
Calculating the starting balance of each environmental impact account per entity.
If we use electrons as our ‘guiding path’, the entities through which the electrons are flowing are:
The Data Center Facility
Electrons travel from grid or generators to switchgear to the UPS batteries and from there to the PDUs of the racks
Some electrons are converted into thermal energy by cooling systems (overhead)
Some electrons are diverted to auxilliary systems like lighting or security systems (overhead)
The Rack
Electrons arrive from the UPS systems at the rack and are given to the Power Distribution Units (PDUs)
The Server
Servers are plugged into the PDUs (usually two or more plugs for redundancy)
The Server also receives the thermal energy (made from electrons) from the facility through cold air pushed through the floor of the rack
Digital Resource
The server converts the electrons into a computing capacity by powering a CPU or GPU as well as memory chips (both the writing/reading and the persistence), storage disks and a networking card.
At this point, the electrons become computing, storage and network capacity (and thermal output, heat, which is the lost energy) which can be utilized by a digital application. The application doesn’t per-se know about electrons–it knows about digital resources it requires to run and consumes.
Calculating the starting balance of each environmental impact account per entity.
If we use electrons as our ‘guiding path’, the entities through which the electrons are flowing are:
The Data Center Facility
Electrons travel from grid or generators to switchgear to the UPS batteries and from there to the PDUs of the racks
Some electrons are converted into thermal energy by cooling systems (overhead)
Some electrons are diverted to auxilliary systems like lighting or security systems (overhead)
The Rack
Electrons arrive from the UPS systems at the rack and are given to the Power Distribution Units (PDUs)
The Server
Servers are plugged into the PDUs (usually two or more plugs for redundancy)
The Server also receives the thermal energy (made from electrons) from the facility through cold air pushed through the floor of the rack
Digital Resource
The server converts the electrons into a computing capacity by powering a CPU or GPU as well as memory chips (both the writing/reading and the persistence), storage disks and a networking card.
At this point, the electrons become computing, storage and network capacity (and thermal output, heat, which is the lost energy) which can be utilized by a digital application. The application doesn’t per-se know about electrons–it knows about digital resources it requires to run and consumes.
Calculating the starting balance of each environmental impact account per entity.
If we use electrons as our ‘guiding path’, the entities through which the electrons are flowing are:
The Data Center Facility
Electrons travel from grid or generators to switchgear to the UPS batteries and from there to the PDUs of the racks
Some electrons are converted into thermal energy by cooling systems (overhead)
Some electrons are diverted to auxilliary systems like lighting or security systems (overhead)
The Rack
Electrons arrive from the UPS systems at the rack and are given to the Power Distribution Units (PDUs)
The Server
Servers are plugged into the PDUs (usually two or more plugs for redundancy)
The Server also receives the thermal energy (made from electrons) from the facility through cold air pushed through the floor of the rack
Digital Resource
The server converts the electrons into a computing capacity by powering a CPU or GPU as well as memory chips (both the writing/reading and the persistence), storage disks and a networking card.
At this point, the electrons become computing, storage and network capacity (and thermal output, heat, which is the lost energy) which can be utilized by a digital application. The application doesn’t per-se know about electrons–it knows about digital resources it requires to run and consumes.
Data Center Facility
As the first step we need to determine the starting balance of the account of the data center facility. This means determining the Embodied Impact of the facility.To do this we need to consider the following components of the facility. If you can’t get this data from the facility, we have put together a reasonable default assumption based on public information that you can use.
Data Center Facility
As the first step we need to determine the starting balance of the account of the data center facility. This means determining the Embodied Impact of the facility.To do this we need to consider the following components of the facility. If you can’t get this data from the facility, we have put together a reasonable default assumption based on public information that you can use.
Data Center Facility
As the first step we need to determine the starting balance of the account of the data center facility. This means determining the Embodied Impact of the facility.To do this we need to consider the following components of the facility. If you can’t get this data from the facility, we have put together a reasonable default assumption based on public information that you can use.
If a data center has a BREEAM certification for the building, they also have a Life Cycle Assessment for the facility, which you should request from them.
If a data center has a BREEAM certification for the building, they also have a Life Cycle Assessment for the facility, which you should request from them.
If a data center has a BREEAM certification for the building, they also have a Life Cycle Assessment for the facility, which you should request from them.
Lifetime: 15 years (default assumption)
Note that if a data center facility owner commits to use the facility for 20 or 25 years, this reduces the annual starting balance of the facility and reducing the impact per year (and thus also for the application as we will see later). This is desired, as extending the lifetime of all entities is a primary objective toward sustainability.
UPS System
For the batteries or other UPS components we need to get a Life Cycle Assessment (LCA), or even better an Environmental Product Declaration (EPD) that includes the required information and has been independently verified. See an example here. (PDF)
Grid replacement generators (diesel, gas)
When the primary power source, usually the power grid, has an outage, data centers have grid replacements on site that kick-in while the UPS batteries bridge the time until these generators have started.
For each generator, we require also an LCA or EPD to add them to the account balance of the facility. See an example here. (PDF)
On-site generation assets
The facility might have on-site power generation capacity, such as solar panels or hydrogen fuel cells.
For these components also an LCA or EPD is required to add their Embodied Impacts to the starting balance of the facility account.
Building (shell, supporting infrastructure, floors, …)
A data center facility is a building made from cement, concrete, steel among other building materials. When the facility is certified with BREEAM, these certifications require to have a total LCA available for the facility.
The LCA information on the Embodied Impacts should be added to the starting balance of the facility account.
Cooling system (inside the whitespace/air handlers, transport, e.g. pumps, heat exchangers, chillers, cooling fluids)
For each component of the cooling system, an LCA or EPD should be procured, like this example (PDF).
In addition, the total amount of cooling fluids and types should be determined to calculate the Embodied Impacts of the fluids used in the facility. You can use our table here to assess the impacts of the fluids.
Air treatment systems (humidification/dehumidification)
Most data center facilities treat the air inside the white space (the area which is housing the IT equipment) to avoid high/low humidity that might damage the equipment.
For these systems an LCA or EPD should be present and added to the starting balance of the facility. We don’t know any vendor publishing one, but here is an example of a product in use.
Fire extinguishing systems
Most facilities have either gas or water-based fire extinguishing systems in place. For these an LCA or EPD should be present to be able to determine the Embodied Impact.
It might be necessary to assess the Embodied Impact of the gas/chemicals used separately based on the volume used in the extinguishing system.
Here is an example product using a gas to suppress fires.
When the data from all the components is collected it can be added up. This will be the total Embodied Impact of the facility. This should then be divided by the Lifetime of the facility to get the annual starting balance. If the facility is empty, meaning there is no IT equipment in the facility; the starting balance for the first year might look like this:
Facility Total Embodied Impact over Lifetime: 15.000 units
Facility Environmental Impact Account (year 1): 1.000 units
Non-Productive Impact: 1.000 units
Productive Impact: 0 units
We will add the operational impacts to this account further below in the respective section. For now we have built the base account balance for the facility that is exists irrespective of the usage of the facility.
Lifetime: 15 years (default assumption)
Note that if a data center facility owner commits to use the facility for 20 or 25 years, this reduces the annual starting balance of the facility and reducing the impact per year (and thus also for the application as we will see later). This is desired, as extending the lifetime of all entities is a primary objective toward sustainability.
UPS System
For the batteries or other UPS components we need to get a Life Cycle Assessment (LCA), or even better an Environmental Product Declaration (EPD) that includes the required information and has been independently verified. See an example here. (PDF)
Grid replacement generators (diesel, gas)
When the primary power source, usually the power grid, has an outage, data centers have grid replacements on site that kick-in while the UPS batteries bridge the time until these generators have started.
For each generator, we require also an LCA or EPD to add them to the account balance of the facility. See an example here. (PDF)
On-site generation assets
The facility might have on-site power generation capacity, such as solar panels or hydrogen fuel cells.
For these components also an LCA or EPD is required to add their Embodied Impacts to the starting balance of the facility account.
Building (shell, supporting infrastructure, floors, …)
A data center facility is a building made from cement, concrete, steel among other building materials. When the facility is certified with BREEAM, these certifications require to have a total LCA available for the facility.
The LCA information on the Embodied Impacts should be added to the starting balance of the facility account.
Cooling system (inside the whitespace/air handlers, transport, e.g. pumps, heat exchangers, chillers, cooling fluids)
For each component of the cooling system, an LCA or EPD should be procured, like this example (PDF).
In addition, the total amount of cooling fluids and types should be determined to calculate the Embodied Impacts of the fluids used in the facility. You can use our table here to assess the impacts of the fluids.
Air treatment systems (humidification/dehumidification)
Most data center facilities treat the air inside the white space (the area which is housing the IT equipment) to avoid high/low humidity that might damage the equipment.
For these systems an LCA or EPD should be present and added to the starting balance of the facility. We don’t know any vendor publishing one, but here is an example of a product in use.
Fire extinguishing systems
Most facilities have either gas or water-based fire extinguishing systems in place. For these an LCA or EPD should be present to be able to determine the Embodied Impact.
It might be necessary to assess the Embodied Impact of the gas/chemicals used separately based on the volume used in the extinguishing system.
Here is an example product using a gas to suppress fires.
When the data from all the components is collected it can be added up. This will be the total Embodied Impact of the facility. This should then be divided by the Lifetime of the facility to get the annual starting balance. If the facility is empty, meaning there is no IT equipment in the facility; the starting balance for the first year might look like this:
Facility Total Embodied Impact over Lifetime: 15.000 units
Facility Environmental Impact Account (year 1): 1.000 units
Non-Productive Impact: 1.000 units
Productive Impact: 0 units
We will add the operational impacts to this account further below in the respective section. For now we have built the base account balance for the facility that is exists irrespective of the usage of the facility.
Lifetime: 15 years (default assumption)
Note that if a data center facility owner commits to use the facility for 20 or 25 years, this reduces the annual starting balance of the facility and reducing the impact per year (and thus also for the application as we will see later). This is desired, as extending the lifetime of all entities is a primary objective toward sustainability.
UPS System
For the batteries or other UPS components we need to get a Life Cycle Assessment (LCA), or even better an Environmental Product Declaration (EPD) that includes the required information and has been independently verified. See an example here. (PDF)
Grid replacement generators (diesel, gas)
When the primary power source, usually the power grid, has an outage, data centers have grid replacements on site that kick-in while the UPS batteries bridge the time until these generators have started.
For each generator, we require also an LCA or EPD to add them to the account balance of the facility. See an example here. (PDF)
On-site generation assets
The facility might have on-site power generation capacity, such as solar panels or hydrogen fuel cells.
For these components also an LCA or EPD is required to add their Embodied Impacts to the starting balance of the facility account.
Building (shell, supporting infrastructure, floors, …)
A data center facility is a building made from cement, concrete, steel among other building materials. When the facility is certified with BREEAM, these certifications require to have a total LCA available for the facility.
The LCA information on the Embodied Impacts should be added to the starting balance of the facility account.
Cooling system (inside the whitespace/air handlers, transport, e.g. pumps, heat exchangers, chillers, cooling fluids)
For each component of the cooling system, an LCA or EPD should be procured, like this example (PDF).
In addition, the total amount of cooling fluids and types should be determined to calculate the Embodied Impacts of the fluids used in the facility. You can use our table here to assess the impacts of the fluids.
Air treatment systems (humidification/dehumidification)
Most data center facilities treat the air inside the white space (the area which is housing the IT equipment) to avoid high/low humidity that might damage the equipment.
For these systems an LCA or EPD should be present and added to the starting balance of the facility. We don’t know any vendor publishing one, but here is an example of a product in use.
Fire extinguishing systems
Most facilities have either gas or water-based fire extinguishing systems in place. For these an LCA or EPD should be present to be able to determine the Embodied Impact.
It might be necessary to assess the Embodied Impact of the gas/chemicals used separately based on the volume used in the extinguishing system.
Here is an example product using a gas to suppress fires.
When the data from all the components is collected it can be added up. This will be the total Embodied Impact of the facility. This should then be divided by the Lifetime of the facility to get the annual starting balance. If the facility is empty, meaning there is no IT equipment in the facility; the starting balance for the first year might look like this:
Facility Total Embodied Impact over Lifetime: 15.000 units
Facility Environmental Impact Account (year 1): 1.000 units
Non-Productive Impact: 1.000 units
Productive Impact: 0 units
We will add the operational impacts to this account further below in the respective section. For now we have built the base account balance for the facility that is exists irrespective of the usage of the facility.
Rack
For the racks we run through the same process as for the facility. For each rack we need to collect the following information to determine the total embodied impact and thus the calculate the annual starting balance of each rack.
Useful Lifetime: 15 Years (default assumption)
Again, increasing the expected/committed lifetime will reduce the annual starting balance, which is a desired effect as we want to maximize the lifetime of the equipment.
PDUs
For each PDU an LCA or EPD should be available so that the Embodied Impacts for each PDU can be accounted for.
UPS Battery
Some racks might contain their own, dedicated UPS battery.
If this is the case, an LCA or EPD should be available for the battery, so that the total Embodied Impact can be determined for the rack
Rack Shelf
Racks are usually steel shelves for which can LCA or EPD should be collected. The embodied impacts from manufacturing the shelf should be added to the rack account.
Once this information is collected, we can again calculate the Rack Total Embodied Impact and divide it by the useful lifetime in years to get the annual starting balance for the rack’s environmental impact account.
If the rack is empty, the balance on the account might look like this:
Rack Total Embodied Impact over Lifetime: 1.500 units
Rack Environmental Impact Account (year 1): 100 units
Non-Productive Impact: 100 units
Productive Impact: 0 units
Rack
For the racks we run through the same process as for the facility. For each rack we need to collect the following information to determine the total embodied impact and thus the calculate the annual starting balance of each rack.
Useful Lifetime: 15 Years (default assumption)
Again, increasing the expected/committed lifetime will reduce the annual starting balance, which is a desired effect as we want to maximize the lifetime of the equipment.
PDUs
For each PDU an LCA or EPD should be available so that the Embodied Impacts for each PDU can be accounted for.
UPS Battery
Some racks might contain their own, dedicated UPS battery.
If this is the case, an LCA or EPD should be available for the battery, so that the total Embodied Impact can be determined for the rack
Rack Shelf
Racks are usually steel shelves for which can LCA or EPD should be collected. The embodied impacts from manufacturing the shelf should be added to the rack account.
Once this information is collected, we can again calculate the Rack Total Embodied Impact and divide it by the useful lifetime in years to get the annual starting balance for the rack’s environmental impact account.
If the rack is empty, the balance on the account might look like this:
Rack Total Embodied Impact over Lifetime: 1.500 units
Rack Environmental Impact Account (year 1): 100 units
Non-Productive Impact: 100 units
Productive Impact: 0 units
Rack
For the racks we run through the same process as for the facility. For each rack we need to collect the following information to determine the total embodied impact and thus the calculate the annual starting balance of each rack.
Useful Lifetime: 15 Years (default assumption)
Again, increasing the expected/committed lifetime will reduce the annual starting balance, which is a desired effect as we want to maximize the lifetime of the equipment.
PDUs
For each PDU an LCA or EPD should be available so that the Embodied Impacts for each PDU can be accounted for.
UPS Battery
Some racks might contain their own, dedicated UPS battery.
If this is the case, an LCA or EPD should be available for the battery, so that the total Embodied Impact can be determined for the rack
Rack Shelf
Racks are usually steel shelves for which can LCA or EPD should be collected. The embodied impacts from manufacturing the shelf should be added to the rack account.
Once this information is collected, we can again calculate the Rack Total Embodied Impact and divide it by the useful lifetime in years to get the annual starting balance for the rack’s environmental impact account.
If the rack is empty, the balance on the account might look like this:
Rack Total Embodied Impact over Lifetime: 1.500 units
Rack Environmental Impact Account (year 1): 100 units
Non-Productive Impact: 100 units
Productive Impact: 0 units
Server
The servers, in principle, should be the simplest to determine the starting impact for, as they are a single product by a single vendor. Unfortunately, not all vendors provide LCAs or EPDs for each product. Luckily there is a plentitude of APIs, most notably the Boavizta API, which can be used to get an estimated for the Embodied Impacts of any server model.
So for the server, we can determine the starting balance like this:
Useful Lifetime: 5 Years
As with the rack and facility, increasing the expected/committed lifetime will reduce the annual starting balance, which is a desired effect as we want to maximize the lifetime of the equipment.
Server Hardware
Ideally an LCA or EPD should be collected for the specific server model. Here is an example for a Dell PowerEdge R740 (PDF)
If that is not available, using the specifications of the server (CPU model, memory, storage, etc.) an estimation can be generated via the Boavizta API or other databases.
With this information, we can calculate the Server Total Embodied Impact and divide it by the lifetime to determine the annual starting balance for the server. For the sake of this calculation, assume that the server is turned off.
Server Total Embodied Impact over Lifetime: 1.500 units
Server Environmental Impact Account (year 1): 300 units
Non-Productive Impact: 300 units
Productive Impact: 0 units
Server
The servers, in principle, should be the simplest to determine the starting impact for, as they are a single product by a single vendor. Unfortunately, not all vendors provide LCAs or EPDs for each product. Luckily there is a plentitude of APIs, most notably the Boavizta API, which can be used to get an estimated for the Embodied Impacts of any server model.
So for the server, we can determine the starting balance like this:
Useful Lifetime: 5 Years
As with the rack and facility, increasing the expected/committed lifetime will reduce the annual starting balance, which is a desired effect as we want to maximize the lifetime of the equipment.
Server Hardware
Ideally an LCA or EPD should be collected for the specific server model. Here is an example for a Dell PowerEdge R740 (PDF)
If that is not available, using the specifications of the server (CPU model, memory, storage, etc.) an estimation can be generated via the Boavizta API or other databases.
With this information, we can calculate the Server Total Embodied Impact and divide it by the lifetime to determine the annual starting balance for the server. For the sake of this calculation, assume that the server is turned off.
Server Total Embodied Impact over Lifetime: 1.500 units
Server Environmental Impact Account (year 1): 300 units
Non-Productive Impact: 300 units
Productive Impact: 0 units
Server
The servers, in principle, should be the simplest to determine the starting impact for, as they are a single product by a single vendor. Unfortunately, not all vendors provide LCAs or EPDs for each product. Luckily there is a plentitude of APIs, most notably the Boavizta API, which can be used to get an estimated for the Embodied Impacts of any server model.
So for the server, we can determine the starting balance like this:
Useful Lifetime: 5 Years
As with the rack and facility, increasing the expected/committed lifetime will reduce the annual starting balance, which is a desired effect as we want to maximize the lifetime of the equipment.
Server Hardware
Ideally an LCA or EPD should be collected for the specific server model. Here is an example for a Dell PowerEdge R740 (PDF)
If that is not available, using the specifications of the server (CPU model, memory, storage, etc.) an estimation can be generated via the Boavizta API or other databases.
With this information, we can calculate the Server Total Embodied Impact and divide it by the lifetime to determine the annual starting balance for the server. For the sake of this calculation, assume that the server is turned off.
Server Total Embodied Impact over Lifetime: 1.500 units
Server Environmental Impact Account (year 1): 300 units
Non-Productive Impact: 300 units
Productive Impact: 0 units
Digital Resources
As digital resources do not physically exist–they only come into existence when the server is powered on and their Embodied Impact is equal to the server’s impact, we don’t set a starting balance for digital resources.
Digital Resources
As digital resources do not physically exist–they only come into existence when the server is powered on and their Embodied Impact is equal to the server’s impact, we don’t set a starting balance for digital resources.
Digital Resources
As digital resources do not physically exist–they only come into existence when the server is powered on and their Embodied Impact is equal to the server’s impact, we don’t set a starting balance for digital resources.
Summary of Embodied Impacts
Now to summarize our environmental impact accounts in January 1, with a single rack in a data center facility and a turned-off server, looks like this:
Facility Environmental Impact Account (year 1): 1.000 units (15.000/15 Years)
Non-Productive Impact: 1.000 units
Productive Impact: 0 units
Rack Environmental Impact Account (year 1): 100 units (1.500/15 Years)
Non-Productive Impact: 100 units
Productive Impact: 0 units
Server Environmental Impact Account (year 1): 300 units (1.500/5 Years)
Non-Productive Impact: 300 units
Productive Impact: 0 units
Summary of Embodied Impacts
Now to summarize our environmental impact accounts in January 1, with a single rack in a data center facility and a turned-off server, looks like this:
Facility Environmental Impact Account (year 1): 1.000 units (15.000/15 Years)
Non-Productive Impact: 1.000 units
Productive Impact: 0 units
Rack Environmental Impact Account (year 1): 100 units (1.500/15 Years)
Non-Productive Impact: 100 units
Productive Impact: 0 units
Server Environmental Impact Account (year 1): 300 units (1.500/5 Years)
Non-Productive Impact: 300 units
Productive Impact: 0 units
Summary of Embodied Impacts
Now to summarize our environmental impact accounts in January 1, with a single rack in a data center facility and a turned-off server, looks like this:
Facility Environmental Impact Account (year 1): 1.000 units (15.000/15 Years)
Non-Productive Impact: 1.000 units
Productive Impact: 0 units
Rack Environmental Impact Account (year 1): 100 units (1.500/15 Years)
Non-Productive Impact: 100 units
Productive Impact: 0 units
Server Environmental Impact Account (year 1): 300 units (1.500/5 Years)
Non-Productive Impact: 300 units
Productive Impact: 0 units
Summary of Embodied Impacts
Now to summarize our environmental impact accounts in January 1, with a single rack in a data center facility and a turned-off server, looks like this:
Facility Environmental Impact Account (year 1): 1.000 units (15.000/15 Years)
Non-Productive Impact: 1.000 units
Productive Impact: 0 units
Rack Environmental Impact Account (year 1): 100 units (1.500/15 Years)
Non-Productive Impact: 100 units
Productive Impact: 0 units
Server Environmental Impact Account (year 1): 300 units (1.500/5 Years)
Non-Productive Impact: 300 units
Productive Impact: 0 units
Summary of Embodied Impacts
Now to summarize our environmental impact accounts in January 1, with a single rack in a data center facility and a turned-off server, looks like this:
Facility Environmental Impact Account (year 1): 1.000 units (15.000/15 Years)
Non-Productive Impact: 1.000 units
Productive Impact: 0 units
Rack Environmental Impact Account (year 1): 100 units (1.500/15 Years)
Non-Productive Impact: 100 units
Productive Impact: 0 units
Server Environmental Impact Account (year 1): 300 units (1.500/5 Years)
Non-Productive Impact: 300 units
Productive Impact: 0 units
Summary of Embodied Impacts
Now to summarize our environmental impact accounts in January 1, with a single rack in a data center facility and a turned-off server, looks like this:
Facility Environmental Impact Account (year 1): 1.000 units (15.000/15 Years)
Non-Productive Impact: 1.000 units
Productive Impact: 0 units
Rack Environmental Impact Account (year 1): 100 units (1.500/15 Years)
Non-Productive Impact: 100 units
Productive Impact: 0 units
Server Environmental Impact Account (year 1): 300 units (1.500/5 Years)
Non-Productive Impact: 300 units
Productive Impact: 0 units
Adding the operational impacts to the environmental impact accounts
That was the easy part. Now let’s add the operational impacts of each entity to the balance. These are the measurements that likely vary throughout the year and need to actually measured in each entity and the measurements added on at least an hourly scale to the accounts.
The challenge is that some operational impacts can have a positive or negative impact on the balance, which needs to be calculated for each entity using dedicated logic. Measuring alone is not sufficient, a conversion and first allocation to the right impact indicator is needed. In our list of metrics for each entity, we include explanations on those conversions. We use the same list of entities as in the previous chapter.
Adding the operational impacts to the environmental impact accounts
That was the easy part. Now let’s add the operational impacts of each entity to the balance. These are the measurements that likely vary throughout the year and need to actually measured in each entity and the measurements added on at least an hourly scale to the accounts.
The challenge is that some operational impacts can have a positive or negative impact on the balance, which needs to be calculated for each entity using dedicated logic. Measuring alone is not sufficient, a conversion and first allocation to the right impact indicator is needed. In our list of metrics for each entity, we include explanations on those conversions. We use the same list of entities as in the previous chapter.
Adding the operational impacts to the environmental impact accounts
That was the easy part. Now let’s add the operational impacts of each entity to the balance. These are the measurements that likely vary throughout the year and need to actually measured in each entity and the measurements added on at least an hourly scale to the accounts.
The challenge is that some operational impacts can have a positive or negative impact on the balance, which needs to be calculated for each entity using dedicated logic. Measuring alone is not sufficient, a conversion and first allocation to the right impact indicator is needed. In our list of metrics for each entity, we include explanations on those conversions. We use the same list of entities as in the previous chapter.
Data Center Facility
For the facility, the calculation is straightforward and mostly focusses on energy, water and waste. The main challenge is to differentiate the various energy sources, such as local generation, nearby renewable generation as well as the fuel of local generation (e.g. when the diesel generators are running). This is relevant to calculate the GHG impact indicator from the energy use.
Data Center Operational Impact:
Total Non-IT Energy Use (kWh, measured at the output of the UPS system)
This should measure the power consumption of all overhead-related activities, such as cooling, lighting and losses in the electrical and mechanical equipment
Total Renewable Energy Production (kWh), broken down by
on-site renewable energy generation: kWh and Type (e.g. Solar Panels)
physical power contracts (meaning the output of of the power generation is bought directly by the facility) with renewable energy sources in a 50km radius: kWh and Type (e.g. Wind)
If the total production covers 100% of the Non-IT Energy Use, the GHG Emissions can be considered 0, essentially not adding any GHG Emissions to the operational balance (energy is still added, see list of environmental impact indicators)
Total Non-Renewable Energy Production (kWh), broken down by
energy produced by on-site diesel generators (kWh and fuel type)
fuel type should be used to calculate the emission factor, you can find a a list here.
energy procured by the grid (kWh)
a grid emission factor will have to be procured either from historical data (EEA) or via APIs like the Electricity Map API.
Total Waste Disposed, broken down by
see the overview of waste categories that need to be accounted for in the Appendix.
In principle, the following waste streams should be considered: Packaging, electrical components, cooling liquids, other fluid & chemical waste, mechanical components and any other components that exit the data center
Total Freshwater Consumption (m3)
this should be measured via a water-meter or through invoices provided by the water utility. Any freshwater use should be considered here - be it for evaporative cooling or to fill up other water systems.
Data Center Facility
For the facility, the calculation is straightforward and mostly focusses on energy, water and waste. The main challenge is to differentiate the various energy sources, such as local generation, nearby renewable generation as well as the fuel of local generation (e.g. when the diesel generators are running). This is relevant to calculate the GHG impact indicator from the energy use.
Data Center Operational Impact:
Total Non-IT Energy Use (kWh, measured at the output of the UPS system)
This should measure the power consumption of all overhead-related activities, such as cooling, lighting and losses in the electrical and mechanical equipment
Total Renewable Energy Production (kWh), broken down by
on-site renewable energy generation: kWh and Type (e.g. Solar Panels)
physical power contracts (meaning the output of of the power generation is bought directly by the facility) with renewable energy sources in a 50km radius: kWh and Type (e.g. Wind)
If the total production covers 100% of the Non-IT Energy Use, the GHG Emissions can be considered 0, essentially not adding any GHG Emissions to the operational balance (energy is still added, see list of environmental impact indicators)
Total Non-Renewable Energy Production (kWh), broken down by
energy produced by on-site diesel generators (kWh and fuel type)
fuel type should be used to calculate the emission factor, you can find a a list here.
energy procured by the grid (kWh)
a grid emission factor will have to be procured either from historical data (EEA) or via APIs like the Electricity Map API.
Total Waste Disposed, broken down by
see the overview of waste categories that need to be accounted for in the Appendix.
In principle, the following waste streams should be considered: Packaging, electrical components, cooling liquids, other fluid & chemical waste, mechanical components and any other components that exit the data center
Total Freshwater Consumption (m3)
this should be measured via a water-meter or through invoices provided by the water utility. Any freshwater use should be considered here - be it for evaporative cooling or to fill up other water systems.
Data Center Facility
For the facility, the calculation is straightforward and mostly focusses on energy, water and waste. The main challenge is to differentiate the various energy sources, such as local generation, nearby renewable generation as well as the fuel of local generation (e.g. when the diesel generators are running). This is relevant to calculate the GHG impact indicator from the energy use.
Data Center Operational Impact:
Total Non-IT Energy Use (kWh, measured at the output of the UPS system)
This should measure the power consumption of all overhead-related activities, such as cooling, lighting and losses in the electrical and mechanical equipment
Total Renewable Energy Production (kWh), broken down by
on-site renewable energy generation: kWh and Type (e.g. Solar Panels)
physical power contracts (meaning the output of of the power generation is bought directly by the facility) with renewable energy sources in a 50km radius: kWh and Type (e.g. Wind)
If the total production covers 100% of the Non-IT Energy Use, the GHG Emissions can be considered 0, essentially not adding any GHG Emissions to the operational balance (energy is still added, see list of environmental impact indicators)
Total Non-Renewable Energy Production (kWh), broken down by
energy produced by on-site diesel generators (kWh and fuel type)
fuel type should be used to calculate the emission factor, you can find a a list here.
energy procured by the grid (kWh)
a grid emission factor will have to be procured either from historical data (EEA) or via APIs like the Electricity Map API.
Total Waste Disposed, broken down by
see the overview of waste categories that need to be accounted for in the Appendix.
In principle, the following waste streams should be considered: Packaging, electrical components, cooling liquids, other fluid & chemical waste, mechanical components and any other components that exit the data center
Total Freshwater Consumption (m3)
this should be measured via a water-meter or through invoices provided by the water utility. Any freshwater use should be considered here - be it for evaporative cooling or to fill up other water systems.
Batteries can play a role in increasing the amount of renewable energy that can be absorbed and used by the facility. We hope to take this into account in a future revision of this document.
Batteries can play a role in increasing the amount of renewable energy that can be absorbed and used by the facility. We hope to take this into account in a future revision of this document.
Batteries can play a role in increasing the amount of renewable energy that can be absorbed and used by the facility. We hope to take this into account in a future revision of this document.
Again for now, we assume the facilities are empty, yet the cooling and other overhead systems are running and consume 10.000 kWh over a year. During that year, on-site solar panels generated 3.000 kWh and procurement of wind energy from a farm in a 50km radius contributed another 3.000 kWh of renewable energy to the balance sheet. During that year, the average grid emission factor was 1 kg of CO2-eq/kWh. The diesel generators were not running during that time.
This means the facility balance now should look something like this:
Facility Environmental Impact Account (Year 1):
Non-Productive Impact: 1.000 units
Embodied Impact: 1.000 units
Operational Impact:
Total Energy Use: 10.000 kWh
Total Non-Renewable Energy Use: 4.000 kWh (at 1 kg/CO2-eq)
Total Renewable Energy Use: 6.000 kWh (emission factor depending on type of production and own assumptions)
GHG Emissions: 4.000kg CO2-eq
Freshwater Use: 1.000 m3
Waste Disposed: 1.000 kg
Productive Impact: 0 units
We consider the impacts as productive, if the data center is filled with servers. If 100% of the available white space is covered with servers which are running, the operational and embodied impacts are 100% productive.
Again for now, we assume the facilities are empty, yet the cooling and other overhead systems are running and consume 10.000 kWh over a year. During that year, on-site solar panels generated 3.000 kWh and procurement of wind energy from a farm in a 50km radius contributed another 3.000 kWh of renewable energy to the balance sheet. During that year, the average grid emission factor was 1 kg of CO2-eq/kWh. The diesel generators were not running during that time.
This means the facility balance now should look something like this:
Facility Environmental Impact Account (Year 1):
Non-Productive Impact: 1.000 units
Embodied Impact: 1.000 units
Operational Impact:
Total Energy Use: 10.000 kWh
Total Non-Renewable Energy Use: 4.000 kWh (at 1 kg/CO2-eq)
Total Renewable Energy Use: 6.000 kWh (emission factor depending on type of production and own assumptions)
GHG Emissions: 4.000kg CO2-eq
Freshwater Use: 1.000 m3
Waste Disposed: 1.000 kg
Productive Impact: 0 units
We consider the impacts as productive, if the data center is filled with servers. If 100% of the available white space is covered with servers which are running, the operational and embodied impacts are 100% productive.
Again for now, we assume the facilities are empty, yet the cooling and other overhead systems are running and consume 10.000 kWh over a year. During that year, on-site solar panels generated 3.000 kWh and procurement of wind energy from a farm in a 50km radius contributed another 3.000 kWh of renewable energy to the balance sheet. During that year, the average grid emission factor was 1 kg of CO2-eq/kWh. The diesel generators were not running during that time.
This means the facility balance now should look something like this:
Facility Environmental Impact Account (Year 1):
Non-Productive Impact: 1.000 units
Embodied Impact: 1.000 units
Operational Impact:
Total Energy Use: 10.000 kWh
Total Non-Renewable Energy Use: 4.000 kWh (at 1 kg/CO2-eq)
Total Renewable Energy Use: 6.000 kWh (emission factor depending on type of production and own assumptions)
GHG Emissions: 4.000kg CO2-eq
Freshwater Use: 1.000 m3
Waste Disposed: 1.000 kg
Productive Impact: 0 units
We consider the impacts as productive, if the data center is filled with servers. If 100% of the available white space is covered with servers which are running, the operational and embodied impacts are 100% productive.
Rack
For the rack, the operational impacts are coming from the energy that is passed-thru the rack–both thermal and electrical energy. Further the rack inherits indirect impacts from the facility, e.g. the operational and embodied impacts from the facility are allocated to each rack in the facility (evenly). This allows the rack to have visibility (but not per-se responsibility) into the impacts it’s existence is causing ‘downstream’ in the value chain.
Rack
For the rack, the operational impacts are coming from the energy that is passed-thru the rack–both thermal and electrical energy. Further the rack inherits indirect impacts from the facility, e.g. the operational and embodied impacts from the facility are allocated to each rack in the facility (evenly). This allows the rack to have visibility (but not per-se responsibility) into the impacts it’s existence is causing ‘downstream’ in the value chain.
Rack
For the rack, the operational impacts are coming from the energy that is passed-thru the rack–both thermal and electrical energy. Further the rack inherits indirect impacts from the facility, e.g. the operational and embodied impacts from the facility are allocated to each rack in the facility (evenly). This allows the rack to have visibility (but not per-se responsibility) into the impacts it’s existence is causing ‘downstream’ in the value chain.
Important: You don’t need to measure the operational emissions of the rack if you have access to the servers for measurement. In this case, you can skip this step. Rack-level accounting is only needed for situations in which the measuring party cannot access server-level metrics.
Important: You don’t need to measure the operational emissions of the rack if you have access to the servers for measurement. In this case, you can skip this step. Rack-level accounting is only needed for situations in which the measuring party cannot access server-level metrics.
Important: You don’t need to measure the operational emissions of the rack if you have access to the servers for measurement. In this case, you can skip this step. Rack-level accounting is only needed for situations in which the measuring party cannot access server-level metrics.
Rack Operational Impact
Total Energy Input (kWh)
Measured using a power meter, this is the total electrical energy delivered to the rack’s PDUs for distribution to the servers.
Total Energy Use (kWh)
Measured through the PDUs, this is the total energy delivered to the servers of the rack.
Rack Design Capacity (kW)
Static value: How much power is the rack designed for to deliver to the servers
Total Thermal Energy Input (kWh)
Should be calculated using a temperature and/or airflow sensor at the bottom of the rack (or wherever the inlet is located for the cold air to flow through the rack)
Total Thermal Discharge (kWh)
Should be calculated using a temperature and/or airflow sensor at the back of the rack (or wherever the hottest point of air output is located)
Electricity to Thermal Conversion Efficiency (%)
At which efficiency do the air-handlers, heat exchangers and chillers turn 1 kWh of electricity into 1 kWh of thermal energy
Dependent Metrics from the Data Center Entity (see “Metrics that need to be exposed”)
Data Center Facility - Current Emission Factor (1 kg CO2-eq/kWh)
Data Center Facility - Total Rack Capacity at Facility (10)
Data Center Facility - Total Water Use (1.000 m3)
Data Center Facility - Total Waste Disposed (1.000 kg)
Data Center Facility - Power Usage Effectiveness (PUE, 1.6)
A rack is considered to be productive if the Rack Design Capacity and Total Energy Use are close to equal, as this means that the delivered power is fully utilized.
To calculate the all the impact (operational, embodied and indirect) of the rack, we need to have some metrics available from the data center, e.g. to attribute the total water consumption of the facility to a single rack. We do this by dividing the total impact values, by the number of racks that the facility can support, distributing the operational impacts of the facility evenly into the rack.
For the example calculation, we assume the facility only has capacity for 10 racks, and that the rack is 50% occupied (Rack Design Capacity/Total Energy Use). We assume that the rack has a design capacity of 5 kW.
Now the account might look like this (by the end of the year):
Non-Productive Impact:
Embodied Impact: 50 units
Operational Impact: 0 units (as the rack doesn’t consume the 50% unused power, it’s only the embodied impact that is ‘unproductive’)
Productive Impact:
Embodied Impact: 50 Units (this half of the rack is utilized, and therefore productive)
Operational Impact:
Total Energy Use: 21.900 kWh (5 kW @ 50% x 8760 hours per year)
GHG Emissions: 21.900 kg CO2-eq (Emission Factor: 1 kg CO2-eq/kWh from the Facility)
Indirect Impact (from the Facility):
Productive (50%)
Embodied Impact: 1.000 Units / 10 Racks = 100 Units per Rack * 50% Utilization = 50 Units
Operational Impact:
Freshwater Use: 100 m3 (1.000 m3 / 10 Rack - Total Rack Capacity at Facility) * 50% = 50 m3
Waste Disposed: 100 kg (1.000 kg / 10 Rack - Total Rack Capacity at Facility) * 50% = 50 kg
Energy Use (Facility Overhead): 2.5 kW * (1-PUE) * 8760 Hours = 8.760 kWh * 50% = 4.380 kWh
GHG Emissions (Facility Overhead): 4.380 kg CO2-eq (Overhead Power Utilized * Emission Factor)
Non-Productive (50%)
Embodied Impact: 1.000 Units / 10 Racks = 100 Units per Rack * 50% Utilization = 50 Units
Operational Impact:
Freshwater Use: 100 m3 (1.000 m3 / 10 Rack - Total Rack Capacity at Facility) * 50% = 50 m3
Waste Disposed: 100 kg (1.000 kg / 10 Rack - Total Rack Capacity at Facility) * 50% = 50 kg
Energy Use (Facility Overhead): 2.5 kW * (1-PUE) * 8760 Hours = 8.760 kWh * 50% = 4.380 kWh
GHG Emissions (Facility Overhead): 4.380 kg CO2-eq (Overhead Power Utilized * Emission Factor)
Rack Operational Impact
Total Energy Input (kWh)
Measured using a power meter, this is the total electrical energy delivered to the rack’s PDUs for distribution to the servers.
Total Energy Use (kWh)
Measured through the PDUs, this is the total energy delivered to the servers of the rack.
Rack Design Capacity (kW)
Static value: How much power is the rack designed for to deliver to the servers
Total Thermal Energy Input (kWh)
Should be calculated using a temperature and/or airflow sensor at the bottom of the rack (or wherever the inlet is located for the cold air to flow through the rack)
Total Thermal Discharge (kWh)
Should be calculated using a temperature and/or airflow sensor at the back of the rack (or wherever the hottest point of air output is located)
Electricity to Thermal Conversion Efficiency (%)
At which efficiency do the air-handlers, heat exchangers and chillers turn 1 kWh of electricity into 1 kWh of thermal energy
Dependent Metrics from the Data Center Entity (see “Metrics that need to be exposed”)
Data Center Facility - Current Emission Factor (1 kg CO2-eq/kWh)
Data Center Facility - Total Rack Capacity at Facility (10)
Data Center Facility - Total Water Use (1.000 m3)
Data Center Facility - Total Waste Disposed (1.000 kg)
Data Center Facility - Power Usage Effectiveness (PUE, 1.6)
A rack is considered to be productive if the Rack Design Capacity and Total Energy Use are close to equal, as this means that the delivered power is fully utilized.
To calculate the all the impact (operational, embodied and indirect) of the rack, we need to have some metrics available from the data center, e.g. to attribute the total water consumption of the facility to a single rack. We do this by dividing the total impact values, by the number of racks that the facility can support, distributing the operational impacts of the facility evenly into the rack.
For the example calculation, we assume the facility only has capacity for 10 racks, and that the rack is 50% occupied (Rack Design Capacity/Total Energy Use). We assume that the rack has a design capacity of 5 kW.
Now the account might look like this (by the end of the year):
Non-Productive Impact:
Embodied Impact: 50 units
Operational Impact: 0 units (as the rack doesn’t consume the 50% unused power, it’s only the embodied impact that is ‘unproductive’)
Productive Impact:
Embodied Impact: 50 Units (this half of the rack is utilized, and therefore productive)
Operational Impact:
Total Energy Use: 21.900 kWh (5 kW @ 50% x 8760 hours per year)
GHG Emissions: 21.900 kg CO2-eq (Emission Factor: 1 kg CO2-eq/kWh from the Facility)
Indirect Impact (from the Facility):
Productive (50%)
Embodied Impact: 1.000 Units / 10 Racks = 100 Units per Rack * 50% Utilization = 50 Units
Operational Impact:
Freshwater Use: 100 m3 (1.000 m3 / 10 Rack - Total Rack Capacity at Facility) * 50% = 50 m3
Waste Disposed: 100 kg (1.000 kg / 10 Rack - Total Rack Capacity at Facility) * 50% = 50 kg
Energy Use (Facility Overhead): 2.5 kW * (1-PUE) * 8760 Hours = 8.760 kWh * 50% = 4.380 kWh
GHG Emissions (Facility Overhead): 4.380 kg CO2-eq (Overhead Power Utilized * Emission Factor)
Non-Productive (50%)
Embodied Impact: 1.000 Units / 10 Racks = 100 Units per Rack * 50% Utilization = 50 Units
Operational Impact:
Freshwater Use: 100 m3 (1.000 m3 / 10 Rack - Total Rack Capacity at Facility) * 50% = 50 m3
Waste Disposed: 100 kg (1.000 kg / 10 Rack - Total Rack Capacity at Facility) * 50% = 50 kg
Energy Use (Facility Overhead): 2.5 kW * (1-PUE) * 8760 Hours = 8.760 kWh * 50% = 4.380 kWh
GHG Emissions (Facility Overhead): 4.380 kg CO2-eq (Overhead Power Utilized * Emission Factor)
Rack Operational Impact
Total Energy Input (kWh)
Measured using a power meter, this is the total electrical energy delivered to the rack’s PDUs for distribution to the servers.
Total Energy Use (kWh)
Measured through the PDUs, this is the total energy delivered to the servers of the rack.
Rack Design Capacity (kW)
Static value: How much power is the rack designed for to deliver to the servers
Total Thermal Energy Input (kWh)
Should be calculated using a temperature and/or airflow sensor at the bottom of the rack (or wherever the inlet is located for the cold air to flow through the rack)
Total Thermal Discharge (kWh)
Should be calculated using a temperature and/or airflow sensor at the back of the rack (or wherever the hottest point of air output is located)
Electricity to Thermal Conversion Efficiency (%)
At which efficiency do the air-handlers, heat exchangers and chillers turn 1 kWh of electricity into 1 kWh of thermal energy
Dependent Metrics from the Data Center Entity (see “Metrics that need to be exposed”)
Data Center Facility - Current Emission Factor (1 kg CO2-eq/kWh)
Data Center Facility - Total Rack Capacity at Facility (10)
Data Center Facility - Total Water Use (1.000 m3)
Data Center Facility - Total Waste Disposed (1.000 kg)
Data Center Facility - Power Usage Effectiveness (PUE, 1.6)
A rack is considered to be productive if the Rack Design Capacity and Total Energy Use are close to equal, as this means that the delivered power is fully utilized.
To calculate the all the impact (operational, embodied and indirect) of the rack, we need to have some metrics available from the data center, e.g. to attribute the total water consumption of the facility to a single rack. We do this by dividing the total impact values, by the number of racks that the facility can support, distributing the operational impacts of the facility evenly into the rack.
For the example calculation, we assume the facility only has capacity for 10 racks, and that the rack is 50% occupied (Rack Design Capacity/Total Energy Use). We assume that the rack has a design capacity of 5 kW.
Now the account might look like this (by the end of the year):
Non-Productive Impact:
Embodied Impact: 50 units
Operational Impact: 0 units (as the rack doesn’t consume the 50% unused power, it’s only the embodied impact that is ‘unproductive’)
Productive Impact:
Embodied Impact: 50 Units (this half of the rack is utilized, and therefore productive)
Operational Impact:
Total Energy Use: 21.900 kWh (5 kW @ 50% x 8760 hours per year)
GHG Emissions: 21.900 kg CO2-eq (Emission Factor: 1 kg CO2-eq/kWh from the Facility)
Indirect Impact (from the Facility):
Productive (50%)
Embodied Impact: 1.000 Units / 10 Racks = 100 Units per Rack * 50% Utilization = 50 Units
Operational Impact:
Freshwater Use: 100 m3 (1.000 m3 / 10 Rack - Total Rack Capacity at Facility) * 50% = 50 m3
Waste Disposed: 100 kg (1.000 kg / 10 Rack - Total Rack Capacity at Facility) * 50% = 50 kg
Energy Use (Facility Overhead): 2.5 kW * (1-PUE) * 8760 Hours = 8.760 kWh * 50% = 4.380 kWh
GHG Emissions (Facility Overhead): 4.380 kg CO2-eq (Overhead Power Utilized * Emission Factor)
Non-Productive (50%)
Embodied Impact: 1.000 Units / 10 Racks = 100 Units per Rack * 50% Utilization = 50 Units
Operational Impact:
Freshwater Use: 100 m3 (1.000 m3 / 10 Rack - Total Rack Capacity at Facility) * 50% = 50 m3
Waste Disposed: 100 kg (1.000 kg / 10 Rack - Total Rack Capacity at Facility) * 50% = 50 kg
Energy Use (Facility Overhead): 2.5 kW * (1-PUE) * 8760 Hours = 8.760 kWh * 50% = 4.380 kWh
GHG Emissions (Facility Overhead): 4.380 kg CO2-eq (Overhead Power Utilized * Emission Factor)
Server
For the server, the operational impacts is coming from the energy consumption of the server, as it’s the main input. The server also demands cooling energy, which we account for using the Power-Usage-Effectiveness value provided by the data center. Lastly, we attribute the indirect impacts from the facility. We do this the proxy of power of the server, vs. total available power for servers in the facility, which is explained below. Lastly, we consider a server to be productive, when it’s actual power consumption is close to it’s rated power consumption.
Server
For the server, the operational impacts is coming from the energy consumption of the server, as it’s the main input. The server also demands cooling energy, which we account for using the Power-Usage-Effectiveness value provided by the data center. Lastly, we attribute the indirect impacts from the facility. We do this the proxy of power of the server, vs. total available power for servers in the facility, which is explained below. Lastly, we consider a server to be productive, when it’s actual power consumption is close to it’s rated power consumption.
Server
For the server, the operational impacts is coming from the energy consumption of the server, as it’s the main input. The server also demands cooling energy, which we account for using the Power-Usage-Effectiveness value provided by the data center. Lastly, we attribute the indirect impacts from the facility. We do this the proxy of power of the server, vs. total available power for servers in the facility, which is explained below. Lastly, we consider a server to be productive, when it’s actual power consumption is close to it’s rated power consumption.
It’s useful to mention here that PUE value must be a near real-time value to accurately account for shifts in outside conditions of the facility as well as to see the effect of measures to reduce the cooling load of the server, e.g. by turning it off. In future revisions of this document, we would prefer to calculate the thermal output (’load’) that is generated by the server to accurately account for the burden that the server is adding to the cooling system of the facility.
Another area of improvement is the productive server assumption, as the productivity should likely not be measured as total rated power vs. actual power usage, but by the amount of digital resources it provides. A new metric for this is being developed as part of the ‘SIEC’ project.
It’s useful to mention here that PUE value must be a near real-time value to accurately account for shifts in outside conditions of the facility as well as to see the effect of measures to reduce the cooling load of the server, e.g. by turning it off. In future revisions of this document, we would prefer to calculate the thermal output (’load’) that is generated by the server to accurately account for the burden that the server is adding to the cooling system of the facility.
Another area of improvement is the productive server assumption, as the productivity should likely not be measured as total rated power vs. actual power usage, but by the amount of digital resources it provides. A new metric for this is being developed as part of the ‘SIEC’ project.
It’s useful to mention here that PUE value must be a near real-time value to accurately account for shifts in outside conditions of the facility as well as to see the effect of measures to reduce the cooling load of the server, e.g. by turning it off. In future revisions of this document, we would prefer to calculate the thermal output (’load’) that is generated by the server to accurately account for the burden that the server is adding to the cooling system of the facility.
Another area of improvement is the productive server assumption, as the productivity should likely not be measured as total rated power vs. actual power usage, but by the amount of digital resources it provides. A new metric for this is being developed as part of the ‘SIEC’ project.
Server Operational Impact
Rated Power (kW)
Static Value: The vendor rated maximum power consumption of the server (may also be retrieved as an estimate, e.g. from the Boavizta API)
Total Energy Use (kWh)
Measured via IPMI or approximated through RAPL or any other available tools (list in Appendix)
Dependent Metrics from the Data Center Entity (see “Metrics that need to be exposed”)
Data Center Facility - Current Emission Factor (1 kg CO2-eq/kWh)
Data Center Facility - Total Power Capacity for IT at Facility (1000 kW)
Data Center Facility - Total Water Use (1.000 m3)
Data Center Facility - Total Waste Disposed (1.000 kg)
Data Center Facility - Power Usage Effectiveness (PUE, 1,6)
If a server is running for a year and it’s Rated Power is 1 kW, it’s total possible power consumption would have been 8.760 kWh. If during that time, it only used half, 4.380 kWh, we can consider that value to be ‘non-productive’, as the server was manufactured but is not fully utilized.
Further, to assess the indirect impacts, we must receive some values from the data center, as listed above. In our example, we consider the Rated Power to be 1 kW and the data center facility’s total capacity for IT to be 1.000 kW, which means that we allocate a 1000th of the operational impacts of the facility as indirect impact to the server.
For our example, we assume that the server is 50% productive.
Server Operational Impact
Rated Power (kW)
Static Value: The vendor rated maximum power consumption of the server (may also be retrieved as an estimate, e.g. from the Boavizta API)
Total Energy Use (kWh)
Measured via IPMI or approximated through RAPL or any other available tools (list in Appendix)
Dependent Metrics from the Data Center Entity (see “Metrics that need to be exposed”)
Data Center Facility - Current Emission Factor (1 kg CO2-eq/kWh)
Data Center Facility - Total Power Capacity for IT at Facility (1000 kW)
Data Center Facility - Total Water Use (1.000 m3)
Data Center Facility - Total Waste Disposed (1.000 kg)
Data Center Facility - Power Usage Effectiveness (PUE, 1,6)
If a server is running for a year and it’s Rated Power is 1 kW, it’s total possible power consumption would have been 8.760 kWh. If during that time, it only used half, 4.380 kWh, we can consider that value to be ‘non-productive’, as the server was manufactured but is not fully utilized.
Further, to assess the indirect impacts, we must receive some values from the data center, as listed above. In our example, we consider the Rated Power to be 1 kW and the data center facility’s total capacity for IT to be 1.000 kW, which means that we allocate a 1000th of the operational impacts of the facility as indirect impact to the server.
For our example, we assume that the server is 50% productive.
Server Operational Impact
Rated Power (kW)
Static Value: The vendor rated maximum power consumption of the server (may also be retrieved as an estimate, e.g. from the Boavizta API)
Total Energy Use (kWh)
Measured via IPMI or approximated through RAPL or any other available tools (list in Appendix)
Dependent Metrics from the Data Center Entity (see “Metrics that need to be exposed”)
Data Center Facility - Current Emission Factor (1 kg CO2-eq/kWh)
Data Center Facility - Total Power Capacity for IT at Facility (1000 kW)
Data Center Facility - Total Water Use (1.000 m3)
Data Center Facility - Total Waste Disposed (1.000 kg)
Data Center Facility - Power Usage Effectiveness (PUE, 1,6)
If a server is running for a year and it’s Rated Power is 1 kW, it’s total possible power consumption would have been 8.760 kWh. If during that time, it only used half, 4.380 kWh, we can consider that value to be ‘non-productive’, as the server was manufactured but is not fully utilized.
Further, to assess the indirect impacts, we must receive some values from the data center, as listed above. In our example, we consider the Rated Power to be 1 kW and the data center facility’s total capacity for IT to be 1.000 kW, which means that we allocate a 1000th of the operational impacts of the facility as indirect impact to the server.
For our example, we assume that the server is 50% productive.
It’s important to note that we assume here that the data facility is delivering overhead cooling energy in accordance with the total power capacity of the server. If there is 50 kW of servers deployed, that means that 50 kW * 0,6 (PUE) overhead energy will be used, regardless if these servers operate at 10, 20 or 50% load.
We account for it as non-productive impact, however we always assume the rated power to calculate the non-productive overhead power usage. This should be a more dynamic calculation and we aim to improve it in the next iteration of this model.
It’s important to note that we assume here that the data facility is delivering overhead cooling energy in accordance with the total power capacity of the server. If there is 50 kW of servers deployed, that means that 50 kW * 0,6 (PUE) overhead energy will be used, regardless if these servers operate at 10, 20 or 50% load.
We account for it as non-productive impact, however we always assume the rated power to calculate the non-productive overhead power usage. This should be a more dynamic calculation and we aim to improve it in the next iteration of this model.
It’s important to note that we assume here that the data facility is delivering overhead cooling energy in accordance with the total power capacity of the server. If there is 50 kW of servers deployed, that means that 50 kW * 0,6 (PUE) overhead energy will be used, regardless if these servers operate at 10, 20 or 50% load.
We account for it as non-productive impact, however we always assume the rated power to calculate the non-productive overhead power usage. This should be a more dynamic calculation and we aim to improve it in the next iteration of this model.
Now the account might look like this (by the end of the year):
Non-Productive Impact:
Embodied Impact: 150 units
Operational Impact: 0 units (we don’t account for non-consumed power of the server)
Productive Impact:
Embodied Impact: 150 Units (50% of the server’s embodied impact is productively used)
Operational Impact:
Total Energy Use: 4.380 kWh (1 kW @ 50% x 8760 hours per year)
GHG Emissions: 4.380 kg CO2-eq (Emission Factor: 1 kg CO2-eq/kWh from the Facility)
Indirect Impact (from the Facility):
Productive (50%)
Embodied Impact: 1.000 Units * 0,1% = 10 Units * 50% = 5 Units (Server occupies 1 kW of 1.000 kW IT Capacity, and is using 50% of this occupied capacity in a productive way)
Operational Impact:
Freshwater Use: 1.000 m3 * 0,1% = 10 m3 * 50% = 5 m3
Waste Disposed: 1.000 kg * 0,1% = 10 kg * 50% = 5 kg
Energy Use (Facility Overhead): 4.380 kWh * (1-PUE of 1,6) = 2.628 kWh
GHG Emissions (Facility Overhead): 2.628 kg CO2-eq (Overhead Power Utilized * Emission Factor)
Non-Productive (50%)
Embodied Impact: 1.000 Units * 0,1% = 10 Units * 50% = 5 Units (Server occupies 1 kW of 1.000 kW IT Capacity, and is using 50% of this occupied capacity in a productive way)
Operational Impact:
Freshwater Use: 1.000 m3 * 0,1% = 10 m3 * 50% = 5 m3
Waste Disposed: 1.000 kg * 0,1% = 10 kg * 50% = 5 kg
Energy Use (Facility Overhead): 4.380 kWh * (1-PUE of 1,6) = 2.628 kWh
GHG Emissions (Facility Overhead): 2.628 kg CO2-eq (Overhead Power Utilized * Emission Factor)
Now the account might look like this (by the end of the year):
Non-Productive Impact:
Embodied Impact: 150 units
Operational Impact: 0 units (we don’t account for non-consumed power of the server)
Productive Impact:
Embodied Impact: 150 Units (50% of the server’s embodied impact is productively used)
Operational Impact:
Total Energy Use: 4.380 kWh (1 kW @ 50% x 8760 hours per year)
GHG Emissions: 4.380 kg CO2-eq (Emission Factor: 1 kg CO2-eq/kWh from the Facility)
Indirect Impact (from the Facility):
Productive (50%)
Embodied Impact: 1.000 Units * 0,1% = 10 Units * 50% = 5 Units (Server occupies 1 kW of 1.000 kW IT Capacity, and is using 50% of this occupied capacity in a productive way)
Operational Impact:
Freshwater Use: 1.000 m3 * 0,1% = 10 m3 * 50% = 5 m3
Waste Disposed: 1.000 kg * 0,1% = 10 kg * 50% = 5 kg
Energy Use (Facility Overhead): 4.380 kWh * (1-PUE of 1,6) = 2.628 kWh
GHG Emissions (Facility Overhead): 2.628 kg CO2-eq (Overhead Power Utilized * Emission Factor)
Non-Productive (50%)
Embodied Impact: 1.000 Units * 0,1% = 10 Units * 50% = 5 Units (Server occupies 1 kW of 1.000 kW IT Capacity, and is using 50% of this occupied capacity in a productive way)
Operational Impact:
Freshwater Use: 1.000 m3 * 0,1% = 10 m3 * 50% = 5 m3
Waste Disposed: 1.000 kg * 0,1% = 10 kg * 50% = 5 kg
Energy Use (Facility Overhead): 4.380 kWh * (1-PUE of 1,6) = 2.628 kWh
GHG Emissions (Facility Overhead): 2.628 kg CO2-eq (Overhead Power Utilized * Emission Factor)
Now the account might look like this (by the end of the year):
Non-Productive Impact:
Embodied Impact: 150 units
Operational Impact: 0 units (we don’t account for non-consumed power of the server)
Productive Impact:
Embodied Impact: 150 Units (50% of the server’s embodied impact is productively used)
Operational Impact:
Total Energy Use: 4.380 kWh (1 kW @ 50% x 8760 hours per year)
GHG Emissions: 4.380 kg CO2-eq (Emission Factor: 1 kg CO2-eq/kWh from the Facility)
Indirect Impact (from the Facility):
Productive (50%)
Embodied Impact: 1.000 Units * 0,1% = 10 Units * 50% = 5 Units (Server occupies 1 kW of 1.000 kW IT Capacity, and is using 50% of this occupied capacity in a productive way)
Operational Impact:
Freshwater Use: 1.000 m3 * 0,1% = 10 m3 * 50% = 5 m3
Waste Disposed: 1.000 kg * 0,1% = 10 kg * 50% = 5 kg
Energy Use (Facility Overhead): 4.380 kWh * (1-PUE of 1,6) = 2.628 kWh
GHG Emissions (Facility Overhead): 2.628 kg CO2-eq (Overhead Power Utilized * Emission Factor)
Non-Productive (50%)
Embodied Impact: 1.000 Units * 0,1% = 10 Units * 50% = 5 Units (Server occupies 1 kW of 1.000 kW IT Capacity, and is using 50% of this occupied capacity in a productive way)
Operational Impact:
Freshwater Use: 1.000 m3 * 0,1% = 10 m3 * 50% = 5 m3
Waste Disposed: 1.000 kg * 0,1% = 10 kg * 50% = 5 kg
Energy Use (Facility Overhead): 4.380 kWh * (1-PUE of 1,6) = 2.628 kWh
GHG Emissions (Facility Overhead): 2.628 kg CO2-eq (Overhead Power Utilized * Emission Factor)
Attributing the Operational and Embodied Impacts of the Server to Digital Resources
Attributing the environmental impact to digital resources is an approach we first explored in our SoftAWERE project (final report soon to be released). One can think about it like this:
A server, when running makes digital resources available for an application to use.
Let’s take a real server for which an LCA is available - the Dell PowerEdge R740 (official LCA is here). This server is configured to produce the following digital resources:
2 x Intel Xeon Gold 6132 CPUs (https://www.intel.com/content/www/us/en/products/sku/123541/intel-xeon-gold-6132-processor-19-25m-cache-2-60-ghz/specifications.html)
12 x 32 GB RAM = 384 GB Total
1 x 400 GB SSD + 8 x 3,84 TB SSD = 31,12 TB SSD
Dual Port 10 GbE Network Card
2 x 1.100W PSUs (Rated Power = 1.100W)
Using this information, we can say that the server uses 1.100W to provide at the maximum 100% CPU Usage on the two CPUs (28 Cores), 384 GB of RAM, 31,12 TB storage capacity and 20 Gbit network capacity. Or expressed simpler: the server produces digital resources, using 1.100W of input energy. But how do we distribute the 1.100W to each type of digital resource?
Attributing the Operational and Embodied Impacts of the Server to Digital Resources
Attributing the environmental impact to digital resources is an approach we first explored in our SoftAWERE project (final report soon to be released). One can think about it like this:
A server, when running makes digital resources available for an application to use.
Let’s take a real server for which an LCA is available - the Dell PowerEdge R740 (official LCA is here). This server is configured to produce the following digital resources:
2 x Intel Xeon Gold 6132 CPUs (https://www.intel.com/content/www/us/en/products/sku/123541/intel-xeon-gold-6132-processor-19-25m-cache-2-60-ghz/specifications.html)
12 x 32 GB RAM = 384 GB Total
1 x 400 GB SSD + 8 x 3,84 TB SSD = 31,12 TB SSD
Dual Port 10 GbE Network Card
2 x 1.100W PSUs (Rated Power = 1.100W)
Using this information, we can say that the server uses 1.100W to provide at the maximum 100% CPU Usage on the two CPUs (28 Cores), 384 GB of RAM, 31,12 TB storage capacity and 20 Gbit network capacity. Or expressed simpler: the server produces digital resources, using 1.100W of input energy. But how do we distribute the 1.100W to each type of digital resource?
Attributing the Operational and Embodied Impacts of the Server to Digital Resources
Attributing the environmental impact to digital resources is an approach we first explored in our SoftAWERE project (final report soon to be released). One can think about it like this:
A server, when running makes digital resources available for an application to use.
Let’s take a real server for which an LCA is available - the Dell PowerEdge R740 (official LCA is here). This server is configured to produce the following digital resources:
2 x Intel Xeon Gold 6132 CPUs (https://www.intel.com/content/www/us/en/products/sku/123541/intel-xeon-gold-6132-processor-19-25m-cache-2-60-ghz/specifications.html)
12 x 32 GB RAM = 384 GB Total
1 x 400 GB SSD + 8 x 3,84 TB SSD = 31,12 TB SSD
Dual Port 10 GbE Network Card
2 x 1.100W PSUs (Rated Power = 1.100W)
Using this information, we can say that the server uses 1.100W to provide at the maximum 100% CPU Usage on the two CPUs (28 Cores), 384 GB of RAM, 31,12 TB storage capacity and 20 Gbit network capacity. Or expressed simpler: the server produces digital resources, using 1.100W of input energy. But how do we distribute the 1.100W to each type of digital resource?
If the rated power of the server is not available, it is possible to estimate it using the TDP value of the CPU which you can get if you know the model of the CPU.
For the Intel Xeon Chips used in the Dell server, Intel lists a TDP value of 140W. You can use the method developed by Tom Kennes (here), to turn this into an estimate of the total server power.
If the rated power of the server is not available, it is possible to estimate it using the TDP value of the CPU which you can get if you know the model of the CPU.
For the Intel Xeon Chips used in the Dell server, Intel lists a TDP value of 140W. You can use the method developed by Tom Kennes (here), to turn this into an estimate of the total server power.
If the rated power of the server is not available, it is possible to estimate it using the TDP value of the CPU which you can get if you know the model of the CPU.
For the Intel Xeon Chips used in the Dell server, Intel lists a TDP value of 140W. You can use the method developed by Tom Kennes (here), to turn this into an estimate of the total server power.
Allocating operational impacts to each digital resource type
In our previous research we have defined the following assumptions based on existing research to allocate the operational impacts to each type of digital resource.
Allocating operational impacts to each digital resource type
In our previous research we have defined the following assumptions based on existing research to allocate the operational impacts to each type of digital resource.
Allocating operational impacts to each digital resource type
In our previous research we have defined the following assumptions based on existing research to allocate the operational impacts to each type of digital resource.
In our previous research we have defined the following assumptions based on existing research to allocate the operational impacts to each type of digital resource.
Resource | Operational Allocation % |
|---|---|
CPU | 65% |
Memory | 20% |
Storage | 10% |
Network | 5% |
In our previous research we have defined the following assumptions based on existing research to allocate the operational impacts to each type of digital resource.
Resource | Operational Allocation % |
|---|---|
CPU | 65% |
Memory | 20% |
Storage | 10% |
Network | 5% |
In our previous research we have defined the following assumptions based on existing research to allocate the operational impacts to each type of digital resource.
Resource | Operational Allocation % |
|---|---|
CPU | 65% |
Memory | 20% |
Storage | 10% |
Network | 5% |
Allocating embodied impacts to each digital resource type
For the embodied impacts, the Dell study offers a useful graph for creating an attribution ratio. Note that whereas for operational impacts, the CPU is clearly dominant, for embodied impacts the disks are the primary factor.
Allocating embodied impacts to each digital resource type
For the embodied impacts, the Dell study offers a useful graph for creating an attribution ratio. Note that whereas for operational impacts, the CPU is clearly dominant, for embodied impacts the disks are the primary factor.
Allocating embodied impacts to each digital resource type
For the embodied impacts, the Dell study offers a useful graph for creating an attribution ratio. Note that whereas for operational impacts, the CPU is clearly dominant, for embodied impacts the disks are the primary factor.
Resource | Embodied Allocation % | Comment |
|---|---|---|
CPU | 7% | part of ‘Mainboard’, assuming half is memory and half CPU |
Memory | 7% | part of ‘Mainboard’, assuming half is memory and half CPU |
Storage | 80% | |
Network | 2% | Assumption |
Resource | Embodied Allocation % | Comment |
|---|---|---|
CPU | 7% | part of ‘Mainboard’, assuming half is memory and half CPU |
Memory | 7% | part of ‘Mainboard’, assuming half is memory and half CPU |
Storage | 80% | |
Network | 2% | Assumption |
Resource | Embodied Allocation % | Comment |
|---|---|---|
CPU | 7% | part of ‘Mainboard’, assuming half is memory and half CPU |
Memory | 7% | part of ‘Mainboard’, assuming half is memory and half CPU |
Storage | 80% | |
Network | 2% | Assumption |
Note that the embodied ratio’s need to be scaled according the how many disks, CPUs and memory elements are in there, and the ratio’s in the table are specific for the configuration of the Dell PowerEdge R740. In a later revision of this paper, we plan to add a calculation model.
Further in the example, we distributed Fans, PWB, PSU and Chassis to the CPU, Memory and Network digital resources.
Note that the embodied ratio’s need to be scaled according the how many disks, CPUs and memory elements are in there, and the ratio’s in the table are specific for the configuration of the Dell PowerEdge R740. In a later revision of this paper, we plan to add a calculation model.
Further in the example, we distributed Fans, PWB, PSU and Chassis to the CPU, Memory and Network digital resources.
Note that the embodied ratio’s need to be scaled according the how many disks, CPUs and memory elements are in there, and the ratio’s in the table are specific for the configuration of the Dell PowerEdge R740. In a later revision of this paper, we plan to add a calculation model.
Further in the example, we distributed Fans, PWB, PSU and Chassis to the CPU, Memory and Network digital resources.
With the data from the LCA we can set up our Embodied Impact account for the Server entity like this (using the Lifetime assumption from the section on Servers above for 5 years). Let’s assume the server is idling, so we can allocate all the embodied impact to the Non-Productive sub-account. All data is accumulated at the end-of-year for simplicity.
Server - Embodied Impact Account
Productive: None
Non-Productive
Abiotic Depletion [MJ]: 9,66E+04 / 5 Years
Acidification Potential [kg SO2 eq.]: 3,01E+01 / 5 Years
Eutrophication Potential [kg Phosphate eq.]: 2,43E+00 / 5 Years
Ozone Layer Depletion Potential [kg R11 eq.]: 5,74E-08 / 5 Years
Photochem. Ozone Creation Potential [kg Ethene eq.] 1,96E+00 / 5 Years
Global Warming Potential 100 years incl. biogenic carbon [kg CO2 eq.]: 4290 kg CO2-eq / 5 Years
We can also charge the operational account for the server using the data from the LCA as well as the metrics from the data center (see the section on Operational Impact of Servers for details). Again, we assume the server is idling.
Server - Operational Impact Account
Productive Impact: none
None-Productive Impact:
Total Energy Use: 9.636 kWh (1,1 kW @ 100% x 8760 hours per year)
GHG Emissions: 9.636 kg CO2-eq (Emission Factor: 1 kg CO2-eq/kWh from the Facility)
Indirect Impact (from the Facility):
Productive: None
Non-Productive:
Embodied Impact: 1.000 Units * 0,11% = 11 Units (Server occupies 1,1 kW of 1.000 kW IT Capacity)
Operational Impact:
Freshwater Use: 1.000 m3 * 0,11% = 11 m3
Waste Disposed: 1.000 kg * 0,11% = 11 kg
Energy Use (Facility Overhead): 9.636 kWh * (1-PUE of 1,6) = 5.781,6 kWh
GHG Emissions (Facility Overhead): 5.781,6 kg CO2-eq (Overhead Power Utilized * Emission Factor)
With the data from the LCA we can set up our Embodied Impact account for the Server entity like this (using the Lifetime assumption from the section on Servers above for 5 years). Let’s assume the server is idling, so we can allocate all the embodied impact to the Non-Productive sub-account. All data is accumulated at the end-of-year for simplicity.
Server - Embodied Impact Account
Productive: None
Non-Productive
Abiotic Depletion [MJ]: 9,66E+04 / 5 Years
Acidification Potential [kg SO2 eq.]: 3,01E+01 / 5 Years
Eutrophication Potential [kg Phosphate eq.]: 2,43E+00 / 5 Years
Ozone Layer Depletion Potential [kg R11 eq.]: 5,74E-08 / 5 Years
Photochem. Ozone Creation Potential [kg Ethene eq.] 1,96E+00 / 5 Years
Global Warming Potential 100 years incl. biogenic carbon [kg CO2 eq.]: 4290 kg CO2-eq / 5 Years
We can also charge the operational account for the server using the data from the LCA as well as the metrics from the data center (see the section on Operational Impact of Servers for details). Again, we assume the server is idling.
Server - Operational Impact Account
Productive Impact: none
None-Productive Impact:
Total Energy Use: 9.636 kWh (1,1 kW @ 100% x 8760 hours per year)
GHG Emissions: 9.636 kg CO2-eq (Emission Factor: 1 kg CO2-eq/kWh from the Facility)
Indirect Impact (from the Facility):
Productive: None
Non-Productive:
Embodied Impact: 1.000 Units * 0,11% = 11 Units (Server occupies 1,1 kW of 1.000 kW IT Capacity)
Operational Impact:
Freshwater Use: 1.000 m3 * 0,11% = 11 m3
Waste Disposed: 1.000 kg * 0,11% = 11 kg
Energy Use (Facility Overhead): 9.636 kWh * (1-PUE of 1,6) = 5.781,6 kWh
GHG Emissions (Facility Overhead): 5.781,6 kg CO2-eq (Overhead Power Utilized * Emission Factor)
With the data from the LCA we can set up our Embodied Impact account for the Server entity like this (using the Lifetime assumption from the section on Servers above for 5 years). Let’s assume the server is idling, so we can allocate all the embodied impact to the Non-Productive sub-account. All data is accumulated at the end-of-year for simplicity.
Server - Embodied Impact Account
Productive: None
Non-Productive
Abiotic Depletion [MJ]: 9,66E+04 / 5 Years
Acidification Potential [kg SO2 eq.]: 3,01E+01 / 5 Years
Eutrophication Potential [kg Phosphate eq.]: 2,43E+00 / 5 Years
Ozone Layer Depletion Potential [kg R11 eq.]: 5,74E-08 / 5 Years
Photochem. Ozone Creation Potential [kg Ethene eq.] 1,96E+00 / 5 Years
Global Warming Potential 100 years incl. biogenic carbon [kg CO2 eq.]: 4290 kg CO2-eq / 5 Years
We can also charge the operational account for the server using the data from the LCA as well as the metrics from the data center (see the section on Operational Impact of Servers for details). Again, we assume the server is idling.
Server - Operational Impact Account
Productive Impact: none
None-Productive Impact:
Total Energy Use: 9.636 kWh (1,1 kW @ 100% x 8760 hours per year)
GHG Emissions: 9.636 kg CO2-eq (Emission Factor: 1 kg CO2-eq/kWh from the Facility)
Indirect Impact (from the Facility):
Productive: None
Non-Productive:
Embodied Impact: 1.000 Units * 0,11% = 11 Units (Server occupies 1,1 kW of 1.000 kW IT Capacity)
Operational Impact:
Freshwater Use: 1.000 m3 * 0,11% = 11 m3
Waste Disposed: 1.000 kg * 0,11% = 11 kg
Energy Use (Facility Overhead): 9.636 kWh * (1-PUE of 1,6) = 5.781,6 kWh
GHG Emissions (Facility Overhead): 5.781,6 kg CO2-eq (Overhead Power Utilized * Emission Factor)
Allocating impact to digital resources
Using our logic of environmental impact accounts and the percentage-allocation rules we defined above, we can fill the impact accounts for each digital resource type produced by the server. We assume it’s completely idling–allowing us to assign it all to the non-productive account of each digital resource type. Let’s further assume that the server is running for a year. We can use the charged accounts from above to simplify the calculations:
Allocating impact to digital resources
Using our logic of environmental impact accounts and the percentage-allocation rules we defined above, we can fill the impact accounts for each digital resource type produced by the server. We assume it’s completely idling–allowing us to assign it all to the non-productive account of each digital resource type. Let’s further assume that the server is running for a year. We can use the charged accounts from above to simplify the calculations:
Allocating impact to digital resources
Using our logic of environmental impact accounts and the percentage-allocation rules we defined above, we can fill the impact accounts for each digital resource type produced by the server. We assume it’s completely idling–allowing us to assign it all to the non-productive account of each digital resource type. Let’s further assume that the server is running for a year. We can use the charged accounts from above to simplify the calculations:
CPU Usage
Operational Impacts
Non-Productive: (Server Operational Impacts - Productive) * 65%
Productive: None
Embodied Impact
Non-Productive: (Server Embodied Impacts - Productive) * 7%
Productive: None
Indirect Impact
Non-Productive:
(Server Indirect Operational Impacts - Productive) * 65%
(Server Indirect Embodied Impacts - Productive) * 25%
Productive: None
Memory Usage
Operational Impacts
Non-Productive: (Server Operational Impacts - Productive) * 20%
Productive: None
Embodied Impact
Non-Productive: (Server Operational Impacts - Productive) * 7%
Productive: None
Indirect Impact
Non-Productive:
(Server Indirect Operational Impacts - Productive) * 20%
(Server Indirect Embodied Impacts - Productive) * 25%
Productive: None
CPU Usage
Operational Impacts
Non-Productive: (Server Operational Impacts - Productive) * 65%
Productive: None
Embodied Impact
Non-Productive: (Server Embodied Impacts - Productive) * 7%
Productive: None
Indirect Impact
Non-Productive:
(Server Indirect Operational Impacts - Productive) * 65%
(Server Indirect Embodied Impacts - Productive) * 25%
Productive: None
Memory Usage
Operational Impacts
Non-Productive: (Server Operational Impacts - Productive) * 20%
Productive: None
Embodied Impact
Non-Productive: (Server Operational Impacts - Productive) * 7%
Productive: None
Indirect Impact
Non-Productive:
(Server Indirect Operational Impacts - Productive) * 20%
(Server Indirect Embodied Impacts - Productive) * 25%
Productive: None
CPU Usage
Operational Impacts
Non-Productive: (Server Operational Impacts - Productive) * 65%
Productive: None
Embodied Impact
Non-Productive: (Server Embodied Impacts - Productive) * 7%
Productive: None
Indirect Impact
Non-Productive:
(Server Indirect Operational Impacts - Productive) * 65%
(Server Indirect Embodied Impacts - Productive) * 25%
Productive: None
Memory Usage
Operational Impacts
Non-Productive: (Server Operational Impacts - Productive) * 20%
Productive: None
Embodied Impact
Non-Productive: (Server Operational Impacts - Productive) * 7%
Productive: None
Indirect Impact
Non-Productive:
(Server Indirect Operational Impacts - Productive) * 20%
(Server Indirect Embodied Impacts - Productive) * 25%
Productive: None
Storage Usage
Operational Impacts
Non-Productive: (Server Operational Impacts - Productive) * 10%
Productive: None
Embodied Impact
Non-Productive: (Server Embodied Impacts - Productive) * 80%
Productive: None
Indirect Impact
Non-Productive:
(Server Indirect Operational Impacts - Productive) * 10%
(Server Indirect Embodied Impacts - Productive) * 25%
Productive: None
Network Usage
Operational Impacts
Non-Productive: (Server Operational Impacts - Productive) * 5%
Productive: None
Embodied Impact
Non-Productive: (Server Embodied Impacts - Productive) * 2%
Productive: None
Indirect Impact
Non-Productive:
(Server Indirect Operational Impacts - Productive) * 5%
(Server Indirect Embodied Impacts - Productive) * 25%
Productive: None
Storage Usage
Operational Impacts
Non-Productive: (Server Operational Impacts - Productive) * 10%
Productive: None
Embodied Impact
Non-Productive: (Server Embodied Impacts - Productive) * 80%
Productive: None
Indirect Impact
Non-Productive:
(Server Indirect Operational Impacts - Productive) * 10%
(Server Indirect Embodied Impacts - Productive) * 25%
Productive: None
Network Usage
Operational Impacts
Non-Productive: (Server Operational Impacts - Productive) * 5%
Productive: None
Embodied Impact
Non-Productive: (Server Embodied Impacts - Productive) * 2%
Productive: None
Indirect Impact
Non-Productive:
(Server Indirect Operational Impacts - Productive) * 5%
(Server Indirect Embodied Impacts - Productive) * 25%
Productive: None
Storage Usage
Operational Impacts
Non-Productive: (Server Operational Impacts - Productive) * 10%
Productive: None
Embodied Impact
Non-Productive: (Server Embodied Impacts - Productive) * 80%
Productive: None
Indirect Impact
Non-Productive:
(Server Indirect Operational Impacts - Productive) * 10%
(Server Indirect Embodied Impacts - Productive) * 25%
Productive: None
Network Usage
Operational Impacts
Non-Productive: (Server Operational Impacts - Productive) * 5%
Productive: None
Embodied Impact
Non-Productive: (Server Embodied Impacts - Productive) * 2%
Productive: None
Indirect Impact
Non-Productive:
(Server Indirect Operational Impacts - Productive) * 5%
(Server Indirect Embodied Impacts - Productive) * 25%
Productive: None
Now if you imagine that half of the CPU is fully utilized, half of the non-productive account of the CPU is shifting to productive. If an application would run on the bare-metal server is occupying half of the digital resources, you can allocate all of the impact to the application, separated by productive and non-productive and even break it down by the type of digital resource that the application is utilizing. It’s not very helpful yet as when an application is running on a single bare-metal server, the impact accounts for the server can be utilized directly for impact reporting. But we will use the digital resource attribution in a later step.
Now if you imagine that half of the CPU is fully utilized, half of the non-productive account of the CPU is shifting to productive. If an application would run on the bare-metal server is occupying half of the digital resources, you can allocate all of the impact to the application, separated by productive and non-productive and even break it down by the type of digital resource that the application is utilizing. It’s not very helpful yet as when an application is running on a single bare-metal server, the impact accounts for the server can be utilized directly for impact reporting. But we will use the digital resource attribution in a later step.
Now if you imagine that half of the CPU is fully utilized, half of the non-productive account of the CPU is shifting to productive. If an application would run on the bare-metal server is occupying half of the digital resources, you can allocate all of the impact to the application, separated by productive and non-productive and even break it down by the type of digital resource that the application is utilizing. It’s not very helpful yet as when an application is running on a single bare-metal server, the impact accounts for the server can be utilized directly for impact reporting. But we will use the digital resource attribution in a later step.
Weaving it all together–for a software application
We’ve charged all the physical impact accounts of all the machines and buildings in the value-creation chain below the application. So far so logical. Now comes the hard-part, connecting it all to the actual application.
On a conceptual level, we can say that if an application is running and doing anything that utilizing the server or/and it’s digital resources, that’s productive. Let’s not debate if the application is doing something useful or not–that’s the territory of philosophy.
What’s not productive is an application placing a reservation, e.g. booking a virtual machine with 16 GB memory and 16 cores, of which it uses only 30% at the most. This 70% of ‘reserved but not utilized’ is unproductive, as it could be used by another application.
Weaving it all together–for a software application
We’ve charged all the physical impact accounts of all the machines and buildings in the value-creation chain below the application. So far so logical. Now comes the hard-part, connecting it all to the actual application.
On a conceptual level, we can say that if an application is running and doing anything that utilizing the server or/and it’s digital resources, that’s productive. Let’s not debate if the application is doing something useful or not–that’s the territory of philosophy.
What’s not productive is an application placing a reservation, e.g. booking a virtual machine with 16 GB memory and 16 cores, of which it uses only 30% at the most. This 70% of ‘reserved but not utilized’ is unproductive, as it could be used by another application.
Weaving it all together–for a software application
We’ve charged all the physical impact accounts of all the machines and buildings in the value-creation chain below the application. So far so logical. Now comes the hard-part, connecting it all to the actual application.
On a conceptual level, we can say that if an application is running and doing anything that utilizing the server or/and it’s digital resources, that’s productive. Let’s not debate if the application is doing something useful or not–that’s the territory of philosophy.
What’s not productive is an application placing a reservation, e.g. booking a virtual machine with 16 GB memory and 16 cores, of which it uses only 30% at the most. This 70% of ‘reserved but not utilized’ is unproductive, as it could be used by another application.
We ignore the fact that Hypervisors and Orchestrators are doing a lot of magic to oversubscribe a server, essentially allowing applications to reserve 110-200% of the actual physically available digital resources, well knowing they won’t use them all at the exact time. In principle, this magic shouldn’t even be needed if applications would update their reservations continuously based on actual usage (’right sizing’).
With our approach(es), we capture the most important fact: Reserving more resources then needed is not productive and creates waste that should be managed and avoided.
We ignore the fact that Hypervisors and Orchestrators are doing a lot of magic to oversubscribe a server, essentially allowing applications to reserve 110-200% of the actual physically available digital resources, well knowing they won’t use them all at the exact time. In principle, this magic shouldn’t even be needed if applications would update their reservations continuously based on actual usage (’right sizing’).
With our approach(es), we capture the most important fact: Reserving more resources then needed is not productive and creates waste that should be managed and avoided.
We ignore the fact that Hypervisors and Orchestrators are doing a lot of magic to oversubscribe a server, essentially allowing applications to reserve 110-200% of the actual physically available digital resources, well knowing they won’t use them all at the exact time. In principle, this magic shouldn’t even be needed if applications would update their reservations continuously based on actual usage (’right sizing’).
With our approach(es), we capture the most important fact: Reserving more resources then needed is not productive and creates waste that should be managed and avoided.
In our previous research we have defined the following assumptions based on existing research to allocate the operational impacts to each type of digital resource.
In our previous research we have defined the following assumptions based on existing research to allocate the operational impacts to each type of digital resource.
In our previous research we have defined the following assumptions based on existing research to allocate the operational impacts to each type of digital resource.
Approach 0: Bare-Metal Allocation
The easy one. If an application uses one or multiple bare-metal servers, the total digital resources of the bare-metal server are the reservation (non-productive) and the actual usage of digital resources is the productive use.
This can be calculated in the two ways outlined above. Either less precise by using the server’s impact account and simply allocating it all to non-productive. Then calculating the percentage of digital resources actually used, e.g. if a server offers at most 32 Cores, 128 GB of memory, 100 Million I/O Ops/10 Gbit bandwidth and 100 Million Network Ops/100 Gbit Bandwidth and the application in aggregate using 30% of that capacity, then you can move 30% of the impact account of the server into ‘productive’ for the application.
The second way, also outlined in the previous section is to break down the impact accounts onto each type of digital resource and calculating it directly through actual application or process usage of each digital resource type, e.g. Disk I/O might have more embodied impact than operational, whereas the CPU is operational impact heavy and lower on embodied.
To do either, one needs to monitor digital resource usage of the server, using an IT infrastructure monitoring tool of choice.
If an application spans across multiple servers, the accounts should be calculated per-server and then added to the total impact account of the application. It’s important to avoid averages here as the servers may have different utilization profiles (think: a database server and an application server working together to deliver an application).
Approach 0: Bare-Metal Allocation
The easy one. If an application uses one or multiple bare-metal servers, the total digital resources of the bare-metal server are the reservation (non-productive) and the actual usage of digital resources is the productive use.
This can be calculated in the two ways outlined above. Either less precise by using the server’s impact account and simply allocating it all to non-productive. Then calculating the percentage of digital resources actually used, e.g. if a server offers at most 32 Cores, 128 GB of memory, 100 Million I/O Ops/10 Gbit bandwidth and 100 Million Network Ops/100 Gbit Bandwidth and the application in aggregate using 30% of that capacity, then you can move 30% of the impact account of the server into ‘productive’ for the application.
The second way, also outlined in the previous section is to break down the impact accounts onto each type of digital resource and calculating it directly through actual application or process usage of each digital resource type, e.g. Disk I/O might have more embodied impact than operational, whereas the CPU is operational impact heavy and lower on embodied.
To do either, one needs to monitor digital resource usage of the server, using an IT infrastructure monitoring tool of choice.
If an application spans across multiple servers, the accounts should be calculated per-server and then added to the total impact account of the application. It’s important to avoid averages here as the servers may have different utilization profiles (think: a database server and an application server working together to deliver an application).
Approach 0: Bare-Metal Allocation
The easy one. If an application uses one or multiple bare-metal servers, the total digital resources of the bare-metal server are the reservation (non-productive) and the actual usage of digital resources is the productive use.
This can be calculated in the two ways outlined above. Either less precise by using the server’s impact account and simply allocating it all to non-productive. Then calculating the percentage of digital resources actually used, e.g. if a server offers at most 32 Cores, 128 GB of memory, 100 Million I/O Ops/10 Gbit bandwidth and 100 Million Network Ops/100 Gbit Bandwidth and the application in aggregate using 30% of that capacity, then you can move 30% of the impact account of the server into ‘productive’ for the application.
The second way, also outlined in the previous section is to break down the impact accounts onto each type of digital resource and calculating it directly through actual application or process usage of each digital resource type, e.g. Disk I/O might have more embodied impact than operational, whereas the CPU is operational impact heavy and lower on embodied.
To do either, one needs to monitor digital resource usage of the server, using an IT infrastructure monitoring tool of choice.
If an application spans across multiple servers, the accounts should be calculated per-server and then added to the total impact account of the application. It’s important to avoid averages here as the servers may have different utilization profiles (think: a database server and an application server working together to deliver an application).
Meet the Hypervisor & Orchestrator
In the context of our approach, the Hypervisor’s and Orchestrator’s can be understood as reservation managers. One of their jobs is actually to close the delta between reservations & usage, maximizing the utilization of the underlying hardware. They also offer a level of isolation, which generally makes measurements more complex, but there many tools out there that circumvent this, see the list in the Appendix.
The great thing is that these systems have a complete overview of all reservations per virtual machine, container or pod (’bundles of digital resources’) that are running on a server or within a cluster of servers. They also have accurate data on the digital resources that each bundle is using at any given time. And they usually know all the specifications of the host system they are running on (e.g. total CPU, memory, disk and I/O capacities).
In Approach 1 and 2, if accessible and possible, data from the Hypervisor or Orchestrator should be preferred.
Meet the Hypervisor & Orchestrator
In the context of our approach, the Hypervisor’s and Orchestrator’s can be understood as reservation managers. One of their jobs is actually to close the delta between reservations & usage, maximizing the utilization of the underlying hardware. They also offer a level of isolation, which generally makes measurements more complex, but there many tools out there that circumvent this, see the list in the Appendix.
The great thing is that these systems have a complete overview of all reservations per virtual machine, container or pod (’bundles of digital resources’) that are running on a server or within a cluster of servers. They also have accurate data on the digital resources that each bundle is using at any given time. And they usually know all the specifications of the host system they are running on (e.g. total CPU, memory, disk and I/O capacities).
In Approach 1 and 2, if accessible and possible, data from the Hypervisor or Orchestrator should be preferred.
Meet the Hypervisor & Orchestrator
In the context of our approach, the Hypervisor’s and Orchestrator’s can be understood as reservation managers. One of their jobs is actually to close the delta between reservations & usage, maximizing the utilization of the underlying hardware. They also offer a level of isolation, which generally makes measurements more complex, but there many tools out there that circumvent this, see the list in the Appendix.
The great thing is that these systems have a complete overview of all reservations per virtual machine, container or pod (’bundles of digital resources’) that are running on a server or within a cluster of servers. They also have accurate data on the digital resources that each bundle is using at any given time. And they usually know all the specifications of the host system they are running on (e.g. total CPU, memory, disk and I/O capacities).
In Approach 1 and 2, if accessible and possible, data from the Hypervisor or Orchestrator should be preferred.
Approach 1: Using Digital Resources Monitoring (consumption based)
With this approach, you are ignoring the non-productive impacts and focus on the turning the digital resource consumption of the application into environmental impact. You do this by having, e.g. an IT monitoring system that monitors the digital resource usage of the application, and combining that usage with the impact account for each digital resource (as outlined under ‘Attributing the Operational and Embodied Impacts of the Server to Digital Resources’).
This means you need the information from the server on the impact account per digital resource that is being produced.
As a mental model, you can see this as a wire transfer. If the application is utilizing 10% of the CPU of the underlying server system for a day, that means the server must ‘send’ the impact of the CPU usage for that one day to the application (productive) account.
If the applications spans across multiple systems, e.g.
10 Kubernetes Pods
2 Bare-Metal Servers
14 Virtual Machines
The transfer must happen for each of these individually and be added up to the application impact account. You can not measure digital resource consumption on each and build averages or sum those first, you need to calculate the impact to be attributed to the application for each bundle or physical server based on the actual usage occurred on that system.
Approach 1: Using Digital Resources Monitoring (consumption based)
With this approach, you are ignoring the non-productive impacts and focus on the turning the digital resource consumption of the application into environmental impact. You do this by having, e.g. an IT monitoring system that monitors the digital resource usage of the application, and combining that usage with the impact account for each digital resource (as outlined under ‘Attributing the Operational and Embodied Impacts of the Server to Digital Resources’).
This means you need the information from the server on the impact account per digital resource that is being produced.
As a mental model, you can see this as a wire transfer. If the application is utilizing 10% of the CPU of the underlying server system for a day, that means the server must ‘send’ the impact of the CPU usage for that one day to the application (productive) account.
If the applications spans across multiple systems, e.g.
10 Kubernetes Pods
2 Bare-Metal Servers
14 Virtual Machines
The transfer must happen for each of these individually and be added up to the application impact account. You can not measure digital resource consumption on each and build averages or sum those first, you need to calculate the impact to be attributed to the application for each bundle or physical server based on the actual usage occurred on that system.
Approach 1: Using Digital Resources Monitoring (consumption based)
With this approach, you are ignoring the non-productive impacts and focus on the turning the digital resource consumption of the application into environmental impact. You do this by having, e.g. an IT monitoring system that monitors the digital resource usage of the application, and combining that usage with the impact account for each digital resource (as outlined under ‘Attributing the Operational and Embodied Impacts of the Server to Digital Resources’).
This means you need the information from the server on the impact account per digital resource that is being produced.
As a mental model, you can see this as a wire transfer. If the application is utilizing 10% of the CPU of the underlying server system for a day, that means the server must ‘send’ the impact of the CPU usage for that one day to the application (productive) account.
If the applications spans across multiple systems, e.g.
10 Kubernetes Pods
2 Bare-Metal Servers
14 Virtual Machines
The transfer must happen for each of these individually and be added up to the application impact account. You can not measure digital resource consumption on each and build averages or sum those first, you need to calculate the impact to be attributed to the application for each bundle or physical server based on the actual usage occurred on that system.
Approach 2: Using Digital Resource Allocation (reservation based)
Let’s say, you don’t have any IT monitoring system to measure the consumption of digital resources, but you got the following information from the IT infrastructure team (or someone else).
The application is using:
3 Virtual Machines with 16 GB Memory each, 16 Cores and 100 GB Disk
2 Bare Metal Servers with 128 GB Memory each, 96 Cores and 1.92 TB Disk
10 Pods with a resource request of 512 MB of memory each
Now the impact accounts of the servers providing the bundles or bare-metal capacity for each digital resource (as outlined under ‘Attributing the Operational and Embodied Impacts of the Server to Digital Resources’) can be used to calculate the non-productive impact account for the application. For this you can multiply the reservations with the digital resource type account, e.g. 128 GB of memory * operational and embodied impact account for the digital resource type ‘memory’ for that server.
For the virtual machines (VM), you need to to first calculate the percentage the resources that the VM is reserving of the total resources available in the underlying server, e.g. the server might have 128 GB of memory and 16 GB represent 12.5%. So you can take 12.5% of the memory’s digital resource impact account and allocate it to the application (as non-productive).
Approach 2: Using Digital Resource Allocation (reservation based)
Let’s say, you don’t have any IT monitoring system to measure the consumption of digital resources, but you got the following information from the IT infrastructure team (or someone else).
The application is using:
3 Virtual Machines with 16 GB Memory each, 16 Cores and 100 GB Disk
2 Bare Metal Servers with 128 GB Memory each, 96 Cores and 1.92 TB Disk
10 Pods with a resource request of 512 MB of memory each
Now the impact accounts of the servers providing the bundles or bare-metal capacity for each digital resource (as outlined under ‘Attributing the Operational and Embodied Impacts of the Server to Digital Resources’) can be used to calculate the non-productive impact account for the application. For this you can multiply the reservations with the digital resource type account, e.g. 128 GB of memory * operational and embodied impact account for the digital resource type ‘memory’ for that server.
For the virtual machines (VM), you need to to first calculate the percentage the resources that the VM is reserving of the total resources available in the underlying server, e.g. the server might have 128 GB of memory and 16 GB represent 12.5%. So you can take 12.5% of the memory’s digital resource impact account and allocate it to the application (as non-productive).
Approach 2: Using Digital Resource Allocation (reservation based)
Let’s say, you don’t have any IT monitoring system to measure the consumption of digital resources, but you got the following information from the IT infrastructure team (or someone else).
The application is using:
3 Virtual Machines with 16 GB Memory each, 16 Cores and 100 GB Disk
2 Bare Metal Servers with 128 GB Memory each, 96 Cores and 1.92 TB Disk
10 Pods with a resource request of 512 MB of memory each
Now the impact accounts of the servers providing the bundles or bare-metal capacity for each digital resource (as outlined under ‘Attributing the Operational and Embodied Impacts of the Server to Digital Resources’) can be used to calculate the non-productive impact account for the application. For this you can multiply the reservations with the digital resource type account, e.g. 128 GB of memory * operational and embodied impact account for the digital resource type ‘memory’ for that server.
For the virtual machines (VM), you need to to first calculate the percentage the resources that the VM is reserving of the total resources available in the underlying server, e.g. the server might have 128 GB of memory and 16 GB represent 12.5%. So you can take 12.5% of the memory’s digital resource impact account and allocate it to the application (as non-productive).
Approach 3: Combining Reservation & Consumption Approach for measuring productive and non-productive impact
The real magic happens when you combine both of these approaches. Because it enables you to close the delta of productive and non-productive environmental impact. If you can’t work on reduction for whatever reason, closing this delta at very least reduces the amount of wasted energy and manufactured equipment that is idling.
So for the portfolio of servers, virtual machines, containers and/or pods that the application is responsible for, you first calculate the non-productive account as outlined in Approach 2. This is the baseline, 100% idling, 100% non-productive. Then you add the measurement of usage for digital resources and can now continuously shift (’wire’) impact from the productive/non-productive account, depending on the actual usage.
Remember the accounts are cumulative, hence it will become a ‘an optimization game’ to avoid filling the non-productive account further, by ensuring utilization.
Approach 3: Combining Reservation & Consumption Approach for measuring productive and non-productive impact
The real magic happens when you combine both of these approaches. Because it enables you to close the delta of productive and non-productive environmental impact. If you can’t work on reduction for whatever reason, closing this delta at very least reduces the amount of wasted energy and manufactured equipment that is idling.
So for the portfolio of servers, virtual machines, containers and/or pods that the application is responsible for, you first calculate the non-productive account as outlined in Approach 2. This is the baseline, 100% idling, 100% non-productive. Then you add the measurement of usage for digital resources and can now continuously shift (’wire’) impact from the productive/non-productive account, depending on the actual usage.
Remember the accounts are cumulative, hence it will become a ‘an optimization game’ to avoid filling the non-productive account further, by ensuring utilization.
Approach 3: Combining Reservation & Consumption Approach for measuring productive and non-productive impact
The real magic happens when you combine both of these approaches. Because it enables you to close the delta of productive and non-productive environmental impact. If you can’t work on reduction for whatever reason, closing this delta at very least reduces the amount of wasted energy and manufactured equipment that is idling.
So for the portfolio of servers, virtual machines, containers and/or pods that the application is responsible for, you first calculate the non-productive account as outlined in Approach 2. This is the baseline, 100% idling, 100% non-productive. Then you add the measurement of usage for digital resources and can now continuously shift (’wire’) impact from the productive/non-productive account, depending on the actual usage.
Remember the accounts are cumulative, hence it will become a ‘an optimization game’ to avoid filling the non-productive account further, by ensuring utilization.
Summary
In short, for mapping the environmental impact of the infrastructure to the servers we are proposing that you first create an impact account for the reservation of resources created by the bundle of resources (virtual machine, pod or else). This account is the non-productive environmental impact and is defined by the share of environmental impact of the underlying server in relation to the amount of digital resources the reservation occupies on the server.
From there, you continuously shift the environmental impact (remember it’s cumulative!) to the productive account when the digital resources that are reserved are actually utilized. This way you can get an accurate reading of ‘resource efficiency’ of the application as well as total environmental impact created during the life cycle of the application.
When an application consists of many of those bundles (e.g. thousand virtual machines), we recommend you keep an impact account for each bundle and then aggregate the accounts on an application level. This also allows you to include development and staging environments in the calculation and when bundles are removed or added, they are simply added to the cumulative account of the application.
Since environmental impact can never be reversed, e.g. resource depletion or carbon emissions, can not be reversed and neither can energy be ‘put back’ it’s critical to keep all the accounts cumulative. Unfortunately, reducing an application’s infrastructure from a thousands virtual machines to hundred, cannot change the past. It only affects the rate of change, meaning the impact account accumulates impact less quickly.
Summary
In short, for mapping the environmental impact of the infrastructure to the servers we are proposing that you first create an impact account for the reservation of resources created by the bundle of resources (virtual machine, pod or else). This account is the non-productive environmental impact and is defined by the share of environmental impact of the underlying server in relation to the amount of digital resources the reservation occupies on the server.
From there, you continuously shift the environmental impact (remember it’s cumulative!) to the productive account when the digital resources that are reserved are actually utilized. This way you can get an accurate reading of ‘resource efficiency’ of the application as well as total environmental impact created during the life cycle of the application.
When an application consists of many of those bundles (e.g. thousand virtual machines), we recommend you keep an impact account for each bundle and then aggregate the accounts on an application level. This also allows you to include development and staging environments in the calculation and when bundles are removed or added, they are simply added to the cumulative account of the application.
Since environmental impact can never be reversed, e.g. resource depletion or carbon emissions, can not be reversed and neither can energy be ‘put back’ it’s critical to keep all the accounts cumulative. Unfortunately, reducing an application’s infrastructure from a thousands virtual machines to hundred, cannot change the past. It only affects the rate of change, meaning the impact account accumulates impact less quickly.
Summary
In short, for mapping the environmental impact of the infrastructure to the servers we are proposing that you first create an impact account for the reservation of resources created by the bundle of resources (virtual machine, pod or else). This account is the non-productive environmental impact and is defined by the share of environmental impact of the underlying server in relation to the amount of digital resources the reservation occupies on the server.
From there, you continuously shift the environmental impact (remember it’s cumulative!) to the productive account when the digital resources that are reserved are actually utilized. This way you can get an accurate reading of ‘resource efficiency’ of the application as well as total environmental impact created during the life cycle of the application.
When an application consists of many of those bundles (e.g. thousand virtual machines), we recommend you keep an impact account for each bundle and then aggregate the accounts on an application level. This also allows you to include development and staging environments in the calculation and when bundles are removed or added, they are simply added to the cumulative account of the application.
Since environmental impact can never be reversed, e.g. resource depletion or carbon emissions, can not be reversed and neither can energy be ‘put back’ it’s critical to keep all the accounts cumulative. Unfortunately, reducing an application’s infrastructure from a thousands virtual machines to hundred, cannot change the past. It only affects the rate of change, meaning the impact account accumulates impact less quickly.
Outlook
With this methodology, we introduce a few new key ideas:
Keeping cumulative accounts for environmental impacts
Attributing or distributing the environmental impacts from the total value chain of an application to the application itself
A holistic list of environmental impact indicators
Outlook
With this methodology, we introduce a few new key ideas:
Keeping cumulative accounts for environmental impacts
Attributing or distributing the environmental impacts from the total value chain of an application to the application itself
A holistic list of environmental impact indicators
Outlook
With this methodology, we introduce a few new key ideas:
Keeping cumulative accounts for environmental impacts
Attributing or distributing the environmental impacts from the total value chain of an application to the application itself
A holistic list of environmental impact indicators
Appendix
List of environmental impact indicators for software
Total Energy Use (kWh)
Total GHG Emissions (CO2-eq)
Embodied CO2-eq from manufacturing and transport of equipments and buildings
Operation CO2-eq from energy use
Resource Usage - Abiotic depletion potential (ADP)
Abiotic depletion connects the resource consumption of an organisation with the rarity of fossil resources. It uses the Abiotic depletion potential which is a dimensionless metric that compares the extraction rate of a resource with the ultimate reserve that we have in the world
Waste of electrical and electronic equipment (WEEE, tonnes)
List of environmental impact indicators for software
Total Energy Use (kWh)
Total GHG Emissions (CO2-eq)
Embodied CO2-eq from manufacturing and transport of equipments and buildings
Operation CO2-eq from energy use
Resource Usage - Abiotic depletion potential (ADP)
Abiotic depletion connects the resource consumption of an organisation with the rarity of fossil resources. It uses the Abiotic depletion potential which is a dimensionless metric that compares the extraction rate of a resource with the ultimate reserve that we have in the world
Waste of electrical and electronic equipment (WEEE, tonnes)
List of environmental impact indicators for software
Total Energy Use (kWh)
Total GHG Emissions (CO2-eq)
Embodied CO2-eq from manufacturing and transport of equipments and buildings
Operation CO2-eq from energy use
Resource Usage - Abiotic depletion potential (ADP)
Abiotic depletion connects the resource consumption of an organisation with the rarity of fossil resources. It uses the Abiotic depletion potential which is a dimensionless metric that compares the extraction rate of a resource with the ultimate reserve that we have in the world
Waste of electrical and electronic equipment (WEEE, tonnes)
Metrics that need to be exposed for by each entity to enable impact calculation by other entities:
Data Center
Emission Factor of IT Energy Provided:
on-site non-renewable energy generation: kWh and Type (e.g. Diesel)
depending on each Type, the GHG emission factor of the energy will vary when calculating the Operational Impacts
for the difference between Total Energy Use and Total Renewable Energy Production (kWh) the Grid Emission Factor (e.g. from the Electricity Map API) should be used to determine the GHG emissions for Operational Impact
Data Center Facility - Current Emission Factor (1 kg CO2-eq/kWh)
Data Center Facility - Total Rack Capacity at Facility (10)
Data Center Facility - Total Water Use (1.000 m3)
Data Center Facility - Total Waste Disposed (1.000 kg)
Data Center Facility - Power Usage Effectiveness (PUE, 1.6)
Metrics that need to be exposed for by each entity to enable impact calculation by other entities:
Data Center
Emission Factor of IT Energy Provided:
on-site non-renewable energy generation: kWh and Type (e.g. Diesel)
depending on each Type, the GHG emission factor of the energy will vary when calculating the Operational Impacts
for the difference between Total Energy Use and Total Renewable Energy Production (kWh) the Grid Emission Factor (e.g. from the Electricity Map API) should be used to determine the GHG emissions for Operational Impact
Data Center Facility - Current Emission Factor (1 kg CO2-eq/kWh)
Data Center Facility - Total Rack Capacity at Facility (10)
Data Center Facility - Total Water Use (1.000 m3)
Data Center Facility - Total Waste Disposed (1.000 kg)
Data Center Facility - Power Usage Effectiveness (PUE, 1.6)
Metrics that need to be exposed for by each entity to enable impact calculation by other entities:
Data Center
Emission Factor of IT Energy Provided:
on-site non-renewable energy generation: kWh and Type (e.g. Diesel)
depending on each Type, the GHG emission factor of the energy will vary when calculating the Operational Impacts
for the difference between Total Energy Use and Total Renewable Energy Production (kWh) the Grid Emission Factor (e.g. from the Electricity Map API) should be used to determine the GHG emissions for Operational Impact
Data Center Facility - Current Emission Factor (1 kg CO2-eq/kWh)
Data Center Facility - Total Rack Capacity at Facility (10)
Data Center Facility - Total Water Use (1.000 m3)
Data Center Facility - Total Waste Disposed (1.000 kg)
Data Center Facility - Power Usage Effectiveness (PUE, 1.6)
Conversion formula’s
Conversion formula’s
Conversion formula’s
In a future update, we are going to include approaches for converting measurements into environmental impacts, e.g. energy as well as provide our research findings on useful defaults for anything you might need to account for.
In a future update, we are going to include approaches for converting measurements into environmental impacts, e.g. energy as well as provide our research findings on useful defaults for anything you might need to account for.
In a future update, we are going to include approaches for converting measurements into environmental impacts, e.g. energy as well as provide our research findings on useful defaults for anything you might need to account for.
List of assumptions for cloud region data centers
List of assumptions for cloud region data centers
List of assumptions for cloud region data centers
We are going to add this in a future update, still researching an up-to-date dataset.
We are going to add this in a future update, still researching an up-to-date dataset.
We are going to add this in a future update, still researching an up-to-date dataset.
List of tools to measure energy use of servers
List of tools to measure energy use of servers
List of tools to measure energy use of servers
We are going to add this in a future update, still researching an up-to-date list.
We are going to add this in a future update, still researching an up-to-date list.
We are going to add this in a future update, still researching an up-to-date list.
List of waste streams to consider for the facility
List of waste streams to consider for the facility
List of waste streams to consider for the facility
