예산에 아파치로드 밸런싱?

수백만 명의 사용자에게 블리 스터링 속도를 제공하기 위해로드 밸런싱이 아니라로드 밸런싱 개념을 중심으로로드 밸런싱 개념을 이해하려고 노력하고 있습니다.

우리는 예산을 책정하고 많은 지식이있는 것들을 고수하려고 노력하고 있으므로 우분투 VPS에서 Apache를 실행하면 유명한 검색 엔진이 우리를 얻을 때까지 전략처럼 보입니다 ( 토요 아이러니 포함, 참고 ).

적어도 나에게는 다양한 솔루션의 완벽한 정글입니다. Apaches 자체의 mod_proxy 및 HAproxy는 빠른 Google 검색에서 찾은 두 가지이지만로드 밸런싱 경험이 전혀 없으므로 상황에 적합한 것이 무엇인지, 또는 해결하기 위해 솔루션을 선택할 때 살펴볼 내용이 무엇인지 모릅니다. 가용성 문제.

우리에게 가장 좋은 방법은 무엇입니까? 예산 범위 내에서 가용성을 높이려면 어떻게해야합니까?

내가 사용하고 VPS로 쉽게 구현할 수있는 솔루션은 다음과 같습니다.

• DNS는 6 개의 유효한 IP 주소로 라운드 로빈 (sp?)됩니다.
• 구성이 동일하고 corosync / pacemaker 를 사용 하여 6 개의 IP 주소를 균등하게 분배하는 3 개의로드 밸런서가 있습니다 (따라서 각 컴퓨터에 2 개의 주소가 부여됨).
• 각로드 밸런서에는 nginx + varnish 구성이 있습니다. Nginx는 연결 수신 및 재 작성 및 일부 정적 서빙을 수행하고로드 밸런싱 및 캐싱을 수행하는 Varnish로 다시 전달합니다.

이 아치는 편견에 따라 다음과 같은 장점이 있습니다.

1. corosync / pacemaker는 LB 중 하나가 실패 할 경우 IP 주소를 재배포합니다.
2. nginx는 캐시 (큰 비디오, 오디오 또는 큰 파일)를 사용하지 않고 파일 시스템 또는 NFS에서 직접 특정 유형의 파일 인 SSL을 제공하는 데 사용할 수 있습니다.
3. 바니시는 무게, 백엔드 상태 확인을 지원하는 매우 우수한로드 밸런서이며 리버스 프록시로 뛰어난 역할을합니다.
4. 트래픽을 처리하기 위해 더 많은 LB가 필요한 경우 클러스터에 시스템을 추가하기 만하면 IP 주소가 모든 시스템간에 재조정됩니다. 자동으로 수행 할 수도 있습니다 (로드 밸런서 추가 및 제거). 그렇기 때문에 3 대의 머신에 6 개의 ip를 사용하여 성장을위한 공간을 확보했습니다.

귀하의 경우 물리적으로 분리 된 VPS를 갖는 것이 좋은 생각이지만 IP 공유를 더욱 어렵게 만듭니다. 목표는 내결함성, 중복 시스템 및로드 밸런싱 / HA를위한 일부 구성으로 인해 단일 트래픽 지점을 수신하는 단일로드 밸런서와 같은 단일 장애 지점을 추가하는 것입니다.

나는 또한 당신이 아파치에 대해 물었다는 것을 알고 있지만, 그 당시 우리는 작업에 더 적합한 특정 도구 (nginx 및 varnish)를 가지고 있습니다. 아파치가 백엔드에서 응용 프로그램을 실행하고 다른 도구를 사용하여 서비스를 제공하도록 남겨 두십시오 (아파치가로드 밸런싱이나 리버스 프록시를 제대로 수행 할 수없는 것은 아닙니다) 공유).

HAproxy는 좋은 솔루션입니다. 구성은 매우 간단합니다.

최소 2 개의 다른 VPS 앞에 앉아 또 다른 VPS 인스턴스가 필요합니다. 따라서로드 밸런싱 / 페일 오버를 위해서는 최소 3 VPS가 필요합니다.

