Current Issue

NRD는 로컬 호스트의 파일 시스템을 통해 원격 시스템의 RAM 영역에 접근하는 것으로, 크기에 제약이 있어 디스크 등 보조기억장치 설치에 한계가 있는 임베디드 시스템이 원격 호스트의 RAM 영역 중 일부를 파일 시스템을 이용하여 접근할 수 있도록 한다[7]. NRD는 리눅스 커널에 적재되는 장치 구동기 모듈과 통신을 수행하는 사용자 수준의 클라이언트와 서버 데몬으로 구성되어 있다. 로컬 호스트의 사용자 프로그램이 파일 입출력을 위한 시스템 콜을 호출하면, NRD 커널 모듈은 이 호출에 대응하여 관련 요청을 NRD 클라이언트 데몬에 전달한다. NRD 클라이언트는 소켓 통신을 통해 원격 호스트의 NRD 서버 데몬에게 관련 요청을 전달하며, NRD 서버 데몬은 이 요청을 처리하고 반응한다.

NRD는 원격 호스트의 RAM 영역을 호스트의 보조기억장치로 사용하므로 전원 공급의 문제 또는 재시작 등 원격 호스트에 문제가 있는 경우 파일 시스템의 내용이 모두 소실되는 문제가 있다.

휘발성 메모리를 이용한 저장 매체 구현 연구는 호스트 시스템의 RAM 영역 일부를 이용하여 리눅스 블록 장치 구동기를 구현하고, 성능 시험을 통해 메모리 기반의 저장 매체가 작업 부하의 양과 관련 없이 성능 차이가 거의 없음을 보여 주었다[1]. 반면, 이 결과는 HDD와 SSD가 작업 부하의 양에 따라 각각 최대 30배, 15배의 성능 차이가 남을 보였다. 즉, RAM과 같은 휘발성 메모리를 이용하여 이 연구에서 구현한 저장 매체는 작업 부하의 양에 상관없이 거의 일관된 성능을 보였다. 또, 이 연구에서 구현한 저장 매체는 리눅스 시스템의 부팅 중 시스템 메모리를 할당함으로써 저장 매체를 위한 메모리 주소 공간을 고정하여 할당함으로써 성능을 높이고 있다.

이 시스템도 앞서 기술한 것과 같이 전원 공급 장치 고장 등 다양한 원인으로 시스템을 재시작하면 휘발성 메모리의 내용이 모두 소실되는 문제를 갖고 있다.

미션 크리티컬한 작업을 실시간으로 처리해야 하는 IoT 장치들은 RAM을 스토리지로 사용하고 있다[3][4]. 다양한 환경에서 동작하는 IoT 장치가 안정적이고 영속적인 동작이 가능하지 않을 수 있어 IoT 장치에 구현된 RAM 디스크는 데이터 소실의 가능성을 항상 갖고 있다. 이를 해결하기 위한 하이브리드 RAM 디스크[3]는 IoT 장치를 위한 것으로 RAM 디스크의 내용을 SSD를 이용하여 백업하는 방법을 제공하고 있다.

하이브리드 RAM 디스크는 RAM의 내용을 SSD에 동시 저장하므로 메모리 내용 소실 문제를 해결할 수 있지만 IoT 장치에 SSD를 설치해야 하므로 장치의 크기와 전력 소모가 증가하는 문제가 있다.

전원 공급의 중단 또는 시스템 재시작 등의 상황으로 인해 RAM 디스크의 파일 시스템이 소실되는 문제를 해결하기 위해 본 논문에서 제안하는 방법은 RAM 디스크를 대상으로 한 블록 쓰기 요청을 원격 호스트에 실시간으로 백업하는 것이다. 본 논문에서 제안하는 방법은 그림 1에서 나타낸 것과 같이 드라이브 서비스와 블록 백업 및 복구 서비스로 구성되어 있다. 사용자 공간의 프로세스가 파일 접근을 위해 시스템 호출을 이용하여 파일 시스템에 접근하면 파일 시스템은 이를 서비스하기 위해 시스템 호출의 대상이 되는 디스크 블록에 대한 읽기 또는 쓰기 요청(Request)을 큐에 추가한다. 블록 읽기 또는 쓰기 요청이 큐에 추가되면 드라이브 서비스는 큐에서 요청을 꺼내어 처리한다. 요청의 종류가 블록 읽기이면 드라이브 서비스는 RAM 디스크를 위해 사전에 할당된 메모리 영역에서 해당 블록의 내용을 읽어 이 요청을 처리한다. 큐에서 꺼낸 것이 블록 쓰기 요청이면 이 서비스는 블록의 내용을 메모리 영역에 저장함과 동시에 백업 서비스에 블록의 내용을 전달한다. 즉, 드라이브 서비스는 RAM의 메모리 영역을 이용한 디스크 입출력을 서비스하고, 블록 쓰기 요청에 대한 백업 서비스를 활성화하는 역할을 한다.

