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

Укажите оборудование для минимальной скорости передачи

Я, возможно, буду работать над системой, которая собирает изображения с системы технического зрения и хранит их в дБ вместе с информацией о состоянии. Поскольку система привязана к непрерывному производственному процессу, работающему на высокой скорости, потребуется высокая скорость передачи данных. От SF я хотел узнать, как вы подберете систему, отвечающую моим требованиям.

Физически система устроена так:

Что касается скорости передачи данных, система должна будет получать как минимум 40-80 МБ изображений в секунду (примерно 2 МБ на изображение).

Возможные улучшения включают разделение db / webserver на две системы. Сохранение только путей к файлам в дБ и получение компьютера для сжатия BMP в JPG или PNG.

Какую же базовую статистику мне нужно указать для этого?

Спасибо за совет

редактировать Исправлены размеры для чтения МБ

редактировать Забудьте, что я упомянул слово «камера» и заменил его на «magical-box-that-drop-2MB-files-into-computer-by-ftp»

Изменить 24 февраля Извините людей, которые ответили, и похоже, что я вас игнорировал. Проект был приостановлен на некоторое время, когда они поняли, что не все компоненты в системе на самом деле имеют Ethernet (да, я должен размещать на TDWTF)

Первые новости. Когда сказали об общих требованиях к данным, спецификации были отклонены. Теперь мне нужно архивировать только 6 или 7 однострочных текстовых файлов каждую секунду, и только при возникновении проблемы архивируйте полные изображения размером 2 МБ. Поскольку производственный процесс, в котором все это работает, должен давать хороший продукт, это должно быть редкостью. Также они отключают линию, если есть несколько сбоев подряд .. так что средняя пропускная способность данных все еще будет низкой, и я могу буферизовать вставки на диске, пока не догоню (при необходимости)

Теперь перейдем к ужасной истории. Хотя я действительно ценю советы, данные о том, как построить надежную систему, я сегодня узнал, что для проекта был куплен «этот» (да - единственный) компьютер (и я вообще не имел права голоса в его спецификациях). Я уверен, что это хороший компьютер, но на моем столе начинают появляться выемки в форме головы, когда мне интересно, как, черт возьми, это будет работать с Dell Optiplex 760.

Я выберу самый хороший ответ и награду его своим выбором

На самом деле все это хорошие ответы. Жаль, что я не могу разделить свой голос.

Мне пришлось немного подумать об этом, так что извиняюсь за задержку с ответом к вам.

Если бы я строил это, я бы сделал следующее;

  • Выделенный сервер БД (или кластер) любого вкуса, который вам удобнее всего.
  • Купите двухконтроллерную коробку NetApp приличного размера, что-то вроде 3140 с 4 портами 10 Гбит / с. Настройте на нем vFiler на базе SAS емкостью 1–2 ТБ в качестве портала получения FTP, файлы попадают в этот общий ресурс, а также доступны через SMB или NFS. Затем настройте второй vFiler гораздо большего размера SATA (или SAS в зависимости от бюджета), который будет использоваться через SMB или NFS.
  • купить N серверы, подключенные к NetApp через двойные каналы 1 Гбит / с или 10 Гбит / с, они смотрят на FTP "Watch Folder", назначают себе управление одним набором файлов через крошечный файл флага, копируют изображения в более крупный файловый сервер и создают запись в БД указав окончательное расположение файлов, как только это будет завершено, удалите оригиналы, включая файл флага управления. Потом ищите другую работу, повторяйте, полощите.

Кстати, вам понадобятся достаточно мощные брандмауэры, маршрутизаторы, балансировщики нагрузки и коммутаторы.

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

Затем вы можете создать внутреннюю функциональность для запроса к БД и получения изображений по мере необходимости, не влияя на производительность входящего трафика.

Дайте мне знать, если вы хотите, чтобы я подробно остановился на этом.

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

Ты абсолютно должен чтобы сделать раунд тестирования производительности, прежде чем приступить к этому. Это может означать получение демонстрационных модулей от поставщиков оборудования. Позвоните одному из них и поговорите, продавцы имеют право организовать демонстрации оборудования, которые вы можете использовать в течение недели или двух. И IBM, и HP неплохо подходят для этого.

