Понять Spark: диспетчер кластеров, узлы мастера и драйвера

Ответ 1

  1. Cluster Manager - это долговременная служба, на каком узле он работает?

Диспетчер кластеров - это основной процесс в автономном режиме Spark. Его можно запустить где угодно, выполнив ./sbin/start-master.sh, в YARN это будет Resource Manager.

2. Возможно ли, что узел Master и Driver будут одной и той же машиной? Я предполагаю, что где-то должно быть правило, утверждающее, что эти два узла должны быть разными?

Master для каждого кластера, а Driver для каждого приложения. Для автономных кластеров/пряжи Spark в настоящее время поддерживает два режима развертывания.

1. В режиме клиента драйвер запускается в том же процессе, что и клиент, который отправляет приложение.
2. Однако в кластерном режиме для автономного режима драйвер запускается с одного из рабочих & для пряжи он запускается внутри главного узла приложения, и клиентский процесс завершается, как только он выполняет свою обязанность по отправке приложения, не дожидаясь его завершения.

Если приложение отправлено с --deploy-mode client на главном узле, и мастер и драйвер будут на одном узле. проверить развертывание приложения Spark через YARN

3. В случае сбоя узла драйвера, кто отвечает за повторный запуск приложения? И что именно будет? то есть, как будут задействованы главный узел, узлы Cluster Manager и Workers (если они это сделают) и в каком порядке?

В случае сбоя драйвера все задачи исполнителей будут убиты для этого отправленного/запущенного приложения зажигания.

4. В случае отказа главного узла, что именно произойдет и кто отвечает за восстановление после сбоя?

Ошибки главного узла обрабатываются двумя способами.

1. Резервные Мастера с ZooKeeper:

   Использование ZooKeeper для обеспечения выборов лидеров и некоторого государственного хранения, вы можете запустить несколько мастеров в вашем кластере, подключенных к одному Экземпляр ZooKeeper. Один будет избран "лидером", а другие - оставаться в режиме ожидания. Если текущий лидер умирает, другой Мастер будет избран, восстановить старое государство мастеров, а затем возобновить планирования. Весь процесс восстановления (со времени первого лидер идет вниз) должно занять от 1 до 2 минут. Обратите внимание, что это задержка влияет только на планирование новых приложений - приложений, которые были уже запущены во время перехода на другой ресурс без изменений. проверьте здесь для конфигураций

2. Восстановление одного узла с локальной файловой системой:

   ZooKeeper - лучший способ достичь высокого уровня производства наличие, но если вы хотите, чтобы иметь возможность перезапустить мастер, если он отключается, режим FILESYSTEM может позаботиться об этом. Когда приложения и работники регистрируются, им достаточно написано в каталог, чтобы они могли быть восстановлены после перезапуска мастера процесс. проверьте здесь для конф и более подробную информацию

Ответ 2

Диспетчер кластеров - это долговременная служба, на которой работает node?

Диспетчер кластеров - это просто менеджер ресурсов, т.е. ЦП и ОЗУ, которые SchedulerBackends использует для запуска задач. Диспетчер кластеров ничего не делает для Apache Spark, но предлагает ресурсы, и после запуска исполнителей Spark они напрямую взаимодействуют с драйвером для запуска задач.

Вы можете запустить автономный главный сервер, выполнив:

./sbin/start-master.sh

Может быть запущен где угодно.

Чтобы запустить приложение в Spark-кластере

./bin/spark-shell --master spark://IP:PORT

Возможно ли, что узлы Master и Driver будут одинаковыми? Я полагаю, что должно существовать правило, указывающее, что эти два узла должны быть разными?

В автономном режиме, когда вы запускаете свою машину, запускается JVM. Ваш SparK Master запустится, и на каждой машине начнется JVM Worker, и они будут регистрироваться у Spark Master. Оба являются диспетчерами ресурсов. Когда вы запускаете приложение или отправляете свое приложение в режиме кластера, драйвер запускается там, где вы делаете ssh, чтобы запустить это приложение. Driver JVM свяжется с SparK Master для исполнителей (Ex) и в автономном режиме Worker запустит Ex. Таким образом, Spark Master - для каждого кластера, а JVM драйвера - для каждого приложения.

В случае отказа драйвера node, кто несет ответственность за повторное запуск приложения? и что будет точно? например, как будут задействованы узлы Master node, Cluster Manager и Workers (если они есть) и в каком порядке?

Если Ex JVM выйдет из строя, рабочий JVM запустит Ex и когда Worker JVM плохой сбой, Spark Master запустит их. И с автономным кластером Spark с режимом развертывания кластера вы также можете указать - контролировать, чтобы убедиться, что драйвер автоматически перезагрузится, если он завершился неудачей с ненулевым кодом выхода. Spark Master запустит драйвер JVM

Аналогично предыдущему вопросу: в случае неудачи мастера node что произойдет точно и кто несет ответственность за восстановление после отказа?

отказ от мастера приведет к тому, что исполнители не смогут связаться с ним. Таким образом, они перестанут работать. Неспособность мастера заставит водителя не общаться с ним для статуса работы. Таким образом, ваше приложение не удастся. Исходные потери будут подтверждены работающими приложениями, но в противном случае они должны продолжать работать более или менее, так как ничего не произошло с двумя важными исключениями:

1. приложение не сможет закончить элегантным способом.

2.if Spark Master не работает. Работник попытается перерегистрировать WithMaster. Если это не удастся многократно, рабочие просто откажутся.

reregisterWithMaster() - перерегистрируется с активным мастером, с которым этот сотрудник общался. Если его нет, значит, этот рабочий все еще загружается и еще не установил соединение с мастером, и в этом случае мы должны перерегистрироваться со всеми мастерами.  Важно перерегистрироваться только с активным мастером во время сбоев. Worker безоговорочно пытается перерегистрироваться со всеми мастерами,  может возникнуть состояние гонки. Ужас, подробно описанный в SPARK-4592:

В этот момент долго работающие приложения не смогут продолжить обработку, но это все равно не должно приводить к немедленному сбою. Вместо этого приложение будет ждать, пока мастер вернется в режим онлайн (восстановление файловой системы) или контакт нового лидера (режим Zookeeper), и если это произойдет, он продолжит обработку.