Кластер CycleCloud GridEngine

Open Grid Scheduler (Grid Engine) можно легко включить в кластере Azure CycleCloud, изменив "run_list" в определении кластера. Двумя основными компонентами кластера grid Engine являются главный узел, который предоставляет общую файловую систему, на которой выполняется программное обеспечение Grid Engine, и узлы execute, которые являются узлами, которые подключают общую файловую систему и выполняют отправленные задания. Например, простой фрагмент шаблона кластера 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 будет получен один главный узел. Узлы выполнения можно добавить в кластер с помощью cyclecloud add_node команды . Например, чтобы добавить еще 10 узлов, выполните следующую команду:

cyclecloud add_node grid-engine -t execute -c 10

Автомасштабирование подсистемы сетки

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

[cluster grid-engine]
Autoscale = True

По умолчанию все задания, отправленные в очередь ядра сетки, будут выполняться на компьютерах типа "execute", которые определяются массивом узлов с именем "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, предоставляя MachineType с двумя GPU Nvidia (Standard_NV12 в Azure). Кроме того, обратите внимание, что в разделе конфигурации есть два новых элемента, кроме рецепта csge:sgeexec. Добавление gridengine.slot_type = gpu сообщает планировщику ядра сетки, что эти узлы должны называться узлами GPU и поэтому должны выполнять только задания GPU. Имя gpu является произвольным, но наиболее полезным является имя, описывающее узел. Задайте gridengine.slots = 2параметр , который сообщает программному обеспечению, что узел этого типа может выполнять только два задания одновременно (Standard_NV12 имеет только 2 GPU). По умолчанию число слотов на узел в Grid Engine будет равно количеству ЦП в системе, что в этом случае приведет к одновременному выполнению слишком большого количества заданий на узле. В приведенном выше примере параметр задается в nodearray в соответствии с количеством GPU, CoreCount=2 доступными в MachineType, что позволяет CycleCloud правильно масштабировать этот массив на GPU и количество ЦП.

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

    -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, которые мы указали в нашем шаблоне конфигурации кластера. Третий компьютер является главным узлом, на котором не выполняются задания.

Расширенное использование подсистемы сетки

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

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

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

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

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

Отправка заданий в подсистему сетки

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

qsub my_job.sh

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

qsub -l slot_type=gpu my_gpu_job.sh

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

Если slot_type опущен, задание будет автоматически назначено "execute". Пользователь может изменить механизм, который автоматически назначает заданиям slot_type. Можно создать скрипт Python, расположенный по адресу /opt/cycle/jetpack/config/autoscale.py , который должен определить одну функцию "sge_job_handler". Эта функция получает представление задания в словаре, аналогично выходным данным qstat -j JOB_ID команды, и должна возвращать словарь жестких ресурсов, которые необходимо обновить для задания. Например, ниже приведен скрипт, который назначит задание slot_type 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 обычных заданий, так как тип компьютера для узла "выполнение" имеет 4 ЦП каждое, CycleCloud запустит 2 из этих узлов для обработки заданий (5/4 = 1,25 округлено до 2). Через некоторое время для загрузки и настройки вновь запущенных узлов все 10 заданий будут выполняться до завершения, а затем 5 узлов автоматически завершатся, прежде чем поставщик облачных служб снова будет выставлять счета.

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

qsub -ac average_runtime=10 job_with_duration_of_10m.sh

Справочник по конфигурации ядра сетки

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

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

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

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

Эта страница касается возможностей и конфигурации использования GridEngine (Altair) с 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, группы узлов и параллельные среды

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

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, которая является специальной группой узлов.

Без указания pe qsub -q short.q my-script.sh результирующая виртуальная машина будет добавлена в @allhosts и @lowpriority это группы узлов в очереди, которым не назначены pes.

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

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

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

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

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

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

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

Конфигурация автомасштабирования

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

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

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

Дополнительный ресурс автомасштабирования

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

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

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

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

Дополнительные атрибуты находятся в 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
    },

Сопоставление виртуальных ЦП узла со сложными слотами и memmb с mem_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 для проверки соответствия поведения автомасштабирования ожиданиям. В качестве привилегированного пользователя можно выполнять следующие операции. Рекомендуется ознакомиться с этими параметрами, чтобы понять поведение автомасштабирования.

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 = falsegridengine.shared.bin = false и установив GridEngine локально. В простом случае необходимо предоставить файловую систему, которую можно подключить с помощью узлов выполнения, содержащих $SGE_ROOT каталог, и настроить это подключение в дополнительных параметрах. После освобождения зависимости каталогов sched и общих каталогов можно завершить работу узла планировщика, который по умолчанию является частью кластера, и использовать конфигурации из внешней файловой системы.

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

Использование модуля Сетки Univa в 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 по умолчанию и расположение установки при запуске кластера. Отходить от /sched небезопасно, так как это специально общее расположение nfs в кластере.