LINUX.ORG.RU
ФорумAdmin

Виртуализация на кластере

 , , ,


0

2

Всем много ядер!
Вообще не уверен, что этот вопрос нужно писать в admin. А вопрос вообще довольно нетипичный. Есть один НИИ, у НИИ есть вычислительный кластер с кучей видеокарт. На кластере крутиться какой-то там линукс. Притом кластер не предназначен для какой-то высшей цели. Предполагается, что все отделы НИИ (коих кстати овердофига и занимаются они от ядреной физики до всякой биоинженирии) будут одновременно считать на этом кластере каждый свою тему. Те самому продвинутому из каждого отдела заводят учетку с правом лазить только по своему хомяку, а дальше крутись, как хочешь. Поставить нужный пакет? Обращайся к администрации, да-да, с письменным заявлением. Угадайте с трех раз, кто пользуется этим кластером? Правильно - никто. Ну и поскольку до руководства дошло, что что-то оно делает не так, решили собрать совещание с рук-лями отделов, на тему «что вам надо, чтоб вы начали пользоваться буржуинской чудо-машиной». Вот тут и начинается мой вопрос. От одного знакомого PhD, защитившегося в области hpc, я услышал, что в таких ситуациях на кластере разворачивают систему виртуализации. Для каждой команды заводят виртуальную машину, в которую тем или иным образом пробрасывают реальное железо (процы и видеокарты) и уже каждая команда настраивает виртуалку под себя. Как называется подобная архитектура? Возможно ли применение CUDA при таком подходе? Какой софт для такого используется? Есть ли примеры удачной реализации такого подхода?

★★★

я вижу несколько требований

1. самообслуживание

2. разделение ресурсов

3. проброс железа

по всем трем пунктам подойдет oVirt/RHEV или Openstack, но последний требует очень много как железа так и знаний, для поддержания.

Проблема тут в первую очередь не в системе управления ресурсами, а в том что народ будет делать с ними. Вот подключился пользователь, получил свою квоту - X виртуальных машин с Y ядер на каждой и Z дискового места. Что дальше? Он сам поставит там тот софт который ему нужен, или побежит к админу?

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

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

Я как раз представитель отдела, а не тот кто будет все это дело админить. От админа мне нужно: а) Создание виртуальной машины б) Установка указанной мною ОС в) Проброс в ОС вычислительного оборудования. Опционально, помощь в настройке всяких MPI и cuda. Если пойдет все гладко, я и сам это могу сделать (на пк делал), но на такой системе возможны затыки.Т. е. нужные пакеты и либы в виртуалку в общем случае ставит уже сам юзер. Про софт вы сказали (хотя тот PhD предлагал обойтись qemu и kvm), а можете покидать ссылок на какие-нить презентации и обзорные статьи этих технологий, так как подозреваю, что наше руководство про такие вещи ни сном ни духом, и просто не поверят, что такое вообще возможно.

LIKAN ★★★
() автор топика

Мне кажется, что openstack для такой ситуации подходит хорошо, с точки зрения пользователя сервиса, а вот с точки зрения админа - гемор.

Deleted
()
Ответ на: комментарий от Deleted

Чем легче будет развертывание системы, тем с большей охотой руководство согласится на неё перейти

LIKAN ★★★
() автор топика

вычислительный кластер с кучей видеокарт
Для каждой команды заводят виртуальную машину

а сколько нод в кластере? и как собираются предлагающие rhev, kvm, и прочее создавать виртуальную машину с количеством процов больше чем то количество процов, которое установлено в физ-сервере?

если физ серверов 1000, то нужно создать 1000 виртуалок со своими ресурсами и опять же городить поверх их mpi и всё такое?

ukr_unix_user ★★★★
()
Ответ на: комментарий от protiv

Много маркетинговой ерунды. Хотелось бы что-то, объясеяющее на пальцах как это работает. Нет ни слова про проброс оборудования и cuda.

LIKAN ★★★
() автор топика

Как по мне то ставите Linux + LXC контейнеры каждому с реальным почти железом напрямки, есть cgroup он поможет делить и ограничивать. Быстрые бекапы, можно развернуть почти любой Linux.

anonymous
()
Ответ на: комментарий от dvrts

Почему или? Вместе они отлично сработаться могут, ты это знаешь :)

можно и вместе, но тогда надо еще и MIQ ставить для центрального управления. too many moving parts, хотя при правильно поставленном тз это вполне возможно. Я пытаюсь для начала выбить из т/с хоть какое нибудь тз

dyasny ★★★★★
()
Ответ на: комментарий от LIKAN

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

