UUID: 000011302025 | Documentation ArchThinkCluster

————————————————————————————————————————————————————-

  System Specifications Notes

 # LAB Setup :

LAB1: work computer, LAB3: mobile work terminal 1, LAB4: mobile work terminal 2. Xfinity home router, network switch 1: TP-link TL-SG108E switch.

 # Cluster Setup :

5x Lenovo ThinkCentre Micro Desktops 16GB DDR4 RAM 256GB SSD Drive AMD Processor Model Name M625, Network Switch 2: STEAMEMO 16 Port Gigabit PoE,CENMATE Aluminum 6 Bay Hard Drive Enclosure, 3× 2TB hard drives

 # Network setup :

  I do not know proper technical terms, so bear with me.

The data flow starts at the router; this is the section I call the Home Network and is where all of the home devices can be found, these are connected directly to the router modem through WiFi. Past this, we have Network Switch 1. Network Switch 1 is connected directly to the router modem via a CAT9 Ethernet cable. LAB1 is connected to Network Switch 1 with a CAT9 Ethernet cable. Past Net Switch 1, we have Network Switch 2, which is directly connected to Net Switch 1 via CAT9 Ethernet cable. Network Switch 2 is the hub switch for the cluster, all of the cluster machines are connected to Network Switch 2 with a CAT9 Ethernet cable such as thinkcenter001 the master node and NAS1 the NAS.

#    [wifi home network]      [LAB1, 3D printers, ect]    [Cluster, master nodes, slave nodes, NAS1]

  |                      |                                   |      

#    [router modem]<——CAT9——>[network switch 1]<——CAT9——>[network switch 2]

————————————————————————————————————————————————————-

 The PXE boot system                            

 The PXE boot system is primarily composed of two services. The first one that I had to build from scratch or set up by hand is the Proxy-DHCP + TFTP server run as the dnsmasq service. This service is what is handing out the PXE boot info and the iPXE (a modern open-source replacement for PXE) binary over TFTP (Trivial File Transfer Protocol). It does not hand out any IPs and does not handles leases, and the router hosts a full DHCP server. The second service is PXE-HTTP.Service, this is the actual repository. The packages the TFTP server handles are transferred to the booting node.

————————————————————————————————————————————————————-

 # What is the service dnsmasp.service

 The service dnsmasq.service is the proxy DHCP + TFTP server. This service is handing out the PXE boot info and the iPXE (a modern open-source replacement for PXE) binary over TFTP (Trivial File Transfer Protocol). It does not hand out any IPs and keeps no leases. The router hosts a full DHCP server.                                                                                                      

————————————————————————————————————————————————————-

 # What is the service pxe-http.service

 The PXE boot system is primarily composed of two services. The first one that I had to build from scratch or set up by hand is the ProxyDHCP + TFTP server run as the dnsmasq service. This service is what is handing out the PXE boot info and the iPXE (a modern open-source replacement for PXE) binary over TFTP (Trivial File Transfer Protocol). It does not hand out any IPs and does not handles leases, and the router hosts a full DHCP server. The second service is PXE-HTTP.Service, this is the actual repository.The packages the TFTP server handles are transferred to the booting node.

————————————————————————————————————————————————————-

 # what is the service cluster-repo.service

The service cluster-repo.service is a simple Python HTTP server that, as of right now hosts just SLURM and its dependencies.It’s similar to the service pxe-http.service in the sense that it’s just a local single package repo that the cluster can pull from. This service is also self-restarting.The directory is located in is /srv/cluster-repo/ where all the files for this service are as well.

————————————————————————————————————————————————————-

 # ACNST Tool Documentation            

The ACNST (Arch Cluster Network Scan Tool) is a custom C++ tool. It scans the cluster LAN using arp-scan and keeps a persistent device log keyed by MAC address. This is the tool that makes provisioning on a network with non-static IPs simple.At present, the current cluster network is tied to my home network via DHCP, managed by the Xfinity router. The router hands out the IPs.That means when a fresh slave node PXE boots, we have no idea what IP it has been assigned, and nothing on the network remembers who is who between reboots, and the master node can’t talk to anything either.ACNST fixes this by keeping a living log of every device it has ever seen, keyed by MAC address, which stays the same between reboots.So even when the router shuffles IPs around, we always know “e0:be:03:… is arch001” and can see its current IP, online/offline status, and last-seen time.This program tries to keep a live map of the network using a systemd timer (acnst-scan.timer) that runs a scan every 30 minutes.

 # operation

 # !we run all ACNST commands inside the ACNST directory!

 We can run the help command with – bin/acnst help,

 run a the scan command with – bin/acnst scan,

 We can vew the logs with the command – bin/acnst list,

 and we can set a hostname with the command bin/ acnst set-hostname –mac <MAC> –hostname <name>.

 It is important to tag nodes as soon as or before they come online.

 The ssh-list command prints the root@ for the online systems so scripts, robots, and humans don’t have to look up or hard code an IP.

 The ssh-list can pass that information to whatever needs it, we can call the ssh-list command with bin/acnst list.

 # Troubleshooting

 Troubleshooting: If a node is supposed to be running but the log shows it OFFLINE, something is wrong with that node or its cabling. Check the log first before digging deeper. If required, we have additional documentation such as full build, install, and test instructions in the ACNST repo’s README.

 (repo: https://github.com/REDACTED(coming soon))

 # dependencies – CMake v3.16, C++ compilerC++17 capable (GCC or Clang), arp-scan, glibc, make

——————————————————————————————————

 thinkcenter001 the master node and the first node|

 Networking

# Network management service :

We are using the NetworkManager network manager. Because of this, all networking function are managed by NetworkManager and auto-starts on boot. systemd-networkd is also present and running,pulled in as a dependency/socket-activated, but is disabled and should not start on boot and reports enp3s0 as unmanaged—it does not manage any interfaces and does not conflict with NetworkManager. We are using the default-named connection profile “Wired connection 1” (UUID 75c857cf-25b1-3302-8f43-8f84cd588bb3), set to a manual IPv4 config. There is no DHCP reservation and no custom dispatcher script involved. The static config lives entirely in this NM profile.

frame STL files

This section contains the STL files for ArchThinkCluster’s modular frame system, a 3D-printable rack structure built to house and organize compute nodes in a compact footprint. The frame breaks down into four printable components: a node cage for securing individual boards, stackable rack body sections (base and middle) that let the enclosure scale vertically as the cluster grows, and a rear wire cover for clean cable routing. Like the rest of this project, these files are a work in progress. Dimensions are currently sized for Lenovo ThinkCentre units only, and other platforms aren’t supported yet.