[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] LTSP Lab Slow to Boot

See inline.  :-)

Todd O'Bryan wrote:

    To help answer this, I'll need a little more info.  If I
    understand you
    correctly, the "192.168..." NICs on both of your LTSP servers (you
    specify this, so I'm by necessity making an assumption here) are
    your "eth0"
    interfaces for talking to your thin clients.

You're correct. They're not actually eth0 (we were having driver issues with the onboard eth0 NIC, so they're eth2, I think), but they're the interface that talks to all the thin clients.

Interesting...what kind of onboard NICs are these? And what kind of server motherboard nowadays includes non-Linux-friendly NIC's? I'd like to know, so I can avoid them like the plague.

    Furthermore, both of these eth0 interfaces are now on the 8-port
    Gig-E switch.
    Additionally, you have this newly acquired, SCSI-disk-equipped
    file server
    that is on this same Gig-E switch, and all of this constitutes a
    broadcast domain which houses only the 192.168.x.x subnet.

    BTW, which specific 192.168.x.x subnet are you using--is it <>, <>,
    <>, etc?  I don't see that specified.  And what is
    the subnet mask?

I'm in room 202, so my local network is <> = server1 (application server) <> = server2 (application server) <> = server3 (file server with /home which is NFS mounted to server1 and server2) <> - 130 = the thirty thin clients (assigned by MAC address so I know the IP of each client)

I'm not sure what the subnet mask is set to (and I actually don't know what it's used for, so guidance would be appreciated if there a particular setting that would be useful). I think it's <>, but I'd have to check to be sure.

server1 and server2 also have separate NICs that plug into the school network, get an IP using DHCP and are what we use to access the wider internet.

So, all this means that you have both LTSP servers with their thin-client-facing interfaces (eth2, in this case) on the same broadcast domain. I guess that's why you're doing DHCP reservations (assigning by MAC address), so you can manually load-balance the clients across the two LTSP servers. If that's what you're doing, then it's higher-maintenance than another method involving VLANs, but it certainly would work.

I take it that you don't want "server3", the file server, accessible from the main school LAN. If so, then you did it right.

Most people use (or "/24" in CIDR notation). In your case, since you don't need to handle gobs of nodes on this subnet, that's certainly sufficient. For the anally retentive, yes, a smaller one (a /25, or would also work here, but unless you know why you need to do that, you *don't* need to do that.

    Finally, you have this 8-port Gig-E switch uplinked to a Gig-E
    port on the two
    switches in the lab (another, separate room).

    Is all of this correct, or am I misunderstanding something here.

Correct. Actually, servers 1, 2, and 3 are in a storage closet in my room so they can be behind a locked door and the thin clients are in the room proper. The 8-port gig switch is in the closet with the servers and the 2 24-port switches with 2 gig ports each are in the room.

I don't predict that you should have any problems related to network design. Since all the servers's Gig-E ports are on the same Gig-E switch, the backplane will make traffic between them quite fast, assuming that your 8-port switch has a decent backplane (all quality ones do). Fifteen thin clients will be coming into the 8-port switch via one Gig-E interface (the downlink to one 24-port classroom switch), and the other fifteen will be coming in via another Gig-E interface. The backplane of the 8-port "core" switch will most certainly be big enough to bridge such traffic to the correct switch port (the ones for server1 and server2, that is).

So, it sounds like you have a good setup here.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]