03. Amazon FSx

Amazon FSx

AWS 에서 제공하는 fully managed 3rd party high-performance file systems service 다. 아래와 같은 타입의 파일시스템을 완전관리형으로 제공한다.

FSx for Windows File Server
FSx for Lustre
FSx for NetApp ONTAP
FSx for OpenZFS

4종 비교

	Windows File Server	Lustre	NetApp ONTAP	OpenZFS
프로토콜	SMB 2.0 ~ 3.1.1	Lustre (POSIX 호환)	NFS, SMB, iSCSI, NVMe	NFS v3 ~ v4.2
클라이언트	Windows, Linux	Linux	Linux, Windows, macOS	Linux, Windows, macOS
주 용도	Windows 업무 공유, 홈 디렉터리, AD 환경	HPC, ML 학습, S3 데이터 고속 처리	온프레미스 NetApp 이전, 멀티프로토콜	ZFS/Linux NFS 파일 서버 이전

고르는 순서
- 프로토콜로 먼저 거른다: SMB 는 Windows File Server 또는 ONTAP, NFS 는 ONTAP 또는 OpenZFS, 블록(iSCSI, NVMe)은 ONTAP
- Linux 외 클라이언트가 섞여 있으면 Lustre 는 제외한다
- 대규모 병렬 처리량이 우선이면 Lustre, snapshot 과 clone 중심의 데이터 관리가 중요하면 OpenZFS 또는 ONTAP
- 온프레미스 NetApp 과 하이브리드로 운영하면 ONTAP

Amazon FSx for Lustre

Lustre 파일시스템

Lustre 파일시스템은 1999년 CMU 에서 개발한 오픈소스 병렬 파일시스템으로 지리 정보 처리, 금융 모델링 등 HPC 기반 워크로드에 주로 활용한다.
대규모 확장으로 ms 미만의 지연 시간, 초당 최대 수백GB-수백만GB IOPS 로 데이터를 처리할 수 있다.
POSIX 호환으로 기존 Linux 기반 응용 프로그램을 사용한다.

EC2 에서 FSx for Lustre 마운트하기

sudo dnf install -y lustre-client # lustre-client 를 설치하고
sudo mkdir -p /mnt/fsx # 마운팅할 디렉터리를 생성하고
sudo mount -t lustre -o relatime,flock ${file_system_dns_name}@tcp:/${mountname} /mnt/fsx # FSx for Lustre 를 마운팅

04. Amazon S3 와 연동할 수 있다.

Lustre 아키텍처 — MDT 와 OST

Lustre 는 메타데이터와 데이터를 물리적으로 분리하고, 데이터를 여러 서버에 쪼개 저장하는 분산 파일시스템이다.

구성 요소	풀네임	역할
MDT	Metadata Target	파일명, 디렉터리 구조, 권한, inode, layout(데이터가 어느 OST 에 있는지) 저장. 실제 파일 내용은 없음
OST	Object Storage Target	실제 파일 데이터(바이트) 저장. 여러 개로 분산
MGT	Management Target	클러스터 설정 (보통 노출 안 됨)

서버 단위로는 MDS (Metadata Server) / OSS (Object Storage Server). Target 은 그 서버에 붙은 저장 장치 단위.
FSx for Lustre 는 보통 MDT 하나(MDT0000) + OST 여러 개로 구성된다.

접근 흐름 — client 는 데이터를 OST 와 직접 통신한다. MDT 는 “어디 있나” 만 알려주고 빠진다.

1. client: open("/mnt/fsx/bigfile")
              ↓
2. MDT: "이 파일은 OST0,1,2,3 에 stripe_size 1M 로 흩어져 있다" (layout 반환)
              ↓
3. client → OST0,1,2,3 와 동시에 직접 read/write (MDT 안 거침)

→ 데이터 path 가 단일 서버에 묶이지 않는 게 핵심.

Striping — 데이터 분산 방식

파일을 stripe_size 단위 청크로 잘라 여러 OST 에 round-robin 분산한다 (RAID-0 방식, replica 아님).

stripe_size = 청크 하나 크기. Lustre 기본 1 MB.
stripe_count = 몇 개 OST 에 분산할지.

예시 — stripe_count=4, stripe_size=1MB, 10 MB 파일:

