KR20050072011A

KR20050072011A - 분산 네트워크 시스템 및 그 관리 방법

Info

Publication number: KR20050072011A
Application number: KR1020040000435A
Authority: KR
Inventors: 백승학; 최병구; 박용석
Original assignee: 삼성전자주식회사
Priority date: 2004-01-05
Filing date: 2004-01-05
Publication date: 2005-07-08

Abstract

본 발명은 시스템 관리에 로그를 사용하는 시스템들로 구성된 분산 네트워크 시스템에서 네트워크 상의 하나의 시스템이 모든 시스템에 대한 로그 관리를 수행할 수 있도록 하는 것으로, 네트워크 상의 임의의 시스템을 동일 네트워크 상의 로그 클라이언트로부터 로그를 수집하고 관리하는 로그 서버로 설정하고, 로그 서버에서 입력된 명령이 로그 클라이언트에 송신되도록 하는 로그 데몬을 이용하여 로그 서버에 입력되는 사용자의 명령이 로그 클라이언트에 송신되도록 함으로써 로그 서버에 연결된 사용자가 로그 클라이언트에 대한 제어를 수행할 수 있도록 한다.

Description

분산 네트워크 시스템 및 그 관리 방법{DISTRIBUTED NETWORK SYSTEM AND MANAGEMENT METHOD FOR THE SYSTEM}

본 발명은 네트워크 환경에서 하나의 시스템이 네트워크 상의 모든 시스템을 관리할 수 있는, 통합관리가 가능한 네트워크 시스템 및 그 관리 방법에 관한 것으로, 특히, 네트워크를 구성하는 시스템들에서 발생하는 각종 로그(log)를 하나의 시스템에 모으고 용이하게 제어하기 위한 통합 관리 가능한 네트워크 시스템 및 관리 방법에 관한 것이다.

도 1은 본 일반적인 네트워크 시스템의 블록구성도이다.

도 1에 도시된 바와 같이, 일반적인 시스템은 통신부(140), 입력부(130), 제어부(120), 저장부(110)를 포함한다. 통신부(140)는 다른 시스템과 통신함으로써 데이터 및 신호의 입출력을 수행한다. 입력부(130)는 콘솔 등을 통한 시스템(100)과의 직접 연결을 통한 명령 및 데이터의 입력을 수행한다. 제어부(120)는 통신부(140) 및 입력부(130)를 통한 신호의 입출력 동작을 비롯한 시스템 동작의 전반에 대한 제어를 수행한다. 저장부(110)는 통신부(140) 및 입력부(130)를 통해 입력되는 데이터를 포함하는, 시스템의 동작에 따라 발생하는 데이터를 저장한다.

이와 같이 구성되는 시스템들이 연결되어 동작하는 분산 네트워크를 고려할 때, 시스템의 효율적인 운용 등을 위해 시스템에 대한 관리는 반드시 필요하다. 시스템 관리 방법 중의 하나로 "로그(log)"를 사용하는 방법이 있는데, 로그(log)란 서버 혹은 일반 장치에서 자신의 상태 또는 에러 등을 출력하여 모아두거나 화면으로 보여주는 텍스트 메시지를 의미한다. 일반적으로 시스템에서는 사용자가 알아야 할 사항들이 이 로그를 통해 화면 혹은 파일의 형태로 출력ㆍ저장된다. 특히, BSD(Berkeley Software Distribution) 계열의 시스템은 각종 동작 상태 또는 오류 상태를 파악하기 위해 로그를 남기는데, 로그를 남기기 위해서 일반적으로 "syslogd"라는 범용적인 데몬(daemon)을 사용한다. 일반적으로 시스템 로그 데몬이라 불리는 syslogd는 일반적인 유닉스 시스템에서 사용되는 시스템 기록 도구이다. syslogd는 FIFO(First In First Out)라 불리는, 하나의 파이프와 같이 동작하는 파일을 여는 데몬이다. FIFO를 사용하면 쓰는 쪽에서 기록한 내용은 모두 읽는 쪽에 나타나게 된다. syslogd는 FIFO의 쓰는 쪽에서 보내는 데이터를 읽는 쪽에서 기다리고 있다. 즉, syslogd는 보내어지는 로그 데이터들을 받아서 설정된 곳(장치, 파일 등)에 저장한다. 이 때 사용하는 로그 데이터에는 로그 시간, 로그 레벨(log level), 로그 내용 등이 포함되며, 모든 로그 메시지(log message)는 텍스트(text)형태로 전달된다. 일반적으로 한 시스템 내에서의 로그들은 도메인 소켓(domain socket)을 이용하여 전달되고, 네트워크를 통하여 전달되어야 하는 로그들은 UDP port 514를 통하여 전달된다. syslogd는 syslog.conf 라는 설정파일(configuration)의 제어를 받는다. 이하 도면을 참조하여 네트워크 시스템에서 syslogd를 사용하는 시스템 관리 방법을 설명한다.

도 2는 시스템 로그 데몬인 syslogd 설정 과정을 도시하는 도면이다.

