3.5. Red Hat OpenStack Platform 17.1 GA - 2023년 8월 17일

이번 업데이트 이전에는 삭제 후에도 베어 메탈 오버클라우드 노드가 metalsmith 툴에 의해 활성으로 나열되었습니다. 이는 노드 이름 지정 체계가 오버클라우드 역할 이름 지정 체계와 겹치는 환경에서 발생하여 배포 취소 중에 잘못된 노드가 프로비저닝되지 않을 수 있었습니다. metalsmith 툴에서는 먼저 할당 이름(hostname)을 사용하여 베어 메탈 노드의 상태를 조회하기 때문에, 삭제된 노드를 계속 활성 상태로 찾는 경우가 있었습니다.

이번 업데이트를 통해 이제 프로비저닝 해제할 노드가 할당 이름(hostname)으로 참조되므로 올바른 노드가 항상 프로비저닝되지 않습니다. 노드는 호스트 이름이 없는 경우에만 노드 이름에서 참조됩니다.

이번 업데이트 이전에는 데이터베이스가 대상 호스트 세부 정보로 업데이트되지 않았기 때문에 실시간 마이그레이션이 실패할 수 있었습니다.

이번 업데이트를 통해 실시간 마이그레이션 중에 데이터베이스의 인스턴스 호스트 값이 대상 호스트로 설정됩니다.

이번 업데이트 이전에는 Load Balancer 가상 IP(VIP)와 연결된 유동 IP(FIP)를 사용한 경우 OVN(Open Virtual Network) 로드 밸런서 상태 점검이 수행되지 않았으며, FIP가 사용된 경우 트래픽이 Error 상태의 멤버로 리디렉션되었습니다.

이번 업데이트를 통해 Load Balancer 가상 IP(VIP)와 연결된 유동 IP(FIP)를 사용하는 경우 FIP에 대해 생성된 새 로드 밸런서 상태 점검이 있고 트래픽이 Error 상태의 멤버로 리디렉션되지 않습니다.

이번 업데이트 이전에는 /home/stack/config-download/overcloud/cephadm 의 cephadm-ansible 로그가 순환되지 않았습니다. 모든 오버클라우드 배포에 cephadm_command.log 가 추가되었으며 크기가 증가했습니다. 또한 모든 openstack overcloud ceph spec 작업에 대해 /home/stack/ansible.log 로그가 순환되지 않았습니다.

이제 모든 오버클라우드 배포에 대해 날짜 로그가 생성되고 다음 형식의 모든 Ceph 사양 작업이 생성됩니다.

이번 업데이트 이전에는 Compute 서비스(nova)에서 VMI(가상 머신 디스크) 이미지 파일의 콘텐츠를 신뢰하지 않았습니다. 특수하게 조작된 VMDK 이미지를 사용하면 호스트 파일 시스템의 중요한 파일을 해당 VMDK 이미지로 부팅한 게스트에 노출할 수 있었습니다. 이번 업데이트를 통해 Compute 서비스 신뢰에서 VMDK 파일을 확인하고 누출 동작이 의존하는 VMDK 기능을 금지합니다. 특수하게 조작된 VMDK 파일을 사용하여 중요한 호스트 파일 시스템 콘텐츠를 더 이상 누출할 수 없습니다. 이 버그 수정에서는 CVE-2022-47951 을 해결합니다.

이번 업데이트 이전에는 rgw_max_attr_size 의 기본값이 256으로 되어 대규모 이미지를 업로드할 때 OpenStack에 OpenShift에 대한 문제가 발생했습니다. 이번 업데이트를 통해 rgw_max_attr_size 의 기본값은 1024입니다.

오버클라우드 배포에 포함하는 환경 파일에 다음 구성을 추가하여 값을 변경할 수 있습니다.

parameters_default:
  CephConfigOverrides:
    rgw_max_attr_size: <new value>

