7 ms·

Red Hat Introduces Arm Server Support for Red Hat Enterprise Linux

156 points by cpeterso 9y ago

reacweb 9y ago
I had the impression that CENTOS7.3 was available on baremetal ARM64 on scaleway since a long time. Is it really new ? Maybe I do not understand what this announce is about.
- vbezhenar 9y ago
  CentOS and RHEL are different distributions. CentOS supports 32-bit x86 architecture, for example, while RHEL only supports x64.
  - deleted 9y ago
    [deleted]
  - freedomben 9y ago
    My understanding was that CentOS is simply a rebuild of all RHEL packages with the Red Hat branding removed. If there's different arch support tho, then there's probably more to it than I thought.
    - vbezhenar 9y ago
      Well, basically that's right and if they're rebuilding RHEL packages anyway, they can just rebuild them for more architectures. Of course that implies that important packages actually support those architectures. RHEL offers more than just binary distribution, they should support their product, so they decided to go with less architectures than theoretically possible. That's how I see it.
- mattl 9y ago
  I guess it's now supported. You can buy a support contract from Red Hat and when your ARM server has a problem, they'll help.
- invokestatic 9y ago
  RHEL 7 only supported x86_64, so CentOS 7 only "officially" supports x86_64. While AArch64, i386, and other arch builds are available from the AltArch SIG, they aren't maintained by the core. With RHEL 7 supporting AArch64 after this announcement, I'd assume CentOS will follow suit.
  - jwildeboer 9y ago
    RHEL 7 dropped i386. But of course also continues to support Power and s390 (IBM mainframe).
- gtirloni 9y ago
  Supported platforms: CentOS 5/6/7: https://wiki.centos.org/FAQ/General#head-059f2f807ebb83e93f272a8cf4c287f92831927e https://wiki.centos.org/FAQ/General#head-059f2f807ebb83e93f2... RHEL 7.4: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.4_release_notes/chap-red_hat_enterprise_linux-7.4_release_notes-architectures https://access.redhat.com/documentation/en-us/red_hat_enterp...
  - chowyuncat 9y ago
    CentOS 5 and 6 are not supported based on the link you provided.
- jononor 9y ago
  The new is that you can now get a support contract from RedHat for RHEL on ARM64. It has been possible to run it for a long time without such support.
- andreiw 9y ago
  Enterprise-level support vs. use-at-your-own-risk science project.
wyldfire 9y ago
> Our goal was to develop a single operating platform across multiple 64-bit ARMv8-A server-class SoCs from various suppliers while using the same sources to build user functionality and consistent feature set that enables customers to deploy across a range of server implementations while maintaining application compatibility. I wonder how successful this was. Previously, all x86 CPUs (including x86_64) would bootstrap into the same mode from 1970s CPUs and preserve all the functionality from the original ISA (we still talk to the RTC via inb/outb, e.g.). I suppose this changed a little bit after EFI/UEFI was offered? ARM CPUs were not bound to this backwards compatibility so AFAIK every vendor could implement their own bootstrapping functionality, and therefore having a single bootloader was challenging/impossible? uboot is a popular basis solution but IIRC everyone provides their own tweak to suit their SoC. Does TrustZone normalize the bootstrapping process for ARM devices such that we can write a single bootloader binary and expect it to work the same way across ARM server SoCs?
- kpxxx 9y ago
  How is uboot fundamentally different than BIOS or UEFI/EFI? It's not like all the PC clones through the ages had the same bootup sequence for RAM and peripheral init.
  - wyldfire 9y ago
    It's different because uboot typically resides on what I would refer to as "end-user" storage. If it booted from an on-chip or on-board flash/ROM device and then loaded content from the end-user's device, you're right -- in that case it would be remarkably similar to BIOS/UEFI.
  - StillBored 9y ago
    uboot is more striped down than traditional INT call based BIOS because it doesn't provide a boot API, or any "runtime" services. Basically it does little more than early hardware init, and jump to kernel image. For example it doesn't have an execution environment for option roms. Its great if your shipping a device with a fixed hardware configuration and kernel, but what ends up happening is that it fails to provide "platform" abstractions to the kernel. The result is constant churn at the platform level because even simple operations like "I want to boot this kernel/configuration on the next boot" cannot be communicated from the OS/kernel to the firmware in a standard way. UEFI OTOH, is a bad combination of BIOS and openfirmware, but has standardized an execution environment that allows device vendors to build standalone "driver" packages that enable booting off plug-in network boards/RAID controllers/graphical display/etc.. Those drivers can then either be installed in the firmware or provided on option roms. There is a higher level API so that grub/whatever can say read a config file written by the OS without having to know the underlying technology. Basically uboot is great for devices that could do without firmware and just boot a kernel, uefi is useful if you want to have a standard environment usable by a generic kernel/OS across a wide range of devices because combined with ACPI AML/etc it abstracts away much of the underlying platform management.
