Nota: en mi respuesta de respuesta Supongo que está utilizando Apache. Mi respuesta será correcta incluso si está utilizando algún otro servidor como nginx etc.
escribe:
Sin embargo, no parece ser capaz de conseguir lejos con Drupal, el principal problema en el este punto es ser capaz de salvar a todos los variables de sesión en MySQL, por lo indepdent de qué servidor del equilibrador de carga envía la solicitud a la solicitud tiene un único punto de referencia en lo que respecta a sessions.reference en lo que respecta a sesiones
Las sesiones son algo que se manejan a nivel de núcleo de PHP y a nivel Drupal + MySQL. Esencialmente, cuando un navegador accede a su servidor, la lógica de manejo de la sesión central de PHP asigna una cookie única PHPSESSID. Esta cookie es enviada por ese navegador en cada solicitud posterior.
[En una nota lateral, usando PHPSESSID, la lógica de la sesión central de PHP podría asociar otros datos como preferencias de comentarios, mensajes drupal que deben mostrarse en la vista de página siguiente, etc. Todo esto se hace usando la variable $ _SESSION PHP. PHP hace esto sin interrupciones.Tenga en cuenta que MySQL todavía no entra en la imagen hasta este punto. MySQL solo ingresa la imagen cuando se necesita asociar datos adicionales con un PHPSESSID como el ID de usuario, etc., de Drupal]
En resumen, PHP maneja algunas sesiones asignando la cookie PHPSESSID. Ahora digamos que el equilibrador de carga envía la solicitud a Apache Webserver 1 y mod_php (módulo PHP apache) asigna un PHPSESSID único, por ejemplo, "563" (es una cadena más larga en la vida real). Ahora próxima vez que este cliente tiene acceso a su sitio web, el PHPSESSID cookie se envía a través con el valor 563. Ahora podrían ocurrir dos casos diferentes:
- El equilibrador de carga (coincidentemente) envía la petición al Apache 1, que originalmente asignado la cookie PHPSESSID . Reconoce 567 y las cosas funcionan bien
- El equilibrador de carga envía la solicitud a Apache 2. PHPSESSID es 567 que Apache 2 mod_php nunca asignó. Entonces se confunde y asigna un nuevo PHPSESSID. Aquí es donde ocurren sus problemas.
Cómo solucionar su problema: El problema al que se enfrenta es un problema común. Simplemente necesita decirle al equilibrador de carga que una vez que un cliente se envía a un servidor web particular, el mismo servidor de web debe continuar atendiendo esa solicitud. Esto generalmente se hace al decirle al equilibrador de carga en sí que envíe una cookie que diga qué servidor tratar con la solicitud inicial. En el futuro, el cliente presenta esta cookie al equilibrador de carga y el equilibrador de carga dirige la solicitud al servidor original que se ocupa de la solicitud. Esto, como expliqué anteriormente, es importante porque solo ese servidor sabe sobre el PHPSESSID asignado.
Todos los equilibradores de carga decentes tienen la capacidad de asignar cookies. Busque los detalles de la configuración de su balanceador de carga.referencia en lo que respecta a las sesiones.
Más cosas para doblar la cabeza Después de haber resuelto el problema de las sesiones configurando su equilibrador de carga para asignar cookies, tendrá que considerar un problema más importante. La carpeta files de su servidor DEBE compartirse de alguna forma. Esto tiene sentido. Si un usuario carga una imagen en un servidor, otras personas que accedan al sitio a través del otro servidor deberían tener acceso a la misma imagen. Esto se logra mediante un montaje NFS (Networked File System) o una SAN.
Sólo luego tendrá una instalación de Drupal totalmente compatible con varios servidores. Como han señalado otras personas, es posible que desee consultar algunos artículos de referencia en la red. Se recomiendan optimizaciones adicionales, como almacenar la tabla de sesiones en Memcache y no en MySQL, pero nuevamente esto no tiene nada que ver con lo que escribí arriba. Las cookies de emisión del equilibrador de carga son realmente necesarias.
¿Por qué pasar por tanta pena que pregunto? He hecho cosas de servidores múltiples en el pasado y realmente no vale la pena a menos que su sitio reciba un tráfico serio. ¿Tu tráfico es lo suficientemente grande? Poner una capa de almacenamiento en caché como Varnish delante de Drupal o incluso mejor, usando el módulo boost debería resolver sus problemas si la mayoría de sus usuarios son anónimos.
Mira este video http://sf2010.drupal.org/conference/sessions/24-million-page-views-day-60-m-month-one-server. El chico está atendiendo un número loco de visitas a la página usando solo 1 servidor. Todo es mucho más simple con un servidor. ¡Pruébalo! Solo el más grande de los sitios web puede requerir varios servidores.
Esto es grande gracias – Amir
Lamento haber surgido un problema antiguo, pero no puedo entender por qué es necesario que un equilibrador de carga emita cookies. Las cookies se almacenan en el navegador, por lo que cada máquina puede leer los mismos datos de cookies y acceder a los mismos datos de sesión (almacenados unificados). Si cookie tiene session_id, ¿por qué la necesidad de mantener al usuario en una máquina específica? ¡Gracias! :) –
Cada webhead o servidor web tendrá su propio intérprete de PHP. Cada intérprete de PHP no sabrá sobre las sesiones de PHP de otros servidores web. El equilibrador de carga debe emitir cookies que asocian un navegador en particular con un servidor web particular. Entonces, cuando el navegador evalúa nuevamente el sitio, el equilibrador de carga reenviará la conexión al servidor web que conoce esa sesión particular de Drupal. –