https://ns.opennet.dev/openforum/vsluhforumID1/94338.html Всем доброго времени суток!<br>Прошу совета по следующей проблеме:<br>Требуется организовать серверную структуру с высокой доступностью веб-приложения.<br>Как я себе это вижу: <br>1. Размещаем 2 разных сервера в 2-х ЦОДах.<br>2. Каким-то образом надо решить проблему с одним виртуальным IP, чтобы в случае падения одного сервера все запросы обрабатывал второй сервер. (в инете нашел статью с wackamole и apache+mod_backhand, но она уже старая)<br>3. На серверах находятся базы MySQL - решить проблему синхронизации планирую через MySQL репликацию Master-Master.<br><br>По поводу второй проблемы - можно использовать DNS RoundRobin и Nginx в качестве балансировщика, но что будет, если ДНС запрос закешировался и пакеты будут идти на сдохший сервер?<br> https://ns.opennet.dev/openforum/vsluhforumID1/94338.html#21 Wed, 06 Mar 2013 05:54:41 GMT &gt; с ДНС вроде понятно.<br>&gt; Теперь встала проблема о синхронизации файлов.<br>&gt; Как организовать синхронизацию файлов?<br>&gt; чтобы файлы синхронизовались и с основного и с вспомогательного сервера.<br>&gt; Что-то типа Мастер-Мастер...<br><br>csync2<br> https://ns.opennet.dev/openforum/vsluhforumID1/94338.html#20 Fri, 01 Mar 2013 15:17:49 GMT &gt;&gt; Где тут важная роль растущего serial ? мое имхо говорит мне, что <br>&gt;&gt; клиенту на это значение глубоко пофиг.<br>&gt;&gt; Разве не так?<br>&gt;&gt; //клиент - ресольвер, кеширующий DNS и т п.<br>&gt; По истечении refresh клиент обязан проверить serial зоны. Если serial совпадает, можно <br>&gt; расслабиться - сервер сказал, что зона не менялась.<br>&gt; Клиент зону может и скачал, но ничего делать не обязан.<br><br>Может ошибаюсь, но где-то читал, что ie вообще пофиг на ttl и он будет долбиться в старый адрес часов 12. У него свой кеш и свой ttl)<br> https://ns.opennet.dev/openforum/vsluhforumID1/94338.html#19 Thu, 28 Feb 2013 03:22:14 GMT с ДНС вроде понятно.<br>Теперь встала проблема о синхронизации файлов.<br>Как организовать синхронизацию файлов?<br>чтобы файлы синхронизовались и с основного и с вспомогательного сервера.<br>Что-то типа Мастер-Мастер...<br><br><br> https://ns.opennet.dev/openforum/vsluhforumID1/94338.html#18 Sat, 16 Feb 2013 06:08:50 GMT &gt;[оверквотинг удален]<br>&gt;&gt;&gt; расслабиться - сервер сказал, что зона не менялась.<br>&gt; [...] <br>&gt;&gt; происходит и для положительных записей, ткните, пожалуйста в RFC, либо как-то еще <br>&gt;&gt; приведите доказательство (с указанием наименований и версий софта), что это где-то <br>&gt;&gt; происходит именно так, как указано вами.<br>&gt;&gt; А пока я считаю, что клиенту пофиг на serial в положительных ответах.<br>&gt; Внимательно прочитай раздел 4.3.5. RFC1034. Более поздние навороты над ним же - <br>&gt; #3.11 RFC1996, #8.2. RFC4033 и проч. немного запутывают картинку подписями и <br>&gt; уведомлениями, оставляя исходную идею без изменений.<br>&gt; Попробуй написать распределённый кэш чего угодно, догадаешься до такого алгоритма сам. <br><br>Всё что написано в 4.3.5 относится к слейв-серверам, поддерживающим зону. К клиентам и клиентским кэшам, обращающимся за данными зоны, это никакого отношения не имеет.<br><br>Такое поведение, что запись в _кеше_ считается валидной, если serial не изменился, специфицировано только для negative cache, да и то optional - не обязат https://ns.opennet.dev/openforum/vsluhforumID1/94338.html#17 Fri, 15 Feb 2013 20:11:25 GMT &gt;&gt;&gt; Где тут важная роль растущего serial ? мое имхо говорит мне, что <br>&gt;&gt;&gt; клиенту на это значение глубоко пофиг.<br><br>[...]<br>&gt;&gt; По истечении refresh клиент обязан проверить serial зоны. Если serial совпадает, можно <br>&gt;&gt; расслабиться - сервер сказал, что зона не менялась.<br><br>[...]<br>&gt; происходит и для положительных записей, ткните, пожалуйста в RFC, либо как-то еще <br>&gt; приведите доказательство (с указанием наименований и версий софта), что это где-то <br>&gt; происходит именно так, как указано вами.<br>&gt; А пока я считаю, что клиенту пофиг на serial в положительных ответах. <br><br>Внимательно прочитай раздел 4.3.5. RFC1034. Более поздние навороты над ним же - #3.11 RFC1996, #8.2. RFC4033 и проч. немного запутывают картинку подписями и уведомлениями, оставляя исходную идею без изменений.<br><br>Попробуй написать распределённый кэш чего угодно, догадаешься до такого алгоритма сам.<br> https://ns.opennet.dev/openforum/vsluhforumID1/94338.html#16 Fri, 08 Feb 2013 18:18:05 GMT &gt;&gt; Где тут важная роль растущего serial ? мое имхо говорит мне, что <br>&gt;&gt; клиенту на это значение глубоко пофиг.<br>&gt;&gt; Разве не так?<br>&gt;&gt; //клиент - ресольвер, кеширующий DNS и т п.<br>&gt; По истечении refresh клиент обязан проверить serial зоны. Если serial совпадает, можно <br>&gt; расслабиться - сервер сказал, что зона не менялась.<br><br>Описанное вами будет происходить только при истечении TTL негативного ответа, да и то, является штукой не обязательной, кто как реализовал - это еще надо посмотреть.<br><br>Собственно это кеширование негативного ответа не является предметом дискуссии, а при кешировании положительного ответа, насколько я осведомлен, эта процедура (проверка serial зоны по истечению TTL записи) - не стандартизирована и не применяется. <br><br>Всё это также подтверждается парой запусков dig. Для негативных ответов (для отсутствующих записей по запросу) dig показывает, что сервер отправляет SOA (для поддерживающих фичу клиентов), для положительных ответов SOA не отправляется. <br><br>Если вы уверены, что указанное вами явл https://ns.opennet.dev/openforum/vsluhforumID1/94338.html#15 Fri, 08 Feb 2013 13:17:37 GMT &gt; Где тут важная роль растущего serial ? мое имхо говорит мне, что <br>&gt; клиенту на это значение глубоко пофиг.<br>&gt; Разве не так?<br>&gt; //клиент - ресольвер, кеширующий DNS и т п.<br><br>По истечении refresh клиент обязан проверить serial зоны. Если serial совпадает, можно расслабиться - сервер сказал, что зона не менялась.<br><br>Клиент зону может и скачал, но ничего делать не обязан.<br> https://ns.opennet.dev/openforum/vsluhforumID1/94338.html#14 Thu, 07 Feb 2013 08:54:51 GMT &gt;[оверквотинг удален]<br>&gt;&gt;&gt; будет из одной сетки ?<br>&gt;&gt;&gt; тогда можено heartbeat <br>&gt;&gt;&gt; можно так же сделать <br>&gt;&gt;&gt; 1 сервер nginx -&gt; который использует как upstream IP1-server, IP2-server, DNS смотри <br>&gt;&gt;&gt; на IP-nginx <br>&gt;&gt; ложится сеть в ДЦ и превед, только не надо говорить, что это <br>&gt;&gt; маловероятно :D <br>&gt; ну тоже вероятность есть.. так же как и вероятность того, что ляжет <br>&gt; сеть и там и там или ДЦ ляжет и там и <br>&gt; там <br><br>100% дают сами знаете где :D<br><br>Даже хваленный Rackspace со своими 100% uptime садился пару раз в лужу ;)<br> https://ns.opennet.dev/openforum/vsluhforumID1/94338.html#13 Thu, 07 Feb 2013 05:45:18 GMT &gt;&gt; почему бы два сервера не держать в одном ДЦ и еще IP <br>&gt;&gt; будет из одной сетки ?<br>&gt;&gt; тогда можено heartbeat <br>&gt;&gt; можно так же сделать <br>&gt;&gt; 1 сервер nginx -&gt; который использует как upstream IP1-server, IP2-server, DNS смотри <br>&gt;&gt; на IP-nginx <br>&gt; ложится сеть в ДЦ и превед, только не надо говорить, что это <br>&gt; маловероятно :D <br><br>ну тоже вероятность есть.. так же как и вероятность того, что ляжет сеть и там и там или ДЦ ляжет и там и там<br>