클러스터링, 분산 및 로드 밸런싱의 차이점은 무엇입니까? (사진과 텍스트)-PHP 튜토리얼-php.cn

PHP에는 클러스터링, 배포 및 로드 밸런싱 사이에 큰 차이점이 있습니다. 다음 기사에서는 클러스터링, 배포 및 로드 밸런싱의 구체적인 차이점에 대해 자세히 설명하겠습니다. .

클러스터의 개념

컴퓨터 클러스터는 느슨하게 통합된 컴퓨터 소프트웨어 및/또는 하드웨어 세트를 통해 연결되어 매우 긴밀하게 협력하여 컴퓨팅 작업을 완료합니다. 어떤 의미에서는 컴퓨터라고 생각할 수 있습니다. 클러스터형 시스템의 개별 컴퓨터는 일반적으로 노드라고 불리며 일반적으로 LAN(Local Area Network)을 통해 연결되지만 다른 연결도 가능합니다. 클러스터 컴퓨터는 단일 컴퓨터의 컴퓨팅 속도 및/또는 안정성 을 향상시키는 데 사용되는 경우가 많습니다. 일반적으로 클러스터 컴퓨터는 워크스테이션이나 슈퍼컴퓨터와 같은 단일 컴퓨터보다 훨씬 비용 효율적입니다.
예를 들어, 단일 과부하 작업은 병렬 처리를 위해 여러 노드 장치 간에 공유되며, 각 노드 장치의 처리가 완료된 후 결과가 요약되어 사용자에게 반환되므로 시스템의 처리 능력이 크게 향상됩니다. 일반적으로 여러 유형으로 나뉩니다.

고가용성 클러스터: 일반적으로 클러스터의 노드에 장애가 발생하면 해당 노드의 작업이 자동으로 다른 노드로 이전됩니다. 일반 노드에서. 이는 또한 클러스터의 노드가 오프라인으로 유지되었다가 다시 온라인으로 전환될 수 있음을 의미합니다. 이 프로세스는 전체 클러스터의 작동에 영향을 주지 않습니다.
로드 밸런싱 클러스터: 로드 밸런싱 클러스터가 실행될 때 일반적으로 하나 이상의 클러스터를 통해 로드됩니다. 프런트 엔드 밸런서는 전체 시스템의 고성능 및 고가용성을 달성하기 위해 백엔드의 서버 그룹에 작업 부하를 분산합니다.
고성능 컴퓨팅 클러스터: 고성능 컴퓨팅 클러스터는 다양한 방법을 사용하여 컴퓨팅 작업을 분산합니다. 컴퓨팅 노드는 컴퓨팅 성능을 향상시키므로 과학 컴퓨팅 분야에서 주로 사용됩니다.

Distributed

클러스터: 동일한 비즈니스가 여러 서버에 배포됩니다. 분산형: 비즈니스가 여러 하위 비즈니스로 분할되거나 서로 다른 서버에 배포된 서로 다른 비즈니스입니다.
간단히 말하면, 분산은 단일 작업의 실행 시간을 단축하여 효율성을 향상시키는 반면, 클러스터링은 단위 시간당 실행되는 작업 수를 늘려 효율성을 향상시킵니다. 예를 들어, Sina.com을 방문하는 사람이 더 많으면 클러스터를 만들고 앞쪽에 밸런싱 서버를 배치하고 뒤쪽에 여러 서버를 배치하여 동일한 비즈니스 액세스를 완료할 수 있습니다. 응답 서버는 어떤 서버가 부하가 높지 않은지 확인하여 어느 서버가 이를 완료할지 할당합니다. 각 분산 노드는 서로 다른 서비스를 완료합니다. 하나의 노드가 무너지면 비즈니스가 실패할 수 있습니다.

로드 밸런싱

Concept

