Найкращий спосіб ділитися каталогом завантажень файлів через горизонтальне масштабування веб-серверів

На даний момент я намагаюся розглянути кластер, що горизонтально масштабується, для веб-програми, заснованої на друпах, яка виглядає приблизно так, як барвиста діаграма нижче:

Балансир навантаження реалізує липкі сеанси, тому користувач зберігає стан після того, як йому буде призначений сервер для роботи.

Кожен сервер додатків має:

• лак спереду
• drupal 6 посередині працює на ламповому стеку
• запам’ятовується ззаду

Два сервери баз даних mysql знаходяться на спільному IP-адресі, і вони знаходяться в кластері HA з DRBD та чутливим звуком, так що втрата одного не зведе всю платформу.

Є кілька речей, в яких я не впевнений, що я буду вдячний за ваші думки щодо:

Як слід зберігати шкалу зберігання по горизонталі?

Я думаю використовувати NFS для монтажу спільного файлу файлів на кожному сервері додатків, тому файл, завантажений в один раз, буде доступний для всіх. Я думаю про NFS, тому що це вже багато років, і я не маю досвіду роботи з MogileFS або GlusterFS, і це щось, що ми використовували раніше, тому ми з ним більше знайомі.

Чи існують якісь вказівки, які слід дотримуватися, щоб розробити, на скільки серверів розумно ділитися каталогом через NFS таким чином?

Як слід надавати HA на спільному зберіганні файлів тут?

Однією з проблем є те, що сервер NFS є єдиною точкою відмови.

Ми вже використовуємо Heartbeat і DRBD на серверах Mysql, і я вважаю за краще, щоб кількість технологій, що задіяні в стеку, було якомога меншим - які підводні камені були б, якби я використовував ту саму стратегію HA для файлу сервери теж?

Альтернативний підхід

Це стосується внутрішнього веб-сайту із обмеженою кількістю користувачів, які періодично користуються сайтом дуже інтенсивно протягом коротких періодів, коли внутрішня ініціатива працює. Тому для цього не потрібно нескінченно масштабувати, як деякі стартапи.

Враховуючи це

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

Я також розглядаю можливість просто зробити два веб-сервери beefier, щоб вони могли обробляти пікове навантаження між ними, а також встановлювати унісон, або rsync через них на роботу з кроном, щоб:

• вони файли все ще синхронізовані (липкі сеанси підтримують користувача на тому самому сервері, на який він завантажив файл)
• втратити один означає, що сайт все ще працює.

Це звучить як можливий спосіб подолати будь-які можливі головні болі складності НФС / DRBD HA?

Дякую,

С

Сервер NFS повинен мати принаймні те саме забезпечення, що і сервер MySQL, оскільки вони мають в основному однакові функції та обмеження (обидва - це місця, куди ви записуєте дані). Мені не подобається ідея декількох авторів для NFS, вона робить дуже складним управління блоками файлів, і мій досвід не дуже вдався з цього приводу.

Моя пропозиція полягає в тому, щоб сконцентрувати всі записи на одному з серверів додатків (можливо, один сервер додатків, призначений для запису на сервері NFS), і кілька серверів додатків для читання, що монтують його лише для читання (я знаю, що в drupal є деякі динамічні ескізи, які потрібно бути написаним, але ви можете зберегти його найбільше на RO fs). Вам знадобиться принаймні другий сервер NFS (використання DRBD - найкращий вибір тут, якщо у вас немає спільного сховища, наприклад, SAN) для забезпечення HA.

Нарешті, подивіться на Gluster та інші розподілені системи.

Ви можете спробувати mogileFS. Я використовував це один із наших проектів. Він простий у використанні та конфігуруванні і може масштабувати, і немає жодних точок відмови.

http://danga.com/mogilefs/

Найкращий спосіб - знайти хороше рішення для зберігання. Залежно від масштабу та типу програми ви можете використовувати хороший NAS, підтримуючи NFS та принаймні два гігабітні порти та джерела живлення (замовити деякі рішення підприємства).

Якщо ви дійсно серйозно ставитесь до своєї програми, найкраще поставити підказку щодо SAN-рішень, але це може бути дуже дорого, оскільки це вимагає спеціального обладнання (це можна зробити за допомогою апаратного забезпечення, але це може бути занадто повільно).