클러스터 개요 및 분류

1. 클러스터의 원리와 기능

1. 클러스터 란 무엇입니까?
간단히 말해 클러스터는 함께 작동하는 서버 그룹입니다.

2. 클러스터링의 목적?
1) 높은 동시성
2) 더 안정적, 즉 높은 견고성
3) 높은 적시성

3. 서버 성능을 향상시키는 방법
3.1 수직 확장
보다 강력한 소프트웨어 / 하드웨어 교체
단점 :
1) 소프트웨어와 하드웨어에 상한선이 있으며 병목 현상이 분명합니다.
우선 nginx와 같은 소프트웨어는 현재 리소스를 모두 차지하여 동시성으로 변환 할 수 없습니다. 둘째, 운영 체제 자체가 제한적입니다. 이론적으로 단일 프로세스는 최대 65535 개의 스레드를 지원할 수 있습니다. 즉, 단일 프로세스의 최대 동시성은 65535입니다. CPU의 코어 수는 이론적으로 단일 서버가 지원할 수있는 최대 동시성 양입니다. 한 가지 제한은 응용 프로그램이 현재 리소스를 완전히 이해할 수 있는지 여부이고 다른 하나는 서버 리소스를 계속 개선 할 수 있는지 여부입니다.
2) 서버를 업그레이드하거나 교체하면 서버가 다운되어 서비스 액세스가 중단됩니다.
장점 :
1) 기술 구현의 어려움이 낮음
2) 네트워크 토폴로지를 변경할 필요가 없음 (가장 큰 장점)

3.2 수평 적 확장
서버 수 증가의
장점 :
1) 소프트웨어 및 하드웨어의 상한이 높다
2) 노드 추가 서비스가 중단되지 않음
3) 비용 대비 성능이 우수
단점 :
1) 기술적 구현이 더 어렵다.

3.3
수평 확장의 공통 구현 방안 1) 1 세대 수평 확장 구현 방안
거의 모든 부하 분산은 몇 년 전 DNS 서버를 통해 구현되었으며, DNS 서버의 동일한 도메인 이름에 여러 개의 서로 다른 A 레코드를 추가함으로써, rr 폴링 메커니즘을 사용하여 도메인 이름을 다른 ip를 가진 서버로 확인합니다.
이후 캐시 서버는 DNS 서버의 액세스 분산 균형에 영향을 미치는 도메인 이름 확인 결과를 기록했으며, DNS 서버는 도메인 이름을 액세스에 사용하는 경우에만 부하 분산을 달성 할 수 있으며 사용 영역이 매우 좁아 제거되었습니다.

2) 2 세대 수평 확장 구현 계획 :
기본 아키텍처는 에이전트 (프론트 엔드 구성 요소), 실제 서버 및 공유 스토리지의 세 부분으로 구성됩니다.
예를 들어 Nginx로드 밸런싱에서 Apache는 웹 액세스로드 서버 역할을하고 MySQL은 데이터베이스 역할을합니다. 일부 사용자 기반 메타 데이터는 일반적으로 사용자 이름 및 비밀번호와 같은 데이터베이스에 기록됩니다. 비디오 화면 및 사용자 아바타와 같은 기타 데이터는 일반적으로 공유 저장소 (SHARE)에 저장됩니다.

2. 공통 클러스터 소개

1. 부하 분산 클러스터 (LBC)
1.1 부하 분산 클러스터 란 무엇입니까?
LBC 부하 분산 클러스터는 단일 서버의 압력을 다른 서버의 노드에 공유하는 것입니다.
구조 : 프런트 엔드 구성 요소 (로드 스케줄러), 실제 서버, 공유 스토리지

1.2 생각 : 클러스터의 웹 서버 액세스 압력이 너무 높으면 확장, 즉 실제 서버 노드를 추가하여 문제를 해결하는 것을 고려할 수 있습니다. 그러나 Nginx 부하 분산 서버가 너무 많은 압력을 받고 있다면 어떻게 해결할 수 있습니까?
솔루션 1 : 프런트 엔드 구성 요소 및로드 스케줄러의 성능을 향상시킵니다.
옵션 2 : 서로 다른 비즈니스를 서로 다른 클러스터에 할당합니다.
솔루션 3 : 데이터 지원을 제공하기 위해 일부 캐시 서버를 추가하고 다른 노드에 캐시하십시오. 예를 들어 Douyu에서 사용하는 CDN 기술은 각 도시 노드에서 캐시 된 데이터에 의해 지원됩니다.

1.3로드 스케줄러의 분류
1) 소프트웨어 / 하드웨어로 구분
소프트웨어 : amoeba, Nginx, LVS, Ha-Proxy (linux-HA)
하드웨어 : ROSE, Anrui Technology, F5

2) OSI 7 계층 모델에 따라 OSI 7 계층 모델을 구분하기 위해
물리 계층, 데이터 링크 계층, 네트워크 계층, 전송 계층, 세션 계층, 표현 계층, 응용 계층
,로드 스케줄러를 구현할 수 있는 계층 은 다음과 같다. 전송 계층, 응용 계층

