Может быть, мой вопрос немного глуп, но идея состоит в том, чтобы иметь резервный веб-сервер, который будет активирован, КОГДА основной веб-сервер станет неактивным (DDos или любой другой инцидент).
Назовите общие практики для этого решения. Операционная система будет FreeBSD. Мне действительно интересны имена пакетов, методы, как синхронизировать файлы почти в реальном времени, с минимальной задержкой, особенно сервер базы данных, потому что платежи, сеансы и тому подобное должны оставаться такими, как они были запущены на первом сервере. Моя первая идея - это rsync, но для меня это звучит неубедительно, если вы думаете, сколько вещей нужно передать ... Я даже согласился бы клонировать стек памяти =))
p.s. даже если вы, ребята, не понимаете, о чем я говорю, или мне нужно быть более конкретным, снимайте все свои идеи для различного рода синхронизации =) Thnx.
РЕДАКТИРОВАТЬ:
Спасибо, ребята, теперь у меня много идей по отработке отказов. Я, вероятно, буду использовать HA Cluster с балансировкой нагрузки.
Почему аварийное переключение вместо использования интеллектуальной балансировки нагрузки? Есть много вещей, которые могут пойти не так во время операции переключения при отказе - с балансировкой нагрузки это не проблема.
Для репликации файлов в реальном времени взгляните на AFS или его производные, или используйте обычный HD с файловой системой кластера. Для не-реального времени - rsync или unison. Для репликации базы данных .... ну, это зависит от вашей текущей БД.
В пространстве Linux веб-серверы будут монтировать файловую систему кластера (например, OCFS2). Я не знаю, существует ли во FreeBSD «настоящая» кластерная файловая система. Вы можете использовать NFS с опцией монтирования «noac», но производительность ужасна, поэтому его не рекомендуется использовать в качестве надежного / масштабируемого решения.
Ура
Изменить: Что касается резервной природы веб-сервера, используйте прокси / балансировщик нагрузки, такой как nginx, который выполняет обратную передачу двух серверов. Конфигурация nginx фактически определяет резерв как «резервную копию».
Вы можете почерпнуть литературу о GGATED на FreeBSD, но если вы хотите использовать другую ОС для хранения своей базы данных MySQL, тогда DRBD с участием Сердцебиение - хорошее решение для зеркалирования данных в реальном времени и обработки автоматического переключения кластера mySQL при отказе.
РЕДАКТИРОВАТЬ: это также не снизит вероятность DDOS-атаки на ваш внешний IP-адрес.
На высоком уровне вам нужно создать двухузловой кластер высокой доступности с аварийным переключением.
http://www.todoo.biz/cluster_ha_freebsd.php
Какой тип страницы размещен на веб-сервере? Присутствует ли база данных?
идея состоит в том, чтобы переключиться при отказе основного сервера. это может быть выполнено очень легко, если в этой проблемной области нет ограничений, поскольку у вас нет такого компонента, как привязка сеанса или центральной базы данных.
теперь, если у вас есть этот тип ограничений, вы все равно можете это сделать, но более ограниченным образом. например, если вы хотите иметь один сервер в Австралии и один в США, для серверов будет сложнее использовать общую базу данных через Интернет.
однако, если вы можете жить с аварийным переключением в один и тот же центр обработки данных (сеть), единственная проблема в этом случае, когда вы сохраняете сеансы - если они находятся в базе данных, вы все настроены, потому что оба сервера могут читать эти данные.
для содержимого сервера, даже если вы чувствуете, что rsync не работает ... разве он не просто выполняет свою работу. есть и другие решения, например, наличие общей файловой системы и т. д.
в случае, если у вас есть серверы, географически разделенные, вы можете посмотреть в базу данных, отличную от sql, которая распространяется через Интернет (посмотрите appengine из google :) или используйте один из инструментов, которые предложил maxwell.