클라우드 티어링은 급격한 데이터 증가로 인해 발생하는 과제를 해결하여 다음과 같은 이점을 제공합니다.

기본적으로 기본 및 보조 저장 시스템 모두에서 비활성으로 간주되는 모든 데이터는 클라우드로 옮기기에 적합한 대상입니다. 기본 시스템에서 이러한 데이터에는 스냅샷, 과거 기록, 완료된 프로젝트 등이 포함될 수 있습니다. 보조 시스템에서는 DR 및 백업 목적으로 만들어진 기본 데이터의 사본이 들어 있는 모든 볼륨이 여기에 포함됩니다.

네, StorageGRID 와 같이 NAS 볼륨의 데이터를 퍼블릭 클라우드나 프라이빗 클라우드로 계층화할 수 있습니다. SAN 프로토콜을 통해 액세스되는 데이터를 계층화하는 경우 NetApp 프라이빗 클라우드를 사용할 것을 권장합니다. SAN 프로토콜은 NAS보다 연결 문제에 더 민감하기 때문입니다.

콜드 데이터라고도 불리는 것의 정의는 "일정 기간 동안 접근되지 않은 볼륨 블록(메타데이터 제외)"입니다. "시간"은 cooling-days라는 계층화 정책 속성에 의해 결정됩니다.

네, 압축, 중복 제거, 압축과 같은 ONTAP 볼륨 수준 스토리지 효율성은 데이터를 클라우드 계층으로 이동할 때 유지됩니다.

FabricPool 은 ONTAP CLI 및 System Manager를 통해 자체 관리하거나 Cloud Tiering을 통해 서비스로 관리할 수 있는 ONTAP 계층화 기술입니다. 클라우드 티어링은 FabricPool ONTAP 과 클라우드 모두에서 고급 자동화 프로세스를 갖춘 관리형 서비스로 전환하여 하이브리드 및 멀티 클라우드 배포 전반에서 티어링에 대한 가시성과 제어력을 향상시킵니다.

아니요. 볼륨의 메타데이터는 성능 계층에서 계층화되지 않으므로 개체 스토리지에 저장된 데이터에 직접 액세스할 수 없습니다.

그러나 클라우드 티어링을 사용하면 보조 시스템과 SnapMirror 대상 볼륨(DP 볼륨)에서 활성화하여 비용 효율적인 백업 및 재해 복구를 달성하고 모든 데이터(메타데이터 제외)를 계층화하여 데이터 센터 설치 공간과 TCO를 줄일 수 있습니다.

볼륨별로 계층화 정책을 연결하여 볼륨 수준에서 클라우드 계층화를 활성화할 수 있습니다. 콜드 데이터 식별은 블록 수준에서 수행됩니다.

볼륨과 관련된 계층화 정책은 어떤 블록을 언제 계층화할지 제어하는 메커니즘입니다. 정책은 데이터 블록 유형(스냅샷, 사용자 데이터 또는 둘 다)과 냉각 기간을 정의합니다. 보다"볼륨 티어링 정책" 자세한 내용은.

클라우드 티어링은 볼륨의 용량에는 영향을 미치지 않지만 집계된 성능 계층 사용에는 영향을 미칩니다.

네, 클라우드 티어링은 각 집계에 대해 비활성 데이터 보고(IDR)를 활성화합니다. 이 설정을 사용하면 저비용 개체 스토리지에 계층화할 수 있는 비활성 데이터의 양을 식별할 수 있습니다.

IDR은 구성된 냉각 기간이 지난 후에 정보를 표시하기 시작합니다. ONTAP 9.7 이하 버전을 사용할 경우 IDR의 냉각 기간은 31일로 조정이 불가능했습니다. ONTAP 9.8부터 IDR 냉각 기간을 최대 183일까지 구성할 수 있습니다.

콜드 데이터를 퍼블릭 클라우드로 계층화하는 경우:

"가격 세부 정보 보기" .

콜드 데이터를 NetApp StorageGRID 시스템(프라이빗 클라우드)에 계층화할 때는 비용이 발생하지 않습니다.

네. 클라우드 티어링을 사용하면 BYOL 라이선스, PAYGO 구독 또는 두 가지를 조합하여 사용할 수 있습니다.

BYOL 용량 한도에 도달하거나 BYOL 라이선스가 만료되면 새로운 콜드 데이터의 계층화가 중지됩니다. 이전에 계층화된 모든 데이터는 계속 액세스할 수 있습니다. 즉, 이 데이터를 검색하여 사용할 수 있습니다. 검색된 데이터는 클라우드에서 성능 계층으로 다시 이동됩니다.

