[Kea-users] HA use-cases for large enterprises?

[Serge Sterck]

We have à San in Master Master we expoet from this San à nfs share where we put de postgresSQL DB. Je we use 2 server with pacemaker with à Virtual ip to provide  ha and the dhcp is started on Master node

Envoyé à partir de Outlook pour Android<https://aka.ms/AAb9ysg>
________________________________
From: Kea-users <kea-users-bounces at lists.isc.org> on behalf of Geist, Dan (CCI-Atlanta) <Dan.Geist at cox.com>
Sent: Tuesday, August 22, 2023 5:28:46 PM
To: kea-users at lists.isc.org <kea-users at lists.isc.org>
Subject: [Kea-users] HA use-cases for large enterprises?

Vous ne recevez pas souvent de courriers de la part de dan.geist at cox.com. Découvrez pourquoi cela est important<https://aka.ms/LearnAboutSenderIdentification>

Greetings. We’re looking to scope what a solution might look like with KEA for our enterprise. It’s a rather large one with multiple millions of endpoints (not running KEA now).



We’re currently broken into multiple service POPs with multiple pairs of servers in an active/standby configuration (large POPs with lots of pairs and small POPs with only a few). We’re configured now for each server pair to handle about 250k client devices (of mixed types). The largest POPs handle somewhere in the high hundreds to low thousands of complete DORA/SARR transactions per second.



After looking through the various HA options presented in the admin manual, a question arises around scaling and HA setup options: What happens to the model when a common db lease backend (MySQL or PostgreSQL) is used? If most of the transactional latency in using the HA models is due to lease updates being propagated to backups, how does that change when a common backup is in place?



Further, utilizing one of the new features of 2.4 ( **Early allocation**: RFC2131 ) to help with possible lease collisions, would it be possible to create an n-node (horizontally scaled) cluster of servers without a native HA scheme but WITH a highly performant lease and configuration backend? We would likely run ECMP and Anycast on the cluster nodes for the listening IP(s) such that for a given client/server transaction, there would be only one service node communicating with that client. In this way, the drawbacks of HA blocking transactions are avoided by making the service nodes completely unaware of each other and relying on the DHCP service behavior and current lease data to avoid conflicts.



The eventual intent with this setup would be to also include bi-directional and non-blocking db replication to one or more “disaster sites” which would be kept (almost) in sync with the data in POPs but would only ever receive client traffic in the case of catastrophic site failure; absolute sync being not as important as the simple ability to serve the subnets in question.



Thoughts?



Thanks

Dan



________________________________

«Ceci est un courrier électronique à caractère professionnel. Le présent message comporte une information confidentielle à l'attention exclusive de la personne ou de l'entité à qui il est adressé ainsi que des autres destinataires autorisés à le recevoir. Si vous n'êtes pas le destinataire désigné ou autorisé, il vous est signifié que toute divulgation, copie, distribution ou utilisation de cette information est strictement interdite et peut être illégale. L'expéditeur ne peut être tenu pour responsable en cas de transmission incorrecte ou incomplète de l'information contenue dans le message ou en cas de retard dans sa réception. Nous déclinons toute responsabilité pour toute perte ou dommage causé par des virus. Pour tout renseignement complémentaire concernant le traitement de vos données à caractère personnel, veuillez consulter notre Charte sur la protection des données disponible à l'adresse suivante https://www.solidaris-brabant.be/fr/conditions_d_utilisation. Pour tout renseignement complémentaire concernant le traitement de vos données à caractère personnel dans le cadre d'un dossier chez Solidaris Brabant Assurance, veuillez consulter la Charte sur la protection des données disponible à l'adresse suivante https://www.solidaris-brabant.be/fr/informations-légales-et-vie-privée-concernant-solidaris-brabant-assurances<https://www.solidaris-brabant.be/informations-l%C3%A9gales-et-vie-priv%C3%A9e-concernant-solidaris-brabant-assurances>

________________________________

«Dit is een professionele e-mail. De informatie in dit bericht is vertrouwelijk en uitsluitend bestemd voor de persoon of entiteit aan wie het bericht is verzonden en anderen die gerechtigd zijn dit bericht te ontvangen. Indien u niet de geadresseerde of een gerechtigde bent, wordt u hierbij op gewezen dat het openbaar maken, kopiëren, verspreiden of gebruik maken ervan, verboden is en illegaal kan zijn. De verzender kan niet aansprakelijk worden geacht voor een onjuiste of onvolledige overbrenging van de inhoud van dit verzonden bericht, noch voor niet tijdige ontvangst ervan. We wijzen elke aansprakelijkheid af voor elk verlies of schade door software virussen veroorzaakt. Voor meer informatie met betrekking tot de verwerking van uw persoonsgegevens, kan u het handvest over persoonsgegevensbescherming raadplegen via de link https://www.solidaris-brabant.be/nl/gebruiksvoorwaarden. Voor meer informatie met betrekking tot de verwerking van uw persoonsgegevens in het kader van een dossier bij Solidaris Brabant Verzekeringen, kan u het handvest over persoonsgegevensbescherming raadplegen via de link https://www.solidaris-brabant.be/nl/juridische-informatie-en-privacy-van-solidaris-brabant-verzekeringen.

________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20230822/35940334/attachment-0001.htm>