У нас будет работающий компьютер, который на пиковой производительности должен будет обрабатывать 50 («головки записи») х 75 ГБ данных в час. Это максимальная скорость записи ~ 1100 МБ / с. Чтобы получить это от машины, требуется две линии по 10 ГБ. У меня вопрос, какая технология server + может обрабатывать / хранить такой поток данных?
В настоящее время для хранения данных мы работаем с ZFS, хотя скорость записи никогда не возникала. (мы даже не близки к этим скоростям) Будет ли ZFS (zfs на linux) вариантом? Нам также необходимо хранить большое количество данных, «Руководство по ИТ» предлагает всего около 50-75 ТБ. Так что, вероятно, не все SSD, если мы не хотим предложить нашего первенца.
Некоторые дополнения, основанные на превосходных ответах:
- максимум составляет 50x75 ГБ / час во время пика, который составляет менее 24 часов (наиболее вероятно, <6 часов)
- Мы не ожидаем, что это произойдет в ближайшее время, скорее всего, мы будем работать 5-10x75GB / час
- это пре-альфа-машина, однако требования должны быть соблюдены (хотя в игре много знаков вопроса)
- мы бы использовали NFS как соединение с машины к серверу
- макет: генерирующая машина -> хранилище (это) -> (безопасный рейд 6) -> вычислительный кластер
- так что скорость чтения не важна , но было бы неплохо использовать ее из вычислительного кластера (но это совершенно необязательно)
- скорее всего, это будут большие файлы данных (не много маленьких)
источник
Ответы:
Абсолютно ... ZFS в Linux - это возможность, если она правильно спроектирована. Есть много случаев плохой конструкции ZFS , но если все сделано правильно, ваши требования могут быть удовлетворены.
Таким образом, основным фактором будет то, как вы подключаетесь к этой системе хранения данных. Это NFS? CIFS? Как клиенты подключаются к хранилищу? Или обработка и т.д. делается на системы хранения данных?
Заполните еще несколько деталей, и мы посмотрим, сможем ли мы помочь.
Например, если это NFS и с синхронным монтированием, то определенно возможно масштабировать ZFS в Linux, чтобы удовлетворить потребности в производительности записи и при этом поддерживать требования к длительному объему хранилища. Являются ли данные сжимаемыми? Как каждый клиент связан? Гигабитный Ethernet?
Редактировать:
Хорошо, я укушу
Вот спецификация, которая стоит примерно 17–23 тыс. Долл. И помещается в стойку размером 2U.
Эта установка предоставит вам 80 ТБ доступного пространства с использованием аппаратного RAID6 или ZFS RAIDZ2.
Поскольку основное внимание уделяется производительности на основе NFS (при условии синхронной записи), мы можем легко справиться с этими задачами с помощью дисков P3608 NVMe (чередующийся SLOG). Они могут вместить 3 ГБ / с при последовательной записи и имеют достаточно высокий уровень выносливости, чтобы постоянно справляться с описанной вами рабочей нагрузкой. Приводы могут быть легко предоставлены для дополнительной защиты в случае использования SLOG.
При рабочей нагрузке NFS записи объединяются и сбрасываются на вращающийся диск. Под Linux мы настраивали бы его на сброс каждые 15-30 секунд. Вращающиеся диски могут справиться с этим и могут получить еще большую выгоду, если эти данные сжимаются.
Сервер можно расширить еще 4 открытыми слотами PCIe и дополнительным портом для двухпортовых адаптеров 10GbE FLR. Таким образом, у вас есть сетевая гибкость.
источник
Для такой экстремальной скорости записи я рекомендую использовать ZFS, BTRFS или любую файловую систему CoW. Я бы использовал XFS, которая чрезвычайно эффективна при больших / потоковых передачах.
Есть много недостающей информации (как вы планируете получить доступ к этим данным? Важны ли скорости чтения? Вы собираетесь писать большими кусками? И т. Д.), Чтобы дать вам конкретные советы, однако некоторые общие советы таковы:
источник
Ethernet с пропускной способностью 25 Гбит / с уже граничит с мэйнстримом, в то время как NVMe на базе PCIe будет легко пропускать этот трафик.
Для справки: недавно я создал небольшое решение для «захвата журнала» с использованием четырех обычных серверов с двумя процессорами xeon (в данном случае HPE DL380 Gen9), каждый из которых имеет 6 дисков NVMe. Я использовал IP поверх Infiniband, но эти сетевые адаптеры 25/40 Гбит / с были бы одинаковыми. и мы записываем до 8 Гбит / с на сервер - это удовольствие.
В основном это не дешево, но это очень выполнимо в наши дни.
источник
Не похоже на большое дело. Наш местный поставщик оборудования имеет это в качестве стандартного продукта - очевидно, он может поддерживать скорость 1400 МБ / с в режиме записи CCTV, что должно быть тяжелее, чем ваши пиковые требования.
(Ссылка на конфигурацию по умолчанию 12 ГБ, но они отмечают, что 20x4 ТБ также вариант. Никакого личного опыта с этой конкретной моделью сервера.)
источник
Последовательные записи на скорости 1100 МБ / с не являются проблемой современного оборудования. Как ни странно, моя домашняя установка с 8x5900 об / мин для ноутбуков, 2x15000 об / мин и 2x7200 об / мин выдерживает 300 МБ / с с одноразовой полезной нагрузкой 16 ГБ.
Сеть представляет собой 10GbE с оптоволоконными кабелями, 9000 MTU в Ethernet, а прикладной уровень - Samba 3.0. Хранилище сконфигурировано в raid50 с тремя полосами на трех томах raid5 с 4 накопителями. Контроллер LSI MegaRAID SAS 9271-8i со скоростью до 6 Гбит / с на порт (у меня есть дополнительный, более медленный множитель портов).
Поговорите с любым опытным системным администратором, и он сможет точно сказать вам, какой контроллер (ы) и накопители будут соответствовать вашим требованиям.
Я думаю, что вы можете попробовать с любым контроллером 12Gb / s и настроить две зеркальные полосы по восемь дисков 7200 об / мин каждый (почти любой диск должен делать). Начните 3-4 соединения TCP, чтобы насытить соединение, и если одна пара карт 10GbE не может справиться с этим, используйте четыре карты.
источник
Что-то вроде касательного, но рассмотрите возможность использования InfiniBand вместо двойных 10GbE-ссылок. Вы можете получить карты Infiniband 56 Гбит / с довольно дешево или 100 Гбит / с за не слишком много, а в Linux легко использовать NFS с RDMA поверх IB, что обеспечит вам чрезвычайно низкую задержку и почти теоретическую пропускную способность линии (если ваша базовая память может справиться). Вам не нужен коммутатор, только две карты InfiniBand и кабель прямого подключения (или оптоволоконный кабель InfiniBand, если вам нужны большие расстояния).
Стоимость однопортовой карты Mellanox 56 Гбит / с (8x PCIe 3.0), такой как MCB191A-FCAT, составляет менее 700 долларов, а 2-метровый медный кабель прямого подключения стоит 80 долларов.
Производительность обычно выдувает 10GbE из воды во всех случаях использования. Недостатков нет, если только вам не нужен доступ к серверу от множества разных клиентов, которые не могут все использовать InfiniBand (и даже тогда коммутаторы Mellanox могут соединять 10GbE и 40GbE с IB, но это немного больше инвестиций, конечно).
источник
Выполнение этого с ZFS возможно, однако, рассмотрите возможность использования FreeBSD, поскольку FreeBSD имеет более быстрый сетевой стек. Это позволило бы возможно 100 Гбит на одной машине.
1100 Мбит / с звучит как много, но вы можете реально добиться этого, используя только обычные жесткие диски. Вы говорите, что вам нужно 75 ТБ места, чтобы вы могли использовать 24 8 ТБ жестких дисков в зеркалах. Это даст вам 12x скорость записи одного диска и 24x скорость чтения диска. Поскольку эти диски имеют скорость записи более 100 Мбит / с, это может легко обеспечить пропускную способность. Удостоверьтесь, что вы не получите SMR-накопители, так как они имеют значительно меньшую скорость записи.
ZFS создает контрольные суммы для каждого блока. Это реализовано однопоточным. Таким образом, вы должны иметь процессор с достаточно высокой тактовой частотой, чтобы не блокировать.
Однако точные детали реализации в значительной степени зависят от деталей.
источник
Мы установили привязку данных NIC 10G к кластеру Gluster через их клиент-предохранитель. Это займет немного настройки, вы не поверите, что производительность может быть достигнута с 3.0.
источник