하지만 _BlueXP - 클라우드 데이터 서비스 배포 및 관리_에 대한 PAYGO 마켓플레이스 구독이 있는 경우 새로운 콜드 데이터는 계속해서 개체 스토리지에 계층화되며 사용량 기준으로 요금을 지불하게 됩니다.

아니, 그렇지 않습니다.

네. 퍼블릭 클라우드에서 읽는 모든 작업에는 이탈 수수료가 부과됩니다.

클라우드 제공업체가 데이터 호스팅에 대해 청구할 금액을 추정하는 가장 좋은 방법은 해당 업체의 계산기를 사용하는 것입니다. "AWS" , "하늘빛" 그리고 "구글 클라우드" .

네. 확인하다 "Amazon S3 가격" , "블록 블롭 가격" , 그리고 "클라우드 스토리지 가격" 데이터 읽기/검색에 따른 추가 가격이 부과됩니다.

추정치를 얻으려면 ONTAP 클러스터를 NetApp 콘솔에 추가하고 클라우드 계층화 클러스터 페이지를 통해 검사하세요. 클러스터를 시작하려면 *잠재적 계층화 절감 계산*을 선택하세요. "클라우드 티어링 TCO 계산기" 얼마나 많은 돈을 절약할 수 있는지 확인해 보세요.

MetroCluster 환경에서 사용하는 경우 전체 계층화 라이선스가 두 클러스터 모두에 적용됩니다. 예를 들어, 100TiB의 계층화 라이선스가 있는 경우 각 클러스터의 사용된 계층화 용량은 총 100TiB 용량에 포함됩니다.

클라우드 티어링은 ONTAP 버전 9.2 이상을 지원합니다.

클라우드 티어링은 단일 노드 및 고가용성 AFF, FAS, ONTAP Select 클러스터에서 지원됩니다. FabricPool Mirror 구성과 MetroCluster 구성의 클러스터도 지원됩니다.

네, ONTAP 9.8부터 HDD 집계에 호스팅된 볼륨의 데이터를 계층화할 수 있습니다.

네. 클라우드 티어링은 모든 집계에 호스팅된 볼륨을 계층화하도록 구성할 수 있습니다. 데이터 계층 구성은 사용된 컨트롤러 유형이나 클러스터가 이기종인지 여부와 관련이 없습니다.

Cloud Volumes ONTAP 시스템이 있는 경우 클라우드 계층화 클러스터 페이지에서 해당 시스템을 찾을 수 있으며, 이를 통해 하이브리드 클라우드 인프라의 데이터 계층화를 전체적으로 파악할 수 있습니다. 하지만 Cloud Volumes ONTAP 시스템은 Cloud Tiering에서 읽기 전용입니다. Cloud Tiering에서 Cloud Volumes ONTAP 에 데이터 계층화를 설정할 수 없습니다. "NetApp 콘솔의 ONTAP 시스템에서 Cloud Volumes ONTAP 시스템에 대한 계층화를 설정합니다." .

이는 콜드 데이터를 어디에 계층화하느냐에 따라 달라집니다. 자세한 내용은 다음 링크를 참조하세요.

Cloud Tiering은 다음과 같은 개체 스토리지 공급자를 지원합니다.

네, 가능합니다. 데이터 계층화를 설정할 때 새 버킷/컨테이너를 추가하거나 기존 버킷/컨테이너를 선택할 수 있습니다.

클라우드 티어링은 표준, 표준-빈번하지 않은 액세스, 단일 영역-빈번하지 않은 액세스, 지능형 티어링, Glacier 즉시 검색 스토리지 클래스에 대한 데이터 티어링을 지원합니다. 보다"지원되는 S3 스토리지 클래스" 자세한 내용은.

Amazon S3 Glacier Flexible과 S3 Glacier Deep Archive가 지원되지 않는 주된 이유는 Cloud Tiering이 고성능 계층화 솔루션으로 설계되었기 때문에 데이터를 지속적으로 사용할 수 있어야 하고 검색을 위해 빠르게 액세스할 수 있어야 하기 때문입니다. S3 Glacier Flexible과 S3 Glacier Deep Archive를 사용하면 데이터 검색에 몇 분에서 최대 48시간까지 걸릴 수 있습니다.

네, ONTAP 9.8 이상을 사용하는 클러스터에서는 Tiering UI를 통해 S3 호환 개체 스토리지를 구성할 수 있습니다. "자세한 내용은 여기에서 확인하세요" .

클라우드 티어링은 비활성 데이터에 대해 핫 또는 쿨 액세스 계층으로의 데이터 티어링을 지원합니다. 보다"지원되는 Azure Blob 액세스 계층" 자세한 내용은.

클라우드 티어링은 Standard, Nearline, Coldline, Archive 스토리지 클래스에 대한 데이터 티어링을 지원합니다. 보다"지원되는 Google Cloud 스토리지 클래스" 자세한 내용은.

