Here is a post of mine and response in a RHEL5 discussion, I think someone here might find it interesting also and maybe give me an insider's hint (about all linux and xen distributions for IA64):
I
feel deceived :( ... Itanium is not going to be supported after March
2014 and in RHEL 6 ?!!?!?!! I know this probably is a bit late
reaction, I have also a SR open with this question and a business case
officially documented in my company (I can send it gladly to anyone
interested) with proposal based on RHEL and HP Integrity blades
(Itanium). I will open another SR if needed, but I am not sure this is
the best way. Now, can anyone give me deeper insights on this, hints
how to turn somebody's attention (manager in RHEL which could help or
at least deliver options), suggestions, anything ? I know that Itanium
has a strange story, but you don't just give up like that on a
platform which is still supported by other vendors, this is not good. I
have Micro$oft people here awaiting this situation with all the joy
knowing that hardware migration is not an option, and HP being
indifferent. Please help,
Zoran Popovic.
/****************************************************************************************************************************************************************************/
/* I got one response so far:
*/
/****************************************************************************************************************************************************************************/
> I feel deceived :( ... Itanium is not going to be supported after March 2014
> and in RHEL 6 ?!!?!?!! I know this probably is a bit late reaction, I have
> also a SR open with this question and a business case officially documented
> in my company (I can send it gladly to anyone interested) with proposal
> based on RHEL and HP Integrity blades (Itanium). I will open another SR if
Sure, I'm interested in looking at your business case. We have two SGI
itanium altix 350's (8 node/16p total) and another with 2 nodes/4p and
all I know is that replacement parts are expensive, the warranty
contracts are expensive, and the systems are expensive, and they have
a bigger rack and environmental footprint. The 1.5GHz 16p system has
lower performance than a single node 16p 2.93GHz Xeon nehalem system
(for our computational work loads). Let's just say we're not replacing
the itaniums as the nodes start dieing. Ours used to run RHEL3 but SGI
made us switch to SLES9 or 10, perhaps that's another option if you
really want itanium support (don't know about novell's plans).
In any case, even SGI's new "UV" large shared memory/many cores system
uses nehalem CPUs.
HTH /****************************************************************************************************************************************************************************/ /* And this is what I've answered: */
/****************************************************************************************************************************************************************************/
I
am still compiling some data about current state and different
benchmarking (both official SAP, Oracle and HP, and my personal
unofficial experience). I will send you what I have (document about
half year or more old) at the moment, to your personal mail if you tell
me why you need it.
In short, my company bought 10 HP Integrity servers (two rx2620, 10
rx4640) five years ago, having older non-dual non-HT/VT-i (Montvale,
Madison, I don't remember anymore) cores, with FC SAN EVA 5000 at that
time. They were unfortunately implemented on Windows 2003 (for reasons
I do not wish to discuss). And here comes my favourite anegdote about
Itanium raw performance: while doing an Oracle 10g patch (CPUJan2009
bundle, I think or something like that), carelessly for some reason (I
usually don't do it that way, of course) I haven't read the patch
README and I have omitted to do additional view compiling by habit
(many patches/patchsets do not need it beside the usual compiling).
Production database node has two dual 1.1GHz processor modules and 8 or
16G of RAM at that time (mx2 modules, let's say it is like 2 CPUs with
dual cores), and the moment I have had database ready for use I have
concurrently read that I need additional compiling which needs about 30
minutes for average database with 2000 objects by internal Oracle
benchmarking/testing. I have sighed, did query and saw three to four
times more objects in my database than stated in the README manual, and
started swearing in myself about complicated corporate procedures and
flows about informing users, system availability, internal QA, etc. So,
I decided to put system back down with my teeth strongly clenched
together and started these two scripts on production system (not the
usual situation, I repeat). It lasted not more than 5 minutes ! I
didn't have to follow all the strict QA procedures, inform users, and
so on ...
In the mean time, my company bought additional two rx4640 and 4
Integrity blades (Madison dual core HT/VT-i enabled and newer 1.6GHz
CPUs). There are many different Itanium models, I don't want to go into
details, but blades were bought recently a year ago or so. Official
vendor support was obtained for three years, and knowing that a
previous old and historical Alpha 4000 server worked in production for
nearly 8 years, and that we still have legacy non-SAP Alpha ES47
OpenVMS cluster systems working now for 7 years, I don't believe our
management will change much about Itanium, especially having all this
crisis situation (though, support becomes progressively expensive for
systems older than 5 years, that's with HP and more or less same with
all hardware vendors). My company supported me in making prototype with
Xen virtualization based on Red Hat Enterprise Linux on those blades. I
was able to run 4-5 guest machines on 4p host with 32G RAM without
significant performance loss compared to 1 guest, and it proves to be
very stable (though having HVM windows guest which show poor I/O, it
shows to be almost comparable with current production). I have followed
all the recommendations given by SAP, Oracle, HP and RHEL and their
support, and showed that this configuration is supported and
practically useful (some bad experience with database, but nothing
unsolvable), while optimum performance would be with PV RHEL guests.
Business users and management in a pharmaceutical company have very
high expectations about reliability, availability, QA and many other
things, so it is really not just about making things work cheaper, and
I think I have managed to prove that for RHEL on Itanium.
One of the reasons I didn't choose SLES is that I had problems with
installation (though I've found workarounds) and Xen on Itanium, and
more important, I think there are issues about official SAP support for
it. SAP is a very serious and affected vendor, you get roadmaps, strict
patch dates (including Itanium), extensive support infrastructure, and
it is very good for planning critical business environments like those
I have now, so - Suse is an option, but not for production at the
moment. My long run goal is to move to RHEL. That is the basic reason I
am disappointed with Red Hat's decision to move away from Itanium so
quickly and suddenly. They left me either to migrate to different
hardware, or stay with awful Micro$oft (they obtain Itanium support,
but no VT for it, only resource management) - we already have VMWare as
VT platform for x86/x64, so I don't expect anyone will invest in
additional linux or VT like Xen in first case. HP has it's HP-UX which
is an excellent OE and AFAIK the only true alternative, but also very
expensive and I have lost management's support for it long ago. And now
I'm kind of stuck. Yes, year 2014 is far away, while M$ signs here
extensive contracts and I get less artillery for persuasion. Oh, and an
option I usually forsee is to take some of those nice tranquillizing
pills from the production plant directly in the mean time, or someone
just kills finally and completely that Itanium CPU so all affected can
continue their lives.
ZP.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|