클라이언트-서버 처리 모델

로컬 및 원격 애플리케이션 프로세스는 모두 동일한 데이터베이스에서 작동할 수 있습니다. 원격 애플리케이션은 데이터베이스 서버가 상주하는 머신의 원격 머신에서 데이터베이스 조치를 시작하는 애플리케이션입니다. 로컬 애플리케이션은 서버 머신의 데이터베이스에 직접 접속되어 있습니다.

클라이언트 연결의 관리 방식은 연결 집중기의 설정 여부에 따라 다릅니다. max_connections 데이터베이스 관리자 구성 매개변수의 값이 max_coordagents 구성 매개변수의 값보다 클 때마다 연결 집중기가 설정됩니다.
  • 연결 집중기가 해제된 경우 각 클라이언트 애플리케이션에는 해당 애플리케이션의 처리를 조정하고 통신하는 코디네이터 에이전트라고 하는 고유 엔진 디스패치 가능 장치(EDU)가 지정됩니다.
  • 연결 집중기가 설정된 경우 각 코디네이터 에이전트는 여러 클라이언트 연결을 한 번에 하나씩 관리할 수 있으며 다른 작업자 에이전트가 이 작업을 수행하도록 조정할 수 있습니다. 여러 임시 연결을 사용하는 인터넷 애플리케이션이나 비교적 작은 여러 개의 트랜잭션을 사용하는 애플리케이션의 경우 연결 집중기는 여러 개의 추가 클라이언트 애플리케이션을 동시에 연결할 수 있도록 허용하여 성능을 향상시킵니다. 또한 각 연결의 시스템 자원 사용이 줄어듭니다.
그림 1에서 Db2® 서버의 각 원은 운영 체제 스레드를 사용하여 구현되는 EDU를 나타냅니다.
그림 1. 클라이언트-서버 처리 모델 개요
클라이언트-서버 처리 모델의 개요를 표시하는 그림
  • A1에서 로컬 클라이언트는 db2ipccm을 통해 통신을 설정합니다.
  • A2에서 db2ipccm은 로컬 클라이언트의 애플리케이션 요청에 따라 코디네이터 에이전트가 되는 db2agent EDU에 대해 작업합니다.
  • A3에서 코디네이터 에이전트는 클라이언트 애플리케이션에 접속하여 클라이언트 애플리케이션과 코디네이터 간 공유 메모리 통신을 설정합니다.
  • A4에서 로컬 클라이언트의 애플리케이션이 데이터베이스에 연결합니다.
  • B1에서 원격 클라이언트가 db2tcpcm을 통해 통신을 설정합니다. 다른 통신 프로토콜을 선택한 경우 적합한 통신 관리자를 사용합니다.
  • B2에서 db2tcpcm은 애플리케이션의 코디네이터 에이전트가 되는 db2agent EDU에 대해 작업하고 이 에이전트로 연결을 전달합니다.
  • B4에서 코디네이터 에이전트는 원격 클라이언트 애플리케이션에 접속합니다.
  • B5에서 원격 클라이언트 애플리케이션이 데이터베이스에 연결합니다.
다음의 사항도 참고하십시오.
  • 작업자 에이전트가 애플리케이션 요청을 수행합니다. 네 가지 유형의 작업자 에이전트 즉, 활성 코디네이터 에이전트, 활성 서브에이전트, 연관된 서브 에이전트 및 유휴 에이전트가 있습니다.
  • 각 클라이언트 연결은 활성 코디네이터 에이전트에 링크됩니다.
  • 파티션된 데이터베이스 환경 또는 파티션 내 병렬 처리가 사용 가능한 환경에서 코디네이터 에이전트는 서브에이전트(db2agntp)로 데이터베이스 요청을 분산시킵니다.
  • 유휴 에이전트가 새 작업을 기다리는 에이전트 풀(db2agent)이 있습니다.
  • 다른 EDU는 클라이언트 연결, 로그, 2단계 커미트 조작, 백업 및 복원 작업과 기타 태스크를 관리합니다.
그림 2 는 서버 시스템 환경의 일부인 추가 EDU를 표시합니다. 각 활성 데이터베이스에는 자체의 프리페처(db2pfchr) 공유 풀과 페이지 클리너(db2pclnr) 및 자체 로그 프로그램(db2loggr)과 교착 상태 검출기(db2dlock)가 있습니다.
그림 2. 데이터베이스 서버의 EDU
데이터베이스 서버의 EDU를 표시하는 그림