1 "두 번째 계층 (데이터 링크 계층)
에서로드 스케줄러 실현합니다.로드 스케줄러의 기능 실현하는 하드웨어 도구 : F5
원칙 : 서로 다른 공용 네트워크 케이블을 서로 다른 네트워크 카드에 연결하고 사용자가 사용하는 공용 네트워크 유형에 따라 서로 다른 네트워크 카드를 통해 전송합니다. 사용자 데이터 패킷은로드 스케줄러의 기능을 구현합니다. 현재이 기능을 지원하는 하드웨어 (예 : F5)에는이를 지원할 수있는 공용 소프트웨어가 없습니다.
예 : 예를 들어 현재 국내 네트워크 연결 상태가 좋지 않습니다. 사용자가 World Wide Web에 액세스하면 여러 도시에서 서로 다른 네트워크 제공 업체의 네트워크가 서로 수렴하지 않기 때문에 데이터를 일부 핵심 노드로 보내야합니다. 두 번째 계층을 사용할 수 있습니다. 네트워크 사용량 부하 스케줄러는 방문자의 IP에 따라 방문자가 사용하는 공용 네트워크의 종류를 다른 제공자의 공용 네트워크와 구분하여 각 공용 네트워크의 웹 서버에 할당하여 전용선 접속이 항상 동일한 네트워크에서 완료되고 접속이 향상되도록합니다. 유효성.

2 "네 번째 계층 (전송 계층)에
로드 스케줄러 구현로드 스케줄러 기능 구현하는 도구 : LVS (가장 많이 사용됨), Ha-Proxy (linux-HA), Nginx (새 버전)
원칙 : 하나의 TCP 연결 만 완료됩니다. 고객 끝과 실제 서버 사이.
프로세스 : 클라이언트는로드 디스패처에 액세스 요청을 보내고로드 디스패처는 요청을 실제 서버에 직접 전달합니다. 요청을 수신 한 후 실제 서버는 발견 된 데이터를로드 디스패처에 전송하고로드 디스패처는 데이터를 클라이언트에 직접 전달합니다. 종료. 이는로드 호출자가 클라이언트에게 실제 서버의 위치를 ​​알려 주기만하면 클라이언트가 데이터를 가져올 실제 서버를 찾을 수 있도록하는 것과 같습니다.
보안 : SYN 공격은 가로 챌 수 없으며 실제 서버는 클라이언트의 SYN 공격에 취약합니다.
범위 :로드 스케줄러는 클라이언트 및 실제 서버와 완전한 TCP 연결을 설정할 필요가 없기 때문에 C / S 구조라면 TCP UDP 기반으로 개발 된 서비스 시스템을 사용할 수 있습니다.
동시성 : 계층 4는 계층 7보다 큽니다 (TCP 연결 및 워크 플로의 수에서 볼 수 있음).

3 "7 번째 계층 (애플리케이션 계층)에서
로드 스케줄러 구현로드 스케줄러 기능 구현하는 도구 : Nginx (가장 많이 사용됨) Ha-Proxy (linux-HA)
팁 : 도메인 이름과 호스트 이름을 사용하여로드 밸런싱 스케줄러를 구현하려면 , 7 번째 레이어에서만 완료 할 수 있으며 7 번째 레이어에서만 인식 할 수 있습니다.
원칙 : 완전한 2 개의 완전한 TCP 연결, 첫 번째는 클라이언트와로드 스케줄러, 두 번째는로드 스케줄러와 실제 서버입니다.
프로세스 : 클라이언트는 액세스 요청을로드 스케줄러에 보내고로드 스케줄러는 요청 메시지를 수신 한 후 디스 어셈블 한 다음 다시 캡슐화 한 다음 요청을 수신 한 후 실제 서버로 새로운 요청 메시지를 보냅니다. 발견 된 데이터는로드 스케줄러로 전송되고로드 스케줄러는 데이터를 클라이언트로 전송합니다. 클라이언트가 실제 서버에서 데이터를 가져 오는 데 도움이되는로드 스케줄러와 동일합니다.
보안 : SYN 공격을 차단할 수 있습니다.
범위 :로드 스케줄러는 클라이언트 및 실제 서버와 동시에 완전한 TCP 연결을 설정해야하므로로드 스케줄러는 인식하는 프로토콜 모드 만로드 할 수 있습니다.
동시성 : 7 개 레이어보다 큰 4 개 레이어

네 번째 및 일곱 번째 계층 요약 정보 :
클러스터 동시성이 강하지 않음, 보안 요구 사항이 높음, 7 계층로드
클러스터 동시성이 강하지 않지만 도메인 이름을 식별해야 함
, 보안 요구 사항에 관계없이 7 계층로드 클러스터 동시성이 강함 4 계층로드를 사용하는 방법
클러스터에는 강력한 동시성과 높은 보안 요구 사항이 있습니다. 4 계층 또는 7 계층로드를 사용합니다.