파일:  [0-1M][1-2M][2-3M][3-4M][4-5M][5-6M][6-7M][7-8M][8-9M][9-10M]
          ↓     ↓     ↓     ↓     ↓     ↓     ↓     ↓     ↓     ↓
        OST0  OST1  OST2  OST3  OST0  OST1  OST2  OST3  OST0  OST1

분산 방식별:

큰 파일 = n 분할 striping (stripe_count>1)
작은 파일 = 한 OST 통째 (stripe_count=1)
아주 작은 파일 = DoM (Data on MDT) 으로 MDT 에 데이터까지 직접 저장 (OST 왕복 제거)
replica = 기본 아님. 내구성은 하부 스토리지(RAID), AWS 가 책임

HPC 에 유리한 이유

병렬성 두 축으로 일반 NAS(NFS) 가 못 내는 aggregate 대역폭을 낸다.

단일 파일의 병렬 대역폭 = 한 client 가 큰 파일 하나 읽어도 여러 OST 에서 동시에 → 단일 OST 대역폭 × OST 수. (1 GB 를 한 서버에서 받는 것보다 100 MB 씩 10 서버에서 동시에 받는 게 빠른 원리)
다중 client 병렬성 = 수천 compute 노드가 각자 다른 OST 두드림 → 단일 병목 없음
데이터 path 와 메타데이터 path 분리 = 데이터 전송이 MDT 안 거쳐 둘이 독립 scale

	일반 NAS (NFS)	Lustre
파일 하나	서버 1대가 처리	여러 OST 병렬
대역폭 한계	단일 서버	OST 수만큼 합산
메타데이터/데이터	같은 서버	분리 (MDT vs OST)
scale	scale-up	scale-out (OST 추가)
단, 병렬 효과는 client NIC 대역폭, straggler(느린 OST 하나), stripe 오버헤드에 막힐 수 있다. 작은 파일 다수는 striping 이 오히려 손해다.

df vs lfs df

df = 범용 POSIX 도구. Lustre 마운트를 하나의 파일시스템으로 보고 합산 용량만 표시. statfs() 호출.
lfs df = Lustre 전용 client 유틸(lfs = Lustre FileSystem). 구성 target(MDT/OST) 마다 따로 조회.

$ lfs df -h
UUID               bytes  Used  Available  Use%  Mounted on
fsx-MDT0000_UUID   ...                            /mnt/fsx[MDT:0]
fsx-OST0000_UUID   ...                            /mnt/fsx[OST:0]
fsx-OST0001_UUID   ...                            /mnt/fsx[OST:1]
...

fsx-MDT0000_UUID = 메타데이터 target. fsx-OST0000_UUID 등 = 데이터 target 들.
Mounted on 의 /mnt/fsx[OST:0] = 진짜 마운트 포인트 아님. <마운트경로>[타입:인덱스] 라벨. 전부 같은 /mnt/fsx 에 마운트돼 있다.
bytes, Used, Available, Use% = 각 target 하나의 용량.

왜 구분이 중요한가:

MDT 와 OST 는 따로 찬다. MDT(메타데이터) 고갈 시 OST 공간 남아도 새 파일 생성 불가. 작은 파일 수억 개 = MDT 고갈, 큰 파일 = OST 고갈.
OST 불균형 = df 는 합산이라 “공간 있음” 으로 보이지만 특정 OST 가 꽉 차면 그 OST 로 가는 쓰기는 ENOSPC 실패. lfs df 로만 발견 가능.

자주 쓰는 lfs 명령:

lfs df -h                      # target별 용량
lfs df -i                      # inode 기준 (MDT 메타데이터 고갈 확인)
lfs getstripe <파일>           # 이 파일이 어느 OST 에 어떻게 쪼개졌나
lfs setstripe -c 4 <디렉터리>  # 이 디렉터리 새 파일은 OST 4개에 stripe
lfs find <경로> ...            # Lustre 최적화 find (MDT 직접 질의)
lfs quota -u <user> /mnt/fsx   # 사용자별 quota

Throughput tier — 용량에 묶인 성능

FSx for Lustre 의 throughput 은 따로 못 사고 용량에 묶여 있다.

총 throughput (MB/s) = 스토리지 용량 (TiB) × throughput tier (MB/s per TiB)

