3장. 릴리스 정보

이번 Red Hat OpenStack Platform 릴리스에는 다음과 같은 개선된 기능이 포함되어 있습니다.

Swift 오브젝트는 디스크에 일반 텍스트로 저장됩니다. 이러한 디스크는 수명 종료에 도달할 때 적절히 폐기되지 않은 경우 보안 위험을 초래할 수 있습니다. 오브젝트를 암호화하면 해당 위험이 완화됩니다.

Swift는 swift로 업로드할 때 자동으로 암호화되고 사용자에게 제공할 때 자동으로 암호 해독되는 오브젝트와 함께 이러한 암호화 작업을 투명하게 수행합니다. 이 암호화 및 암호 해독은 Barbican에 저장된 동일한 (symmetric) 키를 사용하여 수행됩니다.

collectd 구성 가능 서비스에 대한 다음 새 매개변수가 추가되었습니다. CollectdGnocchiAuthMode가 'simple'으로 설정된 경우 CollectdGnocchitocol, CollectdGnocchiServer, CollectdGnocchiPort 및 CollectdGnocchiUser가 구성에 대해 고려됩니다.

CollectdGnocchiAuthMode가 'keystone'로 설정된 경우 CollectdGnocchiKeystone* 매개변수가 구성에 대해 고려됩니다.

다음은 추가된 매개변수에 대한 자세한 설명입니다.

이 섹션에 나열된 항목은 기술 프리뷰로 제공됩니다. 기술 프리뷰 상태 범위에 대한 자세한 내용 및 해당 지원에 미치는 영향은 https://access.redhat.com/support/offerings/techpreview/의 내용을 참조하십시오.

"필수 사항"(필수 사항) "기존"(기본값)이 있어야 합니다. "사용 가능한 경우 우선"이 있어야 합니다(필요한 경우).

가능한 경우 모든 경우에 엄격한 NUMA 선호도가 제공됩니다. 이러한 정책을 사용하면 리소스 사용을 최대화하려면 NUMA 선호도를 PCI 별칭별로 얼마나 엄격하게 구성할 수 있습니다. 정책의 주요 차이점은 예약에 실패하기 전에 쉐이크를 위조할 것인지에 대한 NUMA 선호도입니다.

PCI 장치에 대해 "기본 설정" 정책이 구성된 경우 nova는 사용 가능한 경우 PCI 장치의 NUMA 노드와 다른 NUMA 노드에서 CPU를 사용합니다. 이로 인해 리소스 사용률이 향상되지만 이러한 인스턴스의 성능이 저하됩니다.

본 섹션에서는 Red Hat OpenStack Platform에 대한 권장 사항 및 중요한 변경 사항을 포함하여 이번 릴리스 관련 중요한 세부 사항에 대해 간단히 설명합니다. 최상의 배포 결과를 얻으려면 이 정보를 반드시 숙지하셔야 합니다.

결과적으로 공유 파일 시스템 서비스는 이제 IPv6 네트워크를 통해 NetApp ONTAP 백엔드에서 지원하는 공유 내보내기를 지원합니다. 내보낸 공유에 대한 액세스는 IPv6 클라이언트 주소로 제어합니다.

# ip netns exec qrouter...
RTNETLINK answers: Invalid argument

네트워크 네임스페이스 내에서 명령을 실행하려면 네임스페이스를 생성한 neutron 컨테이너에서 해당 명령을 수행해야 합니다. 예를 들어 l3-agent는 라우터의 네트워크 네임스페이스를 생성하므로 명령을 다음과 같이 변경해야 합니다.

# docker exec neutron_l3_agent ip netns exec qrouter...

'qdhcp'로 시작하는 네트워크 네임스페이스와 마찬가지로 'neutron_dhcp' 컨테이너에서 exec가 필요합니다.

확장 기능은 GA 릴리스에서 tripleo에서 기본적으로 구성되지 않습니다. 해결방법은 .BZ#1577592를 참조하십시오.

parameter_defaults: NovaReservedHostMemory: 2048

