Примечание: в моем ответе я предполагаю, что вы используете Apache. Мой ответ будет правильным, даже если вы используете какой-либо другой сервер, например, nginx и т. Д.
Вы пишете:
Однако я, кажется, не могу получить
далеко с Drupal, главная проблема в
этот момент должен быть в состоянии сохранить все
переменные сеанса в MySQL, так
независимо от того, какой сервер загружен
балансировщик отправляет запрос
приложение имеет одну точку
ссылка на сессии. ссылка на сессии.
Сессии - это то, что обрабатывается на уровне ядра PHP и на уровне Drupal + MySQL. По сути, когда браузер обращается к вашему серверу, логика обработки основного сеанса PHP назначает уникальный файл cookie PHPSESSID. Этот файл cookie отправляется этим браузером при каждом последующем запросе.
[В дополнение к этому, используя PHPSESSID, базовая логика сеанса PHP может связывать некоторые другие данные, такие как настройки комментариев, сообщения drupal, которые должны отображаться при просмотре следующей страницы и т. Д. Все это выполняется с помощью переменной PHP $ _SESSION. PHP делает это довольно легко. Обратите внимание, что MySQL все еще не входит в изображение до этой точки. MySQL входит в картину, только когда дополнительные данные должны быть связаны с PHPSESSID, такими как идентификатор пользователя и т. Д. От Drupal]
Короче говоря, PHP выполняет некоторую обработку сеанса, назначая файл cookie PHPSESSID. Теперь предположим, что балансировщик нагрузки отправляет запрос в Apache Webserver 1, а mod_php (модуль PHP apache) назначает уникальный PHPSESSID, скажем, «563» (это более длинная строка в реальной жизни). Теперь в следующий раз, когда этот клиент зайдет на ваш сайт, файл cookie PHPSESSID будет отправлен со значением 563. Теперь могут возникнуть два разных случая:
- Балансировщик нагрузки (по совпадению) отправляет запрос в Apache 1, который изначально назначил файл cookie PHPSESSID. Он распознает 567 и все работает нормально
- Балансировщик нагрузки отправляет запрос в Apache 2. PHPSESSID равен 567, который Apache 2 mod_php никогда не назначал. Так что он запутался и назначил новый PHPSESSID. Здесь возникают ваши проблемы.
Как решить вашу проблему : Проблема, с которой вы сталкиваетесь, является распространенной проблемой. Вам просто нужно сообщить балансировщику нагрузки, что после отправки клиента на определенный веб-сервер тот же веб-сервер должен продолжать обрабатывать этот запрос. Обычно это делается сообщением самому балансировщику нагрузки отправить файл cookie, сообщающий, какой сервер обрабатывает первоначальный запрос. В будущем клиент представляет этот файл cookie для балансировщика нагрузки, а балансировщик нагрузки направляет запрос на исходный сервер, который обрабатывает запрос. Это, как я объяснил выше, важно, потому что только этот сервер знает о назначенном им PHPSESSID.
Все приличные балансировщики нагрузки имеют возможность назначать куки. Посмотрите сведения о конфигурации для вашего баланса нагрузки в отношении сеансов.
Больше умопомрачительных вещей После того, как вы решили проблему сессий, настроив балансировщик нагрузки для назначения файлов cookie, вам нужно будет рассмотреть еще одну важную проблему. ДОЛЖЕН быть общий доступ к папке files на вашем сервере. Это имеет смысл. Если изображение загружено пользователем на один сервер, другие люди, получающие доступ к сайту через другой сервер, должны иметь доступ к тому же изображению. Это достигается с помощью NFS (Networked File System) mount или SAN.
Только , затем у вас будет полностью работающая многосерверная установка Drupal. Как уже отмечали другие люди, вы можете обратиться к некоторым справочным статьям в сети. Рекомендуется дальнейшая оптимизация, например, сохранение таблицы сессий в memcache, а не в MySQL, но опять же, это не имеет ничего общего с тем, что я написал выше. Файлы cookie для выдачи балансировки нагрузки действительно необходимы.
Зачем переживать столько горя, что я спрашиваю? В прошлом я занимался многосерверными вещами, и это не стоит того, если ваш сайт не получает серьезного трафика. Ваш трафик достаточно велик? Установка слоя кэширования, такого как Varnish, перед Drupal или даже лучше, использование модуля boost решит ваши проблемы, если большинство ваших пользователей анонимны.
Проверьте это видео http://sf2010.drupal.org/conference/sessions/24-million-page-views-day-60-m-month-one-server. Парень раздает огромное количество просмотров страниц, используя только 1 сервер. С одним сервером все намного проще. Попробуйте! Только самые большие веб-сайты могут требовать нескольких серверов.