N Apache 서버간에 들어오는 웹 트래픽의 균형을 맞추려면 어떻게해야합니까?

내부 아파치 인스턴스간에 들어오는 트래픽 양의 균형을 맞추기 위해 하트 비트 / 오징어 / 바니시 / 등과 같은 것을 사용하려고합니다. 내 물건이 모두 VPS에서 실행되므로 하드웨어가 아닌 소프트웨어 여야합니다. 이 분야에 대한 경험이 많지 않으므로 용어를 잘못 사용하고 잘못된 패키지를 선택하는 경우 미안합니다.

나는 내가 무엇을하고 있는지 설명하기 위해 무언가를 작성했습니다. 녹색은 초기 설정의 모습이고, 파란색은 트래픽 증가로 인해 더 많은 아파치 인스턴스를 추가 한 후의 모습입니다. 이것이 이런 방식으로 작동하지 않을 수도 있지만 이상적으로는 밸런서의 IP를 도메인의 DNS에 추가합니다. 그런 다음 밸런서는 각 아파치 인스턴스에 몇 개의 연결이 있는지 (내부 IP 또는 영구 IP의 일부 구성 목록을 통해) 확인하고 연결을 균등하게 분배합니다. 파란색에는 어떤 시점에서 밸런서도 도움이 필요하다고 확신하는 두 번째 밸런서가 있습니다.

어쩌면 나는이 잘못에 대해 가고 있지만, "밸런서 / s"가 무엇인지, 설정 방법에 대한 모범 사례에 대한 도움을 찾고 있습니다.

어떤 도움이라도 좋을 것입니다.

"역 프록시"는 당신이 원하는 것을 할 것입니다.

예를 들어, Varnish, Pound 및 HAProxy는 모두 자신이하는 일에 능숙하지만 차이점도 있습니다. 그러나 요청한 내용에 대해서는 그들 모두 할 것입니다. 개인적으로, 나는 당신이 HAProxy를 사용하는 것이 가장 좋을 것이라고 생각하지만, 그것은 단지 추측 일뿐입니다.

필요한 종류를 결정하는 데 도움이되는로드 밸런서에 대한 기사를 읽는 것이 가장 좋습니다. http://1wt.eu/articles/2006_lb/

또한 Amazon Elastic Compute Cloud에서 소프트웨어를 실행하고 Elastic Load Balancing을 사용하는 등 사전 구축 된 서비스 사용을 고려할 수 있습니다.

처음에는 응답해야 할 중요한 질문이 있습니다.
사용자 세션을로드 밸런서에서 처리하고 항상 동일한 웹 서버로 이동해야합니까 (생존하는 경우)?

• 세션이 필요하지 않습니다 .이 경우 효율적인 nginx 프로그램을로드 밸런서로 사용해야합니다 . 구성은 설정하기 쉽습니다. 기본적으로 upstream upstream_name { server1, ..., serverN }명령문 에 웹 서버 목록 만 표시하면 주어진 도메인에 대해 간단한 proxy_pass upstream_name지시문 이 필요합니다 . Nginx 위키를
  참조하십시오 .

• session required 세션 ID ( )를 호스팅 할 쿠키 이름을 표시 한 다음 모든 서버 에 대한 목록을 표시하는 파운드 와 비슷한 설정이 있습니다. 예 를 들어, 파운드 설정 예를 참조하십시오 .ID MYCOOKIENAMEBACKEND
  

여러로드 밸런서가 필요한 heartbeat경우 하나의 밸런서 만 주어진 도메인에 대해 가상 IP를 마운트하도록합니다 (세션이 필요한 경우 또는 둘 다 마운트하고 두 개의 IP 주소로 DNS에 피드). 예). 아마도 도구가 빠르게 발전함에 따라 필요할 때 다른 질문에 자세히 설명되어있을 것입니다. 예를 들어이 링크 를
참조하십시오 .

아키텍처에 추가적인 복잡성과 단일 실패 지점을 도입 할만한 충분한 이유가 필요합니다.

라운드 로빈로드 밸런싱

• 비용이 들지 않습니다
• 구현 및 관리가 간단합니다.
• 클라이언트에서 장애 조치를 구현합니다. 장애를 안정적으로 감지 할 수있는 유일한 곳
• 서버 선호도를 암시 적으로 지원하지만 고정 세션과 관련된 세션 관리 문제없이 여전히 장애 조치를 허용합니다.
• 클러스터 노드에서 추가 소프트웨어 / 하드웨어 / 구성이 필요하지 않음

라운드 로빈에 관한 잘못된 정보의 양이 놀랍습니다. 내가 냉소적 인 사람이라면 큰 고가의로드 밸런싱 하드웨어를 생산하는 공급 업체와 관련이 있는지 궁금 할 것입니다.

내가 인정할 유일한 요점은

1. IPV4 주소는 드물어지면서 비싸지 만 여전히 비쌉니다. Cisco CSS보다 훨씬 저렴합니다.

2. 인터넷은 점점 웹 서비스에서 실행되며 모든 개발자 가 사양 에 따라 DNS 지원을 구현하는 것은 아닙니다 . 그러나 내가 사용한 모든 브라우저는 정상적으로 작동합니다.

