|
|
During the 94-95 summer season, the station was still running one LAN. The current
mode of LAN growth seems to be ad hoc (we have never seen a plan). We understand
that subnets are being implemented in the Pomerantz Observatory this winter season.
Subnets are necessary to cut down on the large data traffic that will begin to occur as
AMANDA and CARA come on line and are beneficial in allowing a more manageable
network. This traffic should be local only, except in the cases of downloading to CONUS
or backing up to the central backup facility (presumably in the Science Bldg.).
While fiber should be FDDI capable, network protocols should remain normal ethernet,
and not be replaced by FDDI or ATM. The current protocols are adequate for science
needs for the near term. We see no need to spend resources on higher speed protocols at
this time.
2. Network Management
The subnet design makes the job of a single network manager more difficult. In the case
of many of the science groups, we recommend that a Distributed Manager Scenario be
adopted where local 'managers' are responsible for their own subnet, such as CARA or
AMANDA. ASA staff at the station would be responsible for maintaining the backbone
and routers up to where the researchers' computers plug into the wall. The ASA staff
should also be available for consulting and help, but the research staff should be
responsible for their own machines, backups, software upgrades, etc. Local managers
would also be responsible for configuring any domain name servers, as well as notifying
the ASA system manager of changes relevant to the main network or name server. With
proper communications to CONUS, non-resident managers may remotely login and
continue in a limited management role.
Requests by groups for a subnet address allocation which they configure and maintain,
and/or a physical subnet, separated by a router, should be honored. Conditions of
agreement should include a requirement of registering all domain addresses with the
system manager (for the name server, network diagnosis, and packet accounting), and
keeping the network wiring configuration diagram current. This would greatly reduce the
number of discussions and negotiations over network configurations, would allow large
continuing research projects to configure their workstations in the manner most suitable
for their research, and would off-load some of the responsibilities of the system manager.
3. Accounts
Install a finger server that is kept current.
Use the domain name for all accounts, so that rfl@spole.gov is sufficient to email to rfl.
Likewise, fingering a name @spole.gov should return adequate information to facilitate
contacting that person. At present, individual machine names have to be known to reach
a person at Pole, and it is not always possible to determine how to email to them without
fingering first. Example: how do you contact Dave Fischer at the pole by email
(assuming he were still there at this moment).
There may be a problem of keeping the database current with the transient population at
pole. Also local managers have to inform the system manager of changes. But even with
these few inaccuracies, the system could be better than it is now.
|
|