Pull to refresh

Опыт переноса веб-сервисов компании СОЮЗ в масштабируемый виртуальный комплекс

Reading time 4 min
Views 11K
Оверсан-Меркурий corporate blog
В начале марта мы достигли принципиального соглашения с представителями компании «СОЮЗ» по проведению мероприятий по виртуализации корпоративной ИТ-инфраструктуры. Если проще – то СОЮЗ с нашей помощью производит аутсорсинг ИТ-инфраструктуры, размещает собственные мощности в дата-центре «Оверсан-Меркурий» и проводит еще ряд мероприятий, в результате чего получает экономию средств и массу новых возможностей по развитию.

Тому, как мы переносили веб-сервисы компании в МВК, и технологическим особенностям реализации проекта и посвящен этот пост.

image

Читать дальше →
Total votes 55: ↑32 and ↓23 +9
Comments 31

«Идеальный» www кластер. Часть 1. Frontend: NGINX + Keepalived (vrrp) на CentOS

Reading time 9 min
Views 105K
Acronis corporate blog


Этом цикле статей «Идеальный www кластер», я хочу передать базовые основы построения высокодоступного и высокопроизводительного www решения для нагруженных web проектов для неподготовленного администратора.
Статья будет содержать пошаговую инструкцию и подойдет любому человеку кто освоил силу copy-paste
Ошибки найденые вами, помогут в работе и мне и тем кто будет читать эту статью позже! Так что любые улучшение и правки приветствуются!

Хочу отметить, что эта инструкция родилась в процессе миграции web-систем компании Acronis в высокодоступный кластер. Надеюсь мои заметки будут полезны и для Вас!.

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

На frontend мы будем использоваться связку из двух службы:



keepalived — реализации протокола VRRP (Virtual Router Redundancy Protocol) для Linux. Демон keepalived следит за работоспособностью машин и в случае обнаружения сбоя — исключает сбойный сервер из списка активных серверов, делегируя его адреса другому серверу.

Другими словами, у нас 2 сервера на которых прописано по одному публичному адресу. Если любой из этих серверов падает, то адрес упавшего подхватывается вторым.
Демоны keepalived общаются по протоколу VRRP, посылая друг другу сообщения на адрес 224.0.0.18.
Если сосед не прислал свое сообщение, то по истечению периода он считается умершим и оба адреса обслуживает оставшаяся нода. Как только упавший сервер начинает слать свои сообщения в сеть, все возвращается на свои места


nginx [engine x] — это HTTP-сервер и обратный прокси-сервер, а также почтовый прокси-сервер, написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных российских сайтов, таких как Яндекс, Mail.Ru, ВКонтакте и Рамблер. Согласно статистике Netcraft nginx обслуживал или проксировал 15.08% самых нагруженных сайтов в октябре 2013 года.

Основная функциональность HTTP-сервера

  • Обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;
  • Акселерированное обратное проксирование с кэшированием, простое распределение нагрузки и отказоустойчивость;
  • Акселерированная поддержка FastCGI, uwsgi, SCGI и memcached серверов с кэшированием, простое распределение нагрузки и отказоустойчивость;
  • Модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно;
  • Поддержка SSL и расширения TLS SNI.


Другие возможности HTTP-сервера

  • Виртуальные серверы, определяемые по IP-адресу и имени;
  • Поддержка keep-alive и pipelined соединений;
  • Гибкость конфигурации;
  • Изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;
  • Настройка форматов логов, буферизованная запись в лог, быстрая ротация логов;
  • Специальные страницы для ошибок 3xx-5xx;
  • rewrite-модуль: изменение URI с помощью регулярных выражений;
  • Выполнение разных функций в зависимости от адреса клиента;
  • Ограничение доступа в зависимости от адреса клиента, по паролю (HTTP Basic аутентификация) и по результату подзапроса;
  • Проверка HTTP referer;
  • Методы PUT, DELETE, MKCOL, COPY и MOVE;
  • FLV и MP4 стриминг;
  • Ограничение скорости отдачи ответов;
  • Ограничение числа одновременных соединений и запросов с одного адреса;
  • Встроенный Perl.


Читать дальше →
Total votes 46: ↑40 and ↓6 +34
Comments 79

