Hadoop (2)-완전 분산 설치, Hadoop 고 가용성

Hadoop (2)-완전 분산 설치, Hadoop 고 가용성

1. 완전 분산 설치

재설정 후에는 삭제할 필요가 없습니다. clusterID 및 이름 ID는 동일하게 유지할 수 있습니다.

의사 배포는 모든 역할 프로세스를 node06 프로세스 위에 배치하는 것이지만 전체 배포는 다른 노드의 배포 여야합니다.

이전 설정은 모든 역할 프로세스가 동일한 노드 hadoop0에 있고 실제 네임 노드는 단일 서버를 배포해야한다는 것입니다.

1. 모든 환경은 JDK가 있어야합니다;
   를 통해 jps보기에
2. 모든 서버의 시간 동기화,
   별칭 확인 : cat /etc/hosts서로 ping 할 매핑 된 IP 주소
   cat /etc/sysconfig/selinux가 있습니다. 닫혀 있는지 여부를 확인합니다.
   
   완전히 분산 된 암호없는 로그인에는 다음이 있어야합니다. 마스터 노드는 누구이며 관리 노드는 누구든 자신의 키 파일을 배포하는 것 입니다.
   비밀없는 로그인은 하나의 마스터 노드와 다른 세 개의 슬레이브 노드의 비밀없는 로그인을 포함합니다.

1 단계 : 먼저 홈 디렉토리로 돌아가서 숨겨진 파일이 있는지 확인합니다. (그렇지 않은 경우 생성해야 함)

cd 
ll -a
查看是否有.ssh文件

2 단계 : .ssh 파일 디렉토리를 입력하고 배포 명령을 통해 배포합니다.

在node06的服务器上：
cd .ssh/
scp id_dsa.pub node07:`pwd` /node06.pub
node06是主节点，node07是要被分发的节点；
在node07的服务器上：
cd .ssh/
cat node06.pub >> authorized_keys

공개 키가 있다는 것은 node06의 서버에서 ssh node07을 통해 키없이 로그인 할 수 있음을 의미합니다.

이 토대를 통해 완전히 분산 된 것을 구축 할 수 있습니다. 이전에 의사 배포를 빌드하지 않은 hadoop-env.sh경우 먼저 수정 해야합니다 . 그렇지 않은 경우 JVM을 찾을 수 없다는 메시지가 표시됩니다.
core-site.xml을 수정해야 함 :

또한 hdfs-site.xml

을 수정 해야 합니다 . 슬레이브를 수정 하고 슬레이브 노드를 구성

해야합니다. 실수로 첫 번째 행에 06을 입력하면 마스터 및 슬레이브 노드가 함께 배치하면 수행해야 할 작업이 전송입니다. DataNode를 전송하십시오.

배포 작업 :

먼저 각 서버에 동일한 디렉토리가 있는지 확인하십시오.
그런 다음 해당 문서를 배포하십시오.
scp -r stx/node07:pwd ''

세부 사항 : 환경 변수를 구성 할 위치. 지금까지는 node06이고 환경 변수를 성공적으로 구성해야합니다.
프로파일 환경 변수의 분배는 scp를 통해 실현됩니다.
scp /etc/profile node07:/etc/

이제 클러스터 시작을위한 기본 조건이 충족되었지만 클러스터를 시작할 때 먼저 노드 포맷 작업을 수행해야합니다.

hadoop0 (node06)에서 실행 : hdfs namenode -format포맷합니다. 형식화 기능은 core-site.xml에 정의 된 전체 파일 위치에 파일을 저장하는 것입니다.

포맷 은 다른 노드가 아닌 기본 노드에 대해서만 설정 됩니다. 다른 노드는 시작할 때 그것을 가질 것입니다.

전체 폴더로 이동 을 시작 cd /var/sxt/hadoop/full/dfs통해 start-dfs.sh. 시작이 완료된 후 jps를 통해 노드의 시작을 확인하십시오.

마스터 노드 (hadoop0 또는 node06)에는 이름 노드 만 있습니다. 이름 노드




중 하나에 문제가 있다고 가정하면 어떻게해야합니까?

• logs, log /hadoop-2.7.4/logs, 마스터 노드 전용 namenode 로그 (hadoop0 또는 node06), 다른 노드의 datanode 로그를 참조하십시오. (hadoop1, hadoop2, hadoop3)
• 로그의 맨 아래 100 줄보기 :tail -100 hadoop-root-datanode-hadoop1.log
• 업로드 된 파일은 잘릴 때 엄격하게 잘립니다.hdfs dfs -D dfs.blocksize=1048576 -put test.txt

2. 고 가용성

