데이터 하이웨이: 데이터 웨어하우스 클러스터 통신 기술에 대한 자세한 설명

이 기사는 Hu Latang이 Huawei 클라우드 커뮤니티 " 라이브 방송 검토 | 데이터 하이웨이 - 데이터 웨어하우스 클러스터 통신 기술에 대한 자세한 설명 "에서 공유한 것입니다.

빅데이터 시대에는 클러스터의 규모가 점점 커지고, 비즈니스 동시성이 점점 높아지고, 데이터베이스 클러스터의 노드 간 통신 압력도 높아지고 있습니다. "데이터 하이웨이 - 데이터 웨어하우스 클러스터 통신 기술에 대한 자세한 설명"이라는 주제의 이번 생방송에서는 Huawei Cloud GaussDB(DWS) 기술 전도사인 Wei Deng 씨를 초대하여 GaussDB(DWS) 클러스터 통신 기술이 어떻게 수행될 수 있는지 심층적으로 설명했습니다. 대규모 배포 클러스터에서 동시성 높은 서비스를 전달할 때 고성능 분산 통신 시스템을 구현하는 방법

1. GaussDB(DWS) 클러스터 통신 개요

GaussDB(DWS) 클러스터에는 하나 이상의 조정 노드(CN)가 있으며 각 호스트에는 여러 개의 데이터 노드(CN), 글로벌 트랜잭션 컨트롤러(GTM), 운영 및 유지 관리 모듈(OM), 클러스터 관리 모듈( CM), 데이터 가져오기 및 내보내기 모듈(GDS).

  • CN(조정 노드): 요청 분해, 예약, 결과 반환, SQL 구문 분석 및 최적화를 담당하며 데이터가 아닌 메타데이터만 저장됩니다.
  • 데이터 노드(DN): 실제 테이블 데이터(지정된 배포 방식: 해시 테이블, 복제 테이블, RroundRobin 테이블)를 저장하고 SQL 작업을 실행하고 실행 결과를 CN으로 반환하는 역할을 담당합니다.
  • 글로벌 트랜잭션 컨트롤러(GTM) : 글로벌 트랜잭션 ID, 트랜잭션 스냅샷, 타임스탬프 및 기타 전역적으로 고유한 정보를 생성하고 유지 관리하는 역할을 담당합니다.
  • 운영 및 유지보수 관리 모듈(OM) : 일상적인 운영 및 유지보수, 구성 관리 기능을 제공합니다.
  • 클러스터 관리 모듈(CM) : 클러스터 관리 및 각 유닛의 물리적 자원 사용량 모니터링.
  • GDS 로더 : 일괄 데이터 로딩, 병렬 가속

위의 모든 모듈은 클러스터 네트워크를 통해 서로 통신합니다.클러스터 통신은 실행기, 옵티마이저, 스토리지 등의 기존 데이터베이스 모듈과 다릅니다.클러스터 통신은 분산 데이터베이스에만 해당됩니다. 클러스터 성능 최적화는 클러스터 문제를 찾는 데 큰 영향을 미칩니다.

다음 그림은 GaussDB(DWS) 클러스터의 개요를 나타낸 것으로, 컨텐츠 공유를 통해 그림을 단순화하였습니다. GaussDB(DWS)는 Share Nothing 아키텍처를 사용하는 MPP 분산 데이터베이스입니다. 데이터는 다양한 DN 노드에 분산되어 저장됩니다. CN은 데이터를 저장하지 않으며, 쿼리 수신을 위한 진입점으로 생성된 계획을 DN으로 푸시하여 최대한 병렬 실행하여 성능을 향상시킵니다. DN이 다중 테이블 Join을 수행할 때 로컬 DN은 부분적인 데이터만 가지고 있기 때문에 테이블 데이터나 중간 결과를 중앙에서 분산시키기 위해서는 DN 간의 데이터 교환이 필요합니다.

GaussDB(DWS) 일반 쿼리의 데이터 통신 프로세스: (녹색 화살표)

  • 클라이언트는 CN에 연결하고 쿼리를 실행합니다.
  • CN은 모든 DN을 연결하고 실행 계획을 생성 및 발행합니다.
  • 네트워크를 통해 DN 간에 테이블 데이터 또는 중간 결과를 교환합니다.
  • DN은 로컬에서 데이터 처리를 수행하고 결과 세트를 CN으로 반환합니다.
  • CN은 결과 집합을 집계 및 처리하여 클라이언트에 반환합니다.