네. 특정 기간이 지난 후 Cloud Tiering이 기본 스토리지 클래스/액세스 계층의 데이터를 더 비용 효율적인 계층으로 전환하도록 수명 주기 관리를 활성화할 수 있습니다. 수명 주기 규칙은 Amazon S3 및 Google Cloud Storage의 경우 선택된 버킷에 있는 모든 개체에 적용되고, Azure Blob의 경우 선택된 스토리지 계정의 모든 컨테이너에 적용됩니다.

일반적인 구성에서는 클러스터 전체에 대해 하나의 개체 저장소가 있습니다. 2022년 8월부터 고급 설정 페이지를 사용하여 클러스터에 대한 추가 개체 저장소를 추가한 다음, 다른 개체 저장소를 다른 집계에 연결하거나 미러링을 위해 2개의 개체 저장소를 집계에 연결할 수 있습니다.

미러링을 목적으로 집계당 최대 2개의 버킷을 연결할 수 있으며, 이때 콜드 데이터는 두 버킷 모두에 동기적으로 계층화됩니다. 버킷은 다양한 공급업체와 위치에서 제공될 수 있습니다. 2022년 8월부터 고급 설정 페이지를 사용하여 두 개의 개체 저장소를 단일 집계에 연결할 수 있습니다.

네. 일반적으로 가장 좋은 방법은 하나의 버킷을 여러 개의 집계에 연결하는 것입니다. 그러나 퍼블릭 클라우드를 사용하는 경우 개체 스토리지 서비스에 대한 최대 IOPS 제한이 있으므로 여러 버킷을 고려해야 합니다.

한 클러스터에서 다른 클러스터로 볼륨을 마이그레이션할 때 모든 콜드 데이터는 클라우드 계층에서 읽혀집니다. 대상 클러스터의 쓰기 위치는 계층화가 활성화되었는지 여부와 소스 및 대상 볼륨에서 사용된 계층화 정책 유형에 따라 달라집니다.

대상 집계에 연결된 클라우드 계층이 없으면 소스 집계의 클라우드 계층에서 데이터를 읽어 대상 집계의 로컬 계층에 전부 씁니다. 대상 집계에 연결된 클라우드 계층이 있는 경우 소스 집계의 클라우드 계층에서 데이터를 읽어 대상 집계의 로컬 계층에 먼저 기록하여 빠른 전환을 용이하게 합니다. 나중에 사용된 계층화 정책에 따라 클라우드 계층에 기록됩니다.

ONTAP 9.6부터 대상 집계가 소스 집계와 동일한 클라우드 계층을 사용하는 경우 콜드 데이터는 로컬 계층으로 다시 이동하지 않습니다.

쓰기 백업은 일반적으로 읽기에서 수행되며 계층화 정책 유형에 따라 달라집니다. ONTAP 9.8 이전에는 볼륨 이동 작업을 통해 전체 볼륨을 다시 쓸 수 있었습니다. ONTAP 9.8부터 계층화 UI에 모든 데이터 다시 가져오기 또는 활성 파일 시스템 다시 가져오기 옵션이 추가되었습니다. "데이터를 성능 계층으로 다시 이동하는 방법 보기" .

아니요. "헤드 스왑" 절차 동안 변경되는 것은 집계된 소유권뿐입니다. 이 경우, 데이터 이동 없이 새로운 컨트롤러로 변경됩니다.

아니요. 클라우드에 생성되어 계층화된 객체는 단일 파일을 포함하지 않고 여러 파일에서 최대 1,024개의 4KB 블록을 포함합니다. 볼륨의 메타데이터는 항상 로컬 계층에 남아 있습니다.

콘솔 에이전트는 클라우드 계정 내부 또는 온프레미스의 컴퓨팅 인스턴스에서 실행되는 소프트웨어로, NetApp 콘솔이 클라우드 리소스를 안전하게 관리할 수 있도록 해줍니다. 클라우드 티어링 서비스를 사용하려면 에이전트를 배포해야 합니다.

네. 에이전트 소프트웨어는 네트워크의 Linux 호스트에 다운로드하여 수동으로 설치할 수 있습니다. "귀하의 건물에 에이전트를 설치하는 방법을 확인하세요" .

네. 사용하려는 개체 스토리지를 정의하려면 먼저 계정이 있어야 합니다. VPC 또는 VNet에서 클라우드에 에이전트를 설정하는 경우에도 클라우드 스토리지 공급자의 계정이 필요합니다.

에이전트에 장애가 발생하는 경우, 계층화된 환경에 대한 가시성만 영향을 받습니다. 모든 데이터에 접근할 수 있으며, 새로 식별된 콜드 데이터는 자동으로 개체 스토리지에 계층화됩니다.