사업 규모의 증가에 따라 기존의 다양한 핵심 부분에 대한 액세스 네트워크 볼륨과 데이터 트래픽의 급속한 증가로 인해 처리 능력과 컴퓨팅 집약도도 그에 따라 증가하여 단일 서버 장치가 이를 감당할 수 없게 되었습니다. 이런 경우 기존 장비를 버리고 하드웨어 업그레이드를 많이 하게 되면 기존 자원의 낭비가 발생하게 되고, 다음번 사업 규모 증가에 직면하게 되면 또 다른 하드웨어 업그레이드에 드는 비용이 높아지게 됩니다. 비용 투자, 아무리 우수한 장비라 할지라도 현재의 사업 규모 성장 요구를 충족할 수 없습니다.
로드 밸런싱 기술은 가상 서버 IP(VIP)를 설정하여 백엔드에 있는 여러 실제 서버의 애플리케이션 자원을 고성능 애플리케이션 서버로 가상화하는 기술로, 로드 밸런싱 알고리즘을 통해 사용자의 요청을 백엔드 인트라넷으로 전달합니다. server 인트라넷 서버는 요청된 응답을 로드 밸런서에 반환하고 로드 밸런서는 사용자에게 응답을 보냅니다. 이렇게 하면 인터넷 사용자가 인트라넷 구조를 숨기고 사용자가 백엔드(인트라넷) 서버에 직접 액세스할 수 없게 됩니다. 핵심 네트워크 스택과 다른 포트에서 실행되는 서비스에 대한 공격을 방지하기 위해 보안이 강화되었습니다. 그리고 로드 밸런싱 장치(소프트웨어 또는 하드웨어)는 서버의 애플리케이션 상태를 지속적으로 확인하고 유효하지 않은 애플리케이션 서버를 자동으로 격리하여 문제를 해결하는 간단하고 확장 가능하며 신뢰성이 높은 애플리케이션 솔루션을 실현합니다. , 확장성이 부족하고 신뢰성이 낮습니다.
시스템 확장은 수직(수직) 확장과 수평(수평) 확장으로 나눌 수 있습니다. 수직적 확장이란 대규모 분산 시스템(웹 사이트)의 요구를 충족할 수 없는 CPU 처리 능력, 메모리 용량, 디스크 등 하드웨어 처리 능력을 높여 단일 머신 관점에서 서버의 처리 능력을 높이는 것입니다. , 대규모 트래픽, 높은 동시성 및 대규모 데이터 문제. 따라서 대규모 웹사이트 서비스의 처리능력에 부응하기 위해서는 기계를 추가하여 수평적 확장방식을 채택할 필요가 있다. 예를 들어, 한 대의 기계가 요구 사항을 충족할 수 없는 경우 두 대 이상의 기계를 추가하여 액세스 압력을 공유합니다.

　로드 밸런싱의 가장 중요한 응용 프로그램 중 하나는 여러 서버를 사용하여 단일 서비스를 제공하는 것입니다 이 솔루션을 서버 팜이라고도 합니다. 일반적으로 로드 밸런싱은 주로 웹 웹 사이트, 대규모 인터넷 릴레이 채팅 네트워크, 트래픽이 많은 파일 다운로드 웹 사이트, NNTP(Network News Transfer Protocol) 서비스 및 DNS 서비스에서 사용됩니다. 이제 로드 밸런서는 데이터베이스 로드 밸런서라고 불리는 데이터베이스 서비스도 지원하기 시작합니다.
　 서버 로드 밸런싱에는 로드 밸런싱 알고리즘, 상태 확인 및 세션 유지 관리의 세 가지 기본 기능이 있습니다. 이 세 가지 기능은 로드 밸런싱의 정상적인 작동을 보장하는 기본 요소입니다. 다른 기능 중 일부는 이 세 가지 기능에 대해 좀 더 자세히 설명되어 있습니다. 아래에서는 각 기능의 기능과 원리를 자세히 소개하겠습니다.
　로드 밸런싱 장치가 배포되기 전에 사용자는 서버 주소에 직접 액세스합니다(서버 주소는 방화벽의 다른 주소에 매핑될 수 있지만 기본적으로 일대일 액세스입니다). 단일 서버에서 성능이 부족하여 많은 사용자의 접속을 처리할 수 없는 경우, 여러 대의 서버를 활용하여 서비스를 제공하는 방안을 고려해볼 수 있는 방법이 바로 로드 밸런싱입니다. 로드 밸런싱 장치의 구현 원리는 여러 서버의 주소를 외부 서비스 IP(보통 VIP라고 부름)에 매핑하는 것입니다. 서버 매핑의 경우 서버 IP를 VIP 주소에 직접 매핑하거나 서버를 매핑할 수 있습니다. IP:포트를 VIP:포트로 변경합니다. 포트 매핑 중에 서버 포트와 VIP 포트가 다를 수 있습니다. 사용자는 실제로 서버가 무엇인지 알 수 없습니다. 로드 밸런싱이 완료되었으므로 여전히 동일한 대상 IP에 액세스하므로 사용자의 액세스가 로드 밸런싱 장치에 도달한 후 사용자의 액세스를 적절한 서버에 분배하는 방법은 로드 밸런싱 장치의 작업입니다. 위에서 언급한 세 가지 주요 기능.
자세한 액세스 프로세스 분석을 해보겠습니다.

　사용자(IP: 207.17.117.20)가 도메인 이름 www.a10networks.com에 액세스하면 이 도메인 이름의 공개 주소가 먼저 DNS 쿼리: 199.237.202.124를 통해 구문 분석됩니다. 사용자 207.17.117.20은 주소 199.237.202.124에 액세스하므로 데이터 패킷이 로드 밸런싱 장치에 도착합니다. 그런 다음 로드 밸런싱 장치는 데이터 패킷을 적절한 서버에 배포합니다.