GaussDB(DWS) 클러스터 통신 개요

2. CN 통신 프레임워크 소개

 

1. IP 및 포트 정보

클라이언트는 IP 포트를 통해 CN에 연결하는데, CN의 pgxc_node 시스템 테이블은 클러스터에 있는 모든 노드의 IP 및 포트 정보를 저장하여 CN이 클러스터의 다른 노드에 연결할 수 있도록 도와줍니다.

아래 그림의 pgxc_node 시스템 테이블에서 node_port와 node_host는 호스트 정보이고, node_port1과 node_host1은 대기 정보입니다. Hostis_primary는 마스터-대기 관계를 가지며, t이면 CN이 호스트에 먼저 연결한 다음 대기 호스트에 연결하고 그 반대의 경우도 마찬가지입니다. Hostis_primary 값은 활성/대기 전환 중에 CM 클러스터 관리 구성 요소에 의해 자동으로 새로 고쳐집니다.

2. 클라이언트는 CN과 통신합니다.

클라이언트는 쿼리 프로세스를 실행합니다.

  • 클라이언트는 CN의 수신 포트에 대한 연결을 시작합니다.
  • CN postmaster 메인 스레드는 연결을 수락하고 postgres 스레드를 생성한 후 처리를 위해 이 스레드에 연결을 전달합니다.
  • 클라이언트는 쿼리를 CN으로 보냅니다.
  • CN의 postgres 스레드는 쿼리 계획을 다른 CN/DN에 전달하고 쿼리 결과는 원래 경로를 따라 클라이언트에 반환됩니다.
  • 클라이언트 쿼리가 종료되고 연결이 닫힙니다.
  • CN의 해당 postgres 스레드가 삭제되고 종료됩니다.

클라이언트와 CN 간의 통신 다이어그램

CN과 DN 사이의 연결을 설정하는 과정은 기본적으로 클라이언트와 CN 사이의 과정과 동일합니다. CN과 DN 간의 연결 설정에 따른 오버헤드와 DN 프로세스에서 postgres 스레드의 생성 및 삭제를 줄이기 위해 CN 측은 풀러 연결 풀을 구현합니다.

3. 풀러 연결 풀

풀러 연결 풀은 CN과 다른 CN/DN 프로세스 간의 모든 연결을 저장합니다. 각 연결은 다른 CN/DN의 postgres 스레드에 해당합니다. 풀러 연결 풀은 연결과 스레드를 재사용하여 연결을 설정하고 postgres 스레드를 생성 및 삭제하는 오버헤드를 줄입니다.

풀러 재사용 프로세스:

  • 세션을 연결해야 하는 경우 DB+USER를 통해 키에 대한 올바른 풀러 연결 풀을 찾고 먼저 기존 연결을 가져옵니다.
  • 쿼리가 끝난 후 CN의 postgres 스레드는 연결을 반환하지 않으며 해당 연결은 현재 세션의 다음 쿼리에 사용될 수 있습니다.
  • 세션이 끝난 후 CN의 postgres 스레드는 해당 풀러에 대한 연결을 반환합니다. 해당 DN의 postgres 스레드는 종료되지 않으며 ReadCommand에 있으며 CN의 새 postgres 스레드가 재사용 후 작업을 시작하기를 기다리고 있습니다.

풀러 연결 풀 다이어그램

4. 풀러

pg_pooler_status 뷰는 풀러 연결 풀의 모든 연결 정보를 기록합니다. 아래 그림에 표시된 것처럼 각 줄은 이 CN에 의해 ​​시작된 연결을 나타내며, 이는 상대 프로세스의 postgres 스레드에 해당합니다. in_use는 스레드에서 연결을 사용하고 있음을 의미하는 't'이고, 유휴 연결이 재사용을 기다리고 있음을 의미하는 'f'입니다. tid는 이 연결을 보유하는 이 CN의 스레드 번호로 나열되고, node_name은 피어 프로세스 번호로 나열되며, remote_pid는 피어 스레드 번호로 나열됩니다. query_id가 0이거나 CN/DN이 일치하지 않는 경우 풀러 뷰를 통해 CN과 DN 연결 관계를 찾습니다.

