Приветствую,У меня стоят 2 сервера в территориально разных датацентрах. На обоих идентично настроены веб серверы и между ними синхронизируются все сайты в реальном времени. Серверы работают в режиме МАСТЕР-СЛЕЙВ, то есть один из них постоянно работает, на активном сервере поднят Apache. Второй СЛЕЙВ стоит с выключенным сервисом Apache и просто синхронизирует у себя данные сайтов на диске. В ДНС у меня для сайта прописано 2 A записи:
www.website.com A 1.1.1.1
www.website.com A 1.1.1.2Все бы ничего, браузер всегда открывает с того сервера на котором работает apache и сайт открывается без проблем. Но у некоторых пользователей эта схема не работает. На компе, на котором не работает такая схема DNS резолвит 2 ip адреса, как пологается, но опрос веб браузером идет не по всем ip адресам чтоли, и, если браузер нарывается на сервер с выключенным Apache, то он просто говорит что сервер недоступен.
В чем может быть дело? Никто не сталкивался?
Я пересмотрел все возможные варианты, и, как я понял это проблема на стороне клиента. Но в чем проблема и как ее решить не нашел.
Может я не правильно вообще реализовал схему? Хотя посмотреть и гугл и майкрософт, да и вообще все крупные сайты имеют по несколько А записей с балансерами. У меня просто все работает без балансера, он мне не нужен. Мне нужно только 2 взаимозаменямых сервера и все.
P.S. Пробовали открывать во всех браузерах. В основном проблема возникает на машинах с уже давно установленной Windows XP.
проблема не на стороне клиента, а у Вас в /dev/head>www.website.com A 1.1.1.1
>www.website.com A 1.1.1.2в таком случае, все нормально настроенные DNS адрес будут выдавать попеременно.
средствами ДНС такого сделать практически невозможно.
>проблема не на стороне клиента, а у Вас в /dev/head
>
>>www.website.com A 1.1.1.1
>>www.website.com A 1.1.1.2
>
>в таком случае, все нормально настроенные DNS адрес будут выдавать попеременно.
>
>средствами ДНС такого сделать практически невозможно.Да нет. С /dev/head у меня все в порядке. Даже пусть дают попеременно. В 98% случаев все работает нормально, так как происходит следующая картина:
1. Клиент открывает браузер и вбивает в него адрес www.website.com
2. Браузер делает ДНС запрос для адреса и получает ip адрес для него. В моем случае их 2.
3. В каком бы порядке не были получены ip адреса, браузер начинает обращаться, к примеру на 80 порт, на 1 ip адрес. Если ответ получен. то сайт соотв. открывается с этого сервера. Если ответ не получен, то браузер уже делает запрос по 2 ip адресу. То есть открывает сайт с того адреса, с которого получен ответ.Но вот также есть 2% случаев, когда этого браузер не делает. Я немогу понять почему и поэтому написал на форуме.
учите матчасть... браузер такого не делает, браузер вообще по адресам не обращается, чисто по урлу, иначе имели б мы виртуальные хосты :)
идет днс-запрос, потом идет обращение на полученный адрес, адрес , при наличие нескольких записей A, выдается попеременно.
В вашем конкретном случае, получается, что половина пользователей на Ваш сайт попасть не может.
и не надо говорить "да, нет", не понимая как всё работает.спросите у своего NS-сервера
dig A @your_NS your.site.hostnameнесколько раз подрят, и вы убедитесь в моей правоте.
У Вас розовые очки на глазах, вероятнее всего потому, что сами довольно часто заходите на сайт и получаете данные из кеша.
>[оверквотинг удален]
>не может.
>и не надо говорить "да, нет", не понимая как всё работает.
>
>спросите у своего NS-сервера
>dig A @your_NS your.site.hostname
>
>несколько раз подрят, и вы убедитесь в моей правоте.
>
>У Вас розовые очки на глазах, вероятнее всего потому, что сами довольно
>часто заходите на сайт и получаете данные из кеша.Значит получается моя схема не правильна? Браузер не работает к примеру как почтовики с несколькими MX записями или DNS сервера с несколькими NS серверами. Хорошо, как же тогда к примеру у многих крупных сайтов реализована такая схема, где явно видно по несолько А записей на один сайт?
Именно так, "Ваша схема" не работает, да и не должна работать.
у каждого по разному реализовано.
куча разных вариантов, например: geo+view в DNS - это самое простое что пришло в голову.
>Именно так, "Ваша схема" не работает, да и не должна работать.
>у каждого по разному реализовано.
>куча разных вариантов, например: geo+view в DNS - это самое простое что
>пришло в голову.Хорошо. Отсюда возникают вопросы.
- Зачем те же самые крупные сайты прописывают по несколько А записей?
- Не знаете ли каких либо вариантов, как тогда правильней реализовать схему "1 вебсайт на 2х независымых серверах с синхронизацией", без каких либо мастер или nginx серверов?
нет такой схемы, без дополнительного ПО.ну разве что, если оба работают и синхронизация почти моментальная.
ну или, как я указал выше geo+view в DNS.
>нет такой схемы, без дополнительного ПО.
>
>ну разве что, если оба работают и синхронизация почти моментальная.
>
>ну или, как я указал выше geo+view в DNS.Синхронизация у меня моментальная, реализовано на DRBD (Primary-Secondary), переключается все за считанные секунды. Вот только есть вот эта проблема с ДНС. Как сделать, чтобы клиент попадал на нужный сервер. Вот и ищу решение.
так если drbd и на нем сам сайт с базой хранится, зачем вы тогда вообще на втором серваке отключаете апачь? пусть работают оба.
>так если drbd и на нем сам сайт с базой хранится, зачем
>вы тогда вообще на втором серваке отключаете апачь? пусть работают оба.
>Потому, что DRBD работает в режиме Primary-Secondary и данные доступны только на Primary. Я пробовал реализовать схему с двумя Primary+GFS, все на столько глючно и опасно, что лучше этого не делать. Потом помимо БД и самих сайтов, на DRBD также хранятся конфиги апача, которые при монтировании линкуются в нужные места и при запуске апач их читает. Это сделано что бы не гемороиться с репликацией именно конфигов. Тем более режим Pri-Sec.
вообщето, при drbd+ha нодам можно назначить разные адреса, а общий один, вот тогда "ваша схема" работать будет. соответственно в DNS указан будет общий адрес, который переходит на secondary ноду, в случае падения/сгорания/отключения primary.
>вообщето, при drbd+ha нодам можно назначить разные адреса, а общий один, вот
>тогда "ваша схема" работать будет. соответственно в DNS указан будет общий
>адрес, который переходит на secondary ноду, в случае падения/сгорания/отключения primary.У меня серверы находятся на Collocation в рахных городах. Как я смогу настроить общий ip адрес? Это нужно просить провайдера переделывать роутинг для этого ip адреса? На такое провайдер просто не пойдет.
ну тогда Вы изначально неправильно подошли к вопросу.
Надо было изначально обозначить схему и варианты, а не прикручивать их потом.
Да и знать надо, в таких случаях, хотяб элементарные вещи.
Я почему то был уверен что браузер будет нормально работать с несколькими A записями. Даже кажется тестировал. А теперь нарвался на проблему. Сейчас пока буду рассматривать варианты с Dynamic DNS или что то типа того.
>Я почему то был уверен что браузер будет нормально работать с несколькими
>A записями. Даже кажется тестировал. А теперь нарвался на проблему. Сейчас
>пока буду рассматривать варианты с Dynamic DNS или что то типа
>того.C DDNS нарветесь на пользовательские DNS-кэши, и криво настроенные кэширующие DNS, игнорирующие ttl
Можно бюджетно сделать в одном ДЦ, но в разных стойках (весь ДЦ выключается реже, чем ДЦ-ки сдуру перезагружают всю стойку) средствами, например, RedHat Cluster Suite или heartbeat.
Если у Вас Debian/Ubuntu, под первый есть собранные пакеты с RHCS, в отличае от heartbeat в RHCS нет проблемы brainsplit. В документации drbd есть статья про интеграцию с RHCS
У меня к Вам вопрос: скажите честно, как у Вас с производительностью drbd, при репликации в другой ДЦ (у нас он и по гигабитному кроссу, и даже баунду из кроссов тормозил)?
Просто тоже думаем о реализации чего-то подобного :)
У меня стоит CentOS 5.x. Пробовал и Heartbeat и RHCS. Все это на столько глючные поделия, что я все делаю сам, свои скрипты для heartbeat написал.А DRBD по умолчанию тормазит и будет тормазить пока сами не укажите ему в конфиге на какой скорости работать, смотрите параметр SYNCER:
- syncer { rate 4M; } - это к примеру для 100 мегабитного соединения.При правильной настройке ничего тормазить не будет. У меня нет с этим проблем и все отлично синхронизируется.
Да уж, проблема серьезная. Теперь нужно искать какое-то решение с ДНС. Странно, почему браузеры не работают с несколькими А записями как почтовики с MX'ами или DNS сервера с NS'ами, вроде это не сложно реализуется. Я еще посмотрел в DNS есть записи SRV, но кажется это всего лишь информационные поля, надо полазать, почитать про них.
>Я еще посмотрел в DNS есть записи SRV, но кажется это
>всего лишь информационные поля, надо полазать, почитать про них.Эти поля, в данном случае не помогут.
один из примеров использования: gtalk своего домена для интеграции в общюю jabber структуры.
>У меня стоит CentOS 5.x. Пробовал и Heartbeat и RHCS. Все это
>на столько глючные поделия, что я все делаю сам, свои скрипты
>для heartbeat написал.У HeartBeat есть проблема с brainsplit. Насчет глючности, как-то Вы громко это написали, у нас на стенде все работает хорошо :)
ага, на стенде ;)
я пока в реальности не испытал все это, тоже думал отличная штука
>ага, на стенде ;)
>я пока в реальности не испытал все это, тоже думал отличная штукаА какого рода были проблемы? Вы писали баги в багзиллу? Может быть, Вы все-таки что-то делали не так?
Это тема думаю немного другая. По ней много можно писать. Я ее не касаюсь уже. Просто решил сделать по своему, без вышеупомянутых средств.
>>У меня стоит CentOS 5.x. Пробовал и Heartbeat и RHCS. Все это
>>на столько глючные поделия, что я все делаю сам, свои скрипты
>>для heartbeat написал.
>
>У HeartBeat есть проблема с brainsplit. Насчет глючности, как-то Вы громко это
>написали, у нас на стенде все работает хорошо :)
>А DRBD по умолчанию тормазит и будет тормазить пока сами не укажите ему в конфиге на >какой скорости работать, смотрите параметр SYNCER:
>- syncer { rate 4M; } - это к примеру для 100 мегабитного соединения.Я меняла, и не только это, не помогает. У системы огромный iowait :(
Но подозреваю, что что-то делаю не так.
>У HeartBeat есть проблема с brainsplit. Насчет глючности, как-то Вы громко это
>написали, у нас на стенде все работает хорошо :)Дык у меня в продакшене работает связка drbd+ha больше года, координация нод по COM-порту. Нареканий нет.
>>У HeartBeat есть проблема с brainsplit. Насчет глючности, как-то Вы громко это
>>написали, у нас на стенде все работает хорошо :)
>
>Дык у меня в продакшене работает связка drbd+ha больше года, координация нод
>по COM-порту. Нареканий нет.Нет, просто сама идея двух нод она ущербна. Вот с наличием третьей, с кворумным диском, проблема решается на корню
>>У HeartBeat есть проблема с brainsplit. Насчет глючности, как-то Вы громко это
>>написали, у нас на стенде все работает хорошо :)
>
>Дык у меня в продакшене работает связка drbd+ha больше года, координация нод
>по COM-порту. Нареканий нет.А какая у Вас дисковая? Если честно, у нас сейчас с бюджетом очень туго, так как своя маленькая фирма и едим мы сейчас только макароны, и я тестила на сервере с ipmi, PC-ке, и виртуалке(под кворум), без умных UPS-ов.
Естественно, смоделировать паделение можно только сервера(с прибитием ноды через IPMI). Да и дисковая тоже из soft-зеркала на SATA, и чудес производительности от связки заранее не ожидала, но и не ожидала, что все будет настолько плохо :(
hardware 1+0 4х146G 2.5sas
>hardware 1+0 4х146G 2.5sasА можно глянуть iostat -x, vmstat при типовой нагрузке, и когда слегка возрастает?
И что у Вас за сеть? Вы карточки какие используете? И что больше всего не хватает, диска?
--------
avg-cpu: %user %nice %system %iowait %steal %idle
4,66 0,01 0,05 0,07 0,00 95,20Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
cciss/c0d0 0,04 8,57 0,48 4,24 10,69 103,73 24,24 0,01 1,30 0,40 0,19
drbd1 0,00 0,00 0,47 3,99 6,68 32,34 8,76 0,79 178,12 1,92 0,86
--------
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 140036 288716 7320752 0 0 1 6 0 1 5 0 95 0 0
--------
основная загрузка часа через 4 начнется, но не сильно прыгает.
--------
С диском как-раз проблем нет.
Вы имеете ввиду Net-карты? - Intel - 1G
--------
а что значит "какая у Вас сеть" - этот вопрос не понял. конкретнее спросите.
>[оверквотинг удален]
>0 1 5 0 95
>0 0
>--------
>основная загрузка часа через 4 начнется, но не сильно прыгает.
>--------
>С диском как-раз проблем нет.
>Вы имеете ввиду Net-карты? - Intel - 1G
>--------
>а что значит "какая у Вас сеть" - этот вопрос не понял.
>конкретнее спросите.Ясно, спасибо. Я, наверное, просто еще почитаю доки по drbd, и переделаю стенд на нормальном железе, когда оно (надеюсь) появится
У меня обычные PC сервера, с RAID1 используя RAID карточку на SATA дисках. В Датацентре предусмотрены системы питания и т.п.
>У меня обычные PC сервера, с RAID1 используя RAID карточку на SATA
>дисках. В Датацентре предусмотрены системы питания и т.п.Тогда дико интересно, что же я делаю не так :) так как у меня по гигабитному порту софт-зеркало (которое, вообще-то быстрее, чем большинство аппаратных контроллеров до $1000, если md замапить на одно ядро) пользоваться этим было нельзя
У меня все вообще на встроенных 100 мегабитных карточках работает без каких либо задержек :). Это учитывая то, что датацентры в разных городах. Сеть между ними правда многодесяти гигабитная...
>У меня все вообще на встроенных 100 мегабитных карточках работает без каких
>либо задержек :). Это учитывая то, что датацентры в разных городах.
>Сеть между ними правда многодесяти гигабитная...Знакомые тоже отказались от drbd из-за тормозов, но у них кривая база MySQL, которую нельзя переделывать, и там очень интенсивный ввод-вывод, так как куча бинарей в БД (у них был какой-то adaptec в 10-ом рейде с SAS 15k на супермикровской платформе)
>Знакомые тоже отказались от drbd из-за тормозов, но у них кривая база
>MySQL, которую нельзя переделывать, и там очень интенсивный ввод-вывод (у них
>был какой-то adaptec в 10-ом рейде с SAS 15k на супермикровской
>платформе)"
Вероятнее всего, ключевым здесь является "кривая база MySQL".
У меня Cache там вертится. ну и не кривая, это точно.
Значит я выбрал следующий метод/схему именно для моих нужд и моей системы.1. На каждом сервере будет поднят DNS сервис.
2. В каждом DNS сервисе будут прописаны те ip адреса, которые обслуживают сервисы типа Apache, почта и т.п. именно на нем.
3. Всегда будет (поднят) работать только один DNS сервер, именно на том сервере, на котором в данный момент работает все остальное - Apache, почта и т.п.Получится что у меня будут NS1 на одном сервере и NS2 на другом. У регистратора я пропишу оба этих сервера. Отвечать всегда будет активный сервер, само собой отдавая нужные ip адреса, которые в данный момент обслуживают все сервисы.
>[оверквотинг удален]
>2. В каждом DNS сервисе будут прописаны те ip адреса, которые обслуживают
>сервисы типа Apache, почта и т.п. именно на нем.
>3. Всегда будет (поднят) работать только один DNS сервер, именно на том
>сервере, на котором в данный момент работает все остальное - Apache,
>почта и т.п.
>
>Получится что у меня будут NS1 на одном сервере и NS2 на
>другом. У регистратора я пропишу оба этих сервера. Отвечать всегда будет
>активный сервер, само собой отдавая нужные ip адреса, которые в данный
>момент обслуживают все сервисы.Что делать с кривыми резолверами собираетесь?
Думаю, что даже кривые резолверы сделав запрос на NS1 и не получив ответа полезут на NS2, где соотв. получат ответ.
>Думаю, что даже кривые резолверы сделав запрос на NS1 и не получив
>ответа полезут на NS2, где соотв. получат ответ.Не знаю как щас но раньше agnitum outpost с включенным по умолчанию dns-модулем, вообще игнорировал ttl днс-записей, и кешировал ответы - два раза по дохрена времени
интересно, какой TTL Вы пропишите в записях на DNS?А то ведь, DNS кеш никто не отменял.
TTL поставлю обычный 1 час или пол часа, но TTL тут не играет роли. У регистратора прописано 2 NS сервера.Каждый NS содержит разные A записи.
К примеру:
NS1: www.website.com IN A 1.1.1.1
NS2: www.website.com IN A 1.1.1.2Соотв. на NS1 апач отвечает по адресу 1.1.1.1, а на NS2 на 1.1.1.2. Если к примеру NS1 в дауне (апач на нем тоже в дауне), запрос пойдет на NS2, откуда выдастся адрес 1.1.1.2 где и апач поднят на это адрес.
Молодой человек, вы опять полезли в дебри, в которых ничерта не поняли.если TTL 1 час, то запись кешируется на DNS-сервере клиента 1 час.
и не будет он никуда обращаться, пока TTL не истечет.
то есть, при плохом раскладе, только через час, после реального подключения, клиенты попадут на новый адрес.
Да, точно! Спасибо за подметку!
Сделаю TTL минут 10-15. думаю меньше 10 минут ставить не нужно. Ну а кривые резолверы, что с ними поделаешь - это уже их проблема, за всеми не усмотришь.
В вашем случае, я бы сделал от 120 до 300 сек, но только на A запись, ну и MX, если надо, остальное не трогать.
Или у Вас настолько популярный ресурс, что DNS запросами могут задолбать :) ?
Да не так чтобы особо прям. Посмотрим, поставлю, дальше будет видно по ситуации уже оттюню TTL.