Tomcat 클 러 스 터 실현 원리 분석

필자 의 지난 블 로그 (http://zyycaesar.iteye.com/admin/blogs/295227) 에서 간단 한 설정 을 통 해 tomcat 군집 을 실현 하 는 방법 을 간략하게 소개 했다. 본 고 는 tomcat 군집 에 대해 더욱 깊이 있 고 상세 한 설정 을 하여 특정한 수 요 를 만족 시 키 는 것 을 소개 하고 자 한다.
 
     WEB 응용 클 러 스 터 의 기술 실현 에 있어 가장 큰 난점 은 클 러 스 터 의 여러 노드 간 에 데이터 의 일치 성 을 유지 하 는 것 이다. 세 션 (Session) 정 보 는 이런 데이터 에서 가장 중요 한 부분 이다.이 를 실현 하려 면 대체적으로 두 가지 방식 이 있다. 하 나 는 모든 Session 데 이 터 를 한 서버 나 데이터 베이스 에 두 고 클 러 스 터 의 모든 노드 는 이 Session 서버 에 방문 하여 데 이 터 를 얻 는 것 이다.다른 하 나 는 클 러 스 터 의 모든 노드 간 에 Session 데 이 터 를 동기 화하 고 모든 노드 가 모든 Session 데 이 터 를 저장 하 는 것 이다.두 가지 방식 은 모두 장점 이 있 는데 첫 번 째 방식 은 간단 하고 실현 하기 쉽 지만 세 션 서버 가 고장 이 나 면 전체 시스템 이 정상적으로 작 동 하지 못 할 위험 이 존재 한다.두 번 째 방식 은 신뢰성 이 더욱 높 고 모든 노드 의 고장 은 전체 시스템 이 고객 방문 에 대한 응답 에 영향 을 주지 않 지만 기술 실현 에 있어 더욱 복잡 하 다.흔히 볼 수 있 는 플랫폼 이나 미들웨어, 예 를 들 어 microsoft asp. net 과 IBM WAS 는 두 가지 공유 방식 에 대한 지원 을 제공 합 니 다. tomcat 도 마찬가지 지만 보통 두 번 째 방식 을 사용 합 니 다.
 
     tomcat 기본 클 러 스 터 설정 (< Cluster className = "org. apache. catalina. ha. tcp. Simple TcpCluster" / >) 을 사용 할 때 설정 의 세부 사항 은 사실상 생략 되 었 습 니 다. 대부분의 응용 프로그램 에 서 는 기본 설정 을 사용 하 는 것 이 충분 합 니 다. 완전한 기본 설정 은 다음 과 같 습 니 다.
 
     

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="8">
          <Manager className="org.apache.catalina.ha.session.DeltaManager"
                   expireSessionsOnShutdown="false"
                   notifyListenersOnReplication="true"/>

          <Channel className="org.apache.catalina.tribes.group.GroupChannel">
            <Membership className="org.apache.catalina.tribes.membership.McastService"
                        address="228.0.0.4"
                        port="45564"
                        frequency="500"
                        dropTime="3000"/>
            <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                      address="auto"
                      port="4000"
                      autoBind="100"
                      selectorTimeout="5000"
                      maxThreads="6"/>

            <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
              <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
            </Sender>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
          </Channel>

          <Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""/>
          <Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>

          <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
                    tempDir="/tmp/war-temp/"
                    deployDir="/tmp/war-deploy/"
                    watchDir="/tmp/war-listen/"
                    watchEnabled="false"/>

          <ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
          <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
        </Cluster> 

      다음 에 필 자 는 이곳 의 배치 항목 에 대해 상세 하 게 설명 한다. 다음 과 같은 내용 은 모두 필자 가 tomcat 공식 문 서 를 읽 은 후에 자신의 이해 이 고 틀 릴 수 있 으 므 로 독자 들 이 비판 적 인 시선 으로 읽 고 필자 의 잘못 을 지적 하 는 것 을 환영한다.
    
     tomcat 군집 각 노드 는 tcp 링크 를 구축 하여 Session 의 복사 본 을 완성 하고 복사 본 은 동기 화 와 비동기 두 가지 모델 이 있 습 니 다.동기 화 모드 에서 클 라 이언 트 에 대한 응답 은 Session 에서 다른 노드 로 복사 한 후에 해 야 합 니 다.비동기 모드 는 세 션 복사 가 완료 되 기 를 기다 리 지 않 아 도 응답 할 수 있 습 니 다.비동기 모드 는 더욱 효율 적 이지 만 동기 모드 는 신뢰성 이 높다.동기 비동기 모드 는 channelsendeOptions 매개 변수 에 의 해 제어 되 고 기본 값 은 8 이 며 비동기 모드 이 며 4 는 동기 모드 입 니 다.비동기 모드 에 서 는 복사 확인 (Acknowledge) 을 추가 해 신뢰성 을 높 일 수 있 으 며, 이때 channelsend Options 는 10 으로 설정 된다.
 
     Manager 는 노드 간 에 Session 을 복사 하 는 데 사 용 됩 니 다. 기본적으로 Delta Manager 를 사용 합 니 다. Delta Manager 는 all - to - all 작업 방식 을 사용 합 니 다. 즉, 클 러 스 터 의 노드 는 Session 데 이 터 를 모든 다른 노드 에 복사 합 니 다. 다른 노드 가 현재 응용 프로그램 을 배 치 했 는 지 여부 에 관 계 없 이.클 러 스 터 의 노드 수량 이 많 고 서로 다른 응용 프로그램 이 배치 되 어 있 을 때 BackupManager 를 사용 할 수 있 습 니 다. BackManager 는 현재 응용 되 고 있 는 노드 에 만 Session 을 복사 할 수 있 습 니 다.그러나 지금까지 BackupManager 는 대규모 테스트 를 거치 지 않 아 신뢰성 이 Delta Manager 에 미 치지 못 했다.
 
     Channel 은 tomcat 군집 의 IO 층 을 설정 합 니 다.Membership 은 클 러 스 터 의 다른 노드 를 발견 하 는 데 사 용 됩 니 다. 여기 address 는 멀티캐스트 address (Multicast address) 를 사용 합 니 다. 더 많은 멀티캐스트 주소 에 대한 자세 한 정 보 는 참조 하 시기 바 랍 니 다.http://zyycaesar.iteye.com/admin/blogs/296501) 같은 그룹 방송 주소 와 포트 의 여러 노드 를 사용 하여 같은 키 클 러 스 터 에 속 합 니 다.따라서 사용자 정의 멀티캐스트 주소 와 포트 를 통 해 하나의 큰 tomcat 클 러 스 터 를 여러 부분 으로 나 눌 수 있 습 니 다.Receiver 는 각 노드 가 다른 노드 에서 보 낸 데 이 터 를 수신 하 는 데 사 용 됩 니 다. 기본 설정 에서 tomcat 는 4000 - 4100 사이 에서 사용 가능 한 포트 를 순서대로 선택 하여 수신 합 니 다. 사용자 정의 설정 을 할 때 여러 tomcat 노드 가 물리 서버 에서 서로 다른 포트 를 사용 해 야 합 니 다.Sender 는 다른 노드 에 데 이 터 를 보 내 는 데 사 용 됩 니 다. 구체 적 으로 Transport 설정 을 통 해 Pooled ParallelSender 는 tcp 연결 풀 에서 연결 을 얻 고 병렬 전송 을 실현 할 수 있 습 니 다. 즉, 클 러 스 터 의 여러 노드 는 다른 모든 노드 에 데 이 터 를 동시에 보 내 고 서로 영향 을 주지 않 습 니 다.Interceptor 는 다음 에 설명 할 Valve 와 유사 하여 하나의 밸브 역할 을 합 니 다. 데이터 가 목적 노드 에 도달 하기 전에 검 측 하거나 다른 작업 을 합 니 다. 예 를 들 어 TcpFailureDetector 는 데이터 전송 과정 에서 tcp 오류 가 발생 했 는 지 확인 하 는 데 사 용 됩 니 다.채널 의 프로 그래 밍 모델 에 대해 서 는 참조 하 시기 바 랍 니 다.http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/tribes/Channel.html。
 
     Valve 는 노드 가 클 라 이언 트 에 응답 하기 전에 검 측 하거나 일부 조작 을 하 는 데 사 용 됩 니 다. ReplicationValve 는 현재 응답 이 Session 데이터 의 업데이트 와 관련 되 는 지 검사 하 는 데 사 용 됩 니 다. 만약 에 Session 복사 작업 을 시작 하면 filter 는 필터 요청 에 사 용 됩 니 다. 예 를 들 어 클 라 이언 트 가 그림, css, js 에 대한 요청 은 Session 과 관련 되 지 않 기 때문에 검 측 할 필요 가 없습니다.기본 상태 에서 필 터 를 하지 않 고 모든 응답 을 모니터링 합 니 다.JvmRouteBinderValve 가 앞 에 있 는 Apache modjk 에 오류 가 발생 했 을 때 같은 클 라 이언 트 의 요청 이 클 라 이언 트 의 같은 노드 로 보 내 도록 보장 합 니 다. tomcat 공식 문 서 는 이 점 을 어떻게 실현 하 는 지 설명 하지 않 았 고 필 자 는 이 설정 이 그다지 실용성 이 없 는 것 같다 고 생각 합 니 다.
 
     Deployer 는 클 러 스 터 의 farm 기능 에 사용 되 고 응용 프로그램 에서 파일 의 업 데 이 트 를 감시 하 며 클 러 스 터 의 모든 노드 응용 프로그램의 일치 성 을 확보 합 니 다. 예 를 들 어 특정한 사용자 가 클 러 스 터 의 특정한 노드 의 응용 프로그램 디 렉 터 리 에 파일 을 업로드 하면 Deployer 는 이 동작 을 감지 하고 이 파일 을 클 러 스 터 의 다른 노드 와 같은 응용 디 렉 터 리 에 복사 하여 모든 응용 프로그램의 일치 성 을 유지 합 니 다.이것 은 상당히 강력 한 기능 이지 만 안 타 깝 게 도 tomcat 클 러 스 터 는 현재 이 점 을 하지 못 하고 개발 자 들 이 이 를 실현 하려 고 노력 하고 있 습 니 다. 이곳 의 설정 은 하나의 인터페이스 만 남 겨 두 었 을 뿐 입 니 다.
 
    Listener 는 클 러 스 터 의 노드 가 보 내 고 받 은 데 이 터 를 추적 하 는 데 사용 되 며 Valve 와 유사 한 기능 도 있 습 니 다.
 
    tomcat 클 러 스 터 실현 모델 을 대체적으로 알 게 된 후에 클 러 스 터 에 대해 더욱 최적화 된 설정 을 할 수 있 습 니 다. tomcat 는 설정 을 추 천 했 습 니 다. Delta Manager 보다 효율 적 인 BackupManager 를 사 용 했 고 ReplicationValve 에 대해 필 터 를 요청 하 였 습 니 다. 한 서버 에 여러 노드 를 설치 할 때 Receiver 의 검색 포트 를 수정 해 야 합 니 다. 또한,노드 간 에 데 이 터 를 더욱 효율적으로 복사 하기 위해 모든 tomcat 노드 는 같은 설정 을 사용 하 는 것 이 좋 습 니 다. 구체 적 인 설정 은 다음 과 같 습 니 다.
 
     

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
                 channelSendOptions="6">

          <Manager className="org.apache.catalina.ha.session.BackupManager"
                   expireSessionsOnShutdown="false"
                   notifyListenersOnReplication="true"
                   mapSendOptions="6"/>

          <Channel className="org.apache.catalina.tribes.group.GroupChannel">
            <Membership className="org.apache.catalina.tribes.membership.McastService"
                        address="228.0.0.4"
                        port="45564"
                        frequency="500"
                        dropTime="3000"/>
            <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                      address="auto"
                      port="5000"
                      selectorTimeout="100"
                      maxThreads="6"/>

            <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
              <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
            </Sender>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
          </Channel>

          <Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
                 filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/>

          <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
                    tempDir="/tmp/war-temp/"
                    deployDir="/tmp/war-deploy/"
                    watchDir="/tmp/war-listen/"
                    watchEnabled="false"/>

          <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
        </Cluster>

    
     Tomcat 클 러 스 터 는 Session 데 이 터 를 복사 할 수 있 을 뿐만 아니 라 Context 속성 복사 도 할 수 있 습 니 다. context. xml 의 Context 설정 을 수정 하면 이 루어 집 니 다. < Context className = "org. apache. catalina. ha. context. Replicated Context" / > 를 사용 하여 기본 Context 를 교체 하면 됩 니 다. 물론 distributable = "true" 속성 도 추가 할 수 있 습 니 다.
 
     다음은 가상의 장면 을 통 해 tomcat 군집 이 어떻게 일 하 는 지 설명 하고 군집 은 기본 설정 을 사용 하 며 t1 과 t2 두 개의 tomcat 루틴 으로 구성 되 며 장면 은 시간 순서에 따라 배열 된다.
1. t1 시작
     t1 표준 tomcat 에 따라 시작 합 니 다. Host 대상 이 생 성 되 었 을 때 하나의 Cluster 대상 (기본 설정 은 Simple Tcp Cluster) 도 이 Host 대상 과 동시에 연 결 됩 니 다.웹. xml 에 distributable 을 설정 하면 Tomcat 는 이 를 위 한 컨 텍스트 환경 을 Delta Manager 로 만 듭 니 다.Simple Tcp Cluster 는 membership 서비스 와 Replication 서 비 스 를 시작 합 니 다 (tcp 연결 을 만 드 는 데 사용).
2. t2 시작 (t1 시작 완료 후)     먼저 t2 는 t1 과 같은 동작 을 수행 하고 Simple Tcp Cluster 는 t1 과 t2 로 구 성 된 membership 을 만 듭 니 다.이 어 t2 는 클 러 스 터 에서 시 작 된 서버 인 t1 에 Session 데 이 터 를 요청 합 니 다. t1 이 t2 의 복사 요청 에 응 하지 않 으 면 t2 는 60 초 후에 time out 이 됩 니 다.Session 데이터 복사 가 완료 되 기 전에 t2 는 클 라 이언 트 의 http 또는 mod 를 받 지 않 습 니 다.jk / ajp 요청.
3. t1 http 요청 접수, 세 션 s1 생 성     t1 은 클 라 이언 트 요청 에 정상적으로 응답 하지만 t1 에서 결 과 를 클 라 이언 트 에 보 낼 때 ReplicationValve 는 현재 요청 을 차단 합 니 다. (filter 에 차단 할 필요 가 없 는 요청 형식 이 설정 되 어 있 으 면 이 단 계 는 진행 되 지 않 습 니 다. 기본 설정 에서 모든 요청 을 차단 합 니 다) 현재 세 션 을 업데이트 하 십시오.Replication 서 비 스 를 호출 하여 tcp 연결 을 만 들 고 session 을 membership 목록 의 다른 노드 인 t2 로 복사 하여 결 과 를 클 라 이언 트 에 게 되 돌려 줍 니 다.복사 할 때 현재 세 션 에 저 장 된 정렬 가능 한 모든 대상 은 업데이트 가 발생 하 는 부분 만 복사 되 는 것 이 아 닙 니 다.
4. 붕괴     t1 이 무 너 지면 t2 는 t1 이 클 러 스 터 에서 종료 되 었 음 을 알 리 고 t2 는 t1 을 자신의 membership 목록 에서 삭제 합 니 다. t2 에서 발생 한 Session 업 데 이 트 는 t1 로 복사 하지 않 으 며 부하 이퀄 라이저 는 후속 http 요청 을 모두 t2 에 전달 합 니 다.이 과정 에서 모든 세 션 데 이 터 를 잃 어 버 리 지 않 습 니 다.
5. t2 s1 요청 접수     t2 는 s1 의 요청 에 정상적으로 응답 합 니 다. t2 는 s1 의 모든 데 이 터 를 저장 하고 있 기 때 문 입 니 다.
6. t1 다시 시작     절차 1, 2 와 같은 조작 으로 시작 하여 클 러 스 터 에 가입 하여 t2 에서 모든 세 션 데 이 터 를 복사 하고 복사 가 완료 되면 http 와 mod 를 엽 니 다.jk / ajp 포트 수신 요청.
7. t1 수신 요청, s1 실효     t1 s1 에서 온 요청 을 계속 받 고 s1 을 만 료 로 설정 합 니 다.여기 서 만 료 된 것 은 s1 이 비 활동 상태 에서 설 정 된 시간 을 초과 한 것 이 아니 라 로그아웃 과 같은 작업 을 수행 하여 발생 하 는 Session 이 효력 을 잃 었 기 때 문 입 니 다.이때 t1 은 s1 의 모든 데 이 터 를 보 내 는 것 이 아니 라 s1 expired 와 유사 한 메시지 입 니 다. t2 는 메 시 지 를 받 은 후에 도 s1 을 만 료 로 설정 합 니 다.
8. t2 수신 요청, 세 션 s2 생 성     절차 3 과 같다.
9. 기한 이 지나다     시간 초과 로 인 한 Session 실효 t1 에 대해 서 는 t2 에 알 릴 필요 가 없습니다. t2 역시 s2 가 시간 을 초과 했다 는 것 을 알 고 있 기 때 문 입 니 다.따라서 tomcat 클 러 스 터 에 있어 매우 중요 합 니 다. 모든 노드 의 운영 체제 시간 이 일치 해 야 합 니 다!그렇지 않 으 면 어떤 노드 의 Session 이 만 료 되 었 고 다른 노드 에서 이 Session 은 여전히 활동 상태 에 있 는 현상 이 나타 날 것 이다.