2. 고 가용성 클러스터 (HAC)
2.1 정의
서버 가용성을 극대화하는 클러스터입니다.
가용성 기준 : 99 % (통과 선, 전체 길이가 약 3.65 일인 경우 연간 서버 다운 타임에 해당)
99.9 %
99.99 %
~ 99.999 % (현재 업계 최고 수준, 총 길이가 약 315 초인 경우 연간 서버 다운 타임에 해당)
팁 : 표준 개선으로 실현 비용 (비용)이 기하 급수적으로 상승했습니다.
2.2 목적
로드 스케줄러의 단일 노드 장애로 인한 전체 클러스터의 마비 방지합니다.
2.3 원칙
하트 비트 감지.
동일한 기능을 가진 두 대의 서버 중 하나는 사용자 액세스 요청을 수신하고 실제 서버에 압력을 분산하는 주 서버 역할을하고, 다른 하나는 주 서버에 하트 비트 감지를 지속적으로 전송하는 상시 대기 서버 역할을합니다. 상시 대기 서버가 주 서버가 다운 된 것을 발견하면 주 서버의 작업을 인계하기 위해 주도권을 잡습니다.
2.4 고 가용성 서버 쌍 스위칭 IP
1) 네트워크 카드에서 하위 인터페이스를 열고 메인 서버와 동일한 IP를 구성하고 스크립트로 구현합니다
.2) VRRP 라우팅 중복 프로토콜을 사용하여 달성합니다.
2.5 고 가용성 클러스터의 단점 낮은
리소스 활용도
2.6 분할 브레인 문제의 고 가용성 서버
1) 분할 브레인이란?
몇 가지 이유로 인해 두 개의 고 가용성 서버 쌍은 지정된 시간 내에 서로의 하트 비트 메시지를 감지하지 못하여 리소스 및 서비스의 소유권을 얻습니다. 현재 두 개의 고 가용성 서버 쌍은 여전히 ​​활성화되어 있습니다. 정상적인 동작은 IP 나 서비스가 양단에 존재하고 충돌을 일으키며, 사용자가 데이터를 쓸 때 양단에 따로 쓰게되어 서버 양단의 데이터 불일치 나 데이터 손실이 발생할 수 있습니다. 이 상태를 분할 브레인이라고합니다.

2) 브레인 분할의 가능한 원인
1 "고 가용성 서버 쌍 간의 하트 비트 링크가 잘못되어 정상적인 통신이 이루어집니다.
2 "하트 비트 라인이 끊어졌습니다 (파손, 노화 포함).
3 "네트워크 카드 및 관련 드라이버가 손상됨, IP 구성 및 충돌 문제 (네트워크 카드가 직접 연결됨).
4》 하트 비트 라인 사이에 연결된 장비에 결함이 있습니다 (네트워크 카드 및 스위치).
5 "중재 계획이 채택되고 중재 기계에 문제가 있습니다.
6 "고 가용성 서버 쌍에서 iptables 방화벽이 활성화되어 하트 비트 메시지 전송을 차단합니다.
7 "고 가용성 서버에 하트 비트 네트워크 카드 주소 및 기타 정보가 잘못 구성되어있어 하트 비트 전송에 실패합니다.
8 "다른 하트 비트 모드, 하트 비트 브로드 캐스트 충돌, 소프트웨어 버그 등과 같은 부적절한 서비스 구성과 같은 기타 이유.
9 "virtual_router_id 매개 변수의 구성이 양쪽 끝에서 일치하지 않는 경우 연결 유지 구성의 동일한 VRRP 예.

3) 솔루션
1 "Redundant heartbeat line
2"상시 대기 서버는 정확한 감지 결과를 보장하기 위해 간헐적으로 여러 번 감지합니다.
3 "상시 대기 서버는 네트워크 명령을 통해 제어 전원 스위치에 연결하여 주 서버 전원을 차단합니다.

2.7 고 가용성 클러스터 구현 솔루션
소프트웨어 : 하트 비트 (linux-ha), Keepalived
하드웨어 : ROSE, Anrui Technology, F5

3. HPC (고성능 컴퓨팅 클러스터)
3.1 정의
단일 컴퓨터가 제공 할 수없는 컴퓨팅 성능을 제공합니다.
3.2 원리
처리 할 데이터를 n 개로 분할하여 n 개의 컴퓨터에 할당하면 각 컴퓨터가 1 개씩 처리하고 마지막으로 처리 된 결과를 집계하여 최종 결과를 얻습니다.
3.3 특징
강력한 특이성과 좁은 사용 영역
3.4 고성능 컴퓨팅 클러스터와로드 밸런싱 클러스터의 차이점을 이해하기위한 한 가지 질문
예 : 작업 A는 이론적으로 10a로 나눌 수 있으며 이제 동일한 성능을 가진 11 개의 서버가 있습니다. 문제는 다음과 같습니다 :
LBC를 ​​구축하는 경우 프로세스 1 A, 계산에 총 2 개의 노드가 포함되고 프로세스 0 a;
HPC를 구축하는 경우 프로세스 1 A, 총 11 개의 노드가 계산에 포함되고 10 a가 처리됩니다. .

추천

출처blog.csdn.net/weixin_43455673/article/details/112251392