Cal Poly Pomona Intranet
Omega Implementation Plan

Intranet Services

The Cal Poly Pomona Intranet seeks to bring unified centrally-provided computing services to the entire Cal Poly Pomona community (on and off campus) through networking protocols that can be used on ordinary Windows and MacOS workstations... access-controlled file storage, access-controlled Web publishing, access-controlled Windows/MacOS/Unix file sharing, access-controlled file transfers, electronic mail handling, and a rich software development facility including complete Web, CGI and Java development environments. The Intranet introduces several innovative services to Cal Poly Pomona--central authentication, a community-wide Distributed File System (DFS) and a universal access control mechanism--and integrates them with existing protocols that are currently provided by numerous "islands" of service with disjoint authentication mechanisms, file systems and access controls. The Intranet is fully documented at

http://www.csupomona.edu/~intranet/.

Design Overview


The Cal Poly Pomona Intranet implements a three-tiered enterprise architecture in which centrally-managed Unix machines comprising the first and second tiers cooperate in providing integrated services to ordinary Windows and MacOS workstations comprising the third tier. Machines in the outer tiers act as clients (C) using services (S) provided by machines in the inner tiers. The variety and integration of services is illustrated in the protocol schematic above.

All of the services used by third tier machines have been used by parts of the community in the past, but they have been provided by scattered servers having distinct user bases and file systems, built independently and managed with high redundancy of effort, and serving relatively small groups of users. The services of the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE)--Security Service (Sec), Cell Directory Service (CDS), Distributed Time Service (DTS), and Distributed File System (DFS)--interoperate with existing services at the second tier. The unifying effect of DCE will significantly increase the availability and baseline uniformity of services while decreasing the overall effort required to provide them. This design squarely addresses the undesirable situation in which local technical support personnel spend more time maintaining servers than supporting or training clients. At the same time, the Intranet coexists with all existing locally-provided services and precludes none of them, so localities can migrate gradually to Intranet services.

Alpha and Beta Implementations

Initial Intranet research and planning began in November 1995. Based on the requirements analysis and recommendations presented to President Suzuki and the cabinet in March 1996, the Division of Academic Affairs authorized hiring a temporary system administrator and funded construction of an alpha prototype that would demonstrate working services on a small scale. The alpha platform (a single DEC 3000 implementing both the first and second tier of the architecture) was completed in August 1996 and demonstrated to Dr. Ed Hohmann, Interim Vice President for Academic Affairs, Dr. Don Bell, Associate Vice President for Academic Resources, Dr. Lev Gonick, Dean of Instructional Technology and Academic Computing (ITAC), and Hamid Etesamnia, Acting Director of the Computing Resource Center (CRC).

After the reorganization that created the Division of Instructional and Information Technology (I&IT), Dr. Ed Hohmann, Interim Vice President of I&IT hired a permanent system administrator and approved construction of a beta platform that would provide a rigorous test of services for at least 500 users through Fall 1997. The beta hardware and software components were completed in April 1997, and provided the primary computing platform for the Virtual Summer School '97 and the Faculty Center's Summer Web Institutes and Mentoring (SWIM) program. In August 1997, the Computer Science Department reconfigured its laboratory of 32 Sun SPARC 20 workstations to rely on Intranet services. The beta platform is currently supporting 1100 users during Fall 1997, and is comprised of the following machines:

Beta First Tier
IP Name bone steel diamond
Serves Tier 2 Tier 2 Tier 2
Location 98-B1-205 98-B1-205 98-B1-205
Model Sun Ultra I Sun Sparc 20 Sun Sparc 20
Processor 167 MHz UltraSPARC-I 50 MHz SuperSPARC-II 50 MHz SuperSPARC-II
Memory 128 MB RAM 128 MB RAM 128 MB RAM
Drive Storage 24 GB SCSI-2 8.5 GB SCSI-2 17 GB SCSI-2
Beta Second Tier
IP Name intranet cceast-itac ccwest-itac edtech *.sci
Serves Community Computing Commons East Computing Commons West Ed. Technology/
Faculty Center
Computer Science Lab
Location 98-B1-205 98-B1-205 98-B1-205 98-C4-26 8-52
Model Sun Ultra I Sun Ultra I Sun Ultra I Sun Ultra I 32 Sun Sparc 20s
Processor 143 MHz UltraSPARC-I 167 MHz UltraSPARC-I 167 MHz UltraSPARC-I 167 MHz UltraSPARC-I 50 MHz SuperSPARC-II
Memory 128 MB RAM 128 MB RAM 128 MB RAM 128 MB RAM 64 MB RAM
Drive Storage 2.1 GB SCSI-2 2.1 GB SCSI-2 2.1 GB SCSI-2 2.1 GB SCSI-2 2.5 GB SCSI-2

