Un CDN fonctionne-t-il toujours même lorsque mon serveur est en panne?

Je suis un propriétaire de site Web prévoyant d'utiliser le cloudfront S3 d'Amazon. J'ai lu tous les trucs sur ce qu'un CDN peut faire mais j'ai encore une question sans réponse.

Est-ce qu'un CDN fonctionne toujours même lorsque mon serveur principal est en panne. C'est la raison principale qui m'intéresse. Parce que mon serveur subit généralement des pannes fréquentes en raison d'une panne de courant ici au Mali.

Cela dépend de la personne qui héberge votre CDN. Si vous hébergez votre site Web sur un serveur et le CDN avec un tiers, il est probable que votre CDN restera actif lorsque votre site Web le fermera. Cela peut ne pas être le cas cependant, car certains CDN ne distribuent que du contenu dont ils peuvent vérifier la présence sur votre site Web.

Remarque: les CDN ne sont pas destinés à l'hébergement de l'ensemble de votre site Web. Donc, si vous pensez que vous pouvez en utiliser un pour remplacer votre hébergement Web ou l'utiliser comme une sorte de plan de basculement, vous aboyez la mauvaise arborescence.

TL; DR - Vous devrez demander à votre fournisseur CDN.

Les CDN sont conçus pour l'évolutivité et les performances, mais pas pour la haute disponibilité. À tout moment, ils peuvent avoir besoin d'accéder aux fichiers d'origine.

La plupart des gens les utilisent pour stocker des fichiers statiques tels que des images, des fichiers css et javascript. Certains peuvent être configurés pour mettre en cache HTML, mais ce n'est que si vous avez un site Web complètement statique. Si tel était le cas, vous pourriez héberger le tout sur S3 et n'auriez pas du tout besoin d'un serveur.

Généralement, oui, jusqu'au TTL.

Lorsque vous utilisez des CDN, vous configurez généralement des TTL (durée de vie) pour votre contenu. Il s'agit d'un maximum sur l'âge du cache avant de décider qu'il doit absolument actualiser le cache avec le contenu le plus récent. Par exemple, supposons que vous configuriez toutes les URL * .jpg pour avoir un TTL de 5 minutes.

Ensuite, si votre serveur tombe en panne, vous disposez de 5 minutes supplémentaires pour le réactiver avant que les utilisateurs ne le remarquent. Eh bien, au moins pour .jpgs. Eh bien, au moins pour les .jpgs qui se sont avérés avoir été mis en cache au préalable.

De plus, certains CDN utilisent des fonctionnalités comme Akamai NetStorage où vous pouvez télécharger du contenu directement sur le CDN - le CDN reçoit du contenu et est invité à le servir directement a priori. Puisqu'il n'y a jamais de mise en cache de style "pull" à la demande pour commencer, cela devrait bien sûr fonctionner lorsque votre serveur est en panne.

Comme l'ont noté les autres affiches, ce n'est pas pour cela que les CDN sont conçus et ils ne fournissent AUCUNE garantie que ce comportement fonctionnera. Il se trouve que cela fonctionne généralement (et c'est génial quand vous le regardez se produire!). Et bien sûr, pour des détails techniques spécifiques, vous devrez contacter votre fournisseur.

Oui: les serveurs CDN continueront de fonctionner même lorsque votre site est en panne, ce qui est une bonne option à avoir pour gérer les pannes majeures. Vous avez un bon contrôle sur ce qui se passe afin que vous puissiez adapter l'expérience en fonction de vos ressources et de vos priorités. Les options entrent généralement dans ces catégories:

1. Les objets qui ont été configurés pour la mise en cache (le plus souvent en définissant l'en- Cache-Controltête) doivent être disponibles jusqu'à leur expiration. Certains CDN offrent aux serveurs de périphérie CDN la possibilité de récupérer du contenu à partir d'autres serveurs CDN, ce qui peut aider pendant les pannes et améliorer généralement les performances lorsque vos serveurs d'origine ont une latence relativement élevée par rapport aux serveurs CDN.

2. Certains CDN offrent la possibilité de diffuser du contenu qui a expiré lorsque votre serveur principal n'est pas disponible (par exemple, avec Fastly, vous pouvez activer les modes grâce ou saint de Varnish). Évidemment, cela n'aidera pas le contenu qui n'a jamais été mis en cache, mais dans de nombreux cas, cela pourrait au moins garder votre page d'accueil principale, vos coordonnées, etc. en ligne pendant que vous travaillez pour remettre vos serveurs en ligne.

3. La plupart des CDN offrent la possibilité d'essayer plusieurs serveurs d'arrière-plan afin que vous puissiez avoir un site de basculement distinct offrant l'expérience qui a du sens pour votre site: basculement vers un autre serveur ou site à fonctionnalités réduites, une page HTML statique, etc. Cela peut être utile pour les catastrophes. échecs d'hébergement puisque vous avez la possibilité d'héberger avec une entreprise complètement différente ou, dans le cas de quelque chose comme Akamai NetStorage, directement avec le fournisseur CDN afin qu'ils prennent en charge la pile complète.

À l'exception de la troisième option, vous n'avez aucun contrôle sur ce qui sera mis en cache sur les serveurs CDN, donc la partie la plus importante du processus consiste à décider comment votre site peut se dégrader si diverses fonctionnalités ne sont pas disponibles: par exemple, si vous avez un contenu HTML raisonnable même lorsque JavaScript échoue complètement, un site principalement axé sur les informations peut fonctionner avec uniquement du contenu de page de base même lorsque des fonctionnalités plus avancées échouent discrètement en arrière-plan.

La plupart des CDN mettent en cache le contenu (dynamique) pendant une période de temps (TTL) à partir de l'origine, dans ce cas, votre serveur. Dans Cloudfront Management Console d'Amazon, le contrôle du cache d'un compartiment S3 est expliqué.

1. Le comportement par défaut d'Amazon S3 consiste à mettre en cache un objet 24 heures.

2. Vous pouvez influencer le comportement par défaut, en fournissant / écrivant un en-tête Cache-Control sur votre serveur d'origine ou un en-tête Expires.

   • Lorsque vous utilisez l'en-tête max-age Cache-Control, la valeur minimale est 0. À ce stade, Amazon contiendra votre serveur d'origine, pour vérifier si l'objet a changé, à chaque fois.

   • Lorsque vous utilisez l'en-tête Expires pour un objet, Amazon ne contactera pas votre serveur d'origine avant cette date.

J'espère que cela clarifie le comportement d'Amazon.

J'ai été ingénieur de support dans un CDN pendant plus d'un an et je dirai que toutes les réponses ici sont excellentes, mais IMO @ Chris-Adams a la meilleure réponse (si je pouvais voter pour, je le ferais).

Une chose que nos clients font est de pointer www vers le CDN et 301 le TLD vers www. Si un objet TTL expire, le bord servira le contenu expiré s'il est disponible dans le cache.

Cela dit, si le temps de disponibilité (et le nouveau contenu) est important pour vous, j'envisagerais de déplacer votre origine (douleur dans le cul que je connais) vers un hôte qui ne connaît pas de pannes de courant fréquentes.