이번 업데이트 이전에는 OVS 인터페이스의 네트워크 구성에서 회귀 문제가 네트워크 성능에 부정적인 영향을 미쳤습니다. 이번 업데이트를 통해 Windows 이외의 인스턴스의 OVS 인터페이스에서 네트워크 성능을 개선하도록 os-vif OVS 플러그인이 개선되었습니다.

이번 업데이트 이전에는 RHOSP 동적 라우팅을 사용하는 RHOSP 17.1 환경에서 OVN BGP 에이전트가 사용하는 Autonomous System Number (ASN)의 기본값이 FRRouting (FRRouting)에서 사용하는 ASN과 다른 알려진 문제가 있었습니다.

17.1 GA에서 이 문제가 해결되었습니다. FrrOvnBgpAgentAsn 및 FrrBgpAsn 기본값이 유효하며 수정할 필요 없이 사용할 수 있습니다.

이번 릴리스 이전에는 hw_machine_type 이미지 속성이 없는 인스턴스의 머신 유형에서 하드 재부팅 또는 마이그레이션 후 새로 구성된 시스템 유형을 사용하므로 RHOSP 배포의 수명 동안 NovaHWMachineType 을 변경할 수 없었습니다. 인스턴스의 기본 머신 유형을 변경하면 인스턴스의 내부 ABI가 손상될 수 있습니다.

이번 릴리스에서는 인스턴스를 시작할 때 Compute 서비스가 인스턴스의 시스템 메타데이터 내에 인스턴스 시스템 유형을 기록합니다. 따라서 기존 인스턴스의 머신 유형에 영향을 주지 않고 RHOSP 배포 수명 동안 NovaHWMachineType 을 변경할 수 있습니다.

이번 업데이트에서는 보안 그룹 로깅 기능이 도입되었습니다. 트래픽 흐름을 모니터링하고 인스턴스로의 시도를 모니터링하려면 보안 그룹에 대한 네트워킹 서비스 패킷 로깅을 구성할 수 있습니다.

인스턴스 포트를 하나 이상의 보안 그룹과 연결하고 각 보안 그룹에 대해 하나 이상의 규칙을 정의할 수 있습니다. 예를 들어, financial 보안 그룹의 모든 인스턴스에 대한 인바운드 ssh 트래픽을 삭제하는 규칙을 생성할 수 있습니다. 해당 그룹의 인스턴스가 ICMP(ping) 메시지를 보내고 응답할 수 있도록 다른 규칙을 만들 수 있습니다.

그런 다음 수락 및 삭제된 패킷 흐름의 조합을 기록하도록 패킷 로깅을 구성할 수 있습니다.

상태 저장 및 상태 비저장 보안 그룹 모두에 보안 그룹 로깅을 사용할 수 있습니다.

기록된 이벤트는 인스턴스를 호스팅하는 컴퓨팅 노드에 저장됩니다. 파일 /var/log/containers/stdouts/ovn_controller.log.

이번 개선된 기능을 통해 클라우드 사용자는 인스턴스를 호스팅하는 컴퓨팅 노드에 연결할 수 없기 때문에 "ACTIVE" 인스턴스에 액세스할 수 없는 이유가 있는지 확인하는 데 도움이 됩니다. RHOSP 관리자는 호스트 컴퓨팅 노드에 연결할 수 없는 경우 openstack show server details 명령을 실행할 때 클라우드 사용자에게 host_status 필드에 상태를 제공하는 사용자 정의 정책을 활성화하도록 다음 매개변수를 구성할 수 있습니다.

이번 업데이트를 통해 별도의 셀 데이터베이스에서 리소스를 계산하는 대신 API 데이터베이스의 인스턴스 매핑에서 리소스 사용량과 인스턴스에 대한 배치를 쿼리하여 코어 및 RAM의 할당량 사용량을 계산하도록 RHOSP 배포를 구성할 수 있습니다. 이렇게 하면 다중 셀 환경에서 임시 셀 중단 또는 셀 성능이 저하될 수 있습니다.

배치에서 할당량 사용량을 계산하려면 다음 구성 옵션을 설정합니다.