첫째, 로그를 수집할 하나의 메인 시스템 즉, 로그 서버를 설정하고, 로그 서버가 다른 시스템으로부터 로그를 받아들일 수 있도록 로그 옵션을 설정하고 syslogd를 재동작시킨다. 도 2의 시스템 A가 로그 서버로 설정되어 있다. 도 2에 도시된 바와 같이, 로그 서버가 다른 시스템으로부터 로그를 받아들일 수 있도록 하기 위해 "-r"이라는 옵션이 사용될 수 있다. 로그 서버로 설정된 시스템 A는 그 외의 시스템들, 시스템 B 내지 시스템 E의 로그를 수집할 수 있다. 수집된 로그들은 일반적으로, 시스템 A의 저장부(110)에 저장될 것이나, 설정에 따라서는 시스템 A가 아닌 다른 장치에 저장될 수도 있을 것이다.

둘째, 시스템 B 내지 시스템 E는 로그 서버인 시스템 A에 로그를 송신하기 위해서 각각의 시스템에서 syslog.conf를 수정하여 해당 로그 서버의 아이피 어드레스를 설정하고, 로그 서버인 시스템 A로의 포워딩(forwarding)이 가능하도록 syslogd를 재동작시킨다. 즉, 이후 시스템 B 내지 시스템 E는 수집되는 도 2에 도시된 예에서는 시스템 A가 로그 서버이므로, 시스템 A의 아이피 어드레스인 1.1.1.1이 각 시스템의 syslog.conf 파일에 기록된다. 시스템 B 내지 시스템 E는 이후 수집되는 로그를 로그 서버인 시스템 A에 송신한다.

계층(hierarchy) 구조 형태로 분산 시스템이 구성되어 있는 경우에는 상술한 첫째, 둘째의 과정을 구조에 맞추어 모두 실행해야 한다.

도 3은 syslogd 설정 방법을 도시하는 도면으로, 로그 서버가 변경되거나, 로그 우선순위(log severity), 장치(facility)가 변경되는 등 설정이 바뀐 경우의 syslogd 설정 방법을 도시하는 도면이다.

도 3에 도시된 바와 같이, 종래의 시스템에서는, 로그 서버를 변경하거나 로그 서버의 아이피 어드레스가 달라지는 등, 설정이 바뀌는 경우, 도 2를 참조하여 설명한 과정들을 모두 수행해야 한다. 즉, 종래의 시스템에서는 각각의 시스템의 정보가 바뀔 때마다 syslog.conf를 수정하고 재동작을 시켜주어야만 한다. 이와 같이, 종래의 syslogd는 하나의 시스템에 대해서는 구성이 용이하나, 분산 네트워크 시스템에 대해서는 적용하기가 어려우므로, 분산 네트워크 시스템에 쉽게 적용할 수 있는 시스템 통합 관리 방법이 필요하다.

앞서 언급한 바와 같이, syslogd는 syslog.conf의 제어를 받는데, 네트워크 상에 여러 대의 시스템이 존재하는 경우에는 모든 시스템 각각에 대하여 설정파일을 제어해주어야 한다. 따라서, 하나의 시스템에서의 로깅(logging)을 목적으로 syslogd를 사용하는 경우와는 달리, 여러 대의 시스템이 하나의 일을 수행하면서 동작하는 분산 시스템에서는 각종 로그를 소팅(sorting)하거나 제어하기가 상당히 불편하고 쉽지 않다. 분산 시스템에서는 동시에 하나의 작업(job)을 여러 곳에서 컴퓨팅(computing)하기 때문에 오류 복구나 백업 등의 기능들이 하나의 시스템에서 잡을 수행할 때보다 월등하다. 그러나, 이러한 분산 시스템에서 로그를 수집하고 제어하는 데에는 종래의 syslogd의 기능은 부족한 점이 많다. 이로 인해 로그가 절실히 필요한 경우인 오류 발생 시에 오히려 문제 해결을 어렵게 할 소지가 있다.

또한, syslogd를 이용한 로그의 분석은 상당히 많은 시스템 디버그에 유용하지만, 분산 시스템 환경에서 현재의 syslogd로 로그를 설정하고 변경하기는 상당히 불편하다. 특히, log severity를 변경을 통해 필요한 정보만을 보고자 할 때에 모든 system에 syslogd를 재설정하고 재구동하는 것은 상당히 힘든 일이다. 따라서, 본 발명은 이와 같은 문제를 해결하여 쉽게 사용하고자 하는데 있다.

본 발명의 목적은 분산 네트워크 시스템을 용이하게 관리할 수 있는 시스템 관리 방법을 제공함에 있다.

본 발명의 다른 목적은 로그를 사용하여 분산 네트워크 시스템을 용이하게 관리할 수 있는 분산 네트워크 관리 방법을 제공함에 있다.

이와 같은 목적을 달성하기 위하여 본 발명은 종래의 로그 데몬인 syslogd와 달리 분산 네트워크 시스템을 관리하기에 용이한 새로운 로그 데몬을 제안하고, 텔넷 연결을 통해 각 시스템의 로그들을 수집할 수 있도록 한다.

