Showing posts with label power. Show all posts
Showing posts with label power. Show all posts

Net-SNMP for PDU?

Mike's Notes

I'm looking for a solution to a problem. Some working notes.

"The first Data Centre

Once scaling begins, Pipi 9 will then need a data centre to use as a render farm to automatically create customised SaaS enterprise applications based on user requirements. The data centre will be completely isolated from the internet to maximise security. It can be expanded in stages if it is planned appropriately.

Each industry and each enterprise customer will get a dedicated server to store a mirrored copy of their deployment configuration and parameters, including localisation. No user data will be stored." - On A Sandy Beach

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

15/01/2026

Net-SNMP for PDU?

By: Mike Peters
On a Sandy Beach: 15/01/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

The future Pipi 9 data centre must be fully automated and physically isolated from the internet.

Power

19" rack-mounted intelligent PDU will distribute power to servers.

According to Server Room Environments

Intelligent Rack PDUs

Intelligent PDUs add a level of sophistication to power distribution within IT server racks and include:

  • PDU and Outlet Metering: metered PDUs provide power-related information locally and remotely, which can include Amps (A), Volts (V), Frequency (Hz), Watts (W), Energy (kWh) and Power (kVA). The power readings can be for individual outlets and the total PDU usage. The information can be used by IT managers for capacity planning, the prevention of circuit overloads, client and cost centre billing (with +/- 1% accuracy) and efficiency calculations, including Power Usage Effectiveness (PUE).
  • Switched and Outlet Switched: a switching PDU will include metering and add the ability to remotely control (ON/OFF) to the PDU and the outlets. Outlet-switched PDUs provide a way for IT and data centre managers to remotely reboot or power down connected loads and allow for cascading power-ups to manage load inrush currents. Switching PDUs adds a layer of security to a server room or data centre power plan in terms of controlling unauthorised access to rack-level loads and their power connections. Costs are also reduced, as an onsite engineer visit is removed in most instances.
  • Remote IP Monitoring: the PDU provides connectivity for remote monitoring and can include HTTP/HTTPS, iPV4 and iPV6, Telnet, SSH, Virtual Serial, SNMP (v1, v2c, v3), JSON-RPC, LDAP, FTP/SFTP and RADIUS for secure login. The monitoring provides a way to view the status of the PDU and its individual socket outlets using a browser, monitoring software or a data centre infrastructure management (DCIM) software suite. The PDU may also offer a RESTful API for bespoke communications applications. Dual Ethernet ports can provide communications redundancy, and the communications module will typically be a ‘hot-swap’ type.

This means that each individual power outlet can be remotely switched on and off via IP. That could be controlled by another server.

A server can power up automatically when the power outlet is turned on. The server can be made to run a program (Pipi 9), do some work, create a backup, and then shut down.

My question is:

"Could the PDU detect that the server has shut down and then turn off the power outlet?"

According to a post on the Schneider Electric forum, this can be done with scripting using Net-SNMP.

Net-SNMP

It runs on Linux and Windows and is open-source.

"Net-SNMP is a suite of software for using and deploying the SNMP protocol (v1, v2c and v3 and the AgentX subagent protocol). It supports IPv4, IPv6, IPX, AAL5, Unix domain sockets and other transports. It contains a generic client library, a suite of command line applications, a highly extensible SNMP agent, perl modules and python modules." - Wikipedia

Pipi 9 in production

Pipi 9 is large but also very power-efficient (it's not an LLM). Each copy of Pipi 9 requires its own server. In this data centre, each enterprise customer has its own backend server running a customised Pipi 9 as a digital twin. I'm experimenting to see whether a small-form-factor refurbished PC could do the job.

There would need to be hundreds of these PCs in racks, autonomously coming online and offline as required to run batch jobs. Massive redundancy is provided by having spare PCs synced, NAS storage, VMs, etc.

This means that single-phase PDUs can be used. Maybe 1 PDU per 10-15 PCs per shelf, with only a few PCs running at any given time. 1 UPS per cabinet at the bottom, supplying multiple shelves.

Mechanical air-lock

Data needs to pass between this isolated data centre and customer deployments hosted in the cloud. My thought is to add a staging area (or several) between the two and pass data back and forth via network switches that are mechanically cycled (analogue). A bit like a double air-lock in space.

This would make it impossible for an external attacker to breach the system.

Robots in control

Pipi 9 is designed to serve as the system administrator for all customer cloud deployments. Coming on only as needed and in quiet times to minimise any disruption.

  • Updates
  • Configuration
  • Security
  • Databases
  • Deploying Docker
  • etc

Data Center Heatmap

Mike's Notes

Note

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

17/05/2025

Data Centre Heatmap

By: Barry
Barry on WordPress: 28/07/2022

At Automattic, our systems team manages over 10,000 physical servers located across 30 data centers on 6 continents. As our compute density has increased from 24 CPU threads/RU in 2013 to 128 CPU threads/RU in 2022 the maximum thermal thresholds have decreased. Older, less powerful servers could operate with inlet air temperatures up to 42C (107.6F) while newer servers trigger CPU throttling at much lower temperatures of 35C-37C (95F – 98.6F). Normal data center operating temperatures tend to be between 20F-25C, but cooling failures are somewhat common (they even affect Google), so we have to monitor temperatures carefully.

We are big fans of Prometheus and Grafana, and for a few years, our temperature graphs have looked like this.


This graph shows the temperatures of some servers located in our data center in Johannesburg, South Africa over one week. The coloured lines represent individual servers, and the bold red line is the average temperature in the rack.

We get this data from our server's inlet temperature sensor using ipmitool. I thought it would be interesting to visualize this data a bit differently, and Grafana has a Heatmap graph type that makes it pretty easy. 

First, we simply want to graph the temperature by location for a given datacenter. In PromQL this looks like

avg by (location) (ipmi_inlet_temp{dc="$DC"})

location includes the rack identifier and the location in the rack. For example a location of 101-10 would mean Rack 101, RU 10. We store this information is our data center asset management system (which is a colon separated file) and it gets added as labels to all Prometheus metrics. By choosing the Heatmap (New) graph type and configuring some basic graph options, Grafana allows us to create a graph which shows the same data as our original graph, but in a different, and more useful way. We can easily see that the top of the rack is warmer than the bottom which is to be expected since the cold air in this facility comes from the floor. We can also see that temperatures have increased slightly over the past week, which is not ideal, but they are not at dangerous levels.

JNB

We can contrast this with a rack in Milan, Italy, where there was a cooling outage which caused the servers to operate beyond their intended temperature threshold for some time: 

Milan, Italy

Using the same data and graph options, we can also easily create heat maps of entire rows of racks to visualize airflow management and identify areas for potential improvement. Here is a row of racks in a data center in Los Angeles with poor airflow management. We can see the racks at the end of the row suffer from increased temperatures due to air leakage from the hot aisle to the cold aisle. 

Los Angeles

This data can be contrasted with data from a set of racks in Amsterdam, which have much better airflow management.

Amsterdam

This post shows how easy it is to create cool(!!) and useful heat maps using Grafana, Prometheus, and a little time. If this sort of stuff interests you, Automattic is hiring!