[K12OSN] network design
Sharon Betts
sbetts at msad71.net
Sat Feb 5 22:20:29 UTC 2005
"Support list for opensource software in schools." <k12osn at redhat.com> on
Saturday, February 05, 2005 at 1:10 PM +0000 wrote:
Thanks for the input so far -- I will try to elaborate:
>
>>What specific services do you need to provide? (general computing,
>roaming
>>profiles, roaming profiles across buildings, email, printing, web, shared
>>folders, library, database access, etc)
I need to provide general computing, roaming profiles within each LAN,
printing, web, etc.
These are all within LANS. OTher services (SIS etc.) are via web.
>
>>What kind of connection do you have between sites?
T1s
>
>>Will these all be thin clients, or will this be a mixed mode install
>(thin,
>>thick, windows, mac)
Mixed
>
>>What kind of policies are in place that may effect this?
None
>>In an ideal world, with big fat pipes that never go down to each
>location, I
>>would say that you would want an LDAP server, a home server, backup
>server,
>>web server, email server, web filter/proxy and central print server in
>the
>>central office (or other suitable location), connected via WAN to the
>other
>>locations. You then have K12LTSP servers at each location to boot
>clients,
>>and provide most applications. You might want a number of application
>>servers for OO.o, Moz, programming, and what ever other high demand apps
>you
>>have at each location, plus a Windows TS for what ever win apps you have
>to
>>have.
How easy is it to combine the Windows TS?
>
>
>I would add this: at least one slave LDAP server at each physical
>location. The reason for this is our own experience with the Windows
>Craptive Directory in our district. We now have collapsed our domain
>structure so that everyone authenticates to our pair of domain
>controllers at one facility.
This is something we have considered.But had the fears you wrote about
below.
> Therefore, folks are authenticating across
>the WAN, so when the WAN link goes down, nobody can authenticate.
>Cached credentials on the Windows workstations don't fix all the
>problems, either. This was back in the Windows NT Server 4.0 days as
>well and applies to any centralized authentication scheme. Sadly, WAN
>links do not respond well to, say, backhoes ripping the line to shreds,
>problems at your provider's end, your router either going Tango Uniform
>or getting misconfigured, etc. They can and at times do go down, so
>this should, whenever possible, be accounted for.
>
>LDAP authentication, being a centralized authentication scheme, operates
>the same way. If you have a slave LDAP server at each physical site,
>then people can still log in and, for example, hit the file server, fire
>up certain network apps local to the school, etc.
Maybe this is a start to our solution.
>
>On the LAN side, you'll want fiber runs between all of your wiring
>closets, and you'll want that fiber backbone to be running nothing less
>than Gigabit Ethernet. All client drops should be 100Mbps, capable of
>autonegotiating to 100M/FullDuplex. Pretty much everything made today
>and for at least the last five years is capable of this, so that won't
>be a issue. There are some new switches coming out whose client drops
>do 10/100/1000, which, while not necessary for client drops, doesn't
>hurt anything to have if the pricing is close enough to 10/100.
We are nearing this level -- still have one school pretty "old".
>
>I would also suggest switches that are capable of both 802.1q VLANs and
>GVRP. GVRP is a very, very nice thing to have unless you're using Cisco
>gear, which uses a proprietary version that they call VTP. We use VLANs
>for quite a few things in our district, and without something like GVRP
>or VTP, setting up all the VLAN info in all of our switches would simply
>be untenable. Make sure, therefore, that you get *full* GVRP support.
Yep.
>
>You might consider going with TLS for your WAN links. Essentially, this
>is Ethernet across the WAN. We're using TLS in some parts of our
>network, and WAN bandwidth for TLS is about half to a third the price
>of, say, ATM links of the same speed. You can go as high as Gigabit
>links with TLS. Furthermore, if you go with TLS, you have a wider
>choice of router gear than just Cisco. You can use, say, an inexpensive
>OpenBSD or GNU/Linux box with two Ethernet cards for your router
>(doesn't have to be x86, but of course it can be). Either way, the
>boxes are cheap, and the Ethernet interfaces are cheap. By contrast, if
>you go with ATM or Frame Relay, you're going to pay through the nose for
>your WAN interface cards. We run ATM in my district, so I know. I
>strongly urge you to at least look at TLS.
>Speaking of WAN links and capacity, do *NOT* attempt to run LTSP itself
>across your WAN links! You *will* be sorry. What I mean here is,
>"don't fire up clients at one site trying to do X11 to a LTSP server at
>another site." Keep all that inside the school's LAN. Accessing file,
>print, or Web servers across WAN links? Fine. X11 across them? Nope.
This we knew.
This is great - thanks. Any other suggestions?
Sharon
More information about the K12OSN
mailing list