При правильно установленной системе, все это пользователь делает сам, одним кликом мышки. VM с нужной OS создается из готового образа, настраивается по надобности готовой системой конфигурации (foreman например) или триггером над системой виртуализации запускающем playbook. проброс тоже не проблема, было бы что пробрасывать.

насчет ссылок, про openstack их чуть более чем дофига, по oVirt/RHEV немного меньше, но тоже немало. книг кстати тоже хватает. Самое простое - поднять кластерок, поставив перед собой набор задач, и погонять его на предмет соответствия. С этим могу помочь, хотя я немного в другой временной зоне.

dyasny ★★★★★
()
Ответ на: комментарий от ukr_unix_user

как собираются предлагающие rhev, kvm, и прочее создавать виртуальную машину с количеством процов больше чем то количество процов, которое установлено в физ-сервере

никак. Такое не позволяет ни одна система виртуализации в принципе.

dyasny ★★★★★
()

Я бы не стал связываться ни с какой виртуализацией. Зачем? Все равно встанет вопрос. А на каком узле(-ах) кластера запустить эту(-и) виртуальную(-ые) машину(-ы), чтобы она вам что-то там посчитала??? А не будет ли этот же узел использоваться для работы другими пользователями и их виртуальными машинами (конкуренция за ресурсы => тормоза обеих задач).

Поэтому внедрите на кластере систему управления ресурсами SLURM, OpenPBS и т.п. и будет вам счастье. Конечно, нужно будет ее настроить, продумать политику выделения ресурсов и т.д. Но уже без виртуализации.

И кстати я не уверен, что CUDA-видюха нормально виртуализируется в гостевую систему (точно не как видеокарта, скорее может как PCI устройство). Будет ли работать sinned-memory, асинхронный вызов и прочее

gvtlor
()
Ответ на: комментарий от gvtlor

Я бы не стал связываться ни с какой виртуализацией. Зачем? Все равно встанет вопрос. А на каком узле(-ах) кластера запустить эту(-и) виртуальную(-ые) машину(-ы), чтобы она вам что-то там посчитала??? А не будет ли этот же узел использоваться для работы другими пользователями и их виртуальными машинами (конкуренция за ресурсы => тормоза обеих задач).

вообще-то одна из задач системы управления виртуализации - динамическое распределение нагрузки по хостам. И кстати, SLURM, ОpenPBS и прочие умеют вживую мигрировать нагрузку с перегруженого хоста на более свободный?

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

Да, совещание состоялось. Кластерщики сказали, делать виртуалки не хотят. И привели 2 аргумента
1) Виртуалки сложно(невозможно) переносить, если происходит апгрейд кластера. Правда ли это?

2) Виртуализация потребует значительно больше ресурсов по памяти, процам, дискам чем если считать напрямую на одной системе Так ли это на самом деле, сколько в процентном соотношении примерно сожрет виртуализация?

LIKAN ★★★
() автор топика
Ответ на: комментарий от dyasny

Нет, этот софт вообще никак не связан с виртуализацией. Ориентирован на «чистые» системы. И на вычислительных кластерах вообще редко задумываются о динамическом перемещении нагрузки, ибо каждое перемещение приводит к временному, но замедлению расчетов, что как бы противоречит цели пользователя - посчитать максимально быстро.

gvtlor
()
Ответ на: комментарий от LIKAN

1. Если есть общее хранилище (san,nas) то не сложно
2. Разве что по дискам чуть хуже чем в нативном режиме + на гипервизор гиг ОЗУ оставить, а так в целом не значительно что бы отказываться от виртуализации

Ien_Shepard ★★★
()
Ответ на: комментарий от LIKAN

1) Виртуалки сложно(невозможно) переносить, если происходит апгрейд кластера. Правда ли это?

абсолютная чушь.

2) Виртуализация потребует значительно больше ресурсов по памяти, процам, дискам чем если считать напрямую на одной системе Так ли это на самом деле, сколько в процентном соотношении примерно сожрет виртуализация?

не очень значительно, но больше. ОС отъедает обычно примерно 0.5-1 гиг памяти, периодически требует немного cpu для обработки собственных задач, и занимает несколько гиг на диске. Сами виртуалки всегда бегут немного медленнее чем такая же машина на настоящем железе, потеря производительности - несколько процентов.

Виртуализация существует для того чтоб лучше утилизировать железные ресурсы. Там где задача нагрузит хост на 10-15%, несколько VM дотянут до 100%, а зачем платить за дорогую железку, если она на 85% простаивает? Во многих серьезных фирмах (от анимационных студий и до банков и страховых фирм), даже на десктопах по ночам автоматически поднимается виртуалка, и присоединяется к пулу ресурсов, чтоб железо не пыхтело зря.

