SDN은 무엇인가? 그리고 왜 대두되었는가?

Posted by MD워시퍼
2013. 6. 26. 22:06 Study/Cloud
728x90

수년 동안 컴퓨터 과학자들은 네트워크의 속도와 안정성, 에너지 효율, 보안 등을 획기적으로 개선시킬 수 있는 방법을 꿈꿔왔다. 그러나 그 방법을 설계하거나 고안하더라도, 실제로 대규모(large-scale)로 실험하거나 검증하는 것은 불가능했다. 인터넷의 코어(core)를 구성하는 라우터나 스위치들이 이른바 완전히 닫혀 있어서 그 위에서 새로운 소프트웨어나 프로그램을 실험하는 것이 원천적으로 봉쇄되었기 때문이다.


이러한 연유로 연구되어온 많은 기술 중 SDN은 Software Defined Networking을 의미하며 우리말로 소프트웨어 정의 네트워킹이라 부른다. SDN은 OpenFlow라는 기술 혹은 소프트웨어를 통하여 널리 알려졌다. OpenFlow와 SDN은 뗄레야 뗄 수 없는 관계이다. SDN이 물론 더 큰 개념으로 네트워크 구조 혹은 새로운 패러다임이며, OpenFlow는 SDN을 위한 “인터페이스 표준 기술”로 정의된다. SDN을 지원하는 기술 중에서 학교, 연구소, 기업 등으로부터 가장 관심을 받는  OpenFlow는 별도로 설명하기로 하고 (이미 많은 참고자료가 나와 있기도 하다),여기서는 먼저 SDN이 무엇인지, 그리고 왜 필요성이 부각되었는지에 대하여 몇 가지 레퍼런스를 바탕으로 다루어 보려 한다.


먼저 위키피디어의 정의를 살펴보자. Kate Greene이 2009년도3/4월 판 MIT 테크니컬 리뷰에서 소개한 용어로 알려져 있는 SDN은 네트워크 제어 기능(control plane)이 물리적 네트워크와 분리되어 있는 “네트워크 구조”를 말한다. 위키피디어에 따르면  SDN을 특징짓는 두 가지 중요한 포인트는 다음과 같다. 첫째, 네트워크 제어 기능을 데이터 전달 기능(data plane)과 분리하여 구현해야 한다. 둘째, 네트워크 제어 기능이 개발되고 실행될 수 있는 환경을 분리하여 전형적인 낮은 성능의 CPU가 장착된 하드웨어 스위치에 더 이상 위치시키지 않는다. 다시 말해서 SDN이라면 기본적으로 네트워크 제어 기능이 기존의 스위치나 라우터 등의 하드웨어와 별도로 분리되어야 하고, 데이터 전달 기능과도 역시 분리되어 개발 및 실행될 수 있는 네트워크 구조를 가져야 한다.


분리된 SDN의 제어 기능은 필연적으로 네트워크 스위치(하드웨어) 상의 데이터 경로와 상호작용할 수 있는 기능을 가져야만 한다. 이러한 상호작용 혹은 통신 메커니즘 중의 하나가 바로OpenFlow 기술이다. OpenFlow는 흔히 SDN과 동일한 것으로 혼동되기도 하지만, 사실 SDN을 구성하는 하나의 요소로 제어 기능을 가진 머쉰과 네트워킹 스위치간의 통신을 담당하는 표준 인터페이스이다. 그리고, SDN의 범주 안에서 OpenFlow를 반드시 사용해야 한다는 아무런 제약이나 요구사항도 없다. 현재 SDN과 OpenFlow의 정의, 마켓팅 등의 이슈는 개방형 네트워킹 재단(Open Networking Foundation; ONF)에서 관리되고 있다. 


그렇다면 ONF에서는 SDN을 어떻게 바라보고 있을까? 일단 ONF가 무엇인지부터 살펴보자. ONF는 (미연방세법을 따르며) 비영리, 상호 이익을 바탕으로 하는 국제 기구로 SDN의 개발과 활용을 촉진하는 것을 목표로 삼고 있다. ONF의 이사회는 여덟 명의 멤버로 구성되는데 여섯 개의 설립 회사가 각각 한 명씩 지정한 여섯 명의 이사와 두 명의 창립자이다. 여섯 개의 설립 회사는 대규모 네트워크 운영자 및 (잠재) 사용자 그룹을 대표하는 도이치 텔레콤(Deutsche Telecom), 페이스북(Facebook), 구글(Google), 마이크로소프트(Microsoft), 버라이즌(Verizon)과 야후(Yahoo)이며, 두 명의 창립자는 UC 버클리의 Scott Shenker와 스탠포드 대학의 Nick Mckeown이다. 그리고 이외에 사무총장(Executive Director) Dan Pitt이 ONF를 총괄 관리한다.


