하나는 하드웨어를 통해 하는 것입니다. 일반적인 하드웨어에는 상대적으로 비싼 F5 및 Array와 같은 상용 로드 밸런서가 포함되어 있으며 이러한 서비스를 유지 관리하는 전문적인 유지 관리 팀이 있다는 것이 단점입니다. 비용이 너무 많이 들기 때문에 당분간 소규모 네트워크 서비스에는 사용할 필요가 없으며, 다른 하나는 Nginx/LVS/HAProxy와 유사한 Linux 기반 오픈 소스 무료 로드 밸런싱 소프트웨어로 모두 구현됩니다. 소프트웨어 수준에서는 비용이 매우 낮습니다.
현재 웹 사이트 아키텍처를 위한 가장 합리적이고 널리 사용되는 아키텍처 솔루션은 다음과 같습니다. 웹 프런트 엔드는 로드 밸런서로 Nginx/HAProxy+Keepalived를 사용하며 백 엔드는 하나의 마스터가 있는 MySQL 데이터베이스를 사용합니다. LVS +Keepalived 아키텍처를 사용한 다중 슬레이브 및 읽기-쓰기 분리.물론 프로젝트의 구체적인 요구 사항에 따라 계획을 수립해야 합니다. 각각의 특징과 적용 사례에 대해 이야기해보겠습니다.
Nginx의 장점은 다음과 같습니다.
1. 네트워크의 레이어 7에서 작업하면 http 애플리케이션에 대해 일부 오프로드 전략을 구현할 수 있습니다. 예를 들어, 도메인 이름 및 디렉토리 구조의 경우 일반 규칙은 HAProxy보다 더 강력하고 유연하며, 이는 Nginx가 현재 널리 사용되는 주요 이유 중 하나입니다. 이를 기반으로 하는 LVS보다 훨씬 더 많은 상황에서 사용할 수 있습니다.
2. Nginx는 네트워크 안정성에 대한 의존도가 거의 없습니다. 이론적으로 이는 ping이 가능한 한 로드 기능을 수행할 수 있는 반면, LVS는 네트워크에 대한 의존도가 더 높습니다. 3. Nginx는 설치와 구성이 비교적 간단하고, 기본적으로 로그에 오류를 출력하는 것이 더 편리합니다. LVS의 구성 및 테스트에는 상대적으로 오랜 시간이 걸리며 LVS는 네트워크에 크게 의존합니다.
3. 높은 부하 압력을 견딜 수 있고 안정적입니다. 하드웨어가 나쁘지 않으면 일반적으로 수만 개의 동시성을 지원할 수 있으며 부하 정도는 LVS보다 상대적으로 작습니다.
4. Nginx는 웹 페이지를 처리하는 서버에서 반환되는 상태 코드, 시간 초과 등 내부 서버 오류를 포트를 통해 감지하고 오류를 반환하는 요청을 다른 노드에 다시 제출한다는 단점이 있습니다. 감지할 URL을 지원하지 않습니다. 예를 들어, 사용자가 파일을 업로드하고 있는데 업로드 프로세스 중에 업로드를 처리하는 노드가 실패하는 경우 Nginx는 재처리를 위해 업로드를 다른 서버로 전환하고 대용량 파일이 업로드되면 LVS의 연결이 직접 끊어집니다. 중요한 파일은 사용자가 불만족할 수 있습니다.
5. Nginx는 뛰어난 로드 밸런서/역방향 프록시 소프트웨어일 뿐만 아니라 강력한 웹 애플리케이션 서버이기도 합니다. LNMP는 최근 몇 년 동안 매우 인기 있는 웹 아키텍처이기도 하며 트래픽이 많은 환경에서도 안정성이 매우 좋습니다.
6. Nginx는 이제 웹 역가속 캐시로 점점 더 성숙해지고 있으며 기존 Squid 서버보다 빠릅니다.
7. Nginx는 중간 수준의 역방향 프록시로 사용할 수 있습니다. 이 수준에서는 Nginx와 비교할 수 있는 유일한 것이 lighttpd입니다. , 구성이 그다지 명확하지 않으며 읽기 쉽고 커뮤니티 정보가 Nginx보다 훨씬 덜 활성화되어 있습니다.
8. Nginx는 정적 웹페이지 및 이미지 서버로도 사용할 수 있으며 이 분야에서의 성능은 타의 추종을 불허합니다. Nginx 커뮤니티도 매우 활발하며 많은 타사 모듈이 있습니다.
Nginx의 단점은 다음과 같습니다.
2. 백엔드 서버의 상태 점검은 포트를 통한 감지만 지원하고 URL을 통한 감지는 지원하지 않습니다. Session의 직접 보유는 지원하지 않지만, ip_hash를 통해 해결할 수 있습니다.
LVS: Linux 커널 클러스터를 사용하여 확장성(Scalability), 신뢰성(Reliability), 관리성(Manageability)이 우수한 고성능, 고가용성 로드밸런싱 서버를 구현합니다.
LVS의 장점은 다음과 같습니다.
1. 강력한 부하 저항. 네트워크의 4번째 계층에서 작동하며 배포에만 사용됩니다. 이 기능은 부하 분산 소프트웨어에서도 성능을 결정합니다. . 상대적으로 적은 메모리와 CPU 리소스를 소비하는 가장 강력한 것입니다.
2. 구성 가능성이 상대적으로 낮다는 점은 단점이기도 하고 장점이기도 합니다. 너무 많이 구성할 수 있는 것이 없기 때문에 접촉이 많이 필요하지 않아 인적 오류가 발생할 가능성이 크게 줄어듭니다.
3. 부하 저항이 강하고 LVS+Keepalived와 같은 완전한 이중 머신 핫 백업 솔루션을 갖추고 있기 때문에 안정적으로 작동합니다. 그러나 프로젝트 구현에서 가장 많이 사용하는 것은 LVS/DR+Keepalived입니다.
4. 트래픽이 없습니다. LVS는 요청을 배포할 뿐이며 트래픽이 자체적으로 나가지 않습니다. 이는 대규모 트래픽에 의해 밸런서 IO의 성능이 영향을 받지 않도록 합니다.
5. LVS는 레이어 4에서 작동하기 때문에 적용 범위가 비교적 넓습니다. http, 데이터베이스, 온라인 채팅방 등 거의 모든 애플리케이션의 로드 밸런싱이 가능합니다.
LVS의 단점은 다음과 같습니다.
1. 소프트웨어 자체는 정규식 처리를 지원하지 않으며 동적 및 정적을 분리할 수 없으며 현재 많은 웹사이트에서 이에 대한 수요가 높습니다. 이것이 바로 Nginx/HAProxy+입니다. Keepalived의 장점.
2. 웹 사이트 애플리케이션이 상대적으로 큰 경우 LVS/DR+Keepalived는 구현하기가 더 복잡합니다. 특히 그 뒤에 Windows Server 시스템이 있는 경우 구현, 구성 및 유지 관리 프로세스가 상대적으로 더 복잡해집니다. , Nginx/HAProxy+Keepalived가 훨씬 간단합니다.
HAProxy의 특징은 다음과 같습니다.
1. HAProxy는 가상 호스트도 지원합니다.
2. HAProxy의 장점은 세션 보존 및 쿠키 안내 지원과 같은 Nginx의 일부 단점을 보완할 수 있으며, 지정된 URL을 획득하여 백엔드 서버의 상태 감지도 지원합니다.
3. HAProxy는 LVS와 유사하며 순전히 효율성 측면에서 로드 밸런싱 소프트웨어일 뿐입니다. HAProxy는 Nginx보다 로드 밸런싱 속도가 더 좋고 동시 처리에서도 Nginx보다 좋습니다.
4. HAProxy는 TCP 프로토콜의 로드 밸런싱을 지원하며, MySQL 읽기 로드 밸런싱을 지원하고, LVS+Keepalived를 사용하여 MySQL 마스터와 슬레이브의 로드 밸런싱을 수행할 수 있습니다.
5. HAProxy의 로드 밸런싱 전략은 현재 다음과 같은 8가지 유형이 있습니다.
첫 번째 라운드 로빈은 말할 것도 없이 기본적으로 로드 밸런싱을 의미합니다. > ② static-rr, 가중치 기준으로 주의를 기울이는 것이 좋습니다.
③ 최소 연결이 먼저 처리됨을 나타내는 최소 conn
④ source, 요청 소스에 따라 표시됩니다. IP는 Nginx의 IP_hash 메커니즘과 유사합니다. 세션 문제를 해결하는 방법으로 사용하므로 주의하는 것이 좋습니다.
⑤ ri는 요청에 따라 URI를 나타냅니다. 요청 'balance url_param'에 따른 URl 매개변수에는 URL 매개변수 이름이 필요합니다.
7 hdr(name)은 HTTP 요청 헤더
8 rdp-cookie(name)를 기반으로 각 HTTP 요청을 잠그는 것을 의미합니다. 쿠키(이름)를 기반으로 각 TCP 요청을 잠그고 해시하는 것을 의미합니다.
Nginx와 LVS 비교 요약:
1. Nginx는 네트워크의 7번째 계층에서 작동하므로 도메인 이름, 디렉터리 구조 등과 같은 http 애플리케이션 자체에 대한 전환 전략을 구현할 수 있습니다. 이와 대조적으로 LVS는 그렇지 않습니다. 이러한 기능을 사용하면 Nginx는 이것만으로도 LVS보다 훨씬 더 많은 상황에서 사용할 수 있습니다. 그러나 Nginx의 이러한 유용한 기능을 사용하면 LVS보다 조정이 더 쉬워지므로 자주 만지고 만져야 합니다. . , 인간 문제의 가능성이 더 커질 것입니다.
2. Nginx는 네트워크 안정성에 대한 의존도가 적습니다. 이론적으로 ping이 성공하고 웹페이지 액세스가 정상이면 Nginx에 연결할 수 있다는 점이 Nginx의 큰 장점입니다! Nginx는 내부 네트워크와 외부 네트워크가 모두 있는 노드인 경우 백업 라인이 있는 단일 시스템과 동일합니다. 현재 서버는 네트워크 환경에 더 많이 의존합니다. 동일한 네트워크 세그먼트와 LVS는 직접 모드를 사용하여 오프로드 효과를 더욱 보장합니다. 또한, LVS가 Visual IP로 사용하기 위해서는 호스팅 제공업체로부터 하나 이상의 IP를 추가로 신청해야 합니다. 자체 IP를 VIP로 사용할 수는 없는 것으로 보입니다. 훌륭한 LVS 관리자가 되려면 더 이상 HTTP만큼 간단하지 않은 네트워크 통신에 대해 많은 지식을 습득하고 후속 조치를 취해야 합니다.
3. Nginx 설치 및 구성은 비교적 간단하며, 기본적으로 로그에 오류를 출력할 수 있어 테스트하기에도 매우 편리합니다. LVS의 설치, 구성 및 테스트에는 상대적으로 오랜 시간이 걸립니다. LVS는 네트워크에 크게 의존하기 때문에 구성 문제가 아닌 네트워크 문제로 인해 실패하는 경우가 많습니다. 해결하기가 더 어렵습니다.
4. Nginx는 높은 로드를 견딜 수 있고 안정적이지만 로드와 안정성은 여러 수준이 있습니다. Nginx는 모든 트래픽을 처리하므로 자체 버그로 인해 여전히 제한됩니다. 피하다.
5. Nginx는 웹 페이지를 처리하는 서버에서 반환되는 상태 코드, 시간 초과 등 내부 서버 오류를 감지하고 오류를 반환하는 요청을 다른 노드에 다시 제출합니다. 현재 LVS의 ldirectd는 서버의 내부 상태 모니터링도 지원할 수 있지만 LVS의 원칙으로 인해 요청을 다시 보낼 수 없습니다. 예를 들어, 사용자가 파일을 업로드하고 있는데 업로드 프로세스 중에 업로드를 처리하는 노드가 실패하는 경우 Nginx는 재처리를 위해 업로드를 다른 서버로 전환하고 대용량 파일이 업로드되면 LVS의 연결이 직접 끊어집니다. 중요한 파일이 있으면 사용자가 짜증을 낼 수 있습니다.
6. Nginx의 비동기 요청 처리는 노드 서버가 로드를 줄이는 데 도움이 될 수 있습니다. Apache를 사용하여 외부 당사자에게 직접 서비스를 제공하는 경우 협대역 링크가 많으면 Apache 서버가 많은 양의 메모리를 차지하게 됩니다. Nginx를 하나 더 Apache 프록시로 사용하면 이러한 협대역 링크가 Nginx에 의해 차단되고 Apache에 너무 많은 요청이 누적되지 않으므로 상당한 양의 리소스 사용량이 줄어듭니다. Squid를 사용하면 이와 관련하여 동일한 효과가 있습니다. Squid 자체가 캐시하지 않도록 구성되어 있어도 Apache에는 여전히 큰 도움이 됩니다.
7. Nginx는 http, https 및 이메일을 지원할 수 있습니다(이메일 기능은 덜 일반적으로 사용됨). 이 점에서 LVS는 Nginx보다 더 많은 애플리케이션을 지원합니다. 사용 측면에서 일반적으로 프론트엔드에서 채택하는 전략은 LVS입니다. 즉, DNS가 LVS 이퀄라이저로 연결되어야 한다는 것입니다. LVS의 장점은 이 작업에 매우 적합합니다. 데이터베이스 IP, 웹 서비스 서버 IP 등과 같은 중요한 IP 주소는 LVS에서 가장 잘 관리됩니다. 시간이 지남에 따라 이러한 IP 주소는 IP 주소가 변경되면 점점 더 널리 사용됩니다. 따라서 이러한 중요한 IP를 LVS에 넘겨 호스팅하는 것이 가장 안전합니다. 그렇게 하면 필요한 VIP 수가 더 많아진다는 단점이 있습니다. Nginx는 LVS 노드 머신으로 사용될 수 있습니다. 첫째, Nginx의 기능을 활용할 수 있습니다. 둘째, Nginx의 성능을 활용할 수 있습니다. 물론 이 수준에서는 Squid를 직접 사용할 수도 있습니다. Squid의 기능은 Nginx에 비해 훨씬 약하고 성능도 Nginx에 비해 떨어집니다. Nginx는 중간 수준 프록시로도 사용할 수 있습니다. 이 수준에서 Nginx는 기본적으로 Nginx를 흔들 수 있는 유일한 것은 lighttpd이지만 lighttpd는 아직 그렇게 할 수 없습니다.
Nginx는 완벽하게 작동하며 구성이 명확하지도 않고 읽기 쉽지도 않습니다. 또한, 중간 에이전트의 IP도 중요하므로, 중간 에이전트에게도 VIP와 LVS를 갖는 것이 가장 완벽한 솔루션입니다. 특정 애플리케이션을 자세히 분석해야 합니다. 상대적으로 작은 웹사이트(일일 PV가 1,000만 개 미만)인 경우에는 Nginx를 사용하는 것이 좋습니다. 머신이 많으면 LVS를 계속 사용할 수 있습니다. ; 대규모 웹사이트나 중요한 서비스의 경우 시스템이 걱정되지 않으면 LVS 사용을 고려해야 합니다.
현재 네트워크 로드 밸런싱의 사용은 웹 사이트 규모가 증가함에 따라 다양한 단계에 따라 다양한 기술을 사용하는 것입니다.
1단계: 단일 지점 로드 밸런싱을 위해 Nginx 또는 HAProxy를 사용합니다. 이 단계에서는 서버 규모가 단일 서버 및 단일 데이터베이스 모델에서 벗어나 어느 정도의 로드 밸런싱이 필요합니다. 그러나 규모가 여전히 작고 이를 유지 관리할 전문적인 유지 관리 팀이 없습니다. 대규모 웹사이트 배포가 필요하지 않습니다. 이러한 방식으로 Nginx 또는 HAproxy를 사용하는 것이 첫 번째 선택입니다. 이러한 작업은 시작하기 쉽고 레이어 7 이상의 HTTP 프로토콜을 사용하기만 하면 됩니다. 이것이 첫 번째 선택입니다.
두 번째 단계: 네트워크 서비스가 더욱 확장됨에 따라 단일 포인트 Nginx는 더 이상 충분하지 않습니다. 특히 현재로서는 LVS 또는 상용 Array를 사용하는 것이 첫 번째 선택입니다. , LVS 또는 Array의 선택은 회사의 규모와 예산에 따라 결정됩니다. 저는 프로젝트에서 사용해 본 적이 있는데 가격 대비 성능 비율이 F5보다 훨씬 높습니다. 상업적인 이용! 그러나 일반적으로 이 단계의 관련 인재는 비즈니스 개선을 따라갈 수 없으므로 상용 로드 밸런싱을 구매하는 것이 유일한 방법이 되었습니다.
세 번째 단계: 네트워크 서비스가 주류 상품이 된 이때, 회사의 인기가 더욱 확대됨에 따라 관련 인재의 역량과 수량도 증가했습니다. 자사 제품에 맞는 커스터마이징 개발 및 오픈 소스 LVS는 비용 절감 측면에서 첫 번째 선택이 되었으며, LVS는 이때 주류가 될 것입니다.
최종 이상적인 기본 아키텍처는 Array/LVS — Nginx/Haproxy — Squid/Varnish — AppServer입니다.
이 블로그 게시물은 http://www.ha97.com/5646.html에서 복사되었습니다.
이상에서는 Nginx/LVS/HAProxy 로드 밸런싱 소프트웨어의 장점과 단점을 관련 내용을 포함하여 자세히 소개(요약)했습니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
