Thanks Tim for clarifying. On Wed, Mar 30, 2016 at 3:39 PM, Tim Starling <tstarl...@wikimedia.org> wrote:
> On 31/03/16 02:55, Katherine Maher wrote: > > IIRC, we included clean energy consumption as a factor in > > evaluating in our RFC for our choice of a backup colo a few years back > > Since I strongly support emissions reduction, on my own initiative I > did an analysis of expected CO2 emissions of each of the candidate > facilities during the selection process of the backup colo. That's > presumably what you're referring to. > > < > https://docs.google.com/spreadsheets/d/1adt45Msw2o8Ml0s8S0USm9QLkW9ER3xCPkU9d2NJS4Y/edit#gid=0 > > > > My conclusion was that codfw (the winner) was one of the worst > candidates for CO2 emissions. However, the price they were offering > was so much lower than the other candidates that I could not make a > rational case for removing it as an option. You could buy high-quality > offsets for our total emissions for much less than the price difference. > > However, this observation does require us to actually purchase said > offsets, if codfw is to be represented as an ethical choice, and that > was never done. > > codfw would not tell us their PUE, apparently because it was a > near-empty facility and so it would have technically been a very large > number. I thought it would be fair to account for marginal emissions > assuming a projected higher occupancy rate and entered 2.9 for them, > following a publication which gave that figure as an industry average. > It's a new facility, but it's not likely that they achieved an > industry-leading PUE since the climate in Dallas is not suitable for > evaporative cooling or "free" cooling. > > > Ops runs a tight ship, and we're a relatively small footprint in our > colos, > > so we don't necessarily have the ability to drive purchasing decisions > > based on scale alone. > > I think it's stretching the metaphor to call ops a "tight ship". We > could switch off spare servers in codfw for a substantial power > saving, in exchange for a ~10 minute penalty in failover time. But it > would probably cost a week or two of engineer time to set up suitable > automation for failover and periodic updates. > > Or we could have avoided a hot spare colo altogether, with smarter > disaster recovery plans, as I argued at the time. My idea wasn't > popular: Leslie Carr said she would not want to work for an > organisation that adopted the relaxed DR restoration time targets that > I advocated. And of course DR improvements were touted many times as > an effective use of donor funds. > > Certainly you have a point about scale. Server hardware has extremely > rudimentary power management -- for example when I checked a couple of > years ago, none of our servers supported suspend-to-RAM, and idle > power usage hardly differed from power usage at typical load. So the > only option for reducing power usage of temporarily unused servers is > powering off, and powering back on via out-of-band management. WMF > presumably has little influence with motherboard suppliers. But we > could at least include power management and efficiency as > consideratons when we evaluate new hardware purchases. > > > At the time the report came out, we started talking to Lukas about how we > > could improve our efforts at the WMF and across the movement, but we've > had > > limited bandwidth to move this forward in the Foundation (and some > > transitions in our Finance and Operations leadership, who were acting as > > executive sponsors). However, I think it's safe to say that we'd like to > > continue to reduce our environmental impact, and look forward to the > > findings of this effort. > > We could at least offset our datacentre power usage, that would be > cheap and effective. > > -- Tim Starling > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Katherine Maher Wikimedia Foundation 149 New Montgomery Street San Francisco, CA 94105 +1 (415) 839-6885 ext. 6635 +1 (415) 712 4873 kma...@wikimedia.org _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
