1. RuggedPOD O/S Deployment strategy

2. Disclaimers The content of this presentation is released under GPL v2 license en Creative Common Attribution-ShareAlike 4.0 International Attribution-ShareAlike 4.0 International Feel free to contact us if you have any question – team@ruggedpod.qyshare.com team@ruggedpod.qyshare.com RuggedPOD is an Open Hardware project released under OCP HL R license.

3. Context RuggedPOD can be operated from LAN to WAN (aka the distance between the POD might be really long with limited bandwidth and high latency in the case of a Telco CDN usage, or could be ultra short in the case of an Outdoor Datacenter Approach)

4. Software constraints RuggedPOD has a local firmware running on a RaspberryPI 2 board. This firmware is Linux based and has to be upgradable Local boards needs to be remotely bootable and installable.

5. Long distance use case  600 kms  10Mbps  100 kms  100Mbps RuggedPOD 1RuggedPOD n Blade 1Blade 2 Blade 3Blade 4 Raspberry Interna l switch Optional switch Remote management site End user backbone and offices 1Gb/s 10Gb/s or 1Gb/s copper

6. Short distance use case Can we assume that if long distance strategy works short distance might be relevant too ?

7. VLAN strategy We assume that the boards used doesn’t have a mandatory IPMI interface and that Administration tasks are “special” tasks performed into a distinct operating mode than production. 2 VLAN – 1 Admin Address allocated through DHCP request or static mode – Initial configuration performed through DHCP – If remote technician deployment, setup can be performed locally with a pre-configured laptop running a DHCP server and associated cable Remote management board port as well as Blade boards ports are in the same admin VLAN at initial setup Remote management board moves Blades boards from Admin VLAN to Production VLAN through ReST call PXE is available only on the Admin network and from the Remote Management card – => everything to deploy O/S must be distributed through this network – Remote management board discover Mac Address and provide PXE only to the local Mac Address

8. VLAN strategy (2) Production – Production is a routable network with public access and no firewall – Production is accessible only through the node when they have reached the “INSTALL” status Switch ports – At a time a switch port can be configured into a single VLAN. No port trunking is allowed

9. VLAN strategy constraints Internal switch has to be reconfigurable through the management board as to switch ports from Administration VLAN to Production VLAN Switch firmware has to be “rock-solid” as if it is hacked, access to the admin network could be performed except if MAC address filtering is performed at the backbone side. A CLI or ReSTful API is needed on the switch side

10. Remote console and Management GUI Blade boards can be accessed through a local Webserver running on the admin board The GUI provides full access to remote console through serial connection to each board or through IPMI remote console (need to be configured board per board through the GUI)

11. Case of boards with integrated IPMI We do not use the feature and it has to be disabled at firmware level if the remote console is still accessible after that operation Remote console has to be available through serial connection