Uma CDN ainda funciona mesmo quando meu servidor está inoperante?

Sou o proprietário de um site e planeja usar o S3 na nuvem da Amazon. Eu tenho lido todas as coisas sobre o que uma CDN pode fazer, mas ainda tenho uma pergunta sem resposta.

Uma CDN ainda funciona mesmo quando meu servidor principal está inoperante. Essa é a principal razão pela qual estou interessado. Porque, geralmente, meu servidor sofre interrupções frequentes devido a falta de energia aqui no Mali.

Depende de quem está hospedando sua CDN. Se você hospedar seu site em um servidor e a CDN com terceiros, é provável que a CDN permaneça ativa quando o site for desativado. No entanto, esse pode não ser o caso, pois algumas CDNs distribuem apenas o conteúdo que podem verificar no seu site.

Uma observação: as CDNs não são para hospedar todo o site. Portanto, se você pensa que pode usar um para substituir sua hospedagem na Web ou como algum tipo de plano de failover, está latindo para a árvore errada.

TL; DR - Você precisará solicitar ao seu provedor de CDN.

As CDNs são projetadas para escalabilidade e desempenho, mas não para alta disponibilidade. A qualquer momento, eles podem exigir acesso aos arquivos originais.

A maioria das pessoas os usa para armazenar arquivos estáticos, como imagens, arquivos css e javascript. Alguns podem ser configurados para armazenar em cache HTML, mas isso é apenas se você tiver um site completamente estático. Se fosse esse o caso, você poderia hospedar tudo no S3 e não precisaria de um servidor.

Geralmente, sim, até o TTL.

Ao usar CDNs, você geralmente configura TTLs (tempo de vida) para o seu conteúdo. É o máximo de quantos anos o cache pode obter antes de decidir que é absolutamente necessário atualizá-lo com o conteúdo mais recente. Por exemplo, suponha que você configure todos os URLs * .jpg para terem um TTL de 5 minutos.

Então, se o servidor ficar inativo, você terá 5 minutos extras para recuperá-lo antes que os usuários notem. Bem, pelo menos para .jpgs. Bem, pelo menos para .jpgs que foram armazenados em cache antes.

Além disso, algumas CDNs usam recursos como o Akamai NetStorage, onde você pode fazer upload de conteúdo diretamente para a CDN - a CDN recebe algum conteúdo e é instruído a servi-lo diretamente a priori. Como nunca há um cache de estilo "sob demanda" "puxado" acontecendo aqui para começar, isso certamente funcionará quando o servidor estiver inoperante.

Como os outros pôsteres observaram, porém, não é para isso que as CDNs foram projetadas e elas NÃO fornecem garantias de que esse comportamento funcionará. Acontece que geralmente funciona (e é incrível quando você assiste!). E, é claro, para obter detalhes técnicos específicos, você precisaria entrar em contato com seu provedor.

Sim: os servidores CDN ainda estarão em execução, mesmo enquanto o site estiver inativo, o que é uma boa opção para lidar com grandes interrupções. Você tem uma quantidade razoável de controle sobre o que acontece, para poder personalizar a experiência com base em seus recursos e prioridades. As opções genericamente se enquadram nessas categorias:

1. Os objetos que foram configurados para armazenamento em cache (geralmente configurando o Cache-Controlcabeçalho) devem estar disponíveis até que expirem. Algumas CDNs oferecem aos servidores de borda da CDN a capacidade de recuperar o conteúdo de outros servidores da CDN, o que pode ajudar durante as interrupções e também melhorar o desempenho quando os servidores de origem têm latência comparativamente alta em relação aos servidores da CDN.

2. Algumas CDNs oferecem a capacidade de veicular conteúdo que expirou quando o servidor back-end não está disponível (por exemplo, com o Fastly, você pode ativar os modos graça ou santo do Varnish). Obviamente, isso não vai ajudar com o conteúdo que nunca foi armazenado em cache, mas em muitos casos, pode pelo menos manter sua página principal, informações de contato etc. online enquanto você trabalha para colocar seus servidores online novamente.

3. A maioria das CDNs oferece a capacidade de experimentar vários servidores de back-end para que um site de failover separado forneça a experiência que faz sentido para o seu site: failover para outro servidor ou site de funcionalidade reduzida, uma página HTML estática etc. Isso pode ser útil para situações catastróficas. falhas de hospedagem, pois você tem a opção de hospedar em uma empresa completamente diferente ou, no caso de algo como o Akamai NetStorage, diretamente com o provedor CDN, para que eles suportem a pilha completa.

Com exceção da terceira opção, você não tem controle sobre o que será armazenado em cache nos servidores da CDN; portanto, a parte mais importante do processo é decidir como o site pode ser degradado se vários recursos não estiverem disponíveis: por exemplo, se você tiver conteúdo HTML razoável, mesmo quando o JavaScript falha completamente, um site principalmente orientado por informações pode ser capaz de executar apenas o conteúdo básico da página, mesmo quando recursos mais avançados falham silenciosamente em segundo plano.

A maioria das CDNs armazena em cache o conteúdo (dinâmico) por um período de tempo (TTL) a partir da origem, nesse caso, o seu servidor. No Cloudfront Management Console da Amazon, o controle de cache de um bucket S3 é explicado.

1. O comportamento padrão do S3 da Amazon é armazenar em cache um objeto 24 horas.

2. Você pode influenciar o comportamento padrão, fornecendo / gravando um cabeçalho de controle de cache no servidor de origem ou um cabeçalho de expiração.

   • Quando você usa o cabeçalho de idade máxima do Cache-Control, o valor mínimo é 0. Nesse momento, a Amazon contará com o servidor de origem para verificar se o objeto mudou sempre.

   • Quando você usa o cabeçalho Expira para um objeto, a Amazon não entrará em contato com o servidor de origem até essa data.

Espero que isso esclareça o comportamento da Amazon.

Eu fui engenheiro de suporte na CDN por mais de um ano e direi que todas as respostas aqui são ótimas, mas a IMO @ Chris-Adams tem a melhor resposta (se eu pudesse votar novamente, eu faria).

Uma coisa que nossos clientes fazem é apontar www para a CDN e 301 o TLD para www. Se um TTL de um objeto expirar, a borda exibirá o conteúdo expirado, se estiver disponível no cache.

Com isso dito, se o tempo de atividade (e o novo conteúdo) for importante para você, eu consideraria mudar sua origem (dor no traseiro que eu conheço) para um host que não sofra quedas de energia frequentes.