parameter_defaults:
  ControllerExtraConfig:
    nova::config::nova_config:
      quota/count_usage_from_placement:
        value: 'True'

이번 업데이트를 통해 백업 워크플로에서 검증 프레임워크를 사용하고 프로시저를 복원하여 복원된 시스템의 상태를 확인할 수 있습니다. 다음 검증이 포함됩니다.

이번 개선된 기능을 통해 클라우드 관리자는 Shared File Systems 서비스(manila) 백엔드 스토리지를 구성할 때 director를 통해 스토리지 백엔드를 통해 가용성 영역(AZ)을 지정할 수 있습니다.

이번 업데이트를 통해 관리자는 AZ 주석을 사용하여 스토리지 프로비저닝 요청을 논리적으로 분리하고 장애 도메인을 표시할 수 있습니다. 관리자가 구성한 AZ는 공유 파일 시스템 서비스에 의해 최종 사용자에게 노출됩니다. 최종 사용자는 요구 사항에 따라 특정 AZ에 워크로드를 예약하도록 요청할 수 있습니다. 여러 스토리지 백엔드를 구성할 때 관리자는 모든 백엔드에 대해 단일 AZ를 사용하지 않는 대신 각 백엔드를 다른 AZ에 태그를 지정할 수 있습니다.

director에는 스토리지 AZ를 나타내는 새로운 옵션이 있습니다. 각 옵션은 지원되는 스토리지 백엔드 드라이버에 해당합니다. AZ에 대한 자세한 내용은 영구 스토리지 구성을 참조하십시오.

이번 업데이트를 통해 각 펜싱 리소스를 정의하여 tripleo를 통해 다른 펜싱 장치와 마찬가지로 sbd 를 사용하는 fence_watchdog 을 구성할 수 있습니다.

parameter_defaults:
  EnableFencing: true
  FencingConfig:
    devices:
    - agent: fence_watchdog
      host_mac: "52:54:00:74:f7:51"

Operator는 sbd 를 활성화하고 워치독 시간 초과를 설정해야 합니다.

parameter_defaults:
  ExtraConfig:
    pacemaker::corosync::enable_sbd: true
    tripleo::fencing::watchdog_timeout: 20

이번 개선된 기능을 통해 overcloud-hardened-uefi-full에서 설치한 LVM 볼륨을 사용할 수 있습니다.qcow2 전체 디스크 오버클라우드 이미지는 이제 씬 풀에서 지원합니다. 사용 가능한 물리적 스토리지를 사용하도록 볼륨이 계속 증가되지만 기본적으로 과도하게 프로비저닝되지 않습니다.

씬 프로비저닝된 논리 볼륨의 이점:

이번 업데이트에서는 neutron-remove-duplicated-port-bindings 스크립트가 도입되어 실패한 실시간 마이그레이션 처리에 영향을 미치는 문제를 해결합니다.

실시간 마이그레이션이 실패하면 Compute 서비스(Nova)가 마이그레이션을 되돌립니다. 마이그레이션 취소는 데이터베이스 또는 대상 계산 노드에서 생성된 오브젝트를 삭제하는 것을 의미합니다.

그러나 실패한 실시간 마이그레이션 후 포트가 중복 포트 바인딩으로 남아 있는 경우도 있었습니다.

neutron-remove-duplicated-port-bindings 스크립트는 중복 포트 바인딩을 찾아 비활성 바인딩을 삭제합니다. 실시간 마이그레이션 실패로 인해 중복 포트 바인딩이 발생하는 경우 스크립트를 실행할 수 있습니다.

이번 개선된 기능을 통해 Operator는 Pacemaker 관리 가상 IP(VIP)에 대해 run_arping 기능을 활성화하여 클러스터에서 중복 IP를 선점하여 확인할 수 있습니다.

이렇게 하려면 환경 파일에 다음 구성을 추가해야 합니다.

  ExtraConfig:
    pacemaker::resource::ip::run_arping: true

중복이 발견되면 /var/log/pacemaker/pacemaker.log 파일에 다음 오류가 기록됩니다.