hadoop1의 이름 노드는 가장 어색합니다. 이름 노드는 여러 데이터 노드를 제어해야하며 전체 클러스터를 관리하는 단일 관리 노드입니다. 네임 노드가 중단되면 전체 클러스터를 사용할 수 없게됩니다.

위는 단일 실패 지점 문제입니다. 네임 노드는 메타 데이터 정보를 유지하고 디스크와 상호 작용하지 않습니다. 클러스터가 대규모에 도달하고 단일 지점이 대규모 클러스터의 데이터 볼륨을 제어 및 유지하고 있다고 가정하면 단일 지점의 기능이 제한되고 전체 클러스터 효과의 성능을 제한합니다. 이를 단일 지점 병목 문제 라고합니다 .

F– 페더레이션,
HA– 고 가용성

HA는 동시에 여러 마스터 노드가 제공하는 여러 개가 될 수 있습니다. 백업 방법을 제공하십시오. 메인이 끊기면 대기가 시작되어 단일 다운 타임 지점으로 인한 전체 클러스터의 다운 타임을 방지합니다.

F-Multiple 마스터 노드는 동시에 서비스를 제공하는데, 이는 소위 연합이라고 불리는 네임 노드의 용량을 확장하기 위해 존재합니다.

2.0 마스터-슬레이브 아키텍처 모델 다이어그램 :

위에서 자동 전환이 완료되고 아래에서 수동 전환이 완료됩니다. 사육사 프레임 워크는 계획을 조정하기 위해 자동 건설 중에 사용됩니다.

두 개의 네임 노드 노드 중 하나를 교체하려는 경우 데이터 동기화가 필요합니다. 원래 데이터 정보를 동기화하는 것은 실제로 아래의 다른 데이터 블록에 대한 설명입니다.

블록 데이터를 동적이라고하고 오프셋을 정적이라고합니다.

동기화에는 정적 및 동적의 두 가지 방법이 있습니다.

데이터 노드가 네임 노드에보고하기 때문에 동적이라고하는 이유는 무엇입니까? 이제 데이터 노드는 동시에 두 개의 네임 노드에보고하고 동적 블록 정보는 단일 보고서에서 다자간 보고서로 변경되었으며 메타 데이터는 두 네임 노드간에 동기화 될 수 있습니다.

핵심은 정적 동기화를 동기화하는 방법입니다.

소켓 통신, 하드 코딩 됨. 그러나이 방법은 확인 확인 메커니즘이 필요하고 피드백을 제공해야하며 확인 여부에 관계없이 딜레마에 직면합니다. 기계가 고장난 경우 확인할 수 없습니다. 이를 강력한 일관성이라고합니다. 이로 인해 단일 지점 차단의 역할이 발생했습니다.

클라이언트 역할은 활성 네임 노드와 만 연락을 유지합니다.

하둡을 수행하는 방법? -편집 내용은 로그 파일에 기록되고 네임 노드로 확인됩니다. (앞서서)

새 서버가 현재 로그 파일을 저장하고 (클라이언트가 명령에 따라 작동 함) 다른 이름 노드가 로그를 읽어 이러한 방식으로 동기화되도록합니다. 이것을 nfs라고합니다.

이 접근 방식의 단점은 여전히 ​​단일 장애 지점이 있으므로 저널 노드 기술이 파생된다는 것입니다.

클러스터 서버 동기화 데이터의 작업을 완료하는 데 도움이되는 로그 서버 클러스터 노드를 제공합니다. 세 대의 서버는 동시에 로그 파일을 수신하고 세 대의 서버는 모두 동일하게 수신합니다. 왜 3 개의 방송국이 같은 콘텐츠를 받아 들여야하는지, 그것이 망가 질까 걱정하고 보험 업무를 수행해야합니다.

여러 서버의 이유 : 그중 하나가 끊어 질까 봐 걱정됩니다. 그러나 여러 서버에는 어떤 일이 발생할 수 있습니다. 세 서버 모두 수락에 성공했는지 확인해야합니까? 관계형 데이터베이스에서는 강력한 일관성이 가능하지만 클러스터에서는 가능하지 않습니다.

따라서 세 가지 중 하나가 실패하면 공차 하한이 있어야합니다. 하나를 끄도록 허용합니다 (3 세트). 일반적으로 홀수 클러스터가 사용됩니다. 약한 일관성.

그것은 모자 정리를 포함합니다.

Activate는 데이터를 클러스터에 저장하고 Stabdy는 보조 노드없이 데이터를 동기화합니다 (지속성 작업 수행).

데이터는 데이터 노드가 두 노드를 동기화하는 방법과 정적 메타 데이터 정보를 동기화하는 방법의 두 부분으로 나뉩니다. journalnode 클러스터를 통해 메시지를 업로드하고 다운로드합니다.