고려해야 할 몇 가지 사항은 다음과 같습니다.

1. SSL 종료 HTTPS : //를 사용하는 경우 해당 연결이로드 밸런서에서 종료되고로드 밸런서 뒤에서 모든 트래픽이 암호화되지 않은 연결을 통과해야합니다.

2. 파일 저장 사용자가 이미지를 업로드하면 어디로 이동합니까? 한 대의 컴퓨터에만 앉아 있습니까? 머신간에 즉시 파일을 공유해야합니다. Amazon S3 서비스를 사용하여 모든 정적 파일을 저장하거나 파일 서버 역할을하는 다른 VPS가있을 수 있지만 S3는 중복되고 엄청나게 저렴하기 때문에 권장합니다.

3. 세션 정보. 로드 밸런서 구성의 각 머신은 어떤 머신에 충돌하는지 알 수 없으므로 사용자의 세션 정보에 액세스 할 수 있어야합니다.

4. db-별도의 db 서버가 있습니까? 지금 머신이 하나 뿐인 경우 새 머신이 db 서버에 액세스 할 수 있도록하는 방법과 별도의 VPS db 서버 인 경우 중복되는 방법은 무엇입니까? 하나의 db 서버에서 고 가용성 웹 프론트 엔드와 단일 실패 지점을 갖는 것이 반드시 의미가있는 것은 아니므로 이제 DB 복제 및 슬레이브 승격도 고려해야합니다.

그래서 나는 당신의 신발에 있었고, 그것은 실제 작업에 하루에 수백 명중하는 웹 사이트의 문제입니다. 복잡해집니다. 희망은 당신에게 생각을위한 음식을 줬습니다 :)

내 투표는 로드 밸런서로서 Linux Virtual Server 에 대한 것입니다. 이로 인해 LVS 디렉터는 병목 현상뿐만 아니라 단일 실패 지점이됩니다.

1. 병목 현상은 내 경험상 문제가 아닙니다. LVS 재 지정 단계는 계층 3이며 매우 (계산적으로) 저렴합니다.
2. 단일 실패 지점은 Linux HA에 의해 제어되는 두 개의 디렉터와 함께 두 번째 디렉터를 보유함으로써 처리해야합니다 .

첫 번째 디렉터가 첫 번째 LVS 노드와 동일한 시스템에 있고 두 번째 디렉터가 두 번째 LVS 노드와 동일한 시스템에 있으면 비용을 줄일 수 있습니다. 세 번째 및 후속 노드는 LVS 또는 HA에 영향을주지 않는 순수한 노드입니다.

또한 리디렉션이 응용 프로그램 계층 아래에서 수행되므로 원하는 웹 서버 소프트웨어를 자유롭게 실행할 수 있습니다.

이 체인은 어때?

라운드 로빈 dns> 두 머신 모두에서 haproxy> 정적 파일을 분리하기위한 nginx> Apache

아마도 hacarp 또는 heartbeat를 사용하여 haproxy가 항상 응답하도록하십시오. SSL이 필요한 경우 Stunnel이 haproxy 앞에 앉아 있습니다.

적절한 클러스터링 소프트웨어 사용을 고려할 수 있습니다. 레드햇 (또는 CentOS는) 클러스터 스위트 , 또는 오라클 클러스터웨어 . 이들은 능동-수동 클러스터를 설정하는 데 사용될 수 있으며, 서비스를 다시 시작하고 심각한 문제가있을 때 노드간에 실패하는 데 사용될 수 있습니다. 이것은 본질적으로 당신이 찾고있는 것입니다.

이러한 모든 클러스터 솔루션은 해당 OS 라이센스에 포함되어 있으므로 비용이 많이 들지 않습니다. 여기에는 NFS 마운트 또는 클러스터 파일 시스템이있는 두 노드가 액세스하는 실제 디스크와 같은 공유 스토리지 방식이 필요합니다. 후자의 예는 OCFS2 또는 GFS로 포맷 된 다중 호스트 액세스가 허용 된 SAN 디스크입니다 . VMWare 공유 디스크 를 사용할 수 있다고 생각합니다 .

