특정 Red Hat OpenStack Platform 서비스에 대한 배포 권장 사항

Red Hat OpenStack Platform 16.2

Red Hat OpenStack Platform Telemetry 및 Object Storage 서비스의 성능 극대화

OpenStack Documentation Team

초록

Red Hat OpenStack Platform을 director와 함께 배포할 때 이러한 권장 사항을 따르면 많은 성능 문제를 해결할 수 있습니다.

1장. 오버클라우드 최적화 이유

대규모 오버클라우드로 확장하거나 배포하려는 경우 워크로드가 증가함에 따라 잠재적인 성능 문제를 방지하기 위해 오버클라우드를 최적화합니다. 이러한 권장 사항에 따라 오버클라우드 내의 스케일링이 원격 분석 서비스 및 오브젝트 스토리지 서비스의 성능에 영향을 미치지 않도록 할 수 있습니다.

2장. Telemetry 서비스의 구성 권장 사항

RHOSP(Red Hat OpenStack Platform) Telemetry 서비스는 CPU를 많이 사용하므로 RHOSP 16.2에서 Telemetry를 기본적으로 사용하도록 설정되어 있지 않습니다. 그러나 이러한 배포 권장 사항에 따라 Telemetry를 활성화하는 경우 성능 저하를 방지할 수 있습니다.

이러한 절차-작은 테스트 오버클라우드용이고 하나는 대규모 프로덕션 overcloud용 오버클라우드용입니다.원격 분석 서비스 성능을 최대화하는 권장 사항을 포함합니다.

2.1. 소규모 테스트 오버클라우드에서 Telemetry 서비스 구성

작은 테스트 오버클라우드에서 RHOSP(Red Hat OpenStack Platform) 원격 분석 서비스를 활성화하면 파일 백엔드를 사용하여 성능을 향상시킬 수 있습니다.

사전 요구 사항

  • 원격 분석 서비스를 구성하는 오버클라우드 배포는 프로덕션 시스템이 아닙니다.
  • 오버클라우드는 100개 이하의 인스턴스를 지원하며 각 컨트롤러 노드에서 최대 12개의 물리적 코어 또는 하이퍼 스레딩이 활성화된 24개의 코어를 지원하는 소규모 배포입니다.
  • Overcloud 배포의 고가용성이 비활성화되었습니다.

절차

  1. /usr/share/openstack-tripleo-heat-templates/environments/enable-legacy-telemetry.yaml 환경 파일에서 parameter_defaults 에 다음을 추가합니다.

    parameter_defaults:
      GnocchiBackend: file
  2. openstack overcloud deploy 명령에 enable-legacy-telemetry.yaml 파일을 추가합니다.

    openstack overcloud deploy \
    -e /home/stack/environment.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/enable-legacy-telemetry.yaml \
    [...]

추가 리소스

2.2. 대규모 프로덕션 오버클라우드에서 원격 분석 서비스 구성

대규모 프로덕션 오버클라우드에서 RHOSP(Red Hat OpenStack Platform) 원격 분석 서비스를 활성화하면 전용 노드에 Telemetry 서비스를 배포하여 성능을 개선할 수 있습니다.

원격 분석 서비스에서는 스토리지 백엔드로 선택한 RHOSP 오브젝트 저장소를 사용합니다. Red Hat Ceph Storage를 활성화하지 않으면 원격 분석 서비스에서 RHOSP Object Storage 서비스(swift)를 사용합니다. 기본적으로 RHOSP director는 컨트롤러의 Telemetry 서비스와 Object Storage 서비스를 함께 배치합니다.

주의

시계열 데이터베이스(gnocchi) 스토리지에 RHOSP Object Storage(swift) 사용은 소규모 및 비프로덕션 환경에서만 지원됩니다.

사전 요구 사항

  • 원격 분석 서비스를 배포하는 오버클라우드는 대규모 프로덕션 오버클라우드입니다.

절차

  1. 전용 원격 분석 노드를 설정하려면 Controller 역할에서 Telemetry 서비스를 제거합니다.

    /usr/share/openstack-tripleo-heat-templates/roles_data.yaml을 /home/stack/templates/roles_data.yaml로 복사하여 오케스트레이션 서비스(heat ) 사용자 지정 환경 파일을 만듭니다.

  2. /home/stack/templates/roles_data.yaml 에서 Controller 역할의 ServicesDefault 목록에서 다음 행을 제거합니다.

        - OS::TripleO::Services::CeilometerAgentCentral
        - OS::TripleO::Services::CeilometerAgentNotification
        - OS::TripleO::Services::GnocchiApi
        - OS::TripleO::Services::GnocchiMetricd
        - OS::TripleO::Services::GnocchiStatsd
        - OS::TripleO::Services::AodhApi
        - OS::TripleO::Services::AodhEvaluator
        - OS::TripleO::Services::AodhNotifier
        - OS::TripleO::Services::AodhListener
        - OS::TripleO::Services::PankoApi
        - OS::TripleO::Services::CeilometerAgentIpmi
  3. 다음 스니펫을 추가하고 roles_data.yaml을 저장합니다.

    - name: Telemetry
      ServicesDefault:
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::CertmongerUser
        - OS::TripleO::Services::Kernel
        - OS::TripleO::Services::Ntp
        - OS::TripleO::Services::Timezone
        - OS::TripleO::Services::Snmp
        - OS::TripleO::Services::Sshd
        - OS::TripleO::Services::Securetty
        - OS::TripleO::Services::TripleoPackages
        - OS::TripleO::Services::TripleoFirewall
        - OS::TripleO::Services::SensuClient
        - OS::TripleO::Services::FluentdClient
        - OS::TripleO::Services::AuditD
        - OS::TripleO::Services::Collectd
        - OS::TripleO::Services::MySQLClient
        - OS::TripleO::Services::Docker
        - OS::TripleO::Services::CeilometerAgentCentral
        - OS::TripleO::Services::CeilometerAgentNotification
        - OS::TripleO::Services::GnocchiApi
        - OS::TripleO::Services::GnocchiMetricd
        - OS::TripleO::Services::GnocchiStatsd
        - OS::TripleO::Services::AodhApi
        - OS::TripleO::Services::AodhEvaluator
        - OS::TripleO::Services::AodhNotifier
        - OS::TripleO::Services::AodhListener
        - OS::TripleO::Services::PankoApi
        - OS::TripleO::Services::CeilometerAgentIpmi
  4. /home/stack/node-info.yaml 파일에서 Telemetry 서비스의 전용 노드 수를 설정합니다.

    예를 들어 TelemetryCount를 추가합니다. 3 parameter_defaults 로 이동하여 세 개의 전용 Telemetry 노드를 배포합니다.

    parameter_defaults:
      TelemetryCount: 3

    이제 사용자 지정 Telemetry 역할이 있습니다.

    이 역할을 사용하면 특정 원격 분석 노드를 태그하고 할당할 새 플레이버를 정의할 수 있습니다.

  5. 오버클라우드를 배포할 때 openstack overcloud deploy 명령을 호출하는 템플릿 및 환경 파일 목록에 roles_data .yaml 및 storage-environment.yaml 을 포함합니다.

    $ openstack overcloud deploy \
      -r /home/stack/templates/roles_data.yaml \
      -e /home/stack/templates/storage-environment.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/enable-legacy-telemetry.yaml \
    [...]
  6. 오브젝트 스토리지에 전용 노드를 할당할 수 없는 경우 컨트롤러 노드에서 더 낮은 전체 스토리지 I/O를 실행하도록 오브젝트 스토리지를 구성합니다.

추가 리소스

3장. Object Storage 서비스(swift)에 대한 구성 권장 사항

RHOSP(Red Hat OpenStack Platform)를 Red Hat Ceph Storage와 함께 배포하지 않으려면 RHOSP director에서 RHOSP Object Storage 서비스(swift)를 배포합니다. 오브젝트 저장소 서비스는 RHOSP 원격 분석 서비스 및 RabbitMQ를 포함하여 여러 OpenStack 서비스의 오브젝트 저장소입니다. 오브젝트 스토리지 서비스와 함께 원격 분석 서비스를 사용할 때 RHOSP 성능을 개선하기 위한 몇 가지 권장 사항은 다음과 같습니다.

3.1. 오브젝트 스토리지 서비스에 대한 디스크 권장 사항

RHOSP(Red Hat OpenStack Platform) 오브젝트 스토리지 서비스에 대해 하나 이상의 개별 로컬 디스크를 사용합니다.

기본적으로 RHOSP director는 시스템 디스크의 /srv/node/d1 디렉터리를 오브젝트 스토리지 서비스에 사용합니다. 컨트롤러의 이 디스크는 다른 서비스에서도 사용되며 원격 분석 서비스가 엔터프라이즈 설정에서 이벤트 기록을 시작한 후 디스크가 성능 병목이 될 수 있습니다.

다음 예제는 RHOSP Orchestration 서비스(heat) 사용자 지정 환경 파일에서 발췌한 것입니다. 각 컨트롤러 노드에서 Object Storage 서비스는 두 개의 개별 디스크를 사용합니다. 두 디스크 전체에는 XFS 파일 시스템이 포함되어 있습니다.

parameter_defaults:
  SwiftRawDisks: {"sdb": {}, "sdc": {}}

SwiftœwDisks 는 노드의 각 스토리지 디스크를 정의합니다. 이 예제에서는 각 컨트롤러 노드에서 sdbsdc 디스크를 모두 정의합니다.

중요

여러 디스크를 구성할 때 베어 메탈 서비스(ironic)에서 의도한 루트 디스크를 사용하는지 확인합니다.

추가 리소스

3.2. 전용 Object Storage 노드 정의

RHOSP(Red Hat OpenStack Platform) 오브젝트 스토리지 서비스에 노드를 지정하면 성능이 향상됩니다.

절차

  1. 사용자 지정 roles_data.yaml 파일을 생성합니다(기본 /usr/share/openstack-tripleo-heat-templates/roles_data.yaml기반).
  2. 컨트롤러 노드에서 Object Storage 서비스 항목을 제거하여 사용자 지정 roles_data.yaml 파일을 편집합니다.

    특히 Controller 역할의 ServicesDefault 목록에서 다음 행을 제거합니다.

        - OS::TripleO::Services::SwiftStorage
  3. 사용자 지정 환경 파일에서 ObjectStorageCount 리소스를 사용하여 오브젝트 스토리지 서비스에 할당할 전용 노드 수를 설정합니다.

    예를 들어 ObjectStorageCount를 추가합니다. 3 환경 파일의 parameter_defaults 로 이동하여 전용 오브젝트 스토리지 노드 3개를 배포합니다.

    parameter_defaults:
      ObjectStorageCount: 3
  4. 이 구성을 적용하려면 오버클라우드를 배포하고 roles_data.yaml 을 다른 환경 파일과 함께 스택에 추가합니다.

    (undercloud) $ openstack overcloud deploy --templates \
      -e [your environment files]
      -e /home/stack/templates/roles_data.yaml

추가 리소스

3.3. 오브젝트 스토리지 서비스에 대한 전원 권장 사항 파티션

별도의 RHOSP(Red Hat OpenStack Platform) Object Storage 서비스 노드를 사용하는 경우 더 높은 파티션 전원 값을 사용합니다.

오브젝트 스토리지 서비스는 수정된 해시 링 을 사용하여 디스크와 노드에 데이터를 배포합니다. 기본적으로 링은 계정용 1개, 컨테이너용 1개, 오브젝트용 링 3개가 있습니다. 각 링은 파티션 파워 라는 고정 매개 변수를 사용합니다. 이 매개 변수는 생성할 수 있는 최대 파티션 수를 설정합니다.

파티션 전원 매개 변수는 중요하며 새 컨테이너 및 해당 오브젝트에 대해서만 변경할 수 있습니다. 따라서 초기 배포 전에 이 값을 설정하는 것이 중요합니다.

RHOSP director가 배포하는 환경의 기본 파티션 전원 값은 10 입니다. 특히 오브젝트 스토리지 서비스에 대해 컨트롤러 노드에서 디스크를 사용할 계획인 경우 소규모 배포에 적합한 값입니다.

다음 표는 세 개의 복제본을 사용하는 경우 적절한 파티션 파워를 선택하는 데 도움이 됩니다.

표 3.1. 사용 가능한 디스크 수당 적절한 파티션 전원 값

파티션 전원

최대 디스크 수

10

~ 35

11

~ 75

12

~ 150

13

~ 250

14

~ 500

중요

과도한 높은 파티션 전원 값(예: 40개의 디스크의 경우 14 )을 설정하면 복제 시간에 부정적인 영향을 미칩니다.

파티션 전원을 설정하려면 다음 리소스를 사용합니다.

parameter_defaults:
  SwiftPartPower: 11
작은 정보

새 컨테이너에 대한 추가 오브젝트 서버 링을 구성할 수도 있습니다. 초기에 파티션의 전원을 적게 사용하는 오브젝트 스토리지 서비스 배포에 디스크를 추가하려는 경우 유용합니다.

추가 리소스

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.