수동 스위치

---

자동 전환

분산 조정 시스템 인 사육사 클러스터에 의존해야합니다. 다른 빅 데이터 클러스터의 실행 상태를 조정합니다.

그것에서 핵심 관리 역할을 수행하십시오.

Zookeeper는 분산 조정을위한 최고의 아키텍처입니다.

Zookeeper는 각 네임 노드에서 물리적 프로세스를 엽니 다.이 물리적 프로세스는 장애 조치 제어 프로세스 인 FailoverController라고합니다.

사육사는 해당 마스터-슬레이브 스위치를 어떻게 완료합니까? 처음에 네임 노드는 비결 함 상태에 있습니다. 사육사는 선택 메커니즘을 제공합니다. 각 네임 노드는 사육사에게 적용됩니다. 먼저 등록하는 사람이 마스터 노드가됩니다.

Zookeeper는 작은 데이터베이스로 이해되며, 그 의미는 조정을 돕고 노드를 등록하거나 노드 경로 znode를 만드는 것입니다.

경로 아래에는 노드의 관련 등록 정보가 있습니다. 사육사 유지 성능은 부모-자식 디렉터리 트리를 통해 이루어지며, 등록은 메인 노드가 유지하고 있음을 의미합니다.

사육사 클러스터에 노드를 등록하고 만듭니다.

이벤트 모니터링 -zookeeper 및 namenode는 항상 연락을 유지하고 zkfc를 통해 연락을 유지합니다. 노드가 갑자기 중단되고 zkfc 프로세스는 선택 메커니즘 인 healthmo라는 두 가지 구성 요소를 엽니 다. zkfc는 언제 어디서나 namenode의 상태를 모니터링합니다. 의무는 그가 선거에 참여하고 건강을 모니터링하는 것입니다.

문제를 발견 한 zk는 이벤트를 파악하고 대기 노드에 알 렸습니다. 슬레이브 노드는 이벤트 발생을 모니터링하기 위해 zk를 맡깁니다. zk 클러스터는 이벤트를 캡처하고 슬레이브 노드에 알립니다. 슬레이브 노드가하는 일은 권한을 변경하고 자신을 마스터 노드로 등록하는 것입니다. 이 동작을 함수 콜백이라고합니다.

함수 콜백은 각 클라이언트의 기능입니다.

노드 생성 및 알림 동작을 등록합니다.
Zookeeper는 다음과 같은 작업을 유지합니다.

1. 등록이 성공하면 zkfc 프로세스는 언제 어디서나 정상 마스터 노드의 상태를 관찰합니다.
2. 건강에 해로운 것이 발견되면 사육사는 리프팅 메커니즘을 통해 선거인의 신원 변경에 대한 알림을받습니다.
3. 노드에서 이벤트가 발생하면 zookeeper는 대기자에게 알리고 대기자는 자신을 활성화 된 것으로 간주합니다 (그러나 아직 직접 변경할 수 없음)
4. 대기 모드는 강제로 활성 상태로 전환 된 다음 자체적으로 활성화 상태로 전환됩니다.

동시에 하나의 활성화 만 허용됩니다.

연방

그림에서 볼 수 있듯이 세 개의 네임 노드는 동시에 병렬로 연결되어 있으며 기본 데이터 노드 분업은 다음 스토리지 모델과 같습니다.

연합의 역할 :
네임 노드 노드의 메모리 데이터 양은 제한되어 있지만 기본 데이터의 양이 매우 크다고 가정하면 단일 노드의 한계가 나타납니다.

Joint i Form One :
연합이 필요한 이유 : 클러스터는 균형이 맞지 않습니다. 여러 네임 노드 노드가 병렬로 작동하고 공동으로 기본 저장 공간을 사용합니다.

조인트 형태 2 :
네임 노드 노드를 추가하면 원래 메모리 공간이 확장되지 않습니다.

공동 i 형태 3 : 데이터
노드가 충분하지 않으며 연합 형태로 운영 및 관리하려면 여러 개의 네임 노드가 필요합니다.

첫 번째 예는 각 네임 노드가 서로 다른 업무를 수행하고 저장 공간이 병합된다는 것입니다. 세 번째는 모든 사람이 업무를 수행하는 것입니다.
(상사가 호스트를 분할하는 시나리오를 기억하십시오)

네임 노드 노드가 많으면 이는 고객 단점도 있습니다. 어떤 네임 노드가 일을하는지 기억해야합니다.

이러한 단점은 네임 노드 연합 스토리지를 기반으로 서비스 플랫폼 인터페이스를 제공하는 기업에서 종종 발견됩니다. 인터페이스 메커니즘은 작업을 분류합니다. 클라이언트가 서비스 플랫폼에 연결하고 먼저 빅 데이터에 대한 플랫폼의 인터페이스를 찾고 이러한 인터페이스가 다음 데이터 노드의 분류 및 저장을 완료합니다.

