Как стать автором
Обновить
  • по релевантности
  • по времени
  • по рейтингу

Uptime day: 12 апреля, полёт нормальный

Блог компании ITSummaВысокая производительностьРезервное копированиеКонференцииРаспределённые системы


«Да чего же ждать от конференций? Сплошь танцовщицы, вино, гулянки» — шутил герой фильма «Послезавтра».

Наверное, на каких-то конференциях и не такое бывает (делитесь историями в комментах), но на it-сборищах обычно вместо вина пиво (по завершении), а вместо танцовщиц — «танцы» с кодами и информационными системами. 2 года назад мы тоже вписались в эту хореографию, организовав конференцию Uptime day. В этом апреле, на День космонавтики, мы проводим её уже в четвёртый раз — традиционно бесплатно и традиционно под аккомпанемент вопросов «зачем вам это надо?»
На весеннем Uptime day будем говорить об организации резервирования веб-проектов со сложной распределённой архитектурой — способам переключения с боевого окружения на резервное, а также разбору различных сценариев отката и переключения на резервную площадку в случае неудачного деплоя.

А зачем нам это надо?.. Об этом под катом. И о том, чем вам будет полезна конференция Uptime day.
Читать дальше →
Всего голосов 23: ↑23 и ↓0 +23
Просмотры1.9K
Комментарии 4

«Битрикс24»: «Быстро поднятое не считается упавшим»

Блог компании ITSummaAmazon Web ServicesРезервное копированиеКонференцииОблачные сервисы
На сегодняшний день у сервиса «Битрикс24» нет сотен гигабит трафика, нет огромного парка серверов (хотя и существующих, конечно, немало). Но для многих клиентов он является основным инструментом работы в компании, это настоящее business-critical приложение. Поэтому падать — ну, никак нельзя. А что если падение все-таки случилось, но «восстал» сервис так быстро, что никто ничего и не заметил? И как удаётся реализовать при этом failover без потери качества работы и количества клиентов? Александр Демидов, директор направления облачных сервисов «Битрикс24», рассказал для нашего блога о том, как за 7 лет существования продукта эволюционировала система резервирования.


Читать дальше →
Всего голосов 35: ↑29 и ↓6 +23
Просмотры8.1K
Комментарии 1

Построение и эксплуатация отказоустойчивой anycast-сети

Блог компании Qrator LabsIT-инфраструктураСетевые технологииРазработка систем связи
Привет, Хабр! Ниже следует транскрипция доклада Евгения error2407 Богомазова (сетевой R&D инженер) и Дмитрия h8r Шемонаева (глава NOC) с прошедшего UPTIMEDAY. Видео в конце поста.


Сегодня мы бы хотели рассказать о том, какие проблемы возникают при построении сети anycast. Зачем мы полезли в это и чем там занимаемся.
Читать дальше →
Всего голосов 38: ↑37 и ↓1 +36
Просмотры6.8K
Комментарии 1

Failover: нас губит перфекционизм и… лень

Блог компании ITSummaIT-инфраструктураAccessibilityРезервное копированиеDIY или Сделай сам
Летом традиционно снижается и покупательская активность, и интенсивность изменения инфраструктуры веб-проектов, говорит нам Капитан Очевидность. Просто потому что даже айтишники, случается, ходят в отпуск. И CТО тоже. Тем тяжелее тем, кто остаётся на посту, но сейчас не об этом: возможно, именно поэтому лето — лучший период для того, чтобы не торопясь обдумать существующую схему резервирования и составить план по её улучшению. И в этом вам будет полезен опыт Егора Андреева из AdminDivision, о котором он рассказал на конференции Uptime day.

При строительстве резервных площадок, при резервировании есть несколько ловушек, в которые можно попасть. А попадаться в них совершенно нельзя. И губит нас во всем этом, как и во многом другом, перфекционизм и… лень. Мы пытаемся сделать всё-всё-всё идеально, а идеально делать не нужно! Нужно делать только определённые вещи, но сделать их правильно, довести до конца, чтоб они нормально работали.

Failover — это не какая-то такая весёлая фановая штука «чтоб было»; это вещь, которая должна сделать ровно одно — уменьшить время простоя, чтобы сервис, компания, теряла меньше денег. И во всех методах резервирования я предлагаю думать в следующем контексте: где деньги?


Читать дальше →
Всего голосов 31: ↑29 и ↓2 +27
Просмотры10.6K
Комментарии 2

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

Блог компании ITSummaБлог компании BadooВысокая производительностьNginxРезервное копирование


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

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

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

Читать дальше →
Всего голосов 70: ↑67 и ↓3 +64
Просмотры23.5K
Комментарии 17

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

Блог компании Mail.ru GroupБлог компании ITSummaВысокая производительностьВиртуализацияОблачные вычисления


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

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

Видеоверсию этой истории, первоисточником которой стал доклад на конференции Uptime day 4, организованной ITSumma, можно посмотреть на YouTube-канале Uptime Community.
Читать дальше →
Всего голосов 71: ↑66 и ↓5 +61
Просмотры13.9K
Комментарии 5