Volcano Engine Edge Cloud는 클라우드 컴퓨팅 기반 기술과 네트워크가 결합된 Edge 이기종 컴퓨팅 성능을 기반으로 하는 클라우드 컴퓨팅 서비스로, Edge 대규모 인프라에 구축되어 Edge 기반 컴퓨팅, 네트워크, 스토리지, 보안, 인텔리전스를 형성하는 차세대 핵심 기능을 갖춘 분산 클라우드 컴퓨팅 솔루션.
01- 에지 장면 저장 문제
에지 스토리지는 주로 에지 렌더링과 같은 에지 컴퓨팅에 적응하는 일반적인 비즈니스 시나리오를 위한 것입니다. Volcano 엔진의 에지 렌더링은 기본 대용량 컴퓨팅 리소스에 의존하여 사용자가 수백만 개의 렌더링 프레임 대기열을 쉽게 배열하고 근처의 렌더링 작업 예약, 다중 작업 및 다중 노드의 병렬 렌더링을 실현할 수 있도록 도와줍니다. , 렌더링을 크게 향상시킵니다. 가장자리 렌더링 질문에서 발생하는 스토리지를 간략하게 소개합니다.
- 오브젝트 스토리지와 파일 시스템의 메타 데이터를 통합하여 오브젝트 스토리지 인터페이스를 통해 데이터를 업로드한 후 POSIX 인터페이스를 통해 직접 운영할 수 있도록 해야 합니다.
- 특히 읽을 때 높은 처리량 시나리오의 요구 사항을 충족합니다.
- S3 인터페이스와 POSIX 인터페이스를 완벽하게 구현합니다.
에지 렌더링에서 발생하는 스토리지 문제를 해결하기 위해 팀은 스토리지 선택 테스트를 수행하는 데 거의 반년을 보냈습니다. 처음에 팀은 지속 가능성과 성능 측면에서 우리의 요구 사항을 더 잘 충족할 수 있는 회사의 내부 스토리지 구성 요소를 선택했습니다. 그러나 가장자리 장면의 경우 두 가지 특정 문제가 있습니다.
- 우선, 회사의 내부 구성 요소는 중앙 전산실을 위해 설계되었으며 일부 주변 전산실에서는 충족하기 어려운 물리적 기계 자원 및 수량에 대한 요구 사항이 있습니다.
- 둘째, 회사 전체의 스토리지 구성 요소는 오브젝트 스토리지, 블록 스토리지, 분산 스토리지, 파일 스토리지 등을 포함하여 함께 패키지되며, 에지 측은 주로 파일 스토리지와 오브젝트 스토리지가 필요하며 맞춤화 및 변환해야 합니다. 온라인 마구간에도 프로세스가 필요합니다.
팀이 논의한 후 CephFS + MinIO 게이트웨이 라는 실행 가능한 솔루션이 형성되었습니다 . MinIO는 개체 스토리지 서비스를 제공하고 최종 결과는 CephFS에 기록되며 렌더링 엔진은 CephFS를 마운트하여 렌더링 작업을 수행합니다. 테스트 및 검증 과정에서 파일 수가 수천만 개에 도달했을 때 CephFS의 성능이 저하되기 시작했고 때때로 정지되었으며 비즈니스 측면의 피드백이 요구 사항을 충족하지 못했습니다.
마찬가지로 Ceph RGW + S3FS를 사용하는 Ceph 기반의 또 다른 솔루션이 있습니다. 이 솔루션은 기본적으로 요구 사항을 충족할 수 있지만 파일 쓰기 및 수정 성능은 장면 요구 사항을 충족하지 않습니다.
3개월 이상의 테스트 끝에 엣지 렌더링의 스토리지에 대한 몇 가지 핵심 요구 사항을 명확히 했습니다.
- 운영 및 유지 관리가 너무 복잡해서는 안 됩니다 . 스토리지 R&D 직원은 운영 및 유지 관리 문서로 시작할 수 있으며 이후 확장 및 온라인 오류 처리의 운영 및 유지 관리 작업은 충분히 간단해야 합니다.
- 데이터 신뢰성 : 스토리지 서비스를 사용자에게 직접 제공하므로 성공적으로 작성된 데이터가 손실되거나 작성된 데이터와 일치하지 않습니다.
- 일련의 메타 데이터를 사용하고 개체 저장소와 파일 저장소를 모두 지원 : 이렇게 하면 비즈니스 측면에서 사용할 때 파일을 여러 번 업로드하고 다운로드할 필요가 없으므로 비즈니스 측면의 사용 복잡성이 줄어듭니다.
- 더 나은 읽기 성능 : 팀은 읽기를 늘리고 쓰기를 줄이는 시나리오를 해결해야 하므로 더 나은 읽기 성능을 기대합니다.
- 커뮤니티 활동 : 활발한 커뮤니티는 기존 문제를 해결하고 새로운 기능의 반복을 적극적으로 추진할 때 더 빠르게 대응할 수 있습니다.
핵심 요구 사항을 명확히 한 후 이전 세 가지 솔루션이 요구 사항을 충분히 충족하지 못한다는 사실을 발견했습니다.
02- JuiceFS 사용의 이점
Volcano Engine 에지 스토리지 팀은 2021년 9월에 JuiceFS에 대해 알게 되었고 Juicedata 팀과 약간의 교류를 가졌습니다. 통신 후 Edge Cloud 시나리오에서 시도하기로 결정했습니다. JuiceFS의 공식 문서는 매우 풍부하고 읽기 쉽습니다. 문서를 읽으면 자세한 내용을 알 수 있습니다.
따라서 타당성 검증, O&M 및 배포의 복잡성, 업스트림 비즈니스에 대한 적응, 업스트림 비즈니스의 요구 사항을 충족하는지 여부에 중점을 두고 테스트 환경에서 PoC 테스트를 시작했습니다.
하나는 단일 노드 Redis + Ceph 기반 이고 다른 하나는 단일 인스턴스 MySQL + Ceph 기반입니다 .
전반적인 환경 구축 측면에서 Redis, MySQL 및 Ceph(Rook를 통해 배포)가 비교적 성숙하고 운영 및 유지 관리 계획 배포를 위한 참조 자료가 비교적 포괄적이기 때문에 동시에 JuiceFS 클라이언트는 이들을 연결할 수도 있습니다. 데이터베이스와 Ceph를 간단하고 편리하게 배포 프로세스가 매우 원활합니다.
비즈니스 적응 측면에서 에지 클라우드는 클라우드 네이티브를 기반으로 개발 및 배포됩니다.JuiceFS는 S3 API를 지원하고 POSIX 프로토콜과 완벽하게 호환되며 CSI 마운팅을 지원하여 비즈니스 요구를 완전히 충족합니다.
포괄적인 테스트 후 우리는 JuiceFS가 비즈니스 측면의 요구 사항을 완전히 충족하고 비즈니스 측면의 온라인 요구 사항을 충족하기 위해 프로덕션 환경에서 배포 및 실행할 수 있음을 확인했습니다.
이점 1: 비즈니스 프로세스 최적화
JuiceFS를 사용하기 전에는 에지 렌더링은 주로 ByteDance의 내부 개체 저장소 서비스(TOS)를 사용했습니다. 렌더링 결과를 생성한 다음 렌더링 결과를 TOS에 다시 업로드하고 마지막으로 사용자는 TOS에서 렌더링 결과를 다운로드합니다. 전체 상호 작용 프로세스에는 여러 링크가 있으며 중간에 많은 네트워크 및 데이터 복사가 포함되므로 이 프로세스에서 네트워크 지터 또는 높은 지연이 발생하여 사용자 경험에 영향을 미칩니다.
JuiceFS를 사용한 후에는 사용자가 JuiceFS S3 게이트웨이를 통해 업로드하는 프로세스가 됩니다.JuiceFS는 파일 시스템의 개체 스토리지와 메타데이터의 통합을 실현하므로 JuiceFS를 렌더링 엔진에 직접 탑재할 수 있으며 렌더링 엔진은 POSIX 인터페이스를 사용합니다. 파일 처리 읽기 및 쓰기, 최종 사용자는 JuiceFS S3 게이트웨이에서 렌더링 결과를 직접 다운로드하므로 전체 프로세스가 더 간결하고 효율적이며 안정적입니다.
장점 2: 파일 읽기 가속 및 대용량 파일의 순차적 쓰기
JuiceFS의 클라이언트 측 캐싱 메커니즘 덕분에 자주 읽는 파일을 렌더링 엔진에서 로컬로 캐시하여 파일 읽기 속도를 크게 높일 수 있습니다. 캐시 오픈 여부를 비교 테스트 해본 결과, 캐시 사용 후 처리량이 약 3~5배 증가할 수 있음을 확인했습니다 .
마찬가지로 JuiceFS의 쓰기 모델은 메모리를 먼저 쓰는 것이므로 청크(기본 64M)가 가득 차거나 애플리케이션이 강제 쓰기 인터페이스(close 및 fsync 인터페이스)를 호출하면 데이터가 오브젝트 스토리지에 업로드됩니다. 데이터 업로드에 성공합니다. 그런 다음 메타데이터 엔진을 업데이트합니다. 따라서 큰 파일을 쓸 때 먼저 메모리에 쓴 다음 디스크에 쓰면 큰 파일의 쓰기 속도를 크게 향상시킬 수 있습니다.
현재 에지의 사용 시나리오는 주로 렌더링이고, 파일 시스템은 더 많이 읽고 적게 쓰고, 파일 쓰기도 주로 대용량 파일에 사용됩니다. 이러한 비즈니스 시나리오의 요구 사항은 JuiceFS의 해당 시나리오와 매우 일치하며 비즈니스 측면에서 스토리지를 JuiceFS로 교체한 후 전반적인 평가도 매우 높습니다.
03- 가장자리 장면에서 JuiceFS를 사용하는 방법
JuiceFS는 주로 Kubernetes에 배포되며 각 노드에는 JuiceFS 파일 시스템을 마운트하는 DaemonSet 컨테이너가 있으며 이를 HostPath 형태로 렌더링 엔진의 포드에 마운트합니다. 마운트 지점이 실패하면 DaemonSet이 자동으로 마운트 지점을 복원합니다.
권한 제어 측면에서 Edge Storage는 LDAP 서비스를 사용하여 JuiceFS 클러스터 노드의 ID를 인증하고 JuiceFS 클러스터의 각 노드는 LDAP 클라이언트 및 LDAP 서비스에 의해 인증됩니다.
현재 애플리케이션 시나리오는 주로 렌더링을 기반으로 하며 향후 더 많은 비즈니스 시나리오로 확장될 예정입니다. 데이터 접근 측면에서 현재 에지 스토리지는 주로 HostPath를 통해 접근하고 있으며, 향후 탄력적 확장이 필요한 경우 JuiceFS CSI Driver 도입을 고려할 예정이다.
04- 생산 환경에서의 실무 경험
메타데이터 엔진
JuiceFS는 많은 메타데이터 엔진(MySQL, Redis 등)을 지원하며, 볼케이노 엔진의 엣지 스토리지 프로덕션 환경은 MySQL을 사용합니다 . 데이터 볼륨의 규모와 파일 수(파일 수는 수천만, 아마도 수천만, 더 많은 읽기와 더 적은 쓰기의 시나리오)와 쓰기 및 읽기 성능을 평가한 후, 우리는 다음을 발견했습니다. MySQL이 운영 및 유지 관리, 데이터 안정성, 비즈니스 측면에서 더 잘 수행되었습니다.
MySQL은 현재 단일 인스턴스 및 다중 인스턴스(마스터 1개와 슬레이브 2개)의 두 가지 배포 체계를 채택하고 있으며, 이는 에지에서 다양한 시나리오에 대해 유연하게 선택할 수 있습니다. 리소스가 적은 환경에서는 단일 인스턴스를 배포에 사용할 수 있으며 MySQL의 처리량은 주어진 범위 내에서 비교적 안정적입니다. 이 두 가지 배포 방식 모두 고성능 클라우드 디스크(Ceph 클러스터에서 제공)를 MySQL 데이터 디스크로 사용하므로 단일 인스턴스 배포에서도 MySQL 데이터가 손실되지 않도록 할 수 있습니다.
리소스가 풍부한 시나리오에서는 배포에 여러 인스턴스를 사용할 수 있습니다. 여러 인스턴스의 마스터-슬레이브 동기화는 MySQL Operator ( https://github.com/bitpoke/mysql-operator) 에서 제공하는 오케스트레이터 구성 요소를 통해 실현됩니다. 기간도 설정되며, 타임아웃이 만료된 후에도 동기화가 완료되지 않으면 성공을 반환하고 알람이 발생합니다. 이후의 재해 복구 계획이 완료된 후 로컬 디스크를 MySQL의 데이터 디스크로 사용하여 읽기 및 쓰기 성능을 더욱 향상시키고 대기 시간을 줄이며 처리량을 늘릴 수 있습니다.
MySQL 단일 인스턴스 구성 컨테이너 리소스:
- CPU：8C
- 메모리: 24G
- 디스크: 100G (Ceph RBD 기준, 수천만 개의 파일을 저장하는 시나리오에서 메타 데이터는 약 30G 디스크 공간을 차지함)
- 컨테이너 이미지: mysql:5.7
MySQL my.cnf구성 :
ignore-db-dir=lost+found # 如果使用 MySQL 8.0 及以上版本，需要删除这个配置
max-connections=4000
innodb-buffer-pool-size=12884901888 # 12G
객체 스토리지
오브젝트 스토리지는 Rook을 통해 배포되는 자체 구축된 Ceph 클러스터를 사용하며 , 현재 프로덕션 환경은 Octopus 버전을 사용합니다. Rook을 사용하면 Ceph 클러스터를 클라우드 네이티브 방식으로 운영 및 유지 관리할 수 있으며 Ceph 구성 요소는 Kubernetes를 통해 관리 및 제어할 수 있으므로 Ceph 클러스터 배포 및 관리의 복잡성이 크게 줄어듭니다.
Ceph 서버 하드웨어 구성:
- 128 핵 CPU
- 512GB 램
- 시스템 디스크: 2T * 1 NVMe SSD
- 데이터 디스크: 8T * 8 NVMe SSD
Ceph 서버 소프트웨어 구성:
- 운영 체제: 데비안 9
- 커널: /proc/sys/kernel/pid_max 수정
- Ceph 버전: Octopus
- Ceph 스토리지 백엔드: BlueStore
- Ceph 복제본 수: 3
- 배치 그룹의 자동 조정 기능을 끕니다.
에지 렌더링의 주요 초점은 짧은 대기 시간과 고성능이므로 서버 하드웨어 선택 측면에서 NVMe SSD 디스크로 클러스터를 구성합니다. 다른 구성은 주로 화산 엔진에서 유지 관리하는 버전을 기반으로 하며 우리가 선택한 운영 체제는 Debian 9입니다. 데이터 중복성을 위해 Ceph에 대해 3개의 복사본을 구성합니다. Edge Computing 환경에서는 리소스 제약으로 인해 EC가 불안정할 수 있습니다.
JuiceFS 클라이언트
JuiceFS 클라이언트는 Ceph RADOS에 대한 직접 연결을 지원하지만(Ceph RGW보다 우수한 성능) 이 기능은 공식 바이너리에서 기본적으로 활성화되어 있지 않으므로 JuiceFS 클라이언트를 다시 컴파일해야 합니다. 컴파일하기 전에 librados를 설치해야 합니다.librados 버전은 Ceph 버전에 해당하는 것이 좋습니다.Debian 9에는 Ceph Octopus(v15.2.*) 버전과 일치하는 librados-dev 패키지가 없으므로 다운로드해야 합니다. 직접 설치 패키지.
librados-dev를 설치한 후 JuiceFS 클라이언트 컴파일을 시작할 수 있습니다. 여기서는 Go 1.19를 사용하여 컴파일합니다. 1.19에서는 최대 메모리 할당을 제어하는 기능 ( https://go.dev/doc/gc-guide#Memory_limit) 이 추가되어 JuiceFS 클라이언트가 너무 많이 차지하는 것을 방지할 수 있습니다. 극단적인 경우 더 많은 메모리로 인해 OOM이 발생합니다.
make juicefs.ceph
JuiceFS 클라이언트를 컴파일한 후 파일 시스템을 생성하고 컴퓨팅 노드에 JuiceFS 파일 시스템을 마운트할 수 있습니다.자세한 단계는 공식 JuiceFS 설명서를 참조하십시오.
05- 미래와 전망
JuiceFS는 클라우드 네이티브 분야의 분산 저장 시스템 제품으로 클라우드 네이티브 배포 방식을 매우 잘 지원할 수 있는 CSI 드라이버 구성 요소를 제공하여 사용자에게 운영 및 유지 관리 배포 측면에서 매우 유연한 선택을 제공합니다.사용자는 클라우드를 선택할 수 있습니다. , 스토리지 확장 및 운영 및 유지 관리 측면에서 비교적 간단한 개인화 배포를 선택할 수도 있습니다. POSIX 표준과 완벽하게 호환되며 S3와 동일한 메타데이터 세트를 사용하므로 업로드, 처리 및 다운로드 작업 프로세스를 매우 편리하게 수행할 수 있습니다. 백엔드 스토리지는 개체 스토리지 기능이기 때문에 임의의 작은 파일을 읽고 쓰는 데 높은 지연이 있고 IOPS가 상대적으로 낮습니다. 쓰기가 많고 적은 시나리오의 경우 JuiceFS는 상대적으로 큰 이점이 있습니다. 가장자리 렌더링 시나리오의 비즈니스 요구 사항에 적합합니다 .
JuiceFS와 관련된 Volcano Engine Edge Cloud 팀의 향후 계획은 다음과 같습니다.
- 더 많은 클라우드 네이티브 : JuiceFS는 현재 HostPath 형식으로 사용되지만 나중에 몇 가지 탄력적인 확장 시나리오를 고려하여 CSI 드라이버 형식의 JuiceFS를 사용하도록 전환할 수 있습니다.
- 메타데이터 엔진 업그레이드 : 메타데이터 엔진의 gRPC 서비스를 추상화하여 더 많은 읽기와 더 적은 쓰기로 시나리오에 더 잘 적응할 수 있도록 다단계 캐싱 기능을 제공합니다. 기본 메타데이터 스토리지는 더 많은 수의 파일을 지원하기 위해 TiKV로 마이그레이션하는 것을 고려할 수 있습니다.MySQL과 비교하여 수평 확장을 통해 메타데이터 엔진의 성능을 더 높일 수 있습니다.
- 새로운 기능 및 버그 수정 : 현재 비즈니스 시나리오에 대해 일부 기능이 추가되고 일부 버그가 수정되어 커뮤니티에 PR을 제공하고 커뮤니티에 환원할 것으로 기대합니다.
도움이 되셨다면 저희 프로젝트 Juicedata/JuiceFS 에 주목해주세요 ! (0ᴗ0✿)