"Nova에서 블록 장치 매핑"의 두 판 사이의 차이

 
(같은 사용자의 중간 판 8개는 보이지 않습니다)
6번째 줄: 6번째 줄:
https://docs.openstack.org/nova/latest/user/block-device-mapping.html
https://docs.openstack.org/nova/latest/user/block-device-mapping.html
----
----
Nova는 클라우드 인스턴스에 노출될 수 있는 블록 장치 개념을 가지고 있습니다. 인스턴스가 가질 수 있는 블록 장치의 유형은 여러 가지가 있으며, 어떤 유형이 사용가능한지는 특정 배포와 테넌트 및 사용자에게 설정된 사용 제한에 따라 다릅니다. 블록 장치 매핑은 인스턴스가 가지고 있는 모든 블록 장치에 대한 데이터를 조직하고 보관하는 방법입니다.
블록 장치 매핑에 대해 이야기할 때, 보통 두 가지 중 하나를 의미합니다:
* 1. 인스턴스 부팅 요청을 위한 블록 장치를 지정하는 API/CLI 구조와 구문
* 2. 블록 장치 매핑 테이블에 최종적으로 저장되는, 기록 및 보관을 위해 Nova 내부에서 사용하는 데이터 구조. Nova 내부에는 같은 데이터를 나타내기 위해 여러 '약간' 다른 형식들이 있습니다. 이 형식들은 모두 코드에 문서화되어 있거나, 별도의 클래스 집합으로 제공됩니다. 이들이 존재한다는 것을 모르면 코드를 읽을 때 혼란을 겪을 수 있습니다. 따라서 데이터베이스 스키마를 반영하는 BlockDeviceMapping 객체 외에도, 다음과 같은 형식이 있습니다:
** 2.1 API 형식 - 이는 API 클라이언트에서 받은 원시 키-값 쌍 세트로, 거의 즉시 객체로 변환됩니다. 그러나 일부 검증은 이 형식을 사용하여 수행됩니다. 우리는 이 형식을 'API BDMs'라고 부를 것입니다.
** 2.2 virt 드라이버 형식 - 이는 <code>nova.virt.block_device</code>에 정의된 클래스들에 의해 정의된 형식입니다. 이 형식은 다양한 virt 드라이버 코드에서 사용되고 기대됩니다. 이 클래스들은 다른 형식을 노출하는 것 외에도(파이썬 dict 인터페이스를 모방), 특정 유형의 블록 장치에 공통된 기능을 번들로 제공하는 장소를 제공합니다(예: Cinder와 virt 드라이버 코드 모두와 상호작용해야 하는 볼륨 연결). 우리는 이 형식을 'Driver BDMs'라고 부를 것입니다.
::자세한 내용은 [[드라이버 BDM 데이터 구조]] 참고 문서를 참조하십시오.
{{NOTE}}
참고로, 단일 서버에 연결할 수 있는 디스크 장치의 최대 수는 <code>[[nova 설정 옵션#max_disk_devices_to_attach|compute.max_disk_devices_to_attach]]</code> 옵션으로 설정할 수 있습니다.
{{/NOTE}}
==API BDM 데이터 형식과 그 역사==
Nova의 초기 시절, 블록 장치 매핑의 일반 구조는 EC2 API의 구조를 밀접하게 따랐습니다. Nova의 Havana 릴리스 동안, 블록 장치 처리 코드와 블록 장치 매핑 구조에 대한 작업이 이루어져 일반성과 유용성이 개선되었습니다. 이러한 개선사항에는 API에서 추가 세부정보와 기능을 노출하는 것이 포함되었습니다. 이를 촉진하기 위해 <code>BlockDeviceMappingV2Boot</code><ref>이 작업은 API 마이크로버전보다 이전에 이루어졌기 때문에 API 확장을 통해서만 추가할 수 있었습니다.</ref>라는 새로운 확장이 v2 API에 추가되어 인스턴스 부트 API 요청에 추가 <code>block_device_mapping_v2</code> 필드가 추가되었습니다.
===블록 장치 매핑 v1 (레거시)===
이것은 처음으로 도입된 형식으로, Cinder 볼륨만을 지원했습니다 (EC2 블록 장치로 EBS 볼륨만을 지원하는 것과 유사합니다). 모든 항목은 디바이스 이름으로 키가 지정되었으며 (이것이 문제가 되었던 이유는 나중에 이 페이지에서 논의할 예정입니다), 다음만을 허용했습니다:
* Cinder 볼륨 또는 스냅샷의 UUID
* 타입 필드 - 볼륨과 Cinder 볼륨 스냅샷을 구분하는 데만 사용
* 선택적 크기 필드
* 선택적 <code>delete_on_termination</code> 플래그
모든 Nova 내부 코드는 새로운 데이터 구조만을 사용하고 저장하지만, 여전히 레거시 형식을 사용하는 API 요청을 처리해야 합니다. 이는 각 요청마다 Nova API 서비스에서 처리됩니다. 나중에 보겠지만, 블록 장치 매핑 정보는 Glance의 이미지 메타데이터에도 저장될 수 있으므로, 이곳에서도 v1 형식을 처리해야 합니다. 레거시 변환을 처리하는 코드는 <code>nova.block_device</code> 모듈의 일부입니다.


==API BDM 데이터 형식과 이력==
===블록 장치 매핑 v1(레거시라고도 함)===
===Intermezzo - 장치 이름 문제===
===Intermezzo - 장치 이름 문제===
===블록 장치 매핑 v2===
===블록 장치 매핑 v2===
===유효한 소스/대상 조합===
===유효한 소스/대상 조합===
==FAQ==
==FAQ==
==참고==

2024년 7월 6일 (토) 11:28 기준 최신판

1 개요[ | ]

Crystal Clear action info.png 작성 중인 문서입니다.
Block Device Mapping in Nova
Nova에서 블록 장치 매핑

https://docs.openstack.org/nova/latest/user/block-device-mapping.html


Nova는 클라우드 인스턴스에 노출될 수 있는 블록 장치 개념을 가지고 있습니다. 인스턴스가 가질 수 있는 블록 장치의 유형은 여러 가지가 있으며, 어떤 유형이 사용가능한지는 특정 배포와 테넌트 및 사용자에게 설정된 사용 제한에 따라 다릅니다. 블록 장치 매핑은 인스턴스가 가지고 있는 모든 블록 장치에 대한 데이터를 조직하고 보관하는 방법입니다.

블록 장치 매핑에 대해 이야기할 때, 보통 두 가지 중 하나를 의미합니다:

  • 1. 인스턴스 부팅 요청을 위한 블록 장치를 지정하는 API/CLI 구조와 구문
  • 2. 블록 장치 매핑 테이블에 최종적으로 저장되는, 기록 및 보관을 위해 Nova 내부에서 사용하는 데이터 구조. Nova 내부에는 같은 데이터를 나타내기 위해 여러 '약간' 다른 형식들이 있습니다. 이 형식들은 모두 코드에 문서화되어 있거나, 별도의 클래스 집합으로 제공됩니다. 이들이 존재한다는 것을 모르면 코드를 읽을 때 혼란을 겪을 수 있습니다. 따라서 데이터베이스 스키마를 반영하는 BlockDeviceMapping 객체 외에도, 다음과 같은 형식이 있습니다:
    • 2.1 API 형식 - 이는 API 클라이언트에서 받은 원시 키-값 쌍 세트로, 거의 즉시 객체로 변환됩니다. 그러나 일부 검증은 이 형식을 사용하여 수행됩니다. 우리는 이 형식을 'API BDMs'라고 부를 것입니다.
    • 2.2 virt 드라이버 형식 - 이는 nova.virt.block_device에 정의된 클래스들에 의해 정의된 형식입니다. 이 형식은 다양한 virt 드라이버 코드에서 사용되고 기대됩니다. 이 클래스들은 다른 형식을 노출하는 것 외에도(파이썬 dict 인터페이스를 모방), 특정 유형의 블록 장치에 공통된 기능을 번들로 제공하는 장소를 제공합니다(예: Cinder와 virt 드라이버 코드 모두와 상호작용해야 하는 볼륨 연결). 우리는 이 형식을 'Driver BDMs'라고 부를 것입니다.
자세한 내용은 드라이버 BDM 데이터 구조 참고 문서를 참조하십시오.

Note

참고로, 단일 서버에 연결할 수 있는 디스크 장치의 최대 수는 compute.max_disk_devices_to_attach 옵션으로 설정할 수 있습니다.

2 API BDM 데이터 형식과 그 역사[ | ]

Nova의 초기 시절, 블록 장치 매핑의 일반 구조는 EC2 API의 구조를 밀접하게 따랐습니다. Nova의 Havana 릴리스 동안, 블록 장치 처리 코드와 블록 장치 매핑 구조에 대한 작업이 이루어져 일반성과 유용성이 개선되었습니다. 이러한 개선사항에는 API에서 추가 세부정보와 기능을 노출하는 것이 포함되었습니다. 이를 촉진하기 위해 BlockDeviceMappingV2Boot[1]라는 새로운 확장이 v2 API에 추가되어 인스턴스 부트 API 요청에 추가 block_device_mapping_v2 필드가 추가되었습니다.

2.1 블록 장치 매핑 v1 (레거시)[ | ]

이것은 처음으로 도입된 형식으로, Cinder 볼륨만을 지원했습니다 (EC2 블록 장치로 EBS 볼륨만을 지원하는 것과 유사합니다). 모든 항목은 디바이스 이름으로 키가 지정되었으며 (이것이 문제가 되었던 이유는 나중에 이 페이지에서 논의할 예정입니다), 다음만을 허용했습니다:

  • Cinder 볼륨 또는 스냅샷의 UUID
  • 타입 필드 - 볼륨과 Cinder 볼륨 스냅샷을 구분하는 데만 사용
  • 선택적 크기 필드
  • 선택적 delete_on_termination 플래그

모든 Nova 내부 코드는 새로운 데이터 구조만을 사용하고 저장하지만, 여전히 레거시 형식을 사용하는 API 요청을 처리해야 합니다. 이는 각 요청마다 Nova API 서비스에서 처리됩니다. 나중에 보겠지만, 블록 장치 매핑 정보는 Glance의 이미지 메타데이터에도 저장될 수 있으므로, 이곳에서도 v1 형식을 처리해야 합니다. 레거시 변환을 처리하는 코드는 nova.block_device 모듈의 일부입니다.

2.2 Intermezzo - 장치 이름 문제[ | ]

2.3 블록 장치 매핑 v2[ | ]

2.4 유효한 소스/대상 조합[ | ]

3 FAQ[ | ]

4 참고[ | ]

  1. 이 작업은 API 마이크로버전보다 이전에 이루어졌기 때문에 API 확장을 통해서만 추가할 수 있었습니다.
문서 댓글 ({{ doc_comments.length }})
{{ comment.name }} {{ comment.created | snstime }}