기본 네트워크의 이름을 변경하려면 사용자 지정 구성 가능 네트워크 파일(network_data.yaml)을 사용하여 '-n' 옵션을 사용하여 'openstack overcloud deploy' 명령에 포함하십시오. 이 파일에서 "name_lower" 필드를 변경하려는 네트워크의 사용자 지정 네트워크 이름으로 설정해야 합니다. 자세한 내용은 Advanced Overcloud Customization 가이드의 "추가 네트워크 사용"을 참조하십시오.

또한 ServiceNetMap 테이블의 로컬 매개변수를 network_environment.yaml에 추가하고 이전 네트워크 이름의 모든 기본값을 새 사용자 지정 이름으로 재정의해야 합니다. 기본값은 /usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml에서 확인할 수 있습니다. ServiceNetMap을 수정하기 위한 이 요구 사항은 향후 OSP-13 릴리스에서 필요하지 않습니다.

결과적으로 metadata-agent가 새 메타데이터 네임스페이스를 프로비저닝하지 않고 클러스터링이 예상대로 작동하지 않으므로 VM 부팅이 작동하지 않을 수 있습니다.

가능한 해결 방법은 새 컨트롤러가 OVN 데이터베이스의 마스터로 승격된 후 모든 컴퓨팅 노드에서 ovn_metadata_agent 컨테이너를 다시 시작하는 것입니다. 또한 plugin.ini의 ovsdb_probe_interval을 600000밀리초 값으로 늘립니다.

이 문제의 증상은 - DuplicateMessageError: Found duplicate message(629ff0024219488499b0fac0caa5) 형식의 OpenStack 서비스 로그에 참여합니다. 이를 건너뜁니다. - "openstack network agent list"는 일부 에이전트가 DOWN임을 반환합니다.

일반 작업을 복원하려면 모든 컨트롤러 노드에서 다음 명령을 실행합니다(컨트롤러에서만 이 작업을 수행해야 함): pcs resource restart rabbitmq-bundle

현재 Red Hat OpenStack Platform의 확인된 문제는 다음과 같습니다.

이 문제를 해결하려면 OS::TripleO::Services::NeutronDhcpAgent를 다음과 같이 변경합니다.

OS::TripleO::Services::NeutronDhcpAgent: docker/services/neutron-dhcp.yaml

따라서 'Back Up and Restore the Director Undercloud'는 Red Hat OpenStack Platform 13의 일반 사용 가능으로 사용할 수 없습니다. 이 절차는 일반 가용성 릴리스 후 우선 순위로 업데이트되고 확인되는 즉시 게시됩니다.

FIB 테이블 누락으로 인해 VM이 공용 네트워크에 대한 연결이 끊어집니다.

유동 IP를 VM에 연결하면 공용 네트워크에 대한 연결이 복원됩니다. 유동 IP가 VM과 연결되어 있으면 인터넷에 연결할 수 있습니다. 그러나 외부 네트워크에서 공용 IP/유동 IP가 손실됩니다.

배포가 통과되면 배포에 성공하려면 세 개의 OpenDaylight 인스턴스 중 두 개만 작동해야 합니다. 세 번째 OpenDaylight 인스턴스가 잘못 시작되었을 수 있습니다. docker ps 명령을 사용하여 각 컨테이너의 상태를 확인합니다. 비정상적인 경우 docker 재시작 opendaylight_api 를 사용하여 컨테이너를 다시 시작합니다.

배포에 실패하면 유일한 옵션은 배포를 다시 시작하는 것입니다. TLS 기반 배포의 경우 모든 OpenDaylight 인스턴스가 올바르게 부팅되어야 합니다. 그렇지 않으면 배포가 실패합니다.

문제가 발생하지 않도록 하려면 오버클라우드가 OSP 10에 남아 있고 마지막 오버클라우드 마이너 버전 업데이트를 수행할 준비가 된 경우 1입니다. 템플릿 파일 /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration.yaml 2를 편집합니다. 템플릿에서 RHELUnregistration 및 RHELUnregistrationDeployment 리소스를 삭제합니다. 3. 마이너 업데이트 및 빠른 전달 업그레이드 절차를 진행합니다.

