원하는 위치에 파일 레이아웃 쓰기

Write Anywhere File Layout
와플
개발자넷앱
풀네임원하는 위치에 파일 레이아웃 쓰기
한계
최대 볼륨 크기최대 100 TB(애그리게이트 사이즈에 따라 제한됨, 플랫폼에 따라 최대 가변, 중복 배제 사용 시 최대 16 TB로 제한됨)ONTAP 8.2는 이제 플랫폼에서 지원되는 최대 볼륨 크기까지 중복 제거 지원)
최대 파일 크기최대 16[1] TB
특징들
기록된 날짜atime, ctime, mtime
파일 시스템 권한UNIX 권한 및 ACL
투과적 압축있음(Onap 8.0 이후)
투과적 암호화예(Ontap 9.[2]1 이후, 이전 버전의 경우 Decru DataFort와 같은 타사 어플라이언스에서 가능)
데이터 중복 배제있음(FAS 중복 배제: 정기적인 온라인 스캔, 블록 기반,)
카피 온 라이트네.
다른.
지원되는 운영 체제ONTAP

WAFL(Write Anywhere File Layout)은 대규모 고성능 RAID 어레이를 지원하며 크래시 또는 전원 장애 발생 시 긴 무결성 검사 없이 빠르게 재시작할 수 있으며 파일 시스템 크기를 빠르게 확장할 수 있습니다.NetApp FAS, AFF, Cloud Volumes ONTAP 및 ONTAP Select와 같은 스토리지 어플라이언스에서 사용할 수 있도록 NetApp에서 설계되었습니다.

WAFL은 [3]파일 시스템을 포함하고 있지만 파일 시스템은 아니라고 합니다.NVRAM 또는 NVMEM이라고 하는 전용 메모리 스토리지 디바이스의 비휘발성 랜덤 액세스 메모리에서 파일 시스템을 로그(NVLOG)로 저널링하는 것과 마찬가지로 변경을 추적합니다.WAFL은 디스크 블록에 액세스하기 위한 다양한 파일 시스템과 기술을 가능하게 하는 메커니즘을 제공합니다.

설계.

WAFL inode 구조, 데이터와 함께 저장된 메타데이터

WAFL은 데이터뿐만 아니라 메타데이터를 파일에 저장합니다.볼륨에 할당되어 있는 블록을 나타내는 inode나 블록 맵 등의 메타데이터는 파일 시스템의 고정 위치에 저장되지 않습니다.볼륨의 최상위 파일은 다른 모든 파일의 inode를 포함하는 inode 파일입니다. 루트 inode라고 하는 inode 파일 자체의 inode는 고정된 위치를 가진 블록에 저장됩니다.충분히 작은 파일을 위한 inode는 파일의 내용을 포함한다.그렇지 않으면, 파일 데이터 블록에 대한 포인터의 리스트 또는 파일 데이터 블록에 대한 포인터의 리스트를 포함한 간접 블록에 대한 포인터의 리스트가 포함되며, 필요한 만큼 많은 간접 블록의 레이어가 블록의 트리를 형성한다.루트 inode를 포함한 블록 이외의 파일 시스템 내의 모든 데이터 및 메타데이터 블록은 파일 시스템 내의 파일에 저장됩니다.따라서 루트 inode를 사용하여 inode [4]파일을 제외한 모든 파일의 모든 블록을 찾을 수 있습니다.

메인 메모리는 파일 블록의 페이지 캐시로 사용됩니다.파일 블록이 변경되면 페이지캐시 내의 복사본이 갱신되어 더티 마크가 붙습니다.이 차이는 NVLOG라고 불리는 로그에 비휘발성 메모리에 기록됩니다.페이지 캐시내의 더티 블록을 영구 스토리지에 쓰는 경우는, 읽어낸 블록에 고쳐 쓰는 것이 아니라, 새로운 블록이 영구 스토리지에 할당되어 블록의 내용이 새로운 장소에 기입되어 문제의 블록을 가리킨 inode 또는 간접 블록이 메인 메모리에 갱신된다.inode를 포함한 블록, 즉 간접 블록을 영구 스토리지에 쓰는 경우에는 이전 위치에서 덮어쓰기되는 것이 아니라 새로운 위치에 쓰기도 한다.이것이 "Write Anywhere File Layout"의 "Write Anywhere"가 [4]나타내는 것입니다.