이하 기술하는 본 발명은 BSD(Berkeley Software Distribution) 계열 시스템뿐만 아니라, syslogd라는 로그 데몬을 사용하는 모든 시스템에 적용 가능하다. 이와 같이 syslogd 데몬을 사용하는 시스템의 예로는 UNIX, LINUX, FreeBSD, NetBSD, HPunix 등이 있다. 또, 비록 "syslogd"라는 명칭을 사용하지 않더라도 동일한 기능의 로그 데몬을 가지는 시스템에도 본 발명을 적용할 수 있다. 본 발명은 syslogd를 업데이트하여 분산 네트워크 시스템에 대한 관리에 사용함을 특징으로 한다.

이와 같은 본 발명에 따른 분산 네트워크 시스템은 자신의 시스템에서 생성된 로그를 네트워크를 통해 전송하며, 네트워크를 통해 수신된 명령에 따라 자신의 환경 설정정보를 변경하는 적어도 하나의 로그 클라이언트와, 동일 네트워크 상에 있는 각 로그 클라이언트로부터 전송되는 로그를 수신하여 저장하고, 사용자로부터 입력되는 명령에 따라 상기 로그 클라이언트의 환경 설정정보를 변경하기 위한 명령을 해당 로그 클라이언트에 송신하는 로그 서버를 포함하는 분산 네트워크 시스템이다.

또, 본 발명에 따른, 분산 네트워크 상의 시스템들에서 발생하는 로그를 로그 서버로 설정된 하나의 시스템이 관리하는 통합관리가 가능한 네트워크 시스템의 관리 방법은, 사용자로부터 로그 서버로 설정된 시스템에 입력되는 명령을 상기 로그 서버에 연결된, 로그 클라이언트로 등록된 시스템에 송신하는 로그 데몬을 네트워크 상의 시스템에 설치하는 제 1과정과, 상기 네트워크 상의 임의의 시스템을 로그 서버로 설정하는 제 2과정과, 상기 네트워크 상의 다른 시스템을 상기 로그 서버에 대한 로그 클라이언트로 등록하는 제 3과정과, 상기 로그 서버 및 로그 클라이언트에서 발생하는 로그를 상기 로그 서버에 저장하는 제 4과정을 포함하는 네트워크 시스템 관리 방법이다.

이하 본 발명을 기술하기 위해 사용하는 용어들을 설명한다.

"mylogd"는 본 발명에 따른 분산 네트워크 시스템의 관리를 위해 사용되는 로그 데몬이다.

"데몬(daemon)"이란, 컴퓨터 시스템의 운영에 관련된 작업을 후선(background) 상태로 동작하면서 실행하는 프로그램으로써, 처리해야 할 작업 조건이 발생하면 자동으로 기동하여 필요한 작업을 실행한다

"severity"란 로그의 레벨, 즉 우선순위를 의미하는 용어로, severity가 높을수록 중요한 내용임을 나타낸다.

"로그 서버"는 각 로그 클라이언트로부터 로그를 수집하고 전체 시스템의 로그를 관리 및 저장하는 시스템을 의미한다.

"로그 클라이언트"는 로그를 포워딩하고, 로그 서버로부터 로그 제어를 받는 시스템을 의미한다.

"mylogd"는 본 발명에서 사용하는 로그 데몬으로, 로그 서버에 입력한 명령들이 로그 클라이언트에 전달될 수 있도록 하고, 로그 클라이언트에서 발생하는 로그들이 로그 서버로 전달될 수 있도록 하는 기능을 가진다. 별도의 부연설명이 없는 한, 이하 본 발명을 설명하면서 언급하는 로그 데몬은 mylogd를 가리킨다.

"admin status"는 본 발명에 따른 mylogd의 새로운 설정 파라미터(config parameter)로, 이 값에 따라서 시스템이 외부 로그 제어를 받을지의 여부가 결정된다. 즉, admin status 값에 의해 해당 시스템에 로그 서버로 동작할 것인지, 로그 클라이언트로 동작할 것인지가 결정된다. 물론, admin status라는 명칭은 본 발명을 설명하기 위해 선택된 것으로 명칭에 의해 제한되지 않으며, 동일한 역할을 하는 모든 것을 지칭한다.

이하 설명하는 본 발명을 적용함으로써, 시스템들의 동작 중에 설정 및 변경되는 환경 설정(configuration)이 mylogd라는 하나의 로그 데몬을 통해 모든 시스템에 내려가고, 이를 통해 모든 시스템들이 동시에 동작할 수 있게 된다. 이하 도면 및 실시예를 들어 본 발명을 상세히 설명한다.

본 발명에서 네트워크 상의 각 분산 시스템들에 본 발명에 따른 로그 데몬인 mylogd를 설치하고 실행시키는 과정에 대해 설명한다. 먼저, 로그 서버는 설정파일인 syslog.conf를 수정하고, 로그 옵션을 조정하여 원격 접속이 가능하도록 설정한 후 로그를 재시작하여 시스템에 변경사항이 반영되도록 한다. 로그 클라이언트는 syslog.conf를 수정한 후 로그를 재시작하여 시스템에 변경사항이 반영되도록 한다. 한편, 기존의 설정파일인 syslog.conf는 mylogd의 설치 시, 최초 디폴트 설정으로만 사용되고, 이후에는 동작 중에 변경이 가능하도록 데몬으로 텔넷 포트(telnet port)를 연결할 수 있도록 한다. 텔넷 포트 연결을 통해 CLI(Command Line Interface) 커맨드(command, 명령어)들을 사용할 수 있는데, 사용 가능한 CLI 명령어들 및 사용 예를 기술한다.

