IXP-from-Scratch: The Peering LAN
• 13 min read
In the third of our “IXP from Scratch” series, we discuss our setup of the peering switches and route servers at DD-IX, an Internet Exchange located in Dresden, Germany. We explain how we connect our two PoPs and which security and safety mechanisms (L2 and L3) we configured to ensure reliable oper…
“Great article, thanks! How is file/data storage handled on/for the VMs? Local Data partitions on the host passed through to the VMs without any replication or alike (apart from maybe RAID) plus external backup?”
The root file system on the VM is a tempfs, the relevant folders (e.g. /etc, /var/lib) are shared directories on the host using virtiofs (e.g. in /var/lib/microvm/svc-cloud01/var/lib). On the host, we use ZFS with a simple mirror between two SSDs and two additional SSDs as hot spares. Our offsite backup is restic based.
“"the NixOS infrastructure relies heavily on GitHub" Why? NixOS needs to contact Github daily like ChromeOS needs to talk to Google? And if it is just to update packages, aren't they alternative sources?”
NixOS does not need to connect to GitHub daily. GitHub only hosts derivations (similar to "Makefiles") to build NixOS packages but not the actual packages. All packages are hosted on caches hosted by fastly (among other features, fastly supports IPv6). Once the derivations repository is retrieved and stored on your local system, you no longer need to contact GitHub, unless you want to switch to another compile configuration. One solution to avoid connecting to GitHub at all would be mirroring Nixpkgs somewhere else. But since the repository size increases continously to a size similar to the kernel repository, third-party providers don't like that so much. To give a rough estimate, Nixpkgs experiences one commit every 3 minutes.
Showing 2 comment(s)