Рубрика «haproxy» - 2

в 13:00, , рубрики: api, BGP, HA, haproxy, ITSumma, Mail.Ru Cloud Solutions, openstack, uptime, uptimeday, балансировщик, Блог компании Mail.Ru Group, виртуализация, высокая производительность, Облачные вычисления, отказоустойчивость, системное администрирование

Как реализуется отказоустойчивая веб-архитектура в платформе Mail.ru Cloud Solutions - 1

Привет! Я Артем Карамышев, руководитель команды системного администрирования Mail.Ru Cloud Solutions (MCS). За последний год у нас было много запусков новых продуктов. Мы хотели добиться, чтобы API-сервисы легко масштабировались, были отказоустойчивыми и готовыми к быстрому росту пользовательской нагрузки. Наша платформа реализована на OpenStack, и я хочу рассказать, какие проблемы отказоустойчивости компонентов нам пришлось закрыть, чтобы получить отказоустойчивую систему. Я думаю, это будет любопытно тем, кто тоже развивает продукты на OpenStack.

Общая отказоустойчивость платформы складывается из устойчивости её компонентов. Так что мы постепенно пройдём через все уровни, на которых мы обнаружили риски и закрыли их.

Видеоверсию этой истории, первоисточником которой стал доклад на конференции Uptime day 4, организованной ITSumma, можно посмотреть на YouTube-канале Uptime Community.
Читать полностью »

в 12:06, , рубрики: BMC, haproxy, kubernetes, meetups, nginx, novnc, Блог компании Selectel, конференции, работа в команде, системное администрирование, управление проектами

Selectel MeetUp: системное администрирование - 1

Cogia.de, «Островок», Digital Vision Labs и Selectel рассказывают о Kubernetes, legacy code в современных системах и работе администраторов с другими отделами.

Небольшая предыстория

Selectel MeetUp ― это встречи с короткими докладами и живым общением. Идея мероприятия проста: послушать классных спикеров, пообщаться с коллегами, обменяться опытом, рассказать про свои проблемы и услышать, как их решали другие. В целом, все то, что называют нетворкингом в IT-сообществе.

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

12 сентября прошла первая встреча в новом формате. Вместе со спикерами из «ВКонтакте», UseDesk, Studyworld обсудили состояние и перспективы клиентского сервиса в русском IT. На этом решили не останавливаться.

3 октября в Selectel прошел митап для системных администраторов. В этот раз пригласили спикеров из компаний Cogia.de, «Островок» и Digital Vision Labs. Говорили про Kubernetes, legacy code в современных системах и работе администраторов с другими отделами. Представьте ― Питер, вечер, дождь, а у нас полный конференц-зал сисадминов. Ну как здесь не воодушевиться? Вадим Исаканов на свое выступление вообще из Челябинска приехал.

Пока мы думаем над темой следующего митапа, под катом публикуем записи докладов.
Читать полностью »

в 10:06, , рубрики: devops, haproxy, linux, network, tuning, Серверная оптимизация, Сетевые технологии

Приветствую, друзья!

В предыдущих двух статьях (раз, два) мы погружались в сложность выбора между технологиями и искали оптимальные настройки для нашего решения в Ostrovok.ru. Какую тему поднимем сегодня?

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

I’m going deeper underground, или о чем стоит знать, оптимизируя работу сетевого приложения - 1
Читать полностью »

в 7:37, , рубрики: devops, haproxy, http, keep-alive, network, tuning, микросервисы, Сетевые технологии, системное администрирование

И снова здравствуйте!

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

История блужданий по документации Haproxy, или на что стоит обратить внимание при его конфигурации - 1
Читать полностью »

в 8:25, , рубрики: devops, haproxy, nginx, reverse-proxy, высокая производительность, системное администрирование

Всем привет!

Сегодня мы хотим рассказать о том, как команда сервиса бронирования отелей Ostrovok.ru решала проблему роста микросервиса, задачей которого является обмен информацией с нашими поставщиками. О своем опыте рассказывает undying, DevOps Team Lead в Ostrovok.ru.

Пробы и ошибки при выборе HTTP Reverse Proxy - 1

Читать полностью »

в 17:00, , рубрики: haproxy, RabbitMQ, биллинговые системы, высокая производительность, Системы обмена сообщениями

