CERNVM Status and Plans
Harry R. Renshall CN/PDP
The CERNVM system is now essentially frozen. The last system change was the introduction of VM/ESA 2.1 in January of this year and none are planned at the moment. We will be following the evolution of the CP and CMS components in order to evaluate the need for any such changes during the remaining lifetime of CERNVM but do not anticipate any will be deemed necessary. The current planning is to run a reduced size machine during 1995 and 1996.
This planning, for reducing the size, and hence cost, of the IBM ES9000 mainframe which hosts the CERNVM service, is now well advanced. The objective is to move most of the LEP batch computing from CERNVM to CORE services during 1994 so that the CERNVM machine can be changed during the 1994 Christmas shutdown. This load corresponds to half of the VM capacity. The remainder of the load is made up of interactive work at fifteen percent of the current machine and the balance being non-LEP batch work; the reduced size machine is being chosen to take this load. However, the time distribution of interactive and batch work is very different with the interactive load being concentrated between 08.00 and 19.00 Monday to Fridays and thus taking a much larger fraction of a half-sized machine. We have performed tests on various configurations of our current machine and concluded that we need half the current CPU power, half of the extended storage, currently 1 Gbyte, but all of the 512 MB of real memory. We are thus considering an offer by IBM for a 3090-600J machine satisfying these requirements. This has 6 CPUs as does our current machine but they run at half the speed. We do not believe this will affect the interactive response time and, for batch work, turnaround time is controlled by the mix of batch workers. So in order to give reasonable daytime turnaround for short and medium jobs we will run fewer batch workers overall and probably not run any long jobs during prime shift. We will be reducing the amount of staging disk at the same time, as the main user of this is LEP batch. Our planning is to run this reduced machine during 1995 and 1996. So all interactive users, including those of LEP using CERNVM as a front-end to submitting CORE batch and non-LEP batch users will have plenty of time to convert to new services.
The new services to take over the functions of CERNVM are now emerging. CERNVM users can already move to the NICE PC Office network which supports users requiring electronic mail and office applications (as well as specialized engineering packages) and which now includes good X-terminal emulators for connectivity to other systems and the world wide web. This environment requires users to have a PC and it is not targeted at the Fortran applications developer or the data processing needs of experiments and for this work Unix platforms will be offered. For CERNVM users to move to Unix requires both the building of a comfortable Unix environment, both for batch and interactive work, and the provision of hardware platforms. Since the CN reorganization last December much work has been done towards these goals and there are already interactive platforms for some experiments. By the end of this year there will be at least one public interactive Unix platform targetted for VM migration and, subject to final management approval, one public platform for batch work. We would not encourage the average user to look at migrating this year but we will certainly be encouraging pilot users.
A particular problem with CERNVM for the rest of 1994 is that of scheduling the batch time that has until now been allocated to the LEP experiments. The COCOTIME committee deliberately gave them a reducing budget during 1994 with the last quarter allocations being those which they can expect next year. Each LEP experiment already has at least five times their CERNVM CPU capacity and twice the disk space available on the CORE services. The committee also agreed that CERNVM resources should not be wasted and agreed that LEP batch could use the unallocated time for work that was guaranteed to not be required on CERNVM next year. This could either be because a particular project was going to finish this year, a program was under conversion with an agreed target date of this year, or that an already converted program could profit from an idle system to get good turnaround. We have now introduced mechanisms to allow exploitation of otherwise idle time but wish it to be done in such a way that users are made aware of their migration responsibilities. The mechanism is to give a low queue priority to batch work submitted with the SPEED 1 attribute but only charge this work at 1% of the normal cost. VM budgets have a CPU time and Swiss Franc equivalent component (about 250 FS per hour with additional charging for I/O and tape mounts) and it is the Franc balance that is used to prevent job submission. LEP group administrators can register their users to use SPEED 1 via the PRIOREG command after making sure they understand that this is for work that must not be done on CERNVM next year. These users should then use BATCH SUBMIT (SPEED 1) myexec for their time-intensive work, typically L and V class jobs, while the group budgets should permit short and medium jobs at normal priority (in fact this is SPEED 2). From the next quarter we will be much less sympathetic to LEP groups that exhaust their CERNVM budgets by not using SPEED 1 and will want some explanations from those users who over-consumed at normal priority before reactivating the group. This will have the unpleasant effect of stopping the whole group from submitting batch for some period of time and I hope the groups will be sufficiently disciplined that this will not happen. Note that interactive work is not affected when a budget is exhausted.
The final major change to affect users of CERNVM was the recent security audit where the password cracking program was run against the 8000 active account entries in the VM password file. Only 311 accounts were found to have weak passwords, the most common reason being inclusion of the login identifier in the password. The passwords of these accounts have been expired so their owners will have been obliged to define new passwords, under the new rules which forbid inclusion of the login identifier in any way. Only five of the accounts had not been used recently and these were blocked. It is normal procedure for us to block, and eventually delete, unused accounts. To recover a blocked account users should contact their group administrator who will then inform the UCO, or can make direct contact with the UCO (tel. 4952 or e-mail to UCO@CERN.CH), as they will normally check with your administrator. Articles on password security, and the crack program, have been published in CNLs 212 or 210. You can read them on CERNVM via XFIND CNL PASSWORD or on the World Wide Web by entering these keywords in the search box of the XFIND searchable index page of the World Wide Web (follow the link to ``Computing'' under the Activities heading on the CERN home page and then link to 'Documentation and Newsletter index' under the CN heading).