5. 풀러 연결 청소

연결 풀 정리 메커니즘에는 세션이 보유하는 연결과 풀러의 유휴 연결 풀에 있는 연결이라는 두 가지 유형이 있습니다.

세션에서 보유한 연결:

  • 캐시 연결, 풀러 연결 풀을 사용하여 연결을 캐시할지 여부;
  • session_timeout, 클라이언트 연결은 유휴 시간 초과 후 오류를 보고하고 연결을 종료한 후 반환합니다.
  • 활성화_force_reuse_connections, 트랜잭션이 끝난 후 강제로 연결이 반환됩니다.
  • conn_recycle_timeout(2.1), CN 유휴 세션 시간이 초과된 후 연결을 반환합니다.

유휴 연결 풀의 풀러 연결:

  • pg_clean_free_conn은 유휴 연결 풀 연결의 1/4을 정리하고 CM은 이를 정기적으로 호출합니다.
  • 연결 정리, DB 또는 사용자에 해당하는 모든 유휴 연결을 정리합니다.

3. DN 통신 프레임워크 소개

1. 스트림 운영자

GaussDB(DWS)는 Share Nothing 아키텍처를 사용하는 MPP 분산 데이터베이스로, 데이터는 다양한 DN 노드에 저장되며, Join 조건을 만족하는 두 테이블의 데이터는 동일한 DN에 분산되어야 하며, 조건을 만족하지 않는 테이블은 즉, 스트림 연산자가 생성됩니다.

각 스트림 운영자는 비동기 네트워크 IO를 처리하기 위해 두 개의 스레드가 필요합니다. 데이터를 보내는 하위 계층을 생산자라고 하며, 데이터를 받는 상위 계층을 소비자라고 합니다.

2. 스트림 스레드

DN의 각 스트림 운영자는 네트워크 데이터를 비동기적으로 전송하기 위해 스트림 스레드를 시작해야 합니다. SMP 병렬 처리가 활성화된 경우 스트림 운영자는 여러 스트림 스레드를 시작하고 DN 간에 더 많은 연결을 설정해야 할 수 있습니다. 스트림 연산자(스트리밍)에는 세 가지 유형이 있습니다.

  • GATHER: CN은 DN과 통신하고 DN 결과 세트를 수집합니다.
  • BROADCAST: DN은 모든 로컬 데이터를 다른 DN으로 브로드캐스트합니다.
  • REDISTRIBUTE: DN은 로컬 데이터를 해시하여 해당 DN으로 보냅니다.

3. 스트림 스레드 풀

스트림 스레드 풀은 DN 스트림 스레드의 재사용을 구현하고 스트림 스레드 생성, 초기화, 정리 및 삭제의 오버헤드를 방지합니다.

스트림 스레드 풀은 잠금 없는 대기열을 사용하여 구현되었으며, 2000개의 스트림 스레드가 동시에 시작되고 시간은 2초에서 10ms로 최적화됩니다. 스트림 연산자가 스트림 스레드를 요구하는 경우, DB 이름을 통해 해당 스트림 스레드 풀을 일치시키고, 동일한 DB의 기존 스레드를 먼저 재사용합니다. 생성된 스트림 스레드는 쿼리가 완료된 후 재사용을 대기하기 위해 스레드 풀에 배치됩니다. 스트림 스레드 풀의 스레드 자체에는 유휴 상태일 때 시간 초과 기능이 있으며 60초마다 1/4이 재활용됩니다. max_stream_pool 매개변수는 스레드 풀 캐시의 상한값을 설정하며, 0일 경우 스트림 스레드 풀 기능이 꺼지도록 하며, 일시적으로 스트림 스레드를 정리하도록 설정할 수도 있다.

스트림 스레드 풀 다이어그램

4. Libcomm 통신 라이브러리

