Apache avec Nginx

Vous pouvez optimiser le fonctionnement du serveur Web qui héberge les sites Web des clients (Apache) en installant Nginx, un autre serveur Web extrêmement performant généralement utilisé en tant que serveur proxy inversé. Ce serveur Web a été spécialement conçu pour prendre en charge de larges volumes de contenu statique (comme les images, vidéos, css, xml, etc.). Contrairement à Apache, Nginx est beaucoup plus efficace pour traiter un gros volume de connexions simultanées. Autre atout de ce serveur Web par rapport à Apache : Nginx utilise beaucoup moins de mémoire par connexion client.

Pour profiter de tous les avantages de Nginx, Plesk le configure en tant que serveur proxy inversé situé entre Internet et Apache (cf. le schéma ci-dessous). Autrement dit, Nginx devient un serveur Web frontal qui traite toutes les requêtes entrantes des visiteurs des sites. Les requêtes sont envoyées vers Apache, qui, en retour, différencie les requêtes pour le contenu statique et dynamique. Si une requête est destinée à un fichier statique (comme jpg, css, html, etc.), Apache passe la demande à tous les gestionnaires ou gestionnaires enregistrés (applique la configuration au niveau du répertoire .htaccess, réécrit une URL, etc.) et renvoie à Nginx une réponse qui ne contient qu’un emplacement du fichier requis sur le système de fichiers. Nginx localise le fichier et l’envoie au client. Si la requête est destinée à un fichier dynamique (comme un script PHP), Apache exécute le fichier et envoie la réponse à Nginx, qui la fournit au client.

Une telle combinaison de Nginx et Apache apporte les avantages suivants :

• Augmentation du nombre maximum de connexions simultanées à un site Web.
• Diminution de l’utilisation des ressources mémoire et CPU du serveur. L’effet maximum sera atteint pour les sites Web avec un large volume de contenu statique (comme les galeries de photos, les sites de streaming vidéo, etc.).
• Amélioration de l’efficacité en matière de prestations fournies aux visiteurs avec une connexion Internet lente (GPRS, EDGE, 3G, etc.). Par exemple, un client avec une connexion à 10 Ko/s a besoin d’un script PHP qui génère une réponse à 100 Ko. Si le serveur ne dispose pas de Nginx, la réponse est fournie par Apache. Pendant les 10 secondes requises pour envoyer la réponse, Apache et PHP continuent d’utiliser toutes les ressources du système pour cette connexion ouverte. Si Nginx est installé, Apache transfère la réponse à Nginx (la connexion Nginx vers Apache est très rapide, les deux étant sur le même serveur) et libère ainsi des ressources système. Comme le volume de mémoire de Nginx est plus faible, la charge générale sur le système diminue. S’il y a beaucoup de connexions lentes de ce type, l’utilisation de Nginx optimisera largement la performance du site Web.

Vous trouverez plus de détails techniques sur la manière dont Plesk traite les requêtes HTTP avec Nginx dans cette section. Pour en savoir plus sur l’activation de l’assistance de Nginx dans Plesk, consultez la section Installer Nginx. Si vous ne voulez pas utiliser Nginx, faites d’Apache votre serveur Web frontal en procédant comme décrit dans la section Désactiver Nginx. Si vous souhaitez que Nginx traite toutes les requêtes HTTP pour le contenu Web, consultez la section Ajuster les paramètres du serveur Web Apache.

Traitement des requêtes HTTP par Plesk avec Nginx

Pour intégrer sans problème Nginx à Apache, Plesk utilise deux modules Apache supplémentaires :

