Никогда не удалось построить большой хаос и искровой кластер

Question

Мне было интересно, может ли кто-нибудь помочь мне с этой проблемой при развертывании искрового кластера с помощью инструмента bdutil. Когда общее количество ядер увеличение (> = 1024), он не все время со следующими причинами:

1. Некоторые машины никогда не sshable, как «Ср Дек 8 13:45:14 PST 2015: «hadoop-w-5» еще не sshable (255); спать «

2. Некоторые узлы терпят неудачу с ошибкой« Exited 100 »при развертывании узлов искровой рабочей станции, например« Вторник 8 декабря 15:28:31 PST 2015: Exited 100: gcloud --project = cs-bwamem --quiet --verbosity = info compute ssh hadoop-w-6 --command = sudo su -l -c "cd $ {PWD} & & ./deploy-core- setup.sh "2 >> deploy-core-setup_deploy.stderr 1 >> deploy-core-setup_deploy.stdout --ssh -flag = -tt --ssh-флаг = -oServerAliveInterval = 60 --ssh-флаг = -oServerAliveCountMax = 3 --ssh-флаг = -oConnectTimeout = 30 = --zone нам-central1-е»

В файле журнала, он говорит:

Hadoop-ш-40: ==> разворачивать-ядро-setup_deploy.stderr < ==

Hadoop-ш-40: DPKG-запрос: пакет «OpenJDK -7-jdk 'не установлен и информация отсутствует

hadoop-w-40: Используйте dpkg -info (= dpkg-deb -info) для проверки архивных файлов,

hadoop-w-40: и dpkg --contents (= dpkg-deb --contents), чтобы перечислить их содержимое.

hadoop-w-40: Не удалось получить http://httpredir.debian.org/debian/pool/main/x/xml-core/xml-core_0.13+nmu2_all.deb Ошибка чтения с сервера. Дистанционное закрытое соединение [IP: 128.31.0.66 80]

hadoop-w-40: E: Не удалось получить некоторые архивы, возможно, запустить apt-get update или попробовать с -fix-missing?

Я попытался использовать 16-ядерные 128-узловые, 32-ядерные 64-х узлы, 32-ядерные 32-разрядные и другие по 1024-ядерным конфигурациям, но либо вышли вышеизложенные причины 1 или 2.

Я также попытался изменить ssh-флаг, чтобы изменить ConnectTimeout на 1200 и изменить bdutil_env.sh, чтобы установить интервал опроса в 30, 60, ..., ни один из них не работает. Всегда будут какие-то узлы, которые терпят неудачу.

Вот одна из конфигураций, которые я использовал:

время ./bdutil \ --bucket $ ВЕДРО \ --force \ --machine_type n1-Highmem-32 \ --master_machine_type n1 -highmem-32 \ --num_workers 64 \ --project $ ПРОЕКТА \ --upload_files $ {JAR_FILE} \ --env_var_files hadoop2_env.sh, расширение/искровой/spark_env.sh \ развернуть

Answer 1

To суммировать часть ormation, которые вышли из отдельного обсуждения по электронной почте, поскольку изменения IP-адресов изменяются, и назначаются разные зеркала debian, иногда могут возникать проблемы, когда параллельные вызовы apt-get install во время развертывания bdutil могут либо перегружать некоторые несбалансированные серверы, либо запускать защиту DDOS, приводя к сбоям развертывания ,Они имеют тенденцию быть временными, и в настоящий момент, как представляется, я могу снова развернуть большие кластеры в таких зонах, как us-east1-c и us-east1-d.

Есть несколько вариантов, вы можете предпринять, чтобы уменьшить нагрузку на DEBiAN зеркал:

1. Установите MAX_CONCURRENT_ASYNC_PROCESSES в гораздо меньшее значение, чем по умолчанию 150 внутри bdutil_env.sh, таких как 10 только развернуть 10 на время; это заставит развертывание заняться больше времени, но облегчит загрузку, как если бы вы просто сделали несколько развертываний с 10-узлами в обратном порядке.
2. Если виртуальные машины были успешно созданы, но шаги развертывания завершились неудачно, вместо необходимости повторить весь цикл удаления/развертывания, вы можете попробовать ./bdutil <all your flags> run_command -t all -- 'rm -rf /home/hadoop', а затем ./bdutil <all your flags> run_command_steps, чтобы просто запустить всю попытку развертывания.
3. Постройте кластер, используя resize_env.sh; сначала установите --num_workers 10 и разверните кластер, а затем отредактируйте resize_env.sh, чтобы установить NEW_NUM_WORKERS=20, и запустите ./bdutil <all your flags> -e extensions/google/experimental/resize_env.sh deploy, и он будет развертывать новые рабочие 10-20, не касаясь этих первых 10. Затем вы просто повторяете, добавляя еще 10 работников в NEW_NUM_WORKERS каждый раз. Если попытка изменения размера не удалась, вы просто ./bdutil <all your flags> -e extensions/google/experimental/resize_env.sh delete, чтобы удалить этих дополнительных работников, не затрагивая тех, которые вы уже развернули успешно.

Наконец, если вы ищете более воспроизводимые и оптимизированных развертывания, вы должны рассмотреть возможность использования Google Cloud Dataproc, что позволяет использовать стандартные gcloud CLI для deploy cluster, submit jobs, и далее manage/delete clusters без необходимости запоминать ваши bdutil флаги или отслеживать, какие кластеры у вас есть на вашей клиентской машине. Вы можете использовать SSH в кластерах Dataproc и использовать их в основном так же, как и кластеры bdutil, с некоторыми незначительными отличиями, такими как Dataproc DEFAULT_FS, являющийся HDFS, так что любые пути GCS, которые вы используете, должны полностью указывать полное имя gs://bucket/object.