Статически зеркально отражая тяжелый переданный сайт, CloudFlare как DNS

В первую очередь на ум приходит пара разных вещей:

Во-первых, у вас уже есть статическое зеркало вашего сайта, которое предназначено только для этого варианта использования: Cloudflare. Я предполагаю, что вы не только предоставляете свой DNS, но и настроили их как CDN, чтобы снизить нагрузку на трафик, идущий к вам. Cloudflare имеет функцию под названием Always Online, которая предназначена для выполнения именно тех задач, которые вы ищете: предоставления статической копии веб-сайта, даже если «источник» - в данном случае ваш балансировщик нагрузки и / или серверы, стоящие за ним - идут вниз. Прежде чем беспокоиться о более сложном решении, убедитесь, что у вас все настроено правильно. Всегда хорошо решить 80% + проблемы с 2% работы! Фактически, вы можете просто положиться на Cloudflare, чтобы полностью решить проблему за вас. Сначала ознакомьтесь с Cloudflare Always On, так как это будет намного проще для вас реализовать, чем что-либо другое, поскольку Cloudflare уже настроен в вашей инфраструктуре. Если после того, как вы прочитали, этого недостаточно для вас, читайте дальше.

Теперь есть пара разных вещей, о которых вам нужно подумать, когда вы беспокоитесь о том, чтобы сделать ваш сайт доступным при различных видах сбоев. Первое - это цели. Вы пытаетесь поддерживать доступность своих сайтов только при отключении? или вы бы предпочли также поддерживать второй сайт, который вы используете для балансировки нагрузки между локациями? Какие сбои системы вы пытаетесь предотвратить? Сколько времени и / или денег вы готовы потратить на минимизацию простоев?

После того, как вы установили некоторые цели, теперь вы можете взглянуть на различные виды решений, которые существуют. Вообще говоря, все различные стратегии минимизации времени простоя включают в себя синхронизацию одного или нескольких «дополнительных» местоположений с контентом в основном местоположении, предпочтительно в другом хостинг-провайдере и сети, чтобы предотвратить простои, которые распространяются на всю компанию. Отработка отказа обычно выполняется путем манипулирования записями DNS. Более крупные компании иногда используют решения на уровне IP, такие как anycasting или управление маршрутами, для выполнения задач, что дает ряд преимуществ, но это дорого и крайне сложно выполнить правильно.

Есть много компаний, которые могут помочь вы изменяете свои записи DNS автоматически, когда один IP-адрес становится недоступным, но вы можете довольно легко сделать это самостоятельно, используя Cloudflare API (или API любого вашего DNS-провайдера, если вы измените его в будущем). Все, что требуется, это вторая система в другом месте, где бы ни размещался ваш веб-сайт, постоянно проверяет ваш сайт, чтобы убедиться, что он работает. В противном случае он обращается к API вашего DNS-провайдера и изменяет записи DNS вашего сайта, чтобы указать на ваше резервное хранилище. Это означает, что у вас будет наихудший (на бумаге) простои интервала мониторинга + TTL DNS. На практике DNS может быть достаточно агрессивно кэширован, и даже короткие (<30 секунд) TTL могут занять до пары часов, чтобы полностью очистить их всеми клиентами по всему миру. Мобильные устройства, в частности, известны своей проблемой. Существует множество руководств о том, как использовать различные системы мониторинга для выполнения этой задачи - быстрый поиск по запросу «cloudflare failover» дал мне эти два , которые используют nagios и monit соответственно, но я я уверен, что есть много более легкодоступных.

Конечно, для любого вида аварийного переключения требуется место, куда можно переключиться! Для этого существует множество различных требований, в зависимости от вашего конкретного приложения. s спецификации и требования к синхронизации. Некоторые сайты, которые представляют собой статический контент, можно просто копировать каждый раз, когда они обновляются в обоих местах, вручную, с помощью автоматизированного скрипта, который отправляет или извлекает от главного к подчиненным (cron + rsync - ваш друг!) Или другие такие методы, как блочная репликация (DRBD) или общая файловая система (GlusterFS). Другие сайты с динамическим содержимым потребуют как такой синхронизации на уровне файлов, так и репликации базы данных в настройке «главный-подчиненный». Обратите внимание: базы данных могут вызывать всевозможные проблемы, если вы пытаетесь принимать записи в обоих местах, поэтому тщательно изучите репликацию главной / главной базы данных с использованием ваших конкретных технологий базы данных, если вы планируете иметь оба центра обработки данных одновременно. Нередко настраивают ведомое устройство как реплику только для чтения даже при отказе, чтобы избежать необходимости обратно синхронизировать данные с повышенного ведомого устройства, когда главный центр снова доступен.

разные вещи, о которых следует подумать при рассмотрении такого рода настройки высокой доступности. Если вы расскажете нам немного больше о специфике вашего приложения, я уверен, что мы сможем добавить более конкретный совет.

Вместо покупки NodeBalancer универсальной, готовой к использованию функции от Linode, вы можете просто купить еще один обычный Linode и реализовать балансировку нагрузки и кэширование,

Вы можете использовать nginx, и он будет действовать как прокси и балансировщик для вашего реального веб-сайта.

В зависимости от того, требуется ли вам, чтобы ваш веб-сайт изменялся каждые пару часов / дней или нет, вы можете использовать несколько функций nginx для сохранения контента из ваших исходных Linodes.

http://nginx.org/en/docs/http/ngx_http_proxy_module.html

Одна из функций, которую вы можете найти очень полезной, - это proxy_cache . Другой - proxy_store .

Набор директив proxy_cache очень гибкий, так что nginx может быть настроен на автоматическое сохранение и удаление всех страниц, или автоматически обслуживать устаревшие страницы, только те, которые находятся в восходящем потоке, недоступны (например, посмотрите proxy_cache_use_stale ). В то время как proxy_store потенциально может быть реализован вместе с ручным скриптом очистки rm -rf , в зависимости от ваших потребностей.

Конечно, если вы уже платите 20 $ / mo для вашего балансировщика нагрузки в Linode (и при условии, что вы не превышаете бюджет), тогда вы также можете отменить это и изучить CloudFlare, Incapsula и другие подобные предложения, некоторые платные версии которых могут быть настроены для кеширования всех видов контента (включая динамически генерируемые, например, начиная с 10 $ / мес в Incapsula).

Best Speed, Best Reliability, Most Secure

If your site is static then you should consider hosting it purely on CDN, then you don't need load balancers , dedicated or vps servers. Good CDNS scale as much you need and your only charged for the send amount or per Xrequests depending which company you go with. In regards of the non www cname issues I believe that cloudsflare has a workaround, Rackspace and Amazon you'd need a vps to redirect from non www to www. on the cdn.

CDN would offer more performance than a vast number dedicated servers or vps. Also its by far the most reliable and secure.

If you have some php files like contact forms then you can host them on a vps 64mb-256mb by using ajax js.

Further you mention mirroring,cdns mirror files all over the world this one of the main reasons there so fast and they use fail proof raids, and other failover redundantances... cdns cant really fail. But if you wanted a mirror say to a vps then you just use the api and cron the backup.

DNS.. Just pickone that has anycast/active failover
http://dyn.com/dns/dns-comparison/

Cloudflare уже может сделать это за вас. Хотя служба называется Always Online ™ (прокрутите вниз примерно наполовину).

Если вам нужно собственное решение, используйте прокси / балансировщик нагрузки. Что-то вроде haproxy очень хорошо для этого подходит. Хотя, поскольку это статический запрос файла, nginx тоже будет работать очень хорошо. Итак, если кто-то выходит из строя, прокси просто перестает запрашивать у неработающего сервера. Но обратите внимание, что использование одного только балансировщика нагрузки не является аварийным переключением, вам нужны дополнительные веб-серверы, готовые обслуживать дополнительную нагрузку, когда другой выходит из строя.

Аварийное переключение DNS, о котором вы упомянули, не рекомендуется, если вы хотите оставаться в одном центре обработки данных. См. Почему не рекомендуется переключение DNS? В этом сообщении также будут описаны некоторые дополнительные решения для вас.