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"
        ...
    }
}

5 서버 액션

• Reboot(재부팅)

이 기능을 사용하여 서버를 소프트 재부팅 또는 하드 재부팅할 수 있습니다. 소프트 재부팅은 운영체제에 다시 시작하라는 신호를 보내어 모든 프로세스를 우아하게 종료할 수 있도록 합니다. 하드 재부팅은 서버의 전원을 끄고 다시 켜는 것과 동일합니다. 가상화 플랫폼은 기본 도메인/VM이 일시 중지되거나 중지/중단된 경우에도 재부팅 작업이 성공적으로 완료되었는지 확인해야 합니다.

• Rebuild(재구축)

이 기능을 사용하여 서버의 모든 데이터를 제거하고 지정된 이미지로 교체합니다. 서버 ID, 플레이버, IP 주소는 동일하게 유지됩니다.

• Evacutate(대피)

nova-compute 서비스가 실제로 오프라인이 되면 더 이상 해당 서버의 상태를 보고할 수 없습니다. 이는 해당 서버들이 'ACTIVE' 상태로 영원히 나열된다는 것을 의미합니다.

대피는 관리자가 이러한 서버를 다른 노드에서 강제로 다시 구축할 수 있게 하는 해결 방법입니다. 호스트가 실제로 다운되었는지 여부는 보장하지 않으므로 울타리는 배포자가 처리해야 합니다.

• Resize(크기조정) - Confirm resize(크기조정 확인), Revert resize(크기조정 되돌리기) 포함

이 기능을 사용하여 기존 서버를 다른 플레이버로 변환하여 서버를 확장하거나 축소할 수 있습니다. 문제가 발생할 경우 롤백할 수 있도록 원본 서버가 일정 기간 저장됩니다. 모든 크기조정은 테스트 후 명시적으로 확인해야 하며, 이때 원본 서버가 제거됩니다. 관리자의 배포 설정에 따라 크기조정된 서버가 자동으로 확인될 수 있습니다.

크기조정 확인 작업은 virt 레이어에서 이전 서버를 삭제합니다. 이후 virt 레이어에서 생성된 서버를 사용합니다. 반대로 크기조정 되돌리기 작업은 virt 레이어에서 새로 생성된 서버를 삭제하고 모든 변경사항을 되돌립니다. 이후 원본 서버를 사용합니다.

• Pause(일시중지), Unpause(일시중지 해제)

일시중지 요청을 통해 서버를 일시 중지할 수 있습니다. 이 요청은 VM의 상태를 RAM에 저장합니다. 일시중지된 서버는 동결된 상태로 계속 실행됩니다.

일시중지 해제는 일시중지된 서버를 활성 상태로 되돌립니다.

• Suspend(서스펜드), Resume(재개)

서버가 자주 사용되지 않거나 시스템 유지관리를 수행하기 위해 서버를 서스펜드할 수 있습니다. 서버를 서스펜드하면 VM 상태가 디스크에 저장되고 모든 메모리가 디스크에 기록되며 가상 머신이 중지됩니다. 서버를 서스펜드하는 것은 장치를 최대 절전 모드로 전환하는 것과 유사하며, 점유된 리소스는 해제되지 않고 서버가 재개될 때까지 유지됩니다.

• Snapshot(스냅샷)

서버 루트 디스크의 현재 상태를 저장하여 나중에 이 저장된 이미지를 사용하여 서버를 다시 부팅할 수 있습니다.

• Backup(백업)

백업 방법을 사용하여 서버의 현재 상태를 glance 리포지토리에 저장할 수 있습니다. 동시에 '일일(daily)' 또는 '주간(weekly)' 유형에 따라 오래된 스냅샷이 제거됩니다.

• Start(시작)

서버를 켭니다.

• Stop(정지)

서버의 전원을 끕니다.

• Delete(삭제), Restore(복구)

지정된 서버의 전원을 먼저 끄고 네트워크 및 볼륨과 같은 서버와 연결된 모든 리소스를 분리한 다음 서버를 삭제합니다.

설정 옵션 'reclaim_instance_interval'(초 단위)에 따라 서버가 시스템에 남아 있을지 여부가 결정됩니다. 이 값이 0보다 크면 삭제된 서버는 즉시 삭제되지 않고 큐에 넣어져 일정 시간 경과 후 삭제됩니다. 관리자는 복구 작업을 사용하여 삭제 큐에서 서버를 복구할 수 있습니다. 삭제된 서버가 reclaim_instance_interval 값보다 오래 남아 있으면 컴퓨트 서비스에서 자동으로 삭제됩니다.

• Shelve(보관), Shelve offload(보관 오프로드), Unshelve(보관 해제)

서버를 보관하면 일정 기간 동안 필요하지 않음을 의미하며 하이퍼바이저에서 임시로 제거될 수 있습니다. 이를 통해 리소스를 다른 사용자가 사용할 수 있도록 해제할 수 있습니다.

