추상적인
Abstract - RPC(원격 프로시저 호출)는 분산 서비스에서 주로 사용되는 기술입니다. 현재 HPC(고성능 컴퓨팅)의 맥락에서 점점 더 많이 사용되는 이 기술을 통해 루틴 실행을 원격 노드에 위임할 수 있으며 이를 따로 설정하고 특정 작업에 전용할 수 있습니다. 그러나 기존 RPC 프레임워크는 HPC 시스템에 적합하지 않은 소켓 기반 네트워크 인터페이스(일반적으로 TCP/IP 위에 있음)를 가정합니다. 이 API는 일반적으로 해당 시스템에서 사용되는 기본 네트워크 전송에 잘 매핑되지 않기 때문에 네트워크가 낮아집니다. 성능. 또한 기존 RPC 프레임워크는 읽기 또는 쓰기 호출에서 발견되는 것과 같은 큰 데이터 인수 처리를 지원하지 않는 경우가 많습니다.
이 백서에서는 매개 변수 및 실행 요청의 비동기 전송과 큰 데이터 인수의 직접 지원을 허용하는 HPC 시스템에서 사용하도록 특별히 설계된 비동기 RPC 인터페이스를 제시합니다. 인터페이스는 모든 함수 호출을 전달할 수 있도록 일반적입니다. 또한 네트워크 구현이 추상화되어 미래 시스템으로 쉽게 포팅하고 기존 기본 전송 메커니즘을 효율적으로 사용할 수 있습니다.
RPC(원격 프로시저 호출)는 분산 서비스에 널리 사용되는 기술입니다. 현재 고성능 컴퓨팅(HPC)의 맥락에서 점점 더 많이 사용되는 이 기술을 사용하면 루틴 실행을 원격 노드에 위임할 수 있으며, 원격 노드는 별도로 설정하여 특정 작업에 전용할 수 있습니다. 그러나 기존 RPC 프레임워크는 소켓 기반 네트워크 인터페이스(일반적으로 TCP/IP 위에 있음)를 사용하는데, 이 API는 일반적으로 이러한 시스템에서 사용되는 기본 네트워크 전송에 잘 매핑되지 않기 때문에 HPC 시스템에 적합하지 않습니다. 네트워크 성능. 또한 기존 RPC 프레임워크는 읽기 또는 쓰기 호출에서 발견되는 것과 같은 대용량 데이터 매개변수 처리를 지원하지 않는 경우가 많습니다. 본 논문에서는 매개변수 및 실행 요청의 비동기 전송을 허용하고 대용량 데이터 매개변수를 직접 지원하는 HPC 시스템용으로 특별히 설계된 비동기 RPC 인터페이스를 제안합니다. 인터페이스는 일반적이므로 모든 함수 호출을 전달할 수 있습니다. 또한 네트워크 구현이 추상화되어 미래 시스템으로 쉽게 포팅하고 기존 기본 전송 메커니즘을 효율적으로 사용할 수 있습니다.
RPC(원격 프로시저 호출, 원격 프로시저 호출)는 분산 시스템에서 원격 통신을 위한 프로토콜 및 프로그래밍 모델입니다. 로컬 호출과 마찬가지로 하나의 컴퓨팅 노드(일반적으로 클라이언트)가 네트워크를 통해 다른 컴퓨팅 노드(일반적으로 서버)의 함수 또는 메서드를 호출할 수 있습니다. RPC는 네트워크 통신의 세부 사항을 숨겨 개발자에게 원격 호출 프로세스를 보다 투명하고 간단하게 만듭니다.
RPC에서 클라이언트와 서버 간의 통신은 일반적으로 TCP 또는 UDP와 같은 네트워크 전송 프로토콜을 통해 구현됩니다. 전체 프로세스에는 일반적으로 다음 단계가 포함됩니다.
1. 인터페이스 정의: 먼저 클라이언트와 서버 간의 통신을 위한 인터페이스를 정의해야 합니다. 이는 프로토콜, 버퍼, Thrift 또는 SOAP와 같은 특정 IDL(인터페이스 정의 언어)을 사용하여 달성할 수 있습니다. 인터페이스 정의는 사용 가능한 메소드, 매개변수 및 리턴 유형을 설명합니다.
2. 코드 생성: 인터페이스 정의에 따라 IDL 컴파일러에서 클라이언트 및 서버 코드를 생성할 수 있습니다. 이러한 생성된 코드에는 네트워크 통신을 처리하고 데이터를 직렬화/역직렬화하는 데 사용되는 클라이언트 및 서버 스텁(Stub)과 스텁(Skeleton)이 포함됩니다.
3. 원격 호출: 클라이언트 애플리케이션은 로컬 클라이언트 스텁을 호출하여 원격 호출을 트리거할 수 있습니다. 스텁은 호출 요청을 네트워크 메시지로 캡슐화하고 서버로 보내는 역할을 합니다. 서버는 요청을 받은 후 스텁을 사용하여 요청을 구문 분석하고 해당 메서드를 실행합니다. 실행 결과는 응답 메시지로 캡슐화되어 클라이언트로 다시 전송됩니다.
4. 데이터 전송 및 직렬화: RPC에서 함수 매개변수 및 반환 값은 클라이언트와 서버 간에 직렬화 및 역직렬화되어야 합니다. 이는 데이터를 네트워크 전송에 필요한 형식으로 변환하여 서로 다른 컴퓨팅 노드 간에 전송할 수 있도록 하는 것입니다.
5. 오류 처리 및 예외: RPC 프레임워크는 일반적으로 오류 처리 메커니즘과 예외 전파를 제공합니다. 원격 호출에서 오류 또는 예외가 발생하면 적절한 처리를 위해 오류 정보를 클라이언트에 다시 전달할 수 있습니다.
일반적인 RPC 프레임워크에는 gRPC, Apache Thrift, Apache, Avro, XML-RPC 등이 포함됩니다. 이러한 프레임워크는 언어 간 지원, 로드 밸런싱, 서비스 검색 및 인증 등과 같은 다양한 기능을 제공하여 원격 통화를 보다 편리하고 안정적으로 만듭니다.
RPC는 서로 다른 노드 간의 통신 및 협업을 달성하기 위해 마이크로 서비스 아키텍처, 분산 컴퓨팅 및 원격 데이터 액세스 등 분산 시스템의 다양한 시나리오에서 널리 사용됩니다.
I. 서론
이기종 환경에서 작업할 때 엔지니어나 과학자가 애플리케이션 워크플로우의 다양한 단계를 분산할 수 있는 것은 종종 매우 유용합니다. 특히 계산, 저장 또는 분석 및 시각화와 같은 특정 작업에 전념할 수 있는 다양한 유형의 리소스 및 라이브러리를 포함하는 시스템 또는 노드를 보는 것이 일반적인 고성능 컴퓨팅에서 그렇습니다. RPC(원격 프로시저 호출)[1]는 클라이언트/서버 모델을 따르고 로컬 호출이 원격 리소스에서 투명하게 실행되도록 하는 기술입니다. 로컬 함수 매개변수를 메모리 버퍼로 직렬화하고 해당 버퍼를 원격 대상으로 전송하여 매개변수를 역직렬화하고 해당 함수 호출을 실행하는 것으로 구성됩니다. 이 기술을 구현하는 라이브러리는 Google Protocol Buffers[2] 또는 Facebook Thrift[3]를 사용하는 웹 서비스와 같은 다양한 도메인이나 GridRPC를 사용하는 그리드 컴퓨팅[4]과 같은 도메인에서 찾을 수 있습니다. 또한 RPC는 CORBA [5] 또는 Java RMI [6]와 같은 프레임워크를 사용하여 보다 객체 지향적인 접근 방식을 사용하여 실현할 수 있습니다. 여기서 추상 개체 및 메서드는 다양한 노드 또는 시스템에 분산될 수 있습니다.
이기종 환경에서 작업할 때 엔지니어나 과학자가 애플리케이션 워크플로의 개별 단계를 분산할 수 있는 것이 유용한 경우가 많습니다. 특히 고성능 컴퓨팅에서는 다양한 유형의 리소스가 포함된 시스템이나 노드를 보는 것이 일반적입니다. 및 라이브러리, 이러한 리소스 및 라이브러리는 컴퓨팅, 스토리지 또는 분석 및 시각화와 같은 특정 작업 전용일 수 있습니다. RPC(원격 프로시저 호출)[1]는 클라이언트/서버 모델을 따르고 원격 리소스에 대한 로컬 호출을 투명하게 실행할 수 있는 기술입니다. 이것은 로컬 함수 매개변수를 메모리 버퍼로 직렬화하고 해당 버퍼를 원격 대상으로 보내는 것으로 구성되며, 원격 대상은 매개변수를 역직렬화하고 해당 함수 호출을 실행합니다. 이 기술을 구현하는 라이브러리는 Google 프로토콜 버퍼[2] 또는 Facebook Thrift[3]를 사용하는 웹 서비스 또는 GridRPC[4]를 사용하는 그리드 컴퓨팅과 같은 분야에서 찾을 수 있습니다. 또한 RPC는 CORBA [5] 또는 Java RMI [6]와 같은 보다 객체 지향적인 방법 및 프레임워크를 사용하여 구현될 수 있습니다. 여기서 추상 객체 및 방법은 일련의 노드 또는 시스템에 분산될 수 있습니다.
이기종 환경(Heterogeneous Environment): 이기종 환경은 서로 다른 유형의 컴퓨팅 장치 및 프로세서로 구성된 컴퓨팅 시스템을 의미합니다. 이기종 환경에서 서로 다른 장치는 서로 다른 아키텍처, 처리 기능 및 특성을 가질 수 있습니다. 일반적인 이기종 환경은 다음과 같습니다.
1. 멀티 코어 CPU 및 가속기: 이 환경에서 컴퓨팅 시스템은 여러 CPU 코어 및 가속기(예: GPU, FPGA 또는 ASIC)로 구성됩니다. CPU 코어는 일반적으로 범용 컴퓨팅 작업에 사용되는 반면 가속기는 그래픽 렌더링, 딥 러닝 또는 암호화 작업과 같은 고도의 병렬 특정 컴퓨팅 작업에 사용됩니다.
2. 분산 컴퓨팅 클러스터: 이 환경에서 컴퓨팅 시스템은 각각 다른 프로세서 유형과 아키텍처를 가질 수 있는 여러 대의 컴퓨터로 구성됩니다. 클러스터의 컴퓨터는 네트워크를 통해 연결되고 함께 작동하여 대규모 컴퓨팅 작업을 완료할 수 있습니다.
3. 클라우드 컴퓨팅 환경: 클라우드 컴퓨팅은 가상화된 가상 머신 또는 컨테이너가 될 수 있는 네트워크 기반 컴퓨팅 리소스를 제공합니다. 클라우드 환경에서 사용자는 다양한 유형의 가상 머신 인스턴스를 선택할 수 있으며 각 인스턴스는 서로 다른 처리 기능과 특성을 가질 수 있습니다. 이를 통해 사용자는 필요와 예산에 따라 가장 적합한 컴퓨팅 리소스를 선택할 수 있습니다.
이기종 환경에서 다양한 컴퓨팅 장치의 장점을 최대한 활용하기 위해서는 그에 상응하는 프로그래밍 모델과 도구의 개발이 필요하다. 예를 들어 CUDA, OpenCL 또는 MPI와 같은 병렬 프로그래밍 프레임워크를 사용하여 가속기의 병렬 처리 기능을 활용하거나 작업 스케줄러 및 분산 시스템 관리 도구를 사용하여 분산 컴퓨팅 클러스터를 관리합니다.
이기종 환경의 과제는 서로 다른 장치의 컴퓨팅 성능을 효율적으로 활용하고 데이터 전송 및 동기화 문제를 관리하는 것입니다. 그러나 합리적인 작업 할당 및 스케줄링을 통해 고성능 및 효율적인 컴퓨팅을 달성할 수 있습니다.
그러나 HPC 시스템에서 이러한 표준 및 일반 RPC 프레임워크를 사용하면 두 가지 주요 제한 사항이 있습니다. RPC 인터페이스에 의해 부과된 제한이 일반적으로 메가바이트 정도이기 때문에 매우 많은 양의 데이터를 전송할 수 없습니다. 또한 제한이 적용되지 않더라도 RPC 라이브러리를 통해 많은 양의 데이터를 전송하는 것은 일반적으로 바람직하지 않습니다. 대부분 직렬화 및 인코딩으로 인한 오버헤드로 인해 원격 노드에 도달하기 전에 데이터가 여러 번 복사됩니다.
그러나 HPC 시스템에서 이러한 표준 및 공통 RPC 프레임워크를 사용하는 데는 두 가지 주요 제한 사항이 있습니다: 1. 기본 전송 메커니즘을 사용하여 데이터를 효율적으로 전송할 수 없다는 점, 이러한 프레임워크는 주로 TCP/IP 프로토콜을 기반으로 설계되었기 때문입니다. RPC 인터페이스에서 부과하는 제한이 일반적으로 메가바이트(MB) 정도이기 때문에 매우 많은 양의 데이터를 전송할 수 없습니다. 또한 RPC 라이브러리를 통해 많은 양의 데이터를 전송하는 것은 제한을 적용하지 않더라도 일반적으로 권장되지 않습니다. 주로 직렬화 및 인코딩의 오버헤드로 인해 원격 노드에 도달하기 전에 데이터가 여러 번 복사됩니다.
이 문서는 다음과 같이 구성되어 있습니다. 먼저 섹션 II에서 관련 작업을 논의한 다음 섹션 III에서 인터페이스가 구축되는 네트워크 추상화 계층과 크고 작은 데이터를 효율적으로 전송하기 위해 정의된 아키텍처에 대해 논의합니다. 섹션 IV에서는 API를 간략하게 설명하고 파이프라이닝 기술을 사용할 수 있도록 하는 이점을 보여줍니다. 그런 다음 인터페이스용 네트워크 전송 플러그인 개발과 성능 평가 결과에 대해 설명합니다. V장에서는 결론과 향후 작업 방향을 제시한다.
본 논문의 구성은 다음과 같다. 먼저 II장에서 관련 작업을 논의하고, III장에서 인터페이스를 구축하는 네트워크 추상화 계층과 크고 작은 데이터의 효율적인 전송을 위해 정의된 아키텍처에 대해 논의한다. 섹션 IV는 API에 대한 개요를 제공하고 파이프라이닝 사용에 대한 API 지원의 이점을 보여줍니다. 그런 다음 인터페이스용 네트워크 전송 플러그인 개발 및 성능 평가 결과에 대해 설명합니다. V장에서는 결론과 향후 연구 방향을 제시한다.
II. 관련된 일
네트워크 파일 시스템(NFS)[7]은 대용량 데이터 전송에 RPC를 사용하는 매우 좋은 예이므로 HPC 시스템에서 RPC를 사용하는 것과 매우 유사합니다. XDR[8]을 사용하여 임의의 데이터 구조를 직렬화하고 시스템 독립적인 설명을 생성한 다음 결과 바이트 스트림을 원격 리소스로 전송하여 역직렬화하고 데이터를 다시 가져올 수 있습니다. 또한 RDMA 프로토콜을 통해 데이터를 전송하기 위해 별도의 전송 메커니즘(최신 버전의 NFS에서)을 사용할 수 있습니다. 이 경우 데이터는 XDR 스트림 외부에서 처리됩니다. 이 백서에서 제시하는 인터페이스는 유사한 원칙을 따르지만 추가로 대량 데이터를 직접 처리합니다. 또한 데이터 인코딩을 위해 XDR을 사용하는 것으로 제한되지 않습니다. 이는 특히 발신자와 수신자가 공통 시스템 아키텍처를 공유할 때 성능 저하가 될 수 있습니다. 우리가 정의하는 RPC 인터페이스는 네트워크 추상화 계층을 제공함으로써 사용자가 작은 메시지 또는 원격 메모리 액세스(RMA) 유형의 전송을 사용하여 작은 데이터와 큰 데이터를 효율적으로 보낼 수 있는 기능을 제공합니다. HPC 시스템. 또한 제공된 모든 인터페이스는 비차단형이므로 비동기 작업 모드를 허용하여 호출자가 다른 작업이 실행되기 전에 작업이 실행될 때까지 기다릴 필요가 없습니다.
네트워크 파일 시스템(NFS)[7]은 RPC를 사용하여 대용량 데이터 전송을 처리하는 좋은 예이므로 HPC 시스템에서 RPC를 사용하는 것과 매우 유사합니다. XDR[8]을 활용하여 임의의 데이터 구조를 직렬화하고 시스템 독립적인 설명을 생성한 다음 결과 바이트 스트림을 원격 리소스로 전송하여 데이터를 역직렬화하고 검색할 수 있습니다. 또한 별도의 전송 메커니즘(최신 버전의 NFS에서)을 사용하여 RDMA 프로토콜을 통해 데이터를 전송할 수 있으며, 이 경우 데이터는 XDR 스트림 외부에서 처리됩니다. 이 문서에서 제공하는 인터페이스는 유사한 원칙을 따르지만 추가로 대량 데이터를 직접 처리합니다. 또한 XDR을 사용한 데이터 인코딩에 국한되지 않으며, 이는 특히 발신자와 수신자가 공통 시스템 아키텍처를 공유할 때 성능에 영향을 미칠 수 있습니다. 우리가 정의하는 RPC 인터페이스는 네트워크 추상화 계층을 제공함으로써 사용자가 최신 HPC 시스템에 존재하는 일방적 의미 체계를 완벽하게 지원하는 소형 메시지 또는 원격 메모리 액세스(RMA) 유형 전송을 사용하여 크고 작은 데이터를 효율적으로 보낼 수 있도록 합니다. 또한 제시된 모든 인터페이스는 비차단형이므로 비동기 작업 모드를 허용하여 호출자가 다른 작업을 실행하기 전에 한 작업이 실행될 때까지 기다리지 않아도 됩니다.
네트워크 파일 시스템(NFS): NFS(네트워크 파일 시스템)는 컴퓨터 네트워크에서 파일과 디렉토리를 공유하기 위한 프로토콜입니다. 이를 통해 여러 컴퓨터가 마치 로컬 파일인 것처럼 네트워크를 통해 공유 파일 시스템에 투명하게 액세스할 수 있습니다. NFS는 원래 Sun Microsystems에서 개발했으며 널리 사용되는 네트워크 파일 공유 프로토콜이 되었습니다. 파일이 파일 서버에 저장 및 관리되고 클라이언트가 네트워크를 통해 서버의 파일에 대한 액세스를 요청하는 클라이언트-서버 모델을 사용합니다.
NFS의 작동 원리는 다음과 같습니다.
1. 파일 서버 설정: 파일 서버의 디렉토리는 공유 디렉토리로 표시되고 액세스가 허용된 클라이언트 목록이 구성됩니다.2. 클라이언트 마운트: 클라이언트는 특정 NFS 마운트 명령을 사용하여 서버의 공유 디렉토리를 로컬 파일 시스템에 마운트합니다. 일단 마운트되면 클라이언트는 공유 디렉토리와 파일이 로컬 파일인 것처럼 액세스할 수 있습니다.
3. 파일 액세스: 클라이언트는 마운트된 공유 디렉토리 및 파일에서 읽기, 쓰기, 생성 및 삭제와 같은 표준 파일 작업을 수행할 수 있습니다. 이러한 작업은 파일 서버로 전송되고 해당 작업은 서버에서 수행됩니다.
4. 파일 동기화: NFS는 파일에 대한 동시 액세스를 지원하며 여러 클라이언트가 동시에 동일한 파일을 읽고 쓸 수 있습니다. 서버는 동시 액세스에 대한 동기화 및 충돌 해결을 처리합니다.
NFS는 다음과 같은 이점과 기능을 제공합니다.
1. 투명성: NFS는 원격 파일 시스템을 클라이언트에게 투명하게 만들고 클라이언트는 마치 로컬 파일인 것처럼 원격 파일에 액세스할 수 있습니다.
2. 공유 가능성: 여러 클라이언트가 동시에 동일한 파일 시스템에 액세스하고 공유할 수 있으므로 협업 및 리소스 공유가 촉진됩니다.
3. 교차 플랫폼 지원: NFS는 교차 플랫폼이며 UNIX, Linux, Windows 등과 같은 서로 다른 운영 체제 간에 파일을 공유할 수 있습니다.
4. 성능 최적화: NFS는 캐싱 및 미리 읽기와 같은 메커니즘을 지원하여 파일 액세스 성능을 향상시킵니다.
NFS는 파일 공유에 많은 이점이 있지만 네트워크 대기 시간, 보안 및 성능과 같은 몇 가지 고려 사항이 있습니다. NFS를 구성하고 사용할 때 네트워크 환경과 보안 요구 사항을 고려하고 파일 액세스의 안정성과 보안을 보장하기 위해 해당 조치를 취해야 합니다.
XDR(외부 데이터 표현)은 서로 다른 컴퓨터 시스템 간에 데이터를 전송하고 저장하는 데 사용되는 데이터 직렬화 형식입니다. 서로 다른 시스템 간의 데이터 교환을 위해 데이터를 시스템 독립적인 형식으로 변환하는 방법을 설명하는 일련의 사양을 정의합니다. XDR 직렬화는 고정 데이터 표현 형식을 사용하므로 데이터가 서로 다른 시스템과 운영 체제 간에 일관된 표현 및 구문 분석 방법을 갖습니다. 이것은 데이터 이식성과 상호 운용성을 보장합니다. XDR 직렬화 프로세스는 데이터를 네트워크를 통해 전송하거나 디스크 및 기타 미디어에 저장하기 위한 표준 이진 표현으로 변환합니다. 직렬화된 데이터는 네트워크 전송 프로토콜(예: RPC)을 통해 전송되거나 영구적으로 저장될 수 있습니다.
XDR 직렬화 기능은 다음과 같습니다.1. 기계 독립적: XDR은 특정 기계 및 운영 체제와 독립적인 일련의 데이터 표현을 정의하므로 데이터가 다른 플랫폼에서 교환될 수 있습니다.
2. 단순성: XDR 직렬화 형식은 비교적 단순하고 중복 정보를 포함하지 않으며 효율적인 데이터 표현 및 분석 방법을 제공합니다.
3. 확장성: XDR 직렬화는 정수, 부동 소수점 숫자, 문자열, 구조 등을 포함한 여러 데이터 유형을 지원하며 복잡한 데이터 구조를 필요에 따라 정의하고 사용할 수 있습니다.
4. 상호 운용성: XDR 직렬화 형식은 여러 프로그래밍 언어 및 플랫폼에서 지원되므로 서로 다른 시스템이 데이터 교환을 위해 통합된 데이터 표현 방법을 사용할 수 있습니다.
XDR 직렬화는 RPC(Remote Procedure Call) 프로토콜에서 데이터 전송 형식으로 자주 사용됩니다. 데이터를 XDR 형식으로 직렬화하면 클라이언트와 서버 간에 파라미터를 전송하고 결과를 반환하는 것이 편리합니다. XDR 직렬화를 사용하려면 데이터의 구조와 유형을 정의하고 해당 구문 분석 및 직렬화 코드를 작성해야 합니다. 데이터 교환을 위해 XDR을 사용하는 경우 발신자와 수신자는 동일한 데이터 정의 및 직렬화 규칙을 사용하여 데이터의 올바른 구문 분석 및 일관성을 보장해야 합니다.
RMA(원격 메모리 액세스)는 병렬 컴퓨팅 및 고성능 컴퓨팅(HPC) 시스템에서 원격 메모리 액세스를 위한 기술입니다. 이를 통해 컴퓨팅 노드는 메시지 전달 인터페이스 MPI와 같은 기존 메시지 전달 인터페이스를 통해 데이터를 전송할 필요 없이 다른 노드의 메모리에 직접 액세스할 수 있습니다. 전통적인 메시지 전달 프로그래밍 모델에서 노드 간의 데이터 교환은 데이터 복사 및 메시지 전송을 포함하는 명시적인 송수신 작업을 통해 완료되어야 합니다. RMA 모델에서 노드는 원격 노드의 메모리에 직접 액세스할 수 있으므로 데이터 교환을 보다 효율적으로 만들고 데이터 복사 오버헤드를 줄일 수 있습니다.
RMA 모델은 일반적으로 두 가지 주요 작업을 사용합니다.
원격 쓰기: 원격 쓰기 작업을 통해 노드는 원격 노드의 메모리에 데이터를 쓸 수 있습니다. 송신 노드는 수신 노드의 명시적인 수신 작업 없이 수신 노드의 메모리 공간에 직접 데이터를 기록합니다.원격 읽기: 원격 읽기 작업을 통해 노드는 원격 노드의 메모리에서 데이터를 읽을 수 있습니다. 송신 노드는 수신 노드에서 명시적인 송신 작업을 요구하지 않고 수신 노드의 메모리에서 직접 데이터를 읽을 수 있습니다.
RMA 모델의 구현은 일반적으로 InfiniBand(IB) 또는 이더넷의 RDMA(Remote Direct Memory Access) 기술과 같은 전용 고성능 네트워크 인터페이스에 의존합니다. 이러한 인터페이스는 RMA 작업의 효율적인 실행을 지원하기 위해 대기 시간이 짧은 고대역폭 통신 기능을 제공합니다. RMA 모델은 고성능 컴퓨팅 분야, 특히 병렬 컴퓨팅 및 대규모 데이터 처리 분야에서 중요한 애플리케이션을 보유하고 있습니다. 데이터 복사 및 통신 오버헤드를 줄이고 컴퓨팅 노드 간의 데이터 교환 효율성을 개선하여 병렬 컴퓨팅 작업의 실행을 가속화할 수 있습니다. 그러나 RMA 모델에는 메모리 액세스의 정확성과 일관성을 보장하고 데이터 경합 및 동시성 문제를 방지하기 위해 합리적인 프로그래밍 및 디버깅 기술도 필요합니다.
RDMA(Remote Direct Memory Access)는 컴퓨팅 노드 간의 원격 메모리 액세스를 위한 고성능 네트워크 통신 기술입니다. RDMA 기술을 사용하면 컴퓨팅 노드가 중앙 처리 장치(CPU)의 개입 없이 서로 간에 직접 데이터를 전송할 수 있습니다. 전통적인 네트워크 통신 모델에서 데이터 전송에는 일반적으로 CPU의 개입이 필요합니다. 즉, 소스 노드에서 송신 노드의 커널 버퍼로 데이터가 복사된 다음 수신 노드의 커널 버퍼에서 복사됩니다. 대상 노드의 메모리에. 이 데이터 복사 프로세스에는 CPU 처리 및 컨텍스트 전환이 포함되어 추가 대기 시간과 시스템 오버헤드가 발생합니다. RDMA 기술을 사용하면 CPU 및 커널 버퍼의 개입을 우회하여 소스 노드의 메모리에서 대상 노드의 메모리로 데이터를 직접 복사할 수 있습니다. 이것은 짧은 대기 시간과 높은 대역폭을 특징으로 하여 데이터 전송을 보다 효율적으로 만듭니다.
RDMA 기술은 일반적으로 IB(InfiniBand) 또는 RoCE( RDMA over Converged Ethernet)와 같은 전용 고성능 네트워크 인터페이스를 기반으로 합니다 . 이러한 인터페이스는 데이터 패킷 전송, 데이터 무결성 검사 및 흐름 제어와 같은 기능을 포함하여 하드웨어 수준의 지원을 제공합니다. RDMA 기술은 고성능 컴퓨팅(HPC) 분야에서 널리 사용되며 대규모 병렬 컴퓨팅, 데이터 센터 상호 연결 및 스토리지 시스템과 같은 시나리오에 특히 적합합니다. 낮은 대기 시간, 높은 처리량 및 낮은 CPU 사용량으로 통신 기능을 제공하여 데이터 전송 및 처리 작업을 가속화할 수 있습니다. RDMA 기술을 사용하여 데이터를 전송하려면 적절한 프로그래밍 모델과 MPI(Message Passing Interface) 또는 RDMA 인식 라이브러리 및 프레임워크와 같은 소프트웨어 지원이 필요합니다. 이러한 도구는 RDMA의 추상화 및 캡슐화를 제공하므로 개발자는 효율적인 원격 메모리 액세스를 위해 RDMA 기술을 쉽게 사용할 수 있습니다.
비동기 작업 모드는 네트워크 요청, 파일 읽기 및 쓰기, 데이터베이스 쿼리 등과 같이 장시간 실행해야 하는 작업을 처리하기 위한 프로그래밍 모드입니다. 기존의 동기식 작업 모드에서 프로그램은 실행을 계속하기 전에 작업이 완료될 때까지 대기하는 반면, 비동기식 작업 모드에서는 프로그램이 작업이 완료될 때까지 기다리지 않고 다른 작업을 계속 수행할 수 있습니다. 비동기 작업 패턴의 핵심은 작업을 다른 작업이나 스레드에 위임하고 작업이 완료되면 메인 스레드에 알리거나 콜백 함수를 호출하여 결과를 처리하는 것입니다. 이렇게 하면 특히 많은 수의 IO 작업을 처리해야 하는 시나리오의 경우 프로그램의 동시성 및 응답성이 향상될 수 있습니다.
비동기 작업 모드에는 일반적으로 다음 개념이 포함됩니다.
1. 비동기 함수/메소드: 비동기 함수 또는 메서드는 작업 중에 일시 중단될 수 있는 함수 또는 메서드를 말하며 중간 결과를 반환합니다. 이들은 일반적으로 특수 키워드 또는 수정자(예: async/await)로 식별되며 컴파일러가 이를 적절한 비동기 코드로 전환하도록 지시합니다.
2. 콜백 함수: 콜백 함수는 비동기 작업이 완료되었을 때 호출되는 함수입니다. 일반적으로 비동기 작업에 매개 변수로 전달되며 작업이 완료된 후 호출되어 작업 결과를 처리합니다. 콜백 함수는 성공 조건, 오류 처리, 리소스 정리 등을 처리하는 데 사용할 수 있습니다.
3. 비동기 작업 스케줄러: 비동기 작업 스케줄러는 비동기 작업의 실행을 관리하고 예약하는 역할을 합니다. 작업의 실행 순서를 결정하고 사용 가능한 시스템 리소스 및 작업 우선 순위와 같은 조건에 따라 리소스를 할당할 수 있습니다.
4. 비동기 이벤트 루프: 비동기 이벤트 루프는 비동기 작업의 완료 알림을 수신 및 처리하고 콜백 함수의 실행을 예약하는 데 사용되는 메인 스레드에서 실행되는 루프입니다. 이벤트 대기열을 관리하고 완료된 작업을 처리하며 해당 콜백 함수를 실행 대기열로 푸시하는 일을 담당합니다.
비동기 작동 모드의 이점은 다음과 같습니다.
1. 프로그램의 동시성 및 응답성 향상: 각 작업이 완료될 때까지 기다리지 않고 여러 작업을 동시에 처리할 수 있습니다.
2. 리소스 낭비 감소: IO 작업이 완료되기를 기다리는 동안 CPU 리소스를 사용하여 다른 작업을 수행하여 리소스 활용도를 높일 수 있습니다.
3. 더 나은 사용자 경험: 비동기 작업은 시간 소모적인 작업을 수행하는 동안 프로그램의 응답성을 유지하여 사용자 경험을 향상시킬 수 있습니다.
I/O Forwarding Scalability Layer(IOFSL)[9]는 이 백서에 제시된 작업의 일부가 기반으로 하는 또 다른 프로젝트입니다. IOFSL은 특히 I/O 호출을 전달하기 위해 RPC를 사용합니다. 함수 매개변수를 로컬에서 직렬화하고 이를 원격 서버로 전송하는 ZOIDFS라는 API를 정의합니다. 여기서 매개변수는 파일 시스템 특정 I/O 작업에 매핑될 수 있습니다. IOPSL에 이미 존재하는 작업을 확장하는 주요 동기 중 하나는 ZOIDFS API를 통해 정의된 것과 같은 특정 호출 세트뿐만 아니라 다양한 호출 세트를 보낼 수 있는 기능입니다. 일반적으로 정의됩니다. IOPSL이 PVFS(Parallel Virtual File System)[11]에서 사용되는 BMI[10] 네트워크 전송 계층 위에 구축된다는 점도 주목할 가치가 있습니다. 이는 내결함성뿐 아니라 동적 연결에 대한 지원을 허용하고 비동기 작동 모드를 가능하게 할 수 있는 예기치 않은 메시지와 예상되는 메시지(섹션 III-B에서 설명)의 두 가지 유형의 메시징을 정의합니다. 그럼에도 불구하고 BMI는 클라이언트 메모리에서 서버 메모리로 RDMA 작업을 명시적으로 달성하는 데 필요한 RMA 시맨틱을 직접 노출하지 않아 설계에 제한이 있습니다. 이는 문제 및 성능 제한이 될 수 있습니다(RMA 접근 방식을 사용하는 주요 이점은 다음과 같습니다. 섹션 III-B에 설명되어 있음). 또한 BMI는 일방적인 작업을 제공하지 않지만 비교적 높은 수준의 네트워크 작업 집합을 제공합니다. 이로 인해 BMI를 새로운 네트워크 전송(예: Cray Gemini 상호 연결 [12])으로 포팅하는 작업이 쉽지 않고 예상보다 더 많은 시간이 소요됩니다.
I/O Forwarding Scalability Layer(IOFSL)[9]는 여기에 제시된 일부 작업의 기반이 되는 또 다른 프로젝트입니다. IOFSL은 RPC를 사용하여 독점적으로 I/O 호출을 전달합니다. ZOIDFS라는 API를 정의합니다. 이 API는 함수 인수를 로컬에서 직렬화하고 원격 서버로 전송하여 파일 시스템별 I/O 작업에 매핑할 수 있습니다. IOFSL에 이미 존재하는 작업을 확장하는 주요 동기 중 하나는 특정 호출 세트(ZOIDFS API를 통해 정의됨)뿐만 아니라 동적으로 및 일반적으로 정의될 수 있는 다양한 호출을 보낼 수 있다는 것입니다. IOPSL이 PVFS(Parallel Virtual File System)[11]에서 사용되는 BMI[10] 네트워크 전송 계층 위에 구축된다는 점도 주목할 가치가 있습니다. 동적 연결 및 내결함성을 지원하고 비동기식 작동 모드를 가능하게 하는 예상치 못한 메시지와 예상되는 메시지(섹션 III-B에서 설명)의 두 가지 유형의 메시징도 정의합니다. 그러나 BMI는 문제 및 성능 제한이 될 수 있는 클라이언트 메모리에서 서버 메모리로 RDMA 작업을 명시적으로 구현하는 데 필요한 RMA 의미 체계를 직접 노출하지 않기 때문에 설계에 제한이 있습니다(RMA 접근 방식을 사용하는 주요 이점은 다음과 같습니다. 섹션 III-B에서 설명) 또한 BMI는 일방적인 작업을 제공하지 않지만 비교적 높은 수준의 네트워크 작업 집합을 제공합니다. 이로 인해 BMI를 새로운 네트워크 전송(예: CrayGemini 상호 연결 [12])으로 포팅하는 것이 쉽지 않고 예상보다 더 많은 시간이 소요됩니다. 우리의 맥락에서 RPC를 구현하려면 BMI가 제공하는 기능의 일부만 필요하기 때문입니다. 부분 집합.
IOPSL(I/O Forwarding Scalability Layer)은 고성능 컴퓨팅(HPC) 시스템에서 확장성을 제공하는 데 사용되는 I/O 전달 계층입니다. 대규모 병렬 컴퓨팅에서 I/O 병목 현상과 성능 문제를 해결하고 I/O 로드를 최적화하고 분산하여 시스템의 I/O 성능과 확장성을 향상시키는 것을 목표로 합니다. IOFSL은 컴퓨팅 노드와 스토리지 노드 사이에 중간 계층을 도입하여 컴퓨팅 노드에서 스토리지 노드로 I/O 요청을 전달하고 I/O 로드의 균형을 맞추고 최적화합니다. 다음과 같은 주요 기능을 제공합니다.
1. I/O 분산 및 로드 밸런싱: IOFSL 계층은 I/O 요청을 여러 스토리지 노드의 여러 디스크 장치에 분산하여 로드 밸런싱 및 병렬 I/O 작업을 구현합니다. 이러한 방식으로 스토리지 시스템의 대역폭과 처리량을 최대한 활용하고 전반적인 I/O 성능을 향상시킬 수 있습니다.
2. 데이터 집계 및 캐싱: IOPSL 계층은 서로 다른 컴퓨팅 노드의 작은 I/O 요청을 더 큰 데이터 블록으로 집계하고 데이터 캐싱을 수행하여 스토리지 시스템의 부하와 네트워크 전송 오버헤드를 줄일 수 있습니다. 이는 데이터 액세스 효율성과 전반적인 I/O 성능을 향상시키는 데 도움이 됩니다.
3. 데이터 압축 및 인코딩: IOFSL 계층은 네트워크 전송에서 데이터의 대역폭 소비를 줄이기 위해 데이터 압축 및 인코딩 기술을 구현할 수 있습니다. 이를 통해 스토리지 시스템의 로드를 줄이고 데이터 전송 프로세스 속도를 높일 수 있습니다.
4. 확장성 및 탄력성: IOFSL은 확장 및 구성이 가능하도록 설계되었으며 다양한 크기와 요구의 HPC 시스템에 적응할 수 있습니다. 스토리지 노드의 동적 증가 또는 감소를 지원하고 시스템 변경 및 장애에 자동으로 적응합니다.
IOFSL 계층을 도입함으로써 HPC 시스템은 스토리지 리소스를 최대한 활용하고 I/O 성능과 확장성을 향상시킬 수 있습니다. 대규모 병렬 컴퓨팅 및 데이터 집약적 애플리케이션에 매우 유용하며 I/O 작업을 최적화하고 데이터 전송 오버헤드를 줄여 전반적인 컴퓨팅 효율성과 시스템 성능을 향상시킬 수 있습니다.
PVFS(Parallel Virtual File System)는 고성능 병렬 컴퓨팅 환경을 구축하는 데 사용되는 분산 파일 시스템입니다. PVFS의 설계 목표는 대량 병렬 컴퓨팅에서 파일 시스템의 고성능 요구 사항을 충족하기 위해 높은 처리량, 짧은 대기 시간 및 확장성을 제공하는 것입니다. PVFS는 여러 스토리지 노드를 논리적 파일 시스템으로 구성하는 것을 지원하고 병렬로 파일에 액세스하는 기능을 제공합니다. 파일 데이터를 여러 스토리지 노드에 배포하고 여러 컴퓨팅 노드가 파일에 병렬로 액세스하여 효율적인 I/O 작업을 달성할 수 있도록 합니다.
PVFS의 주요 기능 및 설계 원칙은 다음과 같습니다.
1. 분산 아키텍처: PVFS는 분산 아키텍처를 채택하여 파일 데이터를 여러 스토리지 노드에 분산 및 저장하여 병렬 데이터 액세스 및 높은 처리량 I/O 작업을 달성합니다.
2. 병렬 액세스: PVFS를 사용하면 여러 컴퓨팅 노드가 동시에 파일에 액세스하여 병렬 읽기 및 쓰기 작업을 실현할 수 있습니다. 이 병렬 액세스 방법은 파일 시스템의 성능과 응답 속도를 향상시킬 수 있습니다.
3. 데이터 분산 및 로드 밸런싱: PVFS는 데이터 분산 전략을 사용하여 파일 데이터를 여러 스토리지 노드에 균등하게 분산하여 로드 밸런싱 및 효율적인 데이터 액세스를 달성합니다.
4. 내결함성 및 확장성: PVFS에는 노드 장애의 자동 감지 및 복구를 지원하는 내결함성 메커니즘이 있습니다. 또한 PVFS는 확장성도 뛰어나 파일 시스템의 용량과 성능을 확장하기 위해 필요에 따라 스토리지 노드를 추가할 수 있습니다.
BMI(대량 메모리 작업)는 대용량 메모리 작업의 성능을 향상시키기 위해 x86-64 아키텍처에 도입된 일련의 명령 및 기능입니다. 메모리 영역 복사, 채우기 및 비교와 같이 큰 메모리 블록을 효율적으로 조작하는 방법을 제공합니다. BMI에는 메모리 블록을 조작하기 위한 movs, stos, cmps 및 lods와 같은 여러 명령어가 포함되어 있습니다. 이러한 명령어는 SIMD(Single Instruction Multiple Data) 기능을 활용하고 필요한 메모리 액세스 수를 줄여 대량의 데이터를 효율적으로 처리하도록 최적화되어 있습니다. BMI 지침의 주요 이점은 다음과 같습니다.
1. 성능 향상: BMI 명령은 SIMD 기능을 활용하고 메모리 액세스 수를 줄여 대용량 메모리 작업의 성능을 향상시킵니다.
2. 명령 수 감소: BMI 명령을 사용하면 필요한 명령 수를 줄일 수 있으므로 명령의 실행 시간과 전력 소비를 줄일 수 있습니다.
3. 코드 단순화: BMI 명령은 메모리 블록을 직접 작동하는 기능을 제공하여 코드 작성 및 유지 관리를 단순화하고 개발 효율성을 향상시킬 수 있습니다.
또 다른 프로젝트인 Sandia National Laboratories의 NEtwork Scalable Service Interface(Nessie)[13] 시스템은 경량 파일 시스템[14] 프로젝트를 위해 원래 개발된 간단한 RPC 메커니즘을 제공합니다. 주로 계산과 I/O를 중첩하도록 설계된 비동기식 RPC 솔루션을 제공합니다. Nessie의 RPC 인터페이스는 실질적으로 모든 고성능 컴퓨팅 시스템이 동종이지만 주로 이기종 아키텍처 간에 통신하도록 설계된 Sun XDR 솔루션에 직접 의존합니다. Nessie는 RDMA를 사용하여 한 메모리에서 다른 메모리로 데이터를 효율적으로 전송하고 여러 네트워크 전송을 지원합니다. Nessie 클라이언트는 RPC 인터페이스를 사용하여 제어 메시지를 서버에 푸시합니다. 또한 Nessie는 다른 사용자가 클라이언트와 서버 간에 데이터를 푸시하거나 풀하는 데 사용할 수 있는 일방적 API(포털[15]와 유사). Mercury는 기본적으로 RDMA도 지원하는 인터페이스라는 점에서 다릅니다. 원격 대용량 데이터 인수를 나타내는 추상 메모리 핸들을 자동으로 생성하여 사용자가 쉽게 조작할 수 있고 사용자의 추가 노력이 필요하지 않습니다. 또한 Mercury는 필요한 경우(예: 파이프라이닝 구현) 데이터 전송에 대한 세밀한 제어를 제공합니다. 또한 Mercury는 Nessie보다 높은 수준의 인터페이스를 제공하므로 RPC 기능을 구현하는 데 필요한 사용자 코드의 양이 크게 줄어듭니다. 원격 대용량 데이터 인수를 나타내는 추상 메모리 핸들을 자동으로 생성하여 대량 데이터를 투명하게 처리할 수 있습니다. 이 핸들은 조작하기 쉽고 사용자의 추가 노력이 필요하지 않습니다. 또한 필요한 경우 Mercury는 데이터 전송에 대한 미세한 제어를 제공합니다( 예를 들어 파이프라이닝 구현). 또한 Mercury는 Nessie보다 높은 수준의 인터페이스를 제공하므로 RPC 기능을 구현하는 데 필요한 사용자 코드의 양이 크게 줄어듭니다. 원격 대용량 데이터 인수를 나타내는 추상 메모리 핸들을 자동으로 생성하여 대량 데이터를 투명하게 처리할 수 있습니다. 이 핸들은 조작하기 쉽고 사용자의 추가 노력이 필요하지 않습니다. 또한 필요한 경우 Mercury는 데이터 전송에 대한 미세한 제어를 제공합니다( 예를 들어 파이프라이닝 구현). 또한 Mercury는 Nessie보다 높은 수준의 인터페이스를 제공하므로 RPC 기능을 구현하는 데 필요한 사용자 코드의 양이 크게 줄어듭니다.
또 다른 프로젝트인 Sandia National Laboratories의 NEtworkScalable Service Interface(Nessie)[13] 시스템은 원래 LightweightFile Systems[14] 프로젝트를 위해 개발된 간단한 RPC 메커니즘을 제공합니다. 주로 중첩 계산 및 I/O용으로 설계된 비동기 RPC 솔루션을 제공합니다. Nessie의 RPC 인터페이스는 거의 모든 HPC 시스템이 동종임에도 불구하고 주로 이기종 아키텍처 간의 통신을 위해 설계된 Sun XDR 솔루션에 직접 의존합니다. Nessie는 대량 데이터 전송을 처리하는 단일 메커니즘을 제공하고 RDMA를 사용하여 한 메모리에서 다른 메모리로 데이터를 효율적으로 전송할 수 있으며 다중 네트워크 전송을 지원합니다. Nessie 클라이언트는 RPC 인터페이스를 사용하여 제어 메시지를 서버에 푸시합니다. 또한 Nessie는 사용자가 클라이언트와 서버 간에 데이터를 푸시하거나 풀하는 데 사용할 수 있는 다른 일방적 API(포털 [15]와 유사)를 노출합니다. Mercury는 인터페이스 자체가 RDMA를 지원하기 때문에 다릅니다. RDMA는 조작하기 쉽고 사용자의 추가 작업이 필요하지 않은 원격 빅 데이터 매개변수를 나타내는 추상 메모리 핸들을 자동으로 생성하여 사용자의 대량 데이터를 투명하게 처리할 수 있습니다. 또한 Mercury는 원하는 경우 데이터 전송에 대한 세분화된 제어(예: 파이프라이닝 구현)를 제공합니다. 또한 Mercury는 Nessie보다 높은 수준의 인터페이스를 제공하므로 RPC 기능을 구현하는 데 필요한 사용자 코드의 양이 크게 줄어듭니다.
DART(Decoupled and Asynchronous Remote Transfers)[16] 프로젝트에서도 유사한 접근 방식을 볼 수 있습니다. DART는 명시적 RPC 프레임워크로 정의되지 않았지만 클라이언트/서버 모델을 사용하여 HPC 시스템의 컴퓨팅 노드를 로컬 스토리지 또는 원격 위치로 연결하여 원격 애플리케이션 모니터링, 데이터 분석, 코드 결합 및 데이터 보관을 가능하게 합니다. DART가 충족시키려는 주요 요구 사항에는 애플리케이션의 데이터 전송 오버헤드 최소화, 높은 처리량, 낮은 대기 시간 데이터 전송 달성 및 데이터 손실 방지가 포함됩니다. 이러한 목표를 달성하기 위해 DART는 전용 노드, 즉 애플리케이션 컴퓨팅 노드와 분리되어 RDMA를 사용하여 컴퓨팅 노드의 메모리에서 비동기식으로 데이터를 추출하도록 설계되었습니다. 이런 식으로,
DART(Decoupled and Asynchronous Remote Transfers) [16] 프로젝트에서 또 다른 유사한 접근 방식을 볼 수 있습니다. 명시적 RPC 프레임워크로 정의되지는 않았지만 DART를 사용하면 클라이언트/서버 모델을 사용하여 HPC 시스템의 컴퓨팅 노드에서 실행되는 애플리케이션에서 원격 애플리케이션 모니터링, 데이터 분석, 코드 결합을 위해 로컬 스토리지 또는 원격 위치로 대량의 데이터를 전송할 수 있습니다. 그리고 데이터 아카이빙. DART가 충족하고자 하는 주요 요구 사항에는 애플리케이션의 데이터 전송 오버헤드 최소화, 높은 처리량 달성, 낮은 대기 시간 데이터 전송 및 데이터 손실 방지가 포함됩니다. 이러한 목표를 달성하기 위해 DART는 전용 노드(즉, 애플리케이션 컴퓨팅 노드와 분리됨)가 RDMA를 사용하여 컴퓨팅 노드의 메모리에서 비동기식으로 데이터를 가져오도록 설계되었습니다. 이러한 방식으로 애플리케이션 컴퓨팅 노드에서 전용 노드로의 값비싼 데이터 I/O 및 스트리밍 작업이 오프로드되고 애플리케이션이 데이터 전송과 동시에 진행할 수 있습니다. DART를 사용하는 것은 불투명하므로 사용자가 명시적 요청을 보내야 하지만 네트워크 추상화 계층에 이러한 프레임워크를 통합하는 데 내재된 제한이 없으므로 정의된 RPC 계층에 래핑하면 사용자가 다음을 지원할 수 있습니다. 플랫폼은 DART를 사용하여 전송 데이터.
III. 건축학
이전 섹션에서 언급했듯이 Mercury의 인터페이스는 네트워크 추상화 계층, 일반적인 방식으로 호출을 처리할 수 있는 RPC 인터페이스, RPC 계층을 보완하고 쉽게 전송하도록 의도된 대량 데이터 인터페이스의 세 가지 주요 구성 요소에 의존합니다. 메모리 세그먼트를 추상화하여 대량의 데이터. 이 섹션에서는 전체 아키텍처와 각 구성 요소를 제시합니다.
이전 섹션에서 언급했듯이 Mercury의 인터페이스는 네트워크 추상화 계층 NA, 일반적인 방식으로 호출을 처리할 수 있는 RPC 인터페이스, RPC 계층을 보완하고 설계되는 대량 데이터 인터페이스(Bulk)의 세 가지 주요 구성 요소에 의존합니다. 쉽게 전송하기 위해 추상 메모리 세그먼트를 통과하는 데이터의 양. 이 섹션에서는 전체 아키텍처와 각 구성 요소를 소개합니다.
가. 개요
RPC 인터페이스는 클라이언트/서버 아키텍처를 따릅니다. 그림 1에 설명된 대로 원격 호출을 실행하면 호출과 관련된 데이터의 크기에 따라 다른 단계가 수행됩니다. 우리는 두 가지 유형의 전송을 구분합니다. 일반적으로 메타데이터라고 하는 일반적으로 작은 일반적인 함수 매개변수를 포함하는 전송과 대량 데이터라고 하는 대용량 데이터를 설명하는 함수 매개변수의 전송입니다.
RPC 인터페이스는 클라이언트/서버 아키텍처를 따릅니다. 그림 1에 표시된 것처럼 원격 호출을 수행하면 호출과 관련된 데이터의 크기에 따라 다른 단계가 수행됩니다. 우리는 두 가지 유형의 전송을 구별합니다: 일반적으로 메타데이터라고 하는 작은 일반적인 기능 매개변수를 포함하는 전송과 대량 데이터라고 하는 대량의 데이터를 설명하는 기능 매개변수의 전송입니다.
그림 1: 아키텍처 개요: 각 당사자는 RPC 핸들러를 사용하여 인터페이스를 통해 전송된 매개변수를 직렬화 및 역직렬화합니다. 상대적으로 작은 매개변수를 가진 함수를 호출하면 네트워크 추상화 계층에 의해 노출된 짧은 메시지 전달 메커니즘이 사용되는 반면, 큰 데이터 매개변수가 있는 함수는 추가로 RMA 메커니즘을 사용합니다.
인터페이스를 통해 전송된 모든 RPC 호출은 함수 매개변수를 메모리 버퍼(상호 연결에 따라 일반적으로 1킬로바이트로 제한되는 크기)로 직렬화한 다음 네트워크 추상화 계층 인터페이스를 사용하여 서버로 전송됩니다. 주요 요구 사항 중 하나는 특히 대량의 데이터를 전송할 때 전송의 모든 단계에서 메모리 복사본을 제한하는 것입니다. 따라서 전송된 데이터가 작으면 직렬화되어 작은 메시지를 사용하여 전송됩니다. 그렇지 않으면 전송될 메모리 영역에 대한 설명이 동일한 작은 메시지 내에서 서버로 전송됩니다. 그런 다음 데이터 풀링을 시작할 수 있습니다(만약 데이터가 원격 호출의 입력인 경우) 또는 데이터를 푸시합니다(데이터가 원격 호출의 출력인 경우). 서버에 대한 초기 RPC 요청의 크기를 제한하면 확장성에도 도움이 됩니다. 동일한 서버에 동시에 접속하는 클라이언트가 많을 경우 불필요한 서버 리소스 소모를 방지하기 때문입니다. 원하는 제어 정도에 따라 이러한 모든 단계를 Mercury에서 투명하게 처리하거나 사용자에게 직접 노출할 수 있습니다.
인터페이스를 통해 전송된 각 RPC 호출은 함수 매개변수를 메모리 내 버퍼(상호 연결에 따라 크기가 1KB로 제한되는 경우가 많음)로 직렬화한 다음 네트워크 추상화 계층 인터페이스를 사용하여 서버로 전송합니다. 주요 요구 사항 중 하나는 특히 대량의 데이터를 전송할 때 전송의 모든 단계에서 메모리 복사본을 제한하는 것입니다. 따라서 전송된 데이터가 작으면 직렬화되어 작은 메시지를 사용하여 전송됩니다. 그렇지 않으면 전송될 메모리 영역에 대한 설명이 동일한 작은 메시지로 서버에 전송되고 서버는 데이터 풀링을 시작할 수 있습니다. 데이터가 원격 호출에 입력됨) 또는 데이터가 원격 호출의 출력인 경우 데이터를 푸시합니다. 서버에 대한 초기 RPC 요청의 크기를 제한하면 많은 수의 클라이언트가 동시에 동일한 서버에 액세스하는 경우 서버 리소스의 불필요한 소비를 방지하므로 확장성에도 도움이 됩니다. 필요한 제어 수준에 따라 Mercury에서 이러한 모든 단계를 투명하게 처리하거나 사용자에게 직접 노출할 수 있습니다.
B. 네트워크 추상화 계층
네트워크 추상화 계층의 주요 목적은 이름에서 알 수 있듯이 사용자에게 노출되는 네트워크 프로토콜을 추상화하여 플러그인 시스템을 통해 여러 전송을 통합할 수 있도록 하는 것입니다. 이 아키텍처에 의해 부과된 직접적인 결과는 새로운 플러그인을 구현하는 데 합리적인 노력만 필요한 경량 인터페이스를 제공하는 것입니다. 인터페이스 자체는 데이터 전송을 위한 세 가지 주요 유형의 메커니즘을 정의해야 합니다. 예기치 않은 메시징, 예상되는 메시징 및 원격 메모리 액세스; 또한 클라이언트와 서버 간의 연결을 동적으로 설정하는 데 필요한 추가 설정도 있습니다(동적 연결은 사용되는 기본 네트워크 구현에 따라 항상 가능하지 않을 수 있음).
이름에서 알 수 있듯이 네트워크 추상화 계층의 주요 목적은 사용자에게 노출된 네트워크 프로토콜을 추상화하여 플러그인 시스템을 통해 여러 전송을 통합할 수 있도록 하는 것입니다. 이 아키텍처의 직접적인 결과는 합리적인 노력만으로 새 플러그인을 구현할 수 있도록 가벼운 인터페이스를 제공하는 것입니다. 인터페이스 자체는 데이터 전송을 위한 세 가지 주요 유형의 메커니즘을 정의해야 합니다: 예기치 않은 메시지 전달 예기치 않은 예상 메시지 전달 예상 원격 메모리 액세스 rma 클라이언트와 서버 간의 연결을 동적으로 설정하는 데 필요한 추가 설정(동적 연결 사용되는 기본 네트워크 구현에 따라 항상 가능한 것은 아닙니다(사용되는 항목에 따라 다름).
예상치 못한 예상 메시징은 짧은 메시지 전송으로 제한되며 양방향 접근 방식을 사용합니다. 최대 메시지 크기는 성능상의 이유로 상호 연결에 의해 결정되며 몇 킬로바이트 정도로 작을 수 있습니다. 예상치 못한 메시징의 개념은 BMI[10]와 같은 다른 통신 프로토콜에서 사용됩니다. 네트워크 추상화 계층을 통해 예기치 않은 메시지를 보내는 경우 완료되기 전에 일치하는 수신을 게시할 필요가 없습니다. 이 메커니즘을 사용하면 클라이언트가 차단되지 않고 서버에서 예기치 않은 수신이 발생할 때마다 게시된 새 메시지를 선택할 수 있습니다. 예상 메시지와 예상치 못한 메시지의 또 다른 차이점은 예상치 못한 메시지가 모든 원격 소스에서 도착할 수 있는 반면 예상 메시지는 원격 소스를 알아야 한다는 것입니다.
예상치 못한 예상 메시지는 단문 메시지 전송으로 제한되며 양방향 방식을 사용합니다. 성능상의 이유로 최대 메시지 크기는 상호 연결에 의해 결정되며 몇 킬로바이트 정도로 작을 수 있습니다. 우발적인 메시지 전달의 개념은 BMI[10]와 같은 다른 통신 프로토콜에서도 사용됩니다. 네트워크 추상화 계층을 통해 예기치 않은 메시지를 보내는 경우 완료 전에 일치하는 수신을 게시할 필요가 없습니다. 이 메커니즘을 사용하면 클라이언트가 차단되지 않고 서버가 예기치 않은 수신이 발생할 때마다 게시된 새 메시지를 선택할 수 있습니다. 예상 메시지와 예상치 못한 메시지의 또 다른 차이점은 예상치 못한 메시지가 모든 원격 소스에서 도착할 수 있는 반면 예상 메시지는 원격 소스에 대한 지식이 필요하다는 것입니다.
원격 메모리 액세스(RMA) 인터페이스를 사용하면 원격 메모리 청크(연속 및 비연속)에 액세스할 수 있습니다. 대부분의 단면 인터페이스 및 RDMA 프로토콜에서는 메모리를 사용하기 전에 NIC(네트워크 인터페이스 컨트롤러)에 등록해야 합니다. 네트워크 추상화 계층에 정의된 인터페이스의 목적은 1차 추상화를 생성하고 대부분의 RMA 프로토콜과 호환되는 API를 정의하는 것입니다. 메모리 세그먼트를 NIC에 등록하면 일반적으로 가상 주소 정보 등을 포함하는 해당 세그먼트에 대한 핸들이 생성됩니다. 생성된 로컬 핸들은 해당 노드가 넣기 또는 가져오기 작업을 시작하기 전에 원격 노드와 통신해야 합니다. 네트워크 추상화는 이러한 메모리 핸들이 직렬화되고 네트워크를 통해 전송될 수 있도록 하는 역할을 합니다. 핸들이 교환되면 비차단 넣기 또는 가져오기를 시작할 수 있습니다. 대부분의 상호 연결에서 넣기 및 가져오기는 상호 연결에서 제공하는 특정 API에서 제공하는 넣기 및 가져오기 작업에 매핑됩니다. 네트워크 추상화 인터페이스는 양방향 메시징 접근 방식만 지원하는 TCP/IP와 같은 네트워크 프로토콜에 대해 양방향 전송 및 수신 위에 단방향 전송을 에뮬레이션할 수 있도록 설계되었습니다.
원격 메모리 액세스(RMA) 인터페이스는 원격 메모리 블록(연속 및 비연속)에 대한 액세스를 허용합니다. 대부분의 단방향 인터페이스 및 RDMA 프로토콜에서는 메모리를 사용하기 전에 NIC(네트워크 인터페이스 컨트롤러)에 등록해야 합니다. 네트워크 추상화 계층에서 인터페이스를 정의하는 목적은 추상화의 첫 번째 수준을 만들고 대부분의 RMA 프로토콜과 호환되는 API를 정의하는 것입니다. NIC에 메모리 세그먼트를 등록하면 일반적으로 무엇보다도 가상 주소 정보를 포함하는 해당 세그먼트에 대한 핸들이 생성됩니다. 생성된 로컬 핸들은 put 또는 get 작업을 시작하기 전에 원격 노드와 통신해야 합니다. 네트워크 추상화는 이러한 메모리 핸들이 직렬화되고 네트워크를 통해 전송될 수 있도록 보장하는 역할을 합니다. 핸들이 교환된 후 비차단 넣기 또는 가져오기를 시작할 수 있습니다. 대부분의 상호 연결에서 넣기 및 가져오기는 상호 연결에서 제공하는 특정 API에서 제공하는 넣기 및 가져오기 작업에 매핑됩니다. 네트워크 추상화 인터페이스는 양방향 메시징 방법만 지원하는 TCP/IP와 같은 양방향 송신 및 수신 네트워크 프로토콜 위에 단방향 전송을 에뮬레이션할 수 있도록 설계되었습니다. 이 네트워크 추상화 계층을 통해 Mercury를 쉽게 포팅하여 새로운 상호 연결을 지원할 수 있습니다. 네트워크 추상화에 의해 제공되는 상대적으로 제한된 기능(예: 무한한 크기의 양방향 메시지 없음)은 거의 기본 성능을 보장합니다.
이 네트워크 추상화 계층을 사용하면 Mercury를 쉽게 포팅하여 새로운 상호 연결을 지원할 수 있습니다. 네트워크 추상화에 의해 제공되는 상대적으로 제한된 기능(예: 무제한 크기의 양면 메시지 없음)은 기본 성능에 가까운 성능을 보장합니다.
이 네트워크 추상화 계층을 사용하면 Mercury를 쉽게 포팅하여 새로운 상호 연결을 지원할 수 있습니다. 네트워크 추상화에 의해 제공되는 상대적으로 제한된 기능(예: 무한한 크기의 양방향 메시지 없음)은 거의 기본 성능을 보장합니다.
양방향 메시지라고도 하는 양면 메시지는 두 엔터티가 양방향으로 메시지를 교환할 수 있는 통신 패턴입니다. 이 모드에서 각 엔터티는 양방향 통신을 실현하기 위해 발신자와 수신자 역할을 모두 수행할 수 있습니다.
병렬 컴퓨팅 또는 분산 시스템의 맥락에서 양방향 메시지를 통해 두 프로세스 또는 노드 간에 데이터 또는 정보를 교환할 수 있습니다. 각 엔터티는 메시지를 보내 통신을 시작할 수 있으며 수신자는 메시지를 처리하고 응답을 보낼 수 있습니다. 이 양방향 메시지 교환을 통해 엔터티 간에 상호 조정된 통신이 가능합니다. 양방향 메시지는 병렬 및 분산 컴퓨팅 프레임워크의 메시징 시스템 및 통신 프로토콜에서 자주 사용됩니다. 이에 대한 예로는 고성능 컴퓨팅의 MPI(Message Passing Interface)와 TCP/IP와 같은 네트워크 프로토콜이 있습니다. 양방향 메시지를 사용하면 일방적이거나 일방적인 커뮤니케이션보다 유연하고 역동적인 커뮤니케이션 패턴이 가능합니다. 발신자가 수신자에게 정보나 서비스를 요청하고 특정 응답을 받는 요청-응답 상호 작용을 허용합니다.
C. RPC 인터페이스 및 메타데이터
작은 데이터만 포함된 호출을 전송하면 III-B에 정의된 예기치 않은/예상된 메시징을 사용합니다. 그러나 더 높은 수준에서 서버에 함수 호출을 보내는 것은 구체적으로 클라이언트가 정보 전송을 시작하기 전에 입력 매개 변수를 인코딩하는 방법을 알아야 하고 서버로부터 응답을 받은 후 출력 매개 변수를 디코딩하는 방법을 알아야 한다는 것을 의미합니다. 서버 측에서 서버는 RPC 요청을 수신할 때 실행할 내용과 입력 및 출력 매개변수를 디코딩하고 인코딩하는 방법에 대한 지식도 가지고 있어야 합니다. 함수 호출 및 인코딩/디코딩 매개변수를 설명하는 프레임워크는 인터페이스 작동의 핵심입니다.
소량의 데이터만 포함된 통화 전송은 III-B에 정의된 대로 예상치 못한/예상된 메시징을 사용합니다. 그러나 높은 수준에서 서버에 함수 호출을 보내는 것은 특히 클라이언트가 정보 전송을 시작하기 전에 입력 매개변수를 인코딩하는 방법과 서버의 응답을 받은 후 출력 매개변수를 디코딩하는 방법을 알아야 한다는 것을 의미합니다. 서버 측에서 서버는 RPC 요청을 수신할 때 수행할 작업과 입력 및 출력 매개변수를 디코딩하고 인코딩하는 방법도 알고 있어야 합니다. 함수 호출 및 인코딩/디코딩 인수를 설명하는 프레임워크는 인터페이스 작동의 핵심입니다.
중요한 점 중 하나는 하드 코딩된 루틴 세트의 제한을 피하면서 일반적인 방식으로 서버에 보낼 수 있는 함수 호출 세트를 지원하는 기능입니다. 일반 프레임워크는 그림 2에 설명되어 있습니다. 초기화 단계에서 클라이언트와 서버는 클라이언트와 서버가 공유하는 각 작업의 고유 ID에 매핑되는 고유한 함수 이름을 사용하여 인코딩 및 디코딩 함수를 등록합니다. 서버는 또한 함수 호출로 오퍼레이션 ID를 받았을 때 실행해야 하는 콜백을 등록합니다. 대량 데이터 전송을 포함하지 않는 함수 호출을 보내기 위해 클라이언트는 해당 작업 ID와 함께 입력 매개 변수를 버퍼로 인코딩하고 비차단인 예기치 않은 메시징 프로토콜을 사용하여 서버로 보냅니다. 완전한 비동기성을 보장하기 위해, 서버에서 응답을 다시 수신하는 데 사용되는 메모리 버퍼도 클라이언트에서 미리 게시합니다. 효율성과 자원 소비의 이유로 이러한 메시지는 크기가 제한됩니다(일반적으로 몇 킬로바이트). 그러나 메타데이터가 예상치 못한 메시지의 크기를 초과하는 경우 클라이언트는 메타데이터를 별도의 메시지로 전송해야 합니다. 추가 메타데이터를 서버에 노출하기 위해 III-D에 설명된 대량 데이터 인터페이스.
주요 포인트 중 하나는 하드 코딩된 루틴 집합의 제한을 피하면서 일반적인 방식으로 서버에 보낼 수 있는 함수 호출 집합을 지원하는 기능입니다. 일반적인 프레임워크는 그림 2에 나와 있습니다. 초기화 단계에서 클라이언트와 서버는 각 작업의 고유 ID에 매핑되는 고유한 함수 이름을 사용하여 클라이언트와 서버가 공유하는 인코딩 및 디코딩 함수를 등록합니다. 또한 서버는 함수 호출을 통해 오퍼레이션 ID를 받았을 때 실행해야 하는 콜백을 등록합니다. 대량 데이터 전송을 포함하지 않는 함수 호출을 보내기 위해 클라이언트는 작업 ID와 함께 입력 매개 변수를 버퍼에 인코딩하고 비차단 예기치 않은 메시징 프로토콜을 사용하여 서버로 보냅니다. 완전한 비동기성을 보장하기 위해 서버에서 응답을 수신하는 데 사용되는 메모리 버퍼도 클라이언트에서 미리 릴리스합니다. 이러한 메시지는 효율성과 리소스 소비 때문에 크기가 제한됩니다(일반적으로 몇 킬로바이트). 그러나 메타데이터가 예상치 못한 메시지 크기를 초과하는 경우 클라이언트는 추가 메타데이터를 서버에 노출하기 위해 대량 데이터 III-D에 설명된 인터페이스를 투명하게 사용하여 별도의 메시지로 메타데이터를 전송해야 합니다.
그림 2: RPC 호출의 비동기 실행 흐름. 수신 버퍼가 미리 게시되어 호출이 원격으로 실행되고 응답이 전송되는 동안 클라이언트가 다른 작업을 수행할 수 있습니다.
서버가 새 요청 ID를 수신하면 해당 콜백을 조회하고, 입력 매개변수를 디코딩하고, 함수 호출을 실행하고, 출력 매개변수를 인코딩하고 응답을 다시 클라이언트로 보내기 시작합니다. 클라이언트에 응답을 다시 보내는 것도 비차단이므로 새 함수 호출을 받는 동안 서버는 응답 요청 목록을 테스트하여 완료를 확인하고 작업이 완료되면 해당 리소스를 해제할 수 있습니다. 클라이언트가 응답을 수신(대기/테스트 호출 사용)하여 함수 호출이 원격으로 완료되었음을 알게 되면 출력 매개변수를 디코딩하고 전송에 사용된 리소스를 해제할 수 있습니다.
서버가 새 요청 ID를 수신하면 해당 콜백을 조회하고, 입력 매개변수를 디코딩하고, 함수 호출을 실행하고, 출력 매개변수를 인코딩하고, 응답을 다시 클라이언트로 보내기 시작합니다. 클라이언트로 응답을 다시 보내는 것도 비차단이므로 새 함수 호출을 수신할 때 서버는 응답 요청 목록을 테스트하여 완료를 확인하고 작업이 완료되면 해당 리소스를 해제할 수 있습니다. 클라이언트가 응답을 수신(대기/테스트 호출 사용)하여 함수 호출이 원격으로 완료되었음을 알게 되면 출력 매개변수를 디코딩하고 전송에 사용된 리소스를 해제할 수 있습니다.
이 메커니즘을 사용하면 대량 데이터를 처리하도록 확장하기가 간단해집니다.
이 메커니즘을 사용하면 배치 데이터를 처리하도록 확장하는 것이 간단해집니다.
D. 대량 데이터 인터페이스
이전 인터페이스 외에도 일부 함수 호출에는 더 많은 양의 데이터 전송이 필요할 수 있습니다. 이러한 함수 호출의 경우 대량 데이터 인터페이스가 사용되며 네트워크 추상화 계층에 정의된 원격 메모리 액세스 프로토콜 위에 구축됩니다. RPC 서버만 일방적 전송을 시작하여 데이터 흐름을 제어할 뿐만 아니라 동시 액세스로부터 메모리를 보호할 수 있습니다.
이전 인터페이스 외에도 일부 함수 호출은 더 많은 양의 데이터를 전송해야 할 수 있습니다. 이러한 함수 호출의 경우 네트워크 추상화 계층에 정의된 원격 메모리 액세스 프로토콜 위에 구축된 대량 데이터 인터페이스가 사용됩니다. RPC 서버만 데이터 흐름을 제어하고 동시 액세스로부터 메모리를 보호할 수 있도록 일방적 전송을 시작합니다.
그림 3에서 설명한 것처럼 대량 데이터 전송 인터페이스는 일방적 통신 방식을 사용합니다. RPC 클라이언트는 대량 데이터 설명자(가상 메모리 주소 정보, 노출되는 메모리 영역의 크기 및 기본 네트워크 구현에 따라 달라질 수 있는 기타 매개 변수 포함)를 생성하여 RPC 서버에 메모리 영역을 노출합니다. 그런 다음 대량 데이터 디스크립터를 직렬화하여 RPC 요청 매개변수와 함께 RPC 서버로 보낼 수 있습니다(III-C 섹션에 정의된 RPC 인터페이스 사용). 서버가 입력 매개변수를 디코딩할 때 대량 데이터 디스크립터를 역직렬화하고 전송해야 하는 메모리 버퍼의 크기를 가져옵니다.
그림 3과 같이 대량 데이터 전송 인터페이스는 단방향 통신 방식을 사용합니다. RPC 클라이언트는 가상 메모리 주소 정보, 노출되는 메모리 영역의 크기 및 기본 네트워크 구현에 따라 달라질 수 있는 기타 매개 변수를 포함하는 대량 데이터 설명자를 만들어 RPC 서버에 메모리 영역을 노출합니다. 대량 데이터 디스크립터는 직렬화되어 RPC 요청 매개변수와 함께 RPC 서버(섹션 III-C에 정의된 RPC 인터페이스 사용)로 전송될 수 있습니다. 서버가 입력 매개변수를 디코딩할 때 대량 데이터 디스크립터를 역직렬화하고 전송해야 하는 메모리 버퍼의 크기를 가져옵니다.
대용량 데이터 매개변수를 소비하는 RPC 요청의 경우 RPC 서버는 수신해야 하는 데이터 크기의 버퍼를 할당하고 대량 데이터 블록 디스크립터를 생성하여 로컬 메모리 영역을 노출하고 비동기 읽기/ 해당 메모리 영역에서 작업을 가져옵니다. 그런 다음 RPC 서버는 작업 완료를 기다리거나 테스트하고 데이터가 완전히 수신되면(또는 실행 호출이 지원하는 경우 부분적으로) 호출을 실행합니다. 그러면 응답(즉, 호출 결과)이 RPC 클라이언트로 다시 전송되고 메모리 핸들이 해제됩니다.
RPC 요청이 많은 수의 데이터 매개변수를 사용하는 경우 RPC 서버는 수신해야 하는 데이터 크기의 버퍼를 할당하고 대량 데이터 블록 설명자를 생성하여 로컬 메모리 영역을 노출하고 비동기 읽기/ 해당 메모리 영역에서 작동합니다. 그런 다음 RPC 서버는 작업이 완료될 때까지 대기/테스트하고 데이터가 완전히 수신된 후(또는 실행 중인 호출이 지원하는 경우 부분적으로 수신된 후) 호출을 실행합니다. 그러면 응답(즉, 호출 결과)이 RPC 클라이언트로 다시 전송되고 메모리 핸들이 해제됩니다.
대용량 데이터 매개변수를 생성하는 RPC 요청의 경우 RPC 서버는 생성할 데이터 크기의 버퍼를 할당하고 대량 데이터 블록 설명자를 생성하여 메모리 영역을 노출하고 호출을 실행한 다음 노출된 클라이언트 메모리 영역에 대한 비동기 쓰기/넣기 작업을 시작합니다. 그런 다음 RPC 서버는 작업이 완료될 때까지 대기/테스트하고 응답(즉, 호출 결과)을 RPC 클라이언트로 다시 보낼 수 있습니다. 그런 다음 메모리 핸들을 해제할 수 있습니다.
큰 데이터 매개변수를 생성하는 RPC 요청의 경우 RPC 서버는 생성할 데이터와 동일한 크기의 버퍼를 할당하고 대량 데이터 블록 디스크립터를 생성하여 메모리 영역을 노출하고 호출을 실행한 다음 이미 노출된 클라이언트 끝 메모리 영역에서 비동기 쓰기/넣기 작업을 시작합니다. 그런 다음 RPC 서버는 작업 완료를 기다리거나 테스트하고 RPC 클라이언트에 응답(즉, 호출 결과)을 다시 보낼 수 있습니다. 그런 다음 메모리 핸들을 해제할 수 있습니다.
이 프로세스를 통한 데이터 전송은 특히 RPC 인터페이스가 다른 매개변수와 함께 메모리 핸들의 직렬화/역직렬화를 처리할 수 있기 때문에 사용자에게 투명할 수 있습니다. 이는 비연속 메모리 세그먼트를 전송해야 할 때 특히 중요합니다. 두 경우 모두 메모리 세그먼트는 RPC 클라이언트에 자동으로 등록되고 생성된 메모리 핸들에 의해 추상화됩니다. 그런 다음 메모리 핸들은 RPC 함수의 매개 변수와 함께 직렬화되고 비연속 메모리 영역을 사용하여 큰 데이터를 전송하므로 위에서 설명한 것과 동일한 프로세스가 발생합니다. 이 경우 핸들은 더 많은 정보를 포함할 수 있고 메모리 세그먼트 등록을 직접 지원할 수 있는 기본 네트워크 구현에 따라 크기가 가변적일 수 있습니다.
이 프로세스를 통한 데이터 전송은 특히 RPC 인터페이스가 메모리 핸들 및 기타 매개변수의 직렬화/역직렬화도 처리할 수 있기 때문에 사용자에게 투명합니다. 이는 비연속 메모리 세그먼트를 전송해야 할 때 특히 중요합니다. 두 경우 모두 메모리 세그먼트는 자동으로 RPC 클라이언트에 등록되고 생성된 메모리 핸들에 의해 추상화됩니다. 그런 다음 메모리 핸들은 RPC 함수의 매개 변수와 함께 직렬화되므로 비연속 메모리 영역을 사용하여 대용량 데이터를 전송하면 위와 동일한 프로세스가 발생합니다. 이 경우 핸들은 더 많은 정보를 포함할 수 있고 메모리 세그먼트 등록을 직접 지원할 수 있는 기본 네트워크 구현에 따라 크기가 가변적일 수 있습니다.
IV. 평가
이전에 정의된 아키텍처를 사용하면 대량 데이터 전송이 필요할 때 연속 및 비연속 메모리 영역을 설명할 수 있는 핸들과 함께 일반 RPC 호출을 전달할 수 있습니다. 이 섹션에서는 이 아키텍처를 활용하여 온디맨드 데이터 블록을 쉽게 요청할 수 있는 파이프라이닝 메커니즘을 구축하는 방법을 제시합니다.
이전에 정의된 아키텍처를 사용하면 대량 데이터 전송이 필요할 때 연속 및 비연속 메모리 영역을 설명할 수 있는 핸들과 함께 일반 RPC 호출을 실행할 수 있습니다. 이 섹션에서는 이 아키텍처를 활용하여 온디맨드 데이터 청크를 쉽게 요청할 수 있는 파이프라인 메커니즘을 구축하는 방법을 설명합니다.
A. 대량 데이터 전송 파이프라이닝
파이프라이닝 전송은 통신과 실행을 중첩하려는 일반적인 사용 사례입니다. 우리가 설명한 아키텍처에서 대량의 데이터를 처리하도록 요청하면 대량 데이터 전송뿐만 아니라 RPC 클라이언트에서 RPC 서버로 RPC 요청이 전송됩니다. 일반적인 사용 사례에서 서버는 요청된 호출을 실행하기 전에 전체 데이터가 수신될 때까지 기다릴 수 있습니다. 그러나 전송을 파이프라이닝하면 실제로 전송되는 동안 데이터 처리를 시작할 수 있으므로 전체 RMA 전송에 대한 대기 시간 비용을 지불하지 않아도 됩니다. 아래 예에서 이 점에 중점을 두고 있지만 RPC 서버에 전송해야 하는 모든 데이터를 처리할 메모리가 충분하지 않은 경우에도 이 기술을 사용하는 것이 특히 유용할 수 있습니다.
파이프라이닝은 통신과 실행을 중첩하려는 일반적인 사용 사례입니다. 우리가 설명하는 아키텍처에서 대량의 데이터를 처리하라는 요청은 RPC 클라이언트에서 RPC 서버로의 RPC 요청과 대량의 데이터 전송을 초래합니다. 일반적인 사용 사례에서 서버는 요청된 호출을 실행하기 전에 모든 데이터가 수신될 때까지 기다릴 수 있습니다. 그러나 파이프라이닝을 사용하면 전체 RMA 전송에 대한 대기 시간 비용을 지불하지 않고 전송되는 데이터 처리를 실제로 시작할 수 있습니다. 아래 예에서 이에 중점을 두지만 RPC 서버에 전송해야 하는 모든 데이터를 처리할 메모리가 충분하지 않은 경우에도 이 기술을 사용하는 것이 특히 유용합니다. 처리하는 동안 데이터.
RPC 클라이언트 코드의 단순화된 버전은 다음과 같습니다.
RPC 클라이언트 코드의 단순화된 버전은 다음과 같습니다.
#define BULK_NX 16
#define BULK_NY 128
int main(int argc, char *argv[])
{
hg_id_t rpc_id;
write_in_t in_struct;
write_out_t out_struct;
hg_request_t rpc_request;
int buf[BULK_NX][BULK_NY];
hg_bulk_segment_t segments[BULK_NX];
hg_bulk_t bulk_handle = HG_BULK_NULL;
/* Initialize the interface */
[...]
/* Register RPC call */
rpc_id = HG_REGISTER("write",write_in_t, write_out_t);
/* Provide data layout information */
for (i = 0; i < BULK_NX ; i++) {
segments[i].address = buf[i];
segments[i].size = BULK_NY * sizeof(int);
}
/* Create bulk handle with segment info */
HG_Bulk_handle_create_segments(segments,BULK_NX, HG_BULK_READ_ONLY, &bulk_handle);
/* Attach bulk handle to input parameters */
[...]
in_struct.bulk_handle = bulk_handle;
/* Send RPC request */
HG_Forward(server_addr, rpc_id,&in_struct, &out_struct, &rpc_request);
/* Wait for RPC completion and response */
HG_Wait(rpc_request, HG_MAX_IDLE_TIME,HG_STATUS_IGNORE);
/* Get output parameters */
[...]
ret = out_struct.ret;
/* Free bulk handle */
HG_Bulk_handle_free(bulk_handle);
/* Finalize the interface */
[...]
}
클라이언트는 초기화할 때 보내려는 RPC 호출을 등록합니다. 이 호출에는 비연속 대량 데이터 전송이 포함되기 때문에 메모리 영역을 설명하는 메모리 세그먼트가 생성되고 등록됩니다. 그러면 결과 bulk_handle이 다른 호출 매개변수와 함께 HG_Forward 호출로 전달됩니다. 그런 다음 응답을 기다리고 요청이 완료되면 대량 핸들을 해제할 수 있습니다(대량 핸들을 더 일찍 해제하여 메모리를 고정 해제할 수 있도록 나중에 알림을 보낼 수도 있음).
클라이언트는 초기화할 때 보내려는 RPC 호출을 등록합니다. 이 호출에는 비순차적 대량 데이터 전송이 포함되므로 메모리 영역을 설명하는 메모리 세그먼트가 생성되고 등록됩니다. 그러면 결과 bulk_handle이 다른 호출 매개변수와 함께 HG_Forward 호출로 전달됩니다. 그런 다음 응답을 기다리고 요청이 완료되면 대량 핸들을 해제할 수 있습니다(또한 대량 핸들이 더 일찍 해제되어 메모리 바인딩이 해제되도록 나중에 알림을 보낼 수도 있음).
파이프라이닝 메커니즘은 대량 전송을 처리하는 서버에서 발생합니다. 파이프라인 자체에는 고정된 파이프라인 크기와 파이프라인 버퍼 크기가 있습니다. RPC 서버 코드의 단순화된 버전은 다음과 같습니다.
파이프라이닝 메커니즘은 대량 전송을 담당하는 서버에서 발생합니다. 여기서 파이프 자체에는 고정된 파이프 크기와 파이프 버퍼 크기가 있습니다. RPC 서버 코드의 단순화된 버전은 다음과 같습니다.
#define PIPELINE_BUFFER_SIZE 256
#define PIPELINE_SIZE 4
int rpc_write(hg_handle_t handle)
{
write_in_t in_struct;
write_out_t out_struct;
hg_bulk_t bulk_handle;
hg_bulk_block_t bulk_block_handle;
hg_bulk_request_t bulk_request[PIPELINE_SIZE];
void *buf;
size_t nbytes, nbytes_read = 0;
size_t start_offset = 0;
/* Get input parameters and bulk handle */
HG_Handler_get_input(handle, &in_struct);
[...]
bulk_handle = in_struct.bulk_handle;
/* Get size of data and allocate buffer */
nbytes = HG_Bulk_handle_get_size(bulk_handle);
buf = malloc(nbytes);
/* Create block handle to read data */
HG_Bulk_block_handle_create(buf, nbytes,
HG_BULK_READWRITE, &bulk_block_handle);
/* Initialize pipeline and start reads */
for (p = 0; p < PIPELINE_SIZE; p++) {
size_t offset = p * PIPELINE_BUFFER_SIZE;
/* Start read of data chunk */
HG_Bulk_read(client_addr, bulk_handle,
offset, bulk_block_handle, offset,
PIPELINE_BUFFER_SIZE, &bulk_request[p]);
}
while (nbytes_read != nbytes) {
for (p = 0; p < PIPELINE_SIZE; p++) {
size_t offset = start_offset + p * PIPELINE_BUFFER_SIZE;
/* Wait for data chunk */
HG_Bulk_wait(bulk_request[p],
HG_MAX_IDLE_TIME, HG_STATUS_IGNORE);
nbytes_read += PIPELINE_BUFFER_SIZE;
/* Do work (write data chunk) */
write(buf + offset, PIPELINE_BUFFER_SIZE);
/* Start another read */
offset += PIPELINE_BUFFER_SIZE * 51 PIPELINE_SIZE;
if (offset < nbytes) {
HG_Bulk_read(client_addr,bulk_handle, offset,bulk_block_handle, offset,PIPELINE_BUFFER_SIZE,&bulk_request[p]);
} else {
/* Start read with remaining piece */
}
}
start_offset += PIPELINE_BUFFER_SIZE * PIPELINE_SIZE;
}
/* Free block handle */
HG_Bulk_block_handle_free(bulk_block_handle);
free(buf);
/* Start sending response back */
[...]
out_struct.ret = ret;
HG_Handler_start_output(handle, &out_struct);
}
int main(int argc, char *argv[])
{
/* Initialize the interface */
[...]
/* Register RPC call */
HG_HANDLER_REGISTER("write", rpc_write,write_in_t, write_out_t);
while (!finalized) {
/* Process RPC requests (non-blocking) */
HG_Handler_process(0, HG_STATUS_IGNORE);
}
/* Finalize the interface */
[...]
}
모든 RPC 서버는 일단 초기화되면 새 RPC 요청을 기다리고 등록된 해당 콜백을 실행하는 HG_Handler_process 호출을 반복해야 합니다(사용자 요구에 따라 동일한 스레드 또는 새 스레드에서). 요청이 역직렬화되면 bulk_handle 매개변수를 사용하여 전송할 데이터의 총 크기를 가져오고 적절한 크기의 버퍼를 할당하고 대량 데이터 전송을 시작할 수 있습니다. 이 예에서 파이프라인 크기는 4로 설정되고 파이프라인 버퍼 크기는 256으로 설정됩니다. 즉, 256바이트의 RMA 요청 4개가 시작됩니다. 그런 다음 256바이트의 첫 번째 조각이 도착하여 처리할 때까지 기다릴 수 있습니다. 처리되는 동안 다른 조각이 도착할 수 있습니다. 한 조각이 처리되면 파이프라인의 4단계에 있는 조각에 대해 새로운 RMA 전송이 시작되고 다음 조각을 기다릴 수 있습니다. 클라이언트에 등록된 메모리 영역은 비연속적이지만 서버의 HG_Bulk_read 호출은 이를 연속 영역으로 표시하여 서버 코드를 단순화합니다. 또한 데이터 조각을 개별적으로 이동하기 위해 논리적 오프셋(데이터 시작 부분에 상대적)을 제공할 수 있으며, 대량 데이터 인터페이스는 연속적인 논리적 오프셋에서 비연속적 클라이언트 메모리 영역으로의 매핑을 처리합니다.
각 RPC 서버는 일단 초기화되면 새 RPC 요청을 기다리고 등록된 해당 콜백을 실행하는 HG_Handler_process 호출을 반복해야 합니다(사용자 요구에 따라 동일한 스레드 또는 새 스레드에서). 요청이 역직렬화되면 bulk_handle 매개변수를 사용하여 전송할 데이터의 총 크기를 가져오고 적절한 크기의 버퍼를 할당하고 대량 데이터 전송을 시작할 수 있습니다. 이 예에서 파이프라인 크기는 4로 설정되고 파이프라인 버퍼 크기는 256으로 설정됩니다. 즉, 256바이트의 RMA 요청 4개가 시작됩니다. 그런 다음 256바이트의 첫 번째 블록이 도착하여 처리할 때까지 기다릴 수 있습니다. 처리되는 동안 다른 조각이 도착할 수 있습니다. 프래그먼트가 처리되면 파이프라인의 4단계에서 프래그먼트에 대해 새로운 RMA 전송이 시작되고 다음 프래그먼트가 처리될 때까지 기다릴 수 있습니다. 클라이언트에 등록된 메모리 영역이 비연속적이지만 서버의 HG_Bulk_read 호출은 이를 연속적 영역으로 나타내어 서버 코드를 단순화합니다. 또한 데이터 청크를 개별적으로 이동하기 위해 논리적 오프셋(데이터 시작 부분에 상대적)을 제공할 수 있으며, 대량 데이터 인터페이스는 연속된 논리적 오프셋을 클라이언트 메모리의 비연속 영역에 매핑하는 작업을 처리합니다.
모든 데이터를 읽고 처리하고 응답(즉, 함수 호출의 결과)을 다시 보낼 수 있을 때까지 이 프로세스를 계속합니다. 다시 우리는 HG_Handler_start_output 호출을 호출하여 응답 전송을 시작하고 완료는 HG_Handler_process를 호출해야만 테스트할 수 있습니다. 이 경우 응답과 관련된 리소스가 해제됩니다. 모든 함수는 비동기 실행을 지원하므로 원하는 경우 Mercury를 이벤트 기반 코드에서 사용할 수 있습니다.
모든 데이터를 읽고 처리하고 응답(즉, 함수 호출의 결과)을 다시 보낼 수 있을 때까지 이 프로세스를 계속합니다. 마찬가지로 HG_Handler_start_output 호출을 호출해야만 응답 전송을 시작할 수 있고 HG_Handler_process를 호출해야만 완료를 테스트할 수 있습니다. 이 경우 응답과 관련된 리소스가 해제됩니다. 모든 함수는 비동기 실행을 지원하며 원하는 경우 Mercury를 이벤트 기반 코드에서 사용할 수 있습니다.
B. 네트워크 플러그인 및 테스트 환경
네트워크 추상화 계층의 기능을 설명하기 위해 이 백서가 작성된 날짜를 기준으로 두 개의 플러그인이 개발되었습니다. 이 시점에서 플러그인은 성능을 위해 최적화되지 않았습니다. 하나는 BMI 위에 구축됩니다[10]. 그러나 섹션 II에서 이미 지적했듯이 BMI는 정의된 네트워크 추상화 계층과 일방적 대량 데이터 전송 아키텍처를 효율적으로 활용하기 위한 RMA 의미 체계를 제공하지 않습니다. 다른 하나는 최근 MPI3[19]와 함께 전체 RMA 시맨틱[18]을 제공하고 있는 MPI[17] 위에 구축되었습니다. 많은 MPI 구현, 특히 이미 설치된 시스템과 함께 제공되는 구현은 아직 모든 MPI3 기능을 제공하지 않습니다. BMI는 아직 최신 HPC 시스템에 포팅되지 않았기 때문에 기능을 설명하고 초기 성능 결과를 측정하기 위해 이 백서에서는 MPI 플러그인만 고려합니다. 이 플러그인은 Cray 시스템과 같은 MPI-2 기능으로 제한된 기존 HPC 시스템에서 실행할 수 있도록 양방향 메시징 위에 대량 데이터 전송을 구현합니다.
실제로 이것은 각 대량 데이터 전송에 대해 추가 대량 데이터 제어 메시지를 클라이언트에 보내 데이터를 보내거나 받는 것을 요청해야 함을 의미합니다. 그런 다음 진행 스레드를 사용하거나 진행 함수를 입력하여 전송 진행을 실현할 수 있습니다.
작성 시점에 네트워크 추상화 계층의 기능을 설명하기 위해 두 개의 플러그인이 개발되었습니다. 이 시점에서 플러그인은 아직 성능에 대해 최적화되지 않았습니다. 하나는 BMI[10]를 기반으로 합니다. 그러나 섹션 II에서 이미 지적했듯이 BMI는 정의된 네트워크 추상화 계층과 일방적 대량 데이터 전송 아키텍처를 효율적으로 활용하기 위한 RMA 의미 체계를 제공하지 않습니다. 다른 하나는 최근 MPI3[19]를 통해 전체 RMA 시맨틱[18]을 제공하는 MPI[17] 위에 구축됩니다. 많은 MPI 구현, 특히 MPI가 설치된 시스템은 아직 모든 MPI3 기능을 제공하지 않습니다. BMI는 최근의 고성능 컴퓨팅 시스템에 포팅되지 않았기 때문에 이 기사에서는 기능을 설명하고 초기 성능 결과를 측정하기 위한 목적으로만 MPI 플러그인을 고려합니다. Cray 시스템과 같이 MPI-2 기능으로 제한된 기존 HPC 시스템에서 실행할 수 있는 이 플러그인은 양방향 메시지 전달을 기반으로 대량 데이터 전송을 가능하게 합니다.
실제로 이는 각 대량 데이터 전송에 대해 추가 대량 데이터 제어 메시지를 클라이언트에 보내 데이터를 보내거나 받을 것을 요청해야 함을 의미합니다. 그런 다음 진행 스레드를 사용하거나 진행 함수를 입력하여 전송 진행을 달성할 수 있습니다.
테스트를 위해 두 가지 다른 HPC 시스템을 사용합니다. 하나는 MVAPICH[20] 1.8.1이 포함된 Infiniband QDR 4X 클러스터이고 다른 하나는 Cray MPT[21] 5.6.0이 포함된 Cray XE6입니다.
테스트를 위해 두 개의 서로 다른 HPC 시스템을 사용했습니다. 하나는 MVAPICH[20] 1.8.1을 사용하는 Infiniband QDR 4X 클러스터이고 다른 하나는 Cray MPT[21] 5.6.0을 사용하는 Cray XE6 클러스터입니다.
다. 성과평가
첫 번째 실험으로 비어 있는 함수(즉, 즉시 반환되는 함수)에 대해 작은 RPC 호출(대량 데이터 전송 없이)을 실행하는 데 걸리는 시간을 측정했습니다. Cray XE6 시스템에서 20개의 RPC 호출에 대한 평균 시간을 측정하면 각 호출에 23µs가 소요됩니다. 이 시간에는 함수 매개변수의 XDR 인코딩 및 디코딩이 포함됩니다. 그러나 앞서 지적한 바와 같이 대부분의 HPC 시스템은 동종이므로 XDR에서 제공하는 데이터 이식성이 필요하지 않습니다. XDR 인코딩을 비활성화하면(단순 메모리 복사 수행) 시간이 20µs로 떨어집니다. 이 무시할 수 없는 개선(15%)은 특히 HPC 환경을 위한 RPC 프레임워크 설계의 이점을 보여줍니다.
첫 번째 실험으로 빈 함수(즉, 즉시 반환되는 함수)에 대한 작은 RPC 호출(대량 데이터 전송을 포함하지 않음)을 실행하는 데 걸리는 시간을 측정했습니다. Cray XE6 시스템에서 평균 시간은 각각 23µs가 소요되는 20개의 RPC 호출에 대해 측정되었습니다. 이번에는 함수 매개변수의 XDR 인코딩 및 디코딩이 포함됩니다. 그러나 이전에 지적한 바와 같이 대부분의 HPC 시스템은 동종이므로 XDR에서 제공하는 데이터 이식성이 필요하지 않습니다. XDR 인코딩이 비활성화되면(단순 메모리 복사가 대신 수행됨) 시간이 20µs로 떨어집니다. 이 무시할 수 없는 개선(15%)은 특히 HPC 환경을 위한 RPC 프레임워크 설계의 이점을 보여줍니다.
두 번째 실험은 이전에 한 클라이언트와 한 서버 간에 설명한 대량 데이터 전송을 위한 파이프라이닝 기술을 테스트하는 것으로 구성됩니다. 표 I에서 볼 수 있듯이 Cray XE6에서 파이프라이닝 전송은 다른 파이프라인 단계가 처리되는 동안 요청이 이미 완료된 경우 특히 효율적일 수 있으므로 매우 높은 대역폭을 얻을 수 있습니다. 그러나 이 시스템의 높은 주입 대역폭은 특히 데이터 흐름이 연속적이지 않을 때 작은 패킷(예: 이 시스템의 일면 기능 에뮬레이션으로 인한 대량 데이터 제어 메시지)에 대해 좋은 성능을 얻기 어렵게 만듭니다.
두 번째 실험은 이전에 클라이언트와 서버 간의 대량 데이터 전송에 대해 설명한 파이프라이닝 기술을 테스트하는 것으로 구성되었습니다. 표 1에서 볼 수 있듯이 Cray XE6에서 파이프라이닝은 다른 파이프라인 단계가 처리되는 동안 요청이 이미 완료되었을 때 특히 효율적일 수 있으므로 매우 높은 대역폭을 달성할 수 있습니다. 그러나 이 시스템의 높은 주입 대역폭은 특히 데이터 흐름이 연속적이지 않은 경우 작은 데이터 패킷(예: 이 시스템의 일방적 기능 시뮬레이션으로 인한 대량 데이터 제어 메시지)에 대해 우수한 성능을 달성하기 어렵게 만듭니다.
마지막으로 클라이언트 수를 늘리면서 전체 데이터 처리량을 평가하여 RPC 서버의 확장성을 평가했습니다. 그림 4와 5는 각각 QDR InfiniBand 시스템(MVAPICH 사용)과 Cray XE6 시스템의 결과를 보여줍니다. 두 경우 모두 부분적으로 서버 측 대량 데이터 흐름 제어 메커니즘으로 인해 Mercury는 동시 클라이언트 수가 증가함에 따라 처리량이 증가하거나 안정적으로 유지되는 탁월한 확장성을 보여줍니다. 비교를 위해 각 시스템의 지점간 메시지 대역폭이 표시됩니다. InfiniBand 시스템에서 Mercury는 최대 네트워크 대역폭의 약 70%를 달성합니다. OSU 벤치마크에서 단일 메시지를 보내는 데 걸리는 시간과 비교할 때 Mercury 시간이 데이터 전송 외에 RPC 호출을 나타낸다는 점을 고려하면 이는 탁월한 결과입니다. 크레이 시스템에서는 성능이 좋지 않습니다(최고점의 약 40%). 이는 주로 시스템의 작은 메시지 성능이 상대적으로 낮고 일방적 에뮬레이션으로 인한 추가 제어 메시지가 결합되었기 때문인 것으로 예상됩니다.
마지막으로 RPC Serverby의 확장성을 평가하여 클라이언트 시간을 늘릴 때 총 데이터 처리량을 평가합니다. 그림 4와 5는 각각 AQDR Infiniband 시스템(MVAPICH 사용)과 CRAY XE6SYSTEM의 결과를 보여줍니다. 두 경우 모두 부분적으로 서버 사이드벌크 데이터 흐름 제어 메커니즘으로 인해 HG는 동시 클라이언트 수가 증가함에 따라 처리량이 증가하거나 안정적으로 유지되는 우수한 성능을 보여줍니다. 비교를 위해 각 시스템의 포인트 메시지 대역폭이 표시됩니다. Infiniband 시스템에서 Mercury는 최대 네트워크 대역폭의 70%에 도달했습니다. HG 시간이 데이터 전송을 위한 RPC 호출을 나타내는 것을 고려하면 OSU 벤치마크의 Asingle 메시지를 보내는 시간과 비교하면 좋은 결과입니다. Cray 시스템에서 성능이 좋지 않습니다(최고점의 약 40%). 우리는 이것이 주로 이 시스템의 작은 정보 성능과 일방적 시뮬레이션에 의해 유도된 추가 제어 조치 때문일 것으로 예상합니다. 그러나 Nessie의 유사한 연산(읽기)[22]의 성능이 MPI를 우회하고 실제의 네이티브 uGNI API를 사용하여 달성했음에도 불구하고 동일한 낮은 대역폭을 나타내는 것을 고려할 때 낮은 성능은 시스템 제한에 의한 것일 수도 있습니다. RDMA 상호 연결 .
V. 결론 및 향후 과제
이 백서에서 우리는 Mercury 프레임워크를 제시했습니다. Mercury는 고성능 컴퓨팅 환경에서 RPC 서비스를 제공하도록 특별히 설계되었습니다. Mercury는 현대 HPC 네트워크 환경의 기능과 거의 일치하는 작업을 제공하는 작고 쉽게 이식할 수 있는 네트워크 추상화 계층을 기반으로 합니다. 대부분의 다른 RPC 프레임워크와 달리 Mercury는 큰 데이터 인수가 포함된 원격 호출을 처리하기 위한 직접적인 지원을 제공합니다. Mercury의 네트워크 프로토콜은 수천 개의 클라이언트로 확장되도록 설계되었습니다. 큰 데이터 인수의 파이프라이닝을 포함하여 원격 쓰기 기능을 구현하여 프레임워크의 성능을 입증했습니다. 이후 두 개의 다른 HPC 시스템에서 구현을 평가하여 단일 클라이언트 성능과 다중 클라이언트 확장성을 모두 보여주었습니다.
이 기사에서는 Mercury 프레임워크를 소개했습니다. Mercury는 고성능 컴퓨팅 환경에서 RPC 서비스를 제공하도록 특별히 설계되었습니다. Mercury는 작고 휴대하기 쉬운 네트워크 추상화 계층에 구축되어 최신 HPC 네트워크 환경의 기능과 거의 일치하는 작업을 제공합니다. 대부분의 다른 RPC 프레임워크와 달리 Mercury는 큰 데이터 매개변수가 포함된 원격 호출을 처리하기 위한 직접적인 지원을 제공합니다. Mercury의 네트워크 프로토콜은 수천 개의 클라이언트로 확장되도록 설계되었습니다. 대용량 데이터 매개변수에 대한 파이프라인을 포함하는 원격 쓰기 기능을 구현하여 이 프레임워크의 성능을 보여줍니다. 이후 두 개의 서로 다른 HPC 시스템에서 구현을 평가하여 단일 클라이언트 성능과 다중 클라이언트 확장성을 입증합니다.
Mercury에서 제공하는 고성능의 이식 가능한 일반 RPC 기능을 사용할 수 있으므로 내부의 하드 코딩된 IOPSL 코드를 Mercury 호출로 교체하여 IOPSL을 단순화하고 현대화할 수 있습니다. Mercury가 구축된 네트워크 추상화 계층은 이미 네트워크 연결을 위한 BMI 사용을 지원하므로, Mercury 네트워크 프로토콜의 향상된 확장성 및 성능을 활용하는 동시에 기존 IOFSL 배포가 계속 지원됩니다.
Mercury에서 제공하는 고성능의 휴대 가능한 범용 RPC 기능을 사용하면 내부 하드 코딩된 IOPSL 코드를 Mercury 호출로 교체하여 IOPSL을 간소화하고 현대화할 수 있습니다. Mercury가 구축된 네트워크 추상화 계층은 이미 네트워킹을 위한 BMI 사용을 지원하므로 Mercury 네트워킹 프로토콜의 향상된 확장성과 성능을 활용하면서 기존 IOPSL 배포가 계속 지원됩니다.
현재 Mercury는 진행 중인 RPC 호출 취소에 대한 지원을 제공하지 않습니다. 취소는 노드나 네트워크가 실패할 수 있는 환경에서 복원력을 위해 중요합니다. 향후 작업에는 취소 지원이 포함될 예정입니다.
현재 Mercury는 진행 중인 RPC 호출 취소를 지원하지 않습니다. 취소는 노드 또는 네트워크 오류가 발생할 수 있는 환경에서 복원력을 위해 중요합니다. 향후 작업에는 취소 지원이 포함될 예정입니다.
Mercury는 RPC 호출을 효율적으로 실행하는 데 필요한 모든 기능을 이미 지원하고 있지만 각 호출에 필요한 사용자 코드의 양을 더 줄일 수 있습니다. 향후 버전의 Mercury는 일련의 전처리기 매크로를 제공하여 가능한 한 많은 상용구 코드를 자동으로 생성하여 사용자의 노력을 줄여줄 것입니다.
Mercury는 이미 RPC 호출을 효율적으로 실행하는 데 필요한 모든 기능을 지원하지만 각 호출에 필요한 사용자 코드의 양을 더 줄일 수 있습니다. Mercury의 향후 버전은 가능한 한 많은 상용구 코드를 자동으로 생성하여 사용자의 작업 부하를 줄이는 일련의 전처리기 매크로를 제공할 것입니다.
네트워크 추상화 계층에는 현재 BMI, MPI-2 및 MPI-3용 플러그인이 있습니다. 그러나 MPI RMA 기능은 클라이언트/서버 컨텍스트[23]에서 사용하기 어려우므로 Infiniband 네트워크, Cray XT, IBM BG/P 및 Q 네트워크에 대한 기본 지원을 추가할 예정입니다.
네트워크 추상화 계층에는 현재 BMI, MPI-2 및 MPI-3용 플러그인이 있습니다. 그러나 MPI RMA 기능은 클라이언트/서버 환경[23]에서 사용하기 어렵기 때문에 Infiniband 네트워크, Cray XT 및 IBM BG/P 및 Q 네트워크에 대한 기본 지원을 추가할 예정입니다.