Hi, Actually rgw can handle SSL traffic, and updates of certs is just a restarting of service. For client it will be reset of connection, client will make a new one We use keeaplived DR method for RGW's for a years The only bottleneck in this setup is input traffic limited by LB. This also can be scaled via another LB, e.g. you need more public IP or change LB ports from 10G to 25/40G k Sent from my iPhone > On 16 Sep 2022, at 14:56, Boris Behrens <bb@xxxxxxxxx> wrote: > > Hi, > does someone got experience with having the RGW daemons directly handling > the public traffic, without any LB or so in front? > > We are thinking to ditch the HAproxy. It handles SSL termination, load > balancing (only RR) and stuff like this, but because of the nature of the > setup we only get 6-8 GBit traffic through it. > > Then we thought to put the HAProxy directly on RGW hosts (which are also > mon, mgr and OSD hosts) and hope to get more bandwidth through it (remove > one network hop, more power than some virtualized VM). > > And now we are discussing just to remove the haproxy, and have the RGW > processes handle it directly. > I am a bit scared this might be a bad idea (can it handle SSL updates well, > without killing active connections? Does nonlocal bind work and we move IP > adresses between the three hosts via keepalived? How good is it handling > bad HTTP request, sent by an attacker?) > > Does someone got experience with it and can share some insights? > > Cheers > Boris > > -- > Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im > groüen Saal. > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx > To unsubscribe send an email to ceph-users-leave@xxxxxxx _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |