Рубрика «отказоустойчивость»

Этот день — яркий пример того, как несколько вещей, которые сами по себе не приводят к отказу, могут удачно совпасть. Итак, 23 апреля было совершенно обычным днём, с обычным трафиком и обычной загрузкой ресурсов. Как обычно, с запасом больше трети, чтобы при потере любого из ЦОДов пережить это без проблем. Никто не думал, что к серверному мониторингу нужно прикручивать ещё мониторинг того, что говорит президент на прямой линии, поэтому дальше случилось вот что:

Как новость про +4 выходных дня уронила нам базу данных - 1

Примерно в 13:30 у нас резко подскочила нагрузка на поиск по авиации и по железнодорожным билетам. Где-то в этот момент РЖД сообщила о перебоях на сайте и в приложении, а мы начали экстренно наливать дополнительные инстансы бекендов во всех ЦОДах.

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

Как и любое другое облако, Yandex.Cloud — это многослойная иерархия абстракций: SaaS, лежащий поверх PaaS, запущенный на IaaS. Связность виртуальной инфраструктуры обеспечивает виртуальная же сеть, которая является, по сути, оверлеем. И только в самой глубине этой системы обнаруживается физическая сеть из проводов и коммутаторов. Мало кто вспоминает о ней, пока всё работает. А меж тем она — кровеносная система всей платформы.

Привет, я Марат Сибгатулин, сетевой инженер Yandex.Cloud. Яндекс про свою сеть рассказывал уже не раз. И про её физическую инфраструктуру, и про особенности устройства Yandex.Cloud, и про то, как вообще работает виртуальная сеть. Не буду повторяться. Расскажу о том, как мы запустили публичное облако на том, что было — на двух стойках, и масштабировали его до сети для десятков тысяч серверов, не наращивая неоплатный технический долг.

Как превратить две серверные стойки в сеть для десятков тысяч машин и не остаться в неоплатном техническом долгу - 1

Мы практикуем следующий подход к созданию и развитию чего бы то ни было: прототип → минимально необходимая функциональность и масштаб → рост → эволюционное развитие. На первый взгляд он естественен и очевиден, в отличие от подхода «сделать сразу идеально и на века». На деле — требует вдумчивого предварительного планирования, чтобы потом не подставлять в горячке новые костыли под старые, пытаясь поспеть за внезапным ростом.
Читать полностью »

Как подготовить сайт к росту нагрузки - 1

Только ленивый не достал с дальней полки свою экспертность и не предсказал «онлайнизацию» жизни — такую же вынужденную, как и режим самоизоляции. Но трафик, действительно, уже начал расти, а с учётом «каникул» до конца апреля ресурсы, предлагающие доставку товаров, услуги онлайн-образования и, особенно, онлайн-развлечений, могут оказаться не готовыми к потоку посетителей в новой реальности.

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

Итак, вот 10 пунктов, которые критичны для активной жизни вашего веб-проекта в ближайшие дни и недели:
Читать полностью »

Архитектура AERODISK vAIR или особенности национального кластеростроения - 1

Привет, Хабровчане! Мы продолжаем знакомить вас с российской гиперконвергентной системой AERODISK vAIR. В этой статье речь пойдет об архитектуре данной системы. В прошлой статье мы разобрали нашу файловую систему ARDFS, а в данной статье пройдёмся по всем основным программным компонентам, из которых состоит vAIR, и по их задачам.

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

RabbitMQ против Kafka: отказоустойчивость и высокая доступность - 1

В прошлой статье мы рассмотрели кластеризацию RabbitMQ для обеспечения отказоустойчивости и высокой доступности. Теперь глубоко покопаемся в Apache Kafka.

Здесь единицей репликации является раздел (partition). У каждого топика один или несколько разделов. В каждом разделе есть лидер с фолловерами или без них. При создании топика указывается количество разделов и коэффициент репликации. Обычное значение 3, это означает три реплики: один лидер и два фолловера.
Читать полностью »

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

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

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

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

Борис Цирлин и Александр Кушнеров
30.10.2019