ONF가 SDN을 바라보는 관점은 크게 두 가지의 기본적인 원칙을 바탕으로 하고 있다.


먼저 SDN은 소프트웨어 정의 포워딩(Software Defined Forwarding)을 해야 한다. 이것은 스위치와 같은 하드웨어가 수행하는 데이터 포워딩 기능이 반드시 개방형 인터페이스와 소프트웨어를 통해서 제어되어야만 한다는 것을 의미한다. 하드웨어는 소프트웨어로부터 [헤더 템플릿, 포워딩 액션] 셋을 받아 특정한 액션(action)을 실행한다. 예를 들면 어떤 네트워크 포트로 패킷을 “전달(forwarding)”하거나 혹은 “폐기(drop)”할 수 있다. 다만 해당 특정 액션은 [헤더 템플릿, 포워딩 액션]의 “헤더 템플릿”에 상응하는 패킷에 대해서만 실행된다. 여기서 헤더 템플릿은 “모든 패킷” 혹은 “어떤 패킷의 그룹”등을 의미하는 와일드 카드를 포함할 수 도 있다. 앞서 언급되었듯이 SDN의 소프트웨어 정의 포워딩은 반드시 개방형 인터페이스와 소프트웨어를 포함하는데, OpenFlow 기술이 “개방형 인터페이스”에 해당된다.


그리고, 두 번째 원칙은 SDN이 추상화된 글로벌 관리 혹은 글로벌 관리 추상화(Global Management Abstraction)를 목표로 한다는 것이다. SDN은 기본적인 글로벌 관리 추상화를 지원함으로서 보다 선도적인 네트워크 관리 툴이 개발될 수 있도록 해야 한다. 예를 들면 이런 추상화 도구들은 네트워크의 글로벌 뷰, 네트워크 이벤트(토폴로지 변화나 새로운 플로우 생성 등)에 따른 반응, 그리고 네트워크 요소를 제어할 수 있는 기능 등을 포함할 수 있다. (네트워크 요소 제어는 해당 엔트리를 하드웨어의 포워딩 테이블에 넣는 방법을 사용한다.)


따라서, ONF 가 바라보는 SDN은 두 가지, 즉,  소프트웨어 정의 포워딩과 글로벌 관리 추상화가 핵심이다. 그리고, 이를 위해서 개방형 인터페이스(예: OpenFlow), 제어 소프트웨어, 글로벌 네트워크 관리 툴 등의 세부적인 기능이 언급되었다.


여기서 잠시 위키피디어로 돌아가보자. 위키피디어에서 언급한 Kate Greene (과학기술 저널리스트)이 작성한 테크니컬 리뷰의 내용을 보면 SDN이 무엇인지 개괄적으로 잘 정리되어 있다. 이 기사에 따르면 ONF의 창립자 중 하나이자 이사회 멤버이며, OpenFlow 기술과 표준을 개발한 Nick McKeown이 다음과 같이 말한다. “오늘날 보안, 라우팅, 에너지 효율 관리 등은 단지 기계덩어리인 네트워크 장비에 의해 좌지우지됩니다. 그건 정말 바꾸기 힘들지요. 이것이 바로 인터넷 인프라가 40년 동안이나 변하지 않은 이유입니다.” 일반적으로 데이터 패킷이 스위치 (혹은 라우터)에 도착하면 스위치의 펌웨어가 해당 패킷의 목적지 주소를 보고 그 패킷을 이미 정해진 규칙에 따라 포워딩(forwarding)한다. 정해진 규칙은 네트워크 운영자도 제어하기 어렵다. 같은 목적지를 갖는 모든 패킷은 같은 경로를 이용하고 언제나 같은 방식으로 다루어진다. 이것이 현대 인터넷의 일반적인 패킷 포워딩 방식이다.


