Кластер CycleCloud GridEngine

Open Grid Scheduler (Grid Engine) можно легко активировать в кластере Azure CycleCloud, изменив значение "run_list" в определении кластера. Кластер Grid Engine состоит из двух основных компонентов. Первым является главный узел, который предоставляет общую файловую систему, в которой выполняется программное обеспечение Grid Engine. Второй — это набор узлов выполнения, которые подключают общую файловую систему и выполняют отправленные задания. Например, простой фрагмент шаблона кластера Grid Engine может выглядеть следующим образом:

[cluster grid-engine]

[[node master]]
    ImageName = cycle.image.centos7
    MachineType = Standard_A4 # 8 cores

    [[[configuration]]]
    run_list = role[sge_master_role]

[[nodearray execute]]
    ImageName = cycle.image.centos7
    MachineType = Standard_A1  # 1 core

    [[[configuration]]]
    run_list = role[sge_execute_role]

Импорт и запуск кластера с определением в CycleCloud приводит к одному главному узлу. Узлы execute можно добавить в кластер с помощью cyclecloud add_node команды. Например, чтобы добавить еще 10 исполнительных узлов:

cyclecloud add_node grid-engine -t execute -c 10

Диспетчер задач 'Grid Engine' с функцией автомасштабирования

Azure CycleCloud поддерживает автомасштабирование для обработчика сетки. Это означает, что программное обеспечение постоянно отслеживает состояние очереди и автоматически включает или отключает узлы по мере необходимости, чтобы эффективно выполнять рабочую нагрузку с точки зрения времени и затрат. Вы можете включить автомасштабирование для ядра Grid, добавив Autoscale = true в определение кластера:

[cluster grid-engine]
Autoscale = True

По умолчанию все задания, отправленные в очередь Grid Engine, выполняются на компьютерах типа 'исполняющий'. Эти машины, заданные массивом узлов с именем Execute. Вас не ограничивают использованием имени 'execute', и вы не ограничены одним типом конфигурации машины для выполнения заданий и автомасштабирования.

Например, распространенный сценарий включает кластер с двумя разными определениями узлов. Он предназначен для выполнения "обычных" заданий, использующих стандартные ЦП. Другой предназначен для заданий, требующих компьютеров с поддержкой GPU. В этом случае необходимо независимо масштабировать очередь по обычным заданиям и заданиям GPU, чтобы убедиться, что у вас есть соответствующее количество машин каждого типа для обработки очереди заданий. Пример определения может быть примерно следующим:

[cluster grid-engine]
Autoscale = True

[[node master]]
    ImageName = cycle.image.centos7
    MachineType = Standard_A3  # 4 cores

    [[[configuration]]]
    run_list = role[sge_master_role]

[[nodearray execute]]
    ImageName = cycle.image.centos7
    MachineType = Standard_A4  # 8 cores

    [[[configuration]]]
    run_list = role[sge_execute_role]

[[nodearray gpu]]
    MachineType = Standard_NV12 # 2 GPUs
    ImageName = cycle.image.centos7

    # Set the number of cores to the number of GPUs for autoscaling purposes
    CoreCount = 2  

    [[[configuration]]]
    run_list = role[sge_execute_role]
    gridengine.slot_type = gpu
    gridengine.slots = 2

В приведенном примере теперь есть два массива узлов: один — это стандартный массив узлов выполнения, второй — массив узлов под названием 'gpu', который предоставляет тип машины с двумя GPU NVIDIA (Standard_NV12 в Azure). Кроме того, обратите внимание, что в разделе конфигурации есть два новых элемента, кроме рецепта csge:sgeexec. Добавление gridengine.slot_type = gpu сообщает планировщику ядра Grid, что эти узлы должны называться узлами GPU, поэтому должны выполнять только задания gpu. Имя GPU является произвольным, но имя, описывающее узел, является наиболее полезным. Установите gridengine.slots = 2, чтобы сообщить программному обеспечению, что данный тип узла может выполнять только два задания одновременно, поскольку у Standard_NV12 есть всего 2 графических процессора.

По умолчанию Grid Engine назначает количество слотов на узел на основе количества центральных процессоров системы. В этом случае поведение по умолчанию может привести к тому, что слишком много заданий выполняется одновременно на одном узле. В приведенном примере CoreCount=2 устанавливается на массиве узлов, чтобы соответствовать количеству графических процессоров, доступных для MachineType, что позволяет CycleCloud правильно масштабировать этот массив по количеству графических процессоров и процессоров.

Вы можете проверить количество слотов и тип слота ваших компьютеров, выполнив команду:

    -bash-4.1# qstat -F slot_type
    queuename                      qtype resv/used/tot. load_avg arch          states
    ---------------------------------------------------------------------------------
    all.q@ip-0A000404              BIP   0/0/4          0.17     linux-x64
        hf:slot_type=execute
    ---------------------------------------------------------------------------------
    all.q@ip-0A000405              BIP   0/0/2          2.18     linux-x64
        hf:slot_type=gpu
    ---------------------------------------------------------------------------------
    all.q@ip-0A000406              BIP   0/0/4          0.25     linux-x64

Обратите внимание, что для каждой указанной "slot_type" есть по одной: "execute" и "gpu". Типы слотов настраиваются по отдельности, а количество слотов для слота 'execute' составляет 4, что соответствует числу процессоров на компьютере. Количество слотов для типа слота gpu — 2, указанное в шаблоне конфигурации кластера. Третий компьютер — главный узел, который не выполняет задания.

Расширенное использование Grid Engine

Эти параметры конфигурации обеспечивают расширенную настройку узлов и массивов узлов. Например, если для заданий требуется определенный объем памяти, например 10 ГБ, можно определить узел execute, который запускает компьютеры с 60 ГБ памяти, а затем добавить в параметры gridengine.slots = 6 конфигурации, чтобы обеспечить одновременное выполнение только 6 заданий на этом узле (убедитесь, что каждое задание имеет не менее 10 ГБ памяти для работы).

Сгруппированные узлы в сетевой системе

При отправке параллельного задания в диспетчер сетки, поведение автомасштабирования по умолчанию, используемое в CycleCloud, заключается в обработке каждого задания MPI как группового запроса на узлы. Сгруппированные узлы тесно связаны и идеально подходят для рабочих процессов MPI.

При присоединении набора группированных узлов к кластеру Grid Engine идентификатор группы каждого узла используется в качестве значения сложного значения affinity_group. Требование указать affinity_group для заданий позволяет планировщику Grid Engine гарантировать, что задания выполняются только на компьютерах, которые находятся в одной группе.

Автоматизация CycleCloud автоматически запрашивает сгруппированные узлы и назначает их доступным группам сходства при обнаружении параллельных заданий.

Отправка заданий на Grid Engine

Наиболее универсальным способом отправки заданий в планировщик ядра Grid является команда:

qsub my_job.sh

Эта команда отправляет задание, которое выполняется на узле типа execute, то есть узел, определенный nodearray "execute". Чтобы запустить задание на массиве узлов другого типа, например, на узле типа 'gpu', мы изменим нашу заявку.

qsub -l slot_type=gpu my_gpu_job.sh

Эта команда гарантирует, что задание выполняется только на типе слота 'GPU'.

Если slot_type опущен, execute автоматически назначает задание. Пользователь может изменить механизм, который автоматически назначает slot_type рабочим заданиям. Скрипт Python, расположенный в файле /opt/cycle/jetpack/config/autoscale.py , можно создать, который должен определить одну функцию "sge_job_handler". Эта функция получает представление задания словаря, аналогично выходным данным qstat -j JOB_ID команды и должно возвращать словарь жестких ресурсов, которые необходимо обновить для задания.

Например, следующий скрипт назначает задание типу слота 'gpu', если имя задания содержит буквы 'gpu'. Пользователям разрешено автоматически отправлять задания, не изменяя их параметры, при этом обеспечивая выполнение и правильное автомасштабирование на подходящих узлах.

#!/usr/env python
#
# File: /opt/cycle/jetpack/config/autoscale.py
#
def sge_job_handler(job):
  # The 'job' parameter is a dictionary containing the data present in a 'qstat -j JOB_ID':
    hard_resources = {'slot_type': 'execute', 'affinity_group' : 'default' }

  # Don't modify anything if the job already has a slot type
  # You could modify the slot type at runtime by not checking this
  if 'hard_resources' in job and 'slot_type' in job['hard_resources']:
      return hard_resources

  # If the job's script name contains the string 'gpu' then it's assumed to be a GPU job.
  # Return a dictionary containing the new job_slot requirement to be updated.
  # For example: 'big_data_gpu.sh' would be run on a 'gpu' node.
  if job['job_name'].find('gpu') != -1:
      hard_resources {'slot_type': 'gpu'}
  else:
      return hard_resources

