У меня возникли проблемы с конфигурацией хранилища для обмена файлами, которую мы недавно настроили. Недавно мы перешли на NAS (1x24TB) для нашей службы потокового видео. Мы настроили 9 внешних серверов, которые будут взаимодействовать с NAS с помощью NFS, и у нас возникли проблемы. Поскольку существует так много запросов к файлам и только «1 физический» диск, NAS-сервер не справляется со всеми запросами, оставляя нас с проблемами ввода-вывода.
В любом случае мы решили, что хотим перейти на другую конфигурацию, потому что настройка NAS не подходит для нас. Я думаю, это не идеально для сотен случайных загрузок файлов.
Где ищу альтернативное решение. Мы хотели настроить два кластера из 4 серверов и использовать gluster на каждом кластере, но я не думаю, что это лучшее решение. Мы также думаем о настройке mogilefs на кластере из 8 серверов, однако нам нужно использовать nginx для серверных файлов, а это невозможно сделать с помощью mogilefs.
Может ли кто-нибудь порекомендовать несколько идей для более масштабной службы обмена файлами, которая обеспечила бы некоторую избыточность и масштабируемость? Я не эксперт, и я впервые пытаюсь настроить что-то настолько большое.
Другая конфигурация, заслуживающая некоторого внимания, - это использование 9 серверами nginx параметра proxy_cache для хранения копии файла по мере его обслуживания, поэтому второй запрос того же файла обслуживается с ЛОКАЛЬНОГО диска сервера. Вы можете установить для этого кеша ограниченный размер и хранить файлы в течение ограниченного времени. Это снизит нагрузку на ваш NFS-сервер и не потребует репликации данных на каждый узел.
Когда файлы локальны, вы также можете использовать функцию sendfile ОС, которая позволяет ядру взять на себя отправку данных в сокет, вместо того, чтобы делать это nginx, это значительно увеличивает производительность, но не рекомендуется для NFS.
Название вашего вопроса не имеет ничего общего с тем, что вы просите.
Используя общую файловую систему, вы столкнетесь с проблемами масштабируемости - вы можете отложить момент, когда это станет проблемой, используя SAN (даже если это всего лишь iSCSI 10 ГБ), но для вашего приложения, где очень мало операций записи и (предположительно) обновления должны быть только почти в реальном времени, а не атомарными, я бы рекомендовал использовать либо распределенную одноранговую, либо реплицированную файловую систему.
AFAIK, есть ограниченные возможности для готовых решений для файловых систем ptp, но реализовать это в вашем приложении было бы тривиально.
Реплицированные файловые системы - это гораздо более зрелая технология - в наши дни AFS входит в стандартную комплектацию Linux.
Вам лучше взглянуть на Блеск + DRBD. Первый, вероятно, обеспечит желаемую масштабируемость. Я думал о DRDB только из-за избыточности на уровне блочного устройства. Хотя я не тестировал эту установку и не могу много сказать о ее производительности. Сообщите мне свои улучшения.
Скажи мне, если ты когда-нибудь получишь GridFS на MongoDB в состоянии «диск заполнен» или «не хватает ресурсов».