SEJeff 9y ago
Anyone know where one can buy an ARM server to run this on?
- mtgx 9y ago
  Cavium and Qualcomm sell the "top" Arm servers. There's also AppliedMicro but not sure what kind of future they have there.
- chr15p 9y ago
  Shamelessly stealing links from the discussion on https://lwn.net/Articles/738898/ https://lwn.net/Articles/738898/ https://www.avantek.co.uk/arm-server-h270-t70/ https://www.avantek.co.uk/arm-server-h270-t70/] http://www.asacomputers.com/Cavium-ThunderX-ARM.html http://www.asacomputers.com/Cavium-ThunderX-ARM.html https://system76.com/servers/starling https://system76.com/servers/starling https://www.deltacomputer.com/hochleistungs-rechner/stand.. https://www.deltacomputer.com/hochleistungs-rechner/stand...
  - flyinghamster 9y ago
    I hope prices on high-performance ARM hardware can come down a bit. Currently there's nothing between Chromebooks and $3000+ servers. On the other hand, if I were in the market for a high-end server, it looks pretty competitive vs. Xeon or Epyc. Any good benchmarks out there?
    - jabl 9y ago
      HPC stuff: https://www.nextplatform.com/2017/11/13/arm-benchmarks-show-hpc-ripe-processor-shakeup/ https://www.nextplatform.com/2017/11/13/arm-benchmarks-show-...
    - yazr 9y ago
      Full 96 core baremetal ARM64 servers from $0.50 per hour: https://www.packet.net/bare-metal/servers/type-2a/ https://www.packet.net/bare-metal/servers/type-2a/ Or Low end VM's from 3€ month: https://www.scaleway.com/armv8-cloud-servers/ https://www.scaleway.com/armv8-cloud-servers/
ComputerGuru 9y ago
Does anyone know the current ARM (equipment cost + ~0.9 utilization power costs) amortized over, say, three or five years compares to the latest generation of Xeon and Epyc?
- andreiw 9y ago
  https://www.qualcomm.com/news/onq/2017/11/08/qualcomm-centriq-2400-worlds-first-10nm-server-processor https://www.qualcomm.com/news/onq/2017/11/08/qualcomm-centri...
Daviey 9y ago
ARM64 was released on Debian and Ubuntu 5 or 6 years ago.. Why has it taken RedHat so long? They were part of the same ARM server club.

156 points by cpeterso 9y ago

I had the impression that CENTOS7.3 was available on baremetal ARM64 on scaleway since a long time. Is it really new ? Maybe I do not understand what this announce is about.

vbezhenar 9y ago
CentOS and RHEL are different distributions. CentOS supports 32-bit x86 architecture, for example, while RHEL only supports x64.
- deleted 9y ago
  [deleted]
- freedomben 9y ago
  My understanding was that CentOS is simply a rebuild of all RHEL packages with the Red Hat branding removed. If there's different arch support tho, then there's probably more to it than I thought.
  - vbezhenar 9y ago
    Well, basically that's right and if they're rebuilding RHEL packages anyway, they can just rebuild them for more architectures. Of course that implies that important packages actually support those architectures. RHEL offers more than just binary distribution, they should support their product, so they decided to go with less architectures than theoretically possible. That's how I see it.
mattl 9y ago
I guess it's now supported. You can buy a support contract from Red Hat and when your ARM server has a problem, they'll help.
invokestatic 9y ago
RHEL 7 only supported x86_64, so CentOS 7 only "officially" supports x86_64. While AArch64, i386, and other arch builds are available from the AltArch SIG, they aren't maintained by the core. With RHEL 7 supporting AArch64 after this announcement, I'd assume CentOS will follow suit.
- jwildeboer 9y ago
  RHEL 7 dropped i386. But of course also continues to support Power and s390 (IBM mainframe).
gtirloni 9y ago
Supported platforms: CentOS 5/6/7: https://wiki.centos.org/FAQ/General#head-059f2f807ebb83e93f272a8cf4c287f92831927e https://wiki.centos.org/FAQ/General#head-059f2f807ebb83e93f2... RHEL 7.4: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.4_release_notes/chap-red_hat_enterprise_linux-7.4_release_notes-architectures https://access.redhat.com/documentation/en-us/red_hat_enterp...
- chowyuncat 9y ago
  CentOS 5 and 6 are not supported based on the link you provided.
jononor 9y ago
The new is that you can now get a support contract from RedHat for RHEL on ARM64. It has been possible to run it for a long time without such support.
andreiw 9y ago
Enterprise-level support vs. use-at-your-own-risk science project.

wyldfire 9y ago