Sep 07 05:54:54  IPaddr2(ip-172.17.3.115)[209771]:    ERROR: IPv4 address collision 172.17.3.115 [DAD]
Sep 07 05:54:54  IPaddr2(ip-172.17.3.115)[209771]:    ERROR: Failed to add 172.17.3.115

이번 업데이트를 통해 프로젝트 및 사용자 이름 필드를 발신 데이터 수집 서비스(ceilometer) 메트릭에 추가할 수 있습니다. 이전에는 클라우드 관리자가 테넌트를 식별하기 위해 프로젝트 및 사용자의 UUID를 사용해야 했습니다. 이제 UUID가 아닌 프로젝트 및 사용자 이름 목록을 볼 수 있습니다.

이번 개선된 기능을 통해 사용자는 RHOSP 16.2에서 RHOSP 17.1로 업그레이드하고 RHEL 9를 실행하는 노드와 함께 컴퓨팅 노드의 RHEL (Red Hat Enterprise Linux) 8 기반 운영 체제를 유지할 수 있습니다.

컨트롤 플레인 노드 및 스토리지 노드를 업그레이드해야 합니다. 기본 동작은 명시적으로 달리 구성되지 않는 한 모든 노드가 RHEL 9로 업그레이드된다는 것입니다.

RHOSP 네트워킹 환경에서는 VM 인스턴스를 생성할 때 인스턴스를 vport(가상 포트)에 바인딩하지 마십시오. 대신 IP 주소가 다른 포트의 허용된 주소 쌍의 멤버가 아닌 포트를 사용합니다.

vport를 인스턴스에 바인딩하면 인스턴스가 생성되지 않고 다음과 유사한 오류 메시지가 생성됩니다.

WARNING nova.virt.libvirt.driver [req-XXXX - - - default default] [instance: XXXXXXXXX] Timeout waiting for [('network-vif-plugged', 'XXXXXXXXXX')] for instance with vm_state building and task_state spawning.: eventlet.timeout.Timeout: 300 seconds

IPv6를 사용하여 OVN 메커니즘 드라이버로 마이그레이션하는 동안 인스턴스에 연결하는 경우 ML2/OVS 서비스가 중지되면 인스턴스에 대한 연결이 최대 몇 분 동안 중단될 수 있습니다. 이를 방지하려면 대신 IPv4를 사용합니다.

IPv6의 라우터 알림 데몬은 OVN 메커니즘 드라이버로 마이그레이션하는 동안 중지됩니다. radvd 가 중지되지만 라우터 알림은 더 이상 브로드캐스트되지 않습니다. 이 브로드캐스트 중단으로 인해 IPv6를 통한 인스턴스 연결이 손실됩니다. 새 ML2/OVN 서비스가 시작되면 IPv6 통신이 자동으로 복원됩니다.

잠재적인 중단을 방지하려면 대신 IPv4를 사용합니다.

현재 ML2/OVS 배포에서 OVS(Open vSwitch)는 skb_priority,skb_mark 또는 출력 대기열 필드가 설정된 OpenFlow 규칙 오프로드를 지원하지 않습니다. 이러한 필드는 virtio 포트에 대한 QoS(Quality of Service) 지원에 필요합니다.

virtio 포트에 대한 최소 대역폭 규칙을 설정하면 Networking 서비스(neutron) OVS 에이전트는 이 포트의 트래픽을 패킷 마크 필드로 표시합니다. 이 트래픽은 오프로드할 수 없으며 다른 포트의 트래픽에 영향을 미칩니다. 대역폭 제한 규칙을 설정하면 모든 트래픽이 기본 0 큐로 표시됩니다. 즉, 트래픽을 오프로드할 수 없습니다.

해결방법: 환경에 OVS 하드웨어 오프로드 포트가 포함된 경우 하드웨어 오프로드가 필요한 노드에 패킷 표시를 비활성화합니다. 패킷 표시를 비활성화하면 virtio 포트에 대한 속도 제한 규칙을 설정할 수 없습니다. 그러나 고유 서비스 코드 포인트(DSCP) 표시 규칙을 계속 사용할 수 있습니다.

