View 파일 시스템 오버로드 스킴 가이드
View 파일 시스템 오버로드 스킴 가이드 (View File System Overload Scheme Guide)
View File System(ViewFS)의 두 가지 핵심 문제를 해결하는 ViewFileSystemOverloadScheme을 설명하는 문서예요. 기존 fs.defaultFS 스킴을 계속 쓰면서 여러 파일 시스템을 마운트하고, 마운트 테이블을 중앙에 두어 관리합니다.
출처: 문서
본문
소개 (Introduction)
View File System Overload Scheme은 View File System(ViewFS)의 두 가지 핵심 문제를 해결하기 위해 도입됐습니다. 첫 번째 문제는 ViewFS를 쓰려면 사용자가 fs.defaultFS를 viewfs 스킴(viewfs://)으로 갱신해야 한다는 것입니다. 두 번째 문제는 사용자가 마운트 테이블 구성을 모든 클라이언트 노드에 복사해야 한다는 것입니다. ViewFileSystemOverloadScheme은 이 문제들을 해결합니다.
View 파일 시스템 오버로드 스킴 (View File System Overload Scheme)
세부 사항 (Details)
View File System Overload Scheme은 View File System의 확장입니다. 이를 통해 사용자는 viewfs 스킴 대신 기존 fs.defaultFS 구성 스킴이나 새 스킴 이름을 계속 사용할 수 있어요. 마운트 링크 구성 키, 값 형식은 ViewFS Guide와 같습니다. 사용자가 같은 fs.defaultFS를 계속 쓰면서 더 많은 마운트 지점을 갖고 싶다면, 마운트 링크 구성이 ViewFileSystemOverloadScheme 초기화 URI의 호스트명을 마운트 테이블 이름으로 가져야 합니다. 예를 들어 fs.defaultFS가 hdfs://mycluster이면 마운트 링크 구성 키 이름은 fs.viewfs.mounttable.*mycluster*.link.<mountLinkPath> 형식이어야 해요. 초기화 fs URI에 hostname:port가 있어도 포트 번호는 무시하고 호스트명만 마운트 테이블 이름으로 간주합니다. 다음 절에서 더 많은 예시 구성을 논의할게요. 초기화 URI의 호스트명을 마운트 테이블 이름으로 한 마운트 링크가 구성되지 않았으면, 현재 URI를 폴백(fs.viewfs.mounttable.*mycluster*.linkFallback) 대상 fs URI로 자동 간주합니다. 초기화 URI가 경로 부분을 포함하면 스킴과 authority 부분만 고려하고 경로 부분은 고려하지 않아요. 예를 들어 초기화 URI가 hdfs://mycluster/data면 폴백 대상 fs URI로 hdfs://mycluster만 고려하고 경로 부분 data는 무시됩니다.
ViewFileSystemOverloadScheme의 또 다른 중요한 개선은 관리자가 mount-table.xml 구성 파일을 수천 개의 클라이언트 노드에 복사할 필요가 없다는 것입니다. 대신 Hadoop 호환 파일 시스템에 마운트 테이블 구성 파일을 둘 수 있어요. 구성 파일을 중앙에 두면 관리자가 마운트 테이블을 한 곳에서만 갱신하면 되어 더 쉬워집니다.
View File System Overload Scheme 활성화
이 클래스를 사용하려면 core-site.xml 파일에 다음 구성이 추가돼야 합니다.
<property>
<name>fs.<scheme>.impl</name>
<value>org.apache.hadoop.fs.viewfs.ViewFileSystemOverloadScheme</value>
</property>
여기서 <scheme>은 fs.defautFS에 구성된 uri-scheme과 같아야 합니다. 예를 들어 fs.defaultFS가 hdfs://mycluster로 구성됐다면 위 구성은 아래와 같을 거예요.
<property>
<name>fs.hdfs.impl</name>
<value>org.apache.hadoop.fs.viewfs.ViewFileSystemOverloadScheme</value>
</property>
예시 구성 (Example Configurations)
예시 1:
기존 클러스터(hdfs://cluster) 데이터 일부와 다른 객체 스토어 클러스터(o3fs://bucket1.volume1.omhost/, s3a://bucket1/)를 hdfs(hdfs://cluster)로 마운트하고 싶다면, 다음 예시 구성으로 마운트 링크를 추가하는 방법을 보여줍니다.
<property>
<name>fs.viewfs.mounttable.cluster.link./user</name>
<value>hdfs://cluster/user</value>
</property>
<property>
<name>fs.viewfs.mounttable.cluster.link./data</name>
<value>o3fs://bucket1.volume1/data</value>
</property>
<property>
<name>fs.viewfs.mounttable.cluster.link./backup</name>
<value>s3a://bucket1/backup/</value>
</property>
마운트 링크에 따라 이 연산들이 어디로 위임되는지 이해하기 위해 다음 연산을 생각해 봅시다.
Op1: hdfs://cluster/user/fileA 경로로 파일을 만들면 물리적으로 hdfs://cluster/user/fileA에 생성됩니다. 이 위임은 위 구성의 첫 구성 파라미터에 기반합니다. 여기서 /user는 hdfs://cluster/user/에 매핑됩니다.
Op2: hdfs://cluster/data/datafile 경로로 파일을 만들면 o3fs://bucket1.volume1.omhost/data/datafile에 생성됩니다. 이 위임은 위 구성의 두 번째 파라미터에 기반합니다. 여기서 /data는 o3fs://bucket1.volume1.omhost/data/에 매핑됩니다.
Op3: hdfs://cluster/backup/data.zip 경로로 파일을 만들면 물리적으로 s3a://bucket1/backup/data.zip에 생성됩니다. 이 위임은 위 구성의 세 번째 파라미터에 기반합니다. 여기서 /backup은 s3a://bucket1/backup/에 매핑됩니다.
예시 2:
기존 클러스터(s3a://bucketA/) 데이터 일부와 다른 hdfs 클러스터(hdfs://cluster), 객체 스토어 클러스터(o3fs://bucket1.volume1.omhost/, s3a://bucketA/)를 마운트하고 싶다면, 다음 예시 구성으로 마운트 링크를 추가하는 방법을 보여줍니다.
<property>
<name>fs.viewfs.mounttable.bucketA.link./user</name>
<value>hdfs://cluster/user</value>
</property>
<property>
<name>fs.viewfs.mounttable.bucketA.link./data</name>
<value>o3fs://bucket1.volume1.omhost/data</value>
</property>
<property>
<name>fs.viewfs.mounttable.bucketA.link./salesDB</name>
<value>s3a://bucketA/salesDB/</value>
</property>
마운트 링크에 따라 이 연산들이 어디로 위임되는지 이해하기 위해 다음 연산을 생각해 봅시다.
Op1: s3a://bucketA/user/fileA 경로로 파일을 만들면 물리적으로 hdfs://cluster/user/fileA에 생성됩니다. 이 위임은 첫 구성 파라미터에 기반합니다. 여기서 /user는 hdfs://cluster/user에 매핑됩니다.
Op2: s3a://bucketA/data/datafile 경로로 파일을 만들면 o3fs://bucket1.volume1.omhost/data/datafile에 생성됩니다. 이 위임은 두 번째 구성 파라미터에 기반합니다. 여기서 /data는 o3fs://bucket1.volume1.omhost/data/에 매핑됩니다.
Op3: s3a://bucketA/salesDB/dbfile 경로로 파일을 만들면 물리적으로 s3a://bucketA/salesDB/dbfile에 생성됩니다. 이 위임은 세 번째 구성 파라미터에 기반합니다. 여기서 /salesDB는 s3a://bucket1/salesDB에 매핑됩니다.
참고: 위 예시에서는 create 연산만 사용했지만, 같은 메커니즘이 여기서 다른 모든 파일 시스템 API에도 적용됩니다.
ViewFileSystemOverloadScheme에서 ViewFileSystem과 비교해 서로 다른 스킴을 어떻게 사용할 수 있는지는 다음 그림이 보여줍니다.
참고: ViewFsOverloadScheme에서 기본적으로 마운트 링크는 심볼릭 링크로 표현되지 않습니다. 권한 비트와 isDirectory 값은 대상 디렉터리/파일에서 전파됩니다.
중앙 마운트 테이블 구성 (Central Mount Table Configurations)
중앙 마운트 테이블 구성을 활성화하려면 core-site.xml의 fs.viewfs.mounttable.path를 Hadoop 호환 파일 시스템 디렉터리/파일 경로 값으로 구성해야 합니다. mount-table.<versionNumber>.xml 파일이 복사되는 곳입니다. 여기서 versionNumber는 정수이며, 버전 번호를 올리고 같은 디렉터리에 새 파일을 업로드해야 해요.
ViewFileSystemOverloadScheme은 항상 가장 높은 버전 번호의 mount-table.<versionNumber>.xml을 로드합니다. 같은 이름으로 파일을 교체하지 마세요. 항상 버전 번호를 올려 새로 초기화하는 클라이언트가 새 파일을 가져가게 하세요. 파일 교체를 권장하지 않는 이유는 일부 클라이언트가 이미 옛 mount-table 파일에 연결을 열고 구성 파일을 로드하는 중일 수 있고, 파일 교체가 그들을 실패하게 만들 수 있기 때문이에요.
<property>
<name>fs.viewfs.mounttable.path</name>
<value>hdfs://cluster/config/mount-table-dir</value>
</property>
mount-table 파일을 절대 갱신하지 않을 것이라고 확신한다면, 아래처럼 파일 경로를 직접 구성할 수도 있습니다. 파일 경로를 구성하면 최고 버전 번호 로딩을 확인하지 않습니다. 구성된 그 파일이 로드됩니다. 다만 파일 이름 형식은 같아야 해요.
<property>
<name>fs.viewfs.mounttable.path</name>
<value>hdfs://cluster/config/mount-table-dir/mount-table.<versionNumber>.xml</value>
</property>
참고: 위의 유효한 경로를 구성하면 core-site.xml에는 마운트 링크를 구성하지 않는 것을 권장합니다. 그렇지 않으면 두 마운트 링크가 섞여 혼란스러운 동작을 초래할 수 있어요.
mount-table.<versionNumber>.xml을 복사할 때는 클러스터 크기에 따라 큰 복제 팩터를 고려할 수 있습니다. 그러면 애플리케이션(MR/YARN/HBASE 등)이 mount-table.<versionNumber>.xml을 읽을 때 HDFS 로컬리티를 사용하므로 대부분의 클라이언트에 파일이 로컬로 제공됩니다.
View File System Overload Scheme과 DFSAdmin 명령
HDFSCommands Guide를 참고하세요.
authority 없는 경로 접근 (Accessing paths without authority)
hdfs:///foo/bar, hdfs:/foo/bar 또는 viewfs:/foo/bar처럼 경로의 authority(클러스터 이름이나 호스트명)가 지정되지 않은 경로에 접근하는 것은 매우 흔합니다. 특히 같은 코드가 이름이나 HDFS Namenode가 다른 여러 클러스터에서 실행될 것으로 예상될 때 그렇죠.
ViewFileSystemOverloadScheme을 사용할 때(위에서 설명한 대로), (a) 접근하는 경로의 스킴이 fs.defaultFS로 지정된 경로의 스킴과 다르고 (b) 경로에 authority가 지정되지 않았다면, 접근 시 Empty Mount table in config for viewfs://default/ 같은 오류가 발생할 수 있습니다. 예를 들어 다음 구성을 사용하는데 viewfs:/foo/bar나 viewfs:///foo/bar 같은 경로에 접근하면 이런 오류가 생겨요.
<property>
<name>fs.hdfs.impl</name>
<value>org.apache.hadoop.fs.viewfs.ViewFileSystemOverloadScheme</value>
</property>
<property>
<name>fs.defaultFS</name>
<value>hdfs://cluster/</value>
</property>
해결책 (Solution)
위 문제를 피하려면 fs.viewfs.mounttable.default.name.key 구성을 클러스터 이름으로 설정해야 합니다. 즉 core-site.xml에 다음을 추가해야 해요.
<property>
<name>fs.viewfs.mounttable.default.name.key</name>
<value>cluster</value>
</property>
이 구성의 문자열 cluster는 fs.defaultFS 값의 authority 이름과 일치해야 합니다. 또한 위 예시처럼 마운트 테이블이 올바르게 구성돼야 합니다. 즉 fs.viewfs.mounttable.*cluster*.link.<mountLinkPath> 구성이 설정돼야 합니다(이 구성들에 같은 문자열 cluster가 사용되는 점에 주의).
부록: XInclude를 사용한 마운트 테이블 구성 (Appendix)
신뢰할 수 있는 네트워크에 HTTP 서버가 있고 인증 메커니즘이 필요 없다면, 그 서버에 mount-table.xml 파일을 두고 mount-table.xml 파일로 XInclude xml 태그를 구성할 수 있습니다.
<configuration xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include href="http://myserver/mountTable/mountTable.xml" />
</configuration>
Apache Hadoop 구성은 XInclude에서 http url을 읽어 구성에 로드하는 기능이 있습니다. 이 옵션을 선택한다면 core-site.xml이나 fs.viewfs.mounttable.path에는 마운트 테이블 구성 항목을 구성하지 마세요. Hadoop 구성 XInclude는 url을 열 때 SPNego 인증을 사용하지 않습니다. 따라서 mount-table.xml을 둔 http 서버가 인증이 필요하면 이것은 동작하지 않아요.
더 알아보기 (Learn more)
- 원문: 문서