Я студент компьютерной инженерии, работаю над проектом с кластером лезвий Verari, немного устаревшим по сегодняшним стандартам. У меня был некоторый опыт работы с Unix, но я совсем не эксперт.
Этот кластер Verari имеет 30 рабочих блейд-узлов, 20 из которых с двумя двухъядерными процессорами AMD (Opteron 250), оперативной памятью DDR 4 Гб и двумя жесткими дисками IDE по 250 Гб. Другие 10-узловые блейд-модули имеют два четырехъядерных процессора Opteron и оперативную память 8 Гбайт с такими же жесткими дисками IDE. Эти 30 узлов прикреплены к патч-панели, которая заканчивается двумя гигабитными коммутаторами, соединены друг с другом двумя кабелями категории 6 и подключены к обоим коммутаторам. Кроме того, у меня есть рабочая станция IBM, на которой размещены DNS, DHCP, HTTP, LDAP, PXE / TFTP и сервер FOG для моего домена.
Моя миссия - установить кластер beowulf с этим оборудованием. Он будет использоваться для программ MPI, научных расчетов и геологического моделирования. Мой первоначальный план - использовать CentOS 6.5 с хорошим файлом кикстарта для облегчения развертывания с программной настройкой RAID 1 на каждом узле, центральной аутентификацией пользователя с сервером OpenLDAP, программным обеспечением OpenMPI и диспетчером ресурсов SLURM.
Поскольку у меня еще нет центрального хранилища для использования, мне нужно найти способ сохранить доступ к домашним каталогам пользователей для каждого вычислительного узла с минимальными издержками производительности и обеспечением некоторой избыточности, если что-то пойдет не так (это 2004 ~ 2006 гг. И более подвержено сбоям). Я подумал об использовании автоматически смонтированных общих ресурсов NFS, при этом каждый вычислительный узел экспортирует папку / home и путь homeDirectory, хранящийся в учетной записи пользователя ldap. Это заканчивается подключением до 30 серверов NFS на гигабайтном канале, смешивая узлы хранения с вычислительными узлами, что не является хорошей практикой, но это то, что я получил. Помните, что это жесткие диски IDE, поэтому у нас есть старые добрые узкие места при записи и чтении.
Другая идея, которая приходит мне в голову, - использовать распределенную файловую систему, снова смешивая вычислительные узлы с узлами хранения. У меня красный GlusterFS, Ceph, AFS, PVFS2, OrangeFS и Lustre. Для того, что мне нужно, я думаю, что Lustre - это то, что нужно, но он предназначен для работы на группе серверов NAS / SAN, подключенных к вычислительным узлам с Infiniband, Myrinet или другим высокоскоростным каналом с низкой задержкой. Чтобы использовать Lustre в моей инфраструктуре, мне понадобится центральный узел для MDT и MDS, а также остальные 29 узлов в качестве узлов OST / вычислений. Я могу восстановиться в случае сбоя с помощью обоих вариантов, но я не знаю, как Lustre будет масштабироваться с более чем 30 узлами, выступающими в качестве хранилищ и вычислительных единиц одновременно.
У кого-нибудь есть лучшее представление о том, что использовать в моем проекте? Есть ли какой-либо опыт или отзывы о подобных настройках?
Заранее благодарим за ответы.
Я всегда использовал кластеры как первостепенную, а скорость как второстепенную цель.
Я обнаружил, что очень консервативный подход может достичь обеих целей, если мы говорим о менее чем 1000 одновременных пользователях.
Для домашних каталогов я бы выбрал простой двухузловой активный / пассивный кластер на основе nfs с четным количеством общих ресурсов, распределенных между двумя узлами в роли первичного / вторичного drbd.