Practically every server today comes with some sort of onboard management
interface. Through that interface, the server can - via network of course
- be remotely powered up, down or reset if it has crashed. A serial console
is practically always available too, which is everything you need for
linux or other proper (unixoid) operating systems. If you think you need
to run servers on windows, you'll have to get one of the really good ones
(and sometimes pay a bit extra for additional licenses), that allow you to
redirect graphical output, mouse and keyboard to your pc (usually through
a java applet). As an added bonus, they usually allow you to insert
an .iso file on your local hard drive into a virtual cdrom drive on the
server, so that you e.g. can boot from it.
However, all major manufacturers have in the past managed or still manage to
mess some things up in these management interfaces, so here is my personal
list of favourite screwups:
- One manufacturer, lets just say the name starts with an S., manages
to build management cards onboard that take 5 minutes to boot. Now
that alone would not be horrible - but the thing is, you cannot
even power on the server before the management has fully booted!
That's right, you plug in the power, and maybe 5 minutes later you're
allowed to actually turn the machine on.
- There is another manufacturer, lets just call him Howling Packrat.
Of course, any similarities in name are pure coincidence.
The remote control java applet of this one used to be a bit
delicate, it would only run with one exact version of java.
Not 0.0.1 higher
or 0.0.1 lower. Just that one version. Of course, it will happen
that you try to run the applet on the wrong version of java, usually
resulting in the applet locking up. So you kill your browser and try
again. However, you don't really have many attempts there, because
usually the management card will lock up after the applet crashed
1 or 2 times, and you have to power cycle the server physically
to bring it back to life.
- A different manufacturer of business machinery, active internationally,
does not seem to have understood the concept of
TCP
on their
management interfaces yet. I noticed this last week, when I couldn't
get the Java Applet for graphical redirection to run. It just kept
spewing nonsense errors (permission denied, class not found, ...)
at me. It took me a while to realize that sometimes the simple
webpages from the webinterface just stopped loading in the middle
of the text. From there on, it was pretty clear what happened:
In the management network there was still one 10 MBit switch, because
there is close to zero traffic on this network and thus nobody ever
cared to exchange it. All remote managements we had ever used before had no
problem with that, but not this one: Instead of slowing down when
the acknowledgements from the receiving side don't come, and resubmitting
packets that got lost due to overflows on the slow link, as a proper
TCP implementation would do, this one just closes the connection.
That caused the webinterface-pages to be incomplete sometimes, and
it prevented the Java applet from ever loading successfully, because
the transmission of the rather big file would always die after a
few kilobytes. As soon as the switch was exchanged with a
100 MBit one, all of these problems dissapeared. I wonder what will
happen if that manufacturer ever builds management cards with a
gigabit interface... Hopefully they will have learnt how TCP works
by then.
|