«Компания» — оператор связи ПАО «Мегафон»
«Нода» — сервер RabbitMQ.
«Кластер» — совокупность, в нашем случае трех, нод RabbitMQ работающих как единое целое.
«Контур» — совокупность кластеров RabbitMQ, правила работы с которыми определяются на стоящем перед ними балансировщике.
«Балансировщик», «хап» — Haproxy – балансировщик, выполняющий функции переключения нагрузки на кластеры в рамках контура. Для каждого контура используется пара серверов Haproxy, работающих параллельно.
«Подсистема» — публикатор и/или потребитель сообщений, передаваемых через кролика
«СИСТЕМА» — совокупность Подсистем, являющая собой единое программно-аппаратное решение, используемое в Компании, характеризующееся распределённостью по всей территории России, но обладающее несколькими центрами, куда стекается вся информация и где происходят основные расчёты и вычисления.
СИСТЕМА – географически распределённая система – от Хабаровска и Владивостока до Санкт-Петербурга и Краснодара. Архитектурно это несколько центральных Контуров, разделенных по особенностям подсистем, к ним подключённым.
Читать полностью »

в 17:10, , рубрики: consul, devops, github, haproxy, high availability, mysql, Блог компании Southbridge, Серверное администрирование, системное администрирование

GitHub использует MySQL в качестве основного хранилища данных для всего, что не связано с git, поэтому доступность MySQL имеет ключевое значение для нормальной работы GitHub. Сам сайт, интерфейс API на GitHub, система аутентификации и многие другие функции требуют доступа к базам данных. Мы используем несколько кластеров MySQL для обработки различных служб и задач. Они настроены по классической схеме с одним главным узлом, доступным для записи, и его репликами. Реплики (остальные узлы кластера) асинхронно воспроизводят изменения главного узла и обеспечивают доступ для чтения.

Доступность главных узлов критически важна. Без главного узла кластер не поддерживает запись, а это значит, что нельзя сохранить необходимые изменения. Фиксация транзакций, регистрация проблем, создание новых пользователей, репозиториев, обзоров и многое другое будет просто невозможно.

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

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

Высокая доступность MySQL в GitHub - 1Читать полностью »

в 10:03, , рубрики: envoy, haproxy, nginx, балансировка нагрузки, Блог компании okmeter.io, Блог компании Конференции Олега Бунина (Онтико), высокая нагрузка, высокая производительность, системное администрирование

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

Тонкая настройка балансировки нагрузки - 1

Маленький минутрый пик в 84 RPS «пятисоток» — это пять тысяч ошибок, которые получили реальные пользователи. Это много и это очень важно. Необходимо искать причины, проводить работу над ошибками и стараться впредь не допускать подобных ситуаций.

Николай Сивко (NikolaySivko) в своем докладе на RootConf 2018 рассказал о тонких и пока не очень популярных аспектах балансировки нагрузки:

  • когда повторять запрос (retries);
  • как выбрать значения для таймаутов;
  • как не убить нижележащие серверы в момент аварии/перегрузки;
  • нужны ли health checks;
  • как обрабатывать «мерцающие» проблемы.

Под катом расшифровка этого доклада.

Читать полностью »

в 16:37, , рубрики: GUI, haproxy, python, web, системное администрирование

Современный мир системных администраторов обленил нас красивыми web-face-ами, что даже не охота ставить софт, где нет этого самого «гуя» (чувствую сейчас полетят камни от правоверных строчкеров), ну не через строку же постоянно туда лазить, правда? Все бы ничего, если софт поставил, настроил и забыл, а что делать, если туда надо постоянно лазить, править, ну и конечно же нет лога всех действий, не писать же каждый раз cp cfg cfg_back, со временем запутаешься и забьешь на это дело.

Как случайно написать Web-GUI для Haproxy - 1
Читать полностью »

в 5:29, , рубрики: ad-hoc решение., CORS, filelist, haproxy, javascript, jquery, kibana, logstash, redmine, автоматизация, Блог компании ИНФОРИОН, КодоБред, логи, ненормальное программирование, никто не читает теги, хук

Типичный юзкейс для Kibana — смотрим логи, видим ошибки, создаем тикеты по ним. Логов у нас довольно много, места для их хранения мало. Поэтому просто вставить ссылку на документ из Elasticsearch/Kibana недостаточно, особенно для низкоприоритетных задач: пока доберемся до нее, индекс с логом может быть уже удален. Соответственно, приходится документ сохранять в файл и прикреплять к тикету.

Если один раз это делать, то это еще куда ни шло, но создавать уже десять тикетов подряд будет тупо лень, поэтому я решил это «быстренько» (ха-ха) автоматизировать.

Автоматизация загрузки логов из Kibana в Redmine - 1

Под катом: статья для пятницы, экспериментальная фича javascript, пара грязных хаков, небольшая регулярка с галочками, reverse proxy, проигрыш безопасности удобству, костыли и очевидная картинка из xkcd.
Читать полностью »

123...4
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js