저장소를 가만히 들여다보면 일반적으로 발생하는 이슈는 콘텐츠의 활용성과 저장된 용량입니다. 데이터는 필요에 의해 저장됐지만, 시간이 지남에 따라 저장된 데이터의 접근이 점점 줄어들게 되며 언젠가 접근을 하지 않는 데이터가 됩니다.
그때 쯤 해당 콘텐츠를 삭제하고 싶지만 "언젠가 필요할 것 같다"는 심리적 압박과 "향후 이 데이터에 접근이 진짜 없을 것인가?" 의 딜레마에 빠지게 됩니다.
다른 입장으로는 이 데이터를 저장하고 있다 보니 시간이 지남에 따라 불필요한 데이터가 저장되어 있는 것 같고, 그러한 데이터의 용량이 필요한 데이터의 용량을 초과하는 순간 비용에 대한 고민이 깊어지게 될 것입니다.
결국 내부적인 데이터 관리 정책이 없고, 데이터 관리가 되지 않는 것이 문제입니다만, 비용은 비용대로 나가고 있어 답답한 상황이 발생합니다.
Auto Tiering이란?
이러한 이슈를 해소하기 위해 티어링(Tiering)이라는 것을 운영합니다. 티어링은 서로 다른 성능을 내는 리소스를 하나의 Pool로 묶어 하나의 Volume으로 제공하는 기술을 의미합니다.
최초 On-premise에서의 티어링은 HDD와 SSD를 적절하게 섞어서 자주 사용하는 데이터는 SSD에, 자주 사용하지 않는 데이터는 HDD에 저장함으로써 저장소의 효율을 높이고 비용을 절감하는 Auto Tiering을 사용했습니다.
그림에서 보듯이 자주 접근하는 데이터를 Hot, 자주 접근하지 않는 데이터를 Cold라고 했을 때 자주 접근할 수록 SSD(Flash Disk)로, 자주 접근하지 않을 수록 HDD(Magnetic Disk, IOPS가 적은 순)로 데이터 마이그레이션을 자동으로 진행해 주는 것입니다.
일반적으로 클라우드 제공업체가 제공하는 티어링은 콘텐츠가 생성된 날짜를 기반으로 동작합니다. 이 기능은 대부분 Log 보관용으로 자주 사용하는 정책이 대부분이며 이미지, 동영상, 프레임, 폰트 등의 컨텐츠에는 적절하지 않은 정책입니다.
따라서 우리에게 필요한 정책은 최근 접속으로 부터 얼만큼 시간이 지났는가? 라는 정책과 자주 사용되는 데이터는 일정 기간동안 접근이 없더라도 Hot 계층에 머무르게 할 수 있는 정책입니다. 이를 지원해야만 비로소 Auto Tiering이라고 부를 만한 기능이 된다고 생각합니다.
사설이 좀 깁니다만, NetApp의 정책도 소개드립니다. NetApp은 4k의 청크(chunk)단위로 데이터를 저장하고 관리합니다. 그로 인해 Auto Tiering도 청크단위 관리를 하고 있으며 이 정책은 중복제거(Deduplication)와 함께 사용이 가능합니다.
Cloud 제품의 저장소 과금 비교
대부분의 Cloud 제공자는 다음과 같은 저장소 비용을 제시합니다. (한국 중부 기준)
| 종류 | 설명 | 비용 | |
|
Object Storage (Blob) |
Premium |
Object Storage임에도 불구하고 트랜잭션 비율이 높은 워크로드에 최적화되었으며 대기 시간이 짧고 일관된 액세스를 제공합니다. LRS(로컬 중복 스토리지)만 사용할 수 있습니다. |
LRS: $0.203/GB |
| Hot |
일반적인 접근 성능을 나타내는 Object Storage로 가장 많이 사용하는 계층입니다. LRS, ZRS, GRS, RA-GRS를 지원합니다. |
LRS: $0.02/GB |
|
| Cool |
접근이 적고 데이터 저장용으로 사용되는 계층입니다. LRS, GRS, RA-GRS를 지원합니다. |
LRS: $0.0144/GB |
|
| Archive | 보관용 저장소로 사용되는 계층입니다. LRS만 사용할 수 있습니다. |
LRS: $0.002/GB |
|
| Block Storage (Disk) | Standard HDD |
일반적으로 가상컴퓨터에 연결되는 HDD 디스크입니다. LRS, GRS, RA-GRS를 지원합니다. 현재 최대 500 IOPS와 60MB/초를 지원합니다. |
32 GiB $1.54 |
| Standard SSD |
일반적으로 가상컴퓨터에 연결되는 SSD 디스크입니다. LRS, GRS, RA-GRS를 지원합니다. 현재 최대 500 IOPS와 60MB/초를 지원합니다. |
32 GiB $2.40 |
|
| Premium SSD |
높은 대역폭과 IOPS를 지원하는 가상컴퓨터에 연결되는 SSD 디스크입니다. 높은 성능을 보장받으려면 이 디스크를 사용해야 합니다. 현재 최대 7,500 IOPS와 250MB/초를 지원합니다. |
32 GiB $5.28 |
|
| Ultra SSD |
초고성능의 성능을 보장하는 차세대 SSD 디스크입니다. IOPS와 처리량을 조절할 수 있습니다. |
미정 | |
내용을 보면 Block Storage가 Object Storage보다 비싸고, IOPS와 처리량이 높을수록 비쌉니다. 그렇다면 자주 접근하는 데이터일수록 Block Storage(Premium SSD)에 저장하고 자주 접근하지 않는 데이터일수록 Object Storage(Cool)로 저장할 수 있다면 저장용량에 대한 최적화를 구성할 수 있을 것입니다.
하지만 이는 데이터를 자동으로 재배치 해야하는 이슈가 발생할 것이라는 예측이 가능합니다. 따라서 데이터를 자동으로 재배치하는 정책에 대해 알아보겠습니다.
Snapshot-Only: Snapshot만 Cold 계층에 저장합니다. Snapshot은 일반적으로 Volume Backup으로 사용되고 있으며 특정 시점에 새로운 Volume으로 복구를 할 수 있기에 유용하게 사용할 수 있습니다.
Auto Random read: 자동으로 Data Tiering을 해줍니다. Cold 계층(Object Storage)에 있는 데이터에 Random Read가 발생할 경우 Hot 계층(Block Storage)으로 데이터를 이동합니다.
Auto Sequential read: 자동으로 Data Tiering을 해줍니다. Cold 계층에 있는 데이터에 Sequential Read가 발생할 경우 Hot 계층으로 데이터가 이동하지 않습니다.
All: 모든 데이터를 Cold 계층에 저장합니다. 이 옵션을 사용하면 모든 데이터는 Cold 계층에만 존재하기 때문에 Hot 계층에 저장되지 않습니다.
>70% capacity on performance tier: NetApp 장비의 성능이 70%를 넘어서게 되면 Cold 계층에 있는 데이터가 Hot 계층으로 이동하지 않습니다.
Cloud Tiering 구성도
Cloud Tiering은 NetApp On-premise 장비의 기능중 하나인 FabricPool에 한 종류입니다. NetApp에서 지원하는 구성도를 보면 On-premise에 NetApp ONTAP 장비가 있고, ONTAP이 Service Connector를 이용하여 Tiering을 구현해주는 모습입니다. On-premise 장비를 Cloud Volume ONTAP(CVO)으로 바꿔서 보시면 이해가 쉽습니다.
Cloud Tiering 설정
Cloud Tiering은 위 구성도에서 보는 것과 같이 CVO 또는 On-premise에 NetApp장비가 있어야 설정할 수 있습니다. 우리는 가난하기에 CVO를 설정합니다.
* CVO를 구성하는 것에 대해서는 다음 블로그로 만날께요~ 어마어마한 비밀이 숨어있거든요...
1. NetApp Cloud Central의 Fabric View로 이동합니다. 일반적으로 https://cloud.netapp.com 에 로그인 하시거나, https://services.cloud.netapp.com/fabric-view 로 오시면 됩니다. 다음 화면과 같이 뜨면 Cloud Tiering 아래쪽에 Go to Cloud Tiering을 클릭합니다.
2. 현재 Service Connector가 없기 때문에 Let's Start, Discover Your First Cluster 버튼을 눌러 배포를 진행해 줍니다.
3. 앞서 아키텍처에서 보셨듯이 Service Connector를 새로 만들어주어야 합니다. Add Service Connector를 클릭하여 새로운 Service Connector를 만들어 봅시다!
4. 다음 화면에서 배포할 Cloud 제공업체를 선택합니다. 여기서는 Microsoft Azure를 선택합니다.
5. Service Connector의 인증을 한 후 계정정보를 입력합니다.
6. Service Connector가 생성 될 구독과 지역, 리소스 그룹을 선택합니다.
7. Service Connector의 네트워크를 선택한 후 네트워크 보안 그룹을 설정합니다.
8. 생성되는데 약 7분이 걸린답니다! 페이지를 닫지 말고 기다려줍니다.
9. 다음과 같이 다시 첫번째 화면으로 돌아오면, CVO Cluster Management 정보와 함께 생성된 Service Connector를 선택합니다. 여기서 주의할 점은 Service Connector의 서비스가 올라오는데 2~3분 정도 걸릴 수 있습니다.
10. CVO를 연결하면 다음과 같이 CVO의 Tiering 현황이 나옵니다. 저는 설정을 일부러 빼놔서 Set up Tiering을 눌러 공유된 Volume에 Tiering설정을 해보겠습니다.
11. Tiering을 설정할 Volume을 선택합니다.
12. CVO를 만들 때 이미 Storage Account를 만들고 연결이 되어있기 때문에 확인만 하고 Tier Cluster를 클릭합니다.
13. 연결된 CVO의 More info를 선택하면 다음과 같이 Tiering 현황을 볼 수 있습니다.
강제로 Data를 넘겨보면 아래와 같이 Tiering 데이터와 Save Cost를 알려줍니다.
제약사항
NetApp Cloud Tiering은 4k 청크를 기준으로 Tiering을 하기 때문에 Object Sotrage에 저장된 데이터를 직접 접근할 수 없습니다. Object Storage는 단지 저장할 공간만 제공할 뿐이며 기존의 Object Storage의 기능을 사용하는데 제약이 걸립니다. 따라서 Object Storage에 저장한 데이터를 직접 접근할 수 없으며 NetApp 장비를 이용해서만 접근이 가능합니다.
또한 Object Storage에 저장하는 용량은 4MB로 저장되며 1,024개의 4k 청크를 하나의 File로 저장합니다. 따라서 1,024개의 청크 중 하나만 필요하더라도 해당 파일을 읽어와야 하는 방식으로 동작합니다. 4MB 전체를 읽어오진 않는다고 하더라도 Read API가 동작함으로써 비용이 발생할 수 있다는 점을 유의해야 합니다.
Tiering의 세부적인 설정도 Cloud Tiering에서는 어렵고, CVO 또는 NetApp 장비에서 직접 수정을 해야 합니다. 또한 Tiering 기간 변경 등 세부적인 설정은 CLI를 이용해야만 수정이 가능하기에 ONTAP CLI도 사용할 수 있어야 세부적인 조작이 가능합니다.
Auto Tiering은 전체 용량의 50% 이상 가용용량을 사용하기 전까지는 자동으로 동작하지 않으며, 기본적으로 저장용량 효율화를 위해 제작되었다는 것을 이해하고 사용해야 합니다. 이미 생성한 가상 컴퓨터의 용량을 줄이는 옵션이 아닌 데이터가 늘어났을 때 효율성을 고려해야 하기 때문에 실제로 저장되는 데이터의 양과 자주 사용될 것 같은 데이터의 양을 잘 따져보고 구성해야 합니다.
Cloud Tiering은 FabricPool이라는 제품에서 파생되었으며, 기본적으로 가용량 확보를 위한 제품임을 이해하고 사용한다면 매우 좋은 옵션이 된다고 확신합니다.
'NetApp Cloud' 카테고리의 다른 글
| NetApp과 Cloud의 조화 (0) | 2019.07.18 |
|---|
