Es irrt der Mench, solange er strebt.

● Physical Storage

○ Data ONTAP Storage Architecture

○ Disk Type

○ Aggregate 생성 Workflow

1. aggregate auto-provision

auto-provisioning을 사용한 aggregate 생성은 ONTAP 9.2 이상에서 best practice 이지만 사용자 환경에서 지원되는지 여부를 확인해야 함. 지원하지 않는 경우 RAID 정책 및 디스크 구성에 대해 결정한 다음 수동으로 생성해야 함.

::>storage aggregate auto-provision 명령 사용

※ Default RAID policies

RAID-DP나 RAID-TEC가 새 aggregate에 대한 기본 RAID 정책.

RAID 정책은 디스크 오류 발생 시 사용하는 패리티 보호를 결정.

RAID-DP는 단일 또는 이중 디스크 오류 발생 시 이중 패리티(double-parity) 보호를 제공.

RAID-DP는 아래 aggregate type에 대한 기본 RAID 정책임.

1) All Flash Aggregates

2) Flash Pool Aggregates

3) Performance hard disk drive aggregates.

 - ONTAP 9.0부터는 RAID-TEC라는 새로운 RAID 정책을 사용할 수 있음

RAID-TEC는 AFF를 포함한 모든 디스크 유형과 모든 플랫폼에서 지원됨. 더 큰 디스크를 포함하는 Aggregate는 동시 디스크 오류 가능성이 더 높음. RAID-TEC은 3중 패리티 보호를 제공하여 데이터가 최대 3개의 디스크 오류가 발생하더라도 견딜 수 있도록 함.

RAID-TEC는 6TB 이상의 디스크를 사용하는 용량 HDD 집합에 대한 기본 RAID 정책임.

• Aggregate에 필요한 Disk나 Disk Partition 수를 결정하는 방법

- 시스템 요구 사항을 충족하려면 충분한 디스크 또는 디스크 파티션이 있어야 함.

- 데이터 손실 가능성을 최소화하려면 권장되는 수의 Hot Spare나 Hot Spare Disk Partition이 있어야 함.

- Root-data 파티셔닝은 특정 구성에서 기본적으로 활성화 됨. root-data 파티셔닝이 활성화 된 시스템은 디스크 파티션을 사용하여 Aggregate를 생성.

- root-data 파티셔닝이 활성화 되지 않은 시스템은 파티션 되지 않은 디스크?를 사용.

- RAID 정책에 필요한 최소 수를 충족하고 최소 용량 요구 사항을 충족하기에 충분한 디스크 또는 디스크 파티션이 있어야 함.

※ ONTAP에서 드라이브의 사용 가능한 공간은 드라이브의 물리적 용량보다 적음. 하드웨어 Universe에서 특정 드라이브의 사용 가능한 공간과 각 RAID 정책에 필요한 최소 디스크 또는 파티션을 찾을 수 있음.

::> storage aggregate show-spare-disks

- RAID Group를 만들고 용량 요구 사항을 충족하는데 필요한 디스크나 디스크 파티션의 수 외에도 Aggregate에 권장되는 최소 Hot Spare나 Hot Spare Disk partition이 있어야 함.

- 모든 Flash Aggregate는 최소 하나의 Hot Spare나 Hot Spare Disk partition이 있어야 함.

- non-flash Aggregate의 경우 최소 2개의 Hot Spare나 Hot Spare Disk partition이 있어야 함.

- Maintenance Center를 지원하고 여러 동시 디스크 장애로 인한 문제를 방지하려면 multi-disk carrier에 최소 4개의 Hot Spare가 있어야 함.

2. 수동으로 Aggregate 생성

- Aggregate에 필요한 디스크 수와 Hot Spare 수를 결정해야 함.

※ root-data-data 파티셔닝이 활성화 되고 구성에 SSD가 24개 이하인 경우 데이터 파티션을 다른 노드에 할당하는 것이 좋음.

root-data 파티셔밍 및 root-data-data 파티셔닝이 활성화 된 시스템에서 aggregate를 만드는 절차는 파티션 되지 않은 디스크를 사용하여 시스템에서 aggregate를 만드는 절차와 동일.

시스템에서 root-data 파티셔닝이 활서오하 된 경우 -diskcount 옵션에 디스크 파티션 수를 사용해야 함. root-data-data를 분할의 경우 -diskcount 옵션은 사용할 디스크 수를 지정.

※ FlexGroups 와 함께 사용하기 위해 여러 aggregate를 만들 때 aggregate는 가능한 한 크기가 비슷해야 함.

○  스토리지 aggregate 생성