로드 밸런싱 장치가 데이터 패킷을 전송 중입니다. 서버가 실행 중일 때 데이터 패킷은 위 그림에 표시된 것처럼 일부 변경을 거쳤으며 데이터 패킷이 로드 밸런싱 장치에 도달하기 전에 소스 주소는 207.17.117.20입니다. 대상 주소는 199.237.202.124입니다. 로드 밸런싱 장치가 데이터 패킷을 전달할 때 서버가 선택되면 소스 주소는 여전히 207.17.117.20이고 대상 주소는 172.16.20.1이 됩니다. 이 방법을 대상 주소 NAT라고 합니다. (DNAT, 목적지 주소 번역). 일반적으로 DNAT는 서버 로드 밸런싱에서 수행되어야 하며(DNAT를 수행하지 않는 서버 직접 반환-DSR이라는 또 다른 모드가 있으므로 별도로 논의하겠습니다), 소스 주소는 배포 모드에 따라 달라지기도 합니다. SNAT(소스 주소 NAT)라고 하는 다른 주소로 변환해야 합니다. 일반적으로 바이패스 모드에는 SNAT가 필요하지만 직렬 모드는 그렇지 않습니다. 따라서 소스 주소 NAT가 수행되지 않습니다.
　 서버에서 반환되는 패킷을 살펴보겠습니다. 아래 그림과 같이 IP 주소 변환 과정도 거쳤으나 응답 패킷의 소스/대상 주소는 요청 패킷과 정확히 반대로 되어 있습니다. 서버에서 반환된 패킷은 172.16.20.1이고 목적지는 172.16.20.1입니다. 주소는 207.17.117.20입니다. 로드 밸런싱 장치에 도달한 후 로드 밸런싱 장치는 소스 주소를 199.237.202.124로 변경한 후 전달합니다. 사용자에게 액세스 일관성을 보장합니다.

로드 밸런싱 알고리즘

일반적으로 로드 밸런싱 장비는 기본적으로 다음과 같은 여러 로드 밸런싱 분산 전략을 지원합니다.

RoundRobin은 순차적이고 주기적으로 각 서버에 요청을 보냅니다. 서버 중 하나에 오류가 발생하면 AX는 해당 서버를 순차 순환 큐에서 꺼내어 서버가 정상으로 돌아올 때까지 다음 폴링에 참여하지 않습니다.
비율(Ratio): 각 서버에 가중치를 부여하여 비율로 할당합니다. 이 비율을 기준으로 사용자 요청이 각 서버에 할당됩니다. 서버 중 하나에 오류가 발생하면 AX는 해당 서버를 서버 대기열에서 꺼내고 서버가 정상으로 돌아올 때까지 다음 사용자 요청 배포에 참여하지 않습니다.
우선순위: 모든 서버를 그룹화하고, 각 그룹의 우선순위를 정의하고, 사용자 요청을 우선순위가 가장 높은 서버 그룹에 할당합니다(동일한 그룹 내에서 사전 설정된 폴링 또는 비율 알고리즘을 사용하여 사용자 요청 할당). 우선 순위가 가장 높은 모든 서버 또는 지정된 수의 서버에 오류가 발생하면 AX는 우선 순위가 낮은 서버 그룹에 요청을 보냅니다. 이 방법은 실제로 사용자에게 핫 백업 방법을 제공합니다.
LeastConnection: AX는 각 서버 또는 서비스 포트의 현재 연결 수를 기록하고, 새로운 연결은 연결 수가 가장 적은 서버로 전달됩니다. 서버 중 하나에 오류가 발생하면 AX는 해당 서버를 서버 대기열에서 꺼내고 서버가 정상으로 돌아올 때까지 다음 사용자 요청 배포에 참여하지 않습니다.
Fast 응답 시간: 가장 빠른 서버에 응답하는 사람들에게 새로운 연결이 전달됩니다. 서버 중 하나에 오류가 발생하면 AX는 해당 서버를 서버 대기열에서 꺼내고 서버가 정상으로 돌아올 때까지 다음 사용자 요청 배포에 참여하지 않습니다.
해시 알고리즘(해시): 계산에 따라 클라이언트의 소스 주소와 포트를 해시합니다. 결과가 처리를 위해 서버로 전달됩니다. 서버 중 하나에 오류가 발생하면 서버 대기열에서 제외되고 정상으로 돌아올 때까지 다음 사용자 요청 배포에 참여하지 않습니다.
패킷 기반 콘텐츠 배포: 예를 들어 URL에 다음이 포함된 경우 HTTP URL을 판단합니다. .jpg 확장자는 데이터 패킷을 지정된 서버로 전달합니다.

