Каковы преимущества и недостатки зеркального отображения сайта [закрыто]
Пользователь Джейсон Таун посоветовал мне задать этот вопрос здесь, а не на ТАК ЧТО. Итак, вот что:
Вопрос 1:
При зеркальном отображении сайтов содержимое их соответствующих серверы синхронизируются (возможно, автоматически (живые зеркала) или вручную). Это правда? Все ли серверы "равны" или существует основной сервер? который затем отправляет изменения на другие "дочерние серверы"? Значит, все изменения должны происходить на главном сервере, а дочерним серверам запрещены изменения?
Вопрос 2:
Ожидаемые преимущества:
- Глобальное преимущество: когда сайт, первоначально размещенный в США, зеркально отображается на сервере в Лондон, европейцы выиграют от этого. У них будет лучшее время отклика, а поскольку количество загрузчиков сокращено на две части (американские и европейские серверы), их скорость загрузки может быть выше.
- Безопасность: Когда один сервер выходит из строя или взломан, другой сервер может продолжать нормально работать.
Ожидаемые недостатки:
- Если живое зеркальное отображение не используется, некоторым пользователям придется ждать обновления содержание.
- Большее количество серверов означает более высокие затраты на содержание.
Какие еще пункты можно добавить в эти списки?
2 answers
Существует множество различных способов зеркального отображения сайта (и для разных целей, таких как резервное копирование/высокая доступность или для балансировки нагрузки/распределения). Вы можете использовать запланированную передачу данных или двустороннюю синхронизацию, или вы можете вносить изменения в зеркала по мере их поступления через приложение, или вы можете настроить репликацию базы данных, которая сама по себе может быть настроена по-разному, например, настройка ведущего устройства с несколькими ведомыми устройствами для чтения, но записи только в ведущее устройство базы данных, или вы можете настроить двустороннюю репликацию с 2 или более совместными мастерами, где вы записываете в любое из зеркал базы данных.
В зависимости от настроек у вас могут быть разные затраты на хранение, производительность и пропускную способность. В зависимости от приложения и настроек у вас также могут возникнуть проблемы с согласованностью данных. Для некоторых приложений вам может потребоваться воспользоваться блокировками таблиц, чтобы обеспечить атомарность транзакций. И чем больше зеркал вам нужно синхронизировать, тем больше вызов становится. Это одна из причин, по которой люди часто выбирают одностороннюю репликацию ведущий-ведомый, чтобы им не нужно было решать эту проблему. Конечно, если вы это сделаете, то все изменения должны быть записаны на один сервер, независимо от географического местоположения конечного пользователя, и вы получаете преимущества географической близости только при чтении из подчиненных баз данных. Но если ваше приложение сильно загружено чтением и мало записывает, то это может быть справедливым компромиссом.
Во многих кейсы, веб-мастера и разработчики просто не готовы справляться со всеми этими сложностями. Если вы намерены просто создать резервную копию своих данных, есть более простые способы сделать это (черт возьми, ваш веб-хост, вероятно, уже предлагает стандартное решение). Если ваша цель - обеспечить избыточность данных и поддержку отработки отказа приложений, платформы облачных вычислений и некоторые виртуальные частные компании могут обеспечить это без необходимости пачкать руки. Или, по крайней мере, они обеспечивают стандартную, хорошо продуманную и проверенные и проверенные решения, которые вы можете использовать, просто используя их платформу хостинга и следуя их рекомендациям по разработке.
CDN - это еще один вариант с низким уровнем обслуживания. Обычно они предназначены для статических данных, но их также можно использовать для размещения динамических данных или ускорения приложений. В последнем случае вам потребуется кодировать их архитектуру CDN и использовать их API, но это все равно требует меньше работы и обеспечивает более высокую доступность и избыточность, чем при настройке базы данных репликация или какое-либо решение для зеркального отображения вручную с использованием нескольких VPS или выделенных серверов.
Чтобы ответить на ваш первый вопрос, наиболее распространенным методом создания зеркал между серверами является использование программы под названием rsync в системах Linux/Unix. Основы того, как это сделать, можно прочитать здесь http://kb.liquidweb.com/using-rsync-to-transfer-and-synchronize-local-and-remote-systems/
В apache foundation также есть учебник по созданию зеркальных сайтов, в котором также используется rsync, поэтому это обычная команда для резервного копирования и зеркал.
Веб-сайт, размещенный в Лондоне, может не всегда будет быстрее, чем веб-сайт, размещенный в США. Какой веб-сайт будет работать быстрее, размещенный на одном сервере с подключением OC-48+ и без других доменов на сервере в США, по сравнению с веб-сайтом, размещенным на домашнем компьютере с широкополосной связью? Далее идет CDN, какой веб-сайт использует CDN, в то время как местоположение играет определенную роль в CDN, если ваш сервер работает медленно вверх по течению, это повлияет на скорость ваших веб-сайтов, а местоположение ничего не значит.
Что касается безопасности, то вы имеете в виду наличие резервные серверы и балансировка нагрузки. Для этого я предлагаю Scalr http://code.google.com/p/scalr / он будет следить за вашими серверами и, если один выйдет из строя, вызовет другой.