× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> From: Walden H. Leverich
> 
> >Yeah, but let's be clear here: "rolling upgrades" means a completely
> >redundant set of servers...
> 
> No, no no, that's exactly not what it means. Let's say I have 2
servers
> running my site. I can take one offline, leaving 1 server running my
> site, upgrade that one and then put it back online. Then I can take
the
> other server offline and upgrade it and put it back online. If I have
> only 1 server, then yes, I need a completely redundant server, but
once
> I have more than one I can just use part of the cluster for the
upgrade.

Walden, whatcha smokin'?  This ONLY works if you have holographic
redundancy (that is, every server can serve every application).  This is
absolutely NOT the case.

Let's take your mythical situation, with servers A, B and C.  Let's
assume for fun's sake that server A and server B are entirely
self-contained, in that they have all the database and application
software they need.  (This is rare in anything but the most simplistic
environments, but let's say that's the case.)  That means that in order
for C to truly back up A and B, it must be able AT ANY TIME to be able
to run the software for both A and B.  Which means that AT ALL TIMES,
server C must have up-to-date and hot-switchable copies of both pieces
of software.

Not bloody likely, dude.

Sure, if all you're talking about is scheduled downtime, then you can
possibly roll all your servers through a single backup machine, but
that's not high availability.  You MUST have an ENTIRELY REDUNDANT SET
OF SERVERS in order to be H/A.  This is pretty simple stuff.

And it gets far more complicated in a real-world environment where you
have servers that cross-communicate, like database servers and LDAP
servers and the like.  I don't know what kind of applications you run,
but in my world if applications don't talk to the other applications in
the network they're pretty useless.


> >I'd love to see the offsite DR system that can handle
> >20 Windows servers--or 120... and how much that costs.
> 
> We use one in Hawthorne, NY. We've got a dozen or so servers up there
> and that's not a drop in the bucket for that data center. Costs a
couple
> grand a month -- peanuts.

HEE HEE HEE!  $25,000 a year!  That's a whole BACKUP ISERIES!  Maybe
TWO!  EVERY YEAR!  WITHIN A COUPLE OF YEARS I COULD HAVE A CLUSTER OF
BACKUP ISERIES!!!!  WHOOOO HOOOO!

<g>


> >3. You can partition your machine and use a small partition as the
> >"backup" box as in option 1.
> 
> Um, sort of. Yes, you can do an OS upgrade on partition 1 while
running
> partition 2. But what about hardware upgrades, or upgrades to the
> service processor?

How often do you think this occurs, Walden?  I get the idea that you see
iSeries guys opening the box up every week and changing cards like in a
Wintel machine.  It doesn't happen that way.


> >the vast majority of software upgrades for the iSeries can be
> >loaded while the machine is running, and only a subset of them
> >require so much as an IPL
> 
> No argument -- and the same is true of windows. I'm speaking of the
> upgrades that do require downtime. How long does it take to upgrade
the
> OS? Between full save (twice?), OS load, ptf load, validation and full
> save, that's usually a full weekend event -- often a long-weekend.
That
> really puts a dent in the five-nines concept.

Oh bullsnarkey.  Every week I get a security that wants me to reboot the
machine.  Every week.

Second, you constantly bitch about O/S upgrades.  If you understood the
difference between system saves and non-system saves (and the fact that
non-system data can be saved WHILE THE SYSTEM IS RUNNING), you'd realize
that with a decent tape drive the window for a full system save really
isn't that long.  Personally, I've never required more than four hours
for the whole shebang, except the one time I completely read the manual
incorrectly and had to reinstall the SLIC.

For other people, they are a bit more anal.  They'll do a complete
system save.  If this is on terabytes of data, yes indeed it will take a
little while.  But then again, that's not an issue of the hardware;
those same people would have to do the multiple saves on the Windows
machines, and would run into the same expanded timeframe.

But even if that window were truly an issue, I could easily rent time on
another machine (my DR machine, for example) for the upgrade that
happens perhaps once every 12-18 months.  This would in fact be an ideal
way to test my DR procedures.


> On a single piece of hardware, perhaps -- and I'm not convinced about
> that. However, that misses the point. Users no longer care if the
> computer is up or down, they care if the application is up or down.
> Multiple pieces of hardware will _always_ provide better uptime than a
> single piece.

No, no, no.  This is simply untrue.  Redundant hardware will provide
better uptime.  But clusters are NOT redundant.  You need all of those
servers up in order to have your system up.  Unless you have redundant
CLUSTERS, you still have a single point of failure, and in the case of a
cluster, MULTIPLE single points of failure, which add up to REDUCED
reliability, not increased.

Man, this is simple stuff, Walden, and I'm surprised you're spewing the
company line on it.

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.