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부터 지원)을 사용할 수 있습니다. 원격 콘솔 접근 설정에 대해 참고하세요.

11 서버 네트워크

서버가 연결되는 네트워크는 실행 시에도 공급될 수 있습니다. 하나 이상의 네트워크를 지정할 수 있습니다. 사용자는 네트워크에서 특정 포트 또는 서버 인터페이스에 할당할 고정 IP 주소를 지정할 수도 있습니다.

12 서버 접근 주소

하이브리드 환경에서 서버의 IP 주소는 기본 구현에 의해 제어되지 않을 수 있습니다. 대신 접근 IP 주소는 전용 하드웨어(예: 라우터/NAT 장치)의 일부일 수 있습니다. 이 경우 구현체에서 제공하는 주소는 실제로 서버에 접근하는 데 사용될 수 없습니다(로컬 LAN 외부에서). 이 경우 서버에 접근하기 위해 생성 시 별도의 접근 주소가 할당될 수 있습니다. 이 주소는 서버의 네트워크 인터페이스에 직접 연결되지 않을 수 있으며, 서버의 주소를 조회할 때 반드시 나타나지 않을 수 있습니다. 그럼에도 불구하고 서버에 직접 접근해야 하는 클라이언트는 접근 주소를 통해서 서버에 접근하는 것이 권장됩니다. 아래 예제에서는 생성 시 IPv4 주소가 할당되는 경우를 보여줍니다.

예제: 접근 IP를 사용하여 서버 생성: JSON 요청

{
    "server": {
        "name": "new-server-test",
        "imageRef": "52415800-8b69-11e0-9b19-734f6f006e54",
        "flavorRef": "52415800-8b69-11e0-9b19-734f1195ff37",
        "accessIPv4": "67.23.10.132"
    }
}

Note

IPv4와 IPv6 주소 모두 접근 주소로 사용할 수 있으며, 아래와 같이 두 주소를 동시에 할당할 수도 있습니다. 서버가 생성된 후에도 접근 주소를 업데이트할 수 있습니다.

예제: 여러 접근 IP를 사용하여 서버 생성: JSON 요청

{
    "server": {
        "name": "new-server-test",
        "imageRef": "52415800-8b69-11e0-9b19-734f6f006e54",
        "flavorRef": "52415800-8b69-11e0-9b19-734f1195ff37",
        "accessIPv4": "67.23.10.132",
        "accessIPv6": "::babe:67.23.10.132"
    }
}

13 서버 이동

서버가 한 컴퓨팅 호스트에서 다른 호스트로 이동하게 되는 여러 가지 작업에는 쉘브, 크기조정, 마이그레이션, 대피 등이 포함됩니다. 다음의 사용 사례들은 이러한 작업의 의도와 운영 절차에 미치는 영향을 보여줍니다.

13.1 클라우드 운영자로서 서버 이동이 필요한 경우

클라우드 운영자는 운영 목적으로 작업 부하를 재분배해야 할 때가 있습니다. 예를 들어, 운영자는 유지보수를 위해 컴퓨팅 호스트를 제거하거나 커널 보안 패치를 배포해야 하는 경우 호스트를 재부팅해야 할 수도 있습니다.

운영자는 작업 부하를 의도적으로 이동시키기 위해 두 가지 행동을 취할 수 있습니다: 콜드 마이그레이션(활성화되지 않은 서버를 이동)과 라이브 마이그레이션(활성화된 서버를 이동).

콜드 마이그레이션은 서버가 활성 상태가 아닐 때 한 호스트에서 다른 호스트로 이동시키는 것입니다. 서버의 상태, 로컬 스토리지와 네트워크 설정을 새 호스트에 할당된 새 자원으로 복사합니다. 이 작업은 서버가 복사 과정에서 상태를 변경하지 않기 때문에 비교적 빠릅니다. 사용자는 이 작업 중 서버에 접근할 수 없습니다.

라이브 마이그레이션은 서버가 활성 상태일 때 한 호스트에서 다른 호스트로 이동시키는 것입니다. 따라서 작업 중 서버의 상태가 계속 변경됩니다. 이로 인해 콜드 마이그레이션보다 시간이 훨씬 더 오래 걸릴 수 있습니다. 작업 중 서버는 온라인 상태이며 접근할 수 있지만, 사용자는 제한된 관리 작업만 가능합니다.

클라우드에서 마이그레이션을 사용하는 일반적인 패턴은 다음과 같습니다:

• 호스트 유지보수

컴퓨팅 호스트를 클라우드에서 제거하려면 모든 서버를 다른 호스트로 이동시켜야 합니다. 이 경우 클라우드의 나머지 부분이 작업 부하를 흡수하여 서버를 재스케줄링하여 재분배하는 것이 일반적입니다.

호스트를 준비하려면 추가 서버를 받지 않도록 호스트를 비활성화합니다. 그런 다음 서버의 상태에 따라 콜드 또는 라이브 마이그레이션을 통해 각 서버를 새 호스트로 이동시킵니다. 완료되면 호스트를 제거할 준비가 됩니다.

• 롤링 업데이트

모든 컴퓨팅 호스트에 업데이트를 수행해야 하는 경우, 호스트를 재부팅해야 합니다. 이 경우 비활성 서버를 이동시키는 것은 필수적이지 않습니다. 재부팅 후에도 사용 가능하기 때문입니다. 그러나 활성 서버는 재부팅에 영향을 받습니다. 라이브 마이그레이션을 통해 계속 운영할 수 있습니다.

이 경우 업데이트 및 재부팅된 빈 컴퓨팅 호스트로 시작하여 롤링 방식을 사용할 수 있습니다. 아직 업데이트되지 않은 다른 호스트를 비활성화하고 해당 호스트의 모든 서버를 새 호스트로 이동시킵니다. 마이그레이션이 완료되면 새 호스트는 정상 운영을 계속합니다. 이전 호스트는 비어 있게 되며 업데이트 및 재부팅될 수 있습니다. 그런 다음 또 다른 마이그레이션 라운드의 새로운 대상으로 사용됩니다.

이 과정을 반복하여 전체 클라우드를 업데이트할 수 있으며, 일반적으로 하나의 빈 호스트 대신 여러 빈 호스트를 사용합니다.

• 자원 최적화

일부 클라우드 운영자는 에너지 사용량을 줄이기 위해 서버를 최소한의 호스트에 맞추려고 서버를 이동시킵니다. 이렇게 하면 일부 서버를 끌 수 있습니다.

때로는 더 높은 성능이 필요할 수 있으며, 이 경우 리소스 경합을 최소화하기 위해 서버를 호스트 간에 분산시킵니다.

서버를 이동시키는 것은 일반적으로 클라우드 사용자가 선택할 수 있는 옵션이 아닙니다. 사용자는 컴퓨팅 호스트에 대해 알지 못하기 때문입니다. 클라우드의 관리 및 서버가 프로비저닝되는 방식은 클라우드 운영자의 책임입니다.