루트 inode를 포함한 블록을 제외한 모든 블록은 루트 inode를 통해 검색되므로 루트 inode가 업데이트될 때까지 영구 스토리지에 기록된 변경 내용은 영구 스토리지에 표시되지 않습니다.루트 아이노드는 무결성 포인트라고 불리는 프로세스에 의해 갱신됩니다.이 프로세스에서는 영구 스토리지에 아직 기록되지 않은 모든 더티 블록이 영구 스토리지에 기록되고 새로운 루트 아이노드가 inode 파일의 새 버전의 블록을 가리키며 작성됩니다.이 시점에서 파일 시스템에 대한 모든 변경 내용은 새 루트 inode를 사용하여 영구 스토리지에 표시됩니다.현재 표시된 변경에 대한 NVLOG 엔트리는 후속 변경을 위한 로그엔트리를 위한 공간을 확보하기 위해 폐기됩니다.일관성 포인트는 정기적으로 수행되거나 비휘발성 메모리가 로그 [4]엔트리로 가득 찬 것에 가까운 경우에 수행됩니다.

일관성 포인트에서 파일시스템에 대한 모든 변경이 표시되기 전에 서버가 크래쉬 했을 경우, 아직 표시되지 않은 변경은 NVLOG에 남습니다.서버가 재부팅되면 NVLOG 내의 모든 엔트리가 재생되고 변경 내용이 NVLOG에 기록되므로 손실되지 않습니다.

특징들

위에서 설명한 바와 같이 WAFL은 데이터나 메타데이터를 디스크 상의 미리 정해진 위치에 저장하지 않습니다.대신 단일 패리티 및 이중 패리티 기반 RAID를 사용하여 안정적인 Disk 스토리지에 데이터를 커밋하는 데 필요한 Disk 작업 수를 최소화하도록 설계된 방식으로 사용자 데이터와 함께 메타데이터를 쓰기 위해 시간적 로컬리티를 사용하여 데이터를 자동으로 배치합니다.

참조의 시간적 위치에 기반한 데이터 배치를 사용하면 작성된 방법(예: 데이터베이스 기록 및 관련 색인 항목)과 유사한 방식으로 읽히는 읽기 데이터 세트의 성능을 개선할 수 있지만, 참조의 공간적 인접성의 관점에서 단편화를 야기할 수도 있다.회전하는 HDD에서는, 같은 시간 패턴을 사용해 차례차례 기입, 랜덤 읽기, 또는 그 후에 읽히는 파일에는 악영향을 주지 않습니다.다만, 자기 헤드가 플래터로부터 데이터를 읽어낼 수 있는 위치가 한 번에 1개뿐이기 때문에, 랜덤 기입 후의 순서 읽기에 영향을 줍니다.SSD 드라이브에는 영향을 주지 않습니다.

7.3.1 이후 ONTAP 릴리즈에는 예약 및 수동 조각 모음을 수행하는 reallocate 명령, 공간 조각화로 인해 발생하는 차선의 데이터 액세스 패턴을 감지하여 자동으로 수정하는 읽기 후 쓰기 볼륨 옵션 등 공간 데이터 레이아웃을 최적화하는 다양한 기술이 포함되어 있습니다.ONTAP 8.1.1 릴리즈에는 파일 시스템의 연속된 여유 공간을 자동으로 최적화하는 다른 기술이 포함되어 있어 대부분의 데이터 액세스 패턴에 대해 최적의 데이터 레이아웃을 유지할 수 있습니다.7G 이전에는 wafl scan reallocate 명령을 고급 권한 수준에서 호출해야 하므로 스케줄링할 수 없었습니다.9.1 이후 ONTAP 릴리즈에는 SSD Aggregate에 필요한 경우 콜드 데이터의 자동 계층화를 위한 ONTAP 9.2 FabricPool 기능, 최대 800TiB의 Aggregate 내 볼륨 중복제거 기능을 비롯하여 인라인 데이터 압축(9.1)과 같은 SSD 사용을 최적화하는 다양한 기술이 포함되어 있습니다.acch [5]골재

스냅숏

기존 Copy On Write 기술 데이터를 인플레이스 백업
NetApp RoW 스냅샷 데이터 인플레이스 백업

WAFL은 파일 시스템의 읽기 전용 복사본인 스냅샷을 지원합니다.스냅샷은 일관성 지점에서 수행되는 것과 동일한 작업을 수행하여 생성됩니다. 단, 파일 시스템의 현재 상태에 따라 루트 inode를 업데이트하는 대신 루트 inode의 복사본을 저장합니다.파일 시스템의 모든 데이터 및 메타데이터는 루트 inode에서 찾을 수 있으므로 스냅샷 생성 시점 현재 파일 시스템의 모든 데이터 및 메타데이터는 루트 inode의 스냅샷 복사본에서 찾을 수 있습니다.스냅샷을 [4]생성하기 위해 다른 데이터를 복사할 필요가 없습니다.

블록 맵을 사용하여 쓸 때 블록이 할당됩니다.이 맵은 사용 중인 블록과 사용 가능한 블록을 추적합니다.블록 맵의 엔트리는 블록이 파일 시스템의 현재 버전에서 사용 중인지 여부를 나타내는 비트와 블록이 스냅샷에서 사용 중인지 여부를 나타내는 여러 비트를 포함합니다.이렇게 하면 스냅샷이 삭제될 때까지 스냅샷의 데이터를 덮어쓰지 않습니다.블록 맵을 사용하면 모든 새로운 쓰기 및 개서가 새로운 빈 블록에 작성됩니다.WAFL은 블록 개서가 성공했다고 보고할 뿐 실제로 개서가 발생하지 않습니다.이 접근방식은 Redirect-on-Write(ROW; 리다이렉트 온-write) [4]기술이라고 불립니다.ROW는 원래 데이터를 보존하기 위해 스냅샷에 저장되고 다시 작성되는 이전 데이터 블록을 먼저 스냅샷 예약용으로 할당된 공간에 복사해야 하는 Copy-on-Write 작업에 비해 개서 작업이 훨씬 빠릅니다.

스냅샷은 파일 시스템의 숨겨진 특수 디렉토리를 통해 빠르게 액세스할 수 있는 온라인 백업을 제공하며, 사용자가 실수로 삭제 또는 [4]수정된 파일을 복구할 수 있습니다.

NetApp의 Data ONTAP 릴리스 7G 운영 체제는 FlexClone이라는 읽기-쓰기 스냅샷을 지원합니다.스냅샷은 SnapMirror, SnapVault 및 Online Volume Move와 같은 기술의 기반이며 FlexClone, SnapLock, SnapRestore와 같은 기능은 WAFL 기능과 inode를 사용한 조작과 같은 속성을 활용하는 스냅샷과 같은 기술입니다.ONTAP 9.4부터는 각 FlexVol에서 지원되는 최대 스냅샷 수가 1024개인데 반해 이전 버전의 경우 최대 255개입니다.

ONTAP 9.5 스냅샷 공유 기능은 Active 파일 시스템 및 스냅샷에 대해 중복제거 검사를 실행하는 데 추가되었으며, 중복제거를 통해 스냅샷 수를 크게 줄일 수 있습니다.9.5 이전에는 스냅샷에 잠긴 중복 제거되지 않은 데이터는 중복 제거 프로세스에서 사용할 수 없었고 활성 파일 시스템에서만 실행되었습니다.

파일 및 디렉토리 모델

WAFL의 중요한 기능은 NFS 클라이언트의 경우 Unix 스타일의 파일 및 디렉토리 모델과 SMB 클라이언트의 경우 Microsoft Windows 스타일의 파일 및 디렉토리 모델을 모두 지원하는 것입니다.또한 WAFL은 같은 볼륨의 다른 파일에 다른 보안 속성을 부가할 수 있는 모드를 포함하여 두 보안 모델을 모두 지원합니다.Unix 에서는 Access Control List(ACL; 접근컨트롤 리스트) 또는 단순한 비트마스크 중 하나를 사용할[6] 수 있지만 최신 Windows 모델은 접근컨트롤 리스트를 기반으로 합니다.이러한 두 가지 기능을 통해 SMB 유형의 네트워크 파일 시스템에 파일을 쓰고 나중에 Unix 워크스테이션에서 NFS를 통해 액세스할 수 있습니다.WAFL은 일반 파일과 함께 블록 장치의 LUN 일련 번호와 같은 필수 특수 특성을 가진 LUN이라는 파일 컨테이너를 포함할 수 있으며, ONTAP OS 소프트웨어에서 실행되는 SAN 프로토콜을 사용하여 액세스할 수 있습니다.

