문제

호스팅 제공업체에서 임대한 전용 루트 서버 2개를 사용할 계획입니다.해당 머신은 클러스터에서 tomcat 6을 실행합니다.나중에 컴퓨터를 추가할 경우 해당 컴퓨터가 다른 서브넷에 위치하므로 멀티캐스트로 액세스할 수 없을 것입니다.

멀티캐스트 없이 tomcat을 실행할 수 있나요?Tomcat 6 클러스터링에 대한 모든 튜토리얼에는 멀티캐스트 하트비트가 포함되어 있습니다.SimpleTcpCluster에 대한 대안이 있습니까?

아니면 이 상황에 다른 대안이 더 적합합니까?

도움이 되었습니까?

해결책

두 서버 사이의 거리를 제어하지 않고 (두 개의 다른 데이터 센터에있을 수 있음) 전용 서버 인터 커뮤니케이션 라인이 없으면, 라운드 로빈 DNS 또는 www1.yourdomain으로 리디렉션하는로드 밸런서를 통해 실행하고 싶습니다. .xxx 또는 www2.yourdomain.xxx를 신중하게 처리합니다.

서버가 서로 크게 통신하는 경우 아키텍처를 변경하거나 응용 프로그램에서 지옥을 하나의 서버에서 "맞추기"(적어도 잠시 동안)로 최적화하거나 위치를 제어하여 전용 호스팅을 위해 이동할 수 있습니다. 서버의 거리 및 케이블 링. 그렇지 않으면 서버 간 커뮤니케이션, 심장 박동 등은 커뮤니케이션하는 클라이언트 (예 : 동일한 네트워크 세그먼트)와 동일한 채널을 사용하여 모든 사람을 느리게 할 수 있습니다.

당신이 정말로 많은 짐을 기대하고 있다면 적어도 약간의 돈이 관련되어 있다고 생각합니다. 현명하게 사용하고 컨트롤 또는 전용 라인없이 분산 클러스터링을 설정하는 것보다 어려운 문제를 위해 설정 기술을 사용하십시오.

다른 팁

다른 답변을 제공한 후 질문에 대한 댓글을 보니 귀하의 질문이 무엇인지 궁금합니다...세션 복제에 관한 것인가요?클러스터 통신?문제 자체가 있는 계획된 솔루션보다 문제를 설명하는 것이 더 나을 수도 있습니다.

빠른 답변과 함께 몇 가지 가능한 문제를 설명하겠습니다.

귀하의 애플리케이션은 CPU/RAM을 많이 사용합니다.

  • 프로파일링하고, 최적화하고, 다시 시도하세요
  • 더 크고 더 나은 서버 구입

귀하의 애플리케이션은 대역폭을 많이 사용합니다.

  • 귀하의 질문에서 언급한 저렴한 클러스터링을 사용하면 클라이언트-서버 통신과 동일한 (은폐된) 채널이 서버 간 통신에 사용되므로 상황이 더 악화될 가능성이 높습니다.
  • 다양한 종류의 대역폭을 분리할 수 있습니다.정적 콘텐츠와 다른 서버에서 동적 콘텐츠를 제공함으로써:여기서는 서버 간 통신이 필요하지 않습니다.

귀하의 애플리케이션은 스토리지 집약적입니다.

  • 더 큰 서버를 확보하세요
  • 전용 호스팅을 선택하고 필요한 만큼 회전 디스크를 장착하세요.
  • 다른 모델(예: Amazon S3 스토리지)이 귀하에게 적합한지 확인하세요.)

귀하의 신청서가 슬래시 점으로 표시될 가능성이 높습니다.

  • 위의 요소 중 어떤 요소(또는 기타 요소)가 애플리케이션의 한계를 결정하는지 확인하고 이를 수정하세요.

세션 복제만 필요한가요?

  • Tomcats SessionManager 인터페이스는 작으며 쉽게 직접 구현/확장할 수 있습니다.원하는 세션 복제에 사용하세요.참조 표준관리자 자세한 내용은 문서화 및 구현

더 많은 아이디어

  • EC2(Amazon), Google 서비스 또는 기타 클라우드 컴퓨팅 설정과 같은 보다 유연한 설정을 살펴보세요.자체 클라우드 스토리지 및 서버 간 통신 기능을 활용하세요.이 인프라에 너무 많이 의존하지 않도록 주의하세요.

확실히 뭔가 잊어버린 것이 있지만 이것이 시작점이 될 수 있습니다.더 나은 답변을 얻으려면 근본적인 문제의 성격에 대해 더 구체적으로 설명하십시오. :)

Yale Central Authentication Server (CAS)를 배포하려고 시도하고 있으며 중복을 위해 클러스터링하고 싶습니다. 이것은 중요한 인프라이기 때문입니다. CAS는 사용자가 응용 프로그램 A에 로그인 한 후 단일 서명 도메인에 참여하는 응용 프로그램 B로 탐색 한 후 Application B가 CAS에 요청을 보내서 사용자가 활성 '티켓'이 있는지 여부를 결정하기 때문에 세션을 복제해야합니다. . 티켓을 검증하기 위해 자체적으로 해결 해야하는 응용 프로그램 B에 표시 할 장치가 없으므로 한 노드의 모든 활성 티켓은 클러스터의 모든 노드에 복제되어야합니다. 다시 말해, 사용자의 쿠키에서 티켓을 검증 할 때 응용 프로그램 B는 사용자가 로그인 한 응용 프로그램 A에서 원래 세션의 세션 ID를 알지 못하기 때문에 세션 고집은 해결책이 아닙니다.

따라서 CAS는 세션이 모든 노드에서 복제되어야합니다. 네트워크가 멀티 캐스팅을 지원해야한다는 요구 사항은 사소한 양의 오버 헤드를 추가 하고이 접근법을 배포하기에 약간 무겁습니다. Google 코드 에서이 프로젝트를 테스트했습니다.

http://code.google.com/p/memcached-session-manager

매우 유용하고 간단하게 배포하는 것처럼 보이지만 (적어도 Linux OS에서) 불행히도 세션 장애 조치에만 제공되며 세션 복제 솔루션이 아닙니다.

그냥 사용하십시오 http://code.google.com/p/memcached-session-manager/ . 잘 작동합니다. 우리는 20 개의 Tomcat 서버를 공유하는 세션을 통해이 설정을 위해 수년간 사용하고 있습니다. 세션 복제를 처리 할 수있는 하나 또는 두 개의 멤버프 서버를 가질 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top