Кластер высокой доступности на postgresql 9.6 + repmgr + pgbouncer + haproxy + keepalived + контроль через telegram

Reading time 32 min
Views 52K
ESOFT corporate blog *nix *Server Administration *Database Administration *Data storage *
Tutorial
Recovery mode
image

На сегодняшний день процедура реализации «failover» в Postgresql является одной из самых простых и интуитивно понятных. Для ее реализации необходимо определиться со сценариями файловера — это залог успешной работы кластера, протестировать его работу. В двух словах — настраивается репликация, чаще всего асинхронная, и в случае отказа текущего мастера, другая нода(standby) становится текущем «мастером», другие ноды standby начинают следовать за новым мастером.

На сегодняшний день repmgr поддерживает сценарий автоматического Failover — autofailover, что позволяет поддерживать кластер в рабочем состоянии после выхода из строя ноды-мастера без мгновенного вмешательства сотрудника, что немаловажно, так как не происходит большого падения UPTIME. Для уведомлений используем telegram.

Появилась необходимость в связи с развитием внутренних сервисов реализовать систему хранения БД на Postgresql + репликация + балансировка + failover(отказоустойчивость). Как всегда в интернете вроде бы что то и есть, но всё оно устаревшее или на практике не реализуемое в том виде, в котором оно представлено. Было решено представить данное решение, чтобы в будущем у специалистов, решивших реализовать подобную схему было представление как это делается, и чтобы новичкам было легко это реализовать следуя данной инструкции. Постарались описать все как можно подробней, вникнуть во все нюансы и особенности.
Читать дальше →
Total votes 43: ↑41 and ↓2 +39
Comments 45

Кластер PostgreSQL высокой надежности на базе Patroni, Haproxy, Keepalived

Reading time 25 min
Views 105K
System administration *Database Administration *DevOps *
Tutorial
Привет, Хабр! Встала передо мной недавно задача: настроить максимально надежный кластер серверов PostgreSQL версии 9.6.

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

Планируя кластер я проштудировал много статей, как из основной документации к PostgreSQL, так и различных howto, в том числе с Хабра, и пробовал настроить стандартный кластер с RepMgr, эксперементировал с pgpool.

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

В итоге где-то (уже не вспомню точно где) нашел ссылку на прекрасный проект Zalando Patroni, и все заверте…
Читать дальше →
Total votes 34: ↑34 and ↓0 +34
Comments 69

Отказоустойчивый кластер для балансировки нагрузки

Reading time 8 min
Views 51K
«NetAngels» corporate blog Nginx **nix *Server Administration *
Recovery mode

Поговорим о горизонтальном масштабировании. Допустим, ваш проект вырос до размеров, когда один сервер не справляется с нагрузкой, а возможностей для вертикального роста ресурсов уже нет.

Читать дальше →
Total votes 16: ↑14 and ↓2 +12
Comments 16

Наш рецепт отказоустойчивого Linux-роутера

Reading time 10 min
Views 41K
Флант corporate blog Configuring Linux *System administration **nix *Network technologies *

В высоконагруженных проектах всегда повышенные требования к избыточности и надежности. Одним из важнейших звеньев инфраструктуры является маршрутизатор, потому что от его устойчивости зависит доступность сети в целом. Именно на таких узлах мы используем одну из схем реализации отказоустойчивого виртуального роутера на базе GNU/Linux с использованием iproute2, NetGWM, keepalived, ISC DHCPD, PowerDNS. Как мы всё это настраиваем, читайте в этой статье.
Читать дальше →
Total votes 26: ↑24 and ↓2 +22
Comments 31

VyOS OpenSource Router

Reading time 5 min
Views 39K
Open source *IT Infrastructure *Network technologies *Software
В этой статье я хотел поднять не стандартную для меня тему о сетевом маршрутизаторе VyOS. Впервые я познакомился с этим проектом благодаря Нилу Андерсону (Neil Anderson) который составил гайд как у себя дома развернуть мини-лабораторию с NetApp симулятором и VyOS.


Ключевые проекты


