Вопросы Теги

выравнивание нагрузки два веб-сервера каждый на двух различных isp's?

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

2
задан 20 April 2010 в 14:14
3 ответа

Круговой DNS не собирается решать Вашу проблему - это - отличный способ обеспечить выравнивание нагрузки веб-серверов - но обработка отказа происходит, когда клиент пытается соединиться с портом и не получает ответа (это затем продолжает пробовать следующую запись DNS за хост). Очевидно, если база данных MySQL перестанет работать, то это не окажет прямого влияния на веб-сервер (т.е. веб-сервер ответит на запросы TCP).

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

Единственным практическим путем я могу думать для контакта с этим сценарием, должен перенаправить к определенному имени хоста в случае обнаружения отказов, поэтому если Вы в настоящее время будили оба набора хостов, поскольку www.example.com затем добавляет записи для www1.example.com и www2.example.com, затем включает автопредварительно ожидание, включают файл, чтобы сделать что-то как:

(on www1.example.com)
check_db();
// if check_db returns, then continue with normal processing...

function check_db() {
  if (request is for www.example.com) { // avoid loops when both sites fail
     if (last check more than 10 secs ago) {
         if (database status bad) {
            raise a database failed flag on the filesystem
            redirect to www2.example.com
            end
         }
     } else {
         if (database failed flag set) {
             redirect to www2.example.com
             end
         }
         return OK
     }
   } else { // request is for www1.example.com i.e. we are already in failover mode
     if (database failed flag set) && (last check more than 5 secs ago) {
         if (database status good) {
            remove database failed flag
            return OK
         } else { // oh no! both hosts down!
            print sorry message and exit
         }
     } else if (last check more than 5 secs ago) {
         if (database status bad) {
            raise a database failed flag on the filesystem
            print sorry message and exit
         }
     }
   }
   return OK
}

Однако Вам все еще нужен некоторый способ протестировать, если база данных работает, не используя блокирующийся вызов.

HTH

C.

2
ответ дан 3 December 2019 в 11:13

Вы просите, заменяют, не выравнивание нагрузки, мне кажется.

Замените является чрезвычайно трудным преуспеть, особенно с оборудованием, которое не является в той же инфраструктуре. Лучший случай должен был бы получить избыточную географическую подсистему балансировки нагрузки в Вашем ISP, который тестирует Ваши сайты и обрабатывает обработку отказа беспрепятственно. Так как мое предположение, это вне Вашего бюджета, давайте пойдем для метода жевательной резинки и палок.

Так как Вашей проблемой, по-видимому, является MySQL, не веб-сервер, затем давайте решим проблему под рукой.

Данный:

  • Хост A: Веб-сервер и база данных MySQL
  • Хост B: Веб-сервер и избыточная база данных MySQL

Метод, который я использовал бы, будет:

  1. Сохраните свои учетные данные соединения с базой данных на диске где-нибудь (очевидно, не в веб-корне) и загрузите их после каждого соединения страницы. Можно отредактировать sites/default/settings.php как так:

    $db_url = file_get_contents ('/some/private/dir/drupal-db.url');

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

  3. Если Вы хотите стать необычными, можно попытаться зарегистрироваться, все ВСТАВЛЯЮТ и ОБНОВЛЯЮТ к диску на веб-сервере, таким образом, можно потенциально повторно синхронизировать базы данных после обработки отказа. Если это главным образом "только для чтения" затем, это не может быть необходимо.

Основная точка здесь должна разъединиться, заменяют от операции веб-приложения. Это является более модульным, и упрощает изменения в веб-приложении.

Наконец, удостоверьтесь, что можно соединиться с резервной базой данных от основного сервера. Можно сделать это на командной строке, и использующий команды предоставления:

На хосте B:

mysql> GRANT ALL PRIVILEGES ON drupaldb.* TO username@'12.34.56.78' IDENTIFIED BY 'mypassword';

Где IP имеет Хост A.

И не забывайте сбрасывать!

mysql> FLUSH PRIVILEGES:

Затем тест:

bash> mysql -u username -pmypassword -h hostb drupaldb
1
ответ дан 3 December 2019 в 11:13

Никакой путь, нет никакой достойной технологии для того - учитывая Вашу инфраструктуру.

  • DNS не будет работать, если Вы не сохраните свой тайм-аут домена DNS МАЛЕНЬКИМ (диапазон секунд), который является fronws на. ЕСЛИ можно сделать это, Вы могли бы написать сценарий его правильно (сценарий на сервере 2 не может достигнуть сервера 1, таким образом изменяет записи DNS). Это в значительной степени - единственный способ сделать это.

  • В зависимости от того, как Ваша установка DNS, это было бы или там, ИЛИ - регистрация записи хоста с помощью чего-то как dyndns.org и заменило бы Ваш В записи с CNAME. DynDNS.org имеет хороший API, который Вы могли назвать через HTTP для изменения записи, и CNAME никогда не будет изменяться. Они также сохраняют свои домены на коротком TTL.

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

0
ответ дан 3 December 2019 в 11:13
  • 1
    Время обновления DNS не имеет никакого отношения к обработке отказа - в лучшем случае Вы не можете получить эффективный TTL меньше чем 3 часов невнимательный wht, Вы вставляете свои файлы конфигурации. –   20 April 2010 в 14:59
  • 2
    Загаженный ответ. Во-первых, DynDNS дает мне эффективно приблизительно 10 секунд TTL. Плохие новости - это возможно. Во-вторых, не уничтожая DNS Вы не можете перенаправить.... домен. И любое основанное на IP перенаправление требует большего количества инфраструктуры как надлежащий маршрутизатор фронтэнда. –  TomTom 20 April 2010 в 15:44

Теги

Похожие вопросы