Sunday, December 30, 2012

Pi Lab - Physical Layout of a Pod

In the previous two posts I outlined an idea for a relatively low cost hardware environment for teaching system administration to high-school and early college level students.  In the first post I created a parts list for the parts of the lab.  In the second I create a manifest for each student's gear and for a working unit I called a Pod

Providing a Grounding for Remote Access



In thinking about the PiLab and what I would like to be able to do with it, I realized that I had made a mistake right at the start. I was focused on emphasizing the remote access non-graphical (non visual) aspect of system administration. I was aware still that I needed some visualization elements to give the students a means to see the effects of what they were doing. I was thinking about creating a set of monitors that work at multiple levels and which could be seen to change as the students turn their idle disjoint computers into a network of interacting services

I started thinking about how I'd lay out the lessons to introduce the systems to the students and then let them play and I realized I'd missed an opportunity with my focus on avoiding physical access.

What I realized is that, if I design the layout of the pod, the placement of devices and cable routing then I can design a session in which the students assemble their pod and can watch the monitors as each component is correctly placed, cabled and powered up. Then when the students begin work over the network they will have a visual reference to the components and connections with which they are working.


This week I've been working to make the idea a bit more concrete.  In this post I'm presenting a physical layout for a single pod. The pods are the units of student control.  Each pod will support 4 students.  Each student gets her own Raspberry Pi.  The pod provides power control and access to the console of each Pi.  It also provides power control and console access to the uplink router for the pod.

Physical Layout


The diagram below shows one possible physical layout for a pod.


The lab include 5 Raspberry Pi's.  The fifth unit is the Head Node.  This node is powered on when the pod has power.  It is the end point for the consoles for the 4 student Pi units and for the lab router. The head node also controls power to second power strip which powers the USB hub and the first three Pi units.

The pod is designed to be build on a plywood backing board approximately 42x56cm (17x22in).  All of the hardware except the Pi units have mounting holes on the back.  The Pi units can be affixed with velcro straps tacked to the board.  Additional velcro straps can be tacked along the cable runs to dress the cables.

Power Control


The PowerUSB Basic units have four sockets, but one is always on.  These will power the head node (from the first power strip) and the USB hub (from the second).  Two of the PowerUSB sockets are controlled by mechanical relays and can provide 4A.  The second power strip is plugged into one of these.  The router and the remaining 4 Pi units are plugged into the switched sockets.

In this configuration, every component except the head node can be powered by the head node itself.  The head node exposes its network port and console serial line which can in turn be used to control the pod as a whole.

Student Assembly


The Pi lab is designed to allow the students to assemble and cable the pod from components and cables.  They will get a chance to handle the parts.  The cables should be cut to length where possible and labeled.  Where the cable lengths are fixed, the pod back board should provide a means to dress the cables with slack loops.

While one of the goals of the course is to show the students how to work remotely using the network and command line, the exercise of assembling the pod and (hopefully) observing as it comes to life for the first time will give the students a sense of the hardware that is on the other end of the network.

Next: The management infrastructure


The next job is to design the infrastructure layer.  The goal there is to provide the next level network and host installation services for the lab Pi units.  It would be possible to add USB storage to the PiLab head node but I think it's preferable to provide the OS and monitoring from outside.  The monitoring must include both passive and active probes for the nodes.  It must provide near real-time graphical feedback of the Pod state to the students.  Back to work!

