C'est un principe c'est sûr mais ça dépend de ton archi et de tes contraintes comme on le dit depuis le début. Je ne sais pas ce que protège ton serveur mais j'ai vu du très critique tourner sur vsphere4 sans problème (y compris de la sécu). Dans ton cas ça ferai passer le nombre de serveur de 4 à 2 et vu la sécurité du OpenBSD (crypto native quasiment partout) je ne sais pas dire ce qu'on peut tirer d'un hack de la couche virtuelle dans ce cas (qui reste une attaque assez complexe) hormis un DoS qui de toutes les façons est très difficile a éviter dans tous les cas. Bonne baignade
Le 7 avril 2012 00:36, Hugues <hugues...@gmail.com> a écrit : > 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> 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/ > >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