(1) "set(master|controlled|none)"는 각 시스템들의 종류를 지시하는 파라미터 값인 admin status 값을 변경하기 위해 사용된다. admin status 값에 따라 각 시스템이 로그 서버인지, 로그 클라이언트인지, 아무런 제어를 받지 않는 시스템인지 등이 결정될 수 있다. admin status는 다음과 같이 설정될 수 있다.

enum_admin_status

{

LOG_NONE,/* Normal system : default value */

LOG_CONTROLLED,/* Controlled system : it can be controlled by master system */

LOG_MASTER/* Master system */

};

이는 admin status 값이 시스템들을 제어 받지 않는 시스템(NONE), 로그 클라이언트(CONTROLLED), 로그 서버(MASTER)로 구분하는 예이다. admin status 값은 필요에 따라 다르게 설정될 수 있다. 예를 들어, 시스템들을 로그 서버와 로그 클라이언트만으로 구분하고자 할 때는 MASTER 값과 CONTROLLED 값만을 사용할 수 있으며, 시스템들을 더 많은 종류로 구분하고자 할 때는 종류 수만큼의 값을 사용할 수 있다. 한편, admin status 값은 각 시스템에서 사용자가 직접 설정할 수 있다. 앞서 언급한 "set (master|controlled|none)" 명령어는 다음과 같이 사용된다. 사용자는 시스템을 로그 서버로 설정하고자 할 시에는 "set master" 명령을 입력하고, 시스템을 로그 클라이언트로 설정하고자 할 시에는 "set controlled" 명령을 입력한다. 한편, "none"이 디폴트 값이므로, 아무런 값도 입력하지 않으면 시스템은 제어 받지 않는 시스템으로 설정된다.

(2) "master log store FILENAME"는 모아지는 로그 메시지들을 "FILENAME"이라는 명칭을 가지는 파일에 출력하여 저장하라는 명령이다. 디폴트 경로는 syslogd와 마찬가지로 /var/log로 할 수 있다.

(4) "master log trap (alerts|critical|debugging|emergencies|errors|informational|notifications|warnings)"은 log severity 값을 조정하는 명령어로써, 로그 서버에서 조정된다. severity는 높은 것부터 나열하는데, emergency, alerts, critical, errors, warnings, notifications, informational, debug 순이며 설정된 severity보다 큰 severity를 가지는 로그만을 포워딩하게 한다. 적용되는 facility는 (3)에서 설정한 facility이다. (3)에서 포워딩할 facility를 특정하지 않고 이 명령어를 수행한 경우 모든 facility에 대해 설정된 severity보다 높은 severity를 가지는 로그를 포워딩한다. 사용자가 불필요한 메시지를 보지 않고 시스템에 문제가 있는 경우만 알고 싶다면 그것을 알 수 있는 레벨 이상(예를 들어, critical 이상)만 보여주거나 저장하도록 설정할 수 있다.

(5) "master log status"는 현재 설정된 구성정보(facility와 trap severity)를 보여준다.

(6) "service syslog on"은 설정파일을 수정한 후, 즉시 적용되도록 한다.

한편, 앞서 기술한 명령어들 중, (2) 내지 (5)와 같은 "master" 명령어에 의한 결과는 각 로그 클라이언트에 전달된다.

이상과 같은 명령들은 시스템(100)에 직접 연결된 콘솔을 통해 입력부(130)로 입력되거나, 텔넷 연결을 통해 통신부(140)로 입력될 수 있다. 제어부(100)는 입력부(130) 또는 통신부(140)를 통해 입력된 명령어를 처리한다.

도 4a 내지 도 4d를 참조하여 mylogd 간의 통신을 위해 사용되는 메시지에 대해 설명한다.

도 4a 내지 도 4d는 본 발명에 따른 로그 데몬인 mylogd간에 사용되는 각 메시지의 내부 포맷을 도시하는 도면이다.

mylogd 간의 통신을 위해서 헬로 메시지(hello), 설정 메시지(cfg), 로그 메시지(log), 응답 메시지(ack)의 네 가지 메시지들이 사용될 수 있다.

헬로 메시지는 로그 서버에 대한 로그 클라이언트의 등록을 위해 사용되는 메시지이다. 도 4a에 도시된 바와 같이, 헬로 메시지는 시스템의 정상동작을 확인하기 위한 비트인 헬로 정보, 로그 서버의 아이피 어드레스 정보, 로그 서버의 포트 정보를 적어도 포함한다. 로그 서버가 이와 같은 헬로 메시지를 플루딩하면, 헬로 메시지를 수신한 로그 클라이언트는 헬로 메시지에 포함된 로그 서버의 아이피 어드레스 및 포트를 참조하여 로그 서버를 자신에서 발생하는 로그를 송신할 대상으로 설정한다.

설정 메시지는 로그 서버가 구성정보를 로그 클라이언트들에 알리기 위해 사용하는 메시지이다. 도 4b에 도시된 바와 같이, 설정 메시지는 본 발명에 따른 기능의 온/오프 여부, 포워딩할 facility, 포워딩할 severity 정보 등의 구성정보를 적어도 포함한다.

