Comments 14
В статье описаны как раз те риски которые с успехом решаются облачными решениями. Минус такого подхода, это чрезвычайно низкая масштабируемость и гибкость. Не рациональное использование ресурсов ведет к удорожанию всего решения в целом. Конечно в определенных ситуациях такой подход имет место быть. Все зависит от требований к проекту.
Всё-таки «низкий» стиль (лексика, т.е. язык) живого выступления не очень подходит для статьи.
Отлично подходит, такую простыню текста пресным языком я бы не осилил — бросил бы читать на середине.
Фразы вроде «он кладет в очередь сообщение, в надежде, что его кто-то обработает, но на самом деле с другой стороны там все умерли, апокалипсис, в общем» дают понять, что текст писал человек, у которого душа болит за проект — гораздо приятнее читать.
Фразы вроде «он кладет в очередь сообщение, в надежде, что его кто-то обработает, но на самом деле с другой стороны там все умерли, апокалипсис, в общем» дают понять, что текст писал человек, у которого душа болит за проект — гораздо приятнее читать.
Такой стиль совсем не подходит. А слова вида "гемор" и "сдох" недопустимы даже для выступления. Статейка доказывает, что специалист не всегда является писателем, а писатель — специалистом. Тем не менее, спасибо автору.
Очень классно. И прям все хорошо расписано. Но один момент просто убил. Вы не боитесь VRRP (когда железки провайдеров на него иногда очень плохо реагируют), но боитесь автоматического переключения на реплику БД? Ну что за бред. На дворе не 2005 год. Даже mysql легко переключается с даунтаймом в секунды. Postgree/mongo/elasticsearch/redis еще быстрее отрабатывают. Какие бы не были инструкции шанс ошибки в 5 утра всегда выше чем работа автоматики. Лучше просто получить инфо о происшествии и утром спокойно решить проблему.
Чтение со слейва БД — тут нужно осторожно. Слейвов должно быть больше одного. Один всегда держим без нагрузки — что бы он точно смог заменить мастер в любой ситуации. Ну и железо у него такое же как на мастере.
И расскажу как у нас бекапы устроены. Отдельные слейвы на которые прилетает «slave stop», делается бекап,«slave start». одна копия бекапа так и останется на винте не сжатой (если срочно понадобится). Она же упакуется zbackup на отдельный volume glusterfs(том c тройной репликацией) И последняя сжимается и отправляется в облако. Через 12 часов bamboo запустит тесты бекапов — создаст контейнер, распакует из zbackup, подключит как слейв к мастеру и через несколько минут проверит статус репликации. Если все OK — тест пройден.
Чтение со слейва БД — тут нужно осторожно. Слейвов должно быть больше одного. Один всегда держим без нагрузки — что бы он точно смог заменить мастер в любой ситуации. Ну и железо у него такое же как на мастере.
И расскажу как у нас бекапы устроены. Отдельные слейвы на которые прилетает «slave stop», делается бекап,«slave start». одна копия бекапа так и останется на винте не сжатой (если срочно понадобится). Она же упакуется zbackup на отдельный volume glusterfs(том c тройной репликацией) И последняя сжимается и отправляется в облако. Через 12 часов bamboo запустит тесты бекапов — создаст контейнер, распакует из zbackup, подключит как слейв к мастеру и через несколько минут проверит статус репликации. Если все OK — тест пройден.
Во-первых стоит понимать, что это был обзорный доклад для тех, у кого грубо говоря 1 сервер.
Про vrrp: обычно провайдеры дают отдельный vlan на каждого клиента, тогда с ним нет проблем никаких (но всегда стоит уточнять).
Переключение мастера можно сделать на автомате, никто не спорит, но есть много подводных камней про флапы, время на заливку слэйва с нового мастера итд (особенно они заметны на больших базах). Я придерживаюсь мнения, что убить N человекомесяцев на отладку автопереключения для многих нецелесообразно, а без этого процедура остается очень стремной.
Про vrrp: обычно провайдеры дают отдельный vlan на каждого клиента, тогда с ним нет проблем никаких (но всегда стоит уточнять).
Переключение мастера можно сделать на автомате, никто не спорит, но есть много подводных камней про флапы, время на заливку слэйва с нового мастера итд (особенно они заметны на больших базах). Я придерживаюсь мнения, что убить N человекомесяцев на отладку автопереключения для многих нецелесообразно, а без этого процедура остается очень стремной.
Некоторые брокеры очередей заявляют о том, что они все проблемы с отказоустойчивостью решили, т.е. что они полностью отказоустойчивые — ставите несколько инстансов, они сами между собой договариваются — я в это не верю.
Я как раз ровно про это и говорил. Мне например очень не хочется разбираться как работает та же mnesia под нагрузкой, какие у нее краевые случаи, в каких случаях какие данные могут потеряться итд. Или взять к примеру kafka — тут тоже все сложно (прочитать по диагонали документацию недостаточно, увы). Я призывал в своем докладе пробовать решать задачу на уровне, где у вас больше компетенции — например на уровне клиента сервиса очередей. В этом случае можно относиться к сервису очередей как к ресурсу, который может в любой момент отказать, тогда обычно можно достаточно легко это обойти (не всегда, но в большинстве задач)
Хорошый дельный разбор, однозначно в закладки.
Как насчет идеи поставить 2 кеш сервиса(для high availability) по типу Varnish и кешировать все запросы. В случаях когда упал бек-энд, база, мемкеш итд итп — отдавать сохраненный кеш. В это время исправлять ошибку и как только проблема разрешится, Varnish начнет кешить свежий контент от бек-энда и отдавать свежий контент юзеру. TTL можно проставить очень маленький так как цель сохранять ответы сервера для ситуации когда будет сбой.
Как насчет идеи поставить 2 кеш сервиса(для high availability) по типу Varnish и кешировать все запросы. В случаях когда упал бек-энд, база, мемкеш итд итп — отдавать сохраненный кеш. В это время исправлять ошибку и как только проблема разрешится, Varnish начнет кешить свежий контент от бек-энда и отдавать свежий контент юзеру. TTL можно проставить очень маленький так как цель сохранять ответы сервера для ситуации когда будет сбой.
VRRP, CARP и т.д.… Вам от провайдера нужно добиться, чтобы оба сервера были в одном Ethernet-сегменте, чтобы они могли перекидываться служебными heartbeat’ами и прочее.
Свеживе версии keepalived умеют для VRRP unicast_peer, так что можно без L2 связности.
Sign up to leave a comment.
Жизнь проекта на production: советы по эксплуатации