Как разместить один веб-сайт на нескольких географически разных серверах

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

Если ваши причины, по которым вам нужен локальный сервер, вызваны исключительно соображениями производительности, я бы настоятельно рекомендовал взглянуть на локальный статический сервер активов, а все динамические вещи отправляются в Лондон. Хотя geoDNS не тривиален, он намного проще, чем надежная синхронизация в реальном времени ваших динамических активов и базы данных. Этот механизм используется многими сайтами (включая этот) для улучшения общей воспринимаемой скорости страницы, и он работает довольно хорошо.

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

Вы находитесь в довольно благоприятном положении по отношению к DNS, потому что у вас есть четко определенное подмножество адресов, которым вы хотите предоставить определенные записи. Предположительно, вы можете получить список сетевых блоков от вашего провайдера, в которых будет определено, что считать "локальным трафиком с неограниченной пропускной способностью", а что - как "международный трафик с ограничением 1 Мбит / с". Если ваш провайдер не может этого сделать, я бы спросил их, как, черт возьми, они на самом деле делают ограничение скорости, потому что где-то там должен быть список. В худшем случае, если они просто делают это, основываясь на том, что "все, что мы видим объявленным по этой ссылке BGP, является локальным", вы все равно сможете получить список префиксов для этой ссылки.

Таким образом, материал DNS сводится к "для A записывать запросы www.example.com, обслуживать localip если адрес источника находится в списке локальных префиксов, и internationalip иначе ". Как вы пишете, что для ваших заданных DNS-серверов зависит от вас; я бы пошел с tinydnsпотому что я использую это для всего, что я могу, и это довольно здорово в этой конкретной задаче.

Но это около 1% от общей проблемы. У вас гораздо больше проблем с динамичной активностью города.

База данных на самом деле (относительно) легко. И MySQL, и PostgreSQL поддерживают репликацию с несколькими хозяевами, в результате чего записи в одну из баз данных реплицируются в другую (более или менее) автоматически. Это не совсем тривиально для установки, и вам нужно следить за bejesus из него, чтобы обнаружить, когда он ломается и исправить это, но это возможно довольно стандартизированным способом.

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

Действительно, периодический rsync - ваш лучший друг для этого. Не обращая внимания на аспекты изменения и удаления вещей на секунду, если вы убедитесь, что ваши имена файлов не могут конфликтовать с обеих сторон (при использовании UUID или PK базы данных в качестве основы для всех ваших имен файлов будет работать хорошо), вы сможете просто сделать периодические rsyncs каждой стороны к другой, и все новые файлы, созданные на каждой стороне, будут волшебным образом появляться на другой. Как часто вы выполняете rsync, зависит от того, сколько времени вы можете стоять до того, как все синхронизируется - это вызов, который вы должны сделать. Вашему приложению также необходимо разумно обрабатывать случаи, когда (например) записи БД синхронизированы, а файлы - нет.

Удаление делает вещи намного сложнее, потому что вы не можете просто запустить вслепую rsync -a --delete потому что все, чего нет у отправителя, будет удалено из получателя - отличный способ потерять много данных. Я бы предпочел иметь журнал удалений, периодически просматривать его и удалять вещи с другой стороны. Если вам это не понравится, вы можете использовать более две отдельные файловые системы на каждом конце (одна для "локальных данных", а другая для "реплики другого конца"), и либо получить доступ к ним из вашего приложения, либо используйте объединенный слой файловой системы, чтобы они выглядели как одна файловая система для веб-сервера.

Модификация - это просто полный кошмар - вы рискуете одновременными модификациями на обоих серверах, и в этот момент вы просто облажались. В той модели "возможной согласованности", с которой вы работаете (для географически распределенной системы репликации с высокой задержкой, с которой вам приходится иметь дело, это единственный вариант), вы просто не можете справиться с этим в инфраструктуре. уровень - вы должны пойти на какой-то компромисс в своем приложении, чтобы решить, как справляться с такого рода проблемами. Вы можете помочь в этой ситуации, рассматривая вашу файловую систему как хранилище только для добавления (если вы хотите изменить файл, вы пишете новую версию и обновляете свою базу данных, чтобы указывать на новую запись), но поскольку ваша база данных тоже только в конечном итоге, вы не можете решить проблему полностью. По крайней мере, если ваша база данных - единственная точка правды, вы будете иметь гарантированную согласованность, если не гарантированную корректность, что является залогом успеха.

И я думаю, что примерно все охватывает. Повторим еще раз: жизнь намного проще, если вам не нужно использовать географически распределенные серверы. Если вы реализуете это, потому что это "звучит круто", отойдите от клавиатуры. Если вы хотите делать классные вещи, делайте это в свое время или в качестве научного эксперимента. Вам платят за то, что вы делаете то, что наиболее эффективно для вашего работодателя, а не за то, что дает вам чудак приапизм.