이러한 상황에서 다음 작업을 수행해야 합니다. * 결함이 있는 노드를 재시작합니다. * REST 엔드포인트를 모니터링하여 클러스터 멤버가 정상인지 확인합니다. http://$ODL_IP:8081/jolokia/read/org.opendaylight.controller:Category=ShardManager,name=shard-manager-config,type=DistributedConfigDatastore * 응답에는 "true" 필드가 포함되어야 합니다.

VM 간 ARP 패킷이 실패하므로 두 VM 간에 네트워킹이 기본적으로 없습니다.

manila-share 서비스가 초기화되도록 하려면 다음을 수행합니다.

1) 오버클라우드 배포에 사용할 /usr/share/openstack/tripleo-heat-templates의 사본을 만듭니다.

2) 295 행의 모든 삼중 백슬래시를 단일 백슬래시로 변경하도록 …​/tripleo-heat-templates/docker/services/ceph-ansible/ceph-base.yaml 파일을 편집합니다.

편집 전:

mon_cap: 'allow r, allow command \\"auth del\\\", allow command \\"auth caps\\", allow command \\"auth get\\", allow command \\"auth get\\", allow command \\"auth get-or-create\\"''

편집 후:

mon_cap: 'allow r, allow command \"auth del\", allow command \"auth caps\", allow command \"auth get\", allow command \"auth get\", allow command \"auth get\".

3) 원래 overcloud-deploy 명령에서 /usr/share/openstack-tripleo-heat 템플릿이 발생한 모든 tripleo-heat-templates 복사본에 대한 경로를 배포할 수 있습니다.

ceph 키 /etc/ceph/ceph.client.manila.keyring 파일에는 적절한 콘텐츠가 있고 manila-share 서비스가 제대로 초기화됩니다.

모니터 경고 임계값이 OSD당 300개에서 200개의 PG로 감소했습니다. 200은 여전히 OSD당 100 PG의 일반적으로 권장되는 대상입니다. 이 제한은 모니터의 mon_max_pg_per_osd 옵션을 통해 조정할 수 있습니다. 이전 mon_pg_warn_max_per_osd 옵션이 제거되었습니다.

풀에서 사용하는 PG의 양을 줄일 수 없습니다. 업그레이드로 인해 기존 배포가 최대 제한에 도달하면 ceph-upgrade 단계에서 제한을 사전 업그레이드 값으로 늘릴 수 있습니다. 환경 파일에서 다음과 같이 매개변수 설정을 추가합니다.

parameter_defaults:
  CephConfigOverrides:
    mon_max_pg_per_osd: 300

설정은 ceph.conf에 적용되며 클러스터는 HEALTH_OK 상태로 유지됩니다.

오버클라우드 외부 네트워크에 대해 NIC 템플릿에서 항상 OVS 브리지를 사용합니다. 이 브리지는 기본적으로 Director에서 "br-ex"라고 합니다(이름을 사용할 수도 있음). 외부 네트워크에 사용되는 물리적 호스트 인터페이스를 이 OVS 브리지에 연결해야 합니다.

OVS 브리지에 연결된 인터페이스를 사용하면 배포가 올바르게 작동하고 테넌트에 대한 외부 네트워크 트래픽이 올바르게 작동합니다.

문제가 발생하면 neutron 서버에서 OVN North 및 South DB 서버와 모든 Create/Update/Delete API를 neutron 서버에 연결할 수 없습니다.

ovn-dbs-bundle 리소스를 다시 시작하면 문제가 해결됩니다. 컨트롤러 노드 중 하나에서 아래 명령을 실행합니다.

"pcs 리소스 재시작 ovn-dbs-bundle"