클러스터가 1000개의 DN에 도달하면 각 스트림 스레드는 1000개의 연결을 설정해야 합니다. 1000개의 스트림 스레드가 동시 실행되는 경우 DN은 총 100만 개의 연결을 설정해야 하며, 이는 많은 연결, 메모리 및 FD 리소스를 소비하게 됩니다. 이러한 상황을 바탕으로 Libcomm 통신 라이브러리가 설계되었으며, Libcomm 통신 라이브러리는 물리적으로 긴 연결에서 n개의 논리적 연결을 시뮬레이션하여 모든 동시 데이터가 하나의 물리적 연결에서 실행되도록 하여 과도한 물리적 연결 수와 시간 문제를 해결했습니다. 연결 설정을 소비하는 문제입니다.

4. 의사소통 문제 찾기

 

1. 통신 끊김 문제

통신 중단 문제를 찾는 단계:

  • pgxc_stat_activity 뷰에서 문제 쿼리의 query_id를 찾으세요.
  • query_id를 기반으로 pgxc_thread_wait_status 뷰를 쿼리합니다.
  • 대기 노드를 필터링하고, 데이터를 플러시하고, 종료 상태를 동기화한 후 쿼리 차단 지점을 찾습니다.
  • 위의 세 가지 상태가 모두 위의 세 가지 상태에 해당하는 경우 추가 위치 지정을 위해 Libcomm 논리적 연결 보기를 사용하십시오.

2. 통신 오류 문제

일반적인 통신 오류 문제는 그림과 같습니다.

3. 통신 성능 문제 찾기

  • 성능 분석 설명을 사용하십시오.

  • 정지 문제에 따라 핫 블로킹 스택을 찾으십시오.
  • gsar 도구를 사용하여 환경에서 네트워크 패킷 손실 및 재전송이 발생하는지 확인하십시오.

4. 네트워크 환경 문제

  • gsar 도구를 사용하여 네트워크 패킷 손실 및 재전송이 발생하는지 확인합니다.
  • 재전송이 발생하는 연결을 확인하려면 netstat 명령을 사용하십시오.

gs_ssh -c "netstat -anot|grep 'on ('|grep -v '/0/0'|sort -rnk3|head“|grep tcp

  • 연결의 양쪽 끝에 있는 시스템에서 ksoftirq 프로세스의 CPU 사용량이 비정상적인지 확인하려면 top 명령을 사용하십시오.
  • ping, telnet 및 tcpdump를 사용하여 패킷 손실 문제를 추가로 분석합니다.

GaussDB(DWS) 제품의 기술 분석 및 데이터 웨어하우스 제품의 새로운 기능 소개에 대한 자세한 내용은 GaussDB(DWS) 포럼을 주목해 주시기 바랍니다. 기술 블로그 공유 및 라이브 방송 준비가 게시됩니다. 가능한 한 빨리 GaussDB(DWS) 포럼에 게시하세요.

포럼 링크: https://bbs.huaweicloud.com/forum/forum-598-1.html

라이브 재생 링크: https://bbs.huaweicloud.com/live/cloud_live/202312191630.html

 

화웨이 클라우드의 신기술에 대해 빨리 알아보고 팔로우하려면 클릭하세요~

Bilibili 두 번 충돌, Tencent '3.29' 1급 사고... 2023년 상위 10개 다운타임 사고 살펴보기 Vue 3.4 'Slam Dunk' MySQL 5.7, Moqu, Li Tiaotiao 출시… 2023년 '정지' 살펴보기 더보기 ” (오픈 소스) 프로젝트와 웹 사이트는 30년 전의 IDE를 되돌아봅니다: 오직 TUI, 밝은 배경색... Redis의 아버지인 Bram Moolenaar에게 헌정하는 Vim 9.1 출시, "신속한 검토" LLM 프로그래밍: 전지적 그리고 Omnipotent&& Stupid "Post-Open Source" 시대가 왔습니다. 라이선스가 만료되어 일반 대중에게 서비스를 제공할 수 없습니다. China Unicom Broadband가 갑자기 업로드 속도를 제한했고 많은 사용자가 불만을 토로했습니다. Windows 경영진은 개선을 약속했습니다. Make the Start 메뉴가 다시 훌륭해졌습니다. Pascal의 아버지인 Niklaus Wirth가 세상을 떠났습니다.
{{o.이름}}
{{이름}}

추천

출처my.oschina.net/u/4526289/blog/10576039