로드 밸런서 뒤에있는 두 서버 간의 단방향 동기화에 대한 일부 구성 변경 사항을 테스트하려고합니다 (모두 Rackspace Cloud 인프라 FYI 임). 내가 가진 문제는 주어진 IP가 항상로드 밸런서의 IP이기 때문에로드 밸런싱 된 서버를 알 수 없다는 것입니다.
내가 실제로 어떤 서버로 향했는지 알 수있는 간단한 방법이 있습니까? 기술적이지 않은 팀 구성원도 비교적 쉽게 문제를보고 할 수 있지만 최선의 접근 방식에 대한 아이디어는 감사 할 것이므로 브라우저에서 이상적으로 좋아합니다.
추가 정보 : 두 서버 모두 Apache를 실행하고로드 밸런서에 세션 지속성이 구성되어 있습니다.
답변:
신중하게하려면 웹 서버가 Server:응답 헤더 ( RFC 2616 Sec 14.38 ) 에서 자신을 식별 하도록 하십시오. 예를 들어 Apache에서는 해당 헤더에 반환 된 정보가 ServerTokens지시문에 의해 제어됩니다 . 그런 다음 Firebug , Chrome DevTools 또는 Safari Web Inspector 타임 라인 에서 응답 헤더를 검사하기 만하면 됩니다.
명백하게 명확하게하려면 웹 응용 프로그램에서 서버 이름을 표시되는 텍스트로 생성 된 페이지에 포함시킬 수 있습니다. HTML 주석으로 서버 이름을보고 할 수도 있는데,이 경우 소스보기가 필요합니다.
사용중인 프로토콜을 지정하지 않았으므로 https를 말하는 것으로 가정합니다.
각 백엔드는 아마도 그 백엔드를 고유하게 식별하는 정보에 대해 알고있을 것입니다. 호스트 이름 또는 유니 캐스트 IP 주소 일 수 있습니다. 백엔드는 해당 정보를 적절한 위치에 포함 할 수 있습니다. 각 페이지의 바닥 글에 포함시킬 수 있습니다. 또는 너무 눈에 띄는 것으로 판단되면 일반적인 상황에서 사용자가 방문하지 않는 페이지에만 포함하십시오. 모든 오류 페이지 (404, 500 등)에는 항상 백엔드 식별이 포함되어야합니다.
로드 밸런서가로드 밸런싱 만하고 다른 작업을 수행하지 않는 경우 백엔드에서 https를 종료하고 TCP 연결이 닫히고 클라이언트가 다시 연결될 때마다 클라이언트가 다른 백엔드로 연결될 수 있습니다.
로드 밸런서는 동일한 백엔드를 대부분 재사용하기 위해 지난 1 시간 내에 표시된 모든 클라이언트 IP 주소에 대해 가장 최근에 사용한 백엔드를 기억할 수 있습니다. 쿠키 및 사용자 ID와 같은 더 자세한 정보는로드 밸런서에 도달 할 수 없으므로 사용자를 동일한 백엔드에 유지하는 데 사용할 수 없습니다.
즉, 사용자가 문제를 경험 한 시간과 사용중인 백엔드를 찾은 시간 사이에 사용자가 백엔드간에 이동할 수 있으므로 사용자가 사용하는 백엔드를 식별하려면 소금 한 알을 사용해야합니다. 그러나 대부분의 경우 관련 로그를 더 빨리 찾는 데 도움이되므로 여전히 유용한 정보입니다.