|
[snip]
I'll try and do two things: Firstly, I'll explain in more
detail exactly what we have decided and present the reasoning
behind it. Secondly, I'll try to say something about the
implications for Windows support.
I'll try to present the reasoning in simple steps, and it
would be very useful to identify clearly any points that you
think are incorrect, or any questions that you think remain
unanswered ...
Decisions
---------
The initial core of the DICE project will focus on providing
infrastructure to support commodity computing under Linux on
PC hardware. This infrastrutre will also support Solaris
(although *deployment* under Solaris will require additional
effort). No infrastructure will be developed to explicitly
support Windows, although compatibility with Windows will be
considered wherever possible, and support for commodity
Windows applications will be provided via VMware.
Reasoning
---------
(1) The remit of the project is to provide an infrastructure
for cost-effective and efficient "commodity" computing for
the majority of users in the Division.
(2) We would expect this infrastructure to support the
majority of the Division's research and teaching
requirements, but special requirements which are driven by
specific research or teaching needs should be justified
and funded from appropriate sources. We will be happy to
incorporate special requirements if suitable additional
funding is available.
(3) Experience at KB and elsewhere demonstrates that (1) is
possible using Linux on PC hardware; this has proven to be
cheaper to buy and considerably cheaper to manage than any
alternative in a large diverse environment.
(4) VMware can provide access to the important Windows
*commodity* applications (eg. MS Office).
(5) Integration with native Windows machine can be supported
where technically possible (eg. Samba, Kerberos).
(6) A formal survey of all Informatics staff has confirmed
that (3,4,5) meet the commodity requirements of all but a
few users.
This seems sufficient to justify the chosen direction. However,
there are a also a number of very strong supporting factors:
(7) Around 85-90% of existing Divisional computing relies on
Unix and it is unlikely that most users would be happy (or
able) to convert to Windows. EUCS would be unable to
provide this Unix support to a level which the Division
would consider acceptable.
(8) Very few resources are available. Linux is much easier to
support in large, diverse configurations than Windows. We
barely have the resources to support the Linux
platform. We don't have sufficient resources to support
Windows and certainly not both platforms.
(9) Most departments in the University which use Windows for
commodity computing use EUCS for support. EUCS has
considerable experience and resources to devote to the
support of these systems. Using Divisional resources to
duplicate this seems foolish.
(10) A significant proportion of the DICE effort looks likely
to be funded by GRID collaboration which is
Unix-based. If a similar source of Windows-based
collaboration could be found, we would be happy to make
use of this.
Implications for Windows Support
--------------------------------
We are well aware that a small but significant number of users
have a genuine requirement to run native Windows operating
systems. There are several options:
(1) In many cases, the small numbers and ad-hoc nature of the
work means that development of large-scale automated
infrastructre is not necessary or cost-effective. In these
cases, it is probably best to continue to provide the
higher level of support staffing which is necessary to
maintain the systems using largely manual methods. The
funding for this additional effort should come from the
group geerating the requirement. EUCS are well-placed to
provide backup and support for this type of installation.
(2) EUCS has developed and deployed various mechanisms for
configuring and maintaining large numbers of Windows
machines. Because of the difficulty of this, these
techinques place considerable restrictions on the
flexibity of the configurations and require larger amounts
of effort to incorporate new software. This probably makes
the technology unsuitable for small research clusters, but
it may be suitable for example, for a student laboratory.
(3) If we were to consider investing seriously in
infrastructure for Microsoft support, the central issues
would be similar to those already identified for DICE:
(a) The authentication and directory service issues being
considered for DICE are supported in the Microsoft
world by Active Directory. We don't believe that
anyone would suggest attempting to replace this with
anything else in a Microsoft environment, so no
development effort would be required. However, there
are very serious deployment and integration issues
which have been extensively investigated by EUCS and
documented in a good series of papers. Even EUCS, with
their Microsoft experience, have reservations about
deploying this technology.
(b) Software distribution and configuration (particularly
of third-party software) is extremely difficult under
Windows. The "single-user" mentality and the
proprietary nature of the software make it very
difficult to develop automated systems for handling
diverse, evolving environments such as ours. However,
the high-level configuration techniques being
developed for DICE are certainly applicable in theory
to the Windows environment and we would be very
interested in following up this application. We have
attempted (unsucessfully) to interest EUCS in such a
collaboration. If other interested parties could be
found, or if specific Windows-related funding was
available, we would certainly be open to working in
this area (note that this is a very difficult problem
and a reasonable resource would be required to make a
significant impression).
A personal gut-feeling for the required effort is that about
twice the effort (again) would be required to develop and
maintain a similar level of service using MS Windows, to
that which we can provide under Linux.
Please do give me some feedback on these issues. They have
been given considerable thought and we are attempting to
provide the very best computing facilities for the Division; I
would also like to think that we are setting an example to
those people outside of our small academic world of how it is
possible to build effective, maintainable computing
environments :-)
Paul
Email 2:
> I have a number of projects where I am required to use Windows tools, Yes. I assume that these are a minority requirement for research-specific reasons, and are hence should not be allowed to unduly influence the commodity needs of the Divison. Of course, we will attempt to interoperate as much as possible, but this is not likely to be easy when propritary, closed protocols are involved. (BTW: Have you tried NetMeeting under our latest VMware installation?) > are Office and VM Ware might be an (expensive) solution to that. This is an important misconception. VMware costs around $70. A single manual rebuild of a typical Windows machine is likely to cost more than that simply in terms of CO time which is our most valuable resource. > c) Informatics infrastructure and DICE design should allow > interworking effectively with Windows (and possibly any other) > systems for those that need them. We certainly plan to do that & this has been explicitly stated in the aims. I would definitely expect to provide application-level services such as IMAP, SMTP Samba, etc, however these are comparatively easy - I'd like to emphasize that (the initial) DICE core involves the layer below that which is much harder. You can't offer *any* service such IMAP etc unless you (a) are capable of building and maintaining servers effectively, and (b) have an authentication infrastructure which allows it to be used safely and conveniently. Just to emphasize - the availability of these services is not the question - that it easy. What is important is the infrastructure that they rely on - Setting up a Windows authentication service to allow these to interoperate seamlessly is very hard (maybe impossible?), so it may be, for example, that you need to type passwords more often under Windows, and/or you system is less secure. > d) I agree with you that Windows users working inside our > environment would be poorly advised to go the whole hog Microsoft > route. We deliberately use simple setups that can be easily built, > restored and maintained. I think the problem here is that most people don't really understand what we mean when we talk about a maintainable system. I doubt whether we would agree that your systems and easy to build, restore, or maintain by our definition (I'd love to be proved wrong!). You need very high standards here to make this pay-off in terms off effort. (I'm happy to talk more about this offline if you are interested).
|
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh |
|