1) spare disk 파티션 목록을 보고 aggregate를 생성하기에 충분한지 확인

::>storage aggregate show-spare-disk -original-owner node_name

=> 데이터 파이션은 사용 가능한 로컬데이터 아래에 표시됨. 루트 파티션은 spare로 사용할 수 없음.

2) Aggregate 생성 시 시뮬레이션:

::>storage aggregate create -aggregate [aggregate_name] -node [node_name] -raidtype raid_dp -diskcount [number of disks or partition] -simulate true

3) 시뮬레이션 된 명령에서 경고가 표시되면 명령을 조정하고 다시 시뮬레이션

4) aggregate 생성

::>storage aggregate create -aggregate [aggregate_name] -node [node_name] -raidtype raid_dp -diskcount [number of disks or partition]      

5) aggregate 생성 확인

::>storage aggregate show-status [aggregate_name]

3. Aggregate 확장 Workflow

4. Node나 Shelf에 Drives 추가

- 노드나 Shelf에 드라이브를 추가하여 Hot Spare 수를 늘리거나 Aggregate에 추가

- 추가하려는 Drives는 플랫폼에서 지원되어야 함.

- 단일 Procedure에서 추가해야 하는 최소 드라이브 수는 6개. 단일 드라이브를 추가하면 성능이 저하될 수 있음.

- Steps

1) 넷앱 지원 사이트에서 최신 드라이브 및 Shelf 펌웨어와 디스크 검증 패키지 파일을 확인.

노드나 Shelf에 최신 버전이 없는 경우 새 드라이브를 설치하기 전에 업데이트 진행.

드라이브 펌웨어는 최신 펌웨어 버전이 없는 새 드라이브에서 자동으로 업데이트 됨.

2) 바르게 접지(Properly ground yourself)

3) 플랫폼 전면에서 베젤을 제거

4) 새 드라이브의 올바른 슬롯을 확인

※ 드라이브 추가를 위한 올바른 슬롯은 플래솜 모델 및 ONTAP 버전에 따라 다름. 어떤 경우에는 특정 슬롯에 순서대로 드라이브를 추가해야 함.

5) 새 드라이브를 삽입

a. Cam handle 이 열린 위치에 있는 상태에서 양손으로 새 드라이브를 삽입

b. 드라이브가 멈출 때까지 밈.

c. Cam handle을 닫아 드라이브가 미드 플레인과 핸들에 완전히 안착되고 핸들이 제자리에 고정되도록 함. Cam handle을 천천히 닫아 드라이브 면과 올바르게 정렬되도록 함.  

6) 드라이브의 activity LED(녹색)가 켜져 있는지 학인. LED가 계속 켜져 있으면 드라이브에 전원이 있음을 의미. activity LED가 깜빡이면 드라이브에 전원이 있고 I/O가 진행 중임을 의미. 드라이브 펌웨어가 자동으로 업데이트되는 경우 LED가 깜빡임.

7) 다른 드라이브를 추가하려면 4) ~ 6)단계를 반복. 새 드라이브는 노드에 할당될 때까지 인식이 되지 않음. 새 드라이브를 수동으로 할당하거나 노드가 드라이브 자동 할당 규칙을 따르는 경우 ONTAP이 새 드라이브를 자동할당할 때까지 기다릴 수 있음.

8) 새 드라이브가 모두 인식 되면 추가 및 소유권 정보를 확인

::>storage aggregate show-spare-disks => 올바른 노드가 소유한 새 드라이브가 표시되어야 함

9) Options: 새로 추가된 드라이브를 제로화(::>storage disk zerospares)

※ Aggregate에서 이전에 사용된 드라이브는 다른 Aggregate에 추가하기 전에 0으로 설정해야 함. 드라이브를 0으로 설정하면 Aggregate 크기를 빠르게 늘려야 하는 경우 지연을 방지할 수 있음. 드라이브 제로화 명령은 백그라운드에서 실행되며 노드에서 제로화 되지 않은 드라이브의 크기에 따라 완료하는데 몇 시간이 걸릴 수 있음.

::>storage disk zerospares

디스크 초기화 후

- 새 드라이브를 aggregate에 추가하거나 Host Spare 목록에 배치 or 새 aggregate 생성 가능.

1) 디스크 검증 패키지를 업데이트 해야 하는 경우,

디스크 검증 패키지(Disk Qualification Package, DQP)는 새로 검증 된 드라이브에 대한 완전한 지원을 추가. 드라이브 펌웨어를 업데이트 하거나 새 드라이브 유형 또는 크기를 클러스터에 추가하기 전에 DQP를 업데이트 해야 함.