4가지 계층화 정책이 있습니다.

"티어링 정책에 대해 자세히 알아보세요" .

데이터 계층화는 블록 수준에서 이루어지므로, 계층화 정책의 최소 냉각 일수 속성에 의해 정의된 일정 기간 동안 액세스되지 않은 데이터 블록은 콜드 상태로 간주됩니다. 적용 범위는 ONTAP 9.7 이하에서는 2~63일이 적용되고, ONTAP 9.8부터는 2~183일이 적용됩니다.

콜드 스냅샷 정책의 기본 쿨링 기간은 2일이고, 콜드 사용자 데이터 및 스냅샷의 기본 쿨링 기간은 31일입니다. 냉각일 매개변수는 모든 계층화 정책에 적용되지 않습니다.

전체 백업 중에는 모든 콜드 데이터를 읽습니다. 데이터 검색은 사용된 계층화 정책에 따라 달라집니다. 모든 사용자 데이터 및 스냅샷 정책을 사용하는 경우 콜드 데이터는 성능 계층에 다시 기록되지 않습니다. 콜드 스냅샷 정책을 사용하는 경우 백업에 이전 스냅샷이 사용되는 경우에만 콜드 블록이 검색됩니다.

아니요. 하지만 계층화에 적합한 볼륨, 계층화할 데이터 유형 및 쿨링 기간은 선택할 수 있습니다. 이는 해당 볼륨에 계층화 정책을 연결하여 수행됩니다.

아니요. 데이터 보호(DP) 볼륨은 사용 가능한 세 가지 정책 중 하나와 연관될 수 있습니다. 소스 및 대상(DP) 볼륨에 사용되는 정책 유형은 데이터의 쓰기 위치를 결정합니다.

계층화 정책이 재설정되면 재수화는 일어나지 않지만 새로운 콜드 블록이 클라우드 계층으로 이동되는 것은 방지됩니다.

네. 변경 후의 동작은 연관된 새 정책에 따라 달라집니다.

해당 데이터가 포함된 볼륨에 계층화 정책을 연결하지 마세요.

볼륨의 메타데이터는 항상 성능 계층에 로컬로 저장되며, 클라우드에 계층화되지 않습니다.

자세한 내용은 다음을 참조하세요.

클라우드 티어링 외에도 "Active IQ Unified Manager" 그리고 "디지털 어드바이저" 모니터링 및 보고에 사용할 수 있습니다.

네트워크 장애가 발생하는 경우 로컬 성능 계층은 온라인 상태를 유지하고, 핫 데이터는 계속 액세스할 수 있습니다. 그러나 이미 클라우드 계층으로 이동된 블록에는 액세스할 수 없으며, 애플리케이션은 해당 데이터에 액세스하려고 하면 오류 메시지를 받게 됩니다. 연결이 복구되면 모든 데이터에 원활하게 접근할 수 있습니다.

기본 FabricPool 계층화 기술의 읽기 지연 시간은 클라우드 계층에 대한 연결성에 따라 달라집니다. 계층화는 모든 대역폭에서 작동하지만 적절한 성능을 제공하려면 10Gbps 포트에 클러스터 간 LIF를 배치하는 것이 좋습니다. 에이전트에 대한 권장 사항이나 대역폭 제한은 없습니다.

또한 볼륨에서 개체 스토리지로 비활성 데이터를 전송하는 동안 사용되는 네트워크 대역폭 양을 조절할 수 있습니다. 최대 전송 속도 설정은 클러스터를 계층화할 때 사용할 수 있으며, 나중에 클러스터 페이지에서 사용할 수 있습니다.

네. 클라우드 계층은 연결성에 따라 지연 시간이 달라지므로 로컬 계층과 동일한 지연 시간을 제공할 수 없습니다. 객체 저장소의 대기 시간과 처리량을 추정하기 위해 Cloud Tiering은 객체 저장소가 연결된 후 계층화가 설정되기 전에 사용할 수 있는 클라우드 성능 테스트( ONTAP 객체 저장소 프로파일러 기반)를 제공합니다.

AES-256-GCM 암호화는 성능 및 클라우드 계층 모두에서 유지됩니다. TLS 1.2 암호화는 계층 간을 이동하는 데이터를 암호화하고, 에이전트와 ONTAP 클러스터 및 개체 저장소 간의 통신을 암호화하는 데 사용됩니다.

네. HA 쌍 내의 각 노드에서, 클라우드로 계층화할 데이터가 있는 볼륨을 호스팅하는 이더넷 포트에 클러스터 간 LIF를 구성해야 합니다. 자세한 내용은 데이터를 계층화하려는 클라우드 공급자의 요구 사항 섹션을 참조하세요.