여기에서 퀘스트를 시작하십시오 : http://httpd.apache.org/docs/2.1/mod/mod_proxy_balancer.html 및 http://www.barneyb.com/barneyblog/2009/02/26/apache-httpds-mod_proxy_balancer/

밸런서의 경우 http://www.linuxvirtualserver.org/ 에서 LVS를 살펴볼 수 있습니다. 트래픽을 지시하고 장애 조치를 수행하기 위해 ldirectord 및 하트 비트를 실행할 수 있습니다.

Nginx 는 업스트림 프록시로 훌륭합니다. 매일 1M + 고유를 수행하는 구성에서 큰 성공을 거두었습니다.

좋아, 이것은 잠시 후에 물었다. 그리고 나는 파티에 늦었다. 여전히 여기에 추가해야 할 것이 있습니다.

재키, 당신은 거의 그것을 못 박았습니다. 그림은 대부분의 중소 규모 설치에서로드 밸런싱을 처리하는 방법을 보여줍니다.

Nakedible이 연결된 Willy Tarreau 의 로드 밸런싱 소개 를 읽어야합니다. 여전히 유효하며 좋은 소개입니다.

이러한 요구 사항을 충족시키는 방법을 고려해야합니다.

• TCP / IP 레벨로드 밸런서 (Linux Virtual Server 등). 연결 당 최저 비용, 최고 속도는 HTTP를 "볼"수 없습니다.
• HTTP 레벨로드 밸런서 (HAProxy, nginx, Apache 2.2, Pound, Microsoft ARR 등) 더 높은 오버 헤드, HTTP를 볼 수 있고, HTTP를 압축하고, SSL을 수행하고, 고정 세션로드 밸런싱을 수행 할 수 있습니다.
• HTTP 리버스 프록시 (Apache Traffic Server, Varnish, Squid). 캐시 가능한 객체 (일부 웹 페이지, css, js, 이미지)를 RAM에 저장하고 백엔드 웹 서버를 사용하지 않고 후속 클라이언트로 전달할 수 있습니다. L7 HTTP로드 밸런서와 동일한 작업을 수행 할 수있는 경우가 종종 있습니다.

어느 시점에서 밸런서도 도움이 필요하다고 확신 할 때 두 번째 밸런서가 있습니다.

물론 이죠 그러나로드 밸런싱은 간단하고, 종종 하나의 부하 분산 갈 수있는 빠른 . 현대의 단일 서버 가 제공 할 수 있는 성능에 대한 예일뿐,이 기사에 링크하여 웹에 신경을 썼습니다 . 여러 LB를 사용하기 전에 사용하지 마십시오. 일반적인 접근 방식이 필요한 경우 맨 앞에 IP 레벨로드 밸런서 (또는 DNS 라운드 로빈)가 있고 HTTP 레벨로드 밸런서로 이동하고 프록시 및 웹 애플리케이션 서버로 이동합니다.

"밸런서"가 무엇인지, 설정 방법에 대한 모범 사례에 도움이됩니다.

문제 지점은 세션 상태 처리이며 어느 정도는 실패 상태 동작입니다. 로드 밸런서 자체를 설정하는 것은 비교적 간단합니다.

백엔드 웹앱 서버를 2-4 개만 사용하는 경우 원본 IP 주소를 기반으로하는 정적 해싱을 실행할 수 있습니다. 이를 통해 웹 애플리케이션 서버간에 공유 세션 상태가 필요하지 않습니다. 각 webapp 노드는 전체 트래픽의 1 / N을 보며 고객-서버 매핑은 정상 작동시 정적입니다. 큰 설치에는 적합하지 않습니다.

이 가장 부하 분산 알고리즘은, 그들이, 높은 부하에도 하중 분포에 따라 양성 동작을한다는 의미에서 라운드 로빈 진정한 무작위로드 밸런싱입니다. 이 두 가지 모두 웹 애플리케이션에 웹 애플리케이션 노드에서 사용 가능한 글로벌 세션 상태가 있어야합니다. 이 작업을 수행하는 방법은 webapp 기술 스택에 따라 다릅니다. 그러나 일반적으로 사용할 수있는 표준 솔루션이 있습니다.

정적 해싱이나 공유 세션 상태가 적합하지 않은 경우 일반적으로 ' 고정 세션 '로드 밸런싱 및 서버 별 세션 상태를 선택합니다. 대부분의 경우 이것은 잘 작동하며 완전히 실행 가능한 선택입니다.

밸런서는 각 아파치 인스턴스에 몇 개의 연결이 있는지 (내부 IP 또는 영구 IP의 일부 구성 목록을 통해)보고 연결을 동일하게 분배합니다.

예, 일부 사이트에서이 기능을 사용합니다. 존재하는 다양한로드 밸런싱 알고리즘 에는 많은 이름 이 있습니다. 라운드 로빈 또는 무작위 (또는 가중 라운드 로빈, 가중 무작위)를 선택할 수 있다면 위에서 언급 한 이유로 그렇게하는 것이 좋습니다.

마지막으로 : 많은 공급 업체 (F5, Cisco 및 고급, FX Coyote Point 및 Kemp Technologies의 다른 합리적인 가격)가 성숙한로드 밸런싱 어플라이언스를 제공한다는 사실을 잊지 마십시오 .