리눅스 확장성 문제 해결법 공개

중앙일보

입력

유니캐스트 및 멀티캐스트 애플리케이션에 문제점들이 드러나고 있다.

리눅스를 수많은 기기에 배포하는 일을 맡고 있는 시스템 관리자들이 선택할 수 있는 툴의 숫자는 제한돼 있다. 하지만 eWEEK 연구소는 기존 아이디어에 신기술과 새로운 시도를 적용하면 선택의 폭이 한결 넓어질 것이라 확신한다.

리눅스 벤더들은 지난달 개최됐던 리눅스월드 컨퍼런스에서 클러스터나 서버 팜(server farms)을 구축할 때 발생하는 운영체제 배포 문제를 해결할 수 있는 몇 가지 흥미로운 방법들을 공개했다.

여기서 VA 리눅스 시스템(VA Linux System)의 시스템이미저(SystemImager) 유틸리티를 비롯한 기존의 유니캐스트 방식들이 논의됐다. 다른 유니캐스트 기술들과 마찬가지로 이 툴은 운영체제 이미지를 각각의 노드에 복제하기 위해 rsync에 의존한다.

유닉스 기반 시스템용으로 개발된 FTP인 rsync 프로그램은 운영체제 설치를 용이하게 하는 기능들이 있어 신속하게 파일을 전송할 수 있다. 우선 rsync는 전체 디렉토리와 파일 시스템을 업데이트할 수 있다.

두 번째로 이 프로토콜은 파일 소유권 및 사용 허가권을 보존할 수 있다. 이 두 가지 특징을 조합하면 관리자들은 맞춤화된 파일 사용 허가권으로 모델 기기를 설치하는 것이 가능해진다. 이는 또한 새롭게 만들어진 서버 팜 전체에 걸쳐 복사된다.

시스템이미저(SystemImager)는 그 자체만으로도 rsync 유틸리티보다 더욱 확실한 보안을 제공한다. 그러나 시스템이미저는 rsync이 대역폭 사용에 제한을 가져다 준다는 특유의 문제를 극복하지 못했다.

컨퍼런스의 한 연설자에 따르면 시스템이미저는 패스트 이더넷(Fast Ethernet)에 접속해 최고 20대의 시스템으로 동시에 확대되는 경향이 있다고 한다. rsync는 IP 멀티캐스트 기술을 사용하지 않고 각 서버에 이미지 데이터 전체를 발송하기 때문이다.

두 번째 영역에서는 VA 리눅스가 선두를 달리고 있는 공개소스 개발 네트워크, 소스포지(SourceForge)에 대한 작업이 흥미롭게 진행되고 있다.

샐리 플로이드를 포함한 몇 사람이 신뢰할 만한 멀티캐스팅에 대해 작성한 논문을 이용, 소규모 지원자들이 프로젝트 완성에 시한을 두지 않고 백신(Vaccine) 프로젝트를 수행하기 시작했다. 백신이란 말이 안티바이러스 개념을 내포하고 있긴 하지만 이 프로젝트는 VA Cluster Computer Install Engine의 첫 글자를 따서 프로젝트명을 붙인 것이다.

이 프로젝트는 아직 시작 단계에 불과하지만 eWeek 연구소는 개발자들이 제대로 프로젝트를 추진하고 있다고 확신한다.

멀티캐스트용 NAK

플로이드의 논문에 따르면 NAK(Negative Acknowledgments)를 다루는 일과 멀티캐스트 프로토콜을 신뢰할만한 것으로 만드는 일이 난관이라고 한다.

백신 프로젝트는 플로이드가 설명한 NAK 억제에 대한 몇 가지 지침을 사용해 멀티캐스트 디스트리뷰션 툴을 구축하고 있다. 멀티캐스트 배포 툴은 패킷을 놓친 타깃 기기가 먼저 NAK에 귀기울인 뒤 또다른 멀티캐스트 멤버가 NAK을 보내지 않았다는 것이 확인된 경우에만 NAK을 전송하게 돼 있다.

이런 과정에 대한 설명과 코딩을 제대로 전달하기가 좀 힘들지만, 네트워크상의 관리 트래픽 양을 과감히 줄인 것은 유익하다고 할 수 있다. 실제 데이터를 위해 좀 더 많은 공간을 확보할 수 있기 때문이다.

멀티캐스팅의 수많은 이점 중 멀티캐스트 그룹에 있는 모든 PC가 동시에 데이터를 받는다는 점을 빼놓을 순 없다. 따라서 같은 파일을 개별 기기에 반복해 전송할 필요는 없다.

프로젝트가 성공하기만 한다면 백신은 클러스터 관리에서 파일 저장 및 멀티미디어 애플리케이션에 이르기까지 많은 애플리케이션에서 사용되기 위해 부분적으로 수정될 수 있다. 그러나 현시점에서는 관리자들에게 지체되는 유니캐스트 배포에 대한 대안은 없는 것으로 보인다. 수많은 운영체제 배포를 생각하는 사람들은 벤더들의 툴이 커널 배포 부담을 덜어준다고 생각할 것이다.

* 리눅스의 멀티캐스트 미해결 과제

멀티캐스트 시스템 이미지가 배포되면 하나의 중앙시스템이 일단의 리스닝 머신에 패킷을 한 번 보낼 수 있게 된다. 몇 가지 이유로 리눅스용 멀티캐스트 제품 완성은 4∼6개월 정도 더 걸릴 것 같다.

-아직 완벽한 무료 멀티캐스트는 없다 : VA 리눅스 같은 기업들의 엔지니어들은 처음부터 그들의 툴을 기초부터 철저히 구축하고 있다.

-NAK 처리 및 억제 문제 : 하나 이상의 타깃 시스템이 멀티캐스트 패킷을 받지 않으면, 어떤 시스템으로 NAK를 보낼 수 있단 말인가? 현재 일반적인 이론은 오직 하나의 타깃만이 개연성있는 네트워크 혼잡을 피하기 위해 NAK를 보낸다고 설명하고 있다.

-누락된 데이터의 재전송도 문제 : 인접한 타깃이 NAK의 대상인 패킷을 받는다면, 이 타깃이 데이터를 보내야 하는가 아니면 중앙 시스템이 이 트래픽을 처리해야 하는가? @