클러스터 소프트웨어는 노드에서 항상 또는 해당 노드가 '활성'인 경우에만 실행되는 '서비스'를 정의하는 데 사용됩니다. 노드는 하트 비트를 통해 통신하고 해당 서비스를 모니터링합니다. 오류가 발견되면 다시 시작하고, 수정할 수 없으면 다시 부팅 할 수 있습니다.

기본적으로 트래픽이 전달 될 단일 '공유'IP 주소를 구성합니다. 그런 다음 아파치 및 기타 필요한 서비스를 정의하고 활성 서버에서만 실행할 수 있습니다. 공유 디스크는 모든 웹 컨텐츠, 업로드 된 파일 및 Apache 구성 디렉토리에 사용됩니다. (httpd.conf 등)

내 경험상, 이것은 매우 잘 작동합니다.

• DNS 라운드 로빈 또는 기타 단일 장애 지점로드 밸런서가 필요하지 않습니다. 모든 것이 하나의 IP / FQDN에 해당합니다.
• 사용자가 업로드 한 파일은 해당 공유 스토리지로 이동하므로 시스템 장애 조치에 신경 쓰지 않습니다.
• 개발자는 추가 교육 없이도 해당 단일 IP / FQDN에 컨텐츠를 업로드하며, 장애 조치가 발생하면 항상 최신 상태입니다.
• 관리자는 오프라인 시스템을 가져 와서 시스템을 패치하거나 재부팅하는 등의 작업을 수행 할 수 있습니다. 그런 다음 활성 노드를 페일 오버합니다. 다운 타임 최소화를위한 업그레이드.
• 이제 구식 노드는 한동안 패치되지 않은 상태로 유지 될 수있어 페일 백도 마찬가지로 쉬운 프로세스입니다. (VMWare 스냅 샷보다 빠름)
• 관리자가 오프라인 상자에서 변경을 잊어 버렸기 때문에 Apache의 구성 변경 사항이 공유되므로 장애 조치 중에 이상한 일이 발생하지 않습니다.

-크리스토퍼 카렐

최적의로드 밸런싱은 매우 비싸고 복잡 할 수 있습니다. 기본로드 밸런싱은 각 서버가 언제든지 거의 동일한 히트 수를 처리하도록 보장해야합니다.

가장 간단한로드 균형 조정 방법은 DNS에서 여러 A 레코드를 제공하는 것입니다. 기본적으로 IP 주소는 라운드 로빈 방식으로 구성됩니다. 이로 인해 사용자가 서버 전체에 비교적 고르게 분산됩니다. 이것은 상태 비 저장 사이트에 적합합니다. 상태 저장 사이트가있는 경우 좀 더 복잡한 방법이 필요합니다.

상태 저장 요구 사항을 처리하기 위해 리디렉션을 사용할 수 있습니다. 각 웹 서버에 www1, www2, www3 등과 같은 대체 주소를 제공하십시오. 초기 www 연결을 호스트의 대체 주소로 리디렉션하십시오. 이런 방식으로 책갈피 문제가 발생할 수 있지만 서버 전체에 고르게 분산되어 있어야합니다.

또는 다른 경로를 사용하여 상태 저장 세션을 처리하는 서버를 나타내면 호스트를 원래 서버로 전환 한 프록시 세션이 허용됩니다. 장애가 발생한 서버의 세션이 장애가 발생한 서버에서 인계 된 서버에 도착할 때 문제가 될 수 있습니다. 그러나 클러스터링 소프트웨어를 금지하면 상태가 사라집니다. 브라우저 캐싱으로 인해 서버를 변경하는 세션이 많지 않을 수 있습니다.

장애가 발생한 서버의 IP 주소를 인계하도록 서버를 구성하여 장애 조치를 처리 할 수 ​​있습니다. 이는 서버 장애시 다운 타임을 최소화합니다. 클러스터링 소프트웨어가 없으면 서버가 실패하면 상태 저장 세션이 손실됩니다.

