Cloudflare는 Linux에서 디스크 암호화 속도를 획기적으로 높이는 패치를 준비했습니다.

Cloudflare의 개발자 말한 Linux 커널에서 디스크 암호화 성능을 최적화하기 위한 작업 수행에 대해 설명합니다. 그 결과 준비한 것은 패치 하위 시스템용 DM-암호화 그리고 합성 테스트에서 읽기 및 쓰기 처리량을 두 배 이상 늘리고 대기 시간을 절반으로 줄이는 Crypto API를 사용했습니다. 실제 하드웨어에서 테스트했을 때 암호화 오버헤드는 데이터 암호화 없이 디스크로 작업할 때 관찰된 수준으로 거의 감소했습니다.

Cloudflare는 dm-crypt를 사용하여 CDN의 콘텐츠를 캐시하는 데 사용되는 저장 장치의 데이터를 암호화합니다. Dm-crypt는 블록 장치 수준에서 작동하고 쓰기 I/O 요청을 암호화하고 읽기 요청을 해독하여 블록 장치와 파일 시스템 드라이버 사이의 계층 역할을 합니다.

패키지를 사용하여 dm-crypt의 성능을 평가하려면 유연한 I/O 테스터 우리는 디스크 성능의 변동을 제거하고 코드 성능에 집중하기 위해 RAM에 위치한 RAM 디스크에서 암호화된 파티션과 암호화되지 않은 파티션으로 작업하는 속도를 측정했습니다. 암호화되지 않은 파티션의 경우 읽기 및 쓰기 성능은 1126MB/s로 유지되었지만 암호화가 활성화되면 속도가 감소했습니다. 시간에 7 147MB/s에 이르렀습니다.

처음에는 커널 암호 시스템에서 비효율적인 알고리즘을 사용한다는 의혹이 제기되었습니다. 그러나 테스트에서는 256개의 암호화 키가 있는 가장 빠른 알고리즘인 aes-xts를 사용했는데, 이 알고리즘의 "cryptsetup 벤치마크"를 실행할 때의 성능은 RAM 디스크를 테스트할 때 얻은 결과보다 두 배 이상 높았습니다. 성능 튜닝을 위한 dm-crypt 플래그를 사용한 실험에서는 결과가 나오지 않았습니다. "--perf-same_cpu_crypt" 플래그를 사용할 때 성능은 심지어 136MB/s로 감소했으며 "--perf-submit_from_crypt_cpus" 플래그를 지정할 때는 성능만 증가했습니다. 최대 166MB/s.

운영 로직에 대한 심층 분석을 통해 dm-crypt는 보이는 것만큼 간단하지 않다는 사실이 드러났습니다. FS 드라이버에서 쓰기 요청이 도착하면 dm-crypt는 이를 즉시 처리하지 않고 "kcryptd" 대기열에 배치합니다. 즉시 구문 분석되지는 않지만 편리한 순간에 구문 분석됩니다. 대기열에서 요청은 암호화를 수행하기 위해 Linux Crypto API로 전송됩니다. 하지만 Crypto API는 비동기 실행 모델을 사용하기 때문에 암호화도 즉시 수행되지 않고 다른 대기열을 우회합니다. 암호화가 완료된 후 dm-crypt는 검색 트리를 사용하여 보류 중인 쓰기 요청을 정렬하려고 시도할 수 있습니다. 레드 블랙. 마지막에는 다시 별도의 커널 스레드가 일정한 지연을 갖고 누적된 I/O 요청을 수집하여 블록 장치 스택으로 보냅니다.

읽을 때 dm-crypt는 먼저 "kcryptd_io" 대기열에 요청을 추가하여 드라이브에서 데이터를 수신합니다. 일정 시간이 지나면 데이터를 사용할 수 있게 되고 암호 해독을 위해 "kcryptd" 대기열에 배치됩니다.
Kcryptd는 정보를 비동기적으로 해독하는 Linux Crypto API에 요청을 보냅니다. 요청이 항상 모든 대기열을 통과하는 것은 아니지만 최악의 경우 쓰기 요청은 최대 4번, 읽기 요청은 최대 3번 대기열에 들어갑니다. 대기열에 도달할 때마다 지연이 발생하며, 이는 dm-crypt 성능이 크게 저하되는 주요 원인입니다.

대기열을 사용하는 이유는 중단이 발생하는 조건에서 작업해야 하기 때문입니다. 2005년에 dm-crypt의 현재 대기열 기반 운영 모델이 구현되었을 때 Crypto API는 아직 비동기식이 아니었습니다. Crypto API가 비동기 실행 모델로 전환된 후 본질적으로 이중 보호가 사용되기 시작했습니다. 커널 스택 소비를 줄이기 위해 대기열도 도입되었지만 2014년에 대기열이 증가한 후 이러한 최적화는 관련성을 잃었습니다. 대량의 요청이 도착할 때 메모리 할당을 기다리게 되는 병목 현상을 극복하기 위해 추가 큐 "kcryptd_io"가 도입되었습니다. 2015년에는 다중 프로세서 시스템의 암호화 요청이 순서 없이 완료될 수 있기 때문에 추가 정렬 단계가 도입되었습니다(디스크에 대한 순차적 액세스 대신 무작위 순서로 액세스가 수행되었으며 CFQ 스케줄러가 효율적으로 작동하지 않았습니다). 현재 SSD 드라이브를 사용할 때 정렬의 의미가 사라지고 CFQ 스케줄러는 더 이상 커널에서 사용되지 않습니다.

최신 드라이브가 더 빠르고 스마트해졌음을 고려하여 Linux 커널의 리소스 분배 시스템이 수정되고 일부 하위 시스템이 재설계되었습니다. Cloudflare 엔지니어 추가 dm-crypt에는 불필요한 대기열과 비동기 호출의 사용을 제거하는 새로운 작동 모드가 있습니다. 이 모드는 별도의 플래그 "force_inline"으로 활성화되며 dm-crypt를 들어오는 요청을 암호화하고 해독하는 간단한 프록시 형태로 만듭니다. Crypto API와의 상호 작용은 동기 모드에서 작동하고 요청 대기열을 사용하지 않는 암호화 알고리즘을 명시적으로 선택하여 최적화되었습니다. Crypto API와 동기식으로 작업하려면 제안 가속을 위해 FPU/AES-NI를 사용하고 암호화 및 암호 해독 요청을 직접 전달할 수 있는 모듈입니다.

결과적으로 RAM 디스크를 테스트할 때 dm-crypt의 성능을 두 배 이상 향상시킬 수 있었습니다. 성능은 294MB/s(2 x 147MB/s)에서 640MB/s로 증가했습니다. 베어 암호화 성능(696MB/s).

실제 서버에서 로드를 테스트할 때 새로운 구현은 암호화 없이 실행되는 구성과 매우 유사한 성능을 보여 주었으며 Cloudflare 캐시를 사용하여 서버에서 암호화를 활성화해도 응답 속도에는 영향을 미치지 않았습니다. 앞으로 Cloudflare는 준비된 패치를 기본 Linux 커널로 전송할 계획이지만, 그 전에 패치를 재작업해야 합니다. 왜냐하면 해당 패치는 특정 로드에 최적화되어 있고 낮은 암호화와 같은 애플리케이션의 모든 영역을 다루지는 않기 때문입니다. - 임베디드 장치에 전원을 공급합니다.

출처 : opennet.ru