|
| |
| Sun Java System Message Queue 3.5 SP1 관리 설명서 | |
부록 E
기술 노트이 부록에서는 다음 내용을 간단하게 다룹니다.
시스템 클럭 설정Message Queue 시스템 사용 시 시스템 클럭 동기화에 주의하고 클럭을 역방향으로 설정하지 않아야 합니다.
동기화 권장
Message Queue 시스템과 상호 작용하는 모든 호스트에서 클럭을 동기화하는 것이 좋습니다. 클럭 동기화는 메시지 만료(TimeToLive)를 사용할 경우에 특히 중요합니다. 호스트의 클럭을 동기화하지 않으면 TimeToLive가 예상한 대로 작동하지 않을 수 있습니다(메시지가 전달되지 않을 수 있음). 브로커를 시작하기 전에 클럭을 동기화해야 합니다.
Solaris 로컬 호스트에서 rdate 명령을 실행하여 원격 호스트와 동기화할 수 있습니다 (이 명령 실행에는 수퍼유저(루트) 권한이 필수). 예를 들어, 다음 명령은 로컬 호스트(Host 2)를 원격 호스트 Host1과 동기화합니다.
# rdate Host1
Linux 이 명령은 Solaris에서와 비슷하지만 다음 -s 옵션을 제공해야 합니다.
# rdate -s Host1
Windows net 명령을 time 하위 명령과 함께 실행하여 로컬 호스트를 원격 호스트와 동기화할 수 있습니다. 예를 들어, 다음 명령은 로컬 호스트(Host 2)를 원격 호스트 Host1과 동기화합니다.
net time \\Host1 /set
역방향 시스템 클럭 설정 금지
Message Queue 브로커를 실행하는 시스템에서 시스템 클럭을 역방향으로 설정하지 마십시오. Message Queue는 트랜잭션, 영구 가입과 같은 내부 객체를 식별하기 위해 타임스탬프를 사용합니다. 시스템 클럭을 역방향으로 설정하면 이론적으로 중복 내부 식별자가 생성될 수 있습니다. 브로커는 식별자에 임의성을 부여하고 실행 중에 클럭 이동을 감지하는 방법으로 이 문제점을 보완하려고 합니다. 그러나 브로커가 실행되지 않을 때 시스템 클럭이 역방향으로 크게 이동하면 식별자가 중복될 가능성이 약간 있습니다.
브로커가 실행 중인 시스템에서 시스템 클럭을 몇 초 이상 역방향으로 설정해야 하는 경우 트랜잭션 또는 영구 가입이 없을 때 설정하거나 브로커가 실행 중이 아닐 때 설정 작업을 수행한 다음 클럭을 이동한 시간만큼 대기한 후 브로커를 다시 실행하는 것이 좋습니다.
가장 좋은 방법은 브로커를 시작하기 전에 클럭을 동기화한 다음 적절한 기술을 사용하여 클럭이 배포된 이후에 많이 이동되지 않도록 하는 것입니다.
OS 정의 파일 설명자 제한Solaris 및 Linux 플랫폼의 경우 클라이언트나 브로커가 실행 중인 쉘에서 클라이언트가 사용 가능한 파일 설명자의 수에는 소프트 한계가 있습니다. Message Queue 시스템에서는 각 클라이언트가 만드는 연결 또는 각 브로커가 받아들이는 연결에 이 파일 설명자 중 하나를 사용합니다. 지속성 메시지를 갖는 각 대상 역시 파일 설명자를 사용합니다.
결과적으로 이러한 요소가 연결 수를 제한합니다. 따라서 파일 설명자 제한을 변경하지 않으면 Solaris에서는 256개, Linux에서는 1024개를 초과하는 연결에서 브로커나 클라이언트를 실행할 수 없습니다(지속성을 위해 파일 설명자를 사용하기 때문에 연결 제한은 실제로 더 낮음).
파일 설명자 제한을 변경하려면 ulimit 설명서 페이지를 참조하십시오. 클라이언트 또는 브로커가 실행될 각 쉘에서 한계를 변경해야 합니다.
지속성 데이터 보안브로커는 정보 가운데 일시적으로 저장되는 메시지 파일을 포함할 수 있는 영구 저장소를 사용합니다. 이러한 메시지에는 소유 정보가 포함될 수 있기 때문에 인증되지 않은 액세스로부터 데이터 저장소를 안전하게 보호하는 것이 좋습니다.
브로커는 기본 제공 또는 플러그 인 지속성을 사용할 수 있습니다.
기본 제공 영구 저장소
기본 제공 지속성을 사용하는 브로커는 플랫폼에 따라 다른 디렉토리에 있는 플랫 파일 데이터 저장소에 지속성 데이터를 작성합니다(부록 A, "Message Queue 데이터의 위치" 참조).
.../span>/instances/instanceName/fs350/
여기서 instanceName은 브로커 인스턴스를 식별하는 이름입니다.
instanceName/filestore/ 디렉토리는 브로커 인스턴스가 처음으로 시작될 때 생성됩니다. 이 디렉토리 보안 절차는 브로커가 실행 중인 운영 체제에 따라 다릅니다.
Solaris 및 Linux IMQ_VARHOME/instances/instanceName/filestore/ 디렉토리에 대한 사용 권한은 브로커 인스턴스를 시작한 사용자의 umask에 따라 다릅니다. 따라서, umask를 적절하게 설정하여 브로커 인스턴스 시작 권한과 지속성 파일 읽기 권한을 제한할 수 있습니다. 또는, 관리자(수퍼유저)가 IMQ_VARHOME/instances 디렉토리에 대한 사용 권한을 700으로 설정하여 지속성 데이터를 안전하게 보호할 수 있습니다.
Windows 사용 중인 Windows 운영 체제에서 제공하는 메커니즘을 사용하여 IMQ_VARHOME/instances/instanceName/filestore/ 디렉토리에 대한 사용 권한을 설정할 수 있습니다. 여기에는 일반적으로 디렉토리에 대한 등록 정보 대화 상자 열기가 포함됩니다.
플러그 인 영구 저장소
플러그 인 지속성을 사용하는 브로커는 JDBC 호환 데이터베이스에 지속성 데이터를 작성합니다.
데이터베이스 서버에서 관리하는 데이터베이스(예: Oracle 데이터베이스)의 경우 Message Queue 데이터베이스 테이블(이름이 "IMQ"로 시작하는 테이블)에 액세스할 사용자 아이디 및 비밀번호를 만드는 것이 좋습니다. 데이터베이스에서 개별 테이블을 보호할 수 없는 경우 Message Queue 브로커 전용 데이터베이스를 만듭니다. 사용자 아이디/비밀번호 액세스 작성 방법에 대한 자세한 내용은 데이터베이스 공급업체 설명서를 참조하십시오.
브로커가 데이터베이스 연결을 여는 데 필요한 사용자 아이디와 비밀번호는 브로커 구성 등록 정보에서 제공될 수 있습니다. 브로커 시작 시 사용자 아이디와 비밀번호를 명령줄 옵션으로 제공하는 것이 보다 안전합니다(Message Queue 관리 설명서, 부록 A, "플러그 인 지속성 설정" 참조).
데이터베이스의 JDBC 드라이버를 통해 브로커가 직접 액세스하는 내장 데이터베이스(예: Cloudscape 데이터베이스)의 경우 일반적으로 지속성 데이터가 저장될 디렉토리에 대한 파일 사용 권한(위 "기본 제공 영구 저장소" 설명 참조)을 설정하여 보호합니다. 브로커와 imqdbmgr 유틸리티를 모두 사용하여 데이터베이스를 읽고 쓸 수 있게 하려면 해당 유틸리티와 브로커를 동일한 사용자가 실행해야 합니다.