Hi. We have large dhcpv6 clients (hundreds of thousands) on deployed hot-standby option with active and standby in separated sites with postgresql standalone in both sites. The kea-dhcp6 replication feature was a bad idea; finally we have stoped kea-dhcp6 replication and deployed manual backend replication with scripts.
________________________________ De: Kea-users <kea-users-boun...@lists.isc.org> en nombre de Serge Sterck <serge.ste...@solidaris.be> Enviado: martes, 22 de agosto de 2023 11:45:20 Para: Geist, Dan (CCI-Atlanta); kea-users@lists.isc.org Asunto: Re: [Kea-users] HA use-cases for large enterprises? 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-boun...@lists.isc.org> on behalf of Geist, Dan (CCI-Atlanta) <dan.ge...@cox.com> Sent: Tuesday, August 22, 2023 5:28:46 PM To: kea-users@lists.isc.org <kea-users@lists.isc.org> Subject: [Kea-users] HA use-cases for large enterprises? Vous ne recevez pas souvent de courriers de la part de dan.ge...@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. ________________________________ ________________________________ AVISO LEGAL: Esta información es privada y confidencial y está dirigida únicamente a su destinatario. Si usted no es el destinatario original de este mensaje y por este medio pudo acceder a dicha información por favor elimine el mensaje. La distribución o copia de este mensaje está estrictamente prohibida. Esta comunicación es sólo para propósitos de información y no debe ser considerada como propuesta, aceptación ni como una declaración de voluntad oficial de NUCLEO S.A. La transmisión de e-mails no garantiza que el correo electrónico sea seguro o libre de error. Por consiguiente, no manifestamos que esta información sea completa o precisa. Toda información está sujeta a alterarse sin previo aviso. This information is private and confidential and intended for the recipient only. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and shall not be regarded neither as a proposal, acceptance nor as a statement of will or official statement from NUCLEO S.A. . Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