구성 파일에서 disable_packet_marking 플래그를 true 로 설정합니다. 구성 파일을 편집할 때 neutron_ovs_agent 컨테이너를 다시 시작해야 합니다. 예를 들면 다음과 같습니다.

$ cat `/var/lib/config-data/puppet-generated/neutron/etc/neutron/plugins/ml2/openvswitch_agent.ini`
  [ovs]
  disable_packet_marking=True

RHOSP 17.1에서 DNS 서비스(designate)가 배포되면 오버클라우드가 삭제될 때 언더클라우드에 생성된 Networking 서비스(neutron) 포트가 삭제되지 않습니다. 이러한 포트는 오버클라우드가 DNS 서비스를 사용하거나 사용하지 않고 다시 생성할 때 운영 문제가 발생하지 않습니다.

해결방법: 오버클라우드를 삭제한 후 openstack port delete 명령을 사용하여 포트를 수동으로 삭제합니다.

BGP 동적 라우팅을 사용하는 RHOSP 17.1 환경에서는 현재 부동 IP(FIP) 포트 전달이 실패하는 알려진 문제가 있습니다.

FIP 포트 전달이 구성되면 FIP와 동일한 대상 IP를 사용하여 특정 대상 포트로 전송된 패킷은 RHOSP Networking 서비스(neutron) 포트에서 내부 IP로 리디렉션됩니다. 이는 사용되는 프로토콜(TCP, UDP 등)에 관계없이 발생합니다.

BGP 동적 라우팅이 구성되면 FIP 포트 전달을 수행하는 데 사용되는 FIP로의 경로가 노출되지 않으며 이러한 패킷은 최종 대상에 도달할 수 없습니다.

현재는 해결방법이 없습니다.

Pacemaker에서 제어하는 ceph-nfs 리소스에는 일부 프로세스 데이터를 저장하기 위해 런타임 디렉터리가 필요합니다. RHOSP를 설치하거나 업그레이드할 때 디렉터리가 생성됩니다. 현재 컨트롤러 노드를 재부팅하면 디렉터리가 제거되고 컨트롤러 노드가 재부팅되면 ceph-nfs 서비스가 복구되지 않습니다. 모든 컨트롤러 노드가 재부팅되면 ceph-nfs 서비스가 영구적으로 실패합니다.

해결방법: 컨트롤러 노드를 재부팅하면 컨트롤러 노드에 로그인하고 /var/run/ceph 디렉터리를 생성합니다.

$ mkdir -p /var/run/ceph

재부팅된 모든 컨트롤러 노드에서 이 단계를 반복합니다. ceph-nfs-pacemaker 서비스가 실패한 것으로 표시되면 디렉터리를 만든 후 컨트롤러 노드에서 다음 명령을 실행합니다.

$ pcs 리소스 정리

현재 Rsyslog가 배포 중 사용자 환경 파일에 "RsyslogReopenOnTruncate: true"를 추가하여 Rsyslog가 로그 순환 시 모든 로그 파일을 다시 열도록 Rsyslog가 Elasticsearch Workaround로 로그 전송을 중지합니다.

현재 RHOSP 17.1은 잘못 구성된 Rsyslog와 함께 이전 puppet-rsyslog 모듈을 사용합니다. 해결방법: Rsyslog를 올바르게 구성하기 전에 /usr/share/openstack-tripleo-heat-templates/deployment/logging/rsyslog-container-puppet.yaml 에 패치 [1]을 수동으로 적용합니다.

현재 오프로드(switchdev) 포트가 있는 Mellanox ConnectX-5, ConnectX-6 및 Bluefield-2 NIC를 사용하는 게스트 인스턴스에 알려진 문제가 있습니다. 예를 들어 sudo systemctl reboot --reboot-arg=now 명령을 사용하여 게스트에서 운영 체제를 직접 재부팅할 때 시스템을 초기화하는 데 시간이 오래 걸립니다. 인스턴스가 동일한 PF(가상 기능)에서 두 개의 VF(가상 기능)로 구성된 경우 VF 중 하나의 초기화가 실패하고 초기화 시간이 길어질 수 있습니다.

해결방법: 게스트 인스턴스를 직접 재부팅하는 대신 OpenStack API를 사용하여 게스트 인스턴스를 적시에 재부팅합니다.

오버클라우드 노드 프로비저닝은 다음 BIOS 설정을 사용하는 경우 RHOSP 17.1의 UEFI 부팅 모드에서 일부 AMD 플랫폼에서 NFV 배포에 실패할 수 있습니다.

DVR이 활성화되어 있고 VLAN 테넌트 네트워크를 사용하는 ML2/OVN 또는 ML2/OVS 환경에서 다른 테넌트 네트워크에 연결된 인스턴스 간 동/서 트래픽은 패브릭에 분산됩니다.

결과적으로 해당 인스턴스 간 패킷은 해당 인스턴스가 실행되는 컴퓨팅 노드뿐만 아니라 다른 오버클라우드 노드에도 도달합니다.

이로 인해 네트워크에 영향을 미칠 수 있으며 모든 곳에서 트래픽을 전송하므로 보안 위험이 발생할 수 있습니다.

이 버그는 이후 FDP 릴리스에서 수정될 예정입니다. FDP 수정을 받기 위해 RHOSP 업데이트를 수행할 필요가 없습니다.

대시보드 서비스(horizon)는 기본적으로 클라이언트 TLS 인증서의 유효성을 검사하도록 구성되어 있으며, 이를 통해 모든 TLS(TLS-e) 배포에서 대시보드 서비스가 중단됩니다.

해결방법:

현재 RHEL 9.2의 Retbleed 취약점 완화로 인해 Intel Skylake CPU에서 OVS-DPDK(Data Plane Development Kit)가 있는 Open vSwitch의 성능이 저하될 수 있습니다.

이 성능 회귀는 BIOS에서 C-state가 비활성화되고 하이퍼 스레딩이 활성화되고 OVS-DPDK가 지정된 코어의 하이퍼 스레드 하나만 사용하는 경우에만 발생합니다.

해결방법: 코어의 하이퍼 스레딩을 OVS-DPDK에 할당하거나 NFV 구성 가이드에서 권장되는 DPDK가 있는 SRIOV 게스트에 할당합니다.

초과 보안 그룹 로그 항목을 버퍼링하는 로깅 대기열은 지정된 제한에 도달하기 전에 항목을 수락하지 않는 경우가 있습니다. 이 문제를 해결하려면 큐 길이를 보유할 항목 수보다 크게 설정할 수 있습니다.

NeutronOVNLoggingRateLimit 매개변수를 사용하여 초당 최대 로그 항목 수를 설정할 수 있습니다. 로그 항목 생성이 이 비율을 초과하면 NeutronOVNLoggingBurstLimit 에서 지정하는 로그 항목 수까지 큐에 초과가 버퍼링됩니다.

이 문제는 버스트의 첫 번째 단계에서 특히 중요합니다. 60 초와 같은 더 긴 버스트에서 속도 제한은 더 많은 영향을 미치고 버스트 제한 부정확에 대한 보완입니다. 따라서이 문제는 짧은 버스트에서 가장 큰 비례 효과가 있습니다.

해결방법: NeutronOVNLoggingBurstLimit 를 대상 값보다 높은 값으로 설정합니다. 필요에 따라 관찰하고 조정합니다.

OVN 메커니즘 드라이버를 사용하는 RHOSP 17.1에서는 포트당 흐름 이벤트 로깅 또는 network log create 명령의 --target 옵션 사용을 지원하지 않습니다.

RHOSP 17.1은 network log create 명령의 --resource 옵션을 사용하여 보안 그룹당 흐름 이벤트 로깅을 지원합니다. Red Hat OpenStack Platform 네트워킹 구성에서 "Logging security group actions"를 참조하십시오.

RHOSP 17.1 GA에서는 RBAC(보안 역할 기반 액세스 제어)가 활성화된 경우 DNS 서비스(designate)가 잘못 구성됩니다. 현재 sRBAC 정책에는 지정에 대한 잘못된 규칙이 포함되어 있으며 지정이 올바르게 작동하도록 수정해야 합니다.

해결방법: 언더클라우드 서버에 다음 패치를 적용하고 오버클라우드를 재배포합니다.

https://review.opendev.org/c/openstack/tripleo-heat-templates/+/888159

RHOSP 17.1에는 OVS-DPDK PMD 스레드에서 또는 DPDK 애플리케이션을 실행하는 게스트에서 하드웨어 인터럽트 요청(IRQ)이 진행 중인 일시적인 패킷 손실 문제가 있습니다.

이 문제는 배포 중에 많은 VF를 프로비저닝한 결과입니다. VFS에는 IRQ가 필요하며, 각 IRQ는 물리적 CPU에 바인딩되어야 합니다. IRQ의 용량을 처리할 수 있는 하우스키핑 CPU가 충분하지 않으면 irqbalance 가 모두 바인딩하지 못하고 분리된 CPU에서 IRQ를 덮어씁니다.

해결방법: 다음 작업 중 하나 이상을 시도할 수 있습니다.

현재 부트스트랩 컨트롤러 노드가 교체되면 OVN 데이터베이스 클러스터가 northbound 및 southbound 데이터베이스에 대해 두 개의 데이터베이스 클러스터로 분할됩니다. 이 경우 인스턴스를 사용할 수 없게 됩니다.

부트스트랩 컨트롤러 노드의 이름을 찾으려면 다음 명령을 실행합니다.

ssh tripleo-admin@CONTROLLER_IP "sudo hiera -c /etc/puppet/hiera.yaml pacemaker_short_bootstrap_node_name"

해결방법: Red Hat KCS 솔루션 7024434에 설명된 단계를 수행합니다. 분할된 클러스터형 OVN 데이터베이스에서 복구 합니다.

현재 다음 배포 아키텍처에 대해 Multi-RHEL이 지원되지 않습니다.

RHOSP 16.2에서 17.1 GA로 인플레이스 업그레이드를 수행할 때 알려진 문제가 있습니다. 컬렉션 에이전트인 collectd-sensubility 가 RHEL 8 컴퓨팅 노드에서 실행되지 않습니다.

해결방법: 영향을 받는 노드에서 파일을 편집하고 26행의 /var/lib/container-config-scripts/collectd_check_health.py. healthy: .State.Health.Status} " 를 "healthy: .State.Healthcheck.Status}" 로 바꿉니다.

ML2/OVN 메커니즘 드라이버를 사용하는 RHOSP 17.1 GA 환경에서는 부동 IP 포트 전달이 제대로 작동하지 않는 알려진 문제가 있습니다. 이 문제는 FIP를 사용할 때 VLAN 및 플랫 네트워크가 north-south 네트워크 트래픽을 배포하므로 발생하며 대신 FIP 포트 전달을 컨트롤러 또는 네트워크 노드에 중앙 집중화해야 합니다.

해결방법: 이 문제를 해결하고 중앙 집중식 게이트웨이 노드를 통해 FIP 포트 전달을 강제 적용하려면 RHOSP Orchestration 서비스(heat) 매개변수 NeutronEnableDVR 을 false 로 설정하거나 VLAN 또는 플랫 프로젝트 네트워크 대신 Geneve를 사용합니다.

이 RHOSP 릴리스에서는 iavf 드라이버와 함께 Intel X710 및 E810 시리즈 컨트롤러 가상 기능(VF)을 사용하는 SR-IOV 인터페이스가 링크 상태 플레이닝과 관련된 네트워크 연결 문제가 발생할 수 있는 알려진 문제가 있습니다. 영향을 받는 게스트 커널 버전은 다음과 같습니다.

현재 인스턴스가 재부팅되지 않도록 할 수 있는 볼륨에 RHCS(Red Hat Ceph Storage) 백엔드를 사용할 때 알려진 문제가 있으며 데이터 손상이 발생할 수 있습니다. 이는 다음 조건이 모두 충족되면 발생합니다.

해결방법: 나열된 모든 조건을 충족하는 볼륨을 재사용 하지 마십시오.

메타데이터 에이전트가 여러 번 오작동하여 HAProxy 하위 컨테이너를 시작하려고 하면 메타데이터 서비스를 사용할 수 없게 될 수 있습니다. 메타데이터 에이전트는 'ProcessExecutionError: exit code: 125; Stdin: ; Stdout: 새 하위 컨테이너 neutron-haproxy-ovnmeta-<uuid>"와 유사한 오류 메시지를 기록합니다.

해결방법: podman kill <_container name_ >을 실행하여 문제가 있는 haproxy 하위 컨테이너를 중지합니다.

RHOSP 17.1.0 GA를 사용 가능으로 처음 다운로드하는 경우 다음 예와 같이 /etc/rhosp/release 파일의 버전 설명에 베타 지정이 잘못 포함되어 있음을 알 수 있습니다.

(overcloud) [stack@undercloud-0 ~]$ cat /etc/rhosp-release
Red Hat OpenStack Platform release
17.1.0 Beta (Wallaby)

해결방법: GA 배포가 영향을 받는 경우 다음 명령을 실행하십시오. # dnf -y update rhosp-release

RHOSP 17.1.0 GA를 사용 가능으로 처음 다운로드하는 경우 다음 예와 같이 /etc/rhosp/release 파일의 버전 설명에 베타 지정이 잘못 포함되어 있음을 알 수 있습니다.

(overcloud) [stack@undercloud-0 ~]$ cat /etc/rhosp-release
Red Hat OpenStack Platform release
17.1.0 Beta (Ussri)

해결방법: GA 배포가 영향을 받는 경우 다음 명령을 실행하십시오. # dnf -y update rhosp-release

RHOSP 17.0 이후 ML2/OVS 메커니즘 드라이버가 더 이상 사용되지 않습니다.

Red Hat은 여러 릴리스에서 ML2/OVS를 ML2/OVN으로 교체하고 있습니다. 예를 들어 RHOSP 15부터 ML2/OVN이 기본 메커니즘 드라이버가 되었습니다.

RHOSP 17 릴리스를 통해 더 이상 사용되지 않는 ML2/OVS 메커니즘 드라이버에 대한 지원이 제공됩니다. 이 기간 동안 ML2/OVS 드라이버는 유지 관리 모드로 남아 있으며 버그 수정 및 정상적인 지원을 수신하며 ML2/OVN 메커니즘 드라이버에서 대부분의 새로운 기능 개발이 수행됩니다.

RHOSP 18.0에서 Red Hat은 ML2/OVS 메커니즘 드라이버를 완전히 제거하고 지원을 중단할 계획입니다.

기존 RHOSP 배포에서 ML2/OVS 메커니즘 드라이버를 사용하는 경우 지금 시작하여 메커니즘 드라이버로 마이그레이션할 계획을 평가합니다. RHOSP 16.2 및 17.1에서 마이그레이션이 지원됩니다.

Red Hat에서는 ML2/OVS에서 ML2/OVN으로 마이그레이션을 시도하기 전에 사전 지원 케이스를 제출해야 합니다. Red Hat은 사전 지원 케이스 없이는 마이그레이션을 지원하지 않습니다. Red Hat OpenStack Platform에서 계획된 활동에 대한 사전 대응 사례를 여는 방법을 참조하십시오. .

sensubility를 사용하여 podman을 통한 API 상태 모니터링은 RHOSP 17.1에서 더 이상 사용되지 않습니다.

sensubility 계층만 더 이상 사용되지 않습니다. API 상태 점검은 계속 지원됩니다. sensubility 계층은 더 이상 지원되는 인터페이스가 아닌 Sensu와의 상호 작용을 위해 존재합니다.