Назад | Перейти на главную страницу

Требования к скорости записи: возможности 1,1 ГБ / с?

У нас будет машина в работе, которая при максимальной производительности должна 50 («пишущие головки») x 75 ГБ данных в час. Это пиковая производительность ~ 1100 МБ / с. Чтобы получить это от машины, требуются две линии по 10 ГБ. У меня вопрос: какая технология сервер + может обрабатывать / хранить такой поток данных?

В настоящее время для хранения данных мы работаем с ZFS, хотя вопрос о скорости записи никогда не стоял. (мы даже близко не подошли к этим скоростям) Будет ли ZFS (zfs на Linux) вариантом? Нам также необходимо хранить много данных, согласно «ИТ-руководству», где-то 50-75 ТБ. Так что, вероятно, это не могут быть все твердотельные накопители, если мы не хотим подарить нашему первенцу.

Некоторые дополнения на основе отличных ответов:

Для такой экстремальной скорости записи я предлагаю отказаться от ZFS, BTRFS или любой файловой системы CoW. Я бы использовал XFS, который чрезвычайно эффективен при большой / потоковой передаче.

Есть много недостающей информации (как вы планируете получить доступ к этим данным? Важна ли скорость чтения? Собираетесь ли вы писать большими кусками? И т. Д.), Чтобы дать вам конкретные советы, однако некоторые общие советы:

  • используйте XFS поверх необработанного раздела или толстого тома LVM (не используйте тонкие тома)
  • настроить размер ioblock, чтобы эффективно справляться с записью больших объемов данных
  • использовать аппаратную карту RAID с кэш-памятью записи, защищенной от потери мощности; если об использовании аппаратного RAID не может быть и речи, используйте программную схему RAID10 (избегая любого режима RAID на основе четности)
  • использовать два сетевых интерфейса 10 Гбит / с с LACP (агрегация каналов)
  • не забудьте включить Jumbo Frames
  • поскольку вы собираетесь использовать NFS, подумайте об использовании pNFS (v4.1) для повышения масштабируемости
  • наверняка многое другое ...

Совершенно верно ... ZFS в Linux возможна, если она спроектирована правильно. Есть много случаев плохой дизайн ZFS, но если все сделано хорошо, ваши требования могут быть выполнены.

Таким образом, основным определяющим фактором будет то, как вы подключаетесь к этой системе хранения данных. Это NFS? CIFS? Как клиенты подключаются к хранилищу? Или сделана обработка и т. Д. на система хранения?

Введите дополнительные сведения, и мы увидим, сможем ли мы помочь.

Например, если это NFS и с синхронным монтированием, то определенно можно масштабировать ZFS в Linux для удовлетворения потребностей в производительности записи и при этом поддерживать долгосрочные требования к емкости хранилища. Можно ли сжимать данные? Как подключен каждый клиент? Гигабитный Ethernet?


Редактировать:

Хорошо, я кусаю:

Вот спецификация примерно 17–23 тыс. Долл. США и помещается в стойку 2U.

HP ProLiant DL380 Gen9 2U Rackmount
2 x Intel E5-2620v3 or v4 CPUs (or better)
128GB RAM
2 x 900GB Enterprise SAS OS drives 
12 x 8TB Nearline SAS drives
1 or 2 x Intel P3608 1.6TB NVMe drives

Эта установка предоставит вам 80 ТБ полезного пространства с использованием аппаратного RAID6 или ZFS RAIDZ2.

Поскольку основное внимание уделяется производительности на основе NFS (при условии синхронной записи), мы можем легко справиться со всем этим с помощью накопителей P3608 NVMe (чередующийся SLOG). Они могут обеспечить последовательную запись со скоростью 3 ГБ / с и обладают достаточно высоким рейтингом выносливости, чтобы постоянно обрабатывать описанную вами рабочую нагрузку. Приводы могут быть легко переоборудованы, чтобы добавить некоторую защиту в случае использования SLOG.

При рабочей нагрузке NFS записи будут объединены и сброшены на вращающийся диск. В Linux мы бы настраивали его на сброс каждые 15-30 секунд. Вращающиеся диски могут справиться с этим и могут получить даже больше, если эти данные будут сжимаемыми.

Сервер можно расширить, добавив еще 4 открытых слота PCIe и дополнительный порт для двухпортовых адаптеров 10GbE FLR. Таким образом, у вас есть гибкость в сети.

Ethernet 25 Гбит / с уже является массовым, а NVMe на базе PCIe легко справится с этим трафиком.

Для справки, я недавно построил небольшое решение для записи журналов с использованием четырех обычных двухпроцессорных серверов (в данном случае HPE DL380 Gen9), каждый с 6 дисками NVMe, я использовал IP через Infiniband, но эти сетевые карты 25/40 Гбит / с будут такими же. и мы захватываем до 8 Гбит / с на сервер - отличное удовольствие.

В основном это не дешево, но в наши дни это очень выполнимо.

Звучит неважно. У нашего местного поставщика оборудования это стандартный продукт - очевидно, он может выдавать 1400 МБ / с в режиме записи видеонаблюдения, что должно быть сложнее, чем ваши пиковые требования.

(Ссылка на конфигурацию по умолчанию 12 ГБ, но они отмечают, что 20x4 ТБ также является вариантом. Нет личного опыта с этой конкретной моделью сервера.)

Последовательная запись со скоростью 1100 МБ / с не является проблемой для современного оборудования. Как ни странно, моя домашняя установка с дисками для ноутбуков 8x5900 об / мин, 2 дисками по 15000 об / мин и 2 дисками по 7200 об / мин выдерживает скорость 300 МБ / с при единовременной полезной нагрузке 16 ГБ.

Сеть представляет собой 10GbE с оптоволоконными кабелями, 9000 MTU в Ethernet, а прикладной уровень - Samba 3.0. Хранилище настроено в raid50 с тремя полосами на трех томах raid5 с 4 дисками. Контроллер - LSI MegaRAID SAS 9271-8i с пропускной способностью до 6 Гбит / с на порт (у меня есть дополнительный, более медленный множитель портов).

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

Я думаю, вы можете попробовать с любым контроллером 12 Гбит / с и настроить две зеркальные полосы по восемь дисков 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 ТБ в зеркалах. Это даст вам 12-кратную скорость записи по сравнению с одним диском и 24-кратную скорость чтения диска. Поскольку эти диски имеют скорость записи выше 100 Мбит / с, это должно легко справиться с пропускной способностью. Удостоверьтесь, что у вас нет дисков SMR, так как они имеют гораздо более низкую скорость записи.

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

Однако точные детали реализации во многом зависят от деталей.

Мы привязали данные дампа сетевой карты 10G к кластеру Gluster через их плавкий клиент. Требуется небольшая настройка, вы не поверите, что производительность, которую он может достичь с версии 3.0.