DQP를 분기 or 반기마다 정기적 업데이트 하는 것이 best practice

2) Hot Spare 디스크 동작

핫 스페어 디스크는 스토리지 시스템에 할당되고 사용할 준비가 되었지만 RAID 그룹에서 사용 중이 아니고 데이터를 보유하지 않는 디스크.

3) Aggregate 생성 플로우

aggregate를 생성하면 시스템의 볼륨에 스토리지가 제공됨. ONTAP 9.2부터는 ONTAP이 시스템에 대한 Aggregate 구성 권장하도록 할 수 있음(Auto Provisioning). Auto Provisioning을 사용할 수 없거나 적합하지 않은 경우 수동으로 구성할 수 있음.

5. 수동으로 디스크 ownership 할당

디스크는 Aggregate에 사용되지 전에 node가 소유해야 함. 클러스터가 자동 디스크 소유권 할당을 사용하도록 구성되지 않은 경우 소유권을 수동으로 할당해야 함.

Aggregate에서 사용중인 디스크의 소유권을 재 할당 할 수는 없음.

- 할당되지 않은 디스크 확인

::>storage disk show -container-type unassigned

- 디스크 할당

::>storage disk assign -disk disk_name -owner owner_name

6. 빠른 드라이브 zeroing

ONTAP 9.4부터는 긴 대기시간 없이 프로비저닝 하기 전에 드라이브(SSD 및 HDD)를 자동으로 빠르게 제로화 할 수 있음.

ONTAP 9.4이상으로 설치되거나 초기화 된 시스템의 경우 드라이브 제로화가 자동으로 수행되고 몇 초 만에 완료.

수동으로 드라이브를 제로화해야 할 경우 아래 방법을 사용

1) storage disk zerospares 명령 사용(관리자 권한 필요)

2) 부팅 메뉴에서 다음 옵션 중 하나를 선택

- (4) Clean configuration and initialize all disks

- (9a) Unpartition all disks and remove their ownership information

- (9b) Clean configuration and initialize node with whole disks

빠른 제로화 향상은 ONTAP 9.4 이전 릴리스에서 업그레이드 된 시스템을 지원하지 않음.

클러스터 노드에 빠르게 비워진 드라이브가 있는 Aggregate가 포함된 경우 클러스터를 ONTAP 9.2 또는 이전으로 되돌릴 수 없음.

7. Aggregate 확장

볼륨에 더 많은 공간을 제공할 수 있도록 Aggregate에 디스크를 추가할 수 있음.

partitioned disks나 unpartitioned disks 를 Aggregate에 추가하는 절차는 유사함.

스토리지를 추가하는 Aggregate RAID Group 크기를 아는 것이 중요.

- Aggregate를 확장할 때 Aggregate에 partitioned disks를 추가하는지 unpartitioned disks를 추가하는지를 알고 있어야 함. unpartitioned disk를 기존 Aggregate에 추가하면 기존 RAID Group 크기가 새 RAID Group 크기에 상속되어 필요한 Parity 디스크 수에 영향을 줄 수 있음.

unpartitioned disk가 Partitioned disk로 구성된 RAID Group에 추가되면 새 디스크가 분할되어 사용되지 않는 예비 분할 영역에 남음.

파티션을 프로비저닝 할 때 두 파티션을 예비로 사용하는 드라이브 없이 노드를 떠나지 않도록?해야 함. 그럴 경우 노드에서 컨트롤러 중단이 발생하면 문제에 대한 중요한 정보(the core file)를 기술 지원에 제공하지 못할 수 있음.

※ disklist 명령을 사용해서 Aggregate 디스크를 확장하지 말도록 하라.

   파티션 정렬이 잘못될 수 있음

-Steps

1) Aggregate를 소유하는 시스템에서 사용 가능한 spare storage를 표시.

::> show-spare-disk -original-owner [node_name] -is-disk-shared true 매개 변수를 사용하여 Partitioned 디스크나 unpartitioned 디스크만 표시할 수 있음.

2) 현재 Aggregate에 대한 RAID 그룹 표시

::>storage aggregate show-status [aggr_name]

3) Aggregate에 디스크 추가

::>storage aggregate add-disks -aggregate [Aggr_name] -diskcount [number_of_disk_or_partition] -simulate true  

실제 프로비저닝하지 않고 스토리지에 디스크 추가 결과를 볼 수 있음.

- Flash Pool Aggregate를 생성할 때, Aggregate와 다른 체크섬이 있는 디스크를 추가하거나 혼합.

체크섬 Aggregate에 디스크를 추가하는 경우 -checksumstyle 매개 변수를 사용해야 함.

