우리는 최근에 Cohesity 팀과 협력하여 Redis 기술 파트너 프로그램에 온보딩하는 단계로 Helios와 Redis Enterprise 간의 통합을 확인할 기회가 있었습니다. Helios에서 실행되는 서비스인 Cohesity SmartFiles는 데이터가 있는 위치에 관계없이 비정형 데이터에 대한 단일 보기 및 글로벌 관리를 제공합니다. Redis Enterprise의 맥락에서 SmartFiles는 데이터베이스 스냅샷의 단일 보기를 제공합니다.
지속성과 백업에 신경을 쓰는 이유는 무엇입니까? 사실입니다. Redis가 캐시로 사용되고 시스템 영향을 최소화하면서 백엔드 데이터베이스에서 복원할 수 있다면 둘 다 필요하지 않습니다. 반면에 느린 데이터(예:거래 내역, 재고 수, 고객 조회)에 대한 빠른 액세스를 제공하기 위해 Redis가 운영 데이터베이스로 사용되는 경우를 고려하십시오. Redis 데이터베이스는 하드웨어 문제로부터 신속하게 복구하거나 다른 데이터 센터로 장애 조치를 취해야 합니다.
지속성
Redis 데이터베이스의 모든 데이터는 RAM 또는 RAM + 플래시 메모리(Redis on Flash)에 독점적으로 저장 및 관리됩니다. 프로세스 또는 서버 오류로 인해 손실될 위험이 있습니다. 이러한 위험을 완화하기 위해 따를 수 있는 몇 가지 전략이 있습니다. 기본 및 보조 데이터 샤드가 있는 고가용성(HA) 데이터베이스, 지리적으로 분산된 활성-활성 데이터베이스, 물론 디스크 기반 지속성. 성능 관점에서 기본 데이터베이스 샤드에서 동기화된 보조 데이터베이스 샤드로 장애 조치하는 것이 항상 선호되며 이것이 Redis Enterprise가 작동하는 방식입니다. 기본 및 보조 샤드가 손실된 경우에만 디스크에서 데이터베이스가 복원됩니다. 마찬가지로 데이터 센터에 장애가 발생한 경우 다른 데이터 센터의 동기화된 활성-활성 데이터베이스로 장애 조치하는 것이 디스크에서 복구하는 것보다 빠릅니다.
지속성의 문제에 대해 Redis는 더 많은 리소스가 필요하지만 더 나은 내구성을 위해 추가 전용 파일(AOF)을 지원하고 더 적은 리소스를 필요로 하는 덜 내구성이 있는 스냅샷(RDB)을 지원합니다. 모든 것과 마찬가지로 Redis Enterprise 문서에서 더 자세히 살펴볼 수 있는 절충안이 있습니다. 이 기사의 목적을 위해 더 나은 내구성을 위해 AOF가 필요하다고 가정합니다.
백업
Redis Enterprise는 기본 및 보조 데이터베이스 샤드가 모두 손실된 경우 복구를 위해 지속성에 의존합니다. 활성-활성이 사용되지 않고 연결된 스토리지와 함께 데이터베이스를 수용하는 랙이 손실되면 백업에서 복원해야 합니다. Redis Enterprise의 경우 백업은 항상 스냅샷이며, 지속성을 위해 AOF와 결합될 때 탄력적이고 내구성 있는 데이터 플랫폼을 생성합니다.
여기서 Cohesity SmartFiles가 작동합니다. Redis Enterprise는 클라우드 전반에서 관리되는 백업을 위해 SmartFiles에서 편리하게 제공하는 S3 호환 엔드포인트를 활용합니다. 이를 설정하기 위해 다음 가정과 함께 Redis Enterprise REST API를 사용합니다.
- $USER 및 $PASS는 각각 Redis Enterprise 관리자 사용자 이름 및 비밀번호로 설정됩니다.
- $ACCESS_KEY 및 $SECRET_KEY는 각각 S3 객체 저장소 액세스 키 및 비밀 키 설정
데이터베이스 지속성을 활성화합니다.
curl -s -k -u $USER:$PASS -H 콘텐츠 유형:application/json -XPUT https://localhost:9443/v1/bdbs/1 -d '{"data_persistence":"aof" }' S3 URL을 설정하여 S3 객체 저장소를 사용하도록 클러스터를 구성합니다. 버킷 이름은 S3 URL에 포함되지 않습니다.
curl -s -k -u $USER:$PASS -H 콘텐츠 유형:application/json -X PUT https://localhost:9443/v1/cluster -d '{"s3_url":'\"$ S3_IP\"'}' 개인 정보 보호용으로만 클러스터 S3 백업을 구성합니다.
curl -s -k -u $USER:$PASS -H 콘텐츠 유형:application/json -X PUT https://localhost:9443/v1/cluster -d '{"s3_certificate_verification":false}'
백업 위치를 확인합니다. 성공에 대한 유일한 응답은 HTTP 200 OK입니다.
curl -s -k -u $USER:$PASS -H 콘텐츠 유형:application/json -X POST https://localhost:9443/v1/bdbs/actions/validate_backup_location -d '{"백업_위치":{"유형":"s3", "버킷 이름":'\"$BUCKET\"', "하위 디렉토리":"","access_key_id":'\"$ACCESS_KEY\"', "secret_access_key":'\"$ SECRET_KEY\"'}}'
백업을 만듭니다. 성공에 대한 유일한 응답은 HTTP 200 OK입니다.
curl -s -k -u $USER:$PASS -H 콘텐츠 유형:application/json -X POST https://localhost:9443/v1/bdbs/1/actions/export -d '{"export_location ":{"유형":"s3", "버킷 이름":'\"$BUCKET\"', "하위 디렉터리":"", "access_key_id":'\"$ACCESS_KEY\"', "secret_access_key":'\ "$SECRET_KEY\"'}}'
30분마다 반복 백업을 구성합니다. 성공에 대한 유일한 응답은 HTTP 200 OK입니다.
curl -s -k -u $USER:$PASS -H 콘텐츠 유형:application/json -X PUT https://localhost:9443/v1/bdbs/1 -d '{"백업":true, "backup_interval":1800, "backup_interval_offset":360, "backup_location":{"type":"s3", "bucket_name":'\"$BUCKET\"', "subdir":"", "access_key_id":' \"$ACCESS_KEY\"', "secret_access_key":'\"$SECRET_KEY\"'}}' 최종 생각
마찰이 없는 세상에서 HA 및 Active-Active로 구성된 Redis Enterprise는 지속성과 백업에 대한 걱정을 덜어줍니다. 우리는 마찰이 없는 세상에 살고 있지 않으며 Redis가 시스템 오류에서 복구될 것으로 예상되는 경우 지속성과 백업(HA와 함께)이 모두 필요합니다. Dell EMC, NetApp 또는 Pure Storage와 같은 어플라이언스 제품에서 볼 수 있는 것처럼 S3 백업 엔드포인트를 보는 것이 일반적입니다. 다행히 Cohesity SmartFiles와의 검증된 통합을 통해 이 엔드포인트를 쉽게 활용하고 운영 전략에 백업을 포함할 수 있습니다.