Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

11장. Director 문제 해결

director 프로세스의 특정 단계에서 오류가 발생할 수 있습니다. 이 섹션에서는 일반적인 문제에 대한 몇 가지 진단 정보를 제공합니다.

director 구성 요소의 일반 로그를 참조하십시오.

  • /var/log 디렉터리에는 여러 OpenStack Platform 구성 요소에 대한 로그와 표준 Red Hat Enterprise Linux 애플리케이션에 대한 로그가 포함되어 있습니다.
  • journald 서비스는 여러 구성 요소에 대한 로그를 제공합니다. ironic은 openstack-ironic-apiopenstack-ironic-conductor 유닛을 제공합니다. 마찬가지로 ironic-inspectoropenstack-ironic-inspectoropenstack-ironic-inspector-dnsmasq 유닛을 사용합니다. 각각의 해당 구성 요소에 두 개 유닛 모두를 사용하십시오. 예를 들면 다음과 같습니다.

    $ sudo journalctl -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq
  • ironic-inspector는 또한 램디스크 로그를 /var/log/ironic-inspector/ramdisk/에 gz로 압축된 tar 파일로 저장합니다. 파일 이름에는 노드의 날짜, 시간 및 IPMI 주소가 포함됩니다. introspection 문제 진단에 이러한 로그를 사용하십시오.

11.1. 노드 등록 문제 해결

노드 등록 문제는 일반적으로 잘못된 노드 세부 사항 문제로 인해 발생합니다. 이 경우 ironic을 사용하여 등록된 노드 데이터 문제를 해결합니다. 다음은 몇 가지 예입니다.

할당된 포트 UUID를 확인합니다:

$ ironic node-port-list [NODE UUID]

MAC 주소를 업데이트합니다:

$ ironic port-update [PORT UUID] replace address=[NEW MAC]

다음 명령을 실행합니다:

$ ironic node-update [NODE UUID] replace driver_info/ipmi_address=[NEW IPMI ADDRESS]

11.2. 하드웨어 Introspection 문제 해결

introspection 프로세스 실행은 끝까지 완료되어야 합니다. 하지만 검색 램디스크가 응답하지 않을 경우 ironic의 검색 데몬(ironic-inspector)이 1시간(기본값) 후에 시간 초과됩니다. 경우에 따라 이는 검색 램디스크의 버그가 원인이 되는 경우도 있지만, 일반적으로는 BIOS 부팅 설정 등 잘못된 환경 구성으로 인해 설정 오류가 발생합니다.

다음은 잘못된 환경 구성이 발생하는 몇 가지 일반적인 시나리오 및 진단/해결 방법에 대한 설명입니다.

시작 노드 Introspection의 오류

일반적으로 introspection 프로세스는 ironic 서비스에 대한 복합 명령 역할을 하는 baremetal introspection을 사용합니다. 하지만 ironic-inspector으로 introspection을 직접 실행하는 경우 AVAILABLE 상태의 노드를 검색하지 못할 수 있습니다(해당 상태는 검색이 아니라 배포에 대한 상태를 의미하기 때문). 검색 전에 노드 상태를 MANAGEABLE 상태로 변경하십시오.

$ ironic node-set-provision-state [NODE UUID] manage

그런 다음 검색이 완료되면 프로비저닝 전에 다시 AVAILABLE로 변경합니다.

$ ironic node-set-provision-state [NODE UUID] provide

검색 프로세스 중지

introspection 프로세스를 중지합니다.

$ openstack baremetal introspection abort [NODE UUID]

프로세스가 시간 초과될 때까지 기다릴 수 있습니다. 필요한 경우 timeout 설정을 /etc/ironic-inspector/inspector.conf에서 다른 기간(분)으로 변경합니다.

Introspection 램디스크 할당

introspection 램디스크는 동적 로그인 요소를 사용합니다. 즉, introspection 디버깅 중에 노드에 액세스할 임시 암호 또는 SSH 키를 제공할 수 있습니다. 램디스크 액세스를 설정하려면 다음 프로세스를 사용하십시오.

  1. openssl passwd -1 명령에 임시 암호를 제공하여 MD5 해시를 생성합니다. 예를 들면 다음과 같습니다.

    $ openssl passwd -1 mytestpassword
    $1$enjRSyIw$/fYUpJwr6abFy/d.koRgQ/
  2. /httpboot/inspector.ipxe 파일을 편집하고, kernel로 시작하는 행을 찾은 다음 rootpwd 매개 변수 및 MD5 해시를 첨부합니다. 예를 들면 다음과 같습니다.

    kernel http://192.2.0.1:8088/agent.kernel ipa-inspection-callback-url=http://192.168.0.1:5050/v1/continue ipa-inspection-collectors=default,extra-hardware,logs systemd.journald.forward_to_console=yes BOOTIF=${mac} ipa-debug=1 ipa-inspection-benchmarks=cpu,mem,disk rootpwd="$1$enjRSyIw$/fYUpJwr6abFy/d.koRgQ/" selinux=0

    또는 공용 SSH 키와 함께 sshkey 매개 변수를 첨부할 수 있습니다.

    참고

    rootpwdsshkey 매개 변수에 모두 따옴표가 필요합니다.

  3. introspection을 시작하고 arp 명령 또는 DHCP 로그에서 IP 주소를 찾습니다.

    $ arp
    $ sudo journalctl -u openstack-ironic-inspector-dnsmasq
  4. 임시 암호 또는 SSH 키를 사용하여 root 사용자로 SSH 연결합니다.

    $ ssh root@192.168.24.105

Introspection 스토리지 확인

director는 OpenStack Object Storage(swift)를 사용하여 introspection 프로세스 중에 가져온 하드웨어 데이터를 저장합니다. 이 서비스가 실행 중이 아니면 introspection이 실패할 수 있습니다. OpenStack Object Storage와 관련된 모든 서비스를 확인하여 서비스가 실행 중인지 확인합니다.

$ sudo systemctl list-units openstack-swift*

11.3. 워크플로우 및 실행 문제 해결

OpenStack Workflow(mistral) 서비스는 여러 OpenStack 작업을 워크플로우에 그룹화합니다. Red Hat OpenStack Platform은 이러한 워크플로우 집합을 사용하여 CLI 및 웹 UI에 일반적인 기능을 수행합니다. 여기에는 베어 메탈 노드 제어, 검증 및 플랜 관리 및 오버클라우드 배포가 포함됩니다.

예를 들어 openstack overcloud deploy 명령을 실행할 때 OpenStack Workflow 서비스는 두 개의 워크플로우를 실행합니다. 첫 번째는 배포 플랜을 업로드합니다.

Removing the current plan files
Uploading new plan files
Started Mistral Workflow. Execution ID: aef1e8c6-a862-42de-8bce-073744ed5e6b
Plan updated

두 번째는 오버클라우드 배포를 시작합니다.

Deploying templates in the directory /tmp/tripleoclient-LhRlHX/tripleo-heat-templates
Started Mistral Workflow. Execution ID: 97b64abe-d8fc-414a-837a-1380631c764d
2016-11-28 06:29:26Z [overcloud]: CREATE_IN_PROGRESS  Stack CREATE started
2016-11-28 06:29:26Z [overcloud.Networks]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.HeatAuthEncryptionKey]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.ServiceNetMap]: CREATE_IN_PROGRESS  state changed
...

워크플로우 오브젝트

OpenStack 워크플로우는 다음 오브젝트를 사용하여 워크플로우를 추적합니다.

동작
관련 작업이 실행되면 OpenStack에서 수행하는 특정한 명령입니다. 예를 들면 쉘 스크립트 실행 또는 HTTP 요청 수행이 있습니다. 일부 OpenStack 구성 요소에는 OpenStack 워크플로우에서 사용하는 기본 제공 동작이 있습니다.
작업
실행할 동작 및 해당 동작을 실행한 결과를 정의합니다. 이러한 작업에는 일반적으로 동작 및 그러한 동작과 연관된 다른 워크플로우가 있습니다. 작업이 완료되면 작업의 성공 또는 실패 여부에 따라 워크플로우에서 다른 작업을 지시합니다.
워크플로우
함께 그룹화되고 특정 순서로 실행되는 작업 집합입니다.
실행
특정 동작, 작업 또는 워크플로우 실행을 정의합니다.

워크플로우 오류 진단

OpenStack Workflow는 지속적으로 실행 기록을 취합할 수 있으므로 특정 명령이 실패했을 경우 문제를 식별할 수 있습니다. 예를 들어 워크플로우 실행이 실패하는 경우 문제 지점을 확인할 수 있습니다. 실패한 상태 ERROR가 있는 워크플로우 실행을 표시합니다.

$ mistral execution-list | grep "ERROR"

실패한 워크플로우 실행의 UUID를 가져와서(예: 3c87a885-0d37-4af8-a471-1b392264a7f5) 실행 및 해당 출력을 표시합니다.

$ mistral execution-get 3c87a885-0d37-4af8-a471-1b392264a7f5
$ mistral execution-get-output 3c87a885-0d37-4af8-a471-1b392264a7f5

이는 실행에서 실패한 작업에 대한 정보를 제공합니다. mistral execution-get은 또한 실행에 사용된 워크플로우를 표시합니다(예: tripleo.plan_management.v1.update_deployment_plan). 다음 명령을 사용하면 전체 워크플로우 정의를 볼 수 있습니다.

$ mistral execution-get-definition tripleo.plan_management.v1.update_deployment_plan

이 명령은 워크플로우에서 특정 작업이 발생한 위치를 식별하는 데 유용합니다.

비슷한 명령 구문을 사용하여 작업 실행 및 해당 결과를 볼 수도 있습니다.

$ mistral action-execution-list
$ mistral action-execution-get b59245bf-7183-4fcf-9508-c83ec1a26908
$ mistral action-execution-get-output b59245bf-7183-4fcf-9508-c83ec1a26908

이는 문제의 원인이 되는 특정 작업을 식별하는 데 유용합니다.

11.4. 오버클라우드 생성 문제 해결

배포가 실패할 수 있는 세 가지 계층이 있습니다.

  • 오케스트레이션 (heat 및 nova 서비스)
  • 베어 메탈 프로비저닝 (ironic 서비스)
  • 배포 후 구성(Puppet)

오버클라우드 배포가 이러한 수준에서 실패한 경우 OpenStack 클라이언트 및 서비스 로그 파일을 사용하여 실패한 배포를 진단합니다.

11.4.1. 오케스트레이션

대부분의 경우 Heat는 오버클라우드 생성 실패 후에 실패한 오버클라우드 스택을 표시합니다.

$ heat stack-list
+-----------------------+------------+--------------------+----------------------+
| id                    | stack_name | stack_status       | creation_time        |
+-----------------------+------------+--------------------+----------------------+
| 7e88af95-535c-4a55... | overcloud  | CREATE_FAILED      | 2015-04-06T17:57:16Z |
+-----------------------+------------+--------------------+----------------------+

스택 목록이 비어 있으면 초기 Heat 설정에 문제가 있음을 나타냅니다. Heat 템플릿 및 구성 옵션을 확인하고, openstack overcloud deploy 실행 후 표시된 오류 메시지를 확인합니다.

11.4.2. 베어 메탈 프로비저닝

ironic에서 등록된 모든 노드와 노드의 현재 상태를 확인합니다.

$ ironic node-list

+----------+------+---------------+-------------+-----------------+-------------+
| UUID     | Name | Instance UUID | Power State | Provision State | Maintenance |
+----------+------+---------------+-------------+-----------------+-------------+
| f1e261...| None | None          | power off   | available       | False       |
| f0b8c1...| None | None          | power off   | available       | False       |
+----------+------+---------------+-------------+-----------------+-------------+

다음은 프로비저닝 프로세스에서 발생하는 몇 가지 일반적인 문제입니다.

  • 결과 테이블에서 프로비저닝 상태 및 유지보수 열을 검토합니다. 다음을 확인하십시오.

    • 빈 테이블 또는 예상보다 적은 노드
    • 유지보수가 True로 설정되어 있는지 여부
    • 프로비저닝 상태가 manageable로 설정되어 있음. 이는 일반적으로 등록 또는 검색 프로세스에 문제가 있음을 나타냅니다. 예를 들어 유지보수가 자동으로 True로 설정되어 있으면 일반적으로 노드에서 잘못된 전원 관리 인증서를 사용하는 것입니다.
  • 프로비저닝 상태가 available이면 베어 메탈 배포가 시작되기 전에 문제가 발생한 것입니다.
  • 프로비저닝 상태가 active이고 전원 상태가 power on이면 베어 메탈 배포가 성공적으로 완료된 것입니다. 즉, 배포 후 구성 단계 중에 문제가 발생한 것입니다.
  • 프로비저닝 상태가 노드에 대해 wait call-back이면 베터 메탈 프로비저닝 프로세스가 이 노드에 대해 아직 완료되지 않은 것입니다. 이 상태가 변경될 때까지 기다리고, 그렇지 않은 경우 실패한 노드의 가상 콘솔에 연결하고 출력을 확인합니다.
  • 프로비저닝 상태가 error 또는 deploy failed이면 베어 메탈 프로비저닝이 이 노드에 대해 실패한 것입니다. 베어 메탈 노드의 세부 사항을 확인합니다.

    $ ironic node-show [NODE UUID]

    오류 설명이 포함된 last_error 필드를 찾습니다. 오류 메시지가 모호한 경우 로그를 사용하여 메시지를 명확히 파악할 수 있습니다.

    $ sudo journalctl -u openstack-ironic-conductor -u openstack-ironic-api
  • wait timeout error가 표시되고 노드 전원 상태가 power on이면 장애가 발생한 노드의 가상 콘솔에 연결하고 출력을 확인합니다.

11.4.3. 배포 후 구성

구성 단계 중에 여러 가지가 발생할 수 있습니다. 예를 들면 특정 Puppet 모듈이 설정 문제로 인해 완료되지 않을 수 있습니다. 이 섹션에서는 그러한 문제를 진단할 프로세스를 제공합니다.

오버클라우드 스택에서 리소스를 모두 나열하여 실패한 리소스를 확인합니다.

$ heat resource-list overcloud

이렇게 하면 모든 리소스 및 해당 상태 테이블이 표시됩니다. CREATE_FAILED가 있는 리소스를 찾습니다.

실패한 리소스를 표시합니다.

$ heat resource-show overcloud [FAILED RESOURCE]

resource_status_reason 필드에서 진단에 도움이 되는 정보를 확인합니다.

nova 명령을 사용하여 오버클라우드 노드의 IP 주소를 확인합니다.

$ nova list

배포된 노드 중 하나에 heat-admin 사용자로 로그인합니다. 예를 들어 스택의 리소스 목록에 Controller 노드에서 발생한 오류가 표시되면 Controller 노드에 로그인합니다. heat-admin 사용자에게 sudo 액세스 권한이 있습니다.

$ ssh heat-admin@192.168.24.14

os-collect-config 로그에서 가능한 오류 원인을 확인합니다.

$ sudo journalctl -u os-collect-config

경우에 따라 nova가 노드 전체를 배포하지 못할 수 있습니다. 오버클라우드 역할 유형 중 하나의 실패한 OS::Heat::ResourceGroup으로 이러한 상황을 알 수 있습니다. 이 경우 오류를 보려면 nova를 사용합니다.

$ nova list
$ nova show [SERVER ID]

표시되는 가장 일반적인 오류는 오류 메시지 No valid host was found입니다. 이 오류 문제 해결에 대한 자세한 내용은 11.6절. “"No Valid Host Found" 오류 문제 해결”을 참조하십시오. 그 외의 경우는 문제 해결을 위해 다음 로그 파일을 확인하십시오.

  • /var/log/nova/*
  • /var/log/heat/*
  • /var/log/ironic/*

시스템 하드웨어 및 구성에 대한 정보를 수집하는 SOS 툴셋을 사용합니다. 이 정보를 진단 목적 및 디버깅에 사용합니다. SOS는 일반적으로 기술자 및 개발자를 지원하는 데 사용됩니다. SOS는 언더클라우드와 오버클라우드 모두에서 유용합니다. sos 패키지를 설치합니다.

$ sudo yum install sos

보고서를 생성합니다.

$ sudo sosreport --all-logs

Controller 노드에 대한 배포 후 프로세스는 배포를 위해 5가지 기본 단계를 사용합니다.

표 11.1. Controller 노드 구성 단계

단계

설명

ControllerDeployment_Step1

Pacemaker, RabbitMQ, Memcached, Redis 및 Galera를 포함한 로드 밸런싱 소프트웨어의 초기 구성.

ControllerDeployment_Step2

Pacemaker 구성, HAProxy, MongoDB, Galera, Ceph 모니터 및 OpenStack Platform 서비스에 대한 데이터베이스 초기화를 포함한 초기 클러스터 구성.

ControllerDeployment_Step3

OpenStack Object Storage(swift)에 대한 초기 링 빌드. 모든 OpenStack Platform 서비스 (nova, neutron, cinder, sahara, ceilometer, heat, horizon, aodh, gnocchi) 구성.

ControllerDeployment_Step4

서비스 시작 순서 및 서비스 시작 매개 변수를 결정하는 제한 사항을 포함하여 Pacemaker에서 서비스 시작 설정 구성.

ControllerDeployment_Step5

OpenStack Identity(keystone)의 프로젝트, 역할 및 사용자의 초기 구성.

11.5. 프로비저닝 네트워크에서 IP 주소 충돌 문제 해결

대상 호스트가 이미 사용 중인 할당된 IP 주소이면 검색 및 배포 작업이 실패합니다. 이 문제가 발생하지 않도록 하려면 프로비저닝 네트워크의 포트 스캔을 수행하여 검색 IP 범위 및 호스트 IP 범위를 사용할 수 있는지 확인합니다.

언더클라우드 호스트에서 다음 단계를 수행합니다.

nmap을 설치합니다.

# yum install nmap

nmap을 사용하여 활성 주소에 대한 IP 주소 범위를 스캔합니다. 이 예에서는 192.168.24.0/24 범위를 스캔하고, 이 범위를 프로비저닝 네트워크의 IP 서브넷으로 교체합니다(CIDR 비트마스크 표기 사용).

# nmap -sn 192.168.24.0/24

nmap 스캔 출력을 검토합니다.

예를 들어 언더클라우드의 IP 주소 및 서브넷에 있는 다른 호스트가 표시됩니다. 활성 IP 주소가 undercloud.conf의 IP 범위와 충돌하는 경우 IP 주소 범위를 변경하거나 IP 주소가 사용 가능하도록 설정한 후에 오버클라우드 노드를 introspect하거나 배포해야 합니다.

# nmap -sn 192.168.24.0/24

Starting Nmap 6.40 ( http://nmap.org ) at 2015-10-02 15:14 EDT
Nmap scan report for 192.168.24.1
Host is up (0.00057s latency).
Nmap scan report for 192.168.24.2
Host is up (0.00048s latency).
Nmap scan report for 192.168.24.3
Host is up (0.00045s latency).
Nmap scan report for 192.168.24.5
Host is up (0.00040s latency).
Nmap scan report for 192.168.24.9
Host is up (0.00019s latency).
Nmap done: 256 IP addresses (5 hosts up) scanned in 2.45 seconds

11.6. "No Valid Host Found" 오류 문제 해결

/var/log/nova/nova-conductor.log에 다음 오류가 포함되는 경우가 있습니다.

NoValidHost: No valid host was found. There are not enough hosts available.

이는 nova 스케줄러가 새 인스턴스 부팅에 적합한 베어 메탈 노드를 찾을 수 없음을 의미하며, 결국은 nova에서 찾아야 하는 리소스와 ironic에서 nova에 통지한 리소스가 일치하지 않음을 의미합니다. 이런 경우 다음을 확인하십시오.

  1. introspection이 성공했는지 확인합니다. 그렇지 않으면 각 노드에 필수 ironic 노드 속성이 포함되어 있는지 확인합니다. 각 노드에 대해 다음을 수행합니다.

    $ ironic node-show [NODE UUID]

    properties JSON 필드에 cpus, cpu_arch, memory_mblocal_gb 키에 대한 올바른 값이 있는지 확인합니다.

  2. 사용된 nova 플레이버가 필요한 노드 수에 대해 위의 ironic 노드 속성을 초과하지 않는지 확인합니다.

    $ nova flavor-show [FLAVOR NAME]
  3. ironic node-list에 따라 available 상태의 노드가 충분한지 확인합니다. manageable 상태의 노드란 일반적으로 실패한 introspection을 의미합니다.
  4. 노드가 유지보수 모드에 있지 않은지 확인합니다. ironic node-list를 사용하여 확인합니다. 유지보수 모드로 자동으로 변경되는 노드는 전원 인증서가 잘못된 것입니다. 이러한 노드를 확인한 다음 유지보수 모드를 제거합니다.

    $ ironic node-set-maintenance [NODE UUID] off
  5. AHC(Automated Health Check) 툴을 사용하여 자동 노드 태깅을 수행하는 경우 각 플레이버/프로필에 해당하는 충분한 노드가 있는지 확인합니다. properties 필드에서 ironic node-show에 대한 capabilities 키를 확인합니다. 예를 들면 Compute 역할에 대해 태그된 노드에는 profile:compute가 포함되어 있어야 합니다.
  6. introspection 후 노드 정보가 ironic에서 nova로 반영되는 데에는 시간이 걸립니다. director 툴에서 일반적으로 이를 수행합니다. 하지만 일부 단계를 수동으로 수행하는 경우 단시간 동안 노드를 nova에서 사용할 수 없습니다. 다음 명령을 사용하여 시스템에서 총 리소스를 확인합니다.

    $ nova hypervisor-stats

11.7. 오버클라우드 생성 후 문제 해결

오버클라우드 생성 후 나중에 특정 오버클라우드 작업을 수행할 수 있습니다. 예를 들어 사용 가능한 노드를 확장하거나 문제가 발생한 노드를 교체할 수 있습니다. 이러한 작업을 수행할 때 특정 문제가 발생할 수 있습니다. 이 섹션에서는 생성 후 작업 실패 문제를 진단하고 해결하는 몇 가지 방법을 설명합니다.

11.7.1. 오버클라우드 스택 수정

director를 통해 overcloud 스택을 수정할 때 문제가 발생할 수 있습니다. 스택 수정의 예는 다음과 같습니다.

  • 노드 확장
  • 노드 제거
  • 노드 교체

director가 요청한 노드 수의 가용성 확인, 추가 노드 프로비저닝 또는 기존 노드 제거 후 Puppet 구성 적용을 수행한다는 점에서 스택 수정은 스택 생성 프로세스와 비슷합니다. 다음은 overcloud 스택을 수정할 때 따라야 하는 몇 가지 지침입니다.

초기 단계로 11.4.3절. “배포 후 구성”에 설정된 지침을 따릅니다. 동일한 단계가 overcloud heat 스택 업데이트 시 문제를 진단하는 데에도 도움이 될 수 있습니다. 특히, 다음 명령을 사용하면 문제가 있는 리소스를 식별하는 데 도움이 됩니다.

heat stack-list --show-nested
모든 스택을 나열합니다. --show-nested는 모든 하위 스택과 해당 상위 스택을 표시합니다. 이 명령은 스택이 실패한 지점을 식별하는 데 도움이 됩니다.
heat resource-list overcloud
overcloud 스택의 모든 리소스 및 리소스의 현재 상태를 나열합니다. 이는 스택에서 오류를 일으키는 리소스를 식별하는 데 도움이 됩니다. heat 템플릿 컬렉션 및 Puppet 모듈에서 이 리소스 오류에 대해 해당 매개 변수와 구성으로 추적할 수 있습니다.
heat event-list overcloud
overcloud 스택과 관련된 모든 이벤트를 시간 순으로 나열합니다. 여기에는 스택에 있는 모든 리소스의 시작, 완료 및 오류가 포함됩니다. 이는 리소스 오류 지점을 식별하는 데 도움이 됩니다.

다음의 일부 섹션에서는 특정 노드 유형에 대한 문제 진단 지침을 제공합니다.

11.7.2. Controller 서비스 오류

오버클라우드 Controller 노드에는 대부분의 Red Hat OpenStack Platform 서비스가 포함되어 있습니다. 마찬가지로 고가용성 클러스터에서 여러 Controller 노드를 사용할 수 있습니다. 노드의 특정 서비스에 문제가 발생하면 고가용성 클러스터에서 특정 수준의 페일오버를 제공합니다. 하지만 문제가 발생한 서비스를 진단하여 오버클라우드가 최대 성능으로 작동하는지 확인해야 합니다.

Controller 노드는 Pacemaker를 사용하여 고가용성 클러스터에서 리소스 및 서비스를 관리합니다. Pacemaker Configuration System(pcs) 명령은 Pacemaker 클러스터를 관리하는 툴입니다. 클러스터의 Controller 노드에서 이 명령을 실행하여 구성 및 모니터링 기능을 수행합니다. 다음은 고가용성 클러스터에서 오버클라우드 서비스 문제를 해결하는 데 도움이 되는 몇 가지 명령입니다.

pcs status
활성화된 리소스, 실패한 리소스 및 온라인 노드를 포함하여 전체 클러스터에 대한 상태 개요를 제공합니다.
pcs resource show
리소스 목록 및 리소스의 해당 노드를 표시합니다.
pcs resource disable [resource]
특정 리소스를 중지합니다.
pcs resource enable [resource]
특정 리소스를 시작합니다.
pcs cluster standby [node]
노드를 대기 모드로 전환합니다. 노드를 클러스터에서 더 이상 사용할 수 없습니다. 클러스터에 영향을 주지 않고 특정 노드에서 유지보수를 수행하는 데 유용합니다.
pcs cluster unstandby [node]
대기 모드에서 노드를 제거합니다. 이 노드는 클러스터에서 다시 사용 가능하게 됩니다.

이러한 Pacemaker 명령을 사용하여 문제가 있는 구성 요소 및/또는 노드를 식별합니다. 구성 요소를 식별한 후에 /var/log/의 해당 구성 요소 로그 파일을 확인합니다.

11.7.3. Compute 서비스 오류

Compute 노드는 Compute 서비스를 사용하여 하이퍼바이저 기반 작업을 수행합니다. 이는 Compute 노드에 대한 기본 진단으로 이 서비스에 대한 문제를 해결할 수 있음을 의미합니다. 예를 들면 다음과 같습니다.

  • 다음 systemd 기능을 사용하여 서비스 상태를 확인합니다.

    $ sudo systemctl status openstack-nova-compute.service

    마찬가지로 다음 명령을 사용하여 서비스에 대한 systemd 저널을 확인합니다.

    $ sudo journalctl -u openstack-nova-compute.service
  • Compute 노드에 대한 기본 로그 파일은 /var/log/nova/nova-compute.log입니다. Compute 노드 통신에 문제가 발생하는 경우 일반적으로 이 로그 파일을 사용하여 진단을 시작하는 것이 좋습니다.
  • Compute 노드에서 유지보수를 수행하는 경우 기존 인스턴스를 호스트에서 운영 가능한 Compute 노드로 마이그레이션한 다음 해당 노드를 비활성화합니다. 노드 마이그레이션에 대한 자세한 내용은 8.8절. “오버클라우드 Compute 노드에서 VM 마이그레이션”을 참조하십시오.

11.7.4. Ceph Storage 서비스 오류

Red Hat Ceph Storage 클러스터에 발생한 문제에 대해서는 Red Hat Ceph Storage 구성 가이드의 10장. 로깅 및 디버깅을 참조하십시오. 이 섹션에서는 모든 Ceph Storage 서비스에 대한 진단 로그 정보를 제공합니다.

11.8. 언더클라우드 성능 조정

이 섹션의 지침은 언더클라우드의 성능 향상을 지원하기 위한 것입니다. 필요에 따라 권장사항을 구현하십시오.

  • Identity 서비스(keystone)는 다른 OpenStack 서비스에 대한 액세스 제어에 토큰 기반 시스템을 사용합니다. 일정한 기간이 지나면 데이터베이스에는 사용하지 않는 많은 토큰이 누적됩니다. 기본 cronjob은 매일 토큰 테이블을 플러시합니다. 환경을 모니터링하고 토큰 플러시 간격을 필요에 따라 조정하는 것이 좋습니다. 언더클라우드에 대해 crontab -u keystone -e를 사용하여 간격을 조정할 수 있습니다. 이러한 변경은 일시적인 것으로 openstack undercloud update를 실행하면 이 cronjob이 다시 해당 기본값으로 재설정됩니다.
  • Heat는 openstack overcloud deploy를 실행할 때마다 모든 템플릿 파일 복사본을 해당 데이터베이스의 raw_template 테이블에 저장합니다. raw_template 테이블은 이전의 모든 템플릿을 유지하고 크기를 늘립니다. raw_templates 테이블에서 사용하지 않는 템플릿을 제거하려면 사용하지 않고 하루 이상 데이터베이스에 있는 템플릿을 지우는 일별 cronjob을 생성하십시오.

    0 04 * * * /bin/heat-manage purge_deleted -g days 1
  • openstack-heat-engineopenstack-heat-api 서비스가 너무 많은 리소스를 사용하는 경우가 있습니다. 그런 경우 /etc/heat/heat.conf에서 max_resources_per_stack=-1을 설정하고 heat 서비스를 다시 시작하십시오.

    $ sudo systemctl restart openstack-heat-engine openstack-heat-api
  • director에 리소스가 부족하여 동시 모드 프로비저닝을 수행하지 못하는 경우가 있습니다. 기본값은 동시에 10개 노드입니다. 동시 노드 수를 줄이려면 /etc/nova/nova.conf에서 max_concurrent_builds 매개 변수를 10보다 작은 값으로 설정하고 nova 서비스를 다시 시작하십시오.

    $ sudo systemctl restart openstack-nova-api openstack-nova-scheduler
  • /etc/my.cnf.d/server.cnf 파일을 편집하십시오. 조정이 권장되는 값은 다음과 같습니다.

    max_connections
    데이터베이스에 대한 동시 연결 수입니다. 권장 값은 4096입니다.
    innodb_additional_mem_pool_size
    데이터베이스에서 데이터 사전 정보와 기타 내부 데이터 구조를 저장하는 데 사용하는 메모리 풀 크기(바이트)입니다. 언더클라우드에 대한 기본값은 일반적으로 8M이며, 이상적인 값은 20M입니다.
    innodb_buffer_pool_size
    데이터베이스에서 테이블 및 인덱스 데이터를 캐시하는 메모리 영역의 버퍼 풀 크기(바이트)입니다. 언더클라우드에 대한 기본값은 일반적으로 128M이며, 이상적인 값은 1000M입니다.
    innodb_flush_log_at_trx_commit
    커밋 관련 I/O 작업이 재정렬되고 배치로 수행되는 경우 가능한 고성능 및 커밋 작업을 위한 엄격한 ACID 준수 간 조정을 제어합니다. 1로 설정됩니다.
    innodb_lock_wait_timeout
    데이터베이스 트랜잭션이 중단될 때까지 행 잠금을 기다리는 시간(초)입니다. 50으로 설정됩니다.
    innodb_max_purge_lag
    이 변수는 제거 작업이 지연될 때 INSERT, UPDATE 및 DELETE 작업을 지연하는 방법을 제어합니다. 10000으로 설정합니다.
    innodb_thread_concurrency
    동시 작동하는 시스템 스레드 제한 수입니다. 각 CPU 및 디스크 리소스에 대해 적어도 두 개의 스레드를 제공하는 것이 좋습니다. 예를 들어 쿼드 코어 CPU 및 단일 디스크를 사용하는 경우 10개 스레드를 사용합니다.
  • heat에 오버클라우드 생성을 수행할 충분한 작업자가 있는지 확인하십시오. 일반적으로 언더클라우드에 있는 CPU 수에 따라 다릅니다. 작업자 수를 수동으로 설정하려면 /etc/heat/heat.conf 파일을 편집하고,num_engine_workers 매개 변수를 필요한 작업자 수(4가 이상적임)로 설정한 다음 heat 엔진을 다시 시작합니다.

    $ sudo systemctl restart openstack-heat-engine

11.9. 언더클라우드 및 오버클라우드 관련 중요 로그

문제를 해결할 때 다음 로그를 사용하여 언더클라우드 및 오버클라우드에 대한 정보를 찾습니다.

표 11.2. 언더클라우드 관련 중요 로그

정보로그 위치

OpenStack Compute 로그

/var/log/nova/nova-compute.log

OpenStack Compute API 상호 작용

/var/log/nova/nova-api.log

OpenStack Compute Conductor 로그

/var/log/nova/nova-conductor.log

OpenStack Orchestration 로그

heat-engine.log

OpenStack Orchestration API 상호 작용

heat-api.log

OpenStack Orchestration CloudFormations 로그

/var/log/heat/heat-api-cfn.log

OpenStack Bare Metal Conductor 로그

ironic-conductor.log

OpenStack Bare Metal API 상호 작용

ironic-api.log

Introspection

/var/log/ironic-inspector/ironic-inspector.log

OpenStack Workflow Engine 로그

/var/log/mistral/engine.log

OpenStack Workflow Executor 로그

/var/log/mistral/executor.log

OpenStack Workflow API 상호 작용

/var/log/mistral/api.log

표 11.3. 오버클라우드 관련 중요 로그

정보로그 위치

Cloud-Init 로그

/var/log/cloud-init.log

오버클라우드 구성(마지막 Puppet 실행 요약)

/var/lib/puppet/state/last_run_summary.yaml

오버클라우드 구성(마지막 Puppet 실행 보고서)

/var/lib/puppet/state/last_run_report.yaml

오버클라우드 구성(전체 Puppet 보고서)

/var/lib/puppet/reports/overcloud-*/*

오버클라우드 구성(각 Puppet 실행의 stdout)

/var/run/heat-config/deployed/*-stdout.log

오버클라우드 구성(각 Puppet 실행의 stderr)

/var/run/heat-config/deployed/*-stderr.log

고가용성 로그

/var/log/pacemaker.log