16장. 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 유닛을 사용합니다. 각각의 해당 구성 요소에 두 개 유닛 모두를 사용하십시오. 예를 들면 다음과 같습니다.

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

16.1. 노드 등록 문제 해결

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

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

$ source ~/stackrc
(undercloud) $ openstack baremetal port list --node [NODE UUID]

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

(undercloud) $ openstack baremetal port set --address=[NEW MAC] [PORT UUID]

다음 명령을 실행합니다:

(undercloud) $ openstack baremetal node set --driver-info ipmi_address=[NEW IPMI ADDRESS] [NODE UUID]

16.2. 하드웨어 인트로스펙션 문제 해결

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

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

시작 노드 인트로스펙션의 오류

일반적으로 인트로스펙션 프로세스는 openstack overcloud node introspect 명령을 사용합니다. 하지만 ironic-inspector로 인트로스펙션을 직접 실행하는 경우 검색이 아니라 배포에 대한 상태를 의미하는 AVAILABLE 상태의 노드를 검색하지 못할 수 있습니다. 검색 전에 노드 상태를 MANAGEABLE 상태로 변경하십시오.

$ source ~/stackrc
(undercloud) $ openstack baremetal node manage [NODE UUID]

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

(undercloud) $ openstack baremetal node provide [NODE UUID]

검색 프로세스 중지

인트로스펙션 프로세스를 중지합니다.

$ source ~/stackrc
(undercloud) $ openstack baremetal introspection abort [NODE UUID]

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

인트로스펙션 램디스크에 액세스

인트로스펙션 램디스크는 동적 로그인 요소를 사용합니다. 즉, 인트로스펙션 디버깅 중에 노드에 액세스할 임시 암호 또는 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. 인트로스펙션을 시작하고 arp 명령 또는 DHCP 로그에서 IP 주소를 찾습니다.

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

    $ ssh root@192.168.24.105

인트로스펙션 스토리지 확인

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

$ sudo systemctl list-units openstack-swift*

16.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가 있는 워크플로우 실행을 표시합니다.

$ source ~/stackrc
(undercloud) $ openstack workflow execution list | grep "ERROR"

실패한 워크플로우 실행의 UUID를 가져와서(예: dffa96b0-f679-4cd2-a490-4769a3825262) 실행 및 해당 출력을 확인합니다.

(undercloud) $ openstack workflow execution show dffa96b0-f679-4cd2-a490-4769a3825262
(undercloud) $ openstack workflow execution output show dffa96b0-f679-4cd2-a490-4769a3825262

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

(undercloud) $ openstack workflow definition show tripleo.plan_management.v1.publish_ui_logs_to_swift

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

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

(undercloud) $ openstack action execution list
(undercloud) $ openstack action execution show 8a68eba3-0fec-4b2a-adc9-5561b007e886
(undercloud) $ openstack action execution output show 8a68eba3-0fec-4b2a-adc9-5561b007e886

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

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

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

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

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

16.4.1. 배포 명령 내역 액세스

이전의 director 배포 명령 및 인수를 이해하면 문제를 해결하고 지원하는 데 유용합니다. 해당 내용은 /home/stack/.tripleo/history에서 확인할 수 있습니다.

16.4.2. 오케스트레이션

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

$ source ~/stackrc
(undercloud) $ openstack stack list --nested --property status=FAILED
+-----------------------+------------+--------------------+----------------------+
| id                    | stack_name | stack_status       | creation_time        |
+-----------------------+------------+--------------------+----------------------+
| 7e88af95-535c-4a55... | overcloud  | CREATE_FAILED      | 2015-04-06T17:57:16Z |
+-----------------------+------------+--------------------+----------------------+

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

16.4.3. 베어 메탈 프로비저닝

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

$ source ~/stackrc
(undercloud) $ openstack baremetal 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이면 베어 메탈 프로비저닝이 이 노드에 대해 실패한 것입니다. 베어 메탈 노드의 세부 사항을 확인합니다.

    (undercloud) $ openstack baremetal node show [NODE UUID]

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

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

16.4.4. 오버클라우드 설정 오류 점검

Ansible 설정 단계에서 오버클라우드 배포 작업이 실패하면 openstack overcloud failures 명령을 사용하여 실패한 구성 단계를 표시합니다.

절차

  1. stackrc 파일을 소싱합니다.

    $ source ~/stackrc
  2. 배포 실패 명령을 실행합니다.

    $ openstack overcloud failures

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

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

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

nmap을 설치합니다.

$ sudo yum install nmap

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

$ sudo nmap -sn 192.168.24.0/24

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

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

$ sudo 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

16.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. 인트로스펙션이 성공했는지 확인합니다. 그렇지 않으면 각 노드에 필수 ironic 노드 속성이 포함되어 있는지 확인합니다. 각 노드에 대해 다음을 수행합니다.

    $ source ~/stackrc
    (undercloud) $ openstack baremetal node show [NODE UUID]

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

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

    (undercloud) $ openstack flavor show [FLAVOR NAME]
  3. openstack baremetal node list에 따라 available 상태의 노드가 충분한지 확인합니다. manageable 상태의 노드란 일반적으로 실패한 인트로스펙션을 의미합니다.
  4. 노드가 유지보수 모드가 아닌지 확인합니다. 확인에는 openstack baremetal node list를 사용합니다. 유지보수 모드로 자동 변경되는 노드는 전원 인증 정보가 잘못된 것입니다. 해당 노드를 확인한 다음 유지보수 모드를 제거합니다.

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

    (undercloud) $ openstack hypervisor stats show

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

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

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

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

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

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

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

16.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/의 해당 구성 요소 로그 파일을 확인합니다.

16.7.3. 컨테이너화된 서비스 오류

오버클라우드 배포 중 또는 이후에 컨테이너화된 서비스 오류가 발생하면 다음 권장 사항에 따라 오류의 근본 원인을 확인하십시오.

참고

이러한 명령을 실행하기 전에 오버클라우드 노드에 로그인하고 언더클라우드에서 이러한 명령을 실행하지 않았는지 확인합니다.

컨테이너 로그 검사

각 컨테이너는 메인 프로세스의 표준 출력을 유지합니다. 이 출력은 컨테이너 실행 중 실제로 발생하는 상황을 판단하는 데 도움이 되는 로그 역할을 합니다. 예를 들어 keystone 컨테이너에 대한 로그를 보려면 다음 명령을 사용하십시오.

$ sudo docker logs keystone

대부분의 경우 이 로그는 컨테이너 오류에 대한 원인을 제공합니다.

컨테이너 검사

경우에 따라 컨테이너에 대한 정보를 확인해야 합니다. 예를 들어 다음 명령을 사용하여 keystone 컨테이너 데이터를 확인합니다.

$ sudo docker inspect keystone

이 명령은 낮은 수준의 구성 데이터를 포함하는 JSON 개체를 제공합니다. 출력을 jq 명령으로 전달하여 특정 데이터를 구문 분석할 수 있습니다. 예를 들어 keystone 컨테이너에 대한 컨테이너 마운트를 보려면 다음 명령을 실행합니다.

$ sudo docker inspect keystone | jq .[0].Mounts

또한 --format 옵션을 사용하여 단일 행에 대한 데이터를 구문 분석할 수 있으며 이는 컨테이너 데이터 세트에 대해 명령을 실행할 때 유용합니다. 예를 들어 keystone 컨테이너 실행에 사용된 옵션을 다시 생성하려면 --format 옵션과 함께 inspect 명령을 사용하십시오.

$ sudo docker inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone
참고

--format 옵션은 쿼리를 생성할 때 Go 구문을 사용합니다.

이러한 옵션을 docker run 명령과 함께 사용하므로 문제 해결을 위한 컨테이너를 다시 생성할 수 있습니다.

$ OPTIONS=$( sudo docker inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone )
$ sudo docker run --rm $OPTIONS /bin/bash

컨테이너에서 명령 실행

일부 경우에 특정 Bash 명령을 통해 컨테이너 내부의 정보를 확보해야 합니다. 이러한 경우에는 docker 명령을 사용하여 실행 중인 컨테이너 내에서 명령을 실행할 수 있습니다. 예를 들어 keystone 컨테이너에서 명령을 실행하는 방법은 다음과 같습니다.

$ sudo docker exec -ti keystone <COMMAND>
참고

-ti 옵션은 대화식 가상 터미널(pseudoterminal)에서 명령을 실행합니다.

<COMMAND>를 원하는 명령으로 대체합니다. 예를 들어 각 컨테이너에는 서비스 연결을 확인하기 위한 상태 점검 스크립트가 있습니다. 다음 명령으로 keystone에 대해 상태 확인 스크립트를 실행할 수 있습니다.

$ sudo docker exec -ti keystone /openstack/healthcheck

컨테이너의 쉘에 액세스하려면 /bin/bash를 명령으로 사용하여 docker exec을 실행합니다.

$ sudo docker exec -ti keystone /bin/bash

컨테이너 내보내기

컨테이너가 실패하면 파일의 전체 콘텐츠를 확인해야 합니다. 이 경우 컨테이너의 전체 파일 시스템을 tar 아카이브로 내보낼 수 있습니다. 예를 들어 keystone 컨테이너 파일 시스템을 내보내려면 다음 명령을 실행합니다.

$ sudo docker export keystone -o keystone.tar

이 명령은 keystone.tar 아카이브를 생성하여 추출 및 확인할 수 있습니다.

16.7.4. Compute 서비스 오류

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

  • 컨테이너 상태를 표시합니다.

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

16.7.5. Ceph Storage 서비스 오류

Red Hat Ceph Storage 클러스터에 발생한 문제에 대해서는 Red Hat Ceph Storage Configuration Guide"Logging Configuration Reference"를 확인하십시오. 이 섹션에서는 모든 Ceph Storage 서비스에 대한 진단 로그 정보를 제공합니다.

16.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

16.9. sosreport 생성

OpenStack Platform에 대해 Red Hat에 지원을 문의하는 경우 sosreport를 생성해야 합니다. sosreport 생성 방법에 대한 자세한 정보는 아래 지식 베이스 문서를 참조하십시오.

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

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

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

정보로그 위치

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

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

정보로그 위치

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


Red Hat의 최신 제품 문서 번역을 신속하게 제공하기 위해 이 페이지에는 영어 원본을 한국어로 자동 번역한 내용이 포함되어 있을 수 있습니다. [자세한 내용보기]