HttpFs выигрывают от высокой доступности и службы имен

Question

Я использую Apache Hadoop-2.7.1 на кластере, который состоит из трех узлов

nn1 master name node 
nn2 (second name node)   
dn1 (data node)

мы знаем, что если мы настроим высокую доступность в этом кластере

у нас будет два основных узла, один из которых активен, а другой находится в режиме ожидания

и если мы настроим кластер для вызова службы имен тоже, следующий сценарий будет в порядке

сценарий такой:

1- nn1 активен, а nn2 находится в режиме ожидания

поэтому, если мы хотим получить файл (называемый myfile) из dn1, мы можем отправить этот URL из браузера (запрос webhdfs)

http://nn1/webhdfs/v1/hadoophome/myfile/?user.name=root&op=OPEN

2- демон узла name в nn1 уничтожен, поэтому в соответствии с высокой доступностью nn1 находится в режиме ожидания, а nn2 активен, поэтому мы можем получить myfile сейчас, отправив этот веб-запрос на nn2, поскольку он сейчас активен

http://nn2/webhdfs/v1/hadoophome/myfile/?user.name=root&op=OPEN

поэтому настройки службы имен с высокой доступностью достаточно для сбоя узла имени и для нормальной работы webhdfs.

так в чем же преимущество добавления httpfs здесь, потому что webhdfs с высокой доступностью не поддерживается, и мы должны настроить httpfs

Answer 1

Я понимаю, что это продолжение вашего предыдущего вопроса здесь.

WebHDFS а также HttpFs это две разные вещи. WebHDFS является частью Namenode, и это NN, который обрабатывает WebHDFS Вызовы API, тогда как HttpFs - это отдельная служба, независимая от Наменодов и HttpFs Сервер обрабатывает вызовы API.

какая польза от добавления httpfs

Ваши вызовы REST API останутся неизменными независимо от того, какой NN находится в активном состоянии. HttpFs будучи осведомленным о HA, перенаправит запрос в текущий активный NN.

Допустим HttpFs сервер запущен в nn1,

WebHDFS GET запрос

curl http://nn1:50070/webhdfs/v1/hadoophome/myfile/?user.name=root&op=OPEN

Это обслуживается демоном Наменоде, работающим в nn1,
Сценарий 1: nn1 Активен Запрос будет вознагражден действительным ответом.
Сценарий 2: nn2 Активен Выполнение одного и того же запроса не удастся, так как в нем не запущен Active NN nn1,

Таким образом, вызов REST должен быть изменен для запроса nn2

curl http://nn2:50070/webhdfs/v1/hadoophome/myfile/?user.name=root&op=OPEN

Теперь это будет обслуживаться демоном NN, работающим в nn2,

HttpFs GET запрос

curl http://nn1:14000/webhdfs/v1/hadoophome/myfile/?user.name=root&op=OPEN

Этот запрос обслуживается HttpFs служба работает в nn1,
Сценарий 1: nn1 Активен HttpFs сервер работает в nn1 перенаправит запрос в текущий активный Namenode nn1,
Сценарий 2: nn2 Активен HttpFs сервер работает в nn1 перенаправит запрос в текущий активный Namenode nn2,

В обоих сценариях вызов REST одинаков. Запрос не будет выполнен, если HttpFs сервер упал.

Настройка службы имен с высокой доступностью достаточно для сбоя узла имени и для нормальной работы webhdfs

nameservice логическое имя, данное паре наменодов. это nameservice не является фактическим хостом и не может быть заменен параметром хоста в вызовах API REST.