기본적으로 설정 옵션 'shelved_offload_time'이 0이면 보관 작업 후 서버가 즉시 하이퍼바이저에서 제거됩니다. 그렇지 않으면 리소스는 'shelved_offload_time'(초 단위) 값 동안 유지되며, 이 기간 동안 보관 해제 작업이 더 빨라지며, 이후 주기적인 작업이 'shelved_offload_time'이 경과하면 서버를 하이퍼바이저에서 제거합니다. 'shelved_offload_time' 옵션을 -1로 설정하면 절대 오프로드되지 않습니다.

보관 작업은 지정된 서버의 전원을 끄고 이미지에서 부팅된 경우 스냅샷을 생성합니다. 그런 다음 컴퓨트 호스트에서 서버를 오프로드하고 리소스를 할당 해제할 수 있습니다. 볼륨에서 부팅된 경우 즉시 오프로드되지만 이미지에서 부팅된 경우 오프로드가 지연되거나 무기한으로 지연될 수 있으며, 이미지가 디스크에 남아 리소스가 여전히 할당된 상태로 유지될 수 있습니다.

보관 오프로드는 호스트에 남겨진 보관된 서버를 명시적으로 제거하는 데 사용됩니다. 이 작업은 보관된 서버에만 사용할 수 있으며 일반적으로 관리자가 수행합니다.

보관 해제는 보관 작업의 반대 작업입니다. 보관된 이미지를 사용하여 새로 예약된 호스트에서 서버를 다시 구축하고 부팅합니다.

• Lock(잠금), Unlock(잠금 해제)

서버를 잠금 상태로 설정하여 비관리자 사용자가 다음 작업을 수행하지 못하도록 할 수 있습니다.

• 서버 삭제
• 관리자 패스워드 변경 (changePassword 작업)
• 크기조정 확인 (confirmResize 작업)
• 서버 강제 삭제 (forceDelete 작업)
• 서버 일시중지 (pause 작업)
• 서버 재부팅 (reboot 작업)
• 서버 재구축 (rebuild 작업)
• 서버 복구 (rescue 작업)
• 서버 크기조정 (resize 작업)
• 소프트 삭제된 인스턴스 복원 (restore 작업)
• 서스펜드된 서버 재개 (resume 작업)
• 서버 크기조정 되돌리기 (revertResize 작업)
• 서버 보관 오프로드 (shelveOffload 작업)
• 서버 보관 (shelve 작업)
• 서버 시작 (os-start 작업)
• 서버 정지 (os-stop 작업)
• 서버 일시중지 (suspend 작업)
• 서버에서 충돌 덤프 트리거
• 서버 일시중지 해제 (unpause 작업)
• 서버 복구 해제 (unrescue 작업)
• 서버 보관 해제 (복원) (unshelve 작업)
• 볼륨을 인스턴스에 연결
• 볼륨 연결 업데이트
• 볼륨을 인스턴스에서 분리
• 인터페이스 생성
• 인터페이스 분리
• 메타데이터 항목 생성 또는 업데이트
• 메타데이터 항목들 생성 또는 업데이트
• 메타데이터 항목 삭제
• 메타데이터 항목 교체
• 고정 IP 추가 (addFixedIp 작업) (지원중단됨)
• 고정 IP 제거 (removeFixedIp 작업) (지원중단됨)

그러나 관리자는 서버가 잠겨 있어도 서버에서 작업을 수행할 수 있습니다. 기본적으로 소유자 또는 관리자만 서버를 잠글 수 있으며 관리자는 소유자의 잠금을 덮어쓰고 잠긴 이유를 지정할 수 있습니다.

잠금 해제는 잠금 상태의 서버를 잠금 해제하여 비관리자 사용자가 서버에서 추가 작업을 수행할 수 있도록 합니다. 기본적으로 소유자 또는 관리자만 서버의 잠금을 해제할 수 있습니다.

• Rescue(복구), Unrescue(복구 해제)

복구 작업은 서버를 특수 루트 디스크 이미지에서 부팅하여 특수 설정에서 시작합니다. 이를 통해 테넌트가 손상된 게스트 시스템을 복구하려고 시도할 수 있습니다.

복구 해제는 복구 작업의 반대 작업입니다. 특수 루트 이미지에서 생성된 서버는 삭제됩니다.

• Set administrator password(관리자 패스워드 설정)

지정된 서버의 root/administrator 패스워드를 설정합니다. 선택적으로 설치된 에이전트를 사용하여 administrator 패스워드를 설정합니다.

• Migrate(이동), Live migrate(라이브 마이그레이션)

이동은 일반적으로 관리자가 사용하며 서버를 다른 호스트로 이동합니다. 동일한 플레이버로 '크기조정' 작업을 사용하므로 이동 중 서버가 종료되고 다른 호스트에서 다시 구축됩니다.

라이브 마이그레이션은 서버를 한 호스트에서 다른 호스트로 이동하지만 일반적으로 서버의 전원을 끄지 않으므로 서버가 다운 타임을 겪지 않습니다. 관리자는 유지관리 작업을 수행해야 하는 호스트에서 서버를 대피시키기 위해 이를 사용할 수 있습니다.

• Trigger crash dump(크래시 덤프 트리거)