Health check

Health check는 서버에 열려 있는 다양한 서비스의 가용성 상태를 확인하는 데 사용됩니다. 로드 밸런싱 장치는 일반적으로 Ping, TCP, UDP, HTTP, FTP, DNS 등과 같은 다양한 상태 확인 방법으로 구성됩니다. Ping은 Health Check의 세 번째 레이어에 속하며 서버 IP의 연결을 확인하는 데 사용되며, TCP/UDP는 Health Check의 네 번째 레이어에 속해 서비스 포트의 UP/DOWN을 확인하는 데 사용됩니다. 더 정확하게는 계층 7을 기반으로 하는 상태 확인을 사용해야 합니다. 예를 들어 HTTP 상태 확인을 생성하고 페이지를 다시 가져와서 페이지 콘텐츠에 지정된 문자열이 포함되어 있는지 확인하면 서비스가 실행됩니다. 포함되어 있지 않거나 페이지를 검색할 수 없는 경우 서버의 웹 서비스를 사용할 수 없는(DOWN) 것으로 간주됩니다. 예를 들어, 로드 밸런싱 장치가 서버 172.16.20.3의 포트 80이 DOWN임을 감지하면 로드 밸런싱 장치는 후속 연결을 이 서버로 전달하지 않고 알고리즘에 따라 데이터 패킷을 다른 서버로 전달합니다. 상태 확인을 생성할 때 확인 간격과 시도 횟수를 설정할 수 있습니다. 예를 들어 간격을 5초로 설정하고 시도 횟수를 3으로 설정하면 로드 밸런싱 장치는 5초마다 상태 확인을 시작합니다. 확인이 실패하면 3번 시도하고, 확인이 3번 실패하면 서비스는 DOWN으로 표시되며, 서버 상태 확인이 발견되면 서버는 5초마다 DOWN 서버를 확인합니다. 특정 순간에 다시 성공하면 서버가 UP으로 다시 표시됩니다. 상태 점검 시도 간격과 횟수는 종합적인 상황에 따라 설정해야 하며, 업무에 영향을 주지도 않고 로드 밸런싱 장비에 큰 부담을 주지 않는 것이 원칙입니다.

Session persistence

사용자의 두 http 요청이 동일한 서버로 전달되도록 하려면 부하 분산 장치에서 세션 지속성을 구성해야 합니다.
세션 지속성은 세션의 연속성과 일관성을 유지하는 데 사용됩니다. 서버 간에 사용자 액세스 정보를 실시간으로 동기화하는 것은 어렵기 때문에 이를 위해서는 사용자의 이전 액세스 세션과 이후 액세스 세션을 하나의 서버에 보관하여 처리해야 합니다. 예를 들어, 사용자가 전자상거래 웹사이트를 방문하면 첫 번째 서버에서 사용자의 로그인을 처리하지만 사용자의 상품 구매는 두 번째 서버에서 처리하므로 두 번째 서버에서는 사용자의 정보를 알 수 없으므로 이번 구매는 수행되지 않습니다. 성공하세요. 이 경우 세션 유지 관리가 필요하며 모든 사용자 작업은 첫 번째 서버에서 처리되어야 성공합니다. 물론 모든 액세스에 세션 유지 관리가 필요한 것은 아닙니다. 예를 들어 서버가 웹 사이트의 뉴스 채널과 같은 정적 페이지를 제공하고 각 서버에 동일한 콘텐츠가 있는 경우 이러한 액세스에는 세션 유지 관리가 필요하지 않습니다.
대부분의 로드 밸런싱 제품은 소스/대상 주소 세션 지속성과 쿠키 세션 지속성의 두 가지 기본 유형의 세션 지속성을 지원합니다. 또한 해시, URL 지속성 등도 일반적으로 사용되는 방법이지만 모든 장치가 이를 지원하는 것은 아닙니다. 지원하다. 다양한 애플리케이션을 기반으로 다양한 세션 보존을 구성해야 합니다. 그렇지 않으면 로드 불균형이나 액세스 예외가 발생할 수 있습니다. 주로 B/S 구조의 세션 유지를 분석합니다.

B/S 구조 기반 애플리케이션:

　웹사이트의 정적 페이지와 같이 일반적인 B/S 구조를 갖는 애플리케이션 콘텐츠의 경우 세션 지속성을 구성할 필요가 없습니다. 그러나 B/S 구조 기반 비즈니스 시스템, 특히 미들웨어 플랫폼의 경우 세션 지속성을 구성해야 합니다. 일반적으로 이 경우 필요에 맞게 소스 주소 세션 지속성을 구성할 수 있습니다. 그러나 클라이언트가 위에서 언급한 소스 주소 세션 지속성에 도움이 되지 않는 환경을 가지고 있을 수 있다는 점을 고려하면 쿠키 세션 지속성을 사용하는 것이 더 나은 방법입니다. . 쿠키 세션 지속성은 로드 밸런싱 장치가 선택한 서버 정보를 쿠키에 저장하여 클라이언트에 전송합니다. 클라이언트가 계속 방문하면 로드 밸런서는 쿠키를 분석하여 이전 세션을 유지합니다. 선택한 서버. 쿠키는 파일 쿠키와 메모리 쿠키로 구분되며, 파일 쿠키는 클라이언트 컴퓨터의 하드 드라이브에 저장되며, 쿠키 파일이 만료되지 않는 한, 브라우저를 반복적으로 닫거나 닫아도 동일한 서버에 보관될 수 있습니다. 아니다. 메모리 쿠키는 쿠키 정보를 메모리에 저장합니다. 쿠키의 생존 시간은 브라우저가 열릴 때 시작되고 브라우저가 닫힐 때 종료됩니다. 현재 브라우저에는 쿠키에 대한 특정 기본 보안 설정이 있으므로 일부 클라이언트에서는 파일 쿠키 사용이 허용되지 않는다고 규정할 수 있으므로 현재 애플리케이션 개발에서는 대부분 메모리 쿠키를 사용합니다.
　그러나 메모리 쿠키는 전능하지 않습니다. 예를 들어, 브라우저는 보안상의 이유로 쿠키를 완전히 비활성화하여 쿠키 세션 보존 효과를 잃을 수 있습니다. Session-id를 통해 세션 지속성을 달성할 수 있습니다. 즉, session-id를 URL 매개변수로 사용하거나 숨겨진 필드<input type="hidden">에 넣은 다음 배포를 위해 Session-id를 분석할 수 있습니다.
또 다른 해결책은 각 세션 정보를 데이터베이스에 저장하는 것입니다. 이 솔루션은 데이터베이스의 로드를 증가시키므로 성능 향상에는 좋지 않습니다. 데이터베이스는 더 긴 세션에 대한 세션 데이터를 저장하는 데 가장 적합합니다. 데이터베이스의 단일 장애 지점을 방지하고 확장성을 향상시키기 위해 데이터베이스는 일반적으로 여러 서버에 복제되고 요청은 로드 밸런서를 통해 데이터베이스 서버로 분산됩니다.
　소스/대상 주소 기반 세션 지속성은 고객이 DHCP, NAT 또는 웹 프록시를 통해 인터넷에 연결할 수 있고 IP 주소가 자주 변경될 수 있기 때문에 실제로 사용하기 쉽지 않으며 이로 인해 이 솔루션의 서비스 품질이 보장되지 않습니다.
NAT(Network Address Translation): 사설망의 일부 호스트에 로컬 IP 주소(즉, 이 사설망 내에서만 사용되는 사설 주소)가 할당되었으나 이제는 인터넷으로 통신하고 싶은 경우 호스트 간 통신 시( 암호화가 필요하지 않음) NAT 방식을 사용할 수 있습니다. 이 방법을 사용하려면 개인 네트워크를 인터넷에 연결하는 라우터에 NAT 소프트웨어를 설치해야 합니다. NAT 소프트웨어가 탑재된 라우터를 NAT 라우터라고 하며, 유효한 외부 글로벌 IP 주소가 하나 이상 있습니다. 이런 방식으로 로컬 주소를 사용하는 모든 호스트가 외부 세계와 통신할 때 해당 로컬 주소는 NAT 라우터에서 글로벌 IP 주소로 변환되어야 인터넷에 연결할 수 있습니다.

로드 밸런싱의 또 다른 이점

높은 확장성

서버 수를 추가하거나 줄여서 높은 동시 요청에 더 잘 대처할 수 있습니다.

(서버) 상태 점검

　로드 밸런서는 백엔드 서버 애플리케이션 계층의 상태를 확인하고 실패한 서버를 서버 풀에서 제거하여 안정성을 향상시킬 수 있습니다.

TCP 연결 재사용