Для опытного разработчика схем не составляет большого труда узнать знакомую схему, в каком бы виде она не была нарисована. В этой статье мы покажем, что две транзисторные схемы из патентов являются вариантом асинхронного счётного триггера (АСТ). По сравнению со стандартной схемой, в схемах из патентов отсутствуют некоторые транзисторы. Это может рассматриваться как неисправность. Мы покажем, что, если такая же неисправность возникает в стандартной схеме, она продолжает работать правильно. АСТ, реализованный только на элементах ИЛИ-НЕ [1] или только на элементах И-НЕ известен как гарвардский триггер. Оба варианта схем показаны на Рис. 1, где g7 – это индикатор завершения переходных процессов. В дальнейшем мы его рассматривать не будем. На Рис. 1 показаны также графы сигнальных переходов (STG) [2] построенные в Workcraft [3].

Распознавание цифровых схем. Асинхронный счётный триггер - 1

Рис. 1. Асинхронный счётный триггер (АСТ) и его STG.

Обратим внимание, что в обоих вариантах АСТ есть три пары элементов (g1, g2), (g4, g5) и (g3, g6), которые имеют общий вход. Транзисторные схемы элементов 2И-НЕ и 2ИЛИ-НЕ показаны на Рис. 2. Трёхвходовые элементы устроены аналогично и содержат 6 транзисторов.

Распознавание цифровых схем. Асинхронный счётный триггер - 2

Рис. 2. Транзисторные схемы элементов 2И-НЕ и 2ИЛИ-НЕ.

Возьмём два элемента 2ИЛИ-НЕ и выберем у каждого вход, где p-MOS транзистор подключён к Uпит. Соединим эти входы вместе и подключим к земле (лог. 0). Оба транзистора откроются и напряжение на их стоках будет равным Uпит. Достаточно ли этого чтобы безопасно соединить стоки и заменить два транзистора на один, как показано на Рис. 3? Нет. Нужно проверить что произойдёт если на общий вход подать лог. 1. Выходы обоих элементов соединятся с землёй, и мы будем иметь мостиковую схему из четырёх p-MOS транзисторов. Для оставшихся двух входов имеем четыре комбинации 0 и 1. Легко показать, что ни в одной из них не возникает короткого замыкания между Uпит и землёй.

Распознавание цифровых схем. Асинхронный счётный триггер - 3

Рис. 3. Два элемента 2ИЛИ-НЕ, имеющие общий вход.

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

Что бы вы почувствовали, если в один прекрасный летний день дата-центр с вашим оборудованием стал бы выглядеть вот так?

«Тушить» ли сервера, если «загорелся» смоук тест датацентра? - 1

Всем привет! Меня зовут Дмитрий Самсонов, я работаю ведущим системным администратором в «Одноклассниках». На фотографии один из четырёх дата-центров, где установлено оборудование, обслуживающее наш проект. За этими стенами находится около 4 тыс. единиц техники: серверы, система хранения данных, сетевое оборудование и т.д. — почти ⅓ всего нашего оборудования.
Большинство серверов — это Linux. Есть и несколько десятков серверов на Windows (MS SQL) — наше наследие, от которого мы на протяжении многих лет планомерно отказываемся.
Итак, 5 июня 2019 г. в 14:35 инженеры одного из наших дата-центров сообщили о пожарной тревоге.
Читать полностью »

Обеспечение отказоустойчивости хранилищ - 1

Всем привет! Недавно состоялся открытый вебинар «Обеспечение отказоустойчивости хранилищ». На нём рассмотрели, какие проблемы возникают при проектировании архитектур, почему выход из строя серверов — это не оправдание для падения сервера и как сокращать время простоя до минимума. Вебинар провёл Иван Ремень, руководитель направления серверной разработки в «Ситимобил» и преподаватель курса «Архитектор высоких нагрузок».


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

Прим. перев.: Рады поделиться переводом замечательного материала от старшего технологического евангелиста из AWS — Adrian Hornsby. В простых словах он объясняет важность экспериментов, призванных смягчить последствия сбоев в ИТ-системах. Вы, наверное, уже слышали про Chaos Monkey (или даже применяли подобные решения)? На сегодняшний день подходы к созданию подобных инструментов и их реализация в более широком контексте осуществляются в рамках деятельности, которую называют chaos engineering. Подробнее о ней читайте в этой статье.

Chaos Engineering: искусство умышленного разрушения - 1

«Но за всей этой красотой скрывается хаос и безумие». — Tanner Walling

Пожарные. Эти высококвалифицированные специалисты каждый день рискуют жизнью, борясь с огнем. Знаете ли вы, что перед тем, как стать пожарным, необходимо провести в тренировках минимум 600 часов? И это только начало. Согласно отчетам, пожарные тренируются до 80% своего рабочего времени.

Почему?

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js