내구성 있는 데이터 저장소 및 Linux 파일 API

클라우드 시스템에서 데이터 스토리지의 지속 가능성을 연구하면서 기본적인 사항을 이해했는지 확인하기 위해 직접 테스트해 보기로 결정했습니다. 나 NVMe 사양을 읽고 시작했습니다. 지속 가능한 데이터 스토리지에 관한 보장(즉, 시스템 장애 후 데이터 사용 가능 보장)이 무엇인지 이해하기 위해 NMVe 디스크를 제공합니다. 저는 다음과 같은 주요 결론을 내렸습니다. 데이터 쓰기 명령이 내려진 순간부터 저장 매체에 기록되는 순간까지 데이터는 손상된 것으로 간주되어야 합니다. 그러나 대부분의 프로그램은 시스템 호출을 사용하여 데이터를 기록합니다.

이 게시물에서는 Linux 파일 API가 제공하는 영구 저장 메커니즘을 살펴봅니다. 여기서는 모든 것이 간단해야 하는 것 같습니다. 프로그램이 명령을 호출합니다. write(), 이 명령이 완료되면 데이터가 디스크에 안전하게 저장됩니다. 하지만 write() 응용 프로그램 데이터를 RAM에 있는 커널 캐시에만 복사합니다. 시스템이 데이터를 디스크에 쓰도록 하려면 몇 가지 추가 메커니즘을 사용해야 합니다.

일반적으로 이 자료는 내가 관심 있는 주제에 대해 배운 내용과 관련된 일련의 메모입니다. 가장 중요한 것에 대해 아주 간략하게 이야기하면 지속 가능한 데이터 스토리지를 구성하려면 다음 명령을 사용해야 합니다. fdatasync() 또는 플래그가 있는 파일 열기 O_DSYNC. 코드에서 디스크로 이동하는 동안 데이터에 어떤 일이 발생하는지 자세히 알아보려면 다음을 살펴보세요. 이 조.

write() 함수 사용의 특징

시스템 호출 write() 표준에 정의되어 있음 IEEE POSIX 파일 설명자에 데이터를 쓰려는 시도로. 성공적인 작업 완료 후 write() 데이터 읽기 작업은 다른 프로세스나 스레드에서 데이터에 액세스하는 경우에도 이전에 기록된 바이트를 정확히 반환해야 합니다(여기에 POSIX 표준의 관련 섹션). 여기에, 스레드가 일반 파일 작업과 상호 작용하는 방법에 대한 섹션에는 두 스레드가 각각 이러한 함수를 호출하는 경우 각 호출은 다른 호출의 지정된 결과를 모두 확인하거나 전혀 확인하지 않아야 한다는 메모가 있습니다. 결과. 이는 모든 파일 I/O 작업이 작업 중인 리소스에 대해 잠금을 유지해야 한다는 결론으로 ​​이어집니다.

이것이 수술을 의미합니까? write() 원자입니까? 기술적인 관점에서 보면 그렇습니다. 데이터 읽기 작업은 작성된 내용을 모두 반환하거나 전혀 반환하지 않아야 합니다. write(). 하지만 수술은 write(), 표준에 따라 그녀가 기록하도록 요청받은 모든 것을 기록하여 끝날 필요가 없습니다. 데이터의 일부만 쓸 수 있습니다. 예를 들어 동일한 파일 설명자가 설명하는 파일에 각각 1024바이트를 추가하는 두 개의 스트림이 있을 수 있습니다. 표준의 관점에서 각 쓰기 작업이 파일에 XNUMX바이트만 추가할 수 있는 경우 결과가 허용됩니다. 이러한 작업은 원자성으로 유지되지만 완료되면 파일에 쓰는 데이터가 뒤죽박죽이 됩니다. 여기에 스택 오버플로에 대한 이 주제에 대한 매우 흥미로운 토론.

fsync() 및 fdatasync() 함수

데이터를 디스크로 플러시하는 가장 쉬운 방법은 함수를 호출하는 것입니다. fsync(). 이 기능은 운영 체제에 수정된 모든 블록을 캐시에서 디스크로 이동하도록 요청합니다. 여기에는 파일의 모든 메타데이터(액세스 시간, 파일 수정 시간 등)가 포함됩니다. 이 메타데이터는 거의 필요하지 않다고 생각하므로 중요하지 않은 경우 함수를 사용할 수 있습니다. fdatasync(). 에 돕다 에 fdatasync() 이 기능이 작동하는 동안 "다음 데이터 읽기 작업을 올바르게 실행하는 데 필요한" 만큼의 메타데이터가 디스크에 저장된다고 합니다. 그리고 이것이 바로 대부분의 애플리케이션이 관심을 갖는 부분입니다.

