У нас есть небольшой кластер из шести серверов ubuntu. Мы проводим биоинформатический анализ этих кластеров. На выполнение каждого анализа уходит около 24 часов, каждый сервер Core i7 может обрабатывать 2 сервера одновременно, принимает в качестве входных данных около 5 ГБ данных и выводит около 10–25 ГБ данных. Мы проводим их десятки в неделю. Программное обеспечение представляет собой смесь пользовательских сценариев Perl и стороннего программного обеспечения для выравнивания последовательностей, написанного на C / C ++.
В настоящее время файлы обслуживаются двумя вычислительными узлами (да, мы используем вычислительные узлы в качестве файловых серверов) - каждый узел имеет 5 дисков sata емкостью 1 ТБ, смонтированных отдельно (без рейда), и объединяется в пул через glusterfs 2.0.1. Каждая из них имеет по 3 связанных карты Intel Ethernet PCI Gigabit Ethernet, подключенных к коммутатору d-link DGS-1224T (300 долларов США, 24 порта потребительского уровня). В настоящее время мы не используем jumbo-кадры (на самом деле не знаю почему). Затем два вычислительных узла, обслуживающих файлы, зеркалируются через glusterfs.
Каждый из четырех других узлов монтирует файлы через glusterfs.
Все файлы большие (4 ГБ +) и хранятся как простые файлы (без базы данных и т. Д.), Если это важно.
Как вы понимаете, это немного беспорядок, который вырос органически без предусмотрительности, и мы хотим улучшить его сейчас, когда у нас заканчивается место. Наш анализ требует интенсивного ввода-вывода, и это узкое место - мы получаем только 140 МБ / с между двумя файловыми серверами, возможно, 50 МБ / с от клиентов (у которых есть только один сетевой адаптер). У нас есть гибкий бюджет, который я, вероятно, смогу получить около 5 тысяч долларов.
Как нам потратить наш бюджет?
Нам нужно как минимум 10 ТБ хранилища, достаточно быстрого для обслуживания всех узлов. Насколько быстрым / большим должен быть процессор / память такого файлового сервера? Должны ли мы использовать NFS, ATA через Ethernet, iSCSI, Glusterfs или что-то еще? Стоит ли покупать два или более серверов и создавать какой-то кластер хранения, или одного сервера достаточно для такого небольшого количества узлов? Стоит ли инвестировать в более быстрые сетевые адаптеры (скажем, карты PCI-express с несколькими разъемами)? Выключатель? Стоит ли использовать raid, если да, то железо или софт? а какой рейд (5, 6, 10 и тд)?
Любые идеи приветствуются. Мы биологи, а не гуру информационных технологий.
Я занимаюсь информатикой и занимаюсь исследованиями в области биоинформатики. Сейчас 746 на Биостарс :)
Я управлял вычислительными средствами биоинформатики в течение 3 лет в университете (около 40 серверов Linux, 300 процессоров, 100 ТБ дискового пространства + резервные копии, всего около 1 ТБ ОЗУ - серверы с объемом ОЗУ от 16 до 256 ГБ). В нашем кластере 32 8-ядерных вычислительных узла, 2 головных узла, и мы расширяем его еще двумя 48-ядерными вычислительными узлами. Мы обслуживаем файлы на вычислительных узлах через NFS.
Я бы порекомендовал перейти на NFS в вашей ситуации.
Мы думали о переходе на Gluster, Lustre и Samba, но решили не использовать их.
У меня есть несколько основных советов по поводу NFS:
Наш текущий кластер был куплен 3 года назад, поэтому он не использует SAS, а имеет обширные диски FiberChannel и сан контроллеры. Это меняется, все новое хранилище, которое мы покупаем, принадлежит SAS.
Я бы предложил рассмотреть SAS место хранения. SAS заменяет FiberChannel как более дешевое, быстрое и лучшее решение. Недавно я изучил различные предлагаемые решения. Удобно, что варианты, которые мы рассмотрели, задокументированы для Server Fault: Какие есть варианты внешнего хранилища SAS (Promise, Infortrend, SuperMircro, ...)?
Недавно мы заказали у RAID Incorporated систему хранения SAS 6 ГБ - 6 ГБ SAS. Только за хранение мы заплатили 12к долларов. Заказ должен прийти через пару недель. Это система без единой точки отказа - все компоненты избыточны и автоматически переключаются при отказе любого из компонентов. Он подключен к 2 серверам, каждый из которых использует разные разделы массива. Это решение «под ключ», поэтому после его доставки нам просто нужно подключить его, включить, и оно будет работать (разделы RAID6 будут смонтированы в Linux). В заказ также включены серверы, и RAID Incorporated устанавливает на них Linux Debian без дополнительных затрат.
К сожалению, если вы занимаетесь операциями с инфраструктурой биоинформатики, вам, вероятно, придется стать гуру хранения.
Для своего раздела 10 ТБ выберите RAID6 - 2 диска могут выйти из строя без потери данных. Перестройка диска емкостью 2 ТБ в «горячий» резерв занимает 24 часа, в течение этого времени может выйти из строя другой диск. У меня одновременно вышли из строя 2 диска в массиве из 16 дисков.
Рассмотрите возможность выделения одного диска в качестве горячего резерва в массиве. Когда у вас более 16 дисков, я бы сказал, что горячий резерв просто необходим.
Придумайте план действий в случае отказа оборудования на выделенном сервере NFS. Я бы оставил двойник в качестве вычислительного узла в качестве потенциальной замены исходного сервера NFS.
Наконец, я должен упомянуть, что наш файловый сервер работает под управлением OpenSolaris (звучит необычно - я знаю). OpenSolaris (как нам выяснилось) имеет отличную поддержку серверного оборудования (FiberChannel, IniniBand, ...). Настройка сервера NFS с нуля занимает 1 час - все шаги полностью просты: установка ОС, обновление через NAT, настройка сети, создание пула zfs, создание файловых систем zfs, совместное использование NFS. Sun была тем, кто разработал NFS в 1984 году, поэтому неудивительно, что OpenSolaris очень хорош в обслуживании NFS. Основной причиной использования OpenSolaris было ZFS - а хорошая файловая система для биоинформатики. Некоторые функции, которые мне нравятся:
zfs send).Было бы хорошо использовать Linux для вашего NFS-сервера - в этом случае придерживайтесь XFS или Ext4.
Ваш бюджет не уведет вас слишком далеко с оборудованием класса SAN, но вы сможете получить гораздо лучшую производительность, увеличив оборудование, которое у вас есть. Купите приличный RAID-контроллер, купите больше дисков, получите гораздо лучший коммутатор и, возможно, хороший многопортовый сетевой адаптер (приобретите приличные серверные, такие как Intel PRO 1000 GT или ET).
Если ваше описание шаблона ввода-вывода верное, у вас соотношение чтения / записи 15:85, поэтому вам нужно будет перейти на RAID 10, чтобы улучшить показатели пропускной способности с дисками SATA. С учетом предвзятости записи, если бы вы просто перенастроили свои текущие диски для RAID-5 (или RAID6, что было бы более целесообразно в этом масштабе), производительность резко упала бы. Однако RAID-10 уменьшит полезную емкость дисков вдвое.
Получение всего вышеперечисленного и достаточного количества дисков для доставки 10 ТБ в RAID10 за 5 тысяч долларов вполне выполнимо, но это не безрисковое упражнение. Есть несколько очень интересных вариантов, описанных в этот вопрос и его ответы, которые стоит рассмотреть, если вы довольны рисками и комфортно придумываете собственное решение.
Однако мой главный совет вам - начать спрашивать себя (или того, кто подписывает чеки), во сколько на самом деле будет стоить сбой хранилища вашему бизнесу и согласны ли вы с этим риском. Ваш бюджет в 5 тысяч долларов может примерно позволить вам повысить производительность, но вы говорите о том, что у вас есть 10 ТБ из того, что, как я полагаю, является критически важными для бизнеса данными и вычислительной мощностью, и все это обеспечивается инфраструктурой с множеством единичных точек отказа. Возможно, сейчас самое подходящее время, чтобы внимательно присмотреться к тому, насколько важна эта инфраструктура, и выяснить, сможете ли вы собрать достаточно средств для покупки подходящего решения SAN или NAS начального уровня.
Вы самостоятельно разрабатываете задачи обработки? Распределяются ли они, назначая каждому узлу некоторый фрагмент данных для обработки?
Если это так, может быть более эффективным приблизить процесс к данным, а не передавать данные процессам. Это не так уж сложно, но требует другого мышления, чем просто создание серверов.
Сначала установите несколько дисков на каждый узел. Может быть, не RAID, а только файловая система на каждом. Разделите данные на всех дисках на всех узлах и запустите задачи на узлах, которые содержат данные, необходимые для задачи. Старайтесь минимизировать межузловые передачи.
Конечно, ничего из этого не сработает, если вашим задачам нужны непредсказуемые части данных.
Обычно такая обработка связана с извлечением информации из данных - но ваш результат на несколько порядков больше, чем входной?
Первое, на что нужно обратить внимание, это как используются данные? Большая часть генетического анализа и, в определенной степени, сворачивания белков с использованием анализа конечных элементов полагается на последовательный доступ к большим файлам данных - по сравнению с произвольным доступом. Таким образом, задержка - это не столько проблема, сколько пропускная способность диска.
Итак, с точки зрения организации ваших дисков, вы, вероятно, захотите как можно больше полос на как можно большем количестве пластин - например, RAID 5 или 6.
То, как вы подключите это к узлам обработки, во многом зависит от вашего бюджета. Если у вас много денег, то установка нескольких виртуальных дисков в SAN с коммутируемой структурой с напрямую подключенными обрабатывающими узлами - лучший вариант.
Для дешевого решения (то есть с вашим бюджетом) локальное хранилище на каждом узле обработки - это лучший вариант. Важно то, что вы держите обработку ввода-вывода вне сети (но при необходимости используйте сеть для копирования данных между узлами, если SAN недоступна). И если вы можете сопоставить данные локально, то наличие большого количества памяти на узлах обработки поможет с кешированием.
Конечно, если у вас очень строгий бюджет, вы захотите получить эти локальные диски в конфигурации RAID 5. Кроме того, если возможно, буферизируйте вывод на локальный диск во время обработки, а не записывайте напрямую на серверы.
HTH
Я не думаю, что вы, скорее всего, не захотите использовать ATAoE, iScsi или FC, если можете этого избежать. Все это технологии блочного хранения, и они лучше предоставляют дисковое пространство отдельным серверам из общего пула дисков. Они не предназначены для простого обмена этими данными между клиентскими машинами, если только вы не запустите какое-то специальное программное обеспечение для работы с общими файловыми системами с менеджерами метаданных и т. Д.
NFS основана на файлах и предназначена для совместного использования файловых систем между несколькими серверами и является бесплатной. Александр направляет вас в правильном направлении, если то, что вам нужно сделать, как говорит Хавьер, - переместить данные в процессы для выполнения вычислений. Если вы хотите, чтобы любое задание могло выполняться на любом узле, тогда вам подойдет NFS. Пропускная способность, вероятно, будет лучше, если вы сможете предварительно заполнить данные на узлах и отправить задания, требующие определенных данных, на узлы, у которых они есть. Это способ сделать это с помощью hadoop, map / reduce. Например, если вы предварительно загрузили геном мыши в один из узлов, и когда кто-то выполняет взрывную работу с этим геномом, вы отправляете задание узлу, который уже имеет данные. Никакие реальные данные не перемещены. Однако это может создать узкое место на этом узле, если набор данных, который у него есть, популярен, и задания могут выполнять резервное копирование, когда другие узлы простаивают.
Некоторые исследователи, с которыми я работал в последнее время, использовали несколько «толстых» узлов или кластеров в коробке. Один купил одну 48-ядерную (4 12-ядерных процессора) систему на базе AMD с 128 ГБ оперативной памяти примерно за 15 тысяч долларов. Его алгоритмы очень параллельны, поэтому для него имеет смысл большее количество ядер. Имея такой объем памяти, Linux имеет массу места для файлового кеша, поэтому последующее чтение файлов данных с несколькими гигабайтами на этой машине происходит очень быстро. Кроме того, с имеющейся у него рейд-картой он получает около 300 мегабайт в секунду в свое локальное хранилище. Я не говорю, что эта машина подойдет всем, но она работает для него. Прежде чем мы предоставили его ему для использования, я для развлечения протестировал параллельное задание bzip на этой машине, которое сжало текстовый файл размером 3 ГБ до 165 МБ, и это заняло около 4 секунд. (Файл был кэширован в оперативной памяти). Довольно шустрый.
К вашему сведению, вы увидите то, что мы привыкли называть сумасшедшей средней нагрузкой на машинах с большим количеством ядер. Средняя загрузка 20+ довольно распространена на этой машине, и ее интерактивная производительность все еще довольно бодрая.