로그 메시지는 로그 클라이언트가 각각의 로그를 로그 서버에 송신하기 위해 사용하는 메시지이다. 도 4c에 도시된 바와 같이, 로그 메시지는 타임 스탬프, severity, 프로세스명인 로그 태그, 로그 메시지의 길이 정보를 적어도 포함한다.

응답 메시지는 메시지의 수신 여부를 알리기 위해 사용하는 메시지이다. 도 4d에 도시된 바와 같이, 응답 메시지는 상태(status) 정보를 적어도 포함한다.

이상의 메시지들에 대한 프로그램 코드의 일실시예를 보이면 다음과 같다.

struct mylog_msg

{

struct mylog_msg_header hdr;

union

{

struct log_hellohello;

struct log_cfgcfg;

struct log_msglog;

struct log_ackack;

} bdy;

};

struct mylog_msg_header

{

unsigned short magic;

unsigned short msg_type;/* hello/cfg/log/ack */

unsigned short bdylen;

};

struct log_hello

{

unsigned char hello;/* request hello = 1, response hello = 0 */

unsigned long my_ip;/* my (master ip): client can set master ip */

unsigned long my_port;/* my (master port) : client can set master port */

};

struct log_cfg

{

unsigned char cfg_on;/* on/off */

unsigned char cfg_fac;/* forwarding facility */

unsigned char cfg_sev;/* forwarding severity */

};

struct log_msg

{

long time;/* time stamp */

unsigned char sev;/* severity */

unsigned char tag[6];/* log tag : process name */

unsigned short len;/* log message length */

};

struct log_ack

{

unsigned long status;

};

앞서 설명한 CLI 명령어 및 메시지 포맷을 참조하여 본 발명을 설명한다. 이하 본 발명을 설명함에 있어, 본 발명의 동작을 로그 서버와 로그 클라이언트로 구분하여 설명하도록 한다.

해당 기능은 기본적으로 같은 랜 세그먼트(LAN segment)상의 서브넷(subnet)에서 동작하며, 다른 서브넷(subnet)의 로그 서버를 설정하려면 해당 로그 서버에 직접 설정하는 것을 원칙으로 한다. 모든 커맨드는 로컬 텔넷 포트(local telnet port)로 mylogd에 접속하여 설정이 가능하도록 한다. 텔넷 포트는 3010을 이용한다.

① 사용자는 모든 시스템의 syslogd에 각각 접속하여 "set" 명령을 사용하여 각 시스템에 대한 설정을 수행한다. 즉, 로그를 수집하고 관리 및 제어할 하나의 시스템에 대해서는 "set master" 명령을 사용하여 admin status 값을 "master"로 변경하여 로그 서버로 설정하고, 다른 시스템에 대해서는 admin status를 "controlled"로 변경하여 로그 클라이언트로 설정한다. 그 과정은 다음과 같다.

> telnet localhost 3010

#> set master

#> set controlled

#> exit

"telnet localhost 3010"은 텔넷 포트 3010을 이용하여 텔넷 접속을 하도록 하는 명령어이다. 이 명령어를 통해 시스템에 접속한 후에는 "set" 명령을 사용하여 시스템의 admin status 값을 변경할 수 있게 된다. 해당 시스템을 로그 서버로 설정하고자 하는 경우에는 "set master" 명령을 사용하고, 해당 시스템을 로그 클라이언트로 설정하고자 하는 경우에는 "set controlled" 명령을 사용한다. 이 과정에 대해서는 이하 도 5를 참조하여 더 상세히 설명한다.

② 로그 서버로 설정된 시스템에서는 헬로 메시지가 플루딩되며, 헬로 메시지를 수신한 시스템들은 자신의 admin status 값이 "controlled"이면 로그 서버로 커넥트 응답을 송신하여 연결을 시도한다.

③ 로그 서버는 시스템으로부터의 커넥트 응답을 처리하고 접속된 시스템을 로그 클라이언트로 등록한다. 이 과정에 대해서는 이하 도 6을 참조하여 더 상세히 설명한다.

④ 로그 클라이언트 등록 이후에는 로그 서버에서 "master"명령어에 의한 결과는 각 로그 클라이언트에 전달된다. 이를 통해 하나의 커맨드로 네트워크 상의 모든 시스템들에 대한 로그 제어가 가능하게 된다.

먼저 마스터 시스템, 즉 로그 서버의 동작을 설명한다.

> telnet localhost 3010

#> master log fac local3 ---> 로그 서버로 포워딩하는 facility를 local3로 함

#> master log trap errors ---> 로그 서버로 포워딩하는 log severity를 error이상으로 함

#> exit

로그 서버에서 이와 같은 명령어들이 입력되는 경우, "master" 명령어에 의한 결과가 각 로그 클라이언트들에 전달되므로, "log fac local3" 및 "log trap errors"는 로그 서버에 등록된 모든 로그 클라이언트에 적용된다. 이 과정에 대해서는 이하 도 7을 참조하여 더 상세히 설명한다.

⑤ 한편, 동작 중에 로그 클라이언트로 추가하고 싶은 시스템이 있는 경우, 추가할 시스템을 해당 랜 세그먼트에 물리적으로 접속하고 로그 서버에서 "set master" 명령을 다시 내려주면 재접속 과정이 진행된다. 이 과정에 대해서는 이하 도 8을 참조하여 더 상세히 설명한다.

