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/
