Comments 34
Статья хорошая но заголовок, мне кажется, следует переработать
спасибо за статью, я последнего инвайта не пожалел, чтобы иметь возможность добавить ее в избранное. )
отличная статья
не очень понятно, зачем MySQL-proxy
проксирование обращений пользователей к базе данных
Вы написали перевод фразы «MySQL-proxy», но не пояснили, зачем нужен этот дополнительный слой в конфигурации, почему нельзя напрямую с сервера данные брать
Компонента распределяет запросы между серверами mysql, обеспечивая дополнительный уровень безопасности.
На самом деле вот именно по поводу этого слоя у меня самого возникает вопрос в его необходимости.
На самом деле вот именно по поводу этого слоя у меня самого возникает вопрос в его необходимости.
Во-первых, он может балансировать запросы — если у вас мастер-мастер, и оба сервера работают, то он может балансировать запросы для снижения нагрузки. если один сервер упадет, то он сам перенаправит все запросы на второй, иначе если вы соединяетесь в приложении по IP сервера БД, придется менять настройки и реконектится с новым адресом
имхо стоило описать немного про сам процесс смены ip адреса у пар серверов.
но в любом случае — я открыл кое-что новое.
но в любом случае — я открыл кое-что новое.
В этой схеме очень много железа, а толку мало.
1) MySQL и апач можно держать на одном физическом сервере. Дело в том, что mysql нагружает диски, а апач нагружает процессор и они довольно сносно уживаются на одном сервере. В результате мы на выделенном железе (6 серверов) запросто можем собрать 4 комплекса (mysql + apache — апач ходит только к своему mysqlю на том же физическом сервере) и настроить между ними репликацию.
2) Оставшиеся 2 сервера вынесем вверх принимать входящие запросы с настройкой между ними heartbeat. На серверах установим nginx в качестве балансера на 4 бекендных комплекса (mysql+апач).
3) В результате мы увеличили общую производительность в 2 раза на все тех же 6 серверах! :)
1) MySQL и апач можно держать на одном физическом сервере. Дело в том, что mysql нагружает диски, а апач нагружает процессор и они довольно сносно уживаются на одном сервере. В результате мы на выделенном железе (6 серверов) запросто можем собрать 4 комплекса (mysql + apache — апач ходит только к своему mysqlю на том же физическом сервере) и настроить между ними репликацию.
2) Оставшиеся 2 сервера вынесем вверх принимать входящие запросы с настройкой между ними heartbeat. На серверах установим nginx в качестве балансера на 4 бекендных комплекса (mysql+апач).
3) В результате мы увеличили общую производительность в 2 раза на все тех же 6 серверах! :)
Спасибо за вариант
>Дело в том, что mysql нагружает диски, а апач нагружает процессор и они довольно сносно уживаются на одном сервере.
Когда научитесь отдавать с Апача что-нибудь мелкофайловое с потоком мегабит этак в 300 — поймете, что апач тоже умеет некисло нагружать диск и в итоге оно заткнется (я знаю, что можно отдавать с nginx, но не всегда это возможно). Поэтому в случае HA проектов лучше таки разделить web & db сервера.
Когда научитесь отдавать с Апача что-нибудь мелкофайловое с потоком мегабит этак в 300 — поймете, что апач тоже умеет некисло нагружать диск и в итоге оно заткнется (я знаю, что можно отдавать с nginx, но не всегда это возможно). Поэтому в случае HA проектов лучше таки разделить web & db сервера.
Можно не разделять, достаточно бюджетного ssd смонтированного в /var/lib/mysql :)
К сожалению SSD долго не живут на высоконагруженных системах даже на раздаче картинок, даже смонтированные в RO режиме :(
Вы правы — апач может нагрузить диск, но в 2U сервер без проблем можно вставить 8 дисков. И можно сделать так, чтобы апач нагружал не те диски, которые нагружает база.
> Поэтому в случае HA проектов лучше таки разделить web & db сервера.
Все зависит от нюансов.
Но в большом количестве случаев необходимо минимизировать стоимость решения. И тогда начинаются пляски с бубном…
> Поэтому в случае HA проектов лучше таки разделить web & db сервера.
Все зависит от нюансов.
Но в большом количестве случаев необходимо минимизировать стоимость решения. И тогда начинаются пляски с бубном…
стоимость решения вы может и минимизируете, но мы же HA систему строим, не? Практика показала — на HA (и конечно это HighLoad, иначе зачем нам HA) выгоднее увеличить стоимость первоначального решения — ибо стоимость простоя и стоимость восстановления или масштабирования в будущем получится гораздо выше.
Мы пока остановились на примерно такой схеме для «небольших» проектов: balancer -> 2 nginx frontend -> 2+ apache backend + staging backend -> DB Master + DB Slave -> Backup. В этой схеме можно немного заэкономить и совместить балансинг и фронт в одной машине. Учитывая то, что все сервера одинаковой конфигурации — даже в случае поломки можно быстро переконфигурить любую машину фермы на выполнение другой роли. В нашей схеме правда есть еще storage controller — сервер(ы) держащие SAN-NAS-DAS стораджи и раздающие их на ферму.
Схема достаточно распростаненная, можно сказать стандартная даже. Есть конечно некоторые хитрости — например вынос тяжелых SQL работ не требующих записи в базу на slave (например поиск по форуму)
Мы пока остановились на примерно такой схеме для «небольших» проектов: balancer -> 2 nginx frontend -> 2+ apache backend + staging backend -> DB Master + DB Slave -> Backup. В этой схеме можно немного заэкономить и совместить балансинг и фронт в одной машине. Учитывая то, что все сервера одинаковой конфигурации — даже в случае поломки можно быстро переконфигурить любую машину фермы на выполнение другой роли. В нашей схеме правда есть еще storage controller — сервер(ы) держащие SAN-NAS-DAS стораджи и раздающие их на ферму.
Схема достаточно распростаненная, можно сказать стандартная даже. Есть конечно некоторые хитрости — например вынос тяжелых SQL работ не требующих записи в базу на slave (например поиск по форуму)
Все-таки какие плюсы и минусы предложенной мною схемы?
И, если можно, более подробно рассказать о предложенной вами схеме или дать соответствующие ссылки?
Сейчас мне необходимо принять решение о выборе схемы для продакшна.
И, если можно, более подробно рассказать о предложенной вами схеме или дать соответствующие ссылки?
Сейчас мне необходимо принять решение о выборе схемы для продакшна.
Минус-не-минус, но mysql proxy можн смело почикать, для минимизации затрат. Держать две машины под прокси — черезчур. Можно забалансить другими методами (да хоть Linux Virtual Machine, если хочется в приложении не париться доступом к разным ip).
Еще, с моей точки зрения, минус — локальные скрипты на каждом бекенде. В моем случае весь проект, включая скрипты, лежит на системе хранения, которая «расшарена» на все web-сервера (и фронт и бекэнды), соответственно одинаковые настройки апачей и nginx отдает всю статику сам, скрипты проксирует на апачи. Архитектура приложений разрабатывается таким образом, что никакие скрипты не могут писать в один и тот-же файл (логично! нафига нам геморой с локами, хотя это тоже решабельно). Ну и забываем о проблемах синхронизации заодно. Надежность систем хранения обеспечивается другими методами (взрослые ли СХД, DRBD и т.п.)
В нашей схеме потеря любого backend вообще никак не сказывается на работоспособности, в этом случае или при пиковой нагрузке мы можем еще и staging сервер зацепить в качестве backend'а. Он является таким же backend'ом, только доступен «снаружи» мимо nginx и на нем тестируются обновления (короче это либо дев машина или выделенный в ферме сервер на котором делаются аццкие эксперименты по вкатыванию обновлений, сборки свежего софта и обкатки конфигурации).
Для совсем небольших проектов, где не требуется HA, но хочется определенного запаса производительности и масштабируемости в будущем у нас работает схема (очень экономная):
1. Один nginx frontend + storage controller + nfs server
2. Один Apache backend + все cron задачи
3. MySQL Master
4. MySQL Slave + backup
Все это конечно же на «брендовых» серверах с гарантией на замену хотя бы NBD. Мы используем HP Proliant DL360/DL380. Это страховка на случай поломок.
Еще, с моей точки зрения, минус — локальные скрипты на каждом бекенде. В моем случае весь проект, включая скрипты, лежит на системе хранения, которая «расшарена» на все web-сервера (и фронт и бекэнды), соответственно одинаковые настройки апачей и nginx отдает всю статику сам, скрипты проксирует на апачи. Архитектура приложений разрабатывается таким образом, что никакие скрипты не могут писать в один и тот-же файл (логично! нафига нам геморой с локами, хотя это тоже решабельно). Ну и забываем о проблемах синхронизации заодно. Надежность систем хранения обеспечивается другими методами (взрослые ли СХД, DRBD и т.п.)
В нашей схеме потеря любого backend вообще никак не сказывается на работоспособности, в этом случае или при пиковой нагрузке мы можем еще и staging сервер зацепить в качестве backend'а. Он является таким же backend'ом, только доступен «снаружи» мимо nginx и на нем тестируются обновления (короче это либо дев машина или выделенный в ферме сервер на котором делаются аццкие эксперименты по вкатыванию обновлений, сборки свежего софта и обкатки конфигурации).
Для совсем небольших проектов, где не требуется HA, но хочется определенного запаса производительности и масштабируемости в будущем у нас работает схема (очень экономная):
1. Один nginx frontend + storage controller + nfs server
2. Один Apache backend + все cron задачи
3. MySQL Master
4. MySQL Slave + backup
Все это конечно же на «брендовых» серверах с гарантией на замену хотя бы NBD. Мы используем HP Proliant DL360/DL380. Это страховка на случай поломок.
В вашей «экономной» схеме одно из узких мест — это NFS. Да это удобнее, чем периодическая синхронизация скриптов rsync'ом, но в случае неполадок с сетью у вас начнут вставать раком бекенды, зашарившие себе скрипты. Мы этим уже набили себе шишки :(
Если база активно читается, но «редко» апдейтится, то логично развернуть на каждом апаче [2] по реплике базы, чтобы распределить нагрузку чтения по нескольким серверам.
Если [4] держится только для того, чтобы периодически с базы снимать резервные копии, то для [4] не нужен выделенный сервер — можно подселить на один из [2] или [1].
Кстати, Вы не упомянули о том, что файловая система с БД должна уметь снапшотиться (lvm для Linux). Резервное копирование БД очень хорошо проводить со снятого снапшота, а не с работающей БД.
Если база активно читается, но «редко» апдейтится, то логично развернуть на каждом апаче [2] по реплике базы, чтобы распределить нагрузку чтения по нескольким серверам.
Если [4] держится только для того, чтобы периодически с базы снимать резервные копии, то для [4] не нужен выделенный сервер — можно подселить на один из [2] или [1].
Кстати, Вы не упомянули о том, что файловая система с БД должна уметь снапшотиться (lvm для Linux). Резервное копирование БД очень хорошо проводить со снятого снапшота, а не с работающей БД.
NFS поднят через отдельный гигабитный маршрутизатор, сервера в него светят «небоевыми» сетевухами (то есть NFS на одном интерфейсе, а http траф на другом, да и через другой маршрутизатор). Свичи простецкие Cisco 2970 или подобные. В схеме с СХД каким-то другим способом и не «пошарить» общий том на фронты и бекэнды
Хорошо, а если откажет front-end — выставлять application-server в интернет? Но он тоже не вечен.
Нет избыточности, а это критично при отказе.
Нет избыточности, а это критично при отказе.
Большой минус в вашей системе — это мастер-мастер репликация. В MySQL на больших нагрузках она иногда подвисает. Предпочтение лучше отдать мастер — слейв репликации.
Хорошо. Мастер-слейв. Но при падении мастера, в том случае, если мы отказываемся от mysql-proxy, необходимо ВСЕ application-сервера перенастраивать на новую базу.
Время восстановления увеличивается
Время восстановления увеличивается
А вы соединяйтесь к БД не по IP адресу, а по доменному имени…
так. доменное имя все равно соответствует ip.
какое имя имеется ввиду: имя для общего адреса для heartbeat между mysql-серверами (при отсутствии mysql-proxy) или между адреса для heartbeat между mysql-proxy?
какое имя имеется ввиду: имя для общего адреса для heartbeat между mysql-серверами (при отсутствии mysql-proxy) или между адреса для heartbeat между mysql-proxy?
Имеется в виду строка инициализации соединения к БД в скриптах (PHP?) на application-серверах. Упал мастер — указываем IP слейва в DNS и скрипты начинают соединяться к слейв серверу…
Дописал в статью скрипт и конфиг
>В случае двунаправленной репликации базы данных будут находиться в согласованном состоянии.
Не так. Могут находиться в согласованном состоянии во многих случаях.
Но если у вас wordpress и вы все протестировали годами, ну ладно…
Не так. Могут находиться в согласованном состоянии во многих случаях.
Но если у вас wordpress и вы все протестировали годами, ну ладно…
Sign up to leave a comment.
Высокодоступное отказоустойчивое web-приложение на Apache2 и MySQL