Чи працює CDN, навіть коли мій сервер не працює?

Я власник веб-сайту, який планує використовувати хмару Amazon S3. Я читав усі матеріали про те, що може зробити CDN, але у мене все ще немає відповіді.

Чи працює CDN, навіть якщо мій основний сервер не працює. Це головна причина, що мені це цікаво. Тому що мій сервер, як правило, переживає часті відключення внаслідок відключення електроенергії тут, у Малі.

Це залежатиме від того, хто розміщує ваш CDN. Якщо ви розміщуєте свій веб-сайт на одному сервері, а CDN - з третьою стороною, цілком ймовірно, що ваш CDN залишиться активним, коли ваш веб-сайт не працює. Однак це може бути не так, оскільки деякі CDN розповсюджують лише вміст, який вони можуть перевірити, на вашому веб-сайті.

Побічна примітка, CDN не для розміщення всього веб-сайту. Отже, якщо ви думаєте, що можете використовувати його для заміни веб-хостингу або використовувати його як якийсь план відмови, ви гавкаєте неправильне дерево.

TL; DR - Вам доведеться запитати у свого постачальника CDN.

CDN розроблені для масштабованості та продуктивності, але не для високої доступності. У будь-який момент часу вони можуть вимагати доступу до оригінальних файлів.

Більшість людей використовують їх для зберігання статичних файлів, таких як зображення, файли css та javascript. Деякі можуть бути налаштовані на кешування HTML, але це лише в тому випадку, якщо у вас є повністю статичний веб-сайт. Якби це було так, ви могли розмістити всю річ на S3 і сервер взагалі не знадобився б.

Як правило, так, аж до TTL.

Під час використання CDN ви зазвичай налаштовуєте TTL (час жити) для свого вмісту. Це максимум того, скільки років може отримати кеш, перш ніж він вирішить, що він повинен абсолютно оновити кеш найновішим вмістом. Наприклад, припустимо, що ви налаштували всі URL-адреси * .jpg так, щоб вони мали 5 хвилин TTL.

Тоді, якщо ваш сервер вийде з роботи, у вас є додаткові 5 хвилин, щоб повернути його назад, перш ніж користувачі помітять. Ну принаймні для .jpgs. Ну, принаймні, для .jpgs, які траплялися заздалегідь кешовані.

Крім того, деякі CDN використовують такі функції, як Akamai NetStorage, де ви можете завантажувати вміст безпосередньо в CDN - CDN надається деякий вміст і наказано подавати його безпосередньо апріорі. Оскільки тут ніколи не відбувається кешування кеша стилем "на вимогу", для початку, це, звичайно, повинно працювати, коли ваш сервер не працює.

Як зазначають інші плакати, це не те, для чого створені CDN, і вони не дають жодних гарантій того, що така поведінка буде працювати. Це зазвичай буває, як правило, працює (і це дивовижно, коли ти спостерігаєш, як це відбувається!). І звичайно, для конкретних технічних деталей вам доведеться звернутися до свого постачальника.

Так: сервери CDN все ще працюватимуть навіть під час роботи вашого веб-сайту, що є хорошим варіантом для вирішення великих відмов. У вас є достатній контроль над тим, що відбувається, щоб ви могли налаштувати досвід, виходячи зі своїх ресурсів та пріоритетів. Варіанти загально підпадають під такі категорії:

1. Об'єкти, налаштовані на кешування (найчастіше за допомогою встановлення Cache-Controlзаголовка), повинні бути доступними до їх закінчення. Деякі CDN пропонують можливість крайових серверів CDN отримувати вміст з інших серверів CDN, що може допомогти під час відключень, а також загалом покращити продуктивність, коли ваші вихідні сервери мають порівняно високу затримку щодо серверів CDN.

2. Деякі CDN пропонують можливість подавати вміст, термін дії якого закінчився, коли ваш сервер запущеного сервера недоступний (наприклад, за допомогою програми «Швидко ви можете включити режим ласки або святий Варніш»). Очевидно, це не допоможе вмісту, який ніколи не кешований, але в багатьох випадках він може принаймні зберігати основну домашню сторінку, контактну інформацію та ін. В Інтернеті, поки ви працюєте над тим, щоб повернути свої сервери в Інтернет.

3. Більшість CDN пропонують можливість спробувати декілька серверів сервера, щоб у вас був окремий веб-сайт з відмовою, який забезпечує сенс для вашого сайту: перехід на інший сервер або сайт із зниженою функціональністю, статична HTML-сторінка тощо. Це може бути корисно для катастрофічних збої в хостінгу, оскільки у вас є можливість хостингу з зовсім іншою компанією або, у випадку чогось на кшталт Akamai NetStorage, безпосередньо з провайдером CDN, щоб вони підтримували повний стек.

За винятком третього варіанту, ви не маєте контролю над тим, що буде кешовано на серверах CDN, тому найважливішою частиною процесу є рішення про те, як ваш сайт може деградувати, якщо різні функції недоступні: наприклад, якщо у вас є розумний вміст HTML, навіть коли JavaScript виходить з ладу повністю, веб-сайт, керований інформацією, може працювати лише з базовим вмістом сторінки, навіть коли більш досконалі функції тихо не спрацьовують у фоновому режимі.

Більшість CDN кешують (динамічний) вміст протягом певного періоду часу (TTL) від початку, у цьому випадку ваш сервер. У консолі управління Cloudfront Amazon пояснюється кеш-керування відра S3.

1. Типова поведінка Amazon S3 - це кешування об'єкта протягом 24 годин.

2. Ви можете впливати на поведінку за замовчуванням, надаючи / записуючи заголовок кеша-керування на своєму початковому сервері або заголовку Expires.

   • Якщо ви використовуєте заголовок максимального віку Cache-Control, мінімальне значення дорівнює 0. У цей момент Amazon буде вміщувати ваш початковий сервер, щоб перевіряти, чи змінився об'єкт щоразу.

   • Коли ви використовуєте заголовок Expires для об'єкта, Amazon не зв’яжеться з вашим початковим сервером до цієї дати.

Сподіваюся, це пояснює поведінку Амазонки.

Я був інженером підтримки в CDN більше року, і я скажу, що всі відповіді тут чудові, але найкраща відповідь на ІМО @ Кріс-Адамса (якби я міг би проголосувати за це).

Одне, що ми робимо нашими клієнтами - це вказати www на CDN та 301 на TLD на www. Якщо термін TTL об’єктів закінчується, то край буде подавати вміст, що минув, якщо він доступний у кеші.

З урахуванням сказаного, якщо для вас важливо продовження часу (і свіжого вмісту), то я б подумав перенести своє походження (біль у прикладі, який я знаю) до господаря, який не відчуває частого відключення електроенергії.