9 января 2007 в 16:02
Есть люди дико озабоченные безопасностью сайта, которые хотят сделать зеркало. Т.е. чтобы сайт был доступен с двух серверов, одновременно, причем сервера в разных частях планеты. НЕ бэкап базы данных, а как-то в реальном времени, на лету, чтобы если перерубят кабель в одном месте все работало без перебоев в другом.
Сайт сам не очень большой. Как такое сделать и возможно ли вообще я незнаю. Что-нибудь посоветуете?
Комментарии
сделать для каждого зеркала файл robots.txt (в корне)
и ссылку поставить на основной...
А если у www.основной сайт.ru прововод покоцают?
тогда верёвка пушистая и мыло душистое...
или редирект))
Скорее это два сервера, для каждого свое доменное имя site.ru и site.org, при этом должна быть синхронизация БД в режиме реального времени. Но что-то мне подсказывает что это из разряда фантастики.
Два сайта, на разных доменах. Ну например org и ru.
А база на выделенном серверном кластере в третьем месте, постоянным зеркалированием по RAID массивам.
Ну а с этих сайтов удаленные запросы того же PostgreSQL ...
Нет, это конечно возможно, но так никто не делает. Такая схема безсмысленна из-за своей неэффективности.
Вопервых RAID массив не относится к решениям зеркализации, а является продолжением технологии резервного копирования.
Во вторых зеркалом является резервный сервер с тем же доменным именем, либо, как в старину, с измененным префиксом (например ww2. или www2. вместо www.), но стоять такой сервер действительно должен в другом месте, или хотя бы на другом IP.
В третьих кластеры, как и в случае с RAID, используются не столько для зеркалирования, сколько для повышения производительности, отказоустойчивости и удобоабслуживаемости отдельной системы (если мы не говорим о распределенных кластерах, которые стоят как полтора самолета).
Ну и наконец не только PostgreSQL умеет работать с базой по IP, но и любая современная база данных. Хотя на практике использование удаленной базы данных вызывает кучку нетривиальных проблемм, и в сайтостроении почти не применяется.
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы
Понимаю, мир Друпала на столько далек от мира юниксоидов, что даже простую репликацию можно смело относить в разряд фантастики
На самом деле есть десятки способов: от трехуровневых кластеров, до самописных скриптов синхронизации - всё зависит от задачь проекта и бюджета.
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы
На все 100.
Вобщем читайте доки Апача и MySQL'я, там эти темы подробно освещены (а так же учитесь настраивать named, хотя за психическое здоровье научившихся не поручусь %~).
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы
Во первых - автору статьи посвящается - кабель не перерубят, по тому как почти у любого хостинг провайдера, даже самого дешевого, есть услуга, аля охраняемый выделенный сервер. Охрана там стоит настоящая. Ибо подумайте сколько компаний среднего звена хостятся не у себя, а у провайдера? Их бы давно обокрали всех до единого, если б не возможность (повторяю) охраняемой площадки.
Во вторых
, я имел в виду RAID 1 как способ зеркалирования дисковых массивов
>>Вопервых RAID массив не относится к решениям зеркализации, а является продолжением технологии резервного копирования.
____
А я и не уверял, что это способ зеркализации сайта. В этом контексте (внимательнее на до быть
>>Во вторых зеркалом является резервный сервер с тем же доменным именем, либо
____
Автор писал: "Скорее это два сервера, для каждого свое доменное имя site.ru и site.org...". Насколько я понял это его непосредственное условие в задаче. Если это не так - пардон.
>>В третьих кластеры, как и в случае с RAID, используются не столько для зеркалирования, сколько для повышения производительности, отказоустойчивости и удобоабслуживаемости отдельной системы (если мы не говорим о распределенных кластерах, которые стоят как полтора самолета).
_____
Ну так в данном случае именно это и надо.
Удаленные SQL запросы, по несколько по несколько 1000 в минуту например, требуют стабильности и скорости выполнения задач. Тем паче, что сервер баз данных физически может находиться в Улан-Баторе а сайты на серверах в Будапеште и Норильске.
>>Ну и наконец не только PostgreSQL умеет работать с базой по IP, но и любая современная база данных.
_____
Видимо я не правильно понят был.
Мои слова: "Ну а с этих сайтов удаленные запросы того же PostgreSQL ...
"
По моему скромному мнению, того же не означает только.
С уважением
''Во первых - автору статьи посвящается - кабель не перерубят, по тому как почти у любого хостинг провайдера, даже самого дешевого, есть услуга, аля охраняемый выделенный сервер.''
Ну зря вы так думаете, вы же не знаете какие нравы в Улан-Баторе ))
На самом деле, т.к. сайт сам не оч. посещаемый пока, затраты на такие махинации себя не окупят ИМХО. Проще регулярно делать бэкапы и иметь под боком резервный хостинг, чтобы в случае чего развернуться там.
DNS динамический настроить, чтобы редиректил запросы к одному и тому же имени на разные сервера. И БД реплицировать, для MySQL и PostgreSQL есть готовые решения.
--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!
Во, слушайте Акселя, он знает.
Спорить с остальными не стану, только замечу что кабель перерубать не обязательно. Возможно Уважаемые не сталкивались с DoS, DDoS, нашествием спамботов и прочих червей, когда единственный возможный доступ к серверу через консоль, да и то только при отключенном сетевом интерфейсе.
Конечно, такого рода проблемы встают не перед администратором сайта, а перед его старшим братом - хостером и крёстным папой - датацентром, но это не делает их менее реальными.
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы
Реплицикация БД подробно описана в документации по MySQL, (PostgreSQL не пробовал, не знаю :),
Синхронизацию файлов между хостами можно сделать через rsync. Основной вопрос - максимально синхронизировать время запуска этих механизмов, чтобы не получилось так, что база обновлена, а прилагающиеся к материалам картинки еще нет.
Динамически выдаваемый IP через DNS может быть проблемой в том случае если "перерубят кабель", потому как все запросы к отключенному серверу уйдут в никуда...
Так что не смотря на то что по отдельности все выглядит не очень сложно, собрать все это воедино может оказаться непростой задачей.
а почему-бы не сделать модуль который будет просто на второй сервер передавать то что набрали на первом а на втором передавать то что набрали на втором,
Какое однако простое решение! "Просто передавать!" Никаких репликаций и синхронизаций!
На самом деле "модуль для Друпала" будет всего лишь более высоким уровнем абстракции решающим ту же самую задачу на основе существующих механизмов репликации файлов и БД.
Round-robin dns:
http://dedic.ru/node/205
Это решение для распределения нагрузки, отказы всё равно нужно обрабатывать отдельно.
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы
а можно и так сделать - один сервер главный - остальные второстепенные - на них тоже установлены друпалы но обращение идет к базе основного с одним нюансом что таблица/директория кеша у каждого своя.
а вообще новый mysql уже кажется в нем репликации есть какие-то
> Есть люди дико озабоченные безопасностью сайта
> если перерубят кабель в одном месте все работало без перебоев в другом
Вообще-то заявлены две проблемы - безопасность и надёжность.
По мне, так проще купить надёжный хостинг, нежели огребать проблемы с репликацией. Но это моё имхо конечно.
Возвращаясь к теме бюджета: нет смысла морочиться с репликацией, стоящей как хороший автомобиль, когда стоимость проекта в разы ниже.
Если есть возможность растрясти заказчика на отдельную статью бюджета - безопасность и гарантированную доступность сайта (что звучит более чем сомнительно, а подобного клиента, моё воображение, рисовать напрочь отказывается), можно заказать подобное решение у крутых интеграторов, или менее крутых хостеров, или у знакомого юниксоида, а деньги пропить
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы
"или менее крутых хостеров, или у знакомого юниксоида, а деньги пропить"
вот так всегда... а лучше бы было, если проблема всё-таки была решена... мне кажется, не такая уж это страшная вещь, что это невозможно сделать...
но на мой взгляд, куда надёжнее было бы и с DNS не заморачиваться, так как он тоже уязвим для атаки, а поэтому лучше сделать два отдельных сайта по отдельным доменам с репликацией на уровне баз данных... это возможно, не так доростояще и проще в разы...
домены можно сделать похожими настолько, что на это никто не будет обращать внимания...
Еще предлагают бюджетный вариант. Имея 2 виртуальных хостинга, один рабочий другой резервный. На резервный по крону полностью сливать БД. В случае кризисной ситуации нужно обновить DNS. Возможные потери это дельта запуска крона.
Почти такая же проблема...
Есть свой сервак с сайтами. В инет есть выход через 2-х провайдеров. Последнее время стали перебои с каналом основного провайера.
Как замутить чтоб при отсутсвии связи по одному каналу сайт работал через другой канал?
[deleted]
Последние FreeBSD умеют "динамический роутинг" (кажется, это так называется), когда можно прописать, например, два default gateway-я, и трафик будет между ними распределяться, а при падении одного - уйдет через другой. Правда, насколько я понял, этим версиям до состояния STABLE еще далеко.
динамический роутинг придумали очень давно - называется динамическая маршрутизация - провайдеры должны уметь выдавать данные по протоколу BGP - по другому не знаю как - ведь как то надо оповестить всех снаружи о изменении пути к вашему ip-шнику, к тому же надо зарегистрировать автономную систему, а на сервере drupal.ru поменять 386-й процессор на более мощный...
а вот тут про зеркала заговорили, сейчас в крупных городах РФ внутренние сети накрыли целиком города, и народ почти не вылазиет в интернете, они все имеют в своих сетях.
Как сделать эти самые зеркала, или клоны сайта в внутри сетей, чтобы они посещались и работали там внутри?
договорится с провайдером, дабы сделать безлимитный доступ
Интересная тема.
Стало интересно, а что если просто ns прописать не 2 как обычно а 2+2дополнительных. На втором хостинге держать актуальный код и базу данных. Кто в теме?
ребята, а кто скажет конкретно, что надо делать, чтобы в другой сети могли видеть наш сайт и считать его своим?
возникла похожая проблема:
Основной_сайт.ru размещается на сервере_1 у Хостера_1
Зеркало_сайта.ru размещается на шаред-хостинге_2 у Хостера_2
каким образом можно сделать синхронизацию файлов и базы данных
Основного_сайта и Зеркала_сайта хотя бы один раз в час?
Отчасти схожий вопрос. Есть два сайта, хостящиеся у одного хостинг-провайдера и ссылающиеся на общий каталог файловой системы (то есть фактически один сайт, доступный по двум доменным именам одновременно). Первый, соответственно, называется Сайт1 и доступен по ссылке site1.ru, а второй - Сайт2 со ссылкой site2.ru
В итоге вопрос - как отследить, по какому из сайтов сейчас серфит пользователь, чтобы подставить на всех страницах соответствующее название сайта и соответствующие ссылки во все views и кастомно созданные администратором блоки?
а можно ли средствами Друпал как-то сделать, чтобы был сайт
old-name.ru как главное зеркало и на нем весь контент,
например нода 1 по адресу old-name.ru/node1
а на сайте
cool-name.ru это все отражалось бы автоматом
например cool-name.ru/node1
И возможно ли чтобы активность юзеров, зашедших через cool-name.ru учитывалась как будто это активность на old-name.ru ?
Если нет, то какой самый близкий к описанному вариант из реального?
Для этого достаточно направить оба домена old-name.ru и cool-name.ru на один и тот же сайт.
Речь идёт о cluster и программа heatbeat переключает на другой компьютер в случае недоступности первого.
Есть несколько наборов ПО для обеспечения работы и синхронизации. Лучше сначанала все протестировать а потом сдавать в работу.