[rescue] advice on rescuing an e10k

[velociraptor]

On 10/26/06, William Enestvedt <William.Enestvedt at jwu.edu> wrote:
> Nadine wrote:
> >
> > But most IT shops are not built like that.  They start
> > out as these tiny flower beds and morph into full-blown gardens
> > without any real regard for sanity and structure.
> >
>    "Feed me, Seymour!"
>
>    I will cheefully suggest that there are lessons to be learned -- and
> tools to be borrowed -- from Linux for use in Solaris shops.

What kind of tools/lessons are you thinking of?  Personally, I don't
find many *deployment* differences in the sense of methods between the
two.  Speaking from the perspective of managing the systems themselves
after they are installed, in my experience, I find that Solaris Sparc
systems tend to be more robust when under-spec'd or overloaded, and
generally act in more predictable ways when they break.  So, if the
data center and the infrastructure is a spaghetti bowl, I'd rather
negotiate the mess under Solaris than Linux, that's all I'm saying.

>    'Course, anyone who's so wedded to a single platform that their NIMBY
> gets in the way probably has other things wrong in their data center
> already.

Would you say that about using Windows for "mission critical"
services?  :-) Speaking purely from the perspective of having to
support large numbers of systems, I think there is a lot to be said
for homogeneous configurations, barring over-riding requirements for
some feature in a given application that is not available on your
preferred OS.

In the past, I supported 1000+ systems while on-call[0]--managed by 40
different admins and probably half the boxes were built by hand--and
that would have been a much, much more difficult proposition had there
been anything beyond various versions of Solaris, SunOS, and OnTap
(NetApp) with a scattering of HP-UX (compute farms, very homogeneous
builds).

In an ideal world, IT people would look down the road whenever they
build out something and hedge against future requirements.  Most
people are not put into a position where they can do that though.
Generally, we are given ridiculously small budgets and ridiculously
long laundry lists of requirements and are forced to make do.

=Nadine=

[0] "On-call" in this context means you are expected to fix the
problem without contacting the "owner" of the machine, with end-users
(engineers) having the direct # to the on-call phone/pager for 24x7
support.