배포 타입	throughput per TiB	비고
Scratch (SSD)	200 MB/s/TiB (+ burst)	임시, 복제 X, 저렴
Persistent_2 (SSD)	125 / 250 / 500 / 1000 중 선택	영구, AZ 내 복제
예시 — Persistent_2, `500 MB/s/TiB`, `4.8 TiB` → 총 `2400 MB/s`.

용량에 묶이는 이유 = 용량을 키우면 내부 OST 가 늘어나기 때문. 용량 ↑ = OST 수 ↑ = striping 병렬도 ↑ = aggregate throughput 선형 증가. AWS 가 이걸 “MB/s per TiB” 로 추상화해 판다.

성능 튜닝 두 노브:

용량 ↑ → OST 수 ↑ → 병렬 대역폭 ↑
tier ↑ (125 → 1000) → 같은 용량에서 OST 당 provisioned 대역폭 ↑

Scratch vs Persistent

	Scratch	Persistent_2
용도	임시 (단기 처리, 중간 결과)	장기, 중요 데이터
복제	없음 — 서버 장애 시 데이터 손실	AZ 내 복제
throughput	200 MB/s/TiB + burst	125~1000 선택 (provisioned 안정)
비용	저렴	비쌈
전형	HPC 중간 계산, CI artifact	ML 학습 데이터셋, 반복 접근

Scratch 가 괜찮은 경우 = 원본이 04. Amazon S3 에 있고 FSx 는 빠른 작업 공간일 때. 날아가도 S3 에서 다시 hydrate.
Scratch 의 burst = baseline 200 MB/s/TiB 위로 일시적 spike 흡수 (credit 모델).

Amazon FSx for Windows File Server

Windows Server 기반의 완전 관리형 Windows 파일 서버, SMB 2.0 ~ 3.1.1 지원
인증은 Microsoft Active Directory, 파일/폴더 권한은 Windows ACL 로 제어한다
백업은 Windows VSS 로 파일시스템 정합성을 맞춘 증분 백업이며, 일일 자동 백업이 기본 활성화된다
저장 시 KMS 로, 전송 중에는 SMB Kerberos 세션 키로 자동 암호화된다
배포: Single-AZ, Multi-AZ (다른 AZ 에 standby 파일 서버를 두고 failover)
스토리지는 SSD 또는 HDD 이며, 스토리지 용량, SSD IOPS, throughput 을 독립적으로 프로비저닝하고 이후에 변경할 수 있다
온프레미스에서는 Direct Connect 또는 Site-to-Site VPN 으로 접근한다

Amazon FSx for NetApp ONTAP

NetApp ONTAP 파일시스템 기반의 완전 관리형 서비스
NFS, SMB, iSCSI, NVMe 멀티프로토콜로 파일 스토리지와 블록 스토리지를 함께 제공한다
자주 쓰지 않는 데이터를 저비용 capacity pool 계층으로 자동 tiering 해 일부 데이터만 SSD 비용을 낸다
압축, 중복 제거, compaction 으로 사용량을 줄인다
snapshot, clone, SnapMirror 복제(cross-Region DR), FlexCache(온프레미스 캐싱)를 지원한다
SnapLock WORM (Compliance, Enterprise retention 모드)을 지원한다
온프레미스 NetApp ONTAP 사용자는 코드와 데이터 관리 방식을 바꾸지 않고 이전, 백업, burst 할 수 있다
배포: Single-AZ, Multi-AZ

Amazon FSx for OpenZFS

OpenZFS 파일시스템 기반의 완전 관리형 서비스, 온프레미스 ZFS 또는 Linux 파일 서버 이전용
NFS v3, v4.0, v4.1, v4.2 로 Linux, Windows, macOS 에서 접근한다
즉시 point-in-time snapshot, data cloning, 압축을 지원한다
스토리지 클래스
- Intelligent-Tiering: 크기를 미리 정하지 않고 저장한 만큼 과금, SSD read cache 옵션
- SSD: 크기를 지정하고 프로비저닝한 만큼 과금
성능: 디스크 기준 최대 400,000 IOPS, 10 GBps, 메모리/NVMe 캐시 기준 수백만 IOPS, 최대 21 GBps
배포: Multi-AZ (HA), Single-AZ (HA), Single-AZ (non-HA)
백업은 S3 에 저장되며 cross-Region 백업 복사를 지원한다

meatsby.github.io

Explorer