Tomcat 7 또는 Glassfish 3.1 (GlassFish 일 수 있지만 아직 결정되지 않았습니다) 중 하나를 사용할 수있는 Java SE 7/Java EE 6 응용 프로그램에서 작업하고 있습니다. 이 응용 프로그램은 최근 모든 주요 브라우저에서 널리 채택 된 새로운 WebSockets 기술을 이용합니다.웹 소켓 + Tomcat/Glassfish + 클러스터 +로드 균형 조정 - 옵션은 무엇입니까?
많은 연구, 포럼 읽기 및 메일 링리스트 모니터링을 통해 (현재, AFAICT) mod_jk/isapi_redirect도 mod_proxy도 웹 소켓을 안정적으로 (또는 전혀) 지원하지 않는다고 결정했습니다. 다음은 Tomcat 또는 GlassFish 클러스터에서로드 균형 조정/트래픽 방향을 지정하기위한 두 가지 테스트를 거친 방법이므로 문제가 있음을 분명히 나타냅니다.
그러나 Tomcat과 GlassFish는 모두 Apache 또는 IIS와 같이 정적 컨텐츠를 효율적으로 제공 할 수 있도록 널리 권장되는 웹 서버가 내장되어 있으므로 일반적으로 Apache 또는 리던던시 /로드 균형 조정이 필요하지 않는 한 이러한 서버 중 하나 앞에있는 IIS.
그래서,이 모든 것이 나에게 이러한 질문에 리드 :
- 아파치인가 또는 톰캣/글래스 피쉬 클러스터의 부하 균형에 더 이상 필요 IIS? Tomcat이나 GlassFish 서버 클러스터 앞에서 표준로드 밸런서를 다른 시나리오처럼 사용하고 중개 웹 서버를 포기하는 것만으로도 효율적이지는 않습니까? 아니면 표준로드 밸런서가 TC/GF에서 작동하지 않는다는 기술적 인 이유가 있습니까? 표준로드 밸런서를 사용할 수 있다고 가정하면, 단순히 코요테와 같은 웹 소켓을 지원하는 브라우저를 찾아서 사용할 수 있습니다.
- 표준로드 밸런서가 Tomcat/GlassFish에서 작동하지 않으면 다른 옵션은 무엇입니까? Java EE를 사용하여 성능이 뛰어나고 안정적인 WebSocket 기술에 어떻게 영향을 미칩니 까?
주의 할 : 나는 (라운드 로빈 (Round-Robin) DNS 등) 바보 라운드 로빈 프로토콜로 제한됩니다로드 밸런싱 기술을 고려하지 선호합니다. 클러스터의 다른 서버보다 훨씬 많은 수의 연결을 처리 중이거나 이미 처리중인 서버로 쉽게 전송할 수 있기 때문에이 옵션을 안정적/중복 적으로 고려하지 않습니다. 분명히 Round-Robin DNS와 같은 것이 호환성 문제없이 WebSockets에 쉽게 사용될 수 있다는 것을 알고 있습니다.
분명히 도움이되었고 SSL을 고려하지 않았습니다. 필자는 F5와 Coyote로드 밸런서가 모두 TLS/SSL에 상당히 뛰어나다는 점을 이해 했으므로 여기서 고려해야 할 사항은 없습니다. 그러나이 과정에서 염두에 두어야 할 기본 정보가 있는지 확인하는 것이 좋습니다. (내가 대답하기 전에 다른 사람이 더 구체적인 세부 사항을 표시하는지 기다릴 것입니다.) –
nginx의 SSL은 tomcat의 SSL보다 얼마나 빠릅니까? – irreputable
@irreputable 우리에겐 속도에 관한 질문이 아니 었습니다. 우리 작전 요원들로부터 이해 한 바에 따르면 관리의 용이성과 우리가 우리의 인증서를 흩어 놓은 장소의 수를 최소화하는 것이 었습니다. 그러므로 나는 속도에 관해 모른다. –