> Our goal was to develop a single operating platform across multiple 64-bit ARMv8-A server-class SoCs from various suppliers while using the same sources to build user functionality and consistent feature set that enables customers to deploy across a range of server implementations while maintaining application compatibility. I wonder how successful this was. Previously, all x86 CPUs (including x86_64) would bootstrap into the same mode from 1970s CPUs and preserve all the functionality from the original ISA (we still talk to the RTC via inb/outb, e.g.). I suppose this changed a little bit after EFI/UEFI was offered? ARM CPUs were not bound to this backwards compatibility so AFAIK every vendor could implement their own bootstrapping functionality, and therefore having a single bootloader was challenging/impossible? uboot is a popular basis solution but IIRC everyone provides their own tweak to suit their SoC. Does TrustZone normalize the bootstrapping process for ARM devices such that we can write a single bootloader binary and expect it to work the same way across ARM server SoCs?

kpxxx 9y ago
How is uboot fundamentally different than BIOS or UEFI/EFI? It's not like all the PC clones through the ages had the same bootup sequence for RAM and peripheral init.
- wyldfire 9y ago
  It's different because uboot typically resides on what I would refer to as "end-user" storage. If it booted from an on-chip or on-board flash/ROM device and then loaded content from the end-user's device, you're right -- in that case it would be remarkably similar to BIOS/UEFI.
- StillBored 9y ago
  uboot is more striped down than traditional INT call based BIOS because it doesn't provide a boot API, or any "runtime" services. Basically it does little more than early hardware init, and jump to kernel image. For example it doesn't have an execution environment for option roms. Its great if your shipping a device with a fixed hardware configuration and kernel, but what ends up happening is that it fails to provide "platform" abstractions to the kernel. The result is constant churn at the platform level because even simple operations like "I want to boot this kernel/configuration on the next boot" cannot be communicated from the OS/kernel to the firmware in a standard way. UEFI OTOH, is a bad combination of BIOS and openfirmware, but has standardized an execution environment that allows device vendors to build standalone "driver" packages that enable booting off plug-in network boards/RAID controllers/graphical display/etc.. Those drivers can then either be installed in the firmware or provided on option roms. There is a higher level API so that grub/whatever can say read a config file written by the OS without having to know the underlying technology. Basically uboot is great for devices that could do without firmware and just boot a kernel, uefi is useful if you want to have a standard environment usable by a generic kernel/OS across a wide range of devices because combined with ACPI AML/etc it abstracts away much of the underlying platform management.

SEJeff 9y ago

Anyone know where one can buy an ARM server to run this on?

mtgx 9y ago
Cavium and Qualcomm sell the "top" Arm servers. There's also AppliedMicro but not sure what kind of future they have there.
chr15p 9y ago
Shamelessly stealing links from the discussion on https://lwn.net/Articles/738898/ https://lwn.net/Articles/738898/ https://www.avantek.co.uk/arm-server-h270-t70/ https://www.avantek.co.uk/arm-server-h270-t70/] http://www.asacomputers.com/Cavium-ThunderX-ARM.html http://www.asacomputers.com/Cavium-ThunderX-ARM.html https://system76.com/servers/starling https://system76.com/servers/starling https://www.deltacomputer.com/hochleistungs-rechner/stand.. https://www.deltacomputer.com/hochleistungs-rechner/stand...
- flyinghamster 9y ago
  I hope prices on high-performance ARM hardware can come down a bit. Currently there's nothing between Chromebooks and $3000+ servers. On the other hand, if I were in the market for a high-end server, it looks pretty competitive vs. Xeon or Epyc. Any good benchmarks out there?
  - jabl 9y ago
    HPC stuff: https://www.nextplatform.com/2017/11/13/arm-benchmarks-show-hpc-ripe-processor-shakeup/ https://www.nextplatform.com/2017/11/13/arm-benchmarks-show-...
  - yazr 9y ago
    Full 96 core baremetal ARM64 servers from $0.50 per hour: https://www.packet.net/bare-metal/servers/type-2a/ https://www.packet.net/bare-metal/servers/type-2a/ Or Low end VM's from 3€ month: https://www.scaleway.com/armv8-cloud-servers/ https://www.scaleway.com/armv8-cloud-servers/

ComputerGuru 9y ago

Does anyone know the current ARM (equipment cost + ~0.9 utilization power costs) amortized over, say, three or five years compares to the latest generation of Xeon and Epyc?

andreiw 9y ago
https://www.qualcomm.com/news/onq/2017/11/08/qualcomm-centriq-2400-worlds-first-10nm-server-processor https://www.qualcomm.com/news/onq/2017/11/08/qualcomm-centri...

Daviey 9y ago

ARM64 was released on Debian and Ubuntu 5 or 6 years ago.. Why has it taken RedHat so long? They were part of the same ARM server club.