- Flash Pool Aggregate에 디스크를 추가하는 경우 -disktype 매개 변수를 사용하여 지정

- disksize 매개 변수를 사용하여 추가 할 디스크의 크기를 지정할 수 있음. 지정된 크기의 디스크만 선택 됨.

::> storage aggregate add-disks -aggregate TEST_AGGR -raidgroup new -diskcount 5

5) 디스크 추가 확인

::>storage aggregate show-status -aggregate TEST_AGGR

- 새 raidgroup에 디스크 추가

6) 노드에 root partition과 data partition 이 모두 스페어인 디스크가 있는지 확인

::>storage aggregate show-spare-disks -original-owner NETAPPPAR_TEMP-N1

8. Managing Aggregates

디스크 RAID protection levels

- 3가지 RAID 지원. RAID 보호 수준에 따라 디스크 오류 발생 시 데이터 복구에 사용할 수 있는 Parity 디스크 수가 결정 됨.

- RAID Protection 기능을 사용하면 RAID 그룹 디스크 오류가 있는 경우, 오류가 발생한 디스크를 Spare 디스크로 교체하고 패리티 데이터를 사용하여 오류가 발생한 디스크의 데이터를 재구성 함.

1) RAID 4

하나의 Spare 디스크 사용. RAID 그룹 내 장애 발생 시 하나의 디스크에서 데이터를 교체 재구성.

2) RAID DP

RAID-DP 보호 기능을 통해 최대 2개의 Spare 디스크를 사용하여 RAID 그룹 내에서 동시에 오류가 발생한 최대 2개의 디스크에서 데이터를 교체하고 재구성.

3) RAID-TEC

RAID-TEC 보호 기능을 사용하면 최대 3개의 Spare 디스크를 사용하여 RAID 그룹 내에서 동시에 오류가 발생한 최대 3개의 디스크에서 데이터를 교체하고 재구성.

Aggregate에 필요한 디스크나 디스크 파티션 수를 결정하는 방법

- Aggregate에 충분한 디스크 또는 디스크 파티션이 있어야 함. 데이터 손실 가능성을 최소화하려면 권장되는 수의 hot spare 디스크나 hot spare 디스크 파티션이 있어야 함.

- Root-data partitioning은 특정 구성에서 기본적으로 활성화 됨. Root-data partitioning이 활성화 된 시스템은 디스크 파티션을 사용하여 Aggregate를 생성.  Root-data partitioning이 활성화되지 않은 시스템은 파티션되지 않은 디스크를 사용.

- RAID 정책에 필요한 최소 수를 충족하고 최소 용량 요구 사항을 충족하기에 충분한 디스크 도는 디스크 파티션이 있어야 함.

※ ONTAP에서 드라이브의 사용 가능한 공간은 드라이브이 물리적 용량보다 적음.

특정 드라이브의 사용 가능한 공간과 하드웨어 유니버스에서 각 RAID 정책에 필요한 최소 디스크나 디스크 파티션을 찾을 수 있음.

::>storage aggregate show-spare-disks

- RAID 그룹을 만들고 용량 요구 사항을 충족하는데 필요한 디스크 또는 디스크 파티션 수 외에도 Aggregate에 권장되는 최소 hot spare 디스크나 hot spare 디스크 파티션이 있어야 함.

1) 모든 Aggregate의 경우 최소 하나의 hot spare디스크나 hot spare 디스크 파티션이 있어야 함.

2) 비플래시 동종 Aggregate의 경우 최소 2개의 hot spare 디스크나 디스크 파티션이 있어야 함.

3) Flash Pool Aggregate의 경우 각 디스크 유형에 대해 최소 2개의 hot spare 디스크나 디스크 파티션이 있어야 함.

4) Management Center의 사용을 지원하고 여러 동시 디스크 오류로 인한 문제를 방지하려면 다중 디스크 캐리어에 최소 4개의 hot spare가 있어야 함.

CIFS SHARE

Volume mount

::>mount -vserver SVM01 -volume cifs_vol1 -junction-path /cifs_vol1

CIFS Share설정

::>cifs share create -vserver SVM01 -share-name CIFS_SHARE -path /cifs_vol1

Access 권한 설정

::>access-control remove -share CIFS_SHARE -user-or-group everyone 

::>access-control create -share CIFS_SHARE -user-or-group "Domain\Administartors" -permission full_control

CIFS Properties 설정

::>vserser cifs share properties add -vserver SVM01 -share-name CIFS_SHARE -share-properties showsnapshot, changnotfy

::>vserver cifs share properties remove

<properties>

