Linux에는 4가지 유형의 로드 밸런싱이 있습니다. 1. 가상 Mac 주소를 사용하는 레이어 2 로드 밸런싱(mac). 가상 MAC 주소에 대한 외부 요청은 로드 밸런싱을 통해 수신되고 백엔드의 실제 MAC 주소 응답을 할당합니다. 레이어 3 로드 밸런싱(ip)은 가상 IP 주소를 사용하여 외부 가상 IP 주소를 요청합니다. 로드 밸런싱은 요청을 받은 후 응답으로 백엔드의 실제 IP 주소를 할당합니다. 3. 4레이어 로드 밸런싱(tcp), 네 번째 계층 "전송 계층" "시작, "ip+port"를 사용하여 요청 수신 4. 7계층 로드 밸런싱(http).
이 튜토리얼의 운영 환경: linux7.3 시스템, Dell G3 컴퓨터.
정기적인 개발과 운영 및 유지보수 작업에서는 로드 밸런싱 서비스를 자주 사용하는데, 4레이어 로드와 7레이어 로드를 자주 언급합니다. 레이어 4 로드란 정확히 무엇인가요? 레이어 7 로드란 무엇입니까? 둘의 차이점은 무엇인가요?
1) 로드 밸런싱 (로드 밸런싱)은 기존 네트워크 구조를 기반으로 구축되어 네트워크 장치 및 서버의 대역폭을 확장할 수 있는 저렴하고 효과적이며 투명한 방법을 제공합니다. , 처리량을 늘리고, 네트워크 데이터 처리 기능을 강화하고, 네트워크 유연성과 가용성을 향상시킵니다. 로드 밸런싱에는 두 가지 의미가 있습니다: 첫째, 별도의 처리를 위해 다수의 동시 액세스 또는 데이터 트래픽이 여러 노드 장치에 공유되어 사용자가 응답을 기다리는 시간이 줄어듭니다. 둘째, 단일 과부하 작업이 여러 노드 장치에 공유됩니다. 병렬 처리가 수행되면 각 노드 장치가 처리를 완료한 후 결과가 요약되어 사용자에게 반환됩니다.
2) 은 간단히 말해서 입니다. 하나는 처리를 위해 대량의 동시 처리를 여러 백엔드 노드에 전달하여 작업 응답 시간을 줄이는 것이고, 다른 하나는 단일 과중한 작업 부하를 여러 백엔드 노드에 전달하는 것입니다. 처리 후 로드밸런싱 센터로 반납한 후, 사용자에게 반납합니다. 현재 로드 밸런싱 기술은 주로 웹 서버, FTP 서버, 기타 미션 크리티컬 서버 등 인터넷 서버 프로그램의 가용성과 확장성을 향상시키는 데 사용됩니다.
가장 일반적인 4레이어 로드 밸런싱과 7레이어 로드 밸런싱이 개발 및 운영에 가장 많이 사용됩니다.
레이어 2 로드는 OSI 모델에 따라 구분되며 일반적으로 가상 MAC 주소에 대한 외부 요청을 로드에서 받습니다. 밸런서와 백엔드의 실제 MAC 주소가 할당됩니다.
일반적으로 가상 IP 주소 방식을 채택합니다. 가상 IP 주소에 대한 외부 요청을 로드 밸런싱으로 수신하고 백엔드의 실제 IP 주소 응답을 할당합니다. (즉, 하나의 IP 대 하나의 IP 포워딩, 모든 포트가 열려 있음)
3개의 로드 밸런싱을 기반으로, 즉 4번째 계층부터 "전송" 레이어"인 경우 "ip+port"를 사용하여 요청을 수신하고 해당 시스템으로 전달합니다.
IP+포트 기반 로드 밸런싱입니다. 3레이어 로드 밸런싱을 기반으로 3레이어 IP 주소(VIP)를 공개한 후 4레이어 포트 번호를 추가하여 로드해야 할 트래픽을 결정합니다. 트래픽은 NAT 처리되어 백엔드 서버로 전달되며, 이 연결의 모든 후속 트래픽은 처리를 위해 동일한 서버로 전달됩니다.
해당 로드 밸런서는 4계층 스위치(L4 스위치)라고 하며 주로 IP 계층과 TCP/UDP 계층을 분석하여 4계층 로드 밸런싱을 달성합니다. 이 유형의 로드 밸런서는 애플리케이션 프로토콜(예: HTTP/FTP/MySQL 등)을 이해하지 못합니다.
4계층 로드 밸런싱을 구현하는 소프트웨어는 다음과 같습니다.
F5: 하드웨어 로드 밸런서로 기능은 좋지만 비용이 매우 높습니다.
lvs: 중량급 4계층 로드 소프트웨어
nginx: 캐싱 기능을 갖춘 경량 4계층 로드 소프트웨어, 보다 유연한 정규 표현식
haproxy: 4계층 포워딩 시뮬레이션, 더욱 유연함
7번째 레이어인 "application layer"에서 시작하여 가상 URL이나 IP, 호스트 이름에 따른 요청을 받아 해당 처리 서버로 전달합니다.
가상 URL 또는 호스트 IP 기반의 로드 밸런싱입니다. 4계층 로드 밸런싱을 기반으로(4개 계층 없이 7개 계층을 갖는 것은 절대 불가능합니다). 그런 다음 응용 프로그램 계층의 특성을 고려합니다. 동일한 웹 서버의 로드 밸런싱을 위해 VIP와 포트 80을 기준으로 트래픽을 처리해야 하는지 여부를 식별하는 것 외에도 7계층 URL, 브라우저 카테고리, 언어를 기반으로 로드 밸런싱을 수행할지 여부를 결정할 수도 있습니다. . 예를 들어, 웹 서버가 중국어 그룹과 영어 그룹으로 나누어져 있는 경우, 7계층 로드 밸런싱은 사용자가 도메인 이름에 액세스할 때 자동으로 사용자 언어를 식별한 후 해당 언어를 선택할 수 있습니다. 서버 그룹은 로드 밸런싱 처리를 수행합니다.
해당 로드 밸런서는 7레이어 스위치(L7 스위치)라고 합니다. 4레이어 로드 밸런싱을 지원하는 것 외에도 HTTP 프로토콜 URI 또는 쿠키 정보와 같은 애플리케이션 레이어 정보를 분석하여 7레이어 로드 밸런싱을 달성합니다. . 이 유형의 로드 밸런서는 애플리케이션 프로토콜을 이해합니다.
7계층 로드 밸런싱을 구현하는 소프트웨어에는 다음이 포함됩니다.
haproxy: 타고난 로드 밸런싱 기술, 7계층 프록시, 세션 유지, 표시, 경로 전송을 완벽하게 지원합니다.
nginx: http 프로토콜 및 메일 프로토콜. 성능은 haproxy와 유사합니다.
apache: 열악한 기능
Mysql 프록시: 허용되는 기능.
일반적으로 lvs는 레이어 4 로드에 사용됩니다. nginx는 레이어 7 로드에 사용됩니다(스트림 모듈을 통해 레이어 4 로드에도 사용할 수 있음). haproxy는 더 유연하며 레이어 4와 레이어 4를 모두 수행할 수 있습니다. 레이어 7 로드 밸런싱.
소위 4레이어 로드밸런싱, 즉 주로 메시지 내 대상을 통해 로드 밸런싱 장치에서 설정한 서버 선택 방법과 주소 및 포트가 결합되어 최종 내부 서버 선택이 결정됩니다.
일반 TCP를 예로 들면, 로드 밸런싱 장치는 클라이언트로부터 첫 번째 SYN 요청을 받으면 위의 방법을 통해 최적의 서버를 선택하고 메시지의 대상 IP 주소(최종 서버 IP로 변경)를 수정하여 전달합니다. 서버에 직접. TCP 연결 설정, 즉 클라이언트와 서버 간에 직접 3방향 핸드셰이크가 설정되고 로드 밸런싱 장치는 라우터와 같은 전달 작업 역할만 수행합니다. 일부 배포 상황에서는 서버 반환 패킷이 로드 균형 조정 장치에 올바르게 반환될 수 있도록 하기 위해 패킷을 전달하는 동안 패킷의 원래 소스 주소가 수정될 수 있습니다.
"콘텐츠 교환"이라고도 알려진 소위 7계층 로드 밸런싱은 주로 메시지에 포함된 정말 의미 있는 애플리케이션 계층 콘텐츠와 로드 밸런싱에서 설정한 서버 선택 방법을 통해 이루어집니다. device 는 내부 서버의 최종 선택을 결정합니다.
일반적인 TCP를 예로 들면, 로드 밸런싱 장치가 실제 애플리케이션 계층 콘텐츠를 기반으로 서버를 선택하려는 경우 먼저 최종 서버와 클라이언트 간의 연결을 설정한 후에만 클라이언트가 보낸 요청을 수락할 수 있습니다. (3방향 핸드셰이크) 메시지의 실제 애플리케이션 계층 내용은 메시지의 특정 필드와 로드 밸런싱 장치에 의해 설정된 서버 선택 방법을 기반으로 결정되어 최종 내부 서버 선택을 결정합니다. 이 경우 로드 밸런싱 장치는 프록시 서버와 더 유사합니다. 부하 분산 및 프런트엔드 클라이언트와 백엔드 서버는 각각 TCP 연결을 설정합니다. 따라서 이러한 기술 원칙의 관점에서 볼 때 7레이어 로드 밸런싱은 로드 밸런싱 장비에 대한 요구 사항이 더 높으며 7레이어를 처리하는 능력은 필연적으로 4레이어 모드 배포 방법보다 낮습니다.
4계층 로드 밸런싱 은 메시지 전달을 처리하지만 메시지 내용을 고려하지 않는 중간 전송 계층에서 수행됩니다. 예를 들어, TCP는 네트워크의 HTTP(Hypertext Transfer Protocol) 트래픽을 위한 계층 4 프로토콜입니다. 이 프로세스 동안 레이어 4 로드 밸런싱은 네트워크 패킷을 업스트림 서버로 전달하지만 패킷의 내용을 검사하지는 않으며 TCP 스트림의 처음 몇 개의 패킷을 검사하여 제한된 라우팅 결정만 내릴 수 있습니다.
7계층 로드 밸런싱4계층 로드 밸런싱과 달리 상위 애플리케이션 계층에서 실행되며 각 메시지의 실제 내용을 처리합니다. HTTP는 웹상의 웹사이트 트래픽을 위한 기본 레이어 7 프로토콜입니다. 레이어 7 로드 밸런싱은 레이어 4 로드 밸런싱보다 더 복잡한 방식으로 네트워크 트래픽을 라우팅하며 특히 TCP 기반 트래픽(예: HTTP)에 적합합니다. 계층 7 로드 밸런싱은 네트워크 트래픽을 종료하고 서버에서 메시지를 읽습니다. 메시지 콘텐츠(예: URL 또는 쿠키)를 기반으로 로드 밸런싱 결정을 내릴 수 있습니다. 그 후, 7계층 로드 밸런싱은 선택한 서버와 새로운 TCP 연결을 설정하고 서버에 요청을 씁니다.
간단히 말하면 둘의 차이점은
- 7계층 로드 밸런싱은 기본적으로 http 프로토콜 기반으로 웹 서버의 로드 밸런싱에 적합합니다. (nginx)
- 4계층 로드 밸런싱은 주로 tcp 프로토콜 메시지 기반이며 tcp/ip 프로토콜 기반의 모든 소프트웨어에 대한 로드 밸런싱을 수행할 수 있습니다. (haproxy, LVS)
- 둘의 주요 차이점은 사용되는 메시지의 수준이 다르며 각각 고유한 장점이 있다는 것입니다.
- 7계층 애플리케이션 로드의 이점은 전체 네트워크를 더욱 "지능적"으로 만드는 것입니다. 예를 들어, 웹 사이트를 방문하는 사용자 트래픽은 이미지 요청을 특정 이미지 서버로 전달할 수 있으며, 7계층 접근 방식을 통해 텍스트 요청을 특정 텍스트 서버로 전달할 수 있으며 압축 기술을 사용할 수 있습니다. 물론 이는 기술적인 관점에서 볼 때 이는 7계층 애플리케이션의 작은 사례일 뿐입니다. 이 방법은 어떤 의미에서든 클라이언트의 요청과 서버의 응답을 수정하여 네트워크 계층에서 애플리케이션 시스템의 유연성을 크게 향상시킬 수 있습니다. Nginx 또는 Apache와 같이 백그라운드에 배포된 많은 기능은 클라이언트 요청의 헤더 재작성, 키워드 필터링 또는 서버 응답의 콘텐츠 삽입 및 기타 기능과 같은 로드 밸런싱 장치로 이동할 수 있습니다.
- 4계층 로드 밸런싱은 주로 더 유연하며 다양한 소프트웨어의 로드 밸런싱 장치로 사용할 수 있습니다.
생생하게 예를 들어보겠습니다. 4계층 로드 밸런싱은 은행의 셀프 서비스 대기열기와 같습니다. 은행에 도착한 각 고객은 대기열기의 순서에 따라 해당 창구를 선택하여 서비스를 받습니다. -레이어 로드 밸런싱은 은행 로비 관리자와 마찬가지로 고객이 처리해야 할 업무를 먼저 확인한 후 넘버링을 조정합니다. 이러한 방식으로 재무 관리, 입출금 등을 처리하는 고객은 은행 내부 자원에 따라 조정 및 처리되어 고객 비즈니스 프로세스의 속도를 높일 수 있습니다.
7계층 로드 밸런싱의 이점
7계층 로드 밸런싱은 패킷 기반 4계층 로드 밸런싱보다 CPU를 더 많이 소모하지만 서버 성능 저하를 거의 일으키지 않습니다. 7계층 로드 밸런싱을 통해 로드 밸런서는 더 많은 정보를 바탕으로 결정을 내리고 압축, 암호화 등과 같은 콘텐츠를 최적화하고 변경할 수 있습니다. 레이어 7 로드 밸런싱은 버퍼링을 사용하여 업스트림 서버의 느린 연결을 오프로드하여 성능을 향상시킬 수도 있습니다.
계층 7 로드 밸런싱을 수행하는 구성 요소를 역방향 프록시 서버라고도 합니다.
7계층 로드 밸런싱 예시
간단한 예로, 사용자가 세션 중에 트래픽이 많은 웹사이트를 방문한다고 가정해 보겠습니다. 정적 콘텐츠(예: 이미지 또는 동영상), 동적 콘텐츠( 뉴스피드 등)) 또는 거래정보(주문상태 등) 등 계층 7 로드 밸런싱을 사용하면 로드 밸런서가 콘텐츠 유형과 같은 요청 자체의 메시지를 기반으로 요청을 라우팅할 수 있습니다. 즉, 이미지나 비디오에 대한 요청은 이를 저장하고 멀티미디어 콘텐츠를 제공하도록 고도로 최적화된 서버로 라우팅될 수 있으며, 할인 가격과 같은 거래 정보에 대한 요청은 가격 관리를 담당하는 애플리케이션 서버로 라우팅될 수 있습니다. 레이어 7 로드 밸런싱을 통해 네트워크 및 애플리케이션 설계자는 안정성을 보장하면서 효율적으로 확장되는 고도로 최적화된 서버 인프라 또는 애플리케이션 제공 네트워크를 구축할 수 있습니다.
간단히 요약
위의 비교를 보면 4레이어 로드와 7레이어 로드의 가장 큰 차이점은 효율성과 기능성의 차이인 것 같습니다. 4계층 로드 아키텍처 설계는 상대적으로 간단하며 특정 메시지 내용을 구문 분석할 필요가 없으며 상대적으로 높은 네트워크 처리량 및 처리 기능을 갖습니다. 7계층 로드 밸런싱의 장점은 다양한 기능과 유연하고 강력한 제어에 반영됩니다. . 특정 비즈니스 아키텍처를 설계할 때 특정 상황에 따라 7레이어 또는 4레이어 로드 사용을 고려해야 합니다.
로드 밸런싱 중 데이터 흐름은 모두 로드 밸런서를 통과합니다. 로드 밸런서가 병목 현상을 일으키는 문제를 해결하는 방법은 무엇입니까?
TCP 메시지의 소스 주소와 대상 주소를 수정하면 웹 서버에서 반환된 데이터가 클라이언트에 직접 반환됩니다. 이는 TCP 3방향 핸드셰이크가 설정되어 있기 때문에 7계층 로드 밸런싱으로는 할 수 없는 일입니다. 클라이언트와 로드 간 http 프로토콜은 tcp 프로토콜을 기반으로 합니다. tcp 링크가 설정된 후 http 메시지가 전송되면 로드 밸런서와 클라이언트가 연결을 설정했음을 나타냅니다. tcp 연결이 완료되었지만 웹 서버와 클라이언트 간의 tcp 링크가 설정되지 않았습니다. 클라이언트에 데이터를 반환하는 방법입니다. 위의 방법은 문제를 일으킬 수 있습니다. 클러스터의 모든 호스트는 내부 IP 주소를 가지며 외부 세계와 통신할 수 없습니다.
해결책 1:
사용할 외부 IP 주소를 너무 많이 구입할 수 있는 경우 tcp 링크가 설정될 때 실제 웹 서버에 로드 밸런싱하여 클라이언트와 서버가 tcp 링크를 설정할 수 있도록 합니다. .
해결책 2:
인용문: 모든 컴퓨터 문제는 가상 레이어를 설정하면 해결될 수 있습니다.
모든 서버 호스트 IP를 로드 밸런싱 서버 IP로 가상화하여 서버 클러스터 내의 모든 호스트가 외부 네트워크에 접근할 수 있도록 할 수 있습니다. 두 번째 계층에서는 데이터 흐름 방향을 구별하고, 데이터 링크 계층(2계층) 대상 호스트의 MAC 주소를 수정하여 웹 서버로 요청을 보내면 실제로 웹이 연결되기 때문입니다. 서버는 인터넷에 연결할 수 있으며 클라이언트에 직접 데이터를 반환할 수 있습니다.
7계층 애플리케이션 로드의 이점은 전체 네트워크를 더욱 "지능적"으로 만드는 것입니다. . 예를 들어, 웹 사이트를 방문하는 사용자 트래픽은 이미지 요청을 특정 이미지 서버로 전달할 수 있으며, 7계층 접근 방식을 통해 텍스트 요청을 특정 텍스트 서버로 전달할 수 있으며 압축 기술을 사용할 수 있습니다. 물론 이는 기술적인 관점에서 볼 때 이는 7계층 애플리케이션의 작은 사례일 뿐입니다. 이 방법은 어떤 의미에서든 클라이언트의 요청과 서버의 응답을 수정하여 네트워크 계층에서 애플리케이션 시스템의 유연성을 크게 향상시킬 수 있습니다. Nginx 또는 Apache와 같이 백그라운드에 배포된 많은 기능은 클라이언트 요청의 헤더 재작성, 키워드 필터링 또는 서버 응답의 콘텐츠 삽입 및 기타 기능과 같은 로드 밸런싱 장치로 이동할 수 있습니다.
자주 언급되는 또 다른 기능은 보안입니다. 네트워크에서 가장 일반적인 SYN Flood 공격은 해커가 많은 소스 클라이언트를 제어하고 잘못된 IP 주소를 사용하여 동일한 대상에 SYN 공격을 보내는 것입니다. 일반적으로 이 공격은 많은 수의 SYN 메시지를 보내고 서버의 관련 리소스를 소모합니다. 서비스 거부(DoS) 목적. 또한 4계층 모드에서는 이러한 SYN 공격이 백엔드 서버로 전달되고 7계층 모드에서는 이러한 SYN 공격이 자연스럽게 로드 밸런싱 장치에서 종료된다는 기술적 원리를 통해 알 수 있습니다. 백엔드 서버의 정상적인 작동에는 영향을 미치지 않습니다. 또한 로드 밸런싱 장치는 SQL 주입 및 기타 애플리케이션 수준 공격 방법과 같은 특정 메시지를 필터링하기 위해 7계층 수준에서 여러 정책을 설정하여 애플리케이션 수준에서 전체 시스템 보안을 더욱 향상시킬 수 있습니다.
현재 7계층 로드 밸런싱은 주로 HTTP 프로토콜 적용에 중점을 두고 있기 때문에 적용 범위는 주로 수많은 웹사이트나 내부 정보 플랫폼 등 B/S 기반 시스템입니다. 레이어 4 로드 밸런싱은 ERP 및 C/S를 기반으로 개발된 기타 시스템과 같은 다른 TCP 애플리케이션에 해당합니다.
3.1) 정말 필요한가요? 7계층 애플리케이션은 실제로 트래픽 인텔리전스를 향상시킬 수 있지만 동시에 복잡한 장치 구성, 로드 밸런싱 압력 증가, 문제 해결의 복잡성 등의 문제를 필연적으로 야기합니다. 시스템을 설계할 때 4개 레이어와 7개 레이어를 동시 적용하는 혼합 상황을 고려해야 한다.
3.2) 정말 보안이 개선될 수 있는지. 예를 들어, SYN Flood 공격, 7레이어 모드는 서버에서 이러한 트래픽을 차단하지만 로드 밸런싱 장치 자체는 강력한 DDoS 방지 기능을 갖추고 있어야 합니다. 그렇지 않으면 서버가 정상이고 로드 밸런싱 장치가 서버로 사용되는 경우에도 마찬가지입니다. 중앙 스케줄링 실패로 인해 전체 애플리케이션이 붕괴됩니다.
3.3) 유연성이 충분한가요. 7계층 애플리케이션의 장점은 전체 애플리케이션의 트래픽을 지능적으로 만들 수 있다는 점이지만, 로드 밸런싱 장비는 다양한 상황에 따른 고객의 애플리케이션 기반 스케줄링을 충족하기 위해 완전한 7계층 기능을 제공해야 합니다. 가장 간단한 평가는 Nginx나 Apache와 같은 백그라운드 서버의 스케줄링 기능을 대체할 수 있는지 여부입니다. 7계층 애플리케이션 개발 인터페이스를 제공할 수 있는 로드 밸런싱 장치를 통해 고객은 필요에 따라 기능을 설정할 수 있으므로 강력한 유연성과 인텔리전스를 제공할 수 있습니다.
4.1) Intelligence
7계층 로드 밸런싱은 OIS 7계층의 모든 기능을 갖추고 있어 사용자 요구 사항을 보다 유연하게 처리할 수 있습니다. 이론적으로는 7계층 모델이 가능합니다. 서버에 대한 모든 사용자 요청이 수정됩니다. 예를 들어, 파일 헤더에 정보를 추가하고 다양한 파일 형식에 따라 분류하여 전달합니다. 4계층 모델은 네트워크 계층을 기반으로 한 수요 전달만 지원하며 사용자 요청 내용을 수정할 수 없습니다.
4.2) 보안
7계층 로드 밸런싱에는 OSI 모델의 모든 기능이 포함되어 있으므로 원칙적으로 네트워크의 공격에 더 쉽게 저항할 수 있습니다. 4계층 모델은 사용자의 요청을 직접 서버에 전달합니다. 백엔드 노드에는 사이버 공격에 대한 직접적인 보호가 없습니다.
4.3) 복잡성
4레이어 모델은 일반적으로 비교적 단순한 아키텍처이고 관리가 쉽고 문제 찾기가 쉽습니다. 7레이어 모델 아키텍처는 더 복잡하며 일반적으로 혼합 사용을 고려해야 합니다. 4계층 모델의 경우 문제 위치를 더욱 복잡하게 만듭니다.
4.4) 효율성 비율
4레이어 모델은 낮은 수준의 설정을 기반으로 하며 일반적으로 더 효율적이지만 적용 범위가 제한됩니다. 7레이어 모델은 더 많은 리소스를 소모하며 이론적으로 더 강력한 기능을 갖습니다. 4계층 모델, 현재 구현은 http 애플리케이션을 기반으로 합니다.
소프트웨어 로드 밸런싱 솔루션은 하나 이상의 서버에 해당하는 운영 체제에 하나 이상의 서버를 설치하는 것을 말합니다. 추가 소프트웨어 DNS 로드 밸런싱, CheckPoint Firewall-1 ConnectControl, Keepalive+ipvs 등과 같은 로드 밸런싱을 달성하는 데 사용됩니다. 장점은 특정 환경, 간단한 구성, 유연한 사용, 저렴한 비용을 기반으로 하며 일반적인 로드 밸런싱 요구 사항을 충족할 수 있습니다. . 소프트웨어 솔루션에도 많은 단점이 있습니다. 각 서버에 추가 소프트웨어를 설치하면 시스템 리소스가 무제한으로 소모되기 때문입니다. 따라서 연결 요청이 특히 클 경우 소프트웨어 자체가 더 많이 소모됩니다. 서버의 성공 또는 실패의 열쇠가 되며, 소프트웨어 확장성이 그다지 좋지 않고 운영 체제 자체의 버그로 인해 제한되므로 보안 문제가 자주 발생합니다.
하드웨어 로드 밸런싱 솔루션은 서버와 외부 네트워크 사이에 로드 밸런싱 장치를 직접 설치하는 것입니다. 이 장치는 일반적으로 로드 밸런서라고 하는 시스템과 독립된 하드웨어입니다. 전문 장비는 전문적인 작업을 완료하고 운영 체제와 독립적이기 때문에 다양한 로드 밸런싱 전략과 지능형 트래픽 관리가 결합되어 전반적인 성능이 크게 향상됩니다. 최적의 로드 밸런싱 요구 사항을 달성할 수 있습니다. 로드 밸런서는 다양한 형태로 제공되며, 일부 로드 밸런서는 스위칭 장치에 통합되어 있으며, 일부 로드 밸런서는 이를 연결하기 위해 두 개의 네트워크 어댑터를 사용합니다. PC 중 하나는 인터넷에 연결되어 있고, 다른 하나는 백엔드 서버팜 내부 네트워크에 연결되어 있습니다.
소프트웨어 로드 밸런싱과 하드웨어 로드 밸런싱 비교:
소프트웨어 로드 밸런싱의 장점은 명확한 수요 환경, 간단한 구성, 유연한 운영, 저비용, 저효율이며 일반 기업의 요구를 충족할 수 있다는 것입니다. 단점은 시스템에 대한 의존성이 리소스 오버헤드를 증가시킨다는 것입니다. 소프트웨어의 품질이 환경의 성능을 결정하고 소프트웨어의 안정성이 전체 환경의 보안에 영향을 미칩니다.
하드웨어 로드 밸런싱의 장점은 시스템에 독립적이고 전반적인 성능이 크게 향상되며 기능 및 성능 측면에서 소프트웨어 방식보다 우수하며 다양한 전략이 선택 가능하며 달성할 수 있다는 것입니다. 가장 좋은 로드 밸런싱 효과는 비용이 많이 든다는 단점입니다.
로드 밸런싱은 애플리케이션의 지리적 구조, 로컬 로드에 따라 로컬 로드 밸런싱과 글로벌 로드 밸런싱(Global Load Balance, 지역 로드 밸런싱이라고도 함)으로 구분됩니다. 밸런싱은 로컬 서버 그룹의 로드 밸런싱을 의미하고, 글로벌 로드 밸런싱은 서로 다른 지리적 위치와 서로 다른 네트워크 구조를 가진 서버 그룹 간의 로드 밸런싱을 의미합니다.
로컬 로드 밸런싱은 과도한 데이터 트래픽과 네트워크 과부하 문제를 효과적으로 해결할 수 있으며, 우수한 성능의 서버를 구입하기 위해 값비싼 비용을 들이지 않고도 기존 장비를 최대한 활용하고 단일 지점 장애를 방지할 수 있습니다. 데이터 트래픽 손실을 일으키는 서버. 데이터 트래픽을 서버 그룹 내 서버에 합리적으로 할당하여 부담을 공유하는 유연하고 다양한 밸런싱 전략을 갖추고 있습니다. 기존 서버를 확장, 업그레이드하더라도 기존 네트워크 구조를 변경하거나 기존 서비스를 중단하지 않고도 서비스 그룹에 신규 서버를 추가하면 됩니다.
글로벌 로드 밸런싱은 주로 다중 지역에 자체 서버를 보유하고 있는 사이트에 사용됩니다. 글로벌 사용자가 하나의 IP 주소 또는 도메인 이름만으로 가장 가까운 서버에 액세스할 수 있도록 하여 가장 빠른 액세스를 얻을 수 있도록 하기 위함입니다. 속도도 빠르고, 자회사가 분산되어 있고 사이트가 널리 분산되어 있는 대기업에서도 인트라넷(인트라넷)을 통해 통일되고 합리적인 자원배분을 이루기 위해 사용할 수 있습니다.
네트워크의 다양한 수준에서 시작하여 네트워크에 과부하가 걸리는 다양한 병목 현상을 목표로 해당 로드 밸런싱 기술을 사용하여 기존 문제를 해결할 수 있습니다.
대역폭이 증가하고 데이터 트래픽이 계속 증가함에 따라 네트워크 핵심 부분의 데이터 인터페이스는 병목 현상 문제에 직면하게 됩니다. 원래 단일 회선은 수요를 충족하기 어려울 것이며 회선 업그레이드는 너무 비싸거나 심지어 달성하기 어려울 것입니다. 이때 링크 어그리게이션(트렁킹) 기술 사용을 고려해 볼 수 있습니다.
링크 집합 기술(레이어 2 로드 밸런싱)은 여러 물리적 링크를 하나의 집합 논리 링크로 사용합니다. 네트워크 데이터 트래픽은 집합 논리 링크의 모든 물리적 링크에서 공유되므로 논리적으로 링크의 용량이 증가됩니다. 증가하는 대역폭 수요를 충족할 수 있습니다.
최신 로드 밸런싱 기술은 일반적으로 네트워크의 네 번째 또는 일곱 번째 계층에서 작동합니다. 레이어 4 로드 밸런싱은 인터넷에 합법적으로 등록된 IP 주소를 여러 내부 서버의 IP 주소에 매핑하고 각 TCP 연결 요청에 대해 내부 IP 주소 중 하나를 동적으로 사용하여 로드 밸런싱을 수행합니다. 레이어 4 스위치에서는 이 밸런싱 기술이 널리 사용됩니다. 대상 주소는 스위치를 통해 흐르는 서버 그룹 VIP(가상 IP 주소) 연결 요청 데이터 패킷입니다. 스위치는 소스 및 대상 IP 주소, TCP 또는 UDP 포트 번호를 결정합니다. 특정 로드 밸런싱 전략, 서버 IP와 VIP 간의 매핑, 연결 요청을 처리하기 위해 서버 그룹에서 가장 적합한 서버 선택.
7계층 로드 밸런싱은 애플리케이션 계층 서비스의 콘텐츠를 제어하고, 액세스 트래픽에 대한 높은 수준의 제어 방법을 제공하며, HTTP 서버 그룹의 애플리케이션에 적합합니다. 레이어 7 로드 밸런싱 기술은 전달되는 HTTP 헤더를 확인하고 헤더의 정보를 기반으로 로드 밸런싱 작업을 수행합니다.
7레이어 로드 밸런싱의 장점은 다음과 같은 측면에서 나타납니다:
1) HTTP 헤더를 확인하여 HTTP400, 500 및 600 시리즈 오류 메시지를 감지할 수 있으므로 연결 요청을 투명하게 리디렉션할 수 있습니다. 애플리케이션 계층 오류를 방지하기 위한 또 다른 서버입니다.
2) 흐르는 데이터의 유형(예: 데이터 패킷이 이미지 파일인지, 압축 파일인지, 멀티미디어 파일 형식인지 판단 등)에 따라 데이터 트래픽이 해당 콘텐츠의 서버로 전달되어 처리될 수 있습니다. , 시스템 성능이 향상됩니다.
3) 연결 요청 유형에 따라 일반 텍스트나 이미지 등의 정적 문서 요청인지, ASP, CGI 등의 동적 문서 요청인지 해당 요청을 해당 서버로 전달할 수 있습니다. 처리하여 시스템의 성능과 보안을 향상시킵니다.
7계층 로드 밸런싱의 단점은 다음 측면에 반영됩니다:
1) 7계층 로드 밸런싱은 지원하는 프로토콜(일반적으로 HTTP만)에 의해 제한되므로 애플리케이션의 폭이 제한됩니다.
2) HTTP 헤더를 확인하는 레이어 7 로드 밸런싱은 많은 양의 시스템 리소스를 차지하므로 필연적으로 시스템 성능에 영향을 미칠 수 있습니다. 연결 요청이 많은 경우 로드 밸런싱 장치 자체가 쉽게 병목 현상을 일으킬 수 있습니다. 전반적인 네트워크 성능을 위해.
실제 애플리케이션에서는 서버 다운 여부에 관계없이 클라이언트 서비스 요청을 내부 서버에 균등하게 분배하고 싶지 않을 수도 있습니다. 대신에 우리는 Pentium III 서버가 Pentium II보다 더 많은 서비스 요청을 받아들이기를 원합니다. 더 적은 서비스 요청을 처리하는 서버에는 더 많은 서비스 요청이 할당될 수 있습니다. 실패한 서버는 오류가 복원될 때까지 더 이상 서비스 요청을 받아들이지 않습니다. . 여러 장치가 함께 작업을 완료하고 고르지 않은 네트워크 로드 분산, 데이터 트래픽 정체 및 긴 응답 시간으로 인해 발생하는 기존 병목 현상을 제거하거나 방지할 수 있도록 적절한 로드 밸런싱 전략을 선택하십시오. 각 로드 밸런싱 방법에는 다양한 애플리케이션 요구 사항에 따라 OSI 참조 모델의 레이어 2, 3, 4, 7에서 로드 밸런싱을 위한 해당 로드 밸런싱 전략이 있습니다.
로드 밸런싱 전략의 장단점과 구현 용이성은 두 가지 핵심 요소, 즉 로드 밸런싱 알고리즘과 네트워크 시스템 상태를 감지하는 방법 및 기능입니다.
로드 밸런싱 알고리즘
1) 라운드 로빈: 네트워크의 각 요청은 1부터 N까지 차례로 내부 서버에 할당된 후 다시 시작됩니다. 이 균형 조정 알고리즘은 서버 그룹의 모든 서버가 동일한 하드웨어 및 소프트웨어 구성을 갖고 평균 서비스 요청이 상대적으로 균형을 이루는 상황에 적합합니다.
2) Weighted Round Robin: 서버의 다양한 처리 능력에 따라 각 서버에 서로 다른 가중치가 할당되어 해당 가중치로 서비스 요청을 수락할 수 있습니다. 예를 들어 서버 A의 가중치는 1, B의 가중치는 3, C의 가중치는 6으로 설계되면 서버 A, B, C는 서비스의 10%, 30%, 60%를 받게 됩니다. 각각 요청합니다. 이 밸런싱 알고리즘은 고성능 서버의 활용률을 높이고 저성능 서버의 과부하를 방지합니다.
3) Random Balance(Random): 네트워크의 요청을 여러 내부 서버에 무작위로 배포합니다.
4) Weighted Random Balancing(Weighted Random): 이 밸런싱 알고리즘은 Weighted Round-Robin 알고리즘과 유사하지만 요청 공유 처리 시 무작위 선택 프로세스입니다.
5) 응답 시간 밸런싱(Response Time): 로드 밸런싱 장치는 각 내부 서버에 감지 요청(예: Ping)을 보낸 후 각 내부 서버의 가장 빠른 응답 시간을 기준으로 어떤 서버를 사용할지 결정합니다. 탐지 요청에 응답합니다. 이 밸런싱 알고리즘은 서버의 현재 실행 상태를 더 잘 반영할 수 있지만 가장 빠른 응답 시간은 클라이언트와 서버 간의 가장 빠른 응답 시간이 아니라 로드 밸런싱 장치와 서버 간의 가장 빠른 응답 시간만을 의미합니다.
6) 최소 연결 : 각 클라이언트 요청 서비스가 서버에 머무르는 시간은 큰 차이가 있을 수 있습니다. 작업 시간이 증가함에 따라 간단한 라운드 로빈 또는 무작위 밸런싱 알고리즘을 사용하는 경우 각 서버의 연결 프로세스가 다를 수 있습니다. 실제로 로드 밸런싱이 이루어지지 않습니다. 최소 연결 수 밸런싱 알고리즘에는 내부적으로 로드되어야 하는 각 서버에 대한 데이터 레코드가 있으며, 서버에서 현재 처리 중인 연결 수를 기록합니다. 새로운 서비스 연결 요청이 있는 경우 현재 요청이 할당됩니다. 서버는 연결 수가 가장 적은 서버로 실제 상황과 균형을 맞추고 부하의 균형을 유지합니다. 이 균형 조정 알고리즘은 FTP와 같은 장기 처리 요청 서비스에 적합합니다.
7) 처리 용량 밸런싱: 이 밸런싱 알고리즘은 내부 처리 부하(서버 CPU 모델, CPU 수, 메모리 크기, 현재 연결 수 등에 따라 변환됨)가 가장 가벼운 서버에 서비스 요청을 할당합니다. 내부 서버의 처리 능력과 현재 네트워크 작동 조건에 따라 이 밸런싱 알고리즘은 상대적으로 더 정확하며 특히 레이어 7(애플리케이션 레이어) 로드 밸런싱에 적합합니다.
8) DNS 응답 밸런싱(플래시 DNS): 인터넷에서 HTTP, FTP 또는 기타 서비스 요청이든 클라이언트는 일반적으로 도메인 이름 확인을 통해 서버의 정확한 IP 주소를 찾습니다. 이 밸런싱 알고리즘에 따라 서로 다른 지리적 위치에 있는 로드 밸런싱 장치는 동일한 클라이언트로부터 도메인 이름 확인 요청을 수신하고 동시에 도메인 이름을 해당 서버(즉, 로드 밸런싱 장치)의 IP 주소로 확인합니다. 동일한 지리적 위치에 있는 서버의 IP 주소)를 클라이언트에 반환하면 클라이언트는 처음 수신한 도메인 이름 확인 IP 주소로 계속 서비스를 요청하고 다른 IP 주소 응답을 무시합니다. 이 밸런싱 전략이 글로벌 로드 밸런싱에 적합한 경우 로컬 로드 밸런싱에는 의미가 없습니다.
관련 추천: "Linux 비디오 튜토리얼"
위 내용은 Linux에는 여러 유형의 로드 밸런싱이 있습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
