Le plus petit serveur que je peux acheter aujourd'hui c'est un type dell 210
avec ça et un Openbsd dessus et un minimum de tuning je route 3 à 400 mb/sec
Aujourd'hui si je consomme 100 Mb/sec c'est le bout du monde
si je suis ta pensée et que je reste dans l'idée du LB et donc Fail over
j'ai besoin
2FW ===> 2 SSL ==> mes serveurs applicatifs
ça va me faire 4 serveurs qui dorment au lieu de 2...
En théorie je suis d'accord avec toi mais ça fait raller quand même.
d'autre part faire des VM de BSD pour des serveurs critiques, je ne suis
pas très chaud.
Merci pour ces infos et bonne nuit
il est 18:30 chez moi et je vais me baigner ( je suis au antilles )
bye
Hugues
Le 07/04/2012 00:17, J. Mardas a écrit :
Le 6 avril 2012 23:07, Hugues <hugues...@gmail.com
<mailto:hugues...@gmail.com>> a écrit :
Es ce que c'est une bonne idée d'ajouter la prise en charge du ssl
sur les firewall ?
A mon sens mélanger FW et RP sur une même machine physique est non
seulement un risque de sécurité mais surtout une erreur d'architecture
(au sens urbanisation) et d'exploitabilité. J'ai vu de nombreux FW
commerciaux (au hasard checkpoint et son module web filtering)
utilisant ses fonctions en prod devenir rapidement de véritables
usines à gaz inexploitables avec le temps et la multiplication des
fonctions. Ceci est même risqué, car très souvent dans ce type
d'appliance commercial, il n'y a pas d'HTTP en asic et c'est le CPU
qui traite les règles applicatives en soft. Conséquence, les perfs
s'écroulent avec la multiplication de règles applicatives.
De tels équipements, ainsi utilisés, finissent par être des spof qui
se trouvent sur beaucoup de chemins critiques et deviennent avec le
temps un gouffre financier. Segmenter son architecture par protocole
et niveau en gardant une architecture simple et homogène me semble
dans beaucoup de cas comme étant une bonne pratique pour construire
des architectures durables, évolutives, maîtrisées et sécurisées.
Un FW est un équipement majoritairement réseau (1-4). Un LB qui
supporte du SSL, que je considère comme un RP car il implémente
nécessairement des fonctions applicatives (persistance de session,
cookie, ...) est un équipement de niveau applicatif et réseau (3-7).
FW et RP sur le même serveur risque de faire double emploi sur la
partie réseau, ce qui peut être le cas lors d'un incident, d'un bug ou
dans l'urgence. Surtout au vu de la complexité des applications et des
SI et de la difficulté du debug des applications distribuées.
Cela ne veut pas dire que c'est à proscrire car encore une fois ça
dépend des cas. On peut par exemple se demander si votre serveur n'est
pas sur-dimensionné ou s'il n'est pas plus intéressant de le
virtualiser au vu des ressources restantes et de l'overhead que cela
implique.
Le 06/04/2012 22:44, Michel Blanc a écrit :
On 06/04/2012 15:25, Hugues wrote:
Bonjour
j'ai jamais testé HA Proxy mais j'en ai toujours entendu
que du bien.
je suis en train de travailler avec Dancer
http://perldancer.org/
dans la doc il propose de déployer les appli dancer avec
Perlbal comme
load balancer
détails sur :
https://metacpan.org/module/Dancer::Deployment#Using-perlbal
est ce que quelqu'un a déjà testé ça en prod ?
Bonsoir Hugues,
Non, et bien que (ex-) fan de perl (et sans connaitre tes
besoins), je
te conseille vraiment HAProxy. C'est la rolls pour du LB http,
tu peux
faire quasiment tout ce que tu veux : router vers les backends en
fonction d'en-têtes HTTP (parfait pour les virtualhosts), en
fonction du
chemin (sympa pour renvoyer les assets statiques depuis un serveur
specifique), authentification, LB avec des poids, montée en charge
progressive des noeuds qui reviennent up, serveurs de backup,
arrêt des
noeuds depuis l'interface web, etc..., j'en découvre encore
tous les jours.
C'est vraiment un petit bijou. Par ailleurs, même si nous avons un
trafic modeste (50k-100k hits par jour), je ne l'ai jamais vu
défaillir
(malgré la version tagguée -dev, (oui c'est mal, non pas la
claque)).
Si tu as besoin de faire du SSL pour ton appli, un petit nginx par
dessus est bien pratique. HAProxy ne gère pas encore
"vraiment" (mais
c'est en vue pour la 1.5), et peut juste forwarder du TCP dur
le port
443. Dans tous ls cas, ça me parait mieux de terminer le SSL
sur le LB
pour les soulager les backends et pour présenter un certificat
valide.
A+
M
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
