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

Конфигурация сервера на 100 пользователей

У меня проблема, связанная с тем, какой сервер выбрать для следующего сценария (реальная ситуация):

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

Не могли бы вы поделиться некоторыми мыслями о создании конфигурации оборудования для этого сервера? Операционная система на нем будет Linux.

Заранее спасибо.


ИЗМЕНИТЬ I:

Я использую веб-сервер Apache HTTP, но вполне вероятно, что он будет действовать как прокси для Java сервер (установлен конечно на этой машине).

Другие приложения, которые будут работать на этом сервере, будут:

Этот сервер также будет работать постоянно (24/7).

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

Вы также можете выполнить полный бенчмаркинг, а также бенчмаркинг стека

Такие инструменты, как

  1. ab
  2. http_load
  3. sysbench
  4. unixbenchmark

и т. д. доступны.

Судя по вашему описанию, основным вариантом использования сервера будет потоковая передача видео 100 клиентам.

Учитывая это, двумя наиболее важными подсистемами для сервера будут:

  1. Сетевое подключение
  2. Система хранения

Чтобы определить их производительность, вам необходимо знать, какая пропускная способность вам требуется - это зависит от качества видео, которое вы будете обслуживать. Предполагая, что скорость видео составляет 1 МБ / с, для 100 пользователей и сеть, и системы хранения должны иметь возможность передавать 100 МБ / с (800 МБ / с для сети) данных.

Если соединение с пропускной способностью сети больше, чем может обработать один канал, и вы не можете позволить себе увеличить скорость канала (например, перейти с 1GbE на 10GbE / 40GbE), вы можете добавить больше ссылок и либо агрегировать их на уровне 2, либо использовать несколько IP-адрес (по одному на ссылку) и раздайте соединения через приложение. Кроме того, вы должны убедиться, что путь данных от сервера к клиентам может обрабатывать пропускную способность, нет смысла в том, чтобы сервер мог передавать 10 Гбит / с, если есть узкое место в другом месте в сети!

Для системы хранения необходимо убедиться, что она может обрабатывать как полосу пропускания, так и количество операций ввода-вывода в секунду (операций ввода-вывода в секунду) для обслуживания данных. Согласно нашим расчетам, приведенным выше, вам потребуется 100 МБ / с потокового чтения, но поскольку у вас 100 пользователей, система хранения должна поддерживать не менее 100 операций ввода-вывода в секунду. Если вы ожидаете, что пользователи будут перемещаться по видео, вам потребуется гораздо больше для поддержания производительности. В то время как жесткие диски могут обеспечивать хорошую производительность потоковой передачи, когда у них нет конкуренции, я бы рассмотрел SSD, когда количество одновременных доступов увеличивается.

Помимо этих основных характеристик производительности, вам также необходимо учитывать надежность как сетевых подключений, так и систем хранения. Что происходит в случае сбоев связи или сбоев жесткого диска? Если вы хотите продолжить предоставление услуг, у вас должно быть несколько каналов и гибкая конфигурация хранилища (через RAID или репликацию данных на уровне приложения / файловой системы).

ОЗУ для системы хранения поможет вам кэшировать видео и снять некоторую нагрузку с системы хранения, поэтому, если вы ожидаете, что много людей будут просматривать одно и то же видео, как правило, поможет больше ОЗУ. Но если размер рабочего набора (обычно используемых данных) больше, чем объем оперативной памяти в системе, не удивляйтесь, если вы не увидите значительного улучшения.

Поскольку большая часть системы будет доставлять данные через ввод-вывод, вам, вероятно, не потребуется много мощности процессора, поэтому любого современного многоядерного процессора должно хватить. Хотя вам следует позаботиться о том, чтобы при наличии нескольких процессоров в архитектуре NUMA вы не перегружали межсоединение процессора.

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

Учитывая все, что я сказал выше, вам следует поговорить с вашим предпочтительным поставщиком и посмотреть, какую конфигурацию они рекомендуют. Если вы сделаете свои требования частью RFP (особенно если вы включите жесткие требования, такие как возможность доставки определенного профиля ввода-вывода), это может упростить устранение любых сбоев в производительности позже.

При разработке этих систем постарайтесь подумать о том, как данные перемещаются в системе и где будут ограничения.

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

Не могли бы вы поделиться некоторыми мыслями о создании конфигурации оборудования для этого сервера? Операционная система на нем будет Linux.

да. используйте двойной размер. </irony>

нет, с этого этапа невозможно. вы можете использовать RAM 4core-4GB или мотор, это действительно зависит от того, что вы с ним будете делать. если вы просто обслуживаете загрузки из файловой системы, тогда небольшая машина будет в порядке, но когда дело доходит до java и др. ... Benchmark!


чтобы быть более конкретным, вы должны быть более конкретными и сами.

  • какой веб-сервер?
  • сервер только для скачивания?
  • дополнительное веб-программное обеспечение, такое как cms и т. д.?
  • полный LAMP-стек?
  • 24/7 нужен?

Я бы предложил nginx, если основная цель - доставка видео и действовать как обратный прокси для вашего java-приложения. он намного легче, чем apache, и обрабатывает больше одновременных подключений, требуя при этом меньше системных ресурсов.

для раздела загрузок старайтесь избегать использования веб-приложений и обслуживать файлы напрямую через обратный прокси-сервер; это снизит общую необходимую производительность.

обратите внимание, что nginx имеет несколько прекрасных модулей для работы в качестве статического сервера для видео


по поводу 24/7: нужно ли вам обеспечить операции 24/7? тогда вам понадобится настройка аварийного переключения.