У меня довольно интенсивный веб-сайт, и из-за некоторых неудачных инцидентов машины, которые находятся в моем облаке в Linode, вышли из строя. И у меня есть только одна машина Load Balancer, доступная внешнему миру (один IP).
Также мой сайт претендует на 6000 статических страниц которые можно отразить. Теперь мой DNS CloudFlare.
Что я могу сделать, чтобы сохранить статическое зеркало моего сайта и перейти к нему, если мой сайт выйдет из строя.
Поскольку я убегаю от Линоде, у меня нет ничего подобного Маршрут53 для обнаружения времени простоя на IP-адресе и указания на другой.
Какие стратегии люди используют статическое зеркало сайта и работают против простоев?
В первую очередь на ум приходит пара разных вещей:
Во-первых, у вас уже есть статическое зеркало вашего сайта, предназначенное только для этого варианта использования: 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 могут занять до пары часов, чтобы полностью очистить их всеми клиентами по всему миру. Мобильные устройства, в частности, известны своей проблемой. Существует множество руководств о том, как использовать различные системы мониторинга для выполнения этой задачи - быстрый поиск по фразе «отказоустойчивость облачных вспышек» помог мне эти два которые используют nagios и monit соответственно, но я уверен, что есть много более доступных.
Конечно, для любого вида аварийного переключения требуется место, куда можно переключиться! Для этого существует множество различных требований в зависимости от спецификаций вашего конкретного приложения и требований к синхронизации. Некоторые сайты, которые представляют собой статический контент, можно просто копировать каждый раз, когда они обновляются в обоих местах, вручную, с помощью автоматизированного скрипта, который отправляет или извлекает от главного к подчиненным (cron + rsync - ваш друг!) Или другие такие методы, как блочная репликация (DRBD) или общая файловая система (GlusterFS). Другие сайты с динамическим содержимым потребуют как такой синхронизации на уровне файлов, так и репликации базы данных в настройке «главный-подчиненный». Обратите внимание, что базы данных могут вызывать всевозможные проблемы, если вы пытаетесь принимать записи в обоих местах, поэтому тщательно изучите репликацию главной / главной базы данных с использованием ваших конкретных технологий баз данных, если вы планируете иметь оба центра обработки данных одновременно доступными. Нередко настраивают ведомое устройство как реплику только для чтения даже при отказе, чтобы избежать необходимости обратно синхронизировать данные с повышенного ведомого устройства, когда главный центр снова доступен.
При рассмотрении такого рода настройки высокой доступности необходимо учитывать множество разных вещей. Если вы расскажете нам немного больше о специфике вашего приложения, я уверен, что мы сможем добавить более конкретные советы.
Вместо того, чтобы покупать NodeBalancer подходит для всех, готовая к использованию функция от Linode, вы можете просто купить другой обычный Linode и самостоятельно реализовать балансировку нагрузки и кеширование.
Вы можете использовать nginx, и он будет действовать как прокси и балансировщик для вашего реального веб-сайта.
В зависимости от того, требуется ли вам, чтобы ваш веб-сайт изменялся каждые пару часов / дней или нет, вы можете использовать несколько функций nginx для сохранения контента с ваших восходящих линодов.
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 долларов в месяц за свой балансировщик нагрузки в Linode (и при условии, что вы не превышаете бюджет), вы можете отменить это и изучить CloudFlare, Incapsula и другие подобные предложения, некоторые из которых платные. версии которых могут быть настроены для кэширования всех видов контента (включая динамически генерируемый, например, начиная с 10 $ / мес в Incapsula).
Лучшая скорость, лучшая надежность, самая безопасная
Если ваш сайт статический, вам следует подумать о размещении его исключительно на CDN, тогда вам не нужны балансировщики нагрузки, выделенные или vps-серверы. Хороший CDNS масштабируется настолько, насколько вам нужно, и вы платите только за сумму отправки или за Xrequests, в зависимости от того, с какой компанией вы работаете. Что касается проблем с именами без www, я считаю, что у cloudflare есть обходной путь, Rackspace и Amazon вам понадобятся vps для перенаправления с не www на www. на компакт-диске.
CDN будет предлагать большую производительность, чем огромное количество выделенных серверов или vps. Кроме того, это самый надежный и безопасный вариант.
Если у вас есть некоторые файлы php, такие как контактные формы, вы можете разместить их на vps 64–256 МБ, используя ajax js.
Далее вы упоминаете зеркалирование, зеркальные файлы cdns по всему миру - это одна из основных причин, по которой они работают так быстро, и они используют рейды с защитой от сбоев и другие избыточные резервы ... cdns действительно не может выйти из строя. Но если вы хотите, чтобы зеркало говорило vps, вы просто используете api и cron для резервного копирования.
DNS .. Просто выберите тот, у которого есть любое / активное аварийное переключение
http://dyn.com/dns/dns-comparison/
Cloudflare уже может сделать это за вас. Хотя служба называется Всегда в сети ™ (прокрутите вниз примерно наполовину).
Если вам нужно собственное решение, используйте прокси / балансировщик нагрузки. Что-то вроде haproxy очень хорошо работает для этого. Хотя, поскольку это статический запрос файла, nginx тоже будет работать очень хорошо. Итак, если кто-то выходит из строя, прокси просто перестает запрашивать у неработающего сервера. Но обратите внимание, что использование одного только балансировщика нагрузки не является аварийным переключением, вам нужны дополнительные веб-серверы, готовые обслуживать дополнительную нагрузку, когда другой выходит из строя.
Отказоустойчивость DNS, о которой вы упомянули, не рекомендуется, если вы хотите оставаться в одном центре обработки данных. Видеть Почему отказоустойчивый DNS не рекомендуется? В этом посте также будут описаны некоторые дополнительные решения для вас.