FlexVol

WAFL FlexVol Layout: 사용자 데이터와 함께 메타데이터 블록 및 inode

각 FlexVol(FlexVol)은 Aggregate에 위치하며 Aggregate의 모든 Disk에 분산되는 별도의 WAFL 파일 시스템입니다.각 Aggregate에는 여러 개의 FlexVol 볼륨이 포함될 수 있으며 일반적으로 여러 개의 FlexVol 볼륨이 있습니다.Consistency Points(NVRAM 참조)로 끝나는 "Tetris"를 비롯한 데이터 최적화 프로세스 중에 ONTAP은 각 FlexVol 볼륨에서 데이터 블록을 Aggregate의 모든 Disk에서 사용 가능한 모든 성능을 사용할 수 있도록 프로그래밍됩니다.Aggregate의 모든 데이터 Disk에 데이터 블록을 균등하게 분산하는 방식을 사용하면 FlexVol의 성능 조절을 스토리지 QoS로 동적으로 수행할 수 있으며, 성능을 보장하고 필요한 FlexVol 볼륨에 사용되지 않는 성능을 제공하기 위해 각 FlexVol에 대해 전용 Aggregate 또는 RAID 그룹이 필요하지 않습니다.각 FlexVol은 씩 또는 씬 프로비저닝된 공간으로 구성할 수 있으며 나중에 언제든지 즉시 변경할 수 있습니다.iSCSI, FC(Fibre Channel), FCoE(Fibre Channel over Ethernet) 등의 SAN(Storage Area Network) 프로토콜을 사용한 블록 디바이스 액세스는 FlexVol 볼륨 위에 Loop 디바이스 기술과 유사한 LUN 에뮬레이션을 사용하여 수행되므로 WAFL 파일 시스템의 각 LUN은 파일로 표시되지만 블록 디바이스에 대한 추가 속성이 필요합니다.LUN은 씩 또는 씬 프로비저닝으로 구성할 수도 있으며 나중에 즉시 변경할 수도 있습니다.WAFL 아키텍처를 통해 FlexVol 및 LUN은 구성된 공간 사용을 즉각적으로 늘리거나 줄일 수 있습니다.FlexVol에 데이터가 포함된 경우 내부 공간을 사용된 공간보다 적게 줄일 수 있습니다.데이터가 포함된 LUN 크기는 WAFL 파일 시스템에서 줄어들 수 있지만, ONTAP은 SAN 아키텍처로 인해 상위 레벨 블록 구조에 대한 지식이 없으므로 데이터를 잘라내고 해당 LUN의 파일 시스템을 손상시킬 수 있으므로 호스트는 데이터가 포함된 블록을 새 LUN 경계로 마이그레이션하여 데이터 손실을 방지해야 합니다.각 FlexVol은 자체 QoS, FlashPool, FlasCache 또는 FabricPool 정책을 가질 수 있습니다.

