In this post I’ll explain how we run our LAN-Party Server including networking, caching, monitoring and how we observe our energy Consumption in a IoT manner.
Edit: Visit this imgur collection for more images in high quality.
Server
Our Server is a dedicated machine we bring to every LAN-Party. It has the following specs:
CPU: 2x Intel Xeon E5645 6x2.4 GHz
RAM: 48GB DDR3
NIC: 3x Gigabit
SSD: 2x 250GB
On this machine we run Proxmox as virtualization management platform.
Network
To allow us basic network management a pfSense VM on there was set up following this guide.
For monitoring pfSense we use graylog and Grafana which are running in a separate VM. It’s all setup pretty straight forward using docker-compose and this guide. Besides the usual separation from the houses uplink and network management this allows us to see interesting metrics such as bandwidth used per client or traffic type.
We also added DNS rebind firewall rules so the hackerboys on our LAN-Party can’t bypass the cache server.
Caching
As for every good LAN-Party one should have Caching Server running to save bandwidth. The most popular is lancache.net which is what we use too. We went with the generic docker-compose setup because it’s very easy to set up and maintain. With the hardware above we’re able to handle a 100Mbit uplink through the cache and reach up to 110MB/s peak Download speeds from the cache (RAM).
Lancache monitoring
For monitoring the cache we use the ELK-Stack. This kibana dashboard shows general stats like internet bandwidth saved (because we the data was served from cache) or cache content type (steam, origin …).
Settings this up takes a bit more work as things might not run out of the box. There’s a repository containing configurations for logstash and kibana from the makers of lancache.net. However depending on when you’re reading this article the Pull Request containing updated logstash v7 configs might not be merged yet. You’ll have to use the updated config from the PR. Additionally, I had to modify the output section in logstash.conf to reflect my setup with just one elasticsearch instance and the DNS name used in the docker-compose.yml.
output {
elasticsearch {
hosts => “elasticsearch:9200”
ssl => false
user => “elastic”
password => “changeme”
index => “%{my_index}”
}
}I used docker-elk as a starting point to run the elk stack. I replaced the logstash.conf file there with the one I talked about above. Additionally I imported the elasticsearch/kibana config from everyting.json. This creates some Dashboards like the one shown in the screenshot above.
On the caching server (where lancache.net is running in docker-compose) I added a filebeat container to the bottom of docker-compose.yml from lancache.net.
filebeat:
image: docker.elastic.co/beats/filebeat:7.9.1
volumes:
— ${CACHE_ROOT}/logs:/data/logs
— /home/administratore/lancache/config/filebeat/filebeat.yml:/usr/share/filebeat/filebeat.ymlThe filebeat.yml contains config for where filebeat sends the logs to. You’ll have to edit the host IP to point to your elk machine.
filebeat.inputs:
- type: log
paths:
— '/data/logs/*.log'
encoding: utf-8
output.logstash:
hosts: [“192.168.1.6:5044”]
bulk_max_size: 1024This will send all .log from §{CACHE_ROOT}/logs via filebeat to elasticsearch which accepts the logs with logstash as configured above.
Energy monitoring
This is probably the part most people are interested in. On our previous LAN-Parties we were curious how much energy we’re consuming with all that equipment running. Therefore, we built Wattson with the help of Datacake (more on Datacake later). Wattson is an IoT power and energy meter which allows us to monitor 3x16A 230V power lines (theoretically up to 100A) i.e. a normal 16A CEE plug which is enough power for our LAN-Party size.
We built everything around the B+G E-Tech SDM630Modbus V2 power/energy meter. This device measures everything you probably ever want to know about your power lines like voltage, current, power, phase angle, THD (Total harmonic distortion) or just simple power consumption in kWh. The data is read using a particle Argon and a custom made Modbus breakout (You don’t have to use an particle board for that. Any Internet enabled Modbus board will do). With the particle board it’s simple to periodically send data up into the cloud from where we can process and visualize it. And this is where Datacake joins the game. Datacake allows us to get IoT projects running in minutes and build beautiful dashboards for them (without writing a single line of code!). You now might ask yourself: “With all this other technology you use for monitoring pfSense and Lancahce, why don’t you simply run Grafana on your own server here again?”. The answer is pretty simple: flexibility. We built Wattson with the thought in mind to use it for other events too, not only LAN-Parties. With datacake we don’t need to host any services by ourselfs and I don’t have to struggle with setting up the connection from the particle board up to Grafana (which can get complicated, trust me).
Setting up Wattson
I just set up a new device on Datacake and started adding all the fields according to the datasheet.
And afterwards started to create a general and a more detailed dashboard for the device (there was no data back then, the screenshots were taken later)
Connecting Wattson with Datacake
After connecting the particle board to particle Cloud (see the particle’s getting started guide) I had to program the board to read values via Modbus and publish them as events to the particle cloud. This example shows the process for just the 3 power lines.
float p1 = readRegister(0x000C);
float p2 = readRegister(0x000E);
float p3 = readRegister(0x0010);
Particle.publish("power", String::format("%.3f;%.3f;%.3f", p1, p2, p3));This will read current power levels on each line and publish them on the “power” event to particle cloud. From there we forward the event over to Datacake with a Webhook Integration.
On the Datacake device we just added appropriate Webhook handlers. These will assign the values from the Webhook to Datacake device fields.
Repeat that process until you have everything you’re interested in. We also added different priority queues to reduce total message count because some Measurements were more important than others to us.
Conclusion
Using all this technology we manages to have a nice LAN-Party. We didn’t have huge problems with high ping or bandwidth being occupied. We were able to distribute power evenly across the 3 phases. Definitely looking forward to use this setup at future LAN-Parties or other events.
Feel free to contact me for more information on this project.
