여기서 다루는 내용
· 시작
· Amazon FSx 서비스 개요
· 더 알아볼 것들
· 정리
Intro
안녕하십니까, GS네오텍 최준승입니다.
AWS에서 제공하는 공유 스토리지 서비스로는 EFS가 있습니다.
제 기억으로는 이 서비스가 2015년 어디 미국 AWS 써밋에서 발표가 되었구요.
'18년 5월인가 드디어 서울 리전에서 사용할 수 있게 되었습니다.
기존과 동일한 프로토콜로 마운트해서 쓰면 되기 때문에.
어플리케이션 뜯어-고치기 싫어하는 한국 특성상 많이 쓰일 줄 알았는데. 생각보다는 인기가 덜한 느낌이더군요.
사실 EFS는 NFSv4 프로토콜이 기본이기 때문에 리눅스가 아닌 윈도우 환경에서 좀 부적합한 측면도 있었습니다.
그래서 뭔가 Windows Native한 관리형 공유 파일시스템이 하나 나올때쯤 됐는데.. 라는 생각이 들때.
역시나 하고 Reinvent 2018에 똭하고 신규 서비스가 나왔습니다.
오늘 소개드릴 완전 관리형(Full-Managed) 윈도우 파일 서버인 "Amazon FSx for Windows File Server"입니다.
Amazon FSx for Windows File Server?
서비스 주요 특징입니다.
- Windows 기반의 완전 관리형 파일 시스템
- SMB 프로토콜(v2.0 ~ 3.1.1) 사용하여 Access
- EC2, WorkSpaces, AppStream 2.0, VMware Cloud on AWS VM에서 연결
- Active Directory와 통합, DFS(Microsoft Distributed File System) 지원
표준 프로토콜을 사용하기 때문에. 대부분의 Windows OS에서는 지원이 된다고 생각하셔도 무방하구요.
Linux 계열에서도 Samba 클라이언트를 쓰면 되기 때문에. 원하신다면 활용이 가능합니다.
그럼 이쯤에서 제가 한번 맹글어 보겠습니다.
※ [AWS Management Console] ▷ [FSx] ▷ [Create File System]
오늘은 왼쪽입니다. 오른쪽것은 다음에 소개드릴 예정.
※ 필요한 용량과 성능값을 지정. 참고로 용량은 300GB - 64TB 범위 내 지정
※ 해당 파일 서버 객체가 생성될 VPC와 Subnet을 지정
참고로 캡쳐엔 생략되었지만. 사용자 인증에 사용할 Active Directory ID도 반드시 지정해줘야 합니다.
※ 추가로 백업과 메인터넌스 설정을 할 수 있습니다
이제 좀 기다려봅시다. 완료까지 20분 정도 걸리네요. 아래 보시다시피 "어밸러블" 상태가 되었습니다.
※ 드라이브 매핑에 사용할 주소값이 딱히 보이질 않네요. 이따 저 File System ID와 AD 주소를 섞어서 사용하게 됩니다
※ 심심해서 해당 VPC 내에 ENI 목록을 조회해 보았습니다. Description을 보니 FSx 객체에서 사용하는 ENI가 나래비되네요
자, 이제 파일시스템은 다 만들었으니. 클라이언트에서 연결해서 쓰면 되겠죠?
저는 Windows Server 2016 AMI로 EC2 인스턴스를 하나 만들었습니다. 물론 동일한 VPC에 생성을 했구요.
이어 RDP 접속을 했습니다. 네트웍 드라이브를 연결하는 방법은 다양하겠지만. 저는 데모니 수동으로 붙여 보겠습니다.
※ [File Explorer] ▷ [Network] 우클릭 ▷ [Map Network Drive]
※ "\fs-012345678901234567.ad-domain.comshare" 주소규칙에 따라 제 환경값을 입력
앞에서 만든 파일시스템을 X: 드라이브로 공유를 잡았습니다.
※ 편의상 AD의 Admin 계정으로 인증
※ 300GB 크기의 디스크가 네트웍 드라이브로 할당된 것을 확인할 수 있다
보신것처럼. 모든 작업이 아주 손쉽게 완료되었습니다.
더 알아볼 사항
좀 더 디테일한 내용들을 꼭지별로 간략하게 정리해 보겠습니다.
:: DFS를 활용한 복수의 파일시스템 통합
DFS는 복수의 공유 객체를 하나 이상의 논리적으로 구성된 Namespace로 그룹화할 수 있는 Windows Server 역할 서비스입니다.
앞에서 말씀드렸듯이 Amazon FSx는 DFS를 지원하기 때문에. DFS Namespace를 통해 여러가지 구성을 만들어낼 수 있습니다.
※ Scaling Out Performance with Shards
※ Scaling Out Read Performance with Read Replicas
※ Grouping Multiple File Systems into a Common Namespace
※ Multi-AZ File System Deployments
목적에 따라 복수의 파일시스템을 묶어. 하나의 논리적인 DFS 네임스페이스로 관리하는 구성입니다.
샤딩을 통해 단위 성능을 향상시키거나.. AZ에 걸쳐 파일시스템을 이중화하는 것이 가능합니다.
주석을 참고하시고 편의상 자세한 설명은 생략하겠습니다.
:: 보안 기능
- 파일/폴더 단위의 Access Control은 Active Directory 정책에서 제어합니다
- 클라이언트와 파일시스템간 네트웍 Access Control은 기존 VPC 규칙을 따릅니다: Security Group / Network ACLs
- Amazon FSx 객체 생성/조정/삭제에 대한 권한은 AWS IAM 권한을 따릅니다
- KMS 서비스와 통합되어 At Rest 암호화됩니다. 전송단 암호화는 SMB 프로토콜이 3.0 이상일때 지원합니다
- 백업 기능을 지원합니다. 일단위 자동백업을 하거나 원하는 시점에 수동백업본을 만드는 것이 가능합니다. 백업은 증분방식
:: 과금 구조
파일시스템 생성시 과금 안내가 나옵니다. 참고용으로 한번 보시죠.
- Storage capacity: 파일시스템에 할당한 용량별 월환산 과금
- Throughput capacity: 지정한 성능 수치별 과금. 별도로 더 높은 capacity를 설정하면 비례해서 높은 요금 부과
- Backup storage: 생성한 백업본 용량별 과금
물론 리전별로 단가가 다르며, 일반적으로 볼 수 있는 AWS 서비스스러운 과금 체계입니다.
마치며
정리합니다.
가만 보면 EFS 서비스랑 비슷하면서도. 세부적으로 들어가면 근본적으로 다른 부분이 많이 보이는데요.
파일 시스템 생성 이후 서비스를 컨트롤 하는것은 기존 윈도우 시스템의 방식을 그대로 준용하고 있습니다.
'18년 12월 기준, 사용 가능한 리전은 Virginia/Ohio/Oregon/Ireland로 서울 리전은 해당되지 않습니다.
성능 구조나 좀 더 상세한 부분은 기회가 되면 다시 리뷰하도록 하고. 오늘은 여기서 마치도록 하겠습니다.
끝!
