중요 업데이트 :
2018 년 10 월 AWS는 EFS를 지원하는 네트워크 기술의 기능을 확장하여 이제 아래에 설명 된 프록시 해결 방법에 의존하지 않고 관리 형 VPN 연결 및 리전 간 VPC 피어링에서 기본적으로 작동합니다.
https://aws.amazon.com/about-aws/whats-new/2018/10/amazon-efs-now-supports-aws-vpn-and-inter-region-vpc-peering/
EFS는 2016 년 말 AWS Direct Connect 회로를 통한 연결 지원을 추가했습니다.
https://aws.amazon.com/blogs/aws/amazon-efs-update-on-built-access-via-direct-connect-vpc/
코멘트는 몇 가지 흥미로운 문제를 제기했습니다. 처음 질문을 읽었을 때, 나는 당신보다 EFS에 더 익숙하다고 가정했을 것입니다.
먼저, 약간의 배경 지식 :
Elastic File System의 "Elastic"은 주로 외부 액세스 유연성이 아니라 스토리지 공간 및 처리량의 자동 확장을 나타냅니다.
EFS에는 저장할 수있는 데이터 양에 대한 의미있는 제한이없는 것 같습니다. EFS 볼륨에서 단일 파일의 문서화 된 최대 크기는 52,673,613,135,872 바이트 (52TiB) 입니다. 다른 한계의 대부분은 비슷하게 관대합니다.
EFS는 청구되는 방식에서 특히 "탄력적"입니다. EBS 볼륨의 파일 시스템과 달리 공간은 EFS에 사전 할당되지 않으며 시간당 평균으로 저장 한 비용 만 지불합니다. 저장 한 금액에 따라 요금이 증가 및 축소됩니다 ( "탄력적"). 파일을 삭제하면 1 시간 이내에 파일이 차지한 공간에 대한 비용 지불이 중지됩니다. 1GB를 750 시간 (≅1 개월) 동안 저장 한 다음 삭제하거나 2 시간 동안 375GB를 저장 한 다음 삭제하면 월별 청구액은 $ 0.30이됩니다. 이것은 물론 EBS와는 상당히 다릅니다. 375GB를 저장하면 $ 37.50의 비용이 청구됩니다.0x00 달 남은 시간 동안 .
S3의 스토리지 가격 모델은 객체를 삭제하자마자 스토리지에 대한 청구가 중단되고 비용은 EFS 비용의 ~ 1 / 10이지만, 나와 다른 사람들이 여러 번 언급 한 것처럼 S3는 파일 시스템. s3fs-fuse와 같은 유틸리티는 "임피던스 브리지 (impedance bridge)"를 제공하려고 시도하지만 실제로는 파일 시스템이 아닌 것을 처리하려고 시도하는 데 고유 한 어려움이 있습니다 (덮어 쓰기에 대한 최종 일관성은 최소가 아닙니다). 따라서 실제 "파일 시스템"이 필요한데 액세스가 공유되어야하거나 필요한 저장 공간이 필요한 애플리케이션을 결정하기 어렵거나 필요에 따라 확장하려는 경우 EFS가 유용 할 수 있습니다.
여유 공간이 8.0 EiB 인 경우에는 멋지게 보입니다.
$ df -h | egrep '^Filesystem|efs'
Filesystem Size Used Avail Use% Mounted on
us-west-2a.fs-5ca1ab1e.efs.us-west-2.amazonaws.com:/ 8.0E 121G 8.0E 1% /srv/efs/fs-5ca1ab1e
us-west-2a.fs-acce55ed.efs.us-west-2.amazonaws.com:/ 8.0E 7.2G 8.0E 1% /srv/efs/fs-acce55ed
물론 응용 프로그램에 가장 적합한 저장소 서비스를 사용하는 것이 중요합니다. 각 옵션에는 유효한 사용 사례가 있습니다. EFS는 아마도 AWS에서 제공하는 가장 전문화 된 스토리지 솔루션으로, EBS 또는 S3보다 사용 사례가 더 좁습니다.
그러나 VPC 외부에서 사용할 수 있습니까?
공식 답변은 아니요 .
VPN 연결, VPC 피어링 및 AWS Direct Connect와 같은 VPC 프라이빗 연결 메커니즘을 통한 파일 시스템 마운트는 지원되지 않습니다.
— http://docs.aws.amazon.com/efs/latest/ug/limits.html
EFS는 현재 EC2 Linux 액세스로만 제한되어 있습니다. VPC 내에서도 마찬가지입니다. 더 많은 기능이 곧 추가 될 것입니다. 출시 된 새로운 기능에 대한 AWS 발표를 주시 할 수 있습니다.
— https://forums.aws.amazon.com/thread.jspa?messageID=732749
그러나 실제적인 대답은 '예'입니다 공식적으로 지원되는 구성은 아니지만 입니다. 작동하려면 몇 가지 특별한 단계가 필요합니다.
각 EFS 파일 시스템에는 일반적으로 가용 영역 당 하나씩 탄력적 네트워크 인터페이스 (ENI)를 사용하여 VPC에 엔드 포인트 IP 주소가 할당되며 성능상의 이유로뿐만 아니라 인스턴스와 일치하는 가용 영역에 하나를 설치해야합니다. 또한 가용 영역 경계를 통해 데이터를 전송할 때 대역폭 요금이 적용되기 때문입니다.
이러한 ENI의 흥미로운 점은 이들이 연결된 서브넷에 라우팅 테이블을 사용하지 않는 것입니다. 보안 그룹 설정에 관계없이 VPC 내부의 인스턴스에만 응답 할 수있는 것 같습니다 (각 EFS 파일 시스템에는 액세스를 제어하는 자체 보안 그룹이 있습니다).
외부 경로에 액세스 할 수 없으므로 하드웨어 VPN을 통해 EFS 엔드 포인트에 직접 액세스 할 수 없습니다. 따라서 이전 pal HAProxy로 전환했습니다. 실제로 @Tim이 예상 한대로이 작업을 수행해야합니다. EFS는 TCP 포트 2049 만 사용하므로 간단한 구성입니다.
t2.nano (HAProxy는 매우 효율적 임)에서 다음과 같은 구성으로 HAProxy를 사용하고 있습니다.
listen fs-8d06f00d-us-east-1
bind :2049
mode tcp
option tcplog
timeout tunnel 300000
server fs-8d06f00d-us-east-1b us-east-1b.fs-8d06f00d.efs.us-east-1.amazonaws.com:2049 check inter 60000 fastinter 15000 downinter 5000
server fs-8d06f00d-us-east-1c us-east-1c.fs-8d06f00d.efs.us-east-1.amazonaws.com:2049 check inter 60000 fastinter 15000 downinter 5000 backup
server fs-8d06f00d-us-east-1d us-east-1d.fs-8d06f00d.efs.us-east-1.amazonaws.com:2049 check inter 60000 fastinter 15000 downinter 5000 backup
이 서버는 us-east-1b에 있으므로 us-east-1b 엔드 포인트를 기본으로 사용하고 다른 하나는 1b의 엔드 포인트가 상태 확인에 실패한 경우 백업으로 사용합니다.
당신이 당신의 VPC에 VPN이있는 경우 다음 대상으로이 프록시 인스턴스의 IP 주소를 사용 (대신 EFS 직접 엔드 포인트 사용) 볼륨을 마운트하고 짜잔 당신이 장착 한 EFS는 VPC 외부에서 특정 파일 시스템.
필자는 외부 Ubuntu 시스템과 Solaris¹ 서버에 성공적으로 마운트했습니다 (EFS는 서비스를 서버에서 멀리 마이그레이션하는 것이 더 쉬워서 서비스 해제를 촉진하는 데 매우 유용함).
마이그레이션 중에 데이터를 AWS로 옮기거나 특정 데이터에 대해 레거시 및 클라우드 시스템을 병렬로 실행하는 것과 같은 특정 상황에서는 EFS가 승자처럼 보입니다.
물론, 왕복 시간이 더 높은 레거시 시스템은 EC2 인스턴스만큼 성능이 좋지는 않지만 물리적 법칙에는 예외가 없습니다. 그럼에도 불구하고 EFS와 HAProxy 게이트웨이는 외부에서 작동하도록하는 안정적인 솔루션 인 것 같습니다.
VPN이없는 경우 AWS와 데이터 센터에있는 HAProxy 머신 쌍이 TLS를 통해 EFS를 터널링하여 각 개별 EFS의 전송을 위해 TLS에 싸인 페이로드와 개별 TCP 연결을 설정할 수 있습니다. 인터넷을 통한 연결. 기술적으로는 VPN이 아니라 암호화 된 연결 터널링입니다. 이것은 또한 잘 수행하는 것 같습니다.
루트 특별한 권한을 가지고있는 것으로 나타났습니다 처음 - - 루트가 소유 루트에 의해 생성 된 EFS 볼륨에서 파일을하지만, 할 수없는 ¹Solaris (10)은 다소 기본적으로 고장 (당연한)입니다 chown으로부터 다른 사용자에게 에드 Operation not permitted모든 것이 Ubuntu 클라이언트에서 예상대로 작동하더라도 Solaris 시스템 ( ). 이 경우 해결책은을 사용하여 Solaris 시스템에서 NFS ID 매핑 데몬을 물리 치는 것입니다 svcadm disable svc:/network/nfs/mapid:default. 이 서비스를 중지하면 모든 것이 예상대로 작동합니다. 또한 /usr/sbin/quota각 로그인에 대한 호출을 에서 비활성화해야합니다 /etc/profile. 더 나은 또는 더 정확한 솔루션이있을 수 있지만 Solaris이므로 조사하기에 충분히 궁금하지 않습니다.