⑥ 로그 서버를 변경하고 싶은 경우에는 기존의 로그 서버에서 "set controlled" 명령을 내리고, 새로이 로그 서버가 될 시스템에서 "set master" 명령을 내려주면 재설정 과정이 진행된다.

⑦ 랜 세그먼트 바깥(플루딩이 되지 않는 서브넷)의 시스템을 로그 클라이언트로 하고 싶은 경우, 기존의 로그 클라이언트와 동일하게 syslog.conf를 수정하고 텔넷 접속을 한 후 "service syslog on" 명령어를 통해 새로운 설정을 적용한다. 즉, 로그 클라이언트로 설정하고자 하는 시스템의 syslog.conf에 "local3.errors1.1.1.1 (로그 서버의 IP)"를 추가한 후 다음의 커맨드를 수행한다.

> telnet localhost 3010

#> service syslog on

#> exit

도 5는 본 발명의 일 실시예에 따른 도면으로, 로그 클라이언트로부터 로그를 수집하고 관리할 로그 서버 설정 과정 및 로그 클라이언트 설정 과정을 도시하고 있다.

먼저 로그 서버 설정 과정에 대해 설명한다. 사용자(user)는 로그 서버로 설정하고자 하는 시스템에 텔넷을 통해 접속한 후, "set master" 명령을 사용하여 로그 서버로 설정한다. 도 5는 5대의 시스템, 시스템 A 내지 시스템 E로 이루어진 네트워크에서 시스템 A를 로그 서버로 설정하는 실시예를 도시하고 있다. "set" 명령은 admin status 값을 변경하기 위해 사용되는 것으로, "set master" 명령을 사용하여 해당 시스템을 마스터 시스템 즉, 로그 서버로 설정한다. 해당 시스템을 로그 서버로 설정한 후에는 "master log store FILENAME" 명령을 사용하여 로그 클라이언트인 시스템 B 내지 시스템 E로부터 수집한 로그 메시지들을 "FILENAME"이라는 명칭을 가지는 파일로 출력하여 저장한다. 디폴트 경로는 "/var/log"로 한다. "master" 명령어에 의한 결과는 각 로그 클라이언트에 전달되므로, 로그 서버 및 로그 클라이언트들 모두가 이 명령을 수행하게 된다. 즉, 별도의 명령이 없는 한, 로그 서버인 시스템 A에서 발생하는 로그와, 로그 클라이언트인 시스템 B 내지 시스템 E로부터 발생하는 로그 메시지들은 모두 시스템 A에 "log"라는 명칭을 가지는 파일로 저장된다. 다음으로 "master log fac localX" 명령을 사용하여 시스템 A가 로그를 포워딩할 장치(facility)를 결정한다. 시스템 B에만 로그를 포워딩하고자 할 시에는 "master log fac 시스템 B"라 명령하고, 시스템 B 및 시스템 C에 로그를 포워딩하고자 할 시에는 "master log fac (시스템 B|시스템 C)라 명령한다. 포워딩할 facility를 결정하지 않은 경우에는 디폴트 값으로써 모든 facility에 로그가 포워딩된다. 로그를 포워딩할 로그 클라이언트를 결정한 후에는 "master log trap <sev>" 명령을 사용하여 로그의 레벨 값을 조정한다. severity는 높은 것부터 나열하며, 일반적으로 emergency, alerts, critical, errors, warnings, notifications, informational, debug순이다. 설정된 severity보다 큰 severity를 가지는 로그만을 포워딩하게 한다. 이는 포워딩할 facility로 결정된 facility에만 적용되며, facility를 결정하지 않은 경우에는 모든 facility에 대하여 적용된다. 또, 상술한 명령어들 외에도 현재 설정된 로그 서버의 구성정보(facility와 trap severity)를 보여주는 "master log status" 명령과 syslog.conf를 수정한 후 즉시 적용되도록 하는 "service syslog on" 명령 등이 있다.

한편, 사용자는 로그 클라이언트로 설정하고자 하는 시스템 즉, 시스템 B 내지 시스템 E에 텔넷을 통하여 접속한 후, "set controlled" 명령을 사용하여 admin status 값을 변경함으로써 해당 시스템을 로그 클라이언트로 설정한다. 이와 같은 로그 서버 및 로그 클라이언트 설정 과정 이후에는 로그 클라이언트를 로그 서버인 시스템 A에 등록한다. 로그 클라이언트의 등록 과정 을 도 6을 참조하여 설명한다.

도 6은 본 발명에 따른 도면으로, 로그 서버 및 로그 클라이언트간의 메시지 전송 과정과 로그 서버에 대한 로그 클라이언트 등록 과정을 도시하는 도면이다.

