HAProxy

— 이강우 2017/09/25 11:58

• 홈페이지 : http://www.haproxy.org/

• HAProxy용 WEB Dashboard https://github.com/roxy-wi/roxy-wi

• HAProxy 설정 예제
• HAProxy SSL 설정

• https://serversforhackers.com/c/letsencrypt-with-haproxy
• http://zephlee2.blogspot.com/2016/06/haproxy-lets-encrypt.html
• https://serverfault.com/questions/560978/configure-multiple-ssl-certificates-in-haproxy

• https://www.haproxy.com/blog/layer-4-load-balancing-direct-server-return-mode/

HAProxy는 아래 나열된 특정 제품과 상당히 잘 통합되므로 HAProxy와 직접 관련이없는 경우에도 여기 언급됩니다.

Apache는 사실상의 표준 HTTP 서버입니다.
파일 서비스와 동적 컨텐츠를 모두 지원 하는 매우 완전하고 모듈화 된 프로젝트입니다. 일부 응용 프로그램 서버 의 프런트 엔드 역할을 할 수 있습니다. 프록시 요청 및 캐시 응답의 경우도 포함됩니다. 일반적으로 이러한 모든 사용 사례에서 전면 로드밸런서가 필요합니다.

아파치는 다양한 모드로 작동 할 수 있으나 다른 것들에 비해 무겁습니다. 특정 모듈은 여전히 ​​더 무거운 Pre-forked 모델을 필요로하기때문에 Apache 가 많은 수의 연결로 확장 하기가 어려울 것입니다. 이 경우 HAProxy는 서버 별 연결 제한을 안전한 값으로 적용하여 엄청난 도움을 제공 할 수 있으며 서버 속도를 크게 높이고 리소스를 보존합니다.

Apache는 mod_rpaf 확장 모듈을 사용하여 X-Forwarded-For 헤더에서 클라이언트의 주소를 추출 할 수 있습니다. HAProxy는 option forwardfor 옵션이 설정 되어있으면 이 헤더를 자동으로 제공 합니다. HAProxy는 또한 인터넷에 노출되었을 때 Apache에 대한 훌륭한 보호 기능을 제공 할 수 있습니다. Apache 는 다양한 종류의 DoS에 더 잘 대처할 수 있습니다.

NGINX는 사실상 두 번째 표준 HTTP 서버입니다. Apache와 마찬가지로 다양한 기능을 제공합니다. NGINX는 HAProxy와 유사한 모델을 기반으로 구축되었으므로 수만 개의 동시 연결을 처리하는 데 아무런 문제 가 없습니다.
일부 응용 프로그램 (예 : 포함 된 PHP FPM 사용)의 게이트웨이로 사용되는 경우 PHP 응용 프로그램의 부하를 줄이기 위해 일부 프론트 엔드 연결 제한을 설정하는 것이 유용 할 수 있습니다. HAProxy는 일반 로드 밸런서와 트래픽 조절기로서 PHP를 decongestion하여 PHP 속도를 향상 시키는 데 유용 합니다. 또한 두 제품 모두 이벤트 기반 아키텍처로 인해 CPU 사용량이 거의 없기 때문에 두 시스템을 동일한 시스템에 쉽게 설치할 수 있습니다. NGINX는 HAProxy의 PROXY 프로토콜을 구현하므로 HAProxy가 클라이언트의 연결 정보를 NGINX 로 전달 하여 응용 프로그램이 모든 관련 정보를 쉽게 얻을 수 있습니다. 일부 벤치 마크에서는 대규모 정적 파일 처리의 경우 NGINX 앞에있는 HAProxy에서 일관된 해시를 구현 하는 것이 기본적으로 서버 노드 수를 곱한 OS의 캐시 적중률을 최적화하여 유용 할 수 있음을 보여주는 벤치 마크가 있습니다 .

Varnish는 스마트 캐싱 역방향 프록시이며 웹 응용 프로그램 가속기 로 가장 잘 묘사됩니다. Varnish는 SSL / TLS를 구현하지 않으며 모든 CPU 사이클을 최상의 성능 으로 바치 려고합니다. 또한 Varnish는 HAProxy가 SSL 오프 로더 및로드 밸런서로 매우 쉽게 배치되어 모든 관련 클라이언트 정보를 전달할 수 있도록 HAProxy의 PROXY 프로토콜을 구현 합니다. 또한 Varnish 는 서버가 압축 된 객체를 제공하지만 압축하지는 않지만 자연스럽게 캐시에서 압축 해제를 지원합니다.
백엔드 서버가 압축을 구현하지 않을 때 HAProxy 를 사용하여 나가는 데이터를 압축 할 수 있지만 로드 밸런서를 압축하는 것은 거의 불가능합니다.

HAProxy는 여러 노드에 걸쳐 대규모 캐싱 팜을 구축 할 때 일관된 URL 해싱을 사용 하여 캐싱 노드에로드를 지능적으로 분산시키고 캐시 복제를 피할 수 있으므로 모든 캐싱 노드 의 합계 인 전체 캐시 크기가 됩니다.

Linux 커널에 포함된 L4 로드 밸런서 입니다. 패킷 레벨에서 작동하며 TCP 및 UDP를 처리합니다. L7 기능이 필요하지 않은경우 가장 쉽게 사용할 수 있습니다.
http://www.linuxvirtualserver.org/

HAProxy 보다 기능 이 훨씬 간단하고 훨씬 간단 하지만 많은 기본 설정에서 이 둘을 사용할 수 있습니다. 이 솔루션의 개발자는 기능보다는 성능과 안정성에 최우선을 두고 있습니다. 스레드 기반 아키텍처라서 연결 수가 많을 때 확장성이 떨어지지만 좋은 제품입니다.
http://www.apsis.ch/pound/

펜은 꽤 가벼운 로드 밸런서입니다. SSL을 지원하고, 고정 크기의 클라이언트의 IP 주소 테이블을 가지고 있습니다. 패킷 지향(Packet-Oriented) 모드를 지원하여 DSR(Direct Server Return)과 일부 범위의 UDP를 지원할 수 있습니다. 따라서 매우 적은 부하를 가지게 됩니다.
(지속성 테이블이 오직 2048개만 유지)
http://siag.nu/pen/