여기서 발생할 수 있는 한 가지 문제는 이러한 메커니즘이 가능한 오류 후에 파일을 검색할 수 있다는 것을 보장하지 않는다는 것입니다. 특히, 새 파일을 생성할 때 다음을 호출해야 합니다. fsync() 그것을 포함하는 디렉토리에 대해. 그렇지 않으면 실패 후 이 파일이 존재하지 않는 것으로 판명될 수 있습니다. 그 이유는 UNIX에서는 하드 링크 사용으로 인해 파일이 여러 디렉토리에 존재할 수 있기 때문입니다. 그러므로 전화할 때 fsync() 어떤 디렉토리 데이터도 디스크로 플러시해야 하는지 파일이 알 수 있는 방법이 없습니다(여기에 이에 대한 자세한 내용을 읽을 수 있습니다). ext4 파일 시스템이 가능한 것 같습니다. 자동으로 적용하다 fsync() 해당 파일이 포함된 디렉터리로 이동하지만 다른 파일 시스템에서는 그렇지 않을 수도 있습니다.

이 메커니즘은 다양한 파일 시스템에서 다르게 구현될 수 있습니다. 나는 사용했다 블록 추적 ext4 및 XFS 파일 시스템에서 사용되는 디스크 작업에 대해 알아봅니다. 둘 다 파일 내용과 파일 시스템 저널 모두에 대해 디스크에 일반 쓰기 명령을 실행하고, 캐시를 플러시하고, 저널에 FUA(Force Unit Access, 디스크에 직접 데이터 쓰기, 캐시 우회) 쓰기를 수행하여 종료합니다. 그들은 아마도 거래가 이루어졌는지 확인하기 위해 이렇게 할 것입니다. FUA를 지원하지 않는 드라이브에서는 캐시 플러시가 두 번 발생합니다. 내 실험에 따르면 fdatasync() 조금 더 빠르게 fsync(). 공익사업 blktrace 것을 나타냅니다 fdatasync() 일반적으로 디스크에 더 적은 양의 데이터를 씁니다(ext4의 경우). fsync() 20KiB를 쓰고 fdatasync() - 16KiB). 또한 XFS가 ext4보다 약간 빠르다는 것도 알게 되었습니다. 그리고 여기 도움으로 blktrace 그걸 알아낼 수 있었어 fdatasync() 더 적은 양의 데이터를 디스크에 플러시합니다(XFS의 경우 4KiB).

fsync() 사용 시 모호한 상황

세 가지 모호한 상황을 생각할 수 있습니다. fsync()내가 실제로 만난 것입니다.

첫 번째 사건은 2008년에 발생했습니다. 그 당시 많은 수의 파일이 디스크에 기록되는 경우 Firefox 3 인터페이스가 "정지"되었습니다. 문제는 인터페이스의 구현이 상태에 대한 정보를 저장하기 위해 SQLite 데이터베이스를 사용했다는 것입니다. 인터페이스에서 발생한 각 변경 후 함수가 호출되었습니다. fsync()이는 안정적인 데이터 저장을 보장합니다. ext3 파일 시스템에서 사용된 함수는 다음과 같습니다. fsync() 해당 파일과 관련된 페이지뿐만 아니라 시스템의 모든 "더티" 페이지를 디스크에 플러시했습니다. 즉, Firefox에서 버튼을 클릭하면 메가바이트의 데이터가 자기 디스크에 기록될 수 있으며 이는 몇 초가 걸릴 수 있습니다. 내가 이해하는 한 문제에 대한 해결책 그것 자료는 데이터베이스 작업을 비동기 백그라운드 작업으로 옮기는 것이었습니다. 즉, Firefox는 실제로 필요한 것보다 더 엄격한 스토리지 지속성 요구 사항을 구현하는 데 사용되었으며 ext3 파일 시스템 기능은 이 문제를 악화시킬 뿐입니다.

