Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emit node level metrics for grid intensity #40

Open
rossf7 opened this issue Jul 15, 2022 · 4 comments
Open

Emit node level metrics for grid intensity #40

rossf7 opened this issue Jul 15, 2022 · 4 comments

Comments

@rossf7
Copy link
Contributor

rossf7 commented Jul 15, 2022

Currently each deployment of the grid-intensity exporter needs to be manually configured with the correct region for the data centre it is deployed in. If the cluster spans multiple physical data centres then multiple deployments of the exporter are needed.

If each node could auto-discover its grid intensity the manual configuration step can be removed. This would also allow carbon aware schedulers to place workloads on nodes with the lowest intensity.
e.g. Carbon Aware Nomad https://github.com/hashicorp/nomad/blob/h-carbon-meta/CARBON.md

The Carbon Explorer paper from FaceBook describes how they use the Monitor real-time data source in their US data centres to get grid intensity data. https://arxiv.org/pdf/2201.10036.pdf

Many hosting providers provide metadata APIs so physical nodes or VMs can identify which region they are deployed in.
If these regions can be mapped to physical locations they can be mapped to the correct region for the grid intensity provider.

e.g. WattTime API for mapping latitude / longitude to balancing authority https://www.watttime.org/api-documentation/#determine-grid-region

@rossf7
Copy link
Contributor Author

rossf7 commented Jul 15, 2022

@mrchrisadams Here is the issue from our discussion in https://github.com/thegreenwebfoundation/grid-intensity-go/pull/35/files#r921183214

Does it look OK?

@mrchrisadams
Copy link
Member

Yeah, this is good.

I think it's plausible to support reporting based on the grid intensity of the DC or region a node is working in, but it would likely be a larger piece of work to support reporting based on local green energy generation or batteries.

It's possible though!

There's now a spec and a set of configurations for people running infra to export what are essentially time stamped certificates for the renewable energy generated on site from Energy Tag called Granular Certificates.

These essentially make make machine readable claims about their infra running on green energy on an higher time resolution than annual certifications we currently rely on.

The Granular certifcates spec outlines various ways to describe a scheme so it can be audited, but I think that just how you can do self certified SSL certificates, you could generate self-certified timestamped certificates that used the same fields and units as the audited schemes, for building prototypes.

Morein the energy tag spec below:
https://energytag.org/publications/

This wouldn't be the same as having certificates issued by an actual trusted, audited scheme that was 'blessed' by Energy Tag, but it would provide an on-ramp for having this information audited in future, and you could use this to work out the effective carbon intensity of infra that had it's own way to reduce the carbon intensity of power it draws from the grid.

Here's an example that RISE is doing in the Nordics - https://www.ri.se/en/smart-integration-of-electricity-grid-micro-grids-and-data-center

And here's the very simplified image for it - carbon intensity of compute can be different to the grid based on what kind mix of energy inputs it runs on :)

multiple kinds of energy going into a DC

@mrchrisadams
Copy link
Member

mrchrisadams commented Jul 15, 2022

oh, I just remembered.

We could plausibly experiment with getting box to simulate some of the ideas listed above by asking @scottsweb about his project, Ham:

https://scott.ee/project/solar-hosting-raspberry-pi/

It's conceptually similar, but working at a muuuuuch smaller scale - he's running a raspberry pi to manage a series of containerised workloads with a connected battery and solar panel, and even I think there is a fallback to the grid for some scenarios too.

Here's a pic. It's a fun read.

pic

@scottsweb
Copy link

scottsweb commented Jul 15, 2022

Thanks for the ping @mrchrisadams! Let me know if you folks have any questions about my project.

Just had a look through grid-intensity-go (not seen it before) and being able to move your code about to follow carbon intensity is an interesting idea. Definately not without challenges. For example the product I am working on at the moment has a huge database that would take days (possibly weeks to move), so this is only going to lend itself to certain parts of the stack... the front end would be easily moved around. It would be nice to be able to constrain desitnations too... so you could move your containers within in the EU for example, choosing the best location that is also near to your audience.

Anyway, I will stop mumbling in your GitHub thread! Keep up the good work! 😃

One last comment/thought. I use Home Assistant for my container orchestration as everything is hosted at home and it allows me to respond to all sorts of events and sensor. For example I startup a VPN container when anyone leaves home so we can connect back if needed. I also just pushed my automations that control my secondary host based on the battery level of the primary host: scottsweb/ham@3e60b20 - so when the battery gets low, the backup container is started up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants