Compute API 서버 개념

1 개요

Server concepts

서버 개념

https://docs.openstack.org/api-guide/compute/server_concepts.html

---

OpenStack Compute API에서 서버는 가상머신(VM) 인스턴스, 물리적 머신, 컨테이너를 의미합니다.

2 서버 상태

이미지, 플레이버, 이름, 상태에 따라 서버 목록을 필터링할 수 있습니다. 각 필터는 해당 쿼리 매개변수를 통해 설정합니다.

서버에는 현재 서버 상태를 나타내는 상태 속성이 포함되어 있습니다. 서버 목록 요청을 수행할 때 서버 상태를 기준으로 필터링할 수 있습니다. 서버 상태는 응답 본문에 반환됩니다. 서버 상태는 다음 값 중 하나입니다:

서버 상태 값

• ACTIVE: 서버가 활성 상태입니다.
• BUILD: 서버가 초기 빌드 프로세스를 완료하지 않았습니다.
• DELETED: 서버가 삭제되었습니다.
• ERROR: 서버에 오류가 있습니다.
• HARD_REBOOT: 서버가 하드 재부팅 중입니다. 이는 물리 서버의 전원 플러그를 뽑았다가 다시 꽂고 재부팅하는 것과 동일합니다.
• MIGRATING: 서버가 마이그레이션 중입니다. 이는 라이브 마이그레이션(활성 상태의 서버를 이동) 작업에 의해 발생합니다.
• PASSWORD: 서버의 비밀번호가 리셋되고 있습니다.
• PAUSED: 서버가 일시중지 상태입니다.
• REBOOT: 서버가 소프트 재부팅 상태에 있습니다. 운영체제에 재부팅 명령이 전달되었습니다.
• REBUILD: 서버가 현재 이미지에서 재구성되고 있습니다.
• RESCUE: 서버가 복구 모드에 있습니다.
• RESIZE: 서버가 초기 복사본 이후 변경분 복사를 수행하고 있습니다. 이 단계에서 서버는 다운되어 있습니다.
• REVERT_RESIZE: 서버의 크기조정 또는 마이그레이션이 어떤 이유로 실패했습니다. 목적지 서버가 정리되고 원본 서버가 다시 시작되고 있습니다.
• SHELVED: 서버가 쉘브 상태에 있습니다. 쉘브 오프로드 시간에 따라 서버는 자동으로 쉘브 오프로드 됩니다.
• SHELVED_OFFLOADED: 쉘브된 서버가 오프로드(컴퓨팅 호스트에서 제거)되었으며, 다시 사용하기 위해서는 언쉘브 작업이 필요합니다.
• SHUTOFF: 사용자가 OpenStack Compute API를 통해 또는 서버 내에서 서버를 종료했습니다. 예를 들어, 사용자가 서버 내에서 shutdown -h 명령어를 실행했습니다. OpenStack Compute 매니저가 VM이 종료된 것을 감지하면 서버는 SHUTOFF 상태로 전환됩니다.
• SOFT_DELETED: 서버가 삭제된 것으로 표시되지만 설정된 시간 동안 클라우드에 남아 있습니다. 소프트 삭제된 동안 권한 있는 사용자는 서버를 정상 상태로 복원할 수 있습니다. 시간이 만료되면 서버는 영구적으로 삭제됩니다.
• SUSPENDED: 서버가 요청 또는 필요에 의해 일시중지되었습니다. 지원되는 컴퓨트 드라이버는 기능 지원 매트릭스를 참조하십시오. 서버를 일시중지하면 상태가 디스크에 저장되고 모든 메모리가 디스크에 기록되며 서버가 중지됩니다. 서버를 일시중지하는 것은 장치를 절전 모드로 전환하는 것과 유사하며, 사용된 리소스는 해제되지 않고 서버가 재개될 때까지 유지됩니다. 서버가 자주 사용되지 않고 다른 서버를 생성하기 위해 사용된 리소스를 해제해야 할 경우, 서버는 쉘브되어야 합니다.
• UNKNOWN: 서버의 상태를 알 수 없습니다. 이는 인프라의 일부가 일시적으로 다운된 경우일 수 있습니다. 자세한 내용은 "다운 셀 처리"를 참조하십시오. 클라우드 제공자에게 문의하십시오.
• VERIFY_RESIZE: 시스템이 서버의 이동 또는 크기조정 후 정상적으로 작동하는지 확인을 기다리고 있습니다.

서버 상태는, 관리자에게 노출되는 vm_state와 task_state에 따라 산출됩니다:

• vm_state: VM의 현재 안정적인(전환중이 아닌) 상태를 나타냅니다. 즉, 진행 중인 컴퓨트 API 호출(실행 중인 작업)이 없을 때, vm_state는 고객이 기대하는 VM의 상태를 반영해야 합니다. task_state와 결합하면 서버의 상태와 진행 상황에 대한 더 나은 그림을 그릴 수 있습니다. VM 상태를 참조하십시오.
• task_state: 인스턴스에서 현재 진행 중인 작업을 나타냅니다. 이러한 작업은 일반적인 작업(예: spawning)부터 특정 작업(예: block_device_mapping)까지 다양합니다. 이러한 작업 상태는 서버가 수행 중인 작업을 더 잘 파악할 수 있게 해줍니다.

3 서버 생성

상태 전환:

• BUILD

서버가 빌드되는 동안 여러 작업 상태 전환이 발생할 수 있습니다:

• scheduling: 요청이 컴퓨트 노드에 스케줄링되고 있습니다.
• networking: 네트워크 인터페이스를 비동기적으로 설정 중입니다.
• block_device_mapping: 블록 디바이스(로컬 디스크, 볼륨)를 준비 중입니다.
• spawning: 하이퍼바이저에서 게스트를 생성 중입니다.

• ACTIVE

성공적으로 빌드되고 실행 중인 서버의 최종 상태입니다.

• ERROR (오류 발생 시)

서버를 생성할 때, 이 작업은 비동기적으로 새로운 서버를 프로비저닝합니다. 이 작업의 진행 상황은 요청된 이미지의 위치, 네트워크 I/O, 호스트 로드, 선택된 플레이버 등 여러 요인에 따라 달라집니다. 요청의 진행 상황은 /servers/{server_id}에 대해 GET 요청을 수행하여 진행률 속성(0%에서 100% 완료)을 확인할 수 있습니다. 새로 생성된 서버에 대한 전체 URL은 Location 헤더를 통해 반환되며, 서버 표현의 self와 bookmark 링크로 사용할 수 있습니다. 서버를 생성할 때 서버 ID, 링크, 관리 비밀번호만 반환되는 것이 보장됩니다. 추가 속성은 서버에 대한 후속 GET 작업을 수행하여 조회할 수 있습니다.

4 서버 쿼리

서버를 쿼리하는 데 두 가지 API가 있습니다: GET /servers와 GET /servers/detail. 이 두 API는 쿼리 옵션을 사용하여 쿼리 결과를 필터링하는 것을 지원합니다.

사용자 역할에 따라 사용할 수 있는 쿼리 옵션 세트가 다릅니다:

• 일반 사용자에게는 제한된 서버 속성 세트가 쿼리 옵션으로 사용할 수 있습니다. 지원되는 옵션은 다음과 같습니다:
  • changes-since
  • flavor
  • image
  • ip
  • ip6 (버전 2.5에서 새로 추가됨)
  • name
  • not-tags (버전 2.26에서 새로 추가됨)
  • not-tags-any (버전 2.26에서 새로 추가됨)
  • reservation_id
  • status
  • tags (버전 2.26에서 새로 추가됨)
  • tags-any (버전 2.26에서 새로 추가됨)
  • changes-before (버전 2.66에서 새로 추가됨)
  • locked (버전 2.73에서 새로 추가됨)
  • availability_zone (버전 2.83에서 새로 추가됨)
  • config_drive (버전 2.83에서 새로 추가됨)
  • key_name (버전 2.83에서 새로 추가됨)
  • created_at (버전 2.83에서 새로 추가됨)
  • launched_at (버전 2.83에서 새로 추가됨)
  • terminated_at (버전 2.83에서 새로 추가됨)
  • power_state (버전 2.83에서 새로 추가됨)
  • task_state (버전 2.83에서 새로 추가됨)
  • vm_state (버전 2.83에서 새로 추가됨)
  • progress (버전 2.83에서 새로 추가됨)
  • user_id (버전 2.83에서 새로 추가됨)

기타 옵션은 nova에 의해 조용히 무시됩니다.

• 관리자의 경우 대부분의 서버 속성을 쿼리 옵션으로 사용할 수 있습니다. Ocata 릴리스 이전에는 서버의 데이터베이스 스키마에 있는 필드가 쿼리 옵션으로 노출되어 예상치 못한 API 변경을 초래할 수 있었습니다. Ocata 릴리스 이후로는 쿼리 옵션의 정의와 데이터베이스 스키마가 분리되었습니다. 이는 서버 API 응답에서 속성 명명과 쿼리 옵션 명명이 다른 이유이기도 합니다.

사전조건: 다음과 같은 정보가 있는 클라우드에 2개의 서버가 존재합니다:

{
    "servers": [
        {
            "name": "t1",
            "OS-EXT-SRV-ATTR:host": "devstack1",
            ...
        },
        {
            "name": "t2",
            "OS-EXT-SRV-ATTR:host": "devstack2",
            ...
        }
    ]
}

예시: 관리자 전용 옵션이 있는 일반 사용자 쿼리(서버 조회)

비관리자 컨텍스트로 요청: GET /servers/detail?host=devstack1

Note

host 쿼리 매개변수는 관리자 사용자만 사용할 수 있으며, 비관리자 사용자가 지정한 경우 쿼리 매개변수가 무시됩니다. 따라서 이 예시에서는 devstack1과 devstack2의 서버가 모두 반환됩니다.

응답:

{
    "servers": [
        {
            "name": "t1",
            ...
        },
        {
            "name": "t2",
            ...
        }
    ]
}

예시: 관리자 전용 옵션이 있는 관리자 쿼리(서버 조회)

관리자 컨텍스트에서의 요청: GET /servers/detail?host=devstack1

응답:

{
    "servers": [
        {
            "name": "t1",
            ...
        }
    ]
}

특별한 쿼리 옵션도 있습니다:

• changes-since: 주어진 시간 이후에 업데이트된 서버를 반환합니다. 자세한 내용은: 효율적 폴링
• changes-before: 주어진 시간 이전에 업데이트된 서버를 반환합니다. 자세한 내용은: 효율적 폴링
• deleted: 삭제된 서버를 반환(또는 제외)합니다.
• soft_deleted: 'deleted'의 동작을 수정하여 vm_state가 SOFT_DELETED인 인스턴스를 포함하거나 제외합니다.
• all_tenants: 관리자가 모든 테넌트의 서버를 쿼리할 수 있게 하는 관리자 전용 옵션입니다.

예시: 특별 키 changes-since 또는 changes-before가 있는 사용자 쿼리(서버 조회)

요청: GET /servers/detail

응답:

{
    "servers": [
        {
            "name": "t1",
            "updated": "2015-12-15T15:55:52Z",
            ...
        },
        {
            "name": "t2",
            "updated": "2015-12-17T15:55:52Z",
            ...
        }
    ]
}

요청: GET /servers/detail?changes-since='2015-12-16T15:55:52Z'

응답:

{
    {
        "name": "t2",
        "updated": "2015-12-17T15:55:52Z",
        ...
    }
}

요청: GET /servers/detail?changes-before='2015-12-16T15:55:52Z'

응답:

{
    {
        "name": "t1",
        "updated": "2015-12-15T15:55:52Z",
        ...
    }
}

요청: GET /servers/detail?changes-since='2015-12-10T15:55:52Z'&changes-before='2015-12-28T15:55:52Z'

응답:

{
    "servers": [
        {
            "name": "t1",
            "updated": "2015-12-15T15:55:52Z",
            ...
        },
        {
            "name": "t2",
            "updated": "2015-12-17T15:55:52Z",
            ...
        }
    ]
}

쿼리 옵션에는 두 가지 종류의 매칭이 있습니다: 정확한 매칭과 정규식 매칭.

호스트로 정확한 매칭을 사용한 쿼리(서버 조회)

관리자 컨텍스트로 요청: GET /servers/detail

응답:

{
    "servers": [
        {
            "name": "t1",
            "OS-EXT-SRV-ATTR:host": "devstack"
            ...
        },
        {
            "name": "t2",
            "OS-EXT-SRV-ATTR:host": "devstack1"
            ...
        }
    ]
}

관리자 컨텍스트로 요청: GET /servers/detail?host=devstack

응답:

{
    "servers": [
        {
            "name": "t1",
            "OS-EXT-SRV-ATTR:host": "devstack"
            ...
        }
    ]
}

예시: 이름으로 정규식 매칭을 사용한 쿼리(서버 조회)

관리자 컨텍스트로 요청: GET /servers/detail

응답:

{
    "servers": [
        {
            "name": "test11",
            ...
        },
        {
            "name": "test21",
            ...
        },
        {
            "name": "t1",
            ...
        },
        {
            "name": "t14",
            ...
        }
    ]
}

관리자 컨텍스트로 요청: GET /servers/detail?name=t1

응답:

{
    "servers": [
        {
            "name": "test11",
            ...
        },
        {
            "name": "t1",
            ...
        },
        {
            "name": "t14",
            ...
        }
    ]
}

예시: 호스트로 정확한 매칭, 이름으로 정규식 매칭을 사용한 쿼리(서버 조회)

관리자 컨텍스트로 요청: GET /servers/detail

응답:

{
    "servers": [
        {
            "name": "test1",
            "OS-EXT-SRV-ATTR:host": "devstack"
            ...
        },
        {
            "name": "t2",
            "OS-EXT-SRV-ATTR:host": "devstack1"
            ...
        },
        {
            "name": "test3",
            "OS-EXT-SRV-ATTR:host": "devstack1"
            ...
        }
    ]
}

관리자 컨텍스트로 요청: GET /servers/detail?host=devstack1&name=test

응답:

{
    "servers": [
        {
            "name": "test3",
            "OS-EXT-SRV-ATTR:host": "devstack1"
            ...
        }
    ]
}

요청: GET /servers/detail?changes-since='2015-12-16T15:55:52Z'

응답:

{
    {
        "name": "t2",
        "updated": "2015-12-17T15:55:52Z"
        ...
    }
}