빠른 팁: 출력 파일 압축

압축
클라우드 HPC의 주요 과제 중 하나는 온프레미스 시스템과 클라우드 내 시스템 간에 전송해야 하는 데이터 양을 최소화하는 것입니다. 기존 온프레미스 시스템과 달리 이 전송은 훨씬 느리고 안정성이 낮은 광역 네트워크를 통해 발생합니다. 우리가 접촉한 것처럼 이전에, 가장 좋은 방법은 원격으로 사후 처리를 수행하고 불필요하게 데이터를 전송하지 않는 것입니다.
즉, 많은 사용자의 일반적인 시나리오는 시뮬레이션을 실행한 다음 작업의 모든 출력 파일을 다시 워크스테이션으로 전송하는 것입니다.
작업이 완료된 후 작업 디렉터리의 각 파일은 암호화되어 클라우드 저장소에 업로드됩니다. 이는 출력 파일의 작은 하위 집합만 컴퓨터에 다운로드해야 하는 사용자에게 유연성을 제공합니다. 그러나 단점은 각 파일이 전송 시 추가 오버헤드를 발생시킨다는 것입니다. 네트워크를 통해 데이터를 전송할 때 단일 파일에 담을 수 있는 데이터가 많을수록 좋습니다. 또한 많은 엔지니어링 코드는 압축률이 높은 파일을 생성합니다. 파일을 압축하는 데 추가 시간이 걸리더라도 압축에 더해 작은 파일을 전송하는 데 소요되는 시간이 더 큰 압축되지 않은 아카이브를 업로드하는 데 소요되는 시간보다 적다면 이는 여전히 순익이 될 수 있습니다. 압축 및 그에 따른 전송이 전반적으로 더 오래 걸리더라도 전체 전송 프로세스의 실제 병목 현상은 클라우드 스토리지와 사용자 워크스테이션 간의 마지막 홉이 될 것입니다. 여기에서 전송할 압축 파일의 크기가 작으면 사용자의 인터넷 연결 속도에 따라 엄청난 차이가 발생할 수 있습니다.
작업에 대한 모든 출력 파일을 다운로드해야 한다는 것을 미리 알고 있는 경우 일반적으로 각 파일을 개별적으로 전송하는 대신 먼저 단일 압축 아카이브 파일을 생성하는 것이 가장 좋습니다. linux tar 명령은 압축된 아카이브를 생성하는 쉬운 방법을 제공하지만 MPI 클러스터에서 사용 가능한 추가 컴퓨팅 성능을 활용하여 아카이브를 생성하지는 않습니다.
Jeff Gilchrist는 MPI 클러스터에서 실행되는 사용하기 쉬운 bz2 압축기를 개발했습니다(https://compression.ca/mpibzip2/). 우리는 정적 bzip2 라이브러리 참조로 Linux 바이너리를 컴파일하여 사용 가능하게 만들었습니다. 여기에서 지금 확인해 보세요. 자신의 작업에 더 쉽게 통합할 수 있도록 다운로드하세요. 바이너리는 OpenMPI 1.6.4 mpic++ 래퍼 컴파일러로 빌드되었습니다. 사용 중인 MPI 버전에 따라 다시 컴파일해야 할 수도 있습니다.
이를 사용하려면 mpibzip2 실행 파일을 작업의 추가 입력 파일로 업로드하세요. 그런 다음 작업 설정 페이지의 분석 명령 끝에 다음 명령을 추가해야 합니다.
tar cf files.tar –exclude=mpibzip2 *
mpirun -np 16 mpibzip2 -v 파일.tar
찾다 ! -name 'files.tar.bz2' -type f -exec rm -f {} +
먼저, 병렬 bzip 유틸리티를 제외한 모든 것을 포함하는 files.tar라는 tar 파일이 생성됩니다. 그런 다음 mpibzip2 실행 파일을 실행하고 files.tar.bz2라는 압축 아카이브를 생성합니다. 마지막으로 files.tar.bz2를 제외한 모든 파일이 삭제됩니다. 이렇게 하면 개별 파일과 압축된 아카이브가 모두 클라우드 스토리지에 업로드되는 것을 방지할 수 있습니다.
mpirun 호출의 -np 인수는 클러스터의 코어 수를 반영해야 합니다. 여기서 명령은 16개의 니켈 코어 클러스터에서 실행됩니다.
추가적으로 알아야 할 점은 Windows는 기본적으로 bz2 또는 tar 파일을 지원하지 않는다는 것입니다. 7 - 우편 번호 다른 많은 형식과 함께 이 형식에 대한 지원을 추가하기 위해 설치할 수 있습니다.
빠른 테스트로 우리는 2.1개 파일에 분산된 369GB 상당의 출력 데이터가 포함된 OpenFOAM 작업에서 압축된 아카이브를 구축하고 결과 파일을 클라우드 스토리지에 업로드했습니다.
영상
기준으로 우리는 압축되지 않은 tar 파일을 구축했습니다. 또한 tar 명령과 함께 -z 플래그를 사용하여 gzip 압축 tar 파일 생성을 시도했습니다. 마지막으로 우리는 2, 8, 16개의 니켈 코어로 bz32 압축 아카이브를 구축해 보았습니다.
당연하게도 기본 사례에서 아카이브를 구축하는 데는 무시할 만한 시간이 소요되며 전체 시간의 대부분은 더 큰 파일을 업로드하는 데 소요됩니다. 파일을 압축할 때 전체 시간 분석이 반전됩니다. 대신 대부분의 시간이 파일을 압축하는 데 소요됩니다. 또한 당연히 다중 코어를 활용하면 tar 명령과 함께 제공되는 단일 코어 gzip 지원을 사용하는 것보다 속도가 크게 향상됩니다. 약 16개 코어에서 전체 시간은 기준 사례와 거의 동일합니다.
그러나 압축된 bz2 파일은 압축되지 않은 tar(5MB 대 439GB)보다 거의 2.1배 작기 때문에 사용자가 자신의 로컬 워크스테이션에 출력을 다운로드하려고 시도할 때 압축 단계의 실제 이점이 분명해집니다.
다시 한번 말씀드리지만, 우리는 후처리 및 시각화 작업을 클라우드에 최대한 많이 적용하는 것이 데이터 전송을 최소화하는 가장 좋은 방법이라고 믿습니다. 그러나 많은 수의 출력 파일이 필요한 경우 미리 압축된 아카이브를 준비하는 데 약간의 시간을 투자하면 전송 시간을 크게 줄일 수 있는 경우가 많습니다. 우리는 이 게시물에 설명된 많은 수동 단계를 자동화하고 앞으로 더욱 원활한 프로세스를 만들 계획입니다. 계속 지켜봐 주시기 바랍니다!

비슷한 게시물