Переданный параметр job — это словарь, содержащий данные в вызове qstat -j JOB_ID :

{
    "job_number": 5,
    "job_name": "test.sh",
    "script_file": "test.sh",
    "account": "sge",
    "owner": "cluster.user",
    "uid": 100,
    "group": "cluster.user",
    "gid": 200,
    "submission_time": "2013-10-09T09:09:09",
    "job_args": ['arg1', 'arg2', 'arg3'],
    "hard_resources": {
       'mem_free': '15G',
       'slot_type': 'execute'
    }
}

Эту функцию сценариев можно использовать для автоматического назначения slot_type на основе любого параметра задания, определенного, например аргументов, требований к ресурсам, таких как память или отправляющего пользователя.

Предположим, что вы отправляете 5 заданий для каждого 'slot_type':

qsub -t 1:5 gpu_job.sh
qsub -t 1:5 normal_job.sh

Теперь в очереди будет 10 заданий. Согласно определенному скрипту пять заданий с gpu в имени будут автоматически настроены только на узлах "slot_type=gpu". Механизм автомасштабирования CycleCloud обнаружит, что есть 5 заданий gpu и 5 заданий выполнения. Так как массив узлов 'gpu' определяется как имеющий 2 слота на узел, CycleCloud должен будет запустить 3 таких узла (5/2=2,5 округляется до 3).

Есть 5 обычных заданий, так как тип компьютера для узла 'execute' имеет по 4 ЦП, CycleCloud запустит 2 из этих узлов для обработки заданий (5/4=1,25 округлено до 2). После краткого периода запуска только что запущенные узлы загружаются и настраиваются сами. После готовности все 10 заданий выполняются до завершения. Затем 5 узлов автоматически отключаются до начала другого цикла выставления счетов у поставщика облачных услуг.

Предполагается, что работа имеет длительность одного часа. Если среда выполнения задания известна, алгоритм автомасштабирования может воспользоваться этой информацией. Уведомьте систему автомасштабирования о ожидаемом времени выполнения задания, добавив эту информацию в контекст задания. Следующий пример задает время выполнения задания при автомасштабировании, равное 10 минутам.

qsub -ac average_runtime=10 job_with_duration_of_10m.sh

Справочник по конфигурации для системы управления сетевыми вычислениями Grid Engine

Ниже приведены параметры конфигурации ядра Grid Engine, которые можно переключать для настройки функциональных возможностей.

CycleCloud поддерживает стандартный набор атрибутов автоостановки во всех планировщиках.

Известные проблемы

• qsh команда для интерактивного сеанса не работает. Используйте qrsh в качестве альтернативы.
• Автомасштабирование не учитывает сложный exclusive=1 комплекс, что может привести к тому, что начнется меньше узлов, чем ожидалось.

Эта страница касается возможностей и конфигурации использования (Altair) GridEngine с CycleCloud.

Настройка ресурсов

Приложение cyclecloud-gridengine сопоставляет ресурсы sge с облачными ресурсами Azure, чтобы обеспечить широкие средства автомасштабирования и конфигурации кластера. Приложение развертывается автоматически для кластеров, созданных с помощью пользовательского интерфейса CycleCloud, или его можно установить на любом узле администратора GridEngine в существующем кластере.

Установка или обновление «cyclecloud-gridengine»

Пакет cyclecloud-gridengine доступен в GitHub в качестве релизного артефакта. Установка и обновление соответствуют тому же процессу. Приложению требуется python3 с virtualenv.

tar xzf cyclecloud-gridengine-pkg-*.tar.gz
cd cyclecloud-gridengine
./install.sh

Важные файлы

Приложение анализирует конфигурацию sge при каждом запуске — задания, очереди, комплексы. Сведения предоставляются в stderr и stdout команды, а также в файл журнала, на конфигурируемых уровнях. Все команды управления GridEngine с аргументами также записываются в файл.

Очереди SGE, группы хостов и параллельные среды

Программа автомасштабирования cyclecloud-gridengine, azge, добавляет узлы в кластер в соответствии с конфигурацией кластера. Операции автомасштабирования выполняют следующие действия.