На самом деле, при небольшой потере в производительности, можно во первых полностью использовать железо по максимуму, а во вторых создавать и уничтожать машины автоматически, на лету. В принципе, при помощи IPMI и PXE это можно кое-как делать и с железом, но в VM все намного быстрее и проще, при том что сами железки будут бежать с одной ОС и не меняться, кроме как во время апдейтов/апгрейдов. И во время апдейтов, хост просто переводится в maintenance mode, что запускает живую миграцию всех машин на другие хосты. Закончил апдейт - верни хост в пул, и на нем начнут запускаться виртуалки.

Кстати, если потеря нескольких процентов от виртуализации это серьезная проблема, то она вполне решаема контейнерами.

dyasny ★★★★★
()
Ответ на: комментарий от gvtlor

когда рассчет длинный, рендер на несколько суток например, всегда полезно иметь возможность спокойно, и без потери прогресса убрать машину на другое железо, если на хосте внезапно выпал диск из рейда (например). Да, миграция немного притормозит рассчеты (только на время самой миграции, т.е. на время переброса стека памяти по сети на другой хост, плюс синхронизация наработанной дельты), но немного притормозить vs потерять наработанное за несколько уже отработанных суток - непростое решение.

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

И ещё, последний вопрос, околоюридического толка. Касательно виртуальных машин. Коммерические продукты аля matlab, обычно имеют отдельные версии продуктов для разворачивания на кластерах. Стоят они естественно дороже. Можно ли создать и настроить ВМ так, чтобы на ней разворачивалась обчная ПК версия этого продукта, притом пробросить оборудование, что б получить хоть какой-то прирост производительности по сравнению с обычным ПК ?

LIKAN ★★★
() автор топика
Ответ на: комментарий от dyasny

Ещё небольшой вопрос к Вам, как к специалисту. Кластер, грубо говоря пример массово-параллельной архитектуры, т.е. ноду кластера доступно адресное пространство ОП только этого нода. Следовательно если на ноде N Gb оперативы, дать процессу больше N Gb оперативы (если процесс не может в MPI конечно) невозможно. Можно ли это ограничение обойти при помощи виртуалки развернутой сразу на несколько нод? Те можно сделать так, чтоб приложение, работающие в виртуалке. воспринимало оперативку нескольких нод как единое целое?

LIKAN ★★★
() автор топика
Ответ на: комментарий от LIKAN

Нет, вы путаете вычислительные кластеры, где все ресурсы собираются в одну кучу, а потом распределяются задачам, и отказоустойчивые кластеры, где каждый хост - набор локальных ресурсов способных нести X нагрузки, и если одна из нод откажет, взять на себя еще и нагрузку другой ноды. В кластере виртуализации невозможно поднять VM у которой будет больше ресурсов чем у хоста на котором VM бежит. Более того, это просто не нужно. Вся идея виртуализации и контейнеров в том, что железо в наше время настолько мощное что одна задача просто не способна полностью его использовать, и поэтому поднимаются виртуальные машины, которые более чем способны, ведь их много.

На одном хосте можно поднять несколько VM сумма выделенной памяти и процессорных ядер которых, будет превышать количество фиьической памяти или ядер, но эффект от этого такой же как от запуска множества очень прожорливых процессов - они будут мешать друг другу в очереди на исполнение и при нехватке памяти, гипервизор начнет свопить. Для этого есть решения (KSM, для дедупликации памяти например, ведь несколько одинаковых линуксов скорее всего будут держать в памяти много одинаковых страниц). Но если выделить машине больше ядер чем есть у хоста, она начнет соревноваться за время исполнения с самой собой, и работать будет мягко выражаясь хреново. С памятью то же самое - чего дедуплицировать, если оно все от одной единственной виртуалки? А значит надо уходить в своп, или даже добраться до OOM

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

Таак, а со всяким докерами (lxc, docker) проблема будет такая же? Тут то как раз и весь сыр бор из-за того, что есть задачи которым нужно ну просто дохрена оперативки, больше чем есть у одной ноды. Получается от какой бы то ни было виртуализации (в том числе и от docker) нужно отказываться?

LIKAN ★★★
() автор топика
Ответ на: комментарий от dyasny

А ещё очень любопытно, как эту проблему решил амазон. Там тоже пользовательский контейнер не может занимать более одного узла?

LIKAN ★★★
() автор топика
Ответ на: комментарий от LIKAN

Это общая проблема. Делиться оперативкой даже через rdma - курам насмех. Тормозить будет страшно

dyasny ★★★★★
()
Ответ на: комментарий от LIKAN

Конечно. Вообще, встречный вопрос: до хрена памяти это сколько, и как вы сейчас справляетесь?

dyasny ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.