두 번째 문제는 2009년에 발생했다. 그런 다음 시스템 충돌 후 새로운 ext4 파일 시스템 사용자는 새로 생성된 많은 파일의 길이가 3이라는 사실에 직면했지만 이전 ext3 파일 시스템에서는 이런 일이 발생하지 않았습니다. 이전 단락에서는 extXNUMX가 너무 많은 데이터를 디스크에 플러시하여 속도가 크게 느려지는 방법에 대해 설명했습니다. fsync(). 상황을 개선하기 위해 ext4에서는 특정 파일과 관련된 더티 페이지만 디스크에 플러시됩니다. 그리고 다른 파일의 데이터는 ext3보다 훨씬 오랫동안 메모리에 남아 있습니다. 이는 성능을 향상시키기 위해 수행되었습니다. 기본적으로 데이터는 30초 동안 이 상태로 유지되며 다음을 사용하여 구성할 수 있습니다. dirty_expire_centisecs; 여기에 이에 대한 추가 자료를 찾을 수 있습니다.) 이는 오류 발생 후 복구할 수 없을 정도로 많은 양의 데이터가 손실될 수 있음을 의미합니다. 이 문제에 대한 해결책은 다음을 사용하는 것입니다. fsync() 안정적인 데이터 스토리지를 제공하고 오류의 결과로부터 최대한 보호해야 하는 애플리케이션에서. 기능 fsync() ext4을 사용할 때보다 ext3를 사용할 때 훨씬 효율적으로 작동합니다. 이 접근 방식의 단점은 이전과 마찬가지로 이를 사용하면 프로그램 설치와 같은 일부 작업의 실행 속도가 느려진다는 것입니다. 이에 대한 세부정보 보기 여기에 и 여기에.

에 관한 세 번째 문제 fsync(), 2018년에 시작되었습니다. 그런 다음 PostgreSQL 프로젝트의 프레임워크 내에서 다음과 같은 기능이 발견되었습니다. fsync() 오류가 발생하면 "더티" 페이지를 "깨끗함"으로 표시합니다. 결과적으로 다음과 같은 호출이 발생합니다. fsync() 그러한 페이지에는 아무 것도 하지 마십시오. 이 때문에 수정된 페이지는 메모리에 저장되고 디스크에 기록되지 않습니다. 응용 프로그램은 일부 데이터가 디스크에 기록된다고 생각하지만 실제로는 그렇지 않기 때문에 이것은 실제 재앙입니다. 이러한 실패 fsync() 이러한 상황에서는 응용 프로그램을 적용해도 문제를 해결하는 데 거의 아무 것도 할 수 없습니다. 요즘 이런 일이 발생하면 PostgreSQL과 기타 애플리케이션이 충돌합니다. 여기에, "응용 프로그램이 fsync 오류로부터 복구할 수 있습니까?"에서 이 문제를 자세히 살펴봅니다. 현재 이 문제에 대한 최상의 솔루션은 플래그와 함께 Direct I/O를 사용하는 것입니다. O_SYNC 아니면 깃발로 O_DSYNC. 이 접근 방식을 사용하면 시스템은 특정 쓰기 작업 중에 발생할 수 있는 오류를 보고하지만 이 접근 방식을 사용하려면 애플리케이션이 버퍼 자체를 관리해야 합니다. 이에 대해 자세히 알아보기 여기에 и 여기에.

O_SYNC 및 O_DSYNC 플래그를 사용하여 파일 열기

영구 데이터 저장소를 제공하는 Linux 메커니즘에 대한 논의로 돌아가 보겠습니다. 즉, 우리는 깃발의 사용에 대해 이야기하고 있습니다 O_SYNC 또는 플래그 O_DSYNC 시스템 콜을 사용하여 파일을 열 때 열다(). 이 접근 방식을 사용하면 각 데이터 쓰기 작업이 마치 각 명령 이후처럼 수행됩니다. write() 시스템에 각각 명령이 부여됩니다. fsync() и fdatasync(). 에 POSIX 사양 이를 "동기화된 I/O 파일 무결성 완료" 및 "데이터 무결성 완료"라고 합니다. 이 접근 방식의 가장 큰 장점은 데이터 무결성을 보장하기 위해 두 개가 아닌 한 개의 시스템 호출만 하면 된다는 것입니다(예: write() и fdatasync()). 이 접근 방식의 가장 큰 단점은 해당 파일 설명자를 사용하는 모든 쓰기가 동기화되어 애플리케이션 코드를 구조화하는 기능이 제한될 수 있다는 것입니다.