• mod_aclr2. Ce module configure un gestionnaire qui s’exécute après les gestionnaires de tous les autres modules Apache (mod_rewrite, modules associés .htaccess, mod_php, etc). Par conséquent, si la requête est destinée au contenu dynamique, mod_aclr2 ne l’obtiendra jamais car la requête sera servie par des gestionnaires de niveau supérieur de certains modules Apache (mod_php, mod_perl, mod_cgi, etc.). Les seules exceptions sont les requêtes SSI : une fois qu’elles atteignent mod_aclr2, il les redirige vers les gestionnaires corrects. Si la requête est destinée à un fichier statique, mod_aclr2 recherche l’emplacement exact du fichier sur le système de fichiers et envoie l’emplacement à Nginx.
• mod_rpaf ou .mod_remoteip Du point de vue d’Apache, tous ses clients ont la même adresse IP, l’adresse du serveur Nginx (cf. le diagramme ci-dessus). Cela entraîne des problèmes avec les sites Web et les applications Web qui utilisent les adresses IP des clients à des fins d’authentification, de statistiques, etc. mod_rpaf (dans Apache 2.2) ou mod_remoteip (dans Apache 2.4) résout le problème en remplaçant l’adresse IP du serveur Nginx dans toutes les requêtes par des adresses IP clientes. Pour être plus précis, le module utilise l’en-tête spécial X-Forwarded-For (X-Redirigée-Pour) dans laquelle Nginx place l’adresse IP d’un client.

Regardons de plus près comment Plesk traite les requêtes pour le contenu statique et dynamique à l’aide de ces modules.

La séquence de traitement d’une requête HTTP pour un fichier statique se présente comme suit (cf. le schéma) :

1. Un client envoie une requête à un serveur Web.
2. Nginx ajoute les en-têtes X-Accel-Internal (utilisée par mod_aclr2) et X-Forwarded-For (contient l’adresse IP du client) à la requête qu’il envoie à Apache.
3. Apache reçoit la requête et initie le traitement par des gestionnaires enregistrés (applique la configuration .htaccess, réécrit l’URL, etc.). À cette étape, mod_rpaf remplace l’adresse IP du serveur Nginx dans la variable d’Apache REMOTE_ADDR par l’adresse du client à partir de l’en-tête X-Forwarded-For.
4. Une fois la requête traitée par tous les gestionnaires enregistrés, elle atteint mod_aclr2. Le gestionnaire vérifie la présence de l’en-tête X-Accel-Internal. Si l’en-tête est présent, le module envoie à Nginx une réponse avec une longueur de contenu nulle et l’en-tête X-Accel-Redirect. L’en-tête contient l’emplacement exact du fichier tel qu’il est déterminé par mod_aclr2.
5. Lorsque Nginx reçoit la réponse, il localise le fichier et le remet au client.

Le schéma ci-dessous illustre comment Plesk traite la requête d’un fichier GIF de 2 Ko.

En cas de traitement des requêtes de contenu dynamique, les étapes 1 à 3 sont identiques. Ensuite, la requête passe dans le gestionnaire du module Apache approprié (mod_php, mod_perl, mod_cgi, etc.). La requête n’atteint jamais mod_aclr2 (sauf les requêtes SSI). Le gestionnaire génère une réponse et l’envoie à Nginx, qui, en retour, remet la réponse au client. Le schéma ci-dessous illustre comment Plesk traite une requête de fichier PHP.

Installer Nginx

Lorsque vous réalisez une installation conforme de Plesk, Nginx est activé par défaut. Si vous mettez à niveau depuis une version antérieure, vous pouvez ajouter le composant « Nginx web server » à tout moment après la mise à niveau dans Outils & Paramètres > Mises à jour (sous « Plesk ») > Ajouter ou supprimer des composants. Une fois que vous avez ajouté le composant, démarrez le service Reverse Proxy Server (Nginx) dans Outils & Paramètres > Gestion des services (sous « Gestion des serveurs »).

Vous pouvez voir la version du serveur Nginx installée dans Outils & Paramètres > Composants du serveur (sous « Gestion des serveurs »).

Désactiver Nginx

Pour revenir à la configuration avec un seul serveur web Apache, stoppez le service Reverse Proxy Server (Nginx) dans Outils & Paramètres > Gestion des services (sous « Gestion des serveurs »).

Pour rétablir Nginx dans le serveur Web frontal, lancez le service Reverse Proxy Server (Nginx).

Note

Les opérations de démarrage et d’arrêt du service Reverse Proxy Server (Nginx) ne démarrent et n’arrêtent pas simplement Nginx, elles activent la configuration du serveur Web (combinaison de Nginx et d’Apache ou juste Apache en tant que serveur Web frontal). L’opération de redémarrage fonctionne de la même manière pour tous les autres services : le service Nginx est redémarré.