>> То есть при доступности 99,95% мы получаем 8,76 часов даунтайма в месяц, а не в год
Это что за бред? У вас с математикой плохо? Периодичность SLA влияет только на максимальный даунтайм за малый период.
Если SLA за месяц, то даунтайм в 1 час нарушит 99,9. А если за год — то и 8 часов подряд не нарушат SLA. В это смысле по месячное SLA удобнее.
InfluxDB для метрик отличное решение. Но если вам нужно метрик больше чем за пару последних недель — вам обязательно нужно использовать Continuous Queries для уплотнения данных. Тогда графики даже за несколько лет будут моментально отображаться.
DEPO40 — это же продавцы проксей. Реально ужасные люди. Тоже нас парсили через них. выделил самые бредовые UA и по ним автоматически наполнял ipset. Адреса держал в списке 1 сутки.
Ручками наполнять — боль. У меня в итоге в список разрастался до 25к ip адресов. А вообще у них их в разы больше.
Уже много лет проводим тесты по вопросу как быстрее парсить логи регэкспом. И много лет побеждает perl. Он создан для регулярок все таки. У нас объем меньше вашего, но и парсим мы только логи nginx.
Ansible проследит что бы везде был одинаковый формат. Syslog-ng направит поток из файла логов nginx на stdin парсера.
150 тысяч записей лога в минуту (многострочные данные мы считаем за одну запись) — в сумме со всех серверов дает <10%CPU нагрузки.
Согласен читал по диагонале и много упустил.
1. Про ZFS, снапшоты и предидущую статью у вас ни слова в статье. Откуда берутся delete? Конечно из кода. От необдуманных действий пользователей до неидеального кода. Не стоит называть реплику бекапом. Читатель статьи может подумать, что этого будет достаточно и без снапшотов
2. Вы меня не поняли. Я не про Atlas). Я про In-Memory Storage Engine
3. Это очень хорошо что вы можите сами все поднять. Но падает все — процессы, ядро, память, винты, сетевые карты. Про добавим сотрудников — даже смешно. Добавить админа вы не смогли(У вас же они есть, но почему-то делаете все вы)
4. вот тут я пропустил. Извиняюсь
Вы уж извините, но то то вы сделали с монгой это жесть.
1. Ваш бекап — это не бекап. Он вас не спасет от случайных drop|delete. И никак он вам не поможет откатить базу. Это просто еще одна реплика. У вас нет бекапа.
2. Монгу на рам диск? есть же специальный storage — memory. Тогда монга сама будет знать как использовать память и какого размера использовать буфферы.
3. Реплика сет на 4 ноды? это вот так выглядит
— В субботу терям бекап сервер — и откладываем его ремонт до понедельника( ну все ж работает и еще 3 есть)
— В воскресенье у нас что-то скушало рам (или умер один из дисков, или любая другая причина) — упал еще один процесс монги. Осталось два, но они оба в SECONDARY.
4. Задайте приоритеты у нод. А то у вас однажды при падении мастера все проголосуют за бекап. Который как я понял не особо сильный сервер.
Осталось пара практических вопросов.
1. Например есть у нас в группе web два аккаунта — developer1 и developer2. И все работает. В какой-то момент developer1 уходит с этого проекта и нам нужно удалить все его ключи со всех серверов. Пупет это сможет?
2. Частность от первого варианта. developer1 во время работы добавил ключ своего ноутбука, ручками в authorized_keys. Что будет с ними?
У Sеntinel было преимущество. Можно читать с localhost сколько угодно. А в Кластере чтение ограниченно скоростью сетевого интерфеса.
Бывали случаи, когда популярный на чтение ключ увеличивался в размерах ( до 1-2Мбайт). Как вы с таким боролись? Sеntinel это переживал вообще без осечек.
от prometheus понадобится и агент и сервер. А от telegraf только агент. Так ведь проще.
Или я ошибаюсь про prometheus? и он может писать сразу в influxdb?
Пару месяцев назад прочитал «Worm». Очень много, но читается не отрываясь. В начале похоже рассказ для читателя лет 13-15, но чуть позже понимаешь что ребенку такое лучше не читать.
5 лет с генту? И для вас стало сложностью перейти от сорцов к общим для всех серверов бинарникам? Это же азы генту в проде.
Эти бинарники нужно будет самому поддерживать и компилировать, но только один раз. И уже потом разливать по тестовым серверам.
Нужно ли это если есть готовые бинарные дистры? Каждый конечно решает сам. Но любой проект через какое-то время хочет использовать то, чего в них нет. Будь то pagespeed — гугловый модуль для nginx. Или устаревшая версия glasterfs т.к. обновить ее сразу и везде нет возможности. Ну или вы параноик и не доверяете сторонним репозиториям.
Вам придется создать свой и поддерживать его дальше. Вот только поддерживать свой репозиторий на debian/centos то еще удовольствие. Например если у сброка nginx в репе использует не ту версию openssl чем та что прилетела вам с офф апдейтом.
В генгу же вы все эти проблемы даже не увидите т.к. она знает что у вас зависит от openssl и сама все пересоберет с актуальной версией зависимостей.
Вы уж извините, но вы просто не осилили работу с генту на проде. Как и предидущий админ. f1inx все верно сказал.
Тот треш который вы описали можно вычистить и выровнять на генте. А на убунте/дебиане/центос пришлось бы переставлять на всех железках ОС.
Как я понимаю вы уговорили начальство на полный переезд на новую ОС? и куда?
PS. Помните пословицу про «два перезда» = «один пожар». На серверах такая же фигня.
>> время на заливку слэйва с нового мастера
Это вы о чем? По моему варианту такое делается утром. После разбора полетов падания. А при переключении мастера такое нужно только редису вроде бы. Остальные легко переключат источник репликации на новый мастер.
Очень классно. И прям все хорошо расписано. Но один момент просто убил. Вы не боитесь VRRP (когда железки провайдеров на него иногда очень плохо реагируют), но боитесь автоматического переключения на реплику БД? Ну что за бред. На дворе не 2005 год. Даже mysql легко переключается с даунтаймом в секунды. Postgree/mongo/elasticsearch/redis еще быстрее отрабатывают. Какие бы не были инструкции шанс ошибки в 5 утра всегда выше чем работа автоматики. Лучше просто получить инфо о происшествии и утром спокойно решить проблему.
Чтение со слейва БД — тут нужно осторожно. Слейвов должно быть больше одного. Один всегда держим без нагрузки — что бы он точно смог заменить мастер в любой ситуации. Ну и железо у него такое же как на мастере.
И расскажу как у нас бекапы устроены. Отдельные слейвы на которые прилетает «slave stop», делается бекап,«slave start». одна копия бекапа так и останется на винте не сжатой (если срочно понадобится). Она же упакуется zbackup на отдельный volume glusterfs(том c тройной репликацией) И последняя сжимается и отправляется в облако. Через 12 часов bamboo запустит тесты бекапов — создаст контейнер, распакует из zbackup, подключит как слейв к мастеру и через несколько минут проверит статус репликации. Если все OK — тест пройден.
telegraf -> influx(с использованием CQ) -> grafana -> kapacitor — вот реально шикарно. И практически не кушает ресурсов даже на очень больших объемах данных для мониторинга.
Очень редкий пример настройки со сложной авторизацией. Это вам спасибо!
Но смущает колхоз с 2,5 серверами под кластер монги. Что случается с кластером из 2 нод без резервных мощностей при падении одной из нод = Вторая падает еще быстрее чем первая. «Высокая отказоустойчивость» — это не про ваш пример.
Для наглядности
Это что за бред? У вас с математикой плохо? Периодичность SLA влияет только на максимальный даунтайм за малый период.
Если SLA за месяц, то даунтайм в 1 час нарушит 99,9. А если за год — то и 8 часов подряд не нарушат SLA. В это смысле по месячное SLA удобнее.
Ручками наполнять — боль. У меня в итоге в список разрастался до 25к ip адресов. А вообще у них их в разы больше.
Ansible проследит что бы везде был одинаковый формат. Syslog-ng направит поток из файла логов nginx на stdin парсера.
150 тысяч записей лога в минуту (многострочные данные мы считаем за одну запись) — в сумме со всех серверов дает <10%CPU нагрузки.
1. Про ZFS, снапшоты и предидущую статью у вас ни слова в статье. Откуда берутся delete? Конечно из кода. От необдуманных действий пользователей до неидеального кода. Не стоит называть реплику бекапом. Читатель статьи может подумать, что этого будет достаточно и без снапшотов
2. Вы меня не поняли. Я не про Atlas). Я про In-Memory Storage Engine
3. Это очень хорошо что вы можите сами все поднять. Но падает все — процессы, ядро, память, винты, сетевые карты. Про добавим сотрудников — даже смешно. Добавить админа вы не смогли(У вас же они есть, но почему-то делаете все вы)
4. вот тут я пропустил. Извиняюсь
1. Ваш бекап — это не бекап. Он вас не спасет от случайных drop|delete. И никак он вам не поможет откатить базу. Это просто еще одна реплика. У вас нет бекапа.
2. Монгу на рам диск? есть же специальный storage — memory. Тогда монга сама будет знать как использовать память и какого размера использовать буфферы.
3. Реплика сет на 4 ноды? это вот так выглядит
— В субботу терям бекап сервер — и откладываем его ремонт до понедельника( ну все ж работает и еще 3 есть)
— В воскресенье у нас что-то скушало рам (или умер один из дисков, или любая другая причина) — упал еще один процесс монги. Осталось два, но они оба в SECONDARY.
4. Задайте приоритеты у нод. А то у вас однажды при падении мастера все проголосуют за бекап. Который как я понял не особо сильный сервер.
Для вашего кейса достаточно вебхуков.
1. Например есть у нас в группе web два аккаунта — developer1 и developer2. И все работает. В какой-то момент developer1 уходит с этого проекта и нам нужно удалить все его ключи со всех серверов. Пупет это сможет?
2. Частность от первого варианта. developer1 во время работы добавил ключ своего ноутбука, ручками в authorized_keys. Что будет с ними?
Бывали случаи, когда популярный на чтение ключ увеличивался в размерах ( до 1-2Мбайт). Как вы с таким боролись? Sеntinel это переживал вообще без осечек.
Или я ошибаюсь про prometheus? и он может писать сразу в influxdb?
Эти бинарники нужно будет самому поддерживать и компилировать, но только один раз. И уже потом разливать по тестовым серверам.
Нужно ли это если есть готовые бинарные дистры? Каждый конечно решает сам. Но любой проект через какое-то время хочет использовать то, чего в них нет. Будь то pagespeed — гугловый модуль для nginx. Или устаревшая версия glasterfs т.к. обновить ее сразу и везде нет возможности. Ну или вы параноик и не доверяете сторонним репозиториям.
Вам придется создать свой и поддерживать его дальше. Вот только поддерживать свой репозиторий на debian/centos то еще удовольствие. Например если у сброка nginx в репе использует не ту версию openssl чем та что прилетела вам с офф апдейтом.
В генгу же вы все эти проблемы даже не увидите т.к. она знает что у вас зависит от openssl и сама все пересоберет с актуальной версией зависимостей.
Тот треш который вы описали можно вычистить и выровнять на генте. А на убунте/дебиане/центос пришлось бы переставлять на всех железках ОС.
Как я понимаю вы уговорили начальство на полный переезд на новую ОС? и куда?
PS. Помните пословицу про «два перезда» = «один пожар». На серверах такая же фигня.
Это вы о чем? По моему варианту такое делается утром. После разбора полетов падания. А при переключении мастера такое нужно только редису вроде бы. Остальные легко переключат источник репликации на новый мастер.
Чтение со слейва БД — тут нужно осторожно. Слейвов должно быть больше одного. Один всегда держим без нагрузки — что бы он точно смог заменить мастер в любой ситуации. Ну и железо у него такое же как на мастере.
И расскажу как у нас бекапы устроены. Отдельные слейвы на которые прилетает «slave stop», делается бекап,«slave start». одна копия бекапа так и останется на винте не сжатой (если срочно понадобится). Она же упакуется zbackup на отдельный volume glusterfs(том c тройной репликацией) И последняя сжимается и отправляется в облако. Через 12 часов bamboo запустит тесты бекапов — создаст контейнер, распакует из zbackup, подключит как слейв к мастеру и через несколько минут проверит статус репликации. Если все OK — тест пройден.
Но смущает колхоз с 2,5 серверами под кластер монги. Что случается с кластером из 2 нод без резервных мощностей при падении одной из нод = Вторая падает еще быстрее чем первая. «Высокая отказоустойчивость» — это не про ваш пример.