O_DIRECT 플래그와 함께 직접 I/O 사용

시스템 호출 open() 깃발을 지지하다 O_DIRECT는 운영 체제 캐시를 우회하여 디스크와 직접 상호 작용하여 I/O 작업을 수행하도록 설계되었습니다. 이는 대부분의 경우 프로그램에서 실행된 쓰기 명령이 디스크 작업을 위한 명령으로 직접 변환된다는 것을 의미합니다. 그러나 일반적으로 이 메커니즘은 기능을 대체하지 않습니다. fsync() 또는 fdatasync(). 사실은 디스크 자체가 연기 또는 캐시 데이터를 쓰기 위한 적절한 명령. 그리고 더 나쁜 것은 어떤 특별한 경우에 플래그를 사용할 때 수행되는 I/O 작업이 O_DIRECT, 방송 기존의 버퍼 작업으로. 이 문제를 해결하는 가장 쉬운 방법은 플래그를 사용하여 파일을 여는 것입니다. O_DSYNC, 이는 각 쓰기 작업 뒤에 호출이 뒤따른다는 것을 의미합니다. fdatasync().

XFS 파일 시스템이 최근에 "빠른 경로"를 추가한 것으로 나타났습니다. O_DIRECT|O_DSYNC-데이터 기록. 다음을 사용하여 블록을 덮어쓰는 경우 O_DIRECT|O_DSYNC, 그러면 XFS는 캐시를 플러시하는 대신 장치가 지원하는 경우 FUA 쓰기 명령을 실행합니다. 유틸리티를 사용하여 이를 확인했습니다. blktrace Linux 5.4/Ubuntu 20.04 시스템에서. 이 접근 방식은 사용 시 최소한의 데이터가 디스크에 기록되고 두 가지 작업(캐시 쓰기 및 플러시)이 아닌 한 가지 작업이 사용되므로 더 효율적입니다. 에 대한 링크를 찾았습니다. 패치 2018 커널은 이 메커니즘을 구현합니다. 이 최적화를 다른 파일 시스템에 적용하는 것에 대한 논의가 있지만, 제가 아는 한 XFS는 지금까지 이를 지원하는 유일한 파일 시스템입니다.

sync_file_range() 함수

리눅스에는 시스템 콜이 있다 sync_file_range(), 전체 파일이 아닌 파일의 일부만 디스크에 플러시할 수 있습니다. 이 호출은 비동기 데이터 플러시를 시작하고 완료될 때까지 기다리지 않습니다. 하지만 인증서에는 sync_file_range() 이 명령은 "매우 위험하다"고 합니다. 사용하지 않는 것이 좋습니다. 기능 및 위험 sync_file_range() 에 아주 잘 설명되어 있습니다. 이 재료. 특히 이 호출은 RocksDB를 사용하여 커널이 "더티" 데이터를 디스크에 플러시하는 시기를 제어하는 ​​것으로 보입니다. 그러나 동시에 안정적인 데이터 저장을 보장하기 위해 사용됩니다. fdatasync(). 에 암호 RocksDB에는 이 주제에 대한 몇 가지 흥미로운 의견이 있습니다. 예를 들어 다음과 같이 호출됩니다. sync_file_range() ZFS를 사용하는 경우 데이터를 디스크로 플러시하지 않습니다. 경험에 따르면 거의 사용되지 않는 코드에는 버그가 포함될 가능성이 높습니다. 그러므로 꼭 필요한 경우가 아니면 이 시스템 호출을 사용하지 않는 것이 좋습니다.

데이터 지속성을 보장하는 시스템 호출

지속적인 I/O 작업을 수행하는 데 사용할 수 있는 세 가지 접근 방식이 있다는 결론에 도달했습니다. 모두 함수 호출이 필요합니다. fsync() 파일이 생성된 디렉터리에 대해 접근 방식은 다음과 같습니다.

