В настоящее время у меня есть 2 сервера, использующих cPanel / WHM. Первый - это VPS, размещенный в Лондоне (мы назовем его «международным»), а второй - это выделенный сервер, расположенный в моей стране (назовем его «локальным»).
"local" будет иметь неограниченную локальную пропускную способность, однако международная пропускная способность будет только 1 Мбит / с.
Мне нужно разместить один веб-сайт (или, возможно, несколько веб-сайтов) на обоих серверах и обслуживать посетителей в зависимости от страны их происхождения. Я имею в виду, когда посетитель из моей страны, данные будут обслуживаться из «местного», а если посетитель из любой другой страны, данные будут обслуживаться из «международного».
Оба типа посетителей могут выполнять операции чтения / записи на серверах, и мне нужно синхронизировать файлы и базы данных между обоими серверами, поскольку оба сервера будут иметь обновленные файлы и базу данных.
Итак, как это возможно в отношении DNS и синхронизации? Или что легко и возможно? Может ли кто-нибудь помочь мне с шагами, которые я должен выполнить?
Первый, простой, понятный и, прежде всего, крепкий Решение состоит в том, чтобы отказаться от ваших планов иметь два сервера и просто запустить одну машину из подходящего центрального места. Хотя я понимаю причины отказа от размещения чего-либо на локальном сервере из-за ограниченной международной пропускной способности, я не вижу в вашем вопросе ничего, что требует наличия локального сервера.
Если вам нужен локальный сервер исключительно из соображений производительности, я бы серьезно рекомендовал взглянуть на локальный сервер статических ресурсов со всеми динамическими материалами, отправляемыми в Лондон. Хотя geoDNS нетривиально, это намного проще, чем надежная синхронизация в реальном времени ваших динамических ресурсов и базы данных. Этот механизм используется многими сайтами (включая этот) для улучшения общей воспринимаемой скорости страницы, и работает он довольно хорошо.
Предполагая, что это не так, и вы действительно делать Если вам нужны два сервера, я вижу серьезный недостаток в вашем плане - международная полоса пропускания 1 Мбит / с будет довольно насыщена вашим трафиком синхронизации. Вы захотите надеяться, что ваш сайт не станет слишком популярным, иначе вы попадете в мир боли.
Вы находитесь в довольно выгодном положении по отношению к DNS, потому что у вас есть четко определенное подмножество адресов, по которым вы хотите обслуживать определенные записи. Предположительно, вы можете получить у своего провайдера список сетевых блоков, в которых будет указано, что считается «локальным трафиком с неограниченной пропускной способностью», а что считается «международным трафиком с ограничением 1 Мбит / с». Если ваш провайдер не могу Сделайте это, я бы спросил их, как, черт возьми, они на самом деле ограничивают скорость, потому что где-то там должен быть список. В худшем случае, если они просто делают это, основываясь на том, что «все, что мы видим, объявленное по этой ссылке BGP, является локальным», вы все равно должны иметь возможность получить список префиксов по этой ссылке.
Итак, DNS сводится к "для A записывать запросы к www.example.com, обслуживать localip если исходный адрес находится в списке локальных префиксов, и internationalip в противном случае ». Как вы создадите сценарий для ваших DNS-серверов, зависит от вас; я бы пошел с tinydns, потому что я использую его для всего, что могу, и он отлично справляется с этой конкретной задачей.
Но это около 1% от общей проблемы. У вас гораздо большая проблема с динамическими активами города.
База данных на самом деле (относительно) простая часть. И MySQL, и PostgreSQL поддерживают репликацию с несколькими мастерами, в результате чего записи в одну базу данных реплицируются в другую (более или менее) автоматически. Это не совсем тривиально в настройке, и вам нужно контролировать bejesus вне его, чтобы определить, когда он сломается, и исправить это, но он является возможно достаточно стандартизированным способом.
С другой стороны, ваши файлы требуют гораздо большей разведки на местах. Чтобы это работало, вам необходимо правильно спроектировать хранилище файлов, чтобы репликация работала. Это еще интереснее, потому что вы говорите, что вам нужно поддержать удаление.
На самом деле, периодический rsync - ваш лучший друг для этого. Игнорируя аспекты модификации и удаления вещей на секунду, если вы убедитесь, что ваши имена файлов не могут конфликтовать с обеих сторон (использование UUID или PK базы данных в качестве основы для всех ваших имен файлов будет работать хорошо), вы сможете просто сделать периодические rsync каждой стороны с другой, и все новые файлы, созданные на каждой стороне, волшебным образом появятся на другой. Как часто вы выполняете rsync, зависит от того, сколько времени вы можете простоять, прежде чем все будет синхронизировано - это вызов, который вы должны сделать. Ваше приложение также должно разумно обрабатывать случаи, когда (например) записи БД синхронизированы, а файлы - нет.
Удаление значительно усложняет задачу, потому что вы не можете просто запустить слепой rsync -a --delete потому что все, чего нет у отправителя, будет удалено из получателя - отличный способ потерять много данных. Я бы предпочел иметь журнал удалений и время от времени просматривать его и удалять вещи с другой стороны. Если это вас не устраивает, вы можете пофантазировать с двумя отдельными файловыми системами на каждом конце (одна для «локальных данных», а другая для «реплики другого конца») и либо получить доступ к обеим из них из вашего приложения, либо используйте слой объединенной файловой системы, чтобы они выглядели как одна файловая система для веб-сервера.
Модификация - это просто кошмар - вы рискуете одновременной модификацией на обоих серверах, и тогда вы просто облажаетесь. В модели «конечной согласованности», с которой вы работаете (которая для географически распределенной системы репликации с высокой задержкой, с которой вы вынуждены иметь дело, является единственным вариантом), вы просто не можете справиться с этим в инфраструктуре. уровень - вы должны пойти на какой-то компромисс в своем приложении, чтобы решить, как решать такие проблемы. Вы можете помочь в этой ситуации, рассматривая свою файловую систему как хранилище только для добавления (если вы хотите изменить файл, вы пишете новую версию и обновляете свою базу данных, чтобы указывать на новую запись), но поскольку ваша база данных тоже только в конечном итоге вы не сможете решить проблему полностью. По крайней мере, если ваша база данных является единственной точкой истины, тем не менее, у вас будет гарантированная согласованность, если не гарантированная правильность, а это половина дела.
И я думаю, что это почти все. Однако повторюсь, жизнь намного проще, если вы не приходится использовать географически распределенные серверы. Если вы применяете это, потому что это «круто звучит», отойдите от клавиатуры. Если вы хотите делать крутые вещи, делайте это в свободное время или в качестве научного эксперимента. Вам платят за то, что вы делаете то, что наиболее эффективно для вашего работодателя, а не за то, что вызывает у вас приапизм.