이 기사는 Huawei Cloud 커뮤니티 " [GaussTech Express] 세분화된 리소스 관리 및 제어에 대한 기술적 해석 ", 저자: GaussDB 데이터베이스 에서 공유되었습니다 .
배경
데이터베이스 클러스터 내의 리소스 제어 및 리소스 격리는 기업 고객의 오랜 요구 사항이었습니다. 기업 수준의 분산 데이터베이스인 Huawei Cloud GaussDB는 대규모 데이터베이스 클러스터에 대한 기업의 관리 요구 사항을 충족하기 위해 노력해 왔습니다.
데이터베이스가 관리할 수 있는 리소스에는 컴퓨팅 리소스와 스토리지 리소스가 포함됩니다. 컴퓨팅 리소스에는 CPU, 메모리, IO, 네트워크가 포함됩니다. 스토리지 리소스에는 데이터 저장 공간, 로그 저장 공간, 임시 파일이 포함됩니다.
사용자 관점에서 볼 때 리소스 관리 및 제어는 리소스 사용에 대한 임계값 또는 우선 순위 제한을 설정함으로써 서비스 수준 계약을 보장하는 동시에 여러 사용자 간의 리소스 격리를 충족하고 여러 테넌트 간에 데이터베이스 리소스를 공유하는 목적을 달성합니다.
시스템 관점에서 볼 때, 리소스 모니터링 및 제어 방법을 도입하면 제어 가능한 조건에서 리소스를 합리적으로 활용하고 리소스 고갈을 방지하며 시스템의 응답 중지 및 충돌을 방지할 수 있습니다. 작업 우선순위는 작업의 원활한 운영을 보장하고, 리소스 사용량이 너무 높을 때 작업이 다른 작업에 영향을 미치는 것을 방지하며, 리소스가 풍부할 때 리소스 활용도를 극대화할 수 있습니다. 또한 외부 기대치를 충족하고 시스템 리소스의 최대 활용을 보장할 수도 있습니다. 작업을 제어함으로써 작업이 안정적인지 확인하고 작업 실행 중에 제어할 수 없는 동작을 방지할 수 있습니다.
위의 목표를 해결하기 위해 Huawei Cloud GaussDB 데이터베이스는 데이터베이스 클러스터 내 리소스의 세분화된 관리 및 제어, 즉 세분화된 리소스 관리 및 제어를 위한 솔루션을 제공합니다. 이 솔루션은 다양한 제어 세분화(예: 사용자 수준, 세션 수준, 명령문 수준) 및 다양한 제어 차원(CPU, 메모리 및 IO)에서 해당 관리 및 제어 기능을 제공합니다. 사용자는 자신의 비즈니스 요구 사항에 따라 적절한 제어 차원과 제어 세분성을 채택하여 리소스 제어 및 리소스 격리 목표를 달성하고 다양한 시나리오에서 리소스 제어 요구 사항을 충족할 수 있습니다.
기술 아키텍처
먼저 세분화된 리소스 관리 및 제어의 기술 아키텍처와 운영 원칙을 살펴보겠습니다.
위 그림에서 볼 수 있듯이 GaussDB는 CPU, 메모리, IO의 관리 및 제어 로직을 완성하기 위한 리소스 풀 모듈을 제공합니다. 사용자는 리소스 풀을 생성하고 사용할 수 있는 CPU, 메모리 및 IO 공유를 지정하고 리소스 풀을 사용자에게 바인딩할 수 있습니다. 이후 사용자가 시작한 작업은 데이터베이스 커널 최적화 및 구문 분석, 실행 엔진 및 스토리지 엔진 모듈이 작동하는 동안 실시간 리소스 관리 및 제어를 거쳐 해당 작업의 CPU, 메모리 및 IO가 해당 작업 범위 내에 있는지 확인합니다. 해당 리소스 풀의 범위.
A 회사가 GaussDB 인스턴스를 배포하고 OLTP 비즈니스, 보고서 비즈니스 및 기타 우선 순위가 낮은 비즈니스와 같은 세 가지 다른 애플리케이션이 동시에 인스턴스에 액세스한다고 가정합니다. A사는 자원 활용을 극대화하면서 시스템이 원활하게 운영될 수 있도록 3개 사업의 자원을 합리적으로 관리 및 통제하기를 희망합니다. 시스템 관리자를 통해 다음 명령을 실행하여 세 명의 비즈니스 사용자에 대한 리소스 공유 비율을 50:30:10으로 설정하고 나머지 10%는 시스템용으로 예약할 수 있습니다.
다음은 간단한 사용 예입니다. 각 매개변수의 구체적인 의미는 다음 장에서 자세히 설명합니다.
(control_group="cgroup_tp", max_dynamic_memory="5GB", max_shared_memory="5GB", io_limits=50, io_priority="High")을 사용하여 리소스 풀 respool_tp를 생성합니다. 역할 tp_user 리소스 풀 'respool_tp' 변경; (control_group="cgroup_report", max_dynamic_memory="3GB", max_shared_memory="3GB", io_limits=30, io_priority="Medium")을 사용하여 리소스 풀 respool_report를 생성합니다. 역할 Report_user 리소스 풀 'respool_report' 변경; (control_group="cgroup_other", max_dynamic_memory="1GB", max_shared_memory="1GB", io_limits=10, io_priority="Low")로 리소스 풀 respool_other를 생성합니다. other_user 리소스 풀 'respool_other' 역할 변경;
위 작업 후 OLTP 비즈니스, 보고서 비즈니스 및 기타 우선순위가 낮은 비즈니스가 tp_user, report_user 및 other_user를 사용하여 GaussDB에 연결하여 작업을 실행하는 경우 이 세 비즈니스는 해당 리소스 풀 respool_tp, respool_report 및 respool_other에 의해 제어됩니다. 리소스 경합이 발생하면 세 기업이 각각 GaussDB 클러스터 리소스의 50%, 30%, 10%를 사용할 수 있음이 보장됩니다.
주요 기능
세분화된 리소스 관리 및 제어의 전반적인 아키텍처와 사용법을 이해한 후, 주요 기능과 이러한 기능이 고객에게 가져올 수 있는 비즈니스 가치를 살펴보겠습니다.
CPU 제어
GaussDB의 CPU 관리 및 제어는 사용자 리소스 관리 및 제어를 위한 리소스 풀 입도(granularity)를 기반으로 합니다. 각 리소스 풀은 컨트롤 그룹에 바인딩되어 있으며, CPU 관리 및 제어는 컨트롤 그룹(Control Group, CGroup)을 통해 구현됩니다. CGroup은 프로세스 그룹에서 사용하는 물리적 리소스(예: CPU, 메모리, IO 등)를 제한, 기록 및 격리하기 위해 Linux 커널에서 제공하는 메커니즘입니다.
다양한 차원의 데이터베이스 시스템, 사용자 및 작업의 격리 및 구성 가능성을 고려하여 GaussDB는 제어 그룹의 계층적 특성을 사용하여 데이터베이스 시나리오(아래 그림 참조)에 맞는 모델을 구성합니다. 고객 SLA는 계층적 격리 및 제어, 즉 데이터베이스 프로그램과 비데이터베이스 프로그램 간의 격리, 데이터베이스 상주 백업 스레드와 실행 작업 스레드 간의 격리, 여러 데이터베이스 사용자 간의 격리를 지원합니다.
GaussDB 제어 그룹은 CPU 비율과 코어 수의 상한을 설정할 수 있습니다. 루트 노드는 GaussDB 프로세스에 사용 가능한 CPU 공유를 제어합니다. 백엔드 제어 그룹은 데이터베이스 상주 CPU 공유를 제어합니다. 백그라운드 스레드(Vacuum, DefaultBackend), 클래스 제어 그룹은 사용자 작업 스레드(UserClass1, UserClass2,...UserClassN)의 CPU 공유를 제어합니다. 작업 부하 제어 그룹(TopWD, RemainWD...)도 생성될 수 있습니다. 보다 세밀한 제어를 위해 클래스 제어 그룹 내에서.
위의 예를 계속해서 GaussDB에서 제공하는 CGroup 도구를 사용하여 A 회사의 OLTP 비즈니스, 보고 비즈니스 및 기타 우선 순위가 낮은 비즈니스에 대한 제어 그룹을 생성하고 CPU 할당 비율은 50%, 30% 및 10%입니다.
gs_cgroup -c -S cgroup_tp -s 50; gs_cgroup -c -S cgroup_report -s 30; gs_cgroup -c -S cgroup_other -s 10;
위 명령을 실행하면 세 개의 제어 그룹이 성공적으로 생성되었음을 의미합니다. 그런 다음 리소스 풀을 생성할 때 제어 그룹의 이름을 지정할 수 있습니다. 리소스 풀에 바인딩된 사용자가 시작한 작업은 제어 그룹의 해당 CPU 공유에 의해 제어됩니다.
CGroup으로 CPU를 제어할 때 주의해야 할 두 가지 문제가 있습니다.
첫째, 스레드의 CPU를 CGroup이 제어해야 하는 경우 CGroup의 시스템 API를 실행하여 해당 CGroup을 스레드에 바인딩해야 하는데 이는 시간이 많이 걸리는 작업입니다.
둘째, CGroup의 CPU 제어 효과는 스레드 수가 CPU에 비례할 때 가장 좋습니다.
이러한 문제를 바탕으로 GaussDB는 스레드 그룹의 개념을 제안했습니다. 각 리소스 풀은 스레드 그룹에 해당하고 스레드 그룹의 스레드는 리소스 풀에 해당하는 CGroup에 바인딩됩니다. 동시에 GaussDB는 각 스레드 그룹의 스레드 수를 해당 CGroup의 CPU 공유와 일치하도록 조정합니다. 자세한 내용은 아래 그림을 참조하세요.
사용자가 시작한 각 작업은 실행을 위해 해당 스레드 그룹의 스레드에 배포됩니다. 스레드가 해당 Cgroup 노드에 바인딩되었으므로 운영 체제는 스레드 예약 중에 CPU 관리 및 제어를 완료합니다.
GaussDB는 클래스 제어 그룹에 바인딩된 리소스 풀을 그룹 리소스 풀이라고 하며 해당 사용자를 그룹 사용자라고 합니다. 해당 사용자는 비즈니스 사용자입니다. 그룹 사용자는 일반적으로 부서에 해당하고 비즈니스 사용자는 이 부서의 다른 비즈니스에 해당합니다. 비즈니스 자원 풀의 각 자원 차원의 자원 점유율이 자신이 속한 그룹의 자원 풀 점유율을 초과하여 2단계 자원 관리 및 제어 목표를 달성할 것인가?
CPU 제어는 또한 단일 세션의 CPU가 해당 리소스 풀의 CPU 제한을 초과하지 않도록 제한하기 위해 session_respool이라는 GUC를 제공합니다.
메모리 관리
GaussDB는 동적 메모리와 공유 캐시에 대한 관리 및 제어를 제공합니다. 리소스 풀을 생성할 때 max_dynamic_memory 및 max_shared_memory를 지정하여 동적 메모리와 공유 캐시의 임계값 설정을 각각 완료할 수 있습니다.
동적 메모리 관리는 원래의 메모리 자원 할당 메커니즘을 변경하지 않고 과도하게 할당된 메모리를 고려하기 위해 메모리를 할당하기 전에 논리적 판단 계층만 추가하고, 계정 값이 허용된 메모리의 상한에 도달했는지 확인하고 메모리 관리를 완료합니다. 제어. 동적 메모리가 상한을 초과하면 작업에 메모리가 적용되지 않습니다. 작업이 종료되면 다른 작업이 정상적으로 실행될 수 있도록 해당 작업에서 요청한 메모리가 해제됩니다. 마찬가지로, 작업에서 사용하는 공유 캐시가 리소스 풀 상한을 초과하여 다시 공유 캐시를 신청하는 경우에는 BufferPool 등 이미 점유하고 있는 공유 캐시를 먼저 해제해야 합니다. 작업이 페이지에 적용되면 이미 차지한 페이지는 제거된 후 계속해서 사용할 수 있습니다.
사용자 세분화된 메모리 제어 외에도 GaussDB는 세션 수준 및 명령문 수준 동적 메모리 제어를 완료하기 위해 두 개의 GUC 매개변수 session_max_dynamic_memory 및 query_max_mem도 제공합니다. 세션 또는 명령문에서 사용하는 동적 메모리가 GUC 임계값에 도달하면 작업은 메모리 신청에 실패했습니다.
IO 제어
GaussDB의 디스크 읽기 및 쓰기 IO는 모두 백그라운드 스레드에 의해 완료됩니다. 이 스레드는 시간순으로 디스크에 쓸 뿐이며 사용자마다 다른 IO 사용량을 제어할 수 없습니다. 이를 기반으로 IO 관리 및 제어 기능이 논리적 IO 통계를 사용하여 사용자 또는 세션의 읽기 및 쓰기 IO를 제어하고 제한한다는 점을 고려하십시오. 행 스토리지 테이블의 경우 논리적 IO 수가 추가됩니다. 매 6000(io_control_unit GUC(GUC에 의해 수정됨) 전달 가능)은 1개의 IO로 계산됩니다. 1초에 생성된 읽기 및 쓰기 IO 요청 수가 리소스 풀에서 설정된 임계값을 초과하면 IO 요청이 대기에 추가됩니다. 백그라운드 스레드의 큐와 백그라운드 스레드는 대기 큐에 응답합니다. 이러한 IO 요청이 모니터링되고 대기 시간이 조건을 충족하면 이러한 IO 요청이 대기 큐에서 깨어납니다.
GaussDB는 IO 리소스 관리 및 제어의 두 가지 모드를 지원합니다. 온라인 숫자 모드는 IO 횟수를 트리거하는 고정 값을 설정하여 IO 리소스를 제어합니다. 우선 순위 모드는 현재 디스크 사용량이 오랫동안 95% 이상에 도달하는 경우를 의미합니다. 온라인 값 모드에 도달하면 사용자는 이 모드를 통해 IO를 제어하여 원래 IO를 트리거한 작업의 우선 순위 비율을 제어할 수 있습니다. 우선 순위에는 높음, 중간, 낮음의 세 가지 수준이 있습니다.
위의 예에 이어 A사의 OLTP 업무, 보고 업무, 기타 우선순위가 낮은 업무에 대한 리소스 풀을 생성하고 IO 가중치를 각각 높음, 중간, 낮음으로 설정합니다. 그런 다음 OLTP 비즈니스는 IO 요청의 50%를 사용하여 BufferPool에 데이터를 읽거나 쓸 수 있으며, 소수의 IO 요청이 대기 대기열에 들어가 대기할 수 있습니다. 보고 비즈니스는 IO 요청의 20%를 사용하여 읽을 수 있습니다. 또는 BufferPool에 데이터를 쓰려면 더 많은 IO 요청이 대기 대기열에 들어가고 우선 순위가 낮은 다른 기업은 IO 요청의 10%를 사용하여 BufferPool에 데이터를 읽거나 쓸 수 있으며 더 많은 IO 요청이 대기 대기열에 들어가게 됩니다. 대기; 백그라운드 모니터링 스레드는 IO 대기 큐를 주기적으로 통과하고 BufferPool에서 데이터를 읽거나 쓰는 데 필요한 대기 시간을 충족하는 IO 요청을 깨웁니다.
사용자 세분화된 IO 제어 지원 외에도 GaussDB는 세션 수준 GUC 매개변수 io_limits 및 io_priority 설정을 지원하여 지정된 세션에서 허용되는 작업의 IO 제어를 완료합니다.
연결 수 및 동시성 관리
GaussDB는 리소스 풀을 기반으로 연결 수 제어 및 동시성 제어를 제공하며, max_connections 및 max_concurrency를 지정하여 각각 연결 수 및 동시성 설정을 완료할 수 있으며, 이에 해당하는 리소스를 제공할 수 있습니다. 이전 예에서 회사 A의 세 가지 비즈니스는 연결 수와 동시성 수에 대한 관리 및 제어를 완료합니다.
리소스 풀 respool_tp를 변경합니다(max_connections=-1, max_concurrency = -1); 리소스 풀 respool_report를 변경합니다(max_connections=200, max_concurrency = 100); 리소스 풀 respool_other를 변경합니다(max_connections=100, max_concurrency = 50);
위의 SQL이 성공적으로 실행되면 실시간으로 적용됩니다. A사의 OLTP 업무는 연결 수와 동시성에 제한이 없으며, 클러스터에 리소스가 있는 경우 보고 업무의 최대 연결 수는 200이고, 기타 우선순위가 낮은 경우에는 최대 연결 수를 사용할 수 있습니다. 두 비즈니스의 연결 수가 이 값을 초과하면 GaussDB 커널은 자동으로 차단하여 현재 연결 수가 부족하고 링크가 실패한다고 보고합니다. 보고 비즈니스의 최대 동시성 수는 100입니다. 우선순위가 낮은 다른 비즈니스의 최대 동시성 수는 50입니다. 이 두 비즈니스가 동시에 시작된 작업 수가 이 값을 초과하면 초과 작업은 대기 대기열에 들어가고 깨어나지 않습니다. 기존 작업이 완료될 때까지 작업을 계속 실행합니다.
저장공간 관리 및 제어
저장 공간 관리 및 제어는 여러 사용자가 사용할 수 있는 공간 할당량을 제한하여 단일 사용자의 과도한 저장 공간 사용으로 인해 전체 데이터베이스 업무가 차단되는 것을 방지하는 데 사용됩니다. GaussDB는 사용자 생성 시 저장 공간의 크기를 지정하여 저장 자원을 관리하고 제어합니다.
스토리지 공간 자원은 영구 테이블 공간(Perm Space), 임시 테이블 공간(Temp Space), 운영자 하단 디스크 공간(Spill Space)의 세 가지 유형으로 구분됩니다.
앞선 예에서 A사의 3개 사업에 해당하는 사용자에 대한 디스크 공간 관리 및 제어를 완료하려면 다음 SQL을 이용하면 된다.
사용자 tp_user PERM SPACE '200G' TEMP SPACE '20G' SPILL SPACE '20G' 변경; 사용자 보고_사용자 PERM SPACE '100G' TEMP SPACE '10G' SPILL SPACE '10G' 변경; 사용자 other_user PERM SPACE '100G' TEMP SPACE '10G' SPILL SPACE '10G' 변경;
저장 공간 관리는 그룹 사용자와 기업 사용자를 위한 저장 공간 관리를 지원합니다. 비즈니스 사용자에 해당하는 그룹 사용자에게 공간 제한이 있는 경우, 비즈니스 사용자의 공간도 사용자 그룹의 공간 제한에 의해 제한됩니다. 저장 공간의 크기를 지정한 후 DN에서 사용자의 모든 쓰기 작업은 사용자의 사용 공간을 늘리고 삭제 작업은 사용자의 사용 공간을 줄입니다. CN은 DN에서 사용된 전체 공간을 주기적으로 가져와서 계산합니다. 최대값을 초과하면 쓰기 작업이 취소되고(테이블 삽입/복사) 후속 쓰기 작업은 오류를 보고하고 종료됩니다.
기능 시연
기능 시연 여기에서는 CPU가 비즈니스에 가장 큰 영향을 미치기 때문에 모든 사람을 위한 CPU 제어 효과를 간단히 설명하겠습니다.
두 개의 리소스 풀을 생성하고 각각 CPU의 20%와 60%를 설정한 다음 리소스 풀에 바인딩된 두 명의 사용자를 사용하여 비즈니스 실행을 시작합니다. 실제 CPU 사용량을 관찰하세요.
1. 통제 그룹을 생성합니다:
gs_cgroup -c -S class1 -s 20; gs_cgroup -c -S class2 -s 60;
2. 리소스 풀을 생성합니다.
리소스 풀 생성 xuuer_pool with(control_group = "class1"); 리소스 풀 생성 xyuser1_pool with(control_group = "class2");
3. 사용자 바인딩된 리소스 풀을 생성합니다.
user1 리소스 풀 'xuuer_pool' 역할 생성; user2 리소스 풀 'xyuser1_pool' 역할 생성;
4. Top을 통해 시스템 CPU 상태를 관찰하고, 세분화된 리소스 관리 및 제어는 gs_wlm_respool_cpu_info 기능을 제공하여 각 리소스 풀의 실시간 CPU 상태를 관찰합니다.
위 그림과 같이 초기 시스템 CPU가 유휴 상태임을 알 수 있으며, 리소스 풀의 CPU 모니터링 뷰에서도 CPU 사용량이 0으로 표시됩니다. user1이 서비스 실행을 시작하면 시스템 CPU가 특정 서비스에 의해 점유되는 것을 볼 수 있습니다. 리소스 풀의 CPU 모니터링 보기를 쿼리하면 user1이 CPU의 80%를 사용할 수 있음을 알 수 있습니다. 이때 user2도 비즈니스 실행을 시작합니다. 관찰 결과, 리소스 풀의 CPU 리소스 모니터링 시스템 기능을 쿼리하면 user1의 CPU 사용량이 감소하기 시작하고 user2의 CPU 사용량이 증가하기 시작하는 것으로 나타났습니다. .
두 사용자의 CPU 사용량을 정리하고 아래와 같이 곡선 차트를 그리면 결국 user1과 user2의 CPU 사용량은 20%와 60%에 부합하는 3:1 상태로 균형을 이루는 것을 알 수 있습니다. 리소스 풀 % 비율에 해당하는 CGroup 제어 그룹의 설정을 통해 CPU 제어 효과를 얻을 수 있습니다.
요약하다
세분화된 리소스 관리 및 제어 기능은 현재 중앙 집중식과 분산식을 지원합니다. 분산 컴퓨팅 자원 관리 및 제어는 각 노드가 자신의 노드의 자원을 독립적으로 제어하는 반면, 스토리지 자원 관리 및 제어는 클러스터 차원에서 전체적으로 관리되는 것을 의미합니다.
세분화된 리소스 관리 및 제어는 멀티 테넌트 리소스 격리의 기반이 되어 리소스의 정확한 분할 및 제어를 가능하게 하고, 부하가 높은 시나리오에서 리소스 부족으로 인해 발생하는 클러스터 서비스 불가 문제를 해결합니다. 이 기능은 데이터 격리가 중요하지 않지만 다양한 비즈니스에 리소스 격리가 필요한 시나리오에 적합합니다. 고객이 리소스 격리와 데이터 격리에 대한 요구 사항이 있는 경우 나중에 공유할 다중 테넌트 데이터베이스 기능에 주의할 수 있습니다.
화웨이 클라우드의 신기술에 대해 빨리 알아보고 팔로우하려면 클릭하세요~
고등학생들이 성인식으로 자신만의 오픈소스 프로그래밍 언어를 만든다 - 네티즌들의 날카로운 논평: 애플은 방어에 의존해 만연한 사기로 인해 국내 서비스가 중단됐다 . 앞으로는 윈도 플랫폼 타오바오(taobao.com)에서 독립 게임을 제작할 계획이다. 웹 버전 최적화 작업을 다시 시작해 프로그래머들의 종착지, 비주얼 스튜디오 코드 1.89에서 가장 많이 쓰이는 자바 LTS 버전인 자바 17이 출시되고, 윈도 10에는 시장 점유율 70%, Windows 11은 계속해서 하락 중
{{o.이름}}
{{이름}}