Понимание Spark: диспетчер кластеров, главный и драйверный узлы
Прочитав этот вопрос, я хотел бы задать дополнительные вопросы:
- Cluster Manager - это долговременная служба, на каком узле он работает?
- Возможно ли, что узел Master и Driver будут одной и той же машиной? Я предполагаю, что где-то должно быть правило, утверждающее, что эти два узла должны быть разными?
- В случае сбоя узла драйвера, кто отвечает за повторный запуск приложения? и что конкретно будет? т. е. как будут задействованы главный узел, кластерный менеджер и рабочие узлы (если они это сделают) и в каком порядке?
- Аналогично предыдущему вопросу: в случае отказа главного узла, что именно произойдет, и кто отвечает за восстановление после сбоя?
2 ответа
1. Cluster Manager - это долговременная служба, на каком узле он работает?
Диспетчер кластеров - это основной процесс в автономном режиме Spark. Это можно запустить где угодно ./sbin/start-master.sh В YARN это будет менеджер ресурсов.
2. Возможно ли, что узел Master и Driver будут одной и той же машиной? Я предполагаю, что где-то должно быть правило, утверждающее, что эти два узла должны быть разными?
Master на кластер и Driver по заявке. Для автономных кластеров / пряжи Spark в настоящее время поддерживает два режима развертывания.
- В режиме клиента драйвер запускается в том же процессе, что и клиент, отправляющий приложение.
- В кластерном режиме, однако, для автономного, драйвер запускается с одного из рабочих и для пряжи, он запускается внутри главного узла приложения, и клиентский процесс завершается, как только он выполняет свою обязанность по отправке приложения, не ожидая приложения заканчивать.
Если заявка подана с --deploy-mode client в главном узле мастер и драйвер будут находиться на одном узле. проверить развертывание приложения Spark через YARN
3. В случае сбоя узла драйвера, кто отвечает за перезапуск приложения? и что конкретно будет? т. е. как будут задействованы главный узел, кластерный менеджер и рабочие узлы (если они это сделают) и в каком порядке?
В случае сбоя драйвера все задачи исполнителей будут уничтожены для этого отправленного / запущенного приложения зажигания.
4. В случае отказа главного узла, что именно произойдет и кто отвечает за восстановление после сбоя?
Сбои главного узла обрабатываются двумя способами.
Резервные Мастера с ZooKeeper:
Используя ZooKeeper для обеспечения выбора лидера и некоторого хранилища состояний, вы можете запустить несколько Мастеров в своем кластере, подключенных к одному и тому же экземпляру ZooKeeper. Один будет избран "лидером", а остальные останутся в режиме ожидания. Если текущий лидер умрет, будет выбран другой Мастер, восстановит состояние старого Мастера, а затем возобновит планирование. Весь процесс восстановления (с момента выхода первого лидера из строя) должен занять от 1 до 2 минут. Обратите внимание, что эта задержка влияет только на планирование новых приложений - приложения, которые уже работали во время восстановления после отказа Master, не затрагиваются. проверьте здесь для конфигурации
Восстановление одного узла с локальной файловой системой:
ZooKeeper - лучший способ обеспечить высокую доступность на уровне производства, но если вы просто хотите иметь возможность перезапустить мастер, если он выйдет из строя, режим FILESYSTEM может позаботиться об этом. Когда приложения и рабочие регистрируются, они имеют достаточно состояния, записанного в предоставленный каталог, чтобы их можно было восстановить после перезапуска главного процесса. проверьте здесь для конф и более подробную информацию
Cluster Manager - это долговременная служба, на каком узле он работает?
Диспетчер кластеров - это просто диспетчер ресурсов, то есть процессоров и оперативной памяти, которые SchedulerBackends использует для запуска задач. Менеджер кластера больше ничего не делает с Apache Spark, но предлагает ресурсы, и после запуска исполнителей Spark они напрямую связываются с драйвером для запуска задач.
Вы можете запустить автономный мастер-сервер, выполнив:
./sbin/start-master.sh
Может быть запущен где угодно.
Чтобы запустить приложение в кластере Spark
./bin/spark-shell --master spark://IP:PORT
Возможно ли, что узел Master и Driver будут одной и той же машиной? Я предполагаю, что где-то должно быть правило, утверждающее, что эти два узла должны быть разными?
В автономном режиме, когда вы запускаете вашу машину, запускается определенная JVM. Запускается ваш SparK Master, и на каждой машине запускается рабочая JVM, и они регистрируются в Spark Master. Оба являются диспетчером ресурсов. Когда вы запускаете приложение или отправляете его в кластерном режиме, драйвер запускается везде, где вы запускаете ssh для запуска этого приложения. Драйвер JVM свяжется с SparK Master для исполнителей (Ex) и в автономном режиме Worker запустит Ex. Таким образом, Spark Master для каждого кластера, а драйвер JVM для каждого приложения.
В случае сбоя узла драйвера, кто отвечает за повторный запуск приложения? и что конкретно будет? т. е. как будут задействованы главный узел, кластерный менеджер и рабочие узлы (если они это сделают) и в каком порядке?
Если Ex JVM выйдет из строя, Worker JVM запустит Ex, а когда Worker JVM выйдет из строя, Spark Master запустит их. А в автономном кластере Spark с режимом развертывания кластера вы также можете указать --supervise, чтобы убедиться, что драйвер автоматически перезапускается в случае сбоя с ненулевым кодом выхода.Spark Master запустит драйвер JVM
Аналогично предыдущему вопросу: в случае отказа главного узла, что именно произойдет, и кто отвечает за восстановление после сбоя?
отказ мастера приведет к тому, что исполнители не смогут общаться с ним. Итак, они перестанут работать. Отказ мастера сделает водителя неспособным связаться с ним для статуса работы. Итак, ваше приложение не удастся. Основные потери будут подтверждены работающими приложениями, но в противном случае они должны продолжать работать более или менее, как будто ничего не произошло с двумя важными исключениями:
1. приложение не сможет закончить элегантным способом.
2.Если Spark Master не работает Рабочий попытается перерегистрировать Master. Если это не удастся несколько раз, рабочие просто сдадутся.
reregisterWithMaster () - Перерегистрация с активным мастером, с которым этот работник общался. Если его нет, то это означает, что этот работник все еще загружается и еще не установил соединение с мастером, и в этом случае мы должны перерегистрировать всех мастеров. Важно перерегистрировать только у активного мастера во время сбоев. Работник безоговорочно пытается перерегистрироваться у всех мастеров, может возникнуть состояние гонки. Ошибка подробно описана в SPARK-4592:
В этот момент долго работающие приложения не смогут продолжить обработку, но это не должно привести к немедленному отказу. Вместо этого приложение будет ждать, пока мастер вернется в оперативный режим (восстановление файловой системы) или контакт нового лидера (режим Zookeeper), и, если это произойдет, продолжит обработку.