1.  oplocks

share가 클라이언트 측 캐싱이라고도 하는 opportunistic locks(기회적잠금?) 사용하도록 지정. 일부 프로그램은 oplock이 활성화된 경우 정상 작동하지 않을 수 있음(MS Access는 oplock이 활성화 되면 손상되기 쉬움)
share의 장점은 단일 경로를 여러 번 공유할 수 있으며 각 공유는 서로 다른 속성을 가질 수 있음. 
cifs_vol1/vol1라는 경로에 DB와 다른 유형의 파일이 모두 포함된 경우 안전한 DB액세스를 위해 oplock이 비활성화된 것과 클라이언트 측 캐싱에 대해 oplock이 활성화된 두 개의 공유를 만들 수 있음. default 설정.

2. browsable: Windows 클라이언트가 공유를 찾아 볼 수 있음. default 설정

3. showsnapshot: 클라이언트가 스냅샷 복사본을 볼수 있도록 지정

4. changenotify: Change Notify 요청을 지원하도록 지정. default 설정

5. attributecache: SMB 1.0을 통해 속성에 대한 빠른 액세스를 제공하기 위해 CIFS 공유에서 파일 속성 캐싱을 활성화

6. continuously-available: 지원하는 SMB클라이언트가 파일을 영구적?으로 열 수 있음. 이러한 방식으로 열린 파일은 장애 조치 및 반환과 같은 중단 이벤트로부터 보호됨. FlexGroups나 WORKGROUP CIFS서버에 대해 지원하지 않음

7. branchcache: 공유를 통해 클라이언트가 이 공유 내의 파일에 대해 Branchcache 해시를 요청할 수 있도록 지정. CIFS branchcache 구성에서 운영 모드로 'per-share' 을 지정하고 'oplocks' 공유 속성도 지정하는 경우에만 유용

8. access-based-enumeration: 공유에서 ABE(액세스기반열거?)를 사용하도록 지정. ABE필터링 된 공유 폴더는 개별 사용자의 액세스 권한을 기반으로 사용자에게 표시되므로 사용자가 액세스 할 수 없는 폴더나 공유리소스가 표시되지 않도록 함

9. namespace-caching: 공유에 연결하는 SMB 클라이언트가 CIFS 서버에서 반환한 디렉터리 열거 결과를 캐시할 수 있음을 지정

10. encrypt-data: 공유에 액세스 할 때 SMB 암호화를 사용해야 함을 지정. 암호화를 지원하지 않는 클라이언트는 이 공유에 액세스 할 수 없음

11. show-previous-versions: 클라이언트에서 이전 버전을 보고 복원할 수 있도록 지정. default 설정

* 

클러스터 구성 요소

1. Nodes (Controller + Disk Shelf)

- 구성: Network ports / Expansion slots / Nonvolatile Memory(NVRAM, NVMEM)

          Disks

2. HA Pair

- 파트너 간 2개의 커넥선 노드

- 같은 Disk shelves 에 연결

- 파트너 디스크 fail 시 남은 노드에서 디스크 제어

- HA pair 연결 구성: HA interconnect / Multipath HA shelf connectivity / Cluster interconnect connectivity

3. Networks

- Cluster interconnect : 노드간 연결, private network

- Management network 

- Data network : one or more networks 필요, Ethernet / FC / converged network

4. Ports & Logical Interfaces

Data ONTAP 스토리지 아키텍처

- Physical Layer : RAID Groups of Disks > Aggregate

- Logical Layer : FlexVol Volumes > Files and LUNs

1. Physical Storage

1) Disk

- Disk ownership은 하나의 컨트롤러에 할당

- spare로 두거나 RAID 그룹에 추가

2) RAID Group

- disk collection 

- data is striped across the disks.

3) Aggregate

- 하나 이상의 RAID group 집합

- 하나의 컨트롤러가 ownership을 가짐.

2. Logical Storage

1) SVM(Storage Virtual Machine)

- data volumes 컨테이터

- 클라이언트 데이터는 LIF를 통해 

2) Volume

- file or LUNs의 논리 데이터 컨테이너

- 하나 이상의 FlexVol , 한 개의 확장 가능한 무한 볼륨?

3) LIF

- 포토와 연결된 네트워크 주소 대표.

- 클라이언트 데이터 엑세스

SVM with FlexVol Volumes

A200::>vserver setup

...

A200>vserver show

- SVM root volume = 1GB, root volumes는 공간이나 inode의 부족으로 인해 SVM root volume에 볼륨을 마운트 할 때 오류를 방지.

- SVM은 자동 시작 실행. 기본적으로 vsadmin 사용자 계정이 만들어 지고 잠긴 상태가 됨.

