У меня возникла проблема, связанная с тем, какой сервер выбрать для следующего сценария (реальная ситуация):
У меня есть сервер, на котором будут храниться некоторые видео, к которым можно получить доступ через веб-приложение, работающее на этом сервере. Будет около 100 (одновременных) пользователей, которые будут им пользоваться (обычно через планшеты или телефоны, но ПК также будут включены).
Можете ли вы дать мне несколько мыслей по поводу построения конфигурации оборудования для этого сервера? Операционная система, работающая на нем, будет Linux.
Заранее спасибо.
ПРАВКА I:
Веб-сервер, который я использую, — Apache HTTP, но весьма вероятно, что он будет действовать как прокси-сервер для Javaсервера (установленного на этой машине, конечно).
Другие приложения, которые будут работать на этом сервере:
- приложение для аутентификации
- заявление на администрирование.
Этот сервер также будет работать непрерывно (24/7).
решение1
Из вашего описания следует, что основным вариантом использования сервера будет потоковая передача видео 100 клиентам.
Учитывая это, двумя наиболее важными подсистемами для сервера будут:
- Сетевое соединение
- Система хранения
Чтобы определить их для производительности, вам нужно знать, какая пропускная способность вам требуется - это зависит от качества видео, которое вы будете обслуживать. Предполагая, что видео имеет скорость 1 МБ/с, для 100 пользователей и сеть, и системы хранения должны иметь возможность предоставлять 100 МБ/с (800 Мб/с для сети) данных.
Если пропускная способность сетевого соединения больше, чем может обработать один канал, и вы не можете позволить себе увеличить скорость канала (т. е. перейти с 1GbE на 10GbE/40GbE), то вы можете добавить больше каналов и либо объединить их на уровне 2, либо использовать несколько IP-адресов (по одному на канал) и распределить соединения через приложение. Также вы должны убедиться, что путь данных от сервера к клиентам может обработать емкость, нет смысла в том, чтобы сервер мог обеспечить 10 Гбит/с, если где-то в сети есть узкое место!
Для системы хранения данных вам необходимо убедиться, что она может обрабатывать как пропускную способность, так и количество IOPS (IOS в секунду) для обслуживания данных. Из наших расчетов выше, вам потребуется 100 МБ/с потокового чтения, но поскольку у вас 100 пользователей, система хранения данных должна быть способна обрабатывать не менее 100 IOPS. Если вы ожидаете, что пользователи будут просматривать видео, вам понадобится гораздо больше для поддержания производительности. Хотя жесткие диски могут обеспечивать хорошую производительность потоковой передачи, когда у них нет конкуренции, я бы рассмотрел SSD, когда количество одновременных доступов увеличивается.
Помимо этих основных характеристик производительности, вам также необходимо учитывать надежность как сетевых подключений, так и систем хранения данных. Что происходит в случае сбоев связи или сбоев жесткого диска? Если вы хотите продолжать предоставлять услуги, у вас должно быть несколько связей и устойчивая конфигурация хранения (через RAID или репликацию данных на уровне приложения/файловой системы).
ОЗУ для системы хранения поможет вам кэшировать видео и снять часть нагрузки с системы хранения, поэтому если вы ожидаете, что много людей будут просматривать одно и то же видео, то больше ОЗУ, как правило, поможет. Но если размер рабочего набора (данных, к которым обычно обращаются) больше, чем объем ОЗУ в системе, не удивляйтесь, если вы не увидите большого улучшения.
Поскольку большая часть системы будет доставлять данные через IO, вам, вероятно, не понадобится много мощности ЦП, поэтому любого современного многоядерного ЦП будет достаточно. Хотя вам следует позаботиться о том, чтобы при наличии нескольких ЦП в архитектуре NUMA вы не перегружали межсоединение ЦП.
После того, как у вас есть оборудование, вы должны протестировать его, чтобы убедиться, что оно обеспечивает производительность. Для системы хранения я рекомендуюфиоинструмент, позволяющий вам специально тестировать сценарии, такие как потоковое чтение со 100 одновременными чтениями.
Учитывая все, что я сказал выше, вам следует поговорить с вашим предпочтительным поставщиком и узнать, какую конфигурацию они рекомендуют. Если вы сделаете свои требования частью RFP (особенно если вы включите жесткие требования, такие как возможность предоставить определенный профиль ввода-вывода), то это может облегчить устранение любых недостатков в производительности в дальнейшем.
При проектировании таких систем постарайтесь продумать, как данные перемещаются по системе и где будут возникать ограничения.
Наконец, убедитесь, что вы проектируете систему с избыточной пропускной способностью, чтобы вы могли справиться как с ростом, так и с пиками трафика.
решение2
Трудно предоставить точную конфигурацию сервера в зависимости от количества одновременных пользователей, так как это также зависит от вашего кода и оптимизации базы данных. По сути, вам нужно выполнить бенчмаркинг для вашего приложения и сервера, поэтому для этого доступно множество инструментов с открытым исходным кодом, например:
Вы можете провести полный бенчмаркинг, а также стековый бенчмаркинг.
Такие инструменты, как
- аб
- http_load
- sysbench
- unixbenchmark
и т.д. доступны.
решение3
Можете ли вы дать мне несколько мыслей по поводу построения конфигурации оборудования для этого сервера? Операционная система, работающая на нем, будет Linux.
да. используйте двойной размер.</irony>
нет, на данном этапе это невозможно. вы можете использовать машину с 4 ядрами и 4 ГБ оперативной памяти или mot, это действительно зависит от того, что вы будете с ней делать. если вы просто обслуживаете загрузки из файловой системы, то небольшая машина будет в порядке, но когда дело доходит до Java и т. д. ... бенчмарк!
чтобы быть более конкретным, вы и сами должны быть более конкретными.
- какой веб-сервер?
- сервер предназначен только для скачивания?
- дополнительное веб-программное обеспечение, такое как cms и т. д.?
- полный комплект LAMP?
- Требуется 24/7?
Я бы порекомендовал nginx, если вашей основной целью является доставка видео и работа в качестве обратного прокси-сервера для вашего Java-приложения. Он гораздо легче Apache и обрабатывает больше одновременных подключений, при этом требуя меньше системных ресурсов.
для раздела загрузок постарайтесь избегать веб-приложений и обслуживать файлы напрямую через обратный прокси-сервер; это снизит общую необходимую производительность.
обратите внимание, что у nginx есть несколько замечательных модулей, которые могут выступать в качестве статического сервера для видео.
относительно 24/7: вам нужногарантироватькруглосуточной работы? Тогда вам понадобится настройка отказоустойчивости.