그림에 표시되지 않은 분리(fenced) 사용자 정의 함수(UDF) 및 스토어드 프로시저를 관리하여 작성 및 폐기와 연관된 비용을 최소화합니다. keepfenced 데이터베이스 관리자 구성 매개변수의 기본값은 YES이며, 스토어드 프로시저 프로세스를 다음 프로시저 호출 시 재사용할 수 있도록 유지합니다.

주: 비분리 UDF및 스토어드 프로시저는 성능 향상을 위해 에이전트의 어드레스 스페이스에서 직접 실행됩니다. 그러나 에이전트의 어드레스 스페이스에 대한 무제한 액세스가 가능하므로 사용하기 전에 엄격하게 테스트해야 합니다.
그림 3 은 단일 데이터베이스 파티션 처리 모델과 다중 데이터베이스 파티션 처리 모델 간의 유사성 및 차이점을 보여줍니다.
그림 3. 다중 데이터베이스 파티션의 프로세스 모델
다중 데이터베이스 파티션에 대한 프로세스 모델을 표시하는 그림

다중 데이터베이스 파티션 환경에서 CREATE DATABASE 명령이 발행된 데이터베이스 파티션을 카탈로그 데이터베이스 파티션이라고 합니다. 이 데이터베이스 파티션에 시스템 카탈로그 테이블이 저장됩니다. 시스템 카탈로그는 데이터베이스의 오브젝트에 대한 모든 정보의 저장소입니다.

그림 3에 표시된 대로, 애플리케이션 A가 Node0000에 PROD 데이터베이스를 작성하므로 PROD 데이터베이스의 카탈로그도 이 데이터베이스 파티션에 작성됩니다. 마찬가지로 B 애플리케이션은 Node0001에서 TEST 데이터베이스를 작성하므로 TEST 데이터베이스의 카탈로그가 이 데이터베이스 파티션에서 작성됩니다. 사용자 환경의 여러 데이터베이스 파티션들에서 각 데이터베이스의 카탈로그와 연관된 추가 활동의 균형을 맞추기 위해 다른 데이터베이스 파티션에서 데이터베이스를 작성하는 것이 좋습니다.

인스턴스와 연관된 추가 EDU(db2pdbc 및 db2fcmd)가 있으며 다중 데이터베이스 파티션 환경의 각 데이터베이스 파티션에서 찾을 수 있습니다. 이러한 EDU는 데이터베이스 파티션에서 요청을 조정하고 FCM(Fast Communication Manager)을 사용 가능하게 할 때 필요합니다.

카탈로그 데이터베이스 파티션과 연관된 추가 EDU(db2glock)가 있습니다. 이 EDU는 활성 데이터베이스가 있는 데이터베이스 파티션에서 전역 교착 상태를 제어합니다.

애플리케이션의 각 연결 요청은 코디네이터 에이전트와 연관된 연결로 표시합니다. 코디네이터 에이전트는 요청을 받고 응답을 보내어 애플리케이션과 통신하는 에이전트입니다. 요청 자체를 충족시키거나 요청을 수행하기 위해 다중 서브에이전트를 조정할 수 있습니다. 코디네이터 에이전트가 상주하는 데이터베이스 파티션을 해당 애플리케이션의 코디네이터 데이터베이스 파티션이라고 합니다.

애플리케이션에서 발행하는 데이터베이스 요청의 일부분은 코디네이터 데이터베이스 파티션에 의해 다른 데이터베이스 파티션의 서브에이전트로 전송됩니다. 모든 결과를 애플리케이션으로 다시 보내기 전에 코디네이터 데이터베이스 파티션에서 통합합니다.

여러 데이터베이스 파티션을 동일한 머신에서 실행하도록 구성할 수 있습니다. 이러한 구성을 다중 논리적 파티션 구성이라고 합니다. 이러한 구성은 주기억장치가 매우 큰, 대형 대칭형 멀티프로세서(SMP)에서 매우 유용합니다. 이 환경에서 공유 메모리 및 세마포어를 사용하도록 데이터베이스 파티션들 간 통신을 최적화할 수 있습니다.