　TCP 연결 재사용 기술은 프런트 엔드에 있는 여러 클라이언트의 HTTP 요청을 백엔드와 서버 간에 설정된 TCP 연결로 다중화합니다. 이 기술을 사용하면 서버의 성능 부하를 크게 줄일 수 있고, 서버와의 새로운 TCP 연결로 인한 지연을 줄일 수 있으며, 클라이언트에서 백엔드 서버로의 동시 연결 요청 수를 최소화하고, 서버의 리소스 점유를 줄일 수 있습니다.
　일반적인 상황에서 클라이언트는 HTTP 요청을 보내기 전에 서버와 TCP 3방향 핸드셰이크를 수행하고 TCP 연결을 설정한 다음 HTTP 요청을 보내야 합니다. 서버는 HTTP 요청을 수신한 후 이를 처리하고 처리 결과를 클라이언트로 다시 보냅니다. 그러면 클라이언트와 서버는 서로에게 FIN을 보내고 FIN에 대한 ACK 확인을 받은 후 연결을 닫습니다. 이런 방식으로 간단한 HTTP 요청을 처리하려면 12개 이상의 TCP 패킷이 필요합니다.
　TCP 연결 재사용 기술을 사용한 후 클라이언트(예: ClientA)와 로드 밸런싱 장치 간에 3방향 핸드셰이크가 수행되고 HTTP 요청이 전송됩니다. 요청을 받은 후 로드 밸런싱 장치는 서버에 유휴 긴 연결이 있는지 여부를 감지합니다. 존재하지 않는 경우 서버는 새 연결을 설정합니다. HTTP 요청 응답이 완료되면 클라이언트는 로드 밸런싱 장치와 협상하여 연결을 종료하고, 로드 밸런싱은 서버와의 연결을 유지합니다. 다른 클라이언트(예: ClientB)가 HTTP 요청을 보내야 하는 경우 로드 밸런싱 장치는 서버와 유지 관리되는 유휴 연결에 HTTP 요청을 직접 보내 새 TCP 연결로 인한 지연 및 서버 리소스 소비를 방지합니다.

　HTTP 1.1에서는 클라이언트가 TCP 연결을 통해 여러 HTTP 요청을 보낼 수 있습니다. 이 기술을 HTTP 멀티플렉싱이라고 합니다. TCP 연결 다중화와 가장 근본적인 차이점은 TCP 연결 다중화는 여러 클라이언트 HTTP 요청을 서버 측 TCP 연결로 다중화하는 반면, HTTP 다중화는 TCP를 통해 클라이언트의 HTTP 요청을 다중화하는 것입니다. 연결이 처리됩니다. 전자는 로드 밸런싱 장치의 고유한 기능인 반면 후자는 HTTP 1.1 프로토콜에서 지원되는 새로운 기능이며 현재 대부분의 브라우저에서 지원됩니다.

HTTP 캐시

로드 밸런서는 정적 콘텐츠를 저장하고 백엔드 서버를 요청할 필요 없이 사용자가 요청할 때 직접 응답할 수 있습니다.

TCP 버퍼링

　TCP 버퍼링은 백엔드 서버의 네트워크 속도와 고객의 프런트엔드 네트워크 속도 불일치로 인해 발생하는 서버 리소스 낭비 문제를 해결하기 위한 것입니다. 클라이언트와 로드 밸런서 사이의 링크는 대기 시간이 길고 대역폭이 낮은 반면, 로드 밸런서와 서버 사이의 링크는 대기 시간이 낮고 대역폭이 높은 LAN 연결을 사용합니다. 로드 밸런서는 백엔드 서버의 응답 데이터를 고객에게 임시로 저장한 다음 응답 시간이 길고 네트워크 속도가 느린 고객에게 이를 전달할 수 있으므로 백엔드 웹 서버는 해당 스레드를 해제하여 다른 작업을 처리할 수 있습니다.

SSL 가속

일반적인 상황에서 HTTP는 네트워크에서 일반 텍스트로 전송되므로 불법적으로 도청될 수 있으며, 특히 인증에 사용되는 비밀번호 정보는 더욱 그렇습니다. 이러한 보안 문제를 방지하기 위해 일반적으로 SSL 프로토콜(예: HTTPS)을 사용하여 HTTP 프로토콜을 암호화하여 전체 전송 프로세스의 보안을 보장합니다. SSL 통신에서는 먼저 비대칭 키 기술을 사용하여 인증 정보를 교환하고, 서버와 브라우저 간에 데이터를 암호화하는 데 사용되는 세션 키를 교환한 후 통신 과정에서 해당 키를 사용하여 정보를 암호화하고 복호화합니다.
　SSL은 CPU 자원을 많이 소모하는 보안 기술입니다. 현재 대부분의 로드 밸런싱 장치는 SSL 가속 칩(하드웨어 로드 밸런서)을 사용하여 SSL 정보를 처리합니다. 이 방법은 기존의 서버 기반 SSL 암호화 방법보다 높은 SSL 처리 성능을 제공하므로 서버 자원을 많이 절약하고 서버가 비즈니스 요청 처리에 집중할 수 있습니다. 또한 중앙 집중식 SSL 처리를 통해 인증서 관리를 단순화하고 일상적인 관리 작업량을 줄일 수도 있습니다.

콘텐츠 필터링

　일부 로드 밸런서는 필요에 따라 이를 통과하는 데이터를 수정할 수 있습니다.

침입 방지 기능

　 네트워크 계층/전송 계층 보안을 보장하는 방화벽을 기반으로 애플리케이션 계층 보안 방지도 제공합니다.

