Сценарий масштабирования с несколькими веб-сервером и общими файлами - PullRequest
0 голосов
/ 11 мая 2018

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

У меня будет около 500 ГБ (или даже больше) образов продукта и некоторыеPDF-файлы, поскольку у нас больше клиентов позже.

Мне бы хотелось иметь минимальный набор файлов (файлы HTML и javascript) на веб-серверах (вначале 2 или 3) и общий каталог, в котором будут находиться все изображения продуктов.У меня будет некоторый автономный бэкэнд-процесс Java, который будет загружать изображения и сохранять их в общем каталоге, поэтому, когда запрос отправляется на любой веб-сервер, клиент должен иметь возможность просматривать изображения и файлы PDF.

У меня будет Spring MVC в бэкэнде, а сеанс будет обрабатываться кластером Redis, поэтому я не беспокоюсь об этой распределенной обработке сеанса.

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

Я прочитал NFS, которая может быть доступна с веб-серверов.

Мне интересно, является ли эта NFS хорошим решением для этого варианта использования.Я уверен, что этот вариант использования может быть общей проблемой.

Есть ли лучший вариант вместо NFS?

Спасибо.

1 Ответ

0 голосов
/ 12 мая 2018

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

По дешевке:
1) у вас есть 2 или 3 сервера. Поэтому приобретите один большой диск на систему для хранения статических файлов и используйте rsync, чтобы убедиться, что они одинаковы. Большие диски дешевы, вы даже можете получить SSD! Это может вырасти на некоторое время.
2) то же самое с дисками и использовать что-то более развитое для обеспечения синхронизации. механизмы кластера или inotify сделали бы. Вы можете использовать гораздо больше программ.
3) NFS ок . Но это не очень хорошо работает с веб-серверами с высоким рейтингом. Итак, ваш файл есть и доступен, но если вы сильно пострадали, у вас будут проблемы с производительностью и / или сетью. У нас было это однажды, и мы сократили NFS, это замедляло работу сайта.
4) недостатки NFS можно минимизировать, используя кеширование на веб-серверах для частых изображений.

Дороже:
5) NAS. Существует специальное программное обеспечение NAS, которое можно настроить с помощью выделенной системы файлового сервера.
6) NAS, выделенное оборудование, супер быстро, дорого. Может расти, но $$$.
7) Распределенные статические файлы сервисов. Ex. Akamai. Они хранят файлы и распространяют их для ваших клиентов. Таким образом, их инфраструктура получает хиты. Но это приходит за плату. Установка не очень сложная, если вы можете себе это позволить. Вы платите по объему. К вашему сведению, это не одобрение, мы использовали его в моей последней компании, вероятно, есть другие поставщики, которые делают что-то подобное.

Это большая тема, надеюсь, я начал с некоторых идей.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...