|
Large Scale System Administration of Windows NT Workshop, 1997
   
[Technical Program]
Implementing Large NT Networks in a Heterogeneous Computing Environment at SLACAndrea Chan, Freddie Chow, Jonathan Wong Stanford Linear Accelerator Center, Stanford, CA* Abstract* Similar to most research labs, Stanford Linear Accelerator Center (SLAC) has multiple computing platforms. But in the recent two years, there has been a tremendous growth of Windows NT at SLAC. We have encouraged this due to the popularity and availability of Windows-based software, and to the fact that Windows NT has system management tools. In this paper, we describe implementing a new support infrastructure and the use of Microsoft Systems Management Server (SMS)both needed to migrate the lab quickly from the chaotic characteristics of desktop computing to a more centrally-managed NT network. We also describe the use of NTrigue servers for UNIX and Macintosh users to access Windows-based software in this heterogeneous environment. Our Environment and Challenge SLAC has approximately 450 Windows NT, 200 Windows 3.x, 700 Macintoshes, 700 UNIX workstations and X Terminals, and 200 VMS workstations. Similar to other research labs we have to support multiple platforms. We need to support specialized and demanding computing that was previously done on mainframe computers. Within the last two and a half years, the number of machines running Windows NT have grown from zero to 450. The main driving force behind this is our business services softwarePeopleSoftwhich runs on Windows NT. Our Windows NT platform also supports four to five Computer Aided Design (CAD) programs, some needing 3-D rendering. Although the main physics computational processing is done using UNIX servers, physicists are also migrating to Windows NT for their desktop computing. So Windows NT is currently one of the main computing anchors at SLAC, carrying out several mission critical functions. However, we have limited resources in budget and manpower to support these demanding requirements. Budgets, decisions and desktop computing support are done at the departmental level and little is centralized. This situationdemanding requirements, scarce resources, heterogeneous environmentis similar to that found at many large institutions. Below we list some changes forced on desktop computer support by the large scale implementation of NT, and some measures we took to prepare to transition to the future. Former Desktop Computer Support Model and Changes Needed for NT SLACs past model of Desktop Computer Support was having a few people at the Computer Center doing central support, and a network of casual desktop computer support done by people in their local departments whose formal jobs were other than desktop computer support. This model corresponded to a situation where the bulk of computing was done on central computers (VM, UNIX, VMS, etc.) while the role of desktop computers was secondary. This is no longer true today. With the bulk of the staff using desktop computers, and mission critical functions on this platform, longer downtime due to an inadequate level of support has a big impact on productivity. Every department where a significant number of users have made the transition to Windows NT has done it with at least one full-time desktop computer support person. There are several reasons why the existing model of casual desktop computer support will not be sufficient for Windows NT computers. The key issues are: Windows NT machines are far more reliant on the servers and the network, and can also more adversely affect the servers and the network proper usage of userids/passwords and security issues become more important. The same powerful features that make Windows NT machines useful for the future also make them affect the entire SLAC community if misused. Security and networking functions are in jeopardy if Windows NT machines are not properly installed and configured. Clearly, the person doing system administration for Windows NT, or a mixed desktop environment that includes Windows NT machines will have to: be better trained, and have continual training to keep up with new hardware/software be coordinated with the central desktop support team and be responsible to following guidance on security and domain policies from initial installation to maintenance and troubleshooting devote a significant amount of his/her time to helping users install new machines, servicing the computers, and planning and performing upgrades. Formalize the Supportthe Emerging Desktop Computer Support Model We are currently implementing a more effective model of Desktop Computer Support. Besides a small team (4 people) doing support of central servers and central services, we also coordinate the network of computer support personnel doing client workstation support (these are the department system administrators). We need department system administrators who have a solid foundation in hardware and who can easily adapt to the changing technology. In this job market, where there are few NT-knowledgeable personnel for hire, we develop our own training material to be able to recruit inexperienced people and bring them quickly up to speed. Department system administrators are oriented to only one or two departments to provide: good response time for service customized servicesomeone who is familiar with the local setup and the users needs in particular departments will be able to troubleshoot their systems faster and build on his/her knowledge. This customized service for each department has proved satisfying for users and has given recognition and job satisfaction to the department system administrators. This person identifies with the needs and priorities of the department(s), and represents them in interactions with the central support team. Programs for buying software and hardware at attractive bulk discount prices have been launched to benefit departments that go through their department system administrators for these purchases. This approach eases the burden on the department system administrators, and permits centralizing purchases in software and hardware that will evolve to more standardized configurations ultimately needed by the central management of the NT network. Evaluation and Implementation of NT Central Management Software We evaluated two centrally managed Windows NT network models that would best fit into the SLAC environment: 1) Microsoft Systems Management Server (SMS) 2) NICE/NT that is developed by and currently used at CERN (European Laboratory for Particle Physics). While exploring our options, we found the following comparisons of the two models to be note-worthy: commercially available off-the-shelf application vs. home developed Windows NT only environment vs. mixed with Novell NetWare. The SMS based model requires Microsoft SQL server as a part of the implementation. SMS supports the three critical capabilities that are most needed in a Windows NT network of our size: 1) electronic software distributions 2) automatic software and hardware inventory 3) remote trouble-shooting. With SMS software distribution, a software package can be set up to be installed mandatorily or a time interval can be specified before it becomes mandatory. The SMS Help Desk function provides the capability to quickly look at a reported problem on the user's display from the central support personnels workstation display (which saves support personnel a trip to the user workstation). In the long run it saves manpower and increases user satisfaction because of the capability of addressing problems rapidly. The strong point for the SMS based model is that it is a commercially available product from the same company that creates Windows NT. It can be implemented using the Windows NT domain structure in a network running TCP/IP protocol, which is what SLAC utilizes today. CERNs NICE/NT model requires the use of customized programs developed by CERN. It currently runs on Novell NetWare 4.10 servers and NDS (Novell Directory Services). Windows NT workstations are run as clients to NetWare servers. IPX/SPX protocol is required on the network in the current configuration CERN is running. In the current CERN configuration, the pull method is used for software distribution. Software and hardware inventory are done to some extent, but the remote control of clients is not used (although it is possible to implement this, as some commercially available software packages are available on the NetWare platform). Implementation of CERN model would likely require some code modifications to fit in the SLAC environment. For future Windows NT versions, the source code is available for such modifications. The strong point for the CERN model is that it can be implemented in a short time with help from CERN. CERN plans to develop the means to implement NICE/NT using the Windows NT domains structure without relying upon Novells NetWare and NDS. In addition to our own discussions, we had several discussions with the support teams from CERN and other institutions. After these discussions, we decided to use SMS because it is a commercially available off-the-shelf product, and recent trade publications have given good reviews of the current version of SMS. In addition to our own evaluation of SMS, we discussed with other SMS users their experiences. Some of our counterparts at Argonne National Lab, Illinois who have been using SMS for several years shared their experience with us, and they rated SMS highly. Automatic software distribution will save considerable manpower in the lab from doing the repetitious work of physically visiting and installing or upgrading software on each workstation. Currently SLAC is in the testing stage for SMS. SMS version 1.2 (with Service Pack 2) has been installed on a 200 MHz Intel Pentium Pro server with 128 MB of RAM running Windows NT 4.0 Server (with Service Pack 3). This is the SMS site server for the central site. The Microsoft SQL Server installed on the same server has version 6.5 (with Service Pack 3). When we go into production mode, we plan to add a second processor, an additional 128 MB of RAM and more disk capacity on the server. SMS client software needs to be installed in each workstation, which is to be configured in a SMS domain. Each SMS client requires a SMS client license. The installation of SMS client software can be done by adding a batch file, which invokes the client installation program, to the logon script or manually. When included in the logon script, the client software is installed when the user logs on. After the client software is installed on a client, appropriate check boxes of the Remote Viewer Options and Local Options in the Help Desk Option screen are required to be checked for the SMS Help Desk function to work. In our tests the three main functions of SMSelectronic software distribution, help desk and software/hardware inventorywork as desired. SMS has been successfully implemented in a small scale to upgrade workstations with Windows NT 3.51 to Windows NT 4.0, as well as distribution of software packages to these workstations. A careful planning of the SMS site server and distribution servers to run SMS successfully includes having enough processing power, RAM, and enough disk space based on each software application to be distributed using SMS. In the current desktop environment at SLAC, each workstation has its own setup and all the applications are installed on the local hard disk. The user profiles are also stored locally. In this environment, a user faces inconvenience and access difficulty when he or she tries to use another workstation. We believe that the fragmented implementation we now have is a result of several factors: lack of central management tools used a very thinly staffed central support group the rapid growth of the Windows NT computers. Our goal is to improve this situation and obtain a more logical and reasonable configuration using SMS.
We believe that the desktop-computing environment should be consistent
and SLAC users should have easy access to all common applications
regardless of the location of the user or the workstation. We
plan to set up the commonly used applications such as the Microsoft
Office suite, NTrigue Operating System-Using NT to Integrate a Heterogeneous Environment Developed by Insignia Solutions Inc., the NTrigue Operating System version 3.0 is based on core technology from Microsoft Windows NT Server 3.51. The NTrigue Operating System incorporates technologies from Citrix, Microsoft, and Insignia Solutions. It provides cross-platform, multi-user login capabilities and functionalities found in operating systems like UNIX, VM, and VMS which are traditionally used at SLAC. SLAC employees need to take advantage of the rapid growth in software available for the Windows 95/NT Operating Systems. However, it is difficult to make changes in hardware and operating systems across the lab due to constraints in time, labor, cost, and expertise. Users are sensitive to drastic changes in their hardware and operating system environment. The transition to Windows NT must not be disruptive to user workload and productivity. The main objectives for using NTrigue at SLAC were to allow UNIX, Windows 3.x, and Macintosh users to take advantage of and use the software available for Windows 95/NT and to facilitate user migration to Windows NT in a more gradual manner. SLACs interest in NTrigue came from two frontsthe general users who wish to use office productivity tools like Microsoft Office, and the power users who wish to use engineering and graphically powerful applications like AutoCAD, Pro/Engineer and ANSYS. Given the popularity of the Microsoft Windows 95/NT Operating Systems and the amount of windows applications available in the market today, NTrigue was initially well received by Macintosh and UNIX users who needed to run Windows-based applications that were not available to them natively on their computers. SLAC is currently planning to implement two NTrigue Servers to run PeopleSoft applications for those users who do not have computers capable of running the Windows NT version of this business applications. The BABAR Project at SLAC has fueled the interest in NTrigue from the engineering front. With more than 75 institutions spanning several countries, and over 400 collaborators, the BABAR Project faces enormous challenges when it comes to coordinating, collaborating, and sharing resources. Since most of BABARs engineering efforts at SLAC are done under Windows NT, the commissioning of one NTrigue server has allowed sharing of information and resources with collaborators inside and outside of SLAC. We have monitored NTrigue usage by SLAC users during the day and by European collaborators during the night for large engineering/analysis jobs, which average desktop computers may not be capable of performing. It is now common for users to login to our NTrigue server to check progress of their analysis job in ANSYS or to make minor changes on models in AutoCAD or Pro/Engineer using a high speed modem linked through their local Internet Service Provider (though network performance issues might arise from time to time). The BABAR NTrigue Server is currently equipped with dual Pentium Pro 200 MHz CPUs w/512k cache, 512 MB RAM, 16 GB RAID Disk, 8 GB scratch space, 2 GB swap disk, and 100Base-Tx connection. The use of NTrigue Server at SLAC is broad. However, user login is limited to a few handful of users since only a base 15 concurrent-user package per server was purchased. NTrigue has not really been stress tested for large scale enterprise applications like PeopleSoft at SLAC yet. According to our colleagues at Stanford University (who are working on a similar project with NTrigue and an Oracle business application), a comparable NTrigue Server equipped with dual Pentium Pro 200 MHz CPUs w/512k cache and 512MB RAM was stress tested with 32 concurrent users running the Oracle client with little degradation in performance. We anticipate serving up to 50 concurrent users per server for PeopleSoft usage without encountering performance problems. Should performance problems surface, we hope adding up to four processors on the server will alleviate them. With over six months of testing and evaluating NTrigue, we can conclude that NTrigue or a similar operating system from Microsoft (Windows NT Enterprise Server 4.0 announced for release in Q3 1997), will be needed at SLAC to aid in integration of a heterogeneous computing environment. NTrigue has brought UNIX-like functionality to the Windows platform allowing users more mobility while maintaining a consistent user environment with a consistent set of applications. With NTrigue, one can centralize administration efforts, control software licensing, and control software revision levels with ease. Furthermore, administration can be done remotely from almost anywhere and on any platform with a network link to the internet. NTrigue has saved time, effort and money as it significantly decreases the amount of time spent on hardware and software upgrades. NTrigues drawback is that it is based on the older Windows NT 3.51 technology. PeopleSoft version 6 is certified to run under Windows NT 4.0 and it is necessary to occasionally tweak NTrigue in order to get PeopleSoft version 6 to function properly. It is uncertain if there will be future releases of NTrigue based on the Windows NT 4.0 core operating system, since Microsoft and Citrix have entered into agreement to create Microsofts own version of NTrigue in the release of Windows NT 4.0 Enterprise Server. It is said that only Windows-based operating systems will be able to remotely login to the Windows NT 4.0 Enterprise Server, leaving Insignia Solutions to develop third party clients for the Macintosh and UNIX platform. Summary The rapid growth of Windows NT at SLAC over the last 2 years has substantially changed our support structure, as well as opened up directions for central management of the desktop computing environment and provided further cross-platform capabilities. Acknowledgments We thank our fellow desktop computing support colleagues at SLAC, who are going through these turbulent times with us. We also benefited greatly from discussions with our colleagues at Stanford University, Argonne National Lab and CERN. E-mails for the authors are: Andrea Chan achan@slac.stanford.edu Freddie Chow fchow@slac.stanford.edu Jonathan Wong johnw@slac.stanford.edu URL for the SLAC Desktop Computing web site is: https://www.slac.stanford.edu/comp/desktop/desktop.html |
This paper was originally published in the
Proceedings of the Large Scale System Administration of Windows NT Workshop,
August 14-16, 1997,
Seattle, Washington, USA
Last changed: 15 April 2002 aw |
|