SDN은 무엇인가? 라는 질문의 답은 바로 현재 인터넷이 가지고 있는 “항상 같은 방식이며 제어가 어려운” 패킷 포워딩 방식을 바꾸는 것으로 부터 시작한다. OpenFlow의 예를 들면, 그 전에는 거의 아무도 손대기 어려웠던 종단간 네트워크 경로를 컴퓨터 과학자들이 쉽게 변경할 수 있도록 지원하여 e-mail보다 비디오 어플리케이션이 우선 데이터를 받을 수 있도록 하거나 다양한 트래픽을 각자 다른 경로로 보낼 수도 있고, 어떤 트래픽은 보안 목적으로 격리할 수 있도록 해준다.


그렇다면 패킷 포워딩 방식을 바꾸는 것이 바로 SDN인가? 그렇지 않다. 이것은 SDN이라는 큰 구조를 구성하는 하나의 요소일 뿐이다. OpenFlow가 바로 패킷 포워딩 방식을 표준화된 방법으로 바꿀 수 있는 하나의 콤포넌트이다. SDN은 아키텍쳐 혹은 프레임을 제공하는 큰 개념이자 구조 혹은 패러다임으로, 하드웨어와 어플리케이션, 하드웨어 추상화 계층, 하드웨어와 분리된 제어 기능(control plane, controller 등으로 불리운다.), 하드웨어 추상화 계층과 통신하는 표준 기능 등을 모두 포함한다.


SDN 구조에서, 하드웨어는 스위치나 라우터 등이며, 시스코, 쥬니퍼, HP, NEC 등이 개발하고 현재 인터넷 공급자들이 서비스를 제공하기 위하여 설치하고 운영하는 하드웨어 박스(box)를 의미한다. Nick이 말했듯이 오늘날의 인터넷이 거의 변화하지 못한 가장 큰 원인을 제공하는 주범들이다. SDN은 이 기계덩어리에 하드웨어 추상화를 위한 계층을 더해준다. 즉, OpenFlow와 같이 표준화된 인터페이스를 통하여 하드웨어에 접근하고, 소프트웨어에 기반하여 하드웨어를 “통제”할 수 있는 기반을 제공하는 것이다. 이 추상화 계층은 OpenFlow의 플로우 테이블과 같은 형태로 하드웨어에 구현되어야 한다. 따라서 하드웨어 벤더들의 지원과 협력이 필수적이다. (현재 약 16개의 주요 네트워크 벤더들이 구현했거나 구현중이다. SDN을 지향하는 OpenFlow가 가장 선두에서 탄력받는 기술로 주목받고 있는 배경이기도 하다.) 추상화 계층을 구현함에 있어서 가장 중요한 것은 표준화된 인터페이스를 지원하는 것이고, 두 번째는 각 개별 벤더가 원하는 “독립성”을 보장해 주는 것이다. 개별 벤더의 고유 기술이나 고유 기능은 자치적으로 보장되면서 SDN을 위한 표준화된 통로를 제공하는 것은 벤더 고유의 기술을 보호하면서도 호환성을 유지하는데 있어서 필수적이며, OpenFlow의 경우 이를 매우 잘 준수하고 있다.


다음으로 무엇보다 중요한 요소는 바로 하드웨어와 분리된 제어 기능이다. Controller로 불리기도 하는 이 제어 기능은 스위치나 라우터가 아닌 별도의 머쉰 상에서 구현된다. 머쉰은 PC가 될 수도 있고 성능 좋은 서버가 될 수도 있다. 이 제어 기능은 두 가지 SDN의 다른 두 가지 콤포넌트와 상호작용한다. 한 가지가 어플리케이션이고 다른 한 가지는 하드웨어, 좀 더 정확히는 하드웨어에 구현된 추상화 계층이다. 따라서 제어 기능을 통해서 어플리케이션은 네트워크의 다양한 정보를 얻을 수 있고, 반대로 네트워크 역시 어플리케이션 요구 사항 등의 정보를 얻을 수 있다. 이러한 핵심적인 역할 때문에, 제어 기능은 종종 네트워크 운영 체제(Network OS)라고 불리우기도 한다.


제어 기능은 주로 API와 같은 방법을 통해서 어플리케이션이 원하는 기능을 제공한다. 반대의 경우도 거의 같다. 어플리케이션과 제어 기능 간의 통로인 셈이다. 그렇다면 제어 기능과 하드웨어 추상화 계층의 통신은 어떻게 이루어질까? OpenFlow가 이 질문에 대한 해답이며, 이미 많은 연구가 진행되어 있다.


지금까지 위키피디어, ONF, 테크니컬 리뷰 등을 인용하고 몇 가지 살을 붙여 SDN이 무엇인지 정리해 보았다. SDN은 새로운 네트워크 구조이며 패러다임이다. 그럼 이제부터 SDN이 왜 대두되었는지 알아보기로 하자.