또 다른 문제는 서버가 다운 타임의 위험이 있으며 수평 적 관점에서 서버 클러스터의 수평 확장 스토리지 용량이 향상된다는 것입니다. 따라서 수직 각도의 경우 각 기계의 가용성이 높아야합니다. 고 가용성의 목적은 마스터 노드의 정보를 동기화하는 것입니다.

연맹의 설립은 초점이 아닙니다. 네임 노드가 저장하는 데이터는 메타 데이터 데이터이며 오프셋과 같은 정보를 포함합니다.

HA 고 가용성 클러스터 구축

두 개의 네임 노드 노드 간의 자동 전환 기능이 실현되어야합니다. 따라서 node06과 node07 사이에 키가없는 작업이 있어야합니다.

키 생성기 :
자신의 파일에 추가합니다.

node06의 현재 디렉토리에 배포합니다 : (덮어 쓰지 않도록 이름 변경)

nameservices는 구성된 노드 정보와 연관되어야하는 논리적 이름을 나타냅니다.

고 가용성 구성 이론

버전 2.0은 주로 고 가용성 HA 및 페더레이션을 통해 버전 1.0의 단일 장애 지점 문제를 해결합니다.

문서를 읽으십시오.

nameservices :
먼저 hdfs에로드합니다.

dfs.namenode.rpc-address를 사용하여 원격 서비스 호출을 통해 물리적 시스템의 위치를 ​​찾습니다.

dfs.namenode.http-address : 브라우저에 서비스를 제공하여 브라우저가이 클러스터에 액세스 할 수 있도록합니다.

dfs.namenode.shared.edits.dir ：

dfs.ha.fencing.methods : 상태 격리의 의미를 나타냅니다. 이 일의 구성은 실패 할 때 살아남은 노드를 격리합니다.

예 : 두 개의 노드가 있는데 하나는 ann이고 다른 하나는 sbnn입니다. ann이 실패하면 선거 메커니즘은 사육사 클러스터에 알리고 사육사는이 이벤트를 캡슐화하여 sbnn에 전달합니다. sbnn이 가져 오면 단순히 자신을 승격시키는 것이 아니라 먼저 ann의 상태를 강제로 변환하여 비활성 노드로 만듭니다.

이 변환은 dfs.ha.fencing.methods의 기능입니다.

개인 키 작업에 관련된 파일 – id_dsa.

명령은 다음과 같습니다. 키 파일을 생성 한 다음 작성자의 파일에 추가합니다.

fs.defaultFS : namenode 마스터 노드, 코어 사이트 파일이 수정되었습니다.

Zookeeper는 전체 시스템 외부에 있으며 필요하지 않습니다. 시작 및 종료는 현재 클러스터의 시작 및 종료와 관련이 없습니다.

사육사 클러스터에서 각 nameNode에는 세션 세션과 바인딩이 있습니다.

웹 개발에서 세션은 방문자의 고유 식별자로 사용되며 http 프로토콜은 상태 비 저장 프로토콜이므로 다음에 방문 할 때 알 수 없습니다. 이를 해결하기 위해 서버는 클라이언트의 쿠키에 의해 유지되는 세션을 제공하여 다른 얼굴을 구현합니다.

각 namenode 노드는 zookeeper에 등록되고 각 namenode는 영구 세션에 해당합니다. 세션에 수명주기 문제가 있으며 노드와 클러스터 간의 연결이 중단되면 해당 세션에 바인딩 된 노드 노드도 파괴됩니다.

사육사 : 첫 번째는 등록, 두 번째 콜백 모니터링, 세 번째 이벤트 기능입니다. 콜백은 클라이언트의 기능이며 실제로 콜백은 zkfc의 기능입니다.
zkfc는 네임 노드의 상태를 유지하고 모니터링합니다.

Zookeeper는 3-5 개의 노드에서 실행되어야하는 별도의 클러스터입니다. 클러스터를 차단합니다. hdfs-site에 매개 변수 구성을 추가합니다. 완전한 자동 장애 조치.

Zookeeper는 클러스터 구성 시작시 메시지, 즉 클러스터 구성에 참여한 서버 수를 요구합니다. 두 번째 요구 사항은 각 서버에 serverid 인 서버 ID를 제공하는 것입니다. 그것은 사육사의 선거 메커니즘을 포함합니다. 마스터-슬레이브 구조이기 때문에 처음에는 누가 마스터인지, 동시에 가장 높은 숫자를 가진 사람이 마스터인지 결정해야합니다.

그런 다음 배포하기 시작했습니다.