Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 2. Top new features
This section provides an overview of the top new features in this release of Red Hat OpenStack Platform (RHOSP).
2.1. Backup and restore
This section outlines the top new features related to backing up and restoring the Red Hat OpenStack Platform (RHOSP) undercloud and control plane nodes.
- Snapshot and revert
- The RHOSP snapshot and revert feature is based on the Logical Volume Manager (LVM) snapshot functionality and reverts an unsuccessful upgrade or update. Snapshots preserve the original disk state of your RHOSP cluster before performing an upgrade or an update. You can then remove or revert the snapshots depending on the results. If an upgrade completes successfully and you do not need the snapshots anymore, remove them from your nodes. If an upgrade fails, you can revert the snapshots, assess any errors, and start the upgrade procedure again. A revert leaves the disks of all the nodes exactly as they were when the snapshot was taken.
2.2. Bare Metal provisioning
This section outlines the top new features for the Red Hat OpenStack Platform (RHOSP) Bare Metal Provisioning service (ironic).
- LVM thin provisioning
-
In RHOSP 17.1, the LVM volumes installed by the
overcloud-hardened-uefi-full.qcow2whole disk overcloud image are now backed by a thin pool. By default, the volumes expand to consume the available physical storage, but they are not over-provisioned.
2.3. Compute
This section outlines the top new features for the Red Hat OpenStack Platform (RHOSP) Compute service (nova).
- Moving to Q35 default machine type
- The default machine type for each host architecture is Q35 for new RHOSP 17 deployments. The Q35 machine type provides several benefits and improvements, including live migration of instances between different RHEL 9.x minor releases, and native PCIe hotplug, which is faster than the ACPI hotplug used by the i440FX machine type. You can still use the i440FX machine type.
- Emulated virtual Trusted Platform Module (vTPM) devices for instances
- You can use TPM to enhance computer security and provide a chain of trust for virtualization. The emulated vTPM is a software-based representation of a physical TPM chip. An administrator can provide cloud users the ability to create instances that have vTPM devices.
- UEFI Secure Boot
- Cloud users can launch instances that are protected with UEFI Secure Boot when the overcloud contains UEFI Secure Boot Compute nodes. For information about creating an image for UEFI Secure Boot, see Creating an image for UEFI Secure Boot. For information about creating a flavor for UEFI Secure Boot, see "UEFI Secure Boot" in Flavor metadata.
- Ability to create instances that have a mix of dedicated and shared CPUs
- You can now create flavors that have a mixed CPU policy to enable your cloud users to create instances that have a mix of dedicated (pinned) and shared (unpinned) CPUs.
- VirtIO data path acceleration (VDPA) support for enterprise workloads
- On RHOSP deployments that are configured for OVS hardware offload and to use ML2/OVN, and that have Compute nodes with VDPA devices and drivers and Mellanox NICs, you can enable your cloud users to create instances that use VirtIO data path acceleration (VDPA) ports. For more information, see Configuring VDPA Compute nodes to enable instances that use VDPA ports and Creating an instance with a VDPA interface.
- Scheduler support for routed networks
-
On RHOSP deployments that use a routed provider network, you can now configure the Compute scheduler to filter Compute nodes that have affinity with routed network segments, and verify the network in placement before scheduling an instance on a Compute node. You can enable this feature by using the
NovaSchedulerQueryPlacementForRoutedNetworkAggregatesparameter.
2.4. Distributed Compute Nodes (DCN)
This section outlines the top new features for Distributed Compute Nodes (DCN).
- Framework for upgrades for Distributed Compute Node Architecture
- In RHOSP 17.1.3, Red Hat now supports upgrading edge deployed architectures from 16.2 to 17.1 using the framework for upgrades workflow.
2.5. Networking
This section outlines the top new features for the Red Hat OpenStack Platform (RHOSP) Networking service.
- Revert back to the OVS mechanism driver after failed migration to OVN
- Starting in RHOSP 17.1.3 you can revert a failed or interrupted migration if you first follow the proper backup steps and revert instructions. The reverted OVS environment might be altered from the original. For example, if you migrate to the OVN mechanism driver, then migrate an instance to another Compute node, and then revert the OVN migration, the instance will be on the original Compute node. Also, a revert operation interrupts connection to the data plane.
- HTTP/2 listener support for TLS-terminated load balancers
RHOSP 17.1.2 introduces support for TLS-terminated HTTP/2 listeners. HTTP/2 listeners enable you to improve the user experience by loading web pages faster and by employing the Application-Layer Protocol Negotiation (ALPN) TLS extension when load balancers negotiate with clients.
For more information about HTTP/2 listener support, see Creating a TLS-terminated load balancer with an HTTP/2 listener in Configuring load balancing as a service.
- Migration to OVN mechanism driver
Migrations from the OVS mechanism driver to the OVN mechanism driver were not supported in RHOSP 17.0 because upgrades to RHOSP 17.0 were not supported.
OVN migration is now supported in RHOSP 17.1 GA.
You have the choice of migrating from ML2/OVS in 16.2 or 17.1. In most cases, Red Hat recommends upgrading to RHOSP 17.1 before migrating to ML2/OVN, because of enhanced functionality and improved migration functions in RHOSP 17.1.
- Stateless security groups
This RHOSP release introduces support of the OpenStack stateless security groups API with the ML2/OVN mechanism driver. Stateless security groups are not supported by RHOSP deployments with the ML2/OVS mechanism driver.
A stateless security group can provide performance benefits because it bypasses connection tracking in the underlying firewall, providing an option to offload conntrack-related OpenFlow rules to hardware.
For more information about stateless security groups, see Configuring security groups.
- Security group logging
To monitor traffic flows and attempts into and out of an instance, you can create packet logs for security groups. Each log generates a stream of data about events and appends it to a common log file on the Compute host from which the instance was launched.
You can associate any port of an instance with one or more security groups and define one or more rules for each security group. For example, you can create a rule to allow inbound SSH traffic to any instance in a security group named finance. You can create another rule in the same security group to allow instances in that group to send and respond to ICMP (ping) messages.
Then you can create packet logs to record combinations of packet flow events with the related security groups.
- Quality of Service (QoS) for egress on hardware offloaded ports
- Starting with RHOSP 17.1, in ML2/OVN deployments, you can enable minimum bandwidth and bandwidth limit egress policies for hardware offloaded ports. You cannot enable ingress policies for hardware offloaded ports. For more information, see Configuring the Networking service for QoS policies.
- Open vSwitch (OVS) Poll Mode Driver (PMD) Auto Load Balance
Starting in RHOSP 17.1, OVS PMD moves from technology preview to full support. You can use Open vSwitch (OVS) Poll Mode Driver (PMD) threads to perform the following tasks for user space context switching:
- Continuous polling of input ports for packets.
- Classifying received packets.
Executing actions on the packets after classification.
For more information, see Configuring DPDK parameters for node provisioning.
2.6. Network Functions Virtualization
This section outlines the top new features for Red Hat OpenStack Platform (RHOSP) Network Functions Virtualization (NFV).
- OVS and OVN TC Flower offload with Conntrack
-
In RHOSP 17.1, connection tracking (conntrack) hardware offloading is supported for ML2/OVS and ML2/OVN with TC Flower. For the conntrack module to offload openflow flows to hardware, you must enable security groups and port security on
switchdevports. For more information, see Configuring OVS TC-flower hardware offload.
2.7. Security
This section outlines the top new features for security components in Red Hat OpenStack Platform (RHOSP).
- FIPS 140-3 compatibility is now fully supported
- You can now enable FIPS 140-3 compatibility mode with RHOSP.
- SRBAC is now fully supported
- You can now enable secure role-based access control in RHOSP.
2.8. Storage
This section outlines the top new features for the Red Hat OpenStack Platform (RHOSP) storage services.
- Upgrade Red Hat Ceph Storage 5 to 6
Upgrading your Red Hat Ceph Storage cluster from version 5 to version 6 is now supported as a step in upgrading your RHOSP to RHOSP 17.1.2.
Upgrading directly from Red Hat Ceph Storage version 4 to version 6 is not supported. If you are currently using Red Hat Ceph Storage version 4, you must upgrade to Red Hat Ceph Storage version 5 before upgrading to Red Hat Ceph Storage version 6.
For more information about this procedure see, Framework for upgrades (16.2 to 17.1).
- Red Hat Ceph Storage 6
- If you deploy greenfield RHOSP 17.1 with Red Hat Ceph Storage (RHCS), RHOSP is deployed with RHCS 6.1. RHCS 6 is also supported as an external Red Hat Ceph Storage cluster.
- Red Hat Ceph Storage 7
- RHOSP 17.1.3 adds support for RHCS 7 as an external Red Hat Ceph Storage cluster.
- Availability zones for file shares
- In RHOSP 17.1, cloud administrators can configure availability zones for Shared File Systems service (manila) back ends.
- Manage/unmanage file shares
- In RHOSP 17.1, cloud administrators can bring shares that are created outside the Shared File Systems service (manila) under the management of the Shared File Systems service and remove shares from the Shared File Systems service without deleting them. The CephFS driver does not support this feature. You can use this manage/unmanage functionality when commissioning, decommissioning, or migrating storage systems, or to take shares offline temporarily for maintenance.
- Block Storage supports NVMe over TCP back ends
- In RHOSP 17.1, the Block Storage service (cinder) supports NVMe over TCP (NVMe/TCP) drivers, for Compute nodes that are running RHEL 9.
- Active-active configuration for the Block Storage backup service
- In RHOSP 17.1, the Block Storage (cinder) backup service is deployed using an active-active configuration. For more information, see Deploying your active-active Block Storage backup service.
- Other Block Storage backup service improvements
- In RHOSP 17.1, the Block Storage (cinder) backup service supports the S3 back end and the zstd data compression algorithm. For more information, see Backup repository back-end configuration and Block Storage backup service configuration.
- New Dell PowerFlex and PowerStore drivers
- The Shared File Systems service (manila) now includes back-end drivers to provision and manage NFS shares on Dell PowerFlex storage systems, and NFS and CIFS shares on Dell PowerStore storage systems. The use of these drivers is supported when the vendor publishes certification on the Ecosystem Catalog.
2.9. Upgrades and updates
This section outlines the top new features for Red Hat OpenStack Platform (RHOSP) upgrades and updates.
- Pre-update and post-update validations
- In RHOSP 17.1.1, pre-update and post-update validations are now supported. With this enhancement, you can verify the requirements and functionality of your undercloud before you begin a minor update of your environment. You can then verify the overcloud functionality after you perform a minor update. For more information, see Validating RHOSP before the undercloud update and Validating RHOSP after the overcloud update in Performing a minor update of Red Hat OpenStack Platform.
- Multi-RHEL
- In RHOSP 17.1, you can upgrade a portion of your Compute nodes to RHEL 9.2 while the rest of your Compute nodes remain on RHEL 8.4. This is referred to as a Multi-RHEL environment. For more information about the benefits and limitations of a Multi-RHEL environment, see Planning for a Compute node upgrade in Framework for upgrades (16.2 to 17.1).
2.10. Technology previews
This section provides an overview of the top new technology previews in this release of Red Hat OpenStack Platform (RHOSP).
For more information on the support scope for features marked as technology previews, see Technology Preview Features Support Scope.
- Router flavors
- The router flavors feature lets you define router flavors and use them to create custom virtual routers. For more information, see Creating custom virtual routers with router flavors.
