Re: [TECH] [FRnOG] Re: Un CDN Down ?
On 10/06/2021 15:41, Damien Wetzel wrote: Ton systeme ne fonctionne que si tu mets en cache que les sous domaines de ta page (pas le www) et neccessite un developement agile du site (ils sont souvent figés et il est difficile d'en changer l'archi) Disons que si tu as la problèmatique du multi cdn tu dois être assez gros pour avoir une équipe de dev capable de réaliser ceci. Après globalement ce que tu mets en cache c'est quand meme souvent tes assets et ou des choses très statiques qui ne sont pas accédé directement. Enfin tu peux tenter de CDNiser tout ton site mais c'est assez casse gueule, qu'on se rappelle la blague sur l'invalidation de cache. D'autres part, j'ai l'impression que la plupart des resolveurs operateurs acceptent et obeissent à des ttl relativement courts contrairement à une époque ancienne. La solution DNS meme si elle n'est pas parfaite me parait la seule utilisable à l'heure actuelle. Je suis d'accord qu'avoir un ou plusieurs niveaux d'indirections niveau DNS avec des ttl(s) courts (et globalement ca marche meme si moche théoriquement) est une solution simple. La question après c'est à qui tu confie ta gestion de ton DNS. Les services types route53 sont vraiment pratique mais ont souffert leur lots d'indisponibilités. Tu peux aussi avoir un mécanisme qui controle différente API de différents fournisseur DNS en effet. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [TECH] [FRnOG] Re: Un CDN Down ?
Ton systeme ne fonctionne que si tu mets en cache que les sous domaines de ta
page
(pas le www) et neccessite un developement agile du site (ils sont souvent
figés et il est difficile d'en changer l'archi)
on peut partir du principe qu'un DNS robuste aura moins de chances
de tomber en panne qu'un CDN robuste , don on limite la proba de panne
sans l'eliminer totalement.
D'autres part, j'ai l'impression que la plupart des resolveurs operateurs
acceptent
et obeissent à des ttl relativement courts contrairement à une époque ancienne.
La solution DNS meme si elle n'est pas parfaite me parait la seule utilisable à
l'heure
actuelle.
Cordialement,
Damien
Raphael Mazelier writes:
>
> On 09/06/2021 14:51, Renaud Chaput wrote:
> > a m'ammène à la question du multi-CDN, est ce que sa complexité
> > se justifie pour palier à des problemes comme celui rencontré hier
> > qui sont quand meme relativement trés rares ?
>
> Cela dépend de ton buisness comme toujours.
>
> Le multi CDN n'est pas nécessairement complexe et tu n'as pas besoin
> d'un intermédiaire pour le faire.
>
> Cela dépend evidement de ce que tu caches mais cela ne me parait pas
> déconnant d'avoir une brique interne qui construit les URLs de ce que tu
> as à cacher/servir via ton CDN.
>
> On le faisait dans un previous job et cela avait beaucoup d'avantage,
> redondance de CDN, controle des couts aussi. Et tout cela sans
> intervention/magie DNS.
>
> Tu peux meme cacher le resultat avec un ttl assez court pour lisser les
> gros burst et protéger tes origines. Cela ne te protégera pas
> complétement mais cela limitera beaucoup la casse.
>
> Sinon en beaucoup plus simple tu utilise un DNS type route53 et tu fais
> du weighted DNS sur les x domains de tes x CDNs. Alors évidement dans ce
> cas tu déportes le spof chez ton fournisseur de DNS.
>
>
> > Est ce que avoir une config de secours sur un autre CDN + un DNS
> > configurable
> > rapidement avec des TTL courrs ~1min a un sens ?
> Voir ci dessus, perso je pense que cela peut valoir le coup, mais tout
> dépend de ton buisness.
> >
> > Le gros problème du multi-CDN c’est la configuration du-dit CDN. Si tu ne
> > t’en sers que pour du cache simple de fichiers statiques, pourquoi pas,
> > mais si tu fais des choses plus complexes (réécriture de requêtes,
> > sécurité, optimisation d’images, routage dynamique, intelligence at the
> > edge) ça devient beaucoup plus compliqué.
>
> J'ai un avis assez tranché sur le fait qu'on ne devrait pas mettre
> d'intelligence spécifique à un fournissseur CDN (ou autre d'ailleurs)
> pour des raisons de risque de couplage.
>
> Sinon quand tu veux bouger pour x raisons (souvent financière) tu es un
> petit peu dans le mal.
>
> >
> > Et vu que la grosse force de Fastly c’est de pouvoir faire un peu ce que tu
> > veux en terme de config, ça me parait vraiment complexe de le redonder. Et
> > ensuite, quelle est la probabilité que ta brique qui gère la redondance
> > cause à son tour une panne, est-ce plus ou moins élevé que la proba que
> > Fastly (ou autre) tombe ? Est-ce que tu n’introduis pas un SPOF via ton
> > outil de multi-CDN ?
> >
> > Bref, sujet complexe et pas évident quand on commence à considérer tous les
> > aspects.
>
> Assurément mais passionnant.
>
> --
>
> Raphael
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
--
~
Damien WETZEL (ATANAR TECHNOLOGIES)("`-/")_.-'"``-._
http://www.atanar.com . . `; -._)-;-,_`)
(v_,)' _ )`-.\ ``-'
Phone:+33 9 67 35 09 05_.- _..-_/ / ((.'
- So much to do, so little time - ((,.-' ((,/
~
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [TECH] [FRnOG] Re: Un CDN Down ?
On 09/06/2021 14:51, Renaud Chaput wrote: a m'ammène à la question du multi-CDN, est ce que sa complexité se justifie pour palier à des problemes comme celui rencontré hier qui sont quand meme relativement trés rares ? Cela dépend de ton buisness comme toujours. Le multi CDN n'est pas nécessairement complexe et tu n'as pas besoin d'un intermédiaire pour le faire. Cela dépend evidement de ce que tu caches mais cela ne me parait pas déconnant d'avoir une brique interne qui construit les URLs de ce que tu as à cacher/servir via ton CDN. On le faisait dans un previous job et cela avait beaucoup d'avantage, redondance de CDN, controle des couts aussi. Et tout cela sans intervention/magie DNS. Tu peux meme cacher le resultat avec un ttl assez court pour lisser les gros burst et protéger tes origines. Cela ne te protégera pas complétement mais cela limitera beaucoup la casse. Sinon en beaucoup plus simple tu utilise un DNS type route53 et tu fais du weighted DNS sur les x domains de tes x CDNs. Alors évidement dans ce cas tu déportes le spof chez ton fournisseur de DNS. Est ce que avoir une config de secours sur un autre CDN + un DNS configurable rapidement avec des TTL courrs ~1min a un sens ? Voir ci dessus, perso je pense que cela peut valoir le coup, mais tout dépend de ton buisness. Le gros problème du multi-CDN c’est la configuration du-dit CDN. Si tu ne t’en sers que pour du cache simple de fichiers statiques, pourquoi pas, mais si tu fais des choses plus complexes (réécriture de requêtes, sécurité, optimisation d’images, routage dynamique, intelligence at the edge) ça devient beaucoup plus compliqué. J'ai un avis assez tranché sur le fait qu'on ne devrait pas mettre d'intelligence spécifique à un fournissseur CDN (ou autre d'ailleurs) pour des raisons de risque de couplage. Sinon quand tu veux bouger pour x raisons (souvent financière) tu es un petit peu dans le mal. Et vu que la grosse force de Fastly c’est de pouvoir faire un peu ce que tu veux en terme de config, ça me parait vraiment complexe de le redonder. Et ensuite, quelle est la probabilité que ta brique qui gère la redondance cause à son tour une panne, est-ce plus ou moins élevé que la proba que Fastly (ou autre) tombe ? Est-ce que tu n’introduis pas un SPOF via ton outil de multi-CDN ? Bref, sujet complexe et pas évident quand on commence à considérer tous les aspects. Assurément mais passionnant. -- Raphael --- Liste de diffusion du FRnOG http://www.frnog.org/
[TECH] [FRnOG] Re: Un CDN Down ?
On 9 Jun 2021 at 11:59 +0200, Damien Wetzel , wrote: a m'ammène à la question du multi-CDN, est ce que sa complexité se justifie pour palier à des problemes comme celui rencontré hier qui sont quand meme relativement trés rares ? Est ce que avoir une config de secours sur un autre CDN + un DNS configurable rapidement avec des TTL courrs ~1min a un sens ? Le gros problème du multi-CDN c’est la configuration du-dit CDN. Si tu ne t’en sers que pour du cache simple de fichiers statiques, pourquoi pas, mais si tu fais des choses plus complexes (réécriture de requêtes, sécurité, optimisation d’images, routage dynamique, intelligence at the edge) ça devient beaucoup plus compliqué. Et vu que la grosse force de Fastly c’est de pouvoir faire un peu ce que tu veux en terme de config, ça me parait vraiment complexe de le redonder. Et ensuite, quelle est la probabilité que ta brique qui gère la redondance cause à son tour une panne, est-ce plus ou moins élevé que la proba que Fastly (ou autre) tombe ? Est-ce que tu n’introduis pas un SPOF via ton outil de multi-CDN ? Bref, sujet complexe et pas évident quand on commence à considérer tous les aspects. -- Renaud --- Liste de diffusion du FRnOG http://www.frnog.org/
