|
|
Issue 15 |
December 2003 |
Andy Kowalski (kowalski@jlab.org,
x6240)
The core network for the site is being
upgraded during the December shutdown.
This upgrade requires network outages on December 27, 28, 29, and
30. The upgrade is being done during the
shutdown to limit its impact on the daily operation of the lab. Services such as email, internet access, web
server access, Domain Name Service (DNS), Network Information Service (NIS),
calendar, and other
The working plan is to completely shut down
the network on the 27th to perform hardware upgrades, replacements, and
installations. The outages on the 28th,
29th, and 30th will be intermittent as configurations are changed to make use
of the new features and capabilities the hardware provides. These intermittent outages will be random and
could last for hours at a time. Although
the outages on the 28th, 29th, and 30th will be intermittent, there should be
no expectation of service or network availability.
Accelerator networks located within the fence
will remain operational during this upgrade but will not be externally accessible;
either from the internet or RAS (dial-in) connections.
The new features and capabilities provided by
the network upgrade will enable us to keep up with the increasing demands being
placed on the network. These demands are
in the areas of security, functionality, flexibility, and manageability. One new feature that will be of importance to
many groups at JLab is the deployment of VLAN (Virtual Local Area Network)
support. A VLAN is a logical grouping of
systems that appear to be on the same physical LAN segment. In reality, the systems are located on
different physical segments. This will
allow, for example, one of our current subnets (Business Services) to be
deployed as a VLAN such that select systems across the site (
One area of new growth requiring the use of VLANs has been in the monitoring of heating and air conditioning units by facilities management. This upgrade will allow us to build a private network across the site where only the facilities management systems are included. In the past, dedicated fiber and cables were used to build a private physical network. With VLANs, this can be done logically using existing fiber, cables, and in some cases, network equipment. The sharing of physical components to build VLANs will provide us greater flexibility while saving us time and money.
Marty Wise (wise@jlab.org,
x7214)
A few months ago, the 
the
site network.
For most users, their systems will support
installation of Windows XP without any problem. Most systems, hardware
components, etc. that are in common use at the lab are supported by Windows XP.
A few exceptions exist for hardware whose manufacturer has gone out of
business. In some of these cases, drivers for XP (or anything else) are not
available. In a few cases select hardware may need to be replaced to maintain
compatibility. Fortunately, Microsoft provides information on its web site
about this issue, and even a tool that you can download and run to determine if
your system is supported. More information is available on the
The
Many users continue to store documents, data,
etc. on their local system disks. Since your local disk will be completely
overwritten by the rebuild process, before you rebuild, you’ll need to insure
that you have all of your data stored in a safe location. Rebuilding your system
provides a great opportunity to reorganize where you store your working data to
take advantage of our central file servers. See the “Building or Rebuilding
Windows Systems at JLab” article in this newsletter about this topic for more
information on how to prepare your system for a rebuild.
While upgrading from NT4.0 to a newer version
of Windows will certainly take planning and a bit of care, the many benefits of
these newer systems is well worth the trouble. And, if that’s not a good enough
reason, the fact that NT will effectively be unsuitable for use on the network
within a few months should provide ample reason to pursue the upgrade.
David Bianco (bianco@jlab.org,
x5268) 
As you may have heard, RedHat has announced
that they are dropping support for their free Linux product, RedHat Linux,
preferring, instead, to concentrate on corporate customers (with a targeted
RedHat Enterprise Linux product). RedHat
has announced the end-of-life of all RedHat distributions up to and including
version 9. RedHat will cease support for version 9 on
One option would be to change to an entirely
new Linux distribution. This would mean,
however, tearing down and rebuilding our entire Linux infrastructure from
scratch. As we gave a strong preference to solutions based on current RedHat
technology, the two leading contenders were RedHat Enterprise Linux and the
community-supported Fedora project.
We first considered the community supported
Fedora Linux project. Sponsored (but not supported) by RedHat, this project can
most simply be described as a continuation of the RedHat Linux
Since Fedora Linux was not deemed a viable
solution, we evaluated RedHat Enterprise Linux next. Based on RedHat 8.0 (with improvements from
version 9), this is a stable platform upon which to build a computing
infrastructure that would enjoy vendor support for a minimum of 5 years. It supports most of the newer hardware and
software available, and can be integrated with RedHat's system management
solution, similar to SUS and SMS which we already use for the Windows side of
the house. Technically speaking, this is
a very attractive option, but it is also the most expensive. However, since most of the other High Energy
Physics Labs are facing the same issue, the Department of Energy has been in
negotiations with RedHat for more favorable licensing costs. This cost would need to be spread among the
various divisions at the lab each year.
Ultimately, the DOE negotiations with RedHat
resulted in a price for RedHat Enterprise Linux Workstation at an attractive,
and workable, cost. We have recently
purchased enough desktop licenses to support our current number of Linux desktops
(about 500), and will be developing a level 1/2 desktop build based on it. This build will be available by mid-December
and we encourage anyone running a version of RedHat less than 9 to upgrade to RHEL
3 as soon as possible. People running
RedHat 9 should also upgrade to the
The
Paul Letta (letta@jlab.org,
x5106)
On the October maintenance day, several of
the general purpose Unix login systems were upgraded to new hardware. Both
jlabs1 and jlabs2 were Sun E450 servers with four 250MHz cpus and 2GB of RAM. They
are now Sun E280R servers with dual Ultra III Sparc CPUs that run at 1.2GHz and
have 4GB of RAM.
Andy Kowalski (Kowalski@jlab.org,
x6224)
SILOA total of fifteen 9940B tape drives are now
installed in the SILO. The last five 9940B tape drives went into production
during October. All writes to the tape SILO are being made to 9940B tape
drives. The six 9840 and fifteen 9940A tape drives are being used as read only
devices. The 9940B tape drives have a
capacity of 200GB per tape and a transfer rate of 30MB/sec. This represents a
233% gain in capacity and a 200% gain in transfer rate when compared to the 9940A
tape drives. The table below lists the type and quantity of drives we currently
have in production and how they are being used.
|
Type |
Quantity
|
Capacity
|
I/O
Rate |
Use |
|
9840 |
6 |
20 GBytes |
10 Mbytes/sec |
Read Only |
|
9940A |
15 |
60 GBytes |
10 Mbytes/sec |
Read Only |
|
9940B |
15 |
200 GBytes |
30 Mbytes/sec |
Read and Write |
The following table shows the usage of the
tape SILO over the past 8 months minus any data migration activity.
|
Month,
Year |
Terabytes
|
Files
Requested |
Failures |
Percent
Success |
|
March, 2003 |
91.40 |
161,374 |
8,653 |
94.64 |
|
April, 2003 |
93.02 |
185,071 |
21,261 |
88.51 |
|
May, 2003 |
59.01 |
104,915 |
7,390 |
92.95 |
|
June, 2003 |
98.38 |
334,312 |
24,352 |
92.72 |
|
July, 2003 |
131.79 |
199,705 |
21,551 |
89.21 |
|
August, 2003 |
73.91 |
161,881 |
13,246 |
91.82 |
|
September, 2003 |
59.40 |
97,689 |
9,485 |
90.29 |
|
October, 2003 |
65.549 |
102,471 |
3,475 |
96.61 |
The majority of failures result from either
the clients (jput and jget) not being active to receive the data files and
cache servers failing during data file transfer. In the case of clients not being active, they
usually have been killed by the user (Ctrl-c).
In the case of failed cache servers, these are failures for files being
transferred from the data mover to the cache server at the time of the cache
server failure.
The last of the tower-cased systems have been
decommissioned from the farm. They were
dual Intel Pentium III 500MHz systems.
They have been replaced by 24 dual Intel P4 Xeon 2.6GHz systems. These new systems have 1GB of RAM and 120GB
of disk space for user jobs. The
Hyper-Threading feature of the P4 Xeon processor make the systems appear as
quad processor systems. These systems
run 6 simulations jobs instead of the traditional 3. As currently configured,
this increase results in the farm now having up to 738 running job slots. Limits and restrictions do, however, prevent a
single user from using all the available job slots.
Ifarml1 was replaced with a quad Intel P4
Xeon 1.4GHz system similar to ifarml3.
The ifarm now consists of 3 quad processor Linux systems and 2 dual
processor Sun 280Rs. With
Hyper-Threading, the Linux systems appear to be 8 processor systems to the
operating system.
Michael Haddox-Schatz (mschatz@jlab.org,
x5803)
The
David Bianco (Bianco@jlab.org,
x5268)
As you may have noticed, the Lab's default
web browser and email client are getting a bit long in the tooth. In the past,
we've settled on using Netscape as our standard for both browsing and email,
but we are now revisiting this choice. While Windows and Linux users are able
to take advantage of the newer versions of Netscape Communicator, our Solaris
and HP-UX users are left out in the cold. In the interests of making the same
features available to all our users and reducing support costs, the 
changing
the standard supported browser/email client recommendations from Netscape to
Mozilla 1.5.
“What the heck is 'Mozilla'?” you may be
asking yourself. You might not think you're familiar with it, but you probably
know more about it than you think. Mozilla is an Open Source project that
provides a full suite of Internet utilities, including a web browser, email
client, HTML editor and IRC chat client. If this sounds familiar, it should: Netscape
has been based on Mozilla technology since version 6! Netscape Communicator and
Mozilla offer many of the same features in an interface that is very similar to
what you probably already use.
That's not to say that there are no
differences. First, unlike Netscape, the latest versions of Mozilla are
available on all our computing platforms, including HP-UX and Solaris. Mozilla
also offers many new features that Netscape does not. For example, the browser
features integrated blocking that can end those annoying pop-up window ads forever.
On the email side, Mozilla has a built-in spam filter that learns the
difference between legitimate messages and junk mail. After a short initial
training period, you can configure it to automatically route junk email to a
special folder where it can be held for manual review or automatically deleted
after a few days. For those of us who get a lot of spam, this feature alone
could make it worth checking out Mozilla.
Mozilla is now available for all JLab CUE
machines. Under Unix, simply type “mozilla” launch and use to the software to
launch it. Under Windows, you can install Mozilla by pointing at
“Start->Programs->JLab CUE->User Installable Programs->Mozilla
1.5”. On either platform, it will detect the presence of your Netscape
configuration profile (only if you have used Netscape 6.0 or higher) and offer
to import your web and email settings automatically. Configuration details and
information for the Mozilla email client can be found in the
Marty Wise (wise@jlab.org,
x7214)
Everyone who is currently running Windows NT
4.0 will soon need to upgrade their systems to a newer version of Windows. In
general, there is very little reason to choose Windows 2000 over Windows XP, so
most people will be upgrading to Windows XP.
By now, I’m sure all of us have a collection
of horror stories of the problems we have encountered in the past while
tackling this process. I can’t even count how many times I have forgotten to
back up my address book prior to rebuilding, only to discover after the fact
that my system no longer knows who “sweetie” is. And if remembering to take
care of all of my data wasn’t enough to worry about, I also had to make sure
that the system itself was installed, configured, patched, etc. correctly. The
Additionally the
In the past, the process of installing
Windows, getting it patched, installing MS Office, common applications, etc.
has been very time consuming. It has also provided numerous opportunities to
introduce configuration errors either through misunderstanding or simple
mistakes. Speaking from experience – a simple typo in the wrong form field
during setup can turn an otherwise perfectly good system into an incoherent
mass of electronic parts. The new system is designed to allow users to rebuild
an existing system with a minimum of trouble.
Once rebuilt, the system will conform to the Windows Workstation
Configuration defined by the
For the most part, systems built at the lab
conform to a fairly simple basic configuration. Most users need Windows to be
correctly configured and they need access to a fairly small set of common
tools. A standard basic configuration for desktop systems has been developed. A
description of this configuration is available online at http://cc.jlab.org/docs/services/windows/WorkstationConfig.pdf.
The
Overall, the new build process is intended to
provide a stable, reliable windows desktop platform that is well integrated
into our environment. For users, this means a system that does what you want,
when you want, without a lot of hassles.
Microsoft has announced that security patches
for Windows NT4.0 will no longer be available after
|
Platform |
OS Revision |
Notes |
|
Sun |
Solaris 2.6 |
Support Ended |
|
|
Solaris 7 |
Not supported |
|
|
Solaris 8 |
Supported, default for new systems |
|
|
Solaris 9 |
Not supported |
|
HP |
HP-UX 10.20 |
Support Ended (except special cases) |
|
|
HP-UX 11.11 |
Supported, default for new systems |
|
Linux |
RedHat 6.2 |
Support Ended |
|
|
RedHat 7.2 |
Currently Supported, Default for new
systems |
|
|
RedHat 7.3 |
Not Supported |
|
|
RHEL 3 |
Support Beginning Mid-December 2003 |
|
Windows |
3.x, 95, 98 |
Not supported. Microsoft Security Fixes
ending |
|
|
ME |
Not supported. Microsoft Security Fixes
ending |
|
|
NT 4.0 |
Currently Supported, support ending |
|
|
2000 Pro |
Currently Supported |
|
|
XP Home |
Not Supported on site |
|
|
XP Pro |
Currently Supported, recommended for new
purchases |
The
Networks
Michael Memory (memory@jlab.org,
x6240)
As the