Fig. 1. 
Architecture of RAM disk block backup/recovery

백업 및 복구 서비스는 블록 쓰기에 대한 백업 서비스와 원격 호스트에 백업된 블록을 이용하여 RAM 디스크의 파일 시스템을 복구하는 복구 서비스로 구성되어 있다. 백업 서비스는 블록 쓰기 요청에 포함되어있는 블록 번호와 블록 내용을 원격 호스트에 전송하여 그 내용을 백업하는 역할을 수행한다. 파일 시스템에 의해 그 내용이 변경되는 블록만이 백업 대상이 되므로 백업 서비스는 블록 쓰기 요청에 대해 활성화된다. 복구 서비스는 시스템 업그레이드 등을 포함한 여러 원인으로 시스템을 재시작한 경우에 원격 호스트에 백업한 파일 시스템을 이용하여 RAM 디스크를 복구하는 기능을 수행한다. 또한, 복구 서비스는 네트워크를 이용하여 원격 호스트에 백업된 파일 시스템을 복구하므로 그림 2에 나타낸 것과 같이 다른 호스트로 교체하여 RAM 디스크를 구성하여도 파일 시스템을 복구할 수 있다는 장점이 있다. 즉, 그림 2(a)는 호스트 A에서 구성된 RAM 디스크 파일 시스템이 백업 호스트에 백업되는 것을 나타내고 있으며, 그림 2(b)는 그 백업 호스트에 저장된 파일 시스템 백업을 이용하여 다른 호스트 B에 복구하는 것을 나타내고 있다. 이러한 복구 방법은 호스트의 하드웨어 고장 또는 교체가 필요한 경우와 더불어 조직의 업무 이관 등으로 인한 호스트 변경이 필요한 경우에 효과적으로 활용될 수 있다.

Fig. 2. 
Recovery from RAM disk file system of another host

백업 및 복구 서비스는 네트워크를 통해 원격 백업 호스트에 디스크 블록을 백업 또는 복구를 위한 프로토콜을 실행한다. 백업 및 복구 서비스는 소켓 기반 서버-클라이언트 통신 모델을 기반으로 하고 있으며, RAM 디스크를 생성하는 호스트가 클라이언트, 백업을 위한 원격 호스트가 서버 역할을 한다. 그림 3은 원격 호스트에 백업된 블록을 이용하여 호스트의 RAM 디스크를 위한 파일 시스템을 복구하기 위한 프로토콜을 나타내고 있다. 복구 서비스는 호스트에 새로운 RAM 디스크를 생성하는 경우에 실행되며, 사전 부여된 식별자(ID)와 블록 수(nBlk) 등 호스트에 생성하고자 하는 RAM 디스크의 식별 정보를 백업 기능을 수행하는 원격 호스트에 전송한다. 원격 백업 호스트에 RAM 디스크의 파일 시스템 백업 본이 존재하면 백업 호스트는 식별자와 블록 수를 호스트에 전송한다. 만약, 파일 시스템의 백업이 존재하지 않으면 백업 호스트는 블록 수에 0을 넣어 호스트에 전송한다. 프로토콜에서 DskReq와 DskRes는 각각 디스크에 대한 파일 시스템 백업 본의 존재 여부를 확인하기 위한 코드이다.

Fig. 3. 
File system recovery protocol