가장 최근에 ONF가 개최한 컨퍼런스인 Open Networking Summit(2011년 10월)에서 ONF의 또 다른 창립자인 Scott Shenker가 발표한 내용을 보면, 인터넷이 이렇게 크게 성공한 가장 큰 이유가 바로 “계층화(layering)”에 있다는 것을 알 수 있다. 어플리케이션(WWW, e-mail 등)은 신뢰성/비신뢰성 트랜스포트 계층(TCP/UDP)위에서 돌아가고, 트랜스포트 계층은 최선형 글로벌 패킷 전달 계층(IP)위에서 동작되며, IP는 최선형 로컬 패킷 전달 계층(Ethernet, PPP등)위에서, 다시 로컬 패킷 전달 계층은 물리 계층(copper, fiber, radio등) 위에서 돌아가는 것이 바로 계층화이다. 즉, 서로 다른 계층이 독립적으로 동작하되 상/하위 계층과 상호 호환되는 방식으로 일종의 혁신을 이룬 것이다. 덕분에 인터넷은 교육/연구망으로 시작되었으나, 상업적으로도 엄청난 성공을 거두었고 지금까지 가장 널리 사용되고 있다. 그러나, 초창기 개발된 인터넷 구조나 모델이 아직도 거의 그대로 사용되고 있는 형편으로, 상업적인 성공이 또 다른 인터넷의 혁신으로 이어지지 못했다. 왜 그럴까?


이 질문에 답하기 전에 먼저 다른 분야를 한 번 살펴보자. 예를 들어 컴퓨터 운영체제(OS), 데이터베이스(DB), 분산 시스템 등은 소프트웨어의 연구 개발을 통해 발전해 왔다. 학교에서 배우는 기본적 원리들을 바탕으로 소프트웨어를 개발하고 진화시킨 것이다. 이러한 소프트웨어는 우리가 흔히 알고 있는 고급 프로그래밍 언어로 작성할 수 있으며, 새로운 기능이 필요한 경우 기존에 개발된 소프트웨어를 바탕으로 새로운 버젼으로 계속해서 발전할 수 있다. LINUX, Windows, Mac OS 등이 이런 방식으로 진화해온 대표적인 OS 이다. 데이터베이스나 분산 시스템도 마찬가지이다. 그리고 이러한 소프트웨어 기반의 시스템들은 대부분 편리하고 쉬운 유저 인터페이스를 통해 쉽게 관리 가능한 환경을 가지고 있다.


그렇다면 네트워크는 어떤가? 일단 학교에서 OSI 7 계층 부터 시작하여 TCP, IP 등등의 여러 프로토콜에 대해서 배운다. 이들의 기본적 원리나 알고리즘에 대해서도 배우지만 대부분 동작 원리 등 실용적인 부분에 집중된다. 물론 이른바 단말 시스템(end-system)에서 돌아가는TCP 등의 일부 프로토콜은 기능이 향상된 버젼이 개발되었거나 개발이 진행 중이다. 하지만,단말과 단말 사이에서 데이터 전송과 전달을 담당하는 액세스/코어 네트워크의 프로토콜이나 기타 기능들은 이미 대부분 개발이 끝나서 적용 및 서비스 되고 있는 단계이기 때문에 새롭게 수정하거나 개발하기 어렵다. 물론 네트워크 벤더의 경우 추가적인 기술 개발과 적용이 가능하지만 DB나 운영체제 등과 비교할 때 많은 진보가 일어나지는 않았다. 네트워크 분야의 경우, 소프트웨어와 프로그래밍을 바탕으로 한 새로운 기술의 개발과 진화가 다른 컴퓨터 과학 분야와 비교할 때 그 발전이 더디게 진행되어 온 것은 분명한 사실이다. 네트워크 관리 환경은 어떠한가? 일부 운영자나 엔지니어에게 종속되어 있는데다가 그 마저도 사용하기가 쉽지 않다. 전문적인 지식이나 기술을 요구하는 경우도 많다. 최근 몇 몇 연구들이 이러한 관리 환경을 개선하는데 그 촛점을 맞추고 있긴 하지만 다른 분야에 비해서 부족한 상태로, 매우 불편한 사용자 인터페이스를 가지고 있다.


