Жизнь проекта на production: советы по эксплуатации

[7rgio]

В статье описаны как раз те риски которые с успехом решаются облачными решениями. Минус такого подхода, это чрезвычайно низкая масштабируемость и гибкость. Не рациональное использование ресурсов ведет к удорожанию всего решения в целом. Конечно в определенных ситуациях такой подход имет место быть. Все зависит от требований к проекту.

[NikolaySivko]

Особенно хорошо все эти проблемы закрывают облака типа google app engine, но там много своих проблем (они тоже падают и иногда надолго, есть задержки при работе с datastore, которые для некоторых задач очень сложно обходить). Выбор технологий/решений — всегда баланс

[DevOpsEngineer]

Всё-таки «низкий» стиль (лексика, т.е. язык) живого выступления не очень подходит для статьи.

[river-fall]

Отлично подходит, такую простыню текста пресным языком я бы не осилил — бросил бы читать на середине.
Фразы вроде «он кладет в очередь сообщение, в надежде, что его кто-то обработает, но на самом деле с другой стороны там все умерли, апокалипсис, в общем» дают понять, что текст писал человек, у которого душа болит за проект — гораздо приятнее читать.

[reff]

Такой стиль совсем не подходит. А слова вида "гемор" и "сдох" недопустимы даже для выступления. Статейка доказывает, что специалист не всегда является писателем, а писатель — специалистом. Тем не менее, спасибо автору.

[Sovigod]

Очень классно. И прям все хорошо расписано. Но один момент просто убил. Вы не боитесь VRRP (когда железки провайдеров на него иногда очень плохо реагируют), но боитесь автоматического переключения на реплику БД? Ну что за бред. На дворе не 2005 год. Даже mysql легко переключается с даунтаймом в секунды. Postgree/mongo/elasticsearch/redis еще быстрее отрабатывают. Какие бы не были инструкции шанс ошибки в 5 утра всегда выше чем работа автоматики. Лучше просто получить инфо о происшествии и утром спокойно решить проблему.

Чтение со слейва БД — тут нужно осторожно. Слейвов должно быть больше одного. Один всегда держим без нагрузки — что бы он точно смог заменить мастер в любой ситуации. Ну и железо у него такое же как на мастере.

И расскажу как у нас бекапы устроены. Отдельные слейвы на которые прилетает «slave stop», делается бекап,«slave start». одна копия бекапа так и останется на винте не сжатой (если срочно понадобится). Она же упакуется zbackup на отдельный volume glusterfs(том c тройной репликацией) И последняя сжимается и отправляется в облако. Через 12 часов bamboo запустит тесты бекапов — создаст контейнер, распакует из zbackup, подключит как слейв к мастеру и через несколько минут проверит статус репликации. Если все OK — тест пройден.

[NikolaySivko]

Во-первых стоит понимать, что это был обзорный доклад для тех, у кого грубо говоря 1 сервер.
Про vrrp: обычно провайдеры дают отдельный vlan на каждого клиента, тогда с ним нет проблем никаких (но всегда стоит уточнять).
Переключение мастера можно сделать на автомате, никто не спорит, но есть много подводных камней про флапы, время на заливку слэйва с нового мастера итд (особенно они заметны на больших базах). Я придерживаюсь мнения, что убить N человекомесяцев на отладку автопереключения для многих нецелесообразно, а без этого процедура остается очень стремной.

[Sovigod]

>> время на заливку слэйва с нового мастера
Это вы о чем? По моему варианту такое делается утром. После разбора полетов падания. А при переключении мастера такое нужно только редису вроде бы. Остальные легко переключат источник репликации на новый мастер.

[NikolaySivko]

Это было при ситуацию с 1 мастер + 1 слэйв. Еще раз, автоотработку проблем с мастером сделать можно, но это дорого (если не забыть ничего посчитать).
Наверное стоило назвать доклад «Отказоустойчивость для бедных» :)

[crazylh]

Некоторые брокеры очередей заявляют о том, что они все проблемы с отказоустойчивостью решили, т.е. что они полностью отказоустойчивые — ставите несколько инстансов, они сами между собой договариваются — я в это не верю.

Вроде нормально общались Вроде бы технический блог и про хайлоад, а раз так то неплохо разбираться как оно устроено внутри.

[NikolaySivko]

Я как раз ровно про это и говорил. Мне например очень не хочется разбираться как работает та же mnesia под нагрузкой, какие у нее краевые случаи, в каких случаях какие данные могут потеряться итд. Или взять к примеру kafka — тут тоже все сложно (прочитать по диагонали документацию недостаточно, увы). Я призывал в своем докладе пробовать решать задачу на уровне, где у вас больше компетенции — например на уровне клиента сервиса очередей. В этом случае можно относиться к сервису очередей как к ресурсу, который может в любой момент отказать, тогда обычно можно достаточно легко это обойти (не всегда, но в большинстве задач)

[crezd]

Хорошый дельный разбор, однозначно в закладки.

Как насчет идеи поставить 2 кеш сервиса(для high availability) по типу Varnish и кешировать все запросы. В случаях когда упал бек-энд, база, мемкеш итд итп — отдавать сохраненный кеш. В это время исправлять ошибку и как только проблема разрешится, Varnish начнет кешить свежий контент от бек-энда и отдавать свежий контент юзеру. TTL можно проставить очень маленький так как цель сохранять ответы сервера для ситуации когда будет сбой.

[Sanasol]

Для проектов где основной контент что-то вроде статей вполне допустимо.

А для чего-то где «бизнес-логика» и работа с данными постоянная(CRUD), увы не поможет.

[selivanov_pavel]

VRRP, CARP и т.д.… Вам от провайдера нужно добиться, чтобы оба сервера были в одном Ethernet-сегменте, чтобы они могли перекидываться служебными heartbeat’ами и прочее.

Свеживе версии keepalived умеют для VRRP unicast_peer, так что можно без L2 связности.