VyOS это opensource проект на базе Debian Linux, который родился как форк от проекта Vyatta Core Edition of the Vyatta Routing software. Как и любой роутер VyOS оперирует на третьем уровне OSI и маршрутизирует North-South трафик. VyOS включает в себя следующие ключевые проекты:

  • Debian 8, ядро 4.19
  • FRRouting (в версии 1.1 и более древних использовался Quagga)
  • ISC-DHCP
  • Keepalived
  • StrongSwan
  • OpenVPN
  • PowerDNS
  • Wireguard
  • OpenNHRP
  • Accel-ppp
  • xL2tpd
  • Squid
  • mDNS-repeater
  • IGMP-Proxy
  • iPerf
  • более детальный список в Release notes

Настроить корпоративную сеть с VyOS роутером
Total votes 16: ↑16 and ↓0 +16
Comments 37

Как Badoo добился возможности отдавать 200k фото в секунду

Reading time 12 min
Views 24K
ITSumma corporate blog Badoo corporate blog High performance *Nginx *Backup *


Современный веб практически немыслим без медиаконтента: смартфоны есть практически у каждой нашей бабушки, все сидят в соцсетях, и простои в обслуживании дорого обходятся компаниям. Вашему вниманию расшифровка рассказа компании Badoo о том, как она организовала отдачу фотографий с помощью аппаратного решения, с какими проблемами производительности столкнулась в процессе, чем они были вызваны, ну и как эти проблемы были решены с помощью софтового решения на основе Nginx, обеспечив при этом отказоустойчивость на всех уровнях (видео). Благодарим авторов рассказа Олега Sannis Ефимова и Александра Дымова, которые поделились своим опытом на конференции Uptime day 4.

— Начнем с небольшого введения о том, как мы храним и кэшируем фотографии. У нас есть слой, на котором мы их храним, и слой, где мы фотографии кэшируем. При этом, если мы хотим добиваться большого хитрейта и снижать нагрузку на стораджи, нам важно, чтобы каждая фотография отдельного пользователя лежала на одном кэширующем сервере. Иначе нам пришлось бы ставить во столько раз больше дисков, во сколько у нас больше серверов. Хитрейт у нас в районе 99%, то есть мы в 100 раз снижаем нагрузку на наши storage, и для того, чтобы это сделать, еще 10 лет назад, когда все это строилось, у нас было 50 серверов. Соответственно, для того, чтобы эти фотографии отдавать, нам нужно было по сути 50 внешних доменов, которые эти серверы обслуживают.

Естественно, сразу встал вопрос: а если у нас один сервер упадет, будет недоступен, какую часть трафика мы теряем? Мы посмотрели, что есть на рынке, и решили купить железку, чтобы она решила все наши проблемы. Выбор пал на решение компании F5-network (которая, кстати, не так давно купила NGINX, Inc): BIG-IP Local Traffic Manager.

Читать дальше →
Total votes 70: ↑67 and ↓3 +64
Comments 17

Отказоустойчивый кластер с балансировкой нагрузки с помощью keepalived

Reading time 15 min
Views 38K
Configuring Linux *System administration *Network technologies *Server Administration *DNS *
Tutorial

Сегодня я расскажу о том, как быстро собрать отказоустойчивый кластер с балансировкой нагрузки с помощью keepalived на примере DNS-серверов.

Читать дальше →
Total votes 18: ↑17 and ↓1 +16
Comments 40

Босяцкий кластер высокой доступности

Reading time 8 min
Views 13K
High performance *System administration *Nginx *Network technologies *
Tutorial
Translation

Крайне минималистичная схема кластера высокой доступности, требующая только 2 сервера и ничего более. Пригодна в том числе для серверов у разных хостеров или в разных датацентрах. Позволяет решить вопрос отказоустойчивости для балансировщика, так чтобы он сам не был единой точкой отказа.

Читать далее
Total votes 50: ↑45 and ↓5 +40
Comments 41

Доступная отказоустойчивость для вашего сайта

Reading time 27 min
Views 2.9K
Website development *IT Infrastructure *Server Administration *Database Administration *Development for e-commerce *
Tutorial

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

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

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

А есть ли способы, защитить ваш интернет-магазин или другой сервис от таких проблем?

Да, конечно, есть, и не один, но также есть и множество нюансов.

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

Эта статья поможет вам настроить доступный вариант отказоустойчивости, созданный на базе технологии VRRP (Virtual Router Redundancy Protocol) и сервиса keepalived.

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

Читать далее
Total votes 3: ↑1 and ↓2 -1
Comments 44