Cloud instances
Warning
Before v1.2, the impacts in the verbose dictionary qualified the impacts of the component of the whole server hosting the instance. Since v1.2, the impacts in the verbose dictionary are the impacts of the portion of the component used by the instance itself.
Characteristics
Cloud instance characteristics are pre-recorded as archetypes. The API will complete the following characteristics depending on the cloud provider and cloud instance name given by the user :
| Name | Unit | Description | Example |
|---|---|---|---|
| vcpu | None | Number of virtual CPUs | 2 |
| memory | GB | RAM capacity | 32 |
| ssd_storage | GB | SSD storage capacity | 500 |
| hdd_storage | GB | HDD storage capacity | 0 |
| platform | None | Bare metal hosting the instance | a1.metal |
| usage | None | See usage |
To add a new cloud instance to the API please refer to the cloud instance contribution guide.
Cloud instance usage
In addition to the characteristics available for usage, you can use the following:
| Name | Unit | Default value (default;min;max) | Description | Example |
|---|---|---|---|---|
| other_consumption_ratio | None | 0.33;0.2;0.6 | Power consumption ratio of other components relative to RAM and CPU | 0.2 |
Perimeter covered
Following the Life Cycle Assesment methodology, we should include everythin that is needed to provide the Functional Unit. In the case of cloud instances, using te BoaviztAPI for evaluation, the Functional Unit would probably look like "using an instance of type/family X during N hours, with a load average of Z%". To be complete regarding the impact of such an FU, we should of course account for a share of the bare metal servers used to provide the instance, but also : - share of network infrastructure dedicated to the same service/FU - share of the mutualized infrastructure (servers, network, storage, etc.) used to deliver the service - share of the mutualized technical environment (building, cooling, lighting, etc.), allocated thanks to an adequate allocation factor
Today the BoaviztAPI only accounts for the share of resources used on the bare metal servers dedicated to the IaaS/instances service.
The drawing above represents in black and plain lines the parts of the impact that are actually accounted for and in gray and dotted lines the ones that remain to be implemented.
The other parts of the impact shall be implemented in a near future, using hypothesis when necessary.
Embedded impacts
Impacts criteria
| Criteria | Implemented | Source |
|---|---|---|
| gwp | yes | Bottom-up approach based on Green Cloud Computing, 2021 |
| adp | yes | Bottom-up approach based on Green Cloud Computing, 2021 |
| pe | yes | Bottom-up approach based on Green Cloud Computing, 2021 |
| gwppb | yes | Base IMPACTS® ADEME |
| gwppf | yes | Base IMPACTS® ADEME |
| gwpplu | yes | Base IMPACTS® ADEME |
| ir | yes | Base IMPACTS® ADEME |
| lu | yes | Base IMPACTS® ADEME |
| odp | yes | Base IMPACTS® ADEME |
| pm | yes | Base IMPACTS® ADEME |
| pocp | yes | Base IMPACTS® ADEME |
| wu | yes | Base IMPACTS® ADEME |
| mips | yes | Base IMPACTS® ADEME |
| adpe | yes | Base IMPACTS® ADEME |
| adpf | yes | Base IMPACTS® ADEME |
| ap | yes | Base IMPACTS® ADEME |
| ctue | yes | Base IMPACTS® ADEME |
| ctuh_c | yes | Base IMPACTS® ADEME |
| ctuh_nc | yes | Base IMPACTS® ADEME |
| epf | yes | Base IMPACTS® ADEME |
| epm | yes | Base IMPACTS® ADEME |
| ept | yes | Base IMPACTS® ADEME |
Method
Embedded impacts of cloud instances are assessed based on the physical characteristics of the bare metal server hosting the instance (also named platform in this documentation).
The API allocate a portion of the impacts of each component to the instance based on the ratio of the instance characteristics to the server characteristics :
- For RAM : \(\text{RAM}_{\text{instance}}^{\text{embedded}} = \text{RAM}_{\text{server}}^{\text{embedded}} \times \frac{\text{memory}_{\text{instance}}}{\text{RAM}_{\text{server}}}\)
- For SSD storage : \(\text{SSD}_{\text{instance}}^{\text{embedded}} = \text{SSD}_{\text{server}}^{\text{embedded}} \times \frac{\text{ssd_storage}_{\text{instance}}}{\text{ssd_storage}_{\text{server}}}\)
- For HDD storage : \(\text{HDD}_{\text{instance}}^{\text{embedded}} = \text{HDD}_{\text{server}}^{\text{embedded}} \times \frac{\text{hdd_storage}_{\text{instance}}}{\text{hdd_storage}_{\text{server}}}\)
- For CPU and all other components : \(\text{Component}_{\text{instance}}^{\text{embedded}} = \text{Component}_{\text{server}}^{\text{embedded}} \times \frac{\text{vCPU}_{\text{instance}}}{\text{vCPU}_{\text{server}}}\)
The API will sum the embedded impacts of each component to get the embedded impacts of the instance :
When component impacts are not available, the API will use the generic impacts of the server and allocate the impacts to the instance based on the ratio of the instance vCPU to the server total vCPU :
\(\text{Instance}_{\text{embedded}} = \text{Server}_{\text{embedded}} \times \frac{\text{vCPU}_{\text{instance}}}{\text{vCPU}_{\text{server}}}\)
Usage impacts
Usage impact of cloud instance are measured only from its consumption profile.
Consumption profile
A cloud instance consumption profile is of the form :
\(\text{CP}_{\text{CPU_server}}(\text{workload})\) and \(\text{CP}_{\text{RAM_server}}(\text{workload})\) depend on the technical characteristics of the RAM and CPU. \(\text{other_consumption_ratio}\) is used to account for the electrical consumption of the other components (other than RAM and CPU).