장애 조치가 없으면 사용자는 브라우저가 다음 IP 주소로 장애 조치 될 때까지 지연됩니다.

상태 저장 세션보다는 안정된 서비스를 사용하면 프런트 엔드에서 클러스터링 문제를 해결할 수 있습니다. 스토리지 측의 클러스터링 문제는 여전히 적용됩니다.

서버 앞에로드 밸런서가 있더라도 라운드 로빈 DNS가 서버 앞에있을 수 있습니다. 이렇게하면 모든로드 밸런서가 활용됩니다. 추가 복잡성 및 실패 지점과 함께 설계에 다른 계층을 추가합니다. 그러나 일부 보안 기능을 제공 할 수 있습니다.

최상의 솔루션은 관련 요구 사항에 따라 다릅니다.

이미지, CSS 파일 및 기타 정적 컨텐츠와 같은 컨텐츠를 제공하기 위해 이미지 서버를 구현하면 애플리케이션 서버의로드를 쉽게 할 수 있습니다.

나는 보통 한 쌍의 동일한 OpenBSD 머신을 사용한다 :

• 로드 균형 조정, 웹 서버 모니터링 및 실패한 웹 서버 처리에 RelayD를 사용하십시오.
• 로드 밸런서 자체의 고 가용성을 위해 CARP를 사용하십시오.

OpenBSD는 가볍고 안정적이며 매우 안전합니다. 네트워크 서비스에 적합합니다.

• http ://www.openbsd.org-기본 사이트
• http://www.openbsd.org/faq/pf/carp.html- 잉어 문서
• https://calomel.org/relayd.html-RelayD에 대한 적절한 하우투 정보 세트

시작하려면 layer3 설정을 권장합니다. PF (복합 방화벽) 설정을 피합니다. 다음은 백엔드 웹 서버를 모니터링하여 간단한 릴레이로드 밸런서의 설정을 보여주는 /etc/relayd.conf 파일의 예입니다.

# $OpenBSD: relayd.conf,v 1.13 2008/03/03 16:58:41 reyk Exp $
#
# Macros
#

# The production internal load balanced address
intralbaddr="1.1.1.100"

# The interface on this load balancer with the alias for the intralbaddr address
intralbint="carp0"

# The list of web/app servers serving weblbaddress
intra1="1.1.1.90"
intra2="1.1.1.91"

# Global Options
#
# interval 10
timeout 1000
# prefork 5

log updates

# The "relaylb" interface group is assigned to the intralbint carp interface
# The following forces a demotion in carp if relayd stops
demote relaylb

#
# Each table will be mapped to a pf table.
#
table <intrahosts> { $intra1 $intra2 }

# Assumes local webserver that can provide a sorry page
table <fallback> { 127.0.0.1 }

#
# Relay and protocol for HTTP layer 7 loadbalancing and SSL acceleration
#
http protocol httprelay {
        return error
        header append "$REMOTE_ADDR" to "X-Forwarded-For"
        header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
        # header change "Connection" to "close"

        # Various TCP performance options
        tcp { nodelay, sack, socket buffer 65536, backlog 128 }

#       ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
#       ssl session cache disable
}

relay intra-httprelay {
        listen on $intralbaddr port 80
        protocol httprelay

        # Forward to hosts in the intrahosts table using a src/dst hash
        # The example shows use of a page with dynamic content to provide
        # application aware site checking.  This page should return a 200 on success,
        # including database or appserver connection, and a 500 or other on failure
        forward to <intrahosts> port http mode loadbalance \
                check http "/nlbcheck.asp" code 200

}

Cloudfoundry 또는 Elastic Beanstalk 또는 일반 오래된 AWS 자동 스케일링 으로 ec2를 제공 했습니까? 나는 그것을 사용하고 있으며 꽤 잘 확장되며 사람이 개입하지 않고도 탄력적으로 확장 할 수 있습니다.

로드 밸런싱에 대한 경험이 전혀 없다고 가정 할 때, 이러한 옵션은 시작 및 실행에 최소한의 두뇌 "튀김"이 필요하므로 제안합니다.

시간을 잘 활용하는 것이 좋습니다.