업데이트 날짜: 2018년 11월 13일

VMware Integrated OpenStack 4.1 | 2018년 1월 18일 | 빌드 7538136
Kubernetes와 VMware Integrated OpenStack 4.1 | 2018년 1월 18일 | 빌드 7549988

이 릴리스 정보의 추가 사항 및 업데이트 사항을 확인하십시오.

릴리스 정보에 포함된 내용

릴리스 정보에는 다음과 같은 항목이 포함됩니다.

VMware Integrated OpenStack 정보

VMware Integrated OpenStack은 통합 프로세스를 효율화하여 OpenStack 클라우드 인프라 배포를 크게 단순화합니다. VMware Integrated OpenStack은 vCenter Server에서 직접 실행되는 배포 관리자 vApp을 통해 기본 제공 OpenStack 기능 및 편리한 구성 워크플로를 제공합니다.

새로운 기능

이 릴리스는 최신 OpenStack Ocata 릴리스에 기반하며 다음과 같은 새로운 기능 및 향상된 기능을 제공합니다.

VMware Integrated OpenStack

  • 최신 버전의 VMware 제품 지원: VMware Integrated OpenStack 4.1은 VMware vSphere 6.5 업데이트 1, VMware NSX for vSphere 6.3.5, VMware NSX-T 2.1.및 vSAN 6.6.1을 지원하며 이러한 제품과 완벽하게 호환됩니다.
  • HTML5 vSphere Client 지원: VMware Integrated OpenStack은 HTML5 vSphere Client 버전 6.5.0U1, 6.5.0U1b, 6.5.0U1c 및 6.5.0f를 지원합니다.
  • 여러 도메인 LDAP 백엔드: Keystone은 이제 여러 LDAP 도메인에서 지원될 수 있어 더욱 복잡한 구조 및 환경 지원이 가능합니다. 
  • 네이티브 NSX-T LBaaS: VMware Integrated OpenStack은 가상 시스템 기반 워크로드와 컨테이너 기반 워크로드에 대해 새 NSX-T 네이티브 로드 밸런서를 완전하게 지원합니다. 
  • HAProxy 제한: 악의적이거나 의도하지 않은 API 오버로드를 방지하기 위해 HAProxy가 추가 구성 설정을 사용하여 업데이트되었습니다.
  • 매우 작음 배포 모드: 장치 모델의 단일 서버로의 배포를 허용하기 위한 새 배포 옵션이 도입되었습니다. 
  • 공용 관리 API: VMware Integrated OpenStack의 배포 및 수명 주기 관리를 직접 자동화하는 데 사용될 수 있는 OpenStack 관리 서버 API가 이제 일반 사용을 위해 문서화 및 제공됩니다. 

Kubernetes와 VMware Integrated OpenStack

Kubernetes에 구축된 컨테이너 오케스트레이션 플랫폼이 VMware Integrated OpenStack에 포함되어 애플리케이션 개발자가 전체 인프라 스택을 프로비저닝할 수 있게 되었습니다. 이 플랫폼은 다음과 같은 새 기능을 제공합니다.

  • 최신 버전의 Kubernetes 지원: VMware Integrated OpenStack 4.1에는 완전하게 지원되는 Kubernetes 버전 1.8.1이 포함되어 있습니다.
  • 로깅 향상 기능: 이제 로그를 모든 Syslog 호환 대상으로 전달할 수 있어 기존 로그 관리 도구와의 통합이 가능합니다.
  • 추가 구성 요소: 컨테이너 플랫폼에 배포된 애플리케이션을 관리 및 모니터링하는 데 도움이 되는 Helm 및 Heapster에 대한 지원 기능이 추가되었습니다. 
  • 제어부 백업 및 복구: 이 릴리스에는 컨테이너 플랫폼 제어부 백업을 지원하기 위한 추가 도구 및 모범 사례가 포함되어 있습니다. 

호환성

vSphere 구성 요소를 포함하여 VMware Integrated OpenStack과 다른 VMware 제품의 호환성에 대한 자세한 내용은 VMware 제품 상호 운용성 매트릭스를 참조하십시오.

버전 4.1로 업그레이드

VMware Integrated OpenStack 업그레이드

VMware Integrated OpenStack 3.1 이상에서 VMware Integrated OpenStack 4.1로 직접 업그레이드할 수 있습니다. 

  • VMware Integrated OpenStack 3.1.x에서 VMware Integrated OpenStack 4.1로 업그레이드하려면 설치 가이드의 VMware Integrated OpenStack 업그레이드를 참조하십시오.
    참고: 소스 NAT가 사용되지 않도록 설정된 라우터에서 부동 IP 주소를 구성한 경우 버전 4.1로 업그레이드하기 전에 소스 NAT를 사용하도록 설정하거나 부동 IP 주소를 제거합니다. 부동 IP 주소는 소스 NAT가 사용되지 않도록 설정된 라우터에서 더 이상 지원되지 않습니다.
  • VMware Integrated OpenStack 4.0에서 VMware Integrated OpenStack 4.1로 업그레이드하려면 설치 가이드의 VMware Integrated OpenStack에 패치 적용을 참조하십시오.

VMware Integrated OpenStack 3.0 이하 버전을 실행 중인 경우 먼저 버전 3.1로 업그레이드한 다음 버전 4.1로 업그레이드합니다. 

Kubernetes와 VMware Integrated OpenStack 업그레이드

Kubernetes와 VMware Integrated OpenStack 4.0에서 Kubernetes와 VMware Integrated OpenStack 4.1로 업그레이드하려면 Kubernetes와 VMware Integrated OpenStack 시작 가이드Kubernetes와 VMware Integrated OpenStack 업그레이드를 참조하십시오.

국제화

VMware Integrated OpenStack 4.1은 영어 및 7개의 추가 언어인 중국어 간체, 중국어 번체, 일본어, 한국어, 프랑스어, 독일어, 스페인어로 제공됩니다.

다음 항목에는 ASCII 문자만 사용할 수 있습니다.

  • OpenStack 리소스(예: 프로젝트, 사용자 및 이미지)의 이름
  • 인프라 구성 요소(예: ESXi 호스트, 포트 그룹, 데이터 센터 및 데이터스토어)의 이름
  • LDAP 및 Active Directory 특성 

Kubernetes와 VMware Integrated OpenStack은 영어로만 제공됩니다.

VMware Integrated OpenStack의 오픈 소스 구성 요소

VMware Integrated OpenStack 4.1에서 배포되는 오픈 소스 소프트웨어 구성 요소에 적용되는 저작권 정보 및 라이센스는 제품 다운로드 페이지의 Open Source(오픈 소스) 탭에서 확인할 수 있습니다. 소스 코드 또는 소스 코드에 대한 수정을 사용 가능하도록 요구하는 GPL, LGPL 또는 기타 유사한 라이센스의 적용을 받는 VMware Integrated OpenStack의 구성 요소에 대한 공개 패키지를 다운로드할 수도 있습니다.

해결된 문제

해결된 문제는 다음과 같이 그룹화되어 있습니다.

VMware Integrated OpenStack
    Kubernetes와 VMware Integrated OpenStack
    • SDDC 클라우드 제공자에 대해 GUI에 vSphere 클러스터가 나타나지 않음

      GUI에서 SDDC 클라우드 제공자를 생성하고 루트 CA 파일을 업로드하면 [vSphere 클러스터] 페이지에 클러스터가 나타나지 않습니다. 신뢰할 수 있는 인증 기관에서 승인한 인증서로 vCenter Server를 보호하거나 vCenter Server 인증서 검증을 무시하도록 선택하면 이 문제가 발생하지 않습니다.

      이 문제는 이 릴리스에서 해결되었습니다.

    • 관리 암호가 변경된 후 사용자 및 그룹을 나열할 수 없음

      캐시된 관리 암호가 새 관리 암호와 동기화되지 않습니다.

      이 문제는 이 릴리스에서 해결되었습니다.

    • GUI에서 파일을 업로드할 때 "{0} 파일만 지원됩니다." 오류 메시지가 나타남

      이 오류 메시지는 잘못된 파일 유형이 업로드되었을 때 나타납니다. 이 문제는 다음 중 하나의 경우에 발생할 수 있습니다.

      • 클라우드 제공자 또는 클러스터를 생성할 때 이전에 다운로드한 페이로드 파일을 생성 프로세스 중 업로드하려고 시도하는 경우
      • SDDC 클라우드 제공자 또는 OpenStack 제공자를 생성할 때 CA 인증서 파일을 업로드하려고 시도하는 경우

      이 문제는 이 릴리스에서 해결되었습니다.

    • 제공자 이름을 입력한 후에도 GUI에서 제공자 이름을 입력하라는 메시지를 표시함

      SDDC 또는 OpenStack 클라우드 제공자를 생성할 때 [제공자 추가] 마법사에서 제공자 이름을 지정했는데도 GUI가 "제공자 이름이 필요합니다."라는 오류를 표시합니다.

      이 문제는 이 릴리스에서 해결되었습니다.

    알려진 문제

    알려진 문제는 다음과 같이 그룹화되어 있습니다.

    VMware Integrated OpenStack
    • NSX-T 암호가 변경된 후 VMware Integrated OpenStack이 NSX-T에 연결될 수 없음

      Neutron 서버가 실행되는 동안 NSX-T 암호를 변경하는 경우 VMware Integrated OpenStack이 NSX-T에 연결되지 못할 수 있습니다.

      해결 방법: NSX-T 암호를 변경하기 전에 활성 컨트롤러 노드에 로그인하고 systemctl stop neutron-server 명령을 실행하여 Neutron 서버 서비스를 중지합니다. 이 서비스는 VMware Integrated OpenStack에서 NSX-T 암호를 업데이트한 후 다시 시작됩니다.

    • 테넌트 가상 데이터 센터와 함께 삭제된 계산 노드를 다시 추가할 수 없음

      테넌트 가상 데이터 센터와 함께 계산 노드를 삭제한 후 다시 추가하려고 하면 해당 시도가 실패하고 /var/log/nova/nova-compute.log에 "리소스 제공자를 생성하지 못함" 오류가 기록됩니다.

      해결 방법: 다음 단계를 수행하여 데이터베이스에서 Nova 계산 노드를 제거합니다.

      1. 삭제된 계산 노드의 MOID를 찾습니다.
      2. 활성 데이터베이스 노드에 로그인하고 nova_api 데이터베이스를 엽니다.

        mysql
        use nova_api

      3. "resource_providers" 테이블에서, 삭제된 계산 노드의 MOID를 가진 resource_provider 레코드를 제거하고 해당 레코드의 모든 하위 항목을 제거합니다.
    • 잘못된 순서로 계산 노드를 삭제한 다음 계산 노드를 추가하려고 할 때 오류가 발생함

      내림차순으로 계산 노드를 삭제하지 않은 경우 나중에 노드를 추가하면 오류가 발생합니다.

      해결 방법: 가장 큰 노드 번호에서 가장 작은 노드 번호 순서대로 노드를 삭제합니다. 예를 들어 3개의 계산 노드인 VIO-Compute-0, VIO-Compute-1 및 VIO-Compute-2가 포함된 경우 먼저 VIO-Compute-2를 삭제한 다음 VIO-Compute-1을 삭제하고 마지막으로 VIO-Compute-0을 삭제해야 합니다.

    • OpenStack GUI가 공용 가상 IP 주소의 원래 값만 내보냄

      공용 가상 IP 주소가 변경되고 VMware Integrated OpenStack 또는 OpenStack 구성을 내보낸 후 설정 시 다시 로드하는 경우 내보낸 구성이 업데이트된 값이 아닌 원래 구성의 공용 가상 IP 주소를 포함합니다.

      해결 방법: OpenStack 구성을 다시 로드하기 전에 내보내고 저장한 구성 파일의 공용 가상 IP 주소를 업데이트합니다. 또는 다시 배포를 확인할 때 GUI에서 공용 가상 IP 주소를 업데이트합니다.

    • 공용 로드 밸런서 IP 주소가 OpenStack API 액세스 네트워크와 충돌함

      GUI 외부에서 구성된 경우 공용 로드 밸런서의 IP 주소가 OpenStack API 액세스 네트워크와 겹칠 수 있습니다. 해당 구성을 내보내고 OpenStack 또는 VMware Integrated OpenStack 설정에 다시 적용하는 경우 IP 주소 겹침이 허용되지 않습니다.

      해결 방법: IP 주소를 제공하거나 구성하는 경우 공용 로드 밸런서 IP 주소가 OpenStack API 액세스 네트워크와 겹치지 않는지 확인합니다.

    • HTML5 vSphere Client를 사용한 VMware Integrated OpenStack 배포가 실패함

      HTML5 vSphere Client에서 배포 유형을 선택하지 않고 이전 템플릿을 사용하여 VMware Integrated OpenStack을 배포하는 경우 배포 마법사의 마지막 단계에서 내부 REST API 오류가 발생합니다.

      해결 방법: 이전 템플릿을 사용하는 경우 수동으로 배포 유형을 선택합니다. 또는 Flex 기반 vSphere Web Client를 사용하여 OpenStack을 배포할 수 있습니다.

    • VMware Integrated OpenStack vApp이 HTML5 vSphere Client에 표시되지 않음

      VMware Integrated OpenStack을 설치한 후 HTML5 vSphere Client가 VMware Integrated OpenStack 플러그인을 로드하지 못할 수 있습니다.

      해결 방법: vSphere Client에서 로그아웃한 다음 다시 로그인합니다. vApp이 여전히 표시되지 않는 경우 다음 단계를 수행하여 HTML5 vSphere Client를 다시 시작합니다.

      1. Flex 기반 vSphere Web Client에 로그인합니다.
      2. 관리를 선택합니다.
      3. 탐색기 트리에서 시스템 구성을 선택하고 서비스를 클릭합니다.
      4. VMware vSphere Client를 선택합니다.
      5. 작업 아이콘을 클릭하고 다시 시작을 선택합니다.
    • 로드 밸런서가 오류 상태로 전환됨

      로드 밸런서가 Tier-1 네트워크 라우터에 연결되지 않은 서브넷을 사용하여 생성되는 경우 해당 로드 밸런서가 성공적으로 생성될 수 없으며 오류 상태로 전환됩니다.

      해결 방법: 로드 밸런서를 생성하기 전에 Tier-1 네트워크 라우터를 서브넷에 연결합니다.

    • 과도한 부하 상태에서 인스턴스가 부팅되지 않음

      시스템이 과도한 부하 상태일 때 VMware Integrated OpenStack 인스턴스를 배포하는 경우 Keystone이 API 요청으로 과도한 부하가 발생하고 "서비스 사용 불가" 오류가 표시되며 서비스 제공에 실패합니다.

      해결 방법: 시스템 로드가 가벼울 때 인스턴스를 배포합니다.

    • 인증서 확인이 OpenStack 관리 서버에서 실패할 수 있음

      viocli 명령줄 유틸리티를 사용하는 경우 다음 오류가 발생할 수 있습니다.

      ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

      해결 방법: OpenStack 관리 서버에서 다음 명령을 실행하여 vCenter Server 인증서의 확인을 사용하지 않도록 설정합니다.

      sudo su - export VCENTER_INSECURE=True
    • BGP 지원 공유 라우터의 게이트웨이를 제거하면 다른 BGP 지원 공유 라우터에서 짧은 네트워크 중단이 발생할 수 있음

      공유 라우터가 있는 환경에서 여러 라우터가 동일한 Edge에서 호스팅될 수 있습니다. BGP가 사용되도록 설정된 경우 이러한 라우터 중 하나의 게이트웨이 IP 주소가 router id로 사용됩니다. 라우터의 게이트웨이가 지워지면 플러그인이 다른 BGP 지원 라우터의 게이트웨이를 router id의 새 값으로 선택합니다. 해당 Edge에서 호스팅된 다른 BGP 지원 라우터에 대해 보급된 경로가 손실되기 때문에 이 프로세스는 일시적인 피어링 중단을 일으킵니다.

      해결 방법: 단독 라우터를 사용합니다.

    • Nova 또는 Neutron 서비스를 새로 고치는 도중 서비스 중단이 발생함

      VMware Integrated OpenStack이 라이센스 요구 사항을 준수하지 않는 OpenStack 설정을 감지하는 경우 Nova 또는 Neutron 서비스를 다시 시작하여 해당 설정을 수정하려고 합니다.

      해결 방법: 없음 OpenStack을 배포하기 전에 라이센스를 할당하여 OpenStack 설정이 라이센스 요구 사항을 준수하도록 합니다.

    • NSX-T 배포의 경우 새로운 Tier-0 라우터가 router-gateway-set 동안 Tier-1 라우터에 연결되지 않음

      이미 Tier-0 라우터를 구성한 상태에서 새 Tier-0 라우터를 생성하면 새 라우터의 UUID가 nsxv3.ini 파일에 자동으로 기록되지 않습니다. 이후에 생성한 Tier-1 라우터는 새로운 Tier-0 라우터에 연결되지 않습니다.

      해결 방법: 수동으로 nsxv3.ini 파일을 업데이트하고 외부 네트워크를 다시 생성합니다.

      1. 새 Tier-0 라우터의 UUID를 찾습니다.
      2. /etc/neutron/plugin/vmware/nsxv3.ini 파일을 열고 새 Tier-0 라우터의 UUID로 업데이트합니다.
      3. Neutron 서버를 다시 시작합니다.
      4. 외부 네트워크를 삭제하고 새로운 외부 네트워크를 생성합니다.
    • 라우터 인터페이스 삭제 시간이 초과됨

      동시 히트 스택이 공유 NSX 라우터로 배포되는 경우 라우터 인터페이스 삭제의 시간이 초과될 수 있습니다. 다음이 표시될 수 있습니다. neutron_client_socket_timeout, haproxy_neutron_client_timeout 또는 haproxy_neutron_server_timeout일 수 있습니다.

      해결 방법: 네트워크 리소스가 자주 변경되는 환경에서 공유 라우터를 사용하지 마십시오. NAT/FIP가 필요한 경우 단독 라우터를 사용합니다. 또는 분산 라우터를 사용합니다.

    • NSX-V 배포의 경우 게이트웨이를 메타데이터 프록시 라우터에 연결한 후 OpenStack 배포가 메타데이터 서버에 액세스할 수 없음

      게이트웨이를 메타데이터 프록시 라우터에 연결하는 경우 NSX E dge vnic0 인덱스가 VM 네트워크에서 게이트웨이 네트워크 포트 그룹으로 변경됩니다. 이로 인해 OpenStack 배포가 메타데이터 서버에 액세스하지 못할 수 있습니다.

      해결 방법: 게이트웨이를 메타데이터 프록시 라우터에 연결하지 않습니다.

    • NSX-T 배포의 경우 방화벽을 게이트웨이가 없는 라우터에 연결할 때 방화벽 규칙이 NSX 라우터에 추가됨

      FWaaS(Firewall as a Service) 규칙과 일치하는 관련 트래픽이 없는 경우에도 게이트웨이가 없는 라우터에 해당 규칙이 추가됩니다.

      해결 방법: 규칙을 활성화하려면 라우터에 대한 게이트웨이를 구성합니다.

    • Nova 인스턴스가 "유효한 호스트 없음" 오류와 함께 부팅되지 않음

      스트레스 조건에서 tenant_vdc 속성을 사용한 인스턴스 부팅이 실패할 수 있습니다.

      해결 방법: 시스템 로드가 가벼울 때 인스턴스를 부팅합니다.

    • 서비스 게이트웨이 Edge에서 BGP 테넌트 네트워크가 손실됨

      BGP 스피커와 서비스 게이트웨이 간의 BGP 피어링이 설정된 후 외부 또는 제공자 네트워크와 BGP 스피커의 연결을 끊기 위해 neutron bgp-speaker-network-remove 명령을 실행하면 서비스 게이트웨이의 테넌트 경로가 손실될 수 있습니다. neutron bgp-speaker-network-add를 사용하여 BGP 스피커에 대한 외부 또는 제공자 네트워크를 복원해도 경로가 재생성되지 않습니다.

      해결 방법: nsxv.ini 파일에서 ecmp_wait_time의 값을 5초로 변경합니다.

    • DLR 테넌트 Edge(PLR)와 제공자 게이트웨이 Edge 간의 iBGP 피어링이 테넌트 네트워크를 제대로 보급하지 않고 외부 통신을 차단함

      iBGP 피어링이 사용되는 경우 다음 홉을 수정하지 않고 보급된 경로가 피어에 설치됩니다. 그 결과 제공자 게이트웨이 Edge가 테넌트의 PLR Edge 업링크 대신 전송 네트워크 범위의 다음 홉 IP 주소로 테넌트 네트워크 간에 라우팅을 설치합니다. 게이트웨이 Edge가 전송 네트워크로의 경로를 확인할 수 없으므로 통신이 중단됩니다.

      해결 방법: 분산 라우터를 사용할 경우 eBGP 피어링을 사용합니다.

    • NSX-V 배포의 경우 admin_state 매개 변수가 효력이 없음

      Nova 포트에 대해 admin_state 매개 변수를 False로 변경하는 것은 적용되지 않습니다. 이 매개 변수는 NSX-V에서 지원되지 않습니다

      해결 방법: 없음

    • 클라우드 서비스 라우터에 IP 주소가 포함되어 있지만 FQDN은 포함되어 있지 않음

      VMware Integrated OpenStack 배포 중 로드 밸런서 구성의 공용 호스트 이름이 지정되지 않았거나 공용 액세스에 대한 요구 사항을 준수하지 않았습니다. 공용 호스트 이름은 VMware Integrated OpenStack 대시보드 및 API에 대한 외부 액세스에 사용됩니다.

      해결 방법: 배포 후 공용 호스트 이름을 변경하거나 편집하려면 KB 2147624를 참조하십시오.

    • 방화벽을 게이트웨이가 없는 라우터에 연결할 때 방화벽 규칙이 NSX 라우터에 추가되지 않음

      라우터에 게이트웨이가 포함된 경우에만 FWaaS(Firewall as a Service) 규칙이 추가됩니다. 이러한 규칙은 관련 트래픽이 없기 때문에 게이트웨이가 없는 라우터에 영향을 미치지 않습니다.

      해결 방법: 방화벽을 연결하기 전에 라우터에 대한 게이트웨이를 구성합니다.

    • Nova 서버와의 메타데이터 에이전트 HTTP 통신에 보안 위험이 발생함

      Edge Appliance의 메타데이터 에이전트는 역방향 프록시 역할을 하며 OpenStack에서 NSX 환경에 대한 메타데이터 정보를 수집하기 위해 업스트림 Nova 서버와 통신합니다. nginx 역방향 프록시 구성 또한 일반 텍스트 통신을 지원합니다. TLS 암호화가 부족하여 중요 데이터가 노출될 수 있고 네트워크의 공격자가 전송 중인 사이트의 데이터를 수정할 수도 있습니다.

      해결 방법: 메타데이터 프록시 서버와 Nova 서버 간에 보안 통신을 보장하려면 HTTP 대신 CA 지원과 함께 HTTPS를 사용합니다.

      1. nova.conf에 다음 매개 변수를 추가하여 Nova 메타데이터 HTTPS 지원을 사용하도록 설정합니다.
        [DEFAULT] enabled_ssl_apis = metadata [wsgi] ssl_cert_file = nova-md-https-server-cert-file ssl_key_file = nova-md-https-server-private-key-file
      2. NSX Manager에서 시스템 > 신뢰 > 인증서를 선택하고 CA 인증서 또는 인증서 체인을 가져옵니다. 가져온 인증서의 UUID를 기록합니다.
      3. 다음 형식의 https_mdproxy.json 파일을 준비합니다. 
        { "display_name" : "https_md_proxy", "resource_type" : "MetadataProxy", "metadata_server_url" : "https://md-server-url", "metadata_server_ca_ids": ["ca-id"], "secret": "secret", "edge_cluster_id" : "edge-cluster-id" }
      4. REST API를 사용하여 HTTPS 메타데이터 프록시 서버를 배포합니다.
        curl -i -k -u nsx-mgr-admin:nsx-mgr-passwd -H "content-type: application/json" -H "Accept: application/json" -X POST https://nsx-mgr-ip/api/v1/md-proxies -d "`cat ./https_mdproxy.json`"
      5. 생성된 메타데이터 프록시 서버의 UUID로 VMware Integrated OpenStack을 구성합니다. 이제 메타데이터 프록시 서버와 Nova 서버 간의 통신이 인증서 인증으로 HTTPS에 의해 보호됩니다.
    • 정책 파일 사용자 지정이 VMware Integrated OpenStack 대시보드에 동기화되지 않음

      GUI가 사용자 지정 플레이북에 지정된 정책에 대한 변경 내용을 인식하지 않습니다.

      해결 방법: 사용자 지정 플레이북을 사용하여 정책 파일을 편집하는 경우 일관성을 보장하기 위해 VMware Integrated OpenStack 대시보드 정책 파일도 동일하게 변경합니다.

    • 가용성 영역 구성이 성공적으로 적용되지 않을 수 있음

      가용성 영역 구성을 수정한 후, 새 구성은 백업 Edge가 삭제되고 다시 생성되기 전까지 적용되지 않을 수 있습니다.

      해결 방법: 모든 백업 Edge를 삭제하고 Neutron을 다시 시작합니다.

      1. 모든 백업 Edge를 삭제합니다.
        nsxadmin -r backup-edges -o clean --property edge-id=edge-node-id
      2. Neutron을 다시 시작합니다.
    • vCenter Server에서 이름이 변경된 OpenStack 인스턴스가 원래 이름 아래에 나타남

      nova rename 명령을 사용하여 OpenStack 인스턴스의 이름을 변경한 경우, 변경 내용은 OpenStack 데이터베이스에만 나타납니다. vCenter Server 인스턴스가 계속해서 원래 이름을 표시합니다.

      해결 방법: 없음

    • 논리적 분산 라우터의 DHCP를 사용하지 않는 서브넷에서 메타데이터에 액세스할 수 없음

      DHCP를 사용하지 않는 서브넷의 인스턴스는 논리적 분산 라우터의 인터페이스를 통해 메타데이터에 액세스할 수 없습니다. 이 동작은 공유 및 단독 라우터에서는 나타나지 않습니다.

      해결 방법: 없음

    • OpenStack 인스턴스를 배포할 때 "인증서가 CA 저장소에 없음" 오류가 나타날 수 있음

      이미 vRealize Automation에 연결된 다른 인스턴스에 사용된 IP 주소를 사용하여 새 VMware Integrated OpenStack 인스턴스를 배포하는 경우 다음 인증서 오류가 발생할 수 있습니다.
      요청을 실행할 수 없음: ; java.security.cert.CertificateException: 인증서가 CA 저장소에 없습니다. (워크플로: REST 작업 / REST 호출을 호출합니다. (item0)#35)

      해결 방법: 이전 VMware Integrated OpenStack 인스턴스의 인증서를 삭제하고 vRealize Orchestrator에 새 인증서를 가져옵니다.

      1. vRealize Orchestrator에 로그인합니다.
      2. 라이브러리 > 구성 > SSL 신뢰 관리자를 선택합니다.
      3. 워크플로를 실행하여 이전 VMware Integrated OpenStack 인스턴스의 신뢰된 인증서를 삭제합니다.
      4. 워크플로를 실행하여 URL에서 새 인스턴스의 인증서를 가져옵니다.
    • Neutron에서 NSX 정책을 사용하도록 설정한 후 테넌트 트래픽이 차단될 수 있음

      Neutron 플러그인에서 security-group-policy를 사용하도록 설정한 후 NSX 방화벽 섹션이 잘못된 순서로 나열될 수 있습니다. 올바른 순서는 다음과 같습니다.

      1. NSX 정책
      2. 테넌트 보안 그룹
      3. 기본 섹션

      해결 방법: vSphere Web Client에서 [NSX 방화벽] 페이지를 열고 섹션을 올바른 위치로 이동합니다. 이 문제가 발생하는 것을 방지하려면 VMware Integrated OpenStack을 구성하기 전에 첫 번째 NSX 정책을 생성합니다.

    • 라우터 크기 드롭다운 메뉴가 VMware Integrated OpenStack 대시보드에 표시되지 않음

      VMware Integrated OpenStack 대시보드에 단독 라우터를 생성하는 경우 해당 크기를 지정할 수 있습니다. 하지만 공유에서 단독으로 라우터를 변경하는 경우 라우터 크기 드롭다운 메뉴가 나타나지 않으므로, 라우터 크기를 지정하지 못하게 됩니다.

      해결 방법:라우터에 대한 기본값을 복원하고 유형을 다시 단독으로 수정합니다. 드롭다운 메뉴가 나타납니다.

    • SQL로 구성된 사용자를 VMware Integrated OpenStack 대시보드에서 수정할 수 없음
      VMware Integrated OpenStack 배포가 사용자 인증에 LDAP를 사용하도록 구성된 경우, 사용자의 소스가 SQL 데이터베이스이더라도 VMware Integrated OpenStack 대시보드에서 사용자 정의를 수정할 수 없습니다.

      해결 방법: 없음

    • vSphere HA 이벤트 이후 복구에서 동기화 및 프로세스 시작 오류가 표시됨

      vSphere HA 이벤트는 VMware Integrated OpenStack 배포에 영향을 미칠 수 있습니다. vSphere 복구 후 OpenStack 관리 서버에서 viocli deployment status 명령을 실행합니다. 결과 보고서에 동기화 또는 프로세스 시작 오류가 표시되는 경우 아래의 해결 방법을 사용하십시오.

      해결 방법: viocli services stop 명령을 실행한 다음 viocli services start 명령을 실행하여 모든 OpenStack 서비스를 수동으로 다시 시작합니다. OpenStack 서비스가 다시 시작된 후 viocli deployment status 명령을 다시 실행하고 오류가 없음을 확인합니다.

    • 이미지가 VMX 버전 10 이상이어야 함
      이 문제는 스트림에 최적화된 이미지 및 OVA에 영향을 미칩니다. 이미지의 하드웨어 버전이 VMX 10 이전 버전인 경우 해당 이미지에서 생성된 OpenStack 인스턴스가 작동하지 않습니다. OpenStack 계산 노드가 5.5 등 이전 ESXi 버전에서 배포된 경우 일반적으로 이 문제가 발생합니다. 이미지 메타데이터(vmware_hw_version) 또는 플레이버 메타데이터(vmware:hw_version)를 조정하여 해당 이미지를 수정할 수 없습니다.

      해결 방법: 최신 이미지를 사용합니다.

    • OpenStack 관리 서버가 자동으로 다시 시작되지 않을 수 있음
      특정 상황에서 OpenStack 관리 서버가 자동으로 다시 시작되지 않습니다. 예를 들어 페일오버 이벤트가 발생한 후 모든 OpenStack 서비스가 성공적으로 다시 시작되지만 OpenStack 관리 서버에는 연결하지 못할 수 있습니다.

      해결 방법: vSphere Web Client에서 VMware Integrated OpenStack vApp을 수동으로 다시 시작합니다. 인벤토리 페이지에서 아이콘을 마우스 오른쪽 버튼으로 클릭하고 종료를 선택합니다. 모든 서비스가 종료된 후 vApp 전원을 켭니다. 다시 시작 작업이 성공했는지 OpenStack 관리자 로그에서 확인합니다.

    • 메타데이터 서비스는 게이트웨이 없음 옵션으로 생성된 서브넷에서 액세스할 수 없음

      서브넷이 게이트웨이 없음 옵션을 사용하여 생성된 경우 메타데이터 트래픽을 캡처할 라우터 Edge가 없습니다.

      해결 방법:게이트웨이 없음 옵션으로 구성된 네트워크의 경우 트래픽을 DHCP Edge IP 주소에 전달하도록 169.254.169.254/32에 대한 경로를 구성합니다.

    • 컨트롤러 가상 시스템이 재부팅되는 경우 고가용성이 손상될 수 있음

      컨트롤러가 고가용성 설정에서 실패하는 경우 두 번째 컨트롤러가 계속해서 서비스를 제공합니다. 하지만 초기 컨트롤러가 재부팅되는 경우 서비스를 제공하기 시작하지 않을 수 있습니다. 그러면 두 번째 컨트롤러가 실패한 경우 배포가 초기 컨트롤러로 다시 전환될 수 없습니다.

      해결 방법: 실패한 컨트롤러가 고가용성 설정에서 재부팅된 후 배포를 검토하여 두 컨트롤러가 서비스를 제공하는지 확인합니다. VMware Integrated OpenStack 배포를 시작 및 중지하는 방법에 대한 자세한 내용은 KB 2148892를 참조하십시오.

    • 데이터스토어 이름의 특수 문자가 Glance에서 지원되지 않음
      데이터스토어 이름에 특정 영숫자 이외 문자가 포함된 경우 데이터스토어를 Glance 서비스에 추가할 수 없습니다. 콜론(:), 쉼표(,), 슬래시(/) 및 달러 기호($) 문자는 기타 용도로 예약되었으며 Glance 데이터스토어 이름에서 허용되지 않습니다.

      해결 방법: 데이터스토어 이름에 이러한 기호를 사용하지 않습니다.

    • 이미지 업로드 시간이 길어 NotAuthenticated 오류가 발생함
      이 문제는 Icehouse 릴리스에서 처음으로 보고된 알려진 OpenStack 문제입니다. https://bugs.launchpad.net/glance/+bug/1371121을 참조하십시오.

    • 볼륨 연결이 실패해도 대시보드에 연결됨으로 표시될 수 있음
      이 문제는 Icehouse 릴리스에서 처음으로 보고된 알려진 OpenStack 문제입니다.

    • 배포 후 VMware Integrated OpenStack vApp을 통해 Syslog 설정을 수정할 수 없음

      배포 후 VMware Integrated OpenStack > 관리 서버 > 설정 편집 > vApp 옵션에서 Syslog 서버 구성을 수정할 수 없습니다.

      해결 방법: VMware Integrated OpenStack > OpenStack 클러스터 > 관리 > Syslog 서버에서 구성을 수정합니다.

    Kubernetes와 VMware Integrated OpenStack
    • 가상 IP 주소를 통해 Kubernetes API 서버에 액세스할 수 없음

      NSX-T 네트워크 환경에서 OpenStack 제공자와 함께 여러 Kubernetes 클러스터를 배포한 경우 가상 IP 주소를 사용하여 Kubernetes API 서버에 액세스하지 못할 수 있습니다.

      해결 방법: NSX-T 백엔드 서버에 로그인하고 부동 IP 주소로 로드 밸런서 가상 서버를 업데이트합니다.

    • SDDC 제공자가 있는 VDS 배포의 경우 클러스터가 활성으로 나타날 수 있지만 복구 후 외부 라우팅이 없음

      Nginx 수신 컨트롤러 포드가 복구 후 오류 상태에 있는 경우 외부 라우팅이 발생할 수 없습니다.

      해결 방법: 다음 단계를 수행하여 오류 상태를 지웁니다.

      1. 기본 서비스 계정 및 영향을 받는 Nginx 수신 컨트롤러 포드를 삭제합니다.
        kubectl delete serviceaccount default -n kube-system kubectl delete pod nginx-ingress-controller-id -n kube-system
      2. Kubernetes와 VMware Integrated OpenStack 가상 시스템에서 vkube cluster update 명령을 실행합니다.
    • 삭제된 클러스터를 복원할 수 없음

      클러스터 삭제 및 제공자 삭제 명령이 실행되면 삭제된 네트워크, 라우터 및 로드 밸런서를 복구할 수 없습니다.

      해결 방법: 없음

    • Kubernetes 클러스터 노드의 게스트 운영 체제가 다시 시작된 후 플란넬 포드가 올바르게 시작되지 않음

      Kubernetes 클러스터 노드의 게스트 운영 체제를 다시 시작하면 모든 IP 테이블 규칙이 지워집니다. 그 결과, 플란넬 포드가 올바르게 시작되지 않습니다.

      해결 방법: Kubernetes 네트워크 프록시를 다시 시작합니다. kube-proxy 프로세스를 중지할 수 있으며 hyperkube가 자동으로 새 kube-proxy 프로세스를 시작합니다.

    • 클러스터 작업이 수행될 때 "할당된 정책 없음" 오류가 표시됨

      단독 또는 공유 클러스터에 할당된 그룹의 멤버인 사용자가 클러스터에서 kubectl 유틸리티 실행과 같은 작업을 수행하는 경우 "할당된 정책 없음"이 표시될 수 있습니다. 이 문제는 인증된 사용자의 그룹 정보가 사용자 세션 중 올바르게 저장되지 않기 때문에 발생합니다.

      해결 방법: 개별 사용자를 그룹 대신 클러스터에 할당합니다.

    • SDDC 클라우드 제공자 생성이 실패하고 "dpkg: unrecoverable fatal error, aborting:" 메시지가 표시됨

      SDDC 클라우드 제공자 생성이 실패하고 가상 장치의 column-api 컨테이너 로그에 다음과 유사한 메시지가 포함됩니다.

      - docker logs column-api -fTASK [bootstrap-os : Bootstrap | Install python 2.x and pip] *******************172.18.0.2 - - [06/Sep/2017 05:47:32] "GET /runs/46a74449-7123-4574-90c2-3404dfac6641 HTTP/1.1" 200 -fatal: [k8s-node-1-2393e79d-ec6a-4e63-8f63-c6308d72496e]: FAILED! => {"changed": true, "failed": true, "rc": 100, "stderr": "Shared connection to 192.168.0.3 closed.", "stdout": "........"dpkg: unrecoverable fatal error, aborting:", " files list file for package 'python-libxml2' is missing final newline", "E: Sub-process /usr/bin/dpkg returned an error code (2)"]}"

      해결 방법: SDDC 클라우드 제공자를 삭제하고 다시 생성합니다.

    • SDDC 제공자가 있는 Kubernetes와 VMware Integrated OpenStack 가상 시스템에서 전원을 껐다가 다시 켜면 OpenStack 서비스 컨테이너가 작동을 중지하고 자동으로 다시 시작되지 않음

      하나의 SDDC 제공자가 있는 Kubernetes와 VMware Integrated OpenStack 가상 시스템이 전원이 꺼졌다가 다시 켜지면 해당 가상 시스템이 다른 호스트로 마이그레이션됩니다. Kubernetes 클러스터 생성 및 확장과 같은 제공자에 대한 후속 작업은 실패합니다.

      해결 방법: 제공자를 새로 고치려면 다음 단계를 수행합니다.

      1. Kubernetes와 VMware Integrated OpenStack 가상 시스템에서 루트 사용자로 로그인합니다.
        vkube login --insecure
      2. SDDC 제공자를 새로 고칩니다.
        vkube provider refresh sddc provider-id --insecure 

        vkube provider list --insecure 명령을 실행하여 SDDC 제공자 ID를 가져올 수 있습니다.

      1.  

    check-circle-line exclamation-circle-line close-line
    Scroll to top icon