Omega Implementation

Omega First Tier

This plan describes hardware that should be acquired to scale up DCE/DFS first tier services from the beta platform currently being tested by over a thousand users to the omega platform designed to provide the same services to the entire community of at least 20,000 users. It will be necessary to replace the beta first tier machines with larger enterprise-class machines, since the first tier was intentionally built with less expensive workstation-class machines not sufficiently powerful to support the entire community. Eventually, each of the three machines in the beta first tier should be replaced with an enterprise-class machine having dual processors, 1 GB of RAM and 318 GB of RAID-5 storage. After full implementation, the Security Registry and the Distributed File System (DFS) will be managed by three powerful machines, and DFS will have almost a terabyte capacity:

Omega First Tier
IP Name bone steel diamond
Serves Tier 2 Tier 2 Tier 2
Location 98-B1-205 98-B1-205 98-B1-205
Model Sun Enterprise 3000 Sun Enterprise 3000 Sun Enterprise 3000
Processor 2 250 MHz UltraSPARC-I 2 250 MHz UltraSPARC-I 2 250 MHz UltraSPARC-I
Memory 1 GB RAM 1 GB RAM 1 GB RAM
Drive Storage 318 GB RAID-5 (35 x 9.1 GB) 318 GB RAID-5 (35 x 9.1 GB) 318 GB RAID-5 (35 x 9.1 GB)

Since the construction of a full first tier replacement and a terabyte DFS would cost about $500K, we are planning to build it in two phases each costing about $250K. Phase 1 will replace the two weakest first tier machines (steel and diamond) with enterprise-class machines having 1/2 of the desired RAM, 3/7 of the desired RAID-5 storage, and enough room to expand in phase 2. After phase 1, the Security Registry and Distributed File System (DFS) will be managed by one weak machine and two powerful machines, and DFS will have a 300 GB capacity:

Omega First Tier (phase 1)
IP Name bone steel diamond
Serves Tier 2 Tier 2 Tier 2
Location 98-B1-205 98-B1-205 98-B1-205
Model Sun Ultra I Sun Enterprise 3000 Sun Enterprise 3000
Processor 167 MHz UltraSPARC-I 2 250 MHz UltraSPARC-I 2 250 MHz UltraSPARC-I
Memory 128 MB RAM 512 MB RAM 512 MB RAM
Drive Storage 24 GB SCSI-2 136 GB RAID-5 (15 x 9.1 GB) 136 GB RAID-5 (15 x 9.1 GB)

The transition from the beta platform to the omega platform does not require any additional software acquisition or development; however, there will be increased license fees associated with running existing Transarc DCE/DFS server software on the larger enterprise-class machines specified in this plan.

Omega Second Tier

The beta second tier was built with machines of sufficient power to serve effectively in the omega second tier, so there is no immediate need for machine replacement in the second tier. It is recommended that we acquire four additional Sun Ultra I workstations (about $5K each), like those serving the Computing Commons, to serve laboratory and/or building subnets that place the heaviest load on Intranet services.

Hardware Maintenance

Currently, there are no hardware maintenance contracts on any of the Sun workstations comprising the Intranet beta platform beyond the standard one-year warranty on parts (that could require shipping machines back to the manufacturer). During the past year, we have replaced a defective monitor and power supply at no cost under warranty, but there was a delay of at least a few days in both cases. It is important that we have a hardware maintenance contract on the enterprise-class machines serving the production Intranet that guarantees quicker replacement. We do not need "platinum" round-the-clock replacement delivery, but it would be desirable to be able to replace hardware components and return the machine to full production service within 24 hours. This requirement would be met by Sun's "gold" hardware maintenance contract that provides replacement hardware components within 4 hours during the 8 a.m.-8 p.m. time frame.


Craig A. Rich -- carich@csupomona.edu