크래시 덤프 트리거는 주로 관리자나 서버 소유자가 사용하며, 메모리 이미지를 덤프 파일로 서버에 저장한 후 커널을 다시 재부팅합니다. 이 기능은 서버의 트리거 설정(예: NMI)에 따라 작동합니다.

6 서버 패스워드

서버를 생성할 때 선택적으로 adminPass 속성을 통해 패스워드를 지정할 수 있습니다. 지정된 패스워드는 OpenStack Compute 제공자가 설정한 복잡성 요구사항을 충족해야 합니다. 복잡성 요구사항을 충족하지 않으면 서버가 ERROR 상태에 들어갈 수 있습니다. 이 경우 클라이언트는 패스워드 변경 작업을 수행하여 서버 패스워드를 재설정할 수 있습니다.

패스워드를 지정하지 않으면 무작위로 생성된 패스워드가 할당되어 응답 객체에 반환됩니다. 이 패스워드는 컴퓨트 제공자가 설정한 보안 요구사항을 충족하도록 보장됩니다. 보안상의 이유로 이 패스워드는 이후 GET 호출에서 반환되지 않습니다.

7 서버 메타데이터

커스텀 서버 메타데이터는 서버 실행 시점에 공급될 수도 있습니다. 메타데이터 키와 값의 최대 크기는 각각 255바이트입니다. 서버당 제공할 수 있는 키-값 쌍의 최대 개수는 컴퓨팅 제공자에 의해 결정되며, maxServerMeta 절대 한도를 통해 조회할 수 있습니다.

8 블록 장치 매핑

간단히 말해, 블록 장치 매핑은 블록 장치가 서버에 어떻게 노출되는지를 설명합니다.

역사적인 이유로 인해, nova는 서버 생성 요청 본문에서 블록 장치 매핑을 언급하는 두 가지 방법을 가지고 있습니다:

• block_device_mapping: 이는 레거시 방식이며 EC2 API에 대한 하위 호환성을 지원합니다.
• block_device_mapping_v2: 서버 생성 요청 본문에서 블록 장치 매핑 정보를 지정하는 권장 형식입니다.

사용자는 동일한 요청에서 두 가지 형식을 혼합하여 사용할 수 없습니다.

추가 정보는 블록 장치 매핑을 참조하십시오.

서버를 생성할 때 사용가능한 block_device_mapping_v2 매개변수의 전체 목록은 API 참조를 참조하십시오.

block_device_mapping_v2의 예시

다음 예시는 UUID가 bb02b1a3-bc77-4d17-ab5b-421d89850fca인 이미지에서 100GB 크기의 볼륨 유형 블록 장치를 생성합니다. 이는 첫 번째 부팅 장치로 사용되며(boot_index=0), 이 블록 디바이스는 서버 종료 후에도 삭제되지 않습니다. 이 경우 볼륨 기반 서버를 생성하기 때문에 imageRef 매개변수는 필요하지 않습니다.

{
    "server": {
        "name": "volume-backed-server-test",
        "flavorRef": "52415800-8b69-11e0-9b19-734f1195ff37",
        "block_device_mapping_v2": [
            {
                "boot_index": 0,
                "uuid": "bb02b1a3-bc77-4d17-ab5b-421d89850fca",
                "volume_size": "100",
                "source_type": "image",
                "destination_type": "volume",
                "delete_on_termination": false
            }
        ]
    }
}

9 스케줄러 힌트

스케줄러 힌트는 사용자가 스케줄러가 서버를 배치할 호스트를 결정하는 데 영향을 줄 수 있는 방법입니다. 이들은 서버 생성 요청의 메인 server 딕셔너리와는 별도로 딕셔너리로 지정된 미리 정해진 키-값 쌍입니다. 사용가능한 스케줄러 힌트는 클라우드의 설정에 따라 다르므로 클라우드마다 다릅니다.

{
    "server": {
        "name": "server-in-group",
        "imageRef": "52415800-8b69-11e0-9b19-734f6f006e54",
        "flavorRef": "52415800-8b69-11e0-9b19-734f1195ff37"
    },
    "os:scheduler_hints": {
        "group": "05a81485-010f-4df1-bbec-7821c85686e8"
    }
}

스케줄러 힌트 지정 방법에 대한 자세한 내용은 Compute API 참조의 create-server-detail 요청 섹션을 참조하십시오.

스케줄러 힌트가 플레이버 부가 사양과 어떻게 다른지에 대한 자세한 내용은 이 문서를 참조하십시오.

10 서버 콘솔

서버가 시작된 후에도 서버 콘솔을 제공할 수 있습니다. 여러 가지 서버 콘솔 서비스가 있습니다. 첫째로, 사용자는 지정된 서버의 콘솔 출력을 확인할 수 있으며, 길이를 설정하여 콘솔 텍스트의 줄 수를 제한할 수 있습니다. 둘째로, 사용자는 여러 종류의 원격 콘솔에 접근할 수 있습니다. 사용자는 OpenStack 대시보드 또는 명령줄을 통해 novnc, <ocde>rdp-html5, spice-html5, serial, 그리고 webmks(마이크로버전 2.8부터 지원)을 사용할 수 있습니다. 원격 콘솔 접근 설정에 대해 참고하세요.