제 600단계에서 사용자는 시스템 A를 로그 서버로 설정한다. 이 설정 과정은 도 5를 참조한다. 로그 서버로 설정된 시스템 A는 제 602단계에서 헬로 메시지(hello message)를 플루딩(flooding)한다. 플루딩을 통해 로그 서버와 동일한 랜 세그먼트의 서브넷에 위치하는 시스템들에게 헬로 메시지가 전송된다. 헬로 메시지를 수신한 로그 클라이언트들은 수신한 헬로 메시지를 참조하여 로그 서버인 시스템 A의 아이피 어드레스(1.1.1.1)와 포트 정보를 획득한다. 제 604단계에서 로그 클라이언트들은 획득한 정보를 사용하여 헬로 메시지를 송신한 로그 서버인 시스템 A에 연결한다. 제 606단계에서 시스템 A는 헬로 메시지에 응답한 시스템들을 로그 클라이언트로 등록한다. 이와 같은 과정을 통해 로그 서버 및 로그 클라이언트가 설정되고, 로그 클라이언트가 로그 서버에 등록되면, 로그 서버와 등록된 로그 클라이언트들간에서 로그 메시지의 전송이 이루어진다.

도 7은 본 발명의 일 실시예에 따른 log config 설정 과정 및 로그 메시지 전송 과정을 도시하고 있다.

제 700단계에서 "master" 명령을 통해 log config가 변경되면, 로그 서버인 시스템 A는 제 702단계에서 상기 변경된 log config를 로그 클라이언트들에 송신한다. 로그 서버로부터 log config를 수신한 로그 클라이언트들은 제 704단계에서 log config를 수신했음을 알리는 응답 신호를 로그 서버인 시스템 A에 송신한다. 이후, 로그 클라이언트들은 로그 서버로부터 수신한 log config의 설정에 따라 해당 로그가 발생하는 경우, 이에 따른 로그 메시지를 로그 서버에 송신한다. 로그 서버인 시스템 A는 등록된 로그 클라이언트들로부터 로그 메시지들을 수신하여 저장한다.

도 8은 로그 서버 변경에 따른 설정 과정을 도시하는 도면이다.

로그 서버를 시스템 A에서 시스템 B로 변경하고자 하는 경우, 사용자는, 시스템 A를 로그 서버로 설정하기 위해 수행했던 과정들과 동일한 과정들을 시스템 B에 대해 수행한다. 사용자는 텔넷 연결을 통해 시스템 B에 접속한 후 "set master" 명령을 사용하여 admin status 값을 변경함으로써 시스템 B를 로그 서버로 설정한다. 그리고, 사용자는 시스템 B에 대해 "master log store FILE", "master log fac localX", "master log trap <sev>" 명령을 사용한 설정들을 수행한다. 시스템 B가 로그 서버로 설정된 이후에는 로그 클라이언트들이 송신한 로그들이 시스템 B의 저장부(110)에 저장된다. 한편, 사용자는 기존의 로그 서버였던 시스템 A에 텔넷을 통해 접속한 후 "set controlled" 명령을 사용하여 admin status 값을 변경함으로써 시스템 A를 로그 클라이언트로 설정한다. 로그 클라이언트로 등록된 시스템 A는 이후 시스템 C 내지 시스템 E와 마찬가지로, 로그 서버인 시스템 B에 로그 메시지를 송신한다. 이와 같이 로그 서버가 변경되는 경우에도, 변경되는 시스템 A와 시스템 B 이외의 다른 시스템들인 시스템 C 내지 시스템 E는 아무런 영향을 받지 않는다. 그러므로, 본 발명을 이용하여 분산 네트워크의 로그를 효율적으로 관리할 수 있다.

일반적으로 분산 시스템 환경은 같은 랜 세그먼트 상에서 이루어지기 때문에 새로운 로그 데몬을 이용하면 비교적 손쉽게 사용이 가능하다. 이를 통해 실시간으로 시스템의 상황을 보고 명령어 하나로 바로 로그에 적용하여 필요한 정보들을 얻을 수 있다. 또, 최근에는 분산 시스템이 아니더라도 여러 대의 시스템을 관리하거나 연동하는 경우가 많기 때문에 이 같은 환경에서도 본 발명은 손쉬운 시스템 관리 도구가 될 수 있다.

한편, 로그 서버는 로그 클라이언트들의 로그를 수집해야 하므로, 별도의 제약이 없는 한, 저장 영역이 크고 처리 능력이 뛰어난 시스템을 로그 서버로 설정함이 바람직할 것이다. 물론, 로그 서버 이외에 별도의 저장장치를 지정하고, 수집된 로그를 별도의 저장장치에 저장할 수도 있을 것이다.

본 발명을 사용하면, 사용자는 로그 서버에 연결하여 명령을 입력함으로써 로그 서버에 등록된 로그 클라이언트에 대한 제어까지 수행할 수 있게 된다. 이와 같은 네트워크 시스템에 대한 통합 관리를 통하여 보다 효율적인 네트워크 시스템의 로그 관리가 가능해진다.

도 1은 일반적인 네트워크 시스템의 블록구성도.

도 2는 시스템 로그 데몬인 syslogd 설정 과정을 도시하는 도면.

도 3은 syslogd 설정 과정을 도시하는 도면으로, 로그 서버가 변경되는 경우, 혹은 log severity, facility가 변경되는 경우의 syslogd 설정 방법을 도시하는 도면.

도 4a 내지 도 4d는 본 발명에 따른 로그 데몬인 mylogd간에 사용되는 각 메시지의 내부 포맷을 도시하는 도면.

도 5는 본 발명에 따른 로그 서버 설정 과정을 도시하는 도면.