분류

로드 밸런싱 구현은 아래 여러 수준에서 논의됩니다.

DNS 로드 밸런싱

DNS는 도메인 이름 확인 서비스 제공을 담당합니다. 사이트에 액세스할 때 실제로 먼저 도메인 이름을 얻어야 합니다. DNS 서버는 해당 사이트의 도메인 이름을 가리킵니다. 이 과정에서 DNS 서버는 도메인 이름과 IP 주소의 매핑을 완료합니다. 이때 DNS도 마찬가지입니다. 서버는 로드 밸런싱 스케줄러 역할을 하며 사용자의 요청을 여러 서버에 분산하여 전송합니다. dig 명령을 사용하여 "baidu"의 DNS 설정을 살펴보세요.

Baidu에는 3개의 A 레코드가 있음을 알 수 있습니다.

　이 기술의 장점은 구현이 간단하고 구현이 쉽고 비용이 저렴하며 대부분의 TCP/IP 응용 프로그램에 적합하며 DNS 서버는 사용 가능한 모든 A 레코드 중에서 사용자에게 가장 가까운 서버를 찾을 수 있다는 것입니다. 그러나 이 솔루션의 단점도 매우 분명합니다. 우선, 이 솔루션은 진정한 의미의 로드 밸런싱이 아닙니다. DNS 서버는 현재 로드에 관계없이 HTTP 요청을 백그라운드 웹 서버에 균등하게 분배합니다. 각 웹 서버의 로드 상황, 백엔드 웹 서버의 구성 및 처리 기능이 다르면 가장 느린 웹 서버가 시스템의 병목 현상을 일으키고, 두 번째로 강력한 처리 기능을 갖춘 서버가 제 역할을 제대로 수행할 수 없습니다. 고려되지 않은 경우, 백그라운드의 특정 웹 서버에 장애가 발생하면 DNS 서버는 이 장애가 발생한 서버에 DNS 요청을 할당하므로 클라이언트에 응답할 수 없게 됩니다. 마지막 점은 치명적입니다. 상당수의 고객이 웹 서비스를 즐길 수 없게 될 수 있으며, DNS 캐싱으로 인해 그 결과가 장기간 지속됩니다(DNS의 일반적인 새로 고침 주기는 약 24시간입니다). . 따라서 최근 해외건설센터 웹사이트 솔루션에서는 이 솔루션을 거의 사용하지 않고 있다.

링크 계층(OSI 계층 2) 로드 밸런싱

로드 밸런싱을 위해 통신 프로토콜의 데이터 링크 계층에서 mac 주소를 수정합니다.
데이터 배포 시 IP 주소는 수정하지 마시고(아직 IP 주소를 볼 수 없기 때문에) 타겟 MAC 주소만 수정하시고, 백엔드 서버의 모든 가상 IP는 로드밸런서 IP 주소와 일치하도록 설정해주세요. , 데이터 배포를 위해 데이터 패킷의 소스 주소와 대상 주소를 수정하지 않는다는 목표를 달성합니다.
실제 처리 서버 IP는 데이터 요청 대상 IP와 일치합니다. 주소 변환을 위해 로드 밸런싱 서버를 거칠 필요가 없습니다. 응답 데이터 패킷은 로드 밸런싱을 피하기 위해 사용자의 브라우저에 직접 반환될 수 있습니다. 서버 네트워크 카드 대역폭이 병목 현상을 일으키고 있습니다. 직접 라우팅 모드(DR 모드)라고도 합니다. 아래와 같이:

성능은 매우 좋지만 구성이 복잡하여 현재 널리 사용되고 있습니다.

전송 계층(OSI 계층 4) 로드 밸런싱

전송 계층은 TCP 및 UDP를 포함하는 OSI 계층 4입니다. 널리 사용되는 전송 계층 로드 밸런서는 HAProxy(애플리케이션 계층 로드 밸런싱에도 사용됨)와 IPVS입니다.
　주로 메시지의 대상 주소와 포트 와 로드 밸런싱 장치에서 설정한 서버 선택 방법을 통해 최종 내부 서버를 결정합니다.
일반 TCP를 예로 들면, 로드 밸런싱 장치는 클라이언트로부터 첫 번째 SYN 요청을 받으면 위의 방법을 통해 최적의 서버를 선택하고 메시지에서 대상 IP 주소를 수정합니다. (변경 사항은 백엔드 서버 IP입니다. ) 서버로 직접 전달됩니다. TCP 연결 설정, 즉 클라이언트와 서버 간에 직접 3방향 핸드셰이크가 설정되고 로드 밸런싱 장치는 라우터와 같은 전달 작업 역할만 수행합니다. 일부 배포 상황에서는 서버 반환 패킷이 로드 균형 조정 장치에 올바르게 반환될 수 있도록 하기 위해 패킷을 전달하는 동안 패킷의 원래 소스 주소가 수정될 수 있습니다.

