У меня было довольно много проблем с параллельной настройкой EC2, когда я пытался сохранить локальный главный узел. Использование StarCluster для настройки пула очень помогло, но настоящее улучшение произошло при использовании StarCluster и< /em> наличие главного узла в частном пуле IP-адресов EC2.
StarCluster настраивает всю обработку ключей для всех узлов, а также всех используемых монтирований. Динамическое распределение узлов было невыполнимо, но если спотовые инстансы не будут использоваться в долгосрочной перспективе, а ваша стратегия назначения ставок не «сохраняет» ваши инстансы, динамическое распределение должно стать проблемой.
Некоторые другие извлеченные уроки:
- Создайте переменную, содержащую частные IP-адреса, для передачи в createCluster и экспортируйте ее, чтобы упростить перезапуск с теми же узлами.
- Запустите byobu на главном узле и настройте на нем ведение журнала сеансов R.
- Запуск сервера RStudio на ведущем узле иногда может быть очень полезным, но это должен быть другой AMI, чем ведомые узлы. :)
- Пусть управляющий сценарий разгружает файлы данных rda по пути, который удаленно отслеживается на наличие новых файлов, и автоматически загружает их.
- Используйте htop для мониторинга ведомых устройств, чтобы вы могли легко увидеть экземпляры и определить требования скрипта (память/процессор/масштабируемость).
- Используйте сценарии включения/отключения гиперпоточности процессора.
У меня была небольшая проблема с ведомыми соединениями и сериализацией/десериализацией, и я обнаружил, что одной из вещей был предел соединения, и что предел соединения необходимо уменьшить на количество узлов; и когда сценарий управления был остановлен, самым простым методом очистки был перезапуск основного сеанса R и использование сценария для уничтожения подчиненных процессов вместо ожидания тайм-аута.
Для настройки потребовалось немного работы, но, надеюсь, эти мысли помогут...
Хотя это было 8 месяцев назад, и StarCluster и R изменились, вот кое-что из того, как это было настроено... Вы найдете 90% этого в документации StarCluster.
- Настройте разделы .starcluster/config AWS и пары ключей на основе информации о безопасности из консоли AWS.
- Define the [smallcluster]
- key-name
- зона доступности
- Определите шаблон кластера, расширяющий [smallcluster]. Использование AMI на основе 64-битного AMI StarCluster HVM. Вместо создания новых общедоступных экземпляров AMI я просто сохранил настроенный экземпляр (со всеми необходимыми мне инструментами) и использовал его в качестве AMI.
Вот пример одного...
[cluster Rnodes2]
EXTENDS=smallcluster
MASTER_INSTANCE_TYPE = cc1.4xlarge
MASTER_IMAGE_ID= ami-7621f91f
NODE_INSTANCE_TYPE = cc2.8xlarge
NODE_IMAGE_ID= ami-7621f91f
CLUSTER_SIZE= 8
VOLUMES= rdata
PLUGINS= pkginstaller
SPOT_BID= 1.00
- Настройте общий том, здесь находятся журналы screen/byobu, выходные данные основной контрольной точки сценария .R, общие данные R и исходный код производственного пакета в реальном времени. Он отслеживался на наличие новых файлов в дочернем пути, называемом экспортом, поэтому, если кластер или сценарий управления умирает / искажается, максимальное количество записей будет потеряно, и их необходимо будет пересчитать.
После создания общего тома определение было простым:
[volume rdata]
VOLUME_ID = vol-1145497c
MOUNT_PATH = /rdata
Установщик пакетов, обеспечивающий наличие последних (и одинаковых) версий R на всех узлах.
[plugin pkginstaller]
setup_class = starcluster.plugins.pkginstaller.PackageInstaller
packages = r-base, r-base-dev, r-recommended
Наконец, права доступа для сервера ssh и RStudio. HTTPS через прокси было бы безопаснее, но поскольку RStudio использовался только для настройки скрипта управления...
[permission ssh]
# protocol can be: tcp, udp, or icmp
protocol = tcp
from_port = 22
to_port = 22
# [permission http]
protocol = tcp
from_port = 8787
to_port = 8787
Затем запустите кластер с помощью интерфейса StarCluster. Он обрабатывает все элементы управления доступом, системные имена, общие ресурсы и т. д. После запуска кластера я запустил сеанс ssh для каждого из своей локальной системы и запустил скрипт для остановки гиперпоточности:
#!/bin/sh
# disable hyperthreading
for cpunum in $(
cat /sys/devices/system/cpu/cpu*/topology/thread_siblings_list |
cut -s -d, -f2- | tr ',' '\n' | sort -un); do
echo 0 > /sys/devices/system/cpu/cpu$cpunum/online
done
затем запустил сеанс htop на каждом для мониторинга масштабируемости по экспортированным журналам контрольных точек.
Затем, войдя в мастер, запустил сеанс экрана (с тех пор я предпочитаю byobu) и запустил R из смонтированного тома StarCluster. Таким образом, когда кластер по какой-то причине останавливался, я мог легко настроить его снова, просто запустив R. В R первым делом нужно было создать переменную workers.list, используя имена nodeXXX, что было примерно так:
cluster.nodes <- c("localhost", paste("node00", 1:7, sep='' ) )
workers.list <- rep( cluster.nodes, 8 )
Затем я загрузил скрипт управления, вышел и сохранил рабочее пространство. Сценарий управления обрабатывал все выходные данные таблицы для экспорта и контрольных точек, а также вызовы с парной оболочкой для производственного пакета. Основная функция скрипта также принимала аргумент cpus, в котором размещался список рабочих процессов, который затем передавался как cores инициализатору кластера.
initialize.cluster <- function( cores )
{
if( exists( 'cl' ) ) stopCluster( cl )
print("Creating Cluster")
cl <- makePSOCKcluster( cores )
print("Cluster created.")
assign( 'cl', cl, envir=.GlobalEnv )
print( cl )
# All workers need to have the bounds generator functions...
clusterEvalQ( cl, require('scoreTarget') )
# All workers need to have the production script and package.
clusterExport( cl, varlist=list('RScoreTarget', 'scoreTarget'))
return ( cl )
}
После перезапуска сеанса R (после первоначального создания worker.list) был получен сценарий управления и вызвана основная функция. Вот оно. При такой настройке, если кластер когда-нибудь остановится, я просто выйду из rsession на основном хосте; остановите подчиненные процессы через htop на каждом из подчиненных устройств и запустите снова.
Вот пример в действии:
R
R version 2.15.0 (2012-03-30)
Copyright (C) 2012 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
Platform: x86_64-pc-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
[Previously saved workspace restored]
> source('/rdata/buildSatisfactionRangeTable.R')
Loading required package: data.table
data.table 1.7.7 For help type: help("data.table")
Loading required package: parallel
Loading required package: scoreTarget
Loading required package: Rcpp
> ls()
[1] "build.satisfaction.range.table" "initialize.cluster"
[3] "initialize.table" "parallel.choices.threshold"
[5] "rolled.lower" "rolled.upper"
[7] "RScoreTarget" "satisfaction.range.table"
[9] "satisfaction.search.targets" "search.range.bound.offsets"
[11] "search.range.bounds" "search.range.center"
[13] "Search.Satisfaction.Range" "update.bound.offset"
[15] "workers.list"
> workers.list
[1] "localhost" "localhost" "localhost" "localhost" "localhost" "localhost"
[7] "localhost" "localhost" "node001" "node002" "node003" "node004"
[13] "node005" "node006" "node007" "node001" "node002" "node003"
[19] "node004" "node005" "node006" "node007" "node001" "node002"
[25] "node003" "node004" "node005" "node006" "node007" "node001"
[31] "node002" "node003" "node004" "node005" "node006" "node007"
[37] "node001" "node002" "node003" "node004" "node005" "node006"
[43] "node007" "node001" "node002" "node003" "node004" "node005"
[49] "node006" "node007" "node001" "node002" "node003" "node004"
[55] "node005" "node006" "node007" "node001" "node002" "node003"
[61] "node004" "node005" "node006" "node007" "node001" "node002"
[67] "node003" "node004" "node005" "node006" "node007" "node001"
[73] "node002" "node003" "node004" "node005" "node006" "node007"
[79] "node001" "node002" "node003" "node004" "node005" "node006"
[85] "node007" "node001" "node002" "node003" "node004" "node005"
[91] "node006" "node007" "node001" "node002" "node003" "node004"
[97] "node005" "node006" "node007" "node001" "node002" "node003"
[103] "node004" "node005" "node006" "node007" "node001" "node002"
[109] "node003" "node004" "node005" "node006" "node007" "node001"
[115] "node002" "node003" "node004" "node005" "node006" "node007"
> build.satisfaction.range.table(500000, FALSE, workers.list )
[1] "Creating Cluster"
[1] "Cluster created."
socket cluster with 120 nodes on hosts ‘localhost’, ‘node001’, ‘node002’, ‘node003’, ‘node004’, ‘node005’, ‘node006’, ‘node007’
Parallel threshold set to: 11000
Starting at: 2 running to: 5e+05 :: Sat Apr 14 22:21:05 2012
Если вы дочитали до сюда, то вам может быть интересно узнать, что я протестировал каждую настройку кластера, которую мог (включая openMPI), и обнаружил, что разницы в скорости нет, возможно, это потому, что мои расчеты были связаны с ЦП, возможно, нет .
Кроме того, не сдавайтесь, даже если начать работу с высокопроизводительными вычислениями может быть непросто. Это может стоить того. Я бы все еще ждал, чтобы завершить первые 100 000 итераций вычислений, которые я выполнял, если бы я застрял с наивной реализацией в base-R на обычной рабочей станции (ну, не совсем так, потому что я бы никогда не застрял с R :D). В случае с кластером менее чем за неделю было выполнено 384 000 итераций. Полностью стоит потраченного времени (а его ушло много) на настройку.
person
Thell
schedule
27.11.2012