- FlexVol volume: NAS 환경에서 파일 시스템, SAN 환경에서의 LUN 컨테이너

- QTree: FlexVol의 더 작은 세그먼트 분할 / quotas(할당량), security, CIFS oplock 설정 관리

- LUN : SCSI disk의 Logical Unit

- Infinite Volume : 최대 20억 개 파링과 수십 petabytes의 데이터를 저장할 수 있는 확장 가능한 볼륨 1개

클러스터 설정

- 지원 클러스터 설정

Single-Node / Two-Node Switchless / Multinode Switched / MetroCluster

1) Single-node Cluster

1. 스토리지 성능에 영향을 미치는 요소들

 - 블록 크기(data block size)

 - 랜덤/순차성 (I/O mix of random or sequential access patterns)

 - 읽기/쓰기 비율 (balance of read and write operations)

 - 측정 도구 (tool)

 - 측정 시스템 구성 환경 (system configuration)

2. 스토리지 성능평가를 위한 블록크기

 1) OLTP, random 데이터용 스토리지

  - 블록크기: 4KB, 8KB (512B, 128KB)

  - 주요 응용: E-mail, web, OLTP, 전자결재

  - 중요성능지표: IOPS

  - 512B 일때 최고성능 값이므로 대부분 512B 채택하나 비현실적...?

 2) Stream, sequential 데이터용 스토리지

  - 블록크기: 256KB, 1024KB

  - 주요응용: VOD, batch, backup

  - 주요 성능 지표 : MB/s

  - 블록 크기가 클수록 최고 성능 값

3. Read/Write 비율

 1) R,W 비율 결정

  - Read only

  - Write only

  - Read : Write = 0.5 : 0.5

 2) 주요 근거

 - 벤더들은 최고 성능 획득에 주력하여 read only 일 경우가 많음

 - 다양한 read:write 비율 적용 필요

Volume

I. RAID-DP

- Double parity disks / data disk

- Raid disk type : data / parity / dparity / spare

- degraded mode : no spare disk

- Max raid group : 400 per storage

- Raid group sizing for RAID-DP groups

- RAID group size는 12 ~ 20 recommended
- 쓰기 성능은 Raid-group이 큰게 작은 것 보다 빠름.

- RAID group을 작게하면 짧은 reconstruction 시간, Multiple disk failure 가능성 감소.

* raid group size 조정

 => >aggr options <aggr_name> raidsize 16

 * raid level scrubbing

 => disk block checking, media error, parity inconsistency 수정

 => disk scrub start

* spare disk가 없는 상태에서 disk fail 되면 raid.timeout 설정값에 따라 shutdown 됨 (default = 24h)

 options.raid

II. Aggregation / Volume

       Aggregation /Volume 구조

 1. Root Volume

  - System 당 한 개의 root volume을 가짐

  - Boot volume, /etc directory에 위치

  - 다른 volume으로 변경 가능, vol options [vol_name] root , /etc directory copy

  - Path (Virtual root volume) - /vol

  - root volume 이 결정하는 인자 - 모든 volume의 default language 값

 2. Volume 및 Aggregate Names

  - trad volume or aggregate naming conventions : 문자,숫자,'_' , 255자 이내

 III. Volume Management

  - Volume

  OnTAP에서 지원하는 프로토콜을 통해 유저에게 파일 액세스를 제공하는 data를 포함하는 파일시 스템을 이루는 단위

  1. Trad vol

   - dedicated aggr를 가지는 volume

   - 온라인 확장, 용량 확장은 오직 디스크 추가를 통해 가능.

   2. Flex vol

   - 같은 aggr안에 위치하는 flex vol은 aggr을 공유

   - 온라인 상태에서 확장 및 축소 가능

   - 최소 20MB, 4KB 단위로 증가

   - volume이 생성되면 aggr 사이즈의 0.5%를 reserve volume 의 meta 정보 저장.

   3. volume setting attribute

   - volume name, size, security style, cifs oplock사용 여부, volume language, space guarantee, file limit(quota),

      snapshot schedule, snaplock

   - root volume 여부

   - volume language: volume이 포함하는 데이터와 파일 이름을 표사히는 character set을 결정.

   - Space guarantee? 

  https://library.netapp.com/ecmdocs/ECMM1278323/html/smg/provisioning/concept/c_oc_prov_spc-guar.html

   1) flexvol과 reserve file의 사용된 영역에 snapshot 백업 후 overwrite를 실행할 경우 공간부족으로 인해 write가 실

       패하지 않도록 보장

   2) volume: aggr 안에 생성된 vol에 할당된 공간은 다른 vol을 위한 영역으로 사용될 수 없음.

   3) file / none

   4) Guarantee가 설정되어있다 하더라도 vol이 offline 되면 그 vol 안에서 unused 된 공간은 다른 vol에서 사용가능

       한 영역

   - Fractional_reserve? Volume % 조절

   https://library.netapp.com/ecmdocs/ECMM1278323/html/smg/provisioning/concept/c_oc_prov_spc-frct-rsrv.html

   1) Reservation 설정을 했다면 reserved size를 줄일 수 있음 : vol options ~

   2) Vol에만 적용되는 기능

   3) File reserve 했다면 default reserve 값은 100%가 됨.

   4) Qtree snapmirror를 실행하는 경우, fractional reserve 를 0으로 적용.

    > vol options vol_name fractional_reserve pct

   - volume language 변경

    vol data 영향으로 vol language 변경 시 시스템 리부팅 필요

    vol lang 변경하면 파일에 대해 nfs access 가능한지 체크하기 위해 WAFL_check 를 실행여부 결정.

   - cifs oplocks

    http://netapplines.blogspot.kr/2013/06/cifs-oplocks-opportunistic-locks.html

   - volume, qtree security style

   1) ntfs: 파일 security가 ntfs acl에 의해서 결정되며 nfs 유저는 지정된 windows sid 값에 의해 결정.

   2) unix: 파일과 디렉토리 acl이 unix permission 에 의해 결정.

   3) mixed: 파일과 디렉토리 security style은 가장 최근 permission을 설정한 방식에 의해 결정.

