Ce problème peut être résolu à la fois en utilisant RadWare AppDirector et (pour être complet) probablement également en utilisant Apache mod_security selon votre excellente conclusion dans le commentaire ci-dessous.
Pour une solution AppDirector, je pense qu'il est possible de créer deux batteries de serveurs mappant vers le (s) même (s) serveur (s) backend. Ces exploitations peuvent appliquer différents critères et conditions d'exploitation. Une batterie serait la "valeur par défaut" et l'autre répondrait aux URI: s que vous définissez comme étant "une session". Ce dernier obtiendrait une limite au nombre de sessions qu'il accepte dans l'équilibreur de charge.
Je vais désormais remplacer votre terme "session" par "connecté" pour deux raisons:
- Il évite toute ambiguïté car il définit clairement l'état souhaité dans lequel l'utilisateur est authentifié.
- Le Guide de l'utilisateur et l'interface graphique AppDirector redéfinit le terme «connexion» pour avoir une signification à toutes fins pratiques identique à «session», voir ci-dessous. Cela ajoute une confusion que nous essayons d'éviter.
Il est également possible d'afficher une page désolée si la batterie de serveurs «connectée» a atteint la limite de connexion choisie.
Avant de commencer, je dois clairement déclarer que je n'ai aucune expérience de fonctionnement du produit AppDirector, mais que j'administre quotidiennement un équilibreur de charge concurrent et légèrement moins avancé. Le produit que j'utilise peut faire ce scénario dès le départ. J'ai trouvé des informations dans le Guide de l'utilisateur AppDirector et la documentation en ligne disponible qui suggère que la même chose est vraie pour AppDirector. Cependant, bien que les concepts soient similaires, la terminologie est différente. Je fais simplement un acte quand à Rome en ce qui concerne le libellé, en espérant avoir les choses correctes sans être trop évidemment un crétin ignorant.
Le plus grand obstacle était d'avoir accès à un manuel, qui n'est disponible que si l'on est un client actif. Grâce à quelques recherches sur Google, il a été possible de trouver une ancienne version qui, je l'espère, n'est pas trop obsolète, j'ai également trouvé quelques articles de la base de connaissances et ce lien: Radware AppDirector - Configuration: Application de base .
Voici une ébauche de solution, telle qu'interprétée principalement par le guide de l'utilisateur:
L'entrée du client dans l'équilibreur de charge se fait via un VIP qui est utilisé pour connecter à la fois les sessions "par défaut" et les "sessions connectées". Ceci est réalisé grâce à une politique L4 selon p.99 dans le Guide de l'utilisateur:
"When AppDirector receives the first packet of a session destined to a
Virtual IP address, it searches for a Layer 4 Policy that matches the
Layer 4 Protocol, Destination port, Source IP, etc. Then, based on this
information, AppDirector selects the farm allocated to this service and
the best server for the task from that farm, and forwards the packet to
that server.
La politique L4 peut être liée aux politiques L7 qui sont utilisées pour sélectionner une batterie de serveurs appropriée. Le processus de stratégie L7 est décrit ainsi dans le Guide de l'utilisateur p.104:
"The Layer 7 content aware decision making mechanism allows you to have
a single point of entry to the site, and provides differentiated service
for different user groups.
A Layer 7 decision is made using a mechanism called Delayed Binding.
When Delayed Binding is used, AppDirector first performs a TCP handshake
with the client to receive the HTTP request. AppDirector parses the HTTP
request’s data, usually HTTP headers, and performs the load balancing
decision. Only after that, does AppDirector select a farm and a server.
Lastly, AppDirector initiates a TCP handshake with the server and
forwards the traffic to it
[...]
When Layer 7 Policies are used, farm selection is based on matching the
request data with a list of Layer 7 Policies defining the Layer 7
parameters differentiating the service. The process of server selection
within the farm can also be content-based, using a third Layer 7
parameter."
Les méthodes disponibles pour définir un comportement L7 sont décrites à la p.106, dont vous pouvez choisir une méthode appropriée pour choisir le routage vers votre batterie de serveurs "connectée" plutôt que vers la batterie de serveurs "par défaut":
"Methods are the basic building blocks for Layer 7 service selection.
They define content by which traffic is differentiated. You can use
the same Method to select one or more services. The following Method
Types are available:
- URL: Looks for a specified host name and/or path in the HTTP request.
- File Type: Looks for a specified File Type in the HTTP request.
- Header Field: Looks for a specified Header Field in the HTTP request.
- Cookie: Looks for a specified Cookie in the HTTP request.
- Regular Expression: Looks for a regular expression anywhere in the
HTTP request. AppDirector supports Posix 1002.3 regular expressions;
the string can be up to 80 characters.
- Text: Looks for a text string anywhere in the HTTP request."
Comme le montre le lien de l' application de base , on pourrait par exemple créer une stratégie L7 évaluant les modèles d'URI pour le routage vers différentes batteries. Les modèles d'URI constitués «^ / login? = True» et «^ / login» peuvent être acheminés vers votre batterie de serveurs «connectée». Le modèle composé '^ / logout' (et tous les autres URI: s) pourrait également être routé vers une batterie de serveurs "par défaut".
Une batterie de serveurs est définie par le Guide de l'utilisateur p.121 ainsi: "Une batterie de serveurs AppDirector est un groupe de serveurs en réseau qui fournissent le même service [...] Un serveur qui fournit plusieurs services peut être utilisé dans plusieurs batteries de serveurs."
Un serveur est en outre différencié en séparant la définition d'un serveur principal en deux couches, la couche objet «Physical Server» qui représente l'adresse IP d'un serveur et la couche objet «Farm Server» qui représente les services exécutés sur un ou plusieurs serveurs physiques. .
Selon le «Guide de l'utilisateur AppDirector», la limitation de session sur une batterie de serveurs peut être effectuée pour chaque objet Farm Server défini pour une batterie de serveurs (ainsi que par d'autres moyens) en plus de chaque objet Physical Server. Ceci est décrit entre autres à la p.137:
"The Connection Limit is the maximum number of users that can be directed
to a server for a service provided by the farm. The number of users allowed
depends on the Sessions mode selected because it determines the number of
active entries in the Client Table for sessions destined to the specific server.
When the Entry Per Session or Server Per Session modes are selected, the number
of active entries destined to the same server is higher than in the Regular
mode (see Regular, page 153).
When the Regular mode is selected, all requests from a single client IP destined
to the same server are reflected by a single entry in the Client Table (see
Client Table Views, page 164).
The default value for the Connection Limit parameter is 0. When it is configured
to 0, it is disabled for this server and there is no user number limit."
La table client et son «mode régulier» sont définis à la p.153:
"The Layer 3 Client Table is always used when Entry Per Session is used.
AppDirector uses the Layer 3 Client Table to ensure Layer 3 persistency.
This table contains information about the server selected for each client
(Source IP address) in each farm, and it allows AppDirector to select a
server for a new session.
[...]
In the Regular mode, AppDirector maintains Layer 3 persistency. In this mode,
each entry is identified by the following parameters:
• Layer 4 Policy VIP Address
• Client IP Address
• Destination TCP/UDP Port Used from the Client to the Server"
Dans une capture d'écran d'une fenêtre de définition de serveur sur la page Application de base , la zone de limite de connexion au serveur apparaît juste à côté de la zone de limite de bande passante.
Donc, un peu en fonction de la configuration, mais pour les besoins de cette réponse, une «connexion» telle que définie via la table client et une «session» telle que définie par vous finissent essentiellement par être la même chose. Et une limite à cet effet peut être imposée par objet serveur dans une batterie de serveurs.
Comme AppDirector fait la différence entre les serveurs physiques et les serveurs de batterie de serveurs, il serait possible de définir deux serveurs de batterie de serveurs mappant à votre objet serveur physique Apache, l'un ayant une limite de connexion faible.
Cependant, Apache doit également répondre aux appels des deux objets serveur de batterie de serveurs, par exemple en étant appelé sur deux ports ou adresses IP distincts - un étant utilisé par chaque combo (batterie de serveurs / batterie de serveurs). La question devient alors: êtes-vous capable de définir deux points d'entrée de serveur d'applications? c'est-à-dire êtes-vous en mesure d'équiper votre application frontale Apache (/ vhost?) pour répondre sur deux ports ou adresses IP (une par batterie)? C'est à travers un peu de devinettes car je ne souhaite pas passer trop de temps avec le manuel, mais je suis sûr que vous pourriez résoudre ce problème assez élégamment en regardant l'interface graphique AppDirector et Apache.
La définition de la limite de connexion est un peu bizarre. Depuis les serveurs physiques, limite de connexion p.140:
"Connection Limit
Maximum number of Client Table entries that can run simultaneously on
the physical server. This depends on the farm’s Sessions mode (see
Sessions Modes, page 150). When the limit is reached, new requests are
no longer directed to this server. All open sessions are continued.
When the Connection Limit parameter is configured to 0 (default), this
mechanism is disabled for this physical server and there is no user
number limit.
Note: When configuring the physical server, ensure that the Connection
Limit in the farm servers with the same Server Name is lower than or
equal to the Connection Limit in the physical server. Total number of
active sessions that run simultaneously on the farm servers must not
be higher than the Connection Limit value defined on the physical server."
Vous devez donc définir une limite de connexion très élevée (avec une large marge au nombre maximum possible via votre base d'utilisateurs) pour le serveur de ferme "par défaut" sans restriction, et définir la limite de connexion pour le serveur de ferme "connecté" comme aussi bas que vous devez. La définition de serveur physique devrait avoir la somme des deux comme limite de connexion, comme condition préalable à l'activation de la limite de session souhaitée.
Vous avez également cette exigence dans votre question:
After the specified session limit has been reached, the next user should be
directed to a custom error page.
C'est ce qu'on appelle une «page sans service HTTP» dans le Guide de l'utilisateur, p.134:
When all servers belonging to a farm cannot be used for a specific
session, AppDirector can reply to a Web request (destined to port 80)
with a simple Web page, indicating that the service is currently not
available. Servers that cannot be used for a session include servers
in Not In Service or in No New Sessions mode. No HTTP Service Page is
configured for each farm. Each Web page is limited to 1K of HTML code.
Pour la partie suivi je n'ai pas fait de recherche approfondie mais voici ce que je pense:
track the current number of sessions for monitoring purposes
AppDirector semble avoir des MIB. Probablement une douleur pour trouver le bon OID comme il est habituellement, mais vous pouvez probablement le snmp à votre outil de choix.
whitelist the monitoring server (which is issuing queries to the webapp
periodically) and exempt it from the limit.
Celui-ci pourrait nécessiter une réflexion créative. En supposant que AppDirector n'inclut pas de modèle pour cela dès la sortie de la boîte, que diriez-vous:
- Les URI en dehors de la batterie de serveurs "connecté" ne seraient pas affectés par la limite de session. Surveillez donc, c'est le même serveur (s) backend de toute façon.
- Utilisez plutôt les contrôles de santé AppDirector, ils ne compteront probablement pas dans la limite de session que vous imposez. Trouvez un moyen de transmettre des alertes à votre serveur de surveillance :-)
- Configurez une troisième batterie de serveurs, à travers laquelle vous passez des tests de santé. Désordonné, mais cela fonctionnerait.