SNAT 트래픽이 해당 트래픽을 통과하도록 VXLAN 터널을 올바르게 구성해야 합니다. VLAN 테넌트 네트워크를 사용하는 경우 다음 방법 중 하나를 사용하여 SNAT 트래픽이 VXLAN 터널을 통해 흐름할 수 있도록 MTU를 구성합니다. * 네트워크 구성에 1450의 MTU를 사용하도록 VLAN 테넌트 기반 네트워크를 구성합니다. * NeutronGlobalPhysnetMtu heat 매개변수를 1450으로 설정합니다. 참고: 모든 플랫/VLAN 공급자 네트워크에는 1450 MTU가 있으며 바람직하지 않을 수 있습니다(특히 외부 공급자 네트워크의 경우). * 1550 이상의 MTU를 사용하여 테넌트 네트워크를 구성합니다. 여기에는 테넌트 네트워크 NIC에 대한 NIC 템플릿의 MTU 설정이 포함됩니다.

Red Hat OpenStack Platform 13에 포함된 HAProxy 버전은 PING 유형 상태 모니터를 구성할 때 TCP 연결을 사용하는 1.6 이전 버전입니다.

이러한 테스트를 건너뛰거나 해당 필터를 nova 구성에 추가해야 합니다.

이 문제를 해결하려면 다음과 같이 언더클라우드 배포에 대한 추가 템플릿을 추가하여 컨트롤 플레인 네트워크를 사용하여 snmpd 서브넷을 수동으로 설정해야 합니다.

parameter_defaults: SnmpdIpSubnet: 192.168.24.0/24

이 문제를 해결하려면 다음과 같이 언더클라우드 배포에 대한 추가 템플릿을 추가하여 컨트롤 플레인 네트워크를 사용하여 snmpd 서브넷을 수동으로 설정해야 합니다.

parameter_defaults:
  SnmpdIpSubnet: 192.168.24.0/24

이로 인해 "Error response from daemon: No such container: ceph-create-keys라는 메시지와 함께 배포에 실패할 수 있습니다. 이는 새 배포를 포함하여 ceph-ansible 실행에 영향을 미칠 수 있습니다. * * 여러 컴퓨팅 노트 또는 * 사용자 지정 역할은 ceph를 사용하는 서비스를 호스팅하는 ceph 클라이언트로 변경될 수 있습니다.

문제를 방지하려면 기본 PG 번호를 32로 설정하고 배포가 완료되면 스토리지 전략 가이드( https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html/storage_strategies_guide/placement_groups_pgs#set_the_number_of_pgs 설명된 대로 PG 번호를 수동으로 올립니다.

게스트를 제거한 후 'nova-compute' 서비스를 다시 시작해야 합니다. 게스트를 제거하고 서비스를 다시 시작한 후 사용 가능한 SR-IOV 장치 목록이 수정됩니다.

다음 해결 방법 중 하나를 사용할 수 있습니다.

옵션 A: Pacemaker에서 관리하는 컨테이너가 있는 노드에서 /etc/sysconfig/docker 파일을 수동으로 업데이트하고 새로 도입된 비보안 레지스트리를 추가합니다.

옵션 B: 업그레이드 전에 openstack overcloud deploy 명령을 실행하고 DockerInsecureRegistryAddress 매개변수가 있는 환경 파일을 사용하여 원하는 새 비보안 레지스트리 목록을 제공합니다.

업그레이드 중에 모든 컨테이너 이미지가 성공적으로 다운로드되어야 합니다.

해결방법은 모든 컨트롤러 노드에서 방화벽 규칙을 추가하고 DROP 규칙 앞에 삽입되는지 확인합니다.

IPv4:
  # iptables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv4" -j ACCEPT
  # iptables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv4" -j ACCEPT

IPv6:
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 13876 -m state --state NEW -m comment --comment "100 octavia_api_haproxy_ssl ipv6" -j ACCEPT
  # ip6tables -A INPUT -p tcp -m multiport --dports 9876,13876 -m state --state NEW -m comment --comment "120 octavia_api ipv6" -j ACCEPT

HAProxy를 재시작합니다.

  # docker restart haproxy-bundle-docker-0

예기치 않은 API 오류. 'nova_cell0.instances'가 존재하지 않음

다음 명령을 실행하여 이 오류를 해결할 수 있습니다.

$ sudo nova-manage api_db sync

이 문제는 중요하지 않으며 주요 방식으로 빠르게 후속 업그레이드 프로세스를 중단해서는 안 됩니다.