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

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

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

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

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

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

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

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

oVirt/RHEV или Openstack

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

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

http://maximum.axoft.ru/last/RD/3092797/material/RHEV_Axoft Maximum_Rostov.pdf и ещё куча всего есть в инете

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое контейнеры и с чем их едят?

Это более современный подход к виртуализации и разделению ресурсов

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

Это те саме LXC, которые предлагал товарищ выше?

Это вопрос к продаванам матлаба

Lxc или, что намного моднее - docker

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

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

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

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

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

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

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