Docker 스토리지 드라이버에는 다음이 포함됩니다. 1. 파일 수준 스토리지 드라이버인 AUFS 2. Union FS인 오버레이 3. 매핑 프레임워크 메커니즘인 Btrfs 파일 수준 스토리지 드라이버 5. 새로운 파일 시스템인 ZFS.
이 문서의 운영 환경: Windows 7 시스템, Docker 버전 20.10.11, Dell G3 컴퓨터.
Docker 스토리지 드라이버란 무엇입니까? Docker의 5가지 스토리지 드라이버 원칙과 해당 응용 시나리오
1. 원리 설명
Docker는 처음에 AUFS를 파일 시스템으로 사용했으며 AUFS 계층화 개념도 활용했습니다. 여러 컨테이너가 동일한 이미지를 공유할 수 있습니다. 그러나 AUFS는 Linux 커널에 통합되지 않고 Ubuntu만 지원하므로 호환성 문제를 고려하여 Docker 버전 0.7에서 현재 Docker는 5가지 유형의 AUFS, Btrfs, Device mapper, OverlayFS 및 ZFS를 지원합니다. 스토리지 드라이버. Docker 공식 웹사이트에 명시된 바와 같이 모든 애플리케이션 시나리오에 적합한 단일 드라이버는 없습니다. 다양한 시나리오에 따라 적절한 스토리지 드라이버를 선택해야만 Docker의 성능을 효과적으로 향상시킬 수 있습니다. 적합한 스토리지 드라이버를 선택하는 방법 더 나은 판단을 내리려면 먼저 스토리지 드라이버 원칙을 이해해야 합니다. 이 기사에서는 Docker의 5가지 스토리지 드라이버 원칙에 대한 자세한 설명과 애플리케이션 시나리오 및 IO 성능 테스트를 소개합니다. 원리에 대해 이야기하기 전에 쓰기 시 복사와 쓰기 시 할당이라는 두 가지 기술에 대해 이야기해 보겠습니다.
1. CoW(기록 중 복사)
모든 드라이버에서 사용되는 기술 - CoW(기록 중 복사). CoW는 쓰기 중 복사(copy-on-write)입니다. 이는 쓰기가 필요할 때만 복사하는 것을 의미합니다. 이는 기존 파일을 수정하는 시나리오를 위한 것입니다. 예를 들어 하나의 이미지를 기반으로 여러 개의 컨테이너가 시작되는 경우 각 컨테이너에 이미지와 유사한 파일 시스템이 할당되면 많은 디스크 공간을 차지하게 됩니다. CoW 기술을 사용하면 모든 컨테이너가 이미지의 파일 시스템을 공유할 수 있으며, 파일을 쓸 때만 쓸 파일을 이미지에서 자체 파일 시스템으로 복사하여 수정합니다. . 따라서 동일한 이미지를 공유하는 컨테이너 수에 관계없이 이미지에서 자체 파일 시스템으로 복사된 복사본에 대해 쓰기 작업이 수행되며, 이미지의 소스 파일은 수정되지 않으며 여러 컨테이너 작업이 동시에 수행됩니다. 파일은 각 컨테이너의 파일 시스템에 복사본을 생성합니다. 각 컨테이너는 서로 격리되어 서로 영향을 주지 않는 자체 복사본을 수정합니다. CoW를 사용하면 디스크 활용도를 효과적으로 향상시킬 수 있습니다.
2. 주문형 할당
주문형 할당은 파일이 원래 존재하지 않는 시나리오에서 사용됩니다. 공간은 새 파일을 쓸 때만 할당되므로 스토리지 리소스 활용도를 높일 수 있습니다. . 예를 들어 컨테이너가 시작되면 일부 디스크 공간이 컨테이너에 미리 할당되지 않고 대신 새 파일이 작성될 때 요청에 따라 새 공간이 할당됩니다.
2. 스토리지 드라이버의 5가지 기본 원칙
1. AUFS
AUFS(AnotherUnionFS)는 파일 수준 스토리지 드라이버인 Union FS입니다. AUFS는 하나 이상의 기존 파일 시스템에 계층화된 파일 시스템을 투명하게 오버레이하여 여러 계층을 파일 시스템의 단일 계층 표현으로 병합할 수 있습니다. 간단히 말하면 동일한 가상 파일 시스템의 파일 시스템에 서로 다른 디렉터리를 마운트하는 것을 지원합니다. 이 파일 시스템은 파일을 계층별로 수정할 수 있습니다. 아래 레이어 수에 관계없이 읽기 전용이며 최상위 파일 시스템에만 쓰기가 가능합니다. 파일을 수정해야 할 때 AUFS는 파일의 복사본을 생성하고 CoW를 사용하여 수정을 위해 읽기 전용 레이어에서 쓰기 가능한 레이어로 파일을 복사하고 결과도 쓰기 가능한 레이어에 저장합니다. Docker에서 아래의 읽기 전용 레이어는 이미지이고, 쓰기 가능한 레이어는 컨테이너입니다. 구조는 아래 그림과 같습니다.
2, Overlay
Overlay는 3.18 이후 Linux 커널에서 지원되며 AUFS의 다중 레이어와도 다릅니다. 오버레이에는 두 개의 레이어만 있습니다. 상위 파일 시스템과 하위 파일 시스템은 각각 Docker의 이미지 레이어와 컨테이너 레이어를 나타냅니다. 파일을 수정해야 할 경우 CoW를 사용하여 읽기 전용 하위 계층에서 쓰기 가능한 상위 계층으로 파일을 복사하여 수정하고, 그 결과도 상위 계층에 저장됩니다. Docker에서 아래의 읽기 전용 레이어는 이미지이고, 쓰기 가능한 레이어는 컨테이너입니다. 구조는 아래 그림과 같습니다:
3, Device mapper
장치 매퍼는 Linux 커널 2.6.9 이상에서 지원됩니다. 이는 논리적 장치에서 물리적 장치로의 매핑 프레임워크 메커니즘을 제공합니다. 이 메커니즘에서 사용자는 자신의 필요에 따라 스토리지 리소스에 대한 관리 전략을 쉽게 공식화할 수 있습니다. 앞서 언급한 AUFS와 OverlayFS는 파일 수준의 저장소인 반면, 디바이스 매퍼는 블록 수준의 저장소입니다. 모든 작업은 파일이 아닌 블록에서 직접 수행됩니다. 장치 매퍼 드라이버는 먼저 블록 장치에 리소스 풀을 생성한 다음 리소스 풀에 파일 시스템이 있는 기본 장치를 생성합니다. 모든 이미지는 이 기본 장치의 스냅샷이고 컨테이너는 이미지의 스냅샷입니다. 따라서 컨테이너에 보이는 파일 시스템은 리소스 풀에 있는 기본 장치의 파일 시스템에 대한 스냅샷이며, 컨테이너에 할당된 공간은 없습니다. 새 파일이 기록되면 컨테이너의 이미지에 새 블록이 할당되고 데이터가 기록됩니다. 이를 시간 할당이라고 합니다. 기존 파일을 수정하려면 CoW를 이용해 컨테이너 스냅샷을 위한 블록 공간을 할당하고, 수정하려는 데이터를 컨테이너 스냅샷의 새 블록에 복사한 후 수정하면 된다. 장치 매퍼 드라이버는 기본적으로 이미지와 컨테이너를 포함하는 100G 파일을 생성합니다. 각 컨테이너는 10G 볼륨으로 제한되며 직접 구성하고 조정할 수 있습니다. 구조는 아래 그림과 같습니다.
4, Btrfs
Btrfs는 차세대 Copy-On-Write 파일 시스템이라고 하며 Linux 커널에 통합되어 있으며 파일이기도 합니다. -레벨 스토리지 드라이버이지만 장치 매퍼처럼 사용할 수 있습니다. 항상 기본 장비를 직접 조작하세요. Btrfs는 파일 시스템의 일부를 하위 볼륨이라는 완전한 하위 파일 시스템으로 구성합니다. 하위 볼륨을 사용하면 대규모 파일 시스템을 여러 하위 파일 시스템으로 나눌 수 있습니다. 이러한 하위 파일 시스템은 기본 장치 공간을 공유하고 디스크 공간이 필요할 때 응용 프로그램이 malloc()을 호출하여 기본 장치에서 할당됩니다. 메모리를 할당합니다. 장치 공간을 유연하게 활용하기 위해 Btrfs는 디스크 공간을 여러 청크로 나눕니다. 각 청크는 서로 다른 디스크 공간 할당 전략을 사용할 수 있습니다. 예를 들어 일부 청크는 메타데이터만 저장하고 일부 청크는 데이터만 저장합니다. 이 모델에는 장치의 동적 추가를 지원하는 Btrfs와 같은 많은 장점이 있습니다. 사용자는 시스템에 새 디스크를 추가한 후 Btrfs 명령을 사용하여 파일 시스템에 장치를 추가할 수 있습니다. Btrfs는 대규모 파일 시스템을 리소스 풀로 처리하고 이를 여러 개의 완전한 하위 파일 시스템으로 구성합니다. 기본 이미지는 각 하위 파일 시스템의 스냅샷입니다. -이미지 및 컨테이너 각각에는 자체 스냅샷이 있으며 이러한 스냅샷은 모두 하위 볼륨의 스냅샷입니다.
새 파일이 작성되면 컨테이너의 스냅샷에 새 데이터 블록이 할당되고 이 공간에 파일이 작성되는 것을 시간 할당이라고 합니다. 기존 파일을 수정하려는 경우 CoW 복사를 사용하여 새로운 원본 데이터와 스냅샷을 할당하고 새로 할당된 공간의 데이터를 변경한 다음 관련 데이터 구조를 업데이트하여 새로운 하위 파일 시스템과 스냅샷을 가리키도록 합니다. 원본 원본 데이터 그리고 스냅샷에는 이를 가리키는 포인터가 없어 덮어쓰여집니다.
5, ZFS
ZFS 파일 시스템은 ZFS가 "볼륨 관리"를 완전히 포기하고 더 이상 가상 볼륨을 생성하지 않고 모든 장치를 중앙 집중화하는 혁신적인 새로운 파일 시스템입니다. 관리를 위한 스토리지 풀로, "스토리지 풀" 개념을 사용하여 물리적 스토리지 공간을 관리합니다. 과거에는 파일 시스템이 물리적 장치에 구축되었습니다. 이러한 물리적 장치를 관리하고 데이터에 대한 중복성을 제공하기 위해 "볼륨 관리" 개념은 단일 장치 이미지를 제공합니다. ZFS는 "zpools"라는 가상 저장소 풀을 기반으로 구축되었습니다. 각 스토리지 풀은 여러 가상 장치(vdev)로 구성됩니다. 이러한 가상 장치는 원시 디스크, RAID1 미러 장치 또는 비표준 RAID 수준의 다중 디스크 그룹일 수 있습니다. 그러면 zpool의 파일 시스템은 이러한 가상 장치의 총 스토리지 용량을 사용할 수 있습니다.
Docker에서 ZFS를 사용하는 방법을 살펴보겠습니다. 먼저 zpool에서 이미지의 기본 계층에 ZFS 파일 시스템을 할당하고 다른 이미지 계층은 이 ZFS 파일 시스템 스냅샷의 복제본이며 복제본은 컨테이너가 시작되면 쓰기 가능합니다. 미러에서 최상위 레이어는 쓰기 가능한 레이어를 생성합니다. 아래 그림과 같이:
새 파일을 쓰고 싶을 때 주문형 할당을 사용하면 zpool에서 새 데이터 블록이 생성되고 새 데이터가 이 블록에 기록되며 이 새 공간이 컨테이너(ZFS 클론)에 저장됩니다. ). 기존 파일을 수정하려면 Copy-On-Write를 사용하여 새 공간을 할당하고 원본 데이터를 새 공간에 복사하여 수정을 완료하세요.
3. 스토리지 드라이버 비교 및 시나리오에 대한 적응
1, AUFS VS Overlay
AUFS와 Overlay는 모두 공동 파일 시스템이지만 AUFS에는 여러 레이어가 있지만 Overlay는 두 레이어이므로 쓰기 중 복사 작업을 수행할 때 파일이 더 크고 하위 레이어가 있는 경우 AUSF가 느려질 수 있습니다. 게다가 Overlay는 Linux 커널 메인라인에 통합되어 있지만 AUFS는 그렇지 않기 때문에 AUFS보다 빠를 수도 있습니다. 그러나 오버레이는 아직 너무 어리기 때문에 프로덕션에서는 주의해서 사용해야 합니다. Docker의 첫 번째 스토리지 드라이버인 AUFS는 오랜 역사를 갖고 있고 상대적으로 안정적이며 많은 프로덕션에서 실행되었으며 강력한 커뮤니티 지원을 받고 있습니다. 현재 오픈 소스 DC/OS에서는 오버레이 사용을 지정합니다.
2, Overlay VS Device mapper
Overlay는 파일 수준의 저장소이고, Device mapper는 블록 수준의 저장소입니다. 파일이 특히 크고 수정된 내용이 작을 경우 오버레이는 전체를 복사합니다. 수정된 내용의 크기와 상관없이 파일을 수정하는 경우 작은 파일보다 큰 파일을 수정하는 데 시간이 더 걸리며, 블록 수준에서는 큰 파일이든 작은 파일이든 수정이 필요한 블록만 수정됩니다. 전체 파일이 아닌 복사됩니다. 이 시나리오에서는 장치 매퍼가 더 빠르다는 것이 분명합니다. 블록 수준은 논리 디스크에 직접 액세스하기 때문에 IO 집약적인 시나리오에 적합합니다. 내부 프로그램이 복잡하고 동시성이 크지만 IO가 적은 시나리오의 경우 오버레이의 성능이 상대적으로 더 강력합니다.
3 여러 복사본이 필요하므로 이 스토리지 드라이버는 고밀도 컨테이너 PaaS 플랫폼에서 사용하기에 적합하지 않습니다. 또한 많은 컨테이너가 시작되고 중지되면 디스크 오버플로가 발생하여 호스트가 작동하지 않을 수 있습니다. 장치 매퍼는 프로덕션 용도로 권장되지 않으며 Btrfs는 도커 빌드에서 매우 효율적일 수 있습니다. ZFS는 원래 대용량 메모리를 탑재한 Salaris 서버용으로 설계되었기 때문에 사용 시 메모리에 영향을 미치게 되며, 대용량 메모리를 사용하는 환경에 적합합니다. ZFS의 COW는 순차 쓰기로 생성된 대용량 파일의 경우 나중에 일부가 무작위로 변경되면 하드 디스크에 있는 파일의 물리적 주소가 더 이상 연속적이지 않으며 향후 순차 읽기 성능이 저하됩니다. 더 가난해질 것이다. ZFS는 PaaS 및 고밀도 사용자 시나리오에 적합한 캐시 블록을 공유하는 여러 컨테이너를 지원합니다. 추천 학습: "docker tutorial"
위 내용은 도커 스토리지 드라이버란 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!