I. 기본 제공 소프트웨어

 1. SnapShot : 어플리케이션 서비스 중에 성능 저하없이 즉각적으로 Point in Time Image 백업을 제공하는 논리적 데이터 보호 소프트웨어.

 2. SyncMirror : RAID1과 RAID-DP 이상의 안정성을 제공하는 데이터 보호 소프트웨어.

 3. FlexVol : 볼륨을 하드웨어와 독립적으로 구성하여 논리적 레벨에서 데이터를 관리하게 하여 씬 프로비저닝을 구현하게 하는 데이터 관리 개선 소프트웨어.

 4. RAID-DP : 단일 RAID 그룹내에서 동시에 두 개의 데이터 디스크 장애 시에도 계속적인 서비스를 제공하며, RAID1이상의 안정성과 스토리지 사용량을 제공한는 데이터 보호 기술.

 5. FlexView : 기본적으로 넷앱의 스토리지를 관리,모니터링하는 웹 브라우저 기반의 툴.

 6. FlexShare : 스토리지내에 중요업무의 우선순위에 따라 해당 볼륨의 대기 응답 시간을 최소화 시키는 QoS.

 7. Deduplication : 저장되는 데이터의 중복된 블록을 제거하여 더 작은 공간에 더 많은 데이터를 저장할 수 있는 스토리지 공간 절약 효율화 소프트웨어.

II. 스토리지 소프트웨어(유상)

 1. Data Motion : 클라이언트 어플리케이션의 영향 없이 스토리지 인프라 스트럭쳐내에서 데이터를 자유롭게 이동할 수 있는 Shared Storage를 위한 Data Mobility 소프트웨어로 SnapMirror, MultiStore, Provisioning Manager로 통합된 소프트웨어.

 2. FlexCache : 스토리지 및 어플리케이션 성능 가속 솔루션으로 WAN 구간 사이의 응답 시간 지연 감소, 총 IOPS증가, 성능 병목 현상 제거가 가능한 성능 가속 소프트웨어.

 3. FlexClone : 스토리지 공간 추가없이 여러 개의 데이터셋을 즉각적으로 복제할 수 있어 어플리케이션 테스트 및 개발 환경에 매우 효과적인 Time to Market 개선 소프트웨어.

 4. MultiStore : 단일 스토리지 네트워크와 스토리지 자원을 논리적으로 분할하여 분할된 가상 스토리지간의 데이터 공유과 접근을 통제할 수 있는 Multi Domain & Multi Tenancy 소프트웨어.

III. 데이터 보호 소프트웨어 - 백업,복구

 1. Open Systems SnapVault : 이기종 스토리지 서버 데이터 보호 솔루션으로 Non-NetApp 스토리지 환경에서 Windows, Unix, Linux 등 Open Base 환경의 데이터를 넵앱의 백업스토리지로 백업하는 소프트웨어.

 2. SnapRestore : 전체 볼륨, 개별 파일 및 LUN을 이전 SnapShot으로 즉각적으로 복구하는 솔루션으로 용량에 관계없이 전체 볼륨을 1초 이내에 복구 가능한 최대 가용성을 제공하는 소프트웨어.

 3. SnapVault : 넷앱 D2D 백업 전용 소프트웨어로 최초 Initial Full 백업을 만든 후 영구적인 증분 백업이 가능하며 증분 백업만을 진행하더라도 full 백업 이미지 저장본을 가져가는 스토리지 공간 효율적인 버전관리 D2D 백업 소프트웨어

 4. MetroCluster : 최소의 비용으로 CDP 수준의 재해복구 인프라를 구축할 수 있는 넷앱읠 재해복구 솔루션.

 5. SnapMirror : 디스크 기반의 재해복구 솔루션으로 SnapShot 기술을 이용 넷앱 디스크에 저장된 데이터의 블록 단위로 복제 작업을 수행, FC,IP방식을 통해 데이터를 전송할 수 있어 큰 네트워크 대역폭이 필요하지 않은 복제 솔루션

Snapshot : Point in time copy

I. 운영

- Volume 영역에서 20%차지(default)

- 동일 볼륨에 대해 최대 255개의 snapshot 지원

- schedule & manual 백업 실행

II. 동작

그림1

그림2

III. Snapshot command

- snap list [-A | -V] [-n]  [[-q] [<vol-name>] | -o [<qtree-path>]]

- snap create [-A | -V] <vol-name> <name>

- snap delete [-A | -V] <vol-name> <snapshot-name> |

- snap delete [-A | -V] -a [-f] [-q]  <vol-name>

- snap delta [-A | -V] <vol-name> <old-snapshot-name> <new-snapshot-name>

- snap sched

- snap reserve [-A | -V] [<vol-name> [percent]]

- snap restore [-A | -V] [-f] [-t vol] | file] [-s <snapshot-name>] | [-r <restore-as-path>] <vol-name> | < restore-from-path>

IV. Snapshot schedule

- snap sched <vol_name> weekly nightly hourly@시간

ex) snap sched vol1 2 6 8@8,12,16,20

- snap list

 V. snapshot option

- client access to snapshot 설정:  #vol options <vol_name> snapdir [on|off]

- automatic snapshot 설정: #vol options <vol_name> nosnap [on|off]

- Snapshot (Flex Volume)

- Snapshot (Aggregate)

NetApp Deduplication

- 스토리지 효율성 향상

- FlexVol 볼륨이나 데이터 집합에서 블록 단위 중복 제거 제공

- metadata 생성 - 4KB 블록 단위

  그림1. How NetApp deduplication works at the highest level

동작: 새로 저장된 데이터는 기본적으로 4KB 블록에 저장. 데이터의 각 블록은 FlexVol 볼륨이나 데이터 constituent에 있는 다른 모든 Fingerprints와 비교되는 디지털 fingerprints를 가지고 있음. 이 fingerprints이 동일한 것으로 판단될 경우, 바이트 단위 비교는 블록의 모든 바이트로 이루어짐. 새로운 블록과 FlexVol 볼륨이나 데이터 constituent에 존재하는 블록 이 정확하게 일치하면 중복 블록은 폐기되고 해당 디스크 공간이 회수.

 그림2. Data structure in a deduplicated FlexVol volume or data constituent.

각 데이터 블록은 볼륨이나 데이터 contituent 메타 데이터의 참조 카운트를 갖는다. 기존 데이터를 공유하고 중복된 데이터 블록을 제거하는 과정에서 블록 포인터가 변경. 블록 포인터가 디스크에 남아있는 블록의 경우, 참조 카운트가 증가. 중복 데이터가 포함된 블록의 경우 참조 횟수가 감소. 제공된 블록 포인터는 데이터 블록에 대한 참조가 없으면 블록은 해제 됨.

중복 제거 기술의 핵심은 fingerprints. fingerprints는 FlexVol 볼륨이나 데이터 constituent마다 4KB 데이터 블록에 대해 고유 디지털 '서명'을 함.

중복 제거는 기존 데이터 볼륨에서 처음으로 실행하면 FlexVol 볼륨이나 데이터 constituent에 사용되는 블록에 대한 모든 fingerprints의 분류 목록이 포함된 fingerprints 데이터베이스를 만듦. 이 fingerprints를 만든 후, fingerprints 블록의 바이트 단위 비교가 블록이 실제로 동일한 지 확인하기 위한 것. 중복 검사 중 이들이 동일한 것으로 발견되면 블록의 포인터는 기존 데이터 블록에 업데이트되고 새로운 (중복)데이터 블록은 해제 됨.