백업 호스트에 RAM 디스크를 위한 파일 시스템 백업이 존재하면 호스트는 RAM 디스크를 위한 공간을 자신의 메모리 공간에서 확보한 후 원격 호스트에 백업된 블록을 이용하여 파일 시스템을 복구한다. 백업된 블록 요청을 위해 호스트는 식별자(ID), 블록 번호(#Blk), 블록 수(nBlk)를 필드로 갖는 BlkRReq 메시지를 백업 호스트에 전송하며, 이에 대한 반응으로 백업 호스트는 식별자(ID), 블록 번호(#Blk), 블록 수(nBlk) 및 블록의 내용(Conts)으로 구성된 BLKRRes 메시지를 호스트에 전송한다.

복구 과정에서 원격 호스트가 전송하는 블록은 블록 번호(#Blk)부터 연속된 블록 수(nBlk)개의 블록이다. 즉, 복구 서비스가 0(#Blk=0)번 블록부터 연속된 네 개의 블록(nBlk=4)을 요청하면 원격 호스트는 0, 1, 2, 3번의 백업된 블록을 전송한다. 복구 서비스가 파일 시스템 복구 프로토콜을 완료하면 호스트에 생성된 RAM 디스크는 복구된 파일 시스템을 기반으로 디스크 입출력 서비스를 제공할 수 있다.

파일 시스템이 복구된 RAM 디스크는 사용자 프로세스를 위한 파일 입출력 서비스를 제공할 수 있다. 사용자 프로세스가 파일 접근을 요청하면 드라이브 서비스는 RAM의 메모리 영역에 저장된 블록을 이용하여 서비스할 수 있다. 이때 파일 쓰기 요청은 메모리에 저장된 블록의 내용을 수정하므로, 앞서 기술한 상황에 따른 데이터 소실의 가능성이 있어 원격 호스트로 그 블록들을 즉시 전송하여 백업하여야 한다.

그림 4는 블록 쓰기 요청에 대응하여 백업 서비스가 수행하는 프로토콜을 나타낸 것이다. 파일 시스템 복구 과정에서 수행한 원격 호스트와의 연결 과정을 통해 관련 정보를 교환하였으므로 백업 서비스는 관련 정보의 교환이 필요하지 않으며, 백업할 블록에 대한 정보를 원격 호스트에 전송하면 된다. 블록 백업을 위해 백업 서비스가 원격 호스트에 전송하는 메시지는 식별자(ID), 블록 번호(#Blk), 블록 수(nBlk), 블록 내용(Conts)으로 구성된 BlkWReq이다. 한 개의 BlkWReq 메시지에는 블록 번호 #Blk부터 연속된 nBlk 개의 블록을 포함할 수 있다.

Fig. 4. 
Block backup protocol

그림 5는 그림 3의 복구 프로토콜을 실행하는 복구 서비스를 위한 구조를 나타내고 있다. 복구 프로토콜 실행을 위한 원격 백업 서버와의 상호작용은 상대적으로 긴 지연시간이 필요하므로 복구 서비스는 메시지 전송, 메시지 수신, 프로토콜 메시지 처리 기능을 갖는 세 개의 커널 스레드를 생성한다. 세 스레드는 네트워크를 통해 전송 또는 수신되는 메시지를 이용하여 실행을 동기화한다. 프로토콜 메시지 처리 스레드(Protocol thread)는 복구 프로토콜을 위한 요청 메시지를 생성하여 전송 큐(Sender queue)에 추가한 후 응답 메시지가 도착할 때까지 대기한다. 전송 큐에 새로운 메시지가 추가될 때까지 대기하는 전송 스레드(Sender thread)는 큐에서 메시지를 가지고 와 백업 호스트로 전송하고, 다음 메시지가 전송 큐에 추가될 때까지 대기한다. 백업 호스트는 수신한 요청 메시지에 대한 응답 메시지를 전송하며, 이를 수신한 수신 스레드(Receiver thread)는 응답 메시지를 수신 큐(Receiver queue)에 추가한다. 앞서 응답 메시지가 도착할 때까지 대기하는 프로토콜 처리 스레드는 수신 큐에 새로운 메시지가 추가되면 이를 큐에서 가져와 처리함으로써 복구 프로토콜에 따른 절차를 진행한다.

Fig. 5. 
Thread and synchronization for recovery

RAM 디스크 모듈이 호스트의 커널에서 제거될 때까지 원격 호스트에 백업이 계속되므로 이를 이용하여 복구된 RAM 디스크의 파일 시스템은 정상적인 디스크 서비스를 제공할 수 있다. 알고리즘 1은 블록 IO 요청을 처리하는 드라이브 서비스를 위한 알고리즘이며, 요청 큐에 블록 IO 요청이 추가되면 동작한다. 이 서비스는 큐에서 가져온 요청의 종류에 따라 처리 내용이 다르다.

블록 읽기 요청이면 이 서비스는 요청에 있는 블록 번호와 크기를 기반으로 RAM 디스크 메모리 영역에 저장된 블록 내용을 요청의 버퍼로 복사한다. 블록 쓰기 요청이면 이 서비스는 요청의 버퍼에 저장된 블록의 내용을 RAM 디스크 메모리 영역에 복사하고, 이 블록의 백업을 위해 앞서 소개한 프로토콜 스레드를 통해 백업 호스트에 전송한다.

백업 서비스는 파일 접근에 따른 블록 쓰기뿐만 아니라 파일 시스템을 생성하는 동안에 요청되는 블록 쓰기 등 RAM 디스크를 대상으로 한 모든 블록 쓰기 요청에 대해 블록의 내용을 원격 호스트로 전송하므로 RAM 디스크 파일 시스템 전체를 백업할 수 있다.

백업 서버는 원격 호스트에서 사용자 수준에서 동작하는 소켓 서버이다. 이 서버는 호스트로부터 수신한 DskReq 메시지의 블록 수와 사전 정의된 블록 크기를 기반으로 파일을 생성하고, 이 파일에 RAM 디스크의 블록을 백업한다. 복구 또는 백업 프로토콜의 메시지에 있는 블록 번호는 백업 파일에서 블록의 위치 결정을 위해 사용된다.

본 논문에서 제안하고 구현한 RAM 디스크의 원격 백업 및 복구 동작이 정상적으로 수행되었음을 보이기 위해 표 1에 나타낸 구현 환경에서 원격 호스트에 백업 서버를 실행하고, 호스트 A에 본 논문에서 구현한 RAM 디스크 모듈을 커널에 적재하고, 실험을 하였다. 실험 환경은 블록 크기를 512바이트, 블록 수를 216개 즉, 32MB 크기의 RAM 디스크를 생성하였으며, 1Gbps 연결을 지원하는 스위칭 허브에 두 호스트를 연결하였다. 소용량인 32MB 크기의 RAM 디스크를 생성한 이유는 복구 시간을 짧게 하여 백업 및 복구가 정상적으로 실행됨을 신속하게 확인하기 위함이다.

생성된 RAM 디스크가 정상 작동함을 확인하기 위해 실시한 실험은 파일 시스템 생성, 드라이브 탑재(Mount), 파일 복사, 삭제, 소스 프로그램 편집, 컴파일 및 실행과 드라이브 내림(Un-mount) 등 파일 시스템을 갖는 블록 장치를 이용하여 수행할 수 있는 작업을 성공적으로 수행하였다. 파일 시스템의 정상 복구 확인을 위한 실험은 두 가지 방법으로 진행하였다. 첫 번째 실험은 최초 RAM 디스크를 생성하고, 사용한 호스트 A의 커널에서 모듈을 제거한 후 다시 모듈을 적재하는 과정에서 원격 호스트에 있는 백업을 이용하여 파일 시스템이 성공적으로 복구된 것을 확인하는 것이다. 그림 6은 첫 번째 실험을 위한 실험 시나리오를 나타낸 것이며, 시나리오의 모든 단계는 호스트 A에서 진행되었다.

Fig. 6. 
Backup and recovery test in a single host

두 번째 실험은 호스트 A의 RAM 디스크를 위한 원격 시스템의 백업을 이용하여 호스트 B에 RAM 디스크를 복구하는 것이다.

그림 7은 두 번째 실험을 위한 시나리오를 나타낸 것이며, 호스트 A에서 실행되는 일반적인 작업에 따라 RAM 디스크의 내용이 원격 호스트에 백업되고, 이 백업을 이용하여 호스트 B에서 파일 시스템이 복구되는 것을 확인한느 것이다. 원격 호스트에 있는 백업 파일에 대한 접근은 단 한 개의 호스트만 가능하므로 두 호스트가 동시에 백업 또는 복구할 수 없다. 따라서, 실험은 각 호스트에 대해 순차적으로 진행되었다.

Fig. 7. 
Recovery test in a host which is not a back-up host

성공적 복구의 확인 방법은 복구가 완료된 후 RAM 디스크를 루트 파일 시스템의 한 디렉토리에 탑재하고, 이전에 저장이 되어 있든 파일들이 이 디렉토리에 정상적으로 존재하며, 파일 시스템 관련 각종 명령어의 정상 동작 여부를 확인하는 것이다.

실험 시나리오에 따른 실험 결과는 본 논문에서 구현한 모듈을 호스트 A 또는 호스트 B의 커널에 적재했을 때 RAM 디스크를 위한 파일 시스템이 성공적으로 복구되었고, 파일 시스템 관련 각 명령어 실행에 문제가 없음을 보였다. 다만, 현재의 구현은 64개의 블록 즉, 32KB 단위로 복구를 진행하여 복구에 긴 시간이 필요하였다.

RAM 디스크에 구성된 파일 시스템의 블록을 원격 호스트에 백업하는 것은 네트워크를 블록 데이터 전송 오버헤드로 인한 성능 저하가 있다. 따라서, 본 논문에서는 백업 기능을 갖지 않는 RAM 디스크와 본 논문에서 제안하는 방법으로 백업하는 RAM 디스크의 성능 차이 분석을 위해 사용자 수준에서 파일 읽기, 쓰기 성능 평가를 수행하였다. 성능 평가는 생성한 RAM 드라이브에 /dev/zero 파일을 복사(쓰기)한 후, 저장한 파일을 /dev/zero로 복사(읽기)하는 과정을 위해 리눅스 명령어 dd를 사용하였고, 각 블록 크기별 256개 블록을 읽기, 쓰기를 하였으며, 성능은 MB/s 단위로 평가하였다.

그림 8은 본 논문에서 구현한 RAM 디스크와 백업 및 복구 기능을 갖는 RAM 디스크 사이의 읽기 성능을 나타내고 있다. 성능 평가 결과는 본 논문에서 제안한 백업 및 복구 기능이 있는 RAM 디스크의 읽기 성능이 기본 RAM 디스크의 성능보다 낮음을 보였다. 이것은 본 논문에서 제안한 RAM 디스크에서 프로토콜을 처리하는 스레드들이 주기적으로 활성화되어 CPU 자원을 사용하는 것과 함께 최적화되지 않는 디스크 서비스 루틴이 원인인 것으로 판단된다.

Fig. 8. 
Read performance for each block size(units:MB/s)

특히, 프로토콜을 처리하는 스레드는 전송할 메시지가 큐에 추가되거나 수신한 메시지가 있는 경우에 활성화되어 메시지를 처리하지만 메시지를 위한 큐가 비어 있으면 계속 대기 상태를 유지한다.

모듈의 제거 등으로 인해 메시지가 큐에 추가되지 않는 상황에서도 커널 스레드는 계속 대기 상태를 유지하므로 커널에 설치되어 있는 모듈에 대한 제거 및 재탑재 등의 동작을 수행할 수 없었다.

따라서, 메시지를 위한 큐가 비어 있어도 주기적으로 커널 스레드가 활성화되도록 하여 이러한 문제를 해결하였으나 고속으로 읽기를 처리하는 RAM 디스크의 특성으로 인해 이것이 읽기 성능 저하에 상대적으로 많은 영향을 준 것으로 판단된다.

그림 9는 두 구성의 쓰기 성능을 나타내고 있다. 디스크 블록 쓰기 요청은 파일 시스템에서 사용하지 않는 블록을 찾고, 관련 정보를 수정하는 등의 동작이 요구되어 블록 읽기 요청보다 상대적으로 낮은 성능을 보인다. 특히, 블록 쓰기 요청은 블록 백업을 위해 네트워크를 이용한 메시지 교환이 요구되므로 백업 기능을 수행하는 RAM 디스크가 그렇지 않은 것 대비 낮은 성능을 보인다.

Fig. 9. 
Write performance for each block size(units:MB/s)

그림 9에 나타낸 두 구성 사이의 성능 차이는 앞서 소개한 바 있는 주기적으로 활성화되는 커널 스레드와 네트워크를 이용한 메시지 교환으로 인한 것으로 판단이 된다. 또, 블록 할당을 위해 파일 시스템 정보 접근(i-node 등)과 블록 쓰기를 위해 메모리 접근이 요구되므로 기본 RAM 디스크의 성능이 블록 크기가 일정 크기 이상일 때 성능이 포화되는 것은 SBC의 제한된 메모리 밴드 폭(Band width)이 원인인 것으로 판단된다. 그리고, 본 논문에서 제안하는 백업 및 복구 기능을 갖는 RAM 디스크는 성능 평가를 위해 설정한 블록 크기 증가에 따른 데이터 교환 용량이 메모리 밴드 폭과 네트워크의 전송 속도 한계에 도달하지 않아 그 성능이 블록 크기 증가에 정비례하였다.

그림 10은 읽기 성능 대비 쓰기 성능의 비를 나타낸 것이다. 앞서 기술한 바와 같이 블록 쓰기 요청은 블록 처리를 위한 오버헤드가 있으므로 읽기 요청보다 상대적으로 낮은 성능을 보인다. 그림 8에 나타낸 비는 블록 쓰기 요청을 처리할 때 백업을 위한 프로토콜 수행이 쓰기 요청의 성능 저하에 더 큰 영향을 주는지를 확인할 수 있다. 분석한 결과에 따르면 백업을 수행하지 않는 구성과 백업을 수행하는 구성의 상대적 성능 저하는 블록 크기별 다소 차이가 있지만 유의미한 차이가 있다고 할 수 없는 것으로 판단된다.

Fig. 10. 
Ratio of write performace relative to read