“구조는 단순하지만 관리가 복잡하고 인터페이스는 어렵다.” 이것이 현재의 인터넷이 가지고 있는 가장 큰 문제로 귀결된다. SDN이 대두된 이유는 바로 이 화두를 타파하기 위해서이다.


단순한 구조는 물론 장점이다. 덕분에 인터넷이 오늘날의 압도적 지위를 누리게 되었다. 하지만 단순성을 유지하기 위하여 새로운 기술을 적용하거나 소프트웨어를 개발하는 측면에서 다른 분야에 비해 큰 제약을 가져야만 했다. 이와 같은 단점을 보완하기 위하여 SDN은 제어 프레임워크, 혹은 제어 기능을 분리하여 소프트웨어의 개발을 촉진시키고자 한다. 즉, 소프트웨어를 기반으로 인터넷이 보다 빠른 속도로 진화할 수 있도록 하자는 것이다. 그리고, SDN은 관리의 복잡성을 해소하기 위하여 제어 기능을 기존 하드웨어에서 분리시키고, 사용자 인터페이스를 매우 단순하고 편리하게 만듦으로써 엔지니어, 운영자 뿐만 아니라 일반 사용자도 쉽게 네트워크를 관리하고, 가상 네트워크를 생성하여 이용할 수 있도록 한다.


참고로, 미래인터넷 포럼(FIF)의 테스트베드 워킹그룹 이슈 분석서 #2에서 Nick의 발표 내용을 정리한 부분을 보면, SDN이 어떻게 인터넷이 가지고 있는 문제를 해결하고 혁신을 가속화할 수 있는지에 대하여 잘 알 수 있다.



Nick은 SDN을 기반으로 한 새로운 패러다임을 만들어 내어서 아래와 같은 혜택들을 누리는 네트워크 장치 생태계를 만드는 것이 필요하다고 역설한다.

1.     데이터 전달(Forwarding) 추상화에 따라서 OpenFlow 표준에 의해 검증된   하드웨어를 이용하고, 또한 이에 연동하여 소프트웨어 기반으로 제공되는 네트워킹 특성이 요구되는 모든 절차들에 대해서 각각의 절차마다 충분하게 증빙되어 있는 견실한 네트워킹을 실현할 수 있는 토대를 구축할 수 있다.

2.     장비 사용자들이 자신의 필요에 따라 네트워킹을 유연하게 구성(customize)하고 불필요한 구성요소들은 과감하게 제거하면서 자신만을 위해서 가상화된 네트워크를 생성하기 쉽도록 지원한다.

3.     하드웨어 추상화(abstraction)에 따라 확장성을 고려한 상태에서 공통화된(즉commodity 형식으로) 하드웨어를 구입하고, 또한 소프트웨어도 분리해서 구입하도록 하여 기존의 폐쇄적인 네트워크 장비 공급자 체인을 벗어나서 자체 개발, 외주 개발, 오픈 소스 형식을 모두 포함하는 다변화된 공급자 체인으로 체질 개선을 유도할 수 있다.

4.     소프트웨어를 개발하는 속도로 혁신이 일어나도록 하고, 표준은 구현된 소프트웨어의 확산을 위해 뒤따라가는 방식을 취하고, 소프트웨어적인 개방성에 근간하여 기술의 공유 협력을 쉽도록 함으로써 혁신의 속도를 가속하도록 지원한다.


다른 내용도 모두 중요하지만, 특히 4번에 주목하자. 소프트웨어를 개발하는 속도로 혁신이 일어나게 하고 표준은 이를 뒤따르게 하자는 것이야 말로 SDN이 왜 대두되었는지 설명하는 핵심 중의 핵심이라 할 수 있다.


내용이 두서없이 길어진 듯 하다. 이제 정리해보자. SDN은 아직도 정의되고 있는 단계이다. 본문에서 언급한 여러 레퍼런스를 보면 분명히 주된 맥락은 있지만 모호하고 추상적인 부분도 있는 것이 사실이다. 따라서 앞으로 SDN의 모습은 계속해서 변화될 가능성이 틀림없이 존재한다. 그렇지만 주된 맥락을 고려할 때 SDN은 현재 시점에서 다음과 같이 정의될 수 있을 것이라 생각한다. 


"SDN은 이른바 소프트웨어를 통해서 현재의 인터넷이 가지는 구조적 문제를 근본적으로 해결하고 혁신할 수 있도록 대두된 새로운 네트워크 구조 혹은 패러다임으로써, 어플리케이션,네트워크 OS, 하드웨어 추상화, 표준화된 인터페이스 및 하드웨어를 모두 아우르는 개념"이다.