1. 함수 호출 fdatasync() 또는 fsync() 기능 후 write() (사용하는 것이 더 좋습니다. fdatasync()).
2. 플래그로 열린 파일 설명자 작업하기 O_DSYNC 또는 O_SYNC (더 나은-플래그와 함께 O_DSYNC).
3. 명령 사용 pwritev2() 깃발이 달린 RWF_DSYNC 또는 RWF_SYNC (바람직하게는 깃발 RWF_DSYNC).

성능 노트

나는 내가 조사한 다양한 메커니즘의 성능을 주의 깊게 측정하지 않았습니다. 작업 속도에서 내가 느낀 차이점은 매우 작습니다. 이는 내가 틀렸을 수도 있고, 다른 조건에서는 동일한 결과가 다른 결과를 낳을 수도 있음을 의미합니다. 먼저 성능에 더 많은 영향을 미치는 것이 무엇인지, 성능에 덜 영향을 미치는 것이 무엇인지 이야기하겠습니다.

1. 파일 데이터를 덮어쓰는 것이 파일에 데이터를 추가하는 것보다 빠릅니다(성능 향상은 2-100%일 수 있음). 파일에 데이터를 첨부하려면 시스템 호출 후에도 파일의 메타데이터를 추가로 변경해야 합니다. fallocate()그러나 이 효과의 크기는 다양할 수 있습니다. 최상의 성능을 위해 전화하는 것이 좋습니다. fallocate() 필요한 공간을 미리 할당합니다. 그런 다음 이 공간은 명시적으로 XNUMX으로 채워지고 호출되어야 합니다. fsync(). 이렇게 하면 파일 시스템의 해당 블록이 "할당되지 않음"이 아니라 "할당됨"으로 표시됩니다. 이렇게 하면 성능이 약간(약 2%) 향상됩니다. 또한 일부 디스크는 다른 디스크보다 첫 번째 블록 액세스 작업이 느릴 수 있습니다. 즉, 공간을 100으로 채우면 성능이 크게(약 XNUMX%) 향상될 수 있습니다. 특히 이것은 디스크에서 발생할 수 있습니다. AWS EBS (비공식 데이터라 확인할 수 없었습니다.) 보관도 마찬가지 GCP 영구 디스크 (그리고 이것은 이미 테스트를 통해 확인된 공식 정보입니다). 다른 전문가들도 그렇게 했고 관측, 다양한 디스크와 관련됩니다.
2. 시스템 호출이 적을수록 성능이 향상됩니다(이득은 약 5%일 수 있음). 도전인 것 같네요 open() 깃발이 달린 O_DSYNC 또는 전화 pwritev2() 깃발이 달린 RWF_SYNC 더 빠른 통화 fdatasync(). 여기서 요점은 동일한 문제를 해결하기 위해 더 적은 수의 시스템 호출(두 개가 아닌 한 개 호출)이 수행되어야 한다는 사실에서 이 접근 방식이 중요한 역할을 한다는 것입니다. 그러나 성능 차이는 매우 작으므로 이를 완전히 무시하고 논리를 복잡하게 만들지 않는 애플리케이션에서 무언가를 사용할 수 있습니다.

지속 가능한 데이터 스토리지 주제에 관심이 있다면 다음과 같은 유용한 자료를 참조하세요.

• I/O 액세스 방법 — 입력/출력 메커니즘의 기본 개요.
• 데이터가 디스크에 도달하도록 보장 — 애플리케이션에서 디스크로 이동하는 동안 데이터에 어떤 일이 발생하는지에 대한 이야기입니다.
• 포함된 디렉터리를 언제 fsync해야 합니까? - 지원 시기 질문에 대한 답변 fsync() 디렉토리용. 간단히 말해서 새 파일을 생성할 때 이 작업을 수행해야 함을 알 수 있으며, 이렇게 권장하는 이유는 Linux에서는 동일한 파일에 대한 참조가 많이 있을 수 있기 때문입니다.
• Linux의 SQL Server: FUA 내부 - 다음은 Linux 플랫폼의 SQL Server에서 영구 데이터 저장소가 구현되는 방법에 대한 설명입니다. 여기에서 Windows와 Linux 시스템 호출 간의 몇 가지 흥미로운 비교가 있습니다. XFS의 FUA 최적화에 대해 알게 된 것은 이 자료 덕분이라고 거의 확신합니다.

디스크에 안전하게 저장되어 있다고 생각했던 데이터를 잃어버린 적이 있습니까?

출처 : habr.com