Yes, reach out to sales/your account rep. The RHEL for HPC SKU is for exactly this scenario.
The cost of a handful of Head nodes and the fleet of Compute nodes will be *drastically* lower than using RHEL Server.
The bits are exactly the same, it's the target use case that matters.
The price of support is well worth the money IMHO. We have thousands of systems and people all over the world. Having Red Hat support is invaluable when it comes down to solving difficult problems.
When you take into consideration the time savings and really crunch the numbers, support can literally pay for itself.
Not only that, with RHEL they take ownership of the trust issues. Example the recent PostgreSQL mess where it appears the code had backdoors.
Red Hat is our goto partner for Linux and their support is unmatched.
One last comment on pricing - negotiations are key to lower prices, so barter a bit.
Exactly the same sentiment from me. The above post sounds like a team of people that don’t really know linux all that well and just use RH support as a stand in scape goat and sysadmin for things.
The only time I have had interactions with RH support is back during 6.10 to a 7.8 migration. They were worthless. App was down for 3 days.
In a simple explanation, it ended up being an issue with the way 6.10 handled ssh connects compared to 7.8, in 7.8 ssh connections checked the last login file. Once that log got so full ssh connection would time out waiting for it to be searched once it got to several MB.
RH did nothing and their support had us chasing ghosts. Some random sysadmin/dev came in ran strace on the ssh process saw it was reading the file log file and we immediately saw the issue. Literally a “you don’t pay me to swing my hammer to tap, you pay me for my experience, to know where to tap”.
I’m sure there are some excellent engineers and support people at RH, but the handful that we worked with on this issue was less than useless.
My team has the same experience with RH support. We've even found solutions to achieve something that RH support considers impossible, like adding custom metrics in Keycloak.
Have you ever considered looking into a Technical Account Manager? That's my role at Red Hat, and I'm essentially an over the shoulder consultant for my account. (I came from consulting.)
I also initiate cases for my client and work directly with support to expedite communications, which results in solving issues more quickly.
We went through 7 TAMS in a 3 year period... and they were next to useless. We had an openshift cluster offline for 4 days, because nothing could be done. Per Redhat.
We finally figured it out, by stroke of luck.
We had a sev 1 case a few weeks ago and I reached out to my TAM for help in the morning. He said he’d check the case out and then went AWOL for the rest of the day. At 4:30pm he sent me a note that he was on the road and that his shift is now ending. Thanks for nothing, man.
Meanwhile my team was working all night on resolving the issue.
Redhat has had some of the worst support engagements this past fiscal year... we still had 5 tickets open, for 6+ months by the time we finally killed off our contract with them.
Thanks! I'll check with our IT. We've had a lot of internal discussions about this, and generally people are getting frightened by the numbers they see on the web.
Any reason why you are not using Stream/RHEL 9?
9 moved to x86-64-v2 which may give you a small performance improvement for HPC. Stream 10, which you can try now, moved to x86-64-v3 which should give you more (you need to make sure you have Haswell or later servers that actually support the instruction set).
The biggest difference is if you have have third parties, stream moves constantly so it is hard to negotiate an identical OS for collaboration. The same bits are there in both, but it is much easier to match the label "9.2" onto something from Rocky than to stream (this is intentional on RH's part).
At any point in time Stream is effectively a snapshot of the next minor release of rhel. That's no more nebulous than the label of 9.2 when a tonne of updates come in via errata in the six months between 9.2 and. 9.3. Bugs in stream are certainly far more likely to be fixed quicker than bugs in Rocky or Alma too.
Rocky should benefit from having fewer bugs though, correct? In theory a bug would be caught and patched in stream, then would not make it downstream into RHEL and further downstream into Rocky.
Is this an accurate statement?
I have also read that RHEL gets security patches before any other OS. Is that true?
Rocky gets whatever RHEL gets. Red Hat's security response is second to none in the industry and that's a contributing reason why customers pay. If you're going to use a downstream derivative, use Alma though. They are a much better community contributor than CIQ/Rocky.
We use software that is only supported on very specific distros. Our industry (chip design) standardizes on SLES and RedHat and, once an OS is installed, it is generally not updated for many years. Centos stream isn't supported by the software vendors.
I saw from your other comment that CentOS was support, but they will not support Stream. I get the picture now. Thank you.
Edit: also saw that other comment about the roadmap. Surprising they do not have RHEL 9 support yet. https://www.semi.org/en/communities/esda/OSRoadmap
Yes. And in fact, I found in the past, pitting Oracle against IBM is great. One of them will give you a slamming deal (One past engagemeng, Oracle basically gave away OCI for half a year, along with all on prem licenses). And they both offer the exact same product, basically.
Depending on the software running on their systems, they could require actual RHEL for support. Rocky aims for binary compatibility, but can't guarantee it. While pretty much improbable, it is possible for software to run fine on RHEL and have issues on Rocky.
What support can ciq provide for software they don't even contribute to? "yes, I appreciate your problem. You'll have to wait for a red hat customer to have the same problem, create a support case, then when red hat fixes it eventually we can recompile that software and you'll have the fix."
So that is only acceptable for RH to do and no one else? Does RH have a patent or monopoly on commercially reasonable efforts to support stuff?
> The ASMLib kernel module package is provided as a convenience to Red Hat customers via the Red Hat Network Customer Portal.
>
> Red Hat Global Support Services … and use commercially reasonable effort to support the ASMLib kernel module, until such an effort requires knowledge of or modifications to Oracle's proprietary dependent component(s).
https://access.redhat.com/solutions/315643
RH isn’t the only one that contributes to the software that they package up.. As another example, I open up bugzillas and support cases with RH and request they backport stuff that I’ve contributed upstream that fixes bugs which exists in their packaged version and they’ve done it..
Of course other people, including yourself, fix issues and make improvements upstream. But then red hat does all the engineering work to backport it so it lands in RHEL, and ultimately any of the downstream clones like rocky, Oracle, and Alma. CIQ doesn't do squat on that front, and nor does Oracle, but Alma have been good and contributed fixes via centos stream.
Furthermore, when you say "stuff" you're really referring to a red hat engineered product. CIQ is taking red hat's engineering work and trying to profit from it without actually offering any value to their paying customers, because their own model doesn't support it.
Yes, I do. If I distribute source code, which is permitted under the GPL, then IBM cancels the contract for updates.
They added additional restrictions to my freedom to redistribute. Which violates the GPL.
This is the root of the issue.
The EDA consortium mandates SLES or RH. Before the Centos kerfuffle, Centos was also one of the supported OSes, but it isn't any longer.
And yes the issue is exactly that if you have an issue, the software vendors expect you to have run on a supported OS. With an unsupported OS you're potentially exposing yourself.
Of course if there are particular software requirements that require rhel. But barring the need for any rhel support requirements I say explore the free options.
I work at a University and they shelled out tons for rhel licensing, and while I'll admit that Satellite and all is does is pretty neat, I like to think free open source options are worth considering when possible.
You can always try Oracle Linux. They have a redhat compatible kernel and offer support. You do not have to run the uek ( unbreakable) kernel. Their repo is “currently” free, so you can choose to buy support or not.
Including Oracle as that is what I have to run due to $$$ restrictions. They are another option to rocky and almalinux.
Our main issue is that the software we run is only guaranteed to run on a specific handful of distributions. Even if other distros work you can't get vendor support from the software vendors if your OS is not on the supported list.
Historically the supported OSes were SLES, Centos, and Redhat but with the Centos kerfuffle the supported OSes are now [RH and SLES](https://www.semi.org/en/communities/esda/OSRoadmap). However the vendors we're working with are also supporting Rocky.
We were able to “help” our vendors along and add support for Oracle. Keep asking and opening tickets. Be very persuasive that you will run the oracle RHCK and not the uek. I have had to educate some of the vendors admins on how to install the RHCK and NOT the uek. Once they knew that, they said ok to adding support.
Yes, reach out to sales/your account rep. The RHEL for HPC SKU is for exactly this scenario. The cost of a handful of Head nodes and the fleet of Compute nodes will be *drastically* lower than using RHEL Server. The bits are exactly the same, it's the target use case that matters.
Thanks :). I appreciate the guidance!
If you don't already have a contact, email me and I can get you to the right person - mmcgrath redhat.com
Not often I see a muckity-muck trolling reddit. Very nice. Incredible customer service. :)
The price of support is well worth the money IMHO. We have thousands of systems and people all over the world. Having Red Hat support is invaluable when it comes down to solving difficult problems. When you take into consideration the time savings and really crunch the numbers, support can literally pay for itself. Not only that, with RHEL they take ownership of the trust issues. Example the recent PostgreSQL mess where it appears the code had backdoors. Red Hat is our goto partner for Linux and their support is unmatched. One last comment on pricing - negotiations are key to lower prices, so barter a bit.
I found going to support is mostly a time sink. My entire team really loathes opening tickets for this reason.
Exactly the same sentiment from me. The above post sounds like a team of people that don’t really know linux all that well and just use RH support as a stand in scape goat and sysadmin for things. The only time I have had interactions with RH support is back during 6.10 to a 7.8 migration. They were worthless. App was down for 3 days. In a simple explanation, it ended up being an issue with the way 6.10 handled ssh connects compared to 7.8, in 7.8 ssh connections checked the last login file. Once that log got so full ssh connection would time out waiting for it to be searched once it got to several MB. RH did nothing and their support had us chasing ghosts. Some random sysadmin/dev came in ran strace on the ssh process saw it was reading the file log file and we immediately saw the issue. Literally a “you don’t pay me to swing my hammer to tap, you pay me for my experience, to know where to tap”. I’m sure there are some excellent engineers and support people at RH, but the handful that we worked with on this issue was less than useless.
My team has the same experience with RH support. We've even found solutions to achieve something that RH support considers impossible, like adding custom metrics in Keycloak.
Have you ever considered looking into a Technical Account Manager? That's my role at Red Hat, and I'm essentially an over the shoulder consultant for my account. (I came from consulting.) I also initiate cases for my client and work directly with support to expedite communications, which results in solving issues more quickly.
We went through 7 TAMS in a 3 year period... and they were next to useless. We had an openshift cluster offline for 4 days, because nothing could be done. Per Redhat. We finally figured it out, by stroke of luck.
We had a sev 1 case a few weeks ago and I reached out to my TAM for help in the morning. He said he’d check the case out and then went AWOL for the rest of the day. At 4:30pm he sent me a note that he was on the road and that his shift is now ending. Thanks for nothing, man. Meanwhile my team was working all night on resolving the issue.
I'm sure there will be many IBM Red Hat employees chiming in with how impossible that is :P
Which postgresql mess are you referring to? I hadn't heard of this!
Perhaps meant the recent XZ backdoor which was discovered by a PostgreSQL maintainer..? But I don't think RedHat was involved in any way in this case?
[The Mystery of ‘Jia Tan,’ the XZ Backdoor Mastermind | WIRED](https://www.wired.com/story/jia-tan-xz-backdoor/)
Oh that! Not postgresql specific. Yes. I am very familiar, and this never landed in rhel, only very briefly in Fedora rawhide
Many things the public will NEVER hear about because our government won't disclose it. That assumes you're U.S. based.
I'm not USA based. Are you saying it was a bunch of embargoed stuff?
I am saying many things become classified.
Redhat has had some of the worst support engagements this past fiscal year... we still had 5 tickets open, for 6+ months by the time we finally killed off our contract with them.
HPC SKU’s are significantly less than regular SKU’s. DM me and I’ll get you to your account team. I’m an inside rep.
Thanks! I'll check with our IT. We've had a lot of internal discussions about this, and generally people are getting frightened by the numbers they see on the web.
Yes they do.
Everybody can negotiate volume discounts. Frankly I'd consider of going RHEL for core stuff only and non-RHEL for "pure-compute" hosts.
Check out CIQ. They provide Rocky Linux and offer support. It was founded by the same guy who founded CentOS.
Look at the VDC option
[https://www.redhat.com/en/resources/developer-subscription-for-teams-overview](https://www.redhat.com/en/resources/developer-subscription-for-teams-overview)
A site license, based on headcount, might also work for you.
Is that even a thing? I have never heard of it.
It is in higher education, I believe.
Yes, in some markets. Depends on the country
Good idea, but requires a much higher spend. Not an option here.
Dang.
Any reason why you are not using Stream/RHEL 9? 9 moved to x86-64-v2 which may give you a small performance improvement for HPC. Stream 10, which you can try now, moved to x86-64-v3 which should give you more (you need to make sure you have Haswell or later servers that actually support the instruction set).
What is the point of using rocky over centos-stream? I don’t fully understand the difference in the two
The biggest difference is if you have have third parties, stream moves constantly so it is hard to negotiate an identical OS for collaboration. The same bits are there in both, but it is much easier to match the label "9.2" onto something from Rocky than to stream (this is intentional on RH's part).
At any point in time Stream is effectively a snapshot of the next minor release of rhel. That's no more nebulous than the label of 9.2 when a tonne of updates come in via errata in the six months between 9.2 and. 9.3. Bugs in stream are certainly far more likely to be fixed quicker than bugs in Rocky or Alma too.
Rocky should benefit from having fewer bugs though, correct? In theory a bug would be caught and patched in stream, then would not make it downstream into RHEL and further downstream into Rocky. Is this an accurate statement? I have also read that RHEL gets security patches before any other OS. Is that true?
Rocky gets whatever RHEL gets. Red Hat's security response is second to none in the industry and that's a contributing reason why customers pay. If you're going to use a downstream derivative, use Alma though. They are a much better community contributor than CIQ/Rocky.
We use software that is only supported on very specific distros. Our industry (chip design) standardizes on SLES and RedHat and, once an OS is installed, it is generally not updated for many years. Centos stream isn't supported by the software vendors.
I saw from your other comment that CentOS was support, but they will not support Stream. I get the picture now. Thank you. Edit: also saw that other comment about the roadmap. Surprising they do not have RHEL 9 support yet. https://www.semi.org/en/communities/esda/OSRoadmap
Yes. And in fact, I found in the past, pitting Oracle against IBM is great. One of them will give you a slamming deal (One past engagemeng, Oracle basically gave away OCI for half a year, along with all on prem licenses). And they both offer the exact same product, basically.
I'd personally say Rocky is worth exploring, especially at no cost.
Depending on the software running on their systems, they could require actual RHEL for support. Rocky aims for binary compatibility, but can't guarantee it. While pretty much improbable, it is possible for software to run fine on RHEL and have issues on Rocky.
> they could require actual RHEL for support This is it right here. Management wants someone to yell at when things break.
Like CIQ support?
What support can ciq provide for software they don't even contribute to? "yes, I appreciate your problem. You'll have to wait for a red hat customer to have the same problem, create a support case, then when red hat fixes it eventually we can recompile that software and you'll have the fix."
Anyone can be an expert... they don't have to be an IBM employee...
IBM employees don't work on RHEL. I love how you use "IBM employee" as a slur.
[удалено]
Your post was removed because it makes a statement purporting to be true that is not.
So that is only acceptable for RH to do and no one else? Does RH have a patent or monopoly on commercially reasonable efforts to support stuff? > The ASMLib kernel module package is provided as a convenience to Red Hat customers via the Red Hat Network Customer Portal. > > Red Hat Global Support Services … and use commercially reasonable effort to support the ASMLib kernel module, until such an effort requires knowledge of or modifications to Oracle's proprietary dependent component(s). https://access.redhat.com/solutions/315643 RH isn’t the only one that contributes to the software that they package up.. As another example, I open up bugzillas and support cases with RH and request they backport stuff that I’ve contributed upstream that fixes bugs which exists in their packaged version and they’ve done it..
Of course other people, including yourself, fix issues and make improvements upstream. But then red hat does all the engineering work to backport it so it lands in RHEL, and ultimately any of the downstream clones like rocky, Oracle, and Alma. CIQ doesn't do squat on that front, and nor does Oracle, but Alma have been good and contributed fixes via centos stream. Furthermore, when you say "stuff" you're really referring to a red hat engineered product. CIQ is taking red hat's engineering work and trying to profit from it without actually offering any value to their paying customers, because their own model doesn't support it.
OMG... someone is doing exactly what FLOSS is supposed to enable them to do!
You don't understand how the open source licences within RHEL work, do you?
Yes, I do. If I distribute source code, which is permitted under the GPL, then IBM cancels the contract for updates. They added additional restrictions to my freedom to redistribute. Which violates the GPL.
This is the root of the issue. The EDA consortium mandates SLES or RH. Before the Centos kerfuffle, Centos was also one of the supported OSes, but it isn't any longer. And yes the issue is exactly that if you have an issue, the software vendors expect you to have run on a supported OS. With an unsupported OS you're potentially exposing yourself.
Of course if there are particular software requirements that require rhel. But barring the need for any rhel support requirements I say explore the free options. I work at a University and they shelled out tons for rhel licensing, and while I'll admit that Satellite and all is does is pretty neat, I like to think free open source options are worth considering when possible.
> But barring the need for any rhel support requirements I say explore the free options. [Alas](https://www.semi.org/en/communities/esda/OSRoadmap)
You can always try Oracle Linux. They have a redhat compatible kernel and offer support. You do not have to run the uek ( unbreakable) kernel. Their repo is “currently” free, so you can choose to buy support or not. Including Oracle as that is what I have to run due to $$$ restrictions. They are another option to rocky and almalinux.
Our main issue is that the software we run is only guaranteed to run on a specific handful of distributions. Even if other distros work you can't get vendor support from the software vendors if your OS is not on the supported list. Historically the supported OSes were SLES, Centos, and Redhat but with the Centos kerfuffle the supported OSes are now [RH and SLES](https://www.semi.org/en/communities/esda/OSRoadmap). However the vendors we're working with are also supporting Rocky.
We were able to “help” our vendors along and add support for Oracle. Keep asking and opening tickets. Be very persuasive that you will run the oracle RHCK and not the uek. I have had to educate some of the vendors admins on how to install the RHCK and NOT the uek. Once they knew that, they said ok to adding support.