Прозрачная географическая обработка отказа веб-сайта DR
С точки зрения безопасности это почти никогда не хорошая идея позволить пользователю системы (как www-данные) войти в систему удаленно.
Вместо этого создайте нового пользователя конкретно для владения файлами Wordpress. Сделайте www-данные основной группой для Вашего пользователя, так, чтобы все файлы, которые Вы создаете, были, находящимися в собственности группы группы www-данных. Пока Ваш umask не слишком строг, никакие файлы, которые Вы создаете, поскольку этот пользователь должен быть читаем группой www-данных и таким образом также видим к веб-серверу.
Наконец, я рекомендовал бы против использования FTP (по нескольким причинам, причем безопасность крупнейшим), и вместо этого использовал бы SFTP, SCP или rsync-over-ssh.
Вот некоторые из моих прошлых вопросов.
Общий TL; DR заключается в том, что DNS не является решением , по многим причинам, некоторые из которых вы определили. Некоторые из них находятся в ответах на связанные выше вопросы.
Единственный реальный способ обеспечить географическую устойчивость - это использовать BGP и разделить / 23 на 2/24, объявить их вашими вышестоящими подразделениями, а затем оттуда выполнить отдельные операции с DNS.
Тогда возникает раздражающая проблема синхронизации между ними, но это уже другая история.
Я могу синхронизировать SQL-серверы с помощью ряда различных методов, поэтому это не проблема.
Ну, это еще не проблема.
Если вы использовали интеллектуальное перенаправление, изменив имя хоста или проксируя запрос, у вас возникнет еще одна проблема .. «Куда вы поместите прокси, чтобы он не был SPOF»
В противном случае у вас было бы N географически разделенных сайтов, но одна единственная точка отказа (механизм прокси / перенаправления).
Я полагаю, что теоретически вы могли бы использовать MPLS вместо этого, чтобы ваши местоположения выглядели как в одной сети L2, хотя я не уверен, как это на самом деле поможет повысить устойчивость к сбоям.
DNS сам по себе не обеспечивает возможности автоматического переключения при отказе. Но в сочетании с повторной попыткой клиента браузера он предлагает бесплатное (с точки зрения вложений в сеть) решение с низкой задержкой (~ 1 с). Подробнее см. Ссылки ниже.
http://blog.engelke.com/2011/06/07/web-resilience-with-round-robin-dns/
Несколько центров обработки данных и HTTP-трафик: DNS Round Робин - ЕДИНСТВЕННЫЙ способ обеспечить мгновенное переключение при отказе?