Позволю не согласиться с первым Вашим утверждением. Есть опыт работы (BGP взаимодействие) с крупными и средними провайдерами. Под словом провайдер я понимаю не домосеть с BGP и 2 x /24. Так вот ни один из них не осуществляет такую процедуру, незачем. Во-первых параметр не транзитивный, а значит дальше AS провайдера не уйдет, во-вторых, суровый метод с припендом не всегда оказывается эффективен из-за того что на входящий трафик и так сложнее влиять (и поведение часто определяется вашим соседом), ну и при выборе пути до AS-PATH еще нужно дойти.
Куда более элегантное и красивое решение — использование community. У хотя бы немного нормального провайдера присутствует политика и Вы точно можете определить что от него получаете, и что можете ему послать для влияния на те или иные процессы выбора маршрута. В конкретном случае, засылаете ему некое комьюнити говорящее установить для префиксов полученных по backup каналу lpref=50 (например), при lpref default = 100 (например).
Касательно производительности. Мы производили тестирование под конкретные свои приложения. Получили приблизительно следующее: при чтении информации — производительность аналогична отдельно стоящему mysql серверу (это производительность одной ноды, а учитывая то, что запросы балансируются между тремя серверами, между сказать что деньги и силы потрачены не только на повышенную доступность, но и производительность), при записи информации — падение производительность в 5-7 раз. Да, с одной стороны падение существенное, но мы понимаем на что идем и чего стоит синхронная репликация. А учитывая соотношение чтение/запись как 95/5 — для себя считаем приемлемым результатом.
Может ли сломаться репликация? В принципе может, в продакшене такого не было, но лабораторных условиях когда мы «насиловали» кластер — такое получалось. Если это и происходило, то совсем не там где мы ожидали. В частности, есть базовые методы трансфера: rsync и xtrabackup. Соответственно первый — блокирующий базу на запись, второй нет. Интересно то, что с rsync проблем не было, если на что-то и натыкались, то с xtrabackup. И что еще интереснее, отпад ноды происходил не во время нагрузочных или иных тестов, а чаще в режиме штатной работы. Пусть это и не научно, но проблема бывало как появлялась так и пропадала (при том что куча аналогичных примеров есть у других пользователей и рекомендуемые меры не очень уж и помогали). Где-то делаем ссылку на сыроватость под конкретную платформу, потому как проблемы с xtrabackup чаще всего встречаются у людей с Debian 6 x64. Повторюсь, что все касалось только xtrabackup.
Отмечу также немного слабоватый официальный форум, а-ля покупайте фирменный суппорт.
место общения community — google группы, а там 90% шлака.
По крайней мере для себя многое что отловили, проверили, получили некую базу знаний и сценарии действия в тех или иных ситуациях. На последок скажу, репликация синхронная, но если на уровне приложения Вы можете реализовать балансировку чтение/запись — делайте, это Вам +1 к крепкому сну.
Хороший вариант. Добавлю только то, что особо колдовать с DNS смысла нет. Современные браузеры автоматически распознают не работающий сервис и переключаются на другой IP адрес.
Не готов сказать как можно это подкрутить с помощью apache, но при использовании nginx есть замечательная директива try_files. С ней эта проблема снимается и как следствие, можно делать контрольную синхронизацию медиа контента реже (например раз в несколько часов), потому как сервера сами себя «отсинхронизируют» (происходит не запрос не существующего фала и его локальное сохранение).
Такой вопрос. Медиа контент между сайтами синхронизируется раз в 5 минут. Получается что если добавляется новый материал, но на протяжении 5 минут есть вероятность получить 404 при попадании на другой сервер.
Держать MySQL и HTTP сервера на одной железке это очень большая нагрузка на диск (ну если конечно сервис не посещает полтора землекопа в сутки). И это печалька
Это как-то не о чем. Mysql, http сервера и диски бывают очень разными. Также как и сами движки сайтов…
В продолжение комментария. Касательно, например, mysql. Порт может и прослушивать, но репликация может развалиться. И вам будет казаться что все хорошо, но давным давно не так радостно.
У себя на текущий момент используем Percona XtraDB Cluster. Там есть замечательная утилита clustercheck, которая проверяет не только доступность сервиса в принципе, но и, что самое главное, синхронизированность ноды.
Позволю себе добавить еще одну ссылочку на материал. Последние две картинки информативно показывают разницу между Centralized Forwarding и Distributed Forwarding.
если основным шлюзом у нас является ISP1, то веб-запросы из сети ISP2 приходят к нам на сервер и уходят через основной шлюз в сеть к ISP1, который это дело, понятное дело, блочит.
Я описал нормальную ситуацию среди нормальных провайдеров.
Если правильно понял, Вы хотите сказать, что если провайдер ISP1 выдал нам адрес 1.2.3.4 и получил на вход трафик с источником 5.6.7.8, то такой трафик будет заблокирован? Если так, то это ситуация с домопровайдерами, а не нормальными провайдерами.
3. Представьте ситуацию. Клиент (IP 20.20.20.20) отправляет запрос на сервер и, допустим, приходит через ISP1. Сервер обрабатывает запрос и отправляет ответ на 20.20.20.20. Этот пакет получает маршрутизатор. Какому провайдеру будет отправлен пакет и почему? А потом клиент 30.30.30.30 также запрашивает информацию у сервера, но приходит через ISP2. Сервер отправляет ответ на 30.30.30.30. Как этот пакет обрабатывает маршрутизатор (какому провайдеру будет отправлен и почему)?
Сам по себе haproxy распарсивать запросы чтение/запись не умеет. У Вас приложение умеет обращаться на чтение/запись к разным серверам, или Вы вносили изменения в код и для указывали разные сервера для разных запросов.
Уважаемый автор, хотел бы обратиться к Вам с просьбой проверки материала перед публикацией.
1.
На шлюзе поднят source NAT, который отдает страничку обоим внешним интерфейсам.
я уже не говорю, что NAT вероятно либо statis, либо destination. Во-вторых «отдает страничку обоим внешним интерфейсам» — вообще не понятно.
2.
если основным шлюзом у нас является ISP1, то веб-запросы из сети ISP2 приходят к нам на сервер и уходят через основной шлюз в сеть к ISP1, который это дело, понятное дело, блочит.
С чего бы? Другое дело пользователь сервиса, он отправлял запрос на адрес 1.2.3.4, а получил ответ от 5.6.7.8. Не все приложения нормально это переваривают.
3. И самое главное. Трафик возвращается от сервера к клиенту, на основании чего маршрутизатор должен или сделает вывод об обработке пакета той или иной таблицей маршрутизации?
А что на выходе получается? Может скрин какой?
Я так понимаю результат напоминает а-ля nagiostats?
Не скажу что Ganglia незаслуженно обделена вниманием. Она разрабатывалась немного для других задач. А нормальную реализацию видел в Вычислительном центре КПИ (http://grid.kpi.ua/index.php/ru/national-resource-centre/10-centr-superkompyuternih-obchislen.html), там она мониторит GRID систему.
Куда более элегантное и красивое решение — использование community. У хотя бы немного нормального провайдера присутствует политика и Вы точно можете определить что от него получаете, и что можете ему послать для влияния на те или иные процессы выбора маршрута. В конкретном случае, засылаете ему некое комьюнити говорящее установить для префиксов полученных по backup каналу lpref=50 (например), при lpref default = 100 (например).
Касательно производительности. Мы производили тестирование под конкретные свои приложения. Получили приблизительно следующее: при чтении информации — производительность аналогична отдельно стоящему mysql серверу (это производительность одной ноды, а учитывая то, что запросы балансируются между тремя серверами, между сказать что деньги и силы потрачены не только на повышенную доступность, но и производительность), при записи информации — падение производительность в 5-7 раз. Да, с одной стороны падение существенное, но мы понимаем на что идем и чего стоит синхронная репликация. А учитывая соотношение чтение/запись как 95/5 — для себя считаем приемлемым результатом.
Может ли сломаться репликация? В принципе может, в продакшене такого не было, но лабораторных условиях когда мы «насиловали» кластер — такое получалось. Если это и происходило, то совсем не там где мы ожидали. В частности, есть базовые методы трансфера: rsync и xtrabackup. Соответственно первый — блокирующий базу на запись, второй нет. Интересно то, что с rsync проблем не было, если на что-то и натыкались, то с xtrabackup. И что еще интереснее, отпад ноды происходил не во время нагрузочных или иных тестов, а чаще в режиме штатной работы. Пусть это и не научно, но проблема бывало как появлялась так и пропадала (при том что куча аналогичных примеров есть у других пользователей и рекомендуемые меры не очень уж и помогали). Где-то делаем ссылку на сыроватость под конкретную платформу, потому как проблемы с xtrabackup чаще всего встречаются у людей с Debian 6 x64. Повторюсь, что все касалось только xtrabackup.
Отмечу также немного слабоватый официальный форум, а-ля покупайте фирменный суппорт.
место общения community — google группы, а там 90% шлака.
По крайней мере для себя многое что отловили, проверили, получили некую базу знаний и сценарии действия в тех или иных ситуациях. На последок скажу, репликация синхронная, но если на уровне приложения Вы можете реализовать балансировку чтение/запись — делайте, это Вам +1 к крепкому сну.
Это как-то не о чем. Mysql, http сервера и диски бывают очень разными. Также как и сами движки сайтов…
У себя на текущий момент используем Percona XtraDB Cluster. Там есть замечательная утилита clustercheck, которая проверяет не только доступность сервиса в принципе, но и, что самое главное, синхронизированность ноды.
www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html
Если правильно понял, Вы хотите сказать, что если провайдер ISP1 выдал нам адрес 1.2.3.4 и получил на вход трафик с источником 5.6.7.8, то такой трафик будет заблокирован? Если так, то это ситуация с домопровайдерами, а не нормальными провайдерами.
3. Представьте ситуацию. Клиент (IP 20.20.20.20) отправляет запрос на сервер и, допустим, приходит через ISP1. Сервер обрабатывает запрос и отправляет ответ на 20.20.20.20. Этот пакет получает маршрутизатор. Какому провайдеру будет отправлен пакет и почему? А потом клиент 30.30.30.30 также запрашивает информацию у сервера, но приходит через ISP2. Сервер отправляет ответ на 30.30.30.30. Как этот пакет обрабатывает маршрутизатор (какому провайдеру будет отправлен и почему)?
1.
я уже не говорю, что NAT вероятно либо statis, либо destination. Во-вторых «отдает страничку обоим внешним интерфейсам» — вообще не понятно.
2.
С чего бы? Другое дело пользователь сервиса, он отправлял запрос на адрес 1.2.3.4, а получил ответ от 5.6.7.8. Не все приложения нормально это переваривают.
3. И самое главное. Трафик возвращается от сервера к клиенту, на основании чего маршрутизатор должен или сделает вывод об обработке пакета той или иной таблицей маршрутизации?
Я так понимаю результат напоминает а-ля nagiostats?
Не скажу что Ganglia незаслуженно обделена вниманием. Она разрабатывалась немного для других задач. А нормальную реализацию видел в Вычислительном центре КПИ (http://grid.kpi.ua/index.php/ru/national-resource-centre/10-centr-superkompyuternih-obchislen.html), там она мониторит GRID систему.