<출처 : http://katesfam.blogspot.kr/>



Hadoop의 정의

Posted by MD워시퍼
2012. 4. 28. 13:56 Study/Cloud
728x90

ㅇ 분산파일시스템 : 네트워크로 연결된 서버들의 스토리지를 관리하는 파일시스템


ㅇ HDFS : Hadoop Distributed File System


ㅇHDFS의 특징

 - 매우 커다란 파일로 보유함

 - Data Access를 스트리밍 방식으로 지원함n

 - 범용 하드웨어 (<-> 고가의 신뢰도 높은 하드웨어)

 - 빠른 응답시간의 Data Access에는 적합하지 않음

 - 많은 수의 작은 파일은 효율적이지 않음

 - 다중 라이터 및 임의의 파일 수정은 적합하지 않음 (쓰기 작업은 항상 파일의 끝에서 이루어짐)


ㅇ HDFS 블록

 - 블록 : 한번에 읽고, 쓸 수 있는 데이터의 최대량

 - 추상적인 개념이기에 생기는 이점 :

① 파일 하나가 네트워크에 있은 어떤 하나의 디스크보다 더 커질 수 있다.

파일 하나를 동일 디스크에 저장할 필요없이, 클러스터 내에 어떠한 디스크에도 저장할 수 있다

② 파일보다는 블록을 사용

  - 스토리지 관리 ( 블록은 고정크기이기 때문에 시스템의 저장용량을 계산하기 쉽다 )

  - 메타데이터 관리 ( 파일권한 정보같은 메타데이터를 저장할 필요가 없으므로, 독립적인 관리 가능)

③ 복제를 효율적으로 수행 가능


ㅇ NameNode & DataNode

  1. NameNode(일을 명령함)

- Manage Namespace for File System

- 파일시스템 트리와 그 트리 안에 있는 모든 파일과 디렉토리의 메타데이터를 유지

- Namespace image와 edit log 형태의 두 개의 파일에 지속적으로 저장함

- 파일과 디렉토리의 open, close, rename 그리고 DataNode와 block의 mapping을 결정

  2. DataNode(일을 수행함)

- Client가 요구하는 Read, Write, 그리고 NameNode의 생성과 삭제, 복제와 같은 명령을 수행한다

- 파일시스템 메타데이터의 지속상태를 보완해주는 파일들을 백업합


ㅇ 기본적인 파일시스템 연산

  - fs : 하둡 파일시스템의 쉘 명령어

  - -copyFromLocal : 로컬시스템에 있는 파일을 hadoop에 올린다

  - - ls : ls -l 과 같은 기능


ㅇ 인터페이스

  1. 쓰리프트

    - 하둡 파일시스템을 아파치 쓰리프트 서비스로 제공

    - 동일한 클라이언트 코드에서 하둡 파일시스템의 다른 버전으로 엑세스할 필요가 있을 때 좋음

  2. C => libhdfs 를 사용

    - JNI(Java Native Interface)를 사용

    - libhdfs/docs/api 폴더에서 찾을 수 있음

    - http://wiki.apache.org/hadoop/LibHDFS 를 참조바람

  3. 퓨즈(FUSE : Filesystem in Userspace)

    - 사용자 공간에서 구현한 파일시스템을 유닉스 파일시스템으로 통합할 수 있도록 지원

    - Fuse-DFS contrib :모든 하둡 파일시스템이 표준 파일시스템으로 마운트될 수 있도록 지원

  4. WebDAV(웹다브)

    - 파일 편집과 수정을 지원하기 위한 HTTP의 확장

    - WebDAV shares : 대부분 운영체제가 지원하는 파일시스템처럼 마운트 될 수 있음

    - http://issues.apache.org/jira/browse/HADOOP-496

  5. HTTP

    - 디렉토리 리스팅과 데이터를 검색하기 위한 읽기전용 인터페이스를 제공함

    - 디렉토리 리스팅 : 네임노드의 내장된 웹서버(50070) 에 의해 XML 형태로 제공

    - 파일 데이터 : 데이터노드의 웹서버(50075)로부터 스트리밍 됨

  6. FTP

    - 기존 FTP 클라이언트를 사용함으로 HDFS로 데이터를 송수신하기 위한 편리한 방법 제공


ㅇ Java Interface

  - DistributedFileSystem : HDFS 구현

  - FileSystem 추상 클래스 : 파일시스템 사이의 이식성 유지