Никогда не строил большой кластер hadoop&spark.

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

  1. Некоторая машина никогда не может быть sshable, например «Вт, 8 декабря, 13:45:14 PST 2015: 'hadoop-w-5' еще не sshable (255); спящий"

  2. Некоторые узлы выходят из строя с ошибкой «Exited 100» при развертывании рабочих узлов Spark, например «Вт, 8 декабря, 15:28:31 PST 2015: Exited 100: gcloud --project=cs-bwamem --quiet --verbosity=info вычислить 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-flag=-oServerAliveInterval=60 --ssh-flag=-oServerAliveCountMax=3 --ssh-flag=-oConnectTimeout=30 --zone=us-central1-f"

В лог-файле написано:

hadoop-w-40: ==> deploy-core-setup_deploy.stderr ‹==

hadoop-w-40: dpkg-query: пакет «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 $BUCKET \ --force \ --machine_type n1-highmem-32 \ --master_machine_type n1-highmem-32 \ --num_workers 64 \ --project $PROJECT \ --upload_files ${JAR_FILE } \ --env_var_files hadoop2_env.sh,extensions/spark/spark_env.sh \ развернуть


google-hadoop
person Parthus    schedule 08.12.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Подводя итог некоторой информации, полученной в ходе отдельного обсуждения по электронной почте, можно сказать, что по мере изменения сопоставления 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 интерфейс командной строки для развертывания кластера, отправлять задания и далее управлять/удалять кластеры без необходимости запоминать флаги bdutil или отслеживать, какие кластеры есть на клиентском компьютере. Вы можете использовать SSH в кластерах Dataproc и использовать их в основном так же, как кластеры bdutil, с некоторыми небольшими отличиями, например, Dataproc DEFAULT_FS является HDFS, поэтому любые используемые вами пути GCS должны полностью указывать полное gs://bucket/object имя.

person Dennis Huo    schedule 10.12.2015