9 comments:

  1. What about two configurations for the pods: one with 2 - 3 raspberry pis and one with all five 5? The initial configuration can give the students a way to actually play around with the computers first. They can get a feel for the monitoring, for what services they can run and manage, etc. Everything is done for them, and life is great!

    All the while, they get a handle on some basic ops concepts. Ideas they use every day, like network connections, become a bit more concrete, theoretically. They can realize what next hops do. The same can be true for services/daemons and other such concepts. Once they have this idea down, you give them something they can'd do in the original limited layout.

    Now, they need to add the other raspberry pi nodes and can rebuild the entire pod themselves. Instead of following directions and reading about wires that transmit things they haven't quite gotten a handle on (outside of the rudimentary understanding users have about these things), they can have a notion that the extra raspberry pi will perform a specific function, and needs to be connected in this configuration otherwise the other machines can't communicate with it.

    Once this is done, perhaps you can make it so they might find they need to make their own monitoring system. I guess I'm proposing a "let's get them used to by giving them an inadequate . Then, they need to implement a solution to do what they want with ."

    On a different note, the method of education your proposing is like the lab component of science classes. Have you reached out to science teachers about how that system works? Not to steal their methods, but to gain insight about the psychology of the students going through it.

    We might make snap decisions about how people should work, but teachers actually see how students work. And, we can't succeed with any education initiative if we think in terms of "well, we can change them!" rather than "we need to work with what we have and make them succeed".

    If you don't have any teacher contacts, I have tons of them I could reach out to with any questions.

    Not sure if I should cross post this to the mailing list :/

    ReplyDelete
    Replies
    1. Ed: Thanks for replying!

      Feel free to cross-post if you haven't seen something from me directly. Let me know where and I'll add it to my flooding list :-)

      The pi units themselves will belong to the students at the end. The initial configuration for teaching is up to the instructor.

      I haven't yet had any contact with real teachers and I have only the vaguest notions of how to teach with this (other than to make it cheap, flexible and completely remotely accessible.

      For total beginners I think I'd start with the pods configured and running. I'd give the students some CLI learning exercises first and some instructions that would make visible changes to the monitoring map. After a few sessions then I'd get down to a hands-on session examining the components and then re-assembling them.

      For some classes they might just be fully assembled and prepared for a set of investigations.

      In previous posts I noted that the teaching model I have in mind is something like that in Allen Downey's "Think *" books, especially "Think Python". Check the References section on the previous posts.

      My only purpose with this really is to try something I haven't seen tried yet. If someone finds it useful or inspiring, great. If not... we'll try something else.

      Delete
  2. Ah, that makes sense. I read your other posts. It just sounded like you wanted everyone ti start off building the pod, which didn't seem like a good idea for complete beginners :) Glad that's not your plan.

    I really think this is a great idea. It's a nice way to get around security issues of giving students access to live systems and the expense of redundant, non-networked systems.

    ReplyDelete
    Replies
    1. Yep, the other posts give the context. The "Pod" is just the construction unit of the lab. 4 pis are expendable (student gear, paid for by dues), the remainder are reusable. The pod idea gives a small shared lab unit which can be replicated for multiple groups. I still have to design the next layer up and the software to control is up in the air. You have ideas? :-) As far as how to teach with it, well that's an experiment too.

      Delete
    2. Nothing terribly useful. I'm afraid I'm not familiar with how the pis come outside the box. However, the higher level monitoring tool needs to be as modular as the physical layer. It has to manage many of the scenarios a teacher would want to mess with as possible.

      To that end, a configuration manager could push out the initial configuration to all of the pods. How this works depends on what the pis look like out of the box. You could have a central classroom server (even a normal desktop) that replicates the necessary files to configure the pods to external storage. Then, the head node boots off of this data store (or reads file from it, if the nodes come pre-installed with an OS) and automatically configures the other units in as many reboots as necessary.

      Essentially, there are two configuration servers: a master configuration controlled by the teacher in a central location and a localized configuration manager (or an agent of some kind) that handles the individual pods through the head node. This gives the pods mobility. Once the initial seed is sown, a pod can be taken off the class network, configure itself, run as the instructor intends and collect whatever data it needs to.

      The initial teacher push could be as complex as an entire linux install, with all the apps and monitoring tools a beginner could ever hope to have . . . To nothing more than a linux image students need to install on each machine and a configuration file.

      The configuration file wouldn't just be used to set up useful things for the student. Rather, it can set up whatever monitoring the instructor needs to gather information used to assess a group's pod. And maybe even push out issues the group of students needs to troubleshoot and fix. The agent would merely need to be configured to wait until certain services are installed (ex: when the agent detects apache is available, implement monitor x).

      Ideally, a tool should sit on top of the teacher's configuration manager. This tool should make setting up a configuration (and thus lesson) extremely quick and easy for the teacher. But that would be a level or two higher than your current issue.

      I haven't used a configuration manager yet, but I've been looking into implementing one on our network. We hope to start with CFEngine, then play around with Chef or puppet. But, all of this seems relatively easy to set up.

      I'd love to help put together whatever software solution you think is appropriate.

      Delete
  3. The pis actually boots in an interesting way. The boot loader is in the GPU. It reads an image from a fixed file name in the first filesystem on the SD card and loads that. If that is a proper ARM binary image, it runs.

    I had found a good power on boot process description but I didn't save the link and I have to find it again now.

    Most current distros (Raspian, Arch, Android) place a kernel there. There's one person I've found who's implemented Uboot with USB and NIC initialization. I haven't tried it yet, but if it works that will give me total remote control of the boot process using DHCP/PXE. Any real OS will be installed in a second partition and PXE can instruct uboot to load from there.

    My next post will detail the infrastructure hardware I mean to use. After that I can look at what probe and control points exist and what I can do to collect and then present the data.

    I expect to use at least one CMS, though I haven't decided what. I'm also hoping to use Nagios or some other monitoring system as well as MRTG and simpler things like arpwatch and the logs from dhcpd, bind and ldap services.

    Some of it may have to be massaged to make it palatable and informative to beginners. We'll see.

    Thanks!

    - Mark

    ReplyDelete
  4. I'd love to read the link, if you find it.

    Nagios may need more than a little massaging ;).

    After reading through all this, I'm very tempted to pick up a raspberry pi

    ReplyDelete
  5. Whether you get a Pi or a VIA APC or a Cotton Candy or MK802, they're all relatively inexpensive little computers. The Pi has what may be the most active development community.

    Be aware that while the list price of a Pi is $35US, it will probably run you closer to $85 to create a complete system (though you may have some parts lying around.) Some of the others may be more cost effective. I have about 5 different ones to try :-)

    https://www.linux.com/learn/tutorials/582501-tiny-pluggable-linux-arm-computers-are-red-hot

    ReplyDelete
  6. The software development company helps the business in getting their required programming matching with business requirements

    ReplyDelete