Я очень обеспокоен тем, что неуклюжий метод передачи файлов (BMP и FTP) сочетается с ожиданием высокой производительности. Вы столкнетесь с проблемами, особенно с тем, насколько быстро FTP может обрабатывать соединения. За дополнительные деньги, которые вы в конечном итоге потратите на серверы, вы можете потратить деньги на более гибкие камеры. Каким образом эти камеры могут подключиться к FTP-серверу? Это ip-камеры?

Примерная архитектура: 2 сервера связи, обрабатывающие получение файлов, ввод данных в базу данных, а затем передачу на веб-сервер или хранилище в сети SAN. Два гигабитных сетевых адаптера на каждом, два четырехъядерных ядра для обработки изображений, минимальный объем локального хранилища. 1 сервер БД. Спецификации для этого просто должны быть средними, в зависимости от того, где вы собираетесь выполнять свою обработку, и сколько метаданных и статистики вы хотите сохранить, и сколько одновременных пользовательских подключений вы будете обслуживать. 1 или 2 веб-сервера. Опять же, спецификации полностью зависят от количества пользователей, которых вам нужно поддерживать, будь то общедоступный или частный веб-сайт, и от того, где вы решите обрабатывать свои изображения.

То, что вы пытаетесь достичь, звучит так, будто это может быть какая-то система мониторинга производственного процесса. Если это так, то эту работу следует оставить на усмотрение специалистов в этой области (SCADA и т. Д.). Эти системы ужасно дороги, критичны к безопасности и недоработаны, и наличие специальной команды, которая слабо связана с ИТ, - это очень хорошо (tm)

В ответ на ваше разъяснение относительно объема собираемых вами данных такой объем представляет собой серьезную проблему. Вы указываете, что это связано с какой-то производственной установкой, поэтому я предполагаю, что это будет требование 24x365. Я собираюсь обсудить здесь только объемы хранения - другие прокомментировали архитектуру обработки, но я думаю, что важно, чтобы вы получили представление о масштабе всего решения.

При 40 МБ / с вы получаете полпетабайта в год, если это длительный процесс, и вам нужно хранить все файлы в разумном хранилище. Если вам действительно нужно это сделать, то любое решение для хранения данных, которое вы можете предоставить, с гораздо более быстрой производительностью ввода-вывода, чем вам нужно. Как минимум, если бы я покупал полпетабайта хранилища у поставщика, я бы хотел, чтобы он мог обеспечить несколько хороших вариантов быстрого дискового хранилища, а также объем. Независимо от того, как вы его построите, полпетабайта дискового хранилища будет дорого и займет большой кусок пространства в стойке. Дисковые массивы 6x48 с дисками SATA емкостью 2 ТБ будут съедать половину стойки 42U и потреблять пару киловатт только для того, чтобы продолжать вращаться.

На самом деле нет необходимости тратить так много места на диске - вы хотите отказаться от формата BMP, прежде чем переносить их в свое средне-долгосрочное хранилище. Если вы хотите сохранить вещи без потерь, PNG должен сэкономить вам от 60% до 90% по сравнению с BMP, если сжатие с потерями не является такой большой проблемой, тогда JPEG определенно сэкономит вам 80-95%, поэтому создайте стек обработки, который преобразует BMP раньше Вы сохраняете его в постоянном хранилище. Даже в этом случае вы захотите иметь около 50 ТБ хранилища для данных за год, что не будет дешево, но вы можете найти \ построить это по цене среднего автомобиля, а не по стоимости типа Ferarri, которую вам установит что-то в масштабе петабайтов. назад. Если вы покупаете такое количество места, он также сможет легко предоставить вам высокую пропускную способность ввода-вывода, необходимую для начальной разгрузки камеры и для вашей базы данных.

Ваша база данных также не будет тривиальной - если эта скорость захвата будет поддерживаться (что я предполагаю, что это так, если это для производственного процесса), тогда вы будете добавлять почти 2 миллиона записей в день - 3/4 миллиарда в год. . Если каждая запись составляет всего около 1 КБ, ваша БД будет 600 ГБ. Существует множество решений, которые могут справиться с этим, но это ни в коем случае не маленькая БД.

Если мои предположения о том, что это процесс 24x7 с постоянной скоростью передачи данных, неверны, то, конечно, все это чрезмерно, но даже если это работает только 8x5, а не 24x365, вам понадобится довольно большой и надежный (дорогой) SAN и Тогда не имеет смысла пытаться втиснуть все службы поддержки (веб-интерфейс \ DB \ обработка изображений) в одну коробку.