Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 67
Не очень понятно, как разруливается следующая ситуация:
Получается, данные из пункта 2 теряются. Что я не так понял?
- Мастер записал метку
- Пользователь «купил что-то в магазине» (или другое аналогичное действие)
- Произошёл сбой в дата-центре мастера
- Slave обнаружил это и начал использовать базу пятиминутной давности
- Через две минуты дата-центр мастера восстанавливается
- Мастер копирует себе базу данных slave, но без транзакции из п.2 (slave не успел её скопировать перед сбоем)
Получается, данные из пункта 2 теряются. Что я не так понял?
дело в том, что на слейве база не пятиминутной давности, а репликация — т.е. это база актуальная ровно до тех пор пока мастер на перестанет работать как мастер.
Т.е. если клиент совершил транзакцию — она совершилась на мастере и эти данные в БД передались на слейв в реплике.
Конечно, возможна ситуация, когда пропало соединение между мастером и слейвом и нарушилась репликация — тогда да, это слабое место, — транзакцию мы потеряем. НО это отдельная ситуация, которую можно отдельно диагностировать и лечить
Т.е. если клиент совершил транзакцию — она совершилась на мастере и эти данные в БД передались на слейв в реплике.
Конечно, возможна ситуация, когда пропало соединение между мастером и слейвом и нарушилась репликация — тогда да, это слабое место, — транзакцию мы потеряем. НО это отдельная ситуация, которую можно отдельно диагностировать и лечить
А теперь представим ошибку ПО: и неверные данные расползутся сразу и на master и на slave ноду. Да даже не ошибка ПО, а ошибка реплики — и данные в slave не консистентны.
При ошибке ПО никакие решения по резервированию не помогут — поможет только откручивание головы программистам. Так же и по реплике — это не предмет для обсуждения. Репликация это базовый механизм — она должна работать без ошибок. Ставьте себе нормальные СУБД
Для этого есть бекап, надежность хранения и доступность сервиса все таки разные вещи.
Это вы зря. Репликация в mysql может отставать и отставать намного по разным причинам.
надо правильно настроить репликацию, следить, чтобы она была живой.
Как бы то ни было — я же говорил в статье, что слабые места есть. Но, объективно говоря, я не встречал ничего лучшего в пределах такого же бюджета!
Как бы то ни было — я же говорил в статье, что слабые места есть. Но, объективно говоря, я не встречал ничего лучшего в пределах такого же бюджета!
Да чушь это всё, поверьте)
У нас mysql-ев много. Чтобы оно как-то жило — по 4-5 реплик, при отставании — закрывается от балансера.
У нас mysql-ев много. Чтобы оно как-то жило — по 4-5 реплик, при отставании — закрывается от балансера.
Я предложил решение для заданных условий. Оно реально работает.
У вас есть идеи лучше? поделитесь! давайте обмениваться фишками как обойти те или иные слабые места.
У вас есть идеи лучше? поделитесь! давайте обмениваться фишками как обойти те или иные слабые места.
Ну если навскидку —
0) 2 облака, selectel + amazon или ещё кто (с оплатой по факту потребления).
1) mysql-репликация в отдельные виртуалки, кнопка «переналить реплику» — rsync'ом. С закрыванием при отставании, с проверкой, что оно не остаётся последней доступной репликой.
2) пачка stateless фронтов (которые могут ответить на любой запрос независимо ни от чего). Добивается выносом сессий в базу, в первую очередь.
3) сторадж для файлов из говна и палок (nginx, try_files+ именнованный location который уходит в соседние ноды за файлами, если 404-ка).
4) код сервисов деплоить пакетами, все файлы не вписывающиеся в пакет — смотреть пункт 3.
5) честный ipvs-балансер с адресом, который гуляет по ospf домену (hetzner даже такие продаёт).
Тогда ещё об отказоустойчивости можно начинать говорить. В принципе, описанное мной — 3-4 железки в hetzner в разных гермозонах.
В общем, сервисы отказоустойчивыми получаются из горизонтального масштабирования и stateless-элементов, а не того, что вы описали)
Тогда уж проще поднять на каждом фронте 2 bind'а и с каждого выплевывать A/AAAA-запись, указывающую на себя, делать в nginx'e fallback на соседа, если не можем ответить (а при упавшем nginx — тушить и bind). Тогда упавший сервер просто не отдаст DNS-запись -> при TTL=60 через 2 минуты оттуда уйдет 90% клиентов. Останутся только неудачники с провайдерами, резолверы которых кешируют записи принудительно.
0) 2 облака, selectel + amazon или ещё кто (с оплатой по факту потребления).
1) mysql-репликация в отдельные виртуалки, кнопка «переналить реплику» — rsync'ом. С закрыванием при отставании, с проверкой, что оно не остаётся последней доступной репликой.
2) пачка stateless фронтов (которые могут ответить на любой запрос независимо ни от чего). Добивается выносом сессий в базу, в первую очередь.
3) сторадж для файлов из говна и палок (nginx, try_files+ именнованный location который уходит в соседние ноды за файлами, если 404-ка).
4) код сервисов деплоить пакетами, все файлы не вписывающиеся в пакет — смотреть пункт 3.
5) честный ipvs-балансер с адресом, который гуляет по ospf домену (hetzner даже такие продаёт).
Тогда ещё об отказоустойчивости можно начинать говорить. В принципе, описанное мной — 3-4 железки в hetzner в разных гермозонах.
В общем, сервисы отказоустойчивыми получаются из горизонтального масштабирования и stateless-элементов, а не того, что вы описали)
Тогда уж проще поднять на каждом фронте 2 bind'а и с каждого выплевывать A/AAAA-запись, указывающую на себя, делать в nginx'e fallback на соседа, если не можем ответить (а при упавшем nginx — тушить и bind). Тогда упавший сервер просто не отдаст DNS-запись -> при TTL=60 через 2 минуты оттуда уйдет 90% клиентов. Останутся только неудачники с провайдерами, резолверы которых кешируют записи принудительно.
облака не облака — какая разница. можете использовать облака в моем решение. Для нашего проекта облака получаются дороже.
Реплика — ок. Опять же — можете применять любые хитрости для повышения надежности реплики — это не возбраняется.
Stateless — Это хорошо. На любой stateless есть экскаватор дяди Пети, копающий через магистраль.
Вы, по моему, вообще немного о другом…
Реплика — ок. Опять же — можете применять любые хитрости для повышения надежности реплики — это не возбраняется.
Stateless — Это хорошо. На любой stateless есть экскаватор дяди Пети, копающий через магистраль.
Вы, по моему, вообще немного о другом…
> облака не облака
Облака не потому что облака, а потому что куча малонагруженных серверов там дешевле. Очевидно, что если в вашем случае получается дороже — забейте.
> копающий через магистраль.
вы хотя бы понимаете смысл stateless-фронтов? Если экскаваторщик порвет линк между ДЦ (пусть даже этот линк на границе с популярной Германией) — половина кластера у вас будет отдавать сервис в режиме read-only, а вторая — нормально работать. А там дальше вы уже сами смотрИте, насколько вам такой режим допустим. Можно поотдавать 15 минут, а потом закрыться и не показывать из второго крыла сервис. Тут свобода действий.
> Вы, по моему, вообще немного о другом…
Я то как раз о fail-over в веб-сервисах.
А вот уж сервис смс-рассылок можно из бамбука точно собрать так, чтобы он вообще никогда не упал. Генерирующие машинки, всё такое.
Вы как бы понимаете куда вы написали свой пост, в принципе? Понимаете последствия таких постов?
А, впрочем, пишите. Мне же больше денег будет.
Облака не потому что облака, а потому что куча малонагруженных серверов там дешевле. Очевидно, что если в вашем случае получается дороже — забейте.
> копающий через магистраль.
вы хотя бы понимаете смысл stateless-фронтов? Если экскаваторщик порвет линк между ДЦ (пусть даже этот линк на границе с популярной Германией) — половина кластера у вас будет отдавать сервис в режиме read-only, а вторая — нормально работать. А там дальше вы уже сами смотрИте, насколько вам такой режим допустим. Можно поотдавать 15 минут, а потом закрыться и не показывать из второго крыла сервис. Тут свобода действий.
> Вы, по моему, вообще немного о другом…
Я то как раз о fail-over в веб-сервисах.
А вот уж сервис смс-рассылок можно из бамбука точно собрать так, чтобы он вообще никогда не упал. Генерирующие машинки, всё такое.
Вы как бы понимаете куда вы написали свой пост, в принципе? Понимаете последствия таких постов?
А, впрочем, пишите. Мне же больше денег будет.
Я так и не понял чем ваше решение лучше предложенного? Тем что я должен нажимать кнопку переналить реплику?
А, ну да. Писать — в master, читать из slave. Всегда, если реплики доступны. А то знаем мы их =)
Для WEB-сайта, магазина это м.б. и приемлемо, а для системы с кучей транзакци в секунду, отчетами, биллингом — нельзя. работа должна быть с одной конкретной сущностью бд
Мне вот интересно. Ваша система денег не приносит, чтобы вы могли сисадмина нанять (сисадмина, а не эникейщика 5 минут назад) и потратиться на то, от чего ваш доход зависит напрямую (на серверы, то есть)?
Всё это достижимо. Всё это прекрасно делается. Но не описанным вами способом. Ну то есть в основу можно положить вашу теорию про «возьмем 2 сервера». Только потом читать нельзя.
Вы совершенно не представляете, как работает DNS.
Вы хотя бы раз видели шум трафика на адресе спустя месяц после смены DNS-записей с TTL=360? И он далеко не нулевой — это реальные пользователи, деньги, whatever.
Вы хотя бы раз ругались с провайдером, который принудительно кеширует записи?
Всё это достижимо. Всё это прекрасно делается. Но не описанным вами способом. Ну то есть в основу можно положить вашу теорию про «возьмем 2 сервера». Только потом читать нельзя.
Вы совершенно не представляете, как работает DNS.
Вы хотя бы раз видели шум трафика на адресе спустя месяц после смены DNS-записей с TTL=360? И он далеко не нулевой — это реальные пользователи, деньги, whatever.
Вы хотя бы раз ругались с провайдером, который принудительно кеширует записи?
не надо воздух языком (пальцами..) молоть просто так — ни к чему.
на счет кеширования DNS — проблем никаких нету — пускай кешируются, второй IP тоже наш и на нем прокси. Вся штука нужна для оперативного переброса основного трафика на резервный сервак быстро и «само» во время аварии. и за дешево.
А от чего прибыль зависит линейно или нелинейно — это позвольте считать тем, кто нанимает сисадминов. Оставьте смсадминские понты при себе — как правило намного больше самомения у сисадминов чем реальных стоящих решений.
«Все это прекрасно делается» — расскажите как — добавим в копилку знаний. фигли щеки то надувать просто так…
на счет кеширования DNS — проблем никаких нету — пускай кешируются, второй IP тоже наш и на нем прокси. Вся штука нужна для оперативного переброса основного трафика на резервный сервак быстро и «само» во время аварии. и за дешево.
А от чего прибыль зависит линейно или нелинейно — это позвольте считать тем, кто нанимает сисадминов. Оставьте смсадминские понты при себе — как правило намного больше самомения у сисадминов чем реальных стоящих решений.
«Все это прекрасно делается» — расскажите как — добавим в копилку знаний. фигли щеки то надувать просто так…
Такой сервис на звание 24*7 тянет с натяжкой. 20 минут простоя все же не такая маленькая часть времени.
Да, но это решение, которое доступно всем интернет проектам с самыми маленькими бюджетами. Это лучше чем ничего. И даже такие (или аналогичные) решения очень мало кто применяет на практике!
я предложил здесь реальную работающую надежную схему с временем простоя ок. 20 минут при любых самых жесткых крешах. Использовать эти идеи или не использовать — решать вам.
я предложил здесь реальную работающую надежную схему с временем простоя ок. 20 минут при любых самых жесткых крешах. Использовать эти идеи или не использовать — решать вам.
24x7 это просто красивые циферки от маркетологов. Доступность сервиса нужно измерять с помощью адекватной метрики, н-р, SLA. По поводу того, много или мало 20 минут. Зависит от клиентов/посетителей. Насколько я понимаю ТС продают сервис, возможно клиентов ТС удовлетворяют такие требования. В этом нет ничего такого.
20 минут простоя за год это SLA 99.999962% и на самом деле это нормальный показатель.
20 минут простоя за год это SLA 99.999962% и на самом деле это нормальный показатель.
>> 20 минут простоя за год
Только не за год, а за каждую аварию.
Только не за год, а за каждую аварию.
у нас примерно раз в 2 месяца чтото бывает. вот считайте…
я не хочу тут мериться циферками на самом деле. Просто имея реальный опыт эксплуатация аналогичных систем (СМС-севрисы и пр. операторские штуки) — вот такое решение себя очень и очень хорошо показало!
Многие крупные агрегаторы не могут похвастаться такой системой переклчюения на резерв.
я не хочу тут мериться циферками на самом деле. Просто имея реальный опыт эксплуатация аналогичных систем (СМС-севрисы и пр. операторские штуки) — вот такое решение себя очень и очень хорошо показало!
Многие крупные агрегаторы не могут похвастаться такой системой переклчюения на резерв.
Ну вот кстати и зря. Будет у вас клиент, спросит, «Какую доступность гарантируете при заданной нагрузке?» А вы ему ответите 24x7x365. Как думаете, поверят люди? А если поверят и произойдет факап, кто будет страховать?:) Вы собираетесь выплачивать неустойку? SLA для того и существует, чтобы говорить о гарантии опредленного уровня доступности.
моя статейка не об SLA а о том как малыми силами сделать максимально надежный сервис.
Есть компании разного уровня с разными бюджетом на технику. Если вы хотите за маленькие деньги дать чуть лучший результат чем все ваши ближайшие конкуренты с аналогичным уровнем инвестиций — тогда мое решение для вас.
Есть компании разного уровня с разными бюджетом на технику. Если вы хотите за маленькие деньги дать чуть лучший результат чем все ваши ближайшие конкуренты с аналогичным уровнем инвестиций — тогда мое решение для вас.
Эм. То есть 120 минут простоя в год? 99,8% доступности? Смешно же.
не вижу ничего смешного. мы работаем с СМС-центрами сотовых операторов — при их бюджетах многие их железки «лежат» почаще нашей
KISS.
Табуреточная система легко живет с 99,8% доступности без всяких ухищрений (я вам могу сказать, что аптайм правильно заказанных железок ощутимо выше этой цифры).
Другой вопрос, что экономите вы не только на серверах, но и на разработке. Так что у вас там такой ад, что к KISS вы никогда не вернетесь.
Вам дорога в hetzner, покупку двух тазиков, настройку heartbeat с fail-over адресом у них. И всё. Вопрос 3 килорублей в месяц (5-7, если вам нужны хорошие железки). Таким образом вы себе обеспечите нечто близкое к 100% до тысячных процента, а остальные 0.2% — аварии в ДЦ.
А обеспечивать «отказоустойчивость» сервиса способом описанным вами — это ппц.
А к статье претензии примерно такого рода — «чо приперлись — это все и так знают», да. При том, что те, кто думают головой — знают ещё и то, что это ппц.
Табуреточная система легко живет с 99,8% доступности без всяких ухищрений (я вам могу сказать, что аптайм правильно заказанных железок ощутимо выше этой цифры).
Другой вопрос, что экономите вы не только на серверах, но и на разработке. Так что у вас там такой ад, что к KISS вы никогда не вернетесь.
Вам дорога в hetzner, покупку двух тазиков, настройку heartbeat с fail-over адресом у них. И всё. Вопрос 3 килорублей в месяц (5-7, если вам нужны хорошие железки). Таким образом вы себе обеспечите нечто близкое к 100% до тысячных процента, а остальные 0.2% — аварии в ДЦ.
А обеспечивать «отказоустойчивость» сервиса способом описанным вами — это ппц.
А к статье претензии примерно такого рода — «чо приперлись — это все и так знают», да. При том, что те, кто думают головой — знают ещё и то, что это ппц.
аварии в ДЦ это не 0,2% — это основное от чего мы стараемся защититься, чтобы не рвать себе ж… пу от беспомощности когда звонит клиент и говорит А ГДЕ СЕРВИС?
в теории все красиво — на практике у всех одно и тоже все. Пропадает сервер — телефон ДЦ недоступен из-за обилия звонков. Клиентам приходится отвечать «мы делаем все возможное» и никаких прогнозов по восстановлению!
100 раз это проходили!
описанное решение позволяет всегда сказать клиенту в случае чего: через 10 минут, сервис будет доступен. и все.
это реальное решение а не долбанное теоретизирование…
в теории все красиво — на практике у всех одно и тоже все. Пропадает сервер — телефон ДЦ недоступен из-за обилия звонков. Клиентам приходится отвечать «мы делаем все возможное» и никаких прогнозов по восстановлению!
100 раз это проходили!
описанное решение позволяет всегда сказать клиенту в случае чего: через 10 минут, сервис будет доступен. и все.
это реальное решение а не долбанное теоретизирование…
SLA измеряют не за аварию, а за какое-то время. Вы можете терять доступность внутренних частей вашей сложной системы, но если это не в ущерб функциональности и производительности, то на доступности это никак не отразиться. Чтобы мониторить SLA можно пользоваться внешними сервисами.
Ну и вообще, как правило клиенты/пользователи тоже должны просить о требования к производительности/доступности не с помощью циферок 24x7x365, а с помощью нормальных метрик, которые можно реально измерить. И вот когда стоит задача обеспечить SLA в 99.9999% и что бы она не падала, вот тут нужно пораскинуть мозгами. Простые мысли о зеркалировании и даже год продакшана ничего не гарантируют. И в юбилей из может все покрашиться.
Прислушайтесь выше к inkvizitor68sl он дело говорит:)
Ну и вообще, как правило клиенты/пользователи тоже должны просить о требования к производительности/доступности не с помощью циферок 24x7x365, а с помощью нормальных метрик, которые можно реально измерить. И вот когда стоит задача обеспечить SLA в 99.9999% и что бы она не падала, вот тут нужно пораскинуть мозгами. Простые мысли о зеркалировании и даже год продакшана ничего не гарантируют. И в юбилей из может все покрашиться.
Прислушайтесь выше к inkvizitor68sl он дело говорит:)
вот коммент по делу.
я бы еще уточнил, что в жизни заявленный в SLA uptime мало кто соблюдает и мало кто его меряет. По своему опыту — многие провайдеры, с хорошим SLA не обеспечивают заявленной доступности.
я бы еще уточнил, что в жизни заявленный в SLA uptime мало кто соблюдает и мало кто его меряет. По своему опыту — многие провайдеры, с хорошим SLA не обеспечивают заявленной доступности.
>> это SLA 99.999962%
Ошибаетесь. 20 минут простоя за год это 99.9962%
Ошибаетесь. 20 минут простоя за год это 99.9962%
Вам надо придумать, как обойти ситуацию со spit brain: если по какой-то причине потеряется связность между вашими машинами (что нибудь с пирингом между провайдерами, например), то обе машины будут назначать себя мастерами. Черевато тем, что репликация поломается совсем: при накатывании бинлога будут возникать ошибки, которые придётся чинить руками, потери данных тоже возможны. И клиенты будут во время аварии постоянно попадать на разные машины.
Починить это можно введением третьей реплики, тогда в любой момент времени рабочими считаются только те части кластера, где как минимум 2 машины.
Починить это можно введением третьей реплики, тогда в любой момент времени рабочими считаются только те части кластера, где как минимум 2 машины.
тут просто надо найти компромисс между степенью надежности и уровнем затрат (денежных и трудовых), которые вы готовы понести.
Вы предлагаете добавить еще +1 машину и усложнить схему.
С моей точки зрения это уже излишняя перестраховка.
Но, вообще, вы правы — проблема эта есть. И мы ее решили блокировкой переключения в слейв в случае разрыва коннекта между двумя серверами.
И вообще, я же не говорю, что наше решение — панацея. Система постоянно меняется и тюнингуется. Если есть проблемы с соединением между датацентрами мы переезжаем в другой дата-цетр
Вы предлагаете добавить еще +1 машину и усложнить схему.
С моей точки зрения это уже излишняя перестраховка.
Но, вообще, вы правы — проблема эта есть. И мы ее решили блокировкой переключения в слейв в случае разрыва коннекта между двумя серверами.
И вообще, я же не говорю, что наше решение — панацея. Система постоянно меняется и тюнингуется. Если есть проблемы с соединением между датацентрами мы переезжаем в другой дата-цетр
Дико извиняюсь, я мало чего понимаю в отказоустойчивости, но читая Вашу статью, у меня не сложилось впечатления что это нормальная отказоустойчивость. Всё же наверно должно быть три ноды. Ну и как правильно говорят: писать в master, читать из slave — ИМХО не лишено смысла, но чревато потерей производительности думаю.
тут же фишка в том, что всего 2 сервера применяется. 3 сервера в 1,5 раза дороже систему сделает и усложнит ее обслуживание.
Читать из slave — не годится. Т.к.
1. slave м.б. недоступен
2. БД на slave может отставать
3. производительность. У нас СМСка должна дойти за 4 секунды от момента отправки клиентом и до попадания на телефон — лишний трафик между серверами во время транзакции не целесообразен.
Читать из slave — не годится. Т.к.
1. slave м.б. недоступен
2. БД на slave может отставать
3. производительность. У нас СМСка должна дойти за 4 секунды от момента отправки клиентом и до попадания на телефон — лишний трафик между серверами во время транзакции не целесообразен.
В целом реально здорово. Но не ужели не реален такой случай: когда связность между нодами сбоит, и тут отключается связность вообще и мастер нода в частности (Вы ведь не знаете какая маршрутизация у Ваших провайдеров)? — Мы имеем неконсистент ноду slave чуть более чем полностью которая тутже становится мастером.
И мы ее решили блокировкой переключения в слейв в случае разрыва коннекта между двумя серверами.
То есть 2 мастера и будет постоянно?
Если производительность устроит — то Galera должна решить вашу проблему выбора мастера, данные на разных машинах всегда будут синхронны, в отличие от master-slave, заодно и нагрузку можно сразу на все машины пустить, если получится сделать stateless бизнес логику. Правда, всё же 3 сервера тогда понадобится. Что же касается денег… Вы же продаёте услугу, администраторам платите, неужели не потянете ещё 50-100 евро в месяц? Можно даже не большой сервер брать, а совсем мелкий, и там только арбитра запустить, ещё дешевле выйдет.
Кстати, настроить Galera будет проще, чем поддерживать кучу bash скриптов на разные случаи жизни. Связность между машинами можно проверять, спрашивая тот же mysql, в каком он состоянии. Если нужно именно мастера выбирать — то ZooKeeper очень удобно для этого использовать, опять же это одно из его предназначений. Чем меньше в вашей системе будет самодельных костылей — тем лучше она будет работать в нештатных ситуациях.
2 мастера в нашей схеме не может быть никак. Как только один севрер стал мастером — он сам прописал свой IP на DNS в момент переключения из slave — все начиная с этого момента 2-й «мастер» увидит в DNS что он не мастер больше. А slave себя назначит мастером только если старый мастер не пишет в DNS.
А есть гарантии, что DNS обновляется атомарно, и будет сразу отдавать новые записи с любого ns сервера? Да и что делать, если по какой-то причине сервер, через который вы обновляете DNS, станет недоступным для ваших машин (пиринговые проблемы, опять же)?
Мне кажется, что если есть надёжный и проверенный способ определения состояния кластера — то нужно пользоваться им, а не надеяться на внешние сервисы.
Мне кажется, что если есть надёжный и проверенный способ определения состояния кластера — то нужно пользоваться им, а не надеяться на внешние сервисы.
плюс описанного решения в том, что не требуется никакого кластера, не требуется третей машины для диагностики.
Все можно собрать на 2-х VPS'ках ценой по 3000 рублей в месяц каждая.
И это решение закрывает 90% потребностей большинства интернет проектов малого и среднего размера.
Можно сколько угодно филосовствовать на тему правильного отказоустойчивого решения, а можно взять и сделать то что тут написано. По моему обширному опыту — в большинстве проектов все заканчивается болтовней типа той, что здесь в комментах
Все можно собрать на 2-х VPS'ках ценой по 3000 рублей в месяц каждая.
И это решение закрывает 90% потребностей большинства интернет проектов малого и среднего размера.
Можно сколько угодно филосовствовать на тему правильного отказоустойчивого решения, а можно взять и сделать то что тут написано. По моему обширному опыту — в большинстве проектов все заканчивается болтовней типа той, что здесь в комментах
3-я машина не обязательно должна быть «полноценной».
Поинтересуйтесь логикой работы кластерного софта HP, например.
Определение кто именно отвалился выполняется с помощью отдельной службы — она пересылает та называемый heartbeat между 3 машинами, фактически пингует.
Дополнительный 3-й сервер называется у HP кворум-сервером.
Если сервер видит себя и еще хотя бы одного, то он считает, что он не отвалился.
Если он slave, и виден только кворум, то пора становиться мастером.
И т.д.
Поинтересуйтесь логикой работы кластерного софта HP, например.
Определение кто именно отвалился выполняется с помощью отдельной службы — она пересылает та называемый heartbeat между 3 машинами, фактически пингует.
Дополнительный 3-й сервер называется у HP кворум-сервером.
Если сервер видит себя и еще хотя бы одного, то он считает, что он не отвалился.
Если он slave, и виден только кворум, то пора становиться мастером.
И т.д.
Сколько реальных падений пережила эта система?
Для любителей точных определений, сисадминов, деятелей науки и недооцененных гениальных инженеров.
Друзья, эта статья не является определением термина «откзаустойчивость», «24х7» и п т.п. И не является панацеей от всех бед.
Эта статья в основном предназначена для менеджеров по оптимизации инфраструктуры, фин. директоров, ИТ-директоров, тех, что считает деньги в проекте!
Это статься о том, как силами обычных доступных на рынке админов и программистов с использованием дешевого железа организовать устойчивый надежный сервис и при этом не трезвонить подчиненным техникам по ночам в случае аварии.
Друзья, эта статья не является определением термина «откзаустойчивость», «24х7» и п т.п. И не является панацеей от всех бед.
Эта статья в основном предназначена для менеджеров по оптимизации инфраструктуры, фин. директоров, ИТ-директоров, тех, что считает деньги в проекте!
Это статься о том, как силами обычных доступных на рынке админов и программистов с использованием дешевого железа организовать устойчивый надежный сервис и при этом не трезвонить подчиненным техникам по ночам в случае аварии.
У меня есть интересное наблюдение. Если программист спрашивает как чтото сделать на заграничном форуме — ему стараются ответить ровно на его вопрос, даже если он на чей то взгляд глупый. На наших же пост-советских форумах вместо ответа с вероятностью 90% задающего вопрос будут по максимуму лажать, доказывая, что он не специалист и не разбирается в предметной области — вместо ответа. Это какой то комплекс постсоветский.
вот и сейчас — к чему ваш коммент? я поставил задачу и предложил решение. Я знаю, что это решение реально является ноу хау — мало кто так делает, большинство не делают вообще ничего.
Какая вам разница как я озаглавил статью? Да, очевидно, что 24х7 не бывает в принице. Или бывает? ну предложите решение сами как это сделать. да еще в аналогичных бюджетах
вот и сейчас — к чему ваш коммент? я поставил задачу и предложил решение. Я знаю, что это решение реально является ноу хау — мало кто так делает, большинство не делают вообще ничего.
Какая вам разница как я озаглавил статью? Да, очевидно, что 24х7 не бывает в принице. Или бывает? ну предложите решение сами как это сделать. да еще в аналогичных бюджетах
У меня есть интересное наблюдениеАмериканская культура направлена в будущее — все расказывают как сделать, чтобы было потом лучше. Российская культура — смотрит на настоящее, поэтому все сначала опускают автора, если вдруг чего-то не так.
Какая вам разница как я озаглавил статью?
По сути без разницы. Когда я беру пакет на котором написано «молоко» я ожидаю найти там молоко, а не томатный сок. Я сильно подозреваю, что будь статья названа более близко к сути топика, столько бы негатива она не вызвала.
ну предложите решение сами как это сделать.
fallover ip в том же hetzner переключается, что-то около 30 сек. В профиты — ни каких проблем с DNS кэшем.
У вас сервер приложений и БД — одна машина? Bitch please tell me more ©
Стандартное решение в этой области:
балансир (nginx + кучка upstream) -> сервера приложения -> сервера БД (реплики)
Не учите нас ездить на ваших велосипедах с баш скриптами.
Стандартное решение в этой области:
балансир (nginx + кучка upstream) -> сервера приложения -> сервера БД (реплики)
Не учите нас ездить на ваших велосипедах с баш скриптами.
Вот, посмотрите лучше картинки: aws.amazon.com/architecture/
да какая разница на скольких серверах у нас приложения и СУБД? для описанного решения требуется минимум 2 машины и не требуется никакой балансир, циска и никакая другая железка которая может сама сломаться или отрезаться от мира — используется DNS сервер, за которым не надо ухаживать. решние можно построить с минимальными вложениями.
не хотите учиться — не учитесь — жуйте сопли своих правильных теорий. а 99% проектов в нете так и будут продолжать работать на дерьме
не хотите учиться — не учитесь — жуйте сопли своих правильных теорий. а 99% проектов в нете так и будут продолжать работать на дерьме
Классная истерика!
Вы меня не поняли. Смешно слушать советы по построению отказоустойчивого сервиса от людей неспособных раскошелится на отдельную машину под бд и скупящихся на балансир.
Вам очень правильно пишут выше — если рассматривать ситуацию, что каждая железка может сломаться и выйти из строя, то нужно держать проект на большом количестве максимально независимых и заменяемых элементах. Потому что если вы будете держать все на одной — она просто сломается. И начинать нужно было с этого, но, по-моему, вы не понимаете основ, а брызжите слюной и обижаетесь.
Ваше решение будет работать, кто спорит. Просто оно очень частное и «дурно пахнет». Что бы вы делали если бы не было апи доступа к работе с днс записями? Я, признаться, не часто вижу такую фичу. Как вы будете работать с провайдером который кэширует ваши записи? Как вы новым программистам/админам будете объяснять как администрить ваш зоопарк скриптов?
Если вы подумаете над универсальностью решения — вы рано или поздно придете к устоявшейся, сто раз описаной и подтвержденной архитектуре. Это не сопли правильных теорий, это уже просто де-факто, а у вас — смесь костыля и велосипеда из говна и палок.
Вы меня не поняли. Смешно слушать советы по построению отказоустойчивого сервиса от людей неспособных раскошелится на отдельную машину под бд и скупящихся на балансир.
Вам очень правильно пишут выше — если рассматривать ситуацию, что каждая железка может сломаться и выйти из строя, то нужно держать проект на большом количестве максимально независимых и заменяемых элементах. Потому что если вы будете держать все на одной — она просто сломается. И начинать нужно было с этого, но, по-моему, вы не понимаете основ, а брызжите слюной и обижаетесь.
Ваше решение будет работать, кто спорит. Просто оно очень частное и «дурно пахнет». Что бы вы делали если бы не было апи доступа к работе с днс записями? Я, признаться, не часто вижу такую фичу. Как вы будете работать с провайдером который кэширует ваши записи? Как вы новым программистам/админам будете объяснять как администрить ваш зоопарк скриптов?
Если вы подумаете над универсальностью решения — вы рано или поздно придете к устоявшейся, сто раз описаной и подтвержденной архитектуре. Это не сопли правильных теорий, это уже просто де-факто, а у вас — смесь костыля и велосипеда из говна и палок.
да это не истерика. но признаюсь, я хотя человек уравновешенный по жизни — эта демагогия в комментариях меня изрядно выбешивает.
Моя статья о том, как взять и руками сделать реальное рабочее клевое решение, причем потратив на это 3 копейки и немного времени.
Если человек не умеет систематизировать мысли и привык шаманить — то получится как вы написали — зоопарк из скриптов, которые как работают не понятно. чтобы такого не было — вот вам алгоритм
я предложил алгоритмическое системное решение без 3-й ноды, которое позволяет избежать огромное количество головной боли по подъему резерва и восстановлению после крешей. Никакого зоопарка — надо просто взять и аккуратно сделать — совсем немного скриптов, все понятно как работает.
— за многолетний опыт работы в разных компаниях ( даже таких, где бюджет позволяет сделать грамотное «правильное» решение) я насмотрелся кучу историй когда админы читают лекции руководству надувают щеки, бросаются терминами и в итоге все упирается либо в
а) нежелание руководства инвестировать в закрытие аморфных рисков по безопасности (типа у нас все и так круто, а если сломается — пусть админы разбираются по факту)
б) тупо лень админов, отсутствие практики и / или организационную слабость
Это реально ВЕЗДЕ так! проектов с такими правильными решениями коих тут в коментах напредлагали наши гениальные IT-специалисты —
единицы!
и этот подходец тоже зашибись — типа если у организации нету лишних 5К евро на сервер то пусть она закрывается нафиг.
— эта статья не о том как правильно построить идеальный безотказный сервис, а о том как взять и сделать — закрыть риски, даже если на это нету бюджета.
Если ваши возможности (и организационные и финансовые) позволяют сделать все по-правильному — поздравляю, делайте эта статья просто не для вас. не надо лить кучи говна! я убежден, что огромному числу людей изложенный здесь алгоритм (вцелом как решение) будет очень полезен (при наличие воли к результату)
Моя статья о том, как взять и руками сделать реальное рабочее клевое решение, причем потратив на это 3 копейки и немного времени.
Если человек не умеет систематизировать мысли и привык шаманить — то получится как вы написали — зоопарк из скриптов, которые как работают не понятно. чтобы такого не было — вот вам алгоритм
я предложил алгоритмическое системное решение без 3-й ноды, которое позволяет избежать огромное количество головной боли по подъему резерва и восстановлению после крешей. Никакого зоопарка — надо просто взять и аккуратно сделать — совсем немного скриптов, все понятно как работает.
— за многолетний опыт работы в разных компаниях ( даже таких, где бюджет позволяет сделать грамотное «правильное» решение) я насмотрелся кучу историй когда админы читают лекции руководству надувают щеки, бросаются терминами и в итоге все упирается либо в
а) нежелание руководства инвестировать в закрытие аморфных рисков по безопасности (типа у нас все и так круто, а если сломается — пусть админы разбираются по факту)
б) тупо лень админов, отсутствие практики и / или организационную слабость
Это реально ВЕЗДЕ так! проектов с такими правильными решениями коих тут в коментах напредлагали наши гениальные IT-специалисты —
единицы!
и этот подходец тоже зашибись — типа если у организации нету лишних 5К евро на сервер то пусть она закрывается нафиг.
— эта статья не о том как правильно построить идеальный безотказный сервис, а о том как взять и сделать — закрыть риски, даже если на это нету бюджета.
Если ваши возможности (и организационные и финансовые) позволяют сделать все по-правильному — поздравляю, делайте эта статья просто не для вас. не надо лить кучи говна! я убежден, что огромному числу людей изложенный здесь алгоритм (вцелом как решение) будет очень полезен (при наличие воли к результату)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт построения бюджетного отказоустойчивого online-сервиса 24х7