Как запустить вторичный Наменод в AWS EMR - PullRequest
0 голосов
/ 04 сентября 2018

Мы работаем с системой производственного класса, в которой мы хотим запустить вторичный наменод в AWS EMR. Ниже приведен вывод jps, в котором не работает вторичный демон namenode

[root@ip-10-2-23-23 ~]# jps
6241 Bootstrap
7041 ResourceManager
10754 RunJar
6818 WebAppProxyServer
10787 SparkSubmit
7619 JobHistoryServer
6922 ApplicationHistoryServer
3661 Main
4877 Main
6318 NameNode
8943 LivyServer
4499 Jps
5908 Bootstrap
4791 Main
10619 StatePusher
9918 HistoryServer

Вторичный namenode необходим для проверки контрольных точек namenode и регулярного создания fsImage. Я не настроил HA для Namenode.

Команда, которую мы запустили вручную для создания FsImage:

hdfs secondarynamenode -checkpoint

Как можно запустить вторичный наменод в AWS EMR или есть какая-либо конфигурация?

Версия Hadoop : Hadoop 2.8.3-amzn-0

1 Ответ

0 голосов
/ 25 апреля 2019

AWS EMR не запускает вторичный процесс Namenode в EMR, поэтому FSImage не будет создан. Запуск cron каждый час для создания FSImage решает проблему чрезмерного использования диска, поскольку FSImage объединяет снимок (метаданные Namenode) с создать новый FsImage меньшего размера. Создание FSImage является дорогостоящей операцией для Namenode и использует ресурсы экземпляра. Если существует слишком много снимков, ожидающих слияния, Namenode может никогда не восстановиться после этого утомительного процесса, поэтому лучше часто создавать FSImage через cron. В стандартной системе Hadoop эта работа выполняется путем запуска вторичного Namenode в отдельном экземпляре, но EMR не имеет понятия двух мастеров, поэтому главный узел всегда является единственной точкой отказа.

hdfs secondarynamenode -checkpoint

Другим решением этой проблемы является запуск EMR на пользовательских Hadoop, таких как MapR.

...