[Hadoop Distributed File System]
HDFS는 Hadoop Framework을 위해 JAVA로 작성된 distributed, scalable, potable한 filesystem이다.
Hadoop instance의 각 노드들은 하나의 datanode를 가지고 있다. datanode들의 cluster는 HDFS의 cluster를 형성한다.
각 노드가 하나로 정의된 datanode를 필요로 하지 않기 때문이다.(?) 각 datanode는 네트워크상에서 HDFS가 정한 block protocol을 이용해서 데이터를 서비스한다. 이러한 파일시스템은 TCP/IP 래이어를 사용하며 클라이언트는 RPC를 이용해서 서로 통신한다.
[데이터 복제]
HDFS는 대용량 파일들을 여러개의 머신에 걸쳐서 저장하는데 이상적으로는 여러개의 64MB 크기의 파일들이다. 이것은 결국 여러대의 호스트에 데이터를 복사하여 신뢰성을 확보하고 있다. 그렇기 때문에 각 호스트에 RAID 스토리지가 필요하지 않게된다.
기본값은 3이며 이것은 곧 3대의 호스트에 데이터가 복사된다는 뜻이다. 그 중 2개는 동일한 RACK에 존재하며 나머지 하나는 다른 RACK에 존재한다.
HDFS는 대용량 파일을 다루기 위해 디자인되었으며 성능 향상을 위해 POSIX Filesystem의 호환성을 완벽히 만족하진 않는다. 또한 High Availability를 보장하지 않는다.
[Namenode]
HDFS는 하나의 유일한 서버로 name node라는 것이 필요하다. 이것이 결국 Single point of failure가 된다. 만약 이것이 다운되면 전체 filesystem은 offline이 된다.
다시 복구되었을 때, name node는 모든 outstanding operations를 재수행해야 한다. 대용량 클러스터의 경우 30분이 소요될 수도 있다.
Filesystem은 또한 Secondary Namenode를 구성하고 있는데 사람들은 가끔 Primary namenode가 죽었을 때 secondary namenode가 그 역할을 이어 받을 것이라 착각한다. 하지만 secondary namenode는 primary namenode의 directory 정보의 snapshot을 떠 놓고 이것을 local과 remote directory들에 저장하고 있을 뿐이다. 이것으로 결국 Primary Namenode가 장애로 부터 복구되었을 때 전체 filesystem action들을 다시 수행하지 않아도 복구할 수 있도록 도와준다.
[Jobtracker & Tasktracker]
HDFS를 사용하는 장점은 jobtracker와 tasktracker 사이에서의 data awareness 이다.
jobtracker는 tasktracker에게 데이터의 위치 정보를 이용해서 map/reduce의 스케줄링을 담당한다.
(여기서 부터는 번역 아님)
결과적으로 jobtracker는 MAP/REDUCE job을 tasktracker들에게 할당하고 모니터링 및 failover를 처리하는 master이다.
tasktracker는 작업을 수행하는 worker이고 보통 datanode하고 함께 동작한다. 이유는 보통 HDFS 자체도 network으로 1 hop이 떨어져 있는 것이 대부분인데 실제로 파일을 읽고 연산하는 tasktracker가 datanode와 떨어져 있어서 좋을 것이 하나 없기 때문이다.
일반적으로 datanode는 disk I/O 가 대부분이기 때문에 남아도는 CPU를 tasktracker가 활용하는 것이 효과적인 방법이다.
Tuesday, April 19, 2011
Hadoop Basic
이 글은 WIKIPEDIA에 있는 Apache Hadoop을 번역한 것이며 전체 번역이 아님을 밝힙니다.
[Hadoop Common]
Hadoop에 의해 지원되는 파일시스템의 접근 방법을 제공한다. 관련 JAR 파일들로 구성되어 있으며 Hadoop을 구동하기 위해 필요한 스크립트들로 구성되어 있다. Hadoop Community에서 관련 리소스 모두 제공
작업의 효과적인 스케줄링을 위한 주요 특징은 다음과 같다.
모든 파일시스템은 반드시 location awareness를 제공해야 한다.
[Name of RACK] Worker node가 있는 곳이 RACK의 이름, 즉 네트워크 스위치의 이름이다.
Hadoop application은 이 이름을 통해 데이터가 있는 노드 또는 그 노드에서 작업이 실패한 경우 동일한 RACK/SWITCH에서 동작할 수 있기 때문에 백본 트래픽을 감소시키는 효과가 있다.
HDFS는 데이터 복제를 위해 이것을 사용한다. 복제를 하는 이유는 만약의 사태(정전 등)를 대비하기 위함이다.
[Hadoop Cluster]
일반적인 Hadoop 클러스터는 하나의 마스터와 여러개의 슬레이브 노드로 구성된다.
마스터 노드는 jobtracker, tasktracker, namenode, datanode로 구성된다.
슬레이브 노드(또는 compute node)는 datanode, tasktracker로 구성된다.
[구동환경]
Hadoop은 JRE 1.6 이상에서 동작한다. 표준 구동 및 종료 스크립트는 cluster내의 node들 사이에서 셋업을 수행하기 위한 ssh가 필요하다.(즉 각 노드에 ssh를 열어 두어야 한다.)
[Hadoop Common]
Hadoop에 의해 지원되는 파일시스템의 접근 방법을 제공한다. 관련 JAR 파일들로 구성되어 있으며 Hadoop을 구동하기 위해 필요한 스크립트들로 구성되어 있다. Hadoop Community에서 관련 리소스 모두 제공
작업의 효과적인 스케줄링을 위한 주요 특징은 다음과 같다.
모든 파일시스템은 반드시 location awareness를 제공해야 한다.
[Name of RACK] Worker node가 있는 곳이 RACK의 이름, 즉 네트워크 스위치의 이름이다.
Hadoop application은 이 이름을 통해 데이터가 있는 노드 또는 그 노드에서 작업이 실패한 경우 동일한 RACK/SWITCH에서 동작할 수 있기 때문에 백본 트래픽을 감소시키는 효과가 있다.
HDFS는 데이터 복제를 위해 이것을 사용한다. 복제를 하는 이유는 만약의 사태(정전 등)를 대비하기 위함이다.
[Hadoop Cluster]
일반적인 Hadoop 클러스터는 하나의 마스터와 여러개의 슬레이브 노드로 구성된다.
마스터 노드는 jobtracker, tasktracker, namenode, datanode로 구성된다.
슬레이브 노드(또는 compute node)는 datanode, tasktracker로 구성된다.
[구동환경]
Hadoop은 JRE 1.6 이상에서 동작한다. 표준 구동 및 종료 스크립트는 cluster내의 node들 사이에서 셋업을 수행하기 위한 ssh가 필요하다.(즉 각 노드에 ssh를 열어 두어야 한다.)
Monday, November 15, 2010
Device API에 대한 소문?
오늘 다소 뜻 밖의 이야기를 들었다.
W3C에서 Device API에 대한 진행을 보류(?)한다는 것이다. Nokia가 주도적으로 하던 것, 그리고 BONDI, JIL...
얼마 전에는 Apple AppStore에 대항해서 전 세계 사업자들이 하나된 마켓을 만들겠다고 WAC 이란 것을 기획했다. 현재 KT와 SKT는 과제 진행중이다. 트윗에 보니 이미 관련 개발사도 정해진 것 같고 인력들은 이미 작업 착수했다.
이런 상황에서 W3C의 결정의 진실 유무를 떠나 그 자체가 논란의 대상이 된다는 것이 뜻 밖일 수 밖에 없다. 물론 Device API라는 것이 양날의 검일 수는 있다. Mobile device 제조업체가 PC 시장에서 그랬듯이 단순한 Mobile OS compatible H/W 제조업체로 전락할 수 있는 단초가 될 수도 있다. 하지만 이통사에게는 시장의 주도권을 다시 빼앗을 수 있는 기회일 수도 있고, Web 개발자들에게는 새로운 시장이 열리는 긍정적 신호탄으로 받아 들여질 수도 있다.
W3C의 모호한 행동으로 인해 Device API에 대한 표준화가 지연되면 자연스럽게 Mobile OS 경쟁은 더욱 뜨거워질 것이고 기존 Web OS를 밀고 있는 업체들은 당황할 수도 있겠다. 아니 오히려 WHATWG처럼 W3C의 미온적 태도와는 노선이 다른 조직이 이끌 수도 있을 것이다. 원래 JIL, BONDI는 W3C와는 다른 조직이니 말이다.
당장 서비스를 기획하고 만들고 있는 나의 입장에서는 반갑지만은 않다. 이유는 단순하다. 서비스 데모 어플의 개발을 HTML + Device API로 진행하려 했었기 때문이다. Device API의 모호한 진행상황으로 인해 이제 어플 개발은 아마도 그나마 가장 쉬운 android AVD를 이용하지 않을까 싶다.
휴.. 이제 자야지.
W3C에서 Device API에 대한 진행을 보류(?)한다는 것이다. Nokia가 주도적으로 하던 것, 그리고 BONDI, JIL...
얼마 전에는 Apple AppStore에 대항해서 전 세계 사업자들이 하나된 마켓을 만들겠다고 WAC 이란 것을 기획했다. 현재 KT와 SKT는 과제 진행중이다. 트윗에 보니 이미 관련 개발사도 정해진 것 같고 인력들은 이미 작업 착수했다.
이런 상황에서 W3C의 결정의 진실 유무를 떠나 그 자체가 논란의 대상이 된다는 것이 뜻 밖일 수 밖에 없다. 물론 Device API라는 것이 양날의 검일 수는 있다. Mobile device 제조업체가 PC 시장에서 그랬듯이 단순한 Mobile OS compatible H/W 제조업체로 전락할 수 있는 단초가 될 수도 있다. 하지만 이통사에게는 시장의 주도권을 다시 빼앗을 수 있는 기회일 수도 있고, Web 개발자들에게는 새로운 시장이 열리는 긍정적 신호탄으로 받아 들여질 수도 있다.
W3C의 모호한 행동으로 인해 Device API에 대한 표준화가 지연되면 자연스럽게 Mobile OS 경쟁은 더욱 뜨거워질 것이고 기존 Web OS를 밀고 있는 업체들은 당황할 수도 있겠다. 아니 오히려 WHATWG처럼 W3C의 미온적 태도와는 노선이 다른 조직이 이끌 수도 있을 것이다. 원래 JIL, BONDI는 W3C와는 다른 조직이니 말이다.
당장 서비스를 기획하고 만들고 있는 나의 입장에서는 반갑지만은 않다. 이유는 단순하다. 서비스 데모 어플의 개발을 HTML + Device API로 진행하려 했었기 때문이다. Device API의 모호한 진행상황으로 인해 이제 어플 개발은 아마도 그나마 가장 쉬운 android AVD를 이용하지 않을까 싶다.
휴.. 이제 자야지.
Tuesday, September 08, 2009
Tuesday, September 09, 2008
GPRS Core Network - Wikipedia, the free encyclopedia
GPRS Core Network - Wikipedia, the free encyclopedia: "PDP Context
The PDP (Packet Data Protocol, e.g. IP, X.25, FrameRelay) context is a data structure present on both the SGSN and the GGSN which contains the subscriber's session information when the subscriber has an active session. When a mobile wants to use GPRS, it must first attach and then activate a PDP context. This allocates a PDP context data structure in the SGSN that the subscriber is currently visiting and the GGSN serving the subscribers access point. The data recorded includes.
* Subscriber's IP address
* Subscriber's IMSI
* Subscriber's
o Tunnel Endpoint ID (TEID) at the GGSN
o Tunnel Endpoint ID (TEID) at the SGSN
The Tunnel Endpoint ID (TEID) is a number allocated by the GSN which identifies the tunnelled data related to a particular PDP context.
There are two kinds of PDP contexts.
* Primary PDP Context
o Has a unique IP address associated with it
* Secondary PDP Context
o Shares an IP address with another PDP context
o Is created based on an existing PDP context (to share the IP address)
o Secondary PDP contexts may have different Quality Of Service settings
A total of 11 PDP contexts (with"
The PDP (Packet Data Protocol, e.g. IP, X.25, FrameRelay) context is a data structure present on both the SGSN and the GGSN which contains the subscriber's session information when the subscriber has an active session. When a mobile wants to use GPRS, it must first attach and then activate a PDP context. This allocates a PDP context data structure in the SGSN that the subscriber is currently visiting and the GGSN serving the subscribers access point. The data recorded includes.
* Subscriber's IP address
* Subscriber's IMSI
* Subscriber's
o Tunnel Endpoint ID (TEID) at the GGSN
o Tunnel Endpoint ID (TEID) at the SGSN
The Tunnel Endpoint ID (TEID) is a number allocated by the GSN which identifies the tunnelled data related to a particular PDP context.
There are two kinds of PDP contexts.
* Primary PDP Context
o Has a unique IP address associated with it
* Secondary PDP Context
o Shares an IP address with another PDP context
o Is created based on an existing PDP context (to share the IP address)
o Secondary PDP contexts may have different Quality Of Service settings
A total of 11 PDP contexts (with"
Subscribe to:
Posts (Atom)