애플리케이션 계층(OSI 계층 7) 로드 밸런싱

애플리케이션 계층은 OSI 계층 7입니다. 여기에는 HTTP, HTTPS 및 WebSocket이 포함됩니다. 매우 유명하고 입증된 애플리케이션 계층 로드 밸런서는 Nginx [Engine X = Engine X]입니다.
"컨텐츠 스위칭"이라고도 알려진 소위 7계층 로드 밸런싱은 주로 로드 밸런싱 장치에서 설정한 서버 선택 방법과 결합하여 메시지에 포함된 실제로 의미 있는 애플리케이션 계층 콘텐츠를 통해 최종 선택을 결정합니다. . 내부 서버. 이때 특정 http 요청의 전체 URL을 볼 수 있으므로 아래 그림에 표시된 분포를 얻을 수 있습니다.

일반 TCP를 예, 로드 밸런싱 장비 실제 애플리케이션 계층 콘텐츠를 기반으로 서버를 선택하려는 경우 실제 애플리케이션 계층 콘텐츠 메시지를 보기 전에 최종 서버를 프록시하여 클라이언트와의 연결(3방향 핸드셰이크)만 설정할 수 있습니다. 클라이언트가 보낸 후 실제 애플리케이션 계층 콘텐츠를 기반으로 서버를 선택합니다. 이 문서의 특정 필드는 로드 밸런싱 장치에서 설정한 서버 선택 방법과 결합되어 최종 내부 서버 선택을 결정합니다. 이 경우 로드 밸런싱 장치는 프록시 서버와 더 유사합니다. 부하 분산 및 프런트엔드 클라이언트와 백엔드 서버는 각각 TCP 연결을 설정합니다. 따라서 이러한 기술 원칙의 관점에서 볼 때 7레이어 로드 밸런싱은 로드 밸런싱 장비에 대한 요구 사항이 더 높으며 7레이어를 처리하는 능력은 필연적으로 4레이어 모드 배포 방법보다 낮습니다. 그렇다면 왜 레이어 7 로드 밸런싱이 필요한가요?

　7계층 로드 밸런싱의 이점은 전체 네트워크를 더욱 "지능적"으로 만드는 것입니다. 예를 들어 위에 나열된 로드 밸런싱의 대부분의 이점은 7계층 로드 밸런싱을 기반으로 합니다. 예를 들어, 웹 사이트를 방문하는 사용자 트래픽은 이미지 요청을 특정 이미지 서버로 전달할 수 있으며, 7계층 접근 방식을 통해 텍스트 요청을 특정 텍스트 서버로 전달할 수 있으며 압축 기술을 사용할 수 있습니다. 물론 이는 기술적인 관점에서 볼 때 이는 7계층 애플리케이션의 작은 사례일 뿐입니다. 이 방법은 어떤 의미에서든 클라이언트의 요청과 서버의 응답을 수정하여 네트워크 계층에서 애플리케이션 시스템의 유연성을 크게 향상시킬 수 있습니다.
자주 언급되는 또 다른 기능은 보안입니다. 네트워크에서 가장 흔한 SYN Flood 공격은 해커가 다수의 소스 클라이언트를 제어하고 거짓 IP 주소를 사용하여 동일한 대상에 SYN 공격을 보내는 것입니다. 일반적으로 이 공격은 대량의 SYN 메시지를 전송하고 서버의 관련 리소스를 소진시킵니다. 서비스 거부(DoS) 목적을 달성합니다. 또한 4계층 모드에서는 이러한 SYN 공격이 백엔드 서버로 전달되고 7계층 모드에서는 이러한 SYN 공격이 자연스럽게 로드 밸런싱 장치에서 종료된다는 기술적 원리를 통해 알 수 있습니다. 백엔드 서버의 정상적인 작동에는 영향을 미치지 않습니다. 또한 로드 밸런싱 장치는 SQL 주입 및 기타 애플리케이션 수준 공격 방법과 같은 특정 메시지를 필터링하기 위해 7계층 수준에서 여러 정책을 설정하여 애플리케이션 수준에서 전체 시스템 보안을 더욱 향상시킬 수 있습니다.
　현재의 7계층 로드 밸런싱은 주로 널리 사용되는 HTTP 프로토콜에 중점을 두기 때문에 적용 범위는 주로 수많은 웹사이트나 내부 정보 플랫폼 등 B/S를 기반으로 개발된 시스템입니다. 레이어 4 로드 밸런싱은 ERP 및 C/S를 기반으로 개발된 기타 시스템과 같은 다른 TCP 애플리케이션에 해당합니다.