Différences
Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
| checkpoint:vpn-1:vpn-1 [06.06.2007 13:09] – Ajout de l'astuce de Balto pour désactiver la politique any-any-any-drop youp3 | checkpoint:vpn-1:vpn-1 [07.01.2010 12:32] (Version actuelle) – modification externe 127.0.0.1 |
|---|
| ==== Solutions possibles ==== | ==== Solutions possibles ==== |
| Nous partons ici sur l'hypothèse que VPN-1 n'a pas accès au DNS et que le nom du serveur HTTP n°1 est stocké dans son fichier hosts. | Nous partons ici sur l'hypothèse que VPN-1 n'a pas accès au DNS et que le nom du serveur HTTP n°1 est stocké dans son fichier hosts. |
| - On dispose d'un seul module : Pas de miracle ! Quand on s'aperçoit du disfonctionnement du serveur, il faut modifier le fichier hosts pour indiquer l'adresse du second serveur. Un redémarrage du démon VPN-1 (cpstop;cpstart) est nécessaire pour la prise en compte de ce changement. | - On dispose d'un seul module : Pas de miracle ! Quand on s'aperçoit du dysfonctionnement du serveur, il faut modifier le fichier hosts pour indiquer l'adresse du second serveur. Un redémarrage du démon VPN-1 (cpstop;cpstart) est nécessaire pour la prise en compte de ce changement. |
| - On dispose d'un cluster avec deux modules A et B : Pour éviter d'avoir à redémarrer le démon VPN-1, on renseigne dans le fichier hosts de A l'adresse IP du serveur n°1 et du serveur n°2 sur B (__Attention, le nom lui est celui du serveur n°1 sur les deux modules__). Ainsi si le serveur n°1 ne répond plus, il suffit de provoquer une bascule sur le second module pour interroger le second serveur. Ce qui est tout de même un moindre mal puisqu'une bascule est normalement transparente pour les flux en cours. | - On dispose d'un cluster avec deux modules A et B : Pour éviter d'avoir à redémarrer le démon VPN-1, on renseigne dans le fichier hosts de A l'adresse IP du serveur n°1 et du serveur n°2 sur B (__Attention, le nom lui est celui du serveur n°1 sur les deux modules__). Ainsi si le serveur n°1 ne répond plus, il suffit de provoquer une bascule sur le second module pour interroger le second serveur. Ce qui est tout de même un moindre mal puisqu'une bascule est normalement transparente pour les flux en cours. |
| | |
| | ===== CPU du module chargé à 100% ===== |
| | Si la consommation CPU de votre module passe d'un seul coup à 100%, il est possible que ce comportement survienne avec le dépassement du seuil de sessions simultanées autorisées. Ce seuil est par défaut positionné à 25000, même si le matériel supporte plus. Une première chose à faire est donc de vérifier ce seuil, le comparer avec le nombre de sessions actuel sur le module et de l'augmenter si cela s'avère nécessaire. |
| \\ | \\ |
| \\ | \\ |
| ---- | ---- |
| [[checkpoint:checkpoint|Retour à l'index CheckPoint]] | [[checkpoint:checkpoint|Retour à l'index CheckPoint]] |