도 6은 본 발명에 따른 로그 서버와 로그 클라이언트간의 메시지 전송 과정 및 로그 클라이언트 등록 과정을 도시하는 도면.

도 7은 본 발명에 따른 log config 설정 및 로그 메시지 전송 과정을 도시하는 도면.

도 8은 본 발명에 따른 로그 서버 변경 과정을 도시하는 도면.

Claims

자신의 시스템에서 생성된 로그를 네트워크를 통해 전송하며, 네트워크를 통해 수신된 명령에 따라 자신의 환경 설정정보를 변경하는 적어도 하나의 로그 클라이언트와,

동일 네트워크 상에 있는 각 로그 클라이언트로부터 전송되는 로그를 수신하여 저장하고, 사용자로부터 입력되는 명령에 따라 상기 로그 클라이언트의 환경 설정정보를 변경하기 위한 명령을 해당 로그 클라이언트에 송신하는 로그 서버를 포함하는 분산 네트워크 시스템.
제 1항에 있어서, 상기 로그 서버는,

사용자로부터 명령을 입력받는 입력부와,

상기 로그 클라이언트와의 네트워크 연결을 수행하는 통신부와,

환경 설정정보 및 자신의 로그와 상기 통신부를 통해 로그 클라이언트로부터 수신한 로그를 저장하는 저장부와,

상기 사용자로부터 입력받은 명령을 상기 저장부에 저장된 환경 설정정보에 따라 처리하는 제어부를 포함하는 분산 네트워크 시스템.
제 2항에 있어서, 상기 통신부를 통해 사용자로부터 입력되는 명령은 커맨드 라인 인터페이스(Command Line Interface)인 분산 네트워크 시스템.
제 2항에 있어서, 상기 저장부에 저장된 환경 설정정보는 로그 서버로 동작하도록 설정하는 파라미터를 포함하는 분산 네트워크 시스템.
제 4항에 있어서, 상기 사용자로부터 입력되는 명령에 따른 상기 파라미터의 변경을 통해 상기 로그 서버가 로그 클라이언트로 변경되는 분산 네트워크 시스템.
제 2항에 있어서, 상기 제어부는 상기 사용자로부터 입력되는 명령에 따라 상기 저장부에 저장된 환경 설정정보를 변경하는 분산 네트워크 시스템.
제 6항에 있어서, 상기 환경 설정정보의 변경된 항목에는 발생하는 로그를 포워딩할 장치, 로그 레벨, 로그 서버의 아이피 주소 정보가 포함되는 분산 네트워크 시스템.
제 6항에 있어서, 상기 제어부는 상기 사용자로부터 입력되는 명령 중 특정 명령어를 포함하는 명령을 상기 로그 클라이언트에 송신하여 로그 클라이언트를 제어하는 분산 네트워크 시스템.
제 1항에 있어서, 상기 로그 클라이언트는,

상기 로그 서버로부터 명령을 수신하는 통신부와,

환경 설정정보를 저장하는 저장부와,

상기 환경 설정정보에 따라 로그를 발생하고, 발생한 로그를 상기 통신부에 출력하여 상기 로그 서버에 송신하도록 하는 제어부를 포함하는 분산 네트워크 시스템.
제 9항에 있어서, 상기 환경 설정정보는 로그 클라이언트로서 동작하도록 하는 파라미터를 포함하는 분산 네트워크 시스템.
제 10항에 있어서, 상기 파라미터의 변경을 통해 상기 로그 클라이언트가 로그 서버로 변경되는 분산 네트워크 시스템.
제 9항에 있어서, 상기 환경 설정정보는 로그 서버로부터 수신되는 명령에 따라 변경되는 분산 네트워크 시스템.
사용자로부터 로그 서버로 설정된 시스템에 입력되는 명령을 상기 로그 서버에 연결된, 로그 클라이언트로 등록된 시스템에 송신하는 로그 데몬을 네트워크 상의 시스템에 설치하는 제 1과정과,

상기 네트워크 상의 임의의 시스템을 로그 서버로 설정하는 제 2과정과,

상기 네트워크 상의 다른 시스템을 상기 로그 서버에 대한 로그 클라이언트로 등록하는 제 3과정과,

상기 로그 서버 및 로그 클라이언트에서 발생하는 로그를 상기 로그 서버에 저장하는 제 4과정을 포함하는 분산 네트워크 시스템 관리 방법.
제 13항에 있어서, 사용자로부터 특정 명령어를 포함하는 명령이 입력되면, 상기 로그 서버는 상기 입력된 명령을 상기 로그 클라이언트에 송신하는 제 5과정을 더 포함하는 분산 네트워크 시스템 관리 방법.
제 14항에 있어서, 상기 명령은 로그 클라이언트의 환경 설정정보를 변경하라는 명령인 분산 네트워크 시스템 관리 방법.
제 13항에 있어서, 상기 로크 클라이언트의 등록은 로그 서버가 송신한 헬로 메시지에 응답하는 시스템을 대상으로 하는 분산 네트워크 시스템 관리 방법.
제 1항에 있어서, 상기 사용자로부터 입력되는 명령에 따라 상기 로그 클라이언트 중의 하나가 로그 서버로 변경되는 분산 네트워크 시스템 관리 방법.