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@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