2개의 FlexVol 볼륨이 생성된 경우, 각각 2개의 Aggregate와 2개의 서로 다른 컨트롤러가 소유한 Aggregate에 있으며, 시스템 관리자는 NAS 프로토콜을 통해 이러한 볼륨의 공간을 사용해야 합니다.그런 다음 각 볼륨에 하나씩 두 개의 파일 공유를 생성합니다.이 경우 관리자는 대부분 다른 IP 주소를 만들 수 있으며 각각 전용 파일 공유에 액세스하기 위해 사용됩니다.각 볼륨에는 1개의 write wappinity가 있고, 두 버킷의 공간이 있습니다.2개의 볼륨이 단일 컨트롤러(예를 들어, 1개의 Aggregate(두 번째 Aggregate가 존재하는 경우 두 번째 Aggregate는 사용되지 않음)에 있고, 두 볼륨 모두에 단일 IP 주소를 통해 액세스되더라도 여전히 각 볼륨에 하나씩 두 개의 쓰기 선호도가 있으며 항상 두 개의 개별 버킷이 있습니다.따라서 볼륨이 많을수록 waffinity 쓰기(병렬화 및 CPU 사용률 향상)가 증가하지만 볼륨은 여러 개(공간용 버킷이 있으므로 파일 공유가 여러 개)하게 됩니다.

플렉스

플렉스를 사용한 SyncMirror 레플리케이션

RAID 1과 마찬가지로 ONTAP 시스템의 플렉스는 미러링된 데이터를 2곳에 보관할 수 있지만, 기존 RAID-1은 1개의 스토리지 시스템 범위 내에 있어야 하지만 2개의 플렉스를 2개의 스토리지 시스템 간에 분산할 수 있습니다.각 Aggregate는 1개 또는 2개의 플렉스로 구성됩니다.기존 HA 스토리지 시스템은 Aggregate당 하나의 플렉스만 있는 반면 SyncMirror 로컬 또는 MetroCluster 구성은 Aggregate당 2개의 플렉스를 가질 수 있습니다.한편, 각 플렉스에는 RAID 0과 마찬가지로 1개 이상의 NetApp RAID 그룹 또는 서드파티 스토리지 시스템(FlexArray 참조)의 LUN의 기본 스토리지 공간이 단일 플렉스에 포함됩니다. Aggregate가 2개의 플렉스로 구성되어 있는 경우, 1개의 플렉스는 마스터로 간주되고 2개의 플렉스는 슬레이브로 완전히 동일한 RAID 구성으로 구성되어야 합니다.nd 드라이브예를 들어 마스터 플렉스가 RAID-TEC에서 21개의 데이터 및 3개의 1.8TB SAS 패리티 드라이브로 구성된 Aggregate가 있는 경우, 슬레이브 플렉스는 RAID-TEC에서 21개의 데이터 및 3개의 1.8TB SAS 패리티 드라이브로 구성되어야 합니다.두 번째 예에서는 마스터 플렉스가 RAID 17 데이터 1개와 패리티 SAS 드라이브 3개로 구성된 Aggregate 2개로 구성되어 있으며 마스터 플렉스의 두 번째 RAID는 데이터 2개와 패리티 SSD 960GB로 구성된 RAID-DP입니다.두 번째 플렉스는 RAID 17 데이터 드라이브 1개와 패리티 SAS 드라이브 3개가 RAID-TEC로 구성되어 있어야 합니다.슬레이브 플렉스의 두 번째 RAID는 RAID-DP로 데이터 2개와 패리티 SSD 960GB 2개입니다.MetroCluster 구성은 동기 데이터 복제를 위해 SyncMirror 기술을 사용합니다.SyncMirror 옵션은 다음 두 가지가 있습니다.MetroCluster 및 Local SyncMirror는 모두 동일한 플렉스 기술을 사용하여 2개의 플렉스 간에 데이터를 동기식으로 복제합니다.Local SyncMirror는 단일 컨트롤러에 두 플렉스를 모두 생성하며 스토리지 시스템의 전체 Disk 쉘프에서 장애를 방지하기 위한 추가 보안에 자주 사용됩니다.MetroCluster를 사용하면 두 스토리지 시스템 간에 데이터를 복제할 수 있습니다.각 스토리지 시스템은 하나의 컨트롤러로 구성되거나 두 개의 컨트롤러가 있는 HA 쌍으로 구성할 수 있습니다.단일 HA 쌍에서는 2개의 컨트롤러를 별도의 섀시에 배치할 수 있으며, MetroCluster 구성에서는 최대 300km의 거리가 될 수 있습니다.

비휘발성 메모리

MetroCluster 및 HA의 비휘발성 메모리 캐시 미러링

다른 경쟁업체와 마찬가지로 NetApp ONTAP 시스템도 메모리를 훨씬 더 빠른 스토리지 미디어로 활용하여 호스트의 데이터를 수용 및 캐슁하고, 무엇보다 쓰기 전 데이터 최적화를 통해 이러한 스토리지 시스템의 성능을 크게 향상시킵니다.경쟁업체에서는 쓰기 캐싱 및 데이터 최적화를 위한 재부팅과 같은 예기치 않은 상황에서도 데이터를 보존하기 위해 NVRAM(비휘발성 랜덤 액세스 메모리)을 광범위하게 사용하는 반면, NetApp ONTAP 시스템은 데이터 최적화를 위해 일반 RAM(랜덤 액세스 메모리)을 사용하고 초기 데이터 기록에는 변경되지 않은 상태의 전용 NVRAM 또는 NVDIMM을 사용합니다.릴레이셔널 데이터베이스에서 실행되는 트랜잭션 기록과 유사하게 호스트에서 전송됩니다.따라서 장애 발생 시 RAM은 reboot 후 자동으로 클리어되며 NVLOG라고 불리는 로그 형태로 비휘발성 메모리에 저장된 데이터는 reboot 후에도 유지되며 restore의 일관성을 유지하기 위해 사용됩니다.ONTAP 시스템의 모든 변경 및 최적화는 RAM에서만 수행되므로 ONTAP 시스템의 비휘발성 메모리 크기를 줄일 수 있습니다.Tetris와 같은 방식으로 구조된 호스트의 데이터를 최적화한 후 데이터를 저장할 Aggregate의 RAID 그룹의 기본 디스크에 몇 가지 단계(WAFL 및 RAID)를 거쳐 최적화 및 준비합니다.최적화 후 데이터는 CP(Consistency Point) 트랜잭션의 일부로 디스크에 순차적으로 기록됩니다.Aggregate에 기입된 데이터에는 필요한 WAFL 메타데이터와 RAID 패리티가 포함되어 있기 때문에 기존 RAID-6 및 RAID-4 그룹과 같이 데이터 디스크에서 추가 읽기, 계산 및 패리티 디스크 쓰기 작업이 발생하지 않습니다.CP는 처음에 데이터를 쓰는 Aggregate에 시스템 스냅숏을 작성한 후 RAM에서 Aggregate에 대해 단일 트랜잭션으로 순차적으로 쓴 데이터를 최적화하고 준비하는 데 실패하면 WAFL 파일 시스템이 갑자기 재부팅되면 트랜잭션 전체가 실패합니다.CP 트랜잭션이 성공하면 새로운 활성 파일 시스템 포인트가 전파되고 대응하는 NVLOG가 지워집니다.모든 데이터는 항상 새로운 장소에 쓰이며, 개서할 수 없습니다.빈 상태로 마크된 호스트에 의해 삭제된 데이터 블록은 나중에 다음 CP 사이클에서 사용할 수 있으며 WAFL의 항상 새로운 데이터 투 플레이스 정책에 따라 시스템의 공간이 부족하지 않습니다.HA 스토리지 시스템의 NVLOG만 HA 스토리지 시스템 페일오버 기능을 위해 두 컨트롤러 간에 동기식으로 복제되므로 전체 시스템 메모리 보호 오버헤드를 줄일 수 있습니다.HA 구성에 2개의 컨트롤러가 있는 스토리지 시스템 또는 각 사이트에 1개의 컨트롤러가 있는 MetroCluster에서 2개의 컨트롤러는 각각 자체 비휘발성 메모리를 로컬과 파트너의 두 부분으로 나눕니다.노드가 4개인 MetroCluster 구성에서는 각 비휘발성 메모리는 로컬, 로컬 파트너 및 원격 파트너의 [7]다음 부분으로 나뉩니다.

NetApp은 All-Flash FAS A800 시스템에서 NVRAM PCI 모듈을 메모리 버스에 연결된 NVDIMM으로 교체하여 성능을 향상시켰습니다.

「 」를 참조해 주세요.

메모들

  1. ^ "Storage limits". library.netapp.com.
  2. ^ "NetApp Volume Encryption, The Nitty Gritty IOPS.ca". 30 November 2016.
  3. ^ "Is WAFL a File System?". Blogs.netapp.com. Archived from the original on July 15, 2014.
  4. ^ a b c d e f Dave Hitz; James Lau; Michael Malcolm (January 19, 1994). File System Design for an NFS File Server Appliance (PDF). USENIX Winter 1994.
  5. ^ Parisi, Justin (July 14, 2017). "Running VMware on ONTAP? Why you should consider upgrading to ONTAP 9.2".
  6. ^ "POSIX Access Control Lists on Linux". Suse.de. Archived from the original on 2007-01-24.
  7. ^ "Clustered Data ONTAP® 8.3. MetroCluster™ Management and Disaster Recovery Guide: NVRAM and NVMEM cache mirroring in a MetroCluster configuration". NetApp. 1 September 2015. Archived from the original (url) on 2018-01-24. Retrieved 24 January 2018.

외부 링크