1. Ознакомьтесь с запросом ресурса для задания и найдите подходящую виртуальную машину для запуска.
2. Запустите виртуальную машину и дождитесь его готовности
3. Чтение конфигурации очереди и параллельной среды из задания
4. В зависимости от очереди или pe назначьте хост соответствующей группе хостов.
5. Добавление узла в кластер и в любую другую очередь, содержащую группу узлов

Рассмотрим следующее определение очереди для очереди с именем short.q

hostlist              @allhosts @mpihg01 @mpihg02 @lowprio 
...
seq_no                10000,[@lowprio=10],[@mpihg01=100],[@mpihg02=200]
pe_list               NONE,[@mpihg01=mpi01], \
                      [@mpihg02=mpi02]

Отправка задания через qsub -q short.q -pe mpi02 12 my-script.sh запускает, как минимум, одну виртуальную машину. При добавлении кластера он присоединяется к @mpihg02 хост-группе, так как это группа узлов, доступная как в очереди, так и в параллельной среде. Он также присоединяется к @allhosts, специальной группе хостов.

Если вы отправляете задание с qsub -q short.q my-script.sh и не указываете параллельную среду PE, то результирующая виртуальная машина присоединяется к группам хостов @allhosts и @lowpriority, которые связаны с очередью, не назначенной ни одной PE.

Наконец, задание, отправленное с помощью qsub -q short.q -pe mpi0* 12 my-script.sh, приводит к добавлению виртуальной машины в @mpihg01 или @mpihg02 в зависимости от прогнозов выделения CycleCloud.

Параллельные среды неявно совпадают с группой размещения cyclecloud. Виртуальные машины в PE ограничены рамками той же сети. Если вы хотите использовать PE, который не хранит группу размещения, используйте autoscale.json, чтобы исключить.

Здесь мы откажемся от групп размещения для создать pe:

"gridengine": {
    "pes": {
      "make": {
        "requires_placement_groups": false
      }
    },

Группы размещения CycleCloud

Группы размещения CycleCloud соответствуют один к одному с Azure VMSS с SinglePlacementGroup — виртуальные машины в группе размещения используют Infiniband Fabric совместно только с другими виртуальными машинами в этой же группе размещения. Для интуитивного сохранения этих силосов группы размещения сопоставляются 1:1 с параллельной средой GridEngine.

Указание параллельной вычислительной среды для задания ограничивает выполнение задания в группе размещения серверов с помощью алгоритма умного назначения группы узлов. Это поведение можно отключить с помощью соответствующей конфигурации в autoscale.json: "required_placement_groups" : false.

Настройка автомасштабирования

Этот подключаемый модуль автоматически масштабирует сетку в соответствии с требованиями рабочей нагрузки. Файл конфигурацииautoscale.json определяет поведение автомасштабирования ядра Grid Engine.

• Настройка сведений о подключении cyclecloud
• Установка таймера завершения для неактивных узлов
• Поддерживается многомерное автомасштабирование. Можно настроить атрибуты, используемые в упаковке заданий, например слоты или память.
• Зарегистрируйте очереди, параллельные среды и группы узлов для управления

Программа автомасштабирования рассматривает только соответствующий ресурс

Другой ресурс автоматического масштабирования

По умолчанию задания запрашивают множество слотов, а кластер масштабируется на основе этих запросов.

Предположим, что мы хотим автомасштабировать по запросу ресурса задания m_mem_free.

1. Добавьте m_mem_free к gridengine.relevant_resources в autoscale.json
2. Свяжите m_mem_free с ресурсом памяти уровня узла в autoscale.json

Эти атрибуты можно ссылаться в node.* качестве значения в _default/ресурсах.

Другие атрибуты находятся в node.resources.* пространстве имен, например node.resources.

Сопоставление ресурсов

Существуют также математические вычисления, доступные для default_resources. Уменьшите слоты в определенном массиве узлов на два и добавьте ресурс Docker ко всем узлам:

    "default_resources": [
    {
      "select": {"node.nodearray": "beegfs"},
      "name": "slots",
      "value": "node.vcpu_count",
      "subtract": 2
    },
    {
      "select": {},
      "name": "docker",
      "value": true
    },

Сопоставление виртуальных ЦП узла с сложными слотами и memmbmem_free обычно используется по умолчанию. Первая ассоциация требуется.

    "default_resources": [
    {
      "select": {},
      "name": "slots",
      "value": "node.vcpu_count"
    },
    {
      "select": {},
      "name": "mem_free",
      "value": "node.resources.memmb"
    }
 ],

Если комплекс имеет сокращение, не равное всему значению, определите оба в default_resources, где physical_cpu — это имя комплекса.

"default_resources": [
    {
      "select": {},
      "name": "physical_cpu",
      "value": "node.pcpu_count"
    },
    {
      "select": {},
      "name": "pcpu",
      "value": "node.resources.physical_cpu"
    }
]

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

    "default_resources": [
    {
      "select": {"node.nodearray": "FPGA"},
      "name": "slots",
      "value": "1",
    },
    {
      "select": {},
      "name": "slots",
      "value": "node.vcpu_count"
    },
]

Группы узлов

Автомасштабирование CycleCloud, при попытке удовлетворить требования задания, сопоставляет узлы с соответствующей хостгруппой. Очереди, параллельные среды и комплексы все рассматриваются. Основная часть логики заключается в сопоставлении подходящего контейнера cyclecloud (и количества узлов) с соответствующей группой хостов sge.

Для задания, отправленного как: qsub -q "cloud.q" -l "m_mem_free=4g" -pe "mpi*" 48 ./myjob.sh

CycleCloud ищет и получает пересечение групп хостов, которые:

1. Включаются в pe_list для cloud.q и соответствуют имени pe, например pe_list [@allhosts=mpislots],[@hpc1=mpi].
2. Укажите достаточные ресурсы и квоту подписки, чтобы предоставить все ресурсы задания.
3. Конфигурация ограничений для групп узлов не фильтрует их.

Несколько групп хостов могут соответствовать этим требованиям. В этом случае система должна решить, какой из них следует использовать. Существует три способа разрешения конфликтов членства в группе хостов:

1. Настройте очереди, чтобы избежать неоднозначности.
2. Добавьте ограничения для autoscale.json.
3. Позвольте CycleCloud выбрать подходящие группы узлов в порядке, упорядоченном по имени, изменив конфигурацию планировщика weight_queue_host_sort < weight_queue_seqno.
4. Установите seq_no 10000,[@hostgroup1=100],[@hostgroup2=200] в конфигурации очереди, чтобы указать предпочтение группы узлов.

Ограничения группы узлов

Если очередь или xproject определяет несколько групп хостов, любая из этих групп может потенциально получать новые узлы. Чтобы контролировать, какие узлы имеют право на наличие очередей, можно применить ограничения группы узлов на основе свойств узла.

"gridengine": {
    "hostgroups": {
      "@mpi": {
        "constraints": {
          "node.vm_size": "Standard_H44rs"
        }
      },
      "@amd-mem": {
        "constraints" : { 
            "node.vm_size": "Standard_D2_v3",
            "node.nodearray": "hpc" 
            }
        },
    }
  }

ПОДСКАЗКА. Проверьте все доступные свойства узла по azge buckets.

azge

Этот пакет поставляется с командной строкой , azge. Эта программа используется для автомасштабирования и разделяет все подпроцессы автомасштабирования на отдельные компоненты. Необходимо, чтобы эти команды могли быть вызваны из заданных переменных среды GridEngine. Вы должны иметь возможность вызывать qconf и qsub из того же профиля, где вызывается azge.

При изменении конфигураций планировщика (qconf) или автомасштабирования (autoscale.json) или даже настройке в первый раз azge можно использовать для проверки поведения автомасштабирования соответствует ожиданиям. В качестве root-пользователя можно выполнять следующие операции. Чтобы понять, как работает автомасштабирование, важно ознакомиться с этими понятиями.

1. Запустите azge validate, чтобы проверить конфигурации на известные проблемы.
2. Запустите azge buckets, чтобы проверить ресурсы, предлагаемые кластером CycleCloud.
3. Запустите azge jobs, чтобы проверить подробности задания в очереди.
4. Выполните azge demand задание для сопоставления сегментов. Затем проверьте, какие задания соответствуют контейнерам и группам узлов.
5. Запустите azge autoscale , чтобы запустить процесс выделения узлов или добавить узлы, готовые к присоединению.

После выполнения команд включите непрерывное автомасштабирование, добавив azge autoscale команду в корневой crontab. Убедитесь, что необходимо заранее создать переменные среды GridEngine.

* * * * * . $SGE_ROOT/common/settings.sh && /usr/local/bin/azge autoscale -c /opt/cycle/gridengine/autoscale.json

Создание гибридного кластера

CycleCloud поддерживает сценарий автоматического увеличения облачных ресурсов. Базовая конфигурация предполагает, что $SGE_ROOT каталог доступен для облачных узлов. Это предположение можно ослабить, задав gridengine.shared.spool = false, gridengine.shared.bin = false и установив GridEngine на локальной машине.

В простом случае следует указать файловую систему, которую могут подключать исполняющие узлы. Эта файловая система должна включать ... каталог и настройка подключения в необязательных параметрах. При освобождении зависимостей sched и общих каталогов можно завершить работу узла планировщика, который является частью кластера по умолчанию, и использовать конфигурации из внешней файловой системы.

1. Создайте новый кластер GridEngine.
2. Отключите прокси-сервер возврата.
3. Замените /sched и /shared внешними файловыми системами.
4. Сохраните кластер.
5. Удалите узел планировщика в качестве действия в пользовательском интерфейсе.
6. Запустите кластер, изначально не запускайте узлы.
7. Настройте cyclecloud-gridengine с autoscale.json для использования нового кластера.

Использование Univa Grid Engine в CycleCloud

Проект CycleCloud для GridEngine использует sge-2011.11 по умолчанию. Вы можете использовать собственные установщики Altair GridEngine в соответствии с лицензионным соглашением Altair. В этом разделе описано, как использовать Altair GridEngine с проектом CycleCloud GridEngine.

Предпосылки

В этом примере используется демонстрационная версия 8.6.1, но поддерживаются все версии GE, превышающие 8.4.0.

1. Пользователи должны предоставлять двоичные файлы UGE

• ge-8.6.x-bin-lx-amd64.tar.gz
• ge-8.6.x-common.tar.gz

2. Интерфейс командной строки CycleCloud должен быть настроен. Документация доступна здесь

Копирование двоичных файлов в облачное хранилище

Дополнительная версия AGE (8.6.7-demo) распространяется с помощью CycleCloud. Чтобы использовать другую версию, отправьте двоичные файлы в учетную запись хранения, используемую CycleCloud.

$ azcopy cp ge-8.6.12-bin-lx-amd64.tar.gz https://<storage-account-name>.blob.core.windows.net/cyclecloud/gridengine/blobs/
$ azcopy cp ge-8.6.12-common.tar.gz https://<storage-account-name>.blob.core.windows.net/cyclecloud/gridengine/blobs/

Изменение конфигураций на шаблон кластера

Создайте локальную копию шаблона GridEngine и измените ее, чтобы использовать установщики UGE вместо стандартного.

wget https://raw.githubusercontent.com/Azure/cyclecloud-gridengine/master/templates/gridengine.txt

В файле gridengine.txt найдите первое [[[configuration]]] вхождение и вставьте текст, чтобы соответствовать следующему фрагменту. Файл не зависит от отступов.

[[[configuration gridengine]]]
    make = ge
    version = 8.6.12-demo
    root = /sched/ge/ge-8.6.12-demo
    cell = "default"
    sge_qmaster_port = "537"
    sge_execd_port = "538"
    sge_cluster_name = "grid1"
    gid_range = "20000-20100"
    qmaster_spool_dir = "/sched/ge/ge-8.6.12-demo/default/spool/qmaster" 
    execd_spool_dir = "/sched/ge/ge-8.6.12-demo/default/spool"
    spooling_method = "berkeleydb"
    shadow_host = ""
    admin_mail = ""
    idle_timeout = 300

    managed_fs = true
    shared.bin = true

    ignore_fqdn = true
    group.name = "sgeadmin"
    group.gid = 536
    user.name = "sgeadmin"
    user.uid = 536
    user.gid = 536
    user.description = "SGE admin user"
    user.home = "/shared/home/sgeadmin"
    user.shell = "/bin/bash"

Эти конфигурации GridEngine переопределяют версию GridEngine по умолчанию и расположение установки при запуске кластера. Перемещаться из /sched небезопасно, так как это общее NFS-расположение в кластере.